uniflow
KO / EN
Productivity·판단·2026-09-21

내가 대화하는 AI가 모든 일을 다 할 필요는 없다 — 모델 역할 분담과 Claude Code Projects

대화 상대가 실행까지 다 하면 팀장이 코딩까지 하는 회사입니다. 전략은 Fable, 판단은 Opus, 반복은 Sonnet — 디자인시스템 개편을 1인 분할 작업으로 돌린 실제 구조와, 그걸 제품으로 만든 Claude Code Projects를 정리합니다.

"AI 한 대와 대화한다"는 말에는 함정이 하나 있습니다. 대화 상대가 실행까지 다 하는 구조라면, 팀장이 코딩과 테스트와 회의록까지 혼자 하는 회사와 같습니다. 잘 돌아갈 리 없고, 실제로 잘 돌아가지 않습니다.

이 글은 세 부분입니다. 제가 지금 실제로 돌리고 있는 역할 분담 구조, 그 구조를 Anthropic이 제품으로 만든 Claude Code Projects(9월 17일 베타), 그리고 그래도 사람이 남아야 하는 자리. Projects는 아직 베타 접근 전이라 발표문과 문서 기준으로 정리했고, 직접 써 보면 갱신하겠습니다.

한 모델이 다 하면 생기는 일

한 대화창에서 전략도 짜고 스크립트도 돌리고 결과도 검토하면 세 가지가 따라옵니다.

  • 대화 컨텍스트가 실행 로그로 비대해집니다. 전략을 논의하던 맥락이 파일 목록과 에러 메시지에 밀려납니다.
  • 가장 비싼 모델이 가장 단순한 반복을 합니다. 결과는 같고 청구서만 다릅니다.
  • 병렬이 안 됩니다. 하나가 끝나야 다음을 시키니, 기다리는 쪽은 사람입니다.

가장 똑똑한 사람에게 복사·붙여넣기를 시키면 결과는 똑같이 나오고 비용만 올라갑니다. 모델도 마찬가지입니다.

역할 분담 — 누가 무엇을 하나

제가 쓰는 구조는 이렇습니다. 사람과 대화하는 모델은 하나이고, 그 모델이 일을 쪼개 다른 모델들에게 넘깁니다.

역할필요한 것맡는 모델비유
전략 · 대화 · 보고맥락 전체, 사람의 의도Fable비서실장
판단 · 설계 · 리뷰깊은 추론Opus시니어
반복 · 루프 · 정형 작업빠르고 일관되게Sonnet실무 담당
분류 · 정리 · 요약싸고 많이Haiku인턴

원칙은 한 줄입니다. 모델 등급은 사람의 등급이 아니라 일의 종류에 맞추는 것입니다. 반복 루프에 Opus를 넣으면 더 잘 되는 게 아니라 더 비싸게 됩니다. 반대로 Sonnet이 못 미더워 Opus로 바꿨다면, 그건 모델 문제가 아니라 지시문 문제일 때가 훨씬 많습니다.

이 분담은 대화 중에 매번 정하는 게 아니라 지침 파일에 미리 적어 둡니다. 지침이 곧 조직도입니다.

반복·정형 작업은 서브에이전트로 넘긴다. 반복 루프는 Sonnet, 설계·판단은 Opus. 서브에이전트 결과는 네가 먼저 검토하고, 전략과 어긋난 것만 걸러서 보고한다. 보고에는 항상 제안 하나를 붙인다. 로그를 그대로 보여주지 않는다.

실제로 한 바퀴 — ERP 디자인시스템 개편

지금 회사에서 ERP 전사 디자인시스템을 개편하고 있습니다. 예전 같으면 프로젝트 팀을 꾸리고, 운영과 협의해 오픈일을 잡고, 디데이에 한꺼번에 열면서 모두가 정신없이 확인하던 일입니다. 이번에는 혼자, 분할 작업으로 진행하고 있습니다. 흐름은 다섯 단계입니다.

1단계 — 사람과 Fable이 패턴을 잡는다

전략 대화는 한 모델과만 합니다. 어떤 화면을 어떤 순서로 바꿀지, 바꾸면 안 되는 것은 무엇인지, 결과를 어떤 형식으로 보고받을지. 여기서 나온 것이 "패턴"이고, 이 패턴이 아래 모든 단계의 기준이 됩니다.

2단계 — 샘플 10개를 Sonnet이 돌린다

패턴을 곧바로 전체에 적용하지 않습니다. 화면 10개쯤을 골라 Sonnet이 스크립트로 적용합니다. 반복 작업이니 Sonnet이면 충분하고, 제가 옆에 붙어 있을 필요도 없습니다.

Advertisement본문 중간 · 반응형본 도메인에서만 게재

3단계 — 검토하고 전략을 고친다

샘플 결과를 보고 패턴을 손봅니다. 이 단계의 판단은 Opus에게 1차로 맡기고, 그 판단을 다시 다른 기준으로 교차 확인합니다. 한 모델이 "괜찮다"고 한 것을 그대로 믿지 않는 것이 요점입니다. 여기서 전략이 바뀌면 1단계로 돌아갑니다. 샘플이 10개인 이유가 이겁니다 — 되돌리는 비용이 쌉니다.

4단계 — 섹션 단위로 확산한다

고친 패턴을 섹션별로 넓혀 갑니다. 디데이가 없습니다. 한 섹션을 적용하고 검증한 뒤 다음 섹션으로 가니, 운영 쪽이 한날한시에 긴장할 일이 없습니다.

5단계 — 검증 대조에 에이전트를 붙인다

적용 전과 후를 대조하는 일이 예전에는 사람이 화면을 하나씩 열어 보던 일이었습니다. 지금은 프리뷰 조사, 패턴 적용, 1차 판단, 교차 판단에 각각 적용 모델과 판단 기준을 정해 두고 에이전트가 돌립니다. 사람에게 오는 것은 로그가 아니라 "이 섹션에서 기준을 벗어난 건 세 개, 제안은 이것"이라는 보고입니다.

결과를 한 줄로 말하면, 예전에 팀으로 동원되던 일이 1인 분할 작업이 됐고, 사람이 붙어서 정신없이 확인하는 시간이 크게 줄었습니다. 병렬로 도는 동안 제가 병렬로 붙어 있을 필요가 없다는 것, 그게 이 구조의 핵심입니다.

Claude Code Projects — 이 구조를 제품으로 만든 것

9월 17일 Anthropic이 내놓은 Claude Code Projects는, 위에서 손으로 조립하던 구조에 이름을 붙인 것에 가깝습니다. 대화 하나가 코디네이터가 되어 일을 스레드로 쪼개고, 각 스레드는 자기 브랜치를 가진 클라우드 세션으로 돕니다. Anthropic의 표현은 *"threads do the work, Claude directs it"*입니다.

손으로 하던 것Projects의 부품
사람과 Fable의 전략 대화코디네이터 대화 — 항상 켜져 있다
서브에이전트스레드 — 각자 클라우드 세션 + 자기 브랜치
지침 파일 + 결정 기록공유 메모리 — 결정·일정·기능 상태
Fable의 보고Overview 패널 — "주의 필요" 항목만

새로운 것은 세 가지입니다. 항상 켜져 있어 폰에서도 조종할 수 있다는 것(Dispatch 글에서 하던 일이 기본이 됩니다), 스레드마다 모델과 effort를 조절할 수 있다는 것(위 역할 분담 표를 화면에서 하는 셈), 그리고 스레드가 동시에 돌수록 사용 한도가 빨리 닳는다고 Anthropic이 명시했다는 것입니다.

아직인 것도 세 가지입니다. 클라우드 전용이라 로컬 실행은 "곧"이고, 로컬 파일과 사내망 도구에는 닿지 않으며, Pro·Max 일부 베타에서 시작해 Team·Enterprise는 예정입니다. 사내 ERP처럼 사내망 안쪽이 필수인 일이라면 로컬 지원 뒤가 맞습니다.

Anthropic은 이 제품을 "비서실장에게 브리핑하듯" 쓰라고 설명합니다. 위 표의 첫 줄과 같은 말입니다.

그래도 사람이 남는 자리

AI 팀을 꾸리면 내 일이 없어지는 게 아니라 팀장 일만 남습니다. 팀장 일이 쉬운 건 아니었죠. 남는 자리는 셋입니다.

  1. 브리프. 목표, 제약, 완료 기준, 보고 형식. 어느 모델도 대신 써 주지 않습니다. 1단계가 부실하면 5단계까지 부실합니다.
  2. 결정. 보고에 붙어 오는 제안은 제안입니다. 섹션 적용 순서, 되돌릴 수 없는 변경, 운영과의 약속은 사람이 정합니다. 정한 것은 의사결정 기록으로 남겨야 다음 스레드가 같은 질문을 안 합니다.
  3. 예산. 모델 배분이 곧 비용 결정이고, 병렬 수가 곧 지출 속도입니다. "얼마나 병렬로 갈지"는 기술 설정이 아니라 예산 결정입니다.

정리

  • 대화 상대와 실행자는 다릅니다. 한 모델이 다 하면 비싸고 느리고 컨텍스트가 망가집니다.
  • 일의 종류대로 모델을 나누면 — 전략 Fable, 판단 Opus, 반복 Sonnet — 팀으로 하던 일이 1인 분할 작업이 됩니다. 샘플 10개로 시작해 섹션 단위로 넓히면 디데이도 사라집니다.
  • Claude Code Projects는 그 구조에 이름을 붙인 제품입니다. 사람의 자리는 줄지 않고 브리프·결정·예산으로 옮겨 갑니다.

참고: Anthropic — Projects, redesigned · VentureBeat 보도

Advertisement글 최하단 · 띠배너본 도메인에서만 게재