AI 시대의 엔지니어링 전략

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

AI가 코드를 대신 작성하는 시대, 요구사항을 구현하는 개발자에서 무엇을 만들어야 하는지 고민하는 엔지니어로 넘어가기 위한 책

필요한 선수 지식

• 요구 학력 : 주니어 → 미드레벨로 올라가는 개발자
• 예제 코드 : 코드보다 시나리오·제품 설계 사례 중심
• 난이도 : ★★☆☆☆

책의 구성 중 마음에 들었던 주제

CHAPTER 1 프로덕트 사고의 기본

보통 개발자는 요구사항이 전달되면 어떻게 구현할 것인가?부터 생각하게 된다. 하지만 이 챕터에서는 구현하기 전에 먼저 사용자가 어떤 상황에서 기능을 사용하고, 무엇을 해결하기 위해 필요한지를 시나리오로 작성해보는 방법을 설명한다.

특히 시나리오를 단순히 요구사항을 설명하기 위한 문서가 아니라 구현하려는 기능이 실제 사용자에게 필요한지를 검증하는 수단으로 사용한다는 점이 인상 깊었다. 실무에서는 이미 결정된 요구사항을 전달받고 이를 어떻게 구현할지 고민하는 경우가 많다. 그러다보면 개발 과정에서 이상한 요구사항을 발견하더라도 “요구사항이 그러니까”라는 이유로 그대로 구현하게 되는 경우가 있다.

하지만 실제로 개발을 시작하기 전에 사용자가 이 기능을 왜 사용해야 하는지, 어떤 흐름으로 사용하게 될지를 시나리오로 만들어보면 요구사항 자체의 문제를 훨씬 일찍 발견할 수 있다. 결국 개발자의 역할은 요구사항을 코드로 번역하는 것에서 끝나는 것이 아니라, 요구사항이 실제 사용자의 문제를 해결하는지 검증하는 과정까지 포함된다는 것이 이 챕터의 핵심 내용이다.

CHAPTER 3 에러와 경고

이 챕터에서는 에러와 경고도 하나의 사용자 경험으로 바라본다. 단순히 Error, Failed와 같이 문제가 발생했다는 사실만 알려주는 것이 아니라 무엇이 잘못되었는지, 사용자가 무엇을 해야 하는지, 개발자가 어떤 정보를 이용해 문제를 추적할 수 있는지까지 고려해야 한다고 설명한다.

실제로 오래된 프로그램을 유지보수하다보면 원인을 알 수 없는 에러 메시지 때문에 로그와 소스코드를 역추적하는 데 훨씬 많은 시간을 사용하는 경우가 있다. 개발 당시에는 예외 하나를 잡아서 메시지를 출력하는 정도의 작은 차이지만, 운영 단계에서는 장애 대응 시간이 몇 분에서 몇 시간까지 차이날 수도 있다.

특히 사용자에게 보여주는 에러 메시지뿐만 아니라 API, 라이브러리, 내부 개발 도구처럼 개발자가 사용하는 소프트웨어 역시 결국 누군가가 사용하는 제품이라는 관점이 마음에 들었다.

CHAPTER 4 자사 제품 체험

이 챕터에서는 개발자가 자신이 만든 제품을 직접 사용해보는 도그푸딩(Dogfooding)과 사용 과정에서 발생하는 불편함을 기록하는 마찰 로그(Friction Log)를 설명한다.

테스트 코드가 정상적으로 통과했고 요구사항에 맞게 구현되었다고 해서 반드시 사용하기 좋은 프로그램이 되는 것은 아니다.

개발자는 내부 구조를 이미 알고 있기 때문에 무의식적으로 정상적인 사용 방법을 알고 있지만, 실제 사용자는 어떤 버튼을 눌러야 하는지부터 고민해야 한다. 그렇기 때문에 개발자가 사용자와 같은 조건에서 프로그램을 직접 사용해보는 과정이 필요하다. 특히 기능 단위의 테스트가 아니라 설치부터 설정, 최초 실행, 실제 기능 사용까지 전체 사용자 흐름을 직접 경험한다는 점이 중요하다고 느꼈다.

개발하면서 기능 하나하나만 보면 문제가 없었는데 실제 사용자가 사용하는 순서대로 프로그램을 실행해보면 사소한 불편함이 계속 발견되는 경험이 있었다. 결국 프로그램의 완성도는 각각의 기능이 정상적으로 동작하는 것뿐만 아니라 사용자가 목적을 달성하는 전체 과정이 얼마나 자연스러운지까지 포함한다는 생각이 들었다.

CHAPTER 7 시뮬레이션을 통한 제품 탐색

이 챕터에서는 제품의 비전을 실제 요구사항으로 변환하고, 사용자 흐름과 JTBD(Job To Be Done)를 이용하여 어떤 기능을 먼저 만들어야 하는지 결정하는 방법을 설명한다.

개발 프로젝트에서 요구사항은 처음부터 완벽하게 정의되어 전달되는 경우보다 개발 과정에서 계속 추가되고 변경되는 경우가 훨씬 많다. 문제는 모든 요구사항을 동일한 중요도로 처리하기 시작하면 기능은 계속 늘어나지만 정작 사용자가 가장 필요로 하는 기능이 무엇인지 알기 어려워진다는 점이다.

책에서는 사용자가 최종적으로 무엇을 달성하려고 하는지부터 생각하고, 이를 시나리오와 사용자 흐름으로 만들어 요구사항의 우선순위를 결정한다. 개발자의 입장에서는 기능을 하나 더 추가하는 것이 어렵지 않아 보일 수도 있다. 하지만 기능 하나가 추가될 때마다 UI, 예외처리, 테스트, 문서화, 유지보수 비용도 함께 늘어난다. 그래서 “구현할 수 있는가?”보다 “이 기능을 정말 구현해야 하는가?”를 먼저 고민하는 것이 오히려 장기적으로 더 중요한 엔지니어링 판단이라는 점이 인상 깊었다.

읽고 난 후

추천 지수 : ★★★★★

처음 AI 시대의 엔지니어링 전략이라는 제목을 봤을 때는 Claude Code, Cursor같은 AI 코딩 도구를 이용해 개발 생산성을 높이는 방법을 설명하는 책이라고 생각했다.

하지만 실제로 읽어보면 AI 자체를 설명하는 내용은 거의 없고, AI는 이 책의 주제라기보다 개발자의 역할이 변하고 있는 배경에 가깝다. 원제 역시 The Product-Minded Engineer로, 오히려 원제가 책의 내용을 훨씬 정확하게 표현하고 있다고 생각한다.

AI가 코드를 작성해주는 비율이 높아질수록 개발자가 직접 코드를 작성하는 능력이 필요 없어지는 것은 아니지만, 단순히 요구사항을 빠르게 구현하는 능력만으로 차별화하기는 점점 어려워질 것이다. 그렇다면 개발자에게 남는 역할은 How뿐만 아니라 Why와 What을 고민하는 것이다. 누가 사용하는 기능인지, 왜 필요한 기능인지, 실제 사용자의 문제를 해결하는지, 더 단순한 방법은 없는지 생각하고 필요하다면 요구사항 자체에도 의견을 제시해야 한다.

처음에는 이런 내용들이 기획자나 PM이 해야 하는 일이 아닌가 하는 생각도 들었다. 하지만 책을 읽고 난 뒤에는 개발자가 PM의 역할을 대신해야 한다기보다, 전달받은 요구사항을 아무 생각 없이 구현하는 Ticket Taker가 되어서는 안 된다는 의미에 더 가깝다고 느꼈다. 아무리 아키텍처가 훌륭하고 코드가 깔끔하더라도 사용자의 문제를 해결하지 못한다면 좋은 제품이라고 하기는 어렵다. 반대로 사용자의 목적을 이해하고 있다면 어떤 기능을 추가해야 하는지뿐만 아니라 어떤 기능을 만들지 않아야 하는지도 판단할 수 있다.

그동안 좋은 개발자가 되기 위해 주로 코드 품질, 성능, 설계와 같은 어떻게 잘 만들 것인가?를 고민했다면 이 책을 통해 그보다 앞에 있는 무엇을 왜 만들 것인가?도 개발자가 함께 고민해야 하는 문제라는 인사이트를 얻었다.