여러 AI 모델을 함께 쓰기 시작하면 자연스럽게 “어떤 모델이 제일 좋은가”라는 질문으로 간다. 그리고 그 다음에는 요청마다 가장 적합한 모델을 자동으로 고르는 selector나 gateway를 떠올리기 쉽다.
그 방식은 많은 서비스에서 합리적이다. 비용, latency, provider 장애, 품질 편차를 줄여야 한다면 여러 모델을 하나의 안정적인 inference service처럼 다루는 것이 유리하다.
하지만 개발 과정에서 여러 AI를 쓰면서 내가 더 자주 마주친 문제는 조금 달랐다.
어떤 모델이 가장 좋은가?
보다 중요한 질문이 있었다.
서로 다른 모델의 해석 차이를
어떻게 실제 설계 판단에 사용할 것인가?
일반적인 AI Gateway가 푸는 문제
멀티 모델 gateway는 대체로 다음과 같은 목표를 가진다.
REQUEST
↓
AI GATEWAY
├─ model routing
├─ cost optimization
├─ latency optimization
├─ fallback
├─ provider abstraction
└─ quality selection
↓
STABLE RESPONSE
핵심은 여러 provider와 model의 차이를 사용자에게 최대한 숨기면서 더 좋은 평균 서비스 품질을 만드는 것이다.
이 관점에서는 모델 간 variance가 줄어드는 것이 장점이다. 같은 종류의 요청이 들어왔을 때 결과가 일정할수록 운영하기 편하다.
개발 탐색에서는 variance가 자산이 되기도 한다
설계 초기에는 반대 상황이 생긴다.
하나의 모델이 어떤 구조를 너무 자연스럽게 받아들이면, 다른 모델은 전혀 다른 경계에서 문제를 발견할 수 있다. 한 모델이 구현 편의성을 강조하고, 다른 모델이 장기적인 책임 분리를 강조할 수도 있다.
이때 너무 빨리 하나의 답으로 normalize하면 중요한 반론이 사라진다.
내가 유용하다고 느낀 흐름은 이런 형태였다.
PROBLEM / IDEA
↓
independent perspectives
↓
divergence
↓
critique / contradiction
↓
synthesis
↓
human decision
↓
implementation
모델 간 불일치는 실패가 아니다. 오히려 “왜 둘이 다른 결론을 냈는가”를 확인하는 순간 설계에서 암묵적으로 가정했던 부분이 드러난다.
그래서 역할을 모델 이름보다 먼저 본다
이 방식에서는 “GPT가 무엇을 잘한다”, “Claude가 무엇을 잘한다” 같은 고정된 model ranking보다 작업 역할이 중요해진다.
예를 들어 같은 코드 변경을 두 모델에게 독립적으로 리뷰하게 할 수 있다. 또는 한쪽은 구현안을 만들고 다른 쪽은 contract violation만 찾게 할 수도 있다.
중요한 정보는 다음에 가깝다.
role
scope
context
evidence
authority
mutation
provenance
즉 “어떤 모델이 답했는가”보다 “이 결과가 어떤 역할에서 만들어졌고, 어디까지 권한을 갖는가”가 실제 개발에서는 더 중요할 수 있다.
생각하는 단계와 실행하는 단계의 통제 강도는 달라야 한다
여기서 한 가지 문제가 생긴다. AI가 예상 밖의 아이디어를 내는 것을 원하면서 동시에 repository나 runtime을 멋대로 바꾸지 않게 해야 한다.
둘 다 같은 강도의 규칙으로 해결하려고 하면 탐색 단계가 지나치게 경직되거나, 반대로 실행 단계가 너무 느슨해진다.
그래서 통제를 비대칭적으로 보는 편이 낫다고 생각했다.
EXPLORE
loose / independent / divergent
↓
CHALLENGE
critique / contradiction preservation
↓
CONVERGE
contracts / constraints / selected decisions
↓
EXECUTE
strict scope / authority / verification
아이디어를 찾을 때는 자유도가 높아도 된다. 하지만 실제 파일을 바꾸고 배포하고 데이터를 만지는 단계로 갈수록 scope와 authority가 명확해야 한다.
간단히 말하면:
생각은 넓게, mutation은 좁게.
AI 합의는 결정권이 아니다
멀티 AI를 쓰다 보면 여러 모델이 같은 의견을 냈다는 사실 자체가 강하게 느껴질 때가 있다.
독립적인 모델이 비슷한 결론에 도달했다면 분명 참고할 가치가 있다. 하지만 그것을 자동 승인으로 바꾸면 또 다른 문제가 생긴다.
AI CONSENSUS
!= HUMAN DECISION
여러 모델의 일치는 evidence의 강도를 높일 수 있지만, 어떤 trade-off를 받아들일지는 결국 제품과 시스템을 책임지는 사람이 결정해야 한다.
특히 architecture나 dependency 선택처럼 한번 들어가면 유지보수 비용을 만드는 결정은 다수결로 자동 처리하기 어렵다.
좋은 orchestration은 모든 모델을 똑같게 만들지 않는다
모델 출력 형식을 강하게 통일하면 downstream 처리가 쉬워진다. 하지만 모든 단계에서 그것이 최선은 아니다.
초기 설계에서는 모델 고유의 해석 방식이 보이는 편이 오히려 유용하다. structured output을 너무 이르게 강제하면 무엇을 구조화해야 하는지 자체가 아직 불명확한데도 틀부터 고정하게 된다.
그래서 다음과 같은 단계적 접근이 더 잘 맞았다.
DIVERGE
→ 자유로운 관점
CHALLENGE
→ 서로의 약점 확인
SYNTHESIZE
→ 공통 구조와 차이 정리
DECIDE
→ Human 선택
EXECUTE
→ 명확한 계약 아래 변경
VERIFY
→ 실제 evidence로 확인
이 구조에서는 AI의 창발성과 실행 안전성을 같은 메커니즘으로 해결하려 하지 않는다.
언제 Gateway가 필요한가
그렇다고 model gateway가 필요 없다는 뜻은 아니다.
서비스 규모가 커져 다음 문제가 실제로 중요해지면 별도의 inference layer가 필요해질 수 있다.
- provider outage 대응
- latency 기반 routing
- API 비용 최적화
- 대규모 request 처리
- unified billing
- provider abstraction
- model fleet 운영
다만 이런 문제와 “여러 AI가 개발 과정에서 어떻게 서로 다른 역할을 수행할 것인가”는 별개의 축이다.
Inference orchestration
!=
Cognitive / work orchestration
하나는 AI 호출을 운영하는 문제이고, 다른 하나는 AI가 참여하는 일을 운영하는 문제다.
결국 최적화 대상이 다르다
AI Gateway의 최적화 대상은 보통 하나의 요청을 얼마나 안정적이고 효율적으로 처리하느냐다.
내가 탐색하고 있는 방식의 최적화 대상은 조금 다르다.
PRESERVE USEFUL DIVERGENCE
↓
MAKE CONTRADICTION VISIBLE
↓
CONVERGE DELIBERATELY
↓
BOUND REAL EXECUTION
개발 초기의 좋은 아이디어는 때로 모델 간 불일치에서 나온다. 반대로 실제 mutation은 불일치가 정리되지 않은 상태에서 시작하면 위험해진다.
그래서 “최고의 모델을 자동으로 선택하는 시스템”보다 먼저 필요했던 것은 다른 관점을 보존하고, 그 차이를 인간이 판단 가능한 형태로 만들고, 결정 이후의 실행을 좁게 제한하는 구조였다.
이 방식이 모든 팀에 맞는 답은 아니다. 하지만 여러 AI를 단순한 답변 생성기가 아니라 실제 engineering workflow의 참여자로 사용할수록, model routing보다 role과 authority의 문제가 더 빨리 커진다는 것은 반복해서 확인할 수 있었다.