49일차 회고｜Docker·AWS 배포·Release 환경 구성｜AI 오케스트레이션 개발자 국비지원

 

오늘은 지금까지 배운 Docker와 AWS 관련 내용을 실제 배포 과정으로 연결해보는 시간을 가졌다. 단순히 Docker로 컨테이너를 실행하는 것에서 끝나는 것이 아니라, Docker Hub에 이미지를 올리고 AWS EC2에서 다시 받아 실행하는 과정까지 직접 진행했다.

특히 오늘은 처음부터 모든 환경을 한 번에 구성하는 것이 생각보다 쉽지 않다는 것을 경험했다. 설정 파일 하나, 이미지 이름 하나, 포트 하나가 맞지 않아도 전체 서비스가 정상적으로 실행되지 않았다.

---

오늘 배운 내용

오늘 학습의 큰 흐름은 다음과 같았다.

로컬 개발 → Docker 이미지 생성 → Docker Hub Push → AWS EC2 준비 → Docker 설치 → Redis/PostgreSQL 구성 → Release Compose 실행 → 외부 접속 테스트

이 과정을 직접 따라가면서 지금까지 각각 따로 배웠던 Docker, Docker Compose, Redis, PostgreSQL, AWS가 하나의 배포 과정으로 연결되는 것을 확인했다.

---

1. Docker Hub 이미지와 Release 환경

앞서 로컬에서 Frontend와 Backend를 각각 Docker 이미지로 만들고 Docker Hub에 올렸다.

오늘은 AWS에서 이 이미지를 다시 가져와 실행하기 위해 Release용 Compose 설정을 사용했다.

개발 환경에서는 직접 build해서 이미지를 만들지만, Release 환경에서는 이미 만들어진 이미지를 Docker Hub에서 가져와 실행하는 방식이다.

예를 들면 구조가 다음과 같다.

Docker Hub
 ├─ Frontend 이미지
 └─ Backend 이미지
        ↓
      AWS EC2
        ↓
   Docker Compose
        ↓
Frontend / Backend

여기에 Redis와 PostgreSQL은 별도의 이미지를 가져와 함께 실행하는 구조로 구성했다.

결국 다른 PC나 AWS 서버에 프로젝트를 배포할 때 소스코드를 다시 빌드하는 것이 아니라, 이미 만들어진 Docker 이미지를 가져와 동일한 실행 환경을 구성할 수 있다는 것을 이해하게 됐다.

---

2. 이미지 이름과 버전을 반드시 확인해야 하는 이유

오늘 생각보다 중요하게 느껴졌던 부분은 이미지 이름과 버전 확인이었다.

Docker Hub에 올린 이미지 이름과 Release Compose 파일에서 사용하는 이미지 이름이 서로 다르면 당연히 정상적으로 가져올 수 없다.

특히 AI 코딩 도구를 사용하면 코드 수정 자체는 빠르게 진행할 수 있지만, 이런 환경 설정이나 배포 관련 값까지 항상 정확하게 처리해준다고 생각하면 안 된다는 것을 다시 확인했다.

그래서 다음과 같은 부분은 직접 확인해야 한다.

• Docker Hub 이미지 이름
• 이미지 버전
• Compose 파일의 이미지 설정
• .env의 환경변수
• Frontend와 Backend가 사용하는 포트
• AWS Security Group의 인바운드 규칙

코드를 작성하는 것뿐만 아니라 실행 환경의 설정을 검증하는 능력도 개발 과정의 일부라는 생각이 들었다.

---

3. .env 파일은 왜 조심해야 할까?

AWS 서버에 접속한 뒤 ls를 사용했는데 .env 파일이 보이지 않았다.

이유는 .env가 숨김 파일이기 때문이다.

ls -a

를 사용하면 숨김 파일까지 확인할 수 있다.

그리고 .env가 중요한 이유도 다시 확인했다.

.env에는 API Key와 같은 민감한 설정값이 들어갈 수 있기 때문이다.

파일 권한도 확인하면서 .env는 아무나 읽을 수 있도록 두는 파일이 아니라는 점을 배웠다.

결국 배포할 때는 단순히

"서비스가 실행되는가?"

만 확인하는 것이 아니라,

"중요한 정보가 외부에 노출될 가능성은 없는가?"

까지 확인해야 한다.

---

4. Docker Login과 AWS 배포

AWS에서 Docker Hub의 이미지를 가져오려면 Docker Hub 로그인이 필요했다.

로컬에서는 이미 Docker Desktop을 통해 인증되어 있었기 때문에 별다른 문제 없이 진행했던 부분도 AWS에서는 다시 인증해야 했다.

즉,

내 PC
→ Docker Hub 로그인 상태

AWS EC2
→ 별도의 서버
→ Docker Hub 로그인 필요

라는 차이가 있었다.

로그인 정보를 제대로 입력하지 못하거나 인증 과정에서 문제가 발생한 경우도 있었기 때문에, 실제 배포에서는 계정 정보와 인증 상태를 확인하는 과정도 중요하다는 것을 경험했다.

---

5. AWS EC2에서 직접 환경 구성하기

오늘은 AWS EC2를 실제 서버처럼 사용하면서 필요한 환경을 처음부터 구성했다.

EC2에 접속한 뒤 Docker와 Docker Compose를 설치하고, Redis와 PostgreSQL 환경까지 준비했다.

여기서 sudo도 다시 이해하게 됐다.

AWS의 Ubuntu 서버에서는 일반 사용자로 접속하기 때문에 시스템 수준의 작업을 할 때 관리자 권한이 필요하다.

sudo

는 필요한 명령을 관리자 권한으로 실행하기 위한 명령이다.

Windows에서 작업할 때는 이런 권한 문제를 크게 의식하지 않았는데, Linux 서버 환경에서는 사용자 권한과 파일 권한 자체가 중요한 관리 요소라는 것을 체감했다.

---

6. Redis와 PostgreSQL도 직접 준비해야 했다

로컬에서는 이미 구성되어 있던 Redis와 PostgreSQL이 AWS의 새 EC2에는 당연히 존재하지 않았다.

그래서 AWS에서도 Docker 컨테이너를 이용해 필요한 서비스를 구성했다.

구조를 단순하게 표현하면 다음과 같다.

AWS EC2
│
├─ Frontend
├─ Backend
├─ Redis
└─ PostgreSQL

PostgreSQL의 경우 단순히 컨테이너를 실행하는 것만으로 끝나는 것이 아니라 데이터베이스와 테이블 등의 스키마를 준비해야 했다.

로컬에서는 Python을 이용해 초기화 작업을 할 수도 있지만, 서버에서는 SQL을 직접 이용해 데이터베이스 구조를 구성하는 방식도 사용했다.

이 과정에서 스키마와 테이블을 생성하고 인덱스도 확인했다.

인덱스는 데이터가 많아졌을 때 필요한 데이터를 더 빠르게 찾을 수 있도록 도와주는 구조라고 이해했다.

---

7. 포트와 서버 간 연결

이번 배포 과정에서 포트의 개념도 다시 정리됐다.

외부에서 AWS 서버의 서비스를 사용하려면 Security Group에서 해당 포트를 허용해야 한다.

이번 프로젝트에서는 대표적으로 다음 포트를 사용했다.

포트용도

22	SSH 원격 접속
8000	Backend
8501	Streamlit Frontend

그리고 서버 내부에서 서비스끼리 통신할 때는 단순히 localhost를 사용하는 것이 아니라 Docker Compose에서 정의한 서비스 이름을 이용하는 구조를 사용했다.

예를 들어 Backend에서 Redis에 접근할 때는 Redis 컨테이너의 서비스 이름을 이용한다.

이 부분을 배우면서 예전에 사용했던

127.0.0.1

이라는 주소가 항상 같은 의미를 가지는 것은 아니라는 것도 다시 이해했다.

내 PC에서 실행할 때의 localhost와 Docker 컨테이너 안에서의 localhost, 그리고 서로 다른 AWS 인스턴스 사이의 통신은 각각 다르게 생각해야 한다.

---

8. 실제 AWS 접속 테스트

환경을 구성한 뒤에는 AWS EC2의 Public IP + 8501 포트를 이용해 Frontend에 직접 접속했다.

여기서 단순히 화면이 뜨는지만 확인하는 것이 아니라,

• Frontend가 정상적으로 실행되는지
• Backend와 연결되는지
• LLM 호출이 되는지
• 데이터를 DB에 저장할 수 있는지
• 저장된 데이터를 다시 조회할 수 있는지

까지 확인해야 했다.

결국 배포의 최종 테스트는

"컨테이너가 실행되고 있다."

가 아니라

"사용자가 실제로 서비스를 사용할 수 있다."

까지 확인해야 한다는 것을 배웠다.

---

9. 문제가 생기면 처음부터 다시 구성하기

오늘은 AWS 환경에서 문제가 발생하면서 기존 인스턴스를 정리하고 새 인스턴스를 만들어 다시 진행하는 과정도 경험했다.

기존 인스턴스를 중지하고 삭제한 뒤 새로운 환경을 구성하면서 다음 순서를 다시 밟았다.

EC2 생성
↓
Security Group 설정
↓
SSH 접속
↓
Docker 설치
↓
Docker Compose 확인
↓
Redis / PostgreSQL 구성
↓
DB 스키마 구성
↓
Docker Hub 로그인
↓
Release Compose 설정
↓
이미지 Pull
↓
서비스 실행
↓
외부 접속 테스트

처음에는 과정이 길게 느껴졌지만, 같은 작업을 반복하면서 각각의 단계가 왜 필요한지 조금씩 연결됐다.

강사님도 처음에는 시간이 오래 걸릴 수 있지만 직접 여러 번 해보면 점점 빨라진다고 설명했다.

---

10. 오늘 가장 크게 이해한 것

이번 주까지 Docker를 배우면서 처음에는 Docker를 단순히

"프로그램을 컨테이너로 실행하는 기술"

정도로 생각했다.

하지만 오늘 AWS까지 연결해보면서 조금 더 큰 그림이 보이기 시작했다.

개발자
  ↓
코드 작성
  ↓
Docker 이미지 생성
  ↓
Docker Hub에 Push
  ↓
운영 서버(AWS)
  ↓
Docker 이미지 Pull
  ↓
컨테이너 실행
  ↓
사용자가 서비스 이용

그리고 그 뒤에는 Redis, PostgreSQL 같은 데이터 저장 및 관리 서비스가 존재한다.

즉 Docker를 배우는 목적이 단순히 로컬에서 컨테이너를 실행하는 데 있는 것이 아니라, 개발 환경에서 만든 서비스를 다른 환경에서도 동일하게 실행할 수 있도록 패키징하고 배포하는 과정과 연결된다는 것을 이해했다.

---

AI 코딩 도구를 사용하면서 느낀 점

최근에는 Codex 같은 AI 코딩 도구를 이용하면서 코드 작성 속도가 확실히 빨라졌다.

하지만 오늘 배포 과정을 거치면서 오히려 사람이 직접 확인해야 하는 부분이 더 명확해졌다.

특히 다음과 같은 부분은 AI가 수정했다고 해서 그대로 믿으면 안 된다.

• .env
• YAML
• Docker Compose 설정
• 이미지 이름
• 포트
• 환경변수
• 서버 권한
• 보안 설정

코드가 문법적으로 맞는 것과 실제 서버 환경에서 올바르게 동작하는 것은 다른 문제였다.

AI를 활용할수록 오히려 실행 환경을 이해하고 결과를 검증하는 능력이 중요하겠다는 생각이 들었다.

---

아직 부족한 부분

오늘 AWS 배포를 직접 해보면서 아직 명령어와 작업 순서를 완전히 외운 상태는 아니다.

특히 다음 부분은 다시 정리할 필요가 있다.

• Docker Compose 명령어
• Docker Hub 로그인 및 이미지 관리
• AWS EC2 초기 설정
• Security Group 포트 설정
• Linux 권한과 sudo
• Redis/PostgreSQL 서버 구성
• .env 및 환경변수 관리
• Docker 컨테이너 간 네트워크
• Frontend ↔ Backend ↔ DB/Redis 연결 구조
• Ollama를 별도 환경에서 연결하는 과정

지금은 명령어 하나하나를 찾아가면서 따라 할 수 있는 수준에 가깝기 때문에, 처음부터 끝까지 혼자 재구성해보는 연습이 필요할 것 같다.

---

다음 단계

오늘까지 Docker와 AWS 배포의 기본적인 흐름을 경험했다.

다음에는 CI/CD까지 연결할 예정이다.

CI/CD는 코드를 수정할 때마다 테스트하고, 필요한 경우 빌드와 배포까지 자동화하는 방식이다.

다만 아직 Git과 서버 환경에 익숙하지 않은 상태에서 CI/CD부터 복잡하게 진행하면 설정 문제를 해결하는 데 많은 시간을 사용할 수 있기 때문에, 우선 지금까지 배운 배포 과정을 확실하게 이해하는 것이 중요하다고 느꼈다.

그리고 앞으로 진행할 미니 프로젝트에서는 현재처럼 하나의 인스턴스에 모든 서비스를 넣는 구조에서 더 나아가 Frontend, Backend, DB/Redis, Ollama 등의 역할을 분리하는 구조도 생각해볼 수 있을 것 같다.

특히 Ollama를 별도의 환경에서 실행하고 Backend가 연결하는 구조를 직접 구현할 수 있다면, 지금까지 배운 Docker와 AWS 그리고 로컬 LLM을 하나의 프로젝트 안에서 연결해볼 수 있을 것 같다.

---

오늘의 회고

오늘은 단순히 AWS에 프로젝트를 올린 날이라기보다 개발 환경과 운영 환경이 어떻게 연결되는지를 직접 경험한 날이었다.

로컬에서는 잘 실행되던 프로젝트도 AWS의 새로운 서버에서는 Docker부터 다시 설치해야 했고, Redis와 PostgreSQL도 준비해야 했다. Docker Hub 인증, 이미지 이름, 환경변수, 포트, 권한 등 여러 요소가 하나라도 맞지 않으면 정상적으로 실행되지 않았다.

특히 지금까지는 코드 자체에 집중하는 시간이 많았다면, 오늘부터는 서비스가 실제 서버에서 실행되기까지 필요한 주변 환경까지 개발의 범위로 생각해야 한다는 것을 조금 더 명확하게 이해하게 됐다.

아직 배포 과정을 혼자 처음부터 끝까지 완벽하게 재현할 정도는 아니지만, 최소한

코드 → Docker → Docker Hub → AWS → DB/Redis → 서비스 실행

이라는 전체적인 흐름은 연결해서 볼 수 있게 됐다.

다음 단계에서는 이 과정을 반복해서 명령어에 익숙해지고, 이후 CI/CD와 프로젝트에 적용하면서 단순히 따라 하는 배포가 아니라 왜 이렇게 구성하는지 설명할 수 있는 수준까지 이해해보려고 한다.

---

해시태그

#AI오케스트레이션 #AI에이전트 #Docker #DockerCompose #AWS #EC2 #DockerHub #Redis #PostgreSQL #Ollama