y-log

SQL Injection

웹 사이트의 보안상 허점을 이용해 특정 SQL 쿼리문을 전송하여
공격자가 원하는 데이터베이스의 중요한 정보를 가져오는 해킹 기법이다.

대부분 클라이언트가 입력한 데이터를 제대로 필터링하지 못하는 경우에 발생한다.

공격이 쉬운 난이도에 비해 피해가 상당하기 때문에
보안 위협 1순위로 불릴만큼 중요한 기법이다.

간략한 공격 시나리오

예를 들어 회원이 자신의 일련번호를 조회할 수 있는 상황이 있다고 가정하자.

기본적인 SQL 진행은 클라이언트가 일련번호 조회를 클릭하여 웹서버에 이름이 들어가고 DB에 입력한 값이 있는지 확인 후 존재한다면 번호 DB를 출력해준다.

예를 들어 번호 조회를 클릭하면 url이 http://numbersearch.com/mysearch?=ohyaelim 이 된다고 가정하자.

그럼 공격자의 조회는 http://numbersearch.com/mysearch?=blackhat  에서 탈취하고 싶은 정보의 유저인 ohyaelim으로 변경해줘야하는데, 그냥 변경하는 것으로는 현재 로그인 된 자신과는 다르기 때문에 웹서버에서 인정하지 않는다. 

그러므로 특정 쿼리문을 넣어준다. 'ohyaelim' or '1' = '1' 과 같이 넣어부념 1과 1은 같다라는 구문이 참이므로 결과를 출력해준다.

이러한 SQL Injection의 공격 범위는 매우 다양하다.

bypass
data access
content change
db delete

공격 종류 및 방법

Error based SQL Injection

- 논리적 에러를 이용한 SQL Injection

SQL 공격 기법은 여러가지가 있는데 논리적 에러를 이용한 SQL Injection은 가장 많이 쓰이고 대중적인 공격 기법이다.

앞서 살펴봤던 공격 시나리오가 여기에 해당된다. 

select * from client where name='ohyaelim' and password='1122'

가 올바른 로그인의 예라면 

select * from client where name='ohyaelim' and password=' or '1'='1

와 같이 작성해 or 앞의 값과 뒤에 값 중 하나라도 참이면 참이므로 이 구문 자체가 참으로 인식되어 로그인에 성공하게 된다.

UNION based SQL Injection = UNION

- 명령어를 이용한 SQL Injection

SQL UNION이란, 여러개의 SQL문을 합쳐 하나의 SQL문으로 만들어주는 방법이다. 
쿼리를 날리기에 앞서 사전 조건이 필요하다. Union 하는 두 테이블의 컬럼 수가 같아야 하고 데이터 형이 같아야 한다.

UNION과 UNION ALL로 나뉘는데 중복 값을 제외 하고 안하고의 차이다. 

UNION - 중복 값을 제외한다.

UNION ALL - 중복 값을 제외하지 않고 전체를 합친다.

입력값을 title 과 contents 컬럼의 데이터랑 비교한 뒤 비슷한 글자가 있는 게시글을 출력한다.

여기서 입력값으로 Union 키워드와 함께 컬럼 수를 맞춰서 SELECT 구문을 넣어주게 되면 두 쿼리문이 합쳐서서 하나의 테이블로 보여지게 된다.

현재 인젝션 한 구문은 사용자의 id와 passwd를 요청하는 쿼리문으로 인젝션이 성공하게 되면, 사용자의 개인정보가 게시글과 함께 화면에 보여지게 된다.

( * 물론 패스워드를 평문으로 데이터베이스에 저장하지는 않겠지만 인젝션이 가능하다는 점에서 이미 그 이상의 보안위험에 노출되어 있습니다. 이 공격도 역시 입력값에 대한 검증이 없기 때문에 발생하게 되었다. )

Blind SQL Injection 

- Boolean based Blind SQL Injection

Blind SQL Injection은 데이터베이스로부터 특정한 값이나 데이터를 전달받지 않고, 단순히 참과 거짓의 정보만 알 수 있을 때 사용한다. 로그인 폼에 SQL Injection이 가능하다고 가정 했을 때, 서버가 응답하는 로그인 성공과 로그인 실패 메시지를 이용하여, DB의 테이블 정보 등을 추출해 낼 수 있다.

위 사진과 같은 예시를 살펴보면 limit 키워드를 통해 하나의 테이블만 조회하고, SUBSTR 함수로 첫 글자만, 그리고 마지막으로 ASCII 를 통해서 ascii 값으로 변환해준다. 만약에 조회되는 테이블 명이 Users 라면 ‘U’ 자가 ascii 값으로 조회가 될 것이고, 뒤의 100 이라는 숫자 값과 비교를 하게 된다. 거짓이면 로그인 실패가 될 것이고, 참이 될 때까지 뒤의 100이라는 숫자를 변경해 가면서 비교를 하면 된다.  공격자는 이 프로세스를 자동화 스크립트를 통하여 단기간 내에 테이블 명을 알아 낼 수 있다.

한글자씩 끊어온 값을 아스키코드로 변환시키고 임의의 숫자와 비교하여 참과 거짓을 비교하는 과정을 거쳐가며 계속 질의를 보내어 일치하는 아스키코드를 찾아내는데 이러한 과정을 반복하여 결과들을 조합하여 원하는 정보를 얻어냄으로써 공격을 이루어지게 한다. 많은 비교 과정을 요하므로 악의적 목적을 가진 크래커들은 자동화된 툴을 사용하여 공격한다. 

Blind SQL Injection

- Time based SQL

Time Based SQL Injection 도 마찬가지로 서버로부터 특정한 응답 대신에 참 혹은 거짓의 응답을 통해서 데이터베이스의 정보를 유추하는 기법이다. 사용되는 함수는 MySQL 기준으로 SLEEP 과 BENCHMARK 이다.

위의 그림의 예시에서 로그인 폼에 주입이 되었으며 임의로 abc123 이라는 계정을 생성해 두었는데 악의적인 사용자가 abc123’ OR (LENGTH(DATABASE())=1 AND SLEEP(2)) – 이라는 구문을 주입한 상황이다. 

 주입된 구문에서, LENGTH(DATABASE()) = 1 가 참이면 SLEEP(2) 가 동작하고, 거짓이면 동작하지 않는다. 이를 통해서 숫자 1 부분을 조작하여 데이터베이스의 길이를 알아 낼 수 있다. 만약에 SLEEP 이라는 단어가 치환처리 되어있다면, 또 다른 방법으로 BENCHMARK 나 WAIT 함수를 사용 할 수 있다. 

BENCHMARK 는
BENCHMARK(1000000,AES_ENCRYPT('hello','goodbye'));
이런 식으로 사용하고 이 구문을 실행 하면 약 4.74초가 걸린다. 

Stored Procedure SQL Injection

- 저장된 프로시저에서의 SQL Injection

stored procedure는 일련의 쿼리들을 모아 하나의 함수처럼 사용하기 위한것이다.

공격에 사용되는 대표적인 저장 프로시저는 MS-SQL 에 있는 xp_cmdshell로 윈도우 명령어를 사용할 수 있게 된다. 단, 공격자가 시스템 권한을 획득 해야 하므로 공격난이도가 높으나 공격에 성공한다면, 서버에 직접적인 피해를 입힐 수 있는 공격이다.

Mass SQL Injection

- 다량의 SQL Injection 공격

 2008년에 처음 발견된 공격기법이다.

기존 SQL Injection 과 달리 한번의 공격으로 다량의 데이터베이스가 조작되어 큰 피해를 입히는 것을 의미한다. 보통 MS-SQL을 사용하는 ASP 기반 웹 애플리케이션에서 많이 사용되며, 쿼리문은 HEX 인코딩 방식으로 인코딩 하여 공격한다. 보통 데이터베이스 값을 변조하여 데이터베이스에 악성스크립트를 삽입하고, 사용자들이 변조된 사이트에 접속 시 좀비PC로 감염되게 하는데 이렇게 감염된 좀비 PC들은 DDoS 공격에 사용됩니다.

대응방안

• 입력 값에 대한 검증 
• Prepared Statement 구문 사용
• Error Message 노출 금지
• 웹 방화벽 사용

입력 값에 대한 검증

SQL Injection 에서 사용되는 기법과 키워드는 엄청나게 많습니다. 사용자의 입력 값에 대한 검증이 필요하다. 서버 단에서 화이트리스트 기반으로 검증해야 한다. 블랙리스트 기반으로 검증하게 되면 수많은 차단리스트를 등록해야 하고, 하나라도 빠지면 공격에 성공하게 되기 때문이다. 공백으로 치환하는 방법도 많이 쓰이는데, 이 방법도 취약한 방법이다. 예를 들어 공격자가 SESELECTLECT 라고 입력 시 중간의 SELECT가 공백으로 치환이 되면 SELECT 라는 키워드가 완성되게 된다. 공백 대신 공격 키워드와는 의미 없는 단어로 치환되어야 한다.

Prepared Statement 구문사용

 Prepared Statement 구문을 사용하게 되면, 사용자의 입력 값이 데이터베이스의 파라미터로 들어가기 전에DBMS가 미리 컴파일 하여 실행하지 않고 대기하는데 그 후 사용자의 입력 값을 문자열로 인식하게 하여 공격쿼리가 들어간다고 하더라도, 사용자의 입력은 이미 의미 없는 단순 문자열 이기 때문에 전체 쿼리문도 공격자의 의도대로 작동하지 않는다.

Error Message 노출 금지

공격자가 SQL Injection을 수행하기 위해서는 데이터베이스의 정보(테이블명, 컬럼명 등)가 필요하다. 데이터베이스 에러 발생 시 따로 처리를 해주지 않았다면, 에러가 발생한 쿼리문과 함께 에러에 관한 내용을 반환헤 주는데 여기서 테이블명 및 컬럼명 그리고 쿼리문이 노출이 될 수 있기 때문에, 데이터 베이스에 대한 오류발생 시 사용자에게 보여줄 수 있는 페이지를 제작 혹은 메시지박스를 띄우도록 하여야 한다.

웹 방화벽 사용

웹 공격 방어에 특화되어있는 웹 방화벽을 사용하는 것도 하나의 방법. 웹 방화벽은 소프트웨어 형, 하드웨어 형, 프록시 형 이렇게 세가지 종류로 나눌 수 있는데 소프트웨어 형은 서버 내에 직접 설치하는 방법이고, 하드웨어 형은 네트워크 상에서 서버 앞 단에 직접 하드웨어 장비로 구성하는 것이며 마지막으로 프록시 형은 DNS 서버 주소를 웹 방화벽으로 바꾸고 서버로 가는 트래픽이 웹 방화벽을 먼저 거치도록 하는 방법이다.

참고

link1 link2

NoSQL이란?

일명 "SQL만을 사용하지 않는 데이터베이스"
표 형식이 아니며, 관계형 테이블과는 다른 방식으로 데이터를 저장

NoSQL은 Not Only SQL의 약자로 기존 RDBMs 형태의 관계형 데이터베이스가 아닌 다른 형태의 데이터 저장 기술을 의미하며, 관계형 데이터 베이스의 한계를 극복하기 위한 데이터 저장소의 새로운 형태로, 수평적 확장성을 갖고 있다. 문서, 그래프, 키 값, 인 메모리, 검색을 포함해 다양한 데이터 모델을 사용한다. RDBMS가 클라이언트/서버 환경에 맞는 데이터 저장기술이라면, NoSQL은 클라우드 환경에 맞는 저장 기술이다.

NoSQL 데이터베이스를 사용해야하는 이유

NoSQL 데이터베이스는 탁월한 사용자 경험을 제공하기 위하여 유연성과 확장성을 비롯해 고성능의 매우 기능적인 데이터베이스를 필요로 하는 모바일, 웹이나 게이밍과 같은 다양한 현대적인 애플리케이션에 적합하다.

• 유연성: NoSQL 데이터베이스는 일반적으로 유연한 스키마를 제공하여, 보다 빠르고 반복적인 개발을 가능하게 해준다. 이 같은 유연한 데이터 모델은 NoSQL 데이터베이스를 반정형 및 데이터에 이상적으로 만들어준다.
• 확장성: NoSQL 데이터베이스는 일반적으로 고가의 강력한 서버를 추가하는 대신 분산형 하드웨어 클러스터를 이용해 확장하도록 설계되었다. 일부 클라우드 제공자들은 완전 관리형 서비스로서 이런 운영 작업을 보이지 않게 처리한다.
• 고성능: NoSQL 데이터베이스는 특정 데이터 모델(문서, 키 값, 그래프 등) 및 엑세스 패턴에 대해 최적화되어 관계형 데이터베이스를 통해 유사한 기능을 충족하려 할 때보다 뛰어난 성능을 얻게 해준다.
• 고기능성: NoSQL 데이터베이스는 각 데이터 모델에 맞추어 특별히 구축된 뛰어난 기능의 API와 데이터 유형을 제공한다.

SQL 장점
명확하게 정의된 스키마, 데이터 무결성 보장관계는 각 데이터를 중복없이 한번만 저장
SQL 단점
덜 유연함. 데이터 스키마를 사전에 계획하고 알려야 함. (나중에 수정하기 힘듬)관계를 맺고 있어서 조인문이 많은 복잡한 쿼리가 만들어질 수 있음대체로 수직적 확장만 가능함


NoSQL 장점
스키마가 없어서 유연함. 언제든지 저장된 데이터를 조정하고 새로운 필드 추가 가능데이터는 애플리케이션이 필요로 하는 형식으로 저장됨. 데이터 읽어오는 속도 빨라짐수직 및 수평 확장이 가능해서 애플리케이션이 발생시키는 모든 읽기/쓰기 요청 처리 가능
NoSQL 단점
유연성으로 인해 데이터 구조 결정을 미루게 될 수 있음데이터 중복을 계속 업데이트 해야 함데이터가 여러 컬렉션에 중복되어 있기 때문에 수정 시 모든 컬렉션에서 수행해야 함 (SQL에서는 중복 데이터가 없으므로 한번만 수행이 가능)

NoSQL의 특징

1. NoSQL은 RDBMS와는 달리 데이터 간의 관계를 정의하지 않는다.
   • 가장 큰 특징 중 하나는 관계형 데이터 베이스인 RDBMS가 데이터의 관계를 Foreign Key 등으로 정의하고 이를 이용해 Join 등의 관계형 연산을 한다고 하면, NoSQL은 데이터 간의 관계를 정의하지 않는다. 데이터 테이블은 그냥 하나의 테이블이며 각 테이블 간의 관계를 정의하지 않고 일반적으로 테이블 간의 Join도 불가능하다.
2. RDBMS에 비해 훨씬 더 대용량의 데이터를 저장할 수 있다.
   • RDBMS의 복잡도와 용량의 한계를 극복하기 위한 목적으로 등장한 만큼 페타바이트급의 대용량 데이터를 저장할 수 있다.
3. 분산형 구조이다.
   • NoSQL은 기존 RDBMS와는 다르게 하나의 고성능 머신에 데이터를 저장하는 것이 아니라 일반적인 서버 수십 대를 연결해 데이터를 저장 및 처리하는 구조를 갖는다. 즉 분산형 구조를 통해 데이터를 여러 대의 서버에 분산해 저장하고 분산 시에 데이터를 상호 복제해 특정 서버에 장애가 발생했을 때에도 데이터 유실이나 서비스 중지가 없는 구조의 형태를 가진다.
4. 고정되지 않은 테이블 스키마를 갖는다.
   • RDBMS와는 다르게 테이블의 스키마가 유동적이다. 데이터를 저장하는 컬럼은 각기 다른 이름과 다른 데이터 타입을 갖는 것이 허용된다.
   • 스키마란? 데이터베이스의 구조와 제약 조건에 관한 전반적인 명세를 기술한 메타데이터의 집합이다.

CAP 이론

1. 일관성(Consistency)

일관성은 동시성 또는 동일성이라고도 하며 다중 클라이언트에서 같은 시간에 조회하는 데이터는 항상 동일한 데이터임을 보증하는 것을 의미한다. 이것은 관계형 데이터베이스가 지원하는 가장 기본적인 기능이지만 일관성을 지원하지 않는 NoSQL 을 사용한다면 데이터의 일관성이 느슨하게 처리되어 동일한 데이터가 나타나지 않을 수 있다. 느슨하게 처리된다는 것은 데이터의 변경을 시간의 흐름에 따라 여러 노드에 전파하는 것을 말한다. 이러한 방법을 최종적으로 일관성이 유지된다고 하여 최종 일관성 또는 궁극적 일관성을 지원한다고 한다.

각 NoSQL 들은 분산 노드 간의 데이터 동기화를 위해서 두 가지 방법을 사용한다. 첫번째로 데이터의 저장 결과를 클라이언트로 응답하기 전에 모든 노드에 데이터를 저장하는 동기식 방법이 있다. 그만큼 느린 응답시간을 보이지만 데이터의 정합성을 보장한다. 두번째로 메모리나 임시 파일에 기록하고 클라이언트에 먼저 응답한 다음, 특정 이벤트 또는 프로세스를 사용하여 노드로 데이터를 동기화하는 비동기식 방법이 있다. 빠른 응답시간을 보인다는 장점이 있지만, 쓰기 노드에 장애가 발생하였을 경우 데이터가 손실될 수 있다.

2. 가용성(Availability)

가용성이란 모든 클라이언트의 읽기와 쓰기 요청에 대하여 항상 응답이 가능해야 함을 보증하는 것이며 내고장성이라고도 한다. 내고장성을 가진 NoSQL 은 클러스터 내에서 몇 개의 노드가 망가지더라도 정상적인 서비스가 가능하다.

몇몇 NoSQL 은 가용성을 보장하기 위해 데이터 복제(Replication)을 사용한다. 동일한 데이터를 다중 노드에 중복 저장하여 그 중 몇 대의 노드가 고장나도 데이터가 유실되지 않도록 하는 방법이다. 데이터 중복 저장 방법에는 동일한 데이터를 가진 저장소를 하나 더 생성하는 Master-Slave 복제 방법과 데이터 단위로 중복 저장하는 Peer-to-Peer 복제 방법이 있다.

3. 네트워크 분할 허용성(Partition tolerance)

분할 허용성이란 지역적으로 분할된 네트워크 환경에서 동작하는 시스템에서 두 지역 간의 네트워크가 단절되거나 네트워크 데이터의 유실이 일어나더라도 각 지역 내의 시스템은 정상적으로 동작해야 함을 의미한다.

NoSQL의 종류

• Key-Value DB
  • Key와 Value의 쌍으로 데이터가 저장되는 유형으로써 Amazon의 Dynamo Paper에서 유래되었다. Riak, Vodemort, Tokyo 등의 제품이 알려져 있다.

가장 기본적인 형태의 NoSQL 이며 키 하나로 데이터 하나를 저장하고 조회할 수 있는 단일 키-값 구조를 갖는다. 단순한 저장구조로 인하여 복잡한 조회 연산을 지원하지 않는다. 또한 고속 읽기와 쓰기에 최적화된 경우가 많다. 사용자의 프로필 정보, 웹 서버 클러스터를 위한 세션 정보, 장바구니 정보, URL 단축 정보 저장 등에 사용한다. 하나의 서비스 요청에 다수의 데이터 조회 및 수정 연산이 발생하면 트랜잭션 처리가 불가능하여 데이터 정합성을 보장할 수 없다. 
ex) Redis

• Wide Column DB
  • Big Table DB라고도 하며, Google의 BigTable Paper에서 유래되었다. Column Family 데이터 모델을 사용하고 있고, HBase, Cassandra, Hypertable이 이에 해당된다.

하나의 키에 여러 개의 컬럼 이름과 컬럼 값의 쌍으로 이루어진 데이터를 저장하고 조회한다. 모든 컬럼은 항상 타임 스탬프 값과 함께 저장된다.
구글의 빅테이블이 대표적인 예로 차후 컬럼형 NoSQL 은 빅테이블의 영향을 받았다. 이러한 이유로 Row key, Column Key, Column Family 같은 빅테이블 개념이 공통적으로 사용된다. 저장의 기본 단위는 컬럼으로 컬럼은 컬럼 이름과 컬럼 값, 타임스탬프로 구성된다. 이러한 컬럼들의 집합이 로우(Row)이며, 로우키(Row key)는 각 로우를 유일하게 식별하는 값이다. 이러한 로우들의 집합은 키 스페이스(Key Space)가 된다.
대부분의 컬럼 모델 NoSQL 은 쓰기와 읽기 중에 쓰기에 더 특화되어 있다. 데이터를 먼저 커밋로그와 메모리에 저장한 후 응답하기 때문에 빠른 응답속도를 제공한다. 그렇기 때문에 읽기 연산 대비 쓰기 연산이 많은 서비스나 빠른 시간 안에 대량의 데이터를 입력하고 조회하는 서비스를 구현할 때 가장 좋은 성능을 보인다. 채팅 내용 저장, 실시간 분석을 위한 데이터 저장소 등의 서비스 구현에 적합하다.

• KDoument DB
  • Lotus Notes에서 유래되었으며, JSON, XML과 같은 Collection 데이터 모델 구조를 채택하고 있다. Mongo DB, Cough DB가 이 종류에 해당된다.

키-값 모델을 개념적으로 확장한 구조로 하나의 키에 하나의 구조화된 문서를 저장하고 조회한다. 논리적인 데이터 저장과 조회 방법이 관계형 데이터베이스와 유사하다. 키는 문서에 대한 ID 로 표현된다. 또한 저장된 문서를 컬렉션으로 관리하며 문서 저장과 동시에 문서 ID 에 대한 인덱스를 생성한다. 문서 ID 에 대한 인덱스를 사용하여 O(1) 시간 안에 문서를 조회할 수 있다.
대부분의 문서 모델 NoSQL 은 B 트리 인덱스를 사용하여 2 차 인덱스를 생성한다. B 트리는 크기가 커지면 커질수록 새로운 데이터를 입력하거나 삭제할 때 성능이 떨어지게 된다. 그렇기 때문에 읽기와 쓰기의 비율이 7:3 정도일 때 가장 좋은 성능을 보인다. 중앙 집중식 로그 저장, 타임라인 저장, 통계 정보 저장 등에 사용된다. ex) MongoDB

• Graph DB
  • Euler & Graph Theory에서 유래한 DB이며, Nodes, Relationship, Key-Value 데이터 모델을 채용하고 있다. Neo4J 등의 제품이 있다.

References.

link1 link2

트랜잭션이란 

트랜잭션은 여러 개의 수행이 일련의 처리 단위로 묶이는 것을 말한다.

위 그림은 왼쪽 계좌의 돈을 오른쪽 계좌로 입금하는 과정이다.
첫번 째처럼 왼쪽 계좌에서 출금이 성공되면 오른쪽 계좌로 입금된다.
ATM의 문제로 왼쪽에서 출금이 되고 몇 분 후, 출금이 취소되었다고 하면 두번째 그림처럼 오른쪽 계좌에도 입금이 되지 않아야한다.

만약 출금은 취소 되었는데 입금이 돼버리면 큰 기능상의 문제인 것이다.
이렇게 일련의 처리가 All or Nothing으로 이루어지는 것이 트랜잭션이다.

• 데이터베이스의 상태를 변화시키기 위해 수행하는 작업 단위
• 상태를 변화 시킨다 =  SQL 질의어를 통해 DB에 접근한다 

  • SELECT INSERT DELETE UPDATE

• 작업 단위 ---> 많은 SQL 명령문들을 사람이 정하는 기준에 따라 정하는 것
  
  •  게시판에서 사용자가 글을 작성하고 올리기 버튼을 누른 후 게시판에 다시 돌아오면 게시판에 내가 쓴 글이 업데이트된 상태를 볼 수 있다.
    • 이때 DB 작업
      • 올리기 버튼을 누른다. : INSERT문을 사용해 사용자가 입력한 게시글 데이터를 옮김.
      • 게시판 새로 구성 : SELECT문을 사용해 최신 정보를 유지.
    • 현재 작업 단위  INSERT 문 + SELECT 문 -----------> 이를 통틀어 하나의 tranaction이라 한다!

즉. 하나의 트랜잭션 설계를 잘 만드는 것이 데이터를 다룰 때 많은 이점을 준다.

작업의 완전성 을 보장해주는 것이다. 즉, 논리적인 작업 셋을 모두 완벽하게 처리하거나 또는 처리하지 못할 경우에는 원 상태로 복구해서 작업의 일부만 적용되는 현상이 발생하지 않게 만들어주는 기능이다. 사용자의 입장에서는 작업의 논리적 단위로 이해를 할 수 있고 시스템의 입장에서는 데이터들을 접근 또는 변경하는 프로그램의 단위가 된다.

트랜잭션의 Commit, Rollback 연산

Commit

 이란 하나의 트랜잭션이 성공적으로 끝났고, 데이터베이스가 일관성있는 상태에 있을 때, 하나의 트랜잭션이 끝났다라는 것을 알려주기위해 사용하는 연산이다.

이 연산을 사용하면 수행했던 트랜잭션이 로그에 저장되며, 후에 Rollback 연산을 수행했었던 트랜잭션단위로 하는것을 도와준다.

Rollback

이란 하나의 트랜잭션 처리가 비정상적으로 종료되어 트랜잭션의 원자성이 깨진경우, 트랜잭션을 처음부터 다시 시작하거나, 트랜잭션의 부분적으로만 연산된 결과를 다시 취소시킨다.

후에 사용자가 트랜잭션 처리된 단위대로 Rollback을 진행할 수도 있다.

트랜잭션 특징 ACID

ACID 4가지 특성을 만족해야한다.

1. 원자성(Atomicity)

만약 트랜잭션 중간에 어떠한 문제가 발생한다면 트랜잭션에 해당하는 어떠한 작업 내용도 수행되어서는 안되며 아무런 문제가 발생되지 않았을 경우에만 모든 작업이 수행되어야 한다.

2. 일관성(Consistency)

트랜잭션이 완료된 다음의 상태에서도 트랜잭션이 일어나기 전의 상황과 동일하게 데이터의 일관성을 보장해야 한다.

3. 고립성(Isolation)

각각의 트랜잭션은 서로 간섭없이 독립적으로 수행되어야 한다.

4. 지속성(Durability)

트랜잭션이 정상적으로 종료된 다음에는 영구적으로 데이터베이스에 작업의 결과가 저장되어야 한다.

트랜잭션의 상태

Active

트랜잭션의 활동 상태. 트랜잭션이 실행중이며 동작중인 상태를 말한다.

Failed

트랜잭션 실패 상태. 트랜잭션이 더이상 정상적으로 진행 할 수 없는 상태를 말한다.

Partially Committed

트랜잭션의 Commit 명령이 도착한 상태. 트랜잭션의 commit이전 sql문이 수행되고 commit만 남은 상태를 말한다.

Committed

트랜잭션 완료 상태. 트랜잭션이 정상적으로 완료된 상태를 말한다.

Aborted

트랜잭션이 취소 상태. 트랜잭션이 취소되고 트랜잭션 실행 이전 데이터로 돌아간 상태를 말한다.

Partially Committed 와 Committed 의 차이점

Commit 요청이 들어오면 상태는 Partial Commited 상태가 된다. 이후 Commit을 문제없이 수행할 수 있으면Committed 상태로 전이되고, 만약 오류가 발생하면 Failed 상태가 된다.

즉, Partial Commited는 Commit 요청이 들어왔을때를 말하며, Commited는 Commit을 정상적으로 완료한 상태를 말한다.

잠금

■ 잠금(Locking)이란 ?

- 여러 사용자가 동일한 시간에 동일한 데이터를 동시에 액세스할 수 있게 해준다.

- 잠금은 트랜잭션을 순차적으로 처리되도록 함으로써 손실된 업데이트를 방지하는데 중요한 역할을 하며 자동으로 발생한다.

- 잠금을 통해 데이터에 대한 일관성 유지와 동시 사용이 가능해진다.

 ■ 블로킹(Blocking)이란 ?

- 어떤 프로세스가 자원을 엑세스하려고 할 때 이미 다른 프로세스가 그 자원을 잠그고 있어서 그 잠금이 풀릴 때까지 기다려야 하는 상황을 말한다. 이러한 차단이 오랫동안 유지될 경우 문제가 된다.

■ 잠금 관리

- 교착상태(Dead Locks) :

  * 트랜잭션 A는 트랜잭션 B가 원하는 데이터를 잠그고 있으면서 트랜잭션 B가 잠그고 있는 데이터를 원한다.

  * 트랜잭션 B는 트랜잭션 A가 원하는 데이터를 잠그고 있으면서 트랜잭션 A가 잠그고 있는 데이터를 원한다.

- MSSQL 해결방법 : 한쪽 트랜잭션 처리를 강제로 종료(비용이 적은 트랜잭션의 처리를 강제 종료한다.)

- SET DEADLOCK_PRIORITY 문을 사용해 교착 상태 발생 시 트랜잭션의 중요도를 지정할 수 있다.

- 우리 회사의 경우 sp_mon_blocking 프로시저를 이용해 블로킹 상태인 spid를 찾아낸다. 블로킹하고 있는 spid 세션을 죽이기 위해 ' kill [spid] ' 명령어를 사용한다.

트랜잭션을 사용할 때 주의할 점

트랜잭션은 꼭 필요한 최소의 코드에만 적용하는 것이 좋다. 즉 트랜잭션의 범위를 최소화하라는 의미다.

일반적으로 데이터베이스 커넥션은 개수가 제한적이다.

그런데 각 단위 프로그램이 커넥션을 소유하는 시간이 길어진다면 사용 가능한 여유 커넥션의 개수는 줄어들게 된다.

그러다 어느 순간에는 각 단위 프로그램에서 커넥션을 가져가기 위해 기다려야 하는 상황이 발생할 수도 있는 것이다.

교착상태

교착상태란 무엇인가
복수의 트랜잭션을 사용하다보면 교착상태가 일어날수 있다. 교착상태란 두 개 이상의 트랜잭션이 특정 자원(테이블 또는 행)의 잠금(Lock)을 획득한 채 다른 트랜잭션이 소유하고 있는 잠금을 요구하면 아무리 기다려도 상황이 바뀌지 않는 상태가 되는데, 이를 교착상태라고 한다.

교착상태의 빈도를 낮추는 방법

• 트랜잭션을 자주 커밋한다.
• 정해진 순서로 테이블에 접근한다. 위에서 트랜잭션 1 이 테이블 B -> A 의 순으로 접근했고, 트랜잭션 2 는 테이블 A -> B의 순으로 접근했다. 트랜잭션들이 동일한 테이블 순으로 접근하게 한다.
• 읽기 잠금 획득 (SELECT ~ FOR UPDATE)의 사용을 피한다.
• 한 테이블의 복수 행을 복수의 연결에서 순서 없이 갱신하면 교착상태가 발생하기 쉽다, 이 경우에는 테이블 단위의 잠금을 획득해 갱신을 직렬화 하면 동시성을 떨어지지만 교착상태를 회피할 수 있다.

Reference.

link1 link2 link3

정규화의 탄생 배경

한 relation에서 여러 entity의 attribute들을 혼합하게 되면 정보가 중복 저장되며 저장공간을 낭비하게 된다.

또한 이런 중복된 정보로 인해 갱신 이상이 발생하게 된다.

동일한 정보를 한 relation에는 변경하고 나머지 relation에서는 변경하지 않은 경우, 어느 것이 정확한지 알 수 없게 되는 것이다. 

이러한 문제를 해결하기 위해 정규화 과정을 거치게 된다.

갱신 이상이란...?

1. 삽입 이상 Insertion anomalies
원하지 않는 자료가 삽입된다든지, 삽입하는데 자료가 부족해 삽입이 되지 않아 발생하는 문제점

2. 삭제 이상 Deletion anomalies
하나의 자료만 삭제하고 싶지만, 그 자료가 포함된 튜플 전체가 삭제됨으로 원하지 않는 정보 손실이 발생하는 문제점

3. 수정 이상 Modification anomalies
정확하지 않거나 일부의 튜플만 갱신되어 정보가 모호해지거나 일관성이 없어져 정확한 정보 파악이 되지 않는 문제점

정규화란

관계형 데이터베이스에서 중복을 최소화하기 위해 데이터를 구조화하는 작업이다. 좀 더 구체적으로는 불만족스러운 나쁜 relation의 attribute들을 나누어서 좋은 작은 relation으로 분해하는 작업을 말한다.

나쁜 relation ?
엔티티를 구성하고 있는 애트리뷰트 간에 함수적 종속성(Functional Dependency)을 판단하는데, 각각의 정규형마다 어떠한 함수적 종속성을 만족하는지에 따라 정규형이 정의되고, 그 정규형을 만족하지 못하는 정규형을 나쁜 릴레이션으로 파악한다.

함수적 종속성은..?
애트리뷰트 데이터들의 의미와 애트리뷰트들 간의 상호 관계로부터 유도되는 제약조건의 일종이다. 

정규화 과정을 거치게 되면 정규형을 만족하게 된다. 정규형이란 특정 조건을 만족하는 릴레이션의 스키마의 형태를 말하며 제 1 정규형, 제 2 정규형, 제 3 정규형, … 등이 존재한다.

제 1 정규형

애트리뷰트의 도메인이 오직 원자값만을 포함하고, 튜플의 모든 애트리뷰트가 도메인에 속하는 하나의 값을 가져야 한다. 즉, 복합 애트리뷰트, 다중값 애트리뷰트, 중첩 릴레이션 등 비 원자적인 애트리뷰트들을 허용하지 않는 릴레이션 형태를 말한다.

제 2 정규형

모든 비주요 애트리뷰트들이 주요 애트리뷰트에 대해서 완전 함수적 종속이면 제 2 정규형을 만족한다고 볼 수 있다. 완전 함수적 종속이란 X -> Y 라고 가정했을 때, X 의 어떠한 애트리뷰트라도 제거하면 더 이상 함수적 종속성이 성립하지 않는 경우를 말한다. 즉, 키가 아닌 열들이 각각 후보키에 대해 결정되는 릴레이션 형태를 말한다.

제 3 정규형

어떠한 비주요 애트리뷰트도 기본키에 대해서 이행적으로 종속되지 않으면 제 3 정규형을 만족한다고 볼 수 있다. 이행 함수적 종속이란 X - >Y, Y -> Z의 경우에 의해서 추론될 수 있는 X -> Z의 종속관계를 말한다. 즉, 비주요 애트리뷰트가 비주요 애트리뷰트에 의해 종속되는 경우가 없는 릴레이션 형태를 말한다.

BCNF(Boyce-Codd) 정규형

여러 후보 키가 존재하는 릴레이션에 해당하는 정규화 내용이다. 복잡한 식별자 관계에 의해 발생하는 문제를 해결하기 위해 제 3 정규형을 보완하는데 의미가 있다. 비주요 애트리뷰트가 후보키의 일부를 결정하는 분해하는 과정을 말한다.

각 정규형은 그의 선행 정규형보다 더 엄격한 조건을 갖는다.

• 모든 제 2 정규형 릴레이션은 제 1 정규형을 갖는다.
• 모든 제 3 정규형 릴레이션은 제 2 정규형을 갖는다.
• 모든 BCNF 정규형 릴레이션은 제 3 정규형을 갖는다.

수많은 정규형이 있지만 관계 데이터베이스 설계의 목표는 각 릴레이션이 3NF(or BCNF)를 갖게 하는 것이다.

정규화의 장점

1. 데이터베이스 변경 시 이상 현상(Anomaly) 제거 위에서 언급했던 각종 이상 현상들이 발생하는 문제점을 해결할 수 있다.
2. 데이터베이스 구조 확장 시 재 디자인 최소화 정규화된 데이터베이스 구조에서는 새로운 데이터 형의 추가로 인한 확장 시, 그 구조를 변경하지 않아도 되거나 일부만 변경해도 된다. 이는 데이터베이스와 연동된 응용 프로그램에 최소한의 영향만을 미치게 되며 응용프로그램의 생명을 연장시킨다.
3. 사용자에게 데이터 모델을 더욱 의미있게 제공 정규화된 테이블들과 정규화된 테이블들간의 관계들은 현실 세계에서의 개념들과 그들간의 관계들을 반영한다.

정규화의 단점

릴레이션의 분해로 인해 릴레이션 간의 연산(JOIN 연산)이 많아진다.

이로 인해 질의에 대한 응답 시간이 느려질 수 있다.

조금 덧붙이자면, 정규화를 수행한다는 것은 데이터를 결정하는 결정자에 의해 함수적 종속을 가지고 있는 일반 속성을 의존자로 하여 입력/수정/삭제 이상을 제거하는 것이다. 데이터의 중복 속성을 제거하고 결정자에 의해 동일한 의미의 일반 속성이 하나의 테이블로 집약되므로 한 테이블의 데이터 용량이 최소화되는 효과가 있다.

따라서 정규화된 테이블은 데이터를 처리할 때 속도가 빨라질 수도 있고 느려질 수도 있는 특성이 있다.

이와 같은 단점이 있다면, 어떤 상황에서 정규화를 진행해야하는가?

반정규화(De-normalization, 비정규화)
반정규화는 정규화된 엔티티, 속성, 관계를 시스템의 성능 향상 및 개발과 운영의 단순화를 위해 중복 통합, 분리 등을 수행하는 데이터 모델링 기법 중 하나이다. 디스크 I/O 량이 많아서 조회 시 성능이 저하되거나, 테이블끼리의 경로가 너무 멀어 조인으로 인한 성능 저하가 예상되거나, 칼럼을 계산하여 조회할 때 성능이 저하될 것이 예상되는 경우 반정규화를 수행하게 된다. 일반적으로 조회에 대한 처리 성능이 중요하다고 판단될 때 부분적으로 반정규화를 고려하게 된다.

* 반정규화의 대상
1. 자주 사용되는 테이블에 액세스하는 프로세스의 수가 가장 많고, 항상 일정한 범위만을 조회하는 경우
2. 테이블에 대량 데이터가 있고 대량의 범위를 자주 처리하는 경우
3. 성능 상 이슈가 있을 경우
4. 테이블에 지나치게 조인을 많이 사용하게 되어 데이터를 조회하는 것이 기술적으로 어려울 경우


(주의, 반정규화를 과도하게 적용하다 보면 데이터의 무결성이 깨질 수 있다. 또한 입력, 수정, 삭제의 질의문에 대한 응답 시간이 늦어질 수 있다.)

Reference.

링크1

Index

칼럼의 값과 해당 레코드가 저장된 주소를 키와 값의 쌍으로 인덱스를 만들어둔다.

* DBMS의 인덱스는 항상 정렬된 상태를 유지하기 때문에

원하는 값을 탐색하는 것은 빠르지만 새로운 값을 추가하거나 삭제, 수정하는 경우에는 query문 실행 속도가 느려진다.

DBMS에서 인덱스는 데이터의 저장 성능을 희생하는 대신 데이터의 읽기 속도를 높이는 기능이다.

Index 자료구조 - DBMS의 인덱스 관리

B+- Tree Index 알고리즘
일반적으로 사용되는 알고리즘이다.
B +- 인덱스는 칼럼의 값을 변형하지 않고(사실은값의 앞부분만 잘라서 관리한다고 한다),
원래의 값을 이용해 인덱싱하는 알고리즘이다.

Hash 인덱스 알고리즘

칼럼의 값으로 해시 값을 계산해서 인덱싱하는 알고리즘으로 매우 빠른 검색을 지원한다.

하지만 값을 변형해서 인덱싱하므로, 특정 문자로 시작하는 값으로 검색을 하는 전방 일치와 같이 값의 일부만으로 검색하고자 할 때는 해시 인덱스를 사용할 수 없다.

주로 메모리 기반의 데이터베이스에서 많이 사용한다.

왜 index 를 생성하는데 b-tree 를 사용하는가?
데이터에 접근하는 시간복잡도가 O(1)인 hash table 이 더 효율적일 것 같은데?
SELECT 질의의 조건에는 부등호(<>) 연산도 포함이 된다.
hash table 을 사용하게 된다면 등호(=) 연산이 아닌 부등호 연산의 경우에 문제가 발생한다.
동등 연산(=)에 특화된 hashtable은 데이터베이스의 자료구조로 적합하지 않다.

Primary Index vs Secondary Index

클러스터(Cluster)란 여러 개를 하나로 묶는다는 의미로 주로 사용되는데, 클러스터드 인덱스도 크게 다르지 않다. 인덱스에서 클러스터드는 비슷한 것들을 묶어서 저장하는 형태로 구현되는데, 이는 주로 비슷한 값들을 동시에 조회하는 경우가 많다는 점에서 착안된 것이다. 여기서 비슷한 값들은 물리적으로 인접한 장소에 저장되어 있는 데이터들을 말한다.
클러스터드 인덱스는 테이블의 프라이머리 키에 대해서만 적용되는 내용이다. 즉 프라이머리 키 값이 비슷한 레코드끼리 묶어서 저장하는 것을 클러스터드 인덱스라고 표현한다. 클러스터드 인덱스에서는 프라이머리 키 값에 의해 레코드의 저장 위치가 결정되며 프라이머리 키 값이 변경되면 그 레코드의 물리적인 저장 위치 또한 변경되어야 한다. 그렇기 때문에 프라이머리 키를 신중하게 결정하고 클러스터드 인덱스를 사용해야 한다.
클러스터드 인덱스는 테이블 당 한 개만 생성할 수 있다. 프라이머리 키에 대해서만 적용되기 때문이다, 이에 반해 non 클러스터드 인덱스는 테이블 당 여러 개를 생성할 수 있다.


Composite Index

인덱스로 설정하는 필드의 속성이 중요하다. title, author 이 순서로 인덱스를 설정한다면 title 을 search 하는 경우, index 를 생성한 효과를 볼 수 있지만, author 만으로 search 하는 경우, index 를 생성한 것이 소용이 없어진다. 따라서 SELECT 질의를 어떻게 할 것인가가 인덱스를 어떻게 생성할 것인가에 대해 많은 영향을 끼치게 된다.

Index의 성능과 고려해야할 사항

SELECT 쿼리의 성능을 월등히 향상시키는 INDEX 항상 좋을까?  아니다.

- INDEX 를 생성하게 되면 INSERT, DELETE, UPDATE 쿼리문을 실행할 때 별도의 과정이 추가적으로 발생

INSERT 의 경우 INDEX 에 대한 데이터도 추가해야 하므로 그만큼 성능에 손실이 따른다.

DELETE 의 경우 INDEX 에 존재하는 값은 삭제하지 않고 사용 안한다는 표시로 남게 된다.

즉 row 의 수는 그대로인 것이다. 이 작업이 반복되면 어떻게 될까? 실제 데이터는 10 만건인데 데이터가 100 만건 있는 결과를 낳을 수도 있는 것이다. 이렇게 되면 인덱스는 더 이상 제 역할을 못하게 되는 것이다.

UPDATE 의 경우는 INSERT 의 경우, DELETE 의 경우의 문제점을 동시에 수반한다.

이전 데이터가 삭제되고 그 자리에 새 데이터가 들어오는 개념이기 때문이다.

즉 변경 전 데이터는 삭제되지 않고 insert 로 인한 split 도 발생하게 된다.

- 컬럼을 이루고 있는 데이터의 형식에 따라서 인덱스의 성능이 악영향을 미칠 수 있다.

즉, 데이터의 형식에 따라 인덱스를 만들면 효율적이고 만들면 비효율적인 데이터의 형식이 존재한다.

이름, 나이, 성별 세 가지의 필드를 갖고 있는 테이블을 생각해보자.

이름은 온갖 경우의 수가 존재할 것이며 나이는 INT 타입을 갖을 것이고, 성별은 남, 녀 두 가지 경우에 대해서만 데이터가 존재할 것임을 쉽게 예측할 수 있다.

이 경우 어떤 컬럼에 대해서 인덱스를 생성하는 것이 효율적일까? 이름에 대해서만 인덱스를 생성하면 효율적이다.

*왜 성별이나 나이는 인덱스를 생성하면 비효율적일까? 

10000 레코드에 해당하는 테이블에 대해서 2000 단위로 성별에 인덱스를 생성했다고 가정하자. 값의 range 가 적은 성별은 인덱스를 읽고 다시 한 번 디스크 I/O 가 발생하기 때문에 그 만큼 비효율적인 것이다.

< 참고 >

https://mungto.tistory.com/312

데이터베이스 시스템

파일처리시스템의 문제점을 해결하기 위해 등장
다양한 형태의 데이터를 모아놓은 데이터의 집합체
데이터 베이스 관리 시스템

데이터 베이스의 등장 배경
이전에는 구조화되지 않은 파일처리 시스템이었다. 
하지만 파일처리에는 다양한 문제점들이 있어 데이터베이스 시스템이 등장하게 된다. 

*파일 처리 시스템의 문제점

1) 중복 : 파일처리시스템은 각 파일마다 필요한 데이터를 각각 가지고 있어야 하므로 전체적인 시간과 노력, 경제비용에 있어서 효율이 없다.

2) 비일관성 : 데이터에 변경사항이 조금만 있어도 각 파일에서 해당되는 데이터를 모두 변경해야 하므로 수정에 문제가 있고, 한꺼번에 수정이 되지 않으면 데이터값이 서로 틀리게 되는 문제점이 있다.

3) 응용 프로그램 개발 문제 : 기존의 파일 시스템은 파일 용도에만 맞춰서 제작되기 때문에 다른 프로그램을 만들때는 다시 데이터베이스 작업을 해야 한다는 문제가 있다

4) 데이터 추가 및 검색의 문제 : 데이터가 여러 파일에 산재하고 또 그 파일마다 데이터베이스 양식이 다르기 때문에 일률적인 검색이나 단순 추가 작업이 어렵다.

데이터베이스의 특징

1. 데이터의 독립성

• 물리적 독립성 : 데이터베이스 크기를 늘리거나 성능 향상을 위해 데이터 파일을 늘리거나 새롭게 추가해도 관련 애플리케이션을 수정할 필요가 없다.
• 논리적 독립성 : 데이터베이스는 논리적인 구조로 다양한 애플리케이션의 논리적 요구를 만족시켜준다.

2. 데이터의 무결성 

• 데이터는 여러 경로를 통해서 들어오는데, 데이터에서 발생하는 경우의 수를 방지하는 기능으로 데이터의 유효성을 검사해서 무결성을 구현한다.

3. 데이터의 보안성

• 인가된 사용자들만 데이터베이스나 데이터베이스 내에 자원을 접근할 수 있도록 계정 관리 또는 접근 권한을 설정

4. 데이터의 일관성

• 연관된 정보를 논리적인 구조로 관리해서, 어떤 하나의 데이터만 변경했을 경우에 발생할 수 있는 불일치성을 배제할 수 있다.
• 또 작업 중에 일부 데이터만 변경되서 나머지 데이터와 일치하지 않는 경우를 방지한다.

5. 데이터의 중복 최소화

• 데이터베이스는 데이터를 통합해서 관리함으로써, 파일 시스템의 단점 중 하나인 자료의 중복과 데이터의 중복성 문제를 최소화할 수 있다.

데이터베이스의 장점

1. 데이터 공유

2. 데이터 중복의 최소화

3. 계속적 변화에 대한 적응

4. 보안성

데이터베이스의 성능

디스크 I/O를 어떻게 줄이냐에 따라 달려있다.

데이터를 읽는데 디스크 헤더의 위치 이동없이 얼마나 많은 데이터를 한번이 기록하느냐에 따라 결정된다.

따라서 순차적으로 I/O를 수행하는게 랜덤 I/O보다 빠르다.

쿼리 최적화, 빠른 쿼리를 위한 7가지 체크리스트

1. SELECT 시에는 꼭 필요한 칼럼만 불러와야 한다.

• 너무 많은 필드값을 불러올 수록 DB는 더 많은 로드를 부담하기 때문에

2. 조건 부여시, 가급적 기존 DB값에 별도의 연산을 걸지 않는 것이 좋다.

• 조건 검색이 필요할때 굳이 모든 필드 값을 탐색할 필요 없게 쿼리를 짜주자

3. LIKE 사용시 %(와일드카드문자열)를 string 앞부분에 배치하지 않는 것이 좋다.

• 위의 2번과 마찬가지로 full table scan을 막게 다른 형태의 조건절을 사용하는것이 효과적이다.

4. SELECT DISTINCT, UNION DISTINCT와 같이 중복 값을 제거하는 연산은 최대한 사용하지 않아야한다.

• 중복 값을 제거하는 연산은 시간이 많이걸리기 때문이다.
• 차라리 EXISTS를 사용하자.

5. 같은 내용의 조건이라면, GROUP BY 연산 시에는 가급적 HAVING보다는 WHERE 절을 사용하는 것이 좋다.

• WHERE 절이 HAVING절보다 먼저 실행되기 때문에 WHERE로 미리 데이터 크기를 줄여 놓는게 좋다.

6. 3개 이상의 테이블을 INNER JOIN 할 때는, 크기가 가장 큰 테이블을 FROM 절에 배치하고, INNER JOIN 절에는 남은 테이블을 작은 순서대로 배치하는 것이 좋다.

• INNER JOIN 과정에서 최소한의 Combination을 탐색하도록 FROM & INNER JOIN의 순서를 배열하면 좋다는 이야기인데, 항상 통용되지는 않다.

7. 자주 사용하는 데이터의 형식에 대해서는 미리 전처리된 테이블을 따로 보관, 관리하는 것도 좋다.

<참고>

https://velog.io/@redgem92/%EB%8D%B0%EC%9D%B4%ED%84%B0%EB%B2%A0%EC%9D%B4%EC%8A%A4-%EB%8D%B0%EC%9D%B4%ED%84%B0%EB%B2%A0%EC%9D%B4%EC%8A%A4%EB%A5%BC-%EC%82%AC%EC%9A%A9%ED%95%98%EB%8A%94-%EC%9D%B4%EC%9C%A0%EC%99%80-%ED%8A%B9%EC%A7%95 https://yang1650.tistory.com/28

https://medium.com/watcha/%EC%BF%BC%EB%A6%AC-%EC%B5%9C%EC%A0%81%ED%99%94-%EC%B2%AB%EA%B1%B8%EC%9D%8C-%EB%B3%B4%EB%8B%A4-%EB%B9%A0%EB%A5%B8-%EC%BF%BC%EB%A6%AC%EB%A5%BC-%EC%9C%84%ED%95%9C-7%EA%B0%80%EC%A7%80-%EC%B2%B4%ED%81%AC-%EB%A6%AC%EC%8A%A4%ED%8A%B8-bafec9d2c073