지난번까지는 Omnigent의 구성을 이해하고, Polly를 통해 코드 크로스 리뷰(Cross-review)를 실행해 왔습니다. 하지만 만지다 보니 "합성의 가치란 결국 크로스 리뷰 정도인가?"라는 의문이 생겼습니다. 병렬로 서브 에이전트(Sub-agent)를 실행하는 것뿐이라면 Claude Code 단독으로도 가능합니다.

이 기사에서는 또 다른 동봉 에이전트인 Debby를 실행하여, 합성의 완전히 다른 측면을 체험합니다. Debby는 동일한 질문을 여러 모델에 던져 대조하고, 토론하게 하여 통합까지 이끌어가는 에이전트입니다. "합성 = 병렬"도 "합성 = 크로스 리뷰"도 아닌, 제3의 합성이 보입니다.

먼저 용어를 정리하겠습니다. Polly도 Debby도 Omnigent에 동봉된 샘플 에이전트 정의(YAML 1장)입니다. Omnigent 본체의 기능이 아니라, "Omnigent로 이런 에이전트를 구성할 수 있습니다"라는 공식 예시가 2개 들어있다는 위치 선정입니다. 지난번 아키텍처 편에서 보았듯이, 에이전트는 name / prompt / executor(하네스)/ tools를 작성한 YAML에 불과하며, Polly도 Debby도 그 실례입니다.

두 에이전트는 합성의 다른 패턴을 보여주기 위해 준비되었습니다.

Polly는 코딩 오케스트레이터(Orchestrator)입니다. 스스로 코드를 작성하지 않고, 태스크를 분할하여 claude_code / codex / pi 서브 에이전트에게 각각 별도의 worktree에서 병렬 구현을 시키고, 다른 벤더에게 크로스 리뷰를 시킵니다. "구현을 분할·병렬화하고, 상호 체크하는" 합성입니다.

Debby는 두 개의 머리를 가진 브레인스토밍 상대입니다. 스스로 답하지 않고, 모든 질문을 claude와 gpt라는 두 개의 서브 에이전트에 동시에 던져 양쪽의 관점을 나열합니다. debate 스킬을 읽어들이면, 두 에이전트가 서로의 답변을 비평한 후 통합으로 수렴합니다. "동일한 질문을 여러 모델에 던져 대조하는" 합성입니다.

두 에이전트의 공통점은 뇌 자체는 claude-sdk 하네스로 동작하여 지휘에 전념하고, 실제 작업(구현 또는 응답)은 다른 서브 에이전트에게 위임하는 오케스트레이터 구조라는 점입니다. 차이점은 목적뿐이며, Polly는 코드 구현의 분할·병렬·리뷰를, Debby는 동일 질문의 다중 모델 비교·토론을 담당합니다. 이름은 단순한 샘플의 애칭이며, 동일한 형식으로 직접 만들면 독자적인 오케스트레이터도 만들 수 있습니다.

실행하기 전에 Debby의 에이전트 정의를 읽어둡시다. 가지고 있는 clone 저장소에 있습니다.

cd ~/src/omnigent
cat examples/debby/config.yaml

정의를 통해 Debby의 내부 구조가 명확해집니다. 뇌는 claude-sdk 하네스로 움직이며, 스스로 실질적인 사고를 하지 않습니다. 두 개의 순수한 응답 역할인 서브 에이전트, claude (claude-sdk 하네스)와 gpt (codex 하네스)를 가지며, 모든 질문을 양쪽에 병렬로 던져 각각의 답을 나열합니다. debate 스킬을 읽어들이면, 두 에이전트에게 서로의 답변을 비평하게 하고, 지정된 라운드 수만큼 토론하게 한 뒤 통합합니다.

이 부분이 Polly와의 구조적 차이점입니다. Polly의 서브 에이전트는 worktree에서 코드를 작성하는 구현 역할이었지만, Debby의 서브 에이전트는 동일한 질문에 대한 두 개의 응답 역할입니다. 태스크를 분할하는 것이 아니라, 동일한 질문을 여러 벤더에게 병행시키고 있습니다.

전제로 Debby의 두 머리는 claude-sdk와 codex 하네스로 동작하므로, Claude와 OpenAI 양쪽 프로바이더가 필요합니다. 지난번 스모크 테스트에서 양쪽 구독을 설정해 두었다면 그대로 동작합니다.

Debby는 코드를 쓰지 않고 문답만 하므로 git 리포지토리는 필요하지 않습니다. 일회용 디렉토리에서 실행합니다.

mkdir -p ~/work/debby-try && cd ~/work/debby-try
omni run ~/src/omnigent/examples/debby/

http://localhost:6767에 Web UI가 열립니다. 화면 하단에 "Debby (Claude SDK)"라고 표시되어, 뇌가 claude-sdk로 동작하고 있음을 알 수 있습니다.

두 모델 사이에서 차이가 날 법한 질문을 던집니다. 사실에 기반한 일문일답보다는, 판단이나 설계가 포함된 질문이 모델의 개성이 드러나 더 흥미롭습니다.

Python으로 대량의 CSV를 집계하는 처리를 작성할 때, pandas와 polars 중 어느 것을 선택해야 하는가.
각자의 입장에서 주장해 주세요.

전송하면, Debby는 스스로 답하지 않고, claude와 gpt 두 서브 에이전트(sub-agent)에게 동시에 이 질문을 던집니다. 오른쪽 Agents 패널에 pandas-vs-polars-claude와 pandas-vs-polars-gpt 두 개가 매달려 각각 독립적으로 생각하기 시작합니다. 정의된 대로 "스스로 답하지 않고 양쪽에 병렬로 던지는" 동작입니다.

양쪽의 답변이 모두 준비되면, Debby가 두 가지 관점을 나란히 보여줍니다. 이번 결과는 방향성은 일치하면서도 강조점이 갈렸습니다.

양측 모두 새로운 대량의 CSV 집계라면 Polars를 제1후보로 추천하며, 결정적인 이유는 지연 실행 (lazy execution, scan_csv)에 의한 푸시다운 (pushdown)을 통해 속도와 메모리를 모두 잡을 수 있다는 점이라는 데 일치했습니다. pandas의 가치는 에코시스템 (ecosystem)의 두터움과 기존 자산의 연장선에 있다는 평가도 공통적입니다.

반면 강조점은 달랐습니다. Claude는 "애초에 DuckDB라는 제3의 선택지가 있다"를 강력히 추천하며, "빠르다고 해서 반드시 옳은 것은 아니다, 우선 실측하라"라는 실험주의를 내세웠습니다. GPT는 "CSV를 그만두고 Parquet으로 바꾼다"라는 전처리 개선과, pandas 3.0의 Copy-on-Write / PyArrow backend와 같은 pandas 측의 최신 개선 사항을 더 구체적으로 평가했습니다.

같은 질문이라도 한쪽은 DuckDB와 실측주의, 다른 한쪽은 Parquet화와 pandas의 최신 기능이라는 서로 다른 접근 방식이 나옵니다.

여기까지는 2개의 모델에 따로 물어보고 답을 나열했을 뿐이라고도 할 수 있습니다. 솔직히 이 정도라면 손으로 복사해서 붙여넣어도 할 수 있는 일입니다. Debby의 진가는 다음 단계에 있습니다.

빈 화면에 칩(chip)으로 표시된 debate 스킬을 불러옵니다. 채팅창에 /debate라고 입력하기만 하면 됩니다.

이를 실행하면, Debby는 앞서 나온 두 답변을 "라운드 0"로 삼아 1라운드의 상호 비평을 진행합니다. 각각에게 상대방의 답변을 전달하고, 비평과 자기 주장의 업데이트를 요청합니다. 여기서 논의가 실제로 움직였습니다.

Claude는 세 가지 지점에서 명확하게 양보했습니다. Parquet화의 우선순위, 상호 변환 시의 clone 비용, pandas 3.0 CoW의 정확한 단계입니다. 자신의 약점을 솔직하게 인정하며 상류(upstream) 관점을 강화했습니다. GPT는 Claude의 "단정"을 정량적인 면에서 깎아내렸습니다. 성능 배율도 메모리 배율도 "워크로드(workload) 의존적"이며 일반론으로서 너무 단정적으로 말하는 것을 경계하며, pandas의 최신 개선 사항을 반영하도록 촉구했습니다. 숫자를 다루는 데 있어서는 GPT가 더 신중했습니다.

그리고 DuckDB에서 양측이 완전히 합류했습니다. 라운드 0에서는 Claude만이 DuckDB를 지목했고 GPT는 "Spark 계열 / DWH"라고 모호하게 말했지만, 라운드 1에서 GPT도 DuckDB를 명확한 제3의 후보로 격상시키며 양측의 의견이 일치했습니다.

남은 온도 차이는 "지저분한 CSV"를 대하는 태도뿐이었습니다. Claude는 "pandas의 관용성이 실무에서 유용하다"는 점을 남겼고, GPT는 "Polars의 엄격한 스키마 (strict schema)로 불일치를 조기에 찾아낼 수 있다"는 이점을 대치시켰습니다. 이는 우열의 문제가 아니라 설계 사상의 차이로서 양론을 모두 병기하는 것이 타당하다는 정리로 귀결되었습니다.

1라운드 만에 실질적으로 수렴했기에, Debby가 양측을 하나의 결론으로 통합했습니다. 두 개의 독립된 관점이 비평을 거쳐 다음 3단계의 의사결정 프레임워크로 정리되었습니다.

먼저 입력 형식을 의심하라. 동일한 CSV를 반복해서 집계한다면, 처음에 한 번 Parquet화한다. 열 지향(columnar), 스키마 포함, 압축을 통해 라이브러리 선택보다 더 큰 개선을 얻는 경우가 많다 (양측의 합의점).

다음으로 엔진을 선택하라. 새로운 열 중심 ETL이라면 Polars (scan_csv / scan_parquet의 lazy + pushdown), 수백 MB까지의 탐색적 데이터 분석(EDA)이나 sklearn / 시각화 도구와의 직접 연결이 필요하다면 pandas, CSV가 정말 거대하여 SQL로 직접 집계하고 싶다면 DuckDB.

마지막으로 비기술적 요인으로 덮어쓰기(override)하라. 유지보수성, 인수인계, 팀의 기술 역량으로 최종 판단한다.

주의사항으로서, 성능의 "수 배10배"나 메모리의 "25배"도 워크로드 의존적인 지표일 뿐 보증된 수치가 아니라는 점, Polars에서 pandas로의 변환은 from_pandas에서 clone이 발생할 수 있으므로 중간에 pandas로 되돌릴수록 Polars의 이득이 줄어든다는 점이 양측의 합의 사항으로 명시되었습니다.

처음의 두 답변 중 어느 쪽과도 다른, 더 실무적이고 빈틈없는 결론에 도달했습니다. 이것이 단순히 두 개를 나란히 놓는 것만으로는 얻을 수 없는 결과입니다.

여기서, 이전까지 가졌던 "합성(Synthesis) = 크로스 리뷰(cross-review) 혹은 병렬"이라는 이해가 한 단계 확장됩니다.

서브 에이전트 (Sub-agent)를 병렬로 실행하는 가치는 "독립된 태스크를 동시에 처리하여 빠르다"는 것이었습니다. 병렬 그 자체에 가치가 있습니다. 반면 Debby의 /debate는 "독립된 두 관점을 맞부딪혀, 단일 모델로는 도달할 수 없는 결론에 도달하는 것"이었습니다. 병렬이 아니라, 이종 (heterogeneous) 모델을 상호작용시키는 것에 가치가 있습니다.

즉, 합성 (Synthesis)의 본질은 "병렬화할 수 있는가"가 아니라 "이종을 섞어서 상호작용시킬 수 있는가"입니다. 서브 에이전트를 동일한 벤더 (vendor) 내에서 병렬로 실행하는 것만이라면 Claude Code 단독으로도 충분하겠지만, 서로 다른 벤더를 한 세션 (session)에 섞어서 서로 비평하게 하고 통합까지 이끌어내는 것은 메타 하네스 (meta-harness)만의 특징입니다.

또 하나, 이 화면은 그대로 모델의 거동 비교 로그가 됩니다. 동일한 질문에 대한 초기 답변의 차이, 비평을 통해 어느 쪽이 어떻게 양보했는지, 최종적으로 어디에서 일치하고 어디에 온도 차가 남았는지 등을 확인할 수 있습니다. Claude는 DuckDB와 실측주의를, GPT는 수치의 신중함과 pandas 최신 기능을 사용하는 것과 같은 개성을 정성적으로 읽어낼 수 있습니다.

두 모델의 A/B 비교를 수동으로 복사하여 붙여넣지 않고, 심지어 상호 비평까지 포함하여 하나의 세션에서 얻을 수 있습니다. 모델의 장단점이나 응답 스타일의 차이를 일상적으로 보고 싶은 사람에게는 그대로 평가 도구가 됩니다. 단순한 일문일답이 아니라, 판단이 갈리는 설계 문제를 던질수록 그 차이가 명확하게 드러납니다.

Debby를 통해, 합성에는 병렬 구현이나 크로스 리뷰 (cross-review, 상호 체크)와는 별개로, 다중 모델의 토론과 통합이라는 측면이 있다는 것을 체험했습니다. 동일한 질문을 여러 벤더에 던지고, /debate로 상호 비평하게 하여 단일 모델로는 나올 수 없는 결론으로 수렴시킨다. 병렬이 아니라 이종 혼합에 가치가 있다는 합성의 핵심이 여기서 가장 명확하게 보입니다.

Polly와 Debby는 모두 YAML 파일 한 장 분량의 샘플에 불과합니다. 동일한 형식으로 직접 만든다면 자신의 용도에 맞춘 오케스트레이터 (orchestrator)를 구축할 수 있습니다. 다음에는 이 두 가지를 토대로 제어 (policy)나 자작 에이전트로 나아가겠습니다.

• omnigent-ai/omnigent (GitHub)
• Debby / Polly 등 Example Agents (Omnigent 공식)
• 제1탄: Omnigent 개요
• 제2탄: Polly 스모크 테스트
• 제3탄: 아키텍처 (Architecture)