최근 국내 개발자 커뮤니티에서 K-skill과 블루리본서베이를 둘러싼 논란이 커지고 있습니다.

K-skill은 한국에서 자주 사용하는 여러 서비스를 AI 에이전트가 이용할 수 있도록 연결한 오픈소스 프로젝트입니다. 현재 GitHub에서 6천 개가 넘는 스타를 받을 만큼 많은 관심을 모았습니다. 하지만 프로젝트에 포함됐던 블루리본 맛집 검색 기능이 유료 데이터를 외부에 다시 제공하고, 서비스의 자동화 접근 차단을 우회하려 했다는 지적이 나오면서 문제가 시작됐습니다.

개발자는 이후 관련 기능의 운영을 중단하고 저장소에서도 제외했으며, 현재 진행 중인 법적 절차에 대해서는 변호사의 도움을 받아 소명하겠다고 밝혔습니다.

아직 법원의 판단이나 블루리본 측의 공식 입장이 공개된 것은 아닙니다. 따라서 현재 단계에서 저작권 침해나 부정경쟁행위가 확정됐다고 단정해서는 안 됩니다. 하지만 공개 저장소에 남은 개발 기록만으로도 이번 사건이 왜 많은 사람에게 충격을 주었는지는 충분히 살펴볼 수 있습니다.

MIT 라이선스는 다른 회사의 데이터 사용 허가서가 아니다

K-skill 저장소의 기본 라이선스는 MIT이며, 프록시 서버 일부에는 AGPL이 적용됩니다. 여기서 가장 먼저 구분해야 할 것이 있습니다.

이 라이선스들은 K-skill에 작성된 코드의 복제·수정·배포 조건을 정합니다. 블루리본의 데이터, 유료 회원 계정, 서버 API, 브랜드를 사용할 권리까지 제공하지는 않습니다.

프로젝트에 MIT 라이선스를 붙였다고 해서 프로젝트가 접근하는 모든 외부 데이터까지 오픈소스가 되는 것은 아닙니다. 인터넷에서 브라우저로 볼 수 있다는 사실도 자유롭게 수집하고 재배포할 수 있다는 뜻은 아닙니다.

우리는 다음 네 가지를 자주 혼동합니다.

  • 공개적으로 접속 가능한 정보
  • 오픈데이터로 배포된 정보
  • 오픈소스 라이선스가 적용된 코드
  • 자동 수집과 재배포가 허용된 정보

이것들은 전혀 다른 개념입니다.

외부 서비스를 연결하는 프로그램을 만들 때는 코드 라이선스만 볼 것이 아니라 서비스 이용약관, 공식 API 정책, 데이터베이스 권리, 상표 사용, 개인정보, 자동화 접근 제한을 각각 확인해야 합니다.

논란이 커진 결정적인 이유

K-skill 저장소의 과거 코드에는 블루리본 프리미엄 계정의 세션 ID를 프록시 서버 환경변수로 보관하고, 이를 사용해 주변 맛집 데이터를 조회하는 구조가 남아 있습니다. 블루리본의 공식 안내에서도 주변 맛집 기능은 프리미엄 콘텐츠로 소개됐습니다.

더 큰 논란을 만든 것은 차단 이후의 대응입니다.

블루리본 서버가 자동화 요청에 403 응답을 반환하자, 프로젝트에는 일반 브라우저처럼 보이도록 자동화 흔적을 숨기는 기능이 추가됐습니다. 해당 PR 설명에는 navigator.webdriver 제거, 브라우저 정보 위장, 지문 변경 등 봇 탐지를 피하기 위한 방법이 구체적으로 적혀 있습니다.

단순히 공개 페이지를 읽어 본 것과, 서비스 운영자의 차단 의사를 인식한 뒤 그 차단을 기술적으로 우회하는 것은 전혀 다른 문제입니다.

법적 판단은 구체적인 이용약관, 데이터의 성격, 수집 범위와 반복성, 영업적 이용 여부 등을 종합해 내려져야 합니다. 그러나 개발 윤리의 관점에서는 403이나 계정 차단을 단순한 기술적 장애물로만 취급해서는 안 됩니다. 그것은 서비스 운영자가 자동화 접근을 원하지 않는다는 명확한 신호일 수 있습니다.

사람들의 반응이 갈린 이유

커뮤니티에서 확인한 반응은 크게 세 방향으로 나뉘었습니다.

첫 번째는 강한 비판입니다. 유료 데이터에 접근하기 위해 결제한 계정의 세션을 프록시로 공유하고, 차단 이후 우회 방법까지 병합한 것은 ‘좋은 의도의 오픈소스 실험’이라는 설명으로 넘어가기 어렵다는 반응입니다. 코드가 공개됐다는 사실과 외부 데이터의 사용 권한을 혼동했다는 지적도 많았습니다.

두 번째는 개발자 개인에 대한 과도한 공격을 우려하는 반응입니다. 개인적인 실험으로 시작한 프로젝트가 예상보다 빠르게 성장하는 과정에서 운영 기준을 갖추지 못한 실수일 수 있으며, 공개적인 조롱이나 신상 공격보다는 문제를 수정할 기회를 줘야 한다는 의견입니다.

세 번째는 이 사건을 한 개발자의 실수로만 볼 수 없다는 반응입니다. AI 에이전트가 실제 서비스에 접속하고 행동하는 시대에는 비슷한 문제가 계속 발생할 것이므로, 프로젝트 차원의 데이터 출처와 권한 검토 절차가 필요하다는 주장입니다.

저 역시 세 번째 관점에 가깝습니다. 개인에 대한 비난보다 중요한 것은 왜 이런 기능이 별다른 제동 없이 만들어지고 공개되고 확산될 수 있었는지를 살펴보는 일입니다.

바이브 코딩이 확대시킨 책임의 공백

이번 사건은 무분별한 바이브 코딩이 만들 수 있는 한 가지 폐해처럼 보입니다.

AI는 웹사이트의 숨겨진 요청 구조를 찾고, 비공식 API를 호출하는 코드를 만들고, 프록시 서버와 브라우저 자동화까지 연결하는 작업을 매우 빠르게 해줍니다. 과거라면 며칠이 걸렸을 기능이 몇 시간 만에 완성될 수 있습니다.

문제는 구현 속도만 빨라졌을 뿐 검토 속도는 빨라지지 않았다는 점입니다.

AI는 “이 코드를 만들 수 있는가”에는 쉽게 답하지만, “이 데이터를 사용할 권리가 있는가”, “서비스가 차단했는데 계속 접근해도 되는가”, “이 기능을 수천 명에게 배포했을 때 누가 책임지는가”까지 대신 판단해 주지 않습니다.

바이브 코딩 자체가 문제는 아닙니다. 사람이 직접 코드를 작성했어도 같은 일은 생길 수 있습니다. 그러나 AI는 한 명의 개발자가 감당할 수 있는 기능과 서비스의 범위를 급격히 넓힙니다. 그만큼 잘못된 판단도 빠르게 제품화되고 여러 사용자에게 확산됩니다.

코드 생성 비용이 낮아질수록 검토와 책임의 비용은 오히려 높아져야 합니다.

앞으로 프로젝트와 기업은 어떻게 움직일까

K-skill은 이미 저장소의 여러 기능을 대상으로 데이터 출처, 접근 방식, 이용약관, 상표 사용을 다시 검토하기 시작했습니다. 60개가 넘는 법적 검토 이슈가 등록된 것은 이번 문제가 블루리본 기능 하나에 그치지 않을 가능성을 프로젝트 측도 인식했다는 의미로 볼 수 있습니다.

앞으로 오픈소스 AI 에이전트 프로젝트에는 다음과 같은 기준이 필요해질 것입니다.

  • 기능마다 데이터 출처와 공식 API 여부를 명시한다.
  • 유료 계정이나 세션을 공용 프록시에서 재사용하지 않는다.
  • 공식 API가 없다면 자동 수집 허용 여부를 먼저 확인한다.
  • 401·403·캡차·기기 차단을 우회 대상으로 취급하지 않는다.
  • 라이선스뿐 아니라 이용약관과 데이터 권리 검토 결과를 남긴다.
  • 문제가 생기면 즉시 중단할 수 있는 기능별 종료 장치를 둔다.
  • 외부 서비스의 이름과 로고를 사용할 때 공식 제휴로 오인되지 않게 한다.

기업들의 대응도 강화될 가능성이 높습니다. 자동화 요청에 대한 속도 제한과 봇 차단, 계정과 기기 단위 제한, 비공식 API 변경이 늘어날 수 있습니다. 이용약관에 AI 에이전트, 크롤링, 데이터 재판매에 관한 조건을 더 명확히 넣는 기업도 많아질 것입니다.

반대로 모든 자동화를 막는 것만이 좋은 해결책은 아닙니다. AI 에이전트가 새로운 사용자 인터페이스로 자리 잡는다면, 기업들도 제한된 공식 API와 제휴 프로그램을 제공하는 방향을 검토해야 합니다. 데이터 사용 범위와 호출량, 표시 방법, 수익 배분을 계약으로 정할 수 있기 때문입니다.

오픈소스의 자유는 타인의 권리를 지우지 않는다

오픈소스는 코드를 자유롭게 공유하고 함께 발전시키기 위한 약속입니다. 다른 회사가 시간과 비용을 들여 만든 데이터까지 자유롭게 가져다 쓸 수 있다는 선언이 아닙니다.

이번 사건에서 우리가 배워야 할 것은 “크롤링은 무조건 불법이다”라는 단순한 결론도, “인터넷에 공개됐으니 써도 된다”는 낙관도 아닙니다.

AI가 코드를 작성해 주는 시대일수록 개발자의 역할은 줄어들지 않습니다. 오히려 무엇을 만들지, 어디까지 연결할지, 언제 멈출지를 판단하는 책임은 더 커집니다.

이번 논란이 한 개발자를 공격하고 잊히는 사건으로 끝나지 않았으면 합니다. 국내 오픈소스와 AI 개발 문화가 코드 라이선스를 넘어 데이터 출처와 서비스 권한까지 함께 검토하는 계기가 되어야 합니다.