이 글에는 제휴 링크가 없고 OpenAI·앤트로픽과 아무 관계가 없습니다. 제가 직접 만든 중계기의 개발 기록을 바탕으로 썼습니다. 삽화는 GPT 이미지 생성, 도식은 직접 제작했습니다.
AI와 함께 하루 만에 만든 첫 버전 — 짐 풀고, 고치고, 밤에야 눕는 이삿날
이삿날을 떠올려 볼게요. 아침에 짐이 들어오고 상자를 하나씩 엽니다. 꽂아 보니 안 맞는 플러그가 있고, 덜 닫히는 문도 있어요. 하나를 고치면 다음 게 보이고, 그렇게 고치다 보면 어느새 밤이죠. 그래도 잠자리에 누울 때쯤이면 그 집에서 하룻밤은 지낼 수 있게 됩니다.
제 LLM 중계기의 첫날이 꼭 그랬어요. 아침 8시 8분에 첫 버전이 저장됐고, 밤 10시 23분에 v0.1.16이 합쳐지며 하루가 끝났습니다. 그 사이에 저장 기록(커밋)이 54개 쌓였어요. 그리고 그 가운데 절반이 넘는 28개에 AI의 이름이 공동 작성자로 함께 올라 있습니다.
이 글은 LLM 중계기 개발기의 4편입니다. 지난 3편 「‘OpenAI 호환’은 왜 표준 콘센트가 됐나」에서는 중계기가 여는 창구의 형식을 이야기했어요. 오늘은 그 창구를 처음 연 하루의 기록입니다.

결론 요약
- 무엇을 — 아침에 여러 AI를 ‘OpenAI 호환’ 창구 하나 뒤에 세운 첫 버전(v0.1.0)을 만들고, 밤까지 판을 열여섯 번 더 올렸습니다
- 어떻게 — 그날 직접 작업한 기록 28개 모두에 AI 코딩 도우미 Claude가 공동 작성자로 올라 있어요. 사람은 실제 컴퓨터에서 써 보고, 재 보고, 무엇이 중요한지 판단했습니다
- 남긴 것 — 고장 하나를 고칠 때마다 같은 고장을 다시 잡아내는 검사를 하나씩 붙였어요. 첫날에만 6개가 생겼고, 지금도 모두 남아 있습니다
🗓️ 1. 하루를 한 장으로
그날의 기록을 시간 순서로 펼치면 아래와 같아요. 노란 점 하나가 새로 내놓은 판(버전) 하나입니다. 오후 1시 45분부터 5시까지 9개, 저녁 6시 38분부터 밤 10시 23분까지 7개가 올라갔어요.

낱말 세 개만 먼저 짚을게요.
- 커밋(commit) — 작업을 저장하면서 “무엇을 왜 바꿨는지” 메모를 붙여 남기는 기록이에요. 게임의 세이브 포인트와 비슷합니다
- PR 합치기 — 따로 작업한 변경을 본 줄기에 합치는 절차예요. 이날은 대부분의 변경이 이 절차를 거쳤어요
- 판(버전) — 쓰는 사람에게 내놓는 묶음의 번호예요. v0.1.0 다음이 v0.1.1, 그다음이 v0.1.2 식으로 올라갑니다
그날의 저장 기록 54개는 직접 작업한 기록 29개와 PR 합치기 기록 25개로 이뤄져 있습니다.
📦 2. 아침 — 상자를 열다
아침 8시 8분, 첫 버전이 저장됐어요. 저장 메모에 적힌 내용을 쉬운 말로 옮기면 이렇습니다.
- AI마다 연결 방식이 다른데, 같은 약속으로 다룰 수 있게 AI별 어댑터(adapter)를 만들었다 — 5편에서 다룰 ‘같은 어댑터’의 첫 모습이에요
- ‘OpenAI 호환’ 창구를 열어, 연결된 AI들의 모델 목록을 한데 모아 보여 주고 그 형식 그대로 대화를 주고받게 했다
- 관리 화면은 내 컴퓨터에서 AI 모델을 돌리는 프로그램 LM Studio의 화면에서 잘된 점만 빌렸다. 왼쪽에는 연결 목록과 상태, 오른쪽에는 꼭 필요한 입력 칸만
- 로그인 정보는 내 컴퓨터 안에 암호화해 저장하고, 기록(로그)에는 비밀 값을 가려서 남긴다
그리고 실제로 붙여 봤어요. 내 컴퓨터의 LM Studio에서 6개, Codex에서 4개, Claude에서 3개, 모두 13개 모델이 창구 하나의 목록에 나란히 떴습니다. 그중 몇 개에 직접 말을 걸어 답이 돌아오는 것까지 확인했고요.
7분 뒤의 두 번째 기록은 작은 손질이었어요. 연결을 확인하는 시험 호출이 열린 질문을 던지면 답이 길어져서 한 번에 끝나지 않을 수 있었거든요. 그래서 “pong” 한 마디로만 짧게 답하게 바꿨습니다. 탁구공을 쳤을 때 받아치는지만 보는 셈이에요. 9시 35분에는 비밀 값이 담긴 파일이 실수로라도 저장 기록에 섞여 올라가지 않도록, ‘올리지 않을 파일 목록’을 넓혔습니다.
🔧 3. 오전 — 윈도에서 처음 켜 보다
상자를 열었으니 이제 전기를 꽂아 볼 차례였어요. 중계기는 맥에서 만들었지만, 실제로 쓸 컴퓨터는 윈도였습니다. 여기서부터 ‘여기선 되는데 저기선 안 되는’ 고장이 줄줄이 나왔어요.
- 10시 21분 — 켜자마자 꺼짐. 윈도의
D:드라이브 글자를http:같은 주소의 앞머리로 착각한 고장이었어요(20편에서 자세히 다룹니다) - 10시 40분 — 두 컴퓨터가 부품 목록을 서로 고쳐 씀. 맥과 윈도에 깔린 개발 도구(npm)의 버전이 달라서, 한쪽이 부품 목록 파일에 한 줄을 넣으면 다른 쪽이 지우기를 되풀이했어요. 그 바람에 최신 코드를 내려받는 일까지 막혔습니다
- 12시 36분 — 깔려 있는데 ‘미설치’. Codex와 Claude가 분명히 설치돼 있는데 화면에는 ‘미설치’로 떴어요. 윈도에서는 Codex 같은 명령어 도구가
.cmd라는 껍데기 파일로 깔리는데, 중계기가 그 껍데기를 실행하지 못하고 “없다”고 판단한 거예요 - 1시 44분 — 8초 멈춤과 401. 명령창에서는 곧바로 답하는 Codex의 버전 확인이, 중계기 안에서 부르면 8초로 정해 둔 기다림 시간이 다 지나도록 답이 없었어요. 윈도의 명령 해석기(cmd)를 직접 불러 그 안에서 실행하게 바꿔 해결했습니다. 같은 판에서, 로그인을 했는데도 Claude가 401(인증 실패)을 내던 문제도 잡았어요. 컴퓨터 환경 설정에 들어 있던 API 키가 로그인보다 먼저 쓰이고 있었거든요(8편에서 자세히 다룹니다)
오전의 수정은 모두 v0.1.0이라는 번호를 단 채 이어졌고, 1시 44분의 수정까지 묶어 처음으로 번호를 올린 판이 오후 1시 45분의 v0.1.1입니다.
⏱️ 4. 오후 — 판을 아홉 번 올리다
오후에는 판이 빠르게 올라갔어요. 1시 45분 v0.1.1부터 5시 v0.1.9까지, 세 시간 남짓 동안 아홉 판입니다.
가장 오래 붙잡은 건 첫 답이 너무 늦게 오는 문제였어요. v0.1.2부터 v0.1.5까지는 걸리는 시간을 단계별로 재는 장치를 달고, “프로그램을 새로 띄우는 데 드는 시간인가”, “AI가 생각을 너무 많이 하나” 같은 가설을 하나씩 지워 나간 판이에요. 답은 3시 20분의 v0.1.6에서 나왔습니다. 새 대화를 열 때마다 준비 시간이 크게 들었고, 열어 둔 대화를 다시 쓰자 두 번째 호출부터는 몇 초 만에 답이 왔어요. 그래서 연결하자마자 대화를 미리 열어 데워 두는 워밍업(warm-up)을 넣었습니다. 켜 둔 채 쓰는 방식은 6편에서 따로 풀게요.
다만 대화를 다시 쓰면 앞의 내용이 다음 요청에 섞일 수 있어요. 그래서 같은 판에 세 가지를 함께 넣었습니다. 요청마다 필요한 내용을 전부 담아 보내고, 한동안 쓰지 않으면 새 대화로 갈아타고, 손으로 누르는 ‘세션 리셋’ 버튼도 달았어요.
나머지 판도 다 ‘써 보니 필요한 것’이었어요.
- v0.1.7 — 실패하면 ‘HTTP 400’ 한 줄만 남기고 진짜 이유는 버리던 것을, AI 쪽이 보낸 오류 원문을 그대로 전하도록 바꿨어요(18편에서 다룹니다)
- v0.1.8 — 연결은 되는데 끄는 방법이 없었어요. 저장 메모에 제가 한 말이 그대로 남아 있습니다. “방금 Codex를 안 쓰게 하려고 했더니 방법이 없었어.” 그래서 연결 해제, 잠깐 사용 안 함, 모델별 끄기를 한 판에 넣었어요
🌙 5. 저녁~밤 — 짐 정리와 마지막 고장
저녁부터는 이사로 치면 ‘다른 사람이 와서 지내도 되게’ 정리하는 시간이었어요.
- 6시 38분 v0.1.10 — 다른 화면에 다녀오면 시험 호출 결과가 사라지던 것을, 중계기가 결과를 기억해 두도록 바꿨어요
- 7시 9분 v0.1.11 — 설치 과정 없이 압축(zip)만 풀면 바로 실행되는 배포판을 만들었어요. 지울 때는 폴더만 지우면 되고, 설정은 다른 곳에 보관돼서 새 판으로 바꿔도 그대로 남아요. 같은 판에서 ‘두 번 켜면 꺼지던’ 문제도 고쳤습니다. 먼저 켜 둔 중계기가 자리를 차지하고 있으면 새로 켠 쪽이 오류를 내고 죽었는데, 이제는 이미 켜져 있는 쪽 화면을 열어 줘요. 예제 코드와 작은 데모 채팅 앱도 이때 들어갔고요
- 8시 54분 v0.1.13 — LM Studio 주소 같은 기본값은 입력 칸에 미리 채워 두고, “설정 파일(.env)을 직접 열어 고치세요”라는 안내가 문서나 화면에 남아 있으면 실패하는 검사를 붙였어요. 로그인 정보는 화면에서 넣고 암호화해 보관한다는 원칙을 검사로 굳힌 거죠
- 9시 14분 v0.1.14 — 앱 안에 ‘개발자’ 탭을 만들었어요. 지금 연결된 모델과 주소가 이미 채워진 예제 코드(cURL·Python·Node·C#)를 복사해 붙이면 그대로 돌아갑니다
- 10시 4분 v0.1.15 — 중계기를 꺼도 뒤에서 살아남은 프로세스(좀비)가 다음 실행을 막던 문제를 고쳤어요(21편에서 다룹니다)
- 10시 22분 v0.1.16 — 압축 배포판에서만 Claude가 연결되지 않았어요. 맥에서 윈도용 압축 파일을 만들다 보니, 윈도용 부품 대신 맥용 부품이 들어가 있었던 거예요. 이미 깔려 있는 Claude 명령어 도구를 쓰도록 바꿨더니, 덤으로 압축 파일도 180MB에서 113MB로 줄었습니다

참고로 그다음 판인 v0.1.17은 날짜를 넘긴 새벽 1시 9분에 올라갔어요. 이삿날 밤은 생각보다 길었던 셈입니다.
🤝 6. AI와 짝으로 일한 기록 — 고칠 때마다 검사 하나
그날의 저장 기록 54개를 나눠 보면 이렇습니다.
- 직접 작업한 기록 29개 — 그중 저장소를 만들 때 생긴 두 줄짜리 첫 기록을 빼면 28개
- PR 합치기 기록 25개
작업 기록 28개에는 하나도 빠짐없이 ‘Co-Authored-By’(공동 작성자) 꼬리표로 Claude가 올라 있어요. 아침의 두 건에는 Claude Fable 5, 나머지 26건에는 Claude Opus 4.8이라는 모델 이름이 적혀 있습니다. Codex는 이날 공동 작성자가 아니라, 중계기에 연결되는 쪽이었고요.

역할은 저장 메모에 그대로 드러나 있어요.
- AI(Claude) — 공동 작성자로 올라 있는 기록들의 메모에는 무엇이 왜 고장 났고, 어떻게 고쳤고, 어떻게 확인했는지가 길게 적혀 있어요
- 사람(저) — 윈도 컴퓨터에서 실제로 써 보고 증상을 알려 주고, 직접 시간을 재고, 무엇이 치명적인지 짚었어요. 메모에도 “사용자가 잰 값으로 결론이 났다”, “사용자가 명령어 도구를 직접 실행해 봤다” 같은 문장이 남아 있습니다. PR 합치기 25건은 제 계정으로 기록돼 있고요
그리고 첫날부터 습관이 하나 생겼어요. 고장 하나를 고치면, 같은 고장을 다시 잡아내는 검사를 하나 붙인다.
| 시각 | 고친 고장 | 붙인 검사 |
|---|---|---|
| 10:21 | 윈도 드라이브 글자를 주소로 착각 | 파일 위치를 주소 형식으로 바꾸지 않고 넘기는 코드가 있으면 실패 |
| 10:40 | 두 컴퓨터가 부품 목록을 서로 고쳐 씀 | 목록 파일에 문제의 한 줄이 다시 생기면 실패 |
| 12:36 | 윈도에서 명령어 도구를 못 찾음 | 정해 둔 실행 방법을 거치지 않고 프로그램을 띄우면 실패 |
| 20:54 | (원칙) 설정 파일을 직접 고치라는 안내 | 그런 안내가 문서·화면에 남아 있으면 실패 |
| 22:04 | 끈 뒤에도 남은 프로세스 | 프로세스를 실제로 띄웠다 끄고, 정말 사라졌는지 확인 |
| 22:22 | 압축판에서 Claude 부품 누락 | 배포판에 그 컴퓨터용 부품이 들어 있는지 확인 |
이 검사들은 시험을 돌릴 때마다 먼저 실행되도록 묶였고, 시험 항목(테스트)도 하루 사이에 0개에서 48개로 늘었어요. 첫날 생긴 검사 6개는 11주가 지난 지금도 하나도 지워지지 않고 남아 있습니다. 검사를 지우지 않는 원칙은 31편에서 다시 이야기할게요.
정리
① 첫날 아침 여러 AI를 ‘OpenAI 호환’ 창구 하나 뒤에 세운 첫 버전이 나왔고, 밤까지 판을 열여섯 번 더 올렸어요 ② 그날 작업 기록 28개 모두에 AI(Claude)가 공동 작성자로 올라 있어요. 사람은 실제 컴퓨터에서 써 보고, 재 보고, 판단했어요 ③ 고장 하나에 검사 하나 — 첫날 생긴 검사 6개는 지금도 남아 있어요
다음 편부터는 2부가 시작됩니다. 2부의 주제는 ‘여러 AI를 한 줄로’예요. 5편 「AI마다 다른 플러그를 같은 어댑터로」에서는 연결 방식이 제각각인 AI들을 한 가지 약속으로 묶는 어댑터 이야기를 할게요.
2026년 10월 1일 기준입니다. 제가 만든 중계기의 개발 기록(저장 기록의 시각과 메모)을 바탕으로 썼고, 특정 기업·서비스의 공식 입장이 아닙니다.