사람들이 싫어하는 제품을 만드는 개발자의 생존법

유저가 내 제품을 욕할 때

개발자로 일하다 보면 한 번쯤은 이런 상황을 겪게 돼요. 내가 만든 기능에 대해 유저들이 불만을 쏟아내는 거예요. 트위터에서 욕을 먹거나, 커뮤니티에 "이 기능 왜 넣었냐"는 글이 올라오거나, 심지어 회사 전체가 비판의 대상이 되기도 하죠. 이런 상황에서 개발자는 어떻게 마음을 다잡아야 할까요?

Sean Goedecke라는 시니어 엔지니어가 이 주제에 대해 자신의 경험을 솔직하게 풀어놓은 글이 있어서 소개해드리려고 해요. 그는 실제로 유저들에게 미움받는 제품을 여러 번 만들어본 경험이 있는 사람인데요, 그 과정에서 배운 것들이 꽤 현실적이에요.

"싫어하는 제품"이란 구체적으로 뭘까

여기서 말하는 "사람들이 싫어하는 제품"이 뭔지 좀 더 구체적으로 얘기해볼게요. 단순히 버그가 많거나 품질이 낮은 제품을 말하는 게 아니에요. 제품의 존재 자체가 논란이 되는 경우를 말하는 거예요.

예를 들면 이런 것들이에요. 광고 시스템을 만드는 개발자, DRM(디지털 저작권 관리)을 구현하는 팀, 유료 구독 모델로 전환하는 프로젝트, AI가 기존 워크플로우를 대체하는 기능을 만드는 사람들. 이런 제품들은 기술적으로 아무리 잘 만들어도 유저들이 "이런 걸 왜 만들어?"라고 반응하는 경우가 많거든요.

핵심적인 통찰 중 하나는, 유저의 분노가 대부분 개발자 개인을 향한 게 아니라 비즈니스 결정을 향한 것이라는 점이에요. 유저가 "이 기능 만든 개발자 무능하다"고 할 때, 실제로는 "이런 방향으로 제품을 가져가는 회사가 마음에 안 든다"는 뜻인 경우가 대부분이에요.

그럼에도 불구하고 왜 만드는 걸까

"그냥 안 만들면 되잖아"라고 생각할 수 있는데요, 현실은 그렇게 단순하지 않아요. 회사가 수익을 내야 직원이 월급을 받을 수 있고, 수익을 내려면 때로는 유저가 좋아하지 않는 결정도 해야 하거든요.

이 글에서 흥미로운 관점은, "모든 제품 결정이 유저에게 사랑받을 필요는 없다"는 거예요. 유저가 싫어하는 기능이라도 비즈니스 관점에서는 필수적인 것들이 있어요. 예를 들어 인증 시스템을 더 까다롭게 만들면 유저 경험은 나빠지지만, 보안 사고를 예방할 수 있잖아요. 결제 흐름에 확인 단계를 하나 더 넣으면 귀찮지만, 환불 분쟁을 줄일 수 있고요.

중요한 건 그 결정에 대해 개발자가 스스로 납득할 수 있느냐는 거예요. "왜 이걸 만드는지" 이해하고, 그 이유에 동의할 수 있다면 외부의 비판을 견딜 수 있는 내면의 기반이 생기거든요.

실무에서의 생존 전략

이 글에서 제안하는 생존 전략들이 꽤 실용적이에요.

첫째, 유저 피드백과 감정적 공격을 구분하는 능력을 기르라는 거예요. "이 버튼 위치가 불편하다"는 건 피드백이고, "이런 쓰레기 기능을 만든 사람은 개발자 자격이 없다"는 건 감정적 공격이에요. 전자는 경청하고, 후자는 흘려보내야 해요.

둘째, 기술적 자부심을 제품의 인기와 분리하라는 조언도 있어요. 유저가 싫어하는 기능이라도 기술적으로 깔끔하고 견고하게 구현했다면, 그건 좋은 엔지니어링이에요. 광고 시스템도 잘 만들면 수십억 건의 트래픽을 밀리초 단위로 처리하는 정교한 시스템이거든요.

셋째, 자신의 윤리적 선을 미리 정해두라는 것도 중요한 포인트예요. 모든 비즈니스 결정에 동의할 필요는 없지만, "여기까지는 괜찮고 여기서부터는 안 된다"는 기준이 있어야 해요. 그 기준을 넘는 요청이 오면 그때는 진지하게 거부하거나 이직을 고려해야 하는 거고요.

한국 개발 문화에서 더 공감되는 이유

이 주제는 한국 개발 문화에서 특히 공감되는 부분이 있어요. 한국의 IT 기업들은 빠른 실행을 중시하는 문화가 강하고, 개발자가 제품 방향에 대해 목소리를 내기 어려운 경우가 많거든요. "일단 만들어"라는 지시를 받고 만들었는데, 결과물에 대한 비판은 고스란히 개발자에게 돌아오는 상황이 적지 않아요.

또한 커뮤니티나 앱 스토어 리뷰에서 "개발자가 무능하다"는 식의 댓글이 달리면, 실제로 그 기능의 기획이나 방향 결정에 관여하지 않았던 개발자가 상처받는 경우도 많죠.

이 글의 메시지는 결국 이거예요. 개발자로서 자기 일에 대한 건강한 거리두기가 필요하다는 것. 내가 만든 코드와 나 자신을 동일시하지 않는 것, 비즈니스 결정과 기술적 구현을 분리해서 바라보는 것, 그러면서도 자기 윤리적 기준은 지키는 것. 이 균형을 잡는 게 장기적으로 번아웃 없이 일하는 비결이에요.