샘플 본문

이 책을 펼친 개발자에게

이 책은 공포를 말하기 위해 쓰인 책이 아닙니다

이 책은 AI가 개발자를 대체한다고 겁주기 위해 쓰인 책이 아닙니다. 반대로 “개발자는 절대 사라지지 않는다”는 막연한 위로를 하기 위해 쓰인 책도 아닙니다. 이 책은 지금 이런 질문을 하는 개발자를 위한 책입니다.

앞으로 90일 동안 무엇을 바꾸면 다시 필요해질 수 있는가. 이 책을 다 읽었을 때 손에 남아야 할 것은 거창한 낙관론이 아닙니다. 지난 2주 동안 반복해서 처리한 업무 목록, AI가 초안을 만들 수 있는 일과 사람이 끝까지 책임져야 할 일의 구분, 그리고 앞으로 90일 동안 남길 산출물 하나입니다.

오래 버티는 것만으로는 충분하지 않습니다. 내 일이 어디에서 줄어들고, 어디에서 다시 비싸질 수 있는지 냉정하게 봐야 합니다. 그래야 다시 필요해질 수 있습니다.

프롤로그

개발자는 회사를 얼마나 더 오래 다닐 수 있을까요?

AX TF 회의실에서 임원이 말했다.

“각 팀에서 AI로 줄일 수 있는 반복 업무를 이번 주 안에 정리해 주세요. 단순히 사례를 모으는 데 그치지 말고, 실제로 업무의 몇 퍼센트를 줄일 수 있는지도 함께 정리해 주시기 바랍니다.”

회의실이 순간 조용해졌습니다. 사람 이름은 나오지 않았습니다. 대신 업무 이름들이 테이블 위에 빠르게 쌓여갔습니다. 반복 운영 대응, 신규 기능 기술 검토, 테스트 시나리오 작성, 일정 리스크 분석, 유관 부서 협의 요약, 운영 영향 검토.

나는 그 자리에 앉아 있었습니다. 20년 넘게 소프트웨어 개발 현장을 겪었고, 현재는 개발 조직 안에서 기술 기반 프로젝트와 AX 전환 과제를 조율하고 있습니다.

처음에는 솔직히 안도했습니다. 반나절 걸리던 보고서 초안과 기술 검토 자료가 한두 시간 만에 그럴듯한 형태로 나왔습니다. 여러 부서 의견을 넣으면 쟁점과 후속 과제를 빠르게 정리해 주었고, 신규 기능 검토 자료에도 요구사항, 리스크, 운영 영향을 제법 잘 뽑아냈습니다.

그런데 회의가 이어질수록 마음이 점점 무거워졌습니다.

“AI가 초안을 만든다면 고연차는 어디까지 검토해야 합니까?”
“업무의 상당 부분을 자동화할 수 있다면 다음 분기 역할과 인력 계획은 어떻게 해야 합니까?”

메모를 하다 손이 멈췄습니다. 회사는 사람을 줄이기 전에 먼저 일을 분해하고 있었습니다. AI는 그 속도를 무섭게 빠르게 만들고 있었습니다.

오랫동안 나는 성실함이 답이라고 믿었습니다. 요구사항이 바뀌면 밤을 새워 다시 맞췄고, 일정이 흔들리면 끝까지 조율했습니다. 그런데 지금 나는 개발 조직 안에서 그동안 해오던 일들을 잘게 쪼개 ‘AI가 할 수 있는 일’과 ‘사람이 끝까지 책임져야 하는 일’로 나누고 있었습니다.

AI가 만든 결과는 문장도 매끄럽고 표도 깔끔했습니다. 하지만 그대로 의사결정 자료로 올릴 수는 없었습니다. 어떤 내용은 회의 중 나온 의견일 뿐 확정된 결정이 아니었고, 어떤 리스크는 기술 문제가 아니라 운영 정책과 고객 영향이 복잡하게 얽힌 문제였습니다.

문장은 맞았지만, 맥락은 부족했습니다. 그때 필요한 사람은 AI를 더 빠르게 돌리는 사람이 아니었습니다.

“이건 이 상태로 진행하면 위험합니다.”

그 한마디를 할 수 있는 사람이었습니다. 결과를 빨리 만드는 능력보다, 결과를 끝까지 책임지는 판단력이 더 중요해지고 있었습니다.

이 책은 그 불편한 깨달음에서 시작합니다. 개발자는 사라지지 않습니다. 다만 AI 자동화가 진행될수록 같은 개발자라도 몸값은 크게 갈리고 있습니다. 반복적인 정리와 구현에만 머무는 역할은 점점 값을 잃고, AI 결과를 비즈니스와 운영 관점에서 검증하고 모호한 요구를 진짜 문제로 바꾸는 사람은 더 강한 위치를 차지하고 있습니다.

이 책은 이론서도, 공포서도, 위로서도 아닙니다. 개발 조직 안에서 AX 전환을 직접 겪고 있는 실무자가 현장에서 마주한 불편한 현실을, 후배들에게 솔직하게 남기는 생존 매뉴얼입니다.

Chapter 01.

개발자는 회사를 얼마나 더 오래 다닐 수 있을까

회의실 분위기는 밝았습니다.

“올해부터 전사적으로 AI 도구를 도입합니다. 반복 업무를 줄이고 생산성을 높이겠습니다. 팀별 개선 효과를 다음 달까지 정리해 주세요.”

말 자체는 틀리지 않았습니다. 문서 초안은 빨라졌고, 테스트 케이스 초안도 금방 나왔습니다. 장애 보고서 첫 문장도 쉽게 잡혔습니다. 회의록에서 액션 아이템을 뽑는 일도 수월해졌습니다.

처음에는 나도 고개를 끄덕였습니다. 반복 업무를 줄일 수 있다면 좋은 일입니다. 하루 종일 비슷한 보고서를 다듬거나 테스트 케이스를 복사해 붙여넣기 하거나 로그를 뒤져 요약하는 시간에서 벗어날 수 있다면 환영할 만한 일이었습니다.

그런데 회의가 끝나고 자리로 돌아가는 복도에서 이상한 감정이 따라붙었습니다.

좋은 일인데, 왜 이렇게 불안하지?

AI를 직접 써보니 그 감정이 더 선명해졌습니다. 편하고 빠릅니다. 어떤 일은 민망할 정도로 쉽게 끝납니다. 반나절 걸리던 기술 검토 자료가 한두 시간 만에 모양을 갖춥니다. 장애 보고서에 원인, 영향 범위, 후속 조치를 넣어 달라고 하면 제법 그럴듯한 표까지 나옵니다.

그 순간 개발자는 편해집니다. 그리고 동시에 불안해집니다. 내가 줄인 시간을 회사도 보고 있기 때문입니다.

내 업무가 빨라지는 장면을 나만 보는 것이 아닙니다. 회사도 봅니다. 그리고 조용히 다음 질문으로 넘어갑니다.

이 정도 속도가 가능하다면 사람을 더 뽑아야 할까?
지금 인원으로도 충분하지 않을까?
반복 업무가 줄었다면 팀 구조도 다시 볼 수 있지 않을까?

그래서 지금 개발자들이 진짜로 묻는 질문은 “AI를 어떻게 잘 쓸까?”가 아닙니다.

더 깊은 질문은 이것입니다.

앞으로도 나는 회사 안에서 필요한 사람일까?

이 장은 그 질문에서 시작합니다.

1. 이제 개발자들이 가장 많이 묻는 질문

몇 년 전까지만 해도 개발자들이 가장 많이 했던 질문은 성장에 관한 것이었습니다. 어떤 언어를 배워야 할까. 백엔드와 프론트엔드 중 어디가 더 유리할까. 이직하면 연봉을 얼마나 올릴 수 있을까. 질문의 중심에는 늘 “어떻게 더 성장할 것인가?”가 있었습니다.

지금은 질문이 완전히 달라졌습니다.

개발자는 회사를 얼마나 더 오래 다닐 수 있을까?
AI가 코드를 이렇게 잘 쓰는데, 나는 앞으로도 필요할까?
40대 개발자는 이제 어디에 있어야 할까?

성장의 질문이 생존의 질문으로 바뀌고 있습니다. 개발자는 원래 변화에 익숙합니다. 새로운 언어, 프레임워크, 클라우드, 개발 방법론이 계속 바뀌어도 적응해 왔습니다. 그래서 이번에도 그저 새로운 도구가 하나 추가된 것이라고 생각하고 싶은 마음이 큽니다.

하지만 이번 변화는 이전과 다릅니다. 단순히 도구를 배우는 문제가 아니라, 개발자의 역할 가격 자체가 다시 매겨지고 있기 때문입니다.

예전에는 코드를 얼마나 잘, 얼마나 많이 쓰는지가 핵심이었습니다. 지금도 코딩 능력은 중요합니다. 다만 회사가 더 높은 값을 매기는 지점이 이동하고 있습니다.

AI가 만든 코드에서 빠진 권한 체크를 찾아냈는가. 배포 전에 롤백 기준을 제대로 세웠는가. 장애가 났을 때 어떤 로그부터 확인해야 하는지 정리했는가. 모호한 요구를 실제 고객 문제와 운영 영향으로 다시 정의했는가.

개발자는 사라지지 않습니다. 다만 모든 개발자가 같은 방식으로 남지는 않습니다. 어떤 개발자의 일은 점점 줄어듭니다. 어떤 개발자의 역할은 더 비싸집니다. 이 차이를 만드는 기준을 아는 것이 이 책의 출발점입니다.

2. 왜 회사는 채용보다 AI 도입을 먼저 검토하는가

예전에는 일이 늘어나면 사람을 뽑았습니다. 프로젝트가 생기면 채용 공고를 냈고, 업무가 늘어나면 팀을 키웠습니다. 일정이 빠듯하면 외주나 계약직을 충원했습니다.

지금은 순서가 바뀌었습니다. 회의에서 먼저 나오는 질문은 대개 이쪽입니다.

AI로 줄일 수 있나?
기존 인원으로 감당할 수 있나?
그래도 안 되면 그때 뽑으면 되지 않나?

채용이 기본값이던 시대에서, 채용이 마지막 선택지가 되는 시대로 이동하고 있습니다.

개발자 한 명의 비용은 결코 작지 않습니다. 특히 고연차일수록 장비, 복지, 교육, 관리 비용까지 합치면 부담이 큽니다. 반면 AI 도구는 도입이 빠르고 비용 예측도 쉽습니다.

회사가 처음부터 사람을 전부 없애겠다고 생각하는 것은 아닙니다. 회사가 먼저 보는 것은 얼마나 줄일 수 있는가입니다. 20퍼센트만 줄어도 인력 계획은 바뀝니다.

한 팀이 AI를 도입해 테스트 케이스 작성 시간과 장애 보고서 정리 시간을 크게 줄였다고 보고했습니다. 처음에는 생산성 개선 사례로 칭찬을 받았습니다. 팀장은 전사 공유까지 제안받았습니다.

그런데 다음 분기 회의에서 질문이 달라졌습니다.

다른 팀은 왜 아직 못 줄였나?
이 정도면 신규 채용은 보류해도 되지 않나?
이 업무는 앞으로도 사람이 직접 해야 하나?

칭찬으로 시작했던 숫자가 인력 재편의 근거로 바뀌는 데는 오래 걸리지 않았습니다.

이제 가장 위험한 사람은 AI를 모르는 사람이 아닙니다. 자신의 일이 어떻게 분해되고 있는지 모르는 사람입니다. “나는 코드를 씁니다”만으로는 부족합니다. 이제는 이렇게 말할 수 있어야 합니다.

AI로 초안을 만들 수 있는 일은 여기까지입니다. 하지만 배포 전 권한 체크, 롤백 기준, 운영 영향은 사람이 끝까지 봐야 합니다. 저는 그 기준을 만들어 팀에 남길 수 있습니다.

3. 생산성 압박은 이미 시작됐다

생산성 압박은 거친 말로 시작되지 않습니다. 아주 부드러운 말로 시작됩니다.

AI 좋은 사례를 공유해 주세요.
팀별 개선 효과를 정리해 주세요.
반복 업무를 줄일 수 있는 항목을 찾아보세요.

처음에는 실험처럼 보입니다. 하지만 숫자가 쌓이면 분위기가 달라집니다. 어떤 팀은 테스트 시간을 줄였고, 어떤 팀은 같은 인원으로 배포 횟수를 늘렸습니다. 어떤 팀은 장애 보고서를 빠르게 정리했습니다.

그러면 회사는 곧바로 비교를 시작합니다.

다른 팀은 왜 못 하는가?
다음 분기에는 얼마나 더 줄일 수 있는가?
신규 채용이 정말 필요한가?

같은 AI를 써도 남는 것이 다릅니다. 어떤 사람은 AI를 코드 생성기로만 씁니다. 요구사항을 넣고 초안을 받고, 조금 고쳐서 제출합니다.

어떤 사람은 AI를 써서 팀의 반복 업무를 찾아냅니다. 테스트 케이스 작성 방식을 바꾸고, 코드 리뷰 체크리스트를 만들고, 장애 로그 분석 순서를 정리하고, 후배가 같은 질문을 반복하지 않도록 온보딩 자료를 고칩니다.

몇 달 뒤 성과 회의에서 이름이 다시 나오는 사람은 보통 후자입니다.

4. 평가는 조용히 바뀌고 있다

회사는 평가 기준을 바꿀 때 공식 발표를 하지 않습니다. 대신 승진하는 사람의 유형이 바뀌고, 회의에서 강조되는 성과의 종류가 달라집니다.

예전에는 일정을 지키고, 장애가 나면 밤을 새우고, 요구사항이 바뀌어도 끝까지 맞춰주는 사람이 좋은 평가를 받았습니다. 지금도 그런 태도는 중요합니다. 하지만 그것만으로는 부족해졌습니다.

이제 더 높게 평가받는 것은 다음과 같은 사람입니다.

AI가 결과를 빠르게 만들수록, 그 결과를 끝까지 판단하고 책임지는 사람의 가치가 올라갑니다. 개발자의 가격표는 코드 작성량보다 판단하고 기준을 남기는 쪽으로 조금씩 옮겨가고 있습니다.

5. 불안은 착각이 아니라 시장 신호다

불안을 느끼는 개발자는 대부분 자신부터 의심합니다. 내가 너무 예민한가. 내가 공부를 덜 했나. 내가 나이가 많아져서 그런가.

하지만 지금의 불안은 개인의 문제만은 아닙니다. 시장이 보내는 신호입니다. 채용 문이 좁아지고, AI 전환 TF가 만들어지고, 팀별 생산성 숫자를 요구하는 움직임이 늘고 있습니다. 회사가 개발자의 가격을 다시 계산하고 있다는 분명한 신호입니다.

불안을 느끼는 것은 이상한 일이 아닙니다. 아무 불안도 느끼지 못하는 것이 더 위험합니다. 문제는 불안을 느끼느냐가 아니라, 그 불안을 어떻게 보느냐입니다.

불안을 공포로만 보면 움직이지 못합니다. 시장 신호로 보면 전략을 세울 수 있습니다. 이제 질문은 바뀌어야 합니다.

“얼마나 더 버틸 수 있을까?”가 아니라
“나는 어떤 개발자가 되어야 계속 필요해질까?”로.

이제 질문은 바뀐다

개발자는 사라지는 직업이 아니라 재정의되는 직업입니다. 코드를 쓰는 사람에서 문제를 해결하는 사람으로, 혼자 빠르게 일하는 사람에서 팀의 반복을 줄이는 사람으로, 기술만 아는 사람에서 AI와 조직과 비즈니스를 연결하는 사람으로 이동해야 합니다.

AI 시대에 오래 살아남는 개발자는 일을 많이 떠안는 사람이 아닙니다. 어떤 일은 과감히 줄이고, 어떤 일은 자동화하고, 어떤 일은 사람이 끝까지 책임져야 하는지 구분할 수 있는 사람입니다. 그리고 그 구분을 팀 안에 기준으로 남기는 사람입니다.

앞으로의 개발자는 더 많은 일을 떠안는 사람이 아니라, 일의 구조를 다시 설계하는 사람이 되어야 합니다.