1. 해시 조인 (Hash Join)

개요: 해시 조인은 대용량 테이블 조인에 적합하며, 두 테이블 중 하나가 메모리에 적합할 때 사용됩니다. 이는 주로 조인 조건이 = (등호)일 때 사용됩니다.

작동 방식:

1. 빌드 단계:

   • 더 작은 테이블을 선택합니다(일반적으로 더 작은 테이블을 메모리에 올리기 쉽기 때문입니다).
   • 이 테이블의 조인 컬럼을 기반으로 해시 테이블을 생성합니다. 해시 함수는 입력값을 특정 버킷(bucket)으로 매핑합니다. 이 버킷은 실제 메모리 내의 저장 위치를 나타냅니다.
   • 각 행의 조인 키를 해시 함수에 입력하여 해시 값을 계산하고, 그 해시 값을 사용하여 해당 행을 해시 테이블에 저장합니다.

2. 프로브 단계:

   • 큰 테이블의 각 행을 읽고, 해당 행의 조인 키에 해시 함수를 적용하여 해시 값을 얻습니다.
   • 그 해시 값을 사용하여 해시 테이블에서 일치하는 버킷을 찾습니다.
   • 버킷에서 해당 행이 존재하는지 확인하고, 조인 조건에 부합하는 행이 있다면 두 행을 결합하여 결과 집합에 추가합니다.

장점:

• 매우 빠른 조회가 가능하며, 대량의 데이터를 다룰 때 효율적입니다.

단점:

• 메모리 사용량이 많을 수 있습니다.
• 해시 테이블을 생성하는 데 시간이 소요될 수 있습니다.

예시: 고객 정보와 주문 정보를 조인한다고 가정할 때, 고객 정보가 메모리에 올릴 수 있는 크기라면 고객 정보를 해시 테이블로 만들어 주문 정보의 각 행을 탐색하며 일치하는 고객 정보를 찾습니다.

2. 중첩 루프 조인 (Nested Loop Join)

개요: 중첩 루프 조인은 가장 기본적이고 직관적인 조인 방법으로, 두 테이블을 비교하여 조인하는 방식입니다. 두 테이블의 모든 조합을 비교하기 때문에 성능은 비교적 떨어질 수 있습니다.

작동 방식:

1. 외부 루프:

   • 첫 번째(외부) 테이블의 각 행을 순차적으로 선택합니다.

2. 내부 루프:

   • 두 번째(내부) 테이블의 각 행을 선택하고, 외부 테이블의 현재 행과 비교합니다.
   • 두 행이 조인 조건을 만족하면 이 두 행을 결합하여 결과에 추가합니다.

장점:

• 구현이 간단하며, 작은 테이블이나 인덱스가 있는 경우 매우 효과적입니다.

단점:

• 두 테이블의 크기가 크면 비효율적이며, 성능이 저하됩니다. 이는 모든 행의 모든 조합을 비교하기 때문입니다.

예시: 제품 정보와 그 제품의 공급업체 정보를 조인할 때, 각 제품을 하나씩 읽어 해당 제품을 공급하는 공급업체를 하나씩 비교하여 찾습니다.

3. 병합 조인 (Merge Join)

개요: 병합 조인은 두 테이블이 조인 키로 정렬되어 있을 때 사용하는 조인 방식입니다. 정렬된 데이터를 순차적으로 읽으며 조인을 수행하기 때문에 대용량의 정렬된 데이터를 조인할 때 매우 효율적입니다.

작동 방식:

1. 정렬:

   • 두 테이블이 조인 키로 정렬되어 있어야 합니다. 정렬이 되어 있지 않으면 먼저 정렬합니다.

2. 순차 비교:

   • 각 테이블의 시작 지점에서부터 조인 키를 비교합니다.
   • 두 테이블의 조인 키가 같으면, 해당 행들을 결합하여 결과에 추가합니다. 이후, 두 테이블 모두 다음 행으로 이동합니다.
   • 만약 한 테이블의 조인 키가 더 작다면, 작은 키의 테이블만 다음 행으로 이동하여 비교를 계속합니다.

장점:

• 데이터가 정렬되어 있다면 매우 효율적입니다.
• 대량의 데이터를 처리할 때 성능이 뛰어납니다.

단점:

• 데이터가 정렬되지 않은 경우, 정렬하는 데 추가적인 비용이 발생합니다.

예시: 판매 데이터와 고객 데이터를 조인할 때, 두 데이터가 고객 ID로 이미 정렬되어 있다면, 첫 번째 고객부터 순차적으로 비교하여 조인 결과를 생성합니다.

최종 정리

이 세 가지 조인 방식은 각각의 데이터 크기, 정렬 여부, 인덱스 존재 여부 등에 따라 적절히 선택되어야 합니다. 데이터베이스 엔진은 이러한 정보를 기반으로 최적의 조인 방식을 자동으로 선택하여 쿼리 성능을 최대화합니다. 조인을 잘 이해하고 있으면 SQL 쿼리의 성능을 향상시키는 데 큰 도움이 됩니다.

OSI (Open Systems Interconnection) 모델은 네트워크 통신의 표준을 정립한 모델로, 네트워크 시스템 간의 상호 운용성을 보장하기 위해 7개의 계층으로 나누어 설명한다. 각 계층은 특정한 네트워크 기능을 담당하며, 상호 간의 의사소통을 위해 표준화된 인터페이스를 제공한다.

1. 물리 계층 (Physical Layer)

• 역할: 네트워크 하드웨어와 관련된 모든 것, 즉 물리적인 전송 매체와 신호 변환을 담당.
• 주요 기능:
  • 비트 스트림 전송
  • 전기적, 기계적, 기능적 사양 정의 (케이블, 스위치, 허브 등)
  • 데이터 전송 속도와 물리적 연결 관리
• 예시: Ethernet, USB, RS-232

2. 데이터 링크 계층 (Data Link Layer)

• 역할: 네트워크 기기 간의 데이터 전송과 오류 검출 및 수정 기능 담당.
• 주요 기능:
  • 프레임화 (Framing): 데이터 단위를 프레임으로 분할
  • 물리 주소 지정 (MAC 주소)
  • 오류 검출 및 수정 (CRC, Parity Bit 등)
  • 흐름 제어
• 예시: Ethernet (IEEE 802.3), Wi-Fi (IEEE 802.11), PPP

3. 네트워크 계층 (Network Layer)

• 역할: 데이터가 여러 네트워크를 통해 목적지에 도달할 수 있도록 경로 결정.
• 주요 기능:
  • 라우팅 (Routing): 경로 설정 및 데이터 전달
  • 논리 주소 지정 (IP 주소)
  • 패킷 포워딩
  • 혼잡 제어
• 예시: IP (Internet Protocol), ICMP, ARP

4. 전송 계층 (Transport Layer)

• 역할: 종단 간 (end-to-end) 통신 제공 및 데이터의 신뢰성 있는 전송 보장.
• 주요 기능:
  • 세그멘테이션과 재조립 (Segmentation and Reassembly)
  • 연결 설정, 유지, 해제 (TCP)
  • 흐름 제어와 오류 제어
  • 데이터 전송의 신뢰성 보장
• 예시: TCP (Transmission Control Protocol), UDP (User Datagram Protocol)

5. 세션 계층 (Session Layer)

• 역할: 통신 세션을 설정, 관리, 종료하는 역할.
• 주요 기능:
  • 세션 설정 및 종료
  • 데이터 교환 관리 (반이중 또는 전이중 모드)
  • 체크포인팅과 복구
• 예시: NetBIOS, PPTP

6. 표현 계층 (Presentation Layer)

• 역할: 데이터의 형식화 및 변환을 담당하여 서로 다른 시스템 간의 데이터 호환성 제공.
• 주요 기능:
  • 데이터 암호화 및 복호화
  • 데이터 압축
  • 데이터 형식 변환 (예: 문자 인코딩, 이미지 포맷 변환)
• 예시: JPEG, MPEG, GIF, TLS/SSL

7. 응용 계층 (Application Layer)

• 역할: 사용자와 직접 상호작용하는 애플리케이션과 관련된 기능 제공.
• 주요 기능:
  • 네트워크 서비스 요청 및 응답
  • 사용자 인터페이스 제공
  • 데이터 처리 및 애플리케이션 로직 구현
• 예시: HTTP, FTP, SMTP, DNS, Telnet

이러한 계층화된 접근 방식은 네트워크 통신의 복잡성을 줄이고, 각 계층의 표준화된 인터페이스를 통해 다양한 시스템 간의 상호 운용성을 보장합니다. 각 계층은 자신의 특정 역할을 수행하며, 다른 계층과 독립적으로 동작하여 네트워크 통신의 유연성과 효율성을 높인다.

REST는 Representation State Transfer라는 용어의 약자로 웹(HTTP)의 장점을 최대한 활용할 수 있는 아키텍처

2. REST 구성

• 자원(RESOURCE) - URI
• 행위(Verb) - HTTP METHOD
• 표현(Presentations)

3. REST의 특정

1) Uniform (유니폼 인터페이스) Uniform Interface는 URI로 지정한 리소스에 대한 조작을 통일되고 한정적인 인터페이스로 수행하는 아키텍처 스타일을 말합니다.

2) Stateless (무상태성) REST는 무상태성 성격을 갖습니다. 다시 말해 작업을 위한 상태정보를 따로 저장하고 관리하지 않습니다. 세션 정보나 쿠키정보를 별도로 저장하고 관리하지 않기 때문에 API 서버는 들어오는 요청만을 단순히 처리하면 됩니다. 때문에 서비스의 자유도가 높아지고 서버에서 불필요한 정보를 관리하지 않음으로써 구현이 단순해집니다.

3) Cacheable (캐시 가능) REST의 가장 큰 특징 중 하나는 HTTP라는 기존 웹표준을 그대로 사용하기 때문에, 웹에서 사용하는 기존 인프라를 그대로 활용이 가능합니다. 따라서 HTTP가 가진 캐싱 기능이 적용 가능합니다. HTTP 프로토콜 표준에서 사용하는 Last-Modified태그나 E-Tag를 이용하면 캐싱 구현이 가능합니다.

4) Self-descriptiveness (자체 표현 구조) REST의 또 다른 큰 특징 중 하나는 REST API 메시지만 보고도 이를 쉽게 이해 할 수 있는 자체 표현 구조로 되어 있다는 것입니다.

5) Client - Server 구조 REST 서버는 API 제공, 클라이언트는 사용자 인증이나 컨텍스트(세션, 로그인 정보)등을 직접 관리하는 구조로 각각의 역할이 확실히 구분되기 때문에 클라이언트와 서버에서 개발해야 할 내용이 명확해지고 서로간 의존성이 줄어들게 됩니다.

6) 계층형 구조 REST 서버는 다중 계층으로 구성될 수 있으며 보안, 로드 밸런싱, 암호화 계층을 추가해 구조상의 유연성을 둘 수 있고 PROXY, 게이트웨이 같은 네트워크 기반의 중간매체를 사용할 수 있게 합니다.

4. REST API 디자인 가이드

REST API 설계 시 가장 중요한 항목은 다음의 2가지로 요약할 수 있습니다.

첫 번째, URI는 정보의 자원을 표현해야 한다. 두 번째, 자원에 대한 행위는 HTTP Method(GET, POST, PUT, DELETE)로 표현한다.

4-1. REST API 중심 규칙

1) URI는 정보의 자원을 표현해야 한다. (리소스명은 동사보다는 명사를 사용)

GET /member/delete/1

위와 같은 방식은 REST를 제대로 적용하지 않은 URI입니다. URI는 자원을 표현하는데 중점을 두어야 합니다. delete와 같은 행위에 대한 표현이 들어가서는 안됩니다.

2) 자원에 대한 행위는 HTTP Method(GET, POST, PUT, DELETE 등)로 표현

위의 잘못 된 URI를 HTTP Method를 통해 수정해보면

DELETE /member/1

으로 수정할 수 있습니다.

회원정보를 가져올 떄는 GET, 회원 추가 시의 행위를 표현하고자 할 때는 POST Method를 사용하여 표현합니다.

회원정보를 가져오는 URI

GET /member/show/1 (X)
GET /member/1      (O)

회원을 추가할 때

GET /member/insert/2 (X) - GET 메서드는 리소스 생성에 맞지 않습니다.
POST /member/2.      (O)

[참고]HTTP METHOD의 알맞은 역할 POST, GET, PUT, DELETE 이 4가지의 Method를 가지고 CRUD를 할 수 있습니다.

다음과 같은 식으로 URI는 자원을 표현하는 데에 집중하고 행위에 대한 정의는 HTTP METHOD를 통해 하는 것이 REST한 API를 설계하는 중심 규칙입니다.

4-2.URI 설계 시 주의할 점

1) 슬래시 구분자(/)는 계층 관계를 나타내는 데 사용

http://restapi.example.com/houses/apartments
http://restapi.example.com/animals/mammals/whales

2) URI 마지막 문자로 슬래시(/)를 포함하지 않는다.

URI에 포함되는 모든 글자는 리소스의 유일한 식별자로 사용되어야 하며 URI가 다르다는 것은 리소스가 다르다는 것이고, 역으로 리소스가 다르면 URI도 달라져야 합니다. REST API는 분명한 URI를 만들어 통신을 해야 하기 때문에 혼동을 주지 않도록 URI 결로의 마자막에는 슬래시(/)를 사용하지 않습니다.

 http://restapi.example.com/houses/apartments/ (X)
 http://restapi.example.com/houses/apartments  (0)

3) 하이픈(-)은 URI 가독성을 높이는데 사용

URI를 쉽게 읽고 해석하기 위해, 불가피하게 긴 URI경로를 사용하게 된다면 하이픈을 사용해 가독성을 높을 수 있습니다.

4) 밑줄(_)은 URI에 사용하지 않는다.

글꼴에 따라 다르긴 하지만 밑줄은 보기 어렵거나 밑줄 때문에 문자가 가려지기도 합니다. 이런 문제를 피하기 위해 밑줄 대신 하이픈(_)을 사용하는 것이 좋습니다.(가독성)

5) URI 경로에는 소문자가 적합하다.

URI 경로에 대문자 사용은 피하도록 해야 합니다. 대소문제에 따라 다른 리소스로 인식하게 되기 때문입니다. RFC 3986(URI 문법 형식)은 URI 스키마와 호스트를 제회하고는 대소문자를 구별하도록 규정하기 때문입니다.

RFC 3986 is the URI (Unified Resource Identifier) Syntax document

6) 파일 확장자는 URI에 포함하지 않는다.

    http://restapi.example.com/members/soccer/345/photo.jpg (X)

REST API에서는 메시지 바디 내용의 포맷을 나타내기 위한 파일 확장자를 URI 안에 포함시키지 않습니다. Accept header를 사용하도록 합니다.

    GET / members/soccer/345/photo HTTP/1.1 Host: restapi.example.com Accept: image/jpg

4-3.리소스 간의 관계를 표현하는 방법

REST 리소스 간에는 연관 관계가 있을 수 있고, 이런 경우 다음과 같은 표현방법으로 사용합니다.

    /리소스명/리소스 ID/관계가 있는 다른 리소스명

    ex)    GET : /users/{userid}/devices (일반적으로 소유 ‘has’의 관계를 표현할 때)

만약에 관계명이 복잡하다면 이를 서브 리소스에 명시적으로 표현하는 방법이 있습니다. 예를 들어 사용자가 '좋아하는'디바이스 목록을 표현해야 할 경우 다음과 같은 형태로 사용될 수 있습니다.

    GET : /users/{userid}/likes/devices (관계명이 애매하거나 구체적 표현이 필요할 때)

4-4. 자원을 표현하는 Collection과 Document

Collection 과 Document에 대해 알면 URI 설계가 한 층 더 쉬워집니다. DOCUMENT는 단순히 문서로 이해해도 되고, 한 객체라고 이해해도 됩니다. 컬렉션은 문서들의 집합, 객체들의 집합이라고 생각하면 이해하는데 좀 더 편합니다. 컬렉션과 도큐먼트는 모두 리소스라고 표현할 수 있으며 URI에 표현됩니다. 예를 들어보면

    http:// restapi.example.com/sports/soccer

위 URI를 보면 sports라는 컬렉션과 soccer라는 도큐먼트로 표현되고 있다고 생각하면 됩니다. 좀 더 예를 들어보자면

    http:// restapi.example.com/sports/soccer/players/13

sports, players 컬렉션과 soccer, 13(13번인 선수)를 의미하는 도큐먼트로 URI가 이루어지게 됩니다. 여기서 중요한 점은 컬렉션은 복수로 사용되고 있다는 점입니다. 좀 더 직관적인 REST API를 위해서는 컬렉션과 도큐먼트를 사용할 때 단수 복수도 지켜준다면 좀 더 이해하기 쉬운 URI를 설계할 수 있습니다.

5. HTTP 응답 상태 코드

마지막으로 응답 상태코드를 간단히 살펴보도록 하겠습니다. 잘 설계된 REST API는 URI만 잘 설계된 것이 아닌 그 리소스에 대한 응답을 잘 내어주는 것까지 포함되어야 합니다. 정확한 응답의 상태코드만으로도 많은 정보를 전달할 수 있기 떄문에 응답의 상태코드 값을 명확히 돌려주는 것은 생각보다 중요한 일이 될 수 있습니다. 혹시 200이나 4XX관련 특정 코드 정도만 사용하고 있다면 처리 상태에 대한 좀 더 명확한 상태코드 값을 사용할 수 있기를 권장합니다.

[출처]

REST API 제대로 알고 사용하기

오류를 검출하고 수정까지 할 수 있게 하는, 신중하게 제어된 여분의 정보를 추가하는 과정

체크섬(checksum) 알고리즘

• 중복 검사의 한 형태로, 오류 정정을 통해, 공간(전자 통신)이나 시간(기억 장치) 속에서 송신된 자료의 무결성을 보호하는 단순한 방법이다.

• 체크섬은 나열된 데이터를 더하여 체크섬 숫자를 얻고, 정해진 비트수의 모듈라로 정해진 비트수로 재구성 한다.
• 단순 덧셈 방식과 순환 중복 검사의 계산 방식과는 차이가 있으나,
  • 많은 경우 순환 중복 검사의 결과를 체크섬이라고 말하므로 단순 덧셈만을 의미하지는 않는다.

• 기본적인 메시지 구성 요소(보통 비트)를 추가하여 결과값을 저장함으로써 동작한다.

체크섬의 예

• 다음과 같이 4 바이트의 데이터가 있다고 치자: 0x25, 0x62, 0x3F, 0x52
• 1 단계: 모든 바이트를 덧셈하면 0x118이 된다.
• 2 단계: 캐리 니블을 버림으로써 0x18을 만든다.
• 3 단계: 0x18의 2의 보수를 얻음으로써 0xE8을 얻는다. - 이것이 체크섬 바이트이다.
• 체크섬 바이트를 테스트하려면 원래 그룹의 바이트에 체크섬 바이트까지 모두 더하면 0x200이 된다.
• 다시 캐리 니블을 버림으로써 0x00이 된다. 0x00이라는 뜻은 오류가 없다는 뜻이다. (하지만 오류가 있어도 우연히 0x00이 될 수도 있다.)

페리티 코드

• 패리티 비트(parity bit)를 사용하여 만드는 코드
• 패리티 비트는 데이터의 에러 검출을 위해 데이터에 추가되는 여분의 한 비트로서 시스템의 설계 기준에 따라 데이터 시작의 한 비트나 데이터 끝의 한 비트를 사용

패리티 비트

• 정보의 전달 과정에서 오류가 생겼는지를 검사하기 위해 추가된 비트이다.
• 문자열 내 1비트의 모든 숫자가 짝수 또는 홀수인지를 보증하기 위해 전송하고자 하는 데이터의 각 문자에 1 비트를 더하여 전송하는 방법
  • 2가지 종류의 패리티 비트(홀수, 짝수)가 있다.

• 짝수(even) 패리티
  • 전체 비트에서 1의 개수가 짝수가 되도록 패리티 비트를 정하는 것인데, 이를테면 데이터 비트에서 1의 개수가 홀수이면 패리티 비트를 1로 정한다.
• 홀수(odd) 패리티
  • 전체 비트에서 1의 개수가 홀수가 되도록 패리티 비트를 정하는 방법이다.

• 7비트의 0010110라는 데이터에서 짝수 패리티가 되게 하기 위해서는 1의 패리티 비트를 붙여 10010110로 한다.

  • 같은 데이터에 대해 홀수 패리티 비트가 되게 하려면 0의 패리티 비트를 붙인다.

• 이렇게 패리티 비트를 정하여 데이터를 보내면 받는 쪽에서는 수신된 데이터의 전체 비트를 계산하여 패리티 비트를 다시 계산함으로써 데이터 오류 발생 여부를 알 수 있다.

• 패리티 비트는 오류 발생 여부만 알 수 있지 오류를 수정할 수는 없다.

압축의 목표는 같은 정보를 더 적은 비트로 인코딩하는 것이다.

• 압축의 기본 아이디어는 군더더기 정보, 즉 연결 부분의 반대쪽에서 데이터를 수신했을 때 재현하거나 유추할 수 있는 정보는 저장하거나 보내지 않는 것이다.

인코딩

사용자가 입력한 문자나 기호들을 컴퓨터가 이용할 수 있는 신호로 만드는 것

• 넓은 의미의 컴퓨터는 이러한 신호를 입력받고 처리하는 기계를 뜻한다.
  • 신호 처리 시스템을 통해 이렇게 처리된 정보를 사용자가 이해할 수 있게 된다.

문자 인코딩의 구성

• 문자 정보는 정보를 표현하기 위한 글자들의 집합을 정의한 것
• 직접적으로 사용되지 않을 수도 있고 한 문자 집합을 여러 문자 인코딩에서 쓸 수도 있다.
• 특히 집합 안의 문자들에 음수가 아닌 정수들을 배정한 것을 부호화된 문자 집합(coded character set, CCS)라 한다.

문자 인코딩 형태(character encoding form, CEF)

• 특정한 문자 집합 안의 문자들을 컴퓨터 시스템에서 사용할 목적으로 일정한 범위 안의 정수(코드값)들로 변환하는 방법이다.
  • 유니코드 코드 포인트를 8비트 숫자의 집합으로 나타내는 UTF-8이나, 16비트 숫자의 집합으로 나타내는 UTF-16, 그리고 대부분의 일반적인 문자 인코딩들이 포함

문자 인코딩 구조(character encoding scheme, CES)

• 문자 인코딩 형태로 변환된 코드값을 옥텟 기반의 시스템에서 사용하기 위하여 옥텟들로 변환하는 방법이다.
  • 대부분의 문자 인코딩 형태는 이 과정에서 아무런 일도 일어 나지 않으며, 8비트 이상의 숫자를 사용하는 UTF-16과 같은 문자 인코딩 형태의 경우 엔디안을 지정해 주는 것으로 충분하다.
    • 여기에는 ISO 2022와 같은 복합 인코딩이나, SCSU와 같은 압축 방법 등이 속한다.

퍼센트 인코딩

• 퍼센트 인코딩(percent-encoding)은 URL에 문자를 표현하는 문자 인코딩 방법이다.
  • 알파벳이나 숫자 등 몇몇 문자를 제외한 값은 옥텟 단위로 묶어서, 16진수 값으로 인코딩한다.

허프먼 코딩(부호화)(Huffman coding)

무손실 압축에 쓰이는 엔트로피 부호화의 일종으로, 데이터 문자의 등장 빈도에 따라서 다른 길이의 부호를 사용하는 알고리즘

• 문자들의 빈도로부터 접두 부호(어떤 한 문자에 대한 부호가 다른 부호들의 접두어가 되지 않는 부호)를 만들어 내는 알고리즘으로, 적게 나오는 문자일수록 더 긴 부호를 쓰고 많이 나올수록 더 짧은 부호를 쓴다.

무손실 압축

• 비손실 압축 또는 무손실 압축은 데이터 압축의 일종
• 원래의 정보를 그대로 보존해야 하기 때문에, 정보 엔트로피의 한계가 그대로 반영된다.
  • 정보 엔트로피의 한계란 개별 정보의 확률값에 의하여 계산되는 값이 아닌, 전체 신호의 상관관계를 반영한 한계값

• 일반적으로 파일 데이터 압축에 사용하는 gzip을 비롯한 알고리즘들이 이에 해당한다.
  • 오디오나 이미지 압축에서 사용하는 무손실 압축 기술들은 각각의 신호 특성에 맞추어서 최적화가 된 것
  • 범용성을 가지는 데이터 압축 기술에 비하여 조금 더 압축률을 끌어 올릴 수 있다.

손실 압축

• 데이터를 압축하여 자료를 받는 곳에 압축으로 풀어서 원래의 것과 다르게 보여주는 것을 말하지만 어떠한 부분에서는 충분히 유용한 방식
  • 멀티미디어 데이터를 압축하는 데에 가장 많이 사용된다.

손실 압축의 개념

• 주관적으로 중요한 정보들을 최대한 보존하는 것을 목표로 하며, 이를 위해 사람들이 잘 느끼지 못하거나 둔감한 정보는 손실시킨다.
  • 영상 압축의 경우에는 고주파 성분을 손실 시키거나, 색차 정보를 손실시키는 방식을 주로 사용
  • 오디오의 경우에는 사람에게 잘 들리지 않는 소리를 손실시키는 방법을 사용

지각 부호화(Perceptual Coding)

• 인식(지각)에 영향을 주지 않는 요소를 제거하여, 원 데이터를 압축하는 기술
  • 인간 감각의 불완전한 특징을 활용하는 부호화

• 주로, 오디오 신호에 대해 심리음향적 효과를 이용한 오디오 신호 압축을 의미함
  • 심리음향 이론을 이용하여, 신호 중복성 및 무관성을 제거한 오디오 압축 코딩 기술

• 오히려 불필요한 정보가 추가되어 크기가 더 커지는 경우도 있는데
  • 더 이상 압축할 정보가 없는데도 압축 알고리즘을 거듭하는 경우가 그렇다.

컴퓨터가 켜졌을 떄 영구 기억 장치에 저장된 약간의 명령어를 실행해서 작동을 시작하도록 구성

• 플래시 메모리에서 읽은 멸령어는 최종적으로 유용한 작업을 하기에 충분한 코드가 로드될 때까지 더욱더 많은 명령어를 읽는다.
  • 이 과정을 부트스트래핑bootstrapping이라고 불렀는데, 지금은 부팅booting이라고 한다.
  • 부팅 과정에는 메모리와 다른 구성 요소를 점검해서 올바르게 작동하는지 확인하는 절차가 포함된다.

• 운영체제는 일단 실행되면 간단한 작업 사이클을 집중적으로 수행하는데, 실행할 준비가 됐거나 관심이 필요한 각 애플리케이션에 차례로 통제권을 준다.
• 프로세서가 이 프로세스 각각에 차례로 관심을 갖고 처리하게 하고, 필요에 따라 프로세스 간에 초점을 전환한다.
• 각 프로그램은 짧은 시간조각을 할당 받는데, 시간 조각은 프로그램이 시스템 서비스를 요천하거나 프로그램에 할당된 시간이 다 되면 끝난다.

• 운영체제는 각 이벤트에 대해 필요한 어떤 일이든 수행하며, 보통은 그런 이벤트가 발생했다는 사실을 해당 이벤트를 처리해야 하는 애플리케이션에 전달한다.
  • 예를 들어 사용자가 메뉴에서 종료를 선택하거나 닫기 버튼을 클랙해서 애플리케이션을 종료하면 OS는 애플리케이션에 곧 끝나야 된다고 통보해서 애플리케이션이 남은 일을 정리할 기회를 준다.
  • 그러고 나서 OS는 프로그램이 사용하던 모든 자원을 회수하고, 화면에 창이 노출될 다른 애플리케이션에 창을 다시 그려야 한다고 알려준다.

시스템 콜

• 운영체제는 하드웨어와 다른 소프트웨어 간의 인터페이스를 제공한다.
  • OS는 애플리케이션이 구축될 수 있는 플랫폼platform을 제공한다.
  • 추상화의 또 다른 예로, 구현상 들쑥날쑥한 부분이나 관련 없는 세부 사항을 감추는 인터페이스 또는 외관을 제공한다.

• OS는 이러한 서비스를 표준화된 방식 또는 합의된 방식으로 이용할 수 있게 하고, 애플리케이션은 운영체제의 특정 부분에 통제권을 넘겨주는 특별한 명령어를 실행함으로써 서비스를 요청한다.
  • OS에 서비스를 요청하는 이 진입점을 시스템 콜system call이라고 하며, 시스템 콜의 세부 명세에서 그 운영체제가 무엇인지를 규정한다.

디바이스 드라이버

운영체계와 프린터나 마우스 같은 특정 종류의 하드웨어 장치 간에 가교 역할을 하는 코드

• 드라이버 코드는 특정 장치가 어떤 일을 하도록 하는 방법을 자세히 알고 있다.

• 디바이스 드라이버는 특정 장치의 즉이한 속성에서 시스템의 나머지 부분을 분리한다.
  • 드라이버 인터페이스는 OS가 서로 다른 장치에 균일한 방식으로 접근하도록해서 장치를 전환하기 쉽게 해준다.
  • 실제로는 OS가 추상적이거나 이상화된 장치에 포괄적인 요청을 하고, 드라이버가 특정 장치에 맞게 요청을 구체적으로 구현한다.
  • 범용 OS는 많은 디바이스 드라이버가 있다.
  • 부팅 시에 시스템에 현재 가용 장치에 필요한 드라이버를 불러오는 작업도 이루어진다.
  • 새로운 장치가 갑자기 연결되는 일도 흔한데, 보통은 새로운 드라이버를 찾을 필요가 없다.

• 위 그림은 디바이스 드라이버, 운영체제, 시스템 콜, 애플리케이션 간의 관계를 보여준다.

다양한 디지털 장치와 OS

• 기술 발달 덕분에 장치들은 전반적으로 앞에서 살펴봤던 범용 컴퓨터와 비슷한 모습을 띠고 있다.
  • 성능이 좋은 프로세서와 용량이 큰 메모리가 내장되어 있고, 카메라 렌즈와 디스플레이 같은 주변 장치가 여러 개 달려있다.

• 사용환경이 특수한 경우가 아니라면 자신만의 전용 시스템을 개발하거나 값비싼 상용 제품의 라이선스를 얻는 것보다 리눅스에서 불필요한 부분을 뺀 버전을 사용하는 편이 더 쉽고 저렴하다.
  • 별도의 OS를 만들기보다는 범용 OS를 사용하는 방식이 더 타당하다.

리눅스의 장점

• 견고하다.
• 개조하기 용이하다.
• 이식 가능하다
• 무료이다.

  리눅스의 단점

• GPL 같은 라이센스에 따라 결과물 코드 일부를 공개해야 한다.

간단한 프로그램과 마찬가지로 그저 하나의 프로그램이고, 그런 프로그램과 같은 종류의 프로그래밍 언어로 작성되며 대부분 C나 C++로 구현

• 초기 운영체제는 메모리도 작고 작업이 단순했기 때문에 크기도 작았다.
• 초창기의 운영체제는 한번에 한 개의 프로그램만 실행했으므로 스와핑이 제한적으로 이루어졌다.
• 지금은 운영체제가 매우 크고 복잡한데, 그만큼 다양하고 복잡한 일을 처리하기 때문이다.

• 많은 운영체제의 조상 격인 유닉스 운영체제는 1975년 두 명이 작성했고 C와 어셈블리 언어 9000행으로 이루어져 있었다.
• 오늘날 리눅스는 1천만 행이 훨씬 넘고, 수십 년간 수천 명이 작업한 결과물이다.
• 윈도우 10은 정확한 규모가 공개된 적은 없지만 5천만 행정도로 추측된다. → 운영체자가 어떤 구성 요소를 포함해야 하는지에 대한 관점도 유닉스 시절과 차이가 있다.

• 운영체제는 단지 프로그램이므로 이론상으로는 모든 사람이 직접 작성할 수 있다.
• 하드웨어 개발 시 원래 의도했던 것과는 다른 운영체제를 실행하기도 한다.
  • 멀티 부트multiple boot 기능은 애플에서도 부트 캠프Boot Camp라는 이름으로 지원하는데, 맥OS 대신 윈도우를 실행하면서 시스템을 시작할 수 있다.

• 심지어 다른 운영체제의 관리하에 특정한 운영체제를 가상 운영체제virtual operating system로 실행 가능하다.

  • VM웨어VMware, 버추얼박스VirtualBox, 젠Xen 같은 가상 운영체제 프로그램은 호스트 OS에서 어떤 OS를 게스트 OS로 실행할 수 있게 해준다.

  

• 위 그림은 호스느 OS에서 가상 OS가 어떻게 실행되는지를 도식화한 것으로, 게스트 OS는 호스트 OS 입장에서 보면 보통의 애플리케이션이다.

가상 머신 Virtual Machine

컴퓨터인 것처럼 작동하는 프로그램 소프트웨어로만 존재하지만 마치 하드웨어인 것처럼 작동 방식을 모방하는 프로그램

가상 머신의 예시

• 자바 스크립트 프로그램을 해석하기 위한 가상 머신
• 자바 프로그램용 가상 머신
• 안드로이드용 가상 머신

→ VM이 사용되는 이유는 물리적 장비를 만드는 것보다 프로그램을 작성해서 배포하는 것이 더 쉽고 유연

클라우드 컴퓨팅 Cloud Computing

• 저장 공간과 네트워크 대역폭이 출분한 물리적 컴퓨터를 대량으로 보유하고, 그 자원을 이용하여 이용자에게 컴퓨팅 성능을 제공

• 아마존 웹 서비스Amazon Web Service, 즉 AWS는 최대 클라우드 컴퓨팅 제공 업체이다.
• 마이크로소프트 애저Microsoft Azure와 구글 클라우드 플랫폼Google Cloud Platform이 그 뒤를 잇는다.
  • 이러한 업체들 모두 고객의 작업량 변화에 맞게 서비스의 성능과 용량을 늘리거나 줄여 제공한다.
  • 개별 사용자가 사용 규모를 즉각 확대하거나 축소할 수 있을 만큼 충분한 컴퓨팅 자원을 보유하고 있기에 가능하다.

• 대표적인 예로 넷플릭스 같은 대형 업체를 비롯해서 많은 회사가 자체 서버를 운영하는 것보다 클라우드 컴퓨팅을 활용하는데, 서비스의 규모가 클수록 클라우드 컴퓨팅을 이용하는 것이 경제적, 적응성, HR 필요성 감소 등에 유리하기 때문이다.

• JWT는 JSON Web Token의 약자로 전자 서명 된 URL-safe (URL로 이용할 수있는 문자 만 구성된)의 JSON입니다.
• 전자 서명은 JSON 의 변조를 체크 할 수 있게되어 있습니다.
• JWT는 속성 정보 (Claim)를 JSON 데이터 구조로 표현한 토큰으로 RFC7519 표준 입니다.
• JWT는 서버와 클라이언트 간 정보를 주고 받을 때 Http 리퀘스트 헤더에 JSON 토큰을 넣은 후 서버는 별도의 인증 과정없이 헤더에 포함되어 있는 JWT 정보를 통해 인증합니다.
• 이때 사용되는 JSON 데이터는 URL-Safe 하도록 URL에 포함할 수 있는 문자만으로 만듭니다.
• JWT는 HMAC 알고리즘을 사용하여 비밀키 또는 RSA를 이용한 Public Key/ Private Key 쌍으로 서명할 수 있습니다.

2.JWS(JSON WEB SIGNATURE) 와 JWE(JSON WEB ENCRYPTION)

JWS(JSON Web Signature)

• JWS(JSON Web Signature)는 JSON 데이터 구조를 사용하는 서명 표준이며,
• 간단히 말하면 “JSON으로 전자 서명을하여 URL-safe 문자열로 표현한 것”입니다.

JWE(JSON Web Encryption)

• JWE(JSON Web Encryption)는 JSON 데이터 구조를 사용하는 암호화 방법입니다.
• JWE(JSON Web Encryption)는 “JSON을 암호화하여 URL-safe 문자열로 표현한 것” 입니다.

3.JWT 토큰 구성

• JWT는 세 파트로 나누어지며, 각 파트는 점으로 구분하여 xxxxx.yyyyy.zzzzz로 표현됩니다. 순서대로 헤더 (Header), 페이로드 (Payload), 서명 (Sinature)으로 구성합니다.
• Base64 인코딩의 경우 “+”, “/”, “=”이 포함되지만 JWT는 URI에서 파라미터로 사용할 수 있도록 URL-Safe 한 Base64url 인코딩을 사용합니다.

• 헤더(Header)는 토큰의 타입과 해시 암호화 알고리즘으로 구성되어 있습니다.
  • 첫째는 토큰의 유형 (JWT)을 나타내고,
  • 두 번째는 HMAC, SHA256 또는 RSA와 같은 해시 알고리즘을 나타내는 부분입니다.

• 페이로드(Payload)는 토큰에 담을 클레임(claim) 정보를 포함하고 있습니다. 페이로드(Payload)에 담는 정보의 한 ‘조각’ 을 클레임이라고 부르고, 이는 name / value 의 한 쌍으로 이뤄져있습니다. 토큰에는 여러개의 클레임들을 넣을 수 있습니다.

  • 클레임의 정보는 등록된 (registered) 클레임, 공개 (public) 클레임, 비공개 (private) 클레임으로 세 종류가 있습니다.

• 마지막으로 서명(Sinature)은 secret key를 포함하여 암호화되어 있습니다.

4.JWT PROCESS

1. 사용자가 id와 password를 입력하여 로그인을 시도합니다.
2. 서버는 요청을 확인하고 secret key를 통해 Access token을 발급합니다.
3. JWT 토큰을 클라이언트에 전달 합니다.
4. 클라이언트에서 API 을 요청할때 클라이언트가 Authorization header에 Access token을 담아서 보냅니다.
5. 서버는 JWT Signature를 체크하고 Payload로부터 사용자 정보를 확인해 데이터를 반환합니다.
6. 클라이언트의 로그인 정보를 서버 메모리에 저장하지 않기 때문에 토큰기반 인증 메커니즘을 제공합니다.

• 인증이 필요한 경로에 접근할 때 서버 측은 Authorization 헤더에 유효한 JWT 또는 존재하는지 확인합니다.
• JWT에는 필요한 모든 정보를 토큰에 포함하기 때문에 데이터베이스과 같은 서버와의 커뮤니케이션 오버 헤드를 최소화 할 수 있습니다.
• Cross-Origin Resource Sharing (CORS)는 쿠키를 사용하지 않기 때문에 JWT를 채용 한 인증 메커니즘은 두 도메인에서 API를 제공하더라도 문제가 발생하지 않습니다.
• 일반적으로 JWT 기반의 인증 시스템은 위와 같은 프로세스로 이루어집니다. 처음 사용자를 등록할 때 Access token과 Refresh token이 모두 발급되어야 합니다.

5.JWT 장점과 단점

JWT 장점

• JWT의 주요한 장점은 사용자 인증에 필요한 모든 정보가 토큰 자체에 포함되기 때문에 별도의 인증 저장소가 필요없다는 것입니다.
• 분산 마이크로 서비스 환경에서 중앙 집중식 인증 서버와 데이터베이스에 의존하지 않는 쉬운 인증 및 인가 방법을 제공합니다.
• 개별 마이크로 서비스에는 토큰 검증과 검증에 필요한 비밀 키를 처리하기 위한 미들웨이가 필요한데, 검증은 서명 및 클레임과 같은 몇 가지 매개 변수를 검사하는 것과 토큰이 만료되는 경우로 구성됩니다.
• 토큰이 올바르게 서명되었는지 확인하는 것은 CPU 사이클을 필요로하며 IO 또는 네트워크 액세스가 필요하지 않으며 최신 웹 서버 하드웨어에서 확장하기가 쉽습니다.

JWT 단점

• 토큰은 클라이언트에 저장되어 데이터베이스에서 사용자 정보를 조작하더라도 토큰에 직접 적용할 수 없습니다.
• 더 많은 필드가 추가되면 토큰이 커질 수 있습니다.
• 상태 비저장(stateless) 애플리케이션에서 토큰은 거의 모든 요청에 대해 전송되므로 데이터 트래픽 크기에 영향을 미칠 수 있습니다.

출처 : http://www.opennaru.com/opennaru-blog/jwt-json-web-token/

• 인증(Authentication)은 쉽게 말해서 '자신을 증명하는 것'이다.
  • 다시 말해서 자기 스스로가 무언가 자신을 증명할 만한 자료를 제시하는 것이다.
• 반면에 권한 부여(Authorization - 인가)는 권한부여남에 의해서 자격이 부여된다.

• 시큐리티의 개념을 어떤 회사에 방문하는 장면으로 비유하면 아래 그림과 유사하다.

• 엔지니어 A는 B 회사에 고장 난 데이터베이스를 고치기 위해서 방문했다. 예약을 한 상태에서 방문한 A시는 우선 회사 입구에서 '본인을 인증'할 것을 요구받는다. 출입증을 검사하는 직원은 A의 신분을 확인한다. 인증이란 이처럼 본인이 무엇인가를 증명하는 행위라고 보면 된다.

• 회사 내부에 들어간 A씨는 다시 담당자를 만나서 데이터베이스의 접근 권한 등의 정보를 얻어야 한다.
  • 이 과정을 인가혹은 권한 부여(Authorization)라고 볼 수 있다.
• 권한 부여 과정에서 A시는 데이터베이스를 조회하거나 수정할 수 있는 권한이 부여된다.

• 스프링 시큐리티의 내부에도 이와 비슷한 구조를 가지고 있다.
• 스프링 시큐리티에서 가장 중요한 역할을 하는 존재가 인증을 담당하는 AuthenticationManager(인증 매니저)라는 존재이다.
• AuthenticationManager는 다양한 방식의 인증을 처리할 수 있도록 아래와 같은 구조로 설계되어 있다.

• ProviderManager는 인증에 대한 처리를 AuthenricationProvider라는 타입의 객체를 이용해서 처리를 위임한다.

• AuthenricationProvider(인증 제공자)는 실제 인증 작업을 진행한다.
  • 이때 인증된 정보에는 권한에 대한 정보를 같이 전달하게 되는데 이 처리는 UserDetailsService라는 존재와 관련이 있다.
  • UserDetailsService 인터페이스 구현체는 실제로 사용자의 정보와 사용자가 가진 권한의 정보를 처리해서 반환하게 된다.

• 개발자가 스프링 시큐리티를 커스터마이징 하는 방식은 크게 AuthenricationProvider를 직접 구현하는 방식과 실제 처리를 담당하는 UserDetailsService를 구현하는 방식으로 나누어진다.

• 대부분의 경우에는 UserDetailsService를 구현하는 형태를 사용하는 것만으로도 충분하지만, 새로운 프로토콜이나 인증 구현 방식을 직접 구현하는 경우에는 AuthenticationProvider 인터페이스를 직접 구현해서 사용한다.

처음에 어디서 문제인지 파악하는 과정에서 이것저것 검색도 해봤는데 H2가 버전업이 되면서 예약어 관련 문제라는 것을 봤고 어디가 문제일지 파악하는 과정에서 설마 User가 예약어라 에러가 나는건 아니겠지 하고 넘어갔는데, 그 설마가 맞았다.

그래서 클래스 위에

@Table(name = "Users")

어노테이션을 추가하고 테이블 명을 설정한다음 실행하니까 에러가 발생하지 않았고 테이블도 생성 되었다.

아니 이게 버전때문에 이렇게 에러가 생길줄 알았나.... 그리고 강의좀 다시 찍어서 재배포좀 해주지....

복잡도란

• 알고리즘의 성능을 나타내는 척도
• 크게 시간 복잡도, 공간 복잡도로 나눌 수 있다.

1.시간 복잡도

• 특정한 크기의 입력에 대해 알고리즘이 얼마나 오래 걸리는지를 의미한다.
• 알고리즘을 위해 필요한 연산의 횟수
• 복잡도를 표현하기 위해 빅오 표기법을 사용한다.
• 최악의 경우에 대한 연산 횟수가 가장 중요하다.
• N의 범위에 따라 시간 복잡도를 계산하고 사용할 수 있는 알고리즘을 선택하는 방법도 있다.

※ 빅오 표기법 (O, big-O)

빅오란 입력값이 무한대로 향할때 함수의 상한을 설명하는 수학적 표기 방법이다.

• 빅오는 점근적 실행 시간을 표기할 때 가장 널리 쓰이는 수학적 표기 방법이여, 여기서 점근적 실행 시간이란 간단하게 N이라는 입력값이 무한대로 커질때의 실행 시간의 추이를 의미한다.
• 따라서 충분히 큰 입력값에서의 알고리즘의 효율성에 따라 수행 시간이 크게 차이가 날 수 있다.

2.공간 복잡도

• 특정한 크기의 입력에 대해 알고리즘이 얼마나 많은 메모리를 차지하는지를 의미한다.
• 알고리즘을 위해 필요한 메모리의 양

2. P vs NP

1.다항 시간 알고리즘(Polynomial-Time Algorithms)

• 다항 시간(합리적인 시간)안에 풀 수 있는 문제.

• 모든 문제가 다항 시간안에 해결되지 않는다.

  • Ex) 튜링의 "Halting Problem(정지 문제)" : 정지 문제란

  프로그램을 설명한 것과 처음 입력값이 주어졌을 때, 이 프로그램에 입력값을 넣고 실행한다면 이 프로그램이 계산을 끝내고 멈출지 아니면 영원히 계속 계산할지 판정하라.

  • 1936년 앨런 튜링이 모든 가능한 입력값에 대해 정지 문제를 풀 수 있는 일반적인 알고리즘은 존재하지 않는다는 것을 증명했다.

2.클래스 P

• 다항 시간내에 해결되는 알고리즘을 가지고 있는 결정(decision) 문제의 클래스
  • 어떤 상수 k에 대해 O(N^K) 시간에 풀 수 있는 문제
• O(P(N)) - 이때 P(N)은 N상의 다항시간
• 항상 올바른 답을 계산하는 방법
• 다항시간내에 해결되지 않으면 비효율적

3.클래스 NP

• '비결정적인 다항시간' 상에 존재(stand)
• 주로 "추측" or "평행선화(parallelize)"방식으로 계산
• 다항 시간에 "확인할 수 있는" 문제로 구성
  • 해의 "후보"가 주어지면 문제 입력 크기에 대한 다항 시간에 그 후보가 올바른 해인지 확인할 수 있음을 의미
• 이 방식의 문제점은 "속도(quickly)"

• 4.P ⊆ NP (아직 증명X)
• NP-complete(완비) 문제는 NP에서 가장 어려운 문제이다.
• 대부분의 전문적인 문제는 P or NP-complete 문제이다.
• NP-complete 문제 : P로 해결 가능하지만 NP로 해결되지 않는 문제(미제문제)

3.여행하는 외판원 문제(Traveling-Salesman-Problem)

1.여행하는 외판원 문제(TSP)

외판원 문제 또는 순회 외판원 문제는 초합 최적화 문제의 일종이다. 이 문제는 NP-난해에 속하며, 흔히 계산 복잡도 이론에서 해를 구하기 어려운 문제의 대표적인 예로 많이 다룬다.

• 외판원은 자신이 사는 도시에서 출발해서 어떤 순서로든 다른 도시를 모두 방문하고 나서 다시 출발점으로 돌아와야 한다.
  • 여기서 목표는 각 도시를 정확히 한 번씩(반복 없이) 방문하고,
  • 전체 여행한 거리를 최소로 만드는 것이다. ⇒ 그래프 이론의 용어로 엄밀하게 정의한다면, "각 변에 가중치가 주어진 완전 그래프(weighted complete graph)에서 가장 작은 가중치를 가지는 해밀턴 순회를 구하라" 라고 표현할 수 있고, 반드시 시작점으로 돌아와야 한다는 제약 조건을 없애도 계산 복잡도는 변하지 않는다.

• 외판원 순회 알고리즘은 무식하게 풀 수 있다. 무조건 0번 도시에서 출발한다고 가정해도 경로의 길이는 다르지 않다.
• 그러면 남은 도시들을 어떤 순서로 방문할지를 정하기만 하면 된다.
• 남은 n-1개의 도시를 나열하는 방법으로는 (n-1)!가지가 있다.
• 그래서 재귀 호출을 통해 쉽게 외판원 순회 알고리즘을 설계할 수 있다.
• 그러나 보통 n!의 풀이는 사용하지 않는다. 12!만 해도 479,001,600라는 엄청난 수를 지니기 때문이다.

2.외판원 순회 알고리즘을 더 빠르고 효율적으로 구하는 방법은?

• 모든 정점을 한 번씩 방문하는(출발 정점 제외) 최단 순환 경로를 탐색하는데 최적의 효율로 탐색하기 위해서 사용한다.

DP 메모제이션

• (n-1)!의 모든 경로를 조사하지 않고 중복된 경로를 제거하는 dp 메모제이션 기법을 사용하면 된다.
  • 동일한 하위 문제의 반복을 막아줌으로써 더 높은 효율로 연산이 이루어지게 해준다. 중복되는 경로의 조사를 제거해주는 것이다.

• 예를 들어, 피보나치 함수는 dp 메모제이션 기법을 통해 O(2^n)의 복잡도를 O(N)까지 줄여준다. **그렇다고 무조건 dp 메모제이션을 적용하면 각 문제의 성질이 다르기 때문에 O(n)으로 줄어든다는 뜻은 아니다.

비트마스킹

• 비트마스킹을 사용하면 bit연산이기 때문에 다른 자료구조(boolean배열)을 사용하는 것보다 훨씬 빠르게 동작되고 코드도 간결해진다.
• 가장 큰 장점은 N이 16개인 경우 2^16가지의 경우를 16bit로 표현이 가능하다.

⇒ 정리하면 TSP(외판원 순회)는 최단 순환 경로를 탐색해야하는데 1) N! 의 중복 경로를 제거해주는 DP 메모제이션 기법을 사용한다. 그래도 2^N의 모든 경우의 수를 표현해야 하기 때문에 그만큼의 공간복잡도가 필요하다. 2) 메모리 사용량도 줄이고 성능 향상을 위해서 2^N의 경우의 수를 Nbit로 표현할 수 있는 비트마스킹으로 사용한다.

⇒ 올라가야 할 계단의 수를 100 개에서 1개로 줄여주는 설계 방법 이라고 보면 된다.

그렇다면 왜 한 정점만 탐색해도 될까?

• DP 메모제이션 기법으로 엄청나게 시간을 단축 할 수 있는 것은 그만큼 중복되는 경로가 많기 때문이다.
• 이 순회 경로는 싸이클로 n개의 정점 중 어느 정점에서 탐색을 시작해도 결과는 똑같다는 것을 알아야 한다.

• 어차피 최적 경로 싸이클은 어디서 시작해도 똑같이 나오기 때문에 한 정점에서만 탐색해줘도 된다.

  • 1번에서 출발 : 1 → 2 → 5 → 3 → 4 → 1
  • 2번에서 출발 : 2 → 5 → 3 → 4 → 1 → 2
  • 3번에서 출발 : 3 → 4 → 1 → 2 → 5 → 3

알고리즘 참고 영상(강추) :

[youtube] hungarian dance - sorting algorithms

참고 링크 :

[알고리즘] 복잡도란 무엇인가 빅오 표기법 (O, big-O) 정지 문제 P와 NP 여행하는 외판원 문제(TSP)

💡 인증과 인가는 한글로 보나 영어 (Authentication vs. Authorization) 로 보나 비슷해 보일 뿐 아니라 실제 많이 혼동되어 사용되고 있지만 명확히 다른 의미를 가지고 있습니다.

출처: https://aboutssl.org/authentication-vs-authorization/

인증(Authentication) : 사용자 신원을 확인하는 행위

인가(Authorization) : 사용자 권한을 확인하는 행위

예를 들면,

• 인증: 회사 출입을 위한 출입증 확인 혹은 생체정보 (지문, 홍채) 인식
• 인가: 회사 건물 내 접근 권한 관리
  1. 방문자 → 회의실만 접근 가능
  2. 직원 → 회의실, 사무실 접근 가능
  3. 관리자 → 회의실, 사무실, 서버실, 물품보관실 접근 가능

웹에서의 인증 및 인가

• 인증: 로그인을 통해 본인임을 확인 (주로, 아이디와 패스워드 이용)

• 인가: 주로 역할에 따른 사용 권한 관리

  예) 웹 카페 사이트에서 회원 랭킹 별 가능한 첨부파일 크기를 다르게 부여

  

• POJO 기반의 구성
• 의존성 주입(DI)을 통한 객체 간의 관계 구성
• AOP(Aspect-Oriented-Programming) 지원
• 편리한 MVC 구조
• WAS의 종속적이지 않은 개발 환경

1.POJO 기반의 구성

• 스프링의 성격 자체가 가벼운(light-weight) 프레임워크지만, 그 내부에는 객체 간의 관계를 구성할 수 있는 특징을 가지고 있다.
• 스프링은 다른 프레임워크들과 달리 이 관계를 구성할 때 별도의 API 등을 사용하지 않는 POJO(Plain Old Java Object)의 구성 만으로 가능하도록 제작되어 있다. 쉽게 말해서 일반적인 Java 코드를 이용해서 객체를 구성하는 방식을 그대로 스프링에서 사용할 수 있다.

• 이것이 중요한 이유는 코드를 개발할 때 개발자가 특정한 라이브러리나 컨테이너의 기술에 종속적이지 않다는 것을 의미하기 때문이다.
• 개발자는 가장 일반적인 형태로 코드를 작성하고 실행할 수 있기 때문에 생산성에서도 유리하고 코드에 대한 테스트 작업 역시 좀 더 유연하게 할 수 있다는 장점이 생긴다.

2.의존성 주입(DI)과 스프링

• 스프링에 대한 얘기를 하면서 빠지지 않는 개념이 '의존성 주입'이라는 개념이다.

• 의존성(Dependency)이라는 것은 하나의 객체가 다른 객체 없이 제대로 된 역할을 할 수 없다는 것을 의미한다.
• 의존성은 하나의 객체가 다른 객체의 상태에 따라 영향을 받는 것을 의미한다. 흔히 A 객체가 B 객체 없이 동작이 불가능한 상황을 'A가 B에 의존적이다'라고 표현한다.

• 주입(Injection)은 말 그대로 외부에서 '밀어 넣는 것'을 의미한다.
• 필요한 객체를 얻는 방식에 따라서 주체가 능동적인지 수동적인지에 대한 차이가 있다.

• 의존성과 주입을 결합해서 생각해 보면 '어떤 객체가 필요한 객체를 외부에서 밀어 넣는다'는 의미가 된다.
• 그렇다면 '왜 외부에서 객체를 주입하는 방식'을 사용하는지 알아볼 필요가 있다.

• 예를 들어 음식점에서 직접 식재료를 사지 않고, 대행업체에서 배송해 주는 것을 사용하는 경우에 얻는 장점이 무엇인가에 대해서 고민해보면 역시 '편리하다', '장사에만 집중할 수 있다'와 같은 장점들을 생각해 볼 수 있다.
• 이것을 코드에 대입해서 살펴보면 '주입을 받는 입장에서는 어떤 객체인지 신경 쓸 필요가 없다', '어떤 객체에 의존하든 자신의 역할은 변하지 않는다'를 그림으로 표현하면 다음과 같은 형태가 될 수 있다.

• '의존성 주입' 방식을 사용하려면 두번째 그림의 오른쪽 도형처럼 추가적인 하나의 존재가 필요하게 된다. 이 존재는 의존성이 필요한 객체에 필요한 객체를 찾아서 '주입'하는 역할을 하게 된다.

• 스프링은 이러한 구조를 만드는 데 적합한 구조로 설계되어 있다.
• 스프링에서는 'ApplicationContext'라는 존재가 필요한 객체들을 생성하고, 필요한 객체들을 주입하는 역할을 해 주는 구조이다.
• 따라서 스프링을 이용하면 개발자들은 기존의 프로그래밍과 달리 객체와 객체를 분리해서 생성하고, 이러한 객체들을 엮는(wiring) 작업을 하는 형태의 개발을 하게 된다.

• 스프링에서는 ApplicationContext가 관리하는 객체들을 '빈(Bean)'이라는 용어로 부르고, 빈과 빈 사이의 의존관계를 처리하는 방식으로 XML 설정, 어노테이션 설정, Java 설정 방식을 이용할 수 있다.

3.AOP의 지원

• 좋은 개발환경의 중요 원칙은 '개발자가 비즈니스 로직에만 집중할 수 있게 한다.'이다.

• 이 목표를 이루기 위해 몇 가지 중요 원칙이 있지만, 가장 쉽게 생각할 수 있는 것이 '반복적인 코드의 제거'라고 할 수 있다.
• 스프링은 프레임워크를 이용한 개발에도 이러한 반복적인 코드를 줄이고, 비즈니스 로직에만 집중할 수 있는 방법을 제공한다.

• 대부분의 시스템이 공통으로 가지고 있는 보안이나 로그, 트랜잭션과 같이 비즈니스 로직은 아니지만, 반드시 처리가 필요한 부분을 스프링에서는 '횡단 관심사(cross-concern)'라고 한다.
• 스프링은 이러한 횡단 관심사를 분리해서 제작하는 것이 가능한데, AOP(Aspect Oriented Programming)는 관점지향 프로그래밍이라고도 불리며 이러한 횡단 관심사를 모듈로 분리하는 프로그래밍의 패러다임이다.
• 관점 지향은 쉽게 말해 어떤 로직을 기준으로 핵심적인 관점, 부가적인 관점으로 나누어서 보고 그 관점을 기준으로 각각 모듈화하겠다는 것이다.

• 스프링은 AOP를 AspectJ의 문법을 통해서 작성할 수 있는데, 이를 통해서 개발자는

  1) 핵심 비즈니스 로직에만 집중해서 코드를 개발할 수 있게 되었고,

  2) 각 프로젝트마다 다른 관심사를 정용할 때 코드의 수정을 최소화시킬 수 있었으며

  3) 원하는 관심사의 유지 보수가 수월한 코드를 구성할 수 있다.

4.트랜잭션의 지원

• 데이터베이스를 이용할 때 반드시 신경 써야 하는 부분은 하나의 업무가 여러 작업으로 이루어지는 경우의 트랜잭션 처리이다.
• 이 트랜잭션 처리는 상황에 따라서 복잡하게 구성될 수도 있고, 아닐 수도 있는데, 그때마다 코드를 이용해서 처리하는 작업은 개발자에게는 상당히 피곤한 일이다.
• 스프링은 이런 트랜잭션의 관리를 어노테이션(@)이나 XML로 설정할 수 있기 때문에 개발자가 매번 상황에 맞는 코드를 작성할 필요가 없도록 설계되었다.

출처:

https://engkimbs.tistory.com/746 [새로비:티스토리] 코드로 배우는 스프링 웹프로젝트 / 구멍가게 코딩단

1.1 JPA 표준 예외 정리

• JPA 표준 예외들은 javax.persistence.PersistenceException의 자식 클래스다. 그리고 이 예외 클래스는 RuntimeException의 자식이다. 따라서 JPA 예외는 모두 언체크 예외다.

• JPA 표준 예외는 크게 2가지로 나눌 수 있다.

  • 트랜잭션 록백을 표시하는 예외
  • 트랜잭션 롤백을 표시하지 않는 예외

• 트랜잭션 롤백을 표시하는 예외는 심각한 예외이므로 복구해선 안된다. 이 예외가 발생하면 트랜잭션을 강제로 커밋해도 트랜잭션이 커밋되지 않고 대신에 javax.persistence.RollbackException 예외가 발생한다. 반면에 트랜잭션 롤백을 표시하지 않는 예외는 심각한 예외가 아니다. 따라서 개발자가 트랜잭션을 커밋할지 롤백할지를 판단하면 된다.

트랜잭션 롤백을 표시하는 예외

트랜잭션 롤백을 표시하지 않는 예외

1.2 스프링 프레임워크의 JPA 예외 변환

• 서비스 계층에서 데이터 접근 계층의 구현 기술에 직접 의존하는 것은 좋은 설계라 할 수 없다. 이것은 예외도 마찬가지인데, 예를 들어 서비스 계층에서 JPA의 예외를 직접 사용하려면 JPA에 의존하게 된다. 스프링 프레임워크는 이런 문제를 해결하려고 데이터 접근 계층에 대한 예외를 추상화해서 개발자에게 제공한다.

JPA 예외를 스프링 예외로 변경

• 추가로 표 15.4를 보면 JPA 표준 명세상 밸상할 수 있는 다음 두 예외도 추상화 해서 제공한다.

1.3 스프링 프레임워크에 JPA 예외 변환가 적용

• JPA 예외를 스프링 프레임워크가 제공하는 추상화된 예외로 변경하려면 PersistenceExceptionTranslationPostProcessor를 스프링 빈으로 등록하면 된다.

• 이것은 @Repository 어노테이션을 사용한 곳에 예외 변환 AOP를 적용해서 JPA 예외를 스프링 프레임워크가 추상화한 예외로 변환해준다. 설정 방법은 다음과 같다.

<bean class="org.springframework.dao.annotation, PersistenceExceptionTranslationPostProcessor"/>

• JavaConfig를 사용하면 다음처럼 등록한다.

@Bean
public PersistenceExceptionTranslationPostProcessor
    exceptionTranslation() {
    return new PersistenceExceptionTranslationPostProcessor();
}

• findMember() 메소드는 엔티티를 조회하려고 getSingleResult() 메소드를 사용했다. 이 메소드는 조회된 결과가 없으면 javax.persistence.NoResultException이 발생한다. 이 예외가 findMember() 메소드를 빠져 나갈 때 PersistenceExceptionTranslationPostProcessor에서 등록한 AOP 인터셉터가 동작해서 해당 예외를 org.springframework.dao.EmptyResultDataAccessException 예외로 변환해서 반환한다. 따라서 이 메소드를 호출한 클라이언트는 스프링 프레임워크가 추상화한 예외를 받는다.

• 만약 예외를 변환하지 않고 그대로 반환하고 싶으면 다음처럼 throws 절에 그대로 반환할 JPA 예외나 JPA 예외의 부모 클래스를 직접 명시하면 된다. 예를 들어 예제 15.2와 같이 예외를 명시하면 해당 예외를 그대로 반환한다. 참고로 java.lang.Exception를 선언하면 모든 예외의 부모이므로 예외를 변환하지 않는다.

1.4트랜잭션 롤백 시 주의사항

• 트랜잭션을 롤백하는 것은 데이터베이스의 반영사항만 롤백하는 것이지 수정한 자바 객체까지 원상태로 복구해주지는 않는다. 예를 들어 엔티티를 조회해서 수정하는 중에 문제가 있어서 트랜잭션을 롤백하면 데이터베이스의 데이터는 원래대로 복구되지만 객체는 수정된 상태로 영속성 컨텍스트에 남아 있다. 따라서 트랜잭션이 롤백된 영속성 컨텍스트를 그대로 사용하는 것은 위험하다. 새로운 영속성 컨텍스트를 생성해서 사용하거나 EntityManager.clear()를 호출해서 영속성 컨텍스트를 초기화한 다음에 사용해야 한다.

• 스프링 프레임워크는 이런 문제를 예방하기 위해 영속성 컨텍스트의 범위에 따라 다른 방법을 사용한다.

• 기본 전략인 트랜잭션당 영속성 컨텍스트 전략은 문제가 발생하면 트랜잭션 AOP 종료 시점에 트랜잭션을 롤백하면서 영속성 컨텍스트도 함께 종료하므로 문제가 발생하지 않는다.

• 문제는 OSIV처럼 영속성 컨텍스트의 범위를 트랜잭션 범위보다 넓게 사용해서 여러 트랜잭션이 하나의 영속성 컨텍스트를 사용할 때 발생한다. 이때는 트랜잭션을 롤백해서 영속성 컨텍스트에 이상이 발생해도 다른 트랜잭션에서 해당 영속성 컨텍스트를 그대로 사용하는 문제가 있다. 스프링 프레임워크는 영속성 컨텍스트의 범위를 트랜잭션의 범위보다 넓게 설정하면 트랜잭션 롤백시 영속성 컨텍스느를 초기화(EntityManager.clear())해서 잘못된 영속성 컨텍스트를 사용하는 문제를 예방한다.

출처 - 자바 ORM 표준 JPA 프로그래밍. 저자 김영한

들어가며

Http Method 중 특히 자원(Entity)를 수정하는 용도로 사용하는 "Put"과 "Patch"

• 웹 API를 설계할 때, 최대한 Http 표준을 따라서 용도에 맞는 Http Method를 사용해야 한다는 것은 아마 많은 개발자들이 인지하고 있을 것이다.

• 개발자들 중에는 Put과 Patch의 차이를 크게 생각하지 않고 아무거나 선택하거나 혼용하여 API를 만드는 사람도 있다.

• 정말로 두 메서드를 구별없이 사용해도 괜찮은 걸까!?

• 여기 지하철 노선 정보를 수정하는 자바스크립트 코드가 있다.

지하철 노선(Line)은 이름(name), 첫 차 시간(startTime), 마지막 차 시간(endTime), 배차간격(intervalTime)을 상태로 갖는다.

const updateSubwayLine = () => {
  // 수정할 노선 정보
  const updatedSubwayLine = {
    name: $subwayLineNameInput.value,  // 노선이름
    startTime: $subwayLineStartTime.value,  // 첫 차 시간
    endTime: $subwayLineEndTime.value,  // 마지막 차 시간
    intervalTime: $subwayIntervalTime.value  // 배차간격
  }

  // 노선 정보를 수정하는 API 호출
  request(`/lines/${$activeSubwayLineItem.dataset.id}`, {
    method: 'PUT',
    headers: {
      'Content-Type': 'application/json'
    },
    body: JSON.stringify({
      ...updatedSubwayLine
    })
  })
  .then(() => {
    subwayLineModal.toggle()
    $activeSubwayLineItem.querySelector('.line-name').innerText = updatedSubwayLine.name
  })
  .catch(error => alert(ERROR_MESSAGE.COMMON))
}

• 이 updateSubwayLine 함수가 실행되면 ‘Put’ 메서드로 노선 정보를 수정하는 API가 호출되고, 요청으로 전달된 데이터에 따라 데이터베이스에 저장된 노선의 정보가 변경될 것이다.

• 그렇다면 위의 함수에서 ‘Put’을 ‘Patch’로 바꾼다면 어떨까? Put으로 요청을 보냈을 때와 같은 변경이 이루어질까?

그렇다!

• ‘Put’과 ‘Patch’가 같은 결과를 도출하기 때문에 둘 다 자원을 “수정하는 역할”을 한다고 말할 수 있을 것이다. 하지만 이 코드에는 두 메서드가 같은 결과를 보여주게 하는 함정이 숨어있다.

• 실제로 ‘Put’과 ‘Patch’는 서로 대체재 관계가 아니다. 둘은 애초에 엄연히 다른 정의와 규약을 가지고 있고, 실제 사용할 때도 멱등성과 관련한 차이를 보이기 때문이다.

• 그렇다면 Put과 Patch 정의와 각각을 사용한 예시 코드를 통해 차이를 한번 이해해보자. 그리고 위에서 말한 함정이 무엇이었는지도 함께 알아보자.

HTTP Method - PUT

The PUT method requests that the state of the target resource be created or replaced with the state defined by the representation enclosed in the request message payload.

• RFC 문서에 따르면 PUT 메서드는 요청한 URI에 payload(ex. Request Body)에 있는 자원으로 대체(replace)하는 메서드이다. 여기서 대체하는 메서드라는 것은 대상을 저장하기도, 변경한다는 것을 의미한다.결국 PUT 메서드는 상황에 따라 다르게 동작하게 되는데 이를 두 가지 경우로 나누어 살펴보도록 하자.

요청한 URI 아래에 자원이 존재하지 않는 경우

• 자원이 존재하지 않는 경우는 단순하다. POST와 마찬가지로 새로운 자원으로써 저장하고 클라이언트에게 Http Status Code를 201(Created) 응답을 보내주면 된다.

요청한 URI 아래에 자원이 존재하는 경우

• payload에 담긴 정보를 이용해서 새로운 자원을 만들어 기존에 존재하던 자원을 대체한다.그리고 해당 요청이 잘 적용되었다는 것을 클라이언트에게 200(ok) 혹은 204(no content)를 이용해서 알려주면 된다.

PUT을 사용하는 코드

• PUT의 정의를 가장 잘 설명하는 예시가 주변에서 흔히 볼 수 있는 “좋아요”와 “싫어요”(혹은 추천/비추천) 기능이라고 생각한다. 좋아요와 싫어요 정보를 갖고 있는 Like 엔티티가 다음과 같이 구성되어있다.

@Entity
public class Like {

  @Id
  private Long id;

  private Long articleId;

  private Long userId;

  private LikeType likeType;   //** liked or disliked

  ...
}

• Like 엔티티는 articleId(어떤 게시물에 대한건지), userId(누가 좋아요를 한건지), 그리고 type(좋아요/싫어요)를 상태로 가지고 있다.

• 클라이언트에서 액션을 받을 때에도 이 세 정보가 모두 필요하다. 유저가 처음으로 좋아요(혹은 싫어요)를 눌렀다면, 생성이 되어야할 것이고, 기존에 누른적이 있다면 다른 타입으로 토글(수정)되거나, 취소가 되어야 한다.

• 이런 경우는 다음과 같이 PUT Method를 이용해서 Like 자원의 온전한 생성과, 수정을 표현할 수 있다.

// LikeController.java
...
@PutMapping  //** PUT Method
public ResponseEntity<Void> updateLike(
    @RequestParam Long articleId,
    @LoginUser User user,
    @RequestBody LikeRequest request  //** LikeType
) {
    articleService.update(articleId, user.getId(), request.getLikeType());
    return ResponseEntity.noContent().build();
}
...

// LikeService.java
...
@Transactional
public void update(Long articleId, Long userId, LikeType likeType) {
    Like like = likeRepository.findByArticleIdAndUserId(articleId, userId)
      .map(l -> l.setType(likeType))
      .orElse(new Like(articleId, userId, likeType));

    likeRepository.save(like);
}

• LikeService에서 payload로 전달받은, articleId와 userId를 사용해서 식별가능한 데이터가 있는지 확인한 후 있으면, body에 있는 새로운 type으로 수정한다. 만약 식별가능한 데이터가 없다면, payload에 있는 데이터들로 새로운 엔티티를 만들어 데이터베이스에 저장하게된다. 이렇게하면 PUT 메서드 정의와 규약을 지키면서도 도메인 요구사항에 맞는 API를 만들 수 있다.

HTTP Method - PATCH

This specification defines the new HTTP/1.1 [RFC2616] method, PATCH, which is used to apply partial modifications to a resource.

• RFC 문서에 따르면 PATCH 요청은 자원에 대한 부분적인 수정을 적용하기 위한 HTTP 메서드이다.

주의점

PUT 메서드를 사용하는 클라이언트는 해당 자원의 상태를 모두 알고 있다고 가정되어야 한다.

• PUT 메서드는 요청 경로에 자원이 존재하는 경우 해당 자원을 payload 정보와 교체하는 메서드이다. 즉, PUT 메서드를 사용할 때 전송하는 payload만으로 자원의 전체 상태를 나타낼 수 있어야 한다. 새로운 자원을 생성해야 하는 경우 완전한 상태의 자원을 저장해야 하고 새로운 자원으로 대체하는 경우 대체하는 자원이 완전한 상태를 가지고 있어야 하기 때문이다.

• 만약 PUT의 정의대로 전달 받은 payload가 기존 정보를 대체하도록 구현한 경우 payload 정보가 불완전한 상태로 전송된다면 일부 entity의 field값들은 null로 변경될 수 있다.

Patch를 사용하는 코드

• 처음 들었던 예시로 다시 돌아가서 지하철노선(Line)이 가지고 있는 네 가지 필드 중 이번에는 이름(name)과 배차간격(intervalTime) 필드만 변경이 가능하다고 가정해보겠다. 클라이언트에서는 기존처럼 모든 필드를 요청에 실을 필요없이 아래처럼 name과 intervalTime에 대한 정보만 body에 담아서 보내면 된다.

...
body: JSON.stringify({
  name: "변경된 노선 이름",
  intervalTime: 100
})
...

• PUT의 경우, URL에 담긴 정보로 엔티티를 식별할 수 없다면 생성까지 해야하기 때문에 엔티티에 필요한 모든 정보를 payload에 실어 보내야 한다.

• 하지만 PATCH는 부분 수정을 위한 데이터만 요청의 payload로 보내기 때문에 아래와 같이 body를 받는 DTO를 별도로 만들어 주어야 하고, 이 부분 데이터를 받는 DTO로는 새로운 엔티티를 생성할 수 없고 오직 부분 수정을 위한 데이터로써의 준비를 마치게 된다.

public UpdateLineNameAndIntervalTime {

    private String name;
    private int intervalTime;

    public UpdateLineNameAndIntervalTime() {}

    public UpdateLineNameAndIntervalTime(String name, int intervalTime) {
        this.name = name;
        this.intervalTime = intervalTime;
    }
}

• 클라이언트에서 PATCH 요청을 보낸 뒤, 이어서 호출 되는 함수를 보자.

// LineService.java
...
@Transactional
public void updateLine(final Long id, final UpdateLineNameAndIntervalTime request) {
    Line line = lineRepository.findById(id)
        .orElseThrow(NoSuchElementException::new);

    line.update(request);
}
...

// Line.java
public void update(final UpdateLineNameAndIntervalTime request) {
    this.name = request.getName();
    this.intervalTime = request.getIntervalTime();
}

결론

• PUT과 PATCH는 HTTP 메서드이지만 규약일 뿐 특정 행동을 강제할 수 없다.

• 하지만 이러한 규약은 모두가 동의한 약속이고 클라이언트와 서버 간의 통신에서 혼란이 발생하지 않도록 정의를 잘 알고 사용하는 것이 좋다.

• PUT과 PATCH의 차이점으로 멱등성에 대한 이야기도 많이 있다.

• PUT은 멱등성을 지키지만 PATCH는 멱등성을 지키지 못한다는 것이다. 멱등성에 대한 이야기 만으로도 하나의 글을 작성할 수 있을 만큼 그 내용이 방대하기 때문에 아쉽게도 이번 글에서는 다루지 않았다.

• 만약 멱득성의 차이를 알아보고 싶다면 아래 참고에 추가한 PUT과 PATCH의 멱등성을 보길 추천한다.

출처 : https://tecoble.techcourse.co.kr/post/2020-08-17-put-vs-patch/

• MVC의 컨트롤러가 모여 있는 곳이다.
• 컨트롤러는 서비스 계층을 호출하고 결과를 뷰(JSP)에 전달한다.

Service

• 서비스 계층에는 비즈니스 로직이 있고 트랜잭션을 시작한다.
• 서비스 계층은 데이터 접근 계층인 리포지토리를 호출한다.

Repository

• JPA를 직접 사용하는 곳은 리포지토리 계층이다.
• 엔티티 매니저를 사용해서 엔티티를 저장하고 조회한다.

1946년 개발된 컴퓨터인 에니악(ENIAC)은 사람에게 익숙한 10진법을 사용하도록 설계되었으니 전기회로는 전압이 불안정해서 전압을 10단계로 나누어 처리하는데 한계가 있었다. 그래서 1950년에 개발된 에드박(EDVAC)은 단 두 가지 단계, 전기가 흐르면 1, 흐르지 않으면 0, 만으로 작동하도록 설계되었고 매우 성공적이었다. 그 이후로 지금까지 대부분의 컴퓨터는 2진 체계로 설계되었기 때문에, 2진법을 알지 못하면 컴퓨터의 동작원리나 데이터 처리방식을 온전히 이해할 수 없다.

• 컴퓨터는 2진수(0과 1) 밖에 모르기 때문에 10진수 숫자 25를 저장할때 2진수 11001로 바꾸어 저장된다.

  십진수

• 10의 거듭제곱의 합을 줄여 표기한 것
• 0 ~ 9까지의 숫자를 이용해 수를 표현하는 것
  • 10은 9보다 큰 숫자를 표현하기 위해 사용

이진수

→ 0과 1로 이루어진 일련의 비트를, 수로 해석할 수 있다는 점은, 여러 개의 항목에 이진 레이블을 차례로 할당할 수 있음을 뜻한다.

• 기수가 10 대신 2이고 사용되는 숫자가 0과 1뿐
  • 그래서 2진수 1에 1을 더하면 2가 아닌 10이 되고, 2진수 11에 1을 더하면 12가 아닌 100이 된다.

이진수 → 십진수

• 이진수를 십진수로 변환하기는 쉽다.
• 비트가 1인 자릿값에 해당하는 2의 거듭제곱을 합산하기만 하면된다.

  십진수 → 이진수

• 십진수를 이진수로 변환하는 것은 까다롭지만, 어렵지 않다.
• 십진수를 2로 나누는 것을 반복한다.
• 나눌 때마다 0 또는 1이 되는 나머지 값을 적고, 몫은 다음 나누기를 위한 값으로 사용한다.

• 또는 원래 수에서 2의 거듭제곱을 하나씩 내려가면서 뺌으로써 십진수를 이진수로 변환할 수 있다.

바이트

바이트는 1956년 컴퓨터 설계자인 베르너 부흐홀츠(Werner Buchholz)가 만든 단어이다.

• 보든 최신 컴퓨터에서 데이터 처리와 메모리 구성의 기본 단위는 8비트(bit)로, 컴퓨터가 값을 저장할 수 있는 최소단위
• 그러나 1 비트는 너무 작은 단위이기 떄문에 1비트 8개의 묶어서 바이트(byte)라는 단위로 정의해서 데이터의 기본 단위로 사용
  • 단일 바이트로는 256개의 구별되는 값을 인코딩 가능
    • 0 ~ 255 사이의 정수 또는 7비트 아스키코드 문자 집합 중 하나의 문자이거나, 뭔가 다른 것
• 이 외에도 바이트 9개를 묶은 '워드(word)'라는 단위가 있는데, '워드(word)'는 'CPU가 한 번에 처리할 수 있는 데이터의 크기'를 의미

십육진수(16진수)

만일 비트별로 다른 종류의 정보를 인코딩 한다면, 2진수는 10진수 형태보다 세 배 이상 길어서 너무 많은 공강을 차지하므로 십육진수hexadecimal라는 대안 표기법을 일반적으로 사용한다.

• 1~ 4비트로 표현할 수 있는 값의 개수

• 16진수는 16을 기수로 사용하여 16개의 숫자로 표시한다.
  • 0 ~ 9, A ~ F 를 이용하여 각 16진 숫자가 네 개의 비트를 표현한다.
  • 2, 8, 10, 16 진법에 사용되는 기호

• 8진수는 2진수 3자리를, 16진수는 2진수 4자리를 각각 한자리로 표현할 수 있기 때문에 자리수가 짧아져서 알아보기 쉽고 서로 간의 변환방법 또한 매우 간단

• 프로그래머가 아니라면 16진수를 볼 수 있는 곳은 많지 않다.
  • 예를 들면 웹페이지의 색상에 16진수가 사용된다.
    • 각 바이트는 적색의 양, 녹색의 양, 청색의 양을 표현하는 데 쓰인다.
      • 이 방법을 RGB 인코딩이라고 한다.
      • 적색의 양 x 녹색의 양 x 청색의 양 = 255 x 255 x 255개를 표현 가능
  • 또한 유나코드 코드표에서도 문자를 식별하고자 16진수를 사용한다.

• 16진수는 뒤에 '네트워크' 주제에서 다룰 이더넷 주소에서도 볼 수 있고,
  • '웹'에 쓰이는 URL에서 특수 문자를 표현하는 데도 사용

컴퓨터의 32비트와 64비트란?

• 컴퓨터는 내부적으로 데이터를 다양한 크기의 덩어리 단위로 조작
• 이런 덩어리는 수와 주소를 포함
  • 수 : 32비트와 64비트가 편리하게 사용
  • 주소 : 메모리상에 있는 정보의 위치
    • 여기서 관련된 것은 후자인 주소 속성

비트와 바이트에 대한 논의

• 기억해야 할 가장 중요한 사실은 비트 모음의 의미가 상황에 따라 결정
  • 보이는 것만 가지고 비트의 의미 식별 불가
    • 참 또는 거짓을 나타내는 비트 한개와 사용하지 않는 비트 일곱 개
    • 작은 정수 또는 # 같은 아스키코드 문자를 저장한 것
    • 다른 체계에서 문자 한 개의 일부
    • 2바이트, 4바이트, 8바이트로 표현되는 큰 수의 일부
    • 사진이나 음악 작품의 일부분
    • 프로세서가 실행할 명령어의 일부

• 서로 지양하는 바가 다른 2개 영역(객체지향 프로그래밍(OOP) 언어와 관계형 데이터베이스(SQL))을 중간에서 패러다임 일치를 시켜주기 위한 기술
  • 개발자는 객체지향적 프로그래밍을 하고,
  • JPA가 이를 관계형 데이터 베이스에 맞게 SQL을 대신 생성하고 실행

  • 개발자는 항상 객체 지향적으로 코드를 표현할 수 있으니 더는 SQL에 종속적인 개발을 하지 않아도 된다.

    • 그렇기에 생산성이 향상되고 코드의 유지 보수가 편해지는 장점이 있다.

Spring Data JPA

• JPA는 인터페이스로서 자바 표준명세서이다.

  • 인터페이스인 JPA를 사용하기 위해서는 구현체가 필요하고, 대표적으로 Hibernate, Eclipse Link 등이 있다.

  • 하지만 Spring에서 JPA를 사용할 때는 이 구현체들을 직접 다르지 않고 구현체들을 좀 더 쉽게 사용하고자 추상화시킨 Spring Data JPA라는 모듈을 이용하여 JPA 기술을 쓴다. 이들의 관계는 다음과 같다.

    JPA ← Hibernate ← Spring Data JPA

    실질적으로 Hibernate를 쓰는 것과 Spring Data JPA를 쓰는 것 사이에 큰 차이는 없다.

  • 이렇게 한 단계 더 감싸놓은 Spring Data JPA가 등장한 이유는 두가지가 있다.

    구현체 교체의 용이성 저장소 교체의 용이성

  구현체 교체의 용이성

  • Hibernate 외에 다른 구현체로 쉽게 교체하기 위함

  저장소 교체의 용이성

  • 관계형 데이터베이스 외에 다른 저장소로 쉽게 교체하기 위함

객체지향에서 배운 개념과 문법을 이용해서 다음 요구조건을 만족하는 클래스를 작성하시요. 여러분이 게임을 만든다고 생각해보세요.

요구사항

1. 사람은 자식, 부모님, 조부모님이 있다.
2. 모든 사람은 이름, 나이, 현재 장소정보(x,y좌표)가 있다.
3. 모든 사람은 걸을 수 있다. 장소(x, y좌표)로 이동한다.
4. 자식과 부모님은 뛸 수 있다. 장소(x, y좌표)로 이동한다.
5. 조부모님의 기본속도는 1이다. 부모의 기본속도는 3, 자식의 기본속도는 5이다.
6. 뛸때는 속도가 기본속도대비 +2 빠르다.
7. 수영할때는 속도가 기본속도대비 +1 빠르다.
8. 자식만 수영을 할 수 있다. 장소(x, y좌표)로 이동한다.

위 요구사항을 만족하는 클래스들을 바탕으로, Main 함수를 다음 동작을 출력(System.out.println)하며 실행하도록 작성하시오. 이동하는 동작은 각자 순서가 맞아야 합니다.

1. 모든 종류의 사람의 인스턴스는 1개씩 생성한다.
2. 모든 사람의 처음 위치는 x,y 좌표가 (0,0)이다.
3. 모든 사람의 이름, 나이, 속도, 현재위치를 확인한다.
4. 걸을 수 있는 모든 사람이 (1, 1) 위치로 걷는다.
5. 뛸 수 있는 모든 사람은 (2,2) 위치로 뛰어간다.
6. 수영할 수 있는 모든 사람은 (3, -1)위치로 수영해서 간다.

퀴즈: 객체지향 - 정답 예시

Human.java

    public class Human {
        String name;
        int age;
        int speed;
        int x, y;

        public Human(String name, int age, int speed, int x, int y) {
            this.name = name;
            this.age = age;
            this.speed = speed;
            this.x = x;
            this.y = y;
        }

        public Human(String name, int age, int speed) {
            this(name, age, speed, 0, 0);
        }

        public String getLocation() {
            return "(" + x + ", " + y + ")";
        }
        protected void printWhoAmI() {
            System.out.println("My name is " + name + ". " + age + " aged.");
        }
    }

Walkable.java

    public interface Walkable {
        void walk(int x, int y);
    }

Runnable.java

    public interface Runnable {
        void run(int x, int y);
    }

Swimmable.java

    public interface Swimmable {
        void swim(int x, int y);
    }

GrandParent.java

    public class GrandParent extends Human implements Walkable {
        public GrandParent(String name, int age) {
            super(name, age, 1);
        }

        @Override
        public void walk(int x, int y) {
            printWhoAmI();
            System.out.println("walk speed: " + speed);
            this.x = x;
            this.y = y;
            System.out.println("Walked to " + getLocation());
        }
    }

Parent.java

    public class Parent extends Human implements Walkable, Runnable{
        public Parent(String name, int age) {
            super(name, age, 3);
        }

        @Override
        public void run(int x, int y) {
            printWhoAmI();
            System.out.println("run speed: " + (speed + 2));
            this.x = x;
            this.y = y;
            System.out.println("Ran to " + getLocation());
        }

        @Override
        public void walk(int x, int y) {
            printWhoAmI();
            System.out.println("walk speed: " + speed);
            this.x = x;
            this.y = y;
            System.out.println("Walked to " + getLocation());
        }
    }

Child.java

    public class Child extends Human implements Walkable, Runnable, Swimmable{
        public Child(String name, int age) {
            super(name, age, 5);
        }

        @Override
        public void swim(int x, int y) {
            printWhoAmI();
            System.out.println("swimming speed: " + (speed + 1));
            this.x = x;
            this.y = y;
            System.out.println("Swum to " + getLocation());
        }

        @Override
        public void run(int x, int y) {
            printWhoAmI();
            System.out.println("run speed: " + (speed + +2));
            this.x = x;
            this.y = y;
            System.out.println("Ran to " + getLocation());
        }

        @Override
        public void walk(int x, int y) {
            printWhoAmI();
            System.out.println("walk speed: " + speed);
            this.x = x;
            this.y = y;
            System.out.println("Walked to " + getLocation());
        }
    }

Main.java

    public class Main {
        public static void main(String[] args) {
            Human grandParent = new GrandParent("할아버지", 70);
            Human parent = new Parent("엄마", 50);
            Human child = new Child("나", 20);

            Human[] humans = { grandParent, parent, child };
            for (Human human : humans) {
                System.out.println(human.name + ", 나이: " + human.age + ", 속도: " + human.speed + ", 장소: " + human
                        .getLocation());
            }
            System.out.println("<활동 시작>");
            for (Human human : humans) {
                if (human instanceof Walkable) {
                    ((Walkable) human).walk(1, 1);
                    System.out.println(" - - - - - - ");
                }
                if (human instanceof Runnable) {
                    ((Runnable) human).run(2, 2);
                    System.out.println(" - - - - - - ");
                }
                if (human instanceof Swimmable) {
                    ((Swimmable) human).swim(3, -1);
                    System.out.println(" - - - - - - ");
                }
            }
        }
    }

💡 구현하는 방법은 여러가지 입니다. 꼭 예시가 정답은 아닙니다. 다만, 여러분이 짠 코드와 비교해보면서 어떤 코드가 어떤 점에서 더 좋은지 생각해보세요.

추상클래스란?

추상클래스는 추상메소드를 선언할 수 있는 클래스를 의미합니다. 또한 추상클래스는 클래스와는 다르게 상속받는 클래스 없이 그 자체로 인스턴스를 생성할 수는 없습니다.

• 먼저 추상메소드에 대해서 알아보겠습니다.

• 추상메소드는 설계만 되어있으며 수행되는 코드에 대해서는 작성이 안된 메소드입니다.

• 이처럼, 미완성으로 남겨두는 이유는 상속받는 클래스 마다 반드시 동작이 달라지는 경우에 상속받는 클래스 작성자가 반드시 작성하도록하기 위함입니다.

• 추상 메소드 형식

  👉 abstract 리턴타입 메소드이름();

• [코드스니펫] 추상클래스 예제 - Main 함수

    public class Main {
        public static void main(String[] args) {
  
        }
    }

abstract class Bird {
    private int x, y, z;

    void fly(int x, int y, int z) {
        printLocation();
        System.out.println("이동합니다.");
        this.x = x;
        this.y = y;
        if (flyable(z)) {
            this.z = z;
        } else {
            System.out.println("그 높이로는 날 수 없습니다");
        }
        printLocation();
    }

    abstract boolean flyable(int z);

    public void printLocation() {
        System.out.println("현재 위치 (" + x + ", " + y + ", " + z + ")");
    }
}

class Pigeon extends Bird {
    @Override
    boolean flyable(int z) {
        return z < 10000;
    }
}

class Peacock extends Bird {
    @Override
    boolean flyable(int z) {
        return false;
    }
}

public class Main {
    public static void main(String[] args) {
        Bird pigeon = new Pigeon();
        Bird peacock = new Peacock();
        System.out.println("-- 비둘기 --");
        pigeon.fly(1, 1, 3);
        System.out.println("-- 공작새 --");
        peacock.fly(1, 1, 3);
        System.out.println("-- 비둘기 --");
        pigeon.fly(3, 3, 30000);
    }
}

• fly(x, y, z) 함수는 Bird 를 상속받는 모든 클래스에서 동일한 동작을 합니다. 다만, 그 안에서 호출된 flyable(z) 의 동작만 그것을 구현하는 자식 클래스에서 구현한대로 동작하는 것입니다.
• 공작새(peacok)는 새이지만 전혀 날 수가 없죠? 그래서 공작새의 flyable() 은 항상 false 를 리턴해서 언제나 x,y 좌표로만 움직입니다. 반면에, 비둘기(pigeon)는 일정 높이까지는 날아갈 수 있기 때문에 그 기준(여기서는 10000)이 되기 전까지는 z좌표로도 움직일 수 있습니다. 이것을 새의 종류마다 중복코드 없이 구현하려면 추상클래스와 추상메소드를 이용해서 이렇게 구현할 수 있습니다. 이렇게 코드를 짜면, 중복코드가 없으면서도 새의 종류마다 주어진 위치까지 날 수 있는지를 판단할 수 있는 유연성을 허용하며 구현할 수 있습니다.

💡 Tip: interface의 메소드 또는 abstract class 의 abstract method 처럼 구현하는 클래스에서 직접 구현해야하는 경우 IntelliJ IDEA에서 command + N (window는 alt + insert)을 눌러서 implement methods를 선택하면 자동으로 코드완성이 됩니다. 혹은 class 선언 부분에 빨간줄이 그어진다면 alt + enter 로도 추천이 가능합니다. 이렇게 IDEA의 shortcut과 자동완성 기능을 잘 활용하면 코드를 빠르게 작성할 수 있으니 강의에서 다루지 않는 것이라도 찾아서 활용해보세요.

2) 인터페이스(interface)

• 인터페이스는 객체의 특정 행동의 특징을 정의하는 간단한 문법입니다. 인터페이스는 함수의 특징(method signature)인 접근제어자, 리턴타입, 메소드 이름만을 정의합니다. 함수의 내용은 없습니다. 인터페이스를 구현하는 클래스는 인터페이스에 존재하는 함수의 내용({} 중괄호 안의 내용)을 반드시 구현해야합니다.

• 인터페이스 형식

  👉 interface 인터페이스명{

    public abstract void 추상메서드명();

  }

  → 인터페이스의 메소드는 추상메소드, static메소드, default 메소드 모두 허용됩니다. (JDK 1.8부터)

• [코드스니펫] 인터페이스 예제 - Main 함수

    public class Main {
        public static void main(String[] args) {
  
        }
    }

interface Bird {
    void fly(int x, int y, int z);
}

class Pigeon implements Bird{
    private int x,y,z;

    @Override
    public void fly(int x, int y, int z) {
        printLocation();
        System.out.println("날아갑니다.");
        this.x = x;
        this.y = y;
        this.z = z;
        printLocation();
    }
    public void printLocation() {
        System.out.println("현재 위치 (" + x + ", " + y + ", " + z + ")");
    }
}

public class Main {

    public static void main(String[] args) {
        Bird bird = new Pigeon();
        bird.fly(1, 2, 3);
//        bird.printLocation(); // compile error
    }
}

• interface인 Bird 타입으로 선언한 bird 변수는 실제로 Pigeon 객체이지만, interface인 Bird 에 선언되지 않은 printLocation() 이라는 함수는 호출할 수 없습니다. interface type 으로 선언되어있는 부분에서는 실제 객체가 무엇이든지, interface에 정의된 행동만 할 수 있습니다.

💡 @Override 이 부분을 보고 생각나는게 있으신가요?! 앞에서 배웠던 메소드 오버라이딩의 개념이 abstract method, interface의 함수를 구현하는 데에도 사용됩니다.

3) 인터페이스 vs 추상클래스

• 인터페이스

  1. 구현하려는 객체의 동작의 명세
  2. 다중 상속 가능
  3. implements를 이용하여 구현
  4. 메소드 시그니처(이름, 파라미터, 리턴 타입)에 대한 선언만 가능

• 추상클래스

  1. 클래스를 상속받아 이용 및 확장을 위함
  2. 다중 상속 불가능 , 단일 상속
  3. extends를 이용하여 구현
  4. 추상메소드에 대한 구현 가능