쟈쟈의 코딩일기

CRUD

Create 저장

Read 열람

Update 변경

Destroy 삭제

우리가 쓰는 모든 웹 서비스의 바탕이 CRUD로 이루어졌다 보아도 무관하다.

스프링부트(Springboot)는 MVC 구조(모델, 뷰, 컨트롤러)를 가지고 사용자의 요청을 받아서 컨트롤러가 전달한 뒤, 데이터베이스가 전달한 데이터를 기록할 수 있도록 구성되어있다.

스프링부트에서 우리가 설계한 모델을 데이터베이스에 어떤 식으로 적용하게 되는지 알아보자.

스프링부트와는 RDBMS라고 하는 관계형 데이터베이스를 주로 사용한다. 관계형 데이터베이스는 표 형식으로 데이터를 관리하는 데이터베이스로 행, 열로 구성되어있으며 각각의 attribute(속성)에 대한 값을 한줄한줄 객체로 기록해놓는다. 대부분의 시스템에서 사용하고 있으며 Sqlite, mySQL, Postgresql 등 다양한 종류의 RDBMS가 출시되었다.

Row(행) - 개별 객체

Column(열) - 항목(attributes, fields)Table - 표 전체. 데이터를 모아놓은 구조.

운영환경에 레포트하는 어플리케이션은 취약점이나 보안이 노출될 수 있기 때문에 로그를 자세히 띄워주지 않는데 개발환경에서는 Debug로 설정하여 로그를 자세하게 볼 수 있도록 한다.

실제로 데이터베이스를 사용하는 것은 H2라는 데이터베이스를 사용한다. H2 베이스는 인메모리 방식으로 사용할 수 있는 빠른 데이터베이스이다. 상용에는 적합하지 않지만 개발에서는 활용할 수 있는 데이터베이스이다.

JPA는 스프링부트에서 데이터베이스와 연동을 하기 위한 중간 매개체이다.

h2 콘솔 enabled를 true로 준 이유는 브라우저를 통해 h2 콘솔에 접속하여 실제 데이터베이스가 어떻게 접속되었는지 확인해 볼 수 있다.

Spring Boot 이전에 Spring은 Java 오픈소스 어플리케이션 프레임워크에서 출발했다.

엔터프라이즈급 어플리케이션을 정해진 규칙이나 설계에 따라 개발했을 때, 견고하고 안정적인 서비스가 개발 가능하다는 장점으로 많은 환영을 받았다. 그런데 기존 스프링은 웹 개발에 필요한 설정이 너무 복잡하고 일일이 메뉴얼을 추가하고 확인해야하는 문제가 있었다. 그래서 스프링의 하위 프로젝트로 웹 개발에 최적화된 Spring Boot라고 하는 프로젝트가 발표되었다.

Spring Boot는 웹 개발에 필요한 설정을 어노테이션(@) 등으로 간편하게 처리할 수 있게 되었다. 어노테이션을 사용하면 불필요하게 설정을 입력하는 반복작업을 줄일 수 있다. 각종 의존성은 스프링이 모두 도맡아서 관리하며 톰캣 웹 서버가 내장되어 있어 별도의 세팅이 불필요하다.

Spring Boot 프로젝트 생성

1. 프로젝트를 선택하고 언어와 버전을 선택한 뒤, 프로젝트 정보를 입력한다.

2. 디펜던시에서 Spring WEB, 데이터 베이스를 연동하기 위한 JPA, 우리가 사용할 H2 Database를 추가한 뒤, Generate를 누른다.

3. 압축을 풀어 IntelliJ에서 실행한다.

4. main - java에서 프로젝트를 실행하고 인터넷 주소창에 localhost:8080을 입력하여 접근한다.

네트워크

네트워크는 우리가 만들어나갈 웹서비스의 밑바탕이다. 두 대 이상의 컴퓨터가 연결된 통신망를 네트워크라고 한다. 인터넷에 꼭 접속되지 않더라도 내 컴퓨터와 다른 컴퓨터를 연결한 것 자체가 작은 네트워크를 구성한 것이라 볼 수 있다.

네트워크에서 중요한 것은 어떤 방식으로 어떻게 데이터가 오가는지 이해하는 것이 핵심이다. 구성된 네트워크에서 연결된 개별 컴퓨터를 호스트(host)라고 한다. 많은 컴퓨터를 하나의 네트워크망 안에 구성하기 위해서는 연결을 위한 매개체가 필요하다. 하나로 묶어주는 것을 스위치(switch)라고 한다. 동일한 네트워크에서 호스트 간의 통신을 가능하게 해준다. 그러나 다른 네트워크에는 접선할 수 없다. 그래서 라우터(router)가 등장했다. 네트워크를 구성하는 스위치의 기능을 포함하고 있으며 서로 다른 네트워크 간에 통신을 할 수 있도록 한다. 우리에게 친숙한 이름으로 공유기라고도 불린다. 그렇게 네트워크와 네트워크가 연결된 거대한 통신망을 인터넷(internet)이라고 한다. 

IP 주소

Internet Protocol

컴퓨터 간 데이터를 주고 받는 네트워크 계층의 규약

네트워크 계층의 규약에 따라 데이터 전달에 필요한 목적지 컴퓨터 정보가 반드시 필요하다.

송신자가 수신자에게 우편을 보내기 위해 우체국에 필요한 정보를 넘겨야한다. 이때 가장 중요한 정보는 수신자 주소이다. 송신자가 우체국에 정보를 전달하면, 우체국은 수신자 주소에 문제가 없다면 수신자에게 우편을 전달한다. 만약 수신자 주소를 잘못 전달한다면 우체국에서는 수신자에게 우편을 수신할 수 없게 되고 송신자에게 다시 반송한다.

컴퓨터가 다른 컴퓨터에 요청할 때에는 식별할 수 있는 고유한 주소를 가져야한다. 네트워크에서 컴퓨터가 부여받는 고유한 주소를 IP 주소라고 한다.

IP 주소에는 크게 두 가지 종류가 있다. IPv4 체계에서는 32bit의 용량을 가질 수 있다. 초창기 인터넷과는 달리 IT 서비스가 급성장을 하고 환경이 급변하게 되면서 전세계의 주소자원, IP 주소자원이 매우 부족해지게 됐다. 그래서 이를 대체할 수 있는 128bit의 IPv6가 나오게 된다. IPv6는 아직 자리잡기 못해 IPv4와 병행 중이다.

IP 주소의 구조(IPv4 기준)

IP 주소는 2진수로 이루어져있다. 실제 활용할 때는 10진수로 변환한 값을 활용한다.

2진수 IP를 8비트씩 분할하면 4개로 구성된다. 여기서 분할된 1byte(=8bit)는 옥텟(octet)이라고 한다. 즉, 4개의 옥텟으로 구성된다. 이 4개의 옥텟으로 분할된 각각의 값을 2진수에서 10진수로 변환한 다음, 마침표로 구분해주면 우리가 사용하는 IP 주소의 형태가 된다.

각 마디의 숫자는 0부터 255까지의 범위를 가지고 있다. 이 범위를 벗어난 숫자로 된 IP 주소는 잘못된 IP 주소이다.

공인 IP vs 사설 IP

일반적인 가정에서는 대부분 SK나 KT, LG U+ 등에서 제공하는 인터넷 서비스에 가입하여 사용한다. 이렇게 인터넷 서비스를 제공하는 업체를 ISP(Internet Service Provider)라고 한다. ISP는 우리가 사용하고 있는 공유기나 컴퓨터에 공인 IP를 할당한다. 공인 IP(Public IP)는 전체 인터넷 망에서 고유하게 식별 가능한 주소이다. 어떠한 컴퓨터, 모바일 환경에서든 인터넷이 연결된 환경에서는 IP가 동일한 곳을 가르킨다. 그러나 공인 IP가 전체 인터넷 망에서 사용되고 있기 때문에 IPv4 체계에서는 자원이 부족하다. 그래서 유효 자원수가 모자라서 IPv6가 등장했다.

우리가 사용하고 있는 컴퓨터는 공인 IP를 사용하고 있을까? 사실은 그렇지 않다. 일반적으로 인터넷이 연결된 컴퓨터는 공인 IP 대신 사설 IP를 할당받는다. 공인 IP를 할당받은 공유기에서 컴퓨터, 모바일 등 다양한 기기들에게 새로운 네트워크의 IP를 할당받는다. 그렇게 하면 공인 IP를 굳이 모든 장비가 받지 않아도 인터넷 환경에 접근할 수 있기 때문에 효율적으로 IPv4의 주소자원을 관리할 수 있게 된다. 즉, 하나의 공인 IP에서 수많은 사설 IP 할당이 가능하다.

사설 IP(Private IP)는 가정의 LAN과 같은 네트워크에서 할당되는 주소이다. 컴퓨터에서 조회하면 나오는 IP이다. 사설 IP가 인터넷 환경이 아니라 LAN과 같은 소규모 네트워크 환경에서 유효한 주소이기 때문에 외부와 통신할 때만 이 공유기에 할당된 공인 IP를 활용하기 때문에 내가 사용하고 있는 IP 주소를 명령어로 조회해보면 라우터에서 부여한 사설 IP가 조회된다. 즉, 내가 연결한 공유기 안에서만 유효하며 인터넷 환경에서 가르키는 IP 주소가 아니다.

내 컴퓨터가 외부에 빛춰지는 공인 IP는 네이버에 내 IP라고 검색하면 IP 주소를 조회할 수 있다. 실제로 내 PC에서 다른 외부 서버를 접근할 때, 제한되는 방화벽 등의 조건들을 해제할 때에는 반드시 공인 IP를 기준으로 등록해야 방화벽이 해제 또는 설정된다.

127.0.0.1(Localhost)

컴퓨터의 관점에서 자기자신을 가르키기 위해 약속된 IP 주소

특정 컴퓨터, 즉 내가 사용하는 내 컴퓨터에서만 유효한 이름이다. 이 네트워크 내역을 조회해보면 lo라는 이름으로 IP 127.0.0.1이 조회되는 것을 확인할 수 있다. lo는 Loopback Network Interface에서 비롯된 네트워크 명칭으로, 컴퓨터 관점에서 자기자신인 로컬호스트를 의미한다.

Port

하나의 컴퓨터에는 다양한 서비스가 실행 중이다.

컴퓨터를 특정할 수 있는 IP 주소만으로는 실행되고 있는 다양한 서비스 중에 어떤 곳에 데이터를 보내고 요청 해야하는지 알 수 없다. Port는 하나의 컴퓨터에서 실행되고 있는 다양한 어플리케이션 서비스를 구분하는 역할을 한다. 대표적으로 할당된 포트 번호 예시로는 HTTP(80), HTTPS(443), SMTP(25), FTP(21) 등이 있다. 웹서비스를 개발 할 때 다른 서버와 통신을 해야할 때가 있다. 접근하려는 목적지 IP와 Port를 정확하게 설정해야한다.

DNS

일반적으로 상용 서비스의 공인 IP는 보안 등의 이유로 공개되지 않는다. 우리가 사용하는 것은 문자열로 되어있는 주소이다. 그렇다면 알파벳으로 이루어진 URL로 어떻게 웹서버의 위치를 정확히 파악할 수 있는 것일까?

DNS(Domain Name Server)는 URL을 해석하여 IP 주소로 반환하는 역할을 하는 서버이다. 사용자가 주소창에 URL을 입력하면 먼저 DNS 서버로 가서 매칭되는 IP 주소가 있는지 찾는다. 이 DNS는 전세계에 분포 되어있으며 첫 번째로 탐색한 DNS 서버에 웹핑 정보가 없으면 다른 DNS 서버를 돌아다니며 주소를 찾게 된다. DNS 서버에서 URL과 맵핑된 IP 주소를 찾게 되면 이 IP 주소를 브라우저로 전달한다. 최종적으로 브라우저는 DNS로부터 전달받은 IP를 통해 홈페이지에 접속하게 된다. 즉, URL이나 IP 주소 모두 어떤 서버, 클라이언트(컴퓨터)의 위치를 특정하는 역할을 한다. 우리가 통상 사용하는 URL을 사용할 때, IP 주소로 반환해주는 역할을 하는 DNS 서버가 있다.DNS 서버는 전세계적으로 국가, 기업, 클라우드 사업자 등이 운영한다. URL에 대한 IP 주소를 반환하는 성능을 향상시키기 위해 여러가지 알고리즘이 활용되거나 하드웨어적인 개선을 하기도 한다. DNS 서버에 장애가 발생하면 막대한 피해로 이어진다.

클라이언트에서 서버에 로그인 요청을 보내고 서버에서 로그인의 성공 응답을 보내주는 로그가 있다고 가정해보자.

로그인 인증정보가 맞다면 사용자는 화면에서 로그인을 성공했다는 화면을 확인 할 수 있다. 그런데 우리는 서버로부터 로그인 성공 화면 외에도 다른 것들을 받는다. 그 대표적인 것으로 쿠키(cookie)가 있다.

쿠키

쿠키는 서버에서 클라이언트로 보내져서 브라우저에 저장되는 아주 작은 크기의 데이터이다.

쿠키는 속성을 나타내는 키와 그 속성에 해당되는 값을 가지고 있으며, 명시된 유효기간이 만료된 시점에 브라우저에서 삭제되는 특징을 가지고 있다.

우리가 로그인을 성공한 이후의 작업을 가정해보자. 쇼핑사이트를 예시로 들면 장바구니를 이동하거나 여러 물품을 검색하거너ㅏ 개인정보를 수정하는 등 페이지를 이동할 것이다. 클라이언트가 자유롭게 페이지를 이동하며 여러가지 자원을 활용할 수 있는 이유는 로그인을 성공하여 회원임을 인증하였기 때문이다. 그러나 장바구니에 이동하는 회원이 로그인을 성공했다는 것을 클라이언트와 서버가 요청 자체는 기억하지 못한다. HTTP 통신에서는 각각의 요청과 응답이 독립적이다. 그렇기 때문에 이전의 작업을 기록하지 못한다. HTTP는 각각의 요청과 응답이 종료되었을 때, 연결이 지속되지 않고 상태를 기억하지 않는다는 특징을 가지고 있는데 이것을 Stateless 혹은 무상태성이라고 한다. 수천 명, 수만 명이 동시에 서버에 접속하면 거대한 컴퓨팅 리소스를 하게 되며 서버가 온전히 버틸 수 없는 상태가 될 것이다. 그렇기 때문에 Stateless 속성이 리소스 측면에서는 효율적이다. 그리고 요청을 어딘가에 남기기 위해 고안된 것이 바로 쿠키이다.

서버가 클라이언트에게 작업을 성공해서 데이터를 보내겠다는 쿠키를 보내면, 쿠키를 받은 클라이언트는 로그인을 하고 다른 페이지로 이동해도 로그인이 풀리지 않게 된다. 쿠키가 없었다면 페이지를 이동할 때마다 로그인을 해야할 것이다. 브라우저에 저장된 쿠키에 의해 클라이언트는 로그인 했거나 장바구니에 물건을 추가하는 등 서버와 있었던 작업들을 받게 되고 서버는 다시 클라이언트에서 보낸 쿠키 정보에 따라 작업을 기억하고 다시 브라우저에 내용을 띄워주는 역할을 한다.

그러나 쿠키는 취약점이 노출되거나 악의적인 공격에 악용될 수 있어 민감한 데이터들은 최대한 남기지 않도록 해야한다. 서버에서만 쿠키값을 조작할 수 있도록 하는 httpOnly 옵션이나 보안연결에서만 쿠키값을 전송하는 secure를 활용하는 것이 좋다. 해킹이나 사용자 변조, 위장의 피해가 발생하지 않도록 하기 위해 개발자로 하여금 쿠키를 적절하게 활용하는 것이 중요하다.

세션

쿠키의 한계점을 보안하기 위해 나온 개념이다.

클라이언트에서 로그인 요청을 보내고 성공하게 되면 서버에서는 여러가지 정보들을 주는 것이 아니라 세션 아이디만 쿠키에 실어보낸다. 클라이언트의 상태를 나타내는 나머지 쿠키 데이터들은 서버 측의 세션 저장소에서 가지고 있는다. 클라이언트에서 불필요한 민감 정보나 보안에 접촉되는 데이터를 담지 않고 서버에서 세션 아이디를 받고 그 세션 아이디에 해당되는 정보를 찾아 활용하게 된다.

만약 로그인 이력이 있는 브라우저에서 다시 로그인 요청을 하게 되면 서버에서 세션 아이디가 세션 저장소에 있는지 먼저 찾아보고 아이디가 있다면 거기에 저장된 상태 데이터들을 기반으로 클라이언트에 응답한다.

세션은 민감한 정보가 클라이언트에 저장되거나 노출되어 변조되는 것을 방지하고 클라이언트가 매번 요청 시에 쿠키값을 보내는 리소스 비용을 절감한다. 그런데 세션 저장소는 서버 측 입장에서는 또하나의 비용이 들 수 있다. 그래서 서버 측에서 세션 저장소를 운용하는 가용성과 설계가 서버 성능에 영향을 미치거나 운영비에 변동을 줄 수 있다.