
서로 다른 벤더의 AI로 돌리는 『개선 루프』 — Multi-LLM Reflection의 설계와 도입
요약
단일 LLM의 자기 비판 한계를 극복하기 위해 생성, 비평, 퇴고 역할을 서로 다른 벤더의 모델에 분담시키는 'Multi-LLM Reflection' 설계 방식을 소개합니다. 각 모델의 고유한 사고 편향을 활용하여 논리적 모순을 줄이는 원패스(One-pass) 개선 루프의 메커니즘과 도입 방법을 다룹니다.
핵심 포인트
- 단일 모델의 셀프 리뷰 시 발생하는 사고 편향(Bias) 문제 해결
- Generator, Critic, Refiner 역할을 서로 다른 벤더의 LLM에 할당
- 무한 루프가 아닌 한 바퀴만 도는 효율적인 원패스(One-pass) 구조
- 모델 간의 차이를 이용한 크로스 모델 비평(Cross-model Critique) 활용
서로 다른 벤더의 AI로 돌리는 『개선 루프』 — Multi-LLM Reflection의 설계와 도입

AI에게 문장이나 코드의 초안(Draft)을 쓰게 하는 것은 편리하지만, **"하나의 AI에게 생성과 리뷰를 모두 시키면, 동일한 사고의 습관(Bias)으로 작성하고 동일한 사고의 습관으로 놓치게 된다"**라는 과제에 직면한 적이 없으신가요?
인간의 셀프 리뷰(Self-review)와 마찬가지로, AI도 자신이 작성한 문장이나 코드의 논리적 모순이나 놓친 부분을 자기 리뷰만으로 완벽하게 찾아내는 것은 서툽니다.
이 과제에 대한 하나의 접근법이, 생성(Generation)・비평(Critique)・퇴고(Refinement)라는 세 가지 역할을 의도적으로 서로 다른 벤더의 LLM에 분담시키는 개선 루프 「Multi-LLM Reflection」 입니다. 단, 끝없이 돌아가는 루프가 아니라, Generator → Critic → Refiner라는 원환을 딱 한 바퀴만 돌고 멈추는, 이른바 「원패스(One-pass) 개선 루프」라는 설계로 되어 있습니다.
본 기사에서는 이 리포지토리의 multi-llm-reflection 스킬을 실제로 로컬 환경에 도입하여 구동하기까지의 절차와 그 메커니즘, 적합성과 부적합성, 운용의 베스트 프랙티스(Best Practice)를 해설합니다.
1. Multi-LLM Reflection이란?
Multi-LLM Reflection이란, Generator(생성), Critic(비평), Refiner(퇴고·수정)라는 세 가지 서로 다른 역할을 각각 서로 다른 벤더의 LLM에 할당하여 실행하는 개선 루프입니다. 「루프」라고 부르는 이유는 생성→비평→퇴고라는 원환형 역할 분담 그 자체를 가리키며, 구현(workflow.py)을 보면 이 원환을 딱 한 바퀴만 📝 원재료가 된 Self-Refine 등의 연구에서는 여러 라운드의 반복을 수행하지만, 본 스킬의 구현은 「생성→비평→수정이라는 개선 루프를 서로 다른 벤더의 모델에 분담시켜 한 바퀴만 돌린다」라는 심플한 구성이라는 점에 주의하십시오. 각 스테이지를 1회씩, 독립된 컨텍스트(Context)에서 실행하고 종료합니다. Refiner에서 Critic으로 돌아가 여러 번 돌리는 식의 반복은 수행되지 않습니다.
workflow.py
핵심인 「Cross-model Critique (크로스 모델 비평)」
단일 AI 모델에게 자기 비판을 시키는 것보다, 개발사가 다른 별도의 AI 모델에게 비평하게 하는 것이 논리의 모순이나 놓친 부분을 발견하기 쉽습니다.
각 벤더(Google, Anthropic, OpenAI 등)의 모델은 학습 데이터, 파인튜닝(Fine-tuning) 정책, 얼라이먼트(Alignment) 기법이 다르기 때문에 각각 고유한 「사고의 습관(Bias)」이나 특기 분야를 가지고 있습니다. 어떤 모델에게는 「맹점」인 것이 다른 모델에게는 「발견하기 쉬운 문제점」인 경우가 많기 때문에, 이 차이를 활용하여 출력을 리뷰합니다.

2. 장점·단점과 트레이드오프 (Trade-off)
본 패턴을 도입하기 전에 그 강점과 한계를 이해해 두는 것이 중요합니다.
장점 (얻을 수 있는 효과)
블라인드 스팟(Blind spot)의 완화: Google, Anthropic, OpenAI의 서로 다른 「사고 편향(Thinking Bias)」이 조합되기 때문에, 단일 모델의 셀프 리뷰로는 놓치기 쉬운 논리적 모순이나 에지 케이스(Edge case)에 대한 지적이 반영되기 쉬워집니다. -
리뷰 관점의 초안 작성 가능: 인간이 검토하기 전에 AI들끼리 「한 차례의 지적과 수정」이 완료되어 있으므로, 초기 단계의 거친 리뷰 수고를 줄일 수 있습니다. -
단일 모델보다 폭넓은 1차 초안: 생성·비평·퇴고를 별도의 모델이 담당하므로, 하나의 모델에게 생성부터 마무리까지 맡기는 것보다 관점이 다른 수정 사항이 반영됩니다.
단점 (유의해야 할 제약)
실행 시간(지연)의 증가: 세 가지 CLI를 순차적으로 호출하기 때문에(Generator→Critic→Refiner 총 3회의 모델 호출), 1회 처리 완료까지 수 분이 걸릴 수 있습니다. -
API 비용(토큰 소비)의 증가: 초안과 비평 내용을 각 단계로 인계하기 때문에, 단발성 1회 호출에 비해 입력·출력 토큰 수가 늘어납니다. -
환경 구축의 번거로움: 각 사의 CLI 셋업 및 인증을 각각 완료해 두어야 합니다. -
실행 검증은 이루어지지 않음: 어디까지나 텍스트 기반의 비평·퇴고이며, 코드를 실제로 컴파일·실행·테스트하는 것이 아닙니다. 구문 오류(Syntax error)나 런타임 버그(Runtime bug)의 유무를 보장하는 메커니즘이 아니라는 점에 주의하십시오.
3. 최적의 유스케이스 (Use case)
이 기술의 정체는 「생성 → 비평 → 퇴고라는 개선 루프(Improvement loop)를 각각 서로 다른 벤더의 모델에 한 바퀴씩 담당시키는 텍스트 생성 파이프라인(Text generation pipeline)」이며, 코드를 실행·컴파일·테스트하는 기능은 가지고 있지 않습니다. 이 전제를 고려할 때, 비용과 시간을 들일 가치가 있는 것은 **「텍스트의 완성도 그 자체가 결과물의 품질로 직결되는 태스크(Task)」**입니다.
구체적인 활용 시나리오
CI/CD에 통합하여 사용하는 방법만이 핵심은 아닙니다. 오히려 많은 현장에서는 **로컬에서 인간이 사용하는 「초안 생성(Draft generation)」**으로서의 역할이 더 많을 것입니다. 실제 상황과 실행 예시를 들어보겠습니다.
장애 대응 후의 포스트모템 (Post-mortem, 사후 분석 보고서) 초안
심야의 인시던트(Incident) 대응으로 지친 상태에서 원인 규명 및 재발 방지 대책을 정리한 보고서를 처음부터 쓰는 것은 매우 힘든 일입니다. 우선 초안을 만들고, Critic에게 논리적 비약이나 기재 누락을 지적하게 합니다. skills/multi-llm-reflection/scripts/run.sh "결제 API가 15분 동안 504를 반환한 장애의 포스트모템을 작성해 주세요. 타임라인, 근본 원인, 영향 범위, 재발 방지 대책의 4개 항목을 포함해 주세요."
파괴적 변경(Breaking change)을 수반하는 API 마이그레이션 가이드
인증 방식의 변경이나 API 버전 업그레이드 등, 기존 이용자에게 미치는 영향을 빠짐없이 설명해야 하는 문서입니다. Critic에게 「간과하고 있는 마이그레이션 케이스」를 지적하게 하는 것이 효과적입니다. skills/multi-llm-reflection/scripts/run.sh "인증 방식을 API 키에서 OAuth2로 전환하는 마이그레이션 가이드를 작성해 주세요. 기존 이용자에 대한 영향, 마이그레이션 절차, 지원 종료(Deprecation) 일정을 포함해 주세요."
기술 선정 비교 검토 메모
「왜 이 DB/라이브러리를 선택했는가」를 팀이나 상사에게 설명하는 자료입니다. 서로 다른 벤더의 모델에 리뷰를 맡김으로써, 편향된 비교(자사에 유리한 비교)가 되어 있지 않은지 체크할 수 있습니다. skills/multi-llm-reflection/scripts/run.sh "신규 주문 관리 서비스의 DB를 PostgreSQL과 DynamoDB로 비교 검토하는 메모를 작성해 주세요. 쓰기 특성, 비용, 운영 부하 관점을 포함해 주세요."
구현 코드에 대한 리뷰 코멘트 초안 (CI 이외, 로컬에서의 이용)
리뷰어가 주변에 없는 개인 개발이나, 심야의 혼자 작업 중 커밋하기 전에 다른 벤더의 모델로부터 한 번쯤 지적을 받고 싶을 때 사용합니다. prompt는 단일 인자이므로, 쉘(Shell)의 명령 치환(Command substitution)을 통해 파일 내용을 삽입합니다. skills/multi-llm-reflection/scripts/run.sh "$(cat payment_service.py) 상기 코드를 병렬 처리의 안전성과 에러 핸들링(Error handling) 관점에서 리뷰해 주세요."
단, 출력물은 컴파일·실행되지 않으므로, 「버그가 없음을 보장」하는 용도로는 사용하지 마십시오. 최종적인 정확성은 실제로 빌드·테스트하여 인간이 확인해야 합니다.
고객 대상 공지문·이용 약관의 퇴고
요금제 변경이나 사양 변경 공지 등, 표현의 정확성과 배려가 요구되는 대외 문서입니다. skills/multi-llm-reflection/scripts/run.sh "요금제 변경 안내문을 작성해 주세요. 가격 인상 이유, 적용 시작일, 기존 사용자를 위한 경과 조치를 포함해 주세요."
CI/CD 파이프라인에서의 리뷰 초안 자동 생성
이것은 어디까지나 여러 가지 사용법 중 하나입니다. 풀 리퀘스트(Pull Request) 생성 시 트리거하여, 리뷰 코멘트 초안을 PR에 자동으로 댓글로 다는 등의 운영도 가능합니다 (자세한 내용은 6장).
부적합한 시나리오
- 단순한 API 사양 확인이나 에러 메시지의 의미 검색 (일반적인 LLM에 대한 1회의 질의로 충분합니다).
- 빠른 응답이 요구되는 실시간 채팅 대화나, 대략적인 브레인스토밍.
- 테스트 실행이나 컴파일 등, 실행 검증을 수반하는 품질 보증 (본 기술은 코드를 실제로 구동하지 않으므로, 이 용도를 대신할 수 없습니다).
4. 원 커맨드(One-command) 설치 및 셋업
본 리포지토리의 multi-llm-reflection 등의 기술을 구동하려면 다음과 같은 셋업을 수행합니다.
STEP 1: 기술 패키지 추가 (원 커맨드)
skills CLI (skills.sh
)를 사용하여 사용 중인 코딩 에이전트(Claude Code, Codex, Cursor, Gemini CLI 등)에 본 리포지토리의 스킬을 간편하게 추가할 수 있습니다.
터미널에서 다음 명령어를 실행하기만 하면 됩니다.
npx skills add buddypia/agent-skills
이 명령어 하나만 실행하면 multi-llm-reflection을 포함한 고품질의 자율형 에이전트 스킬 군이 한 번에 설치되어, 에이전트가 해당 기능을 직접 사용할 수 있게 됩니다.
STEP 2: 각사 CLI 백엔드 준비
생성(Generation), 비평(Criticism), 퇴고(Refinement)의 각 단계에서 각 AI(Gemini, Claude, GPT)를 호출하기 위해, 공식 CLI 도구를 각각 설치하고 로그인을 완료해 둡니다.
| 역할 / 단계 | 사용하는 CLI | 설치 방법 | 인증 방법 |
|---|---|---|---|
| Generator (생성) | agy (Antigravity CLI) | 공식 사이트에서 설치 | agy install을 실행하고, 최초 실행 시 OAuth 로그인 |
| Critic (비평) | claude (Claude Code) | npm i -g @anthropic-ai/claude-code | claude를 실행하여 로그인 (구독 필요) |
| Refiner (퇴고) | codex (Codex CLI) | npm i -g @openai/codex | codex login을 실행 (ChatGPT 구독 필요) |
각 CLI가 설치되어 사용할 수 있는 상태인지 확인하려면, 각각의 도움말(help)이나 버전 명령어를 실행해 보면 됩니다.
# 각각 실행했을 때 에러가 발생하지 않고 응답이 돌아오면 OK입니다
agy --help
claude --version
...
STEP 3: Python 실행 환경 준비
본 스킬의 스크립트는 내부적으로 Python(Pydantic 등)을 사용합니다.
프로젝트에서는 uv를 통한 관리를 권장하며, uv가 설치되어 있다면 스크립트 실행 시 자동으로 가상 환경(.venv)이 생성 및 동기화되므로 수동 설치는 필요하지 않습니다. (※ 만약 uv가 없는 경우에도, 스크립트가 자동으로 표준 venv + pip를 사용하여 폴백(fallback)합니다.)
5. 구체적인 사용법
설치가 완료되면 에이전트 환경이나 스크립트에서 간편하게 실행할 수 있습니다. 부속된 러너 스크립트 run.sh (Windows 환경에서는 run.ps1 또는 run.cmd)를 호출합니다.
기본적인 실행
# 스킬 폴더 내의 스크립트에 프롬프트를 전달하여 실행
skills/multi-llm-reflection/scripts/run.sh "신기능 『팀 간 태스크 공유 대시보드』의 RFC를 작성해 주세요. 배경, 목적, 범위 외 사항, 기술 선정 비교, 이행 계획을 포함해 주세요."
※ 코드 생성 프롬프트를 전달하는 것 자체는 가능하지만, 출력물은 컴파일되거나 실행되지 않는 텍스트입니다. 코드로 사용할 경우에는 어디까지나 설계 방침이나 로직에 대한 리뷰 코멘트의 초안으로 취급해 주세요.
편리한 옵션
- 상세 로그 표시 (
--verbose): 각 단계(생성, 비평, 퇴고)의 로우(raw) 아웃풋이나 중간 과정을 상세히 확인할 수 있습니다.skills/multi-llm-reflection/scripts/run.sh --verbose "태스크 내용" - 구조화된 데이터 취득 (
--json): 최종 결과물을 JSON 형식으로 출력합니다.skills/multi-llm-reflection/scripts/run.sh --json "태스크 내용"
6. 실전을 위한 베스트 프랙티스 & 고급 커스터마이징
로컬 환경이나 실제 업무의 팀 개발에서 본 시스템을 운용할 때, 알아두면 유익한 조언 및 커스터마이징 방법입니다.
① CI/CD (GitHub Actions 등) 또는 헤드리스(Headless) 환경에서 구동하는 방법
기본적으로 본 시스템은 로컬에 설치된 CLI(agy, claude, codex...
)의 로그인 상태(구독)를 통해 통신을 수행합니다. 하지만, 인터랙티브(Interactive)한 로그인이 불가능한 CI/CD 환경이나 컨테이너 내부에서는, API 키를 전달함으로써 직접 API를 통한 통신으로 폴백(Fallback)할 수 있습니다.
다음 환경 변수를 정의하여 실행하면, CLI 로그인 단계를 건너뛰고 직접 API 통신이 가능합니다.
# 필요에 따라 환경 변수를 설정 (또는 .env 파일에 정의)
export GEMINI_API_KEY="your-gemini-key"
export ANTHROPIC_API_KEY="your-anthropic-key"
...
② 역할 프로바이더와 모델의 자유로운 커스터마이징
"Gemini로 만들고, Claude로 비평하며, GPT로 수정한다"는 구성은 기본 설정일 뿐입니다. 본 시스템에서는 환경 변수를 사용하여 역할별 프로바이더(Provider)나 모델을 자유자재로 교체할 수 있습니다.
REFLECTION_GENERATOR_PROVIDER: 생성 담당 프로바이더 (gemini | anthropic | openai | mock)
REFLECTION_GENERATOR_MODEL: 사용하는 모델 ID
예를 들어, "첫 생성은 비용이 저렴한 Gemini 3.5 Flash로 수행하고, 비평과 퇴고는 고성능인 Claude 3.5 Sonnet이나 GPT-4o로 엄격하게 수행한다"와 같이, 속도와 비용, 품질의 균형을 최적화한 운용이 가능합니다.
# Generator를 Gemini의 Flash 모델로 변경하는 예시
export REFLECTION_GENERATOR_PROVIDER="gemini"
export REFLECTION_GENERATOR_MODEL="gemini-3.5-flash"
③ 안전하게 정지하는 「Degraded Mode (품질 저하 모드)」의 활용
추론 모델이 너무 오래 생각하여 셸 도구(Shell Tool) 등의 제한 시간(통상 10분/600초)을 초과해 프로세스가 갑자기 강제 종료(Killed)되는 것을 방지하기 위해, 스크립트에는 MULTILLM_TOTAL_DEADLINE (기본값 540초)이 설정되어 있습니다.
시간 제한이 다가오면 시스템은 자동으로 **「Degraded Mode (부분 출력 모드)」**로 이행합니다. 이는 남은 처리 단계를 건너뛰거나 간이 출력으로 낮추고, 그때까지 축적된 중간 결과물을 안전하게 파일로 출력한 뒤 프로그램을 종료하는 기능입니다.
실행 시간이 길어지기 쉬운 복잡한 태스크에서도, 그때까지의 작업이 모두 무효화되는 리스크를 방지하기 위한 전문적인 에러 핸들링(Error Handling) 기구입니다.
8. 요약
multi-llm-reflection 스킬은 생성·비평·퇴고라는 개선 루프를 서로 다른 벤더의 모델에 분담시킴으로써, 단일 모델의 셀프 리뷰(Self-review)에서는 놓치기 쉬운 논리적 모순이나 엣지 케이스(Edge Case)를 포착하기 쉽게 만드는 텍스트 생성 파이프라인입니다. 다만, 이는 끝없이 돌아가는 자동 개선 장치가 아니라, 한 바퀴만 돌고 멈추는 개선 루프입니다. 실행 검증을 수행하는 것도 아니므로, 최종 결과물의 리뷰는 여전히 인간의 역할이라는 점을 잊지 마십시오.
npx skills add buddypia/agent-skills를 실행하여, 가지고 있는 agy, claude, codex CLI를 조합하는 것만으로도 기술 문서나 설계 문서의 크로스 모델 리뷰를 로컬 환경이나 CI/CD 환경에 즉시 구축할 수 있으니 꼭 시도해 보시기 바랍니다!
Discussion

AI 자동 생성 콘텐츠
본 콘텐츠는 Zenn AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기