유튜브 AI 팁 보고서 — 2026-09-07 — 코딩

오늘의 영상 5편 · 누적: 팁 555개 / 다룬 영상 139편(후보 등재 1077편)

한눈에 (TL;DR)

• "컨텍스트 창 하나 = 작업 단위 하나"가 영어권 두 편에서 같은 결론으로 만난다. Matt Pocock은 사양서를 컨텍스트 창 하나 크기의 티켓으로 쪼개고 티켓마다 컨텍스트를 비우며, Claude Code 팀은 조사·버그 사냥을 팬아웃 후 요약으로 접는다. 프롬프트 기술이 아니라 세션 경계 설계가 오늘의 공통 주제다.
• 코드 리뷰의 쟁점이 "누가 리뷰하나"에서 "무엇을 기준으로 두나"로 옮겨 갔다. 사양서 대비 수용 기준(Pocock), 세 관점 적대적 테스트(Claude 팀), 시니어 관점 허점 질문(신영선) — 세 편이 서로 모르는 채 각기 다른 기준을 제시한다. 셋 다 "코드를 방금 쓴 에이전트에게 리뷰를 맡기지 않는다"는 점에서 일치한다.
• 회의론(Aviator)의 반박이 이번 호에서 가장 날카롭다: 문제는 기술부채가 아니라 인지부채·의도부채다. 코드는 돌아가는데 "왜 이렇게 만들었는지 아는 사람"이 사라지는 것이 진짜 비용이라는 주장. 다만 저자 스스로 "수년간의 실증 연구가 아니라 내 의견"이라고 밝혔고 측정 프레임워크는 작업 중이다.

오늘의 팁

1. npx skills@latest add mattpocock/skills 로 스킬 저장소를 설치하라

• 방법: Node.js가 있는 상태에서 프로젝트 디렉터리에서 npx skills@latest add mattpocock/skills 실행 → skills.sh 설치기가 뜨고 38개 스킬이 mattpocock 그룹과 other 그룹으로 나뉘어 나옴 → 목록 맨 위로 올라가 space로 공식 스킬만 일괄 선택 후 return → 에이전트 선택(Claude Code 등) → 설치 범위는 팀이면 project, 1인이면 global → 링크 방식은 symlink 선택(복사보다 깔끔). 이어서 setup mattpocock skills 실행: ①이슈 트래커를 말로 지정("I'm just going to set it up with local markdown, please") ②triage 라벨 기본값 수락 ③대형 모노레포가 아니면 도메인 문서는 single context. 그러면 claude.md에 트래커·라벨·도메인 문서 링크가 추가된다. 막히면 ask Matt 스킬에 "how do I get started? What is the main flow I should use?"라고 묻는다.
• 출처: mattpocock/skills: A complete AI Coding workflow, end-to-end — Matt Pocock · 01:10
• 보정: 발표자 본인이 설치 CLI의 선택 UI가 "kind of broken"이라며 향후 자체 CLI로 교체할 수 있다고 인정한다. 설치 중 패키지 보안 경보(Socket)가 떴으나 확인은 미뤄졌다.

2. grill with docs 로 계획을 뽑고 to spec 으로 압축한 뒤 tickets 로 컨텍스트 창 하나 크기로 쪼개라

• 방법: ①끊기지 않은 한 컨텍스트 창 안에서 grill with docs를 호출하고 아주 막연한 아이디어로 시작해도 된다. 스킬이 레포를 탐색하며 후속 질문을 던지고 알아낸 것을 context.md와 ADR에 기록한다(플랜 모드가 아니라 기본 auto 모드). "공유된 이해에 도달했다"고 느낄 때까지 답한다(사례 6개 질문, 보통 약 20개). ②여러 세션에 걸칠 크기면 to spec이라고만 입력 — 그때까지의 논의(사례 46.1k 토큰)를 문제 정의·해법·유저 스토리·구현 결정·테스트 결정이 담긴 문서 하나로 압축해 트래커에 발행한다. ③같은 세션에서 to tickets — 각 티켓은 컨텍스트 창 하나 크기. 슬라이스가 과하면 "I actually think it can be done in one slice"처럼 직접 줄인다(사례: 스펙 1개 아래 티켓 11개 = 세션 11개). ④구현은 컨텍스트를 clear하고 implement this @tickets로 티켓 하나씩, 티켓마다 clear.
• 출처: mattpocock/skills: A complete AI Coding workflow, end-to-end — Matt Pocock · 09:40~16:30
• 보정: 영상 속 시연은 티켓 3개를 1개로 줄일 만큼 작은 작업이라 다중 세션 분할의 실효를 보여주지 못한다. 발표자 스스로 "꽤 나쁜 예시"라며 과거 사례를 대신 든다.

3. 컨텍스트 140k 스마트존 안에 들면 곧장 /implement 로 넘어가라

• 방법: 계획이 나온 시점에서 남은 컨텍스트를 확인한다. 발표자는 140k 언저리부터 모델이 "눈에 띄게 멍청해진다"고 보고 그 아래를 스마트존으로 잡는다. 남은 예산과 작업량을 비교해("100k 남았고 커맨드 10개 제거 → 가능") 한 세션에 들어오면 to spec·to tickets를 건너뛰고 바로 /implement this 후 끝까지 돌게 둔다. 사례의 구현은 42.7k로 끝났다.
• 출처: mattpocock/skills: A complete AI Coding workflow, end-to-end — Matt Pocock · 12:30
• 보정: 140k라는 수치는 발표자 개인의 체감이며 측정 근거나 모델별 검증이 제시되지 않는다.

4. 도구 호출 대신 HTML 결과물이 나에게 질문하도록 만들어라

• 방법: 사용자에게 묻는 전용 도구를 에이전트가 호출하게 설계하는 대신, 에이전트가 HTML 형식의 결과물(다이어그램·목업)을 만들게 하고 그 결과물이 사용자에게 질문을 던지도록 한다. 계획 단계 이후 상호작용이 필요할 때 쓴다.
• 출처: How the Claude Code team uses Claude Code — Claude · 05:30
• 보정: "도구를 거의 안 쓴다"는 개인 경험담이고, HTML을 어떻게 생성시키는지 프롬프트나 설정은 원문에 없다.

5. 찾아낸 버그마다 세 가지 관점의 적대적 테스트로 실재 여부를 검증하라

• 방법: 워크플로우로 대규모 팬아웃을 걸어 버그 후보를 모은다. 그다음 각 버그를 세 가지 다른 관점에서 적대적으로 테스트해 실제 존재하는지 확인하고, 수많은 후보 중 정말 주의가 필요한 것만 남긴다. 성능 버그·일반 심층 조사에도 같은 방식을 적용한다.
• 출처: How the Claude Code team uses Claude Code — Claude · 11:30
• 보정: 세 관점이 구체적으로 무엇이고 어떻게 프롬프트하는지는 원문에 명시되지 않는다.

6. PR 검증은 테스트 실행과 화면 스크린샷까지 첨부하게 하라

• 방법: PR을 생성할 때 테스트를 실행하고 화면이 어떻게 보이는지 스크린샷을 함께 붙이게 한다. TUI라면 먼저 TUI를 조작해 녹화하게 요청하고, 그 뒤 직접 복제해 확인한다.
• 출처: How the Claude Code team uses Claude Code — Claude · 18:00
• 보정: "어느 정도 확신이 생긴다" 수준의 체감 서술이고 자동화 설정 방법은 없다.

7. "네가 시니어 엔지니어라면 이 계획의 허점은 뭐야"로 계획을 리뷰시켜라

• 방법: 1) 플랜 모드로 상세 계획을 짜고 누락을 질문받는다. 2) 완성된 계획을 바로 구현하지 말고 다른 세션에 리뷰를 맡긴다(A가 계획, B가 검토·구현). 3) 리뷰 프롬프트는 "네가 시니어 엔지니어라면 이 계획의 허점은 뭐라고 생각해?" 4) 나온 허점을 보완한 뒤 구현에 들어간다.
• 출처: 클로드코드 7가지 꿀팁 총정리 — 신영선의 AI탐구 · 07:20
• 보정: "클로드를 만든 팀이 쓰는 프롬프트"라고 소개하지만 출처 문서는 제시되지 않는다.

8. 하루에 두 번 이상 반복되는 업무는 무조건 스킬로 만들어라

• 방법: 1) 작업을 한 번 쭉 수행한다. 2) "지금까지 작업했던 내용을 스킬로 만들어 줘"라고 입력하면 스킬이 생성된다. 3) 이후 슬래시 + 단어 하나로 자동 실행되는 단축어가 된다. 4) 하루 두 번 이상 반복되는 업무는 전부 이 방식으로 누적시킨다.
• 출처: 클로드코드 7가지 꿀팁 총정리 — 신영선의 AI탐구 · 15:00
• 보정: 함께 인용된 "기능 완성 속도 65% 향상"은 10개월간 에이전트 13개·스킬 40개가 쌓인 결과이지 스킬 단독 효과가 아니다.

9. 에러 로그를 복사하지 말고 원인 후보와 최소 재현 테스트를 만들어 달라고 지시하라

• 방법: 에러가 터진 터미널에서 로그를 드래그·복사하지 않고 채팅창에 그대로 지시한다. "이 에러 원인 후보 세 개랑 확인 방법 좀 알려 줘", "이거 재현 가능한 최소 단위 테스트 케이스 좀 만들어 줘". 오픈코드는 터미널의 에러를 스스로 읽는다. 대용량 로그는 스냅 플러그인이 설치 진행률 바·반복되는 npm 의존성 에러를 정규식으로 걸러 스택 트레이스 같은 핵심만 압축해 보낸다.
• 출처: OC004: OpenCode 실전 활용 - 프로젝트 구축부터 디버깅까지 — 인공지능 팟캐스트 · 09:10
• 보정: "수만 줄 → 250 토큰 미만", "기억 한계 83% 연장" 같은 수치는 출처 없이 제시된다.

10. 시스템 트랜스폼 훅에 팀 코딩 컨벤션을 주입해 매번 프롬프트에 쓰지 마라

• 방법: experimental system transform이라는 프롬프트 주입 훅에 팀의 절대 규칙을 미리 넣어 둔다. 예: "타입스크립트 짤 때 any 타입 절대 금지", "모든 API 응답에는 타입가드 필수", "테스트는 무조건 Jest". 그러면 "이 컴포넌트 테스트 코드 짜줘"라고만 쳐도 모델에 들어가기 직전에 시스템이 가로채 지침을 프롬프트 최상단에 주입한다.
• 출처: OC004: OpenCode 실전 활용 - 프로젝트 구축부터 디버깅까지 — 인공지능 팟캐스트 · 12:20
• 보정: "컨벤션 싸움이 거의 제로가 된다"는 근거 없는 기대치이고, 기능 이름 자체가 experimental이다.

11. 대규모 프로젝트는 SKILL.md에 목차와 핵심 워크플로만 담아 점진적으로 열게 하라

• 방법: 스킬 문서에 전체 내용을 넣지 않고 목차와 핵심 워크플로만 담아, 에이전트가 필요할 때 하위 문서를 점진적으로 열게 한다.
• 출처: OC004: OpenCode 실전 활용 - 프로젝트 구축부터 디버깅까지 — 인공지능 팟캐스트 · 17:10
• 보정: 이 팁은 2차 증류에서 단계 서술이 확보되지 않아 원칙 수준으로만 남았다 — 원문에 구체적 파일 구성 예가 없다.

12. 프로토타입에서 제품으로 가는 지점마다 기술부채와 인지부채를 캔버스로 평가하라

• 방법: 팀별로 캔버스(워크시트)를 나눠 세 칸을 채우게 한다: ①프로토타입-제품 여정에서 지금 어디인가 ②기술부채는 얼마나 있는가 ③인지부채(시스템이 무엇을 왜 하는지에 대한 이해, 그리고 팀 안에서 누가 무엇을 아는지)는 얼마나 있는가. 그리고 무엇을 할지 정한다. 회고에서는 아키텍처 그림을 띄우고 "이 전체를 누가 이해하는가", "각 서브시스템 옆에 누구 이름을 붙일 수 있는가"를 묻는다. 숫자 지표를 서둘러 만들기보다 신호를 먼저 찾는다 — 내부 질문 빈도 같은 대리 지표는 '아예 이해 못 해 질문조차 못 하는 경우'를 놓치므로 부채 척도로 쓰지 않는다.
• 출처: The Hidden Cost of AI-Generated Code: Cognitive Debt and Intent Debt — Aviator · 21:10
• 보정: 저자 본인이 "수년간의 실증 연구에 기반한 게 아니라 내 의견"이라고 밝혔고 측정 프레임워크는 아직 작업 중이다.

13. 주 1회 AI를 쓰지 않는 날을 두고 의도적 마찰을 일정에 넣으라

• 방법: 매주 하루는 AI를 쓰지 않는 날로 정하고 대신 게임을 하거나 자연 속을 걷는다. 그러면 "이 게임의 이 요소가 우리 제품의 기능이 되겠다"는 말이 나오기 시작한다. 조직 차원에서는 '의도적 마찰(intentional friction)'을 넣어 속도를 늦추고 며칠 쉬게 한다. 회고에서는 배(boat) 비유로 크루의 안녕을 점검한다 — 잘 쉬었는가, 지쳤는가, 누가 교대해야 하는가.
• 출처: The Hidden Cost of AI-Generated Code: Cognitive Debt and Intent Debt — Aviator · 37:00
• 보정: 'AI 없는 날'은 진행자가 즉석에서 던진 제안에 화자가 동의한 수준이고 검증된 실천법으로 제시된 것이 아니다.

시도 후보

• 스펙-티켓 분할을 이 시스템의 큰 작업에 적용해 보기(팁 2): 보고서·수리 주행처럼 여러 호출에 걸치는 일에 '컨텍스트 창 하나 = 티켓 하나' 경계를 명시적으로 세워 본다.
• 로그 붙여넣기 대신 '원인 후보 3개 + 최소 재현' 요구(팁 9): 다음 백엔드 오류 수리 때 한 번 이 순서로 해 본다.
• 훅으로 컨벤션 주입(팁 10): 프롬프트에 매번 실리는 규칙 중 결정론적인 것을 단편으로 접을 여지가 있는지 본다.

오늘의 영상

• mattpocock/skills: A complete AI Coding workflow, end-to-end — Matt Pocock · 42.3만 · 17:17 · 2026-07-16 — 공개 스킬 저장소를 설치부터 구현까지 끝에서 끝까지 실연. 오늘 다섯 편 중 재현 가능성이 가장 높다. 자기 저장소 홍보라는 점은 감안.
• How the Claude Code team uses Claude Code — Claude · 14.5만 · 22:23 · 2026-09-02 — 개발팀 내부 사용 습관. 발상은 신선하나 설정·프롬프트 수준의 구체성은 낮다. 오늘 후보 중 가장 최신(5일 전).
• 클로드코드 7가지 꿀팁 총정리 — 신영선의 AI탐구 · 2.4만 · 20:32 · 2026-03-29 — 한국어 층. 7개 중 5개는 이미 수집한 팁과 겹쳐 2개만 채택. 인용 수치의 출처 표기가 약하다.
• OC004: OpenCode 실전 활용 - 프로젝트 구축부터 디버깅까지 — 인공지능 팟캐스트 · 19회 · 22:45 · 2026-07-07 — 한국어 층. 조회수 19회지만 오늘 팁 밀도로는 상위. Claude Code 일색인 검색 결과에서 다른 하네스를 보여 준 유일한 편.
• The Hidden Cost of AI-Generated Code: Cognitive Debt and Intent Debt — Aviator · 478회 · 39:59 · 2026-05-07 — 회의론 층. 연구자 인터뷰라 주장이 조심스럽고 자기 한계를 스스로 밝힌다. 오늘 유일한 반대편 시각.

지켜볼 점 / 내일 주제 후보

• '코딩' 검색은 이제 Claude Code 단일 종목이 됐다. 원장 제외 후 64편 중 한국어 후보의 절대다수가 클로드코드 입문·정복 튜토리얼이었고, 6개월 통과 44편에서도 마찬가지였다. 다음에 코딩을 걸면 하네스 이름(OpenCode·Codex CLI·Cursor)이나 행위 어휘(코드리뷰·디버깅·마이그레이션)로 좁혀야 새 것이 나온다.
• "코드를 쓴 에이전트에게 리뷰를 맡기지 않는다"가 세 편에서 교차한다. 서로 다른 근거(사양서 대비·적대적 테스트·역할 분리)로 같은 결론에 도달한 것이 이번 호의 가장 강한 신호다.
• spec-driven development 계열이 통과 후보에 대거 있었으나 이번 호에는 한 편도 정독하지 못했다(IBM·Spec Kit·BMAD 비교 등). '스펙 주도 개발' 자체를 주제로 하루를 쓸 만하다.
• 내일 주제 후보: 스펙주도개발 / 디버깅 / 음성.

이 호의 한계

• 자막만 읽었고 실제로 돌려보지 않았다 — 효과는 전부 검증 전이다.
• 날짜 확인 64편 중 180일 통과 44편(69%), 그중 정독 5편. 통과 44편 중 나머지 39편은 적합도·층 균형으로 not_selected, 탈락 20편은 too_old로 원장 기록.
• 자막 전사 실패 0편(5편 전부 성공), 팁 후보 57개 중 13개 채택.
• 신영선 편에서 뽑힌 후보 중 '워크트리 병렬', '플랜 모드 우선', 'PostToolUse 훅 자동 포맷', '실수를 CLAUDE.md에 기록'은 08-13·08-27 코딩 호의 기존 팁과 같은 개념이라 재탕으로 제외했다.
• 팁 11(SKILL.md 점진 로딩)은 2차 상세 증류에서 따라 할 단계가 원문에 없어 원칙 수준으로만 남았다.
• 오늘 세 번째 호다(06시 '학습', 15시 'AX'에 이어). 같은 날 앞선 두 호와 주제·영상 중복은 원장 대조로 배제했다.