개발용 API 키가 깃허브에 올라갔을 때 벌어질 수 있는 일

웹사이트나 앱을 개발하다 보면 API 키를 사용하는 일이 많습니다. 지도 API, 결제 API, 문자 발송 API, 이메일 발송 API, 클라우드 저장소, 번역 API, 인공지능 API, 소셜 로그인, 배포 자동화 도구 등 외부 서비스와 연결할 때 API 키가 필요합니다. API 키는 서비스가 “누가 요청하는지”를 식별하고, 사용 권한과 사용량을 관리하는 인증 정보입니다.

문제는 개발 과정에서 API 키가 깃허브 같은 코드 저장소에 실수로 올라가는 경우입니다. 개발자는 테스트용 키라서 괜찮다고 생각할 수 있지만, 실제 권한이 있는 키라면 비용 발생, 데이터 접근, 서비스 악용, 계정 정지 같은 문제가 생길 수 있습니다. 특히 공개 저장소에 API 키가 올라가면 자동화된 도구가 빠르게 이를 찾아낼 수 있습니다.

API 키 유출은 단순한 코드 관리 실수가 아닙니다. 외부 서비스에 접근할 수 있는 열쇠가 공개된 것과 비슷합니다. 따라서 개발용 API 키라도 공개 저장소에 올라가지 않도록 관리해야 하며, 이미 올라갔다면 삭제만으로 끝내지 말고 반드시 키 폐기와 재발급을 진행해야 합니다.

API 키란 무엇인가

API 키는 외부 서비스에 요청을 보낼 때 사용하는 인증용 문자열입니다. 예를 들어 웹사이트에 지도를 표시하려면 지도 서비스 API 키가 필요할 수 있고, 회원에게 인증 문자를 보내려면 문자 발송 서비스 API 키가 필요할 수 있습니다. 결제, 이메일, 번역, 클라우드 저장소, AI 서비스도 API 키를 사용합니다.

API 키는 비밀번호와 비슷한 성격을 가집니다. 사용자가 직접 로그인할 때 쓰는 비밀번호는 아니지만, 프로그램이 외부 서비스에 접근할 때 권한을 증명하는 값입니다. 이 키를 가진 사람은 설정된 범위 안에서 해당 서비스를 사용할 수 있습니다.

일부 API 키는 단순히 사용량을 측정하는 정도의 권한만 가질 수 있습니다. 하지만 어떤 키는 데이터 조회, 파일 업로드, 문자 발송, 결제 요청, 서버 제어, 배포 작업까지 가능할 수 있습니다. 권한 범위에 따라 위험도가 크게 달라집니다.

따라서 API 키는 코드에 직접 적어두는 값이 아니라, 환경변수나 비밀 관리 도구를 통해 별도로 관리해야 합니다. 공개 저장소, 블로그 글, 캡처 화면, 문서에 그대로 노출되면 안 됩니다.

깃허브에 API 키가 올라가는 이유

API 키가 깃허브에 올라가는 가장 흔한 이유는 개발 편의성 때문입니다. 처음 테스트할 때 코드 안에 키를 직접 적어두면 빠르게 기능을 확인할 수 있습니다. 예를 들어 apiKey = "..." 형태로 넣어두면 별도 설정 없이 바로 실행됩니다.

문제는 테스트가 끝난 뒤 이 코드를 그대로 커밋하는 경우입니다. 개발자는 임시로 넣어둔 값이라고 생각했지만, 깃허브에 올리는 순간 저장소 기록에 남습니다. 공개 저장소라면 누구나 볼 수 있고, 비공개 저장소라도 접근 권한이 있는 사람은 확인할 수 있습니다.

설정 파일이 함께 올라가는 경우도 많습니다. .env, config.json, settings.py, application.yml, firebaseConfig.js 같은 파일에 API 키가 들어 있을 수 있습니다. 이 파일을 .gitignore에 추가하지 않으면 실수로 커밋될 수 있습니다.

초보 개발자나 블로그 운영자는 테스트 프로젝트를 올리면서 민감한 키가 포함되었는지 놓치기 쉽습니다. 특히 워드프레스 플러그인 개발, 개인 웹앱, 자동화 스크립트, 포트폴리오 프로젝트를 공개할 때 주의해야 합니다.

공개 저장소에 올라가면 왜 위험한가

깃허브 공개 저장소는 누구나 검색하고 열람할 수 있습니다. API 키가 포함된 코드가 올라가면 사람뿐 아니라 자동화된 스캐너도 이를 찾을 수 있습니다. 인터넷에는 공개 저장소에서 키, 토큰, 비밀번호를 찾는 자동화 도구가 많습니다.

키가 노출되면 짧은 시간 안에 악용될 수 있습니다. 예를 들어 문자 발송 API 키가 유출되면 대량 문자 발송에 사용될 수 있고, 클라우드 API 키가 유출되면 저장소 접근이나 리소스 생성에 악용될 수 있습니다. 유료 API라면 비용이 급격히 발생할 수 있습니다.

지도 API나 AI API처럼 사용량 기반 과금 서비스는 특히 주의해야 합니다. 공격자가 키를 사용해 대량 요청을 보내면 예상치 못한 요금이 청구될 수 있습니다. 서비스 제공자는 사용량을 기준으로 과금하기 때문에, 키 주인이 비용을 부담하게 될 수 있습니다.

공개 저장소에 올린 뒤 바로 삭제해도 안전하다고 볼 수 없습니다. 깃 기록에 남아 있을 수 있고, 이미 외부 스캐너가 수집했을 수 있습니다. 그래서 노출된 키는 삭제가 아니라 폐기해야 합니다.

개발용 키도 안전하지 않은 이유

많은 사람이 “개발용 API 키니까 괜찮다”고 생각합니다. 하지만 개발용 키도 실제 서비스 권한을 가지고 있을 수 있습니다. 테스트 환경이라고 해도 외부 API 사용량이 발생하거나, 테스트 데이터에 접근하거나, 특정 기능을 실행할 수 있습니다.

개발용 키가 운영용 키와 같은 계정에 연결되어 있다면 더 위험합니다. 사용량 한도, 결제수단, 프로젝트 권한이 공유될 수 있습니다. 공격자가 개발용 키를 통해 서비스를 악용하면 운영 계정 전체에 영향이 갈 수 있습니다.

또한 개발용 키는 제한이 약한 경우가 많습니다. 빠른 테스트를 위해 도메인 제한, IP 제한, 사용량 제한을 걸어두지 않는 경우가 있습니다. 이 상태로 유출되면 공격자가 다른 환경에서도 자유롭게 사용할 수 있습니다.

개발용과 운영용 키는 반드시 분리해야 합니다. 개발용 키에도 최소 권한과 사용량 제한을 적용하고, 테스트가 끝나면 폐기하는 것이 좋습니다. “개발용”이라는 이름이 보안 위험을 없애주지는 않습니다.

비용 폭탄이 발생할 수 있다

API 키 유출에서 가장 현실적인 피해 중 하나는 비용입니다. 사용량 기반 서비스는 요청 수, 처리량, 저장 용량, 전송량에 따라 요금이 부과됩니다. 키가 노출되면 공격자가 대량 요청을 보내 비용을 발생시킬 수 있습니다.

예를 들어 AI API 키가 유출되면 대량의 텍스트 생성 요청이 발생할 수 있습니다. 지도 API 키가 유출되면 지도 호출량이 급증할 수 있습니다. 문자 발송 API 키가 유출되면 대량 문자 발송 비용이 생길 수 있습니다. 클라우드 키가 유출되면 서버나 저장소 리소스가 생성되어 비용이 늘어날 수 있습니다.

이런 비용은 사용자가 바로 알아차리지 못할 수 있습니다. 월말 청구서를 보고 뒤늦게 발견하거나, 서비스 제공자가 이상 사용량을 감지해 계정을 제한한 뒤 알게 되는 경우도 있습니다.

비용 피해를 줄이려면 API 키에 사용량 제한과 예산 알림을 설정해야 합니다. 하루 요청량, 월간 예산, 특정 금액 이상 알림을 걸어두면 이상 사용을 빠르게 파악할 수 있습니다. 키 유출을 완전히 막는 것이 가장 중요하지만, 유출 후 피해를 줄이는 장치도 필요합니다.

데이터 유출로 이어질 수 있다

일부 API 키는 데이터를 조회하거나 수정할 수 있는 권한을 가집니다. 단순 사용량 과금 문제를 넘어 실제 데이터 유출로 이어질 수 있습니다. 클라우드 저장소, 데이터베이스 서비스, 이메일 서비스, 고객 관리 도구와 연결된 키라면 특히 위험합니다.

예를 들어 저장소 API 키가 유출되면 파일 목록을 조회하거나 파일을 다운로드할 수 있습니다. 이메일 발송 서비스 키가 유출되면 발송 목록, 템플릿, 수신자 정보 일부가 노출될 수 있습니다. 고객 관리 API 키가 유출되면 고객명, 이메일, 문의 내역에 접근할 수 있습니다.

데이터 수정 권한이 있는 키라면 피해가 더 커집니다. 공격자가 데이터를 삭제하거나 변경하거나, 악성 파일을 업로드하거나, 잘못된 내용을 발송할 수 있습니다. 이 경우 단순 정보 유출을 넘어 서비스 장애와 신뢰도 하락으로 이어질 수 있습니다.

API 키는 가능한 최소 권한으로 만들어야 합니다. 읽기만 필요한 기능에는 쓰기 권한을 주지 않고, 특정 서비스만 필요한 키에는 전체 계정 권한을 부여하지 않아야 합니다. 권한 범위가 좁을수록 유출 시 피해도 줄어듭니다.

서비스 악용과 계정 정지 위험

API 키가 유출되면 공격자가 해당 서비스를 악용할 수 있습니다. 문자 발송, 이메일 발송, 번역, 이미지 생성, 파일 업로드, 서버 생성, 배포 자동화 같은 기능이 악의적으로 사용될 수 있습니다.

문자나 이메일 API가 유출되면 스팸 발송에 악용될 수 있습니다. 이 경우 서비스 제공자가 계정을 제한하거나 발송 기능을 정지할 수 있습니다. 도메인 평판이나 발신 번호 신뢰도에도 악영향이 갈 수 있습니다.

클라우드나 배포 관련 키가 유출되면 악성 서버를 만들거나, 기존 서비스를 변경하거나, 악성 파일을 배포하는 데 사용될 수 있습니다. 사용자는 직접 공격하지 않았더라도 자신의 계정이 악용된 책임을 져야 할 수 있습니다.

서비스 제공자는 API 키가 공개 저장소에서 발견되면 자동으로 경고를 보내거나 키를 비활성화하기도 합니다. 하지만 모든 서비스가 자동으로 보호해주는 것은 아닙니다. 키 소유자가 직접 관리해야 합니다.

삭제만으로 해결되지 않는 이유

깃허브에 API 키가 올라갔다면 파일에서 해당 줄을 삭제하고 다시 커밋하는 것만으로는 충분하지 않습니다. 깃은 변경 이력을 저장하기 때문에 이전 커밋에 키가 남아 있을 수 있습니다. 누군가 저장소 기록을 보면 삭제 전 키를 확인할 수 있습니다.

또한 공개 저장소에 올라간 순간 외부 스캐너가 이미 키를 수집했을 가능성이 있습니다. 몇 분 안에 자동으로 감지되는 경우도 있습니다. 따라서 “바로 지웠으니 괜찮다”고 생각하면 안 됩니다.

노출된 키는 즉시 폐기해야 합니다. API 제공 서비스의 관리자 페이지에 들어가 해당 키를 비활성화하거나 삭제하고, 새 키를 발급받아야 합니다. 이후 새 키는 안전한 방식으로 저장해야 합니다.

깃 기록에서 키를 제거하는 작업도 필요할 수 있지만, 이것은 보조 조치입니다. 이미 노출된 키는 신뢰할 수 없으므로 반드시 교체해야 합니다. 기록 삭제보다 키 폐기가 우선입니다.

API 키가 노출되었을 때 해야 할 일

API 키가 깃허브에 올라간 것을 발견했다면 먼저 해당 키를 즉시 비활성화해야 합니다. 서비스 관리자 페이지에서 키를 삭제하거나 재발급합니다. 운영 중인 서비스가 해당 키를 사용 중이라면 새 키로 교체한 뒤 기존 키를 폐기해야 합니다.

두 번째로 사용량과 로그를 확인합니다. 노출된 시점 이후 이상한 요청이 있었는지, 비용이 갑자기 늘었는지, 낯선 IP나 지역에서 요청이 발생했는지 확인해야 합니다. 데이터 접근 권한이 있는 키였다면 어떤 데이터가 조회되었는지도 확인해야 합니다.

세 번째로 저장소를 점검합니다. 키가 포함된 파일을 삭제하거나 환경변수 방식으로 바꾸고, .gitignore에 민감한 설정 파일을 추가합니다. 필요하면 깃 기록에서 민감한 문자열을 제거하는 작업도 진행합니다.

네 번째로 관련 계정과 권한을 점검합니다. API 키 하나가 아니라 다른 키, 토큰, 비밀번호도 함께 올라갔는지 확인해야 합니다. 설정 파일에는 여러 민감정보가 같이 들어 있는 경우가 많습니다.

다섯 번째로 재발 방지 설정을 합니다. 시크릿 스캔 도구, 커밋 전 검사 도구, 저장소 보안 알림, 사용량 알림, 예산 제한을 적용하면 같은 실수를 줄일 수 있습니다.

환경변수로 관리해야 하는 이유

API 키를 코드에 직접 적지 않으려면 환경변수를 사용해야 합니다. 환경변수는 실행 환경에 따로 저장해두고, 코드에서는 변수 이름으로 불러오는 방식입니다. 이렇게 하면 코드 저장소에는 실제 키 값이 들어가지 않습니다.

예를 들어 코드에는 API_KEY = process.env.API_KEY처럼 작성하고, 실제 키는 서버나 개발 환경의 환경변수 설정에 저장합니다. 이렇게 하면 깃허브에 코드를 올려도 키 값은 공개되지 않습니다.

개발 환경에서는 .env 파일을 사용할 수 있습니다. 하지만 .env 파일에는 실제 키가 들어가기 때문에 절대 공개 저장소에 올리면 안 됩니다. 반드시 .gitignore에 추가해야 합니다. 대신 .env.example 파일을 만들어 필요한 변수 이름만 예시로 제공하는 방식이 좋습니다.

환경변수는 기본적인 관리 방법입니다. 더 큰 프로젝트에서는 클라우드의 비밀 관리 서비스나 CI/CD 플랫폼의 시크릿 저장소를 사용하는 것이 좋습니다. 중요한 것은 키를 코드와 분리하는 것입니다.

최소 권한 원칙이 필요한 이유

API 키는 필요한 권한만 가져야 합니다. 이것을 최소 권한 원칙이라고 합니다. 모든 기능을 다 사용할 수 있는 키 하나를 만들어 여러 곳에서 쓰는 것은 편하지만, 유출되었을 때 피해가 커집니다.

예를 들어 지도 표시만 필요한 키에는 지도 조회 권한만 주면 됩니다. 파일 업로드만 필요한 서비스에는 특정 버킷이나 특정 폴더 접근 권한만 주는 것이 좋습니다. 읽기 권한만 필요한 기능에 삭제 권한까지 줄 필요는 없습니다.

개발용 키와 운영용 키도 분리해야 합니다. 개발자가 테스트하는 키가 운영 데이터에 접근할 수 있으면 안 됩니다. 테스트 환경에서는 테스트 데이터만 사용할 수 있게 제한하는 것이 안전합니다.

키를 서비스별, 기능별, 환경별로 나누면 관리가 조금 번거로울 수 있습니다. 하지만 유출 사고가 발생했을 때 특정 키만 폐기하면 되고, 피해 범위도 줄일 수 있습니다. API 키 관리에서 권한 분리는 매우 중요합니다.

도메인과 IP 제한 설정

일부 API 서비스는 키 사용 범위를 도메인이나 IP로 제한할 수 있습니다. 예를 들어 특정 웹사이트 도메인에서만 키를 사용할 수 있게 하거나, 특정 서버 IP에서 오는 요청만 허용하는 방식입니다. 이런 제한을 걸어두면 키가 유출되어도 다른 곳에서 악용하기 어려워집니다.

프론트엔드에서 사용하는 지도 API 키처럼 브라우저에 노출될 수밖에 없는 키는 도메인 제한이 특히 중요합니다. 특정 도메인에서만 호출되도록 설정해야 합니다. 제한 없이 공개된 키는 다른 사이트에서도 사용할 수 있습니다.

서버에서 사용하는 API 키는 IP 제한을 적용할 수 있습니다. 운영 서버의 고정 IP에서만 요청을 허용하면 외부에서 키를 가져가도 사용하기 어렵습니다. 다만 서버 IP가 자주 바뀌는 환경이라면 관리가 필요합니다.

도메인과 IP 제한은 완벽한 방어는 아니지만 유출 피해를 줄이는 데 효과적입니다. 키를 발급받은 뒤 기본값 그대로 두지 말고, 가능한 제한 옵션을 확인하는 것이 좋습니다.

깃허브에 올리기 전 확인할 것

코드를 깃허브에 올리기 전에는 민감정보가 포함되어 있는지 확인해야 합니다. API 키, 비밀번호, 토큰, 개인 인증서, 데이터베이스 주소, 클라우드 자격 증명, 이메일 계정 정보가 들어 있는지 봐야 합니다.

특히 .env, config, settings, credentials, secret, firebase, service-account 같은 이름의 파일은 주의해야 합니다. 이런 파일에는 민감한 값이 들어 있을 가능성이 큽니다. 공개 저장소에 올리기 전 반드시 확인해야 합니다.

커밋 전 검사 도구를 사용할 수도 있습니다. 민감한 패턴을 감지해 커밋을 막아주는 도구가 있습니다. 깃허브 자체도 일부 시크릿 스캔 기능을 제공하지만, 모든 상황을 대신해주지는 않습니다. 개발자 스스로 확인하는 습관이 필요합니다.

포트폴리오나 블로그용 예제 코드를 올릴 때는 실제 키 대신 YOUR_API_KEY_HERE 같은 예시 값을 사용해야 합니다. 튜토리얼 글에 캡처를 넣을 때도 API 키가 화면에 보이지 않도록 가려야 합니다.

워드프레스와 개인 블로그 운영자가 주의할 점

워드프레스 블로그 운영자도 API 키 유출을 조심해야 합니다. SEO 도구, 통계 도구, 이메일 발송 서비스, 지도 플러그인, 결제 플러그인, 보안 플러그인, 자동 백업 서비스가 API 키를 사용할 수 있습니다.

플러그인 설정 화면을 캡처해 블로그 글에 올릴 때 API 키가 보이지 않게 해야 합니다. 설정값이 일부만 표시되어도 서비스에 따라 추정 가능성이 있을 수 있습니다. 공개 글에는 키, 토큰, 사이트 인증값을 넣지 않는 것이 원칙입니다.

워드프레스 파일을 백업하거나 깃허브에 올릴 때도 주의해야 합니다. wp-config.php에는 데이터베이스 접속 정보와 보안 키가 들어 있습니다. 테마나 플러그인 개발 중에 외부 API 키를 코드에 직접 넣었다면 저장소에 올라갈 수 있습니다.

개인 블로그라도 API 키가 유출되면 비용과 계정 문제가 생길 수 있습니다. 애드센스 승인용 블로그를 운영하더라도 지도, 통계, 메일 발송, 자동화 기능을 붙일 때는 키 관리가 필요합니다.

API 키 관리 체크리스트

API 키를 안전하게 관리하려면 먼저 코드에 직접 적지 않는 것이 중요합니다. 환경변수, 시크릿 저장소, 서버 설정을 활용해 코드와 키를 분리해야 합니다.

두 번째로 .env와 설정 파일을 .gitignore에 추가합니다. 실제 키가 들어 있는 파일은 저장소에 올라가지 않도록 해야 합니다.

세 번째로 개발용 키와 운영용 키를 분리합니다. 개발용 키가 운영 데이터나 운영 결제 계정에 접근하지 못하게 해야 합니다.

네 번째로 최소 권한을 적용합니다. 필요한 API와 기능에만 접근할 수 있도록 권한을 제한합니다.

다섯 번째로 도메인 제한과 IP 제한을 설정합니다. 키가 유출되어도 다른 환경에서 쓰기 어렵게 만들어야 합니다.

여섯 번째로 사용량 제한과 비용 알림을 설정합니다. 이상 요청이나 비용 증가를 빠르게 확인할 수 있어야 합니다.

일곱 번째로 공개 저장소에 키가 올라갔다면 즉시 폐기하고 새 키를 발급합니다. 삭제만으로는 충분하지 않습니다.

여덟 번째로 정기적으로 사용하지 않는 키를 삭제합니다. 오래된 테스트 키, 외부 업체 작업용 키, 더 이상 쓰지 않는 프로젝트 키는 방치하지 않아야 합니다.

결론

개발용 API 키가 깃허브에 올라가는 것은 단순한 실수가 아니라 실제 보안 사고로 이어질 수 있는 문제입니다. 공개 저장소에 키가 올라가면 자동화된 도구가 빠르게 이를 찾아낼 수 있고, 공격자는 해당 키를 이용해 비용을 발생시키거나 데이터를 조회하거나 서비스를 악용할 수 있습니다.

특히 사용량 기반 API, 문자 발송 API, 클라우드 API, 결제 관련 API, 이메일 발송 API는 유출 피해가 클 수 있습니다. 개발용 키라고 해도 실제 권한과 과금 계정이 연결되어 있다면 안전하지 않습니다. 공개된 키는 삭제가 아니라 폐기와 재발급이 필요합니다.

안전하게 관리하려면 API 키를 코드와 분리하고, 환경변수나 시크릿 저장소에 보관해야 합니다. 개발용과 운영용 키를 나누고, 최소 권한과 도메인·IP 제한, 사용량 알림을 설정하는 것이 좋습니다. API 키는 외부 서비스에 접근하는 열쇠이므로, 깃허브나 블로그 글, 캡처 화면에 노출되지 않도록 항상 점검해야 합니다.