데굴데굴

Valkey 커스텀 명령어 응답 가공하기: echo2_ prefix 붙이기

데구르르.. — Sun, 24 May 2026 11:59:42 +0900

지난 과제에서는 Valkey에 ECHOPIXXLIX라는 커스텀 명령어를 추가했다.

동작은 기존 ECHO 명령어처럼.사용자가 abc를 입력하면 그대로 "abc"를 돌려주는 단순한 명령어였다.

이번 과제에서는 여기서 한 단계 더 나아가, 입력값 앞에 echo2_라는 prefix를 붙여 응답하도록 수정해보자.

겉으로 보면 단순히 문자열 앞에 echo2_만 붙이는 작업처럼 보인다.
하지만 Valkey 내부에서는 기존 입력값을 그대로 반환하는 것과, 새로운 문자열을 만들어 반환하는 것이 꽤 다르게 처리된다.

이번 글에서는 코드 흐름을 세세하게 따라가기보다는, 왜 새 문자열을 만들어야 했는지, Valkey는 문자열을 어떻게 다루는지, 응답을 만들 때 메모리 소유권은 어떻게 처리되는지를 중심으로 정리해보려고 한다.

1. 기존 방식: 입력값을 그대로 돌려주기

지난 과제에서 구현했던 echoPixxlixCommand는 이런 형태였다.

void echoPixxlixCommand(client *c) {
    addReplyBulk(c, c->argv[1]);
}

기존 구현에서는 c->argv[1]을 그대로 addReplyBulk()에 넘겼다.

사용자가 보낸 값 → 그대로 bulk string 응답

이 방식은 이미 존재하는 object를 그대로 응답할 때는 적합하다.
하지만 이번 과제에서는 "abc"를 그대로 돌려주면 안 된다. 기존 입력값 앞에 새로운 문자열을 붙인 새 응답 문자열이 필요하다.

2. 새 문자열 만들기

이번 과제의 전체 로직은 다음과 같다.

사용자 입력: abc
↓
c->argv[1]에서 실제 문자열 값 꺼내기
↓
빈 sds 문자열 만들기
↓
echo2_ + 입력값 붙이기
↓
새로 만든 문자열을 bulk string 응답으로 반환

void echoPixxlixCommand(client *c) {
    sds reply = sdsempty();

    reply = sdscatfmt(reply, "echo2_%S", objectGetVal(c->argv[1]));

    addReplyBulkSds(c, reply);
}

코드 줄 수만 보면 짧은 수정이다.
하지만 이 안에는 Valkey의 문자열 처리 방식과 응답 처리 방식이 함께 들어 있다.

2.1 c->argv[1]은 그냥 문자열이 아니다

처음에는 c->argv[1]을 그냥 char *처럼 생각하기 쉽다.

하지만 Valkey에서 command argument는 단순 C 문자열이 아니라 robj * 형태로 관리된다.

그래서 입력값 자체를 그대로 문자열처럼 이어 붙이는 것이 아니라, 먼저 object 안에 들어 있는 실제 문자열 값을 꺼내야 한다.

이 역할을 하는 함수가 objectGetVal()이다.

objectGetVal(c->argv[1])

즉, 이 부분은 이렇게 이해할 수 있다.

c->argv[1]이라는 Valkey object에서
실제 문자열 값을 꺼낸다

기존에는 object 자체를 그대로 addReplyBulk()에 넘겼지만, 이번에는 그 안의 실제 값을 꺼내서 새 문자열을 만드는 데 사용했다.

2.2 Valkey의 문자열 타입, sds

이번 과제에서 가장 중요하게 본 개념은 sds였다.

C에서는 보통 문자열을 char *로 다룬다.
하지만 일반 C 문자열은 길이를 알려면 strlen()처럼 문자열 끝까지 직접 훑어야 한다.

예를 들어 "hello"의 길이를 구하려면, 내부적으로는 \0을 만날 때까지 한 글자씩 확인한다.

h → e → l → l → o → \0

문자열이 짧을 때는 큰 문제가 없지만, Valkey처럼 문자열 데이터를 매우 자주 다루는 서버에서는 이 비용이 중요해질 수 있다.

그래서 Valkey는 문자열을 다룰 때 주로 sds라는 구조를 사용한다.

sds는 겉으로는 char *처럼 보이지만, 실제 메모리 구조는 조금 다르다.

[ len | alloc | flags ][ 실제 문자열 buf ][ \0 ]
                         ↑
                       sds 포인터

sds의 앞쪽에는 header가 있고, 그 안에는 문자열 길이, 할당된 크기, 타입 정보 등이 들어 있다.

재밌는 점은 sds 포인터가 header를 가리키는 것이 아니라, 실제 문자열이 시작되는 buf를 가리킨다는 것이다.

처음에는 조금 이상하게 느껴졌다.

header가 중요하면 포인터가 header를 가리켜야 하는 것 아닌가?

이렇게 하면 장점이 있다.

1. C 문자열처럼 사용하기 쉽다. 바로 문자열 시작 위치를 가리키기 때문이다.

2. 길이나 할당 크기 같은 정보가 필요하면 문자열 전체를 훑지 않고, 포인터 앞쪽으로 이동해서 header를 읽으면 된다.

즉, 사용하기에는 C 문자열처럼 편하게 쓰고, 내부적으로는 header를 통해 길이와 메모리 정보를 빠르게 확인할 수 있는 구조다.

이 부분이 처음에는 낯설었지만, Valkey가 왜 자체 문자열 구조를 사용하는지 이해하는 데 도움이 됐다.

2.3 빈 문자열을 만들고, 뒤에 붙이기

이번 과제에서는 먼저 빈 sds 문자열을 만들고, 이후 sdscatfmt()를 사용해 echo2_와 입력값을 이어 붙였다.

sds reply = sdsempty();

reply = sdscatfmt(reply, "echo2_%S", objectGetVal(c->argv[1]));

중요한 점은 sdscatfmt()의 반환값을 다시 reply에 저장한다는 것이다.

문자열을 뒤에 붙이다 보면 기존 공간이 부족할 수 있다.
그 경우 내부적으로 더 큰 공간을 새로 할당하거나 realloc이 일어날 수 있다.

그러면 기존 reply 포인터가 바뀔 수도 있다.

그냥 아래처럼 반환값을 받지 않는 방식은 위험할 수 있다.

sdscatfmt(reply, "echo2_%S", objectGetVal(c->argv[1]));

3. addReplyBulkSds() 로 응답하기

기존에는 이렇게 응답했다.

addReplyBulk(c, c->argv[1]);

기존 방식은 이미 존재하는 robj를 그대로 bulk string 응답으로 보낼 때 사용하기 좋다.

하지만 이번에는 새로 만든 sds 문자열이 있으니 addReplyBulkSds()를 사용했다.

sds reply = sdsempty();
reply = sdscatfmt(reply, "echo2_%S", objectGetVal(c->argv[1]));

addReplyBulkSds(c, reply);

조심해야 할 점은 addReplyBulkSds()의 메모리 소유권이다.

addReplyBulkSds()는 단순히 응답만 추가하는 함수가 아니라, 전달받은 sds의 메모리 소유권까지 가져간다.

따라서 reply를 다시 사용하거나 직접 해제하면 안 된다.

sdsfree(reply); // 하면 안 됨

왜냐하면 addReplyBulkSds() 내부에서 이미 해당 sds를 처리하고 해제하기 때문이다.

이걸 모르고 직접 sdsfree(reply)를 한 번 더 호출하면 double free 문제가 생길 수 있다.
또 호출 이후에 reply를 다시 사용하면 이미 해제된 메모리를 참조하는 use-after-free 문제가 생길 수 있다.

쉽게 말하면,

addReplyBulkSds()에 reply를 넘기는 순간
reply의 책임은 함수 쪽으로 넘어간다

테스트 결과

수정 후 valkey-cli에서 직접 확인했다.

127.0.0.1:6379> echoPixxlix abc
"echo2_abc"

127.0.0.1:6379> echoPixxlix hello
"echo2_hello"

인자 없이 실행했을 때는 command metadata의 arity 검증에 따라 에러가 발생한다.

127.0.0.1:6379> echoPixxlix
(error) ERR wrong number of arguments for 'echopixxlix' command

정리하며

처음에는 단순히 문자열 앞에 echo2_만 붙이면 되는 과제라고 생각했는데, Valkey 내부에서는 기존 object를 그대로 반환하는 것과, 새 문자열을 만들어 반환하는 것이 다르게 처리된다는 점을 알게 되었다.

Valkey의 문자열 처리 방식과 응답 생성 방식을 조금 더 구체적으로 이해할 수 있었다.

추가로 Valkey 네트워크 처리과정에 대해서도 배웠는데, 다음 포스팅에서 이어서 작성하겠다.(epoll과 멀티스레딩의 개념을 이해하고 있다고 생각했는데, 너무 어려워서 PPT 슬라이드를 이해하는데만 3일정도 걸렸다)

Redis/Valkey는 Command를 어떻게 실행할까? - Valkey 커스텀 명령어를 만들어보자

데구르르.. — Thu, 21 May 2026 04:36:06 +0900

들어가며

OSSCA Valkey 4주차에서는 Valkey에 직접 command를 추가해보는 실습을 진행했다.

처음에는 단순히 함수 하나를 추가하면 되는 과제처럼 보였다. 하지만 실제로 따라가 보니 Valkey 내부에서 command가 어떻게 정의되고, 서버 시작 시 어떻게 등록되며, client 요청이 어떤 흐름을 거쳐 실제 C 함수까지 도달하는지 이해할 수 있는 실습이었다.

이번 글에서는 수업에서 다룬 Valkey command 등록 및 실행 흐름과, 내가 ECHOPIXXLIX command를 추가하고 PR을 보낸 과정을 정리한다.

Valkey command는 어디에 정의될까?

Valkey에서 command를 추가하려면 단순히 C 함수 하나만 작성하면 되는 것이 아니다.

command의 이름, 설명, 인자 수, 실행할 함수, command 성격 등이 함께 정의되어야 한다. 이번 실습에서 수정한 주요 파일은 다음과 같다.

파일 역할

src/commands/echo-pixxlix.json	ECHOPIXXLIX command metadata 정의
src/commands.def	ECHOPIXXLIX command 항목 추가
src/server.h	echoPixxlixCommand 함수 선언
src/server.c	echoPixxlixCommand 함수 구현
tests/unit/other.tcl	ECHOPIXXLIX unit test 추가

Valkey command는 “어떤 이름의 command가 들어왔을 때 어떤 함수를 실행할 것인지”를 미리 등록해두고, client 요청이 들어오면 해당 command를 찾아 실행하는 구조로 동작한다.

Command 등록 흐름 4단계

수업에서 가장 먼저 본 부분은 command 등록 흐름이었다.

Valkey command는 요청이 들어올 때마다 새로 만들어지는 것이 아니라, 서버가 시작될 때 command table에 등록된다.

큰 흐름은 다음과 같다.

commands.def
↓
serverCommandTable[]
↓
populateCommandTable()
↓
server.commands

commands.def에는 command 이름, 설명, 실행 함수, 인자 수, flag, ACL category 같은 정보가 들어간다.

이후 서버가 시작되면 populateCommandTable()을 통해 command들이 command table에 등록된다. client가 command를 보내면 Valkey는 이 command table에서 해당 command를 찾는다.

이번에 추가한 ECHOPIXXLIX도 이 흐름에 포함되어야 한다. 즉, command metadata와 실행 함수가 제대로 연결되어 있어야 client가 ECHOPIXXLIX를 보냈을 때 정상적으로 실행된다.

Client 요청 이후 command 실행 흐름 7단계

클라이언트가 다음과 같이 command를 보냈다고 해보자.

ECHO abc

겉으로 보기에는 서버가 곧바로 echoCommand()를 호출하는 것처럼 보인다. 이 장면만 보면 “소켓에서 문자열을 읽고 바로 함수 하나를 실행하는 단순한 구조”라고 생각하기 쉽다.

하지만 실제 Valkey 내부에서는 command 함수가 호출되기 전에 여러 단계를 거친다. 네트워크에서 데이터를 읽고, 프로토콜을 parsing하고, command를 lookup하고, 인증과 ACL, 인자 수 검사 등을 통과한 뒤에야 실제 command 함수가 실행된다.

수업에서 정리한 Valkey command 실행 흐름은 다음과 같다.

client 요청
↓
readQueryFromClient()
↓
processInputBuffer()
↓
parseMultibulkBuffer() / parseInlineBuffer()
↓
lookupCommand()
↓
processCommand()
↓
call()
↓
c->cmd->proc(c)
↓
addReply()
↓
client 응답

이 흐름을 역할별로 나누면 다음 7단계로 정리할 수 있다.

단계 함수 설명

1. 연결 수락	acceptCommonHandler() → createClient()	client 객체를 생성하고 read 이벤트 핸들러를 등록한다.
2. 데이터 수신	readQueryFromClient() → readToQueryBuf()	소켓에서 데이터를 읽어 client query buffer에 저장한다.
3. 프로토콜 파싱	parseMultibulkBuffer() / parseInlineBuffer()	RESP 또는 inline command를 parsing하여 c->argc, c->argv[]를 채운다.
4. 명령어 lookup	lookupCommand() → hashtableFind()	등록된 server.commands hashtable에서 command를 찾고 c->cmd에 연결한다.
5. 실행 전 검증	processCommand()	인증, ACL, arity, cluster redirection, 서버 상태 등을 검사한다.
6. 명령어 실행	call() → c->cmd->proc(c)	실제 command 함수가 호출된다.
7. 응답 전송	addReply() → sendReplyToClient()	응답을 client buffer에 쌓고 소켓으로 전송한다.

이 중 가장 중요한 지점은 6단계다.

c->cmd->proc(c)

c->cmd에는 lookup된 command 정보가 들어 있고, proc에는 실제로 실행할 C 함수가 연결되어 있다.

즉, 커스텀 command를 추가한다는 것은 단순히 함수 하나를 작성하는 일이 아니다. 새 command 이름이 lookup될 수 있도록 등록하고, 그 command의 proc에 연결될 실제 함수를 작성하는 과정이다.

과제 목표

이번 과제는 Valkey에 새로운 command를 하나 추가하는 것이었다.

추가할 command는 기존 ECHO와 같은 방식으로 동작한다. 사용자가 전달한 문자열을 그대로 다시 반환하는 command를 구현하면 된다.

기존 ECHO command 분석

이번 과제는 기존 ECHO command를 참고하면 이해하기 쉽다.

ECHO command의 핵심 구현은 다음과 같은 구조다.

void echoCommand(client *c) {
    addReplyBulk(c, c->argv[1]);
}

client가 다음과 같이 입력했다고 해보자.

ECHO abc

Valkey 내부에서는 parsing 이후 argument가 다음과 같이 정리된다.

c->argv[0] = "ECHO"
c->argv[1] = "abc"
c->argc = 2

여기서 c->argv[0]은 command 이름이고, c->argv[1]은 사용자가 전달한 첫 번째 인자다.

따라서 echoCommand()에서 c->argv[1]을 응답으로 반환하면 사용자가 입력한 abc가 그대로 출력된다.

addReplyBulk(c, c->argv[1]);

이 부분을 통해 Valkey command 함수는 parsing된 argv 배열을 기반으로 동작한다는 것을 확인할 수 있었다.

ECHOPIXXLIX command 구현

이제 기존 ECHO command를 참고해 ECHOPIXXLIX command를 추가했다.

1. command metadata 추가

먼저 src/commands/echo-pixxlix.json 파일을 추가했다.

이 파일에는 ECHOPIXXLIX command의 기본 정보가 들어간다.

{
    "ECHOPIXXLIX": {
        "summary": "Returns the given string.",
        "complexity": "O(1)",
        "group": "connection",
        "since": "8.1.0",
        "arity": 2,
        "function": "echoPixxlixCommand",
        "command_flags": [
            "LOADING",
            "STALE",
            "FAST"
        ],
        "acl_categories": [
            "CONNECTION",
            "FAST"
        ],
        "reply_schema": {
            "description": "The given string",
            "type": "string"
        },
        "arguments": [
            {
                "name": "message",
                "type": "string"
            }
        ]
    }
}

여기서 중요한 필드는 다음과 같다.

필드 의미

summary	command 설명
complexity	시간복잡도
group	command 분류
arity	command 이름을 포함한 인자 수
function	실제 실행될 C 함수 이름
command_flags	command 실행 성격
acl_categories	ACL category
arguments	command가 받는 인자 정보

ECHOPIXXLIX abc는 내부적으로 command 이름과 message를 포함해 총 2개의 argument로 처리된다.

argv[0] = "ECHOPIXXLIX"
argv[1] = "abc"
argc = 2

따라서 arity는 2로 설정했다.

❓명령어 처리 속도는 왜 O(1)일까?

ECHOPIXXLIX command의 metadata에는 시간복잡도를 다음과 같이 작성했다.

"complexity": "O(1)"

처음에는 문자열을 응답으로 돌려주는 command인데 왜 O(1)인지 헷갈릴 수 있다. 입력 문자열의 길이가 길어지면 실제로 전송해야 하는 byte 수도 늘어나기 때문이다.

여기서 O(1)은 Valkey 내부 command 처리 로직 기준으로 이해하는 것이 좋다.

ECHOPIXXLIX는 key를 조회하지 않고, hash table이나 skip list 같은 자료구조를 탐색하지도 않는다. 단순히 parsing이 끝난 뒤 c->argv[1]에 들어 있는 값을 응답으로 추가한다.

void echoPixxlixCommand(client *c) {
    addReplyBulk(c, c->argv[1]);
}

즉, command 함수 입장에서 하는 일은 다음 한 가지다.

사용자가 전달한 첫 번째 인자 c->argv[1]을 응답으로 등록한다.

GET, HGET, ZRANGE처럼 특정 key나 자료구조 내부를 찾아가는 과정이 없기 때문에 command 자체의 논리적 처리 비용은 상수 시간으로 볼 수 있다.

다만 실제 네트워크 응답을 만들고 전송하는 비용은 문자열 길이에 영향을 받을 수 있다. 예를 들어 "abc"를 돌려주는 것과 매우 긴 문자열을 돌려주는 것은 전송해야 하는 byte 수가 다르다. 따라서 응답 크기에 따른 I/O 비용은 별도로 존재한다.

정리하면 다음과 같다.

command 로직 기준: O(1)
응답 데이터 전송 비용: 문자열 길이에 영향받을 수 있음

이번 command는 DB 조회나 자료구조 순회 없이 인자를 그대로 응답하는 echo 계열 command이므로 metadata의 complexity를 O(1)로 작성했다.

2. commands.def에 command 항목 추가

다음으로 src/commands.def에 ECHOPIXXLIX command 항목을 추가했다.

{MAKE_CMD("echopixxlix","Returns the given string.","O(1)","8.1.0",CMD_DOC_NONE,NULL,NULL,"connection",COMMAND_GROUP_CONNECTION,ECHOPIXXLIX_History,0,ECHOPIXXLIX_Tips,0,echoPixxlixCommand,2,CMD_LOADING|CMD_STALE|CMD_FAST,ACL_CATEGORY_CONNECTION|ACL_CATEGORY_FAST,NULL,ECHOPIXXLIX_Keyspecs,0,NULL,1),.args=ECHOPIXXLIX_Args},

3. server.h에 함수 선언 추가

commands.def에서 echoPixxlixCommand를 참조하므로, server.h에 함수 선언을 추가했다.

void echoPixxlixCommand(client *c);

이 선언을 통해 다른 파일에서도 echoPixxlixCommand 함수의 존재를 알 수 있다.

4. server.c에 함수 구현 추가

실제 동작은 server.c에 구현했다.

void echoPixxlixCommand(client *c) {
    addReplyBulk(c, c->argv[1]);
}

기존 echoCommand와 동일하게 사용자가 전달한 첫 번째 인자인 c->argv[1]을 그대로 응답으로 반환하도록 구현했다.

예를 들어 다음 명령을 실행하면,

ECHOPIXXLIX abc

내부적으로는 다음과 같이 처리된다.

c->argv[0] = "ECHOPIXXLIX"
c->argv[1] = "abc"

그리고 addReplyBulk(c, c->argv[1])에 의해 abc가 응답으로 반환된다.

테스트 코드 추가

command가 정상적으로 동작하는지 확인하기 위해 tests/unit/other.tcl에 unit test를 추가했다.

test {Coverage: ECHOPIXXLIX} {
    assert_equal bang [r ECHOPIXXLIX bang]
}

만약 command가 제대로 등록되지 않았다면 command를 찾지 못해 실패할 것이고, 함수 구현에서 잘못된 argument를 반환했다면 기대값과 실제값이 달라져 테스트가 실패할 것이다.

즉, 이 테스트는 단순히 문자열 하나가 잘 출력되는지만 확인하는 것이 아니라, 다음 흐름이 정상적으로 이어졌는지 확인하는 역할도 한다.

ECHOPIXXLIX command가 등록되어 있다.
lookupCommand()가 command를 찾을 수 있다.
c->cmd에 command 정보가 연결된다.
call() 내부에서 echoPixxlixCommand()가 호출된다.
c->argv[1] 값이 응답으로 반환된다.

빌드 및 테스트

구현 후 먼저 빌드를 진행했다.

make -j$(nproc)

이후 unit test를 실행했다.

./runtest --single unit/other

결과는 다음과 같이 정상적으로 통과했다.

[ok]: Coverage: ECHOPIXXLIX (0 ms)

valkey-cli 수동 검증

unit test 외에도 valkey-cli를 통해 직접 command를 실행해보았다.

127.0.0.1:6379> ECHOPIXXLIX abc
"abc"

127.0.0.1:6379> ECHOPIXXLIX "hello world"
"hello world"

입력한 문자열이 그대로 반환되는 것을 확인할 수 있었다.

PR 과정 정리

이번 구현 과정은 다음 순서로 진행했다.

기존 ECHO command 구조 확인
ECHOPIXXLIX command metadata 추가
commands.def에 command 항목 추가
server.h에 함수 선언 추가
server.c에 echoPixxlixCommand 구현
tests/unit/other.tcl에 unit test 추가
make로 빌드
unit test 실행
valkey-cli로 수동 검증
commit 후 PR 생성

작은 command 하나를 추가하는 과정이었지만, 실제로는 command metadata, command table 등록 정보, 함수 선언, 함수 구현, 테스트까지 여러 지점이 함께 맞아야 했다.

배운 점

이번 실습을 통해 Valkey command가 단순히 C 함수 하나로만 이루어진 것이 아니라는 점을 알 수 있었다.

처음에는 ECHOPIXXLIX abc를 입력하면 곧바로 echoPixxlixCommand()가 호출될 것처럼 생각했다. 하지만 실제로는 client 연결 수락, 데이터 수신, 프로토콜 parsing, command lookup, 실행 전 검증, 실제 함수 호출, 응답 전송이라는 여러 단계를 거친다.

학기 초 운영체제 tiny shell 과제에서 명령어 만들기를 했었는데, 그때와 유사한 C 코드를 작성하여 기억이 새록새록 나고 재밌었다. 역시 전공수업 과제를 딸깍 안하고 열심히 하면 언젠가는 도움이 된다.

command 등록 흐름과 실행 흐름이 server.commands hashtable에서 만난다는 점을 이해한 것도 큰 수확이었다.

서버 시작 시 command가 table에 등록되고, client 요청이 들어오면 lookupCommand()가 이 table에서 command를 찾는다. command를 찾은 뒤에는 c->cmd에 command 정보가 연결되고, 최종적으로 call() 함수 내부에서 다음 코드가 실행된다.

c->cmd->proc(c)

즉, 커스텀 command를 추가한다는 것은 단순히 새로운 C 함수를 작성하는 일이 아니라, “이 command 이름이 들어왔을 때 어떤 함수가 실행되어야 하는가”를 Valkey의 command 등록 구조에 연결하는 일이다.

마지막으로, 아주 작은 echo command를 추가하는 실습이었지만 Valkey 코드를 읽는 방법을 익힐 수 있었다. 그동안 한 파일에 16000줄이 넘어가는 코드들을 보며 대체 어디에 PR을 시도해야할지, 구조를 어떻게 이해할지 어려웠는데 해당 실습을 통해 코드를 어떻게 읽어야 할지 감이 잡혔다.

앞으로 다른 command를 분석할 때도 먼저 command 정의를 찾고, 연결된 함수 이름을 확인한 뒤, 실제 구현으로 따라 들어가면 된다. 예를 들어 GET, HGET, ZRANGE 같은 command도 같은 방식으로 command 정의에서 출발해 내부 구현을 추적할 수 있다.

Redis, Valkey는 왜 빠를까? - 자료구조, 메모리 최적화, RESP 프로토콜 실습

데구르르.. — Sun, 10 May 2026 15:05:56 +0900

OSSCA 2026 - Valkey 수업 내용을 바탕으로 정리한 글입니다.

누가 redis가 뭔가요? 라고 물어보면 in-memory에 데이터를 저장하는 빠른 key-value store라고 대답했다. 실제로 Valkey를 사용하는 가장 큰 이유도 DB나 disk보다 memory 접근이 훨씬 빠르기 때문이다.

하지만 Valkey의 성능은 단순히 “memory라서 빠르다”로만 설명되지 않는다. 내부적으로는 Hash Table, Skip List, Listpack, QuickList 같은 자료구조가 상황에 맞게 사용되고, command 실행 구조와 network I/O 처리 방식도 성능에 큰 영향을 준다. 또한 client와 server는 RESP라는 protocol을 통해 명령과 응답을 주고받는다.

이번 글에서는 Valkey가 왜 빠른지, 그 빠름이 어떤 내부 구조에서 나오는지, 그리고 RESP 실습을 통해 명령어가 실제로 어떻게 전달되는지 정리해보려고 한다.

Valkey를 쓰는 이유

Valkey를 사용하는 가장 직접적인 이유는 빠른 응답 속도다.

일반적인 DB는 data를 조회할 때 disk 접근, index 탐색, query execution, network 통신 등 여러 과정을 거친다. 반면 Valkey는 data를 memory에 저장하기 때문에 자주 접근하는 data를 훨씬 빠르게 읽고 쓸 수 있다.

그래서 Valkey는 DB를 완전히 대체하기보다는, DB 앞단이나 옆에서 빠른 처리가 필요한 역할을 맡는 경우가 많다.

사용처 설명

Cache	DB 조회 결과를 memory에 저장해 빠르게 응답
Session Store	여러 Web Server가 login session을 공유
Distributed Lock	여러 process가 같은 resource를 동시에 수정하지 못하게 제어
Rate Limiter	특정 user나 IP의 요청 횟수 제한
Leaderboard	Sorted Set을 이용해 ranking 관리
Queue	작업 대기열 관리

예를 들어 게시글 상세 조회 API가 있다고 하자. 매번 DB에서 게시글 정보를 읽으면 DB 부하가 커지고 응답 속도도 느려질 수 있다. 이때 자주 조회되는 게시글을 Valkey에 cache해두면 다음 요청부터는 DB까지 가지 않고 Valkey에서 바로 응답할 수 있다.

SET post:1 "{title:'Valkey 정리', content:'...'}"
GET post:1

이처럼 Valkey는 자주 조회되거나 빠르게 처리해야 하는 data를 memory에 올려두는 역할을 한다.

다만 Valkey를 잘 사용하려면 단순히 명령어 사용법만 아는 것으로는 부족하다. 내부 자료구조와 처리 방식을 이해해야 어떤 상황에서 빠르고, 어떤 상황에서 성능 문제가 생기는지 판단할 수 있다.

Sorted Set과 Skip List

Valkey의 대표적인 자료구조 중 하나는 Sorted Set이다.

Sorted Set은 일반 Set처럼 member를 저장하지만, 각 member에 score가 붙는다. 이 score를 기준으로 정렬된 상태를 유지할 수 있기 때문에 ranking, leaderboard, 인기 게시글 순위 같은 기능에 자주 사용된다.

ZADD ranking 100 user1
ZADD ranking 90 user2
ZADD ranking 120 user3
ZRANGE ranking 0 -1

문제는 정렬이다.

score 기준으로 빠르게 삽입하고 조회하려면 내부 자료구조가 중요하다. 단순 linked list를 사용하면 원하는 위치를 찾기 위해 처음부터 순차 탐색해야 하므로 최악의 경우 O(N)이 걸린다.

이를 개선하기 위해 Redis/Valkey의 Sorted Set은 큰 data에서는 Skip List를 사용한다.

Skip List는 linked list에 여러 단계의 “급행 구간”을 추가한 구조라고 이해하면 쉽다. 가장 아래 level에는 모든 node가 있고, 위 level로 갈수록 일부 node만 남는다. 탐색할 때는 가장 높은 level에서 시작해 오른쪽으로 이동하다가, 더 이상 갈 수 없으면 아래 level로 내려간다.

일반 linked list에서 30을 찾으려면 다음처럼 하나씩 봐야 한다.

1 → 5 → 10 → 15 → 20 → 30

반면 Skip List는 위쪽 level에서 일부 node를 건너뛰면서 탐색할 수 있다.

상위 level에서 크게 이동
→ 목표값보다 커질 것 같으면 아래 level로 내려감
→ 다시 오른쪽으로 이동

이 과정을 통해 평균적으로 O(log N) 탐색이 가능하다.

Skip List의 특징을 정리하면 다음과 같다.

linked list에 빠르게 건너뛰는 level을 추가한 구조
평균 탐색 시간복잡도는 O(log N)
node의 높이는 random하게 결정됨
트리보다 구현이 비교적 단순함
Sorted Set에서 score 기반 탐색과 삽입에 적합함

즉, Sorted Set은 단순히 “score가 있는 Set”이 아니라, 내부적으로 빠른 정렬 조회를 위해 Skip List 같은 자료구조를 사용하는 구조다.

Hash 자료구조와 field 단위 접근

Valkey의 Hash는 key 안에 다시 field-value 쌍을 저장하는 자료구조다. 쉽게 말하면 main key 안에 sub key를 가지는 구조라고 볼 수 있다.

예를 들어 user 정보를 저장한다고 해보자.

String으로 저장하면 다음처럼 JSON 형태로 저장할 수 있다.

SET user:1 "{name:'kim', age:20, email:'a@test.com'}"

이 방식은 전체 profile을 한 번에 읽고 쓸 때는 편하다. 하지만 email 하나만 수정하고 싶다면 문제가 생긴다.

GET user:1
JSON parsing
email 수정
다시 JSON serialize
SET user:1

이 과정은 read-modify-write 구조다. 여러 요청이 동시에 같은 값을 읽고 수정하면 race condition이 생길 수 있다.

반면 Hash를 사용하면 field 단위로 접근할 수 있다.

HSET user:1 name kim
HSET user:1 age 20
HSET user:1 email a@test.com

email만 바꾸고 싶다면 다음 한 줄이면 된다.

HSET user:1 email b@test.com

이렇게 하면 전체 JSON을 다시 읽고 쓰지 않아도 된다. 따라서 개별 field를 자주 변경하는 data라면 String보다 Hash가 더 적합하다.

방식 장점 단점

String JSON	전체 data를 한 번에 다루기 편함	field 단위 수정이 불편하고 race condition 가능
Hash	field 단위 수정이 쉬움	구조 설계를 미리 고려해야 함

Valkey를 cache로 사용할 때도 이 차이가 중요하다. 단순히 조회 결과 전체를 cache하는 경우라면 String JSON이 편할 수 있지만, 개별 field가 자주 바뀐다면 Hash를 사용하는 것이 더 안전하고 효율적이다.

Single-threaded command 처리 구조

Valkey를 공부하면서 자주 헷갈리는 부분이 있다.

Valkey는 single-threaded인가, multi-threaded인가?

정확히는 이렇게 이해하는 것이 좋다.

Valkey는 여러 thread를 사용할 수 있지만, 실제 data를 조회하거나 변경하는 command 실행은 main thread에서 순차적으로 처리된다.

즉, Valkey가 프로그램 전체에서 thread 하나만 사용한다는 뜻은 아니다. network I/O나 background 작업 등은 다른 thread가 도울 수 있다. 하지만 GET, SET, ZADD, HSET처럼 실제 자료구조를 읽고 수정하는 command 실행은 main thread 중심으로 이루어진다.

이 구조의 장점은 atomic성이다. 예를 들어 두 client가 동시에 다음 명령을 보냈다고 하자.

INCR count
INCR count

Valkey 내부에서는 두 명령이 완전히 동시에 실행되는 것이 아니라 순서대로 처리된다.

INCR count 실행 완료
→ 다음 INCR count 실행 완료

이 때문에 단일 command는 중간에 다른 command가 끼어들지 않고 atomic하게 처리될 수 있다. 내부 자료구조에 복잡한 lock을 많이 걸지 않아도 data 일관성을 유지할 수 있다는 장점이 있다.

하지만 단점도 있다.

명령 하나가 오래 걸리면 그동안 뒤에 들어온 다른 명령들이 기다려야 한다. 예를 들어 다음과 같은 명령은 조심해야 한다.

HGETALL huge_hash
SMEMBERS huge_set
ZRANGE huge_zset 0 -1

data가 적을 때는 괜찮지만, collection이 매우 크면 main thread를 오래 점유할 수 있다. 이 경우 단순한 GET, SET 요청까지 뒤에서 대기하게 되어 전체 latency가 증가할 수 있다.

따라서 Valkey를 사용할 때는 “명령 하나가 얼마나 오래 main thread를 점유하는가”를 항상 생각해야 한다.

Multi-threaded I/O와 main thread

그렇다면 Valkey가 multi-threaded I/O를 지원한다는 말은 무슨 뜻일까?

핵심은 network 처리와 command 실행을 구분하는 것이다.

Valkey는 client와 TCP connection을 맺고 요청을 받는다. 이 과정에는 socket read, request parsing, response write 같은 network I/O 작업이 포함된다. client 수가 많거나 응답 크기가 크면 이 I/O 작업 자체가 부담이 될 수 있다.

그래서 multi-threaded I/O에서는 worker thread가 network I/O를 도울 수 있다.

영역 처리방식

client network read/write	worker thread가 도울 수 있음
command parsing	일부 I/O thread가 도울 수 있음
실제 command 실행	main thread에서 순차 처리
data 조회/변경	main thread 중심

즉, multi-threaded I/O는 network 병목을 줄이기 위한 구조다. 하지만 실제 data를 변경하는 command 실행은 여전히 main thread에서 처리된다.

이 설계는 Valkey의 atomic한 command 처리 특성을 유지하면서도, network I/O 부담을 줄이기 위한 절충이라고 볼 수 있다.

메모리 최적화: Ziplist, Listpack, QuickList

Valkey는 in-memory 기반이다. 모든 data가 memory에 올라가기 때문에 메모리 사용량은 매우 중요하다. 같은 data를 저장하더라도 어떤 내부 encoding을 사용하는지에 따라 메모리 사용량이 크게 달라질 수 있다.

작은 data를 저장할 때는 Hash Table이나 Skip List처럼 무거운 자료구조를 바로 쓰는 대신, 더 compact한 구조를 사용하는 방식이 유리할 수 있다.

Ziplist

Ziplist는 Redis 6.x까지 사용되던 compact한 자료구조다. field와 value를 연속된 memory 공간에 순차적으로 저장한다.

예를 들어 Hash data가 다음과 같다면,

name → kim
age → 20
email → a@test.com

Ziplist에서는 대략 다음처럼 연속된 memory에 저장된다.

[name][kim][age][20][email][a@test.com]

이 방식은 pointer overhead가 적어 메모리를 아낄 수 있다. 하지만 중간에 값을 삽입하거나 크기가 변하면 뒤쪽 data를 이동해야 할 수 있어 비용이 커진다.

Listpack

Listpack은 Redis 7.x부터 ziplist를 대체하는 구조다. ziplist보다 구현을 단순화하고, 값 크기 변경 시 뒤쪽 entry들이 연쇄적으로 수정되는 문제를 줄이기 위해 도입되었다.

Listpack도 연속된 memory에 data를 촘촘하게 저장한다. 작은 collection에서는 Hash Table보다 메모리를 훨씬 적게 사용할 수 있다.

QuickList

QuickList는 Redis List에서 내부적으로 사용하는 자료구조다.

완전히 하나의 큰 연속 배열로 저장하면 realloc이나 memmove 비용이 커질 수 있고, 완전히 linked list로 저장하면 pointer overhead가 커진다. QuickList는 이 둘의 중간 형태다.

quicklistNode → quicklistNode → quicklistNode
     ↓               ↓               ↓
  listpack        listpack        listpack

즉, QuickList는 node 하나에 여러 값을 담고, 그런 node들을 linked list로 연결한다.
이 구조는 linked list의 유연성과 listpack의 메모리 효율을 함께 얻기 위한 방식이다.

성능과 메모리의 trade-off

Valkey 내부 자료구조를 이해할 때 가장 중요한 것은 메모리와 속도 사이의 trade-off다.

실습 자료의 예시 벤치마크에서는 Hash 10만 개를 저장할 때 Hash Table은 약 8.99MB를 사용하지만 listpack은 약 2MB 정도만 사용하는 것으로 제시되었다. 같은 data를 저장하더라도 compact encoding을 사용하면 메모리를 4~5배 정도 절약할 수 있다는 의미다.

하지만 메모리를 아낀다고 항상 좋은 것은 아니다.

Listpack은 data를 연속된 memory에 저장하므로 data 개수가 많아지면 insert/update 과정에서 realloc이나 memmove 비용이 커질 수 있다. 그래서 매우 큰 collection에 listpack을 사용하는 것은 오히려 성능에 좋지 않을 수 있다.

작은 collection에서는 listpack이 유리하다.

data 개수가 적음
→ 순차 탐색 비용이 크지 않음
→ 메모리 절약 효과가 큼
→ listpack 사용이 유리

반대로 data 개수가 많아지면 Hash Table이나 Skip List 같은 구조가 유리하다.

data 개수가 많음
→ 순차 탐색 비용 증가
→ 삽입/삭제 비용 증가
→ Hash Table, Skip List 사용이 유리

Sorted Set에서도 비슷한 trade-off가 있다.

실습 자료에서 제시된 500개짜리 Sorted Set 기준 예시에서는 ZADD 성능이 Skip List는 약 0.49μs, listpack은 약 5~6μs 정도로 비교되었다. 정확한 수치는 실험 환경과 설정에 따라 달라질 수 있지만, 이 예시는 Skip List가 연산 성능 면에서 더 빠르고, listpack은 메모리 절약 면에서 유리하다는 점을 보여준다.

구조 장점 단점

Listpack	메모리 절약	data가 많아지면 탐색/삽입 느림
Hash Table	조회/삽입 빠름	메모리 overhead 큼
Skip List	정렬 탐색 빠름	pointer와 node overhead 큼

Valkey는 기본적으로 작은 collection에는 compact encoding을 사용하고, 일정 임계값을 넘으면 원래 자료구조로 전환한다.

설정: compact encoding과 압축 설정

Valkey의 내부 encoding은 설정값에 따라 달라질 수 있다. 다만 설정마다 제어하는 대상이 다르기 때문에 구분해서 이해해야 한다.

먼저 Hash나 Sorted Set이 listpack으로 유지될지, 아니면 Hash Table이나 Skip List 같은 구조로 전환될지를 결정하는 설정이 있다.

hash-max-listpack-entries
hash-max-listpack-value
zset-max-listpack-entries
zset-max-listpack-value

이런 설정은 대략 다음 기준을 조정한다.

collection의 entry 개수가 일정 이하인가?
각 value 또는 member의 크기가 일정 이하인가?

조건을 만족하면 compact한 listpack encoding을 사용하고, 임계값을 넘으면 더 빠른 일반 자료구조로 전환된다.

List의 경우에는 listpack node의 크기와 관련된 설정으로 다음이 더 적절하다.

list-max-listpack-size

이 설정은 QuickList 내부에서 각 listpack node가 어느 정도 크기까지 저장될 수 있는지에 영향을 준다.

한편 다음 설정은 listpack과 Hash Table/Skip List 간 전환 기준이 아니라, QuickList node 압축과 관련된 별도의 설정이다.

list-compression-depth

list-compression-depth는 QuickList에서 head와 tail 쪽 몇 개 node를 압축하지 않고 유지할지 결정한다. 중간 node는 LZF 알고리즘으로 압축될 수 있다. 즉, 이 설정은 compact encoding 전환 임계값이라기보다는 List 내부 node 압축 정책에 가깝다.

설정 역할

hash-max-listpack-entries	Hash가 listpack으로 유지될 최대 field 수
zset-max-listpack-entries	Sorted Set이 listpack으로 유지될 최대 member 수
list-max-listpack-size	QuickList 내부 listpack node 크기 제어
list-compression-depth	QuickList node 압축 깊이 제어

설정을 메모리 절약 방향으로만 조정하면 성능이 나빠질 수 있고, 반대로 빠른 자료구조를 너무 빨리 사용하면 메모리 사용량이 증가할 수 있다. 결국 workload에 맞게 적절한 균형을 잡는 것이 중요하다.

하나의 collection에 너무 많은 data를 넣으면 안 되는 이유

Valkey를 사용할 때 특히 조심해야 할 점은 많은 수의 data를 하나의 collection에 몰아넣지 않는 것이다.

예를 들어 다음과 같은 구조를 생각해볼 수 있다.

HSET all_users user1 ...
HSET all_users user2 ...
HSET all_users user3 ...
...

이렇게 all_users라는 하나의 Hash에 모든 user 정보를 넣으면, 해당 key 하나가 매우 커진다. 이런 big key는 여러 문제를 만들 수 있다.

특정 command가 main thread를 오래 점유함
전체 조회 명령이 위험해짐
network response가 커짐
rehash, realloc, encoding conversion 비용이 커짐
p99 latency가 튈 수 있음

따라서 data가 많다면 하나의 collection에 몰아넣기보다는 여러 key로 나누는 것이 좋다.

예를 들어 user id 기준으로 range를 나눌 수 있다.

users:0      → user_id 0~9999
users:1      → user_id 10000~19999
users:2      → user_id 20000~29999

또는 날짜 기준으로 나눌 수도 있다.

viewcount:2026-05-01
viewcount:2026-05-02

Valkey는 빠르지만, 모든 data를 무작정 하나의 큰 collection에 넣는 방식은 위험하다.
작은 collection을 적절히 나누고, 필요한 경우 TTL이나 trim을 사용해 크기를 제한하는 설계가 필요하다.

RESP: Valkey 명령어가 오가는 protocol

지금까지는 Valkey 내부 자료구조와 command 처리 구조를 정리했다.
이제 실습과 직접 연결되는 RESP를 살펴보자.

RESP는 REdis Serialization Protocol의 약자다.
Valkey client와 server가 명령어와 응답을 주고받기 위한 network protocol이다.

우리가 valkey-cli에서 다음처럼 입력한다고 하자.

GET a

사람이 보기에는 단순한 문자열이지만, 실제로는 RESP 형식으로 표현된다.

*2\r\n$3\r\nGET\r\n$1\r\na\r\n

이를 해석하면 다음과 같다.

*2   → 인자가 2개인 배열
$3   → 길이 3인 문자열
GET  → 첫 번째 인자
$1   → 길이 1인 문자열
a    → 두 번째 인자

즉, server 입장에서는 다음과 같은 command 배열을 받는 것이다.

["GET", "a"]

RESP2의 주요 타입은 다음과 같다.

타입 시작문자 예시

Simple String	+	+OK
Error	-	-ERR
Integer	:	:1
Bulk String	$	$3\r\nabc\r\n
Array / Multi Bulk	*	*2 ...

RESP에서 각 line은 \r\n, 즉 carriage return과 line feed로 구분된다.
Bulk String은 문자열 길이를 먼저 보내고, 그 다음 실제 문자열을 보낸다.

$3\r\nabc\r\n

이는 길이가 3인 문자열 abc를 의미한다.

이렇게 길이 기반으로 문자열을 표현하는 이유는 공백이나 특수문자가 포함된 data도 정확히 처리하기 위해서다. 예를 들어 value가 hello world라면 공백 기준 parsing만으로는 하나의 문자열인지 두 개의 인자인지 구분하기 어렵다. RESP는 길이를 명시하기 때문에 이런 문제를 피할 수 있다.

RESP3도 있다. RESP3는 RESP2보다 표현력이 더 좋고, double, null, boolean, big number 같은 타입을 더 명확하게 표현할 수 있다. 기본 접속은 RESP2지만, HELLO 3 명령을 통해 RESP3로 전환할 수 있다.

HELLO 3

실습: valkey-cli로 명령 실행하기

먼저 valkey-cli로 Valkey server에 접속해 기본 명령어를 실행했다.

get a
set a 123
set a abc
get a
zadd z1 100 OSSCA
zrange z1 0 -1

실행 결과는 다음과 같았다.

127.0.0.1:6379> get a
(nil)

127.0.0.1:6379> set a 123
OK

127.0.0.1:6379> set a abc
OK

127.0.0.1:6379> get a
"abc"

127.0.0.1:6379> zadd z1 100 OSSCA
(integer) 1

127.0.0.1:6379> zrange z1 0 -1
1) "OSSCA"

처음 get a를 실행했을 때는 a라는 key가 없었기 때문에 (nil)이 반환되었다. 이후 set a 123으로 값을 저장했고, 다시 set a abc를 실행하면서 같은 key의 value가 abc로 덮어써졌다.

zadd z1 100 OSSCA는 z1이라는 Sorted Set에 OSSCA라는 member를 score 100으로 추가하는 명령이다. 결과로 나온 (integer) 1은 새로운 member가 1개 추가되었다는 뜻이다.

zrange z1 0 -1은 z1의 0번째 index부터 마지막 index까지 조회하는 명령이다. 실습에서는 OSSCA 하나만 들어 있었기 때문에 결과도 하나만 출력되었다.

여기서 중요한 점은, valkey-cli가 보여주는 출력은 사람이 보기 좋게 가공된 형태라는 것이다. 실제 server와 client 사이에서는 RESP 형식의 요청과 응답이 오간다.

실습: RESP 형식으로 직접 명령 보내기

이제 RESP 형식으로 명령을 직접 보내보자.

telnet으로 6379 port에 접속할 수 있다.

telnet 127.0.0.1 6379

또는 \r\n을 정확히 보내기 위해 printf와 nc를 사용할 수도 있다.

예를 들어 GET a를 RESP 형식으로 보내면 다음과 같다.

printf '*2\r\n$3\r\nGET\r\n$1\r\na\r\n' | nc 127.0.0.1 6379

이 요청은 다음 command를 의미한다.

["GET", "a"]

응답은 다음처럼 올 수 있다.

$3
abc

이는 길이 3인 bulk string abc를 의미한다.

SET c 789를 RESP로 표현하면 다음과 같다.

printf '*3\r\n$3\r\nSET\r\n$1\r\nc\r\n$3\r\n789\r\n' | nc 127.0.0.1 6379

이는 다음 배열과 같다.

["SET", "c", "789"]

성공하면 server는 다음과 같은 RESP 응답을 보낸다.

+OK

ZADD z2 100 OSSCA도 RESP로 표현할 수 있다.

printf '*4\r\n$4\r\nZADD\r\n$2\r\nz2\r\n$3\r\n100\r\n$5\r\nOSSCA\r\n' | nc 127.0.0.1 6379

응답은 다음과 같이 integer 형태로 온다.

:1

valkey-cli에서는 이 응답을 (integer) 1처럼 보여준다.

마지막으로 ZRANGE z2 0 -1은 다음처럼 보낼 수 있다.

printf '*4\r\n$6\r\nZRANGE\r\n$2\r\nz2\r\n$1\r\n0\r\n$2\r\n-1\r\n' | nc 127.0.0.1 6379

응답은 다음과 같은 array 형태로 올 수 있다.

*1
$5
OSSCA

이를 해석하면 다음과 같다.

*1    → 원소가 1개인 배열
$5    → 길이 5인 문자열
OSSCA → 실제 반환된 member

즉, valkey-cli에서 보던 1) "OSSCA"는 실제 RESP 응답을 사람이 읽기 좋게 바꾼 결과다.

실습을 통해 확인한 점

이번 실습을 통해 가장 먼저 확인한 것은, valkey-cli에서 입력하는 명령이 server에 그대로 문자열로 전달되는 것이 아니라는 점이다.

예를 들어 다음 명령은,

GET a

실제로는 다음과 같은 RESP 배열 구조로 전달된다.

["GET", "a"]

또한 ZADD, ZRANGE처럼 인자가 여러 개인 명령도 Multi Bulk 형식으로 표현할 수 있었다.

["ZADD", "z2", "100", "OSSCA"]
["ZRANGE", "z2", "0", "-1"]

Valkey server는 TCP socket을 통해 들어온 byte stream을 input buffer에 저장하고, RESP parser를 통해 command를 완성한 뒤 실행한다. 이 과정을 생각하면 Valkey는 단순히 명령어를 실행하는 프로그램이 아니라, network protocol을 기반으로 동작하는 server라는 점이 더 분명해진다.

Valkey를 사용할 때 주의할 점

Valkey를 사용할 때는 몇 가지를 조심해야 한다.

첫째, 하나의 collection에 너무 많은 data를 넣지 않는 것이 중요하다.
Hash, Set, Sorted Set, List 모두 data가 너무 커지면 특정 명령이 main thread를 오래 점유할 수 있다.

둘째, 전체 조회 명령을 조심해야 한다.

ZRANGE z1 0 -1

실습에서는 z1에 OSSCA 하나만 들어 있었기 때문에 문제가 없었다. 하지만 실제 서비스에서 수십만 개의 member가 들어 있는 Sorted Set에 대해 ZRANGE key 0 -1을 실행하면 전체 data를 한 번에 반환하게 된다. 이 경우 command 실행 시간뿐 아니라 network response 크기도 커진다.

셋째, Valkey의 성능은 내부 자료구조와 설정에 따라 달라진다.
작은 collection에서는 listpack을 사용해 메모리를 아낄 수 있지만, data가 커지면 Hash Table이나 Skip List로 전환되어야 성능이 유지된다.

넷째, Valkey가 memory 기반이라 빠르다는 말은 맞지만, 무거운 command나 big key가 생기면 single-threaded command 처리 구조 때문에 전체 latency가 튈 수 있다.

마무리

이번 정리를 통해 Valkey를 조금 더 시스템 관점에서 바라볼 수 있었다.

처음에는 Valkey를 단순히 빠른 cache 정도로 생각했지만, 실제로는 다양한 내부 구조가 함께 동작하고 있었다.

Sorted Set은 Skip List를 통해 score 기반 탐색을 빠르게 처리하고, Hash는 field 단위 접근을 제공해 개별 값 수정에 유리하다. 작은 collection에서는 Ziplist나 Listpack 같은 compact encoding을 사용해 메모리를 절약하고, List는 QuickList를 통해 linked list와 compact structure의 장점을 함께 활용한다.

또한 Valkey는 command 실행을 main thread에서 순차적으로 처리해 atomic성을 유지한다. 동시에 network I/O는 worker thread가 도울 수 있어 I/O 병목을 줄일 수 있다.

즉, Valkey의 single-threaded 특성은 단순한 한계가 아니라 data 일관성과 성능 사이의 설계 선택이라고 볼 수 있다.

마지막으로 RESP 실습을 통해 GET, SET, ZADD, ZRANGE 같은 명령이 실제로는 RESP protocol 형식으로 server에 전달된다는 점을 확인했다.

정리하면, Valkey를 잘 사용하려면 단순히 명령어 사용법만 아는 것으로는 부족하다.
내부 자료구조, 메모리 encoding, command 처리 방식, network protocol이 성능에 어떤 영향을 주는지 함께 이해해야 한다.

Valkey는 단순한 in-memory 저장소가 아니라, 자료구조와 protocol, OS-level 처리 방식이 결합된 시스템이다.

참고한 글 - https://serverwizard.tistory.com/117

Redis

Redis - in memory 데이터 저장소 (key-value형태의 데이터) - 싱글 스레드 (1번에 1개의 명령어만 처리) => 여러 문제의 원인이 됨 https://www.zdnet.co.kr/view/?no=20131119174125 - 초당 10만~15만 get/set 가능 Redis의 자

serverwizard.tistory.com

https://velog.io/@banggeunho/%EB%A0%88%EB%94%94%EC%8A%A4Redis-%EC%95%8C%EA%B3%A0-%EC%93%B0%EC%9E%90.-%EC%A0%95%EC%9D%98-%EC%A0%80%EC%9E%A5%EB%B0%A9%EC%8B%9D-%EC%95%84%ED%82%A4%ED%85%8D%EC%B2%98-%EC%9E%90%EB%A3%8C%EA%B5%AC%EC%A1%B0-%EC%9C%A0%ED%9A%A8-%EA%B8%B0%EA%B0%84

[Redis] 레디스 알고 쓰자. - 정의, 저장방식, 아키텍처, 자료구조, 유효 기간

레디스(Redis)는 메모리 기반의 데이터 저장소이다. 키-밸류(key-value) 데이터 구조에 기반한 다양한 형태의 자료 구조를 제공하며, 데이터들을 저장할 수 있는 저장소이다. 최신 버전의 레디스는 PU

velog.io

Git-X-Ray : 깃 구조 살펴보기

데구르르.. — Sun, 10 May 2026 14:10:25 +0900

1. 실습 개요

이번 실습에서는 Git 저장소를 직접 생성하고, 파일을 추가한 뒤 두 번의 commit을 수행하면서 .git 내부, 특히 .git/objects 디렉터리에 어떤 object가 생성되는지 관찰하였다.

또한 Git object 파일을 Python의 zlib.decompress()로 직접 열어 보고, commit / tree / blob object가 각각 어떤 정보를 담고 있는지도 확인하였다.

2. 진행한 작업

이번 실습은 PowerShell 환경에서 진행하였다.

실습 순서는 다음과 같다.

2-1. 저장소 생성 및 파일 추가

git init
echo "ossca" > a.txt
git add a.txt
git commit -m "첫번째 커밋"

2-2. 파일 수정 후 두 번째 커밋

"ossca study" | Out-File -Encoding utf8 a.txt
git add a.txt
git commit -m "두번째 커밋"

2-3. 생성된 object 확인

Get-ChildItem .git\\objects-Recurse-File

2-4. object 압축 해제 확인

예를 들어 두 번째 commit object는 아래와 같이 확인하였다.

python -c "import zlib; OBJECT_PATH=r'.git\\objects\\7b\\8819c6d32d120877db51b459cd3894e3c057fe'; data=zlib.decompress(open(OBJECT_PATH,'rb').read()); print(data); print(); print(data.decode(errors='replace'))"

tree object는 Git 명령으로 더 쉽게 확인할 수 있었다.

git cat-file -p f261758d74fb919ad6b381d6f7be894d4b6c034c

출력 결과:

100644 blob f853bacec969b422f71054a8b1810b9bb8f7ba29    a.txt

이를 통해 두 번째 tree가 a.txt와 두 번째 blob object를 가리키고 있음을 확인하였다.

3. object 관계 정리

이번 실습에서 생성된 object들은 다음과 같은 관계를 가진다.

첫 번째 상태
a.txt 내용 -> blob 9e0176...
           ↓
        tree 2cdbd2...
           ↓
      commit c137bd...   ("첫번째 커밋")

두 번째 상태
a.txt 내용 -> blob f853ba...
           ↓
        tree f26175...
           ↓
      commit 7b8819...   ("두번째 커밋")
           ↑
        parent = c137bd...

파일 내용을 blob으로 저장하고
파일 목록과 blob 연결을 tree로 묶은 뒤
이를 가리키는 commit object를 생성하며
이전 commit과는 parent로 연결

4. 생성된 object 표 정리

해시 타입 의미

9e0176bd24d00fdb5b837f3a7bdd4db7611efd25	blob	첫 번째 a.txt 내용 (ossca)
2cdbd2c5688b466cc9287982a9fc0ef26c3898b6	tree	첫 번째 시점의 디렉터리 스냅샷
c137bde3269577c083c813cf30a9afdcd5504c6b	commit	첫 번째 커밋
f853bacec969b422f71054a8b1810b9bb8f7ba29	blob	수정된 a.txt 내용 (ossca study)
f261758d74fb919ad6b381d6f7be894d4b6c034c	tree	두 번째 시점의 디렉터리 스냅샷
7b8819c6d32d120877db51b459cd3894e3c057fe	commit	두 번째 커밋

총 6개의 object가 생성되었고, 구성은 다음과 같다.

blob 2개
tree 2개
commit 2개

5. 느낀 점

이번 실습을 통해 Git의 commit이 단순한 파일 저장이나 메시지 기록이 아니라는 점을 확인할 수 있었다. object 파일을 직접 열어본 결과, Git은 파일 내용을 blob으로 저장하고, 이를 tree로 묶은 뒤, commit object가 해당 tree와 부모 commit을 가리키는 방식으로 동작하고 있었다. 특히 두 번째 commit에서 parent 항목이 나타나는 것을 보고, Git의 버전 관리가 단순한 덮어쓰기가 아니라 이전 상태와 연결된 구조라는 점이 인상적이었다.

겉으로는 간단한 명령어 몇 줄에 불과하지만, 내부적으로는 체계적인 객체 구조를 기반으로 버전 관리가 이루어진다는 점을 이해할 수 있었다. 이번 실습을 통해 앞으로 Git을 사용할 때 commit의 의미를 더 정확히 인식하면서 활용할 수 있을 것 같다.

[데이터베이스 시스템 7판 10장] 빅데이터 정리 | HDFS, MapReduce, Spark, 스트림 처리까지

데구르르.. — Thu, 12 Mar 2026 03:14:39 +0900

1. 왜 빅데이터가 등장했을까

빅데이터는 단순히 “데이터가 많다”는 뜻이 아니다. 웹, SNS, IoT, 로그 시스템의 성장으로 데이터 양이 너무 커지고 너무 빠르게 들어와서 기존 방식만으로 처리하기 어려워졌다는 점이다.

그래서 한 대의 강한 서버보다, 여러 서버를 묶어 병렬로 저장하고 처리하는 방식이 중요해졌다.

클러스터를 구성하는 개별 서버를 보통 node라고 부른다.

2. 빅데이터의 3V

빅데이터를 설명할 때 가장 자주 나오는 개념이 3V다.

요소 의미 예시

Volume	데이터 규모가 매우 큼	TB, PB 단위 로그/센서 데이터
Velocity	데이터가 매우 빠르게 생성됨	클릭 로그, 실시간 거래, IoT 이벤트
Variety	데이터 형태가 다양함	테이블, JSON, 텍스트, 이미지, 영상

3. 분산 저장 방식 한눈에 보기

빅데이터 환경에서는 한 가지 저장 방식으로 모든 문제를 해결하지 않는다. 데이터 형태와 처리 목적에 따라 분산 파일 시스템, 샤딩, Key-Value 저장소, 병렬/분산 DB 같은 방식을 나눠 쓴다. 관계형 저장소가 강한 일도 있고, NoSQL 계열이 더 잘 맞는 일도 있다.

방식 핵심 아이디어 강점 아쉬운 점

분산 파일 시스템	큰 파일을 여러 노드에 분산 저장	확장성, 장애 내성	작은 레코드 대량 처리엔 비효율적일 수 있음
샤딩	데이터를 키 기준으로 여러 DB에 분할	구현이 비교적 단순	라우팅/복제 책임이 커짐
Key-Value 저장소	key로 빠르게 읽고 쓰는 단순 모델	고확장성, 고가용성	join/복잡한 질의 제약
병렬/분산 DB	여러 노드에서 DB 연산 병렬 처리	SQL 지원 강함	초대규모 확장성엔 한계가 있을 수 있음

4. Distributed File System이란

분산 파일 시스템은 데이터를 여러 머신에 나눠 저장하지만, 사용자 입장에서는 하나의 파일시스템처럼 보이게 하는 구조다.

특징

여러 머신에 분산 저장
높은 확장성
값싼 서버 여러 대 사용 가능
일부 서버가 고장 나도 복제로 버틸 수 있음

대표 예시:

GFS (Google File System)
HDFS (Hadoop Distributed File System)

4-1. HDFS 이해하기

HDFS는 Hadoop의 대표적인 분산 파일 시스템이다. 핵심 아이디어는 큰 파일을 block 단위로 나눠 여러 DataNode에 저장하고, 메타데이터는 NameNode가 관리하는 구조다.

사용자는 하나의 파일시스템처럼 보지만, 실제론 파일이 여러 block으로 쪼개져 분산 저장된다.

NameNode: 파일명, block 위치 같은 메타데이터 관리
DataNode: 실제 block 저장
Client: NameNode에 block 위치를 묻고, 실제 데이터는 DataNode와 직접 주고받음

HDFS는 write-once-read-many 모델에 잘 맞고, 큰 파일을 저장하고 순차적으로 읽는 작업에 강하다. 반면 작은 파일이 지나치게 많거나, 잦은 랜덤 업데이트가 필요한 워크로드엔 잘 맞지 않을 수 있다. 그래서 HDFS는 일반 관계형 DB를 대체한다기보다, 대규모 파일 저장소에 더 가깝게 보는 편이 자연스럽다.

5. 복제, 일관성, CAP

분산 시스템은 일부 노드가 죽어도 계속 동작해야 하니까 보통 데이터를 복제해둔다. 이때 중요한 개념이 Availability(가용성) 과 Consistency(일관성) 이다.

예를 들어 복제본이 3개일 때 read/write 시 다수 복제본을 확인하는 majority 방식은 일관성을 확보하는 대표적인 아이디어다.

여기서 유명한 게 CAP 정리다. 네트워크 파티션이 생긴 상황에서는, 분산 시스템이 Consistency와 Availability를 동시에 완벽히 만족시키기 어렵다!! 둘 중 하나를 선택해야한다.

전통적인 DB 시스템: 일관성을 더 중시
대규모 Web 서비스: 가용성을 더 중시하는 경우 많음

6. MapReduce와 WordCount

MapReduce는 대규모 병렬 계산을 단순하게 만들기 위한 프로그래밍 모델이다. 개발자는 기본적으로 map 함수와 reduce 함수만 작성하고, 분산 실행, 장애 처리, 스케줄링, 중간 데이터 정렬 같은 복잡한 일은 시스템이 맡는다.

가장 대표적인 예제가 WordCount다. 문서에서 단어를 뽑아 (word, 1) 형태로 내보내고, 같은 단어끼리 묶은 뒤, 마지막에 합을 계산한다. 이때 shuffle 단계는 같은 key를 자동으로 모아주는 시스템 단계다.

단계 하는 일

map	입력에서 단어를 꺼내 (word, 1) 생성
shuffle	같은 단어끼리 자동 그룹핑
reduce	각 단어별 값을 합쳐 최종 개수 계산

MapReduce의 장점은 초대규모 배치 처리와 장애 내성이다. 하지만 단순한 조회나 join, aggregation 같은 작업까지 전부 MapReduce 코드로 직접 짜면 너무 장황해진다. 그래서 이후에는 더 높은 수준의 대수 연산을 지원하는 엔진이 발전하게 된다.

자세한 코드를 보고싶다면 https://hadoop.apache.org/docs/stable/hadoop-mapreduce-client/hadoop-mapreduce-client-core/MapReduceTutorial.html

7. Spark와 고수준 분산 처리

MapReduce 다음 세대 시스템들은 map/reduce 두 단계만이 아니라, join, groupBy, filter, agg 같은 더 풍부한 연산을 기본 지원한다. 그 대표적인 예가 Spark다.

Spark의 핵심 개념 중 하나가 RDD(Resilient Distributed Dataset) 다.

RDD 특징

데이터가 여러 노드에 partition 되어 저장됨
연산을 적용하면 새로운 RDD 생성
immutable에 가까운 변환 중심 모델
장애 발생 시 재계산 가능

또 Spark 계열 연산은 보통 lazy evaluation 방식으로 동작해서, collect() 같은 action이 호출되기 전까지는 실행 계획만 쌓아둘 수 있다.

MapReduce vs Database

MapReduce가 강한 쪽

매우 큰 규모 병렬 처리
비정형 데이터
복잡한 절차형 처리
대규모 로그 분석

SQL/DB가 강한 쪽

select/project/join/aggregation
짧고 선언적인 질의
구조화 데이터 분석

항목 MapReduce Spark

처리 방식	map / shuffle / reduce 중심	더 다양한 고수준 연산 지원
표현력	비교적 저수준	RDD, DataFrame, Dataset 지원
실행 특징	배치 중심	lazy execution 기반 최적화 가능
사용감	단순하지만 장황해질 수 있음	분석/ETL 파이프라인 작성이 더 자연스러움

8. 스트림 데이터와 윈도우

빅데이터가 꼭 저장된 데이터만 뜻하는 건 아니다. 현실에서는 데이터가 끊임없이 들어오는 스트림 형태인 경우가 많다. 주식 거래, 검색 로그, IoT 센서, 네트워크 이벤트, SNS 피드 같은 데이터가 여기에 해당한다.

이런 데이터는 쌓아두고 나중에 보는 것보다 즉시 계산하고 반응하는 것이 중요할 때가 많다.

문제는 스트림이 사실상 무한하다는 점이다.

그래서 스트림 처리 시스템은 보통 window 개념으로 무한 스트림을 유한 구간으로 잘라서 계산한다.

윈도우 종류 의미 예시

Tumbling	겹치지 않는 고정 구간	매 1시간 집계
Hopping	겹칠 수 있는 고정 구간	1시간 윈도우를 20분마다 계산
Sliding	현재 이벤트를 중심으로 이동하며 계산	최근 N분 이벤트 기준 계산
Session	활동 간격을 기준으로 묶음	사용자가 일정 시간 쉬면 새 세션 시작

스트림 처리에서는 continuous query, 늦게 들어오는 이벤트 문제, 그리고 특정 시점 이전 데이터가 다 도착했음을 알려주는 메타 정보 같은 개념도 중요하다. 결국 핵심은 무한한 흐름을 의미 있는 구간으로 잘라서 계산하는 것이다.

9. Kafka와 Publish-Subscribe

스트림 파이프라인에서 데이터를 한 시스템에서 다른 시스템으로 흘려보내려면 producer와 consumer를 느슨하게 연결하는 구조가 필요하다.

이때 자주 쓰는 게 Publish-Subscribe 모델이다. 생산자는 topic에 데이터를 publish하고, 소비자는 관심 있는 topic을 subscribe 해서 가져간다.

즉, Kafka는 단순 메시지 큐라기보다 현대 데이터 파이프라인의 허브 역할에 가깝다. topic, partition, replication 개념을 바탕으로 생산자와 소비자를 이어주고, 스트림 처리 엔진과 저장 시스템 사이를 연결하는 중심축처럼 자주 쓰인다.

10. 핵심 요약

빅데이터는 Volume, Velocity, Variety 때문에 기존 DBMS 방식만으로 처리하기 어려운 데이터 환경이다.
이를 해결하려고 클러스터 기반 분산 저장/처리가 등장했다.
HDFS는 큰 파일을 block 단위로 나눠 분산 저장하는 대표적인 시스템이다.
샤딩은 데이터를 여러 DB로 나누는 방식이지만, 애플리케이션 책임이 커질 수 있다.
Key-Value 저장소는 고확장성을 위해 많은 DB 기능을 단순화한 NoSQL 계열이다.
분산 시스템에서는 복제, 가용성, 일관성, CAP 문제가 매우 중요하다.
MapReduce는 대규모 병렬 처리를 단순한 map/reduce 모델로 추상화했다.
이후에는 Spark, Tez 같은 더 고수준 대수 연산 기반 엔진이 발전했다.
RDD, DataFrame, DataSet 은 Spark에서 분산 데이터를 다루는 핵심 개념이다.
스트림 데이터는 저장된 데이터와 달리 실시간으로 계속 들어오는 데이터다.
스트림 처리에서는 window, continuous query, pub-sub, Kafka 같은 개념이 중요하다.

11. 전체 흐름

데이터가 너무 많아지고 빨라짐, 한 대 서버와 기존 DBMS만으로는 부족
분산 저장(HDFS, NoSQL)이 등장
분산 처리(MapReduce) 등장
더 높은 수준의 실행 엔진(Spark)으로 발전
이제는 실시간 스트림 처리와 Kafka 같은 데이터 흐름 플랫폼까지 중요해졌다.

이미지 출처 모음

HDFS 구조도: Apache Hadoop HDFS Architecture Guide
WordCount / MapReduce 흐름: Apache Hadoop MapReduce Tutorial
스트림 윈도우 종류: Azure Stream Analytics / Apache Flink 문서

[데이터베이스 시스템 7판 6장] E-R 모델 정리 | ERD 기본 개념부터 관계형 스키마 변환까지 한 번에 이해하기

데구르르.. — Thu, 12 Mar 2026 02:57:22 +0900

1. 데이터베이스 설계는 어떻게 진행될까

데이터베이스 설계는 그냥 테이블부터 만드는 작업이 아니다. 보통 다음 순서로 진행된다.

1) 요구사항 분석

사용자가 어떤 데이터를 필요로 하는지 정리하는 단계다.

예:

학생 정보가 필요한가
수강 정보가 필요한가
교수와 지도 관계를 관리해야 하는가

이 단계의 결과물은 요구사항 명세서다.

2) 개념적 설계

요구사항을 바탕으로 데이터를 개념적으로 표현한다.
이때 사용하는 대표적인 도구가 E-R 모델(Entity-Relationship Model) 이다.

결과물은 보통 E-R 다이어그램(ERD) 이다.

3) 논리적 설계

E-R 다이어그램을 실제 DB에서 사용할 수 있는 관계형 스키마로 바꾸는 단계다.

개체 → 테이블
속성 → 컬럼
관계 → 외래키 or 별도 릴레이션

같은 식으로 변환한다.

4) 물리적 설계

실제로 어떻게 저장할지 결정하는 단계다.

예:

인덱스 생성 여부
파일 구조
저장 방식
성능 최적화

2. 설계할 때 왜 E-R 모델이 필요할까

처음부터 테이블을 바로 만들면 편해 보이지만,
그렇게 하면 구조가 꼬이기 쉽다.

특히 다음 두 가지 문제가 자주 생긴다.

중복성

같은 정보를 여러 번 저장하는 문제다.

예를 들어 분반마다 course_id, title을 반복 저장하면
같은 과목 제목이 여러 행에 중복 저장된다.

이러면 수정할 때 일부만 바뀌어서 일관성 문제가 생길 수 있다.

불완전성

현재 구조로는 어떤 정보를 표현할 수 없는 문제다.

예를 들어 분반 정보만 있고 과목 자체를 나타내는 테이블이 없다면,
아직 분반이 열리지 않은 새 과목은 DB에 넣을 수 없다.

즉, 어떤 구조는 데이터를 저장할 수는 있어도
현실 세계를 충분히 표현하지 못할 수 있다.

결국 E-R 모델의 역할

E-R 모델은 이런 문제를 줄이기 위해
현실 세계의 개체와 관계를 먼저 정리하게 도와준다.

즉, 테이블 만들기 전에 먼저

무엇이 개체인지
무엇이 관계인지
어떤 속성이 필요한지
어떤 제약이 있는지

를 정리하는 과정이라고 보면 된다.

3. E-R 모델의 기본 개념

개체(Entity)

현실 세계에서 구별 가능한 대상이다.

예:

학생
교수
과목
학과

즉, 독립적으로 존재를 생각할 수 있는 객체다.

개체 집합(Entity Set)

같은 종류의 개체들을 모아둔 집합이다.

예:

모든 학생들의 집합
모든 교수들의 집합

ERD에서는 보통 사각형으로 표현한다.

관계(Relationship)

개체들 사이의 연결이다.

예:

학생이 과목을 수강한다
학생이 교수의 지도를 받는다
교수가 학과에 소속된다

즉, 개체끼리 어떤 식으로 연관되는지를 나타낸다.

관계 집합(Relationship Set)

같은 종류의 관계들의 집합이다.

예:

모든 지도 관계
모든 수강 관계

관계도 단순 연결만 있는 게 아니라
필요하면 속성을 가질 수 있다.

예:

advisor 관계의 date
takes 관계의 grade

즉, 관계에도 설명 정보가 붙을 수 있다.

4. E-R 다이어그램 보는 법

E-R 다이어그램은 개체, 관계, 속성을 기호로 표현한 그림이다.

기본 기호

사각형: 개체 집합
다이아몬드: 관계 집합
원: 속성
밑줄: 주 키
이중선: 전체 참여
이중 다이아몬드: 식별 관계

왜 그림으로 그릴까?

ERD는 단순히 예쁘게 그리려고 쓰는 게 아니다.
테이블 만들기 전에 구조를 눈으로 검토할 수 있어서 좋다.

특히

빠진 개체는 없는지
관계 방향이 맞는지
중복 저장이 생기지 않는지
약한 개체인지 강한 개체인지

이런 걸 미리 확인할 수 있다.

5. 관계의 세부 요소

관계에도 속성이 있을 수 있다

관계는 단순히 “연결”만 표현하는 게 아니다.

예를 들어 학생과 교수 사이 advisor 관계가 있다고 하면,
“언제 지도교수로 지정되었는가” 같은 정보는
학생 속성도 아니고 교수 속성도 아니라 관계 자체의 속성이다.

예:

advisor(date)

이런 속성을 설명 속성(descriptive attribute) 라고 생각하면 된다.

역할(Role)

같은 개체 집합이 하나의 관계에 두 번 이상 참여할 때는 역할이 필요하다.

예를 들어 과목과 선수과목 관계를 생각해보자.

한 과목이 다른 과목의 선수과목일 수 있음
둘 다 같은 course 개체 집합에 속함

이럴 때는

현재 과목
선수 과목

같이 역할 이름을 구분해줘야 헷갈리지 않는다.

6. 속성의 종류

ER 모델에서는 속성도 여러 종류로 나뉜다.

1) 단순 속성

더 이상 쪼갤 수 없는 속성이다.

예:

2) 복합 속성

여러 하위 속성으로 나눌 수 있는 속성이다.

예:

name = {first_name, last_name}
address = {city, street, zip}

실제 관계형 스키마로 바꿀 때는 보통 쪼개서 저장한다.

3) 단일값 속성

한 개체가 하나의 값만 가지는 속성이다.

예:

학생의 학번

4) 다중값 속성

한 개체가 여러 값을 가질 수 있는 속성이다.

예:

전화번호
이메일
자격증

예를 들어 교수 한 명이

연구실 번호
집 번호
개인 번호

를 모두 가질 수 있다면 전화번호는 다중값 속성이다.

관계형 모델로 변환할 때는 보통 별도 릴레이션으로 분리해야 한다.

5) 유도 속성

다른 속성으로부터 계산 가능한 속성이다.

예:

age = today - birth_date

이건 굳이 DB에 저장하지 않고 필요할 때 계산할 수도 있다.

7. 관계의 차수(Degree)

관계에 몇 개의 개체 집합이 참여하는지에 따라 나뉜다.

이진 관계(Binary)

두 개체 집합이 참여하는 관계다.

예:

학생 — 지도교수
학생 — 수강과목

대부분의 관계가 여기에 속한다.

삼진 관계(Ternary)

세 개체 집합이 동시에 참여하는 관계다.

예:

학생 — 교수 — 프로젝트

이건 단순히 이진 관계 세 개로 쪼개면 의미가 달라질 수 있어서
정말로 세 개가 함께 묶여야 하는 관계라면 ternary 관계로 표현하는 게 더 정확하다.

8. 대응 카디널리티(Mapping Cardinality)

카디널리티는 “몇 대 몇 관계인가”를 나타낸다.

예를 들어 학생과 지도교수 관계를 보자.

교수 한 명이 여러 학생을 지도할 수 있다
학생은 한 명의 지도교수만 가진다

이건 일대다(1:N) 관계다.

대표적인 카디널리티

일대일 (1:1)
일대다 (1:N)
다대일 (N:1)
다대다 (M:N)

예시로 이해하기

advisor 관계에서

교수: 지도학생이 없을 수도 있음 → 0..*
학생: 지도교수가 반드시 한 명 있어야 함 → 1..1

이렇게 생각할 수 있다.

즉, 카디널리티는 단순히 숫자 문제가 아니라
현실 세계의 규칙을 모델에 반영하는 과정이다.

9. 전체 참여와 부분 참여

이건 카디널리티와 함께 자주 나온다.

전체 참여(Total Participation)

모든 개체가 반드시 어떤 관계에 참여해야 하는 경우다.
ERD에서는 보통 이중선으로 표시한다.

예:

모든 학생은 반드시 지도교수가 있어야 한다

부분 참여(Partial Participation)

일부 개체만 관계에 참여해도 되는 경우다.
ERD에서는 보통 단일선으로 표시한다.

예:

어떤 교수는 지도학생이 없을 수도 있다

왜 중요한가?

이건 나중에 관계형 스키마로 바꿀 때
외래키가 NULL 가능인지, NOT NULL인지와 연결될 수 있다.

즉,

전체 참여 → 보통 반드시 참조 필요
부분 참여 → 참조가 없을 수도 있음

10. 키(Key)

개체 집합의 키

각 개체를 고유하게 식별하는 속성이다.

예:

학생의 ID
교수의 ID
학과의 dept_name

관계 집합의 키

관계를 고유하게 식별하는 키다.
이건 관계의 카디널리티에 따라 달라진다.

예를 들어 학생(s)과 교수(i)의 관계라면:

관계 유형관계 키

다대일	s_id
일대다	i_id
일대일	s_id 또는 i_id
다대다	(s_id, i_id)

즉, 어떤 쪽이 여러 번 나타날 수 있는지에 따라 키 구성이 달라진다.

11. 약한 개체 집합(Weak Entity Set)

이 부분은 ER 모델에서 꽤 중요하다.

약한 개체는 자기 자신의 속성만으로는 유일하게 구별할 수 없는 개체다.
즉, 다른 개체에 의존해서만 존재를 구분할 수 있다.

예:

section(분반)

분반은 보통 course 없이 단독으로 존재한다고 보기 어렵다.
어떤 과목의 분반인지가 있어야 의미가 생긴다.

식별 개체 집합

약한 개체를 식별해주는 강한 개체 집합이다.

예:

course 가 section의 식별 개체 집합

식별 관계

약한 개체와 식별 개체를 연결하는 관계다.
ERD에서는 이중 다이아몬드로 표시한다.

예:

sec_course

약한 개체의 키

약한 개체의 주 키는 보통

식별 개체의 키 + 약한 개체의 부분 키(discriminator)

로 구성된다.

예:
section의 경우

course_id
sec_id
semester
year

이 합쳐져야 분반을 유일하게 식별할 수 있다.

즉:

section(course_id, sec_id, semester, year)

약한 개체에서 헷갈리기 쉬운 점

ER 다이어그램에서는 약한 개체 안에 식별 개체의 키를 직접 속성처럼 안 그릴 수도 있다.
하지만 실제 관계형 DB로 구현할 때는 반드시 포함해야 한다.

즉,

개념 모델에서는 종속성을 강조
구현 모델에서는 실제 키 컬럼이 필요

이 차이를 구분해야 한다.

12. E-R 다이어그램을 관계형 스키마로 변환하는 방법

이제 ERD를 실제 테이블 구조로 바꾸는 단계다.
이 부분이 바로 논리적 설계다.

변환은 크게 몇 가지 경우로 나눠 생각하면 편하다.

1) 단순 속성만 가진 강한 개체 집합

가장 간단한 경우다.

ER 개체 하나를 그대로 릴레이션 하나로 만든다.

예:

student(ID, name, tot_cred)

즉,

개체 집합 → 테이블
속성 → 컬럼

으로 바로 옮기면 된다.

2) 복합 속성이 있는 강한 개체 집합

복합 속성은 그대로 둘 수 없고
하위 단순 속성으로 분해해서 넣는다.

예:

name = {first_name, last_name}

그러면 스키마는 이렇게 바뀔 수 있다.

student(ID, first_name, last_name, tot_cred)

필요하면 prefix를 붙여도 된다.

예:

name_first
name_last

3) 다중값 속성 처리

다중값 속성은 별도 릴레이션을 만들어야 한다.

예를 들어 교수 한 명이 여러 전화번호를 가진다면
전화번호를 instructor 테이블 안에 반복 컬럼으로 넣는 건 적절하지 않다.

그래서 보통 이렇게 분리한다.

instructor(ID, name, dept_name, salary)
inst_phone(ID, phone_number)

여기서 inst_phone의 기본키는 보통

(ID, phone_number)

가 된다.

즉, 한 교수에게 여러 전화번호를 연결하는 구조다.

4) 약한 개체 집합 변환

약한 개체는 식별 개체의 주 키를 포함해서 릴레이션을 만든다.

예:

section(course_id, sec_id, semester, year)

여기서 course_id는 식별 개체인 course에서 온 키고,
나머지는 section을 구분하는 속성이다.

5) 관계 집합 표현

다대다 관계

참여하는 개체 집합들의 주 키를 모두 가져와야 한다.

예:

advisor(s_id, i_id, date)

여기서 date는 관계의 설명 속성이다.

다대일 관계

보통 “다” 쪽에 “일” 쪽의 기본키를 외래키로 넣으면 된다.

즉, 굳이 별도 관계 릴레이션을 안 만들어도 되는 경우가 많다.

예:

여러 학생이 한 학과에 속한다면
student 테이블에 dept_name을 넣는 식

13. 스키마 중복 처리

일대다 / 다대일 관계

“다” 쪽이 전체 참여라면
별도 관계 릴레이션을 만들지 않고 “다” 쪽 릴레이션에 “일” 쪽 키를 넣는 방식이 효율적이다.

예:

학생은 반드시 한 학과에 속함
그러면 student 릴레이션에 dept_name 추가

이렇게 하면 관계 릴레이션을 따로 만들 필요가 없다.

일대일 관계

한쪽 릴레이션에 다른 쪽의 주 키를 넣고 관계 집합 릴레이션을 생략할 수 있다.

다만 어느 쪽에 넣을지는

전체 참여 여부
NULL 허용 여부
설계 의도

를 보고 결정하는 게 좋다.

14. E-R 설계에서 자주 생기는 고민

이 부분은 진짜 중요하다.
ER 모델은 “정답 하나”가 아니라 설계 선택의 문제가 많이 나온다.

1) 속성으로 넣을까, 개체로 만들까?

예: 교수 전화번호

선택지는 여러 개다.

단일 속성 phone_number
다중값 속성 phone_number
별도 phone 개체 집합

어떤 구조가 맞는지는 요구사항에 따라 다르다.

예:

전화번호 하나만 필요 → 단일 속성
여러 개 가능 → 다중값 속성 or 별도 개체

즉, 현실 세계 규칙을 보고 정해야 한다.

2) 관계로 표현할까, 개체로 만들까?

예: 학생과 분반의 수강 관계

단순히 수강 여부만 저장하면 takes 관계로 충분할 수 있다.
하지만 여기에

재수강 여부
등록 상태
결제 상태
수강 신청 시간

같은 정보가 많이 붙으면
단순 관계보다는 registration 같은 별도 개체로 분리하는 게 더 자연스러울 수 있다.

3) 이진 관계로 할까, n진 관계로 할까?

세 개 이상의 개체가 하나의 사실을 이루는 경우는
단순한 이진 관계 몇 개보다 n진 관계가 더 정확할 수 있다.

예:

부품 — 공급업체 — 프로젝트
학생 — 교수 — 프로젝트

이건 셋이 동시에 묶이는 의미가 중요하다.

4) 관계 속성을 어디에 둘까?

일대다 관계에서는 관계의 설명 속성을 “다” 쪽 개체에 옮길 수 있는 경우가 있다.

예:

advisor 관계의 date

학생이 지도교수를 정확히 한 명만 가진다면
그 날짜를 학생 쪽 속성으로 옮겨도 의미가 유지될 수 있다.

하지만 다대다 관계에서는 이런 이동이 어려운 경우가 많다.

5) n진 관계를 이진 관계로 쪼갤 수 있을까?

가능한 경우도 있지만, 의미가 달라질 수도 있다.

필요하면 새로운 개체 E를 만들고

형태의 이진 관계로 변환할 수 있다.

그리고 원래 관계의 속성은 E에 넣는다.

하지만 이건 단순 변환이 아니라
원래 의미가 유지되는지 꼭 따져봐야 한다.

15. 핵심 요약

이번 장 핵심만 다시 정리하면 이렇다.

데이터베이스 설계는 요구사항 분석 → 개념적 설계 → 논리적 설계 → 물리적 설계 순서로 진행된다.
E-R 모델은 현실 세계의 데이터 구조를 개체와 관계 중심으로 표현하는 도구다.
개체, 관계, 속성, 키, 카디널리티, 참여 제약은 ERD의 핵심 요소다.
속성은 단순 / 복합 / 단일값 / 다중값 / 유도 속성으로 나눠 이해할 수 있다.
약한 개체는 다른 개체에 의존해서 식별되며, 식별 개체의 키를 함께 사용해야 한다.
ERD를 관계형 스키마로 변환할 때는 개체는 테이블로, 관계는 외래키 또는 별도 릴레이션으로 변환한다.
다중값 속성은 별도 릴레이션으로 분리하는 것이 일반적이다.
설계에서는 “속성으로 둘지 / 개체로 분리할지 / 관계로 표현할지” 같은 선택이 중요하다.

마무리

6장은 “좋은 테이블 구조를 만들기 위한 사고방식” 을 배우는 장이라고 보면 된다.

지금까지는 이미 만들어진 테이블에 질의하는 느낌이었다면, ER 모델부터는 이제 반대로

어떤 개체가 필요한지
어떻게 관계를 맺을지
어떤 속성을 어디에 둘지

를 먼저 고민하게 된다.

[데이터베이스 시스템 7판 5장] JDBC, 트리거, 재귀 질의, 윈도우 함수까지 | 데이터베이스 고급 SQL 한 번에 정리

데구르르.. — Thu, 12 Mar 2026 02:43:04 +0900

1. 왜 범용 프로그래밍 언어로 DB에 접근할까

SQL은 데이터베이스를 다루는 데 아주 강력한 언어지만,
현실에서는 SQL만으로 모든 작업을 처리할 수는 없다.

왜냐면 실제 서비스에서는 이런 작업도 필요하기 때문이다.

사용자 입력 받기
버튼 클릭 처리
보고서 출력
GUI 화면에 결과 보여주기
조건에 따라 SQL을 동적으로 바꾸기
외부 시스템과 통신하기

즉, SQL은 데이터를 다루는 언어이고
Java, Python, C 같은 범용 프로그래밍 언어는 프로그램 전체 흐름을 제어하는 언어다.

그래서 실제 개발에서는 보통

프로그램 언어가 전체 로직을 담당하고
SQL이 데이터 조회/수정 담당

이렇게 역할을 나눠서 쓴다.

2. SQL 접근 방식: 동적 SQL vs 내장 SQL

DB에 접근하는 방식은 크게 두 가지로 볼 수 있다.

1) 동적 SQL

프로그램 실행 중에 SQL문을 만들어서 DB에 보내는 방식이다.

예:

JDBC
ODBC

즉, 실행 시점에 SQL이 결정된다.

예를 들어 검색 조건이 사용자 입력에 따라 달라진다면 동적 SQL이 필요하다.

2) 내장 SQL (Embedded SQL)

프로그램 코드 안에 SQL을 직접 포함하는 방식이다.

예:

EXEC SQL SELECT ...;

이 방식은 전처리기가 SQL을 일반 함수 호출 코드로 변환한 뒤 컴파일한다.

즉,

SQL이 코드 안에 고정적으로 들어가고
컴파일 전에 변환 과정을 거친다

동적 SQL vs 내장 SQL 차이

구분 동적 SQL 내장 SQL

SQL 생성 시점	실행 시	컴파일 전/전처리 시
유연성	높음	낮음
대표 예시	JDBC, ODBC	Embedded SQL
장점	상황에 따라 쿼리 변경 가능	고정 쿼리 처리에 유리

요즘 실무에서는 보통 JDBC 같은 동적 SQL 방식이 훨씬 더 많이 쓰인다.

3. JDBC란?

JDBC(Java Database Connectivity) 는
Java에서 데이터베이스에 접속하고 SQL을 실행할 수 있게 해주는 API다.

쉽게 말하면
Java ↔ DB를 연결하는 표준 통로라고 생각하면 된다.

JDBC 기본 절차

JDBC 코드는 보통 이 흐름으로 간다.

DB 연결
SQL 실행 객체 생성
SQL 실행
결과 처리
자원 정리

예시:

Connection conn = DriverManager.getConnection(url, user, pass);
Statement stmt = conn.createStatement();
ResultSet rs = stmt.executeQuery(
"SELECT dept_name, avg(salary) FROM instructor GROUP BY dept_name"
);

while (rs.next()) {
System.out.println(rs.getString("dept_name") + " " + rs.getFloat(2));
}

각 객체 역할 정리

Connection
DB와 연결된 통로
Statement
SQL문 실행용 객체
ResultSet
조회 결과를 담는 객체

연결> 실행> 결과 읽는 구조

NULL 처리 주의

JDBC에서 숫자 컬럼을 읽을 때는 NULL 처리가 헷갈릴 수 있다.

예:

int a = rs.getInt("a");
if (rs.wasNull()) {
// NULL 처리
}

왜냐면 getInt()는 NULL이어도 자바 기본형 int를 반환해야 해서
0처럼 보일 수 있기 때문이다.
그래서 wasNull()로 꼭 확인해야 한다.

4. PreparedStatement가 중요한 이유

SQL을 문자열 이어붙이기로 만들면 편해 보여도 위험하다.

예:

"SELECT * FROM instructor WHERE name='" + name + "'"

이런 방식은 사용자가 이상한 입력을 넣으면 SQL 자체가 변형될 수 있다.

SQL Injection이란?

예를 들어 사용자가 이름에 이렇게 입력했다고 해보자.

X' OR 'Y'='Y

그러면 원래 의도했던 쿼리가 아니라
항상 참이 되는 SQL이 만들어질 수 있다.

결과적으로:

로그인 우회
전체 데이터 노출
권한 없는 조회

같은 문제가 생길 수 있다.

이게 바로 SQL Injection Attack 이다.

해결책: PreparedStatement

PreparedStatement는 SQL 구조를 먼저 고정하고,
값만 나중에 바인딩하는 방식이다.

예:

PreparedStatement ps =
conn.prepareStatement("INSERT INTO instructor VALUES (?,?,?,?)");

ps.setString(1, "88877");
ps.setString(2, "Perry");
ps.setString(3, "Finance");
ps.setInt(4, 125000);
ps.executeUpdate();

장점

SQL Injection 방지
같은 형태의 SQL 반복 실행 시 성능상 이점
코드 가독성 향상

실무에서는 사용자 입력이 들어가는 SQL은 거의 무조건
PreparedStatement를 쓴다고 생각하면 된다.

보안은 PreparedStatement만으로 끝일까?

아니다. 이것도 같이 중요하다.

최소 권한 원칙
입력값 검증
화이트리스트 기반 필터링
DB 계정 권한 분리

즉, PreparedStatement는 핵심 방어 수단이지만
보안 전체의 전부는 아니다.

5. 메타데이터(Metadata)란?

메타데이터는 말 그대로 데이터에 대한 데이터다.

즉,

테이블 이름
컬럼 이름
타입
기본키 정보
스키마 구조

같은 정보를 의미한다.

이건 단순히 “보기용”이 아니라 실제로 꽤 유용하다.

활용 예

동적 쿼리 생성
자동 문서화
마이그레이션 스크립트 작성
DB 구조 점검
컬럼 기반 UI 자동 생성

ResultSetMetaData

조회 결과의 컬럼 정보를 확인할 수 있다.

예:

ResultSetMetaData rsmd = rs.getMetaData();
for (int i = 1; i <= rsmd.getColumnCount(); i++) {
 System.out.println(rsmd.getColumnName(i));
 System.out.println(rsmd.getColumnTypeName(i));
}

이건 “지금 조회된 결과가 어떤 컬럼들로 구성돼 있는지”를 보는 데 쓴다.

DatabaseMetaData

DB 전체 구조에 대한 정보를 가져온다.

예:

DatabaseMetaData dbmd = conn.getMetaData();
ResultSet rs = dbmd.getTables("", "", "%", new String[]{"TABLE"});
while (rs.next()) {
 System.out.println(rs.getString("TABLE_NAME"));
}

즉, 스키마 수준의 정보 확인에 더 가깝다.

6. JDBC에서 트랜잭션 제어하기

PostgreSQL은 기본적으로 auto commit 상태다.
즉, SQL 하나 실행할 때마다 바로 반영된다.

그런데 여러 작업을 하나의 묶음으로 처리해야 할 때는
직접 트랜잭션을 제어해야 한다.

예:

conn.setAutoCommit(false);

// SQL 작업들 수행

conn.commit();
conn.rollback();

왜 필요할까?

예를 들어 계좌 이체는 보통 2단계다.

A 계좌에서 돈 차감
B 계좌에 돈 증가

이때 중간에 오류가 나면 둘 중 하나만 반영되면 안 된다.
그래서 둘 다 성공하거나, 둘 다 취소되어야 한다.

그걸 보장하는 게 트랜잭션이다.

7. 함수와 프로시저

데이터베이스에도 반복해서 쓰는 로직을 저장해둘 수 있다.
이게 함수(Function) 와 프로시저(Procedure) 다.

즉, 비즈니스 로직을 애플리케이션 코드에만 두지 않고
DB 내부에도 넣을 수 있다.

왜 DB 안에 로직을 넣을까?

여러 프로그램이 같은 로직 공유 가능
중복 코드 감소
로직 변경 시 애플리케이션 전체 수정 필요 감소
데이터 가까이에서 실행돼 효율적일 수 있음

함수 vs 프로시저 차이

구분 함수(Function) 프로시저(Procedure)

반환값	있음	보통 직접 반환 안 함
사용 위치	SQL 식 안에서 사용 가능	독립 실행
용도	계산 결과 반환	여러 단계 작업 수행
트랜잭션 제어	제한적	DBMS에 따라 가능

PostgreSQL 함수 예시

create function function_name(param_list)
returns return_type
language plpgsql
as $$
declare
begin
-- 로직
end;
$$;

테이블 함수

테이블 자체를 반환하는 함수도 있다.

create function function_name(param_list)
returns table (column_list)
language plpgsql
as $$
begin
end;
$$;

이건 결과를 하나의 릴레이션처럼 반환한다.

PostgreSQL 프로시저 예시

create procedure procedure_name(parameter_list)
language plpgsql
as $$
declare
begin
end;
$$;

PostgreSQL 11+부터 프로시저를 지원하고,
프로시저는 함수보다 트랜잭션 제어에 더 적합하다.

외부 언어 루틴

plpgsql 말고도

C
Java
C++
같은 외부 언어로 함수/프로시저를 만들 수 있다.

이건 강력하지만 보안상 위험할 수 있다.

특히 C는 메모리 접근이 자유로워서 더 조심해야 한다.

보안 대책

샌드박스 실행
메모리 안전 언어 사용
별도 프로세스에서 실행

대신 이런 방식은 성능 오버헤드가 생길 수 있다.

8. 트리거(Trigger)란?

트리거는 DB에서 특정 사건이 발생했을 때 자동으로 실행되는 작업이다.

즉,

INSERT
UPDATE
DELETE

같은 이벤트가 일어나면 자동으로 실행된다.

트리거는 보통 두 가지를 정의한다.

언제 실행할지
- BEFORE
- AFTER
무슨 동작을 할지
- 로그 저장
- 값 자동 수정
- 제약조건 보완
- 연쇄 갱신

트리거가 유용한 이유

트리거는 단순 자동화가 아니라
데이터 무결성 보조 장치 역할도 한다.

예를 들어 잘못된 입력을 자동으로 바꾸거나,
변경 이력을 남기거나,
관련 데이터 갱신을 자동화할 수 있다.

예시 1: 빈 문자열을 NULL로 바꾸는 트리거

create trigger setnull_trigger before update of takes
referencing new row as nrow
for each row
when (nrow.grade = '')
begin atomic
set nrow.grade = null;
end;

이건 성적이 빈 문자열로 갱신되면 자동으로 NULL로 바꾼다.

예시 2: 감사 로그 남기기

실습 예시처럼 last_name 변경 전 값을 로그 테이블에 저장하는 것도 대표적인 트리거 활용이다.

트리거 함수:

CREATE OR REPLACE FUNCTION log_last_name_changes()
RETURNS TRIGGER
LANGUAGE PLPGSQL
AS
$$
BEGIN
IF NEW.last_name <> OLD.last_name THEN
INSERT INTO employee_audits(employee_id, last_name, changed_on)
VALUES(OLD.id, OLD.last_name, now());
END IF;

RETURN NEW;
END;
$$;

이렇게 하면 UPDATE가 일어날 때마다 이전 성이 자동 저장된다.

OLD / NEW

트리거에서 자주 나오는 핵심 개념이다.

OLD: 변경 전 행
NEW: 변경 후 행

즉, UPDATE 트리거에서는 둘 다 중요하다.

트리거 사용 시 주의

트리거는 편리하지만 과하게 쓰면

로직 흐름이 숨겨져서 디버깅 어려움
성능 저하
예상 못한 부작용

이 생길 수 있다. 그래서 보통

감사 로그
무결성 보조
자동 파생값 갱신

같은 곳에 신중하게 쓴다.

9. 재귀 질의(Recursive Query)란?

재귀 질의는 계층 구조 데이터를 처리할 때 사용한다.

예:

조직도
댓글 트리
부품 조립 구조
선수과목 관계
상사-부하 관계

이런 구조는 “부모를 찾고, 그 부모의 부모를 또 찾고...” 같은 방식이 필요하다.
이때 재귀 질의를 쓴다.

기본 문법

WITH RECURSIVE cte_name AS (
 <base query>
 UNION ALL
 <recursive query>
)
SELECT * FROM cte_name;

구조는 두 부분으로 나뉜다.

base query

처음 시작점

recursive query

이전 결과를 이용해서 다음 단계 확장

더 이상 새 결과가 없으면 종료된다.

숫자 세기 예시

WITH RECURSIVE cnt(n) AS (
 SELECT 1
 UNION ALL
 SELECT n + 1
 FROM cnt
 WHERE n < 3
)
SELECT n FROM cnt;

결과는 1, 2, 3 이 나온다.

이건 재귀 질의 구조를 가장 단순하게 보여주는 예시다.

조직도 / 부하 직원 찾기 예시

WITH RECURSIVE subordinates AS (
SELECT employee_id, manager_id, full_name
FROM employees
WHERE employee_id = 2

UNION

SELECT e.employee_id, e.manager_id, e.full_name
FROM employees e
INNER JOIN subordinates s ON s.employee_id = e.manager_id
)
SELECT * FROM subordinates;

이 쿼리는 특정 직원 아래의 모든 하위 직원들을 단계적으로 찾는다.

즉,

base: 시작 직원
recursive: 그 직원의 부하
그다음은 부하의 부하
더 없으면 종료

재귀 질의에서 주의할 점

사이클이 있으면 무한 반복 문제가 생길 수 있다.
그래서 실제 실무에서는

중복 제거
방문 여부 추적
깊이 제한

같은 장치를 넣기도 한다.

10. 순위 함수와 윈도우 함수

이번 파트는 SQL에서 꽤 재밌는 부분이다.
왜냐면 집계처럼 계산하면서도 행을 유지할 수 있기 때문이다.

먼저, 기존 방식의 한계

예전 방식으로 순위를 구하려면 보통 서브쿼리를 써야 했다.

select ID, (1 + (select count(*)
 from student_grades B
 where B.GPA > A.GPA)) as s_rank
from student_grades A
order by s_rank;

이 방식도 맞긴 한데, 학생마다 서브쿼리가 한 번씩 실행되니까 비효율적이다.

rank() 윈도우 함수

select ID, rank() over (order by GPA desc) as s_rank
from student_grades
order by s_rank;

이제 DB가 자동으로 순위를 계산해준다.

OVER가 의미하는 것

윈도우 함수는 항상 OVER(...)와 함께 쓴다.

예:

rank() over (order by GPA desc)

여기서 OVER는 “어떤 기준으로 계산할지”를 정하는 창(window) 역할을 한다.

PARTITION BY

이건 그룹을 나눠서 각 그룹 안에서 따로 계산하게 한다.

select ID, dept_name,
 rank() over (partition by dept_name order by GPA desc) as dept_rank
from dept_grades
order by dept_name, dept_rank;

이 쿼리는 학과별 순위를 따로 구한다.

즉,

partition 안 하면 전체 대상 순위
partition 하면 그룹별 순위

주요 순위 함수

함수 의미

rank()	공동순위 허용, 다음 순위 건너뜀
row_number()	무조건 1,2,3...
percent_rank()	백분위 순위
cume_dist()	누적 분포
ntile(n)	n개 구간으로 나눔

rank() vs row_number()

이건 자주 비교된다.

예를 들어 점수가

이면

rank() 결과:

row_number() 결과:

즉,

공동순위 반영 → rank()
그냥 번호 매기기 → row_number()

ntile(n)

전체를 n개 구간으로 나눈다.

select ID, ntile(4) over (order by GPA desc) as quartile
from student_grades;

이건 GPA 기준으로 학생들을 4등분한다.

즉, 사분위처럼 나눌 때 유용하다.

11. 윈도우 함수의 진짜 핵심: 행을 안 합친다

이 부분이 중요하다.

GROUP BY는 여러 행을 하나로 합쳐버린다.
반면 윈도우 함수는 원래 행을 유지한 채 계산 결과를 덧붙인다.

예를 들어 이동합:

select date, sum(value) over
 (order by date rows between 1 preceding and 1 following)
from sales;

이건 현재 행 기준으로

이전 1행
현재 행
다음 1행

까지 포함해서 합계를 계산한다.

즉, 각 행마다 주변 데이터를 보고 계산하는 느낌이다.

ROWS vs RANGE

ROWS

행 개수를 기준으로 범위를 잡는다.

예:

rows unbounded preceding

처음 행부터 현재 행까지

RANGE

값 범위를 기준으로 잡는다.

예:

range interval '7 days' preceding

현재 날짜 기준 7일 전부터 현재까지

즉,

ROWS = 물리적 행 기준
RANGE = 값의 범위 기준

누적 잔액 예시

select account_number, date_time,
sum(value) over
(partition by account_number
order by date_time
rows unbounded preceding) as balance
from transaction
order by account_number, date_time;

이건 계좌별로 거래 내역을 시간순으로 보면서
처음 거래부터 현재까지의 누적 잔액을 계산한다.

실무적으로도 꽤 직관적인 예시다.

12. ODBC는 뭐고 JDBC랑 뭐가 다를까

ODBC는 Open Database Connectivity 의 약자다.
DB 접근용 API라는 점에서는 JDBC와 비슷하지만, 더 범용적이고 오래된 표준이다.

구분 ODBC JDBC

언어	주로 C/C++ 등	Java 전용
플랫폼	전통적으로 Windows 중심	Java 기반이라 OS 독립적
스타일	절차적	객체지향

지금은 Java에서는 거의 JDBC를 쓰는 편이다.

13. 핵심 요약

이번 고급 파트 핵심만 뽑으면 이렇다.

SQL만으로는 GUI 처리나 프로그램 제어까지 다 하긴 어렵다.
그래서 Java 같은 범용 언어와 DB를 연결해서 사용한다.
JDBC는 Java에서 DB에 접근하는 표준 API다.
PreparedStatement는 SQL Injection 방지와 성능 면에서 중요하다.
메타데이터를 이용하면 테이블 구조나 결과 컬럼 정보를 동적으로 다룰 수 있다.
트랜잭션 제어는 auto commit과 commit/rollback 흐름으로 이해하면 된다.
함수와 프로시저는 DB 내부에 비즈니스 로직을 저장하는 도구다.
트리거는 특정 이벤트 발생 시 자동 실행되는 로직이다.
재귀 질의는 계층 구조 데이터를 처리할 때 매우 유용하다.
윈도우 함수는 행을 유지하면서 계산한다는 점에서 GROUP BY와 다르다.
rank(), row_number(), ntile() 같은 함수는 순위와 분석에 자주 쓰인다.

마무리

5장은 DB를 실제 시스템 안에서 어떻게 활용하는지를 보여주는 장이라고 보면 된다.

개인적으로 시험에서 중요한 흐름은 이거다.

앱에서 DB 접근 → JDBC
안전하게 실행 → PreparedStatement
DB 내부 로직 → 함수 / 프로시저 / 트리거
복잡한 구조 처리 → 재귀 질의
분석형 계산 → 윈도우 함수

[데이터베이스 시스템 7판 4장] SQL 조인, 뷰, 무결성 제약조건, 인덱스, 권한

데구르르.. — Thu, 12 Mar 2026 02:34:58 +0900

1. 조인 연산이란

조인(join)은 두 개의 릴레이션을 연결해서 하나의 결과 릴레이션으로 만드는 연산이다.

관계형 데이터베이스에서는 데이터가 보통 여러 테이블로 나뉘어 저장된다.
그래서 실제로 원하는 정보를 얻으려면 테이블을 합쳐서 봐야 하는 경우가 많다.

예를 들어

student
takes

이 두 테이블이 있다고 하면,

학생 이름과 수강한 과목을 함께 보고 싶을 때 조인을 쓴다.

조인은 카티션 곱과 비슷해 보이지만,
아무 튜플이나 다 합치는 게 아니라 특정 조건을 만족하는 튜플끼리만 결합한다.

실제 SQL에서는 보통 FROM 절에서 쓴다.

2. 조인 연산의 종류

조인은 크게 다음처럼 나눠서 보면 된다.

자연 조인(NATURAL JOIN)
내부 조인(INNER JOIN)
외부 조인(OUTER JOIN)
- LEFT OUTER JOIN
- RIGHT OUTER JOIN
- FULL OUTER JOIN

3. 자연 조인(NATURAL JOIN)

자연 조인은 두 릴레이션에서 이름이 같은 모든 속성을 기준으로 자동으로 매칭해서 조인한다.

즉, 공통 이름의 열이 있으면
그 열의 값이 같은 튜플끼리 자동으로 합쳐진다.

특징

공통 속성을 자동으로 찾아서 조인
결과에서 공통 속성은 한 번만 나타남
결과는 하나의 릴레이션

예를 들면:

SELECT *
FROM student NATURAL JOIN takes;

이 경우 두 테이블에서 이름이 같은 속성을 전부 기준으로 조인한다.

자연 조인의 장점

문법이 짧다
공통 속성이 명확할 때는 편하다

자연 조인의 위험성

문제는 이름이 같다고 해서 항상 같은 의미의 속성은 아니라는 점이다.

예를 들어:

course.dept_name
student.dept_name

이 둘은 이름은 같아도 의미가 다를 수 있다.
그런데 NATURAL JOIN을 쓰면 이 둘도 자동으로 매칭해버릴 수 있다.

이게 자연 조인의 가장 큰 위험이다.

즉, 편하긴 한데 의도치 않은 조인 조건이 숨어들 수 있다.

4. USING과 ON 차이

자연 조인 대신 더 안전하게 조인하려면 USING 이나 ON 을 많이 쓴다.

USING

두 릴레이션에 이름이 같은 속성이 있을 때,
그중 어떤 공통 속성으로 조인할지 명시하는 방식이다.

SELECT *
FROM student JOIN takes USING (course_id);

특징

공통 속성 이름이 같아야 사용 가능
결과에서 공통 속성은 한 번만 표시됨
문법이 간단함

ON

조인 조건을 직접 적는 방식이다.

SELECT *
FROM student JOIN takes
ON student.ID = takes.ID;

특징

속성 이름이 달라도 사용 가능
가장 일반적이고 유연함
결과에서 양쪽 속성이 모두 남을 수 있음

USING vs ON 한 번에 정리

구분USINGON

사용 조건	같은 이름 속성이 있어야 함	이름 달라도 가능
조건 방식	USING(column)	ON A.col = B.col
결과 컬럼	공통 컬럼 1번만 표시	양쪽 컬럼 다 남을 수 있음
장점	짧고 깔끔	유연하고 명확
실무 사용	제한적	훨씬 많이 사용

실제로는 ON을 가장 많이 쓴다고 보면 된다.
왜냐면 조건을 명시적으로 보여줘서 실수할 가능성이 적기 때문이다.

5. 내부 조인(INNER JOIN)

내부 조인은 조건에 맞는 튜플만 결과에 포함하는 조인이다.

사실 JOIN 이라고만 쓰면 대부분 INNER JOIN 의미다.

SELECT *
FROM student
JOIN takes
ON student.ID = takes.ID;

이 경우 양쪽 테이블에서 ID가 일치하는 행만 결과로 나온다.

즉, 매칭되지 않는 튜플은 버려진다.

6. 외부 조인(OUTER JOIN)

외부 조인은 매칭되지 않는 튜플도 결과에 보존하는 조인이다.
일치하지 않는 쪽은 NULL로 채운다.

이게 내부 조인과 가장 큰 차이다.

LEFT OUTER JOIN

왼쪽 릴레이션의 모든 튜플을 유지한다.

SELECT *
FROM student
LEFT OUTER JOIN takes
ON student.ID = takes.ID;

이 경우 수강 정보가 없는 학생도 결과에 나타난다.
단, takes 쪽 컬럼은 NULL이 된다.

RIGHT OUTER JOIN

오른쪽 릴레이션의 모든 튜플을 유지한다.

FULL OUTER JOIN

양쪽 릴레이션에서 매칭되지 않은 튜플도 전부 보존한다.

즉,

왼쪽에만 있는 것
오른쪽에만 있는 것
둘 다 결과에 남는다.

LEFT OUTER JOIN vs NATURAL LEFT OUTER JOIN

구분LEFT OUTER JOINNATURAL LEFT OUTER JOIN

조인 조건	ON 또는 USING으로 직접 지정	같은 이름 속성 자동 매칭
결과 컬럼	중복 속성 남을 수 있음	공통 속성 하나로 합쳐짐
제어 가능성	높음	낮음
안전성	더 안전	자동 매칭이라 주의 필요

정리하면,
NATURAL JOIN 계열은 편하지만 위험하고,
보통은 LEFT OUTER JOIN ... ON ... 형태를 더 많이 쓴다.

7. 조인 종류와 조인 조건은 다르다

이건 은근 많이 헷갈린다.

조인 종류(Join Type)

매칭되지 않는 튜플을 어떻게 처리할지 결정한다.

예:

INNER
LEFT OUTER
RIGHT OUTER
FULL OUTER

조인 조건(Join Condition)

어떤 튜플끼리 매칭할지 결정한다.

예:

NATURAL
USING
ON

즉,

종류 = 안 맞는 행을 버릴지 살릴지
조건 = 어떤 기준으로 연결할지

라고 이해하면 된다.

8. 뷰(View)란?

뷰는 기본 테이블이나 다른 뷰로부터 파생된 가상 릴레이션이다.

쉽게 말하면,
복잡한 SELECT 문에 이름을 붙여서 테이블처럼 사용하는 것이다.

뷰의 특징

실제 데이터를 따로 저장하지 않음
질의 시점에 기본 테이블을 바탕으로 계산됨
복잡한 질의를 단순화할 수 있음
보안 목적으로도 유용함

예:

CREATE VIEW geo_instructor AS
SELECT *
FROM instructor
WHERE dept_name = 'Geology';

이제 geo_instructor를 테이블처럼 사용할 수 있다.

9. 뷰 정의할 때 중요한 점

뷰를 정의한다고 해서 결과가 즉시 테이블처럼 저장되는 건 아니다.

이거 진짜 중요하다.

즉,

CREATE VIEW ...

는 “결과를 저장”하는 게 아니라
SQL 표현식을 저장하는 것에 가깝다.

필요할 때마다 그 정의를 이용해서 결과를 계산한다.

뷰 제거

DROP VIEW view_name;

10. 뷰의 장점

1) 복잡한 질의 단순화

긴 조인 쿼리를 뷰로 만들어 두면 이후엔 짧게 쓸 수 있다.

2) 보안

사용자에게 전체 테이블을 공개하지 않고 필요한 열/행만 보이게 할 수 있다.

3) 논리적 독립성

사용자 입장에서는 복잡한 내부 구조를 몰라도 된다.

11. 갱신 가능한 뷰 / 불가능한 뷰

모든 뷰가 INSERT, UPDATE, DELETE 가능한 건 아니다.

일반적으로 갱신 불가능한 뷰

다음 요소가 들어가면 보통 갱신이 어렵다.

집계 함수 (AVG, SUM 등)
GROUP BY
DISTINCT
여러 테이블 조인
계산식이 많이 포함된 경우

예를 들어 평균 급여를 보여주는 뷰에 값을 삽입하는 건 애초에 의미가 모호하다.

갱신 가능한 뷰의 조건

보통 다음 조건을 만족해야 비교적 갱신 가능하다.

SELECT 절에 단순한 속성 이름만 있음
FROM 절에 릴레이션 하나만 있음
GROUP BY, HAVING 없음
생략된 속성이 NULL 허용 또는 DEFAULT 가능해야 함

즉, “거의 기본 테이블처럼 보이는 단순 뷰”여야 한다.

12. WITH CHECK OPTION

이 옵션은 뷰를 통해 삽입/수정되는 데이터가
그 뷰의 조건을 반드시 만족하도록 강제한다.

예:

CREATE VIEW dept_instructor AS
SELECT *
FROM instructor
WHERE dept_name = 'Comp. Sci.'
WITH CHECK OPTION;

이제 이 뷰를 통해 데이터를 넣거나 수정할 때는
반드시 dept_name = 'Comp. Sci.' 조건을 만족해야 한다.

이 옵션이 없으면
뷰를 통해 수정한 결과가 오히려 뷰에서 안 보이는 이상한 상황이 생길 수 있다.

13. 뷰 갱신에서 생기는 문제

예를 들어 이런 뷰가 있다고 하자.

CREATE VIEW instructor_info AS
SELECT id, name, building
FROM instructor I, department D
WHERE I.dept_name = D.dept_name;

여기에

INSERT INTO instructor_info VALUES ('67787', 'Amy', '1공학관');

를 하면 문제가 생긴다.

왜냐면 뷰에는 dept_name이 없어서,
실제 기본 테이블에 어떻게 넣어야 할지 정보가 부족하기 때문이다.

발생 가능한 문제

삽입된 튜플이 조인 조건을 만족하지 않아 뷰 결과에 안 보일 수 있음
기본 테이블의 필수 속성이나 기본키가 NULL이 되어 삽입 불가능할 수 있음

즉, 조인 뷰는 갱신이 특히 까다롭다.

14. 실체화 뷰(Materialized View)

일반 뷰는 결과를 매번 계산하지만,
실체화 뷰는 결과를 실제로 저장한다.

장점

조회 속도가 빠름
복잡한 집계나 분석 쿼리에 유리

단점

저장 공간 필요
원본 데이터 변경 시 최신 상태 유지 필요
갱신 비용 발생

즉, 속도와 저장/유지 비용의 트레이드오프가 있다.

15. 무결성 제약조건이란

무결성 제약조건은 잘못된 데이터가 들어오는 걸 막는 규칙이다.

데이터베이스는 한 번 이상한 값이 들어가면
그 뒤로 모든 질의 결과가 오염될 수 있다.
그래서 제약조건은 진짜 중요하다.

16. 단일 릴레이션 제약조건

NOT NULL

해당 속성에 NULL을 허용하지 않는다.

PRIMARY KEY

기본키를 지정한다.
자동으로 유일성과 NOT NULL 성질을 가진다.

UNIQUE

중복을 허용하지 않는다.
다만 SQL에서는 NULL 처리 방식이 DBMS마다 약간 다를 수 있는데,
보통 여러 NULL을 허용하는 경우가 많다.

CHECK (조건)

속성 값 범위를 제한한다.

예:

CREATE TABLE section2(
 semester varchar(6),
 CHECK (semester IN ('Fall','Winter','Spring','Summer'))
);

또는

salary numeric(8,2) CHECK (salary > 29000)

이런 식으로 사용한다.

17. 참조 무결성 제약조건

참조 무결성은 외래키 값이 반드시 다른 릴레이션의 기본키와 일치해야 한다는 규칙이다.

예:

CREATE TABLE instructor(
 dept_name varchar(20),
 FOREIGN KEY (dept_name) REFERENCES department(dept_name)
);

이제 instructor.dept_name에는
반드시 department에 존재하는 학과명만 들어갈 수 있다.

외래키 옵션 정리

옵션 의미

ON DELETE CASCADE	부모 삭제 시 자식도 같이 삭제
ON DELETE SET NULL	부모 삭제 시 자식 외래키를 NULL로 변경
ON DELETE SET DEFAULT	부모 삭제 시 자식 외래키를 기본값으로 변경
ON UPDATE CASCADE	부모 값 변경 시 자식도 자동 반영
ON UPDATE NO ACTION	부모 값 변경을 막음

실무에서는 특히 CASCADE를 쓸 때 조심해야 한다.
잘못하면 연쇄 삭제가 발생할 수 있다.

18. SQL 날짜/시간 타입

SQL에는 날짜와 시간을 다루는 타입도 있다.

타입예시설명

DATE	'2005-07-27'	연/월/일
TIME	'09:00:30.75'	시/분/초
TIMESTAMP	'2005-07-27 09:00:30.75'	날짜 + 시간
INTERVAL	'1 day'	시간 간격

이 타입들은 예약 시스템, 로그 저장, 기간 계산 같은 데서 많이 쓴다.

19. 대형 객체 타입 (LOB)

대용량 데이터를 저장할 때는 LOB 타입을 쓴다.

BLOB

Binary Large Object
이미지, 영상, 바이너리 데이터 저장

CLOB

Character Large Object
문서, 긴 텍스트 저장

실제로는 대형 데이터를 DB 자체에 전부 넣기보다
참조 포인터나 파일 경로처럼 관리하는 방식도 많이 쓴다.

20. 사용자 정의 타입과 도메인

CREATE TYPE

사용자 정의 복합 타입을 만들 수 있다.

예:

CREATE TYPE Dollars AS (
 dollars numeric(12,2)
);

이후 테이블에서 사용할 수 있다.

CREATE TABLE department(
 dept_name varchar(20),
 budget Dollars
);

CREATE DOMAIN

도메인은 기존 타입에 제약조건을 붙인 재사용 가능한 타입이라고 생각하면 된다.

예:

CREATE DOMAIN degree_level varchar(10)
 CONSTRAINT degree_level_test
 CHECK (VALUE IN ('Bachelors', 'Masters', 'Doctorate'));

이렇게 만들어두면 여러 테이블에서 일관되게 재사용할 수 있다.

타입 vs 도메인 차이

TYPE: 구조 자체를 새로 정의
DOMAIN: 기존 타입 + 제약조건 재사용

이렇게 구분하면 된다.

21. 인덱스(Index)란

인덱스는 검색을 빠르게 하기 위한 자료구조다.

쉽게 말하면 책 뒤의 색인 같은 느낌이다.
본문을 처음부터 끝까지 다 안 읽고도 원하는 내용을 빨리 찾을 수 있게 해준다.

인덱스의 핵심

속성값과 해당 튜플 위치를 저장
특정 조건 검색 속도 향상
한 번 만들면 같은 조건의 질의에 반복적으로 도움됨

예:

CREATE INDEX dept_index
ON instructor(dept_name, salary);

왜 그냥 테이블을 정렬해두면 안 될까?

이 질문도 자주 나온다.

예를 들어 테이블을 dept_name 기준으로 정렬하면
다른 속성 기준 정렬은 깨진다.

즉,

하나의 정렬 상태로 모든 검색을 빠르게 만들 수는 없음
그래서 검색이 자주 발생하는 속성마다 인덱스를 따로 둔다

인덱스의 단점도 있다

저장 공간 추가 필요
INSERT, UPDATE, DELETE 때 인덱스도 함께 갱신해야 해서 쓰기 비용 증가

즉, 조회는 빨라지지만 갱신은 더 무거워질 수 있다.

22. 권한(Authorization)

DB에서는 모든 사용자가 모든 데이터를 다 만지면 안 된다.
그래서 권한 관리가 필요하다.

기본 권한 종류

권한설명

SELECT	조회
INSERT	삽입
UPDATE	수정
DELETE	삭제
ALL PRIVILEGES	모든 권한

예:

GRANT SELECT ON department TO amit, satoshi;
GRANT UPDATE (budget) ON department TO amit, satoshi;

특정 컬럼에 대해서만 권한을 줄 수도 있다.

권한 회수는 이렇게 한다.

REVOKE SELECT ON department FROM amit, satoshi;
REVOKE UPDATE (budget) ON department FROM amit, satoshi;

23. ROLE이란

ROLE은 권한 묶음이라고 보면 된다.

사용자마다 권한을 하나하나 주는 대신,
역할을 만들고 거기에 권한을 준 다음 사용자를 그 역할에 넣는 방식이다.

예:

CREATE ROLE instructor;
GRANT instructor TO amit;

CREATE ROLE teaching_assistant;
GRANT teaching_assistant TO instructor;
GRANT SELECT ON takes TO instructor;

이렇게 하면 권한 관리가 훨씬 편해진다.

24. 뷰에 대한 권한

뷰는 보안 목적으로 정말 유용하다.

예:

CREATE VIEW geo_instructor AS
SELECT * FROM instructor WHERE dept_name = 'Geology';

GRANT SELECT ON geo_instructor TO geo_staff;

이 경우 geo_staff는 원본 instructor 전체를 볼 필요 없이
뷰를 통해 필요한 데이터만 조회할 수 있다.

중요한 포인트

뷰를 만든 사용자는 원본 테이블 접근 권한이 있어야 함
뷰를 사용하는 사람은 원본 테이블 권한이 없어도,
뷰에 대한 권한만 있으면 사용할 수 있는 경우가 많음

즉, 뷰는 보안 필터 역할도 할 수 있다.

25. USAGE, SELECT, CREATE 헷갈리는 이유 정리

이 부분은 진짜 많이 헷갈린다.

권한은 대상 객체가 무엇인지에 따라 이름이 다르다.

대상가능한 권한

TABLE / VIEW	SELECT, INSERT, UPDATE, DELETE
SCHEMA	USAGE, CREATE
DATABASE	CONNECT, CREATE, TEMP
FUNCTION / SEQUENCE	EXECUTE, USAGE

GRANT SELECT ON mini_user TO maker;

대상: 테이블
의미: mini_user 데이터를 조회할 수 있음

GRANT USAGE ON SCHEMA public TO maker;

대상: 스키마
의미: public이라는 공간 안의 객체를 인식하고 접근할 수 있음

비유하면 이렇다.

스키마 = 폴더
테이블 = 파일
USAGE = 폴더에 들어갈 권한
SELECT = 파일 내용 읽기 권한
CREATE = 폴더 안에 새 파일 만들기 권한

즉, 어떤 사용자가 public 안에서 뷰를 만들고 테이블을 읽으려면 보통

USAGE ON SCHEMA
CREATE ON SCHEMA
테이블에 대한 SELECT

이 조합이 필요하다.

26. 핵심 요약

이번 4장의 핵심만 다시 정리하면 이렇다.

조인은 두 릴레이션을 조건에 따라 결합하는 연산이다.
NATURAL JOIN은 편하지만, 동명이 속성을 자동 매칭해서 위험할 수 있다.
실무에서는 보통 JOIN ... ON ... 을 더 많이 쓴다.
INNER JOIN은 매칭된 튜플만, OUTER JOIN은 매칭되지 않은 튜플도 보존한다.
뷰(View) 는 가상 릴레이션으로, 복잡한 질의 단순화와 보안에 유용하다.
모든 뷰가 갱신 가능한 건 아니며, 특히 조인/집계 뷰는 갱신이 어렵다.
WITH CHECK OPTION은 뷰 조건을 만족하는 데이터만 삽입/수정하게 한다.
제약조건에는 NOT NULL, PRIMARY KEY, UNIQUE, CHECK, FOREIGN KEY 등이 있다.
인덱스는 조회 속도를 높여주지만 갱신 비용도 늘린다.
권한 관리는 GRANT, REVOKE, ROLE을 중심으로 이해하면 된다.

마무리

4장은 내용이 많아서 처음 보면 좀 산만하게 느껴질 수 있는데, 큰 흐름은 이렇다.

조인으로 여러 테이블을 연결하고
뷰로 복잡한 질의를 감추고
제약조건으로 이상한 데이터 입력을 막고
인덱스로 조회 성능을 높이고
권한 관리로 보안을 지킨다

4장은 “데이터베이스를 실제로 운영하려면 필요한 기능들”을 한 번에 모아놓은 느낌이다.

여기까지 이해하면 이제 SQL이 단순 조회 언어가 아니라 구조, 성능, 무결성, 보안까지 다루는 언어라는 게 확실히 보이기 시작한다.

[데이터베이스 시스템 7판 3장] SQL 타입, 제약조건, 하위 질의(Subquery) 완벽 정리 | IN, EXISTS, WITH까지 이해하기

데구르르.. — Thu, 12 Mar 2026 02:29:33 +0900

1. SQL 언어 구성

SQL은 단순히 데이터를 조회하는 언어가 아니라
데이터베이스 전체를 관리하는 언어다.

보통 SQL 기능은 다음 네 가지로 나눠서 이해한다.

1️⃣ DDL (Data Definition Language)

데이터베이스 구조를 정의하는 언어다.

대표 명령어

CREATE
ALTER
DROP

DDL은 다음 작업을 수행한다.

스키마 정의
테이블 생성
무결성 제약조건 정의
뷰(View) 정의
권한 관리

예:

CREATE TABLE student(
id INT PRIMARY KEY,
name VARCHAR(20)
);

2️⃣ DML (Data Manipulation Language)

데이터를 조회, 수정, 삽입, 삭제하는 언어다.

대표 명령어

SELECT
INSERT
UPDATE
DELETE

예:

SELECT * FROM student;

3️⃣ 트랜잭션 제어

데이터 변경 작업을 원자적으로 처리하기 위해 사용한다.

대표 명령어

COMMIT
ROLLBACK
BEGIN

예:

BEGIN;
UPDATE account SET balance = balance - 100;
COMMIT;

4️⃣ Embedded SQL

SQL을 프로그래밍 언어 안에 포함해서 사용하는 방식이다.

예

Java + JDBC
Python + psycopg2
C + Embedded SQL

즉 SQL을 프로그램 로직 안에서 실행하는 구조다.

2. SQL 기본 데이터 타입

SQL에서는 다양한 데이터 타입을 제공한다.

문자열 타입

char(n)

고정 길이 문자열이다.

char(10)

항상 10자리 공간을 사용
부족하면 공백으로 채움

varchar(n)

가변 길이 문자열이다.

varchar(20)

최대 20자
실제 저장 길이는 문자열 길이만큼

실무에서는 대부분 varchar를 많이 사용한다.

숫자 타입

int

정수 타입

예

age INT

smallint

작은 범위 정수

메모리를 조금 더 절약할 수 있다.

numeric(p, d)

고정 소수점 숫자다.

p : 전체 자릿수
d : 소수점 자릿수

예

numeric(8,2)

가능 값

123456.78

금액 계산 같은 정확한 계산이 필요한 경우 사용한다.

real

부동소수점 숫자

약 7자리 정밀도

double precision

더 높은 정밀도 부동소수점

약 15~17자리

과학 계산 등에서 사용한다.

float(n)

정밀도를 지정하는 부동소수점 타입이다.

3. SQL 제약조건 (Integrity Constraints)

제약조건은 데이터의 무결성을 보장하기 위해 사용한다.

대표적인 제약조건은 다음과 같다.

NOT NULL

속성이 NULL 값을 가질 수 없도록 제한한다.

name varchar(20) NOT NULL

CHECK

속성 값의 범위를 제한한다.

CHECK (salary > 0)

예

age INT CHECK(age >= 0)

PRIMARY KEY

테이블의 기본 키를 정의한다.

특징

중복 불가
NULL 불가

예

PRIMARY KEY(id)

복합 키도 가능하다.

PRIMARY KEY(student_id, course_id)

FOREIGN KEY

다른 테이블의 기본 키를 참조한다.

예

FOREIGN KEY(dept_name)
REFERENCES department

외래키는

NULL 가능
중복 가능

하지만 반드시 참조 테이블에 존재하는 값이어야 한다.

4. 하위 질의 (Subquery)

하위 질의는 SQL 안에 들어가는 또 다른 SELECT문이다.

즉

SELECT 안에 SELECT

구조라고 보면 된다.

예

SELECT name
FROM instructor
WHERE salary >
 (SELECT avg(salary) FROM instructor);

이 쿼리는

평균 급여보다 높은 교수를 찾는다.

하위 질의가 들어갈 수 있는 위치

SELECT

SELECT name,
 (SELECT avg(salary) FROM instructor)
FROM instructor;

FROM

SELECT *
FROM (
 SELECT dept_name, avg(salary)
 FROM instructor
 GROUP BY dept_name
) AS dept_avg;

WHERE

SELECT name
FROM instructor
WHERE dept_name IN
 (SELECT dept_name FROM department);

5. IN / NOT IN

IN

값이 집합에 존재하는지 확인한다.

SELECT name
FROM instructor
WHERE dept_name IN
 (SELECT dept_name FROM department);

NOT IN

집합에 존재하지 않는 값을 찾는다.

WHERE dept_name NOT IN
 (SELECT dept_name FROM department);

주의할 점

NOT IN은 NULL이 포함되면 결과가 예상과 다르게 나올 수 있다.

그래서 실무에서는 보통

NOT EXISTS

를 더 많이 사용한다.

6. ANY / SOME / ALL 비교

이 부분은 노트에 조금 부족해서 보완한다.

SOME / ANY

둘은 같은 의미다.

= SOME
= ANY

즉

집합 안에 하나라도 만족하면 TRUE

예

salary > ANY
 (SELECT salary FROM instructor);

ALL

집합의 모든 값과 비교한다.

예

salary > ALL
 (SELECT salary FROM instructor);

의미

모든 교수보다 급여가 높은 사람

중요한 비교

표현의미

= ANY	IN
≠ ALL	NOT IN

7. EXISTS / NOT EXISTS

EXISTS

하위 질의 결과가 비어있지 않으면 TRUE

예

SELECT name
FROM instructor i
WHERE EXISTS (
 SELECT *
 FROM teaches t
 WHERE i.id = t.id
);

즉

강의를 하는 교수만 조회

NOT EXISTS

하위 질의 결과가 비어 있으면 TRUE

예

SELECT name
FROM instructor i
WHERE NOT EXISTS (
 SELECT *
 FROM teaches t
 WHERE i.id = t.id
);

즉

강의를 하지 않는 교수

8. FROM 절 하위 질의

FROM 절에서 하위 질의를 쓰면
임시 테이블처럼 사용할 수 있다.

예

SELECT *
FROM (
 SELECT dept_name, avg(salary)
 FROM instructor
 GROUP BY dept_name
) AS dept_avg;

이때 반드시 별칭(alias) 을 줘야 한다.

9. WITH 절 (CTE)

WITH 절은 임시 릴레이션을 정의하는 기능이다.

Common Table Expression이라고 부른다.

예

WITH dept_avg AS (
 SELECT dept_name, avg(salary) AS avg_salary
 FROM instructor
 GROUP BY dept_name
)
SELECT *
FROM dept_avg
WHERE avg_salary > 50000;

장점

복잡한 쿼리 가독성 개선
재사용 가능
단계적 질의 작성 가능

요즘 SQL에서는 WITH 절 사용이 매우 흔하다.

10. 스칼라 하위 질의

스칼라 하위 질의는 단일 값만 반환하는 하위 질의다.

즉

하나의 튜플
하나의 속성

만 반환해야 한다.

예

SELECT name
FROM instructor
WHERE salary >
 (SELECT avg(salary) FROM instructor);

여기서

avg(salary)

결과는 하나의 값이다.

그래서 스칼라 하위 질의가 된다.

주의

하위 질의가 여러 튜플을 반환하면 오류가 발생한다.

예

SELECT name
FROM instructor
WHERE salary =
 (SELECT salary FROM instructor);

이 경우 여러 결과가 나오기 때문에 런타임 오류가 발생한다.

핵심 정리

SQL은 DDL, DML, 트랜잭션 제어 기능을 가진다.
SQL에는 문자열, 정수, 부동소수점, 고정소수점 타입이 있다.
제약조건은 NOT NULL, CHECK, PRIMARY KEY, FOREIGN KEY 등이 있다.
Subquery는 SQL 안에 들어가는 SELECT문이다.
하위 질의는 SELECT, FROM, WHERE에 사용 가능하다.
IN, EXISTS, ANY, ALL은 집합 비교 연산이다.
WITH 절은 임시 테이블(CTE)을 만드는 기능이다.
스칼라 하위 질의는 반드시 단일 값만 반환해야 한다.

[데이터베이스 시스템 7판 2장] 관계형 데이터베이스 구조 정리 | 릴레이션, 키, 관계대수, 무결성까지 한 번에 이해하기

데구르르.. — Thu, 12 Mar 2026 02:21:37 +0900

1. 관계형 데이터베이스의 기본 구조

관계형 데이터베이스는 데이터를 테이블 형태로 저장하는 방식이다.
우리가 흔히 보는 행과 열 구조가 바로 관계형 모델의 핵심이다.

여기서 중요한 용어 몇 개를 먼저 정리하고 가면 이해가 훨씬 쉬워진다.

릴레이션(Relation): 튜플들의 집합
튜플(Tuple): 하나의 행(row), 즉 속성값들의 집합
속성(Attribute): 열(column), 각 데이터 항목의 이름
도메인(Domain): 각 속성이 가질 수 있는 허용된 값의 집합

예를 들어 학생 테이블이 있다고 해보자.

학번 이름 학과

2024001	김민수	컴퓨터학과
2024002	이서연	경영학과

여기서

테이블 전체는 릴레이션
각 행은 튜플
학번, 이름, 학과는 속성
학과 속성에 들어갈 수 있는 값들의 범위는 도메인

이라고 보면 된다.

2. 릴레이션 스키마와 릴레이션 인스턴스

이 부분은 ch.1의 스키마 / 인스턴스 개념이 그대로 이어진다.

릴레이션 스키마(Relation Schema)

릴레이션의 구조를 정의하는 틀이다.
즉, 테이블 이름, 속성 이름, 타입, 도메인 등을 정의한 설계도라고 보면 된다.

예:

student(s_id, name, dept_name)

이건 student 테이블이 어떤 속성들로 구성되는지 보여주는 스키마다.

릴레이션 인스턴스(Relation Instance)

어느 시점에 실제로 테이블 안에 들어 있는 튜플들의 집합이다.

즉,

스키마 = 구조
인스턴스 = 실제 데이터

이렇게 구분하면 된다.

3. 속성, 튜플, 도메인 개념 정리

속성(Attribute)

테이블의 열(column)이다.
데이터의 한 항목을 의미한다.

예:

학번
이름
전화번호
학과명

속성의 개수를 degree(차수) 라고도 부른다.

예를 들어 속성이 4개면 그 릴레이션의 차수는 4다.

튜플(Tuple)

테이블의 한 행(row)이다.
하나의 데이터 레코드라고 생각하면 된다.

튜플 수는 cardinality(기수) 라고 한다.

즉,

차수(degree) = 열 개수
기수(cardinality) = 행 개수

이 둘은 자주 헷갈리니까 구분해두는 게 좋다.

도메인(Domain)

각 속성이 가질 수 있는 허용된 값의 범위다.

예를 들어 나이 속성의 도메인은 정수일 수 있고,
학년 속성의 도메인은 1, 2, 3, 4처럼 제한될 수도 있다.

관계형 모델에서는 일반적으로 각 속성의 값이 원자적(atomic) 이어야 한다.
즉, 더 이상 쪼갤 수 없는 단일 값이어야 한다는 뜻이다.

예를 들어 전화번호 속성에 여러 개 번호를 한 번에 넣는 건 관계형 모델 관점에서는 적절하지 않다.

NULL 값

NULL은 그냥 빈 값이 아니라,

아직 모르는 값
존재하지 않는 값

을 나타내는 특별한 값이다.

예를 들어 학생의 연락처가 아직 등록되지 않았다면 NULL이 들어갈 수 있다.

4. 키의 종류 정리

관계형 데이터베이스에서는 각 튜플을 구분하고, 테이블 사이 관계를 맺기 위해 키(Key) 개념이 매우 중요하다.

1) 슈퍼키(Super Key)

튜플을 유일하게 식별할 수 있는 속성들의 집합이다.

단, 꼭 최소일 필요는 없다.
즉, 필요 없는 속성이 더 들어가 있어도 유일성만 만족하면 슈퍼키다.

예를 들어 학생 테이블이 있고 속성이 다음과 같다고 해보자.

학번
이름
전화번호

이때 가능한 슈퍼키 예시는:

{학번}
{학번, 이름}
{학번, 전화번호}
{학번, 이름, 전화번호}

이처럼 유일성만 만족하면 다 슈퍼키다.

2) 후보키(Candidate Key)

슈퍼키 중에서 최소성까지 만족하는 키다.

즉,

유일해야 하고
불필요한 속성이 없어야 한다

예를 들어 학생 테이블에서

{학번}
{전화번호}

둘 다 각 학생을 유일하게 구분할 수 있다면 둘 다 후보키가 될 수 있다.

3) 기본키(Primary Key)

후보키 중에서 대표로 선택된 키다.

기본키는 다음 조건을 만족해야 한다.

중복 불가
NULL 불가

그래서 보통 NOT NULL 과 UNIQUE 성격을 함께 가진다.

기본키를 정할 때는 보통 이런 기준을 고려한다.

값이 잘 바뀌지 않는가
단순한가
짧고 관리하기 쉬운가

4) 외래키(Foreign Key)

한 테이블에서 다른 테이블의 키를 참조하는 속성이다.

쉽게 말하면 테이블과 테이블을 연결하는 다리 같은 역할이다.

예를 들어 학생 테이블에 학과명이 있고,
학과 테이블에 학과명이 기본키라면 학생 테이블의 학과명은 학과 테이블을 참조하는 외래키가 될 수 있다.

외래키의 특징은 이렇다.

중복 가능
NULL 가능
반드시 참조 대상 테이블에 존재하는 값이어야 함

즉, 부모 테이블에 없는 값을 자식 테이블에서 마음대로 넣으면 안 된다.

5) 대체키(Alternate Key)

후보키 중에서 기본키로 선택되지 않은 나머지 키를 말한다.

예를 들어 후보키가 {학번}, {전화번호} 두 개이고,
기본키를 {학번}으로 골랐다면 {전화번호}는 대체키가 된다.

5. 관계대수(Relational Algebra)란?

관계대수는 관계형 데이터베이스에서 데이터를 질의하는 형식적 연산 체계다.

쉽게 말하면,
“테이블에서 원하는 데이터를 어떻게 뽑아낼지”를 수학적으로 표현한 방식이다.

관계대수는 절차적 질의어에 가깝다.
즉, 어떤 데이터를 얻을지뿐 아니라 어떻게 얻는지도 표현한다.

SQL을 배우기 전에 관계대수를 배우는 이유는,
관계형 데이터베이스가 내부적으로 어떤 방식으로 연산을 생각하는지 이해하는 데 도움이 되기 때문이다.

6. 기본 관계 연산자

관계대수의 기본 연산자는 크게 단항 연산과 이항 연산으로 나뉜다.

단항 연산

하나의 릴레이션에 대해 수행하는 연산이다.

1) 선택(Select, σ)

조건을 만족하는 튜플만 골라낸다.
SQL의 WHERE와 비슷하다.

예:

급여가 50000 이상인 교수만 선택

즉, 행을 고르는 연산이라고 생각하면 된다.

2) 추출(Project, π)

원하는 속성만 뽑아낸다.
SQL의 SELECT 컬럼명과 비슷하다.

예:

교수 테이블에서 이름과 학과만 추출

즉, 열을 고르는 연산이다.

3) 재명명(Rename, ρ)

릴레이션이나 속성 이름을 임시로 바꾼다.

이 연산은 특히 같은 테이블을 두 번 비교할 때 중요하다.
즉, 셀프 조인 같은 상황에서 많이 쓴다.

같은 테이블끼리 비교하는 이유: 셀프 조인 아이디어

예를 들어 “가장 높은 연봉을 받는 교수”를 찾고 싶다고 해보자.

이럴 때 한 테이블 안의 데이터를 그 테이블 자체와 비교해야 한다.
그래서 같은 릴레이션을 하나 더 복사한 것처럼 재명명해서 사용한다.

과정은 이렇게 이해하면 된다.

instructor를 하나 더 만들어 d라고 이름 붙인다.
instructor × d 로 모든 교수-교수 조합을 만든다.
instructor.salary < d.salary 조건을 만족하는 경우를 찾는다.
그러면 “자신보다 더 높은 연봉을 가진 사람이 있는 교수”가 나온다.
이들을 전체 교수 목록에서 빼면, 최종적으로 최고 연봉자만 남는다.

이 예시는 관계대수에서 카티션 곱 + 선택 + 차집합이 어떻게 결합되는지 보여줘서 꽤 중요하다.

이항 연산

두 개의 릴레이션을 대상으로 수행하는 연산이다.

1) 합집합(Union, ∪)

두 릴레이션의 결과를 합친다.

단, 합집합을 하려면 두 릴레이션의 구조가 호환되어야 한다.
즉, 속성 개수와 타입이 맞아야 한다.

2) 차집합(Set Difference, -)

한 릴레이션에는 있고 다른 릴레이션에는 없는 튜플만 남긴다.

3) 카티션 곱(Cartesian Product, ×)

두 릴레이션의 모든 튜플 조합을 만든다.

예를 들어 A에 3개 행, B에 4개 행이 있으면
A × B 결과는 12개 행이 된다.

카티션 곱 자체만 단독으로 쓰기보다는,
보통 이후에 선택 조건을 걸어서 조인처럼 활용하는 경우가 많다.

7. 확장 관계 연산자와 조인

기본 연산 외에도 자주 쓰는 확장 연산이 있다.

1) 배정(Assignment, ←)

중간 결과를 변수처럼 저장해서 다음 연산에 활용할 때 쓴다.

복잡한 관계대수 식을 단계별로 표현할 때 유용하다.

2) 교집합(Intersection, ∩)

두 릴레이션에 공통으로 포함된 튜플만 남긴다.

3) 조인(Join)

관계형 데이터베이스에서 제일 중요한 연산 중 하나다.
서로 관련 있는 두 테이블을 연결해서 새로운 결과를 만든다.

자연 조인(Natural Join, ⨝)

이름이 같은 속성을 기준으로 자동으로 조인한다.

장점은 간단하다는 거지만,
원하지 않는 같은 이름의 속성까지 기준으로 잡힐 수 있어서 조심해야 한다.

세타 조인(Theta Join, ⨝θ)

조건을 명시해서 조인하는 방식이다.

예를 들어

student.dept_name = department.dept_name
같은 조건을 직접 줘서 조인한다.

세타 조인에서 조건이 = 인 경우를 동등 조인(Equal Join) 이라고 한다.

외부 조인(Outer Join)

일치하는 값이 없어도 한쪽 테이블의 튜플을 유지하고 싶을 때 사용한다.

종류는 다음과 같다.

왼쪽 외부 조인(Left Outer Join, ⟕)
왼쪽 릴레이션의 모든 튜플 유지
오른쪽 외부 조인(Right Outer Join, ⟖)
오른쪽 릴레이션의 모든 튜플 유지
전체 외부 조인(Full Outer Join, ⟗)
양쪽 릴레이션의 모든 튜플 유지

이건 SQL의 LEFT OUTER JOIN, RIGHT OUTER JOIN, FULL OUTER JOIN과 연결해서 이해하면 된다.

8. 관계 해석(Relational Calculus)

노트에 짧게 정리된 부분인데, 개념만 같이 잡고 가면 좋다.

관계 해석은 관계대수와 달리 선언형 질의어다.
즉, 결과로 무엇을 원하는지를 표현하는 방식이다.

종류는 두 가지다.

튜플 관계 해석
도메인 관계 해석

관계대수는 “어떻게 구할지”에 초점이 있고,
관계 해석은 “무엇을 구할지”에 초점이 있다고 보면 된다.

SQL은 완전히 관계대수도 아니고 완전히 관계해석도 아니지만,
전체적으로는 선언형 질의어에 더 가깝다.

9. 무결성과 제약조건

데이터베이스에서 무결성은
데이터가 정확하고 일관되게 유지되는 성질을 의미한다.

아무 값이나 막 들어가면 데이터베이스는 금방 망가진다.
그래서 제약조건을 통해 데이터를 보호해야 한다.

1) 개체 무결성(Entity Integrity)

기본키는 각 행을 유일하게 식별해야 하므로

중복되면 안 되고
NULL이면 안 된다

즉, 기본키의 무결성을 보장하는 규칙이다.

2) 참조 무결성(Referential Integrity)

외래키는 반드시 참조 대상 테이블에 존재하는 값을 가져야 한다.

예를 들어 학생 테이블에 없는 학과를 참조하면 안 된다.

즉,

존재하지 않는 부모 키를 참조하면 안 됨
테이블 간 관계가 일관되게 유지되어야 함

3) 도메인 무결성(Domain Integrity)

각 속성은 자신의 도메인에 맞는 값만 가져야 한다.

예를 들어:

학점에 문자 넣으면 안 됨
주민번호 자리에 알파벳 넣으면 안 됨
나이는 음수가 되면 안 됨

이런 규칙은 CHECK, 타입 제한 등으로 보장할 수 있다.

외래키 제약조건에서 중요한 점

외래키는 단순히 “참조한다”로 끝나는 게 아니라,
부모 테이블과 자식 테이블의 변화에 따라 제약이 생긴다.

1) 삽입 / 수정 제한

부모 테이블에 없는 값을 외래키로 넣을 수 없다.

2) 삭제 제한

부모 테이블의 행을 삭제하려면
자식 테이블에서 그 값을 참조하고 있는 행도 함께 고려해야 한다.

3) ON DELETE / ON UPDATE 옵션

부모 값이 삭제되거나 수정될 때 자식 쪽을 어떻게 처리할지 정할 수 있다.

예:

CASCADE
SET NULL
RESTRICT

이 부분은 실제 SQL에서 외래키 제약조건 설정할 때 굉장히 중요하다.

10. 문제로 다시 보는 핵심 포인트

릴레이션 인스턴스 vs 릴레이션 스키마

이 둘은 꼭 구분해야 한다.

릴레이션 스키마: 속성 이름, 타입, 도메인을 정의한 구조
릴레이션 인스턴스: 실제 시점의 데이터 집합

즉, 설계도와 실제 데이터의 차이다.

주 키는 왜 중요한가?

주 키는 각 튜플을 유일하게 식별해야 하므로
중복되거나 NULL이면 안 된다.

그래서 다음 같은 경우는 허용되지 않는다.

주 키 값이 중복되는 경우
속성 도메인에 없는 값이 들어가는 경우

advisor 릴레이션 예시

s_id만으로 advisor 릴레이션의 기본키가 될 수 있는지 생각해보면,

답은 안 된다.

왜냐하면 한 학생이 여러 지도교수를 가질 수 있기 때문이다.

예:

s_id i_id

1001	2001
1001	2002

이 경우 s_id만으로는 유일성을 보장하지 못한다.
그래서 기본키는 보통 {s_id, i_id} 같은 복합키가 된다.

이 예시는 “유일성”이 실제로 어떤 뜻인지 이해하는 데 꽤 좋다.

11. 핵심 요약

이번 챕터 핵심만 다시 정리하면 이렇다.

릴레이션은 튜플의 집합이고, 튜플은 하나의 행이다.
속성은 열이고, 각 속성은 자신만의 도메인을 가진다.
릴레이션 스키마는 구조, 릴레이션 인스턴스는 실제 데이터다.
슈퍼키는 유일성만 만족, 후보키는 유일성과 최소성 모두 만족한다.
기본키는 후보키 중 대표 키, 외래키는 다른 테이블을 참조하는 키다.
관계대수의 기본 연산은 선택, 추출, 재명명, 합집합, 차집합, 카티션 곱이다.
조인은 관계형 데이터베이스에서 테이블 간 관계를 다루는 핵심 연산이다.
무결성은 개체 무결성, 참조 무결성, 도메인 무결성으로 구분해 이해하면 된다.

마무리

관계형 데이터베이스 2장 정리: “테이블 구조를 어떻게 이해할 것인가”에 대한 챕터

1장에서 데이터베이스가 왜 필요한지 배웠다면, 2장에서는 이제 그 데이터가 어떤 구조로 저장되고, 그 구조 안에서 키와 관계, 제약조건이 어떤 역할을 하는지 본격적으로 배운다.

특히 여기서 나오는

릴레이션
튜플
속성
키
관계대수
무결성

내용은 뒤에서 SQL, 정규화, ERD, 스키마 설계 배울 때 계속 나온다!! 개념을 정확히 잡아두자.