Win-Brother's Dev

[JavaScript] 호이스팅이란?

WinBro — Fri, 31 Mar 2023 07:12:59 +0900

호이스팅이란?

호이스팅은 코드를 실행하기 전 변수선언/함수선언을 해당 스코프의 최상단으로 끌어올리는 것이 아니다.
호이스팅은 코드가 실행하기 전 변수선언/함수선언이 해당 스코프의 최상단으로 끌어 올려진 것 같은 현상을 말한다.
자바스크립트 엔진은 코드를 실행하기 전 실행 가능한 코드를 형상화하고 구분하는 과정(*실행 컨텍스트를 위한 과정)을 거친다.
자바스크립트 엔진은 코드를 실행하기 전 실행 컨텍스트를 위한과정에서 모든 선언(var, let, const, function, class)을 스코프에 등록한다.
코드 실행 전 이미 변수선언/함수선언이 저장되어 있기 때문에 선언문보다 참조/호출이 먼저 나와도 오류 없이 동작한다.
(정확히는 var 키워드로 선언한 변수와 함수 선언문일 경우 오류 없이 동작한다. 이는 선언이 파일의 맨 위로 끌어올려진 것 처럼 보이게 한다.)
*실행 컨텍스트는 실행 가능한 코드가 실행되기 위해 필요한 환경을 의미하고 실행되기전 이러한 실행 컨텍스트 과정(코드를 구분하는 과정)을 거친다.

이 호이스팅이라는 용어를 자바스크립트 실행 컨텍스트에 의한 위에 설명한 현상을 호이스팅이라고 부른다는 것으로 이해하면 되겠다. 그 현상이란 선언이 코드 실행 보다 먼저 메모리에 저장되는 과정으로 인한 현상을 말한다.

그래서 자바스크립트 실행 컨텍스트에 대한 이해하는 것이 호이스팅을 이해하는데 도움이 된다. (scope, hoisting, this, function, closure 등의 동작원리를 담고 있는 자바스크립트 핵심원리이다. 코드를 보고 실행 컨텍스트를 이해할 수 있어야 코드 독해, 디버깅을 할수 있다.)

변수 호이스팅 (var, let, const 키워드)

자바스크립트의 모든 선언에는 호이스팅이 일어난다.
그런데 let, const, class를 이용한 선언문을 호이스팅이 발생하지 않는 것처럼 동작한다.
var 키워드로 선언된 변수와는 달리 let 키워드로 선언된 변수를 선언문 이전에 참조하면 참조 에러(ReferenceError)가 발생한다.
이는 let 키워드로 선언된 변수는 스코프의 시작에서 변수의 선언까지 *일시적 사각지대(Temporal Dead Zone; TDZ)에 빠지기 때문이다.

여기서 중요한 지점은 이 호이스팅이라는 용어가 ‘선언이 먼저 메모리에 저장되었다.’는 것을 의미하기 때문에 즉, ‘선언이 끌어올려진다’는 의미이기 때문에 모든 선언은 호이스팅이 일어난다는 말은 참이된다.

즉, 호이스팅이 파일의 맨 위로 끌어올려진 것 같은 현상을 의미할 때 선언문 이전에 참조해서 에러를 발생시킨다고 호이스팅이 일어나지 않은 것은 아니라는 의미이다.

왜냐하면 정말 선언은 끌어올려진 것이 맞다. (표현하면 그렇고 정확히는 선언이 코드 실행 전에 메모리에 저장되었다는 의미이다.)
그런데 왜 오류가 나는가 하면 var 키워드는 선언과 함께 undefined로 초기화되어 메모리에 저장되는데 let과 const는 초기화되지 않은 상태로 선언만 메모리에 저장되기 때문이다.
초기화 되지 않으면 변수를 참조할 수 없다. 그래서 참조 에러를 일으키는 것이다.
let과 const에도 호이스팅이 일어나기 때문에 에러를 일으키는 것이다.
호이스팅이 일어나지 않는다면 아래 코드에서 에러가 발생하지 않을 것이다.
선언이 호이스팅되었기 대문에 블록 스코프에서 foo를 찾을 수 없는 것이다.

let foo = 1;

{

console.log(foo);

let foo = 2;

}

호이스팅이 ‘현상’을 의미하는 것이라면 변수 키워드 중 var 만이 에러 없이 변수 선언이 상단으로 끌어올려지는 것 같은 ‘현상’이 일어나기 때문에 var 만이 호이스팅이 일어난다고 생각했다.
하지만 위 예시에서 알 수 있었고 자바스크립트 엔진이 동작하는 방식을 알고보니 let 키워드에서도 상단으로 끌어올려진 것 같은 ‘현상(즉, 호이스팅)’이 발생했기 때문에 에러가 발생하는 것이라는 것을 알게되었다.
(에러가 난다고 호이스팅이 되지 않은 것이 아닌, 호이스팅이 발생했기 때문에 에러가 발생한 것이다.)

변수는 어떻게 생성되며, 호이스팅은 어떻게 이뤄질까?

변수는 3단계에 걸쳐 생성된다.

1단계: 선언 단계(Declaration phase)

변수를 실행 컨텍스트의 변수 객체에 등록한다.
이 변수 객체는 스코프가 참조하는 대상이 된다.

2단계: 초기화 단계(Initialization phase)

변수 객체에 등록된 변수를 위한 공간을 메모리에 확보한다.
이 단계에서 변수는 undefined로 초기화 된다.

3단계: 할당 단계(Assignment phase)

undefined로 초기화된 변수에 실제 값을 할당한다.

var 키워드로 선언한 변수는 선언 단계와 초기화 단계가 한번에 이뤄진다. 즉, 스코프에 변수를 등록(선언 단계)하고 메모리에 변수를 위한 공간을 확보한 후, undefined로 초기화한다. 따라서 변수 선언문 이전에 변수에 접근하여도 스코프에 변수가 존재하기 때문에 에러가 발생하지 않는다. 다만 undefined를 반환한다. 이후 변수 할당문에 도달하면 비로소 값이 할당된다.

let 키워드로 선언된 변수는 선언 단계와 초기화 단계가 분리되어 진행된다. 즉, 스코프에 변수를 등록(선언 단계)하지만 초기화 단계는 변수 선언문에 도달했을 때(코드 실행 후) 이뤄진다. 초기화 이전에 변수에 접근하려고 하면 참조 에러가 발생한다. 이는 아직 변수가 초기화되지 않았기 때문이다. 즉, 변수를 위한 메모리 공간이 아직 확보되지 않았기 때문이다. 따라서 스코프의 시작 지점부터 초기화 시작 지점까지는 변수를 참조할 수 없다. 스코프의 시작 지점부터 초기화 시작 지점까지의 구간을 ‘일시적 사각지대(Temporal Dead Zone; TDZ)’라고 부른다.

호이스팅 예시

변수 선언에서의 호이스팅 예시

// 호이스팅 때문에 선언이 끌어올려져서 오류 안남.

console.log(text); // (선언 + 초기화 된 상태)

text = 'Hanamon!'; // (선언 + 초기화 + 할당 된 상태)

var text;

console.log(text);

// 호이스팅 때문에 선언이 끌어올려졌지만 초기화 안된 상태에서 참조해서 오류 남.

console.log(text); // (선언 된 상태, 초기화(메모리 공간 확보와 undefined로 초기화) 안되서 참조 불가능 -> 에러남)

let text; // 여기서 초기화 단계가 실행됨

const text; // 에러남. 주의! 애초에 const 키워드로 재할당 불가능! 그래서 선언과 동시에 할당해야함

함수 선언에서의 호이스팅 예시

foo1(); // 함수 선언문에서는 호이스팅 일어난다.

foo2(); // 함수 표현식이라서 호이스팅 안된다.

function foo1() {

console.log('Hello');

}

var foo2 = function() {

console.log('world');

}

참고 :
https://developer.mozilla.org/ko/docs/Glossary/Hoisting
https://velog.io/@hoo00nn/%ED%98%B8%EC%9D%B4%EC%8A%A4%ED%8C%85Hoisting-%EC%9D%B4%EB%9E%80
https://poiemaweb.com/es6-block-scope#13-%ED%98%B8%EC%9D%B4%EC%8A%A4%ED%8C%85

공인(Public) && 사설(Private) IP의 차이점

WinBro — Tue, 28 Mar 2023 07:27:22 +0900

1. 공인 IP (Public IP)

인터넷 사용자의 로컬 네트워크를 식별하기 위해 ISP(인터넷 서비스 공급자)가 제공하는 IP 주소이다. 공용 IP 주소라고도 불리며 외부에 공개되어 있는 IP 주소이다.

공인 IP는 전세계에서 유일한 IP 주소를 갖는다.
공인 IP 주소가 외부에 공개되어 있기에 인터넷에 연결된 다른 PC로부터의 접근이 가능하다. 따라서 공인 IP 주소를 사용하는 경우에는 방화벽 등의 보안 프로그램을 설치할 필요가 있다.

2. 사설 IP (Private IP)

일반 가정이나 회사 내 등에 할당된 네트워크의 IP 주소이며, 로컬 IP, 가상 IP라고도 한다. IPv4의 주소부족으로 인해 서브넷팅된 IP이기 때문에 라우터에 의해 로컬 네트워크상의 PC 나 장치에 할당된다.

2.1. 사설IP 주소대역

사설IP 주소는 다음 3가지 주소대역으로 고정된다.

Class A : 10.0.0.0 ~ 10.255.255.255
Class B : 172.16.0.0 ~ 172.31.255.255
Class C : 192.168.0.0 ~ 192.168.255.255

3. 사설 IP와 공인 IP의 차이

공인 IP (Public IP)사설 IP (Private IP)

할당 주체	ISP(인터넷 서비스 공급자)	라우터(공유기)
할당 대상	개인 또는 회사의 서버(라우터)	개인 또는 회사의 기기
고유성	인터넷 상에서 유일한 주소	하나의 네트워크 안에서 유일
공개 여부	내/외부 접근 가능.	외부 접근 불가능

❗ 사설 IP 주소만으로는 인터넷에 직접 연결할 수 없다. 라우터를 통해 1개의 공인(Public) IP만 할당하고, 라우터에 연결된 개인 PC는 사설(Private) IP를 각각 할당 받아 인터넷에 접속할 수 있게 된다.

아래의 그림을 보면 이해가 쉽다.

➡ : 사설 IP를 할당받은 스마트폰 혹은 개인 PC가 데이터 패킷을 인터넷으로 전송하면, 라우터(공유기)가 해당 사설 IP를 공인 IP로 바꿔서 전송한다.

➡ : 인터넷에서 오는 데이터 패킷의 목적지도 해당하는 사설 IP로 변경한 후 개인 스마트폰 혹은 PC에 전송한다.

4. 고정 IP와 유동 IP

고정 IP는 컴퓨터에 고정적으로 부여된 IP로 한번 부여되면 IP를 반납하기 전까지는 다른 장비에 부여할 수 없는 IP 주소를 말한다.
유동 IP는 장비에 고정적으로 IP를 부여하지 않고 컴퓨터를 사용할 때 남아 있는 IP 중에서 돌아가면서 부여하는 IP를 뜻한다.

인터넷 상에서 서버를 운영하고자 할 때는 공인 IP를 고정 IP로 부여해야 한다는 것이 중요하다. 즉, 공인 IP를 부여받지 못하면 다른 사람이 내 서버에 접속할 수가 없고, 고정 IP를 부여하지 않으면 내 서버가 아닌 다른 사람의 서버로 접속이 될 수도 있기 때문이다.

반면에 우리가 집에서 사용하는 인터넷 서비스 업체는 각 가정마다 공인 IP를 유동 IP로 부여하고, 공유기 내부에서는 사설 IP를 유동 IP로 부여하는 것이 일반적이라고 보면 될 것이다.

출처 : https://velog.io/@hidaehyunlee

Docker 개념과 명령어 사용 방법 및 예제

WinBro — Thu, 23 Mar 2023 07:06:19 +0900

1. Docker란

Docker는 가상 머신처럼 독립된 실행환경을 만들어주는 것으로, 운영체제를 설치하 것과 유사한 효과를 낼 수 있지만, 실제 운영체제를 설치하지 않기 때문에 설치 용량이 적고 실행 속도 또한 빠릅니다. 예전에는 윈도에 VM Ware와 같은 가상 머신을 설치하였으나 최근에는 리눅스 계열에서 Docker가 그 역할을 대신하고 있습니다.

출처: 위키 백과

도커 컨테이너는 일종의 소프트웨어를 소프트웨어의 실행에 필요한 모든 것을 포함하는 완전한 파일 시스템 안에 감싼다. 여기에는 코드, 런타임, 시스템 도구, 시스템 라이브러리 등 서버에 설치되는 무엇이든 아우른다. 이는 실행 중인 환경에 관계 없이 언제나 동일하게 실행될 것을 보증한다.

2. Docker 를 사용하는 이유

Docker는 다양하게 사용할 수 있습니다. (출처: 나무위키) 실무에서는 우분투 환경에 CentOS container를 설치하여 사용하거나, 이미 검증된 Web server의 설정 및 Binary가 설치된 container를 설치하여 복잡한 configuration 과정을 줄일 수 있습니다.

구성 단순화 Docker는 하나의 Configuration으로 모든 플랫폼에서 실행할 수 있습니다. Configuration 파일을 코드에 넣고 환경 변수를 전달하여 다른 환경에 맞출 수 있습니다. 따라서 하나의 Docker 이미지를 다른 환경에서 사용할 수 있습니다.
코드 관리 Docker는 일관된 환경을 제공하여 개발 및 코딩을 훨씬 편안하게 만들어줍니다. Docker 이미지는 변경이 불가하기에 개발환경에서 운영 환경까지 애플리케이션 환경이 변경되지 않는 이점이 존재합니다.
개발 생산성 향상 개발 환경을 운영 환경에 최대한 가깝게 복제할 수 있습니다. Docker를 사용하면 코드가 운영 환경의 컨테이너에서 실행될 수 있으며 VM과 달리 Docker는 오버 헤드 메모리 용량이 적기에 여러 서비스를 실행하는데 도움이 됩니다. 또한 Docker의 Shared Volume을 사용하여 호스트에서 컨테이너의 어플리케이션 코드를 사용할 수 있도록 할 수 있습니다. 이를 통해 개발자는 자신의 플랫폼 및 편집기에서 소스 코드를 편집할 수 있으며 이는 Docker내에서 실행 중인 환경에 반영됩니다.
애플리케이션 격리 Web Server(e.g. Apache, Nginx)와 연결된 API 서버를 격리할 필요가 있는 경우가 있습니다. 이 경우 다른 컨테이너에서 API를 서버를 실행할 수 있습니다.
빠른 배포 컨테이너가 OS를 부팅하지 않고 어플리케이션을 실행하기 때문에 Docker 컨테이너를 매우 빠르게 만들 수 있습니다.

3. Images와 Container 개념 이해

Docker 공식 홈페이지는 https://docker.com/이며, 개념을 설명한 문서는 링크에 설명되어 있습니다. Docker는 Client (docker)와 서버 (dockerd)로 구성되어 있습니다. Docker Images는 read only의 docker container를 생성하기 위한 template이고, Container는 images가 실제 메모리에 로딩된 instance입니다. 하나의 images로 유사한 container를 만들 수 있습니다. Registry는 Docker hub이며 images의 저장소입니다.

Images: libs와 package의 template, read only
Container: Images가 설치되어 메모리에 로딩된 instance

Docker 구조 (출처: https://docs.docker.com/get-started/overview/)

4. Container와 Virtual Machine 비교

Container는 리눅스/Windows와 Host OS 기반에 docker가 운영되고, Container 별로 각각 process 단위로 bin/libs가 구동됩니다. 반면 Virtual machine은 Hypervisor 위에 full host OS (리눅스/윈도우)가 올라가고 이를 기반으로 각각의 bin/libs가 구동됩니다. VM은 full OS를 구동하기 때문에 overahead가 높습니다. 즉, Container와 Virtual machine의 차이점은 Host OS를 설치 여부에 있습니다.

Container와 Virtual Machine (출처: https://docs.docker.com/get-started/overview/)

5. Docker 설치 및 사용 방법

Docker에 대한 설명은 아래 동영상을 참조해주세요. 쉽게 설명되어 있으며, 꼭 필요한 명령어를 설명하고 있습니다.

https://youtu.be/Bhzz9E3xuXY

5.1 Docker 설치

우분투 기준으로 Docker 설치 방법을 링크에 설명되어 있습니다. 자동 설치 script 활용합니다. get-docker.sh 에서는 OS 맞는 설치 방법을 자동으로 선택하고 우분투의 경우에는 apt update 후 repository를 추가해서 docker를 패키지를 설치합니다. 설치 script 진행 후에는 Docker client와 server의 설치 버전을 표시합니다.

$ curl -fsSL https://get.docker.com -o get-docker.sh
$ sudo sh get-docker.sh

# docker는 sudo 계정을 필요로 합니다. 일반 user 계정에서 사용하는 아래 명령어를 사용해주세요.

$ sudo usermod -aG docker [your-user]

Docker 설치 명령어

5.2. Docker 삭제

Docker 를 삭제하기 위해서는 아래 명령어를 사용합니다. Docker client와 서버를 삭제하고 docker에서 설치한 images와 container를 수동으로 삭제합니다.

#Uninstall the Docker Engine, CLI, and Containerd packages:
$ sudo apt-get purge docker-ce docker-ce-cli containerd.io

# Images, containers, volumes, or customized configuration files on your host are not automatically removed. To delete all images, containers, and volumes:
$ sudo rm -rf /var/lib/docker

5.3. Docker Image 검색 (docker search) 및 다운로드 (docker pull)

# docker image 검색 (Docker Hub에서 검색)

$ sudo docker search [검색 단어]

$ sudo docker search centos

#docker image 받아오기
docker pull <이미지 이름>:<태그>

#최신 버전의 centos

$ sudo docker pull centos

#특정 버전 (특정 tag)의 centos : registry.hub.docker.com/_/centos?tab=tags

$ sudo docker pull centos:centos7

Docker Hub에서 Image와 Tag 확인

5.3. Docker image에서 container 실행 (docker run)

#docker image에서 container 실행

docker run <옵션> <이미지 이름:Tag이름> <실행할 파일> 형식입니다

$ sudo docker run -i -t centos:centos7 /bin/bash

-i(interactive), -t(Pseudo-tty) 옵션을 사용하면 실행된 Bash Shell에 입력 및 출력을 할 수 있습니다.

Docker run 실행하면 root 계정으로 bash를 실행합니다. 우분투에서 CentOS7 cotainer를 설치 후에 OS를 확인하면 아래와 같습니다.

docker 에서 설치된 OS 확인 결과

# Container 시작

$ sudo docker start [컨테이너 이름 or ID]

# Container 접속

$ sudo docker attach [컨테이너 이름 or ID]

Bash Shell에서 exit 또는 Ctrl+D를 입력하면 컨테이너가 정지됩니다. 여기서는 단축키 Ctrl+P와 Ctrl+Q를 차례대로 입력하여 컨테이너를 정지하지 않고, 컨테이너에서 빠져나옵니다

5.4. Docker image 리스트 확인 (docker images) 및 삭제

# 설치된 이미지 리스트 확인

$ sudo docker images
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
ubuntu              latest              9140108b62dc        3 weeks ago         72.9MB
hello-world         latest              bf756fb1ae65        9 months ago        13.3kB

# doker image 삭제

$ sudo docker rmi [image id]

$ sudo docker rmi bf756fb1ae65

5.4. 동작 중인 container 확인 (docker ps) 및 삭제 (docker rm)

# 동작 중인 container 확인

$ sudo docker ps

#정지된 container 확인

$ sudo docker ps -a

#container 삭제

$ sudo docker rm [container id]

$ sudo docker rm afc479607c11 fdfe0a5387ef

5.6. 파일 공유를 위한 Volume mount 및 파일 복사

Host의 storage를 container로 전달하는 명령어입니다. -v (volume)을 사용할 수입니다. Host와 container 사이에 storage를 공유할 수 있습니다

# 로컬 volume을 container의 /conainer_volume 로 마운트

$ docker run -i -t -v /home/host_volume:/conainer_volume centos:centos7 /bin/bash

# 로컬 파일을 cotainer로 복사: 로컬의 “~/data/test.md” 라는 파일을 컨테이너의 “/root/data/”로 복사

$ docker cp ~/data/test.md tmp_container:/root/data/

5.7. Docker 명령어 리스트

Management Commands:
  builder     Manage builds
  config      Manage Docker configs
  container   Manage containers
  context     Manage contexts
  engine      Manage the docker engine
  image       Manage images
  network     Manage networks
  node        Manage Swarm nodes
  plugin      Manage plugins
  secret      Manage Docker secrets
  service     Manage services
  stack       Manage Docker stacks
  swarm       Manage Swarm
  system      Manage Docker
  trust       Manage trust on Docker images
  volume      Manage volumes

Commands:
  attach      Attach local standard input, output, and error streams to a running container
  build       Build an image from a Dockerfile
  commit      Create a new image from a container's changes
  cp          Copy files/folders between a container and the local filesystem
  create      Create a new container
  diff        Inspect changes to files or directories on a container's filesystem
  events      Get real time events from the server
  exec        Run a command in a running container
  export      Export a container's filesystem as a tar archive
  history     Show the history of an image
  images      List images
  import      Import the contents from a tarball to create a filesystem image
  info        Display system-wide information
  inspect     Return low-level information on Docker objects
  kill        Kill one or more running containers
  load        Load an image from a tar archive or STDIN
  login       Log in to a Docker registry
  logout      Log out from a Docker registry
  logs        Fetch the logs of a container
  pause       Pause all processes within one or more containers
  port        List port mappings or a specific mapping for the container
  ps          List containers
  pull        Pull an image or a repository from a registry
  push        Push an image or a repository to a registry
  rename      Rename a container
  restart     Restart one or more containers
  rm          Remove one or more containers
  rmi         Remove one or more images
  run         Run a command in a new container
  save        Save one or more images to a tar archive (streamed to STDOUT by default)
  search      Search the Docker Hub for images
  start       Start one or more stopped containers
  stats       Display a live stream of container(s) resource usage statistics
  stop        Stop one or more running containers
  tag         Create a tag TARGET_IMAGE that refers to SOURCE_IMAGE
  top         Display the running processes of a container
  unpause     Unpause all processes within one or more containers
  update      Update configuration of one or more containers
  version     Show the Docker version information
  wait        Block until one or more containers stop, then print their exit codes

유용한 명령어 모음입니다.

# 컨테이너의 로컬 셸 가져오기

docker run -i -t --entrypoint /bin/bash imageID

# 이 디렉터리의 Dockerfile을 사용하여 이미지 생성

docker build -t friendlyname .

# 포트 4000에서 80으로 "friendlyname" 매핑 실행

docker run -p 4000:80 friendlyname

# 동일하지만 분리된 모드에서

docker run -d -p 4000:80 friendlyname

# 실행 중인 모든 컨테이너 목록 보기

docker ps

# 지정된 컨테이너를 정상적으로 중지

docker stop <hash>

# 실행 중이 아닌 컨테이너를 포함해 모든 컨테이너 목록 보기

docker ps -a

# 지정된 컨테이너 강제 종료

docker kill <hash>

# 이 시스템에서 지정된 컨테이너 제거

docker rm <hash>

# 이 시스템에서 모든 컨테이너 제거

docker rm $(docker ps -a -q)

# 이 시스템의 모든 이미지 표시

docker images -a

# 이 시스템에서 지정된 이미지 제거

docker rmi <imagename>

# 이 시스템에서 모든 이미지 제거

docker rmi $(docker images -q)

# Docker 자격 증명을 사용하여 이 CLI 세션에 로그인

docker login

# 레지스트리에 업로드할 <image> 태그 지정

docker tag <image> username/repository:tag

# 태그 지정된 이미지를 레지스트리에 업로드

docker push username/repository:tag

# 레지스트리에서 이미지 실행

docker run username/repository:tag

출처 :
https://kibua20.tistory.com/135

[Spring MVC] HTTP 메시지 컨버터

WinBro — Wed, 22 Mar 2023 07:09:57 +0900

HTTP 메시지 컨버터란?

JSON 데이터를 HTTP 메시지 바디에서 직접 읽거나 쓰는 경우, HTTP 메시지 컨버터를 사용하면 매우 편리하다.

HTTP 메시지 컨버터란, 요청 본문에서 메시지를 읽어들이거나(@RequestBody), 응답 본문에 메시지를 작성할 때(@ResponseBody) 사용하는 컨버터다.

HTTP 메시지 컨버터 인터페이스

boolean canRead(Class<?> clazz, @Nullable MediaType mediaType);
boolean canWrite(Class<?> clazz, @Nullable MediaType mediaType);

List<MediaType> getSupportedMediaTypes();

T read(Class<? extends T> clazz, HttpInputMessage inputMessage)
	throws IOException, HttpMessageNotReadableException;
void write(T t, @Nullable MediaType contentType, HttpOutputMessage outputMessage)
	throws IOException, HttpMessageNotWritableException;

HTTP 요청, 응답 양방향으로 사용
canRead(), canWrite(): 메시지 컨버터가 해당 클래스, 미디어 타입을 지원하는지 체크
read(), write(): 메시지 컨버터를 통해 메시지를 읽고 쓰는 기능

스프링 부트의 기본 메시지 컨버터

ByteArrayHttpMessageConverter
StringHttpMessageConverter
MappingJacksonHttpMessageConverter
...

기본적으로 위의 컨버터들을 지원함
대상 클래스 타입과 미디어 타입을 체크해 사용여부 결정
(만족하지 않는 경우 다음 메시지 컨버터로 우선순위 넘어감)
ex1: @RequestBody String data 형식으로 요청이 오면 StringHttpMessageConverter 사용
ex2: @ResponseBody return helloData로 쓰고 미디어 타입 application/json인 경우 MappingJacksonHttpMessageConverter 사용

HTTP 요청 데이터 읽기

HTTP 요청이 들어오고, 컨트롤러에서 @RequestBody나 HttpEntity 파라미터 사용
메시지 컨버터가 canRead() 호출 // 읽을 수 있는 메시지인지 확인
- 대상 클래스 타입과 HTTP의 Content-Type 미디어 타입 지원하는지
canRead() 만족 시 read() 호출해 객체 생성 및 반환

HTTP 응답 데이터 생성

컨트롤러에서 @ResponseBody나 HttpEntity로 값 반환
메시지 컨버터가 canWrite() 호출 // 메시지를 쓸 수 있는지 확인
- 대상 클래스 타입과 HTTP의 Accept 미디어 타입 지원하는지
canWrite() 만족 시 write() 호출해 HTTP 응답 메시지 바디에 데이터 생성

HTTP 메시지 컨버터의 실행

그렇다면 이제 궁금한 것이 하나 생겼다.

HTTP 메시지 컨버터는 어디서 실행되는걸까?

SpringMvc 구조를 다시 보자

HTTP 요청이 들어오면 핸들러 조회
핸들러를 처리할 수 있는 핸들러 어댑터 조회
handle(handler)
handler 호출
ModelAndView 반환
viewResolver 호출
View 반환
render(model) 호출

위 과정에서 4번 과정을 주목해보자.

어노테이션 기반의 핸들러(컨트롤러)의 여러 파라미터를 생성해서 호출할 수 있는 '핸들러 어댑터'

이 어댑터가 HTTP 메시지 컨버터와 관련이 있다.

먼저, @RequestMapping을 처리하는 핸들러 어댑터인 RequestMappingHandlerAdapter를 자세히 살펴보자.

ArgumentResolver 호출
ArgumentResolver: 매우 다양한 종류의 파라미터를 유연하게 처리해 파라미터 값(객체) 생성
파라미터 값이 준비되면 컨트롤러를 호출하며 값을 넘겨줌

그럼 이제 본격적으로 HTTP 메시지 컨버터는 어디있을까?

만약 ArgumentResolver에 요청하는 파라미터가 @RequestBody 또는 HttpEntity인 경우 HTTP 메시지 컨버터를 사용해 'read' 한다. 응답의 경우에도 @ResponseBody 또는 HttpEntity를 처리하는 ReturnValueHandler에서 HTTP 메시지 컨버터를 호출해 응답 결과를 'write' 한다.\

출처 : 스프링 MVC 1편 - 백엔드 웹 개발 핵심 기술

[Spring Boot] Logger 사용법 & 팁

WinBro — Mon, 20 Mar 2023 07:42:41 +0900

1. 스프링 부트에서 로깅 사용법

스프링 부트는 spring- boot-starter-logging을 기본적으로 제공한다

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

@Configuration
public class RedisScheduler {
    private final Logger logger = LoggerFactory.getLogger(this.getClass());

    private void log(String name) {
        logger.trace("trace log={}", name);
        logger.debug("debug log={}", name);
        logger.info(" info log={}", name);
        logger.warn(" warn log={}", name);
        logger.error("error log={}", name);
    }
}

1.1.1. {}, xxx 문법을 사용하는 이유

위에 예제 코드를 보면, logger.trace("trace log={}", name)로 되어있다.
logger.trace(”trace log=” + name)으로 사용하면 안될까?
사용하면 안되는데 이유를 알아보자.

의미없는 문자열 연산이 일어난다. 반면 name을 파라미터로 넘기면, 연산이 일어나지 않는다.
로그 레벨에 따라서 출력되지 않는 로그 레벨의 문자열 연산이 일어난 후 로그 레벨을 검사한다.
만약 debug 레벨인 경우 trace는 아예 동작할 필요가 없기 때문에 trace는 검사만 하고, 출력하지 않는다.
하지만 문자열 연산이 있으면, 문자열 연산을 하고 레벨을 검사하는 것이다.

1.1.2. 로그 레벨 설정하기

application.properties

logging.level.project=debug

debug 레벨로만 설정하면 하위 레벨은 로깅되지 않음. 즉, trace는 로깅되지 않음.
별도로 설정하지 않는다면, info가 기본값.

logging.level.root=debug

기본값은 이렇게 root에 debug가 아닌 info가 되어있다고 했다.
만약 debug나 trace로 변경하면, 라이브러리들의 모든 로그까지 다 로깅하기 때문에
필요한 경로에 별도로 지정해서 사용하자.

1.1.3. 로그 레벨

trace
debug
info
warn
error

2. 로그 설정 팁

2.1.1. 개발 서버는 debug

디버깅에 필요한 상세 정보를 봐야하기 때문이다.
디버깅이 더 상세한 정보를 보여주기도 하고, 개발 중 작성한 로그가 실수로 운영에도 반영되는 일이 방지할 수 있음.
실제로 이런 경우가 많음. System.out.println은 방법이 없음.

2.1.2. 운영 서버는 info

운영 서버에서 디버깅은 필요없고 기본 정보나 에러가 발생할 경우만 로그가 필요하기 때문이다.
트래픽도 많기 때문에 의미없는 로그는 없애야하기 때문이다.

3. Log 라이브러리 사용하는 이유

대표적으로 SLF4J 인터페이스있고, Logback, log4j, log4j2 구현체가 있다.

쓰레드 정보, 클래스 이름 같은 부가 정보를 함께 볼 수 있다.
출력 모양을 가독성 좋게 변경할 수 있다.
로그 레벨에 따라 환경에 맞게 설정할 수 있다.
콘솔에만 출력이 아닌 네트워크, 파일로도 남길 수 있다.
파일로 남길 때는 특정 용량에 따라 로그를 분리하는 것도 가능하다.
성능도 일반 System.out보다 수십배 차이가 난다고 한다.

출처 : https://dev-monkey-dugi.tistory.com/

[Spring MVC] 쿼리 파라미터, 쿼리스트링, 패스변수 (Query parameter, Query String , Path Variable)

WinBro — Mon, 20 Mar 2023 07:04:21 +0900

웹에서 데이터를 보내고 받기 위해서는 어떤 식으로 전송하고 어떤 경로(End-point)에 전달할지를 중요하게 본다.

데이터를 전송하고 받는 방식으로는 GET, POST 등의 HTTP 메서드가 있고, 관련해서 REST API라는 개념이 있다.

그보다 이번 글에서는 경로에 대해서, 그 중에서도 Query Parameter와 Path Variable에 대해서 정리해보려 한다.

Query Parameter (Query String)

위 이미지는 우리가 흔하게 보는 URL의 구조이다.

여기서 ? 이후부터 시작되는 Parameters라는 부분이 바로 Query Parameter이다.

흔히 Query String, 쿼리 스트링이라고 부르기도 한다. 쿼리 파라미터와 쿼리 스트링은 같은 표현이다.

Query String은 key와 value로 쌍을 이룬 문자 형태이며 & 로 연결한다.

위 구조로 따지면 2개의 key, value 쌍이 parameter에 들어가 있는 것이다.

이렇게 담겨진 Query String은 웹서버로 전달된다.

아래와 같은 경우는 q라는 key에 abc를 담아 전달한다고 보면 되겠다.

/search?q=abc

Path Variable

Path Variable은 경로를 변수로 사용한다.

게시글을 조회한다고 가정하면, 해당 게시글의 id를 서버로 넘겨주어야만 조회할 수 있을 것이다.

/boards/100

위와 같은 형태로, id 같은 특정 인덱스에 대한 조회를 하는 경우 Path Variable을 사용한다.

각각 언제 쓰는 것이 좋을까?

그럼 Query Parameter와 Path Variable을 사용하기 적절한 때는 언제일까?
아래와 같이 정리해볼 수 있겠다.

Query Paramater : id를 어떤 리소스를 식별하고 싶을 때 더 적절!

/users  // 모든 사용자 목록 가져오기
/users/123  // 회원 번호 혹은 id가 123인 사용자 정보 가져오기

Path Variable : 필터링을 하거나 정렬을 하는 경우 사용하는 것이 이상적!

/posts  // 모든 게시글 목록 가져오기
/posts?user=abc  // 작성자가 abc인 게시글만 가져오기

항상 모든 경로에 Query String이나 Path Variable이 필요한 것은 아니다.
필요에 따라, 경우에 맞게 사용하면 된다.

출처 : 스프링 MVC 1편 - 백엔드 웹 개발 핵심 기술

[Backend] 이클립스 디버깅(Eclipse) - Debugging 사용법

WinBro — Fri, 17 Mar 2023 08:16:46 +0900

프로그래밍을 하다 보면 필연적으로 각종 오류에 부딪치게 되고 그 오류를 해결하는 과정에서 디버깅은 필수입니다. 디버깅을 얼마나 잘하느냐에 따라 프로그램의 생산성과 개발자의 능력이 좌우되기도 합니다. 그렇기에 모든 IDE에는 디버깅을 할 수 있는 기능들이 아주 잘 되어있습니다. 자바 개발이나 웹 개발을 할 때 많이 쓰이는 이클립스에도 디버깅 기능이 있습니다. 오늘은 이클립스의 디버깅 기능에 대해 포스팅 해보려 합니다.

Break Point 지정

디버깅을 진행하기 위해서는 가장 먼저 우선 자신이 조사하고 싶은 시점에 브레이크 포인트를 지정해주어야 합니다. 이클립스 좌측의 라인에서 오류가 의심가는 부분에 더블클릭 or 우클릭 -> Toggle Breakpoint를 누르면 좌측 그림과 같이 조그마한 점이 찍힙니다. 이것이 브레이크 포인트입니다. 반복하면 브레이크 포인트가 해제됩니다.

디버그 모드 실행

디버그 모드를 실행시키려면 상단바에 있는 벌레모양 Debug를 클릭하거나 Run -> Debug를 클릭합니다. 단축키는 [F11]입니다

디버깅 중 위와 같은 메시지 창이 뜬다면 Switch를 눌러 디버깅 모드로 전환하도록 합시다.

디버깅 진행

디버깅을 시작하면 위와 같이 브레이크 포인트를 지정한 부분에 정확히 멈춥니다. 여기서 디버깅을 진행하기 위해서는 자주 사용하는 단축키를 외워두시면 좋은데 자주 사용하는 단축키는 아래와 같습니다.

Step Into(F5) : 한 줄씩 진행하되 함수 안이면 함수 안으로 들어갑니다.

Step Over(F6) : 한줄씩 진행하되 함수 호출은 건너뜁니다.

Step Return(F7) : 현재 함수 끝까지 바로 가서 리턴 후 함수 호출부로 되돌아갑니다.

Resume(F8) : 다음 브레이크 포인트까지 건너뜁니다.

단축키가 싫으신 분들은 위와 같이 Debug Toolbar를 활용해도 됩니다.

만약 Debug툴이 없으시다면 Debug창의 우측에 3개의 세로 점 아이콘 (View Menu)를 클릭하신 후 Show Debug Toolbar를 클릭하시면 됩니다.

Debug Toolbar 사용법

변수의 값 확인

대부분의 사소한 오류들은 자신이 선언해놓은 변수들에 정확한 값이 들어와있는지 검증을 통해 해결이 가능합니다. 디버깅 모드를 실행하고 변수에 커서를 가져다 대면 위와 같이 변수에 있는 값들을 확인하실 수 있습니다.

디버깅 활용

현재 설정되어 있는 Break Point 모두 확인하기

현재 설정되어있는 브레이크 포인트들은 Breakpoints탭에서 확인이 가능합니다. 어느 프로젝트 어느 라인에 설정이 되어있는지 객관적으로 확인이 가능합니다. 주로 가고 싶은 브레이크 포인트를 더블클릭하여 해당 브레이크 포인트로 이동하고 싶을 때 사용하며 체크박스를 해제하여 비활성화도 할 수 있고 우클릭 -> Remove ALL을 눌러 모두 해제할 수도 있습니다.

현재 설정되어있는 변수의 모든 값 확인하기

Variables탭에서는 커서가 지나쳐온 모든 변수의 값을 확인하실 수 있습니다. 마우스 오버로는 하나의 변수밖에 한 번에 확인하실 수 없지만 이 탭에서는 모든 변수들의 값을 확인이 가능합니다.

특정 변수의 값 확인하기

Expressions탭에서는 자신이 확인하고 싶은 특정 변수의 값을 확인할 수 있습니다. 확인하고 싶은 변수의 값을 추가할 때는 Add new expression을 누른 뒤 변수명을 입력하시면 됩니다.

만약 위의 탭이 존재하지 않는다면 Window -> Show View에서 활성화시키시면 됩니다.

디버그 모드 전환

이클립스를 사용하다 보면 의도하지 않은 상황에서 강제로 디버깅 모드로 전환이 되기도 하고 특정 작업을 위해 디버깅 모드로 전환을 하고 싶을 때도 있습니다. 이럴 때 즉시 전환할 수 있는 기능이 있습니다. 이클립스의 우측 상단을 보시면 위와 같은 아이콘이 있습니다. 여기서 Debug버튼을 누르면 즉시 디버그 모드로 전환됩니다. 디버그 모드를 해제하고 다시 원래대로 돌아가고 싶다면 Java EE나 Java버튼을 누르시면 됩니다. Open Perspective 버튼을 눌러 자신이 전환하고 싶은 모드를 선택할 수도 있습니다.

만약 위와 같은 아이콘이 없다면 Windows -> Perspective -> Open Perspective -> Debug를 누르셔도 됩니다. 모든 디버깅은 이 Debug모드에서 하게 됩니다.

출처 : https://coding-factory.tistory.com/642

[Backend] 인텔리제이 디버깅(Intellij) - Debugging 사용법

WinBro — Fri, 17 Mar 2023 07:32:00 +0900

디버거

프로그램을 한 줄씩 실행시킬 수 있고 실행될 때 변하는 변수와 그 값들을 확인할 수 있다.

메뉴설명

Step Over (F8) : 현재 정지되어 있는 시점에서 명령어 하나만 실행이 된다
Step Into (F7) : 현재 위치의 메소드를 확인할 수 있다.
Run to Cursor (Alt + F9) : 현재 커서까지 디버그할 수 있도록 도와준다.

Resume Program (F9) : 현재에서 다음 Breakpoint까지 디버그해준다.
Stop(ctrl + F2) :현재 디버그를 중지해준다.
Return : 처음에 디버그한 파일로 돌아갈 수 있게해준다.

디버깅 과정

1. 처음에 Breakpoint를 만들고 Debug 현재파일을 시작한다.

→ Breakpoint가 빨간색 동그라미고, id에 값 할당 전까지 디버그한것이다. 변수도 아직 args에 대해서만 할당되었다.

2. Step Over(F8)로 바로 다음 명령어만 실행시킨다.

→ 다음 파란색 줄로 밑줄이 쳐져있는 곳으로 이동하였고 id의 값을 디버그 했으며 변수가 저장된 것을 볼 수 있다.

3. resume을 클릭하여 다음에 있는 BreakPoint까지 이동한다.

4. 현재 위치한 메소드를 확인하기 위해 Step Into(F7) 클릭한다.→ Step Into를 클릭하면 on이라는 함수의 위치로 이동하여 그 메소드를 확인할 수있다.

5. 다시 처음 파일로 돌아가기 위해 Return을 클릭한다.
→ 디버그 페이지가 종료된다.

[Spring MVC] RequestMapping

WinBro — Thu, 16 Mar 2023 07:50:06 +0900

Spring Framework는 다양한 방식으로 HTTP 요청을 처리할 수 있는데, 그 중에서도 가장 많이 사용되는 방식 중 하나가 RequestMapping 입니다.

RequestMapping은 컨트롤러의 메서드와 HTTP 요청을 매핑시켜주는 애노테이션으로, 이를 통해 Spring은 HTTP 요청을 컨트롤러 메서드와 매핑시켜 해당 메서드를 실행하게 됩니다.

RequestMapping은 다양한 방식으로 사용될 수 있는데, 다음과 같은 방식으로 사용할 수 있습니다.

1. URL 경로 매핑

RequestMapping은 URL 경로와 매핑되는 기능을 수행합니다. URL 경로 매핑은 다음과 같이 사용할 수 있습니다.

단순 경로 :

@RequestMapping("/hello")와 같이 요청 URL 경로를 직접 지정할 수 있습니다.

예를 들어, "/hello" 경로에 대한 요청이 들어오면 해당 메서드가 실행됩니다.

경로 변수 :

@RequestMapping("/users/{id}")와 같이 중괄호({}) 안에 변수 이름을 지정할 수 있습니다.

예를 들어, "/users/123" 경로에 대한 요청이 들어오면, id 변수에 "123" 값이 할당되어 해당 메서드가 실행됩니다. 경로 변수는 여러 개 사용할 수 있으며, @PathVariable 애노테이션을 사용해 변수를 매핑할 수 있습니다.

Ant 스타일 패턴 :

@RequestMapping("/users/")와 같이 와일드카드(*)와 더블 와일드카드()를 사용해 패턴을 지정할 수 있습니다. 예를 들어, "/users/123/orders" 경로에 대한 요청이 들어오면 해당 메서드가 실행됩니다.

2. HTTP Method 매핑

RequestMapping은 HTTP 요청 메서드와도 매핑됩니다. HTTP Method 매핑은 다음과 같이 사용할 수 있습니다.

GET 요청: @RequestMapping(value = "/users", method = RequestMethod.GET)와 같이 value와 method 속성을 사용해 GET 요청에 대한 매핑을 지정할 수 있습니다. @GetMapping("/users")와 같이 간편하게 사용할 수도 있습니다.

POST 요청: @RequestMapping(value = "/users", method = RequestMethod.POST)와 같이 value와 method 속성을 사용해 POST 요청에 대한 매핑을 지정할 수 있습니다. @PostMapping("/users")와 같이 간편하게 사용할 수도 있습니다.

PUT 요청: @RequestMapping(value = "/users/{id}", method = RequestMethod.PUT)와 같이 value와 method 속성을 사용해 PUT 요청에 대한 매핑을 지정할 수 있습니다. @PutMapping("/users/{id}")와 같이 간편하게 사용할 수도 있습니다.

DELETE 요청: @RequestMapping(value = "/users/{id}", method = RequestMethod.DELETE)와 같이 value와 method 속성을 사용해 DELETE 요청에 대한 매핑을 지정할 수 있습니다. @DeleteMapping("/users/{id}")와 같이 간편하게 사용할 수도 있습니다.

3. 파라미터 매핑

RequestMapping은 요청 파라미터에도 매핑됩니다. 요청 파라미터에 대한 매핑은 @RequestParam 애노테이션을 사용해 지정할 수 있습니다. 예를 들어, @RequestMapping("/user") 애노테이션과 함께 @RequestParam("userId") String userId 라는 파라미터가 있다면, "/user?userId=1234"와 같은 요청에 대해 해당 메서드가 실행되어 userId 파라미터에 "1234" 값을 전달받게 됩니다.

Spring MVC에서는 @RequestParam, @PathVariable, @RequestBody 등의 애노테이션을 사용하여 파라미터 매핑을 수행합니다.

@RequestParam
- @RequestParam 애노테이션은 HTTP 요청 파라미터를 메서드 파라미터와 매핑합니다. 이 애노테이션은 다음과 같이 사용할 수 있습니다.
- @RequestParam("파라미터 이름") 타입 변수명: HTTP 요청 파라미터 이름과 메서드 파라미터 이름을 지정합니다.

- @RequestParam(value="파라미터 이름", required=false, defaultValue="기본값") 타입 변수명: value 속성으로 HTTP 요청 파라미터 이름을, required 속성으로 필수 여부를, defaultValue 속성으로 기본값을 지정할 수 있습니다.

@PathVariable
- @PathVariable 애노테이션은 URI 경로 변수를 메서드 파라미터와 매핑합니다. 이 애노테이션은 다음과 같이 사용할 수 있습니다.
- @PathVariable("변수 이름") 타입 변수명: URI 경로 변수 이름과 메서드 파라미터 이름을 지정합니다.

@RequestBody
- @RequestBody 애노테이션은 HTTP 요청 본문을 메서드 파라미터와 매핑합니다. 이 애노테이션은 다음과 같이 사용할 수 있습니다.
- @RequestBody 타입 변수명: HTTP 요청 본문의 내용을 메서드 파라미터 타입으로 변환하여 매핑합니다.

@RequestHeader
- @RequestHeader 애노테이션은 HTTP 요청 헤더를 메서드 파라미터와 매핑합니다. 이 애노테이션은 다음과 같이 사용할 수 있습니다.
- @RequestHeader("헤더 이름") 타입 변수명: HTTP 요청 헤더 이름과 메서드 파라미터 이름을 지정합니다.
- @RequestHeader(value="헤더 이름", required=false, defaultValue="기본값") 타입 변수명: value 속성으로 HTTP 요청 헤더 이름을, required 속성으로 필수 여부를, defaultValue 속성으로 기본값을 지정할 수 있습니다.

이러한 파라미터 매핑 애노테이션을 사용하면 HTTP 요청 파라미터, 경로 변수, 요청 본문 등을 메서드 파라미터와 쉽게 매핑할 수 있습니다. 이를 통해 컨트롤러 메서드에서 HTTP 요청을 처리할 때 매우 편리하게 사용할 수 있습니다.

출처 : 스프링 MVC 1편 - 백엔드 웹 개발 핵심 기술

[Spring] @Controller와 @RestController 차이

WinBro — Wed, 15 Mar 2023 08:23:47 +0900

Spring에서 컨트롤러를 지정해주기 위한 어노테이션은 @Controller와 @RestController가 있습니다.

전통적인 Spring MVC의 컨트롤러인 @Controller와 Restuful 웹서비스의 컨트롤러인 @RestController의 주요한 차이점은 HTTP Response Body가 생성되는 방식입니다.

이번에는 2가지 어노테이션의 차이와 사용법에 대해 알아보도록 하겠습니다.

1. @Controller 이해하기

[ Controller로 View 반환하기 ]

전통적인 Spring MVC의 컨트롤러인 @Controller는 주로 View를 반환하기 위해 사용합니다. 아래와 같은 과정을 통해 Spring MVC Container는 Client의 요청으로부터 View를 반환합니다.

Client는 URI 형식으로 웹 서비스에 요청을 보낸다.
DispatcherServlet이 요청을 위임할 HandlerMapping을 찾는다.
HandlerMapping을 통해 요청을 Controller로 위임한다.
Controller는 요청을 처리한 후에 ViewName을 반환한다.
DispatcherServlet은 ViewResolver를 통해 ViewName에 해당하는 View를 찾아 사용자에게 반환한다.

Controller가 반환환 뷰의 이름으로부터 View를 렌더링하기 위해서는 ViewResolver가 사용되며, ViewResolver 설정에 맞게 View를 찾아 렌더링합니다.

[ Controller로 Data 반환하기 ]

하지만 Spring MVC의 컨트롤러를 사용하면서 Data를 반환해야 하는 경우도 있습니다. 컨트롤러에서는 데이터를 반환하기 위해 @ResponseBody 어노테이션을 활용해주어야 합니다. 이를 통해 Controller도 Json 형태로 데이터를 반환할 수 있습니다.

Client는 URI 형식으로 웹 서비스에 요청을 보낸다.
DispatcherServlet이 요청을 위임할 HandlerMapping을 찾는다.
HandlerMapping을 통해 요청을 Controller로 위임한다.
Controller는 요청을 처리한 후에 객체를 반환한다.
반환되는 객체는 Json으로 Serialize되어 사용자에게 반환된다.

컨트롤러를 통해 객체를 반환할 때에는 일반적으로 ResponseEntity로 감싸서 반환을 합니다. 그리고 객체를 반환하기 위해서는 viewResolver 대신에 HttpMessageConverter가 동작합니다. HttpMessageConverter에는 여러 Converter가 등록되어 있고, 반환해야 하는 데이터에 따라 사용되는 Converter가 달라집니다. 단순 문자열인 경우에는 StringHttpMessageConverter가 사용되고, 객체인 경우에는 MappingJackson2HttpMessageConverter가 사용되며, 데이터 종류에 따라 서로 다른 MessageConverter가 작동하게 됩니다. Spring은 클라이언트의 HTTP Accept 헤더와 서버의 컨트롤러 반환 타입 정보 둘을 조합해 적합한 HttpMessageConverter를 선택하여 이를 처리합니다. MessageConverter가 동작하는 시점은 HandlerAdapter와 Controller가 요청을 주고 받는 시점이다. 그림의 4번에서는 메세지를 객체로, 6번에서는 객체를 메세지로 변환하는데 메세지 컨버터가 사용된다.

[ @Controller 예제 코드 ]

@Controller
@RequiredArgsConstructor
public class UserController {

    private final UserService userService;

    @GetMapping(value = "/users")
    public @ResponseBody ResponseEntity<User> findUser(@RequestParam("userName") String userName){
        return ResponseEntity.ok(userService.findUser(user));
    }
    
    @GetMapping(value = "/users/detailView")
    public String detailView(Model model, @RequestParam("userName") String userName){
        User user = userService.findUser(userName);
        model.addAttribute("user", user);
        return "/users/detailView";
    }
}

위 예제의 findUser는 User 객체를 ResponseEntity로 감싸서 반환하고 있고, User를 json으로 반환하기 위해 @ResponseBody라는 어노테이션을 붙여주고 있습니다. detailView 함수에서는 View를 전달해주고 있기 때문에 String을 반환값으로 설정해주었습니다. (물론 이렇게 데이터를 반환하는 RestController와 View를 반환하는 Controller를 분리하여 작성하는 것이 좋습니다.)

2. @RestController 이해하기

[ RestController ]

@RestController는 @Controller에 @ResponseBody가 추가된 것입니다. 당연하게도 RestController의 주용도는 Json 형태로 객체 데이터를 반환하는 것입니다. 최근에 데이터를 응답으로 제공하는 REST API를 개발할 때 주로 사용하며 객체를 ResponseEntity로 감싸서 반환합니다. 이러한 이유로 동작 과정 역시 @Controller에 @ReponseBody를 붙인 것과 완벽히 동일합니다.

Client는 URI 형식으로 웹 서비스에 요청을 보낸다.
DispatcherServlet이 요청을 위임할 HandlerMapping을 찾는다.
HandlerMapping을 통해 요청을 Controller로 위임한다.
Controller는 요청을 처리한 후에 객체를 반환한다.
반환되는 객체는 Json으로 Serialize되어 사용자에게 반환된다.

[ @RestController 예제 코드 ]

@RestController
@RequestMapping("/user")
@RequiredArgsConstructor
public class UserController {

    private final UserService userService;

    @GetMapping(value = "/users")
    public User findUser(@RequestParam("userName") String userName){
        return userService.findUser(user);
    }

    @GetMapping(value = "/users")
    public ResponseEntity<User> findUserWithResponseEntity(@RequestParam("userName") String userName){
        return ResponseEntity.ok(userService.findUser(user));
    }
}

findUser는 User 객체를 그대로 반환하고 있습니다. 이러한 경우의 문제는 클라이언트가 예상하는 HttpStatus를 설정해줄 수 없다는 것입니다. 예를 들어 어떤 객체의 생성 요청이라면 201 CREATED를 기대할 것이지만 객체를 그대로 반환하면 HttpStatus를 설정해줄 수 없습니다. 그래서 객체를 상황에 맞는 ResponseEntity로 감싸서 반환해주어야 합니다.