Stack Overflow 공식 블로그가 7월 29일 "개발자는 왜 도구에 집착하는가"라는 주제로, AI 코딩 에이전트가 빠르게 퍼지는데도 개발자의 신뢰는 오히려 낮아지는 현상을 다뤘다. Stack Overflow의 최근 개발자 서베이에 따르면 개발 과정에서 AI 도구를 쓰는 비율은 76%에서 84%로 늘었지만, AI 결과물을 신뢰한다고 답한 비율은 40%에서 29%로 줄었다. 사용은 늘고 신뢰는 줄어드는 이 간극이 글 전체의 출발점이다.
글은 6년 전 Stack Overflow가 실었던 "IDE가 좋아졌으니 Vim·Emacs를 쓰는 건 구식"이라는 기사에 개발자들이 거세게 반발했던 일화로 시작한다. 개발자가 낯선 도구보다 오래 써서 손에 익은 도구를 고집하는 이유는 도구 자체의 성능이 아니라, 그 도구를 중심으로 쌓아 온 작업 방식과 신뢰 때문이라는 것이 핵심 주장이다.
손에 익은 도구를 놓지 못하는 이유는 무엇인가
개발자 생산성 옹호자 트리샤 지(Tricia Gee)는 "IDE로 작업하는 게 더 빠른 이유는 그게 어떻게 동작하는지 알기 때문"이라고 말한다. Vim·Emacs를 오래 쓴 사람이 IntelliJ IDEA의 리팩토링 도구를 보고도 "학습 곡선이 필요하다"며 거부하는 것과 같은 현상이다. 도구를 오래 쓰면 손이 먼저 반응하는 무의식적 숙련(unconscious competence)이 쌓이고, 그 숙련이 곧 신뢰의 근거가 된다.
C++를 만든 비야네 스트로스트룹(Bjarne Stroustrup)은 이 지점에서 AI 코딩 도구의 근본적인 차이를 짚는다. "코드는 해법을 정확하게 표현한 것이지만, 영어(자연어)는 모호함이 없어야 할 것을 표현하기에는 형편없는 언어"라는 것이다. IDE나 정적 분석기, 컨테이너 도구는 자신이 하는 일의 경계가 뚜렷하지만, 자연어로 지시하는 AI 에이전트는 SDLC 전 영역에 걸쳐 예측 가능성이 떨어지는 방식으로 개입한다. 코드를 만드는 속도는 빨라졌지만, 그 결과물을 실제로 신뢰할 수 있는 수준까지 검증하는 데는 오히려 더 시간이 걸린다는 것이 글의 관찰이다.
도구는 왜 프로세스를 고쳐 주지 못하는가
글의 두 번째 축은 "도구가 프로세스를 담아 두기는 하지만, 도구 자체가 프로세스는 아니다"라는 구분이다. 좋은 CI/CD 도구를 쓴다고 배포가 빨라지는 것도 아니고, 좋은 이슈 트래커를 쓴다고 추정치가 정확해지는 것도 아니다. 프로세스의 상당 부분은 사람들의 행동과 규범, 즉 조직 문화로 존재하기 때문에 새 도구를 들여오는 일은 곧 조직 문화를 바꾸는 일과 같다는 것이다.
에이전트형 코딩 도구가 던진 충격은 코드를 만드는 일이 거의 무료에 가까워졌다는 점이다. 문제는 그 코드를 검증하는 일은 여전히 비용이 든다는 데 있다. "100줄을 고치면 PR이 빨리 승인된다"는 오래된 농담처럼, 에이전트는 순식간에 수백 줄짜리 diff를 만들어 리뷰어에게 던진다. LLM이 다른 AI가 쓴 코드를 심사하는 LLM-as-a-judge 방식이 대안으로 떠오르고 있지만, AI가 쓴 코드를 AI가 신뢰할 만하게 심사하도록 만드는 일 자체가 새로운 과제다.
비트(Bit)의 수석 과학자 랄리 바르일란(Laly Bar-Ilan)은 이를 DRY(같은 코드를 반복하지 않는다) 원칙이 AI 시대에는 WET(모든 것을 두 번 쓴다)로 뒤집힌 사례로 설명한다. 한 개발자가 에이전트에게 "버튼을 만들어 달라"고 하면 순순히 만들어 주고, 다른 팀 개발자가 똑같이 요청하면 코드베이스에는 비슷한 버튼이 하나 더 생긴다는 것이다. 재사용 가능한 컴포넌트를 만드는 순간이 아니라, 그것을 검증한 뒤 다시 쓰도록 관리하는 지점에서 신뢰가 갈린다.
흩어진 신뢰를 다시 모으려면 무엇이 필요한가
예전 SDLC에서는 기획자가 요구사항을 정하고, 아키텍트가 설계하고, 엔지니어가 구현하고, QA가 깨뜨려 보고, DevOps가 운영을 지켜보는 식으로 역할이 나뉘어 있었고, 그 나뉜 구조 자체가 서로를 검증하는 안전판이었다. 슬랙 최고제품책임자 제이미 들랑그(Jaime DeLanghe)는 지금은 "디자이너와 상의하지 않고 에이전트에게 디자인을 시키고, 다른 도메인 엔지니어에게 묻지 않고 에이전트에게 코드베이스를 물어보는" 식으로 개발자가 혼자 모든 것을 처리하는 실리콘 같은 존재가 되기 쉽다고 짚는다. 클라우드플레어 최고기술책임자 데인 크넥트(Dane Knecht)는 그 대안으로 PR에 에이전트와 나눈 대화 기록을 함께 남기는 방식을 제안한다. 코드가 어떻게 만들어졌는지 프롬프트 과정을 그대로 볼 수 있으면, 코드만 보는 것보다 더 많은 신뢰 근거가 생긴다는 것이다.
허니컴 최고기술책임자 채리티 메이저스(Charity Majors)는 "인간이 루프 안에 있다(human-in-the-loop)"는 표현이 마치 동정으로 끼워 준 자리처럼 들린다고 꼬집으며, "내가 그 루프를 만들었고 내가 그 루프를 소유한다"고 말한다. 커밋을 올린 사람이 그 코드를 소유하고, PR을 승인한 사람이 그 승인을 소유한다는 원칙은 AI 이전과 다르지 않다. 금요일 밤 배포가 사고로 이어져도 IDE를 탓하지 않았던 것처럼, 에이전트가 만든 코드가 문제를 일으켜도 책임은 키보드와 의자 사이, 즉 사람에게 있다는 것이다.
마이크로소프트 개발자 커뮤니티 부사장 스콧 핸슬먼(Scott Hanselman)은 "기회에 맡겨 두면 반드시 기회에 맡겨진 대로 된다"며, ARM에서도 동작해야 한다고 명시하지 않으면 에이전트는 x64용으로만 앱을 만든다고 예를 든다. spec.md 같은 명세 파일로 원하는 동작을 명시적으로 적어 두는 일이 예전에는 시니어 개발자의 암묵적 감각이었던 부분을 대신 채워야 한다는 뜻이다. 마지막으로 아닐 대시(Anil Dash)는 "6년째 잘 돌아가는 소박한 bash 스크립트는 그대로 두라"며, 결정적(deterministic) 해법이 이미 있는 자리에 비결정적인 AI를 끼워 넣지 않는 판단 자체가 신뢰를 지키는 가장 큰 요령이라고 정리한다.
결국 글이 말하는 신뢰는 도구의 성능이 아니라 도구를 둘러싼 프로세스에서 나온다. 사람이 만든 프로세스를 사람이 신뢰했던 것처럼, AI가 낀 프로세스에서도 누가 책임지는지 명시하고, 프롬프트와 명세를 남기고, 검증된 결과를 재사용하는 습관을 쌓아야 그 신뢰가 다시 생긴다는 것이 결론이다.
출처: Stack Overflow Blog, "Developers are attached to tools because tools encode trust"