체이닝 실험: 언제 나눠야 이득일까

체이닝은 프롬프트를 여러 단계로 쪼개 각 단계의 출력을 다음 단계의 입력으로 넘기는 방식이다. 공개 자료 기준으로는 중간 산출물이 실제로 필요한 복합 작업에서 유리하다는 보고가 있고, 단순 작업에서는 오히려 손해를 본다는 보고도 함께 있다. 이 글은 그 경계를 2026년 기준 공개 자료와 자체 실험 로그로 짚어본다.

체이닝은 언제 단일 프롬프트보다 나을까?

체이닝은 만능 해법이 아니라 조건부 이득이다. 공개 자료들을 종합하면, 분류 라벨·검색 청크 목록·JSON 파싱 결과 같은 구조화된 중간 산출물이 실제로 다음 단계에 필요한 작업에서는 단계형 구조가 유리하지만, 단일 프롬프트로 충분한 단순 작업에서는 쪼갤수록 지연 시간만 늘어난다는 보고가 있다.

• 목표·제약·형식·평가를 먼저 나누고, 그다음에 단계를 나눈다.
• 각 단계는 "무엇을 받아 무엇을 내보내는지" 계약(output contract)으로 명시한다.
• 평가는 단계별 검증과 전체 결과 검증을 따로 돌린다.
• 복합 작업일수록 이득이 크고, 단순 작업일수록 손해가 크다는 경향이 보고된다.
• 체이닝은 기본값이 아니라 작업 성격에 따라 선택하는 도구 중 하나로 다룬다.

이번 실험에서 검증하려 한 건 하나다. 같은 작업을 (a) 단일 프롬프트, (b) 목표·제약·형식을 명시한 뒤 3~4단계로 나눈 체인, 두 방식으로 각각 반복 실행했을 때 결과물의 일관성과 디버깅 난이도가 실제로 달라지는가였다. 정량 벤치마크 점수를 새로 만든 건 아니고, 같은 프롬프트를 반복 실행했을 때 출력이 얼마나 흔들리는지, 실패했을 때 어느 단계에서 막히는지를 로그로 남기는 쪽에 초점을 맞췄다.

목표·제약·형식을 어떻게 나눠 담아야 할까?

구조화의 기본 골격은 목표 → 제약 → 출력 형식 순으로 반복해서 제시된다. UF Business Library는 Goal/Context/Constraints/Output Format 순서를 제안하고, OpenAI의 엔터프라이즈 프롬프팅 가이드는 # Context, # Instructions, # Constraints 같은 헤더로 과제를 물리적으로 분리하라고 안내한다. 실험에서도 헤더 없이 한 문단에 지시·맥락·제약을 섞어 넣었을 때보다, 섹션을 분리했을 때 모델이 요구 형식을 놓치는 빈도가 체감상 줄었다.

Google의 Gemini 문서는 objective, constraints, response format을 명시적으로 나눠 쓰라고 하며, 응답 형식을 JSON·표·불릿 등으로 구체화하고 순서·레이블·구분자가 결과 품질에 영향을 줄 수 있다고 설명한다(Gemini API 프롬프팅 가이드). 실제로 "표로 정리해줘" 같은 느슨한 지시보다 "컬럼명: 항목/기준/근거, 마크다운 표"처럼 구체적으로 못 박았을 때 다음 단계로 넘길 파싱 실패율이 낮았다.

단계 사이의 출력 계약은 어떻게 만들었나?

체이닝의 핵심은 한 단계의 출력을 다음 단계가 그대로 받아 쓸 수 있게 만드는 것이다. 실무 예시로 자주 소개되는 패턴은 "요구사항 추출 → 초안 작성 → 검토/비판 → 최종본" 4단계이며, 각 단계가 독립적으로 테스트 가능하다는 점이 강조된다.

실험에서는 1단계 출력을 JSON으로 고정하고, 2단계 프롬프트가 그 JSON을 그대로 파싱해 쓰도록 설계했다. 여기서 실패 사례가 하나 있었다. 1단계 모델이 종종 JSON 앞뒤에 설명 문장을 덧붙였고, 그 결과 2단계의 파서가 깨지면서 체인 전체가 멈췄다. 이건 모델 성능 문제라기보다 "JSON만 출력하라"는 제약이 형식 지시와 분리되지 않은 채 뭉뚱그려져 있었던 탓이 컸다. 제약을 별도 섹션으로 분리하고 "다른 텍스트 없이 JSON만"이라는 문장을 명시적으로 추가한 뒤에야 실패 빈도가 줄었다. 즉 체이닝이 실패하는 지점은 대개 모델이 아니라 계약을 애매하게 적은 프롬프트 쪽이었다.

각 단계와 전체 결과를 따로 평가하면 뭐가 달라질까?

단계별 평가와 전체 결과 평가를 분리하면 회귀를 더 빨리 찾을 수 있다는 게 공개 자료의 공통된 설명이다. 각 링크를 개별 검증한 뒤 end-to-end 평가를 별도로 돌리는 2중 구조가 실무적으로 유리하다고 보는 시각이 반복해서 등장한다.

실험에서도 전체 결과만 봤을 때는 "그럭저럭 괜찮다"고 넘어갔던 케이스가, 중간 단계 출력을 따로 열어봤을 때는 2단계 초안이 1단계 추출 결과를 절반만 반영하고 있었던 경우가 있었다. 전체 결과 평가만으로는 이 누락이 잘 드러나지 않았다. 평가 기준으로는 정확도 외에 완결성, 어조/명확성, 정책 준수, 사용성, 효율성을 함께 두는 편이 권장되며, 여기에 토큰 비용과 처리 시간을 같이 기록해두면 "정확도는 비슷한데 비용이 두 배"인 케이스를 놓치지 않을 수 있다.

공개 자료들은 체이닝을 어떻게 뒷받침하나?

정량 수치는 벤치마크별 편차가 크지만, 반복적으로 언급되는 요지는 "복합 작업에서 체인형 구조가 단일 프롬프트보다 유리한 경우가 있다"는 것이다. Future AGI는 agentic benchmark 맥락에서 체인형 planner-retriever-writer-validator 구조가 단일 프롬프트 baseline보다 난이도 상위(level-2/3) 문제에서 약 8~12점 높고, 반대로 난이도 하위(level-1) 작업에서는 3~5점 낮으면서 지연 시간이 약 30% 늘어난다고 요약한다. 같은 맥락에서 τ-bench의 retail task 통과율이 프론티어 모델 기준 약 50%, GAIA level 1이 약 55%라는 수치도 함께 인용된다.

다만 이 수치들은 벤더 블로그의 요약치이고 버전에 따라 변동될 수 있다는 점을 같이 적어두는 편이 안전하다(OpenAI 프롬프트 엔지니어링 가이드). 원문 벤치마크나 1차 자료로 교차검증하지 않은 상태에서 이 숫자만으로 결론을 확정하는 건 과도한 해석이다.

체이닝이 오히려 손해였던 지점은 어디였을까?

체이닝이 불리한 경우도 분명하다. 일부 최신 모델은 예전엔 3단계가 필요했던 일을 단일 프롬프트로 처리할 수 있게 되었고, 이 경우 억지로 잘게 쪼개면 오히려 성능이 떨어질 수 있다는 지적이 있다. 실험에서도 단순 요약 작업을 4단계로 쪼갰을 때, 단계마다 API 호출이 추가되면서 응답 시간이 눈에 띄게 늘었을 뿐 결과 품질 차이는 체감하기 어려웠다.

체이닝의 이득은 "중간 산출물이 다음 단계에 실제로 필요한가"에 달려 있다. 그 조건이 성립하지 않는 단순 작업에 체인을 적용하면, 늘어나는 건 지연 시간과 토큰 비용뿐이고 품질 개선은 뚜렷하지 않았다. 이 부분은 이번 실험 표본이 크지 않아 일반화하기는 조심스럽고, 작업 유형별로 더 넓게 반복해볼 필요가 있다.

이번 실험에서 남은 것은 무엇일까?

이번 라운드에서 확인한 건 세 가지 정도다. 첫째, 목표·제약·형식을 섹션으로 분리하는 것만으로도 다음 단계로 넘길 출력의 파싱 실패율이 줄었다. 둘째, 체이닝의 실패는 대개 모델보다 계약이 애매한 프롬프트 쪽에서 발생했다. 셋째, 전체 결과 평가만으로는 중간 단계의 누락이나 회귀를 놓치기 쉬웠다. 반대로 단순 작업에서는 체인을 늘릴수록 비용만 커지는 경우도 있어, "체인을 쓸 것인가"를 매번 다시 판단하는 편이 나아 보였다. 다음 라운드에서는 같은 체인 구조를 서로 다른 난이도의 작업 셋에 반복 적용해, 이득과 손해의 경계를 좀 더 구체적인 표본으로 잡아볼 계획이다.

핵심 정리

• 체이닝은 중간 산출물이 다음 단계에 실제로 필요할 때 유리하고, 단순 작업에서는 지연 시간만 늘어날 수 있다.
• 목표·제약·형식을 섹션으로 분리하면 단계 간 출력 파싱 실패율이 줄어드는 경향이 있었다.
• 실패 원인은 대개 모델 성능이 아니라 출력 계약을 애매하게 적은 프롬프트였다.
• 평가는 단계별 검증과 전체 결과 검증을 함께 돌려야 중간 회귀를 놓치지 않는다.
• 공개 수치(8~12점 우위, 3~5점 열위, 지연 30% 증가 등)는 벤더 요약치이며 교차검증이 필요하다.