안녕하세요! KIYOラーニング에서 AirCourse 개발을 하고 있는 모리시타입니다.

이번에는 Claude Code의 스킬(Skill)로 New Relic CLI와 Backlog MCP를 조합하여, 에러 조사와 진척 관리를 자동화한 이야기를 소개해 드리겠습니다.

이번에는 평소 익숙하게 사용하고 있는 New Relic CLI를 이용했습니다. MCP를 이용하는 방법도 생각할 수 있지만, 본 기사에서는 CLI 기반의 구성으로 소개합니다.

평소의 에러 모니터링에서는 "이거 버그인가?", "이미 티켓을 발행했나?", "대응 중인가?", "고쳤는데 또 발생했나(재발)?"를 한 건씩 확인하고 있었는데, 이것이 은근히 힘들었습니다. 그래서 조사 리포트 작성과 진척 대시보드 업데이트를 한꺼번에 수행하는 스킬을 직접 만들었습니다. 이 기사에서는 그 내용, 구조, 만드는 방법까지 하나씩 설명하겠습니다.

Claude Code의 「스킬 (Skill)」은 AI에게 업무 절차를 학습시켜 재사용할 수 있는 메커니즘입니다. 이번에는 이것으로 일련의 에러 대응을 자동화했습니다.

【목차】

• 이런 분께 추천
• 이 스킬이 만드는 두 가지 성과물
• 스킬로 할 수 있는 일
• 만든 이유 (배경)
• 전제 도구
• 성과물 ① 모니터링 조사 리포트
• 성과물 ② 진척 대시보드
• 이 스킬의 가장 큰 포인트: 대응 상황의 가시화와 재발 탐지
• 구조: New Relic과 Backlog를 어떻게 연결하고 있는가
• 만드는 방법과 설정
• 요약
• 마치며
• KIYOラーニング 주식회사에 대하여

괜찮으시다면 끝까지 봐주세요!

• New Relic으로 에러 모니터링은 하고 있지만, 대응 상황(대응 중/완료/재발) 관리가 힘드신 분
• New Relic과 Backlog처럼 모니터링 도구와 이슈 관리 도구를 수동으로 대조하며 작업하고 계신 분
• Claude Code의 스킬로 자신의 업무를 자동화해 보고 싶은 분

ac-error-triage를 실행하면 다음 두 가지가 자동으로 만들어집니다.

• 모니터링 조사 리포트 (Markdown) … 해당 시점의 에러를 appName별로 트리아지(Triage)한 조사 리포트

• 진척 대시보드 (HTML) … 에러가 Backlog에서 대응 완료되었는지, 재발하지 않았는지를 목록으로 확인할 수 있는 진척 대시보드

• 대상 앱 및 대상 기간을 대화로 확인 (기간은 "어제 10:00 ~ 현재 / 최근 1주일 / 최근 2주일 / 최근 1개월" 중에서 선택)

• 5가지 관점 (PHP 예외, JS 에러, 4xx, 5xx, DB 부하)을 appName별로 횡단 집계

• 지난주 대비 급증(🚨) 탐지

• 외부 요인이나 클라이언트 환경 기인 등, 예상 범위 내의 노이즈와 실제 버그 후보를 분류

• 실제 버그 후보가 Backlog에 이미 발행되었는지 검색하여 상태, 출시 예정일, 진척 단계를 확인

• 지속적인 에러 관리를 위한 대장 업데이트

• 상태(대응 중/완료/재발/출시 대기/미발행/진정됨)를 판정하여 HTML 대시보드 재생성

웹 서비스를 운영하다 보면 New Relic에는 다양한 에러가 흘러들어옵니다. 저희 팀의 운영 플로우는 다음과 같습니다.

[New Relic에서 에러 확인] → [소스 코드 조사를 통한 원인 확인] → [버그라면 Backlog에 티켓 발행] → [대응 및 수정]

심플하지만, 에러 한 건 한 건에 대해 매번 이런 확인을 수동으로 반복해야 하며, 이것이 은근히 번거롭습니다.

• 애초에 이것이 버그인가? (외부 요인이나 예상 범위 내의 액세스로 인한 노이즈가 아닌가)
• 버그라면, 이미 Backlog에 발행했는가?
• 발행했다면, 지금 대응 중인가, 아니면 이미 완료되었는가?
• 완료되었다면, 재발한 것이 아닌가?
• 아니면 건수가 적으니 일단 지켜봐도 되는 것인가?

게다가 이 확인을 앱(appName)별, 에러 종류별로 반복해야 하기에 솔직히 매우 힘듭니다.

더 나아가 New Relic과 Backlog라는 두 개의 서로 다른 화면을 오가며 대조하는 수고도 따릅니다.

이 "한 건씩 확인하기"와 "두 화면 대조하기"를 매번 수동으로 하는 것을 그만두고 싶다. 그것이 ac-error-triage를 만든 이유입니다.

각각 다기능 도구이지만, 여기서는 이 기사에서의 역할에 한정하여 소개하겠습니다. 각 도구가 본래 할 수 있는 기능은 훨씬 더 넓으므로, 자세한 내용은 공식 문서를 참조해 주세요.

도구	이 기사에서의 역할
New Relic	애플리케이션의 에러와 퍼포먼스를 모니터링하는 서비스. 본 기사에서는 "지금 어떤 에러가 발생하고 있는가"의 정보원으로 사용합니다.
New Relic CLI	New Relic을 커맨드 라인(Command Line)에서 조작하는 공식 도구. 본 기사에서는 NRQL로 에러를 집계·취득하는 용도로만 사용하고 있습니다. (대시보드 조작이나 배포 기록 등, 이 외에도 할 수 있는 일은 다수 있습니다)
Backlog	과제 관리 도구. 본 기사에서는 "해당 에러가 기표되었는지·대응 중인지·완료되었는지"의 정보원으로 사용합니다.
MCP	AI가 외부 도구와 연결되기 위한 공통 규격. 본 기사에서는 Claude가 Backlog를 읽기 위한 접속에 사용하고 있습니다.
Claude Code	터미널에서 동작하는 AI 어시스턴트. 본 기사에서는 일련의 조사를 실행하는 역할로 사용합니다.
스킬 (Skill)	Claude Code에 절차를 기억시키는 메커니즘. 이번에는 "조사 & 진척 관리" 절차를 기억시키는 데 이용하고 있습니다.

New Relic에서 데이터를 추출할 때는,

NRQL이라는 SQL과 유사한 언어를 사용합니다 (예: "지난 1주일간의 에러를 집계해줘"). 스킬이 백그라운드에서 구성해 주므로, 사용하는 측에서 직접 작성할 필요는 없습니다.

appName별로 "5가지 관점 (PHP 예외 · JS 에러 · 4xx · 5xx · DB 부하) + 전주 대비" 요약을 출력하고, 그 후에 실제 버그 후보를 1건씩 심층 분석하며, 마지막으로 노이즈 집계와 권장 액션을 나열합니다. 실제로 샘플용으로 출력된 리포트에서 일부를 발췌합니다.

전체적으로 허용 범위 내이며,

신규 중대 사안 없음. 전주에 눈에 띄었던 사안은 모두 대폭 감소. 신규 급증🚨은 일부 앱의 4xx뿐이며, 주된 원인은 예상 범위 내의 액세스 제어에 의한 것. 사용자에게 미치는 실질적인 피해는 한정적.

다음 요약은 기사용으로 내용을 추상화한 샘플입니다. 실제 수치나 원인과는 무관합니다.

"전주 대비"는 전주 동일 기간과의 비교입니다 (1.0을 초과하면 증가, 🚨는 눈에 띄는 급증).

■ app-name-01 (앱 A)
- PHP 예외 : 9건 (전주 대비 2.25배) — 경미한 경고가 중심이며 낮은 빈도
- JS 에러 : 78,462건 (전주 대비 1.07배) — 거의 보합세. 대부분은 클라이언트 환경에 기인했을 가능성이 높음
...

4. 관리 화면 일부에서 경미한 경고 (app-name-03 / 12건)
- 버그 가능성 : 중 (화면은 동작하지만(HTTP200), 경고가 계속 발생하여 로그의 노이즈 원인이 되고 있음)
- 발생 위치 : 관리 도구의 일부 화면
...

이와 같이 "건수", "전주 대비", "발생 위치", "판단", "Backlog 기표 여부와 상태"까지 1건씩 갖추어 주므로, 인간은 "그래서 어떻게 할 것인가?"라는 판단에 집중할 수 있습니다.

리포트가 "그 시점의 조사 결과를 정리한 문서"라면, 대시보드는 "에러의 현재 상태를 일람으로 파악하기 위한 화면"입니다. 완성 이미지는 다음과 같으며, 상태별로 색상이 구분되고 필터링이나 정렬도 가능합니다.

다음 진척 대시보드는 기사용으로 작성한 샘플입니다. 실제 수치나 원인과는 무관합니다.

• 상태 색상 배지 (🔴 재발 / 🟠 릴리스 대기 / 🟡 대응 중 / ⚪ 미기표 / 🟢 완료 / ⚫ 진정됨)로 상태를 파악 가능
• 상태·앱별 필터링과 열 정렬 가능
• 각 에러의 Backlog 티켓 · 최초 감지/최종 감지 · 건수 (합계 + 감지일별 내역)를 한 줄로 표시

재발이나 대응 중 등 "지금 무엇을 봐야 하는가"를 즉시 찾아낼 수 있도록 구성되어 있습니다.

이 기사에서 가장 전달하고 싶은 핵심은 이것입니다. New Relic은 "지금 에러가 발생하고 있다"는 것은 알 수 있지만, 그것이 미대응인지·대응 중인지·이미 수정되었는지까지는 알려주지 않습니다. 이 스킬은 감지된 에러를 Backlog의 티켓과 대조하여, 각 에러의 "현재 상황"을 일람으로 파악할 수 있게 합니다. 상황을 파악해야 비로소 "다음에 무엇을 해야 할지"를 판단할 수 있게 됩니다.

그리고 상황을 알게 되면, 한 단계 더 나아가 "수정했을 텐데 다시 발생함 = 재발"도 구분할 수 있습니다. 여기서 중요한 것은 "완료 = 수정됨"이라고 단순하게 단정 짓지 않는 것입니다. 예를 들어 Backlog의 티켓이 "완료" 상태여도, 아직 운영 환경에 릴리스되지 않았을 수 있습니다. 그 경우에는 에러가 계속 발생하는 것이 당연하며, 재발이 아닙니다. 그래서 이중 구조로 판정하고 있습니다.

• "운영 환경에 반영되었는가"를 Backlog의 릴리스 예정일(없다면 마일스톤 단계. 예: 운영 릴리스 승인 / 운영 모니터링 중)로 확인합니다.

）로 판정 - 그 후 「운영 반영 후에도 여전히 발생하고 있는가」를 New Relic의 발생 상황으로 확인합니다.

판정표는 다음과 같습니다.

지금 발생 중?	티켓	운영 반영	→ 상태
발생 중	완료	완료됨	🔴 재발 (수정 후에도 다시 발생)
발생 중	완료	아직	🟠 릴리스 대기 (발생하는 것이 당연함. 재발이 아님)
발생 중	처리 중/미대응	—	🟡 대응 중
발생 중	없음	—	⚪ 미기표
발생하지 않음	완료	완료됨	🟢 완료
발생하지 않음 (한동안)	없음	—	⚫ 침전화

「완료했을 터인 에러가, 운영 환경에 반영된 후에도 여전히 발생하고 있다」를 🔴로 눈에 띄게 표시함으로써, 「고쳤다고 생각한 버그의 재발」을 놓치지 않고 방지할 수 있습니다.

New Relic은 「지금 발생 중인 에러」, Backlog는 「그 대응 상황」으로, 보고 싶은 정보가 두 가지 도구에 나누어져 있습니다. 이 두 가지를 대조하는 것이 이 스킬의 핵심이었습니다.

• New Relic CLI로 「지금 어떤 에러가 발생하고 있는가」를 취득 (NRQL로 집계 및 트리아지 (Triage))
• Backlog MCP로 「그 에러가 대응 완료되었는가」를 취득 (티켓 상태, 릴리스 예정일, 마일스톤)
• **로컬 대장 (registry.json)**으로 「어제의 그 에러」와 「오늘의 이 에러」를 동일한 것으로 계속해서 동일시함

① New Relic CLI로 집계 및 트리아지
↓
② Backlog MCP로 티켓 상태 및 릴리스 예정일 취득
...

대장이 있음으로써 조사가 「그때뿐」이 아니라 「시계열로 계속 추적」할 수 있게 되어, 재발 감지가 가능해집니다.

이 스킬은 Anthropic 공식의 skill-creator를 사용하여 만들었습니다. 스킬의 템플릿 제작, 테스트, 개선 루프를 도와주는 스킬입니다.

skill-creator 자체의 사용법은 본 기사에서 깊게 다루지 않습니다. 별도의 기사나 공식 문서를 참조해 주세요. 여기서는 「이것을 사용하면 스킬 만들기가 단번에 쉬워진다」라고만 소개하겠습니다.

New Relic CLI를 설치하고, 프로필(API 키, 계정 ID)을 등록합니다.

# 설치 (공식: OS별 패키지 매니저)
# macOS
brew install newrelic-cli
...

설치 절차는 공식 튜토리얼이 최신입니다. 프로필은 API 키와 리전(us 또는 eu)이 필수입니다.

프로젝트 직하의 .mcp.json에 다음을 추가하기만 하면 됩니다.

※ 이번에는 Docker로 진행했습니다.

{
  "mcpServers": {
    "backlog": {
      ...
    }
  }
}

BACKLOG_DOMAIN은 자신의 스페이스(예: xxxx.backlog.com), BACKLOG_API_KEY는 Backlog의 「개인 설정 → API」에서 발행한 키로 교체해 주세요.

API 키는 비밀 정보입니다.
.mcp.json을 Git에 커밋하는 운용 방식이라면, 키는 환경 변수나 .gitignore 대상 파일로 분리하는 것이 안전합니다.

스킬은 하나의 디렉토리에 모여 있습니다.

ac-error-triage/
├── .claude-plugin/
│   └── plugin.json # 플러그인의 메타 정보
...

포인트는 다음과 같습니다.

• SKILL.md에 「무엇을, 어떤 순서로 조사하고 어떻게 판정할지」를 작성 (절차서)
• 세부 지식은 **references/**로 분리 (NRQL 정형 패턴, 노이즈 식별 방법, 대장의 상태 전이 규칙)
• 기계적인 처리는 **scripts/**로 분리 (HTML 생성은 Python에 맡기고, 판단은 Claude가 담당)

이러한 역할 분담입니다. 판단은 AI에게, 정형 처리는 스크립트에 맡기는 것이 직접 만들어보며 깨달은 포인트였습니다.

스킬의 "절차서"인 SKILL.md는 서두에 「언제, 무엇을 위해 사용하는가」를 적는 frontmatter가 있으며, 본문에 워크플로우를 번호 순서대로 나열하기만 하면 됩니다. 실물을 일부 발췌합니다 (사내 고유 값은 숨겼습니다).

---
name: ac-error-triage
description: |
...

본문의 워크플로우는 체크리스트 형식입니다. Claude는 이 순서대로 진행합니다.

- [ ] 스텝 1: 기간 → 대상 앱(appName)을 대화로 확정
- [ ] 스텝 2: 앱별로 5가지 관점 집계 (PHP 예외/JS 에러/4xx/5xx/DB 부하)
- [ ] 스텝 3: 전일 대비·전주 대비를 산출하여 급증을 탐지
...

이와 같이 "해야 할 일을 일본어(한국어) 절차로 작성"하는 것만으로 스킬이 됩니다. 세부적인 판단 기준(NRQL 정형 문구, 노이즈 식별 방법, 상태 전이 규칙)은 references/로 분리하여, SKILL.md 본체는 가독성을 유지하도록 했습니다.

스킬로 등록되어 있으므로, Claude Code에서 슬래시 명령어를 입력하기만 하면 됩니다.

/ac-error-triage

실행하면 먼저 조사 기간(어제 10:00~현재 / 최근 1주일 / 최근 2주일 / 최근 1개월), 다음으로 대상 앱(appName)을 차례로 물어보므로 선택만 하면 됩니다. 그 후 조사 → Backlog 대조 → 대장 업데이트 → 리포트 및 진척 대시보드 생성까지 진행해 줍니다. 마지막에는 브라우저에서 열 수 있는 링크도 제공됩니다.

물론, 처음부터 조건을 덧붙여 자연어로 요청해도 괜찮습니다 (이 경우 대화 확인 과정이 생략됩니다).

/ac-error-triage aircourse-app-name-01의 최근 1주일간 에러를 조사하고, 진척 대시보드도 업데이트해줘

• New Relic과 Backlog를 연동하여, "현재 발생하고 있는 에러"와 "대응 상황"을 대조할 수 있도록 구현
• 운영 릴리스 후에도 동일한 에러가 발생하고 있는지 탐지하여, 재발하는 항목을 🔴로 시각화
• Claude Code의 스킬을 통해 조사·대조·조사 리포트/진척 대시보드 생성까지를 통합적으로 자동화

지금까지 건별로 수동으로 진행하던 에러 조사와 대응 상황 확인을 짧은 시간 안에 완료할 수 있게 되었습니다.

본 기사가 New Relic이나 Backlog, Claude Code의 스킬을 사용하여 자신의 팀을 위한 에러 관리 플로우를 만드는 데 참고가 된다면 좋겠습니다.

끝까지 읽어주셔서 감사합니다.

조금이라도 도움이 되었기를 바랍니다.

괜찮으시다면 '좋아요'와 '저장'도 부탁드립니다.

당사의 비전은 『세계에서 가장 「배우기 쉽고, 이해하기 쉽고, 지속하기 쉬운」 학습 수단을 제공하는 것』입니다. 혁신적인 교육 서비스를 만들고 성장시킴으로써, 온라인 교육 분야에서 넘버원 존재가 되어 세계로 전개해 나가는 것을 목표로 하고 있습니다.

• Studying: 「배우기 쉽고·이해하기 쉽고·지속하기 쉬운」 온라인 자격증 대비 강좌
• Studying Career: 자격 취득자의 구직 및 커리어 형성을 지원하는 이직 서비스
• AirCourse: 무제한 시청 가능한 영상 연수가 포함된 e-러닝 시스템 (LMS)