X가 니터에 보낸 경고장, 무슨 일이 있었나
오픈소스 프로젝트를 운영하다 보면 언젠가 마주칠 수 있는 오픈소스 법적 리스크가, 최근 니터(Nitter) 사건으로 다시 수면 위로 떠올랐습니다. 8월 24일 저녁, X Corp이 오픈소스 트위터 대체 프론트엔드 니터와 미러 서비스 엑스캔슬(XCancel)에 중단 요구서(cease-and-desist)를 보냈습니다. 더 레지스터 보도에 따르면 요구서의 핵심 사유는 “X의 API와 관련 데이터를 불법적으로 이용하고 우회했다”는 것이었습니다.
두 서비스 모두 즉시 운영을 멈췄고, 니터의 깃허브 저장소는 다음 날인 8월 25일 아카이브(읽기 전용) 상태로 전환됐습니다. 저는 이 소식을 처음 들었을 때 “오픈소스 유지보수자 개인이 대형 플랫폼의 법적 압박을 받으면 실제로 뭘 할 수 있나”라는 생각이 먼저 들었습니다. 회사 뒤에 법무팀이 있는 것도 아니고, 대부분은 취미로 시작한 프로젝트니까요.
법적 조언 이후, 니터는 다시 살아났다
약 2주가 지난 9월 초, 니터 저장소 관리자는 커밋 하나로 저장소 아카이브를 해제했습니다. 메시지는 짧지만 분명했습니다.
Following legal advice, the Nitter project will continue. More details will be announced soon.
zedeus, Nitter 저장소 커밋 메시지 (2026년 9월)
실제 커밋 내용은 깃허브 커밋 기록에서 직접 확인할 수 있습니다. 다만 서비스 재개 시점이나 구체적 방식은 아직 공개되지 않았고, “곧 더 자세한 내용을 발표하겠다”는 문장이 전부입니다. 법적 조언을 받아 프로젝트 존속은 결정했지만, 실무적으로 무엇이 달라지는지는 지켜봐야 하는 상황인 셈이죠.
왜 오픈소스 스크래핑 도구는 법적으로 위태로운가
API 우회와 이용약관 위반의 경계
X의 공식 개발자 약관(Developer Agreement)은 인증 없이 자동화된 방식으로 서비스에 접근하거나 API 제한을 우회하는 행위를 명시적으로 금지합니다. 니터는 공식 API 대신 페이지를 직접 파싱해 트윗을 보여주는 방식으로 동작했는데, 이 지점이 이번 요구서의 핵심 근거가 됐습니다. 공개된 웹페이지를 보여주는 것과 API 계약을 우회하는 것은 서비스 제공자 입장에서 전혀 다른 문제로 취급된다는 점을 이번 사건이 다시 보여준 셈입니다.
아카이브냐 프록시냐, 법적 취급이 갈린다
개발자 커뮤니티 논의를 보면, 니터가 단순히 과거 트윗을 보관하는 정적 아카이브였다면 상황이 달랐을 거라는 의견이 많았습니다. 하지만 니터는 실시간으로 최신 트윗을 불러와 보여주는 살아있는 프록시·프론트엔드였고, 이 차이가 법적 리스크의 크기를 갈랐다는 분석입니다. 같은 “오픈소스 도구”라도 데이터를 정적으로 다루는지, 실시간으로 계속 끌어오는지에 따라 서비스 제공자가 느끼는 위협의 크기가 달라집니다.
사이드 프로젝트를 운영하는 개발자가 챙겨야 할 것
후배님이 지금 개인 프로젝트나 사이드 프로젝트로 어떤 플랫폼의 데이터를 가져오는 도구를 만들고 있다면, 이번 사건이 남 일처럼 느껴지지 않으실 거예요. 실제로 점검해볼 만한 지점들이 있습니다.
- 대상 서비스의 이용약관에 스크래핑·자동화 접근 금지 조항이 명시돼 있는지
- 인증 없이 우회하는 방식으로 데이터에 접근하는지, 아니면 공개된 정적 페이지만 읽는지
- 프로젝트가 정적 아카이브에 가까운지, 실시간으로 계속 데이터를 끌어오는 프록시에 가까운지
- 이용자가 늘어나 서비스 제공자 눈에 띌 만큼 트래픽 규모가 커졌는지
혼자 재미로 시작한 프로젝트라도, 사용자가 늘고 트래픽이 커지는 순간부터는 법적 리스크도 함께 커진다는 걸 이번 사건이 보여줍니다.
회사 업무에서도 벌어질 수 있는 일
제가 예전에 몸담았던 팀에서도 비슷한 고민을 한 적이 있습니다. 특정 벤더가 공식적으로 열어두지 않은 내부 API를 참고해 사내 대시보드에 데이터를 끌어오는 기능을 만들었는데, 이후 벤더가 이용약관을 개정하며 자동화된 접근을 금지 조항으로 명시했습니다. 법무팀 검토 없이는 그 기능을 그대로 유지할 수 없다는 결론이 났고, 결국 공식 계약된 API로 전면 교체하는 데 두 스프린트가 걸렸습니다.
이런 일은 스타트업일수록 더 자주 벌어집니다. 빠르게 기능을 붙이려다 보니 공식 채널이 아닌 우회 경로를 먼저 쓰고, 나중에야 법무 검토가 따라오는 순서가 되기 쉽거든요. 저는 이런 상황일수록 엔지니어가 먼저 “이 접근 방식이 상대 서비스의 이용약관과 충돌할 가능성이 있다”는 걸 팀에 알리는 역할을 해야 한다고 생각합니다. 법무팀은 코드를 안 보니까요.
판단 체크리스트: 내 프로젝트는 안전한가
아래 항목 중 두 개 이상에 해당한다면, 지금 한 번쯤 이용약관과 접근 방식을 다시 점검해볼 시점입니다.
- 공식 API가 아닌 방식으로 데이터를 가져오는 로직이 프로젝트 핵심에 있다
- 대상 서비스의 최신 이용약관을 마지막으로 읽은 게 언제인지 기억나지 않는다
- 사용자·트래픽이 늘고 있는데 법적 리스크는 따로 검토한 적이 없다
- 회사 업무라면, 법무팀에 이 접근 방식을 공유한 적이 없다
니터 사건의 결말은 아직 완전히 나지 않았습니다. 다만 법적 조언을 받고 나서야 다음 걸음을 정할 수 있었다는 사실 자체가, 오픈소스든 사내 프로젝트든 “일단 만들고 본다”는 접근이 갖는 한계를 보여줍니다. 후배님의 프로젝트가 크든 작든, 이용약관을 한 번 다시 읽어보시길 권합니다.
관련 글
이번 글과 함께 읽으면 좋은 시니어 개발자 관련 글들입니다.
- 크롬 제로데이 터졌다, 패치 속도로 시니어가 갈립니다 — 외부 위협에 팀이 얼마나 빠르게, 어떤 판단으로 대응하는지를 다룬 글입니다.
- Cerebras Qwen 3.8 초당 1500토큰, 시니어가 챙길 판단 기준 — 기술 변화 속에서 시니어가 무엇을 우선 판단해야 하는지 살펴봤습니다.
- AI 코딩 에이전트 경쟁, 시니어 개발자가 챙겨야 할 변화 — 도구가 빠르게 바뀌는 시기에 시니어가 놓치기 쉬운 지점을 다룹니다.
📌 함께 보시면 좋은 글
이직·퇴사·연봉 협상을 혼자 판단하기 어렵다면
1:1 개발자 커리어 상담 신청하기 →
※ 본 글은 AI(Claude)의 초안을 기반으로 편집자 검수를 거쳐 발행되었습니다. (한국 AI기본법 대응 고지)
이직·퇴사, 지금 움직여도 될지 헷갈리시나요?
막연히 불안한 건지, 정말 시점이 온 건지 판단이 어려울 때가 있습니다.
5분 체크리스트로 지금 상태를 먼저 정리해보세요.
결론을 대신 내리기보다, 스스로 판단할 기준을 잡는 데 도움을 드립니다.
아직 확신이 없다면, 지금이 ‘고민 단계’인지부터 먼저 점검해보세요