AI 개발자를 뽑겠다는 공고는 넘쳐나는데, 막상 서류를 내보면 감감무소식이다. 반대로 이미 취업한 사람들의 후기를 들어보면 “코딩 테스트보다 다른 것을 더 많이 봤다”는 말이 반복된다. 이 간극이 어디서 오는지, 그리고 지금 준비하는 사람이 실제로 무엇을 바꿔야 하는지를 이 글에서 구체적으로 살펴본다.
채용 공고가 요구하는 것과 면접관이 실제로 보는 것
AI 개발자 채용 공고를 보면 PyTorch, TensorFlow, LangChain, RAG, 벡터 DB, MLOps 같은 키워드가 빼곡하다. 이 목록을 처음 접하는 사람은 ‘이걸 다 알아야 하나’라는 생각에 압도된다. 그런데 실제 면접 현장에서 들려오는 이야기는 조금 다르다. 기술 스택 나열보다, 그 기술로 무엇을 만들었고 어떤 문제를 어떻게 풀었는지를 훨씬 집중적으로 물어봤다는 것이다.
이는 국내외 테크 기업을 막론하고 반복적으로 회자되는 패턴이다. 공고의 기술 목록은 ‘이 정도 맥락은 알아야 대화가 된다’는 최저 기준선이고, 실제 평가는 문제 정의 능력, 실험 설계, 결과 해석, 그리고 그것을 다른 사람에게 설명하는 역량에 집중된다. 스택 암기는 입장권이고, 경험 서사가 본 게임이다.
‘AI 개발자’라는 말이 실제로 가리키는 여러 직군
혼란의 상당 부분은 ‘AI 개발자’라는 단어 자체가 너무 넓다는 데서 온다. 현장에서 이 타이틀 아래 실제로 하는 일은 크게 세 갈래로 나뉜다.
- ML 엔지니어 / 리서처: 모델 학습, 파인튜닝, 논문 구현. 수학·통계 기반이 탄탄해야 하고, 대규모 GPU 클러스터 경험이 차별점이 된다.
- AI 애플리케이션 개발자: GPT, Claude 같은 기성 LLM API를 프레임워크(LangChain, LlamaIndex 등)로 묶어 실제 서비스를 만드는 역할. 백엔드·프론트엔드 경험이 직접적인 자산이 된다.
- MLOps / AI 인프라 엔지니어: 모델을 안정적으로 서빙하고, 파이프라인을 관리하며, 실험 재현성을 보장하는 역할. 클라우드, 쿠버네티스, CI/CD 경험이 핵심이다.
지원 전에 “내가 지원하는 포지션이 이 세 가지 중 어디에 가까운가”를 먼저 파악해야 한다. 준비 방향이 완전히 달라지기 때문이다. AI 개발자 공고를 무작정 쌓아두고 준비하면, 면접장에서 엉뚱한 질문을 받고 당황하는 상황이 생긴다.
포트폴리오가 통하지 않는 흔한 이유
튜토리얼 데이터셋(MNIST, Titanic, 공개 Kaggle 데이터)으로 모델을 학습시키고 GitHub에 올린 프로젝트는 이미 포트폴리오로서의 변별력이 거의 없다. 채용 담당자들 사이에서 이런 프로젝트를 ‘학습 증거’로는 인정하지만 ‘실력 증거’로는 보지 않는다는 인식이 퍼져 있다. 그 이유는 단순하다. 결과가 정해진 문제를 따라가는 것과, 문제 자체를 정의하는 것은 전혀 다른 역량이기 때문이다.
변별력 있는 포트폴리오의 공통점은 대개 세 가지다. 첫째, 실제 불편함이나 업무 문제에서 출발한 프로젝트다. 둘째, 단순 정확도 수치가 아니라 ‘왜 이 모델을, 왜 이 지표로 평가했는가’를 설명할 수 있다. 셋째, 배포 또는 실사용 흔적이 있다. 로컬 jupyter 노트북 하나로 끝나지 않고, 실제로 누군가가 써봤거나 API로 서빙된 경험이 있으면 이야기가 달라진다.
지금 포트폴리오 프로젝트를 만들고 있다면, 주제 선정 단계에서 “이 문제를 왜 AI로 풀어야 하는가, 그냥 규칙 기반으로 풀면 안 되는가”를 먼저 자문해보자. 이 질문에 대한 답을 자기 말로 설명할 수 있어야 면접장에서도 같은 질문에 대응할 수 있다.
비전공자·커리어 전환자가 자주 빠지는 함정
비전공자이거나 다른 직군에서 AI로 전환을 준비하는 사람들이 공통적으로 겪는 함정이 있다. 바로 ‘지식을 먼저 다 채운 뒤 프로젝트를 시작하겠다’는 순서다. 선형대수, 확률통계, 머신러닝 이론, 딥러닝 아키텍처까지 교재를 정독하고 나서야 코드를 짜기 시작하면, 실제 프로젝트 경험 없이 시간이 지나가 버린다.
현장에서 확인되는 패턴은 반대다. 일단 작동하는 것을 만들면서 필요한 이론을 채워나가는 방식이 더 빠르고 더 오래 기억된다. 예를 들어 챗봇 하나를 LLM API로 만들어보면서 프롬프트 엔지니어링의 한계를 직접 체감하고, 그 한계를 넘으려고 RAG를 공부하고, RAG를 구현하면서 임베딩 개념을 실제로 이해하는 흐름이다. 이렇게 쌓인 지식은 면접에서 “이 기술을 왜 선택했는가”라는 질문에 자연스럽게 이야기로 연결된다.
커리어 전환자라면 이전 직군의 도메인 지식을 AI와 연결하는 것도 강점이 될 수 있다. 마케터였다면 고객 행동 데이터 분석, 법무 출신이라면 계약서 분류·요약, 의료 분야 종사자였다면 임상 텍스트 처리 같은 식이다. 범용 AI 개발자보다 ‘특정 도메인을 아는 AI 개발자’로 포지셔닝하는 것이 초기 진입에 유리할 수 있다.
면접 준비에서 놓치기 쉬운 것들
코딩 테스트 준비는 대부분 열심히 하는데, AI 관련 면접에서 비중이 높은 다른 영역을 놓치는 경우가 많다. 구체적으로는 다음 항목들이다.
- 프로젝트 디브리핑: 내 경험을 15분 안에 문제 → 접근법 → 결과 → 배운 점 순서로 말할 수 있어야 한다. 이것을 말로 여러 번 연습하지 않으면 면접장에서 횡설수설하게 된다.
- 트레이드오프 설명: “왜 A 대신 B를 선택했는가”라는 질문에 답할 준비. 선택지를 나열하고 각각의 장단점을 실제 상황 기준으로 설명할 수 있어야 한다.
- 실패 경험: 잘 된 프로젝트만 이야기하는 것보다, 안 됐던 시도와 그로부터 무엇을 바꿨는지를 말할 수 있는 사람이 더 신뢰를 받는 경향이 있다.
- 최근 업계 흐름에 대한 의견: “요즘 가장 관심 있게 보는 기술이나 논문이 있나요?”라는 질문이 자주 나온다. 무조건 최신 트렌드를 외울 필요는 없지만, 자기 관심사와 연결해서 한 가지를 구체적으로 말할 수 있어야 한다.
지금 당장 바꿀 수 있는 세 가지 행동
긴 글의 끝에서, 지금 준비 중인 사람이 이번 주 안에 실제로 할 수 있는 것을 세 가지로 압축해본다.
- 지원 직군 재정의: ‘AI 개발자’ 공고를 모아두기 전에, 앞서 소개한 세 갈래(ML엔지니어 / AI 앱 개발자 / MLOps) 중 어디에 집중할지 하나를 고른다. 이 결정이 이후 공부·프로젝트·이력서 방향을 모두 바꾼다.
- 포트폴리오 한 줄 점검: 지금 있는 프로젝트를 꺼내서 “이 문제를 왜 AI로 풀어야 했는가”를 적어본다. 쓰지 못하면 프로젝트를 보완하거나 새 프로젝트 주제를 고른다.
- 말하기 연습: 내 프로젝트 중 하나를 골라서 10분 분량의 설명을 말로 연습한다. 녹음해서 들어보면 어디서 막히는지 바로 보인다. 이 연습이 코딩 테스트 공부만큼, 혹은 그 이상으로 합격률에 영향을 준다.
준비 방향이 헷갈리거나, 내 경험이 어느 직군에 맞는지 판단이 서지 않는다면 혼자 고민하는 것보다 실제 현장 경험자에게 물어보는 것이 훨씬 빠르다. 누스쿨 커뮤니티에는 다양한 배경의 AI 직군 종사자와 전환 성공 사례가 모여 있다. 1:1 멘토링이나 커뮤니티 질문을 통해 내 상황에 맞는 조언을 받아보는 것을 권한다.
💬 댓글 0