검증된 AI 제품을 사면 그걸로 끝일 것 같습니다. 그런데 그 제품을 우리 회사에 하는 순간, 사실 같은 문제가 처음부터 다시 시작됩니다. “제품만 사면 되는 줄 알았는데”가, AI 도입에서 가장 흔한 후회입니다.
왜 제품을 사도 끝이 아닌가
아무리 좋은 제품이라도, 회사마다 데이터·업무·사람이 다릅니다. 우리 회사의 문서 체계, 우리만의 업무 규칙, 우리 직원들이 실제로 묻는 방식 — 이건 제품에 들어 있지 않습니다. 제품이 80%라면, 나머지 결정적인 20%는 붙이는 과정에서 만들어집니다. 그리고 그 20%가 “쓸 만하다”와 “안 쓰게 된다”를 가릅니다.
현장 경험칙
AI 솔루션의 가치는 제품 자체가 아니라 얼마나 우리 현장에 잘 접목되느냐에서 결정됩니다. “무슨 제품을 사느냐”보다 “누가 어떻게 붙여 주느냐”를 봐야 하는 이유입니다.
배우면서 바뀌는데, 계약에 묶입니다
도입을 시작하면 배우게 되고, 배우면 아이디어가 생깁니다. “아, 이것도 되겠네”, “이건 이렇게 바꾸면 좋겠다.” 그런데 초반 계약에 기능이 못박혀 있으면 그 아이디어를 살릴 수가 없습니다. 그렇다고 안 할 수도 없어 계속 요청하게 되고, 개발사는 반대로 계약서상 하지 않아도 될 일들을 떠안게 됩니다.
현장 경험칙
요구사항은 반드시 변합니다. 도입 도중에 요구가 안 변한다면, 그건 고객이 아무것도 배우지 못했다는 더 나쁜 신호입니다. 그러니 “요구가 변하면 어쩌지”가 아니라 “변할 것을 어떻게 담을까”로 설계해야 합니다.
이건 선의(善意)가 부딪히는 자리입니다
쉽게 말하면
고객은 “자꾸 부탁해서 미안하고”, 개발사는 “자꾸 늘어나서 힘들고.” 양쪽 다 나쁜 마음이 아닙니다. 그런데 중간에서 조율하는 사람이 없으면, 좋은 마음으로 시작한 프로젝트가 서서히 서로에게 부담이 되고 관계가 상합니다.
흔한 실수
처음에 모든 걸 정해 한 번에 전체를 도입하는 대형 계약. 아직 아무도 배우지 못한 시점에 전 범위를 못박으면, 스코프가 어긋나는 건 실력 문제가 아니라 구조적으로 정해진 결과입니다. 큰 계약일수록 이 위험은 커집니다.
핵심은 ‘무엇을 잠그느냐’입니다
올윈은 명세가 아니라 ‘질문’에 합의합니다. 무엇을 만들지(기능)를 잠그는 대신, 무엇에 답해야 하는지(질문 목록)와 품질 기준을 잠급니다. 기능을 잠그면 배움이 죄가 되고, 질문을 잠그면 배움이 반영됩니다. 두 방식이 어떻게 다른지 눌러서 비교해 보세요.
기능을 못박습니다
- ① 착수 전에 만들 기능을 전부 확정
- ② 쓰면서 배운 아이디어 → 계약 밖 → 못 살림
- ③ 계속 요청 → 개발사는 무보수로 떠안음
- ④ 결국 서로 지침 · 중재 없이 무너짐
그리고 중간에서 조율하는 사람을 둡니다
진화하는 고객의 요구와 개발팀의 범위 사이에 이 서서 조율합니다. PM이 실제로 하는 일은 세 가지입니다 — 고객의 말을 개발팀이 만들 수 있는 형태로 번역하고, 쏟아지는 요구에 우선순위를 매기고, 어느 쪽도 손해 보지 않게 양측을 보호합니다. 고객은 방치되지 않고, 개발사는 무보수로 떠안지 않습니다.
현장 경험칙
접목은 한 번에 하지 말고 단계로 하세요. 작게 붙여 보고, 배우고, 확장합니다. 파일럿 없이 곧장 전사 도입한 프로젝트는 거의 예외 없이 크게 헤맵니다. 작게 시작하는 건 소심한 게 아니라, 가장 빠른 길입니다.
그래서 제품을 사더라도, 접목은 “던지고 끝”이 아니라 합의·단계·중재로 관리되는 여정이 됩니다. 좋은 제품을 고르는 것만큼, 그 제품을 우리 현장에 제대로 앉혀 줄 사람을 두는 것이 중요합니다.
핵심 3줄
- 1쓰면서 배우면 아이디어가 생기는데, 초반 계약(명세)에 못박혀 있으면 그 아이디어를 살릴 수 없습니다.
- 2고객은 계속 요청하게 되고, 개발사는 계약 밖 일을 떠안습니다 — 중재가 없으면 양쪽 다 다칩니다.
- 3해법은 명세가 아니라 '질문'에 합의하고, 단계마다 다시 합의하며, 중간에서 조율하는 사람(PM)을 두는 것입니다.