개발자들이 도구에 집착하는 이유: 도구가 신뢰를 인코딩하기 때문이다

약 6년 전, 우리는 IDE(통합 개발 환경)에 관한 글을 게재한 적이 있습니다. 그 요지는 IDE가 너무 강력하고 능숙해져서, 여전히 Vim이나 Emacs 같은 것을 사용하는 것은 마치 동굴 사람 같다는 것이었습니다. 비록 도발적인 기사였지만, 많은 개발자들을 상당히 자극했습니다. 댓글은 양쪽에서 달렸는데, 한쪽에서는 개발자가 어떻게 일하는지 이해하지 못했다며 기사를 폄하하는 의견이 있었고, 다른 쪽에서는 하루 종일 Emacs의 좋은 소식을 전파하는 개발자들이 있었습니다. 하지만 대부분은 이 도구들이 실제로 왜 유용한지에 대한 큰 논의가었습니다.

초보자에게 Vim과 Emacs는 사용하기 위해 비밀 키 입력을 암기해야 하는 직관적이지 않은 터미널 프로그램처럼 보일 수 있습니다 (그리고 탈출하는 방법도요). 하지만 숙련된 사용자에게는 생각하는 것처럼 자연스럽게 느껴질 수 있습니다. 한 댓글은 David Thomas와 Andrew Hunt의 The Pragmatic Programmer를 언급하며, 개발자들—그들이 장인(craftsmen)이든 아니든—에게 손의 연장처럼 느껴지는 “날카로운 도구”가 필요하다고 설명했습니다. Vim과 Emacs는 무한한 커스터마이징 가능성을 가지고 있어 사용자의 정확한 손과 작업 흐름에 맞게 조형될 수 있습니다. 자신의 도구에 숙련도와 신뢰를 쌓는 데 시간을 투자하고, 또한 자신에게 맞도록 해킹하는 것은 깊은 배당금을 가져다줍니다.

에이전트 엔지니어링(agentic engineering) 시대에 접어들면서, 새로운 도구들은 자연어로 대화하는 터미널입니다. 코딩 에이전트는 잘 작성된 코드를 작성하는 개발자가 가진 정밀함과 구체성을 갖추고 있지는 않지만, 아주 짧은 시간에 전체 애플리케이션을 출력할 수 있습니다. 오늘날까지도 여전히 남아있는 질문은 그 결과물들을 신뢰할 수 있는지 여부입니다. 우리의 지난 Developer Survey에 따르면, 개발자들이 AI를 더 많이 사용할수록 그것에 대한 신뢰도는 낮아지는 경향을 보였습니다. 사용률은 76%에서 84%로 증가했지만, 신뢰도는 40%에서 29%로 하락했습니다.

도구 자체는 새롭고 그 기능은 끊임없이 변합니다. 만약 당신의 주방 칼이 모양, 무게, 날카로움이 계속 바뀐다면, 매번 다시 배워야 할 것입니다. 이는 신뢰를 쌓기 어려운 도구입니다. 하지만 이것은 또한 당신이 그 도구를 사용하는 방식, 주변 프로세스, 그리고 그 도구가 프로세스를 강화하는 방식에 결함이 있다는 것을 시사합니다. 당신이 가장 좋아하는 칼, IDE, 붓이나 무엇이든 간에 그것을 신뢰하는 것은 당신이 그것과 주변 프로세스를 통해 쌓아온 신뢰 덕분입니다.

본문에서는 도구가 어떻게 신뢰할 수 있는 프로세스를 구축하는지, 도구의 변화가 깨진 프로세스를 강조하지만 고칠 수는 없는 방식은 무엇인지, 그리고 도구와 문화가 함께 작동하여 새로운 신뢰를 구축할 수 있는 지점을 살펴볼 것입니다.

도구는 프로세스의 일부입니다

개발자 도구(Developer tooling)는 소프트웨어 개발 전체와 함께, 그리고 개별 개발자와 함께 운영되고 진화합니다. 만약 당신이 터미널에서 작업하고 학습하기 시작했다면, 어쩌면 IDE나 그래픽 인터페이스가 존재하지 않던 날에 말입니다. 그렇다면 코드를 작성하는 방식을 이해하는 것에는 그 터미널과 터미널 텍스트 편집기가 포함됩니다. 여기에 IDE를 추가한다는 것은 단순히 새로운 도구를 배우는 것을 넘어 코드 작성 프로세스를 재구성(refactoring)해야 함을 의미합니다.

터미널에서 IDE로 이동하는 것이 어려운 프로세스 변화이거나 (혹은 어떤 이들이 말하듯이 불필요하다면), 거기서 에이전트형 코딩 도구(agentic coding tool)로 이동하는 것은 더 어렵습니다. 개발자 생산성 옹호가인 Tricia Gee는 “AI 프로그래밍의 일부를 받아들이는 데 있어 저의 주저함 중 하나는 제가 IDE에 더 빠르기 때문입니다. 저는 그것이 어떻게 작동하는지 알거든요”라고 말했습니다. 그녀는 또한 “Vim과 Emacs를 아주 잘 아는 사람들과 작업했을 때도 같은 것을 보았습니다. IntelliJ IDEA에서 재구성 도구(refactoring tools)를 사용할 수는 있습니다. 물론 가능하지만, 학습 곡선이 필요합니다. 저는 어떤 도구를 사용하든 너무 오랫동안 사용해 왔습니다. 제 손가락은 무엇을 해야 할지 알고 있습니다. 어떤 것이든 간에 도구를 매우 잘 이해하는 것은 많은 무의식적 역량(unconscious competence)이 됩니다.”라고 말했습니다.

이러한 근육 기억(muscle memory)과 소프트웨어가 코드 수준에서 어떻게 작동하는지에 대한 암묵적 지식(tacit knowledge)을 구축하게 함으로써, 개발자들은 자신의 코드를 생성하고 개선하는 데 도움을 줄 도구를 신뢰할 수 있게 됩니다. 한편 AI 에이전트들은 더 빠르고, 더 불투명하며, 예측하기 어렵습니다. 당신은 코드가 아닌 모호한 언어를 사용하여 소프트웨어를 만듭니다. C++의 창시자인 Bjarne Stoustrup은 “코드는 해결책에 대한 정확한 진술이다”라고 말했습니다. 그는 또한 “영어는 모호해서는 안 되는 것을 표현하기에는 형편없는 언어다”라고 덧붙였습니다. 믿을 수 있는 도구는 예측 가능하고, 신뢰할 수 있습니다. 당신은 Emacs나 Vim으로 반복적으로 작업할 필요가 없습니다.

IDE(통합 개발 환경), 컨테이너화 도구, 정적 분석기 같은 대부분의 개발자 도구들은 경계가 어디인지 알고 있습니다. 각자의 역할이 있으며 그 범위를 벗어나지 않습니다. 하지만 AI는 SDLC(소프트웨어 개발 수명 주기) 툴체인 전체 영역으로 침투하고 있습니다. 이는 개발자들이 AI에 대해 느끼는 신뢰 감소가 프로세스 전체에 적용된다는 것을 의미합니다. 코드를 생성하는 것은 빠를 수 있지만, 이를 검증하고 개발자가 이것이 값비싼 프로덕션 실패를 유발하지 않을 것이라고 신뢰할 수 있는 지점까지 만드는 과정은 종종 더 오래 걸립니다.

도구는 프로세스를 인코딩하지만, 그것들을 고치지는 못한다

에이전트 기반 코딩 도구(Agentic coding tools)는 소프트웨어 개발 프로세스의 본질을 변화시킵니다. 이전 프로세스 주변에서 생겨난 도구들—린터(linter), 자동화된 단위 테스트(automated unit tests), CI/CD 등—은 이 변화된 프로세스와 함께 현재의 형태로 작동하지 않을 수 있습니다.

이러한 도구들은 프로세스를 인코딩했을 뿐, 그 자체가 프로세스는 아니었습니다. 훌륭한 CI/CD 도구가 더 빠르게 배포한다는 것을 의미하지 않았습니다. 훌륭한 IDE가 더 나은 코드를 작성한다는 것을 의미하지도 않았습니다. 스토리 포인트(story points)를 가진 이슈 추적 시스템이 노력을 잘 추정했다는 것을 의미하지도 않았습니다. 프로세스의 일부는 문화, 즉 소프트웨어를 구축하는 사람들의 행동과 규범으로 존재했습니다. 새로운 도구들은 종종 조직 문화를 변화시킨다는 것을 의미합니다.

이 이야기는 규모가 큰 엔지니어링 조직에서 일하는 누구에게나 익숙할 것입니다. 어떤 새로운 도구든, 아무리 많은 약속을 하더라도 기존의 문화와 프로세스에 맞지 않으면 실패할 수 있습니다. 성공적인 도구는 개발자들이 받아들이고 이해하는 방식으로 문화와 프로세스를 변화시키는 것을 필요로 합니다. 여러분은 무언가를 만들고 문제를 해결하는 것을 좋아하기 때문에, 그것을 더 잘하도록 돕지 못하는 도구는 무시됩니다.

Agentic coding이 빠르게 채택된 것은 개발자가 문제를 더 빨리 해결할 수 있게 해주었기 때문입니다. 하지만 코드를 생성하는 것이 거의 사소해지자 기존 프로세스의 많은 결함을 노출했습니다. 항상 불분명하고 변동하는 요구사항의 문제가 있었지만, 이제 문제를 해결하려면 '문제'와 '해결'이 무엇을 의미하는지 엄격하게 정의해야 합니다.

코드는 (거의) 무료일 수 있지만, 이를 검증하는 것은 그렇지 않습니다. 새로운 병목 현상은 코드 리뷰가 되었습니다. 예전 농담은 PR(Pull Request)을 빨리 승인받고 싶으면 100줄만 수정하라는 것이었습니다. 코딩 에이전트는 순식간에 수백 줄의 코드를 변경하고, 인간에게 검토할 (또는 형식적으로 승인할) 방대한 diff를 보냅니다. LLM-as-a-judge가 여기서 확장 가능한 해결책으로 발전하고 있지만, AI가 작성한 코드를 AI가 검토할 것이라고 신뢰하는 엔지니어링 방법론을 구축하는 데에는 노력이 필요합니다.

이와 같은 맥락에서, 코드를 실행하는 것도 무료가 아닙니다. 클라우드 네이티브 시대에 인프라 비용이라는 요소는 애플리케이션이 발생시키는 컴퓨트(compute), 메모리, 트래픽 볼륨의 비율입니다. 호스팅된 종속성 및 API의 비용도 있습니다. 그리고 예산 책정이 가장 어려운 실패의 비용, 즉 다운타임, 보안 침해, 기회비용이 있습니다. 이러한 비용들을 고려하지 못하거나 할 수 없는 소프트웨어를 생성하는 도구는 가치가 없을 수도 있습니다. 또한 이는 이전에 신뢰할 수 있고 안정적인 소프트웨어를 생산하던 프로세스에 부담을 줍니다.

많은 사람들에게 있어 에이전트 코딩(agentic coding) 덕분에 소프트웨어 개발 생명주기(SDLC)가 고장 난 것처럼 보이기 시작했습니다. 당연히 이러한 사람들은 그 균열을 메우기 위해 새로운 도구들, 즉 AI SRE, 자동화된 코드 리뷰, 메모리 및 컨텍스트 관리자, 제어 평면(control plane) 및 하네스 개선 등을 찾고 있습니다. 이 모든 것은 AI가 활성화된 소프트웨어 조직의 도구에 견고한 추가 요소입니다. 하지만 도구만으로는 문제가 해결되지 않을 것이며, 특히 문화와 프로세스가 변하지 않는다면 더욱 그렇습니다. 더 나은 도구가 있지만(사람들이 사용하지 않을 수도 있는) 프로세스 자체가 망가지면 여전히 망가진 것입니다.

더 나은 프로세스로 신뢰 구축하기

기존 SDLC에서는 제품 관리자(PM)가 자신의 연구, 고객 대화 및 경쟁사 이해를 바탕으로 기능 및 요구사항을 제시했습니다. 아키텍트(Architect)는 수년간의 경험과 기존 기술 스택에 대한 이해를 바탕으로 소프트웨어를 명세화했습니다. 엔지니어(Engineer)는 코드 로직과 기존 코드베이스에 대한 지식을 바탕으로 구축하고 커밋을 검토했습니다. QA는 소프트웨어가 어떻게 망가지는지에 대한 경험을 바탕으로 리뷰하고 부수려고 시도했습니다. 소프트웨어가 프로덕션 환경에 배포된 후에는 DevOps와 SRE가 이전의 경험을 바탕으로 성능과 사용 리소스를 모니터링하고 관리했습니다.

이 시스템에서 신뢰는 사람들과 함께 일하고, 그들이 어떻게 생각하는지 이해하며, 어느 한 개인이나 도구가 제멋대로 행동하여 시스템을 파괴할 수 있는 방식을 제한함으로써 구축되었습니다. AI가 활성화된 SDLC에서 신뢰를 구축하려면 이와 동일한 것들, 즉 사람들과 협력하고 그들이 책임감 있고 설명 가능하도록 보장하며, 작동하는 프로세스를 공유하고 반복적으로 개선하고, 실수의 가능성을 최소화해야 합니다.

첫 번째 단계는 인간을 책임 당사자로 확립하고 AI가 기여한 부분을 명시하는 것입니다. 모두가 ‘인간 개입형(human-in-the-loop)’에 대해 이야기하지만, Honeycomb의 CTO인 Charity Majors가 지적했듯이, “인간 개입형은 동정심 어린 초대처럼 들립니다. 제가 루프를 만들었고, 제가 루프를 소유하며, 이 루프가 존재하는 유일한 이유입니다. 이건 제 망할 루프예요!” 커밋을 푸시하는 사람이 그 코드를 소유합니다. PR(Pull Request)을 승인하는 사람들은 그 승인을 소유합니다. AI 이전 금요일에 프로덕션 환경(prod)을 고장 낸다고 해서 IDE를 탓하지 않았습니다. 만약 지금 고장 난다면, 문제는 에이전트가 아니라 키보드와 의자 사이에 있습니다.

AI 시대의 협업은 더 어렵고 생소한 일이 될 수 있습니다. 에이전트는 제품 요구 사항부터 코딩 에이전트를 통한 DevOps까지 모든 것을 수행함으로써 풀스택 개발자(fullstack developer)에 대한 아이디어를 확장하게 합니다. 개발자는 너무 쉽게 고립될 수 있습니다. Slack의 최고 제품 책임자(chief product officer)인 Jaime DeLanghe는 “설계 담당자에게 디자인에 대해 확인하지 않아도 됩니다. 방금 에이전트가 디자인을 만들었기 때문이죠.”라며, “특정 도메인의 다른 엔지니어와 협업하여 그들의 코드베이스를 이해할 필요도 없습니다. 그냥 에이전트에게 질문하면 되니까요. 이 경로로 너무 깊이 들어가서 거대한 PR을 만들 수도 있습니다.”라고 말했습니다.

일부 사람들은 모두가 댓글을 달고 프로세스를 수정할 수 있도록 공유된 공간에서 에이전트를 프롬프팅(prompting)하는 것을 제안했습니다. 다른 사람들은 모든 PR에 프롬프팅 과정의 스크립트(transcripts)를 포함해야 한다고 제안했습니다. 에이전트와의 대화에 대한 이러한 통찰은 그 코드가 어떻게 탄생했는지에 대해 더 큰 통찰력을 제공할 수도 있습니다. Cloudflare의 최고 기술 책임자(chief technology officer)인 Dane Knecht는 “PR을 열어 개발자가 어떻게 생각했고, 어떻게 문제 해결을 했는지 실제로 볼 수 있다는 것이 정말 멋집니다.”라고 말했습니다.

과거 프로세스가 접근 제어(access controls), 감사 추적(audit trails), diff 및 CI/CD 검사를 사용하여 실수로 인한 피해 범위를 제한했다면, 새로운 프로세스는 코드를 작성하기 전에 우연성을 제거해야 합니다. 이는 코드에 수행되기를 원하는 모든 것이 프롬프트에 명시적으로 기술되어야 함을 의미합니다. 이를 위해 spec.md 파일을 사용할 수 있지만, 지정되지 않은 것은 이제 빌드될 수 있습니다. Microsoft의 개발자 커뮤니티 VP인 Scott Hanselman은 “만약 무언가를 우연에 맡긴다면, 그것은 계속해서 우연에 맡겨질 것이다”라고 말했습니다. 그는 “이 작은 링 라이트 앱을 만들게 했는데, 저는 x64용으로 작업하고 있었습니다. ARM에서도 작동하게 하고 싶었기 때문에 'ARM 버전을 만들어줘'라고 알려줘야 했습니다. 그렇게 하지 않았다면 일어나지 않았을 것입니다.”라고 덧붙였습니다.

물론 필요한 모든 것을 기발한 프롬프트에 담을 수는 없습니다(그리고 그래선 안 됩니다). 그러면 반복하는 내용이 너무 많아지고, 회사 내부 지식으로 존재하는 몇 가지를 놓칠 가능성이 높습니다. 많은 똑똑한 사람들이 에이전트에게 더 나은 컨텍스트를 제공하고 장기 및 단기 메모리를 부여하는 방안을 고민하고 있습니다. 핵심은 에이전트가 필요로 하는 올바른 컨텍스트를 제공하는 것입니다. 일반적으로 이것은 선임 개발자들이 시간이 지나면서 얻는 노하우입니다. 하지만 에이전트는 여러분이 그 지식을 어딘가(예: Stack Internal)에 기록하고, 검증하며, 필요할 때 적절한 조각으로 서비스해야 합니다.

따라서 세상에서 가장 좋은 프롬프트를 갖게 되었습니다. 올바른 컨텍스트를 제공했고, 에이전트는 동료 검토를 통과하여 프로덕션(prod)에 배포된 무언가를 만들었습니다. 시스템에 대한 다음 점검은 그 기능 조각을 다시는 빌드하지 않는 것입니다. 완벽하게 좋은 소프트웨어 컴포넌트를 갖게 되었으니, 잃지 말고 재사용하세요. Bit의 수석 과학자인 Laly Bar-Ilan은 “DRY(Don’t Repeat Yourself, 반복하지 마라) 원칙이 우리의 주요 원칙입니다”라고 말했습니다. 그는 “오늘날 AI는 본질적으로 WET(Write Everything Twice, 모든 것을 두 번 쓰기)합니다. 이 개발자는 에이전트에게 '좋아, 버튼을 생성해줘'라고 지시하고, 에이전트는 기꺼이 그렇게 하고, 다른 팀의 또 다른 개발자가 그것을 요청하며, 코드베이스에 또 다른 버튼이 생깁니다.”라고 설명했습니다.