LLM 중계기 개발기 · 1부 왜 만들었나 · 2부 여러 AI를 한 줄로 · 3부 교통정리 · 4부 AI가 이상하게 굴 때 · 5부 만들고 나서가 더 어렵다 · 6부 중계기 위에서, 그리고 회고 — 부별 목차 →
- LLM 게이트웨이를 직접 만든 이유, 퇴근하면 노는 AI 구독 (LLM 중계기 개발기)
매달 결제하는 Codex와 Claude는 내가 채팅창 앞에 앉아 있을 때만 일합니다. 웹·앱·터미널·편집기 플러그인이라는 서로 다른 껍데기에 갇혀 있기 때문이에요. 여러 AI를 주소 하나 뒤에 세워 내 프로그램 어디서든 골라 쓰거나 동시에 쓰게 해 주는 'LLM 중계기'를 직접 만든 이야기의 첫 편. 왜 만들었는지, 처음에 던진 세 가지 질문, 중계기 전과 후에 연결선이 어떻게 달라지는지를 비개발자 눈높이로 정리했습니다.
- LLM 게이트웨이 구조, 질문 하나가 지나가는 네 칸과 두 창구 (LLM 중계기 개발기)
여행용 멀티 어댑터를 열어 보면 꽂는 구멍, 모양을 바꾸는 부품, 과부하를 막는 장치가 따로 있습니다. 제가 만든 LLM 중계기도 안을 열어 보면 칸이 나뉘어 있어요. 프로그램이 보낸 질문 하나가 창구 → 교통정리 → 어댑터를 지나 AI에 닿고 답이 조금씩 흘러 돌아오는 길, 사람용 관리 화면과 프로그램용 API라는 두 창구, 요청마다 남는 기록(토큰·첫 글자까지 걸린 시간·끝난 이유), 그리고 처음부터 지키는 세 가지 안전 기본값을 비개발자 눈높이로 정리했습니다.
- OpenAI 호환 API 뜻, 표준이 된 이유와 빈틈 4가지 (LLM 중계기 개발기)
AI 도구 설명에 자주 보이는 'OpenAI 호환'은 OpenAI의 AI를 쓴다는 뜻이 아니라, OpenAI가 정한 대화 요청의 모양을 따른다는 뜻입니다. 이 모양이 널리 쓰이면서 LM Studio 같은 프로그램도 같은 모양으로 창구를 열고, 제가 만든 LLM 중계기도 이 모양 덕분에 주소 한 줄로 어떤 프로그램이든 받게 됐어요. 그런데 '호환'인데도 끝난 이유, 생각 과정, 빈 도구 목록, 거절 이유에서 AI마다 조금씩 달라 하나씩 맞춰야 했습니다. 그 이득과 한계를 비개발자 눈높이로 정리했습니다.
- AI 페어 프로그래밍, 하루 만에 첫 버전을 만든 이삿날 기록 (LLM 중계기 개발기)
LLM 중계기의 첫날은 이삿날 같았습니다. 아침 8시에 여러 AI를 'OpenAI 호환' 창구 하나 뒤에 세운 첫 버전이 나왔고, 윈도에서 처음 켜 보자 고장이 줄줄이 나왔고, 밤 10시가 넘어서야 v0.1.16으로 하루를 마감했어요. 그날 쌓인 저장 기록을 시간 순서로 펼쳐, AI 코딩 도우미와 짝을 이뤄 작은 판을 여러 번 올린 방법과 '고장 하나에 검사 하나'라는 습관이 생긴 과정을 비개발자 눈높이로 정리했습니다.
- 어댑터 패턴, AI마다 다른 플러그를 한 창구로 묶는 법 (LLM 중계기 개발기)
어떤 AI는 웹 주소로, 어떤 AI는 내 컴퓨터의 명령어 도구로, 또 어떤 AI는 로컬 서버로 불러야 합니다. 플러그 모양이 다 다른 셈이에요. 제가 만든 LLM 중계기는 AI마다 작은 어댑터를 하나씩 끼우고, 모든 어댑터가 확인·목록·특성·대화라는 네 가지 약속을 같은 모양으로 지키게 했습니다. 그 덕분에 바깥 프로그램은 메뉴판 한 장만 보면 되고, 새 AI는 어댑터 파일 하나와 등록 한 줄로 들어옵니다. 첫 버전 닷새 뒤 NVIDIA를 붙인 날의 기록까지 비개발자 눈높이로 정리했습니다.
- 세션 재사용과 워밍업, AI를 새로 켤까 켜 둔 채 쓸까 (LLM 중계기 개발기)
Codex와 Claude의 명령어 도구는 내 컴퓨터에서 켜야 대답하는 프로그램이라, 중계기는 요청마다 새로 켤지 켜 둔 채 다시 쓸지를 정해야 했습니다. 콜택시와 셔틀버스에 빗대어 두 방식의 속도·기억 섞임·메모리·정리 부담을 비교하고, 중계기가 Codex(앱 서버 하나에 요청마다 새 대화방)와 Claude(프로그램별 세션 최대 6개, 5분 쉬면 정리)를 어떻게 다루는지 비개발자 눈높이로 정리했습니다.
- CLAUDE.md·AGENTS.md가 질문마다 실린 사고와 빈 폴더 (LLM 중계기 개발기)
Codex와 Claude의 명령어 도구는 켜진 폴더의 안내문과 기억을 먼저 읽고 일을 시작합니다. 코딩할 때는 고마운 기능인데, 제가 만든 중계기가 이 AI들을 자기 폴더에서 켜는 바람에 평범한 채팅 질문에도 중계기 개발 메모가 덤으로 실렸어요. 같은 질문인데 켠 폴더에 따라 답이 달라진 증상, 원인, 아무것도 없는 전용 폴더로 자리를 옮긴 해결, 그리고 '채팅은 빈 책상, 일은 내가 고른 폴더'라는 규칙을 비개발자 눈높이로 정리했습니다.
- Claude 401 오류, 로그인했는데 옛 API 키가 먼저 쓰인 이유 (LLM 중계기 개발기)
Claude 명령어 도구에 로그인해 둔 컴퓨터에서, 중계기가 Claude를 부르면 401(인증 실패)이 돌아왔습니다. 원인은 컴퓨터 전체에 붙어 있는 설정인 환경 변수에 남아 있던 API 키였어요. Claude가 로그인보다 그 키를 먼저 썼거든요. 환경 변수가 무엇인지, 중계기가 Claude에게 건네는 설정 사본에서 그 키만 지워 로그인을 쓰게 한 방법, 어떤 열쇠를 썼는지 알려 주는 안내와 401·403·429의 차이를 비개발자 눈높이로 정리했습니다.
- LLM 모델 스펙 비교, 에너지 라벨처럼 카드로 만든 이유 (LLM 중계기 개발기)
냉장고를 고를 때는 옆면의 라벨을 나란히 놓고 비교하죠. 제가 만든 LLM 중계기의 메뉴판에는 처음에 모델 이름만 있어서, 쓰는 쪽 프로그램은 모델마다 한 번에 얼마나 읽는지, '끝났다'는 표시를 믿어도 되는지, 생각하느라 답 분량을 얼마나 쓰는지 알 수 없었어요. 이걸 프로그램이 읽는 스펙 카드로 내놓은 이야기입니다. 글을 잘게만 쪼개 보내던 도구 때문에 카드가 생긴 날, 양식이 어긋나 빈칸만 보이던 카드를 같은 날 아침에 고친 일, 그리고 '모르면 비워 둔다'는 규칙까지 비개발자 눈높이로 정리했습니다.
- AI 동시 요청 제한과 429, 중계기에 톨게이트를 세운 이유 (LLM 중계기 개발기)
AI마다 한꺼번에 받을 수 있는 질문 수가 정해져 있어서, 들어오는 대로 넘기기만 하는 중계기는 금방 막히거나 '너무 많다(429)'는 거절을 받습니다. 제가 만든 LLM 중계기 한가운데에는 그래서 요금소 같은 교통정리 칸이 있어요. AI별·모델별 차선(Codex 3, Claude 3, NVIDIA 4, LM Studio 1), 길이와 시간이 정해진 대기 줄, 전체 상한(동시 10건·줄 포함 16건), 꽉 찼을 때 매달아 두지 않고 이유와 다시 올 시간을 알려 주는 방식, 사람이 기다리는 요청을 먼저 들여보내는 순서까지 비개발자 눈높이로 정리했습니다.
- AI 요청 취소, '그만' 신호를 끝까지 전해야 하는 이유 (LLM 중계기 개발기)
고객은 전화를 끊었는데 상담원의 수화기에는 그 소식이 오지 않으면, 상담원은 빈 수화기를 든 채 '통화 중'으로 남고 다음 고객은 연결되지 못합니다. 제가 만든 LLM 중계기에도 같은 함정이 있어요. 프로그램이 연결을 끊었을 때 '그만' 신호를 창구 → 줄 → 어댑터 → AI까지 끝까지 전해야 하는 이유, 신호가 한 곳에서 끊기면 AI 차선이 영원히 막히는 구조, 내 컴퓨터에서 돌리는 AI(LM Studio)의 '유령 줄', 15초 안부 신호와 느린 받는 쪽 처리, 그리고 '그만두는 법'을 먼저 설계하라는 교훈을 비개발자 눈높이로 정리했습니다.
- RPM·TPM 뜻과 429, 거절당하기 전에 간격을 두는 페이서 (LLM 중계기 개발기)
AI 서비스에는 '동시에 몇 건' 말고도 '1분에 몇 번(RPM)', '1분에 토큰 몇 개(TPM)'라는 한도가 있습니다. 넘으면 429라는 거절 번호와 함께 '이만큼 뒤에 다시 오라(Retry-After)'는 안내가 오죠. 제가 만든 LLM 중계기에는 거절당하고 다시 보내는 대신 처음부터 간격을 두고 보내는 '페이서'가 있어요. 최근 1분의 기록을 보며 요청 시작 시각을 고르게 띄우는 방법, 토큰을 미리 잡아 두고 끝나면 고쳐 적는 장부, NVIDIA에는 페이서를 붙이지 않은 이유, 그리고 Gemini API로 본 '잠깐 붐빔'과 '오늘 몫을 다 씀'의 차이를 비개발자 눈높이로 정리했습니다.
- 설정 누락 장애, '연결 성공'인데 호출이 전멸한 이유 (LLM 중계기 개발기)
새로 붙인 명령어 도구 AI 하나가 '연결 성공'으로 떴는데, 그 뒤 호출은 전부 실패했습니다. AI는 멀쩡했어요. 원인은 중계기의 교통정리 칸에 이 AI의 차선 설정 한 줄이 빠져, 오류 없이 전체 기본값(차선 1개·줄에서 60초)으로 떨어진 것이었습니다. 한 번 부르는 데 1분 가까이 걸리는 AI에게 60초 줄은 너무 짧았고, '연결 확인을 다시 하라'는 실패 안내가 줄을 더 막는 고리까지 만들었어요. 조용한 기본값의 함정, 스스로 불어나는 대기 고리, 부품 시험은 통과했는데 조립품에서 터진 이유, 그리고 '새 AI는 등록 한 줄'이라는 규칙에 붙은 두 번째 줄을 비개발자 눈높이로 정리했습니다.
- AI 대화 섞임, 다른 AI가 '저는 Claude예요'라고 한 이유 (LLM 중계기 개발기)
켜 둔 AI 세션 하나를 서로 다른 두 프로그램이 같이 쓰면, 한 프로그램의 대화가 다른 프로그램 요청을 받는 AI의 기억에 남을 수 있습니다. 게다가 대화를 한 덩어리로 합칠 때 '누가 한 말인지' 이름표를 빼 버리자, AI가 다른 AI의 답('저는 Claude입니다')을 자기 말로 받아들이기도 했어요. 공용 메모장을 같이 쓴 두 팀에 빗대어, 두 증상이 모두 '누가'를 잃어버린 데서 왔다는 원인, 프로그램 이름표·프로그램별 세션·요청마다 새 대화방·말마다 이름표라는 해결, '세션은 속도를 위한 준비물'이라는 원칙을 비개발자 눈높이로 정리했습니다.
- 추론 모델 max_tokens, 생각만 하다 답 0자로 끝난 이유 (LLM 중계기 개발기)
답하기 전에 속으로 생각하는 AI는 그 생각도 '답에 쓸 수 있는 글자 예산'에서 꺼내 씁니다. 제가 만든 LLM 중계기에서 생각형 AI 하나가 답 예산 8,192토큰을 생각에 전부 써 버려, 생각 33,748자에 답 0자로 돌아온 날이 있었어요. 원인을 따라가 보니 예산은 조심스럽게 작게 잡혀 있었고, 생각이 얼마나 길어질지는 미리 적어 둔 표로 알 수 없었습니다. 실제 생각 분량을 배우고, 답 몫 위에 생각 여유분을 얹고, 그래도 비면 예산을 두 배로 늘려 한 번 더 시도하고, 답에 섞여 오는 생각 꼬리표를 떼어 내는 4겹 방어를 비개발자 눈높이로 정리했습니다.
- AI 답변 잘림, finish_reason ‘다 했음’을 믿기 전에 (LLM 중계기 개발기)
AI의 답장 끝에는 왜 멈췄는지를 적는 '끝난 이유' 칸이 있습니다. 여기에 '다 했음'이 찍히면 프로그램은 잘린 답도 완성본으로 저장해요. 제가 만든 LLM 중계기가 이 칸을 바로잡기까지의 경위 — 둘째 날의 첫 수정, 34분 뒤의 두 번째 수정, 일주일 뒤에야 드러난 '말 없는 AI' 문제 — 와 AI마다 다른 '끝'의 말투, 직접 재서 추정하는 방법, 스펙 카드의 '믿어도 되는지' 표시, 쓰는 쪽 프로그램의 점검표를 비개발자 눈높이로 정리했습니다.
- Claude 로그인 만료·한도 소진, 성공 응답 속에 숨은 실패 (LLM 중계기 개발기)
Claude가 로그인 만료와 사용 한도 소진을 '성공' 결과에 담아 보낸 날이 두 번 있었습니다. 제가 만든 LLM 중계기는 그 안내문을 진짜 답처럼 넘겼고, 중계기를 쓰던 도구는 엉뚱하게 '답 형식이 틀렸다'며 실패했어요. 중계기가 성공 답을 넘기기 전에 열어 보고 로그인 만료는 인증 실패(401) 갈래로, 한도 소진은 429와 '10분 뒤 다시'로 바꿔 돌려주게 된 경위, 글자를 읽어 판단하는 검사의 약점과 그 울타리(Claude에게만, 성공 답에만, 한도 문구는 600자 이하에만)를 비개발자 눈높이로 정리했습니다.
- 에러 메시지 로그, 자르면 안 되는 이유와 남기는 법 (LLM 중계기 개발기)
AI가 요청을 거절하면 이유를 글로 적어 보냅니다. 그런데 제가 만든 LLM 중계기는 개발 첫 이틀 동안 그 이유를 세 번이나 잃어버렸어요. 화면에 200자만 보여 준 날, 양식이 아니라며 원문을 통째로 버리고 'HTTP 400'만 남긴 날, 기록에 160자만 남겨 '더 새 버전이 필요하다'는 안내가 잘린 날. 세 번의 경위와 그 뒤 정한 '오류 원문은 자르지 않는다'는 규칙, 자르는 코드가 다시 들어오면 실패하는 자동 검사를 비개발자 눈높이로 정리했습니다.
- 한국어 토큰 수, 영어보다 2배 넘게 드는 이유와 긴 문서 나누기 (LLM 중계기 개발기)
AI는 글을 글자가 아니라 토큰이라는 상자로 셉니다. 제가 만든 LLM 중계기의 설명서에 적어 둔 어림값으로 영어는 약 3.0자에 1토큰, 한국어와 기호는 약 1.1자에 1토큰이라, 같은 3,000자라도 한국어는 영어의 2.7배쯤 되는 토큰을 씁니다. 글자 수로 잡은 '안전해 보이던' 분량이 실제로는 두 배가 넘는 토큰이어서 번번이 넘쳤던 일, 그 일로 중계기 첫날 설명서에 남은 '여기서 크게 데였다'는 절, 중계기 안에서도 용도마다 다르게 쓰는 세 가지 자, 그리고 긴 한국어 문서를 AI에 나눠 줄 때의 계산법을 비개발자 눈높이로 정리했습니다.
- 맥에서 되는데 윈도에서 안 되는 이유, D: 두 글자의 함정 (LLM 중계기 개발기)
맥에서 만들어 잘 돌던 LLM 중계기가 실제로 쓸 윈도 컴퓨터에서는 켜자마자 꺼졌습니다. 윈도 파일 위치 맨 앞의 'D:'를 'https:' 같은 인터넷 주소의 앞머리로 읽었기 때문이에요. 파일 위치와 주소가 어떻게 다른지, 왜 맥에서는 몰랐는지, 같은 날 이어진 '같은 코드, 다른 컴퓨터' 고장 세 가지(부품 목록 다툼·'미설치' 오판·맥에서 싼 윈도용 짐)와 그때 붙인 검사, 그리고 '쓸 컴퓨터에서 시험한다'는 교훈을 비개발자 눈높이로 정리했습니다.
- 좀비 프로세스, 껐는데 남은 프로그램이 다음 실행을 막을 때 (LLM 중계기 개발기)
LLM 중계기를 껐는데, 중계기가 띄워 둔 Codex 앱 서버가 뒤에 혼자 살아남아 문 번호(포트)를 붙들고 있었습니다. 다음 실행은 실패했고, 안내 창은 작업 관리자를 열라고 했어요. 부모·자식·고아 프로세스가 무엇인지, 첫날 밤 '고쳤다'던 기록이 다음 날 '틀렸다'로 바뀐 이유(창 X 닫기는 정리 코드를 부르지 않는 다른 길이었다), 그 뒤에 더한 안전망까지 비개발자 눈높이로 정리했습니다.
- 무한 로딩 원인, '준비 중'에서 멈춘 화면을 고친 기록 (LLM 중계기 개발기)
AI 연결도 끝났고 채팅도 잘 되는데, LLM 중계기 화면의 준비 표시는 '워밍업 중'에서 영영 넘어가지 않았습니다. 첫 번째는 준비에 실패한 모델이 갈 '끝'이 없어서, 두 번째는 아무도 데우지 않는 모델까지 '워밍업 중'이라고 보고해서였어요. 카페 주문 번호판에 빗대어 상태와 끝 상태가 무엇인지, 실패와 시간 초과도 끝으로 쳐야 하는 이유, 진행 중인 일이 없으면 '준비 전'이라고 정직하게 말해야 하는 이유, 같은 병이 업데이트 '적용 중'에서 다시 나타난 이야기까지 비개발자 눈높이로 정리했습니다.
- 자동 업데이트 롤백, 업데이트했는데 버전이 그대로인 이유 (LLM 중계기 개발기)
LLM 중계기의 자동 업데이트가 어떤 컴퓨터에서는 하고 나도 버전이 그대로였습니다. 옛 판이 남긴 업데이트 도우미가 새 판이 30초 안에 대답하는지 지켜봤는데, 새 판은 처음 켜질 때 파일 5천8백여 개를 푸느라 몇 분이 걸렸고, 도우미는 이를 실패로 판정해 조용히 되돌렸거든요. 판정하는 쪽이 옛 판이라 고친 판조차 도착하지 못한 '부트스트랩' 함정, 판정 시간을 5분으로 늘리고 되돌림을 알리게 한 응급 처치, 파일을 다 펼쳐 까는 설치 프로그램으로 갈아탄 결말을 비개발자 눈높이로 정리했습니다.
- 진행률 표시, 조용한 업데이트가 멈춘 줄 알았던 이유 (LLM 중계기 개발기)
LLM 중계기의 자동 업데이트는 트레이 아이콘이 사라진 뒤 설치 프로그램이 창 하나 없이 돌았습니다. 몇 초, 어떤 컴퓨터에서는 수십 초 동안 아무것도 보이지 않자 '중단된 줄 알았다'는 피드백이 돌아왔어요. 설치 프로그램을 '아주 조용히'에서 '조용히'로 바꿔 진행률 바 창 하나를 띄운 이야기, 알림은 숨겨질 수 있지만 창은 남는다는 점, 고친 효과가 다음 업데이트부터 나타나는 함정, 그 전에 연결 확인 카드·멈춘 스피너·트레이 아이콘에서 배운 같은 교훈까지 비개발자 눈높이로 정리했습니다.
- Electron 앱이 무거운 이유, 329MB를 61MB로 줄인 기록 (LLM 중계기 개발기)
화면 구석의 작은 앱이던 LLM 중계기는 앱 껍데기(Electron) 안에 웹 브라우저 한 벌을 통째로 싣고 다녔습니다. 재 보니 329MB 가운데 274MB가 껍데기 몫이었어요. 서버는 다시 짜지 않고 브라우저만 걷어내 이미 깔린 브라우저의 '앱 모드'를 빌려 쓰고(61MB), 이틀 뒤 작은 트레이 프로그램으로 바꿔 윈도용 압축 파일을 112MB에서 41.6MB로 줄인 이야기. 브라우저를 빌려 쓰는 값, 그리고 끄는 방식과 검사를 그대로 옮긴 이유까지 비개발자 눈높이로 정리했습니다.
- 여러 AI 답 비교하는 병렬 채팅, 429 거절이 끝나지 않던 이유 (LLM 중계기 개발기)
제가 만든 LLM 중계기의 관리 화면에는 질문 하나를 여러 AI에게 동시에 보내고 답을 카드로 나란히 받아 보는 '병렬 채팅'이 있습니다. 답을 나란히 놓으면 비교가 쉽고, 엇갈리는 답이 다시 확인할 곳을 알려 주죠. 그런데 Codex 모델 네 개를 고르면, 중계기가 한가할 때도 '잠깐 붐빈다(429), 1초 뒤 다시'라는 거절만 돌아왔어요. 동시에 3개까지만 달리는 Codex에 '다 같이 아니면 아무도'인 묶음 요청을 보냈기 때문입니다. 모델마다 따로 보내 넷째는 줄을 서게 한 해결, 그리고 '잠깐 붐빔(429)'과 '이대로는 불가능(400)'을 나눠 알려야 끝없는 재시도를 막을 수 있는 이유를 비개발자 눈높이로 정리했습니다.
- AI 코드리뷰, 여러 AI에게 나눠 맡기고 교차 검증하는 법 (LLM 중계기 개발기)
노래 경연의 심사위원은 혼자 점수를 매기지 않죠. 여럿이 따로 채점한 뒤 채점표를 맞춰 봅니다. 제가 만든 LLM 중계기를 처음부터 써 온 '코드 리뷰 대결 도구'도 그렇게 일해요. 바뀐 코드를 조각으로 나누고, 사용자 치명 문제·실행 중 멈춤·호환성·동시성 같은 일곱 가지 관점을 여러 AI에게 나눠 맡긴 뒤, 같은 지적을 몇이 찾았는지와 다른 AI가 동의하는지로 믿을 만한 정도를 매겨 한 장의 보고서로 합칩니다. 보스·파이터·장비로 그린 게임 같은 화면 뒤의 구조, 걸러 내던 심판이 표시하는 심판으로 바뀐 이유, 그리고 중계기가 맡은 일 — 한 창구, 같은 출발선의 묶음 요청, 스펙 카드로 정하는 조각 크기 — 를 비개발자 눈높이로 정리했습니다.
- AI 코드 리뷰 컨텍스트 주입, 지식을 넣었더니 지적이 0건 (LLM 중계기 개발기)
AI 코드 리뷰어에게 프로젝트 지식을 더 넣어 주면 문제를 더 잘 찾아낼까요? 같은 코드 변경과 같은 AI로 넣어 주는 자료만 바꿔 재 보니 반대였습니다. 지식 카드를 넣은 구성은 심판이 인정한 지적이 3건에서 0건으로 줄었고, 틀린 지적이 늘어난 게 아니라 AI가 아예 입을 다물었어요. 주변 코드는 입력만 늘고 결과는 그대로였고, 지식이 가장 필요해 보이는 관점 하나에만 좁혀 넣어도 손해였습니다. 컨텍스트 주입, 정답셋, 심판 검증이 무엇인지와 '좋아진다는 걸 증명하기 전엔 넣지 않는다'는 규칙을 비개발자 눈높이로 정리했습니다.
- AI 분류 판정이 느린 이유, 출력 토큰을 절반으로 줄인 방법 (LLM 중계기 개발기)
제가 만든 LLM 중계기에는 답이 정해진 보기 안에서만 나오는 질문(분류, 갈림길, 다음 행동 고르기)만 받는 '판정 창구'가 있습니다. 고르기 전용 AI인 Jev가 없을 때는 글을 쓰는 보통 AI가 같은 답안 형식을 흉내 내는데, 첫 흉내는 AI에게 보기마다 확률을 하나씩 다 쓰게 했어요. 글 쓰는 AI는 한 글자씩 쓰니 쓸 게 많을수록 느리고, 그 확률은 애초에 '믿지 말라'고 표시해 둔 숫자였죠. AI는 고른 답과 확신도 하나만 쓰고 나머지 확률은 중계기가 채우게 바꾼 해결, 같은 AI라면 창구만 바꿔서는 빨라지지 않는 이유, 공정한 A/B 비교를 위해 데모를 고친 이야기를 비개발자 눈높이로 정리했습니다.
- 코덱스·클로드 코드 승인 요청, AI가 허락을 기다리다 멈춘 이유 (LLM 중계기 개발기)
Claude Code와 Codex 같은 코딩 AI는 명령을 실행하거나 파일을 고치기 전에 사람에게 '해도 될까요?'라고 묻습니다. 제가 만든 LLM 중계기에 이 AI들이 내 폴더에서 일하게 하는 '작업 폴더 모드'를 붙였더니, 중계기가 그 질문을 아무에게도 전하지 않고 조용히 버리는 바람에 AI가 대답을 기다리며 멈췄어요. 5분 뒤 시간 초과로 끝난 증상, 원인, 어떤 질문에도 반드시 답하게 한 첫 고침, 사람 화면에 승인 벨을 울리는 두 번째 고침, 폴더마다 고르는 세 가지 규칙(물어보기·자동 허용·거절), 그리고 AI에게 파일을 맡길 때의 안전장치를 비개발자 눈높이로 정리했습니다.
- 회귀 테스트와 품질 게이트, 검사를 지우지 않고 빠르게 돌리는 법 (LLM 중계기 개발기)
LLM 중계기는 고장 하나를 고칠 때마다 같은 고장을 다시 잡는 자동 검사를 하나씩 세웠습니다. 첫 버전이 나오고 이틀이 채 안 돼 시험을 돌릴 때마다 먼저 도는 검사·시험이 13개가 됐고, 한 번 돌리는 데 18초쯤 걸리자 기록은 '매번 18초를 물리면 시험을 안 돌리게 된다'고 적었어요. 하나도 지우지 않고 커밋 전의 빠른 핵심 검사 5종과 새 판 전의 전체 검사로 나눈 이야기, 코드가 옮겨 가면 검사도 옮겨 단 사례, 검사가 정말 무는지 일부러 고장을 넣어 확인하는 방법을 비개발자 눈높이로 정리했습니다.
- 목 테스트 한계, 가짜로 통과해도 스모크 테스트가 필요한 이유 (LLM 중계기 개발기)
LLM 중계기의 자동 시험은 대부분 진짜 AI 대신 흉내만 내는 가짜를 상대로 합니다. 빠르고, 늘 같은 결과가 나오고, 고장을 일부러 만들 수 있어서예요. 그런데 가짜는 내가 아는 만큼만 진짜를 닮습니다. 최신 Codex만 흉내 낸 가짜 탓에 옛 판 Codex의 거절을 몰랐던 날, 개발 폴더에서 띄운 중계기로만 시험해 배포판에서 빠진 변경 이력을 몰랐던 일주일, 그리고 그 뒤에 만든 윈도 실전 점검과 실제 AI 점검까지. '가짜는 매번, 진짜는 내놓기 전에 적어도 한 번'이라는 균형을 비개발자 눈높이로 정리했습니다.
- AI 코딩 도우미 협업 회고, 사람이 판단하고 AI가 만들었다 (LLM 중계기 개발기)
LLM 중계기 개발기의 마지막 편입니다. 7월 13일부터 10월 1일까지 쌓인 저장 기록 394개를 주별로 펼치고, AI 코딩 도우미가 공동 작성자로 이름을 올린 기록이 얼마나 되는지, 시험과 릴리스 노트가 어떻게 늘었는지 세어 봤어요. AI는 코드·시험·릴리스 노트·저장 메모를 썼고, 사람은 무엇을 만들고 뺄지 정하고, AI의 '고쳤다'를 실제 환경에서 확인하고, 직접 재고, 지킬 규칙을 정했다는 것을 기록으로 정리합니다. 1편의 세 질문에 답하고, 아직 계획인 다음 단계와 연재 전체 목차로 마무리해요.
