서버에 코드 배포

1. 코드에 변경 사항 적용

앞서 말했듯이 소프트웨어 개발은 결국 코드에 작은 변경을 반복해서 넣는 일입니다. 수십 년 동안 전 세계 수백만 명의 프로그래머가 이 과정을 수행해 왔고, 그 결과 온갖 방식으로 정교하게 다듬어지고 표준화·체계화되었습니다.

코드를 저장하기 위한 전용 도구가 바로 – Git입니다. Git은 분산형 버전 관리 시스템입니다. 단순히 코드를 보관하는 것을 넘어, 모든 변경 이력을 추적하고 개발자들이 서로 방해하지 않으면서 함께 프로젝트를 진행하도록 도와줍니다 🤝.

Git을 사용하면 개발자는 프로젝트의 다양한 버전(브랜치)을 만들고, 전체 변경 이력을 보존하며, 과거의 어느 시점으로든 되돌아갈 수 있습니다. 말 그대로 코드용 타임머신이죠! Git은 변경 사항을 병합하고 충돌을 해결하는 데 도움을 주기 때문에, 현대 개발에서 팀 협업의 핵심 도구가 되었습니다. 👩‍💻

2. 프로젝트 빌드

프로젝트를 테스트하거나 서버에 올리기 전에 먼저 빌드해야 합니다.

🏗️ 프로젝트 빌드는 프로젝트의 소스 코드를 실행 가능한 프로그램이나 다른 실행 형식으로 컴파일하는 과정이며, 종종 테스트와 배포까지 포함합니다. 이는 소프트웨어 개발의 핵심 요소로, 프로그램을 사용 가능한 상태로 만드는 단계입니다.

빌드는 단순한 컴파일이 아닙니다(물론 컴파일이 빌드 과정의 일부인 경우가 많습니다). 빌드가 끝나면 다양한 서버에 업로드해야 하는 파일이 수십, 많게는 수백 개 생길 수 있습니다.

빌드 도구는 다음과 같은 저수준 도구가 있을 수 있습니다:

• ☕ Maven과 Gradle – Java 프로젝트에서 의존성 관리와 빌드에 널리 사용됩니다.
• 🐜 Apache Ant – 또 다른 Java 빌드 도구로, 빌드 스크립트를 유연하게 작성할 수 있습니다.
• 🖥️ MSBuild – Microsoft Visual Studio로 만든 프로젝트의 빌드에 사용됩니다.
• ⚙️ Make – Makefile로 빌드 규칙을 정의하는 고전적인 빌드 도구로, 특히 C 및 C++ 프로젝트에서 널리 쓰입니다.
• 🌐 Webpack – JavaScript 애플리케이션 빌드에 자주 사용되며, 의존성과 모듈을 관리합니다.
• 📜 Gulp와 Grunt – 파일 최소화, SCSS를 CSS로 컴파일 등 웹 개발에서 자주 수행되는 작업을 자동화하는 데 도움을 주는 도구입니다.

또한 고수준 빌드 도구들도 있습니다. 이에 대해서는 아래에서 다룹니다.

3. CI/CD

🔄 CI/CD (Continuous Integration/Continuous Delivery)는 모든 개발 브랜치의 변경 사항을 지속적으로 메인 브랜치에 통합하고, 이를 자동으로 테스트하고 배포하는 방법론입니다. 이를 통해 오류를 빠르게 발견하고 수정하여 개발의 효율과 속도를 높일 수 있습니다.

가장 널리 쓰이는, 다소 구식이긴 하지만, CI/CD 시스템 중 하나가 Jenkins입니다. 소규모 회사라면 80% 확률로 이것을 사용한다고 봐도 됩니다.

🤖 Jenkins는 지속적 통합과 전달(CI/CD)에 사용되는 인기 있는 자동화 시스템입니다. Jenkins를 사용하면 소프트웨어 개발의 다양한 단계(빌드, 테스트, 배포 등)를 자동화하여 코드 품질을 개선하고 개발 속도를 높일 수 있습니다.

대기업에 가면 다음과 같은 선택지가 추가로 있을 수 있습니다:

• 🚦 TeamCity – JetBrains의 강력한 상용 제품으로, 다양한 개발 및 테스트 환경과의 깊은 통합을 제공합니다.
• 📝 GitLab CI – GitLab에 내장되어 있으며, YAML 파일을 통해 구성 가능한 지속적 통합과 전달을 제공합니다.
• ☁️ CircleCI – 여러 프로젝트의 테스트와 배포 자동화를 지원하는 클라우드 기반 CI/CD 서비스입니다.
• 🦑 Travis CI – 가장 초기의 클라우드 CI 서비스 중 하나로, 다수의 오픈 소스 프로젝트에서 사용됩니다. GitHub과의 통합이 우수합니다.
• 🎍 Bamboo – Atlassian의 제품으로, Jira와 Bitbucket 등 이 회사의 다른 도구들과 긴밀하게 통합됩니다.

이 도구들을 모두 알거나 다룰 줄 알 필요는 없습니다 — 보통 회사에는 이러한 프로세스를 설정하는 DevOps 전문가가 있습니다. Jenkins, CI/CD 또는 “continuous integration(지속적 통합)” 같은 말이 대화에서 나오면 무슨 이야기인지 이해할 정도면 충분합니다.

4. 프로젝트를 서버로 전달하기

코드를 작성하는 것만으로는 부족합니다 — 결국 서버에 올라가 있어야 하죠. 일반적으로 서버에 프로젝트를 배포(디플로이, deploy)한다는 것은 웹 애플리케이션을 서버에 배치하고 활성화하여 인터넷을 통해 사용자가 접근할 수 있도록 만드는 과정을 말합니다 🚚.

이 과정에는 프로젝트 파일을 서버로 옮기고, 서버 환경·데이터베이스·의존성을 설정하며, 네트워크 설정과 보안까지 구성하는 일이 포함됩니다 😅.

그럼 코드가 서버로는 어떻게 갈까요? 누군가가 직접 올려 줄까요? 아니면 여러분이 원격 서버에 SSH로 접속해 몇 개 파일을 올리고 이것저것 설정을 해야 할까요? 걱정 마세요: 이제 그렇게 하지는 않습니다. 지금은 Docker가 있습니다.

🐳 Docker는 컨테이너를 이용해 애플리케이션을 개발·전달·실행하는 플랫폼입니다. Docker는 모든 의존성과 실행 환경을 함께 묶어 하나의 컴팩트한 객체로 패키징하여 애플리케이션의 생성, 배포, 실행을 단순화합니다. 이를 통해 개발부터 테스트, 프로덕션까지 모든 단계에서 환경의 일관성을 보장합니다.

Docker는 여러분의 프로젝트(들)를 Docker 컨테이너로 포장할 수 있게 해줍니다. 이는 일종의 가상 머신과 비슷합니다.

Docker 포럼 어디에서든 Docker를 “가상 머신”이라고 부르면 돌맞을 수 있지만, 개념적으로 Docker 컨테이너를 가상 머신처럼 생각해도 됩니다. 다만 훨씬 더 가볍다는 점이 다를 뿐이죠.

본질적으로 Docker 컨테이너는 일종의 “가상 머신”입니다. 가상 머신은 운영체제 전체와 OS 커널, 가상 하드웨어까지 포함하지만, Docker 컨테이너는 호스트의 커널을 공유하므로 더 가볍고 빠를 수 있습니다 ⚡.

Docker를 이용한 배포는 과정을 크게 단순화하면서 빠르고 신뢰성 높게 만듭니다. 프로젝트는 Docker 컨테이너로 패키징되어 Docker를 지원하는 어떤 시스템에서든 손쉽게 옮기고 실행할 수 있습니다 🚢.

이는 서버 환경 차이로 인한 문제를 없애 주고, 부하에 따라 컨테이너를 추가·제거하는 방식으로 애플리케이션을 손쉽게 확장할 수 있게 해줍니다. 모두가 Docker로 넘어간 이유가 있죠 — 정말 편하고 매우 단순합니다.