|
한빛미디어 서평단 ＜나는리뷰어다＞ 활동을 위해서 책을 협찬받아 작성된 서평입니다. AI 시대의 엔지니어링 전략(한빛미디어, 2026) AI 코딩 어시스턴트와 에이전트 덕분에 우리는 '프로덕트 사고'에 시간을 쓸 수 있다. AI로 코딩을 외주하는 시기, 엔지니어들에게 기존의 '코드 구현'에서 나아가 '문제 정의와 판단, 결정'이 중요해지고 있다. 이 책은 제목 그대로 2026년 오늘, AI 시대의 엔지니어링 전략을 담고 있다. 저자는 프로덕트와 엔지니어링의 하이브리드로 실행과 판단을 동시에 맡을 수 있는 전천후 엔지니어가 되는 방법을 안내한다. 
 1장의 페르소나와 시나리오가 무엇인지, 어떻게 정의하는지로 시작하는 책에서 중심 키워드는 '사용자 이해'이다. 사용자 경험(사용자 여정과 기표, 진단과 에러 등)과 사용자 검증(지표, 피드백)을 주제로 프로덕트 사고를 설명하며, 이후 고객 이해와 시뮬레이션, 인터렉션 설계까지 확장된다.  저자의 다양한 경험담을 통해 실제 업무에서 '프로덕트 사고'가 어떻게 전개되는지 그리고 무엇을 체크해야하는지를 현장감 있게 알 수 있는 점이 내용상 강점이다. 챕터별 예제와 답안이 분리수록이 아닌 같은 위치 내 존재하여 문제 속 정답 확인과 본문 확인이 편한 부분은 편집상 강점 요인이다. 소프트웨어 엔지니어로 '코드' 이후를 고민하거나 사용자 요구를 적절히 선택하는 방법 그리고 프로덕트 감각을 발전시키고 싶은 모든 개발자들께 일독을 추천한다.  AI 시대의 엔지니어링 전략 - 한빛+ 코드를 넘어 제품의 성공까지 설계하는 개발자의 사고법 www.hanbit.co.kr 저자 : 드류 호스킨스(Hoskins, Drew) 역자: 김승권 제목 : AI 시대의 엔지니어링 전략 원서: The Product-Minded Engineer(O'Reilly Media, 2025.12 ) 출판사 : 한빛미디어 출간 연도 : 2026.07.31 페이지 : 300쪽 한빛미디어 서평단 ＜나는리뷰어다＞ 활동을 위해서 책을 협찬받아 작성된 서평입니다. |
|
개발은 개발자의 능력을 입증하는 것보단, 사용자가 필요한 것을 이해하고 이를 현실화하는 데에 있다. 예전에 어느 책에서 읽었던 멘트이다. (아마도 정확하지 않을 수 있다.) 하지만 대다수의 초급/뉴비 개발자들은 사용자의 고민에 대한 정확한 이해보다는 신기술이니까, 이 기술이 들어가면 왠지 좋을 것 같으니까 기술을 도입하는 경향이 상당히 강하다. 왜냐하면 막연히 사용자가 이 기능을 사용하면 좋을 것 같다는 생각이 그들을 이끌고 있기 때문이다. 필자는 그래서 궁금했다. 왜 신규/뉴비 개발자들에게 그러한 막연한 기대와 그러한 가정이 생겨나게 되는 것일까? 그것은 아무래도 본인들이 하고 있는 일 자체, 즉 무엇인가 만드는 것에서 오는 즐거움이 사용자의 필요/수요라는 껍질이 더해짐으로써 막연한 예상과 가정이라는 방향으로 피어난 것이리라 지례 짐작해 본다. 이 책은 이런 개발자들이 쉽게 저지를 수 있는 오류에 대해서 직관적이며 쉽게 이해할 수 있는 예시와 이야기를 중심으로 독자들을 설득하고 있다. 한번 책의 구성에 대해서 살펴보도록 하겠다. 【책 내용 요약】 이 책은 기본적으로 네 가지 스텝을 가르쳐 준다. 개발 -＞ 전달 -＞ 발견 -＞ 정의 가 그러하다. 개발은 구현 방안을 고르고 구체화하는 방향에 대해서 설명한다. 즉 상위 수준으로 정의된 제품을 만들고 다 듦은 저자만의 최적의 방법을 탐구한다. 전달은 만든 결과를 검증하는 단계이다. 고객에게 어떻게 피드백을 받고 이를 내보내는지에 대해서 고민하는 장이다. 발견은 우리가 누구를 위해서 이 일을 하는지, 그들을 위해 우리가 풀어줘야 할 문제가 무엇인지 가려내는 방법에 대해서 저자의 생각을 듣고 함께 사유하게 된다. 즉, 일반적인 개발자라면 가장 취약한 부분이 여기이지 않을까 싶다. 정의는 문제를 풀 제품을 설계한다. 여러 선택지를 좁혀 최종적인 완성된 제품이 어떤 모습인지에 대해서 예상 및 청사진을 그린다. 각 장은 그 내용에 걸맞은 콘텐츠로 구성되어 있다. 가령 개발의 경우에는 다양한 코드와 상황을 예시로 사용자의 이해를 돕고, 정의에서는 각각의 상황에 따른 적절한 예시 등을 들어가며 독자의 이해를 돕고 저자의 생각을 전달하고 있다. 무엇보다 이 책의 구성이 좋았던 이유는 저자가 왜 그렇게 생각하고 그렇게 하면 무엇이 좋은지에 대해서 바로바로 설명하고 저자를 설득하기 위해 노력한다는 부분이다. 【 AI 시대의 엔지니어링 전략을 읽고 나서 】 시대가 변화하더라도 본질을 잊어선 안된다. 개발자는 단순히 무엇인가 만드는 사람이 아니다. 개발을 하는 가장 본질적인 이유는 무엇인가 문제를 풀기 위함이다. 게임을 개발하는 이유는 무료한 일상 혹은 고된 일상을 살아가는 이들에게 잠시나마 환상의 세계를 보여줌으로써 그들이 해소하지 못했던 욕구를 풀 수 있는 놀이의 장/예술의 장을 제공함에 있고, 생활에서 사용하는 수많은 앱들은 일상생활을 살아오는 사용자들의 불편을 조금이나마 덜어주기 위함에서 시작된다. 이처럼 시대를 초월하여 본인이 맡은 일의 본질을 이해하고 이를 현실화하기 위해 노력한다면, AI가 아무리 대단할지라도 엔지니어로써 삶을 영위하는 데에 부족함이 없을 것이다. 본 도서는 "한빛미디어 ＜나는 리뷰어다＞ 활동을 위해서 책을 제공받아 작성된 서평입니다. |
|
"한빛미디어 서평단 ＜나는 리뷰어다＞ 활동을 위해서 책을 협찬받아 작성된 서평입니다."  AI가 코드를 작성하는 시대, 개발자는 무엇을 잘해야 할까?개발자로 일하면서 요즘 가장 많이 생각하는 주제 중 하나가 AI가 발전할수록 개발자는 무엇을 잘해야 하는가입니다. 몇 년 전까지만 해도 새로운 프레임워크를 공부하고, 더 좋은 코드를 작성하고, 복잡한 문제를 구현할 수 있는 능력을 키우는 것이 개발자로 성장하는 비교적 명확한 방법이라고 생각했습니다. 물론 지금도 이런 능력은 중요합니다. 하지만 AI를 실제 개발 과정에서 사용하기 시작하면서 조금씩 생각이 달라졌습니다.
예전에는 한두 시간이 걸렸을 코드를 AI가 몇 분 만에 만들어주기도 하고, 익숙하지 않은 기술의 코드도 꽤 그럴듯하게 작성합니다. 아직 결과물을 그대로 신뢰하기는 어렵지만, 적어도 ‘코드를 작성하는 것’ 자체의 비용은 빠르게 낮아지고 있다는 생각이 들었습니다.
그래서 자연스럽게 이런 질문이 생겼습니다. 그렇다면 앞으로 개발자의 가치는 어디에서 만들어질까?
＜AI 시대의 엔지니어링 전략＞은 이 질문에 대해 꽤 흥미로운 방향을 제시합니다. 좋은 엔지니어는 주어진 요구 사항을 정확하게 구현하는 사람에서 그치는 것이 아니라, 무엇을 왜 만들어야 하는지 고민하고 제품의 성공에 영향을 줄 수 있는 사람이어야 한다는 것입니다. 지금 시대의 Product Engineer를 얘기하는 것으로 봐도 될 것 같습니다. 요구 사항을 잘 구현하는 것만으로 충분할까?개발자로 일하다 보면 이미 정해진 요구 사항을 전달받는 경우가 많습니다. 기획서가 나오고 디자인이 완성되면 이를 바탕으로 API를 연결하고 화면을 구현합니다. 이 과정에서도 좋은 구조를 고민하고, 성능을 개선하고, 장애 가능성을 줄이는 등 수많은 기술적인 판단이 필요합니다.
저 역시 이런 부분을 잘하는 것이 좋은 개발자가 되는 중요한 조건이라고 생각해 왔습니다. 그런데 경력이 조금씩 쌓이면서 구현보다 더 어려운 문제가 있다는 것을 느끼기 시작했습니다. “그런데 이 기능은 왜 필요한가?”
기술적으로 완성도가 높은 기능을 만들어도 사용자가 잘 사용하지 않을 수 있습니다. 반대로 구현 자체는 단순하지만 사용자의 불편을 정확하게 해결하면서 제품에 큰 영향을 주는 기능도 있습니다. 책에서 이야기하는 ‘프로덕트 중심 엔지니어’는 바로 이 지점에서 출발합니다.
요구 사항을 받자마자 어떻게 구현할지를 고민하기보다 사용자가 어떤 상황에서 이 기능을 사용하는지, 지금 겪고 있는 문제는 무엇인지, 우리가 만들려는 기능이 정말 그 문제를 해결하는지를 먼저 생각합니다. 읽으면서 제가 평소 개발 과정에서 'How'에는 많은 시간을 사용하면서 'Why'에는 상대적으로 적은 시간을 사용하고 있지 않았나 돌아보게 됐습니다. 코드 밖에도 개발자가 해결해야 할 문제가 많다특히 좋았던 점은 프로덕트 사고를 추상적인 태도나 마인드셋 정도로 설명하지 않는다는 점이었습니다. 사용자 시나리오를 작성하고, 실제 제품을 직접 사용해보고, 사용 과정에서 발생하는 마찰을 기록하고, 사용자 피드백과 제품 지표를 확인하는 등 개발자가 제품을 이해하기 위해 실제로 해볼 수 있는 행동들을 이야기합니다.
그중에서도 제품을 직접 사용해보는 ‘도그푸딩’과 마찰을 기록하는 방식이 인상적이었습니다. 개발하다 보면 내가 만든 기능을 개발 환경에서는 수도 없이 확인하면서도 정작 실제 사용자의 흐름대로 처음부터 끝까지 사용해보는 경험은 의외로 부족할 수 있습니다.
버튼 하나를 클릭하는 데 한 단계가 더 필요한 것, 에러가 발생했는데 사용자가 무엇을 해야 하는지 알 수 없는 것, 개발자는 너무 익숙해서 당연하다고 생각하지만 처음 사용하는 사람에게는 이해하기 어려운 인터페이스 같은 문제는 코드만 보고서는 발견하기 어렵습니다.
결국 좋은 제품을 만드는 능력에는 코드를 작성하는 능력뿐만 아니라 내가 만든 소프트웨어를 사용자의 입장에서 관찰하는 능력도 포함된다는 생각이 들었습니다. 에러 메시지도 제품의 일부다 개발자로서 특히 흥미롭게 읽었던 부분은 에러와 경고를 다루는 내용이었습니다. 개발할 때 에러 처리는 흔히 예외 상황에 대한 방어 코드 정도로 생각하기 쉽습니다. API 요청이 실패하면 에러를 잡고, 적절한 메시지를 보여주고, 로깅 시스템에 기록하는 식입니다. 하지만 사용자의 입장에서 생각하면 에러는 단순한 기술적 실패가 아닙니다.
사용자는 에러를 만났을 때 "무슨 일이 발생했는가?", "내가 잘못한 것인가?", "이제 무엇을 해야 하는가?"를 알고 싶어 합니다. 결국 좋은 에러 처리는 에러를 잡는 것에서 끝나는 것이 아니라 사용자가 문제에서 빠져나올 수 있도록 돕는 데까지 이어져야 합니다.
이런 관점은 프런트엔드 개발자로서 특히 공감되는 부분이었습니다. 화면은 사용자가 시스템과 직접 만나는 곳이기 때문에 백엔드에서 전달된 에러를 단순히 문구로 변환하는 것보다, 사용자가 다음 행동을 선택할 수 있도록 만드는 것이 훨씬 중요하기 때문입니다. 프로덕트 아키텍처라는 관점 후반부에서 다루는 ‘프로덕트 아키텍처’라는 개념도 기억에 남았습니다. 개발자에게 아키텍처라고 하면 보통 모듈의 의존성이나 레이어 분리, 확장성, 성능, 장애 대응 같은 기술적인 문제를 먼저 떠올리게 됩니다. 저 역시 좋은 아키텍처를 생각할 때 변경에 얼마나 유연한지, 테스트하기 쉬운지, 복잡도를 얼마나 잘 통제하고 있는지를 주로 생각했습니다.
하지만 책을 읽으면서 한 가지 기준을 더 추가할 수 있겠다는 생각이 들었습니다. “이 구조가 결국 어떤 사용자 경험을 만들어내는가?”
기술적인 선택과 제품 경험은 생각보다 멀리 떨어져 있지 않습니다. 성능이 느리면 사용자는 기다려야 하고, 시스템의 안정성이 떨어지면 결제나 주문 같은 중요한 순간에 제품을 신뢰하기 어렵습니다. 지나치게 경직된 구조는 새로운 요구 사항에 대응하는 속도를 떨어뜨리고 결국 제품의 실험 속도에도 영향을 줍니다.
좋은 기술적 의사결정은 단순히 코드가 아름다운가를 넘어 제품이 앞으로 어떤 선택을 할 수 있게 만들어주는가까지 고려해야 한다는 점을 다시 생각하게 됐습니다. AI 시대에 오히려 중요해지는 개발자의 역할이 책을 읽고 나서 처음의 질문으로 다시 돌아왔습니다. AI가 코드를 점점 더 잘 작성하게 된다면 개발자는 무엇을 잘해야 할까? 적어도 저는 'AI보다 코드를 더 잘 작성하는 사람'이 되는 것만으로는 충분하지 않을 것 같습니다.
대신 어떤 문제가 중요한지 판단하고, 사용자가 실제로 겪고 있는 문제를 발견하고, 여러 해결책 사이의 트레이드오프를 판단하고, 기술적인 선택을 제품의 결과까지 연결할 수 있는 능력이 점점 중요해질 것 같습니다. 그리고 이런 능력은 AI에게 코드를 많이 작성하게 한다고 자연스럽게 생기지는 않습니다. 오히려 구현 비용이 낮아질수록 무엇을 만들 것인지 결정하는 비용은 상대적으로 더 중요해질 수 있습니다. 잘못된 요구 사항도 빠르게 구현할 수 있고, 필요 없는 기능도 빠르게 만들 수 있기 때문입니다.
그래서 이 책의 제목에는 ‘AI 시대’라는 표현이 붙어 있지만, 개인적으로는 AI 활용법을 알려주는 책이라기보다 개발자의 역할을 코드 바깥으로 확장하는 방법을 이야기하는 책에 더 가깝게 느껴졌습니다. 어떤 개발자에게 추천하고 싶은가이 책은 새로운 기술이나 코딩 방법을 배우고 싶은 사람보다는 어느 정도 실무를 경험한 뒤 다음 단계의 성장을 고민하고 있는 개발자에게 더 잘 맞는 책이라고 생각합니다. 특히 주어진 요구 사항을 구현하는 데에는 어느 정도 익숙해졌지만 앞으로 어떤 역량을 키워야 할지 고민하는 개발자라면 읽어볼 만합니다.
PM이나 디자이너가 정해준 요구 사항을 구현하는 역할에서 조금 더 나아가 제품의 문제를 함께 정의하고, 기술적인 관점에서 해결책을 제안하고 싶은 개발자에게도 잘 맞습니다. 저 역시 좋은 코드를 작성하고 기술적인 깊이를 쌓는 것을 개발자로서 중요한 성장 방향이라고 생각합니다. 다만 한 가지가 추가됐습니다. 좋은 개발자는 코드를 잘 작성하는 사람인 동시에, 자신이 작성한 코드가 결국 누구의 어떤 문제를 해결하는지 알고 있는 사람이어야 한다는 것입니다.
AI가 코드를 점점 더 많이 작성하게 되는 시대라면, 어쩌면 이 차이가 앞으로 개발자의 경쟁력을 결정하게 될지도 모르겠습니다. |
|
『AI 시대의 엔지니어링 전략』이라는 제목만 보면 AI 코딩 도구나 에이전트 활용법을 다루는 책처럼 보인다. 하지만 실제로는 AI가 구현 속도를 높이는 시대에 엔지니어가 무엇을 판단하고 책임져야 하는지를 묻는 책이다. 코드를 얼마나 빠르게 작성하느냐보다 무엇을 왜 만들어야 하는지, 그리고 그 결과가 사용자에게 어떤 변화로 이어지는지를 생각하는 ‘프로덕트 중심 엔지니어’의 사고법을 설명한다. 가장 인상 깊었던 부분은 문서 주도 개발이었다. 문서는 개발이 끝난 뒤 작성하는 설명서라고 생각하기 쉬운데, 이 책은 코드를 작성하기 전에 제품을 검증하는 저렴한 프로토타입으로 활용한다. 기능을 문서로 설명하기 어렵거나 사용 절차가 지나치게 복잡하다면 문서를 늘리기보다 제품 자체를 수정하는 편이 나을 수 있다는 관점이 특히 와닿았다. 문서를 잘 쓰는 능력은 단순한 기록 역량이 아니라 제품의 복잡성과 불필요한 단계를 발견하는 설계 역량이 될 수 있다는 점을 새롭게 이해했다. 사용자의 동기와 페르소나를 바탕으로 시나리오를 만들고, 이를 요구 사항과 PRD, 사용자 흐름, 테스트로 발전시키는 과정도 실무를 돌아보게 했다. 과거 솔루션을 개발하면서 자료 조사와 브레인스토밍을 통해 기능을 정한 뒤 곧바로 구현했던 경험이 떠올랐다. 정작 사용자가 어떤 상황에서 기능을 발견하고, 어떤 순서로 사용하며, 어디에서 막힐지를 충분히 시뮬레이션하지 않았다는 생각에 다소 부끄럽기도 했다. 기능 아이디어가 많다는 것과 좋은 제품을 설계했다는 것은 전혀 다른 문제였다. 프로덕트 아키텍처 부분에서는 지연시간, 가용성, 데이터 일관성을 단순한 시스템 지표가 아니라 사용자가 경험하는 제품의 약속으로 설명한다. 내가 수정한 내용이 언제 다시 보이는지, 다른 사용자의 변경이 언제 반영되는지와 같은 질문으로 일관성을 풀어내는 방식이 흥미로웠다. 이를 통해 진정한 PO는 기능의 우선순위만 관리하는 사람이 아니라, 사용자 가치와 기술적 제약을 함께 이해하고 트레이드오프에 책임지는 역할이어야 한다는 점도 다시 생각하게 됐다. 다만 해외의 애자일 조직문화를 기반으로 한 사례가 많아 국내 SI나 공공 프로젝트 환경에서는 다소 추상적으로 느껴지는 부분도 있었다. 역할과 계약 범위가 명확히 나뉜 국내 개발 환경에서는 엔지니어가 사용자 인터뷰나 제품 의사결정에 직접 참여하기 어려운 경우도 많기 때문이다. 그럼에도 요구 사항을 수동적으로 구현하는 역할에서 벗어나고 싶은 개발자, 테크리드, 플랫폼 엔지니어, 아키텍트와 PO에게는 충분히 읽을 가치가 있다. 구체적인 AI 도구 사용법이나 구현 레시피보다, AI 시대의 엔지니어가 어떤 질문을 던져야 하는지 알려주는 책이다. AI가 코드를 더 빠르게 만들어줄수록 사용자의 문제를 정의하고 기술적 선택을 제품의 성과로 연결하는 능력은 오히려 더 중요해질 것이라는 생각이 남았다. |
예전에는 라이브러리를 찾고 에러 원인을 추적하는 데 많은 시간을 썼다면, 지금은 AI에게 로그와 코드를 보여주고 해결 방법을 함께 찾아가면서 구현 속도가 확실히 빨라졌다. 실제로 최근 면접에서도 프론트엔드 개발 자체보다 AI를 활용한 빠른 프로토타이핑과 기획 역량을 중요하게 보는 곳을 경험하면서 개발자의 역할이 달라지고 있다는 것을 체감했다. 그런데 정작 개발이 빨라진 뒤에도 고민은 줄지 않았다. AI에게 “어떻게 만들지?”는 물어볼 수 있지만, “이걸 정말 만들어야 하나?”, “누가 사용할까?”, “지금 필요한 기능인가?”에 대한 답은 직접 찾아야 했다. 새로운 서비스를 기획하면서 구현할 수 있는 기능을 계속 추가하다가 오히려 서비스의 중심이 흐려지는 경험도 했다. 『AI 시대의 엔지니어링 전략』은 바로 이런 고민을 다른 관점에서 바라보게 만든 책이다. AI 활용법이나 개발 도구를 설명하는 데 그치지 않고, 시나리오, 사용자 안내, 에러, 사용자 이해와 피드백, 요구사항과 우선순위, 인터랙션, 아키텍처까지 제품을 만들기 위해 엔지니어가 판단해야 하는 과정을 짚어간다. AI가 개발자의 일을 없애는 것이 아니라 구현을 쉽게 만든 만큼 무엇을 만들지 결정하는 일이 더 중요해지고 있다고 느끼는 개발자라면, 자신의 개발 방식을 돌아보게 만드는 책이다. #나는 리뷰어다 |
 O'REILLY AI 시대의 엔지니어링전략 The Product-Minded Engineer [코드를 넘어 제품의 성공까지 설계하는 개발자의 사고법] 드류 호스킨스 지음 조쉬(김승권) 옮김 이 책이 나온 이유....
대상 독자 ...
코드를 잘 만드는 개발자에서, 좋은 제품을 만드는 엔지니어로개발자로 일하다 보면 자연스럽게 "어떻게 구현할 것인가"에 집중하게 됩니다. 어떤 언어나 프레임워크를 사용할지, 성능은 어떻게 개선할지, 장애 가능성은 어떻게 줄일지, 구조는 어떻게 설계할지와 같은 문제는 개발자의 일상적인 고민입니다. 하지만 실제 제품이나 서비스를 개발하다 보면 기술적으로 잘 만들어진 소프트웨어가 반드시 좋은 제품이 되는 것은 아니라는 사실을 자주 경험하게 됩니다. 기능은 정상적으로 동작하지만 사용자가 별로 사용하지 않을 수도 있고, 기술적으로 훌륭한 시스템을 만들었지만 실제 사용자가 원하는 문제를 해결하지 못할 수도 있습니다. 반대로 기술적으로 아주 복잡하지 않더라도 사용자의 문제를 정확하게 해결하는 제품은 높은 가치를 만들어 내기도 합니다. 이 책은 바로 이러한 차이에 대해 이야기하는 책입니다. 이 책은 개발자에게 단순히 “코드를 잘 작성하는 방법”을 설명하는 것이 아니라, “우리는 왜 이 기능을 만드는가?” 와 같은 질문을 함께 고민하도록 합니다. 책을 읽으면서 가장 크게 느낀 점은 Product-Minded Engineer란 단순히 제품 기획을 잘하는 개발자가 아니라, 기술적 판단을 실제 사용자 가치와 연결할 수 있는 엔지니어를 의미한다는 점이었습니다. 이 책의 목적은 무엇인가이 책의 목적은 개발자를 Product Manager로 만드는 것이 아닙니다. 개발자는 여전히 기술에 대한 전문성을 가지고 시스템을 설계하고 구현해야 합니다. 하지만 그 과정에서 주어진 요구사항을 그대로 구현하는 데 그치지 않고, 해당 요구사항이 왜 필요한지까지 이해해야 한다는 것이 이 책의 핵심 메시지입니다. 일반적인 개발 과정에서는 다음과 같은 질문이 익숙합니다. “이 기능을 어떻게 구현할 것인가?” 하지만 Product-Minded Engineer는 여기서 한 단계 더 나아갑니다. “왜 이 기능이 필요한가?” “누가 사용하는 기능인가?” “사용자는 어떤 상황에서 이 기능을 사용하는가?” “사용자가 실제로 해결하려는 문제는 무엇인가?” “개발 비용과 효과를 고려했을 때 지금 이 기능을 만드는 것이 맞는가?” 즉, How만 고민하는 것이 아니라 Why와 What까지 함께 고민하는 개발자가 되는 것이 이 책에서 이야기하는 Product-Minded Engineer라고 볼 수 있습니다. 이러한 관점은 단순히 모바일 앱이나 웹서비스와 같은 일반 사용자 대상 제품에만 적용되는 것이 아닙니다. API, 개발자 도구, 플랫폼, 사내 운영 시스템, 인프라 시스템처럼 일반 사용자에게 직접 노출되지 않는 소프트웨어 역시 결국 누군가가 사용하는 제품입니다. 따라서 Backend Engineer, Platform Engineer, Infrastructure Engineer, DevOps Engineer와 같이 일반적으로 제품 기획과 거리가 있다고 생각하기 쉬운 개발자에게도 충분히 적용할 수 있는 내용이 많습니다. 책은 어떻게 구성되어 있는가이 책은 제품을 발견하고, 정의하고, 개발하고, 출시하고, 다시 사용자 반응을 확인하는 전체 과정을 엔지니어의 시각에서 설명합니다. 책을 읽다 보면 각각의 장이 따로 떨어져 있다기보다는 하나의 제품 개발 흐름으로 연결되어 있다는 느낌을 받을 수 있습니다. 특히 Persona와 Scenario라는 개념이 책 전반에서 반복적으로 등장합니다. 단순히 “검색 기능을 개발한다.” 라고 생각하는 것이 아니라, “어떤 사용자가, 어떤 상황에서, 어떤 목적을 가지고 검색 기능을 사용하는가?” 라는 형태로 기능을 바라보도록 합니다. 이러한 사고방식이 이후 사용자 경험, 오류 처리, 요구사항 정의, 테스트, 제품 지표, 아키텍처 설계까지 계속 이어집니다. 1. Persona와 Scenario를 통한 사용자 이해 책의 초반부에서는 제품을 만드는 과정에서 가장 먼저 고려해야 할 사용자와 사용 상황을 설명합니다. 개발자는 요구사항 문서를 보면 자연스럽게 기능 목록에 집중하게 됩니다. 하지만 이 책에서는 기능 자체보다 먼저 누가 어떤 목적으로 해당 기능을 사용하는지를 이해해야 한다고 설명합니다. 예를 들어 동일한 기능이라도 초보자가 사용하는 경우와 전문가가 사용하는 경우에는 필요한 UX와 기능의 깊이가 달라질 수 있습니다. 따라서 기능을 설계할 때 Persona와 Scenario를 명확하게 정의하는 것이 중요합니다. 개인적으로 이 부분은 책 전체에서 가장 기본적이면서도 중요한 개념이라고 생각합니다. 2. User Journey와 제품 사용 경험 다음으로는 사용자가 제품을 처음 발견한 순간부터 실제 기능을 사용하는 과정까지의 전체 User Journey를 다룹니다. 제품 이름은 이해하기 쉬운지, 사용자가 원하는 기능을 쉽게 찾을 수 있는지, 처음부터 너무 많은 기능을 보여 주고 있지는 않은지, 초보자와 숙련자가 모두 사용할 수 있는 구조인지 등을 생각하게 합니다. 개발자는 기능이 정상적으로 동작하면 구현이 완료되었다고 생각하기 쉽습니다. 하지만 사용자 입장에서는 기능을 찾고, 이해하고, 실제로 사용하는 전체 과정이 하나의 제품 경험입니다. 이 책은 이러한 관점의 차이를 잘 보여 줍니다. 3. Error와 Warning도 제품의 일부 개발자 입장에서 특히 흥미롭게 읽었던 부분 중 하나는 Error와 Warning에 대한 내용입니다. 일반적으로 오류 처리는 예외를 검출하고 적절한 오류 코드를 반환하는 기술적 문제로 생각하기 쉽습니다. 하지만 사용자의 입장에서는 오류 메시지 역시 제품 인터페이스의 일부입니다. 예를 들어, ＜＜ Invalid Parameter ＞＞ 라는 메시지만 표시하면 개발자에게는 충분할 수 있지만 사용자는 무엇이 잘못되었고 어떻게 해결해야 하는지 알기 어렵습니다. 좋은 오류 메시지는 단순히 문제가 발생했다는 사실을 알려 주는 것이 아니라, 무엇이 잘못되었는지, 왜 문제가 발생했는지, 다음에 무엇을 해야 하는지 까지 알려 줄 수 있어야 합니다. 이 부분을 읽으면서 오류 처리 역시 단순한 예외처리가 아니라 UX의 일부라는 점이 인상적이었습니다. 제품을 직접 사용해 보는 것이 왜 중요한가 책에서는 자신이 만든 제품을 직접 사용해 보는 Dogfooding의 중요성도 강조합니다. 개발자가 자신이 만든 기능을 실제 사용자처럼 사용해 보면 개발 단계에서는 발견하지 못했던 많은 문제를 찾을 수 있습니다. 특히 Friction Logging이라는 방법이 인상적이었습니다. 제품을 사용하면서 “여기에서 잠시 망설였다.” “이 메뉴가 어디에 있는지 바로 찾지 못했다.” “이 기능을 사용하려면 설명서를 확인해야 했다.” “오류가 발생했는데 어떻게 복구해야 할지 알기 어려웠다.” 와 같은 작은 불편을 기록하는 방식입니다. 기술적으로는 매우 단순한 방법이지만 실제 프로젝트에서 바로 적용해 볼 수 있다는 점에서 실용적이라고 생각합니다. 대규모 UX 분석 도구나 복잡한 테스트 환경이 없어도 개발자가 제품을 실제로 사용하면서 충분히 개선점을 찾을 수 있기 때문입니다. 출시가 개발의 끝은 아니다 제품이나 기능을 출시하면 개발이 끝났다고 생각하기 쉽습니다. 하지만 책에서는 제품을 출시한 이후부터가 오히려 중요한 학습 과정이라고 설명합니다. 사용자가 실제로 기능을 사용하는지, 예상한 방식으로 사용하는지, 어느 부분에서 불편을 느끼는지, 해당 기능이 실제 가치를 만들어 내고 있는지를 확인해야 합니다. 이를 위해 Feedback, Survey, Beta Version, Adoption Metric, Value Metric, KPI와 같은 방법을 활용할 수 있습니다. 이 부분을 통해 제품 개발은 다음과 같은 반복 과정이라는 점을 알 수 있습니다. 가설 → 개발 → 출시 → 측정 → 학습 → 개선 단순히 기능을 많이 추가하는 것이 아니라, 사용자의 반응을 확인하면서 제품을 지속적으로 개선하는 것이 중요합니다. 누구를 위한 제품인지 먼저 결정해야 한다 책의 중반 이후부터는 보다 본격적으로 Product Thinking을 다룹니다. 특히 모든 사용자를 만족시키려고 해서는 안 된다는 점을 강조합니다. 제품을 만들 때 흔히 발생하는 문제 중 하나는 다양한 사용자의 요구사항을 계속 추가하다가 제품이 지나치게 복잡해지는 것입니다. 따라서 “우리 제품이 가장 중요하게 해결해야 할 사용자는 누구인가?” 를 먼저 결정해야 합니다. 이를 위해 Customer Interview, Survey, Persona 등의 방법을 활용할 수 있습니다. 이러한 과정은 제품의 Target Audience를 정의하고, 이후 어떤 기능을 만들고 어떤 기능을 포기할 것인지 결정하는 기준이 됩니다. Scenario에서 Requirement로 책에서는 사용자 Scenario를 실제 Requirement로 변환하는 과정도 설명합니다. Product Thesis, Target Audience, Product Goal, North Star Scenario 등을 정의한 뒤 이를 구체적인 Requirement, User Flow, Jobs to Be Done 등으로 연결합니다. 개발자의 입장에서는 이 과정이 특히 중요하다고 생각합니다. 아이디어가 떠오르면 개발자는 자연스럽게 구현 방법부터 고민하기 쉽습니다. 하지만 이 책의 방식대로 접근하면 개발 전에 다음 순서로 한 번 더 생각하게 됩니다. Target User 이 과정만 거쳐도 불필요한 기능 개발을 상당히 줄일 수 있습니다. 모든 기능을 만들 수는 없다 제품 개발에서는 항상 시간과 인력이 제한되어 있습니다. 따라서 좋은 아이디어라고 해서 모두 구현할 수는 없습니다. 책에서는 기능의 가치와 구현 비용을 함께 고려하여 우선순위를 결정하는 방법을 설명합니다. 이 부분은 실제 개발 현장에서 매우 현실적인 문제입니다. 개발자는 기술적으로 흥미로운 기능을 구현하고 싶을 수 있고, Product Manager는 사업적으로 중요한 기능을 우선하고 싶을 수 있으며, 고객은 자신의 요구사항을 가장 먼저 개발해 달라고 요청할 수 있습니다. 결국 중요한 것은 “현재 가장 큰 사용자 가치를 만들 수 있는 작업이 무엇인가?” 를 판단하는 것입니다. Product-Minded Engineer에게 필요한 능력 중 하나가 바로 이러한 우선순위 판단이라고 생각합니다. UX와 Architecture도 사용자 가치에서 시작한다 책 후반부에서는 Interaction Design과 Product Architecture를 다룹니다. Default 값을 어떻게 정할지, 사용자가 잘못된 선택을 하지 않도록 어떻게 설계할지, 복잡한 기능을 언제 보여 줄지, 처음부터 범용적인 구조를 만들 것인지 아니면 현재 문제에 집중할 것인지 등을 다룹니다. Architecture 부분에서는 Latency, Availability, Data Consistency, Scalability와 같은 엔지니어에게 익숙한 주제들도 등장합니다. 하지만 접근 방식이 조금 다릅니다. 단순히 “Latency는 낮을수록 좋다.” 라고 판단하는 것이 아니라, “이 Latency가 실제 사용자 경험에 어떤 영향을 미치는가?” 를 먼저 생각하게 합니다. Availability나 Scalability 역시 단순한 기술적 목표가 아니라 제품이 제공해야 하는 사용자 경험과 연결해서 판단해야 합니다. 개인적으로 이 부분이 Product-Minded Engineer라는 책의 제목을 가장 잘 보여 주는 부분이라고 생각합니다. 기술적인 의사결정과 제품적인 의사결정이 서로 분리된 것이 아니라는 점을 잘 설명하고 있기 때문입니다. 실제 업무에서 얼마나 실용적인가 이 책의 장점 중 하나는 Product Thinking을 추상적인 철학으로만 설명하지 않는다는 점입니다. 책에서 다루는 내용을 살펴보면 실제 업무에 적용할 수 있는 방법이 상당히 많습니다. Persona 정의, Scenario 작성, Customer Interview, Friction Logging, Dogfooding, Error Message 개선, Documentation-Driven Development, North Star Scenario, Product Requirement, User Flow, Jobs to Be Done, Product Metric, 기능 우선순위 결정 등입니다. 개인적으로는 이 책을 한 번 읽고 끝내는 것보다 현재 진행하고 있는 프로젝트에 하나씩 적용해 보는 방식으로 읽는 것이 더 효과적이라고 생각합니다. 예를 들어 새로운 기능 개발을 시작하기 전에 다음과 같이 정리해 볼 수 있습니다. Persona → Motivation → Scenario → User Value → Requirement → Priority → Validation 기존에는 요구사항을 받으면 바로 구현 방법부터 고민했다면, 이 과정을 거치면서 “이 요구사항이 정말 필요한가?” “더 단순한 방법은 없는가?” “누구에게 가장 중요한 기능인가?” 를 한 번 더 생각하게 됩니다. 이러한 사고 과정 자체가 이 책에서 얻을 수 있는 중요한 실무적 가치라고 생각합니다. 학습하기 쉽게 구성되어 있는가 전체적으로는 비교적 학습하기 좋은 구성입니다. 단순히 개념을 나열하는 방식이 아니라 사례를 통해 문제를 제시하고, 관련 개념을 설명한 뒤 실제 적용 방법으로 이어집니다. 또한 각 장에서 설명한 개념들이 이후 장에서도 반복적으로 등장합니다. 특히 Persona와 Scenario를 중심으로 User Journey, Requirement, Testing, Product Metric, Architecture가 연결되기 때문에 책을 읽을수록 각각의 개념이 하나의 체계로 정리되는 느낌을 받을 수 있습니다. 책의 각 장에는 요약과 연습 문제도 포함되어 있기 때문에 단순한 교양서보다는 학습서에 가까운 구성이라고 볼 수 있습니다. 다만 개발을 처음 시작한 초급자보다 실제 프로젝트를 어느 정도 경험한 개발자가 읽었을 때 훨씬 많은 내용을 얻을 수 있는 책이라고 생각합니다. 실제로 프로젝트를 진행하면서 다음과 같은 경험이 있었다면 책의 내용이 더욱 현실적으로 다가올 것입니다. “요구사항대로 구현했는데 사용자가 잘 사용하지 않는다.” “기능이 계속 추가되면서 제품이 복잡해졌다.” “개발팀과 기획팀이 중요하게 생각하는 부분이 다르다.” “기술적으로 좋은 구조를 만들었는데 실제 사용자 가치가 명확하지 않다.” “개발해야 할 기능은 많은데 무엇부터 해야 할지 판단하기 어렵다.” 이러한 문제를 경험한 개발자라면 책에서 설명하는 내용들을 실제 업무 상황과 쉽게 연결할 수 있을 것입니다. 이 책을 읽으면 무엇을 얻을 수 있는가 이 책에서 얻을 수 있는 가장 중요한 것은 특정 프로그래밍 기술이나 새로운 프레임워크가 아닙니다. 저는 오히려 제품을 바라보고 판단하는 기준을 얻는 책이라고 생각합니다. 첫 번째는 사용자의 관점에서 기능을 바라보는 능력입니다. 기능 자체보다 사용자가 어떤 상황에서 어떤 문제를 해결하려고 하는지를 먼저 생각하게 됩니다. 두 번째는 요구사항의 배경을 질문하는 능력입니다. 단순히 “어떻게 구현할까요?” 라고 질문하는 것이 아니라, “왜 필요한가요?” “누가 사용하는 기능인가요?” “어떤 문제를 해결하려는 것인가요?” 를 함께 질문하게 됩니다. 세 번째는 우선순위를 판단하는 능력입니다. 모든 기능을 구현하는 것이 좋은 제품 개발은 아닙니다. 개발 비용, 사용자 가치, 적용 범위, 장기적인 효과를 함께 고려하여 어떤 기능을 먼저 만들어야 하는지 판단할 수 있어야 합니다. 네 번째는 기술적 판단을 사용자 가치와 연결하는 능력입니다. Performance, Reliability, Scalability, Architecture와 같은 기술적 결정도 결국 사용자의 경험과 연결되어 있다는 점을 이해하게 됩니다. 다섯 번째는 Product Manager나 Designer와의 커뮤니케이션 능력입니다. 제품의 목표와 사용자 문제를 이해하는 개발자는 단순히 요구사항을 전달받는 사람이 아니라 제품 결정 과정에 참여할 수 있는 엔지니어가 됩니다. 결론이 책은 좋은 개발자가 되기 위해 기술력만으로 충분한가라는 질문을 던지는 책입니다. 그리고 이 책의 대답은 비교적 분명합니다. 좋은 엔지니어는 단순히 코드를 잘 작성하는 사람에서 끝나지 않습니다. 사용자가 누구인지 이해하고, 사용자가 해결하려는 문제를 파악하고, 제한된 개발 자원을 가치 있는 문제에 사용할 수 있어야 합니다. 그리고 Performance, Architecture, Reliability와 같은 기술적 결정도 결국 사용자가 경험하는 가치와 연결해서 판단할 수 있어야 합니다. 이 책을 읽는다고 바로 Product-Minded Engineer가 되는 것은 아닐 것입니다. 하지만 개발 과정에서 던지는 질문은 달라질 수 있습니다. 기존에는 "이 기능을 어떻게 구현하지 ?" 였다면, 이 책을 읽은 이후에는 "누구를 위해 만들지 ?" "이 기능이 정말 필요한가 ?" 등 개발자 관점에서 실제 서비스등 제품으로써의 가치까지 보기 위한 질문과 생각으로 바뀔 것이라 생각합니다. 특히 직접 자신의 서비스나 제품을 만들어 보고 싶은 개발자라면 한 번쯤 읽어 볼 만한 책입니다. 기술 자체를 목표로 삼는 것이 아니라, 기술을 이용하여 사용자에게 더 좋은 결과를 만들어 내는 엔지니어라고 생각합니다. 최근에는 AI를 활용해 코드 작성과 프로토타입 개발에 필요한 시간이 빠르게 줄어들고 있습니다. 이러한 환경에서는 단순히 “코드를 얼마나 빨리 작성할 수 있는가”보다 “무엇을 만들어야 하는가” 를 판단하는 능력이 오히려 더욱 중요해질 수 있습니다. 그런 의미에서 이 책은 단순한 제품 개발 방법론에 관한 책이라기보다, 앞으로 개발자가 어떤 방향으로 자신의 역할을 확장해야 하는지를 생각해 보게 하는 책이라고 생각합니다. |
한빛미디어 서평단 ＜나는리뷰어다＞ 활동을 위해서 책을 협찬받아 작성된 서평입니다.이 책을 읽고 가장 크게 달라진 질문은 "어떻게 만들까?"에서 "왜 만들고 누가 사용할까?"였다. 저자는 프로덕트 사고를 PM이나 디자이너만의 영역으로 두지 않는다. API, 개발자 도구, 사내 플랫폼처럼 화면이 없는 소프트웨어에도 사용자가 있으며 엔지니어의 기술적 결정은 결국 그들의 경험으로 이어진다고 설명한다. How보다 먼저 Why를 묻는다책의 첫 장은 시나리오 없이 개발한 경우와 시나리오를 먼저 작성한 경우를 비교한다. 새로운 기능을 접하면 데이터베이스 구조나 API부터 떠올리기 쉽지만 저자는 사용자가 어떤 상황에서 무엇을 하려는지 먼저 이야기로 적어보라고 한다. 시나리오는 단순한 요구 사항 요약이 아니다. 사용자 인터뷰에서 얻은 맥락을 담고 제품의 빈틈과 마찰을 드러내며 구현하려는 기능을 검증하는 작은 시뮬레이션이 된다. 이후에는 테스트와 우선순위를 정하는 기준으로도 사용할 수 있다. 나 역시 새로운 문제를 보면 구현 방법부터 생각하는 편이라 이 부분이 가장 먼저 와닿았다. AI는 불완전한 요구 사항도 빠르게 코드로 바꿔준다. 그래서 출발점이 잘못되면 이전보다 더 빠르게 필요 없는 기능을 완성할 수도 있다. 구현 속도가 빨라질수록 코드를 작성하기 전에 사용자, 상황, 목적을 구체화하는 시간이 더 중요해진다는 뜻이다. 사용자는 화면 밖에도 있다책에서 말하는 사용자는 앱 화면을 직접 보는 고객만을 뜻하지 않는다. 내가 만든 API를 호출하는 개발자, 사내 도구를 사용하는 동료, 라이브러리를 설치하는 사람도 모두 사용자다. 이 관점으로 보면 함수 이름, 기본값, 문서, 샘플 코드와 호환성도 제품 경험의 일부가 된다. 오픈소스에 기여할 때도 같은 기준을 적용할 수 있다. 수정한 코드가 테스트를 통과하는 것과 다른 개발자가 문서와 API만 보고 기능을 문제없이 사용하는 것은 다른 일이다. 기능이 존재해도 사용자가 발견하지 못하거나 의미를 이해하지 못하거나 실제 작업에 적용하지 못하면 제품은 역할을 다하지 못한다. 책이 사용자 여정을 발견, 이해, 사용으로 나누는 이유도 여기에 있다. 에러 메시지도 제품의 인터페이스다개인적으로 가장 인상 깊었던 주제는 에러와 경고였다. 개발자는 에러 메시지를 예외 처리 뒤에 붙이는 문구나 디버깅 정보로 보기 쉽다. 하지만 사용자에게 에러는 제품이 문제를 설명하고 다음 행동을 안내하는 순간이다. 단순히 "잘못된 요청"이라고 알려주는 것과 어떤 입력이 왜 잘못됐고 어떻게 고쳐야 하는지 알려주는 것은 전혀 다른 경험을 만든다. 좋은 진단은 문제가 원인에서 멀리 퍼진 뒤가 아니라 원인에 가까운 지점에서 일찍 실패하게 한다. 메시지에는 사용자가 처한 맥락과 해결 방법이 함께 있어야 한다. 이 내용을 읽으면서 안정적인 코드를 만드는 것과 사용자가 스스로 문제를 해결할 수 있게 만드는 일이 분리되어 있지 않다는 생각이 들었다. 에러 메시지는 마무리 단계의 자잘한 작업이 아니라 엔지니어의 제품 감각이 가장 직접적으로 드러나는 인터페이스였다. 직접 사용하고 마찰을 기록한다도그푸딩, 문서 주도 개발, 마찰 로그를 다루는 부분은 바로 적용해보기 좋았다. 개발자는 이미 제품의 구조와 사용법을 알기 때문에 처음 쓰는 사람이 멈추는 지점을 쉽게 지나친다. 직접 설치하고 첫 작업을 끝까지 수행해보면서 불필요하게 고민한 순간, 설명이 부족한 부분, 반복되는 단계를 마찰 로그에 남기면 익숙함 때문에 보이지 않던 문제를 찾을 수 있다. 문서를 코드를 완성한 뒤 쓰는 설명서가 아니라 설계 도구로 사용하는 접근도 좋았다. 사용 방법을 먼저 적어보면 인터페이스가 지나치게 복잡한지 입력과 결과가 자연스러운지 구현 전에 확인할 수 있다. 다만 팀 내부의 도그푸딩만으로 실제 사용자를 완전히 이해할 수는 없다. 저자도 피드백과 제품 지표를 함께 보며 출시 이후에도 계속 사용자를 배워야 한다고 강조한다. 직접 사용해보는 일은 고객 발견의 대체재가 아니라 더 나은 질문을 만드는 출발점에 가깝다. 아키텍처도 사용자 경험에서 시작한다마지막 장의 프로덕트 아키텍처도 흥미로웠다. 지연 시간, 가용성, 일관성, 확장성과 같은 비기능 요구 사항(Non-Functional Requirements, NFR)은 보통 시스템 내부의 품질로만 생각하기 쉽다. 이 책은 그 수치를 사용자의 경험으로 다시 번역한다. 긴 지연 시간은 단순히 벤치마크가 나쁜 것이 아니라 사용자의 작업 흐름을 끊고, 낮은 가용성은 서비스를 믿고 사용할 수 없게 만든다. 일관성 역시 데이터베이스가 제공하는 속성만이 아니라 사용자가 제품에서 기대하는 동작과 연결된다. 이 관점이 좋았던 이유는 프로덕트 사고가 기술을 덜 중요하게 만드는 것이 아니라 기술적 선택의 기준을 더 분명하게 만들기 때문이다. 먼저 어떤 경험을 지켜야 하는지 정하면 모든 지표를 무조건 높이는 대신 사용자에게 중요한 부분에 비용과 복잡성을 쓸 수 있다. 좋은 시스템 설계와 좋은 제품 설계가 따로 존재하지 않는다는 메시지가 책의 마지막까지 이어진다. 제품 판단에 더 깊이 참여한다한편 프로덕트 중심 엔지니어가 PM이나 디자이너를 무조건 대신해야 한다는 뜻은 아니다. 책은 엔지니어가 PM이나 디자이너와 더 잘 협업하는 방법을 설명하면서도 상황에 따라 제품 방향을 더 주도적으로 이끌거나 프로덕트/엔지니어링 하이브리드로 성장할 수 있다고 말한다. 모든 제품 의사결정을 혼자 떠안으라는 의미라기보다 기술적 제약과 사용자 경험을 함께 이해한 사람이 판단 과정에 더 깊이 참여하라는 뜻으로 읽혔다. 내가 이 부분에서 가져가고 싶은 것은 새로운 직무를 하나 더 맡아야 한다는 부담보다 주어진 요구 사항을 그대로 구현하지 않고 더 적극적으로 의견을 내는 태도였다. 왜 필요한지 묻고 더 작은 실험을 제안하고 출시 뒤의 반응까지 확인하는 것이다. 이 정도의 주도성은 직급과 상관없이 연습할 수 있다고 생각한다. 읽으면서 느낀 장점과 한계가장 큰 장점은 추상적인 "사용자 중심"을 시나리오, 진단, 도그푸딩, 마찰 로그, 페르소나, 제품 지표처럼 실행 가능한 도구로 바꿔준다는 점이다. 각 장의 예제에서 먼저 답을 생각하고 저자의 답안과 비교할 수 있는 구성도 좋았다. 제품 문제에는 하나의 정답이 없기 때문에 내가 놓친 관점을 확인하는 과정 자체가 공부가 된다. 다만 다루는 범위가 넓다 보니 모든 개념을 같은 깊이로 설명하지는 않는다. 더블 다이아몬드(Double Diamond)와 해야 할 일(Jobs to Be Done, JTBD)은 전체 흐름을 설명하는 틀에 가깝다. 반면 페르소나와 시나리오는 고객 인터뷰부터 요구 사항과 우선순위로 바꾸는 과정까지 꽤 구체적으로 다룬다. 이미 제품 조직에서 오래 일한 독자에게는 익숙한 내용도 있을 것이다. 반대로 개발을 막 시작한 독자는 개념을 이해하더라도 실제 경험과 연결하기 어려울 수 있다. 에러 처리, 운영, 사용자 피드백, 아키텍처의 트레이드오프를 한 번이라도 겪어본 독자가 더 많은 내용을 가져갈 수 있다고 생각한다. 무엇보다 제목만 보고 AI 도구 사용법을 기대하면 방향이 다르다. Claude Code나 Cursor 사용법, 프롬프트 작성법, AI 애플리케이션 구현법을 가르치는 책은 아니다. 다만 7장에서는 AI 어시스턴트를 사례로 제품 테제, 타깃 오디언스, 북극성 시나리오와 요구 사항을 구체화한다. AI를 완전히 비켜가는 책이 아니라 AI를 어떻게 만들지보다 무엇을 왜 만들지에 초점을 둔다. 새로운 기술 하나를 배우는 책이라기보다 이미 가진 기술을 어디에 어떻게 써야 하는지 기준을 세워주는 책이었다. 대상 독자
|
|
한빛미디어 서평단 ＜나는리뷰어다＞ 활동을 위해서 책을 협찬 받아 작성된 서평입니다.  코드를 작성할 때에도 제품 중심 마인드를 갖추자 개발하면서 AI를 이용하는 게 거의 필수가 된 지금, 정작 이 코드를 소비할 내부 팀원들을 고려하지 못한 채 개발하는 케이스가 종종 있었습니다. 특히, 저는 회사에서 WMS API 연계를 개발하면서 제가 작성한 클래스, 함수 (예: 재고 조회 API, 출고 생성 API..)들을 내부 팀원들이 이용하는 케이스가 많았는데, 그동안 저 자신만 이해할 수 있는 명명 규칙을 이용했거나, 확장성 있게 기존 API를 보완하지 않은 채 특정 유즈케이스를 충족하는 같은 기능의 별도 API를 따로 만든 적이 많아 오히려 유지보수 / 사용성 측면에서 헷갈리게끔 작성한 적이 있었습니다. 그리고 이 경험은 후에 리팩터링을 하는 과정에서도 큰 장애물로 남겨졌었습니다. 코드를 작성하는 것은 AI로 위임되었지만, 최종적으로 그 코드로 가이드해야 하는 것은 지시한 사람이 해야 하는 것이기에 더욱 더 API 설계와 네이밍 규칙 등 기본기에 대해 꾸준히 공부하자는 마인드를 갖게 되었습니다. 기획 부채의 시대: 불완전한 기획, 불완전한 개발, 불완전한 출시 본 책을 읽으면서, 동시에 링크드인에서 좋은 글을 하나 보았습니다. 레스큐 엔지니어링이라는 시장을 들어보셨나요. AI가 만든 소프트웨어를 사람이 다시 뜯어고치 레스큐 엔지니어링이라는 시장을 들어보셨나요. AI가 만든 소프트웨어를 사람이 다시 뜯어고치는 일로 새로운 시장과 직업이 생겼습니다. 세계 최대 프리랜서 플랫폼인 Fiverr의 Vibe Coding 카테고 kr.linkedin.com 정리하자면, 애매한 요구사항은 애매한 채로 그 즉시 코드가 되고, 기획의 빈칸은 그대로 제품에 반영된다는 뜻입니다. 그래서 요즘은 역으로 AI가 개발한 제품을 사람이 손보는 작업인 레스큐 엔지니어링이라는 시장이 생긴 것입니다. 이와 같은 케이스는 제가 업무를 진행할 때에도 비슷한 현상이 많이 있었습니다. 개발은 AI가 진행해주고, 출시해야 할 제품이 많다보니 기획도 많아지고, 그에 따라 각 제품의 디테일한 엣지 케이스 등은 고려되지 못한 채 그대로 개발 및 출시가 되는 현상이 잦았고, 결과적으로 제품의 품질 또한 낮아지고 있었습니다. 이를 개선하기 위한 방법으로는 기획 과정에서부터 기획자만 기획을 하는 게 아니라 실제 개발을 진행할 개발자들이 기획 과정에서 충분한 유즈케이스와 사용자 시나리오를 논의해보고, QA도 개발 후 검토를 하지 않고 기획 단계에서부터 기획자 / 개발자가 파악하지 못한 엣지 케이스는 없는지 검토해보는 과정이 필요할 것입니다. 또한, 반드시 각 제품을 기획/개발할 때 제품 하나에만 집중할 수 있도록 충분히 지원이 보장되어야 한다고 생각합니다. (다른 제품을 기획/개발/검증하는 것을 반복할 경우, 잦은 컨텍스트 스위칭으로 품질 저하를 초래할 수 있다고 생각합니다.) 또한, 개발을 할 때에는 반드시 의사결정기록 (ADR: Architecture Decision Record)을 남기면서 진행을 해야 어떤 의사결정을 통해 코드가 만들어지게 되었는지 관리해야 할 것입니다. 충분한 기획에서 만들어진 코드가 어떤 의사결정을 토대로 만들어졌는지 확인할 수 있다면, AI의 hallucination으로 인한 잘못된 개발을 지양할 수 있을 것이라 생각합니다. 테스트 주도 개발을 할 때 테스트를 먼저 진행하는 이유 AI로 개발을 하면서 테스트 또한 AI에게 작성을 시키는 경우가 흔한데, 이때 개발을 다 하고 나서 테스트를 작성하게 하면 이미 동작하고 있는 것에 대해서만 테스트를 작성할 확률이 큽니다. "테스트를 작성했으니까 괜찮겠지" 정도가 아니라, "기획서에 기반한 사용자 시나리오를 테스트로 검증했으니, 그만큼의 신뢰성이 확보되었다" 수준으로 끌어올려야지만 테스트의 의미가 있다고 봅니다. 이는 AI 개발 시대에 따른 테스트의 신뢰도를 유지할 수 있는 방법이라고 생각합니다. 특히, 요즘은 AI Agent를 이용하여 Playwright 기반 E2E 테스트를 쉽게 만들어낼 수 있는 등 자동화 기법이 다양하게 지원되기 때문에 앞으로는 본질적으로 테스트가 추구하던 것 (신뢰성)을 지키도록 해야겠다는 생각이 들었습니다. 마무리하며본질적인 "엔지니어"란 어떤 책임과 자세를 갖추어야 하는가에 대한 고민을 할 수 있게 해 주었던 책이었습니다. 책을 읽으며 기획적인 역량은 전혀 갖추고 있지 못했음을 알게 되어 반성이 되기도 했고, AI 시대에 제품/사용자 중심의 엔지니어가 왜 중요한 자리로 평가받는지에 대해서도 체감할 수 있었습니다. 더 이상 "나는 아직 1년차, 2년차 주니어 개발자야. 그래서 이런 부분은 미숙한 게 괜찮아" 와 같은 태도는 허용해주지 않는 세상입니다. 하루빨리 내가 만들고 있는 게 이쁜 쓰레기는 아닌지 점검하고 더 개선해서 의사결정에 적극적으로 참여하는 개발자가 되어야겠다고 느끼게 해 준 책이었습니다. |
|
“한빛미디어 서평단 ＜나는리뷰어다＞ 활동을 위해서 책을 협찬 받아 작성된 서평입니다.”
읽다 보니 제목과 달리 product에 대한 내용이 대부분이란 생각을 했는데, 원제가 'The Product-Minded Engineer'다. AI에 대한 책이라기보다 프로덕트를 만드는 개발자/팀의 사고방식에 관한 책이다. 그렇다고 한국어판 제목이 아주 틀린 것도 아니다. 일부지만 코드를 직접 작성하지 않는다고 답하는 개발자도 많아진 시대에 엔지니어에게 남는 일은 결국 '무엇을 왜 만드는가'를 판단하는 일이고, 이 책이 처음부터 끝까지 다루는 것이 그 판단을 어떻게 하면 잘할지에 대한 이야기이기 때문이다. MS, Meta(페이스북, 오큘러스), Stripe를 거친 저자는 자신의 경험을 설명한다. 사용자 여정을 발견, 이해, 사용의 세 시나리오로 나누는 프레임에서 시작해 테스트, 지표 선택, 인터랙션 설계, 프로덕트 아키텍처까지 프로덕트를 만드는 전 과정을 다룬다. 추상적인 원칙이나 구호에 그치지 않고 구체적으로, 예를 들어 2003년 MS 워드의 도구 모음이 31개였다는 숫자, Stripe API 문서에 회계 용어가 없는 것이 의도된 결정이었다는 일화를 통해 좀 더 독자가 쉽게 다가갈 수 있게 알려준다. 특히 기억에 남는 것 중 하나가 '대체 제품 대비 가치'라는 개념이다(야구의 VORP에서 가져왔다는 게 흥미롭다). 시장에 이미 존재하는 대체재의 가치를 빼고 나면, 제품의 가치는 단순한 효용보다 훨씬 늦게 양수로 바뀐다. 자전거는 바퀴 두 개, 브레이크, 핸들바에 언덕을 오를 기어까지 갖춰져야 비로소 탈 수 있을 물건이 된다. 바퀴 하나만 있거나(외발자전거를 탈 수는 있지만, 수요 자체가 많지 않다), 핸들이 없으면(굴러는 가겠지만 서커스에서나 사용할 가능성이 높다) 일반적인 자전거 시장에서는 수요가 거의 없어서 효용 자체가 없거나 매우 낮다. 사용자들이 기대하는 일반적인 걸 갖춰야 상품이 될 최소한의 자격을 갖게 되고, 단순히 유용한 것을 넘어 어딘가 특별해야 팔리는 상품이 된다는 '진실'은, 만들다 보면 잊기 쉬운 현실을 보여준다. 그 밖에도 관점을 뒤집는 부분들이 기억할 만하다. 에러 메시지는 빨리 해치울 엣지 케이스가 아니라 제품을 차별화하는 핵심이고 장인 정신이 드러나는 부분이라는 것, 지원 요청에서 잘못한 건 사용자가 아니라 제품이라는 것, 일관성 보장은 데이터베이스의 속성이 아니라 제품 기능의 속성이라는 것 모두 엔지니어가 시스템 쪽에 서서 보던 것을 사용자 쪽으로 돌려세우는 문장들이다. 저자는 이렇게 시나리오, 페르소나, 기표, 어포던스로 사고하는 능력을 기술 역량과 연결하면 '구조화된 공감'이 생긴다고 말하는데, 공감이라는 막연한, 특히 기술에만 매몰되기 쉬운 엔지니어들이 빠뜨리기 쉬운, 요소를 훈련 가능한 기술로 바꿔 놓은 표현이란 생각이 든다. AI가 코드를 쓰는 시대에 엔지니어/프로덕트 팀의 경쟁력이 어디에 있을지 궁금한 사람이라면, 이 책에서 꽤 유용한 답을 얻을 수 있겠단 생각이다. |
|
한빛미디어 서평단 ＜나는 리뷰어다＞ 활동을 위해서 책을 협찬받아 작성된 서평입니다. 이 책을 읽으면서 가장 인상적이었던 점은 개발 과정의 익숙한 활동들을 모두 프로덕트 사고의 관점에서 다시 해석한다는 점이었다. 사용자 시나리오, 에러 메시지, 테스트, 도그푸딩, 피드백, 인터랙션, 아키텍처처럼 각각 따로 생각하기 쉬운 요소들을 결국 하나의 질문으로 연결한다. “이 소프트웨어를 사용하는 사람은 누구이며, 그 사람에게 실제로 어떤 경험을 제공하고 있는가”라는 질문이다. 1장에서 다루는 사용자 시나리오는 데이터 분석 경험과 특히 잘 연결됐다. 데이터 분석을 시작할 때는 보통 데이터 자체에 먼저 관심이 간다. 어떤 컬럼이 있는지, 결측치는 얼마나 되는지, 어떤 모델이나 시각화를 적용할 수 있는지를 살펴보게 된다. 하지만 실제 프로젝트에서는 분석 기법보다 먼저 확인해야 할 것이 있다. 누가 이 분석 결과를 보는지, 어떤 판단을 하기 위해 사용하는지, 결과를 본 뒤 어떤 행동을 해야 하는지다. 책에서는 시나리오가 단순한 설명문이 아니라 제품의 공백과 마찰을 찾고, 구현하려는 기능을 검증하고, 나아가 테스트의 역할까지 할 수 있다고 설명한다. 이 부분이 인상적이었다. 데이터 분석에서도 “관리자가 재고 부족 가능성이 높은 품목을 확인하고 발주 여부를 결정한다”처럼 구체적인 시나리오를 먼저 정의하면 필요한 지표와 화면 구성이 훨씬 명확해진다. 반대로 시나리오 없이 분석을 시작하면 그래프와 지표는 많지만 실제로 무엇을 판단해야 하는지 알기 어려운 결과물이 만들어지기도 한다. 2장에서 설명하는 발견, 이해, 사용의 사용자 여정도 프로그램 개발 경험과 연결해서 생각할 수 있었다. 개발자는 기능이 존재하면 사용자가 자연스럽게 찾아서 사용할 것이라고 생각하기 쉽다. 하지만 실제로는 기능을 발견할 수 있는지, 기능의 의미를 이해할 수 있는지, 실제 작업에 사용할 수 있는지가 각각 다른 문제다. 내가 만든 프로그램이나 데이터 분석 도구를 다른 사람이 사용할 때도 이런 차이를 자주 볼 수 있었다. 기능은 정상적으로 구현되어 있지만 어디에서 실행해야 하는지 찾기 어렵거나, 버튼의 이름만으로 기능을 이해하기 어렵거나, 입력 데이터 형식을 몰라 실행하지 못하는 경우가 있다. 책에서 말하는 것처럼 사용자 경험은 기능이 동작하는 순간부터 시작되는 것이 아니라 사용자가 기능을 발견하는 단계부터 이미 시작되고 있다는 생각이 들었다. 3장의 에러와 경고에 대한 내용도 실무 경험과 직접적으로 연결됐다. 개발할 때는 에러 메시지를 디버깅을 위한 정보로 생각하기 쉽다. 스택 트레이스나 예외 이름이 개발자에게는 유용하지만 일반 사용자에게는 해결 방법을 알려주지 못한다. 예를 들어 데이터 분석 프로그램에서 단순히 4장의 도그푸딩과 문서 주도 개발도 프로그램과 시스템을 개발하면서 중요하다고 느꼈던 부분이다. 자신이 만든 프로그램을 직접 처음부터 설치하고 사용해 보면 개발할 때는 보이지 않던 문제가 발견된다. 환경 설정이 지나치게 복잡하거나, 파일을 특정 위치에 두어야 하거나, 실행 순서를 알아야만 사용할 수 있는 경우가 있다. 개발자는 이미 시스템을 알고 있기 때문에 이런 마찰을 쉽게 지나친다. 책에서 제안하는 마찰 로그는 이런 문제를 기록하는 단순하지만 현실적인 방법이다. 직접 사용하면서 막힌 지점이나 불필요하게 생각해야 했던 지점을 기록하는 것만으로도 개선할 부분을 찾을 수 있다. 문서 주도 개발 역시 비슷하다. 코드를 먼저 만들고 사용법을 설명하는 것이 아니라 사용자가 어떻게 사용할지를 먼저 문서로 작성하면 인터페이스 자체의 문제를 더 일찍 발견할 수 있다. 5장에서 다루는 지속적인 사용자 이해와 피드백 루프 역시 데이터 분석 시스템을 운영할 때 중요하다. 처음에 정의한 요구 사항이 시간이 지나도 그대로 유지되는 경우는 많지 않다. 업무 방식이 바뀌거나 데이터가 추가되고 사용자가 중요하게 보는 지표도 달라진다. 특히 대시보드나 분석 시스템에서는 개발자가 중요하다고 생각한 지표와 실제 사용자가 반복해서 확인하는 지표가 다를 수 있다. 이때 사용자의 피드백뿐 아니라 실제 사용 패턴과 제품 지표를 함께 보는 것이 중요하다는 책의 설명에 공감했다. 분석 시스템 역시 한번 만들어 전달하는 결과물이 아니라 계속 수정되고 학습해야 하는 제품으로 바라볼 필요가 있다. 6장의 타깃 오디언스와 페르소나는 내부 시스템을 개발할 때도 적용할 수 있다는 점이 흥미로웠다. 내부 업무 프로그램은 사용자가 명확하기 때문에 별도의 사용자 분석이 필요하지 않다고 생각하기 쉽다. 하지만 같은 시스템을 사용하더라도 실무 담당자, 관리자, 데이터 분석가, 개발자가 필요로 하는 기능은 서로 다르다. 예를 들어 실무자는 빠르게 데이터를 입력하고 결과를 확인하고 싶어 할 수 있고, 관리자는 전체 현황과 예외 상황을 보고 싶어 할 수 있다. 데이터 분석가는 원본 데이터에 접근하고 싶어 할 수 있다. 책에서 이야기하는 다중 페르소나 제품의 문제를 실제 내부 시스템에서도 자주 볼 수 있다는 생각이 들었다. 7장의 북극성 시나리오와 요구 사항 우선순위에 대한 내용도 인상적이었다. 프로그램을 만들다 보면 구현 가능한 기능이 계속 늘어나고, 특히 AI를 활용하면 새로운 기능을 추가하는 비용도 많이 낮아진다. 그래서 무엇을 추가할 수 있는지가 아니라 무엇을 먼저 만들어야 하는지가 더 중요해졌다. 책에서는 제품의 이상적인 사용 모습을 북극성 시나리오로 정의하고 이를 사용자 흐름과 JTBD, 구체적인 요구 사항으로 연결한다. 이런 방법은 데이터 분석 프로젝트에서도 유용하다고 생각했다. 처음부터 가능한 분석을 모두 하는 것이 아니라 최종적으로 사용자가 어떤 결정을 더 잘 내리게 만들 것인지를 정의하면 우선순위가 훨씬 명확해진다. 8장의 인터랙션 설계에서는 올바른 사용을 유도하고 잘못된 사용을 방지하는 부분이 특히 기억에 남았다. 시스템에서 자유도를 높이는 것이 항상 좋은 것은 아니다. 사용자가 잘못된 데이터를 입력하거나 복구하기 어려운 작업을 실행할 수 있다면 제한을 두는 것이 오히려 좋은 경험이 될 수 있다. 데이터 처리 시스템에서도 날짜 범위를 잘못 입력하거나 필수 컬럼을 누락하거나 너무 큰 데이터를 한 번에 실행하는 등의 문제가 발생한다. 이런 상황을 사용자의 실수로만 볼 것이 아니라 애초에 잘못된 사용을 어렵게 만드는 인터페이스를 설계해야 한다는 관점이 중요하게 느껴졌다. 마지막으로 9장의 프로덕트 아키텍처는 내가 기존에 생각하던 시스템 아키텍처의 관점을 조금 확장시켜 주었다. 성능, 안정성, 확장성 같은 비기능 요구 사항은 보통 기술적인 품질로만 생각했다. 하지만 책에서는 이를 사용자 경험과 연결한다. 응답 속도가 느리다는 것은 단순히 성능 수치가 낮다는 의미가 아니라 사용자의 작업 흐름이 끊긴다는 의미다. 시스템이 불안정하다는 것은 장애율의 문제가 아니라 사용자가 결과를 신뢰할 수 없다는 문제다. API가 자주 변경되는 것도 개발 관점에서는 버전 관리의 문제지만 사용자 입장에서는 기존 프로그램을 계속 수정해야 하는 비용이 된다. 결국 기술적인 아키텍처 역시 제품 경험과 분리할 수 없다는 점이 인상적이었다. 이 책을 읽고 나니 데이터 분석이나 시스템 개발에서도 프로덕트 사고는 별도의 직무에서만 필요한 능력이 아니라는 생각이 들었다. 분석을 시작하기 전에 사용자 시나리오를 생각하고, 에러 메시지를 작성할 때 다음 행동을 안내하고, 직접 만든 프로그램을 사용하면서 마찰을 기록하고, 피드백을 통해 계속 개선하는 모든 과정이 프로덕트 사고에 해당한다. AI가 코드를 빠르게 만들어주는 지금은 이런 관점이 더 중요해진 것 같다. 구현해야 할 기능을 설명하면 AI가 상당 부분을 대신 만들어줄 수 있지만 어떤 문제를 해결해야 하는지, 누구에게 필요한 기능인지, 어떤 기능을 먼저 만들어야 하는지는 여전히 사람이 판단해야 한다. 나에게 이 책은 단순히 좋은 제품을 만드는 방법을 설명하는 책이라기보다 지금까지 해온 데이터 분석과 프로그램, 시스템 개발 경험을 다시 바라보게 만든 책이었다. |