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 변경 시 프롬프트와 에이전트 동작을 함께 재검토해야 한다.