사람들이 싫어하는 제품에서 일하게 된 개발자들에게

^{source https://www.seangoedecke.com/working-on-products-people-hate/}

뭔가 위로받는 느낌과 공감가는 내용이 많은 글이네요.

나는 사람들이 별로 좋아하지 않는 제품을 많이 맡아 왔다.

Zendesk에서는 없애기엔 너무 유용했지만, 그렇다고 사람들이 좋아할 만큼 충분히 다듬어지지는 못한 앱 마켓플레이스의 큰 부분을 만들었다. 지금은 GitHub Copilot에서 일하는데, 많은 사람이 이걸 형편없다고 생각한다.

예전에는 대체로 호감 쪽이었고, Cursor와 Claude Code가 나오면서 비호감이 됐고, 지금은 Copilot CLI tool이 다시 사람들 생각을 바꾸고 있다고 꽤 확신한다. 세상 일이 늘 그렇다.

그 사이 잠깐씩은 사람들이 정말 좋아하는 제품을 맡은 적도 있었다. 예를 들어, 인기 있는 Gist에 댓글이 서른 개를 넘으면 타임아웃이 나던 버그를 고쳤고, GitHub markdown에 LaTeX 수식을 직접 쓸 수 있게 하는 일에도 조금 보탰다. (물론 그것조차 당시에는 꽤 격한 비판을 받았다.)

하지만 지난 몇 년 동안 내가 주로 해 온 일은 사람들이 싫어하는 제품에서 일하는 것이었다.

물론 "모든 사람이 그 소프트웨어를 싫어한다"는 뜻도 아니고, 심지어 "사용자의 절반 이상이 싫어한다"는 뜻도 아니다. 그냥 인터넷에서 읽게 되는 반응 대부분이 칭찬보다 불평일 정도로, 싫어하는 사람이 충분히 많다는 뜻이다.

내가 더 뛰어난 개발자였다면, 사람들이 좋아하는 제품을 더 많이 맡았을까? 아니다. 좋은 소프트웨어가 언제나 사랑받는 제품을 만든다고 치더라도, 큰 회사의 소프트웨어는 팀 이 만들고, 그 팀은 인센티브 에 의해 움직인다. 아주 뛰어난 엔지니어라면 자기 담당 영역의 소프트웨어 품질을 조금은 끌어올릴 수 있다. 하지만 그 코드도 결국 회사의 다른 시스템들과 맞물려 돌아가야 하고, 다른 엔지니어들이 계속 수정하고 확장하게 된다. 그러다 보면 한 사람의 영웅적인 노력은 수많은 코드 커밋 속에 묻혀 버린다. 이 이야기는 How good engineers write bad code at big companies에서 길게 쓴 적이 있다.

돌이켜보면, 내가 만든 소프트웨어 중 일부를 사람들이 아주 싫어했다는 사실이 오히려 다행이다. 석유 재벌 집안에서 태어나지 않은 게 다행인 것과 같은 이유다. 커리어 내내 인기 많은 애플리케이션만 맡았다면, 아마 그게 순전히 내 재능 덕분이라고 믿었을 것이다. 하지만 실제로는 엔지니어링 품질만 보고 내가 맡았던 제품 중 무엇이 사랑받고 무엇이 미움받을지 예측할 수 없다. 사랑받는 기능 중에도 내부는 꽤 위태로운 경우가 있고, 처참하게 실패한 기능 중에는 안쪽 구조만 보면 대성당처럼 공들여 지은 것들도 많다.

이건 바깥에서 tech company의 품질을 판단할 수 없는 이유가 또 하나 추가된 셈이다. 아무리 그러고 싶어도 말이다("insider amnesia"에 대한 글도 참고).

사람들이 싫어하는 제품에서 일해 보면, 사람들이 자기가 만든 것을 좋아할지 말지에 대해 개인 엔지니어가 실제로 쥔 통제력이 얼마나 작은지 받아들이게 된다.

사실 믿고 맡길 수 있는 엔지니어라면 사람들이 싫어하는 제품에서 일하는 것도 편하게 받아들일 수 있어야 한다. 엔지니어는 users 가 아니라 company 를 위해 일하기 때문이다. 물론 회사는 사용자를 만족시키고 싶어 한다. 만족한 사용자는 기꺼이 많은 돈을 내기 때문이다. 그리고 우리도 운이 좋으면 적어도 가끔은 그런 일을 할 수 있다. 하지만 늘 그런 건 아니다. 예를 들어, 예전에는 넉넉했던 사용량 제한을 강화해야 할 수도 있고, 더는 수익을 낼 수 없는 사랑받던 제품을 종료해야 할 수도 있다. 어떤 제품은 겨우 존재할 만큼만 예산이 붙고, 사랑받을 만큼은 아닌 경우도 있다. 많은 엔터프라이즈용 "체크박스 채우기" 기능들이 그렇다. 그리고 그건 거기 참여한 엔지니어가 어쩔 수 있는 일이 아니다.

사람들이 싫어하는 제품에서 일하는 건 감정적으로 꽤 힘들 수 있다. 내가 만든 것에 대한 부정적인 피드백을 읽는 일은 거의 개인 공격처럼 느껴진다. 그들이 불평하는 결정이 내 결정이 아니었다 해도 그렇다. 이런 감정적 고통을 피하려다 보면, 피드백을 아예 무시해 버리거나, 어차피 멍청한 사용자들보다 내가 훨씬 똑똑하다고 스스로를 설득하는 실수를 저지르기 쉽다. 반대로 너무 멀리 가는 실수도 있다. 완전히 "사용자 편"에 서서, 기술적으로든 정치적으로든 불가능한 일인데도 상사에게 사용자가 원하는 걸 하자고 밀어붙이기 시작하는 것이다. 둘 다 실수다. 엔지니어로서의 핵심 책임을 내려놓는 행동이기 때문이다. 그 책임이란 회사가 지속 가능하게 감당할 수 있는 것과 사용자가 원하는 것 사이에서 어떻게든 균형 을 찾으려는 일이다. 이건 정말 어렵다!

그래도 사람들이 싫어하는 제품에서 일할 때 좋은 점이 하나 있다. 사람들이 싫어한다는 건 결국 그 제품을 쓰고 있기 때문 이다. 진짜 최악의 제품은 미움받는 제품이 아니라 그냥 무시되는 제품이다. 그리고 싫어하는 제품에서 일하는 게 힘들다고 생각한다면, 아무도 신경 쓰지 않는 제품에서 일하는 건 그보다 훨씬 더 힘들다. 사람들이 싫어하는 제품은 대개 사용자에게 꽤 많은 가치를 주고 있다. 적어도 엔터프라이즈 소프트웨어라면 구매자에게는 그렇다. 그 비난을 견딜 만큼 멘탈이 단단하다면, 이런 자리에서도 꽤 많은 좋은 일을 할 수 있다. 널리 쓰이지만 사람을 짜증 나게 하는 제품을 조금이라도 더 낫게 만드는 일은, 큰 구조적 문제를 고칠 위치에 있지 않더라도 꽤 임팩트가 크다.

거의 모든 엔지니어는 사람들이 싫어하는 제품에서 일하게 된다. 그냥 평균의 법칙 때문이다. 사용자 감정은 시간에 따라 오르내리고, 당신의 제품이 영웅으로 죽지 않는다면 오래 살아남아 결국 악당이 된다. 그렇다면 인기가 없는 제품에서 일하는 엔지니어를 비난하지 않는 편이 맞다. 그러지 않으면 당신 차례가 왔을 때 결국 자기 자신을 탓하게 되고, 커리어에서 사용자에게 진짜 긍정적인 영향을 줄 수 있는 가장 좋은 기회들을 놓치게 된다.