마지막엔, 그들은 내 “PMing” 없이 완전히 새로운 아키텍처를 구상했음. 그 이유는 우리 제품을 실제로 사용하는 사람이 누구인지 드디어 제대로 이해했기 때문임. 이 경험을 전체적으로 보면, “엔지니어한테 세일즈 콜을 맡겨봤더니, 결국 문제는 PM들이 고객과 엔지니어링 사이 소통을 제대로 못 하고 있었고, DevOps 엔지니어가 오히려 고객 니즈를 실제 작동하는 솔루션으로 빠르게 전환하는 사람이었다”는 결론임
엔지니어가 자신감에 차 있어서 사용자가 제품을 잘못 쓴다고 생각하는 경우가 있음. 이는 “사용자가 멍청하게 굴어서” 생긴 일이지, 내가 만든 복잡한 디자인에는 문제가 없다는 논리임. Desktop Linux 진영 사람들만 해도 사용자 불만을 무시한 경험으로 책 한 권 쓸 수 있을 정도임. 고집 센 엔지니어가 PM과 사용자보다 본인이 낫다고 여기면 아무 일도 진전이 없음. 하지만 그런 엔지니어를 사용자 직접 상대하게 던져놓으면, 평소 친근한 PM 대신, 실제 짜증 내는 유저들이 “이 멋진 창조물”이 마치 문제 많은 햄스터라도 되는 양 혹평을 쏟아냄. 이런 과정은 두려움도 주지만 엔지니어 자존감도 무너지게 함. 내 관점에선, 이건 PM이 멍청하다고 보여주려는 게 아니라 엔지니어를 겸손하게 만드는 일임. 시간이 지나면 또 엔지니어 자만심이 돌아와서 이 과정은 반복적으로 필요함
나는 대형 기업의 기계공학팀에서 오직 코드를 쓸 수 있는 사람임. 사내 IT팀이 다양한 소프트웨어를 직접 만들지만 대다수는 팀원들 눈엔 별로임. 그래서 아예 이걸 새로 만들거나, 도저히 대체 못 하는 “별로인” 프로그램을 보완하는 툴을 직접 고안해서 일을 쉽게 함. 내가 인하우스 IT팀보다 개발을 잘한다기보다는, 실제 사용자 시각 때문에 본인, 즉 우리 팀에 진짜 필요한 게 뭔지 더 잘 파악한다는 생각임. 그리고 내가 바로 이 소프트웨어를 쓰는 사람이니 당연히 동기부여도 높음. 그래서 글 제목이 나한테 공감이 갔음. 단, 본문에서 말하는 부분도 현업에서 충분히 일어날 수 있다고 생각은 함. 나는 공식적인 소프트웨어 개발/프로젝트 관리 프로세스에는 익숙하지 않음
나는 연 200만 달러 매출의 작은 테크 스타트업 경영 중임. 종종 지원 인력이 부족할 때 직접 며칠간 고객 지원을 맡기도 했음. 그럴 때마다 신기하게도 평소엔 엔지니어팀엔 전혀 안 전달되는 고객 불만 사항을 잔뜩 발견함. 지원 담당자들이 문제를 자체적으로 “해결”하는 데 집중해서 근본적인 개선이 엔지니어링까지 이어지지 않는 경향이 있음
원래 소프트웨어가 왜 그렇게 엉망이었는지, 아무도 궁금해하지 않은 게 눈에 띔. 내 생각엔 PM 한 명에게 책임을 다 넘길 수는 없음. 사실은, Agile/Scrum 같이 책임이 흐려지고 개발자들이 엉성하게 만들어진 티켓들을 너무 빠른 주기로 처리하느라 결국 이렇게 어설픈 소프트웨어가 생기는 시스템 문제임. “현대” 소프트웨어 조직이 비대해지면 흔히 나오는 결과물임
이 글을 보고 든 첫 생각이 “PM이 다 개입하기 전, 소프트웨어는 원래 이렇게 만들어졌었지”임. 엔지니어를 실제 운영하는 사람 옆에 앉혀두면, 사실 PM이 필요 없고 모두가 훨씬 행복해지는 경험을 자주 함. 물론 PM 중에도 대단한 사람들 있긴 한데, 내 경험상 PM들은 영역 싸움에 집착하는 경향이 있고, 놀랍게도 엔지니어링이나 고객 쪽 모두에 대해 잘 모르는 경우도 많음
많은 곳에서 엔지니어가 제품과 엇박자가 난 경험을 여러 번 겪었음. 동료가 모르게 뭔가 추가해뒀다가 UI가 헷갈리거나, 웹사이트 내용이 제품 실제와 안 맞는 경우도 있었음. 또, [제품 -> PM -> 버그 트래킹 시스템 -> 엔지니어 -> 수정 -> QA -> 제품] 식의 긴 루프 때문에 중요한 건 고쳐지는데, 사소한 불편은 정말 오랫동안 안 고쳐짐. [제품 <-> 엔지니어]만 남기면 놀라울 정도로 생산성 향상 가능함. 많은 엔지니어가 실제로 제품 전체 경험을 직접 해본 적도 잘 없고, 올해와 작년의 차이도 잘 모르는 경우가 있음
나도 비슷한 경험을 가졌는데, 신기하게도 PM이 많은 곳에서 이런 현상이 더 자주 있었음. 내가 겪은 최악의 경험은 한 회사에서 PM과 “Product Designer”를 엔지니어 숫자에 맞춰 강제 비율로 배정하려 한 경우임. 디자이너, 제품, 프로젝트, 프로그램 담당자 전부 합치면 엔지니어 수보다 더 많음. 결국 더 최악의 상황만 만들어졌음. PM들의 관료주의와 내 역할 침해 우려를 피해다니는 것도 일이었음. 뛰어난 PM은 정말 소중하지만, 요즘 Product Management라는 타이틀은 관료적이고 프로세스에 집착하는 사람이 너무 많이 모여든 느낌임. Product Management 인플루언서들도 문제를 심화시키고 있음
그렇다고 엔지니어를 억지로 세일즈콜에 투입하는 것도 정답이라 생각하진 않음. 전화 한 통을 성공적으로 진행하려면 다양한 소프트 스킬이 필요하고, 엔지니어는 그런 분야로 훈련도 안 돼 있고, 채용 때도 고려 대상이 아님. (‘세일즈콜’이라 함은 데모나 PoC 전의 초기 상담콜 의미. 복잡한 프리세일즈 데모에는 엔지니어가 동행하더라도, 그 역할은 원칙적으론 제품 담당이 해야 맞다고 봄)
잘못될 수 있는 경우가 정말 다양한데, 나는 그런 모든 사례를 직접 본 적 있음. 예를 들어, 모든 고객 소통을 PM이나 PO가 독점하게 하거나, 고객이 개발자와 대화 자체를 피하면서 사용자 매니저 요구사항만 해석해서 전달하는 경우, 개발자 본인이 오직 코드만 쓰고 싶어 하거나, 모든 소통을 PM과 버그 트래커로만 하도록 강요하는 경우 등 정말 다양함. 또, 상용 소프트웨어 플랫폼 쓸 때는 기술적 한계로 워크플로우가 무척 별로가 될 수 있음. 항상 어딘가 소통을 막는 요인이 있고, 고객/중간관리자/개발자 누구든 그걸 가로막을 수 있음. 심지어 잘못된 솔루션을 처음부터 정해놓고 개발자나 사용자는 세부 내용을 전혀 모른 채 시작하는 경우도 적지 않음. 사용자에게 진짜 좋은 시스템을 만들지 못하는 길이 정말 많음
엔지니어들이 제품 자체를 깊이 이해하는 게 정말 중요하다고 생각함. 기본적인 엔지니어링보다 제품 측면이 맞아떨어지는 게 더 어려운 지점임. 내가 경험한 대부분의 제품이 결국 제품적인 이유 때문에 실패했기에, 팀의 강점을 이쪽에 맞추는 게 논리적으로 더 맞는 포인트라 봄
반대로, 엔지니어가 결국 기술 지원팀의 역할로 전락하는 경우도 있음. 각 고객사를 직접 지원하다 보면 핫픽스와 개별 맞춤 솔루션만 쌓이게 되고, 이 모든 게 제대로 테스트도 못 하니 기술 부채만 쌓이고, 크고 제대로 된 투자받은 경쟁사가 더 멋진 제품 만들면 금방 도태됨. 이건 전형적인 제품 관리 실패라고 생각함. PM이 고객 니즈를 엔지니어에게 제대로 전달 못 하거나, 그 반대로도 Push를 못 한다는 얘기임. 엔지니어가 세일즈콜에 투입되는 건, 고객층이 어느 정도 커지고 성숙해지면 확장성 없는 방법임. 만약 제품 관리자가 엔지니어에게 세일즈콜 하길 진짜 원한다면, 그 엔지니어도 각 계정의 커미션 일부를 받아야만 공평함. 내가 커미션 없이 세일즈콜 맡는 일은 절대 없음
스타트업처럼 모든 팀원이 고객 니즈에 깊이 공감이 필요한 환경엔 매우 뛰어난 전략임. 내가 제품 요구사항을 실제로 정의하는 데 참여해서 실무를 꿰뚫고 있을 때 프로젝트 성공률이 훨씬 높았음. 반면 요구사항만 “넘겨받아” 그대로 구현할 때보다 훨씬 더 좋은 결과물이 나옴
내가 실제로 지침을 썼으니 따르기 더 쉬웠다는 뜻인가, 아니면 직접 참여해서 더 나은 UX가 나온다는 말인가 궁금함
“2주 만에 리라이트 완성, 기능 60% 제거, 단순 진행바 추가, Slack 연동 구축, ‘done-for-you’ 워크플로우 제공→ 지원 티켓 70% 감소” 이게 진짜면 뭔가 심각하게 잘못된 상황임
Reddit은 창작글 폭증으로 유명하고, 이 이야기 역시 실화에 영감을 받았든 완전 창작이든, 전형적인 Reddit식 글쓰기 요소에 LinkedIn식 비즈니스 스토리텔링 느낌이 가득함
이건 B2B SaaS가 여러 번 피벗을 거치면서도 제품 관련 가이드가 빈약했던 경우라 봄. 물론 이런 방식으로 일이 꼬이는 경우가 생각보다 아주 흔함
LinkedIn 스타일의 짧은 문장 뒤 극적인 결말이 반복되는 어투 보면, 이건 창작임을 쉽게 눈치챌 수 있음
Reddit이니 당연히 창작임. 이런 글이 어쩌다 이런 화제가 되는지 모르겠음
이런 결과라면 당장 PM, PO, 마케팅팀 다 해고해야 함. 두 가지가 분명함: 첫째, 그 사람들이 고객이 실제로 뭘 원하는지 파악도 못 했거나, 그 니즈를 개발팀에 제대로 전달 못 했거나, 둘 다임. 둘째, 머릿속이 너무 시스템적으로만 굴러가서, 차라리 고객과 개발팀 사이 모든 중간 단계를 없애버리는 게 나을 수도 있음
예전 직장에서도 엔지니어가 영업콜에 꾸준히 들어가곤 했음. 어떤 고객이 뭘 원하는지, 우리 제품이 어떻게 팔리는지 체험하는 건 흥미로웠지만, 획기적이진 않았음. 고객이 원한 기능은 이미 로드맵에 있었고, 헷갈리는 기능 하나도 있었지만 그건 최대 고객사의 특수 요구 때문에 그렇게 설계됐었음. 개발팀은 좀 더 단순하게 만들고 싶었지만 그럴 경우 큰 고객사 요구를 충족할 수 없었음. 결국 쉽게 쓸 수 있는 “라이트” 버전을 따로 만들고, 큰 고객사 빼고 전부 그걸 쓸 수 있게 함. 그런데 이런 변화도 영업콜 동행 때문이 아니라, 모두가 어려운 줄은 처음부터 알았으나 로드맵에 반영될 때까지 바꿀 순 없었음
“실사용자가 누구인지 드디어 제대로 이해하게 됨”이라는 부분에 깊이 공감함. “대부분 엔지니어의 최대 문제는 오버 엔지니어링”이라고 하지만, 실상은 고객 사용사례를 제대로 이해 못 해서 오버 엔지니어링이 발생하는 경우가 더 많음. 이 부분이 더 본질적인 문제임. 나도 엔지니어로서 가장 자주 겪는 답답함은, 다른 엔지니어들이 실제로 팔리는 제품이 뭔지 알려고 들지 않는다는 점임. 이유는 업무적 적합성이든, 자존심이든, 대개는 조직 문화나 인센티브 구조 때문임
예전에 CRM용 로보콜 솔루션 만드는 회사에 있었는데, 오프사이트 행사 때 모든 사람이 직접 콜드콜 해보고 대본대로 따라 해보자고 했음. 이게 비영업 인력한테 어떤 불안감을 주는지 이해도 없고 관심도 없음. 그 일 이후로 이직을 생각하기 시작했음
예전에 비슷한 상황을 직접 본 적 있음. 모니터링팀이 “모든 경보를 프런트라인 엔지니어가 직접 티켓으로 등록해야 한다”고 주장함. 그런데 경보가 시간당 1만 개 이상임. 중요한 이슈가 다 ‘노이즈’ 속에 묻히다 보니, 관리진도 지치고, 한 번은 ‘모니터링팀 네가 한번 전부 직접 티켓 열어서 해결해 봐’라고 강제하게 됨. 그 다음 날엔, 중요도 낮은 알람을 배제하니 고유 알럿이 시간당 십여 개로 줄었고, 나머지도 순차적으로 다 닫힘. 이때야 비로소 “보드가 다 초록 불”이 진짜가 됐음(그 전엔 미디어랑 Gartner Group 보여주려고 억지 녹색을 칠했을 뿐이었음)
Hacker News 의견