“가장 좋은 모델을 쓰면 된다”는 말은 절반만 맞다. 이 대담의 주장은 정반대 방향을 가리킨다. 에이전트의 실력은 모델 자체가 아니라, 그 모델을 감싸는 소프트웨어 설계와 하니스(harness) 에서 나온다는 것이다. Matt Pocock은 모델을 먼저 고르는 사고방식보다, 모델이 일하는 환경을 설계하는 사고방식을 더 중요하게 놓는다.
영상이 한 말은 타임스탬프 클립과 짧은 자막 근거로, 그에 대한 해석은 그 아래에, 그리고 내 생각은 맨 끝에 따로 표시했습니다. 어디까지가 영상이고 어디부터가 제 판단인지 구분해 읽으실 수 있습니다. 원문 자막은 yt-dlp로 확보했고, 공개 글에는 공정 이용 범위의 짧은 조각만 남겼습니다.
한눈에 보기
- 영상: Matt Pocock’s Agentic Engineering Workflow (just copy him) — David Ondrej 채널 · 1:02:24 · 2026-06-19
- 형식: David Ondrej × Matt Pocock 팟캐스트 대담 (스폰서 SerpApi, 자동 더빙)
- 이 글이 답하는 질문: 에이전트 시대에 개발자의 실력은 어디에 쌓이는가 — 모델인가, 하니스인가?
- 세 줄 요약: ① 빠른 기능 구현(전술적)보다 복잡도를 관리하는 설계(전략적)가 에이전트 성능을 좌우한다. ② 스킬·하니스 같은 ‘모델 바깥의 구조’가 핵심 자산이다. ③ 일하는 방식은 사람이 끼는 ‘루프’에서 맡겨 두는 ‘큐’로 옮겨가고, 개발자는 코딩보다 제품·시스템 판단으로 이동한다.
핵심 클립과 해석
1. [0:00] 전술적 vs 전략적 프로그래밍 (Tactical vs Strategic Programming)
이 구간(요약). 대담은 John Ousterhout의 구분, 즉 당장 기능을 쳐내는 전술적 프로그래밍과 복잡도를 다스리도록 설계에 투자하는 전략적 프로그래밍에서 출발한다. 핵심 주장은 에이전트가 코드를 빠르게 뱉을수록 전략적 설계의 가치가 오히려 커진다는 것.
“the harness” · “the wrong thing”
해석. 에이전트 시대에도 병목은 타이핑 속도가 아니라 복잡도다. 모델이 1분에 500줄을 짜도, 경계가 없는 코드베이스에서는 그 500줄이 다음 변경을 더 비싸게 만든다. 이 블로그가 반복해 온 주장 — 좋은 시스템은 검색이 아니라 구조에서 나온다 — 과 정확히 같은 자리다.
John Ousterhout, A Philosophy of Software Design: “Complexity isn’t caused by a single catastrophic error” — 복잡도는 한 방이 아니라 작은 의존성과 모호함이 쌓여 생긴다. 에이전트는 바로 그 작은 것들을 증폭한다.
2. [5:58] “Teach” 스킬 시연 (The “Teach” Skill Demonstration)
이 구간(요약). Matt이 실제 스킬(skill) 하나(“teach”)를 시연한다. 모델에게 매번 길게 설명하는 대신, 반복 가능한 절차를 파일로 패키징해 호출하는 방식이다. (스킬 모음: github.com/mattpocock/skills)
“teaching principles” · “into a skill”
해석. 스킬은 에이전트의 절차 기억을 코드처럼 버전 관리하는 장치다. 이건 남 얘기가 아니다 — 이 블로그도 이미 codex-skills/로 Agent Skills를 운영하고 있고, 지금 이 글도 video 스킬로 만들어졌다. 좋은 스킬은 “한 번 잘 쓴 프롬프트”가 아니라 다음 작업의 문맥이 되는 자산이다.
3. [16:40] 좋은 에이전트 스킬 설계: 절차 vs 능력 (Procedures vs Abilities)
이 구간(요약). 스킬을 둘로 나눈다. 정해진 단계를 따르는 절차(procedure) 와, 모델의 판단에 맡기는 능력(ability). 무엇을 고정하고 무엇을 열어둘지가 좋은 스킬 설계의 핵심이라는 이야기.
“procedures” · “abilities”
해석. 이건 결국 인터페이스 설계다. 무엇을 결정론적으로 박고 무엇을 모델 재량에 넘길지를 정하는 것은, 좋은 API에서 무엇을 계약으로 고정하고 무엇을 구현에 위임할지를 정하는 일과 같다.
The Pragmatic Programmer / A Philosophy of Software Design의 원칙 — 인터페이스는 작게, 정보는 숨겨라 — 이 그대로 에이전트 스킬에 적용된다. 너무 많은 자유를 주면 그럴듯하지만 틀린 행동을 하고, 너무 좁히면 쓸모가 준다.
4. [24:45] 에이전틱 셋업과 하니스의 중요성 (The Importance of the Harness)
이 구간(요약). 영상의 중심 주장. 성능을 모델에서 먼저 생각하지 말고 하니스 — 도구, 컨텍스트 공급, 검증, 권한 같은 모델 바깥의 구조 — 에서 생각하라. 여기서 위의 “Thinking from the model first is the wrong way to do it.”가 나온다.
“model first” · “wrong way”
해석. 하니스에 투자한다는 건 자기 성공을 자기 손에 둔다는 뜻이다. 모든 걸 최신 모델 성능에 의존하면, 그 모델이 사라지거나(댓글에서 반복된 ‘Fable’ 사례) 비싸지는 순간 실력이 통째로 인질이 된다. 반대로 하니스는 내가 통제하고 더 싼 모델에도 이식할 수 있다. 이 블로그식으로 말하면, 하니스의 절반은 출처성과 경계 다 — 에이전트가 무엇을, 어떤 권한으로, 어떤 근거로 만지는지를 설계하는 일.
5. [34:55] AI의 능력과 자율 실행 (AI Capabilities and Autonomous Task Execution)
이 구간(요약). 에이전트가 복잡한 작업을 어디까지 혼자 끌고 갈 수 있는지, 어떤 작업을 위임할 만한지에 대한 논의.
“tools” · “scoped task”
해석. 자율 실행의 상한선은 모델 IQ가 아니라 문맥 공급의 품질이 정한다. 무엇을 넣고 빼고 요약하고 검색해 줄지를 설계하는 것 — 이 블로그가 말해 온 Prompt Engineering에서 Context Engineering으로의 문제다. 틀린 문맥 위에서의 자율성은 빠른 오답일 뿐이다.
6. [42:58] 휴먼 인 더 루프 vs AFK: 루프 vs 큐 (Loops vs Queues)
이 구간(요약). 일하는 방식을 두 모드로 본다. 사람이 매 단계 끼어드는 루프(loop) 와, 일감을 쌓아 두고 자리를 비운 채(AFK) 처리되게 하는 큐(queue). 시청자들은 이를 “이미 루프는 끝났다 / 이제는 중첩 루프의 시대”라고 요약했다.
“human in the loop” · “AFK work”
해석. 핵심은 “사람을 뺀다”가 아니라 사람이 끼는 지점을 옮긴다는 것이다. 실시간 감독에서 → 일감 정의·수용 기준·검수로. human-in-the-loop는 사라지는 게 아니라 더 높은 추상층으로 올라간다. 큐가 돌아가려면 각 작업이 검증 가능해야 하고, 그건 다시 하니스와 출처성의 문제로 돌아온다.
7. [54:08] 제품 설계의 기본과 개발자의 미래 (Product Design & the Future of Developers)
이 구간(요약). 구현이 싸지면, 무엇을·왜 만들지 정하는 제품 설계가 더 중요해진다. 개발자의 일은 코딩에서 판단·설계 쪽으로 이동한다는 마무리.
“talk to customers”
해석. “개발자의 미래는 코딩보다 시스템·제품 설계에 가깝다.” 에이전트가 구현을 돕는 만큼, 사람은 경계와 판단을 설계하는 쪽으로 올라간다. 비관이 아니라 레버리지의 이동이다 — 가장 작은 결정(무엇을 만들지)이 가장 큰 결과를 낳는다.
내 생각 — 하니스가 곧 지식 아키텍처다
“모델에서 먼저 생각하지 말라”는 Matt의 말을 이 블로그의 언어로 옮기면 이렇게 된다. 하니스의 절반은 지식 아키텍처다. 하니스를 도구·문맥 공급·검증·권한의 묶음이라 할 때, 성패를 가르는 건 결국 에이전트가 무엇을, 어떤 경계 안에서, 어떤 출처를 달고 찾아오게 하느냐이기 때문이다. 모델은 그 위에서 추론할 뿐이다.
그래서 나는 하니스 이야기를 LLM Wiki의 핵심은 벡터 DB가 아니라 지식 아키텍처다의 연장으로 읽는다. 좋은 하니스의 한가운데에는 출처를 단 지식이 있다. 모든 청크에 위치·시점·소유자·신뢰도가 붙고, 도메인마다 경계(bounded context)가 서 있고, 작업 중 발견한 불일치가 다시 기록되는 갱신 루프가 돈다. 이게 없으면 컨텍스트 윈도우를 아무리 키워도 잡음만 커진다.
“search engines become Band-Aids for poorly designed navigation systems.”
RAG·임베딩 검색도 똑같다. 지식의 경계와 이름이 엉켜 있으면, 더 큰 모델은 그 혼란을 더 자신 있게 증폭한다. 그래서 검색보다 먼저 필요한 건 정보 아키텍처고, 그게 하니스의 진짜 알맹이다.
이 관점이 중요한 실천적 이유는 소유권이다. 성공을 최신 모델 성능에 걸면, 그 모델이 사라지거나(영상 댓글에서 반복된 ‘Fable’) 비싸지는 순간 실력이 통째로 인질이 된다. 반대로 하니스 — 스킬(절차 기억) + LLM Wiki(지식) + 검증·권한 — 는 내가 통제하고 더 싸고 작은 모델에도 이식할 수 있다. “더 좋은 모델을 쓰라”는 조언이 실은 모델 공급자가 파는 프레임이라는 시청자의 지적에, 나는 절반쯤 동의한다.
다만 제목의 “그냥 따라 하라(just copy him)”는 출발점일 뿐이다. 하니스는 코드베이스와 도메인 경계마다 다르므로, 진짜 일은 복사가 아니라 내 경계에 맞춘 재설계다. 그리고 큐(AFK) 비중이 커질수록 병목은 작성에서 검수로 옮겨간다. 그러면 사람의 핵심 역량은 코드가 아니라 수용 기준(acceptance criteria)을 설계하는 일이 된다 — 결국 또 한 번, 모델이 아니라 하니스의 문제다.
핵심 정리
- 에이전트의 실력은 모델이 아니라 하니스와 설계에 쌓인다. 모델 우선 사고는 함정이다.
- 스킬 = 절차 기억의 코드화. 무엇을 절차로 고정하고 무엇을 능력으로 열지가 설계의 핵심.
- 일하는 방식은 루프 → 큐로 이동하지만 human-in-the-loop는 더 높은 층으로 올라갈 뿐이다.
- 구현이 싸질수록 제품·시스템 판단이 개발자의 본업이 된다.
한 문장: 좋은 모델을 고르는 사람보다, 좋은 하니스를 설계하는 사람이 오래 간다.
출처
- 영상: Matt Pocock’s Agentic Engineering Workflow (just copy him) — David Ondrej 채널 (David Ondrej × Matt Pocock), 2026-06-19, 1:02:24
- 구간 타임스탬프: 영상 설명/커뮤니티 챕터 기준(7개 구간). 짧은 자막 근거는
yt-dlp로 수집한en-orig자막을 기준으로 함. - Matt Pocock 스킬 모음: github.com/mattpocock/skills
- 책 인용 후보(연결용): John Ousterhout, A Philosophy of Software Design — 복잡도/전략적 프로그래밍.
댓글
GitHub 계정으로 의견을 남길 수 있습니다. 댓글은 GitHub Discussions에 저장됩니다.