AI 제품 개발 핵심 개념 지도: 프롬프트에서 평가와 운영까지
데모는 십 분 만에 나오는데 제품이 되지 않는 일이 반복됩니다. 잘 되던 프롬프트가 입력이 조금 달라지면 무너지고, 고쳤더니 다른 경우가 깨지고, 무엇이 나아졌는지 말할 근거가 없습니다. 모델을 다루는 어려움보다는 정답이 하나가 아닌 시스템을 어떻게 판정하고 운영할지의 문제입니다.
데모는 십 분 만에 나오는데 제품이 되지 않는 일이 반복됩니다. 잘 되던 프롬프트가 입력이 조금 달라지면 무너지고, 고쳤더니 다른 경우가 깨지고, 무엇이 나아졌는지 말할 근거가 없습니다. 모델을 다루는 어려움보다는 정답이 하나가 아닌 시스템을 어떻게 판정하고 운영할지의 문제입니다.
로컬에서 AI 모델을 돌리다 보면 이런 상식이 생깁니다. 모델이 크면 똑똑하지만 느리다. 대체로 맞습니다.
온프레미스 추론 서버에 모델이 25개, 154GB 쌓여 있었습니다. 저는 필요할 때마다 하나씩 받았고, 어느 시점부터 무엇을 왜 갖고 있는지 설명할 수 없게 됐습니다.
사내 문서 RAG 챗봇처럼 비용을 아껴야 하는 환경에서는 작은 모델을 쓰게 됩니다. 그런데 작은 모델은 시스템 프롬프트의 금지 규칙을 자주 어깁니다. 이때 흔히 하는 대응이 프롬프트를 더 강하게 쓰는 것입니다. "절대 하지 마세요", "반드시" 같은 말을 덧붙이고, 예시를 추가하고, 규칙 번호를 매깁니다.
사내 문서를 근거로 답하는 RAG 챗봇을 도입하면 대부분 비슷한 지점에서 막힙니다. 첫 질문에는 그럴듯하게 답하는데, 이어서 "그럼 그건 언제 바뀐 거야?" 같은 질문을 던지면 갑자기 엉뚱한 문서를 근거로 들고 옵니다. 사용자는 "AI가 헛소리를 한다"고 느끼고, 도입은 거기서 멈춥니다.
RAG(Retrieval-Augmented Generation)는 사용자의 질문과 관련된 외부 지식을 먼저 찾고, 그 근거를 언어 모델에 전달해 답변을 생성하는 방식입니다. 모델이 학습 과정에서 기억한 정보에만 의존하지 않으므로 조직의 최신 문서나 전문 자료를 답변에 반영하고 출처를 제시하기 좋습니다.
문서 검색과 질의응답을 결합한 RAG 시스템을 만들 때 가장 먼저 떠오르는 질문은 대개 비슷합니다.
AI를 잘 쓰는 핵심은 좋은 모델을 고르는 것만이 아닙니다. 모델에게 어떤 정보를 주고, 어떤 도구를 연결하고, 결과를 어떻게 검증할지까지 설계해야 실제 업무에 도움이 됩니다.