온콜 이슈 접수 및 Triage 스킬. Slack URL이나 Linear 티켓을 받아 맥락을 파악하고, 이슈 유형 분류(오류/데이터/성능/권한/스펙/화면형) 및 FE/BE 판별을 수행한다. "온콜", "triage", "이슈 분류", "FE야 BE야", "이거 봐줘" 등의 표현이나, Slack/Linear URL을 공유하며 분석을 요청할 때 사용한다.
이슈를 접수하고 맥락을 파악하여 유형 분류 + FE/BE 판별 + 대상 레포 특정까지 수행하는 진입 스킬. 조사(investigation)와 슬랙 메시지 작성은 이 스킬의 범위가 아니다.
$ARGUMENTS — 다음 중 하나:
## Triage 결과
- **이슈**: {티켓번호 또는 슬랙 링크} — {이슈 요약 1줄}
- **회사**: {회사명} (ID: {id})
- **서비스 영역**: {영역}
- **긴급도**: {긴급/상/중}
- **슬랙 스레드**: channel_id={channel_id}, thread_ts={message_ts} (슬랙 URL 입력 시)
[분류] {유형} ({영문}) — {근거 한 줄}
[판정] {FE 이슈 / BE 이슈 / FE-BE 교차 / 스펙 이슈 / 판단 불가} — {근거 한 줄}
[대상 레포] {레포명 또는 "BE 라우팅 필요"}
### 유사 이슈 (Linear 검색 결과가 있을 때만 표시)
- {CI-XXXX} ({상태}) — {제목} : {유사점 한 줄}
### 다음 단계
- 조사가 필요하면: `/oncall-investigate`
- 스펙 이슈/Not a bug로 바로 결론 가능하면: `/oncall-summarize`
- BE 이슈로 라우팅만 하면: BE 담당팀에 전달
슬랙 스레드 정보 캡처: Slack URL로 접수한 경우
slack_read_thread호출 시 사용한channel_id와message_ts를 Output에 포함한다. Linear 티켓으로 접수한 경우에도 티켓에 Slack 링크가 첨부되어 있으면 URL에서 channel_id와 message_ts를 추출하여 포함한다. 이 정보는/oncall-summarize에서 슬랙 초안을 스레드에 답장으로 생성할 때 사용된다.
flex-fe/ 하위 각 레포 (flex-frontend-apps-performance-management, flex-frontend-apps-time-tracking 등)flex-support-oncall/ (BE 서브모듈 + brain/ 디렉토리)각 단계를 실행할 때, 사용자가 현재 어디에 있는지 알 수 있도록 아래 포맷으로 진행 상황을 표시한다.
● {단계 요약 한 줄}
{구체적 내용 — 무엇을 확인하는지, 어디를 보는지}
[분류] {유형} ({영문}) — {근거 한 줄}
[첫 번째 액션] {다음에 할 일}
CS팀이 슬랙에 올린 이슈 메시지에서 다음 정보를 추출한다:
슬랙 메시지 URL이 제공되면 Slack MCP로 스레드 내용을 읽어 맥락을 파악한다. CS팀이 스레드에 추가 맥락을 남기는 경우가 많으므로 스레드 댓글도 반드시 확인한다.
먼저 긴급도를 확인한다:
#critical 등)에 이미 올라갔는지 확인하고, 안 올라갔으면 유저에게 크리티컬 채널 escalation을 제안한다. 조사는 escalation 후 병행한다.이슈 유형 분류 전에, CS가 보고한 증상이 기존 스펙(의도된 동작)과 일치하는지 먼저 확인한다:
스펙 이슈 의심 패턴 — 아래 중 하나라도 해당하면 버그 조사 전에 "이것이 의도된 동작일 수 있는 이유"를 반드시 먼저 검토한다:
| 패턴 | 예시 | 왜 스펙일 수 있는가 |
|---|---|---|
| 두 화면에서 같은 값이 다르게 보임 | "내휴가에서는 8일인데 월별 사용내역에서는 7일" | 각 화면이 다른 기준 시점/범위로 계산할 수 있음 |
| 설정 변경이 특정 화면에 반영 안 됨 | "조직도 순서를 바꿨는데 목표 화면에 반영 안 됨" | 해당 화면이 별도 데이터 소스를 사용하거나 의도적으로 분리된 설계일 수 있음 |
| 숨기기/비활성화 후 라벨/순서가 달라짐 | "3차 평가를 숨겼는데 탭이 1차, 2차로 보임" | 숨긴 항목을 빼고 순번을 재정렬하는 것이 의도된 UX일 수 있음 |
| N개 중 일부만 표시됨 | "직무가 2개인데 1개만 보임" | 공간 제약으로 대표값만 표시하는 것이 의도된 설계일 수 있음 |
| "확인 요청" / "의도된 동작인지" 문구 | CS가 직접 스펙 가능성을 언급 | CS도 버그인지 불확실한 상태 |
CS 표현 신뢰도 주의: CS의 "타입: 버그"나 "수정 요청" 같은 표현을 이슈 유형 판단의 결정적 근거로 사용하지 않는다. CS는 고객 요구를 그대로 전달하는 경우가 많으므로, CS의 타입 지정보다 증상의 구체적 내용을 기반으로 판단한다.
판별 결과에 따른 분기:
/oncall-summarize의 "스펙 이슈 / Not a bug 포맷"으로 결과 작성. 버그 조사 진행하지 않음.flex-support-oncall 레포의 brain/triage-signals.md에 정의된 분류 기준을 따른다:
| 유형 | 키워드 신호 | 첫 번째 액션 |
|---|---|---|
| 오류형 | 오류, 에러, 실패, 500, 400 | access log (HTTP 상태코드) |
| 데이터형 | 이상해요, 안 보여요, 누락, 값이 다르다 | access log로 API 응답 선확인 → FE/BE 판정 |
| 성능형 | 느려요, 로딩, 타임아웃 | access log (응답시간) |
| 권한형 | 접근 안 됨, 403, 메뉴가 없어요 | access log + 권한 테이블 |
| 스펙질문형 | 원래 이런 건가요, 정상인가요 | 도메인 스펙 문서 확인 |
| 화면형 | 깨져요, 빈 화면, 버튼이 없어요, UI | API 정상 여부 확인 → FE 코드 |
복합 신호 처리:
| 신호 | 판단 |
|---|---|
| 500 에러, 서버 타임아웃 | BE 이슈 가능성 높음 |
| 403 권한 에러 | BE (권한 설정) 가능성 높음 |
| API 응답은 200인데 화면에 안 보임 | FE 이슈 가능성 높음 |
| 레이아웃 깨짐, 콘솔 에러 | FE 이슈 |
| 데이터 누락/불일치 | BE 또는 FE-BE 간 데이터 불일치 → 로그 선확인 필요 |
| 다수 회사/계정에서 동시 발생 | BE 또는 인프라 이슈 가능성 매우 높음 (FE 버그라면 특정 조건에서만 발생) |
| 갑작스러운 발생 ("방금", "5분 전") | 배포/인프라 변경 가능성 (BE 이슈) |
키워드만으로 FE/BE 판단이 어려운 경우, triage 단계에서 로그를 먼저 확인하여 판정 정확도를 높인다. 특히 데이터형 이슈는 API 응답을 확인해야 FE/BE를 구분할 수 있으므로, investigate로 넘기기 전에 반드시 로그를 본다.
대상: 아래 조건 중 하나라도 해당하면 로그 선확인을 진행한다:
확인 절차:
⛔ [MUST] curl로 OpenSearch를 직접 호출하지 않는다. 로그 조회는 반드시
opensearch:os-query-log스킬을 통해서만 수행한다.
- MCP 도구(
mcp__opensearch-prod__search_documents등)가 세션에 없으면, curl로 우회하지 않는다.- 대신 유저에게
~/.mcp.jsonopensearch MCP 서버 설정 +uvx설치 + Claude Code 재시작을 안내한다.- curl fallback은 유저가 명시적으로 허가한 경우에만 사용한다.
/os-query-log로 access log를 조회한다:
| 로그 결과 | 판정 업데이트 |
|---|---|
| API 4xx/5xx 응답 | BE 이슈 확정 — API가 에러를 반환하고 있으므로 FE 조사 불필요 |
| API 200이지만 응답 데이터가 비정상 (null, 빈 배열, 기대와 다른 값) | BE 이슈 확정 — 서버가 잘못된 데이터를 내려주고 있음 |
| API 200이고 응답 데이터 정상 | FE 이슈 가능성 높음 — 정상 데이터를 FE가 제대로 렌더링하지 못하는 것 |
| 해당 API 호출 기록 없음 | FE 이슈 가능성 높음 — FE가 API를 호출하지 않거나 잘못된 endpoint를 호출 |
| 로그 확인 불가 (API 경로 추정 실패) | 판정 유지, investigate에서 코드 추적 |
● 로그 선확인 — 데이터형 이슈, API 응답 확인
/os-query-log: {API 경로}, company_id={id}, 시점={발생 시각 전후}
→ API 200, 응답 정상 → [판정] FE 이슈로 업데이트
오류형/성능형 이슈 전용 — 최근 배포 선체크: 오류형 또는 성능형으로 분류된 이슈는, 로그 조회 전에 아래를 먼저 확인한다:
#alarm-deploy-prod 또는 #release-hq 슬랙 채널에서 최근 배포 확인코드를 깊이 파기 전에, 아래 3가지를 병렬로 조회한다. 이미 해결되었거나 관련 수정이 진행 중인 경우가 많다.
git log --oneline --since="2 weeks ago" -- <도메인 디렉토리>목적: 동일하거나 유사한 이슈가 이미 접수/해결된 적이 있는지 확인하여 중복 조사를 방지하고, 기존 해결 방법을 참고한다.
검색 방법: mcp__linear__list_issues로 CI 팀 하위 이슈를 검색한다. 검색 정확도를 높이기 위해 2-3개 키워드 조합을 병렬로 시도한다:
| 검색 축 | query 예시 | 왜 필요한가 |
|---|---|---|
| 증상 키워드 | "빈 화면", "로딩 무한", "저장 실패" | CS가 보고한 증상과 동일한 이슈 |
| 서비스 영역 + 기능 | "근태 초과근무", "비용관리 영수증" | 같은 도메인의 유사 이슈 |
| 에러 메시지 / API 경로 (있는 경우) | "Cannot read property", "/api/v2/overtimes" | 기술적으로 동일한 이슈 |
mcp__linear__list_issues(team: "CI", query: "{증상 키워드}", limit: 5)
mcp__linear__list_issues(team: "CI", query: "{서비스영역 + 기능}", limit: 5)
2-3개 검색을 병렬 호출하여 시간을 절약한다. 각 검색은 limit: 5로 제한.
결과 해석:
| 매칭 결과 | 액션 |
|---|---|
| 동일 이슈가 이미 해결됨 (Done/Closed) | 해당 이슈의 해결 방법(댓글, 첨부 PR)을 확인 → "이미 해결됨" 또는 regression 여부 판단 |
| 동일 이슈가 진행 중 (In Progress/Todo) | 중복 접수 가능성 → 기존 이슈에 합류할지 유저에게 확인 |
| 유사하지만 다른 이슈 | 참고 컨텍스트로 활용 — 같은 도메인의 과거 패턴/해결 방향 참고 |
| 매칭 없음 | 신규 이슈로 진행 |
Output에 반영: 유사 이슈가 발견되면 Triage 결과에 아래를 추가한다:
### 유사 이슈
- {CI-XXXX} ({상태}) — {제목} : {유사점 한 줄}
- {CI-YYYY} ({상태}) — {제목} : {유사점 한 줄}
이력에서 관련 변경을 찾으면:
Linear에서 유사 이슈를 찾으면:
Sentry MCP가 설치되어 있으면, 오류형 또는 화면형 이슈에서 Sentry를 먼저 확인하여 FE/BE 판별 근거를 강화한다:
[확인] Sentry에서 동일 에러 발견 — TypeError: Cannot read property 'endDate' of null
- 최초 발생: 2026-04-05 14:30 (배포 v2.2026-04-05.1 직후)
- 영향: 3개 회사 7명
- 스택트레이스: ContractDetail.tsx:142 → useContractQuery
→ FE 이슈 확정, 대상 파일까지 특정됨
FE 이슈로 판정되면 서비스 영역을 기반으로 대상 레포를 특정한다.
CS 메시지에서 backtick으로 감싼 서비스 영역 태그(예: `비용관리`, `근태관리`)를 확인하고, 아래 매핑 테이블로 후보 레포를 선정한다:
| 서비스 영역 태그 | 대상 레포 |
|---|---|
| 비용관리, 지출결의, 영수증, 법인카드 | flex-frontend-apps-fins |
| 근태관리, 출퇴근, 휴가, 초과근무 | flex-frontend-apps-time-tracking |
| 평가, 리뷰, 목표 | flex-frontend-apps-performance-management |
| 급여, 정산 | flex-frontend-apps-payroll |
| 채용, 지원자 | flex-frontend-apps-recruiting |
| 전자결재, 워크플로우 | flex-frontend-apps-workflow |
| 인사정보, 조직 | flex-frontend-apps-people |
| 로그인, 인증 | flex-frontend-apps-auth |
| GNB, 홈, 설정, 문서 | flex-frontend |
후보 레포가 맞는지 확인하기 위해, 이슈 맥락에서 추출한 핵심 키워드(API 경로, UI 텍스트, 기능명 등)로 후보 레포에서 grep을 1회 실행한다.
/oncall-investigate의 역할이다.