<div id="readability-page-1" class="page"><div>
 이 리뷰는 한빛미디어의 나는리뷰어다 활동으로 책을 무상으로 제공받아 작성하였습니다.

<img src="https://i.imgur.com/9uW6CRb.png" width="400">

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 </div></div>

Tabula rasa

이 리뷰는 한빛미디어의 나는리뷰어다 활동으로 책을 무상으로 제공받아 작성하였습니다.
이 책을 읽으면서 가장 인상적이었던 점은 개발 과정의 익숙한 활동들을 모두 프로덕트 사고의 관점에서 다시 해석한다는 점이었다. 사용자 시나리오, 에러 메시지, 테스트, 도그푸딩, 피드백, 인터랙션, 아키텍처처럼 각각 따로 생각하기 쉬운 요소들을 결국 하나의 질문으로 연결한다. “이 소프트웨어를 사용하는 사람은 누구이며, 그 사람에게 실제로 어떤 경험을 제공하고 있는가”라는 질문이다.
1장에서 다루는 사용자 시나리오는 데이터 분석 경험과 특히 잘 연결됐다. 데이터 분석을 시작할 때는 보통 데이터 자체에 먼저 관심이 간다. 어떤 컬럼이 있는지, 결측치는 얼마나 되는지, 어떤 모델이나 시각화를 적용할 수 있는지를 살펴보게 된다. 하지만 실제 프로젝트에서는 분석 기법보다 먼저 확인해야 할 것이 있다. 누가 이 분석 결과를 보는지, 어떤 판단을 하기 위해 사용하는지, 결과를 본 뒤 어떤 행동을 해야 하는지다.
책에서는 시나리오가 단순한 설명문이 아니라 제품의 공백과 마찰을 찾고, 구현하려는 기능을 검증하고, 나아가 테스트의 역할까지 할 수 있다고 설명한다. 이 부분이 인상적이었다. 데이터 분석에서도 “관리자가 재고 부족 가능성이 높은 품목을 확인하고 발주 여부를 결정한다”처럼 구체적인 시나리오를 먼저 정의하면 필요한 지표와 화면 구성이 훨씬 명확해진다. 반대로 시나리오 없이 분석을 시작하면 그래프와 지표는 많지만 실제로 무엇을 판단해야 하는지 알기 어려운 결과물이 만들어지기도 한다.
2장에서 설명하는 발견, 이해, 사용의 사용자 여정도 프로그램 개발 경험과 연결해서 생각할 수 있었다. 개발자는 기능이 존재하면 사용자가 자연스럽게 찾아서 사용할 것이라고 생각하기 쉽다. 하지만 실제로는 기능을 발견할 수 있는지, 기능의 의미를 이해할 수 있는지, 실제 작업에 사용할 수 있는지가 각각 다른 문제다.
내가 만든 프로그램이나 데이터 분석 도구를 다른 사람이 사용할 때도 이런 차이를 자주 볼 수 있었다. 기능은 정상적으로 구현되어 있지만 어디에서 실행해야 하는지 찾기 어렵거나, 버튼의 이름만으로 기능을 이해하기 어렵거나, 입력 데이터 형식을 몰라 실행하지 못하는 경우가 있다. 책에서 말하는 것처럼 사용자 경험은 기능이 동작하는 순간부터 시작되는 것이 아니라 사용자가 기능을 발견하는 단계부터 이미 시작되고 있다는 생각이 들었다.
3장의 에러와 경고에 대한 내용도 실무 경험과 직접적으로 연결됐다. 개발할 때는 에러 메시지를 디버깅을 위한 정보로 생각하기 쉽다. 스택 트레이스나 예외 이름이 개발자에게는 유용하지만 일반 사용자에게는 해결 방법을 알려주지 못한다.
예를 들어 데이터 분석 프로그램에서 단순히 KeyError가 발생했다고 출력하는 것과 “입력 파일에 required_date 컬럼이 없습니다. 샘플 파일의 컬럼 구성을 확인하세요”라고 안내하는 것은 전혀 다른 경험이다. API에서도 단순히 400 응답을 반환하는 것보다 어떤 파라미터가 잘못됐고 어떤 형식으로 수정해야 하는지를 알려주는 것이 훨씬 유용하다. 책에서 강조하는 진단 시나리오와 조기 진단의 개념을 보면서 에러 처리는 단순한 예외 처리가 아니라 제품 설계의 일부라는 점을 다시 생각하게 됐다.
4장의 도그푸딩과 문서 주도 개발도 프로그램과 시스템을 개발하면서 중요하다고 느꼈던 부분이다. 자신이 만든 프로그램을 직접 처음부터 설치하고 사용해 보면 개발할 때는 보이지 않던 문제가 발견된다. 환경 설정이 지나치게 복잡하거나, 파일을 특정 위치에 두어야 하거나, 실행 순서를 알아야만 사용할 수 있는 경우가 있다.
개발자는 이미 시스템을 알고 있기 때문에 이런 마찰을 쉽게 지나친다. 책에서 제안하는 마찰 로그는 이런 문제를 기록하는 단순하지만 현실적인 방법이다. 직접 사용하면서 막힌 지점이나 불필요하게 생각해야 했던 지점을 기록하는 것만으로도 개선할 부분을 찾을 수 있다. 문서 주도 개발 역시 비슷하다. 코드를 먼저 만들고 사용법을 설명하는 것이 아니라 사용자가 어떻게 사용할지를 먼저 문서로 작성하면 인터페이스 자체의 문제를 더 일찍 발견할 수 있다.
5장에서 다루는 지속적인 사용자 이해와 피드백 루프 역시 데이터 분석 시스템을 운영할 때 중요하다. 처음에 정의한 요구 사항이 시간이 지나도 그대로 유지되는 경우는 많지 않다. 업무 방식이 바뀌거나 데이터가 추가되고 사용자가 중요하게 보는 지표도 달라진다.
특히 대시보드나 분석 시스템에서는 개발자가 중요하다고 생각한 지표와 실제 사용자가 반복해서 확인하는 지표가 다를 수 있다. 이때 사용자의 피드백뿐 아니라 실제 사용 패턴과 제품 지표를 함께 보는 것이 중요하다는 책의 설명에 공감했다. 분석 시스템 역시 한번 만들어 전달하는 결과물이 아니라 계속 수정되고 학습해야 하는 제품으로 바라볼 필요가 있다.
6장의 타깃 오디언스와 페르소나는 내부 시스템을 개발할 때도 적용할 수 있다는 점이 흥미로웠다. 내부 업무 프로그램은 사용자가 명확하기 때문에 별도의 사용자 분석이 필요하지 않다고 생각하기 쉽다. 하지만 같은 시스템을 사용하더라도 실무 담당자, 관리자, 데이터 분석가, 개발자가 필요로 하는 기능은 서로 다르다.
예를 들어 실무자는 빠르게 데이터를 입력하고 결과를 확인하고 싶어 할 수 있고, 관리자는 전체 현황과 예외 상황을 보고 싶어 할 수 있다. 데이터 분석가는 원본 데이터에 접근하고 싶어 할 수 있다. 책에서 이야기하는 다중 페르소나 제품의 문제를 실제 내부 시스템에서도 자주 볼 수 있다는 생각이 들었다.
7장의 북극성 시나리오와 요구 사항 우선순위에 대한 내용도 인상적이었다. 프로그램을 만들다 보면 구현 가능한 기능이 계속 늘어나고, 특히 AI를 활용하면 새로운 기능을 추가하는 비용도 많이 낮아진다. 그래서 무엇을 추가할 수 있는지가 아니라 무엇을 먼저 만들어야 하는지가 더 중요해졌다.
책에서는 제품의 이상적인 사용 모습을 북극성 시나리오로 정의하고 이를 사용자 흐름과 JTBD, 구체적인 요구 사항으로 연결한다. 이런 방법은 데이터 분석 프로젝트에서도 유용하다고 생각했다. 처음부터 가능한 분석을 모두 하는 것이 아니라 최종적으로 사용자가 어떤 결정을 더 잘 내리게 만들 것인지를 정의하면 우선순위가 훨씬 명확해진다.
8장의 인터랙션 설계에서는 올바른 사용을 유도하고 잘못된 사용을 방지하는 부분이 특히 기억에 남았다. 시스템에서 자유도를 높이는 것이 항상 좋은 것은 아니다. 사용자가 잘못된 데이터를 입력하거나 복구하기 어려운 작업을 실행할 수 있다면 제한을 두는 것이 오히려 좋은 경험이 될 수 있다.
데이터 처리 시스템에서도 날짜 범위를 잘못 입력하거나 필수 컬럼을 누락하거나 너무 큰 데이터를 한 번에 실행하는 등의 문제가 발생한다. 이런 상황을 사용자의 실수로만 볼 것이 아니라 애초에 잘못된 사용을 어렵게 만드는 인터페이스를 설계해야 한다는 관점이 중요하게 느껴졌다.
마지막으로 9장의 프로덕트 아키텍처는 내가 기존에 생각하던 시스템 아키텍처의 관점을 조금 확장시켜 주었다. 성능, 안정성, 확장성 같은 비기능 요구 사항은 보통 기술적인 품질로만 생각했다. 하지만 책에서는 이를 사용자 경험과 연결한다.
응답 속도가 느리다는 것은 단순히 성능 수치가 낮다는 의미가 아니라 사용자의 작업 흐름이 끊긴다는 의미다. 시스템이 불안정하다는 것은 장애율의 문제가 아니라 사용자가 결과를 신뢰할 수 없다는 문제다. API가 자주 변경되는 것도 개발 관점에서는 버전 관리의 문제지만 사용자 입장에서는 기존 프로그램을 계속 수정해야 하는 비용이 된다. 결국 기술적인 아키텍처 역시 제품 경험과 분리할 수 없다는 점이 인상적이었다.
이 책을 읽고 나니 데이터 분석이나 시스템 개발에서도 프로덕트 사고는 별도의 직무에서만 필요한 능력이 아니라는 생각이 들었다. 분석을 시작하기 전에 사용자 시나리오를 생각하고, 에러 메시지를 작성할 때 다음 행동을 안내하고, 직접 만든 프로그램을 사용하면서 마찰을 기록하고, 피드백을 통해 계속 개선하는 모든 과정이 프로덕트 사고에 해당한다.
AI가 코드를 빠르게 만들어주는 지금은 이런 관점이 더 중요해진 것 같다. 구현해야 할 기능을 설명하면 AI가 상당 부분을 대신 만들어줄 수 있지만 어떤 문제를 해결해야 하는지, 누구에게 필요한 기능인지, 어떤 기능을 먼저 만들어야 하는지는 여전히 사람이 판단해야 한다.
나에게 이 책은 단순히 좋은 제품을 만드는 방법을 설명하는 책이라기보다 지금까지 해온 데이터 분석과 프로그램, 시스템 개발 경험을 다시 바라보게 만든 책이었다.

[도서 리뷰] AI 시대의 엔지니어링 전략

댓글