51일차 회고｜Docker Compose·CI/CD·AWS 배포 자동화｜AI 오케스트레이션 개발자 국비지원

 

오늘은 Docker Compose로 여러 서비스를 구성하고, GitHub Actions를 이용해 CI/CD를 AWS EC2까지 연결하는 과정을 집중적으로 실습했다. 단순히 제공된 YAML 파일을 실행하는 데서 끝나는 것이 아니라, 직접 프로젝트를 선택해 Docker 환경부터 테스트, CI/CD, 배포까지 전체 흐름을 만들어보는 것이 핵심이었다.

특히 오늘은 앞에서 배웠던 Docker와 AWS 배포가 GitHub Actions라는 자동화 파이프라인으로 하나의 흐름으로 연결되는 과정을 제대로 이해하는 데 의미가 있었다.

---

오늘 배운 내용

오늘 실습의 전체 흐름은 다음과 같았다.

프로젝트 분석
    ↓
Dockerfile 작성
    ↓
Docker Compose 구성
    ↓
환경변수 분리
    ↓
API 테스트 작성
    ↓
로컬 CI 테스트
    ↓
GitHub Actions CI
    ↓
AWS EC2 CD
    ↓
Docker Compose 실행
    ↓
서비스 배포

오전에는 기존 Weather MCP 프로젝트를 대상으로 GitHub Actions의 CI/CD 구조를 확인했고, 오후에는 mini-agent-01-LLM 프로젝트를 직접 CI/CD할 수 있도록 구성했다.

이후에는 한 단계 더 나아가 Frontend, Backend, MCP Server, Redis, PostgreSQL이 함께 구성된 프로젝트까지 CI/CD 대상으로 확장하는 과정도 살펴봤다.

---

1. CI와 CD의 역할을 다시 이해하다

오늘 가장 많이 들었던 개념은 역시 CI/CD였다.

CI는 Continuous Integration(지속적 통합)으로, 코드를 GitHub에 반영하기 전에 테스트하고 빌드하는 과정이다.

CD는 Continuous Deployment/Delivery(지속적 배포/전달)로, CI가 성공한 결과물을 실제 배포 환경으로 전달하는 과정이다.

오늘 실습에서는 다음과 같은 구조로 동작했다.

main 브랜치 Push
       ↓
      CI
       ↓
 테스트 실행
       ↓
 Docker 이미지 Build
       ↓
      CD
       ↓
 AWS EC2 접속
       ↓
 프로젝트 배포
       ↓
 docker compose up

특히 모든 브랜치의 Push마다 배포가 일어나도록 하면 안 된다는 점도 다시 확인했다.

개발자가 작업 중인 브랜치에 코드를 올릴 때마다 운영 서버에 배포된다면 아직 완성되지 않은 코드가 배포될 수 있기 때문이다.

그래서 이번 실습에서는 main 브랜치를 기준으로 CI/CD가 동작하도록 구성했다.

---

2. Docker Compose를 먼저 구성해야 했다

오후에는 mini-agent-01-LLM 프로젝트를 가지고 직접 CI/CD를 구성했다.

처음부터 GitHub Actions YAML을 만드는 것이 아니라 Docker 환경부터 정상적으로 만들어야 했다.

먼저 확인한 것은 다음과 같았다.

• Backend Dockerfile
• Frontend Dockerfile
• docker-compose.yml
• Docker용 환경변수 파일

Dockerfile은 각각의 서비스를 컨테이너에서 실행하기 위한 설정 파일이고, Docker Compose는 여러 컨테이너를 하나의 애플리케이션처럼 묶어 실행하기 위한 도구다.

즉,

Backend Dockerfile → Backend 실행 환경
Frontend Dockerfile → Frontend 실행 환경

        ↓

docker-compose.yml

        ↓

Backend + Frontend 실행

이라는 관계로 이해했다.

여기서 중요한 것은 Compose가 정상적으로 실행되지 않는 상태에서 CI/CD부터 만들면 안 된다는 것이었다.

먼저 로컬에서 Docker Compose가 제대로 동작하는지 확인하고 다음 단계로 넘어가야 했다.

---

3. .env와 .env.docker를 분리하는 이유

오늘 여러 번 강조된 부분이 환경변수 파일의 분리였다.

기존 .env는 개발 환경에서 사용하는 설정이고, Docker Compose로 컨테이너를 실행할 때는 별도의 Docker용 환경변수 파일을 준비했다.

.env
→ 개발 환경

.env.docker
→ Docker Compose 환경

그리고 다른 사람이 프로젝트를 가져갔을 때 환경변수 구성을 이해할 수 있도록 .env.example 같은 예시 파일을 함께 관리하는 방식도 확인했다.

이 부분을 보면서 환경변수는 단순히 API 키를 넣어두는 파일이 아니라 같은 프로그램을 서로 다른 환경에서 실행할 수 있도록 환경을 분리하는 역할도 한다는 것을 다시 이해했다.

특히 Docker Compose 파일에 IP나 포트 같은 값을 직접 작성해버리면 서버 환경이 바뀔 때 YAML 자체를 수정해야 한다.

그래서 가능한 설정값은 환경변수로 분리하고, 프로그램과 Compose 파일은 최대한 그대로 유지하는 구조가 중요했다.

---

4. 테스트가 CI의 출발점이라는 것

Docker 구성을 완료한 뒤에는 Backend API 테스트를 진행했다.

Backend의 tests 폴더에 테스트 프로그램을 두고 API가 정상적으로 동작하는지 확인했다.

여기서 테스트는 단순히 정상적인 요청만 확인하는 것이 아니었다.

예를 들어 정상적인 입력을 넣었을 때 잘 동작하는 Happy Case뿐 아니라,

• 잘못된 입력
• 예외 상황
• 비정상적인 요청
• 예상하지 못한 값

등의 Unhappy Case도 테스트해야 한다는 설명을 들었다.

실습에서는 테스트 프로그램을 수정한 뒤 19개 테스트가 모두 통과되는 것까지 확인했다.

이 과정을 통해 CI가 단순히 "코드를 자동으로 실행하는 기능"이 아니라, 문제가 있는 코드를 다음 단계로 넘기지 않기 위한 검증 과정이라는 점을 체감했다.

---

5. GitHub Actions에 올리기 전에 로컬 CI부터 확인

테스트가 끝났다고 바로 GitHub에 Push하는 것이 아니라 로컬에서 먼저 CI 과정을 확인했다.

먼저 테스트를 실행하고 Docker Compose의 문법을 검증한 다음 Docker 이미지를 실제로 빌드했다.

pytest
   ↓
Compose validation
   ↓
Docker image build

이 과정에서 문제가 없다면 그다음 GitHub Actions로 넘어가는 방식이었다.

특히 CI YAML에서 테스트가 특정 디렉터리에서 실행되도록 설정되어 있기 때문에 Working Directory가 정확한지도 중요했다.

명령어 자체가 맞더라도 잘못된 디렉터리에서 실행하면 테스트가 실패할 수 있기 때문이다.

---

6. AWS 배포에서 .env가 없어서 발생한 문제

오늘 실제 CI/CD를 돌리면서 배포 과정에서 발생하는 오류도 경험했다.

GitHub에는 프로젝트 코드가 올라가 있지만 환경변수 파일까지 그대로 올라가는 것은 아니다.

그런데 AWS EC2에서 Docker Compose를 실행하려면 필요한 환경변수가 있어야 한다.

결국 GitHub Actions가 AWS에 코드를 복사하더라도 EC2에 필요한 환경변수 파일이 없다면 정상적으로 Compose를 실행할 수 없다.

그래서 배포 디렉터리를 먼저 만들고 필요한 환경설정 파일을 별도로 준비했다.

이 경험을 통해 다음 구조를 확실히 이해하게 됐다.

GitHub
 └─ 프로그램 코드
       ↓
GitHub Actions
       ↓
AWS EC2
 ├─ 배포된 프로그램
 └─ 미리 준비된 환경변수
       ↓
docker compose up

코드가 있다고 배포가 끝나는 것이 아니라 실행 환경까지 준비되어 있어야 한다는 점이 오늘의 중요한 깨달음이었다.

---

7. GitHub Environment와 Secrets

GitHub Actions가 AWS EC2에 접속하기 위해 GitHub의 Environment를 사용했다.

Environment는 특정 배포 환경에 필요한 설정과 Secret을 관리하는 공간이다.

이번 실습에서는 다음과 같은 AWS 접속 정보를 설정했다.

• AWS_HOST
• AWS_USER
• AWS_SSH_PRIVATE_KEY
• AWS_SSH_KNOWN_HOSTS

이 정보가 있어야 GitHub Actions가 어떤 AWS 서버에 어떤 계정과 SSH 인증정보를 사용해 접속할지 알 수 있다.

그리고 Environment의 이름과 workflow YAML에 지정한 환경 이름도 일치해야 했다.

처음에는 production을 사용했고, 이후 실습에서는 별도의 이름을 사용하는 방법도 확인했다.

---

8. CI/CD가 실패하면서 원인을 찾아가는 과정

오늘 가장 기억에 남는 부분 중 하나는 SSH 22번 포트 문제였다.

CI는 정상적으로 끝났는데 CD 단계에서 AWS 접속이 실패했다.

오류는 SSH의 port 22 연결 문제였다.

처음에는 이상하게 느껴졌다. 왜냐하면 앞에서 직접 SCP로 파일을 AWS에 복사할 때는 정상적으로 접속했기 때문이다.

차이는 접속하는 주체였다.

직접 SCP를 사용할 때는 현재 작업 환경의 IP가 AWS Security Group에서 허용되어 있었지만, GitHub Actions는 GitHub의 실행 환경에서 AWS로 접속한다.

결국 GitHub Actions가 AWS의 SSH 포트에 접근할 수 있도록 Security Group 설정을 변경해야 했다.

이번 실습에서는 학습을 위해 SSH 22번 포트를 외부에서 접근할 수 있도록 설정했다.

다만 실제 운영 환경에서는 이렇게 무조건 SSH를 외부에 개방하는 방식보다는 별도의 보안 정책이나 접근제어 방식을 사용하는 것이 필요하다는 설명도 들었다.

이 과정에서 단순히 "오류가 났으니 설정 하나 바꾸기"가 아니라,

어디에서 어디로 접속하고 있는가?

를 생각해야 문제의 원인을 찾을 수 있다는 것을 배웠다.

---

9. 단순한 프로젝트에서 여러 서비스로 확장

후반부에는 Zero 6 프로젝트처럼 다음과 같이 여러 서비스가 존재하는 프로젝트의 배포 구조도 살펴봤다.

Frontend
Backend
MCP Server
Redis
PostgreSQL

이런 프로젝트는 단순히 애플리케이션 하나만 배포하면 끝나는 것이 아니다.

예를 들어 Backend가 Redis와 PostgreSQL에 의존한다면 인프라가 먼저 준비된 후 애플리케이션이 실행되어야 한다.

Redis + PostgreSQL
        ↓
Backend / MCP Server
        ↓
Frontend

이런 의존 관계를 고려해서 Docker Compose와 CI/CD workflow를 설계해야 한다는 것을 배웠다.

또한 Redis와 PostgreSQL처럼 이미지를 가져와 사용하는 서비스와 직접 Docker 이미지를 빌드해야 하는 애플리케이션을 구분해서 볼 필요도 있었다.

---

10. 실무에서는 테스트 서버를 거친다는 것

오늘 수업에서는 실제 회사에서의 CI/CD 방식에 대한 설명도 들었다.

교육 환경에서는 CI가 성공하면 바로 AWS EC2에 배포했지만, 실제 운영 환경에서는 이런 방식으로 바로 Real Server에 올리는 것보다 테스트 서버를 먼저 거치는 구조가 일반적이라는 설명이었다.

개발자
 ↓
Git Push
 ↓
CI
 ↓
테스트 서버 배포
 ↓
개발자 / 테스터 검증
 ↓
운영 환경 반영

만약 테스트를 건너뛰고 문제가 있는 코드가 운영 서버에 배포된다면 실제 사용자에게 오류가 노출될 수 있다.

따라서 개발자가 CI/CD를 통해 테스트 환경까지 배포하고, 검증된 결과를 운영 환경으로 넘기는 역할을 분리할 수 있다는 점을 이해했다.

---

오늘 새롭게 이해한 점

오늘 가장 크게 달라진 것은 CI/CD를 개별 명령어가 아니라 하나의 파이프라인으로 보기 시작했다는 것이다.

처음에는 Docker Compose, pytest, GitHub Actions, Environment, SSH, AWS가 각각 별개의 기술처럼 보였다.

하지만 오늘 전체 과정을 연결해서 실습하면서 각각의 역할이 이어져 있다는 것을 이해하게 됐다.

Dockerfile
→ 서비스를 컨테이너에서 실행

Docker Compose
→ 여러 서비스를 함께 실행

pytest
→ 프로그램이 정상적으로 동작하는지 검증

GitHub Actions
→ 테스트와 배포 과정을 자동화

GitHub Environment
→ 배포 환경과 Secret 관리

AWS EC2
→ 실제 배포 대상 서버

결국 CI/CD는 특정 YAML 파일 하나를 만드는 것이 아니라 프로젝트가 테스트되고 배포되는 전체 과정을 자동화하는 것이었다.

---

오늘 어려웠던 점

오늘은 단순히 파일 몇 개를 만드는 것보다 각 파일과 환경이 어떻게 연결되는지 이해하는 과정이 어려웠다.

특히 다음 부분에서 계속 확인이 필요했다.

• .env와 .env.docker의 차이
• Docker Compose에서 환경변수 파일을 지정하는 방법
• GitHub Environment와 workflow의 연결
• AWS SSH 접속에 필요한 설정
• EC2 배포 디렉터리의 위치
• CI에서 테스트가 실행되는 Working Directory
• CI 성공 후 CD가 어떤 순서로 실행되는지
• 여러 서비스가 있을 때 인프라와 애플리케이션의 실행 순서

오늘 실제 오류를 경험하면서 오류 메시지를 보는 것보다 먼저 전체 구조와 실행 흐름을 이해해야 한다는 점도 느꼈다.

---

현재 나의 상태

오늘까지 실습하면서 이전처럼 AWS에 직접 접속해서 파일을 복사하고 Docker 명령어를 하나씩 실행하는 방식만 알고 있는 상태에서 조금 벗어났다.

현재는 적어도 다음과 같은 흐름은 이해할 수 있게 됐다.

프로젝트 → Docker Compose → 테스트 → 로컬 CI → GitHub Actions → AWS EC2 → Docker Compose 배포

또한 단순한 Frontend + Backend 프로젝트뿐 아니라 MCP Server, Redis, PostgreSQL 등이 추가됐을 때 어떤 부분을 고려해야 하는지도 조금씩 보이기 시작했다.

다만 아직 workflow YAML을 처음부터 완전히 직접 작성하는 것은 익숙하지 않다.

강사님이 제공한 기존 YAML을 참고하거나 수정하는 과정은 따라갈 수 있지만, 아무것도 없는 상태에서 CI/CD 전체 파이프라인을 설계하고 작성하는 능력은 더 연습이 필요하다.

---

앞으로 복습할 부분

오늘 배운 내용은 한 번 따라 해봤다고 끝낼 수 있는 내용은 아닌 것 같다.

특히 다음 부분은 다시 직접 만들어봐야 할 것 같다.

1. Dockerfile 직접 작성
2. Docker Compose 구성
3. .env / .env.docker 분리
4. Backend API 테스트 작성
5. 로컬 CI 테스트
6. GitHub Actions workflow 분석
7. GitHub Environment와 Secrets 설정
8. AWS EC2 SSH 연결
9. 실제 CI → CD 실행

무엇보다 제공된 YAML을 복사해서 사용하는 것과 YAML의 동작 원리를 이해하는 것은 다르다.

다음에는 기존 파일을 참고하더라도 각 단계가 왜 필요한지 설명하면서 직접 구성해보는 연습이 필요하다.

---

오늘의 회고

오늘은 지금까지 배웠던 Docker, GitHub, AWS가 하나의 흐름으로 연결되는 날이었다.

처음에는 Dockerfile, docker-compose.yml, .env, pytest, GitHub Actions YAML, Environment, AWS Security Group 같은 파일과 설정이 각각 따로 존재하는 것처럼 느껴졌다.

하지만 직접 CI/CD를 구성하고 오류까지 경험해보니 각각의 역할이 연결되어 있었다.

특히 "GitHub에 Push하면 자동으로 AWS에 배포된다"는 결과보다 그 사이에 어떤 과정이 존재하는지를 이해한 것이 더 중요했다.

코드 작성
  ↓
테스트
  ↓
Docker Build
  ↓
CI 성공
  ↓
AWS 접속
  ↓
환경변수 적용
  ↓
Docker Compose
  ↓
배포

그리고 오늘 마지막에는 기존 프로젝트를 따라 하는 수준에서 벗어나 직접 다른 프로젝트의 CI/CD를 구성하는 단계로 넘어갔다.

앞으로는 단순히 "이 파일을 이렇게 만들면 된다"가 아니라,

"내 프로젝트를 배포하려면 어떤 서비스가 있고, 어떤 순서로 실행되어야 하며, CI에서 무엇을 검증하고 CD에서 무엇을 배포해야 하는가?"

를 먼저 생각하는 습관을 만들어야겠다.

오늘은 그동안 따로 배웠던 Docker와 AWS, GitHub Actions가 실제 개발 과정에서 어떻게 하나의 파이프라인으로 연결되는지 이해한 날이었다.