“한빛미디어 서평단 ＜나는리뷰어다＞ 활동을 위해서 책을 협찬 받아 작성된 서평입니다.”

https://www.hanbit.co.kr/books/ai-%EC%8B%9C%EB%8C%80%EC%9D%98-%EC%97%94%EC%A7%80%EB%8B%88%EC%96%B4%EB%A7%81-%EC%A0%84%EB%9E%B5?code=B9394344903

읽다 보니 제목과 달리 product에 대한 내용이 대부분이란 생각을 했는데, 원제가 'The Product-Minded Engineer'다. AI에 대한 책이라기보다 프로덕트를 만드는 개발자/팀의 사고방식에 관한 책이다. 그렇다고 한국어판 제목이 아주 틀린 것도 아니다. 일부지만 코드를 직접 작성하지 않는다고 답하는 개발자도 많아진 시대에 엔지니어에게 남는 일은 결국 '무엇을 왜 만드는가'를 판단하는 일이고, 이 책이 처음부터 끝까지 다루는 것이 그 판단을 어떻게 하면 잘할지에 대한 이야기이기 때문이다.

MS, Meta(페이스북, 오큘러스), Stripe를 거친 저자는 자신의 경험을 설명한다. 사용자 여정을 발견, 이해, 사용의 세 시나리오로 나누는 프레임에서 시작해 테스트, 지표 선택, 인터랙션 설계, 프로덕트 아키텍처까지 프로덕트를 만드는 전 과정을 다룬다. 추상적인 원칙이나 구호에 그치지 않고 구체적으로, 예를 들어 2003년 MS 워드의 도구 모음이 31개였다는 숫자, Stripe API 문서에 회계 용어가 없는 것이 의도된 결정이었다는 일화를 통해 좀 더 독자가 쉽게 다가갈 수 있게 알려준다.

특히 기억에 남는 것 중 하나가 '대체 제품 대비 가치'라는 개념이다(야구의 VORP에서 가져왔다는 게 흥미롭다). 시장에 이미 존재하는 대체재의 가치를 빼고 나면, 제품의 가치는 단순한 효용보다 훨씬 늦게 양수로 바뀐다. 자전거는 바퀴 두 개, 브레이크, 핸들바에 언덕을 오를 기어까지 갖춰져야 비로소 탈 수 있을 물건이 된다. 바퀴 하나만 있거나(외발자전거를 탈 수는 있지만, 수요 자체가 많지 않다), 핸들이 없으면(굴러는 가겠지만 서커스에서나 사용할 가능성이 높다) 일반적인 자전거 시장에서는 수요가 거의 없어서 효용 자체가 없거나 매우 낮다. 사용자들이 기대하는 일반적인 걸 갖춰야 상품이 될 최소한의 자격을 갖게 되고, 단순히 유용한 것을 넘어 어딘가 특별해야 팔리는 상품이 된다는 '진실'은, 만들다 보면 잊기 쉬운 현실을 보여준다.

그 밖에도 관점을 뒤집는 부분들이 기억할 만하다. 에러 메시지는 빨리 해치울 엣지 케이스가 아니라 제품을 차별화하는 핵심이고 장인 정신이 드러나는 부분이라는 것, 지원 요청에서 잘못한 건 사용자가 아니라 제품이라는 것, 일관성 보장은 데이터베이스의 속성이 아니라 제품 기능의 속성이라는 것 모두 엔지니어가 시스템 쪽에 서서 보던 것을 사용자 쪽으로 돌려세우는 문장들이다. 저자는 이렇게 시나리오, 페르소나, 기표, 어포던스로 사고하는 능력을 기술 역량과 연결하면 '구조화된 공감'이 생긴다고 말하는데, 공감이라는 막연한, 특히 기술에만 매몰되기 쉬운 엔지니어들이 빠뜨리기 쉬운, 요소를 훈련 가능한 기술로 바꿔 놓은 표현이란 생각이 든다. AI가 코드를 쓰는 시대에 엔지니어/프로덕트 팀의 경쟁력이 어디에 있을지 궁금한 사람이라면, 이 책에서 꽤 유용한 답을 얻을 수 있겠단 생각이다.

한빛미디어 서평단 ＜나는 리뷰어다＞ 활동을 위해서 책을 협찬받아 작성된 서평입니다.

이 책을 읽으면서 가장 인상적이었던 점은 개발 과정의 익숙한 활동들을 모두 프로덕트 사고의 관점에서 다시 해석한다는 점이었다. 사용자 시나리오, 에러 메시지, 테스트, 도그푸딩, 피드백, 인터랙션, 아키텍처처럼 각각 따로 생각하기 쉬운 요소들을 결국 하나의 질문으로 연결한다. “이 소프트웨어를 사용하는 사람은 누구이며, 그 사람에게 실제로 어떤 경험을 제공하고 있는가”라는 질문이다.

1장에서 다루는 사용자 시나리오는 데이터 분석 경험과 특히 잘 연결됐다. 데이터 분석을 시작할 때는 보통 데이터 자체에 먼저 관심이 간다. 어떤 컬럼이 있는지, 결측치는 얼마나 되는지, 어떤 모델이나 시각화를 적용할 수 있는지를 살펴보게 된다. 하지만 실제 프로젝트에서는 분석 기법보다 먼저 확인해야 할 것이 있다. 누가 이 분석 결과를 보는지, 어떤 판단을 하기 위해 사용하는지, 결과를 본 뒤 어떤 행동을 해야 하는지다.

책에서는 시나리오가 단순한 설명문이 아니라 제품의 공백과 마찰을 찾고, 구현하려는 기능을 검증하고, 나아가 테스트의 역할까지 할 수 있다고 설명한다. 이 부분이 인상적이었다. 데이터 분석에서도 “관리자가 재고 부족 가능성이 높은 품목을 확인하고 발주 여부를 결정한다”처럼 구체적인 시나리오를 먼저 정의하면 필요한 지표와 화면 구성이 훨씬 명확해진다. 반대로 시나리오 없이 분석을 시작하면 그래프와 지표는 많지만 실제로 무엇을 판단해야 하는지 알기 어려운 결과물이 만들어지기도 한다.

2장에서 설명하는 발견, 이해, 사용의 사용자 여정도 프로그램 개발 경험과 연결해서 생각할 수 있었다. 개발자는 기능이 존재하면 사용자가 자연스럽게 찾아서 사용할 것이라고 생각하기 쉽다. 하지만 실제로는 기능을 발견할 수 있는지, 기능의 의미를 이해할 수 있는지, 실제 작업에 사용할 수 있는지가 각각 다른 문제다.

내가 만든 프로그램이나 데이터 분석 도구를 다른 사람이 사용할 때도 이런 차이를 자주 볼 수 있었다. 기능은 정상적으로 구현되어 있지만 어디에서 실행해야 하는지 찾기 어렵거나, 버튼의 이름만으로 기능을 이해하기 어렵거나, 입력 데이터 형식을 몰라 실행하지 못하는 경우가 있다. 책에서 말하는 것처럼 사용자 경험은 기능이 동작하는 순간부터 시작되는 것이 아니라 사용자가 기능을 발견하는 단계부터 이미 시작되고 있다는 생각이 들었다.

3장의 에러와 경고에 대한 내용도 실무 경험과 직접적으로 연결됐다. 개발할 때는 에러 메시지를 디버깅을 위한 정보로 생각하기 쉽다. 스택 트레이스나 예외 이름이 개발자에게는 유용하지만 일반 사용자에게는 해결 방법을 알려주지 못한다.

예를 들어 데이터 분석 프로그램에서 단순히 KeyError가 발생했다고 출력하는 것과 “입력 파일에 required_date 컬럼이 없습니다. 샘플 파일의 컬럼 구성을 확인하세요”라고 안내하는 것은 전혀 다른 경험이다. API에서도 단순히 400 응답을 반환하는 것보다 어떤 파라미터가 잘못됐고 어떤 형식으로 수정해야 하는지를 알려주는 것이 훨씬 유용하다. 책에서 강조하는 진단 시나리오와 조기 진단의 개념을 보면서 에러 처리는 단순한 예외 처리가 아니라 제품 설계의 일부라는 점을 다시 생각하게 됐다.

4장의 도그푸딩과 문서 주도 개발도 프로그램과 시스템을 개발하면서 중요하다고 느꼈던 부분이다. 자신이 만든 프로그램을 직접 처음부터 설치하고 사용해 보면 개발할 때는 보이지 않던 문제가 발견된다. 환경 설정이 지나치게 복잡하거나, 파일을 특정 위치에 두어야 하거나, 실행 순서를 알아야만 사용할 수 있는 경우가 있다.

개발자는 이미 시스템을 알고 있기 때문에 이런 마찰을 쉽게 지나친다. 책에서 제안하는 마찰 로그는 이런 문제를 기록하는 단순하지만 현실적인 방법이다. 직접 사용하면서 막힌 지점이나 불필요하게 생각해야 했던 지점을 기록하는 것만으로도 개선할 부분을 찾을 수 있다. 문서 주도 개발 역시 비슷하다. 코드를 먼저 만들고 사용법을 설명하는 것이 아니라 사용자가 어떻게 사용할지를 먼저 문서로 작성하면 인터페이스 자체의 문제를 더 일찍 발견할 수 있다.

5장에서 다루는 지속적인 사용자 이해와 피드백 루프 역시 데이터 분석 시스템을 운영할 때 중요하다. 처음에 정의한 요구 사항이 시간이 지나도 그대로 유지되는 경우는 많지 않다. 업무 방식이 바뀌거나 데이터가 추가되고 사용자가 중요하게 보는 지표도 달라진다.

특히 대시보드나 분석 시스템에서는 개발자가 중요하다고 생각한 지표와 실제 사용자가 반복해서 확인하는 지표가 다를 수 있다. 이때 사용자의 피드백뿐 아니라 실제 사용 패턴과 제품 지표를 함께 보는 것이 중요하다는 책의 설명에 공감했다. 분석 시스템 역시 한번 만들어 전달하는 결과물이 아니라 계속 수정되고 학습해야 하는 제품으로 바라볼 필요가 있다.

6장의 타깃 오디언스와 페르소나는 내부 시스템을 개발할 때도 적용할 수 있다는 점이 흥미로웠다. 내부 업무 프로그램은 사용자가 명확하기 때문에 별도의 사용자 분석이 필요하지 않다고 생각하기 쉽다. 하지만 같은 시스템을 사용하더라도 실무 담당자, 관리자, 데이터 분석가, 개발자가 필요로 하는 기능은 서로 다르다.

예를 들어 실무자는 빠르게 데이터를 입력하고 결과를 확인하고 싶어 할 수 있고, 관리자는 전체 현황과 예외 상황을 보고 싶어 할 수 있다. 데이터 분석가는 원본 데이터에 접근하고 싶어 할 수 있다. 책에서 이야기하는 다중 페르소나 제품의 문제를 실제 내부 시스템에서도 자주 볼 수 있다는 생각이 들었다.

7장의 북극성 시나리오와 요구 사항 우선순위에 대한 내용도 인상적이었다. 프로그램을 만들다 보면 구현 가능한 기능이 계속 늘어나고, 특히 AI를 활용하면 새로운 기능을 추가하는 비용도 많이 낮아진다. 그래서 무엇을 추가할 수 있는지가 아니라 무엇을 먼저 만들어야 하는지가 더 중요해졌다.

책에서는 제품의 이상적인 사용 모습을 북극성 시나리오로 정의하고 이를 사용자 흐름과 JTBD, 구체적인 요구 사항으로 연결한다. 이런 방법은 데이터 분석 프로젝트에서도 유용하다고 생각했다. 처음부터 가능한 분석을 모두 하는 것이 아니라 최종적으로 사용자가 어떤 결정을 더 잘 내리게 만들 것인지를 정의하면 우선순위가 훨씬 명확해진다.

8장의 인터랙션 설계에서는 올바른 사용을 유도하고 잘못된 사용을 방지하는 부분이 특히 기억에 남았다. 시스템에서 자유도를 높이는 것이 항상 좋은 것은 아니다. 사용자가 잘못된 데이터를 입력하거나 복구하기 어려운 작업을 실행할 수 있다면 제한을 두는 것이 오히려 좋은 경험이 될 수 있다.

데이터 처리 시스템에서도 날짜 범위를 잘못 입력하거나 필수 컬럼을 누락하거나 너무 큰 데이터를 한 번에 실행하는 등의 문제가 발생한다. 이런 상황을 사용자의 실수로만 볼 것이 아니라 애초에 잘못된 사용을 어렵게 만드는 인터페이스를 설계해야 한다는 관점이 중요하게 느껴졌다.

마지막으로 9장의 프로덕트 아키텍처는 내가 기존에 생각하던 시스템 아키텍처의 관점을 조금 확장시켜 주었다. 성능, 안정성, 확장성 같은 비기능 요구 사항은 보통 기술적인 품질로만 생각했다. 하지만 책에서는 이를 사용자 경험과 연결한다.

응답 속도가 느리다는 것은 단순히 성능 수치가 낮다는 의미가 아니라 사용자의 작업 흐름이 끊긴다는 의미다. 시스템이 불안정하다는 것은 장애율의 문제가 아니라 사용자가 결과를 신뢰할 수 없다는 문제다. API가 자주 변경되는 것도 개발 관점에서는 버전 관리의 문제지만 사용자 입장에서는 기존 프로그램을 계속 수정해야 하는 비용이 된다. 결국 기술적인 아키텍처 역시 제품 경험과 분리할 수 없다는 점이 인상적이었다.

이 책을 읽고 나니 데이터 분석이나 시스템 개발에서도 프로덕트 사고는 별도의 직무에서만 필요한 능력이 아니라는 생각이 들었다. 분석을 시작하기 전에 사용자 시나리오를 생각하고, 에러 메시지를 작성할 때 다음 행동을 안내하고, 직접 만든 프로그램을 사용하면서 마찰을 기록하고, 피드백을 통해 계속 개선하는 모든 과정이 프로덕트 사고에 해당한다.

AI가 코드를 빠르게 만들어주는 지금은 이런 관점이 더 중요해진 것 같다. 구현해야 할 기능을 설명하면 AI가 상당 부분을 대신 만들어줄 수 있지만 어떤 문제를 해결해야 하는지, 누구에게 필요한 기능인지, 어떤 기능을 먼저 만들어야 하는지는 여전히 사람이 판단해야 한다.

나에게 이 책은 단순히 좋은 제품을 만드는 방법을 설명하는 책이라기보다 지금까지 해온 데이터 분석과 프로그램, 시스템 개발 경험을 다시 바라보게 만든 책이었다.

한빛미디어 서평단 ＜나는리뷰어다＞ 활동을 위해서 책을 협찬 받아 작성된 서평입니다.

들어가며

  요즘 들어 AI를 활용하고자 한다면 그보다 한 발 앞서 다루고자 하는 것에 대한 감수성을 마련해 둬야 한다는 생각을 한다.

  내가 무엇을 원하고, 이를 어떻게 활용할 것이며, 어떤 결과를 얻었으면 하는지, 그리고 그렇게 생각한 계기는 무엇인지 등 목적에 대한 맥락이 명확할 때에만 AI로 효과적인 결과를 얻는다고 생각한다. 그렇지 않다면 흔한 AI 슬롭이 될 뿐이고 말이다.

  이런 관점에서 목적에 대한 맥락을 설정하기 이전에 다루고자 하는 대상에 대한 이해와 나의 관점이 필요하다고 생각했다. 이 때문에 문제 접근 방식, 문제 해결 전략 등 사고법에 관심을 갖게 됐다.

  이런 배경 아래 나는 기획자라도 AI를 통해 결과물을 내기 위해서는 엔지니어링에 대한 보다 깊은 감수성이 필요하다고 생각했고, 기술적인 영역보다 프로덕트 관점에서 개발자의 사고 방식을 다루는 이 책을 한 번 읽어보고 싶었기에 'AI 시대의 엔지니어링 전략' 책을 리뷰하게 됐다.

리뷰

  결론부터 말하면 이 책은 넓은 맥락 아래 주도적으로 개발하고자 하는 사람에게 적합한 책이다.

  AI와 엔지니어링이라는 키워드가 담긴 제목에 무언가 AI를 활용해 개발에 도움이 되는 전략을 다룰 것으로 착각하기 쉽지만 이 책은 그런 내용을 다루지 않는다.

  그보다는 프로덕트의 목적은 무엇인가, 이 프로덕트가 사용자에게 어떻게 다가갈 것인가, 사용자에 대한 프로덕트의 효과성을 어떻게 검증할 것인가 등 개발자 관점에서 프로덕트에 대한 맥락을 인지하고 사고하는 방식을 다룬다.

  사실 기획자 입장에서 기획 영역에 포함되는 좋은 내용이 많았기에 반쯤은 기획자 향이 첨가된 개발 서적이라고 봐도 좋다고 생각한다.

  우스갯소리로 개발자가 어려워하는 네이밍 규칙에 대한 일관성과 구체성 트레이드 오프부터 설계자가 간과하기 쉬운 사용자 관점, 사용자 임팩트와 같은 추상적인 경험에 대한 효용 함수와 같이 재미있는 내용이 많이 있다.

  그렇다고 난이도가 높은 것도 아니다. 전문적인 용어를 쓰기는 하지만 이는 사람들이 한 번씩 해 본 이름 없는 것들에 이름을 붙인 것으로 개발 지식이 많지 않아도 내용을 이해하며 볼 수 있다.

  일례로 마찰 로그와 같은 있어 보이는 용어도 알고 보면 테스트하면서 그때 그때 불편했던 부분들, 프로덕트를 계속 사용하는 데 저항이 되는 부분들을 기록하는 것으로 일상 속의 행동을 용어로 정의했을 뿐이라는 걸 알 수 있다.

  아무튼 결과적으로 개발과 기획, PM 누구든 맥락에 초점을 맞춰 프로덕트를 개발하고자 할 때 한 번쯤 읽어보기 좋은 책이라고 생각한다.

  비단 회사 환경상 주도적으로 일하기 어려운 사람이라고 하더라도 AI로 인해 1인 개발이 쉬워졌기에 사이드 프로젝트를 할 때도 충분히 도움이 되리라고 생각한다.

  개발을 위한 개발이 아닌 프로덕트를 위한 개발에 관심을 갖게 된 당신에게 이 책을 추천한다.

  인상 깊었던 부분은 프로토타이핑 부분이었는데, 책에서는 페이스북의 "코드가 논쟁을 이긴다"라는 말을 인용하며 백마디 말보다 한 번 보여주는 게 훨씬 설득력이 있다는 말을 한다.

  개인적으로 AI로 인해 누구나 프로토타입을 만들기 쉬워졌기에 앞으로 이런 설득 방식의 주류의 설득 방식이 될 거라고 생각했다. 나도 지금하고 있는 것들에 만족하지 말고 적극적으로 AI를 도입해 보려고 한다.. 리뷰 끝!

 

제목과 내용이 200프로 일치한다고 볼 수는 없지만 

AI 시대에 필요한 엔지니어링 전략을 저역자 관점에서 설명하고 있어 한번쯤 읽어보기 좋은 도서라고 생각한다.

프로덕트 매니저를 지낸 역자의 경험이 책에 더 담겼으면 좋았겠지만 마이크로소프트 메타에서 경험했다던 저자의 인상트도 충분했다

"한빛미디어 서평단 ＜나는리뷰어다＞ 활동을 위해서 책을 협찬받아 작성된 서평입니다."

요즘은 AI한테 딸깍딸깍 몇 마디만 하면 코드가 뚝딱 나오는 시대입니다.

저도 AI 엔지니어로 취업을 준비하면서 AI의 도움을 받아 코드를 짜다 보니, 문득 이런 생각이 들 때가 있습니다.

"그럼 엔지니어는 이제 뭘 해야 하지? 코드 짜는 손은 이제 AI가 대신해주는데, 나는 뭘로 경쟁력을 만들어야 하지?" AI가 구현은 다 해준다면, 개발자에게 남는 진짜 일은 뭘까 라는 궁금증에서

[AI 시대의 엔지니어링 전략]을 읽게 됐습니다.

＜시나리오 하나로 시작된 이야기＞

책은 첫 장부터 아주 인상 깊은 이야기로 시작합니다. 똑같은 기능을 만드는데, 시나리오 없이 개발했을 때와, 시나리오를 쓰고 개발했을 때를 나란히 비교해서 보여주는 부분이었습니다.

실제 시나리오 없이 개발할 때는 결국 제 마음대로 "이렇겠지, 저렇겠지" 하고 제 기준으로 판단해서 만들게 됩니다. 부트캠프에서 프로젝트를 진행할 때 만드는 데 급급해서 시나리오를 만들지 않고 진행한 적이 있었습니다. 저희 팀은 계획을 세워 이때까지 해야겠다고 생각하고, 개발자인 제 머릿속에만 있는 그림으로 기능을 만들었는데 다른 조원들에게 받은 피드백이 안 좋았습니다.

그런데 시나리오를 먼저 써놓고 가상의 고객을 설정해서 개발을 하면, 자연스럽게 고객의 시선에 초점을 맞추게 되고, 그 결과 고객에게 훨씬 더 좋은 경험을 줄 수 있다는 걸 알았습니다.

저희 조도 그 당시 안 좋은 피드백을 받고 고객의 관점에서 프로젝트를 다시 바라보는 시간을 갖게 됐고, 계획을 세워 프로젝트를 전면 수정한 뒤 시나리오를 설정해서 진행했더니 우수상을 받게 됐습니다.

(사실 그때는 이런게 시나리오인지 몰랐지만 지금 와서 보니 저희 조가 시나리오를 세운거였습니다 이래서 배워야하나 봅니다 ^^;)

책은 이 시나리오가 단순한 아이디어 메모가 아니라, 사용자 인터뷰를 담아내고, 제품의 빈틈을 드러내고, 심지어 테스트 역할까지 한다고 설명하고 있습니다.

그리고 마지막엔 이 시나리오에서 "핵심 해답"을 뽑아내는 법까지 차근차근 짚어줍니다. 시나리오를 쓸 때 핵심은 딱 하나, 고객의 입장에서 생각하기였습니다.

＜ 하나의 원칙이 책 전체를 관통합니다 ＞

책을 계속 읽으면서 놀란 건 이 '고객(사용자) 중심으로 생각하기'라는 원칙이 1장에서 끝나지 않았다는 점입니다.

예를 들어 '전달' 파트에서는 내가 만든 제품을 개발자 스스로 먼저 써보는 '도그푸딩'이 나옵니다.

도그푸딩이란 팀원이 자기 제품을 직접 쓰는 걸 말하는데요, 제품 출시 전 베타테스터를 구하기 어렵기 때문에 도그푸딩으로 검증을 하는 겁니다.

저도 지금 개인 프로젝트를 하고 있는게 가장 어려운 것중 하나가 피드백 받는 겁니다.

부트캠프를 다녔을때나, 인턴십 할때는 주변 동료에게 피드백을 받을 수 있었는데, 개인프로젝트를 진행하다보니 피드백을 받을 수가 없는 게 너무 아쉽더라구요

책에서는 이렇게 말합니다.

"제품 설계와 개발 전 과정에서, 여러분의 제품을 직접 쓰고 제품에 압박을 가할 방법을 끊임없이 찾으세요. 그래야 제품이 실제 사용 환경을 견뎌낼 수 있고, 마찰 로그는 동료에게서 실행 가능하고 솔직한 경험 피드백을 얻어내는 훌륭한 방법입니다."

베타테스터를 구하기 어렵다면 도그푸딩을 통해 테스트를 하고, 마찰 로그로 동료들에게서 솔직한 피드백을 받아 개선해야 한다고 말하고 있습니다.

그다음 '발견' 파트에서는 '페르소나'라는 도구로 이어집니다.

"소프트웨어 팀은 자신들이 목표로 삼는 페르소나 리스트를 갖추고 있어야 합니다. 그 페르소나는 사용자의 배경과 동기에 관한 디테일을 담고, 그들이 커뮤니티에 가져다주는 가치를 드러내야 하는데, 이러한 페르소나는 초기에 누구와 대화할지 정할 때, 또 나중에 여러 제품·아이디어를 검증할 때 결정적입니다."

그리고 신기하게도, 가장 딱딱하고 기술적일 것 같은 마지막 장, '프로덕트 아키텍처'에서도 똑같은 원칙이 다시 등장합니다. 이 장에서는 사용자 중심 사고를 바탕으로 한 시스템 설계를 프로덕트 아키텍처 영역에 통합한 뒤, 프로덕트 아키텍처 역량을 쥐면 더 전략적이고 자신 있는 선택을 하게 되고, 사용자는 더 편하고 집중해서 서비스를 사용할 수 있게 된다고 말합니다.

시나리오를 쓰는 법(1장)에서 시작해서, 사용자를 안내하는 법, 제품을 직접 써보는 법, 진짜 타깃을 찾는 법, 그리고 가장 기술적인 시스템 아키텍처 설계까지 — 이 책은 처음부터 끝까지 "사용자 시선으로 생각하기"라는 딱 하나의 원칙을 서로 다른 각도에서 반복해서 보여주는 책이었습니다. 챕터마다 새로운 개념이 나오는 것 같지만, 결국 하나의 원칙 "고객의 입장에서 생각하라"로 이어지고 있어서 좋았습니다.

이런 분께 추천합니다

무작정 코드부터 짜고 나서 "어, 이게 아닌데" 하고 다시 갈아엎어 본 경험이 있는 개발자라면, 이 책이 그 이유를 정확히 짚어줄 거예요. 저처럼 부트캠프나 팀 프로젝트에서 혼자만의 기준으로 기능을 만들었다가 팀원들에게 안 좋은 피드백을 받아본 분이라면 특히 공감하며 읽으실 수 있습니다.

또 AI 시대에 개발자로 첫 커리어를 시작하려는 취업 준비생분들께도 추천하고 싶습니다. AI가 구현을 대신해줄수록, "무엇을 왜 만들어야 하는가"를 판단하는 능력이 오히려 더 중요해지는데, 이 책은 그 판단력을 시나리오, 페르소나, 도그푸딩 같은 구체적인 방법으로 훈련시켜 주기 때문이에요.

한빛미디어 소개에 따르면 이 책은 원래 초·중급 개발자 및 소프트웨어 엔지니어를 대상으로 쓰였다고 하는데, 실제로 읽어보니 코딩 실력보다 "생각하는 방식"에 초점이 맞춰져 있어서, PM이나 기획자 없이 개발자가 기획까지 함께 고민해야 하는 소규모 팀이나 스타트업에서 일하는 분들께도 잘 맞을 것 같습니다.

#ai엔지니어링 #aiengineer #ai시대의엔지니어링전략 #한빛미디어

"한빛미디어 서평단 ＜나는리뷰어다＞ 활동을 위해서 책을 협찬받아 작성된 서평입니다."

📌 이 책을 한 문장으로

"엔지니어링은 단순히 코드를 구현하는 일이 아니라, 사용자의 문제를 발견하고 제품의 성공까지 연결하는 과정이라는 것을 알려주는 책."

『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 시대의 엔지니어링 전략』은 꽤 괜찮은 길잡이가 되어줄 책이라고 생각한다.

한빛미디어 서평단 ＜나는 리뷰어다＞ 활동을 위해서 책을 협찬받아 작성된 서평입니다

AI가 스스로 코드를 찍어내는 시대에 과연 개발자의 가치는 어디로 향해야 하는가라는 질문은, 최근 기술 생태계를 관통하는 가장 무겁고도 본질적인 화두입니다. 저는 이번 책을 단순히 인공지능 도구를 다루는 기술 지침서가 아니라, 기계가 구현을 가속할수록 더욱 빛을 발해야 하는 인간 엔지니어의 존재 이유와 사고방식을 다시 정의하는 사색적인 길잡이로 해석했습니다.

코드를 넘어 질문으로 향하는 엔지니어: 『AI 시대의 엔지니어링 전략』을 읽고

인공지능이 복잡한 알고리즘을 순식간에 작성하고 버그를 찾아내는 광경을 보며, 수많은 개발자들이 형언하기 어려운 위기감을 토로합니다. 어제까지 갈고닦던 코드 구현 기술이 하룻밤 사이에 대체 가능한 노동으로 전락하는 듯한 불안감 때문일 것입니다. 하지만 기술의 진보가 구현의 비용을 제로에 가깝게 낮출수록, 역설적으로 '무엇을 왜 만들어야 하는가'를 묻는 판단의 가치는 천문학적으로 치솟게 됩니다. 바로 이 지점에서 소프트웨어 공학의 무게중심은 단순한 제작(How)에서 목적과 맥락(Why)으로 이동합니다.

마이크로소프트와 메타, 스트라이프에서 굵직한 시스템을 설계해 온 드류 호스킨스의 『AI 시대의 엔지니어링 전략』은 이러한 패러다임 전환의 한복판을 정확하게 짚어냅니다. 저자는 책의 표제에 'AI'를 내걸었지만, 정작 페이지를 넘기다 보면 기계와의 경쟁을 부추기거나 새로운 AI 프레임워크를 나열하지 않습니다. 대신 AI가 당연한 일상으로 자리 잡은 배경 속에서, 엔지니어가 단순히 주어진 요구 사항을 코드로 번역하는 직무를 넘어 제품 전체의 성공을 조망하는 프로덕트 사고를 어떻게 내재화해야 하는지 집요하게 파고듭니다.

우리가 흔히 범하는 오류 중 하나는 소비자용 인터페이스만을 '제품'이라 여기고, 백엔드 API나 사내 인프라는 단순한 공학적 파이프라인으로 치부하는 태도입니다. 저자는 이러한 편견을 정면으로 허물며, 콘솔 창에 찍히는 에러 메시지 하나부터 내부 플랫폼 도구에 이르기까지 세상의 모든 소프트웨어에는 반드시 그것을 마주하는 '사용자'가 존재한다고 역설합니다. 에러 메시지를 기술적 예외 처리의 부산물이 아니라 사용자와 제품이 대화하는 핵심 접점으로 바라보고, 개발자가 직접 자신이 만든 도구를 사용하며 마찰을 기록하는 과정은 엔지니어링의 본질이 결국 인간에 대한 깊은 공감에 닿아 있음을 명쾌하게 일깨워 줍니다.

더블 다이아몬드 모델을 축으로 삼아 개발과 전달, 발견과 정의로 뻗어나가는 이 책의 전개는 엔지니어의 시야를 코드 편집기 바깥으로 시원하게 확장합니다. 페르소나와 시나리오를 통해 시스템의 공백을 찾아내고, 지표와 피드백을 통해 기술적 의사결정을 제품의 비즈니스 임팩트로 연결 짓는 통찰은 실로 현장의 깊은 연륜에서만 길어 올릴 수 있는 지혜입니다. 특정 언어나 프레임워크의 수명이 갈수록 짧아지는 이 격변기에도, 사용자의 고통을 해석하고 가치 있는 아키텍처를 세우는 원칙만큼은 결코 낡지 않는 무기가 될 것입니다.

AI가 마법처럼 코드를 쏟아내는 세상에서 우리는 마침내 기계적인 타이핑의 굴레를 벗어던질 기회를 얻었습니다. 그렇다면 비워진 그 자리에 우리는 어떤 생각을 채워 넣어야 할까요. 당신은 오늘도 화면 속 코드를 어떻게 작성할지 고민하는 구현자에 머물고 계십니까, 아니면 이 기능이 세상에 왜 존재해야 하는지 묻는 진정한 설계자로 나아가고 계십니까.

"한빛미디어 서평단 ＜나는 리뷰어다＞ 활동을 위해서 책을 협찬받아 작성된 서평입니다."

알만한 원작, 감독, 배우들의 영화가 개봉한다는 소식을 접하면 예고편에 현혹되지 않기 위해 사전 정보 없이 극장에 가는 방법을 쓰곤 한다. 재미있는 영화는 보는 재미가 배가 되고, 재미가 없더라도 적어도 속은 기분은 들지 않기 때문이다. ＜AI 시대의 엔지니어링 전략＞을 읽고 나서 책에도 동일한 공식을 적용해야 해야 하나 하는 생각이 들었다. 책에서는 영화의 예고편 같은 것이 책소개와 목차 같은 도서정보인데 저자마저 생소한 책이라면 서점 가서 맛보기를 하지 않는 이상 리스크가 너무 클 것 같긴 하다. 그럼에도 불구하고 불현듯 이런 생각이 들었던 것은 마치 예고편에 현혹된 독자가 된 기분이 들어서였다.

처음 책 제목을 접했을 때 “엔지니어링”이라는 단어가 주는 편견 때문에 나의 전문 분야인 경험 디자인과 관련성이 적으려나 생각했는데 책 소개에 “좋은 개발자는 How를 고민하고, 뛰어난 개발자는 Why를 먼저 묻는다”라는 문구를 보고 살짝 호기심이 들어 목차를 쭉 살펴보니 기존에 흔히 보던 코드 엔지니어링 전략이 아닌 엔지니어도 이제는 유저의 페인포인트를 고민하고 왜 만들어야 하는지부터 고민해야 한다는 것이 책의 핵심 주제였다. 왜? AI 시대에는 AI가 코드를 생성하는 시대이니 지금까지 해왔던 방식대로 요구사항에 충실한 개발을 하는 것은 엔지니어로서의 생명력을 단축하는 길이 될 수 있고, 장기적으로 경쟁력 있는 엔지니어가 되기 위해서는 Why, What, How를 사용자의 관점에서 생각하고 프로덕트를 만들어야 한다는 것이다. 책의 초반부는 조금 달라진 시각이 보이는 듯하였으나 중반부로 접어들면서 삼천포로 빠지는 기분이 들다가 후반부로 향해 갈수록 한글이 외계어로 느껴졌다. 원서로 읽었다면 저자의 의도를 좀 더 잘 이해할 수 있었으려나? 의도적으로 직역을 한 것인지는 모르겠으나 번역한 문장이 전달하는 의미와 문장과 문장, 단락과 단락의 연결성도 난해하여 마치 직역한 고전 문학을 읽는 것 같은 느낌이 들었다.

기존개발자의관점에서코드엔지니어링이라고생각하고책을선택한다면많이무관할것이고, 사용자관점에서사고하는엔지니어링전략을기대하고책을선택했다고하더라도미로를헤매는느낌이들것같긴하다. 기획의도는좋으나전달의도는많이아쉽다.