카르파티의 LLM Council, 주말 ‘바이브 코드’가 그린 기업 AI 오케스트레이션

개요: 주말 해킹이 드러낸 기업 AI의 빈층

테슬라 전 AI 디렉터이자 OpenAI 공동 창립 멤버인 안드레이 카르파티는 주말에 ‘바이브 코드 프로젝트’로 불리는 가벼운 실험을 진행해 깃허브에 LLM Council을 공개했다. 겉으로는 장난처럼 보이지만, 수백 줄의 파이썬·자바스크립트로 기업 애플리케이션과 다양한 AI 모델 사이를 중재하는 오케스트레이션 미들웨어의 참조 아키텍처를 거칠게 스케치한다. 그는 “이 프로젝트는 지원하지 않는다”는 단서를 달았지만, 기술 의사결정자에게는 2026년을 겨냥한 플랫폼 투자에서 빌드 vs 바이 논쟁의 본질을 선명히 보여준다.

위원회형 읽기 보조에서 오케스트레이션 미들웨어로

카르파티는 한 권의 책을 여러 인공지능이 각자 답하고 비평한 뒤, ‘의장’ 모델이 최종 답을 합성하는 위원회 모델로 읽고자 했다. LLM Council은 바로 그 흐름을 구현하며, 단순한 취미 도구를 넘어 기업 AI 오케스트레이션의 빈층을 드러낸다.

동작 방식: 토론–상호평가–종합의 3단계

1) 병렬 응답: 프런티어 모델 패널

사용자가 질문을 입력하면 시스템은 OpenAI GPT-5.1, Google Gemini 3.0 Pro, Anthropic Claude Sonnet 4.5, xAI Grok 4 등 프런티어 모델 패널로 질의를 동시에 보낸다. 각 모델은 1차 답변을 병렬 생성한다.

2) 동료평가: 생성자에서 비평가로

이후 각 모델은 상대의 익명 응답을 받아 정확성과 통찰을 기준으로 평가한다. 표준 챗봇에서는 드문 품질관리 층이 강제되면서 AI가 비평가 역할을 수행한다.

3) 의장 모델의 최종 합성

지정된 ‘Chairman LLM’(기본값은 Google Gemini 3)이 원 질문, 개별 답변, 동료평가 순위를 입력으로 받아 단일 권위 답을 합성한다. 흥미롭게도 카르파티는 모델들이 자신의 답보다 타 모델의 답을 더 낫다고 선택하는 경우가 적지 않았다고 전했다.

얇은 스택과 교체 가능한 모델

경량 아키텍처의 구성요소

백엔드는 현대적 파이썬 프레임워크인 FastAPI, 프런트엔드는 Vite로 빌드한 표준 React를 사용한다. 데이터 저장은 로컬 디스크의 단순 JSON 파일로 처리해 데이터베이스를 생략한다. 이 ‘얇은’ 설계는 오케스트레이션 로직 자체의 단순함을 부각한다.

OpenRouter 중심의 모델 레이어 상품화

핵심은 다양한 모델 제공사의 차이를 평준화하는 API 브로커 OpenRouter다. 이를 통해 OpenAI·Google·Anthropic 각각의 통합 코드를 따로 쓰지 않고도 라우팅을 단일화한다. 백엔드의 COUNCIL_MODELS 목록 한 줄만 바꾸면 차세대 모델을 즉시 교체·추가할 수 있어 공급업체 종속을 완화한다.

프로토타입에서 프로덕션까지: 빠진 운영 래퍼

인증·권한·거버넌스의 공백

LLM Council의 코어 로직은 우아하지만, 엔터프라이즈 운영에 필수적인 ‘지루한’ 인프라가 비어 있다. 로그인과 역할 기반 접근 제어가 없고, 사내 데이터를 동시에 4개 외부 모델로 보내는 구조는 즉각적 컴플라이언스 이슈를 부른다. 개인정보(PII) 마스킹, 네트워크 외부 반출 전의 자동 편집, 누가 무엇을 질의했는지 남기는 감사 로그도 없다.

가용성·복원력·관측성의 결핍

OpenRouter 가용성과 모델 응답성을 낙관적으로 가정해 회로 차단기, 폴백, 재시도 같은 탄력성 패턴이 없다. 상용 인프라 벤더(예: LangChain, AWS Bedrock, 다양한 AI 게이트웨이)는 바로 이 ‘경화(hardening)’—보안, 관측 가능성, 컴플라이언스 래퍼—를 상품으로 제공한다.

철학: ‘코드는 소모품’과 라이브러리의 종말

바이브 코드와 프롬프트 가능한 비계

카르파티는 개발 과정을 ‘99% 바이브 코딩’이라 묘사하며, 사람이 줄 단위로 쓰기보다 AI 비서에 의존했다고 밝혔다. 그는 “이제 코드는 소모품이며, 라이브러리는 끝났다. 원하는 대로 LLM에 바꾸라”는 입장이다. 전통적으로 장기간 유지하던 내부 라이브러리·추상화 대신, 필요 시점에 AI로 재작성하는 ‘프롬프트 가능한 비계(scaffolding)’가 새로운 전략이 될 수 있음을 시사한다. 이는 내부 워크플로 도구를 비싼 패키지로 살지, 주말에 가볍게 ‘바이브 코드’로 맞춤 제작할지라는 딜레마로 이어진다.

LLM이 LLM을 심사할 때: 기계 vs 인간의 간극

장황함 보상 편향의 위험

카르파티는 패널이 GPT-5.1을 가장 통찰력 있다고 평가하는 경향을 보였지만, 본인은 더 응축되고 정제된 Gemini 출력을 선호했다고 밝혔다. 이는 LLM 심사관 체계가 장황함, 특정 형식, 과도한 확신을 보상할 가능성을 시사한다. 고객 챗봇의 품질 평가를 LLM에만 맡기면 지표는 좋아지지만 사용자는 불만을 느낄 수 있다.

2026년 스택을 준비하는 플랫폼 팀을 위한 교훈

라우팅보다 데이터 거버넌스가 어렵다

LLM Council은 취미 프로젝트이자 업계의 로르샤흐 테스트다. 일부 벤더에겐 위협이지만, 기술 리더에게는 오케스트레이션 레이어를 탈신비화한 참조 아키텍처다. 다중 모델 전략은 기술적으로 손에 닿는 곳에 있다. 관건은 거버넌스 층을 직접 구축할지, 상용 래퍼로 ‘바이브 코드’를 엔터프라이즈급으로 감쌀지의 선택이다.

실행 포인트

단순 라우팅·집계 로직은 사내에서도 빠르게 구현 가능하다. 반면 인증, PII 차단, 감사·관측, 복원력은 조기에 요구사항으로 못 박아야 한다. 또한 LLM-as-a-Judge 지표를 인간 평가와 교차검증해 편향을 교정하라. 마지막으로 LLM Council의 최소 구현을 읽고, 자사 맥락에서 필요한 ‘경화’ 목록을 우선순위화하라.