Orbit · 가이드 · Dictionary
Dictionary
업무 기준 사전
Field가 업무의 공간이라면, Dictionary는 그 공간 안에서 무엇을 기준으로 판단하는가를 정의하는 살아있는 사전입니다.
Section 01
Dictionary가 필요한 순간
재무팀은 "매출"이라고 쓰고, 영업팀은 "sales"라고 쓰고, 대표는 "수입"이라고 묻습니다. CRM에 "Acme Corp", ERP에 "(주)에이씨엠이코리아", Slack에 "#acme-team" — 전부 같은 회사지만, 시스템 입장에서는 서로 다른 문자열입니다.
AI가 데이터를 읽어 후보를 만들 때, 기준이 없으면 매번 다른 답이 나옵니다. 어제의 "매출"과 오늘의 "매출"이 같은 정의인지, 이 "Acme"가 저 "에이씨엠이"와 같은 법인인지 알 수 없습니다.
Dictionary는 억지로 하나의 단어로 바꾸는 곳이 아닙니다. 지금 열린 업무 맥락에서 어떤 말은 같은 뜻으로 묶고, 어떤 말은 비슷해 보여도 분리해야 하는지 정하는 회사 기준의 공식 자리입니다.
Dictionary가 있으면 Orbit의 모든 레이어 — Conductor, Sentinel, Protocol, Bridge — 가 같은 기준으로 같은 업무를 읽습니다. Dictionary가 없으면 각 레이어가 제각기 해석하고, 결과가 흔들립니다.
Section 02
다섯 종류의 사전
Orbit의 Dictionary는 하나의 거대한 용어집이 아닙니다. 각각 다른 질문에 답하는 다섯 개의 전문 사전이며, 다섯이 모여 회사의 기준선을 이룹니다.
누구인가, 무엇인가
Entity Dictionary
사람·팀·거래처·계약·법인을 하나의 canonical_ref로 잡습니다. 핵심은 더 많이 등록하는 게 아니라 같은 것은 같게, 다른 것은 다르게 유지하는 것입니다. CRM의 "Acme Corp"와 ERP의 "(주)에이씨엠이"가 같은 개체임을 한 곳에서 확정합니다.
뭐라고 부르는가
Term Dictionary
같은 대상을 canonical term으로 일관되게 부릅니다. 부서별·맥락별 alias를 관리하고 다의어·동음이의어를 구분합니다. 재무팀의 "매출"과 영업팀의 "sales"는 묶고, "수익"은 다른 말로 갈라냅니다.
뭘 보고 판단하는가
Judgment Dictionary
프롬프트 편집기가 아니라 판단 계약 편집기입니다. 무슨 말을 시킬지가 아니라 어떤 맥락을 읽게 할지 정합니다. 답변 형식과 피드백이 다음 Version 후보로 이어지는 기준도 함께 둡니다.
어떤 규칙이 적용되는가
Policy Dictionary
의무·금지·승인 조건·SLA·incident rule을 다룹니다. 정책은 사용자를 막는 순간에 신뢰를 잃기 쉽습니다. 그래서 근거·책임자·해결 경로가 함께 보여야 합니다.
어떤 궤적이 있는가
Field Dictionary
Field의 정의 자체를 다루는 사전입니다. 업무의 시작과 끝, 거쳐야 할 단계, 증거가 놓일 자리를 둡니다. 한 건이 어떤 상태를 지나 어떻게 흘러야 하는지 규정합니다.
Section 03
Candidate에서 Verified로 — 생애주기
모든 Dictionary 항목은 처음부터 공식이 아닙니다. 모든 기준은 후보에서 출발해, 사람의 승인을 거쳐야 비로소 조직의 기준이 됩니다.
이 생애주기가 중요한 이유는 AI가 스스로 기준을 만들지 못하게 하기 위해서입니다. AI는 후보를 제안할 수 있지만, 그것이 공식 기준이 되려면 반드시 사람의 승인을 거칩니다. 확정된 기준도 영원하지 않아서, 더 이상 쓰지 않는 기준은 폐기(Deprecated)로 표시되어 새 업무에는 적용되지 않지만 과거 건은 그대로 보존됩니다.
승인된 것만 다음 기준이 됩니다. 같은 수정이 반복되면 Bridge가 후보로 올립니다. 하지만 후보가 자동으로 기준이 되지는 않습니다. 나쁜 습관도 반복됩니다 — 그래서 사람의 판단이 필요합니다.
Section 04
각 사전의 역할
다섯 사전은 평등하게 나열되지 않습니다. 서로를 떠받치는 순서가 있고, 그 순서가 업무를 읽는 방식을 결정합니다.
Entity Dictionary는 모든 사전의 기반입니다. "누구/무엇"이 식별되지 않으면 "그 대상에 대한 규칙"도 적용할 수 없기 때문입니다.
Policy Dictionary는 금요일 오후, 재무 담당자가 버튼을 누르는 순간에 작동합니다. 문서 속 규정을 실행 화면 위의 다음 행동(실행/승인 요청/차단/경고/감사 기록)으로 바꾸는 운영 안전장치입니다.
Decision Dictionary는 반복되는 판단을 기록합니다. 같은 상황에서 지난번에는 어떤 근거로 어떤 결론을 내렸는지, 그래서 이번에도 같은 기준을 적용할 수 있는지를 확인합니다.
Section 05
Dictionary와 Field의 만남
Field가 "업무의 공간"이고 Dictionary가 "기준의 정의"라면, 실제 운영은 이 둘이 만나는 지점에서 한 단계씩 일어납니다.
Field가 열린다
"2026 Q1 KR 부가세 신고"라는 업무 건이 시작됩니다. Field Dictionary의 Tax Filing v3 정의가 적용됩니다.
Entity가 식별된다
관련 법인(KR Entity), 거래처(Acme Corp), 담당자(민지)가 Entity Dictionary로 정체성을 확인합니다.
Term으로 언어를 통일한다
들어오는 데이터의 "매출", "sales", "수입"이 같은 Term으로 매핑되어 일관된 계산이 가능해집니다.
Policy가 경계를 설정한다
어느 단계에서 누구의 승인이 필요한지, 무엇이 금지되는지 Policy Dictionary가 실행 경계를 제공합니다.
Decision이 판단을 기록한다
사람이 내린 판단(승인/반려/예외)이 Decision Dictionary에 남아 다음 건의 참고 자료가 됩니다.
Dictionary가 없으면 Field는 빈 그릇입니다. 데이터가 들어와도 무엇이 같은 대상인지, 어떤 말이 같은 뜻인지, 무엇이 허용되는지 모릅니다. Dictionary가 있어야 Field 안의 데이터가 업무 궤적으로 읽힙니다.
그리고 이 과정이 반복될수록 Dictionary 자체가 성장합니다. Q1 신고에서 발견된 새로운 판단 기준은 Q2 신고에서 적용됩니다. 회사가 운영될수록 기준이 정확해지는 구조입니다.