코드는 거의 공짜가 됐지만, 신뢰는 아니다 — 에이전트 시대의 도구론

개발자가 특정 편집기나 IDE에 애착을 갖는 이유는 단순한 취향이 아니다. Vim이나 Emacs는 초심자에게 탈출조차 어려운 암호 같은 단축키 덩어리로 보이지만, 숙련자에게는 생각의 연장처럼 자연스럽게 작동한다. 스택오버플로우 블로그가 짚은 핵심은 여기에 있다. 도구는 그 자체로 신뢰를 담는 그릇이며, 개발자는 오랜 시간 손에 맞게 도구를 길들이고 그 위에 자신의 작업 프로세스를 쌓아 올린다. 『실용주의 프로그래머』가 말한 '날카로운 도구', 즉 손의 확장처럼 느껴지는 도구라는 개념이 그것이다. 문제는 이 신뢰의 기반이 지금 크게 흔들리고 있다는 점이다.

왜 에이전트는 신뢰를 얻기 어려운가

자연어로 명령하는 코딩 에이전트는 전통적인 도구와 성격이 다르다. 애플리케이션 전체를 순식간에 만들어내지만, 개발자가 직접 짠 코드가 갖는 정밀함과 예측 가능성은 없다. C++ 창시자 비야네 스트롭스트룹의 지적처럼 코드는 해법을 정확하게 진술하는 언어인 반면, 영어(자연어)는 모호함 없이 무언가를 표현하기에는 형편없는 언어다. 도구가 미덥다는 것은 곧 예측 가능하고 반복 없이 결과를 낸다는 뜻인데, 에이전트는 더 빠른 대신 더 불투명하고 덜 예측 가능하다.

이 간극은 수치로도 드러난다. 스택오버플로우 개발자 설문에서 AI 사용률은 76%에서 84%로 올랐지만, 신뢰도는 오히려 40%에서 29%로 떨어졌다. 많이 쓸수록 덜 믿게 된 셈이다. 부엌칼이 매번 모양과 무게와 날이 바뀐다면 쓸 때마다 다시 익혀야 하듯, 능력이 끊임없이 변하는 도구에는 신뢰가 쌓이기 어렵다. 개발 생산성 옹호자 트리샤 지가 "IDE는 손가락이 알아서 움직인다"며 AI 도입을 주저한 것도 같은 맥락이다. 도구에 대한 깊은 이해는 결국 무의식적 숙련으로 굳는다.

도구는 프로세스를 인코딩할 뿐, 프로세스 자체는 아니다

더 중요한 통찰은 도구의 교체가 신뢰의 위기를 드러낼 뿐 스스로 해결하지는 못한다는 것이다. 린터, 자동화된 유닛 테스트, CI/CD 같은 도구들은 기존 프로세스를 코드로 옮겨 담은 결과물이지, 프로세스 그 자체가 아니었다. 훌륭한 CI/CD가 곧 빠른 출시를 보장하지 않았고, 좋은 IDE가 좋은 코드를 담보하지 않았다. 프로세스의 상당 부분은 사람들의 행동과 규범, 즉 문화로 존재한다. 그래서 새 도구는 조직 문화와 맞물릴 때에만 성공하고, 문화와 어긋나면 아무리 뛰어나도 외면당한다. 깨진 프로세스에 더 좋은 도구를 얹어도 프로세스는 여전히 깨져 있다.

에이전트 코딩은 문제 해결 속도 덕분에 빠르게 확산됐지만, 동시에 기존 프로세스의 균열을 드러냈다. 코드 생성이 거의 공짜가 되자 병목은 검증과 코드 리뷰로 옮겨갔다. "PR을 빨리 승인받으려면 100줄을 바꿔라"던 오래된 농담처럼, 에이전트가 순식간에 쏟아내는 거대한 diff를 사람이 제대로 리뷰하기는 어렵다. LLM이 심판 역할을 맡는 방식이 대안으로 떠오르지만, AI가 쓴 코드를 AI가 리뷰하는 것을 믿을 수 있게 만드는 일 자체가 또 다른 과제다. 실행 비용도 공짜가 아니다. 인프라, 호스팅 의존성과 API, 그리고 가장 예측하기 힘든 장애·다운타임·보안 사고 비용까지, 이런 비용을 고려하지 못하는 코드를 뽑아내는 도구는 오히려 부담이 된다.

책임은 여전히 키보드와 의자 사이에 있다

그렇다면 실무자는 무엇을 붙잡아야 하는가. 첫째는 책임의 소재를 사람에게 명확히 두는 것이다. 허니컴 CTO 채리티 메이저스는 흔히 쓰이는 '휴먼 인 더 루프'라는 표현을 두고, 자신이 그 루프를 만들고 소유한 당사자라고 강조했다. 커밋을 올린 사람이 그 코드의 주인이고, PR을 승인한 사람이 그 승인의 주인이다. AI 이전에 금요일에 운영 장애를 냈을 때 IDE를 탓하지 않았듯, 지금도 문제는 에이전트가 아니라 키보드와 의자 사이에 있다.

둘째는 협업의 재설계다. 슬랙 CPO 제이미 들랑주는 에이전트가 개발자를 '1인 사일로'로 만들 수 있다고 경고한다. 디자이너와 상의하지 않고, 다른 도메인 엔지니어의 코드베이스를 묻지 않고도 거대한 PR을 혼자 밀어붙이게 되는 것이다. 이에 대한 대응으로 프롬프트 과정을 공유 공간에서 진행하거나, PR에 에이전트와 나눈 대화 기록을 첨부하자는 제안이 나온다. 클라우드플레어 CTO 데인 크네흐트의 말처럼, PR을 열어 개발자가 어떻게 사고하고 문제를 풀었는지 그 대화를 들여다보는 것은 코드가 어떻게 나왔는지에 대한 깊은 통찰을 준다.

셋째는 우연을 코드 작성 이전 단계에서 제거하는 것이다. 마이크로소프트의 스콧 핸슬먼은 "무언가를 운에 맡기면, 실제로 운에 맡겨진다"고 말한다. ARM 버전이 필요하면 프롬프트에 명시해야 하고, 명시하지 않은 것은 만들어지지 않는다. spec.md 같은 명세 파일이 방편이 되지만, 프롬프트 하나에 모든 것을 욱여넣을 수는 없다. 시니어 개발자가 오랜 시간에 걸쳐 체득하는 암묵지를 어딘가에 포착하고 검증해 필요한 순간에 맥락으로 공급하는 일이 관건이 된다. 여기에 재사용 원칙도 겹친다. Bit의 수석 과학자 랄리 바르일란은 오늘의 AI가 본질적으로 WET(모든 것을 두 번 쓰기)라고 지적한다. 한 팀이 버튼을 만들게 하고 다른 팀이 또 만들게 하면 코드베이스에 중복이 쌓인다. DRY 원칙, 즉 잘 만든 컴포넌트를 잃지 않고 재사용하는 훈련이 그래서 더 중요해진다.

결국 이 글이 던지는 메시지는 도구를 바꾸는 것만으로 신뢰가 회복되지 않는다는 것이다. AI SRE, 자동 코드 리뷰, 컨텍스트·메모리 관리 같은 새 도구들은 분명 유효한 보강재이지만, 문화와 프로세스가 그대로라면 균열은 남는다. 옛 SDLC가 사람들과 함께 일하며 어느 개인이나 도구도 시스템을 혼자 무너뜨리지 못하게 제어함으로써 신뢰를 쌓았듯, AI 시대의 신뢰 역시 책임과 설명 가능성을 사람에게 묶고, 작동하는 프로세스를 공유하며 반복 개선하고, 실수의 여지를 좁히는 데서 나온다. 한국의 실무 조직이 에이전트 도입을 검토할 때 도구 비교표보다 먼저 점검해야 할 것은, 자신들의 리뷰·검증·책임 프로세스가 코드가 사실상 공짜가 된 세계를 견딜 만큼 단단한가 하는 물음이다.