이 글에는 제휴 링크가 없고 글에 나오는 AI 서비스들(OpenAI·앤트로픽·구글·NVIDIA·LM Studio)과 아무 관계가 없습니다. 제가 직접 만든 중계기의 개발 기록을 바탕으로 썼습니다. 삽화는 GPT 이미지 생성, 도식은 직접 제작했습니다.
설정 한 줄 빠졌을 뿐인데 전멸 — 이름표 없는 손님은 맨 뒤로 (LLM 중계기 개발기)
큰 행사장 접수처를 떠올려 볼게요. 미리 등록한 손님은 이름표를 받아요. 이름표에는 어느 창구로 가면 되는지, 그 창구가 몇 개 열려 있는지, 얼마나 기다려도 되는지가 적혀 있어요.
그런데 등록 명단에서 이름 한 줄이 빠진 손님이 왔어요. 안내원은 친절해서 돌려보내지 않아요. 대신 아무 말 없이 ‘일반 창구’로 보내요. 일반 창구는 하나뿐이고, 1분을 기다려도 차례가 안 오면 “오늘은 어렵습니다”라며 돌려보내는 규칙이 있어요.
하필 이 손님 일행은 접수에 시간이 오래 걸리는 사람들이었어요. 한 사람 접수에 1분 가까이 걸리니, 뒤에 선 일행은 1분을 못 채우고 줄줄이 돌려보내져요. 안내원이 “처음부터 다시 접수해 보세요”라고 하자, 다시 온 사람이 하나뿐인 창구를 또 오래 붙잡아요.
누구도 큰 실수를 한 것 같지 않은데 일행 전원이 접수를 못 했어요. 원인은 등록 명단에서 빠진 한 줄이었어요.
이 글은 LLM 중계기 개발기의 13편입니다. 지난 12편 「1분에 몇 번까지 부를 수 있나」에서는 AI 서비스가 정해 둔 ‘1분에 몇 번’ 한도와, 그 한도에 맞춰 요청 사이 간격을 벌려 주는 페이서 이야기를 했어요. 오늘은 10편 끝에서 예고한 사고, 새 AI의 차선 설정 한 줄이 빠진 날의 이야기입니다.
결론 요약
- 증상 — 새로 붙인 명령어 도구 AI 하나가 ‘연결 성공’으로 떴는데, 그 뒤 호출은 전부 실패했어요. 실패한 호출은 줄에서 60초를 기다리다 쫓겨났고, AI는 한 번도 실행되지 않았어요
- 원인 — 중계기의 교통정리 칸에 이 AI의 차선 설정이 없어서, 오류 없이 전체 기본값(차선 1개·줄에서 60초)으로 떨어졌어요. 한 번 부르는 데 1분 가까이 걸리는 AI에게는 맞지 않는 값이었죠. 게다가 실패 안내가 ‘연결 확인을 다시 하라’여서, 안내를 따를수록 줄이 더 막혔어요
- 해결과 규칙 — 전용 차선 설정을 넣고, 연결 확인은 줄 맨 앞으로, 붐빌 때는 ‘붐빈다’고 알리게 했어요. 그리고 ‘새 AI는 어댑터 파일 하나와 등록 한 줄’이라는 규칙에 차선 설정 한 줄이 함께 붙었어요
🚨 1. 증상 — ‘연결 성공’인데 호출은 전멸
9월 4일 오후, 중계기 새 버전(v0.1.93)을 내놓았어요. 이 버전에서 새로 붙인 명령어 도구 AI 하나의 [연결]이 성공으로 떴어요. 명령어 도구 AI는 Codex나 Claude처럼 내 컴퓨터에서 명령어로 켜서 쓰는 AI예요. 5편에서 본 세 갈래 중 하나죠.
그런데 곧이어 누른 [테스트 호출]이 실패했어요. 중계기를 쓰는 프로그램에서 보낸 호출도 실패했고요. 한두 번이 아니라 전부요.
먼저 AI가 고장 난 건지부터 가렸어요. 같은 앱에서 이 AI를 하나만 따로 불러 보니, 시간은 꽤 걸렸지만 ‘pong’이라는 답이 정상으로 돌아왔어요. AI는 멀쩡했던 거예요.
실마리는 실패한 호출의 기록 한 줄에 있었어요. 2편에서 본, 요청마다 남는 그 기록이에요.
| 기록 칸 | 값 | 뜻 |
|---|---|---|
| 이유 이름 | provider_queue_timeout | 그 AI의 줄에서 기다리다 시간 초과 |
| 줄 선 시간 | 60,001ms (60.001초) | 줄에서 딱 60초를 기다렸다 |
| 달린 시간 | 0ms | 차선에 한 번도 들어가지 못했다 |
달린 시간이 0이라는 건 중계기가 AI를 한 번도 실행하지 않았다는 뜻이에요. 호출들은 AI 근처에도 가 보지 못하고, 요금소 앞 줄에서 60초를 채우자마자 쫓겨났어요. 고장은 AI가 아니라 중계기 안, 교통정리 칸에 있었어요.
🏷️ 2. 원인 — 이름표가 없으면 ‘조용히’ 기본값으로
10편에서 본 것처럼 중계기 한가운데의 교통정리 칸은 AI마다 차선 설정을 따로 갖고 있어요. 차선을 몇 개 열지, 줄에서 얼마나 기다리게 할지, 달리는 시간은 얼마까지 줄지를 AI마다 적어 둔 한 줄이에요. 개발자들은 흔히 이런 묶음을 프로필(profile)이라고 불러요. 손님의 이름표 같은 거죠.
그런데 새로 붙인 이 AI는 그 목록에 없었어요. 어댑터 파일도 있고 등록부에 이름도 올라 있었는데, 교통정리 칸의 설정 목록에만 한 줄이 빠져 있었어요.
설정이 없는 AI가 와도 교통정리 칸은 오류를 내지 않아요. 경고도 없이 전체 기본값을 줘요. 그 기본값은 이랬어요.
- 차선 1개 — 한 번에 한 건만 달릴 수 있어요
- 줄에서 60초 — 앞 요청이 60초 안에 끝나야 뒤 요청이 살아남아요
- 달리는 시간 3분 — 이 AI의 어댑터가 스스로 정한 상한(10분)보다 짧아서, 긴 검토 요청은 중계기가 먼저 끊었어요
이 AI는 한 번 부르는 데 1분 안팎이 걸렸어요. 게다가 [연결] 확인은 설치와 로그인만 보는 게 아니라 진짜 질문을 한 번 던져 답이 오는지까지 보는데, 이 확인이 하나뿐인 차선을 2분 안팎 붙잡았어요.
그다음은 계산대로 흘러갔어요.
① [연결]을 누르면 연결 확인이 하나뿐인 차선에 들어가 2분 안팎을 붙잡아요 ② 그사이 [테스트 호출]이나 프로그램의 호출이 오면 줄을 서요 ③ 줄에서 60초가 지나도 차선은 비지 않아요. 호출은 ‘줄에서 기다리다 시간 초과’로 쫓겨나요
행사장으로 치면 이름표 없는 손님이 ‘일반 창구’로 보내졌는데, 그 창구의 1분 규칙이 하필 접수가 오래 걸리는 이 손님에게 치명적이었던 셈이에요. 빨리 답하는 AI였다면 같은 기본값으로도 티 나지 않고 지나갔을 수 있어요. 기본값은 ‘많은 경우에 무난한 값’이지, ‘모든 AI에게 맞는 값’이 아니었어요.
🔁 3. 따를수록 막히는 안내 — 스스로 불어나는 고리
여기까지만이면 ‘차선 설정을 넣으면 끝’이었을 거예요. 그런데 상황을 더 꼬이게 만든 것이 몇 가지 더 있었어요.
첫째, 실패 안내가 엉뚱한 곳을 가리켰어요.
줄에서 시간이 초과된 호출에 나간 안내는 이랬어요.
“모델 응답을 확인하지 못했습니다. [모델연결확인]을 다시 실행하세요.”
줄이 막혀 차례가 안 온 것뿐인데, 안내는 AI의 응답에 문제가 있는 것처럼 말하고 연결 확인을 다시 하라고 권했어요. 문제는 그 연결 확인이 하나뿐인 차선을 또 2분쯤 붙잡는다는 거예요. 안내를 따르면 이렇게 돌아요.
- 연결 확인이 차선을 붙잡는다
- 그사이 들어온 호출이 또 60초에 쫓겨난다
- 같은 안내가 또 나온다
안내를 성실히 따를수록 실패가 늘어나는 고리였어요. 개발 기록에는 이걸 ‘자기증식 루프’라고 적어 두었어요.
둘째, 연결 확인이 실패하면 멀쩡하던 연결까지 지웠어요.
연결 확인이 붐벼서 실패해도, 중계기는 이미 확인해 둔 연결 상태와 모델 목록을 지웠어요. 화면에서는 되던 AI가 갑자기 ‘연결 해제’된 것처럼 보이니 사람은 [연결]을 다시 누르게 되고, 그 연결 확인이 또 차선을 붙잡았어요.
셋째, 연결 확인도 시험 호출과 같은 줄에 섰어요.
10편에서 교통정리 칸은 요청을 세 등급으로 나눈다고 했죠. 이때 연결 확인은 [테스트 호출]과 같은 ② 보통 등급이었어요. 그래서 연결 확인이 앞선 호출들 뒤에 줄을 서기도 했어요. 기록에는 [테스트 호출] 두 건 뒤에 선 연결 확인이 줄에서만 몇 분씩 기다린 기록이 남아 있어요.
넷째, 멀쩡한 짧은 답도 실패로 처리했어요.
이 AI는 답이 아주 짧으면(열 글자 미만) 마무리 단계에서 스스로 오류 신호를 냈어요. 그런데 프로그램은 정상으로 끝났고, ‘다 했다(completed)‘는 표시와 함께 답 본문도 그대로 있었어요. 중계기는 오류 신호만 보고, 성공한 호출을 실패로 처리했어요.
🧰 4. 고친 것 — 이름표, 앞줄, 솔직한 안내
원인은 새 버전을 내놓은 그날 밤에 가려내 고쳤고, 고친 버전은 9월 8일 아침 v0.1.94로 나갔어요.
① 이름표 달아 주기 — 전용 차선 설정
- 줄에서 기다릴 수 있는 시간: 60초 → 최대 10분
- 달리는 시간 상한: 어댑터가 스스로 정한 상한(10분)보다 길게. 중계기가 먼저 끊지 않게요
② 연결 확인은 줄 맨 앞으로
연결 확인을 ① 먼저 등급으로 올렸어요. 이미 달리고 있는 요청을 끊지는 않고, 줄에서만 앞에 서요. 10편에서 연결 확인이 ‘사람이 기다리는 요청’과 같은 ① 먼저 등급에 들어 있었던 건 이 사고 뒤에 올라간 거예요.
그리고 연결 확인이 붐벼서 실패해도 이미 확인된 연결과 모델 목록은 지우지 않게 했어요. 붐비는 건 고장이 아니니까요.
③ 붐비면 붐빈다고 알리기
줄 때문에 생긴 실패에는 ‘혼잡’(capacity)이라는 새 단계 이름을 붙였어요. 안내도 바꿨어요.
“앞선 요청이 끝나기를 기다리다 대기 시간이 초과됐습니다. … 실행 중인 요청(연결 확인 포함)이 끝난 뒤 다시 호출하세요.”
이제 혼잡으로 생긴 실패에는 ‘연결 확인을 다시 하라’는 말이 붙지 않아요. Codex·Claude·Gemini 같은 다른 명령어 도구 AI도 줄이 찰 수 있어서 똑같이 바꿨어요. 프로그램이 받는 답에도 ‘혼잡’이라는 단계와 다시 올 시간이 그대로 담겨요.
④ 기다리는 중이면 보여 주기
줄에서 기다릴 수 있는 시간을 10분으로 늘리면, 그만큼 오래 화면에 아무 변화가 없을 수 있어요. 멈춘 줄 알고 또 누르면 안 되니까, 시험 호출이 줄에 서 있는 동안에는 이렇게 보여 주게 했어요.
대기 중… 앞선 요청이 끝나면 시작합니다 (실행 N/3 · 대기 N건 · N초 경과)
⑤ 짧은 답 살리기
오류 신호가 있어도 답 본문이 있으면 살려서 돌려주고, 정말 아무 글자도 없을 때만 실패로 처리해요. 살린 경우에는 기록에 ‘복구했다’는 표시를 남겨요.
⑥ 차선 1개 → 3개
이 AI의 차선을 1개로 둔 데는 이유가 있었어요. 예전 버전에 대해 ‘동시에 실행하면 서로의 작업을 끊을 수 있다’는 주의가 있었거든요. 다만 지금 버전에서도 그런지는 확인된 적이 없었어요.
그래서 직접 시험했어요. 호출마다 서로 다른 암호 단어를 주고 ‘그 단어를 그대로 돌려 달라’고 해서, 답이 섞이면 바로 드러나게 했어요. 동시에 3건을 보내도 한 건이 끝나는 시간은 조금 늘었을 뿐이고, 답이 섞이거나 틀리거나 실패한 경우는 없었어요. 그래서 Codex·Claude·Gemini와 같은 3으로 올렸어요.
🧪 5. 부품 시험은 통과했는데 조립품에서 터졌다
이상한 점이 하나 남아요. 이 AI에는 실제 AI를 붙여 단계별로 확인하는 시험이 따로 있었고, 새 버전을 내기 전에 그 시험을 모두 통과했어요. 그런데 왜 못 잡았을까요?
그 시험은 중계기 전체를 띄우지 않고 어댑터만 직접 불렀어요. 실패했을 때 어댑터와 AI 사이의 약속 문제인지 가려내려고 일부러 그렇게 만든 시험이었죠.
그런데 이번 원인은 어댑터가 아니라, 어댑터들을 하나로 조립한 중계기 안의 교통정리 칸 설정이었어요. 어댑터만 보는 시험은 그 칸을 지나가지 않으니 볼 수가 없었어요. 개발 기록은 이 빈틈을 ‘이번 유출의 직접 원인’이라고 적었어요.
자동차로 치면 엔진 시험대에서는 엔진이 멀쩡히 돌았는데, 차에 얹고 보니 설정 하나가 빠져 있었던 셈이에요. 부품 시험은 통과했는데 조립품에서 터진 거죠.
그래서 시험을 두 가지 더했어요.
- 조립된 중계기를 실제로 띄우는 단계 — 연결 확인이 차선을 붙잡고 있는 동안 호출을 보내는 상황을 그대로 재현해요. 이 단계에서는 차선을 일부러 1개로 줄여서 반드시 줄이 생기게 해요. 차선이 3개면 호출들이 그냥 나란히 달려 버려서 이 사고를 다시 잡지 못하거든요
- 매번 도는 자동 검사 하나 — 실제 AI 없이 조립된 중계기를 띄워, 이 AI에 전용 차선 설정이 들어 있는지, 줄 시간과 달리는 시간이 실측보다 넉넉한지 확인해요. 고치기 전 코드에서는 이 검사가 실패한다는 것까지 확인했어요
📌 6. 남긴 규칙 — ‘등록 한 줄’의 두 번째 줄
5편에서 중계기 설명서의 규칙을 소개했죠. 새 AI는 어댑터 파일 하나와 등록 한 줄. 그리고 NVIDIA를 붙인 날 바뀐 것 가운데 ‘교통정리 설정 한 줄’은 규칙의 ‘등록 한 줄’과 별개라 빠뜨리기 쉽다고 적어 뒀어요. 이번 사고가 바로 그 한 줄이었어요.
그래서 AI와 함께 개발할 때 늘 읽히는 안내 문서에 경고를 넣었어요. 요지는 이래요.
AI를 추가하면 교통정리 칸의 설정 목록에도 반드시 한 줄을 넣을 것. 빠지면 전체 기본값(줄에서 60초·달리는 시간 3분)으로 조용히 떨어진다. 한 번 부르는 데 60초를 넘는 AI에서는 뒤 요청이 전부 줄에서 쫓겨난다.
그 뒤로는 빠뜨리지 않았어요. 9월 22일부터 25일까지 나흘 동안 들어온 AI 다섯 개(빠른 판정, 이미지 생성, 영상 생성, 구글 Gemini API, 로컬 임베딩)는 모두 어댑터와 같은 저장 기록(커밋)에 자기 차선 설정을 갖고 들어왔어요. 그중 두 개의 설정 옆에는 이 사고를 막으려는 것이라는 메모도 붙어 있어요.
솔직히 적어 둘 것도 있어요. 설정이 없는 AI가 기본값으로 조용히 떨어지는 동작 자체는 지금도 남아 있어요. 설정이 빠진 AI를 등록 단계에서 아예 거절하거나 크게 경고하는 장치는 아직 없고, 지금은 안내 문서의 경고와 이 AI에 대한 검사가 막고 있어요.
이 사고에서 남긴 교훈은 두 가지예요.
- 조용한 기본값은 위험하다 — 많은 경우에 무난한 값이 어떤 AI에게는 치명적인 값이 돼요. 설정이 없으면 조용히 넘어가기보다 시끄럽게 실패하는 편이 원인을 찾기 쉬워요
- 실패 안내는 원인을 정확히 말해야 한다 — 붐빔을 고장처럼 알리면, 사람은 고장을 고치려고 붐빔을 더 키워요. 안내를 따랐을 때 무슨 일이 생기는지까지 따져 봐야 해요
정리
① 새로 붙인 명령어 도구 AI가 ‘연결 성공’인데 호출은 전부 실패했어요. 원인은 AI가 아니라 교통정리 칸에 빠진 차선 설정 한 줄이었고, 오류 없이 전체 기본값(차선 1개·줄에서 60초)으로 떨어져 1분 가까이 걸리는 AI 뒤의 호출이 줄에서 쫓겨났어요 ② ‘연결 확인을 다시 하라’는 안내가 차선을 또 붙잡는 고리를 만들었어요. 전용 차선, 연결 확인 우선, ‘혼잡’이라는 솔직한 안내, 차선 1개 → 3개로 고쳤어요 ③ 어댑터만 보는 시험은 조립된 중계기의 설정을 보지 못했어요. ‘새 AI = 어댑터 파일 + 등록 한 줄’에는 차선 설정이라는 두 번째 줄이 붙었어요 — 다음 편은 “‘저는 Claude예요’라고 말한 다른 AI”입니다
교통정리 칸의 차선과 줄 이야기는 10편에 있어요.
2026년 10월 1일 기준입니다. 제가 만든 중계기의 개발 기록을 바탕으로 썼고, 특정 기업·서비스의 공식 입장이 아닙니다. 차선 수와 시간 같은 숫자는 기본 설정값이라 이후 버전에서 바뀔 수 있고, 걸린 시간은 이 사고의 AI 하나를 잰 값이에요.