WEEK 17 나만무 MVP TIL(7월4일 금요일)

Devkty·2025년 7월 7일

MVP week 17 나만무 크래프톤 정글 연대기

크래프톤 정글(나만의 무기 만들기 WEEK 14 ~ 20)

목록 보기

30/57

[목표]

프로젝트 흐름/진행도 구성(파이프 라인)(진행중)

~~어제 했던 내용들 회고 작성(트러블슈팅)~~

~~새로운 UX/UI 전체적으로 적용(슬레이트 색상), 아이콘 및 파비콘 적용~~

~~로그인/회원가입/이메일 인증 프론트엔드 개선(명석이형 요청)~~

AWS 오토스케일링 적용하기(ALB)

13:30 ~ 14:30

소영님이 CI/CD 관련된 질문을 하셔서 알려드렸다. 우리 프로젝트 기준으로 설명드렸다.

14:30 ~ 18:00

새로운 UX/UI를 적용하다.

오토스케일링을 하기 전에 로그인과 아이콘, 파비콘, 로그인/회원가입/이메일 인증 프론트엔드를 손보고 있다.

새로운 파비콘, 아이콘 적용
새로운 색상인 #64748b, #475569 슬래이트 색상 UI에 적용
로그인/회원가입/이메일 인증 프론트엔드 적용
오류페이지 404, 500, 일반 오류, 서버 점검 중 Error 페이지 적용

로그인 페이지 개선

회원가입 페이지 개선

이메일 인증 개선

이메일 인증 결과 개선

비밀번호 찾기 추가(구현은 안됨)

오류페이지를 추가하다.

원래는 형편없는 오류 페이지를 발생시키지만, 이제는 정확한 이유를 파악할 수 있다. 그리고 상황에 따라 시스템 점검중이라는 표시를 nginx 주석을 통해 제어 가능하다.
rewrite ^/(.*)$ /maintenance break; 문구를 각각의 서빙 코드에 추가하면된다.

nginx.conf

server {
    listen 80;
    server_name code-planner.com;
    
    # 프론트엔드 정적 파일 서빙
    location / {
        # rewrite ^/(.*)$ /maintenance break;  # 서버 점검시 주석 해제, 점검완료시 주석
        proxy_pass http://localhost:3000;
        proxy_http_version 1.1;
        .
        .
        .
    }
    
    # API 요청을 백엔드로 프록시 + CORS 헤더 및 OPTIONS 처리
    location /api/ {
        # rewrite ^/(.*)$ /maintenance break;  # 서버 점검시 주석 해제, 점검완료시 주석
        proxy_pass http://localhost:5000/api/;
        proxy_http_version 1.1;
        .
        .
        .

→ 팀원이 dev 적용하는대로 서버에 패치해보겠다.

18:20 ~ 19:10

밖에서 식사를 하고 왔다.

19:10 ~ 23:00

약간의 휴식을 가졌다.
이제 어제 적용하다 못한 오토스케일링을 서버에 적용시켜보겠다.

AWS 오토스케일링 적용하기

어제 작업하던게 좀 꼬인것 같아서 처음부터 차근차근 해보려고 한다.
AMI를 써서 오토스케일링 하는 방법도 있는데, 나는 깃허브 액션을 사용한 CI/CD환경이 구축되어 있기 때문에 AWS 기본 AMI + User Data 를 쓰는 방식을 사용할 것이다. 대략적인 차이는 다음과 같다.

항목	AWS 기본 AMI + User Data	직접 생성한 AMI
유연성	매우 높음 (코드 변경 시 자동 반영 가능)	낮음 (AMI 재생성 필요)
GitHub Actions + S3 연계	적합함	번거로움
유지보수	스크립트만 수정하면 됨	매번 AMI 생성/배포 필요
확장성	CI/CD, IaC와 잘 맞음	수동 관리 필요
빌드 자동화 연계	GitHub Actions, S3 배포와 직접 연결 가능	불편함

흐름도

AWS 기본 AMI 선택
- 예: Amazon Linux 2023, Ubuntu 22.04 LTS 등
User Data 스크립트 작성
- Nginx, Node.js 설치
- S3에서 빌드 결과(app.tar.gz 등) 다운로드
- 압축 해제 및 서비스 실행 (예: pm2 start, systemctl start nginx 등)
GitHub Actions에서 S3로 코드 배포
- main 브랜치에 push 시 앱 빌드 및 압축
- S3 버킷에 업로드 (deploy/ 디렉토리 등)
Auto Scaling 그룹은 해당 User Data가 포함된 시작 템플릿 사용

1. 사전 조건

EC2 인스턴스가 Nginx + 웹 서비스 설정 완료된 상태
ALB 생성 및 Target Group 연결 완료
CloudFront가 ALB를 Origin으로 구성됨
EC2에서 서비스 포트는 80 혹은 8080 등으로 노출되어 있어야 함.
서비스가 정상적으로 배포되고 있음.

2. EC2 시작 템플릿 작성하기 (Launch Template)

우선적으로 EC2 시작 템플릿을 작성한다. 왜냐하면 동적으로 EC2를 실행시킬때 원래 서버와 같은 환경을 만들어 둬야 하기 때문이다.

EC2 → 인스턴스 → 시작 템플릿 → 시작 템플릿 생성 클릭!

애플리케이션 및 OS 이미지: 퀵스타트에서 원하는 OS를 선택하면 된다. 나 같은 경우 본 서버와 같은 우분투 24.04_64비트로 선택했다.
인스턴스 유형: 원하는 사양을 고르면 된다. 나같은 경우 t2.micro로 선택했다. 서브 서버이기 때문이다. (본 서버는 t2.medium 이었음)
키 페어 이름: 본인이 원래쓰는 키를 넣으면 된다. 접속할 때 쓰인다.
네트워크 설정: 서브넷, 가용 영역 등은 Auto Scaling 그룹에서 지정하므로 여기선 선택하지 않아도 된다. 그러나 보안 그룹은 기존 서버에 쓰는 보안 그룹을 설정하자. 보통 통신을 위해 80(http), 443(https), 3000(Front), 5000(Back)은 열어줘야한다.
스토리지: 알아서 적당한 크기를 설정한다.
고급 세부 정보: 고급 세부 정보에 맨 밑에 사용자 데이터- 선택사항이라는 필드가 있다. 여기에 CI/CD 배포 코드를 작성하면 된다. 예를 들어 pm2, nginx, git, npm 관련 코드가 여기에 들어간다. 나 같은 경우 커서를 통해 백엔드와 프론트엔드의 ‘위의 코드는 백엔드의 Auto Scaling 시 사용할 EC2 인스턴스 템플릿 스크립트인데, 너가 deploy.yml을 참고해서 프론트엔드와 백엔드를 돌릴수 있는 스크립트를 짜줘’라는 프롬포트를 통해 작성을 했다.

모두 천천히 읽어보고 깃허브 클론 URL 같은 경우는 우리 프로젝트에 맞게 편집해야한다. 이거를 사용자 데이터에 추가하자.

#!/bin/bash
# 1. 기본 패키지 설치
sudo apt-get update -y
sudo apt-get install -y git curl

# 2. Node.js, npm, pm2 설치 (Node 18 기준)
curl -fsSL https://deb.nodesource.com/setup_18.x | sudo -E bash -
sudo apt-get install -y nodejs
sudo npm install -g pm2

# 3. 프로젝트 클론 (이미 있다면 git pull)
if [ ! -d "/home/ubuntu/codeplanner/Codeplanner_Backend" ]; then
  sudo mkdir -p /home/ubuntu/codeplanner
  sudo chown ubuntu:ubuntu /home/ubuntu/codeplanner
  cd /home/ubuntu/codeplanner
  git clone https://github.com/Krafton-Jungle-Weight/Codeplanner_Backend.git
else
  cd /home/ubuntu/codeplanner/Codeplanner_Backend
  git pull origin main
fi

if [ ! -d "/home/ubuntu/codeplanner/Codeplanner_Frontend" ]; then
  cd /home/ubuntu/codeplanner
  git clone https://github.com/Krafton-Jungle-Weight/Codeplanner_Frontend.git
else
  cd /home/ubuntu/codeplanner/Codeplanner_Frontend
  git pull origin main
fi

# 4. 환경 변수 파일(.env) 준비 (필요시 S3 등에서 다운로드)
# 예시: aws s3 cp s3://your-bucket/.env .env
# 나같은 경우 이미 프로젝트 파일에 있어 준비 X

# 5. 백엔드 의존성 설치 및 빌드
sudo chown -R ubuntu:ubuntu /home/ubuntu/codeplanner/Codeplanner_Backend
cd /home/ubuntu/codeplanner/Codeplanner_Backend
sudo npm install
npm run build
pm2 start ecosystem.config.js --env production

# 6. 프론트엔드 의존성 설치 및 빌드
sudo chown -R ubuntu:ubuntu /home/ubuntu/codeplanner/Codeplanner_Frontend
cd /home/ubuntu/codeplanner/Codeplanner_Frontend
sudo npm install
npm run build
pm2 start ecosystem.config.js --env production

# 7. pm2로 서버 실행 (포트는 필요에 따라 조정)
export NODE_ENV=production

# 백엔드 실행 (예: 5000번 포트)
pm2 start dist/src/main.js --name codeplanner-backend || pm2 restart codeplanner-backend

# 프론트엔드 실행 (Next.js, 예: 3000번 포트)
pm2 start npm --name codeplanner-frontend -- start || pm2 restart codeplanner-frontend

pm2 save

3. 대상그룹 생성 (ALB용)

ALB는 트래픽을 특정 EC2에 직접 보내지 않고 Target Group을 통해 전달하기 때문에 필요하다.
EC2 → 대상 그룹 → 대상 그룹 생성 클릭!

이후에 다음과 같이 작성하세요. 저 같은 경우 이미 80번에 배포를 하고 있어서 기존 대상 그룹을 사용했습니다. 생서 후에 대상 그룹 이름은 기억해둬야합니다.

항목	값
대상 유형	인스턴스
프로토콜	HTTP
포트	3000 또는 80 (프론트 기준)
VPC	ALB가 위치할 VPC
헬스체크 경로	예: `/` 또는 `/health`
포트	앱이 리스닝 중인 포트 (예: 3000 또는 5000)

4. ALB 생성하기

대상 그룹 위에 로드 밸런서 → ALB 생성 클릭!

Application Load Balancer 선택하고 다음과 같이 설정하면 된다. 나 같은 경우 이미 생성되어 있는 ALB가 있어서 그걸 사용했다.

항목	값
이름	codeplanner-alb
스키마	인터넷 연결용
리스너	HTTP:80 (HTTPS는 나중에 추가 가능)
VPC 및 서브넷	2개 이상의 퍼블릭 서브넷 선택
보안 그룹	80, 443 포트 오픈된 SG 선택 또는 생성

5. Auto Scaling Group 생성

EC2콘솔 → Auto Scaling Group → 생성
시작 템플릿: 이름을 정하고 아까 만든 시작 템플릿을 선택한다.
VPC: 기본값으로 설정한다.
가용 영역 및 서브넷: ALB와 동일한 VPC와 서브넷을 선택한다.
가용 영역 배포: 상황에 따라 다르지만 나같은 경우 ‘균형 잡힌 최선 노력’으로 했다.
로드 밸런싱: 기존 로드 밸러서에 연결을 선택하고 아까 만든 로드 밸런서 대상 그룹을 선택한다.
VPC Lattice 통합 옵션: 서비스 없음을 누른다.
ARC: 설정하지 않는다. 상황에 따라 켜도된다.
상태확인: 상태확인이 필요하면 키면 된다. Elastic Load Balancer 상태 확인 켜기를 선택한다.
그룹크기: 원하는 용량을 2로 한다.
크기 조정: 최소는 1, 최대는 3~4으로 한다. 그러면 최대 2까지의 EC2를 여분으로 둔다. (지금은 테스트라 2로 해두었고 나중에 조정하면 된다.)
Automatic scaling: 대상 추적 크기 조정 정책으로 선택하고 평균 CPU 사용률 80으로 두면 평균 80퍼에 도달시 인스턴수 수가 증가한다.
인스턴스 유지 관리 정책: 나 같은 경우는 정책 없음으로 했다. 상황에 따라 선택하자.
추가 용량 설정: 기본값. 미리 정해둔 용향으로 진행한다.
추가설정: 건드릴 설정이 없다.
알림 설정: 필요하면 설정하자.
태그 설정: 안해도된다.

6. 대상 그룹으로 가서 헬스 체크를 확인한다.

여기서 안됨. 유예기간 늘리고 로그로 확인중이다.
나중에 이어서 확인중이다.

23:00 ~ 02:30

dev에 병합준비하기

dev에 병합 준비가 완료 되어서 병합을 진행했다. 업데이트 내역은 다음과 같다.

새로운 파비콘, 아이콘 적용
새로운 색상인 #64748b, #475569 슬래이트 색상 UI에 적용
로그인/회원가입/이메일 인증 프론트엔드 적용
오류페이지 404, 500, 일반 오류, 서버 점검 중 등 Error 페이지 적용

패키지 보안 문제 해결(axios의 localtunnel)

C:\Users\KTY\jungle_project\Codeplanner_Backend>npm install

added 44 packages, and audited 941 packages in 3s

168 packages are looking for funding
  run `npm fund` for details

2 high severity vulnerabilities

To address all issues (including breaking changes), run:
  npm audit fix --force

Run `npm audit` for details.

C:\Users\KTY\jungle_project\Codeplanner_Backend>  npm audit
# npm audit report

axios  <=0.29.0
Severity: high
Axios Cross-Site Request Forgery Vulnerability - https://github.com/advisories/GHSA-wf5p-g6vw-rhxx
axios Requests Vulnerable To Possible SSRF and Credential Leakage via Absolute URL - https://github.com/advisories/GHSA-jr5f-v2jv-69x6
fix available via `npm audit fix --force`
Will install localtunnel@1.8.3, which is a breaking change
node_modules/localtunnel/node_modules/axios
  localtunnel  >=1.9.0
  Depends on vulnerable versions of axios
  node_modules/localtunnel

2 high severity vulnerabilities

To address all issues (including breaking changes), run:
  npm audit fix --force

배포에 문제가 생겨서 2시간 정도 썻다. 이게 다른 사람들 패키지 호환성 문제나 여러가지 문제를 생각해야되고 상황에 따라 전체 삭제했다가 다시 빌드 해야되서 생각보다 복잡하다.
권호형 깃허브 리포 연동이 안되서 확인중이다.

SSM 으로 탄력적 IP를 안쓰고 SSH연결을 구현할 수 있다.

# SSH로 서버 접속
ssh ubuntu@3.38.25.129

# pm2 상태 확인
pm2 status

# 백엔드 로그 확인
pm2 logs Codeplanner_Backend

# 포트 확인 (5000번 포트가 열려있는지)
netstat -tlnp | grep :5000

# nginx 액세스 로그
sudo tail -f /var/log/nginx/access.log

# nginx 에러 로그  
sudo tail -f /var/log/nginx/error.log

# 로컬에서 백엔드 API 직접 호출
curl http://localhost:5000/api/github/connect/test

Devkty

모든걸 기록하며 성장하고 싶은 개발자입니다. 현재 크래프톤 정글 8기를 수료하고 구직활동 중입니다.