제목
레거시 프로젝트에서 'DMCA 인질극' 벌어졌을 때, 당황하지 않고 비즈니스 방어하는 현실 프로토콜
본문
야생과도 같았던 소규모 스타트업 시절을 지나, 체계가 잡힌 지금의 회사로 오기까지 참 별의별 일을 다 겪었다고 생각했습니다. 서버실 에어컨이 고장 나 선풍기를 돌리던 밤이나, 프로덕션 DB를 날려 먹고 복구 스크립트를 짜던 새벽 같은 것들 말이죠. 하지만 최근 지인의 부탁으로 잠시 들여다본 오래된 PHP 레거시 프로젝트에서 겪은 일은, 8년 차 개발자인 저에게도 꽤 신선한 충격이었습니다. 코드가 엉망이라서가 아닙니다. 바로 '사람'이 만든 부채가 기술적 문제를 넘어 법적 공격으로 돌아왔기 때문입니다.
상황은 평온한 주말 아침, 클라이언트의 다급한 전화 한 통으로 시작되었습니다. 제가 유지보수를 돕던 웹사이트가 접속 불가 상태가 됐다는 겁니다. name.com에 호스팅 된 평범한 PHP 사이트였고, 저는 전날 밤 아주 사소한 텍스트 수정만 배포한 상태였습니다. "설마 내가 뭘 잘못 건드렸나?" 하는 불안감에 로그를 뒤졌지만, 서버는 깨끗했습니다. 문제는 엉뚱한 곳에 있었습니다. 네임서버(Name Server)가 비활성화되어 있었던 겁니다.
호스팅사로부터 날아온 메일의 제목은 DMCA Takedown(디지털 밀레니엄 저작권법 위반 통지)이었습니다.
알고 보니 이 사이트를 처음 개발했던 전임 개발자가 "잔금을 다 받지 못했다"라고 주장하며 호스팅사에 저작권 침해 신고를 넣은 것이었습니다. 클라이언트는 분명 합의 하에 모든 비용을 지불했다고 주장했지만, 개발자는 잠수를 탔다가 돈이 필요해지자 사이트를 인질로 삼은 셈이었죠. 클라이언트는 당장 사이트를 복구해야 한다며 발을 동동 구르고 있었습니다.
저는 우선 기술적인 응급조치를 취했습니다. 호스팅 계정 자체는 살아있었기에, 네임서버를 Cloudflare의 무료 플랜으로 우회시키고 호스팅 IP를 직접 포인팅했습니다. 다행히 사이트는 다시 열렸습니다. 하지만 진짜 문제는 이때부터였습니다.
클라이언트는 "그 개발자에게 요구하는 돈을 주고 끝내겠다"라고 말했습니다. 저는 즉시 만류했습니다. 기술적인 관점이 아니라 비즈니스 생존 관점에서 말이죠. "지금 돈을 주면, 나중에 또 돈이 필요할 때마다 똑같은 짓을 할 겁니다. 게다가 신고를 철회한다는 보장도 없어요. 차라리 지금 조금 불편하더라도 호스팅을 안전한 곳으로 이전(Migration)하는 게 낫습니다."
하지만 불안했던 클라이언트는 제 조언을 뒤로하고 그 개발자에게 돈을 송금했습니다. 개발자는 돈을 받고 DMCA 신고를 취소하겠다고 했죠. 상황이 종료된 줄 알았습니다. 그러나 몇 시간 뒤, 사이트는 다시 내려갔고 호스팅 관리자 페이지는 접속조차 되지 않았습니다.
이번엔 호스팅사(Name.com)가 계정을 강제 해지(Terminate)해버린 겁니다. DMCA 이슈가 번복되고 시끄러워지자, 리스크를 피하기 위해 고객을 내치기로 결정한 것이죠. 결국 클라이언트는 돈은 돈대로 쓰고, 호스팅 계정은 날아가 버렸습니다. 우리는 부랴부랴 남은 소스 코드를 긁어모아 BlueHost로 이전해야 했습니다. (솔직히 BlueHost를 추천하고 싶진 않았지만, 급한 불을 끄기 위한 클라이언트의 선택이었습니다.)
이 사건을 통해 저는 개발자가 단순히 코드만 짠다고 해서 서비스가 지켜지는 게 아님을 뼈저리게 느꼈습니다. 특히 인수인계가 불투명한 레거시 프로젝트를 다룰 때, 우리가 반드시 챙겨야 할 '생존 프로토콜'은 다음과 같습니다.
첫째, 인프라의 소유권을 분리하십시오. 도메인 등록 업체(Registrar), DNS 관리(Cloudflare 등), 그리고 웹 호스팅 업체를 각각 분리해서 사용하는 것이 좋습니다. 이번 사태처럼 호스팅사가 계정을 날려버려도, DNS와 도메인 소유권을 쥐고 있으면 다른 서버로 트래픽을 돌려 서비스 중단을 최소화할 수 있습니다.
둘째, 오프사이트 백업(Off-site Backup)은 선택이 아니라 필수입니다. 호스팅 서버 안에만 백업 파일이 있다면, 계정이 잠기는 순간 데이터도 함께 인질이 됩니다. AWS S3든, 하다못해 로컬 NAS든, 서비스 제공자와 물리적으로 분리된 공간에 소스 코드와 DB 덤프를 주기적으로 저장하는 파이프라인을 구축해야 합니다.
셋째, 기술 부채보다 무서운 게 계약 부채입니다. 외주 개발자나 프리랜서와 일할 때, 코드의 지적 재산권 양도와 관련된 계약서가 명확하지 않으면 언제든 DMCA 공격을 받을 수 있습니다. 개발자로서 우리는 클라이언트에게 "기능 구현"뿐만 아니라 이런 "운영 리스크"에 대해서도 미리 경고해 줄 수 있어야 합니다.
마지막으로, 협박에 돈으로 대응하지 마십시오. 기술적인 문제라면 돈(리소스 증설)으로 해결할 수 있지만, 악의적인 사람과의 문제는 시스템을 변경하여 원천 차단해야 합니다.
지금의 대기업 환경에서는 법무팀이 처리해 줄 일이지만, 야생에 있는 수많은 개발자분들은 스스로가 엔지니어이자 동시에 최후의 방어선이 되어야 합니다. 코드가 아무리 완벽해도, 그 코드가 돌아가는 땅(인프라)이 불안하면 서비스는 모래성입니다. 부디 여러분의 서비스는 이런 황당한 인질극에서 안전하기를 바랍니다.
