터미널에서 코딩 에이전트를 쓰다 보면 결국 한 가지 질문에 도달합니다. "이 에이전트한테 어떤 모델로 일을 시킬 것인가." 저는 평소 쓰던 Claude를, 그것도 이미 결제해둔 Claude Max 구독을 그대로 활용하고 싶었습니다. 새로 API 요금을 내는 게 아니라, 가진 구독을 코딩 에이전트에 물려 쓰는 쪽이요.
그런데 문제가 하나 있었습니다. 코딩 에이전트가 Claude에게 말을 거는 방법이 한 가지가 아니라는 점입니다. 저는 지난 1년 사이에 세 가지 방식을 차례로 거쳤고, 그때마다 "이게 왜 자꾸 안 되지?" 하면서 다음으로 넘어갔습니다. 이 글은 그 세 가지가 각각 무엇이 다른지, 그리고 제가 왜 결국 마지막 방식에 정착했는지를 정리한 기록입니다. 비슷하게 로컬 프록시 도구 때문에 고생하고 계신 분이라면, 갈아타기 전에 한 번 읽어보시길 권합니다.
1막. CLIProxyAPI 잘 되다가 절전만 하면 죽었습니다
처음 쓴 건 CLIProxyAPI였습니다. 이게 무엇이냐면, 제 Claude 로그인 토큰을 감싸서 "API처럼 보이게 만들어 주는 로컬 프록시 서버"입니다. 제 컴퓨터 안에서 작은 서버 하나가 백그라운드로 떠 있고, 코딩 에이전트는 그 서버에 요청을 보냅니다. 그러면 서버가 대신 Claude에게 전달해 주는 구조입니다.
코딩 에이전트 → [로컬 프록시 서버:포트] → Claude평소에는 아무 문제 없이 잘 됐습니다. 발목을 잡은 건 최대절전모드에 진입했다가 깨울 때였습니다. 복귀하자마자 에러가 터졌고, 그것도 매번 그랬습니다.
원인은 지금 와서 보면 분명합니다. 이 도구는 항상 떠 있어야 하는 로컬 데몬(상주 서버)입니다. 포트를 물고 있고, 토큰을 들고 있고, 네트워크 연결(소켓)을 유지하고 있습니다. 그런데 절전에 들어가면 그 상태가 통째로 얼어붙고, 깨어날 때 연결이 깔끔하게 복구되지 않습니다. 상주 프록시형 도구의 고질병이라고 할 수 있습니다. 깨울 때마다 서버를 손봐야 하니 결국 견디지 못하고 갈아탔습니다.
2막. Meridian 더 좋아졌지만, 느렸습니다
다음으로 옮긴 건 Meridian이었습니다. 한마디로 "CLIProxyAPI보다 똑똑한 로컬 프록시"라고 보시면 됩니다. 실제로 저는 CLIProxyAPI가 쓰던 토큰을 그대로 재사용해서 Meridian 프로필을 만들었습니다. 구조 자체는 비슷합니다. 여전히 제 컴퓨터에 서버 하나가 떠 있고(127.0.0.1:3456), 에이전트는 그쪽으로 요청을 보냅니다.
대신 Meridian은 부가 기능이 좋았습니다. 설정 UI가 따로 있어서 시스템 프롬프트를 깎아낸다거나, CLAUDE.md 로딩을 끄고 켜는 식의 세밀한 제어가 됐습니다. "프록시인데 제어판이 달린 버전"이라고 생각하시면 됩니다. 그런데 한 가지가 계속 거슬렸습니다. 느렸습니다.
이유를 뜯어보니 두 가지였습니다. 첫째, 여전히 프록시를 한 단계 더 거칩니다. 에이전트 → 프록시 → Claude로 중간 홉이 하나 끼어 있습니다. 둘째, 유휴 타임아웃(idle timeout)이 300초로 걸려 있었습니다. 한동안 안 쓰면 서버가 "식고", 다시 요청하면 콜드 스타트 탓에 첫 응답이 굼떴습니다. 기능은 분명 좋았지만, 결국 근본 구조는 1막과 같았습니다. 로컬에 상주하는 서버라는 점이요. 절전 문제든 속도 문제든, 끝내 그 서버의 상태에 발목이 잡혔습니다.
3막. claude-bridge 서버를 아예 없앴습니다
마지막으로 도착한 게 claude-bridge입니다. 그리고 여기서 두 가지 문제가 동시에 사라졌습니다. 비결은 발상의 전환이었습니다. 앞의 두 방식이 "바깥에 서버를 띄우고 거기로 요청을 보내는" 구조였다면, claude-bridge는 그 서버를 아예 없앴습니다.
대신 에이전트 안에 Claude를 호출하는 코드(SDK)를 직접 박아 넣었습니다. 별도의 프로세스도, 포트도, systemd 서비스도 없습니다. 에이전트가 자기 안에서 곧장 Claude를 부릅니다.
코딩 에이전트 → (내부 SDK로 곧장) → Claude
구조로 보면 차이가 분명합니다. CLIProxyAPI와 Meridian은 노트북 바깥에 서버를 따로 띄워 가느다란 연결로 이어 주는 방식입니다. 그래서 그 연결(과 서버 상태)이 절전이나 유휴 때 끊기거나 식습니다. 반면 claude-bridge는 노트북 안에 부품을 직접 박아 넣은 셈이라, 끊어질 외부 연결도 식을 서버도 없습니다.
결과는 이렇게 정리됩니다. 절전 에러는 깨질 외부 서버가 없으니 사라졌고, 유휴 콜드 스타트는 식을 데몬이 없으니 사라졌습니다. 속도는 중간 프록시 홉이 없으니 가장 직접적입니다. 1막과 2막에서 저를 괴롭힌 두 문제가, 알고 보니 둘 다 같은 원인(외부 상주 서버)에서 나온 것이었습니다. 그 원인을 제거하니 한 번에 정리됐습니다.
두 번 갈아타고 깨달은 것
처음에는 매번 "이 도구가 별로네" 하면서 갈아탔습니다. CLIProxyAPI가 절전에서 죽으니 별로, Meridian이 느리니 별로. 그런데 세 번째에 와서야 비로소 보였습니다.
절전 에러와 느린 속도는 서로 다른 증상이 아니라, "외부에 상주 서버를 둔다"는 같은 설계에서 나온 두 얼굴이었습니다.
그래서 도구를 또 바꾸는 대신 설계 자체를 바꾸니까(외부 서버 → 내부 SDK) 두 문제가 한꺼번에 사라졌습니다. 같은 결과(Claude 쓰기)를 두고도 어디에 무엇을 상주시키느냐가 안정성과 속도를 가른다는 것, 이게 이번에 제대로 체감한 교훈입니다.
혹시 비슷하게 "로컬 프록시 도구가 자꾸 말썽"이라면, 도구를 바꾸기 전에 한 번 의심해 보시길 권합니다. 문제는 그 도구가 아니라, 바깥에 서버를 띄운다는 구조 자체일 수 있습니다. 지금 저는 claude-bridge에 정착했고, 더 갈아탈 이유를 찾지 못했습니다. 비슷한 고민을 하고 계셨다면 이 글이 한 단계 건너뛰는 데 도움이 되었으면 합니다.