에이전트 기반 소프트웨어 엔지니어링(Agentic software engineering)은 비용의 중심을 인간의 컨텍스트(human context)로 옮기고 있습니다.

코드는 더 빠르게 생성되고, 풀 리퀘스트(pull requests)는 더 빠르게 쌓이며, 검증(validation) 작업은 여전히 사람이 처리해야 하는 점점 더 거대한 판단 작업의 더미로 쌓이고 있습니다.

이러한 느낌은 Honeycomb의 Douglas Soo가 8월 3일 게시한 글, “LLM 주도 개발: 시니어 엔지니어의 컨텍스트 스위칭(context switching) 피로와 주니어 엔지니어의 성장에 대한 불안(LLM-driven development: the exhaustion of context switching for senior engineers, and anxiety of growth for junior engineers)”에서 포착되었습니다. 그는 에이전트 기반 소프트웨어 엔지니어링이 엔지니어링 팀이 개발하는 소프트웨어의 양을 늘릴 잠재력이 있지만, 개발되는 소프트웨어에 대해 더 적게 이해하면서 더 많은 소프트웨어를 출시할 위험이 있다고 썼습니다. 그는 LLM 주도 개발에서 “컨텍스트 전송(context transfer)”이 엔지니어링 루프(engineering loop)에서 비용이 많이 드는 부분이 된다고 설명합니다. 설계(Design), 구현(Implementation), 검증(Validation), 운영(Operation)으로 이어지는 기존의 소프트웨어 개발 리듬(DIVO)은 에이전트 기반 소프트웨어 엔지니어링의 새로운 리듬인 설계, 구현, 검증 단계에서 구현 시간 내에 압축되고 있습니다.

생성형 AI 소프트웨어 개발은 인간의 컨텍스트를 가장 먼저 소모한다

기존의 소프트웨어 개발 프로세스는 실제로 소프트웨어를 구현하는 데 걸리는 시간에 편향되어 있었습니다. 따라서 팀이 약간의 설계를 마친 후에는 해당 설계를 위한 코드를 작성하는 데 더 많은 시간을 소비했고, 그다음에는 작성된 코드가 실제 트래픽에 적합한지 검증하기 위한 코드 리뷰(code reviews)가 진행되었습니다. 그 후 소프트웨어가 라이브 상태가 되면 팀은 운영 문제(operational problems)를 모니터링했으며, 이는 다시 소프트웨어의 다음 버전을 위한 설계, 구현, 검증 및 운영에 사용되었습니다. 소프트웨어 개발의 이 프로세스는 설계(Design), 구현(Implementation), 검증(Validation), 운영(Operation)을 뜻하는 DIVO라고 불려 왔습니다.

소프트웨어 개발의 이러한 변화는 중요한데, 저렴한 부분(구현)과 희소한 부분(컨텍스트)의 위치가 서로 바뀌었기 때문입니다.

Side-by-side engineering lifecycle showing implementation shrinking while validation and context transfer expand.
구현(Implementation)은 축소되지만, 컨텍스트(context)와 검증 루프(validation loop)는 더 무거워집니다.

앞서 설명했듯이, 컨텍스트 또한 설계 영역(design surface)의 일부가 됩니다. 따라서 에이전트 기반 소프트웨어 엔지니어링(agentic software engineering) 프로젝트의 경계 내에서, 에이전트는 문서, 테스트, 트레이스(traces), 티켓 항목, 코멘트, 예시, 그리고 리포지토리(repository)의 전반적인 코딩 구조 사이에 사전에 저장되고 연결된 만큼의 컨텍스트만을 처리할 수 있습니다. 이후 시니어 엔지니어는 이 모든 에이전트와 컨텍스트를 중심으로 에이전트 형태의 시스템을 실제로 재구성해야 할 것입니다.

이는 아키텍처의 중추(architecture spine)를 가진 엔지니어링 문화의 문제이며, 따라서 더 이상 제한된 자원은 키 입력(keystrokes)이 아니라, 모델로 전달되거나 모델로부터 전달되는 판단(judgment)의 전이입니다.

비용 모델에 드디어 이름이 붙다

스토리 포인트(Story points)는 항상 어느 정도 모호했습니다. 에이전트 기반 소프트웨어 엔지니어링은 이를 훨씬 더 모호하게 만듭니다.

“에이전트 기반 소프트웨어 엔지니어링을 위한 비용 추정 모델(A Cost Estimation Model for Agentic Software Engineering)” 논문에서 ACEM 저자들은 COCOMO II, 기능 점수(Function Points), 스토리 포인트(Story Points)와 같은 전통적인 비용 모델이 소프트웨어 비용을 설계, 코딩, 테스트 전반에 걸친 주로 인간의 노동력으로 가정한다고 말합니다. 소프트웨어 개발이 더욱 에이전트 중심으로 변함에 따라, 인간의 노력은 계획, 사양 정의(specifying), 아키텍처 설계(architecting), 그리고 에이전트 출력물의 검증(validating) 쪽으로 이동하며, 예산은 LLM 토큰, 인간 참여형 감독(human-in-the-loop oversight), 그리고 오케스트레이션 인프라(orchestration infrastructure)를 흡수하게 됩니다.

그 프레임워크는 유용합니다. 우선, LLM(Large Language Model)의 토큰 소모 비용을 정량화하기 쉽습니다. 그다음으로, 인간의 감독(human oversight) 비용은 이미 존재하는 리뷰 프로세스가 이를 커버한다고 말하며 대충 넘길 수 있습니다. 마지막으로, 필요한 인프라 비용은 에이전트 기반 소프트웨어 엔지니어링(agentic software engineering) 하네스(harness)와 샌드박스(sandboxes), 평가 실행기(eval runners), 트레이스 저장소(trace stores), 라우팅 레이어(routing layers), CI 분(CI minutes), 권한 레이어(permission layers)와 같은 모든 추가 레이어 속에 숨길 수 있습니다. 에이전트 기반 소프트웨어 엔지니어링 비용 추정을 위한 승수(multipliers)를 더 개선된 방식으로 표현하는 방법은 수정 계수(Revision Factors), 컨텍스트 계수(Context Factors), 그리고 HITL(Human-in-the-loop) 강도 점수(Intensity Scores)라고 명시하는 것입니다.

Stacked cost model for agentic software engineering showing token, human oversight, and infrastructure costs with revision and context amplifiers.
토큰 소모는 에이전트 기반 엔지니어링 청구서의 한 계층일 뿐입니다.

그렇습니다. ACEM 논문은 초기 단계이며 상수가 상징적입니다. 중요한 점은 저자들이 논문에서 제시된 비용 추정 모델이 아직 실제 프로젝트 데이터에 대해 검증되지 않았다고 단언했다는 것이며, 이는 다른 사람들이 이 작업을 잘못된 방식으로 사용하거나 에이전트 기반 소프트웨어 엔지니어링의 비용을 성급하게 추정하는 것을 방지하기 위해 다시 한번 강조할 가치가 있는 지점입니다.

다음과 같은 비용들이 존재하지 않는 척하는 것을 그만두고, 조직 내부에서 이를 측정하기 시작하십시오.

또한, 단순히 동일한 시도를 반복하는 것이 아니라 방향을 전환하는 재시도(retries)의 횟수가 상대적으로 높을 것이라는 점에 주목하십시오. 마찬가지로, 단순한 구문 오류(syntax errors)가 아닌 제품에 대한 오해를 발견하는 리뷰 단계(review passes)의 횟수도 높을 것입니다. 엔지니어들이 '더 깔끔한' 추상화(abstraction)가 실제로는 운영 불변량(operational invariant)을 어떻게 위반하는지 설명하는 데 소비하는 시간 또한 많을 것입니다. 리뷰어가 관련 브랜치에 적절한 트레이스(traces), 스크린샷, 마이그레이션 계획 또는 롤백 계획(rollback plans)이 없어서 변경 사항을 승인할 수 없는 사례(즉, 변경 사항을 이해할 수 없는 경우)도 빈번할 것입니다.

이것들이 에이전트 기반 소프트웨어 엔지니어링(agentic software engineering)의 진정한 비용이며, 에이전트 기반 소프트웨어 엔지니어링 예산에 반드시 포함되어야 하는 비용들입니다.

컨텍스트 전달은 런타임 상태이다

에이전트는 코드를 생성하기 위해 조직의 상태(organizational state) 또한 사용합니다.

제가 알기로는, 이것이 컨텍스트 압축 이론(Context Compaction Theory)에 관한 논문에서 제시된 문제 설명의 공식적인 버전입니다. 코딩 에이전트에 의해 수행될 작업을 모델링할 때, 모델 호출(model calls)은 제한된 컨텍스트 창(context windows)을 가진다는 점에 유의하십시오. 따라서 에이전트는 작업을 수행하는 동안 축적되는 컨텍스트 상태(context states)를 압축해야 합니다. 에이전트는 상태의 일부를 선택하여 요약(summary)을 생성하거나, 즉시 요약을 생성하는 방식으로 이를 수행합니다. 위 논문에서 모델링된 두 가지 게임은 컨텍스트 선택 게임(Context Selection Game)과 컨텍스트 생성 게임(Context Generation Game)입니다. 이를 통해 생성을 단방향 통신 복잡도(one-way communication complexity)와 연관 지을 수 있습니다.

추상적으로 들릴 수 있지만, 실제로 그렇습니다. 그럼에도 여전히 유용합니다.

모든 팀은 이미 이 게임의 인간 버전을 실행하고 있습니다. 시니어 엔지니어들은 대화에 참여하여 "여기서 중요한 게 무엇인가요?"와 같은 질문을 던지고, 대화가 올바른 방향으로 흐르도록 돕습니다. 리뷰어들은 어떤 파일을 열지, 어떤 로그를 신뢰할지, 그리고 어떤 제품의 엣지 케이스(edge cases)가 잘못된 냄새를 풍기는지 결정합니다. PR(Pull Request) 설명을 작성할 때, 티켓(ticket)에 무엇을 넣고 채팅에서 무엇을 삭제할지 결정하면서, 팀은 무엇이 중요하고 무엇이 중요하지 않은지에 대한 결정을 내리고 있습니다.

오래된 시스템 지식은 비용을 발생시킵니다. 우리는 이미 문서 드리프트(documentation drift)가 코딩 에이전트의 사용에 어떤 영향을 미치는지 확인했지만, 문서에 발생하는 동일한 드리프트는 동일한 워크플로우 내의 인간에게도 영향을 미칩니다. 따라서 현재 시스템에 대한 부실한 표현(representation)에 기반한 에이전트 기반 코딩 워크플로우는 에이전트뿐만 아니라 동일한 워크플로우에 있는 인간에게도 문제를 일으킬 것입니다. 에이전트는 최신 상태가 아닌 README를 따릅니다. 리뷰어는 라이브 시스템의 현재 상태를 머릿속에 담고 있습니다. 주니어 엔지니어는 무엇이 변경되었는지 알아내기 위해 디프(diff)를 수행하다가, 실제로는 틀린 새로운 규칙을 배우게 됩니다.

이 지점이 에이전트 기반 소프트웨어 엔지니어링(agentic software engineering)이 불편해질 수 있는 부분입니다. 팀은 더 많은 코드를 생산할 수 있지만, 동시에 팀의 공유된 이해(shared understanding)를 감소시킬 수 있습니다. 그러한 팀의 처리량(throughput) 그래프는 훌륭해 보일 수 있지만, 라이브 시스템이 아무도 대답할 수 없는 질문을 던지는 순간 문제가 발생합니다.

컨텍스트를 빌드 아티팩트로 만들기

작업이 일어나는 컨텍스트(context)를 패키징하세요.

따라서 지루한 구현 세부 사항으로서의 문서 대신, 에이전트 기반 엔지니어링 루프를 지원하기 위해 반복되는 인간의 설명을 아티팩트(artifacts)(위에서 언급한 바와 같이)로 전환합니다.

이는 또한 LLM 시대의 인간 중심적인 페어링 (pairing) 방식이기도 합니다. Honeycomb은 LLM 기반 개발이 페어링의 방향을 함께 코드를 타이핑하는 것에서 벗어나, 시니어 엔지니어가 판단력을 모델링하고 주니어 엔지니어가 실제 구현을 주도하는 "신속한 피드백 (rapid feedback)" 스타일의 빠른 설계 및 검증으로 이동시킨다고 주장합니다. 이는 엄청난 수의 PR (Pull Request)을 생성하고, 그것들이 큐(queue)에 쌓여 한참 뒤처진 후에 각 PR에 달린 코멘트를 읽는 것보다 훨씬 낫습니다. 큐에 쌓인 리뷰 코멘트는, 비록 그 차이점(diff)이 에이전트로부터 나왔다 하더라도 멘토링이 될 수 없습니다.

기술적인 접근 방식으로는 데이터센터 제어 평면(control plane) 정책을 생성하기 위해 'AtumAI' 스타일의 에이전트 기반 접근 방식을 코드로 구현하는 것이 있을 수 있습니다. 이러한 접근 방식은 먼저 자연어 목표를 목표(objectives), 제약 조건(constraints), 결정 변수(decision variables) 및 평가 방법론(evaluation methodology)에 대한 공식적인 명세(formal specifications)로 컴파일합니다. 그런 다음 공식화된 문제에 대한 솔루션을 탐색합니다. 이러한 접근 방식에 대한 평가에서, 데이터센터 제어 평면 제어를 위해 에이전트가 생성한 정책이 AtumAI의 평가에 따르면 워크로드 배치(workload placement), 컴퓨터 리소스 확장(scaling), 데이터센터 전력 관리(management of power)의 다양한 지표 측면에서 전문가가 직접 설계한(hand-engineered) 동일한 정책보다 더 뛰어난 성능을 보이는 것으로 나타났습니다.

이는 좁은 범위의 테스트이지만, 중요한 점을 시사합니다. 일반적으로 에이전트가 자신이 행동하는 세상에 대해 더 많은 컨텍스트(context)를 얻을수록 더 나아질 것입니다. 이는 예를 들어 에이전트에게 주어지는 프롬프트(prompt)가 명세(specification)만큼 좋지 않은 경우에 특히 그러합니다. 교묘하게 작성된 프롬프트는 평가(eval)만큼 좋지 않습니다. 차이점(diff)을 검토하는 영웅적인 리뷰어는 왜 변경 사항이 안전한지를 기록하는 워크플로(workflow)만큼 좋지 않습니다.

패턴이 반복될 때는 그 행동을 결정론적 실행(deterministic execution)으로 승격시키세요. 저는 이전에 탐색(exploration)은 형태가 알려지면 직관적인 코딩 작업으로 바뀌어야 한다고 언급한 적이 있습니다. 이는 엔지니어링 문화에도 동일하게 적용됩니다. 시니어 엔지니어가 동일한 운영 불변성(operational invariant)을 세 번째로 설명한다면, 재발견에 시니어의 주의력을 낭비하는 것을 멈추세요. 그 불변성을 코드, 테스트, 에이전트 지침, 그리고 검토 체크 항목에 넣어 다시 찾을 수 있게 만드세요.

소유권은 명시적임으로써 생존한다

에이전틱 코딩(Agentic coding)은 브랜치 확산(branch sprawl)과 약한 소유권을 의미합니다.

더 나은 거래는 지루할 때 발생합니다. 연결되지 않은 작업 흐름이 적고, 핸드오프 아티팩트가 더 강력해야 합니다. 다음 프롬프트, 테스트, 그리고 수용 기준에 다시 피드백되는 라이브 트레이스를 검토하세요. 코드가 제품 의도(product intent)를 충족하는지, 운영하기에 안전한지, 그리고 수행된 작업이 다음 실행을 더 저렴하게 만들 만큼 충분한 학습을 포착했는지 묻는 검토가 필요합니다.

여기서는 프로세스 증거(Process evidence)가 중요합니다. 에이전틱 커머스(agentic commerce)에 관한 ACWorld 논문은 최종 상태만으로는 평가된 오류를 놓칠 수 있으며, 불완전한 궤적(incomplete trajectories)조차 유용한 신호를 담고 있음을 발견했습니다. 해당 환경은 공유 상태가 변경되기 전에 액션을 검증하고 진행 중인 거래를 재현 가능한 평가를 위해 상호 작용을 기록합니다. 소프트웨어 팀도 덜 이국적인 모습으로 같은 문제를 안고 있습니다. 녹색 병합(green merge)은 최종 상태입니다. 흥미로운 증거는 경로에 존재합니다: 에이전트가 무엇을 시도했는지, 검토자가 무엇을 거부했는지, 어떤 가정이 변경되었는지, 어떤 트레이스가 수정 사항을 입증했는지, 어떤 롤백 경로가 존재하는지 말입니다.