GitLab Duo Agent Platform으로 배포 프로세스 자동화 (새 탭에서 열림)

GitLab Duo Agent Platform의 커스텀 에이전트를 활용하면 새로운 마이크로서비스를 기존 GitOps 배포 흐름에 자동으로 편입할 수 있다. 에이전트는 애플리케이션의 저장소 구조와 매니페스트, 파이프라인, Dockerfile을 분석해 필요한 설정을 생성하고 수정한다. 에이전트와 생성 결과가 GitLab 안에서 버전 관리·권한 통제되므로 자동화 속도와 엔터프라이즈 거버넌스를 함께 확보할 수 있다는 것이 글의 결론이다.

TanukiBank의 마이크로서비스 온보딩 사례

• 가상의 은행 애플리케이션인 TanukiBank에 intra-account-transfers 마이크로서비스를 추가하는 상황을 예로 든다.
• 기존 애플리케이션에는 계좌 간 송금 UI가 있지만 이를 처리할 백엔드 서비스가 없어 Transfer 버튼이 동작하지 않는다.
• 새 서비스는 기존 GitOps 배포 규칙에 맞게 다음 요소를 모두 구성해야 한다.
  • Kubernetes 배포 매니페스트
  • 컨테이너 이미지 빌드 및 전달 파이프라인
  • 이미지 자동 업데이트 설정
  • 네임스페이스, 포트, 호스트명 참조

TanukiBank의 GitOps 배포 구조

• GitLab 그룹에는 각 마이크로서비스를 담는 services 하위 그룹이 있다.
• 배포 과정은 두 프로젝트와 Flux 컴포넌트가 연계되는 구조다.
  • Tanuki Bank - Delivery: 환경별 배포 매니페스트와 전달 파이프라인 관리
  • Flux Config: Flux 관련 매니페스트 관리
  • Flux Image Automation Controller: 서비스 레지스트리의 새 이미지를 감지하고 Delivery 프로젝트의 매니페스트 갱신
  • Flux CD Controller: Delivery 프로젝트의 상태를 Kubernetes 클러스터의 실행 상태와 동기화
• 새 서비스가 추가되면 서비스 저장소, Delivery 프로젝트, Flux 설정을 모두 정확히 수정해야 한다.
• 수동 작업에서는 특정 파일이나 참조를 빠뜨릴 경우 배포 실패가 발생할 수 있다.

GitLab Duo를 이용한 시스템 프롬프트 생성

• GitLab Agentic Chat에 TanukiBank 그룹과 하위 그룹의 구조 및 파일을 분석하도록 요청한다.
• Duo는 다음 자료를 조사해 커스텀 에이전트용 시스템 프롬프트를 작성한다.
  • Kubernetes 매니페스트
  • 설정 파일
  • Dockerfile
  • 프로젝트 간 의존성
  • 기존 GitOps 규칙
• 생성된 프롬프트에는 다음과 같은 내용이 포함된다.
  • 에이전트가 따라야 할 작업 규칙
  • 결과 보고 방식
  • 사용할 도구
• 이 프롬프트는 현재 애플리케이션의 GitOps 구조를 반영한 것이므로, 향후 배포 방식이 바뀌면 다시 생성해야 한다.

커스텀 에이전트 생성 및 적용

• application-agents라는 별도 프로젝트를 만들어 에이전트를 관리한다.
• GitLab의 AI > Agents > Managed 메뉴에서 TanukiBank Microservice Onboarder 에이전트를 생성한다.
• 에이전트 생성 시 다음을 설정한다.
  • 이름과 설명
  • 공개 여부
  • Duo가 추천한 도구
  • 앞서 생성한 시스템 프롬프트
• 이후 에이전트를 GitOps를 담당하는 다음 프로젝트에서 사용할 수 있도록 활성화한다.
  • Tanuki Bank - Delivery
  • Flux Config
• 각 프로젝트의 Agentic Chat 에이전트 목록에 해당 에이전트가 표시되면 설정이 완료된 것이다.

Developer 플로우로 새 서비스 구현

• services 그룹에 intra-account-transfers 프로젝트를 만든다.
• 프로젝트 이슈에 마이크로서비스 요구사항을 작성하고 Generate MR with Duo를 실행한다.
• Developer foundational flow가 다음 작업을 자동으로 수행한다.
  • 이슈의 사양 분석
  • 서비스 코드 구현
  • 브랜치 생성
  • Merge Request 생성
  • 이슈와 MR 연결
• 로컬에서 curl 명령으로 동작을 확인한 뒤 MR을 병합한다.
• 파이프라인이 실행되어 새 서비스의 컨테이너 이미지를 서비스 프로젝트의 내장 레지스트리에 업로드한다.

커스텀 에이전트를 통한 GitOps 온보딩

• 서비스 자체는 생성됐지만 GitOps 설정에는 아직 등록되지 않은 상태다.
  • Delivery 프로젝트의 manifests/dev에 서비스 매니페스트가 없음
  • 전달 파이프라인에 서비스 참조가 없음
  • Flux Config의 image-update-automation.yaml에 이미지 자동화 항목이 없음
• 새 서비스 프로젝트에서도 TanukiBank Microservice Onboarder를 활성화한다.
• Delivery 프로젝트의 Agentic Chat에서 커스텀 에이전트를 선택한다.
• 서비스 이름과 호스트명을 전달해 온보딩을 요청한다.
• 에이전트는 새 서비스의 Dockerfile을 읽어 포트를 확인하고, 이에 맞는 매니페스트와 파이프라인 설정을 생성·수정한다.
• 제공된 글은 이 작업이 진행되는 지점에서 끝나므로, 이후 생성된 변경 사항과 실제 Kubernetes 배포 결과는 본문에 포함되어 있지 않다.

새 마이크로서비스 온보딩 절차가 반복적이고 규칙 기반이라면, 프로젝트 구조와 GitOps 규칙을 반영한 커스텀 에이전트를 만들어 자동화하는 것이 효과적이다. 다만 시스템 프롬프트가 현재 배포 구조에 강하게 의존하므로, GitOps workflow 변경 시 프롬프트와 에이전트 동작을 함께 재검토해야 한다.