AI 에이전트가 코드의 대부분을 작성하는 팀이 10배 처리량을 달성하면서 드러난 품질·배포·협업의 병목을 분석하고, 전체 시스템 로컬 테스트와 페이크 의존성, 더 빠른 CI/CD, 저비용 조정 메커니즘 등으로 ‘에이전틱 개발’의 새로운 셈법을 제시한다.
지난 3개월 동안, 경험 많고 뜻이 맞는 엔지니어들과 저는 Amazon Bedrock 안에서 정말 멋진 것을 만들어 왔습니다. 우리가 만드는 것 자체도 무척 기대되지만, 우리 팀에는 또 다른 특징이 있습니다 — 우리의 대부분 코드는 Amazon Q나 Kiro 같은 AI 에이전트가 작성합니다. 눈을 굴리기 전에: 아니요, 우리는 '바이브 코딩'을 하지 않습니다. 그런 방식이 견고한 소프트웨어를 만드는 올바른 길이라고 믿지 않습니다.
대신, 우리는 사람과 AI 에이전트가 협업해 코드 변경을 만들어내는 접근을 씁니다. 우리 팀에서 모든 커밋에는 엔지니어의 이름이 붙고, 그 엔지니어가 최종적으로 코드를 리뷰하고 책임집니다. 우리는 스티어링 규칙을 사용해 AI 에이전트가 우리 코드베이스 안에서 어떻게 동작해야 하는지에 대한 제약을 설정하고, 러스트로 작성하는 것은 큰 장점이었습니다. 러스트 컴파일러는 정확성과 안전성에 집중하기로 유명해서, 컴파일 타임에 많은 문제를 잡아 내고 에이전트가 반복하기 쉽게 도와주는 유용한 에러 메시지를 제공합니다. '바이브 코딩'과 대비해 저는 '에이전틱 코딩(agentic coding)'이라는 용어를 선호합니다. 덜 자극적이지만, 우리 업계에서는 대체로 재미없어 보이는 것이 좋은 경우가 많습니다.
저의 경우, 요즘 제가 커밋하는 코드의 대략 80%는 AI 에이전트가 씁니다. 제 개인 워크플로우는 이렇습니다: 작업을 제 머릿속에서 명확해질 때까지 쪼갠 다음(대개 접근을 탐색할 때 AI를 함께 사용), AI 에이전트를 프롬프트하고, 결과를 리뷰하고, 마음에 들 때까지 에이전트와 함께 반복하며, 가끔은 변경 세트를 제가 직접 이어 받아 마무리합니다. 저는 에이전트가 만들어내는 코드 한 줄 한 줄에 주의를 기울이고, 내가 완전히 만족할 때까지는 받아들이지 않습니다 — 마치 내가 직접 모든 줄을 쓴 것과 다르지 않습니다.
저는 늘 효율적인 코더였고, 지난 몇 년 동안 코딩에 쓸 수 있었던 시간이 제한적이었음에도 시간을 쪼개 코드를 써 왔습니다. 그리고 지난 몇 달은 제 커리어에서 가장 높은 코딩 처리량을 기록한 기간이었습니다. 우리 팀도 다르지 않습니다 — 우리는 전형적인 고속 팀의 10배 속도로 코드를 생산하고 있습니다. 과장이 아닙니다 — 실제로 지표를 수집하고 분석했습니다.
여기서부터가 흥미로워집니다. 전형적인 소프트웨어 팀, 심지어 숙련된 팀이라도 항상 정답을 맞히지는 못합니다. 좋은 테스트와 엔지니어링 관행이 있어도 버그는 가끔 새어 나옵니다. '프로덕션에서 테스트한다'는 말을 우리 모두 들어 봤을 겁니다. 이런 현실 때문에 저는 항상 테스트에만 집중하는 것으로는 충분하지 않다고 믿어 왔고, 피해 반경과 복구 시간을 개선하는 데 투자하는 것이 똑같이 중요하다고 생각했습니다.
AI가 보조한 코드도 다르지 않습니다. 사람이 철저히 리뷰했더라도 버그가 들어갈 수 있고, 그 확률은 크게 다르지 않다고 생각합니다. 하지만 팀이 커밋을 10배 속도로 배포하기 시작하면 전체 수학이 달라집니다. 과거에는 1년에 한두 번 일어나던 프로덕션 영향 버그가 주간 단위로 바뀔 수 있습니다. 대부분의 버그가 통합이나 테스트 환경에서 잡힌다 해도, 공유 코드베이스에는 영향을 주어 조사 비용을 발생시키고 팀의 나머지 작업을 느리게 만듭니다. 이 역시 과장이 아닙니다 — 우리 팀은 처리량이 계단식으로 뛰어오를 때 이런 종류의 문제가 생기는 신호를 실제로 보고 있습니다.
저는 점점 확신합니다. 에이전틱 개발이 엔지니어링 속도를 한 자릿수(10배) 높이려면, 문제적 커밋이 발생할 확률을 역시 한 자릿수(10배) 줄여야 한다고요. 아마 그보다 더 줄여야 할지도 모릅니다. 높은 속도에서는 개별 커밋들이 서로 예상치 못한 방식으로 상호작용하기도 하니까요.
다시 말해, 시속 200마일로 달릴 때는 차를 트랙 위에 붙잡아 둘 엄청난 다운포스가 필요합니다!
버그 가능성을 줄이는 가장 좋은 방법 중 하나는 테스트를 개선하는 것입니다. 저는 항공기 덕후라서 항공기 제조사들이 사용하는 테스트 아이디어를 늘 존경해 왔습니다. 초기 시뮬레이션부터, 구성품 테스트, 풍동 테스트, 파손될 때까지의 한계 시험, 그리고 최종적으로 완전 조립 기체의 시험 비행까지. 심지어 비행 시뮬레이터도 업계 전반의 안전을 높이는 데 역할을 합니다. 이런 아이디어들 중 일부는 소프트웨어 산업에서도 시도되었지만, 아직 보편적이지는 않습니다.
예를 들어, 저는 제어된 환경에서 완전히 조립된 시스템을 시험하는 '풍동' 스타일의 테스트를 늘 좋아했습니다. 이를 위해 제가 사용해 온 한 가지 패턴은 로컬에서 실행할 수 있는 외부 의존성의 고충실도 '페이크'(모의) 구현을 만드는 것입니다. 이렇게 하면 빌드 타임 테스트를 로컬에서 실행해 시스템 전체의 E2E 동작을 검증할 수 있습니다. 더 나아가, 페이크 의존성에 예상치 못한 동작이나 실패를 주입해 시스템이 그것을 어떻게 처리하는지도 시험할 수 있습니다. 이런 테스트는 로컬에서 돌아가기 때문에 작성과 실행이 쉽고, 컴포넌트 사이 이음새에 숨어 있는 교묘한 버그를 잡아내는 데 아주 유용합니다.
안타깝게도, 적당히 복잡한 서비스의 모든 외부 의존성을 페이크로 만드는 일은 항상 쉬운 것이 아닙니다. 설령 만들었다 해도, 이제는 실제 의존성이 진화할 때 그에 발맞춰 유지해야 하는 책임이 생깁니다. 이런 이유로 제 경험상 대부분의 팀은 그런 테스트를 작성하지 않습니다.
저는 에이전틱 코딩이 여기서의 셈법을 바꾸고 있다는 초기 징후를 보고 있다고 생각합니다. AI 에이전트는 원하는 동작이 널리 알려져 있고 모호함이 적을 때 대량의 코드를 쏟아내는 데 탁월합니다. 원칙적으로는 타당했지만 구현·유지 비용 때문에 미뤄졌던 아이디어들의 비용이 한 자릿수(10배) 낮아졌습니다. 저는 업계의 이런 변곡을 타는 것을 정말 좋아합니다. 과거에는 실용적이지 않았던 접근들이 문을 열기 때문입니다.
우리 프로젝트는(AI 에이전트의 도움을 받아) 인증, 스토리지, 체인 리플리케이션, 추론 엔진 같은 외부 의존성의 페이크 구현을 테스트에서 사용할 수 있도록 유지합니다. 그리고 그 페이크들을 이용해 개발자 머신에서 우리 전체 분산 시스템, 즉 모든 마이크로서비스를 띄우는 테스트 하니스도 만들었습니다. 빌드 타임 테스트는 그 완전 조립 스택을 대상으로 카나리아를 띄워, 시스템 전체가 제대로 동작하는지 검증합니다.
이 접근이 과거에는 변경이 커밋되어 테스트 환경까지 올라가야만 잡을 수 있었던 카테고리의 버그를 잡아 줄 것이라 저는 매우 낙관적입니다. 불과 몇 년 전만 해도 이런 아이디어는 좋지만 너무 비싸다는 이유로 저항을 받았을 겁니다. 하지만 이번에는 비교적 복잡한 시스템임에도 며칠 만에 구현할 수 있었습니다.
결국 이 모든 변화는 고객 가치를 전달하기 위해 빌드·테스트·배포되어야 합니다. 소프트웨어 팀의 CI/CD 파이프라인이 빌드, 패키징, 테스트에 몇 시간이 걸리는 것은 흔한 일입니다. 그런 파이프라인은 배치된 변경 묶음을 프리프로덕션 단계를 거쳐 프로덕션 단계까지 롤아웃하는 데 며칠이 걸릴 수 있습니다. 보통 그 정도 자동화를 갖춘 팀이라면 건강한 팀으로 간주됩니다.
에이전틱 코딩은 이 역학을 바꿉니다. 한 묶음의 커밋을 빌드·패키징·테스트하는 데 걸리는 시간 동안, 또 다른 수십 개가 나갈 준비를 하고 있을 수 있습니다. 프로덕션 배포 준비가 끝날 즈음이면 변경 세트에 커밋이 100개 이상 들어 있을 수도 있습니다. 그중 하나라도 문제가 있으면 배포를 롤백해야 하고, 파이프라인은 멈춰 섭니다. 그 사이에 더 많은 변경이 쌓여 혼란과 위험은 더 커집니다.
저는 F1 팬인데, 이 상황은 트랙에서 사고가 나 옐로 플래그가 올라가는 것을 떠올리게 합니다. 평소에는 차들이 엄청난 속도와 가속도로 트랙을 질주합니다. 하지만 사고가 발생하면 레이스 마샬이 옐로 플래그를 올리고, 모든 차는 페이스카 뒤에서 속도를 줄여야 합니다. 흥미진진한 레이스가 트랙 잔해가 치워지고 안전이 확보될 때까지 한가로운 주행으로 바뀝니다. 이런 감속을 최소화하기 위해 대회 운영진은 온갖 유형의 사고에 대비하고, 트랙을 몇 분 만에 치우고 레이스를 재개할 수 있도록 세심하게 준비합니다.
전체 시스템 로컬 테스트가 특정 버그를 잡는 피드백 루프를 조밀하게 하는 데 도움이 되는 것처럼, CI/CD 파이프라인을 구현하는 방식도 비슷하게 다시 생각해야 할 수 있습니다. 팀이 시간당 수십 개 커밋의 속도로 움직인다면, 문제를 분 단위로 식별·격리·되돌릴 수 있어야 합니다. 즉, 전형적인 빌드·테스트 인프라는 지금보다 한 자릿수(10배) 더 빨라져야 합니다. 온라인 게임에서 입력과 반응 사이의 지연이 크면 플레이가 불가능해지는 것처럼, 커밋마다 피드백을 보기까지 긴 지연이 남아 있다면 10배 속도로 움직이기는 정말 어렵습니다.
저는 잘 운영되는 오퍼레이션을 관찰하는 것을 좋아합니다. 붐비는 레스토랑의 막후를 엿보면, 처음에는 혼돈처럼 보일 수 있습니다. 하지만 잠시만 자세히 보면 모든 구성원이 끊임없이 서로를 조율하고 있음을 알 수 있습니다. 셰프, 요리사, 홀 스태프, 버서, 매니저가 정보를 끊임없이 주고받습니다. 항상 동기화된 상태를 유지함으로써, 잘 운영되는 레스토랑은 피크 타임에도 품질이나 지연을 희생하지 않고 손님을 응대합니다.
소프트웨어 팀의 속도를 비슷하게 높이려면 팀이 커뮤니케이션하는 방식에 제약을 두는 것이 필요하다고 믿습니다. 처리량이 한 자릿수(10배) 증가하면, 단지 더 많은 코드를 쓰는 것만이 아니라 더 많은 결정을 내리게 됩니다. 이 캐싱 전략을 쓸까, 저 전략을 쓸까? 이 엣지 케이스는 어떻게 처리할까? 여기서 옳은 추상화는 무엇일까? 정상 속도에서는 팀이 이런 결정을 일주일에 한두 번 내릴지 모릅니다. 10배 속도에서는 하루에도 여러 번 내리게 됩니다.
문제는 이런 결정들 가운데 상당수가 다른 사람들이 하고 있는 일에 영향을 준다는 것입니다. 엔지니어 A가 인증 플로우를 리팩터링하기로 결정하면, 엔지니어 B가 확장하려던 API에 영향을 줍니다. 이는 단지 구현 세부사항이 아니라 코드베이스 전반으로 파문을 일으키는 아키텍처적 선택입니다.
전통적인 조정 메커니즘은 여기서 지연을 너무 많이 유발한다고 느낍니다. 슬랙 답변을 기다리거나, 당일 나중에 짧은 싱크를 잡는 것은 병목을 만들거나 — 결정이 진행을 막거나 — 갈등을 뒤늦게 깨닫기 전까지 잘못된 길로 가게 만들 위험을 낳습니다. 높은 처리량에서는 조정 비용이 오히려 지배할 수 있습니다!
한 가지 접근은 조정을 없애는 것입니다 — 모두가 독립적인 컴포넌트만 작업하면 조정할 필요가 줄어들죠. 하지만 저는 그 이상향이 대부분의 현실 세계 시스템에서는 비실용적이라고 봅니다. 그래서 다른 대안은 조정 비용을 대폭 낮추는 것입니다. 우리 팀은 같은 층에 모여 앉는데, 이것이 우리 속도에 결정적이었다고 생각합니다. 누군가 다른 사람들에게 영향을 줄 수 있는 결정을 해야 하면, 자리에서 일어나 화이트보드 앞에서 몇 분 만에 머리를 맞대고 결론을 냅니다. 우리는 접근에 정렬하고, 트레이드오프를 실시간으로 논의하고, 두 엔지니어는 각자 일로 돌아갑니다. 결정은 빠르고 정확하게 내려지고, 막힌 일이 쌓이지 않습니다.
물론 이 방식이 분산 팀의 문제를 해결하지는 못합니다 — 그건 여전히 열린 과제입니다.
저는 에이전틱 개발의 잠재력에 정말 흥분됩니다. 이것이 소프트웨어 개발의 효율을 높이는 것을 넘어, 이전에는 너무 틈새이거나 비용이 많이 들어 해결하지 못했던 문제들까지 다룰 수 있게 해 준다고 생각합니다. 성과는 실재합니다 — 우리 팀의 10배 처리량 증가는 이론이 아니라 측정 가능합니다.
하지만 핵심은 이것입니다: 기존 개발 관행 위에 AI 에이전트를 그냥 덧대는 것만으로는 이런 성과가 나타나지 않습니다. 마치 좁은 타이어와 낡은 브레이크를 단 자동차에 터보차저만 올리는 것과 같습니다. 결과는 더 빠른 랩타임이 아니라 사고일 겁니다. 코드 속도가 10배가 되면, 우리가 지금 쓰는 테스트, 배포, 팀 조정 방식이 한계가 됩니다. 병목은 단지 자리를 옮길 뿐입니다.
이는 우리가 소프트웨어를 만드는 방식을 근본적으로 다시 생각해야 함을 뜻합니다. 하루 10건 커밋을 위해 설계된 CI/CD 파이프라인은 100건에서 버거워집니다. 정상 속도에서는 '충분히 좋았던' 테스트 전략이 고속에서는 너무 많은 버그를 통과시킬 것입니다. 예전에는 잘 작동하던 커뮤니케이션 패턴이 끊임없이 막힌 일을 만들어낼 것입니다.
좋은 소식은, 포괄적 테스트, 빠른 배포, 효율적 조정을 위한 훌륭한 아이디어가 이미 있다는 것입니다 — 가능성이 입증되었지만 구현·유지 비용 때문에 널리 채택되지 못했던 아이디어들 말이죠. 달라진 점은, 에이전틱 개발 자체가 그 비용을 극적으로 낮출 수 있다는 것입니다. 코드 처리량을 높여 주는 그 AI 에이전트가, 그 처리량을 지속시키는 데 필요한 인프라를 구축하는 데도 도움을 줄 수 있습니다.
진짜 기회는 이것입니다: 단지 더 많은 코드를 빨리 쓰는 것이 아니라, AI를 사용해 이전에는 실용적이지 않았던 엔지니어링 실무를 실용적으로 만드는 것. 에이전틱 개발로 성공할 팀은 소프트웨어 개발 라이프사이클 전체가 보조를 맞춰 함께 진화해야 한다는 사실을 깨닫는 팀일 것입니다.
