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

오늘의 영상 4편 · 누적: 팁 351개 / 다룬 영상 79편(후보 등재 357편)

코딩 주제는 8/13 이후 보름만에 다시 잡았다. 그사이에 모델이 바뀌었고(Opus 5), 도구에 새 기능이 들어왔고(Dynamic Workflow), 그리고 처음으로 "더 붙이는 법"이 아니라 "덜어내는 법"을 말하는 영상이 나왔다. 오늘 호의 중심축은 거기다.

한눈에 (TL;DR)

• 내가 만든 규칙은 유통기한이 있다. 3개월 전에 "반드시 계획부터 세워라"라고 친 울타리는 모델이 지시를 안 따르던 시절의 유물이다. 지금은 그 규칙이 중복 지시로 바뀌어 오히려 방해하고 있을 수 있다 — 월 1~2회 감사해서 덜어내라. (팁 16~20)
• Opus 5는 예전 조언의 반대로 다룬다. 작업을 쪼개 주지 말고 전체를 한 번에, 노력(effort)은 낮게, "끝나고 두 번 검토해라"는 빼라. 대신 어디서 끝나는지와 하지 말 것을 써줘라. (팁 7~11)
• 테스트는 순서가 전부다. 구현 다음에 테스트를 쓰게 하면 자기 코드에 맞춘 테스트가 나온다 — 검증이 아니라 커닝이다. (팁 1)
• 그리고 오늘은 반대편 시각이 오랜만에 신선한 모습으로 잡혔다: 개발자 1,300명 설문에서 46%가 멈추려던 지점을 정기적으로 지나쳤고, 그 집단의 58%가 수면 변화를 보고했다(멈춘 집단은 17%). (팁 12~15)

오늘의 팁

1. 테스트를 먼저 쓰게 한 다음 구현시켜라

• 방법: "테스트를 먼저 쓰고, 그다음 구현하라"로 순서를 명시한다. 구현을 먼저 시키면 AI는 자기가 쓴 코드가 통과하도록 테스트를 맞춘다 — 화자의 표현으로는 "테스트가 아니라 커닝". 이어서 "모든 줄을 테스트하지 말고 중요한 것만"을 붙인다 — 똑똑한 모델일수록 전부 테스트하려 들어 코드베이스가 부풀어 오른다.
• 검증 수단은 테스트만이 아니다: 타입 체커·린터를 "완료라고 판단하기 전에 돌려라"로 묶고, 프론트엔드는 스크린샷·브라우저 조작을 붙인다.
• 출처: I Have Spent 1000+ Hours With Claude Code. This Is What I Learned — The Coding Sloth (08:49~09:56)

2. AI가 스스로 /compact를 돌렸다면 그건 새 세션을 시작하라는 신호다

• 방법: 자동 압축이 걸린 것을 보면 그 세션을 이어가지 말고 끓는다. 화자의 말: "작업 중간에 자기가 압축되면 치매가 온다." 반대로 대화를 끊기 싫은 상황이 확실하면 내가 먼저 /compact를 돌리며 무엇을 보존할지 지정한다.
• 보정: "압축에 보존 대상을 지정할 수 있다"는 이미 수집(2026-08-13 코딩호). 오늘 새로운 것은 반대 방향의 판단 — 자동으로 걸렸을 때는 살리려 하지 말고 버리라는 것.
• 같은 맥락의 수치 하나: 화자는 컨텍스트 창을 300k에서 1M으로 늘리는 것이 "멍청해지는 구간을 없애는 게 아니라 늘리는 것"이라고 말한다. 체감상 100k~200k부터 품질이 꿄다는 것은 개인 관찰이니 수치 그대로 믿을 것은 아니다.
• 출처: 같은 영상 — The Coding Sloth (13:06~15:30)

3. 스킬은 설치용이 아니라 읽기용 자산이다 — 그리고 한 계열로만 통일하라

• 방법: 화자는 "스킬을 읽으면서 내가 배운 게 더 많다"고 말한다 — 스킬 파일은 기업·고수 엔지니어가 자기 모범사례를 통째로 적은 문서다. 받는 쪽은 AI만이 아니다.
• 모으는 곳으로 skills.sh를 본진으로 쓰고, 그 외 GitHub 저장소들을 둔다. 즐겨 쓰는 것으로 꼽은 것: Matt Pocock 계열(요구사항을 다듬는 스킬, 아키텍처 개선 스킬), Cursor의 코드 품질 리뷰 스킬(AI가 만들어낸 군살을 걷어낸다), 그리고 코드베이스를 감사해 다른 에이전트용 계획을 써주는 스킬.
• 운용 수칙 둘: 스킬을 수십 개 깔아 넣지 말 것. 그리고 한 계열로 묶을 것 — 스킬은 대부분 "좋은 코드"에 대한 주관이 담겨 있어서 서로 다른 사람의 스킬을 섞으면 지침이 충돌한다.
• 보정: 특정 사이트(skills.sh)를 본진으로 지목하지만 협찬 표기는 없었다. 영상은 별도로 Brilliant 스폰서 구간(16:56~17:58)과 자사 뉴스레터 권유가 있다 — 본문 팁과는 분리되어 있다.
• 출처: 같은 영상 — The Coding Sloth (05:05~08:26)

4. 반복 작업은 대화가 아니라 주기 실행(/loop)에 얹어라

• 방법: /loop에 시간 간격과 할 일을 주면 그 작업을 계속 돌린다 — 사실상 AI 크론잡. 화자가 실제로 돌리는 세 가지:
• 이슈 소화: 매일 열린 GitHub 이슈 중 하나를 골라 작업해두면 돌아왔을 때 PR이 기다린다.
• 보안·버그 스윙: 코드베이스를 훑어 알려진 취약점·버그를 찾으면 이슈로 등록한다.
• 기능 브레인스토밍: 코드베이스·PR·이슈를 보고 실제로 도움될 기능을 제안하게 한다.
• 보정: 화자 자신이 "기업과 오픈소스 프로젝트들이 시험 중이고 괜찮은 결과를 본다더라"라고 전해 들은 형식으로 말한다 — 본인 사례 외에는 실측이 아니다. 또 $20 플랜에서는 사용량 한도가 먼저 마주친다.
• 출처: 같은 영상 — The Coding Sloth (17:59~19:05)

5. 거의 안 쓰이는 명령 네 개 — /voice · /btw · ! 셸모드 · /context

• /voice: 타이핑 대신 말로 프롬프트를 넣는다. 화자의 관찰은 속도가 아니라 서술이 더 구체적으로 나온다는 점이다 — 소리 내어 생각하면서 자기가 원하는 것을 더 정확히 알게 된다.
• /btw: 작업 중간에 질문을 던지되 진행을 끊지 않고 대화 기록도 건드리지 않는다. 이 모드에서는 파일을 읽거나 명령을 쓰지 못하고 이미 가진 대화 내용으로만 답한다 — "왜 그렇게 결정했느냐"를 물을 때 쓴다.
• !로 시작하는 셸 모드: 그냥 터미널처럼 쓰되 출력을 AI도 함께 본다는 게 차이다.
• /context: 큰 작업을 시작하기 전에 잔량을 확인한다.
• 보정: 화자가 촬영 한 달 뒤에 붙인 자기 주석이 여러 번 나온다 — 예를 들어 영상에서 소개한 ultra plan 모드는 업로드 시점에 이미 없어졌다. 명령 목록은 반년은커녕 바뀜다는 증거로 읽는 게 맞고, 그대로 있는지는 직접 확인해야 한다.
• 출처: 같은 영상 — The Coding Sloth (10:44~12:33)

6. MCP는 코드베이스 밖과 직접 상호작용할 때만 붙여라

• 방법: 판별 기준이 하나다 — 코드베이스 밖에 있는 것을 직접 만져야 하는가. DB 시딩, GitHub, 배포, 분석, 브라우저 테스트, 문서 조회는 예다. 반면 "모범사례·패턴·이걸 어떻게 구현하나"는 지식이라 스킬로 충분하고, MCP로 붙이면 상시 컨텍스트 비용만 낸다.
• 부수적으로: 프론트엔드 시각 검증은 예전에 MCP가 필요했지만 지금은 내장됐다고 말한다.
• 출처: 같은 영상 — The Coding Sloth (09:57~10:43)

②다음으로 예상되는 질문: worktree·서브에이전트·플랜 모드는? 이 영상은 세 가지를 모두 다루지만 이미 수집한 팁들이다(worktree·서브에이전트 모델 티어 = 2026-08-13 코딩호, 서브에이전트 컨텍스트 구조 = 08-17 에이전트호). 오늘 더해진 것은 비용 감각 하나다 — $20 플랜에서는 서브에이전트 한 번에 한도가 난다.

7. Opus 5에는 작업을 쪼개 주지 마라 — 처음부터 전체 일을 줘라

• 방법: 예전에는 "먼저 이 파일들을 보고 브랜드 가이드를 만들고 → 그다음 사이트 계획을 세우고"처럼 단계로 먹였다. Opus 5는 그럴 필요 없이 전체를 받아 스스로 분해한다.
• 예문(영상의 실제 프롬프트, 원문 유지): "Build a one-page website for Northline Coffee, a small brand that sells coffee beans online. The goal is to help people understand the brand, choose a coffee, and place their first order. Use the logo, colors, product details, and photos in the brand asset folder. Build the finished website in the project folder."
• 핵심은 목표·재료 위치·산출물 위치를 한 문단에 다 넣는 것이다.
• 출처: Anthropic Just Revealed How to Prompt Opus 5 — Paul J Lipsky (04:14~05:20)

8. 노력(effort)은 높을수록 좋은 게 아니다 — low/medium을 기본값으로

• 방법: effort는 품질 다이얼이 아니라 생각량·시간·토큰 다이얼이다. 화자의 기본값 제안: Pro 플랜은 low, Max 플랜은 medium을 항상 쓰고 결과가 아쉬울 때만 올린다.
• 모델 선택도 같은 문법으로 단순화한다: Pro는 Sonnet 기본 + 복잡한 것만 Opus 5, Max는 Opus 5 기본.
• 교차확인(영상 밖): 이 영상이 근거로 든 Anthropic 공식 Opus 5 프롬프팅 가이드는 실재한다 — platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-claude-opus-5 (응답 길이·나레이션·작업 범위·서브에이전트 위임·자기교정을 다룬다고 예고됨). 다만 본문을 직접 읽지는 않았으므로, 아래 다섯 규칙은 공식 문서의 인용이 아니라 화자의 요약이다.
• 출처: 같은 영상 — Paul J Lipsky (02:37~03:34)

9. 일이 끝나는 지점과 하지 말 것을 프롬프트에 못박아라

• 방법: Opus 5는 시키지 않은 것까지 하려는 성향이 있다. 경계와 자율 범위를 함께 준다:

"Build only the home page. Link the buy buttons to the shop page that already exists. Keep the current logo, colors, and product name. Make small design choices yourself. Only ask me a question if the answer would change the whole website."

• 마지막 문장이 핵심이다 — 질문을 금지하는 게 아니라 질문할 가치가 있는 질문의 기준을 준다.
• 출처: 같은 영상 — Paul J Lipsky (05:21~06:03)

10. 응답 길이와 산출물 크기를 따로 제한하라

• 방법: 둘은 다른 문제다. 응답을 줄이는 지시를 넣어도 산출물은 여전히 거대해질 수 있다.
• 응답: "When you finish, tell me where the website is and give me no more than three short bullets explaining what you made."
• 산출물: "Keep the website to six parts… The main headline should be eight words or less. Each part should have no more than 70 words."
• 정밀할 필요는 없다 — "섹션 6개"만 주고 나머지를 맡기거나, "1분 30초안에 다 읽힐 수 있게"처럼 경험으로 규모를 지정해도 된다.
• 실측 근거: 화자가 이 프롬프트로 실제로 돌렸고, 시킨 대로 6개 섹션·3개 불릿이 나왔으며 평소보다 빨랐다(3분 미만)고 말한다. 1회 시연이지 보장은 아니다.
• 출처: 같은 영상 — Paul J Lipsky (06:04~07:59, 시연 09:59~11:30)

11. "끝나고 두 번 검토해라"는 이제 빼라

• 방법: 수년간 통했던 "끝난 뒤 모든 파일을 두 번 검토해 오류를 다 찾아 고쳐라"를 지우라. Anthropic 설명으로는 Opus 5가 진행 중 스스로 점검·교정하기 때문에, 전면 재검사를 강제하면 시간과 토큰만 늘고 결과는 나아지지 않는다.
• 단, "좋은 결과가 무엇인가"는 여전히 알려준다. 빼는 것은 기준이 아니라 *같은 검사를 반복시키는 지시*다.
• 보정: 이것은 모델별 조언이다 — 다른 모델(이전 세대·타사)에서는 여전히 명시적 재검토가 유효할 수 있다. 전역 규칙으로 옮기지 말 것.
• 출처: 같은 영상 — Paul J Lipsky (08:00~08:49)

12. 한 작업에 시간 상한(10~15분)을 걸어라

• 방법: 거의 다 된 것 같은데 완성이 안 될 때 시계를 본다. 10–15분 안에 안 풀리면 멈추고 다른 방식으로 넘어간다.
• 왜 의지로 안 되는가: 임상심리 전문가의 진단은 이게 변동보상 구조라는 것이다 — 슬롯머신처럼 가끔 완벽한 답이 나오고 대부분은 아니기에 "한 번만 더"가 생긴다. 기대감 자체가 보상이라 의지로 끊기 어렵다.
• 데이터: 응답자 46%가 멈추려던 지점을 정기적으로 지나쳤다. 그 집단의 58%가 수면 변화를 보고했고, 제때 멈춘 집단은 17%였다 — 설문 전체에서 가장 강한 상관이다.
• 보정: 화자가 명시한 한계를 그대로 옮긴다 — 자기선택 표본 1,300명(전체 개발자 모집단 아님)이고, 인과가 아니라 함께 나타난 것이다. 반대 방향일 수도 있다.
• 출처: The True Cost of AI Coding — Syntax (05:30~07:32, 처방 18:09~18:34)

13. 의지 대신 물리적 종료 신호를 하나 만들어라

• 방법: 이 영상에서 유일하게 번아웃을 피한 개발자의 장치는 전부 환경이지 규율이 아니었다:
• 사무실 조명이 5시에 꿼진다 — "어둠 속에 앉아 있지는 않으니까".
• 프롬프트 가능한 앱을 폰에서 전부 지웠다.
• 주말에 아이가 깨어 있으면 노트북을 안 열고, 주 단위·월 단위 고정 약속을 넣어 "마음이 동해도 물리적으로 불가능"하게 만들었다.
• 보정 — 이 팁의 가장 중요한 단서: 영상 자체가 집어낸다. 이 사람은 자영업자라 마감·배포 할당량을 남이 정하지 않는다. 조명 타이머·퇴근 시각 같은 장치는 그것을 누릴 수 있는 사람에게만 작동한다. 화자의 결론은 "건강한 프롬프팅은 개인 규율로만 지탱될 수 없다"였다.
• 출처: 같은 영상 — Syntax (18:34~21:33)

14. 결과(result)와 답(answer)을 구분하는 단계를 워크플로우에 남겨라

• 방법: 20년차 개발자(Redux 메인테이너)가 정착시킨 루틴은 이렇다 — ①내가 무엇을 어떻게 할지 먼저 정한다 ②서브태스크로 자료를 읽게 하고 아키텍처·리서치 문서를 만들게 한다 ③계획을 같이 읽고 서로 같은 그림을 보고 있다고 확신할 때까지 맞춘다 ④그때서야 파일을 고치게 한다 ⑤코드는 여전히 대부분 직접 읽는다.
• 근거로 인용된 문장: "AI는 결과를 주지만 결과는 아직 답이 아니다 — 사람이 평가하고 책임질 때 답이 된다." 화자는 이게 느리다는 것을 알고 의도적으로 고른 속도라고 밝힌다.
• 설문 수치 둘이 이 팁의 배경이다: 59%가 자기 코딩 실력이 퇴보한다고 느끼고 54%가 즐거움이 줄었다고 답했는데, 데이터상 두 집단은 거의 같은 사람들이었다. (실력 평가가 아니라 자기 인식임을 화자가 명시)
• 출처: 같은 영상 — Syntax (10:27~13:04)

15. 야망의 모양을 넓게가 아니라 깊게 바꿔라

• 방법: "이제 뭐든 만들 수 있다"는 무한가능성의 맛이 밤샘 작업을 부른다. 그걸 끊은 것은 자제력이 아니라 계산이었다 — "나만 이 힘을 가진 게 아니고, 모두 만드느라 아무도 안 사면 골드러시가 아니다."
• 그래서 범위를 1~2개로 좁히고 거기서 수직으로 깊게 파는 쪽으로 바꾸자 조바심이 사라졌다 — "내일 트위터에서 남이 먼저 런칭하는 걸 볼 일이 없으니 그냥 자러 갈 수 있다."
• 출처: 같은 영상 — Syntax (14:04~16:11)

16. 하네스는 소모품이다 — 월 1~2회 정기 감사로 덜어내라

• 문제 진단: 예전에는 모델이 지시를 안 따라서 "무조건 이 파일부터 읽어라", "바로 구현하지 말고 계획부터" 같은 울타리를 치는 과정이 필요했다. 그런데 코딩 에이전트 자체가 이미 하나의 하네스다(파일 읽기·수정·터미널·메모리·툴·스킬이 내장). 내가 만든 규칙은 그 위에 얹은 두 번째 하네스고, 제품이 진화하면 중복 지시·방해로 성질이 바뀜다.
• 방법: 더 붙일까가 아니라 덜어낼까로 질문을 바꾸고, 그걸 한 달에 한·두 번 정기 작업으로 삼는다. 감사 대상 여섯: 낡은 규칙 / 중복 지식 / 과도한 전역 컨텍스트 / 너무 넓게 잡힌 스킬 / 불필요한 훅·MCP / 제품 기본기능과 겹치는 설정.
• 출처: 클로드 코드 Dynamic Workflow — 낡아빠진 하네스는 다이어트가 필수입니다...! — 개발동생 (00:00~02:44, 결론 23:16~24:14)

17. Dynamic Workflow 부르는 법 세 가지와 저장법

• 방법: 세 경로 모두 같은 것을 깨운다.
• 프롬프트에 ultracode 키워드를 넣는다(키워드가 하이라이트되고 "이번 턴에 다이나믹 워크플로우가 요청됨"이 뜼다).
• 그냥 자연어로 "워크플로우로 …해 줘"라고 한다.
• 저장된 슬래시 명령으로 부른다.
• 진행 상황은 /workflow로 들어가 단계별·서브에이전트별로 본다. 백그라운드라 현재 세션은 계속 다른 일을 할 수 있다.
• 저장: 실행 중 목록에서 S키를 누르면 이름을 붙여 프로젝트의 워크플로우 폴더에 자바스크립트 파일로 저장된다 — 다음부터 재사용.
• 기본 내장 워크플로우로 deep research가 있고, 이게 구조의 표본이다: 검색(서브에이전트 6개 병렬) → 페치(28개) → 적대적 검증(75개) → 종합. 메인 세션은 최종 보고서만 받아 컨텍스트를 아낀다.
• 보정: 수치(동시 16개·누적 1,000개 상한)는 화자가 "앵트로픽 공식 문서 기반"이라고 말한 것이고 문서를 화면으로 보여주진 않았다.
• 출처: 같은 영상 — 개발동생 (03:53~09:30, 저장법 20:31~21:44)

18. 감사(스캔)와 적용(수정)을 두 워크플로우로 쪼개고 사이에 사람을 넣어라

• 방법: 하나로 합칠 수 있지만 화자는 분리를 권한다.
• 1단계 — 하네스 레거시 스캔(읽기 전용): 인벤토리 → 분석(전역 컨텍스트·스킬·제품중복·권한범위를 각각 다른 서브에이전트가) → 분류 계획 → 적대적 리뷰. 보고서만 낸다.
• 사람이 보고서를 읽는다.
• 2단계 — 하네스 다이어트: 그 보고서를 받아 저위험 항목만 실제로 고친다. 손으로 하나씩 고치지 말 것.
• 분류 어휘를 먼저 정해주는 게 핵심이다: 유지 / 압축 / 이동 / 분할 / 변환 / 삭제, 그리고 각 항목을 "사용자 확인 필요"와 "기계적으로 지워도 되는 것"으로 갈라 표로 낸다.
• 실측 수치(화자 환경 1회): 스캔은 에이전트 16개로 17분 돌았고 항목 109개를 찾았으며 약 160만 토큰을 썼다. 적용 결과는 스킬 10개 정리, SKILL.md 본문이 2,600줄 → 1,800줄(760줄 감량), 활성 스킬 29→28개. → 비용이 작지 않다는 게 같이 읽혀야 할 숫자다.
• 출처: 같은 영상 — 개발동생 (11:15~13:02, 결과 18:31~23:15)

19. 마지막 단계에 적대적 리뷰어를 세워 "지우면 위험한 것"을 반박시켜라

• 방법: 삭제·축소로 분류된 항목을 그대로 실행하지 않고, 비판적 시각의 에이전트를 여러 개 세워 부작용을 반박시킨 뒤 최종 보고서를 낸다. 프롬프트 문구로는 "삭제하거나 줄이면 오히려 위험해짐 수 있는 항목을 반박적으로 검토하라".
• 같은 이유로 분석 단계도 관점별로 쪼개다(인벤토리 / 전역 컨텍스트 / 스킬 / 제품 중복 / 권한 범위). 한 에이전트에 전부 맡기면 편향된 시각이 그대로 결론이 된다.
• 출처: 같은 영상 — 개발동생 (13:43~15:47, 실행 17:38~18:30)

20. 워크플로우·서브에이전트·스킬·에이전트팀은 "계획을 누가 들고 있나"로 갈라라

• 방법: 기능 목록을 외우는 대신 한 축으로 정리한다.

• 스크립트가 계획을 쥔기 때문에 수십~수백 개 규모까지 간다 — 반대로 작은 일에는 과잉이다. 화자도 기본 effort를 ultracode로 두지 않고 필요할 때만 불러낸다고 밝힌다.
• 적합한 일의 모양: 적대적·다각도 검증이 필요한 작업. 반대로 단일 사실 조회·짧은 수정은 아니다.
• 출처: 같은 영상 — 개발동생 (09:57~11:14)

시도 후보

• 하네스 레거시 스캔을 우리 것으로 한 번 돌려보기(팁 16·18). 대상은 CLAUDE.md가 아니라 공용 프롬프트·가이드 79개·액션 설명문이다. 읽기 전용 보고서까지만 받아보면 적용 여부는 보고 결정하면 된다.
• 하나의 프롬프트에서 "끝나고 재검토해라"를 빼보기(팁 11). 가장 싼 실험이고 되돌리기도 쉽다.
• 재반복 지점에 시계 보기(팁 12). 도구도 설정도 필요 없다.

오늘의 영상

• I Have Spent 1000+ Hours With Claude Code. This Is What I Learned — The Coding Sloth · 조회 18.1만 · 22:30 · 2026-08-18 — 오늘 최고 밀도. 기능을 나열하지 않고 티어 랭킹을 매겨 "필수라고 말하지만 안 쓰게 되는 것"을 걸러낸 것이 이 영상의 가치다. 반면 과장 기본값이 높고("무료 스티커 받았다" 수준의 개그 밀도) 촬영 후 한 달 지나 올린 탓에 자기 설명을 영상 안에서 여러 번 발무른다(이건 정직함으로 치는 게 맞다). 중간에 Brilliant 스폰서 구간.
• Anthropic Just Revealed How to Prompt Opus 5 — Paul J Lipsky · 조회 8.6만 · 12:18 · 2026-07-27 — 공식 문서 하나를 다섯 규칙으로 압축하고 그 다섯을 하나씩 쌓아 하나의 프롬프트를 완성해 보인 다음 실제로 돌려본다. 팁 영상의 모범 구조다. 공식 가이드 자체를 보여주진 않으므로 요약의 충실도는 검증 안 됨.
• The True Cost of AI Coding — Syntax · 조회 11.2만 · 24:27 · 2026-08-14 — 오늘 유일한 반대편 시각이고, 드물게 신선한 회의론이다. 자체 설문(1,300명) + 번아웃 당사자·임상심리 전문가·번아웃을 피한 사람 인터뷰를 교차한다. 특히 보기 드문 미덕은 자기 데이터의 한계를 계속 먼저 말한다는 것(자기선택 표본·상관≠인과·표본 부족 구간 명시). 다만 팁 밀도는 낮다 — 24분 중 실행 가능한 것은 다섯 줄이고 나머지는 진단이다.
• 클로드 코드 Dynamic Workflow | 낡아빠진 하네스는 다이어트가 필수입니다...! — 개발동생 · 조회 1.7만 · 24:52 · 2026-06-04 — 신기능 소개 영상인데 신기능을 자기 설정을 줄이는 데 쓴다는 점이 다르다. 수치를 숨기지 않고(160만 토큰·17분·109항목), 적용 결과를 줄 수로 보여주며(2,600→1,800줄), 자기 스킬 하나가 보관 처리된 이유까지 설명한다. 팀보성 없음. 다만 프롬프트 전문은 깃헙으로 넘기며 영상 안에서는 읽힐 만큼 보여주지 않는다.

지켜볼 점 / 내일 주제 후보

• 1순위: 오늘 모두 4편 상한에 걸려 밀린 것들이 너무 좋다. 컷오프를 통과한 17편 중 4편만 읽었다 — 특히 The problem with AI agents..(Low Level, 조회 26.3만)는 오늘 읽은 회의론과 다른 축(심리·노동이 아니라 기술)이라 직접 대체되지 않는다. Claude Code Output Styles Made Opus 5 Readable Again(어제 업로드)도 응답 길이 문제(팁 10)의 도구 쪽 해법이라 짝이 맞는다.
• 한국어 코딩 층은 영어권 중계가 아니다. 8/25 데이터분석호·AX호가 발견한 "언어별 층 분할"과 다른 모양이다 — 오늘 Dynamic Workflow는 한·영 양쪽에서 모두 상위에 있었고(개발동생·AI싱크클럽 vs Nate Herk) 간격도 거의 없었다(6/04 vs 5/30). 개발 주제에서는 한국어 채널이 수일 안에 따라붙는 듯하다.
• 에이전트 감사를 한 호 통째로 — 오늘 팁 16–19와 8/17 에이전트호의 반대편("사내 AI 에이전트 만들면 생기는 문제들")을 엮으면 "만든 것을 어떻게 거두는가"만 다룬 호가 가능하다.
• 아직 안 잡힌 것: AI 코딩의 보안 측면(생성 코드의 취약점·공급망). 오늘 검색 3회에서 한 편도 상위에 안 떴다.

이 호의 한계 (정직 표기)

• 네 편 모두 자막만 읽고 증류했다. 화면으로만 보여준 것(프롬프트 전문·보고서 표 내용·UI 위치)은 확인하지 않았다.
• 팁 7~11은 Anthropic 공식 문서의 인용이 아니라 화자의 요약이다. 공식 가이드가 실재한다는 것까지만 웹 검색으로 확인했고(주소 팁 8에 명기), 문서 본문은 읽지 않았다.
• 팁 12~14의 퍼센트는 모두 자기선택 표본 1,300명의 것이고 인과가 아니다. 영상이 반복해서 밝힌 내용을 그대로 옮겼다.
• 팁 17의 수치(동시 16개·누적 1,000개)는 영상이 "공식 문서 기반"이라고만 말한 것이지만, 이 하네스에서 같은 수치가 확인되어 교차검증되었다.
• 팁 18의 감량 수치(2,600→1,800줄 등)은 화자 환경에서 1회 실행한 결과다. 다른 하네스에서 같은 비율이 나온다는 보장이 없고, 무엇을 지운 것이 올바른 판단이었는지도 영상이 검증하지 않는다(적대적 리뷰 단계가 바로 그 걱정 때문에 들어간 것이다).
• 오늘 팁은 전부 실행 전이다.