2025년 생성형 AI를 이용한 RAG 사업 PM를 수행하고(2026.1.4)

 2025년 AI 사업을 리딩하며 RAG 기반 서비스 프로젝트를 수행했습니다.

 아직 LangGraph나 NoCode기반 WorkFlow툴을 사용하지 않는

RAG 가 아직 실무에서 사업으로 진행된다는 것이 조금은 놀라웠습니다.

 

 프로젝트 중반부에 투입되어 짧은 기간 동안 전체 구조를 정리하고
실질적인 성과를 만들어야 하는 상황이었기에,
이 경험을 RAG 사업 PM 관점과 시니어 개발자 입장에서 정리해 보고자 합니다.

 

1. 데이터 전처리와 “초기 선택의 영향”

데이터 전처리 단계에서 현장의 개발 의견과
RFP에 명시된 요구사항 사이에 간극이 있었습니다.
내가 투입되기 약 두 달간 논의가 이어졌으나, ( 색인 구조 잡고 대상문서 선정하고 고객과 협의가 진행 )
결국 핵심 문서는 3일 만에 입력·처리되며 파이프라인이 가동되었습니다. ( 그외 처리가 더 필요한 내용은 별도 처리 )

 

이 과정에서 느낀 점은 명확했습니다.

• 처리 가능한 영역부터 실행하며 테스트 환경을 만드는 것
• 전체가 준비되지 않으면 시작하지 못하는 일부 개발자

이 차이가 프로젝트 후반부 생산성에 그대로 반영되었습니다.
RAG 사업에서는 완성도보다 조기 실험 가능한 구조가 중요하다는 점을 다시 확인한 계기였습니다.

2. RAG 품질 검증의 공백을 메우다

 문서가 검색 엔진과 연동된 이후,
프롬프트 엔지니어에게 평가셋 기반 RAG 답변 설계를 요청했습니다.
그러나 “테스트할 방법이 없다”는 답변을 받았습니다.

 원인은 기술이 아니라 구조 부재였습니다.

• 역할은 있으나 책임 단위가 명확하지 않음
• 설치 인력은 있으나 실무 협업이 이루어지지 않음
• 프롬프트 결과를 검증할 체계 부재

PM으로서 문제를 분해해 하나씩 해결했습니다.

3. PM 주도로 만든 실무형 RAG 평가 환경

다음과 같은 방식으로 즉시 활용 가능한 평가 환경을 구성했습니다.

• n8n + Qdrant 기반
  → 문서 파일 첨부만으로 전처리 완료, 프롬프트 평가셋 생성환경 제공
• React를 이용한 Rest Api호출 테스트 프로그램 제공
  → RAG 응답 → 참조 문서 매칭 여부와 테이블 구조 답변 등 답변의 상태체크

프로젝트 진행 중,
프롬프트 작업을 위한 ChatGPT 유료 계정이 필요하다는 요청이 있었고
이를 리스크 요소로 분류하여 즉시 조치했습니다.

이후에도

• 테스트 없이 결과만 논의되는 구조
• 단일 루틴 결과로 문제 원인을 추정하는 방식

의 한계를 느껴, 프롬프트 테스트 프로그램을 직접 제작해 제공했습니다.

4. 프로젝트를 통해 얻은 명확한 교훈

프로젝트 종료 시점에 얻은 가장 큰 인사이트는 다음과 같습니다.

LLM 결과의 품질은
프롬프트 엔지니어가 ‘LLM과 어떻게 대화해야 하는지’에 대한
확신을 갖고 있는지에 달려 있다

그 확신이 부족한 경우,
개발자와 바로 협업하기보다 기획·PM·고객과 먼저 정제된 요구를 만들고,
그 이후 개발과 연결하는 구조가 훨씬 안정적이라는 점을 확인했습니다.

5. 직접 구현한 RAG 검증·테스트 자산

프로젝트 과정에서 다음과 같은 실무형 도구와 프로그램을 직접 구성했습니다.

• G-Eval 기반 응답 평가 프로그램 ( 엑셀문서 연동 파이썬 프로그램, ChatGPT Api 사용 )
• RAG 조회 문서 키워드 반복 횟수 검사 도구 ( React )
• 프롬프트 적용 LLM 답변 테스트 (의도 분류 등) ( React )
• 테스트 질의 리스트 기반 ( 질의 리스트 엑셀문서 연동 및 결과 엑셀 저장 )
  → RAG 응답 + 참조 문서 매칭 여부와 테이블 구조 답변 등 답변의 상태체크 ( React )
• 다중 조건을 동시에 검증하는 RAG 멀티 테스트 프로그램
  (스레드 갯수를 GUI 제어 방식으로 약간의 시차를 주어 동시 입력 오류 개선된 배치 테스트 프로그램)

이는 단순 실험이 아니라
운영 가능한 품질 관리 체계를 목표로 한 시도였습니다.

6. 기술 선택과 개인적인 정리

이번 프로젝트에서는 회사 정책상 기술 선택에 제약이 있었지만,
n8n을 활용하며 No-Code 기반 서비스 개발의 가능성을 다시 확인했습니다.

GPU 메모리 제약으로 개인 프로젝트를 진행 못했던 부분도
이번 사업을 통해 상당 부분 해소할 수 있었고,
바이브 코딩과 검증·테스트 중심 개발을 병행하며
지금의 AI 시대에 맞는 개발 방식을 스스로 정리할 수 있었습니다.

 

마무리하며

2025년은 제한된 환경 속에서 사업을 수행한 해였다면,
2026년은 경험을 정리하고 다시 도전하는 해로 삼고자 합니다.

주니어 개발자의 한계,
그리고 AI가 ‘보완’이 아닌 ‘대체’로 검토되는 현장을 직접 경험하며
AI를 잘 활용하는 한 명의 실무형 프로그래머·PM으로
다음 단계를 준비하려 합니다.