Open AI Realtime RAG 앱 구현 전체 과정 회고 [2편]

1. 앱 동작과 첫 번째 실수

OpenAI Realtime API를 활용한 RAG 시스템 구축이 목표였습니다. 유사 코드를 참고하고 AI의 도움을 받아 코드를 수정하면서, Azure 클라우드 서비스 문서를 따라 기본 앱을 구동시키는 데까지는 순조로웠습니다.

 

하지만 첫 번째 실수가 여기서 시작됐습니다. 기본 PDF 파일로 RAG를 테스트했을 때, 앱이 정상적으로 작동하는 것처럼 보였기 때문입니다. LLM이 자체 데이터베이스를 기반으로 답변한 것인지, 실제로 RAG가 제대로 작동한 것인지 검증하지 않은 것이 후속 문제의 뿌리가 되었습니다.

2. 데이터 통합 과정에서 드러난 첫 번째 이슈

자신감을 가지고 7,000개의 대화 데이터셋을 통합하려 했지만, Vector DB가 데이터를 제대로 가져오지 못하는 문제에 직면했습니다.

저는 세 가지 가능성을 의심했습니다:

1. 인덱싱을 위한 필드 변수 오류
2. 프롬프트 메시지 불충분
3. Ragtool.py의 변수 설정 문제

JSON 형식의 데이터를 PDF로 변환하고 인덱싱 변수를 수정하자 리트리버 문제가 해결되는 듯했습니다. 이 과정에서 Ragtool.py의 Tool 함수 스키마 관련 JSON 키값도 수정했는데, 이것이 후에 심각한 문제를 일으킬 줄은 몰랐습니다. 첫 번째 가설이 맞아 보이자 나머지 가설들은 검증도 하지 않고 넘어가는 실수를 저질렀습니다.

3. 두 번째 이슈: 잘못된 원인 분석이 부른 혼란

인덱싱 문제가 해결된 것 같았으나, 이번에는 프롬프트 메시지가 입력되지 않는 새로운 문제가 발생했습니다. 로그 분석, 프론트엔드와 백엔드 코드 검토를 거치면서 세션 업데이트와 웹소켓 통신 시점의 차이를 의심하게 되었습니다.

 

처음에는 비동기 함수 처리 지연을 원인으로 지목했지만, await 함수 분석 과정에서 이것이 잘못된 생각임을 깨달았습니다. 세션 업데이트 설정 메시지를 웹소켓 통신 직후 즉시 전송하도록 수정했고, 놀랍게도 작동했습니다.

 

하지만 이 또한 일시적인 성공에 불과했습니다. 다음날 프롬프트가 다시 작동하지 않았기 때문입니다. 진짜 문제는 엉뚱한 곳에 있었습니다. Ragtool.py에서 Tool 스키마 파라미터 값을 Required에서 Auto로 변경한 것이 원인이었던 것입니다. 이전에 작동했던 이유는 웹소켓 통신 직후 코드를 단순화하면서 Tool 설정을 완전히 누락시켰기 때문이었습니다. 잘못된 설정이 전송되지 않아 우연히 작동했던 거죠.

4. 세 번째 이슈: RAG 연결 안정화

실제 문제를 찾았다고 생각했지만, RAG 연동은 여전히 불안정했습니다. Auto 설정으로는 필요한 문서를 제대로 참조하지 못했고, Required로 설정을 변경하자 이번에는 AI가 응답을 멈추는 새로운 문제가 발생했습니다.

Vector DB에서 데이터는 가져오지만, response.done → response.create가 무한 루프를 도는 현상이 발생했습니다. 더 상세한 로깅을 구현하고 OpenAI Developer 문서를 샅샅이 조사했지만, 결국 Required 옵션은 실제로는 작동하지 않는다는 것을 알게 되었습니다. Auto만 지원된다는 현실을 받아들여야 했습니다.

5. 현실적인 판단과 배포 과정

결국 RAG의 완벽한 구현을 잠시 미루기로 결정했습니다. 사용자 경험을 위한 문장 생성 품질 개선이 더 시급하다고 판단했기 때문입니다. 하지만 배포 과정에서 새로운 도전이 기다리고 있었습니다. Vite/React 프론트엔드와 Python 백엔드를 통합하고, 호스팅 서버에 패키지를 설치하는 과정에서 Docker를 도입해야 했습니다.

 

Docker 구현은 쉽지 않았습니다. 설치 경로 문제, 패키지 누락, 로그 파일 권한 문제가 연이어 발생했고, start.sh 파일도 수정이 필요했습니다. 10번이 넘는 수정과 Git 커밋 끝에 마침내 배포에 성공할 수 있었습니다.

6. 앱 구현 및 배포를 통해 얻은 레슨

약 1달 가량을 이 앱을 작동시키고, 오류를 해결하는데 썼습니다. 아래와 같은 점이 기억에 남네요.

 

1. 모든 가설은 끝까지 검증해야 합니다. 하나의 해결책이 작동한다고 다른 가능성을 배제하면 안 됩니다.
2. 초기 검증의 중요성을 절실히 깨달았습니다.
3. 체계적인 로깅은 문제 해결의 핵심입니다.
4. 사용하는 기술에 대한 깊은 이해가 필요합니다.
5. 때로는 완벽한 기술적 구현보다 사용자 가치가 우선일 수 있습니다.
6. Git을 통한 코드 변경 추적으로, 사소해 보이는 코드 변경이 실제 원인일 수 있음을 항상 염두에 두어야 합니다.

7. 한계 및 계획

현재 이 앱은 부분적으로만 작동하는 상태로 배포되어 있습니다. 개선의 여지는 많지만, Realtime API가 베타 버전이라는 점을 감안하면 향후 발전 가능성을 확인할 수 있었습니다.

 

이 경험을 통해 코딩에 대해 더 배울 수 있었고 , 앞으로는 체계적인 접근 방식을 채택할 계획입니다.

 

가즈아!