제가 코딩을 늦게 시작하고 처음으로 "진짜 돌아가는 프로그램"을 만들었을 때 이야기부터 하겠습니다. AI에게 "날씨 정보를 가져와서 보여주는 페이지 만들어줘"라고 했더니, 몇 초 만에 그럴싸한 코드를 뚝딱 만들어줬어요. 저는 신이 나서 그걸 그대로 복사해 GitHub에 올렸습니다. 남들에게 자랑도 하고 싶었거든요. 그런데 그 코드 안에는 이런 줄이 하나 들어 있었습니다. apiKey = "sk-a1b2c3d4..." 라는, 저는 뜻도 모르던 긴 문자열이요.
그게 뭐였냐고요? 날씨 서비스가 저에게만 발급해준 '출입증' 같은 비밀 열쇠였습니다. 그런데 저는 그걸 코드에 그대로 박아서, 전 세계 누구나 볼 수 있는 공개 저장소에 올려버린 거예요. 다행히 날씨 키라 큰 사고는 없었지만, 만약 그게 돈이 청구되는 유료 서비스 키였다면? 누군가 그 키를 주워다 마음껏 쓰고, 그 요금은 고스란히 제 카드로 청구됐을 겁니다. 실제로 이런 사고로 하룻밤에 수백만 원이 청구됐다는 이야기, 개발자 커뮤니티에 심심찮게 올라옵니다.
오늘 다룰 주제가 바로 이겁니다. 비밀(secret)을 어떻게 코드에서 분리해 안전하게 보관하느냐. 어렵게 들리지만, 원리는 초등학생도 이해할 만큼 간단합니다. 겁먹지 마세요. 저도 이거 몰라서 사고 칠 뻔했지만, 한 번 개념을 잡고 나니 그다음부터는 습관처럼 자연스러워졌습니다.
비밀키를 코드에 박아 넣는 것은 현관 비밀번호를 대문에 큼지막하게 써 붙여두는 것과 같습니다. 반대로 환경변수는 그 비밀번호를 금고에 따로 넣어두고, 필요한 순간에만 꺼내 쓰는 것이죠. 대문(코드)에는 "금고에서 비밀번호를 가져와 쓰라"는 안내만 적어둘 뿐, 실제 번호는 어디에도 노출되지 않습니다.
이 비유 하나만 머릿속에 넣고 시작하세요. 오늘 나오는 .env, .gitignore, Secrets 같은 낯선 단어들은 전부 "비밀번호를 대문에서 떼어내 금고에 넣는 방법"의 세부 항목일 뿐입니다.
비밀(시크릿)이 대체 뭔가요
먼저 용어부터 정리하죠. 개발에서 '비밀(secret, 시크릿)'이란, 남에게 알려지면 안 되는 민감한 문자열을 통틀어 부르는 말입니다. 우리 일상으로 치면 현관 비밀번호, 통장 비밀번호, 신용카드 뒷면의 세 자리 숫자 같은 것들이에요. 하나라도 남에게 새어 나가면 큰일 나는 정보들이죠.
프로그램에서 대표적인 비밀에는 이런 것들이 있습니다.
- API 키(API Key) — 외부 서비스를 쓸 때 "나는 정당한 사용자입니다"를 증명하는 출입증. 날씨 API, 지도 API, 그리고 요즘 많이 쓰는 API 기반 AI 서비스 키가 다 여기에 해당합니다. 유료 서비스라면 이 키로 쓴 만큼 돈이 청구됩니다.
- 데이터베이스 비밀번호 — 회원 정보나 주문 내역이 담긴 창고(데이터베이스)의 열쇠. 새어 나가면 고객 개인정보가 통째로 털릴 수 있습니다.
- 토큰(Token) — 로그인한 사용자를 잠시 대신하는 임시 출입증. 이게 유출되면 남이 나인 척 행세할 수 있어요.
- 결제·클라우드 인증 정보 — 결제 대행사 키, AWS 같은 클라우드 계정 열쇠. 이건 유출되면 정말로 돈과 직결됩니다.
비밀과 헷갈리기 쉬운 게 하나 있어요. 바로 '설정값'입니다. 예를 들어 "한 페이지에 글을 몇 개 보여줄지", "서비스 이름이 뭔지" 같은 값도 코드 바깥에 두면 편한데, 이건 남이 봐도 아무 문제 없으니 비밀이 아니에요. 둘 다 코드 바깥으로 빼서 관리한다는 점은 같지만, 비밀은 절대 저장소에 안 올리고, 일반 설정값은 올려도 됩니다. 이 구분만 헷갈리지 않으면 됩니다. "남이 보면 곤란한가?"를 기준으로 나누세요.
여기서 초보들이 가장 많이 하는 오해를 짚어드릴게요. "내 코드는 아무도 안 볼 텐데 뭐 어때"라는 생각입니다. 천만의 말씀이에요. 뒤에서 자세히 설명하겠지만, 코드는 여러분 생각보다 훨씬 쉽게, 훨씬 널리 퍼집니다. 그리고 한 번 퍼진 비밀은 주워 담을 수 없습니다.
왜 코드나 저장소에 넣으면 위험한가
"비밀을 코드에 그냥 쓰면 안 된다"는 말은 많이 들으셨을 겁니다. 그런데 왜 안 되는지를 제대로 이해해야 습관이 잡힙니다. 위험은 크게 세 갈래예요.
첫째, 공개 저장소는 말 그대로 전 세계에 공개됩니다. GitHub 같은 곳에 코드를 올릴 때, 무료 계정에서 무심코 만들면 대부분 '공개(public)' 상태가 됩니다. 이건 여러분 코드가 인터넷 아무나 검색해서 볼 수 있다는 뜻이에요. 게다가 나쁜 사람들은 이런 공개 저장소를 자동으로 훑는 프로그램(봇)을 돌립니다. "sk-로 시작하는 문자열", "password = 로 시작하는 줄"만 골라서 몇 초 만에 수집해 가요. 사람이 일일이 찾는 게 아니라 기계가 자동으로 긁어가기 때문에, 올린 지 몇 분 만에 털리는 경우도 흔합니다.
둘째, 비공개로 올려도 안심할 수 없습니다. "그럼 비공개(private)로 하면 되잖아요?"라고 하실 텐데, 그것도 완벽하진 않아요. 함께 일하는 동료, 나중에 합류할 팀원, 실수로 공개 전환하는 순간, 협업 도구와 연결되는 지점 — 비밀이 새어 나갈 틈은 생각보다 많습니다. 애초에 코드와 비밀을 분리해두면 이런 걱정 자체를 할 필요가 없어지죠.
셋째, 이게 가장 무서운데 — 한 번 올라간 비밀은 'git 히스토리'에 영원히 남습니다. 여기가 초보들이 크게 당하는 함정이에요. git(깃)이라는 도구는 여러분이 코드를 고칠 때마다 그 모든 변경 기록을 사진처럼 차곡차곡 저장합니다. 그래서 실수로 비밀을 올렸다가 "앗!" 하고 지운 뒤 다시 올려도, 지우기 전의 옛날 기록 속에는 그 비밀이 그대로 남아 있어요. 화면에서는 안 보이지만, 조금만 파고들면 누구나 과거 기록을 들춰볼 수 있습니다.
제 지인 중에도 이걸 뼈저리게 겪은 분이 있습니다. 취미로 만든 작은 프로그램에 결제 서비스 키를 잠깐 넣어 테스트하고, "곧 지울 거니까" 하며 공개 저장소에 올렸대요. 다음 날 아침, 낯선 결제 시도 알림이 수십 건 쌓여 있었다고 합니다. 다행히 결제사에서 이상 거래로 막아줘서 실제 피해는 없었지만, 그 하루를 얼마나 마음 졸이며 보냈는지 모릅니다. "잠깐이면 괜찮겠지"가 통하지 않는 세계라는 걸, 그렇게 배운 거죠.
정리하면, 비밀을 코드에 박는 순간 여러분은 세 가지 위험을 동시에 떠안습니다. 공개 노출, 협업 과정의 유출, 그리고 지워도 남는 흔적. 이 셋을 한 방에 없애는 방법이 바로 다음에 이야기할 '환경변수'입니다.
환경변수가 뭔가요
이제 오늘의 주인공입니다. 환경변수(environment variable)는 이름이 좀 딱딱하지만, 개념은 아주 단순해요. "프로그램이 실행되는 환경(컴퓨터·서버)에 따로 저장해둔 값"을 말합니다. 코드 안에 값을 직접 쓰지 않고, 코드 바깥의 안전한 공간에 값을 넣어두는 거예요.
다시 비유로 가볼게요. 코드는 '요리 레시피'입니다. 레시피에는 "소금 한 스푼을 넣으세요"라고만 적혀 있죠. 소금이 어느 통에 담겨 있는지는 레시피에 안 적습니다. 부엌마다 소금통 위치가 다르니까요. 환경변수도 똑같아요. 코드에는 "API 키라는 값을 가져와 쓰라"고만 적고, 실제 키 값은 실행되는 컴퓨터의 '소금통'에서 그때그때 꺼냅니다. 같은 코드라도 내 컴퓨터에서는 내 키를, 실제 서버에서는 서버용 키를 쓰게 되는 거죠.
초보 단계에서 환경변수를 만나는 방식은 크게 두 갈래입니다. 내 컴퓨터에서 개발할 때 쓰는 .env 파일과, 실제로 서비스가 돌아가는 배포 환경에서 설정하는 값입니다. 이 둘을 표로 비교해볼게요.
| 구분 | 내 컴퓨터(개발 중) | 실제 배포 환경(운영 중) |
|---|---|---|
| 어디에 저장? | .env라는 이름의 파일 하나에 적어둠 | 서버·클라우드·배포 서비스의 '환경변수 설정' 화면에 입력 |
| 모습 | API_KEY=sk-abc123 처럼 한 줄에 하나씩 | 이름/값 칸에 각각 입력하는 웹 화면인 경우가 많음 |
| 누가 보나? | 내 컴퓨터에만 있음(절대 git에 안 올림) | 배포 서비스 관리자만 접근 |
| 비유 | 내 집 부엌의 개인 금고 | 회사 건물의 공용 금고실 |
| 핵심 규칙 | .gitignore로 저장소에서 반드시 제외 | 화면에 입력만 하면 코드엔 안 남음 |
표에서 가장 중요한 건 맨 아랫줄입니다. .env 파일은 편리하지만, 절대로 git 저장소에 올라가면 안 됩니다. 이 파일이야말로 비밀이 몽땅 담긴 금고 문서니까요. 그럼 어떻게 안 올라가게 막을까요? 다음 섹션에서 딱 그걸 다룹니다.
전체 흐름을 한 장의 그림으로 정리하면 이렇습니다. 비밀이 코드와 어떻게 분리되어 각 환경으로 흘러가는지 한눈에 보세요.
서비스에서 키 받음
.env / 서버 설정
값은 안 씀
환경에서 주입
보시다시피 실제 비밀 값이 코드에 등장하는 지점이 어디에도 없습니다. 이게 핵심이에요. 코드는 "이름표"만 알고, 실제 "내용물"은 늘 바깥 금고에서 온다는 것.
왜 이 방식이 그렇게 좋은지 한 번 더 짚고 넘어갈게요. 첫째, 코드를 마음 놓고 공유할 수 있습니다. 코드엔 비밀이 하나도 없으니, 누구에게 보여줘도 걱정이 없어요. 둘째, 환경마다 다른 값을 쉽게 갈아 끼울 수 있습니다. 내 컴퓨터에선 연습용 키를, 실제 서비스에선 진짜 키를 쓰는데, 코드는 단 한 줄도 안 고쳐도 됩니다. 셋째, 비밀이 바뀌어도 코드는 그대로입니다. 키를 새것으로 교체해도 금고 안의 값만 바꾸면 되니, 코드를 다시 손댈 일이 없어요. 처음엔 "번거롭게 파일을 왜 따로 만들지?" 싶지만, 조금만 써보면 이게 얼마나 편하고 안전한지 금방 체감하실 겁니다.
.env 파일은 git에 올리지 않기 — .gitignore
자, 실전입니다. .env 파일을 만들었으면 이제 이게 실수로라도 저장소에 안 올라가게 막아야 합니다. 이때 쓰는 것이 .gitignore(깃 이그노어)라는 파일이에요. 이름 그대로 "git아, 이건 무시해(ignore)"라고 알려주는 목록입니다. 비유하자면 "이삿짐 쌀 때 절대 트럭에 싣지 말 물건 목록"이에요. 여기에 적어두면 아무리 짐을 싸도 그 물건은 빠집니다.
초보자가 딱 이 순서만 따라 하면 사고를 예방할 수 있습니다.
비밀은 .env 파일에 모으기
코드에 흩어져 있던 API 키, 비밀번호 같은 값을 전부 .env라는 파일 하나에 이름=값 형태로 옮겨 적습니다. 예: WEATHER_API_KEY=sk-abc123. 코드 쪽에서는 이제 값 대신 이 '이름'만 불러 씁니다.
.gitignore 파일에 .env 추가
프로젝트 폴더에 .gitignore라는 파일을 만들고(이미 있으면 열고), 그 안에 .env라고 한 줄 적습니다. 이 한 줄이 "이 파일은 저장소에 싣지 마"라는 뜻이에요. 이게 가장 중요한 안전장치입니다.
정말 빠졌는지 확인
코드를 올리기 전에 "올라갈 파일 목록"을 한 번 눈으로 확인하세요. 그 목록에 .env가 없어야 정상입니다. 만약 보인다면 아직 무시 설정이 안 된 것이니 2번을 다시 점검하세요.
대신 .env.example로 안내만 남기기
동료(또는 미래의 나)가 "무슨 값을 채워야 하지?" 헷갈리지 않도록, 값은 비운 채 이름만 적은 .env.example 파일을 만들어 이건 저장소에 올립니다. 예: WEATHER_API_KEY=. 실제 값 없이 '빈칸 안내서'만 공유하는 거죠.
.gitignore에 .env를 적는 건 비밀을 올리기 전에 해야 효과가 있습니다. 이미 한 번 올라간 뒤에 추가하면, 그 파일은 계속 추적될 수 있고 무엇보다 과거 기록엔 이미 남은 상태예요. 그래서 새 프로젝트를 시작하면 코드 한 줄 쓰기 전에 .gitignore부터 만드는 습관을 들이세요.배포처별로 비밀을 보관하는 법
.env는 어디까지나 내 컴퓨터에서 개발할 때 쓰는 방식입니다. 이걸 그대로 서버에 올릴 순 없죠(올리면 안 되니까요). 그럼 실제로 서비스가 돌아가는 곳에서는 비밀을 어떻게 넣어줄까요? 배포하는 장소마다 방법이 조금씩 다른데, 원리는 전부 똑같습니다. "코드 바깥의 안전한 칸에 값을 넣어두고, 실행할 때 꺼내 쓴다." 대표적인 세 곳만 보겠습니다.
1) 서버에 직접 올릴 때 — 서버 환경변수
여러분이 클라우드에 나만의 서버를 하나 빌려서 프로그램을 돌린다고 합시다. 이런 서버 방식이 궁금하시면 AWS EC2 이야기를 함께 보세요. 이 경우엔 그 서버 컴퓨터 자체에 환경변수를 등록합니다. 서버에 "이 이름에는 이 값이 들어 있다"고 미리 심어두면, 프로그램이 켜질 때 그 값을 읽어 씁니다. .env 파일을 서버에만 두는 방식도 있는데(물론 저장소엔 안 올림), 어느 쪽이든 값이 서버 안에만 머물고 코드엔 안 들어간다는 원칙은 같아요.
여기서 초보들이 자주 하는 실수 하나. 내 컴퓨터에선 잘 되던 프로그램이 서버에 올리니 "키가 없다"며 안 돌아가는 경우입니다. 이유는 간단해요. .env 파일은 내 컴퓨터에만 있고 저장소엔 안 올렸으니, 서버에는 그 값이 없는 겁니다. 당연한 일이에요. 그러니 서버에 배포할 땐 "이 서버에도 환경변수를 따로 넣어줬는가?"를 꼭 확인하세요. 코드만 올린다고 비밀이 따라오는 게 아니라는 걸 기억하시면 됩니다.
2) 자동 배포를 쓸 때 — GitHub Actions Secrets
요즘은 코드를 올리면 자동으로 검사하고 배포까지 해주는 자동화를 많이 씁니다. 대표적인 게 GitHub Actions인데, 자세한 내용은 GitHub Actions 글에서 다뤘어요. 이 자동화 로봇도 배포할 때 비밀이 필요하겠죠? 그렇다고 자동화 지시서(코드)에 비밀을 적으면, 그것도 저장소에 올라가버립니다. 도루묵이죠.
그래서 GitHub은 'Secrets'라는 별도의 금고를 제공합니다. 저장소 설정 화면에 이름과 값을 입력해두는 잠긴 서랍이에요. 여기에 넣은 값은 다시 볼 수 없고(입력만 가능), 자동화가 돌 때만 코드가 아닌 '이름'으로 안전하게 불러 씁니다. 화면에 찍히는 로그에서도 자동으로 가려져요(***로 표시). 자동 배포를 쓰신다면 비밀은 반드시 이 Secrets에 넣으세요.
3) 클라우드를 본격적으로 쓸 때 — 비밀 관리 서비스
규모가 커지면 클라우드 회사들이 '비밀 관리 서비스(Secrets Manager)'라는 전문 금고실을 따로 제공합니다. 여러 서버와 프로그램이 공유하는 비밀을 한곳에서 관리하고, 누가 언제 꺼내 갔는지 기록도 남기고, 정해진 주기로 자동으로 비밀번호를 바꿔주기도 해요. 초보 단계에서 당장 쓸 필요는 없지만, "나중에 커지면 이런 전문 금고도 있구나" 정도만 알아두시면 됩니다.
이미 올려버렸다면? — 침착하게 폐기·재발급
여기까지 읽고 "어? 나 이미 올렸는데..." 하고 가슴이 철렁하신 분, 분명 계실 겁니다. 저도 그랬어요. 괜찮습니다. 중요한 건 지금부터 뭘 하느냐예요. 여기서 가장 흔한 착각이 "코드에서 그 줄만 지우고 다시 올리면 되겠지"인데, 앞서 말했듯 git 히스토리엔 그대로 남기 때문에 그것만으론 절대 안전해지지 않습니다.
진짜 해결책은 발상을 바꾸는 겁니다. 이미 노출된 비밀은 '되찾는' 게 아니라 '버리는' 겁니다. 대문에 써놓은 현관 비밀번호가 이미 남에게 보였다면, 그 번호를 아무리 지워봐야 소용없죠. 답은 하나예요. 비밀번호 자체를 새것으로 바꾸는 것. 그럼 옛날에 새어 나간 번호는 아무 쓸모가 없어집니다. 이걸 순서대로 하면 이렇습니다.
당황하지 말고 '노출됐다'고 인정하기
공개 저장소에 한 번이라도 올라갔다면 "이미 남이 봤을 수 있다"고 최악을 가정하세요. "몇 분밖에 안 올렸으니 괜찮겠지"는 위험한 생각입니다. 자동 수집 봇에겐 몇 분도 충분하거든요.
노출된 키를 즉시 '폐기(무효화)'
해당 서비스(날씨 API든, AI 서비스든)의 관리 화면에 들어가, 그 키를 삭제하거나 사용 중지합니다. 이렇게 하면 누가 그 키를 주워 갔어도 더는 못 씁니다. 새는 수도꼭지를 잠그는 것과 같아요.
새 키를 '재발급'
같은 화면에서 새 키를 하나 발급받습니다. 그리고 이 새 키는 이제 배운 대로 절대 코드에 안 쓰고 환경변수(.env 또는 서버 설정)에만 넣습니다.
사용 내역·요금 확인
유료 서비스였다면 노출 기간에 이상한 사용량이나 요금이 없었는지 확인하세요. 낯선 사용이 보이면 서비스 고객센터에 바로 문의합니다. 대부분 상황을 설명하면 도움을 받을 수 있어요.
히스토리 정리는 '보너스'
과거 기록에서 비밀을 지우는 도구들도 있습니다만, 이건 좀 까다로워요. 하지만 2·3번(폐기·재발급)만 제대로 했다면 옛 기록에 남은 키는 이미 죽은 열쇠라 큰 위협이 아닙니다. 히스토리 정리는 여유 있을 때 정돈하는 마무리 정도로 생각하세요.
최소 권한과 키 회전 — 두 가지 안전 원칙
비밀을 잘 숨기는 것만큼 중요한 두 가지 습관이 있습니다. 어렵지 않아요. 상식적인 이야기입니다.
첫째, 최소 권한 원칙입니다. 열쇠를 만들 때, 딱 필요한 문만 열리는 열쇠를 만드는 겁니다. 우리 집에 손님이 왔다고 현관·안방·금고 열쇠를 통째로 주진 않죠. 현관 열쇠 하나면 충분합니다. 키도 마찬가지예요. "날씨 정보만 읽어오는" 프로그램이라면, 그 키에는 '읽기'만 허용하고 '삭제'나 '결제' 같은 강한 권한은 빼세요. 그러면 혹시 그 키가 새어 나가도 피해가 확 줄어듭니다. 도둑이 열쇠를 주웠는데 창고 문밖에 못 연다면, 큰일은 안 나잖아요.
둘째, 키 회전 원칙입니다. 회전(rotation)이라는 말이 어렵게 들리지만, 그냥 비밀번호를 주기적으로 새것으로 바꾸는 것입니다. 은행이 "비밀번호를 정기적으로 변경하세요"라고 권하는 것과 똑같아요. 오래 안 바꾼 열쇠는 그만큼 새어 나갔을 확률이 높으니, 몇 달에 한 번씩 새 키로 갈아주는 겁니다. 특히 팀원이 나가거나, 뭔가 찜찜한 일이 있었을 땐 미루지 말고 바꾸세요.
이 두 가지를 한 문장으로 묶으면 이렇습니다. "약한 열쇠를 자주 바꿔 쓴다." 강한 열쇠 하나를 영원히 쓰는 것보다, 딱 필요한 만큼만 열리는 약한 열쇠를 적당히 자주 바꿔 쓰는 편이 훨씬 안전합니다. 혹시 새어 나가도 피해가 작고, 얼마 못 가 무용지물이 되니까요.
이 두 원칙은 AI가 짜준 코드를 쓸 때 특히 중요합니다. AI는 편의를 위해 종종 강력한 권한의 키를 예시로 넣거나, 비밀을 코드에 박아두는 옛날 방식으로 코드를 짜주기도 하거든요. AI 코드를 쓸 때 주의할 점은 AI 코딩 주의사항 글에서 더 자세히 다뤘으니 함께 보시길 권합니다.
초보가 흔히 하는 실수 & 해결
제가 직접 겪었거나, 옆에서 숱하게 본 실수들을 정리했습니다. 오른쪽 해결책만 챙기셔도 웬만한 사고는 다 피할 수 있어요.
👎 흔한 실수
- AI가 준 코드에 박힌 키를 그대로 두고 저장소에 올린다
.gitignore를 안 만들고 코드부터 올린다- 비밀을 지우고 다시 올리면 안전해진다고 믿는다
- "비공개 저장소니까 괜찮다"며 코드에 그냥 박는다
- 노출됐는데 히스토리 청소부터 붙잡고 시간을 허비한다
- 키 하나에 모든 권한을 다 주고, 한 번 만들면 영영 안 바꾼다
👍 이렇게 해결
- 키를
.env로 옮기고 코드엔 '이름'만 남긴다 - 새 프로젝트는 코드보다
.gitignore를 먼저 만든다 - 노출됐으면 무조건 폐기 → 재발급, 지우기론 부족
- 비공개여도 코드와 비밀은 항상 분리한다
- 사고 시 1순위는 키 폐기·재발급, 청소는 나중
- 최소 권한 키를 쓰고, 주기적으로 회전시킨다
표를 보면 아시겠지만, 해결책은 하나같이 어렵지 않습니다. 대부분 "습관"의 문제예요. 처음 두어 번만 의식적으로 하면, 그다음부턴 몸이 알아서 .gitignore부터 만들고 있을 겁니다. 저도 그랬으니까요.
자주 묻는 질문 (FAQ)
Q. 저는 그냥 혼자 연습용으로 만드는 건데, 이런 것까지 신경 써야 하나요?
A. 네, 오히려 연습할 때 습관을 들여야 합니다. 연습이라고 대충 코드에 키를 박다 보면, 나중에 진짜 서비스를 만들 때도 똑같이 실수해요. 게다가 연습용이라도 유료 API 키가 털리면 요금은 실제로 청구됩니다. 처음부터 바르게 하는 게 훨씬 쉽고 안전합니다.
Q. .env 파일 자체가 해킹당하면 어떡하죠?
A. 좋은 질문입니다. .env는 내 컴퓨터에만 있고 저장소엔 안 올라가므로, 인터넷에 노출되지 않습니다. 즉 내 컴퓨터 자체가 뚫리지 않는 한 안전해요. 반면 코드에 박아 저장소에 올린 비밀은 전 세계에 노출됩니다. 둘의 위험 수준은 비교가 안 됩니다. .env는 훨씬, 훨씬 안전한 방식이에요.
Q. AI에게 코드를 부탁할 때 비밀 문제를 어떻게 예방하나요?
A. 부탁할 때 아예 "API 키는 코드에 넣지 말고 환경변수에서 읽어오게 해줘"라고 명시하세요. 그리고 AI가 준 코드를 올리기 전에, sk-나 password, key 같은 단어가 값과 함께 박혀 있지 않은지 눈으로 한번 훑어보는 습관을 들이면 좋습니다.
Q. 환경변수 이름은 왜 대문자로 쓰나요? 규칙인가요?
A. 강제 규칙은 아니지만, API_KEY처럼 대문자와 밑줄로 쓰는 게 오랜 관례입니다. 코드 안의 다른 값들과 한눈에 구분되어 실수를 줄여주거든요. 관례를 따르면 다른 사람도 "아, 이건 환경변수구나" 하고 금방 알아봅니다.
Q. 비밀이 아닌 값(예: 서비스 주소)도 환경변수로 빼야 하나요?
A. 꼭 그래야 하는 건 아니지만, 환경마다 바뀌는 값이라면 환경변수로 빼면 편리합니다. 예를 들어 개발용 주소와 실제 서비스 주소가 다르다면, 코드는 그대로 두고 환경변수만 바꿔 끼우면 되니까요. 비밀이 아니어도 "환경마다 달라지는 값"은 환경변수의 좋은 후보입니다.
마무리 체크리스트
오늘 내용이 처음엔 낯설었을 수 있지만, 핵심은 결국 문장 하나로 압축됩니다. "비밀은 코드에서 떼어내 금고에 넣고, 필요할 때 꺼내 쓴다." 이거 하나만 몸에 배면, 여러분은 이미 초보를 벗어난 겁니다. 올리기 전에 아래 목록만 훑어보세요.
- ✅ 코드 안에 API 키·비밀번호·토큰이 직접 박혀 있지 않다
- ✅ 비밀은 전부
.env파일 또는 배포처의 환경변수에 들어 있다 - ✅
.gitignore에.env를 넣어 저장소에서 제외했다 - ✅ 올릴 파일 목록에
.env가 없는 것을 눈으로 확인했다 - ✅ 동료를 위해 값 없는
.env.example만 공유했다 - ✅ 자동 배포를 쓴다면 비밀을 GitHub Secrets 같은 금고에 넣었다
- ✅ 혹시 이미 노출됐다면 폐기 → 재발급을 마쳤다
- ✅ 키는 최소 권한으로 만들고, 가끔 새것으로 회전한다
여기까지 오신 여러분, 정말 잘하셨습니다. 이 습관 하나가 앞으로 여러분을 수많은 사고에서 지켜줄 거예요. 저처럼 아찔한 경험을 하기 전에 미리 배우셨으니, 이미 저보다 한 수 위입니다. 다음 글에서는 이렇게 안전하게 관리한 비밀을 실제 서버에 올려 서비스를 돌리는 이야기, AWS EC2로 나만의 서버 갖기로 자연스럽게 이어가 보겠습니다. 그리고 외부 서비스와 대화하는 창구인 API의 기초가 아직 낯설다면 그 글부터 보고 오셔도 좋아요. 오늘도 한 걸음 나아가신 걸 축하드립니다. 겁먹지 마세요, 별거 아니었죠?
(2026년 8월 기준 작성 — 화면·정책은 바뀔 수 있으니 각 서비스의 공식 문서를 함께 확인하세요.)
← 기술 블로그 목록으로