유튜브 AI 팁 보고서 — 2026-08-13 — 코딩

오늘의 영상 4편 (전부 최근 6개월 이내: 2026-02~04월 업로드) · 누적: 팁 46개 / 다룬 영상 27편
※ 오늘 두 번째 호입니다 — 아침 호(주제 자동화)에 이어 코딩(바이브코딩) 편입니다.

오늘은 수확이 유난히 좋았습니다. 4편 중 3편이 서로 독립적으로 같은 결론에 도달했기 때문입니다 — 코드를 쓰기 전에 무엇을 쓸지를 문서로 못박아라. 한국 개발자(김플립), 전 구글 시니어 엔지니어(Maddy Zhang), 그리고 카파시가 각자의 언어로 같은 말을 합니다. 서로 인용하지 않는 세 사람이 같은 처방에 도달했다는 사실 자체가, 이것이 유행이 아니라 수렴점이라는 증거입니다.

한눈에 (TL;DR)

• 계획을 내가 승인하기 전엔 코드를 한 줄도 못 쓰게 한다. 그리고 그 계획은 채팅창이 아니라 plan.md 파일에 있어야 한다 — 세션이 죽어도, 컨텍스트가 압축돼도 파일은 살아남으니까.
• "아직 구현하지 마"를 매번 명시적으로 써라. 이 한 문장이 빠지면 AI가 혼자 "이 정도면 충분하지" 판단하고 코딩을 시작한다. 주도권을 넘기는 지점이 정확히 여기다.
• 검증을 사람이 아니라 시스템에 맡겨라. 할 일 목록 안에 "스크린샷 찍고 확인" 단계를 심고, hooks로 빌드·테스트·타입체크를 매 편집 후 자동 실행시킨다. 자리를 비웠다 돌아왔을 때 에러 더미가 아니라 초록 CI를 보게 된다.
• 카파시의 경계선: 바이브코딩은 바닥을 올리는 일, 에이전틱 엔지니어링은 기존 품질 바를 지키면서 빨라지는 일. 후자에선 "AI가 짰다"가 취약점의 변명이 되지 않는다.

오늘의 팁

1. 계획을 내가 승인하기 전엔 코드를 한 줄도 쓰게 하지 마라

• 방법: 워크플로우 전체를 관통하는 단 하나의 원칙으로 삼는다. 순서는 코드 리서치 → 계획 작성 → 주석 달기(최소 1회 이상 반복) → 구현 → 피드백 반복. 간단한 작업이라면 이 단계를 건너뛰어도 된다.
• 왜: 삽질이 사라지고, 아키텍처 결정권이 내 손에 남고, 코드부터 들이받는 것보다 토큰도 적게 쓰면서 결과물이 좋아진다. 영상 화자는 "작업이 조금이라도 복잡해지는 순간 (계획 없는 방식은) 결과물이 완전히 무너진다. 아직 안 무너져 봤다면 그 수준의 복잡도를 아직 안 만나본 것"이라고 단언한다.
• 출처: 찐 개발자의 바이브 코딩은 다릅니다 — 김플립 · LLM 코딩 (~00:55)
• 보정: "MCP·스킬·팀 에이전트는 다 부차적"이라는 이 영상의 단정은 과합니다. 오늘의 다른 세 영상은 그것들에서 실질적 이득을 보고하고 있고, 특히 서브에이전트·검증 하네스는 계획 원칙과 경쟁하는 게 아니라 보완합니다.

2. 리서치를 채팅창이 아니라 research.md 파일에 쓰게 하라

• 방법: 의미 있는 작업은 전부 코드베이스 정독부터 시작한다. 프롬프트 예문 그대로:

  "이 폴더를 깊이 읽고 어떻게 동작하는지 깊이 이해하고 모든 세부 사항을 파악해라. 끝나면 상세 리서치 보고서를 작성해라."
  "알림 시스템을 매우 상세히 연구하고, 알림이 어떻게 작동하는지 모든 것을 담은 리서치 MD를 작성해라."
  ★ "깊이" "매우 상세히" "세부 사항"이라는 단어가 실제로 작동한다. 이 단어들 없이 시키면 파일 하나 읽고 함수 시그니처 수준에서 "아, 이런 거구나" 하고 넘어간다.

• 왜: 화자가 꼽는 AI 코딩에서 가장 비싼 실패는 문법 에러도 로직 버그도 아니다. 그 자체로는 멀쩡히 돌아가는데 주변 시스템을 슬금슬금 망가뜨리는 구현 — 기존 레이어를 완전히 무시하는 함수, ORM 관리를 고려 안 한 마이그레이션, 이미 있는 로직을 그대로 중복한 API 엔드포인트. 리서치 단계가 이걸 막는다.
• 출처: 같은 영상 (~01:37)

3. 내장 플랜 모드 대신 자체 plan.md 파일을 써라

• 방법: 리서치를 검토한 뒤, 별도 마크다운 파일에 상세 구현 계획을 쓰게 한다.

  "…를 위한 상세 플랜 MD를 작성해 줘. 코드 스니펫도 포함. 변경 사항을 작성하기 전에 소스 파일을 읽고 실제 코드베이스를 기반으로 계획을 작성해."
  결과물에는 접근 방식 설명, 실제 변경을 보여주는 코드 스니펫, 수정될 파일 경로, 고려사항·트레이드오프가 담긴다.

• 왜 내장 플랜 모드가 아닌가: ①에디터에서 직접 편집할 수 있고 ②원하는 위치에 인라인 메모를 달 수 있고 ③프로젝트 안에 실제 산출물로 남고 ④컨텍스트가 압축되든 세션이 죽든 파일은 원본 그대로 살아남는다. 채팅창에 흘러가는 플랜과는 완전히 다르다.
• 출처: 같은 영상 (~03:16)
• 보정: 오늘 다른 두 영상(Nate Herk 7번, Maddy Zhang)은 내장 플랜 모드를 적극 권장합니다. 정면 충돌입니다 — 다만 자세히 보면 반대 이유가 아니라 강도의 차이입니다. 내장 플랜 모드도 계획을 세우지만, 그 계획이 파일로 남지 않는다는 점이 김플립의 불만입니다. 카파시도 같은 자리에서 "플랜 모드 자체보다 더 일반적인 것이 있다 — 에이전트와 함께 아주 상세한 스펙/문서를 설계하고 그걸 에이전트가 쓰게 하는 것"이라고 말해, 이쪽 손을 들어줍니다.

4. 플랜 문서에 인라인 메모를 달고 "아직 구현하지 마"를 매번 붙여라

• 방법: 사이클은 클로드가 plan.md 작성 → 내가 에디터에서 문서 안에 직접 메모 추가 → 다시 보냄 → 계획 갱신 → 만족할 때까지 반복. 되돌려 보낼 때의 문장:

  "문서에 몇 가지 메모를 추가했어. 모든 메모를 반영하고 문서를 업데이트해. 아직 구현하지 마."

★ 마지막 문장이 없으면 클로드가 "이 정도면 계획 충분하지" 하고 혼자 판단하는 순간 바로 코드를 짜기 시작한다. 내가 괜찮다고 할 때까지 절대 충분한 게 아니다.

메모의 종류(실제 예문):
- 잘못된 가정 교정 — "아니 이건 PUT이 아니라 PATCH여야 해"
- 접근 통째 거부 — "이 부분 제거해. 여기는 캐싱이 필요 없어"
- 이유 설명 — "부모가 재시도를 처리하니까 이 재시도 로직은 중복이야. 제거하고 그냥 실패하게 둬"
- 방향 전환 — "이거 틀렸어. visibility 필드는 개별 아이템이 아니라 리스트 자체에 있어야 해. 스키마 섹션을 그에 맞게 재구조화해"
- 지금 안 할 것 쳐내기 — "다운로드 기능은 계획에서 빼. 지금 안 만들 거야"
- 건드리면 안 되는 선 — "이 세 함수의 시그니처는 절대 바꾸면 안 돼. 라이브러리가 호출자에 맞추는 게 아니라 호출자가 맞춰야 해"
- 기술 선택 — "그 모델 말고 이 모델 써" / "그거 직접 만들지 말고 라이브러리에 이미 있는 메서드 써"

메모 길이는 두 단어("선택 사항 아님")부터 한 문단까지 천차만별.
- 왜: 화자는 이걸 shared mutable state 패턴이라 부른다. 채팅창에서 이것저것 설명하는 게 아니라 문서의 정확한 위치를 가리키며 수정 사항을 직접 적는 것 — 에이전트 코딩에서 가장 실용적인 인간주도 루프.
- 출처: 같은 영상 (~04:30, ~11:06 요약)

5. 구현 명령은 세션마다 재사용하는 표준 프롬프트로 정제하라

• 방법: 계획이 준비되면 매번 같은 문장을 쓴다.

  "전부 구현해라. 작업이나 단계를 완료하면 계획 문서에서 완료로 표시해라. 모든 작업과 단계가 완료될 때까지 멈추지 마라. any 타입을 쓰지 마라. 지속적으로 타입 체크를 실행해서 새로운 문제를 만들지 마라."

• 왜: 이 시점엔 모든 결정이 이미 내려지고 검증된 상태라 구현이 기계적이어야 한다. 화자의 말: "코딩 구현은 지루하길 원해요. 창의적인 판단은 이미 주석 달기 사이클에서 다 끝났거든요." 이때 내 역할은 설계자에서 감독자로 바뀌고, 프롬프트가 극적으로 짧아진다("설정 페이지를 메인 앱에 만들었는데 어드민 앱에 있어야 해. 옮겨").
• 출처: 같은 영상 (~06:39)

6. 방향이 틀렸으면 패치하지 말고 git으로 통째 되돌려라

• 방법: 잘못 가고 있다는 걸 알아챈 순간, 그 위에서 고치려 하지 말고 리셋/리버트 후 범위를 좁혀 다시 시작한다.

  "전부 이전으로 되돌려. 이제 목록을 더 심플하게 만드는 것만, 그것 외엔 아무것도 하지 마."

• 왜: 경험칙 — "점진적으로 고치다 보면 원래 잘못된 모래성 위에 계속 벽돌을 쌓아 올리는 꼴이 된다." 되돌리고 범위를 좁히는 쪽이 거의 항상 더 좋은 결과를 냈다고.
• 출처: 같은 영상 (~08:11)
• 관련: Nate Herk의 16번 팁("잘못된 길로 가는 게 보이면 끝날 때까지 기다리지 말고 Esc 누르고 즉시 재조준 — 잘못된 방향으로 쓰는 모든 토큰은 낭비된 컨텍스트")과 같은 원리의 다른 시간대 처방. 이쪽은 실행 중, 김플립은 실행 후.

7. /context 로 토큰 비만의 범인을 찾아라

• 방법: /context 를 치면 시스템 프롬프트·파일 내용·MCP 서버 등이 각각 컨텍스트의 몇 %를 먹고 있는지 분해해서 보여준다. 세션이 무겁게 느껴지면 감으로 줄이지 말고 진단부터.
• 출처: 32 Tricks to Level Up Claude Code in 16 Mins — Nate Herk (~01:51)

8. /compact 에 보존 대상을 지정할 수 있다

• 방법: 그냥 /compact 가 아니라 — "/compact 하되 API 통합 결정과 DB 스키마는 전부 유지해". 압축하면서 잃으면 안 되는 것만 지목한다. 컨텍스트 60% 즈음이 압축 시점이고, 완전히 다른 작업으로 넘어갈 땐 /clear 로 판을 비운다(CLAUDE.md와 파일들은 남으니 맨땅에서 시작하는 게 아니다).
• 출처: 같은 영상 (~02:08)

9. CLAUDE.md는 150~200줄로 묶고 나머지는 다른 파일로 라우팅하라

• 방법: CLAUDE.md는 사실상 시스템 프롬프트라 매 대화에 통째로 실린다. 스타일 가이드·비즈니스 맥락·레퍼런스 문서는 별도 파일로 빼고, CLAUDE.md에는 "그건 저 파일을 보면 된다"만 적는다. 세션에서 새로 발견한 패턴·함정·관습은 그때그때 CLAUDE.md에 되먹이되, 200줄을 넘기 시작하면 덜어낼 때다.
• 왜: 화자의 표현 — "시스템 프롬프트가 특정 프로젝트의 현재 상태를 알 필요는 없다. 하지만 그 정보를 어디서 찾아야 하는지는 정확히 알아야 한다."
• 출처: 같은 영상 (~06:29) · 같은 규칙을 Maddy Zhang도 독립적으로 제시(100~200줄, "더 쓰면 신호가 희석된다")

10. 할 일 목록 자체에 자기검증 단계를 심어라

• 방법: to-do가 "웹사이트 만들기"라면, 다음 to-do를 "스크린샷 찍고 레이아웃이 맞는지 확인"으로, 그다음을 "Chrome DevTools를 열어 기능 에러가 없는지 확인"으로 만든다. 여기에 한 줄 더: "95% 확신이 서기 전엔 다음 to-do로 넘어가지 마."
• 왜: 품질 검사를 실행 계획 안에 굽는 것. 만들어서 넘겨주고 내가 피드백하는 게 아니라, 만들고→스스로 검사하고→그다음에 내 피드백을 받는 구조가 된다. 화자는 웹사이트를 만들 때 설계→스크린샷→수정을 3회 반복시킨 뒤에야 v1을 받는데, 그렇게 받은 v1이 예전 v1보다 훨씬 낫다고.
• 출처: 같은 영상 (~03:58, 스크린샷 루프는 ~08:59)

11. 서브에이전트는 Haiku, 메인 스레드는 Opus로 갈라라

• 방법: 서브에이전트를 띄울 때 모델을 지정할 수 있으므로, 단순 작업이나 대량 데이터 처리는 Haiku에 맡긴다. 수십 개 글을 긁어 수십만 토큰을 읽고 요약 몇 줄만 메인에 넘기는 일에 비싼 모델을 쓸 이유가 없다.
• 출처: 같은 영상 (~05:55)

12. git worktree로 세션을 병렬로 돌려라

• 방법: claude --worktree <기능명> → 격리된 작업공간이 자체 브랜치로 생긴다. 다른 터미널을 열어 다른 기능명으로 하나 더. 3~5개가 같은 프로젝트를 동시에 건드려도 서로 파일을 덮어쓰지 않고, 끝나면 여느 브랜치처럼 병합한다.
• 출처: 같은 영상 (~10:35) · Maddy Zhang도 같은 처방(~05:59), 다만 그는 "파일이 겹치지 않는 작업이면 IDE 패널 여러 개로 충분하고, 진지한 병렬 작업일 때만 worktree"라고 단계를 나눈다.

13. 결과에 공격적으로 반박하고, 나아진 답을 CLAUDE.md에 되먹여라

• 방법: 그냥 괜찮은 정도의 결과가 오면 밀어낸다. "그거 버려. 더 우아한 버전으로." / "이건 부족해. 완전히 다른 접근으로 다시 해." 기준을 높여주면 두 번째 시도가 확연히 낫다 — 이제 하면 안 되는 것을 아니까.
  ★ 핵심은 그다음: 나은 답이 나오면 "이걸 CLAUDE.md(또는 스킬)에 반영해"로 굳혀서 같은 실수를 반복하지 않게 한다.
• 출처: 같은 영상 (~08:00)

14. dangerously-skip-permissions 대신 allow/deny 목록을 명시하라

• 방법: 권한 설정에 들어가 안전하다고 아는 명령은 명시적으로 허용하고, 삭제·제거처럼 파괴적인 것은 명시적으로 거부한다. deny 목록이 allow 목록보다 우선한다.
• 왜: 화자 본인도 영상에서 --dangerously-skip-permissions 를 써왔다고 인정하면서 — "그런 이름이 붙은 데는 이유가 있다"고. 이 방식이면 승인 없이 달리는 속도는 그대로 얻으면서 위험만 제거된다.
• 출처: 같은 영상 (~14:02)

15. CLAUDE.md는 신입 온보딩 문서 3요소로 채워라

• 방법: 새 코드베이스에서 가장 먼저 /init. 생성된 CLAUDE.md가 답해야 할 세 가지 — ①이 프로젝트가 무엇을 하는가 ②무엇이 어디에 있는가(핵심 파일 경로) ③일이 어떻게 되는가(테스트 돌리는 법, 빌드하는 법, 린트하는 법의 실제 명령어). 여기에 "내가 어떤 사람인지"를 적어두면 내 스타일로 코딩한다.
• 왜: CLAUDE.md가 없으면 매 세션마다 코드베이스를 처음부터 다시 탐색한다 — 토큰을 태우고 실수를 낳는다. 잘 된 CLAUDE.md가 있으면 "빌드 명령은 yarn이 아니라 npm run dev", "API 라우트는 이 폴더", "함수형 컴포넌트에 훅을 쓴다"를 이미 안 상태로 시작한다.
• 출처: How I use Claude Code (Senior Software Engineer Tips) — Maddy Zhang (~01:41)

16. 작업이 바뀌면 /clear — 세션은 이어가는 대화가 아니다

• 방법: 한 작업을 끝내고 다른 걸 시작할 때마다 /clear. 되돌아볼 일이 있으면 위 화살표로 과거 세션을 부른다.
• 왜: 컨텍스트가 차면 성능이 급격히 나빠진다 — 이상한 결정을 하고, 앞서 준 제약을 잃고, 낡은 히스토리를 요약하느라 연산을 쓴다. "많은 사람이 클로드 코드 세션을 끊고 싶지 않은 대화처럼 다루는데, 사실은 정반대다. 각 작업은 깨끗한 컨텍스트의 새 세션이어야 한다."
• 출처: 같은 영상 (~03:30)
• 보정 — 오늘의 가장 큰 충돌: 김플립은 정확히 반대를 주장합니다. "리서치·기획·구현을 별도 세션으로 나누지 않고 하나의 긴 세션에서 쭉 간다. 컨텍스트 50% 넘으면 성능이 떨어진다는 얘기를 체감하지 못한다." 그의 근거는 ①구현을 명령할 시점엔 클로드가 그 세션 내내 이해를 쌓아온 상태고 ②오토 컴팩션이 맥락을 유지해주며 ③계획 문서가 파일이라 압축과 무관하게 원본 그대로 살아남기 때문입니다. 세 번째가 결정적입니다 — 계획을 파일로 뽑아둔 사람만 긴 세션을 감당할 수 있고, 채팅창에만 있는 사람은 /clear가 필수라고 읽으면 두 주장이 화해합니다. 실측 전이므로 어느 쪽도 단정하지 않습니다.

17. hooks로 빌드·테스트·타입체크를 매 편집 후 자동 실행되게 묶어라 (검증 하네스)

• 방법: hooks는 워크플로우의 특정 시점에 자동 발화하는 스크립트다. 세 가지를 배선한다 — 빌드 · 테스트 · 타입 체커. CLAUDE.md나 hooks 설정에 이렇게 박는다:

  "매 편집 후 빌드를 실행하고, 테스트를 실행하고, 타입 체크를 실행해라. 하나라도 실패하면 blocker로 취급하고 넘어가기 전에 고쳐라."
  세팅에 20분쯤 걸린다.

• 왜: 클로드도 여느 엔지니어처럼 실수한다 — 함수를 옮기면서 테스트의 엣지 케이스를 놓치는 식. 내가 리뷰에서 잡을 수도 있지만, 검증 루프가 있으면 클로드가 실패 출력을 즉시 보고 스스로 고친다. "세션을 떠났다 돌아왔을 때 디버깅할 에러 더미가 아니라 초록 CI를 보게 된다. 출력 품질의 차이가 극적이다."
• 출처: 같은 영상 (~04:35)

18. 슬래시 커맨드와 스킬을 구분해서 써라

• 방법: 슬래시 커맨드(.claude/commands 안 마크다운) = 한 프롬프트 한 동작의 빠른 트리거. 예: PR 설명을 써주는 PR summary 커맨드(무엇이 바뀌었고, 왜, 어떤 리스크가 있고, 어떻게 테스트하는지). 스킬 = 여러 단계 로직을 담고 다른 파일을 참조하며 서브에이전트가 호출할 수도 있는 플레이북.
  판단 기준: "엔지니어링 워크플로우에서 주 1회 이상 하는 일이면 슬래시 커맨드가 있어야 한다. 같은 프롬프트를 매번 다시 쓰고 있으면 안 된다."
• 출처: 같은 영상 (~04:05, 스킬 구분은 ~07:12)
• 관련: 어제 자동화호에서 수집한 "워크플로우를 Claude Skill로 굳혀라"(2026-08-13)의 정밀화입니다. 그 팁은 "스킬로 만들어라"에서 끝났는데, 이 영상은 언제 스킬이고 언제 슬래시 커맨드인가를 가릅니다.

19. 바이브코딩과 에이전틱 엔지니어링을 구분하라

• 방법: 개념 구분이지만 실무 기준선이다.
• 바이브코딩 = 바닥을 올리는 일. 누구나 무엇이든 만들 수 있게 된다. 훌륭한 일이다.
• 에이전틱 엔지니어링 = 기존 전문 소프트웨어의 품질 바를 지키면서 빨라지는 일. "바이브코딩 탓에 취약점을 넣는 것은 허용되지 않는다. 소프트웨어에 대한 책임은 전과 똑같이 내 것이다. 다만 더 빨리 갈 수 있는가? — 갈 수 있다. 어떻게 제대로 하느냐가 관건이다."
  카파시는 이걸 공학 분과라고 부른다: 에이전트는 뾰족하고, 좀 오류를 내고, 확률적이지만 극도로 강력한 존재들이고 — 품질 바를 희생하지 않으면서 이들을 조율해 빨라지는 법이 그 분과의 내용이다.
• 덧붙임: "10x 엔지니어라는 말을 하곤 했는데, 이건 그보다 훨씬 증폭된다. 10x는 얻는 속도가 아니다. 이걸 아주 잘하는 사람들은 10x보다 훨씬 더 나온다."
• 출처: From Vibe Coding to Agentic Engineering — Sequoia Capital / Andrej Karpathy (~15:57)
• 보정: 이 영상은 팁 모음이 아니라 대담입니다. 실행 단계가 적은 대신, 오늘의 다른 세 영상이 무엇을 하라고 말할 때 이쪽은 왜를 설명합니다. 홍보성 없음(VC 주최 공개 대담).

20. 내 작업이 "검증 가능한 영역"에 있는지 먼저 판별하라

• 방법: 판단 기준 한 줄 — 전통적 컴퓨터는 코드로 명세할 수 있는 것을 자동화했고, LLM은 검증할 수 있는 것을 자동화한다. 프론티어 랩들이 거대한 강화학습 환경에서 검증 보상으로 훈련하기 때문에, 수학·코드처럼 검증 가능한 영역에서 뾰족하게 솟고 나머지는 들쭉날쭉해진다.
• 그래서 실무에서는: 카파시가 드는 예 — 최신 모델이 10만 줄 코드베이스를 리팩터하고 제로데이 취약점을 찾아내면서, "50m 거리의 세차장에 차로 갈까 걸어갈까"에는 걸어가라고 답한다. "이건 미친 일이다." 이 들쭉날쭉함이 뜻하는 것은 둘 중 하나다: ①뭔가 미묘하게 잘못됐거나 ②내가 루프 안에 있어야 한다는 뜻이다. RL 회로 안에 있으면 날아가고, 회로 밖이면 이가 안 들어간다 — 내 작업이 어느 쪽인지 파악하는 것이 실무 능력이고, 회로 밖이라면 파인튜닝이나 사람 개입을 각오해야 한다.
• 덧붙임: 카파시의 micro-GPT 사례 — LLM 학습 코드를 최대한 단순화하려 했더니 "모델들이 이걸 싫어한다. 못 한다. 계속 더 단순화하라고 시켜도 안 된다. RL 회로 밖에 있다는 느낌이 온다. 이 뽑는 것 같다." 코드를 더하는 데이터는 넘치고 덜어내는 데이터는 희소하니 자연스러운 결과입니다.
• 출처: 같은 영상 (~10:02, micro-GPT는 ~22:58)

21. 문서를 사람이 아니라 에이전트에게 써라

• 방법: 카파시의 pet peeve 그대로 — "왜 사람들이 아직도 나한테 뭘 하라고 말하나? 나는 아무것도 하기 싫다. 내 에이전트에 복붙할 텍스트가 뭐냐?"
  실제 사례: OpenClaw 설치가 셸 스크립트가 아니라 에이전트에게 붙여넣으라고 주는 텍스트 뭉치다. 여러 플랫폼·여러 환경을 지원하려면 셸 스크립트는 걷잡을 수 없이 비대해지는데, 에이전트에게 맡기면 세부를 정확히 다 적을 필요가 없다 — 에이전트가 환경을 살펴보고 지능적으로 행동하고 루프 안에서 디버깅한다.
• 왜: 이것이 소프트웨어 3.0이다. "프로그래밍이 프롬프팅으로 바뀌고, 컨텍스트 창에 무엇이 들어 있는가가 LLM이라는 인터프리터에 대한 내 레버가 된다."
• 출처: 같은 영상 (~03:44)

22. 앱을 짓기 전에 "이 앱이 아예 필요 없는가"를 물어라

• 방법: 카파시의 MenuGen 사례. 식당 메뉴판을 찍으면 요리 사진을 보여주는 앱을 만들었다 — 업로드 받고, OCR 하고, 이미지 생성기를 호출하고, 메뉴를 다시 렌더하고, Vercel에 배포하고. 그런 다음 소프트웨어 3.0 버전을 봤다: 사진을 그냥 Gemini에 주고 "Nano Banana로 이 항목들을 메뉴 위에 얹어줘"라고 말하는 것. 나노 바나나가 내가 찍은 그 메뉴판 사진을 그대로 돌려주는데, 픽셀 안에 요리 그림들이 렌더돼 있었다.

  "이게 내 머리를 날려버렸다. 내 MenuGen은 전부 군더더기였다. 그 앱은 존재하면 안 되는 것이었다."

• 왜: "사람들은 기존 패러다임 안에서 지금 있는 것의 속도 향상으로 생각하기를 그만둬야 한다. 실제로는 새로운 것들이 가능해진 것이다." 그가 더 흥미롭게 여기는 쪽은 후자다.
• 출처: 같은 영상 (~04:52)

23. 세부 API는 넘기되 근본 구조는 쥐고 있어라

• 방법: 카파시가 실제로 놓아버린 것 — "keepdims인지 keepdim인지, dim인지 axis인지, reshape인지 permute인지 transpose인지 더 이상 기억하지 않는다. 그럴 필요가 없으니까. 이런 세부는 리콜이 아주 좋은 인턴이 처리한다."
  그가 계속 쥐고 있는 것 — "하지만 텐서 아래에 뷰가 있고 같은 스토리지에 대한 뷰를 가질 수도 있고 다른 스토리지를 가질 수도 있어서 후자가 덜 효율적이라는 것은 여전히 알아야 한다. 그래야 불필요하게 메모리를 복사하고 다니지 않는다."
• 왜: "생각은 아웃소싱할 수 있어도 이해는 아웃소싱할 수 없다." 카파시는 이 문장을 이틀에 한 번꼴로 곱씹는다고 말한다 — "나는 여전히 시스템의 일부이고, 정보는 어떻게든 내 뇌로 들어와야 한다. 무엇을 만들려 하는지, 왜 할 가치가 있는지, 에이전트를 어떻게 지휘할지를 아는 일에서 내가 병목이 되고 있다는 느낌이 든다."
• 출처: 같은 영상 (~21:05, 인용문은 ~28:06)

시도 후보 (직접 해볼 것)

1. plan.md 인라인 주석 사이클 (팁 3·4) — 다음 작업에서 계획 수정을 대화가 아니라 문서 주석으로 되돌려주는 방식을 써보기. "아직 구현하지 마"를 매번 붙이는지가 실험의 핵심 변수다.
2. hooks 검증 하네스 (팁 17) — 프로젝트의 빌드·테스트·타입체크를 편집 시점 hook에 걸어, 실패가 커밋이 아니라 편집 직후에 터지게 만들기. "세팅 20분" 주장의 실측.
3. /context 로 상주 예산 재보기 (팁 7) — CLAUDE.md·MCP 서버·파일 내용이 각각 컨텍스트의 몇 %를 먹는지 확인하고, 150~200줄 규칙(팁 9)에 부합하는지 점검.
4. allow/deny 권한 사다리 (팁 14) — --dangerously-skip-permissions 를 쓰고 있다면, 안전 명령 허용 + 파괴적 명령 거부 목록으로 갈아타 같은 속도가 나오는지 확인.
5. to-do 인라인 자기검증 (팁 10) — "95% 확신 전엔 다음으로 넘어가지 마"를 실제 할 일 목록에 심었을 때 되돌아오는 횟수가 줄는지 관찰.
6. "이 코드가 아예 필요 없는가" (팁 22) — 지금 짓고 있는 것 중 하나를 골라, 모델 호출 한 줄로 대체 가능한지 진짜로 시도해보기.

창간호·아침 호의 시도 후보 7건은 아직 미검증입니다. 오늘 6건이 더해져 누적 13건 — 실험이 증류를 못 따라가고 있습니다. 다음 호에서는 새 팁 수집보다 미검증 후보 소화를 앞세우는 편이 나을 수 있습니다.

오늘의 영상

• 찐 개발자의 바이브 코딩은 다릅니다 — 클로드코드 실전 워크플로우 모두 공개 — 김플립 · LLM 코딩 · 2026-02-26 · 11.8분 · 조회수 17.8만 · 오늘의 최고 밀도. 11분에 완결된 방법론 하나가 프롬프트 원문까지 붙어 나온다. 홍보 없음, 자료 미끼 없음. 유일한 흠은 "MCP·스킬·팀 에이전트는 다 부차적"이라는 과한 단정.
• 32 Tricks to Level Up Claude Code in 16 Mins — Nate Herk · 2026-04-27 · 16.3분 · 조회수 42만 · 폭이 가장 넓다(초급→고급). [홍보성] 무료 PDF 자료를 미끼로 한 스쿨 커뮤니티 유입이 목적이고, 음성 입력 도구도 설명란 제휴 링크. 또 자막상 "hack number 28"이 두 번 나온다 — 실제 팁 개수가 32개가 아닐 수 있어 제목 자체가 살짝 부정확하다. 그럼에도 /context·/compact 보존 지시·allow/deny 같은 알맹이가 분명히 있다.
• How I use Claude Code (Senior Software Engineer Tips) — Maddy Zhang · 2026-04-05 · 9.8분 · 조회수 19만 · 가장 정돈됐다. 구글·아마존·MS 출신 시니어의 시선이라 기능 나열이 아니라 기능이 강제하는 습관(plan → execute → review)으로 묶는다. "모든 기능은 이 세 단계 중 하나를 강제하는 도구일 뿐"이라는 마무리가 이 영상의 값어치.
• Andrej Karpathy: From Vibe Coding to Agentic Engineering — Sequoia Capital · 2026-04-29 · 29.8분 · 조회수 146만 · 팁 밀도는 낮고 개념 밀도는 오늘 최고. 대담 형식이라 실행 단계가 적으니 다른 세 편을 읽고 나서 볼 것을 권한다. 세차장 사례, MenuGen 사례, "이해는 아웃소싱할 수 없다"는 오래 남는다.

지켜볼 점 / 내일 주제 후보

• 내일 주제 후보: 문서업무(엑셀·PPT·보고서) — 어제 차선으로 잡혀 있던 칸이고, 오늘 세 번 연속 개발자 주제(프롬프트→자동화→코딩)였으니 결이 바뀔 때다. 오빠두엑셀의 Genspark 실전 20가지(49분)가 후보로 남아 있다. 차선은 자료조사(리서치·요약) — 카파시가 언급한 "LLM 지식베이스/위키" 흐름이 이 칸에 걸린다.
• 오늘의 방법론적 수확 — 교차 검증이 처음으로 작동했다. 서로 인용하지 않는 4명(한국 개발자·미국 자동화 유튜버·구글 출신 시니어·카파시)이 같은 처방(계획을 문서로 먼저)에 수렴했다. 반대로 /clear vs 하나의 긴 세션은 정면 충돌했고, 그 충돌이 "계획을 파일로 뽑았는가"라는 숨은 변수를 드러냈다(팁 16 보정). 팁 하나짜리 영상보다 서로 충돌하는 영상 여러 편이 정보량이 많다 — 앞으로 선정에서 의도적으로 대립각을 노려볼 가치가 있다.
• 6개월 규칙 3일차 실측: 후보 8편 검증 중 3편 탈락(2025-09, 2025-10, 2026-01-30). 어제보다 탈락률이 낮은데(6/10 → 3/8), 영어권 검색을 섞은 덕으로 보인다 — 영어 원천 채널이 회전이 빨라 최신 영상 비중이 높다. §2-3의 글로벌화 규칙이 6개월 규칙과 궁합이 좋다는 어제의 가설이 한 번 지지받았다.
• 미검증 부채가 쌓이고 있다 — 시도 후보 누적 13건, 검증 0건. 이 보고서의 팁은 전부 자막 기반 증류이므로 실측이 아니다. 부채를 갚는 호를 한 번 끼워 넣을 시점이 다가온다.

출처

• 김플립 - LLM 코딩 · Nate Herk | AI Automation · Maddy Zhang · Sequoia Capital (Andrej Karpathy)