CodeBuddy NPC는 Git 업무 흐름을 어떻게 AI 전달 루프로 바꾸나

CodeBuddy NPC는 AI 코딩을 별도 채팅창에서 꺼내, 개발팀이 실제로 소프트웨어를 배포할 때 쓰는 Git 산출물 안으로 넣으려는 텐센트 클라우드의 시도다. 개발자는 요구사항, 저장소 코드, 오류 로그를 매번 AI에게 복사해 넣는 대신 Issue나 풀 리퀘스트(PR)에서 NPC를 호출할 수 있다. 이후 NPC는 CNB(텐센트 클라우드 개발 플랫폼) 안에서 비동기적으로 작업을 이어 간다. 제공된 자료에서는 정식 출시일이 엇갈린다. 동시대 보도 다수는 2026년 7월 23일을, 이후 보도는 7월 29일을 언급한다. 625

‘AI Native Git’이 뜻하는 것

텐센트가 말하는 AI Native Git은 Git 저장소와 그 주변의 개발 흐름을 AI 에이전트의 운영 메모리로 쓰는 접근이다. 여기에는 다음 기록이 포함된다.

• Issue: 과제의 배경, 목표, 논의
• 코드 저장소와 이력: 프로젝트 구조와 과거 변경 사항
• PR: 제안된 변경 내용과 리뷰 피드백
• CI/CD 결과: 빌드 실패, 테스트 결과, 수정 피드백

이는 코드 자동완성이나 일회성 챗봇 세션과는 다르다. 에이전트는 팀이 이미 사용하는 지속적인 개발 기록을 바탕으로 일하고, 변경과 검증 결과도 같은 기록에 남기는 방식이다. 텐센트는 기존 Git, Docker, CI/CD, 품질 게이트를 재사용해 커밋 → 검증 → 수정 → 재검증의 순환을 구성한다고 설명한다. 123

Issue나 PR에서 NPC 호출하기

CNB 문서는 두 가지 NPC 이벤트를 명시한다. issue.comment@npc는 Issue 설명이나 댓글에서 NPC가 언급될 때, pull_request.comment@npc는 PR 설명·리뷰·리뷰 댓글·일반 댓글에서 NPC가 언급될 때 실행된다. 35

사용 방식은 동료에게 일을 배정하는 것과 비슷하다. Issue 또는 PR에서 적합한 역할을 멘션하고 과제를 적으면 된다. 조사, 구현, 리뷰 같은 요청을 별도의 대화형 코딩 세션을 계속 열어 두지 않고도 맡길 수 있다는 구상이다.

저장소별 NPC 역할은 .cnb/settings.yml에 정의할 수 있다. 역할 이름, 프롬프트, 지식 베이스 가져오기, UI 설정 등을 포함할 수 있으며, 필요하면 .cnb.yml에서 동작과 실행 이미지를 맞춤 설정한다. 별도 설정이 없을 때 CNB 문서는 기본 NPC 런타임 이미지를 사용한다고 안내한다. 3235

즉, 하나의 범용 AI 대신 역할을 나눈 모델을 만들 수 있다. 예를 들어 코드 구현 역할과 코드 리뷰 역할을 두고, 결과가 평가될 바로 그 개발 흐름에서 각 역할을 호출하는 식이다.

과제 배정부터 PR·CI 수정까지

텐센트가 설명하는 CodeBuddy NPC 흐름의 핵심은 비동기 실행이다. 과제를 받은 에이전트는 저장소 맥락을 읽고, 계획을 세우며, 코드를 수정하고, PR을 제출한 뒤 테스트를 실행할 수 있다. CI가 실패하면 결과를 읽어 문제를 진단하고 다음 검증을 위해 변경을 고칠 수 있다. 개발자가 모든 단계를 실시간 채팅에서 지켜볼 필요는 없다는 설명이다. 16

흐름은 대체로 다음과 같다.

1. Issue 또는 PR에서 작업을 배정한다. 멘션이 NPC 이벤트를 실행한다.
2. 개발 맥락을 읽는다. 과제, 저장소, 기존 변경, 과거 워크플로 기록을 활용한다.
3. 계획하고 구현한다. 접근법을 수립하고 코드 변경을 작성한다.
4. PR을 제출하고 검증한다. 테스트와 파이프라인 점검이 변경의 작동 여부를 확인한다.
5. 실패를 분석하고 반복한다. CI가 실패하면 결과를 읽고 수정한 뒤 다시 검증할 수 있다. 1623

이 때문에 텐센트는 이를 단순한 AI 보조 코딩 이상으로 규정한다. AI가 코드 조각을 제안하는 데 그치지 않고, 과제를 리뷰 가능한 테스트 완료 변경으로 바꾸는 과정에 참여하도록 설계됐다는 것이다.

CNB가 제공하는 실행 환경과 통제 장치

이 에이전트 흐름은 CNB의 저장소와 파이프라인 인프라를 기반으로 한다. CNB 파이프라인 설정에서는 Docker 이미지, Dockerfile로 빌드한 이미지, dev container 기반 환경, 볼륨 마운트, 러너 태그와 CPU 설정 등을 지정할 수 있다. 개발자 개인 PC의 설정에 의존하기보다 저장소가 정의한 재현 가능한 환경에서 작업을 실행할 수 있는 구조다. 34

CNB는 재사용 가능한 Docker 캐시도 지원한다. 후속 빌드에서 의존성 등 네트워크 리소스를 반복 다운로드하는 일을 줄일 수 있다. 33

권한 측면에서 CNB는 파이프라인 실행 중 CNB_TOKEN을 제공한다. 문서에 따르면 이 임시 토큰은 코드와 산출물의 가져오기·푸시, API 호출에 사용할 수 있고, 파이프라인 종료 후 폐기된다. 권한은 어떤 이벤트가 실행을 촉발했는지에 따라 달라진다. NPC 실행 문서는 코드, PR, Issue, 댓글 접근과 같은 권한도 설명한다. 44

브랜치를 만들고 PR을 열거나 CI 실패에 반응하는 에이전트에는 모델 접근 권한만으로는 부족하다. 개발 시스템에 대한 범위가 정해진 접근 권한과 추적 가능성이 필요하다. CNB의 비밀 저장소 문서는 민감 정보에 대해 접근 제어, 작업 제한, 감사 로그, 워터마킹을 제공한다고 설명한다. 38

YAML 역할 정의가 중요한 이유

YAML로 NPC 역할을 정의하면 에이전트 행동의 일부를 저장소에 맞게 만들 수 있다. 역할 정의에는 프롬프트와 가져온 지식 소스가 들어가고, 연결된 파이프라인은 실행 방식을 정한다. 3235

이를 통해 하나의 개발 프로세스 안에서 서로 다른 운영 모드를 구성할 수 있다.

• 맥락을 수집하고 진행 경로를 제안하는 조사 역할
• 코드를 바꾸고 PR을 준비하는 구현 역할
• 요청에 따라 PR을 검토하는 리뷰 역할
• 더 큰 과제에서 여러 NPC 역할을 조율하는 방식

텐센트는 복잡한 작업을 위해 여러 NPC를 NPC Team으로 구성할 수 있다고 밝혔다. 문서는 역할과 이벤트의 기반 메커니즘을 뒷받침하지만, 역할 분담의 구체적 방식은 팀이 설계할 문제다. 63235

첫 요청 토큰을 90% 넘게 줄였다는 주장

텐센트는 공식 R&D NPC의 초기 토큰 소비량을 초기 버전의 2만 개 이상에서 약 2,000개로 낮췄다고 밝혔다. 90% 이상 감소한 수치다. 회사는 프롬프트, 도구 호출, CLI 출력, 캐시 적중률을 지속적으로 최적화한 결과라고 설명한다. 623

의미는 누적 비용에 있다. 에이전트 작업은 보통 여러 차례 모델 호출을 거치므로, 첫 요청의 맥락과 도구 오버헤드를 줄이면 전체 실행 비용의 기반도 낮아질 수 있다. 텐센트는 과제 복잡도에 따라 모델 전략을 선택할 수 있다고도 밝혔는데, 모든 작업에 동일한 모델 접근법을 적용하기보다 성능과 비용을 조정하겠다는 의미다. 1523

다만 이는 벤더가 공개한 효율 수치이며, 총비용이나 작업 품질을 독립적으로 검증한 벤치마크는 아니다. 실제 사용량은 저장소 크기, 과제 범위, 모델 선택, 재시도 횟수, 필요한 CI 작업량에 따라 달라진다.

텐센트가 ‘AI 엔지니어링 협업’이라고 부르는 이유

텐센트의 표현은 AI가 개발 생명주기에서 차지하는 위치가 달라진다는 뜻이다.

• AI 보조 코딩은 개발자의 코드 작성·수정을 돕는다.
• AI 기반 작업 실행은 하나의 분리된 작업을 위임한다.
• 텐센트가 말하는 AI 엔지니어링 협업은 과제 접수, 구현, 리뷰, 검증, 수정으로 이어진 연결된 과정 안에 에이전트를 둔다. 110

따라서 가장 현실적인 주장은 ‘완전 자율 배포’가 아니다. 핵심은 워크플로 통합이다. 기존 협업 산출물에서 과제를 배정하고, PR로 변경을 제안하며, CI와 품질 검사가 수용 전 피드백을 제공한다. 이 과정은 에이전트가 무엇을 요청받았고 무엇을 바꿨으며 시스템이 이를 어떻게 평가했는지에 대한 엔지니어링 이력을 남긴다. 144

도입을 검토하는 팀이라면, 기존 권한 체계와 테스트, 리뷰 규칙, 배포 게이트가 의미 있는 저장소 접근 권한을 가진 에이전트를 감독하기에 충분한지부터 점검해야 한다. CodeBuddy NPC는 루프의 일부 단계를 자동화할 수 있지만, 사람의 리뷰와 조직 차원의 통제를 없애지는 않는다.