Rails 애플리케이션 배포의 역사는 웹 기술의 발전과 궤를 같이합니다.
1. 초기 웹 배포 (1991년 ~ 1993년)
- HTML 및 FTP: 웹 초기에는 주로 HTML 파일이 배포되었으며, FTP를 통해 공유 호스팅 서버의 홈 디렉토리에 파일을 업로드하는 방식이 일반적이었습니다. VI 에디터를 사용하여 서버에서 직접 파일을 편집하기도 했습니다.
- CGI (Common Gateway Interface): 1993년, 동적인 웹 페이지의 필요성으로 CGI가 등장했습니다. 웹 서버가 요청을 받으면 Perl 스크립트와 같은 외부 프로그램을 포크(fork)하여 실행하고, 그 결과를 다시 브라우저에 전달하는 방식이었습니다. 이는 각 요청마다 새로운 프로세스를 생성하여 성능 오버헤드가 컸습니다.
2. PHP 및 Mod Ruby의 시대 (1997년 ~ 2004년)
- PHP (PHP Hypertext Preprocessor): 1997년 PHP 3.0이 출시되며 CGI의 한계를 극복했습니다. PHP 인터프리터를 웹 서버 내부에 통합(mod_php)하여 각 요청마다 프로세스를 생성할 필요 없이 더 효율적인 처리를 가능하게 했습니다.
- Mod Ruby의 시도: PHP와 유사하게 Ruby 인터프리터를 Apache 내부에 통합하려는 Mod Ruby가 있었으나, 안정성 문제와 애플리케이션 간 격리 부족으로 인해 실용적이지 못했습니다.
3. Rails의 등장과 배포의 진화 (2004년 ~ 2009년)
- Rails 초기 (CGI 및 FastCGI): 2004년 Rails가 공개된 후, 초기에는 CGI로 배포되었으나 곧 성능 문제에 직면했습니다. 이후 FastCGI (및 SCGI)가 대안으로 부상했습니다. 이는 웹 서버와 별도의 데몬 프로세스를 통해 애플리케이션을 실행하는 방식이었으나, 불안정하고 취약하다는 단점이 있었습니다.
- Mongrel 및 Mongrel Cluster: Ragel 파서를 기반으로 한 Mongrel은 HTTP를 직접 처리하며 Apache와 같은 웹 서버는 프록시 역할만 수행하는 방식으로 효율성을 높였습니다. Mongrel Cluster는 여러 Mongrel 프로세스를 실행하여 동시 요청 처리를 가능하게 했으나, 개발자가 프로세스 관리를 직접 해야 하는 부담이 있었습니다 (Monit, God 등).
- Capistrano (2006년): 배포 자동화의 전환점이 된 Capistrano는 SSH를 통해 원격 서버에 코드를 배포하고 애플리케이션을 재시작하는 등의 작업을 스크립트로 처리하여 개발자의 수작업 부담을 크게 줄였습니다.
- Passenger: Apache나 Nginx 내에서 Ruby 애플리케이션을 격리된 환경으로 실행하는 Passenger는 별도의 프로세스 관리 없이 웹 서버에 통합되어 편리성과 성능을 제공하며 빠르게 인기를 얻었습니다.
4. 현대적 배포 방식 (2009년 이후)
- Unicorn, Puma, Thin: Mongrel의 아이디어를 계승한 Unicorn (프로세스 포크), Puma (멀티스레드), Thin (이벤트 기반)과 같은 애플리케이션 서버들이 등장하여 동시성 처리와 안정성을 개선했습니다.
- Heroku: 2009년 Heroku의 등장은 배포 패러다임을 혁신했습니다.
git push heroku master명령 하나로 인프라 관리 없이 애플리케이션을 배포할 수 있게 하여 개발자들이 시스템 관리 부담에서 벗어나게 했습니다. - Docker (2013년): “내 컴퓨터에서는 되는데…” 문제를 해결한 Docker는 애플리케이션과 그 종속성을 컨테이너로 묶어 어떤 환경에서든 일관되게 실행될 수 있도록 보장했습니다. 이는 배포의 안정성과 이식성을 획기적으로 향상시켰습니다.
- Kamal: Docker 기반의 배포 도구인 Kamal은 Capistrano의 정신을 이어받아 Docker 컨테이너를 원격 서버에 배포하고 관리하는 과정을 간소화했습니다. CI/CD 파이프라인과 통합되어 자동화된 배포가 가능해졌습니다.
- 최신 배포 옵션: 오늘날에는 CI/CD, Docku, Koolifi와 같은 Heroku 유사 환경, Docker Swarm, Docker Compose, Kubernetes, 그리고 Fly.io, Render와 같은 클라우드 플랫폼 등 다양한 배포 옵션이 존재하여 개발자들은 각자의 요구에 맞는 최적의 솔루션을 선택할 수 있습니다.