AI가 다 해주는 시대, 개발자는 뭘 알아야 할까 — AI 시대의 엔지니어링 전략

[전자책] AI 시대의 엔지니어링 전략 - 코드를 넘어 제품의 성공까지 설계하는 개발자의 사고법
드류 호스킨스 지음, 조쉬(김승권) 옮김 / 한빛미디어 / 2026년 8월

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

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

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

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

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

<시나리오 하나로 시작된 이야기>

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

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

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

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

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

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

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

< 하나의 원칙이 책 전체를 관통합니다 >

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

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

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

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

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

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

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

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

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

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

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

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

이런 분께 추천합니다

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

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

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