Q20. 서명키 하드코딩은 문제의 본질일까요?

By PLURA

A. 그렇지 않습니다. 하드 코딩은 ‘문제의 형태’일 수는 있지만, 문제의 본질은 아닙니다.

이번 쿠팡 인증키 노출 사례 이후, 많은 해석이 하나의 문장으로 요약되었습니다.

“서명키를 하드 코딩해서 사고가 났다.”

그러나 이 문장은 사건을 설명하기에는 너무 단순하고, 다음 사고를 막기에는 아무런 도움도 되지 않습니다.

1️⃣ 하드 코딩은 ‘금기’가 아니라 ‘현실’입니다

현실의 시스템을 조금이라도 운영해 본 조직이라면 알고 있습니다.

  • 내부 서비스 간 인증
  • 배치·크론 작업
  • 레거시 연동
  • 일부 SaaS·외부 API

이 영역에서 키·토큰·시크릿이 코드 또는 설정에 포함된 사례는 흔합니다.

즉,

하드 코딩 자체가 곧 사고를 의미하지는 않습니다.

문제는 그 키가 유출되었을 때의 시나리오를 설계 단계에서부터 전혀 고려하지 않았다는 점입니다.

2️⃣ 진짜 질문은 “왜 키를 바꾸기 어려웠는가”입니다

하드 코딩이 보안 사고로 이어지려면, 보통 다음 조건이 동시에 충족됩니다.

  • 키가 코드 곳곳에 흩어져 있음
  • 중앙 관리·분리 구조가 없음
  • 교체 시 전체 빌드·배포가 필요함
  • 실제 운영에서 한 번도 교체해 본 적이 없음

이 상태에서 키는 더 이상 “보안 자산”이 아니라,

시스템을 멈추게 할 수 있는 구조적 취약점

이 됩니다.

3️⃣ 그래서 중앙 관리 서버면 해결됐을까요?

정부 발표를 따라가다 보면 자연스럽게 이런 질문이 등장합니다.

“하드 코딩 대신 중앙 서명 키 관리 서버(KMS 등)를 사용했다면 이 문제는 발생하지 않았을까요?”

결론부터 말하면, 아닙니다.

중앙 관리 서명 키 관리 시스템을 사용하더라도,

  • 키 교체가 어렵고
  • 교체 시 서비스 영향이 크며
  • 실제 운영 환경에서
  • 최근 6개월, 1년 내 한 번도 교체해 본 적이 없다면

결과는 동일합니다.

4️⃣ 구조가 있어도, 운영하지 않으면 의미가 없습니다

중앙 관리 시스템은 ‘가능성’을 제공할 뿐, ‘안전’을 보장하지는 않습니다.

  • 키가 중앙 서버에 있어도
  • 교체 절차가 복잡하고
  • 운영자가 교체를 두려워하며
  • 실제로 교체를 연습해 본 적이 없다면

그 시스템은 결국,

“중앙에 위치한 또 다른 하드 코딩”

과 다르지 않습니다.

즉,

  • ❌ 코드에 하드 코딩된 키
  • ❌ 중앙 서버에 있지만 교체하지 않는 키

는 보안 사고 관점에서 본질적으로 동일한 리스크를 가집니다.

5️⃣ 본질은 ‘어디에 있느냐’가 아니라 ‘바꿀 수 있느냐’입니다

이 문제의 핵심은 단순합니다.

  • 키가 코드에 있느냐 ❌
  • 키가 중앙 서버에 있느냐 ❌

가 아니라,

“유출을 전제로 했을 때, 실제 운영 환경에서 즉시·반복적으로 교체할 수 있는가?”

입니다.

중앙 서명 키 관리 시스템조차
정기적인 키 로테이션을 실제로 수행하지 않는다면,
보안 사고는 시간 문제일 뿐입니다.

정리하면

문제는 하드 코딩이 아니라,
중앙 관리 여부조차 아닌,
교체를 상상하지 않은 설계와
교체를 연습하지 않은 운영입니다.

쿠팡과 같이
거대 기업이자 상장 회사로서,
수많은 사용자와 주주에게 직접적인 책임을 지는 기업에서조차
이러한 문제가 발생했다는 점은 쉽게 넘길 수 없는 대목입니다.

이는 특정 담당자의 실수나
일시적인 개발 관행의 문제가 아니라,
조직 전체의 설계·운영 문화가 만들어낸 결과로 보는 것이 더 타당합니다.

이번 사례는
특정 기업의 실수라기보다,

아직도 많은 조직이 안고 있는
구조적·운영상 보안 리스크를 드러낸 사건

으로 보는 것이 더 정확합니다.

🛡️ 대응에 대한 추가 질문은 Q21에서 논의하겠습니다.

📚 참고 읽기

Tags