러시아 유머에 등장하는 라디오 예레반은 이렇게 답한다. 붉은 광장에서 차를 나눠준다는 게 사실이냐는 질문에, 모스크바가 아니라 상트페테르부르크에서, 붉은 광장이 아니라 혁명 광장에서, 차가 아니라 자전거를, 그것도 나눠주는 게 아니라 훔친다고. 한 macOS 개발자가 겪은 구글 애즈(Google Ads) 계정 정지 사연은 이 농담과 정확히 닮아 있다. 표면적으로 붙은 이유와 실제 벌어진 일 사이의 간극이 컸고, 무엇보다 정작 당사자에게는 그 간극을 좁힐 정보가 주어지지 않았다.
무엇이 정지되었나
문제의 소프트웨어는 RACE라는 이름의 macOS 네이티브 터미널 멀티플렉서다. Rust로 작성됐고, 여러 터미널을 균일한 격자에 욱여넣는 대신 자유롭게 배치·크기 조정할 수 있게 해준다. 큰 편집기 옆에 작은 셸을 두거나 빌드 로그를 펼쳐놓는 식이다. 멀티플렉서인 만큼 백그라운드에서 터미널 프로세스를 띄우고 관리하며, 애플리케이션을 재시작해도 셸 세션이 살아남는다. 배포 사이트 race-term.com은 Bridgetown으로 만든 정적 페이지이고, 서버 애플리케이션은 따로 없다. 광고 신청 시점 기준 외부 자바스크립트는 클라우드플레어 애널리틱스뿐이었으며, 구글 애널리틱스나 광고 추적기는 없었다. 배포 파일은 클라우드플레어 R2에서 서빙됐다.
개발자는 처음으로 광고를 집행해봤다. 캠페인을 세팅하고 500달러를 쓴 뒤, 구글은 '악성 소프트웨어(Malicious software)'와 '손상된 사이트(Compromised Site)'를 사유로 계정을 정지했다. 앱은 서명·공증(notarize)까지 마친 상태였고 웹사이트에는 별다른 공격 표면이 없었다.
설명 없는 거절의 반복
항고 과정 자체가 이 사연의 핵심이다. 개발자가 이의를 제기하자 구글은 이를 기각하며 '새로운 정보를 제출하라'고 했고, 제출할 게 없으면 계정을 삭제하라고 제안했으며 EU 구제 절차를 안내했다. 그러나 무엇이 악성인지, 어디가 손상됐는지, 제출한 근거가 왜 반박이 되지 못했는지는 끝내 알려주지 않았다. 항고 방법에 대한 안내는 있었지만, 정작 그 결정을 다툴 수 있게 해주는 설명은 없었다. 더 많은 정보를 붙여 다시 이의를 제기했으나 결과는 또 기각이었다.
개발자는 자기 나름으로 검증도 했다. 구글 세이프 브라우징은 race-term.com과 downloads.race-term.com 모두에 대해 '안전하지 않은 콘텐츠 없음'으로 표시됐고, 스크린샷상 상태는 2026년 9월 9일자로 갱신됐다. 서치 콘솔의 보안 문제 리포트도 두 도메인 모두 '문제 없음'이었다. 감염된 페이지도, 악성 다운로드도, 주입된 리소스도 목록에 없었다. 배포 파일을 직접 검사해도, 심지어 구글 자체 스캔조차 악성코드를 찾지 못했다. 다만 개발자 스스로 인정하듯 세이프 브라우징이나 서치 콘솔의 결과가 곧 구글 애즈의 판정 기준과 같다는 보장은 없다. 두 시스템이 동일한 잣대를 쓰는지조차 확인할 수 없기 때문이다.
오탐과 카프카식 구조
개발자가 세운 가장 유력한 가설은 오탐(false positive)이다. 터미널 멀티플렉서는 태생적으로 백그라운드 셸 프로세스를 띄우고 관리하는데, 이 서브프로세스 관리 동작이 보안 민감 소프트웨어의 행위와 외형적으로 닮을 수 있다는 것이다. RACE는 이 동작을 숨기지 않고 문서화하고 있으며, 세 가지 지속성(persistence) 백엔드를 제공한다. 자체 PTY 호스트, 외부 도구인 dtach, 그리고 지속성 없음이다. 앱은 다른 프로그램에 코드를 주입하거나 브라우저 동작을 바꾸거나 프로세스 활동을 은폐하지 않는다.
혹시 앱이 삭제된 뒤에도 남는 동작이 문제였을까 싶어, 개발자는 삭제 후 정리를 수행하는 1.0.39 버전을 급조해 제출하기도 했다. 그러나 이 방식은 UX 관점에서 좋지 않아 이후에는 사용자에게 정리 여부를 묻는 형태로 바뀌었고, 그마저도 정지 해제로 이어진다는 보장은 없었다. 어느 쪽이 옳은지 알 수 없는 채로 계정 정지 상태에서 광고 계정 삭제냐, 끝없는 항고냐, 아니면 EU 소송이냐를 저울질하는 전형적인 캐치-22에 갇힌 셈이다.
결말은 다소 허탈하다. 이 사연이 해커뉴스에서 주목받으면서 계정은 복구됐다. 그러나 무엇이 정지를 유발했는지에 대한 설명은 끝까지 없었다. 라디오 예레반은 적어도 정정 내용이라도 알려줬지만, 플랫폼은 그조차 하지 않았다.
한국 개발자에게 남는 함의
이 사례가 국내 실무자에게 던지는 메시지는 분명하다. 앱 서명·공증, 정적 사이트, 최소한의 서드파티 스크립트 같은 '모범 사례'를 모두 지켜도 자동화된 광고 심사는 정상 소프트웨어를 악성으로 분류할 수 있고, 결정적으로 그 근거를 제공하지 않는다는 점이다. 특히 백그라운드 프로세스 관리, 세션 지속성처럼 시스템에 밀착한 동작을 가진 개발자 도구는 보안 민감 소프트웨어와 행위 패턴이 겹쳐 오탐 위험이 상대적으로 높다. 자체 도구로 클린 판정을 받아둔다 해도 광고 심사 기준과 일치한다는 보장이 없으니 그 자체가 방어 논리로 온전히 작동하지 않는다. 유료 채널에 의존해 배포를 설계하기 전에, 심사 거부와 불투명한 항고 절차라는 리스크를 미리 비용으로 계산해두는 편이 현실적이다. 유럽에서는 EU 구제 절차라는 형식적 통로라도 안내되지만, 그것이 실질적 설명을 담보하지 못한다는 점 역시 이 사연이 남긴 씁쓸한 교훈이다.