효과적인 소프트웨어 라이프 사이클은 보통 발견(Discover), 정의(Define), 개발(Develop), 전달(Deliver)의 네 단계로 정리됩니다.

발견에서는 우리가 누구를 위한 제품을 만드는지, 그들이 해결해야 할 문제가 무엇인지 파악합니다. 정의에서는 여러 가능성 가운데 문제를 가장 잘 풀 수 있는 방향을 좁혀 제품을 설계합니다. 이어 개발에서는 구현 방안을 구체화하고 제품을 다듬으며, 전달에서는 만든 결과를 검증해 사용자에게 내보내고 피드백을 받습니다.

이 과정은 한 방향으로만 흘러가지 않습니다. 새로운 사실을 알게 되면 앞 단계로 돌아가 다시 판단하고, 출시한 뒤 얻은 피드백은 또 다른 발견의 출발점이 됩니다. 결국 제품을 만드는 일은 문제를 발견하고, 선택하고, 구현하고, 다시 배우는 과정의 반복입니다.

노련한 프로덕트 중심 엔지니어는 구현 단계에만 머물지 않습니다. 제품의 라이프 사이클 전체를 오가며, 각 단계에서 지금 무엇을 고민해야 하는지 스스로 질문합니다. 그렇다면 발견부터 전달까지, 개발자가 놓치지 말아야 할 질문은 무엇일까요? 제품을 더 잘 만드는 데 필요한 네 가지 질문을 하나씩 살펴보겠습니다.

프로덕트 중심 엔지니어가 던져야 할 질문 4가지

AI가 코드를 쓰는 시대, 개발자는 무엇을 물어야 할까

❶ 발견(Discover) | “우리는 누구의 어떤 문제를 풀고 있는가?” 

좋은 제품을 만들려면 해결책보다 먼저 사용자를 이해해야 합니다. 고객 발견 인터뷰의 첫 번째 목표 역시 사용자의 근본적인 동기와 그들이 처한 상황을 이해하는 것입니다. 문제를 제대로 알고 있다면 처음 떠올린 해결책이 빗나가더라도 다른 해답을 찾아갈 수 있습니다.

여기서 중요한 것은 사용자가 무엇을 원하는지 뿐만 아니라, 얼마나 원하는지까지 파악하는 것입니다. 사실 많은 제품이 실패하는 이유는, 사용자가 그것을 전혀 원하지 않아서가 아닙니다. 그럭저럭 원했기 때문입니다.

그래서 사용자에게 곧바로 “이런 기능이 있으면 쓰시겠어요?”라고 묻기보다, 먼저 사용자의 세계로 들어가야 합니다. 어떤 상황에서 무엇을 했고, 어디에서 불편을 겪었는지 실제 경험을 듣습니다. 제품이나 기능에 대한 이야기는 그다음에 꺼냅니다.

사용자가 우리가 예상하지 못한 문제를 이야기한다면 그 방향도 따라가 볼 필요가 있습니다. 그것은 우리가 지금 잘못된 문제를 풀고 있다는 신호일 수도 있기 때문입니다.
 

발견 단계에서 중요한 것은 빨리 해결책을 내놓는 것이 아닙니다. 누구를 위한 제품인지, 그 사람이 실제로 겪는 문제가 무엇인지, 그리고 그 문제가 해결할 만큼 중요한지를 먼저 확인하는 것입니다.
 

❷ 정의(Define) | “사용자들이 정말 중요하게 여기는 것은 무엇일까?”

자, 우리는 ‘발견’ 단계를 통해 사용자의 (진짜) 문제를 발견했습니다. 이제 여러 선택지 가운데 무엇을 만들고, 무엇을 버릴지 좁혀야 합니다. 이때 엔지니어는 자신이 잘 아는 시스템 문제나 기술적으로 개선하기 쉬운 부분에 먼저 눈이 가기 쉽습니다.

하지만 비용, 확장성, 지연 시간, 데이터 일관성, 가용성과 같은 요소는 그 자체가 사용자 목표가 아닙니다. 사용자가 자신의 목표를 이루도록 돕는 수단입니다. 그래서 모든 것을 완벽하게 개선하려 하기보다, 실제 사용자에게 어떤 영향을 주는지를 기준으로 판단해야 합니다.

예를 들어 알고리즘을 더 빠르게 만들 수 있다고 해서 반드시 지금 최적화해야 하는 것은 아닙니다. 전체 사용자 경험에서 그 차이가 거의 느껴지지 않는다면, 더 중요한 문제에 시간을 써야 할 수도 있습니다.

정의 단계에서 중요한 것은 기술적으로 무엇을 할 수 있는지가 아니라, 사용자에게 가장 큰 영향을 주는 선택이 무엇인지 판단하는 것입니다.

❸ 개발(Develop) | “사용자는 우리 제품을 어떻게 찾아낼까?”

기능을 구현했다고 해서 일이 끝나는 것은 아닙니다. 기능을 출시하는 팀에게는 그것을 사용자 눈에 띄게 하고, 이해하도록 돕고, 안전하게 사용할 수 있도록 이끄는 책임도 있습니다. 이 중 하나라도 빠지면 기능은 기대한 만큼의 임팩트를 내기 어렵습니다.

이때 엔지니어가 자주 놓치는 것은 ‘발견’입니다. 여러분이 만든 제품을 사용자가 어떻게 찾아낼 수 있을까요? 존재 자체를 모르면 제품은 없는 것이나 마찬가지입니다.

사용자는 메뉴를 둘러볼 수도 있고, 검색창을 쓸 수도 있고, 문서를 찾거나 챗봇에게 물어볼 수도 있습니다. 중요한 것은 사용자가 어떤 경로로 들어오든 필요한 기능에 자연스럽게 도달할 수 있는지 살펴보는 것입니다.

개발 단계에서 중요한 것은 기능이 코드 안에 존재하는지가 아니라, 사용자가 실제로 발견하고 이해하고 끝까지 사용할 수 있는가입니다.

❹ 전달(Deliver) | “제품을 출시한 뒤 무엇을 새롭게 배웠는가?”

제품을 출시하면 모든게 끝나는 것이 아닙니다. 실제 사용자의 반응을 통해 다시 배워야 합니다. 베타 버전, 피드백 위젯, 서베이, 사용자 지원 같은 방법은 모두 사용자가 제품을 어떻게 경험하는지 확인하기 위한 피드백 창구입니다.

특히 고객 지원은 단순히 문제를 처리하는 일이 아닙니다. 모든 고객 지원 문의는 사실 제품 피드백의 한 형태입니다.

한편으로는 지금 막힌 사용자의 문제를 해결하고, 다른 한편으로는 왜 사용자가 그 지점에서 막혔는지 살펴 제품을 개선할 단서를 얻어야 합니다. 그래서 문제를 해결한 뒤에는 한 번 더 묻습니다. “제품이 사용자에게 더 나은 서비스를 제공할 수 있었던 방법은 무엇일까요?”

전달 단계에서 중요한 것은 출시 자체가 아니라 실제 사용자의 경험을 통해 배우고, 그 배움을 다음 발견과 개선으로 다시 연결하는 것입니다.

프로덕트 중심 엔지니어에게 중요한 것은 단순히 코드를 잘 구현하는 데서 끝나지 않습니다. 누구의 문제를 풀고 있는지, 무엇이 정말 중요한지, 사용자가 우리가 만든 것을 실제로 발견하고 이해하고 사용할 수 있는지, 그리고 출시한 뒤 무엇을 새롭게 배웠는지 계속 질문해야 합니다.

위에서 이야기한 네 질문은 각각 따로 떨어져 있지 않습니다. 발견 단계에서 이해한 사용자의 문제는 무엇을 만들지 결정하는 기준이 되고, 그 결정은 개발 과정에서 실제 사용 경험으로 이어집니다. 그리고 제품을 출시한 뒤 얻은 피드백은 다시 다음 발견과 개선의 출발점이 됩니다.

그래서 제품을 만드는 일은 한 번 정답을 찾고 끝나는 과정이라기보다, 질문하고 선택하고 만들고 배우는 일을 반복하는 과정에 가깝습니다. 새로운 정보를 얻으면 앞 단계로 돌아가 판단을 바꾸기도 하고, 사용자의 반응을 통해 처음 세운 가정을 다시 살펴보기도 합니다.

제품이 출시됐다고 일이 끝난 것은 아닙니다. 구현 이후에도 사용자의 경험을 살피고, 제품이 정말 문제를 해결하고 있는지 계속 확인해야 합니다. 그렇게 발견에서 전달까지의 과정을 반복하며 더 나은 판단을 쌓아가는 것, 그것이 프로덕트 중심 엔지니어가 제품의 라이프 사이클 전체를 바라보는 방식입니다.

위 컨텐츠는 『AI 시대의 엔지니어링 전략』 내용을 기반으로 작성하였습니다.