2024년 모의해킹 경고부터 ‘누가 알고 누가 결정했는가’라는 Decision Chain까지
AEP LEGAL COORDINATES · EP-02
확인 기준일｜2026년 9월 28일
2024년 티빙 모의해킹에서 개발·운영환경 접속키가 소스코드에 노출되는 취약점이 발견됐지만 개선되지 않았다는 사실이 민관합동조사단의 공식조사에서 확인됐다. 2026년 침해사고 조사에서도 접속키 관리, DB 자격증명 관리, 개발자 접근권한, 비정상행위 탐지·차단 등 회사 차원의 여러 보안통제 문제가 지적됐다.
여기서 한 가지 질문이 생긴다.
취약점이 발견됐다는 사실과 경영진이 그 위험을 알고 있었다는 것은 같은 말일까?
현재 공개된 자료만으로는 그렇게 말할 수 없다. 2024년 모의해킹 최종보고서를 정확히 누가 받았는지, 누가 취약점 시정책임자였는지, CISO·CPO·대표이사 또는 이사회가 해당 위험을 어느 수준까지 실제로 알고 있었는지는 아직 확인되지 않았다. 티빙 측은 당시 모의해킹 대상에 이번 사고에서 문제가 된 프로젝트가 포함되지 않았다는 취지의 설명도 내놓았다. 이 설명과 정부 조사결과의 관계 역시 모의해킹 범위, 프로젝트 이력, 취약점 조치기록, 실제 공격경로 같은 원자료를 함께 확인해야 판단할 수 있다.
그래서 이 사건에서 가장 조심해야 할 것은 ‘있었다’와 ‘알았다’를 같은 말로 바꾸는 일이다. 보고서가 회사에 존재했다는 것과 특정 개인이 실제로 보고받았다는 것은 다르다. 보고를 받았다는 것과 위험의 구체적인 의미를 이해했다는 것도 다르다. 예산이 삭감됐다는 사실과 누군가가 위험을 알고도 필요한 조치를 거절했다는 사실 역시 같지 않다.
개인의 책임을 따지려면 그 사이를 증거로 연결해야 한다. 누가 위험을 발견했고, 어떤 문서에 기록했으며, 누구에게 보고했는가. 실제로 누가 보고를 받았고 내용을 이해했는가. 그 사람에게 취약점을 고칠 권한과 예산·인력 같은 자원이 있었는가. 그리고 승인·보류·예외·위험수용 같은 결정을 실제로 누가 내렸는가.
이렇게 구분하는 것은 책임을 흐리는 일이 아니다. 오히려 책임이 추측이 아니라 증거 위에 서도록 만드는 과정이다. 같은 자료가 어떤 사람의 책임을 강화할 수도 있고, 반대로 그 사람에게 실제 결정권이 없었거나 필요한 조치를 적절히 했다는 사실을 보여줄 수도 있다.
이 사건에서 지금 말할 수 있는 답은 여기까지다.
회사가 위험을 알고 있었다는 말만으로는 부족하다. 누가 그 위험을 보고받고 이해했으며, 누가 고칠 권한과 자원을 가지고 있었고, 누가 실제 결정을 했는지를 원자료로 복원해야 한다.
아래에서는 법률 분석 전문을 이어갑니다
AEP LEGAL COORDINATES · ARC I · 사건과 책임의 좌표
EP-02｜누가 알고, 누가 결정했는가
사고 전 Knowledge + Decision Chain을 원자료로 복원하는 법
확인 기준일｜2026년 9월 28일
1｜확인된 사실과 아직 확인되지 않은 것
공식조사에서 확인된 출발점은 분명하다. 2024년 모의해킹에서 개발·운영환경 접속키가 소스코드에 숨김없이 노출되는 취약점이 발견됐지만 개선되지 않았다. 2026년 사고조사에서는 접속키 관리, DB 자격증명 관리, 개발자 접근권한, 비정상행위 탐지·차단 등 여러 보안통제 문제가 확인됐다. 조사단은 적절한 키 관리와 탐지·차단체계가 있었다면 개발·운영환경 접근 또는 대규모 유출을 차단할 수 있었을 것이라는 취지의 판단도 제시했다.
다만 2024년 모의해킹의 구체적 대상 프로젝트와 2026년 실제 공격에 이용된 프로젝트·키·경로가 동일한지는 별도의 원자료 확인이 필요하다. 티빙 측은 당시 모의해킹 대상에는 이번에 문제가 된 프로젝트가 없었다는 취지로 설명했다. 정부 조사결과와 회사 설명은 같은 층위의 자료가 아니므로, 어느 한쪽만으로 동일성 여부를 확정해서는 안 된다.
현재 공개자료로 확인되지 않는 부분도 분명하다. 2024년 모의해킹 최종보고서의 정확한 수신자, 취약점의 실제 시정책임자, CISO·CPO·대표이사 또는 이사회의 구체적 인지 수준, 개선예산·인력 요청과 처리 과정, 보안예외·위험수용의 존재 여부, 외주업체와 내부조직 사이의 실제 권한배분은 원자료 없이는 확정할 수 없다.
CISO·CPO 지정자료, 조직도, 업무분장표, 전결·위임규정, 내부관리계획, 위험평가, 모의해킹 보고서, 예산자료, 보안예외·위험수용 문서, 외주계약과 SLA·RACI는 이 빈칸을 확인하기 위한 증거요청 목록이다. 이 목록이 있다는 사실은 해당 문서가 실제 존재한다는 뜻이 아니다.
2｜개인책임은 직함이 아니라 실제 역할과 증거로 귀속된다
대표이사·CISO·CPO·부서장이라는 명칭은 조사할 위치를 정해 주는 표지일 뿐, 그 자체로 개인 형사책임을 완성하지 않는다. 형사책임은 해당 개인에게 실제 부여된 구체적 업무·권한·통제가능성과 문제 된 행위 또는 부작위를 기준으로 개별적으로 판단해야 한다.
대법원 1996. 11. 8. 선고 95도2710 판결은 대학병원 과장이라는 지위만으로 다른 의사가 담당한 모든 환자의 진료를 감독하고 직접 조치할 주의의무가 자동으로 발생한다고 볼 수 없다고 판단했다. 대법원 2011. 9. 8. 선고 2009도13959 판결도 실제로 부여된 업무범위를 넘어선 주의의무를 쉽게 확대해서는 안 된다는 제한을 보여준다. 두 판례는 의료사건이므로 티빙에 직접 적용하는 것이 아니라, 직함보다 구체적인 업무범위와 역할을 특정해야 한다는 판단구조만 비교한다.
업무분담과 위임도 마찬가지다. 대법원 2022. 12. 1. 선고 2022도1499 판결은 의료행위의 위임 상황에서 위임의사에게 수임의사의 설명의무 위반 결과를 귀속하기 위한 요건을 구체적으로 심리해야 한다고 보았다. 이 판결을 일반 기업조직에 직접 대입할 수는 없지만, 위임이 있다는 사정만으로 상위자 또는 위임자의 책임을 자동 인정하거나 자동 배제할 수 없고 구체적인 위임범위와 남아 있는 감독의무를 따져야 한다는 제한적 비교자료로 사용할 수 있다.
반대 방향의 비교판례도 있다. 대법원 2009. 12. 24. 선고 2005도8980 판결은 종합병원 간호사가 자신의 직무 수행을 위해 확인해야 할 기본적 사항을 확인하지 않은 사안에서 업무상과실치상 책임을 인정했다. 이 역시 의료판례이므로 티빙에 직접 대입하지 않는다. 다만 조직적 오류나 상위자의 잘못이 존재하더라도 자신의 구체적 업무범위 안에 독립된 확인·조치의무가 있다면 그 개인의 책임은 별도로 검토될 수 있다는 책임인정 축의 비교자료다.
결국 명목상 Position과 실제 Functional Position을 구별해야 한다. 위임했다는 사실만으로 상위자가 자동 면책되지도 않고, 위임받은 사람이 자동 책임자가 되지도 않는다. 실제 권한·자원·보고체계·감독관계를 확인해야 한다.
3｜“받았다”, “알았다”, “결정할 수 있었다”는 서로 다르다
EP-02에서 가장 위험한 추론은 보고서가 존재한다는 사실을 특정 개인의 인지로 바꾸는 것이다. 이메일의 수신자 또는 참조란에 이름이 들어 있다는 사실, 회의자료가 배포됐다는 사실, 이사회 자료에 안건이 포함됐다는 사실은 중요한 출발점이다. 그러나 그것만으로 형사상 Knowledge를 확정할 수는 없다.
형사소송법 제307조에 따라 사실의 인정은 증거에 의하여야 하고, 범죄사실은 합리적인 의심이 없는 정도로 증명되어야 한다. 따라서 보고서의 존재·배포·수신 같은 외형적 사실만으로 특정 개인의 실제 인식, 결정권 또는 주의의무 위반까지 자동으로 추정해서는 안 된다.
AEP 증거통제식｜Receipt ≠ Knowledge ≠ Authority ≠ Breach.
보고수신이 확인됐더라도 다시 물어야 한다. 실제로 문서를 열람하거나 보고를 들었는가. 보고된 내용이 추상적 일반위험이 아니라 문제 된 접속키 노출·접근통제 등 구체적 취약점을 특정했는가. 위험등급·예상피해·시정기한·권고조치는 어느 수준으로 전달됐는가. 수신자에게 시정명령·예산승인·인력배치·보안예외 승인 같은 현실적 결정권이 있었는가. 다른 책임자에게 적절히 이관하거나 후속조치를 지시했는가. 그리고 그 조치가 완료됐는지 확인할 구조가 있었는가.
“알았다”는 단어 하나가 위험의 존재를 들었다는 사실, 기술적 의미를 이해했다는 사실, 그것을 변경할 권한이 있었다는 사실, 아무 조치를 하지 않았다는 사실을 한꺼번에 대신해서는 안 된다.
4｜“회사가 방치했다”를 13개의 증거질문으로 분해한다
EP-02는 사고 전 의사결정을 다음 13개 노드로 분해한다. 어느 한 단계도 추정으로 건너뛰지 않는다.
• D1 — Discovery｜누가 위험을 처음 발견했는가. 모의해킹 수행자, 내부 보안실무자, 외주업체, 감사조직 등 발견 주체를 특정한다.
• D2 — Documentation｜어떤 보고서·티켓·감사결과·위험등록부로 기록됐는가. 기록의 작성일과 원본성을 확인한다.
• D3 — Escalation｜발견된 위험을 누가 누구에게 보고했는가. 공식 보고경로와 실제 보고경로를 구별한다.
• D4 — Receipt｜누가 실제로 보고를 받았는가. 배포목록·수신확인·회의참석·결재기록을 확인한다.
• D5 — Understanding｜수신자가 위험의 구체적 내용과 심각성을 어느 수준까지 이해했는가. 단순 수신을 인지로 자동 변환하지 않는다.
• D6 — Authority｜누가 시정명령·접근권한 변경·키 폐기·정책 변경 등을 결정할 권한을 가졌는가.
• D7 — Resource Control｜누가 예산·인력·기술자원·외주비용을 승인·배분할 수 있었는가.
• D8 — Decision｜승인·거절·보류·조건부 승인 등 실제 결정은 누가 언제 했는가.
• D9 — Exception｜보안정책의 예외가 존재했다면 누가 요청·검토·승인했는가.
• D10 — Risk Acceptance｜잔여위험을 공식적으로 수용했다면 누가 어떤 조건과 기간으로 수용했는가.
• D11 — Implementation｜승인된 조치를 누가 실제 수행해야 했는가. 실행권한과 실행기한을 확인한다.
• D12 — Verification｜누가 개선 완료 여부를 확인하고 취약점을 종결해야 했는가. 재점검 기록을 확인한다.
• D13 — Failure Point｜사슬이 실제로 어느 지점에서 끊겼는가. 보고 실패인지, 결정 실패인지, 자원부족인지, 실행 실패인지, 검증 실패인지 구분한다.
이 13단계는 책임을 넓히기 위한 장치가 아니다. 오히려 “기업”, “경영진”, “보안팀” 같은 추상명사를 개인의 형사책임으로 바꾸기 전에 필요한 중간증명 단계를 드러내는 장치다.
5｜같은 질문을 모든 Entity에게 반복한다
대표이사·이사회 해당자에게는 실제 보고수신, 위험의 구체성, 시정·예산·인력에 대한 권한, 결재 또는 보류, 위험수용 여부를 묻는다. “최고책임자”라는 명칭만으로 사고 당시 개인 형사책임을 만들지 않는다.
CISO에게는 모의해킹·위험평가가 실제로 전달됐는지, 위험식별·평가·개선 과정에서 어떤 보고와 지시를 했는지, 예산·인력 요청권과 시정권이 어느 정도였는지를 묻는다. CPO에게는 개인정보 보호영역에서 어떤 보고를 받았고 어떤 조사·개선·상위보고를 할 수 있었는지를 묻는다. CISO와 CPO의 역할을 하나로 합치지 않고 실제 겸직 여부와 내부 분장을 확인해야 한다.
정보보호 실무책임자와 개발·운영 책임자에게는 취약점을 가장 먼저 알고 기록했는지, 정상적으로 상위보고를 했는지, 자체 시정권한이 있었는지, 예산·인력 부족 때문에 실행하지 못했는지를 나누어 묻는다. 부서장에게는 업무분장, 전결규정, 실제 보고수신, 인사평가권, 예산집행권, 기술적 차단권을 확인한다. “관리자”라는 이유만으로 감독책임을 추정하지 않는다.
예산결정권자에게는 구체적 위험보고와 비용·인력 산정이 전달됐는지, 실제 승인·삭감·보류권을 행사했는지, 대체통제를 요구했는지를 묻는다. 보안예외 승인자와 Risk Owner에게는 예외의 대상, 기간, 잔여위험, 대체통제, 만료일, 재심사 조건과 승인자의 인식범위를 확인한다.
외주선정 결정자에게는 선정기준·보안능력 평가·RFP·보안특약·재위탁 허용범위를, 외주감독자에게는 SLA 이행·감사·경보·취약점 시정·사고보고와 재위탁 감독을 묻는다. 외주업체에는 계약상 업무범위, 접근권한, 관제·보고·시정 의무, 실제 통제권과 이행기록을 확인한다. 계약관계만으로 티빙 내부자의 책임이 사라지거나 외주업체가 자동 책임자가 되는 것은 아니다.
6｜예산·보안예외·위험수용·외주를 어떻게 읽어야 하는가
6-1｜Money Chain — 예산삭감 = 범죄는 아니다
보안예산이 적었다거나 특정 예산이 삭감·보류됐다는 사실만으로 형사상 과실이 성립하지 않는다. 문제 되는 범죄의 구성요건과 개인별 주의의무, 구체적 위험의 인식 가능성, 실제 결정권, 회피가능성 및 인과관계를 별도로 증명해야 한다.
다만 구체적 중대위험이 확인되고, 위험등급·예상피해·시정방안·필요 비용 또는 인력이 명시되어 실제 결정권자에게 보고됐으며, 그 결정권자가 위험의 구체적 내용을 이해한 상태에서 대체통제 없이 필요한 조치를 거절·보류했고, 그때 보고된 구체적 통제 실패 또는 취약점과 실제 사고 경로가 기술적으로 연결된다는 점까지 원자료로 입증된다면 예산결정 기록은 Knowledge + Authority + Decision을 연결하는 중요한 증거가 될 수 있다.
그래서 Money Chain에서는 연도별 투자액 자체보다 요청 → 검토 → 결정 → 집행의 흐름을 추적해야 한다. 현재 공개자료만으로는 특정 취약점 개선예산이나 인력증원을 실제 요청했는지, 요청했다면 누가 승인·삭감·반려했는지 확인되지 않는다.
6-2｜Security Exception / Risk Acceptance — 문서가 있어도 곧바로 유죄는 아니다
보안예외와 Risk Acceptance는 정상적인 위험관리에서도 사용될 수 있다. 시스템을 즉시 중단할 수 없거나 기술적 제약 때문에 임시 대체통제를 두거나 일정 기간 잔여위험을 수용하는 결정은 그 자체로 불법이 아니다.
고위험 취약점에 대한 Security Exception 또는 Risk Acceptance가 실제 존재하고, 문서에 위험의 내용·등급·기간·대체통제·잔여위험·승인자·Business Owner·CISO 의견 등이 기록되어 있으며, 승인자가 그 위험을 다룰 권한을 가진 상태에서 일정 기간 잔여위험을 수용했고, 그 위험과 실제 사고경로 사이의 기술적 연결까지 입증된다면 해당 문서는 Knowledge + Authority + Decision을 검토하는 중요한 직접자료 중 하나가 될 수 있다. 그러나 그 문서만으로 형사상 주의의무 위반이나 유죄가 완성되는 것은 아니다.
사후적으로 사고가 발생했다는 이유만으로 당시의 위험수용을 “무모한 방치”라고 재구성해서도 안 된다. 위험의 심각도와 발생가능성, 비용, 대체통제, 예외기간, 재심사 시점, 규제상 허용범위와 당시의 기술수준을 함께 봐야 한다. 현재 공개자료에서는 문제 된 취약점에 대해 공식적인 보안예외 또는 Risk Acceptance가 존재했는지 확인되지 않는다.
6-3｜Vendor Chain — 외주는 책임의 자동 이전이 아니다
보안업무를 외주화했다는 사실만으로 위탁자가 자동 면책되거나 자동 책임지는 것은 아니다. 계약상 의무와 실제 지휘·통제·감독관계를 확인해야 한다.
대법원 2009. 5. 28. 선고 2008도7030 판결은 산업안전 분야의 도급관계를 다룬 사건이므로 티빙에 직접 대입할 수 없다. 다만 법령상 구체적 관리·감독의무가 있거나 실제로 개별 업무를 지시·감독한 특별한 사정이 있는지에 따라 도급인의 의무를 달리 보는 판단구조는 외주 보안관계의 조사틀로 참고할 수 있다.
따라서 Vendor Chain에서는 누가 수탁자를 선정하고 어떤 보안기준을 계약에 넣었는지, 누가 SLA 이행·감사·경보·취약점 시정·사고보고와 재위탁을 실제 감독했는지를 나눠 봐야 한다. 외주계약·SLA·RACI가 확보되면 키 관리, 관제, 취약점 보고·시정, 사고통지, 접근·차단권이 누구에게 배정됐는지를 구체화할 수 있다. 현재 공개자료로는 그 실제 배분을 확정할 수 없다.
7｜지금은 반드시 빈칸으로 남겨야 할 14개 질문
• U-01. 2024년 모의해킹 최종보고서의 정확한 수신자는 누구인가.
• U-02. CISO가 해당 취약점을 언제, 어느 수준으로 인식했는가.
• U-03. CPO에게 해당 위험이 보고됐는가.
• U-04. 대표이사 또는 이사회까지 보고됐는가.
• U-05. 취약점의 실제 시정책임자는 누구였는가.
• U-06. 시정기한·Risk Owner·후속 재점검이 지정됐는가.
• U-07. 개선예산 또는 인력증원 요청이 실제 있었는가.
• U-08. 요청이 있었다면 누가 승인·삭감·보류·반려했는가.
• U-09. 보안예외(Security Exception)가 존재했는가.
• U-10. 공식적인 Risk Acceptance가 있었는가.
• U-11. 있었다면 승인자는 누구이며 기간·대체통제·잔여위험은 무엇이었는가.
• U-12. 보안업무의 구체적인 외주 범위와 SLA·RACI는 무엇이었는가.
• U-13. 외주업체를 누가 선정·평가·감독했는가.
• U-14. 각 개인에게 실질적인 시정권·예산권·인사권·접근통제 또는 차단권이 어디까지 있었는가.
이 14개의 빈칸은 원고의 약점이 아니라 개인책임의 과잉귀속을 막는 증거경계다. 어느 항목도 언론보도, 직함, 조직도 또는 사고 규모만으로 채우지 않는다.
8｜가설은 가설로 남기고, 반대증거도 같은 무게로 본다
Knowledge Chain 가설은 모의해킹 보고서·메일·회의록·수신기록을 통해 특정 인물이 접속키 노출이라는 구체적 위험과 그 심각성을 실제로 보고받고 이해했다는 사실이 확인될 때 비로소 검토 수준이 높아진다는 것이다. 보고서가 회사에 존재하거나 이름이 배포목록에 있다는 사실만으로 실제 인지를 인정하지 않는다.
Authority + Money Chain 가설은 구체적 시정조치와 필요한 예산·인력이 요청됐고 위험을 설명받은 실제 결정권자가 승인·보류·삭감·거절한 기록이 확인될 때 그 결정이 개인책임 분석의 중요한 증거가 될 수 있다는 것이다. 예산규모나 삭감 사실만으로는 부족하고, 결정권·구체적 위험인식·대체통제·실행가능성·사고와의 관련성을 별도로 증명해야 한다.
Exception / Risk Acceptance Chain과 Vendor Chain 역시 마찬가지다. 문서나 계약이 존재한다는 사실 자체가 책임을 완성하지 않는다. 실제 위험의 내용, 권한, 대체통제, 실행과 감독, 사고경로와의 연결을 함께 확인해야 한다.
반대로 특정 개인이 위험보고를 받지 않았거나, 보고내용이 해당 취약점을 특정하지 않았거나, 실제 결정권이 없었거나, 필요한 예산·인력을 승인하고 합리적으로 위임·감독했거나 적절한 대체통제를 시행했다는 자료가 확인된다면 그 개인의 책임귀속은 약해지거나 배제될 수 있다.
책임을 찾는 자료와 책임을 제한하는 자료는 같은 증거지도 안에서 읽어야 한다. 해당 개인이 문제 된 위험보고를 실제로 받지 못했다는 자료, 권한이 없었다는 자료, 필요한 예산·인력을 승인했다는 자료, 외주업체를 합리적으로 검증·감사·시정요구했다는 자료, 2024년 취약점과 2026년 실제 공격경로가 기술적으로 무관하다는 자료, 당시 가능한 조치를 했더라도 사고를 막을 수 없었다는 기술적 반증 모두 동일하게 검토해야 한다.
형사책임은 결과책임이 아니다. 사고가 발생했다는 사실이 과거의 모든 위험수용·예산배분·위임·외주결정을 사후적으로 과실로 바꾸지는 않는다.
9｜무엇을 확보해야 Decision Chain이 사실이 되는가
필요한 것은 “책임자의 이름”이 아니라 책임선을 복원할 원자료다. 다음 자료는 반드시 존재한다고 전제하는 목록이 아니라 실제 존재 여부부터 확인해야 할 Evidence Request다.
2024년 모의해킹·취약점 자료에서는 최종보고서 원본, 취약점 목록·위험등급·재현절차·개선권고, 보고서 배포목록, 수신·열람확인, 후속 재점검 결과, 취약점 시정 티켓, 담당자·시정기한·종결사유가 필요하다.
Knowledge / Reporting에서는 CISO·CPO 보고자료, CISO/CPO→대표·이사회 보고자료, 이메일·메신저·회의자료, 회의록, 위험등록부(Risk Register), Risk Owner 지정자료, 내부감사·위험평가를 확인해야 한다. Authority에서는 조직도, 개인별 직무기술서, CISO·CPO 지정서, 업무분장표, 전결규정, 위임규정, 결재권한표, 이사회·경영회의 권한규정이 필요하다.
Money Chain에서는 연도별 보안예산안, 취약점 개선비용 산정, 예산 증액요청, 삭감·반려·보류 자료, 인력증원 요청, 채용계획, 투자심의자료, 실제 결재선과 집행기록을 본다. Exception / Risk Acceptance에서는 신청·승인서, 승인자, 만료일, 잔여위험 등급, 대체통제, 재심사·연장기록을 확인한다. Vendor Chain에서는 RFP·업체평가자료, 외주계약, SLA, RACI, 보안특약, 재위탁 승인, 접근권한, 관제시간, 사고보고 시한, 취약점 시정책임, 감사권, 성과평가·위반통지·시정요청을 확인해야 한다.
형사소송법 제307조의 증거재판주의와 합리적 의심 없는 증명원칙에 비추어, 이 목록은 “이미 존재하는 유죄증거 목록”이 아니다. 각 자료는 실제 존재·원본성·내용·작성맥락부터 확인해야 한다. 확보된 문서는 특정인의 책임을 강화할 수도 있고 반대로 실제 권한이 없었거나 필요한 조치를 적절히 했다는 사실을 보여줄 수도 있다.
10｜법인과 개인, 당시 법과 현재법, 형사책임과 피해회복을 분리한다
10-1｜회사 차원의 문제와 개인의 형사책임은 다른 법률명제다
“티빙이라는 회사의 관리체계에 문제가 있었다”는 사실과 “대표이사·CISO·CPO·부서장·실무자 중 특정 개인이 형사범죄를 저질렀다”는 결론은 서로 다른 법률명제다. 자연인의 직접 형사책임은 그 사람에게 적용되는 범죄구성요건과 개인별 Duty·Knowledge·Authority·Action/Omission·Causation·Proof를 통해 판단한다.
특별법에 양벌규정이 적용되는 경우에도 기초범죄, 행위자의 지위, 법인 업무와의 관련성, 법인의 상당한 주의·감독 여부 등을 해당 조문 구조에 따라 별도로 검토해야 한다. 직원의 위반행위가 있다는 사실만으로 법인이 자동 유죄가 되는 것은 아니라는 것이 대법원 판례의 제한선이다. (대법원 2011. 7. 14. 선고 2009도5516; 대법원 2018. 7. 12. 선고 2015도464)
Decision Chain은 “기업의 잘못”을 곧바로 개인의 유죄로 바꾸는 사다리가 아니다. 회사 차원의 사실을 개인별 증거로 분해하고, 개인별 사실을 다시 해당 범죄의 법률요건에 맞추기 위한 귀속·증명 프레임이다.
10-2｜각 행위 당시의 법을 본다
정부 브리핑은 2026년 5월 30일을 티빙이 데이터베이스 서버의 과부하라는 최초 이상징후를 발견한 시점으로 설명한다. 그러나 EP-02의 법률시점은 하나의 “사고일”로 고정할 수 없다. 2024년 취약점 미조치, 그 이후의 보고·예산·외주·위험수용 결정 등 각 행위 또는 부작위는 원칙적으로 그 행위 당시 시행되던 법령과 규범을 기준으로 평가해야 한다.
2026년 9월 11일부터 시행된 개인정보 보호법 제30조의3은 사업주·대표자를 개인정보의 안전한 처리와 정보주체 권리 보호에 대한 최종적인 책임자로 두고 전문인력과 충분한 예산 지원 등 총괄적 관리조치를 규정한다. 같은 날 시행된 개정 제31조제4항은 CPO 업무에 전문인력 관리·예산 확보와 사업주·대표자 및 이사회에 대한 주요사항 보고 등을 명시했다.
이 강화규정을 2026년 9월 11일 이전 행위의 개인 형사상 의무를 새로 만들어 소급 적용하는 근거로 사용할 수는 없다. 현재법은 앞으로의 사건에서 보고·예산·책임선이 어떻게 더 명확해졌는지를 보여주는 비교자료로 사용할 수 있지만, 사고 당시 Knowledge와 Decision을 증명하는 원자료를 대신할 수 없다.
10-3｜개인 형사책임과 피해회복도 서로 종속되지 않는다
특정 개인의 형사책임이 현재 단계에서 확정되지 않았다는 사실만으로 피해자의 민사상 손해배상, 분쟁조정, 보험 또는 다른 회복 가능성이 당연히 소멸하는 것은 아니다. 반대로 회사의 자율보상·보험지원이나 피해회복 가능성이 존재한다는 사실만으로 특정 개인의 형사책임이 증명되는 것도 아니다.
형사책임과 피해회복은 법적 목적과 요건, 증명수준을 각각 따로 검토해야 한다. EP-02에서는 이 경계만 잠그고 손해배상·법정손해·위자료·보험·환급·환부 등 구체적인 피해회복 수단은 Arc III의 회복편에서 별도로 검토한다.
11｜현재 단계에서 금지되는 결론
현재 공개자료는 특정 경영진·CISO·CPO·부서장·예산결정자·보안예외 승인자·외주선정자·외주감독자의 개인별 Knowledge + Decision Chain을 확정하지 않는다. 향후 원자료가 특정 위험의 보고수신, 실제 이해, 시정권·예산권, 거절·보류·예외·위험수용 결정과 사고경로를 하나의 연속된 사슬로 연결한다면 형사책임 검토 수준은 높아질 수 있다. 반대로 결정적 고리가 확인되지 않거나 책임제한 증거가 강하면 책임은 약화되거나 배제될 수 있다.
따라서 원자료가 확보되기 전에는 다음 자동전환을 하지 않는다.
• “대표이사가 2024년 취약점을 알고도 방치했다.”
• “CISO가 보고를 받고도 묵살했다.”
• “CPO도 해당 위험을 알고 있었다.”
• “보안팀이 개선예산을 요청했지만 경영진이 거절했다.”
• “경영진이 위험을 수용하기로 결정했다.”
• “보안예외가 승인되어 취약점이 방치됐다.”
• “티빙이 외주업체에 책임을 떠넘겼다.”
• “외주업체가 사고의 책임자다.”
• “보고서에 이름이 있었으므로 그 사람은 위험을 알고 있었다.”
• “직급이 높으므로 그 사람이 최종 결정자였을 것이다.”
AEP Publication Gate｜개인별 Knowledge·Authority·Decision이 원자료로 확인되지 않는 부분은 FACT로 승격하지 않고 UNKNOWN 또는 HYPOTHESIS로 유지한다. 이것은 법률상 별도의 구성요건이 아니라, 사실과 책임귀속을 과장하지 않기 위해 이 시리즈가 채택한 편집·증거통제 원칙이다.
12｜POLICY — 처벌 확대보다 Decision Chain이 사라지지 않게 하는 기록구조
EP-02에서 제도개선의 핵심은 새로운 처벌죄를 곧바로 만드는 것이 아니라, 사고가 난 뒤 “누가 알고 누가 결정했는가”를 원자료로 복원할 수 있도록 중대한 보안의사결정의 기록을 남기는 방향이다. 이것은 현행법의 내용을 설명하는 문장이 아니라 별도의 정책제안이다.
• Critical/High 수준 취약점의 보고대상과 대표·이사회 보고기준을 사전에 정한다.
• 고위험 취약점마다 Risk Owner, 시정기한, 종결기준과 재점검 결과를 기록한다.
• Security Exception의 승인자, 사유, 만료일, 대체통제, 잔여위험과 재심사 결과를 남긴다.
• 중대 보안위험에 관한 예산·인력 요청이 거절 또는 보류되는 경우 결정주체와 사유를 기록한다.
• 공식 Risk Acceptance에는 승인주체, 위험등급, 대체통제와 재검토 시점을 남긴다.
• 외주업체 선정·평가·SLA·감사·위반통지·시정요구·재위탁을 추적할 수 있는 감독기록을 유지한다.
이 제안은 현행법에 위 기록항목이 모두 동일한 형식으로 이미 의무화되어 있다는 뜻이 아니다. 어느 범위까지 법정의무로 만들 것인지는 별도의 입법·제도설계 문제다.
13｜EP-03로 넘기는 선 — 사고 전 Decision Chain과 사고 후 Response Chain
EP-02는 사고가 현실화되기 전까지의 위험인지와 의사결정을 다룬다. 최초 이상징후 이후 누가 언제 상황을 공유받았는지, 차단이나 키 폐기·계정정지·내부전파·신고가 얼마나 늦었는지, 당시 어떤 즉시조치가 가능했는지는 EP-03의 사고 후 Response Chain에서 분석한다.
정부 브리핑에는 최초 이상징후 후 정보보호 전담조직과 CISO에게 상황이 전달되기까지 약 14시간이 걸렸다는 내용이 포함되어 있다. 이 사실을 EP-02에서 특정 개인의 사고 전 Knowledge를 증명하는 근거로 사용하지 않는다. 사고 이후 시간축과 부작위책임의 경계는 다음 편에서 따로 본다.
14｜결론 — 누가 알고, 누가 결정했는가에 답하는 법
티빙 사건에서 회사 차원의 보안통제 문제와 2024년 취약점 미조치는 공개된 조사자료만으로도 중요한 사실이다. 그러나 특정 개인의 형사책임은 그 사실의 크기에서 자동으로 나오지 않는다.
필요한 것은 사람의 이름을 먼저 정하는 일이 아니다. 위험이 발견된 순간부터 기록·보고·수신·이해·권한·자원·결정·예외·위험수용·실행·검증까지의 사슬을 원자료로 복원하는 일이다. 같은 문서가 책임을 강화할 수도 있고, 반대로 적절한 위임·예산승인·대체통제·감독을 확인하여 책임을 제한할 수도 있다.
따라서 EP-02의 결론은 유죄도 무죄도 아니다. 현재 공개자료로 확인할 수 있는 범위와 확인할 수 없는 범위를 정확히 분리한 뒤, 개인별 Knowledge와 Authority와 Decision이 어디에서 실제로 만나는지 증거로 찾는 것이다.
회사가 위험을 알고 있었다는 추상적 표현만으로는 부족하다. 누가 그 위험을 발견했고, 누가 보고받았으며, 누가 실제 내용을 이해했는지, 누가 시정할 권한과 자원을 가지고 있었으며, 누가 승인·거절·보류·예외·위험수용 결정을 실제로 했는지를 원자료로 복원해야 한다. 그 사슬이 확인되기 전까지 직함이나 사고의 크기로 개인책임의 빈칸을 채우지 않는다.
참고자료
• 과학기술정보통신부·민관합동조사단, 「티빙(TVING) 침해사고 조사결과 발표」, 2026. 9. 3.
• 과학기술정보통신부, 「티빙 민관합동조사단 조사결과 주요내용」 브리핑, 2026. 9. 4.
• 개인정보보호위원회, 「㈜티빙 이용자 개인정보 유출 사고 관련 조사 착수」, 2026. 6. 4.
• 대한민국 「개인정보 보호법」 — 사고 전 각 행위 당시 시행법과 2026. 9. 11. 시행 현행법을 구분. 현행 제30조의3, 제31조제4항은 비교자료로 사용하되 2026. 9. 11. 이전 행위에 소급하여 개인의 형사상 의무를 새로 만드는 근거로 사용하지 않음.
• 대한민국 「정보통신망 이용촉진 및 정보보호 등에 관한 법률」 제45조의3 — CISO 관련 규정. 사고 당시 시행본과 이후 개정본을 구분.
• 대한민국 「형법」 제14조·제17조·제18조·제30조·제32조·제268조.
• 대한민국 「형사소송법」 제307조 — 사실의 인정은 증거에 의하여야 하며, 범죄사실은 합리적인 의심이 없는 정도로 증명되어야 한다는 증거재판주의·증명원칙.
• 대법원 1996. 11. 8. 선고 95도2710 — 직급과 구체적 주의의무의 한계.
• 대법원 2009. 12. 24. 선고 2005도8980 — 자신의 구체적 직무범위 안에서 독립적 확인·주의의무를 인정한 책임인정 비교사례.
• 대법원 2009. 5. 28. 선고 2008도7030 — 도급·외주 관계에서 의무의 원칙과 예외에 관한 판단구조.
• 대법원 2011. 7. 14. 선고 2009도5516 — 양벌규정상 법인의 상당한 주의·감독 여부를 별도로 심리해야 한다는 제한.
• 대법원 2011. 9. 8. 선고 2009도13959 — 실제 업무범위를 넘어선 주의의무 확대 제한.
• 대법원 2018. 7. 12. 선고 2015도464 — 직원 위반행위와 법인의 관리·감독상 과실을 구별한 책임제한 사례.
• 대법원 2026. 3. 12. 선고 2025도10321 — 구 개인정보 보호법 양벌규정의 행위자·법인 적용범위를 엄격하게 해석한 최근 책임귀속 제한사례.
• 대법원 2022. 12. 1. 선고 2022도1499 — 의료행위 위임관계에서 위임의사의 책임요건을 구체적으로 심리하도록 한 판결. 일반 기업조직에는 제한적 비교자료로만 사용.
• 이데일리, 「티빙, 1인당 2만원 보상안 내놨지만…총액·재무부담은 ‘함구’[일문일답]」, 2026. 9. 3. — 티빙 기술본부장의 “2024년 모의해킹 대상에는 이번에 문제가 된 프로젝트가 없었다”는 설명 및 내·외부 보안인력 관련 회사 설명. 정부 공식조사와 구별하여 당사자 설명으로만 사용.
Savor Balance · Korean Archive · Yohan Choi
