AI 외주 개발, 클라이언트가 "좋은 결과"를 정의하지 않으면 프로젝트가 망한다 (maily.so)
한줄 요약
AI 외주 개발에서 품질은 개발사가 보장하는 게 아니라, 클라이언트가 먼저 정의해야 한다.
AI 기능을 외주 개발할 때 가장 자주 발생하는 실패 패턴은 기술 부족이 아니라 품질 기준의 부재다. 개발사는 요구사항대로 만들었다고 하고, 클라이언트는 "이게 아닌데"라고 하는 상황. 서로 틀린 말을 하는 게 아니다. 애초에 무엇이 좋은 결과인지를 합의하지 않았기 때문에 생기는 문제다.
AI 프로젝트에서 QA는 왜 한계에 부딪히나
일반적인 기능 개발은 판단이 명확하다. 버튼을 눌렀을 때 다음 화면이 뜨면 통과, 안 뜨면 실패다. QA는 이 구조 위에서 작동한다. 정해진 시나리오대로 테스트하고, 결과가 기대값과 일치하는지 확인한다.
AI 기능은 이 구조가 통하지 않는다. 챗봇이 답변을 생성했다고 치자. 그 답변이 "작동"하는지는 확인할 수 있다. 하지만 그게 좋은 답변인지는 테스트 케이스로 판별할 수 없다. 같은 질문에 매번 다른 답이 나오고, 정답 자체가 없기 때문이다.
상품 추천 AI, 자동 보고서 생성, 고객 응대 챗봇, 콘텐츠 자동화 툴. 에이전시에서 자주 받는 AI 외주 요청들이다. 이 기능들의 공통점은 "잘 작동하느냐"보다 "결과가 얼마나 좋으냐"가 핵심이라는 점이다. 그리고 "좋다"는 기준은 코드 안에 없다. 클라이언트의 머릿속에 있다.
개발사가 기준을 대신 만들어줄 수 없는 이유
에이전시 입장에서 솔직하게 말하면, 우리는 클라이언트의 비즈니스를 클라이언트만큼 알지 못한다. 어떤 톤의 답변이 브랜드와 맞는지, 어느 정도의 디테일이 실제 사용자에게 유용한지, 어떤 실수가 치명적인지. 이건 도메인 지식의 문제다.
개발사가 임의로 품질 기준을 세우면 두 가지 결과 중 하나가 나온다. 기술적으로는 완성도 높지만 실제 사용자에게는 쓸모없는 결과물이 되거나, 클라이언트가 나중에 "이런 방향이 아니었는데"라고 하면서 대규모 재작업이 발생하거나.
결국 AI 프로젝트에서 품질 기준 정의는 클라이언트 PM의 몫이다. 개발사가 기술적 구현을 담당한다면, 클라이언트는 무엇이 좋은 결과인지를 정의하는 역할을 담당해야 한다. 이게 빠지면 프로젝트 전체가 방향 없이 표류한다.
클라이언트 PM이 실제로 해야 하는 것
기준을 정의하는 게 막막하게 느껴진다면, 다음 세 가지부터 시작하면 된다.
첫째, 결과물을 직접 보고 점수를 매겨본다. AI가 생성한 결과물을 20~30개 정도 꺼내서 별다른 기준 없이 "이건 좋다, 이건 별로다"로 나눠본다. 이 과정에서 기준이 없으면 평가 자체가 안 된다는 걸 몸으로 체감하게 된다. 그 답답함이 기준 정의의 출발점이다.
둘째, 감을 문장으로 바꾼다. "왠지 좋은 것 같은" 결과와 "왠지 별로인 것 같은" 결과를 구분하는 이유를 말로 꺼낸다. "너무 장황하다", "실제로 실행 가능한 내용이 아니다", "우리 브랜드 톤과 다르다" 같은 식이다. 처음부터 완벽할 필요 없다. 팀원에게 설명할 수 있는 수준이면 충분하다.
셋째, 테스트 케이스를 직접 만든다. 우리 서비스가 잘 처리해야 하는 대표 질문 또는 입력값을 리스트로 정리한다. 실패하면 치명적인 케이스, 자주 들어올 평범한 케이스, 까다로운 엣지 케이스를 섞어서 구성한다. 이 리스트가 있어야 개선이 이뤄졌는지 아닌지를 판단할 수 있다.
에이전시에 이렇게 전달해야 프로젝트가 산다
품질 기준이 정의됐다면, 개발사와 공유하는 방식도 중요하다. 막연하게 "자연스럽게 만들어주세요"가 아니라 구체적으로 전달해야 한다.
좋은 예시와 나쁜 예시를 함께 제공하는 것이 가장 효과적이다. "이런 결과는 좋다. 이런 결과는 나쁘다"를 실제 샘플로 보여주면 개발사가 프롬프트를 설계하거나 모델을 튜닝할 때 훨씬 정확하게 방향을 잡을 수 있다. 기준이 여러 개라면 우선순위도 같이 명시한다. 정확성과 창의성이 충돌할 때 무엇을 더 중요하게 볼지 미리 합의하지 않으면, 나중에 같은 결과물을 두고 클라이언트와 개발사가 다른 평가를 내리게 된다.
중간 점검도 결과물 단위로 한다. "개발 진행 상황"이 아니라 "실제 생성 결과의 품질"을 기준으로 체크포인트를 설정하면, 문제를 일찍 발견하고 방향을 빠르게 수정할 수 있다.
자주 묻는 질문
Q.AI 기능 외주를 맡길 때 요구사항 문서만 잘 써도 품질이 보장되지 않나요?
일반 기능 개발은 요구사항 문서가 곧 품질 기준이 된다. 하지만 AI 기능은 다르다. 요구사항대로 구현했어도 결과의 품질은 별개 문제다. 챗봇이 "응답을 생성한다"는 기능은 구현됐지만, 그 응답이 실제로 유용한지는 요구사항 문서에 담기지 않는다. 품질 기준은 별도로 정의해야 한다.
Q.품질 기준은 누가 만들어야 하나요? 클라이언트인가요, 개발사인가요?
기준의 핵심은 클라이언트가 만들어야 한다. "무엇이 좋은 결과인가"는 비즈니스 도메인과 사용자 맥락에 달려 있고, 그걸 가장 잘 아는 건 클라이언트다. 개발사는 그 기준을 기술적으로 구현하고 측정할 수 있도록 지원하는 역할을 한다. 기준 정의 단계에서 클라이언트가 빠지면, 개발사가 임의로 만든 기준에 맞춰 최적화된 결과가 나올 수밖에 없다.
Q.작은 프로젝트에서도 품질 기준 정의가 꼭 필요한가요?
프로젝트 규모와 무관하게 필요하다. 오히려 작은 프로젝트일수록 재작업 비용이 치명적이기 때문에 더 중요하다. 기준이 없으면 완성 여부 판단도 어렵고, 수정 요청이 끝없이 이어질 수 있다. 샘플 20개에 점수 매겨보는 것만으로도 기준 정의는 시작할 수 있다. 거창한 작업이 아니다.