온톨로지 다시 보기: 시맨틱 웹 유행 뒤에 남은 것
20년쯤 전, 처음 개발을 배우던 무렵 「온톨로지」라는 말을 들었습니다. 시맨틱 웹이 다음 웹이 된다던 때였고, 저는 그 말이 무슨 뜻인지 제대로 모른 채 지나갔습니다. 그 말을 최근 터미널 매뉴얼 하나를 고치다가 다시 만났습니다.
업무 규칙을 데이터 구조로 옮기는 방법을 다룹니다. 모델링과 제약 조건부터 변경·이관까지, 운영할 수 있는 데이터베이스를 설계합니다.
우리 서비스에 적용할 계획이 있으신가요?
맞춤 업무시스템 개발 살펴보기 →20년쯤 전, 처음 개발을 배우던 무렵 「온톨로지」라는 말을 들었습니다. 시맨틱 웹이 다음 웹이 된다던 때였고, 저는 그 말이 무슨 뜻인지 제대로 모른 채 지나갔습니다. 그 말을 최근 터미널 매뉴얼 하나를 고치다가 다시 만났습니다.
제조 고객사의 공정관리 앱을 만들면서 계약서에 이런 한 줄이 들어갔습니다. 「직원이 공정 단계를 직접 정의하고, 진행 상태를 기록한다.」 진행 상태 기록은 이미 넘치게 만들어 둔 뒤였습니다. 남은 것은 「정의」 쪽이었고, 처음에는 설정 화면 하나면 끝날 일로 보였습니다.
거래처의 결제 조건이 「월말 마감 30일」에서 「월말 마감 60일」로 바뀌어 있습니다. 거래처 테이블에는 updatedAt 이 있어서 어제 오후 3시에 바뀌었다는 것은 압니다.
견적서의 품목 세 줄에 부가세를 줄마다 계산해서 더한다고 해 보겠습니다. 같은 견적을 합계에서 부가세를 한 번 계산한 화면과 나란히 놓으면 부가세가 1원 다릅니다.
거래처 목록 화면에 거래처별 미수금을 한 칸 더 보여 주기로 했다고 해 보겠습니다. 코드는 자연스럽게 이렇게 나옵니다.
품목 코드 RM-001 을 잘못 만들어서 지웠다고 해 보겠습니다. 소프트 삭제라 행은 남고 deletedAt 에 시각이 찍힙니다. 이제 같은 코드로 품목을 다시 만들려고 하면 오류가 납니다.
여러 회사가 함께 쓰는 업무 시스템에 전표 테이블이 있고, 인덱스가 이렇게 걸려 있다고 해 보겠습니다.
출하 등록 버튼 하나가 서버에서 하는 일을 적어 보면 이렇습니다.
두 사람이 같은 거래처 화면을 열었다고 해 보겠습니다. 한 사람은 전화번호를 고치고 저장합니다. 1분 뒤 다른 사람이 주소를 고치고 저장합니다. 두 번째 저장이 끝나면 전화번호는 옛 번호로 돌아가 있습니다.
제조업 ERP 데모의 문서 번호 함수에는 처음부터 이런 주석이 달려 있었습니다.
제조업 ERP 데모에서 시드로 만든 「수금 완료」 매출 전표에서 수금 취소를 누르면 이상한 일이 생기는 구조를 찾았습니다. 원 전표는 미수로 돌아오는데 수금 전표는 지워지지 않고 남습니다. 수금 합계에는 받지 않은 돈이 이중으로 잡힙니다.
사출 원료를 25kg 포대로 사는 회사가 있다고 해 보겠습니다. 발주서에는 「10」이라고 적습니다. 입고할 때 창고 담당자도 「10」이라고 적습니다. 생산 실적에서 원료를 소요로 빼는 사람은 「12.5」라고 적습니다.
공통 코드 표에 「설비 제조사」 그룹을 만들었다고 해 보겠습니다. 처음 몇 달은 잘 돌아갑니다. 설비를 등록할 때 제조사를 목록에서 고르고, 오타도 생기지 않습니다.
제조업 ERP 데모의 매출 전표 113장을 수주와 하나씩 대조했습니다. 전표 금액과 화면에 보이는 품목 줄의 합이 113장 모두 맞았습니다. 그런데 그 전표 테이블에는 품목 줄이 저장돼 있지 않았습니다.
제조업 ERP 데모에 전자세금계산서 모의 발행을 붙인 날 저녁, 스키마를 다시 읽었습니다. 세금계산서 모델의 전표 연결 한 줄에 이런 주석이 붙어 있었습니다.
생산 실적 화면에 불량 사유를 적는 칸이 있다고 해 보겠습니다. 한 달이 지나 불량 사유별로 집계를 내면 이런 줄이 나옵니다.
한 애플리케이션을 여러 회사가 함께 사용하는 SaaS에서는 로그인보다 테넌트 경계가 더 중요하다. 사용자가 정상적으로 로그인했더라도 다른 회사의 계약, 직원, 파일, 검색 결과를 볼 수 있다면 인증은 성공했지만 데이터 격리는 실패한 것이다.