API 키를 6시간 만에 1,500만원 날려보고 만든 것: 멀티 에이전트 개발자의 ‘키/컨텍스트’ 통합 관리

Claude Code, Cursor, Codex, Copilot을 동시에 돌리다 보면 “각자 잘하는 게 달라서” 병렬로 쓰게 되죠.
그런데 API 키를 여기저기 붙여넣는 순간, 편의성이 리스크로 바뀐다는 걸 뼈아프게 겪은 사례가 공유됐어요.

1) 공개 저장소에 키가 올라가면, 생각보다 빨리 털려요

사례 작성자는 지난 화요일, 테스트용 스크립트에 Anthropic API key를 붙여 넣었다가 커밋에 포함됐고요.
그 결과 약 6시간 만에 누군가 키를 스크래핑(scraping, 자동 수집)해서 약 $15,423(약 2천만 원 내외)의 API 호출을 발생시켰다고 합니다.

여기서 중요한 포인트는 “실수 자체”보다 탐지·대응까지의 시간이에요.
키 유출은 요즘 봇이 상시로 돌아다니기 때문에, 공개 repo로 나가는 순간 ‘언젠가’가 아니라 ‘몇 시간 내’ 문제가 되기 쉽습니다.
개발 흐름에서 임시 테스트 코드는 특히 느슨해지기 쉬워서, 이런 사고가 반복되기 좋은 지점이기도 하고요.

2) 더 큰 문제: “키가 어디서 새었는지” 모른다는 것

작성자는 키를 즉시 로테이션(rotation, 재발급/교체)했지만 더 찝찝했던 건 따로였어요.
동일한 키가 4개 에이전트 설정 + 2개의 .env + docker-compose까지, 총 7군데에 흩어져 있었다는 점이죠.

이 상황에서는 유출이 발생했을 때, 원인이 무엇인지 역추적이 거의 불가능합니다.
테스트 스크립트가 범인일 수도 있고, 잊고 있던 낡은 dev container가 키를 물고 있었을 수도 있어요.
결국 “확실히 막자”는 마음으로 전부 회전(=전부 교체) 할 수밖에 없고, 이건 운영 피로도를 급격히 올립니다.

3) 그래서 만든 Harbor(가칭): 키를 한 번만 넣고, 에이전트는 읽기만

이 문제를 해결하려고 주말 동안 직접 만든 도구가 harbor예요.
핵심 아이디어는 “자격 증명(credential) 저장소를 하나로 통합하고, 모든 에이전트가 거기서만 가져가게 만들자” 입니다.

구체적으로는 이런 흐름입니다.

• 키는 한 번만 저장: 여기저기 복붙하지 않고 중앙 저장소에만 입력해요.
• 로테이션도 한 번만: 키를 교체하면 Claude Code / Cursor / Codex / Copilot이 동시에 업데이트되는 구조를 목표로 해요.
• 에이전트별 스코프(scope, 권한 범위) 읽기: 각 에이전트는 “필요한 만큼만” 읽고, 감사 로그(audit log) 에 “누가 언제 키를 가져갔는지” 남겨서 추적 가능성을 높입니다.

이게 왜 중요하냐면요. “유출 방지”도 있지만 현실적으로는 유출 이후의 피해 최소화가 더 자주 필요해요.
어느 지점에서 키가 노출됐는지 모르면 대응이 과잉(전면 교체)으로 갈 수밖에 없는데, 감사 로그가 있으면 최소한 의심 구간을 좁힐 근거가 생깁니다.

4) 에이전트 ‘공유 메모리’: 작업 맥락이 끊기지 않게

harbor의 두 번째 기능은 에이전트 간 공유 메모리(shared memory) 입니다.
여러 에이전트를 쓰다 보면 이런 경험 많죠: Claude로 하다가 막히면 Codex로 바꾸고, 다시 Cursor로 넘어가면… 앞에서 뭐 했는지 다시 설명해야 해요.

작성자가 말한 공유 메모리의 목표는 간단합니다.
“Claude에서 하던 흐름이 중간에 끊겨도 Codex가 같은 컨텍스트를 이어받는다”는 것.
예를 들어,

• 우리가 어떤 시도를 했고(what we tried)
• 무엇이 실패했고(what failed)
• 지금 중요한 파일이 무엇인지(what files matter)

이런 정보가 이어지면, 에이전트 전환이 ‘리셋’이 아니라 진짜 핸드오프(handoff, 인수인계) 가 됩니다.

5) 실제 사용 시나리오: 멀티 에이전트 쓰는 팀/개인이 바로 겪는 문제

이 도구가 유용한 상황은 꽤 명확해요. 특히 아래 패턴이요.

• 로컬 + 컨테이너 + CI가 섞인 개발
  .env, docker-compose, devcontainer 등 키가 들어갈 표면(surface)이 많아질수록, “어디가 최신인지”부터 헷갈립니다. 중앙화가 체감 효율을 만들어요.
• 여러 에이전트 툴을 병렬로 활용
  에이전트마다 설정 파일 위치가 다르고, 입력 방식도 달라서 키 복제본이 늘어나기 쉽습니다. 한 번 새면 전부 의심해야 하는 구조가 되죠.
• 키 유출 사고 이후 ‘안전한 재발급’ 프로세스가 없는 경우
  로테이션을 “기술적 작업”이 아니라 “운영 프로세스”로 만들려면, 감사 로그와 스코프가 큰 도움이 됩니다.

마무리: 키는 ‘복붙’하는 순간 자산이 아니라 부채가 돼요

이 사례에서 가장 날카로운 교훈은 유출 자체보다, 키가 흩어져 있을 때 발생하는 대응 비용이에요.
키가 7군데에 퍼져 있으면, 한 번의 사고가 곧 “전면 교체 + 전체 점검”으로 커지고, 결국 개발 속도도 같이 무너집니다.

지금 Claude Code나 Cursor 같은 에이전트를 여러 개 돌리고 있다면, 오늘만큼은 한 번 점검해보세요.
내 API 키가 몇 군데에 저장돼 있는지, 그리고 유출 시 어떤 경로로 새었는지 추적할 방법이 있는지요.
관심이 있다면, 이 harbor 같은 접근을 팀의 표준(키 중앙화 + 감사 로그 + 스코프)으로 가져갈지 검토해볼 만합니다.