1.5복잡한 문제의 분해 기법

분해에는 성격이 다른 두 축이 있습니다. 이 둘을 섞어 쓰면 설계가 흐려집니다.

단계 분해(시간 축). 작업을 시간 순서로 자릅니다. 개요 작성 다음에 초안, 그다음 교정처럼 앞 단계의 출력이 뒤 단계의 입력이 됩니다. 프롬프트 체이닝이 여기에 해당합니다. 얻는 것은 각 단계에서 모델이 한 가지에만 집중한다는 점이고, 내주는 것은 지연입니다.

관심사 분해(역할 축). 같은 대상을 서로 다른 관점으로 봅니다. 계약서 하나를 법무 관점, 재무 관점, 운영 관점으로 각각 검토하는 식입니다. 병렬화의 분할이 여기에 해당하고, 서로 독립적이므로 동시에 돌릴 수 있습니다.

두 축은 함께 쓰입니다. 단계로 자른 뒤 특정 단계 안에서 관점별로 다시 나누는 구조가 흔합니다.

# 단계 분해 후 한 단계 안에서 관심사 분해
clauses = extract_clauses(contract)                      # 1단계
reviews = await gather(*[                                # 2단계, 관점별 병렬
    review(clauses, lens=l) for l in ["법무", "재무", "운영"]
])
report = synthesize(reviews)                             # 3단계

어느 축으로 나눌지 헷갈릴 때의 기준은 의존성입니다. 앞의 결과가 있어야 뒤를 할 수 있으면 단계 분해, 서로 몰라도 되면 관심사 분해입니다.

분해에서 가장 중요한 결정은 개수가 아니라 어디서 자르는가입니다. 기준은 하나입니다. 그 지점의 산출물에 대해 정답을 정의할 수 있는가.

정답을 정의할 수 없는 지점에서 자르면 그 단계는 평가할 수 없고, 전체 품질이 떨어졌을 때 어느 단계의 책임인지 가릴 수 없습니다. 반대로 검증 가능한 지점에서 자르면 단계별 회귀 테스트가 가능해집니다.

예를 들어 계약서 검토를 이렇게 자를 수 있습니다.

• 조항 추출 — 정답 정의 가능. 사람이 표시한 조항 목록과 비교합니다
• 조항 유형 분류 — 정답 정의 가능. 라벨과 대조합니다
• 위험도 판정 — 정답 정의 가능하지만 주관이 섞임. 다수 검토자의 합의로 기준을 만듭니다
• 문장 어조 다듬기 — 정답 정의 어려움. 여기서 자르면 평가할 수 없습니다

마지막 항목은 별도 단계로 두기보다 앞 단계에 붙이는 편이 낫습니다. 자를 수 있다고 해서 자를 이유가 되지는 않습니다.

이 기준은 시험에서 "분해 단위를 정하는 근거"를 묻는 형태로 나옵니다. 토큰 절약이나 단계 수 균형을 근거로 든 선택지는 대개 오답이고, 검증 가능성을 근거로 든 것이 정답입니다.

단계를 나눴다면 그 사이에 프로그램적 검사(gate) 를 둘 수 있습니다. Anthropic이 프롬프트 체이닝을 설명할 때 함께 제시하는 요소입니다.

게이트의 역할은 잘못된 중간 산출물이 다음 단계로 전파되는 것을 막는 것입니다. 모델이 만든 결과를 코드가 확인하고, 조건을 만족하지 못하면 재시도하거나 중단합니다.

clauses = extract_clauses(contract)

# 게이트: 다음 단계로 넘기기 전에 결정적으로 검사한다
if not clauses:
    raise NoClausesFound(contract.id)
if any(c.text not in contract.raw for c in clauses):
    raise HallucinatedClause(contract.id)   # 원문에 없는 조항은 차단

types = classify_clauses(clauses)

두 번째 검사가 특히 유용합니다. 추출된 조항이 원문에 실제로 존재하는지 문자열 대조로 확인하는 것은 결정적이고 비용이 거의 들지 않으면서, 환각을 다음 단계로 넘기지 않는 강한 방어가 됩니다.

게이트를 설계할 때의 원칙은 코드로 확인 가능한 것만 게이트로 만든다는 것입니다. 판단이 필요한 검사를 게이트에 넣으면 그것 자체가 또 하나의 불확실한 단계가 됩니다. 그런 검사는 게이트가 아니라 평가자 단계로 두는 편이 맞습니다.

분해가 항상 이득은 아닙니다. 단계를 늘릴 때마다 세 가지 비용이 붙습니다.

컨텍스트 재전송. 각 단계가 자기 판단에 필요한 배경을 다시 받아야 합니다. 다섯 단계로 나누면 같은 배경 설명이 다섯 번 토큰으로 계산됩니다. 프롬프트 캐싱으로 상당 부분 완화되지만 사라지지는 않습니다.

오류 누적. 각 단계의 정확도가 0.95여도 다섯 단계를 통과하면 종단 간 정확도는 크게 떨어집니다. 단계를 늘리는 결정은 각 단계가 그만큼 쉬워져 정확도가 올라간다는 가정 위에 서 있습니다. 그 가정이 성립하지 않으면 나누는 것이 손해입니다.

지연 누적. 순차 단계는 지연이 더해집니다. 지연 SLA가 빡빡한 시스템에서 체인을 길게 만드는 것은 직접적인 위반 원인이 됩니다.

이 셋을 감안하면 실무의 판단 기준이 나옵니다. 단계를 하나 더 나눌 때는 그 단계가 정확도를 얼마나 올리는지 평가 집합으로 확인한 뒤에 확정합니다. 나눠 보고 좋아지지 않으면 되돌립니다.

되돌리는 실험은 간단합니다. 인접한 두 단계를 하나의 프롬프트로 합쳐 같은 평가 집합에 돌려 보고, 품질이 유지되면 합친 쪽을 택합니다. 이 확인 없이 만들어진 긴 체인은 대부분 필요 이상으로 깁니다.