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

2026년 10월 2일 기준

이 글에는 제휴 링크가 없고 글에 나오는 AI 서비스들(OpenAI·앤트로픽)과 아무 관계가 없습니다. 제가 직접 만든 중계기의 개발 기록을 바탕으로 썼습니다. 삽화는 GPT 이미지 생성, 도식은 직접 제작했습니다.

검사는 지우지 않는다 — 사고 다발 교차로의 신호등 (LLM 중계기 개발기)

사고가 유난히 잦은 교차로가 하나 있다고 해 볼게요. 처음에는 신호등이 하나도 없었어요. 차끼리 부딪히는 사고가 나자 신호등이 섰고, 좌회전하던 차가 사고를 내자 좌회전 신호가 더해졌고, 길을 건너던 사람이 다칠 뻔하자 보행 신호가 생겼어요. 신호등 하나하나에 사연이 있는 셈이죠.

몇 달 동안 사고가 한 건도 없었다고 신호등을 뽑자는 사람은 없을 거예요. 사고가 없는 게 바로 신호등 덕분이니까요. 길을 넓혀 차선이 옮겨 가면 신호등을 버리는 대신 새 차선 쪽으로 옮겨 달고요. 다만 신호가 너무 길면 이야기가 달라져요. 빨간불이 몇 분씩 이어지면, 차가 없을 때 그냥 건너는 사람이 생기기 마련이에요. 지키기 어려운 신호는 결국 아무도 지키지 않게 돼요.

제가 만든 LLM 중계기에도 이런 신호등이 있어요. 고장이 날 때마다 하나씩 세운 자동 검사들이에요. 오늘은 그 신호등들이 어떻게 늘었고, 왜 하나도 뽑지 않았고, 너무 길어진 신호를 어떻게 나눴는지 이야기할게요.

이 글은 LLM 중계기 개발기의 31편입니다. 지난 30편 「AI가 허락을 기다리다 멈췄다」에서는 작업 폴더 모드에서 AI가 사람의 허락을 기다리다 멈춰 선 이야기를 했어요. 4편에서 ‘고장 하나에 검사 하나’라는 습관을 소개하며 검사를 지우지 않는 원칙은 31편에서 하겠다고 약속했는데, 오늘이 그 편이에요.

결론 요약

• 습관 — 고장 하나를 고칠 때마다 같은 고장을 다시 잡는 검사를 하나씩 세웠어요. 첫 버전이 나오고 이틀이 채 안 돼 시험을 돌릴 때마다 먼저 도는 검사와 시험이 13개가 됐고, 지금 검사 목록에는 12종이 올라 있어요. 지운 검사는 없어요
• 판단 — 전부 매번 돌리자 시험 한 번에 18초쯤 걸렸어요. 기록은 “매번 18초를 물리면 시험을 안 돌리게 된다”고 적었어요. 그래서 커밋 전에 도는 빠른 핵심 검사 5종과 새 판을 내기 전에 꼭 도는 전체 검사로 나눴어요
• 원칙 — 코드가 옮겨 가면 검사를 지우지 않고 검사가 보는 곳을 옮겨요. 그리고 일부러 고장을 다시 넣어, 검사가 정말 무는지 확인해요

🚦 1. 신호등마다 사연이 있다 — 이틀 만에 열세 개

먼저 낱말 두 개를 짚을게요.

• 시험(테스트, test) — 기능 하나가 정해진 대로 움직이는지 확인하는 작은 시험이에요. “이 글을 넣으면 이 답이 나와야 한다” 같은 것들이죠
• 검사(게이트, gate) — 시험만으로는 잡기 어려운 것을 지키는 관문이에요. 컴퓨터 종류에 따라 달라지는 것, 켜고 끄는 과정, 기록에 남는 내용 같은 것들이요. 통과하지 못하면 다음 단계로 넘어가지 못해요

4편에서 첫날 붙인 검사 6개를 표로 봤어요. 그 습관은 둘째 날에도 이어졌어요. 그리고 새로 생긴 검사와 시험은 모두 시험을 돌릴 때마다 맨 먼저 도는 자리에 줄줄이 붙었어요. 신호등이 하나 설 때마다, 교차로를 지나는 모든 차가 그 신호를 받게 된 셈이에요.

첫 버전이 7월 13일 아침 8시에 나왔으니, 이틀이 채 지나지 않아 시험을 한 번 돌릴 때마다 검사 10개와 시험 3개, 모두 13개가 먼저 돌게 된 거예요. 하나하나가 실제로 겪은 사고, 또는 지키기로 한 원칙에서 나왔어요.

⏱️ 2. 신호가 길면 무단횡단한다 — “매번 18초면 안 돌린다”

신호등이 열세 개가 되자 문제가 생겼어요. 교차로 하나를 건너는 데 시간이 너무 오래 걸리게 된 거예요.

프로그램을 고치는 일은 대개 작은 한 바퀴의 반복이에요. 조금 고치고, 시험을 돌리고, 결과를 보고, 다시 고치고. 그런데 시험을 돌릴 때마다 열세 개가 먼저 돌았으니, 기능 시험 자체는 금방 끝나도 한 바퀴에 18초쯤 걸렸어요. 중계기의 검사 목록 문서에 남은 숫자예요.

18초는 짧아 보여요. 그런데 문서에는 이런 문장이 적혀 있어요.

개발 반복 속도가 곧 품질이다. 매 저장마다 18초를 물리면 테스트를 안 돌리게 된다.

빨간불이 너무 길면 무단횡단이 생기는 것과 같아요. 시험이 느리면 ‘이번엔 작은 수정이니까’ 하며 건너뛰고 싶어지고, 건너뛴 시험은 아무것도 지켜 주지 못하니까요.

그래서 7월 21일 아침, 검사를 세 묶음으로 나눴어요. 하나도 지우지 않고 자리만 바꿨어요.

① 기본 시험 — 시험을 돌릴 때 매번 도는 건 기능 시험만 남겼어요. 그날 기록으로 시험 229개가 약 1.7초에 끝났어요

② 핵심 검사 5종 — 저장 기록(커밋)을 남기기 전에 돌리기를 권하는 묶음이에요. 문서에는 수 초면 끝난다고 적혀 있어요

③ 전체 검사 — 본 줄기에 합치거나(PR) 새 판을 내거나 배포하기 전에는 반드시 돌리는 묶음이에요. 그날 검사 10종과 시험 229개를 모두 돌리는 데 약 19.5초가 걸렸어요

눈여겨볼 점이 있어요. 전체를 다 돌리는 시간은 여전히 20초쯤이에요. 줄어든 건 검사의 양이 아니라 매번 기다리는 시간이에요. 날마다 지나는 길의 신호는 짧게 두고, 꼼꼼한 점검은 차를 내보내기 전 출고 검사에서 한 번 제대로 하는 거죠.

그날 저장 기록의 제목에는 ‘재적용’, 그러니까 다시 적용했다는 말이 붙어 있어요. 그리고 이번에는 방침을 문서로 남겼어요. 검사 목록 문서의 방침 제목은 ‘되돌리지 말 것’이고, 무거운 검사를 매번 도는 자리로 다시 끌어오지 말라는 경고와 함께, 다른 컴퓨터에서 작업하더라도 이 방침이 유지되도록 이 문서를 근거로 삼는다고 적혀 있어요.

나눈 뒤에도 검사가 잊히지 않았다는 흔적은 저장 기록에 있어요. 8월 말의 기록 여러 개에는 ‘핵심 검사 통과’가, 8월 11일·9월 1일·9월 8일 기록에는 ‘전체 검사 통과’가 시험 개수와 함께 적혀 있어요.

🗂️ 3. 안쪽 고리와 바깥 고리 — 검사 목록 12종

중계기 저장소에는 검사 목록 문서가 따로 있어요. 7월 21일에 묶음을 나누며 함께 만든 문서로, 검사마다 어느 묶음에 들어가는지, 어떤 고장을 막는지가 적혀 있어요. 오늘(10월 2일) 이 목록에는 12종이 올라 있어요.

안쪽 고리 — 핵심 검사 5종 (커밋 전)

문서가 꼽은 기준은 셋이에요. 실제로 쓰는 사람이 겪은 고장을 잡았고, 값싸게 돌고, 코드를 고치다 보면 다시 생기기 쉬운 것.

• 부품 목록 검사·경로 검사·실행 통로 검사 — 첫날 ‘같은 코드, 다른 컴퓨터’ 고장 셋에서 나왔어요(20편)
• 종료 정리 검사 — 끈 뒤에 남는 프로그램을 막아요(21편). 실제로 프로그램을 띄웠다 끄고, 정말 사라졌는지와 문 번호(포트)가 닫혔는지를 재요
• 기록 검사 — 흉내만 내는 가짜 AI를 붙여 성공·잘림·오류를 실제로 주고받은 뒤 기록을 열어 봐요. 오류 원문이 잘리지 않았는지, 비밀 값이 드러나지 않았는지, 잘린 답에 경고가 붙었는지 확인해요(18편, 16편)

바깥 고리 — 전체 검사 (PR·새 판·배포 전)

핵심 5종에 검사 다섯을 더하고, 시험 항목 전부를 함께 돌려요.

• 종료 경로 검사 — 정리가 ‘작동하는지’가 아니라 ‘불리는지’를 봐요(21편)
• 압축판 부품 검사 — 배포판에 그 컴퓨터용 부품이 들어 있는지 확인해요(20편)
• 오류 원문 검사 — 코드를 읽어서, 오류를 짧게 자르는 줄이 있으면 실패해요(18편의 ‘검사 ①’)
• 설정 파일 안내 검사 — “설정 파일을 직접 열어 고치세요” 같은 안내가 문서나 화면에 남아 있으면 실패해요(4편). 고장이 아니라 원칙을 지키는 검사예요
• 화면 높이 검사 — 채팅과 문서 화면이 패널을 끝까지 채우는지, 크롬으로 화면을 실제로 띄워 여러 창 크기에서 재요. 크롬 브라우저가 있어야 돌 수 있어서 바깥 고리에 있어요

그리고 8월 8일, 앱 껍데기를 작은 트레이 프로그램으로 바꿀 때(25편) 둘이 더 올라왔어요. 윈도 배포판 검사와 맥·리눅스 배포판 검사예요. 압축 파일이 깨지지 않았는지, 들어 있어야 할 것이 다 들어 있는지 확인해요. 윈도 배포판 검사는 들어 있으면 안 되는 것(예전 껍데기 Electron과 그 안의 브라우저)이 없는지도 봐요. 이 둘은 배포판을 만드는 명령 끝에 자동으로 따라 돌아요.

새 검사를 더하는 규칙도 문서에 있어요.

• 먼저 목록 표에 적고, 어떤 고장을 막는지 함께 쓴다
• 값싸고 실제 고장을 잡는 것이면 안쪽 고리에, 무겁거나 특정 환경이 필요하면 바깥 고리에만 넣는다
• 매번 도는 자리에는 넣지 않는다

검사가 열두 종으로 느는 동안 시험 항목도 늘었어요. 저장 기록에 적힌 숫자를 날짜순으로 옮기면 이래요.

• 7월 13일 저녁 — 48개 (첫날)
• 7월 21일 — 229개 (묶음을 나눈 날)
• 8월 11일 — 490개
• 9월 1일 — 586개
• 9월 8일 — 631개
• 9월 22일 — 713개
• 9월 25일 — 799개 (798개 통과, 1개는 건너뜀)

9월 25일 뒤로는 저장 기록에 숫자가 적혀 있지 않아서 여기까지만 적었어요. 첫날 저녁의 열여섯 배가 넘어요.

🔁 4. 뽑지 않고 옮겨 단다 — 길이 바뀌면 신호등도 옮긴다

검사 목록 문서의 방침에는 이런 줄이 있어요.

게이트는 삭제하지 않는다 — 격리·강등만. 아래 전부 실제 버그를 잡은 이력이 있다(또는 원칙 가드).

‘격리·강등’은 검사를 매번 도는 자리에서 빼 다른 묶음으로 옮긴다는 뜻이에요. 지운다는 선택지는 처음부터 없었어요. 코드가 크게 바뀔 때도 마찬가지였어요. 검사가 보던 코드가 사라지면 검사를 지우는 대신 검사가 보는 곳을 옮겼어요.

① 종료 경로 검사 — Electron에서 트레이로 7월 21일 목록에서 이 검사의 분류는 ‘Electron용’이었어요. 창을 X로 닫을 때 숨기기가 아니라 정리를 부르는지, 창이 모두 닫히면 종료를 부르는지 봤어요. 8월 8일 Electron 껍데기를 걷어내자 검사가 보던 코드가 통째로 사라졌어요. 검사는 지워지지 않고 ‘트레이용’으로 다시 쓰였어요. 지금은 트레이가 중계기의 종료 창구를 부르는지, 정리에 11초 상한이 있는지, 서버가 끝내 꺼지지 않으면 트레이가 나무째 끄는 마지막 수단이 연결돼 있는지 확인해요. Electron 코드를 지우기 전까지 Electron판과 새 시작 파일(런처)을 나란히 둔 것도 이 검사가 Electron 코드를 보고 있었기 때문이에요

② 경로 검사의 재현 시험 — 옛 시작 파일에서 새 시작 파일로 윈도의 D:를 주소로 착각한 고장을 재현하던 시험은 지키는 대상을 Electron 시작 파일에서 런처로 옮겼어요

③ 오류 원문 검사 — 보는 범위를 넓혔다 처음에는 AI 연결 부품 폴더만 읽었는데, 그날 저녁 기록 보관함이 400자에서 자르고 있던 게 드러나자 보관함과 중계기 본체 코드까지 읽게 넓혔어요

④ 압축판 부품 검사 — 윈도 하나에서 배포 대상 넷으로 7월에는 ‘맥에서 만든 윈도용 배포판’만 지키던 검사였어요. 껍데기를 바꾸며 맥판과 리눅스판도 나오자, 검사가 보는 대상도 넓어졌어요. 지금은 컴퓨터마다 다른 실행 파일을 쓰는 부품이 배포 대상 네 가지(윈도, 맥 두 종류, 리눅스) 모두에 갖춰져 있는지 확인해요

⑤ 매번 돌던 시험 셋 — 지우지 않고 전체 시험 안으로 ‘영구 대기 금지’, 명령어 도구 버전, 위장 실패 시험은 원래 매번 맨 먼저 돌았어요. 이 셋은 어차피 기능 시험 전체에도 들어 있어서, 7월 21일에 두 번 돌던 것을 한 번으로 줄였어요. 줄어든 건 중복이지 시험이 아니에요

⑥ 정답이 바뀌면 정답을 고친다 22편에서 Claude 연결 부품의 검사 하나가 ‘연결 직후 다른 모델은 워밍업 중’을 정답으로 지키고 있었어요. 화면 규칙이 ‘준비 전’으로 바뀌자 그 검사도 지우지 않고 정답을 ‘준비 전’으로 고쳤어요

오늘(10월 2일) 코드를 읽는 검사 여섯 개를 다시 돌려 봤어요. 부품 목록, 경로, 실행 통로, 오류 원문, 설정 파일 안내, 종료 경로 검사예요. 모두 통과했어요. 7월 13일 아침에 선 첫 신호등에도 여전히 불이 들어와 있는 셈이에요.

🦷 5. 불이 정말 들어오나 — 일부러 고장을 다시 넣어 본다

꺼진 신호등은 신호등이 없는 것보다 위험할 수 있어요. 사람들은 신호등이 있다는 이유로 마음을 놓으니까요. 검사도 같아요. 가장 위험한 검사는 있는데 걸리지 않는 검사예요. 17편에는 검사가 있는데도 걸리지 않은 일이 두 번 나와요. 그중 하나는 검사가 시작하자마자 오류로 멈췄는데, 주변 장치가 그 오류를 삼켜 버린 일이었어요. 겉으로는 지켜지는 것처럼 보였죠.

그래서 검사를 세우면 그 검사가 정말 무는지 확인해요. 방법은 단순해요. 고친 코드를 일부러 다시 망가뜨리고, 검사가 실패하는지 보는 거예요.

• 오류 원문 검사(18편) — 지웠던 160자 자르기를 일부러 다시 넣었더니 검사가 실패로 끝났어요
• 종료 정리 검사(21편) — 끄기 기능을 아무것도 하지 않는 빈 껍데기로 바꿨더니 “자식이 아직 살아 있음”으로 실패했어요
• 새로 붙인 AI의 전용 차선 검사(13편) — 고치기 전 코드에서는 이 검사가 실패한다는 것까지 확인했어요

검사를 만드는 방식에도 같은 생각이 들어 있어요. 종료 정리 검사의 첫머리에는, 검사는 통과하는데 실제로는 안 되는 일을 피하려고 가짜로 통과시키지 않고 실제 프로그램과 문 번호의 상태를 잰다고 적혀 있어요. 정리 기능을 불렀다는 사실이 아니라, 프로그램이 정말 사라졌는지를 보는 거예요.

그래도 빈틈은 남아요. 종료 정리 검사는 통과했는데 창 X로 닫는 길은 정리를 부르지도 않았던 일(21편)이 그랬어요. 그 빈틈에서 종료 경로 검사가 나왔고, 두 검사는 정리가 ‘작동하는가’와 ‘불리는가’를 나눠 보는 짝이 됐어요.

한계도 숨기지 않아요. 화면 높이 검사는 크롬이 없는 컴퓨터에서는 ‘건너뜀’ 경고를 남기고 넘어가요. 건너뛴 검사는 통과한 검사가 아니라는 걸 기록에 남기는 거죠. 검사가 쓰는 사람의 진짜 열쇠를 건드리지 않게 하는 규칙도 있어요. 중계기를 실제로 띄우는 검사는 늘 임시 폴더와 임시 문 번호에서 돌아요. 검사 때문에 진짜 설정이 바뀌면 그게 또 하나의 사고니까요.

📏 6. 남긴 규칙 — 신호등을 관리하는 법

• 고장 하나에 검사 하나 — 고친 고장은 같은 고장을 다시 잡는 검사와 함께 저장해요
• 검사는 지우지 않는다 — 매번 도는 자리에서 빼거나, 보는 곳을 옮길 뿐이에요. 규칙이 바뀌면 정답을 고쳐요
• 매번 도는 건 가볍게 — 느린 검사는 결국 아무도 돌리지 않아요. 무거운 검사는 내놓기 전에 한 번 제대로 돌려요
• 새 검사는 목록에 적는다 — 어느 고리에 넣을지, 무엇을 막는지 이유와 함께
• 검사가 무는지 확인한다 — 일부러 고장을 다시 넣어 실패하는지 봐요

정리

① 고장 하나를 고칠 때마다 검사를 하나 세웠어요. 이틀이 채 안 돼 매번 먼저 도는 검사·시험이 13개가 됐고, 지금 검사 목록에는 12종이 있어요. 시험 항목은 첫날 48개에서 9월 25일 799개로 늘었어요 ② 매번 다 돌리니 한 번에 18초쯤 걸렸고, “매번 18초를 물리면 시험을 안 돌리게 된다”는 판단으로 커밋 전 핵심 검사 5종과 새 판 전 전체 검사(약 20초)로 나눴어요. 매번 도는 기능 시험은 약 1.7초가 됐어요 ③ 검사는 지우지 않고, 코드가 옮겨 가면 검사가 보는 곳을 옮겨요. 그리고 일부러 고장을 다시 넣어 검사가 정말 무는지 확인해요

다음 32편은 「가짜는 진짜를 대신 못 한다」예요. 오늘 본 검사와 시험의 대부분은 흉내만 내는 가짜 AI로 돌아요. 가짜로 모두 통과해도 새 판을 내기 전에 진짜 환경에서 한 번은 돌려 봐야 하는 이유를 이야기할게요.

2026년 10월 2일 기준입니다. 제가 만든 중계기의 개발 기록(저장 기록의 시각과 메모, 검사 목록 문서, 검사 스크립트)을 바탕으로 썼고, 특정 기업·서비스의 공식 입장이 아닙니다.