{"version":"5.0.0","exportedAt":"2026-07-18T20:09:51.426Z","locale":"ko","owner":"Jayden","platform":"DailySay Digital Legacy","articles":[{"slug":"building-products-alone-with-ai","title":"AI를 활용해 혼자 제품을 만드는 과정: 아이디어에서 출시까지","description":"AI를 리서치, 기획, 개발, 테스트 파트너로 활용해 1인 제품을 아이디어에서 MVP와 실제 출시까지 만드는 현실적인 과정과 원칙을 정리했다.","topic":"work","tags":["AI 제품 개발","1인 개발","MVP","바이브 코딩","제품 출시"],"publishedAt":"2026-07-15T09:00:00+09:00","updatedAt":"2026-07-15T09:00:00+09:00","growthStage":"growing","version":"1.0","revisions":[{"version":"1.0","date":"2026-07-15","summary":"Seven-step guide for solo product building with AI.","changes":["Published idea-to-launch process"]}],"relationships":[{"type":"expands","slug":"how-i-built-three-products-faster-with-ai"},{"type":"references","slug":"every-pm-should-learn-ai-automation"}],"content":"\n예전에는 제품 하나를 만들려면 서로 다른 역할을 맡은 여러 사람이 필요했다. 지금은 AI 덕분에 혼자서도 사용자 조사, 기획, 디자인, 개발, 테스트, 문서 작성까지 빠르게 오갈 수 있다. 그렇다고 AI가 팀 전체를 대신해주는 것은 아니다. 오히려 혼자 만드는 사람에게 더 많은 판단과 책임이 돌아온다.\n\n내가 생각하는 **AI를 활용한 1인 제품 개발**의 핵심은 코드를 빨리 생성하는 데 있지 않다. 해결할 문제를 좁히고, 불필요한 일을 줄이고, 실제 사용자에게 도달하는 시간을 단축하는 데 있다. 이 글은 아이디어를 떠올린 순간부터 MVP를 공개하고 피드백을 받기까지 내가 따르는 과정을 정리한 기록이다.\n\n<Callout type=\"tip\">\nAI는 속도를 높여주지만 방향을 정해주지는 않는다. 무엇을 만들지, 누구를 위해 만들지, 언제 멈출지는 사람이 결정해야 한다.\n</Callout>\n\n## AI는 공동 창업자가 아니라 속도를 높이는 도구다\n\nAI에게 “좋은 서비스 아이디어를 알려줘”라고 물으면 그럴듯한 목록을 금방 얻을 수 있다. 문제는 그 목록이 내 경험, 내가 접근할 수 있는 사용자, 내가 감당할 수 있는 비용을 모른다는 데 있다.\n\n그래서 나는 AI를 공동 창업자처럼 대하지 않는다. 대신 역할이 명확한 여러 명의 보조자처럼 사용한다.\n\n- **리서치 보조자:** 시장과 경쟁 제품을 빠르게 훑는다.\n- **기획 보조자:** 요구사항을 정리하고 빠진 조건을 질문한다.\n- **개발 보조자:** 작은 기능을 구현하고 코드를 설명한다.\n- **테스트 보조자:** 실패할 수 있는 경우와 테스트 항목을 찾는다.\n- **편집 보조자:** 랜딩 페이지, 안내 문구, 문서를 다듬는다.\n\n최종 결정권은 항상 나에게 남긴다. 이 구분이 없으면 생성 속도는 빨라져도 제품은 쉽게 엉뚱한 방향으로 커진다.\n\n## 1. 해결할 문제를 한 문장으로 정의한다\n\n제품을 만들기 전에 먼저 아래 문장을 완성한다.\n\n> **[어떤 사람]이 [어떤 상황]에서 겪는 [구체적인 문제]를 [어떤 방식]으로 줄인다.**\n\n예를 들어 “AI 일정 관리 앱을 만든다”는 제품 설명이지 문제 정의가 아니다. “여러 프로젝트를 동시에 운영하는 1인 사업자가 오늘 반드시 해야 할 일을 5분 안에 정하도록 돕는다”는 문장은 사용자와 상황, 결과가 보인다.\n\n이때 AI에는 아이디어를 만들어달라고 하기보다 문장의 빈틈을 공격해달라고 요청한다.\n\n- 이 문제가 실제로 자주 발생하는가?\n- 사용자는 지금 어떤 방식으로 해결하고 있는가?\n- 돈이나 시간을 들여 바꿀 만큼 불편한가?\n- 더 좁게 정의할 수 있는 사용자는 누구인가?\n- 제품 없이도 검증할 수 있는 가설은 무엇인가?\n\n좋은 시작점은 답이 많은 아이디어가 아니라, 확인해야 할 질문이 선명한 아이디어다.\n\n## 2. AI로 조사하되 사람에게 확인한다\n\n초기 조사에서 AI는 매우 빠르다. 경쟁 제품의 유형을 나누고, 예상 사용자를 정리하고, 인터뷰 질문 초안을 만드는 데 유용하다. 하지만 생성된 요약을 시장의 사실로 받아들이면 안 된다.\n\n나는 조사 결과를 세 층으로 나눈다.\n\n1. **AI가 제안한 가설** — 아직 확인되지 않은 아이디어\n2. **직접 확인한 자료** — 제품 페이지, 가격, 리뷰, 공개 문서\n3. **사용자가 말한 경험** — 인터뷰, 관찰, 실제 행동\n\n제품 방향은 세 번째 층에 가까워질수록 신뢰할 수 있다. 가능하면 잠재 사용자 5명에게 같은 문제를 물어본다. “이 기능을 쓰겠어요?”보다 “최근 이 문제를 어떻게 해결했나요?”가 더 좋은 질문이다. 미래의 의향보다 과거의 행동이 강한 증거이기 때문이다.\n\n## 3. 한 페이지 제품 명세를 만든다\n\n조사가 끝나면 긴 기획서 대신 한 페이지짜리 제품 명세를 작성한다. 문서에는 다음 항목만 둔다.\n\n| 항목 | 적어야 할 내용 |\n|---|---|\n| 사용자 | 이번 버전이 집중할 한 종류의 사용자 |\n| 문제 | 반복해서 발생하는 구체적인 불편 |\n| 약속 | 사용 후 달라지는 한 가지 결과 |\n| 핵심 흐름 | 사용자가 처음부터 끝까지 수행하는 행동 |\n| 제외 범위 | 이번에는 만들지 않을 기능 |\n| 성공 기준 | 출시 후 확인할 행동 또는 숫자 |\n| 위험 | 개인정보, 비용, 정확도, 운영 부담 |\n\nAI에게 이 문서를 검토하게 하면 서로 충돌하는 조건이나 빠진 예외를 빠르게 찾을 수 있다. 특히 **제외 범위**를 명확히 적는 것이 중요하다. 혼자 만드는 제품은 기능 부족보다 범위 초과로 더 자주 멈춘다.\n\n<img\n  src=\"/images/posts/ai-solo-product/ai-product-workflow.webp\"\n  alt=\"아이디어가 조사, 설계, 구현, 테스트를 거쳐 출시되는 AI 기반 1인 제품 개발 흐름\"\n  width=\"1600\"\n  height=\"758\"\n  loading=\"lazy\"\n  decoding=\"async\"\n/>\n\n*AI가 각 단계를 빠르게 연결해도, 다음 단계로 넘어갈지 결정하는 사람은 제품을 만드는 나다.*\n\n## 4. MVP는 가장 짧은 사용자 흐름만 만든다\n\nMVP는 완성도가 낮은 제품이 아니라 **가장 중요한 가설을 가장 적은 기능으로 확인하는 제품**이다. 나는 첫 버전의 흐름을 대개 네 단계로 제한한다.\n\n1. 사용자가 들어온다.\n2. 필요한 정보를 입력한다.\n3. 제품이 핵심 결과를 만든다.\n4. 사용자가 결과를 저장하거나 다음 행동을 한다.\n\n계정 설정, 대시보드, 알림, 결제, 관리자 화면은 핵심 가설과 직접 관련이 없다면 뒤로 미룬다. 먼저 클릭 가능한 화면이나 단순한 수동 서비스로 흐름을 검증할 수도 있다. 코드 한 줄 없이 사용자에게 결과를 직접 만들어주는 방식이 더 빠른 경우도 많다.\n\nAI를 사용하면 기능을 추가하기 쉬워진다. 바로 그 이유 때문에 더 강한 삭제 기준이 필요하다. “만들 수 있는가?”가 아니라 “이 기능 없이 가설을 검증할 수 없는가?”를 묻는다.\n\n## 5. AI와 개발할 때는 작은 단위로 맡긴다\n\n“이 서비스를 전부 만들어줘”라는 요청은 빠르게 많은 코드를 만들지만, 검토하기 어려운 시스템도 함께 만든다. 나는 작업을 화면 하나, 사용자 행동 하나, 데이터 흐름 하나처럼 작은 단위로 나눈다.\n\nAI에 개발 작업을 요청할 때는 네 가지를 함께 준다.\n\n```text\n목표: 사용자가 이메일로 로그인할 수 있게 한다.\n현재 상태: 사용 중인 프레임워크와 관련 파일을 설명한다.\n제약: 기존 구조, 보안 규칙, 수정하면 안 되는 범위를 적는다.\n완료 조건: 성공·실패 흐름과 실행해야 할 테스트를 정의한다.\n```\n\n코드가 생성되면 바로 다음 기능으로 넘어가지 않는다. 변경된 파일을 읽고, 실행하고, 실패 경로를 확인한다. 이해하지 못한 코드는 내가 유지할 수 없는 코드다. AI가 설명을 제대로 못하거나 테스트가 불안정하면 구현을 더 작은 조각으로 되돌린다.\n\n### 내가 지키는 개발 순서\n\n1. 현재 구조와 목표를 AI에 설명한다.\n2. 먼저 구현 계획과 변경 파일 목록만 받는다.\n3. 한 번에 하나의 작은 변경을 적용한다.\n4. 타입 검사, 린트, 테스트, 빌드를 실행한다.\n5. 브라우저에서 실제 사용자 흐름을 확인한다.\n6. 변경 이유와 남은 위험을 기록한다.\n\n이 순서를 지키면 AI가 만든 코드를 수동으로 다시 쓰는 시간보다 검토와 판단에 더 많은 시간을 사용할 수 있다.\n\n## 6. 테스트와 보안은 AI에게 넘기지 않는다\n\nAI는 테스트 케이스를 제안하고 보안 문제를 찾는 데 도움을 준다. 그러나 “문제가 없다”는 답을 보증으로 받아들이면 안 된다. 특히 인증, 결제, 개인정보, 파일 업로드, 외부 API가 들어가면 사람이 직접 확인해야 한다.\n\n출시 전에는 최소한 다음을 점검한다.\n\n- 정상 흐름뿐 아니라 빈 입력, 잘못된 값, 중복 요청을 시험한다.\n- 비밀키와 개인정보가 브라우저나 로그에 노출되지 않는지 확인한다.\n- 사용자가 다른 사용자의 데이터에 접근할 수 없는지 확인한다.\n- AI 기능이 틀리거나 응답하지 않을 때의 화면을 준비한다.\n- 예상보다 사용량이 늘었을 때 비용 상한과 제한이 있는지 확인한다.\n- 모바일 화면, 느린 네트워크, 접근성 기본 동작을 확인한다.\n\n<Callout type=\"warning\">\n사용자가 입력한 민감한 정보나 회사의 비공개 코드를 외부 AI 서비스에 보내기 전에는 데이터 보관 정책과 사용 권한을 반드시 확인해야 한다.\n</Callout>\n\n## 7. 작게 출시하고 실제 반응을 기록한다\n\n출시는 마지막 단계가 아니라 가장 정확한 조사가 시작되는 시점이다. 처음부터 많은 사람에게 알리기보다 문제를 실제로 겪는 작은 사용자 그룹에 공개한다.\n\n첫 출시에서는 페이지뷰보다 아래 행동을 본다.\n\n- 사용자가 설명 없이 핵심 흐름을 끝내는가?\n- 결과를 다시 사용하거나 다른 사람에게 공유하는가?\n- 어느 단계에서 멈추는가?\n- 제품이 사라지면 아쉽다고 말하는가?\n- 시간이나 비용을 지불할 의사가 행동으로 나타나는가?\n\nAI는 인터뷰 메모와 로그를 묶어 반복되는 패턴을 찾는 데 사용할 수 있다. 다만 서로 다른 사용자의 의견을 억지로 하나의 결론으로 합치지 않는다. 무엇을 고칠지는 제품의 약속과 가장 가까운 문제부터 선택한다.\n\n## 혼자 제품을 만드는 7일 실행 루프\n\n작은 실험은 다음과 같은 일주일 단위로 운영할 수 있다.\n\n| 날짜 | 할 일 | 결과물 |\n|---|---|---|\n| 1일차 | 문제와 사용자를 좁힌다 | 한 문장 문제 정의 |\n| 2일차 | 자료 조사와 사용자 대화 | 핵심 가설 3개 |\n| 3일차 | 제품 흐름과 제외 범위 결정 | 한 페이지 명세 |\n| 4~5일차 | AI와 핵심 흐름 구현 | 작동하는 MVP |\n| 6일차 | 테스트와 보안 점검 | 출시 체크리스트 |\n| 7일차 | 소수 사용자에게 공개 | 관찰 기록과 다음 결정 |\n\n일주일 안에 좋은 제품이 완성되는 것은 아니다. 대신 계속 만들 가치가 있는지 판단할 만큼의 증거를 얻을 수 있다. 이 속도가 AI를 사용하는 가장 현실적인 이유다.\n\n## AI가 잘하는 일과 직접 해야 하는 일\n\n### AI에 적극적으로 맡길 수 있는 일\n\n- 자료의 첫 번째 분류와 요약\n- 질문 목록과 문서 초안 작성\n- 반복적인 코드와 테스트 뼈대 생성\n- 오류 메시지 설명과 디버깅 가설 제안\n- 문구의 여러 버전과 번역 초안 생성\n- 회의 및 사용자 인터뷰 메모 정리\n\n### 끝까지 직접 책임져야 하는 일\n\n- 어떤 문제를 해결할지 선택하는 일\n- 사용자 말을 맥락 안에서 해석하는 일\n- 제품의 품질과 보안 기준을 정하는 일\n- 생성된 코드와 정보가 맞는지 검증하는 일\n- 무엇을 버리고 언제 출시할지 결정하는 일\n- 실패의 비용과 사용자에게 미칠 영향을 책임지는 일\n\n## 자주 묻는 질문\n\n### 개발자가 아니어도 AI로 제품을 만들 수 있을까?\n\n간단한 프로토타입과 수동 서비스는 가능하다. 하지만 사용자의 데이터와 결제가 들어가는 실제 제품은 구조, 보안, 운영을 이해해야 한다. 모르는 부분을 AI의 확신으로 덮기보다 범위를 줄이거나 전문가의 검토를 받는 편이 안전하다.\n\n### 어떤 AI 도구부터 선택해야 할까?\n\n도구보다 먼저 작업을 정하는 것이 좋다. 조사, 문서 작성, 디자인, 코딩, 테스트 중 가장 많은 시간이 걸리는 한 단계를 고르고 거기에 맞는 도구 하나부터 사용한다. 도구를 여러 개 연결하는 것보다 반복 가능한 작업 방식을 만드는 것이 먼저다.\n\n### AI가 만든 코드는 그대로 사용해도 될까?\n\n그대로 배포하면 안 된다. 코드의 동작과 의존성, 라이선스, 보안, 예외 처리를 검토하고 프로젝트의 테스트와 빌드를 통과시켜야 한다. 설명할 수 없는 코드는 제품의 부채가 된다.\n\n### 혼자 만들 때 가장 중요한 지표는 무엇일까?\n\n초기에는 가입자 수보다 핵심 문제를 실제로 해결한 사용자 수가 중요하다. 제품의 핵심 행동을 끝낸 사람, 다시 돌아온 사람, 결과를 위해 비용을 지불한 사람을 먼저 본다.\n\n## 결국 제품을 만드는 것은 사람이다\n\nAI는 혼자 제품을 만드는 사람의 손을 빠르게 해준다. 조사와 구현 사이의 거리를 줄이고, 익숙하지 않은 역할을 시작할 수 있게 돕는다. 하지만 제품의 방향, 사용자에 대한 이해, 출시할 용기는 자동으로 만들어주지 않는다.\n\n좋은 1인 제품은 가장 많은 AI 기능을 사용한 제품이 아니다. **작은 문제를 정확히 선택하고, 실제 사용자에게 빠르게 전달하고, 배운 내용을 다음 버전에 반영한 제품**이다.\n\n나는 [삶을 하나의 프로젝트로 바라본다](/ko/posts/built-slowly-updated-daily). 제품 만들기도 마찬가지다. 완벽한 계획을 기다리기보다 작은 버전을 공개하고, 결과를 기록하고, 다음 결정을 내린다. AI는 그 프로젝트를 대신하는 존재가 아니라 더 짧은 주기로 실행하게 해주는 도구다.\n"},{"slug":"principles-of-maintaining-code-quality-with-ai","title":"AI가 짠 코드의 품질을 의심하는 법: 1인 개발자를 위한 8가지 검증 원칙","description":"AI 코딩 도구로 AttractiveWebAI, Shopify 앱 등을 개발하며 겪은 10가지 실패와, 동작하는 것처럼 보이는 'UI 착시'를 극복하고 코드 품질을 지키기 위한 8가지 현실적인 원칙을 공유합니다.","topic":"work","tags":["AI 코딩 원칙","코드 품질","기술 부채","1인 개발","QA"],"publishedAt":"2026-07-13T09:00:00+09:00","updatedAt":"2026-07-13T09:00:00+09:00","growthStage":"growing","version":"1.0","revisions":[{"version":"1.0","date":"2026-07-13","summary":"Eight verification principles from Shopify and AttractiveWebAI builds.","changes":["Published AI code quality checklist"]}],"relationships":[{"type":"expands","slug":"building-products-alone-with-ai"},{"type":"references","slug":"how-i-built-three-products-faster-with-ai"}],"content":"\n#### 그럴듯한 화면이 준 착각\n\nShopify 멤버십 앱의 첫 데모 빌드가 성공했을 때, 나는 흥분을 감추지 못했다. 화면에는 깔끔한 대시보드가 떴고, 설정 메뉴의 토글 버튼들은 부드럽게 작동했으며, 포인트 적립 규칙을 입력하는 폼도 완벽해 보였다. 마우스를 클릭할 때마다 화면이 기민하게 반응했다. AI 코딩 도구에 몇 번의 지시어를 입력한 지 단 이틀 만에 얻은 결과였다. 이 속도라면 다음 주에 당장 앱스토어에 출시할 수 있을 것 같았다.\n\n하지만 기쁨은 오래가지 않았다. 테스트 계정으로 상점에서 실제 결제를 진행하고 고객 등급을 올리려 하자, 앱은 아무런 반응도 하지 않았다. 코드를 뜯어보고서야 차가운 진실을 마주했다. 화면에 표시된 그럴듯한 숫자들은 전부 AI가 임의로 채워 넣은 Mock Data(가짜 데이터)였고, 정작 돈을 처리하는 결제 API와 포인트 적립 웹훅, 자동 할인 트리거는 단 한 줄도 작성되어 있지 않았다. 껍데기만 존재하고 알맹이는 없는 상태였다. \n\n나는 전문 소프트웨어 엔지니어가 아니다. IT 프로젝트 매니저(PM)로 일하며 필요한 제품을 AI의 힘을 빌려 직접 만들고 배포하는 1인 제작자에 가깝다. 웹사이트 분석 SaaS인 AttractiveWebAI, Shopify 멤버십 앱, 그리고 macOS 창 미리보기 유틸리티까지 여러 제품을 개발하면서 Gemini, Claude, Codex 같은 도구들을 전방위로 활용했다. \n\n처음에는 원하는 기능을 대강 묘사하면 알아서 작동하는 코드가 뚝딱 나오는 속도에 취해 있었다. 그러나 프로젝트 규모가 커지고 기능들이 얽히기 시작하자, 화면 뒤에 숨어 있던 결함들이 일제히 머리를 치켜들기 시작했다.\n\n---\n\n#### AI가 숨겨둔 10가지 부채\n\n배포 단계를 거치며 뼈아프게 기록한 실패의 목록은 생각보다 길고 구체적이었다.\n\n1. **DB 저장 누락**: 프론트엔드 폼에서 '저장' 버튼을 누르면 화면에 성공 메시지가 뜨지만, 정작 Supabase 데이터베이스에는 아무것도 입력되지 않은 채 메모리 안에서만 데이터가 맴돌다 사라졌다.\n2. **API 연결 증발**: 프론트엔드 UI의 멋진 버튼과 입력창은 완성되었으나, 백엔드 API 엔드포인트와 통신하는 코드가 누락되어 실제 서비스가 동작하지 않았다.\n3. **가짜 데이터의 방치**: 개발 편의를 위해 임시로 삽입한 Mock Data와 테스트용 하드코딩 값이 실제 운영 모드에서도 그대로 사용되고 있었다.\n4. **동일 코드의 중복 생성**: AI가 기존 프로젝트의 전체 구조를 기억하지 못해, 이미 존재하는 유틸리티 함수나 컴포넌트를 이름만 조금 바꾼 채 서너 개씩 중복으로 새로 만들어냈다.\n5. **회귀(Regression) 오류**: 한 곳의 버그를 고치기 위해 코드를 수정하면, 이전에 잘 작동하던 전혀 다른 페이지의 기능이 깨져버리는 현상이 반복됐다.\n6. **빌드 성공의 함정**: `npm run build`나 TypeScript 타입 검사는 완벽하게 성공했지만, 런타임에 특정 조건에서 브라우저가 흰 화면만 뿜어내는 치명적인 오류가 발생했다.\n7. **`console.log`만 남은 보고**: AI가 기능 구현을 마쳤다고 당당히 답했으나, 코드를 열어보니 알맹이 대신 `console.log(\"TODO: 구현 예정\")` 주석만 덩그러니 남겨져 있었다.\n8. **데이터베이스 스키마 누락**: 로컬 개발 환경에서 Supabase 테스트 계정으로 잘 되던 기능을 실제 운영용 Supabase 계정으로 옮기면서, 코드와 환경변수는 바꿨지만 SQL 테이블과 트리거 스키마를 이관하지 않아 서비스 전체가 멈췄다.\n9. **핵심 로직의 생략**: Shopify 앱 배포 과정에서 화면 디자인은 끝났으나, 정작 핵심인 Billing API 연동과 자동 할인 정책 호출 로직이 연결되지 않아 실제 수익 모델을 검증할 수 없었다.\n10. **시스템 권한 인식 오류**: macOS 창 미리보기 유틸리티 개발 중, OS 설정 화면에서 접근성 권한과 화면 기록 권한이 켜져 있는 것처럼 보여도 실제 런타임 코드에서는 해당 권한 상태를 감지하지 못해 먹통이 되는 디바이스 수준의 예외가 빈번했다.\n\n이 실패들을 수습하며 밤을 새우다 보니 한 가지 깨달음이 머리를 쳤다. AI 코딩에서 진짜 병목은 코드를 짜는 행위 자체가 아니었다. **AI가 뱉어낸 코드를 검증하고, 그것이 '완전히 완료되었다'는 사실을 인간의 눈으로 입증하는 과정**이 핵심이었다. 이를 방치하면 제품은 작동하는 척하는 기술 부채의 거대한 늪으로 변해버린다.\n\n이 시행착오를 건너며 내가 정립한 8가지 코드 품질 검증 원칙을 공유한다.\n\n---\n\n#### 원칙 1. 요청하기 전에 완료 조건(Definition of Done)부터 적는다\n\nAI에게 \\\"로그인 기능 만들어줘\\\"라고 모호하게 요청하면, AI는 임의로 쉬운 방법을 찾아 대충 동작만 하는 코드를 짠다. 나는 기능을 요구하기 전에 반드시 검증해야 할 체크리스트를 미리 작성하여 질문에 포함한다.\n\n```markdown\n[완료 조건]\n1. 사용자가 Google OAuth 계정으로 로그인할 수 있는가?\n2. 로그인 세션이 새로고침이나 브라우저 재시작 후에도 유지되는가?\n3. 로그아웃 버튼을 누르면 세션이 삭제되고 메인 페이지로 리다이렉트되는가?\n4. 로그인하지 않은 사용자가 API를 직접 호출할 때 401 Unauthorized 에러를 반환하는가?\n5. 로그인한 사용자는 오직 자신의 데이터만 조회하고 수정할 수 있는가?\n6. 비밀번호나 민감한 토큰이 로컬 스토리지에 평문으로 남지 않는가?\n```\n\n이렇게 명확한 제약과 테스트 시나리오를 주면 AI는 예외 처리 코드와 보안 로직을 생략하지 않고 처음부터 꼼꼼히 뼈대를 채워 넣는다.\n\n#### 원칙 2. AI의 완료 보고를 절대 그냥 믿지 않는다\n\nAI가 \\\"요청하신 기능을 완벽히 구현했습니다\\\"라고 말할 때가 가장 위험하다. 나는 AI의 보고 직후, 그 결과물을 확인하기 위해 언제나 다음 질문을 던져 답변을 요구한다.\n\n* 변경되거나 새로 생성된 파일의 전체 목록\n* 각 파일에서 실제로 수정된 핵심 코드 영역과 이유\n* 임시 테스트를 위해 남겨둔 Mock Data나 하드코딩된 값의 존재 여부\n* 코드 내에 포함된 `TODO` 주석이나 `console.log` 위치\n* 아직 구현하지 못했거나 환경 제약으로 남겨둔 기술적 한계\n\n이 질문을 던지는 것만으로도 AI는 \\\"사실 이러이러한 부분은 임시 데이터로 처리했습니다\\\"라며 뒤늦게 누락된 부분을 털어놓거나 스스로 미완성된 코드를 보강한다.\n\n#### 원칙 3. 빌드 성공과 기능 성공을 엄격히 구분한다\n\n컴파일러가 에러를 내지 않는다고 해서 비즈니스 로직이 성공한 것은 아니다. 터미널 창의 초록색 성공 메시지를 본 뒤에는 반드시 수동으로 다음 항목들을 하나씩 검증한다.\n\n* **상태 보존**: 폼을 작성하고 저장한 뒤 브라우저를 강제로 새로고침했을 때 데이터가 데이터베이스로부터 정확히 다시 로드되는지 확인한다.\n* **한계치 입력**: 빈 값 제출, 비정상적인 문자 입력, 중복 클릭을 연속으로 발생시켜 시스템이 뻗지 않는지 본다.\n* **권한 분리**: 비로그인 상태이거나 다른 사용자의 계정 토큰을 모방해 비공개 페이지나 API 엔드포인트에 접근을 시도해 본다.\n* **로그 확인**: 정상적으로 동작하는 화면 뒤에서 브라우저 콘솔창이나 서버 로그에 숨겨진 404 에러나 `unhandled rejection` 경고가 없는지 관찰한다.\n\n#### 원칙 4. 작업의 단위를 최소한으로 쪼갠다\n\n한 번에 \\\"대시보드 페이지와 분석 데이터 연동을 한꺼번에 해줘\\\"라고 큰 덩어리로 주문하면 AI는 높은 확률로 내부 구조를 엉망으로 섞거나 일부 로직을 빼먹는다. 귀찮더라도 단계를 철저히 나눈다.\n\n1. **데이터 스키마 설계**: 데이터베이스 테이블 구조와 관계 설정 SQL을 작성해 반영한다.\n2. **API 핸들러 작성**: 데이터를 조회하고 저장하는 백엔드 API 엔드포인트를 먼저 만들고 Postman 등으로 단독 테스트한다.\n3. **UI 바인딩**: 화면 구성 요소를 만들고 앞서 생성한 API에 붙인다.\n4. **예외 처리 추가**: 네트워크 단절, 입력 오류, 에러 응답 상황의 안내 문구를 적용한다.\n5. **프로덕션 검증**: 로컬 환경을 벗어나 staging 혹은 배포 주소에서 실제 동작 여부를 최종 확인한다.\n\n#### 원칙 5. 코드를 짠 AI와 검토하는 AI를 분리한다\n\n하나의 채팅 세션에서 동일한 AI 모델에게 계속 코드를 짜게 하고 그 안에서 검토까지 시키면, 자신이 만든 코드의 논리 오류를 보지 못하는 인지 편향에 빠진다. \n\n나는 기능을 구현하고 나면, 코드를 완전히 새로운 대화 세션이나 다른 모델(예: Claude로 짰다면 Gemini로 검토)에 넣고 다음과 같이 프롬프트를 준다.\n\n> \"이 코드는 특정 기능을 위해 작성된 코드입니다. 당신은 매우 깐깐한 시니어 백엔드 엔지니어이자 QA 전문가입니다. 이 코드의 보안 취약점, 엣지 케이스 오류 가능성, 성능 비효율성, 구조적 개선점을 냉정하게 리뷰해 주세요.\"\n\n이 방식을 쓰면 혼자 일하면서도 아주 훌륭한 코드 리뷰 파트너를 곁에 둔 효과를 얻을 수 있다.\n\n#### 원칙 6. 기능의 세부 구현 상태를 매트릭스로 관리한다\n\n\\\"대시보드 페이지 완성했어요\\\"라는 한 마디에는 너무 많은 오해의 소지가 있다. 기획자, 디자이너, 개발자로서의 자아를 모두 가진 1인 개발자는 더 명확한 기준이 필요하다. 나는 메모장이나 노션에 기능별로 아래 상태를 세분화해 체크한다.\n\n* [ ] **미구현 (Unimplemented)**: 기획만 존재함\n* [ ] **UI 레이아웃 완료 (UI Only)**: 화면 모양만 잡음\n* [ ] **임시 데이터 연결 (Mock Data)**: 로컬 더미 데이터로 동작 시늉만 냄\n* [ ] **백엔드 API 연결 완료 (API Connected)**: API 통신은 됨\n* [ ] **DB 영속성 확인 (DB Persisted)**: 실제 DB에 쓰고 읽기가 보장됨\n* [ ] **예외/엣지 케이스 테스트 완료 (QA Verified)**: 실패 상황 테스트 통과\n* [ ] **운영 환경 검증 완료 (Prod Verified)**: 실서버 배포 후 검증 끝\n\n이 단계를 밟지 않고 눈에 보이는 화면만으로 기능을 완료 처리하면, 나중에 어느 부분이 가짜이고 진짜인지 스스로도 구별하지 못하는 혼란에 직면하게 된다.\n\n#### 원칙 7. 코드 수정 전에 기존 맥락을 먼저 이해시킨다\n\n기존 프로젝트의 소스코드를 대뜸 넘겨주며 \\\"여기에 이거 추가해줘\\\"라고 하면 AI는 기존 코딩 패턴이나 설계 원칙을 무시하고 ad-hoc(임시변통) 식의 지저분한 코드를 덧붙이기 일쑤다. 수정 요청 전에 기존 구조의 맥락 파악을 먼저 시켜야 한다.\n\n> \"이 파일의 코드를 수정할 예정입니다. 변경을 요청하기 전에, 먼저 이 파일의 현재 구조와 데이터 흐름, 그리고 구현 방식의 의도를 설명해 주세요. 어떤 함수가 영향을 받을 수 있는지 정리해 주시기 바랍니다.\"\n\nAI가 기존 코드를 정확하게 해석하고 분석 결과를 내놓은 것을 확인한 뒤에야 비로소 \\\"그렇다면 그 의도와 패턴에 맞게 최소한의 변경으로 기능을 구현해줘\\\"라고 요청한다. 이 단계 하나만으로도 코드의 일관성이 몰라보게 좋아진다.\n\n#### 원칙 8. 빚을 지는 것은 괜찮지만, 숨기지는 않는다\n\n개발을 하다 보면 일정이나 리소스 한계 때문에 어쩔 수 없이 지름길을 택해야 할 때가 있다. 임시 데이터를 하드코딩하거나 보안 검증을 잠시 미뤄두는 식이다. 이때 중요한 것은 그 '부채'를 코드 속에 몰래 묻어두지 않는 것이다. \n\n나는 기술 부채 목록을 프로젝트 루트 폴더에 `tech-debt.md` 파일로 명시해 두고, 임시 방편을 쓸 때마다 즉시 기록한다.\n\n```markdown\n## 현재 프로젝트의 기술 부채 목록\n\n* [AttractiveWebAI] 분석 차트에 여전히 임시 Mock Data 사용 중 (실제 배포 전 빅쿼리 API 파이프라인 연동 필수)\n* [Shopify 멤버십] 신규 회원 가입 혜택 결제 처리 시 할인 검증 웹훅 수신부 누락 (운영 배포 전 보안 체크 필수)\n* [공통] 사용자 세션 만료 예외 발생 시 로그아웃 처리 미비\n* [macOS 유틸리티] 시스템 접근성 권한 획득 확인용 하드코딩된 대기 시간(3초) 존재 -> 이벤트 기반 트리거로 변경 필요\n```\n\n지저분한 코드를 짰다는 사실보다 무서운 것은 내가 어디에 지저분한 코드를 남겨두었는지 잊어버리는 것이다. 빚의 규모를 눈앞에 보이게 관리하면 다음 개발 주기에 무엇을 먼저 개선해야 할지 선명하게 알 수 있다.\n\n---\n\n#### 진짜 완성된 제품을 위하여\n\nAI를 통한 개발은 개발을 '가벼운 행위'로 느끼게 만든다. 프롬프트 창에 질문을 몇 번 던지는 것만으로 수백 줄의 코드가 채워지고 빌드가 완료되는 모습을 보면, 내가 대단히 거대한 제품을 순식간에 통제하고 있다는 착각이 든다.\n\n하지만 진짜 완성도 높은 제품은 작성된 코드의 양이 아니라, 버려진 임시 코드의 양과 확인된 예외 상황의 수로 결정된다. 작동하지 않는 기능을 작동하는 것처럼 둔 껍데기 제품은 첫 사용자가 들어오는 순간 모래성처럼 무너진다.\n\nAI는 훌륭한 러닝메이트이자 타이핑 비서다. 그러나 제품의 완료 선을 긋고 품질을 보장하는 최후의 방어선은 여전히 기획하고 검증하는 인간의 몫이다. 화려한 화면 뒤에 가려진 동작 하나, 데이터 한 줄을 매섭게 뜯어보는 집요함이야말로 AI 시대에 1인 메이커가 갖춰야 할 진짜 개발 역량일지도 모른다.\n"},{"slug":"pmp-pass-review-part-2","title":"PMP 합격 후기 2부: 시험 당일 시간 관리와 마지막 합격 팁","description":"Pearson VUE 센터에서 PMP 시험을 치른 실제 경험과 첫 60문제 시간 관리, 10분 쉬는 시간, 시험 직전 오답 복습 및 준비물을 정리했다.","topic":"work","tags":["PMP 시험 후기","PMP 시간 관리","Pearson VUE","PMP 시험 준비물","PMP 합격 팁"],"publishedAt":"2026-07-05T09:00:00+09:00","updatedAt":"2026-07-05T09:00:00+09:00","growthStage":"maintained","version":"1.0","revisions":[{"version":"1.0","date":"2026-07-05","summary":"Exam-day companion to Part 1: time management and prep tips.","changes":["Added Pearson VUE day-of tactics"]}],"relationships":[{"type":"continues","slug":"pmp-pass-review-part-1"}],"content":"\n[1부](/ko/posts/pmp-pass-review-part-1)에서는 PMP가 어떤 자격증인지, 약 7주 동안 온라인 강의와 PMI Study Hall, 오답노트, GPT와 NotebookLM을 어떻게 활용했는지 정리했습니다.\n\n2부에서는 시험장에 들어간 순간부터 PASS 결과지를 받기까지의 경험을 시간 순서대로 남깁니다. 공부할 때는 알기 어려웠지만, 직접 시험을 치르고 나니 **지식만큼 체력, 시간 관리와 쉬는 시간 운영이 중요하다**는 것을 느꼈습니다.\n\n<Callout type=\"warning\">\n이 글은 2026년 7월 3일, 개편 전 PMP 시험을 응시한 후기입니다. PMI는 2026년 7월 9일부터 새 시험을 적용했습니다. 현재 시험 구조와 출제 영역은 [PMI 공식 PMP 안내](https://www.pmi.org/certifications/project-management-pmp)에서 확인하세요.\n</Callout>\n\n## 시험 당일 한눈에 보기\n\n| 항목 | 나의 경험 |\n|---|---|\n| 시험 장소 | Pearson VUE 시험 센터 |\n| 당시 시험 구성 | 180문항, 230분 |\n| 세션 구성 | 60문항씩 3개 세션 |\n| 쉬는 시간 | 세션 사이 10분씩 2회 |\n| 첫 60문항 소요 시간 | 약 80분 |\n| 준비한 간식 | 초콜릿바, 호두, 아몬드 |\n| 최종 결과 | PASS |\n\n시험 구조만 보면 “60문제씩 세 번 풀면 된다”고 생각하기 쉽습니다. 하지만 약 4시간 동안 비슷한 상황형 문제를 계속 읽고 판단하는 일은 생각보다 훨씬 피곤했습니다.\n\n## Pearson VUE 센터에 도착해서\n\n시험은 Pearson VUE 센터에서 봤습니다. 공부할 때 Full Mock도 풀어봤고 어느 정도 준비됐다고 생각했지만, 시험장에 들어가니 느낌이 완전히 달랐습니다.\n\n신분 확인을 하고 개인 물품을 정리한 뒤 시험 자리에 앉는 순간부터 긴장이 올라왔습니다. 화면에 첫 문제가 나타나자 평소보다 문장을 더 오래 읽게 됐고, 쉬운 선택지도 계속 의심하게 됐습니다.\n\n센터별 안내와 반입 규정은 다를 수 있으므로 도착 시간, 신분증, 보관 가능한 물품을 예약 안내 메일에서 미리 확인하는 것이 좋습니다. 특히 영문 이름과 신분증 정보가 예약 정보와 일치하는지도 다시 확인했습니다.\n\n## 실제 시험은 예상보다 어렵게 느껴졌다\n\n개인적으로 실제 시험은 생각보다 어렵게 느껴졌습니다. Study Hall에서 비슷한 형식의 문제를 많이 봤지만, 시험장에서는 긴장감 때문에 선택지 사이의 작은 차이가 더 크게 느껴졌습니다.\n\n한 문제를 풀 때마다 다음과 같은 생각이 반복됐습니다.\n\n- 둘 다 맞는 말 같은데 무엇을 먼저 해야 하지?\n- 이 상황은 분석이 먼저일까, 행동이 먼저일까?\n- 지금 Escalation할 단계인가?\n- Agile 상황인가, Predictive 상황인가?\n- 문제에서 묻는 것이 `FIRST`인가, `NEXT`인가?\n\n완전히 모르는 문제보다 두 개의 선택지 중 하나를 고르는 문제가 더 많은 에너지를 사용했습니다. 모든 문제에 확신을 얻으려고 하면 시간이 빠르게 사라졌습니다.\n\n## 첫 60문제에 80분을 사용했다\n\n첫 세션 60문제를 푸는 데 약 80분이 걸렸습니다. 첫 번째 쉬는 시간에 나왔을 때 “이 속도면 뒤에서 시간이 부족하지 않을까?”라는 생각이 들었습니다.\n\n첫 구간에서 시간이 오래 걸린 이유는 단순했습니다.\n\n- 긴장해서 문제를 반복해서 읽었다.\n- 확실히 고른 답도 다시 검토했다.\n- 어려운 문제에서 바로 넘어가지 못했다.\n- 전체 시간보다 현재 문제 하나에 집중했다.\n\n첫 쉬는 시간에는 점수나 어려웠던 문제를 다시 생각하지 않으려고 했습니다. 물을 마시고, 초콜릿바와 견과류를 조금 먹고, 목과 어깨를 스트레칭했습니다. 짧게라도 화면과 문제에서 완전히 떨어지는 것이 도움이 됐습니다.\n\n다시 들어간 뒤에는 전략을 바꿨습니다.\n\n> **확실히 아는 문제는 다시 읽지 말고 넘어가자. 어려운 문제 하나가 뒤의 쉬운 문제를 풀 시간을 가져가게 두지 말자.**\n\n이후에는 질문이 `FIRST`, `NEXT`, `BEST` 중 무엇을 요구하는지 먼저 보고, 명백히 맞지 않는 선택지를 제거한 뒤 결정했습니다. 덕분에 마지막 세션에서는 시간이 조금 남았습니다.\n\n## 나에게 맞았던 시간 관리 방법\n\n시험을 다시 준비한다면 문제당 시간을 완벽하게 동일하게 나누지는 않을 것입니다. 대신 60문항 단위로 남은 시간을 확인하고, 한 문제에 오래 머무르는 순간을 줄이겠습니다.\n\n### 1. 질문이 요구하는 행동부터 확인한다\n\n상황 설명을 읽기 전에 마지막 문장에서 프로젝트 매니저가 `가장 먼저`, `다음으로`, 또는 `어떻게` 해야 하는지 확인하면 문제의 초점이 조금 더 잘 보였습니다.\n\n### 2. 명확한 문제는 한 번에 끝낸다\n\n확실한 답을 골랐는데 불안하다는 이유만으로 다시 읽으면 시간이 쌓입니다. 검토가 필요한 문제와 단순히 긴장 때문에 의심하는 문제를 구분하려 했습니다.\n\n### 3. 어려운 문제는 한정된 시간만 사용한다\n\n선택지 두 개가 계속 남는다면 문제의 핵심 단어와 PMI Mindset을 다시 확인한 뒤 결정했습니다. 한 문제에 완벽한 확신을 얻는 것보다 전체 시험을 끝내는 것이 중요했습니다.\n\n### 4. 세션이 끝나기 전에 남은 시간을 본다\n\n문제마다 시계를 보면 집중력이 깨질 수 있습니다. 대신 일정한 간격과 세션 종료 전에 남은 시간을 확인하는 방식이 나에게 더 잘 맞았습니다.\n\n## 10분 쉬는 시간은 직접 확인하세요\n\nPearson VUE 센터에서 시험을 본다면 쉬는 시간을 직접 확인하는 것을 추천합니다. **10분은 생각보다 정말 빨리 지나갑니다.**\n\n화장실을 다녀오고, 간식을 먹고, 다시 들어갈 때 신분 확인과 보안 절차를 거치면 시간이 금방 지나갑니다. 나는 첫 번째 쉬는 시간에 10분을 조금 넘겼습니다.\n\n센터 문 앞이나 안내받은 위치에서 시계를 확인한 뒤 이동하는 것이 좋습니다. 휴대전화는 사용할 수 없거나 접근이 제한될 수 있으므로 개인 휴대전화로 시간을 확인할 수 있다고 생각하지 않는 편이 안전합니다. 정확한 절차는 반드시 해당 센터의 안내를 따르세요.\n\n### 쉬는 시간에 실제로 한 일\n\n1. 물을 마셨다.\n2. 초콜릿바와 견과류를 조금 먹었다.\n3. 목, 어깨와 허리를 스트레칭했다.\n4. 지나간 문제를 떠올리지 않았다.\n5. 남은 시간과 다음 세션 전략만 확인했다.\n\n쉬는 시간에 문제를 복기하면 이미 제출한 세션에 대한 불안만 커질 수 있습니다. 나에게는 머리를 비우고 몸을 움직이는 쪽이 훨씬 효과적이었습니다.\n\n## 시험 직전에 가장 도움이 된 공부\n\n시험 직전에 가장 도움이 된 것은 책을 처음부터 끝까지 다시 읽는 일이 아니었습니다. 내가 틀린 문제를 다시 보면서 **왜 틀렸는지 직접 설명하는 것**이었습니다.\n\n특히 시험 이틀 전부터는 새로운 내용을 더 넣기보다 다음 두 가지를 반복했습니다.\n\n### 1. 기존 오답노트\n\n정답 문장보다 내가 반복한 실수를 봤습니다.\n\n- 문제를 끝까지 읽지 않았다.\n- `FIRST`와 `NEXT`를 구분하지 않았다.\n- 팀과 대화하기 전에 Escalate했다.\n- 원인을 찾기 전에 해결책을 선택했다.\n- 변경의 영향을 분석하기 전에 실행했다.\n- Predictive와 Agile 상황을 혼동했다.\n\n### 2. PMP Mindset\n\n시험 직전에는 방대한 프로세스 목록보다 판단의 기본 순서를 짧게 복습했습니다.\n\n> **상황 파악 → 원인 확인 → 팀과 협업 → 영향 분석 → 절차에 따른 행동**\n\n물론 모든 문제에 동일하게 적용되는 공식은 아닙니다. 하지만 긴장한 상황에서 너무 강한 조치를 성급하게 선택하지 않도록 잡아주는 기준이 됐습니다.\n\n## 시험장에 챙기면 좋았던 것\n\n센터 규정을 먼저 확인한다는 전제에서, 개인적으로 다음 준비가 도움이 됐습니다.\n\n- 예약 정보와 일치하는 유효한 신분증\n- 초콜릿바처럼 빠르게 먹을 수 있는 간식\n- 호두나 아몬드 같은 견과류\n- 물\n- 체온에 맞춰 조절할 수 있는 편한 옷\n- 시험장 위치와 도착 시간 메모\n\n간식을 많이 먹는 것보다 쉬는 시간에 부담 없이 당과 에너지를 조금 보충하는 것이 좋았습니다. 목, 어깨, 허리를 가볍게 풀어주는 것도 다음 세션의 집중력을 회복하는 데 도움이 됐습니다.\n\n## 4시간 모의고사를 꼭 경험해보세요\n\n짧은 문제 세트에서 좋은 점수를 받는 것과 약 4시간 동안 판단을 이어가는 것은 다른 경험이었습니다.\n\nFull Mock을 끝까지 풀어보면 지식 외에도 다음을 확인할 수 있습니다.\n\n- 어느 세션에서 집중력이 가장 떨어지는가?\n- 첫 60문제를 너무 천천히 풀고 있지 않은가?\n- 쉬는 시간 후 다시 집중하는 데 얼마나 걸리는가?\n- 물과 간식을 어느 정도 먹어야 편한가?\n- 오래 앉아 있을 때 목과 허리가 괜찮은가?\n\n가능하면 실제 시험과 비슷하게 휴대전화를 멀리 두고, 시간을 재고, 정해진 쉬는 시간만 사용해보는 것을 추천합니다. 시험 당일 처음 경험하는 요소를 하나라도 줄일 수 있습니다.\n\n## Study Hall 점수가 60%대라면\n\nStudy Hall 점수가 60% 초중반이면 합격 후기의 높은 점수와 비교하며 불안해질 수 있습니다. 내 Full Mock 점수도 66%와 65%, 전체 평균은 약 62%였습니다.\n\n그 점수로 실제 시험에 합격했지만, 이것을 “60%면 무조건 합격한다”는 기준으로 말하고 싶지는 않습니다. 사람마다 풀어본 문제, 오답 분석 수준, 시험 당일 컨디션이 다르기 때문입니다.\n\n대신 아래 질문을 확인해보면 좋겠습니다.\n\n- 틀린 이유를 내 말로 설명할 수 있는가?\n- 비슷한 상황에서 같은 실수를 반복하지 않는가?\n- Full Mock을 실제 시간 안에 끝낼 수 있는가?\n- 답을 외우지 않고 PMI 관점의 판단 순서를 적용할 수 있는가?\n\n점수 하나보다 이 질문에 대한 답이 준비 상태를 더 잘 보여줬습니다.\n\n## AI는 정답지가 아니라 복습 파트너였다\n\nGPT와 NotebookLM은 오답노트 정리, PMP Mindset 복습, 헷갈리는 개념 비교에 도움이 됐습니다. 특히 시험 직전에는 흩어져 있던 내용을 짧은 질문과 요약으로 바꾸는 데 유용했습니다.\n\n하지만 PMP 문제를 그대로 입력하고 AI가 고른 선택지만 확인하는 방식은 추천하지 않습니다. 선택지 사이의 미묘한 차이를 AI가 잘못 해석할 수 있고, 그럴듯한 설명으로 틀린 답을 확신 있게 제시할 수도 있습니다.\n\nAI를 사용할 때도 다음 과정은 직접 해야 합니다.\n\n1. 내가 왜 그 답을 골랐는지 먼저 적는다.\n2. 공식 해설과 출처를 확인한다.\n3. AI에는 정답보다 사고 과정의 빈틈을 질문한다.\n4. 설명이 다르면 공식 자료를 기준으로 다시 검증한다.\n5. 마지막에는 내 언어로 한 줄 원칙을 남긴다.\n\n## 결과지를 받았을 때\n\n시험이 끝나고 PASS 결과를 확인했을 때 가장 먼저 든 감정은 안도감이었습니다. 준비하는 동안 낮은 점수와 어려운 문제를 볼 때마다 흔들렸지만, 결국 그 오답들이 시험장에서 한 번 더 생각하게 해준 자료가 됐습니다.\n\n영역별 결과는 People이 Below Target, Process가 Target, Business Environment가 Above Target이었습니다. 한 영역이 Below Target이었지만 전체 결과는 PASS였습니다. 다만 이것은 나의 개인 결과일 뿐이며, 영역별 등급을 이용해 PMI의 합격 기준을 단순하게 계산할 수 있다는 의미는 아닙니다.\n\n## 마지막으로 전하고 싶은 말\n\n오답이 나왔다고 “나는 안 되나?”라고 생각하기보다, “이 문제는 실제 시험에서 맞힐 확률이 높아진 문제”라고 받아들이면 좋겠습니다. 시험 전에 틀려서 다행인 문제도 분명히 있습니다.\n\n중요한 것은 점수 자체보다, 오답을 통해 **내가 어떤 방식으로 잘못 판단하는지 알아내는 것**이었습니다.\n\n시험을 준비하고 있다면 새로운 자료를 계속 추가하기보다 이미 공부한 내용을 자신의 판단 기준으로 만드는 데 시간을 써보세요. 그리고 시험 전에는 약 4시간을 실제로 앉아보세요. 지식, 체력, 시간 관리가 함께 준비됐을 때 훨씬 안정적으로 문제를 풀 수 있습니다.\n\n지금 준비하고 계신 모든 분을 응원합니다. 화이팅입니다! 💪🍀\n\n**처음부터 읽기:** [PMP 합격 후기 1부: 7주 준비와 Study Hall 60%대에서 PASS까지](/ko/posts/pmp-pass-review-part-1)\n"},{"slug":"pmp-pass-review-part-1","title":"PMP 합격 후기 1부: 7주 준비와 Study Hall 60%대에서 PASS까지","description":"2026년 7월 3일 PMP 시험에 합격하기까지 7주 동안 온라인 강의, PMI Study Hall, 오답노트, GPT와 NotebookLM을 활용한 공부 과정을 정리했다.","topic":"work","tags":["PMP 합격 후기","PMP 공부법","PMI Study Hall","PMP Mindset","AI 공부법"],"publishedAt":"2026-07-03T09:00:00+09:00","updatedAt":"2026-07-03T09:00:00+09:00","growthStage":"maintained","version":"1.0","revisions":[{"version":"1.0","date":"2026-07-03","summary":"Initial PMP pass review covering the 7-week study plan.","changes":["Documented Study Hall journey and AI study methods"]}],"relationships":[{"type":"references","slug":"every-pm-should-learn-ai-automation"}],"content":"\n안녕하세요. **2026년 7월 3일 금요일, PMP 시험을 보고 최종 PASS를 받았습니다.**\n\n시험을 준비하는 동안 국내 PMP 커뮤니티의 합격 후기와 [Reddit r/PMP](https://www.reddit.com/r/pmp/) 글을 거의 매일 읽었습니다. Study Hall 점수가 비슷한 사람은 붙었는지, 실제 시험은 얼마나 어려웠는지, 시험 당일에는 무엇을 준비해야 하는지 찾아보며 도움을 많이 받았습니다.\n\n늘 다른 사람의 합격 후기만 읽다가 이렇게 직접 후기를 쓰게 되니 기분이 묘하면서도 정말 좋습니다. 이 글도 지금 점수 때문에 불안하거나 공부 방향을 잡지 못한 분에게 작은 참고가 되었으면 합니다.\n\n<Callout type=\"warning\">\n이 글은 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)에서 다시 확인하세요.\n</Callout>\n\n<img\n  src=\"/images/posts/pmp-pass-2026/pmp-pass-result-full.webp\"\n  alt=\"2026년 7월 3일 PMP 시험 합격 결과와 영역별 성적이 표시된 결과지\"\n  width=\"1400\"\n  height=\"1016\"\n  loading=\"lazy\"\n  decoding=\"async\"\n/>\n\n*시험 직후 Pearson VUE 센터에서 받은 결과지. 전체 결과는 PASS였고, 영역별 결과는 People Below Target, Process Target, Business Environment Above Target이었다.*\n\n## PMP 자격증이란?\n\nPMP(Project Management Professional)는 PMI(Project Management Institute)가 운영하는 프로젝트 관리 전문 자격증입니다. 특정 산업이나 하나의 방법론에만 한정되지 않고, 프로젝트를 이끌면서 **사람, 프로세스, 비즈니스 우선순위**를 관리할 수 있는지를 평가합니다.\n\n단순히 PMBOK 내용을 얼마나 외웠는지를 확인하는 시험과는 거리가 있습니다. 실제 문제의 대부분은 프로젝트에서 발생할 법한 상황을 제시하고, 그 상황에서 프로젝트 매니저가 **가장 먼저 무엇을 해야 하는지**, 또는 **다음으로 어떤 행동을 해야 하는지** 판단하게 합니다.\n\n그래서 용어와 프로세스를 이해하는 것도 중요하지만, 문제를 바라보는 순서와 PMI가 기대하는 프로젝트 매니저의 태도를 익히는 것이 더 중요했습니다.\n\n응시 자격에는 학력에 따른 프로젝트 리딩 경험과 프로젝트 관리 교육 요건 등이 포함됩니다. 이 기준도 변경될 수 있으므로 본인의 조건은 [PMI 공식 자격 요건](https://www.pmi.org/certifications/project-management-pmp)에서 직접 확인하는 것이 가장 정확합니다.\n\n## 나의 PMP 준비 결과 요약\n\n| 항목 | 내용 |\n|---|---|\n| 시험일 | 2026년 7월 3일 금요일 |\n| 준비 기간 | 약 7주 |\n| 시험 장소 | Pearson VUE 시험 센터 |\n| 주요 학습 자료 | 온라인 강의, PMI Study Hall, 오답노트 |\n| Study Hall Full Mock 1 | 66% |\n| Study Hall Full Mock 2 | 65% |\n| Study Hall 전체 평균 | 약 62% |\n| 보조 도구 | GPT, NotebookLM |\n| 최종 결과 | PASS |\n\n결과지만 보면 준비 과정이 계획대로 흘러간 것처럼 보이지만, 실제로는 Study Hall 점수를 확인할 때마다 불안했습니다. 고득점 합격 후기를 볼수록 “이 점수로 시험을 신청해도 될까?”라는 생각이 커졌습니다.\n\n지나고 나서 보니 점수 자체보다 중요한 것은 **어떤 사고방식 때문에 반복해서 틀리는지 찾아내는 일**이었습니다.\n\n## 왜 7주 만에 기존 시험으로 응시했나\n\n처음에는 PMP 시험이 바뀌는 시점을 고려해 PMBOK 8판 기반 교재로 공부를 시작했습니다. 새로운 시험을 기준으로 여유 있게 준비할 생각이었습니다.\n\n그런데 막상 공부를 시작하니 온라인 강의를 예상보다 빠르게 수강했고, 시험 개편 전에 응시할 수 있는 일정도 남아 있었습니다. 이미 공부한 핵심 원칙은 기존 시험에도 연결되었기 때문에 준비 기간을 길게 늘이기보다, 현재 시험에 맞춰 집중해서 응시하기로 결정했습니다.\n\n이 선택에서 중요했던 것은 최신 책을 봤다는 사실보다 **내가 응시할 시험의 Exam Content Outline과 문제 유형을 다시 맞춰본 것**이었습니다. PMP를 준비한다면 교재의 판수만 보고 결정하기보다, 자신의 시험일에 적용되는 공식 출제 기준을 먼저 확인하는 것이 좋습니다.\n\n## 7주 동안 공부한 방법\n\n나의 공부 과정은 크게 네 단계로 나뉘었습니다.\n\n### 1단계: 온라인 강의로 전체 구조 이해하기\n\n처음부터 PMBOK의 모든 내용을 세세하게 외우려고 하지 않았습니다. 온라인 강의를 들으며 Predictive, Agile, Hybrid 접근 방식이 어떻게 다른지, 프로젝트 매니저가 각 상황에서 어떤 역할을 해야 하는지 큰 흐름부터 잡았습니다.\n\n평일에는 퇴근 후 조금이라도 강의를 들었습니다. 체력이 남는 날에는 여러 강의를 이어서 듣고, 힘든 날에는 짧은 구간이라도 끝냈습니다. 주말에는 평일에 들었던 내용을 복습하거나 문제를 풀었습니다.\n\n나는 원래 퇴근 후에도 오랫동안 집중해서 공부하는 스타일이 아닙니다. 그래서 하루 공부량을 완벽하게 지키는 것보다 **공부를 완전히 끊는 날을 줄이는 것**에 더 집중했습니다.\n\n### 2단계: Study Hall로 실제 판단 방식 익히기\n\n기본 강의를 들은 뒤 가장 많이 활용한 것은 PMI Study Hall이었습니다. 문제를 풀면 내가 개념을 모르는지, 질문을 잘못 읽었는지, 너무 빨리 Escalation을 선택하는지 바로 드러났습니다.\n\n처음에는 문제를 맞힌 개수만 봤습니다. 점수가 낮으면 공부가 부족하다고 생각했고, 높은 점수를 받은 사람의 후기를 찾으며 더 불안해졌습니다. 하지만 문제를 반복해서 풀다 보니 같은 점수라도 그 안에 담긴 정보가 다르다는 것을 알게 됐습니다.\n\n- 개념 자체를 몰라서 틀린 문제\n- `FIRST`, `NEXT`, `BEST` 같은 질문의 의도를 놓친 문제\n- 문제에 없는 상황을 임의로 가정한 문제\n- 바로 Sponsor나 상위 조직에 넘긴 문제\n- 팀과 대화하기 전에 사람을 교체하려 한 문제\n- 변경의 영향을 분석하기 전에 실행한 문제\n\n이렇게 틀린 이유를 분류하자 점수가 단순한 평가가 아니라 다음 공부 방향을 알려주는 자료가 되었습니다.\n\n### 3단계: Full Mock으로 약 4시간을 경험하기\n\nStudy Hall의 Full Mock 1은 66%, Full Mock 2는 65%, 전체 평균은 약 62%였습니다. 솔직히 말하면 안심되는 점수는 아니었습니다.\n\n그래도 Full Mock의 가장 큰 목적을 합격 가능성 예측에만 두지 않았습니다. 긴 시간 동안 집중력을 유지할 수 있는지, 어느 구간에서 속도가 느려지는지, 쉬는 시간 후 다시 문제에 몰입할 수 있는지를 확인했습니다.\n\nPMP 시험은 지식뿐 아니라 체력과 시간 관리도 함께 시험합니다. 짧은 문제 세트만 풀다가 시험장에 가면 실제 시험의 피로도를 처음 경험하게 됩니다. 가능하면 시험 전에 한 번은 시간을 재고 Full Mock을 처음부터 끝까지 풀어보는 것을 권합니다.\n\n### 4단계: 새 문제보다 오답노트에 집중하기\n\n시험이 가까워졌을 때는 새로운 문제를 많이 추가하지 않았습니다. 이미 틀린 문제를 다시 보며 아래 질문에 답하려고 했습니다.\n\n> “나는 왜 이 선택지를 골랐을까?”\n\n> “다른 선택지보다 이 답이 PMI 관점에서 더 적절한 이유는 무엇일까?”\n\n정답 문장을 외우면 비슷한 상황에 단어가 조금만 바뀌어도 다시 틀렸습니다. 반면 내 판단 과정을 설명할 수 있으면 새로운 문제에도 같은 원칙을 적용할 수 있었습니다.\n\n## 시험에서 도움이 된 PMP Mindset\n\nPMP Mindset을 무조건 적용되는 암기 공식으로 받아들이지는 않았습니다. 윤리, 법규, 안전, 긴급한 위험처럼 즉시 조치가 필요한 예외도 있기 때문입니다. 다만 일반적인 갈등이나 변경 상황에서는 다음 순서가 판단에 도움이 됐습니다.\n\n1. **행동하기 전에 상황과 원인을 먼저 파악한다.**\n2. **팀 내부에서 해결할 수 있는 문제는 먼저 팀과 대화한다.**\n3. **바로 Escalate하거나 Sponsor에게 넘기지 않는다.**\n4. **사람을 교체하기 전에 코칭, 협업과 갈등 해결을 시도한다.**\n5. **문제의 증상보다 Root Cause를 찾는다.**\n6. **변경 요청은 영향을 분석한 뒤 공식 절차에 따라 처리한다.**\n7. **프로젝트 매니저는 팀을 통제하기보다 지원하고 장애물을 제거한다.**\n\n실제 문제에서는 여러 선택지가 모두 그럴듯했습니다. 이때 “지금 당장 가장 강한 조치를 하는 답”보다 “상황을 이해하고 팀이 해결하도록 돕는 답”이 더 적절한 경우가 많았습니다.\n\n## 온라인 강의는 충분했나\n\n개인적으로 온라인 강의에 만족했습니다. 시험에 필요한 큰 흐름과 Mindset을 잡는 데 충분한 도움이 됐습니다.\n\n처음에는 오프라인 고가 강의까지 들어야 하나 고민했습니다. 하지만 내 경우에는 온라인 강의로 기본 구조를 익힌 뒤, Study Hall 문제를 풀고 오답을 분석하는 조합이 잘 맞았습니다.\n\n어떤 강의를 선택하느냐도 중요하지만, 강의를 들은 다음 **문제를 풀고, 틀리고, 판단 과정을 다시 정리하는 시간**이 더 중요하다고 느꼈습니다. 강의를 완주했다는 사실만으로는 시험 상황에서 선택지를 고를 수 없었습니다.\n\n## GPT와 NotebookLM을 활용한 방법\n\nPMP 준비 과정에서 GPT와 NotebookLM도 많이 활용했습니다. AI가 정답을 대신 골라주는 도구라기보다, 내가 이해한 내용을 다시 설명하고 비교하는 복습 파트너로 사용했습니다.\n\n### GPT 활용법\n\n- 헷갈리는 개념 두 개의 차이를 표로 비교하기\n- 내가 선택한 답의 사고 과정을 설명하고 빠진 전제를 질문받기\n- 오답 원인을 개념 부족, 문제 해석, Mindset 오류로 분류하기\n- 복잡한 개념을 실제 프로젝트 사례로 다시 설명받기\n- 정리한 내용을 바탕으로 짧은 복습 질문 만들기\n\n예를 들어 정답만 알려달라고 하기보다 다음처럼 질문했습니다.\n\n```text\n나는 이 상황에서 바로 Sponsor에게 보고해야 한다고 판단했다.\n내 판단에 숨어 있는 가정을 찾아주고,\nPMI 관점에서 먼저 확인해야 할 행동을 질문 형태로 알려줘.\n정답을 바로 말하지 말고 내가 다시 판단할 수 있게 도와줘.\n```\n\n### NotebookLM 활용법\n\nNotebookLM에는 내가 정리한 오답노트와 복습 자료를 모아두고, 자료 안에서 반복되는 주제를 다시 찾는 용도로 활용했습니다.\n\n- 자주 틀리는 Mindset만 모아 요약하기\n- Agile과 Predictive 상황을 나눠 복습하기\n- 변경 관리, 갈등 관리처럼 헷갈리는 주제 비교하기\n- 시험 직전 확인할 짧은 복습 목록 만들기\n\n여러 자료가 섞이면 무엇을 기준으로 답했는지 확인하기 어려워집니다. 그래서 출처가 분명한 공식 자료와 내가 직접 검토한 노트를 중심으로 사용했습니다.\n\n<Callout type=\"warning\">\nStudy Hall 문제를 AI에 그대로 넣고, AI가 선택한 답만 보고 오답을 확인하는 방식은 추천하지 않습니다. PMP 문제는 선택지 사이의 미묘한 차이와 상황의 맥락이 중요합니다. AI의 설명도 틀릴 수 있으므로 공식 자료와 해설을 기준으로 직접 검증해야 합니다.\n</Callout>\n\n## Study Hall 60%대 점수에서 배운 것\n\n내 점수는 Full Mock 66%, 65%, 전체 평균 약 62%였습니다. 이 점수만 보면 시험을 미루고 싶어질 수 있습니다. 나 역시 그랬습니다.\n\n하지만 결과적으로 점수보다 더 중요했던 것은 아래 세 가지였습니다.\n\n- 같은 이유로 틀리는 문제의 수가 줄고 있는가?\n- 정답을 외우지 않고 판단 과정을 설명할 수 있는가?\n- 실제 시험 시간 동안 집중력을 유지할 수 있는가?\n\n물론 나의 점수가 모든 사람의 합격 기준이 될 수는 없습니다. Study Hall 점수와 실제 시험 결과는 사람마다 다릅니다. 다만 60% 초중반이라는 숫자 하나만으로 준비 전체를 부정할 필요는 없다고 말하고 싶습니다.\n\n오답은 “나는 아직 준비되지 않았다”는 판정이 아니라, **실제 시험 전에 한 번 더 맞힐 가능성을 만든 문제**였습니다.\n\n## 1부를 마치며\n\n7주 동안 가장 크게 달라진 것은 외운 지식의 양보다 문제를 바라보는 순서였습니다. 바로 행동하기 전에 상황을 확인하고, 사람을 바꾸기 전에 대화하고, 변경하기 전에 영향을 분석하는 방식이 조금씩 익숙해졌습니다.\n\n다음 글에서는 Pearson VUE 시험장에 들어간 순간부터 첫 60문제에 80분을 사용해 멘탈이 흔들렸던 경험, 10분 쉬는 시간, 간식과 스트레칭, 마지막 세션의 시간 관리까지 정리했습니다.\n\n**계속 읽기:** [PMP 합격 후기 2부: 시험 당일 시간 관리와 마지막 합격 팁](/ko/posts/pmp-pass-review-part-2)\n"},{"slug":"built-slowly-updated-daily","title":"삶을 기록하는 나만의 방식\n","description":"일과 프로젝트, 여행과 음식, 그때의 생각까지 기록합니다. 이 블로그는 지나온 경험과 시행착오를 정리하고, 다음 선택을 조금 더 나아지게 만들기 위한 개인 작업 노트입니다.\n","topic":"diary","tags":["삶의 기록","프로젝트 매니저","회고","개인 블로그","성장 기록"],"publishedAt":"Sat Feb 07 2026 00:00:00 GMT+0000 (Coordinated Universal Time)","growthStage":"evergreen","version":"1.0","revisions":[{"version":"1.0","date":"2026-02-07","summary":"Initial publication of the DailySay life-logging manifesto.","changes":["Published personal project notebook framing"]}],"content":"\n삶을 기록하는 나만의 방식\n\n저는 프로젝트 매니저로 일하고 있습니다.\n\n일정을 정리하고, 문제를 발견하고, 여러 사람의 의견을 조율하면서 하나의 결과를 만들어가는 일을 합니다. 그래서인지 일상에서도 비슷한 방식으로 생각할 때가 많습니다.\n\n무엇을 하고 싶은지 정리하고, 우선 실행해봅니다. 결과가 기대와 다르면 그 이유를 돌아보고, 다음에는 무엇을 바꿀지 생각합니다. 계획대로 진행되지 않는 날도 많지만, 그 과정에서 조금씩 저만의 기준을 만들어가고 있습니다.\n\n이 블로그는 그런 경험을 기록하기 위해 시작했습니다.\n\n업무를 하며 배운 것, 프로젝트를 진행하며 겪은 시행착오, 새로운 서비스를 만들면서 고민한 내용을 남깁니다. 여행 중 발견한 장소와 인상 깊었던 음식, 그날 떠올랐던 생각처럼 조금 더 개인적인 이야기도 함께 기록합니다.\n\n각각의 주제는 서로 달라 보이지만, 결국 모두 제가 직접 경험한 일들입니다.\n\n잘 정리된 성공 사례만 남기고 싶지는 않습니다. 계획이 틀어진 이유, 생각보다 어려웠던 부분, 당시에는 최선이라고 생각했지만 나중에 돌아보니 아쉬웠던 선택도 솔직하게 기록하려고 합니다.\n\n기록을 남기면 경험이 단순히 지나간 일로 끝나지 않습니다.\n\n어떤 상황에서 어떤 결정을 내렸는지 다시 돌아볼 수 있고, 비슷한 문제를 만났을 때 조금 더 나은 판단을 내리는 데 도움이 됩니다. 시간이 지나 생각이 달라졌다면, 그 변화 역시 하나의 기록이 됩니다.\n\n장기적으로는 제가 직접 만든 회사를 운영하고, 그 회사를 100만 달러 이상의 가치를 가진 사업으로 성장시키는 것을 목표로 하고 있습니다.\n\n아직은 시작 단계이며, 구체화해야 할 부분도 많습니다. 그래서 완성된 결과만 보여주기보다 목표를 향해 가는 과정 자체를 남기려고 합니다. 무엇을 시도했고, 어떤 문제가 있었으며, 그다음에는 무엇을 바꾸었는지를 꾸준히 기록할 계획입니다.\n\n이 블로그는 대단한 성공담을 보여주기 위한 공간은 아닙니다.\n\n일과 삶에서 경험한 것들을 잊지 않기 위한 개인적인 작업 노트에 가깝습니다. 시간이 지난 뒤 다시 읽었을 때, 당시의 고민과 선택을 이해할 수 있는 기록이면 충분합니다.\n\n완벽하게 준비한 뒤 시작하기보다, 지금부터 하나씩 기록해보려고 합니다.\n"}],"projects":[{"slug":"attractive-web-ai","name":"AttractiveWebAI","timeline":"April 2026 - Present","status":"active","techStack":["Next.js","Tailwind CSS","Framer Motion","Gemini Pro API"],"links":{"demo":"https://attractive-web-ai.vercel.app","github":"https://github.com/jayden/AttractiveWebAI"},"gallery":["/images/placeholder-post.jpg"],"relatedPosts":["built-slowly-updated-daily"],"description":"손으로 그린 와이어프레임과 목업을 멀티모달 AI 모델을 활용해 즉시 인터랙티브하고 현대적인 프론트엔드 코드로 변환해 주는 플랫폼입니다.","lessonsLearned":"멀티모달 피드백 루프를 통합하려면 정밀하게 튜닝된 시스템 프롬프트와 즉각적인 렌더링 샌드박스가 필요합니다. 코드 생성 시 디바운싱을 구현하여 불필요한 LLM API 호출을 크게 줄였습니다."},{"slug":"dailysay","name":"DailySay","timeline":"January 2026 - May 2026","status":"completed","techStack":["Next.js 15","TypeScript","Supabase","MDX"],"links":{"demo":"https://www.dailysay.me","github":"https://github.com/jayden/GlobalBlog"},"gallery":["/images/placeholder-post.jpg"],"relatedPosts":["built-slowly-updated-daily"],"description":"생각, 프로젝트, 여행 로그 및 이정표를 유기적으로 연결하기 위해 디자인된 깔끔하고 미니멀한 개인 지식 플랫폼이자 커먼플레이스 북(Commonplace Book)입니다.","lessonsLearned":"정적 사이트 생성(SSG)과 클라이언트 사이드 반응형 컴포넌트(북마크, 조회수 트래킹 등)를 결합하는 것이 SEO 성능과 사용성의 최상의 밸런스를 제공합니다."},{"slug":"first-run","name":"FirstRun","timeline":"December 2025","status":"completed","techStack":["React Native","Expo","SQLite","Apple HealthKit"],"links":{"github":"https://github.com/jayden/FirstRun"},"gallery":["/images/placeholder-post.jpg"],"relatedPosts":[],"description":"매일의 실외 러닝을 기록하고, 러닝화의 마일리지를 추적하며, 헬스 텔레메트리 데이터를 동기화하는 모바일 러닝 전용 애플리케이션입니다.","lessonsLearned":"배경 GPS 트래킹은 모바일 배터리를 급격히 소모합니다. 원시 가속도계 센서와 어댑티브 위치 업데이트 로직을 사용해 배터리 문제를 해결했습니다."}],"series":[],"glossary":[{"term":"ai-agent","name":"AI Agent","definition":"스스로 환경을 인식하고 의사결정을 내리며 도구를 사용해 자율적으로 작업을 실행하는 소프트웨어 개체입니다."},{"term":"mcp","name":"MCP","definition":"모델 컨텍스트 프로토콜: LLM과 외부 데이터 소스 또는 도구 간의 안전하고 일관된 연결을 지원하기 위해 Anthropic이 개발한 개방형 표준 프로토콜입니다."},{"term":"prompt-engineering","name":"Prompt Engineering","definition":"생성형 AI 모델이 의도된 최적의 결과물을 출력하도록 지시문(텍스트 입력)을 설계, 고도화 및 최적화하는 기술입니다."},{"term":"rag","name":"RAG","definition":"검색 증강 생성: 모델이 답변을 생성하기 전 외부 지식 데이터베이스에서 관련 문서 조각들을 검색해 컨텍스트로 제공함으로써 신뢰성을 극대화하는 기술입니다."},{"term":"shopify","name":"Shopify","definition":"디지털 및 실물 매장을 호스팅하고 다국어 번역, 글로벌 결제 및 맞춤형 앱 생태계를 제공하는 세계적인 커머스 플랫폼입니다."},{"term":"pmbok","name":"PMBOK","definition":"프로젝트 관리 지식 체계: 프로젝트 관리 협회(PMI)에서 발행하는 표준 가이드로, 프로젝트 성공을 위한 핵심 프로세스, 베스트 프랙티스 및 표준 용어집입니다."},{"term":"product-discovery","name":"Product Discovery","definition":"프로덕션 코드를 작성하기에 앞서 사용자의 실제 페인 포인트를 깊이 이해하고, 해결하고자 하는 핵심 문제를 정의하며, 타당한 솔루션을 반복적으로 검증하는 단계입니다."}],"milestones":[{"id":"started-dailysay","date":"2026-01-10","title":"DailySay 프로젝트 착수","description":"다국어로 개발 지식과 일상을 동기화하는 커먼플레이스 북 개발에 착수했습니다.","category":"projects"},{"id":"travel-tokyo","date":"2026-04-12","title":"도쿄 봄 여행 및 워케이션","description":"시부야와 신주쿠에서 로컬 에스프레소 바와 테크 스타트업 오피스를 탐방하고 스트리트 사진을 촬영했습니다.","category":"travel"},{"id":"career-pm","date":"2025-08-01","title":"TechCorp AI 제품 리드 합류","description":"자율형 에이전트 인프라 설계, 언어 모델 가이드라인 정립 및 디스커버리 업무를 총괄하기 시작했습니다.","category":"career"}],"knowledgeGraph":{"nodes":[{"id":"post:building-products-alone-with-ai","label":"AI를 활용해 혼자 제품을 만드는 과정: 아이디어에서 출시까지","type":"article","url":"/ko/posts/building-products-alone-with-ai"},{"id":"category:work","label":"work","type":"category","url":"/ko/topics/work"},{"id":"post:principles-of-maintaining-code-quality-with-ai","label":"AI가 짠 코드의 품질을 의심하는 법: 1인 개발자를 위한 8가지 검증 원칙","type":"article","url":"/ko/posts/principles-of-maintaining-code-quality-with-ai"},{"id":"post:pmp-pass-review-part-2","label":"PMP 합격 후기 2부: 시험 당일 시간 관리와 마지막 합격 팁","type":"article","url":"/ko/posts/pmp-pass-review-part-2"},{"id":"post:pmp-pass-review-part-1","label":"PMP 합격 후기 1부: 7주 준비와 Study Hall 60%대에서 P…","type":"article","url":"/ko/posts/pmp-pass-review-part-1"},{"id":"post:built-slowly-updated-daily","label":"삶을 기록하는 나만의 방식\n","type":"article","url":"/ko/posts/built-slowly-updated-daily"},{"id":"category:diary","label":"diary","type":"category","url":"/ko/topics/diary"},{"id":"tag:ai 제품 개발","label":"#AI 제품 개발","type":"tag","url":"/ko/tags/ai-"},{"id":"tag:1인 개발","label":"#1인 개발","type":"tag","url":"/ko/tags/1-"},{"id":"tag:mvp","label":"#MVP","type":"tag","url":"/ko/tags/mvp"},{"id":"tag:바이브 코딩","label":"#바이브 코딩","type":"tag","url":"/ko/tags/-"},{"id":"tag:제품 출시","label":"#제품 출시","type":"tag","url":"/ko/tags/-"},{"id":"tag:ai 코딩 원칙","label":"#AI 코딩 원칙","type":"tag","url":"/ko/tags/ai-"},{"id":"tag:코드 품질","label":"#코드 품질","type":"tag","url":"/ko/tags/-"},{"id":"tag:기술 부채","label":"#기술 부채","type":"tag","url":"/ko/tags/-"},{"id":"tag:qa","label":"#QA","type":"tag","url":"/ko/tags/qa"},{"id":"tag:pmp 시험 후기","label":"#PMP 시험 후기","type":"tag","url":"/ko/tags/pmp-"},{"id":"tag:pmp 시간 관리","label":"#PMP 시간 관리","type":"tag","url":"/ko/tags/pmp-"},{"id":"tag:pearson vue","label":"#Pearson VUE","type":"tag","url":"/ko/tags/pearson-vue"},{"id":"tag:pmp 시험 준비물","label":"#PMP 시험 준비물","type":"tag","url":"/ko/tags/pmp-"},{"id":"tag:pmp 합격 팁","label":"#PMP 합격 팁","type":"tag","url":"/ko/tags/pmp-"},{"id":"tag:pmp 합격 후기","label":"#PMP 합격 후기","type":"tag","url":"/ko/tags/pmp-"},{"id":"tag:pmp 공부법","label":"#PMP 공부법","type":"tag","url":"/ko/tags/pmp-"},{"id":"tag:pmi study hall","label":"#PMI Study Hall","type":"tag","url":"/ko/tags/pmi-study-hall"},{"id":"tag:pmp mindset","label":"#PMP Mindset","type":"tag","url":"/ko/tags/pmp-mindset"},{"id":"tag:ai 공부법","label":"#AI 공부법","type":"tag","url":"/ko/tags/ai-"},{"id":"tag:삶의 기록","label":"#삶의 기록","type":"tag","url":"/ko/tags/-"},{"id":"project:attractive-web-ai","label":"AttractiveWebAI","type":"project","url":"/ko/projects/attractive-web-ai"},{"id":"project:dailysay","label":"DailySay","type":"project","url":"/ko/projects/dailysay"},{"id":"glossary:shopify","label":"Shopify","type":"glossary","url":"/ko/glossary/shopify"},{"id":"glossary:pmbok","label":"PMBOK","type":"glossary","url":"/ko/glossary/pmbok"}],"links":[{"source":"post:building-products-alone-with-ai","target":"category:work","label":"same-topic"},{"source":"post:principles-of-maintaining-code-quality-with-ai","target":"category:work","label":"same-topic"},{"source":"post:principles-of-maintaining-code-quality-with-ai","target":"post:building-products-alone-with-ai","label":"expands"},{"source":"post:pmp-pass-review-part-2","target":"category:work","label":"same-topic"},{"source":"post:pmp-pass-review-part-2","target":"post:pmp-pass-review-part-1","label":"continues"},{"source":"post:pmp-pass-review-part-1","target":"category:work","label":"same-topic"},{"source":"post:built-slowly-updated-daily","target":"category:diary","label":"same-topic"},{"source":"post:building-products-alone-with-ai","target":"tag:ai 제품 개발","label":"tagged"},{"source":"post:building-products-alone-with-ai","target":"tag:1인 개발","label":"tagged"},{"source":"post:building-products-alone-with-ai","target":"tag:mvp","label":"tagged"},{"source":"post:building-products-alone-with-ai","target":"tag:바이브 코딩","label":"tagged"},{"source":"post:building-products-alone-with-ai","target":"tag:제품 출시","label":"tagged"},{"source":"post:principles-of-maintaining-code-quality-with-ai","target":"tag:ai 코딩 원칙","label":"tagged"},{"source":"post:principles-of-maintaining-code-quality-with-ai","target":"tag:코드 품질","label":"tagged"},{"source":"post:principles-of-maintaining-code-quality-with-ai","target":"tag:기술 부채","label":"tagged"},{"source":"post:principles-of-maintaining-code-quality-with-ai","target":"tag:1인 개발","label":"tagged"},{"source":"post:principles-of-maintaining-code-quality-with-ai","target":"tag:qa","label":"tagged"},{"source":"post:pmp-pass-review-part-2","target":"tag:pmp 시험 후기","label":"tagged"},{"source":"post:pmp-pass-review-part-2","target":"tag:pmp 시간 관리","label":"tagged"},{"source":"post:pmp-pass-review-part-2","target":"tag:pearson vue","label":"tagged"},{"source":"post:pmp-pass-review-part-2","target":"tag:pmp 시험 준비물","label":"tagged"},{"source":"post:pmp-pass-review-part-2","target":"tag:pmp 합격 팁","label":"tagged"},{"source":"post:pmp-pass-review-part-1","target":"tag:pmp 합격 후기","label":"tagged"},{"source":"post:pmp-pass-review-part-1","target":"tag:pmp 공부법","label":"tagged"},{"source":"post:pmp-pass-review-part-1","target":"tag:pmi study hall","label":"tagged"},{"source":"post:pmp-pass-review-part-1","target":"tag:pmp mindset","label":"tagged"},{"source":"post:pmp-pass-review-part-1","target":"tag:ai 공부법","label":"tagged"},{"source":"post:built-slowly-updated-daily","target":"tag:삶의 기록","label":"tagged"},{"source":"post:built-slowly-updated-daily","target":"project:attractive-web-ai","label":"built with"},{"source":"post:built-slowly-updated-daily","target":"project:dailysay","label":"built with"},{"source":"post:principles-of-maintaining-code-quality-with-ai","target":"glossary:shopify","label":"defines"},{"source":"post:pmp-pass-review-part-1","target":"glossary:pmbok","label":"defines"}]},"memoryTimeline":[{"id":"post-built-slowly-updated-daily","date":"Sat Feb 07","year":2001,"month":2,"week":"2001-W06","kind":"article","title":"삶을 기록하는 나만의 방식\n","description":"일과 프로젝트, 여행과 음식, 그때의 생각까지 기록합니다. 이 블로그는 지나온 경험과 시행착오를 정리하고, 다음 선택을 조금 더 나아지게 만들기 위한 개인 작업 노트입니다.\n","url":"/ko/posts/built-slowly-updated-daily","slug":"built-slowly-updated-daily"},{"id":"post-building-products-alone-with-ai","date":"2026-07-15","year":2026,"month":7,"week":"2026-W29","kind":"article","title":"AI를 활용해 혼자 제품을 만드는 과정: 아이디어에서 출시까지","description":"AI를 리서치, 기획, 개발, 테스트 파트너로 활용해 1인 제품을 아이디어에서 MVP와 실제 출시까지 만드는 현실적인 과정과 원칙을 정리했다.","url":"/ko/posts/building-products-alone-with-ai","slug":"building-products-alone-with-ai"},{"id":"post-principles-of-maintaining-code-quality-with-ai","date":"2026-07-13","year":2026,"month":7,"week":"2026-W29","kind":"article","title":"AI가 짠 코드의 품질을 의심하는 법: 1인 개발자를 위한 8가지 검증 원칙","description":"AI 코딩 도구로 AttractiveWebAI, Shopify 앱 등을 개발하며 겪은 10가지 실패와, 동작하는 것처럼 보이는 'UI 착시'를 극복하고 코드 품질을 지키기 위한 8가지 현실적인 원칙을 공유합니다.","url":"/ko/posts/principles-of-maintaining-code-quality-with-ai","slug":"principles-of-maintaining-code-quality-with-ai"},{"id":"post-pmp-pass-review-part-2","date":"2026-07-05","year":2026,"month":7,"week":"2026-W28","kind":"article","title":"PMP 합격 후기 2부: 시험 당일 시간 관리와 마지막 합격 팁","description":"Pearson VUE 센터에서 PMP 시험을 치른 실제 경험과 첫 60문제 시간 관리, 10분 쉬는 시간, 시험 직전 오답 복습 및 준비물을 정리했다.","url":"/ko/posts/pmp-pass-review-part-2","slug":"pmp-pass-review-part-2"},{"id":"post-pmp-pass-review-part-1","date":"2026-07-03","year":2026,"month":7,"week":"2026-W27","kind":"article","title":"PMP 합격 후기 1부: 7주 준비와 Study Hall 60%대에서 PASS까지","description":"2026년 7월 3일 PMP 시험에 합격하기까지 7주 동안 온라인 강의, PMI Study Hall, 오답노트, GPT와 NotebookLM을 활용한 공부 과정을 정리했다.","url":"/ko/posts/pmp-pass-review-part-1","slug":"pmp-pass-review-part-1"},{"id":"milestone-travel-tokyo","date":"2026-04-12","year":2026,"month":4,"week":"2026-W16","kind":"travel","title":"도쿄 봄 여행 및 워케이션","description":"시부야와 신주쿠에서 로컬 에스프레소 바와 테크 스타트업 오피스를 탐방하고 스트리트 사진을 촬영했습니다."},{"id":"milestone-started-dailysay","date":"2026-01-10","year":2026,"month":1,"week":"2026-W02","kind":"project","title":"DailySay 프로젝트 착수","description":"다국어로 개발 지식과 일상을 동기화하는 커먼플레이스 북 개발에 착수했습니다.","url":"/ko/projects/started-dailysay"},{"id":"project-attractive-web-ai","date":"2026-01-01","year":2026,"month":1,"week":"2026-W01","kind":"project","title":"AttractiveWebAI","description":"손으로 그린 와이어프레임과 목업을 멀티모달 AI 모델을 활용해 즉시 인터랙티브하고 현대적인 프론트엔드 코드로 변환해 주는 플랫폼입니다.","url":"/ko/projects/attractive-web-ai","slug":"attractive-web-ai"},{"id":"project-dailysay","date":"2026-01-01","year":2026,"month":1,"week":"2026-W01","kind":"project","title":"DailySay","description":"생각, 프로젝트, 여행 로그 및 이정표를 유기적으로 연결하기 위해 디자인된 깔끔하고 미니멀한 개인 지식 플랫폼이자 커먼플레이스 북(Commonplace Book)입니다.","url":"/ko/projects/dailysay","slug":"dailysay"},{"id":"project-first-run","date":"2026-01-01","year":2026,"month":1,"week":"2026-W01","kind":"project","title":"FirstRun","description":"매일의 실외 러닝을 기록하고, 러닝화의 마일리지를 추적하며, 헬스 텔레메트리 데이터를 동기화하는 모바일 러닝 전용 애플리케이션입니다.","url":"/ko/projects/first-run","slug":"first-run"},{"id":"milestone-career-pm","date":"2025-08-01","year":2025,"month":8,"week":"2025-W31","kind":"career","title":"TechCorp AI 제품 리드 합류","description":"자율형 에이전트 인프라 설계, 언어 모델 가이드라인 정립 및 디스커버리 업무를 총괄하기 시작했습니다."}],"philosophy":[{"slug":"ai","title":"AI","belief":"AI는 판단의 대체가 아니라 시스템 사고를 위한 레버리지다.","evolution":[{"year":2024,"statement":{"en":"Prompt craft felt like the whole game.","ko":"프롬프트 솜씨가 전부처럼 느껴졌다.","es":"El arte del prompt parecía el juego completo."}},{"year":2025,"statement":{"en":"Agents and workflows matter more than single prompts.","ko":"단일 프롬프트보다 에이전트와 워크플로가 중요하다.","es":"Los agentes y flujos importan más que un solo prompt."}},{"year":2026,"statement":{"en":"Maintainable AI systems beat clever one-offs.","ko":"유지 가능한 AI 시스템이 영리한 일회성보다 낫다.","es":"Los sistemas de IA mantenibles vencen a los trucos ingeniosos."}}],"articles":["building-products-alone-with-ai","principles-of-maintaining-code-quality-with-ai"]},{"slug":"projects","title":"프로젝트","belief":"작게 출시하고, 공개적으로 배우며, 시스템을 살아 있게 유지한다.","evolution":[{"year":2024,"statement":{"en":"Side projects were experiments.","ko":"사이드 프로젝트는 실험이었다.","es":"Los side projects eran experimentos."}},{"year":2025,"statement":{"en":"Products need discovery discipline.","ko":"제품에는 디스커버리 규율이 필요하다.","es":"Los productos necesitan disciplina de discovery."}},{"year":2026,"statement":{"en":"A personal knowledge system is itself a lifelong project.","ko":"개인 지식 시스템 자체가 평생 프로젝트다.","es":"Un sistema de conocimiento personal es un proyecto de por vida."}}],"articles":["building-products-alone-with-ai","built-slowly-updated-daily"]},{"slug":"life","title":"삶","belief":"여행과 고요한 날이 내가 만드는 방식을 벼린다.","evolution":[{"year":2024,"statement":{"en":"Work and life felt separate lanes.","ko":"일과 삶이 분리된 차선처럼 느껴졌다.","es":"Trabajo y vida parecían carriles separados."}},{"year":2026,"statement":{"en":"Context from places belongs in the knowledge garden.","ko":"장소에서 얻은 맥락은 지식 정원에 속한다.","es":"El contexto de los lugares pertenece al jardín del conocimiento."}}],"articles":["built-slowly-updated-daily"]},{"slug":"learning","title":"학습","belief":"기억하려고 쓰고, 이해하려고 개정한다.","evolution":[{"year":2024,"statement":{"en":"Consume more, ship less.","ko":"더 많이 소비하고 덜 출시했다.","es":"Consumir más, publicar menos."}},{"year":2025,"statement":{"en":"Structured study (PMP) taught deliberate practice.","ko":"구조화된 학습(PMP)이 의도적 연습을 가르쳤다.","es":"El estudio estructurado (PMP) enseñó práctica deliberada."}},{"year":2026,"statement":{"en":"A digital garden compounds learning across years.","ko":"디지털 정원은 수년에 걸쳐 학습을 복리로 쌓는다.","es":"Un jardín digital acumula aprendizaje a lo largo de los años."}}],"articles":["pmp-pass-review-part-1","pmp-pass-review-part-2"]},{"slug":"career","title":"커리어","belief":"PM의 기술은 디스커버리·딜리버리·시스템을 잇는 일이다.","evolution":[{"year":2025,"statement":{"en":"Exam credentials proved baseline discipline.","ko":"시험 자격은 기본 규율을 증명했다.","es":"Las credenciales de examen probaron disciplina base."}},{"year":2026,"statement":{"en":"AI-native PM is the next operating system for product work.","ko":"AI 네이티브 PM이 제품 업무의 다음 OS다.","es":"El PM nativo de IA es el próximo sistema operativo del producto."}}],"articles":["pmp-pass-review-part-1","pmp-pass-review-part-2"]},{"slug":"travel","title":"여행","belief":"장소는 내가 제품에 던지는 질문을 바꾼다.","evolution":[{"year":2026,"statement":{"en":"Tokyo workation notes belong beside engineering essays.","ko":"도쿄 워케이션 노트는 엔지니어링 에세이 옆에 속한다.","es":"Las notas de workation en Tokio pertenecen junto a ensayos de ingeniería."}}],"articles":[]}],"thinkingEvolution":[{"slug":"prompt-to-systems","title":{"en":"From prompts to systems","ko":"프롬프트에서 시스템으로","es":"De prompts a sistemas"},"topic":"ai","stages":[{"year":2024,"label":{"en":"2024","ko":"2024","es":"2024"},"thought":{"en":"Better prompts would unlock better products.","ko":"더 나은 프롬프트가 더 나은 제품을 열 것이라 생각했다.","es":"Mejores prompts desbloquearían mejores productos."},"relatedPosts":[],"posts":[]},{"year":2025,"label":{"en":"2025","ko":"2025","es":"2025"},"thought":{"en":"Agents and tool protocols matter more than clever wording.","ko":"영리한 문장보다 에이전트와 도구 프로토콜이 중요하다.","es":"Los agentes y protocolos de herramientas importan más que la redacción ingeniosa."},"reason":{"en":"Building real workflows showed prompt-only thinking hit a ceiling.","ko":"실제 워크플로를 만들며 프롬프트만으로는 한계가 보였다.","es":"Construir flujos reales mostró el techo del pensamiento solo-prompt."},"relatedPosts":["mcp-usb-c-of-ai-applications","ai-agents-workflow-evolution"],"posts":[]},{"year":2026,"label":{"en":"2026 → Current","ko":"2026 → 현재","es":"2026 → Actual"},"thought":{"en":"The end of prompt engineering is the start of maintainable AI architecture.","ko":"프롬프트 엔지니어링의 끝은 유지 가능한 AI 아키텍처의 시작이다.","es":"El fin del prompt engineering es el inicio de una arquitectura de IA mantenible."},"reason":{"en":"Shipping alone with AI made quality gates and systems the real craft.","ko":"혼자 AI로 출시하며 품질 게이트와 시스템이 진짜 기술임을 알았다.","es":"Publicar solo con IA hizo de las puertas de calidad y los sistemas el verdadero oficio."},"relatedPosts":["the-end-of-prompt-engineering","principles-of-maintaining-code-quality-with-ai","building-products-alone-with-ai"],"posts":[{"slug":"principles-of-maintaining-code-quality-with-ai","title":"AI가 짠 코드의 품질을 의심하는 법: 1인 개발자를 위한 8가지 검증 원칙"},{"slug":"building-products-alone-with-ai","title":"AI를 활용해 혼자 제품을 만드는 과정: 아이디어에서 출시까지"}]}]},{"slug":"pm-and-ai","title":{"en":"PM craft meets AI automation","ko":"PM 역량과 AI 자동화","es":"Oficio de PM y automatización con IA"},"topic":"career","stages":[{"year":2025,"label":{"en":"2025","ko":"2025","es":"2025"},"thought":{"en":"PMP discipline is about process rigor and exam readiness.","ko":"PMP 규율은 프로세스 엄격함과 시험 준비다.","es":"La disciplina PMP es rigor de proceso y preparación para el examen."},"relatedPosts":["pmp-pass-review-part-1","pmp-pass-review-part-2"],"posts":[{"slug":"pmp-pass-review-part-1","title":"PMP 합격 후기 1부: 7주 준비와 Study Hall 60%대에서 PASS까지"},{"slug":"pmp-pass-review-part-2","title":"PMP 합격 후기 2부: 시험 당일 시간 관리와 마지막 합격 팁"}]},{"year":2026,"label":{"en":"2026 → Current","ko":"2026 → 현재","es":"2026 → Actual"},"thought":{"en":"Every PM should learn AI automation to multiply discovery and delivery.","ko":"모든 PM은 디스커버리와 딜리버리를 증폭하기 위해 AI 자동화를 배워야 한다.","es":"Todo PM debería aprender automatización con IA para multiplicar discovery y delivery."},"reason":{"en":"Credential study gave structure; AI tools gave leverage on real product work.","ko":"자격 학습이 구조를 주고, AI 도구가 실제 제품 업무에 레버리지를 주었다.","es":"El estudio de credenciales dio estructura; las herramientas de IA dieron apalancamiento."},"relatedPosts":["every-pm-should-learn-ai-automation"],"posts":[]}]},{"slug":"solo-building","title":{"en":"Building alone with AI","ko":"AI와 혼자 만들기","es":"Construir solo con IA"},"topic":"projects","stages":[{"year":2025,"label":{"en":"2025","ko":"2025","es":"2025"},"thought":{"en":"Speed of generation is the main advantage.","ko":"생성 속도가 핵심 이점이다.","es":"La velocidad de generación es la ventaja principal."},"relatedPosts":["how-i-built-three-products-faster-with-ai"],"posts":[]},{"year":2026,"label":{"en":"2026 → Current","ko":"2026 → 현재","es":"2026 → Actual"},"thought":{"en":"Speed without memory is noise—DailySay exists so work compounds.","ko":"기억 없는 속도는 소음이다—DailySay는 일이 복리로 쌓이게 하려고 존재한다.","es":"La velocidad sin memoria es ruido—DailySay existe para que el trabajo se acumule."},"reason":{"en":"Three fast products taught that continuity and revision beat one-shot shipping.","ko":"세 개의 빠른 제품이 연속성과 개정이 일회성 출시보다 낫다는 것을 가르쳤다.","es":"Tres productos rápidos enseñaron que continuidad y revisión vencen al envío de un solo tiro."},"relatedPosts":["built-slowly-updated-daily","building-products-alone-with-ai"],"posts":[{"slug":"built-slowly-updated-daily","title":"삶을 기록하는 나만의 방식\n"},{"slug":"building-products-alone-with-ai","title":"AI를 활용해 혼자 제품을 만드는 과정: 아이디어에서 출시까지"}]}]}],"knowledgeHealth":{"overallScore":82,"articles":[{"slug":"built-slowly-updated-daily","title":"삶을 기록하는 나만의 방식\n","score":72,"freshness":56,"completeness":100,"references":0,"brokenLinks":0,"missingImages":false,"outdatedTechnology":false,"confidence":75,"issues":[]},{"slug":"building-products-alone-with-ai","title":"AI를 활용해 혼자 제품을 만드는 과정: 아이디어에서 출시까지","score":82,"freshness":99,"completeness":100,"references":80,"brokenLinks":2,"missingImages":false,"outdatedTechnology":false,"confidence":40,"issues":["Missing relationship target: how-i-built-three-products-faster-with-ai","Missing relationship target: every-pm-should-learn-ai-automation"]},{"slug":"principles-of-maintaining-code-quality-with-ai","title":"AI가 짠 코드의 품질을 의심하는 법: 1인 개발자를 위한 8가지 검증 원칙","score":82,"freshness":98,"completeness":100,"references":50,"brokenLinks":1,"missingImages":false,"outdatedTechnology":false,"confidence":40,"issues":["Missing relationship target: how-i-built-three-products-faster-with-ai"]},{"slug":"pmp-pass-review-part-1","title":"PMP 합격 후기 1부: 7주 준비와 Study Hall 60%대에서 PASS까지","score":83,"freshness":96,"completeness":100,"references":55,"brokenLinks":1,"missingImages":false,"outdatedTechnology":false,"confidence":55,"issues":["Missing relationship target: every-pm-should-learn-ai-automation"]},{"slug":"pmp-pass-review-part-2","title":"PMP 합격 후기 2부: 시험 당일 시간 관리와 마지막 합격 팁","score":90,"freshness":96,"completeness":100,"references":55,"brokenLinks":0,"missingImages":false,"outdatedTechnology":false,"confidence":75,"issues":[]}],"generatedAt":"2026-07-18T20:09:51.426Z"},"monthlyReflection":{"month":"2026-07","whatChanged":["Published or updated: AI를 활용해 혼자 제품을 만드는 과정: 아이디어에서 출시까지","Published or updated: AI가 짠 코드의 품질을 의심하는 법: 1인 개발자를 위한 8가지 검증 원칙","Published or updated: PMP 합격 후기 2부: 시험 당일 시간 관리와 마지막 합격 팁","Published or updated: PMP 합격 후기 1부: 7주 준비와 Study Hall 60%대에서 PASS까지"],"whatLearned":["Recurring focus: 1인 개발","Recurring focus: AI 제품 개발","Recurring focus: MVP","Captured in writing: AI를 활용해 혼자 제품을 만드는 과정: 아이디어에서 출시까지","Captured in writing: AI가 짠 코드의 품질을 의심하는 법: 1인 개발자를 위한 8가지 검증 원칙","Captured in writing: PMP 합격 후기 2부: 시험 당일 시간 관리와 마지막 합격 팁"],"whatObsolete":["No strong obsolescence signals this month."],"whatShouldUpdate":["Core articles look relatively fresh."],"suggestedRevisions":[],"postsThisMonth":[{"slug":"building-products-alone-with-ai","title":"AI를 활용해 혼자 제품을 만드는 과정: 아이디어에서 출시까지"},{"slug":"principles-of-maintaining-code-quality-with-ai","title":"AI가 짠 코드의 품질을 의심하는 법: 1인 개발자를 위한 8가지 검증 원칙"},{"slug":"pmp-pass-review-part-2","title":"PMP 합격 후기 2부: 시험 당일 시간 관리와 마지막 합격 팁"},{"slug":"pmp-pass-review-part-1","title":"PMP 합격 후기 1부: 7주 준비와 Study Hall 60%대에서 PASS까지"}]},"insights":{"totalPosts":5,"postsThisMonth":4,"topTopics":[{"topic":"work","count":4},{"topic":"diary","count":1}],"topTags":[{"tag":"1인 개발","count":2},{"tag":"AI 제품 개발","count":1},{"tag":"MVP","count":1},{"tag":"바이브 코딩","count":1},{"tag":"제품 출시","count":1},{"tag":"AI 코딩 원칙","count":1},{"tag":"코드 품질","count":1},{"tag":"기술 부채","count":1}],"knowledgeGaps":["travel","food","projects"],"mostConnectedSlug":"building-products-alone-with-ai","mostConnectedTitle":"AI를 활용해 혼자 제품을 만드는 과정: 아이디어에서 출시까지","fastestGrowingTopic":"work","writingTrend":[{"month":"2026-02","count":1},{"month":"2026-07","count":4}]},"reading":[{"id":"attention-paper","type":"paper","title":"Attention Is All You Need","author":"Vaswani et al. (Google Brain)","progress":100,"finished":true,"coverImage":"/images/placeholder-post.jpg","favoriteQuotes":{"en":["\"The dominant sequence transduction models are based on complex recurrent or convolutional neural networks...\""],"ko":["\"주요 시퀀스 변환 모델들은 복잡한 순환 신경망이나 컨볼루션 신경망을 기반으로 하고 있습니다...\""],"es":["\"Los modelos de transducción de secuencia dominantes se basan en redes neuronales recurrentes o convolucionales complejas...\""]},"notes":{"en":"The seminal paper that introduced the Transformer architecture, replacing RNNs and CNNs with self-attention mechanisms.","ko":"RNN과 CNN을 완전히 자체 주의(self-attention) 메커니즘으로 대체하며 트랜스포머 아키텍처의 포문을 연 기념비적인 논문입니다.","es":"El artículo fundamental que introdujo la arquitectura Transformer."}},{"id":"clean-architecture-book","type":"book","title":"Clean Architecture","author":"Robert C. Martin (Uncle Bob)","progress":85,"finished":false,"coverImage":"/images/placeholder-post.jpg","favoriteQuotes":{"en":["\"The only way to go fast, is to go well.\""],"ko":["\"빨리 가는 유일한 방법은 제대로 가는 것이다.\""],"es":["\"La única forma de ir rápido es ir bien.\""]},"notes":{"en":"A deep dive into software design principles, component boundaries, and decoupling strategies to maintain codebases over years.","ko":"소프트웨어 설계 원칙, 컴포넌트 경계 설계, 수년에 걸쳐 코드를 우아하게 유지하기 위한 디커플링 전략을 설명합니다.","es":"Una inmersión profunda en los principios de diseño de software y límites de componentes."}},{"id":"lex-fridman-podcast","type":"podcast","title":"Lex Fridman Podcast: Andrej Karpathy","author":"Lex Fridman","progress":100,"finished":true,"coverImage":"/images/placeholder-post.jpg","notes":{"en":"An insightful discussion on building software 2.0, the training dynamics of large neural networks, and the future of Tesla Autopilot.","ko":"소프트웨어 2.0 패러다임, 신경망 학습 역학, 테슬라 오토파일럿의 진화 방향성에 관한 심도 깊은 인터뷰입니다.","es":"Una discusión perspicaz sobre la construcción de software 2.0 y el entrenamiento de redes neuronales."}}]}