최수빈
해커톤에서 하루 만에 만든 RAG 서비스를, 실제 서비스로 만들며 느낀 점 세가지
사내 해커톤에서 1등한 제품을 실제 서비스로 만들기 위해 대략 2개월이 넘는 시간이 걸렸습니다. 해커톤 당일 하루만에 만들었을 때와 기능은 별반 차이가 없는데 말이죠? 😂 더군다나 AI를 활용해 그럴싸한 프로덕트를 뚝딱 만드는 이 세상에 왜이렇게 오래걸렸나 싶으실텐데... 실제 지속 가능한 서비스로 만드는 건 (심지어 AI를 곁들인..) 전혀 다른 세상의 이야기였기 때문입니다.
1. 기술을 모르고 만들 순 있음. 하지만? 실제 서비스는 알고 만들어야 함
실제 AI 제품을 만들고 계시는 외부 전문가의 커피챗으로 실무 지식을 얻고, 그 커피챗에서 가져온 수많은 낯선 단어들을 끊임없는 학습했습니다. 이걸 바탕으로 <뭐RAG하는거야>라는 웃긴 제목으로 사내 세미나도 진행해서 모든 팀원들과 RAG의 전반적인 지식을 나누기도 했고요. 하루 만에 완성했던 프로토타입과 달리, 실제 서비스로 구현하려면 모든 과정에서 기술을 기본적인 부분들은 반드시 이해하고 있어야했어요. 해커톤에선 이해없이 뚝딱 만들 수 있었지만요.
2. 나의 서비스를 토큰 믹서기를 만들고 싶지 않다면 비용을 계산해야한다..
AI 서비스의 지속 가능성을 결정짓는 중요한 요소는 비용입니다. 하루짜리 프로토타입에선 신경 쓰지 않았던 운영 비용과 최적화 전략을 고려하지 않을 수 없었습니다. API 호출 횟수를 줄이고 효율적으로 데이터를 처리하는 방법을 고민하며 비용 효율을 처음보다 59%나 향상시켰습니다. (물론 한참 더 낮춰야하지만요..) 여기엔 PM분이 만들어준 RAG 서비스 비용 계산기가 참 도움이 많이 됐습니다. (llm api 호출 비용, 임베딩 모델 사용 비용 등..) 이 계산기가 없었다면 현실적이고 지속 가능한 가격 구조를 만들어내는 것이 생각보다 더 어려웠을 것 같습니다.
3. 트라이 앤 에러, 즉 노가다는 필수
AI 기술을 쓴 프로덕트는 멋지지만 그걸 만들기 위한 과정에서 소위 노가다... 라고 하는 트라이엔에러 식의 테스트와 개발 과정이 필요했습니다. 여러 프롬프트, p값, 온도, 모델들을 빠르게 실험하고, 실패하고, 다시 시도했습니다. 해커톤에서는 "일단 작동"하는 결과물이 중요했지만, 실제 서비스에선 "모든 상황에서 안정적으로 작동"하는 시스템을 만드는 것이 핵심이었습니다. 이 과정에서 트라이 앤 에러는 무슨 발전이 있든 필수적이겠단 생각을 했습니다 ㅋㅋㅋㅋㅋ
해커톤에서 아이디어가 실제 서비스로 성장하는 과정은 단순히 더 많은 시간이 필요한 것이 아니라, 기술에 대한 깊은 이해와 전략적인 비용 관리, 그리고 끈질긴 실험과 인내심이 요구되는 긴 여정이었네요...
이 학습점을 가장 생생할 때 적어두려고 블로그 글로 적어두었으니 기술적인 실제 구현이 궁금한 분들은 읽어보셔도 좋을 것 같습니다. RAG 서비스 계산기에 어떤 항목이 포함되었는지도 써두었습니다!