에이전트 기반 개발 (Agentic development)은 생산성의 이야기로 시작되지만, 규모가 커지면 빠르게 거버넌스 (governance) 문제로 변합니다.

런던에서 열린 AI Native DevCon에서 우리는 다양한 조직의 시니어 엔지니어링 리더들과 함께 Chatham House 방식의 라운드테이블을 진행했습니다. 특정 개인이나 기업의 발언을 인용하지는 않겠지만, 나타난 패턴은 놀라울 정도로 일관적이었습니다. 에이전트 기반 개발은 개인의 도구 활용 차원을 넘어 기업의 운영 모델 (operating model) 문제로 이동하고 있습니다.

첫 번째 파도는 충분히 익숙했습니다. 개발자들은 GitHub Copilot, Cursor, Claude Code, Codex, Devin 및 유사한 도구들을 시도했고, 많은 이들이 명백한 가치를 발견했습니다. 그들은 더 빠르게 코드를 작성하고, 더 빠르게 테스트를 생성하며, 더 빠르게 아이디어를 탐색했습니다. 어떤 경우에는 비용 문제로 백로그 (backlog)에 방치되었던 작업들을 다시 살려내기도 했습니다.

흥미로운 질문은 에이전트가 개인의 가속기 역할을 넘어 엔지니어링 조직의 작업 방식에 영향을 미치기 시작할 때 어떤 일이 벌어지는가 하는 점입니다. 그 시점에서 문제는 "이 도구가 도움이 되는가?"에서 "우리가 이것을 안전하고, 반복 가능하며, 측정 가능하고, 경제적으로 타당하게 만들 수 있는가?"로 전환됩니다.

그러한 변화 때문에 저는 **AI 에이전트 거버넌스 (AI agent governance)**가 가장 유용한 프레임워크라고 생각합니다. 이는 정체성 (identity), 권한 (permissions), 컨텍스트 (context), 평가 (evals), 모델 라우팅 (model routing), 비용 가시성 (cost visibility), 정책 (policy), 소유권 (ownership), 그리고 피드백 루프 (feedback loops)를 포함하여, 팀이 통제력을 잃지 않으면서 더 빠르게 움직일 수 있게 하는 시스템을 의미합니다.

덧붙여서, 제가 에이전트 거버넌스에 대한 개인적인 프레임워크와 기업의 에이전트 활성화를 위한 제안된 솔루션을 공유하는 강연인 "기술이 새로운 코드다 (skills are the new code)"를 들어보실 수 있습니다.

이제 라운드테이블에서 도출된 10가지 주요 통찰을 살펴보겠습니다.

1. 에이전트 도입은 열정으로 시작되지만, 확장을 위해서는 의도적인 배포가 필요하다

대부분의 조직은 비슷한 방식으로 시작하는 것으로 보입니다. 개발자들에게 AI 코딩 도구에 대한 접근 권한을 부여하고, 의욕적인 팀들이 이를 실행하도록 내버려 두는 것입니다.

이는 시작 단계에서 올바른 직관입니다. 왜냐하면 이 분야는 순수하게 하향식 (top-down) 프로그램만으로는 모든 유용한 패턴을 발견하기에는 너무 빠르게 움직이고 있기 때문입니다. 상향식 (bottom-up) 에너지는 학습을 빠르게 만들어냅니다. 또한 에이전트가 변화를 위한 제안서 (transformation deck)에서 기대했던 곳이 아니라, 실제로 어디에서 유용한지를 드러내 줍니다.

하지만 이는 파편화 (fragmentation)를 초래하기도 합니다.

각 팀은 서로 다른 도구를 채택하고, 서로 다른 프롬프트 (prompts)를 구축하며, 서로 다른 저장소 (repos)에 기술 (skills)을 저장하고, 무엇이 자동화하기에 충분히 안전한지에 대해 서로 다른 가정을 세웁니다. 어떤 그룹은 테스트 생성 (test generation)을 위해 에이전트를 사용할 수 있고, 다른 그룹은 코드 리뷰 (code review), 또 다른 그룹은 제품 사양 (product specs), 또 다른 그룹은 배포 자동화 (deployment automation)를 위해 사용할 수 있습니다. 머지않아 조직은 아직 하나의 시스템으로 합쳐지지 않은 수십 개의 유용한 실험들을 보유하게 될 수 있습니다.

핵심은 실험을 중단시키는 것이 아니라, 로컬 학습 (local learning)에서 공유된 관행 (shared practice)으로 이어지는 경로를 만드는 것입니다.

도입의 첫 번째 물결은 주로 개인의 생산성 (productivity)에 관한 것이었습니다. 다음 물결은 반복 가능하고 거버넌스 (governed)가 적용된 팀 워크플로 (workflows)에 관한 것이어야 합니다. 이는 단계적 배포 (rollout phases), 명확한 소유권 (ownership), 어떤 종류의 작업에 어떤 도구가 승인되었는지에 대한 관점, 그리고 가장 뛰어난 로컬 실험을 다른 이들이 재사용할 수 있는 표준 (standards)으로 전환하는 방법을 의미합니다.

이는 클라우드 (cloud)와 데브옵스 (DevOps)에서 볼 수 있는 익숙한 패턴입니다. 초기 수용자 (early adopters)들이 무엇이 가능한지를 증명하면, 그들을 중심으로 플랫폼이 형성됩니다. 이번의 차이점은 그 주기가 훨씬 빠르며, 거버넌스의 대상이 단순한 인프라 (infrastructure)나 코드 (code)가 아니라 에이전트 워크플로 (agentic workflow) 그 자체라는 점입니다.

2. 가장 강력한 ROI 사례는 생산성이 아닙니다. 그것은 증대된 야망 (ambition) 입니다

소프트웨어 개발에서의 AI에 관한 많은 공개적인 논의는 여전히 생산성을 중심으로 구성되어 있습니다.

• 엔지니어들이 동일한 작업을 더 빠르게 수행할 수 있는가?
• 팀이 동일한 인원으로 더 많은 것을 출시할 수 있는가?
• 비즈니스가 더 적은 자원으로 동일한 일을 할 수 있는가?

많은 비즈니스 리더들은 비용 절감을 추구할 것이며, 그렇지 않은 척하는 것은 순진한 생각일 것입니다. 또한, 아무리 친밀한 그룹 환경이라 할지라도 이러한 점의 일부는 공개적으로 말하기 어렵다는 점을 인정할 가치가 있습니다. 실제로 일부 리더들은 더 적은 인원으로 동일한 업무를 수행하거나, 비용을 절감하거나, 향후 채용을 늦춤으로써 생산성 (Productivity)을 활용하고자 할 것입니다.

하지만 라운드테이블(Roundtables)을 통해 제가 한동안 가져왔던 우려가 다시 한번 확인되었습니다. 만약 우리가 AI 생산성을 너무 공격적으로 홍보한다면, 도입이 무엇을 의미하는지에 대해 사람들이 두려움을 느끼게 함으로써 오히려 도입 속도를 늦출 수도 있습니다.

만약 내부적인 서사 (Narrative)가 주로 인원 감축에 관한 것이라면, 사람들은 스스로를 방어할 것입니다. 그들은 실제 얻은 이득을 숨기거나, 워크플로 (Workflow)가 얼마나 빨라졌는지 보여주기를 피하거나, 혹은 최고의 에이전트 패턴 (Agent patterns)을 공유하는 것이 인원 감축의 근거를 제공하는 것처럼 느껴져 사적으로만 간직할 수도 있습니다.

그것은 변화를 위한 문화적 토대가 아닙니다. 더 나은 프레임은 바로 야망 (Ambition) 입니다.

에이전트는 프로토타입 (Prototypes) 제작 비용을 낮춰줍니다. 에이전트는 시니어 엔지니어들이 일정상의 제약 때문에 묶여 있던 아이디어들을 탐색할 수 있게 해줍니다. 또한, 에이전트는 '직접 구축할 것인가 아니면 구매할 것인가 (Build-versus-buy)'의 방정식을 변화시킵니다. 과거에는 제안 요청서 (RFP)와 벤더 프로젝트가 필요했던 기능이 이제는 소규모 내부 팀이 시도해 볼 수 있는 수준이 될 수 있기 때문입니다.

이것이 바로 리더들이 대내외적으로 강조해야 할 이야기의 버전입니다. 질문은 "우리가 이전에는 시도하지 않았을 어떤 것들을 이제는 시도할 수 있는가?"가 되어야 합니다.

이러한 프레임워크는 경제적 논리를 부정하는 것이 아니라, 그것을 더 건강한 방향으로 인도합니다. 장기적인 서사는 바닥을 낮추는 것이 아니라 천장을 높이는 것에 관한 것이어야 합니다. AI가 조용히 역량을 줄이는 수단이 아니라 야망을 키우는 방법으로 이해된다면, 더 많은 사람이 적극적으로 참여할 것이며, 조직은 복리 효과 (Compounding benefits)를 발견할 가능성이 더 높아질 것입니다.

3. 컨텍스트 엔지니어링 (Context engineering)이 일류 엔지니어링 자산이 되고 있는 이유

에이전트는 적용할 수 있는 컨텍스트 (Context)만큼만 유용합니다.

그러한 컨텍스트 (Context)에는 사양 (Specs), 테스트 (Tests), 정책 (Policies), 아키텍처 가이드 (Architecture guidance), 제품 요구사항 (Product requirements), 런북 (Runbooks), 코딩 컨벤션 (Coding conventions), 인시던트 패턴 (Incident patterns), 보안 규칙 (Security rules), 그리고 도메인 언어 (Domain language)가 포함됩니다. 대부분의 조직은 이미 이러한 지식의 일부를 보유하고 있지만, 에이전트 시대 (Agentic era)가 요구하는 수준만큼 깔끔하거나 발견 가능 (Discoverable)한 경우는 드뭅니다. 그중 일부는 문서 (Docs)에, 일부는 Slack에, 일부는 티켓 (Tickets)에, 일부는 코드 주석 (Code comments)에 존재하며, 아주 많은 양은 사람들의 머릿속에 들어 있습니다.

에이전트 이전의 세상 (Pre-agent world)에서 부실한 문서는 짜증스러운 일이었지만 견딜 만한 수준이었습니다. 개발자는 시스템을 잘 아는 사람에게 물어보거나, 리뷰 코멘트 (Review comments)를 통해 컨벤션을 배울 수 있었습니다. 하지만 에이전트 시대 (Agentic world)에서 누락된 컨텍스트는 에이전트가 할 수 있는 일에 대한 직접적인 제한 요소가 됩니다.

이것이 바로 스킬 (Skills)이 중요한 이유입니다.

스킬은 암묵적인 엔지니어링 지식 (Tacit engineering knowledge)을 에이전트가 적용할 수 있는 재사용 가능한 컨텍스트 (Reusable context)로 전환합니다. 스킬은 단순히 포장만 더 예쁘게 한 프롬프트 (Prompts)가 아닙니다. 그것은 API 사용부터 보안 점검 (Security checks), 글쓰기 스타일 (Writing style), 배포 워크플로우 (Deployment workflow)에 이르기까지, 조직이 업무를 수행하고자 하는 방식을 인코딩 (Encode)하는 방법입니다.

이 지점에서 Tessl의 에이전트 기반 개발 (Agentic development)에 대한 관점이 등장합니다. 에이전트가 소프트웨어 개발 생명주기 (SDLC) 전반에 참여하게 된다면, 조직은 에이전트가 의존하는 컨텍스트를 협업하여 개발하고, 발견하고, 평가하며, 개선할 수 있는 방법이 필요합니다. 스킬 (Skills)과 평가 (Evals)는 이 문제의 양면입니다. 스킬은 에이전트에게 필요한 지식을 패키징 (Package)하고, 평가는 그 지식이 실제로 결과물을 개선했는지 여부를 보여줍니다.

sdlc

컨텍스트를 이런 방식으로 바라보고, 사고의 틀을 SDLC에서 CDLC (Context Development Lifecycle, 위에서 설명한 컨텍스트 개발 생명주기)로 전환하면, 문서화 (Documentation)는 더 이상 단순한 위생 작업 (Hygiene task)이 아니라 인프라 (Infrastructure)가 됩니다. 자신들이 일하는 방식을 기록하고, 그 지식을 최신 상태로 유지하며, 에이전트가 사용할 수 있도록 만드는 팀은 컨텍스트를 부족 사회 지식 (Tribal knowledge)으로 취급하는 팀보다 구조적인 우위를 점하게 될 것입니다.

4. 비용이 중요하지만, 잘못된 프레임워크는 잘못된 의사결정으로 이어집니다

모델 비용이 현실화되고 있습니다.

초기 도입 단계에서 많은 팀은 비용을 직접적으로 체감하지 못했습니다. 사용량이 제한적이었고, 파일럿 프로젝트 규모가 작았으며, 어떤 경우에는 벤더(Vendor)의 가격 책정 방식이나 보조금 덕분에 경제적 영향이 나중에 겪게 될 수준보다 덜 중요해 보였기 때문입니다. 하지만 그 단계는 끝나가고 있습니다…

에이전트가 일상적인 개발의 일부가 됨에 따라, 비용은 더 많은 곳에서 나타납니다: 거대한 컨텍스트 윈도우 (Context window), 반복된 시도, 장시간 실행되는 작업, 모델 업그레이드, 자율적 워크플로우 (Autonomous workflows), 그리고 루프 내에서 다른 도구들을 호출하는 에이전트 등이 그 예입니다.

일회성 실험으로서는 저렴한 프롬프트(Prompt)라도, 매일 수백 명의 개발자가 각자 거대한 리포지토리(Repo) 컨텍스트를 가지고, 여러 번의 재시도(Retries)를 수행하며, 기본값으로 최첨단 모델(Frontier model)을 선택하여 실행하게 되면 매우 비싸질 수 있습니다.

이것이 바로 _AI FinOps_가 실질적인 규율 (Discipline)이 되어야 하는 이유입니다!

클라우드 비유는 유용하지만 (어느 정도까지만 그렇습니다). 클라우드에서는 비용이 인프라 사용량을 따랐습니다. AI에서는 비용이 인지적 작업과 유사한 활동을 따릅니다: 추론 (Reasoning), 컨텍스트 (Context), 재시도 (Retries), 도구 호출 (Tool calls), 평가 (Evals), 그리고 오케스트레이션 (Orchestration) 등이 그것입니다. 이로 인해 지출을 가치와 매핑하기가 더 어려워집니다. 왜냐하면 청구된 비용이 엔지니어링 시간을 일주일이나 절약했거나, 보안 사고를 방지했거나, 고객 기능을 가속화했거나, 혹은 단순히 사람이 다시 쓰기 전까지 세 번의 잘못된 시도를 만들어낸 워크플로우에 부과될 수 있기 때문입니다.

이 라운드테이블이 진행된 이후 불과 몇 주 사이에도 AI 비용에 대한 인식이 상당히 높아졌습니다. 에이전트 도입이 확대됨에 따라 이러한 경향은 계속될 것입니다. 리더들은 지출이 어디로 가는지, 어떤 작업에 어떤 모델이 사용되는지, 컨텍스트가 어디에서 낭비되고 있는지, 그리고 어떤 워크플로우가 전달 속도, 품질, 리스크 또는 야망을 개선함으로써 비용을 정당화하는지에 대한 가시성 (Visibility)을 확보해야 할 것입니다.

잘못된 해답은 맹목적으로 사용을 억제하는 것입니다. 더 나은 해답은 의도적으로 관리하는 것입니다: 모델 라우팅 (Model routing), 캐싱 (Caching), 컨텍스트 규율 (Context discipline), 예산 (Budgets), 관측 가능성 (Observability), 그리고 더 저렴한 옵션이 충분히 괜찮은지 팀이 알 수 있도록 돕는 평가 (Evals) 등이 필요합니다.

5. 모델 라우팅은 AI 에이전트 거버넌스의 일부가 될 것입니다

모든 작업에 가장 크거나 가장 비싼 프론티어 모델 (Frontier Model)을 사용할 필요는 없다는 점에는 폭넓은 공감대가 형성되어 있습니다. 최근 Tessl이 기본 평가 (Eval) 모델을 Sonnet 4.6에서 GLM 5.1로 전환한 것이 좋은 예입니다. 이 원칙을 받아들이기는 쉽지만, 운영 측면의 질문은 더 어렵습니다. 즉, 조직이 어떤 작업에 어떤 모델이 충분히 적합한지 어떻게 알 수 있을까요?

그 해답은 단 하나의 모델이 아니라, 바로 _라우팅 (Routing)_이 될 것입니다.

프론티어 모델 (Frontier Models)은 모호한 추론, 복잡한 계획, 그리고 잘못된 답변의 비용이 높은 작업에서 여전히 가치가 있을 것입니다. 반면, 작업이 잘 정의되어 있고 출력을 검증할 수 있는 제한적이고 반복적인 업무에는 더 작은 모델들이 더 나을 수 있습니다. 오픈 모델 (Open Models)은 이미 충분한 역량을 갖추게 되어, 많은 협소한 작업 (Narrow tasks)에서 매우 충분하면서도 훨씬 저렴할 수 있습니다. 데이터 민감도, 지연 시간 (Latency), 또는 제어권이 원시적인 성능보다 더 중요할 때는 로컬 또는 프라이빗 배포 (Local or private deployments)가 합리적일 수 있습니다.

위험 요소는 모든 팀이 이를 독립적으로 해결하려 한다는 점입니다. 어떤 팀은 Claude Code를 표준으로 삼고, 다른 팀은 Cursor를, 또 다른 팀은 Codex를 사용하며, 다른 팀은 오픈 모델로 실험을 진행한다면, 조직은 중복된 평가 (Eval) 작업에 직면하게 되고 품질, 비용 또는 리스크에 대한 공유된 관점을 갖지 못하게 됩니다.

이것이 바로 모델 라우팅 (Model routing)이 AI 에이전트 거버넌스 (AI agent governance)의 영역에 속해야 하는 이유입니다. 결정은 작업, 데이터, 품질 기준 (Quality bar), 영향 범위 (Blast radius), 비용, 그리고 사용 가능한 검증 (Validation) 방식에 따라 달라져야 합니다. 진정한 역량은 선호하는 모델을 선택하는 것이 아니라, 팀들이 적절한 작업에 적절한 모델을 사용할 수 있도록 측정 및 라우팅 계층 (Measurement and routing layer)을 구축하는 것입니다.

중요한 테스트는 작은 모델이 한 번 작동하느냐가 아닙니다. 실제 운영 환경에서 워크플로우가 갖게 될 컨텍스트 (Context)와 제약 조건 하에서, 현실적인 입력값에 대해 반복적으로 품질 기준을 충족하느냐 하는 것입니다.

6. 왜 AI 에이전트 거버넌스가 기업 보안의 병목 현상이 되고 있는가

비용은 상승하고 있지만, 기업의 도입을 제한할 가능성이 가장 높은 우려는 여전히 보안입니다.

에이전트를 챗봇 (Chatbot)으로 보는 것을 멈추고 개발 환경 (Development environment) 내부의 행위자 (Actor)로 생각하기 시작하면 그 위험성을 쉽게 이해할 수 있습니다. 개발자의 자격 증명 (Credentials)으로 실행되는 코딩 에이전트 (Coding agent)는 내부 저장소 (Internal repositories), 패키지 레지스트리 (Package registries), 로그 (Logs), 배포 시스템 (Deployment systems), 티켓 (Tickets), 고객 데이터 (Customer data), 그리고 운영 환경 인접 시스템 (Production-adjacent systems)에 접근할 수 있습니다. 만약 해당 에이전트가 웹을 탐색하거나, 패키지를 설치하거나, 스크립트를 실행하거나, 시스템 간에 데이터를 이동할 수 있다면, 폭발 반경 (Blast radius)은 실질적으로 변화합니다.

이것이 에이전트를 차단하는 것이 정답이라는 의미는 아닙니다. 이는 신뢰 모델 (Trust model)이 성숙해져야 함을 의미합니다.