에이전트가 풀스택 앱을 혼자 만든다—그래서 우리는 뭘 해야 하나
음성 프롬프트 하나로 멀티에이전트가 병렬로 깨어난다. DevOps 서브에이전트가 Docker Compose를 구성하고, QA 에이전트가 테스트를 작성하는 동안, 또 다른 에이전트가 앱을 다섯 개 언어로 동시에 현지화한다. Google의 Antigravity 2.0을 소개한 Agent Factory 에피소드에서 Rody Davis가 시연한 장면이다. 이게 데모가 아니라 이미 누군가의 일상 워크플로우라면, 팀 리드로서 지금 당장 물어봐야 할 질문은 하나다. 이 팀에서 개발자는 정확히 무엇을 해야 하는가.
100X는 과장이 아니다—단, 조건이 있다
Rody Davis가 말하는 100X 엔지니어링의 핵심은 속도 자체가 아니다. 그는 '인지적 수고(cognitive toil)'를 줄이는 것을 목표로 삼는다. 마케팅 사이트 빌드, 보일러플레이트 핸드셰이크, 반복적인 파일 스캐닝 로직—이런 것들을 에이전트에 넘기고, 자신은 아키텍처와 문제 정의에 집중한다. ZeroBin을 혼자 만든 개발자도 같은 패턴을 보고한다. Tauri v2와 Rust로 4MB짜리 디스크 클리너를 솔로 개발하면서, Antigravity를 "아키텍처 협업자"로 활용해 WiX/NSIS 인스톨러 스크립트 디버깅처럼 막히는 구간을 돌파했다. 두 사례 모두 에이전트가 반복 작업을 흡수한 덕분에 인간 개발자가 더 높은 레이어에 집중할 수 있었다.
단, 조건이 있다. Rody는 "코드베이스 건강 상태가 나쁜 것이 컨텍스트 윈도우 크기보다 훨씬 큰 병목"이라고 잘라 말한다. 에이전트가 파일을 잘못된 위치에 놓는 순간 즉각 감지할 수 있으려면, 아키텍처가 먼저 단순하고 명확해야 한다. 그는 이를 분재 가지치기(Bonsai pruning)에 비유한다. 복잡한 코드베이스 위에서는 100X가 아니라 10X 혼돈이 된다.
Pragmatic Programmer가 AI 시대에 더 날카로워지는 이유
The Pragmatic Programmer를 AI 시대에 다시 읽은 개발자의 분석은 이 논점을 다른 각도에서 확인해준다. 저자들이 1999년에 쓴 문장—"요구사항을 간결하게 기술해서 소프트웨어를 생성하는 컴파일러는 아직 없다"—은 이제 틀렸다. LLM이 그 역할을 하고 있다. 하지만 책의 나머지 원칙들은 오히려 더 중요해졌다.
직접적극적인 증거가 하나 있다. 프론트엔드 경험이 부족한 백엔드 개발자가 AI 도움으로 목업에 맞는 UI를 만들었다. 기능 요구사항은 전부 충족했다. 그런데 시니어 프론트엔드 엔지니어들이 코드 리뷰에서 제동을 걸었다—코드베이스의 확립된 패턴을 전부 무시한 코드였다. 개발자 본인은 그 문제를 알아볼 능력 자체가 없었다. AI가 생성한 코드의 품질을 판별하는 능력은 결국 그 도메인의 깊이에서 나온다.
직교성(Orthogonality)과 DRY 원칙은 AI 시대에 더 엄격한 전제조건이 됐다. 인터페이스와 책임 경계가 모호하면, 에이전트는 비즈니스 로직을 서비스와 모듈 전역에 신뢰성 있게 복제·분산시킨다. 지도감독 없이 AI에게 구현을 맡길수록, 인간이 설계한 경계의 명확성이 결과물의 품질을 결정한다.
팀 리드가 지금 당장 재정의해야 할 세 가지
세 개의 현장 사례가 공통으로 가리키는 지점을 팀 리드 관점에서 정리하면 이렇다.
첫째, 개발자의 핵심 역량을 '구현'에서 '판단'으로 재정의하라. Rody는 "API 계약과 스키마에 대해서는 깊이 신경 쓴다"고 말한다. 마케팅 사이트의 비주얼 아웃풋은 에이전트 판단에 맡기지만, 백엔드 인터페이스 설계는 자신이 직접 첫 예시를 작성하고 에이전트가 패턴을 복사하게 한다. 무엇을 에이전트에 위임하고 무엇을 직접 쥘지—이 판단 자체가 이제 핵심 엔지니어링 역량이다.
둘째, 테스트 설계의 사고권을 AI에 넘기지 마라. Pragmatic Programmer 분석이 가장 날카롭게 지적한 부분이다. "테스트 커버리지 추가해"라고 에이전트에게 시키면 테스트는 생긴다. 하지만 "이 코드가 무엇을 보장해야 하는가"라는 설계 질문은 건너뛴 채. 테스트를 작성하는 행위는 AI에 맡겨도 되지만, 무엇을 검증할지 결정하는 행위는 여전히 사람의 몫이다.
셋째, Skills와 컨텍스트 설계를 팀 자산으로 만들어라. Rody는 Skills를 "에이전트를 위한 컨텍스트 치트시트"라고 부른다. 디자인 시스템, API 문서, 코드베이스 컨벤션—이것을 에이전트가 즉시 활용 가능한 구조화된 형태로 만드는 것이 팀의 경쟁력이 된다. 이는 단순한 문서화가 아니라, AI와 인간이 함께 운영할 수 있는 워크플로우 설계다.
100X 이후: 개발자가 쌓아야 할 직관의 문제
하나의 불편한 질문이 남는다. AI가 구현의 상당 부분을 가져가면, 다음 세대 개발자들은 무엇으로 직관을 쌓는가. Rody 본인도 "Go의 문법이 좋고, 컴퓨터를 직접 제어하는 도전이 좋아서 여전히 손으로 코드를 쓴다"고 답한다. 2년 뒤 문제가 생겼을 때 "어느 예전 프로젝트를 참조해야 하는지" 알려면, 그 경험이 먼저 쌓여 있어야 한다는 것이다.
Pragmatic Programmer 분석이 제기한 질문도 같다. "생성된 코드를 리뷰하면서 기르는 직관은, 직접 코드를 쓰면서 기르는 직관과 같은가." 아직 답이 없는 질문이다. 다음 세대 개발자들은 아키텍처, 분해, AI 아웃풋 판단에 특화된 다른 종류의 직관을 키울 수도 있다. 하지만 그 직관이 지금의 구현 경험을 대체할 수 있는지는, 우리가 직접 실험하면서 확인해야 한다.
지금 팀 리드가 해야 할 일은 이 불확실성을 회피하는 게 아니다. 에이전트에 위임할 영역과 개발자가 반드시 직접 경험해야 할 영역을 의도적으로 설계하는 것이다. 100X 엔지니어링은 개발자를 대체하지 않는다—판단 능력 없이 도구만 쥔 개발자를 대체한다.