2026년 5월, GM이 IT 부서 인력 수백 명을 정리했습니다. 이 소식이 특별한 이유는 해고 규모가 아닙니다. 빈자리를 어떤 역할로 채우기 시작했는지가 다릅니다. 공개된 채용 직군은 AI 네이티브 개발자, 에이전트·모델 개발자, 프롬프트 엔지니어, 데이터 엔지니어링·애널리틱스, 클라우드 기반 엔지니어입니다.

이름들이 완전히 낯설지는 않습니다. 이미 기술 업계에서 자주 등장하는 직군들입니다. 하지만 이것들이 기존 IT 인력의 교육·전환이 아닌, 즉각적 대체로 배치됐다는 점은 이전 흐름과 다릅니다. GM은 현재 직원들에게 AI를 가르치겠다고 하지 않았습니다. 처음부터 AI와 함께 일해온 사람을 외부에서 채용하겠다고 했습니다.

그 차이가 작아 보일 수 있습니다. 결과적으로 AI를 다루는 사람을 조직에 둔다는 목표는 같으니까요. 하지만 기업이 교육 대신 채용을 택했다는 사실은, 내부 교육으로 도달할 수 있는 수준과 처음부터 그 환경에서 일을 배운 사람의 수준 사이에 간격이 있다는 판단을 전제합니다. GM은 그 간격을 교육으로 좁힐 수 없다고 봤습니다.

리스킬링과 교체 사이의 진짜 간격

지난 2~3년 동안 기업들이 반복해서 내놓은 답은 "직원에게 AI를 교육하겠다"는 것이었습니다. 리스킬링, 업스킬링이라는 표현이 채용 공고와 내부 발표를 채웠습니다. 기존 인력을 새 도구에 적응시켜 조직 전체가 변화를 흡수할 수 있도록 하겠다는 전략입니다.

이 전략이 나쁜 것은 아닙니다. 조직 안에 이미 업무 맥락을 이해하는 사람에게 새 역량을 더하는 것은 합리적입니다. 실제로 많은 기업이 그렇게 해왔고, 일부는 효과를 봤습니다.

GM의 이번 결정은 그 경로를 택하지 않았습니다. 기존 인력에게 AI를 가르치는 대신, 처음부터 AI 환경에서 일을 배운 사람을 데려오는 것입니다. 단순한 채용 방식의 차이가 아닙니다. 그 배경에는 두 가지 수준이 다르다는 판단이 있습니다. 기존 방식으로 일하던 사람이 AI를 배워 도달할 수 있는 수준과, 처음부터 AI와 함께 일을 배운 사람이 낼 수 있는 성과가 다르다는 것입니다.

자동차 산업에서 유사한 분기점이 있었습니다. 내연기관에서 전기차로 전환할 때, 기업들은 선택해야 했습니다. 기존 엔진 엔지니어에게 배터리 기술을 가르칠 것인지, 아니면 배터리를 처음부터 다룬 사람을 영입할 것인지. 많은 기업이 두 경로를 동시에 밟았지만, 속도와 결과에서 차이가 났습니다. GM은 AI 분야에서 그 경험을 반영하고 있는 것으로 읽힙니다.

왜 교육이 아니라 채용을 택했을까요. 교육으로 만들 수 있는 역량과 경험을 통해 쌓이는 역량 사이에는 구조적 차이가 있습니다. AI 도구를 사용하는 방법은 배울 수 있습니다. AI를 중심으로 일 자체를 설계하는 감각은, 처음부터 그런 환경에서 일해본 경험이 없으면 형성되기 어렵습니다. GM이 원하는 것은 전자가 아닌 후자입니다.

새로 거래되기 시작한 역량의 실체

GM이 채우려는 역할들을 하나씩 보면 공통된 구조가 드러납니다.

AI 네이티브 개발은 AI를 보조 도구로 활용하는 것이 아닙니다. AI가 무엇을 할 수 있고 무엇을 할 수 없는지 이해한 채로, AI를 중심축에 놓고 시스템을 설계하는 능력입니다. 코드의 어느 부분을 AI에게 맡기고 어느 부분을 사람이 검증해야 하는지를 처음부터 고려합니다.

에이전트 개발은 반복적인 판단과 실행을 자동화하는 소프트웨어를 만드는 역할입니다. 특정 조건이 되면 자동으로 데이터를 수집하고 정리하고 보고하는 흐름, 여러 AI 도구를 연결해 하나의 작업 흐름을 구성하는 구조가 여기에 해당합니다. 에이전트는 단순 자동화와 다릅니다. 상황에 따라 다른 판단을 내릴 수 있어야 합니다.

프롬프트 엔지니어링은 AI에게 적절한 지시를 설계하는 역량입니다. 지시문을 잘 쓰는 것과는 다릅니다. AI가 어떤 방식으로 입력을 처리하고 출력을 생성하는지 이해한 채로, 원하는 결과를 안정적으로 끌어낼 수 있는 입력 구조를 만드는 일입니다. 이 역량은 개발자만의 것이 아닙니다. 기획자, 마케터, 콘텐츠 담당자도 갖출 수 있고, 이미 실무에서 갖춰가고 있는 사람이 늘고 있습니다.

데이터 엔지니어링과 클라우드 엔지니어링은 새로운 직군이 아닙니다. AI와 결합될 때 그 역할이 달라집니다. 데이터를 단순히 저장하고 옮기는 것이 아니라, AI 모델이 잘 작동할 수 있도록 데이터의 형태와 구조를 처음부터 설계하는 일입니다. AI가 학습하거나 참조하는 데이터의 품질이 모델 성능을 직접 결정하기 때문입니다.

이 직군들의 공통점은 AI를 도구로 쓸 줄 아는 능력이 아닙니다. AI가 어떻게 작동하는지 이해하고, 그것을 바탕으로 일의 흐름을 처음부터 다시 설계하는 능력입니다. 기존 IT 직군이 시스템을 구축하고 유지했다면, 이 직군들은 AI를 포함한 전체 작업 구조를 설계합니다. 역할의 범위가 달라진 것입니다.

이 신호가 한국 실무자에게 건네는 질문

GM의 사례는 미국 대기업 이야기입니다. 하지만 이 움직임을 "저쪽 이야기"로만 읽으면, 가장 실용적인 신호를 놓칩니다.

GM이 새로 채용하는 직군들에서 주목할 것은 직군 이름이 아닙니다. 이 사람들이 일하는 방식의 공통점입니다. AI를 변수로 처음부터 고려한 채 일을 설계한다는 것입니다. 반면 많은 현장에서 AI 도입은 다른 순서로 진행됩니다. 기존 업무 흐름이 먼저 있고, 그 중 일부를 AI로 바꾸는 방식입니다. 사용하는 도구가 달라진 것이지 일의 구조가 달라진 것은 아닙니다.

한국 1인 사업자나 기획자, 사내 PM 입장에서 이 차이를 체감할 수 있는 질문들이 있습니다.

내가 지금 반복하고 있는 판단이 있습니까. 비슷한 기준으로 매번 비슷한 결정을 내리는 작업, 같은 유형의 자료를 반복해서 정리하는 일이 있다면, 그것은 에이전트로 위임 가능한 후보입니다. 무엇을 직접 판단해야 하고 무엇을 구조화해 위임할 수 있는지 분리하는 것이 에이전트 설계의 시작입니다.

AI에게 같은 맥락을 반복해서 설명하고 있다면, 프롬프트 설계가 아직 되지 않은 것입니다. 매번 새로 배경을 설명하는 대신, 맥락을 담은 입력 구조를 한 번 만들어두면 이후에는 재사용할 수 있습니다. 이것이 프롬프트 엔지니어링의 실용적 출발점이며, 도구의 문제가 아니라 방법의 문제입니다.

AI가 틀린 결과를 낼 때 무엇이 문제인지 설명할 수 있어야 합니다. "이상하다"가 아니라 "이 부분의 맥락이 빠졌기 때문에" 혹은 "지시가 모호했기 때문에"라고 진단할 수 있을 때, AI와 함께 일하는 역량이 형성되기 시작합니다. 문제를 진단하는 능력이 설계 능력보다 먼저입니다.

이 역량들은 IT 부서나 개발자만의 이야기가 아닙니다. SI 프리랜서, 사내 PM, 1인 마케터, 독립 기획자 모두가 진입할 수 있는 수준의 이야기입니다. 전제는 하나입니다. 지금 내가 하는 일의 구조를 들여다볼 의지가 있어야 합니다.

AI 시대에 사람에게 남는 역량이 무엇인지를 묻는 논의는 많습니다. 창의성, 맥락 이해, 관계 구축 같은 답이 자주 나옵니다. 옳은 말들이지만 실행 가능한 형태가 되려면 한 가지가 더 있어야 합니다. 막연한 마음가짐이 아니라, 실제로 내 일의 구조를 진단하고 다시 설계해본 경험입니다. 그 경험이 없으면 아무리 좋은 태도도 좌표 없는 방향과 같습니다.

GM이 교육이 아닌 채용을 선택했다는 것은, 역량의 격차가 예상보다 빠르게 벌어지고 있다는 인식에서 나온 결정일 것입니다. AI를 쓰는 사람과 AI와 함께 일하는 사람 사이의 간격이, 사내 교육으로 좁힐 수 없는 수준이 되어가고 있다는 것입니다. 그 간격 어디쯤에 내가 있는지 점검하기에, 지금이 너무 이른 시점은 아닙니다.