시야를 확장하기
일을 하다 보면 레벨업의 시기가 온다. 내가 하던 방식이 더 이상 충분하지 않다는 걸 깨닫는 순간. 위에서 기대하는 기준이 버겁게 느껴지고, 책을 다시 펼쳐야겠다는 생각이 들 때. 나에게는 지금이 그렇다.
작년 4월부터 AI 프로젝트에 서브 PO로 참여했고, 이번 달부터는 하나의 대형 프로젝트를 온전히 맡게 되었다. 역할이 바뀌자 가장 먼저 달라진 것은 책임의 범위였다. 서브 PO로 있을 때 나는 주로 기능과 버그를 다뤘다. 주어진 문제를 해결하고, 테크 이슈를 정리하고, 실행을 밀어붙였다.
그런데 그것만으로는 부족한 때가 왔다. 이제는 기능 하나가 아니라 프로덕트 전체를 바라봐야 한다. 어떻게 해결할 것인지보다, 무엇을 먼저 해결해야 하는지를 결정해야 한다. 그 차이가 생각보다 컸다.
최근 모델이 잘못된 카드를 넣는 비율이 높아졌다. 원인을 추적하니 사람이 입력한 SOP가 잘못되어 있었다. 나는 곧바로 SOP를 자동 입력해주는 모델을 만들자는 해결책을 제안했다. 이전의 내 업무스콥이었다면 나쁘지 않은 결과였을 것이다. 루트커즈를 명확히 찾아냈고, 해결책을 정의했고, 실행 계획을 세웠다. 하지만 이번에는 달랐다. 나는 기능 단위에서 사고하고 있었다. 프로덕트 단위에서 사고하지 못했다.
이 문제가 프로덕트 전체 성과에 얼마나 영향을 주는지, 그리고 이를 해결하는 데 들어가는 리소스가 현재의 병목을 악화시키는지까지 고려했어야 했다. 팀 전체에서 가장 큰 병목은 MLE다. 그렇다면 내 1차 고객은 Ops팀이 아니라 MLE다. 그들이 가장 효율적으로 성과를 낼 수 있도록 리소스를 정렬하는 것이 우선이다. 한참 곱씹고 나서야 깨달았다. 내 역할은 기능을 완성하는 사람이 아니라, 목표를 달성할 수 있도록 팀을 진전시키는 것이라는 것을. 이를 위해서는 한정된 리소스를 어디에 쓸지 결정하는 것이 가장 중요하다. 책 '더골'에서 얘기했던 제한된 자원에 대한 관리가 떠올랐다. 아하 모먼트였다.
처음 SOP 이슈를 마주했을 때는 막막했다. 이미 수십만 개의 상품이 과거 SOP를 기반으로 처리된 상태였다. 규모가 압도적으로 느껴졌다. 사람은 절대 할수가 없고 오로지 모델이나 벌크업데이트만이 방법이라고 생각했다. 하지만 문제를 덩어리로 보면 감당이 되지 않는다. 전체를 지금 당장 해결해야 하는지, 장기적으로 더 효율적인 해결책은 없는 지 구조로 보면 나뉜다. 즉시 수정 가능한 영역, 데이터 정합성 점검이 필요한 영역, 장기적으로 개선해야 할 영역. 이렇게 쪼개고 나니 문제는 움직이기 시작했다. 주어진 문제를 당장 지금 모두 해결해야 하는 것은 아니다. 문제를 쪼개어서 이 프로덕트를 위해서 지금 가장 중요한 것에 집중하면 된다.
문제를 쪼개고 나면 액션 아이템이 된다. ETA가 정해지고, 프로그램이 굴러간다. PO의 역할은 모든 것을 직접 해결하는 것이 아니다. 문제를 해결 가능한 상태로 설계하는 것이다. 숏텀으로 불을 끌 수 있는 부분은 빠르게 분리해 맡기고, 나는 구조적인 개선에 집중했다. 실행은 전문가들이 한다. 나는 실행의 구조를 만든다.
이 또한 시야의 확장이다. 실행자에서 설계자로 한 발짝 내딛었다.
초기에 제안한 솔루션이 예상보다 많은 리소스를 요구한다는 사실을 알았을 때, 나는 쉽게 방향을 바꾸지 못했다. 이미 생각해둔 그림이 있었기 때문이다. 하지만 쉽게 생각했던 초반과 달리 깊게 파면 팔수록 아예 새로운 모델이 필요한 일이었다. ROI측면에서 리소스의 인풋을 커버할만큼 큰 문제인지 생각하고, 아니라면 피봇해야 한다. 피봇은 실패가 아니라, 더 큰 관점에서의 합리적 선택이다.
돌아보면 이번 경험의 핵심은 하나다. 작은 기능레벨을 실행하는 것이 아니라 프로덕트 레벨에서 설계하는 방향으로 시야를 넓혀야 한다는 것이다. 이것이 AI PO로서 내가 배워야 할 가장 중요한 감각일 것이다.