금융앱에 문서함이나 알림센터를 넣자는 요청은 작게 들린다. 파일 목록 하나, 화면 구석의 종 아이콘 하나면 될 것 같다. 금융 서비스의 소비자용 앱을 만들어 온 리엄 뉴전트(Liam Nugent)는 9월 14일 공개한 글에서 자신이 여러 차례 거절하려 했던 기능으로 이 둘을 꼽았다. 처음 화면을 만드는 비용보다, 기능이 불어난 뒤 여러 해 동안 유지할 책임을 먼저 보라는 이야기다.
뉴전트는 최초 개발비 대신 여러 해에 걸친 운영비를 보여 줬을 때 요청자들의 생각이 바뀌었다고 쓴다. PM과 창업자는 기능을 승인할 때 출시 이후의 유지보수까지 비용에 넣어 비교할 수 있다.
파일 목록이 어떻게 문서 서비스가 되는가
출발점에는 실제 업무가 있다. 기존 금융 시스템이 편지나 명세서를 PDF로 만든다. 원래 우편으로 보내던 문서를 앱에서도 전달해야 하고, 준법 담당자는 고객에게 지속적으로 남는 전달 수단을 요구한다. 문서함을 제안한 사람도 아무 이유 없이 기능을 늘리려는 것은 아니다.
문제는 목록을 만드는 순간부터 붙는 요구다. 태그로 분류하고, 보관하고, 인쇄하고, 여러 경로로 공유해야 한다. 공유 경로마다 동작이 다르고, 인증을 거친 고객에게 자기 문서만 보여 주도록 접근을 통제해야 한다. 뉴전트는 이런 과정을 구글 드라이브를 다시 만드는 일에 빗댄다. 금융앱을 개발하던 팀이 어느새 문서 서비스까지 관리하는 셈이다.
출시해도 일이 끝나지 않는다. 뉴전트는 iOS가 새 버전으로 바뀌면서 기존 기능이 기대던 동작이 사라지는 경우를 예로 든다. 운영체제나 외부 플랫폼이 바뀔 때 기존 기능을 계속 쓸 수 있게 손봐야 한다. 최초 견적에 화면 개발만 넣으면, 출시 이후에도 반복되는 일을 의사결정에서 놓친다.
알림함에 넣었다고 전달 목적을 이룬 것은 아니다
알림센터도 비슷하다. 빨간 점이 붙은 종 아이콘에서 시작한 일이 몇 달 뒤에는 조잡한 Gmail 복제판으로 커졌다는 것이 뉴전트의 표현이다. 여기서 메일 서비스를 떠안는다는 말은 메일 서버를 직접 운영했다는 뜻이 아니다. 고객에게 메시지를 보여 주려던 기능이 별도의 메시지 관리 제품처럼 커진다는 비유다.
더 곤란한 경험도 있었다. 알림센터를 실제로 만들고 나니, 정작 그 안에 담을 메시지의 원래 목적을 충족하지 못했다. 메시지를 저장하는 일과 고객이 필요한 때 읽고 행동하게 하는 일은 다르기 때문이다. 같은 알림 목록에 담긴다는 이유만으로 모든 전달 문제가 풀리지는 않는다.
이미 쓰는 메일 제품에서도 이 차이를 볼 수 있다. 구글의 Gmail 소개 화면은 받은 메일에 답장이 필요한지, 보낸 메일에 후속 연락이 필요한지를 따로 띄운다. 목록에 메일이 존재한다는 사실에 그치지 않고 다음 행동을 환기하는 기능이다. 이는 뉴전트가 만들었던 금융앱 화면이 아니라, 그가 비교 대상으로 든 메일 제품의 실제 기능 예시다.
문서함 대신 무엇을 승인해야 하는가
뉴전트가 권하는 순서는 전달할 내용을 개별 용도로 나누는 것이다. 누구에게 무엇을 말해야 하는지, 언제 필요한지부터 따진 뒤 그 일을 하려면 정말 별도 플랫폼이 필요한지 묻는다. 그의 경험에서는 완벽하지 않더라도 단순한 방법이나 이미 있는 수단을 쓰는 쪽으로 돌아오는 경우가 많았다.
이를 제품 검토에 적용하면 요청서의 단위가 달라진다. 예를 들어 '알림센터 구축'을 한 번에 승인하는 대신, 고객이 명세서를 나중에 다시 찾아야 하는지, 기한 안에 확인이나 응답을 해야 하는지, 단순히 소식을 알면 되는지를 각각 검토할 수 있다. 아래 표는 원문의 원칙을 적용해 전달 목적별 확인 조건을 나눈 예시다.
기존 채널이 요건을 충족하면 그 경로를 먼저 쓸 수 있다. 보존이나 접근 통제, 전달 시점 같은 조건을 충족하지 못하면 부족한 부분을 특정해 보완하거나 새 기능을 검토해야 한다. 문서함을 만들지 않기로 했다고 고객에게 알려야 할 의무까지 없어지지는 않는다.
개발비가 내려가도 남는 승인 책임
뉴전트는 AI 에이전트로 구현이 쉬워진 상황에서도 같은 질문을 던진다. 만들 수 있는 것이 많아졌다고 매번 더 만들기보다, 에이전트를 유지보수와 신중한 기능 제거에 쓰는 편이 낫다는 것이 그의 생각이다. 출시를 보상하고 정리와 유지보수를 낮게 평가하는 조직에서는 기능을 빼는 결정이 특히 어렵다고도 지적한다.
이 관점을 승인 회의에 가져간다면 견적서 옆에 운영 계획이 필요하다. 출시 뒤 누가 권한 문제를 처리하고, 플랫폼 변경 때 누가 고치며, 그 일을 어느 기간까지 맡을지 적는 것이다. 금액은 팀의 실제 인력과 운영 조건으로 계산해야 한다. 기존 채널로 같은 전달 목적을 충족할 수 있는지도 함께 비교하면, '화면 하나쯤'이라는 요청을 장기 운영 책임까지 포함해 판단할 수 있다.
출처: Liam Nugent, The most important product decision is what you don’t build (2026년 9월 14일)