빌드잇
경력근거: AI Agent 기반 프로세스 자동화 솔루션 제품화
빌드잇은 엔터프라이즈 솔루션 10년 위에서 'AI Agent 기반 프로세스 자동화 솔루션 제품화' 로 전환 중인 회사입니다. 공고가 자격요건에 'AI Code Assistant 또는 Agent 활용 경험' 을, 우대사항에 'AI/ML 프로젝트 참여 또는 AI Agent 개발 경험' 과 '데이터 스트리밍, 메시지 큐 활용 경험' 을 나란히 적은 대로, 자유 텍스트를 실행 가능한 액션으로 바꾸고 큐로 넘기는 구간이 이 회사가 제품화하려는 지점입니다. 고객사 상주 근무가 있는 SI 구조라 요청 채널과 대상 시스템이 회사마다 다르므로, 액션 카탈로그를 데이터로 두고 코드를 그대로 두는 설계가 맞습니다. 이 포트폴리오가 보여주는 것은 원문을 카탈로그에 붙여 결정하고 인용으로 검증하는 기술이며, 고객사 업무 도메인 전문성은 주장하지 않습니다. 모르는 깊이는 면접에서 모른다고 말하는 편이 낫습니다.
엔터프라이즈 솔루션 10년 위에서 'AI Agent 기반 프로세스 자동화 솔루션' 을 제품화하는 단계입니다. 자유 텍스트 업무 요청을 사내 시스템 액션으로 잇는 워크플로우가 바로 그 제품의 최소 뼈대입니다.
'AI Agent Business : AI Agent 기반 프로세스 자동화 솔루션 제품화'. 자동화 제품을 만드는 자리입니다.
Kotlin/Spring 과 Python/FastAPI, 메시지 큐(Kafka·RabbitMQ), Docker/Kubernetes, AWS 가 주요 스택입니다. 결정 서비스와 실행 커넥터를 큐로 분리한 MSA 로 이 스택을 그대로 골조에 씁니다.
네이버웍스·슬랙·메일·폼으로 들어오는 사내 업무 요청 원문을 읽어, 액션 카탈로그의 별칭과 필수 파라미터에 붙여 실행할 액션과 값을 정하고 파라미터마다 원문 인용 근거를 답니다. 값이 빠졌거나 붙일 액션이 없으면 지어내지 않고 사유별로 나눠 담당자가 확인할 자리로 보냅니다. 담당자가 확인한 요청만 Kotlin/Spring 게이트웨이가 메시지 큐로 커넥터에 디스패치합니다. 업무 요청과 액션 카탈로그는 실 데이터 대신 더미를 가정합니다.
빌드잇 PE. 사내로 쏟아지는 '다음 주 연차 올려주세요', '법카 3월 사용내역 조회', '회의실 프로젝터 고장 수리 티켓 등록' 같은 자유 텍스트 요청을 사람이 일일이 읽고 어느 시스템에 어떤 값으로 넣을지 손으로 판단하던 상황을 끝내고, 에이전트가 근거를 붙여 액션을 정하되 실제 실행은 큐로 안전하게 넘기게 하고 싶은 사람입니다.
업무 요청 원문과 실행 가능한 액션 카탈로그(required_params 포함)를 한 스키마로 묶으면, LLM 이 (a) 의도와 실행할 액션 타입·액션 ID 를, (b) 원문에서 인용한 근거(evidence_span)를 붙인 파라미터를, 몇 초 안에 뽑고, (c) 필요한 값이 빠졌거나 매핑되는 액션이 없으면 지어내지 않고 결측·미매핑으로 표시한 뒤 사람에게 라우팅합니다.
자유 텍스트 업무 요청을 액션 카탈로그에 붙여 액션과 파라미터를 정하고, 원문 인용이 실제로 있는지 검증한 뒤 사유별로 나눠 보여주며, 확정된 요청만 목(mock) 커넥터로 큐 디스패치하는 관리자 페이지가 도는 완결품입니다.
정답셋 40건으로 액션 타입·액션 ID 분류가 맞았는지 확인하고, Claude Haiku 저비용 2차 분류로 불일치·저확신 건을 사람 큐로 라우팅하며, RabbitMQ 재시도·DLQ 와 Kafka 감사 스트림을 붙인 뒤 2주차부터 AWS EKS 로 배포·운영하는 단계입니다.
목 커넥터를 실 시스템 어댑터 인터페이스로 교체 가능하게 추상화하고, 액션 카탈로그가 수백 개로 늘어도 후보를 검색(retrieval)으로 압축하며, Redis 멱등 키와 권한 가드로 중복 실행을 막는 단계입니다.
담당자가 업무 요청 12건을 넣으면 각 요청의 액션과 파라미터, 원문 인용 근거가 사유별로 묶여 나오고 확정된 것만 큐로 넘어가는 걸 시연합니다.
일부러 만든 결측·표기흔들림·미매핑·잡담 입력 30종을 넣어도 출력 형식(JSON Schema)이 한 번도 안 깨지고, 인용 span 이 원문에 실제로 존재하는지 자동 검증을 100% 통과합니다
내가 만든 정답 40건과 화면이 낸 액션 타입·액션 ID 를 대조해 일치율을 냅니다. 단, 정답과 데이터를 모두 작성자가 만든 합성 기준이라 성능 검증이 아니라 데모 조건 동작입니다.
매 결정과 커넥터 실행 결과가 감사 이벤트로 Kafka 에 남고, 콘솔에서 요청→액션→커넥터 결과가 추적되는 걸 시연합니다
위 수치는 전부 작성자가 만든 더미데이터 자가채점이며, 실제 분류 정확도·인용 정합은 빌드잇 실제 업무 요청과 실 커넥터 연동이 있어야 측정 가능합니다. 이 포트폴리오는 그 검증을 바로 돌릴 수 있는 상태로 만듭니다
이건 고객·실데이터 없이 혼자 만든 포트폴리오입니다. 모든 수치는 합성 데이터 자가채점이라 '성능 증명' 이 아닙니다. 면접에서 솔직히 '데모 조건 동작 + 실검증 준비 상태' 로 설명합니다
정답을 작성자가 만들었으니 잘 맞는 것이 당연합니다. 일부러 헷갈리는 결측(금액 미기재)·표기흔들림(법카/월차)·미매핑(레지스트리에 없는 요청)·잡담·맥락부족 케이스를 더미에 섞어, 쉬운 문제만 푸는 게 아님을 보여줘야 합니다
자유 텍스트 의도 분류는 표면 단어에 휘둘리기 쉽고, 한 요청에 조회+결재가 섞인 멀티인텐트를 단정하면 위험합니다. 저확신·불일치 건은 지어내지 않고 사람에게 라우팅하며, 멀티인텐트는 1차 액션만 실행하고 후속을 별도 요청으로 분해합니다
실제 도입 시 달라지는 것을 명시합니다. 여기서는 사내 시스템 커넥터(네이버웍스 결재·ERP·Jira)를 목 API 로 두고 action plan 생성부터 큐 디스패치까지만 만들며, 실 커넥터 연동·실행 권한·감사 연계와 고객사별 업무 규칙의 깊이는 도입 단계 과제로 분리합니다
① 인라인 샘플 · ② seed.json 다운로드 · ③ 증강 프롬프트. 세 층 모두 동일한 schema 에서 파생.
네이버웍스·슬랙·메일·폼으로 들어온 사내 업무 요청 원문입니다. 값이 빠진 요청, 별칭으로 쓴 요청, 맥락이 모자란 요청, 업무 요청이 아닌 잡담을 섞어 두어 액션 결정이 원문에서만 도출되게 합니다. 정답 라벨과 판정 메모는 이 표에 두지 않습니다 — 도구가 읽는 표에 답이 있으면 하는 일이 조회가 됩니다.
| request_id | channel | raw_text | submitted_by | received_at |
|---|---|---|---|---|
| req_001 | slack | 다음 주 월화 이틀 연차 상신 부탁드려요 | 인사팀 | 2026-06-02T09:14:00 |
| req_002 | naverworks | 3월 팀 회식비 법카 결재 좀 올려주세요 | 영업1팀 | 2026-06-02T10:02:00 |
| req_003 | slack | 판교 창고에 프로젝터 재고 몇 대 남았는지 확인해줘 | 총무팀 | 2026-06-02T11:30:00 |
| req_004 | A커머스 계약서 만료일 언제인지 조회 부탁합니다 | 제휴팀 | 2026-06-03T09:05:00 | |
| req_005 | slack | 회의실 미팅룸 빔프로젝터 고장났어요. 수리 티켓 등록해주세요 | 개발팀 | 2026-06-03T13:20:00 |
아래 JSON Schema 를 그대로 만족하는 사내 업무 요청 행을 60개 더 만들어 주세요. 결재·조회·등록 요청을 4:4:2 로 섞고, 그중 2할은 필수 값이 빠진 요청, 1할은 별칭 표기(월차·법카·미팅룸), 1할은 맥락이 모자란 한 줄, 1할은 업무 요청이 아닌 잡담으로 두세요. 정답이나 판정 메모는 넣지 마세요.
{"type": "object", "properties": {"request_id": {"type": "string"}, "channel": {"type": "string", "enum": ["slack", "naverworks", "email", "form"]}, "raw_text": {"type": "string"}, "submitted_by": {"type": "string"}, "received_at": {"type": "string"}}, "required": ["request_id", "channel", "raw_text", "submitted_by", "received_at"]}{"type": "object", "properties": {"request_id": {"type": "string"}, "channel": {"type": "string", "enum": ["slack", "naverworks", "email", "form"]}, "raw_text": {"type": "string"}, "submitted_by": {"type": "string"}, "received_at": {"type": "string"}}, "required": ["request_id", "channel", "raw_text", "submitted_by", "received_at"]}에이전트가 트리거할 수 있는 사내 시스템 액션 카탈로그. 각 액션의 필수 파라미터(required_params)와 대상 시스템, 커넥터, 트리거 별칭을 담습니다. 요청의 gold_action_id 가 이 표에 조인되어야 하며, 조인 실패(orphan)면 지어내지 말고 미매핑으로 알려야 합니다. 결측 판정의 기준(required_params)이자 별칭 정규화의 사전입니다.
| action_id | name | action_type | target_system | required_params | aliases | connector |
|---|---|---|---|---|---|---|
| act_leave_approval | 연차/휴가 결재 상신 | approval | 네이버웍스결재 | ["start_date","days"] | ["연차","휴가","반차","월차"] | connector_naverworks |
| act_expense_approval | 지출 결재 상신 | approval | ERP | ["amount","category","period"] | ["법인카드","법카","지출","경비","회식비"] | connector_erp |
| act_purchase_approval | 구매 품의 | approval | ERP | ["item","qty","amount"] | ["구매","품의","발주"] | connector_erp |
| act_inventory_lookup | 재고 조회 | lookup | WMS | ["item","location"] | ["재고","창고","남은 수량"] | connector_wms |
| act_contract_lookup | 계약 조회 | lookup | 계약관리 | ["counterparty"] | ["계약","계약서","만료일"] | connector_contract |
아래 JSON Schema 에 맞는 한국 엔터프라이즈 사내 시스템 액션 카탈로그 20행을 JSON 배열로 생성하세요. action_type 은 approval/lookup/register 세 종을 고루, 대상 시스템(target_system)은 네이버웍스결재·ERP·WMS·Jira·CRM·계약관리 등으로 자연스럽게 분포시키세요.
{"type":"object","properties":{"action_id":{"type":"string"},"name":{"type":"string"},"action_type":{"enum":["approval","lookup","register"]},"target_system":{"type":"string"},"required_params":{"type":"array","items":{"type":"string"}},"aliases":{"type":"array","items":{"type":"string"}},"connector":{"type":"string"}},"required":["action_id","name","action_type","target_system","required_params"]}
조건: (1) 각 액션의 required_params 는 실제 결재·조회·등록에 필요한 2~3개로 현실적으로, (2) aliases 에 구어체 별칭('법카','월차','미팅룸' 같은)을 1~4개씩 넣어 표기흔들림 정규화가 가능하게, (3) connector 는 target_system 과 정합되는 이름으로. JSON 배열만 출력하세요.{"type":"object","properties":{"action_id":{"type":"string"},"name":{"type":"string"},"action_type":{"enum":["approval","lookup","register"]},"target_system":{"type":"string"},"required_params":{"type":"array","items":{"type":"string"}},"aliases":{"type":"array","items":{"type":"string"}},"connector":{"type":"string"}},"required":["action_id","name","action_type","target_system","required_params"]}2주차 평가 러너가 쓰는 정답 라벨입니다. 1주차 도구는 이 표를 읽지 않습니다 — 원문만 보고 낸 결정과 여기 라벨을 나중에 대조해 일치율을 냅니다. 결측·별칭·미매핑·잡담 판정의 근거 메모도 여기에 둡니다.
| request_id | gold_action_type | gold_action_id | gold_params | gold_missing_params | gold_note |
|---|---|---|---|---|---|
| req_001 | approval | act_leave_approval | {"start_date":"다음 주 월","days":"이틀"} | [] | — |
| req_002 | approval | act_expense_approval | {"category":"회식비","period":"3월"} | ["amount"] | 결측: 금액(amount) 미기재. 지어내지 말고 결측 플래그 |
| req_003 | lookup | act_inventory_lookup | {"item":"프로젝터","location":"판교 창고"} | [] | — |
| req_004 | lookup | act_contract_lookup | {"counterparty":"A커머스"} | [] | — |
| req_005 | register | act_issue_register | {"asset":"빔프로젝터","symptom":"고장","location":"회의실"} | [] | 표기흔들림: '미팅룸'='회의실' 별칭 정규화 필요 |
아래 JSON Schema 를 그대로 만족하는 정답 라벨 행을 60개 더 만들어 주세요. work_requests 의 request_id 와 1:1 로 맞추고, 액션이 없는 요청은 gold_action_id 를 null 로 둡니다.
{"type": "object", "properties": {"request_id": {"type": "string"}, "gold_action_type": {"type": ["string", "null"]}, "gold_action_id": {"type": ["string", "null"]}, "gold_params": {"type": "object"}, "gold_missing_params": {"type": "array", "items": {"type": "string"}}, "gold_note": {"type": ["string", "null"]}}, "required": ["request_id", "gold_action_type"]}{"type": "object", "properties": {"request_id": {"type": "string"}, "gold_action_type": {"type": ["string", "null"]}, "gold_action_id": {"type": ["string", "null"]}, "gold_params": {"type": "object"}, "gold_missing_params": {"type": "array", "items": {"type": "string"}}, "gold_note": {"type": ["string", "null"]}}, "required": ["request_id", "gold_action_type"]}| Kotlin | Spring Boot 액션 게이트웨이의 대표 언어. 결정된 action plan 을 사내 시스템 커넥터로 디스패치하는 오케스트레이터입니다 |
| Spring | 요청 인테이크 API + 액션 게이트웨이 (`POST /requests` 로 요청을 받아 큐 발행, 커넥터 라우팅, 감사 로그 적재) |
| Python | FastAPI 에이전트의 전처리, 인용 검증(evidence_span 이 원문 substring 인지 결정론 매칭), 분류 정확도 평가 스크립트 |
| FastAPI | AI Agent 추론 엔드포인트 (`POST /plan`. 자유 텍스트 요청 → action plan 반환) |
| PostgreSQL | work_requests·action_registry·audit_log 단일 진실원 + 결정·실행 감사 추적 |
| Redis | 요청 멱등(idempotency) 키 + 커넥터 호출 rate-limit |
| RabbitMQ | 액션 디스패치 작업 큐. 결정과 커넥터 실행을 분리하고 재시도·DLQ 로 실패를 격리합니다 |
| Apache Kafka | 감사 이벤트 스트림. 모든 결정과 커넥터 실행 결과를 append-only 로 남겨 재생 가능하게 합니다 |
| Docker | 에이전트·게이트웨이·커넥터를 각각 컨테이너로 분리 패키징 |
| Kubernetes | 세 서비스를 MSA 배포 단위로 오케스트레이션 |
| AWS(EKS) | 2주차부터 EKS 로 배포·운영합니다 (JD 명시 인프라) |
| TypeScript | 요청→액션 콘솔의 타입 안전 (프론트 전반) |
| Next.js | 콘솔 UI (인입 요청 큐·결정된 액션·원문 인용 하이라이트·감사 로그) |
| Zustand | 콘솔 요청 큐·필터·선택 상태 관리 |
| Zod | 프론트 런타임 action plan 스키마 검증 |
✓ pass → 그대로 멈춰도 완결입니다. 더 키우고 싶으면 2주차(분류가 실제로 맞았는지 확인 + 재시도·감사 + EKS 배포)로 진행합니다.
✓ pass → 여기서 멈춰도 완결입니다. 더 키우면 3주차(실 커넥터 어댑터 교체 + 레지스트리 확장 + 멱등·권한 가드)로 진행합니다.
위 예측 UI 는 3주차까지 완주했을 때의 화면입니다. 1주차에 실제로 만드는 것은 아래 표시된 화면 하나입니다.
plan_code사유 라벨 · request_id + 한 줄 요약(근거 수치 포함)화면·코드·면접에서 이 단어를 그대로 씁니다. 키는 출력 스키마의 enum 과 같습니다.
dispatched큐 전달param_missing값 부족action_unmapped액션 미매핑context_missing맥락 부족not_a_request업무 요청 아님업무 요청 한 건마다 실행할 액션과 값을 정하고, 확정되지 않으면 무엇이 막았는지 사유 코드로 냅니다. 화면은 이 사유 코드로 요청 목록을 묶고, dispatched 만 큐로 넘어갑니다.
{"type": "object", "properties": {"request_id": {"type": "string"}, "plan_code": {"type": "string", "enum": ["dispatched", "param_missing", "action_unmapped", "context_missing", "not_a_request"]}, "intent": {"type": "string"}, "action_type": {"type": ["string", "null"], "enum": ["approval", "lookup", "register", null]}, "action_id": {"type": ["string", "null"]}, "params": {"type": "array", "items": {"type": "object", "properties": {"name": {"type": "string"}, "value": {"type": "string"}, "evidence_span": {"type": "string"}}, "required": ["name", "value", "evidence_span"]}}, "missing_params": {"type": "array", "items": {"type": "string"}}, "route_to": {"type": ["string", "null"]}, "evidence": {"type": "array", "items": {"type": "object", "properties": {"field": {"type": "string"}, "agg": {"type": ["string", "null"]}, "value": {}}, "required": ["field", "value"]}}, "rationale": {"type": "string"}}, "required": ["request_id", "plan_code", "intent", "action_id", "params", "missing_params", "evidence", "rationale"]}[
{
"request_id": "req_001",
"plan_code": "dispatched",
"intent": "다음 주 월요일부터 이틀 연차 결재 상신",
"action_type": "approval",
"action_id": "act_leave_approval",
"params": [
{
"name": "start_date",
"value": "다음 주 월",
"evidence_span": "다음 주 월"
},
{
"name": "days",
"value": "이틀",
"evidence_span": "이틀"
}
],
"missing_params": [],
"route_to": null,
"evidence": [
{
"field": "raw_text",
"agg": null,
"value": "다음 주 월화 이틀 연차 상신 부탁드려요"
},
{
"field": "aliases",
"agg": null,
"value": [
"연차",
"휴가",
"반차",
"월차"
]
},
{
"field": "required_params",
"agg": null,
"value": [
"start_date",
"days"
]
}
],
"rationale": "원문의 ‘연차’ 가 연차 결재 액션의 별칭 목록에 있고 필수 값 두 개가 원문에서 모두 인용돼 확정했습니다."
},
{
"request_id": "req_003",
"plan_code": "dispatched",
"intent": "판교 창고 프로젝터 재고 수량 조회",
"action_type": "lookup",
"action_id": "act_inventory_lookup",
"params": [
{
"name": "item",
"value": "프로젝터",
"evidence_span": "프로젝터"
},
{
"name": "location",
"value": "판교 창고",
"evidence_span": "판교 창고"
}
],
"missing_params": [],
"route_to": null,
"evidence": [
{
"field": "raw_text",
"agg": null,
"value": "판교 창고에 프로젝터 재고 몇 대 남았는지 확인해줘"
},
{
"field": "required_params",
"agg": null,
"value": [
"item",
"location"
]
}
],
"rationale": "원문의 ‘재고’ 가 재고 조회 액션의 별칭이고 품목과 위치가 모두 인용돼 확정했습니다."
},
{
"request_id": "req_002",
"plan_code": "param_missing",
"intent": "3월 팀 회식비를 법인카드 지출로 결재 상신",
"action_type": "approval",
"action_id": "act_expense_approval",
"params": [
{
"name": "category",
"value": "회식비",
"evidence_span": "회식비"
},
{
"name": "period",
"value": "3월",
"evidence_span": "3월"
}
],
"missing_params": [
"amount"
],
"route_to": null,
"evidence": [
{
"field": "raw_text",
"agg": null,
"value": "3월 팀 회식비 법카 결재 좀 올려주세요"
},
{
"field": "required_params",
"agg": null,
"value": [
"amount",
"category",
"period"
]
}
],
"rationale": "지출 결재가 요구하는 값 셋 중 금액이 원문에 없어 지어내지 않고 결측으로 표시했습니다."
},
{
"request_id": "req_013",
"plan_code": "param_missing",
"intent": "복사용지 500박스 구매 품의 상신",
"action_type": "approval",
"action_id": "act_purchase_approval",
"params": [
{
"name": "item",
"value": "복사용지",
"evidence_span": "복사용지"
},
{
"name": "qty",
"value": "500박스",
"evidence_span": "500박스"
}
],
"missing_params": [
"amount"
],
"route_to": null,
"evidence": [
{
"field": "raw_text",
"agg": null,
"value": "복사용지 500박스 구매 품의 올려주세요"
},
{
"field": "required_params",
"agg": null,
"value": [
"item",
"qty",
"amount"
]
}
],
"rationale": "구매 품의가 요구하는 금액이 원문에 없어 결측으로 표시했습니다."
},
{
"request_id": "req_008",
"plan_code": "action_unmapped",
"intent": "고객사 상주 교통비 정산 담당 문의",
"action_type": null,
"action_id": null,
"params": [],
"missing_params": [],
"route_to": "총무팀",
"evidence": [
{
"field": "raw_text",
"agg": null,
"value": "고객사 상주 교통비 정산은 어느 팀에 문의해야 하나요?"
},
{
"field": "action_id",
"agg": "count",
"value": 10
}
],
"rationale": "카탈로그의 액션 열 개 어느 별칭에도 교통비 정산이 붙지 않아 액션을 지어내지 않고 담당 팀으로 보냅니다."
},
{
"request_id": "req_010",
"plan_code": "context_missing",
"intent": "무엇을 처리해 달라는지 지목되지 않은 요청",
"action_type": null,
"action_id": null,
"params": [],
"missing_params": [],
"route_to": "요청자 확인",
"evidence": [
{
"field": "raw_text",
"agg": null,
"value": "그거 좀 빨리 처리해주세요"
}
],
"rationale": "‘그거’ 가 무엇인지 원문에 없어 액션 후보를 좁히지 못했습니다. 요청자에게 되묻는 자리로 보냅니다."
},
{
"request_id": "req_009",
"plan_code": "not_a_request",
"intent": "잡담",
"action_type": null,
"action_id": null,
"params": [],
"missing_params": [],
"route_to": null,
"evidence": [
{
"field": "raw_text",
"agg": null,
"value": "다들 점심 뭐 드셨어요 ㅎㅎ"
}
],
"rationale": "실행 가능한 업무 요청이 아니어서 어떤 커넥터로도 넘기지 않습니다."
}
][자동 검증 · 코드가 판정합니다] 1. plan_code 가 enum 다섯 값 중 하나인지 확인합니다. 2. request_id·plan_code·intent·action_id·params·missing_params·evidence·rationale 이 모두 채워졌는지 확인합니다. 3. params 의 evidence_span 이 그 요청 raw_text 에 문자열 그대로 있는지 대조해 지어낸 인용을 거릅니다. 4. action_id 가 액션 카탈로그에 실재하는 값인지 대조합니다. 5. plan_code 가 dispatched 이면 그 액션의 required_params 가 params 에 모두 있는지 확인합니다. 6. plan_code 가 param_missing 이면 missing_params 가 비어 있지 않은지 확인합니다. 7. plan_code 가 dispatched 가 아니면 큐 디스패치 대상에서 빠지는지 확인합니다. 8. evidence 의 field 이름이 업무 요청과 액션 카탈로그에 실재하는 컬럼인지 대조합니다. 9. agg 가 없는 evidence 의 value 가 그 컬럼에 수록된 행 값과 같은지 확인합니다. 10. rationale 이 존댓말로 끝나는지 확인합니다. [평가 러너 · 2주차] request_gold_labels 의 정답 라벨과 화면이 낸 결정을 대조해 액션 타입·액션 ID 일치율과 사유 코드별 분포를 냅니다. [수동 검증 · 사람이 봅니다] 1. 멀티 인텐트 요청(조회 뒤 결재)을 한 액션으로 볼지 나눌지 담당자가 정합니다. 2. 맥락이 모자란 요청을 되묻을지 담당 팀으로 보낼지 운영 관례를 따라 정합니다.