코딩 에이전트에 1,000억 토큰을 써보니, 병목은 모델 밖에 있었다

Codex 화면에 집계된 누적 사용량은 약 866억 토큰이었다.

Claude는 내가 확인할 수 있었던 로컬 머신의 집계값만 합쳐도 약 127억 토큰이었다. 다만 Claude는 여러 워크스테이션과 서버에서 사용했고, 중간에 사용량 데이터를 한 번 날려버리기도 했다. 누락된 머신과 기간을 감안하면 실제 사용량은 300억 토큰을 넘었을 가능성이 높다.

여기에 Ollama Cloud로 사용한 GLM, Qwen 등의 모델까지 더하면, 코딩 에이전트를 이용한 개발과 Kubernetes 인프라 운영에 1,000억 토큰 이상을 쓴 셈이다.

물론 이 숫자를 정밀한 계측값으로 보면 곤란하다. 제품마다 입력, 출력, 캐시 등의 집계 기준이 다르고, Claude 사용량은 일부 머신의 로컬 기록을 기반으로 추정한 값이다. 서로 다른 제품의 숫자를 그대로 더해 비용이나 모델 효율을 비교할 수도 없다.

무엇보다 토큰 사용량은 생산성이 아니다. 1,000억 토큰을 썼다고 해서 1,000억 토큰만큼 좋은 소프트웨어를 만들었다는 뜻은 더더욱 아니다. 같은 문제를 계속 틀려서 토큰을 많이 썼을 수도 있고, 검색과 테스트 환경이 좋지 않아 불필요한 시행착오를 반복했을 수도 있다.

그럼에도 이 숫자를 제목에 넣은 이유는 하나다. 몇 번의 데모가 아니라, 상당히 많은 개발과 운영 작업을 에이전트에 맡겨 본 뒤에야 반복해서 보이기 시작한 문제가 있었기 때문이다.

처음에는 어떤 모델이 더 똑똑한지가 가장 중요해 보였다. 그런데 일정 수준 이상의 모델을 사용하기 시작하자 병목은 모델 밖으로 이동했다. 저장소를 얼마나 정확하게 탐색하는지, 필요한 정보를 어디에서 찾는지, 테스트와 배포 결과를 다시 확인할 수 있는지, 여러 에이전트의 작업을 어떻게 통제하는지가 점점 더 중요해졌다.

지금 내 생각은 이렇다.

코딩 에이전트의 생산성은 모델 하나로 결정되지 않는다. 모델이 충분히 좋아진 뒤에는 도구, 실행 환경, 피드백 루프와 개발 체계가 더 큰 차이를 만든다.

처음에는 모델을 골랐다. 나중에는 도구를 고쳤다

LLM과 코딩 에이전트는 같은 모델을 쓰더라도 작동 방식이 다르다.

일반적인 LLM은 질문을 받고 답을 생성한다. 코딩 에이전트는 파일을 읽고, 코드를 수정하고, 명령을 실행하고, 실패한 테스트를 분석한 뒤 다시 코드를 수정한다. 한 번의 응답으로 끝나는 것이 아니라, 모델과 도구가 여러 차례 왕복하면서 결과를 만든다.

OpenAI도 Codex의 핵심 구조를 모델만이 아니라 사용자, 모델, 도구 사이의 상호작용을 조정하는 에이전트 루프 또는 하네스라고 설명한다. 실제 코딩 작업의 결과는 멋진 설명문이 아니라 로컬 저장소에 남은 변경 사항과 실행 결과다.

직접 써보면 이 차이가 분명하다.

모델이 아무리 좋아도 저장소 구조를 제대로 읽지 못하고, 테스트를 실행할 수 없고, 배포 상태를 조회하지 못하면 결국 “이 명령을 실행해 보라”는 조언만 반복한다. 반대로 모델의 성능이 아주 압도적이지 않더라도, 현재 코드와 공식 문서, CI 결과, 운영 로그에 정확히 접근할 수 있으면 꽤 복잡한 문제를 해결한다.

그래서 에이전트 성능을 평가할 때 모델 벤치마크만 보는 것은 부족하다. 실제로는 다음 질문이 더 중요할 때가 많다.

• 필요한 파일과 심벌을 정확하게 찾는가?
• 실행한 명령이 실패했을 때 원인을 구분할 수 있는가?
• 테스트 결과를 읽고 다음 행동을 수정하는가?
• 현재 배포된 버전과 변경된 버전을 비교할 수 있는가?
• 도구를 잘못 호출했을 때 안전하게 실패하는가?

여기서 MCP가 큰 역할을 한다.

MCP는 에이전트가 문서, 브라우저, 이슈 관리 시스템, 데이터베이스, 내부 개발 도구 등에 접근할 수 있게 해준다. 하지만 MCP 서버를 많이 연결한다고 에이전트가 자동으로 좋아지는 것은 아니다.

오히려 비슷한 기능의 도구가 너무 많고 설명이 모호하면 어떤 도구를 써야 하는지 판단하는 데 시간을 쓴다. 결과가 지나치게 크면 컨텍스트가 불필요한 데이터로 채워지고, 읽기와 쓰기 권한이 뒤섞이면 안전하게 운영하기도 어려워진다.

운영 환경에서는 범용 도구 하나보다 업무 범위가 명확한 도구가 낫다. 예를 들어 run_command(command) 하나로 모든 일을 처리하게 하는 것보다 create_preview_environment(service, revision, ttl)이나 get_deployment_health(service, environment)처럼 행위와 입력값이 제한된 도구가 통제하기 쉽다.

후자의 방식은 입력 검증, 최소 권한, 승인 절차, 감사 로그, 재시도 정책을 도구 단위로 붙일 수 있다. 무엇보다 에이전트가 실수했을 때 피해 범위를 예측할 수 있다.

MCP라고 해서 자동으로 안전해지는 것도 아니다. Codex의 셸 도구에 적용되는 샌드박스는 외부 MCP 도구에 자동으로 적용되지 않는다. 외부 MCP 서버는 자체적으로 인증, 권한, 입력 검증과 실행 제한을 구현해야 한다.

결국 좋은 에이전트 도구는 단순한 API 래퍼가 아니다. 에이전트가 수행해도 되는 업무의 범위와 실패 방식을 정의하는 일종의 계약에 가깝다.

모델의 지식보다 ‘지식을 얻는 경로’가 중요해졌다

이제 모델의 지식 깊이가 중요하지 않다고 말하는 것도 지나친 주장이다.

복잡한 문제를 작은 단위로 나누는 능력, 여러 오류 사이에서 원인을 추론하는 능력, 적절한 도구를 고르는 능력은 여전히 모델마다 차이가 크다. 좋은 모델은 같은 작업을 더 적은 시행착오로 끝내고, 잘못된 가설을 더 빨리 버린다.

다만 에이전트 환경에서는 모델이 사전에 얼마나 많은 사실을 암기하고 있는지의 비중이 줄었다.

소프트웨어 개발에 필요한 정보는 너무 빨리 변한다. 라이브러리 API와 설정 방식이 바뀌고, Kubernetes나 각종 클라우드 네이티브 도구는 버전에 따라 동작이 다르다. 사내 인증 체계와 배포 규칙은 외부 모델이 애초에 알 수 없다. 운영 장애의 원인은 모델의 학습 데이터가 아니라 지금 발생한 로그와 메트릭 안에 있다.

이런 환경에서는 모든 것을 알고 있는 모델보다, 필요한 순간에 정확한 정보를 찾고 그 정보가 현재 환경에 적용되는지 검증할 수 있는 에이전트가 더 유용하다.

그래서 나는 에이전트만을 위한 검색 환경이 필요하다고 생각한다.

일반적인 웹 검색은 사람을 위한 결과를 제공한다. 사람은 여러 페이지를 훑어보고 광고, 중복 문서와 오래된 정보를 걸러낼 수 있다. 에이전트는 검색 결과를 다음 행동의 근거로 사용한다. 오래된 문서를 최신 API 문서로 오인하면 잘못된 코드를 작성하고, 빌드하고, 실패한 뒤 다시 검색한다. 검색 품질이 낮으면 토큰과 실행 시간이 함께 낭비된다.

Tavily 같은 외부 검색 API는 간편하지만, 내가 수십 개의 에이전트를 병렬로 사용하는 패턴에서는 비용과 응답 지연이 부담스러웠다. 동일하거나 비슷한 질의가 여러 세션에서 반복되는 일도 많았다.

그래서 로컬 Search Proxy 또는 Agent Search Gateway를 두는 방식을 고민하게 됐다. 에이전트는 이 게이트웨이 하나만 호출하고, 게이트웨이가 내부 문서, 코드 검색, 운영 Runbook, 공식 제품 문서와 외부 웹 검색을 적절히 조합하는 방식이다.

이 구조에서 중요한 것은 단순히 검색 결과를 캐시하는 것만이 아니다.

공식 문서와 사내 승인 문서의 순위를 높이고, 문서가 적용되는 제품 버전과 환경을 함께 돌려줘야 한다. 마지막 검증 시각, 문서 소유자, 출처와 만료 시점도 필요하다. 민감한 질의가 외부 검색 서비스로 나가지 않도록 제어하고, 에이전트별 검색량과 비용도 제한할 수 있어야 한다.

에이전트에게 필요한 검색 결과는 단순한 텍스트 조각이 아니다.

“어디에서 찾은 내용인지”, “어느 버전에 적용되는지”, “누가 관리하는 문서인지”, “지금도 유효한지”가 함께 제공돼야 한다.

코드는 빨리 나왔지만, 제품은 자동으로 완성되지 않았다

바이브 코딩이 주는 가장 강한 인상은 속도다.

화면을 만들고, API를 붙이고, 데이터베이스 스키마를 만드는 속도는 확실히 빨라졌다. 예전 같으면 며칠 걸렸을 프로토타입을 몇 시간 안에 만드는 일도 드물지 않다.

문제는 프로토타입 이후다.

코드가 생성됐다고 해서 반복해서 빌드할 수 있는 것은 아니다. 로컬에서 한 번 실행됐다고 배포할 수 있는 것도 아니다. 테스트, 보안 검사, 버전 관리, 배포, 모니터링과 복구까지 이어져야 비로소 운영할 수 있는 소프트웨어가 된다.

에이전트가 코드를 많이 생성할수록 다음 질문이 더 중요해진다.

• 같은 코드를 다시 빌드해도 같은 결과가 나오는가?
• 변경 사항을 자동으로 검증할 수 있는가?
• 어떤 소스 리비전이 어떤 바이너리나 이미지에 대응하는가?
• 현재 어떤 버전이 어느 환경에 배포돼 있는가?
• 배포 후 성능과 오류율이 나빠지지 않았는가?
• 문제가 생기면 어느 버전으로 되돌아가야 하는가?

이 질문에 답할 수 있는 환경이 없으면 에이전트도 추측할 수밖에 없다.

코드를 수정하고 “이제 해결됐습니다”라고 말하지만, 실제로 빌드했는지, 통합 테스트를 통과했는지, 운영 환경에서 문제가 사라졌는지는 알 수 없다. 그 상태에서 추가 수정을 요청하면 에이전트는 검증되지 않은 코드 위에 또 다른 코드를 쌓는다.

내가 인프라 없는 바이브 코딩에서 가장 많이 낭비한 것은 토큰 자체가 아니었다. 실패 원인을 확인할 수 없어 같은 문제를 다른 방식으로 반복하는 시간이 더 아까웠다.

반대로 CI/CD 환경이 갖춰져 있으면 에이전트의 행동이 훨씬 구체적으로 바뀐다.

코드를 수정한 뒤 빌드하고, 단위 테스트와 정적 분석을 실행하고, 컨테이너 이미지를 만든다. Preview 환경에 배포해 E2E 테스트를 돌리고, 오류가 나면 로그를 확인해 다시 수정한다. 마지막에는 변경 파일과 테스트 결과, 품질 게이트와 배포 상태를 근거로 PR을 만든다.

이때 에이전트의 결과는 “코드를 작성했다”가 아니라 “무엇을 어떻게 검증했는가”가 된다.

AI가 전달 성과를 높이는지에 대한 연구도 단순하지 않다

DORA의 2024년 분석에서는 AI 도입이 25% 증가할 때 소프트웨어 전달 처리량이 1.5%, 전달 안정성이 7.2% 낮아지는 연관성이 관찰됐다. 그러나 2025년 DORA 보고서에서는 AI 활용 증가가 더 높은 처리량과 더 높은 불안정성에 동시에 연관되는 것으로 나타났다.

두 결과의 방향이 완전히 같지 않다. 따라서 특정 연도의 수치 하나를 가져와 “AI는 개발 성과를 떨어뜨린다”거나 “AI는 무조건 생산성을 높인다”고 말하면 곤란하다. 두 연구 모두 관찰된 연관성을 다루며, 단순한 인과관계를 증명한 것도 아니다.

다만 여러 결과를 관통하는 설명은 비교적 일관된다.

AI는 조직이 이미 갖고 있던 개발 시스템을 증폭한다. 내부 플랫폼, API, 테스트와 피드백 체계가 좋은 조직에서는 변경 속도를 높인다. 반대로 도구가 단절돼 있고 테스트가 취약한 조직에서는 기술 부채와 검증 부담까지 빠르게 늘릴 수 있다. DORA의 2025년 보고서도 AI의 역할을 기존 조직 시스템의 강점과 약점을 확대하는 증폭기로 설명한다.

물론 모든 개인 프로젝트에 Kubernetes, Argo CD, OpenTelemetry와 복잡한 보안 게이트를 설치해야 한다는 뜻은 아니다.

한 번 만들고 끝나는 실험과 반복 배포할 서비스는 요구사항이 다르다. 다만 여러 에이전트가 지속적으로 코드를 수정하고, 실제 사용자가 있는 시스템에 배포하기 시작했다면 최소한 재현 가능한 빌드와 자동 테스트, 버전이 붙은 산출물 저장소는 필요하다.

웹서비스가 아니어도 마찬가지다.

CLI, 데스크톱 애플리케이션, 펌웨어와 임베디드 프로그램도 빌드한 바이너리를 저장할 곳이 필요하다. 운영체제, CPU 아키텍처와 하드웨어 조합별로 테스트할 환경이 있어야 하고, 체크섬과 릴리스 이력도 남겨야 한다. 위험 수준에 따라 SBOM이나 서명도 고려할 수 있다.

코드 생성 속도가 빨라질수록 산출물을 검증하고 관리하는 체계의 가치도 함께 커진다.

GitOps와 관측성은 에이전트의 작업 범위를 분명하게 만든다

Kubernetes 환경에서 에이전트를 사용할 때 GitOps는 특히 잘 맞았다.

운영 클러스터의 관리자 권한을 에이전트에게 직접 주고 명령을 실행하게 하는 것보다, 배포 저장소의 선언을 수정하고 PR을 만들게 하는 편이 안전하다. 정책과 테스트를 통과한 변경만 병합하고, Argo CD 같은 컨트롤러가 실제 상태를 원하는 상태에 맞춘다.

OpenGitOps는 GitOps의 핵심을 선언적 상태, 버전 및 변경 이력, 자동 Pull, 지속적인 Reconciliation으로 정의한다.

이 방식에서는 에이전트가 무엇을 변경하려는지 Diff로 확인할 수 있다. 승인 절차를 넣을 수 있고, 실제 클러스터 상태가 선언과 달라졌을 때 Drift도 감지할 수 있다. 문제가 생기면 특정 Git 리비전을 기준으로 되돌릴 수 있다.

무엇보다 에이전트가 실행했던 일회성 명령을 기억할 필요가 없다. 원하는 상태가 저장소에 남는다.

관측성은 그다음 피드백을 제공한다.

OpenTelemetry는 Trace, Metric, Log 등의 텔레메트리를 생성하고 수집·전송하기 위한 표준화된 프레임워크이자 도구 모음이다. OpenTelemetry 자체가 저장 및 시각화 백엔드인 것은 아니며, 수집한 데이터는 Prometheus, Tempo, Jaeger 등의 백엔드로 보낼 수 있다.

에이전트가 배포 전후의 오류율과 지연 시간, Pod 재시작 횟수, CPU Throttling, OOM, Slow Query와 Trace를 조회할 수 있다고 가정해 보자.

그러면 작업 흐름은 단순한 코드 수정으로 끝나지 않는다.

문제에 대한 가설을 세우고, 코드를 변경하고, 배포한 뒤 텔레메트리를 확인한다. 효과가 없거나 회귀가 발생하면 변경을 폐기하거나 이전 버전으로 되돌린다.

관측성이 없는 에이전트는 수정안을 제시한다. 관측성이 있는 에이전트는 수정 효과를 검증할 수 있다.

단, 운영 데이터에 접근한다고 해서 에이전트에게 곧바로 운영 쓰기 권한까지 줄 필요는 없다. 조회는 넓게 허용하더라도 배포, 롤백과 설정 변경은 PR, 정책 검사와 승인을 통과하도록 분리하는 것이 낫다.

어느 순간부터는 워크스테이션과 인프라가 느려지기 시작했다

코딩 에이전트 하나를 채팅 창 하나로 생각하면 실제 자원 사용량을 설명하기 어렵다.

에이전트는 저장소를 Clone하고, Git Worktree를 만들고, Language Server와 코드 인덱서를 실행한다. 빌드 도구와 테스트 프로세스를 띄우고, Docker 컨테이너와 로컬 데이터베이스를 사용한다. 웹 애플리케이션을 검증할 때는 Playwright나 Selenium 브라우저도 여러 개 실행한다.

여기에 GitHub Actions Runner, MCP 서버, 모니터링 스택과 여러 개의 에이전트 세션이 함께 돌아간다.

내 개발 워크스테이션은 128GB 메모리와 7960X CPU를 사용한다. 개인 개발용으로는 충분히 여유로운 사양이라고 생각했다. 하지만 여러 프로젝트의 컨테이너와 Runner, Codex와 Claude, 브라우저 테스트를 동시에 실행하면 평상시에도 메모리 사용량이 70~80GB에 도달한다.

에이전트 세션이 30개를 넘으면 7960X에서도 전체 반응이 느려지는 것이 체감된다.

30개의 에이전트 세션은 채팅 창 30개가 아니다. 빌드, 테스트, 브라우저, 컨테이너와 파일 인덱싱 작업이 겹쳐 실행되는 30개의 개발 워크로드에 가깝다.

디스크도 예상보다 빠르게 부족해진다. 컨테이너 이미지와 레이어, 빌드 캐시, Git Worktree, 테스트 결과, 로그와 Trace가 계속 쌓인다. 관측성을 강화할수록 저장해야 할 데이터도 많아진다. Retention과 Log Rotation을 제대로 설정하지 않으면 “개발을 도와주는 인프라”가 오히려 개발 머신을 멈추게 한다.

이 문제는 더 큰 워크스테이션을 사는 것만으로 해결되지 않는다.

에이전트 세션에도 CPU와 메모리 제한, 동시 실행 수, 우선순위와 만료 시간이 필요하다. 실패한 브라우저와 컨테이너를 정리해야 하고, 빌드와 테스트는 필요에 따라 별도의 Runner로 보내야 한다. 오래된 로그와 Artifact, Worktree를 정리하는 수명주기도 필요하다.

결국 개인 개발 환경에도 작은 규모의 스케줄러와 플랫폼 운영이 들어오기 시작한다.

사람에게 넉넉한 API 한도가 에이전트에는 부족할 수 있다

GitHub의 API 한도도 비슷하다.

현재 일반 인증 사용자의 REST API 기본 한도는 시간당 5,000회다. GitHub Actions의 기본 GITHUB_TOKEN은 저장소당 시간당 1,000회이며, 별도의 동시 요청 및 Secondary Rate Limit도 적용된다. Enterprise Cloud 등 계정 조건에 따라 더 높은 한도가 제공될 수 있다.

사람 한두 명이 개발할 때는 상당히 넉넉한 숫자다.

하지만 여러 에이전트가 저장소, Issue, PR, Check, Workflow와 Artifact 상태를 반복해서 조회하면 금방 체감되는 제약이 된다. 특히 각 에이전트가 같은 정보를 따로 조회하면 실제 작업량보다 API 호출량이 훨씬 커진다.

GitHub Actions 캐시도 현재 저장소당 기본 10GB이며 설정에 따라 확장할 수 있지만, 설정된 한도를 넘으면 오래된 캐시가 제거된다. 캐시가 큰 프로젝트에서는 저장과 제거가 반복되면서 기대했던 만큼 빌드 시간이 줄지 않을 수 있다.

한 가지 해법은 Gitea 같은 자체 형상 관리 시스템과 Self-hosted Runner, 내부 Container Registry와 Artifact Repository를 운영하는 것이다. 내부 네트워크에서 코드, 이미지와 캐시를 이동하면 외부 API 의존성과 전송 지연을 줄일 수 있다.

다만 자체 구축이 무조건 더 싸거나 쉬운 것은 아니다.

Gitea를 설치하는 것과 안정적으로 운영하는 것은 다른 일이다. 백업, 고가용성, 보안 패치, 업그레이드, Runner 격리, 스토리지와 Artifact 수명 관리를 직접 책임져야 한다.

그래서 처음부터 모든 것을 자체 구축하기보다는 GitHub에 Self-hosted Runner와 내부 Registry를 붙이고, Git Mirror와 검색 캐시를 추가하는 식으로 단계적으로 확장하는 편이 현실적이다. API 한도, 망 분리, 데이터 지역성이나 성능 요구가 분명해졌을 때 자체 형상 시스템을 검토해도 늦지 않다.

개발 거버넌스의 대상이 사람에서 에이전트까지 넓어졌다

과거의 소프트웨어 엔지니어링 조직은 사람을 대상으로 개발 규칙을 만들었다.

브랜치 전략, 코딩 규칙, 테스트 기준, 배포 승인, Secret 관리와 장애 대응 절차를 문서화하고 교육했다. 이런 활동은 때로 불필요한 절차로 취급되기도 했지만, 여러 사람이 같은 시스템을 안전하게 변경하기 위해 필요한 장치였다.

에이전트 시대에도 이 규칙은 사라지지 않는다.

오히려 사람이 하루에 몇 번 하던 변경을 에이전트는 훨씬 빠른 속도로 반복할 수 있기 때문에 더 명확한 규칙이 필요하다. 잘 설계된 자동화도 빠르게 반복되지만, 잘못된 방식 역시 빠르게 확산된다.

달라지는 것은 규칙을 전달하는 방법이다.

사람에게 위키 페이지를 읽으라고 안내하는 것만으로는 부족하다. 에이전트가 실제 작업 중에 규칙을 발견하고, 위반할 수 없도록 만들어야 한다.

저장소의 기본 규칙과 빌드 명령은 AGENTS.md나 CLAUDE.md에 둘 수 있다. 반복 작업은 Skill로 만들고, 반드시 실행돼야 하는 검사는 Hook이나 CI 단계로 강제할 수 있다. 운영 정책은 OPA나 Admission Policy처럼 코드로 평가할 수 있다.

OpenAI는 Skill을 지침, 참고 자료와 선택적 스크립트를 하나의 재사용 가능한 워크플로로 묶는 형식으로 설명한다. Claude Code의 Hook은 파일 수정이나 작업 종료 같은 수명주기 시점에 명령을 실행해, 모델이 실행 여부를 판단하는 것과 별개로 규칙을 강제할 수 있다.

이 구분이 중요하다.

Skill은 에이전트가 따라야 할 방법을 알려준다. Hook과 정책은 에이전트가 반드시 지켜야 할 경계를 만든다. 중요한 규칙을 프롬프트에만 적어두면 모델이 잘 해석하기를 기대해야 하지만, CI나 Hook으로 만들면 규칙 위반 시 작업을 실제로 중단할 수 있다.

예를 들어 운영 배포 Skill에는 단순한 배포 명령만 들어가서는 안 된다.

어떤 저장소와 환경에 적용되는지, 어떤 테스트를 통과해야 하는지, 이미지가 Digest로 고정됐는지, 취약점 검사를 통과했는지, 승인된 PR인지, 배포 후 어떤 지표를 확인할지와 어떻게 롤백할지를 함께 정의해야 한다.

조직의 정책은 Skill 설명문에만 맡기지 않고 실행 단계에서 확인해야 한다. OPA는 CI/CD에서 설정과 산출물을 검증하고, 코드가 운영 환경에 도달하기 전에 조직 정책을 적용하는 Policy as Code 방식에 사용할 수 있다.

Skill 자체도 코드처럼 다뤄야 한다.

Skill에는 실행 가능한 스크립트와 외부 도구 접근 방법이 포함될 수 있다. 출처가 불분명한 Skill에 셸 권한과 Secret을 함께 제공하면 새로운 공급망 공격 경로가 된다. OWASP도 자율적으로 계획하고 도구를 실행하는 에이전트 시스템을 별도의 보안 대상으로 다루고 있다.

공유 Skill은 최소한 버전 관리, 리뷰와 테스트를 거쳐야 한다. 운영 권한을 사용하는 Skill이라면 허용된 도구와 환경, 필요한 권한, 소유자와 변경 이력까지 남기는 것이 좋다.

에이전트에도 고유한 신원과 작업 범위가 필요하다

모든 에이전트가 한 사람의 Personal Access Token과 관리자 권한을 공유하게 해서는 안 된다.

어떤 에이전트가 어떤 작업을 했는지 구분할 수 없고, 토큰이 유출됐을 때 피해 범위도 지나치게 커진다. 가능하다면 에이전트나 작업 유형별로 별도의 Identity를 사용하고, 짧은 수명의 Credential과 최소 권한을 제공해야 한다.

코드 탐색 에이전트는 읽기 권한만 있으면 된다. PR을 만드는 에이전트와 배포를 승인하는 주체도 분리할 수 있다. 운영 환경의 변경은 사람이 승인하거나 정책을 통과한 경우에만 허용해야 한다.

멀티 에이전트 환경에서는 권한뿐 아니라 작업 소유권도 필요하다.

각 에이전트에 독립된 Worktree와 브랜치를 할당하고, 동일 파일이나 모듈을 동시에 수정하지 않도록 작업 범위를 나눠야 한다. 작업 Queue와 Lease, Heartbeat를 통해 멈춘 작업을 회수하고, 토큰·CPU·API 예산을 넘은 작업을 중단할 수 있어야 한다.

과거의 개발 거버넌스가 사람을 통제하기 위한 절차였다면, 에이전트 거버넌스는 자동화가 안전하게 움직일 수 있는 실행 경계를 만드는 작업에 더 가깝다.

에이전트도 IDP의 사용자가 되어야 한다

Internal Developer Platform은 개발자가 조직의 인프라와 도구를 일관된 방식으로 사용할 수 있게 만든다.

서비스를 새로 만들고, 저장소와 파이프라인을 생성하고, Preview 환경을 배포하고, 운영 상태와 담당 팀을 찾는 일을 표준화한다. 지금까지는 주로 개발자 포털과 CLI 형태로 제공됐다.

에이전트 시대에는 같은 플랫폼에 기계가 사용할 수 있는 인터페이스가 필요하다.

그렇다고 사람용 IDP와 별도로 ‘에이전트 전용 그림자 플랫폼’을 하나 더 만드는 것은 좋지 않다. 사람과 에이전트가 서로 다른 서비스 정보와 정책을 보면 금방 불일치가 생긴다.

하나의 Source of Truth 위에 사람용 UI와 에이전트용 API 또는 MCP 인터페이스를 함께 제공하는 방식이 낫다.

Backstage의 Software Catalog는 서비스, 라이브러리, 데이터 파이프라인 등의 소유권과 메타데이터를 중앙에서 관리하고, Git에 저장된 메타데이터 파일을 기반으로 이를 조회할 수 있게 한다.

이런 Catalog를 에이전트가 읽을 수 있다면 작업을 시작하기 전에 필요한 정보를 스스로 확인할 수 있다.

이 서비스의 소유 팀이 누구인지, 애플리케이션 저장소와 배포 저장소가 어디인지, 어떤 빌드와 테스트 명령을 사용하는지, 의존 서비스와 운영 SLO가 무엇인지, 장애 Runbook과 대시보드는 어디에 있는지 찾을 수 있다.

여기에 Preview 환경 API, CI/CD 상태, Artifact Registry, Secret Broker, 관측성 조회 API와 Policy Engine을 연결하면 에이전트가 조직의 표준 경로 안에서 작업할 수 있다.

에이전트를 위한 커뮤니티는 채팅방이 아니라 검증된 지식 기반이다

개발자는 공식 문서만으로 조직의 모든 시스템을 배우지 않는다.

사내 Q&A, 장애 회고, 코드 리뷰와 동료의 경험을 통해 “실제로는 어떻게 해야 하는지”를 배운다. 에이전트도 이런 지식에 접근해야 한다.

다만 에이전트 커뮤니티를 에이전트끼리 자유롭게 글을 쓰는 채팅 공간으로 생각하면 위험하다. 잘못된 답변이 검색 결과에 남아 다른 에이전트에 반복 인용되면 같은 실수가 조직 전체로 퍼질 수 있다.

에이전트가 활용할 지식에는 적용 환경과 제품 버전, 재현 조건, 검증 명령, 답변 소유자와 마지막 확인 시각이 함께 들어가야 한다. 오래된 답변은 만료되거나 새 답변으로 대체됐다는 표시가 필요하다.

사내 Q&A나 지식 공유 서비스를 코드 검색, 운영 Runbook과 Search Gateway에 연결할 수 있다. 에이전트가 제안한 해결책은 곧바로 공식 답변으로 올리지 않고, CI나 실제 환경에서 검증한 뒤 담당 팀의 승인을 거쳐 채택하는 편이 좋다.

반복적으로 검증되고 절차가 안정된 답변은 문서에서 끝내지 않고 Skill로 승격할 수 있다.

이렇게 되면 커뮤니티의 지식이 단순한 검색 결과에 머무르지 않고, 재사용 가능한 자동화로 발전한다.

토큰보다 ‘검증된 변경’을 측정해야 한다

1,000억 토큰을 사용했다는 사실은 내가 에이전트를 많이 사용했다는 점만 보여준다.

그 토큰으로 얼마나 좋은 결과를 만들었는지는 설명하지 못한다. 많은 토큰이 복잡한 문제 해결을 의미할 수도 있지만, 같은 오류를 반복했거나 검색과 테스트 환경이 나빴다는 뜻일 수도 있다.

조직에서 에이전트의 생산성을 측정한다면 토큰 소비량을 단독 지표로 사용해서는 안 된다.

DORA는 현재 변경 리드타임, 배포 빈도, 실패한 배포의 복구 시간, 변경 실패율과 배포 재작업률이라는 다섯 가지 소프트웨어 전달 성과 지표를 제시한다. 에이전트 도입 전후에도 먼저 이런 결과가 실제로 좋아졌는지 확인해야 한다.

여기에 에이전트 특화 지표를 추가할 수 있다.

나는 작업이 승인 가능한 PR까지 도달하는 데 걸린 시간, 사람이 다시 수정한 비율, 도구 호출 실패율, 자동 테스트에서 발견된 결함과 운영으로 빠져나간 결함을 함께 보는 편이 낫다고 생각한다.

비용을 보려면 단순한 토큰 총량보다 ‘승인되어 실제 반영된 변경 하나당 비용’을 보는 것이 유용하다. 모델과 검색 API, CI, Runner와 컴퓨팅 비용을 모두 포함해야 한다.

토큰 사용량도 쓸모가 없는 것은 아니다. 특정 작업이나 Skill에서 사용량이 비정상적으로 늘어나는지, 어느 모델이 같은 결과를 더 적은 시행착오로 만드는지 확인하는 운영 지표로 사용할 수 있다.

다만 토큰은 결과가 아니라 투입량이다. 반드시 작업 성공률, 품질과 전달 속도 옆에 놓고 봐야 한다.

전통적인 소프트웨어 엔지니어링은 사라지지 않았다

처음에는 더 좋은 모델을 사용하면 대부분의 문제가 해결될 것이라고 생각했다.

실제로 모델 성능은 중요하다. 좋은 모델은 더 나은 계획을 세우고, 적절한 도구를 선택하며, 잘못된 가설에서 더 빨리 빠져나온다. 모델 간 성능 차이가 사라졌다는 이야기는 아니다.

다만 충분히 좋은 모델을 사용한 뒤에는 다른 요소가 더 자주 병목이 됐다.

현재 정보를 정확하게 찾을 수 있는지, 코드를 자동으로 검증할 수 있는지, 배포 후 결과를 관측할 수 있는지, 실패했을 때 되돌릴 수 있는지, 여러 에이전트의 변경을 안전하게 조정할 수 있는지가 실제 생산성을 좌우했다.

바이브 코딩의 생산성은 프롬프트에서 완성되지 않는다.

Git, CI/CD, Artifact Repository, Container Registry, GitOps, 관측성, 보안 정책과 IDP가 연결돼야 코드 생성이 실제 제품의 변경으로 이어진다.

AI가 등장하면서 재현 가능한 빌드, 자동화된 테스트, 형상 및 산출물 관리, 최소 권한, 빠른 복구와 지식 공유 같은 전통적인 소프트웨어 엔지니어링의 원칙이 낡아진 것은 아니다.

오히려 에이전트가 코드를 만드는 속도가 빨라지면서 그 원칙이 더 중요해졌다.

과거에는 이 체계를 주로 사람이 사용했다. 이제는 사람과 함께 일하는 에이전트도 같은 체계를 사용할 수 있어야 한다. 문서는 검색 가능해야 하고, Runbook은 실행 가능해야 하며, 중요한 정책은 코드와 시스템으로 강제돼야 한다.

1,000억 토큰을 사용하고 나서 남은 결론은 어떤 모델이 가장 똑똑한가가 아니었다.

앞으로의 차이는 누가 더 많은 코드를 생성하느냐보다, 그 속도를 검증 가능하고 운영 가능한 소프트웨어 변경으로 받아낼 수 있는 개발 시스템을 갖췄느냐에서 벌어질 것 같다.