바이브코더를 위한 PM 이론 + 하네스 구축하기

한 줄 핵심

바이브 코딩 시대의 PM 역할을 목표·요구사항·일정·문서·의사결정으로 재해석하고, AI가 스스로 예측·실측·회고하게 만드는 하네스 구축법까지 연결해 보여주는 영상이다.

시간별 요약

1. 0:00
   시작 대기 짧은 인사만 오간 도입부로, 본격적인 강의 내용은 아직 시작되지 않는다.
2. 16:58
   인사 — 오늘 주제: 바이브코더를 위한 PM AI가 실무를 대신하는 시대일수록 사람에게 남는 것은 목표 설정과 책임이며, 그 역할을 PM 역량으로 설명하겠다고 예고한다. 강의는 'The Art of Project Management'를 교재로 삼되, 책을 읽지 않아도 이해할 수 있게 구성된다.
3. 19:04
   교재 소개 PM은 프로젝트 매니저로서 실무를 직접 하기보다 프로젝트 성공을 관찰하고 조율하는 역할로 정의된다. 비전문가가 전문가를 관리하고 검토하는 기술이라는 점이 바이브 코딩의 상황과 겹친다.
4. 21:02
   PM이란 — AI 시대에 사람에게 남는 건 목표와 책임 PM은 목표를 세우고 실무가 그 목표에서 벗어나지 않도록 점검하며, 기한 안에 성과가 나도록 책임지는 역할이다. AI가 실무를 수행하는 구조에서는 사람이 해야 할 일이 바로 이 PM적 판단과 관리라고 정리한다.
5. 25:41
   이 강의에서 가져갈 두 가지 이 강의에서 얻을 핵심은 개발을 잘 몰라도 AI를 관리하는 법과 프로젝트를 기획·요구사항으로 정리하는 법이다. 책의 문장들은 바이브 코딩에서 문서와 스펙을 다루는 방식과도 매우 잘 맞는다고 설명한다.
6. 27:00
   풀스택 펀더멘탈 강의 · 이너서클 3기 소개 무료로 제공되는 풀스택 펀더멘탈 강의와 AI 실무자 커뮤니티 이너서클 3기를 소개한다. 개발 지식과 안목을 기초부터 쌓고 싶은 사람, AI 워크플로우와 팀 빌딩을 공유하고 싶은 사람을 대상으로 안내한다.
7. 30:19
   오늘 다룰 목차 PM의 역할, 일정 관리, 비전 문서, 목표 구조, 아이디어 발굴, 스펙 작성, 의사결정, 실습과 하네스 구축까지 넓게 다룰 예정임을 미리 정리한다. 바이브 코딩 프로젝트를 운영할 때 필요한 주제를 한 번에 묶어 설명하는 구성이다.
8. 33:13
   좋은 PM은 비즈니스·기술·고객 세 관점의 균형을 잡는다 PM은 비즈니스, 기술, 고객 세 관점을 모두 이해하고 충돌할 때 중간지대에서 조율해 결론을 내리는 사람이다. 어느 한 관점만 강하면 프로젝트가 실패할 수 있으므로, 이 균형 감각이 PM의 핵심 역량이라고 설명한다.
9. 40:03
   일정은 원래 안 맞는다 — 예측하고 회고하기 일정은 원래 확률적이어서 틀릴 수 있으며, 중요한 것은 틀린 사실 자체가 아니라 왜 틀렸는지 회고하는 일이다. 일정 실패 기록은 다음 계획의 정확도를 높이는 데이터가 된다.
10. 44:10
    AI에게 일정 예측을 시키고, 틀리면 하네스를 보강한다 AI에게 먼저 일정 예측을 시키고 실제 결과와 비교해 차이를 분석한 뒤, 틀린 이유를 반영해 하네스를 고도화하는 방식이 제안된다. 예측 실패는 단순한 오답이 아니라 컨텍스트 부족이나 설계 문제를 드러내는 신호로 본다.
11. 51:04
    요구사항 → 예측 → 수행 → 실측 구조 요구사항을 준 뒤 예측을 먼저 받고, 그다음 수행하고, 마지막에 실측해 비교하는 흐름이 관리의 기본 구조로 제시된다. 예측이 틀렸다면 요구사항 자체가 모호했는지까지 역으로 점검할 수 있어, 설계와 맥락 품질이 함께 좋아진다.
12. 54:51
    비전 문서 — 가장 먼저 쓰는 문서 비전 문서는 팀이 프로젝트 내내 같은 목표를 보게 만드는 첫 문서이며, 방향성과 철학만 담고 구체적 구현은 빼야 한다. 모든 내용을 한 문서에 몰아넣지 말고 레이어를 나누어 관리해야 문서의 집중력이 유지된다.
13. 57:07
    목표의 세 계층: 비즈니스·팀·개인 목표는 회사 전체의 비즈니스 목표, 특정 팀의 목표, 개인이 책임지는 목표로 나누어 관리해야 한다. 실무에서는 상위 목표와 하위 목표가 각기 다른 문서와 계층에 들어가며, 이것이 PM의 관리 단위가 된다.
14. 1:01:11
    SMART 목표와 '반대를 위한 반대' 목표는 SMART 기준처럼 구체적이고 측정 가능하며 현실적이고 기한이 있어야 한다. 목표를 다 달성해도 실패할 수 있는 경우를 역으로 상정해 보는 방식이 빠진 전제를 찾아내는 데 유용하다.
15. 1:07:02
    프로젝트 아이디어는 고객이 겪는 문제에서 출발한다 아이디어는 막연한 상상보다 고객이 실제로 겪는 문제, 가능하면 고객의 원문 표현에서 출발해야 한다. 문제를 충분히 수집하고 나서야 빠른 프로토타입으로 검증할 수 있다.
16. 1:10:05
    좋은 스펙을 쓰는 법 좋은 스펙은 모든 것을 적는 문서가 아니라 방향을 명확히 하고 모호한 지점을 해소하는 문서다. 무엇을 할지뿐 아니라 무엇을 하지 않을지도 적어야 AI와 사람이 같은 방향을 보게 된다.
17. 1:12:03
    의사결정과 소통 — AI에게 지시하는 법 되돌릴 수 있는 결정은 빨리 내리고, 되돌릴 수 없는 결정만 신중하게 다뤄야 한다. AI에게는 작업을 시키기 전에 이해한 내용을 먼저 브리핑하게 하면 지시 오해를 크게 줄일 수 있다.
18. 1:17:32
    실습 — 실제 앱 프로젝트를 Claude Code로 열기 실제 앱 프로젝트를 Claude Code로 열어 작업하고, 워크트리는 필요할 때만 쓰는 편이 낫다는 실무 팁을 공유한다. 이후 문서 구조와 지침을 점검하며 PM 이론을 프로젝트에 적용할 준비를 시작한다.
19. 1:19:07
    프로젝트 문서 구조 살펴보기 프로젝트 루트의 문서 구조를 살펴보며 CLAUDE.md와 하위 문서들의 역할을 확인한다. 루트에는 핵심 비전과 개요만 두고, 세부 지침은 더 적절한 위치로 분리하는 것이 바람직하다고 본다.
20. 1:23:07
    루트 지침 다이어트: CLAUDE.md → AGENTS.md 루트 레벨 지침이 너무 비대하면 인식과 관리가 비효율적이므로, CLAUDE.md 대신 AGENTS.md로 정리하고 내용도 더 잘게 분리해야 한다. 언제나 반드시 알아야 하는 정보만 루트에 두고, 나머지는 계층적으로 내려보내는 것이 핵심이다.
21. 1:26:03
    Q&A — 개발자가 존경하는 PM 존경받는 PM의 특징으로 개발자 출신의 기술 감각, 리스크를 짚는 능력, 추진력과 행동력을 꼽는다. 프로젝트 흐름을 놓치지 않고 귀찮은 조율 일을 대신 처리해 주는 점이 특히 크게 평가된다.
22. 1:36:05
    여러 세션이 동시에 작업할 때 충돌 막기 여러 세션이 동시에 같은 파일을 고치면 충돌이 쉽게 나므로, 작업 위치와 책임 범위를 명확히 나누어야 한다. 문서와 상태 파일을 한곳에 몰아넣지 않고 구조적으로 분리하는 것이 충돌 방지의 출발점이다.
23. 1:45:12
    작업 예측 하네스 만들기 — 30·50·80% 세 가지 예측 작업을 시작하기 전에 30%, 50%, 80% 세 가지 확률 기준으로 예측을 받는 하네스를 설계한다. 예측 결과와 실측을 기록하고, 그 오차 원인을 분석해 다음 예측 정확도를 높이는 루프가 핵심이다.
24. 1:59:03
    AI가 내놓은 첫 예측 보기 AI는 초기 작업을 15분, 45분 등으로 예측하며, 예측 근거와 더 정확한 판단을 돕는 요소를 추가로 묻는 과정이 이어진다. 느리더라도 근거를 들여다보는 예측이 중요하고, 빠른 모델만으로는 충분하지 않다는 점이 드러난다.
25. 2:12:24
    오늘 배운 비전문서·문제기술문을 프로젝트에 넣기 오늘 배운 내용 중 비전 문서와 고객 문제 기술문을 실제 프로젝트에 반영해 보려 한다. 고객의 문제를 그들의 언어로 적고, 그 문서에서 아이디어와 상세 명세를 뽑는 구조를 적용한다.
26. 2:17:22
    예측보다 빨리 끝났다 — 결과 확인 예측보다 실제 작업이 빨리 끝났고, 예측을 먼저 잘 세우도록 요구하니 작업 속도도 좋아졌다고 본다. AI가 한 작업의 체감 속도와 실제 예측 품질 사이의 관계를 다시 확인하는 장면이다.
27. 2:26:45
    하네스 엔진 설명 — 예측·실측 장부로 스스로 고치는 구조 하네스는 사람이 지시하면 AI가 예측하고, 수행하고, 검증한 뒤 예측과 실측의 차이를 장부에 남기는 구조다. 이 기록을 바탕으로 에이전트 루프가 스스로 하네스를 개선하며, 사람은 방향과 기록 체계만 관리하면 된다.
28. 2:35:02
    Q&A — 빠른 모델을 워크플로 의사결정에 쓰나 빠르기만 하고 에이전틱하게 쓰기 어려운 모델은 워크플로 자동화의 핵심 도구로는 애매하다고 평가한다. 오늘 강의는 다소 추상적이었지만, 다음에는 더 실전적인 개발 접목 사례를 다루겠다고 마무리한다.
29. 2:41:12
    마무리 오늘 라이브는 여기서 마무리하며, 시청에 대한 감사 인사를 전한다. 다음에는 바이브 코딩에 더 직접적으로 연결되는 자료로 돌아오겠다고 예고한다.

실무 인사이트

• 바이브 코딩에서 PM 역량은 '무엇을 만들지'보다 '무엇을 어떻게 검증하고 책임질지'를 정하는 능력으로 재해석하는 것이 가장 실용적이다.
• AI에게 일을 맡길수록 일정 예측과 실측 비교를 자동화해야 하며, 그 오차 기록이 곧 모델과 하네스를 개선하는 학습 데이터가 된다.
• 루트 문서는 비전과 핵심 규칙만 남기고 세부는 계층화해야 AI도 사람도 같은 맥락을 더 안정적으로 따라갈 수 있다.