The New Software Lifecycle
TMTAI가 소프트웨어 라이프사이클을 어떻게 바꾸고 있는지에 대한 Google 백서를 공동 집필했습니다. 여기서 그 전체 내용을 요약할 생각은 없습니다. 대신, 그중에서 제가 정말 중요하다고 생각하는 몇 가지 아이디어를 추려 공유하고, 자유롭게 재사용하실 수 있는 6개의 도표를 함께 소개합니다.
Google은 이번 주에 The New SDLC With Vibe Coding을 공개했습니다. 저는 Shubham Saboo, Sokratis Kartakis와 함께 이 문서를 공동 집필했고, 이 글은 짧은 시리즈의 첫 번째입니다.
이 문서는 1일 차(Day 1)용 백서라 앞부분에서는 기본 개념을 다룹니다. 에이전트가 무엇인지, “vibe coding”이 무엇인지, 그리고 개발자의 역할이 코드를 “작성”하는 일에서 “판단”하는 일로 어떻게 옮겨가고 있는지 같은 내용들입니다. 이 블로그를 늘 읽어 오셨다면 이런 기본 내용은 이미 알고 계실 겁니다. 그래서 저는 이 부분은 건너뛰고, 여러분의 시간을 들일 만한 포인트들만 짚어 보려고 합니다. 그리고 논문에 실린 도표 6개를 따로 떼어 소개합니다. 마음껏 가져다 쓰셔도 됩니다.
에이전트는 모델 + 하니스다
이 논문에서 제가 계속 곱씹게 되는 표현이 있습니다. 에이전트는 모델과 하니스(harness)의 결합이라는 관점입니다.
모델은 하나의 입력일 뿐입니다. 나머지 모든 것이 하니스입니다. 지침과 규칙 파일, 도구와 MCP 서버, 에이전트가 돌아가는 샌드박스, 서브 에이전트를 생성하고 모델 간 라우팅을 담당하는 오케스트레이션 로직, 특정 시점에 결정론적 코드를 실행시키는 훅, 에이전트가 어디로 벗어나고 있는지 알려 주는 관측·모니터링까지 모두 포함됩니다. 논문에서는 대략적인 비중을 모델 10%, 하니스 90% 정도로 나눕니다. 이런 비율이 과하게 들릴 수도 있지만, 일주일 정도만 에이전트를 디버깅해 보면 충분히 납득이 됩니다.
모델이 엔진이라면, 하니스는 자동차 전체이자 도로이고, 교통 법규에 가깝습니다.
이것을 구체적으로 보여 주는 공개 숫자들도 몇 가지 있습니다. Terminal Bench 2.0에서 어느 팀은 동일한 모델을 유지한 채 하니스만 바꿔서, 코딩 에이전트의 순위를 상위 30위 밖에서 상위 5위 안으로 끌어올렸습니다. LangChain에서 진행한 다른 실험에서는, 역시 모델은 그대로 둔 채 시스템 프롬프트, 도구, 미들웨어만 바꾸어 같은 벤치마크 점수를 13.7포인트 끌어올렸습니다. 두 경우 모두 모델 자체는 건드리지 않았습니다.
그래서 이제는 에이전트가 멍청한 짓을 하면, 저는 우선 하니스부터 들여다보게 되었습니다. 대부분은 빠진 도구가 있거나, 제가 너무 느슨하게 적어 둔 규칙이 있거나, 깜빡하고 넣지 않은 가드레일이 있거나, 쓸모없는 내용으로 가득 찬 컨텍스트 창이 원인입니다. 에이전트가 실패하는 이유 상당수는 결국 설정 문제입니다. 저는 이게 오히려 반갑습니다. 설정은 오늘 당장 제가 고칠 수 있는 부분이기 때문입니다. 더 나은 모델을 기다릴 필요가 없습니다. 어차피 모델은 언젠가 하니스 아래에서 갈아끼워질 테니까요. 저는 이런 내용을 좀 더 길게 harness engineering과 factory model 글로 풀어 쓴 바 있습니다.
컨텍스트 엔지니어링이 요금을 결정한다
하니스가 시스템 전체라면, 그 안에서 가장 중요한 조절 장치는 컨텍스트 엔지니어링입니다. 논문에서는 에이전트 컨텍스트를 여섯 가지 유형으로 나눕니다. 지침(instructions), 지식(knowledge), 메모리(memory), 예시(examples), 도구(tools), 가드레일(guardrails). 그리고 여기서 진짜 중요한 결정, 즉 실제 비용에 반영되는 부분은 무엇을 정적 컨텍스트에 두고 무엇을 동적 컨텍스트로 두느냐입니다.
좋은 시스템일수록 이 경계를 아키텍처의 1급 결정으로 다루며, 코드처럼 리뷰와 버전 관리를 한다
정적 컨텍스트는 매 턴마다 항상 불러오므로 신뢰할 수 있지만 비싸고, 동적 컨텍스트는 필요할 때만 불러오므로 각 작업이 실제로 필요한 만큼만 비용을 지불하게 됩니다.
정적 컨텍스트는 매번 함께 로드됩니다. 시스템 지침, 규칙 파일(AGENTS.md, CLAUDE.md, GEMINI.md), 전역 메모리, 핵심 가드레일 같은 것들입니다. 신뢰도는 높지만 비쌉니다. 매 호출마다 비용을 내야 하기 때문입니다. 동적 컨텍스트는 필요할 때만 로드됩니다. 작업과 매칭되면 작동하는 스킬, 도구 실행 결과, RAG로 가져온 문서 등이 여기에 포함됩니다. 특정 작업이 실제로 사용한 부분만 비용을 내면 됩니다.
이 균형을 한쪽으로 과하게 기울이면 토큰을 태워 버리면서 중요한 신호까지 묻혀 버립니다. 반대쪽으로 잘못 맞추면 에이전트가 안전을 책임지는 규칙들을 잊어 버립니다. 논문에서 제안하는 조언, 그리고 저도 동의하는 부분은 이 경계를 진짜 아키텍처 결정으로 다루라는 것입니다. 풀 리퀘스트에서 리뷰하고, 코드처럼 버전 관리하라는 뜻입니다.
동적 컨텍스트를 규모 있게 확장 가능하게 만들어 주는 핵심 요령은, 점진적 공개(progressive disclosure)를 갖춘 Agent Skills입니다. 에이전트는 시작할 때는 각 스킬의 짧은 메타데이터만 보고, 작업이 맞아떨어지면 그때서야 전체 지침을 로드하고, 정말로 참조가 필요할 때에만 무거운 레퍼런스 문서를 끌어옵니다. 이렇게 해야 하나의 에이전트가 수십 개의 스킬을 품고 있으면서도, 실제로 쓰는 스킬 하나에 대해서만 비용을 지불할 수 있습니다.
검증이 vibe coding과 엔지니어링을 가르는 기준선이다
같은 에이전트를 두고도, 여러분은 vibe coding부터 에이전트 기반 엔지니어링까지 어떤 지점에든 설 수 있습니다. 어느 쪽에 더 가까운지는 검증(verification)을 어떻게 하느냐에 따라 갈립니다.
어느 지점이 적절한지는 업무의 중요도에 따라 달라집니다. 각 작업마다 어느 선에서 선을 그을지 아는 것이 실력입니다.
검증에는 두 가지 메커니즘이 있습니다. 테스트는 결정론적 부분을 다룹니다. 이 입력이 들어오면 저 출력이 나와야 하는 식입니다. 평가(evals)는 결정론적이지 않은 부분을 다룹니다. 논문에서는 이 평가를 두 가지로 나누는데, 저는 이 구분이 꽤 유용하다고 느꼈습니다. 최종 결과가 맞는지를 보는 Output evaluation과, 에이전트가 거기까지 가는 동안의 경로, 즉 도구 호출과 추론 과정이 타당했는지를 보는 Trajectory evaluation입니다. 둘 다 필요합니다. 겉으로 보기에는 맞는 것 같지만 검증 절차를 슬쩍 건너뛴 답변은, 아예 깨져 있는 답변보다 더 위험합니다.
논문에서 리더에게 한 줄만 전하라면 저는 이 문장을 고를 것 같습니다. “데모가 아니라 eval에 기준선을 맞춰라.” 데모는 에이전트가 한 번은 잘 작동할 수 있다는 것을 보여 줄 뿐입니다. 반면 제대로 된 평가 기준을 갖춘 eval 스위트는 에이전트가 꾸준히 잘 작동한다는 것을 보여 줍니다. 저는 이 이야기를 계속 반복해서 하고 있습니다. 자세한 내용은 agentic code review 글에 적어 두었습니다.
각 단계는 실제로 어떻게 바뀌는가
AI는 소프트웨어 라이프사이클을 압축하지만, 그 압축이 균일하게 일어나는 건 아닙니다. 오히려 이 “불균형”이 이야기의 전부라고 해도 좋습니다. 구현(Implementation)은 몇 주에서 몇 시간으로 줄어듭니다. 반면 요구사항, 아키텍처, 검증은 여전히 느립니다. 이 일들은 결국 판단(judgment)의 영역이기 때문입니다. 그래서 명세(specification)의 품질이 새로운 병목이 되고, 검증은 라이프사이클의 중간으로 자리를 옮깁니다.
같은 단계들이지만, 병목도 다르고 비율도 완전히 달라집니다.
각 단계를 좀 더 구체적으로 보면:
- **요구사항(Requirements)**은 더 이상 팀 간에 주고받는 문서 한 장으로 끝나지 않습니다. 이제는 명세와 첫 번째 프로토타입이 동시에 나오는 대화 과정이 됩니다. 에이전트는 간단한 브리프에서 사용자 스토리를 초안으로 만들어 내고, 엣지 케이스를 끌어올리고, 자연어 설명을 몇 분 안에 실제로 돌아가는 무언가로 바꿉니다.
- **아키텍처(Architecture)**는 가장 완고하게 인간이 맡고 있는 단계입니다. 일관성(consistency)과 가용성(availability) 같은 트레이드오프는 모델이 충분히 볼 수 없는 비즈니스 맥락에 따라 달라집니다. 개발자의 역할은, 에이전트가 구현할 구조적 결정을 내리고 문서화하는 쪽으로 옮겨갑니다.
- **구현(Implementation)**은 이득과 함정이 동시에 존재하는 구간입니다. 여러 설문에서는 생산성 향상이 25~39% 수준이라고 합니다. 그런데 METR 연구에 따르면, 일부 작업에서는 경험 많은 개발자들이 전체 검토·수정 시간을 합쳤을 때 오히려 19% 느려지기도 했습니다. 둘 다 사실입니다. 정직하게 말하면, AI는 구현을 “작성하는 일”에서 “리뷰하는 일”로 바꿔 놓습니다.
- **테스트와 QA(Testing and QA)**는 방향이 뒤집힙니다. 여러분의 테스트와 평가가 에이전트에게 “무엇이 올바른지”를 알려 주는 주된 수단이 됩니다. 그리고 이게 루프에 딱 붙습니다. 벤치마크에 돌리고, 실패 사례를 클러스터링해서, 원인을 만든 프롬프트나 도구를 고치고, 회귀 테스트 스위트에 다시 돌려 보고, 운영 환경에서 새로 터지는 문제를 감시합니다.
- **유지보수(Maintenance)**는 제가 가장 저평가되어 있다고 생각하는 부분입니다. 작성자만 겨우 이해하고 있어서 “건드리기 너무 위험한 코드”로 남아 있던 부분도 이제 에이전트가 읽고, 리팩터링하고, 현대화할 수 있습니다. 지루하고 위험해서 미뤄 두었던 마이그레이션이나 폐기 작업들이 실제로 진행되기 시작합니다.
이 모든 것의 상한선에는 여전히 80% 문제가 있습니다. 에이전트는 기능의 첫 80%까지는 놀랄 만큼 빨리 데려다 줍니다. 하지만 마지막 20%, 엣지 케이스와 시스템 간 경계에서 벌어지는 일들은 대부분의 모델이 갖고 있지 않은 맥락을 필요로 합니다.
경제학: 컨텍스트와 라우팅이 비용 레버다
리더 입장에서 중요한 숫자는 속도(velocity)가 아니라 총소유비용(TCO, total cost of ownership)입니다. AI 시대에는 이 비용 구조가 조금 다르게 갈라지면서, 겉보기 직관과 “어느 쪽이 진짜로 싸게 먹히는가”에 대한 감각을 완전히 뒤집어 놓습니다.
교차 지점을 지나고 나면, vibe coding 방식은 기능 하나당 비용이 310배까지 뛸 수 있습니다. 코드가 얼마나 오래 살아남아야 하는지가, 이 지점에 도달할지 말지를 결정합니다.
Vibe coding은 시작은 싸고 운영은 비쌉니다. 시작 비용은 거의 없습니다. 구독료와 몇 줄의 프롬프트면 충분합니다. 대신 나중에 비용을 치르게 됩니다. 구조화되지 않은 파일을 통째로 모델에 던지고, 모델에게 자기 실수를 스스로 고치라고 할 때 생기는 토큰 낭비. 몇 달 뒤에 누군가가 즉석에서 짜인 코드를 역공학해야 할 때 드는 유지보수 세금. 빠른 생성 속도만큼 빠르게 취약점을 양산하면서 뒤늦게 처리해야 하는 보안 정리 비용까지. Agentic engineering은 이 흐름을 뒤집습니다. 초기에 (스키마, 테스트, 구조화된 컨텍스트)에 더 투자하고, 그 대신 기능 하나당 추가 비용은 낮게 가져갑니다.
“vibe coding은 기능당 비용이 3~10배 더 든다”라는 숫자는 어디까지나 예시일 뿐, 무슨 상수처럼 측정된 값은 아닙니다. 제가 개발자들에게 꼭 전하고 싶은 부분은 다른 데 있습니다. 컨텍스트 엔지니어링과 모델 라우팅은 기술적인 이슈를 넘어서, 곧바로 재무적인 레버라는 점입니다. 100,000토큰짜리 레포 전체를 매 프롬프트마다 다 집어넣고 그것이 스케일할 거라고 기대할 수는 없습니다. 복잡한 추론이 필요한 부분은 큰 모델에 라우팅하고, 루틴한 작업·테스트 생성·코드 리뷰·CI 체크 같은 부분은 작고 저렴한 모델에 보내야 합니다. 품질은 유지하면서 요금 청구서는 줄어듭니다. 이것이 제가 orchestration tax라고 불러 온 개념의 “돈” 측면입니다.
프로토타입이 곧 프로덕션 에이전트가 되어 간다
논문에서 제가 가장 주의 깊게 지켜보고 있는 부분이 바로 이것입니다. 예전에는 그저 일회용 스크립트를 찍어내는 정도였던 터미널 워크플로우가 이제는 같은 자리에서, 종종 여러분이 늘 쓰던 코딩 에이전트와의 대화를 통해 곧바로 프로덕션 에이전트를 만들어 내고 있습니다.
지속적인 메모리, 범위가 잘 제한된 권한, 평가 커버리지, 관측 기능을 갖춘 “진짜 에이전트”를 만들고, 평가하고, 배포하는 일은 예전에는 완전히 다른 스택과 다른 역할이 맡는 별도의 작업이었습니다. 이제 이게 여러분이 이미 돌리고 있던 루프 안으로 접혀 들어옵니다. Google의 Agents CLI는 이 흐름을 중심으로 설계되어 있습니다. 한 번만 설치를 해 두면, 여러분의 코딩 에이전트는 라이프사이클 전체를 다룰 수 있는 스킬을 얻게 되고, 여러분은 자연어로 이 모든 걸 제어할 수 있습니다.
# one-time setup
uvx google-agents-cli setup
# then, in your coding agent:
> Build a support agent that answers questions from our docs.
> Evaluate it on the FAQ dataset.
> Deploy it to Agent Engine.이 한 줄짜리 지시 뒤에서, 에이전트는 프로젝트를 스캐폴딩하고, 코드를 작성하고, 평가용 데이터셋을 만들고, 평가를 돌리고, 관리형 런타임에 배포하고, 결과를 다시 보고합니다. 어제 여러분의 노트북에서 돌아가던 프로토타입이, 별도의 재작성 없이 오늘은 실제 유저를 상대하는 프로덕션 에이전트가 됩니다. 에이전트 간의 협업은 MCP(도구용)와 A2A(다른 에이전트에게 일을 넘길 때) 같은 오픈 스탠더드를 기반으로 돌아갑니다.
논문에서 제가 사람들에게 자주 들려주는 실험이 하나 있습니다. Anthropic 팀이 여러 에이전트에게 2주 동안 Rust로 동작하는 C 컴파일러를 만들게 한 사례입니다. 사람들은 방향을 잡아 주고 코드를 리뷰할 뿐, 직접 코드를 쓰지는 않았습니다. 대략 이런 모습이 앞으로 우리가 가게 될 방향이라고 보시면 됩니다.
일상에서는 여러분이 두 모드 사이를 오갑니다. 논문에서는 이를 **지휘자(conductor)**와 오케스트레이터(orchestrator) 모드라고 부릅니다. 지휘자 모드는 IDE 안에서 실시간으로, 키 입력 하나하나마다 피드백을 주고받는 방식입니다. 아직 잘 모르는 코드를 탐색하기에 좋습니다. 오케스트레이터 모드는 비동기적입니다. 한두 개 이상의 에이전트에게 목표를 던져 주고, 되돌아온 결과물을 검토하는 방식입니다. 마이그레이션이나 테스트 생성처럼 명확히 정의된 작업에 적합합니다. 요즘 툴들은 이 두 가지 모드를 모두 지원하며, 심지어 같은 한 시간 안에서도 둘 사이를 오가는 일이 흔합니다. 저는 지휘자에서 오케스트레이터로의 전환은 도구의 변화이기 전에 먼저 역량의 변화라고 생각합니다.
다른 사람들을 위한 도표 하나
이제 도표 하나를 더 보겠습니다. 이번 도표는 여러분을 위한 것이 아닐 수도 있습니다. 여러분이 함께 데려가고 싶은 사람들을 위한 그림입니다. 여전히 이 모든 걸 “좀 더 똑똑한 자동 완성” 정도로만 보는 임원, 아직 이쪽으로 넘어오지 않은 동료들을 위한 도표입니다.
각 세대는 이전 세대를 버리지 않고 그대로 품은 채, 한 명의 엔지니어가 할 수 있는 일의 상한선을 계속 끌어올렸습니다.
이 도표에는 “이게 진짜냐”는 논쟁을 끝내 버리는 채택률 숫자들도 들어 있습니다. 2026년 초 기준으로, 전문 개발자의 85%는 AI 코딩 에이전트를 정기적으로 사용하고, 51%는 매일 사용하며, 신규 코드의 대략 41%는 AI가 생성한 코드입니다.
어디서부터 시작할까
논문의 마지막에는 개인, 리더, 조직 각각을 위한 더 긴 권장 사항 목록이 있습니다. 여기서 모두 반복할 생각은 없습니다.
굳이 한 줄만 꼽자면 이렇습니다. AI는 그 조직이 이미 갖고 있던 엔지니어링 문화를 그대로 증폭시킵니다. 좋은 부분이든 나쁜 부분이든 똑같이요. 생성은 이제 대부분 해결된 문제에 가깝습니다. 앞으로 남은 일은 명세와 검증, 그리고 둘을 이어 주는 시스템입니다. 지금 익혀야 할 것은 바로 이 부분입니다.