API 키는 요청을 보낸 프로젝트를 식별하는 비밀 문자열입니다. 비밀번호처럼 취급해야 하지만 사람의 로그인 비밀번호와 역할은 다릅니다. 키가 붙은 요청은 해당 프로젝트의 권한과 결제 한도를 사용하므로, 코드에 넣기 전에 소유 범위를 먼저 알아야 합니다.
이 글의 요금·조건은 2026년 9월 14일에 각 서비스 공식 페이지에서 확인한 값입니다. 이후 변경됐을 수 있습니다.
키는 무엇을 증명하나요?
서버는 요청 헤더의 키를 읽어 어느 조직과 프로젝트에서 보냈는지 판정합니다. 그 결과에 따라 사용할 수 있는 모델과 속도 제한, 비용 귀속이 정해집니다. 키 자체에 잔액이 들어 있는 것은 아닙니다. 키가 가리키는 프로젝트의 설정이 실제 권한을 만듭니다. 같은 조직에서도 개발용과 운영용 프로젝트를 나누는 이유입니다.
로그인 비밀번호와 무엇이 다른가요?
로그인 비밀번호는 사람이 관리 화면에 들어갈 때 씁니다. API 키는 프로그램이 서버끼리 통신할 때 씁니다. 다중 인증을 켜도 이미 노출된 키를 자동으로 막아 주지는 않습니다. 저장소, 브라우저 코드, 화면 캡처에 키가 남았다면 새 키를 만들기보다 먼저 기존 키를 폐기해야 합니다.
어디에 저장해야 하나요?
환경 변수나 비밀 관리 도구처럼 실행 환경만 읽을 수 있는 곳에 둡니다. 모바일 앱과 브라우저 자바스크립트는 사용자가 파일을 열어 볼 수 있으므로 안전한 보관 장소가 아닙니다. 공개 저장소에서 파일을 지워도 커밋 기록에는 남습니다. 문자열을 가리는 작업보다 폐기와 교체가 앞섭니다.
프로젝트를 나누면 무엇이 좋아지나요?
용도별 키만 나누고 같은 프로젝트를 쓰면 청구와 한도는 여전히 섞일 수 있습니다. 시험, 운영, 외부 자동화를 프로젝트 수준에서 분리하면 사고 범위를 좁힐 수 있습니다. 이름에는 개인 정보 대신 서비스와 환경만 적습니다. 매달 사용하지 않는 키를 찾아 폐기하고 마지막 사용 시각을 기록합니다.
공식 지침은 무엇을 강조하나요?
2026년 9월 14일 OpenAI 도움말은 키를 공유하지 않고 브라우저나 모바일 앱에 배포하지 말라고 안내합니다. Gemini 문서도 프로덕션 호출을 서버 측에서 처리하라고 명시합니다. 예제 코드에 문자열을 직접 넣는 짧은 설명을 보더라도 운영 환경에는 그대로 옮기지 않습니다.
확인한 공식 원문
- OpenAI API 키 보안 권장사항 — 2026년 9월 14일 확인
- Gemini API 키 사용 안내 — 2026년 9월 14일 확인
자주 묻는 질문
API 키를 공유해도 되나요?
공유하지 않습니다. 사람이나 서비스마다 별도 키와 프로젝트를 쓰면 폐기와 비용 추적이 쉬워집니다.
키가 노출되면 무엇부터 하나요?
해당 키를 즉시 폐기합니다. 그 뒤 사용량과 로그를 확인하고 새 키로 교체합니다.
환경 변수에 넣으면 완전히 안전한가요?
노출 위험을 줄이지만 권한과 로그 관리도 필요합니다. 서버 접근 권한과 배포 로그에 값이 찍히지 않는지 확인합니다.
