1960년대쯤 활발히 개발된 듯한 소도시를 꽤 다녀봤는데, 야심 차게 지은 공원이나 주민센터가 완공된 채 버려져 폐허가 된 모습을 자주 봄. 그때마다 유지관리 비용을 계산해야 한다는 교훈을 얻음. 멋진 인공 수로를 만들어도 도시가 운영·청소·용수 공급 비용을 감당할 수 있을까? 개발업자도 비용 분석은 했겠지만, 버려진 시설을 보면 계산이나 판단이 잘못됐다고 볼 수밖에 없음.
소프트웨어에서도 범위가 계속 늘어나면 집중력이 흐트러지고, 아무도 필요로 하지 않는 기능을 만드느라 의욕이 떨어짐. 하지만 결국 늘어나는 유지보수 비용이 팀의 역량 전체를 소진시킬 수 있음. 아무리 잘 만든 결과물도 유지보수가 필요하므로 모든 프로젝트의 운영 예산에 이를 반영해야 함.
엔지니어부터 엔지니어링 관리자, CTO까지 겪는 비극은 하지 않기로 한 일로는 승진하기 어렵다는 것임. 제품팀과 이사회를 설득해 프로젝트를 포기하거나 범위를 줄인 적이 수없이 많고 회사에도 도움이 됐다고 확신하지만, 개발 조직은 결국 분위기를 깨는 역할이 됨. 감당은 해도 마음이 편하지는 않은데, 이를 건강하게 다루는 방법이 있다면 듣고 싶음.

섬유 제조업이 전부 아시아로 옮겨가면서, 합리적인 투자였지만 결과가 나빴던 것일 수도 있지 않을까?

계산 착오가 아니라 이해관계의 불일치일 수도 있음. 부동산 개발업자는 장기 유지관리 비용을 책임지지 않았고, 사업을 추진한 공무원도 그 비용이 청구될 때면 자리를 떠났을 가능성이 큼.
기술 업계도 회사 안팎으로 이동이 잦고 한 팀에서 일하는 기간이 몇 년에 불과해 비슷함. 장기적인 판단에서 실제로 도덕적 해이가 생길 수 있는 구조임.

이런 소도시는 어디에서 볼 수 있나? 내가 사는 곳 근처에는 설명에 들어맞는 곳이 떠오르지 않아 궁금함.

그런 시설이 실패한 이유는 따로 있을 듯함. 자본주의가 미국 소도시를 무너뜨린 결과라고 봄.

이런 취지의 글을 자주 보는데 양가적인 생각이 듦. 이제 LLM으로 원하는 기능이나 시제품을 빠르게 만들 수 있지만, 바로 그 속도가 함정이기도 함.
“배를 더 빠르게 만드는가?”라는 기준은 좋지만, 누가 그 답을 알까? 엔지니어가 아는 경우는 드물고, 제품 담당자는 자기 영역에서 감이 좋은 편이며, 좋은 회사의 경영진은 대체로 방향이 맞아 있음. 그래도 한 사람이 결정할 수 있는 일은 드묾.
이제 와서 무슨 새로운 얘기가 있겠나 싶어 이런 글이 뜨면 대개 짜증이 나지만, 결국 매번 읽게 됨.

이론적으로는 그렇지만, 실무에서는 조직 내 누구도 세부 사항에 프로그래머만큼 깊이 관여하지 않아서 프로그래머가 이런 결정을 상당수 직접 내리게 됨.

요즘 소프트웨어를 만들고 새로운 것을 배우는 일이 너무 빠르고 저렴해져서, 나도 자주 그 매력에 빠짐.
오늘은 정말 만들고 유지보수하고 싶은 것이 무엇인지, 그리고 내가 안 만들면 다른 누구도 만들지 않을 듯하고, 세상에 없으면 내가 몹시 아쉬워할 것이 무엇인지 생각해 봄. 새로운 질문인지는 모르겠고 시대마다 반복되는 고민일 수도 있지만, 흥미로울 것 같아 공유함.

내가 즐겨 하는 말은 출시하는 가장 좋은 방법은 기능을 줄이는 것임. 엔지니어링 리더라면 제품·디자인 조직을 상대로 늘 이를 주장해야 함.

더 좋은 방법은 애초에 그런 기능을 개발 계획에 넣지 않는 것임.

제품 기능을 가치를 더하는 기능, 차별화 없이 기본으로 갖춰야 하는 기능, 그리고 잘못 만들어 가치를 깎는 기능으로 나눠 봄. 회원가입과 로그인이 좋은 예임. 꼭 필요하지만 그 자체로 가치를 더하지는 않고, 잘못 만들면 제품의 가치를 떨어뜨림.
여기에 혁신을 시도하다가 불필요한 가입 절차와 불편을 만드는 제품 책임자가 많음. 반대로 남들이 하는 대로만 따라 하느라 2026년에도 이메일·비밀번호 가입을 고집하는 곳도 있음. 과도하게 설계하든 충분히 고민하지 않든, 사용자가 핵심 기능을 경험하기도 전에 떠나게 만들 수 있음.
대부분의 프로젝트는 90%가 흔하고 차별성 없는 요소를 복사하는 작업이며, LLM은 이런 일에 능함. 하지만 당연하게 여긴 결정을 조금만 재검토해도 더 나은 제품이 될 수 있고, 좋은 초기 사용 경험은 큰 차이를 만듦.
핵심은 가치를 더하는 기능이 충분히 좋은지 가장 빨리 검증하는 것임. 있으면 좋지만 성패를 바꾸지 못하는 기능에 시간을 쏟기보다 핵심 기능을 사용자 손에 전달해야 함. LLM은 주변 작업에 낭비하는 시간을 줄이면서 완성도도 높여주므로, 이를 쓰지 않거나 작업을 망치면 오히려 제품의 가치를 깎게 됨.

무엇을 만들지 말아야 할지 판단하기 어려울 때가 있음. 그다음으로 좋은 방법은 간신히 작동하는 조악한 시제품을 빠르게 만드는 것임. 일부러 조금 엉성하게 만드는 편이 도움이 되며, 깔끔한 코드와 테스트 커버리지를 둘러싼 교조적인 집착은 피해야 함.
시간제한을 빡빡하게 둘수록 전체를 망칠 설계 결정에 깊이 얽매일 가능성이 줄어듦. 90분짜리 시제품이 별로라면 잃은 시간도 적고, 이해관계자를 설득하기도 쉬움.
적절한 시점에 적절한 것을 만들어 무엇을 만들지 않아야 하는지 알아내는 방식으로, 몇 달짜리 제품 로드맵 확장 계획을 하루짜리 작업으로 줄인 적이 있음.

끊임없이 들어오는 요구가 맞춤형 보고서임. 그게 정확히 무엇이고, 왜 필요한지 거듭 묻고 나면 실제로 사용할 새 기능을 만들게 되고, 맞춤형 보고서는 또 한 달 뒤로 미루게 됨.

맞춤형 보고 도구와 파이프라인을 전문으로 만드는 동료와 일했는데, 대부분은 앱의 정렬·필터·집계 기능이 사용자의 질문에 답하지 못해서 이런 요구가 나온다고 했음.
이후로는 늘 “어떤 질문의 답을 알고 싶은가?”를 물어봄. 대개 새 기능을 만들거나 기존 기능에서 답을 찾을 위치를 알려주는 것으로 해결됨. 다만 여러 소프트웨어의 데이터를 함께 조회하려고 자체 데이터 웨어하우스에 넣으려는 경우도 있고, 정작 무슨 질문에 답하려는지 끝까지 밝히려 하지 않는 경우도 있음.

여러 곳에서 이런 요구를 너무 많이 봤는데, 정작 무엇을 보고 싶은지나 데이터가 어떤 모습이어야 하는지 모르는 경우가 대부분임. 거의 항상 원하는 것은 온갖 테이블을 억지로 이어 붙여 Excel에 전부 쏟아붓는 것임. 외래 키가 있으면 조인하고, 없으면 맞을 법한 임의의 값을 골라 유니언으로 강제로 연결하는 식이 사실상 표준처럼 통함.

“맞춤형 보고서”는 “우리 사내 개발팀이 느리다”는 뜻인 줄 알았음.

데이터 API를 줘서 직접 보고서를 만들게 하면 됨. 맞춤 보고서 제작을 시간제로 과금할 수도 있음.

내 생각에는 원시 데이터에 접근해서 Excel 같은 도구에 넣고 직접 보고서를 만들고 싶다는 뜻임.

상황에 따라 다름. 내 원칙은 사용자가 원하는 것이 아니라 필요한 것을 주는 것임. 제품 설계는 다수를 대상으로 하지만, 개별 사용자는 자기 사용 방식에 밀착돼 있으므로 의견을 무시하지 않되 전체 맥락에서 검토해야 함.
기능 제안의 70%를 내는 한 사람이 있어도 나머지 99%가 전혀 다르게 사용한다면 어떨까? 그 사람의 목적을 더 쉽고 빠르고 안정적으로 달성할 다른 방법은 없을까? A/B 테스트에서 새 기능을 무시하거나 불평한다면 어떨까?
만들지 않는다는 태도가 멋지고 반항적으로 들릴 수 있지만, 판단 기준은 어디까지나 전체 제품 전략이어야 함. 제품 설계와 개선은 무척 어렵고, 늘 고려해야 하는 하위 호환성은 엄청난 마찰을 만들어 제품을 망칠 수도 있음.
기존 관행을 깨는 더 나은 방식을 도입하려면 어떻게 해야 할까? 만들지 않을 것인가, 머리를 써서 풀어낼 것인가? 플랫폼 리더와 창업자, 제품 디자이너 모두 힘든 일을 하고 있지만, 제대로 풀렸을 때는 더없이 좋음.

멋져 보이지만 핵심 문제를 해결하지 못하는 기능을 없애서 수많은 스프린트를 아꼈음. 코드가 줄면 유지보수도 줄어듦.

PM으로서 아직 깔끔하게 풀지 못한 과제가 기능 아이디어를 영구히 접는 것임. 개발자나 CEO가 제품 방향에 맞지 않는 아이디어를 떠올리면, 안 되는 이유를 설명해도 계속 되살아남. 아이디어 회의에서 다시 꺼내고, 영업 통화에서 잠재 고객에게 제안하고, 내가 2주 휴가를 다녀오면 스프린트에 들어가 있음. 다른 제품 리더들은 “그건 앞으로도 절대 만들지 않습니다”를 어떻게 부드럽게 전달하나?

먼저 공정하게 검토한 아이디어이고 PM의 자존심 때문에 거절한 것이 아니라는 전제가 필요함. 판단을 맡는 만큼 신뢰를 얻어야 하고, 개발·영업 조직과도 가까운 관계를 유지해야 함.
PM을 거쳐 지금은 CEO로 일하는 내가 쓰는 방법은 제품 범위에 맞지 않는 이유를 적고, 삭제하지 않고 “Closed”로 닫아 두는 것임. 같은 요청이 다시 들어오면 거절 이유와 분석이 담긴 기존 티켓에 병합함.
다음으로 비용과 책임을 이야기함. PM이 제품의 시장 적합성과 비용을 책임지는데 다른 사람이 기능을 추가하려 한다면, 그 사람도 비용과 책임을 넘겨받을 의사가 있는지 물어봄. 개발자가 경영진·지원·영업 조직과의 협의를 맡을지, 영업팀이 자기 예산으로 개발비를 부담하고 지원·유지보수까지 맡을지 확인함. 제품이 안 팔리거나 비용이 불어나도 함께 책임질 수 있어야 함.
반발한다면 반대 상황도 괜찮은지 물어봄. PM이 개발 프레임워크나 데이터베이스 선택을 강제로 바꾸면서 정상 작동의 책임은 개발자에게 그대로 남기면 어떨까? 영업팀에는 이상적 고객상이나 제품 초점이 바뀌어 목표 달성이 어려워지고 판매 방식도 바꿔야 하는 상황을 예로 듦.

내 책에는 버튼 하나를 추가하려면 버튼 하나를 없앤다는 원칙으로 이 문제를 다루는 회사가 등장함. 새 UI 요소를 추가하기 전에 먼저 없앨 수 있는 요소를 찾음.
내 책 홍보 링크임: https://killthehippo.com/.