어느 날 팀원이 PR의 오타를 수정하려고 Copilot을 열었다. 결과물을 확인했더니 오타는 고쳐져 있었다. 그런데 PR 설명 하단에 낯선 문구가 붙어 있었다. Copilot 자신과 Raycast를 홍보하는 광고 문구였다. 본인도 모르게 자신의 PR이 광고판이 된 것이다. 이 사건은 Zach Manson의 블로그를 통해 알려졌고, Hacker News에서 수백 개의 댓글을 달며 빠르게 확산됐다.
처음에는 단순 해프닝처럼 보일 수 있다. GitHub의 Copilot Coding Agent 팀은 곧바로 "개발자들이 Copilot을 더 잘 활용하도록 돕기 위한 '팁'이었다"고 해명하며 해당 기능을 비활성화했다. 공식 대응은 빨랐고 표면적으로는 마무리됐다. 하지만 커뮤니티의 반응은 달랐다. "꺼줘서 다행이지만, 피드백이 없었으면 계속했겠다는 말 아닌가." 이 한 문장이 사건의 본질을 꿰뚫는다.
이 사건을 단순한 실수로 읽으면 안 된다. Cory Doctorow가 'TikTok의 Enshittification'에서 묘사한 플랫폼 변질의 공식과 너무나 닮아 있다. 사용자에게 유익한 서비스로 시작해, 비즈니스 파트너에게 유리하게 전환되고, 결국 사용자까지 착취하다 붕괴하는 구조. Copilot의 이번 광고 삽입은 그 두 번째 단계로의 전환 시도처럼 보인다. "팁이었다"는 해명은 언어의 완곡화이고, Hacker News 커뮤니티의 표현처럼 그 완곡화를 그대로 받아들이는 순간 enshittification은 가속된다.
더 불편한 지점은 따로 있다. 이 사건이 드러낸 건 광고 삽입 자체가 아니라, AI 에이전트가 사용자 동의 없이 콘텐츠를 수정할 수 있다는 구조적 사실이다. Hacker News의 한 댓글은 이렇게 지적한다. "Copilot이 PR에 광고를 넣을 정도라면, 코드베이스 안에도 무언가를 넣을 수 있다. 이건 시작 메뉴에 광고를 넣고 업데이트 때마다 다시 삽입하는 그 회사다." PR 설명은 코드가 아니라 커뮤니케이션이다. 그 공간을 오염시키는 것은 신뢰의 기반을 무너뜨리는 일이다.
흥미롭게도 같은 시기에 dev.to에는 정반대의 방향으로 신뢰를 설계하려는 시도가 등장했다. Domscribe라는 도구는 AI 에이전트가 프론트엔드 코드를 편집할 때 겪는 문제—토큰의 90%가 검색에 소비되고, 실제 편집에는 10%도 쓰이지 않는 구조—를 해결하기 위해 만들어졌다. 빌드 타임에 AST를 분석해 모든 DOM 요소에 결정론적 ID를 부여하고, 소스 파일과 렌더링된 요소를 직접 연결하는 매니페스트를 만드는 방식이다. AI 에이전트가 "이 버튼이 어느 파일 몇 번째 줄에서 왔는지"를 즉시 알 수 있게 한다.
두 사례는 같은 긴장축 위에 있다. AI 도구의 코드베이스 침범. Copilot은 그 침범을 사용자 몰래 단행했고, Domscribe는 그 침범을 명확하게 정의하고 제어 가능하게 만들려 했다. 전자는 신뢰를 깎아내렸고, 후자는 신뢰를 쌓으려 했다. 프로덕트 관점에서 보면 이 차이는 의도의 문제가 아니다. 설계 철학의 문제다. Domscribe의 제작자가 강조한 것처럼, 확장 가능한 어댑터 인터페이스를 만들어 Svelte나 Solid 같은 서드파티 커뮤니티도 동일한 공개 인터페이스로 참여할 수 있게 한 것—그것이 신뢰를 구조화하는 방식이다.
프론트엔드 개발자로서 이 사건에서 건져야 할 시사점은 명확하다. AI 코딩 도구를 평가할 때 기능의 강력함만 볼 게 아니라 그 도구가 내 콘텐츠와 코드베이스를 어떻게 다루는지를 봐야 한다. 동의 없이 PR 설명을 수정하는 도구는, 동의 없이 커밋 메시지를 바꾸거나 코드에 무언가를 심을 수도 있다는 신호다. Hacker News의 또 다른 댓글처럼 GitHub의 개인정보 정책이 조용히 바뀌어 AI 학습에 입출력 데이터를 활용할 수 있게 된 것도 같은 맥락이다. 설정 페이지에서 비활성화할 수 있다고는 하지만, 기본값이 '허용'이라는 사실은 무엇을 시사하는가.
한편, 이번 사건이 촉발한 또 하나의 논의는 AI가 작성한 코드와 사람이 작성한 코드를 어떻게 구분할 것인가다. 커뮤니티 일부는 Copilot의 co-author 표기나 Claude의 Co-Authored-By 라인을 긍정적으로 평가한다. 어떤 코드가 AI에 의해 생성됐는지 알 수 있는 것 자체가 투명성이고, 그 투명성이 리뷰의 품질을 높인다는 논리다. 반면 "코드 품질은 누가 썼든 상관없다"는 반론도 있다. 둘 다 맞는 말이지만 순서가 있다. 지금은 AI 코드의 신뢰가 아직 충분히 검증되지 않은 시기다. 먼저 투명성을 확보하고, 그 위에서 품질을 논하는 것이 맞다.
전망은 복잡하다. GitHub은 빠르게 기능을 껐고 공식 사과에 준하는 입장을 냈다. 단기적으로는 사건이 봉합됐다. 하지만 "다시는 하지 않겠다"는 약속을 그대로 믿기는 어렵다. MS가 Windows에서 수십 년간 광고와 팝업을 반복해온 역사를 가진 기업이라는 점, Copilot의 수익 모델이 결국 광고 또는 유료 플랜 전환에 의존할 수밖에 없다는 점을 감안하면 더욱 그렇다. SourceForge가 한때 오픈소스의 거점이었다가 광고와 번들웨어로 신뢰를 잃고 침몰한 것을 기억하는 개발자라면 이 불안을 공유할 것이다.
우리에게 필요한 것은 AI 도구에 대한 무조건적인 불신도, 맹목적인 신뢰도 아니다. 투명하게 설계된 도구를 선택하고, 그 도구가 내 콘텍스트와 콘텐츠를 어떻게 다루는지 지속적으로 감시하는 태도다. AI 에이전트가 코드베이스에 접근하는 범위와 방식을 명시적으로 정의하고, 그 경계를 넘는 순간 즉시 감지할 수 있는 구조를 갖추는 것—그것이 지금 프론트엔드 개발자에게 요구되는 신뢰 설계의 최소 조건이다. Copilot의 광고 삽입은 불쾌한 사건이었지만, 그 불쾌함이 우리에게 물어야 할 질문을 정확하게 가리켜 준다는 점에서는 유용했다.