Q.044 지금까지 일하면서 가장 힘들었던 경험은?
[Chapter 2. 일하는 방식] 어떻게 생각하고 행동하나요?
PM 커리어 150문 150답 내용 발췌PM으로 일하면서 가장 힘들었던 순간을 꼽으라면, 한 달 동안 공들여 만든 기능을 출시 직전에 롤백한 경험이다. 팀 전체가 달려서 만든 기능을 배포 직전에 멈춘 건, 단순히 아까워서가 아니라 더 큰 문제를 막기 위한 선택이었다.
1. 배포는 가능했지만, 사이드 이펙트 리스크가 너무 컸다
당시 유저 니즈를 검증하기 위한 기능이었다. 사용자들이 특정 기능을 원한다는 피드백이 있었고, 빠르게 만들어서 데이터를 보자는 방향으로 프로젝트가 진행됐다. 한 달 동안 개발하고, QA도 통과했고, 출시만 남겨둔 상황이었다.
그런데 배포 직전에 개발팀에서 "이 코드가 다른 기능에 영향을 줄 수 있다"는 우려를 제기했다. 기술적으로 배포 자체는 가능했지만, 배포 후 예상치 못한 사이드 이펙트가 생길 가능성이 있다는 거였다. 다른 코드에 치명적인 문제가 생길 수도 있다는 이야기였다.
2. 데이터를 볼 수도 있지만, 비즈니스 임팩트가 리스크만큼 크지 않았다
'그래도 배포해서 데이터를 보면 유저 니즈를 검증할 수 있지 않을까?'라는 생각과 '사이드 이펙트가 생기면 다른 기능까지 문제가 생길 수 있을 것 같은데'라는 생각이 충돌했다. 개발팀과 여러 번 논의했고, 결국 멈추기로 했다.
리스크가 너무 컸다. 다른 기능에 영향을 줄 가능성이 있고, 그게 치명적일 수 있었다. 게다가 이건 유저 니즈를 검증하는 단계였다. 확실하지 않은 상태에서 리스크를 감수할 필요가 있을까 싶었다. 무엇보다 PM인 내가 기술적 깊이를 제대로 이해하지 못한 채 프로젝트를 진행한 게 근본 원인이었다.
팀 회의를 열어서 상황을 설명했다. "배포를 멈추고, 기술적 문제를 해결한 후 다시 진행하자"라고 제안했다. 개발자들은 당연히 아쉬워했다. "한 달 동안 만든 걸 그냥 버리는 거예요?" 하지만 데이터를 보여주고, 리스크를 설명하면서 "이대로 가면 더 큰 낭비가 된다"는 걸 설득했다.
3. 프로젝트 시작 전에 기술적 제약을 더 깊이 물어봤어야 했다
그 경험 이후로 달라진 게 있다. 프로젝트를 시작할 때 개발팀과 기술적 제약을 먼저 논의하는 것이다. "이 기능을 만들면 다른 코드에 어떤 영향을 주나요?", "사이드 이펙트 가능성은 없나요?"를 꼼꼼히 확인하고, 리스크가 크면 다른 방법을 찾는다. 한 달짜리 프로젝트를 진행하기 전에, 1주일짜리 프로토타입으로 기술적 리스크를 먼저 확인하는 것도 습관이 됐다.
롤백 결정을 내리는 게 쉽지 않았지만, 잘못된 방향으로 가는 걸 멈추는 것도 PM의 역할이라는 걸 배웠다. 팀원들에게 미안했지만, 더 큰 문제를 막는 게 우선이었다.
한 달 만든 기능을 롤백한 경험은 아직도 기억에 남아있다. 배포는 할 수 있었지만, 사이드 이펙트 리스크가 비즈니스 임팩트보다 커서 멈췄다. 물론 그 덕분에 프로젝트 시작 전에 기술적 제약을 더 깊이 논의하게 됐고, 작게 검증한 후 크게 만드는 습관이 생겼다.
* 전체 내용을 정리한 전자책은 아래에서 확인할 수 있습니다.