IPMI는 표준화된 메세지 기반의 하드웨어 관리 interface로, 서버나 장비의 전원 상태, 하드웨어 이상 유무등을 네트워크를 통해 원격으로 모니터링하거나, 직접 제어할 수 있는 기능을 제공한다. IPMI 기능이 탑재된 메인보드나 BMC(Baseboard Management Controller)를 이용하여 운영체제와는 독립적으로 하드웨어를 직접 관리할 수 있다.

즉, 서버 전원의 on/off 여부와 상관없이, 운영체제가 제대로 동작하지 않아도, 기타 문제가 생겨 접속이 불가하더라도 IPMI로 조작할 수 있다. 당연히 모든 문제가 발생해도 IPMI를 사용할 수 있다는 것을 의미하지는 않으나, BMC에 문제가 생기지 않고 서버에 전력이 공급되고 있다면, 대체로 IPMI를 사용할 수 있다.

그렇다면, IPMI를 왜 사용해야하는가?

→ 물리적 접근이 어려운 상황에서의 관리 편의성

서버 랙 셋업, 네트워크 설치, OS 설치 및 IP 할당과 같은 서버 랙 세팅을 해야할 경우, 문제가 발생할 때마다 서버실을 직접 방문해 수정해야한다. 또한, 여러 노드에 OS를 설치해야할 때, 각 노드에 모니터를 연결하고, 부팅 USB를 꽂고, 키보드를 직접 연결한 후 OS를 설치해야하는 번거로움이 있다.이 번거로움을 IPMI는 해결한다. 서버에 접근할 때 물리적인 접근이 필요하지 않게 IPMI는 도와준다.

IPMI 주요 기능

1. 전원 제어

   서버가 응답하지 않는 상황에도 물리적으로 서버실에 갈 필요없이 IPMI를 통해 재부팅 명령을 내릴 수 있다.

   원격 전원 제어가 가능하다.

2. 콘솔 접근

   서버 앞에 직접 모니터와 키보드, 마우스를 연결한 것처럼 원격에서 서버 화면을 보고, 서버를 조작할 수 있다.

   원격 Media Mount가 가능하기 때문에, 내 로컬 PC에 존재하는 파일(ex. iso)을 서버의 가상 드라이브로 인식시켜 운영체제 설치나 복구를 진행할 수 있다.

3. 하드웨어 모니터링

   CPU 온도, 팬 속도, 전압, 전력 사용량과 같은 정보를 실시간으로 모니터링 할 수 있다.

   하드웨어 오류나 일정 온도 이상등의 이벤트 발생시 로그 확인이 가능하고, 미리 지정된 관리자에게 알림을 보낼 수 있다.

4. 펌 웨어/ BIOS 관리

   BMC나 BIOS를 최신 버전으로 업데이트 하거나, 설정을 변경할 수 있다.

IPMI 설치 과정

https://charliekim.tistory.com/6 를 참고하여 설치를 진행했다.

우선 IPMI를 이전에 만들어둔 vm 환경에 설치해서 확인해보려고 한다. 하지만, vm이기때문에 당연히 물리적 하드웨어가 조회되지 않아 IPMI를 설치할 수 없는 환경이다.

이 경우에는 OpenIPMI의 ipmisim을 사용하거나, VirtualBMC(vBMC)를 사용하거나, QEMU/KVM IPMI 애뮬레이션을 통해 IPMI를 소프트웨어적으로 시뮬레이션 할 수 있다고 한다.

VirtualBMC(vBMC)

vBMC 는 리눅스 KVM 기반 가상머신에 대해 가짜 BMC 기능 (IPMI 프로토콜 제공)을 구현해준다.

보통 vBMC이 사용되는 사례는 다음과 같다.

• 베어메탈 프로비전이 기능 개발 및 테스트에 활용하는 Openstack Ironic 개발 및 테스트 진행

• 실제 장비 없이 BMC(IPMI) 인터페이스를 연동해야하는 IPMI 자동화 실습

• 교육용, 데모, PoC 환경에서 사용

• 가상 환경에서 자동화된 인프라 테스트 진행시 사용

필자의 경우 VirtualBMC(vBMC)을 사용해 실습을 진행하였다.

vBMC 설치

기본적으로 설치해야하는 설치 패키지

sudo apt update
sudo apt install python3-pip python3-venv ipmitool
sudo apt install pkg-config
# 하이퍼 바이저 설치 
sudo apt install -y qemu-kvm libvirt-daemon-system libvirt-clients bridge-utils virt-manager

python 가상환경 생성 및 활성화

시스템 영향 최소화를 목적으로 가상환경을 생성해 진행한다.

# python 가상환경 생성 (시스템 영향 최소화를 목적으로)
python3 -m venv --system-site-packages /opt/virtualbmc
# python 가상환경 활성화 
source /opt/virtualbmc/bin/activate

가상환경 내부에 virtualBMC를 설치

# 가상환경 안에 virtualBMC 설치
/opt/virtualbmc/bin/pip3 install virtualbmc
# 제대로 설치되었는지 확인
vbmc --version

하이퍼 바이저 상태 확인

# 서비스 시작
sudo systemctl start libvirtd
# 부팅 시 자동 시작 설정
sudo systemctl enable libvirtd
# 상태 다시 확인
sudo systemctl status libvirtd

실습용 VM (IPMI를 설치할 VM) 생성 및 vbmc에 등록

# 실습용 VM 생성하기
virt-install --name hee \
--ram 128 \
--disk none \
--boot network \
--os-variant ubuntu22.04 \
--graphics none \
--dry-run --print-xml > hee.xml

# XML 설정을 바탕으로 VM 등록
virsh define hee.xml

# 현재 사용중인 가상머신을 vbmc에 등록
vbmc add hee --port 6230 --username admin --password admin

vBMC 활성화

# BMC 활성화
vbmc start hee

# 리스트 확인 
vbmc list 

vbmc list에 실습용으로 생성한 vm이 보이면 준비 완료 !

IPMI 명령어로 제어 실습

ipmitool을 설치한다.

sudo apt install ipmitool -y

전원 상태 확인, 전원 켜기 끄기

# 1. 현재 전원 상태 확인 (아마 off일 겁니다)
ipmitool -I lanplus -H 127.0.0.1 -p 6230 -U admin -P admin chassis power status

# 2. 전원 켜기
ipmitool -I lanplus -H 127.0.0.1 -p 6230 -U admin -P admin chassis power on

# 3. 다시 상태 확인 (on으로 바뀌었는지 확인!)
ipmitool -I lanplus -H 127.0.0.1 -p 6230 -U admin -P admin chassis power status

vBMC는 가상으로 BMC 시뮬레이션을 진행한 것이기 때문에 아래의 실습은 진행이 불가하였다. (값을 가져올 수 없으므로) 다만, 실제 상황에서는 사용이 가능하여 자주 사용되는 명령어를 몇가지 정리해보았다.

• 하드웨어 센서 모니터링 (온도, 팬 속도, 전압 상태)

  • 서버 내부의 온도, 팬 속도, 전압 상태를 실시간으로 확인할 수 있음.

ipmitool -I lanplus -H 127.0.0.1 -p 6230 -U admin -P admin sdr list

• 시스템 이벤트 로그 확인 (SEL)

  • 하드웨어 수준에서 발생한 모든 경고 기록을 확인할 수 있음. OS가 부팅되기 전의 에러도 기록됨.

ipmitool -I lanplus -H 127.0.0.1 -p 6230 -U admin -P admin sel list

• 시리얼 터미널 접속 (Serial Over LAN)

  • 서버에 모니터 연결 안해도 네트워크를 통해 텍스트 기반의 부팅 화면이나 콘솔을 직접 확인 가능

ipmitool -I lanplus -H 127.0.0.1 -p 6230 -U admin -P admin sol activate

• 식별용 LED 제어

  • 수많은 랙 중 작업해야할 장비가 무엇인지 알려줌

ipmitool -I lanplus -H 127.0.0.1 -p 6230 -U admin -P admin chassis identify force

하나의 NIC가 여러 IP를 가지는 원리 
물리적 랜카드는 하나여도, OS는 이를 논리적으로 쪼개서 인식할 수 있음.
Secondary IP  : 하나의 인터페이스에 여러개의 IP 주소를 할당 
Sub-Interface : 인터페이스를 가상으로 나눔 → 물리적으로 하나, 논리적으로는 완전 분리 

OS 레벨에서의 트래픽 구분
VM 혹은 서버 내부로 패킷이 들어오면, OS 커널은 
L3에서 패킷 헤더의 Destination IP 확인 후 내 Secondary IP 중 하나와 일치하면 패킷 수용
L4에서 Port 번호 확인 후, 해당 포트를 열고 기다리는 프로세스에게 데이터를 전달

포트 충돌 해결
동일 IP에서 동일 Port를 동시에 사용할 수 없어서, 다중 IP 나누어 동일 포트를 할당함

트래픽 분리
멀티 테넌트 (여러 고객이 한 인프라 공유)  환경에서 필수적
VXLAN (가상 터널링), 보안 그룹

개념

포트포워딩

공유기, 공유네트워크는 공인 IP를 가지며, 우리가 공유기, 공유 네트워크에 연결해서 사용하는 핸드폰과 같은 기기의 IP는 사설 IP로 사용한다. 따라서, 공인 IP의 몇번 포트로 신호가 들어오면, 공인 IP와 연결된 내부의 누군가에게 전달을 해야하는데, 이때 필요한 것이 포트포워딩이다.

NAT 기술은 공인 IP를 사설 IP로 변환하는 기술로, 포트포워딩을 이해하기 위해 필요한 개념이다.

포트포워딩 테이블은 8080포트는 내부 IP의 80번 포트로 보낸다 와 같은 규칙을 가지고 있다.

다중 IP를 VM에 부여하는 이유

다중 IP를 VM에 부여하는 이유는 다양하다.

1. 포트 중복을 회피하기 위함

보통 웹서비스는 HTTP/HTTPS의 80, 443 포트를 사용하는데, IP가 하나라면 한 서비스가 하나의 포트를 점유했을 경우 다른 서비스는 8080과 같은 생소한 포트를 사용해야한다. 따라서, VM에 다양한 서비스가 존재한다면 서비스별로 IP를 나누고 포트 번호를 80, 443을 사용할 수 있도록 한다.

2. 서버 장애 대응

서버 장애 발생시 서비스용 IP를 따로 만들어두었다면, 메인 서버에 장애가 생겼을시, 그 IP를 즉시 대기중인 다른 서버로 옮길 수 있다.

3. 트래픽 분산

서버로 드나드는 데이터의 성격에 따라, 외부 사용자가 접속하는 IP와 내부 관리자가 백업/모니터링을 위해 사용하는 IP를 분리해 관리용 트래픽이 폭주해도 실제 서비스 트래픽에 영향을 주지않으며, 방화벽도 IP 별로 다르게 지정할 수 있어서 안전하다.

VM 다중 IP 할당 및 컨테이너 포트 포워딩

준비사항

• VM 1대 (Vmware Workstation) / cpu-2core, mem-4GB, DISK-20GB

  • Ubuntu 24.04
  • 테스트 컨테이너 test-nginx1
  • 테스트 컨테이너 test-nginx2

• 설치

  • docker gnu
  • docker compose
  • nginx

NGINX 컨테이너 2대 실행

• 프로젝트 파일 생성
  • html 파일 (nginx1, nginx2) + log 파일 생성

• docker compose 파일 작성

  • 프로젝트 파일 하단에 생성

    version: '3.7'
    services:
    nginx1:
    container_name: test-nginx1
    image: "nginx:latest"
    restart: always
    volumes:
    - /var/log/nginx:/var/log/nginx # log파일의 위치
    - ./html/index1.html:/usr/share/nginx/html/index.html # index1.html 위치  
    environment:
    - TZ=Asia/Seoul
    networks:
    mynet1:
      ipv4_address: 192.168.1.10
    

  nginx2: container_name: test-nginx2 image: "nginx:latest" restart: always volumes:

  • /var/log/nginx:/var/log/nginx # log파일의 위치
  • ./html/index2.html:/usr/share/nginx/html/index.html # index2.html 위치 environment:
  • TZ=Asia/Seoul networks: mynet2: ipv4_address: 192.168.2.10

networks: mynet1: driver: bridge ipam: driver: default config: - subnet: 192.168.1.0/24

mynet2: driver: bridge ipam: driver: default config: - subnet: 192.168.2.0/24

- docker 실행

docker-compose up -d



### rc.local

- rc.local
    - 리눅스 시스템에서 부팅시 자동으로 실행되는 스크립트 파일 중 하나로, 사용자 지정 명령이나 스크립트를 포함할 수 있는 장소로 사용되며, 실행 권한이 없으면 서버 재가동시 스크립트가 실행되지 않는다.

// 상태 체크 systemctl status rc-local systemctl start rc-local systemctl enable rc-local systemctl list-unit-files | grep rc.local // enable 확인

### 다중 포트 할당

- rc.local 실행 권한 부여 및 실행

chmod +x /etc/rc.local

systemctl start rc-local.service

- 그래픽 모드 아닌, 멀티 유저 모드로 부팅시 서비스 파일에 부팅 모드 설정 및 실행
    - `/usr/lib/systemd/system/rc-local.service`

#제일 하단에 추가 후 저장 [Install] WantedBy=multi-user.target

rc-local서비스 자동 실행 등록

systemctl enable rc-local.service

- 추가 IP 부여

서버가 부팅될때마다 아이피 추가 하는 명렁어 작성

vi /etc/rc.local

vm에 아이피 부여

ip addr add 192.168.130.234/24 dev ens33

재시작

systemctl restart rc-local.service

 ![](https://velog.velcdn.com/images/_030702/post/30eaac84-9d47-418b-8cfa-fb09871e4f88/image.png)




### 네트워크 설정 파일 수정

- 설정 파일 이름 확인
    - cd /etc/netplan 으로 확인
- 설정 파일 수정
    - 추가 IP 를 하단에 작성

![](https://velog.velcdn.com/images/_030702/post/c0061781-93d6-4ed1-94db-be4539c0c9ae/image.png)


- 네트워크 재시작
    - systemctl restart NetworkManager


## VM IP 별 포트 포워딩 설정

- 경로
    - 192.168.11.133 / TCP 80 → test-nginx1 / TCP 80
    - 192.168.130.134 / TCP 80 → test-nginx2 / TCP 80

- 포트포워딩 등록
    - /etc/rc.local 에 작성
![](https://velog.velcdn.com/images/_030702/post/36deb4c9-d0c2-437d-86aa-28f44cbcd3a7/image.png)

- 포트포워딩 등록 순서
    - nat 테이블에 192.168.11.133:80으로 들어오는 패킷을 192.168.1.10:80으로 nat 포워딩하는 rule을 추가.
    - 192.168.1.10:80인 TCP 패킷이 서버를 Forward할때, 이를 허용하는 rule을 추가
    - nat 테이블에 192.168.130.134:80으로 들어오는 패킷을 192.168.2.10:80으로 nat 포워딩하는 rule을 추가
    - 192.168.2.10:80인 TCP 패킷이 서버를 Forward할때, 이를 허용하는 rule을 추가

- 포트포워딩 된 ip 주소 조회 및 네트워크 포워딩 조회

포트포워딩 된 ip 주소 조회

iptables -t nat -L -n -v

네트워크 포워딩 조회

iptables -L -n -v

iptables rule 조회

iptables -L

nat 테이블 조회

iptables -t nat -nL

### Nginx 설정 파일 수정으로 IP 별로 다른 화면 나오도록 수정

- /etc/nginx/sites-available/default

map $server_addr $display_file { 192.168.11.133 index_133.html; 192.168.130.134 index_134.html; default index.html; }

server { ... index $display_file; ... }

- nginx 재가동



### 결과
![](https://velog.velcdn.com/images/_030702/post/2d74b9b3-e21c-4771-892c-14dd22ce40e9/image.png)



### 참고자료

https://m.blog.naver.com/anjae83/222064015099 

https://fehoon.tistory.com/103 

https://velog.io/@watervottle/linux-%EC%84%9C%EB%B2%84%EC%9D%98-%EC%83%81%ED%83%9C-%ED%99%95%EC%9D%B8top-free-m-df-Th 

@Slf4j
static class Hello {
    public String callA() {
        log.info("callA");
        return "A";
    }
    public String callB() {
        log.info("callB");
        return "B";
    }
}

@Test
void reflection0 {
        Hello target = new Hello();

    log.info("start"); // 부가기능
    String result1 = target.callA(); // 핵심기능
    log.info("result = {}", result1); // 부가기능

    log.info("start");
    String result2 = target.callB();
    log.info("result = {}", result2);
}

이 예시코드에서는 부가 기능 사이에 핵심 기능이 있고, 해당 핵심 기능은 계속해서 변화하기에 메서드로 따로 빼내기에 애매하다.

// 이렇게 쪼개면...
void logStart() { log.info("start"); }
void logResult(String result) { log.info("result = {}", result); }

// 쓸 때는 여전히 중복이 남고 지저분합니다.
logStart();
String result1 = target.callA();
logResult(result1);

logStart();
String result2 = target.callB();
logResult(result2);

예를들어 메서드로 따로 뺀다 하더라도 이렇게 중복이 남고 지저분한 코드가 완성된다.

따라서, 해당 문제를 해결하기 위해 리플렉션을 사용한다. 클래스와 메서드의 정보를 빼내어 동적으로 사용하는 방식이다.

@Test
void reflection1() throws ClassNotFoundException, NoSuchMethodException,
            InvocationTargetException, IllegalAccessException {

    // 경로로 클래스의 메타정보를 가져와 리플렉션 객체를 생성한다.
    Class classHello = Class.forName("hello.proxy.jdkdynamic.ReflectionTest$Hello");
    // 실제 객체를 생성한다.
    Hello target = new Hello();

    // 리픒렉션 객체에서 매서드 정보를 가져온다.
    Method methodCallA = classHello.getMethod("callA");
    // 매서드가 호출될 객체를 파라미터로 넣는다.
    // 호출의 결과를 Object로 반환한다.
    Object result1 = methodCallA.invoke(target);
    log.info("result = {}", result1);

    Method methodCallB = classHello.getMethod("callB");
    Object result2 = methodCallB.invoke(target);
    log.info("result = {}", result2);
}

invoke() 메서드를 이용해 해당 메서드를 호출하게 되고, 결과를 Object 타입으로 변환시키는 것이다. 이때 주의해야할 점은 invoke() 메서드의 파리미터로는 실제 객체가 들어가야한다.

@Test
void reflection2() throws Exception {

    Class classHello = Class.forName("hello.proxy.jdkdynamic.ReflectionTest$Hello");
    Hello target = new Hello();

    Method methodCallA = classHello.getMethod("callA");
    dynamicCall(methodCallA, target);

    Method methodCallB = classHello.getMethod("callB");
    dynamicCall(methodCallB, target);
}

// 동적으로 리플렉션 매서드와 실제 객체를 받아 사용한다.
private void dynamicCall(Method method, Object target) throws Exception {
    log.info("start");
    Object result = method.invoke(target);
    log.info("result = {}", result);
}

조금 더 간소화 하자면 이렇다.

하지만 리플렉션은 런타임시 동작하기 때문에 컴파일 시점에 오류를 알 수 없다는 단점이 존재한다. 따라서, 리플렉션의 사용을 최대한 지양한다.

컴퓨터에게 시각적인 부분을 제공

컴퓨터가 이미지나 동영상 같은 시각 데이터를 이해하고 해석할 수 있도록 만드는 기술

• 이미지 분류 : 사진을 보고 고양이인지, 강아지인지 맞추는 작업
• 객체 탐지 : 사진 속에서 물체의 위치를 네모 박스로 찾고 무엇인지 알아내는 작업
• 생성 : 존재하지 않는 가상의 이미지나 실사 같은 영상을 만들어내는 작업

Natural Language Processing (NLP)

컴퓨터에게 사람의 말과 글을 알아듣고 소통하게 만드는 분야

인간이 일상적으로 쓰는 언어는 컴퓨터가 이해하는 이진수와 달리 맥락, 비유, 유머가 섞여있어 아주 복잡하나 이를 컴퓨터가 분석, 이해, 생성할 수 있도록 처리하는 기술임.

• 텍스트 분류 및 감성 분석 : 리뷰 글을 읽고 긍정, 부정 파악하기
• 기계 번역 : 파파고나 구글 번역기 처럼 한 언어를 다른 언어로 바꾸기
• 챗봇 및 LLM (대형 언어 모델) : chatGPT 처럼 사람이 질문을 던지면 맥락을 이해하고 자연스럽게 대답하거나 글을 창작해주는 작업

Computer Code

AI가 프로그래밍 언어를 이해하고 직접 코드를 짜거나 버그를 잡는 분야이며, 최근 LLM의 발전으로 가장 가파르게 성장함

• 코드 자동 완성
• 코드 리뷰 및 버그 탐지 : 작성된 코드에서 에러가 날만한 부분 NPE나 보안 취약점을 자동으로 찾아내는 작업
• 리팩토링 및 버전 업그레이드

Playing Games

게임 규칙을 배우고, 스스로 판단해서 게임에서 이기는 법을 터득하는 분야. 바둑, 체스, 스타크래프트같은 환경에서 시행착오를 겪으며 최적의 행동을 학습하는 분야

강화학습이라고도 부름

• 보드게임 정복 (AlphaGo)
• e스포츠 및 시뮬레이션
• 현실 세계 적용 (게임에서 검증된 자율적 판단 알고리즘을 현실 세계의 로봇 제어나 자율주행 주차 시스템에 적용)

Methodology

앞서 말한 모든 AI 기술을 어떻게 하면 더 빠르고 정확하고 효율적으로 만들지에 대한 이론과 방법

특정 데이터에 집중하기 보다 모델을 학습시키는 알고리즘 자체의 구조, 수학적 최적화, 데이터 효율성을 공부하는 원천 기술 연구 분야임

• 최적화 : AI 모델이 정답을 더 빠르게 찾아가도록 수학적 공식을 개선하게 하는 연구
• MLOps (머신러닝 운영 방법론) : 개발된 AI 모델을 서버에 안정적으로 배포하고 모니터링하고 지속적으로 업데이트하는 시스템적 절차 연구
• 경량화 : 거대한 AI 모델의 성능은 유지하며 크기를 줄여 스마트폰이나 로컬 서버에서도 가볍게 돌아가도록 만드는 기술

• Cross Site Scripting
• 게시판이나 웹 메일에 자바 스크립트와 같은 스크립트 코드를 삽입해 개발자가 고려하지 않은 기능이 작동하도록 하는 공격
• 사용자를 대상으로 한 공격임 대부분

위험성

• 쿠키 정보 및 세션 ID를 획득할 수 있음
• 시스템 관리자 권한 획득할 수 있음 (사용자의 브라우저가 악성 데이터를 실행할 수 있도록 함)
• 악성 프로그램으로 redirect 하거나, 트로이 목마 프로그램을 다운로드 하도록 유도할 수 있다

대안책

• script 문자 필터링
  • <, >, “, ‘ 과 같은 문자를 필터링 함
  • htmlentities 함수를 사용해 특수문자를 HTML 엔티티로 변환함

java-lucy-filter

• 지원이 끊겨서 javax→jakarta로 바꾸어 사용 가능 (직접 커스텀)
• 화이트 리스트 방식 채택
  • 모두가 차단된 상태에서 예외적으로 접근 가능한 대상을 지정
  • 블랙리스트는 기본 정책이 모두 허용된 상태에서 에외적으로 차단하는 대상을 지정

lucy-filter github

• https://github.com/naver/lucy-xss-servlet-filter

취약점 발견

• 입력단계에서 escape하지만, sanitize-html 모듈 누락 + 출력단계에서는 unescape

const sanitizeHtml = require('sanitize-html');

const dirty = `h1태그는 <h1>링크</h1> 무시가 될까?`;

const sanitizedDescription = sanitizeHtml(dirty, {
    allowedTags:['h1', 'a'], // h1 , a 태그 허용
    allowedAttributes: { a: ['href'] }, // a 태그의 href 속성 허용
    allowedFrameHostnames: ['www.youtube.com'] // iframe 허용하되 유튜브 사이트만 허용
});

console.log(sanitizedDescription); // 출력 : h1태그는 <h1>링크</h1> 무시가 될까?

• Lucy-XSS-filter가 Json 요청은 처리하지 않음
  • 서블릿 필터 동작방식과 데이터 읽기 방식에 차이가 존재하기 때문
  • Lucy는 HttpServletRequest.getParameters()를 가로채도록 설계되어있는데, JSON은 이 메서드를 통해 전달되지않음
• JSON은 request.getInputStream(), getReader()를 호출해야하는데, 전자의 한계는 HTTP요청의 Body 스트림은 한번만 읽을 수 있어, ContentCachingRequestWrapper와 같은 아이가 본문을 복사해두어야함 후자의 한계는 목적 자체가 form 태그를 통한 공격을 막기 위해 만들어졌다는 것

대안 방법 → Jackson ObjectMapper custom 시행

참고 문서 https://riverblue.tistory.com/46

사용자가 로그인하면:

• 일반 로그인: username + password를 검증
• OAuth 로그인: 외부 서비스에서 받은 토큰 검증

로그인이 성공하면 Spring Security가 사용자 정보를 세션이나 JWT 등에 저장함.

Spring Security가 인증 정보를 관리하는 방식

Spring Security에는 SecurityContext라는 공간이 있음. 여기서 인증된 사용자 정보(Authentication)를 저장.

예를 들어, 로그인 후엔 다음 구조과 같은 구조가 생김.

SecurityContext
   └── Authentication
          ├── principal-> UserDetails 객체 (사용자 ID, 권한 등)
          ├── credentials-> 비밀번호 등 (보통 null)
          ├── authorities-> 권한 목록

• principal이 현재 로그인한 사용자 정보
• Spring MVC 컨트롤러에서 쉽게 가져오기 가능

컨트롤러에서 로그인 사용자 확인하기

@GetMapping("/me")public StringgetMyInfo(Authentication authentication) {UserDetailsuserDetails= (UserDetails) authentication.getPrincipal();
    System.out.println("현재 로그인한 사용자 ID: " + userDetails.getUsername());return"ok";
}

또는 더 간단하게:

@GetMapping("/me")public StringgetMyInfo(@AuthenticationPrincipal UserDetails userDetails) {
    System.out.println("현재 로그인한 사용자 ID: " + userDetails.getUsername());return"ok";
}

즉, 아이디 변경 API, 비밀번호 변경 API 등에서는 요청을 보낸 사람이 누구인지 Authentication이나 @AuthenticationPrincipal로 확인 가능.

JWT를 사용하는 경우

로그인 후 JWT를 발급하면:

• 요청 시 HTTP Header에 Authorization: Bearer <토큰> 추가
• Spring Security Filter가 토큰을 검증하고, 유효하면 SecurityContext에 사용자 정보 저장

결과적으로 JWT 방식이든 세션 방식이든, 컨트롤러에서는 항상 Authentication에서 로그인 사용자 정보를 꺼낼 수 있음.

아이디/비밀번호 변경 시 체크

API 예시:

@PutMapping("/user/username")public ResponseEntity<?> changeUsername(@RequestBody ChangeUsernameRequest req,@AuthenticationPrincipal UserDetails userDetails) {
    userService.changeUsername(userDetails.getUsername(), req.getNewUsername());return ResponseEntity.ok().build();
}

• 여기서 중요한 점: 클라이언트가 전달한 사용자 ID를 사용하지 않고, SecurityContext에서 가져온 로그인 사용자 ID를 사용
• 안 그러면 다른 사람의 ID를 바꿀 수도 있음 → 보안 취약점

정리하면:

1. 로그인 성공 → SecurityContext에 사용자 정보 저장
2. 요청 시 Spring Security가 SecurityContext에서 사용자 정보 확인
3. 컨트롤러에서 Authentication 또는 @AuthenticationPrincipal로 로그인 사용자 확인
4. 이 정보로만 아이디/비밀번호 변경 등 민감한 작업 수행

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

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

오케스트레이션(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" 같은 잘못된 시간 값도 들어갈 수 있음
• 시간 연산 불가: 시간 더하기 빼기 등 로직 작성 시 문자열 파싱 필요
• 타입 의미 모호: 그냥 문자열이어도 시간으로 처리 가능