안녕하세요, 토스 Node.js Developer 정세훈입니다.

요즘 너무나 많은 분들이 고민하고, 토론하고 계신 주제가 바로 ‘개발자는 과연 AI에게 대체될 것인가?’라는 질문이죠. 아무도 이 질문에 쉽게 대답하진 못하지만, 개발자로서 마냥 모른척 하기도 어렵습니다. 저 또한 마찬가지였는데요. 여러 뉴스나 사례, 연구를 보면서 생각이 어느정도 정리되어 글로 써봤습니다.

저의 개인적인 생각이니 가볍게 읽어주시길 바라며, 댓글로 여러분의 생각을 공유해 주시면 더 좋을 것 같습니다.

우리는 버블을 보고 있습니다

아마라의 법칙(Amara's law)이 있습니다.

"기술의 효과는 단기적으로 과대평가되고, 장기적으로 과소평가되는 경향이 있다."

우리는 개발자로서 AI 하이프가 생기는 모든 과정을 직접 겪었습니다. 그리고 지금, 버블의 한가운데 서 있습니다.

숫자가 증명합니다. Magnificent 7이 2024~2025년 2년간 AI 관련 설비투자로 5,600억 달러를 쏟아 부었습니다. 그 결과 만들어진 AI 관련 매출은 고작 350억 달러. 16:1의 불균형입니다.[1] MIT Media Lab 조사에 따르면 생성형 AI 도입의 95%가 실패했고, Atlassian 조사에서도 96%가 뚜렷한 효율 개선을 보지 못했습니다.[2]

Microsoft의 AI 관련 연환산 매출 130억 달러 중 77%는 OpenAI가 Azure를 사용하는 데서 발생한 내부거래입니다.[3] 생성형 AI는 실질 수익도, 명확한 수요도, 지속 가능한 비즈니스 모델도 없이 NVIDIA GPU 판매와 빅테크 내부거래에 기대어 유지되고 있습니다.

AI 붐의 비용은 인력 감축으로 전가되고 있습니다. Amazon CEO Andy Jassy는 감원이 "AI 때문이 아니다"라고 명시했지만, AI 투자 비용을 어딘가에서 메워야 하는 건 사실입니다.[4] AI가 일자리를 대체하는 게 아니라, AI 지출이 일자리를 대체하고 있는 셈입니다.

버블입니다.

그러나 안심할 수 없습니다

1995년에도 닷컴 버블이 있었습니다. 문제는 버블이 꺼진 뒤에도 인터넷은 사라지지 않았다는 겁니다. "웹마스터"라는 직업은 사라졌지만, 웹 관련 일자리는 폭발적으로 늘었습니다.

AI 혁명은 지금 1995년 인터넷의 전화 접속 단계에 있습니다.[5] 버블과 과열, 과소평가가 뒤섞인 혼란기입니다. 하지만 단기적 실패와 과잉투자와 별개로, 하이퍼스케일러의 인프라 투자가 장기적으로 AI 경제의 기반을 깔고 있습니다.

제번스 패러독스를 떠올려봅시다.[6] 에어컨 본체처럼 생산성이 폭발적으로 향상된 영역은 가격이 급락하면서도 수요와 활용처, 관련 일자리가 기하급수적으로 늘어납니다. AI로 코딩이 쉬워지면 더 많은 사람이 코딩을 하게 되고, 더 많은 소프트웨어가 필요해질 것입니다.

John Carmack은 이렇게 말했습니다.[7] 기술 발전은 개발과 그래픽, 엔지니어링 작업을 ‘파워 툴’로 대체해 온 역사적 연속선상에 있으며, AI 역시 기존 숙련을 폄하하기보다는 더 많은 사람이 만들고 실험하게 하는 도구라고요. 게임 엔진이 그랬듯 AI 도구는 소규모 팀에게 프로급 역량을 열어주고, 상위 실력자의 생산성과 퀄리티를 동시에 끌어올릴 것입니다.

GitHub CEO는 자신의 다음 직함이 ‘코드 크리에이티브 디렉터’가 될 거라고 말했습니다.[8] 개발자로서의 정체성이 변했다는 겁니다. 더 이상 코드 생산이 아니라, 시스템 설계와 에이전트 지휘, 결과 검증이 중심이 되고 있습니다.

AI 기술은 고임금 전문직 근로자에게 광범위하게 영향을 미치는 최초의 자동화 혁명이다.

10년 후 소프트웨어 엔지니어의 의미는 지금과 완전히 달라져 있을 것입니다.

질문을 바꿔야 합니다

그렇다면 "AI가 개발자를 대체할까?"라는 이분법적 질문은 잘못된 프레임입니다. 더 본질적인 질문은 이것입니다.

개발자라는 직업은 어떻게 재정의될까?

사실 개발자로서의 저는 점차 대체되어 가고 있다고 생각합니다. 좀 더 정확히 말하자면, 우리가 머릿속에 그리고 있는 ‘개발자’라는 직업이 무엇을 해야 하는지에 대한 정의가 매우 유동적이고 빠르게 변하고 있습니다.

왜냐하면 개발자란 직업은 나눌 수 없는 하나의 개체가 아니기 때문입니다. 코드 작성, 코드 리뷰, 이슈 관리, 멘토링, 기술 검토, 장애 대응, 모니터링, 온콜, 플랫폼 기여, 채용 인터뷰, 문서화, 지식 전파, 레거시 정리, 리팩토링, 성능 개선... ‘개발자’라는 직책은 이름일 뿐이고, 일상적인 업무는 이렇게 다양한 일들로 이루어져 있습니다.

이러한 다양한 업무들이 점진적으로 AI에게 위임된다고 해서 개발자라는 직업이 사라지는 것은 아닙니다. 그렇다면 무엇이 대체되고, 무엇이 남을까요?

위임의 4분면

이 질문에 답하기 위해 두 개의 축을 그려봅시다.

각 사분면을 살펴보겠습니다.

‘위임하기 어려운 것’은 근본적인 구분이 아닙니다

그런데 잠깐. ‘위임하기 어려운 것’이라는 축은 정말 본질적인 구분일까요?

우리는 지난 2년간 이 축을 이동시키기 위해 엄청난 노력을 해왔습니다. 프롬프트 엔지니어링으로 더 정교한 지시를 내리고, RAG로 더 많은 컨텍스트를 주입하고, 에이전트 플랫폼으로 복잡한 워크플로우를 자동화했습니다. 암묵지를 명시지로 끌어내는 작업에 수 개월을 투자했죠.

그리고 어느 날 새로운 모델이 나왔습니다.

GPT-5가 나오자 GPT-4를 위해 만든 정교한 프롬프트들이 오히려 성능을 떨어뜨렸습니다. Claude Opus가 나오자 이전 버전을 위해 구축한 RAG 파이프라인의 청킹 전략이 무의미해졌습니다. 우리가 ‘위임하기 어려운 것’을 ‘위임하기 쉬운 것’으로 만들기 위해 쌓아올린 인프라가, 모델 한 번 업데이트에 허사가 되는 경험을 반복했습니다.

더 많은 컨텍스트, 더 많은 세부사항 주입, 암묵지를 명시지로 끌어내는 노력—이것들은 본질적이지 않습니다. ‘위임하기 어려운 것’은 고정된 속성이 아니라, 기술 발전에 따라 계속 이동하는 일시적인 경계일 뿐입니다.

남는 축은 하나입니다

결국 본질적인 구분은 하나 뿐입니다.

위임해야 하는 것 ◀────────────────────▶ 위임하면 안되는 것

"위임하기 쉬운가, 어려운가"는 시간이 해결합니다. 하지만 "위임해야 하는가, 하면 안 되는가"는 우리가 결정해야 합니다.

흥미로운 건, "직접 하기 싫은 것"과 "위임해야 하는 것"이 대부분 겹친다는 점입니다. 그리고 "직접 하고 싶은 것"과 "위임하면 안 되는 것"도 상당 부분 겹칩니다.

위임해야 하는 것과 하면 안 되는 것의 구분은 더 본질적입니다. 장기적으로 이것은 인간이 AI와 함께 나아가면서 어떤 역할과 책임만을 남길 것인가 하는 문제이기도 합니다.

AI 위임은 곧 업무 추상화입니다

역할과 책임이라는 말을 들으니, 개발자로서 떠오르는 개념이 있습니다. 바로 추상화입니다.

AI에게 특정 역할을 위임한다는 것은 결국 업무를 추상화하는 행위입니다.

우리는 추상화를 ‘공통된 속성을 뽑아내는 것’ 혹은 ‘복잡성을 숨기는 것’이라고 배웠습니다. 하지만 추상화의 본질은 몰라도 되는 세부 사항을 고르는 행위입니다. 즉, 무엇을 더 이상 신경 쓰지 않을 것인가에 대한 판단 과정입니다.

코드로 표현하면 이렇습니다.

type 개발업무 =
  | { type: '버그수정', 난이도: 'easy' | 'hard' }
  | { type: '기능추가', 요구사항: string }
  | { type: '아키텍처결정', 선택지: string[] }
  | { type: '정책변경', 이해관계자: string[] }
  | { type: '레거시리팩토링', 영향범위: 'local' | 'global' };

function AI에게_업무위임(업무: 개발업무): void {
  // AI가 처리 가능한 것 (잘 정의된 문제)
  if (업무.type === '버그수정' && 업무.난이도 === 'easy') {
    AI.수정요청(업무);
    return;
  }

  if (업무.type === '기능추가' && 요구사항이_명확함(업무.요구사항)) {
    AI.구현요청(업무);
    return;
  }

  // 인간의 판단이 필요한 것들
  if (업무.type === '아키텍처결정' ||
      업무.type === '정책변경' ||
      업무.type === '레거시리팩토링') {
    throw new Error("시니어 개발자의 판단 필요");
  }
}

이것은 프로그래밍에서의 type guard 혹은 assertion을 작성하는 것과 같습니다. "이 문제는 AI가 처리할 수 있다"는 가정을 코드로 작성하는 겁니다.

AI에게 맡긴다 = 이 부분은 더 이상 신경 쓰지 않겠다

추상화는 미래에 대한 예측입니다

하지만 추상화는 본질적으로 미래에 대한 예측입니다. 마치 주식이나 파생상품과 비슷한 성질이 있습니다.

추상화는 복잡성을 없애는 게 아니라, 복잡성을 미래로 이동시키는 것입니다. 불확실성에 대한 레버리지입니다.

프로그래밍계에는 "성급한 추상화는 피해야 한다"는 격언이 있습니다. 왜 피해야 할까요? 그 추상화가 잘못되었기 때문입니다. 잘못된 추상화는 결국 더 안 좋은 결과를 가져옵니다.

우리가 "이건 앞으로 신경 쓰지 말자"고 합의한 세부 사항이, 상황이 변함에 따라 예외를 맞닥뜨렸을 때 추상화가 깨지기 시작합니다.

/**
 * AI에게 위임한 "간단한 CRUD API" 개발
 * 6개월 전에는 이렇게 추상화했습니다
 */
const 초기_가정 = [
  '사용자 수 1000명 이하',
  '단일 리전 서비스',
  '개인정보 최소 수집',
  '모든 외부 API 안정적',
];

/**
 * 6개월 후... 추상화가 깨지는 순간들
 */
const 예상치_못한_상황들 = {
  트래픽_급증: {
    문제: 'DB 커넥션 풀 고갈, 메모리 부족',
    AI_한계: '성능 프로파일링, 병목 지점 분석, 아키텍처 재설계',
    필요한_것: '시니어의 시스템 설계 경험'
  },

  GDPR_개정: {
    문제: '개인정보 처리 방침 전면 수정',
    AI_한계: '법률 해석, 비즈니스 영향도 분석, 이해관계자 조율',
    필요한_것: 'Legal팀, PM, 경영진과의 협의'
  },

  보안취약점_발견: {
    문제: '사용 중인 라이브러리에 제로데이 취약점',
    AI_한계: '영향 범위 분석, 긴급 패치 우선순위, 리스크 평가',
    필요한_것: '보안팀, 인프라팀과의 긴급 대응 체계'
  },
};

마치 서브프라임 모기지처럼 누적된 추상화가 한 번에 무너지기 시작할 때, 근본이 흔들리기 시작할 때, 한 번에 무너져 내리는 재앙을 맞닥뜨리기도 합니다.

혹은 여러 개로 쌓인 추상화의 중간 다리에서 고장이 났을 때, 우리는 이를 감수하고 계속 업무에 활용하긴 하지만, 이것은 추상화가 아예 없었을 때보다 훨씬 더 고통스럽고 고된 작업이 됩니다.

잘못된 추상화는 추상화가 없는 것보다 더 나쁩니다.

추상화가 깨졌을 때의 선택지

const 개발팀의_선택 = [
  {
    선택: 'AI 프롬프트 고도화',
    의미: '추상화 확장 - AI에게 더 많은 컨텍스트 제공',
    리스크: 'AI는 여전히 판단이 필요한 상황은 못 함'
  },
  {
    선택: '개발자가 모든 것 검토',
    의미: '추상화 포기 - AI 결과물 전수 검사',
    리스크: 'AI 사용 이점 상실, 결국 직접 작성하는 것과 동일'
  },
  {
    선택: '업무 추상화 리팩토링',
    의미: '어떤 것을 AI에게 맡길지 재정의',
    예시: [
      '✅ AI에게: 보일러플레이트 코드, 단순 CRUD, 테스트 케이스',
      '❌ AI에게: 아키텍처 결정, 보안 정책, 법규 대응',
      '⚠️ 협업: 코드 리뷰, 리팩토링 제안, 문서화'
    ]
  }
];

좋은 추상화란 무엇인가

그렇다면 좋은 추상화의 예시는 무엇일까요? UNIX 철학과 커맨드라인 도구를 들 수 있습니다.

AI에게 위임하기 좋은 업무는 다음을 갖춰야 합니다.

ls | grep .ts | wc -l처럼, 각각의 도구가 자기 역할만 하고, 파이프로 연결되어 복잡한 작업을 수행하는 것. AI에게 위임하는 업무도 이와 같아야 합니다.

반대로 나쁜 추상화는 어떤 것일까요? 경계가 모호하고, 예외가 많고, 컨텍스트에 의존하는 업무입니다. "알아서 잘 처리해줘"라는 위임은 반드시 실패합니다.

좋은 추상화를 다루는 태도

흥미로운 현상이 있습니다. 경험 많은 시니어 엔지니어일수록 오히려 ‘하위 레벨’을 계속 학습합니다. 프레임워크를 쓰면서도 그 아래의 HTTP를 공부하고, ORM을 쓰면서도 SQL을 깊이 파고, AI 에이전트를 활용하면서도 프롬프트가 어떻게 처리되는지 이해하려 하죠.

이것은 오래된 기술에 대한 향수가 아닙니다. 추상화가 깨지는 순간에 대한 존중입니다. 새벽 3시, 장애가 터지고, 추상화 레이어가 무너지고, 문서에 없는 에러가 발생했을 때 — 결국 시스템과 홀로 마주해야 하는 건 AI가 아닌 사람입니다.

좋은 추상화란 그 아래를 몰라도 되게 해주는 것입니다. 하지만 좋은 엔지니어란 자신이 어떤 복잡성 위에 서 있는지 알면서, 그럼에도 신경 쓰지 않기로 선택하는 사람입니다. 이들은 추상화를 신뢰하되, 그것이 어떻게 실패할 수 있는지에 대한 모델을 머릿속에 유지합니다. 모든 세부사항을 아는 게 아니라, 기본적인 실패 모드에 대한 작동 모델을 갖고 있는 것입니다.

우리가 해야 할 것

이 모든 것이 복잡하게 느껴지고 압도된다면, 더 단순하게 생각해봅시다. 앞서 말한 위임의 4분면을 다음처럼 바꿔볼 수 있습니다.

"하기 쉬운가, 어려운가"는 성장하면서 이동하는 축입니다. 주니어가 시니어로 성장하면서 더 많은 것들이 쉬워집니다.

본질적인 건 지향입니다. 무엇을 내려놓고 싶어하고, 무엇을 붙잡고 싶어하는가. AI 리터러시란 결국 이것입니다.

더 높은 층위의 사고를 요구하는 일을 "하고 싶은 것"으로 만드는 능력, 인지적으로 단순하고 지루한 일들을 "하고 싶지 않다"는 것에 대한 집착

개인: 내려놓기와 붙잡기

어떤 작업을 마무리했다면, 두 가지 질문을 해봐야 합니다.

첫째, "이 작업을 AI에게 어떻게 맡길 수 있을까?" — 내려놓기의 질문입니다. 다음에 비슷한 작업이 있을 때, 조금 비효율적이더라도 AI에게 위임하는 실험을 해봐야 합니다.

둘째, "이 작업을 통해 내가 붙잡아야 할 것은 무엇이었나?" — 붙잡기의 질문입니다. AI가 대신할 수 없었던 판단, 맥락, 조율의 지점을 의식적으로 인식해야 합니다.

AI를 꾸준히 활용하다 보면 업무 경계의 모양이 보이기 시작합니다. 어디까지가 내려놓을 수 있는 영역이고, 어디부터가 내가 붙잡아야 할 영역인지.

회사와 팀: 추상화할 시간 확보

AI가 있다고 해서 더 많은 것을 달성할 수 있고, 더 많은 실험과 도전을 할 수 있다고 생각하는 것은 위험합니다. 그런 방식의 접근은 AI로 인지 부하를 줄여나간다는, 기존 업무를 올바른 방식으로 추상화한다는 전제가 있지 않은 한 지속 가능하지 않습니다.

개발자들이 프로젝트 중간에 리팩토링을 해야 한다고 시간을 달라고 할 때, 이것은 추상화의 레버리지가 흔들리기 시작하는 때입니다. 경험 많은 엔지니어링 리더는 이때를 감지하고 판단할 수 있는 능력이 뛰어납니다.

비슷하게, 지금 AI로 인해 우리의 업무가 빠른 속도로 추상화의 탑을 쌓고 있지만, 우리는 이 업무의 추상화를 어느 시점에서 리팩토링해야 하는지 아직 판단하는 경험치가 없습니다. 개개인의 수준에서 업무의 추상화가 이루어져야 하고, 회사와 팀은 그 추상화할 수 있는 시간과 자원을 지원해야 합니다.

플랫폼: 도구와 가드레일 제공

플랫폼은 업무를 추상화하기 위한 좋은 도구들과 가드레일을 제공해야 합니다. AI에게 가장 먼저 맡길 일을 고려할 때, 지루하고 정신적으로 소모적이며 반복적인 일을 찾아야 합니다.

이때 중요한 원칙이 있습니다.

Opinionated하면 안 됩니다. 플랫폼이 "AI는 이렇게 써야 한다"고 강제하는 순간, 개인의 추상화 실험이 막힙니다. 각자의 업무 경계는 다르고, 내려놓을 수 있는 영역도 다릅니다. 플랫폼은 방향을 정해주는 게 아니라, 개인이 자신만의 추상화를 설계할 자유도를 보장해야 합니다.

연결성과 조합 가능성을 최대한 제공해야 합니다. 앞서 말한 UNIX 철학처럼, 좋은 플랫폼은 단일 기능을 잘 수행하는 도구들이 서로 연결될 수 있게 합니다. MCP, 에이전트 파이프라인, API 연동—이 모든 것의 핵심은 "이 도구와 저 도구를 내 방식대로 조합할 수 있는가"입니다.

심리적, 물리적 안전망을 제공해야 합니다. AI는 본질적으로 비결정적입니다. 같은 입력에 다른 출력을 낼 수 있고, 개발자가 원하지 않는 변경을 수행할 수 있으며, 시스템에 악영향을 끼치는 코드를 실행할 수도 있습니다.

이런 것들을 우려하기 시작하면 실험 자체가 멈춥니다. "혹시 잘못되면 어쩌지?"라는 두려움이 "AI에게 맡겨볼까?"라는 시도를 막습니다. 결국 안전한 영역에만 머물게 되고, 추상화의 경계는 확장되지 않습니다.

그래서 플랫폼은 실패해도 괜찮은 환경을 만들어야 합니다. 되돌릴 수 있는 변경, 격리된 실행 환경, 명확한 diff와 승인 단계—이런 가드레일이 있어야 개발자가 두려움 없이 위임의 경계를 실험할 수 있습니다.

잘못된 접근 vs 올바른 접근

마지막으로 강조하고 싶은 것이 있습니다.

"AI를 사용해서 이만큼 빨리 했으니, 더 많은 일을 맡을 수 있겠다"는 접근은 잘못되었습니다.

AI가 인지 부하를 줄여주었다면, 남는 시간은 우리가 어떻게 하면 AI가 조금 더 나를 잘 대체하게 만들 수 있을지에 대한 고민에 써야 합니다.

❌ "AI로 빨리 했으니 더 많은 일들을 진행하자"
✅ "AI로 빨리 했으니 경계를 다듬고 더 많은 일들을 위임하자"

다시, 아마라의 법칙

아마라의 법칙을 다시 떠올려봅시다.

"기술의 효과는 단기적으로 과대평가되고, 장기적으로 과소평가되는 경향이 있다."

우리는 단기적 버블을 똑똑히 봤습니다. 5,600억 달러 투자에 350억 달러 매출. 95%의 도입 실패. 던닝-크루거를 서비스화한 챗봇들.[9]

하지만 이는 우리가 장기적으로 과소평가를 하고 있다는 증거이기도 합니다.

최근 Stanford 연구에 따르면, AI에 많이 노출된 직종의 22~25세 젊은 근로자 고용이 약 13% 하락했습니다.[10] 주니어 채용이 붕괴하고 있다는 건, 단순히 일자리가 줄어든다는 의미가 아닙니다. 견습 사다리가 재편되고 있다는 신호입니다.

AI는 주니어 업무를 자동화하고, 시니어 업무는 보조하는 형태로 발전하고 있습니다. 결과적으로 AI가 모든 인력을 대체하는 것이 아니라, 견습 사다리를 제거하고 있습니다.[11] 현재 시니어 엔지니어가 은퇴할 10~20년 후, 복잡한 시스템을 설계할 차세대 인력 부족이 예상됩니다.

10년 뒤 "개발자"라는 단어의 의미는 지금과 완전히 달라져 있을 것입니다.

맺으며

AI가 전문성의 종말을 초래할까요?

아닙니다. 직업은 자동화할 수 있는 하나의 업무가 아니라, 여전히 사람의 손길과 판단이 필요한 복잡한 업무들의 집합으로 이루어져 있습니다. AI는 그 중 일부를 대체할 뿐입니다.[12]

우리는 어떤 부분을 AI에게 위임하고, 어떤 부분에 우리의 전문성을 집중할지 선택해야 합니다. 그 선택을 위한 능력을 키우는 것이, 지금 우리가 해야 할 가장 중요한 일입니다.

AI에게 업무를 위임하는 것은 추상화하는 행위입니다. 그리고 좋은 추상화를 설계하는 능력이야말로, AI 시대에 개발자가 갖춰야 할 핵심 역량입니다.

버블을 다 봤다고 안심하면 안됩니다. 직업의 재정의는 모든 수준에서 급속도로 진행되고 있습니다. 직접 본인의 업무를 AI가 대체할 수 있게 만들어야 합니다. 그것이 역설적으로, AI 시대에 살아남는 방법입니다.

*이 글에 사용된 이미지는 모두 생성형 AI를 통해 제작되었습니다.

개발자는 AI에게 대체될 것인가

댓글