빌드[AI/솔루션] Product Engineer/(백엔드 or 프론트엔드 5년 이상)
4.5 (12)빌드잇
경력근거: 통합 테스트 및 검증 과정에서 발생한 이슈 분석 및 해결
어제 확인채용 공고 보기
※ 실제 산출물이 아닌 AI 예측 시안입니다.
빌드잇은 AI 중심 소프트웨어 기업으로 전환하며 AI Agent 기반 프로세스 자동화 솔루션을 제품화하고, 백엔드(Kotlin·Python·FastAPI)와 프론트(React·Next)를 아우르는 주니어 풀스택 프로덕트 엔지니어를 찾습니다. Agent 스텝 실행 결과를 규칙으로 검사해 깨진 스텝을 막는 이 풀스택 게이트는 그 핵심(AI Agent 자동화 제품화 + 풀스택 구현) 기술을 정면으로 보여줍니다. 특정 엔터프라이즈 도메인 노하우는 포트폴리오로 증명되지 않으므로 주장하지 않습니다. 스텝 신호를 검사 규칙·차단 가드로 잇는 사슬은 단순 Agent 호출 맥락으로는 그대로 만들 수 없습니다.
AI Agent 기반 프로세스 자동화 솔루션을 제품화합니다. 실행 게이트가 직접 정렬됩니다.
백엔드(Kotlin·Spring·Python·FastAPI)와 프론트(React·Next)를 아우르는 풀스택 프로덕트 엔지니어입니다. 게이트 API·화면이 풀스택과 정렬됩니다.
엔터프라이즈 솔루션을 AI 중심으로 제품화하는 전환기에 있습니다. 워크플로우별 실패율 집계가 제품화와 정렬됩니다.
AI Agent 워크플로우 스텝의 실행 결과(출력·도구 호출·신뢰도·스키마 통과)를 받아, 규칙(스키마 위반·근거 없음·도구 실패·저신뢰·결측)으로 성공으로 넘길지 검토로 둘지 실패로 막을지 정합니다. 정답 여부는 출력 스키마 통과와 도구 호출 성공으로 결정하고, LLM 은 스텝 출력 생성·실패 사유 설명 보조만 맡습니다. 자동화 결과의 사업적 옳고 그름이 아니라 스텝 진행 가능 여부의 객관 게이트입니다.
빌드잇 주니어 풀스택 프로덕트 엔지니어입니다. AI Agent 자동화가 중간 스텝에서 이상한 출력을 내도 그대로 흘러가던 것을, 한 게이트에서 스텝 실행 결과·판정·실패 사유를 함께 보고 막고 싶은 사람입니다.
스텝 실행 결과를 한 스키마로 묶으면, (a) 스키마 위반·근거 없음·도구 실패를 규칙으로 막고, (b) 실패 사유를 실행 로그 인용으로 풀며, (c) 여러 워크플로우의 스텝을 끊김 없이 검사하고 차단합니다.
스텝 실행 결과를 받아 규칙으로 성공·검토·실패를 정하고 깨진 스텝을 막는 동작하는 게이트(API+화면)입니다. 실행 로그는 Agent 워크플로우를 가정한 더미로 시작합니다.
게이트 판정을 심은 정답·검토자 2명 라벨과 비교해 정밀도·재현율과 일치도를 보여주는 화면입니다.
워크플로우·스텝 타입별 실패율과 차단 사유 분포를 누적 집계해 약한 스텝을 보여주는 화면입니다.
검사 시나리오 12종(정상·스키마 위반·도구 실패)을 넣으면, 성공·검토·실패 결과가 몇 초 안에 나오는 걸 시연합니다
일부러 만든 악성·결측 입력 30종(신뢰도 null·미등록 스텝 타입·워크플로우 표기 흔들림)을 넣어도 출력 형식(스키마)이 한 번도 안 깨집니다
더미에 심은 정답 40건 중 성공/실패 판정이 일치한 게 35건(약 88%)입니다. 단, 정답·데이터를 모두 작성자가 만든 합성 기준이라 '성능 검증'이 아니라 '데모 조건에서의 동작'임을 명시합니다
진짜 성능 검증은 여기서 멈춥니다. 위 수치는 전부 작성자가 만든 더미데이터 자가채점이며, 실제 정밀도·재현율은 빌드잇의 실 Agent 로그와 실 검토자가 있어야 측정 가능합니다. 이 게이트는 그 검증을 바로 돌릴 수 있는 상태로 만듭니다
수치는 합성 데이터 자가채점이라 성능 증명이 아닙니다. 면접에서는 데모 동작과 실연동 준비 상태로 솔직히 설명합니다
이 포트폴리오가 보여주는 것은 풀스택 게이트(FastAPI+React) + 실행 결과 스키마 검증 + 차단 가드 기술입니다. 실제 엔터프라이즈 도메인·특정 산업 자동화 노하우는 포트폴리오로 증명되지 않으므로 주장하지 않으며, 모르는 깊이는 면접에서 솔직히 말하는 편이 낫습니다
정답을 작성자가 만들었으니 잘 맞는 것이 당연합니다. 신뢰도 결측·미등록 스텝 타입·워크플로우 표기 흔들림 같은 경계 케이스를 더미에 일부러 섞어, 쉬운 검사만 통과시키는 게 아님을 보여줍니다
스텝의 사업적 옳고 그름은 규칙만으로 단정할 수 없습니다. 이 게이트는 '좋은 결과인가'가 아니라 출력 스키마가 맞는지·도구 호출이 성공했는지 같은 진행 가능 여부만 보고, 애매하면 차단 대신 검토로 돌립니다
워크플로우·스텝 표기가 제각각입니다. 정규화로 같은 타입으로 묶고, 못 묶은 건 추측하지 말고 '미매핑'으로 알립니다. 실제 도입 시 스텝·도구 정의가 더미와 다르므로 규칙을 다시 맞춰야 합니다(도입 단계 과제로 분리)
① 인라인 샘플 · ② seed.json 다운로드 · ③ 증강 프롬프트. 세 층 모두 동일한 schema 에서 파생.
AI Agent 스텝 실행 검사 로그. 검사 규칙이 가장 먼저 질의하는 테이블입니다. 신뢰도 결측·미등록 스텝 타입·워크플로우 표기 흔들림을 일부러 섞고, label 로 정답을 심어 자가채점합니다.
| step_id | wf_raw | wf_id | step_type | schema_ok | tool_ok | grounded | confidence | label | ts |
|---|---|---|---|---|---|---|---|---|---|
| ag_001 | 송장처리 | invoice | extract | true | true | true | 0.92 | success | 2026-03-04T09:00 |
| ag_002 | 송장처리 | invoice | extract | false | true | true | 0.8 | fail | 2026-03-04T10:00 |
| ag_003 | 송장처리 | invoice | tool_call | true | false | true | 0.7 | fail | 2026-03-04T11:00 |
| ag_004 | 송 장처리 | invoice | transform | true | true | false | 0.55 | review | 2026-03-04T12:00 |
| ag_005 | 신규워크플로우X | — | extract | true | true | true | 0.85 | review | 2026-03-04T13:00 |
아래 Zod 스키마에 맞는 Agent 스텝 60행 JSON 배열로 생성합니다. 워크플로우 2~3개, 스텝 타입 3종, 정상 위주에 검토·실패를 섞습니다. label 규칙: schema_ok=false 또는 tool_ok=false → fail, grounded=false 또는 wf_id=null 또는 confidence=null → review, 그 외(스키마·도구·근거 정상 & 고신뢰) → success.
{"type":"object","properties":{"step_id":{"type":"string"},"wf_raw":{"type":"string"},"wf_id":{"type":["string","null"]},"step_type":{"type":"string","enum":["extract","transform","tool_call"]},"schema_ok":{"type":"boolean"},"tool_ok":{"type":"boolean"},"grounded":{"type":"boolean"},"confidence":{"type":["number","null"]},"label":{"type":"string","enum":["success","review","fail"]},"ts":{"type":"string"}},"required":["step_id","wf_raw","wf_id","step_type","schema_ok","tool_ok","grounded","confidence","label","ts"]}
쉬운 데이터만 만들지 말 것. 다음 하드 케이스를 의도적으로 섞어라(쉬운 검사만 통과시키는 함정 회피): (1) 같은 워크플로우의 표기 별칭('송장처리'/'송 장처리', '채널관리'/'채 널관리'처럼 wf_master 로 정규화돼야 함) 3건 이상, (2) 미등록 워크플로우(wf_id=null) 2건, (3) 결측: confidence 가 null 인 행 1~2건, (4) 경계값 — 스키마 위반(schema_ok=false)·도구 실패(tool_ok=false) 각 2건, (5) 근거 없는(grounded=false) 검토 케이스 2~3건. label 은 위 규칙대로 정직하게. JSON 배열만.{"type":"object","properties":{"step_id":{"type":"string"},"wf_raw":{"type":"string"},"wf_id":{"type":["string","null"]},"step_type":{"type":"string","enum":["extract","transform","tool_call"]},"schema_ok":{"type":"boolean"},"tool_ok":{"type":"boolean"},"grounded":{"type":"boolean"},"confidence":{"type":["number","null"]},"label":{"type":"string","enum":["success","review","fail"]},"ts":{"type":"string"}},"required":["step_id","wf_raw","wf_id","step_type","schema_ok","tool_ok","grounded","confidence","label","ts"]}| Python | 스텝 실행 결과 파서·검사 규칙(FastAPI 백엔드)의 구현 언어입니다 |
| FastAPI | 게이트를 워크플로우에 붙이는 검사 API 입니다 |
| TypeScript | 게이트 화면·출력 스키마(Zod)의 구현 언어입니다 |
| React | 워크플로우·스텝 그리드와 실행 카드·차단 사유를 렌더하는 프레임워크입니다 |
| Next.js | 게이트 대시보드의 풀스택 프레임워크입니다 |
| Zod | 스텝 실행 결과와 게이트 출력의 런타임 형식 검증입니다 |
| Claude | 스텝 출력 생성·실패 사유 설명 보조 LLM(판정은 규칙)입니다 |
✓ pass → 그대로 멈춰도 완결입니다. 더 키우려면 2주차(판정이 맞았는지 확인)로 진행합니다.
✓ pass → 여기서 멈춰도 완결입니다. 더 키우면 3주차(워크플로우별 실패율 추이)로 진행합니다.
스텝 실행 1건의 게이트 카드. 결정·요인·근거를 한 스키마로 담아 화면 카드에 씁니다. 결과 사업성이 아니라 스텝 진행 가능 여부 게이트입니다.
{"type":"object","properties":{"step_id":{"type":"string"},"wf_id":{"type":["string","null"]},"decision":{"type":"string","enum":["success","review","fail"]},"factors":{"type":"array","items":{"type":"string","enum":["schema_violation","tool_failure","ungrounded","low_confidence","unmapped_workflow","missing_metric"]}},"reason":{"type":"string","minLength":20},"evidence":{"type":"string","minLength":8},"hedge":{"type":["string","null"]}},"required":["step_id","wf_id","decision","factors","reason","evidence","hedge"]}[
{
"input_ref": "ag_002 (출력 스키마 위반)",
"output": {
"step_id": "ag_002",
"wf_id": "invoice",
"decision": "fail",
"factors": [
"schema_violation"
],
"reason": "스텝 출력이 다음 스텝이 기대하는 스키마를 위반해 그대로 넘기면 자동화가 깨집니다. 다음 단계로 진행하지 않고 실패로 막습니다.",
"evidence": "schema_ok=false",
"hedge": "출력 형식이 깨져 진행을 막습니다"
}
},
{
"input_ref": "ag_003 (도구 호출 실패)",
"output": {
"step_id": "ag_003",
"wf_id": "invoice",
"decision": "fail",
"factors": [
"tool_failure"
],
"reason": "도구 호출이 실패해 스텝 결과를 신뢰할 수 없습니다. 다음 스텝으로 넘기지 않고 실패로 막습니다.",
"evidence": "tool_ok=false",
"hedge": "도구 호출 실패라 진행을 막습니다"
}
},
{
"input_ref": "ag_004 (근거 없음 + 저신뢰)",
"output": {
"step_id": "ag_004",
"wf_id": "invoice",
"decision": "review",
"factors": [
"ungrounded",
"low_confidence"
],
"reason": "스키마·도구는 정상이나 출력 근거가 없고 신뢰도가 낮아 자동 성공을 단정하지 않습니다. 차단까지는 아니라 검토로 돌립니다.",
"evidence": "grounded=false, confidence=0.55",
"hedge": "근거가 약해 검토가 필요합니다"
}
}
][자동 검증] 1. Zod parse 로 출력 형식(필드·enum)이 스키마를 통과하는지 확인합니다. 2. decision 이 검사 규칙(스키마위반/도구실패→fail·근거없음/미등록/결측→review·통과→success)과 일치하는지 봅니다. 3. evidence 가 입력 실행 로그의 실제 값 인용인지 토큰 매칭으로 확인합니다. 4. decision 을 심은 정답 label 과 비교해 정밀도·재현율을 계산합니다. [수동 검증] 1. 검토자 2명이 비동기로 게이트 판정을 라벨링해 정밀도·재현율과 bootstrap Cohen's κ(두 사람 일치가 우연 이상인 정도, 0~1) 하한 0.6 이상을 봅니다. 2. 전체의 5% 를 사람이 직접 점검합니다.