작은 서비스가 오픈스트리트맵에 데이터를 되돌려주지 않기로 한 이유

오픈소스 지도 프로젝트 오픈스트리트맵(OSM)은 전 세계 공공 시설 정보를 자발적 기여로 채워온 공유 데이터베이스다. 작은 무료 도서 교환함(little free library)을 찾아주는 서비스 '북 코너스(Book Corners)'도 초기 데이터의 상당 부분을 OSM에서 가져왔다. 이미 수천 개의 공공 책장이 지도에 표시되어 있었기 때문에, 이 데이터는 신생 서비스에 유용한 출발점이 됐다. 개발자는 여기서 자연스러운 후속 아이디어를 떠올렸다. 사용자가 직접 등록한 새 도서함 중 OSM에 없는 것을 다시 OSM으로 기여(write-back)하면 공정하지 않겠느냐는 것이다. 그러나 실제 구현을 검토한 끝에, 그는 이 기능을 무기한 보류하기로 결정했다. 이 사례는 외부 연동이 단순한 기술 문제가 아니라는 점을 보여준다.

코드보다 무거운 운영 계약

애초 구상은 무분별한 자동 동기화가 아니었다. 사용자 동의를 받고, 기여 상태를 추적하고, 미리보기를 만들고, OSM에 인증한 뒤 API로 새 객체를 생성하는, 관리자가 개별 항목을 검토하는 신중한 흐름이었다. 소프트웨어 관점에서는 충분히 다룰 만한 통합으로 보였다. 문제는 실제 구현을 파고들면서 드러났다. API에 데이터를 쓰는 일은 전체 작업의 작은 일부에 불과했다.

핵심은 OSM 커뮤니티가 이런 기여를 어떻게 규정하느냐에 있었다. 정보가 북 코너스 데이터베이스에서 나오기 때문에 OSM은 이를 외부 데이터의 '임포트(import)'로 간주할 수 있다. 또한 소프트웨어가 변경을 준비하고 제출하기 때문에, 관리자가 각 항목을 일일이 검토하더라도 '스크립트 보조 편집' 또는 '자동 편집' 규정의 적용을 받을 수 있다. OSM의 임포트 가이드라인과 자동 편집 행동 강령을 보수적으로 해석하면, 전용 계정과 OAuth 토큰만으로는 부족했다. 첫 실제 기여 전에 문서화된 절차, 라이선스 검토, 중복 처리 방안, 책임 있는 운영자, 커뮤니티 논의 같은 준비가 필요했다.

라이선스와 지속적 책임

라이선스 문제도 중요했다. 사용자가 자신의 도서함 정보를 OSM에 보내도 좋다고 허락한 것이, 그 사실 정보를 OSM과 호환되는 조건으로 공개할 충분한 권리를 가졌다는 뜻은 아니다. 따라서 사용자에게 보여줄 설명과 동의 절차에는 이 구분을 담아야 하고, 해당 정보가 OSM과 호환되지 않는 출처에서 복사된 것이 아님을 확인하는 과정까지 포함해야 한다. 게다가 이런 요건들은 한 번 양식을 채우고 끝나는 일이 아니다. 계정 관리, 문서화된 절차, 커뮤니티 피드백 대응, 실패와 잠재적 되돌림(reversion)에 대한 지속적 책임을 만들어낸다.

OSM이 이토록 까다로운 것은 그럴 만한 이유가 있다. 잘못된 임포트 하나가 수천 개의 중복을 만들거나, 현지의 더 정확한 지식을 덮어쓰거나, 다른 사람이 이미 편집한 객체에 제거하기 어려운 오류를 남길 수 있다. 문서화·라이선스 명확화·중복 처리·책임 운영자·커뮤니티 논의를 요구하는 것은 공유 지도의 품질을 지키기 위한 합리적 장치다. 선의가 곧 좋은 데이터를 보장하지는 않기 때문이다. 북 코너스 자신이 그 데이터 품질의 수혜자였던 만큼, 안전장치 없이 외부 서비스의 변경을 받아들이라고 기대하는 것은 앞뒤가 맞지 않는다.

소규모 프로젝트의 기회비용

문제는 이 절차에 실질적 비용이 따른다는 점이다. 이는 작은 프로젝트에게 단순한 API 클라이언트를 넘어, 문서화된 임포트 프로그램의 운영자가 되기를 요구한다. 대규모 데이터셋을 옮기는 조직에게는 적절할 수 있지만, 신중히 검토된 몇 개의 공공 책장을 공유 자산에 돌려주려는 저빈도 기능에는 상당한 부담이다. 자격 증명, 운영 안전장치, 감사와 대조 코드, 커뮤니티 절차, 라이선스 작업, 장기 지원 의무가 더해진다. 각 요소는 개별적으로는 정당하지만, 합쳐지면 애초 의도보다 훨씬 큰 기능이 된다.

기회비용도 있다. 이 통합을 운영하는 데 쓰는 시간은 도서관 검색 개선, 검수, 사진, 접근성, 번역, 모바일 경험 향상에 쓰지 못하는 시간이다. 후자의 개선들은 사용자에게 직접 도움이 되고 작은 프로젝트가 감당하기도 훨씬 쉽다. 결국 개발자는 write-back 구현을 무기한 보류하기로 했다. 다만 OSM에서 가져온 기록은 계속 출처를 명시하고, OSM에서 임포트한 도서함을 마치 새 항목인 것처럼 다시 제출하는 일은 없도록 하며, 북 코너스에 직접 등록된 도서함은 북 코너스에만 남긴다. 현재 운영 중인 연동이 없으므로 보류에는 기존 시스템의 비활성화나 이전이 필요치 않다.

이 결정이 영구적인 것은 아니다. 진정으로 가벼운 워크플로가 등장하거나, 북 코너스 기여의 규모와 가치가 절차를 정당화할 만큼 커지면 재고할 여지가 있다. 사용자가 기존 OSM 편집기에서 제안된 항목을 직접 여는 방식도 대안이 될 수 있지만, 이 역시 규칙을 우회하는 수단이 아니라 커뮤니티와 논의할 문제다. 이번 경험이 남긴 교훈은 명확하다. 구현 판단은 순전히 기술적인 문제처럼 보이기 쉽지만, 외부 연동에는 조직적·사회적 계약이 따르며 때로 그 계약이 코드보다 비싸다는 점이다. 그 사실을 배포 전에 발견한 것만으로도 의미가 있다.