빌드잇
경력근거: 요구사항 정의부터 운영 개선까지 담당 제품/영역을 end-to-end로 책임지며
빌드잇은 Enterprise Business와 AI Agent Business를 두 축으로 세우고 AI Agent 기반 프로세스 자동화 솔루션을 제품화하는 중이며, Senior Product Engineer에게는 요구사항 정의부터 운영 개선까지 담당 제품을 end-to-end로 책임지라고 적었습니다. 화면과 REST API와 실행 규칙을 한 사람이 붙여 하나의 흐름으로 완결하는 이 포트폴리오가 그 요구와 같은 모양입니다. 다만 이 포트폴리오가 보여주는 것은 도구 호출 계획을 규칙으로 검증하고 사람 승인을 실행 게이트로 세우는 풀스택 구현 기술이며, 고객사 업무 도메인 전문성은 주장하지 않습니다. 모르는 깊이는 면접에서 모른다고 말하는 편이 낫습니다.
빌드잇이 성장 축으로 세운 AI Agent 기반 프로세스 자동화를, 담당자가 실행 전에 계획을 확인하고 고치는 제품 화면 하나로 구현합니다.
요구사항 정의부터 운영 개선까지 담당 제품을 end-to-end로 책임지는 자리라, 화면과 API와 실행 규칙을 한 사람이 붙여 하나의 흐름으로 끝냅니다.
한 영역에 강점을 두고 반대 영역도 실전으로 다루라는 요구에 맞춰, React 화면과 REST API를 같은 흐름 안에서 설계하고 붙입니다.
빌드잇이 성장 축으로 세운 AI Agent 기반 프로세스 자동화를, 운영 담당자가 매일 여는 제품 화면 하나로 구현합니다. 업무 요청이 들어오면 에이전트가 부를 도구와 인자를 계획으로 내고, 스키마·권한·참조 규칙을 모두 통과한 계획만 그대로 실행됩니다. 규칙에 걸린 계획은 보류 큐에 쌓이고, 담당자가 화면에서 어긋난 인자를 고치거나 다른 도구로 바꿔 승인해야 실행이 나갑니다. 반려하면 사유가 요청에 남고 다음 판정의 재료가 됩니다.
빌드잇이 만든 업무 자동화 제품을 매일 쓰는 운영 담당자로, 같은 유형의 요청을 손으로 조회하고 상태를 바꾸는 일에 지쳤지만 에이전트가 주문 상태를 제멋대로 바꾸는 것도 불안해, 확실한 건은 알아서 끝나고 애매한 건만 자기 화면에 모여 직접 고칠 수 있기를 바라는 사람입니다.
에이전트가 낸 도구 호출 계획을 스키마·권한·참조 규칙으로 먼저 검증하고 걸린 계획만 담당자 화면에 모아 인자 수정과 승인을 받으면, 반복 요청은 자동으로 끝나면서도 잘못된 실행은 사람 손 앞에서 멈춘다는 가정입니다.
업무 요청을 넣으면 에이전트가 도구와 인자를 계획으로 내고, 스키마·권한·참조 규칙을 통과한 계획은 그대로 실행되며, 걸린 계획은 보류 큐 화면에 쌓입니다. 담당자는 요청 상세에서 어긋난 인자를 고치거나 다른 도구로 바꿔 승인하고, 승인한 계획만 실행되어 결과와 판정 근거가 그 자리에 남습니다. 반려하면 사유를 골라 요청을 닫습니다. 여기까지가 혼자 돌려볼 수 있는 완결품입니다.
담당자가 고친 인자와 반려 사유를 유형별로 모아 자주 걸리는 패턴을 규칙에 반영하고, 반영 전후로 같은 유형의 보류가 얼마나 줄었는지 비교합니다. 접수부터 실행까지 걸린 시간과 자동 실행 비율을 화면 상단에 함께 올립니다.
승인된 도구 호출을 이벤트 큐로 넘겨 비동기로 실행하고 실패 건을 유형별로 재시도하며, 화면과 API와 워커를 AWS로 배포해 요청이 몰릴 때 실행 지연이 어떻게 늘어나는지 측정합니다.
권한 위반·미등록 참조·표기 흔들림을 섞은 요청을 넣으면 걸린 계획이 실행되지 않고 보류 큐에 뜨며, 담당자가 인자를 고쳐 승인한 뒤에야 실행되는 과정을 처음부터 끝까지 시연합니다.
일부러 만든 하드 케이스 30종을 넣어도 화면이 멈추지 않고, 스키마를 깨뜨리는 인자 수정은 제출 단계에서 막히는 강건성을 보여줍니다.
2주차부터 자동 실행 비율과 접수부터 실행까지 걸린 시간 두 가지를 재고 규칙 반영 전후로 비교하며, 정답과 더미는 작성자가 만든 합성 기준이라 성능 검증이 아니라 데모 조건 동작입니다.
진짜 성능 검증은 여기서 멈춥니다. 위 수치는 더미데이터 자가채점이며 실제 자동 실행 비율과 오처리율은 빌드잇의 실 업무 요청과 실 담당자가 있어야 측정 가능합니다. 이 포트폴리오는 그 검증을 바로 돌릴 수 있는 상태로 만듭니다.
수치는 합성 데이터 자가채점이라 성능 증명이 아니므로, 면접에서는 데모 동작과 실검증 준비 상태로 솔직히 설명합니다.
정답을 작성자가 만들었으니 잘 맞는 게 당연하므로, 권한 위반·미등록 참조·표기 흔들림 같은 경계 케이스를 더미에 일부러 섞어 쉬운 문제만 푸는 함정을 피합니다.
이 포트폴리오가 보여주는 것은 도구 호출 계획을 규칙으로 검증하고 사람 승인을 실행 게이트로 세우는 풀스택 구현 기술이며, 고객사 업무 도메인 전문성은 주장하지 않습니다. 실행 가능 여부는 도구 스키마·권한 규칙·상태 전이 규칙으로 채점하고 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 가 order_master 에 없는 미등록 참조(예: 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"]}도구 호출 인자가 가리키는 주문의 실체로, 참조가 실제로 있는지와 요청한 상태 전이가 가능한지를 규칙으로 대조하는 기준표입니다. 담당자가 보류 건의 인자를 고칠 때 고를 수 있는 값의 목록이기도 합니다.
| order_id | customer | status | owner_team | updated_at |
|---|---|---|---|---|
| O-1001 | 한빛물산 | 접수 | CS1팀 | 2026-07-28 |
| O-1002 | 대성전기 | 결제완료 | CS1팀 | 2026-07-29 |
| O-1003 | 삼우기업 | 배송중 | CS2팀 | 2026-07-30 |
| O-1004 | 누리테크 | 완료 | CS2팀 | 2026-07-25 |
| O-1005 | 정민상사 | 결제완료 | CS1팀 | 2026-07-31 |
다음 JSON Schema 에 맞는 주문 마스터 행을 더 생성하세요: {"type":"object","properties":{"order_id":{"type":"string"},"customer":{"type":"string"},"status":{"type":"string","enum":["접수","결제완료","배송중","완료","취소"]},"owner_team":{"type":"string"},"updated_at":{"type":"string"}},"required":["order_id","customer","status","owner_team"]} 쉬운 데이터만 만들지 말 것 — 상태 전이 규칙(접수→결제완료→배송중→완료, 취소는 접수·결제완료에서만 가능, 완료·취소는 끝 상태)을 검증할 수 있도록 끝 상태인 완료·취소 주문을 전체의 3할 이상 섞고, 담당팀이 서로 다른 주문을 고르게 배치하며, 업무 요청 쪽에서 참조로 쓰일 수 없는 order_id 대역(O-9xxx)은 만들지 마세요.{"type":"object","properties":{"order_id":{"type":"string"},"customer":{"type":"string"},"status":{"type":"string","enum":["접수","결제완료","배송중","완료","취소"]},"owner_team":{"type":"string"},"updated_at":{"type":"string"}},"required":["order_id","customer","status","owner_team"]}| TypeScript/React/Next.js | 보류 큐 목록과 요청 상세, 인자 수정·승인·반려 폼으로 이뤄진 제품 화면을 구현합니다. |
| Zustand | 담당자가 화면에서 고친 인자와 승인 대기 상태를 화면 단위로 들고 있다가 제출 시점에 한 번에 넘깁니다. |
| Zod | 담당자가 고친 인자를 보내기 전에 브라우저에서 도구 스키마로 검증해, 형식이 깨진 값이 API로 넘어가지 않게 막습니다. |
| Tailwind CSS | 보류 사유 배지와 원래 인자·고친 인자 대비 표시, 승인 버튼의 상태를 스타일링합니다. |
| Kotlin/Spring | 요청 접수와 도구 호출 실행, 승인·반려 상태 전이를 다루는 REST API를 설계하고 구현합니다. |
| Python/FastAPI | 에이전트가 도구와 인자를 고르는 추론 서비스를 맡고, 서버에서 스키마·권한·참조 규칙을 다시 검증합니다. |
| PostgreSQL | 요청과 도구 호출 계획, 담당자 수정 이력, 승인 결과를 저장하고 자동 실행 비율 집계 질의를 처리합니다. |
| Redis | 진행 중 요청 상태와 권한 규칙 캐시를 담아 보류 큐 목록의 응답 시간을 줄입니다. |
| Kafka/RabbitMQ | 3주차부터 승인된 도구 호출을 이벤트 큐로 넘겨 비동기로 실행하고 재시도를 관리합니다. |
| Claude Sonnet | 요청에 맞는 도구와 인자 초안을 고르고 담당자에게 보일 요약을 씁니다. 실행 가능 여부 판정은 규칙이 합니다. |
| AWS | 3주차부터 화면과 API와 워커를 AWS로 배포하고 운영합니다. |
✓ pass → 그대로 멈춰도 완결입니다. 더 키우려면 2주차에서 담당자 수정과 반려 사유를 규칙으로 되먹이는 일을 다룹니다.
✓ pass → 여기서 멈춰도 검증된 완결입니다. 더 키우려면 3주차에서 이벤트 큐 비동기 실행과 AWS 배포를 다룹니다.
업무 요청 한 건에 대해 에이전트가 낸 도구 호출 계획과 규칙 가드의 판정, 담당자가 화면에서 한 수정·승인·반려, 실제 실행 여부를 한 레코드로 남겨, 사람 승인 없이 실행된 건이 있는지 나중에 되짚을 수 있게 합니다.
{"type":"object","properties":{"req_id":{"type":"string"},"agent_plan":{"type":["object","null"],"properties":{"tool":{"type":"string","enum":["lookup","create","update_status"]},"args":{"type":"object"}}},"guard":{"type":"object","properties":{"verdict":{"type":"string","enum":["auto_run","hold"]},"reasons":{"type":"array","items":{"type":"string"}}},"required":["verdict","reasons"]},"reviewer":{"type":["object","null"],"properties":{"action":{"type":"string","enum":["approve","edit_approve","reject"]},"edited_args":{"type":["object","null"]},"note":{"type":"string"}}},"executed":{"type":"boolean"},"evidence":{"type":"array","items":{"type":"object","properties":{"field":{"type":"string"},"note":{"type":"string"}},"required":["field","note"]}},"hedge":{"type":["string","null"]}},"required":["req_id","guard","executed","evidence"]}[
{
"req_id": "W-002",
"agent_plan": {
"tool": "update_status",
"args": {
"order_id": "O-1002",
"to": "배송중"
}
},
"guard": {
"verdict": "auto_run",
"reasons": []
},
"reviewer": null,
"executed": true,
"evidence": [
{
"field": "requester_role",
"note": "운영자 권한으로 상태변경 허용"
},
{
"field": "target_ref",
"note": "O-1002 는 order_master 에 있고 결제완료에서 배송중으로 전이 가능"
}
],
"hedge": null
},
{
"req_id": "W-012",
"agent_plan": {
"tool": "lookup",
"args": {
"order_id": "o-1006"
}
},
"guard": {
"verdict": "hold",
"reasons": [
"order_id 표기가 마스터와 달라 참조 대조 실패"
]
},
"reviewer": {
"action": "edit_approve",
"edited_args": {
"order_id": "O-1006"
},
"note": "담당자가 화면에서 대문자 표기로 고쳐 승인했습니다."
},
"executed": true,
"evidence": [
{
"field": "args.order_id",
"note": "o-1006 을 O-1006 으로 수정한 뒤 마스터에서 확인"
}
],
"hedge": null
},
{
"req_id": "W-004",
"agent_plan": {
"tool": "update_status",
"args": {
"order_id": "O-9999",
"to": "취소"
}
},
"guard": {
"verdict": "hold",
"reasons": [
"외부담당자는 취소 권한 없음",
"O-9999 가 order_master 에 없음"
]
},
"reviewer": {
"action": "reject",
"edited_args": null,
"note": "존재하지 않는 주문이라 요청자에게 주문번호 확인을 요청하며 반려했습니다."
},
"executed": false,
"evidence": [
{
"field": "requester_role",
"note": "외부담당자 권한 밖 요청"
},
{
"field": "target_ref",
"note": "O-9999 는 마스터에 없음"
}
],
"hedge": "권한 규칙과 참조 대조에 함께 걸려 실행하지 않고 담당자 판단으로 닫았습니다(합성 기준)."
},
{
"req_id": "W-008",
"agent_plan": null,
"guard": {
"verdict": "hold",
"reasons": [
"요청 뜻이 애매해 부를 도구를 특정할 근거 부족"
]
},
"reviewer": null,
"executed": false,
"evidence": [
{
"field": "type",
"note": "기타로 들어와 도구를 특정할 수 없음"
}
],
"hedge": "도구를 지어내지 않고 보류 큐에 담당자 확인 대기로 남겼습니다."
}
][자동 검증] 1. agent_plan 의 tool 이 요청 type 과 맞고 args 가 도구 스키마·허용 값에 맞는지 대조합니다. 2. requester_role 별 권한 규칙(외부담당자는 취소·관리자 등록 불가)과 order_master 의 참조 존재 여부, 상태 전이 가능 여부를 확인해 하나라도 어긋나면 verdict 를 hold 로 둡니다. 3. executed 가 true 인데 guard.verdict 가 hold 이고 reviewer 가 null 이면 사람 승인 없이 실행된 것이므로 규칙 위반으로 거릅니다. 4. reviewer.action 이 edit_approve 인데 edited_args 가 비어 있거나 도구 스키마를 어기면 제출 단계에서 막습니다. [수동 검증] 1. 기타로 들어온 애매한 요청을 어디까지 자동 실행 대상으로 볼지 담당자가 정책과 함께 봅니다. 2. 보류 사유 문구가 화면에서 담당자에게 무엇을 고치라는 뜻으로 읽히는지 스팟체크합니다.