매일 오전 9시에 QA 클러스터의 Node·Pod 상태와 컨테이너 취약점(CVE)을 점검하고 Teams로 보고하는 운영 도구가 필요했다. 요구사항과 검증 기준은 직접 정의하고, 코드 초안 작성과 반복적인 빌드·배포 명령에는 Cursor CLI와 MCP를 활용했다.
이 도구가 매일 정해진 시각에 Teams로 보내는 클러스터 상태·노드 브리핑.
무엇을, 무엇으로
- 목표: 매일 09:00 QA 클러스터 Node/Pod 상태 + 컨테이너 CVE 점검 → Teams 리포팅
- 스택: Go 1.22, Docker, Helm, Trivy, AKS
- 작업 환경: Cursor CLI (터미널 기반 AI 에이전트)
- MCP 활용 범위: Cursor CLI가 승인된 로컬 도구와 인프라 명령을 실행
MCP를 연결하면서 Cursor CLI가 코드 제안뿐 아니라 승인된 범위에서 빌드·배포·조회 명령을 실행할 수 있었다. 실행 권한과 대상 클러스터는 사전에 제한했고, 변경 결과는 직접 검토했다.
누가 무엇을 했나
작업은 다음과 같이 나눴다.
직접 수행한 작업
- 점검 범위와 리포트 형식 등 요구사항 정의
- 클러스터 접근 범위, 배포 방식과 검증 기준 결정
- Teams Workflow Webhook 준비 및 자격증명 관리
- 생성된 코드·Helm 차트·명령 검토와 최종 배포 판단
Cursor CLI를 활용한 작업
- 프로젝트 뼈대와 Go 코드 초안 작성
- Dockerfile·Helm 차트·배포 명령 초안 생성
- 승인된 명령 실행과 로그 수집
- 오류 원인 후보 제시 및 수정안 작성
- 반복적인 git 명령과 문서 정리
어떻게 시켰나
처음에는 .cursorrules에 프로젝트 규칙을 명시했다. 새 요구사항을 이 파일에 반영하고, 구현 과정에서도 해당 규칙을 기준으로 판단하도록 작업 절차를 정했다.
"Go로 K8s 클러스터 내 Pod 정보를 수집하고, Trivy로 보안 스캔을 수행하는 툴을 만들 거야. 결과는 Teams Webhook으로 보내줘. 프로젝트 구조를 생성하고 Dockerfile까지 작성해."
이 요청을 바탕으로 Cursor CLI가 main.go, go.mod, Dockerfile과 의존성의 초안을 만들었다. 생성된 코드와 권한 범위를 검토한 뒤 수정 작업을 이어 갔다.
배포도 터미널에서 그대로 이어졌다.
"현재 디렉터리의 Dockerfile을 빌드해서 사내 레지스트리에 push해줘. 그 다음 Helm Chart를 만들어서 QA 클러스터에 배포해."
Cursor CLI가 docker build/push, Helm 템플릿 생성, helm install 명령을 제안하고 승인된 순서에 따라 실행했다.
로그 수집부터 재배포까지 연결한 디버깅
배포 실패 시 상태 조회와 로그 수집부터 수정안 작성까지 한 세션에서 이어지도록 요청했다.
"배포된 Pod가 정상적으로 뜨지 않아. 현재 상태를 확인하고, 로그를 분석해서 원인을 파악한 뒤 코드를 수정해서 재배포해줘."
Cursor CLI는 kubectl get pods와 kubectl logs를 실행해 ConfigMap 파싱 오류를 원인 후보로 제시했다. 제안된 Config 로딩 로직 수정안을 검토한 뒤 이미지를 다시 빌드하고 helm upgrade를 실행했다. 마지막으로 Pod 상태와 리포트 전송 결과를 확인했다. 로그 수집·수정안 작성·재배포 명령을 한 흐름으로 연결한 덕분에 명령을 수동으로 전환하는 시간이 줄었다.
정량 효과
| 구분 | 기존 (엔지니어 단독) | AI 에이전트 활용 | 효과 |
|---|---|---|---|
| 소요 시간 | 약 16시간 (2 M/D) | 약 2.5시간 | 84% 단축 |
| 작업 방식 | 코드 ↔ 터미널 ↔ 검색 반복 | 단일 터미널 대화형 일괄 처리 | 컨텍스트 스위칭 최소화 |
| 디버깅 | 로그 → 검색 → 수정 → 재배포 | 로그 수집·원인 후보·수정안을 한 세션에서 처리 | 트러블슈팅 단축 |
그래서 얻은 결론
요구사항과 검증 기준을 먼저 정한 뒤 코드 초안과 반복 명령 실행에 Cursor CLI를 활용하니 운영 도구 개발 시간이 줄었다. 다만 인프라 접근 권한을 도구에 제공하는 만큼 명령 승인 범위, 자격증명 관리와 배포 후 검증은 엔지니어의 책임으로 남는다.
복잡한 작업일수록 구체적인 요구사항과 제한 조건이 필요했다. .cursorrules 같은 규칙 파일도 코드와 함께 형상 관리해야 결과를 재현할 수 있었다. 규칙 파일만으로 정확성을 보장할 수는 없으므로 코드 리뷰, 제한된 실행 권한과 배포 후 확인 절차를 함께 적용했다.
참고