RAG 프로젝트 취업 포트폴리오 장단점(검색, 생성, 평가)

AI 직무를 준비하는 취업 준비생의 포트폴리오를 함께 점검하다 보면 RAG 프로젝트가 상당히 자주 등장합니다. PDF나 사내 문서를 벡터 DB에 저장하고 사용자가 질문하면 관련 문서를 검색한 뒤 LLM이 답변하는 구조입니다. LangChain이나 LlamaIndex 같은 프레임워크를 사용했고 임베딩과 벡터 검색까지 구현했기 때문에 처음 보면 AI 프로젝트로서 준비가 잘 된 것처럼 보일 수 있습니다. 그런데 프로젝트 설명을 조금 더 들어가면 차이가 나타납니다. 왜 문서를 해당 크기로 나누었는지, 검색 결과 첫 번째 문서가 실제 질문과 관련 있는지, 벡터 검색만 사용했는지 키워드나 하이브리드 검색과 비교했는지 질문하면 답변이 짧아지는 경우가 있습니다. 생성된 답변도 자연스럽지만 실제 문서에 없는 내용을 모델이 추가했는지, 출처와 답변 내용이 정확하게 일치하는지, 검색에 실패한 질문에서는 어떤 결과가 나오는지까지는 검증하지 않은 경우입니다. 이 상태에서는 기술적으로는 RAG를 구현했지만 포트폴리오에서는 LLM API와 벡터 DB를 연결한 기능 구현 프로젝트로 보일 가능성이 있습니다. 반대로 검색 결과를 직접 평가하고, 검색된 문서가 충분했는데 생성 단계에서 오류가 난 것인지, 처음부터 잘못된 문서를 가져온 것인지 원인을 분리해 분석한 프로젝트는 설명의 깊이가 달라집니다. 현재 주요 RAG 가이드에서도 단순한 검색과 생성 연결보다 이 구분을 중요하게 다룹니다. Microsoft의 RAG 평가 체계는 최종 답변의 groundedness와 relevance 같은 시스템 평가와 검색 단계 자체의 품질을 확인하는 프로세스 평가를 분리합니다. Google Cloud 역시 RAG 품질에서 검색 메커니즘이 핵심이며, 잘못된 정보를 검색하면 생성 결과 역시 관련성이 떨어지거나 부정확해질 수 있다고 설명합니다. 이 점 때문에 RAG는 취업 포트폴리오로 좋은 주제이면서 동시에 한계가 분명한 주제입니다. 검색에서는 문서를 어떻게 준비하고 관련 정보를 얼마나 정확하게 찾아오는지, 생성에서는 가져온 정보를 모델이 얼마나 충실하게 활용하는지, 평가에서는 두 단계를 각각 어떤 기준으로 측정하고 개선했는지를 보여줄 수 있어야 프로젝트의 깊이가 생깁니다. RAG 프로젝트의 가치는 RAG를 만들었다는 사실보다 검색과 생성의 실패 원인을 분리하고, 평가를 통해 개선한 과정이 남아 있는가에서 결정됩니다.
이번 글에서는 RAG 프로젝트가 취업 포트폴리오로 좋은 이유와 한계를 검색, 생성, 평가 세 가지 기준으로 나누어 정리하겠습니다.

검색은 RAG 프로젝트의 성능을 결정하는 첫 번째 단계입니다

좋은 RAG 프로젝트는 LLM보다 먼저 어떤 문서를 어떻게 찾는지 설명할 수 있어야 합니다

RAG 프로젝트를 시작하면 어떤 LLM을 사용할지를 먼저 결정하는 경우가 많습니다. 하지만 사용자의 질문과 관련된 정보가 검색되지 않는다면 이후에 아무리 좋은 모델을 사용하더라도 정확한 답변을 만들기 어렵습니다.

검색 프로젝트에서는 다음 내용을 연결해서 볼 수 있습니다.

원본 문서를 어떤 기준으로 수집했는지 정리합니다.
PDF와 HTML, 문서 파일에서 불필요한 요소를 제거합니다.
문서를 어느 크기와 기준으로 나눌지 결정합니다.
각 chunk에 제목과 문서명 같은 메타데이터를 연결합니다.
사용자 질문과 검색 결과의 관련성을 직접 확인합니다.
검색 결과의 개수와 순서를 바꾸면서 결과 차이를 비교합니다.

예를 들어 사내 규정 문서를 이용한 RAG에서 사용자가 휴가 규정을 질문했다고 가정할 수 있습니다. 검색 결과에 휴가 규정이 아니라 복리후생이나 급여 규정이 먼저 나온다면 생성 모델이 자연스러운 답을 만들더라도 근거 자체가 잘못된 상태입니다. 따라서 RAG 포트폴리오에서는 챗봇 화면보다 먼저 질문을 입력했을 때 어떤 문서와 어느 구간이 검색되었는지를 보여주는 것이 중요합니다.

문서 분할과 임베딩은 설정값보다 검색 결과의 변화로 설명하는 편이 좋습니다

RAG 프로젝트에서 chunk size와 overlap, embedding model 같은 단어를 많이 사용하면 기술적으로 보일 수 있습니다. 하지만 특정 값을 선택한 이유가 없다면 설정을 따라 적용한 수준으로 보일 수도 있습니다.

큰 chunk를 사용한 경우: 하나의 검색 결과에 많은 맥락이 포함되지만 질문과 직접 관련 없는 내용도 함께 들어올 수 있습니다.
작은 chunk를 사용한 경우: 세밀한 문장을 찾기 쉬울 수 있지만 필요한 앞뒤 맥락이 분리될 수 있습니다.
overlap이 큰 경우: 연속된 문맥을 유지하기 쉽지만 비슷한 내용이 여러 검색 결과에 반복될 수 있습니다.
메타데이터를 활용한 경우: 부서와 날짜, 문서 유형 같은 조건을 검색에 추가해 범위를 좁힐 수 있습니다.
임베딩을 변경한 경우: 같은 질문에 검색되는 문서의 순위와 관련성이 어떻게 달라지는지 비교할 수 있습니다.

Microsoft의 현재 RAG 가이드도 검색 품질이 콘텐츠 준비와 chunking, embedding, 검색 방식에 영향을 받으며 키워드·semantic·vector·hybrid search 같은 여러 접근을 사용할 수 있다고 설명합니다. 포트폴리오에서는 chunk size 500 사용이라는 문장보다 500과 1,000을 비교했을 때 어떤 질문에서 검색 품질이 달라졌는지가 더 좋은 설명이 됩니다.

벡터 검색만 사용하기보다 질문 특성에 따른 검색 차이를 비교하면 프로젝트 깊이가 생깁니다

RAG를 공부하면 벡터 검색과 임베딩이 중심처럼 느껴질 수 있습니다. 하지만 모든 질문이 의미 유사도 검색에만 적합한 것은 아닙니다.

검색 비교에서는 다음과 같은 상황을 만들 수 있습니다.

문서에 정확한 제품명이나 코드가 있는 질문을 사용합니다.
의미는 비슷하지만 표현이 다른 질문을 준비합니다.
숫자와 날짜가 중요한 질문을 포함합니다.
키워드 검색과 벡터 검색 결과를 비교합니다.
두 방식을 함께 사용하는 경우의 결과를 확인합니다.
검색 결과가 부족한 질문도 별도로 테스트합니다.

예를 들어 A-104 요금제 해지 조건처럼 고유 코드가 포함된 질문은 정확한 키워드 매칭이 중요할 수 있습니다. 반대로 회사를 그만둘 때 남은 휴가는 어떻게 처리되는가처럼 문서 표현과 질문 표현이 다른 경우에는 의미 기반 검색이 도움이 될 수 있습니다. 이런 비교가 있으면 벡터 DB를 사용했다는 사실보다 질문의 특성에 따라 검색 전략을 판단한 경험을 보여줄 수 있습니다.

검색 단계의 한계를 이해하면 RAG가 모든 문서 문제를 해결한다는 설명을 피할 수 있습니다

RAG는 외부 지식을 모델에 제공하는 데 유용하지만 모든 문서 분석 문제에 적합한 방식은 아닙니다. 특히 여러 문서 전체를 비교하거나 매우 긴 문서의 논리를 종합해야 하는 작업에서는 단순한 top-k 검색만으로 충분하지 않을 수 있습니다.

정확한 사실 검색: 특정 문서에서 필요한 정보를 찾아 답하는 업무에 적합할 수 있습니다.
FAQ 검색: 반복되는 질문에 관련 규정이나 절차를 찾아 제공하는 구조에 활용할 수 있습니다.
긴 문서 비교: 일부 chunk만 검색하면 전체 차이를 놓칠 가능성이 있습니다.
복잡한 추론: 여러 문서에 흩어진 조건을 모두 결합해야 한다면 검색 전략이 더 복잡해질 수 있습니다.
검색 실패 상황: 필요한 근거가 검색되지 않았다면 답변 생성을 제한하는 설계가 필요할 수 있습니다.

Microsoft의 RAG 관련 가이드 역시 RAG가 지식 기반의 사실 질문에는 적합하지만 장문의 전체 비교나 복잡한 문서 분석 같은 작업에는 한계가 있을 수 있다고 안내합니다. 따라서 포트폴리오에서도 RAG를 만능 기술처럼 설명하기보다 어떤 질문에서 잘 작동했고 어떤 질문에서는 구조적인 한계가 있었는지를 설명하는 편이 오히려 프로젝트 신뢰도를 높일 수 있습니다.

생성은 검색된 근거를 이용해 얼마나 정확하고 통제된 답변을 만드는지 확인하는 단계입니다

답변이 자연스럽다는 사실과 근거에 맞는 답변이라는 사실은 구분해야 합니다

LLM은 문장을 자연스럽게 만드는 데 강합니다. 이 때문에 검색 결과가 부족하거나 일부 정보가 잘못되어도 그럴듯한 답변을 생성할 수 있습니다.

생성 단계에서는 다음 내용을 확인할 수 있습니다.

검색된 문서에 실제 답변 근거가 존재하는지 확인합니다.
모델이 문서에 없는 내용을 추가하지 않는지 살펴봅니다.
질문에 필요한 내용을 모두 답했는지 확인합니다.
불확실한 정보에서 모른다고 답할 수 있는지 테스트합니다.
답변과 출처 문서를 함께 연결합니다.
동일 질문에서 결과가 지나치게 흔들리지 않는지 비교합니다.

예를 들어 문서에는 사용기간 1년 이상이면 휴가 15일이라고 적혀 있는데 모델이 일반적인 노동법 지식을 이용해 다른 조건까지 추가한다면 문장은 자연스럽더라도 RAG의 목적에는 맞지 않을 수 있습니다. 따라서 생성 품질에서는 얼마나 자연스럽게 답했는지보다 검색된 근거 안에서 얼마나 충실하게 답했는지가 중요합니다.

검색 실패와 생성 실패를 구분하면 문제 해결 방식도 달라집니다

RAG 결과가 틀렸다고 해서 항상 LLM의 문제라고 볼 수는 없습니다. 검색 단계에서 이미 잘못된 문서를 가져왔다면 프롬프트를 계속 수정해도 문제를 해결하기 어렵습니다.

검색 실패: 질문과 관련된 문서가 검색되지 않았습니다.
순위 실패: 필요한 문서는 검색됐지만 너무 낮은 순위에 있어 모델 입력에 포함되지 않았습니다.
맥락 부족: 관련 chunk는 찾았지만 필요한 앞뒤 내용이 빠져 있습니다.
생성 실패: 충분한 근거가 주어졌지만 모델이 잘못 해석하거나 다른 내용을 추가했습니다.
출력 실패: 내용은 맞지만 필요한 형식이나 인용 구조를 지키지 않았습니다.

이렇게 원인을 나누면 프롬프트를 수정해야 하는지와 chunking이나 검색 방식을 변경해야 하는지를 구분할 수 있습니다. RAG 포트폴리오의 좋은 부분은 바로 이 지점입니다. 하나의 AI 결과를 데이터 검색과 모델 생성이라는 서로 다른 시스템 문제로 나누어 디버깅하는 경험을 보여줄 수 있기 때문입니다.

출처와 인용까지 연결하면 생성 결과를 검증하기 쉬워집니다

사용자 입장에서 AI 답변이 맞는지 판단하려면 답변 근거를 확인할 수 있어야 합니다. 특히 내부 규정이나 제품 문서처럼 정확성이 중요한 시스템에서는 출처가 프로젝트의 중요한 기능이 될 수 있습니다.

프로젝트에서는 다음 내용을 연결할 수 있습니다.

검색한 문서명과 페이지 정보를 보존합니다.
답변과 관련된 source를 함께 제공합니다.
답변 내용이 실제 source와 일치하는지 확인합니다.
여러 source를 사용한 경우 각각 어떤 주장과 연결되는지 살펴봅니다.
출처가 없는 답변을 별도로 식별합니다.
문서가 업데이트되었을 때 오래된 출처가 남지 않는지 확인합니다.

OpenAI의 현재 file search 역시 업로드된 지식베이스를 semantic·keyword search로 검색해 모델이 관련 정보를 활용하도록 하는 구조를 제공하며, RAG의 기본적인 검색 후 생성 패턴과 연결됩니다. 이런 경험이 있으면 포트폴리오에서 출처 표시 기능 구현이라는 한 문장보다 답변을 실제 근거와 추적 가능하게 연결한 이유를 설명할 수 있습니다.

생성 단계의 한계까지 정리하면 프로젝트가 단순 챗봇보다 시스템 설계 경험으로 보입니다

좋은 RAG 프로젝트라고 해서 모든 질문에 정확한 답을 생성할 필요는 없습니다. 오히려 어떤 조건에서 답변 품질이 떨어지는지를 확인하고 이를 어떻게 통제했는지가 중요합니다.

근거가 충분한 경우: 검색된 내용을 바탕으로 직접적인 답변을 생성합니다.
근거가 부족한 경우: 확정적인 답변 대신 추가 정보가 필요하다는 결과를 반환합니다.
서로 충돌하는 문서가 있는 경우: 최신 문서나 신뢰도 높은 source를 우선하는 기준이 필요합니다.
질문 범위를 벗어난 경우: 지식베이스에서 확인할 수 없다는 상태를 구분합니다.
민감한 문서가 포함된 경우: 사용자 권한에 따라 검색 가능한 문서를 제한해야 합니다.

Microsoft의 RAG 가이드는 retrieval 단계에서 접근통제를 적용하고 검색된 문서를 신뢰할 수 없는 입력으로 취급해 prompt injection과 민감정보 노출을 고려해야 한다고 설명합니다. 따라서 RAG 포트폴리오의 한계는 모델이 가끔 틀린다는 사실 자체가 아닙니다. 어떤 실패가 발생할 수 있고 어디에서 통제할 수 있는지를 설계했는가가 더 중요한 평가 지점이 됩니다.

평가는 RAG 프로젝트를 단순 구현 프로젝트와 문제 해결 프로젝트로 나누는 기준입니다

평가 데이터셋을 만들면 감으로 RAG 품질을 판단하는 문제를 줄일 수 있습니다

RAG 프로젝트를 테스트할 때 직접 질문 몇 개를 입력해 답변이 괜찮으면 정상이라고 판단하는 경우가 많습니다. 하지만 개선 전후 결과를 비교하려면 일정한 테스트 질문과 기대 결과가 필요합니다.

평가 프로젝트에서는 다음 내용을 구성할 수 있습니다.

실제 사용 상황을 가정한 질문을 여러 유형으로 준비합니다.
각 질문에 필요한 정답 문서를 정리합니다.
쉬운 질문과 모호한 질문을 구분합니다.
검색이 어려운 질문도 일부 포함합니다.
답변이 없어야 하는 질문을 테스트합니다.
설정 변경 전후 동일한 질문으로 다시 평가합니다.

예를 들어 chunk size를 변경했는데 이전과 다른 질문을 사용하면 검색 품질이 개선되었는지 정확하게 비교하기 어렵습니다. 같은 질문 세트를 이용해 결과를 반복 비교해야 어떤 변경이 실제 효과가 있었는지 확인할 수 있습니다. 이런 평가 데이터가 있으면 RAG 프로젝트는 데모 화면에서 벗어나 실험과 비교가 가능한 AI 시스템 프로젝트로 발전합니다.

검색 평가와 생성 평가는 서로 다른 지표를 사용해야 합니다

RAG 시스템을 하나의 최종 정확도만으로 평가하면 어느 단계가 문제인지 찾기 어렵습니다. 따라서 검색과 생성 품질을 분리해 보는 것이 중요합니다.

검색 관련성 평가: 질문과 실제 관련 있는 문서가 검색되었는지를 확인합니다.
검색 순위 평가: 필요한 문서가 상위 결과에 위치하는지 확인합니다.
Groundedness 평가: 생성된 주장이 제공된 context에서 근거를 찾을 수 있는지 확인합니다.
답변 관련성 평가: 생성 결과가 사용자의 질문에 실제로 답하고 있는지 확인합니다.
답변 완전성 평가: 필요한 핵심 내용을 빠뜨리지 않았는지 확인합니다.

Microsoft Foundry의 현재 RAG 평가 체계 역시 최종 생성 결과에는 groundedness·relevance·completeness를, retrieval 과정에는 별도의 retrieval 평가를 적용하는 구조를 제공합니다. 이 기준을 포트폴리오에 활용하면 정확도 90%처럼 근거가 모호한 숫자보다 검색과 생성의 어느 부분이 얼마나 개선되었는지를 더 명확하게 설명할 수 있습니다.

실패 사례를 분류하면 개선 과정이 포트폴리오의 핵심 경험이 됩니다

AI 프로젝트에서는 성공 사례만 골라 데모로 보여주기 쉽습니다. 하지만 실제 엔지니어링 역량은 실패한 질문을 어떻게 분석했는지에서 더 잘 드러날 수 있습니다.

실패 분석에서는 다음 내용을 기록할 수 있습니다.

검색 자체가 실패한 질문을 분리합니다.
올바른 문서가 낮은 순위에 나온 사례를 확인합니다.
검색 문서는 맞지만 답변이 틀린 사례를 구분합니다.
여러 문서를 조합해야 하는 질문을 별도로 살펴봅니다.
답변 불가능한 질문에서 모델이 내용을 만들어내는지 확인합니다.
수정 이후 동일한 실패 사례가 개선되었는지 재검증합니다.

예를 들어 30개의 테스트 질문 가운데 8개가 실패했다면 단순히 성공률만 계산하는 데서 끝나지 않을 수 있습니다. 8개 중 5개가 retrieval 문제이고 3개가 generation 문제라면 검색 전략부터 개선하는 것이 더 합리적인 접근이 됩니다. 이런 과정이 있어야 RAG 프로젝트가 성공한 챗봇을 보여주는 포트폴리오가 아니라 실패 원인을 진단하고 개선한 엔지니어링 프로젝트로 보입니다.

평가가 없는 RAG 프로젝트는 기술 선택의 근거를 설명하기 어렵다는 한계가 있습니다

RAG 프로젝트에서 embedding model과 vector DB, chunk size, top-k, reranking 같은 설정을 여러 개 적용할 수 있습니다. 하지만 평가가 없다면 왜 현재 조합을 선택했는지 설명하기 어렵습니다.

초기 기준 설정: 기본 검색과 생성 결과를 먼저 측정합니다.
검색 개선 실험: chunk와 embedding, 검색 방식 등을 변경합니다.
생성 개선 실험: system prompt와 context 구성 방식을 변경합니다.
비교 평가: 같은 질문 세트로 이전 결과와 비교합니다.
운영 판단: 품질 개선뿐 아니라 응답시간과 비용 변화도 함께 확인합니다.

Google Cloud 역시 RAG 평가에서 retrieval과 grounded generation의 품질을 측정하고, 평가 결과를 기반으로 검색 설정과 source 데이터, chunking 전략 등을 조정하는 접근을 설명하고 있습니다. 따라서 취업 포트폴리오에서 RAG의 가장 큰 장점은 최신 기술을 사용했다는 사실이 아닙니다. 검색 → 생성 → 평가 → 실패 분석 → 수정 → 재평가라는 AI 시스템 개선 과정을 하나의 프로젝트에서 보여줄 수 있다는 점에 있습니다.

conclusion

RAG 프로젝트는 AI 직무 취업 포트폴리오로 활용하기 좋은 주제입니다. LLM API만 사용하는 챗봇보다 데이터 준비와 임베딩, 검색, 프롬프트, 생성, 출처 연결, 평가까지 여러 AI 시스템 요소를 하나의 프로젝트 안에서 경험할 수 있기 때문입니다. 하지만 RAG를 만들었다는 사실만으로 좋은 포트폴리오가 되는 것은 아닙니다. 문서를 벡터 DB에 저장하고 질문에 답하는 기본 구조는 다양한 프레임워크와 관리형 서비스로 비교적 빠르게 구현할 수 있습니다. 현재 OpenAI와 Microsoft 등에서도 파일·지식베이스 기반 검색 기능을 관리형 형태로 제공하고 있기 때문에 단순 연결 자체만으로 프로젝트 차별성을 만들기는 점점 어려워질 수 있습니다. 검색에서는 어떤 문서를 어떤 단위로 나누었는지와 질문에 실제 필요한 정보가 상위 결과로 검색되는지를 확인해야 합니다. 생성에서는 모델이 검색된 근거를 충실하게 사용하는지와 근거가 부족할 때 임의로 내용을 만들지 않는지를 검증해야 합니다. 평가에서는 두 단계를 분리해 같은 테스트 질문으로 변경 전후 결과를 비교해야 합니다.

최종적으로 확인할 항목은 다음과 같습니다.

문서를 어떤 기준으로 chunking 했는지 설명할 수 있는지 확인합니다.
검색된 문서가 실제 질문과 관련 있는지 직접 평가했는지 살펴봅니다.
벡터 검색과 다른 검색 방식의 차이를 비교한 경험이 있는지 확인합니다.
생성 답변이 검색된 근거에 실제로 기반하는지 검증했는지 점검합니다.
검색 실패와 생성 실패를 따로 분류할 수 있는지 살펴봅니다.
같은 질문 세트를 이용해 수정 전후 성능을 다시 비교했는지 확인합니다.

RAG 프로젝트 준비 흐름은 다음과 같이 연결할 수 있습니다.

conclusion문서 수집 → 데이터 정제 → chunking → 메타데이터 구성 → embedding → 검색 인덱스 구축 → 기본 검색 테스트 → LLM 연결 → 출처 표시 → 검색 실패 사례 수집 → 생성 오류 분리 → 평가 질문 세트 구성 → retrieval 평가 → groundedness와 답변 관련성 평가 → 검색 설정 개선 → 생성 설정 개선 → 동일 질문 재평가 → 결과 문서화 → 포트폴리오와 면접 연결

결국 RAG 프로젝트의 장점과 한계는 같은 지점에서 나옵니다. 구조 자체는 이해하기 쉽고 구현도 시작하기 좋지만, 검색 결과가 틀리면 생성 결과도 쉽게 흔들리고 자연스러운 답변만 보고 품질을 판단하기도 어렵습니다. 검색에서는 필요한 근거를 얼마나 정확하게 찾는지, 생성에서는 찾은 근거를 얼마나 충실하게 사용하는지, 평가에서는 두 단계를 분리해 문제를 찾아내고 개선할 수 있는지가 포트폴리오의 핵심입니다. 이 흐름까지 남아 있다면 RAG 프로젝트는 단순한 생성형 AI 챗봇을 넘어 데이터와 검색, LLM, 평가를 연결하고 AI 시스템의 실패 원인을 진단해 개선한 경험으로 설명할 수 있습니다.