본문으로 건너뛰기

AI와 개발하며 배운 것을 팀 규칙으로 남기는 법: WMS의 컴파운드 트리아지

AIAI 에이전트Compound TriageWMS
WMS최영호2026년 8월 18일

AI와 함께 개발하며 발견한 시행착오는 대화가 끝나면 사라지기 쉽습니다. WMS 개발팀은 이를 후보로 모으고 사람이 검토해 다음 작업에서 다시 쓰는 규칙으로 남기고 있습니다. 공용 Drawer에서 발견한 문제 하나가 실제 팀 규칙으로 이어진 과정도 함께 소개합니다.

개발 중 발견한 후보를 사람이 검토하고, 채택한 후보를 팀 규칙과 자동 검증으로 연결하는 흐름

안녕하세요, UMOSONE WMS(Warehouse Management System) 개발팀의 Front Engineer 최영호입니다. 저희 FE팀은 WMS Frontend를 개발하면서 AI 에이전트와 함께 겪은 시행착오를 다음 작업에서도 꺼내 쓸 방법을 고민해왔습니다. 이번 글에서는 그 고민 끝에 도입해 운영하고 있는 컴파운드 트리아지를 소개하려고 합니다. 먼저 저희 팀이 만드는 제품과 이런 과정이 필요했던 배경부터 짧게 이야기해보겠습니다.

Capora WMS​

Capora WMS는 입고, 재고, 피킹, 검수, 출고까지 물류센터에서 일어나는 작업을 관리하는 시스템입니다. 여러 화주와 센터의 재고 흐름을 실시간으로 확인하고 운영자와 현장 작업자가 각 단계의 업무를 이어가도록 돕습니다.

WMS에는 서로 닮은 화면과 작업 흐름이 많습니다. 한 기능에서 발견한 문제나 구현 규칙이 다른 기능에서도 반복되곤 합니다. 이런 경험을 한 번의 작업에만 남기지 않고 팀의 자산으로 쌓을 방법을 고민하게 된 배경도 여기에 있습니다.

입고부터 출고까지 이어지는 Capora WMS의 물류센터 업무 흐름

입고부터 출고까지 이어지는 과정에서는 상태 처리, 조회 조건, 공용 컴포넌트 사용법 같은 규칙이 여러 화면에서 반복됩니다.

AI 에이전트와 개발하다 보면 대화 안에 여러 경험이 쌓입니다. 어떤 API부터 확인했는지, 처음 고른 구현을 왜 버렸는지, 실제 문제를 잡아낸 테스트는 무엇이었는지 같은 기록입니다.

문제는 작업이 끝난 뒤입니다. 새 대화를 열면 이 맥락도 사라집니다. 다음 에이전트는 같은 코드를 다시 살피고 때로는 앞서 겪은 실수를 되풀이합니다. 기능은 완성됐지만 팀의 개발 방식에는 별다른 변화가 남지 않습니다.

저희는 이 경험을 다음 작업에서도 꺼내 쓰고 싶었습니다. 그래서 재사용할 만한 교훈을 후보로 모으고 사람이 검토해 팀 규칙으로 남기는 과정을 만들었습니다. 이 과정을 컴파운드 트리아지(Compound Triage)라고 부릅니다.

이름은 낯설어도 원리는 간단합니다. AI가 찾은 교훈을 바로 규칙으로 삼지 않고 다른 작업에서도 필요한지 사람이 다시 판단합니다.

AI와의 작업에서 발견한 교훈이 Raw Ticket과 사람의 검토, 문서 변경 계획을 거쳐 다음 작업에 다시 사용되는 전체 흐름

자동화는 후보를 모으는 일을 돕지만 어떤 후보를 팀 규칙으로 채택할지는 사람이 결정합니다.

작업 경험도 다음 작업에 쌓일 수 있을까​

이 문제를 고민하던 중 Every의 Compound Engineering을 읽었습니다. 이 글에서 말하는 ‘compound’는 작업 하나가 다음 작업을 더 쉽게 만드는 방향으로 경험을 쌓는다는 뜻입니다. 기능만 완성하고 끝내는 대신, 그 과정에서 발견한 패턴과 도구, 문서를 함께 개선하면 시간이 지날수록 개발 환경도 나아진다는 생각입니다.

처음에는 작업이 끝날 때마다 배운 점을 문서에 추가하면 되겠다고 생각했습니다. 그런데 곧 문제가 드러났습니다. 한 번 효과가 있었던 방법이 다른 작업에도 통한다는 보장은 없습니다. 특정 버그에서만 필요한 우회 방법일 수도 있고 이미 문서에 있는 규칙을 AI가 다시 발견했을 수도 있습니다. AI가 그럴듯하게 정리했다는 이유만으로 팀 규칙이 되면 문서는 서로 충돌하는 지침으로 금방 뒤엉킵니다.

그래서 저희는 ‘배운 점을 모으는 일’과 ‘팀 규칙으로 채택하는 일’을 나눴습니다.

먼저 규칙이 아니라 후보로 남깁니다​

이 과정은 에이전트의 Stop hook에서 시작합니다. Stop hook은 에이전트가 작업을 마칠 때 자동으로 실행되는 후처리입니다. WMS Frontend에서는 이 훅이 compound-capture-stop 스킬을 호출합니다.

compound-capture-stop은 이번 작업에서 얻은 경험이 프로젝트 문서의 규칙으로 남길 만큼 재사용 가능한지 따져봅니다. 다른 작업에서도 반복될 근거가 있는지, 어느 문서의 어느 위치에 반영할지, 어디까지 적용하고 어디에는 적용하지 않을지 확인합니다. 이 질문에 구체적으로 답할 수 없다면 티켓을 만들지 않습니다.

기준을 통과해도 문서를 바로 고치지는 않습니다. 사람이 검토할 후보 카드를 먼저 만듭니다. 내부에서는 이를 Raw Ticket이라고 부릅니다. 작업이 끝날 때마다 반드시 생기는 것은 아닙니다. 남길 만한 교훈이 없다면 0건으로 끝납니다.

실제로 공용 Drawer를 고치던 작업에서 이 과정이 어떻게 시작됐는지 살펴보겠습니다. Drawer는 현재 목록을 그대로 둔 채 그 위에 상세 정보를 펼치는 UI입니다. 제품 목록에서 제품 링크를 누르면 상세 Drawer가 열립니다. 필요한 내용을 확인하고 닫으면 다시 원래 목록으로 돌아갑니다.

당시 공용 Drawer를 닫는 로직을 고치면서 ProductDetail이 열릴 수 있는 overlayId를 하나의 목록에 모아 관리하는 방식을 먼저 택했습니다.

products/config/constant.ts
export const PRODUCT_DETAIL_OVERLAY_IDS = [
  PRODUCT_DETAIL_OVERLAY_ID,
  PRODUCT_DETAIL_OVERLAY_ID_WITH_CURSOR,
  SAFETY_STOCK_PRODUCT_DETAIL_OVERLAY_ID,
] as const;

목록에 모든 ID가 들어 있다면 문제없이 동작합니다. 문제는 그 ‘모든 ID’를 사람이 빠짐없이 찾아야 한다는 데 있었습니다. 첫 조사에서는 openBottomDrawer 호출부를 검색해 제품 상세 Drawer가 두 ID로 열린다고 판단했습니다. 하지만 안전 재고 화면은 openBottomDrawer를 직접 호출하지 않았습니다. DeepLinkDrawerConfig.renderDetail에서 같은 ProductDetail을 렌더링하면서 자체 overlayId를 사용하고 있었습니다.

config/safety-stock/config/drawer-config.tsx
export const SAFETY_STOCK_PRODUCT_DRAWER_CONFIG = {
  overlayId: SAFETY_STOCK_PRODUCT_DETAIL_OVERLAY_ID,
  renderDetail: () => <ProductDetail />,
};

이 경로를 놓친 채 변경을 마쳤다면 제품 관리 화면에서는 Drawer가 정상적으로 닫히지만, 안전 재고 화면에서 연 Drawer만 닫히지 않는 문제가 생길 수 있었습니다. 공용 컴포넌트를 여러 화면에서 재사용할수록 중앙 목록을 사람이 관리하는 방식은 누락에 취약했습니다.

저희는 목록을 더 꼼꼼하게 관리하는 대신, ID를 관리할 책임을 Drawer를 사용하는 화면으로 옮겼습니다. 공용 Drawer가 자신을 사용하는 모든 화면의 ID를 기억하지 않고, Drawer를 여는 화면이 실제로 사용한 ID를 필수 prop으로 넘기도록 바꿨습니다.

- const handleCloseDrawer = useCloseDetailDrawer({
-   overlayIds: PRODUCT_DETAIL_OVERLAY_IDS,
-   searchKey: 'selectedProductId',
- });

+ type ProductDetailProps = {
+   overlayId: string;
+ };

+ const handleCloseDrawer = useCloseDetailDrawer({
+   overlayId,
+   searchKey: 'selectedProductId',
+ });

overlayId가 필수 prop이 되자 빠진 사용처는 컴파일 오류로 드러났습니다. 당시 TypeScript가 찾아낸 렌더링 위치는 ProductDetail 14곳과 ShipmentDetail 7곳, 모두 21곳이었습니다. 사람이 검색어를 잘 고르기를 기대하는 대신 컴파일러가 누락된 곳을 알려주는 계약으로 바뀐 셈입니다.

코드는 이 작업 안에서 이미 고쳤습니다. 하지만 다음 작업의 에이전트는 왜 중앙 목록을 없앴는지 알지 못합니다. 맥락을 모르면 다시 목록을 만들거나, 비슷한 Drawer를 고치면서 openBottomDrawer 호출부만 확인할 수도 있습니다. 저희가 후보로 남기고 싶었던 것은 코드 한 줄이 아니라 그 선택에 이른 판단 기준이었습니다.

작업이 끝난 뒤 Stop hook은 이 사건에서 서로 다른 두 가지 교훈을 찾았고, 각각 Raw Ticket으로 남겼습니다. 첫 번째 티켓에는 공용 Drawer의 ID 계약을 바꿀 때 호출 함수만 검색하지 말고 전체 렌더링 경로를 확인해야 한다는 내용을 담았습니다.

compound-20260722-112558-shared-drawer-overlay-id-audit.md
summary: >
  공유 상세 Drawer의 overlay ID 계약을 변경할 때는
  openBottomDrawer 호출처 검색만으로는 불충분하다.
documentationTargetProposal: docs/llm/url-filter-sync-patterns.md
reuseEvidence: >
  safety-stock의 ProductDetail 마운트 경로를 놓쳐
  해당 화면의 Drawer가 닫히지 않을 뻔했다.
boundary: >
  단일 도메인 Drawer나 내부 UI 변경에는
  앱 전체 감사를 요구하지 않는다.

두 번째 티켓에는 더 근본적인 구조 개선을 담았습니다. 교차 도메인에서 재사용하는 Drawer는 ID 목록을 내부에 열거하지 않고, 마운트하는 화면이 필수 prop으로 ID를 주입한다는 내용입니다.

compound-20260722-130545-drawer-overlay-id-ioc-contract.md
summary: >
  교차 도메인에서 재사용되는 상세 Drawer는 overlay ID 목록을
  내부에 열거하지 않고, 마운트하는 쪽이 필수 prop으로 주입한다.
reuseEvidence: >
  필수 prop을 추가하자 TypeScript가 ProductDetail 14곳과
  ShipmentDetail 7곳의 렌더링 위치를 찾아냈다.
boundary: >
  단일 ID로만 열리는 기존 Drawer를 한꺼번에 전환하라는 규칙은 아니다.

Raw Ticket에는 “필수 prop으로 바꾸자”는 결론만 적지 않습니다. 어떤 경로를 놓쳤는지, 같은 문제가 왜 다시 생길 수 있는지, 규칙을 어디에 남길지, 어디까지 적용할지를 함께 기록합니다. 이렇게 적어두면 원래 대화를 읽지 않은 사람도 후보가 나온 이유와 적용 범위를 확인할 수 있습니다. 반대로 반복 근거나 적용 범위를 설명하기 어렵다면 아직 팀 규칙으로 다룰 후보가 아니라고 봅니다.

후보는 어디까지나 검토 요청입니다. AI가 남겼다는 이유만으로 맞는 규칙이라고 가정하지 않습니다.

사람이 후보의 다음 상태를 결정합니다​

후보가 모이면 개발자가 트리아지 화면을 엽니다. 여기서 트리아지는 후보를 하나씩 살펴보고 다음에 어떻게 처리할지 정하는 일을 뜻합니다. 검토자는 원래 작업의 근거, 기존 문서, 적용 범위를 확인한 뒤 세 가지 중 하나를 고릅니다.

  • 승격(Promoted): 팀 규칙으로 발전시킬 가치가 충분하다.
  • 보류(Held): 가능성은 있지만 근거나 논의가 더 필요하다.
  • 폐기(Discarded): 일회성 문제이거나 이미 있는 규칙과 겹친다.

저희는 이 전체 흐름을 compound-triage라는 상위 스킬로 실행합니다. 하나의 스킬이 모든 일을 한꺼번에 처리하는 대신, 책임이 다른 세 단계를 정해진 순서로 연결합니다.

compound-triage가 session, apply, promote-plan을 순서대로 호출하고 결정 JSON과 승격 여부를 통과 조건으로 확인하는 흐름

compound-triage는 앞 단계의 결과를 확인한 뒤 다음 하위 스킬을 호출합니다. 사람의 결정 데이터가 없으면 적용 단계로 넘어가지 않고 승격된 그룹만 문서 변경 계획이 됩니다. 이미지를 누르면 크게 열립니다.

  1. compound-triage-session은 Raw Ticket을 읽어 비슷한 내용끼리 묶고 사람이 검토할 HTML 화면을 만듭니다. 검토가 끝나면 승격·보류·폐기·미검토 결과가 담긴 결정 데이터를 내보냅니다. 이 단계에서는 아직 파일을 옮기지 않습니다.
  2. compound-triage-apply는 사람이 제출한 결정 데이터가 있을 때만 실행됩니다. 검토한 티켓을 각 상태의 폴더로 옮기고 기록을 갱신하며 미검토 티켓은 다음 검토를 위해 Raw 상태로 남깁니다.
  3. compound-promote-plan은 승격된 티켓을 주제별로 묶어 문서 변경 계획을 만듭니다. 어느 문서의 어떤 부분을 바꿀지, 규칙의 적용 범위를 어디까지로 제한할지, 변경 후 무엇을 확인할지를 계획에 담습니다.

아래 화면은 실제 compound-triage-session의 HTML 템플릿에 설명용 가짜 티켓을 넣어 재현한 것입니다. 검토자는 티켓이 나온 배경과 그대로 뒀을 때의 문제, 제안하는 규칙, 기존 문서와 반영 후 문장의 차이를 한 카드에서 확인합니다.

가짜 검색 필터 티켓의 배경과 문서 반영 미리보기, 승격·보류·폐기 버튼을 보여주는 컴파운드 트리아지 화면

실제 트리아지 UI를 브라우저에서 렌더링해 캡처했습니다. 화면에 표시된 티켓과 경로는 모두 설명을 위해 만든 가짜 데이터이며 이미지를 누르면 크게 열립니다.

공용 Drawer의 두 티켓은 같은 사건에서 나온 진단과 처방으로 묶였습니다. 하나는 놓친 경로를 찾는 방법이었고, 다른 하나는 중앙 목록을 없애 누락을 컴파일 오류로 바꾸는 방법이었습니다. 사람은 둘을 함께 읽고 같은 주제로 승격했습니다. compound-triage-apply가 결정을 반영한 뒤 두 티켓에는 같은 그룹과 Plan 경로가 기록됐습니다.

decision: promoted
groupId: compound-triage-20260728-140841-drawer-overlay-id-contract-23
documentationTarget: docs/llm/url-filter-sync-patterns.md
planStatus: generated
relatedPlanPath: >
  docs/superpowers/plans/
  2026-07-28-update-shared-drawer-overlay-id-audit-and-ioc-contract.md

자동화가 사람의 판단을 앞질러가지 않도록 단계를 나눴습니다. 검토 화면에서 결정 데이터가 제출되지 않으면 티켓을 옮길 수 없고 승격된 후보도 곧바로 문서가 되는 것이 아니라 먼저 변경 계획을 거칩니다.

이 구분은 실제 운영 중 겪은 문제에서 나왔습니다. 한 차례 부분 검토에서는 후보 63개 중 30개만 확인하고 세션을 마쳤는데, 초기 화면은 아직 보지 못한 33개까지 모두 보류로 저장했습니다. 하지만 보류는 “검토해보니 아직 근거가 부족하다”는 사람의 판단입니다. 아직 읽지도 않은 후보와는 의미가 다릅니다.

63개 후보 중 검토한 30개와 미검토 33개를 구분하고, 미검토를 보류로 저장하던 초기 동작과 개선 후 상태를 비교한 화면

보류는 사람이 내린 결정이고 미검토는 아직 결정하지 않았다는 상태입니다.

지금은 검토하지 않은 항목을 미검토(Unreviewed) 상태로 따로 남깁니다. 미검토 후보는 원래 위치에서 다음 트리아지를 기다리고 사람이 실제로 결정한 후보만 승격·보류·폐기 상태로 이동합니다. 작은 상태 하나를 추가한 변화지만 자동화가 사람의 판단을 대신 기록하지 못하게 만드는 데 필요했습니다.

트리아지 결과는 대화 속 동의가 아니라 별도의 결정 데이터로 제출합니다. “좋아 보입니다”라는 AI의 추천과 “팀 규칙으로 채택하겠습니다”라는 사람의 결정을 시스템에서도 구분하려고 만든 장치입니다.

승격된 후보는 문서 변경 계획이 됩니다​

그렇다면 채택한 규칙은 어디에 남고 다음 에이전트는 어떻게 사용하는 걸까요?

WMS Frontend 저장소에는 구조, 구현 패턴, 코딩 규칙, 테스트 방법을 설명하는 문서들이 있습니다. 에이전트는 작업을 시작할 때 먼저 진입 문서를 읽고 현재 작업에 필요한 문서를 찾아가도록 안내받습니다. API를 연동할 때는 API 패턴을, 테스트를 작성할 때는 테스트 규칙을 확인하는 식입니다.

새로운 세션은 이전 대화를 기억하지 못해도 저장소의 문서는 다시 읽을 수 있습니다. 저희가 문서를 에이전트와 사람이 함께 사용하는 팀의 장기 기억으로 보는 이유입니다.

현재 컴파운드 트리아지에서 승격된 후보는 비슷한 주제끼리 묶이고 하나의 문서 변경 Plan으로 이어집니다. 어떤 문서의 어느 부분을 바꿀지, 사례 하나를 너무 넓은 규칙으로 일반화하지는 않았는지, 변경 후 무엇을 확인할지를 Plan에 적습니다.

공용 Drawer 사례에서는 두 티켓을 ‘같은 사건의 진단과 처방’으로 정리했습니다. 필수 prop 주입을 우선 규칙으로 두고, 아직 이 구조를 적용하지 않은 기존 Drawer에만 전체 렌더링 경로 감사를 요구하도록 관계를 정했습니다.

2026-07-28-update-shared-drawer-overlay-id-audit-and-ioc-contract.md
## Goal

공유 상세 Drawer의 overlay ID 계약을 하나의 절로 추가한다.

## Scope

- 교차 도메인에서 재사용하는 Drawer는 overlayId를 필수 prop으로 받는다.
- 기존 열거 방식을 고칠 때는 renderDetail과 타 도메인 렌더링까지 감사한다.
- 단일 도메인 Drawer와 내부 UI 변경에는 이 절차를 강제하지 않는다.

## Success Criteria

한 절만 읽어도 IoC 우선 계약과 기존 Drawer 감사 절차의 관계를 알 수 있다.

Plan을 검토한 뒤 docs/llm/url-filter-sync-patterns.md에 Shared Drawer Overlay ID Contract 절을 추가했습니다. 실제 문서에는 규칙과 적용 범위가 다음과 같이 함께 들어갔습니다.

+ 교차 도메인에서 재사용되는 상세 Drawer는 자신이 열릴 수 있는
+ overlay ID 목록을 내부에 열거하지 않는다.
+ 마운트하는 쪽이 overlayId를 필수 prop으로 전달한다.

+ 아직 열거 방식을 쓰는 기존 Drawer를 고칠 때는
+ openBottomDrawer 호출부만 보지 않는다.
+ 컴포넌트 import, DeepLinkDrawerConfig.renderDetail,
+ 다른 도메인 훅의 인라인 렌더링까지 확인한다.

+ 단일 도메인 Drawer, 내부 UI 변경, ID 기반 닫기 계약이 없는
+ Dialog와 Toast는 이 규칙의 적용 대상이 아니다.

다음 에이전트가 공용 Drawer를 새 화면에서 사용하거나 기존 닫기 계약을 손대면, 중앙 ID 목록을 만들면 안 되는 이유와 기존 구조에서 더 확인해야 할 경로를 문서에서 찾을 수 있습니다. 한 작업에서 내린 판단이 다음 작업의 출발점으로 남았습니다.

여기서 순서를 구분할 필요가 있습니다. overlayId를 필수 prop으로 바꾼 코드 수정은 트리아지 전에 끝났습니다. 컴파운드 트리아지가 해결 코드를 만들어낸 것은 아닙니다. 작업 중 검증한 해결책과 그 판단 기준을 다음 작업에서도 재사용할 수 있도록 보존한 것입니다.

컴파운드 트리아지가 문서까지 자동으로 고치는 것도 아닙니다. 후보를 수집하고 사람이 분류하고 승격된 후보의 문서 변경 Plan을 만드는 데까지를 담당합니다. 실제 문서 변경과 검증은 별도의 작업으로 남겨두었습니다.

문서로 설명하고, 기계가 확인하게 만들기​

문서에 규칙을 남겼다고 해서 모든 문제가 해결되지는 않았습니다. 에이전트가 관련 문장을 놓칠 수도 있고 읽었지만 현재 코드에 어떻게 적용해야 하는지 다르게 해석할 수도 있습니다.

공용 Drawer 사례에서는 overlayId 필수 prop이 기계적인 안전장치가 됐습니다. 규칙이 필요한 이유와 적용 범위는 문서가 설명하고, 빠진 prop은 TypeScript가 코드 작성 단계에서 찾습니다. 문서와 타입이 서로 다른 일을 맡습니다.

WMS Frontend에는 이미 이런 실수를 줄이기 위한 프로젝트 전용 lint 규칙도 있습니다. 현재는 Biome의 GritQL 플러그인으로 다음과 같은 패턴을 검사합니다.

  • 번역 함수가 안전하지 않은 시점에 실행되는 코드
  • renderHook 안에서 렌더링할 때마다 새로운 객체나 배열을 만드는 테스트 코드
  • 검색 버튼과 재조회 동작이 연결되지 않은 검색 필터

코드를 작성한 뒤 lint를 실행하면 에이전트가 문서를 기억하고 있는지와 관계없이 위반을 찾습니다. 이 자동 검증 체계는 이미 사용하고 있지만 지금까지 컴파운드 트리아지에서 승격된 후보는 모두 문서 변경 Plan으로만 변환했습니다. 기존 lint 규칙이 컴파운드 트리아지를 통해 만들어졌다는 뜻은 아닙니다.

다음 단계에서는 이 두 흐름을 연결해보려고 합니다. 승격된 교훈은 지금처럼 문서에 배경과 적용 범위, 예외를 남깁니다. 그중 코드만 보고도 위반 여부를 명확히 판정할 수 있는 부분은 타입이나 lint, 테스트, 정적 검사로도 구현합니다.

코드만 보고 위반을 명확히 판정할 수 있는지에 따라 문서와 작업 절차에 남길지, 문서와 자동 검증을 함께 적용할지 나누는 기준

모든 규칙의 맥락은 문서에 남기고 기계가 판단할 수 있는 위반만 타입·lint·테스트·정적 검사로 한 번 더 확인합니다.

모든 규칙을 자동 검증으로 만들 수는 없습니다. “공용 Drawer의 전체 렌더링 경로를 확인한다”는 절차는 코드 한 조각만 보고 지켰는지 판단하기 어렵습니다. 이런 내용은 문서와 작업 절차로 전달하는 편이 낫습니다. 반면 필수 overlayId prop처럼 코드 구조로 표현할 수 있는 규칙은 TypeScript가 바로 확인합니다.

문서에는 규칙이 필요한 이유와 적용 범위를 남기고 기계가 판정할 수 있는 위반은 자동 검증에서 한 번 더 잡는 방식입니다. 문서를 자동 검증으로 대체하는 것이 아니라, 문서만으로 놓치는 부분에 안전장치를 하나 더 두려는 것입니다.

운영하면서 계속 다듬고 있습니다​

컴파운드 트리아지는 지금도 FE팀에서 운영하며 여러 부분을 고치고 있습니다. 가장 먼저 체감한 문제는 티켓의 양이었습니다. Stop hook의 캡처 기준을 느슨하게 두면 작은 관찰까지 티켓이 되어 쌓입니다. 그러면 한 번의 트리아지에서 모두 검토하지 못하고 다음 회차로 미뤄지는 티켓도 빠르게 늘어납니다. 많이 모으는 것보다 다시 쓸 가치가 있는 경험만 남도록 캡처 기준을 정제하는 일이 중요합니다.

앞으로 FE팀의 인원이 늘어나면 티켓 수도 함께 늘어날 가능성이 큽니다. 지금의 운영 방식이 늘어난 티켓을 감당할 수 있을지는 아직 알 수 없습니다. 중요한 후보를 놓치지 않으면서도 트리아지가 밀리지 않도록, 티켓을 모으고 검토하는 방식 역시 팀 규모에 맞게 바꿔가야 합니다.

티켓을 만든 사람도 막상 트리아지를 진행할 때는 당시의 작업 맥락을 잊곤 합니다. 공용 Drawer 티켓도 나중에 다시 읽었을 때 “필수 prop으로 바꾼다”는 결론만 있었다면 안전 재고 화면을 왜 놓쳤는지, 두 티켓을 왜 함께 봐야 하는지 판단하기 어려웠을 것입니다. 그래서 트리아지 세션에서 함께 보는 HTML 화면은 단순히 승격·보류·폐기를 선택하는 도구에 그쳐서는 안 됩니다. 원래 작업을 다시 찾아보지 않아도 무엇을 발견했고 왜 규칙 후보가 되었으며 어디까지 적용하려는지 이해할 수 있어야 합니다. 현재 화면도 이런 정보를 담고 있지만 아직 개선할 부분이 많습니다. 앞으로는 배경지식이 없는 사람도 티켓의 내용을 충분히 이해하고 판단하도록 UI와 정보 구조를 계속 다듬을 예정입니다.

컴파운드 트리아지가 해야 할 일은 규칙의 개수를 늘리는 것이 아닙니다. FE팀이 WMS Frontend를 개발하며 얻은, 우리 프로젝트에서만 쌓을 수 있는 규칙과 판단 기준을 축적하고 에이전트가 다음 작업에서 꺼내 쓸 컨텍스트로 만드는 일입니다. 컴파운드 트리아지도 이 역할에 맞게 운영 경험을 반영해 계속 개선할 생각입니다.

공용 Drawer 사례에서는 안전 재고 화면에서 놓칠 뻔한 경로가 두 개의 Raw Ticket으로 남았습니다. 사람은 두 후보를 같은 주제로 승격했고, Plan은 진단과 처방을 하나의 문서 절로 묶었습니다. 다음 에이전트는 이전 대화를 기억하지 못해도 그 문서와 필수 prop 계약에서 같은 판단을 다시 꺼내 쓸 수 있습니다.

AI 에이전트와 일하면서 같은 실수를 반복하거나 매번 같은 맥락을 다시 설명하고 있다면, 작은 범위에서 컴파운드 트리아지를 직접 운영해보는 것도 추천합니다. 처음부터 완벽한 체계를 만들기보다, 한 번의 작업에서 얻은 교훈을 후보로 남기고 사람이 검토하는 흐름부터 시작해보셔도 좋겠습니다.