AI 기능의 "잘 작동한다"는 기준 - 개발을 시작하기 전에 합의해야 할 검수 조건

AI 기능이 들어간 제품의 개발을 의뢰하시는 창업자분들과 상담하다 보면, 개발 범위와 일정은 꼼꼼히 논의되는데 한 가지가 자주 빠져 있습니다. "이 AI 기능이 잘 작동한다는 것을 무엇으로 판정할 것인가"라는 질문입니다.

결론을 먼저 말씀드리면, AI 기능은 일반 기능과 달리 "항상 정답"이 원리적으로 불가능하기 때문에, 잘 작동한다는 기준을 착수 전에 합의하지 않으면 개발이 끝났는지조차 판정할 수 없는 상황이 옵니다. 개발사는 "이 정도면 됐다"고 보고, 의뢰자는 "아직 틀리는데요"라고 보는 평행선이 만들어지는 것입니다. 이 간극은 기술의 문제가 아니라 기준 합의의 문제이고, 합의의 적기는 개발이 끝난 후가 아니라 시작하기 전입니다.

AI 기능의 완성은 코드가 아니라 합의된 기준 위에서 판정됩니다.

일반 기능과 AI 기능의 검수는 왜 다른가

버튼을 누르면 전원이 켜지는 기능은 검수가 명확합니다. 켜지거나, 켜지지 않거나 둘 중 하나이고, 켜지지 않으면 수정 대상입니다. 반면 소리를 듣고 상황을 분류하거나 영상에서 대상을 알아보는 AI 기능은 확률적으로 동작합니다. 학습한 범위 안의 입력에는 잘 답하지만, 처음 보는 조건에서는 틀릴 수 있고, 조명·소음·각도 같은 환경 변화에 따라 결과가 흔들립니다.

그래서 AI 기능의 검수는 "틀리는 경우가 있는가"를 묻는 방식으로는 성립하지 않습니다. 틀리는 경우는 반드시 있습니다. 올바른 질문은 "어떤 조건에서, 얼마나 자주, 어떤 방식으로 틀리는 것까지 허용할 것인가"입니다. 이 질문에 대한 답이 곧 검수 기준이 됩니다.

정확도라는 숫자의 함정

어떤 데이터에서의 정확도인가

같은 모델이라도 조용한 시연 환경에서 측정한 정확도와 실제 사용 환경에서 측정한 정확도는 다릅니다. 개발 중에 보던 데이터와 비슷한 입력에서는 높게 나오고, 실제 고객의 환경처럼 조건이 흩어진 입력에서는 낮아지는 것이 일반적입니다. 그래서 "정확도가 높다"는 말은 반드시 "어떤 데이터에서"라는 조건과 함께 읽어야 합니다. 검수에 사용할 데이터가 실제 사용 환경을 대표하는지가 숫자 자체보다 중요합니다.

어떤 오류가 더 치명적인가

AI의 오류에는 두 방향이 있습니다. 있는 것을 놓치는 오류와, 없는 것을 있다고 하는 오류입니다. 어느 쪽이 치명적인지는 제품마다 다릅니다. 위험을 감지해 알리는 제품이라면 놓치는 오류가 치명적이고, 놓치지 않기 위해 민감하게 만들면 잘못된 알림이 늘어 사용자가 알림 자체를 꺼버리는 문제가 생깁니다. 반대로 편의 기능이라면 가끔 놓치는 것보다 시도 때도 없이 반응하는 쪽이 더 큰 불만을 만듭니다. 하나의 정확도 숫자는 이 두 방향의 균형을 보여주지 못하므로, 우리 제품에서는 어느 방향의 오류를 더 엄격하게 볼지 먼저 정해야 합니다.

같은 정확도라도 오류의 방향에 따라 사용자 경험은 완전히 달라집니다.

착수 전에 합의해 둘 세 가지

• "평가용 데이터의 기준": 검수에 사용할 데이터를 어떤 환경과 조건에서 수집할지, 개발에 쓰인 데이터와 분리할지를 합의합니다. 평가 데이터가 곧 시험 문제이므로, 문제의 출처를 함께 정하는 것입니다
• "오류 방향별 우선순위": 놓치는 오류와 잘못 반응하는 오류 중 우리 제품에서 무엇을 더 엄격하게 볼지, 허용 수준을 상대적 기준으로 합의합니다
• "완료 판정 절차": 어떤 시나리오를 어떤 순서로 시연하면 완료로 판정할지, 기준에 못 미칠 때의 개선 절차는 어떻게 되는지를 문서로 남깁니다

이 세 가지가 합의되어 있으면 개발 과정의 논의가 건강해집니다. "더 좋게 해주세요"라는 막연한 요청 대신 "이 시나리오에서 이 방향의 오류를 줄여주세요"라는 구체적 요청이 가능해지고, 개발사도 무엇을 향해 개선할지 명확히 알게 됩니다.

판단 기준은 한 문장입니다

"이 기능이 틀렸을 때 사용자에게 무슨 일이 생기는가." 이 질문에 답하면 어느 방향의 오류를 엄격하게 볼지, 검수 데이터를 어떤 환경에서 모아야 할지, 틀렸을 때 제품이 어떻게 행동해야 할지가 연쇄적으로 정해집니다. AI 기능의 완성도는 이 질문에 대한 답의 구체성에 비례합니다.

사용자의 실제 환경이 곧 최종 검수장입니다.

제언: 기준의 합의가 개발보다 먼저입니다