베스[베스핀글로벌] LLM 엔지니어
2.8 (540)베스핀글로벌
경력근거: Agent Loop Prompt Engineering 구성
어제 확인채용 공고 보기
※ 실제 산출물이 아닌 AI 예측 시안입니다.
베스핀글로벌은 고객사 AX를 자사 솔루션으로 구현하는 조직이고, 이 포지션에 에이전트 루프 구성을 맡깁니다. 고객사마다 어디까지 자동으로 진행하고 어디서 사람에게 물을지가 다르므로 정책이 코드가 아니라 파일로 관리돼야 하고, 이 도구는 그 정책을 판정 기준으로 그대로 씁니다. 공고 업무는 프런트와 백엔드 구현부터 온프레미스 운영 체계까지 걸쳐 있는데 1주 범위에서 루프 점검 축을 골랐습니다. 이 포트폴리오는 실행 기록을 상태 규칙으로 판정하는 기술을 보여줍니다. 파인튜닝이나 트랜스포머 아키텍처의 깊이는 주장하지 않습니다. 모르는 깊이는 면접에서 모른다고 말하는 편이 낫습니다.
주요 업무에 LLM Workflow와 Agent Loop 구성이 들어 있습니다. 루프를 짜면 반드시 따라오는 것이 언제 멈추고 언제 사람에게 물을지의 규칙이고, 그 규칙을 지켰는지 보는 것이 이 도구입니다.
클라우드와 온프레미스를 모두 아우르는 시스템 구성과 운영 체계 수립이 업무입니다. 운영으로 넘기려면 실행 기록을 규칙으로 판정하는 절차가 있어야 합니다.
자사 솔루션으로 고객사의 AI 전환을 실현하는 조직이라고 회사 소개에 적혀 있습니다. 고객사마다 확인 절차와 허용 반복이 달라, 정책을 파일로 받아 판정하는 형태가 맞습니다.
에이전트가 남긴 단계별 실행 기록을 고객사 루프 정책과 대조해, 재시도를 넘긴 실행과 확인 단계를 건너뛴 실행을 나눠 보여주는 점검 CLI입니다. 판정은 정책 규칙으로 정합니다.
고객사에 에이전트를 붙이는 담당자입니다. 프롬프트를 한 번 고칠 때마다 실행 수십 건을 다시 돌려 보는데, 어느 실행이 같은 도구를 반복해 돌다 멈췄고 어느 실행이 사람 확인을 건너뛰었는지를 로그를 스크롤해 찾습니다.
루프 정책에 도구별 허용 반복과 확인 필요 여부가 적혀 있으면, 어느 실행이 규칙을 벗어났는지는 사람이 로그를 읽지 않아도 대조로 갈라집니다.
실행 기록과 정책 파일을 인자로 받아 사유별 판정표를 출력하고 인계용 리포트를 떨구는 CLI입니다. 에이전트를 실제로 돌리지 않고 이미 남은 기록만 읽습니다.
두 실행 묶음을 함께 받아 새로 어긋난 실행과 고쳐진 실행을 가려내는 비교기입니다.
도구 사전과 허용 반복 값을 고객사별 파일로 분리해 같은 판정을 여러 정책으로 돌리는 구성입니다.
실행 기록 20건과 정책을 넣어 사유별 판정표와 인계용 리포트가 나오는 것을 시연합니다.
결측·중복·미등록 도구 표기가 섞인 입력 30종을 넣어도 출력 형식이 깨지지 않고, 판정하지 못한 실행은 사유가 붙어 남습니다.
정책에 없는 도구를 쓴 실행은 정상으로 세지 않고 미매핑으로 따로 답니다. 모르는 도구를 통과시키지 않습니다.
판정과 손으로 만든 정답표를 맞춰 사유별로 어긋난 건을 셉니다. 단, 기록과 정답을 모두 작성자가 만든 합성 기준이라 성능 측정이 아니라 데모 조건 동작입니다.
진짜 성능 검증은 여기서 멈춥니다. 위 수치는 더미데이터 자가채점이며, 실제 판정 정확도는 베스핀글로벌이 고객사에 붙인 실제 에이전트 기록과 실제 승인 정책이 있어야 측정됩니다. 이 포트폴리오는 그 검증을 바로 돌릴 수 있는 상태까지 만듭니다.
수치는 합성 데이터 자가채점이라 성능 증명이 아닙니다. 면접에서는 데모 동작과 실검증 준비 상태로 솔직히 설명합니다.
정답을 작성자가 만들었으니 잘 맞는 것이 당연합니다. 결측·중복·미등록 도구 표기를 더미에 일부러 섞어 쉬운 문제만 푸는 것을 피합니다.
규칙을 지켰다고 해서 에이전트가 옳은 답을 냈다고 단정할 수 없습니다. 이 도구는 절차를 볼 뿐 결과의 품질은 보지 않으므로, 답변 정확도는 따로 평가해야 합니다.
실제 도입하면 고객사마다 확인 단계와 허용 반복이 다릅니다. 정책을 고객과 합의해 채우는 일이 도입 단계의 실제 과제입니다.
실행 기록의 형식은 에이전트 구현에 따라 다릅니다. 형식이 바뀌면 어댑터를 새로 써야 하고, 그 부분은 재사용되지 않습니다.
① 인라인 샘플 · ② seed.json 다운로드 · ③ 증강 프롬프트. 세 층 모두 동일한 schema 에서 파생.
고객사 에이전트가 남긴 단계별 실행 기록입니다. 어떤 도구를 몇 번 불렀고 어떻게 끝났는지가 남습니다. 결측과 중복, 정책에 없는 도구 표기를 일부러 섞었습니다.
| run_no | step_seq | tool_raw | action_type | retry_count | ended_reason |
|---|---|---|---|---|---|
| RUN-001 | 1 | search_docs | call | 0 | — |
| RUN-001 | 2 | send_mail | confirm | 0 | — |
| RUN-001 | 3 | send_mail | finish | 0 | completed |
| RUN-002 | 1 | search_docs | call | 0 | — |
| RUN-002 | 2 | search_docs | retry | 4 | — |
아래 JSON Schema에 맞는 에이전트 실행 단계를 더 만들어 주세요. {"type":"object","properties":{"run_no":{"type":"string"},"step_seq":{"type":"integer"},"tool_raw":{"type":"string"},"action_type":{"type":"string","enum":["call","retry","confirm","finish"]},"retry_count":{"type":"integer"},"ended_reason":{"type":["string","null"]}},"required":["run_no","step_seq","tool_raw","action_type","retry_count","ended_reason"]} 쉬운 데이터만 만들지 말 것. 다음 하드 케이스를 의도적으로 섞어라. 첫째 결측으로 finish 단계인데 ended_reason이 null인 실행, 둘째 중복으로 같은 run_no와 step_seq가 두 행에 있는 기록, 셋째 미매핑으로 tool_raw가 정책에 없어 tool_id가 null인 행, 넷째 표기흔들림으로 같은 도구를 search_docs와 SearchDocs로 다르게 적은 행, 다섯째 경계극단으로 retry_count가 정책 허용치와 정확히 같은 실행과 하나 넘긴 실행, 여섯째 finish 단계가 아예 없이 끝난 실행. 또한 형식 깨뜨리기 시도 3건을 별도 파일로 만들어 action_type에 enum 밖 값을 넣거나 required 필드를 빼서 스키마 검증이 걸러내는지 확인하게 해 주세요.{"type":"object","properties":{"run_no":{"type":"string"},"step_seq":{"type":"integer"},"tool_raw":{"type":"string"},"action_type":{"type":"string","enum":["call","retry","confirm","finish"]},"retry_count":{"type":"integer"},"ended_reason":{"type":["string","null"]}},"required":["run_no","step_seq","tool_raw","action_type","retry_count","ended_reason"]}고객사가 정한 루프 정책입니다. 도구마다 몇 번까지 다시 시도해도 되는지와 사람 확인이 필요한지가 적혀 있습니다. 판정 기준이 이 표에서만 나옵니다.
| tool_raw | tool_id | max_retries | requires_confirm | risk_level |
|---|---|---|---|---|
| search_docs | search_docs | 2 | false | low |
| SearchDocs | search_docs | 2 | false | low |
| send_mail | send_mail | 1 | true | high |
| SendMail | send_mail | 1 | true | high |
| update_crm | update_crm | 2 | false | medium |
아래 JSON Schema에 맞는 루프 정책 행을 더 만들어 주세요. {"type":"object","properties":{"tool_raw":{"type":"string"},"tool_id":{"type":"string"},"max_retries":{"type":"integer"},"requires_confirm":{"type":"boolean"},"risk_level":{"type":"string","enum":["low","medium","high"]}},"required":["tool_raw","tool_id","max_retries","requires_confirm","risk_level"]} 같은 tool_id에 표기가 다른 별칭을 여러 개 두어 표기흔들림을 재현하고, 위험도가 높은 도구는 확인을 반드시 요구하게 해 주세요. 실행 기록에는 나오지만 정책에는 없는 도구가 남도록 일부 도구는 일부러 등록하지 말아 주세요. 또한 형식 깨뜨리기 시도 3건을 별도 파일로 만들어 max_retries에 문자열을 넣어 스키마 검증이 걸러내는지 확인하게 해 주세요.{"type":"object","properties":{"tool_raw":{"type":"string"},"tool_id":{"type":"string"},"max_retries":{"type":"integer"},"requires_confirm":{"type":"boolean"},"risk_level":{"type":"string","enum":["low","medium","high"]}},"required":["tool_raw","tool_id","max_retries","requires_confirm","risk_level"]}| Python | 실행 기록과 정책을 읽어 판정 규칙을 돌리고 리포트를 만드는 본체입니다. |
| Java | 고객사 백엔드가 남기는 실행 기록 형식을 읽어 들이는 어댑터 쪽에서 씁니다. |
| LLM Workflow | 단계 기록이 어떤 순서로 남는지의 기준이며, 판정 규칙이 그 순서를 그대로 검사합니다. |
| Agent Loop | 허용 반복과 종료 조건이 정책에 적히는 대상이고, 이 도구가 지켰는지 봅니다. |
| On-premise | 정책 파일과 판정기를 고객사 폐쇄망 안에서 그대로 돌릴 수 있게 외부 호출 없이 구성합니다. |
✓ pass → 여기서 멈춰도 완결입니다. 더 키우려면 프롬프트 수정 전후 두 묶음을 비교합니다.
✓ pass → 비교까지가 한 덩어리입니다. 더 키우려면 정책을 고객사별 파일로 분리합니다.
실행 한 건의 판정 결과입니다. 루프가 정책대로 끝났는지, 아니면 무엇을 어겼는지를 근거와 함께 담습니다.
{"type":"object","properties":{"run_no":{"type":"string"},"verdict":{"type":"string","enum":["ok","retry_exceeded","confirm_skipped","tool_unmapped","not_finished","duplicate_step"]},"evidence":{"type":"array","items":{"type":"object","properties":{"field":{"type":"string"},"agg":{"type":["string","null"]},"value":{},"quote":{"type":["string","null"]}},"required":["field","value"]}},"next_action":{"type":"string"}},"required":["run_no","verdict","evidence","next_action"]}[
{
"run_no": "RUN-001",
"verdict": "ok",
"evidence": [
{
"field": "tool_raw",
"value": "send_mail"
},
{
"field": "requires_confirm",
"value": true
},
{
"field": "ended_reason",
"value": "completed"
}
],
"next_action": "확인 단계를 거쳐 정상 종료했습니다. 기준 실행으로 남깁니다."
},
{
"run_no": "RUN-003",
"verdict": "ok",
"evidence": [
{
"field": "tool_raw",
"value": "update_crm"
},
{
"field": "retry_count",
"value": 0
},
{
"field": "ended_reason",
"value": "completed"
}
],
"next_action": "재시도 없이 정상 종료했습니다. 기준 실행으로 남깁니다."
},
{
"run_no": "RUN-004",
"verdict": "ok",
"evidence": [
{
"field": "tool_raw",
"value": "SearchDocs",
"quote": "SearchDocs"
},
{
"field": "tool_raw",
"value": "SearchDocs"
},
{
"field": "ended_reason",
"value": "completed"
}
],
"next_action": "표기가 달랐지만 정책 별칭으로 정규화됐습니다. 기준 실행으로 남깁니다."
},
{
"run_no": "RUN-002",
"verdict": "retry_exceeded",
"evidence": [
{
"field": "retry_count",
"value": 4
},
{
"field": "max_retries",
"value": 2
},
{
"field": "ended_reason",
"value": "max_retry"
}
],
"next_action": "허용 반복을 넘겨 끝났습니다. 검색이 실패하는 조건을 프롬프트에서 먼저 거릅니다."
},
{
"run_no": "RUN-007",
"verdict": "confirm_skipped",
"evidence": [
{
"field": "tool_raw",
"value": "send_mail"
},
{
"field": "requires_confirm",
"value": true
},
{
"field": "action_type",
"value": "call"
}
],
"next_action": "확인이 필요한 도구를 바로 실행했습니다. 루프에 확인 단계를 넣기 전에는 운영에 올리지 않습니다."
},
{
"run_no": "RUN-005",
"verdict": "tool_unmapped",
"evidence": [
{
"field": "tool_raw",
"value": "delete_record",
"quote": "delete_record"
},
{
"field": "tool_raw",
"value": "delete_record"
}
],
"next_action": "정책에 없는 도구를 썼습니다. 위험도를 정해 정책에 넣기 전에는 통과시키지 않습니다."
},
{
"run_no": "RUN-009",
"verdict": "not_finished",
"evidence": [
{
"field": "action_type",
"value": "call"
},
{
"field": "ended_reason",
"value": null
}
],
"next_action": "종료 단계 없이 끝났습니다. 실행이 끊긴 지점을 로그에서 확인합니다."
},
{
"run_no": "RUN-008",
"verdict": "duplicate_step",
"evidence": [
{
"field": "step_seq",
"agg": "count",
"value": 2
}
],
"next_action": "같은 단계 번호가 두 번 기록됐습니다. 기록기가 중복 기입하는지 확인합니다."
}
][자동 검증 · 1주차] 1. verdict가 enum 여섯 값 안에 있는지 확인합니다. 2. run_no·verdict·evidence·next_action이 모두 있는지 확인합니다. 3. retry_count가 0 이상인지 확인합니다. 4. tool_id가 null이면 verdict가 tool_unmapped인지 확인합니다. 5. evidence의 field가 두 입력 표의 컬럼에 실재하는지 확인합니다. 6. evidence의 quote가 그 행 tool_raw의 일부인지 확인합니다. 7. next_action이 존댓말로 끝나는지 확인합니다. [판정 규칙] 1. 도구 이름은 대소문자와 띄어쓰기, 구분자를 없애 소문자로 모은 뒤 agent_loop_policy의 tool_id와 맞춥니다. 맞는 것이 없으면 미매핑으로 남기고 그 행은 나머지 판정에서 뺍니다. [수동 검증] 1. 확인 단계를 건너뛴 실행이 실제로 위험했는지 고객사 담당자가 판단합니다. 2. RUN-006처럼 재시도가 허용치 안에 있는 실행은 사유를 달지 않는 것이 맞는지 확인합니다. [평가 러너 · 2주차] 1. 프롬프트 수정 전후 두 묶음을 비교해 새로 어긋난 실행과 고쳐진 실행을 셉니다. 2. 기록과 정답을 작성자가 만든 합성 기준이라 이 수치는 성능 측정이 아니라 데모 조건 동작입니다.