[AI 노동일지 2편 #7] 클라이언트에 API 키 넣으면 안 됩니다 — 보안 실수를 막은 규칙

빠른 구현의 유혹

마감이 촉박하거나 빠르게 뭔가 돌아가는 걸 보고 싶을 때, 가장 빠른 방법은 프론트엔드 코드에 API 키를 직접 넣는 것이다. 한 줄이면 된다. 동작한다. 테스트도 통과한다.

그리고 GitHub에 push하는 순간 전 세계에 공개된다.

GitHub Pages는 퍼블릭 리포지토리다. 소스코드를 보는 사람이라면 누구든 키를 가져갈 수 있다. 자동으로 키를 스캔하는 봇도 있다. push하고 몇 분 안에 키가 수집되는 경우도 실제로 있다.

실제 위험 시나리오

각 키 유형별로 어떤 일이 생기는지 구체적으로 생각해봤다.

OpenAI API 키가 노출되면 빌링 주소는 내 계정이다. 누군가 대량으로 요청을 날리면 하루 만에 수십만 원이 청구될 수 있다. Tistory 인증 토큰이 노출되면 블로그 관리자 권한으로 게시물을 마음대로 조작할 수 있다. D1 접근 키가 노출되면 유저 데이터가 통째로 유출된다.

이게 과장이 아니다. 오픈소스 프로젝트에서 실수로 커밋된 키가 악용된 사례는 검색하면 쉽게 나온다.

안전한 구조 설계

원칙은 하나다. 비밀은 서버에만 있어야 한다. 클라이언트는 서버를 통해서만 민감한 작업을 요청한다.

llm.cocy.io가 이 역할을 한다. AI API 호출은 전부 이 프록시를 통한다. 클라이언트는 Bearer 토큰 하나만 알면 되고, 실제 모델 키는 서버에만 있다. relay.cocy.io에서 외부 API를 호출할 때도 Cloudflare Workers secrets으로 환경변수를 관리한다. 코드에 키가 등장하지 않는다.

Origin 기반 인증도 활용한다. *.cocy.io 도메인에서 오는 요청은 서버 레벨에서 신뢰하고, 외부 요청은 별도 토큰으로 검증한다. 이렇게 하면 내 서비스끼리는 추가 인증 없이 자유롭게 통신하면서 외부 접근은 차단할 수 있다.

이 규칙을 한 번 위반하면 키를 즉시 교체해야 한다. 노출된 키는 살아있는 키가 아니다.

2편 완결. AI, 서비스를 만들다.

---

3편에서 이어집니다: AI, 엔지니어링을 하다