설계 가이드
식품 제조 현장의 요구사항이 데이터 모델과 AI 화면으로 바뀌는 과정
“문제가 반복되는 업체를 먼저 보여주세요.” AI 프로젝트에서 나올 법한 요청입니다. 그런데 이 문장을 그대로 개발하면 서로 다른 화면이 만들어질 수 있어요. 반복의 기간이 다른지, 같은 유형만 셀 것인지, 이미 조치한 이슈를 포함할 것인지가 정해지지 않았기 때문이죠.
아래 요청은 설명을 위해 만든 예시이며 실제 고객의 메일이나 요구사항을 인용한 것이 아닙니다.
기능 이름보다 업무에서 쓰는 말의 뜻을 맞춥니다
처음에는 ‘AI 리스크 분석’ 같은 기능명을 붙이는 대신 요청에 들어 있는 단어를 풀어봅니다. 문제, 반복, 업체, 우선이라는 말이 각각 어떤 기록과 행동을 뜻하는지 정하는 거예요.
예를 들어 문제를 ‘접수된 모든 의견’으로 볼지, ‘검토 결과 확인된 이슈’로 볼지에 따라 집계가 달라집니다. 업체도 계약 상대인지 실제 생산처인지 구분해야 하고요. 이 정의를 건너뛰면 AI 설명이 자연스러워도 현업이 기대한 대상과 다른 결과가 나올 수 있습니다.
한 문장을 데이터 조건으로 바꿉니다
정의가 정리되면 필요한 데이터 관계를 적습니다. 이슈 기록에는 발생 시점과 유형, 상태가 필요하고, 업체를 연결할 기준도 있어야 해요. 생산처 단위로 보려면 계약 상대와 생산처의 관계를 따로 다뤄야 합니다.
그다음 비교 가능한 단위를 정합니다. 단순 이슈 건수로 볼 것인지, 납품량처럼 함께 확인할 분모가 있는지 검토하는 거예요. 분모를 확보하지 못했다면 화면에서 건수를 ‘발생률’로 바꿔 부르지 않도록 해야 합니다.
여기까지 작성한 내용을 작은 입력·출력 예시로 확인해보세요. 같은 기록이 중복 들어온 경우, 업체 연결이 없는 경우, 조치 상태가 뒤늦게 바뀐 경우를 넣으면 정의의 빈틈이 보입니다.
다섯 행으로 요구사항의 빈틈을 찾아봅니다
“반복되는 문제를 보여달라”는 요청을 작은 검증 문제로 바꿔볼게요. 다음 기준은 설명을 위해 정한 가상 업무 규칙입니다. 실제 식품 리스크 평가 기준이 아니에요.
이번에는 ‘최근 7일에 발생한 확인된 이슈 중, 아직 조치가 끝나지 않은 같은 유형의 고유 사건이 생산처별로 2건 이상이면 재점검 후보에 표시한다’고 합의했다고 가정합니다. 조회 시작 시각은 포함하고 종료 시각은 제외하며, 시각 비교에 사용할 시간대도 하나로 정합니다. ‘최근’이라는 말만 남기지 않는 거예요.
시험 자료는 다음 다섯 행입니다. 모두 선택 기간 안에 발생했고, 이슈 유형은 표시 확인으로 같다고 가정해요.
I-01 / F-01 / 확인된 이슈 / 조치 미완료.
I-02 / F-01 / 확인된 이슈 / 조치 미완료.
I-02 / F-01 / 같은 내용을 다시 보낸 중복 행.
I-03 / F-02 / 확인된 이슈 / 조치 완료.
I-04 / 생산처 미확인 / 확인된 이슈 / 조치 미완료.
정상 결과는 F-01만 재점검 후보에 나타나는 것입니다. F-01의 고유 사건은 I-01과 I-02 두 건이에요. I-02의 복사본 때문에 세 건이 되면 안 됩니다. F-02는 이번 규칙의 조치 미완료 조건을 충족하지 않으므로 후보에서 제외합니다. I-04는 F-01이나 F-02에 억지로 붙이지 않고 생산처 확인 목록에 남겨요.
이 결과를 개발 완료 조건으로 적으면 훨씬 명확해집니다. ‘위 자료가 주어졌을 때 목록을 조회하면, F-01과 사건 수 2가 보이고, 상세에서 I-01·I-02를 확인할 수 있다’는 식이에요. 화면이 뜨는지만 보는 검증과는 다르죠.
이어지는 변경 시험도 정해봅시다. I-02의 복사본을 하나 더 넣어도 결과는 2건이어야 합니다. 반대로 I-02가 조치 완료로 바뀌면 F-01의 미완료 사건은 1건이므로 후보 목록에서 빠져야 해요. 이때 사건 자체를 삭제하는 것은 아닙니다. 조건을 바꾸거나 상세 이력을 열면 완료 기록을 다시 확인할 수 있어야 합니다.
조회 기간의 마지막 순간에 걸친 기록은 합의한 시간대와 종료 시각 기준으로 처리합니다. 다른 조직의 동일 사건 번호는 이 자료에 섞이지 않아야 하고요. 이런 경계 조건까지 예시에 포함하면 나중에 데이터 연결이나 권한 문제가 생겼을 때 어느 정의를 확인해야 할지 알 수 있습니다.
화면 문구도 규칙에 맞춰야 합니다. 후보 목록이 비었다면 “해당 조건을 충족하는 재점검 후보가 없습니다”라고 설명하는 것이 맞아요. “품질 문제가 없습니다”라는 결론은 이번 검색으로 확인하지 않았습니다. 생산처 미확인 기록이 남아 있다는 안내도 함께 보여줘야 합니다.
이렇게 만든 입력·기대 결과·변경 시험을 요구사항 문서와 같이 관리해보세요. 이후 기준을 2건에서 3건으로 바꿀 때는 규칙 버전, 화면 설명, 시험의 기대 결과를 함께 수정합니다. 실제 사용자가 원하는 판단을 확인하는 작은 계약서 역할을 하는 셈이에요.
데이터 정의는 화면의 행동과 함께 검토합니다
리스트에서 업체를 클릭했을 때 담당자는 무엇을 하려고 할까요? 상세 기록을 비교할지, 다음 점검 항목을 준비할지에 따라 필요한 화면이 달라집니다.
예시 화면에서는 목록에 선택 기간과 집계 기준을 보여주고, 상세에서는 포함된 이슈와 제외된 이유를 확인하게 할 수 있어요. AI 설명은 그다음에 붙입니다. 사용자가 결과를 이해하지 못하는 이유가 조회 조건의 누락인데 설명문만 늘리는 실수를 피하기 위해서죠.
자료가 없으면 빈 차트 대신 ‘이 기간의 기록이 없음’을 표시합니다. 연결되지 않은 기록이 남아 있다면 완전한 전체 집계처럼 보이지 않게 별도로 알려주고요.
완료 조건을 화면 캡처가 아니라 사용 예시로 남깁니다
“리스트가 뜬다”는 조건만으로는 업무 요구가 충족됐는지 판단하기 어렵습니다. 기간을 바꿨을 때 대상이 일관되게 달라지는지, 중복 기록이 추가돼도 건수가 부풀지 않는지, 근거를 확인한 뒤 이전 목록 조건으로 돌아올 수 있는지를 검증해보세요.
NIST Measure는 평가가 사용 목적과 실제 배포 맥락에 맞아야 한다는 점을 다룹니다.[1] 이를 이 예시에 적용하면, 단순히 답변이 생성되는지보다 담당자의 다음 행동이 가능한지를 시험하게 됩니다.
합의된 정의가 바뀌면 데이터 처리와 화면 문구, 검증 예시를 함께 바꾸는 편이 좋습니다. 문서에는 새 정의가 있는데 화면은 옛 기준으로 계산하는 상태를 남기지 않기 위해서예요.
현업 요청이 기능 목록으로만 쌓이고 있다면, 데이터스케쳐스와 요청 한 문장을 데이터·화면·검증 조건으로 구체화해보세요.
참고자료
[1] NIST AI RMF Playbook · Measure
https://airc.nist.gov/airmf-resources/playbook/measure/
사용 목적에 맞는 평가, 배포 환경과의 차이, 시험 자료와 지표의 문서화
자료 확인: 2026-10-08. 본문의 가상 상황·화면 구성·점검 절차는 출처의 실제 사례가 아니라 이 글에서 제안한 적용 예시입니다.