카카오톡 논란과 해명, 핵심을 외면하지 말라

By | 2011년 05월 28일

한 대학교수의 부인 살해에 대한 증거 중 하나로 대학교수와 내연녀간 오고간 카카오톡 메시지가 제시되었습니다. 결국 이것이 결정적 증거로 작용하여 살해범의 자백에 큰 동기가 되었던 것으로 보입니다.

수사중인 경찰이 카카오톡 메시지를 확보한 방법은 형사소송법상 규정된 압수·수색입니다. 가입 사항을 파악하기 위한 통신자료제공요청(전기통신사업법 상 규정), 접속 로그(접속시간 및 접속위치/IP)를 확보하기 위한 통신사실확인자료제공요청(통신비밀보호법 상 규정)과는 궤를 달리하는 사법 절차로써, 당사자 혹은 제3자의 자료 등을 확보하기 위한 가장 강력한 사법 집행 수단 중 하나입니다.

압수수색은 법원에서 발부한 영장에 따라 집행되는데, 현행 형사소송법에서는 실체가 존재하는 물건에 대한 압수수색 및 압수수색을 집행하는 수사공무원의 행위 보장에 대한 내용을 규정하고 있습니다. 이렇게 말하는 것은 현행 법령상, 실체가 존재하지 않는 디지털 자산에 대한 내용이 형사소송법에서는 규정되어있지 않다는 얘기입니다.

따라서 사법기관에서는 별도의 내규 등을 마련하여 디지털 자산에 대해서도 압수수색을 집행하고 있으며, 보통 디지털 자산에 대한 압수수색의 대상이 되는 전기통신사업자들도 이 절차에 따르고 있습니다. 카카오톡도 이런 절차를 수행했으며, 사업자가 거부할 명분이 없다는 것을 매우 잘 알고 있기 때문에 이에 대해 토달 생각은 없습니다. 그러나.

이번 이슈에 대한 핵심은 압수수색 영장에 의한 데이터 제공이 아닙니다. 왜 삭제한 데이터를 굳이 복원하여(혹은 경찰이 복원할 수 있는 상태로 보관하여) 제공했느냐하는 것입니다. 핵심은 삭제된 메시지의 복원이라는 것이지요. 이 부분에 대해서 카카오톡측은 아래와 같이 얘기합니다.

삭제된 메시지를 복원하는 것 역시 경찰의 영장이 없으면 불가능하다는 게 카카오측 설명이다. 역으로 경찰이 영장을 제시했을 경우에는 이를 법적으로 거부할 수 없다는 것. 강 교수의 삭제된 메시지도 경찰이 영장을 제시했기 때문에 협조한 것이고, 복원작업도 경찰이 직접 해당 저장장치를 복원 전문업체에 의뢰해 수행한 것이지 카카오톡이 간여한 바 없다고 했다.

카톡이 감청? “확인안된 메시지만 저장” 머니투데이, 2011-5-27 / http://winm.kr/myp1CO

경찰이 영장을 제시했을 경우 이를 법적으로 거부할 수 없는 것은 맞습니다. 되려 거부하다가는 처벌받으니까요. 거듭 말하지만 카카오톡이 영장 집행에 협조한 것을 가지고 토다는 것은 아닙니다. 매우 잘 알고 있다니까요.

카카오톡의 인터뷰를 보면 “경찰이 저장장치를 가져다가 복원 전문업체에 의뢰해 수행했다” 라고 이해됩니다. 이 자체는 문제될 것이 아닙니다. 앞서도 얘기했지만 압수수색은 기본적으로 실체가 있는 물건에 대한 강제 절차이기 때문에 “서버 자체에” 대해 압수 영장이 발부되었다면 경찰이 서버 떼가도 됩니다. 그런데 이번 사건의 담당 수사 관서는 부산 북부경찰서이고, 카카오톡 본사는 분당에 있습니다.

물론 IDC야 본사에 두진 않았겠죠. WHOIS 때려보니 KINX 안에 있는데 KINX는 도곡, 가산, 분당, 상암에 센터를 두고 있습니다. 어째 되었던 경기도를 벗어나진 않는다는 얘기입니다. 그렇다면 부산에서 분당까지 친히 방문해서 서버를 들고 가셨다? 서버라는 놈이 덩치에 안 어울리게 열라 민감하셔서 이전시 무진동차가 필수라는 것을 감안하면, 저 같으면 저런 짓 안합니다. 거기에 IDC에 쳐박혀있으니 반출신청도 해야하고 뭐도 해야하고.. 게다가 복구업체까지 들고 가서 복구한 뒤 다시 가져오고.. 그 복잡한 절차를 수행하느니 저 같으면 그냥 문서 팩스로 보내면서 딱 한줄 더 붙이겠어요. “삭제된 데이터 포함.” 이렇게 하면 업체가 알아서 뽑아주는데 뭣하러 그 고생을 하냔 말이죠. 무슨 국가 변란 사건도 아니고.

카카오톡의 오락가락 해명+변명 덕분에 실제로 그 메시지가 삭제되었다가 복구된 건지, 애초에 삭제되지도 않았던 것인지가 확실치 않은데, 일단은 삭제된 메시지가 복구되었다고 하면.. 더 웃기는게 일일 메시지 유통량이 3억건이 넘는 서비스의 디스크가 아무리 섹터를 별도 할당하더라도 오버라이팅이 안되고 배기냔 말이죠. 거기에 개인용 PC도 아니고 서버니까 분명 싱글 드라이브가 아닌 레이드 구성을 했을텐데, 아무리 생각해봐도 복구가 되는게 더 신기한 상황이란 말입니다. 삭제가 진짜 되었다면. 카카오톡이 말한 삭제가 물리적 삭제가 아닌, flag 달아서 삭제된 것으로 간주하는 것이라면 되려 명쾌하겠군요. 그렇게 된다면 카카오톡의 해명은 그냥 뻥이 되겠지만, 설마 그럴리는 없다고 생각하도록 하지요.

삭제된 메시지가 복구된다는 것은 기술적 문제를 차치하더라도 서비스에 대한 정책적 신뢰도를 낮추는데 일조합니다. 기술적 문제에 대비한 백업을 남기는 것에 대해서 토달 사람은 없어요. 컴퓨터라는게 묘한 녀석이라 몇날몇일을 쌩쌩하게 작동하더라도 하루아침에 정줄 놓고 맛가는 일이 비일비재하단 말이죠. 그런 경우를 대비하여 백업을 남기고, 문제가 생겼을 때 백업에서 복구를 한다는 것에 대해 뭐라 그러는 사람은 거의 없다고 봅니다.

하지만, 복구 결과물이 이번 용도처럼 다른 목적으로 쓰이거나, 심지어 정책적 삭제나 사용자 본인 의사에 따른 삭제 데이터까지 모조리 복구가 된다는 것은 결국 헌법에서 규정하고 있는 통신 비밀의 보호가 부정될 수 있는 여지가 다분하기 때문에 문제가 되는 것입니다. 메시지 없어졌다는 컴플레인이 있기 때문에 삭제 데이터까지 복구될 수 있는 여지를 남긴다? 복구할 수 없도록 하는 기술적 방법을 이미 알고 있는데도? 그런 걸 제어하려고 정책이 있는 것이고, 카카오톡은 그걸 망각했거나, 무시했을 뿐입니다. 아주 심플해요. 그런 건 사용자를 배려하는 게 아닌, 자기 편하려고 하는 일인거죠.

무엇보다도 카카오톡은 이번 일을 통해, 각 수사관서의 표적이 될게 뻔해요. 진실이야 어떻든 간에, 각 수사관서에서는 “카카오톡은 삭제된 메시지도 복구해준다는데?”라는 인식이 박힌 상태이지요. 이번 사건과 비슷한 경우 뿐 아니라, 이제는 국가보안법 위반부터 구멍가게 털이범까지 온갖 협조 요청에 시달릴 것이고, 압수수색영장도 뻑하면 날아오겠죠. 그것으로 인해 카카오톡이 시달리는 것은 그들 스스로가 자초한 일이겠지만, 무엇보다도 사용자들로 하여금 “내 메시지도 그럴 수 있다”는 인식을 심어줬다는 측면에서, 지금까지 이통사들에게 시달린 것은 상대적으로 가벼워보일 정도로, 카카오톡의 진정한 위기는 지금 막 다가오고 있는지도 모르겠습니다. ⓣ

Author: 너른호수

2004년부터 모 포털 사이트 알바로 시작한, 취미로 하던 웹질을 직업으로 만든 일을 굉장히 후회하고 있는 이메일 서비스 운영-기획자 출신 앱 PM(?)-SI 사업PM. 메일쟁이로 지낸 15년에 치여 여전히 이메일이라면 일단 관심이 갑니다. 버팔로이자 소원이자 드팩민이고, 혼자 여행 좋아하는 방랑자. 개발자 아님, 절대 아님, 아니라고!

11 thoughts on “카카오톡 논란과 해명, 핵심을 외면하지 말라

  1. 창천

    심히 공감가는 포스트입니다. 인터넷사이트를 운영 담당하고 있는 입장에서 카카오톡의 일처리가 이해 안 가는것은 아니나 그래도 좀 아니다 싶네요.

    Reply
  2. 지나가다

    객관적인 내용 잘 봤습니다.
    언급하신 부분들 중에 기술적인 관점에서 맞는 부분도 있지만, 서비스 운용 관점에서 또 다르게 생각하면 그렇지 않은 부분도 있는 것 같아 댓글 달아봅니다.
    “일일 메시지 유통량이 3억건이 넘는 서비스의 디스크가 아무리 섹터를 별도 할당하더라도 오버라이팅이 안되고 배기냔 말이죠”
    이 부분은 일반적인 관점에서 생각하면 틀린 부분이 아니겠지만, 실제 대용량 서비스를 운영하는 입장에서는 다를 수도 있다고 생각됩니다.
    많은 분들이 일단 OS 에서 삭제명령을 내리더라도 실제 디스크에서는 지워지지 않는 다는 것을 알고 계실 것입니다. 그리고는 어느 시점엔가 해당 디스크블럭에 다른 데이터가 써지는 순간 정말 복구가 어려운 deleted 상태가 되는 것입니다.
    그런데 요즘 나오는 OS 는 꽤 스마트하고, 디스크 IO 에 있어서 random access 가 가장 피해야할 작업이라는 것을 잘 알고 있습니다.
    그렇기 때문에 실제 OS 에서는 저장할 파일 사이즈에 따라 다르겠지만 디스크에서 연속된 데이터 블럭이 있는 한 이미 데이터가 기록되고 다시 삭제된 파편화된 블럭을 좀 처럼 사용하지 않습니다.
    그럼 이런 OS 위에 올라가 있는 DB 는 어떨까요? DB 도 벤더에 따라 다르겠지만, DB 야 말로 디스크 IO 는 가장 줄여야하는 공공의 적입니다. 대부분의 DB 는 직접 데이터 블럭을 관리하며, insert 되는 데이터는 대부분 연속된 데이터 블럭에 저장을 하게 됩니다. 중간에 delete 가 된 데이터 블럭이 있더라도, 관리자 또는 정해진 자동화 정책에 의해 파편화된 데이터 블럭을 다시 연속적인 데이터 블럭으로 재배열하기 전에는 거의 사용하지 않습니다.
    그럼 DB를 관리하는 DBA 입장은 어떨까요. 서버나 스토리지 자원이 충분히 지원되는 상황에서 DB 가 사용할 연속된 스토리지가 부족해 DB 가 online 상태에서 파편화블럭의 재배열 작업이 돌고 있다면 이는 정말 최악의 상황입니다. DB 디스크 IO 가 급등하면서 서비스가 정상적으로 이루어 지지 않을께 뻔합니다.
    카카오톡이 DB 스토리지를 넉넉하게 추가할 돈이 없거나, 대용량 DB 관리경험이 있는 DBA 가 없다면, 그래서 (이게 현실적으로 가능할 지는 모르겠지만) 엄청나게 큰 스토리지를 통 DB 하나에서 매일 3억건의 데이터를 쓰고, 또 지우고 있다면, 일반 PC 에서도 왠만큼 프로그램들을 많이 깔고 지우고 하지 않는 한 발생하지 않는 파편화블럭에 데이터 기록이라는 부분이 생길지도 모르겠습니다.
    그런데 아마 그렇다면, 카카오톡은 정말 엄청나게 좋은 DB 를 쓰고 있을 것입니다. 일일 3억의 데이터를 쓰고 지우는 걸 하나로 처리하다니!!
    하지만 이런 가정(통DB)이 실현가능한지는 모르겠습니다.
    모르긴해도, 몇십개되는 DB 로 분산 처리될 것이고, 가끔 느리거나 장애가 나긴해도 수준급의 DBA는 없더라도 만일 이게 DB 스토리지가 부족해 IO 가 높아진 경험을 했던라면, DB 마다 데이터양의 몇배는 되는 여유공간을 가지고 운영하고 있을 거라 생각이 됩니다.
    말이 주져리 주져리 두서가 없었지만, 내용은 간단합니다.
    매일 3억이 발생하는 DB 에서 삭제된 블럭이 다시 overwrite 되지 않고 남아있을 수 있나?
    “네, 그렇습니다.”
    오히려 실서비스 운영환경에서는 어쩌면 overwrite 되지 않을 가능성이 더 많습니다.

    Reply
    1. 우꺄꺄

      단기저장용 메시지를 모두 디비에 쓴다는 생각이 잘못된 걸로 보이네요. SE 분들이나 DBA 하시는 분들은 RDB 이외에 접할 기회가 많지 않으시겠지만 수시로 쓰기 지우기가 반복될 데이터 구조를 파일에 쓴다는 건 매우 무모하고 해선 안될 짓입니다. 그건 다 알고 계시는 거죠..
      애초에 서버 개발자가 단문 메시징에 적합한 서버를 개발하고 장기 보관으로 이동될만한 정보만 DB에 쌓는 게 맞죠. RDB가 만능은 아니니까요.
      제정신으로 서버를 만들었으면 당연히 중간 서버가 있을 것이고, 그걸 복구할 수 있었다는 건 제 생각엔 별도로 로그를 쌓는다는 것 밖에는 말이 안되네요.

      Reply
  3. 우연히

    우연히 보고 덧글남깁니다.
    경찰은 서버 압수하면 잘 가져오는 경우가 드뭅니다. -_- idc에서 떼어가는 것도 관리하는 업체에 반출요청해서 준비해놓으면 가져가기만 하면 되구요.(법은 어떤지 몰라도 현실은 이렇습니다.) 경찰의 업무협조를 종종 받는사람으로부터 들은 이야기입니다.

    Reply
    1. 너른호수 Post author

      저도 업무협조 요청을 매일 받는지라(-_-;; ) 잘 알고 있습니다. 서버 자체를 꼭 떼가지 않아도 되는 경우라면(그 안의 데이터만 확보할 수 있다면), 특히 특정 서버가 현재 on-service 목적으로 사용되고 있는 중이라면 굳이 떼가진 않습니다.
      경찰이 떼가는게 어렵거나 권한이 없어서 안하는게 아니라, 서버마다 다른 파일시스템 확인도 그렇고(뭐 몇가지 안되겠지만) 현재 서비스중인 서버 떼가면 사용자 불편이라던지.. 뭐 생각보다 어렵지 않은 반출신청 이런 문제뿐 아니라 이래저래 여러모로 여럿 피곤해지니까 데이터 추출 정도로 갈음하는 경우가 생각보다 많답니다. 🙂

      Reply
  4. 날자고도

    원래 DB는 하나의 파일또는 테이블마다 하나의 파일을 사용하므로,
    데이터를 삭제하면 물리적으로 복구가 힘듭니다.
    쉽게 말해서 aa.txt가 있을경우, 중간에 한줄없애고, 저장한것과 같죠.
    그런데, 계속적으로 쓰고 지우므로 물리적으로는 복구가 힘듭니다.
    그에 반해서 DBA는 DB명령을 사용해서 그냥 원래상태로 복구가 가능하죠.
    결론적으로, 하드웨어복구하는곳에서 했다면, 99.99%거짓말이고,
    DBA가 했다면, 카톡측에서 해줬겠죠

    Reply
  5. Pingback: 칫솔_초이의 IT 휴게실

  6. Pingback: ANDY의 쇼핑몰 블로그

  7. 하늘빛

    예전에 구글 g메일에 저장 장치 사고가 나서 메일 수십 만 통이 사라진 적이 있었죠.
    이에 구글에서는 각종 백업 수단―심지어 테이프 백업장치까지―을 써서 거의 모든 메일을 복구해 냈습니다.
    개인의 ‘잊혀질 권리’는 기업의 ‘이익 추구권’이나 국가의 ‘공익’ 앞에 무용지물이 되곤 합니다.

    Reply

답글 남기기

이메일 주소는 공개되지 않습니다. 필수 필드는 *로 표시됩니다