칼럼 | 토큰맥싱 시대, .exe 배포 시절의 실수 반복하나

필자가 개발자로 일한 지 오래된 덕분에, 애플리케이션 배포라고 하면 개발자 PC에 있는 .exe 파일을 그대로 운영 환경에 복사하던 시절도 기억한다. 과장이 아니다. 당시에는 정말 그 정도로 단순했다. 동시에 위험성도 매우 컸다.

그 시절의 애플리케이션은 지금처럼 복잡하지 않았다. 대부분은 단순한 .exe 파일 하나로 구성돼 있었다. 따라서 배포 과정 역시 복잡할 필요는 없었다. 하지만 돌이켜보면 좀 더 체계적이어야 했다.

애플리케이션을 올바르게 배포하는 방법은 오랜 시간에 걸쳐 업계가 배워온 경험의 산물이다. 오늘날 애플리케이션을 구축하고 테스트한 뒤 배포하는 과정이 복잡해진 데에는 두 가지 이유가 있다.

첫째, 모든 배포가 성공적으로 이뤄지도록 보장해야 하기 때문이다. 복잡한 애플리케이션의 배포는 여러 요소가 얽혀 있어 까다롭고 어려울 수 있다. 따라서 엄격한 배포 절차를 통해 모든 과정이 올바르게 수행되고 시스템이 정상적으로 동작하도록 해야 한다.

둘째, 애플리케이션을 충분히 검증해야 하기 때문이다. 다양한 구성 요소가 서로 유기적으로 작동해 애플리케이션이 의도한 기능을 제대로 수행하는지 철저히 테스트해야 한다.

오늘날의 지속적 배포(Continuous Deployment) 프로세스는 수많은 시행착오와 교훈을 통해 어렵게 정립된 결과물이다. 결국 이러한 관행은 공식적인 절차로 제도화됐으며, 나아가 사베인스-옥슬리법(Sarbanes-Oxley Act)에서도 IT 부서가 배포 프로세스를 공식적으로 문서화해야 하는 것으로 받아들여질 정도에 이르렀다.

이러한 거버넌스 체계야말로 전문적인 소프트웨어 개발 조직과 그렇지 못한 조직을 구분하는 기준이다. 다시 말해, 무엇을 하고 있는지 정확히 이해하는 조직과 그렇지 않은 조직을 가르는 요소라고 할 수 있다.

에이전트 개발의 성장통

에이전트 기반 개발도 결국 같은 방향으로 나아가고 있다. 다만 그 과정이 훨씬 더 빠르게 진행되고 있을 뿐이다.

불과 몇 달 전만 해도 개발자들이 AI를 본격적으로 코드 작성에 활용하기 시작한 단계였다. 처음에는 대부분 조심스럽게 접근했다. 클로드 코드(Claude Code)에게 버그를 찾아 수정하게 한 뒤, 결과물을 조용히 저장소에 반영하곤 했다. AI를 활용했다는 사실을 공개하는 데 다소 망설임도 있었다. 하지만 AI의 도움을 받고도 그 공을 자신이 가져가는 것에 부담을 느끼기 시작했고, 결국 이를 공개적으로 이야기하게 됐다.

그런데 얼마 지나지 않아, 정말 일주일도 채 되지 않아 클로드 코드가 충분히 실무에 활용할 만한 수준이라는 사실이 분명해졌다. 그때부터 개발자들은 AI 활용 사실을 훨씬 더 거리낌 없이 공유하기 시작했다.

이러한 변화는 순식간에 일어났다. AI 코딩은 단순히 허용되는 수준을 넘어 적극 권장되는 분위기로 바뀌었고, 개발자들은 앞다퉈 이를 활용하기 시작했다. 한 달도 채 되지 않아 모두가 이른바 ‘토큰맥싱(tokenmaxxing)’에 몰두하는 상황이 됐다.

하지만 지금의 모습은 다소 통제 불능 상태처럼 보이기도 한다. 엄청난 양의 코드가 생성되고 있고 적지 않은 비용도 투입되고 있지만, 그 결과가 과연 그만한 가치가 있는지는 명확하지 않다. 실제로 지출한 비용이 기대한 수준의 성과를 돌려주고 있다고 자신 있게 말할 수 있는 사람이 얼마나 될지도 의문이다.

결국 업계는 어느 시점에서 이 모든 것을 통제할 방법을 찾아야 할 것이다. 문제는 그 과정에서 성급하게 거버넌스를 도입하려는 움직임이 나타날 수 있다는 점이다. 이는 과거 운영 환경에 *.exe 파일을 직접 복사해 배포하던 방식만큼이나 위험한 일이다.

현재는 어떤 도구가 어디에서 사용되고 있는지, 어떤 목적으로 얼마의 비용이 지출되고 있는지, 그리고 그 비용이 실제로 어떤 결과를 만들어내고 있는지에 대한 통제가 거의 이뤄지지 않고 있는 것으로 보인다.

과거 배포 프로세스에 대한 거버넌스가 성공적으로 자리 잡을 수 있었던 이유는 그것이 자연스럽게 형성됐기 때문이다. 실제 현업 개발자들이 애플리케이션을 구축하고 배포하면서 얻은 경험과 교훈이 업계 표준으로 정착됐다. 에이전트 코딩 역시 같은 과정을 거쳐야 한다.

개발자가 가장 잘 안다

에이전트 코딩이 너무 빠르고 광범위하게 확산되고 있다는 점이 문제다. 그 결과 거버넌스 역시 같은 속도로 위에서 아래로 강제될 위험이 있다.

지금은 잠시 속도를 늦추고 우리가 무엇을 하고 있는지, 그리고 무엇보다 어떤 방식으로 하고 있는지를 면밀히 살펴봐야 할 시점이다.

에이전트 코딩은 어떤 형태로든 결국 관리와 통제를 받게 될 것이다. 중요한 것은 현업 실무자들이 그 거버넌스 수립을 주도해야 한다는 점이다. 그렇지 않으면 외부에서 정한 규칙이 현장에 강요될 수 있다.

무엇이 중요한지, 도구를 어떻게 활용해야 하는지를 가장 잘 아는 사람은 개발자다. 또한 결과에 직접 책임을 지는 사람도 개발자이며, 기술 발전 속도를 가장 가까이에서 따라가고 있는 사람 역시 개발자다.

이처럼 빠르게 발전하는 기술을 상향식 참여 없이 하향식으로 통제하는 방식은 결코 변화를 따라갈 수 없다.

SaaS 관리 플랫폼 기업 토리(Torii)의 공동 설립자 겸 CEO인 우리 하라마티(Uri Haramati)는 다음과 같이 설명했다.

“도구와 가장 가까이 있는 사람이 대개 그 도구가 왜 사용되는지를 가장 잘 이해한다. 거버넌스는 그들을 통제하려 하기보다 그들을 의사결정 과정에 포함할 때 더 효과적으로 작동한다.”

운영 환경에 .exe 파일을 직접 복사해 배포하는 방식은 지금 기준으로 보면 무모할 정도로 위험한 행동이다. 우리는 더 이상 그런 방식을 사용하지 않는다. 더 나은 방법을 알고 있기 때문이다.

그 과정에는 시간이 필요했지만, 결국 업계는 소프트웨어를 올바르게 배포하는 방법을 배웠다. 지금 우리는 에이전트 코딩의 ‘운영 환경에 .exe 파일을 직접 복사하던’ 단계에 와 있다. 그리고 누군가가 대신 규칙을 만들기 전에, 개발자 스스로 올바른 활용 방식을 찾아야 한다.
dl-ciokorea@foundryco.com