Claude가 쓰고, Gemini가 리뷰하고, ChatGPT가 말상대가 되어준다

단일 벤더 AI는 서류상으로는 더 쉬워 보이지만 실제로는 취약함을 낳는다. RakuAI는 멀티 벤더 에이전트 루프로 만들어지며, 어떤 벤더의 모델이든 그것을 구동할 수 있도록 만들어진다. 개발 프로세스는 제품 논제를 그대로 반영한다.

토요일 아침, 커피, 그리고 다시 바뀌기 전의 워크플로. 자율 코딩 에이전트와 함께 엔진을 만들고 있다고 말하면 첫 질문은 “어떤 에이전트인가”다. 정직한 답은 “여러 개이고, 서로 다른 역할을 맡고 있으며, 그 역할 분담이 중요하다”이다. 이 글은 그 더 긴 답이다.

지금 이 개발 워크플로는 루프의 서로 다른 부분을 맡는 적어도 세 개의 서로 다른 AI 벤더를 포함한다. 이유는 충성심이나 까다로움이 아니다. 각 모델이 서로 다른 형태의 작업에 실제로 더 뛰어나고, 하나의 모델에게 모든 것을 시키려는 시도는 측정 가능할 정도로 더 나쁜 코드를 만들어내기 때문이다.

오늘의 역할들

Claude는 대부분의 런타임 코드를 작성한다. 큰 코드베이스에 걸친 긴 컨텍스트 추론, 편집 전 계획 수립, 하나의 머릿속에 많은 상태를 담아두는 능력. 이것이 내가 실질적인 서브시스템 작업을 위해 이슈 큐에서 돌리는 모델이다. 이슈에 “OpenXR 컴포지션 레이어 매니저와 액션 스페이스를 구현하라”고 적혀 있으면, PR을 착지시키는 것은 Claude다.

Gemini는 대부분의 PR을 리뷰한다. 다른 학습, 다른 사각지대. Claude가 PR을 착지시키면 Gemini가 그 diff를 읽고 반박한다. Gemini가 드러내는 코멘트의 종류는 내가 손으로 드러낼 종류와 다르다. 일부는 잡음이다. 일부는 유용하다. 신호 대 잡음비가 충분히 좋아서 나는 Gemini를 모든 diff에 대한 첫 번째 리뷰 패스로 신뢰한다.

ChatGPT는 내가 말상대로 삼는 곳이다. 아키텍처 결정에서 막혀서 어느 쪽으로 가야 할지 아직 모를 때, 나는 ChatGPT에게 소리 내어 생각을 던진다. 이 역할에서 모델은 코드를 작성하지 않는다. 내 가정을 밀어붙이고, 세 가지 대안적 프레이밍을 제안하고, 내가 그것과 논쟁하게 해준다. 내게 있다면 시니어 동료가 맡았을 역할이다. 지금 나에게는 그런 사람이 없다. ChatGPT가 그 시뮬레이션이다.

Copilot은 에디터 안에 있다. 이것은 자동완성 역할이다. 내가 손으로 코드를 작성할 때(사람들이 생각하는 것보다 드물지만, 그런 일이 있다), Copilot은 내가 IDE에서 보는 제안을 하는 모델이다. 로컬 컨텍스트, 다음 네 줄 작업에 강하다.

그것이 이 워크플로다. 네 개의 모델, 네 가지 역할. 각각이 다른 것들보다 자신의 역할에서 더 뛰어나다.

왜 멀티 벤더가 중요한가

세 가지 이유가 있다.

능력의 한계는 벤더마다 다르다. 만약 내가 모든 역할에 하나의 모델을 돌린다면, 그 모델의 모든 약점이 개발 프로세스의 약점으로 나타날 것이다. Claude는 작성에 탁월하다. 자신이 작성한 것에서 버그를 찾는 데는 덜 탁월하다. Gemini는 버그를 찾는 데 탁월하지만, 감독 없이 리팩터링을 계획하도록 맡길 모델은 아니다. ChatGPT는 열려 있는 아키텍처 질문에 대해 잘 생각하지만, 실제 서브시스템에서 그 코드가 출시되기를 원하지는 않는다. 각각이 하나의 자리에 가장 알맞은 도구다.

리뷰의 독립성은 구조적이다. 내가 정착한 가장 중요한 단 하나의 규칙은, PR을 작성한 모델이 그것을 리뷰하는 모델이 될 수 없다는 것이다. 자기 자신을 리뷰하는 것은 리뷰가 아니다. 다른 벤더의 모델이 첫 번째 리뷰 패스를 하도록 하면 아키텍처, 학습 데이터, 실패 양상의 독립성이 생긴다. Gemini가 Claude의 코드에서 잡아내는 버그들은 그렇지 않았다면 착지되었을 실제 버그들이다.

단일 벤더 종속이 없다. 이 엔진은 (지난달 XRAssistantService 작업에서 다뤘던) 어떤 클라우드 LLM의 지시든 받도록 만들어지고 있다. 그 엔진을 만드는 개발 워크플로도 그 태도와 맞아야 한다. 나는 이 런타임의 엔지니어링이 앞으로 5년 동안 하나의 벤더가 계속 경쟁력을 유지할 것에 의존하기를 원치 않는다. 그중 어느 벤더도 그러지 못할 것이다. 지금 잘하는 벤더들은 나중에는 다른 방식으로 잘할 것이다. 개발 레이어에서 멀티 벤더 워크플로를 돌리면 엔지니어링이 이식 가능하게 유지된다.

정직하게 말하는 비용들

몇 가지가 있다.

조율 오버헤드는 실재한다. 작업 도중 벤더를 바꾸는 것은 인지적 오버헤드를 수반한다. 해결책은 각 작업을 하나의 벤더 레인 안에 두고, 인계는 작업 사이에서 일어나게 하는 것이지 작업 안에서 일어나게 하는 것이 아니다.

청구서가 쌓인다. 네 개의 모델 구독을 돌리는 것은 공짜가 아니다. 그 비용은 의미 있는 수준이고, 지금은 내가 개인적으로 부담하고 있다. 그 수익은 출시된 서브시스템으로 측정 가능하므로, 지금 단계에서는 셈이 맞는다. 항상 그렇지는 않을 것이다.

벤더 간 품질 표류는 실재하는 문제다. Gemini가 Claude가 해오던 종류의 작업을 더 잘하게 되면, 옳은 답은 그 작업을 Gemini로 옮기는 것이다. 틀린 답은 워크플로 문서가 그렇게 적혀 있다는 이유로 예전 방식대로 계속하는 것이다. 워크플로 문서는 모델 지형이 그 아래에서 계속 움직이기 때문에 몇 주마다 수정되어야 한다.

벤더들은 서로에 대해 알지 못한다. Claude가 Gemini에게 리뷰될 코드 조각을 작성할 때, Claude는 그것을 알지 못한다. ChatGPT가 나와 아키텍처 결정을 두고 논쟁할 때, 나중에 Claude가 하는 구현은 그 논쟁을 보지 못한다. 벤더들 사이의 통합은 내 머릿속에 있다. 통합이 존재하기에는 취약한 곳이며, 만약 내가 다른 사람들이 이 워크플로를 운영하도록 돕는 인프라를 만들고 있다면 고치고 싶은 것들 중 하나다.

런타임 쪽은 어떤가?

이 부분이 개발 워크플로 이야기와 엔진 이야기가 수렴하는 지점이다.

2주 전 런타임에 들어온 XRAssistantService는 설계상 모델 불가지론적이다. 그 이유는 이 개발 워크플로가 멀티 벤더인 이유와 정확히 같다. 이 인터페이스는 이 랩들의 모델 중 어느 것이든 런타임을 통해 AR 경험을 구동할 수 있도록 만들어졌다. 특정 작업에서 가장 뛰어난 모델을 가진 랩이 특정 경험에서 그 작업의 의도를 제공하게 된다.

이것이 더 큰 베팅이다. “이 제품은 이 벤더의 이 모델 위에 만들어졌다”는 시대는 짧다. 우리가 들어서고 있는 시대는 “이 제품은 모델 형태의 능력들을 중심으로 만들어지며, 어떤 시점에 어떤 특정 모델이 어떤 능력 슬롯을 채우는지는 설정 선택이다”는 시대다. 엔진은 그것을 위해 준비되어 있어야 한다. 그 엔진을 만드는 개발 워크플로는 그것을 반영해야 한다.

빌더와 랩들이 이 글에서 가져갔으면 하는 것

당신이 코딩 에이전트 벤더이고 이 글을 읽고 있다면, 내가 최적화하고자 하는 지표는 “이 에이전트의 PR이 경쟁 벤더 에이전트의 리뷰에서 얼마나 자주 살아남는가”이다. 자기 일관성은 기준이 아니다. 벤더 간 교차 리뷰 생존이 기준이다. 그 지표에서 잘하는 에이전트들이 진지한 작업에 쓰이게 될 에이전트들이다.

진지한 코드베이스를 위해 AI 지원 워크플로를 채택하는 것을 고민하는 개발자라면, 하나의 모델을 골라서 거기서 멈추지 마라. 작성할 모델 하나를 고르라. 리뷰할 다른 모델을 고르라. 열려 있는 아키텍처 결정의 말상대로 세 번째 모델을 쓰라. 비용 프리미엄은 실재하고 품질 차이는 더 크다.

당신이 자사 개발 조직 안의 AI를 고민하는 엔터프라이즈 리더라면, 멀티 벤더 패턴이 확장될 패턴이다. 단일 벤더 채택은 서류상으로는 더 쉬워 보인다. 실제로는 기술적으로도 전략적으로도 취약함을 낳는다.

조용한 토요일. 엔진은 서른다섯 개 커밋짜리 주말을 얻었다. 그 커밋들 대부분은 6개월 뒤에는 보이지 않을 것이다. 그것들을 만들어낸 워크플로는 그렇지 않을 것이다.