'만료 없는 토큰'이 불러온 1조 원의 청구서
최근 쿠팡의 대규모 개인정보 유출 사태는 IT 업계에 큰 충격을 주었습니다. 3천만 건이 넘는 정보 유출 규모도 놀랍지만, 그 원인이 외부의 고도화된 해킹이 아니라 내부 개발 편의를 위해 만들어진 '유효 기간이 긴 액세스 토큰'이었다는 점은 우리에게 시사하는 바가 큽니다. 우리는 흔히 개발 속도와 편의성을 위해 보안 절차를 잠시 미루거나 간소화하곤 합니다.
하지만 이번 사건은 그 작은 '타협'이 1조 원에 달하는 과징금과 기업의 신뢰 추락이라는 거대한 청구서로 돌아올 수 있음을 보여주었습니다.
편리함이라는 이름의 함정: '좀비 토큰'의 탄생
개발 과정에서 가장 귀찮은 일 중 하나는 빈번한 로그인과 인증 만료입니다. 개발자들은 테스트 효율을 높이기 위해, 혹은 매번 인증을 갱신하는 로직을 구현하기 번거롭다는 이유로 유효 기간이 매우 길거나 아예 만료되지 않는 액세스 토큰을 발급하곤 합니다. 당시에는 이것이 개발 속도를 높여주는 효율적인 선택처럼 보였을 것입니다. 하지만 퇴사한 직원의 손에 들려 나간 이 '만료 없는 토큰'은, 자물쇠가 바뀌지 않는 회사의 마스터키와 같았습니다.
5개월 동안이나 아무도 모르게 데이터를 빼낼 수 있었던 이유는, 시스템이 이 토큰을 '정상적인 관리자의 접근'으로 인식했기 때문입니다. PM은 개발팀이 "테스트 편의를 위해 보안 설정을 잠시 풀게요"라고 말할 때, 그것이 언제 다시 원상 복구되는지, 그리고 그 '편의'가 초래할 최악의 시나리오가 무엇인지 질문해야 합니다.
기술 부채가 '보안 부채'로 악화되는 순간
우리는 흔히 빠른 출시를 위해 완벽하지 않은 코드를 작성하는 것을 '기술 부채(Technical Debt)'라고 부릅니다. 나중에 갚으면 된다고 생각하지만, 보안 영역에서의 부채는 성격이 다릅니다. 이는 이자가 눈덩이처럼 불어나는 악성 사채와 같은 '보안 부채(Security Debt)'입니다. 쿠팡 사례에서 보듯, 액세스 토큰의 유효 기간을 짧게 설정하고 주기적으로 갱신하는 '리프레시 토큰(Refresh Token)' 구조를 만드는 것은 초기 개발 공수가 더 들고 번거로운 작업입니다. 하지만 이 작업을 생략한 대가는 혹독했습니다.
PM은 "기능 구현이 먼저다"라는 압박 속에서도, 보안 아키텍처를 생략하는 것이 단순히 일정을 당기는 것이 아니라, 미래의 리스크를 현재로 당겨쓰는 위험한 도박임을 인지해야 합니다. 보안은 기능 개발의 발목을 잡는 '블로커(Blocker)'가 아니라, 서비스가 무너지지 않게 지탱하는 '기반(Foundation)'입니다.
PM의 역할: 속도와 안전의 균형을 맞추는 '브레이크'
결국 이 문제를 해결하기 위해 PM은 개발팀의 '액셀러레이터'인 동시에 안전한 주행을 위한 '브레이크'가 되어야 합니다. 개발팀이 비즈니스 로직 구현에 집중하느라 보안을 놓치고 있다면, PM이 먼저 나서서 "퇴사 시 권한 회수 프로세스는 자동화되어 있나요?", "이 접근 권한의 유효 기간은 정책적으로 적절한가요?"라고 질문을 던져야 합니다.
또한, 기획서(PRD) 단계에서부터 기능 요구사항뿐만 아니라 '보안 요구사항'을 명시해야 합니다. 예를 들어, '관리자 페이지 접속 시 2단계 인증 필수', '민감 데이터 조회 시 로그 기록 및 알림 발송' 등을 기능의 일부로 정의하는 것입니다. 개발의 편의성이 고객의 안전보다 우선될 수는 없습니다. PM이 중심을 잡고 불편하지만 안전한 길을 선택할 때, 비로소 우리는 1조 원의 리스크로부터 서비스를 지킬 수 있습니다.
