AI 기능을 만드는 프로젝트, 관리 영역별로 달라지는 것

요지

사내 챗봇, 문서 자동 분류, 수요 예측처럼 AI 기능을 만드는 프로젝트도 범위, 일정, 원가, 리스크, 이해관계자를 관리한다는 점은 다른 프로젝트와 같다. 달라지는 것은 각 영역에서 먼저 챙겨야 할 질문이다. 결과에 틀린 답이 섞일 수 있고, 데이터에 크게 기대며, 오픈한 뒤에도 품질이 바뀐다는 세 성질 때문이다. 그래서 같은 관리 영역이라도 착수 단계에 묻는 질문의 순서가 바뀐다.

세 가지 성질부터

첫째, 결과에 틀린 답이 섞일 수 있다. 일반 시스템은 정해진 규칙대로 동작해, 규칙이 맞으면 결과도 맞다. AI 기능은 맞는 답 사이에 틀린 답이 섞여 나올 수 있다. 여기에 생성형 AI를 쓰는 기능은 같은 입력에도 답이 달라질 수 있다. 그래서 「맞다, 틀리다」가 아니라 「얼마나 자주 맞는가」로 품질을 말해야 한다.

둘째, 데이터가 품질을 좌우한다. 챗봇이 참고하는 문서가 낡았거나 서로 다른 버전이 섞여 있으면, 모델을 아무리 바꿔도 틀린 답이 나온다.

셋째, 오픈이 끝이 아니다. 사용자의 질문 유형이 바뀌고, 참고 문서가 바뀌고, 기반이 되는 모델이 새 버전으로 바뀌면 같은 기능의 품질이 달라진다.

다섯 영역에서 달라지는 것

표는 가로로 밀어서 볼 수 있습니다.

관리 영역	일반 시스템 구축	AI 기능 구축	PM이 먼저 챙길 것
범위	기능 목록과 화면이 범위를 정한다	기능 목록만으로는 「다 됐다」를 정할 수 없다	인수기준을 숫자와 테스트 자료로 정하고, 테스트 자료를 인도물로 넣는다
일정	경험 자료로 기간을 산정한다	실제 데이터로 테스트하기 전에는 기간을 산정하기 어렵다	개념 검증(PoC) 구간과 중단 기준을 따로 둔다
원가	개발 원가를 중심으로 계획한다	사용량 요금과 운영 중 품질 관리가 계속 든다	오픈 뒤 원가를 처음부터 계획에 넣는다
리스크	기술 난이도와 일정 지연이 중심이다	데이터 품질, 사용 권한, 틀린 답의 영향, 모델 변경이 더해진다	리스크 관리대장에 데이터, 틀린 답, 모델 변경 항목을 따로 둔다
이해관계자	화면 시연으로 기대를 조율한다	잘 고른 시연이 기대를 지나치게 높인다	시연 때 틀리는 예와 그 처리 방법을 함께 보인다

범위: 「다 됐다」를 숫자로 정한다

중견 제조 기업이 사내 규정 질의응답 챗봇을 만든다고 하자(가상의 예). 「규정에 대한 질문에 답한다」는 기능 설명만으로는 언제 끝났다고 할 수 없다. 인수기준을 「직원들이 실제로 물어 온 질문 200개로 만든 테스트 자료에서 정답률 90% 이상, 규정에 없는 내용을 지어낸 답 2% 이하」처럼 숫자로 정해야 한다.

이때 테스트 자료 자체가 하나의 인도물이 된다. 테스트 자료를 만드는 일(질문 모으기, 모범 답 정하기)을 작업분류체계(WBS)에 넣고 담당과 기한을 정해 두지 않으면, 개발이 끝난 뒤에야 「무엇으로 테스트하느냐」를 놓고 다시 협의하게 된다.

일정: 해 봐야 아는 구간을 따로 둔다

AI 기능은 실제 데이터로 돌려 보기 전에는 원하는 수준에 닿을지 알기 어렵다. 전체 일정을 한 번에 확정하지 않고, 앞쪽에 개념 검증 구간을 두고 그 결과로 뒤쪽 일정을 다시 산정한다.

이 구간에는 중단 기준이 함께 있어야 한다. 예를 들어 「4주 개념 검증에서 정답률 80%에 닿지 못하면 범위를 줄이거나 멈춘다」(가상의 숫자)처럼 미리 정해 두면, 성과 없이 기간만 늘어나는 일을 막을 수 있다. 불확실성이 큰 구간이므로 일정과 원가 모두에 예비를 따로 떼어 두고, 예비를 언제 쓰는지도 정해 둔다.

원가: 오픈 뒤에 드는 돈을 먼저 본다

외부 AI 서비스를 쓰면 사용량에 따라 요금이 나오는 경우가 있어, 사용자가 늘수록 운영 원가도 늘어난다. 여기에 품질을 지켜보고 참고 문서를 갱신하는 사람의 시간이 더해진다.

D. Sculley 외 9명의 2015년 논문 「Hidden Technical Debt in Machine Learning Systems」는 머신러닝 시스템은 빨리 만들 수 있지만 운영 단계에서 유지 원가가 크게 쌓이기 쉽다고 지적한다. 프로젝트 원가를 오픈 시점까지만 계산하면, 이 원가는 프로젝트가 끝난 뒤 누군가의 예산에서 갑자기 나타난다. 오픈 뒤 품질 관리 담당과 그 원가를 누가 낼지를 프로젝트 안에서 정해 두어야 한다.

리스크: 데이터와 틀린 답을 따로 적는다

일반적인 기술 리스크에 더해, 리스크 관리대장에 다음 항목을 따로 둔다.

데이터 품질: 참고 문서가 낡았거나 버전이 섞여 있을 가능성
데이터 사용 권한: 개인정보나 계약상 제약 때문에 쓰지 못하게 될 가능성
틀린 답의 영향: 틀린 답이 나갔을 때 누가 어떤 손해를 입는가
모델 변경: 기반 모델이 바뀌어 품질이 달라질 가능성

특히 틀린 답의 영향은 기능 설계와 이어진다. 영향이 크면 답과 함께 근거 문서를 보여 주는 장치를 범위에 넣어야 한다.

이해관계자: 시연 때부터 한계를 보인다

잘 고른 질문 몇 개로 하는 시연은 인상적이다. 그 장면을 본 이해관계자는 모든 질문에 같은 수준을 기대한다. 실제 운영에는 오타, 엉뚱한 질문, 규정에 없는 질문이 들어온다.

시연 때 잘 되는 예와 함께 틀리는 예를 보이고, 틀렸을 때 어떻게 처리되는지를 같이 설명하면 오픈 뒤의 실망을 줄일 수 있다. 인수기준의 숫자를 이해관계자와 함께 정하는 것도 같은 효과가 있다. 90%라는 숫자에 동의했다면, 열 번에 한 번 틀리는 것은 약속한 범위 안이라는 뜻이기 때문이다.

착수 단계 확인 목록

인수기준을 숫자로 정했고, 그 숫자를 잴 테스트 자료를 인도물로 넣었는가
테스트 자료를 만드는 일을 작업분류체계에 넣고 담당과 기한을 정했는가
개념 검증 구간의 기간과 중단 기준을 정했는가
일정과 원가의 예비를 따로 떼어 두고 쓰는 조건을 정했는가
필요한 데이터의 위치, 품질, 사용 권한을 확인했는가
리스크 관리대장에 데이터, 틀린 답, 모델 변경 항목을 넣었는가
틀린 답이 나왔을 때의 처리 방법(근거 문서 표시 등)을 범위에 넣었는가
오픈 뒤 품질 관리 담당과 운영 원가를 누가 맡을지 정했는가
이해관계자와 인수기준의 숫자를 함께 정하고, 틀리는 예를 보여 주었는가

참고

D. Sculley, Gary Holt, Daniel Golovin, Eugene Davydov, Todd Phillips, Dietmar Ebner, Vinay Chaudhary, Michael Young, Jean-François Crespo, Dan Dennison, 「Hidden Technical Debt in Machine Learning Systems」, Advances in Neural Information Processing Systems 28 (NIPS 2015), https://papers.nips.cc/paper/2015/hash/86df7dcfd896fcaf2674f757a2463eba-Abstract.html (2026년 10월 12일 확인). 머신러닝 시스템은 빨리 만들 수 있어도 운영 단계의 유지 원가가 크게 쌓이기 쉽다는 생각만 따랐다. 문장은 옮기지 않았다.
사내 규정 질의응답 챗봇 예와 그 안의 숫자는 이 글을 위해 만든 가상의 예다.