Popup Studio Education
L03비밀키와 환경변수
로그인
📚 FDE · 세션 · 개발 기초 · L03

비밀키와 환경변수

작성일자 2026-07-28  ·  수정일자 2026-07-28  ·  강의차수 L03  ·  예상소요 20분

목표 API 키 같은 비밀값을 왜 코드나 git 에 넣지 않고 .env 에 두는지, 환경마다 비밀키가 왜 다른지 이해한다.

1. 비밀키(API 키)란 무엇인가

AI, 문자 발송, 지도 같은 기능을 직접 만들려면 비용과 시간이 많이 듭니다. 그래서 이미 잘 만들어진 외부 서비스를 가져다 씁니다. 이런 서비스는 대부분 유료라 "지금 요청하는 게 누구인지"를 알아야 요금을 청구할 수 있습니다. 따라서 서비스를 쓰려면 먼저 API 키를 발급받아야 합니다.

쉽게 말해 API 키는 일종의 비밀번호가 포함된 신용카드 번호입니다. 사용한 만큼 요금이 이 비밀키로 청구되고, 유출되면 타인이 쓴 비용까지 우리에게 청구되므로 외부에 노출해서는 안 됩니다.

2. Git·코드 에 두면 안 되는 이유

비밀키는 Git 이나 코드에 넣으면 안 됩니다. 코드든 파일이든, 작성한 컴퓨터에만 머물지 않고 보통 GitHub 에 올라가 팀원과 공유되거나 외부에 공개되기 때문입니다. 즉, 비밀키를 코드나 파일에 적어 두는 것은 사실상 그 비밀키를 인터넷에 공개해 버리는 것과 같습니다. 함께 공개되는 순간 비밀키도 그대로 드러나고, 한번 유출된 비밀키는 누가 가져갔는지 추적할 수도, 되돌릴 수도 없습니다.

3. 사고 발생 원인과 대처

별로 어렵지 않은 것 같은데 왜 이런 사고가 자주 일어날까요? 이런 실수는 대개 몰라서가 아니라 익숙해서 발생합니다. 늘 다루는 값이라 방심하고, 별일 없겠거니 넘기는 순간 사고가 터집니다.

예를 들어 급하게 테스트 결과를 확인하려고 코드에 비밀키를 적었다가 그대로 올리거나, 비밀키가 담긴 파일을 무심코 실수로 함께 commit 하는 경우입니다. 이때 흔히 '코드에서 비밀키를 지우고 다시 commit 하면 되지 않나' 생각하지만, 그렇지 않습니다. git 은 모든 변경을 commit 이력으로 남기기 때문입니다. 예를 들어 비밀키를 적어 commit(1번)하고, 뒤늦게 지워 다시 commit(2번)해도, 1번 commit 이력을 확인해 보면 비밀키가 그대로 남아 값이 노출됩니다. 게다가 GitHub 에 올라간 순간 봇이 이미 긁어 갔을 수 있어, 지운다고 없던 일이 되지 않습니다.

그래서 비밀키가 유출됐다면 올바른 대처는 그 비밀키를 폐기하고 새 비밀키로 재발급하는 것입니다. 이미 퍼진 비밀키는 회수가 안 되니, 그 비밀키를 무효로 만들어 남이 못 쓰게 하고 새 비밀키로 갈아 낍니다. '비밀키는 돈·권한이 걸린 열쇠이고 한 번 퍼지면 회수가 안 된다'는 개념을 알아야 이런 사고에 스스로 대응할 수 있습니다.

4. .env 와 환경변수

이러한 사고를 막으려면 비밀키를 코드에 직접 쓰지 않고 .env 라는 별도 파일에 둡니다. .env 는 비밀값만 모아 두는 메모장(txt) 같은 파일로, 비밀키를 이름과 함께 적어 둡니다. 코드는 진짜 비밀키 값을 모릅니다. '비밀키의 이름'만 알고, 실행될 때 그 이름으로 .env 를 열어 실제 값을 읽습니다.

# .env  (git 에는 안 올린다)
OPENAI_API_KEY=sk-실제-비밀-값...

# 코드에는 값이 아니라 '이름'만 있다
key = 환경변수["OPENAI_API_KEY"]   ← 실행될 때 .env 에서 실제 값을 읽어 온다

이렇게 코드가 아닌 별도 파일에 두고 이름으로 불러오는 값을 환경변수라고 합니다. .env 의 env 가 바로 이 '환경(environment)'을 줄인 말입니다.

그런데 .env 도 결국 비밀키가 담긴 파일입니다. 앞서 말한 대로 이런 파일이 git 에 올라가면 코드에 직접 적은 것과 똑같이 유출입니다. 바로 이때 앞 강의에서 배운 .gitignore 가 쓰입니다. .gitignore 에 .env 를 적어 두면, git 이 이 파일을 아예 없는 것처럼 무시해 GitHub 에 올리지 않고 내 컴퓨터에만 남깁니다. 덕분에 코드가 GitHub 에 올라가도 비밀은 새어 나가지 않습니다.

실무에서는 Claude 가 .gitignore 로 .env 를 막아 주지만, 도구가 막아 줘도 왜 막는지 아는 사람만이 사고가 났을 때 제대로 대응할 수 있습니다.

5. 환경별 비밀키 분리

비밀키 값을 담는 .env 는 환경마다 따로 둡니다. 환경에는 개발·연습용 환경(dev)과 실제 고객에게 서비스되는 운영환경(prod)이 있는데, dev 환경엔 dev 의 .env, prod 환경엔 prod 의 .env 가 따로 있어, 같은 서비스라도 dev 용 비밀키(API 키)와 prod 용 비밀키(API 키)를 다르게 씁니다.

왜 다르게 쓸까요? 개발하면서 시험하다가 운영 환경의 진짜 데이터나 요금을 건드리지 않기 위해서입니다. 예를 들어 문자 발송을 테스트할 때 dev 용 비밀키를 쓰면 실제 고객에게 문자가 나가지 않습니다. 하지만 prod 용 비밀키를 dev 에서 그대로 쓰면 테스트하는 순간 진짜 고객에게 문자가 나가는 사고가 날 수 있습니다. 그래서 환경마다 비밀키를 분리합니다.

두 환경의 자세한 설명은 다음 강의 '개발환경과 운영환경'에서 다루므로, 지금은 두 환경이 나뉘어 있다는 것만 알면 됩니다.

6. 비밀키 유출의 대가

보안은 성과가 겉으로 드러나지 않습니다. 잘 지키고 있어도 아무 일 없는 평소와 다를 게 없고, 안전한 것인지 아직 안 터진 것인지 구분되지 않기 때문입니다. 그래서 그 가치는 대개 사고가 터진 뒤에야 드러납니다. 그러다 보니 경영진은 보안 투자에 드는 비용·시간보다 사고 발생 시 부과되는 벌금을 한 차례 감수하는 편이 효율적이라 판단하는 경향이 있습니다. 그 판단이 실제로 타당한지는 아래 사례가 말해 줍니다. 비밀키·인증 정보 유출은 먼 이야기가 아닙니다. 최근 국내에서도 반복됐고, 책임과 대가는 조 단위였습니다 (2026년 보도 기준).

  • SK텔레콤(2025.04): 해킹으로 내부 서버(HSS)에서 가입자 인증에 쓰이는 유심 인증키(Ki 등)를 포함한 약 2,300만 명분의 정보가 유출됐습니다. 이 인증키가 새면 유심 복제로 이어질 수 있어 파장이 컸습니다.
    과징금 약 1,348억 원에 더해 고객 보상 약 5천억 원·정보보호 투자 약 7천억 원 등 1조 원 이상을 지출했습니다.
  • 쿠팡(2025.06): 퇴사한 개발자의 접근 인증키를 회수하지 않아 약 3,370만 명의 개인정보가 다섯 달간 노출됐습니다.
    개인정보위는 역대 최대인 약 6,247억 원의 과징금을 부과했고, 회사는 1조 6천억 원 규모의 보상안을 내놨습니다.
  • KT(2025.09): 불법 기지국(펨토셀) 공격으로 약 2만 2천 명의 정보가 유출되고,
    일부 고객이 무단 소액결제(약 2억 4천만 원) 피해를 입었습니다. 과징금은 최대 2천억 원대가 거론되고, 약 31만 명이 이탈하자 남은 고객의 추가 이탈을 막으려 전 고객을 대상으로 약 4,500억 원 규모의 고객 보답 프로그램까지 시행했습니다. 과징금과 보답 프로그램을 더하면 지출은 약 6,000억 원대에 이를 것으로 추정됩니다.

SK텔레콤과 KT 사례처럼 직접적인 책임이 아닌 해킹으로 인한 비밀키 유출임에도 그 책임과 대가는 수천억 원에서 조 단위에 이릅니다. 하물며 비밀키를 스스로 흘려 자초한 유출이라면 책임과 대가는 더 큽니다.

대기업만의 일도 아닙니다. 소규모 개인 프로젝트 과정에서 AWS·GCP 같은 클라우드 비밀키가 코드에 섞여 GitHub 에 올라가면, 봇이 수십 초 만에 낚아채 서버를 띄워 암호화폐를 채굴합니다. 며칠 만에 수천만 원(수만 달러)이 청구된 사례가 흔합니다. 비밀키 하나의 관리 실패는 개인에게도 감당 못 할 청구서를 남깁니다. 이러한 책임을 감당할 자신이 있다면 비밀키를 코드에 적어도 좋습니다.

관련 기사

오늘 정리 + 다음

  • 정리: 비밀키(API 키)는 비밀번호가 포함된 신용카드 번호 같아서 돈·권한이 걸려 있습니다. 비밀키를 코드나 파일에 넣으면 GitHub 로 퍼져 인터넷에 공개한 것과 같습니다. 그래서 비밀키는 코드가 아닌 .env 에 두고 .gitignore 로 git 에 올리지 않도록 합니다(코드는 '이름'만 알고 실제 값은 .env 에서 읽음 = 환경변수). 비밀키는 dev·prod 환경마다 따로 둡니다.
  • 흔한 함정: 비밀키를 실수로 commit 해 유출하는 경우, 그리고 dev·prod 비밀키를 나누지 않고 개발하다 운영 데이터를 건드리는 경우입니다. 유출은 지운다고 사라지지 않으니(commit 이력에 그대로 남음), 그 비밀키를 폐기하고 새로 재발급합니다.
  • 다음 시간: 개발환경과 운영환경. 앞서 짚은 dev 와 prod 가 왜 다른 서버인지, 무엇을 어떻게 나눠 두는지 자세히 다룹니다.
이 강의를 학습하셨나요?