쿠버네티스 클러스터는 컨테이너화 된 애플리케이션을 실행하는 컴퓨팅 노드이다.

컨테이너화 된 애플리케이션의 대규모 배포, 스케일링 및 관리를 간편하게 만들어주며, 오픈 소스 기반의 컨테이너 오케스트레이션이다.

오케스트레이션(Orchestration)은 
컨테이너, 서버, 애플리케이션, 데이터 파이프라인 등 
여러 IT 구성 요소와 자동화된 태스크들을 연동하여 
복잡한 워크플로우를 효율적으로 관리 및 조율하는 기술을 의미한다.

도커는 애플리케이션의 프로세스 격리 기술을 사용해 컨테이너로 관리할 수 있는 도구라면,

쿠버네티스는 그런 컨테이너를 간편하게 관리할 수 있게 도와준다고 보면 된다.

1. 준비사항

Ubuntu 24.04.1 LTS / VMware workstation Pro

• Master Node 1대 (CPU 2 Core, RAM 2GB)

• Worker Node 2대 (CPU 1 Core, RAM 1GB)

사양 확인

• 코어 nproc

• 메모리 free -h

• ifconfig -a

• uuid sudo cat /sys/class/dmi/id/product_uuid

모든 명령어 입력은 root 계정에서 진행한다.

• sudo su

2. 순서

1. 쿠버네티스 설치 준비

2. 컨테이너 런타임 설치

3. 쿠버네티스 설치

4. Master Node 설정

5. Worker Node 등록

6. 최종 확인

3. swap 비활성화

쿠버네티스의 대표적인 역할은 스케줄링(어느 노드에 어떤 컨테이너 (=Pod)를 배치할까)

스케줄러는 각 노드의 가용자원(CPU, Memory)를 정확히 파악해서 Pod를 배치함

만약 swap이 켜져있으면, 노드의 실제 물리 메모리가 부족할 때 디스크의 일부를 메모리처럼 사용하게 됨

이럴 경우, Pod를 계속 보낼 수 있지만, 실제로는 디스크 I/O 성능이 급격히 저하될 수 있음

따러서, 스케줄러가 자원 상태를 100% 예측 가능하게 관리하기 위해서 변수가 되는 스왑을 제거하는 것임.

# 영구 비활성화
sudo sed -i '/swap/s/^/#/' /etc/fstab

# 메모리 상태확인
sudo free -m

# swap 메모리 상태 확인 (출력값 없으면 비활성화 상태)
sudo swapon -a

4. 방화벽 설정

쿠버네티스 포트만 개방 / 방화벽 비활성화 두가지 방법 중 하나를 선택해서 진행함.

필자의 경우 전자를 선택해서 진행.

# 방화벽 설치 및 예외 설정 
sudo apt-get install -y firewalld
sudo systemctl start firewalld
sudo systemctl enable firewalld
sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --permanent --add-service=https

Master node 인 경우

TCP

• 6443 Kubernetes API Server

• 2379-2380 etcd server API (DB)

• 10250 Kubernetes API

• 10251 kube-scheduler

• 10252 kube-controller-manager

UDP

• CNI (Container network interface) 용도

• 8285 Flannel (UDP)

• 8472 Flannel (VXLAN)

sudo firewall-cmd --permanent --add-port=6443/tcp
sudo firewall-cmd --permanent --add-port=2379-2380/tcp
sudo firewall-cmd --permanent --add-port=10250-10252/tcp
sudo firewall-cmd --permanent --add-port=8285/udp
sudo firewall-cmd --permanent --add-port=8472/udp
sudo firewall-cmd --reload

Worker node 인 경우

TCP

• 10250 kubelet API

• 30000-32767 Nodeport services (외부에서 쿠버네티스 내부 서비스에 접속할 때 사용함

UDP

• 8285/8472 Flannel

sudo firewall-cmd --permanent --add-port=10250/tcp
sudo firewall-cmd --permanent --add-port=30000-32767/tcp
sudo firewall-cmd --permanent --add-port=8285/udp
sudo firewall-cmd --permanent --add-port=8472/udp
sudo firewall-cmd --permanent --add-port=26443/tcp
sudo firewall-cmd --reload

방화벽 오픈 상태 확인

#열린 포트 확인
sudo firewall-cmd --list-all

👆 worker node 👆 master node

5. 네트워크 옵션 설정

리눅스 서버의 네트워크 기능을 쿠버네티스용 (= 컨테이너 통신용)으로 바꾸는 과정

br_netfilter

• 리눅스 서버는 기본적으로 물리적인 통신을 담당

• 하지만, 쿠버네티스는 서버 안에 가상 네트워크를 만들고, 그 안에서 Pod들이 통신하도록 함

• br_netfilter는 리눅스 커널의 bridge 레이어를 통과하는 패킷들을 iptables(방화벽/네트워크 규칙)이 검사할 수 있게 함

k8s.conf

• 컨테이너 간의 통신이 리눅스 방화벽 규칙을 따르도록 강제하는 설정

# /etc/modules-load.d/k8s.conf 파일 생성
sudo cat <<EOF | sudo tee /etc/modules-load.d/k8s.conf
br_netfilter
EOF
# /etc/sysctl.d/k8s.conf 파일 생성
sudo cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf
net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-iptables = 1
EOF
# 시스템 재시작 없이 stysctl 파라미터 반영
sudo sysctl --system

6. 컨테이너 런타임 설치

쿠버네티스는 컨테이너를 관리하는 오케스트레이션 플랫폼이기 때문에, 컨테이너 런타임을 별도로 설치해야한다.

세가지 방법이 존재하는데, 두번째 방법 (containerd만 설치해서 사용하는 방법을 선택했다)

1. docker 설치 시 Depends로 함께 설치되는 containerd 패키지 사용

2. containerd만 설치 사용

3. docker engine + cri-dockerd

Containerd 설치 후 사용

apt 업데이트 후 필수 패키지 설치

sudo apt-get update
sudo apt-get install -y apt-transport-https ca-certificates curl gnupg

공개키 다운로드 및 저장소 등록

공개키는 인터넷에서 파일을 다운로드할때, 해커가 심어놓은 악성코드인지 혹은 진짜 Docker인지 확인하기 위해서 사용함

#공개키 다운로드
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg
# 저장소 등록
echo "deb [arch=amd64 signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

containerd 패키지 설치

쿠버네티스의 표준 런타임

sudo apt-get update
#containerd 패키지 설치
sudo apt-get install containerd
#설치 확인
sudo systemctl status containerd

containerd config 설정

리눅스의 주인은 systemd 인데, 쿠버네티스의 kubelet도 자원관리를 위해 이 systemd를 사용하길 바람.

이 설정을 안해주면 컨테이너 런타임과 시스템이 충돌하게 됨.

#containerd 구성 파일 생성
sudo mkdir -p /etc/containerd
#containerd 기본 설정값으로 config.toml 생성
sudo containerd config default | sudo tee /etc/containerd/config.toml
#config.toml 파일 수정 SystemCgroup 설정을 true로 바꿈
vi /etc/containerd/config.toml
#수정사항 적용 및 재실행
sudo systemctl restart containerd

7. 쿠버네티스 클러스터 설치

필수 패키지 설치 및 구글 클라우드 공개키 다운로드 및 쿠버네티스 레포지토리 추가

sudo apt-get update
sudo apt-get install -y apt-transport-https ca-certificates curl gnupg
#공개 키 다운로드
curl -fsSLo /etc/apt/keyrings/kubernetes-archive-keyring.gpg https://dl.k8s.io/apt/doc/apt-key.gpg
#apt 저장소에 쿠버네티스 저장소 추가
sudo echo "deb [signed-by=/etc/apt/keyrings/kubernetes-archive-keyring.gpg] https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee /etc/apt/sources.list.d/kubernetes.list

쿠버네티스 패키지 설치

kubeadm : 클러스터를 구축(init, join)하는 도구

kubelet : 각 노드에서 컨테이너를 실제로 실행/관리함

kubectl : 사용자가 쿠버네티스에 명령을 내리는 도구

#저장소 추가되었기 때문에 apt 업데이트
sudo apt-get update
#쿠버네티스 패키지 설치
sudo apt-get install -y kubelet kubeadm kubectl
#쿠버네티스 패키지 버전 고정
sudo apt-mark hold kubelet kubeadm kubectl
#쿠버네티스 설치 버전 조회
kubelet --version
kubeadm version
kubectl version
#kubelet service 확인
sudo systemctl status kubelet.service

문제 발생

→ kubelet, kubeadm, kubectl 모두 설치됨

→ 하지만 kubelet.services가 안열림

대안책

Docker 저장소 정보 삭제하고 재설치

제대로 작동함을 확인 ! Master Node 구성

8. Control-Plane 구성 및 CNI 설정

Calico 기본 설정값 192.168.0.0/16

# default
kubeadm init
# calico
sudo kubeadm init --pod-network-cidr=192.168.0.0/16

netstat 보냈는데 답이 없음 = API 서버 죽어있음

API 서버가 죽어있어서, kubectl 설정 삭제하고 다시 작성함.

후에, CNI(container network interface) 설정 진행

*CNI (container network interface)

컨테이너 간의 네트워크를 제어할 수 있는 플러그인으로 컨테이너 런타임에서 컨테이너의 네트워크를 사용하게 하는 인터페이스임.

9. 최종 확인

# connection
nc -vz [ip] [port]
# master node의 kubeadm token create --print-join-command
# 알아온 ip, port, token, hash 값을 worker node에서 실행
# master node와 연동됨
sudo kubeadm join [ip] [port] [token] [hash]
# master node에서 연결된 node 확인
hostname -I

👆 worker node 👆 master node

• VMware에서 개발한 Hypervisor( 가상화 환경을 만들 수 있도록 최소한의 기능만을 지원하는 축소버전의 OS)
• Type1 Hypervisor (bare-metal, os에 종속되지 않고 하드웨어에 직접 설치되는 구조)

vCenter

• 가상화환경을 만드는 가장 큰 이유는 여러 컴퓨터를 하나의 큰 성능과 용량의 컴퓨터처럼 사용하기 위함

  ⇒ 이 기능을 지원하는 것이 vCenter

• vCenter는 가상화 환경 구축을 위한 핵심 소프트웨어 ESXi가 설치된 다수의 머신을 하나의 가상화환경으로 만들어주는 기능을 제공함

• vCenter를 이용해서 여러 ESXi 호스트들을 쉽게 추가/제거 할 수 있고, 그 외에도 vMotion, DRS&DPM과 같은 기능을 제공함

vSphere

• VMware의 정의에 따르면 엔터프라이즈 급 가상화 플랫폼임

• 위에 언급한 소프트웨어들을 전부 포함하고 있는 소프트웨어 패키지를 의미

  • Excel, Word= ESXi, vCenter
  • Microsoft Offic = vSphere

• 소프트웨어 정의 데이터센터 (SDDC)

  • 소프트웨어-정의 데이터 센터는 서버, 네트워크, 스토리지 그리고 기반 설비 등의 모든 인프라가 가상화됨
  • 데이터 센터의 제어 또한 소프트웨어에 의해 자동화 되는 것을 뜻함
  • vSphere은 가상 인프라 계층에서 ESXi 하이퍼바이저를 통해 서버 가상화 환경을 구현하고, 기능을 제공하는 분산 소프트웨어 시스템임
  • 단순히 호스트를 분할하여 사용하는 것이 아니라, 인프라 자원을 하나의 거대한 가상 컴퓨터로 통합해 자원을 효율성있게 분할하여 사용함

• 클라우드 환경

  • vSphere은 규모에 맞는 간편하고 효율적인 관리, 원활한 하이브리드 클라우드 환경을 제공하여 향상된 애플리케이션 성능을 제공하고 모든 클라우드의 기반을 만들어줌
  • 이를 통해서 IT 조직은 유연하고 안정적인 IT 서비스를 제공할 수 있음

vSphere 환경을 사전에 관리하는 방법

• VMware Skyline

  • 잠재적인 문제를 사전에 식별하고 해결 시간을 단축하기 위해 고객별 제품 사용 데이터를 자동으로 안전하게 수집, 집계 및 분석을 하는 기술

  • VMware Skyline Collector 라는 독립형 어플라이언스 기기를 설치해야함

    • 문제사항회피 : 잠재적인 문제를 사전에 식별하고, 문제가 발생하기 전에 해결해서 환경에 대한 신뢰성과 안정성 향상을 도모함
    • 문제해결시간단축 : 환경 별 데이터 기반 분석으로 문제 해결 시간을 단축함
    • 사용자 맞춤 추천 : 사용자 환경에 따른 해결방안을 제시함.

    ⇒ vSphere 구독시 기본으로 제공함

vSphere VMFS (가상 시스템 파일 시스템)

• 클러스터 파일 시스템
  • 클러스터 : 여러대의 컴퓨터들이 연결되어 하나의 시스템처럼 동작하는 집합
• 여러 ESXi 호스트가 공유 스토리지를 동시에 읽거나 쓸 수 있음을 뜻함 ⇒ 분산 스토리지 구조 제공

vSphere가 CPU, 메모리, 네트워크, Disk와 어떤 방식으로 상호작용하는가?

• 물리적 구성요소를 소프트웨어 구성 요소로 추상화 ⇒ 가상화 기술을 통해 상호작용

vCenter Server system과 ESXi hosts에 연결하기위한 사용자 인터페이스는 무엇이 있는가?

• vCenter Server System → vSphere Client
• ESXi hosts → VMware Host Client
  • vCenter Server를 사용할 수 없을 때, ESXi 호스트를 직접 관리하는데 사용할 수 있는 HTML5 기반 사용자 인터페이스

회사에서는 하나의 물리서버를 보다 효율적으로 사용하기를 바람 이런 필요에 의해 가상화 기술이 발전하게 됨 ⇒ VM이나 컨테이너와 같은 기술이 생김 물리적인 하드웨어를 논리적으로 구분하는 것 = 가상화 하나의 하드웨어에서 여러개의 시스템을 효율적으로 사용할 수 있게 해줌

가상화의 유형

가상머신 vm - 하이퍼바이저를 이용해 리소스 전체를 가상화하는 방법

컨테이너 container - OS 수준에서 프로세스를 컨테이너 형태로 격리하는 방법

⇒ virtual machine 은 물리적인 컴퓨터와 동일한 기능을 제공하는 소프트웨어 컴퓨터임

각 OS 마다 커널이 존재함

하드웨어를 제어하기 위한 명령어 : 커널

애플리케이션이 OS 커널에 요청을 보내는 방식이 다르고 (시스템 콜), 이를 하드웨어가 이해할 수 있는 CPU 명령어 셋으로 변환하는 과정이 필요함

Hypervisor은? -> 이때 !!! 각 OS 마다 말하는 명령을 하드웨어가 이해할 수 있게 하나의 명령어로 번역해줌

Windows - NT Kernel

Linux - Linux Kernel

mac - Darwin

프로그램과 하드웨어(CPU) 사이에 CPU에 직접적으로 명령을 실행하기 위한 함수 리스트가 존재함 (ex. Linux system call)

만약 프로그램에서 파일을 연다고 생각해보자.

프로그램 파일 열기 클릭

Kernel 파일 Open 함수 실행

CPU 내부적으로 파일을 여닫고 하는 과정들에 포함되는 명령어 셋들을 실행

=> OS 마다 차이가 발생하는 부분은 2번 과정

3번은 명령어 셋들이 호출되는 과정이 다를 뿐 최종적으로 CPU에 전달되는 명령어는 동일함

Hypervisor

VM과 하드웨어 간의 I/O명령을 처리하는 인터페이스

물리적인 하드웨어를 논리적으로 가상화하는 것을 담당하는 기술이 하이퍼 바이저

가상머신을 생성하고 구동하는 프로그램 (=가상머신 모니터) → 다수의 운영체제를 동시에 실행하기 위한 논리적 플랫폼

host(=ESXI에 리소스를 제공하는 물리적 컴퓨터)에서 여러 가상의 GuestOS(=VM에서 실행되는 운영체제)를 실행하기 위한 플랫폼

VM 위에 올라간 OS들의 명령을 하드웨어가 이해할 수 있게 하나의 명령어로 번역해주고, 반대로 각 OS들에게 하드웨어의 리소스들을 나눠주면서 조율해줌 (운용역할도 진행)

⇒ VMware를 설치하고 CentOS를 올렸다면, CentOS에서 명령들을 하드웨어와 중재하는 역할을 한다고 이해하면 될듯

추가로, PC에서 핸드폰용 Android Emulator, iOS Emulator을 돌릴때 혹은 x86_64 OS에서 ARM / ARM64 OS를 테스트하고 싶을 때 사용하기도 함.

Hypervisor Type

컨테이너

컨테이너의 시작은 화물을 어떻게 하면 효율적으로 옮길 수 있을까 → 표준화된 컨테이너 박스를 만들고, 무엇을 넣어도 표준화된 운송선만 있으면 똑같이 세워서 효율적으로 운송할 수 있음

이 컨셉을 IT에 적용한 것이 컨테이너

소프트웨어 코드, 애플리케이션 코드가 작동하기 위해 필요한 컴포넌트와 함께 표준화된 방식으로 패키징해서, 컨테이너 엔진만 있으면 돌아갈 수 있도록 하는 구조를 컨테이너라고 함.

⇒ 컴퓨팅 환경 간의 이식성이 높아짐

가상화 레이어 없어서 실행 속도가 프로세스 실행 수준으로 빠름

리눅스 커널의 기능인 Namespace(자원 격리), cgroups(자원 제한)을 사용해 프로세스 단위로 격리함

하이퍼 바이저로 구동된 OS는 각자 다른 Kernel을 가질 수 있음

컨테이너는 호스트와 동일한 커널을 사용함

하드웨어 → 하이퍼바이저 → 가상머신 (Guest OS Kernel + App)

하드웨어 → HostOS (Kernel) → container 엔진 (Docker) → Application

• credential

  • PaaS에서 접근할 때 가장 먼저 필요함

  • kubernetes API 서버에 접속 인증 정보

• cluster

  • kubernetes가 실제로 돌아가는 전체 인프라

  • 노드 (Contol Plane+Worker)의 집합
    → API Server/ Scheduler / Controller Manager / Nodes

• Namespace

  • 클러스터 내부 논리적 격리 공간

  • 멀티팀/ 멀티서비스 분리
    → 이름충돌방지/ 권한 분리

• Pod

  • Kubernetes의 최소 배포 단위

  • 1개 이상의 컨테이너 묶음 → 동일 IP 공유, storage 공유, 같이 스케줄링 됨

Public Cloud, Private Cloud, Hybrid Cloud에 대해서 알아보자

Public Cloud

• 누구나 함께 이용할 수 있도록 구축된 대규모 클라우드 서비스

• 사용자는 필요한 때에 필요한 만큼의 클라우드 자원을 할당받아 이용할 수 있도록 제공하는 서비스 방식

• 필요한 서버를 즉시 생성하여 이용할 수 있음

• 트래픽과 자원 사용량 증가 시 바로 확장이 가능한 확장성

• 저렴한 서비스 비용으로 인한 경제성

• 시스템 유지보수나 장애 대응을 위한 효율성과 같은 클라우드 서비스 장점에 최적화 된 서비스

• KT cloud, Amazon AWS, IBM SoftLayer과 같이 대중적인 클라우드 서비스를 제공하는 업체들의 서비가 공용클라우드에 속하며, 일반적인 웹 서비스나 게임, 동영상 서비스가 주로 공용 클라우드 환경으로 구성됨

Private Cloud

• 자사 내부에 직접 클라우드 인프라를 구축한 형태
• 클라우드 인프라에 대한 직접적인 통제 권한을 가진 클라우드 서비스 구축 방식을 말함
• 사설 클라우드를 구축하는 경우에는 보안을 위해 외부의 인터넷 망과 IT 인프라를 분리하거나, 운영 회사에서 원하는 형태로 보안 시스템과 내부 IT 인프라를 구성할 수 있음
• 그러나, 공용 클라우드와 달리 구성된 여유자원이 한정되어있어 자원의 필요량이 증가하면 확장에 제약이 있을 수 있음
• 추가로, 직접 구축을 해야하기 때문에, 클라우드 인프라를 관리하기 위한 관리 인력이 필요함
• 많은 기업과 공공기관들이 보안에 대한 민감도가 높은 IT 시스템을 운영하기 때문에 사설 클라우드를 구축함
• 주로 외부의 접속이 필요없이 회사 내부 서비스를 위한 그룹웨어, ERP와 같은 서비스들이 주로 사설 클라우드 환경임

Hybrid cloud

• 내부에 사설 클라우드를 구축하여 운영하다가 필요에 따라 외부의 공용 클라우드를 함께 이용하는 것을 일반적으로 하이브리드 클라우드라고 함.
• 여기에 기존의 물리 서버를 포함해 비즈니스 환경에 따라 공용, 사설, 물리 서버 중 두가지 이상의 클라우드를 혼용하여 구성하기도 함.
• 공용 서비스를 위한 웹, WAS 서버는 공용 클라우드를 이용하여 클라우드의 장점(비용과 확장성)에 최적화 시키고, 보안이 중요한 서버 (database와 같은 경우)들은 사설 클라우드 환경을 구성하여 외부의 직접적인 접속을 차단함
• 기존에 운영중이거나, 높은 성능을 필요로 하는 물리 서버들과 연동해 사용자의 요구에 맞는 최적의 인프라를 설계할 수 있는 장점 존재
• 외부 서비스와 보안이 모두 중요한 금융, 개인정보 취급 웹서비스, 교육, 시스템들이 하이브리드 클라우드 환경으로 구성됨

회사 코드에서 Client의 IP 주소를 가져오는 공통 유틸리티 메서드를 발견했다. 처음에는 단순히 request.getRemoteAddress()를 사용하면 클라이언트 IP를 얻을 수 있을 것이라고 생각했지만, 실제 코드를 살펴보니 여러 HTTP 헤더를 확인하는 비교적 복잡한 로직이 구현되어 있었다.

이러한 구현 방식이 필요한 이유를 살펴보던 중, 프록시 서버나 로드밸런서를 거치는 환경에서는 getRemoteAddress()만으로는 실제 사용자 IP를 확인하기 어렵다는 사실을 알게 되었다.

특히 최근의 서비스 환경에서는 Reverse Proxy, Load Balancer, API Gateway 등 여러 네트워크 계층을 거쳐 요청이 전달되기 때문에, 실제 클라이언트 IP를 확인하기 위해서는 추가적인 처리가 필요하다.

따라서 이번 글에서는 다음 내용을 정리해보고자 한다.

1. request.getRemoteAddress()로 실제 사용자 IP를 알 수 없는 이유

2. Proxy / Load Balancer 환경에서 요청이 전달되는 방식

3. X-Forwarded-For 헤더를 활용한 실제 Client IP 확인 방법

4. 실무에서 Client 정보를 처리하는 일반적인 방식

왜 getRemoteAddress()를 사용하지 않을까?

보통의 클라이언트 IP를 가져올때는 request.getRemoteAddress()를 사용한다. 하지만 실제 서비스 환경에서는 이 방법만으로는 사용자의 실제 IP를 확인하기 어려운 경우가 많다.

그 이유는 서비스 구조 사이에 여러 네트워크 장비가 존재하기 때문이다.

예를 들어 다음과 같은 구조를 생각해볼 수 있다.

Client 
   ↓
Load Balancer (L4/L7)
   ↓
Nginx (Reverse Proxy)
   ↓
Spring Boot Server

이 상태에서 서버가 request.getRemoteAddress()를 호출하면 실제 사용자 IP가 아니라 바로 앞 단계 장비의 IP가 반환된다.

즉 다음 중 하나가 반환될 가능성이 높다.

• Load Balancer IP

• Reverse Proxy IP

따라서 서버 입장에서는 실제 사용자 IP를 직접 알 수 없다.

그렇다면, 실제 Client IP는 어디에 있을까?

프록시나 로드밸런서를 거칠 경우, 실제 사용자 IP는 HTTP Header를 통해 전달된다.

대표적으로 다음과 같은 헤더들이 사용된다.

주요 Client IP 관련 헤더

• X-Forwarded-For

• 가장 표준적으로 사용되는 헤더이며, 프록시 서버를 거칠 때마다 IP가 누적된다.

X-Forwarded-For: clientIP, proxy1, proxy2

Proxy-Client-IP : Apache 등 특정 프록시 서버에서 사용되는 헤더

WL-Proxy-Client-IP : WebLogic 서버에서 사용하는 헤더

HTTP_CLIENT_IP : PHP 환경에서 사용되는 경우가 있음

마지막으로 위 헤더에 값이 없는 경우에만

request.getRemoteAddress()를 fallback 방식으로 사용하는 것이 일반적이다.

📌 ClientUtil 같은 유틸리티가 필요한 이유

이러한 이유 때문에 실무에서는 단순히 getRemoteAddress()를 호출하기보다 여러 헤더를 순차적으로 확인하는 공통 유틸리티 메서드를 사용하는 경우가 많다.

예를 들어 다음과 같은 방식이다.

X-Forwarded-For

Proxy-Client-IP

WL-Proxy-Client-IP

HTTP_CLIENT_IP

request.getRemoteAddress()

이 순서대로 값을 확인하여 실제 사용자 IP를 찾아내는 방식이다.

Client 정보 파싱 (IP / OS / Browser)

일부 서비스에서는 사용자 IP뿐 아니라 OS, Browser, Device와 같은 정보도 함께 파싱하기도 한다.

하지만 최근 실무에서는 이러한 로직을 직접 구현하기보다는 다른 방식으로 처리하는 경우가 많다.

브라우저와 디바이스 종류가 계속 증가하기 때문에 개발자가 직접 if-else 로직으로 관리하기에는 유지보수 비용이 너무 크기 때문에 그렇다고 한다.

실무에서의 일반적인 처리 방식

최근 서비스 환경에서는 다음과 같은 방식이 많이 사용된다.

1. API Gateway에서 처리

Kong API Gateway
Spring Cloud Gateway

Gateway에서 Client 정보를 파싱하여 전달

2. WAF (Web Application Firewall)

AWS WAF

보안 장비에서 Client 정보를 분석

3. 전문 라이브러리 사용

uap-java

User-Agent 파싱을 전문적으로 처리

정리

로드밸런서나 프록시 서버가 존재하는 환경에서는 request.getRemoteAddress()만으로 실제 사용자 IP를 확인하기 어렵다.

이러한 환경에서는 요청이 전달되는 과정에서 HTTP Header에 실제 Client IP가 포함되기 때문에 X-Forwarded-For와 같은 헤더를 활용하여 IP를 확인해야 한다.

따라서 실무에서는 다양한 헤더를 순차적으로 확인하는 공통 유틸리티 메서드를 사용하거나, API Gateway나 보안 장비에서 해당 정보를 처리하는 방식이 일반적으로 사용된다.

회사 프로젝트의 코드를 살펴보던 중 Service에서 HttpSession을 사용해 RSA 키를 생성하고 관리하는 로직을 발견했다. 하지만 현재 프로젝트는 Microservices Architecture(MSA) 구조로 구성되어 있으며, MSA에서는 일반적으로 Stateless(무상태성)을 지향한다는 점에서 의문이 생겼다.

HttpSession은 특정 서버의 메모리에 사용자 상태를 저장하는 방식인데, 서버가 여러 대로 구성된 환경에서는 요청이 다른 서버로 전달될 수 있기 때문에 세션 기반 로직이 정상적으로 동작하지 않을 가능성이 있다.

이러한 의문을 계기로 다음과 같은 내용을 정리해보고자 한다.

1. MSA 환경에서 HttpSession 사용이 왜 문제가 될 수 있는지

2. 세션 기반 인증과 JSON Web Token(JWT) 기반 인증의 차이

3. MSA 환경에서 인증 및 암호화 키 관리 대안

4. RSA 키를 세션 단위로 생성하는 방식의 한계와 대안

이를 통해 현재 코드 구조가 어떤 환경을 가정하고 작성되었는지 이해하고, MSA 환경에서는 어떤 방식으로 개선할 수 있을지 정리해보고자 한다.

기술적 고민을 시작한 이유

현재 회사 코드를 살펴보면서 한 가지 공통적인 설계 방향을 발견할 수 있었다.

인터페이스 / Impl 분리 → 구현체를 분리하여 유지보수와 확장성을 높이기 위한 객체지향 설계

MyBatis의 BaseVO / Interceptor 사용 → 반복되는 로직을 줄이고 공통 기능을 재사용하기 위한 구조

Stateless 구조 지향 → 서비스 확장성과 장애 대응을 고려한 MSA 아키텍처의 핵심 원칙

결국 이러한 기술적 선택들은 단순한 구현 방식의 차이가 아니라, “어떻게 하면 시스템을 더 쉽게 유지보수하고, 안정적으로 확장할 수 있을까?” 라는 고민에서 출발한다고 볼 수 있다.

따라서 나도 동일한 관점을 갖고, 발전시키고 싶은 부분에 대해 고민을 시작하였다.

MSA 환경에서 HttpSession 사용이 왜 문제가 될 수 있는지

현재 Service 코드에서는 HttpSession을 사용하여 RSA 키를 생성하고 관리하고 있다. 하지만 현재 프로젝트는 Microservices Architecture(MSA) 구조로 구성되어 있으며, MSA는 기본적으로 Stateless(무상태성)을 지향한다.

Stateless 구조에서는 특정 서버가 사용자 상태를 기억하지 않는다. 즉, 어떤 서버가 요청을 처리하더라도 동일한 결과를 반환할 수 있어야 한다.

하지만 HttpSession은 서버 메모리에 사용자 상태를 저장하는 방식이기 때문에, 서버가 여러 대로 구성된 환경에서는 문제가 발생할 수 있다. 예를 들어, 사용자의 요청이 로드밸런서를 통해 다른 서버로 전달될 경우 해당 서버에는 기존 세션 정보가 존재하지 않기 때문에 인증이나 암호화 과정에서 오류가 발생할 수 있다.

이러한 이유로 MSA 환경에서는 HttpSession과 같은 서버 의존적인 상태 관리 방식보다는, JSON Web Token(JWT)이나 공통 저장소 기반의 상태 관리 방식을 사용하는 경우가 많다. 예를 들어 인증 정보나 암호화 키를 Redis와 같은 중앙 저장소에서 관리하면 어떤 서버가 요청을 처리하더라도 동일한 데이터를 참조할 수 있다. 또한 보안 키 관리가 필요한 경우에는 AWS Key Management Service(KMS)와 같은 키 관리 시스템을 사용하는 방법도 있다.

현재 코드에서 HttpSession을 사용하는 이유는 몇 가지 가능성을 생각해볼 수 있다.

1. 초기에는 단일 서버 환경을 가정하고 작성된 로직일 가능성

2. MSA로 전환되는 과정에서 레거시 코드가 그대로 유지되었을 가능성

MSA 환경에서 안정적으로 확장하기 위해서는 세션 기반 상태 관리보다는 공통 저장소 기반의 상태 관리 구조로 전환하는 것이 필요하다.

세션 기반 인증과 JSON Web Token(JWT) 기반 인증의 차이

SESSION은 서버에서 기억해야한다면, JWT는 클라이언트가 기억하는것이다.

MSA 환경에서 인증 및 암호화 키 관리 대안

예시 1. 서버 다중화 환경에서의 세션 문제

현재 서버가 다중화된 환경이라고 가정해보자. 단일 서버 환경이라면 세션에 RSA 키를 저장하더라도 언제든지 동일한 서버에서 해당 키를 사용할 수 있다.

하지만 Microservices Architecture(MSA) 환경에서는 상황이 달라진다.

예를 들어 1번 서버에서 generateRsaKey를 호출하여 세션에 RSA 키를 저장했다고 가정해보자. 이후 암호화 요청이 발생했을 때 로드밸런서에 의해 요청이 2번 서버로 전달될 수 있다. 이 경우 2번 서버에는 해당 세션 정보가 존재하지 않기 때문에 RSA 키를 찾을 수 없고, 인증 또는 복호화 과정이 실패할 수 있다.

이 문제를 해결하기 위해 다음과 같은 방법을 사용할 수 있다.

• Sticky Session

• Session Clustering

하지만 이러한 방식은 특정 서버에 요청이 고정되거나 세션 동기화가 필요해지기 때문에 MSA의 유연성과 확장성을 떨어뜨릴 수 있다.

예시 2. 서비스 간 세션 공유 문제

또 다른 문제는 서비스 간 세션 공유가 어렵다는 점이다.

예를 들어 인증 서비스에서 HttpSession에 RSA 키를 저장했다고 가정하자. 하지만 해당 키는 다른 서비스에서 접근할 수 없다. 각 서비스는 서로 다른 물리적 서버나 컨테이너에서 실행되기 때문이다.

결과적으로 서비스 간에 암호화된 데이터를 주고받아야 하는 상황에서는 세션 기반 키 관리 방식이 의미를 잃게 된다.

MSA에서 권장되는 방식

이러한 이유로 MSA에서는 서버 세션에 의존하는 방식 대신 무상태(Stateless) 구조를 지향한다.

무상태 구조에서는 서버가 사용자 상태를 기억하지 않기 때문에 어떤 서버가 요청을 처리하더라도 동일한 결과를 반환할 수 있어야 한다.

따라서 인증 및 상태 관리를 위해 다음과 같은 방식이 사용된다.

JSON Web Token(JWT) → 인증 정보를 서버 세션이 아닌 토큰 자체에 포함하여 클라이언트가 보관

Redis 기반 중앙 저장소 → 인증 정보나 암호화 키를 모든 서버가 접근할 수 있는 공통 저장소에 관리

RSA 암호화가 필요한 경우

만약 서비스 로직에서 RSA 암호화가 필요한 경우에는 HttpSession 대신 공유 저장소 기반 구조를 사용하는 것이 바람직하다.

예를 들어 Redis 기반 공유 세션, 공통 데이터베이스 기반 키 저장 또는 Key Management System(KMS) 과 같은 방식을 활용하면 어떤 서버가 요청을 처리하더라도 동일한 키에 접근할 수 있다.

RSA 키를 세션 단위로 생성하는 방식의 한계와 대안

현재 코드에서는 HttpSession을 사용하여 RSA 키를 생성하고 세션에 저장하는 방식으로 암호화를 처리하고 있다. 하지만 이러한 방식은 MSA 환경에서는 여러 가지 한계를 가진다.

먼저, 세션 기반으로 RSA 키를 관리할 경우 특정 서버의 메모리에 키가 저장되기 때문에 서버가 여러 대로 구성된 환경에서는 동일한 키를 공유하기 어렵다. 사용자의 요청이 로드밸런서를 통해 다른 서버로 전달될 경우 해당 서버에는 기존 세션 정보가 존재하지 않기 때문에 암호화 또는 복호화 과정에서 문제가 발생할 수 있다.

또한 세션마다 RSA 키를 생성하는 방식은 성능 측면에서도 비효율적일 수 있다. RSA 키 생성은 비교적 비용이 큰 연산이기 때문에 요청이 많아질수록 서버에 불필요한 부하가 발생할 수 있다.

실제 서비스 환경에서는 애플리케이션 레벨에서 RSA 암호화를 직접 처리하기보다는, HTTPS(SSL/TLS)와 같은 표준 보안 프로토콜을 활용하는 것이 일반적이다. HTTPS는 전송 구간에서 이미 강력한 암호화를 제공하기 때문에 대부분의 경우 애플리케이션에서 별도의 RSA 키를 생성하여 관리할 필요가 없다.

만약 서비스 내부 로직에서 암호화 키 관리가 필요하다면 다음과 같은 방법을 고려할 수 있다.

공통 저장소 기반 키 관리 → Redis와 같은 중앙 저장소를 활용하여 여러 서버가 동일한 키에 접근할 수 있도록 구성

키 관리 시스템(KMS) 활용 → 보안 키를 전문적으로 관리하는 시스템을 통해 안전하게 키를 저장하고 사용할 수 있음

결과적으로, MSA 환경에서는 특정 서버의 세션에 의존하는 방식보다는 모든 서버가 동일한 정보를 공유할 수 있는 구조를 사용하는 것이 중요하다. 또한 가능하다면 애플리케이션 코드에서 직접 암호화를 구현하기보다는 인프라 레벨의 표준 보안 프로토콜을 활용하는 것이 더 안정적이고 효율적인 방법이라고 볼 수 있다.

정리

이번 내용을 정리해보면, MSA 환경에서는 서버 세션에 의존하는 방식이 확장성과 안정성 측면에서 한계를 가질 수 있다. 따라서 인증 정보나 암호화 키는 특정 서버에 종속되지 않는 방식으로 관리하는 것이 중요하며, Redis와 같은 공통 저장소나 KMS와 같은 키 관리 시스템을 활용하는 방법을 고려할 수 있다. 또한 대부분의 경우 애플리케이션 레벨의 암호화보다는 HTTPS와 같은 표준 보안 프로토콜을 활용하는 것이 더 효율적인 선택이 될 수 있다.

회사에서 IntelliJ 환경을 초기 설정한 후 프로젝트를 빌드하는 과정에서 Nexus에 접근하지 못해 빌드가 실패하는 문제가 발생했다.

의존성 라이브러리를 내려받는 과정에서 문제가 발생한 것으로 보였고, 이를 계기로 Sonatype Nexus Repository(Nexus)가 어떤 역할을 하는지 알아보게 되었다.

Nexus Repository란?

• 메이븐 사용하면 pom.xml 파일로 jar 파일 다운받아옴
• Nexus는 메이븐에서 사용할 수 있는 Repository.
• 외부 의존을 덜고, local nexus(cache)로 사용함으로써 빠르게 라이브러리 끌어올 수 있음.
  • 한번 다운로드받은 dependency는 로컬에 저장되나, 컴퓨터를 포맷하거나 새롭게 시작하는 상황에서는 설정을 해야함

Nexus Repository 특징

• 회사/단체의 화이트 리스트로 인해 외부 repository에 접속하기 어려운 프록스 역할
• 비상시 외부 인터넷이 느리거나 repository가 다운되는 상황에서도 빠른 다운 가능
• 현재 maven에 올라와있지 않은 자료들을 효율적으로 관리 가능
• 서버에도 동일한 설정을 해줘야함으로 서버 구조 복잡하면 잔업도 늘어남
• 예외 파일로 인한 설정이 줄어들어 일관성 증가함

주의사항

한번 다운 받은 Nexus는 로컬에 반영구적으로 저장되나, 새롭게 시작하는 상황에서는 설정 필요

참고자료

https://m.blog.naver.com/qhdqhdekd261/221827574154

지금까지 프로젝트를 진행하면서 데이터베이스를 사용할 때는 주로 Jakarta Persistence API(JPA)를 사용해왔다. 하지만 이번 프로젝트에서는 처음으로 MyBatis를 사용하게 되었다. MyBatis는 SQL을 직접 작성하여 데이터베이스와 연동하는 방식이라는 점에서 JPA와 차이가 있다. 이번 글에서는 MyBatis의 기본 개념과 동작 방식에 대해 정리해보고자 한다.

MyBatis란 ?

• 자바 애플리케이션에서 데이터 베이스와 상호작용하는데 사용되지만, 접근방식과 특징이 많이 다름

• 여기서의 상호작용 : 저장/조회

• SQL Mapper 기술

• 개발자가 작성한 SQL 실행 결과를 객체에 매핑

  💡 Mybatis

• SQL Mapper 프레임 워크

• 직접 SQL 작성

• 반복적인 SQL 작성 필요

• 복잡한 SQL 제어에 유리

JPA란 ?

• ORM (Object Relational Mapping)

• DB에 자동으로 매핑해주는 프레임 워크

💡 JPA

- Java persistence API, 객체 - 관계 매핑 표준
- JPQL 또는 메서드 이름 기반 쿼리
- 영속성 컨텍스트, JPQL 학습 필요
- CRUD 자동화로 생산성 높음
- 객체 중심 설계에 적합

JPA vs MyBatis 아키텍처 비교

[JPA]
Controller (REST API 받음)
    ↓
Service (비즈니스 로직)
    ↓
Repository (인터페이스만, 구현체 자동 생성)
    ↓
Entity (객체 ↔ 테이블 자동 매핑)
    ↓
Database

[MyBatis]
Controller (REST API 받음)
    ↓
Service (비즈니스 로직)
    ↓
Mapper (인터페이스) + XML (SQL 작성)
    ↓
DTO/VO (데이터 전달 객체) -> model/도메인/dto, vo 존재 
* DAO는 DB접근담당이고
* DTO는 계층간 데이터 전달용
    ↓
Database

JPA 특징

• JPA = Java Persistence API는 자바 표준 ORM(Object - Relational Mapping) 기술
• 객체지향 프로그래밍 방식으로 데이터베이스와 상호작용 할 수 있도록 설계
• JPA를 사용하면 SQL 대신 Entity를 통해 데이터 처리 가능

• 대표 구현체 : Hibernate, EclipseLink, OpenJPA
• 특징 :
  • 데이터베이스 테이블과 자바 객체를 매핑해 객체 지향적으로 데이터 관리
  • JPQL(Java Persistence Query Language) 라는 쿼리 언어 사용
  • 영속성 컨텍스트 (Persistence Context) 를 통해 데이터 변경 사항 자동으로 추적

@Entity 
public class User {
    @Id
    @GeneratedValue
    private Long id;
    private String name;
}

MyBatis 특징

• SQL Mapper 프레임 워크, SQL 쿼리를 직접 작성하면서도 자바 객체와 매핑할 수 있는 기능 제공
• SQL 작성의 자유도 보장, 복잡한 쿼리나 데이터베이스 특화 기능을 활용하기 좋음

<select id="findUserById" parameterType="Long" resultType="User">
    SELECT * FROM users WHERE id = #{id}
</select>

• JDBC 프로그래밍 단순화하고 불필요한 Boilerplate 코드 제거하고 Java 소스코드에서 SQL문을 별도의 XML로 저장해 이를 연결함

• 동적 SQL 생성 기능
  • MyBatis 는 Boilerplate 코드 제거 및 SQL 문 분리 외에도 동적인 SQL 생성 기능을 제공해 프로그램 실행 중에 입력되는 파라미터에 따라 서로 다른 SQL문을 동적으로 생성함

MyBatis 사용 순서와 예시

1. 스프링 프로젝트 생성 후 필요한 의존성 추가

   • 아마 미리 추가 되어있었을 것
   • spring-core
   • spring-jdbc
   • mybatis
   • mybatis-spring

2. DB 설정

   • JDBC로 DB연결을 하기에 DB 연결 정보 설정해야함

   • properties나 XML에 DataSource 등록

     <bean id="dataSource" class="org.springframework.jdbc.datasource.DriverManagerDataSource">
      <property name="driverClassName" value="com.mysql.jdbc.Driver"/> // mysql 드라이버
      <property name="url" value="jdbc:mysql://localhost:3306/mydatabase"/> // mysql 사용
      <property name="username" value="username"/> // 아이디 
      <property name="password" value="password"/> // 비밀번호 
     </bean>

3. MyBatis 설정

   • MyBatis XML 설정 파일 만들고 필요한 설정 추가

     <bean id="sqlSessionFactory" class="org.mybatis.spring.SqlSessionFactoryBean">
      <property name="dataSource" ref="dataSource"/>
      <property name="configLocation" value="classpath:mybatis-config.xml"/>
     </bean>
     
     <bean id="sqlSession" class="org.mybatis.spring.SqlSessionTemplate">
      <constructor-arg ref="sqlSessionFactory"/>
     </bean>

4. MyBatis Mapper 작성과 등록

   • Mapper = DB 쿼리 ↔ 자바 메서드()를 매핑하는 역할

   • 데이터 베이스에 접근하기 위한 SQL 쿼리를 작성하고, 이를 실행하는 자바 메서드 정의함

     ⇒ 정리하자면 XML에 SQL 쿼리들을 작성할 건데 그 SQL이 연결된 메서드를 정의할 파일

     ex) CRUD 쿼리문을 XML에 작성하고. InsertItems(), Getitems(), modifyItems(), DeleteItems() 메서드가 있는 인터페이스 만들거임. 그리고 그 클래스를 Mapper라는 명칭으로 부르자 !

     @Mapper // 등록 
     // 작성
     public interface UserMapper {
      User getUserById(int id);
      void insertUser(User user);
      void updateUser(User user);
      void deleteUser(int id);
     }

5. Mapper 인터페이스와 연결될 XML 작성

   • Mapper 메서드() 별로 SQL 쿼리문을 작성함

     <mapper namespace="com.exmaple.mapper.UserMapper">
       <select id="getUserById" parameterTytpe="int" resultType="com.example.model.User">
       SELECT * FROM users WHERE id = #{id}
       </select>
       <insert id="insertUser" parameterType="com.example.model.User">    
       INSERT INTO users (name, email) VALUES (#{name}, #{email}) 
       </insert>  
     
       <!-- 다른 메서드들에 대한 쿼리도 추가할 수 있다 -->
     
     </mapper>

6. Mapper 사용

   • Mapper 인터페이스를 스프링 Bean으로 등록하고 주입받아 사용함

     @Service
     public class UserSerivce {
       priate final UserMapper userMapper;
     
       public UserService(UserMapper userMapper){
           this.userMapper = userMapper;
       }
     
     // 유저 조회
     public User getUsedById(int id){
        return userMapper.getUserById(id);
     }
     // 유저 등록
     public User insertUser(User user){
        return userMapper.insertUser(user);
     }

현재까지 프로젝트를 진행하며 프로젝트 관리 도구로 Gradle만 사용해봤는데, 현재 회사 프로젝트에서는 Maven으로 프로젝트 관리 도구를 사용하기에 Gradle, Maven이 무슨 역할을 하는지 알아보고, 이 둘을 비교해보려고 한다.

Maven 이란?

• 자바용 프로젝트 관리 도구 → 프로젝트를 빌드, 패키지, 배포등의 역할을 수행하고 각종 라이브러리를 관리함
• 아파치 라이센스로 배포되는 오픈소스 소프트웨어 (Ant 대안)
• 2개의 설정 파일을 통해 관리 가능 → setting.xml pom.xml
  • setting.xml 은 메이븐 툴과 관련 설정 파일
  • pom.xml
    • 자바 프로젝트의 빌드 툴로 메이븐을 설정했다면 생성될 것
    • 프로젝트에 필요한 라이브러리를 정의하는 공간 (해당 라이브러리가 작동하는데 필요한 다른 라이브러리 자동으로 설치

Maven 빌드 순서 (Life Cycle)

• 메이븐은 미리 정의하고 있는 빌드 순서가 있음. → 라이프 사이클

1. Default(=Build) : 소스코드 컴파일. 컴파일 성공하면 target/classes 폴더가 만들어지고 컴파일 된 class 파일 생성
   • target 폴더 = 빌드 결과물이 위치
   • 즉 최종적으로 배포 가능한 WAR/JAR 폴더가 생성됨 (6번 참고)
2. Clean : 빌드 후 생성된 target 삭제 → 생성된 파일 삭제한다
3. Validate : 프로젝트가 올바른지 확인하고, 필요한 모든 정보를 사용할 수 있는지 확인
4. Compile : 프로젝트의 소스코드를 컴파일 하는 단계
5. Test : 유닛 (단위) 테스트를 수행하는 단계 (테스트 실패시 빌드로 처리, 스킵 가능)
6. Package : 실제 컴파일 된 소스코드와 리소스들을 jar, war 과 같은 파일등의 배포를 위한 패키지로 만드는 단계 → 타켓 directory 만듦
7. Verify : 통합 테스트 결과에 대한 검사를 실행하여 품질 기준을 충족하는지 확인
8. Install : 패키지를 로컬 저장소에 설치하는 단계, Package와 다른 점은 로컬 저장소에 있는 다른 프로젝트 들이 접근이 가능하다.
9. Site : 프로젝트 문서와 사이트 작성, 생성하는 단계
10. Deploy : 만들어진 package를 원격 저장소에 release 하는 단계

→ 코드를 수정한 후 package하면 오래걸림

→ 오래걸리니 target 파일의 코드를 바꾸게 하면 package를 할 필요가 없음

→ 무지성 clean → package

Maven 라이브러리 저장 장소 (pom.xml)

• maven은 필요한 라이브러리를 pom.xml 에 저장함 ⇒ 프로젝트 모델링

<modelVersion>4.0.0</modelVersion>
<groupId>com.회사이름</groupId>
<artifactId>모듈이름</artifactId> <!-- jar, war 파일 이름을 의미 -->
<version>artifact의 버전</version> <!-- 0.0.1-SNAPSHOT = 아직 개발 중 -->
<packaging>artifact의 포맷</packaging>

<properties>...</properties> <!-- 값을 가진 상수 ${propertyname} 이런식으로 참조 가능  -->

<repositories>...</repositories> <!-- 라이브러리 받아올 저장소 지정  -->

<dependencies>...</dependencies>
<!-- 의존성은 POM에서 가장 중요함 (일관성 있는 프로젝트에 필수)
Maven은 dependencies 요소에 명시된 의존성을 자동 다운하고,
해당 의존성이 의존하는 또다른 의존성(transitive dependencies) 까지 가져 옴
외부에서 jar 파일을 일일이 다운받아 관리하던 것에비해 매우 개선됨-->

<build>...</build> <!-- 플러그인 목록  -->

그렇다면 빌드란 무엇인가 ?

Maven이 자바 기반 프로젝트를 관리하는 도구라는 것을 알게 되었다. Maven은 프로젝트를 빌드하고, 패키징하며, 배포하는 과정을 관리하고 필요한 라이브러리 의존성까지 효율적으로 관리해준다. 그렇다면 여기서 말하는 빌드(Build)란 무엇일까?

• 빌드
  • 소스코드 혹은 프로젝트에 쓰인 각각의 파일 및 자원을 JVM이나 WAS가 인식할 수 있는 구조로 패키징하는 과정 및 결과물을 의미
• 빌드 관리 도구 (Build Tool)
  • 프로젝트 생성, 테스트 빌드, 배포 → 를 위한 전용 프로그램
  • 소스코드를 실행 가능한 어플리케이션으로 만들어주는 도구
  • if 라이브러리가 계속 늘어나거나, 라이브러리 버전 동기화가 어렵다 ? → build tool이 해소
  • 다시 말해 빌드 과정을 자동화해서 관리해주는 역할
• 특징
  • 빌드 도구의 특징은 개발자가 스크립트를 작성해 다양한 작업을 수행할 수 있게 함
  • 소스코드를 컴파일, 패키징 할 수 있으며 테스트를 자동으로 수행하거나 의존성 주입 및 배포 작업을 할 수 있음
  • 종류에 따라 스크립트 작성시 사용하는 문법이 다르긴 하나 일반적으로 XML 혹은 특정 도메인 언어를 사용함
  • 빌드 도구 종류에는 Ant Maven Gradle 이 있음

💡 빌드 자동화란 ?

1. 종속성 다운로드

2. 소스코드를 바이너리 코드로 컴파일

3. 바이너리 코드를 패키징

4. 테스트 실행

5. 프로덕션 시스템에 배포

를 스크립팅하거나 자동화하는 행위 

Gradle이란 ?

• Maven 을 대체할 수 있는 프로젝트 구성 관리 및 범용 빌드 툴
• Ant Builder 와 Groovy script를 기반으로 구축되어 기존 Ant 역할 + 배포 스크립 기능 모두 사용 가능
• 스프링 부트와 안드로이드에 사용
• 빌드 속도가 Maven에 비해 10~100배 빠름, Java, C/C++, Python을 지원
• XML 사용안함, JVM위에서 동작하는 Groovy나 Kotlin을 통해 작성함
• Maven의 pom.xml은 선언형으로 설정하는 정적인 문서인 반면, Gradle의 build.gradle은 스크립트로 작성하는 동적인 소스 파일
• 즉, Maven은 정적인 문서와 엄격한 규칙으로 인해 어떤 설정이 필요할 때 한계가 있으나 Gradle은 로직을 넣을 수 있으니 한계가 필요없음. → 필요하다면 로직에 플러그인을 호출하거나 직접 코드를 짜면됨

정리하자면,

Groovy는 JVM에서 실행되는 스크립트 언어

JVM에서 동작하지만, 소스코드를 컴파일 할 필요없음

Java와 호환되며, Java class file을 Groovy class로 사용 가능함

Java와 문법 유사 

Gradle 특징

1. 가독성이 좋다 : 코딩에 의한 **간결한 정의**가 가능하므로 가독성이 좋다.
2. 재사용에 용이 : 설정 주입 방식(Configuration Injection)을 사용하므로 재사용에 용이하다.
3. 구조적인 장점 : Build Script를 Groovy 기반의 DSL(Domail Specific Language)를 사용하여 코드로서 설정 정보를 구성하므로 구조적인 장점이 있다.
4. 편리함 : Gradle 설치 없이 Gradle wrapper를 이용하여 빌드를 지원한다.
5. 멀티 프로젝트 : Gradle은 멀티 프로젝트 빌드를 지원하기 위해 설계된 빌드 관리 도구이다.
6. 지원: Maven을 완전 지원한다.

Maven vs Gradle

1. 스크립트 길이와 가독성 면에서는 Gradle이 우세하다

2. Build와 테스트 실행 결과 Gradle이 더 빠르다

• Gradle은 캐시를 사용하기 때문에 테스트 반복 시 실행 결과 시간의 차이가 더 커진다

3. 의존성이 늘어날 수 록 스크립트의 품질의 차이가 커진다

• Maven은 멀티 프로젝트에서 특정 설정을 다른 모듈에서 사용하려면 상속 받아야하지만, Gradle은 설정 주입 방식을 사용하므로 멀티 프로젝트에 적합하다

지금까지 진행했던 프로젝트는 대부분 동아리나 개인 프로젝트 형태였기 때문에, 하나의 애플리케이션 중심으로 개발을 진행하는 경우가 많았다. 하지만 현재 회사에서 진행 중인 프로젝트는 각 기능을 모듈 단위로 분리하여 여러 개의 애플리케이션으로 구성되어 있다. 이러한 구조를 Microservices Architecture(MSA) 라고 한다. 이번 글에서는 MSA의 개념과 특징에 대해 정리해보고자 한다.

MSA 기반 모듈이란?

• Microservices Architecture
• 마이크로 서비스 아키텍처로 설계된 독립적인 서비스 단위를 의미
• 하나의 큰 애플리케이션을 작고 독립적인 서비스들로 쪼개는 아키텍처 방식을 의미함

모놀리식 vs MSA

[모놀리식 - 전통 방식]
┌─────────────────────────┐
│  하나의 큰 애플리케이션      │
│  - 회원 관리              │
│  - 주문 처리              │
│  - 결제 처리              │
│  - 상품 관리              │
└─────────────────────────┘
→ 한 부분만 수정해도 전체 재배포

[MSA - 마이크로서비스]
┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐
│회원 서비스 │  │주문 서비스 │  │결제 서비스 │  │상품 서비스 │
└──────────┘ └──────────┘ └──────────┘ └──────────┘
→ 각각 독립적으로 개발/배포/운영

MSA 특징

각 모듈(서비스)은:

• 독립적인 데이터베이스 보유
• 독립적인 배포 가능
• 다른 언어/기술 사용 가능 (회원은 Java, 결제는 Python 등)
• API로 통신 (REST API, gRPC 등)
• 독립적인 확장 (주문 서비스만 서버 추가 가능)

실제 예시

쿠팡 같은 서비스:
- 회원 모듈 (로그인, 회원가입)
- 상품 모듈 (상품 검색, 상세)
- 주문 모듈 (장바구니, 주문)
- 결제 모듈 (결제 처리)
- 배송 모듈 (배송 추적)
- 리뷰 모듈 (상품 리뷰)

→ 각각 별도 팀이 개발/관리

장단점

장점:

• 부분 수정/배포 용이
• 장애 격리 (결제 오류가 검색에 영향 X)
• 기술 선택 자유
• 팀별 독립 개발

단점:

• 복잡도 증가
• 분산 시스템 관리 어려움
• 서비스 간 통신 오버헤드
  • 처리 시간 및 메모리가 추가적으로 사용되는 현상을 의미
    • 원래 A처리는 3초걸리는데 안정성을 위해 B처리 10초로 진행
    • 이때의 오버헤드는 7초
  • 기존의 단일 Application인 Monolithic과 MSA의 정보 교환 방식은 근본적으로 다름
  • 모놀리식 → 같은 메모리 공간을 쓰기 때문에, 단순히 함수를 호출하고 데이터가 담긴 메모리 주소값만 넘기면 됨.
  • MSA → 서비스가 서로 다른 서버에 존재. 정보를 주려면 데이터를 패킷으로 쪼개서 네트워크(HTTP, gRPC)를 타고 옆 동네로 넘어가야함
    • 추가로 다른 애플리케이션이기때문에 인증 및 인가도 매번 증명해야하며,
    • 데이터 일관성을 유지하는데에 어려움 → 트랜잭션 하나로는 안됨. 2PC, Saga패턴과 같은 복잡한 로직을 사용해야함

기업에서 사용하는 규모가 큰 자바 프로그램을 더 쉽게 만들 수 있게 도와주는, 가볍고 오픈소스로 제공되는 미리 만들어준 코드의 뼈대를 제공하는 프로그램 개발 도구 (프레임워크)

-> Spring을 사용한다는건 Frame안에서 work를 한다고 할 수 있음

API란?

프레임워크가 미리 구성된 것을 가져와서 사용한다는 의미에서 API와도, 라이브러리와도 비슷한 느낌이 들어 셋의 정확한 개념을 알고 있는 것이 중요하다.

API는 애플리케이션 프로그래밍 인터페이스의 약자로 interface라는 이름에서 알 수 있듯 2개 이상의 소프트웨어 컴포넌트 사이에서 상호작용 할 수 있도록 정의된 인터페이스를 의미함

-> 즉, 소프트웨어 애플리케이션이 서로 데이터를 주고 받으며 통신할 수 있도록 만들어진 일련의 규칙이자 약속이라 할 수 있음.

라이브러리란?

라이브러리는 프로그램 개발에 필요한 함수, 클래스, 객체들을 모아둔 도구 상자와 같음

-> 라이브러리의 제어권은 개발자에게 있음. 단순히 필요한 기능을 제공할 뿐임

IoC?

Inversion of Control

-> 라이브러리의 제어권은 개발자에게 있음 -> but, 프레임워크의 제어권은 프레임워크에 있음

따라서, 개발자가 프레임워크가 정해둔 규칙과 구조에 맞게 코드를 작성하고 삽입하면, 실제 실행 흐름은 프레임워크가 관리함

이를 우리는 제어의 역전이라고 부름

즉, spring은 제어의 역전에 해당하는 프레임워크임

제어의 역전

그렇다면 우리가 왜 제어의 역전에 대해 이해하고 있어야하는지 궁금할 것 같음

위에 계속 언급했듯, 프로그램의 제어 흐름을 개발자가 직접 제어하는 것이 아니라 외부에서 관리하는 것을 제어의 역전이라고 함

일반적인 프로그램을 작성할 때는 객체의 생성, 설정, 초기화, 메서드 호출, 소멸까지의 모든 과정을 개발자가 직접 제어해야 함. -> 애플리케이션의 실행 흐름, 생명주기는 모두 전적으로 개발자가 관리하는 구조임

But, 프레임 워크를 사용하면 객체의 생명 주기를 모두 프레임 워크에 위임함.

제어의 역전에서는 오브젝트가 스스로 사용할 오브젝트를 결정하지도 생성하지도 않음

DI란?

Dependency Injection = 의존성 주입

-> IoC가 제어권을 외부로 넘긴다면, 이를 실행하기 위해 DI를 사용함

DI는 객체가 필요로 하는 것(=종속성)을 직접 만들지 않고 외부에서 주입받는 방식을 의미함

토비의 스프링에서는 다음의 세 가지 조건을 충족하는 작업을 의존관계 주입이라고 말함. 1. 클래스 모델이나 코드에는 런타임 시점과 의존관계가 들어나지 않음. 즉, 인터페이스에만 의존하고 있어야 함. 2. 런타임 시점의 의존관게는 컨테이너나 팩토리와 같은 제 3의 존재가 결정함. 3. 의존관게는 사용할 오브젝트에 대한 래퍼런스를 외부에서 주입해주며 만들어짐.

여기서 객체를 생성하고 관리하며 의존관계를 연결해주는 컨테이너를 우리는 IoC 컨테이너 혹은 DI 컨테이너라고 부름 -> 객체가 생성자 인수, 메서드에 대한 팩토리 메서드에서 생성되거나 반환된 후에 객체 인스턴스에 설정된 속성을 통해서만 종속성을 정의하는 프로세스라고 보면 됨.

정리해보면,

1. 객체가 자기 안에서 필요한 것들을 직접 만들지 않고,
2. 생성자 인자, 메서드, 혹은 팩토리 메서드를 통해 외부에서 만들어진 것을 전달받아 사용함
3. 전달 받은 후에는 객체 안에서 설정된 속성을 통해서만 종속성을 사용함

그렇다면 종속성은 무엇인가 .. ?

의존성이란 한 객체가 다른 객체에 기능이나 데이터를 필요로 하는 관계를 의미 -> 즉 한 객체는 다른 객체없이 제대로 동작할 수 없는 상태

외부로부터 의존성 주입하는 것이 왜 필요한가 ?

개발 상황에서는 객체를 마주했을때 서로 의존되어있는 경우가 대다수임. 독립적으로 존재하는 객체도 존재할 수 있으나, 로직을 구현하면서 필연적으로 서로 의존성을 지닌 경우가 많을 것임

ex1) RegularCoffeeBean을 커피 원두로 사용 -> 원두 일체형

public static class RegularCoffeeBean{
        public void grind() {
        System.out.println("기본 원두로 갈고 있습니다");
    }
}

public static class CoffeeMachine {
    private RegularCoffeeBean regularCoffeeBean;

    public CoffeeMachine() {
        this.regularCoffeeBean = new RegularCoffeeBean();
    }

    public void brew() {
        regularCoffeeBean.grind();
        System.out.println("기본 원두로 커피를 내립니다.");
    }
}

ex2) 원두 분리형

// 인터페이스
public interface CoffeeBeans {
    void grind();
}

// 인터페이스 구현하는 구현체 클래스
@Component("regularBean")
public static class RegularCoffeeBeans implements CoffeeBeans {
      @Override
    public void grind() {
        System.out.println("기본 원두로 갈고 있습니다");
    }
}

// 원두 종류 바꾸고싶을땐? 구현체 클래스를 또 만들면 됨
@Component("decafBean")
public static class DecafCoffeeBeans implements CoffeeBeans {

      @Override
    public void grind() {
        System.out.println("디카페인 원두로 갈고 있습니다");
    }
}

// 커피머신
@Component
public static class CoffeeMachine {

        @Autowired
        @Qualifier("decafBean")
    private CoffeeBeans coffeeBeans;

    public void brew() {
        coffeeBeans.grind();
        System.out.println("원두로 커피를 내립니다.");
    }
}

원두일체형은 강한 결합 원두분리형은 느슨한 결합이라고 할 수 있음 -> 각 객체끼리 의존성이 존재할 때 의존성을 외부에서 주입받는 것이 바람직 함.

서블릿

자바 서블릿은 웹페이지를 동적으로 생성하는 서버 측 프로그램을 의미함

기존의 서버는 정적인 자료만을 주고 받고 있었음. 웹이 다양한 기능을 요구하게 되면서 사용자의 요구에 맞춘 동적인 페이지를 만들 필요가 생김 -> 이를 위해 만들어진 것이 서블릿 !

1. WS (Web Server)
- 웹서버를 뜻하며 주로 정적인 컨텐츠 (HTML, img ..)를 클라이언트에 전달함
- 요청 -> 응답 (대부분 HTTP) 
- 정적인 웹페이지 처리에 최적화
- 동적인 처리 (데이터 베이스 접근 불가) 
- Apache HTTP Server, Nginx 존재

2. WAS (Web Application)
- WAS는 웹 애플리케이션 서버라고 부르며, 동적인 웹 서비스를 처리함
- 클라이언트 요청 -> 서버 측에서 로직 처리 -> 결과 응답
- DB 접근, 비즈니스 로직 실행 가능
- 주로 Servlet, JSP, Spring 등 동적인 웹 서비스 제공 가능
- Tomcat, JBoss, WebLogic, Spring Boot embedded Tomcat 존재

서블릿 동작 방식 : 범용

서블릿 동작 방식 : 스프링

Servlet Container란?

서블릿 객체를 생성, 초기화, 호출, 종료하는 생명주기의 담당함.

Servlet이 어떤 역할을 수행하는 메뉴얼이라면, Servlet Container는 클라이언트의 요청을 받아주고 응답할 수 있게 웹 서버과 Socket으로 통신하며 직접 핸들링한다고 볼 수 있음.

클라이언트의 요청이 들어오면 ...
서블릿 컨테이너는 web.xml을 기반으로 사용자가 요청한 URL이 어느 서블릿에 대한 요청인지 찾음

그렇다면 web.xml은 무엇인가?
-> 웹 애플리케이션의 배치 파일로 서블릿, 필터, 리스너 등 웹 구성 요소의 설정 정보를 정의하는 환경설정 파일임
-> 여기서 정의된 서블릿과 URL 매핑 정보를 확인하고, 매핑된 서블릿이 있으면 해당 서블릿으로 전달하고, 서블릿이 처리한 응답을 브라우저로 보내줌.

본래 네트워크를 통한 소통을 위해서는 Socket을 만들고 listen(), accept(), connect()를 통해 구현해야함. 하지만 servlet 컨테이너는 이러한 기능을 api로 제공하여 간편화 함

-> 우리는 servlet으로 구현해야 할 비즈니스 로직에 대해서만 집중하면 되는 것임 !!!

스프링에서의 DI, IoC, Servlet

Bean

빈은 Spring 컨테이너가 관리하는 자바의 객체를 의미함. Spring은 Bean을 통해 객체를 인스턴스화한 후, 객체 간의 의존관계를 관리함. 객체가 의존관계를 등록할 때, Spring 컨테이너에서 해당하는 빈을 찾고, 그 빈과 의존성을 만들게 됨.

일반적인 자바를 사용하는 경우

public class UMC9thMember {
        private int age;
        private String nickname;
        private String school;
        private String studyPart;

        public UMC9thMember(){            
        }

        public UMC9thMember(int age, String nickname, String school, String studayPart) {
                this.age = age;
                this.nickname = nickname;
                this.school = school;
                this.studyPart = studyPart;
        }
}

// 여기서 객체를 생성하기 위해서는 
// new 생성자 사용 -> 개발자가 전적으로 생명주기, 의존성 관리 진행

UMC9thMember umc9thMember = new UMC9thMember(23, "마크","상명대학교", "Server(SpringBoot)");

Bean을 사용하는 경우

@Component → @Autowired : 묵시적 빈 정의

• 클래스에 어노테이션을 추가하고, Autowired로 다른 클래스에서 해당 Bean을 끌어온다.
• @Controller, @Service, @Repository를 사용하면 그 자체로 묵시적 빈 정의를 한 것이라고 볼 수 있음.

@Configuration → @Bean : 명시적 빈 정의

• Spring 설정 파일에 Configuration 어노테이션을 추가하고, Bean 어노테이션을 붙여 명시적으로 빈을 지정한다.
• 스프링 라이브러리에 없는 외부 라이브러리에서도 Bean 생명주기를 사용할 수 있음.

1. Spring Context란?

Spring Context 란 빈(Bean) 객체들을 생성하고 관리하는 스프링의 핵심 컨테이너이다.

• Bean: 스프링이 관리하는 객체 (Controller, Service, Repository)
• Container: Bean의 생명주기, 의존성 주입 등을 관리하는 스프링 내부 시스템
• Context: Bean 등록, 조회, 설정 등을 처리하는 객체 = ApplicationContext

2. 예외처리 위치

예외처리는 도메인에서 처리하는 것이 좋을까, 서비스에서 처리하는 것이 좋을까

도메인에서 처리할 수 있는 예외는 도메인에서, 그 외에는 서비스에서 처리하는 것이 좋다. -> 최대한 더 낮은 계층에서 처리하는 것을 원칙으로 삼자.

시간 객체의 시간 값에 null이 들어왔다 -> 도메인에서 예외처리 시간 객체의 시간 값은 중복이면 안된다 -> 도메인 객체만으로는 안되고 저장된 다른 객체를 봐야함 -> 서비스에서 예외처리

3. Controller -> Repository 직접 의존

[Controller] ↓ 요청 전달 / 응답 반환 [DTO] [Service] ↓ 비즈니스 로직 처리 [Repository] ↓ DB 접근 [Domain] ↔ DB 매핑

+) [Exception] : 예외처리 +) [View] : 화면에 보이는 것

이와 같은 관계를 갖고 애플리케이션은 설계되는데, Controller 는 요청/응답 처리에 집중해야하며, Repository는 DB 접근에 집중해야함. 또한, 비즈니스 로직은 Service에서 진행해야함.

-> 이 부분 제발 좀 ... 지키자 희정아 ... ✅ 설계 시작 전에 계층별 책임 적어보기 "이건 Service 책임인가?" 먼저 생각하기 ✅ 단위 테스트 작성 비즈니스 로직은 Service에서 테스트할 수 있어야 함 ✅ 객체 간 의존 구조 그려보기 간단한 UML, 화살표 그리기 등으로 시각화 ✅ Controller에서 로직이 길어지면 "서비스로 옮길 수 있지 않을까?" 되묻기

4. @Autowired 없이도 작동 ?

public class ReservationController {
    private final ReservationService reservationService;

    @Autowired
    public ReservationController(ReservationService reservationService) {
        this.reservationService = reservationService;
    } 

-> 이 코드에서는 @Autowired 없이도 작동 가능함. Spring 4.3부터 클래스에 생성자가 하나 뿐이라면, 자동으로 주입가능한 Bean을 찾아서 주입함. 당연히, 생성자 2개 이상일 때는 생략하지 않아도 됨.

5. 상태코드 메서드

ResponseEntity
.status(HttpStatus.CREATED)
.location(location)
.body(ReservationResponse.from(savedReservation));

↓

ResponseEntity
.created(location)
.body(ReservationResponse.from(savedReservation));

로 축약할 수 있음.

+) ok = 200 created(URI) = 201 accepted() = 202 noContent() = 204 badRequest() = 400 notFound() = 404

6. 삭제를 의도했는데 삭제가 되지 않은 상황의 예외처리는 서비스에서 !

• TimeController

  boolean deleted = timeService.deleteTime(id);
        if (!deleted) {
            return ResponseEntity.badRequest().build();
        }

  본래 Controller에서 단순 삭제 성공 여부만 판단하고 있다고 생각하여 Controller에 예외처리 로직을 작성하였는데, 삭제 실패와 같은 비즈니스 로직 실패는 Service에서 다루는 것이 맞는 방식이다.

따라서, 말씀해주신대로, 삭제 실패 -> Service 성공 흐름 -> Controller 나머지 예외는 exception에서 처리하는 것으로 수정하였다.

<수정 후>

1. Controller는 성공한 흐름만 다룸

   @DeleteMapping("/{id}")
    public ResponseEntity<Void> deleteTime(@PathVariable Long id) {
        timeService.deleteTime(id);
        return ResponseEntity.noContent().build();
    }

2.Service에서 예외 표현함(비즈니스 로직 예외)

public boolean deleteTime(Long id) {
        if(!timeRepository.deleteById(id)) {
            throw new InvalidTimeException("없는 시간입니다." + id);
        }
        return timeRepository.deleteById(id);
    }

7. 도메인에 setter

도메인 객체에 setter를 열어두는 것은 객체 상태를 마음대로 바꿀 수 있어, 캡슐화에 어긋나고, 객체 불변성 유지에 어려워짐.

보통 도메인 객체를 수정해야하는 경우 서비스 클래스에서 도메인 객체를 받아 서비스 클래스에서 상태 변경을 수행하고, 변경된 도메인 객체를 Repository에 저장하는 방식을 사용할 것 !

8. validation 꼭. 유효성 검증 꼬옥 !!!

까먹지 말긔 ...

9. LocalTime vs String

1. LocalTime

• 타입 안정성: 시간 정보를 명확한 타입으로 표현해서, 시간 연산(더하기, 빼기 등)을 안전하게 수행 가능
• 유효성 검사 내장: 잘못된 시간 값(예: 25:00)은 생성 자체가 안 됨
• 표준 API 지원: 포맷팅, 파싱, 비교, 계산 등 편리한 메서드 제공
• 명확한 의미 전달: 변수 타입만 보고도 시간 정보임을 알 수 있음
• DB 매핑 주의 필요: JDBC에서 LocalTime 직접 매핑이 안 될 수 있어, java.sql.Time으로 변환 필요
• 직렬화/역직렬화 설정 필요: JSON 직렬화 시 기본 String 포맷 지정 필요(예: HH:mm:ss)

2. String

• 단순 저장/전송: 포맷을 문자열로 자유롭게 표현 가능 (예: "10:00", "10시", "10:00 AM")
• 빠른 구현: 복잡한 타입 변환 없이 바로 사용 가능
• 유효성 검사 어려움: "25:00", "abc" 같은 잘못된 시간 값도 들어갈 수 있음
• 시간 연산 불가: 시간 더하기 빼기 등 로직 작성 시 문자열 파싱 필요
• 타입 의미 모호: 그냥 문자열이어도 시간으로 처리 가능

1. Model

• 애플리케이션의 핵심 비즈니스 데이터와 로직을 담은 영역
• 도메인 객체 또는 Entity 클래스가 위치

2. View

• 사용자에게 데이터를 보여주는 부분 (ex) JSON
• Controller로 받은 데이터를 시각적으로 표현

3. Controller

• 사용자에게 요청을 받아서 처리하고, 응답을 반환함
• 주로 Service를 호출해서 비즈니스 로직을 수행

-> 여기까지가 MVC 설계 패턴 but, 스프링과 같은 현대 프레임워크에서는 구조를 더욱 세분화해서 유지보수성과 확장성을 높임. Service Repository DTO Domain Exception 을 알아볼 것.

4. Service

• 비즈니스 로직을 담당
• Controller, Repository 사이의 중간다리 연결
• 트랜잭션 처리, 여러 Repository 조합 호출 등의 로직 수행

5. Repository

• DB와 직접적으로 통신함 (DAO 역할)

6. DTO

• Data Transfer Object
• 데이터 전달용 객체
• 주로 Controller <-> Service 사이에서 사용
• Domain과 분리해 API 요청/응답용 포맷을 정리함
• Validation 이나 보안 목적에서도 중요

7. Domain(또는 Entity)

• 애플리케이션의 핵심 객체
• 불변성, 도메인 규칙을 중심으로 구성

8. Exception

• 예외를 세분화해서 정리
• 예외를 명확하게 분리하여 에러메세지 처리와 로깅을 쉽게 함

[Controller] ↓ 요청 전달 / 응답 반환 [Service] ↓ 비즈니스 로직 처리 [Repository] ↓ DB 접근 [Domain] ↔ DB 매핑

소프트웨어로 해결하고자 하는 문제 영역을 의미

ex) 온라인 서점 : 소프트웨어로 해결하고자 하는 문제 영역 -> 이 도메인에서는 하위 도메인으로 상품조회, 구매, 결제, 배송 추적의 기능을 제공 -> 하위 도메인은 다른 하위 도메인과 연결되어 완전한 기능을 제공 -> 도메인이 제공할 모든 기능을 구현해야 하는 것은 아님 (결제와 같은 기능은 외주 가능)

즉, '도메인'은 우리가 만들고자 하는 대상이 되는 소프트웨어(문제영역)이며, 도메인 설계는 우리가 만들고자 하는 소프트웨어에 어떤 기능을 제공할지, 어떠한 데이터 구성을 가질지, 각 기능간의 관계를 어떻게 할지를 설계하는 것을 의미함.

MVC

MVC 모델은 웹 애플리케이션에서 요청과 응답을 효과적으로 처리하는 패턴 클라이언트의 요청을 Controller -> Service -> Repository -> Database의 흐름으로 처리하고, 결과를 View로 반환해 클라이언트에게 보여준다고 볼 수 있음

MVC 아키텍처

1. Model

• 애플리케이션의 데이터 및 비즈니스 로직을 담당
• 데이터 베이스와 직접적으로 연결되며, Service 계층을 통해 Controller에서 데이터를 가져옴
• 데이터와 데이터가 동작하는 방식을 제공

2. View

• 클라이언트에게 보여줄 화면을 담당
• HTML, JSP, Thymeleaf, React를 사용해 데이터를 표현
• 데이터의 표현 (화면에 보여줌)

3. Controller

• 사용자의 요청을 받아 처리하고, 적절한 데이터를 Model에서 가져와 View로 전달
• @Controller @RestController를 사용해 구현
• 모델과 뷰의 연결고리

예를들면,

1. 사용자가 애플리케이션과 컨트롤러에 최초 처리를 요청
2. 모델에서 데이터 갱신, 생성, 삭제 조작함
3. 모델은 결과를 컨트롤러에 전달
4. 컨트롤러는 뷰에 결과를 전달하여 결과적으로는 뷰가 사용자에게 응답 보여줌

-> 사용자가 요청을 하면 모델에서 조작하고 결과를 데이터 컨트롤러에 전달. 컨트롤러는 뷰에 전달해 응답 보여줌.

책임과 의존성

유연성 있는 소프트웨어를 개발해야함. (다양한 요구사항의 변화에 대처하기 위해) 이는 책임과 의존성과 깊은 연관이 있음.

책임 : 객체가 수행해야하는 역할이나 기능을 의미 의존성 : 어떤 객체가 다른 객체에 기능을 위임하거나 사용할 때 발생

ex) class A 가 class B에 기능을 요청할 경우, A는 B에 의존하고, B는 특정 기능 수행에 대한 책임을 가짐. 좋은 설계란, 책임을 잘 나누고, 동시에 의존성을 낮추는 구조를 의미함.

그렇다면 도메인과 뷰를 왜 분리해야하는가?

-> 관심사의 분리 때문에

도메인은 무엇을 할 것인가를 담당하고, 뷰는 어떻게 보여줄 것인가를 담당.

분리를 통해 재사용, 단위 테스트의 용이성, 유지보수하기 편리, 뷰를 여러가지로 확장해도 도메인을 사용가능해 확장성, 개발 업무의 영역이 분리되어 협업의 효율이 올라간다는 장점이 있음.

뷰로 도메인이 넘어간다면?

뷰에서 핵심 도메인을 처리한다면 다양한 문제 발생 가능함.

1. 로직 중복 : 뷰마다 로직을 구현하면 여러 곳에 같은 로직 반복
2. 버그 발생 가능성 증가 : 로직이 뷰마다 다르게 동작할 수 있음.
3. 테스트 어려움 : 로직이 UI에 묻혀있어 테스트 불가능 하거나 복잡.
4. 유지보수 어려움 : 뷰가 바뀔때마다 로직 수정해야함.

도메인이 뷰를 참조하는 것은 괜찮은가?

도메인은 뷰를 몰라야 함.

-> 도메인은 순수한 소프트웨어 로직이기 때문에 어떠한 UI에서도 독립적으로 존재해야 함. -> 도메인이 뷰를 알게되면, UI변경시 도메인에 영향 줌. -> 도메인 로직을 재사용할 수 없고, 결합도가 높아져 유지보수 어려움.

CSRF 이용자를 속여서, 의도하지 않은 요청에 동의하게 만드는 공격을 의미합니다. 그럴듯한 웹 페이지를 만들어서 이용자의 입력을 유도하고, 이용자가 값을 입력하면 이를 은행이나 중요한 포털사이트로 전송해 스스로 이동한 것 같은 요청을 발생시킵니다. 다시 정리해서 말하면 임의의 이용자의 권한을 이용해 임의의 주소에 HTTP 요청을 보낼 수 있는 취약점입니다.

이용자가 HTTP 요청을 보내도록 하는 방법은 다양하게 존재합니다.

CSRF동작 CSRF 공격에 성공하기 위해서는 공격자가 작성한 악성 스크립트를 이용자가 실행해야합니다. 이는 공격자가 이용자에게 메일을 보내거나, 게시판에 글을 작성해 이용자가 조회하도록 유도합니다. HTML 혹은 Javascript을 통해 공격 스크립트를 작성할 수 있으며 아래 사진 및 코드는 HTML로 작성한 스크립트의 예시입니다. 혹은