앵글컴퍼니는 온톨로지 기반 지식 구조와 산업별 도메인 특화 에이전트 OS(Angle OS)를 만드는 회사이고, FDE 가 고객사에 임베딩되어 업무를 발굴하고 에이전트를 배포합니다. 업무를 개체·관계로 구조화해 적용 지점을 진단하는 이 도구는 앵글컴퍼니가 다루는 ‘온톨로지 + 현장 에이전트 배포’ 라는 고유한 작업 방식이 있어야 의미가 있어, 같은 사슬을 다른 회사 데이터로는 그대로 만들 수 없습니다.
‘온톨로지 기반 지식 구조와 멀티모달 추론형 AI 를 결합한다’ 가 핵심이라, 업무를 개체·관계로 구조화하는 단계가 FDE 작업의 출발점입니다.
‘고객사 안으로 들어가 업무를 직접 들여다보고 에이전트를 설계·배포한다’ 가 직무라, 업무 발굴과 적용 지점 진단이 직격입니다.
‘데모를 운영 시스템으로 바꾸는 마지막 한 사람’ 이라, 진단에서 에이전트 작업 정의까지 한 루프로 잇는 구조가 필요합니다.
고객사의 업무 단계 기록(누가·무엇을·얼마나 자주·얼마나 오래)을 받아 개체·관계(온톨로지)로 구조화하고, 어느 단계에 에이전트를 붙이면 효과가 큰지 RAG 근거와 함께 진단하는 FDE PoC 입니다. 데이터는 작성자가 만든 더미데이터이고, 근거는 채용공고 정렬입니다.
앵글컴퍼니 FDE. 고객사 업무를 사람이 인터뷰로 모아 ‘어디에 에이전트를 넣을지’ 를 매번 손으로 정리하던 일을, 업무 구조화·적용 지점 진단 도구로 보조하고 싶은 사람입니다.
업무 단계에 빈도·소요시간·담당을 붙이면, LLM 이 (a) 단계를 개체·관계로 구조화하고 (b) 자동화 적합도가 높은 단계를 RAG 근거와 함께 짚으며 (c) 그 단계의 에이전트 작업 정의 초안을 만듭니다.
업무 단계 기록을 받아 개체·관계로 구조화하고, 자동화 적합도가 높은 단계를 RAG 근거와 함께 짚는 동작하는 도구입니다. 멀티모달(이미지·영상) 입력은 빠진 20% 기술이라 1주차는 텍스트 업무 기록과 메타데이터 가정으로 시작하고, 멀티모달 결합은 2·3주차로 분리합니다.
현업 검토자 2명이 진단·우선순위가 타당한지 라벨링하고, 자동화 적합도 판정의 일치도를 보여주는 대시보드입니다.
이미지·문서 캡처가 섞인 업무 기록과 여러 부서로 진단을 넓혀, 산업별 온톨로지로 확장 배포하는 단계입니다.
업무 단계 기록을 넣으면 개체·관계 구조와 자동화 적합도 높은 단계가 RAG 근거 인용과 함께 몇 초 안에 나오는 걸 시연합니다
진단이 인용한 근거 문장이 실제 업무 설명 문서에 존재하는 비율 100%를 보여줍니다. 없으면 ‘근거 부족’ 으로 환각을 차단합니다
측정: 인용 일치 규칙, 표본: 업무 단계 200건
일부러 만든 결측·미등록·표기 흔들림 업무 30종을 넣어도 출력 형식(Zod 스키마)이 한 번도 안 깨지는 걸 보여줍니다
진짜 성능 검증은 여기서 멈춥니다. 위 수치는 전부 작성자가 만든 더미데이터 자가채점이며, 실제 진단 정확도와 자동화 효과는 앵글컴퍼니 고객사의 실제 업무 데이터와 실 현업 검수가 있어야 측정됩니다. 이 도구는 그 검증을 바로 돌릴 수 있는 상태까지 만듭니다.
이건 고객·실데이터 없이 혼자 만든 포트폴리오라 모든 수치는 합성 데이터 자가채점이라 성능 증명이 아닙니다. 면접에서 ‘데모 조건 동작 + 실검증 준비 상태’ 로 솔직히 설명하는 게 오히려 신뢰를 줍니다
정답을 작성자가 만들었으니 잘 맞는 게 당연합니다. 그래서 일부러 헷갈리는 결측·미등록·경계 업무 단계를 더미에 섞어 쉬운 문제만 푸는 게 아님을 보여줍니다
‘이 단계가 병목이라 자동화하면 좋다’ 는 상관 관찰일 뿐 인과가 아닐 수 있습니다. 단정 표현을 누그러뜨리고 절대 추정값(절감 시간)은 합성 기준임을 hedge 로 드러냅니다
업무 단계 이름 표기가 부서마다 제각각입니다. 이름 유사도로 같은 개체로 묶고, 못 묶은 건 추측하지 말고 ‘미매핑’ 으로 알립니다
실제 도입 시 달라지는 점을 분리해 둡니다. 실 업무 분포와 멀티모달 입력은 더미와 다르므로 온톨로지 사전·임계값을 다시 맞춰야 하고, 현업 검수도 실제 인력으로 교체해야 합니다
① 인라인 샘플 · ② seed.json 다운로드 · ③ 증강 프롬프트. 세 층 모두 동일한 schema 에서 파생.
고객사 업무 단계 기록. 구조화·진단 LLM 이 가장 먼저 질의하는 테이블입니다. 운영 현실대로 결측(소요시간 미입력)·미등록 개체·별칭 표기·경계값을 일부러 섞어, 쉬운 데이터만 푸는 게 아님을 보여줍니다.
| step_id | dept | step_raw | entity_id | actor | freq_per_week | minutes_each | tool |
|---|---|---|---|---|---|---|---|
| s_001 | 영업 | 견적서 수기 작성 | e_quote | 담당자 | 40 | 25 | 엑셀 |
| s_002 | 영업 | 견적 작성 | e_quote | 담당자 | 12 | 30 | 엑셀 |
| s_003 | 운영 | 입고 검수 사진 대조 | — | 담당자 | 60 | — | 카카오톡 |
| s_004 | 운영 | 재고 수불 입력 | e_inventory | 담당자 | 100 | 4 | ERP |
| s_005 | CS | 반복 문의 답변 복붙 | e_cs_reply | 담당자 | 200 | 3 | 채널톡 |
아래 Zod 스키마에 맞는 고객사 업무 단계 기록 80행 JSON 배열로 생성하세요. 부서 4~5개, 빈도·소요시간 분포 자연스럽게.
z.object({ step_id: z.string(), dept: z.string(), step_raw: z.string(), entity_id: z.string().nullable(), actor: z.enum(["담당자","팀장","외주","시스템"]), freq_per_week: z.number().int().nullable(), minutes_each: z.number().nullable(), tool: z.string().nullable() })
쉬운 데이터만 만들지 마세요. 다음 하드 케이스를 의도적으로 섞으세요(쉬운 문제만 푸는 함정 회피): (1) 같은 업무의 별칭 표기 혼입(step_raw ‘견적서 수기 작성’/‘견적 작성’ 이 entity_id e_quote 로 정규화돼야 함), (2) 미등록 개체(entity_id=null) 2~3건, (3) 결측. freq_per_week 또는 minutes_each 가 null 인 행 각 1~2건(빈도·소요시간 미입력), (4) 경계값 freq_per_week 0(중단된 업무)과 200 이상 극단 각 1건, tool=null 1~2건. 형식 깨뜨리기 시도 3건은 별도로. JSON 배열만 출력하세요.z.object({ step_id: z.string(), dept: z.string(), step_raw: z.string(), entity_id: z.string().nullable(), actor: z.enum(["담당자","팀장","외주","시스템"]), freq_per_week: z.number().int().nullable(), minutes_each: z.number().nullable(), tool: z.string().nullable() })업무 개체 표준 ID와 별칭·관계. 같은 업무가 ‘견적서 수기 작성/견적 작성’ 으로 들어오는 문제를 정규화하고, 마스터에 없는 신규 업무는 ‘미매핑’ 으로 알립니다.
| entity_id | canonical_name | aliases | category | relations |
|---|---|---|---|---|
| e_quote | 견적 작성 | ["견적서 수기 작성","견적 작성","견적서 작성"] | 문서작성 | ["e_settlement"] |
| e_cs_reply | 고객 문의 응대 | ["반복 문의 답변 복붙","문의 답변"] | 응대 | ["e_voc"] |
| e_inventory | 재고 수불 입력 | ["재고 입력","수불 입력"] | 입력반복 | ["e_delivery"] |
| e_tax_match | 세금계산서 대사 | ["세금계산서 대조","계산서 대사"] | 대조검수 | ["e_settlement"] |
| e_settlement | 월말 정산 마감 | ["정산 마감","월마감"] | 정산 | ["e_tax_match","e_quote"] |
아래 Zod 스키마에 맞는 ontology_entities 16행 JSON 배열로 생성하세요. 같은 개체가 별칭 2~3개를 가지도록.
z.object({ entity_id: z.string(), canonical_name: z.string(), aliases: z.array(z.string()), category: z.enum(["문서작성","대조검수","입력반복","응대","정산"]), relations: z.array(z.string()) })
조건: category 분포 자연스럽게, relations 는 다른 entity_id 0~2개. workflow_steps 의 step_raw 표기가 이 aliases 로 매핑되도록 맞추세요. JSON 배열만 출력하세요.z.object({ entity_id: z.string(), canonical_name: z.string(), aliases: z.array(z.string()), category: z.enum(["문서작성","대조검수","입력반복","응대","정산"]), relations: z.array(z.string()) })| LLM | 업무 단계를 개체·관계로 구조화하고 자동화 적합도·에이전트 작업 정의를 생성하는 본 엔진 |
| RAG | 고객사 업무 설명 문서를 검색해 진단 근거 문장을 인용하는 검색 계층(pgvector 임베딩 + 근거 chunk 인용 강제) |
| Python | ingest 파이프라인(업무 기록 → PostgreSQL upsert)과 진단 일치도 eval 스크립트를 돌립니다 |
| PostgreSQL | workflow_steps / ontology_entities / step_labels 단일 진실원과 pgvector 근거 인덱스를 둡니다 |
| Node.js | Next.js 진단 대시보드(업무 그래프 + 적용 지점 우선순위)를 띄웁니다 |
✓ pass → 그대로 멈춰도 완결입니다. 더 키우려면 2주차(진단이 타당한지 검증)로 진행합니다.
✓ pass → 여기서 멈춰도 완결입니다. 더 키우려면 3주차(멀티모달·다부서 확장)로 진행합니다.
1) 업무 단계의 개체·관계 구조화, 2) 자동화 적합도가 높은 약점 단계(근거 인용 포함), 3) 그 단계의 에이전트 작업 정의 초안. 진단에서 작업 정의까지 한 스키마에 담습니다.
z.object({ dept: z.string(), period: z.string(), structured_steps: z.array(z.object({ entity_id: z.string().nullable(), step_label: z.string(), weak_link: z.enum(["반복수작업","대기지연","휴먼에러","없음"]) })).min(1), opportunities: z.array(z.object({ entity_id: z.string(), automation_fit: z.enum(["high","mid","low"]), saved_min_per_week: z.number(), evidence_doc_ids: z.array(z.string()).min(1), hedge: z.string().min(8) })).min(1).max(3), agent_drafts: z.array(z.object({ entity_id: z.string(), task: z.string().min(12), guardrail: z.string().min(8) })).min(1).max(3) })[
{
"dept": "CS",
"period": "2026-05-04 ~ 2026-05-10",
"structured_steps": [
{
"entity_id": "e_cs_reply",
"step_label": "반복 문의 답변 복붙",
"weak_link": "반복수작업"
},
{
"entity_id": "e_voc",
"step_label": "VOC 분류 라벨링",
"weak_link": "반복수작업"
},
{
"entity_id": null,
"step_label": "신규 양식 업무(미등록)",
"weak_link": "없음"
}
],
"opportunities": [
{
"entity_id": "e_cs_reply",
"automation_fit": "high",
"saved_min_per_week": 600,
"evidence_doc_ids": [
"doc_cs_01",
"doc_cs_03"
],
"hedge": "주 200건 × 3분 합성 기준 추정이라 실제 문의 분포로 다시 맞춰야 합니다."
}
],
"agent_drafts": [
{
"entity_id": "e_cs_reply",
"task": "반복 문의를 분류해 템플릿 답변 초안을 생성하고 담당자 승인 후 발송",
"guardrail": "민감·환불 문의는 자동 발송 금지, 사람 검수로 라우팅"
}
]
},
{
"dept": "재무",
"period": "2026-05-04 ~ 2026-05-10",
"structured_steps": [
{
"entity_id": "e_tax_match",
"step_label": "세금계산서 대사",
"weak_link": "휴먼에러"
},
{
"entity_id": "e_settlement",
"step_label": "월말 정산 마감",
"weak_link": "대기지연"
}
],
"opportunities": [
{
"entity_id": "e_tax_match",
"automation_fit": "mid",
"saved_min_per_week": 120,
"evidence_doc_ids": [
"doc_fin_02"
],
"hedge": "표본 1개 문서 근거라 합성 기준 추정입니다. 실데이터 확인 필요."
}
],
"agent_drafts": [
{
"entity_id": "e_tax_match",
"task": "계산서와 장부를 대조해 불일치 건만 리스트업해 담당자에게 전달",
"guardrail": "금액 수정은 자동 반영 금지, 불일치 알림까지만"
}
]
}
]자동: (1) Zod parse, (2) evidence_doc_ids 가 실제 RAG 인덱스 문서 ID 에 존재하는지 인용 검증, (3) opportunities.entity_id 가 ontology_entities 에 존재하는지 미매핑 검사, (4) 단정 표현 토큰 검출 + LLM-as-judge 의미 평가. 수동: 현업 검토자 2명 비동기 라벨 후 bootstrap Cohen’s κ 하한 ≥ 0.6, judge 인간 spot-check 5%. saved_min_per_week 는 합성 기준 추정이라 실 업무 분포로 다시 맞춰야 합니다.