프로젝트 관리 심화과정 (Docker + CI/CD + AWS ECS) 개요

StrayCat·2026년 3월 13일
AWS ECSCI/CDdocker

프로젝트 관리 심화과정 (Docker + CI/CD + AWS ECS)

목록 보기
1/12

본 포스팅은 Docker와 Docker Compose의 기초부터 시작해, CI/CD 파이프라인 구축, 그리고 AWS ECS를 통한 실제 배포까지 다룬다. 단순한 개념 학습을 넘어, 코드를 작성하고 자동으로 배포되는 전체 흐름을 몸으로 익히는 것이 목표다.

과정에서 배우는 것

강의는 크게 두 챕터로 나뉜다.

  • 챕터 1 (기초) : Docker, Docker Compose 개념 및 실습
  • 챕터 2 (CI/CD) : CI/CD 개념, GitLab, AWS(ECR, ECS, IAM) 연동 및 자동 배포

왜 이걸 배워야 하는가

처음 이 커리큘럼을 보면서 든 생각은, "서버 배포를 해보는거구나" 였다. 근데 강의를 듣고, 문서를 읽다 보니 생각이 달라졌다.

개발자의 코드가 사용자에게 전달되는 과정을 생각해보자.

코드 작성 → 빌드 → 테스트 → 배포 → 서버 실행 → 사용자 접근

과거에는 이 과정의 상당 부분을 사람이 직접 처리했다. 서버에 SSH로 접속해서 파일 옮기고, 직접 커맨드 타이핑으로 입력하고... 당연히 실수도 잦고, 느렸다. 이걸 자동화하는 게 바로 CI/CD이고, 이 자동화를 가능하게 해주는 핵심 기술이 Docker다.

2026년 기준, Docker + CI/CD 파이프라인은 규모와 관계없이 대부분의 팀이 채택하는 사실상의 표준(de facto standard) 이 되었다.

강의 커리큘럼 한눈에 보기

챕터 1 (기초)
├── 1-1 오리엔테이션
├── 1-2 Docker
├── 1-3 Docker Compose
└── 실습
    ├── 1-4 실습 개요
    ├── 1-5 애플리케이션 생성
    ├── 1-6 Docker 사용
    └── 1-7 Docker Compose 사용

챕터 2 (CI/CD)
├── 2-1 오리엔테이션
├── 2-2 CI/CD 개념
├── 2-3 Amazon ECS 개념
└── 실습
    ├── 2-4 실습 개요
    ├── 2-5 GitLab 설정
    ├── 2-6 AWS 보안그룹 추가
    ├── 2-7 AWS ECR (컨테이너 이미지 저장소)
    ├── 2-8 AWS ECS (컨테이너 실행 환경)
    ├── 2-9 AWS IAM (접근 권한 관리)
    ├── 2-10 GitLab CI 파일 작성 및 푸시
    ├── 2-11 결과 확인
    └── 2-12 추가 - GitHub Actions

이 강의에서 배우게 될 핵심 기술

1. Docker

"내 컴퓨터에서는 잘 됐는데요(works on my machine)" — 개발자라면 누구나 한 번쯤 해봤거나, 들어봤을 말이다.

Docker는 이 문제를 해결하기 위해 등장했다. 애플리케이션과 그 실행 환경을 하나의 컨테이너(container) 로 묶어버리는 것이다.

  • Dockerfile 작성 → Docker 이미지(image) 생성 → 컨테이너 실행
  • 어디서 실행하든 동일한 환경이 보장된다

컨테이너는 "앱 실행에 필요한 모든 것을 담은 표준화된 패키지"라고 생각하면 이해가 쉽다.


2. Docker Compose

실제 웹 서비스는 보통 하나의 프로세스만으로 이루어지지 않는다. Spring Boot 백엔드, React 프론트엔드, MySQL 데이터베이스... 이것들이 각각 컨테이너로 분리되어 있을 때, 이를 한 번에 묶어서 관리해주는 도구가 Docker Compose다.

  • docker-compose.yml 파일 하나로 여러 컨테이너를 정의하고 실행
  • 컨테이너 간 네트워크 연결, 볼륨(데이터 저장소) 설정 등을 담당

3. CI/CD 파이프라인 구축

CI (Continuous Integration, 지속적 통합) 와 CD (Continuous Delivery/Deployment, 지속적 배포) 를 합친 개념이다.

단계의미예시
CI코드 변경 시 자동으로 빌드·테스트Git push → 자동 테스트 실행
CD테스트 통과 시 자동으로 배포테스트 통과 → 서버 자동 업데이트

이 강의에서는 GitLab CI/CD 를 사용한다. .gitlab-ci.yml 파일 하나로 파이프라인을 정의한다.

참고로 GitHub을 사용하는 경우에는 GitHub Actions 가 사실상 동일한 역할을 한다. 챕터 2-12에서 GitHub Actions에 대한 추가 설명도 포함되어 있으니, 본인의 환경에 맞게 참고하면 된다.


4. AWS ECS (Elastic Container Service)

컨테이너를 클라우드에서 실행하고 관리하는 AWS 서비스다. 함께 등장하는 AWS 서비스들의 역할 분담을 미리 알아두면 이해가 훨씬 빠르다.

AWS 서비스역할비유
ECR (Elastic Container Registry)Docker 이미지 저장소Docker Hub의 AWS 버전
ECS (Elastic Container Service)컨테이너를 실행·관리하는 환경도커를 클라우드에서 실행하는 플랫폼
IAM (Identity and Access Management)접근 권한 관리서비스 간 "이 계정은 여기까지만 접근 가능" 설정

전체 흐름 미리 보기

이 강의를 통해 최종적으로 구현하게 될 흐름은 아래와 같다.

개발자가 코드 작성
    ↓
GitLab에 코드 Push (업로드)
    ↓
GitLab CI 파이프라인 자동 실행
    ↓
Docker 이미지 빌드 → AWS ECR에 Push
    ↓
AWS ECS에서 새 이미지로 컨테이너 자동 배포
    ↓
서비스 업데이트 완료

이 흐름이 자동으로 돌아간다는 것이 핵심이다. 코드 한 줄 바꿔서 push하면, 나머지는 파이프라인이 알아서 처리한다.

⚠️ 실습 전 꼭 알아야 할 것 : AWS 비용 주의

AWS는 사용한 만큼 과금되는 구조다. 실습 후 사용한 서비스(ECS, ECR, EC2 등)를 반드시 중지/삭제해야 불필요한 비용이 청구되지 않는다.

강의에 AWS 실습 후 리소스 제거 방법이 별도로 제공되므로, 실습 마무리 시 꼭 확인하자.


2026년 기준, 이 기술들의 위치

공부하면서 한 가지 더 짚고 넘어가고 싶었다. "이게 지금도 메인스트림인가?" 라는 질문이다.

결론부터 말하자면, 더 주류가 됐다.

2026년 현재, Docker와 CI/CD의 조합은 현대 DevOps의 핵심 기반이 되었으며, 컨테이너화는 "있으면 좋은 것"이 아니라 필수 요소로 자리잡았다.

몇 가지 트렌드 포인트를 짚어두면:

  • 멀티스테이지 빌드(Multi-stage build) : Dockerfile을 빌드 단계와 런타임 단계로 나눠, 최종 이미지 크기를 크게 줄이는 기법. 현재는 표준 관행으로 자리잡았다.
  • 보안 스캔(Security Scan) 통합 : CI 파이프라인 안에 컨테이너 취약점 스캐닝 단계를 포함하는 것이 일반화됐다. (Trivy, Snyk 등)
  • GitHub Actions의 부상 : GitLab CI와 함께 GitHub Actions도 이제 완전히 메인스트림이다. 이 강의는 GitLab 기반이지만, 개념은 공통이므로 GitHub Actions로의 전환도 어렵지 않다.

단, 실제 개발 환경에서는 레거시(legacy, 기존에 구축된 오래된 시스템) 인프라가 여전히 많다. 모든 팀이 최신 스택을 쓰는 게 아니라, 오래된 Jenkins 기반의 파이프라인을 그대로 유지하는 경우도 흔하다. 개념을 탄탄하게 익혀두면, 어떤 환경이든 적응할 수 있다.

정리

이 강의는 단순히 명령어를 외우는 것이 목표가 아니다. "코드가 서버까지 전달되는 전체 과정을 자동화하는 경험" 을 하는 것이 핵심이다.

Docker → Docker Compose → CI/CD → AWS ECS로 이어지는 흐름을 따라가다 보면, 서비스가 어떻게 배포되고 운영되는지에 대한 전체적인 그림이 그려지기 시작할 것이다.

참고 자료

profile
StrayCat
알면 좋은 것보단 잊어버리기 싫은 것들을 기록합니다.
다음 포스트

Docker 기초

0개의 댓글