'AI한테 붙여넣고 고쳐달라고 했더니 됐어요.' 이 문장이 팀 슬랙에 올라오는 순간, 나는 조용히 긴장한다. 도구가 작동한 건지, 아니면 운 좋게 넘어간 건지 구분이 안 되기 때문이다. AI 코딩 도구는 지금 개발 워크플로우 깊숙이 자리를 잡았다. 하지만 도구를 쓰는 속도와 도구를 이해하는 깊이 사이의 간격은 오히려 벌어지고 있다.
"Fix this"가 실패하는 이유
dev.to에 올라온 AI 디버깅 프롬프트 관련 글은 이 간격을 정면으로 짚는다. 저자가 지적하는 핵심은 단순하다. "fix this"라는 프롬프트는 모델에게 역할도, 방법도, 추측을 금지하는 제약도 주지 않는다. 그래서 모델은 가장 쉬운 길을 택한다—해당 에러 메시지에서 가장 흔한 원인을 찾아 그걸 당신의 문제라고 가정하는 것. undefined is not a function이나 connection refused 같은 범용 에러는 흔한 원인과 당신의 원인이 다를 가능성이 높다. 결과적으로 버그는 사라지지 않고, 자신감 있어 보이는 틀린 코드 층 아래 숨는다.
해법은 모델이 코드를 한 줄도 쓰기 전에 추론을 먼저 보여주도록 강제하는 것이다. 시니어 엔지니어가 하는 방식—재현, 격리, 가설 수립, 검증—을 프롬프트 구조 자체에 녹이면 된다. 예를 들어 근본 원인 분석 프롬프트는 가능한 원인을 확률 순으로 나열하고, 각각을 확인하거나 제거할 수 있는 가장 저렴한 체크 방법을 제시하도록 요청한다. 마지막 줄에 "내가 결과를 보고하기 전까지 코드 변경을 제안하지 마라"는 제약을 명시하면, 모델은 증거 없이 패치를 쓰는 것을 멈춘다. 간헐적 버그에는 "실패하는 타임라인을 번호 순으로 써라"는 지시가 핵심이다. 타임라인이 실제로 구성된다면 버그는 실재하는 것이고, 모델이 타임라인을 만들지 못한다면 수정안을 지어내는 대신 그 사실을 인정하게 된다.
보이지 않는 실행, 추적이 없으면 눈이 멀다
프롬프트를 아무리 잘 짜도 해결되지 않는 문제가 있다. AI CLI 도구가 실제로 무슨 일을 하는지 보이지 않는다는 것이다. 같은 dev.to의 AI CLI 도구 투명성 관련 글은 이 불투명성을 구체적인 실패 시나리오로 보여준다. Claude Code가 React 컴포넌트를 리팩토링하는 과정에서 47개 파일을 읽고 $1.20의 토큰을 쓴 뒤 빌드를 깨뜨렸을 때, 도구가 돌려준 메시지는 "task completed with test failures". 무엇이 잘못됐는지 알 방법이 없다.
실행 추적을 붙이면 그림이 달라진다. 4단계에서 모델이 user.d.ts는 읽었지만 실제 API 계약이 담긴 api/users.ts는 읽지 않았다는 사실이 드러난다. 존재하지 않는 필드를 지어냈고, 그게 테스트를 깨뜨렸다. 원인이 보이면 수정은 간단하다—프롬프트에 파일 하나를 추가하면 된다. 추적 없이는 45분짜리 디버깅이고, 추적이 있으면 30초짜리 수정이다. 이건 특정 SDK의 기능 홍보가 아니라 패턴의 문제다. AI CLI 도구는 이제 프로덕션 코드를 쓰고, 배포를 실행하고, 데이터베이스를 건드린다. 실행의 각 단계를 관찰할 수 없다면, 실패했을 때 우리는 그냥 고고학자가 되는 것이다—터미널 로그를 파헤치며 추측하는.
숨겨진 정책 집행, 신뢰의 경계
프롬프트 품질과 실행 추적을 모두 챙겨도 남는 문제가 있다. 도구 자체가 사용자 모르게 무언가를 하고 있다면 어떻게 되는가. Claude Code의 'China Detector' 이슈가 정확히 이 지점을 건드린다. dev.to의 해당 분석 글에 따르면, Anthropic은 무단 리셀러 차단과 모델 증류 방지를 목적으로 로컬 환경에서 중국 관련 신호(타임존, 프록시 데이터 등)를 감지하고 프롬프트에 마커를 삽입하는 실험을 진행했다고 설명했다.
Anthropic이 그렇게 한 이유는 이해할 수 있다. 워싱턴포스트 보도에 따르면 약 2만 5천 개의 사기 계정이 2천 880만 건 이상의 교환을 생성해 경쟁 모델 학습에 활용됐다는 주장이 있다. 액세스 규칙을 집행하지 못하면 모든 API 키가 유출 경로가 된다. 그건 편집증이 아니라 비즈니스 모델의 문제다. 하지만 구현 방식이 문제다. 개발자 입장에서 도구가 사용자가 명확히 볼 수 없는 방식으로 요청 경로를 변경했다. 그것이 선을 넘은 지점이다.
웹 앱이 로그인 시 사기 탐지를 실행하거나, 결제 API가 거래를 스코어링하는 건 놀랄 일이 아니다. 코딩 에이전트는 다르다. 소스 코드, 셸 명령, 환경 변수, 레포 메타데이터, 프라이빗 컨텍스트 바로 옆에 앉아 있다. 신호가 좁더라도 개발자는 그것을 일반적인 서버 사이드 제어로 경험하지 않는다. 로컬 도구가 워크플로우 안에서 숨겨진 결정을 내리는 것으로 경험한다. 엔터프라이즈 보안팀이 지루할 정도로 이 문제를 따지는 건 이유가 있다. 동기가 합리적으로 들리는지가 아니라, 행동을 감사할 수 있는지, 컴플라이언스에 설명할 수 있는지, 버전 간에 안정적인지가 중요하다.
구조화된 불신이 실용적인 신뢰를 만든다
세 기사가 함께 가리키는 방향은 하나다. AI 코딩 도구를 동료처럼 대하는 태도에서, 강력한 서드파티 바이너리로 대하는 태도로의 전환이다. 동료는 무엇을 보내는지, 왜 그런지 설명할 수 있다. 조용히 요청을 태깅하는 바이너리는 내 노트북에 앉아 있는 벤더 인프라다.
실용적인 접근은 세 층위에서 작동한다. 첫째, 프롬프트를 구조화하라. "고쳐줘"가 아니라 모델이 추론을 먼저 보여주고, 증거가 확인된 뒤에만 코드를 수정하도록 제약하는 템플릿을 갖춰라. 특히 간헐적 버그와 회귀 버그에서는 이 구조가 틀린 수정을 걸러내는 실질적인 방어선이 된다. 둘째, 실행을 추적하라. AI 에이전트가 어떤 파일을 읽었고, 어떤 API를 호출했으며, 어디서 결정이 갈렸는지 볼 수 없다면 실패 시 디버깅 비용은 전적으로 팀이 진다. 에이전트가 프로덕션 코드에 가까워질수록 실행 투명성은 선택이 아니라 전제 조건이다. 셋째, 도구의 네트워크 행동을 감시하라. 어떤 메타데이터가 나가는지, 어떤 정책이 로컬에서 집행되는지를 문서화해 공개하는 도구를 선호하라. 민감한 레포는 관리된 환경을 통해 실행하고, 버전을 고정하고, 릴리즈 노트를 읽어라.
전망: 투명성이 다음 경쟁 축이 된다
AI 코딩 도구 시장은 지금 기능 경쟁을 하고 있다. 다음 경쟁 축은 투명성이 될 것이다. 모델 벤더들은 남용 탐지, 증류 방지, 지역 제어, 엔터프라이즈 컴플라이언스를 위해 에이전트에 더 많은 정책을 탑재할 것이다. 동시에 에이전트는 로컬 머신에 더 깊이 접근할수록 유용해진다. 이 두 흐름이 충돌하는 지점은 클라이언트다.
그 충돌을 먼저 투명하게 해결하는 도구가 엔터프라이즈와 보안에 민감한 팀의 표준이 될 가능성이 높다. 조용한 분류기보다 명시적인 오류가, 숨겨진 정책보다 감사 가능한 진단 페이지가 장기적으로 더 많은 신뢰를 만든다. 지금 AI 코딩 도구를 맹목적으로 믿는 팀과, 구조화된 방식으로 이해하며 쓰는 팀 사이의 간격은 조용히 벌어지고 있다. 그 간격이 좁혀지는 방향은 도구가 더 스마트해지는 쪽이 아니라, 팀이 더 명확한 기준을 갖는 쪽이다.