엔지니어를 세일즈 최전선에 투입하면 일어나는 일

반발부터 시작된 실험

DevOps 시니어 엔지니어는 처음 이 제안을 들었을 때 창업자가 미쳤다고 생각했습니다.

나는 세일즈를 하려고 스타트업에 합류한 게 아니야.

하지만 창업자는 단 5번의 콜만 해보자고 설득했고, 그 후에는 다시는 강요하지 않겠다고 약속했습니다. 그리고 이 작은 합의가 회사 전체의 제품 철학을 바꾸는 전환점이 되었습니다.

고객의 진짜 목소리를 들으며 발견한 것들

복잡함에 지친 사용자들

엔지니어들이 세일즈 콜에 참여하면서 가장 먼저 깨달은 것은 경쟁사 제품이 비기술 사용자들에게 얼마나 복잡하게 느껴지는지였습니다. 개발자 입장에서는 당연해 보이는 기능들이 실제 사용자에게는 혼란의 원천이었던 것입니다.

아름다운 로그보다 단순한 녹색 체크마크

팀은 아름다운 로그와 정교한 지표를 자랑스러워했습니다. 하지만 고객들이 진짜 원하는 건 단순했습니다. “모니터링이 제대로 작동하고 있다”는 것을 보여주는 녹색 체크마크 하나였던 겁니다. 기술적 완성도보다 직관적 확신이 더 중요했습니다.

그냥 대신 해줄 수 없나요?

가장 충격적인 발견은 많은 고객들이 “누군가 대신 해줄 수 없냐”고 묻는다는 것이었습니다. 그들은 복잡한 도구를 마스터하고 싶어하지 않았습니다. 문제가 해결되기만 하면 되는 거였죠.

2주 만에 일어난 극적인 변화

과감한 기능 축소

엔지니어들은 PM의 개입 없이 스스로 새로운 아키텍처를 구상하기 시작했습니다. 그 결과는 놀라웠습니다:

• 60%의 기능을 과감하게 제거: 복잡함의 원인이 되는 불필요한 기능들을 정리했습니다.
• 직관적인 프로그레스 바 추가: 사용자가 진행 상황을 한눈에 파악할 수 있게 했습니다.
• Slack 연동 구축: 문의 흐름을 간소화하고 소통을 원활하게 만들었습니다.
• 대행 워크플로우 도입: 고객의 “대신 해줘” 요구를 직접 반영한 기능입니다.

70% 감소한 지원 티켓

이 모든 변화의 결과는 수치로도 명확하게 나타났습니다. 지원 티켓이 70%나 감소했습니다. 제품이 단순해진 만큼 사용자들이 헤매는 일도 줄어든 것입니다.

엔지니어링의 본질에 대한 새로운 통찰

우아한 코드 vs 문제 해결

이 실험을 통해 발견한 가장 중요한 교훈은 사용자들이 우아한 기술적 해결책에는 관심이 없다는 점입니다. 그들이 원하는 건 문제가 사라지는 것뿐입니다.

고객이 지친 목소리로 “그냥 이게 작동하기만 하면 돼요”라고 말하는 것을 직접 들은 엔지니어들은 완전히 다른 관점을 갖게 된 것입니다.

기능의 진짜 비용

모든 기능에는 비용이 따릅니다. 하지만 그 비용은 개발 시간이 아니라 사용자 혼란이라는 형태로 나타납니다. 코드 한 줄 한 줄이 사용자에게는 또 다른 학습 부담이 될 수 있다는 깨달음이었습니다.

문화로 정착된 고객 접점 경험

이제 이 회사에서는 모든 엔지니어가 분기마다 5회의 세일즈 콜에 참여하는 것이 의무화되었습니다. 처음에는 약간의 반발이 있지만, 고객의 피로감을 직접 듣고 나면 모든 것이 달라집니다.

업계의 뜨거운 논쟁

PM 역할에 대한 관점 충돌

레딧 커뮤니티에서는 이 사례를 두고 뜨거운 논쟁이 벌어졌습니다.

일부는 “좋은 Product Manager가 있었다면 이런 일이 애초에 벌어지지 않았을 것”이라며 엔지니어가 세일즈까지 해야 하는 상황 자체가 비효율적이라고 지적했습니다.

반면 다른 그룹은 “PM은 결국 번역기 역할에 그치며, 엔지니어가 직접 고객 문제를 소유할 때 최고의 결과가 나온다”고 반박했습니다.

단순화의 딜레마

“기능을 잘라내고 단순화하는 게 진짜 개선이냐”라는 비판적 시각도 있었습니다. 장기적으로는 파워 유저와 고급 기능에 대한 요구를 외면할 위험이 있다는 경고였죠.

긍정적 사례들의 공유

하지만 은행, 의료기기 등 다양한 업계에서 비슷한 경험을 한 사람들이 긍정적인 사례를 공유하기도 했습니다. 모든 직원이 고객 지원이나 영업을 체험하는 제도가 제품 품질과 문화 개선에 도움이 된다는 공감대가 형성되었습니다.

기술 중심 사고를 넘어서

과도한 엔지니어링의 함정

이 사례가 보여주는 가장 중요한 메시지는 “엔지니어의 가장 큰 문제는 사실 과도한 엔지니어링”이라는 점입니다.

기술적 정확성보다 사용자 이해가 더 중요하다는 것, 아무리 잘 만들어도 사용자가 쓸 수 없다면 의미가 없다는 것을 보여줍니다.

균형 잡힌 접근의 필요성

고객 문제를 직접 체감하게 하는 것은 분명 강력한 학습 도구입니다. 하지만 장기적으로는 전문적인 PM, UX, 디자인 역량과 결합되어야 균형 잡힌 제품 전략을 만들 수 있다는 점도 중요합니다.

진짜 혁신은 어디서 시작되는가

여러분의 회사에서도 엔지니어들이 고객과 직접 만날 기회가 있나요?

이 스타트업의 실험은 단순히 개발 프로세스의 변화를 넘어, 사용자 중심 사고의 중요성을 보여주는 사례입니다. 때로는 가장 우아한 코드보다, 가장 정교한 기능보다, 고객의 한마디 “그냥 작동했으면 좋겠어요”가 더 큰 혁신을 만들어낼 수 있습니다.

기술의 발전이 빨라질수록, 우리는 더욱 사용자의 진짜 목소리에 귀 기울여야 하지 않을까요?