개발자가 도구에 애착을 갖는 이유는 도구에 신뢰가 축적되기 때문이다

약 6년 전, 우리는 IDE에 관한 글을 실었다. IDE가 놀라울 만큼 강력하고 유능해지고 있는데도 누군가 원시인처럼 Vim이나 Emacs를 쓴다는 사실이 경이롭다는 내용이었다. 도발적인 글이었던 만큼 많은 개발자가 격앙된 반응을 보였다. 개발자가 일하는 방식을 이해하지 못한 글이라며 비판하는 사람도 있었고, 온종일 Emacs의 복음을 전파하는 개발자도 있었다. 하지만 대부분은 이런 도구가 실제로 왜 유용한지를 두고 훌륭한 토론을 벌였다.

초보자에게 Vim과 Emacs는 비밀스러운 키 조합을 외워야만 사용하고, 심지어 종료할 수도 있는 직관적이지 않은 터미널 프로그램처럼 보인다. 하지만 숙련된 사용자에게는 생각하는 것만큼 자연스럽게 느껴질 수 있다. 한 댓글은 David Thomas와 Andrew Hunt의 The Pragmatic Programmer를 인용했다. 이 책은 개발자라는 장인에게, 적어도 과거에는 장인이었던 개발자에게, 손의 연장처럼 느껴지는 ‘날카로운 도구’가 필요하다고 설명한다. 무한히 맞춤 설정할 수 있는 Vim과 Emacs는 사용자의 손과 작업 방식에 정확히 맞게 다듬을 수 있다. 도구를 능숙하게 다루고 신뢰하는 데 시간을 들이며 자신에게 맞게 개조하면 큰 보상을 얻는다.

에이전틱 엔지니어링 시대의 새로운 도구는 자연어로 대화하는 터미널이다. 코딩 에이전트에는 개발자가 공들여 작성한 코드만큼의 정밀성과 명확성이 없지만, 훨씬 짧은 시간에 애플리케이션 전체를 만들어 낼 수 있다. 지금도 남는 질문은 그 결과물을 신뢰할 수 있느냐다. 최근 개발자 설문조사에서는 개발자가 AI를 더 많이 사용할수록 신뢰도는 오히려 낮아졌다. 사용률은 76%에서 84%로 올랐지만 신뢰도는 40%에서 29%로 떨어졌다.

도구 자체가 새롭고 기능도 끊임없이 변한다. 주방칼의 모양과 무게, 날이 계속 바뀐다면 사용할 때마다 다시 익혀야 한다. 그런 도구를 신뢰하기는 어렵다. 그러나 이는 도구를 사용하는 방식과 주변 프로세스, 그리고 도구가 그 프로세스를 강화하는 방식에도 문제가 있음을 보여준다. 좋아하는 칼이나 IDE, 붓 같은 도구를 신뢰하는 이유는 그 도구와 함께 쌓은 경험과 이를 둘러싼 프로세스가 있기 때문이다.

이 글에서는 도구가 어떻게 신뢰할 수 있는 프로세스를 만드는지, 도구의 변화가 망가진 프로세스를 어떻게 드러내면서도 고치지는 못하는지, 도구와 문화가 어디에서 함께 새로운 신뢰를 만들 수 있는지 살펴본다.

도구는 프로세스의 일부다

개발자 도구는 소프트웨어 개발 전반과 함께 작동하고 발전하며, 개별 개발자와도 함께 변한다. IDE나 그래픽 인터페이스가 없던 시절부터 터미널로 일하고 배웠다면 코드를 만든다는 개념 자체에 터미널과 터미널 텍스트 편집기가 포함된다. IDE를 도입하려면 새 도구만 배우는 것이 아니라 코드를 작성하는 프로세스까지 재구성해야 한다.

터미널에서 IDE로 옮기는 것만으로도 어려운 프로세스 변화라면, 일부가 말하듯 불필요한 변화라면, 둘 중 어느 환경에서든 에이전틱 코딩 도구로 전환하기는 더 어렵다. 개발자 생산성 지원 전문가 Tricia Gee는 이렇게 말했다. “제가 AI 프로그래밍을 받아들이길 주저하는 이유 중 하나는 작동 방식을 잘 아는 IDE로 작업하는 편이 더 빠르기 때문입니다. Vim과 Emacs를 아주 잘 쓰는 사람들과 일할 때도 같은 모습을 봤습니다. IntelliJ IDEA의 리팩터링 도구를 쓸 수 있다고 하면, 그들도 가능하지만 학습 과정이 필요하다고 답합니다. 어떤 도구든 오랫동안 사용해 왔으니 손가락이 무엇을 해야 할지 이미 아는 겁니다. 도구의 종류와 상관없이 아주 능숙해지면 많은 작업을 무의식적으로 해낼 수 있게 됩니다.”

이런 근육 기억과 소프트웨어가 코드 수준에서 작동하는 방식에 관한 암묵지는 개발자가 도구를 믿고 코드 작성과 개선을 맡길 수 있게 해준다. 반면 AI 에이전트는 더 빠르고, 내부가 더 불투명하며, 예측하기도 어렵다. 코드 대신 모호한 언어를 사용해 소프트웨어를 만든다. C++를 만든 Bjarne Stoustrup은 “코드는 해결책을 정밀하게 표현한 것이다”라며 “영어는 모호함이 없어야 하는 내용을 표현하기에 형편없는 언어”라고 말했다. 믿을 만한 도구는 예측 가능하고 안정적이다. Emacs나 Vim을 상대할 때는 같은 요청을 거듭 수정하며 시도할 필요가 없다.

IDE나 컨테이너화 도구, 정적 분석기 같은 대부분의 개발자 도구는 경계가 분명하다. 맡은 역할이 있고 그 범위를 벗어나지 않는다. 하지만 AI는 SDLC 도구 체계의 모든 영역에 스며들고 있다. 따라서 개발자가 AI에 느끼는 낮은 신뢰가 프로세스 전체로 확대된다. 코드는 더 빨리 만들 수 있지만, 이를 검증하고 비용이 큰 프로덕션 장애를 일으키지 않는다고 개발자가 믿을 수 있는 수준까지 끌어올리는 데는 오히려 시간이 더 걸리곤 한다.

도구는 프로세스를 담지만 고치지는 못한다

에이전틱 코딩 도구는 소프트웨어 개발 프로세스의 성격을 바꾼다. 린터, 자동 단위 테스트, CI/CD처럼 이전 프로세스를 중심으로 만들어진 도구는 달라진 프로세스에서 현재 형태 그대로 작동하지 않을 수 있다.

그 도구들은 프로세스를 담고 있었지만 프로세스 자체는 아니었다. 훌륭한 CI/CD 도구가 있다고 더 빨리 배포하는 것은 아니었다. 훌륭한 IDE가 있다고 더 좋은 코드를 작성하는 것도 아니었다. 스토리 포인트를 지원하는 이슈 추적 시스템이 있다고 작업량을 잘 추정하는 것도 아니었다. 프로세스의 일부는 소프트웨어를 만드는 사람들의 행동과 규범, 즉 문화로 존재했다. 새로운 도구를 도입하려면 흔히 조직 문화도 바꿔야 한다.

규모가 큰 엔지니어링 조직에서 일한다면 익숙한 이야기일 것이다. 아무리 가능성이 큰 새 도구라도 기존 문화와 프로세스에 맞지 않으면 실패할 수 있다. 도구가 성공하려면 개발자가 받아들이고 이해할 수 있는 방향으로 문화와 프로세스도 바뀌어야 한다. 개발자는 무언가를 만들고 문제를 해결하기 좋아하므로, 그 일을 더 잘하도록 돕지 못하는 도구는 외면받는다.

에이전틱 코딩은 개발자가 문제를 더 빨리 해결하게 해주었기 때문에 빠르게 확산했다. 그러나 코드를 만드는 일이 거의 사소해지자 기존 프로세스의 여러 결함도 드러났다. 요구사항이 불명확하고 계속 바뀌는 문제는 전부터 있었지만, 이제 문제를 해결하려면 ‘문제’와 ‘해결’이 각각 무엇을 뜻하는지 엄밀하게 정의해야 한다.

코드는 거의 공짜가 됐을지 몰라도 검증은 공짜가 아니다. 새로운 병목은 코드 리뷰다. PR을 빨리 승인받고 싶으면 100줄을 바꾸라는 오래된 농담이 있었다. 코딩 에이전트는 순식간에 수백 줄을 수정한 뒤 사람이 검토하거나 형식적으로 승인해야 할 거대한 diff를 보낸다. 확장 가능한 해결책으로 LLM-as-a-judge가 발전하고 있지만, AI가 작성한 코드를 다른 AI가 제대로 검토한다고 믿을 방법을 설계하려면 노력이 필요하다.

같은 관점에서 코드를 실행하는 일도 공짜가 아니다. 클라우드 네이티브 시대의 인프라 비용은 애플리케이션이 사용하는 컴퓨팅 자원과 메모리, 트래픽 양에 따라 달라진다. 호스팅된 의존성과 API 비용도 든다. 예산을 잡기 가장 어려운 실패 비용도 있다. 다운타임, 보안 침해, 기회비용이 여기에 포함된다. 이런 비용을 고려하지 않거나 고려할 수 없는 소프트웨어를 만드는 도구라면 사용할 가치가 없을 수 있다. 게다가 이전까지 신뢰할 수 있고 안정적인 소프트웨어를 만들던 프로세스에 부담을 준다.

많은 사람에게 에이전틱 코딩은 SDLC가 망가졌다고 느끼게 했다. 자연스럽게 이들은 AI SRE, 자동 코드 리뷰, 메모리 및 컨텍스트 관리자, 컨트롤 플레인과 하네스 개선 등 균열을 메울 새 도구를 찾고 있다. 모두 AI를 사용하는 소프트웨어 조직의 도구 체계에 유용한 요소다. 하지만 문화와 프로세스가 그대로라면 도구만으로 문제를 해결할 수 없다. 사람들이 사용하지 않을 수도 있는 더 좋은 도구를 망가진 프로세스에 얹어도 프로세스는 여전히 망가져 있다.

더 나은 프로세스로 신뢰 쌓기

기존 SDLC에서는 제품 관리자가 조사와 고객 대화, 경쟁사에 대한 이해를 바탕으로 기능 요구사항을 만들었다. 아키텍트는 오랜 경험과 기존 기술 스택에 대한 이해를 바탕으로 소프트웨어 명세를 작성했다. 엔지니어는 코드 로직과 기존 코드베이스에 관한 지식을 활용해 소프트웨어를 만들고 커밋을 검토했다. QA는 소프트웨어가 어떤 방식으로 망가지는지 경험으로 알고 있었기에 이를 검토하고 깨뜨려 보려 했다. 소프트웨어를 프로덕션에 배포한 뒤에는 DevOps와 SRE가 이전 경험을 토대로 성능과 사용 자원을 모니터링하고 관리했다.

이 시스템에 대한 신뢰는 사람들과 함께 일하고 그들이 어떻게 생각하는지 이해하며, 한 개인이나 도구가 통제를 벗어나 시스템을 파괴할 가능성을 제한하면서 쌓였다. AI를 사용하는 SDLC에서 신뢰를 구축할 때도 같은 요소가 필요하다. 사람들과 협력하면서 책임 소재를 분명히 하고, 작업 프로세스를 공유하고 개선하며, 실수가 발생할 가능성을 최소화해야 한다.

첫 단계는 인간을 책임 주체로 확실히 규정하고 AI가 기여한 부분을 표시하는 것이다. 모두가 ‘human-in-the-loop’를 이야기하지만 Honeycomb CTO Charity Majors는 이렇게 지적했다. “Human-in-the-loop라니, 마지못해 끼워 주는 것처럼 들립니다. 그 루프는 내가 만들었고 내가 소유하며, 내가 있기에 존재합니다. 그건 빌어먹을 ‘내’ 루프예요!” 커밋을 푸시한 사람이 그 코드를 책임진다. PR을 승인한 사람들은 그 승인을 책임진다. AI가 등장하기 전 금요일에 프로덕션을 망가뜨렸다고 IDE를 탓하지는 않았다. 지금 사고를 내더라도 문제는 에이전트가 아니라 키보드와 의자 사이에 있다.

AI 시대의 협업은 더 어렵고 낯설 수 있다. 에이전트를 사용하면 풀스택 개발자의 범위가 넓어진다. 코딩 에이전트 하나로 제품 요구사항부터 DevOps까지 모두 처리할 수 있다. 개발자는 너무 쉽게 혼자만의 사일로가 될 수 있다. Slack 최고제품책임자 Jaime DeLanghe는 이렇게 설명했다. “에이전트가 디자인을 만들게 했으니 디자이너에게 디자인을 확인받지 않아도 되고, 특정 분야의 다른 엔지니어와 함께 일하며 그들의 코드베이스를 이해할 필요도 없습니다. 에이전트에게 질문하면 되니까요. 이 길을 한참 따라가다 보면 거대한 PR을 만들 수 있습니다.”

일부는 모두가 프로세스에 의견을 내고 수정할 수 있도록 공유된 공간에서 에이전트에게 프롬프트를 입력하자고 제안했다. 모든 PR에 프롬프트를 주고받은 기록을 포함하자는 의견도 있다. 에이전트와의 대화를 공개하면 코드가 만들어진 과정을 전보다 더 깊이 이해할 수도 있다. Cloudflare 최고기술책임자 Dane Knecht는 “PR을 열어 개발자가 어떻게 생각하고 문제를 어떻게 해결했는지 실제로 볼 수 있다는 점이 정말 멋지다”고 말했다.

기존 프로세스가 접근 제어, 감사 기록과 diff, CI/CD 검사로 실수의 피해 범위를 제한했다면, 새로운 프로세스는 코드를 작성하기 전에 우연이 개입할 여지를 없애야 한다. 코드가 해야 할 일을 프롬프트에 빠짐없이 명시해야 한다는 뜻이다. 이를 위해 spec.md 파일을 사용할 수 있지만, 이제는 명시하지 않은 것까지 만들어질 수 있다. Microsoft 개발자 커뮤니티 부사장 Scott Hanselman은 이렇게 말했다. “무언가를 우연에 맡기면 정말 우연에 맡겨집니다. 작은 링 라이트 앱을 만들었는데 저는 x64를 쓰고 있었습니다. ARM에서도 작동하게 하려면 ‘ARM 버전도 만들어 줘’라고 말해야 했죠. 그렇게 하지 않았다면 만들어지지 않았을 겁니다.”

물론 필요한 모든 내용을 기발한 프롬프트 하나에 욱여넣을 수는 없고, 그렇게 해서도 안 된다. 같은 말을 여러 번 반복하게 될뿐더러 회사의 암묵지로만 존재하는 내용을 거의 틀림없이 몇 가지 놓치게 된다. 많은 뛰어난 사람이 에이전트에 더 나은 컨텍스트를 제공하고 장·단기 기억을 부여할 방법을 고민하고 있다. 핵심은 코드에 필요한 올바른 컨텍스트를 에이전트에게 주는 것이다. 보통 이런 지식은 시니어 개발자가 오랜 시간 경험하며 체득한다. 하지만 에이전트가 쓰려면 그 지식을 Stack Internal 같은 곳에 기록하고 검증한 뒤, 필요할 때 적절한 부분을 컨텍스트로 제공해야 한다.

이제 세계 최고의 프롬프트를 만들었다고 하자. 에이전트에 올바른 컨텍스트를 주었고, 에이전트가 만든 결과물이 동료 검토를 통과해 프로덕션에 배포됐다. 다음으로 지켜야 할 원칙은 그 기능을 다시 만들지 않는 것이다. 이미 완벽하게 쓸 만한 소프트웨어 컴포넌트가 있으니 잃어버리지 말고 재사용해야 한다. Bit 수석 과학자 Laly Bar-Ilan은 “DRY(don't repeat yourself) 원칙이 우리의 핵심 원칙”이라며 이렇게 말했다. “오늘날 AI는 본질적으로 WET(write everything twice)입니다. 한 개발자가 ‘좋아, 버튼을 만들어 줘’라고 하면 기꺼이 만들고, 다른 팀의 다른 개발자가 요청하면 코드베이스에 또 다른 버튼을 만듭니다.”

하지만 AI 에이전트를 신뢰하기 위한 가장 중요한 요령은 언제 사용하지 말아야 하는지 아는 것일 수 있다. 프로세스에 앞서 언급한 모든 안전장치를 마련해도 AI의 본질상 결과에는 여전히 약간의 운이 따른다. 이미 충분히 잘 작동하는 비확정적 해결책이 있다면 왜 다시 만들겠는가? Anil Dash는 이렇게 말했다. “확정적 코드가 필요한 수많은 사례에 비확정적 시스템을 적용하려 하고 있습니다. LLM은 그런 일에 적합하지 않은데, 왜 못이 아닌 모든 것에 망치를 휘두르려는 걸까요? 6년 동안 실행돼 온 소박한 bash 스크립트면 충분합니다.”

과거에는 함께 일하는 사람과 사용하는 도구 덕분에 신뢰가 시스템에 내재돼 있었다. 그 신뢰는 예측 가능성에서 나왔다. 무엇을 할 수 있는지, 강점과 약점이 어디에 있는지 알았고, 월요일에 함께 일한 경험이 화요일에도 이어지리라 기대할 수 있었다. AI의 확률적 성격과 개선 및 변화의 속도는 이 모든 전제를 무너뜨린다. 프로세스를 개선하면 개발 과정에 신뢰를 다시 설계해 넣을 수 있다.

결론

예전에는 사람을 중심으로 프로세스를 만들었고, 함께 일하는 사람을 신뢰했기에 그 프로세스도 믿었다. 프로세스를 관리할 믿을 만한 도구를 만들었고, 그 도구는 우리 자신과 동료의 연장선으로 작동했다.

AI를 사용하면 그런 프로세스의 상당 부분을 자동화할 수 있다. 좋은 점은 일을 더 빨리 끝낼 수 있다는 것이다. 나쁜 점은 일이 끝나도 그 결과를 믿지 못한다는 것이다. 도구는 새롭고, 사람은 더 상위 수준의 역할로 이동하고 있으며, 우리는 여전히 신뢰를 쌓아야 한다. 인간의 판단을 보존하면서 더 신중하고 명시적으로 정의한 작업 절차를 마련하면 새로운 시스템을 신뢰하기 시작할 수 있다.

성공하는 팀은 가장 많은 코드를 생성하는 팀이 아닐 것이다. 피드백 루프를 만들고, 최상의 컨텍스트를 제공할 표준 지식을 구축하며, 프로세스와 작업 절차를 일치시키는 도구를 갖춘 팀이 성공할 것이다.

^{source https://stackoverflow.blog/2026/07/29/developers-are-attached-to-tools-because-tools-encode-trust/}

HN에서는 개발자가 도구를 믿는 기준으로 기능보다 예측 가능성과 통제권을 꼽았다. 오래 사용한 편집기는 조작법과 동작 방식이 쉽게 바뀌지 않아 오랜 숙련을 그대로 활용할 수 있다. 반면 자동 업데이트와 잦은 인터페이스 변경은 사용자의 선택과 무관하게 작업 환경을 흔든다. 도구에 대한 애착은 단순한 익숙함보다, 무엇이 언제 바뀌는지 스스로 결정할 수 있다는 감각에 가깝다.

AI 코딩 도구를 향한 불신도 여기서 출발한다. 모델과 시스템 설정이 계속 달라지면 어제 성공한 작업이 오늘 실패해도 원인을 찾기 어렵다. 자연어로 명시한 조건을 지키지 않거나, 한 기능의 수정이 예상 밖의 영역을 망가뜨렸다는 경험도 이어졌다. 코드를 빠르게 생성해도 검증과 복구에 비슷한 시간이 든다면 산출량만으로 생산성을 판단하기 어렵다는 지적이다.

그렇다고 활용 자체를 부정하는 분위기는 아니었다. 범위가 뚜렷한 CI 구성, 자동화 테스트 기반 마련, 보일러플레이트 작성에는 도움이 됐다는 경험도 나왔다. 다만 모델을 그대로 믿기보다 촘촘한 테스트와 격리된 실행 환경, 검증하기 쉬운 아키텍처를 갖춰야 한다. 안정적인 CLI나 도메인 전용 도구로 작업 범위를 좁히고, 방대한 자료 대신 필요한 정보만 추려 제공하는 방식도 결과의 일관성을 높이는 조건으로 제시됐다.

중요한 것은 결과를 재현하고 설명하며 제한할 수 있는가다. 생성 속도와 함께 검토 비용, 오류의 파급 범위, 테스트가 놓치는 영역, 업데이트에 따른 재학습 부담까지 살펴야 한다. 도구가 맡는 일의 양보다 사용자가 동작 범위와 변경 시점을 통제할 수 있는지가 신뢰를 가른다.