지난 8월 24일, X(구 트위터)가 오픈소스 프로젝트 Nitter에 정지 명령서(cease-and-desist)를 보냈습니다. 7년간 운영되던 이 프로젝트는 편지 한 장으로 서비스를 멈췄고, 개발자 Zedeus는 “법률 자문을 구하는 중”이라는 말만 남겼습니다.
단순한 서비스 종료 소식처럼 보이지만, 이 사건은 사이드 프로젝트 법적 리스크가 한국 개발자와도 무관하지 않다는 신호입니다. 여러분이 퇴근 후 만들고 있는 사이드 프로젝트, 혹은 이력서에 자랑스럽게 올려둔 개인 프로젝트도 같은 리스크를 안고 있을 수 있거든요.
무슨 일이 있었나: 7년 프로젝트를 멈춘 한 장의 편지
Nitter는 로그인 없이 X 게시물을 읽을 수 있게 해주는 프론트엔드였습니다. 광고와 트래킹 스크립트를 제거하고 공개 게시물만 가져오는 구조였는데, X 측은 이를 “API의 불법적 사용과 우회”로 규정했습니다. TechCrunch 보도에 따르면 X 측 변호사는 텍사스주 컴퓨터 무단접근법과 랜험법(상표법) 위반까지 언급하며, 8월 25일 오후 5시(미 동부시간)까지 서비스 중단을 요구했습니다.
“2026년 8월 24일, X Corp.가 Nitter 인스턴스와 저장소의 영구 폐쇄를 요구하는 정지 명령서를 보냈습니다. nitter.net은 오프라인 상태이며 개발은 잠정 중단되었습니다.”
Nitter 프로젝트 공지 (TechCrunch 인용)
이번이 처음도 아닙니다. 2024년에도 X의 API 정책 변경으로 Nitter가 한 차례 멈춘 적이 있는데, 이번엔 기술이 아니라 법률로 승부를 건 셈입니다. 원문은 Nitter GitHub 이슈 #1442에서 확인할 수 있습니다.
오픈소스 사이드 프로젝트, 법적 리스크는 이미 숫자로 나타나고 있다
GitHub 2025 투명성 보고서에 따르면, 2025년 처리된 DMCA 삭제 통지는 2,661건이며 영향을 받은 저장소는 47,228개로 전년 대비 51.6% 늘었습니다. 같은 보고서 기준으로 우회(circumvention) 관련 신고도 645건으로 전년보다 41% 증가했습니다.
대부분은 대기업 저작권 대응팀이 포크(fork)된 저장소를 한꺼번에 신고하면서 생기는 숫자지만, 개인이 만든 사이드 프로젝트도 예외는 아닙니다. 특히 외부 API를 스크래핑하거나 우회해서 데이터를 가져오는 구조라면, 서비스 약관(ToS) 하나로 프로젝트 전체가 멈출 수 있습니다.
한국 개발자에게 사이드 프로젝트는 취미가 아니라 경력 자산이다
후배님도 이력서나 면접에서 “이런 사이드 프로젝트를 만들었습니다”라고 말한 경험이 있으실 거예요. 실제로 채용 담당자들은 GitHub 저장소나 개인 블로그 같은 실무 증빙 자료를 이력서 외 참고 자료로 요청하는 경우가 많습니다. 사이드 프로젝트가 곧 포트폴리오이자 커리어 자산이라는 뜻입니다.
그런데 그 프로젝트가 어느 날 법적 분쟁의 대상이 되어 저장소가 통째로 삭제된다면 어떨까요? 면접에서 보여줄 코드가 사라지는 건 물론이고, 개인정보나 계정 정보를 다뤘다면 법적 책임까지 떠안을 수 있습니다. 시니어로 갈수록 “재미로 만든 것”이라는 변명이 통하지 않는 이유입니다.
사이드 프로젝트를 시작하기 전 점검해야 할 것들
1. API·ToS 재확인
외부 서비스의 데이터를 가져오는 프로젝트라면 공식 API 정책과 서비스 약관을 먼저 읽어야 합니다. “스크래핑 금지”, “재배포 금지” 조항이 있다면, 그 서비스가 제공하는 정식 API로 대체할 수 있는지부터 확인하는 게 안전합니다.
2. 회사 겸업·부업 규정
사이드 프로젝트가 커져서 광고나 후원을 받는 단계로 가면, 재직 중인 회사의 겸업 규정과 충돌할 수 있습니다. 특히 회사 업무와 겹치는 도메인이라면 미리 인사팀이나 상급자와 상의하는 편이 나중에 분쟁을 줄여줘요.
3. 저작권과 라이선스 고지
오픈소스로 공개할 계획이라면 라이선스를 명확히 표기하고, 타인의 코드를 가져다 쓴 부분이 있다면 원본 라이선스를 지켜야 합니다. GitHub는 저장소 계정을 정지하기 전에 사안별로 검토하는 절차를 두고 있지만, 신고가 누적되면 결국 개인이 소명해야 하는 몫이 커집니다.
판단 체크리스트
- 이 프로젝트가 가져오는 데이터는 공식 API로 받고 있는가, 스크래핑에 의존하는가
- 대상 서비스의 ToS에 재배포·2차 이용 제한 조항이 있는가
- 회사 겸업 규정에 어긋나지 않는가, 상의가 필요한 영역인가
- 저장소가 삭제되어도 포트폴리오로서 손실이 크지 않도록 문서·스크린샷을 별도 보관했는가
넷 중 하나라도 애매하다면, 서비스를 키우기 전에 법률 자문이나 최소한 이용 약관 재검토부터 하는 게 안전합니다. Nitter처럼 7년 운영해온 프로젝트도 한 장의 편지로 멈출 수 있다는 걸 이번 사례가 보여줬으니까요.
관련 글
사이드 프로젝트로 무엇을 만들지 고민 중이라면, API 선택이 면접에서 어떻게 드러나는지 다룬 글도 참고해보세요.
- 사이드 프로젝트 API 선택, 채용 인터뷰에서 드러나는 이유 — 어떤 API를 선택하느냐가 면접 질문으로 이어지는 과정을 다룹니다.
- 스트라이프의 오픈라우터 인수, 개발자 커리어에 남긴 신호 — 플랫폼 정책 변화가 개발자 생태계에 미치는 영향을 다룬 글입니다.
- 개인용 AI 에이전트 확산, 개발자에게 필요한 건 프롬프트 실력만이 아닙니다 — 개인 프로젝트에 AI 에이전트를 붙일 때 고려할 점을 함께 읽어보세요.
📌 함께 보시면 좋은 글
이직·퇴사·연봉 협상을 혼자 판단하기 어렵다면
1:1 개발자 커리어 상담 신청하기 →
※ 본 글은 AI(Claude)의 초안을 기반으로 편집자 검수를 거쳐 발행되었습니다. (한국 AI기본법 대응 고지)
이직·퇴사, 지금 움직여도 될지 헷갈리시나요?
막연히 불안한 건지, 정말 시점이 온 건지 판단이 어려울 때가 있습니다.
5분 체크리스트로 지금 상태를 먼저 정리해보세요.
결론을 대신 내리기보다, 스스로 판단할 기준을 잡는 데 도움을 드립니다.
아직 확신이 없다면, 지금이 ‘고민 단계’인지부터 먼저 점검해보세요