[SK네트웍스 Family 엔코아AI캠퍼스] AI 오케스트레이션 캠프 1기_9월 3주차 회고

 

9월 3주는 지금까지 학습한 AI Agent와 멀티 에이전트 시스템을 실제 서비스 환경에 배포하는 과정을 집중적으로 경험한 한 주였다.

이전까지는 AI Agent의 구조를 만들고 기능을 구현하는 데 집중했다면, 이번 주에는 Docker를 이용해 서비스를 분리하고, Docker Hub에 이미지를 저장하고, AWS EC2에 배포하고, 서버 간 네트워크를 연결하는 것까지 학습 범위가 확장됐다.

여기에 GitHub Actions를 이용한 CI까지 연결하면서 "AI 애플리케이션을 만드는 것"에서 "만든 애플리케이션을 실제 환경에서 실행하고 관리하는 것"으로 관심의 범위가 넓어진 한 주였다. (랩보다 AI 더 잘해지기)

---

1. 이번 주 학습 요약

이번 주의 학습 흐름을 하나로 정리하면 다음과 같다.

Multi-Agent
     ↓
Docker / Docker Compose
     ↓
서비스별 환경 분리
     ↓
Docker Image
     ↓
Docker Hub
     ↓
AWS EC2
     ↓
Security Group / Port / IP
     ↓
Release 환경 구성
     ↓
GitHub Actions
     ↓
CI / CD

처음에는 각각 별개의 기술처럼 보였다.

Docker는 컨테이너를 실행하기 위한 기술이고, AWS는 서버를 제공하는 서비스이며, GitHub Actions는 자동화 도구라고 생각했다.

하지만 이번 주 여러 번 직접 연결해보면서 이 기술들이 실제로는 하나의 배포 흐름 안에서 서로 역할을 나눠 갖고 있다는 것을 이해하게 됐다. (랩보다 AI 더 잘해지기)

---

2. 가장 인상 깊었던 학습

"Docker를 사용할 줄 안다"와 "Docker로 서비스를 배포할 수 있다"는 달랐다

이번 주 가장 크게 느낀 부분이다.

기존에는 docker compose up을 실행해서 컨테이너가 정상적으로 올라오면 어느 정도 성공했다고 생각했다.

하지만 실제 배포를 해보니 확인해야 할 것이 훨씬 많았다.

• 어떤 Docker Image를 사용하는가
• Image가 어디에 저장되어 있는가
• 어떤 버전을 사용하는가
• 각 서비스의 환경변수는 무엇인가
• 컨테이너끼리 어떻게 통신하는가
• 어떤 포트를 사용하는가
• AWS Security Group에서 해당 포트를 허용했는가
• 데이터베이스와 Redis가 정상적으로 연결되는가
• 실제 사용자가 서비스에 접근할 수 있는가

즉, 컨테이너 하나를 실행하는 것과 여러 서비스를 실제로 동작시키는 것은 전혀 다른 문제였다. (랩보다 AI 더 잘해지기)

특히 46일차에는 기존 LawPath 프로젝트를 Docker Compose 환경으로 구성하면서 Frontend, Backend, MCP Server, PostgreSQL, Redis를 연결했고, 실제 법률 검색 데이터까지 Docker 환경에서 재현해봤다. 이 과정에서 Healthcheck, 환경변수, 컨테이너 네트워크, timeout 등의 문제도 직접 확인했다. (랩보다 AI 더 잘해지기)

---

3. 서비스를 분리하면서 달라진 생각

47일차에는 멀티모달 Agent 프로젝트를 Docker 환경에 맞게 다시 구성했다.

기존에는 여러 서비스가 하나의 Python 환경과 requirements.txt를 공유하는 구조였지만, 이를 Frontend, Backend, MCP Server 등의 서비스별 환경으로 분리했다.

optional_multimodal_agent/

├─ frontend/
│  ├─ .env
│  ├─ .env.example
│  └─ requirements.txt
│
├─ backend/
│  ├─ .env
│  ├─ .env.example
│  └─ requirements.txt
│
└─ mcp_server/
   ├─ .env
   ├─ .env.example
   └─ requirements.txt

서비스를 분리하면 각 서비스가 필요한 의존성만 가지고 실행할 수 있고, 패키지 충돌이나 불필요한 의존성을 줄일 수 있다. 무엇보다 서비스를 분리한다는 것이 단순히 폴더를 나누는 것이 아니라 실행 환경과 책임을 나누는 것이라는 점을 이해하게 됐다. (랩보다 AI 더 잘해지기)

또 하나 헷갈렸던 부분은 localhost였다.

로컬 PC에서 사용할 때는 자연스럽게 127.0.0.1이나 localhost를 사용했지만 Docker 컨테이너 안에서 localhost는 내 PC가 아니라 해당 컨테이너 자신을 의미한다.

그래서 Compose에서는 다른 컨테이너와 통신할 때 서비스 이름을 사용해야 했다.

MCP_URL=http://mcp-server:8020/mcp

이런 차이를 실제로 컨테이너를 연결해보면서 이해할 수 있었다. (랩보다 AI 더 잘해지기)

---

4. AWS EC2에 직접 배포해보기

이번 주 학습에서 가장 큰 변화는 로컬 환경을 벗어나 실제 AWS EC2에 서비스를 배포해본 것이다.

EC2는 AWS에서 제공하는 가상 서버이고, 이번 실습에서는 Ubuntu 환경의 EC2에 SSH로 접속해 Docker와 Docker Compose를 구성했다.

전체적인 과정은 다음과 같았다.

로컬 개발
↓
Docker Image 생성
↓
Docker Hub Push
↓
AWS EC2 생성
↓
SSH 접속
↓
Docker / Docker Compose 구성
↓
Docker Hub에서 Image Pull
↓
Release Compose 실행
↓
외부에서 서비스 접속

처음에는 Windows에서 .pem 개인키 권한 문제로 SSH 접속이 거부되는 문제도 있었다.

WARNING: UNPROTECTED PRIVATE KEY FILE!
Permissions for '.\agentkey.pem' are too open.

권한을 수정한 뒤 정상적으로 접속할 수 있었다. (랩보다 AI 더 잘해지기)

이전까지는 SSH 명령어를 하나의 사용법으로만 생각했다면, 이번에는 왜 개인키의 권한을 제한해야 하는지까지 생각하게 됐다.

---

5. AWS에서 가장 어려웠던 부분은 네트워크였다

이번 주에 가장 어려웠던 부분을 하나 꼽는다면 AWS 네트워크와 서비스 간 연결이었다.

로컬에서는 Docker Compose가 알아서 여러 서비스를 연결해주는 느낌이 강했지만, AWS에서 서버를 분리하면서부터는 상황이 달라졌다.

예를 들어 Frontend와 Backend가 서로 다른 서버에서 실행된다면 다음을 모두 확인해야 한다.

Backend 실행 상태
↓
Backend IP
↓
Backend Port
↓
Security Group
↓
환경변수
↓
Frontend 연결

IP가 정확하더라도 Security Group에서 해당 포트를 허용하지 않으면 연결되지 않는다.

또 Private IP와 Public IP의 차이도 직접 경험하면서 IP 주소를 알고 있다는 것과 실제로 해당 서버에 접근할 수 있다는 것은 다른 문제라는 것을 알게 됐다. (랩보다 AI 더 잘해지기)

그래서 문제가 생겼을 때 무작정 코드를 수정하기보다는,

컨테이너 → 이미지 → 환경변수 → IP/포트 → Security Group → 실제 실행 상태

순서로 확인하는 습관이 필요하다는 것을 배웠다.

---

6. 배포하면서 환경변수의 중요성도 다시 느꼈다

이번 주에는 .env를 단순한 설정 파일 정도로 생각하면 안 된다는 것도 다시 확인했다.

Frontend는 Backend의 주소가 필요하고, Backend는 Database와 Redis의 주소가 필요하다.

즉 서비스가 분리될수록 환경에 따라 달라지는 값들을 어떻게 관리할 것인지가 중요해진다.

또 .env에는 API Key와 같은 민감한 정보가 들어갈 수 있기 때문에 Git에 올리지 않아야 하고, AWS 서버에서도 파일 권한을 적절하게 설정해야 했다. (랩보다 AI 더 잘해지기)

이전에는 코드가 정상적으로 실행되는지를 중심으로 봤다면 이제는

"이 코드가 다른 환경에서도 안전하게 실행될 수 있는가?"

까지 생각해야 한다는 것을 조금씩 이해하고 있다.

---

7. CI/CD를 실제 배포 과정과 연결하다

이번 주 후반에는 GitHub Actions를 이용해 CI를 구성했다.

CI(Continuous Integration)는 코드를 GitHub에 올렸을 때 테스트나 빌드 같은 검증 작업을 자동으로 수행하는 과정이다.

이번에 구성한 흐름은 대략 다음과 같았다.

코드 수정
↓
Commit
↓
Push / Pull Request
↓
GitHub Actions
↓
Test
↓
Docker Build
↓
CI 통과

여기서 중요한 것은 단순히 Python 테스트만 하는 것이 아니었다.

실제 Docker Image를 빌드해보면서 배포에 사용할 이미지가 정상적으로 만들어지는지까지 확인했다. (랩보다 AI 더 잘해지기)

그리고 CI와 CD의 차이도 실제 배포 경험을 통해 조금 더 명확해졌다.

CI

코드 변경
↓
테스트
↓
빌드
↓
문제 검증

CD

CI 통과
↓
배포
↓
AWS 서버 반영

직접 AWS에 수동 배포해보니 왜 CI가 먼저 필요한지도 이해하기 쉬웠다.

코드에 문제가 있는 상태에서 바로 서버에 배포하면 이후 발생한 오류가 코드 문제인지, Docker 문제인지, 환경변수 문제인지, 네트워크 문제인지 구분하기가 어려워진다.

그래서 CI에서 먼저 검증하고, 그 결과를 기반으로 CD를 진행하는 구조가 필요한 것이다. (랩보다 AI 더 잘해지기)

---

8. Git Branch와 CI의 연결도 새롭게 보였다

Git도 이번 주에는 단순히 코드를 저장하고 공유하는 도구라는 생각에서 조금 벗어났다.

개인 Branch에서 작업하고,

Branch 생성
↓
코드 수정
↓
Commit
↓
Push
↓
CI 실행
↓
Test + Docker Build
↓
Main 반영
↓
CD
↓
AWS 배포

이런 흐름으로 연결할 수 있다는 것을 경험했다. (랩보다 AI 더 잘해지기)

특히 모든 Push마다 무조건 CI를 실행하는 것이 항상 효율적인 것은 아니라는 점도 배웠다.

프로젝트 규모가 커질수록 어떤 Branch나 Pull Request에서 CI를 실행할지 Workflow 자체를 설계해야 한다.

결국 자동화도 많이 하는 것이 목적이 아니라 적절한 시점에 필요한 검증이 자동으로 실행되도록 만드는 것이 중요하다는 생각이 들었다.

---

9. 이번 주에 가장 많이 겪은 문제

이번 주에는 코드 자체보다 환경과 연결 과정에서 발생하는 문제를 많이 경험했다.

실제로 겪었던 문제를 정리하면 다음과 같다.

Docker

• Redis Healthcheck 인증 문제
• Backend Healthcheck 개선
• MCP 환경변수 누락
• Agent timeout 문제
• Docker 컨테이너 간 localhost 사용 문제
• PostgreSQL 계정 및 데이터 구성 문제

AWS

• SSH .pem 권한 문제
• Docker Hub 인증 문제
• EC2 환경 구성 문제
• Security Group 포트 설정
• Public IP / Private IP 혼동
• 서버 간 연결 문제

배포

• Docker Image 이름과 Release Compose 설정 불일치
• Image 버전 확인
• .env 확인
• PostgreSQL Schema 및 데이터 초기화
• Release Compose 실행 문제

이런 문제들을 겪으면서 이번 주에는 "에러가 발생하면 코드를 먼저 수정한다"는 접근에서 벗어나기 시작했다.

오히려 시스템 전체 구조를 먼저 확인해야 원인을 빠르게 좁힐 수 있었다. (랩보다 AI 더 잘해지기)

---

10. 이번 주에 새롭게 이해한 것

이번 주 학습 전에는 Docker, AWS, GitHub Actions를 각각 별개의 기술이라고 생각했다.

지금은 조금 다르게 보인다.

AI Application
      ↓
Docker Image
      ↓
Container
      ↓
Docker Compose
      ↓
Docker Hub
      ↓
AWS EC2
      ↓
Network / Security Group
      ↓
GitHub Actions
      ↓
CI
      ↓
CD
      ↓
자동 배포

각 기술을 하나씩 배우는 것보다 이 기술들이 어떤 순서로 연결되는지를 이해하는 것이 더 중요하다는 것을 알게 됐다. (랩보다 AI 더 잘해지기)

특히 "배포"라는 단어의 의미도 조금 달라졌다.

예전에는 서버에 프로그램을 올리는 정도로 생각했다면, 이제는 배포를 위해 실행 환경, 이미지, 환경변수, 데이터베이스, 네트워크, 보안, 테스트, 자동화까지 함께 고려해야 한다는 것을 알게 됐다.

---

11. 현재 나의 상태

이번 주를 마친 지금은 이전보다 분명히 할 수 있는 것이 늘었다.

현재는

• Docker Compose를 이용해 여러 서비스를 실행할 수 있고
• Frontend와 Backend 등의 서비스를 분리해서 구성할 수 있고
• Docker Image를 만들고 Docker Hub에 올릴 수 있고
• AWS EC2에 Docker 기반 서비스를 배포해볼 수 있고
• Security Group과 포트를 설정할 수 있고
• .env를 이용해 환경별 설정을 분리할 수 있고
• GitHub Actions로 기본적인 CI Workflow를 구성할 수 있고
• 테스트와 Docker Build를 자동화하는 구조를 이해하는 단계까지 왔다. (랩보다 AI 더 잘해지기)

하지만 아직 AWS 네트워크를 처음부터 설계하거나 복잡한 CI/CD 환경을 혼자 구축할 정도는 아니다.

특히 VPC, Private/Public IP, Security Group의 관계와 실제 운영 환경에서의 네트워크 구성은 더 반복해서 경험해봐야 할 부분이다.

---

12. 다음 주에는 무엇을 보완할까?

다음 주에는 이번 주에 배운 내용을 단순히 따라 하는 수준에서 끝내지 않고 하나의 전체 흐름으로 다시 연결해보는 것을 목표로 잡고 싶다.

특히 다음 부분을 복습할 예정이다.

① AWS 네트워크

• VPC
• Public / Private IP
• Security Group
• Port
• 서버 간 통신

② Docker

• Image와 Container의 차이
• Compose
• Volume
• Network
• Release Compose

③ CI/CD

Code
↓
Test
↓
Docker Build
↓
CI
↓
Docker Registry
↓
CD
↓
AWS

이 흐름을 실제 프로젝트에 적용하면서 각각의 단계가 왜 필요한지 다시 확인해보고 싶다.

---

13. KPT 회고

Keep

이번 주처럼 오류가 발생했을 때 단순히 AI에게 수정 코드를 요청하는 것보다 현재 시스템 구조를 먼저 확인하는 습관을 계속 유지하고 싶다.

특히 Docker와 AWS 환경에서는 코드 한 줄보다 환경변수나 포트 하나가 전체 서비스를 막을 수도 있다는 것을 직접 경험했기 때문에, 문제를 구조적으로 확인하는 습관이 중요하다고 느꼈다.

Problem

아직 AWS 네트워크 구조가 완전히 익숙하지 않다.

특히 Public IP와 Private IP, VPC, Security Group이 서로 어떤 관계를 가지는지 머릿속에서 바로 연결되지 않는 경우가 있다.

또 CI/CD Workflow를 처음부터 설계하는 것도 아직은 익숙하지 않다.

Try

다음에는 단순히 강의에서 제공되는 설정을 따라가는 것에서 벗어나,

코드 수정
→ 테스트
→ Docker Build
→ Docker Hub
→ CI
→ AWS
→ 배포

전체 흐름을 스스로 설명할 수 있는 수준까지 복습해보고 싶다.

---

마무리

9월 3주의 가장 큰 변화는 개발의 범위를 조금 더 넓게 보게 된 것이다.

지금까지는 AI Agent를 어떻게 만들고 기능을 구현하는지가 중심이었다면, 이번 주에는 그 결과물을 실제 환경에서 어떻게 실행하고, 다른 서비스와 연결하고, 서버에 배포하고, 테스트하고, 자동화할 것인지까지 경험했다.

특히 Docker에서 시작해서 Docker Hub, AWS EC2, Security Group, 환경변수, GitHub Actions, CI/CD까지 연결해보면서 각각의 기술이 따로 존재하는 것이 아니라 하나의 서비스를 만들고 운영하기 위한 과정 안에서 연결되어 있다는 것을 조금씩 이해하게 됐다.

아직 혼자서 복잡한 배포 환경을 처음부터 설계할 수 있는 수준은 아니다.

하지만 적어도 이제는

"코드를 만들었다 → Docker로 실행한다 → AWS에 배포한다 → 테스트한다 → GitHub Actions로 자동화한다 → CI를 통과한 결과를 CD로 배포한다."

라는 전체적인 흐름을 볼 수 있게 됐다. (랩보다 AI 더 잘해지기)

이번 주는 AI 개발자로서 새로운 기능을 하나 더 배운 주라기보다, 내가 만든 AI 서비스를 실제 환경에서 실행하기 위해 무엇이 필요한지를 경험한 한 주였다고 정리하고 싶다.

---

해시태그

#SK네트웍스 #엔코아AI캠퍼스 #AI오케스트레이션 #AI에이전트 #Docker #DockerCompose #AWS #EC2 #GitHubActions #CICD