🦊 Weasel 프로젝트 – AI 기반 문제풀이 서비스

📌 Intro

Weasel 프로젝트는 AWS Bedrock Claude Sonnet 3.5 모델을 활용한 문제풀이 서비스입니다.
사용자가 문제 이미지를 업로드하면 AI가 정답과 해설을 제공합니다.
총 6명 (Frontend 2명, Backend 2명, Infra 2명)이 참여했고, 저는 인프라 팀의 일원으로 프로젝트를 성공적으로 마무리했습니다.

---

---

📝 프로젝트 개요

• 목표: 문제 이미지 업로드 → AI 정답·해설 제공 + CI/CD + 모니터링 환경 구성
• 주요 스택:
  • Backend: Spring Boot
  • Frontend: React
  • IaC(인프라 코드화): Terraform
  • 배포 환경: Amazon EKS, S3, Route53, CloudFront
  • AWS 서비스: VPC, ECR, Secrets Manager, WAF
  • CI/CD: Jenkins, ArgoCD
  • GenAI 모델: AWS Bedrock (Claude Sonnet 3.5)
  • 모니터링: Prometheus, Grafana

🔗 GitHub Link

• Weasel - Github

---

🏗 아키텍처

• AI 처리 흐름: 문제 이미지를 업로드하면 API가 AWS Bedrock(Claude Sonnet 3.5)과 연동되어, 빠르고 정확한 정답·해설을 반환하도록 구성
• CI/CD 자동화: 코드 변경 시 Jenkins가 자동 빌드를 수행하고, ArgoCD로 EKS에 배포하여 배포 속도와 안정성을 높임
• 모니터링: Prometheus와 Grafana로 CPU·메모리 사용량, API 응답 속도, 에러율을 실시간 확인해 장애를 조기 발견
• 보안 및 HTTPS 적용: CloudFront와 WAF를 활용해 전 구간 HTTPS 통신과 웹 공격 방어를 구현
• 인프라 코드화: Terraform으로 인프라를 코드로 관리해, 환경 재현성과 재사용성을 확보

---

⚙️ CI/CD 아키텍처

백엔드 배포 파이프라인 (Spring Boot → EKS)

1. GitHub에 코드를 올리면 Jenkins가 자동으로 빌드를 시작합니다.
2. 애플리케이션을 빌드하고, Docker 이미지를 만들어 ECR에 저장합니다.
3. ArgoCD가 매니페스트(Helm/Kustomize) 변경 사항을 감지합니다.
4. 변경된 내용을 EKS에 반영하며, 롤링 업데이트 또는 Blue/Green 방식으로 배포합니다.

프론트엔드 배포 파이프라인 (React → S3·CloudFront)

1. GitHub에 코드를 올리면 Jenkins가 프론트엔드 빌드를 실행합니다.
2. 빌드된 정적 파일(build/)을 S3 버킷에 업로드합니다.
3. 배포 시 CloudFront 캐시를 자동 무효화로 최신 파일을 받을 수 있게 구성했습니다.

Jenkins 빌드 파이프라인 실행 화면

---

📢 배포 알림 자동화

• Jenkins 빌드 완료 후 Slack Webhook을 통해 성공/실패 여부 실시간 알림
• 백엔드·프론트엔드 각각 별도 파이프라인으로 빌드 상태 확인 가능
• 알림 메시지에 Jenkins Job URL을 포함해 즉시 로그·상태 확인 가능

Jenkins 빌드 성공 시 Slack 채널에 실시간 알림

---

💻 서비스 화면

문제 이미지를 업로드할 수 있는 입력 UI 및 채팅 내용 저장

업로드한 문제 이미지에 대해 AI가 정답과 해설을 반환하는 화면

---

📊 모니터링

Grafana 대시보드

Prometheus와 Grafana를 활용해 CPU·메모리 사용량, API 응답 속도, 에러율 등을 실시간으로 모니터링했습니다.
이를 통해 성능 저하나 장애 징후를 조기에 발견하고 신속히 대응할 수 있었습니다.

---

⚠️ 트러블슈팅 : Node.js Dockerfile 최적화

문제

• Dockerfile이 개발 환경과 프로덕션 환경 구분 없이 작성되어 최종 이미지에 불필요한 개발 도구와 의존성이 포함됨
• 빌드 과정 없이 바로 실행해 최적화가 전혀 이루어지지 않음
• 실행 명령어(npm run dev)가 개발 환경 기준으로 설정되어 프로덕션에 적합하지 않음

---

원인

1. 베이스 이미지
   • node:20.14.0 이미지는 개발 도구가 포함되어 최종 이미지 크기가 커짐
2. 빌드 과정 누락
   • 최적화된 빌드 산출물이 아닌 원본 소스 코드로 실행
3. 실행 명령어 부적절
   • npm run dev → 개발 의존성(devDependencies)까지 포함 설치
   • 프로덕션에서는 npm start 사용이 적합

---

해결

• 이미지 최적화: 빌드 단계와 배포 단계를 분리 (multi-stage build)
• 슬림 이미지 사용: 프로덕션 단계에서 node:<버전>-slim 사용
• 빌드 명령어 추가: RUN yarn build로 프로덕션 빌드 생성
• 실행 명령어 변경: CMD ["npm", "start"]로 프로덕션 실행

---

변경 전/후 비교

변경 전

FROM node:20.14.0

WORKDIR /usr/src/app

COPY package.json yarn.lock ./
RUN yarn install

COPY . .

EXPOSE 3000
CMD ["npm", "run", "dev"]

변경 후 (Multi-stage build)

# 빌드 단계
FROM node:20.14.0 AS builder
WORKDIR /usr/src/app
COPY package.json yarn.lock ./
RUN yarn install --frozen-lockfile
COPY . .
RUN yarn build

# 프로덕션 단계
FROM node:20.14.0-slim
WORKDIR /usr/src/app
COPY package.json yarn.lock ./
RUN yarn install --production --frozen-lockfile
COPY --from=builder /usr/src/app/dist ./dist

EXPOSE 3000
CMD ["npm", "start"]

---

효과

• 이미지 크기 감소: 불필요한 개발 도구/의존성 제거
• 실행 효율 향상: 최적화된 빌드 결과물만 배포
• 환경 분리: 개발/배포 환경 명확하게 구분

---

⚠️ 트러블슈팅 : Jenkins 파이프라인 브랜치 필터링

문제

• 메인 브랜치에 병합하기 전에 생성된 브랜치에서 push 시에도 Jenkins 파이프라인이 실행됨
• main 브랜치 변경 시에만 파이프라인이 동작하도록 제어 필요

---

원인

• 기존 설정(GitHub hook trigger for GITScm polling)은 모든 브랜치 변경 시 파이프라인이 실행됨
• 브랜치 조건 필터링 로직이 없어 main 외 브랜치에서도 빌드가 수행됨

---

해결

1. Plugin 변경

• GitHub hook trigger for GITScm polling → Generic Webhook Trigger

---

2. Build Triggers 설정

• 기존: GitHub hook trigger for GITScm polling
• 변경: Generic Webhook Trigger

---

3. Post Content Parameters

1. genericVariables
   • key: 'ref', value: '$.ref' 설정
   • JSONPath($.ref)로 웹훅 페이로드에서 브랜치 정보 추출 후 변수 ref에 저장
2. regexpFilterText
   • $ref로 설정 → 추출된 브랜치 정보(ref)를 필터 텍스트로 사용
3. regexpFilterExpression
   • 'refs/heads/main' 지정 → main 브랜치일 때만 빌드 실행

---

4. Optional filter

• Text: ref 변수 값
• Expression: refs/heads/main

---

웹훅 설정

• Payload URL

  http://<도메인 또는 IP>/generic-webhook-trigger/invoke?token=<토큰>

• Content type: application/json

---

변경 전/후 비교

항목	변경 전	변경 후
Build Trigger	GitHub hook trigger for GITScm polling	Generic Webhook Trigger
브랜치 필터링	모든 브랜치에서 빌드 실행	main 브랜치에서만 빌드 실행
필터 조건	없음	JSONPath($.ref)로 브랜치 추출 → 정규식(refs/heads/main) 매칭

---

💡 마무리

Weasel 프로젝트를 통해 팀원 간 소통과 협력의 중요성을 깊이 느꼈습니다.
첫 팀 프로젝트였던 만큼 부족한 점도 많았지만, 개인 프로젝트에서는 드러나지 않았던 보안 관리, 운영 안정성, 배포 효율성의 한계를 체감했습니다.
이를 해결하기 위해 CI/CD 파이프라인을 최적화해 배포 속도를 개선하고, Grafana·Prometheus 기반 모니터링 환경을 구축해 장애 발생 시 신속하게 대응할 수 있는 체계를 마련하는 등 많은 것을 배웠습니다.

부족하다 느낀점

향후에는 비용 효율성을 위해 Jenkins Fleet을 도입해, 빌드 시에만 에이전트를 동적으로 생성하고 사용 후 자동 종료하는 방식으로 EC2 비용을 절감하는 방안도 고려하고 있습니다.
앞으로도 IaC 기반 클라우드 아키텍처 설계 역량을 확장해, 대규모 트래픽 환경에서도 안정적이고 효율적인 서비스를 운영할 수 있는 체계를 구축하는 것을 목표로 하겠습니다.

---