AI가 코드를 쓰는 시대, 엔지니어는 무엇을 설계해야 하는가
『AI 시대의 엔지니어링 전략』 리뷰
- 도서명: AI 시대의 엔지니어링 전략
- 부제: 코드를 넘어 제품의 성공까지 설계하는 개발자의 사고법
- 원제: The Product-Minded Engineer
- 저자: 드루 호스킨스
- 역자: 조쉬(김승권)
- 출판사: 한빛미디어
AI 코딩 도구를 사용하면 예전에는 며칠이 필요했던 프로토타입도 몇 시간 안에 만들 수 있다. 자연어로 요구 사항을 입력하면 화면과 API, 데이터 구조까지 어느 정도 형태를 갖춘 결과물이 나온다. 개발자에게 오랫동안 중요한 경쟁력이었던 ‘코드를 작성하는 능력’의 희소성이 이전보다 빠르게 줄어들고 있다는 의미이기도 하다.
하지만 구현 속도가 빨라졌다고 해서 무엇을 만들어야 하는지가 저절로 명확해지는 것은 아니다. 오히려 잘못 정의한 제품을 더 빠르게 만들어버릴 가능성이 커졌다. 사용자가 누구인지, 어떤 상황에서 제품을 사용하는지, 무엇을 이루려고 하는지 충분히 생각하지 않은 채 AI가 만들어준 코드만 쌓는다면 기술적으로는 동작하지만 아무도 원하지 않는 제품이 탄생할 수 있다.
『AI 시대의 엔지니어링 전략』은 바로 이 지점을 다룬다. 제목만 보면 AI 코딩 도구나 에이전트 활용법을 설명하는 책처럼 보이지만, 실제 중심 주제는 원제인 The Product-Minded Engineer, 즉 프로덕트 중심 엔지니어**에 더 가깝다.
이 책은 시스템 사고를 버리고 제품만 생각하라고 주장하지 않는다. 알고리즘, 데이터 구조, 분산 시스템, 성능과 안정성 같은 엔지니어링 역량 위에 사용자의 동기와 행동, 제품이 만들어낼 임팩트를 이해하는 능력을 더해야 한다고 말한다. 엔지니어는 시스템 안쪽만 바라보는 사람이 아니라 시스템과 사용자 사이의 경계에 서 있는 사람이라는 것이다.
기능보다 먼저 사용자의 이야기를 설계해야 한다
책에서 가장 먼저 강조하는 개념은 ‘시나리오’다. 여기에서 말하는 시나리오는 단순히 기능을 시간 순서대로 나열한 사용자 스토리가 아니다. 사용자의 동기와 배경, 제품을 사용하는 과정, 제품의 반응과 결과가 하나의 이야기 안에 연결되어야 한다.
책의 Tea++ 사례에서는 재방문 고객이 이전에 마셨던 음료를 다시 주문하는 흐름을 다룬다. 최근 주문, 즐겨찾기, 매장 선택, 결제와 같은 기능을 단순히 이어 붙이면 사용자는 제품 기능을 소개하기 위해 움직이는 인형처럼 보이기 쉽다.
왜 사용자가 최근 주문을 먼저 확인했는지, 음료 이름을 기억하지 못하는지, 즐겨찾기 기능의 존재를 알고 있는지, 앱 사용에 어느 정도 익숙한지와 같은 맥락이 더해져야 행동이 자연스러워진다. 저자는 사용자의 동기를 이해하기 위해 엔지니어에게 익숙한 근본 원인 분석, 즉 RCA를 적용해보는 방법도 제안한다.
페르소나 역시 나이와 직업을 적어놓은 단순한 인물 카드가 아니다. 같은 직장인이라도 처음 앱을 사용하는 사람과 재방문 고객, 숙련된 단골 사용자는 가진 지식과 경험이 다르다. 따라서 기능을 발견하는 방식과 필요한 안내 수준도 달라져야 한다.
제품을 만든 사람은 기능이 어디에 있고 어떻게 작동하는지 이미 알고 있다. 이 지식은 때때로 신규 사용자의 어려움을 보지 못하게 한다. 책에서는 이를 극복하기 위해 자신이 알고 있는 제품 지식을 일부러 잊은 것처럼 생각하는 ‘선택적 망각’을 제시한다. 사용자가 이 기능을 어떻게 쓰는지가 아니라, 먼저 이 기능이 존재한다는 사실을 어떻게 발견할 것인지를 묻는 것이다.
시나리오를 따라 제품을 머릿속에서 실제로 사용해보면 빠진 단계와 예외도 드러난다. Tea++ 사례에서도 주문 흐름을 따라가며 결제 방식, 팁 처리, 여러 매장 이용, 즐겨찾기 매장 설정 등 기능 목록만 볼 때는 발견하기 어려웠던 질문이 생긴다.
이 대목을 읽으며 과거 솔루션 개발 경험이 떠올랐다. 당시에는 자료 조사와 브레인스토밍을 거쳐 필요한 기능을 정리하고 곧바로 개발에 들어간 경우가 많았다. 기능이 필요해 보이는 이유는 설명할 수 있었지만, 특정 사용자가 어떤 상황에서 그 기능을 발견하고 어떤 순서로 사용하며 어디에서 막힐지를 충분히 시뮬레이션하지는 못했다.
책을 읽고 돌아보니 사용자를 위한 솔루션을 만든다고 하면서 정작 사용자 시나리오를 깊게 검토하지 않았다는 사실이 다소 부끄럽게 느껴졌다. 기능 아이디어가 많다는 것과 좋은 제품을 정의했다는 것은 전혀 다른 문제였다.
책에서 시나리오는 기획 단계에만 사용되지 않는다. 제품 이름과 오류 메시지를 설계하고, 시나리오 테스트를 만들고, 사용자 인터뷰와 제품 로드맵을 구성하며, 인터랙션 설계와 부하 시뮬레이션에도 활용된다. 시나리오는 기획자가 작성해 개발자에게 넘겨주는 문서가 아니라 제품의 전 생애주기를 연결하는 공통 언어인 셈이다.
문서를 쓰는 과정이 제품을 설계하는 과정이 된다
이번 책을 통해 가장 새롭게 이해한 부분은 문서 주도 개발이었다. 책에서 사용하는 DDD는 흔히 알고 있는 도메인 주도 설계가 아니라 Documentation-Driven Development를 의미한다.
문서는 대개 개발이 끝난 뒤 작성하는 결과물로 취급된다. 구현된 기능의 사용법을 정리하고 운영 절차와 오류 대응 방법을 기록한다. 그러나 문서 주도 개발에서는 문서를 구현 이후의 설명서가 아니라 구현 이전에 작성할 수 있는 값싼 프로토타입으로 본다.
제품을 다른 사람에게 설명하려다 보면 애매한 개념과 불필요한 단계가 드러난다. 사용 방법을 한 문장으로 표현하기 어렵거나 예외 사항에 대한 설명이 지나치게 길어진다면, 문서 작성 능력이 부족한 것이 아니라 제품 설계 자체에 문제가 있을 수 있다.
예를 들어 사용자가 직접 자원 한도를 설정하도록 만든 뒤 복잡한 런북을 제공하는 것보다, 제품에 안전하고 합리적인 기본값을 넣어 런북의 필요성을 없애는 편이 더 나을 수 있다. 문서를 통해 문제를 보완하려 했지만, 실제로는 제품을 수정하는 쪽이 더 저렴하고 근본적인 해결책인 경우다.
책은 제품을 개발하기 전부터 다양한 형태의 문서를 작성해보라고 제안한다.
설계 전에 페르소나와 시나리오를 반영한 가상의 매뉴얼을 작성하고, 기능 초기 버전을 만드는 동안 사용 가이드를 함께 만든다. 팀이 사용하는 핵심 추상화가 모호하다면 개념 가이드를 작성해 정의를 검토하고, 기능으로 인해 발생할 수 있는 문제와 사용자의 대응 방법도 미리 설명해본다.
이 과정에서 설명하기 어렵거나 지나치게 복잡한 부분이 발견되면 설계를 수정한다. 코드가 상당 부분 완성된 이후보다 문서와 설계 단계에서 변경하는 편이 비용이 훨씬 적게 든다.
문서를 효과적으로 활용한다는 것은 문서의 양을 늘리는 것이 아니다. 사용자가 본래 하려던 일을 하기 위해 반드시 문서를 읽어야 한다면, 그만큼 제품이 사용자의 시간을 요구하고 있는 것이기도 하다. 좋은 문서는 복잡한 제품을 능숙하게 설명하는 문서이기도 하지만, 더 나아가 무엇을 설명하지 않아도 되도록 제품을 개선해야 하는지 알려주는 도구라는 생각이 들었다.
제품을 직접 사용하고, 마찰을 기록하고, 다시 제품에 반영한다
문서를 작성하는 것만으로는 실제 사용 경험의 모든 문제를 발견하기 어렵다. 책은 개발자가 자신의 제품을 직접 사용하는 도그푸딩과 마찰 로그를 중요한 실천 방법으로 제시한다.
마찰 로그는 제품을 사용하면서 느낀 불편과 혼란, 예상과 다른 동작을 기록하는 방식이다. 그러나 기록 양식보다 더 중요한 것은 이를 받아들이는 조직 문화다.
다른 팀의 제품에 대한 마찰을 전달했을 때 공격이나 비난으로 받아들여진다면 누구도 솔직하게 문제를 기록하지 않는다. 전달한 사람을 탓하지 않고, 발견된 내용이 실제 개선으로 이어졌음을 알려주며, 무엇을 언제 수정할지는 해당 제품을 담당하는 팀이 판단해야 한다.
특히 내부 플랫폼과 클라우드 공통환경을 운영하는 조직에서 이 관점이 중요하다. 플랫폼 팀은 API가 정상적으로 응답하고 배포 파이프라인이 성공했다는 사실만으로 서비스가 잘 제공되고 있다고 판단하기 쉽다. 그러나 이를 사용하는 개발팀은 권한 신청, 환경 구성, 오류 메시지 해석, 배포 실패 후 복구, 담당자 문의까지 이어지는 전체 여정에서 불편을 경험한다.
마찰 로그는 이런 경험을 개인의 불평이 아니라 제품 개선을 위한 데이터로 바꾸는 방법이다.
샘플 역시 단순한 코드 조각 이상으로 다뤄진다. 책은 하나의 기능만 보여주는 기능 샘플과 실제 사용 목적을 중심으로 여러 기능을 결합한 시나리오 샘플을 구분한다. 좋은 샘플은 구체적인 사용 상황과 선택 이유를 설명하고, 자동화 테스트나 E2E 테스트의 대상으로 관리해 계속 동작하도록 유지해야 한다.
샘플을 만드는 과정에서 불편함을 느꼈다면 그 마찰을 다시 제품에 반영한다. 이렇게 보면 샘플은 문서의 부속물이 아니라 학습, 검증, 테스트와 제품 발견을 함께 수행하는 작은 제품에 가깝다.
이야기를 요구 사항과 시스템 설계로 변환하는 과정
시나리오가 구체화됐다고 곧바로 개발을 시작하는 것은 아니다. 7장에서는 북극성 시나리오를 고수준 요구 사항과 설계 원칙, PRD, 유스케이스, 마일스톤과 사용자 흐름으로 변환하는 과정을 다룬다.
흥미로운 부분은 이야기 중심의 표현과 시스템 중심의 표현 사이에 상당한 전환이 필요하다는 점이다.
사용자의 관점에서는 제품이 시간 순서에 따라 이어지는 여정으로 보인다. 반면 시스템은 화면, API, 데이터베이스, 서비스와 컴포넌트의 관계로 구현된다. PM은 첫 번째 관점에 익숙하고 엔지니어는 두 번째 관점에 익숙할 수 있다. 한쪽 관점만으로는 제품을 완전하게 설명하기 어렵다.
책은 시나리오를 요구 사항으로 바꾸면서 사용자 관점을 잃지 않도록 유스케이스 요약집을 활용한다. 요구 사항을 단순 기능 명세로 작성하는 대신, 사용자가 어떤 행동을 할 수 있으며 그 행동을 통해 어떤 가치를 얻는지 표현한다.
그 뒤 첫 번째 마일스톤에 포함할 기능을 정하고 상세 사용자 흐름을 설계한다. 이렇게 만든 흐름은 RFC와 사용성 조사를 통해 실제 사용자에게 검증한다. 잠재 사용자에게 스토리보드를 보여주고 의견을 받거나, 작동하는 프로토타입을 이용해 특정 과업을 수행하도록 하면서 기능 발견성, 사용성 문제와 누락된 기능을 확인한다.
특히 책은 RFC에서 설계자가 정답을 먼저 제시하면 더 많은 통찰을 놓칠 수 있다고 지적한다. 제품팀이 완성된 답을 설명하는 자리가 아니라, 실제 사용자의 업무 흐름과 혼란을 발견하는 과정이어야 한다는 의미다.
프로덕트 아키텍처에서 되짚어본 진정한 PO의 의미
9장 「프로덕트 아키텍처」는 클라우드 아키텍트의 관점에서 가장 인상 깊은 부분이었다.
보통 아키텍처를 논의하면 시스템 구성, 컴포넌트 관계, 확장 방식, 데이터 복제와 장애 대응으로 대화가 빠르게 이동한다. 이 책은 그 전에 사용자에게 어떤 경험을 제공해야 하는지를 묻는다.
지연시간, 가용성, 데이터 일관성은 모두 중요한 비기능 요구 사항이지만 모든 상황에서 가장 높은 수준을 동시에 달성할 수는 없다. 강한 데이터 일관성은 성능이나 장애 허용성에 부담을 줄 수 있고, 가용성을 높이기 위해 보조 복제본에서 데이터를 읽으면 최신 변경이 아직 보이지 않을 수 있다.
따라서 무엇을 우선해야 하는지는 기술의 우열이 아니라 제품 시나리오에 따라 달라진다.
책에서 데이터 일관성을 설명하는 방식이 특히 인상적이었다. 일관성을 데이터베이스의 속성으로만 보지 않고 사용자의 행동을 중심으로 풀어낸다.
- 내가 방금 변경한 내용을 이후 화면에서 확인할 수 있는가
- 다른 사용자의 변경이 언제 나에게 보이는가
- 자동화나 에이전트가 수행한 변경이 언제 반영되는가
- 다른 사용자의 변경을 모른 채 내 데이터로 덮어쓸 가능성은 없는가
이러한 보장은 데이터베이스 제품이 자동으로 결정해주는 것이 아니라 제품이 사용자와 맺는 약속에 가깝다. 시스템 전체에 가장 강한 일관성을 일괄 적용하기보다 어떤 사용자 행동에 어느 수준의 일관성이 필요한지 시나리오별로 결정해야 한다.
클라우드 아키텍처도 마찬가지다. Multi-AZ, 복제, 캐시, 메시징, 자동 확장 같은 기술은 그 자체가 목표가 아니다. 사용자가 어떤 행동을 중단 없이 수행해야 하는지, 어떤 결과가 즉시 보여야 하는지, 어느 정도의 지연을 감수할 수 있는지를 먼저 정의해야 기술 선택의 근거가 생긴다.
이 장을 읽으며 ‘진정한 PO는 무엇을 하는 사람인가’를 다시 생각하게 됐다. 개인적으로 PO는 단순히 백로그의 우선순위를 정하고 기능 개발 일정을 관리하는 역할에 머물러서는 안 된다고 느꼈다.
사용자에게 제공할 가치와 시스템의 제약을 함께 이해하고, 지연시간·가용성·일관성·비용 사이에서 어떤 선택을 할지 설명하며, 그 결과에 책임지는 사람이 진정한 제품 오너에 더 가깝지 않을까. 책이 PO의 역할을 직접 정의하는 것은 아니지만, 프로덕트 아키텍처를 다루는 방식이 제품 오너십의 의미를 되짚어보는 계기가 됐다.
시스템이 정상인 것과 사용자가 일을 끝내는 것은 다르다
책은 CPU 사용률이나 서버 가동 상태 같은 저수준 지표만 보지 말고 사용자가 실제로 영향을 받는 행동을 측정하라고 제안한다.
예를 들어 Pod와 데이터베이스, API Gateway가 모두 정상이어도 사용자가 신청, 주문, 결제를 끝내지 못한다면 제품 관점에서는 정상적인 상태라고 보기 어렵다. 동시 사용자 수, 사용자 시나리오 완료율, 클라이언트 측 가용성과 같이 사용자의 실제 결과를 보여주는 지표가 함께 필요하다.
이는 운영 지표를 버리라는 의미가 아니다. 시스템의 세부 상태와 사용자 결과 사이의 간극을 연결해야 한다는 뜻이다.
AI 시대에는 구현뿐 아니라 모니터링과 장애 분석도 자동화될 가능성이 높다. 그럴수록 사람이 해야 할 일은 더 많은 지표를 수집하는 것이 아니라, 어떤 사용자 행동을 보호해야 하며 어느 지표가 실제 제품 성공을 나타내는지 결정하는 쪽으로 이동할 것이다.
국내 개발 환경에서는 다소 추상적으로 느껴지는 부분도 있었다
책의 전반적인 내용은 애자일 기반의 협업 문화와 엔지니어가 제품 의사결정에 적극적으로 참여하는 환경을 전제로 한다.
PM, 디자이너, 엔지니어가 시나리오를 함께 만들고, 마찰 로그를 자유롭게 공유하며, 사용자 피드백에 따라 우선순위와 설계를 조정한다. 엔지니어가 제품 지표와 사용자 인터뷰에도 깊이 관여한다.
그러나 국내 SI와 공공 프로젝트에서는 요구 사항이 계약과 RFP를 통해 상당 부분 고정되고, 기획·설계·개발·운영의 역할이 조직과 사업자별로 나뉘는 경우가 많다. 개발자가 사용자와 직접 만나거나 제품의 방향을 조정할 권한이 충분하지 않은 환경도 흔하다.
이런 현실에서는 일부 내용이 이상적이거나 추상적으로 느껴질 수 있다. 외국 기업의 제품 개발 사례를 국내 프로젝트에 그대로 적용하기 어려운 구간도 있다.
그럼에도 책이 제시하는 질문은 유효하다.
개발자에게 최종 결정 권한이 없더라도 요구 사항의 배경을 확인하고, 사용자의 흐름에서 빠진 단계를 질문하고, 오류 메시지와 문서를 개선하며, 시스템 지표를 사용자 결과와 연결하려는 노력은 가능하다. 조직 전체를 한 번에 바꾸지 못하더라도 맡은 범위에서 제품 사고를 적용할 수 있다.
이 책을 추천하고 싶은 독자
이 책은 프로그래밍 입문서도, AI 코딩 도구 활용서도 아니다. 코드를 작성하고 배포하는 기본기는 이미 갖췄지만, 이제는 무엇을 만들고 어떤 기준으로 설계해야 하는지를 고민하는 독자에게 더 잘 맞는다.
특히 다음과 같은 독자에게 유용하다.
- 요구 사항을 전달받아 구현하는 역할에서 한 단계 더 성장하고 싶은 개발자
- 사용자 가치와 기술 구조를 함께 고민해야 하는 테크리드
- API, 내부 개발 플랫폼과 클라우드 공통환경을 만드는 플랫폼 엔지니어
- 비기능 요구 사항을 제품의 언어로 설명해야 하는 아키텍트
- 기능 우선순위를 넘어 기술적 트레이드오프까지 이해하고 싶은 PM과 PO
- AI로 개발 속도는 빨라졌지만 무엇을 만들어야 할지 더 고민하게 된 엔지니어
반대로 구체적인 AI 도구 사용법이나 코드 구현 예제, 특정 아키텍처 패턴의 상세한 적용 방법을 기대한다면 다소 추상적으로 느껴질 수 있다. 이 책의 가치는 정답이나 구현 레시피보다 제품을 바라보는 사고 프레임에 있다.
마무리
『AI 시대의 엔지니어링 전략』을 읽으며 AI가 개발자를 대체할 것인가라는 익숙한 질문보다 더 중요한 질문을 생각하게 됐다.
AI가 구현을 대신할 수 있는 시대에, 엔지니어는 무엇을 판단하고 책임져야 하는가.
책은 그 답을 사용자 시나리오, 문서 주도 개발, 도그푸딩과 마찰 로그, 요구 사항 변환, 프로덕트 아키텍처로 이어지는 과정에서 찾는다.
무엇을 만들지 정의하고, 사용자의 이야기를 시스템 설계로 연결하며, 기술적 선택이 사용자에게 어떤 결과로 전달되는지 설명하는 일이다. AI는 코드를 빠르게 작성할 수 있지만 어떤 사용자의 어떤 문제를 해결해야 하는지, 무엇을 우선하고 무엇을 양보할지는 스스로 결정하지 못한다.
개인적으로는 문서 주도 개발을 새롭게 이해한 것이 가장 큰 수확 중 하나였다. 문서는 개발 이후에 남기는 설명이 아니라, 제품을 더 저렴하게 검증하고 수정할 수 있는 설계 도구였다. 프로덕트 아키텍처를 통해서는 사용자의 가치와 시스템 트레이드오프를 함께 책임지는 제품 오너십의 의미도 다시 생각해보게 됐다.
이 책이 말하는 프로덕트 중심 엔지니어는 코드를 덜 중요하게 보는 사람이 아니다. 탄탄한 기술 역량을 바탕으로 코드가 사용자에게 어떤 변화를 만들어냈는지까지 설명할 수 있는 사람이다.
AI가 코드를 더 빠르게 만들어줄수록, 그런 엔지니어의 가치는 오히려 더 커질 것이다.
"한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 책을 협찬 받아 작성된 서평입니다."
이글이 도움이 되셨으면 아래↓의 [공감] 버튼과 우측상단↗의 [구독하기] 클릭 부탁드려요 ^^
