베르AI Agent 기업 - FDE(Forward Deployed Engineer) / 대전 근무
0.0베르투솔루션
경력근거: 고객사에 임베딩되어 현장의 모호한 비즈니스 문제를 직접 듣고, 함께 정의·구조화합니다
36일 전 확인채용 공고 보기
※ 실제 산출물이 아닌 AI 예측 시안입니다.
베르투솔루션 FDE 는 고객사에 임베딩되어 현장의 모호한 비즈니스 문제를 직접 듣고 온톨로지·에이전트로 End-to-End 구조화합니다. 이 도구는 베르투의 '문제를 먼저 정의·구조화하는' 작업 흐름이 있어야 의미가 생기고, 모델 성능이 아니라 문제 구조화 품질로 평가됩니다.
공고가 현장의 모호한 비즈니스 문제를 직접 듣고 함께 정의·구조화하는 일을 첫 업무로 꼽는다. 구조화 도구는 그 단계의 초안을 만든다.
데이터 설계·가공부터 온톨로지·에이전트 구축까지 한 사람이 끝까지 한다. 요구사항을 온톨로지·에이전트 스펙으로 잇는 구조가 그대로 맞는다.
어떤 모델을 썼느냐보다 어떤 문제를 풀었느냐를 본다. 출력이 모델 자랑이 아니라 문제 구조화 결과여야 한다.
AI 에이전트 FDE 의 요구사항 구조화 도구입니다. 고객사 업무 설명 텍스트를 넣으면 온톨로지 엔티티·관계와 에이전트 단계 초안이 나오고, 매핑마다 근거 문장이 붙습니다.
베르투솔루션 FDE 와 고객사 현업 담당자입니다.
현장에서 받은 업무 설명 텍스트만으로도 온톨로지 엔티티·관계와 에이전트 단계의 1차 초안을 만들 수 있고, FDE 는 그 초안을 고치며 고객과 합의하면 됩니다.
고객사 업무 설명 텍스트를 넣으면 엔티티·관계(온톨로지 초안)와 에이전트 단계(입력·도구·출력)를 근거 배열과 함께 내는 웹 도구입니다. 실제 고객 시스템 연동은 빼고 설명 텍스트와 가정 데이터 소스 목록만으로 시작한다(실 연동은 빠진 20% 통합 작업이라 W3로 분리).
1주차 초안을 사람 검토자 한 명이 정리한 정답 구조와 비교해 엔티티 누락·과잉을 재고, 어긋난 구간을 보정한 v2. 근거가 설명 문장을 인용했는지 검사하는 표를 붙입니다.
에이전트 단계의 각 도구를 실제 API·DB 연동 스펙(엔드포인트·인증·입출력)으로 채워, 현장 통합 직전 골격까지 만드는 확장판입니다.
고객사 업무 설명 한 건을 넣으면 온톨로지 엔티티·관계와 에이전트 단계, 그 근거 배열이 한 화면에 나오는 걸 시연합니다.
초안 엔티티가 모두 설명 텍스트에 등장하고 근거 배열이 설명 문장을 인용했는지 judge 로 검사해 엔티티 실재율 100%를 보여줍니다. 단, 정답·데이터를 작성자가 만든 합성 기준이라 성능 검증이 아니라 데모 조건 동작입니다.
결측·모호·미정의 용어를 일부러 섞은 설명 30종을 넣어도 출력 JSON 형식이 안 깨지고 '불명확·추가질문필요'로 알리는 걸 시연합니다.
초안 구조와 합성 정답 구조의 일치도를 Cohen's κ(두 채점자가 우연 이상으로 얼마나 일치하는지 -1~1 점수, 높을수록 일치)로 2주차에 보고합니다. 합성 기준 추정이라 실제 일치도와 다를 수 있습니다.
위 수치는 더미데이터 자가채점이며, 실제 구조화 정확도는 베르투솔루션 실 고객 설명과 실 FDE 검토자가 있어야 측정 가능합니다. 이 포트폴리오는 그 검증을 바로 돌릴 수 있는 상태까지 만듭니다.
수치는 합성 데이터 자가채점이라 성능 증명이 아닙니다. 면접에서 데모 동작과 실검증 준비 상태로 솔직히 설명합니다.
정답을 작성자가 만들었으니 잘 맞는 것이 당연합니다. 결측·모호·미정의 용어를 더미에 일부러 섞어 쉬운 문제만 푸는 함정을 피합니다.
설명에 같은 개체가 다른 말로 적혀 표면 유사도가 곧 의미 일치는 아닙니다. 실데이터 도입 단계에서 용어 사전을 맞추는 과제로 분리합니다.
실제 도입 시 합성 정답이 실 FDE 판단으로 바뀌고 고객 도메인도 매번 달라집니다. 엔티티 타입과 도구 enum 을 실 도메인으로 다시 맞추는 일을 도입 과제로 둡니다.
① 인라인 샘플 · ② seed.json 다운로드 · ③ 증강 프롬프트. 세 층 모두 동일한 schema 에서 파생.
고객사 현장에서 받은 업무 설명. 구조화 도구의 입력.
고객 문의가 들어오면 주문번호로 반품 가능 여부를 확인하고 가능하면 반품 접수까지 자동으로 해줬으면 합니다.
설비 점검 결과를 사진이랑 같이 올리면 이상 항목만 모아서 일보로 정리됐으면 좋겠어요.
다음 Zod 스키마를 따르는 업무 설명을 더 생성하라: {"type":"object","properties":{"brief_id":{"type":"string"},"title":{"type":"string"},"body":{"type":"string"},"domain_raw":{"type":["string","null"]},"clarity":{"type":"string","enum":["clear","partial","vague"]}},"required":["brief_id","title","body","domain_raw","clarity"]}. 쉬운 데이터만 만들지 말 것 — 다음 하드 케이스를 의도적으로 섞어라: title 이 빈 문자열인 건, domain_raw 가 null 인 미상 도메인(orphan), clarity 'vague' 로 지시대명사('그거')만 있어 엔티티가 안 잡히는 건, 같은 작업을 다른 말로 적은 표기 흔들림. 추가로 형식 깨뜨리기 시도 3건(타입이 어긋난 행)을 별도 표시해 파서 가드 테스트에 쓴다.{"type":"object","properties":{"brief_id":{"type":"string"},"title":{"type":"string"},"body":{"type":"string"},"domain_raw":{"type":["string","null"]},"clarity":{"type":"string","enum":["clear","partial","vague"]}},"required":["brief_id","title","body","domain_raw","clarity"]}| LLM | 고객사 업무 설명을 엔티티·관계·에이전트 단계로 분해하고, 각 항목이 설명의 어느 문장에서 나왔는지 근거를 생성한다. |
| RAG | 비슷한 과거 구조화 사례를 검색해 few-shot 예시로 넣고, 도메인 용어 사전을 컨텍스트에 붙여 매핑 품질을 높인다. |
| Python | 구조화 엔진의 런타임. 설명 파싱·LLM 호출·스키마 검증·근거 정합 검사를 묶는다. |
| LLM-as-judge | 초안 엔티티가 설명에 실제 등장하는지, 근거가 설명을 인용했는지 검사하는 보조 모델. |
✓ pass → 여기서 멈춰도 FDE 초안 도구로 완결입니다. 더 키우려면 2주차에서 정답 구조와 비교해 엔티티 누락·과잉을 보정합니다.
✓ pass → 신뢰가 붙으면 3주차에서 도구를 실제 연동 스펙으로 채웁니다.
업무 설명 한 건을 온톨로지 엔티티·관계와 에이전트 단계로 구조화한 결과.
{"type":"object","properties":{"brief_id":{"type":"string"},"entities":{"type":"array","items":{"type":"object","properties":{"name":{"type":"string"},"type":{"type":"string","enum":["actor","object","event","data_source","rule"]}},"required":["name","type"]},"minItems":0},"relations":{"type":"array","items":{"type":"object","properties":{"from":{"type":"string"},"to":{"type":"string"},"label":{"type":"string"}},"required":["from","to","label"]}},"agent_steps":{"type":"array","items":{"type":"object","properties":{"step":{"type":"string"},"tool":{"type":"string","enum":["api_call","db_query","doc_search","notify","compute"]},"io":{"type":"string"}},"required":["step","tool","io"]}},"evidence":{"type":"array","items":{"type":"object","properties":{"field":{"type":"string","enum":["title","body","domain_raw"]},"note":{"type":"string"}},"required":["field","note"]},"minItems":1},"hedge":{"type":"string"}},"required":["brief_id","entities","relations","agent_steps","evidence","hedge"]}[
{
"brief_id": "B001",
"entities": [
{
"name": "고객 문의",
"type": "event"
},
{
"name": "주문번호",
"type": "object"
},
{
"name": "반품 가능 여부",
"type": "rule"
}
],
"relations": [
{
"from": "고객 문의",
"to": "주문번호",
"label": "참조"
}
],
"agent_steps": [
{
"step": "주문번호로 반품 가능 여부 확인",
"tool": "db_query",
"io": "주문번호 → 가능여부"
},
{
"step": "가능하면 반품 접수",
"tool": "api_call",
"io": "주문번호 → 접수ID"
}
],
"evidence": [
{
"field": "body",
"note": "'반품 가능 여부를 확인' 에서 rule 추출"
}
],
"hedge": "엔티티 타입은 합성 기준 추정이라 실 도메인에서 달라질 수 있다."
},
{
"brief_id": "B003",
"entities": [],
"relations": [],
"agent_steps": [],
"evidence": [
{
"field": "body",
"note": "'그거' 지시대명사뿐이라 엔티티를 못 잡아 추가질문 필요로 표시"
}
],
"hedge": "vague 입력이라 구조화 불가. 합성 기준."
},
{
"brief_id": "B010",
"entities": [
{
"name": "알람",
"type": "event"
},
{
"name": "로그",
"type": "data_source"
},
{
"name": "담당자",
"type": "actor"
}
],
"relations": [
{
"from": "알람",
"to": "로그",
"label": "수집 대상"
}
],
"agent_steps": [
{
"step": "관련 로그 수집",
"tool": "doc_search",
"io": "알람 → 로그묶음"
},
{
"step": "원인 후보 추림",
"tool": "compute",
"io": "로그 → 후보목록"
},
{
"step": "담당자 라우팅",
"tool": "notify",
"io": "후보 → 알림"
}
],
"evidence": [
{
"field": "body",
"note": "'관련 로그를 모아 원인 후보를 추리고' 에서 단계 추출"
}
],
"hedge": "합성 기준 추정 단계라 실 운영에서 보강 필요."
}
]entities.type·agent_steps.tool enum, relations 의 from/to 가 entities 에 있는지, evidence min(1)은 Zod 와 조인으로 자동 검증한다. evidence note 가 설명과 의미상 맞는지, hedge 가 합성 기준임을 밝혔는지는 judge 와 수동 spot-check 로 검증한다.