빌드잇은 엔터프라이즈 프로젝트를 AI Agent 기반 프로세스 자동화 솔루션으로 제품화하는 Solution Business를 성장 축으로 세우고 있어, 반복 업무 요청을 도구 호출로 자동화하는 문제가 빌드잇의 사업 구성에서 현실적으로 나옵니다. 이 포트폴리오가 입증하는 것은 AI Agent 도구 호출·인자 검증·에스컬레이션을 백엔드로 구현하는 기술이며, 특정 고객사 업무 도메인 전문성은 주장하지 않습니다. 모르는 깊이는 면접에서 모른다고 말하는 편이 낫습니다.
빌드잇 Solution Business가 지향하는 AI Agent 기반 프로세스 자동화를, 업무 요청을 도구 호출로 처리하는 콘솔로 구현합니다.
요구사항 정의부터 운영 개선까지 담당 영역을 end-to-end로 책임지며, 도구 호출·에스컬레이션 규칙을 직접 설계하고 개선합니다.
응답 시간·처리 성공률을 재고 도구 호출 실패·예외 케이스를 분석해, 자동화가 현장에서 안정적으로 도는 근거를 만듭니다.
빌드잇 Solution Business가 지향하는 AI Agent 기반 업무 프로세스 자동화를 콘솔로 구현합니다. 사내·고객사에서 반복되는 업무 요청을 받아 처리 가능한 건은 AI Agent가 조회·등록·상태변경 도구 호출로 끝내고, 도구 호출 인자가 규칙에 맞는지 검증하며 근거를 답니다. 애매하거나 권한·정책에 걸리는 요청은 담당자에게 근거와 함께 에스컬레이션합니다. 업무 요청은 사내 데이터 대신 더미를 가정합니다.
같은 유형의 업무 요청 티켓이 매일 쌓여 조회·등록·상태변경을 손으로 반복하던 운영 담당자가, 처리 가능한 건은 자동으로 끝나고 애매한 건만 근거와 함께 자기에게 넘어오게 하고 싶은 사람입니다.
업무 요청을 AI Agent가 도구 호출로 처리하되 각 호출의 인자를 규칙으로 검증하고 처리 근거를 남기면, 권한·정책에 걸리거나 애매한 건만 담당자에게 넘기면서 반복 요청을 자동으로 끝낼 수 있다는 가정입니다.
업무 요청 더미를 넣으면 AI Agent가 조회·등록·상태변경 도구 호출로 처리하되, 호출 인자가 스키마와 허용 값·권한 규칙에 맞는지 검증하고 처리 근거를 붙여, 자동 완료 건과 담당자 에스컬레이션 건을 나눠 돌려주는 콘솔이 도는 완결품입니다. 권한·정책에 걸리거나 근거가 부족하면 처리하지 않고 담당자로 넘깁니다. 업무 요청은 사내 데이터 대신 더미를 가정합니다.
1주차 콘솔에 응답 시간과 도구 호출 성공률 측정을 붙이고, 호출 실패·예외 케이스를 유형별로 분석해 재시도·에스컬레이션 규칙을 정리하며, 자동 처리율과 오처리 0건을 함께 보여줍니다.
여러 내부·외부 시스템을 연동해 도구 세트를 넓히고, AWS로 배포·운영하면서 이벤트 큐 기반 비동기 처리와 부하 시 처리 지연을 측정해 보여줍니다.
업무 요청 더미를 넣으면 처리 가능한 건은 도구 호출로 끝나고 걸리는 건은 근거와 함께 에스컬레이션되는 과정을 시연합니다.
도구 호출 인자가 스키마·권한 규칙을 통과하는 비율과 자동 처리율을 보여주며, 단 정답과 더미를 작성자가 만든 합성 기준이라 성능 검증이 아니라 데모 조건 동작입니다.
일부러 만든 권한 위반·근거 부족·표기 흔들림 30종을 넣어도 콘솔이 멈추지 않고 잘못된 호출을 막고 에스컬레이션하는 강건성을 보여줍니다.
위 수치는 더미데이터 자가채점이며, 실제 자동 처리율과 오처리율은 빌드잇 실 업무 요청과 실 운영자가 있어야 측정 가능합니다. 이 포트폴리오는 그 검증을 바로 돌릴 수 있는 상태까지 만듭니다.
수치는 합성 데이터 자가채점이라 성능 증명이 아니므로, 면접에서는 데모 동작과 실검증 준비 상태로 솔직히 설명합니다.
정답을 작성자가 만들었으니 잘 맞는 게 당연하므로, 권한 위반·근거 부족·표기 흔들림 같은 경계 케이스를 더미에 일부러 섞어 쉬운 문제만 푸는 함정을 피합니다.
이 포트폴리오가 입증하는 것은 AI Agent 도구 호출·인자 검증·에스컬레이션 백엔드 기술이며, 특정 고객사 업무 도메인 전문성은 주장하지 않습니다. 처리 판정은 스키마·권한 규칙으로 채점하고 LLM은 도구 선택·근거 요약만 맡아 잘못된 호출이 통과하지 못하게 합니다.
실제 도입 때는 고객사별 도구 세트·권한 정책과 실 업무 요청 분포로 검증 규칙이 달라지므로, 도구 세트와 권한 규칙 교체를 도입 단계 과제로 둡니다.
① 인라인 샘플 · ② seed.json 다운로드 · ③ 증강 프롬프트. 세 층 모두 동일한 schema 에서 파생.
사내·고객사 업무 요청으로, 권한 위반·근거 부족·필수 항목 결측·표기 흔들림 같은 하드 케이스를 일부러 섞어 자동 처리와 에스컬레이션 판정이 제대로 도는지 확인합니다.
| req_id | type | payload | requester_role | target_ref |
|---|---|---|---|---|
| W-001 | 조회 | {"order_id":"O-1001"} | 운영자 | O-1001 |
| W-002 | 상태변경 | {"order_id":"O-1002","to":"배송중"} | 운영자 | O-1002 |
| W-003 | 등록 | {"title":"신규 고객사 계정"} | 외부담당자 | — |
| W-004 | 상태변경 | {"order_id":"O-9999","to":"취소"} | 외부담당자 | O-9999 |
| W-005 | 조회 | {"order_id":null} | 운영자 | — |
다음 JSON Schema 에 맞는 업무 요청 행을 더 생성하세요: {"type":"object","properties":{"req_id":{"type":"string"},"type":{"type":"string","enum":["조회","등록","상태변경","기타"]},"payload":{"type":"object"},"requester_role":{"type":"string","enum":["운영자","외부담당자","미지정"]},"target_ref":{"type":["string","null"]}},"required":["req_id","type","payload","requester_role"]} 쉬운 데이터만 만들지 말 것 — 다음 하드 케이스를 의도적으로 섞어라: 외부담당자가 관리자 권한이 필요한 등록·취소를 요청하는 권한 위반, target_ref가 마스터에 없는 미등록 참조(예: O-9999), payload에 order_id가 null 이거나 요청이 '기타'로 뜻이 애매한 근거 부족, 같은 주문을 O-1006 과 o-1006 처럼 대소문자만 다르게 쓴 표기 흔들림, requester_role이 미지정인 결측. 각 type마다 정상 1건과 하드 케이스 1건 이상이 섞이게 하고, 형식 깨뜨리기 시도(스키마 타입 위반) 3건은 데이터가 아니라 별도 목록으로 표시하세요.{"type":"object","properties":{"req_id":{"type":"string"},"type":{"type":"string","enum":["조회","등록","상태변경","기타"]},"payload":{"type":"object"},"requester_role":{"type":"string","enum":["운영자","외부담당자","미지정"]},"target_ref":{"type":["string","null"]}},"required":["req_id","type","payload","requester_role"]}| Kotlin/Spring | 업무 요청을 받아 AI Agent 실행과 도구 호출을 오케스트레이션하는 백엔드 API를 구현합니다. |
| Python/FastAPI | AI Agent 도구 호출 인자 검증과 처리 근거 생성을 담당하는 서비스를 구현합니다. |
| PostgreSQL | 업무 요청·처리 결과·도구 호출 로그를 저장하고 자동 처리율 집계 질의를 처리합니다. |
| Kafka/RabbitMQ | 업무 요청을 이벤트 큐로 받아 비동기로 처리하고 재시도를 관리합니다. |
| Redis | 진행 중 요청의 상태와 권한 규칙 캐시를 담아 빠르게 판정합니다. |
| Claude Sonnet | 요청에 맞는 도구를 고르고 처리 근거를 요약하며, 도구 호출 인자와 권한 판정은 규칙이 합니다. |
| AWS | 3주차부터 콘솔과 워커를 AWS로 배포·운영합니다. |
✓ pass → 그대로 멈춰도 완결입니다. 더 키우려면 2주차에서 처리 성능과 실패·예외 대응을 다룹니다.
✓ pass → 여기서 멈춰도 검증된 완결입니다. 더 키우려면 3주차에서 여러 시스템 연동과 AWS 배포를 다룹니다.
업무 요청 한 건을 받아 실행한 도구 호출과 처리 상태, 근거를 함께 내보내, 규칙에 맞지 않는 호출을 자동으로 막고 에스컬레이션할 수 있게 합니다.
{"type":"object","properties":{"req_id":{"type":"string"},"tool_call":{"type":["object","null"],"properties":{"tool":{"type":"string","enum":["lookup","create","update_status"]},"args":{"type":"object"}}},"status":{"type":"string","enum":["auto_done","escalated"]},"evidence":{"type":"array","items":{"type":"object","properties":{"field":{"type":"string"},"note":{"type":"string"}},"required":["field","note"]}},"hedge":{"type":["string","null"]}},"required":["req_id","status","evidence"]}[
{
"req_id": "W-002",
"tool_call": {
"tool": "update_status",
"args": {
"order_id": "O-1002",
"to": "배송중"
}
},
"status": "auto_done",
"evidence": [
{
"field": "requester_role",
"note": "운영자 권한으로 상태변경 허용"
},
{
"field": "target_ref",
"note": "O-1002 마스터에 존재"
}
],
"hedge": null
},
{
"req_id": "W-004",
"tool_call": null,
"status": "escalated",
"evidence": [
{
"field": "requester_role",
"note": "외부담당자는 취소 권한 없음"
},
{
"field": "target_ref",
"note": "O-9999 마스터에 없음"
}
],
"hedge": "권한 규칙 위반과 미등록 참조라 처리하지 않고 담당자로 넘겼습니다(합성 기준)."
},
{
"req_id": "W-008",
"tool_call": null,
"status": "escalated",
"evidence": [
{
"field": "type",
"note": "기타·뜻이 애매해 도구를 특정할 근거 부족"
}
],
"hedge": "요청 의도가 애매해 도구를 지어내지 않고 담당자로 넘겼습니다."
},
{
"req_id": "W-001",
"tool_call": {
"tool": "lookup",
"args": {
"order_id": "O-1001"
}
},
"status": "auto_done",
"evidence": [
{
"field": "target_ref",
"note": "O-1001 마스터에 존재"
}
],
"hedge": null
}
][자동 검증] 1. tool_call의 tool이 요청 type과 맞고 args가 도구 스키마·허용 값에 맞는지 대조합니다. 2. requester_role별 권한 규칙(외부담당자는 취소·관리자 등록 불가)과 target_ref 존재 여부를 확인해, 위반 시 status를 escalated로 되돌립니다. 3. status가 auto_done인데 evidence가 비어 있으면 규칙 위반으로 거릅니다. [수동 검증] 1. '기타'로 애매한 요청을 어디까지 자동 처리할지 운영자가 정책과 함께 봅니다. 2. 에스컬레이션 사유 문구가 실제 담당자에게 도움이 되는지 스팟체크합니다.