닫히는 담장과 '인터넷 전체를 SELECT'하려는 시도: atproto가 여는 열린 소셜웹

엑스(옛 트위터)가 니터(Nitter)에 법적 조치 중단 요구서를 보냈다. 니터는 로그인 없이 트윗을 볼 수 있게 해주던 단순한 프론트엔드였다. 공개된 게시물을 대신 보여주는 것뿐인 이 작은 프록시조차 법적 위협의 대상이 됐다는 사실은, 팀 버너스리가 2007년 에세이 '거대한 글로벌 그래프'에서 던진 개방형 웹에 대한 문제의식을 다시 떠올리게 한다.

니터의 궤적은 폐쇄가 어떻게 단계적으로 진행되는지를 압축해 보여준다. 처음에는 엑스의 API를 썼다. API가 닫히자 공개 웹페이지를 읽는 방식으로 바꿨다. 그리고 이제 더 닫을 것이 남지 않자, 요구는 소스코드 자체를 내리라는 것으로 옮겨갔다. 공개 게시물을 보여주는 프로그램이 컴퓨터 범죄 법령상의 '우회 장치'처럼 취급되는 상황이다.

개방에서 폐쇄로, 반복되는 각본

2007년 트위터의 API는 개방적이기로 유명했고, 그 덕에 수천 명의 개발자가 무료로 클라이언트와 분석 도구를 만들었다. 그런데 왜 닫혔을까. 원문의 진단은 단순하다. 네트워크가 이겼기 때문이다. 이용자 규모가 임계점을 넘자 개발자는 더 이상 자산이 아니었고, API는 점진적으로 조여졌다. 속도 제한, 유료 등급제, 로그인 요구, 우회로에 대한 기술적 차단, 그리고 마침내 변호사의 편지. 메타도 10여 년 전 같은 각본을 실행했고, 지금은 페이스북이나 인스타그램에 쓸 만한 API가 있었다는 사실조차 기억하기 어렵다. 인터넷 아카이브 설립자 브루스터 케일이 10년 넘게 '웹을 열린 상태로 잠가두자'고 외쳐온 이유다.

다만 저자가 강조하는 핵심은 API의 폐쇄성만이 문제가 아니라는 점이다. 설령 영구적이고 무료이며 넉넉한 속도 제한을 가진 API가 있더라도 충분하지 않다. 애플리케이션은 API가 제공할 수 있는 것보다 훨씬 의미 있는 접근을 필요로 한다.

API라는 '접수 창구'의 한계

저자는 웹을 각 회사가 서류 캐비닛을 하나씩 쥐고, 그 앞에 접수원을 세워둔 구조에 비유한다. 접수원은 당신이 이름을 댈 수 있는 파일을, 한 번에 하나씩, 자기가 내키는 속도로, 상사가 허락하는 동안만 읽어준다. 이 구조에서는 네 가지 근본적 제약이 생긴다. 첫째, 누군가 미리 답을 준비해 둔 질문만 던질 수 있다. API는 getPosts(user)나 getFollowers(user) 같은 고정된 메뉴여서, '내 팔로워가 팔로우하는 사람들의 게시물을 인용 빈도로 정렬'하는 식의 요구에는 해당 엔드포인트가 없고 앞으로도 없다. 둘째, 원하는 질문의 답도 잘못된 형태로 온다. 팔로워는 100개씩 나눠 오므로 200만 팔로워 계정 하나를 훑으려면 2만 번의 왕복이 필요하고, 점잖은 속도 제한 아래에서는 한 사용자에 대한 한 가지 질문에 몇 시간이 걸린다. 즉시성이 필요한 인터랙티브 서비스는 시작도 하기 전에 배제된다.

셋째, 서로 다른 '캐비닛'을 조인할 수 없다. 흥미로운 질문은 거의 항상 서비스 교차형이지만, 두 건물의 두 접수원은 서로를 대조하지 못한다. 넷째, 보유하지 않은 데이터는 색인할 수 없다. 검색, 랭킹, 추천, 피드, 모더레이션 도구는 모두 전체 말뭉치에 대한 색인 위에서 만들어지는데, 열쇠 구멍 너머로는 색인을 구축할 수 없다. 결국 제대로 된 서비스를 만들려면 데이터의 일부 view가 아니라 전체 데이터셋이, 폴링이 아니라 변경되는 즉시 도착하는 라이브 형태로, 내 제품이 원하는 방식으로 색인 가능하고, 쓰기까지 가능하며, 어느 회사의 분기 실적 우선순위로도 취소될 수 없게 보장되어야 한다.

데이터베이스를 공유한다는 발상

데스크톱 앱이 파일시스템을 공유하며 문제를 풀었다면, 인터넷 앱은 파일이 아니라 데이터베이스를 쓴다. 그래서 데이터베이스를 공유해야 한다는 것이 atproto의 출발점이다. 방법은 하나의 거대한 DB를 공유하는 것이 아니라, 여러 개인 데이터 서버(PDS)의 네트워크를 만들고 애플리케이션이 이들과 상호작용하게 하는 것이다. 복잡한 조회는 각 앱이 로그를 통해 데이터를 복제해 로컬에서 질의하도록 하고, 쓰기는 앱이 PDS로 보내면 PDS가 다시 다른 앱으로 복제해 내보낸다. atproto의 직관은 이 쓰기·수집 루프에 있다. 수집 데이터가 네트워크를 한 바퀴 돌아오길 기다리는 대신, PDS의 200 OK 응답을 트랜잭션 승인으로 삼아 앱 자체 DB를 먼저 갱신하는 '쇼트서킷'으로 응답성을 높일 수 있다.

이 관점은 계정 이전 문제에도 닿는다. 트윗 아카이브를 내려받는 것은 이전 수단으로는 쓸모가 없는데, 데이터가 고립된 채로는 살아있지 않기 때문이다. 다른 애플리케이션에서 추가 연산이 불가능한 데이터는 정적 아카이브일 뿐이다. 사용자 입장에서 정체성과 관계망은 처음 가입한 앱보다 오래 살아남아야 하며, 이는 데이터가 서비스를 벗어나서도 계속 조작 가능한 상태로 공유될 때만 가능하다.

중요한 것은 이 네트워크가 이미 실재하고 라이브로 공개되어 있다는 점이다. 저자에 따르면 블루스카이, 탱글드(Tangled), 리플릿(Leaflet) 등이 이미 이 방식으로 동작하며, 노트북 한 대에서 허락을 구하지 않고 전체 데이터를 읽을 수 있다. 새로운 제트스트림(jetstream) 서비스로 데이터에 접근하기가 한층 쉬워졌고, atproto 기반 블로그 글을 찾는다면 standard.site를 참고하라고 안내한다. 다만 원문은 개방형 소셜웹의 이상과 초기 도구 생태계를 소개하는 데 초점이 맞춰져 있어, 대규모 운영 시의 저장·연산 비용, 모더레이션 책임의 분산, 개방된 파이어호스가 초래할 수 있는 오남용 같은 현실적 트레이드오프는 이 글의 범위 밖에 있다. 담장이 계속 높아지는 흐름 자체는 바뀌지 않으리라는 전제 위에서, 처음부터 열린 구조로 다시 시작하자는 제안으로 읽는 편이 정확하다.