hb.변호진
← 프로젝트 목록

CASE STUDY 01

대파, AI 채팅 서비스를 위한
AWS 인프라

서비스 API부터 AIChat·LLM Worker까지, 애플리케이션을 실행하는 인프라 전체를 Terraform으로 구성했습니다.

기간 / 소속2025.06 – 2026.05 / 씨피랩스
프로젝트 인원10명
역할AWS 인프라 구축·운영 / 배포 자동화
핵심 기술Terraform · ECS Fargate · Bedrock

프로젝트와 담당 범위

대파는 사용자와 AI의 대화, 페르소나와의 대화 및 추천 기능을 제공하는 서비스입니다. 기능별 Agent와 Worker를 포함한 서버들이 함께 동작할 AWS 환경을 구성했습니다.

서비스 API, WebSocket, 알림 Consumer, AIChat, LLM Worker를 각각 별도 ECS 서비스로 구성했습니다. 네트워크와 데이터 저장소, Bedrock 연계 자원 등 관련 인프라를 Terraform 모듈로 관리하고 컨테이너 배포 흐름을 구축했습니다.

서비스 아키텍처

서울 리전의 공유 VPC에서 두 가용 영역(ap-northeast-2a·2c)에 Fargate 태스크를 배치했습니다. 외부 요청을 받는 계층과 내부 실행 환경을 구분했습니다.

클릭하면 크게 볼 수 있습니다. 회고 기반 논리 구성도이며, AIChat–RabbitMQ–Worker의 점선 작업 경로는 당시 자료의 추가 확인이 필요합니다. DNS·리소스 연결 관계도 점선으로 표현했습니다.
대파 AWS 서비스 아키텍처 확대 이미지

주요 설계 선택

01 / 외부 진입점

환경별 ALB 하나를 공유

서비스를 분리하면서 ALB 비용을 함께 고려했습니다. 환경별 ALB 하나를 공유하고 호스트 기반 라우팅으로 API와 WebSocket의 Target Group을 구분했습니다. ALB에는 WAF와 ACM 인증서를 연결했습니다.

02 / 실행 환경

서비스별 Fargate와 Service Connect

컨테이너가 실행되는 호스트의 관리 부담을 줄이기 위해 ECS Fargate를 선택했습니다. EC2 인스턴스를 직접 관리하는 대신 서비스와 태스크 단위로 실행 환경을 구성해, 애플리케이션 배포와 운영에 집중할 수 있도록 했습니다.

API, WebSocket, 알림 Consumer, AIChat, LLM Worker의 실행 단위를 각각 분리했습니다. 내부 서비스 통신에는 Service Connect를 사용하고, AIChat·Worker·알림 Consumer에는 외부 진입용 ALB를 직접 연결하지 않았습니다.

03 / 데이터 계층

Aurora를 공유하고 스키마로 구분

Aurora MySQL은 Writer 1대와 Reader 2대로 구성했습니다. 서비스 데이터와 Job Pool은 하나의 Aurora 환경에서 스키마 단위로 구분했습니다. MQ는 RabbitMQ 클러스터, Redis는 ElastiCache 클러스터로 구성했습니다.

04 / 네트워크 경계

Private Subnet 배치와 외부 통신 경로

ECS와 DB를 Private Subnet에 배치했습니다. 외부 API 호출에는 환경당 NAT Gateway 하나를 사용하고, VPC 내부의 S3 접근에는 VPC Endpoint를 적용했습니다.

Terraform과 배포 자동화

모듈 기반 구성과 State 관리

관련 인프라를 Terraform 모듈 단위로 나누어 관리했습니다. Terraform Cloud의 Workspace별로 State를 분리하고, Git에서도 브랜치를 나누어 인프라 코드를 관리했습니다.

구축 환경과 운영 문서를 남겼고, 퇴사 이후에도 구성원들이 이를 활용하고 있습니다.

컨테이너 빌드와 배포

클릭하면 크게 볼 수 있습니다. 컨테이너 이미지 전달 경로와 ECS 배포 제어 흐름을 구분했습니다.
대파 컨테이너 배포 자동화 프로세스 확대 이미지

Bitbucket Pipelines에서 컨테이너 이미지를 빌드해 ECR에 업로드하고, ECS Task 구성을 갱신했습니다. Fargate 태스크는 ECR에 저장된 이미지를 사용해 각 서비스를 실행합니다.

  1. Bitbucket Pipelines애플리케이션 컨테이너 이미지 빌드
  2. Amazon ECR빌드한 이미지 업로드
  3. Amazon ECS서비스에서 실행할 Task 구성 갱신

이미지 처리와 AI 연계

쿼리스트링 기반 이미지 처리

클릭하면 크게 볼 수 있습니다. 그림의 파일명과 쿼리스트링 값은 요청 형식을 보여주기 위한 예시입니다.
이미지 처리 흐름 확대 이미지

이미지에는 별도의 CloudFront·Lambda@Edge·S3 경로를 구성했습니다. 요청 쿼리스트링의 w(너비), h(높이), q(품질)에 맞춰 이미지를 리사이징하고, 변환 결과를 S3에 저장했습니다.

Bedrock Agent 연계 인프라

클릭하면 크게 볼 수 있습니다. 점선은 Agent와 관련 리소스의 연계를 나타냅니다.
AI 연계 구성 확대 이미지

LLM Worker는 Bedrock Agent를 호출합니다. Agent의 Action Group에는 Lambda가 연결되며, Knowledge Base와 OpenSearch, Context·Persona용 S3를 포함한 연계 인프라를 구성했습니다.