피드로 돌아가기
Dev.toInfrastructure
원문 읽기
동시 접속자 50명 한계를 1,000명으로 확장한 시스템 재설계 및 비즈니스 모델 전환
I was hired to manage the code, not write it. I left as their CTO.
AI 요약
Context
외부 벤더가 구축한 Monolithic 구조로 인해 50명 이상의 Concurrent User 발생 시 시스템 지연 및 서버 비용 급증 발생. Database Connection Pooling 부재와 비효율적인 Join 쿼리, Frontend의 Backend 직접 명령 수행 등 설계 전반의 심각한 결함으로 인한 확장성 상실 상태.
Technical Solution
- Monolithic 구조를 Microservices 및 Component 기반으로 분해하여 상호 의존성 제거 및 유지보수성 향상
- Distributed Processing 및 Sticky Sessions 도입을 통한 동시 접속자 처리 병목 지점 해결
- Fixed Cost 기반 서버를 Google App Engine 기반의 Usage-based Cloud 환경으로 이전하여 트래픽 최적화
- Incident Response 체계 정의 및 모니터링/배포 자동화 구축을 통한 외부 벤더 의존적 운영 구조 탈피
- White-label App 구조의 멀티 테넌시 전략 도입을 통한 브랜드 독립성 확보 및 심리적 진입 장벽 제거
Impact
- Concurrent User 수치 6명에서 약 1,000명으로 급증
- 계약 학원 수 14개로 확대 및 비즈니스 성장 가속화
Key Takeaway
단순한 버그 수정(Patch)보다 근본적인 아키텍처 재설계(Rebuild)와 운영 책임 소재(Accountability) 명확화가 시스템 생존의 핵심임. 기술적 해결 이후에는 비즈니스 모델과 기술 구조의 정렬(Alignment)을 통해 실제 성장 동력을 확보해야 함.
실천 포인트
- 동시 접속자 급증 시 특정 지점에서 성능 저하가 반복되는지 확인하여 병목 구간 식별 - 외부 벤더 의존도가 높은 시스템의 경우 운영 가용성(Availability) 및 장애 대응 프로세스 점검 - 기능 추가 시 '불가능하다'는 답변이 반복될 경우 기술 부채로 인한 아키텍처 한계 도달 여부 검토 - 고정 비용 서버 모델에서 사용량 기반 Cloud 모델로의 전환을 통한 비용 효율성 분석