개발 노트

[트러블슈팅] EC2 서버 멀쩡한데 서비스가 전부 안 될 때: SSL 인증서 만료였다

태기 — Tue, 13 Jan 2026 19:20:23 +0900

Spring Boot + Nginx + Let’s Encrypt 환경에서 실제로 겪은 장애 복구 기록

1. 갑자기 서비스가 모두 안됐다

외주 개발을 완료한지 6개월이 지난 지금, 고객사에서 연락이 왔다.

저희 홈페이지 관리자 로그인이 안돼요 ㅠㅠ
홈페이지도 안들어가져요...
확인 한번 부탁드립니다!

홈페이지 확인을 해보니 데이터가 undefined로 내려오고 있고, 관리자 페이지 로그인도 500에러로 뜨고 있었다.

처음엔 이렇게 생각했다.

DB가 죽었나?
서버가 내려갔나?
배포를 잘못했었나?

근데 이상한 점이 하나 있었다.

2. 서버에 들어가보니... 다 살아있다?

배포되어있는 AWS EC2에 접속해서 확인해봤다.

ps -ef | grep app.jar

백엔드 살아있음

sudo ss -lntp | grep java

포트도 정상

curl -i http://127.0.0.1:8080/actuator/health

헬스체크도 정상 (이건 구현안되어있으면 프론트에서 호출하는 컨트롤러 URL로 체크)

DB도, 서버도, 백엔드도 멀쩡한데 서비스는 안 된다?

여기서부터 "외부에서 들어오는 경로"를 의심했다.

3. 프론트에서 호출하는 서버 API 주소로 확인해봤다

서버에서 직접 호출해봤다.

curl -i https://(api URL)/actuator/health

하하... 범인을 찾았다.

나온 에러는 다음과 같다 (해결 완료 후 글 작성하는거라 기간 만료 에러 캡처 못함)

curl: (60) SSL certificate problem: certificate has expired 
More details here: https://curl.se/docs/sslcerts.html 

curl failed to verify the legitimacy of the server and therefore could not 
establish a secure connection to it. To learn more about this situation 
and how to fix it, please visit the webpage mentioned above.

4. 원인은 SSL 인증서 완료였다

일단 Nginx 설정 파일에서 인증서 위치 확인

sudo nginx -T | grep ssl_certificate

인증서 상태를 직접 확인해봤다

sudo openssl x509 -in /etc/letsencrypt/live/(api URL)/fullchain.pem -noout -dates

결과

이미 만료됨 (캡처는 새로 갱신한거임)

이 한 줄로 모든 증상이 설명됐다.

왜 이렇게 보였냐면

HTTPS 인증서 만료
브라우저에서 API 요청 자체 차단
프론트에서 데이터 전부 못 받음
배열이 비어서 undefined 에러 발생
결과적으로 “서비스 전체가 죽은 것처럼” 보임

백엔드는 사실 아무 잘못도 없었다.

여기서 잠깐

장애는 서버/DB 문제보다 인증서 만료가 더 무섭다
내부 테스트는 다 정상인데, 실제 사용자만 다 막히기 때문이다.

5. 해결 방법 : 인증서 갱신 + Nginx 재시작

이 서버는 Nginx + Let’s Encrypt(Certbot) 구조다.

1️⃣ 인증서 갱신

sudo certbot renew

성공 시 :

Congratulations, all renewals succeeded.

2️⃣ Nginx 재시작 (중요)

sudo systemctl reload nginx
# 또는
sudo systemctl restart nginx

3️⃣ 다시 확인

curl -i https://(api URL)/actuator/health

프론트 새로고침 → 모든 데이터 정상 복구

6. 재발 방지: 자동 갱신 설정 꼭 확인하자

이 장애의 진짜 원인은

Certbot 자동 갱신이 안 되어 있었던 것

타이머 확인

sudo systemctl list-timers | grep certbot

없다면 바로 추가 :

sudo systemctl enable certbot-renew.timer
sudo systemctl start certbot-renew.timer

이제 90일마다 자동 갱신된다.

7. 정리하면서 느낀점

이번 장애에서 제일 무서웠던 점은 이거였다.

서버 정상
DB 정상
로그에 에러 없음
헬스체크 OK

그런데 서비스는 완전히 죽어 보인다.

그래서 앞으로 이런 증상이 나오면 나는 무조건 이 순서로 본다.

서버 프로세스
내부 헬스체크
외부 HTTPS 호출
SSL 인증서 만료 여부

8. 같은 환경이라면 꼭 체크해보자

EC2 + Spring Boot
Nginx 리버스 프록시
Let’s Encrypt 사용 중
“배포 안 했는데 갑자기 서비스 장애”

이 조합이면 인증서 만료부터 의심하는 게 정답이다.

마무리

이번 건은 “서버가 죽은 게 아니라, 입구가 닫혀 있었던 상황” 이었다.

혹시 나처럼 서버는 멀쩡한데 서비스가 전부 안 될 때 이 글이 도움이 됐으면 좋겠다.

[Java] 왜 Java String은 조심해서 써야 할까 - JVM과 성능 관점에서

태기 — Fri, 9 Jan 2026 22:58:02 +0900

예전에 개발 팀장으로 있을 때 인턴으로 들어와 함께 일했던 동생과 오랜만에 술자리를 가졌다.
근황 얘기를 하면서 내가 이직 준비중이라고 하니, 동생이 본인 회사 면접 준비 해보라면서 면접에 대한 얘기를 했다.
본인 회사에서 주로 묻는 질문중의 예시로 한가지 질문을 해 주었다.

Java에서 String을 사용할 때 왜 조심해야 한다고 생각하나요?

순간 머릿속이 복잡해졌다.

자바 개발만 5년째 하고 있지만, 막상 그 질문을 정리해서 설명하려니 선뜻 말이 나오지 않았다.

"String은 불변 객체라서 연산할 때마다 객체가 새로 생성되고, 그게 쌓이면 GC에 부담을 준다"

이 정도 설명밖에 하지 못했다.

대답을 하고 나서도 마음 한켠이 찝찝했다.

틀린 말은 아니지만, 어딘가 부족하다는 느낌이 계속 남았다.

String이 왜 실무와 면접에서 이렇게 자주 언급되는지,

정말로 조심해야 할 포인트가 GC 하나뿐인지 스스로 확신이 없었기 때문이다.

그래서 이 글에서는, JVM 관점에서 Java String을 사용할 때 왜 '조심해야 한다'고 말하는지를 다시 정리해보려고 한다.

막연한 성능 이슈 이야기가 아니라,

객체 생성, 메모리 사용, 문자열 결합, 그리고 실무에서 자주 마주치는 패턴들을 중심으로 차근차근 짚어볼 예정이다.

✅ String은 왜 불변(immutable)인가?

Java에서 String이 불변 객체라는 사실은 대부분 알고 있다.

한 번 생성된 문자열은 내용을 바꿀 수 없고, 변경이 필요한 경우에는 항상 새로운 String 객체가 만들어진다.

이 설계는 단순한 구현 선택이 아니라, Java 언어와 JVM 전반에 깊게 연결된 결정이다.

가장 먼저 떠올릴 수 있는 이유는 안정성이다.

String은 파일 경로, 클래스 이름, 환경 변수, 네트워크 요청, SQL, 로그 메세지 등 시스템 전반에서 광범위하게 사용된다.

만약 문자열이 가변 객체였다면, 한 곳에서 수정된 문자열이 의도치 않게 다른 로직에 영향을 주는 일이 발생할 수 있다.

특히 여러 스레드가 같은 문자열을 참조하는 환경에서는 문자열이 불변이라는 사실 자체가 강력한 안전장치가 된다.

또 하나의 중요한 이유는 성능 최적화와 캐싱 전략이다.

Java에는 문자열 리터럴을 재사용하기 위한 String Pool이 존재한다.

"hello" 같은 리터럴은 매번 새로운 객체를 만드는 대신, 이미 존재하는 동일한 문자열을 재사용한다.

이 방식이 가능한 이유 역시 String이 불변이기 때문이다.

마지막으로, String은 HashMap의 key처럼 hash 기반 컬렉션에서 자주 사용된다.

불변이기 때문에 hash 값이 변하지 않고, 컬렉션의 동작이 안정적으로 유지된다.

결국 String의 불변성은 스레드 안정성, 메모리 재사용, 컬렉션 안정성을 동시에 만족시키기 위한 선택이다.

다만 이 선택의 대가로, 문자열을 변경하는 모든 순간마다 새로운 객체가 생성된다는 점을 반드시 인지하고 있어야 한다.

✅ String 연산은 JVM 메모리에서 어떻게 동작할까?

1️⃣ JVM 메모리 구조부터 짚고 넘어가자

Java 애플리케이션이 실행되면, JVM은 메모리를 역할별로 나누어 관리한다.

String과 직접적으로 관련 있는 영역은 크게 Stack과 Heap이다.

먼저 Stack 영역에는 메서드 호출 정보와 지역 변수, 그리고 객체를 가리키는 참조(reference) 가 저장된다.
여기에는 실제 객체 데이터가 아니라, “이 객체는 Heap의 어디에 있다”는 주소 정보만 들어간다.

반면 Heap 영역은 실제 객체 인스턴스가 생성되는 공간이다.
new String()이든, 문자열 연산의 결과든, String 객체 자체는 모두 Heap에 생성된다.

Heap 내부는 다시:

Young Generation (새로 생성된 객체)
Old Generation (오래 살아남은 객체)

으로 나뉘는데,
문자열 연산에서 문제가 되는 객체들은 대부분 Young 영역에 대량으로 생성됐다가 빠르게 사라진다.

2️⃣ String 객체는 JVM 메모리 어디에 생성될까?

String은 조금 특이하다.

모든 String 객체는 Heap에 생성되지만,

그 중 일부는 String Pool이라는 별도의 관리 영역에서 재사용된다.

예를 들어:

"Cat" 같은 문자열 리터럴 → String Pool
new String("Cat") → 일반 Heap 객체

String Pool 역시 Heap의 일부이지만,
“공유 가능한 문자열만 모아둔 공간” 이라는 점에서 의미가 있다.

중요한 건 이 둘 모두 불변 객체라는 사실이다.
즉, 한 번 생성된 문자열은 수정되지 않고,
변경이 필요한 순간마다 새로운 String 객체가 Heap에 만들어진다.

3️⃣ 이제 문자열 연산을 JVM 흐름으로 보자

다음과 같은 코드가 있다고 가정해보자.

String result = "a" + "b";

이 코드는 단순해 보이지만, JVM 입장에서는 다음과 같은 과정을 거친다.

먼저 컴파일러는 문자열 결합을 내부적으로 StringBuilder 기반 코드로 변환한다.

그리고 실행 시점에서는:

StringBuilder 객체가 Heap에 생성되고
"a", "b"가 내부 버퍼로 복사된 뒤
toString()이 호출되면서 새로운 String 객체가 Heap에 생성된다.

즉, 문자열 하나를 만들기 위해:

임시 객체(StringBuilder)
내부 배열 복사
최종 String 객체 생성

이라는 단계를 거친다.

❗️반복문에서 문제가 커지는 이유

이 연산이 반복문 안으로 들어가는 순간, 상황이 달라진다.

문자열을 누적하는 구조에서는:

매 반복마다 새로운 String 객체가 생성되고
이전 String은 더 이상 참조되지 않아 garbege가 된다
이 객체들은 대부분 Young Generation에 쌓였다가 빠르게 수거된다

결과적으로 JVM은:

객체 생성 비용
메모리 복사 비용
잦은 Young GC

를 계속 감당하게 된다.

그래서 "String을 많이 쓰면 GC가 늘어난다"는 말의 정확한 의미는,

String 연산이 Heap에 단명 객체를 대량으로 만들어내는 구조를 쉽게 만들기 때문이다.

✅ String vs StringBuilder - 무엇이 어떻게 다를까?

앞에서 살펴본 것처럼, String 연산에서 문제가 되는 지점은 불변 객체라는 특성 때문에 발생하는 반복적인 객체 생성이다.

이 문제를 해결하기 위해 Java가 제공하는 대표적인 도구가 바로 StringBuilder다.

StringBuilder는 String과 달리 가변 객체(mutable)다.

한 번 생성된 이후에도 내부 상태를 변경할 수 있고,

문자열을 누적하는 과정에서 새 객체를 계속 만들지 않는다는 점이 가장 큰 차이점이다.

1️⃣ StringBuilder는 JVM 메모리에서 어떻게 동작할까?

StringBuilder는 내부적으로 문자 배열(char[] 또는 byte[])을 버퍼로 유지한다.

문자열을 추가할 때마다 새로운 객체를 만드는 대신,
이 내부 버퍼에 내용을 계속 덧붙이는 방식으로 동작한다.

예를 들어, 문자열을 누적하는 코드가 있다고 가정해보자.

StringBuilder 객체는 단 한 번만 Heap에 생성된다
append() 호출 시, 내부 버퍼에 문자열이 추가된다
버퍼가 부족해질 경우에만, 더 큰 배열을 새로 만들어 복사한다
모든 작업이 끝난 뒤, toString()을 호출하면
- 그 시점에 한 번만 새로운 String 객체가 생성된다

즉, 문자열을 100번 이어 붙이더라도
중간 과정에서는 String 객체가 계속 생기지 않는다.

이 점이 String 연산과 결정적으로 다른 부분이다.

2️⃣ 코드로 이해하기

String을 사용한 문자열 누적

String sampleString = "Welcome";

sampleString = sampleString + " everyone";
sampleString = sampleString + ",";
sampleString = sampleString + " how are you?";

JVM에서 실제로 벌어지는 일

이 코드는 겉보기엔 sampleString 하나만 계속 바뀌는 것처럼 보이지만, 실제로 매 줄마다 새로운 String 객체가 생성된다.

개념적으로는 이런 식이다:

String s1 = "Welcome";
String s2 = s1 + " everyone";			// "Welcome everyone"
String s3 = s2 + ",";					// "Welcome everyone,"
String s4 = s3 + " how are you?";		// "Welcome everyone, how are you?"

s1, s2, s3, s4 → 모두 다른 String 객체
변수 sampleString은 마지막 s4만 참조
s1, s2, s3는 참조가 끊어져 GC 대상

StringBuilder를 사용한 문자열 누적

StringBuilder sampleString = new StringBuilder();

sampleString.append("Welcome");
sampleString.append(" everyone");
sampleString.append(",");
sampleString.append(" how are you?");

String result = sampleString.toString();

JVM 관점에서의 차이

StringBuilder 객체는 한 번만 생성
내부 버퍼에 문자열이 계속 추가됨
중간 결과를 위한 String 객체는 생성되지 않음
toString() 호출 시점에서만 최종 String 객체 1개 생성

3️⃣ 그래서 언제 무엇을 써야 할까?

정리하면 기준은 명확하다.

문자열 결합이 한두 번이고, 가독성이 중요한 코드
→ String과 + 연산을 사용해도 문제 없다
반복문 안에서 문자열을 누적하는 구조
→ 반드시 StringBuilder를 사용하는 것이 좋다
멀티스레드 환경에서 하나의 문자열을 여러 스레드가 수정해야 하는 경우
→ StringBuffer 또는 명시적인 동기화 고려

대부분의 문자열 관련 성능 이슈는 String 자체의 문제라기보다,
누적 문자열 처리에 맞지 않는 도구를 사용한 결과인 경우가 많다.

여기까지 정리하면

이제 질문에 이렇게 답할 수 있다.

Java에서 String을 사용할 때 조심해야 하는 이유는,
불변 객체 특성상 문자열 연산 과정에서 단명 객체가 대량으로 생성되고
반복되는 경우 GC 부담과 성능 저하로 이어질 수 있기 때문이다.

마무리

String은 Java에서 가장 자주 사용되는 클래스 중 하나지만,
그만큼 아무 생각 없이 사용하기 쉬운 객체이기도 하다.

이번 글에서는 “String은 불변이라서 GC 부담이 된다”라는 한 줄 설명 뒤에 숨겨진
JVM 메모리 구조, 객체 생성 흐름, 그리고 문자열 연산의 실제 동작을 차근차근 정리해보았다.

중요한 건 String을 피하자는 게 아니라, 어떤 상황에서 어떤 비용이 발생하는지 알고 선택하는 것이다.
특히 반복되는 문자열 누적과 같은 패턴에서는 String과 StringBuilder의 차이가 곧 성능 차이로 이어진다.

다음 글에서는 “String + 연산도 내부적으로 StringBuilder를 쓰는데,
그럼 우리는 왜 여전히 문자열 연산을 조심해야 할까?”라는 질문을 중심으로 컴파일러 최적화의 한계와 반복문에서 성능 차이가 발생하는 이유를 이어서 정리해보려고 한다.

[보안패치] Next.js · React 보안 패치 적용기 (CVE-2025-55182) - 운영 중인 서비스에 React RSC 취약점 패치하기

태기 — Tue, 9 Dec 2025 00:04:13 +0900

최근 외부 파트너사에서 “React Server Components(RSC) 취약점(CVE-2025-55182)” 관련 보안 점검 요청을 받았다.

문제는… 내가 개발했던 프로젝트가 Next.js App Router 기반이라는 점.
즉 구조적으로 취약 버전의 영향을 받을 가능성이 있어 보였다.

그래도 운영 중인 서비스라 보안 패치는 바로 대응해야 했다.

이번 글에서는 React 19 / Next.js 15 환경에서 보안 패치를 적용하며 겪은 과정들을 기록해본다.

1. 상황 파악 — 어떤 취약점인가?

React 19 계열의 RSC 관련 패키지에서 원격 코드 실행(RCE) 취약점이 발견되었다는 내용이었다.
취약 버전은 아래와 같고, 보안 패치는 해당 라인별로 발표된 상태.

취약 버전

react-server-dom-webpack: 19.0 / 19.1.0 / 19.1.1 / 19.2.0
Next.js 역시 App Router + RSC 기반이라 영향 가능성이 존재

안전 버전

React 패치: 19.1.2
Next.js 패치: 15.2.6

문제는 우리 프로젝트가 딱 아래 버전을 쓰고 있었다.

Next.js 15.2.4  
React 19.1.0

그리고 App Router 기반이기 때문에 내부적으로 RSC 기능을 기본 사용한다. ("use server"를 사용하지 않아도 구조적으로 연결됨)

즉, 패치가 필요한 상태.

2. 프로젝트 환경 확인

package.json을 보면 다음과 같이 되어 있었다.

"dependencies": {
  "next": "^15.2.4",
  "react": "^19.1.0",
  "react-dom": "^19.1.0",
  ...
}

직접 use server를 사용하지는 않지만,

Next.js App Router는 기본적으로 RSC 기반이기 때문에 패치가 필요하다는 결론이다.

3. 대응 전략 수집

요약하면 3단계로 정리할 수 있었다.

React/Next.js 버전을 보안 패치 버전으로 올린다.
전체 의존성 재설치 및 빌드 테스트
프로덕션 모드 테스트 → Vercel 자동 배포

이 과정에서 주의해야 할 게 하나 있었는데,
npm audit fix --force를 누르면 메이저 버전까지 강제로 올려버려서
App Router + React 19 환경이 깨질 수 있다.
그래서 절대 강제 업데이트는 하지 않는 방향으로 대응했다.

4. React / Next.js 보안 패치 적용

작업 브랜치를 하나 새로 만들어서 적용했다.

git checkout -b chore/security-react-rsc-patch

그리고 패치 버전으로 업데이트:

npm install next@15.2.6 react@19.1.2 react-dom@19.1.2 --save

eslint-config-next도 버전에 맞춰 업데이트:

npm install eslint-config-next@15.2.6 --save-dev

package.json 수정 후 자연스러운 현상

package-lock.json도 자동으로 변한다.
npm install을 하면 의존성 트리가 재정리되기 때문에 package.json + package-lock.json 둘 다 커밋하는 게 맞다.

5. 빌드 테스트

업데이트 후 바로 빌드를 돌렸다.

npm run build

에러 없이 빌드 성공!
이 단계에서 에러가 나면 대체로 아래 문제들이다:

react-dom mismatched version
ESLint 호환성 문제
Server Components 경로 mismatching
특정 UI 라이브러리의 React 19 대응 문제

다행히 우리 프로젝트에서는 깨지는 부분 없이 통과했다.

6. 프로덕션 모드 테스트

빌드 성공 후, 실제 프로덕션 모드 실행:

npm start

이제 http://localhost:3000 에 접속해서 다음 페이지들을 확인했다.

메인 페이지
스크롤 애니메이션 정상
Swiper 슬라이더 정상
관리자 페이지 진입 정상
콘솔 에러 없음

서버 액션을 사용하지 않는 구조라 더 단순했고, 덕분에 특별한 문제 없이 정상적으로 동작했다.

7. 배포 — main merge → Vercel 자동 배포

이제 작업 브랜치를 main에 PR → merge만 하면 끝.

Vercel은 main 브랜치 변경을 감지하면 자동으로 CI/CD가 실행되어 배포된다.
별도 서버 재부팅이나 작업은 필요 없다.

배포 후 실제 사이트를 확인해봤고, 화면 전환·이미지·라우팅 모두 정상.

8. 조치 완료 후 회신

파트너사에는 아래 내용을 전달했다.

React / Next.js 보안 패치 완료
RSC 취약점 영향 여부 검토
use server 미사용 확인
프로덕션 테스트 문제 없음

요청받았던 1) 버전 확인, 2) Server Actions 확인, 3) 보안 패치 적용
→ 모두 완벽히 대응 완료.

9. 회고

운영 중인 프레임워크를 업데이트하는 건 항상 부담된다.
특히 React 19 / Next.js 15은 아직 변화가 많은 시기라 조심스러웠다.

그럼에도 이번 경험을 통해:

버전 명확히 고정해서 패치하는 습관
main 브랜치 자동 배포 구조의 중요성
App Router + RSC 구조에 대한 이해
보안 공지를 항상 체크해야 한다는 점

을 다시 한 번 느꼈다.

[AWS] Route53으로 도메인 사서 EC2에 연결 방법 기록 (DNS 설정하면서 헷갈렸던 것들)

태기 — Fri, 14 Nov 2025 21:17:32 +0900

EC2 서버 띄워놓고 Public IP로만 접근하다가
이제 도메인을 붙이기 위해 AWS Route53을 만져봤다.

Route53으로 도메인 등록하고 EC2에 연결하는 과정에서
A 레코드, CNAME, 네임서버 설정이 생각보다 헷갈려서
나중에 다시 보려고 정리해둔다.

이 글은 AWS Route53으로 도메인을 구매하고
EC2에 연결하면서 실제로 했던 순서 위주로 적은 기록이다.

✅ Route53이란?

한 줄 요약 : 도메인을 발급하고 관리해주는 서비스이다.

www.naver.com, daum.net, youtube.com처럼 문자 형태로 표현된 인터넷 주소를 도메인(Domain)이라고 한다.

AWS의 Route 53은 이러한 도메인을 구매하고 관리할 수 있는 서비스이며, 더 정확히는 DNS(Domain Name System) 서비스에 해당한다.

이제 DNS가 뭔지 간단히 알아보자.

✅ DNS(Domain Name System)란?

인터넷 초창기에는 특정 컴퓨터와 통신하기 위해 123.123.123.123 같은 IP 주소를 직접 입력해야 했다.

IP는 컴퓨터를 식별하는 핵심 주소지만, 숫자로만 이루어져 있어 사람이 기억하거나 관리하기에는 비효율적이었다.

사용자 입장에서는 직관적인 이름을 사용하고 싶지만, 컴퓨터는 기본적으로 숫자 기반의 값을 처리하는 데 최적화되어 있다.
따라서 단순히 IP 주소를 문자로 대체하는 방식만으로는 문제를 해결하기 어려웠다.

이 문제를 해결하기 위해 문자로 된 이름을 숫자로 이루어진 IP 주소로 변환해주는 시스템, 즉 하나의 중간 서버가 필요해졌다. 이렇게 해서 등장한 것이 바로 DNS(Domain Name System)이다.

DNS는 사용자가 입력한 도메인 이름을 내부적으로 IP 주소로 변환해주는 역할을 수행하며, 이를 통해 우리는 더 이상 복잡한 IP를 외울 필요 없이, 도메인만으로 원하는 서비스에 접근할 수 있게 됐다.

출처 : https://gcore.com/learning/dns-servers-what-they-are-and-how-they-work/

✅ 도메인 연결

1. 도메인 구매

Route53 > 대시보드 > 도메인 등록 > 도메인 검색 > 선택 > 결제 진행 > 요금 확인 > 연락처 정보 입력

Tip. 도메인에서 .link 가 가장 저렴한 것 같다.

주의) 다른 건 몰라도 이메일은 정확히 입력해야 한다. 10~20분 있다가 등록한 이메일로 메일이 날라온다. 이 메일을 확인해야만 정상적으로 도메인이 등록된다.

이렇게하면 Route53에서 등록된 도메인을 확인 할 수 있다.

출처 : jscode 강의 영상

2. EC2에 연결하기

1. Route 53의 호스팅 영역 메뉴에 들어가서 레코드 생성 버튼 누르기

출처 : jscode 강의 영상

2. 레코드 생성

출처 : jscode 강의 영상

위와 같이 설정할 경우 jscode-edu.link의 도메인으로 접속했을 때 52.79.34.240의 IP 주소로 연결시켜준다는 뜻이다. 레코드 유형은 아래에서 자세히 설명하겠다.

만약 api.jscode-edu.link의 도메인으로 접속했을 때 52.79.34.240의 IP 주소로 연결시켜주고 싶다면 레코드 이름의 빈칸에 api를 적으면 된다. 이와 같이 하나의 도메인만 구매하더라도 여러 개의 서브 도메인을 사용할 수 있다. (jscode-edu.link가 주 도메인이고, ___.jscode-edu.link 형태의 도메인이 서브 도메인이다.)

3. 접속 확인

A 레코드로 추가하고나서 도메인이 적용되는데 5~10분 정도 걸린다. 조금 기다렸다가 도메인에 접속해보자.

출처 : jscode 강의 영상

A 레코드

- 도메인을 특정 IPv4 주소에 연결시키고 싶을 때 사용하는 레코드 유형이다.

CNAME 레코드

- 도메인을 특정 도메인 주소에 연결시키고 싶을 때 사용하는 레코드 유형이다.

만약 CNAME 레코드의 값으로 www.naver.com을 적었다고 가정하자. 그러면 해당 도메인으로 접속했을 때, www.naver.com으로 연결되어 이동한다.

✅ 무료 도메인 구매해서 연결하기

https://xn--220b31d95hq8o.xn--3e0b707e/

내도메인.한국 - 한글 무료 도메인 등록센터

한글 무료 도메인 내도메인.한국, 웹포워딩, DNS 등 무료 도메인 기능 제공

xn--220b31d95hq8o.xn--3e0b707e

https://cloud-information.tistory.com/11

무료 도메인 서비스 내도메인.한국 사용 방법

내도메인.한국은 무료 도메인을 사용할 수 도록 제공해 주는 서비스입니다. 나만의 도메인을 무료로 만들어 네이버 블로그, 티스토리 등 다양한 곳에 연결하여 사용할 수 있으며, 무료 도메인을

cloud-information.tistory.com

주의) 실제 운영할 서버에는 무료 도메인을 사용하지 말자. 무료 도메인은 생각보다 불안정하다. 중간에 도메인을 통한 접속이 끊기기도 한다. 즉, 서비스가 중단되는 경우가 발생할 수 있다는 뜻이다.

[AWS] Spring Boot 서버를 EC2에 배포하기

태기 — Tue, 11 Nov 2025 23:05:08 +0900

AWS EC2(Elastic Compute Cloud) 인스턴스에 Spring Boot 애플리케이션을 직접 배포해봤다.

EC2 환경에서 JDK 설치부터 애플리케이션 실행까지 순서대로 정리해보았다.

이 글을 보면 EC2에서 Spring Boot 서버를 띄우는 전체 흐름을 볼 수 있다.

✅ Ubuntu 환경에 JDK 설치

spring boot를 배포하려면 java가 설치되어야한다. EC2 인스턴스에 접속해서 jdk를 설치하자.

각자 필요한 jdk를 설치하면 되는데, 나는 jdk 17 버전 설치를 할 것이다.

# root 권한 변경
sudo su

# jdk17 버전 설치 (그대로 2줄 복붙하면 됨)
sudo apt update && /
sudo apt install openjdk-17-jdk -y

✅ jdk가 잘 설치됐는지 확인

java -version

✅ github 프로젝트 클론

git clone https://github.com/JSCODE-EDU/ec2-spring-boot-sample.git
cd ec2-spring-boot-sample

본인 프로젝트 소스코드를 클론하면 된다.

나는 강의에서 제공해준 예제 프로젝트를 클론받아서 진행하였다.

✅ application.yml 파일 생성

application.yml 와 같은 민감한 정보가 포함된 파일은 Git으로 버전 관리를 하지 않는게 일반적이다. 따라서

application.yml 파일은 별도로 EC2 인스턴스에 올려주어야 한다. 하지만 application.yml 파일을 EC2 인스턴스에 올리는 작업보다는, application.yml 파일을 직접 만드는 게 훨씬 간단하다.

src/main/resources/application.yml

# 경로 접속
cd src/main/resources

# application.yml 파일 생성 및 편집
vi application.yml

# 아래 내용 추가
server:
  port: 80

:wq

✅ 서버 실행

# 프로젝트 경로로 이동
cd ../../

# 기존 빌드된 파일을 삭제하고 새롭게 JAR로 빌드
./gradlew clean build
cd build/libs
sudo java -jar ec2-spring-boot-sample-0.0.1-SNAPSHOT.jar

# 참고 - 백그라운드에서 실행시키기
sudo nohup java -jar ec2-spring-boot-sample-0.0.1-SNAPSHOT.jar &

libs 폴더 들어가면 저렇게 .jar파일이 2개가 생성되어 있고, plain이 아닌 것을 실행시키면 된다.

이렇게 하고 우리가 이전에 할당받았던 탄력적 IP를 접속해보면 다음과 같이 뜬다.

✅ 비용 나가지 않게 깔끔하게 EC2 종료

인스턴스와 탄력적 IP만 삭제하면 된다.

1. 인스턴스 종료(삭제)

2. 탄력적 IP 삭제(릴리즈)

[AWS] EC2 인스턴스 탄력적 IP(Elastic IP) 설정

태기 — Tue, 11 Nov 2025 21:27:28 +0900

AWS EC2 인스턴스는 기본 할당된 퍼블릭 IP가 인스턴스를 중지했다 다시 시작하면 바뀐다.

그래서 중지/재시작해도 변하지 않는 고정 IP가 필요해서 Elastic IP(탄력적 IP)를 설정해봤다.

이 글은 EC2 인스턴스에 Elastic IP를 할당하고 연결하는 순서를 기록한다.

✅ 탄력적 IP가 왜 필요할까?

EC2 인스턴스를 생성하면 IP를 할당받는다. 하지만 이렇게 할당받은 IP는 임시적인 IP이다.

위와 같이 EC2 인스턴스를 잠깐 중지시켰다가 다시 실행시켜보면 IP가 바뀌어있다.

EC2 인스턴스를 중지시켰다가 다시 실행시킬 때마다 IP가 바뀌면 굉장히 불편하다.

그래서 중지시켰다가 다시 실행시켜도 바뀌지 않는 고정 IP를 할당받아야 한다.

그게 바로 탄력적 IP이다.

✅ 탄력적 IP 설정 방법

화면 좌측에 네트워크 및 보안 그룹에 '탄력적 IP'를 선택한 후 우측 상단에 '탄력적 IP 주소 할당' 을 클릭한다.

옵션 그대로 하고 할당을 받는다.

그럼 이렇게 할당된 주소가 나오고 우측상단에 작업을 눌러 탄력적 IP 주소 연결을 클릭한다.

그러면 우리가 생성했던 인스턴스를 선택하여 연결을 한다.

인스턴스에서 다시 확인해보면 할당받은 IP가 이렇게 설정된 것을 확인할 수 있다.
좀더 확실하게 확인하기위해 처음처럼 인스턴스를 중지했다가 다시 시작을 해도 IP가 그대로일 것이다.

[AWS] EC2 인스턴스 정보 확인 및 SSH 접속

태기 — Tue, 11 Nov 2025 03:04:35 +0900

AWS EC2 인스턴스를 만들고 나서, 실제 서버에 어떻게 접속하는지 헷갈려서 정리해둔다.

이 글은 EC2 인스턴스의 퍼블릭 IP/상태 같은 기본 정보를 보고,
SSH로 접속하는 과정까지 순서대로 적은 기록이다.

✅ 생성된 인스턴스 정보 해석하기

1. 세부 정보

세부 정보에서 눈여겨 봐야 할 부분은 2가지 밖에 없다. 퍼블릭 IPv4 주소와 인스턴스 상태이다.

- 퍼블릭 IPv4 주소 : EC2 인스턴스가 생성되면서 부여받은 IP 주소이다. EC2 인스턴스에 접근하려면 이 IP 주소로 접근하면 된다.

- 인스턴스 상태 : 말그대로 EC2 인스턴스가 실행 중이라는 뜻은 컴퓨터가 켜져있다는 뜻이다.

1. 인스턴스 중지 : 컴퓨터를 종료 (전원끄기)
2. 인스턴스 시작 : 컴퓨터를 실행 (전원켜기)
3. 인스턴스 재부팅 : 컴퓨터 재부팅
4. 인스턴스 최대 절전 모드 : 컴퓨터 절전 모드
5. 인스턴스 종료(삭제) : 인스턴스 삭제 - 컴퓨터를 아예 삭제시킨다는 걸 의미한다.
>> EC2 인스턴스를 한 번 종료하면 도중에 취소할 수 없으니 조심해야 한다.

2. 보안 (보안 그룹)

인스턴스 생성 시 설정한 보안 그룹에 대한 정보가 나온다.

3. 네트워킹

일단 네트워킹에서는 그냥 퍼블릭 IPv4 주소만 확인하면 된다.

4. 스토리지

유형은 EBS이고 볼륨 크기가 우리가 설정한 30GB라는 것을 확인한다.

5. 모니터링

EC2 인스턴스에 관련한 여러가지 정보를 볼 수 있는 창이다. AWS를 처음 입문할 때는 자주 볼 일이 없는 창이지만, 나중에 실제 서버를 운영할 때는 자주 보게되는 창이다. EC2 인스턴스가 정상적으로 작동하고 있는 지, EC2 인스턴스의 성능을 향상시켜주어야 하는 건 아닌 지 아래 지표를 통해 파악할 수 있다.

✅ 인스턴스 접속하기

연결하면 이렇게 ubuntu가 설치된 컴퓨터에 접속하게 되고, pwd 명령어를 입력해서 현재 위치를 확인해보았다.

[AWS] EC2 인스턴스 생성 및 기본 세팅

태기 — Tue, 11 Nov 2025 02:28:20 +0900

백엔드 개발을 하고나면 배포를 해야한다.

대표적인 서비스인 AWS(Amazon Web Server)를 사용하여 배포를 해보자.

EC2 설정 과정에서 리전, 인스턴스 유형, 키 페어, 보안 그룹 같은 것들이
자주 안하다 보니까 헷갈려서 나중에 다시 보려고 정리해둔다.

이 글은 AWS EC2 인스턴스를 생성하고 기본 세팅까지 진행한 실제 순서 기록이다.

✅ EC2(Elastic Compute Cloud)

한 줄 요약 : 컴퓨터를 빌려서 원격으로 접속해 사용하는 서비스

EC2를 쉽게 얘기하면 하나의 컴퓨터를 의미한다.

서버를 배포하기 위해서는 컴퓨터가 필요하다. 내가 가진 컴퓨터에서 서버를 배포해 다른 사용자들이 인터넷을 통해 접근할 수 있게 만들 수도 있다. 하지만 내 컴퓨터로 서버를 배포하면 24시간 동안 컴퓨터를 켜놔야 한다. 그리고 인터넷을 통해 내 컴퓨터에 접근할 수 있게 만들다보니 보안적으로도 위험할 수도 있다.

이러한 불편함 때문에 내가 가지고 있는 컴퓨터를 사용하지 않고, AWS EC2라는 컴퓨터를 빌려서 사용하는 것이다.

현업에서도 실제 서버를 배포할 때 AWS EC2를 아주 많이 사용한다. 백엔드 서버를 배포해야 할 때면 EC2에 서버를 배포해서 사용한다.

✅ 리전(Region)

리전(Region)이란 인프라를 지리적으로 나누어 배포한 각각의 데이터 센터를 의미한다.

EC2를 통해 빌려서 쓸 수 있는 컴퓨터들이 전 세계적으로 다양하게 분포해있다. 이렇게 컴퓨터들이 위치한 위치를 보고 AWS에서는 리전(Region)이라고 한다.

1. 리전(Region)의 특징

각 Region은 고유의 이름을 가지고 있다.

ex) us-east-1 , ap-northeast-2

2. 리전(Region)을 선택하는 기준

사람들이 애플리케이션을 사용할 때는 네트워크를 통해 통신하게 된다. 이 때, 사용자의 위치와 애플리케이션을 실행시키고 있는 컴퓨터와 위치가 멀면 멀수록 속도가 느려진다. 따라서 애플리케이션의 주된 사용자들의 위치와 지리적으로 가까운 리전(Region)을 선택하는 것이 유리하다.

예를 들어, 한국 유저들이 주로 사용하는 서비스를 만들거라면 리전(Region)을 아시아 태평양(서울)로 선택하면 된다.

리전(Region)마다 EC2가 따로따로 관리가 되고 있으니 이 점 유의하자.

✅ EC2 세팅하기 - 인스턴스 생성

1. 이름 및 태그

EC2의 이름을 설정하는 곳이다. 이름을 지을 때는 이 컴퓨터가 어떤 역할을 하는 지 알아볼 수 있게 작성한다.

보통 서비스명-server 이렇게 작성한다.

ex) instagram-server

2. Application and OS Images (Amazon Machine Image)

Ubuntu 24.04 LTS 선택

OS를 선택하는 단계이다. Windows나 Mac OS는 생각보다 용량도 많이 차지하고 성능도 많이 잡아먹는다. 그래서 서버를 배포할 컴퓨터의 OS는 훨씬 가벼운 Ubuntu를 많이 사용한다.

3. 인스턴스 유형

우선 인스턴스라는 뜻부터 정리하고 가자. 인스턴스란, AWS EC2에서 빌리는 컴퓨터 1대를 의미한다.

그럼 인스턴스 유형은 무슨 뜻일까? 컴퓨터 사양을 의미한다. 컴퓨터 사양이 좋으면 좋을수록 많은 수의 요청을 처리할 수 있고, 무거운 서버나 프로그램을 돌릴 수 있다.

프리 티어에 해당하는 t3.micro를 사용할 것이다.

4. 키 페어(로그인)

키 페어(Key Pair)는 무슨 뜻일까?

EC2 컴퓨터에 접근할 때 사용하는 비밀번호라고 생각하면 된다. 말 그대로 열쇠(Key, 키)의 역할을 한다.

키 페어 이름 : instagram-server-key-pair

- 키 페어 이름은 어떤 EC2에 접근하기 위한 키 페어였는 지 알아볼 수 있게 지정하면 좋다.

- RSA와 .pem을 선택한 후에 키 페어를 생성하면 된다. ED25519가 뭔지, .ppk가 뭔지는 몰라도 된다. 중요하지 않다.

- 키 페어를 생성하면 파일이 하나 다운받아질텐데, 그 파일은 잃어버리면 안 되니 잘 보관해놔야 한다.

- 참고) 아래에서는 키 페어를 활용해서 EC2에 접근하지 않고, 더 편한 방법으로 접근할 예정이다.

5. 네트워크 설정

외부에서 EC2로 접근할 포트는 22번 포트와 80번 포트라고 생각해서 이 2가지에 대해 인바운드 보안 그룹 규칙을 추가했다. 왜냐하면 22번 포트는 우리가 EC2에 원격 접속할 때 사용하는 포트이고, 80번 포트에는 백엔드 서버를 띄울 예정이기 때문이다. 그리고 어떤 IP에서든 전부 접근할 수 있게 만들기 위해 소스 유형은 위치 무관으로 설정했다.

네트워크 설정 칸을 보면 VPC와 Security Groups(보안 그룹)가 보인다. 여기서 VPC라는 개념은 AWS를 입문하는 입장에서는 크게 중요하지 않으니 넘어가자. 나중에 AWS에 어느 정도 익숙해졌을 때 VPC를 학습하도록 하자. VPC를 몰라도 서버를 배포하는 데 아무 문제가 없다.

하지만 Security Groups(보안 그룹)은 서버를 배포할 때 중요한 개념이므로 자세히 알아보자.

[보안 그룹]

보안 그룹(Security Group)이란 AWS 클라우드에서의 네트워크 보안을 의미한다.

EC2 인스턴스를 집이라고 생각한다면, 보안 그룹은 집 바깥 쪽에 쳐져있는 울타리와 대문이라고 생각하면 된다. 집에 접근할 때 울타리의 대문에서 접근해도 되는 요청인지 보안 요원이 검사를 하는 것과 비슷하다.

인터넷에서 일부 사용자가 EC2 인스턴스에 접근(액세스)하려고 한다고 가정해보자. 위 그림과 같이 EC2 인스턴스 주위에 방화벽 역할을 할 보안 그룹(Security Group)을 만들고 보안 그룹에 규칙을 지정한다. 이 보안 규칙에는 인바운드 트래픽(즉, 외부에서 EC2 인스턴스로 보내는 트래픽)에서 어떤 트래픽만 허용할 지 설정할 수 있고, 아웃바운드 트래픽(즉, EC2 인스턴스에서 외부로 나가는 트래픽)에서 어떤 트래픽만 허용할 지 설정할 수 있다.

보안 그룹을 설정할 때는 허용할 IP 범위와 포트(port)를 설정할 수 있다.

6. 스토리지(볼륨)

우리가 쓰고 있는 노트북이나 데스크톱 컴퓨터는 전부 하드디스크를 가지고 있다. 하드디스크는 컴퓨터에서 파일을 저장하는 공간이다. EC2도 하나의 컴퓨터이다보니 여러 파일들을 저장할 저장 공간이 필요하다. 이 저장 공간을 보고 EBS(Elastic Block Storage)라고 부른다. 즉, EBS란 EC2 안에 부착되어 있는 일종의 하드디스크라고 생각하면 된다. EBS와 같은 저장 공간을 조금 더 포괄적인 용어로 스토리지(Storage), 볼륨(Volume)이라고 부른다.

스토리지의 종류를 보면 gp3 이외에도 여러가지 종류의 스토리지가 있다. 하지만 가성비가 좋은 gp3를 선택해주자. 용량을 30GiB를 설정한 이유는 프리 티어에서 30GiB까지 무료로 제공해주기 때문이다. 이 스토리지의 크기는 추후에 늘릴 수도 있으므로 처음 설정할 때 너무 큰 고민을 할 필요는 없다.

7. 실행 확인

좌측 메뉴에서 인스턴스 들어가보면 생성한 인스턴스가 실행되고 있는것을 볼 수 있다.

[서버] IP와 Port 개념 정리

태기 — Tue, 11 Nov 2025 02:01:21 +0900

서버 개발/운영할 때 IP와 Port의 차이를 정확히 알고 있어야 네트워크 통신이 명확해진다.

IP는 네트워크상의 컴퓨터 주소를,
Port는 그 컴퓨터 내부에서 서비스/프로그램을 구분하는 번호를 의미한다.

이 글은 IP와 Port 개념을 쉽게 이해하기 위해 정리해본다.

✅ IP의 개념

한 줄 요약 : 네트워크 상에서의 특정 컴퓨터를 가리키는 주소

아래와 같은 값이 IP 주소이다.

13.250.15.132

IP는 특정 컴퓨터의 주소를 가리킨다. 예를 들면, naver.com이라는 서비스도 IP 주소를 가지고 있다. 저 IP 주소는 네이버가 운영하고 있는 컴퓨터의 주소이기도 하다.

✅ Port의 개념

한 줄 요약 : 한 컴퓨터 내에서 실행되고 있는 특정 프로그램의 주소이다.

아래와 같은 값에서 :3000 부분이 포트 번호를 의미한다.

13.250.15.132:3000

한 컴퓨터 내에서 여러 프로그램이 실행되고 있을 것이다. 내가 지금 사용하고 있는 노트북만 보더라도 크롬, 카카오톡, 슬랙, VSCode 등 여러가지 프로그램이 동시에 실행되고 있다. 실제 서버를 운영하는 컴퓨터도 동일하다. 하나의 컴퓨터에서 여러가지의 프로그램이 실행된다.

그럼 외부에서 특정 컴퓨터 내부에 있는 Spring Boot라는 서버에 통신을 하고 싶다고 가정하자. 하지만 외부에서 IP 주소만 알아서는 실행되고 있는 여러 프로그램 중 어떤 프로그램과 통신을 해야 할 지 알 수가 없다. 그래서 특정 서버와 통신을 할 때는 IP 주소와 서버가 실행되고 있는 포트 번호까지 알고 있어야 한다.

✅ 브라우저 창에 포트 번호를 입력하지 않는 이유?

위 설명에서 분명 특정 서버와 통신하기 위해서는 IP 주소와 포트 번호를 둘 다 알아야 된다고 했다. 도메인 주소를 통해서 알 수 있는 건 IP 주소 뿐이다. 그럼 포트 번호를 입력해주지도 않았는데 어떻게 정상적으로 통신을 한 걸까?

주소창에 도메인 주소를 입력해서 엔터를 누르면, 브라우저(크롬, 익스플로러 등)는 기본적으로 80번 포트로 통신을 보내게 설정되어 있다. 그래서 포트 번호를 입력해주지 않아도 통신이 잘 됐던 것이었다. 만약 80번 포트로 통신하고 싶지 않고, 3000번 포트로 통신하고 싶다면 아래와 같이 주소창에 입력해야 한다.

✅ 잘 알려진 포트(well-known port)란 ?

‍ 포트(Port)에는 잘 알려진 포트(well-known port)라는 개념이 있다. 이 개념에 대해 알아보자.

포트 번호는 0 ~ 65,535번까지 사용할 수 있다. 그 중에서 0 ~ 1023번까지의 포트 번호는 주요 통신을 위한 규약에 따라 이미 정해져 있다. 이렇게 규약을 통해 역할이 정해져있는 포트 번호를 보고 잘 알려진 포트(well-known port)라고 부른다.

규약으로 정해져 있는 포트 번호 중 자주 사용되는 포트 번호에 대해서만 알아보자.

22번 (SSH, Secure Shell Protocol) : 원격 접속을 위한 포트 번호
- EC2 인스턴스에 연결할 때 22번 포트를 사용한다.
80번 (HTTP) : HTTP로 통신을 할 때 사용
443번 (HTTPS) : HTTPS로 통신을 할 때 사용

여기서 착각하면 안 되는 점은 위에서 정해놓은 규약을 꼭 지키지 않아도 된다. 즉, 규약으로 정해져 있는 포트 번호와 다르게 사용해도 된다는 뜻이다. 예를 들어, 특정 서버와 HTTP 통신을 할 때 80번 포트를 쓰지 않고 3000번 포트나 8080번 포트를 써도 상관 없다.

[리팩토링] OpenFeign으로 외부 API 호출 리팩토링한 기록 (Resilience4j 적용)

태기 — Sun, 6 Apr 2025 01:44:52 +0900

Spring 프로젝트에서 외부 API 호출을 기존 RestTemplate과 자체 HTTP Client로 처리하고 있었다.

API 호출 코드가 늘어나면서 유지보수와 테스트가 점점 불편해져서

OpenFeign으로 전환하는 리팩토링을 진행했다.

전환 과정에서 외부 API 장애로 인한 서버 부하를 줄이기 위해

Resilience4j를 적용해 서킷 브레이커 패턴도 함께 적용했다.

이 글은 RestTemplate 기반 외부 API 호출을

OpenFeign + Resilience4j 구조로 리팩토링한 기록이다.

[핵심 요약]

1. 자체 HTTP Client 및 RestTemplate을 OpenFeign으로 전환

기존에는 RestTemplate이나 직접 구현한 HTTP Client를 사용하여 외부 API를 호출했지만, 이를 OpenFeign으로 변경했다.
OpenFeign을 사용하면 API 호출을 인터페이스 기반으로 선언형으로 작성할 수 있어 코드가 간결해지고 유지보수가 쉬워진다.
테스트 시에도 API 호출을 Mock 객체로 대체하기 쉬워 테스트 용이성이 증가한다.

2. OpenFeign + Resilience4j로 서킷 브레이커 패턴 적용

기존 HTTP Client에서 네트워크 장애가 발생하면, 응답 시간이 지연되거나 서버 부하가 증가하는 문제가 있었다.
이를 Resilience4j의 서킷 브레이커 패턴을 활용해 해결했다.
OpenFeign을 사용할 때 Resilience4j를 적용하면, 장애 발생 시 즉시 실패 처리하고, 특정 시간 동안 API 호출을 차단하여 서버가 과부하되지 않도록 보호한다.

1. [Before] 기존 RestTemplate 사용 방식 (예시)

import org.springframework.stereotype.Service;
import org.springframework.web.client.RestTemplate;
import org.springframework.http.ResponseEntity;

@Service
public class UserService {
	
    private final RestTemplate restTemplate = new RestTemplate();
    
    public String getUserInfo(Long userId) {
    	String url = "http://localhost:8080/users/" + userId;
        ResponseEntity<String> response = restTemplate.getForEntity(url, String.class);
        return response.getBody();
    }
}

[문제점]

- HTTP 요청을 직접 생성해야 하고, 예외 처리 및 장애 대응을 수동으로 구현해야 한다.

- API 호출 코드가 많아지고 테스트하기 어렵다.

2. [After] OpenFeign 적용 방식

import org.springframework.cloud.openfeign.FeignClient;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.PathVariable;

@FeignClient(name = "userClient", url = "https://api.example.com")
public interface UserClient {

    @GetMapping("/users/{id}")
    String getUserInfo(@PathVariable("id") Long userId);
}

[장점]

- API 호출 로직이 인터페이스 선언만으로 간결해진다.

- 테스트 시 이 인터페이스를 Mock 객체로 대체가 가능하다.

3. [Resilience4j 적용] 서킷 브레이커 추가

import io.github.resilience4j.circuitbreaker.annotation.CircuitBreaker;
import org.springframework.stereotype.Service;

@Service
public class UserService {

    private final UserClient userClient;

    public UserService(UserClient userClient) {
        this.userClient = userClient;
    }

    @CircuitBreaker(name = "userService", fallbackMethod = "fallbackUserInfo")
    public String getUserInfo(Long userId) {
        return userClient.getUserInfo(userId);
    }

    public String fallbackUserInfo(Long userId, Throwable t) {
        return "Default User Info"; // 장애 발생 시 기본 응답 반환
    }
}

[서킷 브레이커 기능]

- API 요청이 반복적으로 실패하면, 일정 기간 동안 요청을 차단하여 서버 과부하를 방지한다.

- 장애 발생 시 fallbackUserInfo() 메서드를 호출하여 기본 응답을 반환한다.

- Resilience4j 덕분에 안정적인 API 호출 구조를 유지할 수 있다.

4. 결론

- 기존의 HTTP Clinet, RestTemplate을 OpenFeign으로 전환하여 코드를 간결화하고 테스트 용이성을 증가시켰다.

- OpenFeign에 Resilience4j 서킷 브레이커 패턴을 적용하여, API 장애 발생 시 즉시 실패 처리하고 서버 과부하를 방지한다.

정리하면, 외부 API 호출이 많은 Spring 프로젝트에서는 RestTemplate 기반 구조보다
OpenFeign + Resilience4j 조합이 유지보수와 안정성 측면에서 훨씬 효과적이었다.