사내용 AI 도구를 구축 중인가요? Claude 액세스 계층이 코드보다 중요한 이유

당신은 Claude를 사용하는 사내용 도구를 만드는 데 3주를 보냈습니다. 프롬프트 엔지니어링 (Prompt engineering)은 정교합니다. UX (사용자 경험)는 깔끔합니다. 팀원들도 매우 좋아합니다.

그러다 API 비용 청구서가 날아옵니다.

더 최악의 상황은 이렇습니다. 누군가 루프 (Loop)를 실행하여 단 한 오후 만에 월간 예산을 다 써버립니다. 또는 데모 중에 공유 API 키가 속도 제한 (Rate-limited)에 걸립니다. 혹은 사용자가 3명에서 15명으로 늘어나면서, 갑자기 누가 무엇을 소비하고 있는지, 왜 비용이 3배로 뛰었는지, 그리고 그 인턴의 테스트 스크립트가 아직 어딘가에서 실행 중인지 파악해야 하는 상황이 발생합니다.

도구는 작동합니다. 하지만 액세스 계층 (Access layer)은 작동하지 않습니다.

이것은 아무도 쓰지 않는 이야기입니다. 당신의 코드와 Claude API 사이의 인프라 (Infrastructure)가 바로 대부분의 사내 AI 프로젝트가 조용히 무너지는 지점입니다.

아무도 말하지 않는 액세스 계층 문제

Claude를 기반으로 사내용 도구를 구축할 때, 당신은 실제로 두 가지를 구축하고 있는 것입니다:

1. 도구 그 자체 — 당신의 프롬프트 (Prompts), UI (사용자 인터페이스), 비즈니스 로직 (Business logic)
2. 액세스 계층 (Access layer) — 당신의 도구가 Claude와 통신하는 방식, 누가 비용을 지불하는지, 누가 이를 제어하는지, 그리고 문제가 발생했을 때 어떤 일이 일어나는지

대부분의 팀은 95%의 시간을 1번에 할애하고, 2번에 대해서는 무언가 고장 나기 전까지 0%의 시간만 생각합니다.

무엇이 고장 나는지 살펴보겠습니다:

비용 가시성 (Cost Visibility) 제로

Anthropic의 대시보드 (Dashboard)는 총 지출액을 보여줍니다. 그게 전부입니다. 어떤 도구, 어떤 사용자, 어떤 프롬프트 템플릿 (Prompt template)이 예산을 축내고 있는지 볼 수 없습니다. 도구별 제한을 설정할 수 없습니다. 단일 워크플로 (Workflow)가 하루에 50달러를 초과할 때 알림을 보낼 수도 없습니다.

개인 개발자에게는 이 정도면 괜찮습니다. 하지만 5개의 서로 다른 사내용 도구를 운영하는 10명의 팀이라면? 당신은 눈을 가리고 비행하는 것과 같습니다.

최악의 타이밍에 발생하는 속도 제한 (Rate Limits)

Claude API에는 조직당 속도 제한 (Rate limits)이 있습니다. 고객 지원 도구, 코드 리뷰 도구, 콘텐츠 생성기가 모두 하나의 API 키를 공유할 때, 이들은 동일한 속도 제한 풀 (Rate limit pool)을 두고 경쟁하게 됩니다.

그 결과: CEO가 고객에게 AI 기반 보고서 생성기를 데모하고 있는 동안, 지원 팀의 도구가 429 에러 (429 errors)를 내뱉기 시작합니다. 모두가 불만족스러워집니다.

키 관리 (Key Management)는 보안의 악몽입니다

단 하나의 API 키. 4개의 서로 다른 리포지토리 (repos)에 하드코딩되어 있습니다. 6개월 전 Slack DM으로 공유되었습니다. 지난달에 퇴사한 인턴은요? 여전히 그들의 로컬 .env 파일에 그 키를 가지고 있습니다.

이것이 나쁘다는 것을 당신은 알고 있습니다. 또한 당신이 이를 해결하지 못했다는 것도 알고 있습니다.

확장을 위해서는 재설계 (Rearchitecting)가 필요합니다

당신의 첫 번째 내부 도구는 간단한 스크립트였습니다. 이제 당신은 5개의 도구, 3개의 팀, 그리고 계속 늘어나는 비용을 가지고 있습니다. 각 도구는 자신만의 API 키 관리, 자신만의 에러 처리 (error handling), 자신만의 재시도 로직 (retry logic)을 가지고 있습니다. 어떤 도구는 사용량을 기록하지만, 대부분은 그렇지 않습니다.

새로운 도구를 추가한다는 것은 이전 도구에서 보일러플레이트 (boilerplate)를 복사해 오고, 모든 예외 케이스 (edge cases)를 기억했기를 바라는 것을 의미합니다.

적절한 액세스 계층 (Access Layer)의 모습

적절한 액세스 계층은 내부 도구와 Claude API 사이에 위치합니다. 이는 지루하지만 중요한 작업들을 처리하여, 당신의 도구들이 유용성을 제공하는 데 집중할 수 있게 해줍니다.

인증 (Authentication) 및 격리 (Isolation)

각 도구는 자신만의 자격 증명 (credentials)을 가집니다. 각 사용자(또는 팀)가 식별됩니다. 다른 도구에는 영향을 주지 않고 특정 도구에 대한 액세스 권한만 취소할 수 있습니다. 누가 어떤 요청을 하고 있는지 정확히 확인할 수 있습니다.

이것은 편집증이 아니라 기본적인 운영 위생 (operational hygiene)입니다. 무언가 잘못되었을 때 (만약가 아니라 언제든), 당신은 문제가 어디에 있는지 알아야 합니다.

비용 제어 (Cost Controls)

도구별 예산. 사용자별 제한. 일일 상한선. 지출이 임계값을 초과할 때의 알림. 커스텀 미들웨어 (custom middleware)를 작성하지 않고도 "이 실험적 도구는 하루 최대 20달러까지만 사용할 수 있다"라고 말할 수 있는 능력입니다.

이것이 없다면, 당신의 첫 번째로 유행한 내부 도구는 당신의 첫 번째 예산 위기가 될 것입니다.

통합 로깅 (Unified Logging)

모든 요청, 모든 응답, 모든 토큰 수 — 이 모든 것이 한 곳에 모입니다. 5개의 서로 다른 CloudWatch 로그 그룹에 흩어져 있거나, 아무도 확인하는 것을 잊어버리는 애플리케이션 레벨 로깅 (application-level logging)에 파묻혀 있지 않습니다.

CFO가 "왜 지난달 AI 지출이 3배나 늘었습니까?"라고 물었을 때, 당신은 5일이 아니라 5분 만에 대답할 수 있습니다.

재시도 (Retry) 및 장애 조치 (Failover) 로직

Claude의 API는 가끔씩 문제가 발생할 수 있습니다. 훌륭한 액세스 계층 (Access Layer)은 지수 백오프 (Exponential Backoff)를 사용하여 재시도 (Retry)를 처리하고, 속도 제한 (Rate Limit) 구간 동안 요청을 큐 (Queue)에 쌓으며, 기반이 되는 API에 문제가 생기더라도 당신의 도구들이 일관된 동작을 유지할 수 있도록 해줍니다.

이 기능을 모든 도구에 일일이 구축할 수도 있습니다. 아니면 단 한 번, 한 곳에 구축할 수도 있습니다.

이를 해결하기 위한 세 가지 접근 방식

1. 직접 구축하기 (DIY Proxy)

리버스 프록시 (Reverse Proxy)를 실행합니다. Lua를 사용한 Nginx일 수도 있고, Node.js 서비스일 수도 있으며, Python FastAPI 앱일 수도 있습니다. 여기에 인증 (Authentication), 로깅 (Logging), 속도 제한 (Rate Limiting), 비용 추적 (Cost Tracking) 기능을 추가합니다.

장점:

• 완전한 제어권
• 외부 의존성 없음
• 코드의 모든 줄을 완벽히 이해함

단점:

• 이제 당신은 영원히 API 프록시를 유지보수해야 합니다.
• 인증, 로깅, 비용 추적, 속도 제한, 장애 조치 (Failover) — 각각이 하나의 프로젝트입니다.
• 당신의 프록시는 아무도 맡고 싶어 하지 않는 핵심 인프라 (Critical Infrastructure)가 됩니다.
• 새벽 2시에 문제가 발생하면, 그것은 당신의 문제입니다.

실제 비용: 기본적인 것을 구축하는 데 4080시간이 소요됩니다. 유지보수에 월 510시간이 소요됩니다. 문제가 발생하면 더 늘어납니다. 만약 엔지니어링 시간이 시간당 100달러의 가치가 있다면, 초기 비용으로 4,0008,000달러, 연간 유지보수 비용으로 6,00012,000달러가 듭니다.

2. 오픈 소스 게이트웨이 (Open-Source Gateway) 사용

LiteLLM, Portkey, Helicone 등 LLM API 호출을 프록시하기 위한 여러 오픈 소스 옵션이 있습니다. 이들은 로깅과 라우팅 (Routing)의 일부를 처리합니다.

장점:

• 처음부터 만드는 것보다 빠름
• 커뮤니티에서 유지보수함
• 종종 모델 불가지론적 (Model-agnostic)임

단점:

• 여전히 직접 호스팅하고 유지보수해야 함
• 다중 계정 (Multi-account) 지원이 대개 제한적임
• 비용 제어 기능이 기본적이거나 존재하지 않음
• 당신의 로드맵과 일치할 수도, 그렇지 않을 수도 있는 프로젝트에 의존하게 됨

실제 비용: 설정에 1020시간이 소요됩니다. DIY와 마찬가지로 월 510시간의 유지보수 시간이 필요합니다. 여기에 상위 프로젝트의 변경 사항을 추적하는 인지적 부하 (Cognitive Overhead)가 추가됩니다.

3. 관리형 프록시 서비스 (Managed Proxy Service) 사용

ShadoClaw와 같은 서비스가 바로 여기서 역할을 합니다. 무언가를 직접 구축하거나 호스팅하는 대신, 인증(Authentication), 비용 제어(Cost Controls), 로깅(Logging), 그리고 멀티 계정 관리(Multi-account Management)를 처리하는 관리형 프록시(Managed Proxy)로 도구의 방향을 설정하기만 하면 됩니다.

장점:

• 유지 관리할 인프라가 없음
• 별도의 설정 없이 멀티 계정 지원
• 정액제(Flat-rate pricing)로 예측 가능한 비용
• 새벽 2시에 발생하는 문제들을 다른 사람이 해결해 줌

단점:

• 외부 의존성 발생
• 완전히 맞춤화된 솔루션보다 제어권이 낮음
• 월간 비용 발생

실제 비용: 개인용 월 $29, 최대 5개 계정 월 $79, 최대 20개 계정 월 $179. 엔지니어링 시간 및 유지 관리 비용 없음.

솔직히 말씀드리면, ShadoClaw는 Gerus-lab에서 제작하였으며, 저희는 당연히 편향되어 있습니다. 하지만 저희가 자체 내부 도구와 클라이언트 프로젝트를 위해 Claude를 운영하면서 이 글에서 설명한 모든 문제에 직면했기 때문에 이 서비스를 만들었습니다.

모든 것을 바꾸는 계산법

3개의 내부 Claude 도구를 사용하는 5인 팀을 기준으로 수치를 계산해 보겠습니다.

직접 API 사용 (Anthropic):

• 사용량에 따른 가변 비용: 월 $200-600 (변동 폭이 매우 큼)
• 도구별 가시성(Visibility) 없음
• 비용 제어 기능 없음
• 키 관리, 로깅, 모니터링을 위한 엔지니어링 시간: 월 약 8시간
• 시간당 $100 기준: 숨겨진 엔지니어링 비용 월 $800
• 총합: 월 $1,000-1,400

자체 구축 프록시 (DIY Proxy):

• 동일한 API 비용: 월 $200-600
• 프록시 호스팅 비용: 월 $20-50
• 유지 관리 엔지니어링 시간: 월 약 6시간 = $600
• 총합: 월 $820-1,250 (여기에 초기 구축 비용 $4,000-8,000 별도)

ShadoClaw Pro (5개 계정):

• 정액제: 월 $79
• 액세스 계층(Access Layer)을 위한 엔지니어링 시간: 0
• 총합: 월 $79

정액제 모델은 단순히 더 저렴할 뿐만 아니라 예측 가능합니다. 다음 달에 얼마를 쓸지, 6개월 후에 얼마를 쓸지 알 수 있습니다. 토큰 예측치가 가득한 스프레드시트 없이도 예산을 세울 수 있습니다.

구축할 것인가, 구매할 것인가

다음과 같은 경우에는 직접 액세스 계층을 구축하세요:

• 어떤 외부 서비스도 충족할 수 없는 특정 컴플라이언스 (Compliance) 요구 사항이 있는 경우
• 관리형 서비스 (Managed service)가 지원하지 않는 방식으로 프록시 (Proxy) 동작을 수정해야 하는 경우
• 여유 인력이 있는 전담 인프라 엔지니어를 보유하고 있는 경우
• 규모가 엔지니어링 투자를 정당화할 수 있는 경우 (사용자 100명 이상, 커스텀 라우팅 로직 필요 등)

다음과 같은 경우에는 관리형 서비스를 사용하세요:

• 인프라가 아닌 도구 구축에 집중하고 싶은 경우
• 엔지니어링 시간이 매우 귀중할 정도로 팀 규모가 작은 경우
• 이론적인 비용 절감보다 예측 가능한 비용이 더 중요한 경우
• 직접 구축하지 않고도 멀티 계정 (Multi-account) 지원이 필요한 경우

내부 AI 도구를 구축하는 20명 미만의 대부분의 팀에게는? 관리형 방식이 승리합니다. 기술적으로 더 우수하기 때문이 아닙니다. 숙련된 엔지니어라면 누구나 프록시를 구축할 수 있습니다. 관리형 방식이 승리하는 이유는 엔지니어의 시간을 도구 자체를 만드는 데 더 가치 있게 사용할 수 있기 때문입니다.

더 큰 그림: AI 인프라는 새로운 DevOps이다

2년 전에는 아무도 "Claude 액세스 전략"을 가지고 있지 않았습니다. 하지만 이제 LLM (Large Language Model)을 기반으로 구축하는 모든 팀은 전략이 필요합니다. 이는 우리가 클라우드 인프라, CI/CD, 그리고 모니터링 (Monitoring)에서 보았던 것과 동일한 궤적입니다.

처음에는 모두가 직접 만듭니다. 그다음 고통이 가중됩니다. 그다음 전문화된 도구들이 등장합니다. 그러고 나면 모두가 왜 월 79달러면 살 수 있는 것을 만드는 데 6개월을 소비했는지 의아해하게 됩니다.

우리는 현재 "고통이 가중되는" 단계에 있습니다. 액세스 계층을 초기에 제대로 구축하는 팀은 더 빠르게 움직이고, 비용을 적게 쓰며, 관리되지 않은 API 키가 주말 사이 2,000달러를 태워버릴 때 발생하는 위기를 피할 수 있을 것입니다.

실질적인 첫 단계

오늘 Claude를 사용하여 내부 도구를 구축하고 있다면, 이번 주에 해야 할 일은 다음과 같습니다:

1. 현재의 액세스 패턴을 감사(Audit)하세요. 얼마나 많은 API 키가 존재합니까? 누가 이를 보유하고 있습니까? 어디에 저장되어 있습니까?

2. 기본적인 로깅(Logging)을 추가하세요. 다른 것은 아무것도 하지 않더라도, 모든 API 호출에 대해 도구 이름, 사용자, 토큰 수(Token count)를 기록하세요. 이 데이터가 반드시 필요할 것입니다.

3. 지출 알림을 설정하세요. Anthropic의 대시보드에서는 기본적인 알림을 설정할 수 있습니다. 이를 활용하세요. 5,000달러의 깜짝 놀랄 비용보다는 500달러의 깜짝 놀랄 비용이 훨씬 낫습니다.

4. 옵션을 평가하세요. 완전한 자체 구축(DIY) 프록시(Proxy)가 필요합니까? 오픈 소스 게이트웨이(Gateway)가 필요합니까? 아니면 관리형 서비스(Managed service)가 필요합니까? 정답은 팀의 규모, 예산, 그리고 엔지니어링 역량에 달려 있습니다.

5. 다음 도구를 출시하기 전에 결정을 내리세요. 액세스 전략 없이 구축하는 모든 새로운 내부 도구는 결국 추후 마이그레이션(Migration)을 더 어렵게 만듭니다.

여러분이 작성하는 코드는 중요합니다. 하지만 그 코드와 Claude의 API 사이의 계층(Layer)이 여러분의 AI 도구를 경쟁 우위로 만들지, 아니면 예산의 블랙홀로 만들지를 결정합니다.

인프라 문제로 머리 아픈 일을 건너뛰고 싶으신가요?

ShadoClaw는 멀티 계정 지원, 비용 제어 및 정액제 요금제를 갖춘 관리형 Claude 액세스 계층을 제공합니다. 프록시를 만들기보다 도구를 만드는 데 집중하고 싶은 팀들을 위해 Gerus-lab에서 구축했습니다.

3일 무료 체험 시작하기 → shadoclaw.com