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

매일 팀 메신저에 쌓이는 버그 제보를 두고 어느 팀 이슈인지 판단하고 담당자를 멘션하고 triage 티켓을 만드는 데 시간을 쓰는 것이 아까웠던 데서 출발한다. 실제 코드를 수정하는 시간보다 누가 봐야 하는지 정리하는 시간이 더 긴 경우도 많았다. 버그가 채팅방에 올라오는 순간부터 누가 어떤 코드베이스를 어떻게 손봐야 하는지까지를 자동으로 연결하는 워크플로우를 만들었다.

핵심 포인트

앞단의 triage 생성·전달·정리 단계가 대부분 반복 가능한 패턴인데도 매번 사람이 직접 판단하고 정리해야 했다.
특히 합류한 지 얼마 안 된 구성원에게는 이 문제가 어느 팀 이슈인지 파악하는 것 자체가 큰 진입 장벽이었다.
Feature 정의와 담당자 정보를 코드에 상수로 박으면 정보를 추가·삭제하기 어려워, 팀원 누구나 접근할 수 있는 Notion 데이터베이스에 뒀다.
"애매하면 비워라"는 규칙을 강하게 걸어 LLM이 잘못된 팀에 멘션을 난사하는 것을 막았다.
키워드가 들어갔다고 무조건 그 feature라고 단정하지 말고 문제 발생 지점이 어느 feature 담당인지로 판단하게 했다.

상세 정리

기존 흐름: 제보가 올라오면 어느 팀 이슈인지 논의하고 담당자를 멘션한 뒤 triage 티켓을 만들고, 그제서야 코드를 보고 PR을 만들어 진행 상황을 다시 공유한다. 진짜 개발 작업은 마지막 단계에 불과하다.
추가 비용: triage를 생성하려면 스레드 전체 맥락을 이해하고 내용을 재구성해야 해 매번 수작업 비용이 발생했다.
목표: 버그가 올라오는 순간부터 누가 어떤 코드베이스를 어떻게 손봐야 하는지까지 최대한 자동으로 잇는 것이다.
4단계 구성: LLM이 어느 팀 이슈인지 판단해 담당자를 멘션하고, 명령어로 Linear 티켓을 자동 생성하며, Linear에서 Cursor를 호출해 코드 분석과 PR을 자동 생성하고, 그 결과를 다시 버그방 스레드에 피드백한다. 각 단계마다 LLM과 Notion·Linear API를 연결해 맥락을 점점 풍부하게 만든다.
전처리: 채널 ID와 그룹 채팅 여부, 스레드 여부, 담당자 메시지 여부를 필터링해 멘션이 필요한 메시지만 통과시킨 뒤, 원문에서 불필요한 공백과 멘션, 이모지를 정리해 LLM이 읽기 좋은 버그 리포트 텍스트로 만든다.
저자는 이 단순 전처리가 컨텍스트 엔지니어링 관점에서 중요하다고 짚는다. 지저분한 텍스트 대신 버그 상황에 집중된 문장만 넘겨야 이후 판단이 안정적으로 이어지기 때문이다.
지식 소스: Notion에 두 개의 데이터베이스를 만들어 feature 목록과 담당자 정보를 관리하고, 이를 파싱해 LLM에게 넘길 프롬프트 조각을 생성한다. 이 부분이 AI에게 건네는 도메인 온톨로지 역할을 한다.
분기 처리: LLM 출력 결과에 따라 담당자가 설정된 경우와 아닌 경우를 나누고, 후자에는 Notion 설정을 업데이트해 달라는 안내 메시지를 보낸다.
중복 방지: 스레드에서 이미 특정 팀이나 사람이 멘션돼 있는 경우를 필터링해 중복 멘션하지 않게 했다.