# AI는 나의 PMP 합격을 돕지 않았다, 학습 방식을 바꾸었을 뿐이다 > AI를 단순한 지식 검색 도구가 아닌, 질문을 유도하고 사고력을 훈련하는 파트너로 활용해 구축한 PMP 합격 뒤의 학습 피드백 시스템과 회고 기록. _Slug: ai-changed-how-i-learn · 2026-07-20_ PMP(Project Management Professional) 시험 합격 소식을 전했을 때, 가장 많이 받은 질문은 뜻밖에도 단순했다. > **"어떤 프롬프트를 쓰셨나요?"** 질문을 받을 때마다 가볍게 미소 지을 수밖에 없었다. 그들이 핵심을 놓치고 있음을 알았기 때문이다. 나를 합격으로 이끈 것은 특정 프롬프트의 텍스트가 아니었다. 내가 설계하고 반복했던 **'학습 워크플로우(Workflow)'** 그 자체였다. 이 깨달음은 단순히 PMP 시험 준비에만 국한되지 않는다. 내가 앞으로 배우고 습득해야 할 모든 영역의 공부 방식을 완전히 바꾸어 놓았다. 이 글은 미래의 내가 새로운 도전을 시작할 때, 다시 꺼내어 읽고 적용해야 할 나만의 학습 시스템에 대한 기록이다. --- ## 대부분의 사람들은 AI를 '구글'로 쓴다 나 역시 처음에는 같은 실수를 반복할 뻔했다. 1. 문제를 풀다 막히면 AI에게 질문한다. 2. AI가 즉시 제공하는 정답과 해설을 읽는다. 3. 이해했다고 착각하며 다음 문제로 넘어간다. 이 과정은 매우 효율적이고 생산적인 것처럼 느껴진다. 그러나 안타깝게도 이렇게 얻은 지식은 뇌리에 오래 머물지 않는다. 정답을 쉽게 얻을수록 뇌는 기억하려는 노력을 멈추기 때문이다. 어느 순간 깨달았다. **AI는 정답을 가르쳐 줄 때보다, 내 생각의 허점을 찌르는 더 좋은 질문을 던지게 할 때 비로소 진정한 가치를 발휘한다.** 정답 자판기가 아닌, 생각의 동반자(Thinking Partner)로 대해야 한다. --- ## 내가 구축한 학습 피드백 루프 (Learning Feedback Loop) 정답을 찾는 대신, 실수를 지식으로 전환하는 튼튼한 피드백 시스템을 구축했다. ``` [질문 & 문제 풀이] ↓ [스스로 시도] ↓ [오답 발견] ↓ [AI 해설 및 다각도 분석] ↓ [깊은 성찰] ↓ [개인 오답 노트] ↓ [플래시카드 등록] ↓ [다시 풀어보기] ``` 단순히 많이 푸는 것이 중요한 게 아니다. 오답이 발생했을 때 시스템이 작동하여 오답을 분석하고 내 지식으로 내재화하는 경로를 밟아야 한다. --- ## AI를 사고 파트너로 활용한 5가지 원칙 미래의 내가 공부할 때 반드시 고수해야 할 다섯 가지 원칙을 정리해 둔다. ### 1. 모든 오답의 '이유'를 해체하라 대부분 "왜 A가 정답인가?"를 묻는다. 하지만 진정한 배움은 나머지 보기들에 있다. 나는 AI에게 다음과 같이 질문하곤 했다. > *"이 문제에서 A가 정답인 건 알겠어. 그런데 왜 B, C, D는 오답이 될 수밖에 없어? 각각 어떤 상황이나 전제가 어긋났는지 구체적으로 비교해줘."* 맞는 보기를 하나 이해하는 것보다 틀린 보기 3개가 왜 잘못되었는지 오답 요소를 해체하는 과정이 훨씬 유용하다. 이 습관 덕분에 출제 기관(PMI)의 특유의 가치관과 출제 의도를 훨씬 깊이 있게 이해할 수 있었다. ### 2. 멘탈 모델의 경계를 비교하라 예를 들어 예측형(Predictive), 애자일(Agile), 하이브리드(Hybrid) 방법론 사이에서 갈등할 때, 단순히 "여기서는 어떤 방법론이 맞을까?"라고 묻지 않았다. > *"예측형, 애자일, 하이브리드 세 가지 접근법이 있어. 이 상황에서 각각의 방법론을 고집했을 때 발생할 수 있는 가장 치명적인 실패 시나리오는 무엇일까?"* 각 모델의 장점보다 **'어느 지점에서 실패하고 한계를 드러내는지(Failure modes)'**를 비교할 때, 비로소 각 멘탈 모델의 명확한 경계선이 그려졌다. ### 3. AI가 나를 비판하고 공격하게 하라 때로는 AI에게 내 논리를 정면으로 반박해 달라고 요청했다. 메타인지(Metacognition)를 강제로 작동시키는 훌륭한 방법이다. ```markdown 역할극 설정: "너는 깐깐하고 의심이 많은 PMP 수석 강사야. 내가 방금 도출한 결론에 대해 왜 내 생각이 틀렸는지 논리적인 맹점을 찾아내고, 나를 설득해봐." ``` AI의 날카로운 반박에 대응하기 위해 생각을 다시 정리하고 방어 논리를 세우는 과정에서, 머릿속의 어설픈 지식들이 단단하게 구조화되었다. ### 4. 실수를 재사용 가능한 지산(Asset)으로 전환하라 틀린 문제는 일회성 경험으로 날려 보내지 않고 자산화했다. * **플래시카드(Anki 등)**로 만들어 주기적인 복습 주기 설정 * 단순 요약이 아닌, **'내가 왜 이 오답에 매력을 느꼈는지'**에 대한 분석 노트 작성 * 다른 사람에게 설명할 수 있을 정도로 **짧은 한 문장 요약 작성** 오답을 자산으로 전환하는 과정을 반복하자, 초기에 가장 취약했던 영역들이 시험 막바지에는 가장 자신 있는 강점으로 변해 있었다. ### 5. 거시적인 오류 패턴을 파악하라 AI의 강점은 개별 문제의 답을 알려주는 데 있지 않다. 내가 수집한 오답 데이터 속에서 **'패턴'**을 추출해 주는 데 있다. 틀린 문제와 오답 노트를 뭉뚱그려 AI에게 입력하고 분석을 요청했다. * 반복되는 논리적 비약 * 개념 자체를 잘못 파악하고 있는 부분 * 특정 상황(예: 갈등 관리 등)에서의 오판 경향성 전체 범위를 무작정 회독하는 비효율적인 방식 대신, AI가 짚어준 내 생각의 취약점을 집중 타격하는 방식으로 공부의 밀도를 극대화할 수 있었다. --- ## 합격 이후 남겨진 생각들 시험이 끝난 후 LinkedIn에 올린 글은 감사하게도 21,000회 이상의 노출을 기록하며 많은 관심을 받았다. 하지만 정작 내게 들어온 피드백은 아쉬움을 남겼다. 대부분은 여전히 "어떤 프롬프트를 썼는지", "더 나은 꿀팁이 있는지"에만 집중했다. 사람들은 늘 눈에 보이는 단축키(Shortcuts)를 찾는다. 하지만 지속 가능한 성장은 좋은 프롬프트를 모으는 것에서 오지 않는다. **자신의 실수를 투명하게 대면하고, 이를 개선해 나갈 수 있는 단단한 학습 시스템을 구축하는 것**에서 시작된다. 프롬프트는 바뀔 수 있고, AI 모델도 계속해서 진화한다. 하지만 지식을 습득하고 소화해 나가는 피드백 루프는 변하지 않는 본질이다. ## 미래의 나를 위한 요약 (Key Takeaways) * AI를 지식 자판기가 아닌 **사고의 훈련 파트너**로 대하라. * 정답을 맞히는 것보다 **오답의 이유를 완벽하게 해체하는 것**이 먼저다. * 모든 실수를 방치하지 말고 **다시 꺼내볼 수 있는 학습 자산**으로 구조화하라. * 일시적인 동기부여는 흐려진다. 결국 지탱해 주는 것은 **피드백 시스템**이다. * 질문의 질이 곧 성장의 한계를 결정한다. 최고의 프롬프트는 언제나 **"내가 왜 틀렸을까?"**라는 질문이었다. 이 시스템은 PMP를 넘어, 앞으로 내가 마주할 프로젝트 매니지먼트, 언어 학습, 프로덕트 빌딩, 글쓰기 등 모든 영역의 뼈대가 될 것이다. 다음 번 새로운 학습이 필요할 때, 이 피드백 루프를 가장 먼저 가동하자. --- # AI를 활용해 혼자 제품을 만드는 과정: 아이디어에서 출시까지 > AI를 리서치, 기획, 개발, 테스트 파트너로 활용해 1인 제품을 아이디어에서 MVP와 실제 출시까지 만드는 현실적인 과정과 원칙을 정리했다. _Slug: building-products-alone-with-ai · 2026-07-15_ 예전에는 제품 하나를 만들려면 서로 다른 역할을 맡은 여러 사람이 필요했다. 지금은 AI 덕분에 혼자서도 사용자 조사, 기획, 디자인, 개발, 테스트, 문서 작성까지 빠르게 오갈 수 있다. 그렇다고 AI가 팀 전체를 대신해주는 것은 아니다. 오히려 혼자 만드는 사람에게 더 많은 판단과 책임이 돌아온다. 내가 생각하는 **AI를 활용한 1인 제품 개발**의 핵심은 코드를 빨리 생성하는 데 있지 않다. 해결할 문제를 좁히고, 불필요한 일을 줄이고, 실제 사용자에게 도달하는 시간을 단축하는 데 있다. 이 글은 아이디어를 떠올린 순간부터 MVP를 공개하고 피드백을 받기까지 내가 따르는 과정을 정리한 기록이다. AI는 속도를 높여주지만 방향을 정해주지는 않는다. 무엇을 만들지, 누구를 위해 만들지, 언제 멈출지는 사람이 결정해야 한다. ## AI는 공동 창업자가 아니라 속도를 높이는 도구다 AI에게 “좋은 서비스 아이디어를 알려줘”라고 물으면 그럴듯한 목록을 금방 얻을 수 있다. 문제는 그 목록이 내 경험, 내가 접근할 수 있는 사용자, 내가 감당할 수 있는 비용을 모른다는 데 있다. 그래서 나는 AI를 공동 창업자처럼 대하지 않는다. 대신 역할이 명확한 여러 명의 보조자처럼 사용한다. - **리서치 보조자:** 시장과 경쟁 제품을 빠르게 훑는다. - **기획 보조자:** 요구사항을 정리하고 빠진 조건을 질문한다. - **개발 보조자:** 작은 기능을 구현하고 코드를 설명한다. - **테스트 보조자:** 실패할 수 있는 경우와 테스트 항목을 찾는다. - **편집 보조자:** 랜딩 페이지, 안내 문구, 문서를 다듬는다. 최종 결정권은 항상 나에게 남긴다. 이 구분이 없으면 생성 속도는 빨라져도 제품은 쉽게 엉뚱한 방향으로 커진다. ## 1. 해결할 문제를 한 문장으로 정의한다 제품을 만들기 전에 먼저 아래 문장을 완성한다. > **[어떤 사람]이 [어떤 상황]에서 겪는 [구체적인 문제]를 [어떤 방식]으로 줄인다.** 예를 들어 “AI 일정 관리 앱을 만든다”는 제품 설명이지 문제 정의가 아니다. “여러 프로젝트를 동시에 운영하는 1인 사업자가 오늘 반드시 해야 할 일을 5분 안에 정하도록 돕는다”는 문장은 사용자와 상황, 결과가 보인다. 이때 AI에는 아이디어를 만들어달라고 하기보다 문장의 빈틈을 공격해달라고 요청한다. - 이 문제가 실제로 자주 발생하는가? - 사용자는 지금 어떤 방식으로 해결하고 있는가? - 돈이나 시간을 들여 바꿀 만큼 불편한가? - 더 좁게 정의할 수 있는 사용자는 누구인가? - 제품 없이도 검증할 수 있는 가설은 무엇인가? 좋은 시작점은 답이 많은 아이디어가 아니라, 확인해야 할 질문이 선명한 아이디어다. ## 2. AI로 조사하되 사람에게 확인한다 초기 조사에서 AI는 매우 빠르다. 경쟁 제품의 유형을 나누고, 예상 사용자를 정리하고, 인터뷰 질문 초안을 만드는 데 유용하다. 하지만 생성된 요약을 시장의 사실로 받아들이면 안 된다. 나는 조사 결과를 세 층으로 나눈다. 1. **AI가 제안한 가설** — 아직 확인되지 않은 아이디어 2. **직접 확인한 자료** — 제품 페이지, 가격, 리뷰, 공개 문서 3. **사용자가 말한 경험** — 인터뷰, 관찰, 실제 행동 제품 방향은 세 번째 층에 가까워질수록 신뢰할 수 있다. 가능하면 잠재 사용자 5명에게 같은 문제를 물어본다. “이 기능을 쓰겠어요?”보다 “최근 이 문제를 어떻게 해결했나요?”가 더 좋은 질문이다. 미래의 의향보다 과거의 행동이 강한 증거이기 때문이다. ## 3. 한 페이지 제품 명세를 만든다 조사가 끝나면 긴 기획서 대신 한 페이지짜리 제품 명세를 작성한다. 문서에는 다음 항목만 둔다. | 항목 | 적어야 할 내용 | |---|---| | 사용자 | 이번 버전이 집중할 한 종류의 사용자 | | 문제 | 반복해서 발생하는 구체적인 불편 | | 약속 | 사용 후 달라지는 한 가지 결과 | | 핵심 흐름 | 사용자가 처음부터 끝까지 수행하는 행동 | | 제외 범위 | 이번에는 만들지 않을 기능 | | 성공 기준 | 출시 후 확인할 행동 또는 숫자 | | 위험 | 개인정보, 비용, 정확도, 운영 부담 | AI에게 이 문서를 검토하게 하면 서로 충돌하는 조건이나 빠진 예외를 빠르게 찾을 수 있다. 특히 **제외 범위**를 명확히 적는 것이 중요하다. 혼자 만드는 제품은 기능 부족보다 범위 초과로 더 자주 멈춘다. 아이디어가 조사, 설계, 구현, 테스트를 거쳐 출시되는 AI 기반 1인 제품 개발 흐름 *AI가 각 단계를 빠르게 연결해도, 다음 단계로 넘어갈지 결정하는 사람은 제품을 만드는 나다.* ## 4. MVP는 가장 짧은 사용자 흐름만 만든다 MVP는 완성도가 낮은 제품이 아니라 **가장 중요한 가설을 가장 적은 기능으로 확인하는 제품**이다. 나는 첫 버전의 흐름을 대개 네 단계로 제한한다. 1. 사용자가 들어온다. 2. 필요한 정보를 입력한다. 3. 제품이 핵심 결과를 만든다. 4. 사용자가 결과를 저장하거나 다음 행동을 한다. 계정 설정, 대시보드, 알림, 결제, 관리자 화면은 핵심 가설과 직접 관련이 없다면 뒤로 미룬다. 먼저 클릭 가능한 화면이나 단순한 수동 서비스로 흐름을 검증할 수도 있다. 코드 한 줄 없이 사용자에게 결과를 직접 만들어주는 방식이 더 빠른 경우도 많다. AI를 사용하면 기능을 추가하기 쉬워진다. 바로 그 이유 때문에 더 강한 삭제 기준이 필요하다. “만들 수 있는가?”가 아니라 “이 기능 없이 가설을 검증할 수 없는가?”를 묻는다. ## 5. AI와 개발할 때는 작은 단위로 맡긴다 “이 서비스를 전부 만들어줘”라는 요청은 빠르게 많은 코드를 만들지만, 검토하기 어려운 시스템도 함께 만든다. 나는 작업을 화면 하나, 사용자 행동 하나, 데이터 흐름 하나처럼 작은 단위로 나눈다. AI에 개발 작업을 요청할 때는 네 가지를 함께 준다. ```text 목표: 사용자가 이메일로 로그인할 수 있게 한다. 현재 상태: 사용 중인 프레임워크와 관련 파일을 설명한다. 제약: 기존 구조, 보안 규칙, 수정하면 안 되는 범위를 적는다. 완료 조건: 성공·실패 흐름과 실행해야 할 테스트를 정의한다. ``` 코드가 생성되면 바로 다음 기능으로 넘어가지 않는다. 변경된 파일을 읽고, 실행하고, 실패 경로를 확인한다. 이해하지 못한 코드는 내가 유지할 수 없는 코드다. AI가 설명을 제대로 못하거나 테스트가 불안정하면 구현을 더 작은 조각으로 되돌린다. ### 내가 지키는 개발 순서 1. 현재 구조와 목표를 AI에 설명한다. 2. 먼저 구현 계획과 변경 파일 목록만 받는다. 3. 한 번에 하나의 작은 변경을 적용한다. 4. 타입 검사, 린트, 테스트, 빌드를 실행한다. 5. 브라우저에서 실제 사용자 흐름을 확인한다. 6. 변경 이유와 남은 위험을 기록한다. 이 순서를 지키면 AI가 만든 코드를 수동으로 다시 쓰는 시간보다 검토와 판단에 더 많은 시간을 사용할 수 있다. ## 6. 테스트와 보안은 AI에게 넘기지 않는다 AI는 테스트 케이스를 제안하고 보안 문제를 찾는 데 도움을 준다. 그러나 “문제가 없다”는 답을 보증으로 받아들이면 안 된다. 특히 인증, 결제, 개인정보, 파일 업로드, 외부 API가 들어가면 사람이 직접 확인해야 한다. 출시 전에는 최소한 다음을 점검한다. - 정상 흐름뿐 아니라 빈 입력, 잘못된 값, 중복 요청을 시험한다. - 비밀키와 개인정보가 브라우저나 로그에 노출되지 않는지 확인한다. - 사용자가 다른 사용자의 데이터에 접근할 수 없는지 확인한다. - AI 기능이 틀리거나 응답하지 않을 때의 화면을 준비한다. - 예상보다 사용량이 늘었을 때 비용 상한과 제한이 있는지 확인한다. - 모바일 화면, 느린 네트워크, 접근성 기본 동작을 확인한다. 사용자가 입력한 민감한 정보나 회사의 비공개 코드를 외부 AI 서비스에 보내기 전에는 데이터 보관 정책과 사용 권한을 반드시 확인해야 한다. ## 7. 작게 출시하고 실제 반응을 기록한다 출시는 마지막 단계가 아니라 가장 정확한 조사가 시작되는 시점이다. 처음부터 많은 사람에게 알리기보다 문제를 실제로 겪는 작은 사용자 그룹에 공개한다. 첫 출시에서는 페이지뷰보다 아래 행동을 본다. - 사용자가 설명 없이 핵심 흐름을 끝내는가? - 결과를 다시 사용하거나 다른 사람에게 공유하는가? - 어느 단계에서 멈추는가? - 제품이 사라지면 아쉽다고 말하는가? - 시간이나 비용을 지불할 의사가 행동으로 나타나는가? AI는 인터뷰 메모와 로그를 묶어 반복되는 패턴을 찾는 데 사용할 수 있다. 다만 서로 다른 사용자의 의견을 억지로 하나의 결론으로 합치지 않는다. 무엇을 고칠지는 제품의 약속과 가장 가까운 문제부터 선택한다. ## 혼자 제품을 만드는 7일 실행 루프 작은 실험은 다음과 같은 일주일 단위로 운영할 수 있다. | 날짜 | 할 일 | 결과물 | |---|---|---| | 1일차 | 문제와 사용자를 좁힌다 | 한 문장 문제 정의 | | 2일차 | 자료 조사와 사용자 대화 | 핵심 가설 3개 | | 3일차 | 제품 흐름과 제외 범위 결정 | 한 페이지 명세 | | 4~5일차 | AI와 핵심 흐름 구현 | 작동하는 MVP | | 6일차 | 테스트와 보안 점검 | 출시 체크리스트 | | 7일차 | 소수 사용자에게 공개 | 관찰 기록과 다음 결정 | 일주일 안에 좋은 제품이 완성되는 것은 아니다. 대신 계속 만들 가치가 있는지 판단할 만큼의 증거를 얻을 수 있다. 이 속도가 AI를 사용하는 가장 현실적인 이유다. ## AI가 잘하는 일과 직접 해야 하는 일 ### AI에 적극적으로 맡길 수 있는 일 - 자료의 첫 번째 분류와 요약 - 질문 목록과 문서 초안 작성 - 반복적인 코드와 테스트 뼈대 생성 - 오류 메시지 설명과 디버깅 가설 제안 - 문구의 여러 버전과 번역 초안 생성 - 회의 및 사용자 인터뷰 메모 정리 ### 끝까지 직접 책임져야 하는 일 - 어떤 문제를 해결할지 선택하는 일 - 사용자 말을 맥락 안에서 해석하는 일 - 제품의 품질과 보안 기준을 정하는 일 - 생성된 코드와 정보가 맞는지 검증하는 일 - 무엇을 버리고 언제 출시할지 결정하는 일 - 실패의 비용과 사용자에게 미칠 영향을 책임지는 일 ## 자주 묻는 질문 ### 개발자가 아니어도 AI로 제품을 만들 수 있을까? 간단한 프로토타입과 수동 서비스는 가능하다. 하지만 사용자의 데이터와 결제가 들어가는 실제 제품은 구조, 보안, 운영을 이해해야 한다. 모르는 부분을 AI의 확신으로 덮기보다 범위를 줄이거나 전문가의 검토를 받는 편이 안전하다. ### 어떤 AI 도구부터 선택해야 할까? 도구보다 먼저 작업을 정하는 것이 좋다. 조사, 문서 작성, 디자인, 코딩, 테스트 중 가장 많은 시간이 걸리는 한 단계를 고르고 거기에 맞는 도구 하나부터 사용한다. 도구를 여러 개 연결하는 것보다 반복 가능한 작업 방식을 만드는 것이 먼저다. ### AI가 만든 코드는 그대로 사용해도 될까? 그대로 배포하면 안 된다. 코드의 동작과 의존성, 라이선스, 보안, 예외 처리를 검토하고 프로젝트의 테스트와 빌드를 통과시켜야 한다. 설명할 수 없는 코드는 제품의 부채가 된다. ### 혼자 만들 때 가장 중요한 지표는 무엇일까? 초기에는 가입자 수보다 핵심 문제를 실제로 해결한 사용자 수가 중요하다. 제품의 핵심 행동을 끝낸 사람, 다시 돌아온 사람, 결과를 위해 비용을 지불한 사람을 먼저 본다. ## 결국 제품을 만드는 것은 사람이다 AI는 혼자 제품을 만드는 사람의 손을 빠르게 해준다. 조사와 구현 사이의 거리를 줄이고, 익숙하지 않은 역할을 시작할 수 있게 돕는다. 하지만 제품의 방향, 사용자에 대한 이해, 출시할 용기는 자동으로 만들어주지 않는다. 좋은 1인 제품은 가장 많은 AI 기능을 사용한 제품이 아니다. **작은 문제를 정확히 선택하고, 실제 사용자에게 빠르게 전달하고, 배운 내용을 다음 버전에 반영한 제품**이다. 나는 [삶을 하나의 프로젝트로 바라본다](/ko/posts/built-slowly-updated-daily). 제품 만들기도 마찬가지다. 완벽한 계획을 기다리기보다 작은 버전을 공개하고, 결과를 기록하고, 다음 결정을 내린다. AI는 그 프로젝트를 대신하는 존재가 아니라 더 짧은 주기로 실행하게 해주는 도구다. --- # AI가 짠 코드의 품질을 의심하는 법: 1인 개발자를 위한 8가지 검증 원칙 > AI 코딩 도구로 AttractiveWebAI, Shopify 앱 등을 개발하며 겪은 10가지 실패와, 동작하는 것처럼 보이는 'UI 착시'를 극복하고 코드 품질을 지키기 위한 8가지 현실적인 원칙을 공유합니다. _Slug: principles-of-maintaining-code-quality-with-ai · 2026-07-13_ #### 그럴듯한 화면이 준 착각 Shopify 멤버십 앱의 첫 데모 빌드가 성공했을 때, 나는 흥분을 감추지 못했다. 화면에는 깔끔한 대시보드가 떴고, 설정 메뉴의 토글 버튼들은 부드럽게 작동했으며, 포인트 적립 규칙을 입력하는 폼도 완벽해 보였다. 마우스를 클릭할 때마다 화면이 기민하게 반응했다. AI 코딩 도구에 몇 번의 지시어를 입력한 지 단 이틀 만에 얻은 결과였다. 이 속도라면 다음 주에 당장 앱스토어에 출시할 수 있을 것 같았다. 하지만 기쁨은 오래가지 않았다. 테스트 계정으로 상점에서 실제 결제를 진행하고 고객 등급을 올리려 하자, 앱은 아무런 반응도 하지 않았다. 코드를 뜯어보고서야 차가운 진실을 마주했다. 화면에 표시된 그럴듯한 숫자들은 전부 AI가 임의로 채워 넣은 Mock Data(가짜 데이터)였고, 정작 돈을 처리하는 결제 API와 포인트 적립 웹훅, 자동 할인 트리거는 단 한 줄도 작성되어 있지 않았다. 껍데기만 존재하고 알맹이는 없는 상태였다. 나는 전문 소프트웨어 엔지니어가 아니다. IT 프로젝트 매니저(PM)로 일하며 필요한 제품을 AI의 힘을 빌려 직접 만들고 배포하는 1인 제작자에 가깝다. 웹사이트 분석 SaaS인 AttractiveWebAI, Shopify 멤버십 앱, 그리고 macOS 창 미리보기 유틸리티까지 여러 제품을 개발하면서 Gemini, Claude, Codex 같은 도구들을 전방위로 활용했다. 처음에는 원하는 기능을 대강 묘사하면 알아서 작동하는 코드가 뚝딱 나오는 속도에 취해 있었다. 그러나 프로젝트 규모가 커지고 기능들이 얽히기 시작하자, 화면 뒤에 숨어 있던 결함들이 일제히 머리를 치켜들기 시작했다. --- #### AI가 숨겨둔 10가지 부채 배포 단계를 거치며 뼈아프게 기록한 실패의 목록은 생각보다 길고 구체적이었다. 1. **DB 저장 누락**: 프론트엔드 폼에서 '저장' 버튼을 누르면 화면에 성공 메시지가 뜨지만, 정작 Supabase 데이터베이스에는 아무것도 입력되지 않은 채 메모리 안에서만 데이터가 맴돌다 사라졌다. 2. **API 연결 증발**: 프론트엔드 UI의 멋진 버튼과 입력창은 완성되었으나, 백엔드 API 엔드포인트와 통신하는 코드가 누락되어 실제 서비스가 동작하지 않았다. 3. **가짜 데이터의 방치**: 개발 편의를 위해 임시로 삽입한 Mock Data와 테스트용 하드코딩 값이 실제 운영 모드에서도 그대로 사용되고 있었다. 4. **동일 코드의 중복 생성**: AI가 기존 프로젝트의 전체 구조를 기억하지 못해, 이미 존재하는 유틸리티 함수나 컴포넌트를 이름만 조금 바꾼 채 서너 개씩 중복으로 새로 만들어냈다. 5. **회귀(Regression) 오류**: 한 곳의 버그를 고치기 위해 코드를 수정하면, 이전에 잘 작동하던 전혀 다른 페이지의 기능이 깨져버리는 현상이 반복됐다. 6. **빌드 성공의 함정**: `npm run build`나 TypeScript 타입 검사는 완벽하게 성공했지만, 런타임에 특정 조건에서 브라우저가 흰 화면만 뿜어내는 치명적인 오류가 발생했다. 7. **`console.log`만 남은 보고**: AI가 기능 구현을 마쳤다고 당당히 답했으나, 코드를 열어보니 알맹이 대신 `console.log("TODO: 구현 예정")` 주석만 덩그러니 남겨져 있었다. 8. **데이터베이스 스키마 누락**: 로컬 개발 환경에서 Supabase 테스트 계정으로 잘 되던 기능을 실제 운영용 Supabase 계정으로 옮기면서, 코드와 환경변수는 바꿨지만 SQL 테이블과 트리거 스키마를 이관하지 않아 서비스 전체가 멈췄다. 9. **핵심 로직의 생략**: Shopify 앱 배포 과정에서 화면 디자인은 끝났으나, 정작 핵심인 Billing API 연동과 자동 할인 정책 호출 로직이 연결되지 않아 실제 수익 모델을 검증할 수 없었다. 10. **시스템 권한 인식 오류**: macOS 창 미리보기 유틸리티 개발 중, OS 설정 화면에서 접근성 권한과 화면 기록 권한이 켜져 있는 것처럼 보여도 실제 런타임 코드에서는 해당 권한 상태를 감지하지 못해 먹통이 되는 디바이스 수준의 예외가 빈번했다. 이 실패들을 수습하며 밤을 새우다 보니 한 가지 깨달음이 머리를 쳤다. AI 코딩에서 진짜 병목은 코드를 짜는 행위 자체가 아니었다. **AI가 뱉어낸 코드를 검증하고, 그것이 '완전히 완료되었다'는 사실을 인간의 눈으로 입증하는 과정**이 핵심이었다. 이를 방치하면 제품은 작동하는 척하는 기술 부채의 거대한 늪으로 변해버린다. 이 시행착오를 건너며 내가 정립한 8가지 코드 품질 검증 원칙을 공유한다. --- #### 원칙 1. 요청하기 전에 완료 조건(Definition of Done)부터 적는다 AI에게 \"로그인 기능 만들어줘\"라고 모호하게 요청하면, AI는 임의로 쉬운 방법을 찾아 대충 동작만 하는 코드를 짠다. 나는 기능을 요구하기 전에 반드시 검증해야 할 체크리스트를 미리 작성하여 질문에 포함한다. ```markdown [완료 조건] 1. 사용자가 Google OAuth 계정으로 로그인할 수 있는가? 2. 로그인 세션이 새로고침이나 브라우저 재시작 후에도 유지되는가? 3. 로그아웃 버튼을 누르면 세션이 삭제되고 메인 페이지로 리다이렉트되는가? 4. 로그인하지 않은 사용자가 API를 직접 호출할 때 401 Unauthorized 에러를 반환하는가? 5. 로그인한 사용자는 오직 자신의 데이터만 조회하고 수정할 수 있는가? 6. 비밀번호나 민감한 토큰이 로컬 스토리지에 평문으로 남지 않는가? ``` 이렇게 명확한 제약과 테스트 시나리오를 주면 AI는 예외 처리 코드와 보안 로직을 생략하지 않고 처음부터 꼼꼼히 뼈대를 채워 넣는다. #### 원칙 2. AI의 완료 보고를 절대 그냥 믿지 않는다 AI가 \"요청하신 기능을 완벽히 구현했습니다\"라고 말할 때가 가장 위험하다. 나는 AI의 보고 직후, 그 결과물을 확인하기 위해 언제나 다음 질문을 던져 답변을 요구한다. * 변경되거나 새로 생성된 파일의 전체 목록 * 각 파일에서 실제로 수정된 핵심 코드 영역과 이유 * 임시 테스트를 위해 남겨둔 Mock Data나 하드코딩된 값의 존재 여부 * 코드 내에 포함된 `TODO` 주석이나 `console.log` 위치 * 아직 구현하지 못했거나 환경 제약으로 남겨둔 기술적 한계 이 질문을 던지는 것만으로도 AI는 \"사실 이러이러한 부분은 임시 데이터로 처리했습니다\"라며 뒤늦게 누락된 부분을 털어놓거나 스스로 미완성된 코드를 보강한다. #### 원칙 3. 빌드 성공과 기능 성공을 엄격히 구분한다 컴파일러가 에러를 내지 않는다고 해서 비즈니스 로직이 성공한 것은 아니다. 터미널 창의 초록색 성공 메시지를 본 뒤에는 반드시 수동으로 다음 항목들을 하나씩 검증한다. * **상태 보존**: 폼을 작성하고 저장한 뒤 브라우저를 강제로 새로고침했을 때 데이터가 데이터베이스로부터 정확히 다시 로드되는지 확인한다. * **한계치 입력**: 빈 값 제출, 비정상적인 문자 입력, 중복 클릭을 연속으로 발생시켜 시스템이 뻗지 않는지 본다. * **권한 분리**: 비로그인 상태이거나 다른 사용자의 계정 토큰을 모방해 비공개 페이지나 API 엔드포인트에 접근을 시도해 본다. * **로그 확인**: 정상적으로 동작하는 화면 뒤에서 브라우저 콘솔창이나 서버 로그에 숨겨진 404 에러나 `unhandled rejection` 경고가 없는지 관찰한다. #### 원칙 4. 작업의 단위를 최소한으로 쪼갠다 한 번에 \"대시보드 페이지와 분석 데이터 연동을 한꺼번에 해줘\"라고 큰 덩어리로 주문하면 AI는 높은 확률로 내부 구조를 엉망으로 섞거나 일부 로직을 빼먹는다. 귀찮더라도 단계를 철저히 나눈다. 1. **데이터 스키마 설계**: 데이터베이스 테이블 구조와 관계 설정 SQL을 작성해 반영한다. 2. **API 핸들러 작성**: 데이터를 조회하고 저장하는 백엔드 API 엔드포인트를 먼저 만들고 Postman 등으로 단독 테스트한다. 3. **UI 바인딩**: 화면 구성 요소를 만들고 앞서 생성한 API에 붙인다. 4. **예외 처리 추가**: 네트워크 단절, 입력 오류, 에러 응답 상황의 안내 문구를 적용한다. 5. **프로덕션 검증**: 로컬 환경을 벗어나 staging 혹은 배포 주소에서 실제 동작 여부를 최종 확인한다. #### 원칙 5. 코드를 짠 AI와 검토하는 AI를 분리한다 하나의 채팅 세션에서 동일한 AI 모델에게 계속 코드를 짜게 하고 그 안에서 검토까지 시키면, 자신이 만든 코드의 논리 오류를 보지 못하는 인지 편향에 빠진다. 나는 기능을 구현하고 나면, 코드를 완전히 새로운 대화 세션이나 다른 모델(예: Claude로 짰다면 Gemini로 검토)에 넣고 다음과 같이 프롬프트를 준다. > "이 코드는 특정 기능을 위해 작성된 코드입니다. 당신은 매우 깐깐한 시니어 백엔드 엔지니어이자 QA 전문가입니다. 이 코드의 보안 취약점, 엣지 케이스 오류 가능성, 성능 비효율성, 구조적 개선점을 냉정하게 리뷰해 주세요." 이 방식을 쓰면 혼자 일하면서도 아주 훌륭한 코드 리뷰 파트너를 곁에 둔 효과를 얻을 수 있다. #### 원칙 6. 기능의 세부 구현 상태를 매트릭스로 관리한다 \"대시보드 페이지 완성했어요\"라는 한 마디에는 너무 많은 오해의 소지가 있다. 기획자, 디자이너, 개발자로서의 자아를 모두 가진 1인 개발자는 더 명확한 기준이 필요하다. 나는 메모장이나 노션에 기능별로 아래 상태를 세분화해 체크한다. * [ ] **미구현 (Unimplemented)**: 기획만 존재함 * [ ] **UI 레이아웃 완료 (UI Only)**: 화면 모양만 잡음 * [ ] **임시 데이터 연결 (Mock Data)**: 로컬 더미 데이터로 동작 시늉만 냄 * [ ] **백엔드 API 연결 완료 (API Connected)**: API 통신은 됨 * [ ] **DB 영속성 확인 (DB Persisted)**: 실제 DB에 쓰고 읽기가 보장됨 * [ ] **예외/엣지 케이스 테스트 완료 (QA Verified)**: 실패 상황 테스트 통과 * [ ] **운영 환경 검증 완료 (Prod Verified)**: 실서버 배포 후 검증 끝 이 단계를 밟지 않고 눈에 보이는 화면만으로 기능을 완료 처리하면, 나중에 어느 부분이 가짜이고 진짜인지 스스로도 구별하지 못하는 혼란에 직면하게 된다. #### 원칙 7. 코드 수정 전에 기존 맥락을 먼저 이해시킨다 기존 프로젝트의 소스코드를 대뜸 넘겨주며 \"여기에 이거 추가해줘\"라고 하면 AI는 기존 코딩 패턴이나 설계 원칙을 무시하고 ad-hoc(임시변통) 식의 지저분한 코드를 덧붙이기 일쑤다. 수정 요청 전에 기존 구조의 맥락 파악을 먼저 시켜야 한다. > "이 파일의 코드를 수정할 예정입니다. 변경을 요청하기 전에, 먼저 이 파일의 현재 구조와 데이터 흐름, 그리고 구현 방식의 의도를 설명해 주세요. 어떤 함수가 영향을 받을 수 있는지 정리해 주시기 바랍니다." AI가 기존 코드를 정확하게 해석하고 분석 결과를 내놓은 것을 확인한 뒤에야 비로소 \"그렇다면 그 의도와 패턴에 맞게 최소한의 변경으로 기능을 구현해줘\"라고 요청한다. 이 단계 하나만으로도 코드의 일관성이 몰라보게 좋아진다. #### 원칙 8. 빚을 지는 것은 괜찮지만, 숨기지는 않는다 개발을 하다 보면 일정이나 리소스 한계 때문에 어쩔 수 없이 지름길을 택해야 할 때가 있다. 임시 데이터를 하드코딩하거나 보안 검증을 잠시 미뤄두는 식이다. 이때 중요한 것은 그 '부채'를 코드 속에 몰래 묻어두지 않는 것이다. 나는 기술 부채 목록을 프로젝트 루트 폴더에 `tech-debt.md` 파일로 명시해 두고, 임시 방편을 쓸 때마다 즉시 기록한다. ```markdown ## 현재 프로젝트의 기술 부채 목록 * [AttractiveWebAI] 분석 차트에 여전히 임시 Mock Data 사용 중 (실제 배포 전 빅쿼리 API 파이프라인 연동 필수) * [Shopify 멤버십] 신규 회원 가입 혜택 결제 처리 시 할인 검증 웹훅 수신부 누락 (운영 배포 전 보안 체크 필수) * [공통] 사용자 세션 만료 예외 발생 시 로그아웃 처리 미비 * [macOS 유틸리티] 시스템 접근성 권한 획득 확인용 하드코딩된 대기 시간(3초) 존재 -> 이벤트 기반 트리거로 변경 필요 ``` 지저분한 코드를 짰다는 사실보다 무서운 것은 내가 어디에 지저분한 코드를 남겨두었는지 잊어버리는 것이다. 빚의 규모를 눈앞에 보이게 관리하면 다음 개발 주기에 무엇을 먼저 개선해야 할지 선명하게 알 수 있다. --- #### 진짜 완성된 제품을 위하여 AI를 통한 개발은 개발을 '가벼운 행위'로 느끼게 만든다. 프롬프트 창에 질문을 몇 번 던지는 것만으로 수백 줄의 코드가 채워지고 빌드가 완료되는 모습을 보면, 내가 대단히 거대한 제품을 순식간에 통제하고 있다는 착각이 든다. 하지만 진짜 완성도 높은 제품은 작성된 코드의 양이 아니라, 버려진 임시 코드의 양과 확인된 예외 상황의 수로 결정된다. 작동하지 않는 기능을 작동하는 것처럼 둔 껍데기 제품은 첫 사용자가 들어오는 순간 모래성처럼 무너진다. AI는 훌륭한 러닝메이트이자 타이핑 비서다. 그러나 제품의 완료 선을 긋고 품질을 보장하는 최후의 방어선은 여전히 기획하고 검증하는 인간의 몫이다. 화려한 화면 뒤에 가려진 동작 하나, 데이터 한 줄을 매섭게 뜯어보는 집요함이야말로 AI 시대에 1인 메이커가 갖춰야 할 진짜 개발 역량일지도 모른다. --- # PMP 합격 후기 2부: 시험 당일 시간 관리와 마지막 합격 팁 > Pearson VUE 센터에서 PMP 시험을 치른 실제 경험과 첫 60문제 시간 관리, 10분 쉬는 시간, 시험 직전 오답 복습 및 준비물을 정리했다. _Slug: pmp-pass-review-part-2 · 2026-07-05_ [1부](/ko/posts/pmp-pass-review-part-1)에서는 PMP가 어떤 자격증인지, 약 7주 동안 온라인 강의와 PMI Study Hall, 오답노트, GPT와 NotebookLM을 어떻게 활용했는지 정리했습니다. 2부에서는 시험장에 들어간 순간부터 PASS 결과지를 받기까지의 경험을 시간 순서대로 남깁니다. 공부할 때는 알기 어려웠지만, 직접 시험을 치르고 나니 **지식만큼 체력, 시간 관리와 쉬는 시간 운영이 중요하다**는 것을 느꼈습니다. 이 글은 2026년 7월 3일, 개편 전 PMP 시험을 응시한 후기입니다. PMI는 2026년 7월 9일부터 새 시험을 적용했습니다. 현재 시험 구조와 출제 영역은 [PMI 공식 PMP 안내](https://www.pmi.org/certifications/project-management-pmp)에서 확인하세요. ## 시험 당일 한눈에 보기 | 항목 | 나의 경험 | |---|---| | 시험 장소 | Pearson VUE 시험 센터 | | 당시 시험 구성 | 180문항, 230분 | | 세션 구성 | 60문항씩 3개 세션 | | 쉬는 시간 | 세션 사이 10분씩 2회 | | 첫 60문항 소요 시간 | 약 80분 | | 준비한 간식 | 초콜릿바, 호두, 아몬드 | | 최종 결과 | PASS | 시험 구조만 보면 “60문제씩 세 번 풀면 된다”고 생각하기 쉽습니다. 하지만 약 4시간 동안 비슷한 상황형 문제를 계속 읽고 판단하는 일은 생각보다 훨씬 피곤했습니다. ## Pearson VUE 센터에 도착해서 시험은 Pearson VUE 센터에서 봤습니다. 공부할 때 Full Mock도 풀어봤고 어느 정도 준비됐다고 생각했지만, 시험장에 들어가니 느낌이 완전히 달랐습니다. 신분 확인을 하고 개인 물품을 정리한 뒤 시험 자리에 앉는 순간부터 긴장이 올라왔습니다. 화면에 첫 문제가 나타나자 평소보다 문장을 더 오래 읽게 됐고, 쉬운 선택지도 계속 의심하게 됐습니다. 센터별 안내와 반입 규정은 다를 수 있으므로 도착 시간, 신분증, 보관 가능한 물품을 예약 안내 메일에서 미리 확인하는 것이 좋습니다. 특히 영문 이름과 신분증 정보가 예약 정보와 일치하는지도 다시 확인했습니다. ## 실제 시험은 예상보다 어렵게 느껴졌다 개인적으로 실제 시험은 생각보다 어렵게 느껴졌습니다. Study Hall에서 비슷한 형식의 문제를 많이 봤지만, 시험장에서는 긴장감 때문에 선택지 사이의 작은 차이가 더 크게 느껴졌습니다. 한 문제를 풀 때마다 다음과 같은 생각이 반복됐습니다. - 둘 다 맞는 말 같은데 무엇을 먼저 해야 하지? - 이 상황은 분석이 먼저일까, 행동이 먼저일까? - 지금 Escalation할 단계인가? - Agile 상황인가, Predictive 상황인가? - 문제에서 묻는 것이 `FIRST`인가, `NEXT`인가? 완전히 모르는 문제보다 두 개의 선택지 중 하나를 고르는 문제가 더 많은 에너지를 사용했습니다. 모든 문제에 확신을 얻으려고 하면 시간이 빠르게 사라졌습니다. ## 첫 60문제에 80분을 사용했다 첫 세션 60문제를 푸는 데 약 80분이 걸렸습니다. 첫 번째 쉬는 시간에 나왔을 때 “이 속도면 뒤에서 시간이 부족하지 않을까?”라는 생각이 들었습니다. 첫 구간에서 시간이 오래 걸린 이유는 단순했습니다. - 긴장해서 문제를 반복해서 읽었다. - 확실히 고른 답도 다시 검토했다. - 어려운 문제에서 바로 넘어가지 못했다. - 전체 시간보다 현재 문제 하나에 집중했다. 첫 쉬는 시간에는 점수나 어려웠던 문제를 다시 생각하지 않으려고 했습니다. 물을 마시고, 초콜릿바와 견과류를 조금 먹고, 목과 어깨를 스트레칭했습니다. 짧게라도 화면과 문제에서 완전히 떨어지는 것이 도움이 됐습니다. 다시 들어간 뒤에는 전략을 바꿨습니다. > **확실히 아는 문제는 다시 읽지 말고 넘어가자. 어려운 문제 하나가 뒤의 쉬운 문제를 풀 시간을 가져가게 두지 말자.** 이후에는 질문이 `FIRST`, `NEXT`, `BEST` 중 무엇을 요구하는지 먼저 보고, 명백히 맞지 않는 선택지를 제거한 뒤 결정했습니다. 덕분에 마지막 세션에서는 시간이 조금 남았습니다. ## 나에게 맞았던 시간 관리 방법 시험을 다시 준비한다면 문제당 시간을 완벽하게 동일하게 나누지는 않을 것입니다. 대신 60문항 단위로 남은 시간을 확인하고, 한 문제에 오래 머무르는 순간을 줄이겠습니다. ### 1. 질문이 요구하는 행동부터 확인한다 상황 설명을 읽기 전에 마지막 문장에서 프로젝트 매니저가 `가장 먼저`, `다음으로`, 또는 `어떻게` 해야 하는지 확인하면 문제의 초점이 조금 더 잘 보였습니다. ### 2. 명확한 문제는 한 번에 끝낸다 확실한 답을 골랐는데 불안하다는 이유만으로 다시 읽으면 시간이 쌓입니다. 검토가 필요한 문제와 단순히 긴장 때문에 의심하는 문제를 구분하려 했습니다. ### 3. 어려운 문제는 한정된 시간만 사용한다 선택지 두 개가 계속 남는다면 문제의 핵심 단어와 PMI Mindset을 다시 확인한 뒤 결정했습니다. 한 문제에 완벽한 확신을 얻는 것보다 전체 시험을 끝내는 것이 중요했습니다. ### 4. 세션이 끝나기 전에 남은 시간을 본다 문제마다 시계를 보면 집중력이 깨질 수 있습니다. 대신 일정한 간격과 세션 종료 전에 남은 시간을 확인하는 방식이 나에게 더 잘 맞았습니다. ## 10분 쉬는 시간은 직접 확인하세요 Pearson VUE 센터에서 시험을 본다면 쉬는 시간을 직접 확인하는 것을 추천합니다. **10분은 생각보다 정말 빨리 지나갑니다.** 화장실을 다녀오고, 간식을 먹고, 다시 들어갈 때 신분 확인과 보안 절차를 거치면 시간이 금방 지나갑니다. 나는 첫 번째 쉬는 시간에 10분을 조금 넘겼습니다. 센터 문 앞이나 안내받은 위치에서 시계를 확인한 뒤 이동하는 것이 좋습니다. 휴대전화는 사용할 수 없거나 접근이 제한될 수 있으므로 개인 휴대전화로 시간을 확인할 수 있다고 생각하지 않는 편이 안전합니다. 정확한 절차는 반드시 해당 센터의 안내를 따르세요. ### 쉬는 시간에 실제로 한 일 1. 물을 마셨다. 2. 초콜릿바와 견과류를 조금 먹었다. 3. 목, 어깨와 허리를 스트레칭했다. 4. 지나간 문제를 떠올리지 않았다. 5. 남은 시간과 다음 세션 전략만 확인했다. 쉬는 시간에 문제를 복기하면 이미 제출한 세션에 대한 불안만 커질 수 있습니다. 나에게는 머리를 비우고 몸을 움직이는 쪽이 훨씬 효과적이었습니다. ## 시험 직전에 가장 도움이 된 공부 시험 직전에 가장 도움이 된 것은 책을 처음부터 끝까지 다시 읽는 일이 아니었습니다. 내가 틀린 문제를 다시 보면서 **왜 틀렸는지 직접 설명하는 것**이었습니다. 특히 시험 이틀 전부터는 새로운 내용을 더 넣기보다 다음 두 가지를 반복했습니다. ### 1. 기존 오답노트 정답 문장보다 내가 반복한 실수를 봤습니다. - 문제를 끝까지 읽지 않았다. - `FIRST`와 `NEXT`를 구분하지 않았다. - 팀과 대화하기 전에 Escalate했다. - 원인을 찾기 전에 해결책을 선택했다. - 변경의 영향을 분석하기 전에 실행했다. - Predictive와 Agile 상황을 혼동했다. ### 2. PMP Mindset 시험 직전에는 방대한 프로세스 목록보다 판단의 기본 순서를 짧게 복습했습니다. > **상황 파악 → 원인 확인 → 팀과 협업 → 영향 분석 → 절차에 따른 행동** 물론 모든 문제에 동일하게 적용되는 공식은 아닙니다. 하지만 긴장한 상황에서 너무 강한 조치를 성급하게 선택하지 않도록 잡아주는 기준이 됐습니다. ## 시험장에 챙기면 좋았던 것 센터 규정을 먼저 확인한다는 전제에서, 개인적으로 다음 준비가 도움이 됐습니다. - 예약 정보와 일치하는 유효한 신분증 - 초콜릿바처럼 빠르게 먹을 수 있는 간식 - 호두나 아몬드 같은 견과류 - 물 - 체온에 맞춰 조절할 수 있는 편한 옷 - 시험장 위치와 도착 시간 메모 간식을 많이 먹는 것보다 쉬는 시간에 부담 없이 당과 에너지를 조금 보충하는 것이 좋았습니다. 목, 어깨, 허리를 가볍게 풀어주는 것도 다음 세션의 집중력을 회복하는 데 도움이 됐습니다. ## 4시간 모의고사를 꼭 경험해보세요 짧은 문제 세트에서 좋은 점수를 받는 것과 약 4시간 동안 판단을 이어가는 것은 다른 경험이었습니다. Full Mock을 끝까지 풀어보면 지식 외에도 다음을 확인할 수 있습니다. - 어느 세션에서 집중력이 가장 떨어지는가? - 첫 60문제를 너무 천천히 풀고 있지 않은가? - 쉬는 시간 후 다시 집중하는 데 얼마나 걸리는가? - 물과 간식을 어느 정도 먹어야 편한가? - 오래 앉아 있을 때 목과 허리가 괜찮은가? 가능하면 실제 시험과 비슷하게 휴대전화를 멀리 두고, 시간을 재고, 정해진 쉬는 시간만 사용해보는 것을 추천합니다. 시험 당일 처음 경험하는 요소를 하나라도 줄일 수 있습니다. ## Study Hall 점수가 60%대라면 Study Hall 점수가 60% 초중반이면 합격 후기의 높은 점수와 비교하며 불안해질 수 있습니다. 내 Full Mock 점수도 66%와 65%, 전체 평균은 약 62%였습니다. 그 점수로 실제 시험에 합격했지만, 이것을 “60%면 무조건 합격한다”는 기준으로 말하고 싶지는 않습니다. 사람마다 풀어본 문제, 오답 분석 수준, 시험 당일 컨디션이 다르기 때문입니다. 대신 아래 질문을 확인해보면 좋겠습니다. - 틀린 이유를 내 말로 설명할 수 있는가? - 비슷한 상황에서 같은 실수를 반복하지 않는가? - Full Mock을 실제 시간 안에 끝낼 수 있는가? - 답을 외우지 않고 PMI 관점의 판단 순서를 적용할 수 있는가? 점수 하나보다 이 질문에 대한 답이 준비 상태를 더 잘 보여줬습니다. ## AI는 정답지가 아니라 복습 파트너였다 GPT와 NotebookLM은 오답노트 정리, PMP Mindset 복습, 헷갈리는 개념 비교에 도움이 됐습니다. 특히 시험 직전에는 흩어져 있던 내용을 짧은 질문과 요약으로 바꾸는 데 유용했습니다. 하지만 PMP 문제를 그대로 입력하고 AI가 고른 선택지만 확인하는 방식은 추천하지 않습니다. 선택지 사이의 미묘한 차이를 AI가 잘못 해석할 수 있고, 그럴듯한 설명으로 틀린 답을 확신 있게 제시할 수도 있습니다. AI를 사용할 때도 다음 과정은 직접 해야 합니다. 1. 내가 왜 그 답을 골랐는지 먼저 적는다. 2. 공식 해설과 출처를 확인한다. 3. AI에는 정답보다 사고 과정의 빈틈을 질문한다. 4. 설명이 다르면 공식 자료를 기준으로 다시 검증한다. 5. 마지막에는 내 언어로 한 줄 원칙을 남긴다. ## 결과지를 받았을 때 시험이 끝나고 PASS 결과를 확인했을 때 가장 먼저 든 감정은 안도감이었습니다. 준비하는 동안 낮은 점수와 어려운 문제를 볼 때마다 흔들렸지만, 결국 그 오답들이 시험장에서 한 번 더 생각하게 해준 자료가 됐습니다. 영역별 결과는 People이 Below Target, Process가 Target, Business Environment가 Above Target이었습니다. 한 영역이 Below Target이었지만 전체 결과는 PASS였습니다. 다만 이것은 나의 개인 결과일 뿐이며, 영역별 등급을 이용해 PMI의 합격 기준을 단순하게 계산할 수 있다는 의미는 아닙니다. ## 마지막으로 전하고 싶은 말 오답이 나왔다고 “나는 안 되나?”라고 생각하기보다, “이 문제는 실제 시험에서 맞힐 확률이 높아진 문제”라고 받아들이면 좋겠습니다. 시험 전에 틀려서 다행인 문제도 분명히 있습니다. 중요한 것은 점수 자체보다, 오답을 통해 **내가 어떤 방식으로 잘못 판단하는지 알아내는 것**이었습니다. 시험을 준비하고 있다면 새로운 자료를 계속 추가하기보다 이미 공부한 내용을 자신의 판단 기준으로 만드는 데 시간을 써보세요. 그리고 시험 전에는 약 4시간을 실제로 앉아보세요. 지식, 체력, 시간 관리가 함께 준비됐을 때 훨씬 안정적으로 문제를 풀 수 있습니다. 지금 준비하고 계신 모든 분을 응원합니다. 화이팅입니다! 💪🍀 **처음부터 읽기:** [PMP 합격 후기 1부: 7주 준비와 Study Hall 60%대에서 PASS까지](/ko/posts/pmp-pass-review-part-1) --- # PMP 합격 후기 1부: 7주 준비와 Study Hall 60%대에서 PASS까지 > 2026년 7월 3일 PMP 시험에 합격하기까지 7주 동안 온라인 강의, PMI Study Hall, 오답노트, GPT와 NotebookLM을 활용한 공부 과정을 정리했다. _Slug: pmp-pass-review-part-1 · 2026-07-03_ 안녕하세요. **2026년 7월 3일 금요일, PMP 시험을 보고 최종 PASS를 받았습니다.** 시험을 준비하는 동안 국내 PMP 커뮤니티의 합격 후기와 [Reddit r/PMP](https://www.reddit.com/r/pmp/) 글을 거의 매일 읽었습니다. Study Hall 점수가 비슷한 사람은 붙었는지, 실제 시험은 얼마나 어려웠는지, 시험 당일에는 무엇을 준비해야 하는지 찾아보며 도움을 많이 받았습니다. 늘 다른 사람의 합격 후기만 읽다가 이렇게 직접 후기를 쓰게 되니 기분이 묘하면서도 정말 좋습니다. 이 글도 지금 점수 때문에 불안하거나 공부 방향을 잡지 못한 분에게 작은 참고가 되었으면 합니다. 이 글은 2026년 7월 3일, 시험 개편 전에 응시한 경험을 기준으로 합니다. PMI는 2026년 7월 9일부터 AI, 지속가능성, 가치 전달 등을 강화한 새 PMP 시험을 적용했습니다. 현재 시험의 시간, 영역별 비중과 출제 기준은 반드시 [PMI 공식 PMP 안내](https://www.pmi.org/certifications/project-management-pmp)와 [2026 시험 개편 안내](https://www.pmi.org/certifications/project-management-pmp/new-exam)에서 다시 확인하세요. 2026년 7월 3일 PMP 시험 합격 결과와 영역별 성적이 표시된 결과지 *시험 직후 Pearson VUE 센터에서 받은 결과지. 전체 결과는 PASS였고, 영역별 결과는 People Below Target, Process Target, Business Environment Above Target이었다.* ## PMP 자격증이란? PMP(Project Management Professional)는 PMI(Project Management Institute)가 운영하는 프로젝트 관리 전문 자격증입니다. 특정 산업이나 하나의 방법론에만 한정되지 않고, 프로젝트를 이끌면서 **사람, 프로세스, 비즈니스 우선순위**를 관리할 수 있는지를 평가합니다. 단순히 PMBOK 내용을 얼마나 외웠는지를 확인하는 시험과는 거리가 있습니다. 실제 문제의 대부분은 프로젝트에서 발생할 법한 상황을 제시하고, 그 상황에서 프로젝트 매니저가 **가장 먼저 무엇을 해야 하는지**, 또는 **다음으로 어떤 행동을 해야 하는지** 판단하게 합니다. 그래서 용어와 프로세스를 이해하는 것도 중요하지만, 문제를 바라보는 순서와 PMI가 기대하는 프로젝트 매니저의 태도를 익히는 것이 더 중요했습니다. 응시 자격에는 학력에 따른 프로젝트 리딩 경험과 프로젝트 관리 교육 요건 등이 포함됩니다. 이 기준도 변경될 수 있으므로 본인의 조건은 [PMI 공식 자격 요건](https://www.pmi.org/certifications/project-management-pmp)에서 직접 확인하는 것이 가장 정확합니다. ## 나의 PMP 준비 결과 요약 | 항목 | 내용 | |---|---| | 시험일 | 2026년 7월 3일 금요일 | | 준비 기간 | 약 7주 | | 시험 장소 | Pearson VUE 시험 센터 | | 주요 학습 자료 | 온라인 강의, PMI Study Hall, 오답노트 | | Study Hall Full Mock 1 | 66% | | Study Hall Full Mock 2 | 65% | | Study Hall 전체 평균 | 약 62% | | 보조 도구 | GPT, NotebookLM | | 최종 결과 | PASS | 결과지만 보면 준비 과정이 계획대로 흘러간 것처럼 보이지만, 실제로는 Study Hall 점수를 확인할 때마다 불안했습니다. 고득점 합격 후기를 볼수록 “이 점수로 시험을 신청해도 될까?”라는 생각이 커졌습니다. 지나고 나서 보니 점수 자체보다 중요한 것은 **어떤 사고방식 때문에 반복해서 틀리는지 찾아내는 일**이었습니다. ## 왜 7주 만에 기존 시험으로 응시했나 처음에는 PMP 시험이 바뀌는 시점을 고려해 PMBOK 8판 기반 교재로 공부를 시작했습니다. 새로운 시험을 기준으로 여유 있게 준비할 생각이었습니다. 그런데 막상 공부를 시작하니 온라인 강의를 예상보다 빠르게 수강했고, 시험 개편 전에 응시할 수 있는 일정도 남아 있었습니다. 이미 공부한 핵심 원칙은 기존 시험에도 연결되었기 때문에 준비 기간을 길게 늘이기보다, 현재 시험에 맞춰 집중해서 응시하기로 결정했습니다. 이 선택에서 중요했던 것은 최신 책을 봤다는 사실보다 **내가 응시할 시험의 Exam Content Outline과 문제 유형을 다시 맞춰본 것**이었습니다. PMP를 준비한다면 교재의 판수만 보고 결정하기보다, 자신의 시험일에 적용되는 공식 출제 기준을 먼저 확인하는 것이 좋습니다. ## 7주 동안 공부한 방법 나의 공부 과정은 크게 네 단계로 나뉘었습니다. ### 1단계: 온라인 강의로 전체 구조 이해하기 처음부터 PMBOK의 모든 내용을 세세하게 외우려고 하지 않았습니다. 온라인 강의를 들으며 Predictive, Agile, Hybrid 접근 방식이 어떻게 다른지, 프로젝트 매니저가 각 상황에서 어떤 역할을 해야 하는지 큰 흐름부터 잡았습니다. 평일에는 퇴근 후 조금이라도 강의를 들었습니다. 체력이 남는 날에는 여러 강의를 이어서 듣고, 힘든 날에는 짧은 구간이라도 끝냈습니다. 주말에는 평일에 들었던 내용을 복습하거나 문제를 풀었습니다. 나는 원래 퇴근 후에도 오랫동안 집중해서 공부하는 스타일이 아닙니다. 그래서 하루 공부량을 완벽하게 지키는 것보다 **공부를 완전히 끊는 날을 줄이는 것**에 더 집중했습니다. ### 2단계: Study Hall로 실제 판단 방식 익히기 기본 강의를 들은 뒤 가장 많이 활용한 것은 PMI Study Hall이었습니다. 문제를 풀면 내가 개념을 모르는지, 질문을 잘못 읽었는지, 너무 빨리 Escalation을 선택하는지 바로 드러났습니다. 처음에는 문제를 맞힌 개수만 봤습니다. 점수가 낮으면 공부가 부족하다고 생각했고, 높은 점수를 받은 사람의 후기를 찾으며 더 불안해졌습니다. 하지만 문제를 반복해서 풀다 보니 같은 점수라도 그 안에 담긴 정보가 다르다는 것을 알게 됐습니다. - 개념 자체를 몰라서 틀린 문제 - `FIRST`, `NEXT`, `BEST` 같은 질문의 의도를 놓친 문제 - 문제에 없는 상황을 임의로 가정한 문제 - 바로 Sponsor나 상위 조직에 넘긴 문제 - 팀과 대화하기 전에 사람을 교체하려 한 문제 - 변경의 영향을 분석하기 전에 실행한 문제 이렇게 틀린 이유를 분류하자 점수가 단순한 평가가 아니라 다음 공부 방향을 알려주는 자료가 되었습니다. ### 3단계: Full Mock으로 약 4시간을 경험하기 Study Hall의 Full Mock 1은 66%, Full Mock 2는 65%, 전체 평균은 약 62%였습니다. 솔직히 말하면 안심되는 점수는 아니었습니다. 그래도 Full Mock의 가장 큰 목적을 합격 가능성 예측에만 두지 않았습니다. 긴 시간 동안 집중력을 유지할 수 있는지, 어느 구간에서 속도가 느려지는지, 쉬는 시간 후 다시 문제에 몰입할 수 있는지를 확인했습니다. PMP 시험은 지식뿐 아니라 체력과 시간 관리도 함께 시험합니다. 짧은 문제 세트만 풀다가 시험장에 가면 실제 시험의 피로도를 처음 경험하게 됩니다. 가능하면 시험 전에 한 번은 시간을 재고 Full Mock을 처음부터 끝까지 풀어보는 것을 권합니다. ### 4단계: 새 문제보다 오답노트에 집중하기 시험이 가까워졌을 때는 새로운 문제를 많이 추가하지 않았습니다. 이미 틀린 문제를 다시 보며 아래 질문에 답하려고 했습니다. > “나는 왜 이 선택지를 골랐을까?” > “다른 선택지보다 이 답이 PMI 관점에서 더 적절한 이유는 무엇일까?” 정답 문장을 외우면 비슷한 상황에 단어가 조금만 바뀌어도 다시 틀렸습니다. 반면 내 판단 과정을 설명할 수 있으면 새로운 문제에도 같은 원칙을 적용할 수 있었습니다. ## 시험에서 도움이 된 PMP Mindset PMP Mindset을 무조건 적용되는 암기 공식으로 받아들이지는 않았습니다. 윤리, 법규, 안전, 긴급한 위험처럼 즉시 조치가 필요한 예외도 있기 때문입니다. 다만 일반적인 갈등이나 변경 상황에서는 다음 순서가 판단에 도움이 됐습니다. 1. **행동하기 전에 상황과 원인을 먼저 파악한다.** 2. **팀 내부에서 해결할 수 있는 문제는 먼저 팀과 대화한다.** 3. **바로 Escalate하거나 Sponsor에게 넘기지 않는다.** 4. **사람을 교체하기 전에 코칭, 협업과 갈등 해결을 시도한다.** 5. **문제의 증상보다 Root Cause를 찾는다.** 6. **변경 요청은 영향을 분석한 뒤 공식 절차에 따라 처리한다.** 7. **프로젝트 매니저는 팀을 통제하기보다 지원하고 장애물을 제거한다.** 실제 문제에서는 여러 선택지가 모두 그럴듯했습니다. 이때 “지금 당장 가장 강한 조치를 하는 답”보다 “상황을 이해하고 팀이 해결하도록 돕는 답”이 더 적절한 경우가 많았습니다. ## 온라인 강의는 충분했나 개인적으로 온라인 강의에 만족했습니다. 시험에 필요한 큰 흐름과 Mindset을 잡는 데 충분한 도움이 됐습니다. 처음에는 오프라인 고가 강의까지 들어야 하나 고민했습니다. 하지만 내 경우에는 온라인 강의로 기본 구조를 익힌 뒤, Study Hall 문제를 풀고 오답을 분석하는 조합이 잘 맞았습니다. 어떤 강의를 선택하느냐도 중요하지만, 강의를 들은 다음 **문제를 풀고, 틀리고, 판단 과정을 다시 정리하는 시간**이 더 중요하다고 느꼈습니다. 강의를 완주했다는 사실만으로는 시험 상황에서 선택지를 고를 수 없었습니다. ## GPT와 NotebookLM을 활용한 방법 PMP 준비 과정에서 GPT와 NotebookLM도 많이 활용했습니다. AI가 정답을 대신 골라주는 도구라기보다, 내가 이해한 내용을 다시 설명하고 비교하는 복습 파트너로 사용했습니다. ### GPT 활용법 - 헷갈리는 개념 두 개의 차이를 표로 비교하기 - 내가 선택한 답의 사고 과정을 설명하고 빠진 전제를 질문받기 - 오답 원인을 개념 부족, 문제 해석, Mindset 오류로 분류하기 - 복잡한 개념을 실제 프로젝트 사례로 다시 설명받기 - 정리한 내용을 바탕으로 짧은 복습 질문 만들기 예를 들어 정답만 알려달라고 하기보다 다음처럼 질문했습니다. ```text 나는 이 상황에서 바로 Sponsor에게 보고해야 한다고 판단했다. 내 판단에 숨어 있는 가정을 찾아주고, PMI 관점에서 먼저 확인해야 할 행동을 질문 형태로 알려줘. 정답을 바로 말하지 말고 내가 다시 판단할 수 있게 도와줘. ``` ### NotebookLM 활용법 NotebookLM에는 내가 정리한 오답노트와 복습 자료를 모아두고, 자료 안에서 반복되는 주제를 다시 찾는 용도로 활용했습니다. - 자주 틀리는 Mindset만 모아 요약하기 - Agile과 Predictive 상황을 나눠 복습하기 - 변경 관리, 갈등 관리처럼 헷갈리는 주제 비교하기 - 시험 직전 확인할 짧은 복습 목록 만들기 여러 자료가 섞이면 무엇을 기준으로 답했는지 확인하기 어려워집니다. 그래서 출처가 분명한 공식 자료와 내가 직접 검토한 노트를 중심으로 사용했습니다. Study Hall 문제를 AI에 그대로 넣고, AI가 선택한 답만 보고 오답을 확인하는 방식은 추천하지 않습니다. PMP 문제는 선택지 사이의 미묘한 차이와 상황의 맥락이 중요합니다. AI의 설명도 틀릴 수 있으므로 공식 자료와 해설을 기준으로 직접 검증해야 합니다. ## Study Hall 60%대 점수에서 배운 것 내 점수는 Full Mock 66%, 65%, 전체 평균 약 62%였습니다. 이 점수만 보면 시험을 미루고 싶어질 수 있습니다. 나 역시 그랬습니다. 하지만 결과적으로 점수보다 더 중요했던 것은 아래 세 가지였습니다. - 같은 이유로 틀리는 문제의 수가 줄고 있는가? - 정답을 외우지 않고 판단 과정을 설명할 수 있는가? - 실제 시험 시간 동안 집중력을 유지할 수 있는가? 물론 나의 점수가 모든 사람의 합격 기준이 될 수는 없습니다. Study Hall 점수와 실제 시험 결과는 사람마다 다릅니다. 다만 60% 초중반이라는 숫자 하나만으로 준비 전체를 부정할 필요는 없다고 말하고 싶습니다. 오답은 “나는 아직 준비되지 않았다”는 판정이 아니라, **실제 시험 전에 한 번 더 맞힐 가능성을 만든 문제**였습니다. ## 1부를 마치며 7주 동안 가장 크게 달라진 것은 외운 지식의 양보다 문제를 바라보는 순서였습니다. 바로 행동하기 전에 상황을 확인하고, 사람을 바꾸기 전에 대화하고, 변경하기 전에 영향을 분석하는 방식이 조금씩 익숙해졌습니다. 다음 글에서는 Pearson VUE 시험장에 들어간 순간부터 첫 60문제에 80분을 사용해 멘탈이 흔들렸던 경험, 10분 쉬는 시간, 간식과 스트레칭, 마지막 세션의 시간 관리까지 정리했습니다. **계속 읽기:** [PMP 합격 후기 2부: 시험 당일 시간 관리와 마지막 합격 팁](/ko/posts/pmp-pass-review-part-2) --- # 삶을 기록하는 나만의 방식 > 일과 프로젝트, 여행과 음식, 그때의 생각까지 기록합니다. 이 블로그는 지나온 경험과 시행착오를 정리하고, 다음 선택을 조금 더 나아지게 만들기 위한 개인 작업 노트입니다. _Slug: built-slowly-updated-daily · Sat Feb 07_ 삶을 기록하는 나만의 방식 저는 프로젝트 매니저로 일하고 있습니다. 일정을 정리하고, 문제를 발견하고, 여러 사람의 의견을 조율하면서 하나의 결과를 만들어가는 일을 합니다. 그래서인지 일상에서도 비슷한 방식으로 생각할 때가 많습니다. 무엇을 하고 싶은지 정리하고, 우선 실행해봅니다. 결과가 기대와 다르면 그 이유를 돌아보고, 다음에는 무엇을 바꿀지 생각합니다. 계획대로 진행되지 않는 날도 많지만, 그 과정에서 조금씩 저만의 기준을 만들어가고 있습니다. 이 블로그는 그런 경험을 기록하기 위해 시작했습니다. 업무를 하며 배운 것, 프로젝트를 진행하며 겪은 시행착오, 새로운 서비스를 만들면서 고민한 내용을 남깁니다. 여행 중 발견한 장소와 인상 깊었던 음식, 그날 떠올랐던 생각처럼 조금 더 개인적인 이야기도 함께 기록합니다. 각각의 주제는 서로 달라 보이지만, 결국 모두 제가 직접 경험한 일들입니다. 잘 정리된 성공 사례만 남기고 싶지는 않습니다. 계획이 틀어진 이유, 생각보다 어려웠던 부분, 당시에는 최선이라고 생각했지만 나중에 돌아보니 아쉬웠던 선택도 솔직하게 기록하려고 합니다. 기록을 남기면 경험이 단순히 지나간 일로 끝나지 않습니다. 어떤 상황에서 어떤 결정을 내렸는지 다시 돌아볼 수 있고, 비슷한 문제를 만났을 때 조금 더 나은 판단을 내리는 데 도움이 됩니다. 시간이 지나 생각이 달라졌다면, 그 변화 역시 하나의 기록이 됩니다. 장기적으로는 제가 직접 만든 회사를 운영하고, 그 회사를 100만 달러 이상의 가치를 가진 사업으로 성장시키는 것을 목표로 하고 있습니다. 아직은 시작 단계이며, 구체화해야 할 부분도 많습니다. 그래서 완성된 결과만 보여주기보다 목표를 향해 가는 과정 자체를 남기려고 합니다. 무엇을 시도했고, 어떤 문제가 있었으며, 그다음에는 무엇을 바꾸었는지를 꾸준히 기록할 계획입니다. 이 블로그는 대단한 성공담을 보여주기 위한 공간은 아닙니다. 일과 삶에서 경험한 것들을 잊지 않기 위한 개인적인 작업 노트에 가깝습니다. 시간이 지난 뒤 다시 읽었을 때, 당시의 고민과 선택을 이해할 수 있는 기록이면 충분합니다. 완벽하게 준비한 뒤 시작하기보다, 지금부터 하나씩 기록해보려고 합니다. --- # 멕시코 여행기 02 — 밴쿠버에서 잠시 멈추고, 마침내 멕시코시티 > 밴쿠버 국제공항에서의 환승과 메이플리프 라운지, 에어캐나다 비즈니스석을 거쳐 멕시코시티에 도착하기까지. 긴 여행의 첫날을 마무리한 기록. _Slug: mexico-travel-diary-02-vancouver-to-mexico-city · 2025-10-01_
밴쿠버 국제공항 에어캐나다 메이플리프 라운지 입구
멕시코로 향하기 전, 밴쿠버에서 잠시 멈춘 시간.
## 환승지에서의 멈춤 밴쿠버 국제공항에 내려 비행기 밖으로 나오자, 서늘한 캐나다의 공기가 장거리 비행으로 무거워진 몸을 깨웠다. 하지만 여정은 끝난 것이 아니었다. 멕시코시티로 향하는 다음 비행기까지 몇 시간의 대기 시간이 남아 있었다. 환승은 단순히 목적지로 가기 위해 거치는 공백의 시간이 아니다. 그것은 한 나라에서 다른 나라로 나의 마음이 서서히 이동하는 유예의 시간이다. 길었던 첫 번째 비행의 피로를 풀어내고, 마침내 도달하게 될 멕시코라는 낯선 땅을 맞이하기 위해 몸과 마음의 조율을 다시 해야 할 때였다. --- ## 밴쿠버 환승 정보 ``` [인천국제공항 (ICN)] ──> [밴쿠버 국제공항 (YVR)] ── (현재 위치) ──> [멕시코시티 국제공항 (MEX)] ``` ### 📍 환승지 위치 정보 * **장소**: 밴쿠버 국제공항 (Vancouver International Airport, YVR) * **역할**: 환승 공항 (Transit Airport) * **좌표**: `49.193333, -123.175659` * **지도**: [밴쿠버 국제공항 지도 보기](https://www.google.com/maps/search/?api=1&query=49.193333%2C-123.175659) --- ## 메이플리프 라운지에서의 휴식 장시간 좁은 기내에 머문 탓에 몸은 많이 지쳐 있었다. 환승 대기 시간 동안 에어캐나다 메이플리프 라운지로 향했다. 공항의 분주한 소음에서 벗어나 차분하게 쉴 수 있는 공간이 필요했다.
메이플리프 라운지에 준비된 신선한 샐러드와 붉은색 음료
대기 시간 동안 라운지에서 즐긴 가벼운 음식. 긴 비행 직후라 소화에 부담 없는 샐러드를 선택했다.
라운지 한쪽에 자리를 잡고 가벼운 요깃거리를 챙겨왔다. 신선한 샐러드와 시원한 붉은색 음료로 건조했던 입안을 적셨다. 맛있는 음식을 풍족하게 즐기기 위함이라기보다는, 지친 체력을 조절하기 위한 가벼운 섭취였다. 라운지 밖 공항의 빠른 흐름과 대비되는 이 차분한 공간에서 조용히 숨을 고를 수 있었다.
비교적 한산하고 쾌적하게 꾸며진 메이플리프 라운지 내부 좌석 공간
라운지 내부의 여유로운 모습. 소파에 앉아 짐을 내려놓고 마음을 편안히 가다듬었다.
비행기를 타는 것만으로도 몸에 힘이 잔뜩 들어갔었는지, 푹신한 소파에 기대어 앉으니 긴장이 풀려왔다. 캐나다라는 나라의 흙을 직접 밟지는 못하고 공항 한편의 라운지에 머물러 있을 뿐이지만, 일상과 완전히 차단된 이 비일상의 감각은 여행의 기분을 조금씩 부풀려 주었다. --- ## 멕시코시티를 향한 마지막 비행 어느덧 환승 시간이 지나고 멕시코시티행 비행기에 탑승할 시간이 되었다. 이번 여정의 마지막 장거리 구간이다.
에어캐나다 비즈니스 클래스 창가 좌석 테이블 위에 놓인 음료, 견과류, 태블릿 그리고 창밖 풍경
마지막 비행의 좌석. 웰컴 드링크와 견과류를 곁들이며 창밖을 마주했다.
다행히 이번 비행은 비즈니스 클래스 창가 좌석이어서 개인 공간이 충분히 보장되었다. 자리에 앉아 겉옷을 정리하고 테이블에 태블릿과 웰컴 드링크, 견과류를 올려두었다. 비로소 몸을 편안히 누일 수 있다는 안도감이 밀려왔다. 이 비행기가 다음에 바퀴를 내릴 곳이 마침내 내가 그렇게 그리던 멕시코라는 사실이 마음속에 천천히 내려앉았다. --- ## 구름 위에서의 저녁 식사 비행기가 안정을 찾고 순항을 시작하자 어김없이 식사가 나왔다. 이번에는 비행의 방향이 남쪽으로, 멕시코로 향하고 있음을 알려주듯 식탁보가 곱게 깔린 식사가 준비되었다.
하얀 접시에 담겨 나온 닭고기 구이, 밥, 더운 채소와 샐러드, 식전빵, 디저트 기내식 세트
멕시코로 향하는 길에 제공된 저녁 기내식. 닭고기와 더운 채소, 밥이 함께 조화를 이루었다.
메인으로 나온 닭고기 요리와 따뜻한 밥, 신선한 야채 샐러드와 빵, 그리고 달콤한 디저트를 천천히 비워나갔다. 공항을 떠나 상공에서 먹는 두 번째 저녁 식사는 조금 더 차분하고 안락했다. --- ## 캐나다의 하늘을 지나며 하늘길은 보이지 않는 지도와 같아서, 창밖을 보면 내가 어디쯤 지나고 있는지 짐작하기 어려울 때가 많다.
기내 창문 밖으로 내려다보이는 끝없는 하늘과 구름의 흐름
비행기 창 너머로 바라본 끝없는 구름과 하늘.
창문 너머로 구름의 바다가 끝없이 이어졌다. 대양과 국경을 가로지르는 동안 눈앞에 펼쳐진 푸른빛과 구름만이 변함없는 이정표가 되어주었다. 지평선을 따라 흘러가는 구름을 바라보며 사색에 잠겼다. 밴쿠버에서 멕시코시티로 향하는 비행 노선은 서서히 대륙의 척추를 따라 남쪽으로 길게 뻗어가고 있었다. --- ## 피로와 마주하는 방식 인천에서 출발한 이후 꽤 오랜 시간이 흐르다 보니 아무리 좌석이 편안해도 머리가 무겁고 눈이 피로해지는 것은 피할 수 없었다. 기내에서 제공하는 피로 관리 음료를 선택했다.
에어캐나다 기내에서 마신 비타민 건강 지향성 캔음료
비행이 길어지며 누적된 피로를 달래기 위해 선택한 가벼운 건강 보충용 비타민 음료.
어떤 약품처럼 몸의 피로를 즉시 지워주는 드라마틱한 변화를 기대한 것은 아니었다. 다만 몸의 긴장을 풀어주고 건조해진 목을 달래기 위한 가볍고 상쾌한 선택이었다. 차가운 음료가 목을 타고 넘어가자 멍했던 머리가 조금은 맑아지는 듯한 기분이 들었다. --- ## 기내에서 만난 클라마토의 호기심 음료 목록을 살펴보던 중 흥미로운 캐나다 전통 음료를 발견했다. '클라마토(Clamato)'라는 독특한 이름을 가진 음료였다.
플라스틱 컵에 담긴 붉은색 클라마토 음료와 얼음
캐나다의 음료 문화가 담긴 클라마토. 토마토 주스와 조개 육수의 독특한 풍미가 섞여 있다.
클라마토는 토마토 베이스의 맛에 조개 즙(Clam Broth)과 다양한 향신료를 첨가해 만들어낸 캐나다의 개성 강한 음료다. 캐나다에서는 이 음료를 베이스로 보드카 등을 섞어 해장용 혹은 브런치 칵테일인 '시저(Caesar)'를 즐겨 마신다고 한다. 비행기 안에서 맛본 클라마토는 생소하고 짭조름한 조개의 감칠맛과 토마토의 신맛이 어우러져 꽤 묘한 인상을 남겼다. 과학적으로 숙취가 해소되는 것은 아니겠지만, 현지 문화를 이색적인 맛으로 경험해 볼 수 있는 재미있는 한 모금이었다. --- ## 이동의 찰나
여정 도중에 카메라에 담긴 차분한 길 위의 기록
캐나다에서 멕시코로 이동하는 여정 중 남긴 한 장면.
--- ## 멕시코시티 도착 드디어 비행기가 고도를 낮추고 멕시코시티 국제공항에 바퀴를 내렸다. 비행기 문을 열고 밖으로 걸어 나왔을 때, 훅 끼쳐오는 낯선 향기와 스페인어로 가득 찬 표지판들이 비로소 멕시코에 닿았음을 실감 나게 했다. ### 📍 도착지 위치 정보 * **장소**: 멕시코시티 국제공항 (Aeropuerto Internacional Benito Juárez / MEX) * **역할**: 도착 공항 (Arrival Airport) * **좌표**: `19.4363003, -99.0720978` * **지도**: [멕시코시티 국제공항 지도 보기](https://www.google.com/maps/search/?api=1&query=19.4363003%2C-99.0720978) 장거리 이동의 마침표를 찍으며 여권을 챙겼다. 입국 수속을 무사히 마치고 공항의 무거운 공기를 뚫고 택시 승차장으로 걸어 나갔다. --- ## 택시 창밖으로 본 첫 도시의 조각 공항에서 우릴 태운 공식 택시는 멕시코시티의 도심 속을 부지런히 질주하기 시작했다. 창밖으로 밀려드는 풍경은 내가 알던 아시아나 북미의 느낌과는 완전히 다른 층위를 갖고 있었다.
택시 조수석 유리창 너머로 보이는 멕시코시티 도심의 기념비적 조각
공항에서 숙소로 향하는 도중 마주한 멕시코시티의 도심 풍경.
택시 창문 밖으로 우뚝 솟은 동상과 유적을 스쳐 지나갔다. Cuauhtémoc(콰우테목)은 테노치티틀란의 마지막 아즈텍 통치자로 알려져 있다. 공항에서 숙소로 향하는 길에 그의 이름과 이미지를 마주하면서, 멕시코시티가 가진 역사적 층위를 처음 실감했다. 흘러가는 차창 밖으로 마주한 멕시코시티의 첫 얼굴은 무척이나 낯설고 단단했다. --- ## 드디어 짐을 내려놓다 오랜 시간 끝에 비로소 오늘 묵게 될 숙소인 Pandora Hotel에 다다랐다.
아늑하고 현대적으로 꾸며진 판도라 호텔의 로비 혹은 실내 공간
마침내 도착한 판도라 호텔 내부. 길었던 이동이 비로소 마침표를 찍는 안도감을 느꼈다.
객실 안으로 무거운 여행 가방을 끌고 들어와 바닥에 내려놓았다. 침대에 가볍게 털썩 주저앉아 주위를 천천히 돌아보는 이 순간이야말로, 긴 여정 속에서 가장 원했던 마침표였을지 모른다. 오늘 하루 쌓인 피로를 씻어내기 위해 가방을 정리했다. ### 🏠 숙소 상세 정보 (Pandora Hotel) * **주소**: Nápoles 35, Juárez, 06600 Ciudad de México, CDMX, Mexico * **다른 명칭**: Pandora House, Pandora Luxury Suites Reforma by VH * **확인 링크**: * [Google Maps에서 위치 보기](https://www.google.com/maps/search/?api=1&query=Pandora+Hotel%2C+N%C3%A1poles+35%2C+Ju%C3%A1rez%2C+06600+Ciudad+de+M%C3%A9xico%2C+CDMX%2C+Mexico) * [Agoda에서 숙소 보기](https://www.agoda.com/pandora-luxury-suites-reforma-by-vh/hotel/mexico-city-mx.html) > 💡 숙소 정보와 요금은 시점에 따라 달라질 수 있으므로 예약 페이지에서 최신 내용을 확인해야 한다. --- ## 익숙함과의 뜻밖의 재회 방에서 대충 짐을 정리하고 필요한 생필품을 사러 호텔 밖으로 나왔다. 멀리 나갈 체력이 없어 호텔 바로 옆 상점으로 들어섰을 때, 예상치 못한 장면에 웃음이 터져 나왔다.
한글 안내판과 한식 컵라면, 한국 과자가 진열되어 있는 한국 편의점 분위기의 외경 매장
숙소 바로 옆에 자리 잡은 한국 식품 전문 매장의 모습.
하루 종일 한국에서 멀어지고 있다고 생각했는데, 숙소 바로 옆에서 다시 한식을 만났다. 진열대 가득 채워져 있는 한국어 포장지와 라면 상자들을 보며 문득 묘한 동질감을 느꼈다. 낯선 멕시코시티의 한복판에서 첫날 마주한 한식은, 먼 이동 끝에 쌓인 피로 속에서 작은 안도감과 웃음을 안겨 주었다. --- ## 첫날을 보내며 인천에서 캐나다로, 다시 멕시코로 이어지는 24시간이 넘는 이동 끝에 결국 안늑한 내 방에 짐을 풀었다. 목적지에 마침내 도달했다는 깨달음은 거창한 풍경을 마주한 순간보다, 무거운 배낭을 바닥에 턱 하고 내려두고 주변을 천천히 돌아보는 바로 이 소박한 순간에 더 선명하고 고요하게 찾아온다. 내일부터 시작될 진짜 멕시코의 시간들을 기다리며, 길었던 하루의 조각들을 기분 좋은 안도감으로 덮는다. --- * [이전 이야기: 멕시코 여행기 01 — 인천에서 밴쿠버까지, 긴 여정의 시작](/ko/posts/mexico-travel-diary-01-incheon-to-vancouver) * 다음 여행기는 곧 이어집니다. --- # 멕시코 여행기 01 — 인천에서 밴쿠버까지, 긴 여정의 시작 > 2025년 10월 1일, 멕시코로 향하는 긴 여정이 인천국제공항에서 시작됐다. 에어캐나다를 타고 태평양을 건너 밴쿠버에 도착하기까지의 첫 번째 기록. _Slug: mexico-travel-diary-01-incheon-to-vancouver · 2025-10-01_ **개인정보 보호 안내:** 본문에 사용된 탑승권 및 여권 이미지(IMG_6600)는 개인정보 유출을 방지하기 위해 마스킹 및 비식별화 처리가 완료된 대체 이미지로 안전하게 렌더링되었습니다.
인천국제공항에서 출발을 기다리며 손에 든 여권과 에어캐나다 탑승권
2025년 10월 1일, 여권과 탑승권을 손에 들며 멕시코 여행이 시작됐다.
## 여행의 시작, 그리고 현실감 오랫동안 계획했던 여행이었지만, 매일 똑같이 반복되던 일상의 흔적은 공항철도에 몸을 싣는 순간까지도 쉽게 지워지지 않았다. 인천국제공항에 도착해 출국 수속을 마치고 탑승 게이트 앞에 서서 여권과 비행기 탑승권을 손에 쥐었을 때야 비로소 실감이 났다. 익숙한 서울의 일상에서 벗어나 낯선 시간 och 언어 속으로 들어가는 순간이었다. 가야 할 목적지인 멕시코시티는 아직 아득하게 멀리 있었다. 태평양을 건너 캐나다 밴쿠버에서 한 번 환승해야 하고, 그 후 다시 남쪽으로 날아가야 닿을 수 있는 거리였다. 비행기를 두 번 타야 하는 긴 여정을 앞두고, 설렘과 동시에 찾아올 장거리 비행의 피로감이 조용히 밀려왔다. 그러나 여행은 목적지에 도착했을 때가 아니라, 익숙한 일상을 떠나는 이 순간부터 시작되는 법이다. --- ## 여정 경로 (Route Overview) 이번 여정은 한국에서 출발하여 캐나다를 거쳐 멕시코로 이어지는 긴 하늘길이다. 첫 번째 장에서는 인천에서 출발하여 첫 번째 기착지인 밴쿠버 국제공항에 도착하기까지의 과정을 다룬다. ``` [인천국제공항 (ICN)] ── (비행 1) ──> [밴쿠버 국제공항 (YVR)] ── (비행 2) ──> [멕시코시티 국제공항 (MEX)] *이번 글의 범위* ``` ### 📍 여정 위치 정보 | 항목 | 인천국제공항 (ICN) | 밴쿠버 국제공항 (YVR) | | --- | --- | --- | | **역할** | 출발지 (Departure Airport) | 환승지 (Transit Airport) | | **좌표** | 37.463333, 126.440002 | 49.193333, -123.175659 | | **지도** | [인천국제공항 지도 보기](https://www.google.com/maps/search/?api=1&query=37.463333%2C126.440002) | [밴쿠버 국제공항 지도 보기](https://www.google.com/maps/search/?api=1&query=49.193333%2C-123.175659) | --- ## 한국을 떠나며 탑승을 알리는 안내 방송이 나오고, 사람들의 대열을 따라 에어캐나다 비행기 안으로 들어섰다. 좁은 통로를 지나 좌석을 찾아 짐을 정리하고 자리에 앉았다. 창밖으로 정든 인천공항의 계류장과 관제탑이 멀어지는 모습을 보며 깊은 숨을 들이쉬었다. 이제 몇 시간 동안은 땅이 아닌 하늘 위에서 시간을 보내야 한다. 비행기 엔진의 묵직한 진동이 발바닥을 타고 올라오며 기체가 서서히 움직이기 시작했다. --- ## 태평양 상공에서의 첫 번째 식사 이륙 후 기체가 안정 궤도에 접어들자 승무원들이 분주하게 움직이기 시작했다. 장거리 비행에서 기내식 시간은 단순히 허기를 채우는 것 이상의 의미를 갖는다. 그것은 좁은 좌석에 갇혀 지루하게 흘러가는 비행시간 속에서 유일하게 감각을 환기할 수 있는 소중한 휴식이다.
고기와 으깬 감자, 채소, 빵, 물 그리고 포장된 배추김치가 놓인 에어캐나다 기내식 쟁반
에어캐나다에서 제공된 첫 번째 기내식. 따뜻한 메인 요리와 함께 포장된 김치가 함께 나왔다.
제공된 첫 번째 기내식 쟁반 위에는 따뜻한 소고기 요리와 으깬 감자(매시드 포테이토), 더운 채소, 모닝빵, 그리고 물이 놓여 있었다. 한쪽에 곁들여진 작은 포장 김치가 눈에 띄었다. 익숙한 한국의 맛을 비행기 안에서 마주하는 것은 예상치 못한 위안을 준다. 따뜻한 음식을 천천히 씹어 넘기며 앞으로 이어질 긴 비행에 필요한 에너지를 채웠다. --- ## 캐나다의 작은 조각 기내식을 마치고 조명이 어두워진 객실 안에서 잠을 청해보려 했지만 쉽게 잠이 오지 않았다. 건조하고 묵직한 공기가 맴도는 객실 안에서, 승무원에게 음료로 캐나다 맥주를 부탁했다.
에어캐나다 기내에서 제공된 몰슨 캐네디언 캔맥주와 플라스틱 컵
기내에서 맛본 몰슨 캐네디언 맥주. 캐나다에 도착하기 전 음료를 통해 먼저 그 나라를 접하게 된다.
서빙된 캔은 캐나다의 대표적인 맥주 브랜드 중 하나인 '몰슨 캐네디언(Molson Canadian)'이었다. 차가운 맥주를 컵에 따라 한 모금 마시며, 아직 밟지 못한 캐나다라는 공간의 공기를 맥주 한 캔을 통해 미리 짐작해 보았다. 밤하늘을 가로지르는 기내의 고요한 침묵 속에서 탄산의 청량함이 서서히 긴장을 풀어주었다. --- ## 기내에서 맞이하는 아침 몇 시간 동안 얕은 잠을 자다 깨기를 반복하다 보니 어느덧 창밖이 조금씩 밝아오는 것이 느껴졌다. 승무원들이 다시 불을 켜고 아침 식사를 준비하기 시작했다. 비행기 안에서의 시간은 현실의 시간대와 어긋나 있어, 배꼽시계보다는 기내 조명의 밝기에 따라 아침과 밤이 결정되곤 한다.
스크램블 에그, 베이컨, 알감자, 버섯 요리와 과일 컵, 빵이 담긴 아침 기내식
밴쿠버 도착 전 제공된 두 번째 기내식. 달걀 요리와 베이컨, 알감자가 메인으로 나왔다.
아침 메뉴는 스크램블 에그와 베이컨, 구운 알감자, 버섯 요리였다. 곁들임으로는 달콤한 과일 컵과 모닝빵, 그리고 생수가 준비되었다. 굳어있던 몸을 가볍게 움직이며 따뜻한 아침 식사를 마쳤다. 아침을 먹고 나니 마침내 첫 번째 기착지인 밴쿠버에 가까워졌다는 사실이 실감 나기 시작했다. --- ## 밴쿠버에 닿기 전 아침 식사 트레이가 정리되고 얼마 지나지 않아 기내 방송에서 밴쿠버 국제공항에 착륙을 준비한다는 안내가 흘러나왔다. 길었던 첫 번째 하늘길이 마무리 단계에 접어들었다. 창문 밖으로 캐나다 서부 해안의 풍경이 조금씩 시야에 들어왔다. 오랜 비행 끝에 마침내 구름 아래로 펼쳐진 대지가 보였을 때, 피곤함 속에서도 목적지에 한 걸음 더 가까워졌다는 안도감이 찾아왔다. --- ## 첫 단계를 마치며 밴쿠버는 이번 여행의 최종 목적지가 아니다. 멕시코시티로 향하기 위해 몇 시간 동안 머물다 가야 하는 임시 기착지일 뿐이다. 하지만 한국을 떠나 태평양을 건너 캐나다 영토에 발을 딛는 순간, 막연하게 머릿속으로만 그리던 멕시코 여행이 비로소 확실한 현실로 다가오기 시작했다. 익숙한 시간대와 일상적인 언어를 완전히 벗어난 지금, 나의 여행은 이미 깊숙이 시작되고 있었다. --- [다음 이야기: 멕시코 여행기 02 — 밴쿠버에서 잠시 멈추고, 마침내 멕시코시티](/ko/posts/mexico-travel-diary-02-vancouver-to-mexico-city)