💡 프로프트(Propt) 프로젝트
한 번의 프롬프팅으로 여러 개의 답변을 얻을 수 있는 AI Agent용 MCP 도구입니다.
이번 글에서는 Propt 개발 중 고민했던 '레디스 도입 여부'에 대한 내용을 공유합니다.
프로프트가 궁금하다면, 레포지토리를 확인해보세요!
Redis(레디스)는 참 매력적인 도구입니다.
빠르고, 적용도 간편하고, 무엇보다 인메모리 DB라는 점에서 TTL만 설정하면 불필요한 데이터가 쌓일 걱정이 없습니다.
프로프트의 게스트 로그인 기능을 구현하는 과정에서 자연스럽게 레디스 도입을 생각했습니다만, 고민 끝에 도입하지 않기로 했습니다.
왜 그런 선택을 했는지, 그 이유를 정리해보았습니다.
1. 도입에 들어가는 비용
이때 말하는 '비용'이란, 단순히 금전적인 서버 비용만을 의미하지 않습니다.
- 새로운 라이브러리를 도입하면서 발생하는 프로젝트 볼륨 증가
- 라이브러리의 업데이트에 맞추어 유지보수하는 데에 들어가는 비용
- 새로운 라이브러리를 학습하는 데에 들어가는 비용
- Redis 연결 실패, 타임 아웃 등 새로운 에러 케이스 대응에 소요되는 비용
- 기존 라이브러리와의 호환성을 유지하는 데에 들어가는 비용
이처럼 단순히 '좋으니까 쓴다'라고 하기엔, 도입 자체만으로 감수해야 할 잠재적 비용이 적지 않았습니다.
2. 대체 불가능 여부
Redis를 통해 구현하고자 했던 핵심 기능은 단순했습니다.
게스트 로그인 정보를 저장하고, 24시간이 지나면 자동으로 삭제하기
위 기능은 정말 Redis를 사용하는 것 말고는 구현할 수 있는 방법이 없는걸까요?
기존에 사용 중이던 RDBMS로는 불가능할까요?
결론부터 말하면, 가능했습니다!
현재 프로프트에서는 게스트 로그인 정보를 메인 DB에 저장하고, 생성 시간을 함께 기록하고 있습니다.
그리고 Cron 작업을 통해 새벽 3시마다 생성된 지 24시간이 지난 게스트 로그인 계정을 삭제하는 과정을 수행하고 있습니다.
Redis 없이도 충분히, RDBMS만으로 게스트 계정을 삭제할 수 있었습니다.
3. 정말 필요할까?
솔직히 말해서, 아직 프로프트가 Redis가 필수적일 만큼의 트래픽이 발생하지 않습니다. 🤣
동시 접속자 수가 수천 명 단위도 아니고,
1ms 이내에 빠른 응답을 기대해야 하는 실시간성이 중요한 서비스도 아닙니다.
오히려 당장 중요하게 생각해야 할 부분은,
- 프로프트의 사용법을 사용자로부터 빠르게 익히게 하는 방법
- 조금 더 적은 토큰을 사용해서 병렬 처리를 하도록 하는 방법
- '프롬프트'와 '프로프트' 사이에서 LLM이 헷갈리지 않고 MCP를 수행하도록 하는 방법
처럼 '어떻게 사용자가 더 프로프트를 편하게 사용할 수 있을까?'에 대해 더 고민해야 한다고 생각했어요.
지금 '꼭!' 필요하지 않은데,
성능을 위해, 개발 편의성을 위해 레디스를 도입한다는 생각이, 오버 엔지니어링이라고 느껴졌습니다.
Redis는 정말 훌륭한 도구입니다.
언젠가 프로프트의 사용자가 급증한다면, 그때는 기쁜 마음으로 Redis를 도입하겠지요. 😁
하지만 '지금'의 저에게는 아직 필요하지 않다고 생각합니다.
좋은 도구를 통해 훌륭한 성능을 만들어내는 것도 개발자로서 정말 멋지지만,
한정된 자원 안에서 근거있는 선택을 통해 효율적인 결과를 내는 것도 개발자의 역할이 아닐까요?
'아~ 개발했다~' 하는 뿌듯함이 들었던 경험입니다.
