CLI 도구가 기본으로 백그라운드 데몬을 설치하면 안 되는 이유

개발자가 AI 코딩 어시스턴트를 써보려고 npm install -g @openai/codex를 실행했다가, 요청한 적 없는 지속적이고 스스로 업데이트되는 백그라운드 데몬을 떠안게 됩니다. 최근 OpenAI Codex CLI 사용자들이 이 도구가 백그라운드 프로세스를 자동으로 시작하고, ~/.codex에 pid 파일과 lock 파일을 쓰며, 오래된 바이너리 버전을 디스크에 보관하고(한 사용자는 약 12GB라고 보고), 묻지도 않고 스스로 업데이트한다는 사실을 발견하면서 문제가 커졌습니다. 이건 한 회사의 버그 이야기가 아닙니다. 개발자 도구가 수십 년간 기대어 온 신뢰 모델이 얼마나 조용히 버려지고 있는지에 관한 이야기입니다.

저는 수년간 인프라 운영과 장애 대응 일을 해왔고, 여기서 보이는 패턴은 광고 소프트웨어, 침해된 빌드 에이전트, 하드웨어 업체가 배포한 '도움 되는' 업데이터 서비스에서 이미 본 것입니다. 그래서 이 설계를 옹호하는 흔한 논리를 하나씩 검증해 보려고 합니다. 실제 운영 환경에서는 대부분 버티지 못하거든요.

오해 1: “그냥 업데이터일 뿐입니다. 브라우저도 똑같이 하잖아요”

가장 흔한 옹호 논리이고, 언뜻 합리적으로 들립니다. Chrome과 Firefox도 끊임없이 스스로 업데이트하고, VS Code와 Slack도 마찬가지입니다. 그럼 CLI 하네스라고 안 될 이유가 있나요?

신뢰의 맥락이 완전히 다르기 때문입니다. 브라우저는 첫 실행 경험, 눈에 보이는 설정 페이지, 서명된 설치 파일, 그리고 가장 중요하게는 10년 넘게 강화되고 감사받아 온 업데이트 채널을 갖춘 GUI 애플리케이션입니다. Chrome 업데이터는 세상에서 가장 많이 공격받는 소프트웨어 중 하나이고, 구글은 그것을 안전하게 유지하기 위해 팀을 둡니다. Chrome을 설치할 때 업데이트는 사용자가 눈에 보이게 동의한 계약의 일부입니다.

npm으로 설치한 CLI는 다른 묵시적 계약을 갖습니다. 개발자는 호출될 때 실행되고 끝나면 멈출 것이라고 기대합니다. 이 기대는 향수가 아니라 시스템을 떠받치는 기둥입니다. CI 파이프라인, 컨테이너, 공유 빌드 서버, 보안 검토는 모두 npm i -g some-tool이 요청 시 실행되는 바이너리를 준다고 가정합니다. 로그아웃 후에도 살아남고, 스스로 다시 뜨고, 자기 바이너리를 바꿔치기하는 백그라운드 데몬은 이 가정을 전부 깨뜨립니다. 실제로 저는 “설명되지 않는 프로세스가 왜 있는 거지?”라는 질문 하나가 평범한 알림을 세 시간짜리 포렌식 작업으로 바꿔 놓은 장애 대응 콜에 참여한 적이 있습니다. 설명되지 않는 지속성은 증명되기 전까지 침해와 구별할 수 없습니다.

피해 범위(blast radius)에서도 실질적인 차이가 있습니다. 브라우저는 웹 페이지를 샌드박스에서 렌더링합니다. AI 코딩 하네스는 셸 명령을 실행하고, 소스 트리를 읽고, 종종 환경 변수에 API 키와 클라우드 자격 증명을 들고 있습니다. 그런 도구에 자기 수정이 가능하고 항상 켜져 있는 구성 요소를 붙이는 것은 브라우저 업데이트와는 질적으로 훨씬 큰 위험입니다.

오해 2: “사용자가 설정 플래그로 끄면 되잖아요”

기술적으로는 맞지만 실질적으로는 의미가 없습니다. 실제로 기능 플래그는 있습니다:

# ~/.codex/config.toml
[features]
daemon_auto_start = false

문제는 사용자가 찾아보려 할 때 이것이 문서화되어 있지 않았다는 점입니다. 아무도 모르는 옵트아웃은 동의가 아니라 함정입니다. 그리고 커뮤니티가 세운 대안을 보세요. pid 파일과 lock 파일을 지우고, /dev/null로 심볼릭 링크를 걸고, chattr +i로 불변 속성을 줘서, 플래그가 사라지면 데몬이 시작 시 크래시되도록 만드는 것입니다. 사용자가 소프트웨어로부터 자신을 지키기 위해 자기 홈 디렉터리에 덫을 놓고 있다면, 그것은 설정 시스템을 만든 게 아닙니다. 적대적인 관계를 만든 것입니다.

이 역학은 전에 피트니스 앱의 위치 데이터 유출을 다룰 때도 이야기한 적이 있습니다. 패턴은 언제나 같습니다. 기능은 기본 켜짐으로 배포되고, 토글은 숨겨지거나 문서화되지 않으며, 경계의 부담은 사용자에게 떨어집니다. 기본값은 곧 정책입니다. 지속성을 설치하는 기본값은 그 소프트웨어가 실제로 누구를 위해 일하는지에 대한 선언입니다.

해결책은 아주 쉽고 예전부터 쉬웠습니다. 처음 실행할 때 한 번 물어보면 됩니다. Codex runs a background service to keep itself updated. Enable it? [y/N] 같은 식으로요. apt, Homebrew, 대부분의 리눅스 데몬은 수십 년 동안 명시적 활성화를 기반으로 동작해 왔습니다. systemctl enable이 존재하는 이유도 부팅 시 무언가를 시작하는 일이 의도적인 행위여야 하기 때문입니다.

오해 3: “빠르게 움직이려면 조용한 자동 업데이트가 필요합니다”

이 주장에도 일리가 있고, 좋게 해석해 보고 싶습니다. AI 하네스는 실제로 빠르게 움직입니다. 3주 전 버전의 CLI는 바뀐 API와 맞지 않아 오작동할 수 있고, 현장에 퍼진 버그 있는 클라이언트는 실제 지원 부담이 됩니다. 한 리걸테크 IDE 팀은 데몬을 고려했다가, 대신 실행할 때마다 엄격하게 업데이트를 확인하는 방식을 택했다고 설명했습니다. 앱이 오래됐으면 알려주고 시작할 때 업데이트하며, 마음에 들지 않으면 실행을 멈추면 됩니다. 이것도 정당한 설계입니다.

하지만 “업데이트가 필요하다”는 것이 “당신이 보지 않는 동안 스스로 업데이트하는 지속적 데몬이 필요하다”는 뜻은 아닙니다. 그 사이에는 넓은 중간 지대가 있습니다:

• 실행 시 확인. CLI가 시작될 때 버전을 비교하고 알림을 띄운 뒤, 다음 실행 때 업데이트합니다. Homebrew, gh, 그 밖의 수많은 도구가 이렇게 합니다.
• 패키지 매니저를 통해 업데이트. npm으로 설치했다면 npm으로 업데이트하세요. 사용자는 이미 이해하고, 고정(pin)하고, 감사하고, 잠글 수 있는 메커니즘을 갖고 있습니다.
• 옵트인 데몬, 기본은 꺼짐. 마찰 없는 최신 상태를 원하는 사용자에게는 문서화된 선택지로 데몬을 제공하세요.
• 오래된 버전 정리. 사용자 디스크를 12GB 먹을 때까지 이전 바이너리를 모두 보관하는 것은 업데이트 전략이 아니라 누수입니다.

팀이 조용한 자기 업데이터에 손을 뻗는 진짜 이유는 속도가 아니라 통제입니다. 패키지 매니저 업데이트는 사용자의 lockfile, 미러, 승인 워크플로를 존중합니다. 자기 업데이터는 이 모든 것을 우회합니다. 벤더가 자기 업데이트 경로를 고집한다면, 여러분의 변경 관리보다 자신들의 배포 파이프라인을 더 중요하게 여긴다는 뜻입니다. 이미 로깅 사각지대가 있는 기업에서는 이런 방식이 검토되지 않은 코드가 개발자 자격 증명 아래에서 실행되는 결과로 이어집니다.

오해 4: “오픈소스니까 코드를 읽으면 되잖아요”

오픈소스는 도움이 되지만 실제 문제, 즉 검토한 것과 실행 중인 것 사이의 차이(drift)는 해결하지 못합니다. 자기 업데이트 데몬의 핵심은 지금 내 머신에 있는 바이너리가 설치했던 바이너리가 아니라는 점입니다. 0.157.0 버전의 소스를 읽어도 다음 화요일에 내려받을 빌드에 대해서는 아무것도 알려주지 않습니다. 모든 조용한 업데이트마다 서명과 재현 가능한 빌드를 검증하지 않는 한(그리고 실제로 그렇게 하는 사람은 없습니다), “오픈소스니까”는 위안거리에 불과합니다.

두 번째이자 더 미묘한 문제는 상태와 설정이 얽혀 있다는 점입니다. Codex를 선언적으로 관리하려던 한 사용자는 nix-darwin에서 실패했다고 설명했습니다. 도구가 같은 디렉터리에서 설정과 변경 가능한 런타임 상태를 섞어 놓았기 때문입니다. 그러면 무엇이 바뀌었는지 고정하고, 비교하고, 감사하는 것이 불가능해집니다. 좋은 유닉스 도구들은 이걸 오래전부터 알고 있었습니다. 설정은 ~/.config, 상태는 ~/.local/state, 캐시는 ~/.cache에 두고, 도구가 자기 설정을 변형하지 않게 합니다. 감사 가능한 경로가 왜 중요한지 이해하고 싶다면, 명세와 구현 사이의 간극이 바로 이런 놀라움이 숨어 있는 곳입니다.

지금 내 머신에서 실제로 무엇이 실행 중인지 확인하고 싶다면 30초면 됩니다:

# What AI-tool daemons are alive right now?
ps auxww | grep -Ei 'codex|claude' | grep -v grep
# What's been accumulating on disk?
du -sh ~/.codex ~/.local/share/claude 2>/dev/null
# What launchd/systemd units did tools register?
ls ~/Library/LaunchAgents 2>/dev/null   # macOS
systemctl --user list-units --type=service | grep -Ei 'codex|claude'  # Linux

조직 내 개발자 노트북 몇 대에서 이걸 돌려 보세요. 최소 한 명은 결과에 놀랄 것이라고 장담합니다.

오해 5: “다들 그렇게 하니까 괜찮겠지”

Claude Code도 이전 바이너리 버전을 보관하고 백그라운드 작업을 실행하며, 같은 토론의 사용자들이 이를 확인했습니다. 그러니 이것은 한 벤더의 실수가 아니라 업계의 패턴입니다. 하지만 “다들 그렇게 한다”는 보안 논리가 된 적은 없습니다. 나쁜 관행이 굳어지는 방식일 뿐입니다. 최근 몇 년간의 공급망 사고가 가르쳐 준 것은, 대부분의 조직에서 개발자 머신이 가장 약한 고가치 표적이라는 사실입니다. 그곳에는 클라우드 자격 증명, 서명 키, 푸시 권한이 있고, 그 권한으로 놀라울 만큼 많은 감사되지 않은 코드가 실행됩니다.

그 머신에 추가하는 지속적이고, 네트워크에 연결되어 있고, 자기 수정이 가능한 구성 요소는 가장 민감한 자격 증명을 겨냥한 공격 표면입니다. 인기 있는 개발 도구의 업데이트 채널이 침해되면 악몽 같은 시나리오가 됩니다. 업데이트 메커니즘이 묵시적으로 신뢰되기 때문입니다. 벤더들이 조용한 데몬을 정상화할수록, 각각의 데몬은 공격 대상으로서 더 가치 있어집니다.

그리고 품질 기준도 중요합니다. 사용자들은 Codex 데몬이 자동 업데이트 중 권한을 망가뜨렸다고 보고했습니다. .git 디렉터리가 읽기 전용이 되어 작업 중인 저장소가 멈춰 버린 것입니다. 버그 있는 데몬은 가만히 있지 않고, 여러분이 의식적으로 부여한 적 없는 권한으로 적극적으로 무언가를 망가뜨립니다. “다들 그렇게 한다”에 “버그가 있다”가 더해지면 그것은 안심이 아닙니다. 예보입니다.

동의를 존중하는 업데이트 메커니즘의 모습

이것은 이미 해결된 문제입니다. 새로운 기술이 필요한 게 아니라, 벤더들이 지루하지만 올바른 답을 선택하면 됩니다. 오늘날 출시되는 어떤 AI CLI든 요구사항 문서를 쓴다면 이런 모습일 것입니다:

1. 기본적으로 지속성 없음. 도구는 호출될 때 실행되고 끝나면 종료합니다. 모든 백그라운드 구성 요소는 옵트인이며, 첫 실행 때 명시적으로 요청해야 합니다.
2. 문서화되고 안정적인 킬 스위치. 문서화되고, 테스트되며, 조용히 사라지지 않는 설정 플래그와 환경 변수(예: CODEX_NO_DAEMON=1).
3. 설치 채널을 통한 업데이트. npm으로 설치한 도구는 npm으로 업데이트합니다. 호출 시 알리고, 사용자 몰래 자기 바이너리를 바꾸지 마세요.
4. 변경 로그가 있는 서명되고 버전 관리되는 릴리스. 업데이터를 배포한다면 아티팩트에 서명하고, 사용자가 버전을 고정하고 무엇이 바뀌었는지 감사할 수 있게 하세요.
5. 제한된 디스크 사용량과 깔끔한 상태 분리. 이전 버전은 최대 하나만 보관하고, 설정과 상태를 분리하며, XDG 관례를 따르세요.
6. 배포판 모델을 존중하기. 한 댓글 작성자의 말처럼, 배포판 패키징은 메인테이너가 소프트웨어를 테스트하고 사용자에게 도달하기 전에 잡다한 꼼수를 걷어내도록 존재합니다. 그것에 맞서지 말고 거기에 배포하세요.

이 중 어떤 것도 빠르게 움직이는 팀의 속도를 의미 있게 늦추지 않습니다. 동의를 상호작용의 맨 앞으로 옮길 뿐이고, 원래 그 자리가 맞습니다.

결론

불편한 진실은, AI 코딩 도구가 셸 접근, 여러분의 자격 증명, 전체 소스 트리까지 요구하면서, 2008년형 광고 소프트웨어의 업데이트 위생 수준을 채택하고 있다는 점입니다. 이 두 가지는 안전하게 공존할 수 없습니다. 기본값으로 지속적이고 자가 업데이트되는 데몬을 설치하는 CLI는 여러분을 대신해 결정을 내린 것이며, 그 결정은 벤더의 편의가 여러분이 자신의 머신을 통제하는 것보다 중요하다는 것입니다.

이에 반박하세요. 설정 플래그를 켜고, 머신을 감사하고, 이슈를 올리고, 기본값이 사용자를 존중하는 도구를 선택하세요. 잠긴 플랫폼 대신 사이드로딩의 자유를 찾는 것과 같은 본능이 여기에도 적용됩니다. 오늘 개발자 노트북에서 무인으로 실행하도록 내버려 두는 도구들이 내일의 공급망 사고 보고서가 됩니다. 업데이트 설계에서 동의는 있으면 좋은 것이 아닙니다. 메커니즘 그 자체입니다.