깃허브에 코드 올릴 때 절대 포함하면 안 되는 것들

1. 깃허브에 코드를 올릴 때 왜 보안 점검이 필요한가

1) 저장소는 생각보다 쉽게 공개됩니다

깃허브는 협업과 배포에 매우 편리하지만, 한 번 올라간 내용은 예상보다 넓게 퍼질 수 있습니다. 특히 팀 프로젝트나 오픈소스처럼 저장소를 외부와 공유하는 경우, 작은 실수 하나가 깃허브보안 문제로 이어질 수 있습니다. 그래서 코드를 올리기 전에는 “기능이 정상 동작하는가”만 볼 것이 아니라, “노출되면 안 되는 정보가 들어 있지 않은가”도 함께 확인해야 합니다.

2) 검색하는 이유는 대부분 이미 사고를 겪었거나 걱정되기 때문입니다

많은 사람이 gitignore, 시크릿노출, 레포보안 같은 키워드를 찾는 이유는 비슷합니다.
실수로 API 키를 커밋했거나, .env 파일이 올라갔거나, 인증서 정보가 노출될 뻔한 경험이 있는 경우가 많습니다. 이런 문제는 한 번 발생하면 단순 삭제로 끝나지 않고, 키 폐기와 재발급까지 이어질 수 있어 미리 점검하는 습관이 중요합니다.

3) 이 글에서는 무엇을 확인해야 하는지 정리합니다

이 글에서는 깃허브에 올릴 때 절대 포함하면 안 되는 항목과, 왜 문제가 되는지, 그리고 이를 줄이기 위해 어떤 점을 확인해야 하는지 설명합니다. 또한 gitignore를 어떻게 활용하면 좋은지, 실제로 자주 발생하는 시크릿노출 사례는 무엇인지도 함께 살펴보겠습니다. 마지막에는 어떤 상황에서 외부 점검 도구가 도움이 될 수 있는지도 자연스럽게 정리해보겠습니다.

2. 깃허브에 올리면 안 되는 대표적인 정보들

1) API 키와 토큰

가장 먼저 확인해야 할 것은 API 키, 접근 토큰, 비밀키입니다.
결제 서비스, 클라우드, 메신저, 소셜 로그인 등 다양한 서비스에서 사용되는 인증 정보는 저장소에 포함되면 바로 악용될 수 있습니다. 특히 테스트용이라고 생각해 올린 키도 실제 권한이 연결되어 있는 경우가 있어 시크릿노출 위험이 큽니다.

2) .env 파일과 환경설정 값

.env 파일은 개발 환경에서 자주 사용되지만, 그대로 커밋하면 민감한 설정이 한 번에 노출될 수 있습니다. 데이터베이스 주소, 관리자 비밀번호, 외부 서비스 키, 내부 접속 정보 등이 여기에 들어가는 경우가 많습니다.
그래서 깃허브보안을 이야기할 때 .env 제외는 거의 기본에 가깝고, gitignore에 반드시 포함하는 습관이 필요합니다.

3) 인증서, 개인 키, 배포용 설정 파일

SSL 인증서 자체보다 더 중요한 것은 개인 키나 관련 비밀 파일입니다. 이 정보가 유출되면 사이트 위장, 중간자 공격, 인증 관련 사고로 이어질 수 있습니다.
또 배포 설정 파일이나 서버 연결 정보가 들어 있는 스크립트도 주의해야 합니다. 단순한 설정처럼 보여도 실제로는 운영 환경 접근의 열쇠가 되는 경우가 있습니다.

4) 로그 파일과 디버그 출력

개발 과정에서 찍힌 로그에는 이메일, 토큰, 요청 헤더, 내부 경로 등이 남을 수 있습니다. 디버깅이 끝났다고 생각해도 로그 파일이 함께 올라가면 예기치 않은 정보가 빠져나갈 수 있습니다.
이런 부분은 한 번만 실수해도 레포보안에 영향을 줄 수 있으므로, 배포 전 로그 정리를 습관화하는 것이 좋습니다.

3. gitignore는 왜 중요하고 어떻게 써야 하나

1) gitignore는 단순 편의 기능이 아니라 기본 안전장치입니다

gitignore는 커밋에서 제외할 파일과 폴더를 정하는 기능입니다. 보통은 IDE 설정, 빌드 산출물, 임시 파일을 제외하는 용도로 알고 있지만, 보안 측면에서도 매우 중요합니다.
특히 .env, config.local, 인증서 파일, 개인 키, 백업 파일 같은 항목은 gitignore로 미리 막아두는 것이 좋습니다.

2) 무조건 다 넣는 것보다 기준을 정하는 것이 중요합니다

많은 파일을 무작정 제외하기보다, “배포 환경에서 다시 생성할 수 있는가”, “외부에 보여도 되는가”를 기준으로 판단하는 편이 좋습니다. 예를 들어 빌드 결과물은 다시 만들 수 있지만, 개인 키나 계정 토큰은 복구가 어렵습니다.
따라서 gitignore는 개발 편의만이 아니라 깃허브보안을 위한 선별 장치로 이해하는 것이 적절합니다.

3) 팀 프로젝트에서는 공통 규칙을 맞춰야 합니다

혼자 작업할 때는 실수해도 빨리 수정할 수 있지만, 팀 프로젝트에서는 한 명의 실수가 전체 저장소로 번질 수 있습니다. 그래서 팀 내에서 어떤 파일을 gitignore에 포함할지 미리 정해두는 것이 좋습니다.
특히 여러 명이 같은 레포를 사용할 때는 레포보안 기준이 통일되어 있어야 시크릿이 섞여 올라가는 일을 줄일 수 있습니다.

4. 시크릿노출은 왜 자주 발생할까

1) 로컬에서는 당연해 보여도 저장소에서는 위험할 수 있습니다

개발자는 로컬 환경에서 파일을 열어보는 데 익숙하기 때문에, 민감한 정보가 들어 있는지 체감이 약해질 수 있습니다. 예를 들어 테스트용 키, 샘플 계정, 내부 URL은 혼자 볼 때는 큰 문제처럼 느껴지지 않지만 공개 레포에서는 상황이 달라집니다.
이처럼 시크릿노출은 악의보다 습관과 실수에서 시작되는 경우가 많습니다.

2) 과거 커밋까지 함께 확인해야 합니다

파일을 삭제했다고 해서 끝나는 것은 아닙니다. 이미 과거 커밋에 남아 있으면 히스토리를 통해 다시 접근될 수 있기 때문입니다.
그래서 깃허브에 올리기 전에는 현재 파일만 보는 것이 아니라, 커밋 이력까지 확인하는 습관이 필요합니다. 이런 점에서 레포보안은 단순한 파일 관리보다 한 단계 더 넓은 개념이라고 볼 수 있습니다.

3) 브라우저와 배포 환경에서만 드러나는 문제도 있습니다

일부 취약점은 코드만 봐서는 놓치기 쉽고, 실제 브라우저에서 열어봐야 보이기도 합니다. 예를 들어 Mixed Content, 잘못된 CORS 설정, 불필요하게 열린 API 접근 범위 같은 것들입니다.
이런 부분은 일반적인 gitignore 관리만으로는 잡히지 않기 때문에, 기본적인 깃허브보안 점검과 함께 실제 노출 가능성까지 살피는 것이 좋습니다.

5. 레포보안에서 자주 놓치는 부분

1) 프론트엔드 코드에 들어간 민감 정보

프론트엔드라고 해서 안전하다고 생각하기 쉽지만, 브라우저에 내려가는 정보는 결국 사용자도 볼 수 있습니다. 따라서 비밀키, 내부 관리자 경로, 과도한 권한이 필요한 엔드포인트를 넣는 것은 피해야 합니다.
특히 API 주소와 권한 설정은 레포보안에서 자주 놓치는 부분입니다.

2) 보안 헤더와 HTTPS 설정

코드만 정상이어도 HTTPS 적용이 안 되어 있거나 보안 헤더가 부족하면 기본적인 보호 수준이 떨어질 수 있습니다. 인증서 상태, 보안 헤더, 쿠키 설정처럼 최소한의 항목을 확인하는 습관이 중요합니다.
이런 기본 점검은 고가의 복잡한 도구가 아니어도 시작할 수 있으며, 간단한 웹 점검 도구를 활용해 빠르게 확인하는 경우가 많습니다.

3) CORS와 쿠키 정책

CORS가 너무 넓게 열려 있거나 쿠키 보안 옵션이 약하면, 의도치 않은 접근이 가능해질 수 있습니다. 개발 중에는 편리하게 열어두는 경우가 있지만, 배포 후에도 그대로 남아 있으면 문제가 됩니다.
따라서 레포보안은 저장소 내용뿐 아니라 실제 서비스가 어떻게 동작하는지까지 함께 보는 관점이 필요합니다.

6. 기본 점검만으로도 줄일 수 있는 위험

1) 작은 체크리스트가 큰 사고를 막습니다

배포 전에 .env, 인증서 파일, 로그, API 키, 테스트 계정 정보가 포함되지 않았는지 확인하는 것만으로도 위험을 많이 줄일 수 있습니다.
특히 gitignore가 제대로 작동하는지, 실수로 추적된 파일은 없는지 확인하는 습관은 매우 중요합니다. 이런 기본 점검은 깃허브보안의 출발점이라고 볼 수 있습니다.

2) URL 기반 점검 도구가 도움이 되는 경우

가끔은 저장소를 직접 하나씩 뒤지는 것만으로 부족할 수 있습니다. 공개된 웹사이트 URL을 입력해 기본 보안 상태를 빠르게 확인하는 도구를 활용하면, HTTPS, 인증서, 보안 헤더, 쿠키, CORS, 브라우저 취약점처럼 실제 노출과 연결되는 부분을 훑어볼 수 있습니다.
이런 방식은 복잡한 보안 설정 툴보다 가볍게 시작하기에 적합한 편입니다.

3) 개발 초기보다 배포 직전에 더 자주 점검해야 합니다

초기 개발 단계에서는 실험적인 설정이 많아 실수가 잦고, 배포 직전에는 정리되지 않은 파일이 남아 있는 경우가 많습니다. 그래서 한 번만 확인하는 것보다, 중요한 브랜치 병합이나 배포 전에 반복적으로 확인하는 편이 좋습니다.
이 과정에서 시크릿노출 가능성을 사전에 잡아내면 이후 대응 비용이 크게 줄어듭니다.

7. 결론: 어떤 상황에서 이런 점검이 필요할까

1) 오픈소스 공개 전, 팀 협업 전, 배포 직전에 특히 중요합니다

깃허브에 코드를 올릴 때 절대 포함하면 안 되는 것들은 단순히 몇 개의 파일이 아니라, 계정 정보와 접근 권한을 가진 민감한 데이터 전체라고 보는 것이 맞습니다. 특히 오픈소스를 공개하기 전, 팀 저장소를 정리할 때, 실서비스 배포 직전에 이런 점검이 유용합니다.
이때 gitignore를 정리하고, .env와 토큰 노출 여부를 확인하며, 실제 서비스의 기본 보안 상태까지 함께 보는 것이 좋습니다.

2) 직접 전화해 확인하는 방식과는 역할이 다릅니다

보안 관련 문의를 직접 전화로 해결하는 방법은 필요한 답변을 빠르게 얻는 데는 도움이 될 수 있지만, 매번 사람에게 물어봐야 하고 확인 범위도 제한적일 수 있습니다. 반면 URL 기반 점검이나 기본 보안 검사 도구는 현재 상태를 눈으로 빠르게 확인하는 데 강점이 있습니다.
즉, 전화 상담이 설명을 듣는 방식이라면, 자동 점검은 현재 설정과 노출 상태를 빠르게 확인하는 방식에 가깝습니다. 이런 차이를 이해하면 레포보안과 깃허브보안을 더 현실적으로 관리할 수 있습니다.