오토메타
경력근거: 기관 업무 도메인 Ontology 설계 — 개념·관계·규칙 모델링, RDF/OWL·SPARQL 기반 지식그래프 구축
※ 실제 산출물이 아닌 AI 예측 시안입니다.
오토메타의 FDE 는 국방·정부·공공기관 AX 사업 현장에 상주해 기관 담당자와 요구사항을 정의하고, 업무 목록에 기관 업무 도메인 Ontology 설계와 RDF/OWL·SPARQL 기반 지식그래프 구축이 한 줄로 박혀 있습니다. 자사 플랫폼 Zenith AI 자체가 온톨로지 엔진 위에서 도는 제품이라, 현장에서 조항을 개념·관계로 옮기는 이 작업이 곧 제품에 되돌아가는 재료입니다. 조항이 그래프에 닿았는지를 세어 검수 전에 회의 안건으로 만드는 도구는 검수·납품 대응이 업무로 적힌 이 자리에서 바로 쓰입니다. 입력은 국가법령정보에 공개된 행정규칙 원문과 행정표준코드라 지원자가 직접 내려받아 만들 수 있습니다. 다만 이 포트폴리오가 보여주는 것은 규정 문장을 개념·관계로 옮겨 그래프 경로로 판정하는 기술이고, 국방·공공 사업의 규정 실무나 기관 보안 절차의 깊이는 주장하지 않습니다. 모르는 깊이는 면접에서 모른다고 말하는 편이 낫습니다.
공고는 데이터 분석·컨설팅만 맡는 사업, 기관 요구에 맞춘 소프트웨어 개발까지 맡는 사업, 자사 플랫폼 기반 RAG·Ontology·에이전트를 구축하는 사업을 직접 나눠 적습니다. 어느 쪽에 떨어져도 현장에서 발견한 요구를 본사 제품팀에 되돌려 보내는 일은 같다고 못박습니다.
기관 보유 문서·DB·시스템 로그를 정제해 RAG 파이프라인을 세우는 일과 개념·관계·규칙을 모델링해 지식그래프를 만드는 일이 같은 업무 목록에 나란히 있습니다. 우대에는 RDF/OWL·SPARQL·SHACL 과 Jena·Neo4j 가 이름으로 적혀 있습니다.
사용자 교육과 운영 가이드·기술 문서 작성, 검수·납품 대응이 주요업무 마지막 줄입니다. 답변 정확도·검색 품질 평가 체계를 세워 개선을 반복하라는 줄도 같이 있어, 만든 결과를 기관 담당자 앞에서 설명하는 자리까지가 이 직군의 일입니다.
공개 행정규칙에서 뽑은 조항 표와 지금까지 쌓은 개념·관계 표를 함께 올리면, 조항마다 상위개념을 타고 그래프 경로를 찾아 다섯 갈래 판정으로 나눠 보여줍니다. 검수를 앞두고 기관 업무 담당자와 나란히 앉아 보는 화면이고, 클로드는 판정이 끝난 조항에 담당자에게 물을 확인 질문 한 줄을 붙입니다.
기관 AX 사업 현장에 상주해 업무 도메인 온톨로지를 설계하는 FDE 엔지니어와 옆에 앉은 기관 업무 담당자 — 규정 몇 조가 아직 그래프에 안 올라갔는지 검수 전에 함께 짚어야 한다
검수에서 조항이 되돌아오는 이유는 온톨로지 설계가 틀려서가 아니라 어느 조항이 아직 그래프에 닿지 않았는지 세어 볼 방법이 없기 때문입니다. 조항의 주체어와 대상어를 개념 목록에 맞추고 상위개념을 타고 경로를 찾으면, 검수 전에 채울 조항과 이미 닿은 조항이 갈라집니다.
공개 행정규칙 4건에서 뽑은 조항 168건을 올리면 조항마다 판정과 근거를 붙여 다섯 갈래로 보여주는 화면 하나가 돕니다. 조항 표는 공개 규칙 본문을 조 단위로 잘라 만든 것으로 시작하고, HWP·PDF 원문을 그대로 넣는 파싱은 3주차로 미룹니다.
정답을 붙인 조항 90건으로 판정 일치도를 재고 어긋난 유형을 리포트로 냅니다. 2주차부터 AWS 로 배포해 함께 보는 사람이 링크만으로 같은 화면을 봅니다.
내려받은 HWP·PDF 규칙 원문을 넣으면 조 단위로 잘라 조항 표를 만들고, 화면에서 조항을 눌러 원문 문장을 같은 자리에서 봅니다. 확인 질문 목록은 검수 회의용 문서로 내려받습니다.
FDE 엔지니어가 조항 표와 개념·관계 표를 올리면 조항 168건이 다섯 갈래로 정리된 화면이 뜹니다.
기한값이 비어 있거나 개념명 칸이 빈 표 15종을 올려도 화면이 죽지 않고, 어느 조항이 왜 판정에서 빠졌는지 그 자리에서 읽습니다.
정답을 붙인 조항 90건으로 판정 일치율을 냅니다. 단, 조항 표와 정답을 모두 작성자가 만든 합성 기준이라 성능 검증이 아니라 데모 조건 동작입니다.
판정에 붙은 확인 질문을 모아 검수 회의 안건 문서로 내려받는 것을 시연합니다.
위 수치는 더미데이터 자가채점이며 실제 반영 판정의 정확도는 오토메타가 맡은 기관 사업의 실제 규정과 그 기관이 쓰는 개념 체계가 있어야 측정됩니다. 이 포트폴리오는 그 검증을 바로 돌릴 수 있는 상태로 만듭니다.
수치는 합성 데이터 자가채점이라 성능 증명이 아닙니다. 면접에서는 데모 동작과 실검증 준비 상태로 솔직히 설명합니다.
정답을 작성자가 만들었으니 잘 맞는 것이 당연합니다. 결측·악성·경계 케이스를 더미에 일부러 섞어 쉬운 문제만 푸는 함정을 피합니다.
개념이 그래프에 있다는 사실이 곧 조항을 옳게 옮겼다는 뜻은 아닙니다. 이름이 같아도 조문이 가리키는 대상은 다를 수 있어 판정 옆에 조항 원문을 항상 같이 둡니다.
실제 기관 규정은 한 조문 안에 단서와 예외가 겹쳐 조항 하나가 여러 관계로 갈라집니다. 조문을 절 단위로 나누는 규칙을 늘리는 일은 도입 단계 과제로 나눕니다.
기관 내부 문서와 시스템 로그는 반입 절차와 신원 확인을 거쳐야 볼 수 있어 이 포트폴리오의 범위 밖입니다. 여기서는 누구나 내려받는 행정규칙 원문과 행정표준코드로만 만듭니다.
① 인라인 샘플 · ② seed.json 다운로드 · ③ 증강 프롬프트. 세 층 모두 동일한 schema 에서 파생.
공개 행정규칙 4건을 조 단위로 옮긴 조항 표입니다. 판정 대상이며 기한이 걸리지 않은 조항은 기한값이 비어 있습니다.
| 조항ID | 조항문 | 주체어 | 대상어 | 기한값 | 시행일 |
|---|---|---|---|---|---|
| TRV-A12 | 국내출장은 소속 기관장의 승인을 받아 출장신청을 등록한다. | 기관장 | 출장신청 | — | 2025-01-01 |
| TRV-A19 | 숙박비는 정산담당관이 정산증빙을 확인한 뒤 지급한다. | 정산담당관 | 정산증빙 | — | 2025-01-01 |
| TRV-A24 | 출장신청은 부서장을 경유하여 제출한다. | 부서장 | 출장신청 | — | 2025-01-01 |
| TRV-A31 | 귀국 후 10일 이내에 여비정산을 마쳐야 한다. | 출장자 | 여비정산 | 10 | 2025-01-01 |
| TRV-A07 | 국외출장여비는 회계담당이 등급별 정액으로 지급한다. | 회계담당 | 국외출장여비 | — | 2025-01-01 |
아래 JSON Schema 에 맞는 조항 행을 더 만들어 주세요. {"type":"object","properties":{"조항ID":{"type":"string"},"조항문":{"type":"string"},"주체어":{"type":"string"},"대상어":{"type":"string"},"기한값":{"type":["integer","null"]},"시행일":{"type":"string"}},"required":["조항ID","조항문","주체어","대상어","시행일"]} 쉬운 데이터만 만들지 말 것 — 다음 하드 케이스를 의도적으로 섞어라: (1) 기한이 걸리지 않아 기한값이 null 인 조항, (2) 단서 절이 붙어 한 문장에 주체가 둘로 읽히는 조항, (3) 개념 목록에 아직 없는 낱말만 나오는 조항, (4) 시행일이 표준코드 고시일보다 앞선 조항. 조항ID 는 규칙 약칭과 조 번호를 이은 영문·숫자 문자열로 적고, 생성한 행은 반드시 위 스키마를 통과해야 하며, 형식을 깨뜨리는 시도는 별도로 3건만 표시해 두세요.{"type":"object","properties":{"조항ID":{"type":"string"},"조항문":{"type":"string"},"주체어":{"type":"string"},"대상어":{"type":"string"},"기한값":{"type":["integer","null"]},"시행일":{"type":"string"}},"required":["조항ID","조항문","주체어","대상어","시행일"]}지금까지 쌓은 개념 목록입니다. 조항의 주체어·대상어를 맞추는 상대 축이며 최상위 개념은 상위개념 칸이 비어 있습니다.
| 개념ID | 개념명 | 상위개념 | 출처조항ID |
|---|---|---|---|
| C-0101 | 출장신청 | 행정행위 | TRV-A12 |
| C-0102 | 기관장 | 직위 | TRV-A12 |
| C-0103 | 부서장 | 직위 | TRV-A24 |
| C-0104 | 출장자 | 직위 | TRV-A31 |
| C-0105 | 여비정산 | 행정행위 | TRV-A31 |
아래 JSON Schema 에 맞는 개념 행을 더 만들어 주세요. {"type":"object","properties":{"개념ID":{"type":"string"},"개념명":{"type":"string"},"상위개념":{"type":["string","null"]},"출처조항ID":{"type":["string","null"]}},"required":["개념ID","개념명"]} 쉬운 데이터만 만들지 말 것 — 다음 하드 케이스를 의도적으로 섞어라: (1) 최상위라 상위개념이 null 인 개념, (2) 어느 조항에서 왔는지 기록이 없어 출처조항ID 가 null 인 개념, (3) 상위개념을 두 단계 타고 올라가야 뿌리에 닿는 개념, (4) 이름이 비슷하지만 상위개념이 다른 개념 두 개. 개념ID 는 영문 한 글자와 네 자리 숫자를 이어 적고, 생성한 행은 반드시 위 스키마를 통과해야 하며, 형식을 깨뜨리는 시도는 별도로 3건만 표시해 두세요.{"type":"object","properties":{"개념ID":{"type":"string"},"개념명":{"type":"string"},"상위개념":{"type":["string","null"]},"출처조항ID":{"type":["string","null"]}},"required":["개념ID","개념명"]}개념 사이를 잇는 관계 목록입니다. 조항이 잇는 방향과 규칙 종류를 견주는 축이며 어느 조항에서 왔는지 적히지 않은 관계를 포함합니다.
| 관계명 | 시작개념ID | 끝개념ID | 규칙유형 | 근거조항ID |
|---|---|---|---|---|
| 승인 | C-0102 | C-0101 | 권한 | TRV-A12 |
| 경유 | C-0101 | C-0103 | 절차 | TRV-A24 |
| 정산 | C-0104 | C-0105 | 절차 | TRV-A31 |
| 지급 | C-0107 | C-0106 | 권한 | TRV-A07 |
| 등록 | C-0109 | C-0108 | 절차 | SVC-A03 |
아래 JSON Schema 에 맞는 관계 행을 더 만들어 주세요. {"type":"object","properties":{"관계명":{"type":"string"},"시작개념ID":{"type":"string"},"끝개념ID":{"type":"string"},"규칙유형":{"type":"string","enum":["권한","절차","기한","구조"]},"근거조항ID":{"type":["string","null"]}},"required":["관계명","시작개념ID","끝개념ID","규칙유형"]} 쉬운 데이터만 만들지 말 것 — 다음 하드 케이스를 의도적으로 섞어라: (1) 어느 조항에서 왔는지 적히지 않아 근거조항ID 가 null 인 관계, (2) 같은 개념 쌍을 반대 방향으로 이은 관계, (3) 규칙유형이 구조뿐이라 업무 규칙을 담지 않은 관계, (4) 조항에는 기한이 있는데 규칙유형이 절차로만 적힌 관계. 생성한 행은 반드시 위 스키마를 통과해야 하며, 형식을 깨뜨리는 시도는 별도로 3건만 표시해 두세요.{"type":"object","properties":{"관계명":{"type":"string"},"시작개념ID":{"type":"string"},"끝개념ID":{"type":"string"},"규칙유형":{"type":"string","enum":["권한","절차","기한","구조"]},"근거조항ID":{"type":["string","null"]}},"required":["관계명","시작개념ID","끝개념ID","규칙유형"]}공공데이터 행정표준코드를 옮긴 대조표입니다. 조항의 대상어가 표준 이름으로 서 있는지와 고시 시점을 견주며 적용 업무가 정해지지 않은 코드를 포함합니다.
| 코드값 | 코드명 | 적용업무 | 고시일 |
|---|---|---|---|
| TRV0301 | 국내출장여비 | 여비정산 | 2024-11-01 |
| TRV0302 | 국외출장여비 | 여비정산 | 2025-07-01 |
| TRV0401 | 출장신청 | 복무 | 2024-11-01 |
| SVC0101 | 복무상황 | 복무 | 2024-05-01 |
| SVC0102 | 연가신청 | 복무 | 2024-05-01 |
아래 JSON Schema 에 맞는 표준코드 행을 더 만들어 주세요. {"type":"object","properties":{"코드값":{"type":"string"},"코드명":{"type":"string"},"적용업무":{"type":["string","null"]},"고시일":{"type":"string"}},"required":["코드값","코드명","고시일"]} 쉬운 데이터만 만들지 말 것 — 다음 하드 케이스를 의도적으로 섞어라: (1) 적용 업무가 정해지지 않아 적용업무가 null 인 코드, (2) 조항 시행일보다 뒤에 고시된 코드, (3) 코드명이 조항의 낱말과 한 글자만 다른 코드, (4) 같은 업무에 코드가 둘로 나뉜 경우. 코드값은 영문 세 글자와 네 자리 숫자를 이어 적고, 생성한 행은 반드시 위 스키마를 통과해야 하며, 형식을 깨뜨리는 시도는 별도로 3건만 표시해 두세요.{"type":"object","properties":{"코드값":{"type":"string"},"코드명":{"type":"string"},"적용업무":{"type":["string","null"]},"고시일":{"type":"string"}},"required":["코드값","코드명","고시일"]}| Python | 조항 문장을 조 단위로 자르고 개념 목록과 맞추는 판정 엔진, 그래프 경로 탐색이 여기 있습니다. |
| TypeScript | 판정별 묶음과 조항 원문을 한 화면에 두는 관리자 페이지를 만듭니다. |
| RDF/OWL | 개념·관계·규칙을 저장하는 형식입니다. 상위개념을 타고 올라가는 판정이 이 구조에서 나옵니다. |
| SPARQL | 조항의 주체어에서 대상어로 가는 경로가 있는지 묻는 질의를 세 갈래로 나눠 던집니다. |
| RAG | 3주차에 조항 문장으로 비슷한 조항과 이전 사업의 개념 정의를 찾아 검수 질문 초안에 붙입니다. |
| LLM | 판정이 끝난 조항에 기관 담당자에게 물을 확인 질문 한 줄을 씁니다. |
| REST | 화면과 판정 엔진 사이를 잇고, 조항 표와 개념 표를 올리는 통로입니다. |
| SQL | 조항·개념·관계·표준코드 네 표를 담고 판정 이력을 회차별로 남깁니다. |
| Docker | 판정 엔진과 그래프 저장소를 한 묶음으로 띄워 기관 인수인계 때 그대로 넘깁니다. |
| Kubernetes | 3주차에 그 묶음을 매니페스트로 옮겨 여러 사업 인스턴스를 한 클러스터에서 굴립니다. |
| AWS | 2주차부터 배포·운영을 맡습니다. 조항 표와 판정 이력을 RDS 에 두고 원문 파일은 S3 에 남깁니다. |
| Linux | 조항 파서와 평가 러너를 돌리는 실행 환경이고 로그도 여기서 봅니다. |
✓ pass → 그대로 멈춰도 완결입니다. 더 키우려면 판정이 실제로 맞았는지 정답 조항과 맞춰 보는 단계로 넘어갑니다.
✓ pass → 여기까지도 완결입니다. 더 키우려면 규칙 원문 파일을 그대로 넣어 조항 표를 만드는 단계로 확장합니다.
위 예측 UI 는 3주차까지 완주했을 때의 화면입니다. 1주차에 실제로 만드는 것은 아래 표시된 화면 하나입니다.
verdict사유 라벨 · clause_id + 한 줄 요약(근거 수치 포함)화면·코드·면접에서 이 단어를 그대로 씁니다. 키는 출력 스키마의 enum 과 같습니다.
그래프 반영됨반영 완료개념 없음개념 누락관계 어긋남관계 불일치기한 규칙 누락기한 규칙 없음표준코드 불일치표준코드 불일치조항 하나가 그래프에 어디까지 닿았는지를 판정과 근거로 남기는 형식입니다. 판정은 규칙이 정하고 확인 질문만 모델이 씁니다.
{"type":"object","properties":{"review_id":{"type":"string"},"clause_id":{"type":"string"},"verdict":{"type":"string","enum":["그래프 반영됨","개념 없음","관계 어긋남","기한 규칙 누락","표준코드 불일치"]},"missing_concept":{"type":["string","null"]},"evidence":{"type":"array","items":{"type":"object","properties":{"table":{"type":"string","enum":["reg_clauses","onto_nodes","onto_edges","biz_code_std"]},"field":{"type":"string"},"agg":{"type":["string","null"]},"value":{"type":["string","integer","null"]}},"required":["table","field","value"]}},"summary":{"type":"string"},"check_question":{"type":["string","null"]}},"required":["review_id","clause_id","verdict","evidence","summary"]}[
{
"review_id": "RV-0001",
"clause_id": "TRV-A12",
"verdict": "그래프 반영됨",
"missing_concept": null,
"evidence": [
{
"table": "reg_clauses",
"field": "주체어",
"value": "기관장"
},
{
"table": "onto_nodes",
"field": "개념명",
"value": "기관장"
},
{
"table": "onto_edges",
"field": "관계명",
"value": "승인"
},
{
"table": "reg_clauses",
"field": "기한값",
"value": null
}
],
"summary": "기관장과 출장신청이 개념으로 서 있고 승인 관계도 조항이 잇는 방향 그대로입니다.",
"check_question": null
},
{
"review_id": "RV-0002",
"clause_id": "SVC-A11",
"verdict": "그래프 반영됨",
"missing_concept": null,
"evidence": [
{
"table": "reg_clauses",
"field": "기한값",
"value": 5
},
{
"table": "onto_edges",
"field": "규칙유형",
"value": "기한"
},
{
"table": "onto_edges",
"field": "근거조항ID",
"value": "SVC-A11"
}
],
"summary": "연가신청 5일 기한이 기한 규칙으로 올라가 있어 조항이 그래프에 닿았습니다.",
"check_question": null
},
{
"review_id": "RV-0003",
"clause_id": "TRV-A19",
"verdict": "개념 없음",
"missing_concept": "정산담당관, 정산증빙",
"evidence": [
{
"table": "reg_clauses",
"field": "주체어",
"value": "정산담당관"
},
{
"table": "reg_clauses",
"field": "대상어",
"value": "정산증빙"
},
{
"table": "onto_nodes",
"field": "개념명",
"agg": "count",
"value": 0
}
],
"summary": "정산담당관과 정산증빙이 개념 목록에 서 있지 않아 조항이 그래프에 닿지 않았습니다.",
"check_question": "정산증빙을 별도 개념으로 세울지, 여비정산의 하위로 둘지 정해 주실 수 있을까요?"
},
{
"review_id": "RV-0004",
"clause_id": "TRV-A24",
"verdict": "관계 어긋남",
"missing_concept": null,
"evidence": [
{
"table": "reg_clauses",
"field": "주체어",
"value": "부서장"
},
{
"table": "reg_clauses",
"field": "대상어",
"value": "출장신청"
},
{
"table": "onto_edges",
"field": "시작개념ID",
"value": "C-0101"
},
{
"table": "onto_edges",
"field": "끝개념ID",
"value": "C-0103"
}
],
"summary": "조항은 부서장에서 출장신청으로 잇는데 그래프의 경유 관계는 반대 방향으로 서 있습니다.",
"check_question": "경유를 신청 흐름의 방향으로 볼지, 결재선의 방향으로 볼지 확인 부탁드립니다."
},
{
"review_id": "RV-0005",
"clause_id": "TRV-A31",
"verdict": "기한 규칙 누락",
"missing_concept": null,
"evidence": [
{
"table": "reg_clauses",
"field": "기한값",
"value": 10
},
{
"table": "onto_edges",
"field": "근거조항ID",
"value": "TRV-A31"
},
{
"table": "onto_edges",
"field": "규칙유형",
"value": "절차"
}
],
"summary": "귀국 후 10일이라는 기한이 조항에 있는데 이 조항을 근거로 삼은 관계는 절차 하나뿐입니다.",
"check_question": "10일을 달력 기준으로 셀지 근무일 기준으로 셀지 알려 주시면 규칙으로 옮기겠습니다."
},
{
"review_id": "RV-0006",
"clause_id": "TRV-A07",
"verdict": "표준코드 불일치",
"missing_concept": null,
"evidence": [
{
"table": "reg_clauses",
"field": "대상어",
"value": "국외출장여비"
},
{
"table": "biz_code_std",
"field": "코드값",
"value": "TRV0302"
},
{
"table": "biz_code_std",
"field": "고시일",
"value": "2025-07-01"
},
{
"table": "reg_clauses",
"field": "시행일",
"value": "2025-01-01"
}
],
"summary": "국외출장여비 표준코드가 조항 시행일보다 뒤에 고시돼 지금 코드로는 조문과 맞지 않습니다.",
"check_question": "시행일 당시 쓰던 코드가 따로 있었는지 담당 부서에 확인해 주실 수 있을까요?"
}
][자동 검증 · 코드가 판정합니다] 1. verdict 가 다섯 값 중 하나인지 확인합니다. 2. review_id·clause_id·verdict·evidence·summary 가 모두 들어 있는지 확인합니다. 3. 기한값이 1 이상 365 이하 범위에 드는지 확인합니다. 4. 주체어·대상어를 개념명과 맞추고, 조항이 잇는 방향을 시작개념ID·끝개념ID 와 견주며, 기한값이 있는 조항에 규칙유형이 기한인 관계가 붙었는지와 대상어의 코드명 고시일이 시행일보다 뒤인지를 다시 계산해 판정이 규칙 그대로 나왔는지 확인합니다. 5. evidence 의 field 가 네 데이터셋에 실재하는 컬럼인지 대조합니다. 6. evidence 의 value 가 그 컬럼의 수록된 행 값과 같은지 확인합니다. 7. summary 가 존댓말 한 문장인지 확인합니다. 8. 조건 규칙 — 조항의 기한값이 비어 있으면 기한 규칙 누락 판정을 하지 않습니다. RV-0001 이 조건이 성립한 사례이고 RV-0005 가 성립하지 않은 사례입니다. 9. 판정은 개념 없음, 관계 어긋남, 기한 규칙 누락, 표준코드 불일치 순으로 먼저 걸리는 갈래를 쓰고 하나도 걸리지 않으면 그래프 반영됨으로 적습니다. [평가 러너 · 2주차] 1. 정답을 붙인 조항 90건과 판정을 맞춰 일치율을 냅니다. 2. 개념 이름을 두 글자만 바꾼 조항 20건을 넣어 판정이 뒤집히는 지점을 찾습니다. [수동 검증 · 사람이 봅니다] 1. 이름이 같아도 조문이 가리키는 대상이 다른 경우가 있는지 기관 담당자와 표본 20건을 함께 읽습니다. 2. 확인 질문이 회의에서 그대로 물어도 되는 문장인지 FDE 엔지니어가 읽어 봅니다.
근거: 기관 업무 도메인 Ontology 설계 — 개념·관계·규칙 모델링, RDF/OWL·SPARQL 기반 지식그래프 구축