미투데이 사건과 매쉬업의 취약점

다음 주 강의 자료를 찾다 지난 9월에 있었던 미투데이 사건을 보게 되었다. 발 빠른 대응으로 대략 마무리 된 듯 하며 몇 주 전엔 미투데이의 운영자가 2백여 명의 사건 피해 사용자를 초대하여 식사 대접을 하겠다고 메일을 보낸 것 같다. 몇 달 전 이야기를 다시 언급하는 것은 매쉬업(mash-up)의 취약점에 대해 보다 구체적으로 언급하기 위함이다.


웹 2.0 신드롬에 대해 경고하며 여러 강의에서 매쉬업의 취약점에 주의할 것은 이야기한 바 있다. 이것을 "사무실에서 멀티탭을 사용하지 말아야 하는 이유"로 비유하곤 했다.

오래 전 사무실엔 컴퓨터가 10대 정도 있었는데 각 책상 아래로 멀티탭이 있었고 그 멀티 탭은 주 전원으로 연결되어 있었다. 문제는 주 전원이 하나라는 점이었다. 책상 아래로 발을 잘못 놀려서 멀티탭을 밟아 작업 중이던 컴퓨터 전원이 꺼지는 일은 가끔 있었는데 어느 날 대형 사고가 터졌다. 아주 급한 프로젝트를 진행하던 중이었는데 에어컨이 고장난 것이다. 급히 수리 기사를 불러 놓고 다시 작업에 몰두하고 있었는데 갑자기 컴퓨터 모니터가 꺼져 버렸다. 곧이어 사무실 전체에서 분노에 휩싸인 비명이 들려왔다. 사무실 컴퓨터 전원이 모두 나가 버린 것이다. 형광등이 들어와 있는 걸 보니 정전은 아니었다. 몇 초 지나지 않아 우리는 에어컨 옆에서 멍하게 서 있는 수리 기사를 볼 수 있었다, "이게 아닌가 보네..."


Open API로 제공되는 기능 혹은 콘텐츠를 매쉬업 하는 것은 매우 유용할 때가 많다. 혹은 자금 사정이나 개발 역량 문제, 비즈니스 제휴 등의 이유로 타사의 서비스를 직접 사용할 필요가 있는 경우도 많다. 그러나 멀티탭의 문제를 고려하지 않으면 미투데이 사건과 같은 일은 언제든 발생할 수 있다. 때문에 매쉬업은 다음과 같은 전제 조건 하에 적용하는 것이 바람직하다.

1. 자신이 제공하는 유일한 기능에 적용하지 않는다.
2. 독립적으로 동작하도록 적용한다.
3. 매쉬업으로 인한 생산물은 로컬 서버에 저장한다.
4. 일정한 수준의 성과가 생긴다면 비즈니스 계약을 통해 법적 보호를 받는다.


미투데이 사건 발생 시 운영자의 응대 태도에 대한 칭찬이 많았다. 개별적으로 사과를 하고 회사 명의가 아닌 개인 명의로 사과하며 상세한 경과를 설명한 것은 바람직하다. 그러나 달리 생각하면 그렇게 하는 것이 최선이었다. 왜냐면 미투데이 사건의 경우 민사 소송으로 갈 가능성이 충분히 있었고, 운영 사의 과실이 분명해 보이기 때문이다. 사건의 중요도에 비해 비교적 쉽게 넘어갈 수 있었던 것은 미투데이 사용자들이 서비스 운영사에 호의적이었던 것도 하나의 이유가 될 수 있다. 악질적(?) 사용자가 있었다면 그리 쉽게 넘어갈 수 있는 문제는 아니었다.


** 추가함 : 댓글을 통해 "플리커는 왜 미투데이 사진을 지웠나"라는 글을 읽을 수 있었다. 이 글은 미투데이 사건에 대해 비즈니스 측면에서 분석한 것인데, 내가 쓴 글에서 4번째 조건인 "4. 일정 수준의 성과가 생긴다면 비즈니스 계약을 통해 법적 보호를 받는다"라는 내용과 일치한다. 서비스의 최초 시작 단계에서는 꼼수를 사용하여 비용을 줄일 수도 있다. 그러나 서비스가 안정화 단계에 접어 들거나 기대 수준의 트래픽(사용자를 포함하여)이 발생한다면 즉각 공식적 계약 관계를 만들어야 한다. 웹 2.0이 '공짜로 내 자원을 사용하십시오'라고 말하는 건 결코 아니기 때문이다.

예를 들어 네이버의 Open API 사용 약관을 보면 일 쿼리 제한이 있다. 그러나 실제로 일 쿼리 제한을 넘어도 특별한 제재를 가하지 않는다. 그러나 어떤 새로운 웹 사이트가 네이버 Opne API를 이용하여 일 쿼리 제한의 수 백 배에 달하는 성과를 낸다면 어떤 일이 벌어질까? 그 웹 사이트가 돈을 벌든 그렇지 않든 네이버가 그런 상태를 수수방관하지는 않을 것이다. Open API를 통해 무료로 사용할 수 있는 기준을 매쉬업을 구현하는 사용자가 임의로 판단해서는 안된다는 말이다.