운영 환경에서 보물찾기 엔진의 규칙을 다시 작성해야 했던 이유

우리가 실제로 해결하고 있었던 문제

나는 우리의 보물찾기 엔진(treasure hunt engine)을 운영 환경(production)에 배포하는 임무를 맡았으며, 시작부터 이것이 단순한 과정이 되지 않을 것임이 분명했습니다. 사용자들을 위한 퍼즐과 챌린지를 생성하도록 설계된 이 엔진은 자연어 처리 (Natural Language Processing, NLP)와 머신러닝 (Machine Learning, ML) 알고리즘의 복잡한 상호작용에 크게 의존했습니다. 시스템의 신뢰성과 성능을 보장해야 하는 책임자인 나는, 가장 중요한 파라미터(parameter)들이 개발 팀이 집중했던 것들과는 다르다는 것을 빠르게 깨달았습니다. 구체적으로, 우리 ML 모델의 지연 시간 트레이드오프 (latency tradeoffs)와 환각률 (hallucination rates)이 사용자 경험에 상당한 영향을 미치고 있었으며, 이러한 문제를 식별하고 해결하는 것은 나의 몫이었습니다.

우리가 처음 시도했던 것 (그리고 실패한 이유)

처음에는 개발 팀의 코드를 최소한의 수정만 거쳐 운영 환경으로 단순히 이식(port)하려고 시도했습니다. 하지만 이 접근 방식은 곧 부적절하다는 것이 증명되었습니다. 모델이 부정확하거나 터무니없는 출력을 생성하는 빈도를 의미하는 환각률 (hallucination rate)이 놀라울 정도로 높았고, 이는 저조한 사용자 경험으로 이어졌습니다. 게다가 시스템의 지연 시간 (latency) 또한 용납할 수 없는 수준이었으며, 일부 요청은 처리하는 데 10초 이상이 소요되었습니다. 우리는 모델의 파라미터를 미세 조정(tweaking)하고 할당된 컴퓨팅 자원을 조정함으로써 이러한 문제들을 해결하려 노력했지만, 이러한 노력들은 결국 실패했습니다. 시스템 아키텍처 (architecture)에 대한 보다 근본적인 재사고가 필요하다는 점이 명확해졌습니다.

아키텍처 결정

많은 논의와 분석 끝에, 우리는 규칙 기반 (rule-based) 시스템과 머신러닝 (machine learning) 기반 시스템의 장점을 결합한 하이브리드 접근 방식 (hybrid approach)을 구현하기로 결정했습니다. 우리는 규칙 기반 시스템을 사용하여 초기 퍼즐 구조를 생성하고, 그 다음 머신러닝을 활용하여 챌린지에 복잡성과 가변성의 계층을 추가하기로 했습니다.

이러한 접근 방식은 시스템의 환각률 (hallucination rate)과 지연 시간 (latency)을 크게 줄이는 동시에, 전반적인 유연성과 적응성을 향상시킬 수 있게 해주었습니다. 또한, 시스템의 서로 다른 구성 요소 간의 데이터 흐름을 처리하기 위해 Apache Kafka와 같은 메시지 큐 (messaging queue)를 사용하기로 결정했으며, 이는 시스템의 확장성 (scalability)과 신뢰성 (reliability)을 개선하는 데 도움이 되었습니다.

수치로 보는 결과
새로운 아키텍처 (architecture)가 구축된 후, 우리는 시스템 성능의 상당한 개선을 확인했습니다. 환각률은 25%에서 5% 미만으로 감소했고, 평균 지연 시간은 10초에서 1초 미만으로 떨어졌습니다. 이러한 수치는 우리의 새로운 접근 방식이 효과적이었음을 증명하는 증거였으며, 사용자 경험 (user experience)에 직접적인 영향을 미쳤습니다. 또한, 우리의 핵심 지표 중 하나였던 보물찾기 엔진과 관련된 고객 지원 요청 및 불만 건수도 크게 감소했습니다. 구체적인 지표 측면에서는 초당 100개의 요청 처리량 (throughput)을 달성했으며, 수개월 동안 99.9%의 가동 시간 (uptime rate)을 유지할 수 있었습니다.

다르게 했을 점
되돌아보면, 시스템을 운영 환경 (production)에 배포하기 전에 더 철저한 테스트와 검증을 수행했어야 했습니다. 어느 정도 테스트를 수행하기는 했지만 철저하지는 않았으며, 결국 시스템이 라이브 상태가 된 후에 몇 가지 문제를 발견하게 되었습니다. 또한, 시스템의 배포 및 운영화 (operationalization) 과정에서 개발 팀의 더 직접적인 참여를 이끌어냈어야 했습니다. 코드베이스 (codebase)에 대한 그들의 전문 지식과 지식은 우리가 문제를 더 빠르게 식별하고 해결하는 데 매우 귀중한 자산이 되었을 것입니다. 추가적으로, 시스템의 성능과 동작을 더 잘 파악하기 위해 Prometheus 및 Grafana와 같은 더 고급 모니터링 및 로깅 (logging) 도구를 사용했어야 합니다. 이러한 도구들을 사용했다면 문제를 더 빠르게 식별하고 대응할 수 있었을 것이며, 시간이 지남에 따라 시스템의 동작에 대한 더 상세한 통찰력을 얻을 수 있었을 것입니다.