처음 웹 서비스를 만들고 완성했을 때, 가장 먼저 든 생각은 “그럼 이걸 어떻게 배포하지?”였다.
프론트엔드는 HTML, CSS, JS로 마무리했고, 백엔드는 Java 기반의 Servlet으로 개발. 데이터는 MySQL에 잘 저장되고 있었지만, “이제 이걸 사용자들이 실제로 접속할 수 있게 하려면 어떻게 해야 할까?”라는 질문 앞에서 멈췄다.
많은 사람들이 처음엔 웹서버 = WAS라고 생각한다. 하지만 실제로는 다르다.
이 둘의 협업이 중요한 이유는 성능 때문이다.
예를 들어 Apache(Nginx)와 Tomcat을 조합하면, 정적 리소스는 웹서버에서 빠르게 처리하고, 동적 요청만 WAS가 부담하게 할 수 있다.
✅ 구조 요약:
클라이언트 → 웹서버(Apache/Nginx) → WAS(Tomcat) → DB
서비스를 운영하기 위해 구성한 기본 아키텍처는 다음과 같다:
[사용자]
↓
[웹 브라우저]
↓
[웹 서버 (Nginx)]
↓
[WAS (Tomcat)]
↓
[DB (MySQL)]
여기서 각 역할은 다음과 같다:
main
브랜치에 머지되면 배포 자동화 트리거 발생Gradle/Maven
으로 .war
파일 빌드scp
, FTP
, GitHub Actions)/var/www/html
경로에 업로드443
포트를 통해 SSL 트래픽 수신bind-address=127.0.0.1
)처음에는 수동으로 배포할 때마다 Tomcat을 재시작했지만, 서비스가 커지면서 무중단 배포가 필요해졌다.
도입한 전략:
/health
엔드포인트로 상태 체크/var/log
가 가득 찼던 일Too many connections
오류로 DB 튜닝운영을 하면 할수록 단순히 “배포”만이 아니라 모니터링, 로그관리, 트래픽 대응이 중요하다는 걸 알게 됐다.
웹 서비스의 배포는 단순히 “코드 올리기”가 아니다.
웹서버, WAS, DB 간의 연결과 역할 분담, 그리고 보안과 무중단 운영까지 고려해야 진짜 운영환경을 만든다.
내가 배운 가장 중요한 점은:
**“서비스는 코드로 끝나는 게 아니라, 배포로 완성된다”**는 것이다.
+-------------+
| CLIENT |
+------+------+
|
HTTPS / HTTP 요청
↓
+----------+-----------+
| NGINX (웹서버) |
+----+-------------+---+
| |
정적 파일 응답 WAS로 Proxy 전달
| ↓
+----+-------------+----+
| TOMCAT (WAS) |
+-----------+------------+
|
JDBC / JPA / ORM 등
↓
+-------+--------+
| MySQL / RDS |
+----------------+