백엔드 개발자 CS 개념 모음

Dev-Tech Study Repository

좋은 개발자로 성장하기 위해 부족한 기초 개념을 정리하였습니다. 지속적으로 추가됩니다.

프로세스

메모리상 실행중인 프로그램을 말하며 디스크로부터 메모리에 적재되 CPU 할당을 받을 수 있는 것을 말합니다. 프로세스는 최소 하나의 스레드를 보유하며 별도의 주소공간을 독립적으로 할당받습니다.

스레드

프로세스 내에 하나의 실행 단위를 말합니다. 프로세스내에서 스레드는 자원을 공유할 수 있으며 하나의 프로세스에서 다수의 스레드를 실행 단위로 구분한 것을 멀티스레드라 말합니다.

멀티 프로세스로 처리 가능한걸 멀티 스레드로 하는 이유?

멀티스레드로 작업시 멀티 프로세스보다 공유하는 통신 비용이 적고 프로세스 생성 후 자원을 할당하는 시스템 콜이 감소할 수 있기에 더 효율적입니다. 대신 공유 자원으로 인한 동기화를 고려해야합니다.

DeadLock(교착상태)

프로세스가 자원을 얻지 못해 다음 처리를 못하는 상태에 빠진 것을 말합니다. 한정된 자원보다 더 사용하려고 할때 발생하며 교착상태 발생 필수 조건 다음과 같습니다.

• 상호배제 : 필요로 하는 자원에 대해 배타적 통제권 요구
• 점유대기 : 할당된 자원을 가진 상태에서 다른 자원 기다림
• 비선점 : 어떤 자원의 사용이 끝날때까지 해당 자원을 뺏을 수 없음
• 순환대기 : 순환적으로 다음 프로세스가 요구하는 자원을 가지고 있음

RESTful API

API 설계의 중심엔 자원이 있고 http method를 통해 자원을 처리하도록 설계하는 방식입니다.

• 리소스와 행위를 명시적이고 직관적으로 분리
• 행위는 http method get, post, put(entity 전체 수정), patch(entity 일부 수정), delete로 표현
• Header와 Body를 명확히 분리해서 사용
  • Entity의 내용은 Body에 담아서 요청
• API 버전 관리
• 클라이언트, 서버 둘 다 json이든 form-data 형식으로 보내든 통일

RESTful 장점

• 멀티플랫폼 지원 및 연동에 유리
• 기존 웹 http 인프라를 그대로 사용 가능

RESTful 단점

• 메소드가 4가지밖에 존재하지 않음
• http 통신 프로토콜에 대해서만 지원

HTTP Protocol

서버/클라이언트 모델을 따라 데이터를 주고받기 위한 프로토콜입니다. TCP/IP 위에서 동작하며 method, header, body, path 등으로 request가 구성되어 있습니다. 도청, 변조가 가능하여 보안적으로 안전한 서비스의 경우 https를 사용하기도 합니다.

response code

• 100번대 : 정보 확인
• 200번대 : 성공
  • 200 : 서버 요청 처리 성공
  • 201: 요청 접수 후 새 리소스 작성
• 300번대 : 리다이렉트
  • 301: 요청 페이지가 새 위치로 영구적 이동 (요청페이지 변경)
  • 302: 임시이동 요청자
• 400번대 : 클라이언트 오류
  • 400: 클라이언트 오류 (잘못된 클라이언트 요청)
  • 401: 권한 없음
  • 404: 서버에 요청한 리소스 찾을 수 없음
• 500번대 : 서버측 오류

HTTP와 HTTPS의 차이

http와 https의 차이점은 http 통신하는 소켓 부분을 SSL이라는 프로토콜로 대체하는것입니다.

• http 동작 순서 : TCP → HTTP
• https 동작 순서 : TCP → SSL → HTTP

SSL을 사용하지 않는 사이트의 경우 암호화로 인해 속도 저하가 발생하기 때문입니다.

SSL

Secure Socket Layer라는 뜻으로 보안 프로토콜을 통해 클라이언트와 서버가 통신하는 것을 말합니다. 이 링크를 사용하면 전송된 모든 데이터가 비공개로 유지(TLS - 전송계층보안)됩니다.

또한 SSL 암호화를 통해 연결을 보호하고 데이터의 변조를 방지하는 역할을 합니다.

웹 통신의 흐름-1

1. 주소창에 url을 입력 후 enter를 누르면 서버에 요청이 전송됩니다.
2. 해당 페이지 path에 존재하는 자원들을 응답으로 보내줍니다. (text, css, image)
3. 브라우저는 자원이 담긴 html과 css를 W3C 명세에 따라 해석합니다.
4. 해석한 렌더링 엔진은 html 파싱 작업을 시작하며 DOM 트리를 구축합니다.
5. css 파싱 작업을 시작하며 css가 담긴 정보를 스타일 구조체로 생성합니다.
6. html과 css를 연결하여 렌더트리를 만들고 시각적 요소를 포함한 형태로 출력을 준비합니다.
7. 화면 배치를 시작하고 출력을 진행합니다.
8. 이때 브라우저 화면에 표시될 때 "배치, 렌더링 과정"은 기다리는 동시에 일부분 먼저 진행하고 화면에 표시합니다.

웹 통신의 흐름-2

1. 브라우저는 DNS 서버로 가서 웹사이트의 진짜 서버 주소를 찾는다.
2. 브라우저는 서버에게 웹사이트 사본을 클라이언트에게 보내달라는 http 요청 메세지를 서버로 전송(이때 메세지 및 클라이언트 사이에 전송된 모든 데이터는 TCP/IP 연결)
3. http 요청을 받은 서버는 클라이언트 요청을 승인 후 메세지를 클라이언트에게 전송
4. 서버는 응답해줄 파일들을 데이터 패킷이라는 작은 덩어리로 브라우저에 전송
5. 브라우저는 패킷들을 웹사이트로 조립 후 사용자에게 보여준다

GET

• Header부분에 url이 담겨 전송
• url 공간에 데이터가 담겨 전송되기에 보안에 취약하고 데이터 크기도 제한적
• 브라우저에서 caching 가능

POST

• Body부분에 데이터가 담겨서 전송
• 보안면에서 get보다 뛰어남

GET과 POST의 차이

get은 가져오는 것이고 post는 수행하는 개념입니다. get은 select의 개념에 가까워 데이터의 리스트, object 1개를 조회하는 등 말 그대로 조회만 할 뿐 데이터의 수정, 상태 변경은 발생하지 않습니다. 반면 post는 서버의 상태나 값이 변경되는 작업을 요청할 때 사용합니다. 입력 데이터를 등록하거나 수정되는 경우를 말합니다.

쿠키

클라이언트(브라우저) 로컬에 저장되는 key:value 값 데이터파일을 말합니다. 유효시간을 명시 가능하며, 브라우저가 종료되어도 인증은 유지됩니다. 최대 300개까지 저장이 가능하며 도메인당 20개의 값을 할당 가능합니다. 자동로그인, 팝업, 더 이상 이창을 보지 않음, 장바구니, 아이디 자동저장등 기능에 사용됩니다.

세션

쿠키를 기반하지만 서버측에서 관리되기 때문에 웹에서만 사용 가능합니다. (앱은 불가)

클라이언트가 요청시 서버의 엔진이 클라이언트에게 유일한 id를 부여하게 되는데 이것이 세션 id입니다.

브라우저 종료되면 인증상태 종료되며 서버측에 관리되어 보안은 좋지만 사용자가 많을수록 서버 메모리에 있어 비효율적입니다.

그렇기에 동접이 많은 웹사이트는 성능 저하의 요인이 될 수 있습니다.

화면을 이동해도 로그인이 풀리지 않고 로그아웃 시키기 전까지 인증 유지하는 것을 세션의 대표적 기능입니다. (클라이언트가 요청을 보내면 서버의 엔진이 클라이언트에게 유일한 id를 부여하는데 이게 세션 id)

쿠키와 세션을 사용하는 이유?

정보가 유지되지 않으면, 매번 페이지를 이동할 때마다 로그인(인증)을 다시 하거나, 상품을 선택했는데 구매 페이지에서 선택한 상품의 정보가 없거나 하는 등의 일이 발생할 수 있습니다.

따라서, 상태 유지가 필요한 경우를 대처하기 위해서 쿠키와 세션을 사용한다.

또한 쿠키와 세션의 차이점은 크게 상태 정보의 저장 위치입니다. 쿠키는 클라이언트(=로컬PC)에 저장하고, 세션은 서버에 저장합니다.

쿠키 동작 순서

1. 클라이언트 페이지 요청
2. 웹서버 쿠키 생성
3. 쿠키 정보를 담아 http 응답을 줄 때 클라이언트에게 전달
4. 클라이언트는 받은 쿠키정보를 로컬 pc에 저장했다가 서버에 다시 요청시 쿠키와 함께 전송
5. 서버는 쿠키가 있는 경우 요청페이지와 함께 쿠키를 다시 재전송

세션 동작 순서

1. 클라이언트 페이지 요청
2. 서버는 클라이언트의 request-header 필드인 cookie를 확인하고 클라이언트가 세션 id를 보냈는지 확인
3. 세션 id가 존재하지 않으면 session id 생성 후 클라이언트에게 전달
4. 서버에서 클라이언트로 돌려준 세션 id를 쿠키를 사용해 서버에 저장(jsessionid)
5. 클라이언트는 재 접속시 쿠키(jsessionid)를 이용해 세션 id 를 서버에 전달

인증

어떤 서비스를 이용할 때 사용자의 ID를 식별하는 절차를 말합니다. 쉽게 말해 로그인을 의미하며 디바이스, 애플리케이션별로 사용자의 요구에 따라 조금씩 차이가 있습니다.

소켓

네트워크상 동작하는 프로그램간의 통신 endpoint를 이야기합니다. 프로그램을 사용하면서 네트워크에 데이터 통신할 수 있도록 연결해주는 역할을 하며 두 클라이언트 모두 소켓이 생성되었을때 통신이 가능합니다. 클라이언트 소켓에 연결요청을 하면 서버 소켓이 승인하여 통신할 수 있도록 연결이 되는 방식입니다.

동기와 비동기의 개념

동기

순서대로 일의 처리가 완료된 후 다음 동작을 실행하는 것을 말합니다. 메소드를 실행시킴과 동시에 반환값을 기대하는 경우를 의미합니다. 쉽게 말해 작업을 위임한 상위 프로세스는 작업을 위임받은 하위 프로세스가 종료될때까지 아무 작업도 할 수 없는 상태를 말합니다. (블록킹 방식) 이는 상위 프로세스가 하위 프로세스에게 작업을 지시할 때 종료시점을 알고 있어야 한다는 것을 의미합니다.

비동기

요청의 순서에 따르지 않고 다음 동작을 실행하는 것을 말합니다. 메소드를 실행 후 반환값을 기대하지 않고 다른 것들을 실행하는 것을 말합니다.

멀티스레드

프로세스를 사용해 동시 처리하는 일을 다수의 스레드로 구현시 메모리와 시스템 자원 소모가 줄어들게 됩니다. 이는 스레드간의 자원과 공간을 공유(전역 변수 공간, 동적 heap 영역 공유)할 수 있기 때문입니다. 프로세스간의 공유방식보다 스레드간의 공유 방식이 훨씬 간단한 점도 멀티스레드의 장점이지만 스레드간의 공유로 인해 엉뚱한 값을 읽어오거나 수정할 수 있는 점을 고려해서 늘 동기화를 신경써야하는 점이 단점입니다. (동기화 -> 작업순서 컨트롤 -> 과도한 락으로 병목현상 방지)

stack

한쪽 끝에서 자료를 넣고 뺄 수 있는 LIFO(Last In First Out) 형식의 자료구조입니다. 가장 마지막에 추가한 항목이 가장 먼저 제거되는 것을 의미합니다. 파이썬에서는 빈 리스트로 스택을 구현할 수 있습니다.

• pop: 가장 최근 항목을 제거
• append: item 하나를 추가
• top: 가장 최근 항목을 반환 ([-1])

queue

큐는 FIFO(First In First Out)의 선입선출 형식의 자료구조입니다. 큐는 데이터를 추가한 순서대로 제거할 수 있기때문에 너비우선탐색(BFS), 스트리밍에서 응용하여 사용할 수 있습니다.

python에서 queue를 구현할 때에는 collections의 deque를 이용하여 사용합니다. deque는 double-ended queue의 약자로 양방향에서 추가 및 제거가 가능한 자료구조입니다.

• append: item 하나를 추가
• popleft: 첫번째 데이터 제거

메모리 관리 전략

각 프로세스는 독립된 메모리 공간을 가지고 있고 운영체제 또는 다른 프로세스 메모리 공간에 접근할 수 없는 제약이 있습니다. 운영체제만이 운영체제 메모리와 사용자 메모리 영역에 제약이 없이 접근 가능합니다. CPU가 직접 접근하는 유일한 저장장치로 메모리 시스템(하드웨어)은 주소를 관리하며 자원 할당과 접근을 제어합니다. 제한된 물리 메모리의 효율적 사용(할당)과, 메모리 참조 기능을 합니다.

Swapping

메모리 관리를 위해 사용되는 기법입니다. 표준 Swapping 방식으로 round-robin(시분할 시스템을 위해 설계된 선점형 스케줄링의 하나, 프로세스들 사이에 우선순위를 두지 않고, 순서대로 시간단위로 CPU를 할당하는 방식의 CPU 스케줄링 알고리즘)과 같은 스케줄링의 다중 프로그래밍 환경에서 CPU 할당 시간이 끝난 프로세스의 메모리를 보조 기억장치로 내보내고 다른 프로세스의 메모리를 불러들이는 것을 말합니다. 주 기억장치로 불러오는 과정을 swap-in, 보조 기억장치로 내보내는 과정을 swap-out이라 말합니다.

Fragmentation

프로세스들이 메모리에 적재되고 제거되는 과정이 반복되면 프로세스들이 차지하는 메모리 틈 사이에 여분 찌꺼기 공간이 늘어나는데 이것을 단편화라 말합니다. (디스크 정리와 비슷한 개념)

외부 단편화는 메모리 공간중 사용하지 못하게 되는 일부분을 말하며 물리 메모리 사이에 남는 공간을 합쳤을때 충분한 공간이 되는 부분들이 분산되어 있을떄 발생합니다.

프로세스A	FREE-1	프로세스B	FREE-2	프로세스C

내부 단편화는 프로세스가 사용하는 메모리 공간에 남아 있는 공간을 말합니다. 적재될 수 있는 공간이 1,000B일 때 프로세스가 950B를 사용하게 되면 50B가 남는데 이런 경우를 내부 단편화라 말합니다.

프로세스A	프로세스B	프로세스C	FREE-1

OSI 참조모델

통신시 어떻게 메세지를 주고받고 어떤 언어를 사용할지 규칙일 필요한데 이러한 규약을 통신 프로토콜이라 합니다.

네트워크 시스템에 일어나는 일을 계층으로 나눠 시각적인 7개로 표현을 한것을 말합니다.

7계층을 나눈 이유

통신이 일어나는 과정을 단계별로 구분할 수 있고 중간에 이상이 생기면 해당 단계에서만 수정하면 되기 때문

물리 계층

• Repeaters, Hubs
• 전기적 신호로 변환해서 주고 받는 기능을 진행 (데이터 전송)

데이터 링크 계층

• Bridge, Switch
• 물리 계층으로 송수신되는 정보를 관리하여 안전히 전달되도록 도와주는 역할
• MAC 주소를 기반

네트워크 계층

• Router, IP
• 데이터를 목적지까지 안전하고 빠르게 전달하는 기능
• IP 주소 지정 후 경로에 패킷을 전달 (흐름제어, 오류제어, 라우팅)

전송 계층

• TCP(네트워크 통신시 신뢰적 연결 방식), UDP(비연결성, 신뢰성 없는 연결 방식)
• 위 프로토콜을 통해 통신 활성화, 전송 역할 (데이터 흐름 제공)

세션 계층

• API, SOCKET
• 데이터가 통신하기 위한 논리적 연결을 담당
• TCP/IP 세션을 생성하고 제거하는 역할

표현 계층

• JPG, MPEG
• 데이터 표현에 대한 독립성 제공 및 암호화 인터페이스 역할 (압축, 인코딩, 암호화)

응용 계층

• HTTP, DNS, FTP
• 최종 목적지, 사용자 인터페이스, 전자우편, DB 관리등 사용자 네트워크 접근 서비스 제공

TCP/IP 프로토콜

LINK 계층

• 물리적 영역
• LAN, WAN과 같은 네트워크 표준과 관련된 프로토콜 정의

IP 계층

• 경로 검색 계층
• IP 자체는 비연결지향적, 신뢰할 수 없는 프로토콜
• 데이터를 전송시 경로를 선택해주지만 일정치 않음

TCP/UDP (전송)계층

• 데이터의 실제 송수신 담당
• TCP는 신뢰성있는 데이터 전송, UDP 는 상대적으로 TCP에 비해 간단
• TCP는 데이터 전송시 IP 프로토콜 기반
  • 사실상 IP의 문제를 해결해주는 것이 TCP
  • 데이터가 잘 전송되었는지 확인하고 소통하는 방식 (신뢰성 없는 IP에 신뢰성 부여 TCP)

애플리케이션 계층

• 서버와 클라이언트를 생성하는 과정에 프로그램 성격마다 데이터 송수신에 대한 규격이 정해지는 것을 의미

Cache

서비스 환경에서 성능 향상을 위해 사용하는 기술로 DB에 조회하는 것이 아닌 메모리(값을 미리 복사해놓는 임시 저장소)를 사용하는 방식을 말합니다. 저장공간이 작고 비용이 비싼 대신 빠른 성능을 제공합니다. 서비스 운영시 사용자가 증가하면 유저의 요청을 DB에 매번 접근한다면 무리가 가기 때문에 요청된 결과를 미리 저장해두었다가 빠르게 제공합니다.

Caching 전략시 고려할 점

• 반환 데이터는 늘 고유한지? (검색어)
• 데이터는 한번 쓰고 여러번 읽는지? (유저 프로필)
• 자주 읽는 여부 (시간 기반 로그)
• 캐시 데이터 수명 (데이터가 제거되지 않고 캐시 저장소에 계속 저장되는건 효율적이지 않음)

Caching 전략

캐시를 옆에 두고 필요시 데이터를 캐시에 적재하는 전략

• 처음 사용자 요청시 캐시 스토리지는 아무 데이터도 없는 상황
  • 애플리케이션 캐시 저장소에 데이터 조회
  • DB 데이터 조회 -> 사용자에게 응답
  • 사용자에게 전달한 데이터를 캐시 저장소 저장
• 다음 요청시 캐시 스토리지에 데이터가 존재
  • 애플리케이션 캐시 저장소에 데이터 조회
  • 캐시 저장소에 있는 데이터 제공

Cache Aside 장점

• 읽기(조회)가 많은 서비스에 적합
• redis가 가장 많이 사용되며, 캐시를 분리해 db 모델과 차이를 가질 수 있음

Cache Aside 단점

• 캐시저장소에 데이터가 없을 경우 더 시간이 오래걸림
• 최신 데이터 유지 리스크 (동기화 이슈)

캐시는 DB와 일렬로 배치되고 캐시에서 조회가 불가능시 DB에서 데이터를 조회하고 캐시를 채운 후 애플리케이션에 반환합니다. 즉 처음 조회 요청시만 데이터를 로드합니다. aside 전략과 차이는 애플리케이션이 캐시를 채우는 역할을 하는지 아닌지에 차이입니다.

Read-Through 장점

• 읽기(조회)가 많은 작업에 적합

Read-Through 단점

• DB 모델과 다를 수 없습니다.
• 데이터를 처음 요청시 캐시 누락이 발생하고 이 때문에 패널티가 발생해 첫 요청시만 캐시 미스를 나지 않도록 개발자가 직접 로직을 구현

애플리케이션은 데이터를 캐시에 먼저 저장해놓은 후 특정 시점마다 한번씩 캐시 내 데이터를 DB에 insert하는 방법을 말합니다.

Write-Back 장점

• 쓰기가 많은 작업에 적합
• read-through와 결합해 최근 업데이트되고 접근된 데이터를 항상 캐시에서 사용할 수 있는 작업에 적합
• DB 전체 쓰기 작업에 대한 비용 감소

Write-Back 단점

• 캐시서버 오류시 데이터를 영구 손실할 수 있음

WAS와 Web Server 차이

Web Server

웹 브라우저에서 특정 페이지를 요청할 때 서버에서 해당 요청을 받아 정적 콘텐츠를 제공하는 웹서버를 말합니다. 여기서 말하는 정적콘텐츠란 html, css, js, image등의 static한 파일들을 말합니다. 웹서버는 정적 콘텐츠뿐만 아니라 동적 콘텐츠 요청을 받았을 때 WAS에 해당 요청을 전달해 WAS에서 처리한 결과를 다시 사용자에게 전달해주는 다리 역할도 합니다. (Nginx, Apache)

Web Sever가 필요한 이유

정적 파일들은 클라이언트 요청에 의해 응답으로 보내질때 웹 문서와 함께 전송되는 것이 아닙니다. HTML 웹 문서를 먼저 받고 이에 맞게 이미지 파일들을 다시 서버에 요청하여 그때 정적 파일들을 받아옵니다. 이때 Web Server를 사용해 정적 파일들을 관리한다면 Application Sever까지 가지 않고 앞에서 빠르게 파일들을 가져올 수 있습니다. 결과적으로 Web Server를 사용하여 정적 파일들의 기능 분배를 통해 서버의 부담을 줄일 수 있습니다.

WAS

웹 서버와 웹 컨테이너가 합쳐진 형태로 웹서버 단독으로 처리할 수 없는 DB 조회 또는 다양한 로직 처리가 필요한 동적 콘텐츠를 제공하는 웹서버를 말합니다. 웹 서버의 기능들을 구조적으로 분리해 처리하고자 하는 목적에 의해 탄생했으며 트랜잭션, 보안, 쓰레드 처리등 기능 분산환경에 사용되며 현재 WAS가 가진 웹서버도 정적 콘텐츠를 처리하는데 있어 성능상 큰 차이는 없습니다. (Tomcat, JBoss)

WAS가 필요한 이유

웹페이지는 동적, 정적 콘텐츠를 다루고 있습니다. 동적 콘텐츠는 사용자의 요청에 맞게 제공해야 합니다. 데이터를 DB에 가져와 비지니스 로직에 맞게 요청마다 결과를 만들어 제공함으로 자원을 효율적으로 사용할 수 있습니다. WAS가 정적 콘텐츠를 처리하기도 하지만 기본적으로 동적 콘텐츠를 제공하기 위해 존재하는 서버이며 기능 분리를 한다면 더욱 효율적인 자원 관리와 유지보수가 가능하기 때문에 Web Server와 함께 사용하는 것이 좋습니다.

DNS

인터넷 표준 프로토콜은 TCP/IP입니다. 이 프로토콜을 사용하는 네트워크 안에서 host를 식별하기 위한 목적으로 IP주소를 사용합니다. 길게 숫자로 이루어진 IP 주소를 사람이 읽기 편한 주소 이름으로 변환한 것을 말합니다. 대표적으로 DNS 서비스는 aws의 route 53이 해당됩니다.

캐시 메모리

주 기억장치에 저장된 내용의 일부를 임시로 저장해두는 기억장치를 말합니다. CPU에서 이미 조회한 것을 다시 접근할 때 반복적인 행위에 대한 비용을 줄이기 위해 캐시에 저장해두고 해당 캐시에 접근하여 데이터를 활용하는 것을 말합니다.

OOP

인간 중심적 프로그래밍으로 현실 세계의 사물 또는 개체를 객체로 보고 그 중심으로 개발하고자 하는 프로그래밍을 말합니다. 애플리케이션에서 어떤 객체에 대한 필요한 특징을 구현하는 것을 추상화라 합니다.

OOP를 활용하면 자주 사용하는 로직을 라이브러리로 구현하여 이미 작성한 코드의 재사용성을 높일 수 있습니다. 각종 예외 상황을 고려하여 만든 라이브러리를 통해 생산성도 높일 수 있습니다. 또한 데이터 모델링시 객체와 매핑이 수월하여 요구사항을 명확히 파악할 수 있는 장점도 있습니다.

TDD

테스트 주도 개발은 소프트웨어를 개발하는 여러 방법론중 하나입니다. 에러가 없이 정상적으로 동작하는지 확인하기 위해 모든 코드는 개발자가 작성 후 테스트를 거치는 작업이 이뤄집니다. TDD는 기능구현과 별개로 해당 기능이 제대로 동작하는지 검증하기 위한 테스트코드를 추가적으로 작성합니다. 이를 통해 테스트가 실패한다면 통과하기 위한 최소한의 코드를 작성하여 개선하구 최종적으로 테스트에 통과하면 코드를 리팩토링하는 과정을 진행합니다.

TDD를 해야하는 이유

• 작성한 코드의 불안정성을 개선하여 생산성 증대
  • 기능 단위로 테스트하기 때문에 코드가 완성된 후 개발자의 손을 떠나기 전에 피드백을 받는게 수월
• 개발자의 오버 엔지니어링을 방지
  • 테스트 통과를 위한 최소한의 코드만 작성하여 개선하기 때문에 계획하지 않은 코드를 추가적으로 작성하게 되는 것을 방지

TDD의 양면성

TDD를 도입하게 된다면 초기 비용은 꽤 리스크가 큽니다.

하지만 도입 후 TDD를 사용하지 않은 경우에 비해 비용이 커지지 않고 일정하게 유지됩니다.

단기적으로는 선택적일 수 있지만 장기적으로는 TDD를 사용하는 것이 효과적입니다.

테스트 기법

• 수동 테스트
  • QA와 비슷한 개념
  • 가장 온전한 코드 실행
  • 사용자 경험과 가장 비슷하게 검증
• 테스트 자동화
  • 수동 테스트의 한계를 보완하기 위해 사용
  • 기능 검증하는 코드 작성
  • 실행비용 낮고 신뢰도 높음
• 인수 테스트
  • 배치된 시스템 대상 검증
  • 신뢰도 높음, 높은 비용
• 단위 테스트
  • 인수 테스트의 단점을 보완하는 검증방식
  • 낮은 비용, 높은 피드백 품질
• 통합 테스트
• 시스템 테스트

TDD 프로세스

• RED : 테스트 실패
• GREEN : 테스트 성공
• REFACTOR : 리팩토링

TDD RED

실패하는 것을 확인해야 테스트 검증력, 신뢰도를 가질 수 있습니다.

테스트 코드엔 문제가 있어서 안됩니다.

• 구체적 하나의 요구사항을 검증하는 하나의 테스트를 추가
• 추가된 테스트가 실패하는지 확인

TDD GREED

추가된 테스트를 포함해 모든 테스트가 성공하게끔 운영 코드를 변경합니다.

• 모든 테스트 성공하도록 운영 코드 변경
• 테스트 성공 -> 요구사항 만족 의미
• 최소한의 코드 변경만 진행

TDD REFACTOR

• 코드베이스를 정리
• 인터페이스 뒤에 숨어있는 구현 설계 개선
• 가독성, 성능 고려해서 리팩토링

단위테스트 작성 -> 단위테스트 실행 -> 운영 코드 작성 -> 단위테스트 실행 -> 리팩토링 -> 단위 테스트 실행

DB Key

검색 또는 정렬할 때 Tuple을 구분할 수 있는 기준이 되는 속성

• PK : 기본키, not null, unique
• FK : 외래키, 다른 릴레이션의 PK(기본키)를 그대로 속성으로 참조하는 키

DB 무결성

테이블에 있는 모든 행들의 데이터 값들이 유일한 식별자를 가져야하며 외래키 값은 null 또는 참조하는 테이블의 pk 값을 가져야 하는 것을 말합니다.

DB 정규화

테이블간 중복을 최대한 줄여 데이터를 구조화하고, 불필요한 데이터를 제거해 논리적으로 데이터를 저장하는 것을 말합니다. 무결성(데이터의 값의 정확성)을 유지할 수 있으며 DB 저장 용량 또한 줄일 수 있습니다.

• 제 1 정규화

  • 테이블의 컬럼이 원자값 하나만 갖도록 테이블 분리 (하나의 컬럼에 하나의 데이터)
  • ex) 1개의 컬럼엔 하나의 데이터만 저장될 수 있도록

• 제 2 정규화

  • 제 1 정규화를 진행한 테이블에 대해 완전 함수 종속을 만족하도록 테이블 분리
  • ex) Post 테이블의 하나의 row 데이터에 id 값을 가진 static Tag 테이블 (ManyToMany)

• 제 3 정규화

  • 제 2 정규화를 진행한 테이블에 대해 이행적 종속을 없앨 수 있도록 테이블을 분리
  • ex) A -> B, B -> C 성립시 A -> C 가 성립되어야 함

트랜잭션

하나의 쿼리를 처리할 때 동일한 커넥션 객체를 공유해 에러가 발생한 경우 모든 과정을 되돌리기 위한 방법을 말합니다.

트랜잭션을 사용하는 이유

예를 들어 온라인 쇼핑몰에서 결제가 되고 배송처리가 되어야 할 시점에 시스템이 멈추면 해당 결제건은 배송처리가 되지 않는 상황이 벌어지게 됩니다. 이를 프로세스 관점에서 비추어 봤을때 하나의 기능적인 단위로 동작해야 하는 상황에 데이터의 유효성을 보장하기 위해 사용하게 됩니다.

트랜잭션 ACID

데이터 유효성을 보장하기 위한 특징들을 말합니다.

원자성(Atomicity)

• 여러 작업이 모두 다 반영되거나 모두 롤백이 되는 특징

일관성(Consistency)

• 미리 정의된 규정에서 수정이 가능한 특징 (데이터 타입)

고립성(Isolation)

• A, B 두개의 트랜젝션이 진행될 때 A의 작업이 B에게 보여지는 것을 의미

영구성(Durability)

• 한번 반영된 트랜젝션 내용은 영구적으로 적용되는 특징

DB Index

인덱스란 추가적 쓰기 작업이나 저장 공간을 활용해 DB 테이블의 검색 속도를 향상시키기 위한 자료구조를 말합니다. 예를 들어 전화번호부에서 원하는 업체의 전화번호를 찾고자 할때 전체 페이지를 찾아보는 것은 오랜 시간이 걸립니다. 그렇기 때문에 책의 앞뒤로 색인을 추가하게 되고 이는 DB의 Index와 같은 개념입니다. DB상에서도 모든 데이터를 검색한다면 시간이 오래 걸리기 때문에 해당 데이터의 위치를 포함한 자료구조를 생성해 조금 더 빠르게 조회할 수 있도록 하는 역할을 합니다.

Index 종류

• Hash : 컬럼 값으로 해시 값을 계산하여 인덱싱, 메모리 기반 DB에 자주 사용
• B+Tree : 원래의 값을 사용해 인덱싱

생성시 고려할 점

• 테이블 데이터의 수가 적으면 인덱스를 생성하지 않는게 더 빠름
• 자주 쓰는 컬럼을 앞으로 지정
• 해당 테이블의 데이터 전체의 15%정도만 조회할 때 생성
• DML(select, update, delete)시 인덱스에도 수정이 되므로 DML의 활용이 많은 테이블에선 생성하지 않는게 더 좋음
  • 추가, 수정,삭제의 경우 정렬된 상태에서 데이터의 변경으로 오버헤드가 발생
• 사용하지 않을때는 인덱스를 제거하기

사용하면 좋은 경우

• 규모가 작지 않은 테이블
• 조회가 주를 이루는 테이블
  • 테이블의 데이터의 변경이 자주 일어나지 않는 경우

장&단점

• 장점 : 검색(조회) 및 정렬의 속도 향상, 시스템 부하 감소
• 단점 : 인덱스를 관리하기 위한 리소스 발생(추가 작업, 저장공간), 데이터 변경이 자주 일어나는 경우 성능 저하, 인덱스 생성시 많은 시간 소요

Sql Injection

조작이나 변조된 SQL 쿼리가 DB에 전달되어 비정상적 명령을 수행하여 공격하는 방법

인증 우회

로그인시 비밀번호 입력 input 창에 다른 쿼리를 입력시켜 조작하는 방법을 말합니다.

예를 들어 1234qwer란 비밀번호가 있을때 1234qwer; delete * account from id='1' ; 를 입력한다면 뒤에 delete문이 실행될 수도 있으며, 기본 쿼리에 where절 뒤에 or로 '1' = '1' 을 추가하여 조건을 true로 만들어 조작할 수 있는 방법이 있습니다.

데이터 노출

시스템상 발생하는 에러 메세지를 활용해 공격하는 방법을 말합니다. get 방식 요청시 url 쿼리 스트링을 추가해 에러를 발생시키고 이때 에러를 통해 서비스의 DB구조를 유추해 해킹하는 방식을 말합니다.

SQL Injection 방어

• input 값 받을 때 validation check
• sql 서버 에러 발생시 에러 메세지 숨기기

CSRF

웹 애플리케이션 취약점중 하나로 사용자가 자신의 의지와 무관하게 공격자가 의도한 행위를 웹사이트에 요청하여 공격하는 방법을 말합니다. CSRF의 공격이 이뤄지려면 위조 공격을 하기 위한 서비스에 사용자 로그인이 되어 있어야 하며, 사용자가 해커의 피싱사이트에 접속을 해야합니다. 해커는 특정 사용자의 권한을 도용하여 중요 기능을 실행하는것이 가능해집니다.

XSS

웹페이지 내에 사용자 입력값에 대한 악의적 자바스크립트 코드를 심어 공격하는 방법을 말합니다.

피해의 종류로는 개인정보 쿠키, 세션 ID 획득, 관리자 권한 획득, 악성코드 다운등이 있습니다.

CORS (Cross Origin Resource Sharing)

교차 출처 리소스 공유라는 뜻으로 특정 헤더를 통해 특정 출처에서 실행되고 있는 웹 애플리케이션이 다른 출처의 리소스에 접근할 수 있는 권한을 검사하는 매커니즘입니다. 출처란 특정 페이지에 접근시 사용되는 url의 host, port, protocol을 말합니다. 이 3가지중 하나라도 다르면 CORS가 발생하게 됩니다. 이를 해결하기 위해선 서버로부터 응답받은 헤더에 Access-Controller-Allow-Origin을 설정하면 외부로부터의 리소스 접근이 가능하게 됩니다.

Bcrypt

단반향 암호화를 위해 만들어진 해시 함수입니다. 기존 해시함수의 문제는 빠르게 데이터 검색을 위한 자료구조로 설계가 되어 보안에 취약하거나, rainbow table attack 처럼 해시값을 미리 계산해 놓은 테이블을 가지고 해시함수 반환값을 역추적해 정보를 찾아 내는 방법등이 있습니다. 이를 보완하기위해 Bcrypt를 사용합니다.

Bcrypt의 4가지

• Algorithm: 식별자
• Cost Factor: 키스트레칭 횟수
• Salt: 128비트, 22자 base64로 인코딩
• Hash: salting과 키스트레칭 후 해시값

Salting

실제 정보 이외 추가로 무작위 데이터를 더해 해시 값을 계산하는 방법을 말합니다. 늘 salt로 해시값이 변경되기에 공격자는 해시값 데이터베이스를 생성할 수 없습니다.

키 스트레칭

기존 단반향 해시 알고리즘의 빠른 실행속도가 취약점을 보완한 방법입니다. 단방향 해시값을 계산 후 그 값을 다시 해시하는 방법으로 반복하는 방식을 말합니다.

대칭키

어떤 정보를 암호화 또는 복호화할 때 사용하는 키가 동일한 경우를 말합니다. 따라서 암호화된 정보를 전달하고 확인할 때 송수신쪽 모두 똑같은 키를 가지고 있어야 합니다. 이는 다시 말해 암호가 없다면 누구도 해당 정보를 알 수 없지만 중간에 잃어버리거나 탈취당하지 않도록 안전하게 전달하는 것이 중요합니다.

비대칭키

대칭키와 다르게 암호화, 복호화 할때 사용하는 키가 서로 다른 경우를 말합니다. 이때 사용되는 방식은 개인키로 암호화 하는 방식과 공개키로 암호화하는 방식으로 나뉘게 됩니다.

SSR

Server Side Rendering의 약자입니다. 서버에서 사용자에게 보여줄 페이지를 모두 구성하고 난 후 보여주는 방식을 말합니다. SSR을 사용하면 모든 데이터가 매핑되어진 완성된 페이지를 브라우저에 바로 보여줄 수 있습니다. 서버를 이용해 페이지 구성하기 때문에 CSR보다 속도는 늦어지지만 사용자에게 보여주는 콘텐츠 구성이 완료되는 시점은 빨라지는 장점이 있습니다. 또한 검색엔진최적화(SEO)를 쉽게 구현할 수 있는 장점도 있습니다.

CSR

Client Side Rendering의 약자입니다. 최초 1번 서버에서 전체 페이지를 구성하고 이후부터는 사용자의 요청시마다 리소스를 서버에 전달하여 응답받은 것을 클라이언트측에서 해석하고 렌더링 하는 방식을 말합니다. 대표적으로 CSR로는 React가 있으며 화면 인터렉션이 즉각적으로 렌더링하기 때문에 속도 체감에 있어서 훨씬 빠르게 느껴지는 장점이 있습니다. 단점으로는 SEO와 클라이언트측에 쿠키외엔 유저 정보를 저장할 공간이 없다는 점이 있습니다.