고객 맞춤 프로젝트를 식품 제조 AI 솔루션으로 확장하려면 무엇을 분리해야 하나

고객별 데이터 매핑과 업무 규칙을 공통 AI 처리 기능에서 분리한 구조 — 그림 19. 공통 기능과 조직별 규칙·자료 경계를 구분한 가상 구조.

한 조직을 위해 만든 분석 화면을 다른 조직에도 제공하려고 해볼게요. 화면은 비슷해 보여도 품목 분류, 점검 방식, 업체를 구분하는 기준이 다릅니다. 고객 이름만 바꾸고 같은 코드를 복사하면 다음 변경부터 서로 다른 제품을 관리하게 될 수 있어요.

이 글은 프로젝트를 솔루션으로 확장할 때 검토할 설계안입니다. 특정 고객의 기능을 제품화했다거나 아래 기능을 모두 제공하고 있다는 의미는 아니에요.

데이터의 모양과 업무의 뜻을 분리합니다

파일 형식을 맞추는 일과 업무 의미를 맞추는 일은 다릅니다. 두 조직에 모두 ‘업체’라는 항목이 있어도 하나는 계약 상대, 다른 하나는 생산처를 뜻할 수 있어요.

고객별 연결 계층에서는 원본의 항목과 공통 개념의 관계를 명시하는 방식을 고려할 수 있습니다. 원본 이름을 모두 같은 이름으로 바꾸는 데서 끝내지 않고, 어떤 관계가 일대일인지, 무엇이 확인되지 않았는지 남기는 거예요.

공통 개념에 맞지 않는 데이터를 억지로 넣지 않도록 확장 범위도 정합니다. 공통화를 위해 중요한 업무 차이를 지우면 재사용은 쉬워 보여도 결과는 달라질 수 있으니까요.

고객별 규칙은 바꿀 수 있어도 변경 책임은 분명해야 합니다

집계 기간, 검토 상태, 점수 계산 방식처럼 달라지는 부분을 규칙으로 분리할 수 있습니다. 다만 모든 행동을 자유로운 설정으로 만들면 검증할 조합이 지나치게 많아질 수 있어요.

지원할 변경 범위를 정하고, 규칙의 버전과 적용 대상, 변경 승인 주체를 남겨보세요. 같은 고객의 새 규칙도 과거 결과를 자동으로 바꾸지 않도록 적용 시점을 구분하는 편이 좋습니다.

NIST Govern은 AI 위험 관리 역할과 책임의 명확성을 다룹니다.[1] 공통 엔진을 만드는 경우에도 규칙을 정하는 사람, 시스템을 운영하는 사람, 결과를 검토하는 사람의 책임은 한곳에 뭉개지지 않아야 해요.

공통화할 것은 반복되는 처리와 확인 방법입니다

자료를 받아 형식을 점검하는 과정, 분석 결과에서 근거를 찾는 과정, 검토 의견을 남기는 과정처럼 반복되는 동작부터 공통 기능 후보로 볼 수 있습니다.

반면 고객 고유의 평가 기준을 공통 기본값처럼 넣거나, 한 조직의 예외를 모든 고객에게 적용하지 않도록 주의합니다. 공통 기능을 수정했을 때 각 고객의 핵심 예시가 여전히 통과하는지 확인할 수 있어야 해요.

이 검증에는 정상 예시뿐 아니라 누락된 자료, 지원하지 않는 규칙, 바뀐 코드 체계도 포함해보세요. 기능을 재사용한다는 것은 검증 방법도 반복해서 사용할 수 있다는 뜻이어야 합니다.

두 조직의 다른 기준을 하나의 엔진에서 다뤄봅니다

가상의 조직 A는 최근 7일에 같은 유형의 미완료 이슈가 2건 이상인 생산처를 확인하고, 조직 B는 최근 14일에 3건 이상인 생산처를 확인한다고 해볼게요. 이 숫자는 비교를 위한 임의 규칙이며 실제 고객의 기준이나 권장 리스크 기준이 아닙니다.

두 화면을 복사해 각각 수정할 수도 있지만, 공통 동작과 달라지는 값을 먼저 나눠보는 편이 좋습니다. 기간 안의 고유 사건을 찾고, 조치 상태를 확인하고, 근거 목록을 제공하는 과정은 공통 후보예요. 기간과 최소 사건 수는 정해진 범위 안에서 조직별 규칙으로 관리할 수 있습니다.

이 예시의 설정에는 다음 의미가 필요해요.

tenant_id: 어느 조직의 설정인지 식별합니다. 실제 접근 범위는 서버에서 확인한 권한으로 제한합니다.

lookback_days: 선택 기준 시점에서 되돌아볼 기간입니다.

min_distinct_events: 중복을 제외한 고유 사건 수의 기준입니다.

mapping_version: 원본의 업체·생산처·품목을 연결한 정의의 버전입니다.

rule_version: 기간, 상태, 포함·제외 조건을 함께 묶은 업무 규칙 버전입니다.

설정값 몇 개로 모든 차이를 표현하려고 하지는 마세요. A의 ‘업체’가 법인이고 B의 ‘업체’가 공장이라면 같은 열 이름으로 바꾸는 것으로 해결되지 않습니다. 원본 개념이 공통 모델의 어느 대상에 대응하는지부터 확인해야 해요. 대응하지 않는 값은 미확인으로 남기거나 지원 범위 밖으로 명시합니다.

검증에는 같은 입력을 두 규칙에 넣는 예시가 유용합니다. 최근 7일 안에 발생한 고유 사건 두 건만 있는 생산처는 A의 후보에는 나오고 B의 후보에는 나오지 않아야 해요. 기간과 사건 수를 함께 바꾸면 어떤 조건이 결과에 영향을 줬는지 놓치기 쉬우므로, 기간만 바꾸는 시험과 기준 건수만 바꾸는 시험도 따로 준비합니다.

조직 경계 시험은 별도로 해야 합니다. A와 B가 모두 I-01이라는 사건 번호를 사용하되 내용은 다른 시험 자료를 만들어보세요. A의 권한으로 조회했을 때 B의 본문뿐 아니라 파일명, 검색 결과, 요약과 내려받기 내용도 포함되지 않아야 합니다. 캐시도 조직·권한·조회 조건·자료 및 규칙 버전에 맞게 구분하도록 설계하고, 캐시 키를 나눴다는 이유만으로 서버의 권한 확인을 생략하지 않습니다.

규칙 변경은 코드 배포와 구분해 기록합니다. 새 규칙을 작성하고, 해당 조직의 정상·누락·경계 사례를 시험한 뒤, 변경 책임자가 적용 범위를 확인하는 절차를 둘 수 있어요. 문제가 있으면 이전 규칙으로 새 분석을 다시 생성하되, 이미 남긴 사람의 검토와 후속 실행 이력을 삭제하거나 다른 규칙의 결과로 덮어쓰지는 않습니다.

공통 엔진을 수정할 때도 A와 B의 시험을 모두 통과해야 합니다. A의 예외를 해결한 변경이 B의 기본 동작을 바꾸지 않는지 확인하는 거죠. 재사용 가능한 것은 처리 구조와 시험 방법이지, 한 조직의 데이터를 다른 조직의 예시나 답변에 사용하는 권한은 아닙니다. 위 설정과 시험은 솔루션 경계를 논의하기 위한 설계안이며 실제 구현 완료 목록이 아닙니다.