지니파이
경력근거: 모든 에이전트가 같은 최신 업무 맥락을 사용하며, 사용 결과가 다음 개선으로 이어지는 조직을 만듭니다.
※ 실제 산출물이 아닌 AI 예측 시안입니다.
지니파이는 모든 에이전트가 같은 최신 업무 맥락을 쓰고 사용 결과가 다음 개선으로 이어지는 조직을 만드는 것을 이 자리의 일로 적었습니다. 그래서 문서의 판과 실행 기록을 견주는 이 판정이 사내 AX 업무 자체이고, 에이전트를 몇 개만 쓰는 조직에서는 대장을 둘 이유가 없어 성립하지 않습니다. 다만 이 포트폴리오는 판 대조 규칙과 실행 결과를 보여줄 뿐, 지니파이 업무 도메인의 전문성은 주장하지 않습니다.
사내 팀을 고객으로 삼아 업무 현장에 들어가는 자리라, 외부 고객사를 발명하지 않고 지니파이 안의 업무 부서가 그대로 사용자가 됩니다.
업무 지식을 매일 수집해 에이전트가 함께 쓰는 SSOT 로 관리하는 것이 주요업무라, 문서의 판이 곧 에이전트의 답 품질을 정합니다.
사람의 수정과 사용 데이터를 AI 평가와 개선에 반영하는 고리를 만드는 자리라, 수정이 쌓이는 지점을 찾는 일이 업무 안에 있습니다.
사내 에이전트의 실행 기록을 업무 문서 대장과 견줘, 어느 실행이 지난 판을 보고 답했고 어느 문서가 대장에 없는지 판정해주는 CLI입니다.
지니파이 사내 AX 를 맡은 FDE 엔지니어입니다. 에이전트 답이 어긋난다는 말을 들을 때마다 문서를 하나씩 열어 보다가, 어느 문서의 판부터 손볼지 먼저 알고 싶습니다.
에이전트 답을 사람이 매번 고쳐 쓰는 이유는 문서가 갱신돼도 에이전트가 지난 판을 그대로 보고 있어서입니다. 실행이 쓴 문서 판을 대장의 현재 판과 견주면, 손볼 문서가 먼저 좁혀집니다.
실행 기록과 문서 대장을 넣고 명령을 한 번 실행하면 실행 14건이 네 판정으로 나뉘어 터미널에 뜨고, 각 줄에 실행이 쓴 판과 대장의 현재 판이 붙는 CLI입니다. 실행 기록은 지원자가 자기 에이전트를 며칠 돌려 만든 같은 모양의 로그로 시작합니다.
판정을 문서 기준으로 뒤집어, 오래된 판 참조가 많고 수정이 자주 붙는 문서 순으로 마크다운 보고서를 냅니다.
문서를 갱신한 뒤의 실행 기록을 함께 넣으면 오래된 판 참조와 수정 누적이 문서마다 얼마나 줄었는지 가려냅니다.
실행 기록과 문서 대장을 넣고 명령을 한 번 실행하면 실행 14건이 네 판정으로 나뉘어 뜨고, 담당자가 각 줄에서 실행이 쓴 판과 대장의 현재 판을 함께 읽습니다.
판 번호가 비었거나 수정 비율이 절반과 정확히 같거나 문서 키 표기가 흔들린 실행을 섞은 입력 30종을 넣어도 출력 형식이 안 깨집니다.
문서 키 표기를 정규화한 뒤 대장에 붙는 실행 비율을 실행 결과에 냅니다. 단, 정답과 데이터를 모두 작성자가 만든 합성 기준이라 성능 검증이 아니라 데모 조건에서의 동작입니다.
위 수치는 더미데이터 자가채점이며, 실제 맥락 정합 판정의 정확도는 지니파이 사내 실행 기록과 문서 대장이 있어야 측정됩니다. 이 포트폴리오는 그 검증을 바로 돌릴 수 있는 상태까지 만듭니다.
수치는 합성 데이터 자가채점이라 성능 증명이 아닙니다. 면접에서는 데모가 도는 상태와 실검증 준비 상태로 솔직히 설명합니다.
정답을 작성자가 만들었으니 잘 맞는 것이 당연합니다. 그래서 판 번호 결측, 절반과 정확히 같은 경계, 대장에 없는 문서 키, 표기 흔들림을 로그에 일부러 섞었습니다.
판이 지났다고 답이 틀린 것은 아닙니다. 바뀐 부분이 그 질문과 무관한 문서도 있으므로, 판정은 담당자가 먼저 열어 볼 문서를 정하는 데까지입니다.
실제 도입에서는 문서 키 체계와 판 번호 규칙이 지니파이가 실제로 쓰는 것으로 바뀌고, 판을 남기지 않는 에이전트도 있습니다. 실행 기록에 판 번호를 남기게 하는 일이 도입 단계 과제입니다.
① 인라인 샘플 · ② seed.json 다운로드 · ③ 증강 프롬프트. 세 층 모두 동일한 schema 에서 파생.
사내 에이전트가 남긴 실행 기록입니다. 읽기 좋게 한 주 분량으로 줄였고, 판 번호 결측과 대장에 없는 문서 키와 표기 흔들림을 일부러 섞었습니다. 지원자가 자기 에이전트를 며칠 돌리면 같은 모양의 기록이 나옵니다. doc_key 는 도구가 doc_key_raw 를 정규화해 채우는 칸이라 비워 두었습니다.
| run_id | agent_name | doc_key_raw | doc_version | ran_at | human_edited |
|---|---|---|---|---|---|
| GR-0001 | 견적봇 | onboarding-v | 12 | 2026-08-31T01:04:00Z | true |
| GR-0002 | 견적봇 | Onboarding-V | 12 | 2026-08-31T05:22:00Z | true |
| GR-0003 | 견적봇 | onboarding-v | 17 | 2026-09-01T02:41:00Z | false |
| GR-0004 | 채용봇 | hiring-faq | 5 | 2026-08-31T03:10:00Z | false |
| GR-0005 | 채용봇 | hiring-faq | 5 | 2026-09-01T06:35:00Z | false |
다음 JSON Schema 에 맞는 실행 기록 행을 더 만듭니다. {"type":"object","properties":{"run_id":{"type":"string"},"agent_name":{"type":"string"},"doc_key_raw":{"type":"string"},"doc_key":{"type":["string","null"]},"doc_version":{"type":["integer","null"]},"ran_at":{"type":"string"},"human_edited":{"type":["boolean","null"]}},"required":["run_id","agent_name","doc_key_raw","ran_at"]} 쉬운 데이터만 만들지 말 것. 다음 하드 케이스를 의도적으로 섞어라. 에이전트가 판 번호를 남기지 않아 doc_version 이 null 인 행 1~2건, 한 문서의 수정 비율이 정확히 절반이 되는 묶음 1건, doc_key_raw 에 대문자나 앞뒤 공백이 섞여 정규화가 필요한 행 1~2건, 문서 대장에 없는 키를 쓴 행 1~2건. 같은 문서를 여러 에이전트가 서로 다른 판으로 읽는 상황도 만든다. 그리고 doc_version 에 문자열을 넣거나 ran_at 을 비우는 형식 깨뜨리기 시도 3건을 따로 낸다. run_id 는 행마다 다른 값으로 쓴다.{"type":"object","properties":{"run_id":{"type":"string"},"agent_name":{"type":"string"},"doc_key_raw":{"type":"string"},"doc_key":{"type":["string","null"]},"doc_version":{"type":["integer","null"]},"ran_at":{"type":"string"},"human_edited":{"type":["boolean","null"]}},"required":["run_id","agent_name","doc_key_raw","ran_at"]}사내 업무 문서의 현재 판을 담은 대장입니다. 판정의 기준 판 번호는 전부 이 표에서 오고 실행 기록에는 들어 있지 않습니다. 실행이 쓴 문서 키가 여기 없으면 대장 미등록으로 걸립니다.
| doc_key | title | current_version | updated_at | owner_team | edit_alert_ratio |
|---|---|---|---|---|---|
| onboarding-v | 신규 입사자 온보딩 절차 | 17 | 2026-08-29 | 피플 | 0.5 |
| hiring-faq | 채용 문의 응대 기준 | 5 | 2026-07-11 | 피플 | 0.5 |
| cs-playbook | 고객 상담 운영 가이드 | 9 | 2026-08-20 | 운영 | 0.5 |
| study-guide | 스터디 운영 안내 | 21 | 2026-09-01 | 교육 | 0.5 |
| pricing-b2b | 기업 교육 가격 정책 | 8 | 2026-08-14 | 영업 | 0.4 |
다음 JSON Schema 에 맞는 문서 대장 행을 더 만듭니다. {"type":"object","properties":{"doc_key":{"type":"string"},"title":{"type":"string"},"current_version":{"type":"integer"},"updated_at":{"type":"string"},"owner_team":{"type":"string"},"edit_alert_ratio":{"type":"number"}},"required":["doc_key","title","current_version","updated_at","owner_team","edit_alert_ratio"]} 쉬운 데이터만 만들지 말 것. 문서마다 갱신 주기를 다르게 둔다. 자주 바뀌는 운영 문서는 current_version 을 크게 올리고 updated_at 을 최근으로, 오래 그대로인 문서는 반대로 둔다. 문구를 그대로 쓰는 문서는 edit_alert_ratio 를 높이고 규정 문서는 낮춘다. 실행 기록이 쓰는 키 중 최소 하나는 이 표에 넣지 않아 대장 미등록 판정이 실제로 걸리게 한다. 그리고 current_version 에 문자열을 넣거나 doc_key 를 비우는 형식 깨뜨리기 시도 3건을 따로 낸다.{"type":"object","properties":{"doc_key":{"type":"string"},"title":{"type":"string"},"current_version":{"type":"integer"},"updated_at":{"type":"string"},"owner_team":{"type":"string"},"edit_alert_ratio":{"type":"number"}},"required":["doc_key","title","current_version","updated_at","owner_team","edit_alert_ratio"]}| Python | 실행 기록을 문서 기준으로 묶고 대장과 견주는 판정 규칙을 씁니다. |
| SSOT | 업무 문서의 현재 판을 담는 대장을 설계하고, 실행이 쓴 판과 붙일 키를 정합니다. 공고가 말한 SSOT 관리에 해당합니다. |
| MCP | 에이전트가 문서를 읽을 때 판 번호를 함께 남기도록 실행 기록의 모양을 정합니다. |
| API | 판정 명령이 대장과 실행 기록을 받아 결과를 돌려주는 경로를 만들어, 다른 사내 도구가 같은 판정을 부를 수 있게 합니다. |
| LLM | 판정 사유를 담당자가 읽을 한 줄로 줄여 적습니다. 판정 자체에는 개입하지 않습니다. |
| JSON Schema | 실행 기록과 문서 대장의 모양을 고정해, 열이 빠진 파일을 넣었을 때 판정 대신 어느 줄이 왜 걸렸는지 알려 줍니다. |
✓ pass → 여기서 멈춰도 완결입니다. 더 키우려면 판정을 문서 기준으로 뒤집어 손볼 문서 순서를 냅니다.
✓ pass → 여기서 멈춰도 완결입니다. 더 키우려면 문서를 갱신한 뒤의 실행 기록과 견줘 실제로 줄었는지 봅니다.
실행 한 건마다 어떤 판정이 나왔고 실행이 쓴 판과 대장의 현재 판이 무엇인지 담습니다.
{"type":"object","properties":{"run_id":{"type":"string"},"agent_name":{"type":"string"},"doc_key":{"type":["string","null"]},"verdict":{"type":"string","enum":["current_context","stale_version","unregistered_doc","edit_pileup"]},"used_version":{"type":["integer","null"]},"current_version":{"type":["integer","null"]},"reason":{"type":"string"},"evidence":{"type":"array","items":{"type":"object","properties":{"field":{"type":"string"},"agg":{"type":"string"},"value":{}},"required":["field","value"]}}},"required":["run_id","agent_name","verdict","used_version","current_version","evidence"]}[
{
"run_id": "GR-0003",
"agent_name": "견적봇",
"doc_key": "onboarding-v",
"verdict": "current_context",
"used_version": 17,
"current_version": 17,
"reason": "문서 키 끝에 붙은 공백을 정규화해 대장에 붙였고, 실행이 쓴 판이 대장의 현재 판과 같습니다.",
"evidence": [
{
"field": "doc_version",
"value": 17
},
{
"field": "current_version",
"value": 17
}
]
},
{
"run_id": "GR-0014",
"agent_name": "교육봇",
"doc_key": "study-guide",
"verdict": "current_context",
"used_version": 21,
"current_version": 21,
"reason": "실행이 쓴 판이 대장의 현재 판과 같아 손볼 것이 없습니다.",
"evidence": [
{
"field": "doc_version",
"value": 21
},
{
"field": "current_version",
"value": 21
}
]
},
{
"run_id": "GR-0002",
"agent_name": "견적봇",
"doc_key": "onboarding-v",
"verdict": "stale_version",
"used_version": 12,
"current_version": 17,
"reason": "온보딩 절차가 다섯 판 갱신되는 동안 견적봇이 지난 판을 그대로 보고 답했습니다.",
"evidence": [
{
"field": "doc_version",
"value": 12
},
{
"field": "current_version",
"value": 17
}
]
},
{
"run_id": "GR-0013",
"agent_name": "교육봇",
"doc_key": "study-guide",
"verdict": "stale_version",
"used_version": null,
"current_version": 21,
"reason": "에이전트가 판 번호를 남기지 않아 최신 판을 봤다고 볼 근거가 없어, 지난 판 참조로 함께 셉니다.",
"evidence": [
{
"field": "run_id",
"value": "GR-0013"
},
{
"field": "current_version",
"value": 21
}
]
},
{
"run_id": "GR-0007",
"agent_name": "정산봇",
"doc_key": null,
"verdict": "unregistered_doc",
"used_version": 3,
"current_version": null,
"reason": "정산봇이 읽은 문서 키가 대장에 없습니다. 누가 관리하는 문서인지부터 정해야 합니다.",
"evidence": [
{
"field": "doc_key_raw",
"value": "settle-rule"
},
{
"field": "doc_version",
"value": 3
}
]
},
{
"run_id": "GR-0009",
"agent_name": "상담봇",
"doc_key": "cs-playbook",
"verdict": "edit_pileup",
"used_version": 9,
"current_version": 9,
"reason": "판은 최신인데 상담 가이드를 쓴 실행 넷 중 셋을 사람이 고쳐, 문서가 최신이어도 내용이 실제 업무와 어긋나 있습니다.",
"evidence": [
{
"field": "human_edited",
"agg": "count",
"value": 3
},
{
"field": "edit_alert_ratio",
"value": 0.5
}
]
}
][자동 검증 · 형식과 재계산] 1. verdict 는 current_context, stale_version, unregistered_doc, edit_pileup 네 값 안에 있습니다. 2. run_id, agent_name, verdict, used_version, current_version, evidence 여섯 필드가 모두 있습니다. 3. used_version 과 current_version 은 0 보다 크거나 null 입니다. 4. doc_key 가 null 이면 current_version 도 null 입니다. 5. evidence 의 field 값은 agent_runs 또는 ssot_docs 에 실재하는 컬럼명입니다. 집계 항목은 agg 를 적습니다. 6. evidence 의 집계가 아닌 value 는 두 표의 수록된 행에 있는 값 그대로입니다. 7. verdict 가 stale_version 이면 used_version 이 current_version 과 다르거나 used_version 이 비어 있습니다. 8. verdict 가 unregistered_doc 이면 doc_key 가 null 입니다. 9. verdict 가 edit_pileup 이면 그 문서를 쓴 실행 중 human_edited 가 참인 비율이 edit_alert_ratio 를 초과합니다. 10. 모든 한국어 문장은 존댓말로 끝납니다. [정상으로 처리한 하드 케이스] 1. GR-0006 은 수정 여부가 비어 있어 수정 비율 계산에서만 빠지고, 판이 최신이라 맥락 판정은 그대로입니다. 2. GR-0004 와 GR-0005 가 속한 채용 문의 기준은 수정 비율이 0 이라 경계 0.5 를 넘지 않아 수정 누적이 아닙니다. [평가 러너 · 2주차] 1. 문서를 갱신한 뒤의 실행 기록과 견줘 오래된 판 참조가 문서별로 얼마나 줄었는지 셉니다. 2. 수정 누적으로 판정한 문서의 내용을 고친 뒤 수정 비율이 내려갔는지 주 단위로 견줍니다.