우주국도 털리는 시대, 보안은 결국 '습관'의 문제입니다

안녕하세요. 풀링포레스트 CTO 송찬영입니다.

2025년의 마지막 날, 개발자 커뮤니티를 뜨겁게 달군 소식이 하나 있었습니다. 바로 유럽우주국(ESA)이 또다시 해킹 피해를 입었다는 뉴스였습니다. 연말연시 들뜬 분위기 속에서 접한 이 소식은, 기술 조직을 이끄는 입장에서 등골이 서늘해지는 경각심을 주기에 충분했습니다.

보도에 따르면 ESA는 이번 공격으로 약 200GB에 달하는 데이터를 탈취당했다고 합니다. ESA 측은 "핵심 시스템이 아닌 외부 협업용 서버 일부가 영향을 받았다"며 파장을 축소하려 했지만, 공격자들이 주장하는 탈취 목록을 보면 결코 가볍게 넘길 사안이 아닙니다. 소스 코드, CI/CD 파이프라인 구성, API 액세스 토큰, Terraform 파일, 그리고 하드코딩된 자격증명(Credentials)까지 포함되어 있었으니까요.

솔직히 고백하자면, 이 목록을 보며 남 일 같지 않아 식은땀이 흘렀습니다.

'변두리'가 가장 약한 고리입니다

우리는 흔히 보안이라고 하면 프로덕션 DB나 결제 서버 같은 '핵심 성(Castle)'을 지키는 것을 먼저 떠올립니다. 하지만 해커들은 정문을 뚫기보다 창문이 열려 있는 허름한 별채를 노립니다.

이번 ESA 사례에서도 공격자들은 엔지니어링 및 과학 협업을 위해 열어둔 '외부 서버'를 통해 침투했습니다. 개발자들이 연구 목적으로, 혹은 외부 파트너와 데이터를 주고받기 위해 빠르게 띄워둔 서버들이었을 겁니다.

저희 풀링포레스트 팀에서도 자주 겪는 딜레마입니다. 새로운 AI 기능을 테스트하기 위해, 혹은 클라이언트와의 빠른 협업을 위해 임시로 서버를 띄우거나 저장소를 생성하는 경우가 많습니다. "이건 잠깐 쓰고 지울 거니까", "중요한 데이터는 없으니까"라고 생각하며 보안 그룹 설정을 느슨하게 하거나, 편의를 위해 .env 파일을 리포지토리에 포함시키는 실수를 범하곤 합니다. 하지만 그 '잠깐'이 영원이 되고, 잊혀진 서버는 해커들의 훌륭한 놀이터가 됩니다.

소스 코드보다 무서운 건 '하드코딩된 비밀'입니다

이번 유출 내역 중 가장 뼈아픈 부분은 '하드코딩된 자격증명'과 'Terraform 파일'입니다.

인프라를 코드로 관리하는 IaC(Infrastructure as Code)가 보편화되면서, 우리는 Terraform이나 Ansible 등을 적극적으로 사용합니다. 그런데 이 편리함 이면에는 치명적인 리스크가 숨어 있습니다. 인프라 구성 파일 속에 AWS Secret Key나 DB 패스워드가 평문으로 박제되어 있는 경우를 코드 리뷰 과정에서 종종 발견하곤 합니다.

특히 요즘처럼 Cursor나 Claude 같은 AI 도구를 활용해 코딩하는 속도가 빨라지면, 개발자는 무의식적으로 인증 키를 코드에 직접 붙여넣고 테스트를 진행하고픈 유혹에 빠집니다. "나중에 환경변수로 빼야지"라고 생각하지만, 급한 배포 일정에 쫓기다 보면 그 코드가 그대로 메인 브랜치에 머지되는 사고가 발생합니다.

ESA의 Bitbucket 덤프가 통째로 넘어갔다는 것은, 그 안에 포함된 수많은 커밋 히스토리 어딘가에 이러한 '비밀'들이 숨겨져 있었다는 뜻입니다. 한번 유출된 자격증명은 해커들에게 내부망으로 들어가는 프리패스 티켓이 됩니다.

보안은 '이벤트'가 아니라 '문화'여야 합니다

ESA는 2011년, 2024년, 그리고 2025년까지 반복적으로 비슷한 패턴의 공격을 받고 있습니다. 이는 특정 보안 담당자의 무능이라기보다, 조직 전체의 엔지니어링 문화 문제일 가능성이 큽니다.

기술 리더로서 저는 팀원들에게 항상 이렇게 강조합니다. "보안은 보안팀의 업무가 아니라, 코드 퀄리티의 일부다."

우리가 할 수 있는 구체적인 액션들은 생각보다 멀리 있지 않습니다.

1. 시크릿 관리의 자동화: 1Password나 AWS Secrets Manager 같은 도구를 활용해, 코드 레벨에서 평문 키가 아예 보이지 않게 해야 합니다. 로컬 개발 환경에서도 .env 파일 공유를 엄격히 금지하고, 1Password CLI 등을 통해 주입받는 방식을 권장합니다.

2. 좀비 리소스 정리: 클라우드 비용 절감 목적뿐만 아니라 보안을 위해서라도, 사용하지 않는 개발 서버와 테스트용 리포지토리는 주기적으로 삭제해야 합니다.

3. CI/CD 파이프라인 점검: GitHub Actions나 Jenkins 설정 파일에 혹시라도 민감 정보가 노출되어 있지 않은지, 배포 스크립트가 너무 많은 권한을 가지고 있지 않은지 정기적으로 들여다봐야 합니다.

저 역시 오늘 밤에는 우리 팀의 레거시 리포지토리들을 한번 훑어볼 생각입니다. 혹시 3년 전의 제가 귀찮다는 이유로 API 키를 주석 처리해 놓은 코드가 남아있지는 않은지 말입니다.

완벽한 보안은 없습니다. 하지만 적어도 '현관문 열쇠를 문 앞에 두고 다니는' 실수는 하지 말아야 합니다. 주니어 개발자 여러분도 지금 작성 중인 PR을 다시 한번 살펴보세요. 혹시 여러분의 코드가 해커들에게 보내는 초대장이 되고 있지는 않은지 확인해 보는 습관, 그게 바로 엔지니어로서의 성장을 만드는 첫걸음입니다.