출처 https://youtu.be/Bo2ImHzgOwc?si=9bAO1DlUbRzoZJdx · 채널 Tech Bridge · 길이 22:23 포맷 Anthropic의 Claude Code 개발자 Thariq Shihipar, Sid Bidasaria, Robert Boyce 3인이 지난 1년의 사용 경험과 제품 개발 방식을 이야기하는 대담. 슬라이드·데모보다 발화와 대담 장면이 중심인 B형 영상이다. 원문 자막
raw/transcripts/2026-09-03-claude-code-team-workflow.en.srt표기 주의 자동 영어 자막은 고유명사를
Cloud Code/Cloud Tag처럼 인식한다. 이 노트에서는 문맥상 각각 Claude Code와 Claude Tag로 정정했다.Claude Tag는 대담에서 설명하는 Slack 기반의 Claude 에이전트를 가리키는 이름이다. 장면 캡처의 한국어 자막은 Tech Bridge가 입힌 번역 자막이다.
한눈에 보는 요약
- Claude Code 팀의 사용 방식은 개별 프롬프트와 툴 호출을 감독하는 단계에서 목표를 위임하고 결과를 받는 단계로 이동했다. Thariq는 업무의 70~80%를 Slack 기반 Claude Tag로 처리한다고 말한다.
- 모델이 약할 때 추가한 하니스 기능은 영구적인 자산이 아니다. 모델이 좋아지면 과감히 삭제하고, 과제가 커지면 새로운 프리미티브를 다시 붙이는 지속적인 pruning이 필요하다.
- 로컬 세션을 원격 컨테이너와 루프로 옮기면 에이전트가 세션 밖에서 계속 실행된다. 매일 피드백을 분류하고 확신이 높은 버그를 고치는 루틴도 이 구조에서 가능해진다.
- 동적 워크플로우는 대규모 fan-out, 다각도 adversarial review, 결과 필터링을 결합한다. 많은 출력을 사람이 읽게 만들기 위해 map-reduce와 test-time compute가 필요하다.
- Claude Tag는 Claude Tag 자신을 개발하고 검증한다. 개발 환경·이벤트 로깅·엔드투엔드 테스트를 에이전트가 직접 다룰 수 있게 만드는 것이 핵심이다.
- 엔지니어의 역할은 세부 구현을 모두 직접 통제하는 데서 무엇이 가능한지 크게 보고, 좋은 피드백 루프와 검증 구조를 만드는 일로 이동한다.
장면별 상세 설명
[00:27] 1. 1년 사이에 바뀐 작업 단위
대담은 “내년에는 어떻게 될까?”라는 질문으로 시작하지만, 패널들은 앞으로 1년을 예측하기조차 어렵고 다음 두 달을 생각하는 일도 쉽지 않다고 답한다. 불과 1년 전에는 프롬프트를 입력하고, 모델의 답에 피드백을 주고, 권한 요청을 하나씩 승인하는 방식이었다.
이제 개발자에게 주어지는 작업은 클래스나 함수 구현보다 훨씬 복잡하다. 중요한 변화는 모델이 더 많은 코드를 작성했다는 사실만이 아니라, 개발자가 맡기는 작업의 단위가 함수에서 목표로 커졌다는 점이다.
[01:00] 2. Slack-native 에이전트와 제품 맥락
Claude Tag는 Slack 안에서 동작하며 팀의 제품 맥락과 과거 의사결정을 찾아볼 수 있다. 에이전트가 코드만 읽는 것이 아니라 “이 제품이 어떤 방향이어야 하는가”에 대한 팀의 결정을 함께 참고하면, 목표를 달성하는 과정에서 더 나은 선택을 할 수 있다는 설명이다.
한 패널은 업무의 70~80%를 Claude Tag로 처리하고, 나머지는 데스크톱 앱을 열어 결과를 세밀하게 다듬거나 직접 조종하고 싶을 때 사용한다고 말한다. 사람의 역할은 모든 중간 단계를 감시하는 것에서, 필요한 순간에 방향을 조정하는 것으로 줄어든다.
[02:17] 3. 툴 호출이 아니라 목표를 위임하기
이 팀이 체감하는 가장 큰 변화는 모델의 개별 판단과 툴 호출을 일일이 따라가던 관점에서 벗어나 “이 목표를 달성해 달라”고 말하는 관점으로 이동한 것이다. Claude Tag는 검증, 코드 리뷰, 브레인스토밍, 모니터링까지 하나의 목표 흐름 안에서 처리한다.
이 기능들은 처음부터 하나의 거대한 자동화로 설계된 것이 아니라, 권한·시각화·메모리·워크플로우 같은 프리미티브를 쌓은 뒤 서로 결합한 결과다. 따라서 에이전트 제품의 핵심은 기능 목록보다 재사용 가능한 프리미티브 사이의 조합 가능성에 있다.
[03:00] 4. 두 달마다 바뀌는 기반 모델에 제품 맞추기
전통적인 소프트웨어에서는 기반 기술의 수명이 몇 년이라고 가정할 수 있었지만, AI 모델은 약 두 달마다 제품 아래에서 근본적으로 변한다. 팀은 최전선의 모델을 따라가면서도 현재 모델을 사용하는 사람에게 즉시 가치를 제공해야 한다. 이는 “미래를 위해 만든다”와 “오늘 쓸 수 있게 만든다” 사이의 균형 문제다.
초기 Sonnet 3.5 시기에는 모델이 긴 작업을 끝까지 수행하지 못해 여러 단계의 할 일을 적은 to-do list가 유용했다. 그러나 모델이 더 긴 문맥과 메모리 상태를 다루게 되면서 이 보조 장치는 빠르게 사라졌다. 특정 하니스 기법의 유효기간이 짧다는 것을 보여주는 사례다.
[04:50] 5. 모델이 좋아지면 하니스를 지운다
하니스에 들어간 기능 중 상당수는 당시 모델의 실패 모드를 보완하기 위해 추가된다. 모델이 좋아지면 팀은 “이 기능이 아직 필요한가?”를 다시 묻고, 더 이상 필요하지 않으면 삭제한다. 반대로 작업의 범위가 커지면 모델이 일관성을 유지하도록 새로운 툴과 구조를 추가한다.
Claude Code 팀은 모델 개선에 맞춘 큰 변경, 권한 시스템 재작성, 아티팩트 추가 등을 작은 팀으로 동시에 진행한다. 패널은 이를 소프트웨어 개발의 변화가 극단적으로 압축된 “hyperbolic time chamber”에 비유한다. 빠른 변화에 적응하는 능력 자체가 제품 개발 역량이 된다.
[06:00] 6. AskUserQuestion에서 아티팩트로
AskUserQuestion 도구는 처음에는 모델이 적절한 때에 호출하도록 만들기 어려웠다. 하지만 모델이 해당 상호작용을 잘 수행하게 되자, 팀은 질문 전용 툴을 계속 개선하는 대신 HTML 아티팩트 안에 질문·다이어그램·목업을 함께 만들도록 방향을 옮겼다.
이 사례는 모델의 능력이 변하면 사용자 인터페이스와 하니스의 경계도 변한다는 것을 보여준다. 팀은 권한, 시각화 같은 프리미티브를 분리해 만들고, 모델이 좋아질 때 이 프리미티브를 새로운 방식으로 조합한다.
[06:45] 7. 로컬 실행에서 원격 루프로
루프의 출발점은 단순하다. 노트북에서 에이전트를 실행하면 노트북을 닫는 순간 작업도 멈춘다. 팀은 먼저 원격 개발 박스로 옮겼고, 이후 SSH를 거치지 않아도 되는 클라우드 호스팅 컨테이너와 Claude Code 웹 환경으로 발전시켰다.
실행면이 클라우드에 상주하면 에이전트는 사용자의 현재 세션과 분리되어 계속 작업할 수 있다. 이때부터 반복 실행, 예약된 루틴, 장시간 작업이 제품의 기본 기능이 된다.
[08:50] 8. 세션 밖에서 일하는 루틴
클라우드에서 실행되는 루틴은 매일 팀의 피드백을 모아 중요도별로 분류하고, 확신이 높은 버그를 자동으로 수정할 수 있다. 이는 단순히 한 세션 안에서 모델에게 다음 프롬프트를 입력하는 방식이 아니다.
작업의 경계가 “현재 세션”에서 “지속적으로 목표를 추적하는 에이전트”로 한 단계 올라간다. 사람은 루프가 낸 결과와 예외를 검토하고, 에이전트는 정해진 조건 안에서 반복적인 후속 작업을 맡는다.
[09:30] 9. 코드 리뷰에서 사람은 어디에 집중하는가
생성 코드가 늘어날수록 사람이 모든 줄을 읽어야 한다는 발상은 병목이 된다. 팀에서는 코드 리뷰 봇이 사소한 스타일 문제나 작은 니트픽을 찾도록 하고, 사람은 API 구조·서비스 경계·제품 맥락처럼 모델이 아직 완전히 내면화하지 못한 이유를 검토한다.
좋은 자동화는 인간 리뷰어를 없애는 것이 아니라, 사람이 더 높은 추상화 수준의 결정을 보게 만든다. “읽었다는 신호를 보내기 위한 세 가지 지적” 대신 정말 위험하거나 중요한 설계 문제에 사람의 시간을 쓰는 방식이다.
[11:30] 10. 코드 리뷰에서 시작된 동적 워크플로우
팀은 코드에서 가능한 모든 버그를 찾기 위해 먼저 대규모 fan-out을 사용했다. 여러 에이전트가 각각 문제를 찾고, 발견된 버그마다 다시 세 가지 다른 관점에서 adversarial review를 수행해 실제 버그인지 확인한다.
이 방식은 코드 리뷰에만 한정되지 않는다. 성능 문제, 보안 점검, 일반적인 딥리서치처럼 후보를 많이 찾은 뒤 검증·선별해야 하는 모든 문제에 적용할 수 있다. 워크플로우는 단순한 프롬프트 모음이 아니라, 여러 에이전트의 결과를 다음 단계에 연결하는 실행 구조다.
[13:20] 11. Fan-out의 출력은 map-reduce로 줄인다
예를 들어 여행지를 조사할 때 여러 검색 에이전트를 병렬로 실행하면 정보는 빠르게 쌓이지만, 사람이 모든 결과를 읽으면 오히려 판단할 수 없게 된다. 따라서 fan-out 뒤에는 결과를 정렬·검증·요약하는 filter-back 단계가 필요하다. 패널은 이를 map-reduce 문제로 설명한다.
여기에 test-time compute를 투입하면 모델이 한 번 답하고 끝나는 대신, 여러 후보와 관점을 비교하며 더 높은 확신을 만들 수 있다. 특히 워크플로우의 일부를 에이전트가 실제 코드로 작성하면 for 루프 같은 결정론적 구조와 에이전트의 유연한 판단이 함께 작동한다.
[14:15] 12. Claude Tag가 Claude Tag를 개발한다
Robert Boyce는 Claude Tag를 이용해 Claude Tag 자체를 적극적으로 개발하고 있다고 말한다. 핵심은 에이전트가 소스 코드를 편집하는 것만이 아니다. 개발 환경을 준비하고, 필요한 도구를 호출하고, 소프트웨어를 끝까지 실행해 작동 여부를 확인하는 개발 루프 전체를 에이전트가 사용할 수 있어야 한다.
통합된 시스템이 복잡해질수록 이 조건은 어려워진다. 그래서 제품팀은 에이전트가 스스로 개발하고 검증하는 데 막히지 않도록 환경과 피드백 경로를 먼저 정리한다.
[16:45] 13. Slack에서 아이디어를 제품으로 옮기기
새 도구를 만들 때 한 패널은 Slack에서 이해관계자를 찾고, 목업을 만들고, 구현한 뒤, 이벤트를 심어 내부에 배포한다. Claude Tag가 사용 패턴과 피드백을 관찰하므로 개발자는 “내 아이디어를 구현해 달라”고만 말하는 대신 “이 퍼널을 어떻게 개선할 수 있을까?”라고 더 높은 수준의 목표를 줄 수 있다.
이 흐름에서 중요한 것은 자동 생성 자체보다 계측이다. 이벤트와 사용 데이터를 연결해야 에이전트가 실제 사용 결과를 보고 다음 개선안을 제안할 수 있다.
[18:45] 14. 검증·코드 리뷰·피드백은 하나의 루프다
패널은 Claude Code의 진화를 auto mode, memory, workflows 같은 프리미티브가 차례로 쌓인 과정으로 회고한다. 그중 검증은 특히 중요하다. Claude가 PR을 만들 때 테스트를 실행하고 결과 화면의 스크린샷을 보내면, 사용자는 코드뿐 아니라 실제 동작에 대한 신뢰도 함께 얻는다.
검증은 별도의 마지막 단계가 아니다. 코드 리뷰와 사용자 피드백까지 데이터 저장소·이벤트 저장소에 연결되는 하나의 운영 루프다. 테스트, 화면 확인, 실제 사용 지표가 서로 보강될 때 자동화의 범위를 넓힐 수 있다.
[20:15] 15. 세부 구현에서 한 단계 물러서기
대담 후반부에서 패널들은 예전처럼 성능 튜닝이나 픽셀 단위 UI를 직접 파고드는 즐거움이 줄었다고 말한다. Claude가 그런 세부 작업을 더 잘 수행하는 경우가 많아졌기 때문이다. 대신 엔지니어는 어떤 문제를 풀지, 어떤 결과를 검증할지, 어느 수준에서 방향을 바꿀지에 더 많은 시간을 쓴다.
이것은 세부 능력이 쓸모없어진다는 뜻이 아니다. 사람이 세부를 이해해야 결과를 판단할 수 있지만, 모든 세부를 직접 생산하는 것이 최선은 아니라는 뜻이다. 에이전트가 세부를 맡을수록 사람은 더 넓은 맥락과 품질 기준을 설계해야 한다.
[21:45] 16. 소프트웨어는 여전히 문제 해결이다
마지막 결론은 낙관적이지만 단순한 “코딩의 종말”은 아니다. Claude를 사용하면 기술적 장벽 때문에 시작하지 못했던 아이디어도 목표를 설명하고 함께 쪼개며 구현할 수 있다. 어린 시절 PowerPoint로 게임을 만들려 했던 경험처럼, 도구가 사람에게 새로운 창작 가능성을 열어준다는 비유가 나온다.
소프트웨어 엔지니어링은 본질적으로 변화의 직업이다. 프레임워크와 컴파일러가 생기며 문제의 형태가 바뀌었듯, 에이전트 시대에도 핵심은 달라진 도구로 더 좋은 소프트웨어를 만드는 문제 해결 능력이다.
부록 — 실전 체크리스트
- 툴 호출 목록을 먼저 설계하기보다 달성할 목표와 완료 조건을 먼저 적는다.
- 모델이 이미 잘하는 일을 보완하는 프롬프트·훅·스킬이 쌓여 있지 않은지 주기적으로 지운 뒤 다시 검증한다.
- 장시간 작업은 로컬 세션에 가두지 말고 원격 컨테이너, 중단·재개 조건, 정지 조건을 함께 설계한다.
- 반복 작업에는 루틴을 붙이되, 확신이 낮은 결과는 자동 수정하지 않고 사람에게 에스컬레이션한다.
- 대규모 탐색은
fan-out → 다각도 검증 → filter-back/요약구조로 만들어 사람이 읽을 수 있는 결과만 남긴다. - 코드 리뷰 자동화는 니트픽 제거에 쓰고, 사람은 API·서비스 경계·제품 의도 같은 고차원 설계에 집중한다.
- 에이전트가 구현한 결과에는 테스트, 화면 캡처, 이벤트 로그, 실제 사용 피드백 중 가능한 검증 경로를 붙인다.
- 모델이 만든 하니스도 고정된 자산으로 보지 말고, 새 모델과 새 작업 범위에 맞춰 계속 재평가한다.
관련 노트
- 2026-07-28-boris-cherny-cut-80-percent-prompt — 모델이 좋아질수록 시스템 프롬프트와 하니스를 ablation으로 줄이는 Claude Code 팀의 방법론.
- 2026-07-08-claude-code-getting-started-with-loops — Claude Code 루프의 트리거·정지 조건·프리미티브 설계.
- 2026-04-15-claude-code-routines — 클라우드에서 반복 작업을 실행하는 Claude Code Routines.
- 2026-04-04-how-claude-code-works — 에이전트 루프·도구·컨텍스트를 중심으로 정리한 Claude Code 작동 원리.
- moc-ai-agents-harness — 에이전트 하니스 설계와 실행 루프 관련 노트 모음.
- moc-claude-code — Claude Code 관련 노트 MOC.
원문 인용 모음
- [00:35] “I think 70 to 80% of my work happens on Claude Tag now.”
- [01:17] “We’ve gone from just caring about the transcript so much and caring about each individual tool call … to just a zoomed-out view of, I have a goal and I’d like to achieve this goal.”
- [02:47] “With models in the AI models, it’s like the technology fundamentally shifts underneath you every two months.”
- [03:52] “Maybe you give it a to-do list and it’ll do really well.”
- [04:22] “As the models get better, we have the freedom now to say, actually all these features that we built, it’s not relevant anymore. We don’t need those. We can get rid of them.”
- [06:21] “I use create an artifact and the artifact asks me questions … and has diagrams and mock-ups and things like that.”
- [08:20] “Every day go and look at all the feedback that we’re getting … and fix the ones that it actually has high confidence in fixing.”
- [09:58] “Claude really helps human reviewers choose where to focus their time and energy.”
- [11:56] “For each bug, you might do an adversarial review where you ask it to look at the bug from three different opinions or perspectives.”
- [13:28] “It’s like a map-reduce problem. And so you need to filter back for human consumption.”
- [14:17] “We’re using Claude Tag to build Claude Tag really aggressively.”
- [15:46] “I’m not thinking about the details of which tools is it calling, what parameters is it sending to the tools.”
- [17:52] “Effectively there’s verification, there’s code review, and there’s getting feedback.”
- [21:52] “I feel like software engineering is the profession of change.”