Orbit · 가이드 · Chapter 14
Field
업무 궤적의 공간
워크플로 실행 엔진이 아니라, 흩어진 데이터가 업무 맥락 안에서 의미를 갖게 하는 버전 있는 업무 그래프 정의.
Section 01
한 장면 — 금요일 오후의 부가세 신고
개념을 먼저 풀기 전에 한 장면부터 봅니다. 재무팀 민지의 4월 마지막 주, Q1 부가세 신고 마감을 사흘 앞둔 시점입니다.
ERP 매출 자동 동기화가 전날까지의 매출 행을 보낸다.
전자세금계산서 연동이 매입 세금계산서 2건 미수신 이벤트를 띄운다.
세무대리인이 Slack에 "대사표 먼저, 차이 원인 같이"라고 남긴다.
문서함에 대사표 초안이 올라오지만 차이 원인 칸이 비어 있다.
팀장이 묻는다. "지금 막힌 게 뭐야?"
16:10의 그 한마디가 핵심입니다. Field가 없는 회사라면 민지는 다섯 화면을 다시 열어야 합니다 — ERP, 전자세금계산서, Slack, 문서함, 결재 시스템. 한 시간이 지나서야 답에 도달합니다.
Field가 있는 회사라면 같은 화면 하나에 이미 답이 떠 있습니다:
이 차이를 만든 것은 도구의 가짓수가 아닙니다. 같은 데이터들이 같은 업무 맥락으로 묶였느냐 아니냐입니다. ERP 매출 행은 혼자 있을 때 매출 데이터지만, "Q1 부가세 신고" 안에서는 세액 계산의 입력이 됩니다.
Section 02
Field가 무엇인가
Field는 워크플로 도구의 "프로세스 템플릿"과 비슷해 보이지만, 강조점이 다릅니다. 워크플로의 중심은 실행 순서입니다 — 1번 다음 2번, 그다음 3번. Field의 중심은 업무 맥락입니다.
같은 PDF 업로드도 Tax Field 안에서는 신고 증빙이고, Contract Field 안에서는 계약 검토 자료이며, HR Field 안에서는 민감정보가 됩니다. Field는 그 사건이 어느 업무 장면에서 의미를 갖는지를 정합니다.
자기장과 철가루. 자기장 안에 철가루를 뿌리면 안 보이던 힘의 선이 드러납니다. Field도 같습니다. 매출 행, 세금계산서, 계약서, 승인 로그, 제출확인서는 원래 다른 시스템에 흩어진 철가루입니다. "부가세 신고"라는 Field 안에 들어와야 비로소 자료 수집 → 대사 → 검토 → 승인 → 제출이라는 궤적으로 보입니다.
정확한 정의: Field는 특정 업무 맥락 안에서 여러 개체와 이벤트가 하나의 궤적으로 정렬되는 장입니다. 시작과 끝, 기준 개체, 자료 연결, 필요한 증거 자리, 단계와 상태를 가진 버전 있는 업무 정의입니다.
| 구분 | Workflow | Field |
|---|---|---|
| 중심 | 실행 순서 (1→2→3) | 업무 맥락과 궤적 |
| 같은 파일이 | 항상 같은 단계의 입력 | 맥락에 따라 의미가 달라짐 |
| 상태 표현 | "검토 중" 라벨 하나 | 근거 기반의 복합 상태 |
| 반복 자산 | 없음 (매번 처음부터) | Field Memory로 축적 |
반복되는 업무 타입(예: Tax Field)은 하나의 정의로 굳고, 그 정의가 특정 기간·법인에 열리면 실제 업무 건(예: 2026 Q1 KR 부가세 신고)이 됩니다.
Section 03
Field를 만드는 다섯 가지
Field가 "현재 상태를 계산할 수 있는 장"이려면 다섯 가지가 정해져 있어야 합니다. 외울 목록이 아니라, 새 Field를 설계할 때 던지는 다섯 질문입니다.
시작과 끝 조건
Q1 부가세 신고는 분기 시작에 열려서 외부 접수 확인이 들어오는 순간 닫힙니다. 이 경계가 흐릿하면 같은 업무가 두 건으로 잡히거나 끝났는데 안 끝난 것처럼 남습니다.
기준 개체 (Anchor)
같은 부가세 신고도 법인과 기간이 다르면 별개 업무입니다. KR 법인 + 2026 Q1 + 세무 관할이 묶여야 한 건이 고정됩니다.
자료 연결 규칙
어떤 시스템에서 어떤 이벤트가 들어와 어느 증거 자리를 채우는지를 정합니다. 규칙이 없으면 자료가 들어와도 어느 업무에 속하는지 모릅니다.
필요한 증거 자리
"파일이 있다"와 "다음 단계로 넘어갈 근거가 된다"는 다릅니다. 대사표 한 장이 통과하려면 기간·법인·합계·차이 금액이 모두 있어야 합니다.
현재 상태 묶음
Field의 현재 상태는 "검토 중" 한 문자열이 아니라, 준비된 증거·막힌 이유·현재 단계·승인 경계가 합쳐진 결과입니다.
| 자료 연결 규칙 | 들어오는 데이터 | 채우는 증거 자리 |
|---|---|---|
| ERP 매출 동기화 | 매출 row, invoice | 매출 입력 |
| 전자세금계산서 | 발행/수취 세금계산서 | 발행 / 매입 세금계산서 |
| 은행 내역 동기화 | 입출금 내역 | 입출금 확인 |
| 문서 업로드 | 대사표, 신고서 | 대사표 / 제출확인서 |
| 승인 로그 | 팀장·본부장 승인 | 관리자 승인 |
좋은 Field는 "예쁜 절차"가 아닙니다. 좋은 Field는 현재 상태를 근거로 계산할 수 있는 Field입니다. "대사표 준비됨 · 매입 2건 누락 · 차이 원인 설명 누락 · 본부장 승인 시작 전"처럼 근거로 쪼개져야 Sentinel과 Agent와 사람이 같은 상태를 봅니다.
Section 04
후보 · 정의 · 실행 · 화면
Field가 어렵게 들리는 가장 큰 이유는 한 단어가 네 가지를 동시에 가리키기 때문입니다. 아직 발견된 후보인지, 승인된 정의인지, 실제로 열린 한 건인지, 사람이 보는 화면인지를 먼저 갈라야 합니다.
| 단계 | 뜻 | 잘못 섞으면 |
|---|---|---|
| Field 후보 | 반복 패턴이 관찰된 단계. 아직 공식 업무는 아님 | 나쁜 우회 절차까지 공식처럼 보임 |
| Field 정의 | 승인된 버전 있는 업무 정의 (Tax Filing v3) | "그때 기준이 뭐였나" 재현 불가 |
| 실제 업무 건 | 특정 기간·법인에 대해 열린 한 건 | 실행 지연과 정의 결함을 구분 못함 |
| 사람이 보는 화면 | 정의+실행+근거+정책을 합친 뷰 | 화면 요약을 원본 기록처럼 착각 |
Field 정의는 버전이 있는 계약입니다. v3에서 증거 자리가 하나 추가되거나 v4에서 일본 법인용 변형이 생겨도, 이미 진행 중인 업무 건이 자동으로 바뀌면 안 됩니다. 시작 당시의 정의를 고정해야 1년 뒤 같은 결과를 다시 만들 수 있습니다.
반복된다고 좋은 업무는 아닙니다. 잘못된 우회, 비공식 승인, 누락된 검토도 똑같이 반복됩니다. 후보 발견은 "자주 일어난다"를 보여줄 뿐, 공식 업무로 인정할지는 사람이 판단합니다. Orbit은 나쁜 습관까지 자동으로 업무화하지 않습니다.
Section 05
Micro Field와 Process Graph
Field 전체를 한 번에 자동화하려는 시도는 거의 실패합니다. 부가세 신고 안에는 자료 수집·대사·검토·세무 판단·승인·외부 제출이 섞여 있습니다. 어떤 단계는 자동화가 쉽고, 어떤 단계는 전문가 판단이 필요합니다.
그래서 Orbit에서 자동화의 실제 단위는 Field 전체가 아니라 Micro Field — Field 안의 반복 가능한 단계 정의입니다.
Micro Field의 다섯 자리
필요 자료
시작 전 필요한 근거와 자원
사람
담당자 · 검토자 · 승인자
기준
정책 · 검증 규칙
도구
ERP · 외부 연동 · 문서 도구
산출물
다음 단계가 쓰는 결과
다섯 자리 중 하나라도 비면 단계는 준비 전 상태에 머무릅니다. 다 채워지면 준비됨이 되고, 담당자가 손을 대면 작업 중, 산출물의 통과 기준을 만족하면 완료가 됩니다.
| Micro Field 예 | 자동화 가능성 | 이유 |
|---|---|---|
| 세금계산서 수집 | 높음 | 자료 연결과 증거 자리가 명확 |
| ERP 대사표 생성 | 중간 | 계산 규칙 분명하면 자동 초안 가능 |
| 차이 원인 검토 | 중간 | 후보를 제시하고 사람이 확인 |
| 세무 리스크 판단 | 낮음 | 정책·예외가 많아 사람 영역 |
| 최종 외부 제출 | 낮음 | Authority 승인 + trace 필요 |
Process Graph
Micro Field들이 어떻게 연결되는지를 그린 것이 Process Graph입니다. 중요한 것: Process Graph는 실행 엔진이 아닙니다 — 지하철 노선도가 열차를 움직이지 않듯, Process Graph도 업무를 굴리지는 않습니다.
대신 "원래 어떻게 흘러야 하는가(기대 흐름)"와 "이번엔 어떻게 흘렀는가(실제 기록)"를 비교할 기준선이 됩니다.
모든 이탈이 위반은 아닙니다. 기대 흐름과 다르게 흘렀다고 해서 곧 정책 위반은 아닙니다. 검토를 건너뛴 일이 허용된 예외일 수도 있고, 단순히 기록이 빠진 것일 수도 있습니다. Process Graph의 결과는 판결이 아니라 원인 분석의 시작점입니다.
Section 06
품질 4축과 운영 연결
Field가 잘 만들어졌는지 어떻게 판단하는가. 품질의 4축은 점수표가 아니라 처방전입니다. "Field 품질이 낮다"는 말만으로는 어디를 고쳐야 할지 모릅니다. 어느 축이 낮은지에 따라 손볼 레이어가 달라집니다.
| 축 | 묻는 질문 | 낮을 때 고칠 곳 |
|---|---|---|
| 적합도 | 실제 업무가 정의된 경로로 설명되는가? | 기대 흐름이나 단계 이름을 다시 잡는다 |
| 정밀도 | 관련 없는 이벤트가 붙지 않는가? | Field 경계를 좁힌다 |
| 일반화 | 새 케이스도 같은 정의로 설명되는가? | 국가·팀별 변형을 추가한다 |
| 단순성 | 사람이 5분 안에 설명할 수 있는가? | Field를 분리하거나 단계를 병합한다 |
Field Memory — 실행될수록 자라는 자산
Field는 한 번 실행되고 끝나지 않습니다. Q1 신고가 마무리되면 어떤 증거가 늦게 채워졌는지, 어느 단계가 다시 열렸는지, 어떤 승인자가 병목이었는지가 Field Memory로 남습니다.
Q2 신고가 열릴 때 Orbit은 이 기억을 읽고 "지난번엔 대사표가 늦었습니다. 이번엔 D-5에 미리 요청하세요"라고 제안할 수 있습니다. Field는 실행될수록 회사 고유의 운영 자산을 만듭니다.
다른 사전과의 합류
Field Dictionary는 다른 네 사전이 합류하는 자리입니다.
| 사전 | 역할 |
|---|---|
| Entity Dictionary | 누가 있는지 정한다 |
| Term Dictionary | 무엇이라 부르는지 정한다 |
| Decision Dictionary | 어떻게 판단하는지 정한다 |
| Policy Dictionary | 무엇을 허용·금지하는지 정한다 |
| Work (Field) Dictionary | 이 넷을 한 업무 궤적 위에 배치한다 |
Field가 약하면 다른 사전들도 따로 떠다닙니다. Entity는 있지만 어느 업무에 관여하는지 모르고, Policy는 있지만 어느 단계에서 적용되는지 모릅니다. Field는 사전들이 업무 궤적 위에서 만나는 접점입니다.