스미스요원

운영체제란?

운영체제(operating system)란, 컴퓨터 하드웨어를 관리하는 소프트웨어이다.

운영체제는 컴퓨터 하드웨어를 관리할 뿐만 아니라, 컴퓨터 시스템의 자원들을 효율적으로 관리하고, 응용 프로그램과 하드웨어 간의 인터페이스로써 다른 응용 프로그램이 유용한 작업을 할 수 있는 환경을 제공해준다.

즉, 운영 체제는 사용자가 컴퓨터를 편리하고 효과적으로 사용할 수 있는 환경을 제공하는 시스템 소프트웨어라고 할 수 있다.

개발자는 운영체제를 왜 공부해야 할까? 기업에서는 왜 그렇게 운영체제 이론을 강조하면서 기술질문을 하는 것일까?

우선 내가 만든 프로그램, 혹은 내가 사용하는 프로그램이 컴퓨터에서 어떻게 수행되는지를 알아야 에러가 발생했을 때 빠르게 원인을 찾아
해결할 수 있고, 프로그램의 실행 속도나 메모리 성능을 지속적으로 개선하는 등 서비스를 확장해 나갈 수 있기 때문이다.

더불어 운영체제를 잘 이해하면 프로그램을 만들기 전에 개발 난이도, 비용, 성능 등을 예측할 수 있다.
이걸 사전에 파악하는 것은 한정된 시간과 비용으로 서비스를 개발해야 하는 기업 입장에서는 매우 중요할 것이다.

나 역시 처음 웹 개발 공부를 시작할 때에는 웹 개발에 운영체제 지식이 왜 필요해? 그건 임베디드 하는 애들한테나 중요한거 아니야?
라는 생각을 하곤 했지만... 웹 서비스를 배포하거나 서버 트래픽 관리, DB 쿼리 최적화 작업만 해도 수많은 프로세스 에러를 만나게 되면서
운영체제를 공부해야 한다고 주변에 외치고 다녔더랜다.

이러한 운영체제의 종류에는 Windows, Linux, UNIX, MS-DOS 등이 있으며 각각 장단점이 있으므로 사용하고자 하는 용도에 알맞게 선택하여 사용하는 것이 좋다.

프로세스 관리

운영체제의 역할 중 하나는 프로세스 관리 이며, 운영체제에서 작동하는 응용 프로그램을 관리하는 기능이다.

컴퓨터 CPU가 한번에 처리할 수 있는 양은 제한적이다. 따라서 여러 응용 프로그램이 동시에 CPU을 사용하려고 한다면 운영체제는 이를 적절히 배분해 줄 수 있어야 할 것이다. 즉 프로세스 관리는 프로세서(CPU)를 관리하는 것이라고 볼 수도 있다.

운영체제는 현재 CPU를 점유해야 할 프로세스를 결정하고, 실제로 CPU를 프로세스에 할당한 다음, 이 프로세스의 공유 자원 접근 및 통신 등을 관리한다. 이러한 작업을 우리는 스케줄링, 동기화, IPC 통신 이라고 부르는 것이다.
(각각이 어떤 작업을 의미하는지는 이후 포스팅에서 알아보자)

프로세스와 스레드

프로세스란, 특정 프로그램이 메모리 상에서 실행중인 작업 이다. 이 때 프로세스 안에서 실행되는 여러 흐름 단위를 스레드 라고 한다.

프로세스가 생성될 때, 기본적으로 하나의 스레드가 함께 생성된다. 즉 프로세스마다 최소 1개 이상의 스레드가 존재할 수 있다.

하나의 프로세스에는 Code, Data, Heap 이라는 세가지 메모리 영역이 존재한다.

• Code : 코드 자체, 프로그램 명령 등이 저장되는 영역

• Data : 전역변수, 정적변수, 배열 등이 저장되는 영역

    -  초기화 된 데이터는 data 영역에 저장된다.

    -  초기화 되지 않은 데이터는 BSS(Block Started by Symbol) 영역에 저장된다.

• Heap : 동적 할당된 데이터(new, malloc 등)가 저장되는 영역

이 때 하나의 프로세스에 여러개의 스레드가 존재하는 경우, 각 스레드에는 별도의 Stack 영역이 독립적으로 주어지지만

Code, Data, Heap 영역은 소속된 프로세스의 것을 공유하여 사용한다.

• Stack : 지역변수, 매개변수, 리턴 값 등이 저장되는 영역 (임시 메모리 영역)

즉 프로세스는 자신만의 고유 공간과 자원을 할당받아 사용하는데 반해,

스레드는 프로세스 내부에서 다른 스레드와 공간, 자원을 공유하면서 사용한다는 점에서 공간/자원 사용 측면의 차이가 있다.

멀티 프로세스

멀티 프로세스란 여러개의 프로세스가 동시에 병렬적으로 처리되는 상황을 의미한다.

보통 하나의 컴퓨터에 여러개의 CPU를 장착해야 가능하다. 단일 코어 CPU는 한번에 하나의 프로세스만 처리할 수 있기 때문이다.

• 장점 : 안전성 (메모리 침범 문제를 OS 차원에서 해결해준다)

• 단점 : 프로세스가 각각 독립된 메모리 영역을 갖고 있기 때문에, 작업량이 많을수록 오버헤드가 발생할 수 있다.

              또한 Context Switching 으로 인한 성능 저하가 발생한다.

• Context Switching

    -  프로세스의 상태 정보를 저장하고 복원하는 일련의 과정

    -  프로세스는 동작 상태와 대기 상태를 반복한다. 동작 중인 프로세스가 대기 상태가 되면 해당 프로세스의 정보는 보관되어야 한다.
       이후 대기 상태에서 다시 동작 상태가 되면 보관중이던 정보는 다시 복원되어야 한다. 이 과정이 바로 Contect Switching 이다.

    -  프로세스는 각각 독립된 메모리 영역을 할당받아 사용하기 때문에, 캐시 메모리 초기화처럼 무거운 작업이 진행될 때 오버헤드가
       발생할 수 있다.

멀티 스레드

멀티 스레드란 하나의 프로세스에서 여러 스레드가 각각 별개의 작업을 하나씩 처리하는 것을 의미한다.

즉 멀티 스레드를 이용하면 하나의 프로세스만 가지고 여러 작업을 동시에 처리할 수 있다.

멀티 프로세스로 여러 작업을 동시에 처리하는 것 보다 하나의 프로세스에서 멀티 스레드로 여러 작업을 동시에 처리하면

메모리 공간과 시스템 자원 소모를 줄일 수 있다.

또한 하나의 프로세스에 속한 스레드들은 Code, Data, Heap 공간을 공유하기 때문에

별개의 Code, Data, Heap 공간을 사용하는 멀티 프로세스 방식 보다 통신 방법이 간단하고 속도 역시 빠르다.

• 장점 : 멀티 프로세스 방식 보다 시간, 자원 손실이 적으며 쓰레드끼리 전역 변수와 정적 변수를 공유할 수 있다.

• 단점 : 안전성의 문제가 발생할 수 있다. 메모리 공간을 공유하기 때문에, 하나의 스레드가 메모리를 훼손하면, 모든 스레드의 작동이
              불가능해진다. 이러한 문제는 Critical Section 에 동기화 기법을 적용하여 방지할 수 있다.

• Critical Section

    -  특정 데이터에 둘 이상의 쓰레드가 동시에 접근해서 연산을 실행하는 경우 문제가 발생할 수 있다.
       이러한 문제를 일으키는 코드 블록을 Critical Section 이라고 한다. 즉 한 순간에 하나의 쓰레드만 접근해야 하는 공유 리소스 영역
       (전역 변수 등)에 접근하는 코드 블록을 Critical Section 이라고 한다.

    -  동기화 기법을 이용하면 임계 영역에는 한번에 단 하나의 쓰레드만 접근하도록 제한할 수 있다.

• 동기화 기법의 종류

    -  크리티컬 섹션(Critical Section) 기반 동기화 (유저 모드 동기화)

    -  인터락 함수(Interlocked Family Of Function) 기반 동기화 (유저 모드 동기화)

    -  뮤텍스(Mutex) 기반 동기화 (커널 모드 동기화)

    -  세마포어(Semaphore) 기반 동기화 (커널 모드 동기화)

    -  이름있는 뮤텍스(Named Mutex) 기반 프로세스 동기화 (커널 모드 동기화)

    -  이벤트(Event) 기반 동기화 (커널 모드 동기화)

동기화 기법마다 사용해야 하는 경우가 특별하게 정해져 있는 것은 아니지만,
목적에 적합한 동기화 기법을 잘 선택해서 사용하면 간결하고 정확한 코드를 작성할 수 있다.

참고자료

네트워크 이론을 공부할 때 반드시 마주치게 되는 개념이 있다. 바로 OSI 7 Layers 이다.
이 용어가 무엇을 의미하는지, 각 레이어는 무엇으로 이루어져 있는지 간단하게 살펴보자.

일단 컴퓨터 네트워킹이라는 개념은 아주 광대하고 복잡하다.
전 세계에 퍼져있는 거대한 인터넷망에 대한 이론이 상당히 심플하게 정리될 수 있다면 그거야말로 초-신기술일 것이다.
하지만 그런 마법같은 일은 일어나지 않았고, 개발자들은 이 복잡한 개념을 어떻게 정리해야 할지 고민한 결과,

네트워크 구조는 총 7가지의 계층 구조로 나누어지게 되었다.

그 결과, 거대한 네트워크 통신이 일어나는 과정을 단계별로 파악할 수 있게 되었고
네트워크 통신 규칙 및 통신 기술도 이러한 계층 구조에 기반하여 만들어지기 시작했다.

이에 따라 7개의 레이어 중 특정한 곳에 이상이 생기면 다른 단계의 장비 및 소프트웨어를 건들지 않고도
이상이 생긴 단계만 고칠 수 있게 되니 기술의 생산성이 높아졌고, 통신 기술은 점점 빠르게 발전할 수 있었다.

OSI 7 계층

OSI 7 계층은 위 그림과 같이 총 7개의 레이어로 이루어져 있다.

사용자가 데이터를 다른 누군가에게 보내면, 해당 데이터는 각 레이어를 거치며 제각기 다른 형태로 감싸져 다음 레이어로 전달된다.
7번째 계층부터 차례대로 각 계층의 의미와 역할을 간단하게 살펴보자.

7 Layer : Application Layer (응용 계층)

• 네트워크 상에서 데이터가 이동할 때 가장 끝과 끝에 위치한 목적지라고 볼 수 있다.
   - 예를 들어 A가 B에게 편지를 보낸다고 할 때, A가 보낸 편지는 A의 집에서 시작되어 우체국을 거치고, 도로 위를 이동하고,
       우편 배달부의 손을 거쳐 최종적으로 B의 집에 도착한다면 A의 집과 B의 집이 Application Layer에 해당한다.

• 네트워크 소프트웨어의 UI 부분 및 사용자의 입출력(I/O) 부분을 담당한다.

• 어플리케이션 계층 프로토콜

   -  HTTP(웹 문서), SMTP(전자메일), FTP(파일) 등 다양한 프로토콜을 포함한다.

   -  특정 위치에 있는 어플리케이션이 다른 위치에 있는 어플리케이션과 데이터를 교환할 때 이 프로토콜이 사용된다.

• 네트워크 어플리케이션

   -  어플리케이션 계층에서 생성되는 데이터는 메시지(message) 라고 불린다.

   -  이러한 메시지들은 어플리케이션 계층 프로토콜에 의해 처리되며, 우리가 사용하는 브라우저나 메일 프로그램 등은
      프로토콜을 보다 쉽게 사용하게 해주는 응용프로그램이다.

   -  메시지는 또 다른 어플리케이션 계층까지 전해지기 위해 바로 다음 계층인 Transport Layer로 전달된다.

6 Layer : Presentation Layer (표현 계층)

• 표현 계층은 데이터 표현 형식이 서로 다른 어플리케이션끼리 통신할 때 서로의 데이터를 해석할 수 있도록 해주며,
    데이터 해석 외에도 데이터 압축, 데이터 암호화 등의 작업을 담당한다.

   -  예를 들어 EBCDIC로 인코딩된 문서 파일을 ASCII 파일로 바꿔 주는 것,
       데이터가 TEXT 인지, GIF 인지, JPG 인지 구분하는 것 등이 표현 계층이 수행하는 역할이다.

• 표현 계층이 이러한 서비스를 제공해주기 때문에 어플리케이션 단계에서는 데이터가 표현 및 저장되는 형식을 신경쓰지 않아도 된다.

5 Layer : Session Layer (세션 계층)

• 데이터가 통신하기 위한 논리적인 연결이 이루어지는 계층이다. 쉽게 말해 통신이 맺어지는 관문이라고 할 수 있다.

• 세션 설정, 유지, 종료, 전송 중단시 복구 등의 기능을 수행하며 TCP/IP 세션의 생성과 소멸 작업을 책임지고 담당한다.

• 통신을 관리할 수 있는 기능으로 동시 송수신 방식(duplex), 반이중 방식(half-duplex), 전이중 방식(Full Duplex) 등을 제공하며

    통신 체크 포인팅 작업, 그리고 유휴/종료/다시 시작 등의 상태에 대한 작업을 수행한다. 

4 Layer : Transport Layer (전송 계층)

• 어플리케이션 레이어(4~7 계층)에서 만들어진 메시지를 클라이언트 단에서 서버로 전송하는 역할을 담당하는 계층이다.

    -  A가 B에게 편지를 보내려면 편지를 우체통에 넣어야 한다. 이 때 A가 쓴 편지가 어플리케이션 레이어에서 만들어진 메시지라면,
       편지를 우체통에 넣는 행위가 메시지를 서버에 올리는 작업이라고 할 수 있다.

• 즉 통신을 활성화시키는 계층이며 포트를 열어 응용프로그램이 데이터를 전송 할 수 있도록 연결을 맺는 역할을 수행한다.

• 어플리케이션 레이어에서 메시지를 받아 Transport 레이어에서 한번 더 감싸는 작업을 거치면 해당 데이터는 세그먼트(Segment)
    라고 불리게 된다. 이 데이터는 다시 바로 다음 계층인 Network 레이어로 전달된다.

• 만약 어플리케이션 레이어에서 데이터가 여러 개 도착했다면 전송 계층에서 이를 하나의 세그먼트로 모아 다음 계층에 전달한다.

• Transport Layer에는 TCP 와 UDP 라는 Transport Protocol 이 존재한다.

• 이 두가지 통신 규약을 통해 사용자들은 데이터가 신뢰할 수 있고, 손상되지 않은 데이터임을 보장받을 수 있다.

• Transport Layer가 존재함으로써 해당 계층의 상위 계층들은 데이터 전달의 유효성이나 효율성을 신경쓰지 않아도 된다.

• TCP (Transmission Control Protocol)

    -  연결 지향형 서비스 : 연결 관리를 위한 연결 설정(3 way handshake) 및 연결 해제(4 way handshake)가 필요하다.

    -  신뢰성 있음 (Reliable) : 패킷의 손실, 중복, 순서바뀜 등이 없도록 보장한다.

    -  Network 레이어로 세그먼트를 보낼 때 제대로 전달 되었는지 확인하고, 전송에 실패한 경우 재전송한다.

• UDP (User Datagram Protocol)

    -  TCP와 달리 비연결적인 접속 상태로 통신하며, 신뢰성이 없고 순서화되지 않은 서비스를 제공한다.

        ◦  메세지가 제대로 도착했는지 확인하지 않는다 : 확인 응답 없음

        ◦  수신된 메세지의 순서를 신경쓰지 않고 전송한다 : 순서 제어 없음

        ◦  흐름 제어를 위한 피드백을 제공하지 않는다 : 흐름 제어 없음

        ◦  checksum 을 제외하면 특별한 오류 검출 및 제어가 없다.

    -  그 대신 실시간 응용 및 멀티캐스팅이 가능하므로 빠른 요청과 응답이 필요한 실시간 서비스에 적합하다.

        ◦ 멀티캐스팅 : 여러 다수 지점에 데이터를 동시 전송하는 것 (1:多)

    -  또한 TCP가 세그먼트 헤더로 20 바이트를 사용하는데 비해 UDP는 8 바이트만 사용하므로 헤더 데이터 처리에 소요되는 비용이 적다

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

• Transport Layer 에서 전달된 세그먼트는 네트워크 계층 내에서 패킷(packet)이라는 이름으로 불린다.

• 이 계층에서 가장 중요한 기능은 데이터그램을 목적지까지 안전하고 빠르게 전달하는 기능(라우팅)이다.

    -  즉 목적지로 데이터를 보낼 수 있는 가장 빠른 경로를 선택하고, 경로를 따라 패킷을 전달하는 것이 이 계층의 역할이다.

• IP 프로토콜

    -  IP 데이터그램의 필드를 정의하며 라우터가 이 필드에 어떻게 작용하는지를 정의한다.

• 라우팅 프로토콜

    -  출발지와 목적지 사이에서 패킷이 이동하는 경로를 결정한다.

    -  네트워크 레이어는 여러개의 라우터(패킷 스위치)를 통해 패킷을 전송하고,
        라우터를 하나 지날 때 마다 데이터를 가장 빠르게 전송할 수 있는 라우터를 재탐색하며 경로를 만들어 나간다.

2 Layer : DataLink Layer (데이터링크 계층)

• 앞서 Network Layer는 출발지와 목적지 간에 일련의 라우터를 거쳐 데이터그램을 전송한다고 이야기했다.
    이 때 경로상의 한 라우터에서 다른 라우터로 데이터그램을 이동시킬 때 데이터링크 레이어의 서비스를 이용하게 된다.

    -  각 라우터에서 네트워크 계층은 데이터그램을 아래 데이터링크 레이어로 보내고, 데이터링크 레이어는 다음 라우터에 해당

        데이터그램을 전달한다. 다음 라우터에 데이터그램이 도착하면, 해당 라우터의 데이터링크 레이어는 받은 데이터그램을 상위
        네트워크 레이어로 올려 보낸다.

• 데이터링크 계층에서 전송되는 데이터 단위를 프레임(frame)이라고 하며, 이 계층에서는 맥 주소를 가지고 통신한다.

• 대표적인 장비로는 브리지, 스위치 등이 있다. (해당 장비들이 맥 주소를 사용한다)

1 Layer : Physical Layer (물리 계층)

• 이 계층에서는 주로 전기적, 기계적, 기능적인 특성을 이용해 통신 케이블로 데이터를 전송한다.

• 물리 계층에서 사용되는 통신 단위는 비트(bit)이며 이것은 1과 0, 즉 전기적으로 On, Off 상태를 나타내는 신호이다.

• 물리 계층은 데이터를 전달하기만 할뿐 수신/발신하려는 데이터가 무엇인지, 어떤 에러가 있는지 등은 전혀 신경 쓰지 않는다.
    단지 데이터를 전기적인 신호로 변환해서 주고받는 기능만 할 뿐이며, 이 계층에 속하는 대표적인 장비는 통신 케이블, 리피터, 허브
    등이 있다.

참고자료

검색어 자동완성 그리고 AJAX

• 어떻게 엔터를 쳐서 Request 를 날리지 않았는데도 연관된 검색어가 뜨는 것일까?

• 사용자가 ㄱ을 입력하는 순간, 웹브라우저는 자동으로 사용자가 입력한 값 ㄱ을 서버로 전송한다.

• 서버에서는 ㄱ을 받아서 ㄱ으로 시작하는 추천 검색어를 검색해 웹브라우저로 보내주고, 이를 브라우저에서 출력하는 것

• 그러나 매번 페이지 새로고침/리로드가 실행되지는 않는다 : AJAX 를 사용했기 때문!

AJAX(Asynchronous JavaScript and XML)

• 한국어로 번역하면 비동기식 자바스크립트와 XML 이라 불린다.

• 자바스크립트를 이용해 서버와 브라우저가 비동기 방식으로 데이터를 교환할 수 있는 통신 기술을 의미

    - 웹페이지를 리로드하지 않고 데이터를 불러오는 방식 = 비동기 방식

    -  Ajax를 통해 서버에 요청을 한 후 서버가 멈추어 있는 것이 아니라, 서버 프로그램은 계속 돌아간다

• 브라우저가 가지고있는 XMLHttpRequest 객체를 이용해 전체 페이지를 새로 고치지 않고도
    페이지의 일부만을 위한 데이터를 로드할 수 있는 기술이다.

• 페이지 리로드 하는 경우 전체 리소스를 다시 불러와야 해서 불필요한 리소스 낭비가 생길 수 있지만
    비동기 방식을 사용하면 필요한 부분만 불러와 사용하기 때문에 효율적이다.

AJAX 동작 원리

• 기본적으로 HTTP 프로토콜은 클라이언트쪽에서 Request 를 보내고 서버 쪽에서 Response 를 받으면 이어졌던 연결이
    끊어지게 된다. 즉, 화면의 일부 내용만 갱신하고 싶더라도 전체 페이지에 대한 Request, Response를 보내서 페이지 전체를

    갱신해야 한다.

• AJAX 는 페이지의 일부분만 갱신할 수 있도록 HTML 페이지객체가 아닌, XMLHttpRequest 객체를 통해 서버에 Request를 보낸다.

• 이 경우, JSON 이나 XML 형태로 필요한 데이터만 받아 페이지를 갱신하기 때문에 전체 페이지를 리로드 하지 않고도
    페이지 일부분의 업데이트가 가능하다.

AJAX 동작 과정

• 보내는 쪽

    -  XMLHttpRequest Object를 만든다.

    -  Request 를 보낼 준비를 브라우저에게 시키는 과정

    -  이것을 위해서 필요한 메서드를 갖춘 Object 가 필요하다.

    -  callback 함수를 만든다.

        -  서버에서 Response가 왔을 때 실행되는 함수

        -  HTML 페이지를 업데이트 한다.

    -  Open a Request

    -  Send the Request

• 받는 쪽

    -  수신하는 측에서는 응답을 받으면 응답 결과에 맞는 함수가 실행된다

    -  XMLHttpRequest 객체 생성

    -  URL을 통해 요청 전송

검색어 자동완성 그리고 한글의 자음모음

'a' in 'abcd' = True
'구' in '구공탄 곱창' = True

'ㄱ' in '구공탄 곱창' = 몰?루
'ㄱ' in ['ㄱ', 'ㅜ', 'ㄱ', 'ㅗ', 'ㅇ', 'ㅌ', 'ㅏ', 'ㄴ', ...] = True

• 한글 코드는 한 글자가 2바이트이며, 보통 완성형 코드와 조합형 코드로 나뉜다.

완성형 코드

• 자주 쓰이는 한글 2350자를 골라 가나다 순으로 배치하여 차례대로 코드를 부여한 것

• 코드 : 0xB0A1~0xC8FE (상위 8비트 : 0xB0 ~ 0xC8 / 하위 8비트 : 0xA1~ 0xFE)

• 자음/모음의 구성요소로 분리가 불가능하다.

조합형 코드

• 사용하는 2바이트(16비트) 중에서 상위 1비트는 아스키 코드와 구분하기 위해 사용하고
    다음 5비트/5비트/5비트는 각각 초성/중성/종성에 대한 정보를 저장한다.

• 자음/모음의 구성요소로 분리가 가능하다.

자음과 모음의 분리

• 한글이 조합형 코드로 표현되어 있다면 쉽지만 완성형 코드로 표현되어 있다면 조합형으로 변환이 필요하다.

• OS/라이브러리 등에서 제공하는 인코딩 기술을 사용하면 편하다. (예 : 메모장 활용하기)

검색어 자동완성 그리고 한글의 복잡성

첫번째 문제 : 복자음, 복모음 문제

• 네이버의 검색창에 오 를 쳐보면 자동완성 리스트에 오 로 시작되는 단어도 나오지만,
    와 로 시작되는 와우 같은 단어들도 나오는 것을 확인할 수 있다.

• 하지만 조합형 코드에서 ㅗ는 13, ㅘ는 14의 서로 다른 코드 값을 갖는다.

• 와 = ㅇ + ㅘ (O) / ㅇ + ㅗ + ㅏ (X)

• 이대로라면 오를 쳤을때 와우는 자동완성 리스트에 등장할 수 없다!

• ㅘ 를 ㅗ + ㅏ 로 분리해야 한다.

두번째 문제 : 받침에 오는 자음은 다음 글자의 첫번째 자음이 될 수도 있다.

• 갑을 입력했을 때 추천 검색어에는 갑상선이라는 단어도 나오지만, 가방이라는 단어가 나오기도 한다.

• 갑을 입력한 후 ㅏ를 입력하면 갑의 ㅂ받침이 다음 음절의 초성으로 넘어갈 수 있기 때문

• 그러나 초성에서의 ㅂ 코드값은 9 이고 종성에서의 ㅂ 코드값은 19로, 같은 ㅂ이라도 초성이냐 종성이냐에 따라 그 값이 달라진다.

• 종성에서 나타나는 자음의 코드값을 초성에서 나타나는 자음의 코드값과 같은 값으로 변환해주어야 한다!

• 복자음은 항상 종성에서만 나타나는데 이를 2개의 자음으로 분리한 후 초성의 코드 값으로 변환해야 한다!

    -  예) 돓 → 돌하르방

어떻게 저장하고 탐색할 것인가

데이터 구축 방식

• 자동완성 검색어 리스트를 보여줄 때 어떤 순서로 보여줄 것인가?

• 사용자가 입력한 검색어(검색 버튼을 클릭해 검색을 한) 빈도수 필드

• 빈도수가 높은 순서대로 추천 검색어로 출력이 되도록 하는 방법이 대표적

• 최근 일주일 / 최근 한달 등으로 기간을 정하는 방법도 있을 것이다.

B-Tree 알고리즘

• Trie / 캐싱 등 활용

• 여기까지 구현이 완료되면 이제 AJAX를 이용해 웹브라우저로 SHOW 해주기만 하면 된다.

그래서 이걸 다 구현해야 하나요?

• FE 라이브러리 jQuery의 AutoComplete를 활용하면 조금 더 쉽게 구현할 수 있다.

• 스프링을 이용하여 직접 구현할수도 있지만, 이 경우 DB 설계가 중요하다.

    -  이 때 Redis(인메모리 기반의 DB)가 주로 사용된다.

    -  Redis는 인메모리를 사용하기 때문에 디스크 혹은 클라우드 메모리를 사용할때보다 메모리 Read/Write 속도가 훨씬 빠르므로

참고자료

일반적인 웹 서버

• 클라이언트로부터 요청이 오면 가장 앞단에서 해당 요청에 대한 처리를 수행하고 응답을 반환하는 역할

• HTTP 요청을 받아들이고 HTML, 이미지 파일, CSS 같은 정적 컨텐츠를 반환한다.

    -  정적 컨텐츠(html, png, css 등)는 직접 제공이 가능하지만 DB등을 참조해야 하는 동적 컨텐츠는 WAS의 도움이 필요하다.

• 대표적인 웹 서버 : Apache, NGINX

• 정적 컨텐츠가 아니네! 웹서버에서 간단히 처리하지 못하겠군. WAS 에게 처리를 부탁해야겠다
     → WAS가 처리해준 데이터를 받아 와서 Response에 담아 반환

• 정적 컨텐츠구나! 내가 제공해줄게 → html, png 등을 Response에 담아 반환

웹 어플리케이션 서버(WAS, Web Application Server)(앱서버)

• 동적 컨텐츠(DB조회, 비즈니스 로직 처리가 요구되는 컨텐츠)를 제공하기 위해 만들어진 서버

    -  주로 데이터베이스 서버와 함께 가동된다.

• 웹서버와 WAS의 용어 경계가 명확한 것은 아니다 : WAS가 웹서버의 기능을 포함하는 경우가 많음

• JSP, Servlet 구동 환경을 제공하며 컨테이너, 웹 컨테이너, 서블릿 컨테이너라고 불리기도 한다.

• 대표적인 WAS : Tomcat, Jeus, JBoss

    -  SpringBoot 는 Tomcat을 내장하고 있어서 별다른 WAS 설정 없이도 서버를 구동시킬 수 있다.

• 웹서버와 앱 사이의 동적인 정보를 생성하는 역할을 담당하는 미들웨어

    -  웹서버는 앱을 알지 못하고, 반대로 앱은 웹서버를 알지 못한다.

    -  WAS가 웹서버와 앱 사이에서 중간다리 역할을 해주는 것!

    -  예) Tomcat 은 웹을 통해 들어온 HTTP request를 java 언어로 변환하여 앱에 전달하고,
             앱에서 생성된 java 응답을 다시 HTTP request로 변환하여 웹서버로 전달해주는 역할을 수행한다.

WAS 만 있어도 서버 구동은 가능하잖아?

• 사실 WAS와 DB만 있으면 당장 서비스 제공이 가능하다.

    -  WAS는 정적 리소스, 어플리케이션 로직 모두 핸들링 가능하기 때문

• 실제로 API 만 제공한다면 WAS 만 구축하기도 한다.

• 하지만 이렇게 되면 WAS가 너무 많은 일을 담당하게 된다.

    -  앱 로직도 실행해야 되고, 정적 컨텐츠도 제공해줘야 되고…

    -  정작 중요한 어플리케이션 로직이 정적 리소스를 제공하느라 바빠서 속도가 느려진다면?

• 로직을 잘못 짰거나 디비에 오류가 생겨서 WAS가 죽는다면? 오류 화면 조차 확인이 불가능

• 그래서 일반적으로는 client → Web Server(정적 리소스 처리) → WAS(동적 리소스/로직 처리) → DB
    식으로 아키텍처를 구성한다. 그러면 시스템 리소스를 효율적으로 처리할 수 있음.

• 또한 웹서버를 사용하면, 웹서버가 제공해주는 다양한 기능을 활용할 수 있다.

    -  예) NGINX : 동시 접속 처리에 특화된 웹서버 이 밖에 리버스 프록시, 캐싱, 로드 밸런싱, 미디어 스트리밍 등
             유용한 여러 역할을 수행한다.

  웹서버 + WAS의 동작 프로세스

• 클라이언트가 웹 페이지로 요청을 보내면, 웹서버가 해당 요청을 받아 필요한 부분을 WAS에 요청한다.

• WAS(컨테이너)는 web.xml 을 참조하여 해당 서블릿의 작업을 담당하는 쓰레드를 생성한다.

    -  HTTPServletRequest 와 HTTPServletResponse 객체를 먼저 생성한다.

    -  그 다음 서블릿을 호출하고, 생성한 객체를 전달한다.

• 호출된 서블릿의 작업을 담당하는 쓰레드는

    -  Request 에 따라 doPost 또는 doGet 메소드를 호출해 데이터를 먼저 생성한다.

    -  그 다음 이것를 Response 객체에 담아 다시 WAS 컨테이너에 전달한다.

• WAS 컨테이너는 전달받은 Response 객체를 HTTPResponse 형태로 바꿔 웹서버에 전달하고,
    생성되었던 쓰레드를 종료한 다음 HTTPServletRequest, HTTPServletResponse 객체를 소멸시킨다.

• 프록시 서버 (캐싱)

    -  Client와 WebServer 사이에 프록시 서버가 존재할 수 있다.

    -  자주 조회되는 정보를 프록시 서버에 캐싱하면 빠르게 접근할 수 있다.

  참고자료

1. REST(Representational State Transfer) API 란 무엇인가?

REST API의 개념과 등장 배경

• 자원을 이름으로 구분하여 해당 자원의 상태(정보)를 주고 받는 모든 것을 의미

• 2000년도 로이 필딩(Roy Fielding)의 박사학위 논문에서 최초로 소개된 개념.

    -  HTTP의 주요 저자 중 한 사람

    -  웹(HTTP)이 우수한 설계에 비해 제대로 사용되지 못하고 있음에 안타까워하며 웹의 장점을 최대한 살릴 수 있는
       아키텍처로 REST를 발표했다.

REST API의 구성요소

• 자원(Resource) : URI로 표현된다.

    -  해당 소프트웨어가 관리하는 모든 데이터(문서, 그림 등)

    -  자원의 표현(Representations) : 그 자원을 표시하는 이름

        ◦  예) DB의 학생 정보가 자원일 때, students를 자원의 표현으로 정한다.

    -  URL과 URI의 차이
       

        ◦  https://agentsmith.tistory.com

        ◦  Tistory 블로그 중에서도 agentsmith의 블로그에 대한 경로를 나타내고 있다.

        ◦  서버에서는 해당 라우팅에 대한 알맞은 자원을 전송해줄 것이며, 자원의 실제 위치이므로 URL이다.

        ◦  https://agentsmith.tistory.com/12

        ◦  agentsmith의 티스토리 블로그에서 12의 ID값을 가지는 자원(포스팅)을 식별하고 있다.

        ◦  https://agentsmith.tistory.com 까지는 자원의 실제 위치이기 때문에 URI임과 동시에 URL이며, /12 부분은 식별자이다.

        ◦  즉 위 링크는 URL(https://agentsmith.tistory.com)을 포함한 URI(https://agentsmith.tistory.com/12)라고 할 수 있다. 

• 행위(Verb) : HTTP METHOD(GET, POST, PUT, DELETE)

    -  데이터가 요청되어지는 시점에서 자원의 상태(정보)를 이용한 행위

    -  JSON 혹은 XML를 통해 데이터를 주고 받는 것이 일반적이다.

핵심정리

• 첫번째  URI는 정보의 자원을 표현해야 한다.

• 두번째  자원에 대한 행위는 HTTP Method(GET, POST, PUT, DELETE)로 표현한다.

2. 지키면 좋은 간단한 규칙들

URI Rules

• URI는 정보의 자원을 표현해야 한다.

• 자원 이름은 동사보다는 명사를 사용할 것

• 컨트롤 자원을 의미하는 URI는 예외적으로 동사를 허용한다.

• http://agentsmith.tistory.com/12/duplicate

• URI description 규칙

    -  URI 마지막에  /  를 포함시키지 말 것

    -   _  (underbar) 대신  -  (dash)를 사용할 것

    -  소문자를 사용할 것

    -  행위(method)는 URL에 포함하지 말 것

    -  자원에 대한 행위는 URI가 아닌, HTTP Method로 표현할 것

• HTTP Method

    -  GET(조회), POST(생성), PUT(수정), DELETE(삭제) 등

        ◦  GET /members/delete/1 (X)

        ◦  DELETE /members/1      (O)
       -------------------------------

        ◦  GET /members/show/1  (X)

        ◦  GET /members/1           (O)

• Colllection과 Document을 활용하면 좀 더 직관적인 REST API를 설계할 수 있다.

    -  더 큰 개념으로 생각하면 쉬움. 자원에 대한 부가적인 설명을 나타내는 역할

    -  컬렉션 : sports / 도큐먼트 : soccer

        ◦  예) http:// restapi.example.com/sports/soccer

        ◦  예) http:// restapi.example.com/sports/soccer/players/13

​

HTTP Method Rules

• 하나의 자원에 대해 POST, GET, PUT, DELETE 4가지 methods는 반드시 제공할 것

• OPTIONS, HEAD, PATCH를 사용하여 완성도 높은 API를 만들자.

• HTTP status를 method의 리턴값으로 제공할 것

• 성공 응답은 2XX 로 응답한다.

• 실패 응답은 4XX 로 응답한다. (보통 잘못된 URL 접근시 볼 수 있는 에러)

• 5XX 에러는 절대 사용자에게 나타내지 마라 (보통 DB 또는 코드의 잘못으로 나타나는 에러)

3. RequestParam vs PathVariable vs RequestBody

Path Variable

<https://agentsmith.tistory.com/{id}>
<https://agentsmith.tistory.com/12>

• 개별 자원을 구분하여 요청할 때 많이 사용하는 방법

Request Param

<https://agentsmith.tistory.com/?filter=lowPrice>
<https://agentsmith.tistory.com/?startDate=2022-04-20&endDate=2022-04-25>
<https://agentsmith.tistory.com/?page=3>

• 주로 필터링 또는 페이징을 이용해 자원을 요청할 때 많이 사용하는 방법

    -  필터링  낮은 가격 순으로 보기 / 2022-04-20~2022-04-25 만 보기

    -  페이징  데이터가 너무 많아 한 페이지에 한번에 표시하기 어려운 경우

Request Body

{
   "id": 1,
   "name": "홍길동",
   "team": { "id": 1 },
   "email": "gildong@naver.com",
   "position": "intern",
   "createdAt": "2022-04-22",
   "updatedAt": "2022-04-22"
}

• 새로운 자원을 생성하거나(POST), 자원의 정보를 한번에 수정하고 싶을 때(PUT) 주로 사용하는 방법

• JSON 형식의 데이터를 RequestBody에 담아 보낸다.

4. REST API 설계 방식 엿보기

네이버 오픈 API

카카오 오픈 API

구글 오픈 API

5. 참고자료