개발자들이 Vim과 Emacs 또는 통합 개발 환경과 같은 도구에 애착을 갖는 이유는 단순히 익숙하기 때문만이 아니라, 이러한 도구가 코드를 생각하고 작성하고 검토하는 방식의 일부가 되기 때문이다. 사용자가 오랜 경험을 쌓으면 명령과 절차가 암묵적 지식과 근육 기억으로 바뀌면서 도구는 손의 자연스러운 연장처럼 느껴진다. 이러한 관계는 완전한 애플리케이션을 빠르게 생성할 수 있지만 정확성, 명확성, 예측 가능성은 떨어지는 에이전트 코딩 도구에 대한 망설임의 한 측면을 설명한다.
이 글은 도구와 도구를 둘러싼 신뢰 및 프로세스 사이의 연관성을 설명한다. 신뢰할 수 있는 도구란 단지 작업을 수행하는 도구가 아니라, 개발자가 그 한계와 동작을 알고 결과를 예측할 수 있게 해주는 도구다. 반면 에이전트형 AI 도구는 역량이 끊임없이 변하고, 모호할 수 있는 자연어 명령에 의존한다. 글에서 언급한 최근 개발자 설문 조사 데이터에 따르면 AI 사용률은 76%에서 84%로 증가한 반면, AI에 대한 신뢰도는 40%에서 29%로 하락했다.
도구는 개발 프로세스의 일부다
터미널이나 텍스트 편집기 또는 통합 개발 환경에서 작업하는 법을 배운다는 것은 단순히 별도의 프로그램을 배우는 것이 아니라 코드를 작성하고 이해하고 개선하기 위한 전체 프로세스를 구축하는 것을 의미한다. 따라서 터미널에서 통합 개발 환경으로 전환하려면 작업 방식을 다시 구성해야 할 수 있으며, 어느 쪽에서든 에이전트 코딩 도구로 전환하는 것은 더 큰 변화다.
개발자 생산성 옹호자인 Tricia Gee는 개발자가 익숙한 개발 환경을 사용할 때 더 빠를 수 있다고 설명한다. 손가락이 무엇을 해야 하는지 익숙해져 있기 때문이다. 숙련된 Vim과 Emacs 사용자에게도 같은 원리가 적용된다. 시간이 지나면서 개발자가 도구를 신뢰하고 코드를 생성하고 개선하는 데 사용할 수 있도록 돕는 무의식적인 능숙함이 형성된다.
통합 개발 환경, 컨테이너 도구, 정적 분석기와 같은 전통적인 도구는 사용자에게 도구의 한계와 역할에 대한 명확한 인식을 제공한다. 반면 AI는 소프트웨어 개발 생명 주기의 도구 체인 여러 부분에 스며들기 때문에 AI에 대한 신뢰 하락이 전체 프로세스에 영향을 미친다. 코드 작성은 더 빨라질 수 있지만, 코드를 검증하고 프로덕션에서 비용이 큰 장애를 일으키지 않을지 확인하는 데는 더 많은 시간이 걸릴 수 있다.
도구는 망가진 프로세스를 고치지 못한다
에이전트 코딩 도구는 개발 프로세스의 성격을 바꾸었으며, 이로 인해 정적 검사, 단위 테스트, 통합, 지속적 배포 도구처럼 이전 프로세스를 중심으로 만들어진 도구가 현재 형태로는 덜 적합해질 수 있다. 그러나 이 글은 도구와 도구가 구현하는 프로세스를 구분한다. 좋은 지속적 통합 및 배포 도구가 더 빠른 배포를 보장하는 것은 아니며, 강력한 통합 개발 환경이 더 나은 코드 작성을 보장하는 것도 아니고, 이슈 추적 시스템이 노력 추정의 정확성을 보장하는 것도 아니다.
프로세스의 일부는 조직의 문화와 구성원들의 행동 및 기준 속에서 형성된다. 따라서 새로운 도구는 아무리 큰 가능성을 보여도 기존 문화와 프로세스에 부합하지 않거나 개발자들이 사용 이유를 이해하지 못하면 실패할 수 있다. 이 글은 에이전트 코딩 도구가 개발자들이 문제를 빠르게 해결하도록 도왔기 때문에 빠르게 확산되었지만, 동시에 요구 사항 정의, 문제 정의, 해결의 의미에서 오래된 결함을 드러냈다고 지적한다.
코드 생성 비용은 과거에 비해 거의 무료가 되었지만, 코드 검토 비용까지 그렇게 된 것은 아니다. 개발자들은 에이전트가 짧은 순간에 만들어 낸 거대한 병합 요청을 마주할 수 있으며, 이는 검토자의 부담을 늘리거나 형식적인 검토를 채택하게 만들 수 있다. 검토 범위를 넓히기 위해 언어 모델을 심판으로 사용하는 방법이 개발되고 있지만, AI가 작성한 코드를 AI가 검토하는 능력에 대한 신뢰를 구축하려면 추가 작업이 필요하다.
코드를 실행하는 데에도 비용이 따른다. 여기에는 인프라 비용, 컴퓨팅·메모리·트래픽과 같은 클라우드 자원, 종속 서비스와 호스팅된 API, 그리고 중단·보안 침해·기회비용과 같은 장애 비용이 포함된다. 이러한 요소를 고려하지 않고 코드를 생성하는 도구가 반드시 유용한 것은 아니며, 신뢰할 수 있는 소프트웨어를 만들어 내던 프로세스를 약화시킬 수도 있다.
책임과 프로세스를 통해 신뢰 구축하기
전통적인 개발 주기에서는 서로 연결된 역할을 통해 신뢰가 분산되었다. 제품 관리자는 요구 사항을 정의하고, 아키텍트는 해결책을 설계하며, 엔지니어는 소프트웨어를 구축하고 변경 사항을 검토한다. 품질 보증 팀은 장애 지점을 테스트하고, DevOps 및 SRE 전문가는 출시 후 성능과 자원을 모니터링한다. 이러한 분업은 개인이나 도구가 경계를 벗어나 시스템에 해를 끼치는 방식으로 행동할 가능성을 줄이는 데 도움이 되었다.
이 글은 AI의 지원을 받는 개발 주기에도 이와 유사한 원칙이 필요하다고 본다. 사람과 함께 일하고, 책임과 책무를 정하며, 프로세스를 공유하고 점진적으로 개선하고, 오류 가능성을 줄여야 한다. AI가 기여한 부분을 명확히 하면서도 인간이 책임을 지는 주체로 남아야 한다.
에이전트가 변경 사항을 만들었다는 이유만으로 책임이 에이전트에게 이전되지는 않는다. 변경 사항을 저장소에 푸시하는 사람은 코드에 책임이 있고, 병합 요청을 승인하는 사람은 승인에 책임이 있다. 이 글이 제시하는 논리에 따르면 변경 사항으로 인해 프로덕션 환경이 손상되더라도 개발 환경이나 도구에 책임을 돌릴 수 없다. 변경 사항이 통과하도록 허용한 사람들과 프로세스에 책임이 있다.
이러한 전환은 협업과 관련된 또 다른 과제도 제기한다. 에이전트는 한 명의 개발자가 제품 요구 사항부터 DevOps 작업까지 이어지는 업무를 수행할 수 있게 해 주며, 이로 인해 해당 개발자가 디자이너나 특정 코드베이스를 전문으로 하는 엔지니어와 소통하지 않는 고립된 섬으로 변할 가능성이 커진다. 이 글은 도구가 작업을 빠르게 수행할 수 있어 보이더라도 이러한 경로가 거대한 병합 요청으로 이어질 수 있다고 경고한다.
핵심 결론은 새로운 도구가 유용하지 않다는 것이 아니라 도구만 개선해서는 망가진 개발 주기를 고칠 수 없다는 것이다. 조직에는 개발자들이 이해하고 받아들이는 프로세스, 에이전트의 역할에 대한 명확한 한계, 실질적인 책임을 수반하는 인간의 검토, 개발이 폐쇄적인 개인 활동으로 변하지 않도록 하는 협력이 필요하다. 그렇게 할 때 도구와 문화가 함께 작동해 AI에 의존하는 개발 환경에서 새로운 신뢰를 구축할 수 있다.