AWS 쿠키 설정과 Step Functions TestState 로컬 테스트 완벽 가이드

AWS 웹사이트를 쓰다 보면 화면 아래에 슬쩍 등장하는 쿠키 배너, 그리고 개발자라면 한 번쯤 마주치는 Step Functions 테스트… 둘 다 중요한데, 하나는 내 개인정보와 광고, 다른 하나는 서비스 신뢰성과 직결됩니다.

이 글에서는 일반 사용자 관점에서 AWS 쿠키와 광고·프라이버시 설정을 어떻게 다루면 좋은지, 그리고 개발자 관점에서 Step Functions TestState API로 워크플로를 로컬에서 똑똑하게 테스트하는 방법까지 한 번에 정리해보겠습니다.

쿠키 배너가 뜰 때마다 '대충 수락'을 눌러왔거나, Step Functions 테스트가 막막했다면 오늘 내용이 꽤 도움이 될 거예요.

AWS 사이트 쿠키, 왜 쓰이고 무엇을 저장할까?

AWS 사이트는 크게 두 종류의 쿠키를 사용합니다.

하나는 사이트가 기본적으로 돌아가기 위해 꼭 필요한 필수 쿠키이고, 다른 하나는 사용 경험 개선이나 마케팅을 위한 선택형 쿠키입니다.

필수 쿠키는 로그인 상태를 유지하고, 언어와 국가 설정을 기억해 주며, "쿠키를 허용/거부했다"는 사실 자체를 저장해 두는 역할을 합니다. 이게 없으면 매 페이지마다 다시 로그인하고, 다시 언어를 고르고, 쿠키 배너도 계속 보게 되겠죠.

반대로 선택형 쿠키는 우리가 사이트를 어떻게 사용하는지 통계를 모으거나, 자주 쓰는 기능을 기억해 주고, 관심사에 맞는 광고를 보여주기 위해 사용됩니다.

중요한 점은, 필수 쿠키는 끌 수 없지만 나머지 쿠키는 내가 어느 정도까지 허용할지 선택할 수 있다는 것입니다. 즉 "사이트를 쓰기 위한 최소한의 기억력"만 남겨두고 나머지는 조절할 수 있는 구조라고 볼 수 있습니다.

AWS 쿠키 카테고리 4가지, 한 번에 정리

AWS는 쿠키를 네 가지 카테고리로 구분해 설명합니다. 이 구분을 알고 있으면 쿠키 설정 화면이 훨씬 이해하기 쉬워집니다.

먼저 필수 쿠키는 서비스 제공에 꼭 필요한 쿠키입니다. 로그인, 계정 설정 변경, 장바구니, 보안 관련 기능 등이 여기에 해당하며, 사용자가 특정 동작을 수행할 때 함께 설정되는 경우가 많습니다.

성능 쿠키는 "사람들이 이 사이트를 어떻게 쓰고 있을까?"를 파악하는 용도로 쓰입니다. 어느 페이지에서 머무는 시간이 긴지, 어디에서 오류가 많이 나는지 등을 익명으로 수집해 사이트 품질을 개선하는 데 활용합니다.

기능 쿠키는 편의성을 높이는 역할을 합니다. 선호하는 언어, 레이아웃, 최근에 본 콘텐츠, 특정 위젯 또는 동영상 플레이어 설정 같은 개인화된 환경을 기억해, 다음 방문 때도 같은 경험을 이어갈 수 있게 해줍니다.

마지막으로 광고 쿠키는 AWS 또는 광고 파트너가 설정하여, 사용자의 관심사에 더 가까운 광고를 보여주는 데 활용됩니다. 이 쿠키를 통해 "아예 관련 없는 광고"보다는, 관심 있는 분야와 조금 더 가까운 광고가 노출되는 셈입니다.

AWS 쿠키 동의, 거부, 세부 설정까지 스마트하게 선택하기

AWS 사이트에 처음 들어가면 쿠키 배너에서 세 가지 정도의 선택지를 보게 됩니다.

"수락"을 누르면 필수를 포함해 성능, 기능, 광고 쿠키까지 한 번에 허용합니다. 사용자 경험 최적화, 통계 분석, 광고 개인화를 모두 허용하겠다는 의미죠.

"거부"를 선택하면 필수 쿠키를 제외한 나머지 카테고리의 쿠키는 전부 차단됩니다. 사이트는 돌아가지만, 일부 분석이나 개인화, 광고 관련 기능은 최소 수준으로만 동작합니다.

조금 더 세밀하게 조절하고 싶다면 "커스터마이즈" 옵션을 선택해 카테고리별로 따로 허용/거부를 지정할 수 있습니다. 예를 들어, 성능과 기능 쿠키는 허용하되 광고 쿠키만 끄는 식으로 나에게 맞는 조합을 만드는 것이 가능합니다.

이후 마음이 바뀌면 페이지 하단의 "Cookie preferences" 링크를 열어 언제든 다시 설정을 바꿀 수 있습니다. 다만, 특정 쿠키를 끄면 자동 로그인, 개인화 추천, 일부 위젯 같은 기능이 제대로 작동하지 않을 수 있다는 점은 미리 알고 있는 것이 좋습니다.

크로스 컨텍스트 행동 광고와 AWS 프라이버시 선택

요즘 광고에서 자주 등장하는 단어가 바로 "행동 기반 광고"입니다. AWS가 언급하는 "크로스 컨텍스트 행동 광고"는 한 사이트나 앱에서 수집된 정보를, 다른 회사의 사이트나 앱에서 광고에 활용하는 방식을 뜻합니다.

즉, A라는 서비스에서 본 행동이 B라는 완전히 다른 서비스의 광고 노출에 영향을 줄 수 있는 구조입니다. 그래서 이 부분은 프라이버시 민감도가 높은 사용자에게 특히 중요한 지점이 됩니다.

AWS 사이트에서는 이 기능을 허용할지 말지를 직접 선택할 수 있습니다. 설정 화면에서 허용 여부를 선택한 뒤 "프라이버시 선택 저장" 버튼을 누르면, 해당 선택이 저장되어 이후 광고 처리에 반영됩니다.

또한 브라우저에서 글로벌 프라이버시 컨트롤(GPC)과 같이 법적으로 인정된 거부 신호를 켜두면, AWS는 이를 사용자의 거부 의사로 인식하도록 설계되어 있습니다.

주의할 점은, 쿠키를 삭제하거나 다른 브라우저·기기에서 접속할 경우 이전에 저장해둔 설정이 사라질 수 있다는 것입니다. 새 환경에서 접속했다면 프라이버시 선택을 다시 한번 저장해 주어야 원하는 상태를 유지할 수 있습니다.

AWS Step Functions TestState, 배포 없이 워크플로 검증하기

이제 관점을 개발자로 바꿔보겠습니다. AWS Step Functions를 쓰다 보면 "이 상태 로직이 제대로 동작하는지, 굳이 배포하지 않고 확인할 수 없을까?"라는 고민이 생깁니다. 바로 이 지점에서 TestState API가 등장합니다.

TestState는 Step Functions의 상태를 실제 스테이트 머신으로 배포하지 않고, 로컬이나 CI 환경에서 JSON 정의와 입력만으로 실행해보게 해 주는 테스트 전용 기능입니다.

기존에는 "정의 → 배포 → 실행 → CloudWatch 로그 확인"이라는 제법 무거운 과정을 반복해야 했다면, 이제는 하나의 상태 또는 특정 상태를 선택해 빠르게 돌려보며 로직을 다듬을 수 있습니다.

특히 오류 처리, 데이터 변환, 서비스 연동 패턴 같은 부분을 개발 초기 단계부터 안정화할 수 있어, 나중에 프로덕션에서 겪게 될 시행착오를 크게 줄여줍니다.

모킹으로 Lambda·외부 서비스 없이도 Step Functions 고신뢰 테스트

TestState의 가장 큰 매력은 다운스트림 서비스 호출을 실제로 하지 않고도 테스트할 수 있다는 점입니다.

예를 들어 Lambda를 호출하는 Task 상태를 점검하고 싶다면, Lambda를 진짜로 실행하는 대신 "Lambda가 이런 응답을 돌려줬다"는 모의 데이터를 넘겨줄 수 있습니다. 그러면 Step Functions는 해당 응답을 받은 것처럼 상태를 처리합니다.

흥미로운 점은, 이 모의 응답이 단순한 임의 JSON이 아니라, 실제 AWS 서비스의 API 스키마에 맞는지 검사된다는 것입니다. 필드 이름이나 타입이 틀리면 테스트 단계에서 바로 오류가 발생해, 나중에 런타임에서 터질 문제를 미리 잡아낼 수 있습니다.

에러 상황도 마찬가지입니다. Lambda에서 발생하는 특정 예외를 흉내 내거나, 외부 HTTP 호출 실패를 재현해 볼 수 있어 Retry, Catch, 분기 로직이 설계대로 동작하는지 세밀하게 검증할 수 있습니다.

게다가 모의 응답을 사용할 땐 해당 서비스에 대한 IAM 권한도 필요 없기 때문에, 인프라 권한 세팅 전 단계에서도 워크플로 로직 자체는 충분히 검토할 수 있습니다.

STRICT·PRESENT·NONE, TestState 검증 수준 고르는 법

모킹을 할 때 "얼마나 엄격하게 검증할 것인가"도 TestState에서 중요한 옵션입니다.

STRICT 모드는 실제 서비스 응답과 거의 동일한 구조를 요구하는 가장 강력한 검증 모드입니다. 필수 필드를 포함해 스키마를 꼼꼼하게 확인하기 때문에, 프로덕션에 가까운 수준의 신뢰도를 확보하고 싶을 때 적합합니다.

PRESENT 모드는 필드 이름과 타입 위주의 다소 느슨한 검증을 수행합니다. 응답 구조가 전반적으로 맞는지 확인하되, 세부 필수 필드까지 강하게 요구하지는 않습니다. 빠르게 반복 테스트를 돌리면서도 기본적인 형식 오류는 잡고 싶을 때 유용합니다.

NONE 모드는 검증을 생략하고 어떤 JSON이든 허용합니다. 가장 자유로운 대신 "실제 서비스에는 없는 응답 형태"도 쉽게 통과시킬 수 있으므로, 최종 안정화 단계보다는 아이디어 실험이나 프로토타입 단계에 더 어울립니다.

에러 모킹에서는 에러 코드와 원인을 지정해 "이 상태가 어떤 예외를 만났을 때 어떻게 동작하는지"를 반복해서 재현할 수 있습니다. 덕분에, 평소라면 프로덕션에서 우연히 한 번 만날까 말까 한 극단적인 장애 상황도 마음껏 시뮬레이션해 볼 수 있게 됩니다.

Map·Parallel까지, Step Functions 주요 상태 타입 로컬 테스트

실제 서비스 아키텍처에서는 단순 Task보다 Map과 Parallel 같은 복잡한 제어 흐름이 훨씬 자주 등장합니다. TestState는 이런 상태 타입도 대부분 지원합니다.

예를 들어 Distributed Map 상태를 테스트할 때, 아이템 배열을 입력으로 주고 각 아이템을 처리한 결과를 모의 응답으로 설정하면 됩니다. 그러면 Map 상태가 각 항목을 어떻게 순회하고, 결과를 어떤 구조로 합치는지 로컬에서 확인할 수 있습니다.

Parallel 상태도 각 브랜치의 결과를 배열 형태로 모킹해, 브랜치별 실행 결과가 최종 출력에 어떻게 병합되는지, 한 브랜치에서 오류가 나면 전체 흐름에 어떤 영향을 주는지 미리 검증할 수 있습니다.

이렇게 Map/Parallel 상태를 충분히 테스트해두면 "실제 데이터가 들어가니 출력 구조가 예상과 다르다"거나 "한 브랜치의 오류가 전체 실패로 이어질 줄 몰랐다" 같은 문제를 배포 전에 발견하게 됩니다. 이는 나중에 운영 중 장애를 막는 데 큰 도움이 됩니다.

StateName으로 특정 상태만 골라 디버깅하는 방법

실무에서는 수십 개 상태가 이어진 거대한 스테이트 머신을 한 번에 테스트하기보다는, 특정 상태 하나만 집중적으로 확인해야 할 때가 많습니다.

TestState는 전체 스테이트 머신 정의를 한 번 넘겨준 뒤, StateName을 지정해 그 안의 특정 상태만 선택해 실행할 수 있습니다.

예를 들어 "3번째 재시도에서만 발생하는 오류"나 "Map 상태의 특정 아이템 처리 과정"처럼 재현이 까다로운 상황을 StateName과 입력 조합으로 깔끔하게 다시 만들어 볼 수 있습니다.

이 과정에서 입력 데이터, 재시도 횟수, 에러 유형 등을 세밀하게 조정하면, 실제 프로덕션 환경에서는 만들기 힘든 엣지 케이스까지 손쉽게 테스트할 수 있습니다. 결과적으로 디버깅 시간이 눈에 띄게 줄어드는 효과를 기대할 수 있습니다.

inspection-level DEBUG로 Step Functions 내부 흐름까지 들여다보기

테스트에서 정말 값진 순간은 "왜 이 값이 여기서 사라졌는지"를 정확히 알게 되는 때입니다. TestState의 inspection-level 옵션은 바로 이 부분을 도와줍니다.

inspection-level을 DEBUG로 설정하면 단순 최종 output뿐 아니라, 상태가 입력을 어떻게 변환해 나가는지도 단계별로 보여줍니다.

예를 들어 Lambda Task 상태라면, 원래 들어온 input, InputPath 적용 후 데이터, Parameters로 실제 서비스에 전달되는 페이로드, 모의 또는 실제 응답, ResultSelector 적용 결과, ResultPath 병합 이후 최종 출력까지 모두 확인할 수 있습니다.

이 정보를 하나씩 따라가다 보면 "여기서 JSONPath가 잘못됐구나", "이 ResultPath 때문에 기존 필드가 덮어씌워졌네" 같은 문제를 금방 파악하게 됩니다.

복잡한 JSON 변환과 경로 설정을 많이 사용하는 Step Functions 특성상, 이 디버깅 경험은 워크플로 품질을 끌어올리는 데 상당히 큰 도움을 줍니다.

로컬 개발·CI/CD에서 TestState를 활용하는 실전 전략

TestState는 "한 번 써보고 마는 도구"라기보다, 개발 과정 전체에 자연스럽게 녹여 쓰는 것이 핵심입니다.

로컬 개발 단계에서는 자주 쓰는 테스트 프레임워크(pytest, Jest, JUnit 등) 안에서 TestState 호출을 스크립트로 감싸, 사실상 단위 테스트처럼 운용할 수 있습니다. 코드 수정 → 로컬 테스트 실행 → 실패한 상태만 빠르게 디버깅하는 사이클을 짧게 가져가는 것이 좋습니다.

CI/CD 파이프라인에서는 주요 상태마다 TestState 기반 테스트를 만들어두고, 코드가 변경될 때마다 자동으로 돌리게 하면 좋습니다. 특히 오류 처리, 데이터 변환, 통합 패턴(.sync, .waitForTaskToken 등)은 회귀 테스트 세트를 만들어 두면 배포할 때 훨씬 안심할 수 있습니다.

모든 다운스트림 서비스를 모킹하면 네트워크나 외부 시스템 상태에 관계없이 테스트를 안정적으로 돌릴 수 있고, 불필요한 비용도 줄일 수 있습니다. 이렇게 쌓인 신뢰도는 결국 "배포가 두렵지 않은 팀 문화"로 이어집니다.

TestState 지원 리전, 요금, 기술 스택 호환성

현실적인 부분도 짚고 넘어가겠습니다.

TestState의 향상된 기능은 Step Functions가 지원되는 모든 AWS 리전에서 사용할 수 있어, 별도의 리전 제약을 크게 걱정할 필요는 없습니다.

요금 면에서도 TestState 호출은 Step Functions 서비스 내에서 추가 비용 없이 제공되는 모델이라, 테스트를 자주 돌린다고 해서 청구서가 갑자기 튀어나올 걱정은 거의 없습니다. 오히려 "많이 돌릴수록 이득"에 가까운 도구라고 볼 수 있습니다.

HTTP 요청만 보낼 수 있다면 언어와 프레임워크에 상관없이 통합 가능하므로, Node.js + Jest, Python + pytest, Java + JUnit, Go, .NET 등 어떤 스택에서도 자유롭게 사용할 수 있습니다.

단, 세부 옵션과 지원 상태(Map/Parallel, Distributed Map, JSONata 표현식 등)는 계속 발전하고 있으니, 실제 도입 시에는 AWS 공식 문서와 최신 API 레퍼런스를 한 번 확인하고 들어가는 것을 추천합니다.

마무리: 쿠키는 현명하게, 워크플로는 배포 전에 실패하게

정리해보면, AWS 쿠키와 광고 설정은 "편리함과 개인정보 보호 사이의 균형"을 어디에 둘 것인지에 대한 선택입니다. 필수 쿠키는 그대로 두되, 성능·기능·광고 쿠키는 나의 민감도에 맞게 조절하고, 크로스 컨텍스트 행동 광고가 부담스럽다면 과감히 끄는 것도 좋은 방법입니다.

개발자 입장에서는 Step Functions TestState가 "배포 전에 실패하라"는 원칙을 실천하게 해주는 강력한 도구입니다. 모킹과 검증 모드를 활용해 정상 케이스, 에러 케이스, 특수 상황까지 로컬과 CI 단계에서 충분히 실험해두면, 프로덕션에서 맞닥뜨릴 장애와 디버깅 스트레스를 크게 줄일 수 있습니다.

개인적으로 추천하는 셋업은 다음과 같습니다.

• 쿠키: 기본은 최소 허용, 필요할 때 기능·성능 쿠키만 선택적으로 허용, 광고와 크로스 컨텍스트 광고는 본인 기준에 따라 엄격하게 관리하기

• TestState: 새 스테이트 머신을 만들 때마다 초기 설계 단계에서부터 TestState 테스트를 함께 작성해, 정의와 테스트를 한 세트로 관리하기

이 두 가지 습관만 몸에 익혀도, 사용자로서는 더 안전하게, 개발자로서는 더 안정적으로 AWS를 활용할 수 있을 것입니다.

출처 및 참고 : AWS 쿠키 설정과 Step Functions TestState 로컬 테스트 이해하기

초보자를 위한 AWS 쿠키 설정 실전 가이드

AWS 사이트에 처음 들어가 쿠키 배너를 봤을 때, 초보자라면 이렇게 생각하면 쉽습니다.

• "사이트가 제대로 돌아가게 하는 최소한" → 필수 쿠키

• "조금 더 편하게 쓰게 해 주는 옵션" → 성능·기능 쿠키

• "광고를 더 개인화하는 옵션" → 광고 쿠키

일반적으로 보안·프라이버시가 걱정된다면, 아래처럼 선택해도 사이트 이용에 큰 문제는 없습니다.

1. 쿠키 배너가 뜨면 "모두 수락" 대신 "커스터마이즈(설정 변경)"를 선택합니다.

2. 필수 쿠키는 어차피 꺼지지 않으니 그대로 둡니다.

3. 성능 쿠키: 사이트 품질 개선에 도움은 되지만 꼭 필요하진 않습니다.

   • "괜찮다" → 켜두기

   • "최소한만 남기고 싶다" → 끄기

4. 기능 쿠키: 자동 로그인, 최근 본 콘텐츠, 언어·지역 기억 같은 편의 기능을 원하면 켜두는 것이 좋습니다.

5. 광고 쿠키와 크로스 컨텍스트 행동 광고는, 맞춤형 광고가 불편하다면 과감히 끄면 됩니다.

나중에 마음이 바뀌면, 페이지 맨 아래의 "Cookie preferences" 링크에서 언제든 다시 조정할 수 있습니다. 쿠키를 크게 줄였는데 사이트가 너무 불편해졌다면, 기능 또는 성능 쿠키만 선택적으로 다시 켜는 식으로 "조금씩 조정"해 보는 것이 좋습니다.

브라우저에서 쿠키를 한 번에 삭제하면 AWS에 저장해 둔 동의·거부 기록도 함께 지워질 수 있습니다. 이 경우 AWS 사이트에 다시 방문했을 때 쿠키 배너가 또 뜨는 것이 정상이며, 이때 다시 원하는 설정을 선택해 주면 됩니다.

Step Functions TestState, 한눈에 보는 동작 흐름

초보자 입장에서는 TestState가 "어디에다 무엇을 보내고, 무엇을 받는 도구인지"가 가장 헷갈립니다. 큰 흐름만 간단히 정리하면 다음과 같습니다.

1. 상태 머신 정의 준비

   • 평소에 쓰는 ASL(Amazon States Language) JSON 정의를 준비합니다.

   • 아직 실제로 배포하지 않아도 됩니다. 파일이나 문자열 형태면 충분합니다.

2. 테스트할 상태 선택

   • 정의 안에 여러 상태가 있다면, 그중 한 상태의 이름(StateName)을 골라 "이 상태만 시험해 볼게"라고 지정합니다.

   • 전체 흐름이 아니라, 특정 Task/Map/Parallel 상태 하나만 골라 미리 점검하는 느낌입니다.

3. 입력(JSON) 준비

   • 실제 서비스에서 이 상태가 받게 될 입력을 JSON으로 적습니다.

   • 예: {"userId": 123, "orderId": "ABC-001"} 같은 형태

4. 모킹(가짜 응답/에러) 설정

   • 이 상태가 Lambda, 다른 AWS 서비스, 외부 API를 호출한다면, 그 결과를 진짜로 호출하지 않고 "이렇게 응답했다고 치자" 하고 JSON으로 적습니다.

   • 에러를 시험해보고 싶다면, "이런 오류가 났다고 가정"하는 에러 정보도 함께 적을 수 있습니다.

5. 검증 수준 선택(STRICT / PRESENT / NONE)

   • STRICT: 실제 서비스 응답과 구조가 거의 같아야만 통과 (가장 엄격, 가장 안전)

   • PRESENT: 구조는 대체로 맞는지만 확인 (중간 수준)

   • NONE: 구조 검사 없이 아무 JSON이나 허용 (가장 자유롭지만 실수도 함께 통과)

6. TestState 호출 → 결과 확인

   • 위에서 준비한 정의, StateName, 입력, 모킹 정보를 TestState API에 보내면, Step Functions가 마치 실제로 실행한 것처럼 결과를 계산해 돌려줍니다.

   • 성공/실패 여부, 최종 출력, 오류가 났다면 어떤 지점에서 왜 났는지를 반환해 줍니다.

이 과정을 반복하면서 "입력 → 상태 내부 처리 → 출력"이 내가 설계한 대로 흘러가는지 확인하는 것이 TestState의 핵심입니다. 실제 서비스(Lambda, 외부 API)를 부르지 않기 때문에, 비용과 리스크 없이 마음껏 실험할 수 있다는 점이 가장 큰 장점입니다.

DEBUG 모드로 보는 Step Functions 데이터 흐름, 직관적으로 이해하기

초보자에게 Step Functions가 어려운 가장 큰 이유는 "JSON이 이리저리 바뀌는 과정"이 잘 안 보인다는 점입니다. inspection-level을 DEBUG로 설정하면 이 흐름을 단계별로 눈으로 확인할 수 있어 이해가 훨씬 쉬워집니다.

DEBUG 모드에서는 대략 이런 단계들이 드러납니다.

1. 원본 입력(Input)

   • 상태가 처음 받는 JSON 전체가 어떻게 생겼는지 보여줍니다.

2. InputPath 적용 후 데이터

   • InputPath를 써서 "이 입력 중에서 이 부분만 골라 쓰겠다"라고 했다면, 실제로 어떤 부분이 잘려 나가고 어떤 데이터만 남았는지를 확인할 수 있습니다.

   • 여기서 예상과 다르면 InputPath 표현식부터 점검하면 됩니다.

3. Parameters 적용 후, 실제 서비스로 보내는 페이로드

   • Lambda나 다른 AWS 서비스로 전달되는 최종 JSON 구조를 보여줍니다.

   • 필드 이름을 잘못 적었거나, 중첩 구조를 잘못 만든 경우 여기에서 바로 눈에 띕니다.

4. 서비스 응답(또는 모킹 응답)

   • 실제 호출이든, TestState에서 지정한 모의 응답이든, 상태가 받은 결과 JSON을 그대로 보여줍니다.

5. ResultSelector 적용 결과

   • 응답에서 필요한 필드만 뽑거나 재구성하는 단계입니다.

   • "이 필드만 남기고 나머지는 버리고 싶다"는 요구 조건이 제대로 구현됐는지 확인할 수 있습니다.

6. ResultPath 병합 후 최종 출력

   • 기존 입력과 새 응답이 하나로 합쳐진 최종 결과를 보여줍니다.

   • 이 단계에서 기존 필드가 덮어씌워졌는지, 새 필드가 잘 추가됐는지를 확인하면 됩니다.

JSONPath, InputPath, ResultPath 같은 개념이 헷갈린다면, 간단한 예제를 만들어 DEBUG 모드로 여러 번 실행해 보는 것이 가장 좋은 공부 방법입니다. "어떤 설정을 바꾸면 JSON의 어떤 부분이 어떻게 변하는지"를 눈으로 직접 보는 순간, 문서만 읽을 때보다 훨씬 빠르게 개념이 정리됩니다.