🔗 메모
1. 웹의 기본 구조와 HTML/JS
- HTML의 본질: C/Java 같은 고수준 프로그래밍 언어가 아니라, 웹페이지의 구조를 정의하는 마크업 언어.
→ 컴퓨터가 바로 이해하는 기계어가 아니며, 웹 브라우저(인터프리터)가 HTML 문법으로 작성된 문서(웹페이지, doc 타입)을 한 줄씩 판독하고 분석하여 화면(View 영역)에 렌더링 - 클라이언트와 서버의 통신: 웹 브라우저(프론트엔드)는 필요할 때마다 웹 서버(백엔드)에 URI(URL)를 통해 자원을 요청하고, 서버로부터 HTML, CSS, JS 파일을 받아와 화면에 정적/동적으로 표시함
- JavaScript와 Node.js:
- JS는 원래 웹 브라우저가 판독하던 인터프리터 언어였으나, 이를 브라우저 외부(서버단)에서도 실행할 수 있도록 만든 환경이 Node.js. (JS를 백엔드 서버 언어로 사용 가능하게 함)
- 데이터 교환 포맷으로는 JS 객체 문법을 따르는 JSON(JavaScript Object Notation) 이 글로벌 표준으로 사용됨.
💡웹페이지란? 브라우저 창에 뜨는 하나의 화면(문서). 인터넷 주소(URL)를 통해 데이터를 받아와 화면에 그려주는 결과물 (글, 이미지, 동영상 등의 데이터로 구성 + 사용자가 클릭하거나 글 입력 등 제한된 상호작용 가능)
2. Java 가상머신(JVM)과 컴파일 방식
- Java의 모토 (Write Once, Run Anywhere): 인텔, 리눅스, ARM 등 CPU와 OS마다 기계어가 다르기 때문에, 원래 C계열 언어는 환경별로 컴파일러를 따로 두어 기계어를 만들어야 했음 (플랫폼 종속적)
- *JVM(자바 가상머신)의 역할: 가상의 컴퓨터 환경. 자바는 플랫폼에 종속되지 않기 위해 중간 코드(바이트코드)를 만들고, 실제 실행되는 시점에 각 OS에 설치된 JVM이 이를 기계어로 번역
- JIT(Just-In-Time) 컴파일러: 실행 시점(런타임)에 자주 바뀌지 않는 코드를 기계어로 미리 캐싱해두어 초기 자바의 느린 속도를 극복한 기술
→ 자바 가상머신(JVM) 등이 사용 - AOT(Ahead-Of-Time) 컴파일: 최근(스프링부트 3.0 등)에는 아예 빌드 시점에 기계어로 미리 번역하여 가상머신 없이 실행파일 형태로 배포하는 AOT 방식도 많이 쓰인다. (실행 속도가 빠르고 메모리를 적게 먹지만, 빌드 시간이 길고 용량이 커질 수 있음)
- JIT(Just-In-Time) 컴파일러: 실행 시점(런타임)에 자주 바뀌지 않는 코드를 기계어로 미리 캐싱해두어 초기 자바의 느린 속도를 극복한 기술
더보기
✨ 가상머신 설명
1) 가상머신의 핵심 작동 원리
- 물리적 하드웨어(Host): 실제 눈에 보이는 컴퓨터(CPU, 메모리, 디스크 등)
- 하이퍼바이저(Hypervisor): 물리 하드웨어의 자원을 가상머신에 골고루 분배하고 제어하는 관리자 소프트웨어
- 가상머신(Guest): 하이퍼바이저 위에서 생성된 독립된 컴퓨터 환경. 각 VM은 자신만의 OS(Windows, Linux 등)를 독립적으로 실행
2) 가상머신을 사용하는 이유 (주요 장점)
- 멀티 OS 실행: 윈도우 PC를 쓰면서 리눅스(Ubuntu 등) 환경을 동시에 띄워 개발이나 테스트 가능. 맥북에서 윈도우 전용 프로그램을 돌릴 때도 쓰임.
- 안전한 격리 환경: 가상머신 내부에서 바이러스가 걸리거나 시스템이 완전히 망가져도, 실제 본체의 PC(호스트)에는 전혀 영향을 주지 않는다. (악성코드 분석이나 위험한 실험을 할 때 유용함)
- 백업과 복구의 용이성 (스냅숏): 현재 가상머신의 상태를 그대로 사진 찍듯 저장(스냅숏) 가능. 문제가 생기면 언제든 저장했던 시점으로 1초 만에 되돌릴 수 있음
- 서버 자원의 효율화: 기업에서는 고성능 서버 1대를 사서 가상머신 수십 대를 쪼개어 씀. 서버 컴퓨터 공간과 전기세를 엄청나게 아낄 수 있어서 현대 클라우드 컴퓨팅(AWS, Azure 등)의 핵심 기반 기술
3. 단점
- 성능 손실: 진짜 하드웨어를 직접 쓰는 게 아니라 중간에 하이퍼바이저를 거치기 때문에, 실제 컴퓨터 성능보다 조금 느리다. (무거운 그래픽 작업에는 불리)
- 자원 소모: 가상머신을 하나 띄울 때마다 독립된 OS가 통째로 실행되므로, 내 컴퓨터의 RAM(메모리)과 디스크 용량을 많이 잡아먹음
💡 대표적인 가상머신 소프트웨어 (개인 PC 환경)
최근에는 가상머신보다 더 가볍고 빠르게 실행되는 '컨테이너(Docker 등)' 기술도 많이 쓰이지만, 완전히 분리된 독립 OS 환경이 필요할 때는 여전히 가상머신(VM)이 필수적으로 사용
- VirtualBox (버추얼박스): 오라클에서 만든 무료 프로그램으로, 초보자가 개인 PC에서 가상 환경을 테스트하기 가장 좋음.
- VMware Workstation / Player: 업계에서 가장 유명하고 성능이 뛰어난 유료/무료 프로그램
- Hyper-V: 윈도우 Pro 버전 이상에 기본으로 내장되어 있는 마이크로소프트의 가상화 기능
3. 웹 서버(Web Server)와 WAS(Netty, Tomcat, Nginx)
현대 백엔드 아키텍처에서는 서버의 역할을 분담한다
| 서버 종류 | 주요 역할 및 특징 |
| Nginx (웹 서버) | 비동기 이벤트 기반(Single Event Loop). 가볍고 빠름. 주로 웹 브라우저에게 HTML, CSS, JS(SPA 결과물) 같은 정적 자원을 서빙하거나 프록시 역할을 함. |
| Tomcat (WAS) | 전통적인 스레드 기반의 자바 웹 서버. 요청(Request)이 올 때마다 스레드를 할당하여 자바 코드를 실행(레거시 서블릿 방식부터 발전). 현재 스프링부트는 Tomcat을 내장(Embedded)하고 있어서 자바 실행파일 만으로 서버가 구동됨. 💡 서블릿 방식: 웹서버 특정 폴더안에 자바코드 넣기 ✨ JVM 포함, 자바 코드나 JSP 파일을 실행해 동적으로 결과를 만들어낼 수 있는 특수 서버 |
| Netty (네트워크 프레임워크) | 비동기 이벤트 기반(Reactive) 으로 동작하여 톰캣의 대규모 트래픽 스레드 고갈 문제를 극복함. (혹은 선언형 프로그래밍) 스프링 진영에서는 '스프링 프로젝트 리액터'와 결합하여 고성능 비동기 백엔드를 만들 때 사용함. |
- RESTful API 시대의 도래: 과거에는 톰캣 내부에서 JSP 등을 통해 웹페이지(화면+데이터)를 직접 그려서 반환(레거시)했지만, 현대 백엔드(Tomcat, Netty 등)는 화면을 주지 않고 순수한 데이터(JSON, 이미지, 비디오 등)만 제공하는 REST API 역할에 집중
💡 한 줄 요약:
SPA(Single Page Application): 프론트엔드 개발 기법(리액트, 뷰 등)
Nginx: SPA 결과물(정적 파일)을 브라우저에 빠르게 서빙해주는 웹 서버
Tomcat, Netty: 데이터(이미지, 오디오, 비디오) 만 제공
→ 이런 서버들이 웹페이지는 제공하지 않는 RESTful Api 역할에 집중
✨ *JSP (JavaServer Pages) 설명
HTML 코드 안에 자바(Java) 코드를 넣어서 동적인 웹페이지를 생성하는 서버 측 웹 개발 기술 (.jsp)
서블릿(Servlet) 단점: 자바 백엔드의 시초에는 자바 코드 안에 HTML 문자열을 일일이 넣어야 함
→ 반대로 기본 틀을 HTML로 짜고, 데이터가 바뀌는 부분만 자바 코드로 구성하자는 아이디어로 시작
더보기
✨ JSP 추가 설명
1) JSP의 핵심 구동 원리
JSP 파일은 브라우저가 직접 읽을 수 없음. (브라우저는 오직 HTML, CSS, JS만 가능) 그래서 톰캣(Tomcat) 같은 WAS가 중간에서 변환 과정을 거침
- 사용자가 브라우저에서 mypage.jsp를 요청
- 톰캣 서버가 이 .jsp 파일을 받아와서 순수 자바 파일(.java 서블릿 파일)로 변환 함 (결국 다시 서블릿이 됨)
- 이 자바 파일을 컴파일해서 .class 실행 파일로 만듦
- 실행 결과로 만들어진 순수 HTML만 브라우저에게 던져줌
2) 현대 웹 개발에서 '레거시(Legacy)' 라고 부르는 이유
지금은 JSP를 신규 프로젝트에 잘 쓰지 않고 레거시 취급을 한다. (이유는 역할 분담 때문)
- 과거 (SSR - 서버 사이드 렌더링): JSP가 화면(레이아웃) 도 가지고 있고, DB에서 가져온 데이터 도 자바 코드로 직접 추가해 완성된 HTML을 서버에서 다 만들어 보냈음. + 백엔드 개발자가 화면까지
- 현대 (SPA 기법 + RESTful API):
- 프론트엔드(React, Vue 등): 화면 레이아웃과 UI 로직만 담당 (Nginx 등을 통해 브라우저에 배포)
- 백엔드(Spring Boot 등): 화면은 신경 쓰지 않고, 오직 DB에서 꺼낸 순수한 데이터(JSON)만 넘겨줌.
💡 한 줄 요약: JSP는 과거에 자바 데이터와 HTML 화면을 묶어 웹페이지를 만들던 기술. 현재는 프론트엔드와 백엔드가 철저히 분리되면서, 백엔드는 JSP 대신 데이터만 주는 RESTful API 를 만드는 방식으로 발전한 것
4. 백엔드 트렌드 및 MSA (Microservice Architecture)
현대 백엔드 개발자는 복잡한 인프라나 로직을 직접 짜기보다, 잘 만들어진 라이브러리와 디펜던시(의존성)를 활용해 비즈니스 로직(핵심 서비스)에 집중 한다. 대규모 서비스는 대부분 monolithic(통짜 구조)에서 MSA(마이크로서비스 아키텍처)로 전환하는 추세
- 인증/인가 (Authentication): 회원가입/로그인을 직접 구현하기보다 소셜 로그인의 표준인 OAuth를 도입하거나, 분산 환경에서 사용자 인증을 위해 JWT(Json Web Token) 등을 활용. (※ 참고로 구글이나 넷플릭스 같은 거대 기업은 서비스 특성에 따라 세션 ID 방식과 토큰 방식을 혼용하거나 자체 보안 프로토콜을 쓴다.)
- 비동기 메시징 (Message Broker): 마이크로서비스끼리 통신할 때 동기(HTTP) 방식 외에도, 시스템 간 결합도를 낮추기 위해 RabbitMQ(래빗엠큐)나 Kafka 같은 메시지 브로커를 씀. (발행자가 토큰/토픽을 발행하면, 컨슈머(소비자)가 이를 구독하여 처리하는 구조)
🛠️ MSA의 필수 구성 요소
- API Gateway: 수많은 마이크로서비스의 단일 진입점 역할을 하며, 라우팅 및 인증을 담당.
- Service Discovery: 어떤 서비스(예: 결제 서비스)가 구동 중인지, 인스턴스가 늘어났는지 동적으로 감지하고 주소를 관리함.
- 분산 로그 추적 및 모니터링 (ELK 스택): 서비스가 쪼개져 있어서 에러 추적이 어렵기 때문에, ELK(Elasticsearch, Logstash, Kibana) 등을 이용해 여러 서비스 사이에 돌아다니는 메시지와 로그를 통합 검색하고 모니터링함.
- Database per Service: MSA의 핵심 원칙 중 하나로, 각 마이크로서비스는 자신만의 독립된 DB를 가짐
5. 가상화 기술 (도커와 리눅스 컨테이너)
- 도커(Docker)의 본질: 호스트 OS 위에서 프로세스를 완전히 격리하여 실행시키는 기술
- 과거의 격리 vs 리눅스 컨테이너: 과거 유닉스/리눅스의 프로세스 격리는 커널 공간을 공유하면서 단순히 파일시스템 등을 제한하는 수준
- 리눅스 커널의 내부 기술(Namespace, cgroups 등)이 발전하면서, 하드웨어를 통째로 가상화하는 무거운 VM(가상머신)과 달리 커널은 공유하되 OS 레벨에서 완벽하게 독립된 공간을 분리해내는 '리눅스 컨테이너' 기술이 정립되었고, 이를 누구나 쓰기 쉽게 대중화한 프로그램이 도커(Docker)