플렉스
경력근거: Multi Agent 가 조직화 되고 협업하여, 최적의 문제를 해결해 나가는 과정을 구조화하고 고도화합니다
※ 실제 산출물이 아닌 AI 예측 시안입니다.
이 백엔드가 보여주는 것은 자연어 질문을 하위 작업으로 나누는 플래너, 전문 에이전트 오케스트레이션, 근태 레코드와 규정 조항에 근거를 매는 설계 기술이며, 노무사 수준의 법률 해석 전문성을 주장하지 않습니다. 다만 이 사슬이 말이 되려면 flex 라는 맥락, 즉 사람과 조직 문제를 다루는 인사·근태 SaaS 가 있어야 의미가 있습니다. '근거 없이는 단정하지 않는다' 는 각도는 옮길 수 있지만, 주 52시간·연장근로 한도·휴게시간 같은 근로 규정 조항과 打刻 단위의 근태 레코드가 있어야 규정 판정 에이전트의 근거가 구체화됩니다. 실제 노무 판단은 노무사가 있어야 하고, 면접에서 모르는 부분은 모른다고 말하는 편이 낫습니다.
'사람과 조직에 관한 모든 문제를 해결하는 flex AI Agent 의 백엔드 기반에 집중하여 설계, 개발, 운영' 이 주요업무입니다. 인사·근태 도메인 질문을 받아 답을 만드는 에이전트 백엔드를 세우는 게 보여줄 대상입니다.
'Multi Agent 가 조직화 되고 협업하여, 최적의 문제를 해결해 나가는 과정을 구조화하고 고도화' 를 요구합니다. 플래너가 작업을 나누고 전문 에이전트가 나눠 맡는 오케스트레이션 설계가 필요합니다.
'모든 기술 스택에 능통하지 않아도, 빠르게 습득하고 적정 기술을 판단하는 역량' 을 중시하고 LiteLLM·LangChain·Ragas·Bedrock 을 스택으로 씁니다. 멀티 모델 라우팅과 답변 평가를 수단으로 다루는 각도와 맞습니다.
관리자가 근태·규정에 관한 질문을 자연어로 던지면, 플래너 에이전트가 질문을 근태 집계·규정 판정·급여 영향 같은 하위 작업으로 나누고 전문 에이전트가 각각 근태 기록과 규정 조항에 근거해 답합니다. 답에는 어느 레코드와 어느 조항을 봤는지 근거(record_id·조항)를 함께 붙이고, 수치 계산은 규칙 엔진이 결정하며 LLM 은 질문 분해와 답변 문장 작성을 맡습니다. 근거가 없거나 데이터가 비면 지어내지 않고 확인 필요로 표시합니다. 1주차만으로 완성품이고, Ragas 답변 평가(2주차)와 에이전트 병렬화·도구 호출(3주차)로 키웁니다. 근거는 채용공고 정렬입니다.
flex AI Agent 백엔드 PE. 관리자가 물어보는 근태·규정 질문에 답하려고 근태 조회와 규정 확인, 급여 영향을 손으로 오가며 짜맞추던 일을 끝내고, 질문을 한 번에 던지면 에이전트가 나눠 맡아 근거와 함께 답하되 애매하면 단정 대신 확인 필요로 돌려받고 싶은 사람입니다.
자연어 HR 질문을 플래너로 하위 작업에 나누고 전문 에이전트가 근태 기록·규정 조항에 근거해 답하게 하면, (a) 질문이 근태 집계·규정 판정 같은 작업으로 분해되고, (b) 각 답에 어느 레코드·어느 조항을 봤는지 근거가 붙으며, (c) 데이터가 없으면 지어내지 않고 확인 필요로 남아, 관리자가 그대로 믿고 조치할 답을 만든다는 걸 보여줍니다.
관리자의 자연어 근태·규정 질문을 플래너 에이전트가 하위 작업으로 나누고, 근태 집계·규정 판정 에이전트가 근태 기록과 규정 조항에 근거해 답하며, 근거(record_id·조항)를 함께 붙이는 동작하는 FastAPI 백엔드입니다. 근태 수치는 규칙 엔진이 계산하고 LLM 은 분해와 문장 작성만 맡습니다.
Ragas 로 답변 충실도(faithfulness)와 근거 인용 정확도를 채점하고, HR 검토자 페르소나 2명이 답이 규정에 맞는지 라벨링해 틀린 근거·과잉 단정 비율을 대조하는 대시보드입니다.
독립적인 하위 작업을 전문 에이전트가 병렬로 처리하고, 근태 조회를 LLM 문맥 주입 대신 도구 호출(근태 DB 질의)로 바꿔 지연·비용을 줄이며 LiteLLM 으로 모델을 작업별로 라우팅하는 단계입니다.
관리자 질문 20종을 넣으면, 플래너가 하위 작업으로 나누고 전문 에이전트가 근태 기록·규정 조항에 근거해 답하며 근거를 함께 붙이는 걸 시연합니다
답이 인용한 record_id·조항이 전부 실재하고 근태 수치가 규칙 계산과 일치하는지 자동 대조합니다. 근거 없는 답은 확인 필요로 차단되는 걸 보여줍니다
打刻 누락·미등록 사번·규정 사각지대 30종을 넣어도 출력 스키마가 안 깨지고 단정 대신 확인 필요로 넘기는 강건성을 보여줍니다
내가 만든 정답 30건 중 판정·근거가 일치한 게 25건(83%). 단, 정답과 데이터를 모두 내가 만든 합성 기준이라 성능 검증이 아니라 데모 조건 동작임을 밝힙니다
위 수치는 전부 작성자가 만든 더미데이터 자가채점이며, 실제 규정 판정 정확도와 노무 타당성은 flex 실 근태 데이터와 노무사가 있어야 측정 가능합니다. 이 백엔드는 그 검증을 바로 돌릴 수 있는 상태까지 만듭니다.
이건 고객·실데이터 없이 혼자 만든 포트폴리오라, 수치는 합성 데이터 자가채점이라 성능 증명이 아닙니다. 면접에서 데모 동작과 실검증 준비 상태로 솔직히 설명합니다
정답을 작성자가 만들었으니 잘 맞는 것이 당연합니다. 打刻 누락·미등록 사번·규정 경계 케이스를 더미에 일부러 섞어, 깔끔한 질문만 다루는 게 아님을 보여줍니다
이 포트폴리오가 보여주는 것은 멀티에이전트 오케스트레이션·근거 인용·규칙 판정 기술이지 노무 법률 해석 전문성이 아닙니다. 규정 판단은 노무사가 있어야 하고, 면접에서 모르는 부분은 모른다고 말하는 편이 낫습니다
상관과 인과를 헷갈리기 쉽습니다. 연장근로가 많은 것과 규정 위반은 다르므로, 위반 여부는 LLM 추정이 아니라 규칙 조항 매핑으로만 판정하고 애매하면 확인 필요로 남깁니다
실제 도입 시 달라지는 것 명시합니다. 실 근태 데이터 분포·사내 규정 조항은 더미와 다르므로 규칙과 조항 매핑을 다시 맞춰야 하고, 검토자도 노무사로 교체해야 합니다(도입 단계 과제로 분리)
① 인라인 샘플 · ② seed.json 다운로드 · ③ 증강 프롬프트. 세 층 모두 동일한 schema 에서 파생.
직원별 일 단위 근태 打刻 기록. 근태 집계·규정 판정의 원천입니다. 打刻 누락(clock_out null)·극단값(연장근로 0 또는 과다)·미등록 사번(orphan)·휴가 표기 흔들림을 일부러 섞어, 규칙이 결측에 과민 반응하지 않고 애매한 건 확인 필요로 넘기는지 보여줍니다.
| record_id | employee_id | date | clock_in | clock_out | work_min | overtime_min | leave_type_raw | leave_type_id | status |
|---|---|---|---|---|---|---|---|---|---|
| a_001 | e_A | 2026-05-04 | 09:00 | 22:30 | 690 | 210 | — | — | normal |
| a_002 | e_A | 2026-05-05 | 09:00 | 21:00 | 600 | 120 | — | — | normal |
| a_003 | e_A | 2026-05-06 | 09:10 | — | — | 0 | — | — | missing_punch |
| a_004 | e_B | 2026-05-04 | 10:00 | 19:00 | 480 | 0 | — | — | normal |
| a_005 | e_B | 2026-05-05 | — | — | — | 0 | 반차 | lv_half | leave |
아래 JSON Schema 에 맞는 직원 근태 打刻 기록 40행 JSON 배열로 생성합니다. 직원 4~6명, 한 주치.
{"type":"object","properties":{"record_id":{"type":"string"},"employee_id":{"type":"string"},"date":{"type":"string"},"clock_in":{"type":["string","null"]},"clock_out":{"type":["string","null"]},"work_min":{"type":["integer","null"]},"overtime_min":{"type":"integer"},"leave_type_raw":{"type":["string","null"]},"leave_type_id":{"type":["string","null"]},"status":{"type":"string","enum":["normal","missing_punch","leave","holiday"]}},"required":["record_id","employee_id","date","overtime_min","status"]}
쉬운 데이터만 만들지 말 것. 하드 케이스 의도적 혼입: (1) clock_out 이 null 인 打刻 누락 1~2건(status=missing_punch), (2) 주간 합산이 주 52시간을 명백히 넘는 직원 1명과 경계선(약 52시간 언저리) 직원 1명, (3) hr_policy·직원 마스터에 없는 미등록 사번(e_Z 처럼) 1건, (4) leave_type_raw 가 '반차'·'오전 반차'처럼 같은 개념을 다르게 적어 leave_type_id 가 비는 표기 흔들림 1~2건. JSON 배열만.{"type":"object","properties":{"record_id":{"type":"string"},"employee_id":{"type":"string"},"date":{"type":"string"},"clock_in":{"type":["string","null"]},"clock_out":{"type":["string","null"]},"work_min":{"type":["integer","null"]},"overtime_min":{"type":"integer"},"leave_type_raw":{"type":["string","null"]},"leave_type_id":{"type":["string","null"]},"status":{"type":"string","enum":["normal","missing_punch","leave","holiday"]}},"required":["record_id","employee_id","date","overtime_min","status"]}규정 판정 에이전트가 근거로 인용하는 근로기준법·사내 규정 조항. 규정 판정의 근거원입니다. 서로 겹치거나 예외가 있는 조항을 섞어, 에이전트가 조항을 정확히 인용하고 사각지대는 단정하지 않는지 보여줍니다.
1주간의 근로시간은 휴게시간을 제외하고 40시간을 초과할 수 없으며, 당사자 간 합의로 연장근로를 포함해 1주 12시간, 총 52시간을 초과할 수 없습니다.
연장근로는 당사자 간 합의를 전제로 1주 12시간을 넘지 못합니다. 합의 없는 연장 지시는 위반입니다.
아래 JSON Schema 에 맞는 근로 규정·사내 규정 조항 문서 20건을 JSON 배열로 생성합니다. 각 문서는 title·body 를 반드시 포함합니다.
{"type":"object","properties":{"policy_id":{"type":"string"},"title":{"type":"string"},"body":{"type":"string"},"source":{"type":"string","enum":["law","company"]},"clause":{"type":["string","null"]}},"required":["policy_id","title","body","source"]}
쉬운 데이터만 만들지 말 것. 하드 케이스 의도적 혼입: (1) 서로 예외 관계인 조항(탄력근로처럼 원칙의 예외를 두는 조항) 1~2건, (2) 사내 규정(source=company)과 법 조항(source=law)이 같은 주제를 다르게 정하는 겹침 1건, (3) clause 가 null 인 사각지대 조항 1건(에이전트가 근거 조항을 못 대면 확인 필요로 넘겨야 함), (4) 打刻 누락처럼 판정 보류를 명시하는 조항 1건. JSON 배열만.{"type":"object","properties":{"policy_id":{"type":"string"},"title":{"type":"string"},"body":{"type":"string"},"source":{"type":"string","enum":["law","company"]},"clause":{"type":["string","null"]}},"required":["policy_id","title","body","source"]}| Kotlin | Spring Boot·Spring AI 로 에이전트 오케스트레이션 API 게이트웨이 구현(대표 언어) |
| Python | FastAPI 로 근태 집계·규정 판정 전문 에이전트 서버 구현 |
| Spring Boot | 관리자 질문 접수·응답 조회 엔드포인트(POST /ask, GET /answers) |
| Spring AI | Kotlin 쪽 플래너 에이전트의 프롬프트·도구 호출 오케스트레이션 |
| FastAPI | 규정 판정·근태 집계 에이전트의 경량 추론 서버 |
| LiteLLM | Bedrock·Vertex·Azure 를 한 인터페이스로 묶어 작업별로 모델 라우팅 |
| LangChain | 플래너의 질문 분해와 전문 에이전트 체인·도구 호출 구성 |
| Ragas | 답변 충실도·근거 인용 정확도를 평가하는 2주차 채점 도구 |
| AWS Bedrock | Claude 계열 모델 접근 경로(플래너·요약 에이전트) |
| PostgreSQL | attendance_record·hr_policy·agent_answer 저장소 |
✓ pass → 그대로 멈춰도 완결입니다. 더 키우려면 2주차(Ragas 답변 평가)로 진행합니다.
✓ pass → 여기서 멈춰도 완결입니다. 더 키우면 3주차(에이전트 병렬화·도구 호출)로 진행합니다.
관리자 질문에 대한 멀티에이전트 최종 답변. 질문 분해(plan)·답변(answer)·근거(evidence 의 레코드·조항 ref)·확신도(confidence)·확인 필요 여부(needs_more_info)를 한 스키마에 담아, 근거 없이 단정하지 않고 데이터가 비면 확인 필요로 남겼는지 객관 검증합니다.
{"type":"object","properties":{"question":{"type":"string"},"plan":{"type":"array","items":{"type":"object","properties":{"agent":{"type":"string","enum":["attendance","policy","payroll"]},"task":{"type":"string"}},"required":["agent","task"]}},"answer":{"type":"string"},"evidence":{"type":"array","items":{"type":"object","properties":{"kind":{"type":"string","enum":["record","policy"]},"ref":{"type":"string"},"quote":{"type":"string"}},"required":["kind","ref"]}},"confidence":{"type":"number"},"needs_more_info":{"type":"boolean"}},"required":["question","plan","answer","evidence","needs_more_info"]}[
{
"input_ref": "질문: '이번 주 e_C 가 주 52시간 넘겼어?'",
"output": {
"question": "이번 주 e_C 가 주 52시간 넘겼어?",
"plan": [
{
"agent": "attendance",
"task": "e_C 의 이번 주 근로시간 합산"
},
{
"agent": "policy",
"task": "주 52시간 한도 조항 확인"
}
],
"answer": "e_C 는 이번 주 확인된 이틀(5/4, 5/5)만으로도 근로 약 26.5시간에 연장 630분이 잡혀 주 52시간 한도를 초과할 소지가 큽니다. 남은 요일 打刻이 채워지면 더 늘어납니다.",
"evidence": [
{
"kind": "record",
"ref": "a_007",
"quote": "08:30"
},
{
"kind": "record",
"ref": "a_008",
"quote": "08:30"
},
{
"kind": "policy",
"ref": "p_01",
"quote": "1주간의 근로시간은 휴게시간을 제외하고 40시간을 "
}
],
"confidence": 0.86,
"needs_more_info": false
}
},
{
"input_ref": "질문: 'e_A 5/6 근로시간 얼마야?' (打刻 누락)",
"output": {
"question": "e_A 5/6 근로시간 얼마야?",
"plan": [
{
"agent": "attendance",
"task": "e_A 5/6 근로시간 조회"
}
],
"answer": "5/6 은 퇴근 打刻이 누락되어(status=missing_punch) 근로시간을 자동 산정하지 않습니다. 관리자 확인 후 보정이 필요하며 그 전에는 위반 판정을 보류합니다.",
"evidence": [
{
"kind": "record",
"ref": "a_003",
"quote": "09:10"
},
{
"kind": "policy",
"ref": "p_09",
"quote": "1주간의 근로시간은 휴게시간을 제외하고 40시간을 "
}
],
"confidence": 0.9,
"needs_more_info": true
}
},
{
"input_ref": "질문: 'e_Z 연차 며칠 남았어?' (미등록 사번)",
"output": {
"question": "e_Z 연차 며칠 남았어?",
"plan": [
{
"agent": "attendance",
"task": "e_Z 직원·연차 정보 조회"
}
],
"answer": "e_Z 는 직원 마스터에 없는 사번이라 연차 잔여를 계산할 근거가 없습니다. 사번 등록을 확인해 주셔야 답할 수 있습니다.",
"evidence": [],
"confidence": 0.3,
"needs_more_info": true
}
}
][자동 검증] 1. 출력이 스키마를 통과하는가(형식·필수 필드). 2. evidence 의 record ref 가 attendance_record 에, policy ref 가 hr_policy 에 실재하는가(지어낸 근거 차단). 3. answer 의 근로시간·연장 수치가 규칙 엔진 계산과 일치하는가(LLM 이 수치를 바꾸지 못함). 4. 데이터 결측(打刻 누락·미등록 사번)이면 needs_more_info=true 이고 단정 표현이 없는가. [수동 검증] 1. HR 검토자 페르소나 2명이 규정 판정 타당성 라벨링, bootstrap Cohen's κ(두 사람 답이 우연 이상으로 일치하는 정도) 하한 0.6 이상. 2. Ragas 답변 충실도(faithfulness: 답이 인용한 근거만으로 성립하는 정도) 채점 후 하위 5% 사람 점검.
포트폴리오가 “무엇을 만들지”라면, 시나리오 테스트는 “현장에서 어떻게 판단·소통할지” 입니다. 실제 이 채용공고 맥락의 대본을 읽고 무엇을 물어야 할지 직접 써봅니다.
근거: Multi Agent 가 조직화 되고 협업하여, 최적의 문제를 해결해 나가는 과정을 구조화하고 고도화합니다