1. 기존 아키텍처의 한계와 복잡성
기존의 PrayAI는 기술적으로는 타당한 선택이었으나, 실제 운영 면에서는 과도한 복잡성을 야기했습니다. - 분산된 코드베이스: 백엔드(Node.js), 모바일(React Native), 웹(Next.js), 랜딩 페이지, 이메일 템플릿 등 총 4개의 저장소와 6개의 코드베이스로 나누어져 있었습니다. - 비대한 인프라: 15개 이상의 AWS 관리형 서비스와 35,934라인에 달하는 CloudFormation 템플릿이 필요했습니다. 이는 실제 비즈니스 로직(12,900라인)의 약 2.8배에 달하는 규모였습니다. - 업그레이드 및 유지보수 비용: 주요 프레임워크의 버전이 뒤처지면서 이를 최신화하는 데만 약 48,000~78,000달러의 비용이 예상되는 상황이었습니다.
2. Rails 8과 Turbo Native를 통한 통합
재구축된 플랫폼은 Rails 8의 최신 기능을 활용하여 극도로 단순화된 구조를 가집니다. - 단일 애플리케이션 구조: 비즈니스 로직, UI, 데이터 처리를 하나의 Rails 앱으로 통합했습니다. - SQLite3 기반의 스택: Rails 8의 기본 설정인 SQLite3를 사용하여 데이터베이스, 캐시(Solid Cache), 작업 큐(Solid Queue), 웹소켓(Solid Cable)을 모두 처리합니다. 이를 통해 Redis나 별도의 메시지 큐 없이도 운영이 가능해졌습니다. - Kamal을 이용한 배포: 복잡한 Kubernetes나 Terraform 대신 Kamal과 Docker를 사용하여 단일 서버에 배포하며, 배포 설정 파일은 184라인으로 줄어들었습니다. - Turbo Native의 활용: iOS와 Android는 각각 Swift와 Kotlin으로 작성된 얇은 네이티브 쉘(Shell)만 사용하며, 실제 화면은 Rails에서 서버 사이드 렌더링된 HTML을 Turbo Native를 통해 렌더링합니다.
3. 전환 이후의 주요 지표 변화
플랫폼 재구축은 비용과 속도 측면에서 압도적인 결과를 보여주었습니다. - 인프라 코드 감축: 35,934라인에서 184라인으로 175배 감소했습니다. - 운영 비용 절감: 월 2,250달러였던 호스팅 비용이 50달러로 줄어들었으며, 연간 약 262,500달러의 비용 절감이 예상됩니다. - 개발 속도 향상: 기존에 기능을 배포하기 위해 9단계의 과정을 거쳐야 했던 것과 달리, 이제는 Rails 앱 수정 후 단 한 번의 배포로 웹과 모바일 앱 모두에 즉시 반영됩니다. 기능 개발 속도는 2배 이상 빨라졌습니다. - 온보딩 단축: 신규 개발자가 적응하는 데 3~4개월이 걸리던 이전과 달리, 이제는 2~4주면 충분합니다.
4. 기술적 시사점: ‘배관’보다 ‘제품’에 집중하기
이번 사례는 기술적 정교함이 반드시 비즈니스 가치로 직결되지 않음을 시사합니다. - 적정 기술의 선택: Lambda, DynamoDB 등은 훌륭한 도구이지만, 규모에 맞지 않는 도입은 개발자가 고객의 문제보다 플랫폼의 문제를 해결하는 데 시간을 낭비하게 만듭니다. - 통합의 힘: Turbo Native를 통해 코드 재사용성을 극대화함으로써, 동일한 팀으로 더 적은 비용에 더 많은 기능을 출시할 수 있게 되었습니다.