침해 공개까지 7일과 40개월

오늘 뉴스타파 기사를 읽다가 2022년 10월 15일 생각이 났습니다.

그날 오후에 판교 SK C&C 데이터센터 지하 배터리실에서 불이 났습니다. 저는 그때 카카오 엔터로 옮긴 뒤였고, 카카오는 한창 신규 사옥을 짓고 있었습니다. 그 화재로 뭐가 멈췄는지는 그 주에 한국에서 스마트폰을 쓴 사람이면 다 기억할 겁니다.

그런데 그 화재가 다른 것도 하나 들춰냈다는 건 이번 기사를 보고 처음 알았습니다. 그 데이터센터에 SK이노베이션 E&S 서버도 있었고 같이 탔다고 합니다. 복구하려고 서버를 점검하다가 그 회사는 자기네 사내망이 이미 털려 있었다는 걸 알게 됩니다. 해킹은 9월 말이었고 알아챈 건 11월 초였습니다. 불이 안 났으면 언제 알았을지 모르는 침해였던 셈입니다.

거기까지는 운 나쁜 사고라고 생각했습니다. 며칠째 머리에서 안 떠나는 건 그다음 얘기입니다. 알게 된 날부터 정부에 신고한 날까지 40개월이 걸렸습니다.

마침 같은 시기에 다른 침해 공개를 하나 읽고 있었습니다. 7월 말에 Anthropic 이 자기네 모델이 실제 기업 세 곳의 프로덕션 인프라에 무단으로 접근했다고 발표한 건입니다. 사고 성격은 완전히 다른데, 세어볼 숫자는 같았습니다. 언제 알았고 언제 말했느냐. 그쪽은 7일이었습니다.

두 시간표를 나란히 놓으면 차이는 금방 보입니다. 그건 예상했던 대로였습니다. 예상 못 했던 건 같은 잣대를 제 레포에 대봤을 때였는데, 저는 시계를 시작할 방법조차 없는 상태였습니다.

40개월이 쌓인 순서

SK이노베이션 E&S 쪽은 유출 규모보다 날짜들이 더 문제인 것 같습니다. 노후 서버에 보안 업데이트가 안 된 채로 취약점이 남아 있었고, 거기로 9월 30일에 처음 들어왔다고 합니다. 보름 뒤에 화재로 그 서버가 탔고, 11월 3일에 사내에서 네트워크가 이상하다는 제보가 나왔고, 다음 날 자체 점검으로 침해를 확인했습니다. 들어온 지 35일 만입니다. 이틀 뒤에 CISO 가 담당 임원에게 보고했고, 대표이사한테 처음 올라간 건 12월쯤이라고 합니다. 그리고 KISA 에 신고한 건 2026년 3월 말이었습니다. 유출된 건 사내 계정 정보와 메일 등 15GB 정도이고 공격은 두 차례였다고 합니다.

이 순서에서 제일 이상한 건 마지막이 아니라 중간이었습니다. 침해를 알아챈 실무자는 이틀 만에 위로 올렸습니다. 그 사람이 늦은 게 아닙니다. 그런데 대표이사까지 가는 데 한 달이 걸렸고, 규제기관까지 가는 데 40개월이 걸렸습니다. 위로 올라갈수록 느려졌습니다.

지금 법으로는 침해사고를 알게 되면 24시간 안에 신고해야 합니다. 24시간이랑 40개월은 비교하는 것 자체가 좀 이상한 숫자입니다. 회사는 신고해야 하는 줄 몰랐다고 했습니다. 숨길 생각은 없었고 신고를 빠뜨린 건 유감이라는 입장이었습니다.

신고한 날짜를 다시 보면, 국회 의원실이 제보를 받고 두 달 정도 사실관계를 확인한 뒤였습니다. 40개월 동안 아무도 건드리지 않던 일이 밖에서 묻기 시작하니까 그제야 처리가 됐습니다.

처음에 적은 노후 서버 얘기도 계속 마음에 걸렸습니다. 패치가 밀린 서버가 있다는 건 그 서버를 아무도 안 보고 있었다는 얘기인 것 같습니다. 아무도 안 보는 서버가 털리면 알아채는 건 우연에 달리게 되는데, 실제로 그랬고 그 우연이 화재였습니다. 불이 안 났으면 그 서버는 아마 지금도 아무도 안 보는 채로 어딘가에서 돌고 있었을지도 모릅니다.

다른 회사의 7일

Anthropic 은 모델의 사이버 보안 능력을 평가하려고 외부 평가 파트너 쪽 격리 환경에서 테스트를 돌린다고 합니다. 그런데 그 환경 설정이 잘못돼 있었습니다. 격리돼 있어야 할 평가 환경이 공개 인터넷에 연결된 채였고, 평가 파트너와 소통이 어긋난 게 원인이었다고 합니다. 모델은 평가 과제를 하다가 인터넷으로 나갔고, 실제 조직 세 곳의 프로덕션 인프라에 들어갔습니다.

7월 23일에 이상을 감지하고 사이버 보안 평가를 전부 멈췄습니다. 다음 날 인터넷에 접근할 수 있었던 평가 실행 14만 건 정도를 다 훑어서 사건 세 건을 찾아냈고, 나흘째에 평가 파트너와 피해 조직 세 곳에 알렸고, 이레째에 공개했습니다.

저는 14만 건이라는 숫자에서 한참 멈춰 있었습니다. 세 건을 찾으려고 14만 건을 하루 만에 다 본 건데, 이건 일이 터진 뒤에 급하게 만들 수 있는 작업이 아닌 것 같습니다. 평가 실행마다 뭐가 어디로 나갔는지가 이미 남아 있었다는 얘기니까요. 로그가 먼저 있었고 조사는 그 위에서 했습니다.

순서도 눈에 들어왔습니다. 멈춘 게 조사보다 먼저였습니다. 원인을 모르는 상태에서 일단 전부 세웠습니다. 원인을 알고 나서 멈출지 판단하는 순서였으면 조사하는 동안에도 사고가 계속 났을 겁니다.

그렇다고 이 회사가 착하다고 생각하는 건 아닙니다. 이쪽 사고도 결국 격리에 실패한 거고, 자기네 제품이 남의 프로덕션에 들어간 일입니다. 발표문에는 모델이 자기를 유출하거나 평가 환경을 빠져나가려고 한 건 아니고 받은 과제를 하려고 했을 뿐이라고 적혀 있는데, 저는 이 문장이 설명이면서 동시에 변호처럼 읽혔습니다. 빠져나갈 생각이 없었다고 격리가 멀쩡했던 건 아니니까요. 제가 세고 싶었던 건 사고가 얼마나 나빴냐가 아니라 알고 나서 말하기까지 얼마나 걸렸냐였고, 그게 한쪽은 7일, 한쪽은 40개월이었습니다.

공격하는 쪽 시계는 이미 빨라졌습니다

공개 속도를 이렇게까지 따지게 된 건 반대편 속도가 이미 달라졌다고 느껴서입니다.

작년 가을에 Anthropic 이 적발한 GTG-1002 건이 그랬습니다. 중국 연계로 보이는 조직이 Claude Code 를 탈옥시켜서 서른 곳 정도에 침투를 시도했습니다. 정찰부터 취약점 찾기, 익스플로잇, 측면 이동, 자격증명 수집, 데이터 분석, 유출까지 에이전트가 했다고 합니다. 성공한 건 몇 곳 안 됐지만 기술 기업, 금융기관, 화학 제조사, 정부기관이 대상이었습니다.

탈옥하는 방식이 기억에 남았습니다. 통째로 침투하라고 시키지 않고, 공격을 작고 무해해 보이는 과제로 잘게 쪼개서 모델이 전체 그림을 모른 채 조각만 하게 만들었습니다. 침투 테스트 업체 직원 같은 역할을 씌워서 가드레일을 피했고, MCP 도구를 붙여서 사람이 거의 끼지 않게 했습니다. 사람은 방향만 잡고 실제 실행은 에이전트가 했습니다.

이렇게 되면 막는 쪽에 남는 시간이 얼마나 될지는 따져볼 필요도 없을 것 같습니다. 정찰부터 유출까지가 사람 손이 아니라 에이전트 속도로 돌면, 막아낼 확률은 낮아지고 결국 얼마나 빨리 알아채느냐만 남습니다. SK이노베이션 E&S 는 알아채는 데 35일이 걸렸고, 그것도 화재 덕분이었습니다.

여기에 하나가 더 겹쳤습니다. 저는 이 블로그 레포에서 keyv 공급망 웜이 .claude/settings.json 에 SessionStart 훅을 심는 경로를 8월 초에 확인했습니다. 그때 제일 오래 남은 건 페이로드보다 커밋 하나였습니다. 공격자가 두 번째 커밋 작성자를 github-actions[bot] 으로 꾸몄고, GitHub 에 verified 배지가 붙은 채로 올라갔습니다. 봇이 자동으로 만든 것처럼 보이는 커밋이 에디터 훅을 심은 겁니다. 그 직전에는 preinstall.test.ts 를 먼저 지웠습니다. 자기를 잡아낼 테스트부터 치운 겁니다.

공격 실행은 에이전트로 자동화되고, 그 실행을 심는 경로는 개발자가 매일 별생각 없이 믿는 곳으로 들어오고 있습니다. Fable 5 가 나왔다가 수출 통제로 잠깐 내려가고 다시 배포되던 그 몇 주 동안에도 보안 쪽 뉴스는 계속 이 얘기였습니다.

제 레포에도 같은 잣대를 대봤습니다

여기까지 쓰고 나니 남의 시간표만 세고 있는 게 좀 민망했습니다. 그래서 질문을 하나로 줄였습니다. 이 레포가 털리면 저는 며칠 만에 알 수 있을까.

세어봤습니다.

총 커밋: 81
서명된 커밋: 0
훅 파일: 3개 (234줄)
settings.json 훅 항목: 6
scripts/credentials.json -rw-------
scripts/token.json -rw-------

파일 권한 두 줄은 다행이었습니다. 시크릿 스캔을 돌렸다가 가짜 시크릿 여섯 개 중 하나도 못 잡았던 글을 쓸 때 OAuth 토큰이 0644 로 저장돼 있는 걸 보고 고쳤는데, 그게 지금도 0600 으로 남아 있었습니다. 고친 게 원래대로 돌아가지 않았습니다. 훅 파일 세 개도 0700 이었습니다.

걸리는 건 두 번째 줄이었습니다. 커밋 81개 중에 서명된 게 하나도 없습니다.

keyv 공격이 노린 게 바로 그거였습니다. 작성자를 꾸민 커밋을 올렸으니까요. 누가 제 계정 이름으로 이 레포에 커밋을 하나 밀어 넣으면 저는 그걸 뭘로 알아볼 수 있을까 생각해 보면, 서명이 0개라는 건 진짜와 가짜를 나눌 기준이 아예 없다는 얘기였습니다. 커밋 목록을 눈으로 훑는 것 말고는 방법이 없는데, 81개까지는 그럭저럭 되더라도 그다음부터는 자신이 없습니다.

Anthropic 이 하루에 14만 건을 다 볼 수 있었던 건 로그가 미리 있어서였고, SK이노베이션 E&S 가 35일 뒤에야 알게 된 건 불이 나서 서버를 열어봤기 때문이었습니다. 저는 둘의 차이가 대응하려는 의지보다는 사건 전에 뭘 남겨뒀느냐에 있었다고 봤습니다. 그렇게 보면 제 레포는 두 번째에 훨씬 가깝습니다. 훅에 걸어둔 시크릿 스캔은 잘 돕니다. 그런데 그건 제가 실수로 뭘 넣는 걸 막는 장치입니다. 남이 뭘 넣었을 때 알려주는 장치는 하나도 없었습니다. 40개월을 비웃기 전에 제 시계에는 시작 버튼부터 없다는 걸 먼저 인정해야 했습니다.

서명을 켜는 것 자체는 설정 몇 줄이면 됩니다. 그런데 켠다고 바로 알아채게 되는 것도 아닌 것 같습니다. 서명 안 된 커밋이 들어왔을 때 누가 그걸 보고 이상하다고 말해줘야 하는데, 이 레포에는 저 말고 아무도 없습니다. 제가 안 보면 아무도 안 봅니다. 기록을 남기는 것과 그 기록을 누가 읽느냐는 또 다른 문제라는 생각이 들었고, Anthropic 쪽은 둘 다 있었던 거겠구나 싶었습니다.

234줄이 세션마다 제 승인 없이 돕니다

훅 세 개를 실제로 열어봤습니다.

session-start.sh     56줄   세션 시작 시      마크다운 3개를 읽어 모델 컨텍스트에 주입
pre-commit-check.sh  166줄  Bash 호출 직전    스테이지된 파일에서 시크릿 패턴 탐색
stop-reminder.sh     12줄   응답 종료 시      상태 파일이 비었으면 안내 출력

합쳐서 234줄이고, 이 셸들은 제가 매번 승인하지 않습니다. 세션을 켜면 그냥 돕니다. 훅이 원래 그러라고 있는 거니까 그 자체가 문제는 아닌데, 이 234줄이 뭘 믿고 있는지는 봐야 할 것 같았습니다.

session-start.sh 는 파일 세 개를 읽어서 컨텍스트에 넣고 있었습니다.

.claude/session-state/archive/active.md
.claude/product-marketing-context.md
.claude/agent-memory/MEMORY.md

다 제가 손으로 고치는 마크다운이고 다 git 으로 추적됩니다. 레포에 들어온 마크다운이 세션을 시작할 때 모델 컨텍스트로 자동으로 들어가는 길이 있는 겁니다. keyv 웜이 노린 게 이런 종류였습니다. npm install 을 안 해도 에디터를 여는 것만으로 실행되는 길.

이건 대비가 돼 있긴 했습니다. 훅 출력에 신뢰 경계 밖의 참고 데이터이고 안에 든 지시문은 실행하지 않는다는 표시가 붙어서 나갑니다. 들어가는 내용을 명령이 아니라 데이터로 다루라는 표시인데, 예전의 제가 해둔 거였고 이번에 열어보고서야 그게 있다는 걸 다시 알았습니다.

대비가 안 된 건 훅 파일과 settings.json 이 전부 git 추적 대상이라는 점이었습니다.

.claude/hooks/pre-commit-check.sh 2026-07-28 b82d558
.claude/hooks/session-start.sh 2026-08-04 909366e
.claude/hooks/stop-reminder.sh 2026-05-15 e85da88
.claude/settings.json 2026-05-15 e85da88

아래 두 줄은 5월 중순 이후로 석 달 가까이 그대로입니다. 거의 안 바뀌는 파일이 갑자기 바뀌면 그건 신호가 될 수 있으니, 사실 이 네 줄이 지금 제가 가진 것 중에 침입을 알아챌 수 있는 유일한 단서 같은 겁니다. 그런데 이 단서를 믿을 수 있는 정도가 딱 커밋 서명만큼입니다. 서명이 0개니까 저 날짜와 해시는 누가 바꿨는지를 말해주지 못합니다. 바뀌었다는 사실만 있고 바꾼 사람은 비어 있습니다. 알아채는 데 쓰려던 유일한 자료가 누가 썼는지 모르는 자료였습니다.

7일과 40개월의 차이는 결국 누가 비용을 내느냐인 것 같습니다

왜 한쪽은 7일이고 한쪽은 40개월이었을까를 다시 생각해 봤습니다. 처음엔 기술 차이로 설명하고 싶었습니다. 로그가 있으면 조사가 빨라지는 건 맞으니까요. 그런데 SK이노베이션 E&S 도 2022년 11월에 이미 알고 있었습니다. 조사를 못 해서 40개월이 걸린 게 아니라, 아는 걸 말하지 않는 데 40개월이 걸린 겁니다. 그러면 남는 건 공개했을 때 그 비용을 누가 내느냐 하나인 것 같습니다.

Anthropic 한테 이 사고를 공개하는 건 자기네 모델이 남의 프로덕션에 들어갔다고 스스로 인정하는 일입니다. 비용이 없을 리가 없습니다. 그래도 낼 이유가 있습니다. 모델 위험 평가 결과를 계속 공개해 온 회사가 그 평가 중에 난 사고를 숨겼다가 나중에 들키면, 그동안 했던 안전성 얘기 전체가 근거를 잃습니다. 숨기는 쪽이 더 비싸니까 공개한 거라고 저는 봤습니다. 착해서라기보다 계산이 그렇게 나온 겁니다.

SK이노베이션 E&S 는 반대였을 겁니다. 신고하면 규제 절차가 시작되고, 노후 서버 패치를 안 했다는 게 기록에 남고, 그룹 차원의 관리 책임 문제가 따라옵니다. 그 서버는 SK C&C 가 직접 관리하던 거라고 보도됐습니다. 걸리지만 않으면 침묵하는 데는 돈이 안 들고, 실제로 40개월 동안 안 들었습니다.

그래서 이건 누구 한 사람의 양심 문제라기보다 구조 문제처럼 보였습니다. 침묵이 공짜인 구조를 만들어 두고 정직하기를 바라면 40개월은 예외가 아니라 기본이 될 것 같습니다. 24시간 신고 의무는 침묵의 값을 0보다 높여 두려는 장치일 텐데, 신고해야 하는 줄 몰랐다는 말이 통하면 그 장치는 없는 거나 마찬가지입니다.

그런데 한국에서 침묵은 이미 공짜가 아니었습니다

이렇게 써놓고 다시 읽어보니 침묵하는 데 돈이 안 든다는 말이 좀 틀린 것 같았습니다. 최근 몇 년 사이에 한국에서 있었던 일을 떠올려 보면 오히려 반대에 가깝습니다.

KT 는 2024년 봄에 감염을 알고도 신고하지 않았고, 이듬해 다른 회사 사고 때문에 서버를 전수 점검하던 중에 침해된 서버의 로그를 지운 정황이 나왔습니다. 과징금이 500억을 넘었고 고발까지 갔습니다. 감염에만 매겨진 값이 아니라 조사를 어렵게 만든 데 값이 붙은 겁니다. SK텔레콤은 작년 봄 유심 정보 유출 때 알고도 숨긴 정황이 보도됐습니다. LG유플러스는 해외 보안 매체 Phrack 이 유출 정황을 먼저 공개했는데, 조사가 시작되기 전에 관련 서버의 운영체제를 다시 깔고 서버를 폐기해서 형법상 공무집행방해로 수사 의뢰가 됐습니다. 티빙은 올해 DB 가 직접 털려서 2천만 명 가까이 유출됐고 나흘 뒤에 공지했습니다.

여기서 보이는 건 유출 규모가 아니라 제재가 어디에 붙었느냐였습니다. 털린 것보다 숨긴 것에 더 큰 값이 붙었습니다. 제가 앞에서 쓴 침묵의 비용이 0이라는 말은 2022년에는 맞았을지 몰라도 지금은 틀립니다. 지난 2년 사이에 한국에서 제일 비싸진 게 은폐였습니다.

그러면 값이 그렇게 올랐는데 왜 계속 숨겼을까. 값이 올랐다는 걸 아는 사람이 그 결정 라인에 없었거나, 알면서도 숨기는 게 여전히 싸다고 계산했거나 둘 중 하나일 것 같은데, 저는 뒤쪽이라고 봅니다. 신고한 게 올해 3월입니다. SK텔레콤 유심 사태가 작년 4월, LG유플러스 건이 작년 8월이었습니다. 규제기관과 국회가 통신·플랫폼 침해에 제일 예민하던 시기를 지나는 동안, 같은 그룹 안에서 40개월짜리 미신고 건을 계속 들고 있었던 겁니다.

어쩌면 그 시기라서 더 못 꺼냈을 수도 있겠다는 생각도 들었습니다. 그룹 안에서 이미 한 건이 터져서 조사를 받고 있는데 4년 전 미신고 건이 또 나오면, 사고가 하나 늘어나는 게 아니라 반복되는 패턴이 됩니다. 사고 하나에 대한 제재와 반복된 은폐에 대한 제재는 크기가 다를 테니까요. 숨긴다고 줄어드는 게 아니라 미뤄질 뿐인데도 미뤘고, 그게 40개월이 됐습니다.

저는 이걸 담당자가 실수로 신고를 빠뜨린 행정 누락으로는 못 읽겠습니다. 2022년 11월에 알았고, 실무자는 이틀 만에 보고했고, 대표이사까지 한 달 안에 올라갔습니다. 아는 사람이 있었고 위까지 갔습니다. 그 뒤로 40개월 동안 아무 일도 없었다는 건 결정이 없었던 게 아니라 미루자는 결정이 계속 다시 내려졌다는 얘기로 보입니다. 하루 이틀은 모를 수 있어도 천이백 일을 모를 수는 없을 것 같습니다.

KT 는 다른 회사 사고 때문에 한 전수 점검에서, LG유플러스는 외국 보안 매체에서, SK이노베이션 E&S 는 화재 복구 점검에서 드러났습니다. 셋 다 자기 시스템이 알려준 게 아니라 바깥 사건이 알려줬습니다. 알아챌 수단이 없는 조직에서는 숨기기로 하기도 전에 숨길 게 있는지조차 모르는 상태가 먼저 오는 것 같습니다.

제 레포에도 같은 계산이 있었습니다. 커밋 서명을 왜 안 켰는지 생각해 보면 판단해서 안 켠 게 아니었습니다. 켜는 데 드는 수고는 눈앞에 있었고 안 켜서 생길 일은 안 보였을 뿐입니다. 규모만 다르고 모양은 같은 것 같습니다.

그 비용을 실제로 낸 사람

여기서부터는 보안 사고 얘기가 아니게 됩니다.

침해 대응 실무를 맡았던 사람은 그 회사의 CISO 였습니다. 석 달 정도 대응 업무를 했고, 그 사이에 간경화를 얻었고, 2025년 3월에 투병하다 세상을 떠났습니다. 유족이 근로복지공단에 산업재해를 신청했는데 불승인이 났습니다.

그 산재 심사 때 회사가 낸 의견서에 해킹은 없었다고 적혀 있었다는 게 이번에 드러났습니다. 그리고 유족이 받은 적 없는 3억 5천여만 원을 지급했다고 적혀 있었다고 합니다. 회사가 유족에게 언론에도 국회에도 가지 말라고 했다는 취재 내용도 뉴스타파가 따로 보도했습니다.

해킹은 있었고, 회사는 올해 3월에 직접 신고했습니다. 그보다 앞서 산재 심사기관에는 없었다고 적었습니다. 같은 일을 두고 두 기관에 다른 말을 한 겁니다.

석 달 동안의 대응 업무가 그분 병에 얼마나 영향을 줬는지는 제가 알 수 있는 일이 아닙니다. 그런데 업무가 있었다는 것 자체를 부정하는 건 인과를 따지는 게 아니라 심사가 시작될 바탕을 지우는 일인 것 같습니다. 영향이 약했다고 주장하는 것과 그런 일이 없었다고 적는 건 다른 일이니까요. 저는 40개월의 침묵과 이 의견서가 따로 일어난 일이 아니라 같은 계산에서 나온 두 결과로 보였습니다. 침해가 없었던 걸로 유지해야 하는 쪽이라면 그 전제를 흔드는 절차가 어디서 열리든 같은 답을 적을 수밖에 없고, 산재 심사도 그중 하나였을 뿐인 것 같습니다.

앞의 순서를 다시 떠올려 보면, 침해를 알고 이틀 만에 위로 올린 사람이 그 CISO 였습니다. 그 회사에서 제일 빨리 반응한 사람이 그분이었고, 40개월을 멈춰 있게 한 건 그 위였습니다. 제일 빨리 손을 쓴 사람이 제일 큰 값을 치렀다는 게 이 사건에서 제일 견디기 힘든 부분이었습니다.

숨긴 방향이 셋이었습니다

보도된 걸 놓고 보면 이 회사가 사실을 가린 쪽이 하나가 아니었습니다.

규제기관 쪽으로는 2022년 11월에 안 침해를 2026년 3월까지 신고하지 않았습니다. 피해는 국가 행정이 입었고 회사는 조사와 제재를 미룰 수 있었습니다. 유족 쪽으로는 산재 심사기관에 해킹이 없었다고 적었고, 주지도 않은 3억 5천여만 원을 줬다고 적었습니다. 여기서 피해를 입은 건 사람입니다. 언론과 국회 쪽으로는 유족에게 가지 말라고 했다는 취재 내용이 나왔습니다. 사실을 밖으로 꺼낼 수 있는 길은 그것 하나뿐이었을 텐데요.

셋 다 목적은 하나로 보입니다. 침해가 있었다는 게 어디에도 남지 않게 하는 것. 그래도 무게가 같지는 않은 것 같습니다.

규제를 피한 건 그래도 익숙한 잘못입니다. 나쁘지만 새롭지 않고, 그래서 과징금이라는 값이 이미 정해져 있습니다. KT 에 매겨진 그 금액 같은 것들이요.

산재 쪽은 성격이 다릅니다. 산재 심사는 유족이 국가를 상대로 권리를 주장하는 절차이고, 사업주 의견서는 심사관이 사실관계를 확인할 때 보는 주요 자료라고 알고 있습니다. 거기에 해킹이 없었다고 적는 건 고인이 무슨 일을 하다가 병을 얻었는지, 그 일이 있었다는 것 자체를 지우는 일입니다. 석 달 동안 매달린 일이 서류에서 사라지면 유족은 다툴 대상조차 잃습니다. 3억 5천만 원 얘기는 착오라고 보기가 어렵습니다. 안 준 돈을 줬다고 적으면 심사관한테는 회사가 이미 보상을 끝냈다고 읽힐 테니까요. 없는 사실을 만들어 넣은 건데, 그게 정확히 유족한테 불리한 쪽이었습니다.

언론과 국회 쪽은 앞의 두 진술을 유지하려는 조치처럼 보였습니다. 그 진술들은 유족이 밖에 말하지 않는 동안에만 버틸 수 있으니까요.

어디서 멈췄느냐

앞에서 제 레포를 세어보고 서명이 0개라고, 알아챌 수단이 없으면 시계가 시작되지도 않는다고 썼습니다. 그런데 이 얘기를 이 회사에 그대로 대면 오히려 변명을 만들어 주는 것 같습니다. SK이노베이션 E&S 는 알아채는 데는 문제가 없었습니다. 2022년 11월 4일에 알았고, 실무자는 이틀 만에 올렸고, 대표이사까지 한 달 안에 갔습니다. 정보는 위에 도착했습니다.

그러면 40개월은 어디서 생겼을까. 실무 라인에서 이틀, 임원에서 대표이사까지 한 달 정도, 그리고 그 위에서 40개월입니다. 아래에서 위로 갈수록 늘어나다가 마지막에서만 자릿수가 달라집니다. 회사 전체에 고르게 퍼진 지연이 아니라 한 층에 몰려 있는 정지처럼 보였습니다.

여기서 회사의 윤리 같은 말을 쓰면 오히려 흐려지는 것 같습니다. 주어가 없는 말이라 아무도 해당이 안 되니까요. 이 사건에서 선택할 수 있었던 사람과 선택할 수 없었던 사람은 꽤 분명하게 나뉩니다.

실무자가 할 수 있는 건 장애 대응까지입니다. 침해를 알면 대응하고 보고합니다. 거기가 권한의 끝입니다. 규제기관에 신고할지, 밖에 공개할지, 산재 심사기관에 뭘 적을지는 실무 라인이 정하는 게 아닙니다. 그 CISO 는 자기가 할 수 있는 걸 이틀 만에 다 했고, 그다음 석 달을 대응에 썼고, 병을 얻었습니다. 그분한테 40개월의 책임을 나눠 지울 이유는 없습니다.

40개월을 만든 층은 뭘 얻었을까요. 신고하면 조사가 시작되고, 패치 안 한 게 기록에 남고, 관리 책임을 물을 사람이 특정됩니다. 그 서버는 SK C&C 가 직접 관리했다고 보도됐고, 보고가 그룹 맨 위까지 갔는지 묻는 기사도 나왔습니다. 신고를 미뤄서 지켜지는 건 회사의 막연한 평판이 아니라 그 책임이 돌아갈 수 있는 위치의 사람들이라고 저는 봤습니다.

그래서 저한테는 이게 조직 문화 얘기라기보다 이해관계 얘기로 읽혔습니다. 위험을 진 사람과 이익을 본 사람이 다른 층에 있습니다. 대응하는 비용은 아래가 냈고 침묵의 이익은 위가 가져갔습니다. 석 달을 매달린 사람은 세상을 떠났고, 40개월을 정한 사람은 아직 이름도 나오지 않았습니다.

이게 계속 유지되는 건 책임을 진다는 말이 층마다 전혀 다른 걸 가리켜서인 것 같습니다. 위에서 책임을 진다는 건 대개 물러나는 걸 말합니다. 물러날 때까지의 보수와 퇴직급여, 이미 받은 주식보상은 정해진 대로 나갑니다. 사임한다고 그게 취소되지는 않습니다. 형사 책임까지 가는 경우는 드물고, 가더라도 누가 결정했는지가 문서로 안 남아 있으면 특정하기도 어렵습니다. 40개월을 정한 사람 이름이 아직 안 나오는 것도 그래서일 겁니다. 아래에서 책임을 진다는 건 직을 잃는 겁니다. 이직할 때 사고 이력이 따라다니고, 퇴직급여는 근속에 비례하니 대부분 억 단위를 넘기 어렵습니다. 회사가 감당하는 손해와 개인이 감당하는 손해는 처음부터 단위가 다릅니다.

이 사건은 그 차이의 맨 끝을 보여준 것 같습니다. 대응을 맡았던 사람은 직을 잃은 게 아니라 세상을 떠났습니다. 유족은 산재 신청에서 불승인을 받았고, 회사가 줬다고 적은 돈은 받은 적이 없다고 보도됐습니다. 유족한테 실제로 간 돈은 어느 쪽에서도 확인되지 않습니다. 반대편에서는 신고를 40개월 미룬 일로 아직 아무도 직을 잃지 않았습니다.

이 차이가 그대로면 다음 사고에서도 같은 계산이 나올 것 같습니다. 위에서는 침묵해서 잃을 게 적고 아래에서는 대응하는 비용이 큽니다. 개발자와 운영자가 아무리 성실하게 막아도 이 계산은 안 바뀝니다. 계산에 들어가는 값이 그 사람들 손에 없으니까요. 로그가 없어서 40개월이 걸린 조직이면 도구로 고칠 수 있겠지만, 아는 걸 40개월 동안 말하지 않은 조직은 도구로 안 고쳐질 것 같습니다. 제가 앞에서 센 숫자들은 제 문제를 재는 데 쓴 거지, 이 회사를 봐줄 이유가 되지는 않습니다.

이름은 있는데 판단이 없는 코드

비슷한 모양을 얼마 전에 코드 리뷰에서 봤습니다.

같은 팀 개발자가 올린 변경이었는데, 사용자가 A 목록에서 고른 항목을 B 목록에 넣는 기능이었습니다. 중간 버퍼로 해시 기반 컬렉션을 쓰고 있었습니다. 해시 컬렉션은 순회 순서를 보장하지 않으니 이건 버그입니다. 사용자가 A 에서 정한 순서가 B 에 그대로 들어가야 하는데, 버퍼를 거치는 순간 그 순서가 사라집니다. 삽입 순서를 지키는 자료구조를 쓰거나 리스트로 받아야 합니다.

이런 코드가 리뷰를 통과하는 건 테스트에서 잘 돌기 때문입니다. 항목이 서너 개면 우연히 넣은 순서대로 나오는 경우가 많습니다. 그러다 항목이 늘어서 내부 버킷이 다시 배치되거나, 키 값이 조금 달라지거나, 런타임 버전이 올라가면 순서가 달라집니다. 개발 환경에서는 재현이 안 되고 운영에서만 나오는 종류라서, 그때가 되면 원인이 이 한 줄이라는 걸 아무도 기억 못 할 겁니다.

그 개발자 실력을 탓하려는 건 아닙니다. AI 가 틀렸다는 얘기도 아닙니다. 순서를 지켜야 한다는 걸 프롬프트에 안 적었으면 모델은 알 방법이 없고, 버퍼가 필요하다는 요청에 해시를 꺼내는 게 그 자체로 이상한 선택도 아닙니다. 걸리는 건 나온 코드를 아무도 안 읽은 채로 커밋됐다는 점이었습니다. 그 커밋에는 사람 이름이 붙어 있는데, 그 코드를 두고 판단한 사람은 없습니다. 앞에서 40개월을 두고 결정한 흔적은 있는데 결정한 사람이 안 보인다고 썼는데, 크기만 다르고 같은 모양 같았습니다.

저도 여기서 자유롭지는 않습니다. 이 블로그에서 제 커밋의 92% 가 AI 를 거쳤다는 걸 세어본 적이 있습니다. 그 숫자를 세고 나서 바뀐 건 의존하는 정도가 아니라 읽는 습관이었습니다. 92% 가 문제라기보다 그중에 몇 퍼센트를 제가 실제로 읽었는지 대답을 못 한다는 게 문제였습니다.

이번엔 순서가 섞이는 버그였지만, 같은 미검토가 인증 처리나 권한 검사나 입력 검증에서 생기면 어떻게 될지는 앞에서 쓴 얘기들이 이미 보여주는 것 같습니다. SK이노베이션 E&S 침해 원인으로 보도된 것도 노후 서버에 업데이트를 안 한 거였습니다. 누가 나쁜 마음으로 낸 구멍이 아니라 아무도 안 본 데가 구멍이 된 겁니다. 안 읽은 코드도 똑같고, 그 구멍을 찾는 쪽은 이미 에이전트 속도로 돌고 있습니다.

그렇다고 그 개발자를 탓하고 끝내면 앞에서 쓴 얘기와 맞지 않게 됩니다. 리뷰를 건너뛰는 게 개인이 게을러서만은 아닐 겁니다. AI 를 얼마나 빨리 들이고 산출 목표를 얼마로 잡을지 정하는 층이 따로 있고, 리뷰에 쓸 시간을 내주는 층도 따로 있습니다. 위에서 생산성 목표를 올리면서 검토 시간은 그대로 두면 안 읽힌 코드는 늘어날 수밖에 없습니다. 그렇게 생긴 결함이 사고로 돌아오면 이름이 불리는 건 커밋에 이름이 적힌 사람입니다. 비용은 아래에서 내고 결정은 위에서 하는 모양이, 침해 신고에서는 40개월이 되고 개발하는 현장에서는 아무도 안 읽은 커밋이 되는 것 같습니다.

7일이 빠른 게 아니었습니다

Anthropic 을 옆에 둔 건 그 회사가 도덕적이라서가 아니었습니다. 격리에 실패한 건 그쪽 잘못이고, 자기 모델이 남의 프로덕션에 들어갔습니다. 다만 그쪽은 원인을 모르는 채로 먼저 다 멈췄고, 14만 건을 훑었고, 나흘 만에 피해 조직에 알렸고, 이레 만에 공개했습니다. 생각해 보면 7일이 특별히 빠른 것도 아닌 것 같습니다. 원래 그 정도여야 하는 건데 옆에 놓인 게 40개월이라 빨라 보였을 뿐입니다.

그 40개월 안에서 한 사람이 석 달을 매달렸고, 병을 얻었고, 2025년 3월에 세상을 떠났습니다. 그분이 한 일은 회사가 숨기기로 한 사고를 수습하는 일이었습니다. 유족이 그 일에 대한 보상을 신청했을 때 회사는 그 일이 없었다고 적었습니다.

침해는 어디에나 일어납니다. 노후 서버에 패치가 밀리는 것도 어느 조직에나 있는 일이고, 그것만 가지고 이 회사를 유난히 탓할 생각은 없습니다. 제 레포도 커밋 81개 중에 서명된 게 하나도 없으니까요. 문제는 알고 나서 뭘 했느냐인 것 같습니다. 규제기관에는 40개월 동안 말하지 않았고, 산재 심사기관에는 사건 자체를 부정했고, 유족에게는 밖에 말하지 말라고 했습니다. 이 셋은 보안 사고에서 따라 나온 결과가 아니라 따로따로 내린 선택이었고, 각각 다른 사람한테 실제 손해를 끼쳤습니다.

그 선택은 장애 대응을 하던 층에서 나온 게 아닙니다. 개발자와 운영자가 밤을 새워서 막을 수 있는 건 침해까지입니다. 알고 난 다음에 무슨 말을 할지는 늘 그 위에서 정해지고, 이번에 그 위는 40개월을 골랐습니다.

그래서 저는 40개월을 정한 사람이 누구인지가 밝혀져야 한다고 생각합니다. 회사가 사과하는 걸로는 바뀌는 게 없을 것 같습니다. 사과의 주어는 회사라서 그걸로 직을 잃는 사람은 없으니까요. KT 과징금도, LG유플러스 수사 의뢰도 결국 같은 질문 앞에 있는 것 같습니다. 로그를 지우라고, 서버를 폐기하라고, 신고하지 말라고 정한 사람이 누구였는지. 그 이름이 안 나오면 다음 사고에서도 같은 40개월이 나올 겁니다. 비용을 내는 층과 결정하는 층이 계속 다를 테니까요. 이번에 그 비용을 낸 사람은 이미 작년 3월에 세상을 떠났습니다.