아직도 버그를 직접 해결하시나요?

• 출처: 채널톡 기술 블로그
• 저자: Nari (FE 엔지니어, Web-Core 팀)
• 읽은 날짜: 2025-12-18
• 태그: #LLM #자동화 #버그트리아지 #워크플로우 #DevOps

핵심 내용

채널톡 엔지니어가 버그 처리 과정의 비효율을 해결하기 위해 "킬버그(Kill Bug)" 워크플로우를 개발한 경험을 공유.

문제점

• 버그 보고 후 "어느 팀이 담당할지" 판단하는 데 많은 시간 소요
• triage 티켓 생성 등 반복 업무가 실제 개발 시간보다 많음

4단계 솔루션

1. 자동 담당자 멘션: LLM이 Notion DB의 Feature 정의를 기반으로 담당자 자동 판단
2. 자동 티켓 생성: "킬버그 web 트리아지" 명령어로 Linear 티켓 자동 생성
3. 자동 코드 분석: Linear에서 Cursor AI 호출 → PR 자동 생성 (confidence 0.8 이상)
4. 결과 피드백: 스레드에 수정 내용과 PR 링크 자동 전송

인상 깊은 부분

도메인 지식은 Notion DB에서 관리하고, LLM은 판단과 문서화에 집중

• confidence 기반 자동화: 0.8 이상일 때만 자동 PR 생성 → 적절한 가드레일
• 인간 개입 가능한 설계: 모든 단계에서 사람이 개입할 수 있는 구조
• 도구 분리: 도메인 지식(Notion) / 판단(LLM) / 실행(Cursor AI)의 역할 분리

내 생각 / 적용점

LLM 자동화 설계 원칙 (배운 점)

1. Confidence threshold 설정: 자동화 범위를 신뢰도로 제한 (0.8 이상만 자동 실행)
2. Human-in-the-loop: 항상 사람이 개입할 수 있는 탈출구 마련
3. 도메인 지식 외부화: LLM에게 직접 학습시키지 않고 외부 DB(Notion)에서 컨텍스트 제공

실무 적용 아이디어

• 버그 트리아지를 사람이 하는 조직이라면 같은 워크플로우를 적용할 수 있다
• Slack + Linear + LLM 연동 구조 참고
• Feature ownership을 명확히 정의한 Notion DB 구축이 선행되어야 함

질문/후속 학습

• [ ] Cursor AI의 자동 PR 생성 기능 구체적으로 어떻게 동작하는지?
• [ ] confidence score는 어떻게 계산하는지?