By Lee Rhim in claude-code — 05 Apr 2026

22. 큰 프로젝트를 쪼개다 — 분해하고, 실행하고, 합치는 구조

도구 하나로는 안 되는 일

지난 글에서 반복 업무를 도구 하나로 처리하는 이야기를 했습니다. 엑셀 정리처럼 입력과 출력이 명확한 작업은 그걸로 충분합니다.

그런데 프로젝트가 커지면 얘기가 달라집니다.

한 가구 회사에서 AX(AI Transformation) 프로젝트를 시작하게 됐습니다. "뭘 해야 하지?"부터가 문제였습니다. 시장 조사를 해야 하고, 경쟁사를 봐야 하고, 내부 현황을 파악해야 하고, 교육 커리큘럼을 짜야 하고, 랜딩페이지도 만들어야 합니다.

머릿속으로는 다 알고 있다고 생각했습니다. 막상 시작하면 빠진 게 나옵니다. 리서치를 하다가 분석이 필요해지고, 분석을 하다가 추가 조사가 필요해지고, 글을 쓰다가 디자인 방향이 안 정해져 있다는 걸 깨닫습니다.

문제는 속도가 아니었습니다. 완성도를 높이려면 내가 생각하는 범위 이상의 것들을 고려해야 하는데, 혼자 생각하면 자기 범위 안에서만 돈다는 거였습니다.

혼자 생각하는 범위의 한계

한 사람이 혼자 프로젝트를 설계하면, 자기가 아는 범위 안에서만 생각합니다. 경험해본 일, 익숙한 절차, 떠오르는 것들. 그 바깥에 있는 것들은 "나중에 생각나겠지" 하고 넘기거나, 애초에 존재한다는 것조차 모릅니다.

이게 첫 번째 문제입니다. 내가 모르는 것을 모릅니다. 경쟁사 분석, 기술 환경 점검, 기존 자료 정리 — 이런 것들은 "당연히 해야 하는데 눈에 안 보이는 것들"입니다. 프로젝트가 한참 진행된 뒤에야 "이걸 왜 처음에 안 했지?" 하고 뒤늦게 발견됩니다.

두 번째, 같은 세션에서 다른 종류의 일을 하면 깊이가 얕아집니다. 자료를 조사하는 일과 그 자료로 글을 쓰는 일은 다른 일입니다. 조사할 때는 넓게 봐야 하고, 글을 쓸 때는 좁혀야 합니다. 데이터를 분석할 때는 패턴을 찾아야 하고, 디자인할 때는 사용자 행동을 생각해야 합니다. 한 번에 다 시키면 어느 것 하나 충분한 깊이에 도달하지 못합니다.

세 번째, 순서가 꼬입니다. A 작업의 결과가 B 작업의 입력이 되는 경우가 있습니다. 그런데 A와 C는 서로 관계가 없어서 동시에 할 수 있습니다. 이 구조를 정리하지 않으면, 기다릴 필요 없는 걸 기다리거나 아직 준비 안 된 걸 시작하게 됩니다.

결국 필요한 건, 내 생각의 범위를 넘어서는 구조였습니다.

거꾸로 추적하기

decompose라는 이름을 붙였습니다. 미션을 작업 단위로 쪼개는 스킬입니다.

핵심은 "최종 산출물에서 거꾸로 추적"하는 방식입니다.

"AX 프로젝트를 시작한다"는 너무 큽니다. 대신 이렇게 묻습니다. "이 프로젝트가 끝나면 뭐가 만들어져야 하는가?" 제안서, 교육 커리큘럼, 랜딩페이지 — 산출물이 정해지면, 각 산출물을 만들려면 뭐가 필요한지 역추적합니다.

제안서를 쓰려면? 시장 데이터, 경쟁사 분석, 내부 현황 파악이 필요합니다.
랜딩페이지를 만들려면? 카피, 디자인 명세, 구현이 필요합니다.

이렇게 추적하면 내가 생각하지 못한 범위가 드러납니다. 머릿속으로 나열할 때는 빠졌던 작업들이, 산출물에서 역으로 추적하면 자연스럽게 나타납니다. "혼자 생각해서 나올 수 있는 목록"의 한계를 구조로 넘기는 방법입니다.

각 작업의 의존성도 이 단계에서 정리합니다. 시장 조사와 경쟁사 분석은 동시에 할 수 있습니다. 하지만 제안서 작성은 둘 다 끝나야 시작됩니다. 이 관계를 정리해두면 뭘 먼저 하고, 뭘 동시에 돌리고, 뭘 나중에 할지가 정해집니다.

다른 일에는 다른 전문가

쪼개진 작업을 누가 하느냐가 다음 문제입니다.

각 작업을 전담할 서브에이전트(sub-agent)를 만들었습니다. 이 각각의 서브에이전트인 worker들이 자기 영역에서만 집중해서 작업합니다. 5종류의 worker를 만들었습니다.

Worker	하는 일	왜 분리했는가
`research-worker`	정보 수집, 검색, 소스 검증	조사할 때는 넓게 봐야 합니다. 한국어와 영어를 병행 검색하고, 최소 3개 소스로 교차 검증합니다.
`analysis-worker`	패턴 파악, 비교 분석, 인사이트 도출	데이터를 먼저 보고 패턴을 찾습니다. 프레임워크는 정리 도구일 뿐, 분석의 시작점이 아닙니다.
`content-worker`	글쓰기, 문서 생성	"독자가 이 글에서 가져갈 한 가지"를 먼저 정의하고 씁니다. 쓴 후에는 추가가 아니라 삭제를 합니다.
`design-worker`	랜딩페이지, 웹 디자인 설계	"이뻐서"가 아니라 "이 독자에게 이 행동을 유도하기 위해"라는 근거가 있어야 합니다.
`development-worker`	코드 작성, API 연동, 자동화	요청된 것만 구현합니다. "혹시 모를" 기능을 추가하지 않습니다.

왜 나눠야 했느냐. research-worker와 content-worker는 다른 사고방식이 필요하기 때문입니다.

research-worker는 정보를 넓게 수집하면서 출처를 검증합니다. 하나의 소스만 믿지 않고, 상충하는 정보가 있으면 양쪽을 다 제시합니다. analysis-worker는 수집된 데이터에서 패턴을 찾고 "그래서 뭘 해야 하는가"까지 연결합니다. content-worker는 분석 결과를 받아서 독자에 맞는 글로 변환합니다.

한 세션에서 이 세 가지를 동시에 시키면, 조사가 얕아지거나 분석이 피상적이 되거나 글이 뭉뚱그려집니다. 각각 독립된 세션에서 자기 일에만 집중시키면, 내가 혼자 생각했을 때는 도달하지 못했을 깊이가 나옵니다. research-worker가 찾아온 경쟁사 사례 중에는 제가 그 회사 이름조차 몰랐던 곳도 있었습니다.

동시에 돌리기

execute라는 이름을 붙였습니다. 쪼개진 작업을 worker들에게 보내는 단계입니다.

의존성이 없는 작업들은 동시에 돌립니다. 시장 조사, 경쟁사 분석, 내부 현황 파악 — 이 세 가지는 서로 결과를 기다릴 필요가 없습니다. 동시에 시작해서 동시에 받으면 됩니다.

의존성이 있는 작업은 순서대로 돌립니다. 분석은 리서치가 끝나야 시작되고, 글쓰기는 분석이 끝나야 시작됩니다.

이 판단은 decompose 단계에서 이미 끝나 있습니다. "작업 A의 결과 없이 작업 B를 시작할 수 있는가?" — 이 질문에 Yes면 병렬, No면 순차. 단순합니다.

하나의 worker가 실패해도 다른 worker는 계속 돌아갑니다. research-worker가 특정 데이터를 못 찾았다고 해서 design 작업까지 멈출 이유는 없습니다.

합치는 것도 별도의 일이다

조각이 다 모였습니다. 그런데 그냥 이어 붙이면 글이 되지 않습니다.

integrate라는 이름을 붙였습니다. 각 worker가 보내온 결과를 하나로 합치는 단계입니다.

각 worker는 자기 결과 끝에 "메인 세션 전달 사항"을 남깁니다. "이 부분은 다른 작업 결과와 연결해서 봐야 합니다", "이 데이터는 추가 확인이 필요합니다" 같은 메모입니다.

integrate는 이 전달 사항들을 모아서 연결점을 찾습니다. 리서치에서 발견한 시장 데이터가 분석의 전제와 맞는지, 콘텐츠의 주장이 리서치 결과와 일치하는지, 디자인 방향이 콘텐츠의 톤과 어울리는지.

처음에는 이 통합 단계가 필요 없다고 생각했습니다. 조각을 이어 붙이면 되지 않나? 해보니 안 됐습니다. 리서치 결과와 분석 결론이 어긋나는 경우가 있었고, 콘텐츠가 참조해야 할 데이터를 빠뜨린 경우도 있었습니다. 통합은 단순 병합이 아니라, 조각들 사이의 불일치를 잡아내고 하나의 흐름으로 만드는 작업이었습니다.

실제로 돌린 결과

한 가구 회사의 AX 프로젝트 시작 단계에서 이 구조를 처음 돌려봤습니다.

decompose에 "AX 프로젝트 킥오프 준비"를 넣었습니다. 산출물을 역추적하니 이런 작업들이 나왔습니다.

시장 환경 조사 (research-worker)
경쟁사 AI 도입 현황 조사 (research-worker)
내부 업무 프로세스 분석 (analysis-worker)
제안서 초안 작성 (content-worker)
소개 페이지 설계 (design-worker)

시장 조사와 경쟁사 조사, 내부 분석은 병렬로 돌았습니다. 제안서는 세 결과가 모인 후 시작됐고, 소개 페이지는 제안서의 핵심 메시지가 정해진 후 시작됐습니다.

머릿속으로만 정리했으면 놓쳤을 작업이 2개 있었습니다. 경쟁사 조사를 "나중에 해야지" 하고 미뤘을 거고, 내부 프로세스 분석은 아예 빠뜨렸을 겁니다. 산출물에서 역추적하니 자연스럽게 드러났습니다. 내 머릿속에 없던 것이 구조 덕분에 나타난 겁니다.

각 worker가 독립적으로 집중해서 작업한 결과물에는, 제가 혼자 생각해서는 닿지 못했을 내용이 들어 있었습니다. research-worker는 한국어와 영어를 병행 검색하면서 제가 검색하지 않았을 키워드로 소스를 찾아왔고, analysis-worker는 수집된 데이터에서 제가 예상하지 못한 패턴을 짚어냈습니다.

통합 단계에서 불일치 하나를 잡았습니다. research-worker가 수집한 시장 규모 데이터와 analysis-worker가 전제로 깔았던 수치가 달랐습니다. 통합 없이 그냥 이어 붙였으면 제안서에 모순된 숫자가 들어갔을 겁니다.

전체 흐름

이 세 단계를 각각 독립된 스킬로 만들었습니다. decompose가 작업을 쪼개면, execute가 서브에이전트를 불러서 실행하고, integrate가 결과를 합칩니다. 하나가 끝나면 다음이 자동으로 이어집니다 — 이걸 cascade라고 부릅니다.

[미션]
  ↓
decompose — 산출물에서 역추적하여 작업 분해, 의존성 분석
  ↓
execute — 서브에이전트(worker)를 불러서 병렬/순차 실행
  ↓
integrate — 결과 수집, 연결점 분석, 최종 산출물 생성
  ↓
[완성]

3개의 스킬과 5종류의 서브에이전트가 엮여서 돌아가는 구조입니다. 미션이 바뀌어도 흐름은 "쪼개고 → 실행하고 → 합친다"로 동일합니다.

이런 구조가 필요한 순간

모든 일에 이 구조가 필요한 건 아닙니다. 엑셀 정리처럼 도구 하나로 끝나는 일은 그냥 도구 하나로 하면 됩니다.

이 구조가 필요한 건, 작업의 종류가 2개 이상이고 각각 다른 사고방식을 요구할 때입니다. 조사와 분석과 작성이 동시에 필요한 프로젝트. 여러 사람이 각자 전문 영역에서 결과를 내고 합쳐야 하는 상황. 혼자 머릿속으로 정리하면 빠뜨리기 쉬운 규모의 일.

사람으로 치면 프로젝트 매니저가 팀원에게 일을 나눠주고, 각자 작업한 결과를 모아서 최종 산출물을 만드는 것과 같습니다. 다만 팀원이 AI worker이고, 일을 나누는 기준이 "산출물 역추적"으로 구조화되어 있을 뿐입니다.

혼자 생각하면 자기 범위 안에서 맴돕니다. 쪼개서 각각 다른 관점으로 실행하고, 합치면 — 그 범위 바깥에 있던 것들이 결과물 안에 들어옵니다.

자주 묻는 질문

Q. worker 5개를 다 써야 하나요?

아닙니다. 프로젝트에 따라 필요한 worker만 쓰면 됩니다. research-worker와 content-worker만 필요한 일도 있고, analysis-worker와 development-worker만 필요한 일도 있습니다. decompose 단계에서 필요한 worker가 자동으로 결정됩니다.

Q. 한 worker가 실패하면 전체가 멈추나요?

독립적인 작업이면 멈추지 않습니다. research-worker가 특정 데이터를 못 찾아도 analysis-worker는 자기 일을 계속합니다. 다만 의존성이 있는 경우 — 리서치 결과가 있어야 시작되는 분석 작업 — 는 선행 작업이 끝날 때까지 기다립니다.

Q. 작은 프로젝트에도 쓸 수 있나요?

쓸 수 있지만, 오버헤드가 생깁니다. 쪼개고 합치는 과정 자체에 시간이 들기 때문에, 30분이면 끝나는 일에는 그냥 한 번에 하는 게 빠릅니다. 작업의 종류가 3개 이상이고 각각 깊이가 필요할 때 효과가 납니다.

이번 글에서는 "쪼개고 실행하고 합치는 구조" — 즉 미션을 분해하고, 각 worker로 실행하고, 결과를 통합하는 흐름을 다뤘습니다.

다음 편에서는 한 단계 더 들어갑니다. 각 서브에이전트가 자기 일에 어떻게 집중하는지, worker 안에서 실제로 무슨 일이 벌어지는지를 살펴봅니다.