정경심 2심 포렌식 공방의 시작, '비정상 vs 정상 종료'

[Succegator]

변호인단, PC 포렌식 관련 검찰 주장 대대적 반박
강사휴게실 PC 1호가 압수 당일 ‘뻑났다’? 거짓말
위기 몰린 검찰의 PC ‘비정상 종료’ 주장 기만극
검찰의 ‘이유코드 0x500ff’ 로그 자체가 윈도우 버그
마이크로소프트 기술문서도 ‘0x500ff 로그는 버그’

[조국 사태의 재구성] 42. 정경심 항소심 포렌식 공방의 시작, 비정상종료 vs 정상종료

‘표창장 위조’ 혐의를 다루면서 지금까지 필자는 대체로 2019년 ‘조국 사태’ 당시에 벌어졌던 일들을 시간 순으로 쫓아가면서 연재를 이어왔다. 이 연재에서 ‘현재 시점’은 검찰이 강사휴게실 PC들을 임의제출로 압수했던 ‘2019년 9월 10일’이다.

앞서 검찰이 이날 9월 10일에 강사휴게실 PC들이 ‘뻑났다’면서 위법하게 PC들을 통째로 압수해간 상황을 설명하고, 이후 2021년 초에 필자가 이 PC들을 포렌식 해보니 실제로는 그 ‘뻑났다’ 주장이 완전히 허황된 거짓말이었음을 함께 보여드렸다. ☞ 검찰, 강사휴게실PC ‘뻑났다’ 거짓말…법 정면 위반

그런데 2021년 정경심 교수의 항소심 첫 공판에서 이 같은 검찰의 거짓 주장을 공개한 후, 검찰은 기가 막힐 정도의 황당한 기망 술수를 써가며 반박을 시도했다. 이 사건은 2021년 법정에서 벌어진 상황이지만 앞서의 검찰의 ‘뻑났다’ 주장과 직접 연결되는 부분이라 잠깐 시간을 건너뛰어 살펴보도록 하자.

검찰의 ‘비정상종료’ 법정 주장 근거는?

2021년 정경심 교수의 항소심에서 정 교수 변호인단은, 거의 모든 공판마다 검찰의 주장들을 정면으로 뒤엎는 수많은 포렌식 분석 결과를 융단폭격 식으로 쏟아냈다. (물론 그 대부분은 필자가 분석한 결과들이었다.) 1심에서는 검찰이 일방적으로 공격하는 형국이었는데 항소심에서 공수가 정반대로 뒤집어진 것이다.

항소심 첫 공판 후 YTN 보도. 이 '공방'에서 공격이 변호인, 방어는 검찰이었다. YTN 보도 화면 캡처.

특히 4월 12일 첫 공판에서는 강사휴게실 PC 1호가 압수 당일 동양대에서 ‘뻑났다’던 주장 즉 ‘비정상종료’ 주장이 완전한 거짓이었고, 당일 검찰이 동양대 관계자들 몰래 모종의 USB 장치를 삽입해 작업을 했다는 사실까지 폭로했다.

다른 포렌식 분석 결과들도 모두 매우 심각한 것들이었지만, 이 ‘거짓 비정상종료’ 문제는 다른 포렌식 결과들에 앞서 강사휴게실 PC에서 나온 검찰의 증거들 모두의 증거능력을 무효화하는, 그야말로 결정적인 문제였다. (다른 사안들보다 이 문제를 가장 앞세운 목적도 바로 이 때문이었다.)

검찰로서는 이 거짓말 때문에 ‘표창장 위조’ 혐의 전체가 공중분해될 대위기 상황에 처한 것이다. 1차 공판에서 표창장 위조 혐의 증거 전체를 뒤집을 수 있는 중요사실이 터져나오자 관련 보도를 본 시민들도 크게 고무되었다.

그러면 검찰은 이 대위기에 어떻게 대처했을까? 당시 필자와 변호인단도 첫 공판 이후 많이 궁금해 했었다. 항소심 첫 공판에서 강사휴게실 PC의 정상종료 증거를 제출한 후 한 달만인 5월 10일에 두번째 공판이 있었다. 이 2차 공판에서 검찰의 반격을 시도했다.

필자는 이 2차 공판에 참석하지 않았는데, 공판 진행중에 변호인단으로부터 검찰이 ‘정상종료’ 문제에 대해 뭔가 유의미한 듯 보이는 근거로 반박했다는 연락을 받았다. 그게 뭐였을까?

2차 공판에서 검찰은 소위 ‘입시 비리’ 혐의들 관련 주장들을 취합해 법정에서 프레젠테이션을 진행했다. 검찰의 이 프리젠테이션 자료에 ‘정상종료’ 사실에 ‘기술적으로 반박’하는 내용이 포함되어 있었던 것이다.

아래의 3개 페이지가 바로 검찰이 정경심 항소심 2차 공판에서 ‘비정상종료’를 주장한 내용들 중 ‘기술적 근거’ 부분이다.

검찰이 항소심 2차 공판에서 발표한 PPT에서 '비정상종료' 근거 핵심 3개 페이지.

이 3개의 페이지는 모두 기술 관련의 웹 페이지 내용을 캡처한 것으로, 각각 ①구글에서 “윈도우 이유코드 0x500ff”를 검색한 결과, ②DELL사의 커뮤니티 페이지 내용 일부, ③마이크로소프트사의 기술문서 내용이다.

보다시피 세 페이지 모두 왼쪽과 오른쪽으로 나뉘어 있는데, 셋 모두 왼쪽 부분은 필자가 제시한 증거 파일을 바탕으로 깔아놓은 것이고, 실제 검찰이 ‘기술적 근거’라며 제시한 내용은 오른쪽 절반이다.

(민감한 분들은 당장 여기서부터 뭔가 이상하다고 느낄 것이다. 왜 자신들이 주요 근거라고 제시하는 중요 문건들을 잘 알아보기도 어렵게 화면의 절반에만 올렸을까? 사실 이 화면 배치부터가 검찰의 꼼수의 일부다.)

검찰이 위 3개의 PPT 페이지 왼쪽 바탕에 깔아놓은 윈도우 화면은 아래의 화면으로, 필자가 강사휴게실 PC 1호에서 캡처한 것이다. 이 것은 항소심 시작 전에 필자가 변호인단에 전달했던 ‘정상종료’ 관련 증거들 중 하나인데, 그것을 검찰이 가져다 황당한 꼬투리를 잡고 거짓말을 겹겹이 더해 악용한 것이다.

강사휴게실 PC 1호의 종료 과정이 시작된 이벤트로그 내용. ‘이벤트ID 1074’와 ‘이유코드: 0x500ff’를 확인할 수 있다. 박지훈.

위 화면에서 검찰이 구체적으로 꼬투리 삼은 것은 “이유 코드: 0x500ff”라고 되어 있는 부분이다. 그러면 이 ‘이유 코드 0x500ff’란 무엇일까? 정말 ‘비정상종료’ 주장을 입증할 기술적 근거가 될 수 있는 것일까?

(윈도우의 ‘이벤트로그’는 PC와 윈도우 OS에서 세부적으로 무슨 일이 일어났는지 자동으로 기록되는 저장소다. 일종의 ‘블랙박스’와 같은 역할이라고 보면 된다.)

검찰의 ‘이유코드 0x500ff’ 로그 자체가 윈도우 버그

사실 필자는 항소심 시작 전 변호인에 정상종료 사실 증거들을 전달하기 전에 이 이유코드에 대해 자세히 확인했었다. 다만 그 실체가 전체 맥락에서 전혀 중요하지 않고 자세히 알리면 도리어 전체 맥락이 혼란스러워질 수 있어 변호인과 재판부에 자세히 알려주지 않은 것 뿐이다.

결론부터 말해서, 이 ‘이유코드 0x500ff’가 이벤트로그에 기록되는 것 자체가 윈도우7의 버그다. 그래서 이 로그는 존재하지도 않는 양 그냥 무시해도 된다. 하지만 결과적으로 이것도 역시 ‘정상종료’의 증거들 중 하나다.

여기서부터 아래 설명들은, IT전문가나 기술에 관심 있는 준전문가 분들이 관심을 가질 수 있어 세부적인 내용을 설명해두는 것으로, 큰 관심이 없는 일반인 독자분은 모두 건너뛰고 마지막의 결론 부분만 보시면 된다.

먼저, ‘이벤트 1074’ 기록 중에 “이유 코드 0x500ff”가 기록된 로그는 이 로그 항목의 존재 자체가 버그로 인해 잘못 기록된 것이다. 정상적인 ‘이벤트 1074’ 로그는 0x500ff 직전에 먼저 기록된다. 즉 ‘이벤트 1074’가 두번 연달아 기록되고, “이유 코드 0x500ff”가 포함된 뒤의 로그는 버그로 인한 가짜인 것이다.

실제 아래 화면은 필자의 윈도우7 테스트 시스템에서 필자가 ‘윈도우 시작 메뉴->시스템 종료’로 정상적으로 종료했을 때 기록된 ‘이벤트 1074’ 로그들이다. 보다시피 1건이 아닌 2건이 거의 동시에 기록되어 있다.

필자의 테스트용 윈도우7에서 정상적인 시스템 종료 시 기록된 ‘이벤트 1074’ 로그. 1건이 아닌 2건이 기록되어 있다. 박지훈.

아래는 이 두 개의 ‘이벤트 1074’ 로그를 각각 열어본 화면들이다.

두 개의 ‘이벤트 1074’ 로그 각각을 열어본 화면. 앞의 것은 이유코드 0x0, 뒤의 것은 이유코드 0x500ff가 기록되어 있다.

보다시피 두 건의 ‘이벤트 1074’ 로그가 내용이 다르다. 둘의 차이점이 ‘이유코드’의 내용이다. 첫번째 ‘이벤트 1074’는 이유코드가 0x0이고, 두번째는 이유코드가 0x500ff다. (IT 지식이 있는 분들은 다들 아시겠지만 여기서 숫자 앞의 ‘0x’ 표시는 단지 숫자를 ‘16진수’로 표기했다는 의미일 뿐이다.)

다시 확실히 해두자면, 이 두 건의 ‘이벤트 1074’는 필자가 윈도우7 PC를 ‘윈도우 시작메뉴’->’시스템 종료’를 클릭해 필자가 정상적으로 종료시켰을 때 기록된 것이다. 여기서 첫번째 ‘이벤트 1074’, 즉 이유코드 0x0으로 기록된 것이 정상적인 ‘이벤트 1074’이고, 두번째로 이유코드가 0x500ff인 것은 기록되지 않아야 할 것이 윈도우7의 버그로 인해 잘못 기록된 것이다.

따라서 이유코드 0x500ff가 기록된 ‘이벤트 1074’는 실질적으로 아무 의미가 없으므로 그냥 무시하면 되는 것이다. 그리고 그 이전의 ‘이벤트 1074’에 기록된 이유코드 0x0은 ‘이유가 지정되지 않았다’는 의미로서, 비정상종료 등 외부 요인이 아니라 사용자가 정상적으로 종료했을 때만 기록되는 값이다.

(사용자가 정상적으로 종료시켰을 때 0x0 외에 다른 이유코드가 기록될 수도 있다. 즉 0x0은 정상종료 코드이고, 그 외에도 다른 정상종료의 이유코드들이 더 있다.)

강사휴게실 PC 1호가 2019년 9월 10일 저녁 7시 32분 경 종료되었을 때도 이와 동일하게 ‘이벤트 1074’가 두 번 기록되었고, 그중 첫번째는 이유코드 0x0, 두번째는 이유코드 0x500ff로 기록되었다.

즉 강사휴게실 PC 1호는 사용자가 정상종료 시킨 사실이 한 치의 의문 여지도 없이 확고하게 확인된 것이다.

‘이유코드’와 ‘종료 이벤트 추적기’의 관계

원래 이 ‘이유코드’(Reason Code)라는 것은 엄밀히 말해 에러 발생 여부 등을 기록하는 목적이 아니고, 윈도우7과 같은 데스크탑용 윈도우 OS에 유의미한 것도 아니다.

윈도우7이나 10, 11 등 데스크탑용 윈도우가 아닌 ‘윈도우 서버’ OS를 다루어본 사람이라면, 시스템 종료 화면이 데스크탑용 윈도우 와 달리 추가적인 옵션을 선택하도록 되어 있는 것을 알 것이다. 즉 ‘종료하는 이유’를 PC를 종료하려는 사용자가 선택해 기록하는 것이다.

윈도우7이나 윈도우10, 11같은 데스크탑 윈도우OS가 아닌 ‘윈도우서버’ OS는 기본적으로 끄지 않는다. 24시간 7일(‘24/7’), 연중무휴로 내내 켜두고 운영하는 것이 기본이다. 항상 켜져 있는 것을 전제로 하는 것이기 때문에, 끄거나 재시작을 하는 것은 일반적인 상황이 아닌 특별한 경우다.

그런 경우 윈도우를 종료하거나 재시작하는 ‘특별한 이유’를 기록하는 것이 바로 ‘이유코드’다.

위 화면에서는 ‘옵션’의 값이 ‘기타(계획됨)’으로 선택되어 있는데, 이것이 ‘이유코드 0x0’ 값이다. 이 ‘옵션’ 콤보박스를 클릭해서 아래로 펼쳐보면 다양한 이유코드들을 선택할 수 있다. 그리고 이런 모든 이유코드 값들은 마이크로소프트의 기술문서 페이지 ‘시스템 종료 이유 코드‘에 설명되어 있다. ☞ 시스템 종료 이유 코드 (마이크로소프트)

윈도우종료 화면에서 사용자가 선택 가능한 ‘옵션’ 콤보박스에는 가능한 모든 종류의 이유코드가 다 나열되어 있지는 않다. 또 특수한 상황에서 윈도우OS 자체나 혹은 특정 프로그램이 자동으로 기록하는 특수한 이유코드들도 많다.

어쨌든, 이 ‘이유코드’라는 것이 존재하는 이유는, 윈도우서버가 관리자가 모르는 사이에 종료되었거나 재시작되었을 경우, 그 이유를 찾아볼 수 있도록 하기 위한 것이다.

일정 규모 이상의 서버 관리 조직에서는 서버 관리자가 1명보다 많은 경우가 많다. A 관리자가 어떤 필요가 있어 특정 서버를 재시작 했는데, A가 퇴근한 후 교대 근무를 시작한 B 관리자가 그 서버가 왜 재시작 됐는지 몰라 당황할 수 있다. 이럴 때 윈도우의 이벤트로그에서 1074 이벤트를 찾아 이유코드를 확인하는 것이다. 이유코드는 이런 목적으로 설계된 것이다.

그래서 여러 이유코드들 중에는 에러 상황을 의미하는 코드도 있지만 에러와는 무관한 것들이 더 많다. 에러가 아닌 상황을 예를 들자면 유지관리 목적(0x00000001), 업그레이드(0x00000003) 등이 있고, 에러 상황의 예로는 블루스크린(0x0000000F), 전원 오류(0x00060000) 등이 있다.

앞서 언급한 이유코드 목록 문서를 보시면 아시겠지만, 0x500ff(혹은 같은 의미의 0x000500ff)라는 코드는 코드 목록에 존재하지도 않는다. 단지 ‘시스템오류’를 의미하는 0x00050000만 있을 뿐이다. 즉 0x500ff라는 이유코드 값 자체도 엉터리다.

이상은 윈도우서버 OS에서의 이유코드에 대한 설명이었다. 이런 이유코드는 ‘윈도우서버 2012’ 등 윈도우서버 제품에서는 서버 관리를 위해 중요한 역할을 한다. 그런데 데스크탑용 윈도우에서는 큰 의미는 없다.

그럼에도 윈도우서버 2012와 데스크탑용인 윈도우7이 커널(핵심 엔진)을 공유하기 때문에, 굳이 이유코드가 필요하지 않은 데스크탑 윈도우에도 이 이유코드가 (불필요하게도) 내부적으로 존재하고 실제로 동작도 한다. 다만 큰 의미가 없어서 사용자에게 숨겨져 있을 뿐이다. 또 두 윈도우 OS가 로그 버그까지 공유하는 것이다.

(같은 SW개발자로서 개인적인 추측으로는, 이 0x500ff 로그는 마이크로소프트사의 SW개발자가 윈도우의 해당 기능 개발 중에 코드 추적 등의 목적으로 임시로 넣어두었던 테스트용 코드를 정식 출시할 때 미처 지우지 않은 실수로 보인다.)

요컨대, 0x500ff라는 이유코드가 기록된 ‘이벤트 1074’ 로그는 그런 로그가 기록된 자체가 윈도우7과 윈도우서버2012의 버그다. (그리고 앞서 봤듯 윈도우 종료나 재시작에 대한 실제 이유코드 값을 확인하려면 0x500ff가 아닌 그 직전의 ‘이벤트 1074’ 로그를 확인해야 한다.)

마이크로소프트 기술문서, ‘0x500ff 로그는 버그’

이런 엉터리 로그 문제에 대해서, 마이크로소프트의 기술문서 ‘An incorrect shutdown reason code written to SEL on user initiated shutdown’에 꽤 자세히 설명되어 있다. (동일한 내용의 한글 번역 문서도 있다.) ☞ An incorrect shutdown reason code written to SEL on user initiated shutdown

엉터리 이유코드 0x555ff에 대해 설명한 ‘An incorrect shutdown reason code written to SEL on user initiated shutdown’ 문서. 마이크로소프트 기술문서 캡처.

이 문서의 내용을 잠깐 살펴보자. 먼저 Abstract(개요) 항목에 다음과 같이 기술되어 있고,

This article provides a resolution for the issue that an incorrect shutdown reason code written to SEL on user initiated shutdown. (이 문서에서는 사용자가 시작한 종료 시 SEL(시스템 이벤트로그)에 잘못된 종료 이유코드가 기록되는 문제에 대한 해결 방법을 설명합니다.)

그 아래 ‘Symptoms’ 항목에도 비슷하게 아래와 같이 기술되어 있다.

After reboot from a manual shutdown (START->Shutdown), the Windows System Eventlog shows two events 1074. The first entry contains the correct reason code provided by the user, the second looks similar to:
(중략)
Reason Code: 0x500ff

(수동 종료(시작->종료)로 재부팅한 후 Windows 시스템 이벤트로그에 두 개의 이벤트 1074가 표시됩니다. 첫 번째 항목에는 사용자가 지정한 올바른 이유 코드가 포함되어 있고, 두번째는 다음과 비슷합니다: 이유코드: 0x500ff)

Event 0x000500FF (System Failure) is written to the SEL (System Event Log) even if a different shutdown reason was provided by the user who initiated the shutdown. (시스템 종료를 시킨 사용자가 다른 종료 이유를 지정해도 시스템 이벤트로그에는 이벤트 0x000500FF(시스템 장애)가 기록됩니다.)

(여기서 말하는 ‘user initiated shutdown’와 ‘manual shutdown’는 같은 의미로서, PC 사용자가 ‘시작 버튼->시스템 종료’를 클릭해 종료시키는 것을 말하는 것이다.)

보다시피 필자가 앞서 상세하게 설명한 내용과 일치하는 내용이다. 이벤트로그에 ‘이벤트 1074’가 두 번 기록되고, 그 중 두번째에는 0x000500FF 이유코드가 기록되는데, 이 이유코드는 사용자가 지정한 코드가 아니라는 것이다. 또 위 ‘개요’에서 보다시피 이 0x000500FF 이유코드는 ‘잘못된 종료 이유코드’라는 것이다.

(IT전문가라면 당연히 잘 알고 있다시피, 0x500ff와 0x000500ff는 동일한 것이다. 16진수 표기인 0x 다음을 보면 앞에 000이 붙어있느냐 아니냐의 차이일 뿐이다. 일반적인 10진수에서 12345와 00012345가 동일한 것과 마찬가지다. 물론 FF냐 ff냐 하는 대소문자의 차이도 없다.)

그리고 다음으로, ‘Cause’(원인) 항목에는 “Microsoft has confirmed that this is a problem”, 즉 “마이크로소프트는 이것이 문제라는 것을 확인했습니다”라고 되어 있고, “Resolution”(해결방법) 항목에는 “Microsoft will address the problem in future releases.”, 즉 “마이크로소프트는 향후 릴리즈에서 이 문제를 해결할 예정입니다”라고 되어 있다.

여기서 ‘향후 릴리즈에서 해결’이라는 말의 의미는, 이 문제가 발생하는 윈도우 버전들인 윈도우7과 윈도우서버2012에서 수정할 계획이 없고, 그 다음 버전인 윈도우10과 윈도우서버2016에서 해결할 것이라는 뜻이다.

즉 윈도우7을 사용하는 한에는 영영 이 버그가 계속 나타난다는 것인데, 이벤트로그에 0x500ff라는 엉터리 이유코드 값이 기록되는 이 버그가 심각하지 않고 매우 사소하기 때문에 굳이 수정하기 위해 손을 대지 않겠다는 것이다. 서버 관리자들이 단지 이런 버그가 있다는 사실을 알아두기만 하면 되기 때문이다.

또 그 아래 ‘Workaround’(우회방법) 항목에는 시스템 종료시에 “shutdown.exe /r /d P:4:2”라는 커맨드라인 명령을 쓰라고 되어 있다. 이 shutdown.exe 커맨드라인 툴을 사용하면 엉터리 0x500ff 로그가 기록되지는 않는데, 대신 정상적인 ‘이벤트 1074’의 이유코드가 0x0이 아닌 0x80040002로 기록된다.

(원본이 영문 버전이 기술문서의 한글 번역 버전 문서는 자동번역된 내용이라 읽기에 어색한 부분들이 있다. 실제 한글 버전 문서의 상단에 “이 항목의 일부는 기계 번역되어 있을 수 있습니다.”라고 명시되고 있다. 위에서 제시한 번역문들은 필자가 좀 더 자연스럽게 이해되도록 약간 다듬은 것이다.)

경험 있는 기술 전문가라면 이 문서의 형식이 증상, 원인, 해결방법, 우회방법 등을 나열한 데에서 보다시피 ‘기술지원’ 문서라는 것을 알아챘을 것이다. 마이크로소프트 같은 기술 기업들은 자사 제품에서 어떤 문제가 발생했다고 문의가 자주 발생하면 그 질문과 답변의 내용을 FAQ 형식으로 정리해 게시하는데, 이 문서가 바로 그런 문서다.

한편, 일반 윈도우 사용자가 아닌 윈도우서버 관리자들이 자신들의 서버에서 문제가 발생했을 때 이벤트로그를 뒤지다가 이 0x500ff 로그를 발견하고는 이 로그가 자신들의 문제와 관련된 것으로 오인하는 경우가 흔히 있다.

하지만 필자가 확인한 바로는 이는 그냥 오인이다. 앞서 반복해서 설명했듯 0x500ff는 실제 이유코드가 아닌 윈도우7과 윈도우서버2012의 버그로 인해 무작정 기록되는 로그다. 즉 찾고 있는 문제의 원인과 관련이 있는 내용이 아닌 것이다.

이유코드 0x500ff에 대해 검색해서 나오는 문서들 중 위의 마이크로소프트 문서와 이 문서를 참조하는 내용이 아닌 다른 대부분의 글들은, 바로 이렇게 서버 관리자들이 오인해서 헤매는 내용으로, 안타깝게도 실제 오류의 원인과 관련성이 전혀 없는 무의미한 혼란의 기록일 뿐이다.

마이크로소프트가 게을러서 이 사소한 버그를 수정하지 않아 많은 관리자들이 자신들이 겪고 있는 문제 상황의 해결책을 엉뚱한 데서 찾게 되는 것으로, 이 0x500ff가 서버 관리자들을 혼란시키는 미끼인 셈이다.

결론

이만큼 설명했으면 IT 지식이 있는 분들은 0x500ff가 기록된 이벤트 로그 항목이 왜 무의미한 것인지, 또 왜 그냥 건너뛰어야 하는 것인지 웬만큼은 이해를 하셨을 것이다.

이번 회에서 설명한 기술적 사실들을 정리하자면 이렇다.

• 이벤트로그에 ‘이벤트 1074’에 엉터리 이유코드 0x500ff가 기록된 로그 항목은 그냥 무시해야 한다.
• 이 엉터리 이유코드가 나타날 때는 ‘이벤트 1074’ 로그가 두 번 중복해서 기록되고, 그중 첫번째 ‘이벤트 1074’의 이유코드가 진정한 내용이고 두번째의 0x500ff 이유코드는 가짜다.
• 즉 윈도우가 정상적으로 종료됐을 때 이 엉터리 이유코드 0x500ff가 항상 기록된다.
• 마이크로소프트 기술문서 ‘An incorrect shutdown reason code …’에 이 같은 내용이 명확히 설명되어 있다.

안타깝게도 2021년 항소심 과정에서 이 법정 공방이 있었을 당시, 그 관련 보도를 보고는 일부 커뮤니티들에서 이 관련으로 서로 부정확한 주장들을 가지고 논쟁이 벌어지기도 했다. 당시 오가는 논쟁을 보고 많이 답답했었다.

IT전문가들 중 특히 ‘윈도우서버 관리자’라면 당연히 잘 알고 있을, 아니 잘 알고 있어야만 하는 내용인데도, 당시 논쟁에 참여한 사람들 중에는 그런 전문가가 없어 부정확한 지식들이 난무하는 것을 보고 더욱 안타까웠다.

하지만 당시 필자는 이 문제 외에도 십여 가지의 다른 중요 포렌식 쟁점들을 시시각각 동시 분석 중이었던 상황이라 글로 자세히 설명해줄 여유가 전혀 없었다.

그런데 이 같은 기술적 설명은, 지금까지 보셨다시피 다분히 복잡해서 비전문가에게는 직관적이지 않은 면이 있다. 그리고 검찰은 바로 이 점을 파고들어 공판 중 프리젠테이션을 하면서 ‘직관적인 거짓말’들을 동원해 항소심 재판부를 대대적으로 기망했다.

다음 회에서 검찰이 얼마나 어처구니 없는 짓을 벌였는지 조목조목 뜯어 살펴볼 것이다.

출처 : 정경심 2심 포렌식 공방의 시작, '비정상 vs 정상 종료' < 조국 사태의 재구성 < 기획·연재 < 기사본문 - 세상을 바꾸는 시민언론 민들레 (mindlenews.com)