인프라 팀 업무의 상당수가 Slack에서 시작된다.
한 건에 15~30분이지만, 매일 2~3건씩 반복되면 주 5~10시간을 차지한다. 그보다 더 큰 문제는, 사람은 반복에 지치면 놓친다는 것이다. 놓친 이상은 발견될 때까지 조용히 누적된다.
도구의 효율은 도구 자체보다 사용 방법에 달려 있다. Claude Code를 5주간 6,000개 세션에서 사용하면서, 도구 자체는 강력했지만 반복되는 마찰이 있었다. 서버 재시작이 매번 꼬이고, 분석 결과에 사실 오류가 섞이고, SSO 토큰이 핵심 순간에 만료되었다.
문제는 도구가 아니라 사용 방법이었다. Claude Code의 /insights 명령어로 사용 패턴을 분석한 결과, 어디서 시간을 낭비하고 있는지 명확하게 드러났다. 리포트가 제안한 12개 개선안을 CLAUDE.md, 커스텀 스킬, 훅, 헤드리스 스크립트에 전부 반영한 과정을 공유한다.
Claude Code의 /insights는 사용 패턴을 분석해서 개인화된 리포트를 생성하는 기능이다. 로컬에 저장된 세션 데이터를 기반으로 다음을 보여준다:
1편에서는 Claude Agent SDK와 MCP로 Slack 기반 인프라 자동화를 만들었다. 비용 분석, 파라미터 스토어 등록 같은 반복 업무를 AI 에이전트에 맡기는 구조였다.
처음에는 문제 없었다. 그런데 기능을 추가할 때마다 라우팅 규칙이 복잡해졌다. 키워드를 등록하고, 동의어를 챙기고, 실제 메시지로 매칭이 되는지 테스트하는 과정이 반복됐다. 새 기능 하나를 추가하는 데 구현보다 라우팅 규칙을 다듬는 시간이 더 걸렸다.
기존 메시지 라우팅 구조를 다시 보면 이렇다.
CI/CD 파이프라인의 병목은 코드가 아니라 인프라에서 발생하는 경우가 많다. 특히 self-hosted runner 환경에서는 runner 수가 곧 동시 빌드 수의 상한이 되는데, 이 상한이 적정한지 판단할 데이터가 없다면 감으로 운영하게 된다.
Bitbucket self-hosted runner 3대를 운영하고 있었다. 개발자들이 빌드가 밀린다는 얘기를 했지만, 정확히 하루 중 얼마나 대기가 발생하는지, runner를 몇 대로 늘려야 하는지 판단할 근거가 없었다. Bitbucket에는 runner 사용률을 시계열로 보여주는 기능이 없기 때문이다. AI로 간이 대시보드를 빠르게 만들어 측정하고, 데이터 기반으로 적정 runner 수를 결정한 과정을 공유한다.
2편에서 라우팅을 정리하고 나니, 다음 문제가 보였다. 아직 이 시스템은 나 혼자 쓰고 있다.
우리 팀은 각자의 컴퓨터에서 Claude Code를 쓰고 있다. 각자 .md 파일에 노하우를 정리하고, 각자의 프롬프트로 에이전트를 돌린다. 문제는 이 경험이 개인에게 갇힌다는 것이다. A가 시행착오 끝에 찾은 좋은 프롬프트를 B는 모른다. 같은 실수를 반복하고, 같은 질문에 다른 품질의 답이 나온다. 하나의 요청에 여러 명이 각자의 에이전트를 돌리면 토큰은 중복으로 소모되고, 처리 이력은 각자의 컴퓨터에 흩어진다.
