AI 엔지니어 이력서 작성법 - RAG와 에이전트 다음에 그 품질을 어떻게 쟀는지 봅니다

여기서 말하는 AI 엔지니어는 LLM 같은 생성형 모델을 써서 사용자나 현업에게 결과를 내놓는 기능과 시스템을 만드는 엔지니어입니다. 검색 증강 생성(RAG)으로 문서에 근거해 답하는 기능, 도구를 호출해 일을 처리하는 에이전트, 문서나 이미지에서 정보를 뽑는 기능이 여기에 들어갑니다. 공고에서는 AI 엔지니어, LLM 엔지니어, AI 에이전트 개발자, Applied AI Engineer 같은 이름으로 올라옵니다. 이 직무의 경력은 RAG 기반 사내 챗봇 개발, LangGraph 기반 AI 에이전트 구축, 프롬프트 엔지니어링 같은 문장으로 적는 경우가 많습니다. 이런 문장은 어떤 기술을 썼는지 알려 줍니다. 그런데 담당자가 확인하려는 것은 그 기능이 얼마나 자주 맞았는지, 틀렸을 때 원인을 어떻게 찾았는지, 한 번 호출에 얼마의 비용과 시간이 들었는지입니다. 토스의 AI 엔지니어 (Ads) 공고는 이력서 작성 안내에서 문제 정의, 가설, 평가 기준, 실패와 개선으로 이어지는 의사결정 흐름을 적어 달라고 했습니다. AI 적용 전후의 임팩트를 숫자로 보여 달라고 했고, 잘 안 됐던 시도와 거기서 얻은 결론도 환영한다고 밝혔습니다(2026년 11월 분석 기준).

머신러닝 엔지니어·백엔드 개발자와 다른 점

AI 엔지니어는 이웃 직무와 쓰는 기술이 비슷해서 경력 문장이 다른 직무의 것처럼 보이기 쉽습니다. 직무를 나누는 기준은 결과물입니다.

• 머신러닝 엔지니어: 모델을 학습시키고 빠르고 싸게 서빙하는 시스템(추론 서버의 지연 시간, GPU 비용, 배포와 롤백)
• 백엔드 개발자: 서비스의 데이터와 요청을 처리하는 서버와 API(정합성, 처리량, 장애 대응). 테스트로 결과가 맞는지 확인할 수 있습니다
• AI 엔지니어: 이미 있는 모델을 골라 프롬프트, 검색, 도구 호출을 엮어 만든 기능과 그 기능의 품질

AI 엔지니어가 만드는 기능은 같은 입력에도 답이 달라질 수 있고, 그럴듯하게 틀릴 수 있습니다. 그래서 담당자는 이 직무의 경력을 기능을 만들었다는 사실보다 그 기능이 맞는지 어떻게 확인했는지로 판단합니다. 결과 자리에 서버 응답 속도나 모델 학습 정확도만 있고 기능의 답이 얼마나 맞았는지가 없으면 백엔드나 머신러닝 엔지니어의 경력으로 보입니다. 추론 서버 자체를 최적화한 경험(vLLM 내부 튜닝, 양자화, GPU 자원 배분)은 머신러닝 엔지니어 쪽 경력에 가깝습니다. 망분리 환경처럼 외부 API를 쓸 수 없어 오픈 모델을 직접 띄워 기능에 붙였다면 AI 엔지니어 경력으로 적고, 서빙 숫자는 머신러닝 엔지니어 이력서 작성법의 방식을 참고하면 됩니다.

RAG와 에이전트라는 말만으로는 차이가 보이지 않는다

기업 채용 분석의 AI 엔지니어 공고 54건 가운데 41건이 RAG나 에이전트를 만드는 일을 업무나 자격·우대 사항에 적었습니다. 공고 네 건 중 세 건꼴로 나오는 말이라 이력서에 이 말이 있다는 것만으로는 다른 지원자와 차이가 생기지 않습니다. 차이는 그 말 뒤에 무엇을 했는지에서 생깁니다. RAG를 만들었다면 문서를 어떤 단위로 나눴는지, 키워드 검색과 벡터 검색을 함께 썼는지, 검색 결과의 순서를 다시 매겼는지, 그리고 그 선택을 무엇으로 비교해 정했는지를 적습니다. 에이전트를 만들었다면 어떤 도구를 쓰게 했고 어떤 일은 사람 확인을 거치게 했는지, 단계가 실패하면 어떻게 되는지가 들어가야 합니다. 메가존클라우드의 AI Engineer 공고는 임베딩 모델, 벡터 DB, 문서 파싱, 청킹에 대한 깊이 있는 경험을 우대했습니다. NHN의 LLM 기술 개발 (LLM / Agent) 공고는 청킹·임베딩과 벡터 DB 색인·검색 품질 튜닝을 업무로 적었습니다. 두 공고 모두 RAG라는 이름 대신 그 안의 단계를 하나씩 나열했습니다.

기능을 만들기 전에 정한 평가 기준

54건 가운데 8건이 LLM 기능의 품질을 평가해 본 경험을 자격 요건에 적었습니다(여러 경험 가운데 하나를 고르게 한 2건 포함). 토스의 Ads 공고는 "만들기 전에 평가 기준을 떠올리는 사고방식"을 자격 요건으로 요구했습니다. 브랜드 안전성이나 소재 퀄리티 같은 정성적 품질을 측정 가능한 신호로 정의할 수 있어야 한다고도 했습니다. 힐링페이퍼의 Forward Deployed Engineer 공고는 AI 제품의 응답 품질을 평가셋으로 검증하고 개선해 본 경험을 요구했습니다. 상담사와 품질 기준을 정하는 일도 업무에 들어 있습니다. NAVER의 AI 에이전트 엔지니어 공고는 작업 성공률, 도구 호출 정확도, 환각 비율 같은 정량 지표를 정의하고 평가 파이프라인을 자동화하는 일을 업무로 꼽았고, 평가 파이프라인 설계 경험을 자격 요건으로도 요구했습니다. 평가 경험은 평가셋, 지표, 기준 세 가지로 적습니다. 평가셋은 몇 건이고 어디서 왔는지(실제 사용자 질문인지 직접 만든 질문인지), 지표는 무엇이었는지, 합격 기준은 누구와 정했는지를 밝힙니다. 기능을 고칠 때마다 같은 평가셋으로 회귀 테스트를 했다면 그것도 빠뜨리지 않습니다. 프롬프트 한 줄을 바꿨다가 다른 질문의 답이 나빠지는 일을 막는 장치라서 운영 경험을 보여 줍니다. LLM으로 결과를 채점하게 했다면 그 채점이 사람의 판정과 얼마나 맞았는지도 함께 있어야 합니다. 카카오의 AI Research Engineer (Search & Agent) 공고는 LLM-as-a-Judge로 품질 평가 체계를 만들고 사람 평가와의 정합성을 검증하는 일을 업무로 적었습니다. 사람 판정과 맞춰 보지 않으면 긴 답이나 특정 말투를 높게 쳐 주는 채점 모델의 버릇이 점수에 섞여도 알 수 없습니다. 출시 전 평가만큼 출시 뒤에 품질을 어떻게 지켜봤는지도 운영 경험입니다. 업스테이지의 AI Engineer - Agents 공고는 LLM과 에이전트 시스템의 관측(trace, log, metric)을 설계하고 운영해 본 경험을 자격 요건으로 요구했습니다. 실제 요청을 단계별 기록으로 남겨 어디서 틀렸는지 찾았는지, 사용자 피드백이나 표본 검수로 품질을 계속 쟀는지, 운영에서 나온 실패 사례를 평가셋에 다시 넣었는지를 적습니다. 모델 제공사가 버전을 바꿀 때 같은 평가셋으로 비교한 뒤 옮겼다면 그것도 적을 만합니다.

검색이 틀렸는지 생성이 틀렸는지

RAG 기능의 답이 틀렸을 때 원인은 크게 둘입니다. 필요한 문서를 찾지 못했거나, 찾아온 문서가 있는데도 모델이 다르게 답한 경우입니다. 이 둘을 나눠 재지 않으면 프롬프트만 계속 고치게 됩니다. 문서에 답이 아예 없는 질문에 모델이 답을 지어낸 경우도 따로 셉니다. 이때는 모른다고 답한 비율이 지표가 됩니다. 그래서 RAG 경험은 검색 단계와 생성 단계를 따로 잰 숫자로 적습니다. 검색 단계는 정답 문서가 상위 몇 개 안에 들어왔는지(Hit Rate@K, Recall@K 등), 생성 단계는 답이 찾아온 문서에 근거했는지와 질문에 맞는 답인지로 잽니다. 삼일PwC의 AI Engineer 공고는 RAG 응답 품질을 Faithfulness, Relevance, Groundedness로 평가하는 일과 Graph RAG·Hybrid RAG의 검색 품질을 최적화하는 일을 업무에 따로 적었습니다. 삼정KPMG의 Lighthouse Center AI 서비스 개발자 공고는 RAG 결과를 평가하고 프롬프트와 검색 품질을 개선하는 일을 업무로 적었습니다. 문서가 PDF나 표, 스캔본이라면 검색 전에 문서를 읽어 들이는 단계가 품질을 크게 좌우합니다. 채널코퍼레이션의 Applied AI Engineer 공고는 PDF, 스프레드시트, 웹페이지에서 지식을 전처리하는 파이프라인을 업무로 적었고, 삼정KPMG 공고는 멀티모달과 OCR을 이용한 PDF 문서 처리 역량을 자격 요건으로 요구했습니다. 이 단계에서 표를 어떻게 나눴는지, 스캔 문서의 인식 오류를 어떻게 줄였는지가 차이를 만듭니다.

에이전트가 실패하면 어떤 일이 생기는지

에이전트는 모델이 스스로 도구를 고르고 여러 단계를 이어서 실행합니다. 그래서 담당자는 잘 돌아간 사례보다 틀린 도구를 고르거나 중간에 멈췄을 때 어떻게 대응하도록 설계했는지를 봅니다. 목암생명과학연구소의 LLM 에이전트 연구원/엔지니어 공고는 작업 상태 관리, 실패 복구, 중간 결과 재사용을 포함한 워크플로우 구축을 업무로 적었고, LLM 에이전트를 운영하며 오류와 예상 밖 동작을 처리한 경험을 요구했습니다. 에이전트가 아니어도 외부 생성 API를 여러 번 부르는 자리에서는 같은 것을 봅니다. 영상 생성 파이프라인을 맡는 넥스트증권의 AI Engineer 공고는 외부 생성 API의 실패, 재시도, 멱등성, 비용 상한을 코드로 통제해 본 경험을 자격 요건으로 요구했습니다. 토스의 Ads 공고는 모델이 자신 있게 틀리는 경우를 먼저 그려 보고 방어선을 설계하는 태도를 자격 요건에 적었습니다. 권한 설계를 묻는 공고도 있습니다. 목암생명과학연구소의 AI 에이전트 테크니컬 리드 공고는 도구 사용, 실행 범위, 사람 확인 같은 에이전트 안전장치를 설계하는 일을 업무로 적었습니다. 뷰티셀렉션의 FDE 공고 업무에는 에이전트가 실제 운영 데이터를 다루면서 사고를 내지 않도록 권한과 감사 경계를 코드로 정의하는 일이 들어 있습니다. 힐링페이퍼 공고는 고객 데이터 접근 권한, 개인정보 보호, 에이전트의 도구 사용 권한을 고려해 서비스를 설계해 본 경험을 요구했습니다. 모델에 들어오는 입력도 막아야 합니다. 사용자가 넣은 문장이나 검색해 온 문서 안에 모델에게 내리는 지시가 섞여 들어오면 에이전트가 그 지시대로 도구를 쓸 수 있습니다. 메가존의 AI Architect 공고는 프롬프트 인젝션과 데이터 유출 방지 같은 AI 보안 설계 경험을 우대했습니다. 이런 공격을 어떤 시험 문장으로 확인했는지, 개인정보를 모델에 넘기기 전에 어떻게 가렸는지, 공격 입력을 막아 낸 비율과 정상 입력을 잘못 막은 비율을 함께 적습니다. 에이전트 경험을 적을 때는 도구 목록보다 판단의 경계를 씁니다. 에이전트가 혼자 실행하는 일과 사람이 승인해야 하는 일을 무엇으로 나눴는지, 같은 요청이 두 번 실행되면 안 되는 도구를 어떻게 막았는지, 실패한 작업이 누구에게 넘어가는지를 밝힙니다.

호출 한 번의 비용과 응답 시간

AI 엔지니어가 다루는 비용은 GPU 서버 비용보다 호출 단위의 비용인 경우가 많습니다. 요청 한 건에 모델을 몇 번 부르는지, 입력과 출력 토큰이 얼마나 되는지, 어느 모델을 쓰는지가 비용과 응답 시간을 함께 정합니다. 메가존의 AI Architect 공고는 여러 모델 사이에서 비용과 성능의 트레이드오프를 판단해 본 경험을 자격 요건으로 요구했습니다. 이 공고는 모델 채택 여부를 성능만이 아니라 데이터 처리 위치, 라이선스 조건, 토큰 단가까지 함께 보고 판정하는 일도 업무로 꼽았습니다. 당근의 테크코어 (AI Platform) 공고는 요청된 작업에 맞는 모델을 자동으로 찾아 라우팅하고 성능과 비용의 트레이드오프를 최적화하는 일을 팀의 과제로 들었습니다. 목암생명과학연구소의 LLM 에이전트 공고 업무 목록에는 모델·도구 선택과 컨텍스트 관리로 불필요한 호출과 반복 실행을 줄이는 일도 있습니다. 비용을 줄였다면 품질을 얼마나 지켰는지와 함께 적습니다. 작은 모델로 바꿔 비용이 절반이 됐어도 평가셋 점수가 떨어졌다면 그 결정은 설명이 필요합니다. 요청 한 건당 비용, 응답이 시작되기까지 걸린 시간, 그리고 같은 평가셋에서의 점수를 전후로 나란히 쓰면 담당자가 그 판단을 이해할 수 있습니다. 품질과 비용 다음에는 그 기능이 실제로 쓰였는지를 적습니다. 힐링페이퍼 공고는 응답 시간과 호출 비용을 관리하는 일과 함께 예약 전환율 같은 고객 이용 지표를 개선하는 일을 업무로 적었습니다. 주간 사용자 수, 답변을 고치지 않고 그대로 쓴 비율, 그 업무의 처리 시간이 도입 전후로 어떻게 달라졌는지가 여기에 들어갑니다.

같은 경력을 이렇게 적으면

강한 문장에는 무엇으로 품질을 쟀는지, 원인을 어디서 찾았는지, 지원자가 어떤 기준을 정했는지가 들어 있습니다. 같은 RAG와 에이전트를 만들었어도 이 세 가지가 있어야 기능의 품질까지 책임진 사람으로 보입니다.

현장에 붙어 만드는 자리: FDE와 AI 솔루션 엔지니어

AI 엔지니어 공고 54건 가운데 8건은 Forward Deployed Engineer(FDE)나 AI 솔루션 엔지니어라는 이름으로 올라왔습니다. 회사는 채널코퍼레이션, CJ올리브영, 힐링페이퍼, 크래프톤, 매드업, 뷰티셀렉션, 토스입니다. 이 자리는 모델이나 검색 품질보다 현업이나 고객사의 문제를 정하고 기존 시스템에 연결해 실제로 쓰이게 만드는 일이 중심입니다. 사내 여러 조직과 일하는 자리와 외부 고객사에 들어가는 자리가 섞여 있고, 회사에 따라 솔루션 엔지니어가 판매 전 시연과 PoC를 맡기도 해서 공고의 업무부터 확인하는 것이 좋습니다. 토스의 AI 솔루션 엔지니어 공고는 적용하며 마주친 문제를 제품에 반영해 다음 적용은 설정만으로 되게 만드는 일을 업무로 적었고, 여러 조직에 비슷한 연동을 반복하다 공통 모듈로 바꿔 다음 구축 시간을 줄여 본 경험을 우대했습니다. 크래프톤의 Sr. AI Transformation Specialist (FDE) 공고 업무에는 도입한 AI 기술의 실제 비용 절감과 업무 시간 단축 효과를 정량적으로 분석하는 일이 들어 있습니다. 이런 자리에 지원한다면 몇 개 부서나 고객사에 도입했는지(고객사는 「금융사 3곳」처럼 업종과 규모로), PoC 가운데 몇 건이 실제 도입으로 이어졌는지, 도입 전후로 그 업무의 처리 시간이나 비용이 어떻게 달라졌는지, 첫 도입과 그다음 도입 사이에 구축 기간이 얼마나 줄었는지를 적습니다. 기존 시스템과 연동하며 생긴 문제(권한, 망분리, 오래된 API)를 어떻게 풀었는지도 이 자리에서 중요하게 보는 경험입니다. 고객 요구 가운데 무엇을 범위에서 뺐고 왜 그랬는지도 함께 적을 만합니다.

모델을 직접 학습시키는 자리

AI 엔지니어라는 이름의 공고 가운데 모델 자체를 학습시키는 자리도 있습니다. 카카오의 LLM Research Engineer (Post-training) 공고는 SFT와 RL을 포함한 사후 학습 경험과 분산 학습 경험을 요구했고, 토스의 AI 엔지니어 (Model) 공고는 LLM이나 VLM을 직접 학습해 실제 문제를 개선해 본 경험을 요구했습니다. 이런 공고의 요건은 앞에서 본 기능 개발 경험만으로 채우기 어렵습니다. 이름은 AI 엔지니어지만 일은 머신러닝 엔지니어나 연구 엔지니어에 가까워서, 학습 경험을 적는 방식은 머신러닝 엔지니어 이력서 작성법과 비슷합니다. 기능을 만들다 파인튜닝을 해 본 경험이 있다면 왜 프롬프트나 RAG로는 부족했는지부터 적습니다. 학습 데이터를 몇 건 어떻게 만들었는지, 어떤 방식으로 학습했는지(LoRA 같은 경량 학습, SFT·DPO 같은 학습 단계), 같은 평가셋에서 파인튜닝 전후 점수가 어떻게 달라졌는지를 이어서 씁니다. 파인튜닝을 자격 요건에 적은 공고는 5건이고 우대 사항에만 적은 공고는 9건이라 학습 경험이 없다면 지원하는 공고가 그것을 자격 요건으로 요구하는지부터 확인합니다.

LLM API만 써 봤다면

회사에서 LLM API로 기능을 붙여 본 경험만 있거나 개인 프로젝트뿐인 분은 경력이 얕아 보인다고 느낄 수 있습니다. EY한영의 Gen AI 서비스 및 애플리케이션 개발 컨설턴트 공고는 유관 경력 2~12년과 포트폴리오를 요구하면서도 ML·LLM 기술 활용 경험에 API 활용과 간단한 튜닝도 포함한다고 적었습니다. 전공이나 컨설팅·개발 경력이 없어도 직접 프로그래밍으로 서비스를 만들어 봤다면 지원할 수 있다고 덧붙였습니다. API만 썼더라도 평가와 비교는 혼자 할 수 있습니다. 개인 프로젝트에서 만들어 적을 만한 숫자는 아래와 같습니다.

• 질문 50~100개로 만든 평가셋과 그 평가셋으로 잰 정답률
• 청킹 크기나 검색 방식(키워드, 벡터, 둘 다)을 바꿔 가며 비교한 검색 정확도
• 같은 기능을 모델 두세 개로 돌려 본 품질, 요청당 비용, 응답 시간 비교
• 에이전트가 실패한 사례를 유형별로 나누고 고친 다음 다시 측정한 결과
• LLM 채점 결과와 직접 채점한 결과의 일치율

이 숫자는 실제 사용자 트래픽을 대신하지는 못합니다. 그래도 기능을 만들면서 무엇을 재야 하는지 알고 있다는 것은 보여 줄 수 있습니다. NHN의 LLM 기술 개발 공고, 넥슨코리아의 메이플스토리 AI 엔지니어 공고, EY한영 공고처럼 포트폴리오를 필수로 받는 곳도 있으므로 평가 방법과 숫자를 담은 프로젝트 정리를 그대로 포트폴리오로 낼 수 있습니다.

평가셋과 프롬프트는 회사에 남기고 밝혀도 되는 숫자만 가져온다

AI 기능의 품질 기록은 회사 안에 남습니다. 평가셋에는 실제 고객 문의나 사내 문서가 들어 있고, 프롬프트와 채점표는 회사의 자산입니다. 회사를 옮긴 뒤 이력서를 쓸 때는 이 자료를 다시 열어 볼 수 없어서 기억나는 기술 이름만 적게 됩니다. 그래서 평가를 한 차례 마칠 때마다 결과를 개인 기록으로 남겨 두는 것이 좋습니다. 평가셋의 규모와 출처, 바꾼 것, 전후 점수, 비용이 몇 % 달라졌는지, 버린 시도와 그 이유 정도면 충분합니다. 원가나 매출처럼 회사 숫자가 그대로 드러나는 값은 비율로 바꿔 적습니다. 고객 문의 원문, 사내 문서, 프롬프트 전문은 옮기지 않습니다. 이력서 문장을 다듬으려고 사내 자료를 외부 AI 도구에 붙여 넣는 것도 같은 유출입니다. 회사 밖에 적어도 되는 숫자인지는 보안 규정에서 먼저 확인합니다. GridResume 커리어 기록에 이렇게 남기면 이력서를 쓸 때 평가 기준과 숫자가 들어간 문장을 바로 만들 수 있습니다.

정리하면

AI 엔지니어 이력서에 들어가야 할 것은 다섯 가지입니다.

• 기능을 만들기 전에 정한 평가셋, 지표, 합격 기준과 출시 뒤 품질을 지켜본 방법
• RAG라면 검색과 생성을 따로 잰 숫자와 원인을 찾은 과정
• 에이전트라면 도구 권한, 사람 확인, 실패 처리, 입력 방어를 어떻게 정했는지
• 요청 한 건의 비용과 응답 시간을 품질과 함께 어떻게 조정했는지
• 지원하는 자리(기능 개발, FDE, 모델 학습)에 맞춰 더 자세히 적은 경험

RAG와 에이전트는 공고 네 건 중 세 건꼴로 나오는 말이라 그만큼 지원자 이력서에도 자주 보입니다. 그 기능의 품질을 무엇으로 쟀고 어떤 기준으로 판단했는지가 함께 있어야 AI 엔지니어의 경력으로 인정받습니다.