Summary
엔터프라이즈 AI 서비스 아키텍처 구성도 작성 과정에서 얻은 핵심 인사이트를 컨셉 중심으로 정리합니다. ECS와 ECR의 관계, Docker를 직접 사용하지 않는 개발 전략, 멀티 모듈 시스템 설계 철학 등 실무에서 마주하는 아키텍처 설계 결정의 배경과 사고과정을 다룹니다.
들어가며
AI 서비스 아키텍처 구성도를 작성해야 하는 상황에서, 단순히 기술 스택을 나열하는 것이 아닌 왜 이런 선택을 했는가에 대한 근본적인 질문들과 마주하게 되었다. ECS를 선택한 이유, Docker를 직접 사용하지 않기로 한 결정, 멀티 모듈 시스템을 어떻게 분리할 것인가 등 실무에서 마주하는 아키텍처 설계의 핵심 고민들을 정리해본다.
아키텍처 설계의 핵심 질문들
- 왜 ECS인가? EKS 대신 ECS를 선택한 배경
- Docker 없이 컨테이너? 개발자가 Docker를 직접 다루지 않는 전략
- 어떻게 모듈을 분리할 것인가? 독립적인 배포와 확장을 위한 설계
- 보안을 어떻게 녹여낼 것인가? 엔터프라이즈 환경에서의 보안 고려사항
1. ECS와 EKS: 컨테이너 오케스트레이션 서비스 이해
1.1 AWS 컴퓨팅 서비스 전체 그림
AWS에서 애플리케이션을 실행하는 방법은 크게 가상서버 방식과 컨테이너 방식으로 나뉜다. 각각의 특징과 용도를 이해하는 것이 아키텍처 설계의 첫걸음이다.
전통적인 방식: EC2 (가상서버)
- 물리 서버를 가상화한 클라우드 서버
- 운영체제부터 애플리케이션까지 모든 것을 직접 관리
- 가장 기본적이고 유연한 컴퓨팅 리소스
현대적인 방식: 컨테이너 기반
- 애플리케이션을 컨테이너로 패키징하여 실행
- 더 가볍고 빠른 배포, 확장성 우수
- 컨테이너 오케스트레이션 도구 필요
1.2 컨테이너 오케스트레이션이란?
컨테이너 오케스트레이션은 여러 개의 컨테이너를 자동으로 배포, 관리, 확장, 네트워킹하는 과정을 말한다. 단일 컨테이너를 실행하는 것은 간단하지만, 수십 개, 수백 개의 컨테이너를 관리하려면 자동화된 시스템이 필요하다.
1.3 AWS 4대 핵심 서비스: EC2, ECS, EKS, ECR
AWS에서 애플리케이션을 실행하고 관리하는 데 필요한 4가지 핵심 서비스를 명확히 구분해보자.
EC2 (Elastic Compute Cloud): 가상 서버의 기본
EC2는 AWS의 가상 서버 서비스로, 클라우드에서 확장 가능한 컴퓨팅 파워를 제공한다.
핵심 특징:
- 가상 머신: 물리 서버를 가상화한 클라우드 서버
- 완전한 제어권: 운영체제부터 애플리케이션까지 모든 것을 직접 관리
- 유연한 확장: 필요에 따라 인스턴스 크기와 수량 조절 가능
- 다양한 인스턴스 타입: CPU, 메모리, 스토리지 최적화된 다양한 옵션
언제 사용하나?
- 기존 애플리케이션을 클라우드로 이전할 때
- 특정 운영체제나 소프트웨어가 필요할 때
- 완전한 서버 제어가 필요할 때
ECR (Elastic Container Registry): 컨테이너 이미지 저장소
ECR은 Docker 컨테이너 이미지를 저장하고 관리하는 저장소 서비스다.
핵심 특징:
- 이미지 저장소: Docker Hub와 같은 역할의 AWS 관리형 서비스
- 보안: IAM 기반 접근 제어, 이미지 스캔 기능
- 버전 관리: 이미지 태그 및 라이프사이클 관리
- 통합: ECS, EKS와 자연스러운 연동
역할:
- 개발자가 빌드한 컨테이너 이미지를 안전하게 보관
- ECS나 EKS에서 컨테이너 실행 시 이미지 제공
- CI/CD 파이프라인에서 이미지 배포 허브 역할
ECS (Elastic Container Service): AWS 네이티브 컨테이너 관리
ECS는 AWS에서 자체 개발한 완전관리형 컨테이너 오케스트레이션 서비스다.
핵심 특징:
- AWS 네이티브: AWS 환경에 최적화된 설계
- 간단한 설정: 복잡한 YAML 구성 없이 AWS 콘솔에서 쉽게 설정
- Fargate 지원: 서버 관리 없이 컨테이너 실행 가능
- AWS 서비스 통합: CodePipeline, CloudWatch 등과 자연스러운 연동
ECS의 핵심 개념:
- 클러스터: 컨테이너가 실행되는 논리적 그룹
- 태스크 정의: 컨테이너 실행 방법을 정의하는 청사진
- 서비스: 지정된 수의 태스크를 유지하고 관리
- 태스크: 실제로 실행되는 컨테이너 인스턴스
EKS (Elastic Kubernetes Service): Kubernetes 기반 컨테이너 관리
EKS는 오픈소스 Kubernetes를 AWS에서 관리형으로 제공하는 서비스다.
핵심 특징:
- Kubernetes 기반: 업계 표준 오케스트레이션 플랫폼 사용
- 오픈소스 생태계: 다양한 Kubernetes 도구와 호환
- 멀티 클라우드 지원: 다른 클라우드나 온프레미스와 연동 가능
- 높은 확장성: 복잡한 마이크로서비스 아키텍처에 적합
Kubernetes의 핵심 개념:
- 클러스터: 마스터 노드와 워커 노드로 구성된 전체 시스템
- 파드(Pod): 하나 이상의 컨테이너를 포함하는 최소 배포 단위
- 서비스: 파드들에 대한 네트워크 접근을 제공
- 디플로이먼트: 파드의 배포와 업데이트를 관리
1.4 서비스 간 관계와 차이점
EC2 vs 컨테이너 서비스 (ECS/EKS)
| 비교 항목 | EC2 | ECS/EKS |
|---|---|---|
| 추상화 수준 | 가상 서버 (낮음) | 컨테이너 (높음) |
| 관리 범위 | OS부터 애플리케이션까지 | 애플리케이션 컨테이너만 |
| 배포 속도 | 느림 (부팅 시간 필요) | 빠름 (초 단위) |
| 리소스 효율성 | 낮음 (OS 오버헤드) | 높음 (컨테이너 공유) |
| 확장성 | 수동/반자동 | 자동 (오케스트레이션) |
ECS vs EKS 비교
Elancer 기술 블로그에 따르면:
| 비교 항목 | ECS | EKS |
|---|---|---|
| 학습 곡선 | 완만 (AWS 콘솔 기반) | 가파름 (Kubernetes 지식 필요) |
| 설정 복잡도 | 간단 | 복잡 (YAML 구성 필요) |
| AWS 통합 | 완벽 | 보통 |
| 확장성 | AWS 내 우수 | 멀티클라우드 우수 |
| 운영 부담 | 낮음 | 높음 |
| 적합한 조직 | 스타트업, 소규모 팀 | 대기업, 복잡한 아키텍처 |
ECR의 역할
ECR은 다른 세 서비스와 다른 성격을 가진다:
- EC2: 가상 서버에서 직접 애플리케이션 실행 (ECR 불필요)
- ECS: ECR에서 이미지를 가져와 컨테이너로 실행
- EKS: ECR에서 이미지를 가져와 Kubernetes 파드로 실행
서비스 조합 패턴
- EC2 단독: 전통적인 서버 기반 애플리케이션
- ECR + ECS: AWS 네이티브 컨테이너 환경
- ECR + EKS: Kubernetes 기반 컨테이너 환경
- EC2 + ECS/EKS: 컨테이너 오케스트레이션의 워커 노드로 EC2 활용
1.5 ECS (Elastic Container Service) 상세 분석
Amazon ECS는 AWS에서 자체 개발한 완전관리형 컨테이너 오케스트레이션 서비스다.
핵심 특징:
- AWS 네이티브: AWS 환경에 최적화되어 설계됨
- 완전관리형: AWS가 인프라 관리를 대신 처리
- 간단한 설정: 복잡한 설정 없이 빠른 시작 가능
- AWS 서비스 통합: IAM, VPC, CloudWatch 등과 자연스러운 연동
ECS의 핵심 개념:
- 클러스터: 컨테이너가 실행되는 논리적 그룹
- 태스크 정의: 컨테이너 실행 방법을 정의하는 청사진
- 서비스: 지정된 수의 태스크를 유지하고 관리
- 태스크: 실제로 실행되는 컨테이너 인스턴스
1.6 전체 워크플로우 이해
개발자 코드 작성
↓
CI/CD 파이프라인에서 이미지 빌드
↓
ECR에 이미지 저장 (저장소 역할)
↓
ECS가 ECR에서 이미지 Pull
↓
ECS에서 컨테이너로 실행 (실행 환경 역할)
↓
실제 서비스 운영
이 워크플로우에서 중요한 것은 개발자가 직접 Docker 명령어를 사용하지 않는다는 점이다.
2. “Docker를 쓰지 않는다”의 진짜 의미
2.1 Docker vs 컨테이너 기술의 구분
회의에서 나온 “Docker는 가급적 쓰지 않는 게 좋다”는 말이 처음에는 이해가 안 됐다. ECS는 컨테이너 서비스인데 Docker 없이 어떻게 컨테이너를 쓴다는 건가?
핵심은 역할 분리다:
- 컨테이너 기술: 애플리케이션을 격리된 환경에서 실행하는 기술 자체
- Docker: 컨테이너를 만들고 실행하는 도구 중 하나
즉, “Docker를 안 쓴다”는 것은 개발자가 직접 Docker 명령어를 사용하지 않는다는 뜻이지, 컨테이너 기술 자체를 포기한다는 의미가 아니다.
2.2 개발 환경의 패러다임 전환
전통적인 방식:
로컬에서 Docker 설치
→ Dockerfile 작성
→ docker build로 이미지 생성
→ docker run으로 테스트
→ 수동으로 이미지 푸시
새로운 방식:
로컬에서 네이티브 개발 (venv, npm 등)
→ Git에 코드 푸시
→ CI/CD가 자동으로 이미지 빌드
→ ECR에 자동 업로드
→ ECS가 자동 배포
2.3 OS 호환성 문제 해결 전략
“OS가 다른데?”라는 질문이 핵심이었다. 개발자는 Mac/Windows를 쓰는데 서버는 Linux다. 이 문제를 어떻게 해결할 것인가?
단기 해결책:
- 로컬에서는 가상환경(venv, conda 등) 사용
- 환경 불일치는 CI/CD 단계에서 해결
- 테스트는 클라우드 환경에서 수행
장기 해결책 (데이터포탈):
- JupyterLab 기반 클라우드 개발환경
- 브라우저에서 직접 개발
- 환경 불일치 문제 근본적 해결
핵심 인사이트
“모두가 행복해지는 길”이라는 표현처럼, 개발자는 복잡한 Docker 환경 설정에서 해방되고, 운영팀은 표준화된 배포 파이프라인을 얻게 된다.
3. ECS vs EKS: 실무에서의 선택 기준
3.1 선택 기준 분석
아키텍처 구성도를 그리면서 가장 먼저 마주한 질문이 “ECS vs EKS” 선택이었다.
| 비교 항목 | ECS | EKS | 우리의 선택 근거 |
|---|---|---|---|
| 학습 곡선 | 완만 | 가파름 | Kubernetes 전문가 부족 |
| 운영 복잡도 | 낮음 | 높음 | 운영 리소스 제약 |
| AWS 통합 | 완벽 | 보통 | AWS 생태계 활용 극대화 |
| 확장성 | 충분 | 우수 | 현재 요구사항에 적합 |
| 비용 | 저렴 | 비싸 | 클러스터 관리 비용 없음 |
3.2 “모두가 행복해지는 길”의 의미
회의에서 나온 이 표현이 ECS 선택의 핵심을 담고 있다:
- 개발팀: 복잡한 Kubernetes 학습 부담 없음
- 운영팀: AWS 관리형 서비스로 운영 부담 최소화
- 비즈니스: 빠른 개발과 안정적인 운영으로 비용 효율성 확보
3.3 ECS의 실용적 장점
AWS 네이티브 통합:
- IAM, VPC, CloudWatch 등과 자연스러운 연동
- 별도 설정 없이 AWS 서비스들과 호환
관리 부담 최소화:
- 마스터 노드 관리 불필요
- 자동 패치 및 업데이트
- 서비스 디스커버리 내장
비용 최적화:
- 클러스터 관리 비용 없음
- Fargate 사용 시 서버 관리 완전 제거
- 사용한 만큼만 과금
4. 멀티 모듈 시스템 설계 철학
4.1 모듈 분리의 기준
AI 서비스를 여러 모듈로 나누는 기준이 무엇인가? 단순히 기능별로 나누는 것이 아니라, 비즈니스 도메인과 데이터 특성을 고려해야 한다.
도메인 기반 분리:
- 계획 모듈: 전략 수립, 의사결정 지원
- 제조 모듈: 생산 최적화, 품질 관리
- 고객지원 모듈: 문의 응답, 지식 관리
데이터 특성 기반 분리:
- 각 모듈은 독립적인 데이터 저장소 보유
- 벡터 데이터베이스의 컬렉션 분리
- 관계형 데이터베이스의 스키마 분리
4.2 독립성과 통합의 균형
독립성 확보:
- 각 모듈은 독립적으로 배포 가능
- 한 모듈의 장애가 다른 모듈에 영향 없음
- 모듈별 스케일링 가능
통합 지점 관리:
- API Gateway를 통한 통합 진입점
- 공통 인증 및 권한 관리
- 통합 모니터링 및 로깅
4.3 데이터 저장소 분리 전략
벡터 데이터베이스 (Qdrant):
- 모듈별 독립적인 컬렉션
- 각 모듈의 도메인 특화 임베딩
- 검색 성능 최적화를 위한 분리
관계형 데이터베이스 (MariaDB):
- 모듈별 독립적인 스키마
- 공통 메타데이터는 별도 관리
- 트랜잭션 경계 명확화
오브젝트 스토리지 (S3):
- 모듈별 버킷 또는 폴더 분리
- 접근 권한 세분화
- 라이프사이클 정책 독립 관리
5. 보안 아키텍처의 설계 철학
5.1 다층 보안 체계
엔터프라이즈 환경에서 보안은 단일 지점이 아닌 다층 방어 개념으로 접근해야 한다.
네트워크 레벨:
- VPC를 통한 네트워크 격리
- Private Subnet에 핵심 서비스 배치
- Security Group을 통한 세밀한 접근 제어
애플리케이션 레벨:
- API Gateway를 통한 인증/인가
- JWT 토큰 기반 세션 관리
- Rate Limiting으로 남용 방지
데이터 레벨:
- 전송 중 암호화 (TLS/SSL)
- 저장 중 암호화 (KMS)
- 개인정보 마스킹 및 해싱
5.2 외부 AI API 연동 보안
API 키 관리:
- AWS Secrets Manager를 통한 중앙화된 키 관리
- 키 순환 정책 적용
- 환경별 키 분리
사용량 모니터링:
- CloudWatch를 통한 실시간 모니터링
- 비용 임계값 알람 설정
- 사용 패턴 분석을 통한 이상 탐지
네트워크 보안:
- NAT Gateway를 통한 아웃바운드 트래픽 제어
- 화이트리스트 기반 외부 API 접근
- VPC Endpoint 활용으로 트래픽 AWS 내부 유지
5.3 데이터 프라이버시 고려사항
개인정보 보호:
- 사용자 쿼리 로깅 시 민감정보 마스킹
- 벡터 임베딩 데이터 암호화
- 데이터 보존 정책 적용
감사 추적:
- 모든 AI API 호출 로깅
- 사용자 활동 추적
- 정기적인 보안 감사
6. 운영 효율성을 위한 설계 결정
6.1 자동화 우선 원칙
배포 자동화:
- Git 푸시만으로 전체 배포 파이프라인 실행
- Blue-Green 배포를 통한 무중단 서비스
- 자동 롤백 메커니즘
모니터링 자동화:
- CloudWatch를 통한 실시간 메트릭 수집
- 임계값 기반 자동 알람
- 대시보드를 통한 시각화
스케일링 자동화:
- CPU/메모리 사용률 기반 오토스케일링
- 예측 기반 스케일링
- 비용 최적화를 위한 스팟 인스턴스 활용
6.2 개발자 경험(DX) 최적화
단순화된 워크플로우:
- 로컬에서는 네이티브 개발 환경
- 복잡한 Docker 설정 제거
- 원클릭 배포 시스템
결론: 아키텍처 설계의 핵심 철학
엔터프라이즈 AI 서비스 아키텍처를 설계하면서 얻은 가장 중요한 인사이트는 기술적 완성도보다는 실용성과 운영 효율성이 더 중요하다는 것이다.
핵심 설계 원칙
- 단순함이 복잡함을 이긴다: ECS 선택, Docker 직접 사용 배제
- 개발자 경험이 우선이다: 복잡한 설정보다는 직관적인 워크플로우
- 보안은 설계 단계부터: 나중에 추가하는 것이 아닌 처음부터 고려
- 확장성은 필요할 때: 과도한 엔지니어링보다는 점진적 개선
- 비용 효율성: 기술적 우아함보다는 실제 비즈니스 가치
“모두가 행복해지는 길”이라는 표현처럼, 좋은 아키텍처는 개발자, 운영자, 비즈니스 모든 관점에서 만족할 수 있는 균형점을 찾는 것이다.
차주 수요일까지 완성해야 하는 구성도는 단순히 기술 스택을 나열하는 것이 아니라, 이러한 설계 철학과 의사결정 과정을 담은 살아있는 문서가 되어야 한다. 그래야만 팀 전체가 공감하고 실제로 구현 가능한 아키텍처가 될 수 있을 것이다.
참고자료
AWS 서비스 기본 개념:
- AWS EC2 공식 문서 - Amazon EC2 가상 서버 서비스 개요
- AWS ECS 공식 문서 - Amazon ECS 컨테이너 서비스 개요
- AWS EKS 공식 문서 - Amazon EKS Kubernetes 서비스 개요
- AWS ECR 공식 문서 - ECR과 ECS 연동 가이드
서비스 비교 및 분석:
- Elancer - AWS ECS vs EKS 차이점 - DevOps 엔지니어 관점의 상세 비교 분석
- Medium - Amazon ECS ECR 이해 - ECS와 ECR 관계 설명
- SmileShark - AWS 컨테이너 서비스 비교 - ECS, EKS, Fargate 상세 비교
- JRanke 기술 블로그 - 네트워크 관리 방법 비교
아키텍처 설계 원칙:
- AWS Well-Architected Framework - 엔터프라이즈 아키텍처 설계 원칙
- AWS 컨테이너 보안 모범 사례 - 컨테이너 보안 가이드
- Microservices.io - 마이크로서비스 아키텍처 패턴