[66일차]웹 개발 파이프라인 구축과 도커(Docker)의 활용

1. 서론: 풀 사이클(Full Cycle) 개발과 파이프라인의 이해

현대의 소프트웨어 개발은 단순히 코드를 작성하는 것을 넘어, 개발된 코드가 실제 사용자에게 전달되고 운영되는 전체 과정을 포괄한다. 이를 풀 사이클 개발이라고 하며, 이 과정의 핵심은 개발부터 배포까지의 흐름을 효율적으로 연결하는 파이프라인의 구축이다. 본 보고서에서는 전통적인 인도 프로세스의 한계를 극복하기 위한 CI/CD 방법론과 이를 실현하는 핵심 도구인 도커(Docker)를 중심으로 웹 개발 파이프라인 구축에 대해 논한다.

---

2. 소프트웨어 인도 프로세스의 변화

2.1 전통적인 인도 프로세스와 한계

과거의 소프트웨어 인도는 '개발(Development) → 품질 보증(QA) → 운영(Operation)'이라는 순차적이고 분절된 단계를 거쳤다. 개발팀이 코드를 작성하면 QA팀이 테스트를 수행하고, 이후 운영팀이 배포를 담당하는 방식이다. 이러한 방식은 부서 간 소통 비용을 증가시켜 인도 기간을 지연시키고, 피드백 주기를 늦추며, 핫픽스와 같은 긴급 상황 대응에 취약하다는 구조적 단점을 지닌다. 또한, 수동으로 이루어지는 반복 작업은 자동화의 부재로 이어져 개발 문화의 건전성을 저해하는 요인이 된다.

2.2 지속적 통합 및 배포(CI/CD)

전통적인 방식의 비효율을 해결하기 위해 등장한 개념이 CI/CD이다. 이는 소프트웨어의 인도와 배포 과정을 자동화하여 개발 생산성과 안정성을 높이는 방법론이다.

• 지속적 통합(CI, Continuous Integration):
  개발자가 작성한 코드를 정기적으로 빌드하고 테스트하여 공유 리포지토리에 통합하는 과정이다. 이를 통해 코드의 충돌을 조기에 발견하고 소프트웨어의 품질을 지속적으로 유지한다.
• 지속적 인도/배포(CD, Continuous Delivery/Deployment):
  통합된 코드를 릴리즈 가능한 상태로 준비하고(Delivery), 실제 프로덕션 환경에 자동으로 배포(Deployment)하는 과정이다. 여기에는 QA 및 운영 팀의 역할이었던 인수 테스트(UAT)와 구성 관리가 포함된다.

성공적인 CI/CD 구현을 위해서는 자동화된 빌드/테스트/배포 시스템, 신속한 장애 복구 능력, 무중단 배포 전략, 그리고 트렁크 기반의 개발 방식이 전제되어야 한다. 이를 위해 젠킨스(Jenkins)와 같은 자동화 서버, 앤서블(Ansible)과 같은 구성 관리 도구, 깃허브(Github)와 같은 버전 관리 시스템이 유기적으로 연결되어야 한다.

---

3. 컨테이너 가상화 기술: 도커(Docker)

CI/CD 파이프라인에서 가장 중요한 요소 중 하나는 '어떤 환경에서도 동일한 실행을 보장하는 것'이다. 이를 실현하는 핵심 기술이 바로 컨테이너 가상화이다.

3.1 컨테이너화(Containerization)의 정의

컨테이너화란 애플리케이션 실행에 필요한 소스 코드, 설정 파일, 라이브러리 및 의존성 등을 하나의 패키지(컨테이너)로 묶어 관리하는 기술이다. 이를 통해 시스템 의존성을 최소화하여 이식성을 극대화할 수 있다. 즉, 개발자의 로컬 환경, 테스트 서버, 클라우드 운영 환경(AWS, Azure 등) 어디에서든 예측 가능한 소프트웨어 실행 환경을 제공한다.

3.2 가상 머신(VM)과 컨테이너의 차이

가상화는 물리적 하드웨어 리소스를 추상화하는 기술이다. 기존의 가상 머신(VM) 방식은 하드웨어 전체를 가상화하고 그 위에 게스트 OS를 별도로 설치해야 하므로 무겁고 부팅 속도가 느리다. 반면, 도커와 같은 컨테이너 가상화는 호스트 OS의 커널을 공유하고, 컨테이너 엔진을 통해 애플리케이션 실행 환경(User Space)만 격리한다. 따라서 VM에 비해 훨씬 가볍고 빠르며 리소스 효율성이 뛰어나다. 이러한 특성은 신속한 배포와 확장이 필요한 CI/CD 환경에 최적화되어 있다.

---

4. 도커의 구성 요소 및 활용

도커는 컨테이너 기반의 가상화 플랫폼으로, 리눅스, 윈도우, 맥OS 등 다양한 OS 위에서 실행된다. 도커를 효과적으로 사용하기 위해서는 다음의 핵심 개념과 기능을 이해해야 한다.

4.1 도커 이미지(Image)와 컨테이너(Container)

• 도커 이미지:
  애플리케이션 실행에 필요한 모든 파일과 설정을 포함한 불변(Immutable)의 템플릿이다. 이미지는 상태를 저장하지 않는(Stateless) 특성을 가지며, 레이어(Layer) 구조로 되어 있어 기존 이미지를 기반으로 새로운 이미지를 효율적으로 생성할 수 있다.
• 도커 컨테이너:
  도커 이미지를 실행한 상태(Instance)를 의미한다. 컨테이너는 이미지와 달리 실행 중 변경되는 상태를 저장할 수 있는(Stateful) 격리된 프로세스이다. 단, 컨테이너가 삭제되면 내부 데이터도 함께 사라지므로 영구적인 데이터 저장을 위해서는 별도의 볼륨 설정이 필요하다.

4.2 도커 이미지 생성 및 관리

도커 이미지를 생성하는 방법은 크게 두 가지다:

• 실행 중인 컨테이너의 변경 사항을 docker commit 명령어로 저장.
• Dockerfile이라는 명세서를 작성하여 docker build 명령어로 빌드.
  현업에서는 재현성과 관리 편의성을 위해 주로 Dockerfile을 사용한다.

생성된 이미지는 도커 허브(Docker Hub)와 같은 레지스트리에 docker push 명령어를 통해 업로드하여 공유할 수 있으며, 필요 시 docker pull로 내려받아 사용할 수 있다.

---

4.3 주요 도커 명령어 및 기능 활용

• 컨테이너 실행:
  docker run 명령어를 사용한다. -d 옵션으로 백그라운드 실행이 가능하며, --name 옵션으로 컨테이너의 이름을 지정할 수 있다. 또한 --rm 옵션을 사용하면 실행 종료 후 컨테이너를 자동으로 삭제하여 리소스를 관리할 수 있다.
• 환경 변수 제어:
  Dockerfile 내 ENV 지시어나 docker run -e 옵션을 사용하여 애플리케이션에 필요한 환경 변수를 주입할 수 있다.
• 네트워킹:
  -p 옵션을 통해 호스트 시스템의 포트와 컨테이너의 포트를 연결(Port Forwarding)하여 외부에서 컨테이너 내부 서비스에 접근하게 한다.
• 파일 접근 및 공유:
  docker cp 명령어로 파일을 복사하거나, Dockerfile의 ADD 구문으로 빌드 시 파일을 추가할 수 있다. 특히 -v 옵션을 통한 볼륨 마운트는 호스트의 디렉터리를 컨테이너와 공유하여 컨테이너가 삭제되어도 중요 데이터가 유지되도록 하는 데 필수적이다.

---

5. 결론

웹 개발 파이프라인 구축에 있어 도커는 단순한 가상화 도구를 넘어 CI/CD의 핵심 엔진 역할을 수행한다. 도커를 통해 개발자는 의존성 문제(Dependency Hell)에서 벗어나 애플리케이션 로직에 집중할 수 있으며, 운영자는 표준화된 이미지 배포를 통해 안정적인 서비스 운영이 가능하다. 결과적으로 도커 이미지와 컨테이너의 개념을 명확히 이해하고, Dockerfile 작성부터 레지스트리 등록, 볼륨 관리에 이르는 일련의 과정을 능숙하게 다루는 것은 현대 개발자가 갖추어야 할 필수적인 역량이다.

---

6. 핵심 요약

정리하자면, 본 과정을 통해 학습한 도커와 CI/CD 파이프라인의 핵심 내용은 다음과 같다.

1. 도커 이미지와 컨테이너의 명확한 구분:
   도커 이미지는 애플리케이션 실행에 필요한 모든 파일과 설정을 포함한 불변의 템플릿(Stateless)이며, 컨테이너는 이 이미지를 바탕으로 실제로 실행되어 프로세스가 동작하는 격리된 인스턴스(Stateful)임을 이해해야 한다.
2. CI/CD에서의 도커의 역할:
   도커는 '작성한 그대로 어디서든 실행된다(Build once, Run anywhere)'는 특성을 통해 개발, 테스트, 운영 환경 간의 불일치를 해소한다. 이는 자동화된 파이프라인에서 신뢰성 있는 배포를 보장하는 핵심 기반이 된다.
3. 레지스트리와 이미지 실행 능력:
   사용자는 도커 허브(Docker Hub)와 같은 레지스트리에서 목적에 맞는 이미지를 검색하고, 이를 로컬로 가져와 docker run 명령어를 통해 컨테이너로 실행할 수 있어야 한다.
4. Dockerfile을 통한 이미지 생성:
   베이스 이미지 지정(FROM), 파일 복사(COPY), 명령어 실행(RUN) 등이 포함된 Dockerfile 스크립트를 직접 작성하고 빌드함으로써, 프로젝트에 최적화된 커스텀 이미지를 생성할 수 있다.
5. 식별과 버전 관리의 효율화:
   컨테이너 실행 시 --name 옵션을 사용하여 식별하기 쉬운 이름을 부여하고, 이미지 빌드 시 태그(Tag)를 활용하여 소프트웨어의 버전을 체계적으로 관리할 수 있다.
6. 이미지의 공유 및 게시:
   로컬에서 빌드 완료된 이미지는 docker push 명령어를 사용하여 원격 레지스트리에 업로드함으로써, 협업하는 팀원들과 공유하거나 운영 서버에 배포할 수 있는 상태로 만들 수 있다.

---

7. 실습 결과

Dokcerfile 생성 후 도커 이미지 생성

 

생성된 이미지를 컨테이너화