이번에는 분석용 AI Agent를 구축한 내용을 정리해보겠습니다.

1. Pipeline & Architecture

📌 주요 포인트

• 기존 파이프라인 재활용 (GitOps, Alert)
• SSOT(Single Source Of Truth): GitHub
• AWS ECR 사용

우선 에이전트 개발을 위한 추가 파이프라인을 구축하지 않고자 했습니다.(관리 포인트를 줄이고자)
앞서 구축한 GitOps 파이프라인과 Alert 파이프라인을 재활용 하는 방법을 선택했습니다.
또 이번에도 GitHub 소스 코드를 단일 진실 공급원으로 두어 관리 포인트를 줄였습니다.
마지막으로 에이전트 개발 코드를 이미지로 관리하고자 AWS의 Elastic Container Registry(ECR)을 도입했습니다.

⚠️ ArgoCD core issue

사진에서 볼 수 있듯이 ArgoCD core 가 ECR을 바라보지 못하는(변경사항 등을 감지하지 못하는) 문제가 있었습니다.

이는 ArgoCD core가 Git만 보도록 의도적으로 설계 되어 있기 때문이었습니다.

📌 참고 문서 (설계 의도)
https://github.com/argoproj/argo-cd/blob/master/docs/proposals/headless-argocd.md#provide-an-easy-way-to-deploy-argo-cd-without-apiui

📌 참고 문서 (매니페스트)
https://github.com/argoproj/argo-cd/blob/master/manifests/core-install.yaml
(desired state를 넣는 통로가 Git에 연결된 Application/ApplicationSet CRD 뿐이므로 구조적으로 Git만 바라보는 형태)

해결

ArgoCD의 Image Updater 라는 컴포넌트를 추가 구축을 하면 이 문제를 해결할 수 있었습니다.

하지만 부트캠프 당시 프로젝트 규모 및 추가 구축에 드는 리소스를 고려해보았습니다.
✅ 해당 컴포넌트를 추가 구축하지 않고 CI 단계에서 ArgoCD가 변경사항을 감지할 수 있도록 values.yaml 파일 내 image.tag 한 줄만 자동으로 변경해주는 자동화 봇 PR을 구축했습니다.

(프로젝트 당시 비교를 위한 표)

봇 PR (자동화)

에이전트 개발 코드를 병합하면, CI가 돌 때 자동으로 봇 PR이 생성됩니다. 그 내용은 사진과 같이 ArgoCD가 감지할 수 있는 values.yaml 파일의 image.tag 를 자동으로 변경해줍니다. 개발자(나)는 에이전트 코드 병합과 동시에 올라오는 이미지 태그 변경 PR을 병합하기만 하면 되는 플로우로 위 문제를 해결했습니다.

AI Agent Workflow - Single Shot

신속한 알람(Alert)과 에이전트 분석 내용은 워크플로우를 분리

• 그 이유로는 구체적인 분석 및 해결 가이드라인 제공 또한 중요하지만, 이상 신호 감지 시 관리자에게 알람을 신속하게 보내는 것이 훨씬 중요하기에 두 워크플로우(알람 | 에이전트 분석 내용)를 분리시켰습니다.

Workflow를 간단하게 도식화 해보았습니다.

• Flow 1: Slack 알람
  • Alertmanager를 통해 알람 발생 시 곧바로 관리자용 Slack 채널에 알람을 보내게 됩니다.
• Flow 2: AI Agent 분석
  • 1차 컨텍스트 수집 (비동기, 1회)
    • loki.fetch() : +-15m Log 수집
    • vm.fetch() : +- 15m Metric 수집
    • runbook.find() : 매칭되는 runbook 탐색
  • AWS Bedrock 호출
    • 1차 컨텍스트를 종합하여 Bedrock(Sonnet 4.5 -> Nova Pro) 1회 호출
    • (Sonnet 모델은 꽤 많이 비싸더라구요..)

실제 Alert + Analzer AI Agent

위 과정을 통해 온프레미스 노드에서 이상 신호 감지 시 즉시 알람이 발생하고 (인프라 리소스 감지 봇 - Slack 댓글), 이어서 해당 댓글의 스레드에 분석용 AI Agent(AI 분석 봇 - Slack 댓글의 스레드)가 작성한 내용이 작성됩니다.

AI Agent Workflow - Agentic Loop

🤔(나): 근데 AI한테 "한 번"만 물어보는걸 '에이전트'라고 할 수 있을까? 또 분석 내용과 해결 가이드라인을 조금 더 자세하게 알려줄 수는 없을까?

• AI Agent가 메인인 프로젝트는 아니었지만, 다소 단조롭다는 생각에 조금 더 고도화를 시켜보고자 했습니다.

'Agentic Loop' 라는 용어가 있더군요?! 용어를 정의한 곳마다 약간의(?) 의미 차이가 있었지만, 저는 'Agent가 스스로 판단하여 반복적으로 작업하고 만족하는 결과 도출 시 반복 작업 종료'를 목표로 고도화를 진행해보았습니다.

고도화 요소

• '1차 컨텍스트 수집 + 매칭되는 runbook 탐색' : 기존과 동일
• Agent가 사용할 수 있는 도구(Tool Set)를 선정 및 전달
  • PromQL : VictoriaMetrics의 시계열 메트릭 데이터를 조회/집계/연산하기 위한 쿼리 언어
  • LogQL : Loki에서 로그를 라벨로 필터링하고 메트릭처럼 집계할 수 있게 해주는 로그 쿼리 언어
  • list_recent_alerts : Alertmanager에서 최근 발생했거나 현재 활성 상태인 alert 목록을 조회하는 함수

Bedrock 첫 호출 시 위에서 수집한 1차 컨텍스트와 Tool Set을 함께 전달합니다.
이때 Agent가 스스로 판단하기에 답변을 할 수 있다면 즉시 답변을 보내고, 답변 결과가 부족하다고 판단된다면 Tool을 호출하여 결과를 추가하며 반복적인 작업(loop)을 하게 됩니다.

이렇게 개선된 답변을 Slack 댓글의 스레드에 남기게 되는 구조입니다.

Agentic Loop에 대한 안전망

🤔(나): 에이전트가 스스로 판단하여 반복적인 작업을 하는 것은 좋은데,, 너무 많은 권한을 주는건 아닐까? (감히 AI 주제에?)

이러한 고민을 하며 안정망 을 만들어야겠다(?) 라는 생각이 들었고, 나름의 안정 장치들을 마련해보았습니다.

안전망

• 무한 Loop 방지 : MAX_ITERATIONS=5 를 설정하여 자체적인 Loop 횟수를 5회로 제한
• 중복 호출 detect : 같은 tool. args 두번째 호출 즉시 차단
• query 폭주 방지 : lookbakc <= 6h, limit <- 500 라인 강제
• Mutating 명령 봉쇄 : 제공 tool은 전부 read-only, 에이전트의 리소스 수정 / 삭제 차단
• 즉시 Fallback : Agent 에러 시 Single-Shot 경로 즉시 복귀

최종 Workflow

1. Alertmanager를 통해 Alert 발생
2. 관리자용 Slack에 에러 내용 알람: 인프라 리소스 감지 봇(고오스)
3. Agentic Loop 방식을 통해 에러 내용 분석 및 해결 가이드라인을 Slack 댓글의 스레드에 제공: AI 분석 봇(고우스트)
4. 플랫폼 관리자가 이를 확인하여 빠른 대응 가능: 관리자(나: 팬텀)

---

회고

Observability 회고

이렇게 부트캠프의 최종 프로젝트를 잘 마무리하게 되었습니다. 애플리케이션 레벨이 아닌 온프레미스 노드의 리소스를 관측은 이번에 처음 해보았는데 고려해야하는 부분들이 기존과 달라서 학습에 시간을 꽤 많이 쏟았던 것 같습니다.

어떻게 보면 옵저버빌리티에서 가장 기본적이고, 기초적인 내용을 구축한 것 같은데 이번 기회에 제대로 구축하길 잘한 것 같습니다.

또 처음 써보는 다양한 오픈소스들(OpenTelemetry, VictoriaMetrics, Loki, ArgoCD 등)이 있었는데 역시 클라우드 네이티브 생태계는 강력하고 재밌는 기술들이 참 많은 것 같습니다. 특히, ArgoCD와 OpenTelemetry는 평소에 관심을 갖고 있었는데 이번 기회에 나름 잘(?) 써보았기에 좋은 경험이었습니다.(이제 홈랩에 붙이면 딱일 것 같습니다.ㅎㅎ)

협업 회고

음,, 많이 힘들었습니다. 이미 어느정도 진행이 된 프로젝트가 아닌, 아이디어 기획부터 시작하는 프로젝트이다보니 개발 외적으로 많은 에너지가 쓰인 것 같습니다. 주제 선정에만 4주가 걸렸던 것 같고(?).. 개발에 익숙하지 않은 팀원들도 있었기에 팀원 간의 작업 속도나 기술적인 소통에도 큰 어려움이 많았던 것 같습니다.

최대한 이를 줄여보고자 팀 내 기술 세미나도 진행해보고, 팀원 간 공유를 위한 문서화에 많은 시간을 쏟았던 것 같습니다..(모두에게 도움이 되었던 순간이었으면 좋겠네요..ㅎㅎ)
새로운 협업 툴도 많이 사용하게 되었는데 대표적으로 Jira 와 Confluence 를 깊게 사용해볼 수 있어서 좋았습니다. (혼자 Jira를 써보았을 때는 큰 효과를 못봤습니다.ㅋㅋ)

개인적으로 시간이 더 주어졌더라면, 많은 것들을 구축해보았을텐데 프로젝트 기간이 짧았다는 점에 아쉬움이 많이 남는 것 같습니다.
마지막으로, 취업에 성공했음에도 끝까지 프로젝트에 함께 참여해준 여*환 에게 매우매우 많이 고맙다는 말을 전하고 싶습니다.ㅎㅎ

프로젝트 GitHub 저장소

https://github.com/TEAM-High-Cloud/Observability
(ReadME 작성도 해야겠네요...)

최고의 동료 Claude.. 둘이서 많은 작업을 했습니다. ㅋㅋ