AI가 IT 업계에서 수천 개의 일자리를 대체하고 있다는 이야기가 요즘 커리어 커뮤니티 곳곳에서 회자된다. 실제로 빅테크 기업들이 채용 규모를 줄이거나 특정 직군의 헤드카운트를 조정했다는 뉴스는 꾸준히 나오고 있다. 그러나 이 이야기에는 맥락이 필요하다. AI가 모든 개발자를 대체하는 게 아니라, AI를 다루지 못하는 개발자와 AI를 활용하는 개발자 사이의 격차가 벌어지고 있는 것이다. 지금 이 시점에서 개발자가 어떻게 자신을 단단하게 만들 수 있는지, 구체적으로 살펴본다.
AI가 실제로 무엇을 바꾸고 있는가
현재 AI가 가장 빠르게 대체하고 있는 영역은 반복성이 높고 명세가 명확한 코딩 작업이다. 주어진 API 스펙에 맞춰 CRUD 코드를 작성하거나, 정형화된 테스트 케이스를 생성하거나, 문서 초안을 만드는 일이 여기에 해당한다. 이런 작업들은 이미 GitHub Copilot이나 Cursor 같은 도구가 상당 부분 처리하고 있으며, 숙련된 개발자가 하루에 처리하던 분량을 몇 시간 안에 초안 수준으로 완성해낸다.
반면 AI가 아직 잘 하지 못하는 영역이 있다. 도메인 지식이 깊이 얽혀 있는 설계 결정, 비즈니스 요구사항을 기술 사양으로 변환하는 과정, 레거시 시스템과 신규 기능의 절충점을 조율하는 협업, 보안과 성능 사이에서 우선순위를 정하는 판단이 그것이다. 이런 작업들은 기술적 역량과 비즈니스 이해, 그리고 조직 맥락이 함께 필요하기 때문에 단순한 코드 생성으로 대체되지 않는다.
결론적으로, AI는 코딩의 생산성을 끌어올리면서 개발자 한 명이 커버할 수 있는 범위를 확장시켰다. 기업 입장에서는 같은 산출물을 더 적은 인원으로 만들 수 있다는 뜻이고, 이것이 일자리 감소 뉴스의 실질적인 원인이다. 하지만 동시에, AI를 잘 다루는 개발자의 가치는 이전보다 높아졌다.
AI 도구를 ‘사용하는 것’과 ‘활용하는 것’의 차이
AI 코딩 도구를 써본 적이 있다는 것과, 그 도구를 실질적인 업무 속도 향상으로 연결하는 것은 전혀 다른 수준의 역량이다. 많은 개발자들이 Copilot을 설치하고 자동완성 제안을 수락하거나 거부하는 수준에서 멈춘다. 이 정도는 편의 기능을 쓰는 것이지, AI를 협업 도구로 활용하는 게 아니다.
AI를 잘 활용하는 개발자는 프롬프트를 설계하는 능력이 있다. 모호한 요청 대신 ‘이 함수는 Python 3.11 기준, 인자로 dict를 받아 특정 키가 없으면 ValueError를 던지고, 정상일 때는 가공된 값을 반환한다. 엣지 케이스 테스트 세 가지를 포함해서 작성해줘’처럼 구체적인 맥락과 제약을 제시한다. 이렇게 하면 AI가 생성하는 코드의 품질이 달라지고, 검토·수정에 드는 시간이 줄어든다.
또한 AI가 틀릴 수 있다는 것을 전제로 작업한다. AI가 생성한 코드를 맹목적으로 복붙하지 않고, 자신이 이해하는 범위에서만 채택하며, 이해가 안 되는 부분은 반드시 검증하는 습관을 갖추고 있다. 이 습관이 없으면 AI는 생산성을 높이는 도구가 아니라 버그를 빠르게 심는 도구가 된다.
지금 당장 키울 수 있는 역량 세 가지
AI 시대에 개발자로서 단단해지고 싶다면, 추상적인 ‘소프트 스킬’이 아니라 지금 바로 작업에 적용 가능한 역량을 키워야 한다. 아래 세 가지는 실제로 현업에서 차별점을 만드는 항목들이다.
- 시스템 설계 감각: 개별 기능 구현보다 전체 아키텍처를 이해하고 설명할 수 있는 능력. AI는 파일 하나를 잘 짜줄 수 있지만, 서비스 전체에서 어떤 방향으로 구조를 잡아야 하는지는 개발자의 판단이다. 실제 오픈소스 프로젝트를 읽으며 설계 결정의 이유를 추적하는 것이 가장 빠른 훈련이다.
- 커뮤니케이션과 요구사항 정제 능력: 기획자나 클라이언트가 ‘이런 기능이 필요하다’고 막연하게 말할 때, 구체적인 질문을 통해 명세를 명확하게 만드는 능력. 이 능력이 있으면 AI에게 더 좋은 프롬프트를 줄 수 있고, 팀 내에서도 불필요한 재작업을 줄일 수 있다.
- 코드 리뷰 역량: AI가 생성한 코드든, 동료가 작성한 코드든, 빠르게 읽고 문제를 짚어내는 능력. 이 역량은 오래 코드를 직접 쓰면서만 쌓인다. AI에 의존해 코드를 적게 쓰면 이 능력이 둔해지므로, 의도적으로 직접 작성하는 시간을 유지해야 한다.
포트폴리오와 이력서: AI 시대에 무엇이 달라졌는가
채용 시장에서 지원자들의 평균적인 코딩 결과물 수준이 올라가고 있다. AI 도움을 받으면 예전보다 훨씬 완성도 있는 프로젝트를 만들 수 있기 때문이다. 역설적으로, 이것이 포트폴리오 경쟁을 더 어렵게 만들었다. 단순히 ‘이런 걸 만들었다’가 아니라, ‘이 과정에서 어떤 판단을 했고, 왜 그렇게 했는가’를 설명할 수 있어야 한다.
면접에서도 마찬가지다. 코딩 테스트를 통과하는 것은 AI 도구의 보조로 이전보다 쉬워졌다고 볼 수 있지만, 시스템 설계 인터뷰나 기술 면접에서 ‘이 코드의 시간 복잡도를 설명하라’, ‘이 구조에서 병목이 발생한다면 어떻게 개선하겠는가’라는 질문에는 본인이 직접 답해야 한다. 면접관들도 AI 보조 결과물을 걸러내는 방향으로 질문 방식을 바꾸고 있다.
포트폴리오를 준비할 때는 기술 스택 나열보다 문제 해결 서사를 만드는 것이 효과적이다. 어떤 문제를 발견했는지, 처음에 어떤 접근을 시도했고 왜 그 방법이 부족했는지, 최종적으로 어떻게 해결했는지를 논리적으로 서술할 수 있어야 한다. 이 서사는 AI가 대신 써줄 수 없고, 오직 본인이 직접 겪어야만 갖출 수 있다.
경력 로드맵: 지금 어느 단계라면 무엇을 해야 하는가
단계별로 구체적인 행동 방향이 달라진다. 현재 자신의 위치를 먼저 확인하고, 해당하는 전략을 따르는 것이 현실적이다.
입문·주니어(0~2년차): AI 도구를 쓰되, 반드시 스스로 이해하고 재현할 수 있는 코드만 포트폴리오에 넣는다. 자료구조, 알고리즘, 네트워크 기초는 AI가 있어도 직접 공부해야 한다. 이 시기에 기초를 AI에 위탁하면 나중에 큰 구멍이 생긴다. 한 가지 언어와 스택을 깊게 파는 것이 여러 스택을 얕게 아는 것보다 낫다.
미드레벨(3~5년차): 설계 역량을 의도적으로 키워야 하는 시기다. 혼자 CRUD를 만드는 것에서 벗어나, 팀 내 코드 리뷰에 적극 참여하고 레거시 코드를 읽고 개선하는 경험을 쌓아야 한다. AI를 써서 생산성을 높인 시간을 시스템 설계 학습에 투자하는 것이 이 시기의 핵심 전략이다.
시니어·이직 준비 중: 포지션 선택의 방향이 중요하다. 단순 개발보다 기술 리더십, 아키텍처 설계, 개발-비즈니스 간 번역 역할로 이동하는 것이 AI 대체 위험을 낮추는 방향이다. 이직 전에 본인의 설계 경험과 팀 기여 사례를 정리하고, 숫자로 설명 가능한 임팩트(개선 전후 성능 비교, 배포 빈도 변화 등)를 준비한다.
번아웃과 불안: AI 고용 위기 뉴스를 소비하는 방식
IT 일자리 수천 개가 없어질 것이라는 뉴스는 실제로 불안을 유발한다. 그러나 이런 기사를 매일 소비하는 것 자체가 생산적이지 않다. 구조적인 변화에 대해 한 번 파악하고 나면, 그 다음은 자신의 역량 개발에 집중하는 것이 훨씬 합리적인 대응이다.
채용 시장은 항상 변했다. 모바일이 나왔을 때도, 클라우드가 나왔을 때도, 비슷한 ‘대체’ 이야기가 있었다. 그 과정에서 사라진 역할도 있었지만, 새로운 역할이 더 많이 생겼다. AI 역시 마찬가지일 가능성이 높다. 다만 변화의 속도가 빠르기 때문에, 이에 적응하는 속도도 빠를수록 유리하다는 점은 분명하다.
불안을 관리하는 실용적인 방법은 비교를 줄이고 자신의 학습 진도를 측정하는 것이다. 6개월 전보다 지금 더 잘 설계하고 더 빠르게 디버깅할 수 있는가. 이 질문에 ‘그렇다’고 답할 수 있다면, 올바른 방향으로 가고 있는 것이다.
지금 이 시점, 혼자 하지 않아도 된다
AI 고용충격이라는 말이 주는 두려움은 혼자 앞에 놓고 보면 더 크게 느껴진다. 하지만 같은 고민을 하는 동료들, 이미 변화의 파고를 넘어온 선배 개발자들과 이야기를 나누면 훨씬 구체적인 방향이 보인다. 누스쿨 커뮤니티에는 다양한 경력 단계의 개발자들이 있고, 커리어 고민을 함께 나누는 멘토링 프로그램도 운영 중이다. 이력서와 포트폴리오를 한 번 다듬고 싶다면, 또는 이직 방향에 대해 현업 멘토의 의견이 필요하다면, 지금 한 번 들어와보길 권한다.
💬 댓글 0