[리뷰] <AI 시대의 엔지니어링 전략>, 전통적인 엔지니어링과 어떻게 달라져야할까?

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

도서 링크: 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

AI가 코드를 작성하는 시대, 개발자는 무엇을 잘해야 할까?

개발자로 일하면서 요즘 가장 많이 생각하는 주제 중 하나가 AI가 발전할수록 개발자는 무엇을 잘해야 하는가입니다. 몇 년 전까지만 해도 새로운 프레임워크를 공부하고, 더 좋은 코드를 작성하고, 복잡한 문제를 구현할 수 있는 능력을 키우는 것이 개발자로 성장하는 비교적 명확한 방법이라고 생각했습니다. 물론 지금도 이런 능력은 중요합니다. 하지만 AI를 실제 개발 과정에서 사용하기 시작하면서 조금씩 생각이 달라졌습니다.

 

예전에는 한두 시간이 걸렸을 코드를 AI가 몇 분 만에 만들어주기도 하고, 익숙하지 않은 기술의 코드도 꽤 그럴듯하게 작성합니다. 아직 결과물을 그대로 신뢰하기는 어렵지만, 적어도 ‘코드를 작성하는 것’ 자체의 비용은 빠르게 낮아지고 있다는 생각이 들었습니다.

 

그래서 자연스럽게 이런 질문이 생겼습니다.

그렇다면 앞으로 개발자의 가치는 어디에서 만들어질까?

 

<AI 시대의 엔지니어링 전략>은 이 질문에 대해 꽤 흥미로운 방향을 제시합니다. 좋은 엔지니어는 주어진 요구 사항을 정확하게 구현하는 사람에서 그치는 것이 아니라, 무엇을 왜 만들어야 하는지 고민하고 제품의 성공에 영향을 줄 수 있는 사람이어야 한다는 것입니다. 지금 시대의 Product Engineer를 얘기하는 것으로 봐도 될 것 같습니다.

요구 사항을 잘 구현하는 것만으로 충분할까?

개발자로 일하다 보면 이미 정해진 요구 사항을 전달받는 경우가 많습니다. 기획서가 나오고 디자인이 완성되면 이를 바탕으로 API를 연결하고 화면을 구현합니다. 이 과정에서도 좋은 구조를 고민하고, 성능을 개선하고, 장애 가능성을 줄이는 등 수많은 기술적인 판단이 필요합니다.

 

저 역시 이런 부분을 잘하는 것이 좋은 개발자가 되는 중요한 조건이라고 생각해 왔습니다.

그런데 경력이 조금씩 쌓이면서 구현보다 더 어려운 문제가 있다는 것을 느끼기 시작했습니다.

“그런데 이 기능은 왜 필요한가?”

 

기술적으로 완성도가 높은 기능을 만들어도 사용자가 잘 사용하지 않을 수 있습니다. 반대로 구현 자체는 단순하지만 사용자의 불편을 정확하게 해결하면서 제품에 큰 영향을 주는 기능도 있습니다. 책에서 이야기하는 ‘프로덕트 중심 엔지니어’는 바로 이 지점에서 출발합니다.

 

요구 사항을 받자마자 어떻게 구현할지를 고민하기보다 사용자가 어떤 상황에서 이 기능을 사용하는지, 지금 겪고 있는 문제는 무엇인지, 우리가 만들려는 기능이 정말 그 문제를 해결하는지를 먼저 생각합니다. 읽으면서 제가 평소 개발 과정에서 'How'에는 많은 시간을 사용하면서 'Why'에는 상대적으로 적은 시간을 사용하고 있지 않았나 돌아보게 됐습니다.

코드 밖에도 개발자가 해결해야 할 문제가 많다

특히 좋았던 점은 프로덕트 사고를 추상적인 태도나 마인드셋 정도로 설명하지 않는다는 점이었습니다. 사용자 시나리오를 작성하고, 실제 제품을 직접 사용해보고, 사용 과정에서 발생하는 마찰을 기록하고, 사용자 피드백과 제품 지표를 확인하는 등 개발자가 제품을 이해하기 위해 실제로 해볼 수 있는 행동들을 이야기합니다.

 

그중에서도 제품을 직접 사용해보는 ‘도그푸딩’과 마찰을 기록하는 방식이 인상적이었습니다. 개발하다 보면 내가 만든 기능을 개발 환경에서는 수도 없이 확인하면서도 정작 실제 사용자의 흐름대로 처음부터 끝까지 사용해보는 경험은 의외로 부족할 수 있습니다.

 

버튼 하나를 클릭하는 데 한 단계가 더 필요한 것, 에러가 발생했는데 사용자가 무엇을 해야 하는지 알 수 없는 것, 개발자는 너무 익숙해서 당연하다고 생각하지만 처음 사용하는 사람에게는 이해하기 어려운 인터페이스 같은 문제는 코드만 보고서는 발견하기 어렵습니다.

 

결국 좋은 제품을 만드는 능력에는 코드를 작성하는 능력뿐만 아니라 내가 만든 소프트웨어를 사용자의 입장에서 관찰하는 능력도 포함된다는 생각이 들었습니다.

에러 메시지도 제품의 일부다

개발자로서 특히 흥미롭게 읽었던 부분은 에러와 경고를 다루는 내용이었습니다. 개발할 때 에러 처리는 흔히 예외 상황에 대한 방어 코드 정도로 생각하기 쉽습니다. API 요청이 실패하면 에러를 잡고, 적절한 메시지를 보여주고, 로깅 시스템에 기록하는 식입니다.

하지만 사용자의 입장에서 생각하면 에러는 단순한 기술적 실패가 아닙니다.

 

사용자는 에러를 만났을 때 "무슨 일이 발생했는가?", "내가 잘못한 것인가?", "이제 무엇을 해야 하는가?"를 알고 싶어 합니다.

결국 좋은 에러 처리는 에러를 잡는 것에서 끝나는 것이 아니라 사용자가 문제에서 빠져나올 수 있도록 돕는 데까지 이어져야 합니다.

 

이런 관점은 프런트엔드 개발자로서 특히 공감되는 부분이었습니다. 화면은 사용자가 시스템과 직접 만나는 곳이기 때문에 백엔드에서 전달된 에러를 단순히 문구로 변환하는 것보다, 사용자가 다음 행동을 선택할 수 있도록 만드는 것이 훨씬 중요하기 때문입니다.

프로덕트 아키텍처라는 관점

후반부에서 다루는 ‘프로덕트 아키텍처’라는 개념도 기억에 남았습니다. 개발자에게 아키텍처라고 하면 보통 모듈의 의존성이나 레이어 분리, 확장성, 성능, 장애 대응 같은 기술적인 문제를 먼저 떠올리게 됩니다. 저 역시 좋은 아키텍처를 생각할 때 변경에 얼마나 유연한지, 테스트하기 쉬운지, 복잡도를 얼마나 잘 통제하고 있는지를 주로 생각했습니다.

 

하지만 책을 읽으면서 한 가지 기준을 더 추가할 수 있겠다는 생각이 들었습니다.

“이 구조가 결국 어떤 사용자 경험을 만들어내는가?”

 

기술적인 선택과 제품 경험은 생각보다 멀리 떨어져 있지 않습니다. 성능이 느리면 사용자는 기다려야 하고, 시스템의 안정성이 떨어지면 결제나 주문 같은 중요한 순간에 제품을 신뢰하기 어렵습니다. 지나치게 경직된 구조는 새로운 요구 사항에 대응하는 속도를 떨어뜨리고 결국 제품의 실험 속도에도 영향을 줍니다.

 

좋은 기술적 의사결정은 단순히 코드가 아름다운가를 넘어 제품이 앞으로 어떤 선택을 할 수 있게 만들어주는가까지 고려해야 한다는 점을 다시 생각하게 됐습니다.

AI 시대에 오히려 중요해지는 개발자의 역할

이 책을 읽고 나서 처음의 질문으로 다시 돌아왔습니다. AI가 코드를 점점 더 잘 작성하게 된다면 개발자는 무엇을 잘해야 할까? 적어도 저는 'AI보다 코드를 더 잘 작성하는 사람'이 되는 것만으로는 충분하지 않을 것 같습니다.

 

대신 어떤 문제가 중요한지 판단하고, 사용자가 실제로 겪고 있는 문제를 발견하고, 여러 해결책 사이의 트레이드오프를 판단하고, 기술적인 선택을 제품의 결과까지 연결할 수 있는 능력이 점점 중요해질 것 같습니다. 그리고 이런 능력은 AI에게 코드를 많이 작성하게 한다고 자연스럽게 생기지는 않습니다. 오히려 구현 비용이 낮아질수록 무엇을 만들 것인지 결정하는 비용은 상대적으로 더 중요해질 수 있습니다. 잘못된 요구 사항도 빠르게 구현할 수 있고, 필요 없는 기능도 빠르게 만들 수 있기 때문입니다.

 

그래서 이 책의 제목에는 ‘AI 시대’라는 표현이 붙어 있지만, 개인적으로는 AI 활용법을 알려주는 책이라기보다 개발자의 역할을 코드 바깥으로 확장하는 방법을 이야기하는 책에 더 가깝게 느껴졌습니다.

어떤 개발자에게 추천하고 싶은가

이 책은 새로운 기술이나 코딩 방법을 배우고 싶은 사람보다는 어느 정도 실무를 경험한 뒤 다음 단계의 성장을 고민하고 있는 개발자에게 더 잘 맞는 책이라고 생각합니다. 특히 주어진 요구 사항을 구현하는 데에는 어느 정도 익숙해졌지만 앞으로 어떤 역량을 키워야 할지 고민하는 개발자라면 읽어볼 만합니다.

 

PM이나 디자이너가 정해준 요구 사항을 구현하는 역할에서 조금 더 나아가 제품의 문제를 함께 정의하고, 기술적인 관점에서 해결책을 제안하고 싶은 개발자에게도 잘 맞습니다. 저 역시 좋은 코드를 작성하고 기술적인 깊이를 쌓는 것을 개발자로서 중요한 성장 방향이라고 생각합니다. 다만 한 가지가 추가됐습니다. 좋은 개발자는 코드를 잘 작성하는 사람인 동시에, 자신이 작성한 코드가 결국 누구의 어떤 문제를 해결하는지 알고 있는 사람이어야 한다는 것입니다.

 

AI가 코드를 점점 더 많이 작성하게 되는 시대라면, 어쩌면 이 차이가 앞으로 개발자의 경쟁력을 결정하게 될지도 모르겠습니다.