trae가 API 키 암호화 키가 사실상 공개된 Zcode 전철을 밟는지 의문이다

중국 개발자 커뮤니티 v2ex에 AI 코딩 도구의 자격 증명 저장 방식을 둘러싼 논쟁이 다시 올라왔다. 게시글은 trae가 앞서 유사한 문제로 지적된 Zcode의 전철을 밟는 것이 아니냐는 의문을 던진다. 다만 글에서 구체적인 기술 내용이 확인되는 대상은 Zcode이며, trae가 실제로 어떤 방식을 쓰는지는 이 글에서 명시되지 않는다.

Zcode는 사용자가 등록한 여러 모델 제공사의 API 키와 OAuth 토큰을 AES-256-GCM으로 암호화해 디스크에 기록한다. 문제는 기본 설정에서 그 암호화 키가 비밀로 관리되지 않는다는 점이다. 플랫폼 이름과 홈 디렉터리 경로, 운영체제 사용자 이름을 이어 붙인 문자열을 SHA-256으로 한 번 해싱한 값이 키로 쓰인다. macOS를 예로 들면 "zcode-credential-fallback:darwin:/Users/<사용자명>:<사용자명>" 형태의 문자열이 그대로 키 재료가 된다. 같은 문자열을 재구성할 수 있는 환경이라면 암호문을 복호화할 수 있다는 뜻이다.

배경에는 AI 코딩 도구가 여러 모델 제공사의 키를 한곳에서 관리하게 되면서 생긴 부담이 있다. 사용자는 자연스럽게 로컬에 쌓이는 자격 증명의 안전성을 묻게 되지만, 도구 제작자 입장에서는 운영체제별로 다른 자격 증명 저장소를 일관되게 다루기가 쉽지 않다.

댓글에서는 상반된 시각이 나온다. API 키를 평문으로 저장하는 것이 일반적이므로 암호화 자체는 나은 선택이라는 의견이 있고, 홈 디렉터리 접근 권한은 결국 운영체제와 사용자가 관리하는 몫이라는 지적도 있다. 반면 Windows와 Linux에는 신뢰할 만한 시스템 차원의 자격 증명 저장 수단이 마땅치 않다는 반론도 제기된다. Windows의 DPAPI는 단일 사용자 환경에서 사실상 무의미하고, TPM 기반 방식은 최소 Windows 10 이상, 가상 머신 호환성 문제, TPM 고장 시 데이터 손실, 로그인 암호 설정 필수, 별도 시스템 서비스 필요, 무손실 이전·백업 불가 같은 제약이 따라붙어 결국 같은 대체 방식을 쓰게 된다는 것이다. 자격 증명 저장은 운영체제가 직접 구현해야 신뢰할 수 있지만, 크로스 플랫폼과 호환성을 동시에 만족시키는 방법이 아직 없다는 것이 이 논의의 요지다.

한 댓글 작성자는 Zcode 문제가 불거졌을 당시 국내 네 개 업체를 대상으로 한 테스트가 있었고 그중 온전한 곳이 없었다고 주장했다. 다만 이는 개인 댓글 수준의 주장으로, 테스트 방법이나 대상이 원문에 제시되지 않아 교차 확인된 사실로 보기는 어렵다.

개발자 입장에서 이 논의가 주는 실무적 결론은 분명하다. 로컬에 저장된 자격 증명의 암호화 여부만 보고 안전하다고 판단해서는 안 된다. 키를 도구별로 분리하고, 권한을 최소 범위로 좁히고, 주기적으로 교체하며, 사용량을 모니터링하는 쪽이 현실적인 방어선이 된다. 암호화가 적용됐다는 사실과 그 암호화가 실제로 비밀에 기반한다는 사실은 서로 다른 문제다.