"한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 책을 협찬받아 작성된 서평입니다."
📌 이 책을 한 문장으로
"엔지니어링은 단순히 코드를 구현하는 일이 아니라, 사용자의 문제를 발견하고 제품의 성공까지 연결하는 과정이라는 것을 알려주는 책."
『AI 시대의 엔지니어링 전략』이라는 제목을 처음 봤을 때는 AI를 활용해 개발하는 방법이나, AI 시대에 개발자가 어떤 기술을 익혀야 하는지를 다루는 책이라고 생각했다.
그런데 읽어보니 이 책에서 AI는 주제가 아니라 배경에 가깝다.
AI가 점점 더 많은 코드를 작성해주는 시대가 되었기 때문에, 앞으로 엔지니어에게 중요한 것은 단순히 How, 즉 어떻게 구현할 것인가만 잘 아는 것이 아니라 Why, 왜 이것을 만들어야 하는지를 이해하고 판단하는 능력이라는 것이 책 전체를 관통하는 이야기다. 실제 책 소개 역시 구현을 넘어 사용자와 제품 전체를 바라보는 ‘프로덕트 중심 엔지니어’를 핵심 주제로 삼고 있다.
개인적으로 이 책을 읽으며 가장 크게 얻은 것은 ‘엔지니어링이란 무엇인가’에 대한 기준이 조금 더 명확해졌다는 점이다. 좋은 코드를 작성하고 확장 가능한 아키텍처를 만드는 것만이 엔지니어링의 전부가 아니다.
누가 사용하는지, 왜 필요한지, 사용자는 어떤 상황에서 이 기능을 만나게 되는지, 어떤 마찰을 겪을 수 있는지, 우리가 만든 것이 실제 문제를 해결하고 있는지를 함께 생각하는 것. 그리고 그 생각이 요구 사항과 설계, 구현, 전달, 피드백으로 연결되는 전체 과정이 엔지니어링이라는 생각을 하게 됐다.
📌 책의 흐름 - 구현에서 시작해 제품 전체를 바라보기까지
① 프로덕트 사고의 시작 - "누가, 왜, 어떤 상황에서 사용하는가"
책은 처음부터 기술이나 아키텍처 이야기를 시작하지 않는다. 대신 시나리오를 통해 사용자가 어떤 상황에 놓여 있고, 무엇을 하려고 하며, 우리가 만드는 기능이 그 과정에서 어떤 역할을 해야 하는지를 생각하게 만든다.
특히 시나리오를 단순한 요구 사항 문서가 아니라 사용자 인터뷰를 담아내고, 제품의 빈틈과 마찰을 발견하고, 심지어 구현하려는 기능을 검증하는 도구로 사용하는 방식이 인상적이었다.
책을 읽다 보면 자연스럽게 질문이 바뀐다. "이 기능을 어떻게 구현하지?"에서 "사용자는 왜 이 기능이 필요하지?", "이 기능을 발견하고 이해하고 사용하는 과정은 자연스러운가?"로 넘어간다.
이 질문의 변화가 이 책에서 말하는 프로덕트 사고의 출발점이라고 느꼈다.
② 개발 - 코드 바깥의 사용자 경험까지 바라보기
제품 내 사용자 안내와 에러, 경고를 다루는 부분에서는 평소 개발하면서 쉽게 기술적인 문제로만 생각했던 것들을 사용자 경험의 관점에서 다시 바라보게 한다.
특히 에러 메시지가 대표적이다.
개발자는 에러를 예외 처리나 로그의 문제로 생각하기 쉽지만, 사용자 입장에서는 에러 메시지 역시 제품과 대화하는 하나의 인터페이스다. 책 역시 진단과 에러를 제품의 중요한 인터페이스로 보고, 맥락과 해결 방법을 함께 전달해야 한다는 관점을 강조한다.
이 부분을 읽으면서 프로덕트를 바라보는 시야가 생각보다 훨씬 넓어야 한다는 것을 느꼈다.
③ 전달 - 우리가 만든 제품을 직접 경험하기
도그푸딩, 문서 주도 개발, 마찰 로그, 사용자 피드백과 제품 지표 등은 모두 비슷한 방향을 바라보고 있다.
"만들었으니 끝"이 아니라 실제로 사용되는 과정까지 엔지니어가 관심을 가져야 한다는 것이다. 특히 자신이 만든 제품을 직접 사용해보고 어디에서 불편함을 느끼는지 기록하는 접근법은 특별히 화려한 기술은 아니지만, 그래서 오히려 실무에서 더 중요하다고 느껴졌다.
개발자는 내부 구조를 알고 있기 때문에 사용자가 겪는 불편을 무의식적으로 건너뛰기 쉽다. 이 책은 계속해서 시스템 내부에서 한 걸음 나와 사용자의 위치로 이동해보라고 이야기한다.
④ 발견 - 무엇을 만들 것인가
후반부로 갈수록 타깃 사용자, 고객 발견, 페르소나, 사용자 흐름, JTBD, 요구 사항의 우선순위처럼 조금 더 프로덕트 매니지먼트와 디자인에 가까워 보이는 주제들이 등장한다.
처음에는 "이것까지 엔지니어가 알아야 하나?"라는 생각도 들었다. 그런데 오히려 그 점이 이 책의 핵심이었다.
엔지니어가 PM이나 디자이너의 역할을 대신해야 한다는 뜻이 아니라, 자신이 만드는 제품이 어떤 문제를 풀고 있는지 이해할 정도의 프로덕트 감각은 가져야 한다는 것이다. 저자가 권하는 방법 역시 계속해서 "왜?"를 질문하고, 시스템 관점에서 사용자 관점으로 이동했다가 다시 돌아오고, 시나리오를 통해 사용자의 행동을 시뮬레이션하는 것이다.
⑤ 정의 - 결국 설계와 아키텍처로 돌아온다
마지막에는 인터랙션 설계와 프로덕트 아키텍처를 다룬다. 여기까지 오면 앞에서 배운 내용들이 다시 개발자의 익숙한 영역과 연결된다.
다만 처음과 시선이 달라져 있다. 이제 아키텍처를 단순히 확장성과 성능, 유지보수성의 문제로만 보는 것이 아니라 그 구조가 어떤 사용자 경험을 만들어내는가까지 함께 생각하게 된다.
좋은 시스템 설계와 좋은 프로덕트 설계가 서로 분리된 것이 아니라는 점이 여기서 더욱 명확해졌다.
📌 좋았던 점
1. '엔지니어링이 무엇인가'를 다시 생각하게 만든다
이 책에서 가장 좋았던 부분이다.
그동안 개발을 하면서 설계와 구현을 잘하는 것이 엔지니어의 중요한 능력이라고 생각했다. 물론 그것도 중요하다. 하지만 이 책을 읽고 나서는 그보다 앞에 있는 질문이 더 중요하다는 생각이 들었다.
왜 만들어야 하는가. 누구를 위해 만드는가. 어떤 문제를 해결하려는가. 우리가 선택한 설계가 사용자의 경험에 어떤 영향을 주는가.
결국 엔지니어링은 주어진 요구 사항을 코드로 변환하는 작업이 아니라, 문제를 이해하고 적절한 해결책을 설계하고 구현해 사용자에게 전달하는 전체 과정이라는 것이다. 그래서 개인적으로는 기술 하나를 새롭게 배웠다기보다, 앞으로 개발하면서 어떤 시선으로 제품을 바라봐야 하는지에 대한 기준을 얻었다는 점에서 가치가 컸다.
2. 개발자가 익숙한 영역에서 조금씩 시야를 넓혀준다
API, 에러 메시지, 테스트, 문서, 아키텍처 같은 개발자에게 익숙한 소재에서 출발해 사용자 경험과 프로덕트 사고로 연결한다는 점도 좋았다.
특히 인상적이었던 것은 사용자를 바라보는 범위를 다시 생각하게 했다는 점이다. 흔히 '사용자'라고 하면 화면을 직접 사용하는 사람부터 떠올리기 쉽지만, 내가 만든 API를 사용하는 다른 개발자도 결국 내가 만든 소프트웨어의 사용자다. 이 관점은 백엔드 개발을 할 때도 충분히 적용할 수 있겠다는 생각이 들었다.
백엔드나 플랫폼 개발자는 흔히 "나는 사용자와 직접 만나는 제품을 만들지 않는다"고 생각하기 쉬운데, 이 책을 읽으면 API를 사용하는 다른 개발자 역시 사용자라는 사실을 다시 생각하게 된다.
이런 시각의 변화가 꽤 컸다.
3. 각 장의 '예제 → 답안' 구성이 정말 좋았다
개인적으로 이 책에서 특히 마음에 들었던 구성이다.
각 장이 내용을 설명하고 끝나는 것이 아니라 예제를 던지고 직접 생각해본 뒤 답안을 확인할 수 있도록 구성되어 있다. 실제로 모든 장에 예제와 답안이 배치되어 있다.
프로덕트 사고에는 알고리즘 문제처럼 하나의 정답이 있는 것이 아니다. 그래서 답안 자체보다 더 재미있었던 것은 "나는 이렇게 생각했는데 저자는 이런 부분까지 고려했구나." 라고 비교해보는 과정이었다.
다른 사람은 같은 상황을 어떤 시각으로 바라볼지 간접적으로 경험할 수 있고, 내가 놓친 관점을 발견할 수도 있다. 그냥 읽을 때보다 예제에서 한 번 멈추고 스스로 답을 생각한 뒤 저자의 답안을 확인하면 훨씬 얻어가는 것이 많았다.
4. AI 시대에 오히려 더 필요한 개발자의 능력을 이야기한다
제목에 왜 굳이 'AI 시대'가 붙었는지도 책을 다 읽고 나면 어느 정도 이해가 된다. AI가 코드를 더 빠르게 만들어준다고 해서 제품이 자동으로 좋아지는 것은 아니다.
무엇을 만들어야 하는지 잘못 판단했다면 AI는 잘못된 방향으로 더 빠르게 달려갈 뿐이다. 그래서 구현 비용이 낮아질수록 오히려 문제를 정의하는 능력, 사용자에게 공감하는 능력, 우선순위를 정하는 능력, 시스템과 제품 사이의 트레이드오프를 판단하는 능력이 중요해진다.
원서에 대한 개발자 리뷰에서도 기존에는 시스템을 개선하는 책은 많지만 제품을 개선하는 법을 개발자에게 가르치는 책은 드물다는 점을 이 책의 강점으로 평가한다.
그런 의미에서 이 책은 AI 사용법에 관한 책이라기보다 AI가 코드를 작성하는 시대에 인간 엔지니어가 무엇을 더 잘해야 하는가를 이야기하는 책에 가까웠다.
📌 아쉬웠던 점
가장 먼저 느낀 것은 초보 개발자가 읽기에는 생각보다 쉽지 않다는 점이다.
한빛미디어에서는 난이도를 '초중급'으로 소개하고 있지만, 원서를 출간한 O'Reilly에서는 이 책을 'Intermediate to advanced'로 분류하고 있다. 직접 읽어본 느낌은 후자에 조금 더 가까웠다. 책에서 다루는 개념 자체가 어려운 수식이나 복잡한 코드 때문에 어려운 것은 아니다.
오히려 어느 정도 제품을 만들어본 경험이 있어야 "아, 우리 팀에서도 이런 일이 있었는데.", "그때 이 관점으로 생각했으면 달랐겠구나." 라고 연결되는 내용이 많다.
사용자 피드백, 요구 사항, 아키텍처, 에러 처리, 운영 과정에서의 마찰 같은 문제를 실제로 경험해본 사람일수록 훨씬 많은 내용이 와닿을 것 같다. 그래서 개발을 이제 막 시작한 사람이라면 읽을 수는 있지만, 책의 내용을 온전히 체감하기에는 다소 어려울 수 있다.
또 하나는 제목만 보고 AI 개발 기술서를 기대한다면 내용이 예상과 많이 다를 수 있다는 점이다.
LLM을 활용한 코딩 방법이나 AI 에이전트 개발, 프롬프트 작성법을 알려주는 책이 아니다. AI는 개발자의 구현 능력이 빠르게 평준화되는 시대적 배경이고, 책의 실제 중심은 처음부터 끝까지 프로덕트 중심의 엔지니어링 사고다.
오히려 원제인 『The Product-Minded Engineer』가 책의 내용을 더 직접적으로 표현한다고 느꼈다.
📌 이런 분께 추천
✅ 어느 정도 개발 경험이 생겼는데 "좋은 개발자는 무엇이 다른가?"를 고민하기 시작한 분
✅ 요구 사항을 전달받아 구현하는 것을 넘어 제품에 더 적극적으로 기여하고 싶은 개발자
✅ 백엔드, API, 플랫폼, 인프라를 만들면서도 사용자 관점을 갖고 싶은 개발자
✅ PM·디자이너와 협업하면서 상대방이 어떤 관점으로 제품을 바라보는지 이해하고 싶은 분
✅ AI 코딩 도구가 발전할수록 개발자의 경쟁력이 어디에 있어야 하는지 고민하는 분
✅ 시니어 개발자나 테크 리드로 성장하며 기술적 판단과 제품 판단을 연결하고 싶은 분
반대로 프로그래밍 자체를 처음 배우는 초보 개발자에게 첫 개발 교양서로 권하기에는 조금 어렵다고 생각한다. 또 Claude Code나 Cursor 같은 AI 도구의 구체적인 사용법, 프롬프트 작성법, AI 애플리케이션 구현법을 기대한다면 이 책과는 방향이 다르다.
📌 마무리
개발을 하다 보면 자연스럽게 How에 집중하게 된다. 어떤 언어를 사용할지, 어떤 프레임워크가 좋은지, 데이터베이스를 어떻게 구성할지, 어떤 아키텍처가 더 확장성이 좋은지.
나 역시 이런 고민을 하는 것이 엔지니어링이라고 생각했던 것 같다. 그런데 이 책을 읽으며 그보다 먼저 물어야 할 질문들이 있다는 것을 다시 생각하게 됐다.
누가 이것을 사용하는가?, 왜 필요한가?, 사용자는 어떤 상황에서 이것을 만나게 되는가?, 우리가 해결하려는 문제가 정말 사용자의 문제인가?, 그리고 지금 선택한 설계가 결국 어떤 제품 경험으로 이어지는가?
좋은 엔지니어는 단순히 주어진 문제를 빠르게 구현하는 사람이 아니라, 해결해야 할 문제 자체를 이해하고 그 문제를 기술적으로 풀어내 제품의 성공까지 연결할 수 있는 사람일지도 모른다.
그 의미에서 이 책은 새로운 기술을 하나 알려주는 책은 아니었다. 오히려 앞으로 기술을 사용할 때 어떤 생각을 가지고 설계하고 구현해야 하는지를 알려주는 책이었다.
초반에는 생각보다 추상적인 내용과 낯선 프로덕트 개념 때문에 쉽게 읽히지 않는 부분도 있었다. 하지만 끝까지 읽고 나면 하나의 질문이 남는다.
"나는 지금 코드를 만들고 있는가, 아니면 좋은 제품을 만들고 있는가?"
AI가 점점 더 많은 구현을 대신해주는 시대라면 이 질문은 앞으로 더 중요해질 것 같다.
그리고 이 질문에 답하기 위해 어떤 시각으로 프로덕트를 바라봐야 하는지 알고 싶은 개발자에게, 『AI 시대의 엔지니어링 전략』은 꽤 괜찮은 길잡이가 되어줄 책이라고 생각한다.
