AI에게 번역을 시키면서 깨달은 오케스트레이션의 힘

목차

AI에게 복잡한 작업을 시키면 무슨 일이 일어나는가

AI에게 “이 글 번역해줘”라고 한 마디 하면, 언뜻 괜찮아 보이는 결과물이 나온다. 그런데 자세히 읽어보면 “의 경우”, “그것은”, “된다” 같은 번역투가 곳곳에 보인다. 같은 글을 다시 번역하면 결과가 달라지기도 한다. 어떤 날은 자연스럽고, 어떤 날은 어색하다.

번역이라는 작업의 본질적 복잡성을 생각해보면 이건 당연한 결과다. 번역은 단순한 언어 변환이 아니다. 의미를 정확히 전달하면서도 자연스러운 한국어를 만들어야 하고, 기술 용어의 일관성을 유지해야 하며, 원문의 뉘앙스까지 보존해야 한다. 한 에이전트에게 이 모든 관심사를 동시에 맡기면, 각 관심사가 서로를 방해하여 모든 것이 중간 수준으로 수렴하게 된다.

이번 글에서는 필자가 설계한 멀티 에이전트 번역 시스템을 통해, AI 오케스트레이션의 설계 원칙과 트레이드오프를 살펴보려 한다.

단일 에이전트의 한계: 확증 편향과 인지 과부하

하나의 AI 에이전트에게 “번역하고 검증까지 해줘”라고 시키면 어떻게 될까? 번역은 어색하고, 검증은 형식적이다. 자기 작업을 자기가 검증하니 “뭐 괜찮은 것 같은데?”라며 넘어가는 식이 되는 것이다.

이것은 심리학에서 말하는 확증 편향(Confirmation Bias) 과 같은 현상이다. 인간도 자기가 작성한 보고서를 자기가 검토하면 오류를 놓치기 쉽다. AI 에이전트도 마찬가지다. 자신이 생성한 번역을 자신이 평가하면, “이미 최선의 선택을 했다”는 방향으로 편향된 판단을 내리게 된다.

여기에 프롬프트 과적(Prompt Overloading) 문제도 겹친다. AI 에이전트를 써본 개발자라면 한 번쯤 경험해봤을 것이다. “번역해줘, 근데 번역투는 빼고, 원문 의미도 정확하게 유지하고, 용어는 일관되게, 스타일 가이드도 따라줘”라고 프롬프트 하나에 욱여넣으면, 에이전트는 모든 지시를 따르려다가 어느 것도 제대로 못 하게 된다. 지시사항이 많아질수록 각각의 수행 품질이 떨어지는 현상, 프롬프트 엔지니어링에서 흔히 겪는 문제다.

그렇다면 해법은 무엇인가? 소프트웨어 엔지니어링에서 이미 검증된 원칙을 AI 시스템 설계에 적용하는 것이다.

관심사의 분리: 6개 에이전트의 역할 설계

소프트웨어 설계에는 SoC(Separation of Concerns)라는 원칙이 있다. 각 모듈이 하나의 책임만 갖도록 분리하는 것이다. 마이크로서비스 아키텍처에서 각 서비스가 단일 책임을 갖는 것과 같은 맥락이다.

필자는 이 원칙을 번역 시스템에 그대로 적용했다. “번역”이라는 하나의 작업을 5개 관심사로 분해하고, 각 관심사에 전문 에이전트를 배치했다.

여기서 핵심은 “무시하는 것” 열이다. 각 에이전트가 자신의 관심사 외의 것을 명시적으로 무시하도록 설계한 것이다. reviewer는 오직 한국어 자연스러움만 보고, verifier는 오직 원문 충실도만 본다. 서로 간섭하지 않으니, 각자의 전문 영역에서 더 깊이 있는 판단을 내릴 수 있다.

이건 실제 개발팀의 코드 리뷰와 같은 원리다. 자기 코드를 자기가 리뷰하지 않는다. 다른 사람이 리뷰해야 문제를 발견한다.

이들이 협력하는 전체 파이프라인은 다음과 같다.

사용자: /translate-writer <URL> [--mode=quick|thorough|perfect]
                          |
                          v
          +-------------------------------+
          | Phase 0: 스타일 가이드 확인     |
          | - style-guide.md (73+ 규칙)   |
          | - glossary.md, series.md 참조  |
          +-------------------------------+
                          |
                          v
          +-------------------------------+
          | Phase 1: 번역 생성            |
          | (content-translator)          |
          | - 원문 수집 + 73+ 규칙 참조    |
          | - 마크다운 파일 생성           |
          +-------------------------------+
                          |
            +-------------+-------------+
            v                           v
+---------------------+   +---------------------+
| Phase 2a:           |   | Phase 2b:           |
| translation-reviewer|   | translation-verifier|
| (병렬 실행)          |   | (병렬 실행)          |
|                     |   |                     |
| "한국어로서          |   | "원문의 의미가       |
|  자연스러운가?"      |   |  정확히 전달됐나?"   |
|                     |   |                     |
| 28개 패턴 검사       |   | T1-T10 체크리스트   |
| 10점 만점            |   | 10점 만점           |
+---------------------+   +---------------------+
            |                           |
            +-------------+-------------+
                          v
        +---------------------------------+
        | 점수 병합 & 재검증 루프          |
        | - 기준 미달 -> 수정 후 재검증    |
        | - 최대 3회 반복                  |
        +---------------------------------+
                          |
                          v
          +-------------------------------+
          | Phase 3: 정밀 다듬기          |
          | (polish-agent)                |
          | - 문장별 3-4개 개선 옵션       |
          | - 사용자 최종 선택             |
          +-------------------------------+
                          |
                          v
          +-------------------------------+
          | Phase 5: 학습                 |
          | (translation-learner)         |
          | - 피드백 -> 규칙 추출          |
          | - style-guide.md 자동 업데이트 |
          +-------------------------------+

이중 검증 시스템: 견제와 균형의 원칙

번역에는 근본적인 트레이드오프가 존재한다.

자연스러운 한국어 vs 원문 의미 보존

이 둘은 종종 충돌한다. 실제 사례를 보자.

이 충돌을 해결하려면 두 관점을 독립적으로 확보해야 한다. 여기서 중요한 것은 “독립적”이라는 단어다.

앵커링 바이어스와 병렬 실행

처음에는 reviewer를 먼저 실행하고 verifier를 나중에 실행하는 순차 방식을 시도했다. 그런데 이상한 현상이 발견됐다. verifier가 항상 reviewer의 점수와 비슷한 점수를 매기는 것이었다.

이것은 심리학에서 말하는 앵커링 바이어스(Anchoring Bias) 다. 먼저 제시된 숫자가 이후 판단의 기준점(앵커)이 되는 현상이다. reviewer가 8점을 주면, verifier도 “7~8점 정도가 적당하겠지”라고 판단하게 된다. 독립적이어야 할 두 검증이 사실상 하나의 관점으로 수렴해버리는 셈이다.

해법은 병렬 실행이었다. reviewer와 verifier를 동시에 실행하면, 서로의 평가를 볼 수 없다. 순수하게 자기 관점에서만 평가한다.

1. translation-reviewer (한국어 품질): 28개 번역투 패턴을 검사한다. “~것이 가능하다”, “~에 의해”, “그것은/이것은” 과다 등을 10점 만점으로 채점한다.
2. translation-verifier (원문 충실도): T1-T10 체크리스트로 의미 누락, 왜곡, 추가, 인과관계 반전, 부정/긍정 반전 등을 10점 만점으로 채점한다.
3. 기준: 둘 다 8점 이상이어야 통과. 어느 한쪽이라도 미달이면 최대 3회까지 재검증 루프를 돈다.

재검증 루프의 분기 로직은 다음과 같다.

반복 (최대 3회):
  1. 병렬 실행: reviewer + verifier

  2. 결과 병합:
     - 둘 다 기준 이상 -> Phase 3으로 진행
     - reviewer만 미달 -> 번역투 수정 지시 전달
     - verifier만 미달 -> 의미 오류 수정 지시 전달
     - 둘 다 미달 -> 두 보고서 통합하여 재번역

  3. 3회 후에도 미달 -> 사용자에게 상황 보고

3회 제한을 둔 데에도 이유가 있다. 초기에는 제한 없이 설계했는데, verifier가 계속 6점대를 주며 4, 5, 6…회차까지 간 사례가 있었다. 원인을 분석해보니 원문 자체가 모호한 문장이었다. 시스템의 한계를 인정하고 사람에게 판단을 넘기는 것도 설계의 일부인 것이다.

번역하다보면 가끔 마주치게 되는 상황이다. 원문이 항상 완벽한 글은 아니다.

피드백 루프: 시스템이 학습하는 메커니즘

소프트웨어 엔지니어링에서 피드백 루프(Feedback Loop) 는 시스템이 자기 출력을 평가하고 개선하는 순환 구조를 말한다. CI/CD 파이프라인이 테스트 결과를 기반으로 배포 여부를 결정하는 것처럼, 이 번역 시스템도 사용자의 피드백을 지식으로 변환하여 다음 번역에 자동 적용한다.

사용자 피드백 (승인/거절/수정)
    |
    v
translation-learner 분석
    |
    +-> 피드백 유형 분류 (긍정/부정/용어/수정)
    +-> 구체적 사례에서 패턴 추출
    +-> 패턴을 일반화된 규칙으로 변환
    |
    v
style-guide.md 업데이트
    |
    +-> "반드시 피해야 할 표현" 섹션에 추가
    +-> "자연스러운 표현 패턴" 섹션에 추가
    +-> 용어집 업데이트 제안
    |
    v
다음 번역에 자동 적용

핵심은 구체적 사례에서 일반화된 규칙을 추출한다는 점이다. 단순히 “이 문장을 이렇게 고쳐라”가 아니라, “이런 패턴의 문장은 항상 이렇게 변환하라”는 규칙을 만들어낸다.

실제 학습 사례: Before/After

스타일 가이드의 진화 타임라인

8번의 피드백에서 73개의 규칙이 나왔다. 각 피드백에서 평균 9개의 규칙이 추출된 셈이다. 번역을 할수록 시스템이 사용자의 취향을 학습하고, 다음 번역의 품질이 올라가는 구조다.

품질 모드: 리소스 할당의 트레이드오프

소프트웨어 엔지니어링에서 품질과 비용은 항상 트레이드오프 관계에 있다. 모든 코드에 100% 테스트 커버리지를 요구하는 것이 비현실적이듯, 모든 번역에 동일한 리소스를 투입하는 것도 낭비다.

이 시스템은 3단계 모드로 리소스 할당을 조절한다.

quick은 이중 검증만 통과하면 바로 결과를 내놓고, perfect는 거의 모든 문장을 정밀 다듬기 단계까지 거친다. 실제로 Claude Skills 가이드 6부작은 thorough 모드로 번역했으며, 파트당 15-20분이 소요되었다.

“항상 최고 품질”은 이상적이지만 현실적이지 않다. 사용자가 상황에 맞게 품질 수준을 선택할 수 있어야 한다.

정량적 검증: 시스템의 성과

설계 원칙이 실제로 작동하는지는 숫자로 확인해야 한다.

시스템 규모

성과 지표

학습 효율

13편 번역에 거절이 0회라는 것은, 이중 검증 시스템과 피드백 루프가 실제로 품질을 보장하고 있다는 증거다. 물론 이 숫자만으로 시스템의 완전성을 주장할 수는 없다. 번역 대상이 기술 블로그라는 특정 도메인에 한정되어 있고, 평가자가 필자 한 명이라는 한계도 있다. 다만 “설계 원칙이 의도한 방향으로 작동하고 있는가?”라는 질문에 대해서는, 이 수치들이 긍정적인 신호를 보내고 있다고 판단한다.

그래서 AI 오케스트레이션이란 결국

지금까지의 내용을 정리하면, AI 오케스트레이션의 핵심 설계 원칙은 다음과 같다.

1. 관심사의 분리: 복잡한 작업을 단일 관심사로 분해하고, 각 에이전트에게 하나의 책임만 부여한다. “무시하는 것”을 명시하는 것이 핵심이다.
2. 견제와 균형: 생성자와 검증자를 분리하고, 서로 다른 관점의 검증자를 병렬로 실행하여 앵커링 바이어스를 방지한다.
3. 피드백 루프: 사용자의 피드백을 일반화된 규칙으로 변환하여 시스템에 축적한다. 번역을 할수록 시스템이 성장하는 구조를 만든다.
4. 리소스 할당의 유연성: 모든 작업에 동일한 리소스를 투입하지 않는다. 상황에 맞게 품질 수준을 조절할 수 있도록 모드 시스템을 설계한다.

이 원칙들은 번역에만 국한되지 않는다. 코드 리뷰, 기술 문서 작성, 데이터 분석 등 어떤 복잡한 작업이든 “쪼개고, 전문화하고, 검증하고, 학습시키는” 패턴을 적용할 수 있다.

다만 한 가지 역설이 있다. 오케스트레이션 시스템을 설계하는 것 자체가 상당한 초기 비용을 수반한다는 점이다. 6개 에이전트의 책임 경계를 정의하고, 검증 체크리스트를 설계하고, 피드백 루프를 구축하는 데는 단순히 “번역해줘”라고 프롬프트를 던지는 것보다 훨씬 많은 노력이 필요하다. 이 투자가 정당화되려면, 시스템을 반복적으로 사용해야 한다. 한 번 쓰고 말 작업이라면 단일 프롬프트가 더 효율적이다.

결국 AI 오케스트레이션은 “프롬프트를 잘 쓰는 것”의 다음 단계다. 각 에이전트의 책임을 정의하고, 협업 방식을 설계하고, 학습 메커니즘을 구축하는 것. 이것은 소프트웨어 아키텍처 설계와 본질적으로 같은 작업이다.

마무리

AI 하나를 더 똑똑하게 만드는 것보다, 여러 AI가 잘 협업하도록 설계하는 것이 더 효과적인 경우가 있다. 단일 에이전트의 확증 편향, 관심사의 분리, 병렬 검증의 독립성, 피드백 루프를 통한 지식 축적. 이 모든 설계 결정의 근거는 소프트웨어 엔지니어링에서 이미 검증된 원칙들이다.

필자는 이 시스템으로 13편의 번역을 발행했고, 그 과정에서 73개의 규칙이 자동으로 축적되었다. 시스템은 쓸수록 강해졌다.

참고 자료

• Claude Code 공식 문서
• 번역된 Claude Skills 가이드 시리즈