[JUnit Test] 1. Rest API 실무 배포와 테스트 자동화

✅ 1. CI (지속적 통합)란?

• Continuous Integration: 지속적인 코드 통합 및 자동 테스트

• 개발자들이 코드를 GitHub와 같은 원격 저장소에 푸시할 때마다
자동으로 빌드 및 테스트가 수행되어 안정성을 확보

• 보통 v1.0, v1.1처럼 버전 태깅을 통해 변경 이력을 관리함

• CI의 핵심 목표: "로컬에서만 잘 돌아가는 코드" → "모든 환경에서 안정적으로 작동하도록"

⚠️2. 로컬에서 잘 되더라도 서버에선 잘 안 될 수 있다?

로컬 환경 = 개인 개발 환경 (Windows, 내 JDK, 내 DB)

서버 환경 = 운영 환경 (리눅스, 다른 설정, 클라우드 IP 등)

• 로컬에서는 모든 게 내 기준으로 돌아감 → 운영 서버와는 환경이 다름

• 그래서 "로컬에선 되는데 서버에선 안 됨" 현상이 잦음

• 이를 해결하기 위해 필요한 것이 테스트 서버 + 배포 자동화 시스템

🌐 3. 서버 테스트를 위해 필요한 로컬 테스트 환경 , 배포 서버 환경 요소 (AWS 기준)

🖥️ 로컬 테스트 환경

• 운영체제: Windows

• JDK: 21버전

• DBMS: MySQL

• 버전관리: GitHub에 업로드

• CI (지속적 통합): main 브랜치 기준으로 로컬에서 문제없이 작동하는 것을 확인

• 문제점: 로컬에서 잘 돌아가는 코드가 서버에서는 잘 동작한다는 보장이 없음

☁️ 배포용 서버 환경 (AWS 기준)

운영 환경과 유사한 테스트를 위해 AWS 서버 사용

✅ 서버 환경 구성 조건

🛠️ 서버 작업 순서 (초기 세팅 기준)

1. 리눅스 OS 설치 (예: Ubuntu)

2. JDK 21 설치

3. GitHub에서 프로젝트 클론

4. ./gradlew build 로 빌드 실행

5. java -jar build/libs/xxx.jar 로 실행

🐧 4. 왜 서버 OS는 리눅스를 많이 쓸까?

따라서 서버에서는 CLI 기반의 리눅스가 압도적으로 사용됨

→ 필수: 리눅스 명령어에 대한 이해 필요 (cd, ls, mkdir, vim, ps, kill 등)

🔧 5. 서버에서 포스트맨 테스트? 너무 귀찮다!

• 로컬 포스트맨에서 서버 IP로 API 테스트 가능하지만:
• 매번 주소 복붙
• 헤더 입력
• 요청 본문 작성 → 시간 낭비 + 사람 실수 가능성

• 빌드시 테스트 코드 실행 포함

• 테스트 통과한 경우에만 배포 (CI 자동화 기준)

• → "빌드가 성공했다 = 서비스에 이상이 없다"는 신뢰 확보

🔄 6. 서버 업데이트하면 다운되는 이유와 해결 방법 3가지

① 작은 사이트라면?

• 업데이트 시 서버가 몇 분 꺼져도 괜찮음
→ 직접 jar 던지고 재시작하면 끝

② 테스트 서버 빌드 방식

• 테스트 서버에서 먼저 .jar 파일 생성
→ 운영 서버에 jar만 교체
→ 배포 속도 향상 + 장애 시간 최소화

③ 대형 서비스 (예: 쿠팡)

• 한 번이라도 서버가 멈추면 매출 손해

• 해결책: 로드 밸런서(Load Balancer) 사용

✅ 무중단 배포 (Zero Downtime Deploy)의 핵심 기술!

💬 추가로 물어본 질문 정리

🔹 포스트맨은 어떻게 서버를 테스트하나요?

• 로컬 포스트맨 → 서버의 공인 IP:포트로 요청
• 예: http://43.201.xx.xx:8080/api/products

• 내부 서버에서는 별도 보안 설정 필요할 수 있음 (포트 개방 등)

🔹 도커(Docker)는 뭐에요?

"CD 굽듯이 프로그램 실행 환경 전체를 패키징하는 기술"

• OS, JDK, DB, 프로젝트 jar 등을 하나의 이미지로 묶어 실행 가능

• 장점:
• 로컬과 서버 환경을 완벽하게 일치시킴
• 실행 환경 통제 가능 (예: Ubuntu + MySQL + JDK 21)
• “로컬에선 되는데 서버에선 안 돼요” 문제 해결

📦 전체 요약