최근 추천 기능 프로젝트를 진행하면서 데이터 팀과 처음으로 밀접하게 협업하게 됐습니다.
기존에는 기획-디자인-개발 삼각 구도로만 일해왔는데, 여기에 데이터 사이언티스트가 들어오니 소통 방식 자체를 다시 배워야 했어요.
몇 번의 실수를 거치며 정리한 소통 노하우를 공유해보려고 합니다.
프로젝트 초반에 데이터 팀에게 "얼마나 정확한 모델을 만들 수 있나요"라고 물었더니 "정확도 90% 정도는 나올 것 같아요"라는 답을 들었습니다.
저는 이 말을 듣고 안심했는데, 나중에 알고 보니 그 90%가 제가 생각한 것과 다른 의미였어요.
데이터 팀이 말한 정확도는 전체 예측 중 90%가 맞는다는 뜻이었는데, 저는 "사용자가 실제로 만족할 추천을 90% 확률로 준다"는 뜻으로 받아들였던 겁니다.
실제로 모델이 배포되고 나니, 특정 카테고리에서는 정확도가 급격히 떨어지는데도 전체 평균은 90%를 유지하는 상황이 생겼어요.
이 일을 겪은 뒤로는 "정확도"라는 단어를 쓸 때 반드시 "어떤 지표로, 어떤 데이터셋에서 측정한 정확도인지"를 같이 물어보는 습관이 생겼습니다.
데이터 팀과 킥오프 미팅을 하기 전에, 저는 이제 세 가지 질문을 반드시 준비해갑니다.
- 첫째, "이 모델이 틀렸을 때 사용자가 어떤 경험을 하게 되나요"입니다.
추천이 틀리면 그냥 관심 없는 상품이 하나 더 뜨는 정도인지, 아니면 사용자에게 실질적인 피해를 주는지에 따라 모델의 허용 오차 기준이 완전히 달라집니다. - 둘째, "학습에 필요한 데이터가 지금 충분한가요"입니다.
저희 프로젝트에서는 이 질문을 늦게 던져서 곤란했던 적이 있어요.
기획 문서를 다 쓰고 나서야 "사실 이 기능에 필요한 사용자 행동 데이터가 3개월치밖에 없다"는 걸 알게 됐고, 결국 출시 일정을 6주 미뤄야 했습니다. - 셋째, "모델 업데이트 주기는 어떻게 되나요"입니다.
한 번 학습시키면 끝나는 게 아니라 데이터가 계속 쌓이면서 모델을 재학습시켜야 하는데, 이 주기와 비용을 기획 초반에 계산해두지 않으면 운영 단계에서 예산 문제가 터집니다.
데이터 팀과 회의를 하다 보면 같은 단어를 다른 의미로 쓰는 경우가 자주 있었습니다.
저는 "성능"이라는 말을 "사용자가 느끼는 체감 속도"로 썼는데, 데이터 팀은 "모델의 예측 성능(precision, recall 같은 지표)"으로 이해하고 있었어요.
몇 번 회의가 엉뚱한 방향으로 흘러가고 나서야 이 차이를 알아차렸습니다.
그 다음부터는 회의 시작 전에 공유 문서에 "이 프로젝트에서 쓰는 용어 정의"라는 섹션을 만들어서, 정확도·정밀도·재현율·응답 속도 같은 단어를 우리 프로젝트 맥락에서 각각 어떤 의미로 쓸지 미리 못박아뒀습니다.
이 문서 하나 만든 것만으로 회의 시간이 확실히 줄었어요.
처음엔 "데이터 팀이 알아서 잘 만들어주겠지"라고 생각했는데, 실제로는 기획자가 사용자 맥락을 계속 통역해줘야 하는 역할이 크다는 걸 알게 됐습니다.
데이터 팀은 모델의 지표를 최적화하는 데 집중하는데, 그 지표가 실제 사용자 경험과 항상 일치하지는 않거든요.
예를 들어 저희 추천 모델이 "클릭률"을 최적화하도록 학습됐는데, 실제로는 자극적이지만 만족도가 낮은 상품을 계속 추천하는 방향으로 흘러간 적이 있습니다.
이걸 발견한 건 데이터 팀이 아니라 CS팀에 들어온 "추천이 이상하다"는 사용자 피드백이었어요.
그 이후로는 데이터 팀이 최적화하는 지표에 기획자가 "이게 정말 사용자 만족과 연결되는 지표인가"를 계속 검증해주는 역할을 맡게 됐습니다.
일반 개발 프로젝트는 기능 단위로 일정을 산정하는 게 익숙한데, AI 프로젝트는 "실험해보고 안 되면 다시 시도"하는 과정이 반복되기 때문에 일정 산정 자체가 다른 방식으로 이뤄져야 했습니다.
저희도 처음엔 "이 모델 개발에 4주 걸립니다"라는 말을 일반 기능 개발처럼 받아들였다가, 실제로는 4주 뒤에 "일단 학습은 됐는데 성능이 기대에 못 미쳐서 데이터를 더 보강해야 합니다"라는 답을 들었어요.
이후로는 AI 관련 일정은 "1차 실험 결과를 보는 데까지 얼마나 걸리는가"와 "그 결과를 보고 다음 단계를 결정하는 체크포인트"를 나눠서 계획하는 방식으로 바꿨습니다.
확정된 완료일을 요구하는 대신, 단계별 체크포인트를 여러 개 두는 게 서로에게 훨씬 현실적이었어요.
몇 달간 데이터 팀과 부딪히고 맞춰가면서 느낀 건, 완벽한 소통 프로세스보다 중요한 건 서로의 언어를 배우려는 태도였습니다.
저는 정밀도와 재현율의 차이를 공부했고, 데이터 팀 동료들은 사용자 여정 지도를 같이 그려보는 시간을 가졌어요.
서로의 용어를 완벽히 이해할 필요는 없지만, 적어도 "내가 지금 이해 못 하고 있다"는 걸 인정하고 물어보는 문화가 자리 잡으니 오해로 인한 사고가 눈에 띄게 줄었습니다.
다음 AI 프로젝트에서는 이번에 만든 용어 정의 문서와 체크포인트 방식을 템플릿으로 만들어서 처음부터 적용해볼 계획입니다.