채용공고 제목은 익숙한데, 안에서 요구하는 일은 이미 달라졌다

기업에는 해결해야 할 일이 먼저 생긴다. Foundation Model을 제품에 연결하고, RAG를 만들고, LLM을 평가하고, agent workflow를 기존 시스템에 붙여야 한다. 문제는 그 다음이다. 이 일을 하는 사람을 무엇이라고 부를 것인가.

Andela는 Fortune 500의 공개 software job posting 47,101개에서 2,026개 스킬을 추출해 기존 역할 사이로 스킬이 넘어가는 패턴을 분석했다. 연구에서 AI Engineer·ML Engineer 등 해당 bundle의 home role을 제목에 쓴 1,832개 공고 가운데 53%, 972개가 서로 다른 기존 역할에서 온 스킬을 두 개 이상 함께 요구했다.

즉 제목은 시장이 이미 알고 있는 역할을 쓰지만, 실제 JD는 그 경계 밖으로 움직이고 있었다. “AI Engineer”라는 한 줄이 실제로 같은 일을 뜻한다는 가정부터 흔들리는 지점이다.

6,758개 공고가 같은 방향의 일을 요구했지만, 그 직업의 이름은 정착되지 않았다

Andela는 기존 역할 하나에 잘 들어맞지 않으면서 반복해서 함께 나타나는 23개의 skill bundle을 후보로 잡았다. 그중 연구진이 주목한 역할에는 MLOps Pipeline Engineer와 LLM Application Engineer가 포함된다.

LLM Application Engineer는 foundation model 자체를 새로 훈련하는 연구자보다는 이미 존재하는 모델 위에서 애플리케이션을 만들고 연결하는 엔지니어에 가깝다. 연구에서 이 bundle의 일부 스킬이 함께 나타난 posting coverage는 6,758개였다.

여기서 주의할 점이 있다. 6,758개가 모두 “LLM Application Engineer 채용공고”라는 뜻은 아니다. 연구의 coverage는 bundle에 속한 서로 다른 스킬이 일정 기준 이상 함께 등장한 공고 수다. 오히려 중요한 것은 비슷한 조합이 반복되는데도 하나의 표준 직무명이 그 수요를 온전히 설명하지 못하고 있다는 점이다.

새 직업은 이름부터 생기지 않는다

우리는 새로운 기술이 나오면 새 직업명이 먼저 생긴다고 생각하기 쉽다. Prompt Engineer, AI Engineer, Agent Engineer처럼 이름이 등장하고 기업이 그 직업을 채용한다고 보는 방식이다.

실제 조직에서는 순서가 반대일 수 있다. Backend Engineer에게 LLM orchestration이 붙고, Data Engineer의 pipeline 업무와 ML Engineer의 evaluation 업무가 섞인다. 여러 회사에서 비슷한 조합이 반복된 뒤에야 시장이 그 일을 하나의 직무명으로 부르기 시작한다.

Andela 연구가 표현한 핵심도 “job titles lag the work”다. 다만 이 연구는 5주 동안의 단면 자료에서 taxonomy 대비 스킬 이동을 측정한 것이므로, 특정 직업이 시간에 따라 실제로 성장했다는 추세분석과는 다르다.

기업에게는 “AI Engineer 몇 명?”보다 앞선 질문이 있다

경영진이 “AI Engineer 10명을 뽑자”고 결정하면 채용팀은 그 직무명의 연봉, 후보군, 경력연차와 면접기준을 찾기 시작한다. 하지만 실제 필요한 일이 model training, LLM application, inference·MLOps, agent integration으로 갈린다면 하나의 직함이 오히려 문제를 숨길 수 있다.

필요한 사람이 Software Engineering + RAG + cloud deployment 경험을 가진 사람인데 “ML Engineer 5년”만 검색하면 이미 그 일을 해온 Backend·Platform 인재를 후보 밖으로 밀어낼 수 있다. 반대로 AI Engineer라는 타이틀만 좇으면 production engineering 경험이 부족한 후보를 같은 풀에 넣을 수도 있다.

그래서 인재 부족처럼 보이는 문제의 일부는 실제 공급 부족이 아니라 검색 경계의 문제일 수 있다. “사람이 없다”라고 결론 내리기 전에 어떤 문제를 어떤 스킬 조합으로 해결해야 하는지부터 적어볼 필요가 있다.

지원자는 자기 직함으로만 다음 직업을 검색하면 시장을 놓칠 수 있다

Software Engineer라는 명함을 달고 지난 2년간 LLM API, RAG, agent workflow, evaluation과 monitoring을 구축한 사람이 있다고 하자. 새 회사가 실질적으로 이 경험을 원하면서 공고 제목은 AI Engineer, Applied AI Engineer, ML Engineer 중 하나를 사용할 수 있다.

이때 지원자가 현재 직함과 정확히 같은 공고만 찾으면 자신의 경험이 이미 연결되는 새 역할을 놓칠 수 있다. 반대로 “AI 경력이 없다”고 생각했던 사람도 자신이 실제로 맡았던 문제를 분해하면 새로운 후보군에 들어갈 수 있다.

직무명이 흔들리는 시기에는 이력서 역시 “Backend Engineer 4년”에서 끝나기보다 무엇을 구축했고 어디까지 운영했는지를 보여주는 편이 더 중요해진다.

Indeed 데이터에서는 반대 방향의 변화도 동시에 보인다

Andela가 기존 직무명 안에 새로운 스킬 조합이 숨어드는 현상을 본다면, Indeed Hiring Lab은 직무명 자체에 AI라는 단어가 빠르게 퍼지는 장면을 포착했다.

Indeed에 따르면 미국에서 일정 규모 이상 AI 표현을 제목에 넣은 normalized job title은 2022년 264개에서 2026년 1분기 822개로 늘었다. 또 미국에서는 이런 AI-touched title의 63%가 비기술 직군에 속했다. 영업·HR·법무·교육 같은 기존 직업에도 AI 언어가 붙고 있다.

한쪽에서는 새로운 일이 오래된 이름 안에 숨어들고, 다른 한쪽에서는 오래된 일에 AI라는 새 이름이 붙는다. 지금 노동시장은 단순히 “새 기술 → 새 직업”이 아니라 직업명이 재편되는 중간 구간에 있다는 해석이 가능하다.

헤드헌팅에서는 직무명 검색보다 문제 검색이 먼저일 수 있다

직무명이 안정된 시장에서는 같은 타이틀을 가진 사람을 찾는 것이 좋은 출발점이 된다. 그러나 새 역할이 만들어지는 구간에서는 현재 그 이름을 가진 사람만 찾는 순간 후보군을 너무 일찍 닫을 수 있다.

LLM Application Engineer라는 사람이 필요하다고 해도 현재 그 일을 하고 있는 사람의 명함은 Software Engineer, ML Engineer, Platform Engineer일 수 있다. 따라서 Search의 질문은 “이 직함을 가진 사람은 누구인가”보다 “이 회사가 풀려는 문제를 다른 이름 아래에서 이미 풀어본 사람은 누구인가”가 먼저일 수 있다.

이것은 모든 AI 채용난이 naming failure라는 뜻이 아니다. 실제 희소한 전문역량과 공급 부족도 존재한다. 다만 직무명이 빠르게 변하는 시장에서는 후보군을 정의하는 방식 자체가 채용성과를 바꿀 수 있다.

BANSEOG VIEW

Banseog View — 인재 부족처럼 보이는 문제 중 일부는 직무 정의가 늦어서 생길 수 있다

Andela의 연구에서 가장 중요한 숫자는 새로운 직업명을 몇 개 만들었느냐가 아니다. 같은 이름의 공고 안에서 서로 다른 역할의 스킬이 반복해서 섞이고 있다는 점이다.

기업이 필요한 문제를 정의하기 전에 “AI Engineer”라는 직함부터 정하면 검색·연봉 benchmark·경력연차·면접 기준까지 오래된 역할 경계를 따라갈 수 있다. 지원자 역시 현재 직함만으로 공고를 찾으면 이미 해본 일과 연결되는 기회를 놓칠 수 있다.

AI 시대의 채용에서 더 오래 남을 질문은 “당신의 직무명이 무엇인가”보다 “어떤 문제를 실제로 해결해봤는가”일 수 있다. 당신의 다음 직업은 이미 생겨 있지만, 시장이 아직 그 이름에 합의하지 못했을 수도 있다.

SOURCES

근거가 된 원자료

Andela 원 연구는 2026-03-30~05-02의 약 5주 단면 자료이며 Fortune 500의 software-role filtered 공개공고와 Andela 자체 taxonomy를 사용합니다. 따라서 미국 전체 노동시장 추세나 모든 AI 직군에 그대로 일반화하지 않습니다. 6,758은 “LLM Application Engineer”라는 제목의 공고 수가 아니라 해당 bundle의 스킬 coverage입니다. Indeed 데이터는 별도 방법론의 보조 근거로만 사용합니다.