AI 시대에 개발자의 역할과 방향에 대한 인사이트

비제이퍼블릭에서 리뷰 활동을 위해서 책을 제공받아 작성된 서평입니다.

제목 :
저자 : 팍스
출판사 : 비제이퍼블릭 2026

몇 년 전 GPT 3의 등장과 동시에 개발자는 격변의 시대에 살고 있다. 오늘날 많은 프로그래밍 종사자들은 AI로 코드를 생산한다. 나 역시 Cursor 와 Claude Code 의 등장과 동시에 좋은 파트너로 함께 하고 있다. 특히 올해는 많은 AI 에이전틱 개발 방법론이 떠오르고, 유수의 기업에서도 AI를 주된 토픽으로 꺼낸다. 이렇듯 생성형 AI의 빠른 변화는 코드 구현에 대한 부담을 덜어주게 되었고, 개발자가 아닌 직군에서도 기능을 실제로 구현해볼 기회를 주었다. 그러나 이런 과정에서 개발자의 역할은 '코드 작성' 이라는 주된 개발 업무에서 벗어나 기술적 판단과 의사 결정에 좀 더 무게가 실린다. 변하는 시대에 개발자는 어떻게 역할을 바꿔야 하며, 엔지니어링 관점을 AI에 접목해야할지 이번 책에서 소개한다.

필경사가 아니라 편집자로

저자는 프롤로그에서 구텐베르크 이전의 필경사 이야기를 꺼낸다. 필경사의 일은 옮겨 적는 실행, 오류를 잡는 검증, 남길 텍스트를 고르는 판단으로 나뉘는데, 활자 인쇄기가 대체한 것은 실행뿐이었다. 검증으로 물러난 이들은 교정자가 되었고 판단으로 옮겨 간 이들은 무엇을 출판할지 정하는 편집자가 되었다. 저자는 지금의 AI가 개발자에게 이 인쇄기와 같다고 보고 'AI가 대체하는 것은 오직 실행이며, 결코 대체할 수 없는 고유 영역은 판단이다'라고 말한다.

이 비유가 가볍게 들리지 않는 건 저자가 자기 실패를 먼저 꺼내 놓기 때문이다. 추석 연휴 동안 AI와 함께 만든 개인 비서 시스템이 두 달 뒤 DB 비용 폭탄으로 돌아왔는데, 원인은 5분마다 DB에 접속하도록 꼬여 있던 설정이었다. 저자는 이 일을 겪고 AI 시대에 필요한 것을 '무엇을 만들지 목표를 정확히 설정하고, 성과와 리스크, 비용을 따져 판단하고, 그 판단을 끝까지 검증하는 능력'이라고 정리한다.

이 추석 프로젝트의 뼈아픈 경험은 저자가 AI 시대에 무엇을 판단해야 하는지 설명하기 위한 좋은 사례로 계속 등장한다. 판단을 우선순위, 트레이드오프, 범위, 검증 기준 네 가지로 나눌 때도 마찬가지다. 여기서 배울 점은 네 가지 모두 코드를 쓰기 전에 정해야 한다는 것이다. 저자는 DB 비용이 월 50달러를 넘으면 구조를 재검토한다는 중단 조건 하나만 정해 두었어도 두 달을 날리지 않았을 거라고 돌아본다. 그중에서도 범위 이야기가 오래 남았다. 구현 비용이 0에 가까워진 지금은 오히려 무엇을 만들지 않을지 정하는 일이 더 어려워졌고 저자는 그 단호함이 프로젝트의 일정과 품질, 운영을 지켜낸다고 말한다.

회의실의 질문이 바뀌었다

예전 회의실에서 임원은 구현이 가능한지와 언제 끝나는지를 물었다. 지금이라면 질문은 이번 분기에 꼭 해야 하는지, 안 하면 무엇이 위험한지, A안과 B안 중 무엇을 추천하는지로 바뀐다. 저자는 이것을 '회사가 개발자에게 기대하는 역할이 생산자에서 판단자로 완전히 이동한 것'이라고 표현한다. 그 자리에서 인정받는 사람은 가능하다고 말하는 사람이 아니라, 해야 하는 이유와 안 했을 때 생기는 일, 그리고 붙여야 할 조건을 함께 말하는 사람이다. 판단을 대안과 리스크의 말로 전달하는 것까지가 일이라는 얘기다.

판단자의 자리가 AI에게 넘어가지 않는 이유로 저자는 맥락을 든다. AI의 비교표만 믿고 DB를 골랐다가 몇 달 뒤 다시 옮겨야 했던 경험에서 저자는 이렇게 정리한다. 'AI의 기술 분석은 정확하다. 다만 그 분석에는 우리 팀의 규모, 운영 여력, 향후 인력 계획과 같은 맥락이 빠져 있다.' 기술적으로 최선인 것과 우리 상황에서 최선인 것은 다르고 그 간극을 메우는 것이 판단이라는 것이다.

그렇다고 모든 결정을 무겁게 다루라는 이야기는 아니다. 저자는 제프 베이조스의 단방향 문과 양방향 문을 빌려 결정의 무게를 나눈다. UI 문구처럼 되돌릴 수 있는 결정은 AI의 초안을 받아 빠르게 내보내고 DB 스키마나 인증 체계, 결제 흐름처럼 되돌리기 어려운 결정 앞에서는 멈춰 서서 사람이 주도권을 쥐라고 한다. 이건 그냥 해도 되나 망설여지는 순간에 바로 꺼내 쓸 만한 기준이었다.

깔끔한 코드가 가장 위험하다

AI가 만든 코드를 대하는 저자의 입장은 분명하다. 'AI가 만든 코드는 결코 정답이 아니라 검증해야 할 가설일 뿐'이라는 것이다. 근거로 드는 것은 자동화 편향이다. 리뷰어는 엉성한 주니어의 코드에서는 본능적으로 결함을 찾지만 문법이 완벽하고 주석까지 친절한 코드 앞에서는 검증을 건너뛰기 쉽다. 그래서 저자는 'AI 코드에서 가장 위험한 순간은 코드가 엉망일 때가 아니라 완벽하게 깔끔할 때'라고 말한다.

여기에 대한 저자의 처방이 가설 카드다. AI가 만든 코드나 설정을 머지하기 전에 이 코드가 보장해야 할 것, 깨질 수 있는 반례 세 개, 실패 경로를 재현할 부정 테스트 두 개, 성공 기준, 중단 조건, 이상을 감지할 관측 지표 하나를 적는다. 테스트까지 AI가 짰다면 그 테스트가 우리 비즈니스 규칙을 반영하는지부터 의심하라는 말이 특히 와닿았다.

자동화 전반으로 시야를 넓히면, 자동화가 루틴을 완벽하게 처리할수록 사람은 시스템을 다루는 감각을 잃고 예외가 왔을 때 대응하지 못한다. 그래서 저자는 자동화된 변경을 내보내기 전에 세 가지를 묻자고 한다. 되돌릴 수 있는가, 무엇이 잘못되고 있는지 알아차릴 수 있는가, 조금씩 적용할 수 있는가. 하나라도 아니라면 멈추고 설계를 보강하라는 것이다. 자동화가 잘 돌아갈수록 안전하다고 여기기 쉽지만 저자는 반대로 잘될수록 예외에 더 취약해진다고 본다.

판단은 쌓이고, 구조가 된다

뒤쪽 장들은 판단을 잘하는 사람과 그렇지 못한 사람을 무엇이 가르는지 묻는다. 저자는 맥락 없이 결정하고, 검증 없이 밀어붙이고, 결정을 미루고, 과거에 갇히는 네 가지 유형의 공통점을 '도태되는 개발자는 자기 판단에 대해 메타적으로 사고하지 못한다'로 묶는다. 지금 어떤 근거로 이 결정을 내리고 있는지를 스스로 묻지 않는다는 것이다.

저자는 이 질문을 자기 자신에게도 돌린다. 한 번 성공한 기술 선택을 성공의 이유로 착각하고 조건이 달라진 뒤에도 반복했다는 고백이다. 저자는 이것을 결정하고, 기록하고, 관찰하고, 복기하고, 교정하는 판단의 피드백 루프가 끊긴 결과로 본다. 그래서 정체성도 특정 기술을 잘하는 사람이 아니라 팀의 맥락에 맞는 기술을 고를 수 있는 사람으로 한 층 올려 두라고 권한다. 원하는 방향으로 질문하면 AI는 그 방향의 장점만 정리해 준다며 'AI는 내 편향을 교정해주기보다 세련된 언어로 내 편향을 포장해줄 뿐이다'라고 쓴 대목은, AI와 함께 결정을 내려 본 사람이라면 뜨끔할 지점이다.

마지막 장에서 저자는 커리어를 무엇을 만들 수 있는가, 무엇을 판단할 수 있는가, 판단의 구조를 만들 수 있는가 세 단계로 정리한다. AI 시대에 첫 단계는 급격히 압축되었지만 나머지 둘은 여전히 사람의 몫이다. 앞서 저자가 판단의 대상을 코드, 설계, 제품, 조직 네 레벨로 나누며 '레벨은 대체가 아니라 누적이다'라고 했던 것처럼, 이 세 단계도 앞 단계를 버리고 올라가는 계단이라기보다 그 위에 쌓아 가는 것으로 읽혔다.

변하지 않는 판단의 기준

저자는 에필로그에서 책 전체를 '큰 돌을 먼저 넣어라'로 요약한다. 구현보다 판단이 먼저고, 코드보다 기준이 먼저라는 말이다. 기술은 계속 바뀌지만 결정의 무게를 가르고 운영을 먼저 떠올리는 습관은 남는다는 것, 결국 이 책이 AI 시대의 개발자에게 건네는 것은 그런 변하지 않는 기준이다. 저자 자신의 틀렸던 판단이 솔직하게 실려 있어 읽는 내내 남의 일 같지 않았고 마이크로 ADR이나 판단 로그, 3문 리뷰처럼 장마다 바로 써 볼 수 있는 양식이 붙어 있어 실무로 옮기기도 쉽다. AI가 코드를 쏟아내는 걸 보며 막연한 불안을 느끼는 개발자, 혹은 AI와 함께 일하면서 그 안에서 자기 몫이 어디인지 설명하기 어려운 개발자에게 권하고 싶다. 나도 우선 지금 운영하는 서비스의 결정 기록 양식에 대안과 중단 조건 칸을 더하고 배포 전에 저자의 세 질문을 거치는 것부터 적용해 볼 생각이다.