Jenkins·Web·WAS·DB 서버 직접 구성해보면서 Hetzner 플랜 선택, 로케이션 결정까지 실제로 고민한 과정을 정리했습니다. (74자)
이전 글: [서버, 인프라] - 클라우드 서버 어디서 만들어야 해? AWS 대비 90% 저렴한 Hetzner로 시작하기
서버 하나 만들려다가 고민이 생겼어요
Hetzner 가입하고, 인증도 끝냈어요.
이제 서버 만들면 되는데, 콘솔 들어가니까 또 막히는 거예요.
플랜이 CX, CPX, CAX, CCX로 나뉘어 있고, 로케이션은 Nuremberg, Falkenstein, Helsinki, Singapore, Hillsboro, Ashburn까지 여섯 곳.
근데 어떤 플랜은 회색이라 선택이 안 되고, 같은 플랜인데 로케이션마다 가격이 다르고.
"그냥 아무거나 고르면 안 되나?" 싶은데, 막상 서버 만들고 나서 메모리 부족으로 컨테이너가 죽으면 다시 처음부터 시작해야 하거든요.
그래서 제가 실제로 Jenkins + Nginx(Web) + WAS + DB 구성을 잡으면서 고민한 과정 그대로 풀어볼게요.
먼저 뭘 올릴 건지 정리했어요
목표는 이거였어요.
- Jenkins (CI/CD)
- Nginx (웹 서버)
- WAS (Spring Boot 기준)
- DB (MySQL)
이걸 어떻게 나눌지가 첫 번째 고민이었어요.
DB는 따로 두는 게 맞아요
DB는 무조건 따로 분리하는 걸 추천해요.
이유가 있어요. 같은 서버에 DB까지 같이 올리면, WAS나 Jenkins가 메모리를 확 잡아먹을 때 DB가 같이 영향을 받아요. DB는 I/O가 중요한데, 다른 컨테이너랑 디스크 경합이 생기면 쿼리 응답이 느려지거든요.
그리고 나중에 서비스가 커져서 DB 서버 스펙을 올려야 할 때, 분리가 안 돼 있으면 전체 서버를 교체해야 해요. 따로 두면 DB 서버만 업그레이드하면 되고요.
Jenkins는 지금 당장 분리 안 해도 돼요
Jenkins를 따로 빼면 빌드 부하가 서비스 서버에 영향을 안 주는 장점이 있어요.
근데 개인 프로젝트나 포트폴리오 용도라면, 지금 당장 분리할 필요는 없어요.
현실적으로 생각해보면, Jenkins 빌드가 도는 타이밍에 실제 사용자가 동시에 접속할 일이 거의 없거든요. 서버가 하나 더 늘면 월 $7~10이 추가되는데, 아직 트래픽도 없는 상황에서 그 비용을 굳이 낼 필요가 없어요.
나중에 실제 사용자가 붙기 시작하면 그때 Jenkins 서버를 분리하면 돼요. Hetzner는 서버 추가가 수 분이면 끝나거든요.
최종 구성
결국 이렇게 정리됐어요.
[통합 서버] Jenkins + Nginx + WAS ←→ [DB 서버] MySQL
↑
외부 인터넷 (80/443)
서버 2대. 깔끔해요.
그런데 저는 DB 서버가 이미 있었어요
AWS Free Tier로 RDS를 쓰고 있었거든요.
솔직히 12개월 무료인데 굳이 Hetzner에 DB 서버를 따로 만들 이유가 없잖아요.
그래서 지금 당장은 이렇게 가기로 했어요.
[Hetzner 통합 서버] Jenkins + Nginx + WAS
↓
[AWS RDS] MySQL (무료)
월 비용이 통합 서버 1대 값만 나오는 구조예요.
한 가지만 챙기면 돼요. AWS RDS 보안 그룹에서 인바운드 규칙에 Hetzner 서버의 공인 IP를 허용해줘야 해요. 안 그러면 DB 연결이 안 되거든요.
AWS 무료 기간이 끝나거나, 서비스 오픈이 가까워지면 그때 Hetzner에 DB 서버를 추가하면 돼요. 순서가 자연스럽게 맞아 떨어져요.
플랜 고르기 — 여기서 한 번 더 막혔어요
구성은 정했는데, 이제 플랜을 골라야 해요.
콘솔 들어가서 Cost-Optimized(CX) 탭 보니까 CX33이 회색이에요.
"어? 이상하죠?"
이게 Cost-Optimized 탭 상단에 "Limited availability" 라고 써있는 이유예요. CX 플랜은 오래된 하드웨어라 재고가 있는 사양만 선택 가능한 거거든요.
해결 방법은 간단해요. Regular Performance 탭으로 넘어가면 돼요. CPX 플랜이 나오고, 여기선 사양 제한 없이 다 선택 가능해요.
플랜 한 줄 정리
CX (Cost-Optimized) — 가장 저렴. 재고 있는 것만 선택 가능. EU 리전만. 가볍게 테스트할 때.
CPX (Regular Performance) — AMD EPYC 기반. 재고 제한 없음. 글로벌 리전 지원. 서비스 운영에 무난.
CAX (ARM) — ARM 아키텍처. CPX보다 저렴하고 전력 효율 좋음. EU 리전만. Docker 이미지 ARM64 지원 여부 먼저 확인 필요.
CCX (Dedicated) — 전용 vCPU. 성능이 일정하게 보장됨. DB 서버나 CI/CD 부하 심할 때.
그래서 뭘 골랐냐면
Jenkins + Nginx + WAS 세 개를 Docker로 같이 돌려야 하니까 RAM이 관건이에요.
Spring Boot WAS만 해도 기본 1~1.5GB 먹어요. Jenkins도 빌드 중엔 1~1.5GB 잡아요. Nginx는 가벼워서 100MB 내외고요.
4GB면 빠듯하고, 8GB면 여유 있어요.
| CPX22 | 2코어 | 4GB | 80GB | 20TB | $10.09 | ⚠️ 빠듯함 |
| CPX32 | 4코어 | 8GB | 160GB | 20TB | $17.09 | ✅ 안정적 |
| CX33 | 4코어 | 8GB | 80GB | 20TB | $8.59 | ✅ 가성비 |
CX33이 CPX32보다 $8 저렴하면서 코어·RAM이 같아요. 단, Limited availability라서 선택 가능한 로케이션이 제한될 수 있어요.
안정성과 선택 유연성을 생각하면 CPX32, 비용을 줄이고 싶다면 CX33 (선택 가능할 때) 이 답이에요.
로케이션 고르기 — Nuremberg vs Falkenstein vs Helsinki
가격은 셋 다 똑같아요. 그럼 뭘 기준으로 골라야 하냐면, 레이턴시예요.
한국 기준으로 보면 이렇게 나와요.
| Nuremberg (독일) | 약 220~240ms | 가장 오래된 DC, 안정성 검증 |
| Falkenstein (독일) | 약 220~240ms | 트래픽이 Nuremberg 통해 나감 |
| Helsinki (핀란드) | 약 230~260ms | 셋 중 지리적으로 가장 멀어요 |
여기서 재밌는 게 있어요.
Falkenstein은 독립 회선이 아니라 대부분의 트래픽이 Nuremberg를 경유해서 나가는 구조예요. 그러면 Nuremberg랑 레이턴시가 사실상 같고, 중간 경유 포인트가 하나 더 생기는 셈이에요.
결국 핵심은 이거예요.
셋 중 레이턴시가 가장 낮고, 안정성이 검증된 건 Nuremberg예요.
220ms가 느리게 느껴질 수 있는데, 이건 관리자가 SSH 접속하거나 콘솔에서 배포할 때 체감이지, 실제 서비스 응답속도랑은 다른 얘기예요. 서비스 로직 처리는 서버 내부에서 일어나니까요.
개인 포트폴리오 용도라면 레이턴시 20~30ms 차이는 전혀 신경 안 써도 돼요.
결론: Nuremberg, CPX32로 가세요.
근데 여기서 반전이 있었어요
Nuremberg CPX32로 서버를 만들고 나서, 콘솔을 다시 들여다봤는데요.
Helsinki 로케이션에 CX33 (4코어 / 8GB / $7.99/mo) 이 선택 가능한 상태였어요.
CPX32랑 코어, RAM이 완전히 동일한데 가격이 $17에서 $8.59로 절반이에요. 트래픽도 똑같이 20TB 포함이고요.
"어? 이거 그냥 바꾸면 안 되나?"
바로 찾아봤는데, Hetzner Rescale 기능으로 플랜 변경이 되긴 해요. 근데 CPX → CX 계열 변경은 지원이 안 돼요. 플랜 계열이 달라지면 그냥 새로 만들어야 하거든요.
아무것도 설치 안 한 상태라 데이터 날아갈 것도 없었어요. 시간 단위 과금이라 삭제해도 몇 센트 수준이고요.
그래서 그냥 기존 서버 삭제하고 CX33 Helsinki로 새로 만들었어요.
콘솔에서 서버 삭제 → 새 서버 생성까지 5분도 안 걸렸어요.
근데 CX33은 Limited availability라 재고가 있을 때만 선택 가능해요. 처음 만들 땐 선택이 안 됐다가, 나중에 여유분이 생기면서 선택 가능해진 거예요. 이런 경우도 있으니까, 콘솔 들어갔을 때 CX33이 보이면 그때 바로 잡는 게 맞아요.
최종 선택: Helsinki CX33, $8.59/mo
같은 사양에 한 달 $8.50 아끼는 거니까, 1년이면 $102 차이예요. 개인 프로젝트 서버치고는 꽤 의미 있는 절약이에요.
나중에 확장해야 할 때는?
지금은 이 구성으로 시작하지만, 서비스가 커지면 어떻게 되냐고요?
단계별로 보면 이렇게 흘러가요.
지금: Hetzner 통합 서버 1대 + AWS RDS (무료)
서비스 오픈 초기: 통합 서버 스펙 업그레이드 (CPX32 → CPX42). AWS 무료 기간 끝나면 Hetzner DB 서버 추가. 두 서버를 Private Network로 연결해서 DB 포트는 외부에 노출 안 하는 구조로.
트래픽이 본격적으로 붙을 때: Jenkins를 별도 서버로 분리. Web/WAS도 필요하면 나눠요. 이때 Docker Compose 파일이 처음부터 서비스별로 잘 분리돼 있어야 이 과정이 수월해요.
포인트는 지금 Docker Compose를 짤 때, Jenkins / Nginx / WAS를 하나의 덩어리로 묶지 말고 서비스별로 분리해서 작성하는 거예요. 나중에 떼어낼 수 있게요.
서버 만들고 나면 메일이 와요
"Create & Buy Now" 누르고 1분 안에 서버가 올라와요.
그리고 가입 이메일로 메일이 한 통 날아와요.
Your new server has been created.
IP Address : xxx.xxx.xxx.xxx
Username : root
Password : xxxxxxxxxxxxxxxxIP 주소, 아이디(root), 임시 비밀번호가 같이 와요. 이게 첫 접속 정보예요. 잘 챙겨두세요.
이제 실제로 접속해볼게요
Mac / Linux 사용자 — 터미널
터미널 열고 이렇게 치면 돼요.
ssh root@[메일에서 받은 IP 주소]처음 접속하면 이런 메시지가 나와요.
The authenticity of host 'xxx.xxx.xxx.xxx' can't be established.
Are you sure you want to continue connecting (yes/no)?yes 입력하고 엔터. 그 다음 메일에서 받은 비밀번호 입력하면 돼요.
비밀번호 입력할 때 화면에 아무것도 안 보여도 정상이에요. 보안상 원래 그렇게 설계돼 있거든요. 그냥 입력하고 엔터 치면 돼요.
Windows 사용자 — PuTTY
Windows는 기본 터미널에서 SSH 접속이 안 되는 경우가 있어서 PuTTY를 많이 써요.
PuTTY 다운로드: https://www.putty.org
Mike Yeadon: Final Warning
Welcome. This page has been experiencing publicity, so I'm using it for a cause which I believe will serve the common good. This is the latest interview with Mike Yeadon. "I am a lifetime research scientist. I worked for 32 years in the pharmaceutical indu
www.putty.org
받아서 실행하면 설정 화면이 바로 나와요. 복잡하지 않아요.
- Host Name 칸에 메일에서 받은 IP 주소 입력
- Port : 22 (기본값 그대로)
- Connection type : SSH 선택돼 있는지 확인
- Open 클릭
처음 접속하면 "서버를 신뢰하겠습니까?" 팝업이 떠요. Accept 클릭.
까만 터미널 창이 열리면서 이런 게 나와요.
login as: root
root@xxx.xxx.xxx.xxx's password:root 입력 → 엔터 → 메일에서 받은 비밀번호 입력 → 엔터.
아래처럼 나오면 접속 성공이에요.
Welcome to Ubuntu 26.04 LTS
root@your-server-name:~#접속 직후 꼭 해야 할 것 두 가지
비밀번호 변경
접속하면 바로 이런 메시지가 나와요.
You are required to change your password immediately.
Current password:
New password:
Retype new password:메일로 받은 임시 비밀번호는 처음 접속 즉시 바꾸도록 강제돼 있어요.
현재 비밀번호(메일에서 받은 것) 입력 → 새 비밀번호 두 번 입력하면 끝이에요.
비밀번호는 영문 대소문자 + 숫자 + 특수문자 조합으로 12자 이상 쓰는 걸 추천해요. 이 서버는 외부에 열려 있는 거라 비밀번호가 약하면 자동화된 해킹 시도가 들어오거든요. 생각보다 빠르게 들어와요.
패키지 업데이트
비밀번호 바꾸고 다시 로그인하면, 첫 번째로 할 게 패키지 업데이트예요.
apt update && apt upgrade -y뭔가 쭉 올라가면서 설치가 되는데, 다 끝날 때까지 기다리면 돼요. 중간에 뭔가 물어보면 엔터 치면 대부분 넘어가요.
여기까지 하면 서버 생성 → 플랜/로케이션 선택 → 첫 접속 → 기본 세팅까지 완료예요.
마무리
서버 구성 고민하면서 느낀 건, 처음부터 완벽한 구성을 잡으려다가 오히려 시작을 못 한다는 거예요.
지금 단계에서 필요한 건 "나중에 확장할 수 있는 구조"지, 처음부터 3~4대 굴리는 게 아니에요.
Hetzner CPX33 1대, 월 $9. 여기서 시작하고, 실제로 사용자가 붙으면 그때 고민해도 충분히 늦지 않아요.
다음 편에서는 이 서버에 Docker를 설치하고 Jenkins + Nginx + WAS를 실제로 올리는 과정을 다룰게요.
다음 글: [서버, 인프라] - Docker + Jenkins, 서버에 직접 올려봤습니다 — Hetzner 실전 세팅 3편
