사이드 프로젝트도 지켜야 합니다 — '헛간을 보호하라'는 말의 의미

본격적인 프로젝트만 보안 신경 쓰면 된다고요?

개발자라면 누구나 하나쯤 굴리고 있는 게 있죠. 개인 블로그, 토이 프로젝트, 사내에서 급하게 만든 어드민 툴, 아니면 주말에 재미로 올린 작은 서비스. 이런 것들을 영어에서는 흔히 "shed(헛간)"라고 비유하는데요, 집(메인 프로덕트)은 문 잠그고 보안 카메라까지 달면서, 뒷마당 헛간은 문도 안 잠그고 방치하는 경우가 정말 많거든요.

Dylan Butler의 글 "Protect your shed"는 바로 이 문제를 정면으로 다루고 있어요. 우리가 소홀하게 관리하는 작은 프로젝트들이 실제로 얼마나 큰 보안 위험이 될 수 있는지, 그리고 최소한의 노력으로 어떻게 지킬 수 있는지를 이야기합니다.

왜 작은 프로젝트가 위험한가

"어차피 나만 쓰는 건데 뭐" — 이 생각이 문제의 시작이에요. 사이드 프로젝트에 쓰는 API 키가 메인 서비스와 같은 경우도 있고, AWS 계정이 연결되어 있거나, 같은 비밀번호를 재사용하는 경우도 흔하죠. 공격자 입장에서는 방어가 단단한 메인 서비스를 뚫는 것보다, 보안이 허술한 사이드 프로젝트를 통해 우회하는 게 훨씬 쉬워요.

이게 뭐냐면, 마치 아파트 현관문에는 디지털 도어락을 달아놓고 베란다 창문은 열어둔 것과 같아요. 도둑은 당연히 창문으로 들어오겠죠. 실제로 많은 보안 사고가 잊혀진 스테이징 서버, 방치된 사이드 프로젝트, 관리 안 되는 내부 툴에서 시작되거든요.

특히 요즘처럼 GitHub에 퍼블릭 레포로 올리거나, Vercel이나 Netlify에 무료로 배포하는 경우가 많은 시대에는 더 주의가 필요해요. 환경변수에 시크릿을 넣어두고 .env 파일을 .gitignore에 안 넣는 실수, 한 번쯤은 해보셨을 거예요.

최소한의 보호 방법들

그렇다고 사이드 프로젝트에 엔터프라이즈급 보안 체계를 갖추라는 건 아니에요. 핵심은 "최소한의 위생 관리"를 하자는 거예요.

첫째, 시크릿 분리가 기본 중의 기본이에요. 사이드 프로젝트용 API 키와 메인 서비스 키를 절대 같이 쓰면 안 돼요. AWS 계정도 가능하면 분리하고, 최소한 IAM 권한이라도 제한을 걸어야 해요. 이게 뭐냐면, 열쇠를 용도별로 다르게 만드는 거라고 보면 돼요. 헛간 열쇠를 잃어버려도 집은 안전한 거죠.

둘째, 자동화된 시크릿 스캐닝을 활용하세요. GitHub에는 무료로 제공되는 Secret Scanning 기능이 있고, git-secrets 같은 도구를 pre-commit hook으로 설정해두면 실수로 시크릿을 커밋하는 걸 막아줘요.

셋째, 의존성 관리를 자동화하세요. Dependabot이나 Renovate를 설정해두면 알려진 취약점이 있는 패키지를 자동으로 알려줘요. 사이드 프로젝트는 만들고 나서 의존성 업데이트를 안 하는 경우가 대부분인데, 시간이 지나면 취약점이 쌓이거든요.

넷째, 배포된 서비스는 주기적으로 점검하세요. 더 이상 안 쓰는 서비스라면 내리는 게 최선이에요. 방치된 서버가 가장 위험한 서버예요.

업계에서도 이 문제를 심각하게 보고 있어요

이 이야기는 최근 공급망 공격(supply chain attack)의 맥락에서 더 중요해졌어요. 개인 npm 패키지나 PyPI 패키지를 관리하는 개발자의 계정이 뚫리면서 수많은 다운스트림 프로젝트가 영향을 받는 사례가 반복되고 있거든요. 유지보수가 안 되는 작은 오픈소스 프로젝트가 공격 벡터가 되는 거예요.

한편 GitHub, GitLab 같은 플랫폼들도 이 문제를 인식하고 무료 티어에서 보안 기능을 확대하고 있어요. GitHub의 경우 2023년부터 모든 퍼블릭 레포에 시크릿 스캐닝을 기본 활성화했고, Dependabot 알림도 무료로 제공하고 있죠.

한국 개발자에게 주는 시사점

한국 개발자 커뮤니티에서도 사이드 프로젝트 문화가 활발하잖아요. 포트폴리오용으로, 혹은 순수한 재미로 만드는 프로젝트들이 많은데, 보안까지 신경 쓰는 경우는 생각보다 드물어요. 특히 취업 준비를 위해 GitHub에 올리는 프로젝트에서 DB 접속 정보나 API 키가 그대로 노출된 경우를 종종 보게 되는데, 이건 보안 위험일 뿐 아니라 오히려 마이너스 포인트가 될 수 있어요.

당장 할 수 있는 건 간단해요. 지금 GitHub 레포 목록을 쭉 훑어보면서, 방치된 레포에 시크릿이 노출되어 있지 않은지 확인하는 거예요. 그리고 더 이상 쓰지 않는 배포 서비스가 있다면 내려주세요.

한줄 정리

보안은 메인 서비스에만 필요한 게 아니에요. 잊혀진 헛간 하나가 전체 보안의 가장 약한 고리가 될 수 있습니다.

여러분의 사이드 프로젝트 보안 관리는 어떻게 하고 계세요? 혹시 시크릿 노출로 아찔했던 경험이 있다면 공유해주세요!