이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
저는 LLM 기반 자연어 처리 모델 개발에서 가장 중요한 요소를 프롬프트와 데이터 품질이라고 봅니다. 어떤 파인튜닝 전략을 선택하든, 학습 데이터의 레이블 일관성이 낮거나 프롬프트 포맷이 불안정하면 모델 출력이 흔들렸습니다. 사이드 프로젝트에서 GPT API 기반 요약 서비스를 만들 때 few-shot 예시 3개를 추가한 것만으로 출력 형식 준수율이 40%에서 91%로 뛰었습니다. 파인튜닝 비용을 쓰기 전에 프롬프트 엔지니어링으로 먼저 한계를 탐색하는 것이 효율적이라는 점도 이때 배웠습니다. 단, 모델 규모가 작아질수록 프롬프트 민감도가 높아지므로, 경량 모델에서는 입출력 예시를 더 촘촘히 설계하는 것이 중요하다고 봅니다.
LLM 기반 시스템에서 무엇이 좋은 출력인지 정의하는 것 자체가 가장 어려운 문제라는 것을 경험했습니다. BLEU·ROUGE 같은 자동 지표는 참조 텍스트와 단어 겹침을 측정하는데, 요약이나 대화처럼 정답이 하나가 아닌 태스크에서는 의미 있는 출력도 낮은 점수를 받는 경우가 많았습니다. 사이드 프로젝트에서 GPT를 심판으로 쓰는 LLM-as-Judge 방식을 시도해봤는데, 판단 기준을 프롬프트에 명시하지 않으면 평가 결과가 일관되지 않다는 것을 배웠습니다. 자동 지표와 LLM 판단, 소수의 인간 검토를 혼합해 서로 보완하는 구조가 현실적이라고 생각합니다.
LLM 개발은 모델을 만드는 것보다 출력 품질을 정의하는 것이 더 어려운 문제라는 것을 이 경험으로 배웠습니다.
LLM 기반 서비스를 만들면서 모델이 그럴듯하게 사실이 아닌 내용을 생성하는 환각 문제를 직접 경험했습니다. 특히 특정 도메인 지식이 필요한 질문에서 모델이 학습 데이터 기반으로 잘못된 정보를 자신 있게 답하는 경우가 있었습니다. RAG(Retrieval-Augmented Generation) 방식으로 외부 문서를 검색해 컨텍스트에 넣어주니 환각 빈도가 크게 줄었지만, 검색된 문서가 관련이 없으면 오히려 틀린 컨텍스트를 주입하는 문제도 생겼습니다. 두 단계를 독립적으로 평가하는 구조를 만드는 것이 중요했습니다.
LLM 환각은 완전히 없앨 수 없어서, 어느 범위까지 허용할지와 어떻게 검증할지를 함께 설계하는 것이 현실적이라는 것을 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 올웨이즈 ML 엔지니어 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.