https://www.youtube.com/watch?v=dpJ7-hhja1Q
description: |-
1. 이건 꼭 알아야 한다[^1]
[? 질문] 한국인들이 AI로 코딩할 때 효율이 크게 떨어지는 대표적 원인은 무엇인가[^2]
[= 답] 맥락 설명 없이 곧바로 일을 시키고 질문하기 때문에, AI가 의도와 요구사항을 제대로 정렬하지 못한 채 산으로 가고(재작업 발생), 사용자는 흐름을 통제하지 못해 비효율이 커진다.[^2][^9]
[? 질문] AI 코딩 효율을 결정하는 것은 “어떤 AI를 쓰느냐”인가, “어떻게 쓰느냐”인가[^6]
[= 답] 효율은 모델 자체보다 **AI를 사용하는 방식(프로세스/규칙/운영법)**에서 나오며, 그 최적 방식은 실제로 여러 시간 실험(노가다)을 통해 찾아야 한다.[^6][^7]
[? 질문] 1인 개발자가 AI로 코딩할 때, “세 배 빨라지게” 만드는 실전 작업 순서는 무엇인가[^3]
[= 답] AI에게 일을 ‘그냥’ 시키지 말고, (1) PRD 생성 규칙 → (2) 테스크 생성 규칙 → (3) 테스크 실행 규칙의 “쓰리 파일 시스템(Three-file system)”으로 규칙을 먼저 세팅한 뒤 단계적으로 진행한다.[^3][^10][^17]
[? 질문] 바이브 코딩 중 “AI가 코딩하는 걸 멍하니 지켜보느라” 사람이 피곤해지는 문제는 어떻게 해결하는가[^25]
[= 답] 기다리지 말고 알림을 받도록 시스템을 구성한다. MCP로 슬랙 메시지 전송을 연결하고, 코딩 완료 시 슬랙 알림(필요하면 음성 알림)으로 통지받아 그때만 확인한다.[^25][^33][^35]
2. 큰 그림[^3]
이 콘텐츠는 1인 개발자가 AI 코딩 도구(예: Claude Code)를 사용할 때, 작업을 무작정 던지지 않고 규칙 기반의 단계적 프로세스로 전환해 효율과 정확도를 끌어올리는 방법을 설명한다.[^3][^10] 또한 바이브 코딩 중 사용자가 “지켜보며 대기”하느라 소모되는 에너지를 줄이기 위한 **슬랙 알림 기반 워크플로우(MCP 활용)**를 함께 소개한다.[^25][^33]
- 효율의 본질은 도구 선택이 아니라 운영 방식이다: 어떤 모델을 쓰는지보다, AI에게 일을 시키는 “규칙과 절차”가 생산성을 좌우한다.[^6][^10]
- 쓰리 파일 시스템으로 “요구사항 → 할 일 분해 → 한 번에 하나씩 실행”을 강제하면, AI가 산으로 가는 것을 막고 검수/통제가 쉬워진다.[^12][^17][^20]
- 대기 피로를 제거해야 지속 가능하다: AI가 일하는 동안 사용자는 다른 일을 하고, 완료 시 알림으로 호출받는 구조가 장시간 작업에서 특히 유효하다.[^25][^38]
3. 하나씩 살펴보기[^1]
3.1 “효율을 망치는 습관”: 맥락 없이 바로 시키기[^2]
화자는 한국인들이 AI로 코딩할 때 효율을 “가장 망치는” 방식이 있다고 문제를 제기한다.[^2] 그것은 충분한 맥락 설명 없이 곧바로 일을 시키고 질문하는 것이다.[^2]
즉, 사용자는 “빨리 결과를 얻고 싶다”는 마음으로 AI에게 곧장 코딩 지시를 내리지만, AI 입장에서는 목적/범위/제약/우선순위가 모호하니 결과가 자주 빗나가고, 그 뒤에 수정과 재지시가 반복되면서 오히려 느려진다는 전제를 깔고 있다.[^2][^9]
동시에 화자는 여기서 흔히 드는 반론(또는 심리)을 짚는다: “맥락을 다 설명하면 답답하고 효율이 낮아질 것 같다”는 느낌이다.[^3]
하지만 콘텐츠의 핵심 주장은 반대로, 특정한 3단계를 밟으면 결과적으로 세 배는 빨라질 수 있다는 것이다.[^3]
[!IMPORTANT] 맥락 제공은 ‘장황한 설명’이 아니라 ‘프로세스화된 규칙’으로 해결한다[^3] 화자가 제안하는 해결은 그냥 길게 설명을 늘어놓는 것이 아니라, AI가 따라야 할 규칙 파일 3개를 만들어 맥락/계획/실행을 구조화하는 방식이다.[^10][^17]
3.2 “어떤 AI가 아니라 어떻게 AI를 쓰는가”: 라이언 카슨 사례로 문제의식 고정[^4]
화자는 “라이언 카슨(Ryan Carson)”을 소개한다.[^4]
라이언은 코딩으로 세 개의 회사를 창업해 매각한 연쇄 창업가이며, 세 번째 회사는 매출이 100억 이상이었다고 언급된다.[^5] 이로써 화자는 “검증된 실전가”의 경험담을 가져와 자신의 방법론을 정당화한다.[^5]
이어서 라이언의 핵심 발언을 인용한다:
[h 효율은 어떤 AI를 쓰는지가 아니라, 어떻게 AI를 쓰는지에서 나온다][^6]
즉 모델 교체(예: A 모델 vs B 모델) 자체보다, 동일한 모델이라도 “일 시키는 방식”에 따라 결과가 극적으로 달라진다는 관점을 강조한다.[^6]
또한 라이언은 “가장 효율적인 방법을 알아내는 방법”에 대해, 몇 시간씩 노가다(직접 실험)를 하며 찾아내는 수밖에 없다고 말한다.[^7] 이는 “정답 프롬프트 하나”가 온라인에 떠돌아다니는 식의 접근과 대비된다.[^7]
그 다음 화자는 자신의 위치(전산학을 공부한 서울대 교수 관점)에서 라이언이 실험으로 찾아낸 방식을 요약해 주겠다고 선언한다.[^8]
3.3 쓰리 파일 시스템 개요: “일을 시키는 규칙” 3개를 먼저 만든다[^10]
본격적으로 라이언이 말하는 시스템의 핵심은, AI에게 일을 그냥 던지는 것이 아니라 AI에게 일을 시키는 ‘룰/규칙’을 세 개 만든다는 것이다.[^10]
여기서 중요한 포인트는 “규칙을 파일로 만들어” 반복 가능한 운영체계로 만든다는 점이다.[^10][^11]
화자는 이 시스템을 구성하는 3개 파일을 순서대로 제시한다.[^11][^16]
-
- PRD 생성 규칙 파일[^11]
-
- 테스크 생성 규칙 파일[^16]
-
- 테스크 실행 규칙 파일[^19]
이 구조는 뒤에서 화자가 “AI는 단계로 나눠서 시키면 더 잘한다”는 직관, 그리고 체인 오브 소트/디바이드 앤 컨커 같은 전산학적 비유로 다시 정당화된다.[^22][^23]
3.4 1단계: PRD 생성 규칙 파일 — 요구사항을 먼저 ‘청사진’으로 고정[^11]
화자는 첫 번째 파일을 “PRD 생성 규칙 파일”이라고 부른다.[^11] 그리고 여기서 PRD가 무엇인지 묻고 설명한다.[^12]
[? 질문] PRD란 무엇인가[^12]
[= 답] PRD는 **제품 요구 사항 명세서(Product Requirements Document)**로, 최종 소프트웨어가 “어떤 기능을 가진 어떤 형태여야 하는지”를 미리 청사진처럼 써놓은 문서다.[^12][^13]
PRD를 미리 만드는 이유는 명확하다.
[h PRD 파일을 미리 만들면 AI가 중간에 산으로 가는 것을 방지할 수 있다][^14]
즉, 요구사항이 문서로 고정되어 있으면 AI가 구현 중 해석을 제멋대로 확장/축소하기 어렵고, 사용자는 결과를 PRD와 대조해 “맞는지/틀린지”를 판단할 기준을 얻는다.[^14]
3.4.1 PRD를 ‘어떻게 만들지’까지 규칙으로 만든다[^15]
라이언은 AI에게 “PRD를 이런 방식으로 만들어라”라고 지시하는 규칙 자체를 미리 작성해 두었다고 한다.[^15]
화자는 이 규칙 파일이 “진짜 디테일하다”고 평가한다.[^16]
그 디테일의 예시가 구체적으로 제시된다:
- 독자 수준 지정: “이 PRD는 주니어 개발자도 이해할 수 있게 써줘”라고 콕 집어 말한다.[^16]
그러면 AI는 어려운 말을 피하고 쉽게 풀어쓰는 방향으로 PRD를 작성하게 된다.[^17] - 바로 작성 금지 + 선질문 강제: PRD를 곧바로 쓰지 말고 “이거 만들려면 몇 가지 질문이 있는데 먼저 답해 달라”고 사용자에게 묻게 한다.[^18]
즉, PRD 작성 전 필요한 정보를 AI가 선제적으로 수집하도록 설계한다.[^18] - 질문 구조화(번호 매기기): 질문도 뒤죽박죽되지 않도록 2.1, 2.2처럼 번호를 붙여서 물어보라고 지시한다.[^19]
이는 사용자가 답변을 구조적으로 달 수 있게 하고, AI도 누락 없이 정보를 받도록 하는 장치다.[^19]
화자는 이러한 규칙 설계를 두고 “굉장히 꼼꼼하죠?”라고 반응하며, 핵심이 ‘프롬프트 한 줄’이 아니라 ‘프롬프트 운영 규칙의 설계’임을 강조한다.[^20]
[!TIP] PRD 규칙 파일에 넣을 핵심 장치 3가지[^16]
- PRD의 **독자(주니어 개발자)**를 지정한다.[^16]
- PRD 작성 전에 필수 질문을 먼저 하게 한다.[^18]
- 질문을 번호로 구조화해 대화의 질서를 만든다.[^19]
3.5 2단계: 테스크 생성 규칙 파일 — PRD를 “실제 할 일 목록”으로 쪼갠다[^16]
두 번째 파일은 “테스크 생성 규칙 파일”이다.[^16]
흐름은 다음과 같다:
- 앞 단계에서 만든 PRD를 AI에게 제공한다.[^17]
- AI에게 “이 PRD를 보고 개발에 필요한 테스크 목록을 만들어라”고 지시한다.[^17]
여기서 화자는 의도를 명확히 풀어 말한다:
[h PRD 기획서를 보고 실제 할 일을 AI가 다 알아서 쪼개 주도록 하는 것][^18]
즉 기획(요구사항)과 실행(작업 항목)을 분리하고, PRD를 기준으로 작업 분해(WBS 유사)를 시키는 단계다.[^18]
3.5.1 체크박스 마크다운 강제: “진행 관리”를 AI 작업 흐름에 내장[^19]
이 단계에서 중요한 규칙이 하나 더 나온다.
AI가 테스크 목록을 만들 때 마크다운 파일에 체크박스 형식으로 작성하게 하라는 지시다.[^19]
화자는 체크박스를 예시로 직접 언급하며(“이렇게 생긴 체크박스요”), 이렇게 해야 하는 이유를 설명한다.[^20]
[= 체크박스여야 나중에 AI가 하나하나 체크하면서 일을 할 수 있기 때문][^20]
즉, 체크박스는 단지 사람이 보기 좋으라고 쓰는 게 아니라, AI에게도 ‘완료 상태’를 기록하고 다음 액션으로 넘어가는 인터페이스가 된다.[^20]
[!NOTE] 2단계의 산출물은 “할 일 목록”이 아니라 “실행 가능한 진행판”에 가깝다[^19] 마크다운 체크박스는 이후 3단계(테스크 실행)에서 “하나 끝날 때마다 체크”를 강제하는 기반이 된다.[^20][^21]
3.6 3단계: 테스크 실행 규칙 파일 — 한 번에 하나씩, 매번 승인받고, 체크한다[^19]
화자는 “마지막 세 번째 파일이 중요한데요”라고 말하며, 세 번째를 테스크 실행 규칙 파일로 제시한다.[^19]
여기서의 문제의식은 AI의 전형적 행동으로 설명된다:
AI가 의욕이 넘쳐서 한 번에 모든 걸 다 하려고 한다는 것이다.[^20]
그래서 “그걸 못 하게 막는” 규칙이 필요하다고 한다.[^20]
3.6.1 실행 규칙의 구체 명령 3종 세트[^21]
실행 규칙 파일이 포함하는 지시는 매우 구체적인 운영 프로토콜이다:
- “아까 만든 테스크 목록을 보고 코딩을 시작해라.”[^21]
- “근데 한 번에 딱 하나씩만 해라.”[^21]
- “하나 끝날 때마다 멈춰서 나에게 허락을 받고, 다 했으면 체크박스에 표시를 해라.”[^21]
이 규칙의 효과를 화자는 작업 장면으로 묘사한다.
AI가 코딩하는 동안 사용자는 멍때리고 구경하는 게 아니라, “잠깐 거기까지 내가 한번 보고 오케이, 다음 거 해”처럼 중간중간 적극적으로 명령을 내릴 수 있게 된다.[^22]
다시 말해, 사용자는:
- 단계별로 결과를 확인(검수)하고[^23]
- 다음 단계 진행을 승인하며[^23]
- AI가 혼자 흥분해서 방향을 틀거나 과도하게 확장하는 것을 막는다.[^23]
이로써 “AI를 위한 규칙 세 개”를 만들어 체계적으로 일을 시키면, 더 효율적이고 정확하게 바이브 코딩할 수 있다는 결론을 낸다.[^24]
3.7 화자의 코멘트: 단계화는 AI/전산학 관점에서도 자연스럽다[^24]
화자는 이 시스템을 보고 “이렇게도 할 수 있구나”라고 느꼈다고 말한다.[^24]
그리고 AI는 “항상 뭔가를 단계로 나눠서 시키면 더 잘하는 것 같다”는 경험적 관찰을 덧붙인다.[^25]
이어서 두 가지 연결 고리를 제시한다:
- 체인 오브 소트(Chain-of-thought): 요즘 추론형 모델들이 계획을 세우고 단계별로 해결하는 방식과 유사하다는 언급.[^26]
- 전산학 알고리즘의 디바이드 앤 컨커(Divide and Conquer): 큰 문제를 나눠 해결하는 접근과 닮았다는 비유.[^27]
3.7.1 “프롬프트를 만드는 프롬프트”: 화자 자신의 사례[^28]
화자는 자신의 경험도 예로 든다. “논문 읽게 앱”을 만들며 번역 시퀀스를 짤 때,
번역을 위한 프롬프트를 만드는 프롬프트를 사용했다는 것이다.[^28]
즉, “직접 번역 프롬프트를 한 번에 만들기”보다, “좋은 번역 프롬프트를 생성하는 절차”를 먼저 만들었다는 식의 메타-프롬프팅을 언급한다.[^28][^29]
그리고 이런 식으로 단계적으로 뭔가를 하는 프롬프트를 만드는 프롬프트가 장기적으로 더 좋다고 평가한다.[^29]
마지막으로, 화자는 라이언의 쓰리 파일 시스템을 나중에 자신도 해보겠다고 말하며 1부를 마무리한다.[^30]
3.8 두 번째 팁: “멍하니 대기”를 없애서 피곤하지 않게 바이브 코딩하기[^31]
화자는 두 번째로 전할 팁이 “피곤하지 않게 바이브 코딩하는 팁”이라고 전환한다.[^31] 그리고 이것이 “최근에 해보고 사용하는 방법”이라고 밝힌다.[^31]
문제 상황은 매우 구체적이다:
- 화자는 클로드 코드가 혼자 열심히 코딩하는 모습을 멍하니 지켜보는 게 피곤하다고 말한다.[^32]
- 하루 종일 바이브 코딩을 하면 에너지가 빠지고 녹초가 될 때가 있다고 한다.[^32]
여기서 화자는 자기 자신에게 던지는 질문을 구성한다:
[? 질문] 코딩은 클로드 코드가 했는데 왜 내가 피곤한가[^33]
[= 답] 내가 실제로는 클로드 코드가 코딩하는 과정을 가만히 지켜보고 있기 때문이다.[^33]
화자는 “보고 있으면 꽤 재밌다”고도 말한다.[^34] AI가 생각을 이리저리 하며 코딩하는 모습이 신기하다는 것이다.[^34]
하지만 그 재미가 결과적으로는 에너지를 빨아먹는 형태가 된다고 느낀다.[^34][^35]
3.8.1 비유: 주식/코인 차트를 멍하니 보는 것과 유사[^35]
화자는 과거 경험을 떠올린다. 주식과 코인을 “아주 조금” 할 때, 차트를 멍하니 바라보던 경험과 유사하다고 말한다.[^35]
핵심은 “사실 그걸 꼭 보고 있을 필요가 없는데 자꾸 보게 된다”는 점이다.[^36] 그리고 그 상태는 에너지가 계속 소모된다는 것이다.[^37]
그래서 결론은 간단한 깨달음으로 나온다: “아, 보지 말아야겠다.”[^38]
3.9 기다리지 않는 구조 만들기: ‘끝나면 연락’하도록 설계[^39]
하지만 곧바로 현실적인 제약이 나온다.[^39]
클로드 코드가 다 끝나면 결과 확인도 해야 하고, 다음 명령도 내려야 한다.[^39]
그렇다면 안 보고 다른 일을 하다가 완료 시점을 놓치면 시간이 낭비될 수 있다는 우려를 제기한다.[^40]
그래서 화자는 해결책을 다음처럼 정의한다:
[c 내가 기다릴 게 아니라, 클로드 코드가 다 끝나면 나한테 연락하게 해야 한다][^41]
이 목적을 위해 MCP를 써봐야겠다고 말한다.[^41]
3.10 MCP 설명: 바이브 코딩 툴에 ‘외부 기능/서비스’를 붙이는 연결 레이어[^42]
화자는 MCP가 무엇인지 설명한다.[^42]
[= MCP는 바이브 코딩 툴들이 외부 기능이나 서비스를 쓸 수 있도록 연결해 주는 것][^42]
더 많은 일을 할 수 있도록 “손발을 달아주는 것”이라는 비유를 쓴다.[^43]
즉 여기서는 MCP를 “슬랙 알림”과 연결하는 접착제로 사용한다.[^42][^44]
3.11 슬랙 메시지 알림 시스템 구축 절차 (단계별) — 실제로 이렇게 했다[^44]
화자는 자신이 실제로 구성한 과정을 순서대로 나열한다.[^44]
- 슬랙 가입 후 워크스페이스 생성[^44]
- 워크스페이스 안에 채널 생성[^45]
- 그 채널에 메시지를 포스팅할 수 있는 URL 주소를 받음[^46]
- 클로드 코드에서 간단한 MCP 형식으로 해당 주소를 등록[^47]
claude.md(클로드.md)에 규칙을 넣을 수 있으므로, 코딩이 길어지면 끝나고 슬랙 메시지를 달라고 적어둠[^48]
여기까지가 “완료 통지”의 기본 루프(클로드 코드 → 슬랙 메시지)다.[^44][^48]
3.11.1 음성 알림까지: 11 Labs + 안드로이드 알림음 교체[^49]
화자는 여기에 한 단계 더해, 완료 알림을 더 확실히 체감하도록 만든다.[^49]
- 11 Labs에서 “코딩이 완료되었습니다”라고 말하는 간단한 MP3를 만든다.[^49]
- 다운로드해서 안드로이드 폰의 notifications 폴더에 넣는다.[^50]
- 슬랙 앱에서 해당 채널의 알림음을 이 메시지(해당 음성 MP3)로 바꾸면 완성.[^51]
단, 알림음 교체는 안드로이드에서만 되는 것 같다고 제한사항을 덧붙인다.[^52]
3.12 적용 후 워크플로우: AI 작업 중 나는 다른 일을 한다[^53]
이 설정이 끝나면, 클로드 코드가 오랫동안 일하고 있을 때 사용자는 다른 일을 해도 된다고 말한다.[^53]
예시로 화자는:
- 수업 준비[^54]
- 연구[^54]
- 가벼운 운동[^54]
등을 들고, 폰에서 알림이 오면 그때 가서 확인하면 된다고 정리한다.[^55]
이어서 실제 알림 음성이 재생되는 장면(“코드가 완료되었습니다”)과 화자의 반응(“코드가 다 된 것 같은데요”)이 들어간다.[^56][^57]
3.13 추가 코멘트: “슬랙 MCP 서버”가 따로 있었지만, 미니멀 권한이 오히려 장점[^58]
화자는 나중에 알고 보니 슬랙 MCP 서버가 따로 있더라고 말한다.[^58]
그걸 쓰면 더 간단했을 것 같지만, 어차피 자체 MCP 코드를 작성하는 것도 복잡하지 않았다고 한다.[^59]
그리고 결과적으로 “만족한다”고 평가한다.[^60]
특히 보안/권한 관점의 해석이 흥미로운데, 특정 채널에 메시지만 보낼 수 있는 최소한의 권한만 준 것이므로 “미니멀한 디자인” 같다고 말한다.[^61]
3.14 마무리 정리 + ‘나누기’라는 메타 주제 확장[^62]
화자는 오늘 다룬 내용을 다시 명시한다:
- 효율적인 바이브 코딩을 위한 라이언 카슨의 쓰리 파일 시스템[^62]
- 멍하니 기다리지 않고 다른 일을 할 수 있게 하는 슬랙 메시지 시스템[^63]
이어서 자신의 배경을 짧게 소개한다. 전산학 박사를 받았고, 현재는 유전체 분석 일을 하며 알고리즘 개발을 한다고 말한다.[^64]
그래서 통계학, 머신러닝, 생물학 등 다양한 분야를 공부해야 한다는 맥락을 제공한다.[^65]
이 뒤에는 영상의 주제를 “작업을 어떻게 나눌 것인가”라는 더 일반적인 문제로 확장한다.[^66]
- 어떤 일이 있을 때 작은 파트로 나눌지 말지가 중요하다고 느낀다.[^66]
- 전통적인 통계학은 “두 개가 관련이 있는지 없는지” 측정/판별에 특화되어 있고, 예로 유전자가 질병을 일으키는지 여부를 든다.[^67][^68]
- 하지만 어떤 상황에서는 관련성 판단이 아니라 큰 무언가를 나누는 것이 더 중요할 때도 있다고 말한다.[^69]
- 예로 “유전자 전체로 모아야 하느냐, 두 그룹/세 그룹으로 나누어야 하느냐” 같은 문제를 든다.[^70]
- 그런데 전통 통계학은 이런 “나누는 것”을 판별할 때 큰 도움이 안 될 때가 많고, 오히려 머신러닝의 클러스터링 등을 써야 할 때가 많다고 한다.[^71][^72]
이 이야기를 꺼낸 이유를 직접 밝힌다:
[? 질문] 왜 통계학/머신러닝의 ‘나누기’ 얘기를 하는가[^73]
[= 답] 어떤 것을 나눌지 말지를 결정하는 건 매우 어려운 문제인데, 라이언 카슨이 “바이브 코딩을 3단계로 나누면 좋다”는 경험을 공유한 것이 그만큼 도움이 된다는 점을 말하기 위해서다.[^73][^74]
그리고 “두 단계도 아니고 다섯 단계도 아니고” 실제로 해보니 세 단계가 굉장히 최적화되더라는 경험을 우리에게 나눠 준 것이라고 해석한다.[^75]
결론적으로, 이런 얘기를 듣고 각자 상황에 맞게 적용하면 코딩 효율이 많이 좋아질 거라고 말하며 마무리한다.[^76]
마지막으로 시청 감사, 구독 안내(바이브 코딩으로 수익화까지 가며 얻은 팁/정보 제공), “모두 성공”, 감사 인사로 끝낸다.[^77][^78]
4. 핵심 통찰[^6]
- [c AI 코딩의 생산성은 “모델 성능”보다 “프로세스 설계(규칙/단계/검수)”에서 더 크게 갈린다][^6][^10]
- 행동: 작업 시작 전, 최소한 PRD/테스크/실행 규칙의 골격을 파일로 만들어 반복 사용한다.[^10][^21]
- [h PRD는 ‘길게 쓰는 문서’가 아니라 ‘산으로 가지 않게 하는 기준선’이다][^14]
- 행동: PRD를 먼저 고정하고, AI가 PRD 작성 전 필요한 질문을 하게 만들어 정보 누락을 줄인다.[^18][^19]
- [h 테스크는 체크박스로 만들 때 비로소 “관리 가능한 실행 단위”가 된다][^19][^20]
- 행동: 테스크 산출물을 마크다운 체크박스로 강제해, AI가 완료 표시/진행 제어를 하도록 만든다.[^19][^21]
- [c “한 번에 하나씩 + 매번 승인”은 AI의 과속(과도한 확장/오해)을 막는 안전장치다][^21][^23]
- 행동: 실행 규칙에 “1개 작업 후 멈춤, 사용자 승인 후 다음, 체크박스 업데이트”를 명문화한다.[^21]
- [h 바이브 코딩의 숨은 비용은 ‘대기/관전’으로 인한 사용자 피로다][^32][^35]
- 행동: MCP/슬랙 알림으로 완료 통지를 받아, 그때만 검수/다음 지시를 내리는 구조로 바꾼다.[^41][^55]
- [m “나누기”는 코딩뿐 아니라 연구/분석 전반의 어려운 의사결정이며, 최적 분할은 경험적으로 발견되는 경우가 많다][^73][^75]
- 행동: 내 작업에서도 단계 수/분할 기준을 실험적으로 조정하고, 가장 재작업이 적은 분할을 찾는다.[^7][^75]
5. 헷갈리는 용어 정리 (해당 시에만)[^12]
PRD: 제품 요구 사항 명세서. 최종 소프트웨어가 가져야 할 기능/형태를 미리 청사진처럼 기술한 문서.[^12][^13]
테스크(Task): PRD를 구현하기 위해 수행해야 할 구체적인 작업 단위(할 일) 목록.[^17][^18]
체인 오브 소트(Chain-of-thought): 추론형 모델이 계획을 세우고 단계적으로 문제를 해결하는 방식(화자가 단계적 접근의 비유로 언급).[^26]
디바이드 앤 컨커(Divide and Conquer): 큰 문제를 작은 문제로 나눠 해결하는 알고리즘적 사고(단계화의 비유).[^27]
MCP: 바이브 코딩 툴이 외부 기능/서비스를 쓰도록 연결해 주는 메커니즘(“손발을 달아준다”는 비유로 설명).[^42][^43]
Claude Code(클로드 코드): 화자가 사용하는 바이브 코딩 도구로, 코딩을 수행하는 AI 에이전트로 언급됨.[^32][^33]
클러스터링(Clustering): 데이터를 여러 그룹으로 나누는 머신러닝 기법. 전통 통계학이 약한 “나누기” 문제에서 자주 활용된다고 언급.[^71][^72]
참고(콘텐츠 정보)[^1]
- 제목: 1인개발자를 위한 AI 코딩 작업순서 3단계[^1]
- 채널: 서울대 한범 교수의 AI 바이브코딩[^1]
- 길이: 8분 1초[^1]
- 링크: https://www.youtube.com/watch?v=dpJ7-hhja1Q[^1]
[^1]: 유튜브 영상 메타데이터(사용자 제공): "1인개발자를 위한 AI 코딩 작업순서 3단계", 채널 "서울대 한범 교수의 AI 바이브코딩", 길이 "8분 1초", https://www.youtube.com/watch?v=dpJ7-hhja1Q [^2]: @[00:00] "한국인들이 AI로 코딩할 때 효율성을 가장 망치는 거는요." / @[00:03] "맥락 설명 없이 바로 일을 시키고 질문하는 거예요." [^3]: @[00:08] "맥락을 다 설명하면 답답하고 효율이 낮아질 것 같지만이 세 가지 단계를 밟는다면 세 배는 빨라질 겁니다." [^4]: @[00:15] "라이언 카슨 아시나요?" [^5]: @[00:18] "코딩으로 세 개의 회사를 창업해서 매각한 연쇄 창업가인데요." / @[00:21] "세 번째 회사의 매출이 100억 이상..." [^6]: @[00:27] "효율은 어떤 AI를 사용하는지가 아니라 어떻게 AI를 사용하는지에서 나온다고요." [^7]: @[00:32] "가장 효율적인 방법을 알아내는 거는 몇 시간씩 노가다 하면서 직접 실험하는 방법밖에 없다는 거죠." [^8]: @[00:38] "라이언이 직접 노가다해 알아낸 쓰일 방식을 ... 요약해 드릴게요." [^9]: @[00:46] "라이언이 말하는 쓰일 시스템의 핵심은요." [^10]: @[00:49] "AI한테 그냥 일을 시키는게 아니라 AI한테 일을 시키는 룰, 규칙을 세 개 만드는 거예요." [^11]: @[00:55] "첫 번째 파일은 PRD 생성 규칙 파일입니다." [^12]: @[00:57] "여러분들 PRD라는 거 아세요?" [^13]: @[01:02] "제품 요구 사항 명세서인데요." / @[01:07] "최종 소프트웨어가 어떤 기능을 가진 어떤 형태여야..." [^14]: @[01:12] "PRD 파일을 미리 만들면 AI가 중간에 산으로 가는 거를 방지..." [^15]: @[01:17] "라이언은 AI한테 PRD를 이런 방식으로 만들어라... 규칙을 미리 짜두었습니다." [^16]: @[01:22] "라이언의 규칙 파일을 보면 진짜 디테일한데요. ... 주니어 개발자도 이해할 수 있게..." [^17]: @[01:27] "그럼 AI가 어려운 말은 안 쓰고 쉽게 풀어서 써 주겠죠." [^18]: @[01:34] "PRD를 바로 쓰지 말고 ... 먼저 답해 주세요라고 사용자한테 물어보게..." [^19]: @[01:40] "질문도 ... 2.1 2.2 ... 번호를 붙여서 물어보라고..." / @[02:04] "마크다운 ... 체크박스 형식으로..." [^20]: @[02:12] "그래야 나중에 AI가 하나하나 체크하면서 일을 할 수가 있으니까요." [^21]: @[02:26] "테스크 목록 코딩을 시작해라." / @[02:27] "한 번에 딱 하나씩만 해라." / @[02:32] "멈춰서 나한테 허락 받고 ... 체크박스..." [^22]: @[02:37] "AI가 코딩하고 있을 때 ... 내가 한번 보고 오케이, 다음 거 해." [^23]: @[02:49] "AI가 혼자서 신나서 산으로 가는 거를 막고 내가 한 단계 한 단계 검수..." [^24]: @[02:54] "규칙 세 개를 만들어서 ... 훨씬 효율적으로 정확하게..." / @[02:59] "저도 이걸 보면서..." [^25]: @[03:04] "AI의 경우에 항상 뭔가를 단계로 나눠서 시키면..." / @[03:42] "피곤하지 않게 바이브 코딩하는 팁..." [^26]: @[03:12] "체인 오브 thought도 결국 계획을 세워서 단계별로..." [^27]: @[03:16] "디바이드 앤 컨커랑도 되게 닮았어요." [^28]: @[03:20] "논문일게 앱 ... 번역 시퀀스를 짤 때요." / @[03:24] "번역을 위한 프롬프트를 만드는 프롬프트..." [^29]: @[03:31] "단계적으로 ... 프롬프트를 만드는 프롬프트를 짜서 하는게..." [^30]: @[03:34] "저도 ... 쓰리파일 시스템을 나중에 한번 해 봐야겠습니다." [^31]: @[03:38] "두 번째로 ... 팁은요." [^32]: @[03:53] "클로드 코드가 ... 멍한히 지켜보고 있는게 되게 피곤..." / @[03:57] "녹초..." [^33]: @[04:02] "코딩은 ... 했는데 왜 내가 피곤하지?" / @[04:06] "가만히 지켜보고 있더라고요." [^34]: @[04:11] "이게 보고 있으면 꽤 재밌어요." / @[04:15] "신기하기도..." [^35]: @[04:19] "에너지가 빨리는 경험..." / @[04:24] "주식과 코인 ... 차트를 멍히 바라보고..." [^36]: @[04:28] "사실 그걸 꼭 보고 있을 필요가 없거든요." [^37]: @[04:36] "에너지가 계속 소모되는 거예요." [^38]: @[04:40] "아, 보지 말아야겠다." [^39]: @[04:42] "근데 ... 결과 확인도 해야 ... 다음 명령도..." [^40]: @[04:48] "AI는 이미 다 끝났는데 ... 놓치면 시간이 가고..." [^41]: @[04:53] "내가 기다릴게 아니라 ... 연락을 하도록..." / @[04:59] "그래서 MCP를..." [^42]: @[05:02] "MCP라는 거는요." [^43]: @[05:05] "외부의 기능이나 서비스를 ... 연결" / @[05:08] "손발을 달아..." [^44]: @[05:11] "슬랙에 가입 ... 워크스페이스..." [^45]: @[05:14] "채널을 하나 만들고요." [^46]: @[05:16] "메시지를 포스팅할 수 있는 URL..." [^47]: @[05:19] "클로드 코드에 ... MCP 형식으로 ... 등록" [^48]: @[05:24] "클로드.md ... 규칙들을 넣을 수..." / @[05:29] "끝나고 슬랙 메시지..." [^49]: @[05:33] "11 랩스 ... '코딩이 완료되었습니다'... MP3" [^50]: @[05:39] "다운받아서 ... 안드로이드 폰 ... 노티피케이션스 폴더..." [^51]: @[05:44] "슬랙 앱 ... 알림음을 ... 바꿔 주면 완성" [^52]: @[05:47] "이렇게 알림음 바꾸는 거는 안드로이드에서만..." [^53]: @[05:52] "이제 ... 오랫동안 일하고 있을 때 저는 다른 일을 해도 됩니다." [^54]: @[05:55] "수업 준비 ... 연구 ... 가벼운운동..." [^55]: @[05:58] "폰에서 ... 가서 확인하면..." [^56]: @[06:03] "코드가 완료되었습니다." [^57]: @[06:04] "어, 코드가 다 된 것 같은데요." [^58]: @[06:09] "슬랙 MCP 서버가 따로 있더라고요." [^59]: @[06:12] "조금 더 간단... 어차피 자체 MCP 코드 작성..." [^60]: @[06:18] "만족합니다." [^61]: @[06:22] "특정한 채널의 메시지만 ... 최소한의 권한만..." / @[06:25] "미니멀한 디자인" [^62]: @[06:25] "오늘은 ... 쓰리일 시스템..."(발음상 '쓰리 파일 시스템' 맥락) / @[06:31] "알아보았고요" [^63]: @[06:31] "슬랙 메시지 시스템도 소개..." [^64]: @[06:35] "전산학 박사를 받았지만 유전체 분석..." [^65]: @[06:45] "통계학, 머신 러닝, ... 생물학 등 다양한 분야..." [^66]: @[06:49] "항상 ... 어떤 거를 작은 파트로 나눌지 말지..." [^67]: @[06:54] "전통적인 통계학 ... 두 개가 관련이 있는지..." [^68]: @[06:58] "예를 들면 유전자가 질병을 일으키느냐..." [^69]: @[07:02] "근데 어떨 때는 ... 큰 무언가를 나누는게 중요..." [^70]: @[07:06] "유전자 전체로 ... 두 그룹 세 그룹으로..." [^71]: @[07:10] "전통계약(통계학)은 ... 나누는 거 ... 도움 안 될 때..." [^72]: @[07:20] "머신 러닝에 클러스터링..." [^73]: @[07:23] "왜 이런 말씀을 드리냐면요." [^74]: @[07:25] "어떤 거를 나눌지 말지를 결정하는게 ... 어려운 문제..." [^75]: @[07:37] "두 단계도 아니고 ... 세 단계가 ... 최적화..." [^76]: @[07:43] "우리 상황에 잘 맞게 ... 적용하면 코딩의 효율..." [^77]: @[07:49] "감사드립니다... 구독하시면..." [^78]: @[07:56] "감사합니다."