온톨로지는 업무의 뜻과 관계를 정합니다
온톨로지[1]는 회사·계약·청구 같은 개념과 그 속성, 서로의 관계를 명시한 모델입니다. 업무에서 쓰는 말에 뜻과 연결 규칙을 붙이는 일로 이해할 수 있습니다. W3C의 OWL 설명도 용어의 의미와 관계를 다루며, 데이터베이스 자체와는 구분합니다.
예를 들어 ‘계약은 회사와 체결한다’와 ‘청구 건에는 납부할 회사가 연결된다’는 서로 다른 관계입니다. 한 회사가 두 역할을 맡을 수도 있고, 계약사 A와 납부사 B가 다를 수도 있습니다. 역할을 나눈다고 회사 정보를 무조건 두 개로 복제하는 것은 아닙니다.
AI가 청구 대상을 제대로 고르려면, 프로그램에서 가져온 자료에 계약사와 납부사가 구분돼 있어야 합니다. AI에게 주는 지시에도 어느 회사를 청구 대상으로 삼을지 적어야 합니다. 용어를 정리한 문서만 고쳐서는 기존 AI 업무가 바뀌지 않습니다.
계약사는 A, 납부사는 B인 가상 사례입니다. 두 역할을 나눠 기록해야 AI가 청구 안내의 수신처를 구분할 수 있습니다.
이름만 바뀌었나요, 의미가 바뀌었나요?
표시 이름을 바꾸는 경우
화면의 ‘거래처’를 ‘계약사’로 바꿔도 같은 회사를 같은 용도로 가리킨다면 표시 변경일 수 있습니다. 다만 연결 프로그램이 필드 이름을 직접 사용했다면 이름 변경도 점검해야 합니다. 이름만 바꾸는지, 저장할 항목도 바꾸는지, 그 항목이 뜻하는 업무까지 바꾸는지 개발자가 구분해서 확인해야 합니다. 저장 항목과 형식을 정한 명세를 스키마[2]라고 합니다.
계약사와 납부사를 구분하는 경우
청구 안내 초안을 만드는 가상 사례입니다. 과거에는 ‘거래처’에 계약사만 기록했지만 이제 납부사를 따로 관리하려고 합니다. AI가 예전 조회 결과로 수신 회사를 고르면 계약사 A를 납부사로 잘못 안내할 수 있습니다.
이때 옛 거래처 값을 두 항목에 그대로 복사하면 근거 없는 관계가 생깁니다. 계약사만 확인됐다면 납부사는 미확인으로 남기고 원본 자료나 담당자에게 확인합니다. 데이터 이행[3]은 빈칸을 그럴듯하게 채우는 작업이 아닙니다.
항목을 바꿀 때 기존 프로그램도 살펴봅니다
영향을 받는 곳부터 찾습니다
업무 담당자는 어떤 거래가 달라졌는지, 무엇을 근거로 납부사를 확인하는지 설명합니다. 개발자는 기존 기록과 조회 기능, AI에게 주는 지시, 승인 화면과 보고서에서 ‘거래처’를 어떻게 쓰는지 살펴봅니다. 과거 거래에도 바뀐 뜻을 적용할지, 새 거래부터 적용할지는 업무 담당자와 함께 정합니다.
기존 방식을 유지하며 새 경로를 시험합니다
Parallel Change는 새 기능을 추가하고 사용하는 쪽을 옮긴 뒤 기존 것을 제거하는 단계적 변경 방식입니다. 이를 참고해 개발자는 기존 기능을 유지하면서 새 납부사 항목을 읽는 기능을 만들어볼 수 있습니다. 실제 안내를 보내기 전에, 예전 방식은 계약사 A를 골랐지만 새 방식은 확인된 납부사 B를 고르는지 봅니다. 납부사를 아직 모르면 임의로 고르지 않고 멈추는지도 확인합니다.
새 기능과 기존 기능을 함께 두는 동안 개발자는 수정한 정보가 양쪽에 맞게 반영되고 안내가 중복 발송되지 않도록 관리해야 합니다. 기존 항목을 쓰던 화면과 프로그램이 모두 바뀌었는지 확인한 뒤 옛 항목을 없앱니다. 언제 어떤 뜻으로 바꿨는지도 기록해두면 과거 결과를 확인할 때 도움이 됩니다.
납부사를 아직 모르는 거래는 어떻게 처리할까요?
새 항목을 만들었다고 모든 거래의 납부사를 바로 알 수 있는 것은 아닙니다. 확인되지 않은 거래는 청구 안내를 멈추고 담당자에게 물어보게 해야 합니다. 계약사와 납부사가 같은 거래, 다른 거래, 아직 납부사를 모르는 거래가 각각 어떻게 처리되는지 개발 업체가 보여주면 업무 담당자가 실제 자료와 맞춰볼 수 있습니다.
납부사 칸에 회사 이름이 들어 있는지 확인하는 것과, 정말 그 회사가 돈을 내기로 했는지 확인하는 것은 다른 일입니다. 프로그램은 정해진 조건에 맞는지 검사할 수 있지만, 잘못 입력한 회사도 형식상으로는 검사를 통과할 수 있습니다. 계약서나 청구 근거를 함께 확인해야 하는 이유입니다.
변경 후 청구 대상을 잘못 고르는 문제가 생기면 자동 발송을 멈춰야 합니다. 개발자는 바뀐 데이터와 청구 규칙을 어디까지 되돌릴지 확인하고, 새 형식으로 저장한 거래를 이전 프로그램에서도 읽을 수 있는지 살펴야 합니다. 프로그램을 이전 버전으로 돌려도 이미 보낸 안내까지 취소되지는 않습니다. 발송 기록을 따로 확인해 정정 여부를 판단합니다.
새로운 도구를 크게 도입해야만 하는 것은 아닙니다. 작은 업무라면 두 역할의 뜻을 정리하고 기존 프로그램에 필요한 항목을 추가하는 것으로 시작할 수 있습니다. 어떤 회사에 청구해야 하는지부터 직원들이 같은 뜻으로 이해하는 것이 먼저입니다.
납부사 정보를 따로 메모하고 있다면
계약서에는 A사, 청구 담당자의 메모에는 B사가 적혀 있어 안내를 보낼 때마다 수신자를 고치고 있나요? 계약사와 납부사를 프로그램에서도 구분하면 청구 안내를 만들 때 확인된 납부사 정보를 읽도록 바꿀 수 있습니다.
이런 청구 업무를 개선하고 싶다면 크몽 AX에 현재 쓰는 프로그램과 거래 사례를 알려주세요. 업무에 맞는 전문가를 연결받아 기존 거래 기록을 유지하면서 어떤 기능을 고칠지 상담할 수 있습니다.
참고 자료
2026-09-30 확인. 사례와 도식은 설명용이며 실제 시스템·모델 실행 결과가 아닙니다.
W3C OWL 2 Primer, 2012: 개념·관계·의미와 데이터베이스·형식 검사의 구분.
W3C SHACL, 2017: 그래프 데이터의 제약 검사.
Danilo Sato, Parallel Change, 2014: 추가·이행·제거의 단계적 변경. 본문의 업무 적용은 이 글의 설계 제안입니다.
용어 풀이
용어 1 온톨로지
한 업무 영역의 개체 종류·속성·관계와 그 의미를 명시한 모델입니다. 형식 언어로 논리적 제약을 표현할 수도 있으며, 단순한 용어 목록이나 데이터 저장 형식과는 구분합니다.
용어 2 스키마
데이터의 항목·형식·구조 등을 정한 명세입니다. 온톨로지의 의미를 구현에 반영할 수 있지만 항목 이름만으로 업무상 의미가 모두 정해지지는 않습니다.
용어 3 데이터 이행
기존 데이터를 새 구조와 의미에 맞게 옮기는 작업입니다. 원본에 없는 정보는 단순 변환으로 복원할 수 없으므로 근거 확인이나 별도 보완이 필요합니다.
이 주제에 대한 질문
최초 게시 2026-10-01 · 최종 수정 2026-10-01
