월 250달러로 n8n을 활용해 DevOps 지원을 위한 AI 1차 대응 라인 구축하기 — Part 1

소규모 DevOps 팀이 채팅 분류(triage), CI/CD 진단, 첨부 파일 파싱을 어떻게 AI 에이전트에게 위임했는지 — 그리고 여전히 해결해야 할 과제는 무엇인지에 대하여.

저처럼 소규모 팀을 위해 인프라를 운영하고 있다면, 아마 이런 상황을 겪어보셨을 것입니다. 엔지니어링 조직은 계속 커지는데 DevOps 인력은 그대로인 상황 말이죠. 바이브 코딩(vibe-coding)의 부상과 함께 이러한 불균형은 특히 더 명확해졌습니다. 스튜디오의 개발 팀은 몇 달 만에 약 1.5배 성장했는데, 이는 모든 제품 관리자(Product Manager)가 자신만의 미니 애플리케이션을 원했기 때문입니다. 게다가 특정 지역에서 발생하는 가용성(availability) 문제의 빈도가 높아지면서 추가적인 골칫거리까지 생겼습니다.

그 결과, 저희 Slack 지원 채널의 메시지 흐름은 엔지니어의 업무 시간 중 상당 부분을 분류(triage)하는 데 소비할 정도로 늘어났습니다. 그리고 가장 좌절스러운 부분은, 모든 요청이 실제로 DevOps의 책임 영역은 아니었지만, 이를 확인하기 위해 매번 최소한의 얕은 진단(diagnostic) 과정이 필요했다는 점입니다.

이것이 바로 1차 대응(first line)을 AI 에이전트에게 위임하겠다는 아이디어가 나온 계기였습니다. 그 시점에 저희는 이미 알림에 의해 트리거되는 장애 분석 자동화를 구현했으며, 그 방식의 유효성을 입증한 상태였습니다. 동일한 패턴을 수동 채팅 요청으로 확장하는 것은 논리적인 다음 단계였습니다.

이 글은 두 부분으로 구성된 시리즈 중 첫 번째로, 저희가 다음과 같은 과정을 어떻게 수행했는지 설명합니다:

• 지난 1년간의 요청 흐름을 분류하고 자동화할 가치가 있는 카테고리를 선정했습니다.
• MCP(Model Context Protocol)를 통한 Slack 연동 기능을 갖춘 n8n 기반 분류기(classifier)를 구축했습니다.
• 첫 번째 프로덕션 준비 완료(production-ready) 브랜치로 CI/CD 장애 어시스턴트를 구현했습니다.
• 첨부 파일 파싱(에러 스크린샷, 로그 파일) 기능을 추가했습니다.
• 워크플로우 자체를 위한 적절한 에러 보고(error reporting) 체계를 설정했습니다.

두 번째 파트에서는 나머지 브랜치들, 즉 인프라 장애 어시스턴트, 일상적인 질문을 위한 지식 어시스턴트, 그리고 인프라 수정 작업을 위한 핸들러를 다룰 예정입니다.

모든 워크플로우와 시스템 프롬프트는 별도로 공개되어 있으며, 링크는 기사 끝에 있습니다.

준비 단계: 요청 분류하기

무언가를 자동화하기 전에, 무엇을 자동화할지 이해해야 합니다. 저는 지난 1년 동안의 Slack 채널 요청 내역을 내보내기(export)하여 카테고리별로 분류했습니다. 그 결과는 다음과 같습니다:

1. 인프라 수정 (Infrastructure modification) — 기존 인프라의 변경 또는 표준 리소스 추가.
2. 신규 설치 (New installation) — 기존에 존재하지 않던 새로운 시스템 및 통합(integration) 배포.
3. 장애 (Incident) — 현재 인프라에서 무언가가 작동을 멈춤.
4. CI/CD — 빌드 실패, 테스트 오류, 배포 실패.
5. 질문 (Question) — 우리 인프라에 관한 일반적인 질문.
6. 공지 (Announcement) — 계획된 유지보수와 같은 정보성 메시지.
7. 기타 (Other) — 위 항목에 해당하지 않는 모든 것.

요청의 대부분은 35번 카테고리에 속했으며, 이들이 명확한 시작점이었습니다. 12번 카테고리는 승인이 필요하고 거의 항상 엔지니어가 개입해야 하므로, 이를 자동화하는 것은 의미가 없습니다. 공지 사항은 에이전트(agent)의 처리가 전혀 필요하지 않습니다. 이를 정확하게 인식하여 온콜(on-call) 담당자에게 페이지(page)를 보내지 않는 것만으로도 충분합니다.

하지만 어떤 처리 분기(handling branches)를 구축하기 전에, 새로운 요청이 어떤 카테고리에 속하는지 신뢰할 수 있게 식별할 수 있어야 했습니다.

분류기 (The classifier)

첫 번째 미묘한 차이가 빠르게 드러났습니다. 수신된 메시지는 새로운 스레드 (thread)를 시작할 수도 있고, 기존 스레드 내부의 답장일 수도 있습니다. 두 번째 경우, 스레드 문맥 (context)이 없다면 분류기 (classifier)는 오작동할 것입니다. 예를 들어

에이전트 (agent)의 응답을 수신하고 필드 (fields) 검증이 완료되면, 당직 엔지니어 (on-call engineer)를 결정해야 합니다. 자동화된 처리만으로 요청을 종결할 수 없는 경우 이들이 필요할 수 있기 때문입니다. 당직 순번 (on-call rotations)은 Google Calendar에 기록되어 있으므로, n8n 문서를 따라 이에 대한 OAuth2 액세스를 구성해야 했습니다.

카테고리 (category)와 당직 엔지니어가 결정되면, 그에 해당하는 서브 워크플로 (sub-workflow)가 시작됩니다. 이와 동시에, 작성자가 요청이 수신되었고 처리 중임을 확인할 수 있도록 Slack으로 '확인 (acknowledge)' 메시지를 보냅니다. 이는 매우 중요한 세부 사항입니다. 이 과정이 없다면, 사용자는 스레드에 "저기요, 이거 누가 보고 있나요?"라고 계속 타이핑하게 될 것이며, 이는 자동화의 목적을 완전히 무색하게 만듭니다.

CI/CD 어시스턴트 (CI/CD assistant)

CI/CD는 가장 흔한 카테고리 중 하나이므로 여기서부터 시작했습니다. 이러한 이슈의 상당 부분은 엔지니어 없이도 해결될 수 있습니다. 일시적으로 접근할 수 없는 저장소 (repository) 때문에 실패한 빌드, 불안정한 테스트 (flaky tests), 잘못 구성된 파이프라인 (pipelines), 만료된 토큰 (tokens) 등이 그 예입니다.

서브 워크플로는 요청 데이터가 포함된 다음과 같은 입력 구조를 기대합니다:

{
  "message": "채팅 요청 텍스트",
  "message_ts": "Slack 메시지 타임스탬프",
...

첨부 파일 파싱 (Parsing attachments)

대부분의 CI 요청은 "빌드 실패 (build failed)" 문구와 에러 스크린샷이 결합된 형식으로 들어옵니다. 이러한 설명만으로는 특정 빌드를 식별하기에 명확히 부족하므로, 메인 에이전트가 실행되기 전에 헬퍼 서브 워크플로인 attachmentsAnalyzer가 먼저 실행됩니다.

이 워크플로는 첨부된 파일들을 처리합니다:

• 이미지 (Images) (에러 스크린샷) — 텍스트를 추출하고 문맥을 설명하기 위해 gpt-4o-mini로 전송됩니다.
• 텍스트 파일 (Text files) (로그) — Config 노드에 설정된 제한 용량을 초과하지 않는 경우, 해당 내용이 추가 문맥 (context)으로 전달됩니다.

출력값은 다음과 같은 압축된 텍스트 블록 형태입니다:

{
  "attachments_context": "...사람이 읽을 수 있는 블록 내용...",
  "attachments_count": 1
...

저는 이 부분을 의도적으로 별도의 워크플로로 분리했습니다. 이는 다른 처리 분기에서도 재사용되기 때문입니다. 만약 attachmentsAnalyzer가 실패하더라도, 메인 워크플로는 전체가 중단되는 대신 추가 문맥 없이 계속 진행됩니다.

문맥 수집 및 에이전트 호출

LLM 요청을 구성하기 전에, SetVars 노드가 필요한 모든 요소를 조립합니다:

• 원시 요청 데이터 (raw request data);
• attachmentsAnalyzer의 출력값;
• 시스템 프롬프트 (system prompt)를 위한 보조 문맥 (auxiliary context): GitHub 조직 이름, Kubernetes 컨텍스트 및 네임스페이스 (namespaces), Grafana 데이터 소스 이름.

에이전트 자체는 다음과 같은 MCP 도구 세트와 함께 작동합니다:

• GitHub MCP — Actions 빌드 로그, PR, 소스 코드에 대한 접근 권한.
• Slack MCP — 초기 요청에 충분한 문맥이 포함되지 않은 경우 스레드의 메시지를 읽음.
• Grafana / Kubernetes MCP — 배포 관련 이슈에 대해 클러스터 로그 및 이벤트를 조회.

시스템 프롬프트에는 다음 내용이 포함되어야 합니다:

• 어떤 팀이 존재하며 어떤 리포지토리 그룹이 해당 팀에 속해 있는지 — 적절한 리포지토리를 식별하는 속도를 높여줍니다.
• Slack 스레드에서 추가 문맥을 가져오는 방법;
• DevOps 팀의 책임 범위 — 에러가 해당 범위에 속할 경우, 어시스턴트는 조사 마지막 단계에서 당직자 (on-call)를 추가로 태깅합니다.
• 사용 가능한 도구들에 대한 일반적인 설명 및 각 도구의 사용 시점;
• 몇 가지 작업 예시;
• 출력 형식.

사용자 프롬프트 (user prompt)는 다음과 같은 템플릿 형식을 가집니다:

{{ $json.channel_name }} 채널의 {{ $json.user_name }} 사용자가 제기한 문제를 조사하십시오.{{ $json.is_thread ? ' (메시지가 스레드에 있습니다. thread_ts=' + $json.thread_ts + ' — Slack conversations.replies를 통해 대화 내역을 먼저 읽으십시오.)' : '' }}
{{ $json.message }}{{ $json.attachments_context && $json.attachments_context.trim().length > 0 ? '\n\n첨부 파일의 추가 정보:\n' + $json.attachments_context : '' }}

메시지 자체와 더불어, 이 템플릿은 메시지를 보낸 사람, 메시지가 발생한 채널, 스레드 답글 여부, 그리고 첨부 파일이 있는 경우 해당 파일 정보까지 함께 전달합니다.

HTTP-probe 우회 방법 (The HTTP-probe workaround)

빌드(build)가 실패하는 흔한 이유 중 하나는 의존성 저장소(dependency repository), 프록시(proxy), 레지스트리(registry)와 같이 접근할 수 없는 외부 리소스 때문입니다. 자연스러운 접근 방식은 에이전트(agent)에게 내장된 HTTP Request 도구를 제공하여 가용성을 확인하게 하는 것입니다. 하지만 실제로 해보니 잘 작동하지 않았습니다. n8n의 내장 노드(node)는 타임아웃(timeout)과 네트워크 오류를 유연하게 처리하지 못하며, 오류가 발생하면 전체 에이전트 체인(agent chain)을 중단시켜 버립니다.

그래서 저는 확인 과정을 항상 구조화된 결과(성공, 이유를 포함한 실패, 또는 타임아웃)를 반환하는 별도의 서브 워크플로우(sub-workflow)인 httpProbeTool로 감싸서 구현했습니다. 에이전트는 이를 다른 도구들과 동일하게 사용합니다.

에이전트가 응답하면 짧은 형식의 유효성 검사(validation) 단계를 거친 후, 메시지가 Slack 스레드에 게시됩니다.

워크플로우 오류 처리 (Handling workflow errors)

실제 사용자의 요청을 처리하는 시스템을 구축할 때는 신뢰성 (Reliability)이 매우 중요합니다. 만약 LLM 할당량(Quota) 소진, MCP 서버 접속 불가, 잘못된 JSON 형식 등 어떤 이유로든 워크플로우 (Workflow)가 중단된다면, 채팅창의 그 누구도 이를 알 수 없으며 요청은 그저 그대로 멈춰 있게 됩니다.