유튜브 AI 팁 보고서 — 2026-08-17 — 에이전트

오늘의 영상 4편 (전부 최근 6개월 이내) · 누적: 팁 158개 / 다룬 영상 35편 한국어 2편 + 영어 2편. 에이전트를 어떻게 만드는가보다 무엇을 주지 않을 것인가로 수렴한 날.

한국어·영어로 네 번 검색해 40여 편을 훑고, 6개월 규칙(컷오프 2026-02-18)을 통과한 4편의 자막을 통독했습니다. 이 주제는 이틀 연속 "내일 후보 1번"으로 밀려 있던 것인데, 밀린 값을 했습니다 — 오늘 통과한 영상들은 겹치지 않는 네 층에 각각 서 있었습니다: 설계 원칙(안티패턴), 조직 도입(만들지 마라), 개인 작업 흐름(하루 네 창), 기능 구조(스킬·서브에이전트·훅).

한눈에 (TL;DR)

• 에이전트를 잘 다룬다는 건 더 많이 붙이는 능력이 아니라 뭘 안 줄지 아는 능력이다. Anthropic이 낸 첫 공식 인증 시험을 뜯어본 발표가 다섯 시나리오를 전부 안티패턴부터 뒤집는데, 다섯 개를 관통하는 방향이 하나였습니다 — 툴도 덜 주고, 컨텍스트도 덜 주고, 정보도 덜 준다. 툴 상한은 4~5개, 넘으면 툴을 늘리지 말고 에이전트를 쪼갠다.
• 오늘 가장 반직관적인 팁: 검증하라고 만든 에이전트에게는 정보를 덜 줘라. 크리틱 에이전트에 주장과 근거만 넘기고 그 판단에 이르기까지의 사고 과정은 일부러 뺍니다. 이유가 그룹싱크 — 에이전트들이 서로의 생각을 들여다보면 하나의 결론으로 수렴해 버립니다.
• 오늘 유일하게 반대 방향을 가리킨 영상: "커스텀 에이전트를 만들지 마라." 6개월 걸려 만드는 동안 범용 에이전트가 더 발전해 있고, 만들고 나면 업무가 변할 때마다 누군가 뜯어고쳐야 합니다. 그럼 SI와 뭐가 다른가. 대안은 에이전트가 아니라 에이전트가 일할 수 있는 환경을 먼저 만드는 것.
• "결과는 나오는데 쓰는 사람이 이해를 못 한다." 제안서·견적서·결산을 전부 자동화했다가 방향을 되돌린 실패담이 나옵니다. 자동화가 사람의 학습 구조를 끊으면 그 위 단계로 올라갈 길도 같이 없어집니다.

오늘의 팁

1. 모델 응답을 바로 쓰지 말고 stop_reason으로 루프를 돌려라

• 방법: 먼저 사실관계 하나 — LLM은 툴을 실행하지 못합니다. 확률적으로 다음 단어를 예측하는 것 말고는 아무것도 못 하고, 툴을 쥐어 줘도 "이 툴을 이런 값으로 부르면 된다"고 알려 줄 뿐 실제로 부르는 건 내 코드입니다. 그래서 응답이 오면 답을 바로 쓰는 게 아니라 모델이 왜 멈췄는지(stop_reason)를 먼저 봅니다 — tool_use면 툴을 실행해 결과를 다시 넣고 한 바퀴 더, end_turn이면 빠져나옵니다. 루프를 빠져나온 자리가 사람이 개입할 지점이기도 합니다(신뢰도를 보고 괜찮으면 채택, 아니면 사람에게 에스컬레이션). ★핵심 함정: 토큰이 떨어져서 멈춘 경우에도 응답은 옵니다. 문장도 그럴듯하게 옵니다. stop_reason을 안 보면 중간에 잘린 답을 완성된 답으로 알고 그대로 씁니다.
• 출처: Anthropic 첫 공식 시험이 꼽은 에이전트 안티패턴 5가지 — AgentOS (05:46~09:30)
• 보정: 시험 자체가 특정 회사 제품 인증이므로 API 필드 이름은 그 회사 규격입니다. 다만 "왜 멈췄는지를 보고 분기한다"는 구조는 어느 모델 API든 동일한 층입니다.

2. 툴은 한 에이전트에 4~5개까지 — 넘으면 툴을 늘리지 말고 에이전트를 쪼개라 ★

• 방법: 시험이 이 질문에 숫자로 답합니다. 네다섯 개를 넘어가면 추론 품질이 떨어지고 툴 선택이 불안정해집니다. 발표자의 비유가 정확합니다 — 집에 목수를 불렀는데 배관 공구·목공 공구·전기 공구를 다 들고 와서 "뭐든 할 수 있다"고 하는 사람. 아마 그 사람 말고 진짜 목수를 원할 겁니다. 함수형 프로그래밍의 "함수는 한 가지 일만 한다"를 에이전트에 그대로 적용해, 툴 벨트를 키우는 대신 에이전트를 쪼갭니다.
• 출처: Anthropic 첫 공식 시험이 꼽은 에이전트 안티패턴 5가지 — AgentOS (10:38~13:40)
• 보정: 발표 중 화자는 "툴 한두 개"라고 말하고 슬라이드에는 "4~5개"가 적혀 있어 숫자가 어긋납니다. 영상 진행자도 이 불일치를 짚습니다. A/B 근거는 제시되지 않았고, 어디서 나온 임계값인지 설명도 없습니다 — 방향(적을수록 낫다)은 신뢰하되 숫자는 눈금이지 법칙이 아닙니다.

3. 규칙 파일은 한 곳에 몰지 말고 3단계로 나눠 둬라

• 방법: 규칙 마크다운을 세 자리에 둡니다 — 홈 디렉토리(모든 프로젝트에 적용) / 프로젝트 루트(그 저장소에만) / 디렉토리별(그 폴더에서 작업할 때만). 셋 다 로드돼 병합되고, 충돌하면 가장 구체적인 파일이 이깁니다. 한 파일에 다 몰아넣으면 특정 폴더에서만 필요한 지침이 상관없는 작업까지 따라와 조용히 부딪히고, 어디서 충돌했는지도 안 보입니다.
• 출처: Anthropic 첫 공식 시험이 꼽은 에이전트 안티패턴 5가지 — AgentOS (09:31~10:37)
• 보정: 없음. 다만 이건 특정 도구의 파일 규약이라 다른 에이전트 프레임워크에 그대로 옮기려면 "적용 범위별로 규칙 파일을 분리하고 구체적인 것이 이기게 한다"는 원리만 가져가야 합니다.

4. 검증 에이전트에는 주장과 근거만 주고 사고 과정은 빼라 — 그룹싱크 차단 ★

• 방법: 크리틱(비평) 서브에이전트를 만들 때 넘기는 것은 claim(주장)과 evidence(근거) 딱 두 개입니다. 그 판단이 나오기까지의 사고 과정은 일부러 뺍니다. 검증하라고 만든 에이전트한테 정보를 덜 주는 셈인데, 이유가 그룹싱크입니다 — 여러 에이전트를 모아 놓고 서로 이야기하게 하면 하나의 결론으로 수렴해 버립니다. 발표자의 비유: 파티에서 나만 피자가 싫은데 다들 피자를 원하니 분위기 깨지 않으려고 따라가게 되는 것, 에이전트도 같은 식으로 움직인다는 겁니다. 그래서 각 에이전트에게 필요한 조각만 잘라 준다.
• 출처: Anthropic 첫 공식 시험이 꼽은 에이전트 안티패턴 5가지 — AgentOS (12:09~14:05)
• 보정: 그룹싱크 주장을 뒷받침하는 실험 데이터는 영상에 없습니다(관찰과 비유). 다만 "검증자에게 생성자의 추론을 보여 주면 검증이 무뎌진다"는 방향은 사람의 코드 리뷰에서도 익숙한 현상이라 이식 위험이 낮은 편입니다.

5. CI·파이프라인에선 대화형으로 부르지 말고, 기다려도 되는 일은 Batch로 넘겨라

• 방법: 파이프라인 안에서 코딩 에이전트를 대화용으로 부르면 권한을 묻는 자리에서 멈춰 오지 않을 답을 기다립니다. -p 같은 비대화식 옵션으로 돌리고 출력을 JSON으로 받아야 파이프라인이 읽을 수 있습니다. 그리고 급하지 않은 작업은 Batch API로 넘깁니다 — 토큰 비용 절반에 24시간 안에 결과가 옵니다("낮잠을 자든 하루 쉬든 하고 오면 돼 있다").
• 출처: Anthropic 첫 공식 시험이 꼽은 에이전트 안티패턴 5가지 — AgentOS (16:39~17:57)
• 보정: 자막이 뭉개진 대목이라 옵션 문자열은 문맥으로 복원한 것입니다. 배치 50%·24시간은 공급사 정책이라 바뀔 수 있습니다.

6. 커스텀 에이전트를 만들기 전에 "6개월 뒤에도 이게 최선인가"를 물어라 ★

• 방법: 대기업 임직원 3천여 명 교육과 AX 컨설팅에서 반복해 부딪힌 벽 세 가지를 그대로 옮깁니다. ①유지보수: 업무는 계속 변하는데 구조가 굳은 에이전트는 그때마다 뜯어고쳐야 한다 — 그러면 SI와 무엇이 다른가. ②전제 조건: 커스텀 에이전트를 만들려면 데이터·IT 인프라·보안을 다 건드려야 하고, 그전에 암묵지를 형식지로 바꾸고 데이터를 라벨링하는 DX 장벽을 먼저 만난다. ③속도 차이(결정적): 6개월 걸려 만드는 동안 범용 에이전트는 하루에도 수십 개씩 업데이트되고 새 모델은 두 달 주기로 나온다 — 완성 시점에 이미 낡는다. 그래서 만들어도 되는 것은 변화가 적고 자주 반복되는 업무로 한정합니다.
• 출처: 사내 AI 에이전트 만들면 생기는 문제들이 있습니다 — 퇴근길 AI (01:07~02:41, 06:25~07:00)
• 보정: 화자가 교육·컨설팅 사업자라 "범용 에이전트를 먼저 쓰라"는 결론이 자기 서비스와 정렬돼 있다는 점은 감안해야 합니다. 다만 자기 팀의 자동화 실패를 먼저 공개하고 방향을 바꿨다고 말하는 구조라 홍보라기엔 대가가 큰 편입니다. 근거는 사례 관찰이고 수치는 없습니다.

7. 결과만 내는 자동화는 사람의 학습을 끊는다

• 방법: 화자 팀도 제안서·견적서·결산까지 전부 자동화하는 데 집중했다가 문제를 만났습니다 — 결과는 나오는데 그걸 쓰는 사람이 왜 그렇게 나왔는지 이해를 못 합니다. 맥락 파악이 안 되니 다시 검토하게 되고 자동화의 의미가 사라집니다. 그리고 더 중요한 이유: 사람과 AI가 같이 일하며 사람이 성장하고 인사이트가 생겨야 그다음 레벨의 일을 할 수 있는데, 그 업무를 자동화해 버리는 순간 위로 올라갈 학습 구조가 사라집니다. 그래서 방향을 "AI와 인간이 함께 고민하고 학습하는 구조"로 완전히 바꿨습니다.
• 출처: 사내 AI 에이전트 만들면 생기는 문제들이 있습니다 — 퇴근길 AI (02:45~03:30)
• 보정: 어떤 업무가 이 함정에 걸리고 어떤 업무는 자동화해도 되는지의 경계선은 제시되지 않습니다("반복적이고 변화 적은 것"이라는 느슨한 기준뿐).

8. 사람과 AI가 둘 다 읽는 형식에 맥락을 두고 학습 루프를 돌려라

• 방법: 자동화 대신 택한 구조는 중재자 역할의 에이전트 하나입니다. 예를 들어 영업 리드가 들어오면 그 에이전트가 메신저·업무 시스템의 내용을 요약해 알려 주고, 동시에 구글 드라이브 폴더에 프로젝트 내용을 MD 파일로 정리합니다(README.md, log.md, 회의록.md처럼). 그러면 팀원은 자기 AI를 그 폴더에 연결해 같은 파일 위에서 제안서를 쓰고 견적서를 검토합니다. 핵심은 AI가 읽을 수 있는 형식과 팀원이 읽을 수 있는 형식이 같은 파일이어야 한다는 것 — 팀원이 쓴 걸 AI가 다시 읽고, AI가 쓴 걸 팀원이 다시 읽고, 다른 팀원의 작업도 AI가 빠르게 학습해 참여합니다. 반복이 쌓이면 팀의 지적 자산이 축적됩니다.
• 출처: 사내 AI 에이전트 만들면 생기는 문제들이 있습니다 — 퇴근길 AI (03:30~04:50)
• 보정: 자동 자막이 회사 내부 도구 이름을 뭉개서(‘행보관’ 등) 어떤 제품인지 특정할 수 없었습니다 — 그 부분은 싣지 않았습니다. 그리고 "지적 자산이 축적된다"는 아직 진행 중인 시도지 결과 보고가 아닙니다.

9. 에이전트 도입은 소프트웨어 도입이 아니라 '지능 임대'다 — 온보딩부터 하라

• 방법: 개념부터 갈라야 한다는 지적입니다. 엑셀은 정적입니다 — 함수와 매크로를 짜 두면 스스로 판단하지 않고 그 메커니즘대로만 돕니다. 범용 에이전트는 지능이라 스스로 추론하고 판단하고 매일 더 똑똑해집니다. 우리가 하는 건 소프트웨어 도입이 아니라 지능을 임대해 구독하는 것. 그래서 이 그림으로 정리합니다 — 매일 아침 IQ 200짜리 천재가 신입사원으로 온다. 그런데 우리 회사 맥락도, 팀이 일하는 방식도, 고객이 누구인지도, 지난주에 무슨 결정을 했는지도 모른다. 이 천재가 일을 잘할 수 있을까. 그러니 커스텀 에이전트를 하나 만들어 던져 주는 것보다 온보딩 매뉴얼·조직도·프로세스·결정의 맥락을 주는 게 먼저입니다.
• 출처: 사내 AI 에이전트 만들면 생기는 문제들이 있습니다 — 퇴근길 AI (00:00~00:12, 05:10~06:10)
• 보정: 프레이밍이라 실행 단계가 없습니다. 팁 8이 그 실행판입니다.

10. 창은 4개까지, 그리고 창마다 사고 강도를 다르게 배정하라

• 방법: 단축키 하나로 코딩 에이전트 창 4개를 띄우되 전부 같게 두지 않습니다 — 위 둘은 high effort, 아래 둘은 medium/low. 이유가 명확합니다: 큰 배치 작업("쓸 만한 기능 다섯 개를 뽑아 봐")은 오래 걸리니 high 창에 던져 놓고, 그동안 단순 질의("이 코드베이스가 어떤 언어를 쓰는지 알려 줘")는 low 창에 넣으면 훨씬 빨리 답이 옵니다. 실제로 아래 창이 먼저 답을 내놓는 장면을 보여 줍니다. 4개인 이유는 도구 한계가 아니라 사람의 동시 처리 한계입니다 — "50개 에이전트를 돌리는 척하지 않겠다, 내 정신적 수용력은 대략 네 갈래다."
• 출처: The Agentic Engineer Workflow You Need In 2026 — Zen van Riel (00:31~02:28)
• 보정: 4라는 숫자는 본인 경험치지 권장값이 아닙니다(스스로도 그렇게 말합니다). 창을 늘리면 API 사용량도 따라 늘어납니다.

11. 3~4개월 살아남은 패턴만 채택하라 — 유행 방법론은 결국 도구에 흡수된다

• 방법: 화자는 스펙 주도 개발이니 무슨 메서드니 하는 방법론들을 일부러 다루지 않습니다. 이유: 지난 3년간 화제가 됐던 AI 프로젝트 중 지금도 유효한 게 몇이나 되는지 세어 보라. 그리고 잘 되는 것은 결국 도구 안으로 흡수됩니다 — 예전엔 마크다운 파일로 손수 관리하던 할 일 목록이 이제 기본 기능인 것처럼. 그래서 그의 채택 규칙은 "과열을 일단 지나 보내고 3~4개월 버틴 것만 적용한다"입니다. 그가 영상에서 보여 주는 것도 "6개월 뒤에도 유효할 원칙"으로만 한정했다고 못 박습니다.
• 출처: The Agentic Engineer Workflow You Need In 2026 — Zen van Riel (03:22~04:28)
• 보정: 방법론을 "짐꾹(gimmick)"이라 부르는 대목은 다소 과합니다 — 본인도 곧바로 "유행이라는 뜻은 아니다"라고 물러섭니다. 그리고 이 규칙 자체가 신선한 것을 놓치는 쪽으로도 작동합니다.

12. 프롬프트 저장소를 복붙하지 말고 엔지니어링 책의 패턴을 커맨드로 만들어라

• 방법: 별 6만 개짜리 프롬프트 모음을 통째로 복사해 "너는 시니어 엔지니어다, 실수하지 마라" 같은 걸 쓸 수도 있습니다. 대신 화자가 권하는 건 오래된 엔지니어링 책의 개념을 커맨드로 만드는 것 — 예로 든 smell 커맨드는 Clean Code와 디자인 패턴 책에 기대고 있습니다. 논리가 중요합니다: 그 개념들은 이미 모델 안에 있고, 커맨드는 그쪽 방향으로 밀어 주는 역할이라는 것. 그래야 세계 최고의 소프트웨어를 만든 패턴을 따르게 할 수 있습니다. ★반면 코드 리뷰 커맨드는 공유하지 않겠다고 명시합니다 — 프로그래밍 언어, 작업의 복잡도, 사람 리뷰어가 몇 명이고 그들의 선호가 무엇인지, 팀이 합의한 코드 스타일에 따라 전부 달라지므로 하나로 맞는 리뷰 커맨드는 없다는 것.
• 출처: The Agentic Engineer Workflow You Need In 2026 — Zen van Riel (05:04~07:24)
• 보정: [홍보성] 이 대목 앞뒤로 "내 워크플로우와 스크립트는 설명란 링크에서"가 세 번 반복됩니다. 즉 커맨드를 공유하지 않는 이유가 원칙 때문만은 아닐 수 있습니다 — 다만 리뷰 커맨드가 팀·언어에 종속된다는 논거 자체는 타당합니다.

13. 정직한 숫자는 5배가 아니라 30~60%다 — 하루 1만 줄 PR은 팀에서 안 통한다

• 방법: 화자의 관찰입니다 — 에이전틱 코딩을 가장 잘하는 사람들은 5배 생산성을 외치고 다니지 않습니다. 그들이 말하는 건 30~60% 향상이고, 프로덕션 확인용 일회성 스크립트 같은 특정 작업에선 훨씬 빠릅니다. 이유는 간단합니다: 실제 프로젝트에서 코딩은 엔지니어링 업무의 큰 부분이 아닙니다. 그리고 현실 제약 — 매일 1만 줄을 들고 팀에 가면 더 작은 PR로 되돌려보내지거나, 너무 빨리 생성된 코드가 만든 장기 버그를 다 같이 떠안게 됩니다. 화자 본인의 실패담이 붙습니다: 복잡한 저장소에서 이틀 만에 새 기능을 만들어 PR을 올렸다가 선임에게 "기능은 되는데 장기 아키텍처 관점이 없다"는 지적을 받았고, 자기가 코드를 훑어만 보고 올렸다는 걸 인정합니다.
• 출처: The Agentic Engineer Workflow You Need In 2026 — Zen van Riel (11:34~12:56, 15:56~16:37)
• 보정: 30~60%는 출처 없는 체감치입니다(본인 관찰). 다만 과장 방향이 아니라 축소 방향의 주장이라 유튜브 문법상 드문 종류이고, 본인 실패를 근거로 붙인 점이 신뢰를 높입니다.

14. 스킬·서브에이전트·MCP는 컨텍스트 비용 구조가 다르다 ★

• 방법: 셋을 "무엇이 제일 좋은가"로 고르지 말고 언제 공간을 아끼고 싶은가로 고르라는 정리입니다.
• 스킬 = 2단계 로딩. 평소엔 이름과 한 줄 설명(스킬당 50~100바이트)만 올라가 있고, 호출된다고 판단될 때 비로소 본문 전체를 불러옵니다. 참고 파일도 필요한 시점에 읽습니다. 전체가 50KB여도 안 쓸 때는 공짜에 가까워서 20개를 만들어도 부담이 없습니다.
• 항상 로드되는 규칙 파일(CLAUDE.md 부류) — 세션 시작마다 통째로 올라갑니다. 그래서 항상 지켜야 할 핵심 규칙만 여기 두고, 가끔 쓰는 참고 자료와 반복 작업은 스킬로 분리합니다.
• MCP — 서버를 연결하면 거기 있는 모든 도구의 설명이 시작부터 올라가고 세션마다 반복됩니다. 도구가 50개면 안 써도 50개 전부. 많이 붙일수록 부담이 커집니다.
• 서브에이전트 — 실행 중에는 가장 효율적입니다(별도 컨텍스트에서 돌고 메인엔 요약만 돌아옵니다). ★그런데 함정: 이름·도구·시스템 프롬프트 같은 정의는 시작할 때부터 로드됩니다. 10개를 만들어 두면 안 쓴 에이전트도 매번 자리를 차지합니다 — MCP와 같은 부류의 비용입니다.
• 출처: 메타 엔지니어의 클로드코드 완벽 가이드 [심화편] — 실밸개발자 (05:14~09:09)
• 보정: 50~100바이트라는 수치는 화자가 "라고 한다"로 전한 값이라 직접 측정은 아닙니다. 나머지 구조 비교는 각 기능의 공개 동작과 일치합니다.

15. 훅이 도는 동안 에이전트는 멈춰 기다린다 — 타임아웃을 걸고 무거운 건 백그라운드로

• 방법: 훅은 이벤트 기반 자동화입니다. 이벤트가 나면 매처가 조건을 검사하고 맞으면 액션이 자동 실행됩니다. 흐름은 네 자리 — PreToolUse(툴 호출 직전, 입력값 검증·승인·차단·수정) → 툴 실행 → PostToolUse(직후, 결과 검증이나 린트·포맷 같은 후처리) → Notification(사용자 응답 대기 시 알림·로깅·외부 서비스 연동) → Stop(턴 종료 시 최종 정리·보고서 생성·상태 저장). 만드는 법은 손으로 JSON을 쓰는 게 아니라 그냥 말로 시킵니다("응답 대기 상태에 들어가면 알림과 효과음이 나는 훅을 만들어 줘"). ★주의: 훅이 실행되는 동안 에이전트는 멈춰서 기다립니다. 훅이 끝나야 다음 작업이 진행되므로 오래 걸리는 작업을 넣으면 전체가 느려집니다 — 타임아웃을 반드시 설정하고 무거운 작업은 백그라운드로 돌립니다.
• 출처: 메타 엔지니어의 클로드코드 완벽 가이드 [심화편] — 실밸개발자 (26:47~30:28)
• 보정: 없음. 데모에서 훅이 실제로 트리거되는 것까지 확인합니다.

16. 서브에이전트끼리는 통신할 수 없다 — 결과 통합은 메인에서 하라

• 방법: 서브에이전트는 메인 세션하고만 소통합니다. 서브에이전트끼리는 직접 메시지를 주고받을 수 없습니다(그게 필요하면 여러 인스턴스가 팀으로 협업하는 별도 기능의 영역입니다 — 리더가 조율하고 팀원끼리 메시지를 주고받는 구조). 이 제약에서 나오는 실무 규칙 넷: ①독립적인 작업만 병렬로 분배한다(의존성 있는 작업의 무리한 병렬화 금지) ②각자에게 명확한 역할과 범위를 준다(테스트도 하고 DB 마이그레이션도 하고 프론트·백엔드도 하는 만능 서브에이전트 금지) ③반환된 결과는 메인에서 통합한다 ④에러가 나도 전체가 멈추지 않게 대비책을 둔다, 그리고 결과를 검증 없이 그대로 쓰지 않는다. 판단 기준은 두 질문으로 압축됩니다 — 작업이 독립적인가? 컨텍스트 오염이 우려되는가? 둘 다 아니면 메인 대화에서 순차로 하는 게 낫습니다("간단한 건 직접 하는 게 빠르고, 오래 걸리는 일은 심부름을 시키고 결과만 받는다").
• 출처: 메타 엔지니어의 클로드코드 완벽 가이드 [심화편] — 실밸개발자 (17:23~18:15, 25:08~26:05)
• 보정: 없음. 다만 "에이전트 팀" 기능은 소개만 하고 다음 편으로 미뤄서 그쪽 실측은 이 영상에 없습니다.

17. 경쟁 모델에게 계획을 리뷰시키는 커스텀 MCP를 만들어라 ★

• 방법: 플랜 모드에서 계획을 세운 뒤, 그 계획을 다른 회사 모델의 API로 보내 "이 구현 계획에 빠진 부분이나 리스크를 지적해 달라"고 하고 결과를 돌려받는 MCP 서버를 만듭니다. 만드는 방법도 자연어 한 줄입니다 — "○○ API를 사용하는 플랜 리뷰 MCP 서버를 만들어 줘. 플랜 텍스트를 받아서 구현 계획에 빠진 부분이나 리스크를 지적해 줘." 그다음 API 키를 MCP 서버 환경변수에 넣고 재시작하면 끝. 데모에서 계획 → 타 모델 리뷰 → 피드백 반영된 새 계획까지 한 흐름으로 돌아갑니다. 두 개의 서로 다른 모델이 교차 검토한 계획이 나옵니다.
• 출처: 메타 엔지니어의 클로드코드 완벽 가이드 [심화편] — 실밸개발자 (34:21~36:08)
• 보정: 리뷰 품질이 실제로 나아졌는지는 검증되지 않았습니다 — 피드백이 반영된 새 계획이 나온 것까지가 영상에서 확인된 전부이고, 그게 더 나은 계획인지는 화자의 인상평("조금 더 단단하고 효과적인 플랜")입니다.

이미 수집한 팁의 재탕

• 서브에이전트는 상위 모델 말고 중·하위 모델로 돌려라 — 실밸개발자 편에서 "서브에이전트에 Opus는 권하지 않는다, Sonnet이나 Haiku로 병렬 처리해 토큰을 아껴라"로 나왔고, 내장 탐색 에이전트가 실제로 가장 싼 모델을 쓴다는 관찰도 붙습니다. 이미 수집(2026-08-13 코딩 — "서브에이전트는 Haiku, 메인 스레드는 Opus").
• git worktree로 병렬 작업을 격리하라 — 오늘 두 영상 모두에서 나왔습니다. 이미 수집(2026-08-13 코딩). 새로 얹힌 실무 주름 하나만 적어 둡니다: 워크트리를 새로 만들면 프로젝트 의존성을 다시 설치해야 할 수 있고, 매번 그렇다면 그 설치 자체를 워크트리 생성 시 호출되는 스킬/커맨드로 만들라는 것.
• MCP를 스킬이나 CLI로 갈아타 컨텍스트를 아껴라 — 이미 수집(2026-08-13 자동화 / 2026-08-14 자료조사 "MCP냐 CLI냐 — 공식 제공 여부로 갈라라"). 오늘 얹힌 각도: 8/14 것이 공식 제공 여부로 갈랐다면 오늘 영어 편은 알려진 정도로 가릅니다 — GitHub·Jira처럼 흔한 플랫폼은 이미 CLI가 있으니 bash로, MCP의 진짜 자리는 모델이 모르는 사내 내부 서비스를 붙일 때라는 것. 예외로 문서 검색용 MCP는 계속 씁니다(일반 웹 검색과 달리 문서를 모델이 먹기 좋은 형태로 잘라 주기 때문).
• 스킬 설명란에 내가 실제로 쓸 말을 넣어라 — 이미 수집(2026-08-16 글쓰기). 오늘 실밸개발자 편이 품질 기준 셋을 더 구체화합니다: 핵심 기능이 첫 문장에 나오는가 / 사용자가 실제로 말할 법한 표현이 3개 이상 있는가 / 비슷한 다른 스킬과 구별되는가. "문서를 생성하는 스킬" 같은 추상어는 판단 불가.
• 큰 출력은 별도 컨텍스트로 격리하고 대화가 커지면 압축하라 — 안티패턴 편에도 같은 내용이 나오며 압축 기준선으로 15만 토큰이라는 구체 숫자를 답니다. 이미 수집(2026-08-13 코딩 "/compact에 보존 대상을 지정할 수 있다" + 오늘 팁 14의 서브에이전트 격리)이라 새 항목을 만들지 않았습니다.

시도 후보

• 팁 17(다른 계열 모델에게 계획을 리뷰시키기) — 우리에게 필요한 부품이 전부 있습니다. 한 번 시켜 보면 교차 검증이 실제로 무언가를 잡아내는지 바로 압니다.
• 팁 1(잘린 응답 판정) — 이건 취향이 아니라 결함 여부의 문제라 확인 자체가 짧습니다. 토큰 소진으로 잘린 답이 정상 답으로 흘러가는지 한 번만 보면 됩니다.

오늘의 영상

• Anthropic 첫 공식 시험이 꼽은 에이전트 안티패턴 5가지 — AgentOS · 약 4,100회 · 19분 07초 · 오늘 최고 수확. 이틀 전 올라온 영상이고, 30년 넘게 컴퓨터 과학을 가르쳤다는 버클리 강사의 발표를 한국어 해설로 감싼 구성입니다. 미덕은 방법론에 있습니다 — 정답이 아니라 오답부터 봅니다. 1990년대 객체지향 패턴 운동 때 패턴 카탈로그와 함께 안티패턴 카탈로그가 나왔던 것처럼, 지금 필요한 건 에이전트용 안티패턴 목록이라는 것. 다섯 시나리오가 전부 "하면 안 되는 것"에서 출발하고, 그것들이 한 방향("덜 준다")으로 수렴하는 걸 마지막에 짚어 줍니다. 곁가지로 나온 1966년 정리(순차·조건·반복 셋이면 튜링 완전) 이야기도 좋았습니다 — 프롬프트 한 번 던지고 답 받는 건 순차, 조건 분기까지는 많이들 했고, 에이전트가 갑자기 달라 보이기 시작한 건 세 번째(반복)가 채워진 시점이라는 정리.
• 사내 AI 에이전트 만들면 생기는 문제들이 있습니다 — 퇴근길 AI · 약 2.9만 회 · 7분 55초 · 오늘 유일하게 반대 방향을 가리킨 영상. 출장 가는 길 정차 중에 찍었다는 형식인데도 밀도가 높습니다. 8분 안에 "왜 만들지 말아야 하는가 → 그럼 뭘 하는가 → 우리도 자동화하다 실패했다 → 개념부터 바꿔야 한다"가 순서대로 갑니다. 자기 팀의 실패를 먼저 꺼내는 구조라 컨설팅 홍보로 읽히지 않습니다. 다만 자동 자막이 회사 내부 도구 이름을 뭉개서 그 부분은 싣지 못했습니다.
• The Agentic Engineer Workflow You Need In 2026 — Zen van Riel · 약 5.5만 회 · 17분 11초 · 과장을 줄이는 방향으로 말하는 드문 영상. 5배가 아니라 30~60%라고 하고, 자기 PR이 선임에게 반려당한 이야기를 하고, 리뷰 커맨드는 하나로 맞는 게 없다며 공유를 거절합니다. 반대로 아쉬운 건 링크 유도가 세 번 반복된다는 점과, 좋은 원칙들("직관은 직접 만들어 봐야 생긴다")이 구체적 방법 없이 끝나는 대목이 몇 있다는 것.
• 메타 엔지니어의 클로드코드 완벽 가이드 [심화편] — 실밸개발자 · 약 4만 회 · 45분 04초 · 3부작의 마지막 편. 스킬 → 서브에이전트 → 훅 → 고급 팁 → 통합 데모 순서로 가고 매 섹션마다 실제로 만들어 보여 줍니다. 오늘 네 편 중 유일하게 기능의 내부 동작(무엇이 언제 컨텍스트에 로드되는가)을 설명한 영상이라 팁 14가 여기서 나왔습니다. 마지막 통합 데모는 클라이언트 피드백 10건을 음성 입력 → 타 모델 플랜 리뷰 → 서브에이전트 병렬 수정 → 훅 알림 → 코드 리뷰 → 보고서 생성으로 잇는데, "반나절 걸릴 일이 30분"이라는 주장은 본인 프로젝트 1회 실측이라 일반화하긴 어렵습니다. 8/13 코딩 호와 겹치는 대목(워크트리·서브에이전트 모델 티어)은 재탕으로 돌렸습니다.

지켜볼 점 / 내일 주제 후보

• 내일 주제 후보 1 — 평가(evals). 오늘 검색에서 가장 두껍게 잡혔는데 하나도 못 다룬 축입니다. 2시간짜리 실습 세션(Arize), 1시간 강의, LLM-as-a-Judge 설계까지 후보가 줄줄이 나왔지만 6개월 규칙에 걸리거나(1월·작년), 너무 길거나(2시간 4분), 신호가 너무 약했습니다(169회). 어제도 "도구 정의·평가·조율"을 미충족 영역으로 적었는데 오늘 그중 둘(정의·조율)은 채웠고 평가만 남았습니다. 하루를 여기에 쓸 값어치가 있어 보입니다.

• 내일 주제 후보 2 — 학습. 이레 연속 "만들기" 계열이었습니다. 어제 적은 후보가 그대로 유효합니다.

• 오늘의 관찰 1 — 컷오프가 처음으로 '가장 좋은 영상'을 잘라내지 않았다. 지난 나흘의 관찰은 "조회수 상위권이 계통적으로 잘린다"였는데, 오늘은 반대였습니다. 최다 조회(36.5만) 영상은 한 달 차이로 탈락했지만, 오늘 최고 수확은 조회수 4,100짜리 이틀 된 영상이었습니다. 에이전트 설계는 콘텐츠가 지금 이 순간 만들어지고 있는 주제라 신선한 것과 좋은 것이 같은 쪽에 있었습니다. 이미지·영상 주제에서 "히트작은 전부 작년"이었던 것과 정반대입니다 — 6개월 규칙이 주제마다 다르게 작동한다는 게 나흘 만에 양쪽 사례로 확인됐습니다.

• 오늘의 관찰 2 — 두 개의 신선도 규칙이 서로 반대 방향이다. 팁 11의 화자는 "3~4개월 살아남지 못한 패턴은 안 쓴다"고 하고, 이 보고서는 "6개월 넘은 건 낡았다"고 자릅니다. 겹치면 3~6개월 창이 남습니다. 우리 규칙이 잡아내는 건 정보의 부패고 그의 규칙이 잡아내는 건 검증의 부재라 서로 다른 것을 재고 있지만, 둘을 같이 적용하면 후보가 꽤 좁아집니다 — 오늘은 후보가 충분해서 문제가 안 됐습니다.
• 오늘의 관찰 3 — 자막 언어가 처음으로 선정 자체를 막았다. 조회수 12만짜리 27분 시스템 설계 영상(오늘 후보 최다 조회)이 자동 자막 트랙을 힌디어 하나만 갖고 있어 제외했습니다. 사흘 연속 자막 문제를 적어 왔는데, 지금까지는 품질(외래어·전문어가 뭉개짐)이었고 오늘은 존재 여부였습니다. 이 방식의 경계가 하나 더 드러난 셈입니다 — 우리는 "말로 설명된 것"만 읽는 게 아니라 "우리가 읽을 수 있는 언어로 자동 자막이 붙은 것"만 읽습니다. 오늘 네 편의 도구·기능 이름은 여전히 전부 문맥으로 복원한 것이고("엔트로픽"=Anthropic, "스톱 리즌"=stop_reason, "섭에이전트"=서브에이전트), 화면에만 나오고 말로 설명되지 않은 부분(각 코드 예제의 실제 전문)은 싣지 않았습니다.