LLM 중계기 개발기 6부 · 27편 / 전체 33편

2026년 10월 2일 기준

이 글에는 제휴 링크가 없고 OpenAI·앤트로픽과 아무 관계가 없습니다. 제가 직접 만든 중계기와 코드 리뷰 대결 도구의 개발 기록을 바탕으로 썼습니다. 삽화는 GPT 이미지 생성, 도식은 직접 제작했습니다.

AI끼리 코드리뷰 대결 — 여러 심사위원의 교차 채점 (LLM 중계기 개발기)

노래 경연 프로그램을 떠올려 볼게요. 무대 앞에는 심사위원이 여러 명 앉아 있어요. 한 사람은 음정을, 한 사람은 박자를, 또 한 사람은 무대 매너를 특히 눈여겨보죠. 노래가 끝나면 각자 따로 점수를 적고, 그다음에 서로의 채점표를 맞춰 봅니다.

세 사람이 모두 “2절 고음이 흔들렸다”고 적었다면 그건 거의 확실해요. 한 사람만 적었다면 녹화 화면을 다시 돌려 볼 일이고요. 심사위원이 한 명뿐이라면, 그 사람이 그날 놓친 것은 아무도 모른 채 지나갑니다.

코드 검토도 비슷해요. 프로그램을 고치면, 고친 부분을 합치기 전에 다른 사람이 읽어 보고 문제를 찾는데 이걸 코드 리뷰라고 해요. 요즘은 이 일을 AI에게 많이 맡기죠. 그런데 같은 결함도 어떤 AI는 찾고 어떤 AI는 놓쳐요. 같은 AI라도 물을 때마다 답이 조금씩 달라질 수 있고요. 그렇다면 굳이 AI 하나를 골라 믿을 필요가 있을까요? 심사위원처럼 여럿을 앉히면 됩니다.

이 글은 LLM 중계기 개발기의 27편입니다. 지난 26편 「한 질문, 여러 AI의 답」에서는 질문 하나를 여러 AI에게 동시에 보내는 병렬 채팅과, ‘다 같이 아니면 아무도’인 묶음 창구 이야기를 했어요. 오늘의 주인공은 그 묶음 창구의 원래 손님인 코드 리뷰 대결 도구예요. 중계기와 나란히 만들어 온 도구로, 여러 AI를 심사위원처럼 앉혀 코드를 교차로 채점하게 합니다.

결론 요약

• 문제 — AI 리뷰어 하나는 놓칩니다. 같은 결함도 어떤 AI는 찾고 어떤 AI는 지나쳐요
• 방법 — 코드 리뷰 대결 도구는 바뀐 코드를 조각으로 나누고 일곱 가지 관점을 여러 AI에 나눠 맡긴 뒤, 같은 지적을 몇이 찾았는지와 다른 AI가 동의하는지로 믿을 만한 정도를 매겨 한 장의 보고서로 합쳐요
• 중계기의 몫 — 여러 AI를 한 창구로 부르게 하고, 묶음 창구로 같은 출발선에 세우고, 스펙 카드로 AI마다 조각 크기를 정하게 했어요

🥊 1. 보스, 파이터, 장비 — 게임처럼 보이는 코드 리뷰

먼저 낱말 두 개만 짚고 갈게요.

• 변경분(diff) — 코드에서 바뀐 줄만 모은 것이에요. 지운 줄과 새로 쓴 줄이 나란히 적혀요
• PR(pull request) — “제가 바꾼 이 부분을 합쳐 주세요”라는 요청이에요. 코드 리뷰는 보통 이 요청 하나를 단위로 해요

코드 리뷰 대결 도구는 이 검토 과정을 게임 화면처럼 보여 줘요.

• 보스 = 검토할 PR — 바뀐 파일과 줄 수가 보스의 체력이에요. 쓸모 있는 지적이 확정될 때마다 보스에게 타격이 들어가요
• 파이터 = AI 모델 — 예선을 통과한 AI만 무대에 올라요. 조각 하나를 검토할 때마다 공격 동작을 해서, 전투 장면이 곧 진행 상황이에요
• 장비 = 리뷰 관점 — 관점마다 작은 요정이 있어 그 관점을 맡은 파이터 곁에 떠 있어요. 관점이 다른 AI에게 넘어가면 요정이 옮겨 가는 ‘장비 교체’ 장면이 나오고요

장식처럼 보이지만, 이 화면은 도구가 실제로 일을 나누는 단위를 그대로 무대에 올린 거예요. 누가 어떤 관점으로 어디까지 봤는지가 한눈에 읽힙니다.

대결에서 파티로

이름은 ‘대결’이지만 중간에 방향이 한 번 바뀌었어요. 처음 설계는 말 그대로 AI끼리 경쟁해서 누가 더 잘 찾는지 승부를 가리는 구조였어요. 그러다 7월 19일의 설계 기록에 생각이 이렇게 바뀌었다고 적혔어요. 리뷰의 기준은 관점이어야 하고, AI의 개수와 성능은 관점을 완성하는 수단이다. AI가 하나뿐이어도 관점이 먼저다.

그래서 주인공이 AI에서 관점으로 바뀌었어요. 관점마다 자기 작업 줄(레인)이 생겼고, AI는 그 줄에서 일감을 가져가 처리하는 일꾼이 됐어요. 승패보다 관점이 하나도 빠지지 않았는지가 중요해진 거예요. 대결의 재미는 마지막에 가장 좋은 지적을 낸 ‘관점 + AI’ 조합을 뽑는 데 남겨 뒀어요.

🎯 2. 심사위원마다 다른 채점표 — 일곱 가지 관점

AI에게 “이 코드 검토해 줘”라고만 하면 AI는 저마다 눈에 띄는 것부터 봐요. 그래서 이 도구는 AI마다 어떤 눈으로 볼지를 정해 줘요. 기본 관점은 일곱 가지이고, 번호는 실제 사용자가 겪을 위험이 큰 순서예요.

① 사용자 치명 문제 — 데이터가 사라지거나, 화면에 틀린 값이 뜨거나, 기능이 아예 안 되는 것 ② 실행 중 멈춤 — 비어 있는 값을 건드리거나 예외 처리를 빠뜨려서 프로그램이 그 자리에서 죽는 길 ③ 호환성 — 다른 곳에서 쓰던 이름이나 설정 이름을 바꿔서 기존에 부르던 쪽이 깨지는지. 실제로 부르는 곳을 근거로만 지적해요 ④ 의도 정합 — 이 변경이 하겠다고 한 일을 정말 해냈는지, 엉뚱한 변경이 섞이거나 빠진 건 없는지. 증거가 없으면 지적하지 않아요 ⑤ 옵션 분기 — 설정이나 스위치 조합에 따라 다르게 움직이는 곳에서 빠뜨린 경우 ⑥ 보안 — 들어오는 값을 검사하는지, 권한을 확인하는지, 정보가 새어 나가지 않는지 ⑦ 동시성·자원 — 여러 일이 한꺼번에 돌 때 순서가 꼬이거나, 기다림이 끝나지 않거나, 빌려 쓴 자원을 돌려주지 않는 것

여기에 여덟째 자리로 자유 시점이 있어요. 일부러 아무 관점도 정해 주지 않고 자유롭게 보게 하는 자리예요. 실험해 보고 나서 맨 뒤 순서로 더한 자리인데, 지시를 더 얹을수록 좋아지는 게 아니더라는 실험 이야기는 다음 편에서 이어 갈게요.

경연으로 치면 심사위원마다 맡은 채점 항목이 있는 셈이에요. 한 사람이 음정·박자·가사·무대를 혼자 다 보려 하면, 어느 하나는 놓치기 쉬우니까요. AI 수에 따라 나누는 방식도 정해져 있어요.

• AI가 관점보다 적으면 — 앞 번호 관점부터 배정하고, 한 AI가 여러 관점을 겸해요
• AI가 남으면 — 남는 AI를 앞 번호 관점의 두 번째 일꾼으로 붙여요. 같은 관점을 서로 다른 두 AI가 따로 보니, 그 자체로 교차 확인이 돼요
• AI가 중간에 빠지면 — 로그인이 풀리거나 한도를 다 써서 한 AI가 빠지면, 그 AI가 맡던 관점은 남은 AI들에게 처리 여력에 맞춰 나눠 넘어가요. 관점이 비지 않게요

무대에 오르기 전, 예선

아무 AI나 심사석에 앉히지는 않아요. 본 검토 전에 짧은 예선을 치러요. 문제는 몇 줄짜리 연습용 변경분이에요. “손님 이름이 없으면 ‘손님, 안녕하세요’라고 인사하라”는 안전장치를 지우고, 곧바로 이름을 다듬어 쓰게 바꾼 코드죠. 이름 없는 손님이 오면 프로그램이 그 자리에서 멈춰요.

AI는 두 가지를 해내야 통과해요.

• 약속한 답안 양식(JSON — 프로그램이 읽을 수 있게 정해 둔 형식)으로 답하기
• 이 심어 둔 결함을 위치와 함께 정확히 짚기

양식을 어기거나 결함을 못 찾으면 그 판에는 나오지 못해요. 심사석에 앉기 전에, 음 이탈 하나가 섞인 짧은 녹음을 들려주고 맞히는지 보는 셈이에요. 예선에서 잰 응답 속도와 읽을 수 있는 분량은 관점을 나눠 줄 때도 참고해요.

🧩 3. 조각으로 나누고, 조각 크기는 스펙 카드가 정한다

바뀐 코드가 크면 AI가 한 번에 다 읽지 못해요. 그래서 도구는 변경분을 조각으로 나눠요. 파일 경계를 지키고, 한 파일이 너무 크면 바뀐 덩어리 단위로 자릅니다.

조각을 얼마나 크게 자를지는 AI마다 달라요. 여기서 9편의 스펙 카드가 쓰여요. 사실 9편에서 스펙 카드가 생긴 계기로 소개한 ‘긴 글을 AI에게 읽히는 도구’가 바로 이 코드 리뷰 대결 도구였어요. 도구는 7월 18일에 카드를 읽을 준비를 먼저 해 뒀고, 중계기는 7월 20일에 카드를 내놓았어요. 카드가 없던 때는 AI마다 얼마나 읽는지 몰라서 모두에게 잘게 썰어 하나씩 보낼 수밖에 없었죠.

카드를 읽게 된 뒤로는 이렇게 계획해요.

• 읽을 수 있는 분량 — 조각 크기의 상한이 돼요. 많이 읽는 AI에게는 큰 조각을 줘요
• 권장 방식이 ‘크게 몇 번’인 AI — 요청 한 번 한 번이 귀한 AI예요. 조각을 두 개 이하로 크게 묶어 보내 요청 수를 아껴요. 다른 AI는 기본 설정에서 최대 40조각까지 나눌 수 있어요
• 동시에 받을 수 있는 건수 — 여러 건을 한꺼번에 받는 AI는 작은 조각 여럿을 동시에 처리하고, 무대에서는 분신이 생겨요. 한 번에 하나만 받는 AI는 차례로 처리해요

요청이 비싼 AI에게는 큰 조각 몇 개를, 동시 처리에 강한 AI에게는 잘게 나눈 조각 여럿을. 같은 변경분이라도 받는 AI에 따라 썰어 주는 방식이 달라요.

조각 크기를 어림하는 데에도 19편의 교훈이 그대로 쓰여요. 읽을 수 있는 분량은 글자가 아니라 토큰으로 세고, 그래도 넘치면 오류 문구 속 숫자를 읽어 그만큼 줄여 다시 보내요. 그래도 끝내 검토하지 못한 부분이 남으면, 보고서에 ‘검토 범위 미완성’이라고 따로 적어요. 다 본 척하지 않는 거예요. 9편의 ‘모르면 비워 둔다’와 같은 생각이에요.

🏁 4. 같은 출발선 — 한 창구와 묶음 요청

경연에서 심사위원 셋의 채점표를 맞춰 보려면 셋이 같은 무대를 봤어야 해요. 한 사람은 리허설을, 다른 사람은 본무대를 봤다면 비교가 안 되죠. 이 도구가 AI들에게 보내는 요청문에도 이런 뜻의 문장이 들어 있어요. “선택된 모든 모델이 똑같은 이 요청을 받으므로, 각자의 지적을 독립적으로 비교할 수 있다.”

중계기는 이 ‘같은 조건’을 세 가지로 받쳐 줘요.

① 한 창구 — 도구는 중계기의 첫날인 7월 13일, AI마다 따로 붙여 두었던 연결 코드를 지우고 모든 AI 호출을 중계기 주소 하나로 돌렸어요. 연결 코드와 거기 딸린 부품 목록을 합쳐 약 2,400줄이 지워지고, 그 자리에 중계기와 이야기하는 약 100줄짜리 파일 하나가 들어왔어요. 이제 도구에게는 Codex든 Claude든 3편에서 본 ‘OpenAI 호환’ 창구에 이름만 바꿔 보내는 같은 모양의 요청이에요.

② 묶음 창구 — 26편의 묶음 창구가 생긴 8월 7일, 도구도 같은 날 이 창구를 쓰기 시작했어요. 묶음에 든 AI들은 전부 자리가 있을 때만 같은 순간에 함께 출발해요. 한 AI는 지금, 다른 AI는 1분 뒤에 출발하는 일이 없어요.

③ 차선에 맞춘 웨이브 — 10편에서 본 것처럼 중계기는 AI마다 동시에 달릴 수 있는 차선 수를 정해 둬요. Codex는 3개예요. 그래서 도구는 묶음을 보내기 전에 AI들을 웨이브, 즉 한 번에 같이 출발할 묶음으로 미리 나눠요.

• 한 웨이브에는 AI 종류마다 차선 수를 넘지 않게, 그리고 최대 10개까지만 담아요
• 예를 들어 Codex 모델 넷과 Claude 모델 둘을 고르면, 첫 웨이브에 Codex 셋과 Claude 둘이 함께 출발하고 남은 Codex 하나는 둘째 웨이브로 가요
• 26편에서 본 ‘3인승 칸에 넷이 타려는’ 일이 생기지 않게, 처음부터 나눠 타는 거예요. 같은 웨이브 안에서는 출발선이 같아요

멈출 때도 같아요. 사용자가 중간에 멈추면 ‘그만’ 신호 하나가 묶음 안의 모든 AI에게 전해져요. 11편에서 본, 끊긴 전화를 붙잡고 있는 상담원이 생기지 않게요.

⚖️ 5. 교차 채점 — 지적을 한 장의 보고서로

AI들의 지적이 다 모이면 이제 채점표를 맞춰 볼 차례예요.

모으기 — 같은 곳을 가리키는 같은 지적은 하나로 합치고, 누가 찾았는지는 이름을 함께 남겨요. 이 합치기는 AI에게 맡기지 않고 정해진 규칙으로 해요. 그래서 어느 AI의 답이 먼저 도착하든 결과가 같아요. 변경분에 없는 파일을 가리킨 지적은 지어낸 것으로 보고 뺍니다.

기본 구성 ‘3×8’ — 8월 10일부터 기본 구성은 AI 셋이 같은 변경분을 각자 여덟 관점 체크리스트로 처음부터 끝까지 보는 방식이에요. AI 셋은 가능하면 만든 곳이 서로 다른 AI로 섞어 골라요. 세 심사위원이 같은 무대를 모든 항목으로 따로 채점하는 셈이라, 지적이 겹치면 그 자체가 교차 확인이 돼요. 실험 단계인 ‘검증자 둘’ 구성을 고르면 AI 둘이 더 붙어서, 앞선 지적이 맞는지 하나씩 확인하고 놓친 결함도 따로 찾아요.

그다음 지적마다 믿을 만한 정도를 붙여요.

이 표시는 아무 지적도 지우지 않아요. 순서만 바꿔서, 교차 확인된 지적이 맨 위에 오고 이견 있는 지적이 맨 아래로 가요.

걸러 내던 심판에서, 표시하는 심판으로

처음부터 이랬던 건 아니에요. 7월에는 심판 AI가 지적을 하나씩 맞는지 판정해서 걸러 냈어요. 원칙은 이름표를 가린 채점이었어요. 심판 지침에는 누가 썼는지, 얼마나 자신 있게 말했는지는 무시하고 변경분만 보고 판정하라고 적었고, 7월 21일부터는 심판이 자기 지적을 스스로 채점하지 않게 했어요.

그런데 심판도 AI라서 너무 깐깐해졌어요. 7월 27일 기록에는 판정 기준이 지나치게 엄격해서 ‘확인 못 함’이 사실상 기본값이 됐고, 검증될 만한 지적까지 지나치게 떨어져 나갔다고 적혀 있어요. 심판이 보는 코드는 전체가 아니라 잘라 낸 일부라서, 근거가 화면 밖에 있을 수 있거든요. 그래서 지침에 이런 줄이 들어갔어요. 보여 준 부분에 근거가 안 보이는 것은 지적이 틀렸다는 증거가 아니다. 보이는 코드가 주장을 정면으로 반박할 때만 ‘틀림’이에요.

그리고 7월 30일에는 방향을 아예 바꿨어요. 최종 보고서는 지적을 걸러 내지 않고 모두 싣는 통합 요약이 됐고, 8월 10일부터는 위의 표시로 믿을 만한 정도를 보여 줘요. 버리는 대신 표시하는 거예요. 판단은 읽는 사람이 할 수 있게요.

마지막 심판과 사람의 몫

지적이 다 모이면 심판 AI 하나가 보고서를 마무리해요. 심판은 가능하면 이번 판에 참가하지 않은 AI로 고르고, 후보가 여럿이면 약속한 양식을 잘 지키고 한 번에 많이 읽을 수 있는 AI를 앞에 둬요. 8월 20일부터 심판은 서로 이어진 지적을 묶어 “이 두 문제는 같은 원인에서 나온다” 같은 해설을 붙여요. 다만 지침상 새 지적을 만들거나, 지적의 참·거짓을 판정하거나, 지적을 빼는 일은 하지 않아요.

마지막 결정은 사람이 해요.

• 보고서의 지적마다 [이 지적을 PR에 댓글 달기] 버튼이 있어서, 사람이 골라 누른 지적만 PR의 해당 줄에 댓글로 올라가요
• 댓글 첫 줄에는 ‘관점 × AI’ 출처가 붙어요. 어느 관점의 어느 AI가 찾은 지적인지 바로 보여요
• 도구는 댓글만 달아요. “합쳐도 된다”는 승인이나 “고쳐 오라”는 거절 표시는 AI에게 맡기지 않아요

정리

① AI 리뷰어 하나는 놓쳐요. 코드 리뷰 대결 도구는 바뀐 코드를 조각으로 나누고, 사용자 치명 문제부터 동시성까지 일곱 가지 관점을 여러 AI에게 나눠 맡겨 빈틈을 줄여요 ② 중계기는 한 창구로 여러 AI를 부르게 하고, 묶음 창구와 차선에 맞춘 웨이브로 같은 출발선을 지키고, 스펙 카드로 AI마다 조각 크기를 정하게 해 줬어요 ③ 모은 지적은 지우지 않고, 몇이 찾았는지와 다른 AI가 동의하는지로 믿을 만한 정도를 표시해 한 장의 보고서로 합쳐요. 올릴지 말지는 사람이 정해요

다음 28편은 「지식을 넣었더니 지적이 사라졌다」예요. 리뷰하는 AI에게 프로젝트 지식을 더 넣어 주면 더 잘 찾을 줄 알았는데, 재 보니 정반대였던 실험 이야기예요. 참고서를 줬더니 답안이 짧아진 학생처럼요. 묶음 창구와 ‘3인승 칸’ 이야기는 26편에, 스펙 카드는 9편에 있어요.

2026년 10월 2일 기준입니다. 제가 만든 중계기와 코드 리뷰 대결 도구의 개발 기록을 바탕으로 썼고, 특정 기업·서비스의 공식 입장이 아닙니다. 관점 목록, 조각 수 상한(크게 몇 번 2개 · 기본 40개), 웨이브 크기(최대 10개), 차선 수 같은 값은 기본 설정이라 이후 버전에서 바뀔 수 있어요.