AI 개발자 자소서에서 평가자가 찾는 것은 용어가 아니라 실험 기록입니다

AI 직무 자소서의 절반은 LLM, RAG, 파인튜닝 같은 용어 나열로 채워져 있습니다. 평가자는 그 용어를 지원자가 실제로 다뤘는지 실험 설정과 지표로 확인합니다. 무엇을 어떤 순서로 써야 하는지 정리했습니다.

AI 개발자 자소서를 읽는 평가자는 지원자가 어떤 모델을 아는지 궁금하지 않습니다. 궁금한 것은 그 모델을 실제로 학습시키거나 배포해 봤는지, 결과가 안 좋았을 때 무엇을 바꿨는지, 개선을 어떤 기준으로 측정했는지입니다. 이 세 가지가 있으면 용어가 적어도 통과하고, 없으면 용어가 많아도 걸러집니다. 업스테이지, 리벨리온, 네이버, 카카오, 삼성SDS, LG CNS처럼 AI 인력을 뽑는 회사마다 표현은 다르지만 확인하는 것은 같습니다.

AI 개발자 자소서가 갈리는 첫 지점: 리서치인가 엔지니어링인가

모델을 만드는 일과 모델을 서비스로 돌리는 일은 과제가 다릅니다. 리서치는 데이터 품질, 학습 안정성, 평가 지표의 타당성을 다루고, 엔지니어링은 지연 시간, 처리량, 비용, 장애 대응을 다룹니다. 자소서에서 두 이야기를 섞으면 어느 쪽도 깊지 않아 보입니다. 지원 직무를 정하고 그 직무의 지표로 경험을 다시 정리하세요. 같은 프로젝트라도 리서치 지원이면 '정확도를 어떤 데이터에서 얼마나 올렸는지', 엔지니어링 지원이면 '응답 시간과 비용을 어떻게 줄였는지'가 본론이 됩니다.

실험 설정 세 가지가 없으면 결과 숫자는 의미가 없습니다

'정확도를 92%까지 올렸다'는 문장은 평가자에게 아무 정보도 주지 않습니다. 어떤 데이터에서, 무엇과 비교해서, 어떤 조건으로 측정했는지가 없기 때문입니다. AI 프로젝트 서술에는 세 가지가 함께 있어야 합니다. 첫째, 데이터의 출처와 규모, 그리고 학습·검증·테스트를 어떻게 나눴는지. 둘째, 비교 기준이 된 베이스라인이 무엇인지. 셋째, 평가 지표를 왜 그것으로 골랐는지. 이 셋이 들어가면 문장이 길어지지만, 평가자는 그 길이를 실력으로 읽습니다.

• 데이터: 출처, 규모, 분할 방식, 라벨 품질 문제가 있었다면 어떻게 처리했는지
• 베이스라인: 무엇과 비교했는지. 기존 모델, 단순 규칙, 이전 버전 등
• 지표: 왜 그 지표인지. 클래스 불균형이면 정확도 대신 F1을 쓴 이유처럼
• 실패한 시도: 무엇을 해 봤는데 안 됐는지. 이것이 있으면 지어낸 서술이 아니라는 신호가 됩니다

데이터 품질 서술이 모델 구조 설명보다 강한 이유

실무 AI 프로젝트 시간의 대부분은 데이터에 쓰입니다. 라벨이 틀린 데이터를 찾고, 중복을 제거하고, 분포가 치우친 것을 보정하고, 평가 데이터가 학습 데이터와 겹치지 않는지 확인하는 일입니다. 모델 구조는 논문을 따라가면 되지만 데이터 문제는 프로젝트마다 다릅니다. 그래서 데이터 문제를 발견하고 해결한 서술이 모델 설명보다 실무 감각을 더 잘 보여 줍니다. 자소서에 모델 이름은 한 번만 쓰고 데이터에서 겪은 문제를 한 문단 쓰는 배분이 대부분 지원자보다 낫습니다.

[예시 — 가상 사례, 실제 합격 사례 아님] 문서 분류 프로젝트에서 검증 정확도는 높은데 실제 배포 후 성능이 크게 떨어진 경우를 생각해 봅시다. 원인을 추적하니 같은 원문서에서 잘라낸 조각들이 학습과 검증 양쪽에 들어가 있었고, 문서 단위로 분할을 다시 하자 검증 정확도는 떨어졌지만 배포 성능과 일치하게 됐다는 서술입니다. 여기서 평가자가 읽는 것은 최종 숫자가 아니라 검증이 왜 믿을 수 없었는지 찾아낸 과정입니다.

공개 이력은 앞에, 강의 수료는 빼거나 한 줄로

논문, 학회 발표, 대회 순위, 오픈소스 기여, 기술 블로그는 평가자가 직접 확인할 수 있는 근거입니다. 있으면 자소서 첫 문단이나 경험 문항 첫 줄에 링크와 함께 두세요. 반대로 온라인 강의 수료 목록은 근거가 되지 않습니다. 수료했다는 사실은 무엇을 만들 수 있는지 말해 주지 않기 때문입니다. 강의를 들었다면 그 지식으로 무엇을 만들었는지만 쓰고 강의 이름은 빼는 편이 낫습니다.

AI·데이터 관련 직무의 능력단위와 수행 기준은 국가직무능력표준의 정보통신 분류에서 확인할 수 있습니다. · 국가직무능력표준 NCS

회사 유형별로 조금씩 다른 강조점

• AI 스타트업(업스테이지 등): 재현 가능한 실험과 공개 이력, 문서로 설득하는 비동기 협업 근거를 봅니다.
• AI 반도체·인프라(리벨리온 등): 모델보다 성능 병목을 찾고 개선한 과정, 측정 조건과 개선 폭을 봅니다.
• 대형 IT 서비스(네이버·카카오·NHN 등): 서비스 지표와 연결된 실험, 대용량 데이터 처리 경험을 봅니다.
• IT 서비스·SI(삼성SDS·LG CNS 등): 고객 문제 정의와 요구사항을 모델로 옮긴 경험, 안정성 관점을 봅니다.
• 제조·금융의 AI 조직: 도메인 데이터 특성 이해와 규제·보안 감각을 함께 봅니다.

그대로 따라 쓰면 안 되는 부분

위 예시의 데이터 누출 서술은 흔한 사례라 경험 없이 옮기면 면접에서 바로 드러납니다. 어떤 도구로 확인했는지, 분할을 어떻게 다시 했는지, 배포 성능은 무엇으로 측정했는지 되물으면 세부가 비어 있습니다. 작은 프로젝트라도 실제로 겪은 데이터 문제를 고르세요. 회사별 코딩테스트와 과제, 문항은 공고마다 다르므로 이 글의 강조점을 특정 회사 문항으로 단정하지 마세요.

내 자소서에 적용하기

초안이 있다면 프로젝트 문단마다 데이터·베이스라인·지표 세 가지가 있는지, 실패한 시도가 한 줄이라도 있는지, 모델 이름보다 데이터 문제가 더 길게 쓰여 있는지 확인하세요. 마스터플랜 첨삭은 프로젝트 서술에서 실험 설정이 빠진 곳과 용어만 남은 문장을 줄 단위로 짚어 주고, 기업별 첨삭은 업스테이지·리벨리온·네이버·LG CNS 같은 회사의 확인 항목과 대조합니다.

정리 체크리스트

자주 묻는 질문

AI 관련 채용 공고의 담당 업무와 자격 요건 표현은 고용24에서 직무별로 비교해 볼 수 있습니다. · 고용24