생성형 AI 취업을 준비하는 학생의 포트폴리오를 검토했을 때 처음에는 상당히 준비가 잘 되어 있는 것처럼 보인 적이 있습니다. ChatGPT API를 이용해 챗봇을 만들었고, 역할을 부여하는 프롬프트와 답변 형식을 제한하는 프롬프트도 여러 버전으로 비교해 두었습니다. 질문에 따라 답변 톤을 바꾸고 특정 형식으로 결과를 출력하는 기능까지 구현되어 있어 프롬프트 실습 자체는 충분해 보였습니다. 그런데 실제 프로젝트를 조금 더 깊게 확인하면서 차이가 드러났습니다. 회사 내부 문서를 질문에 활용해야 한다면 어떤 문서를 어떻게 찾을 것인지, 검색된 문서와 모델 답변이 맞는지 무엇으로 평가할 것인지, 잘못된 답변이 반복되면 어떤 기록을 확인해야 하는지 물었을 때 답변이 짧아졌습니다.
모의면접에서도 비슷한 장면이 나옵니다. 프롬프트를 수정해 답변 품질을 높였다고 설명하지만 어떤 질문에서는 좋아지고 어떤 질문에서는 나빠졌는지 객관적으로 비교한 기록이 없습니다. PDF 문서를 넣어 답변하게 만들었다고 했지만 문서를 어떻게 나누었는지, 어떤 검색 결과가 모델에 전달되었는지, 관련 없는 문서가 검색되었을 때 어떻게 확인했는지는 정리되어 있지 않습니다. API를 호출하는 챗봇은 완성했지만 응답 시간이 길어졌을 때 무엇을 볼지, 요청이 많아졌을 때 비용을 어떻게 확인할지, 사용자가 잘못된 답변을 신고했을 때 어떤 로그를 남길지도 준비하지 않은 경우가 많습니다.
반대로 프롬프트 자체는 복잡하지 않아도 문서를 검색해 근거를 제공하는 RAG 구조를 만들고, 정답이 있는 질문 세트를 이용해 응답을 비교하고, 실제 API 호출 기록과 오류를 남긴 프로젝트는 훨씬 다르게 보입니다. 생성형 AI AI 서비스는 좋은 문장을 입력하는 것으로 끝나는 것이 아니라 필요한 정보를 찾아 모델에 전달하고, 결과를 평가하고, 실제 사용 과정에서 품질과 비용과 오류를 관리하는 단계까지 이어져야 하기 때문입니다. 이번 글에서는 생성형 AI 취업 준비생이 프롬프트만 공부하면 부족한 이유를 RAG, 평가, 운영 세 가지 기준으로 정리해 보겠습니다.
RAG는 모델이 답변에 필요한 정보를 어디에서 가져오는지 보여줍니다
- 프롬프트만으로 해결하기 어려운 질문이 있다는 점부터 이해해야 합니다
생성형 AI 공부를 시작하면 프롬프트를 어떻게 작성해야 더 좋은 답변이 나오는지부터 실습하는 경우가 많습니다. 역할을 지정하고, 출력 형식을 정하고, 예시를 제공하면서 결과를 비교해 보는 과정은 분명 중요합니다. 하지만 모델이 가지고 있지 않은 사내 문서나 최근 자료를 근거로 답변해야 하는 상황에서는 프롬프트만 잘 작성한다고 필요한 정보가 자동으로 생기지는 않습니다.
RAG를 공부할 때는 아래 흐름부터 이해하는 것이 좋습니다.
- 사용자가 무엇을 질문했는지 확인합니다.
- 질문과 관련된 문서를 어디에서 찾을지 정합니다.
- 검색된 문서 중 실제로 필요한 부분을 선택합니다.
- 선택된 내용을 모델 입력에 함께 전달합니다.
- 모델이 제공된 근거를 활용해 답변하는지 확인합니다.
- 답변과 실제 문서 내용을 다시 비교합니다.
예를 들어 회사의 휴가 규정에 답하는 챗봇을 만든다고 해보겠습니다. 모델에게 휴가 규정을 잘 설명해 달라는 프롬프트만 주는 것보다 실제 회사 규정 문서에서 관련 내용을 찾고 그 내용을 근거로 답변하게 만드는 구조가 필요합니다.
이 흐름을 이해하면 생성형 AI 프로젝트가 단순한 API 호출에서 벗어나 데이터 검색과 모델 활용이 연결된 서비스로 발전합니다.
- 문서를 넣었다는 것과 필요한 문서를 제대로 찾는 것은 다릅니다
RAG 프로젝트를 만들었다고 할 때 자주 나오는 설명은 PDF를 벡터 DB에 넣고 질문하면 답변하도록 만들었다는 것입니다. 하지만 실제로는 문서를 저장하는 것보다 질문에 맞는 내용을 정확하게 찾아오는 과정이 중요합니다.
- 문서 분할 기준: 긴 문서를 그대로 검색하기보다 어떤 단위로 나눌지를 결정해야 합니다. 너무 크게 나누면 관련 없는 내용이 함께 들어올 수 있고, 너무 작게 나누면 필요한 맥락이 끊길 수 있습니다.
- 검색 기준: 사용자의 질문이 어떤 문서 조각과 가장 관련 있는지 판단할 수 있어야 합니다. 검색 결과의 상위 항목이 실제 질문과 관련 있는지 직접 확인해 보는 과정이 필요합니다.
- 메타데이터 기준: 문서명, 작성 시점, 문서 종류처럼 추가 정보를 함께 관리하면 특정 문서나 최신 자료를 구분하는 데 활용할 수 있습니다.
- 근거 확인 기준: 모델 답변만 읽지 말고 어떤 문서가 검색되어 모델에 전달되었는지 확인해야 합니다. 답변이 틀렸을 때 검색 문제인지 생성 문제인지 구분하려면 이 과정이 필요합니다.
이런 기준을 정리하면 RAG 경험을 훨씬 구체적으로 설명할 수 있습니다. 면접에서도 벡터 DB를 사용했습니다라고 끝나는 것이 아니라 어떤 문서 단위로 저장했고, 검색 결과가 적절한지 어떤 기준으로 확인했는지 말할 수 있습니다.
- 검색 오류와 생성 오류를 구분해야 문제를 제대로 고칠 수 있습니다
RAG 서비스에서 잘못된 답변이 나왔다고 해서 항상 프롬프트를 수정해야 하는 것은 아닙니다. 질문과 관련 없는 문서가 검색되었을 수도 있고, 필요한 문서는 검색되었지만 모델이 다른 내용으로 답했을 수도 있습니다. 그래서 문제를 검색 단계와 생성 단계로 나누어 확인하는 연습이 중요합니다.
오답을 확인할 때는 아래 순서로 접근할 수 있습니다.
- 사용자가 실제로 입력한 질문을 저장합니다.
- 해당 질문에서 검색된 문서를 확인합니다.
- 필요한 근거가 검색 결과 안에 있는지 봅니다.
- 모델에 전달된 입력 내용을 확인합니다.
- 최종 답변이 근거와 일치하는지 비교합니다.
- 검색 문제와 생성 문제를 구분해 기록합니다.
예를 들어 환불 규정을 질문했는데 배송 관련 문서가 검색되었다면 프롬프트보다 검색 과정부터 점검해야 합니다. 반대로 환불 규정이 정확하게 검색되었는데 모델이 다른 날짜를 답했다면 생성 단계나 답변 제한 방식을 살펴볼 수 있습니다.
이런 식으로 문제를 나누는 습관은 실제 생성형 AI 프로젝트에서 매우 중요합니다. 단순히 프롬프트를 계속 바꾸는 것보다 어느 단계에서 문제가 발생했는지를 먼저 찾을 수 있기 때문입니다.
- RAG 포트폴리오는 구조보다 검색 근거를 설명할 수 있어야 합니다
생성형 AI 포트폴리오에서 RAG 아키텍처 그림을 넣는 것은 도움이 됩니다. 문서가 임베딩되고 벡터 DB에 저장된 뒤 사용자의 질문과 관련된 데이터를 검색해 LLM에 전달하는 흐름을 보여줄 수 있기 때문입니다. 하지만 그림 자체만으로는 프로젝트의 깊이가 충분히 드러나지 않습니다.
- 약한 설명: 문서를 벡터 DB에 저장하고 RAG를 이용해 챗봇을 구현했습니다.
이 문장에서는 프로젝트 구조는 보이지만 실제로 검색 품질을 어떻게 확인했는지는 알기 어렵습니다.
- 검색 경험이 보이는 설명: 회사 규정 문서를 일정 단위로 나누어 저장하고, 사전에 만든 질문 목록으로 검색 결과를 확인했습니다. 답변이 틀린 사례는 먼저 검색된 문서를 확인해 필요한 근거가 검색되지 않은 경우와 근거는 있었지만 답변이 잘못 생성된 경우로 나누었습니다.
- 개선 과정이 보이는 설명: 관련 없는 문서가 반복 검색되는 질문을 따로 모아 문서 분할 기준과 검색 결과 수를 변경해 다시 테스트하고, 같은 질문 세트로 변경 전후를 비교했습니다.
이런 설명이 있으면 RAG를 사용했다는 기술 이름에서 벗어나 실제 문제를 분석하고 개선해 본 경험이 보입니다. 생성형 AI 취업에서는 어떤 프레임워크를 사용했는지만큼 검색 결과를 어떻게 검증했는지가 중요합니다.
평가는 좋은 답변이라는 감각을 비교 가능한 기준으로 바꿉니다
- 프롬프트를 바꿨다면 결과가 실제로 좋아졌는지 확인해야 합니다
프롬프트를 공부할 때 가장 흔한 방식은 문장을 바꿔보고 결과를 눈으로 비교하는 것입니다. 학습 초기에는 좋은 방법이지만 취업용 프로젝트에서는 평가 기준이 조금 더 필요합니다. 프롬프트 A보다 프롬프트 B가 좋아 보인다는 느낌만으로는 어떤 질문에서 개선되었는지, 다른 질문에서는 문제가 생기지 않았는지 알기 어렵기 때문입니다.
생성형 AI 평가를 시작할 때는 아래 내용을 먼저 준비해 볼 수 있습니다.
- 서비스에서 실제로 나올 만한 질문을 모읍니다.
- 반드시 맞아야 하는 사실을 따로 정리합니다.
- 답변이 지켜야 할 형식을 정합니다.
- 근거가 없는 질문에서 어떤 반응이 필요한지 정합니다.
- 변경 전과 변경 후에 같은 질문을 사용합니다.
- 실패한 답변을 별도로 저장해 원인을 분석합니다.
예를 들어 사내 규정 챗봇이라면 휴가, 비용 처리, 근무시간, 복리후생처럼 여러 유형의 질문을 준비할 수 있습니다. 프롬프트를 수정한 뒤 이 질문들을 다시 실행해 동일한 기준으로 비교하면 변화가 훨씬 명확하게 보입니다.
평가는 좋은 답변을 찾는 작업이면서 변경이 다른 문제를 만들지 않았는지 확인하는 과정이기도 합니다.
- 정확성만으로 생성형 AI 답변 전체를 평가하기는 어렵습니다
생성형 AI 서비스는 사용 목적에 따라 확인해야 할 기준이 달라질 수 있습니다. 답변이 사실과 일치하는 것이 가장 중요할 수도 있고, 반드시 제공된 문서만 사용해야 할 수도 있으며, 특정 형식을 정확히 지켜야 할 수도 있습니다.
- 정확성 기준: 답변의 핵심 사실이 준비된 정답이나 원본 문서와 일치하는지 확인합니다.
- 근거성 기준: 모델이 답변할 때 실제 검색된 자료에 있는 내용을 사용했는지 봅니다. 문서에 없는 내용을 확정적으로 추가하지 않는지도 확인합니다.
- 관련성 기준: 사용자의 질문에 직접 필요한 내용을 답하고 있는지 봅니다. 내용이 사실이어도 질문과 관계없는 설명이 길다면 품질이 낮을 수 있습니다.
- 형식 기준: JSON이나 표처럼 서비스에서 정한 출력 구조가 있다면 해당 형식을 안정적으로 따르는지도 평가해야 합니다.
- 거부 기준: 근거 문서에서 답을 찾을 수 없는 경우 무리하게 답하지 않고 정보가 부족하다고 처리할 수 있는지도 확인할 수 있습니다.
이렇게 평가 기준을 나누면 모델 답변을 단순히 좋다와 나쁘다로 판단하지 않게 됩니다. 어떤 부분은 정확하지만 형식이 잘못되었는지, 검색 근거가 부족한지 구체적으로 구분할 수 있습니다.
- 오답을 유형별로 나누면 다음 개선 방향을 찾기 쉬워집니다
평가 결과를 점수로만 남기면 어떤 문제를 고쳐야 하는지 알기 어렵습니다. 그래서 잘못된 답변을 직접 읽고 유형별로 분류하는 과정이 필요합니다. 프로젝트 규모가 작더라도 충분히 해볼 수 있는 작업입니다.
오답 분석에서는 아래 항목을 구분해 볼 수 있습니다.
- 필요한 문서가 검색되지 않은 경우를 찾습니다.
- 관련 없는 문서가 상위에 나온 경우를 정리합니다.
- 문서는 맞지만 모델이 사실을 다르게 생성한 경우를 표시합니다.
- 질문과 관계없는 답변이 길어진 경우를 따로 봅니다.
- 요청한 출력 형식을 지키지 못한 사례를 모읍니다.
- 답을 찾을 수 없는데 임의로 답한 사례를 확인합니다.
이렇게 오류 유형을 나누면 개선 방향도 달라집니다. 검색 실패가 많다면 문서 구성이나 검색 방식을 다시 봐야 하고, 근거는 정확한데 임의 정보가 추가된다면 프롬프트와 답변 제한 방식을 조정할 수 있습니다.
생성형 AI 프로젝트에서는 모든 오답을 없애는 것보다 어떤 조건에서 실패하는지를 알고 있는 것이 중요합니다. 면접에서도 이 부분을 구체적으로 설명하면 단순 API 사용 경험과 차이가 생깁니다.
- 평가 기록은 모델과 프롬프트 변경의 이유를 남겨야 합니다
생성형 AI 프로젝트를 진행하면 프롬프트와 모델 설정을 여러 번 바꾸게 됩니다. 문제는 최종적으로 가장 마음에 든 버전만 남기면 왜 변경했는지 설명하기 어려워진다는 것입니다.
- 기록이 없는 프로젝트: 여러 프롬프트를 테스트한 뒤 가장 좋은 결과를 보인 버전을 선택했습니다.
- 평가가 남은 프로젝트: 30개의 테스트 질문으로 기존 프롬프트를 확인했더니 답변 형식을 지키지 못하는 사례와 근거가 없는 내용을 추가하는 사례가 반복되었습니다.
- 변경 이유가 보이는 프로젝트: 출력 형식을 명확하게 제한하고 근거가 없을 때 답하지 않도록 조건을 추가한 뒤 동일한 질문 세트로 다시 비교했습니다.
- 한계까지 남긴 프로젝트: 전체 결과는 개선되었지만 문서 표현과 사용자 질문이 크게 다른 경우 검색 성능이 떨어지는 문제가 남아 추가 개선 항목으로 정리했습니다.
이렇게 기록하면 프롬프트 변경이 감각에 의한 수정이 아니라 평가 결과를 바탕으로 한 개선 과정으로 보입니다. 생성형 AI 엔지니어 취업에서 이런 기록은 모델 사용 경험을 엔지니어링 경험으로 바꿔주는 중요한 근거가 됩니다.
운영은 만들어진 생성형 AI 서비스를 계속 사용할 수 있게 관리하는 과정입니다
- API가 한 번 동작하는 것보다 반복 요청에서 안정적인지가 중요합니다
생성형 AI 프로젝트를 만들 때 개발 환경에서 질문 하나를 보내고 답변이 나오면 완성했다고 생각하기 쉽습니다. 하지만 실제 서비스에서는 다양한 사용자가 반복적으로 요청하고 예상하지 못한 질문도 들어옵니다. 따라서 운영 관점에서는 정상 응답뿐 아니라 오류와 지연도 함께 확인해야 합니다.
운영 경험을 만들 때는 아래 내용을 테스트해 볼 수 있습니다.
- 여러 질문을 연속해서 요청해 봅니다.
- 긴 입력과 짧은 입력의 응답 차이를 확인합니다.
- 잘못된 형식의 요청이 들어왔을 때 반응을 봅니다.
- 모델 API 호출이 실패할 때 오류를 처리해 봅니다.
- 응답에 걸린 시간을 기록합니다.
- 어떤 요청에서 문제가 발생했는지 로그를 남깁니다.
이런 실습은 복잡한 운영 시스템이 없어도 가능합니다. 간단한 챗봇 프로젝트에서도 요청 시각, 질문 유형, 응답 시간, 오류 여부를 기록해 보면 실제 서비스 운영에서 어떤 정보가 필요한지 이해하게 됩니다.
생성형 AI 취업 준비에서는 만들어봤다는 경험에서 한 단계 더 나아가 계속 사용할 수 있도록 무엇을 확인해야 하는지를 고민할 필요가 있습니다.
- 생성형 AI 서비스에서는 응답 품질과 비용을 함께 봐야 합니다
생성형 AI API를 사용하는 서비스에서는 모델을 호출할 때마다 비용이 발생할 수 있고, 입력과 출력 길이에 따라 사용량이 달라질 수 있습니다. 따라서 답변이 좋아졌다는 이유만으로 프롬프트를 계속 길게 만드는 것이 항상 좋은 선택은 아닙니다.
- 품질 기준: 사용자가 필요한 정보를 정확하게 얻을 수 있는지를 먼저 확인합니다.
- 입력량 기준: 불필요하게 많은 문서를 모델에 전달하고 있지는 않은지 확인합니다. RAG에서 검색 결과를 너무 많이 넣으면 비용과 응답 시간이 함께 증가할 수 있습니다.
- 출력량 기준: 사용 목적보다 지나치게 긴 답변이 생성되고 있지는 않은지 살펴봅니다.
- 모델 선택 기준: 모든 요청에서 가장 큰 모델을 사용하는 것이 필요한지, 서비스 목적과 품질 기준에 맞는 선택인지 비교해 볼 수 있습니다.
- 운영 기준: 프롬프트나 검색 설정을 변경했을 때 품질뿐 아니라 응답 시간과 사용량도 함께 기록합니다.
이런 비교 경험이 있으면 포트폴리오에서도 생성형 AI 서비스를 실제로 운영하는 관점을 보여줄 수 있습니다. 단순히 가장 좋은 답변을 만드는 것이 아니라 품질과 비용과 속도 사이의 균형을 생각했다는 설명이 가능해집니다.
- 로그가 있어야 잘못된 답변의 원인을 다시 찾을 수 있습니다
사용자가 챗봇의 답변이 틀렸다고 알려왔을 때 최종 답변만 남아 있다면 원인을 찾기 어렵습니다. 어떤 질문이 들어왔고, 어떤 문서가 검색되었고, 어떤 모델과 설정이 사용되었는지를 확인할 수 있어야 문제를 다시 재현할 수 있습니다.
운영 로그에는 아래와 같은 내용을 고려할 수 있습니다.
- 사용자 질문을 식별 가능한 형태로 기록합니다.
- 어떤 검색 결과가 사용되었는지 남깁니다.
- 모델과 주요 설정 버전을 확인할 수 있게 합니다.
- 응답 시간과 오류 여부를 기록합니다.
- 실패하거나 품질이 낮았던 사례를 별도로 분류합니다.
- 설정 변경 전후의 차이를 추적할 수 있게 합니다.
실제 서비스에서는 개인정보나 민감정보 처리 기준도 함께 고려해야 하므로 모든 입력을 무조건 그대로 저장하는 방식은 적절하지 않을 수 있습니다. 취업 준비 단계에서도 무엇을 기록해야 문제를 분석할 수 있고, 무엇은 보호해야 하는지 생각해 보는 것이 좋습니다.
이런 관점이 추가되면 생성형 AI 포트폴리오는 단순 챗봇 화면보다 훨씬 깊어집니다. 오류를 다시 확인하고 개선할 수 있는 구조가 있기 때문입니다.
- 운영 경험은 배포 이후 품질이 달라질 수 있다는 점까지 봐야 합니다
생성형 AI 서비스는 처음 만든 상태가 계속 유지된다고 보기 어렵습니다. 새로운 문서가 추가될 수 있고, 기존 규정이 바뀔 수 있으며, 사용자가 처음 예상하지 못한 질문을 계속 입력할 수 있습니다. 모델이나 검색 설정이 바뀌는 경우도 있습니다. 그래서 운영에서는 배포 이후 품질을 계속 확인하는 과정이 필요합니다.
- 문서 변경 상황: 회사 규정이 수정되었다면 RAG에 사용되는 자료도 최신 상태로 반영되었는지 확인해야 합니다.
- 사용자 질문 변화: 실제 사용자 질문에서 테스트 단계에는 없었던 표현이 반복된다면 평가 데이터에도 해당 사례를 추가할 수 있습니다.
- 모델 변경 상황: 모델이나 프롬프트를 바꿨다면 기존에 잘 답하던 질문의 품질이 떨어지지 않았는지 같은 평가 세트로 다시 확인해야 합니다.
- 운영 개선 상황: 실제 오류 기록과 사용자 피드백을 바탕으로 검색 설정, 프롬프트, 평가 기준을 수정하고 다시 검증하는 흐름을 만들 수 있습니다.
이런 경험까지 포트폴리오에 남기면 생성형 AI 프로젝트는 한 번 만든 데모가 아니라 지속적으로 개선할 수 있는 서비스로 보입니다. 생성형 AI 엔지니어링에서 운영은 배포 후의 부가적인 일이 아니라 품질을 유지하는 핵심 과정입니다.
- conclusion
생성형 AI 취업 준비에서 프롬프트 공부는 분명 필요합니다. 역할을 어떻게 주고, 필요한 정보를 어떻게 전달하고, 출력 형태를 어떻게 제한하는지 이해해야 모델을 원하는 방향으로 활용할 수 있기 때문입니다. 문제는 좋은 프롬프트를 만드는 것 자체를 생성형 AI 역량의 완성이라고 생각하는 것입니다. 실제 서비스에서는 모델이 모르는 정보를 찾아오는 RAG 구조가 필요할 수 있고, 답변이 실제로 좋아졌는지 확인하는 평가 기준이 필요하며, 배포 이후 품질과 비용과 오류를 관리하는 운영 과정도 필요합니다.
기존에 만든 챗봇 프로젝트가 있다면 새 프로젝트를 시작하기보다 지금 있는 결과물을 확장해 보는 것이 좋습니다. 문서 기반 답변 기능을 만들었다면 어떤 문서가 검색되는지 먼저 기록해 보고, 테스트 질문을 만들어 프롬프트 변경 전후를 비교해 볼 수 있습니다. API를 이미 연결했다면 응답 시간과 실패 요청을 기록하고, 틀린 답변이 나왔을 때 검색 결과와 모델 답변을 다시 추적해 보는 것입니다. 이 과정을 거치면 같은 챗봇이라도 포트폴리오에서 설명할 수 있는 내용이 훨씬 많아집니다.
최종 점검은 아래 기준으로 해보면 좋습니다.
- RAG에서 어떤 문서를 어떤 기준으로 검색하는지 설명할 수 있는지 확인합니다.
- 검색 실패와 생성 오류를 구분할 수 있는지 점검합니다.
- 프롬프트 변경 전후를 같은 질문 세트로 평가해 봤는지 봅니다.
- 정확성뿐 아니라 근거성과 형식 준수 같은 기준을 설명할 수 있는지 확인합니다.
- 실제 API 요청의 응답 시간과 오류와 사용량을 기록해 봤는지 점검합니다.
준비 흐름은 이렇게 잡으면 좋습니다.
- 사용자 질문 → 문서 검색 → 근거 확인 → 프롬프트 구성 → 모델 응답 → 평가 → 오답 분석 → API 배포 → 로그 확인 → 비용과 지연 점검 → 사용자 질문 축적 → 재평가 및 개선. 이 흐름이 연결되면 프롬프트 실습은 단순한 생성형 AI 사용 경험에서 실제 서비스 엔지니어링 경험으로 바뀝니다.
결국 생성형 AI 취업에서 중요한 것은 얼마나 복잡한 프롬프트를 만들었는지가 아니라 필요한 정보를 찾아 답변하게 하고, 결과를 평가하고, 실제 서비스에서 계속 품질을 관리할 수 있는가입니다.
