CCAF 101

Task Decomposition

11 min read

Task Decomposition

이 문서는 CCAF Domain 1을 이해하기 위한 개념 설명용 노트다.
여기서는 task decomposition을 단순한 작업 분할 기법이 아니라, 복잡한 문제를 더 정확하고 안정적으로 풀기 위해 에이전트의 집중 범위와 실행 단위를 설계하는 방법으로 이해하는 데 초점을 둔다.

Task decomposition이란 무엇인가

Task decomposition은 큰 문제를 더 작고 다루기 쉬운 단위로 나누는 과정이다.
하지만 핵심은 단순히 많이 쪼개는 것이 아니다.

좋은 decomposition은:

  • 각 단계의 목표를 분명하게 만들고
  • 필요한 입력과 출력을 선명하게 정의하고
  • 각 실행 단위가 좁은 범위에 집중하게 만든다

즉 decomposition의 목적은 분산 자체가 아니라,

복잡한 문제를 더 명확한 실행 경계로 바꾸는 것

이다.

왜 decomposition이 필요한가

하나의 큰 문제를 단일 agent(Agent Loop)에게 한 번에 던지면 다음 문제가 생기기 쉽다.

  • 문맥이 너무 커진다
  • 여러 목표가 한 응답 안에 섞인다
  • 중요한 하위 문제를 건너뛸 수 있다
  • attention이 분산된다
  • 중간 검증 없이 바로 결론으로 점프할 수 있다

특히 조사, 분석, 리팩터링, 대규모 문서 작성처럼 여러 단계가 필요한 작업일수록 그렇다.

이럴 때 decomposition을 하면 각 단계가 더 좁고 명확한 문제를 다루게 되고, 전체 품질도 더 안정적으로 관리할 수 있다.

decomposition의 핵심은 “많이 나누기”가 아니다

분해를 처음 떠올릴 때 흔히 하는 오해는 이거다.

작업은 잘게 나눌수록 항상 좋다.

그건 아니다.

너무 잘게 나누면:

  • 조정 비용이 커지고
  • 단계 간 전달이 많아지고
  • 전체 흐름이 오히려 끊기고
  • synthesis 비용이 증가한다

즉 decomposition의 핵심은 개수가 아니라,

어디에서 경계를 자르는 것이 가장 자연스러운가

를 잘 판단하는 것이다.

좋은 경계는 보통 다음 특징을 가진다.

  • 단계 목표가 분명하다
  • 출력이 다음 단계 입력으로 자연스럽게 이어진다
  • 각 단계의 실패 원인을 따로 볼 수 있다
  • 중간 점검 포인트를 만들 수 있다

Prompt chaining과 staged workflow

가장 기본적인 decomposition 형태는 prompt chaining이다.

즉 하나의 거대한 요청을 한 번에 처리하는 대신, 여러 단계를 순차적으로 나누어 처리하는 방식이다.

예를 들면:

  1. 자료 수집
  2. 핵심 포인트 추출
  3. 구조 설계
  4. 최종 답변 작성

이런 staged workflow의 장점은:

  • 각 단계 목표가 선명하고
  • 중간 결과를 검토할 수 있고
  • 오류가 생기면 어느 단계에서 틀어졌는지 보기 쉽다는 점이다

즉 prompt chaining은 단순한 편법이 아니라,

모델 작업을 점진적으로 안정화하는 구조적 방법

이다.

Fixed decomposition과 Dynamic decomposition

Task decomposition에는 크게 두 가지 접근이 있다.

Fixed decomposition

항상 정해진 절차대로 나누는 방식이다.

예:

  • 입력 검증
  • 자료 조회
  • 분석
  • 최종 작성

장점:

  • 일관성이 높다
  • 테스트와 운영이 쉽다
  • 규칙 기반 업무에 잘 맞는다

즉 fixed decomposition의 강점은 운영 안정성이다.

단점:

  • 예외 상황에 덜 유연하다
  • 복잡한 탐색형 문제에는 답답할 수 있다

Dynamic decomposition

문제의 성격에 따라 그때그때 분해 방식을 바꾸는 방식이다.

예:

  • 어떤 문서는 별도 조사 단계가 필요하고
  • 어떤 문제는 로그 분석을 먼저 해야 하고
  • 어떤 경우는 하위 주제를 추가로 나눠야 하는 식

장점:

  • 복잡한 문제에 더 유연하다
  • 탐색형 작업에 강하다

즉 dynamic decomposition의 강점은 탐색 유연성이다.

단점:

  • 구조가 흔들리기 쉽다
  • Coordinator 품질에 크게 의존한다

실무에서는 둘 중 하나만 쓰기보다,

기본 골격은 고정하되, 필요한 부분만 동적으로 확장하는 방식

이 자주 쓰인다.

언제 단일 agent로 충분하고, 언제 분해가 필요한가

모든 작업에 decomposition이 필요한 것은 아니다.

단일 agent로 충분한 경우

  • 질문이 짧고 명확하다
  • 입력 자료가 작다
  • 중간 검증 단계가 거의 필요 없다
  • 결과 형식이 단순하다

예:

  • 간단한 요약
  • 짧은 설명
  • 작은 코드 수정
  • 단일 문서 리뷰

decomposition이 필요한 경우

  • 입력 자료가 많다
  • 서로 다른 하위 문제를 함께 다뤄야 한다
  • 조사 → 분석 → 작성처럼 단계가 분명하다
  • 중간 검증이 중요하다
  • 부분 실패를 따로 추적해야 한다

예:

  • 대규모 리서치
  • 복잡한 버그 원인 분석
  • 긴 문서 체계 설계
  • 여러 파일/문서를 종합하는 작업

요점은 이거다.

작업이 길어서가 아니라, 서로 다른 종류의 판단이 섞일 때 decomposition이 필요해진다.

Attention dilution은 왜 중요한가

큰 문제를 한 번에 던지면 모델은 많은 요소를 동시에 붙잡아야 한다.

  • 요구사항 이해
  • 자료 해석
  • 중요한 포인트 선택
  • 구조 설계
  • 최종 표현

이 모든 것을 한 번에 처리하려 하면 attention이 분산되기 쉽다.
그 결과 모델은 일부 요구사항을 놓치거나, 중요하지 않은 부분에 과도한 비중을 두거나, 충분한 중간 검증 없이 평균적으로 무난한 답으로 서둘러 수렴할 수 있다.

Decomposition은 이 attention burden을 줄여준다.

즉 각 단계가 더 좁은 문제를 다루게 되면, 모델은 더 선명한 기준으로 판단할 수 있다.

decomposition은 synthesis를 전제로 해야 한다

작업을 나누는 것만으로는 충분하지 않다.
분해가 끝나면 결국 다시 합쳐야 한다.

즉 좋은 decomposition은 항상 synthesis를 전제로 설계되어야 한다.

중요한 질문은 다음과 같다.

  • 각 단계 결과를 어떻게 합칠 것인가
  • 충돌하는 결과를 어떻게 다룰 것인가
  • 누락된 부분을 어떻게 찾을 것인가
  • 어느 시점에 재분해(re-decomposition)할 것인가

따라서 decomposition은 분해 기술이면서 동시에,

재통합을 고려한 설계 기술

이기도 하다.

런타임 관점에서 보면

OpenClaw 같은 런타임에서 task decomposition은 단순히 “프롬프트를 나누는 요령”이 아니라, 실행 경계와 문맥 전달을 설계하는 운영 기술에 가깝다.

즉 런타임은:

  • 어떤 단위를 별도 실행으로 분리할지 정하고
  • 어떤 문맥을 각 단계에 넘길지 정하고
  • 어떤 중간 산출물을 저장할지 정하고
  • 어디서 다시 합칠지 정해야 한다

이 관점에서 decomposition은 문장 기술이 아니라, 워크플로우 설계와 문맥 관리의 핵심 메커니즘이다.

흔한 오해

“분해하면 항상 더 똑똑해진다”

아니다. 잘못 나누면 오히려 coordination 비용과 오류 표면이 늘어난다.

“복잡하면 무조건 subagent를 많이 써야 한다”

그것도 아니다. 어떤 문제는 순차적 prompt chaining만으로도 충분하다.

“분해는 planner 단계에서 한 번만 하면 끝난다”

실무에서는 그렇지 않다. 진행 중에 새로운 하위 문제가 드러나면, 다시 나누거나 경계를 수정해야 할 수도 있다.

한 문장 요약

Task decomposition은 큰 문제를 무조건 잘게 쪼개는 기술이 아니라, 각 실행 단위가 더 선명한 목표와 더 적은 attention burden으로 일할 수 있게 경계를 설계하는 방법이다.

관련 개념

그래프 뷰

백링크