콘트라베이스

MacOS 네트워크 인터페이스(Networt Interfaces)

완성 — Sun, 23 Apr 2023 20:02:36 +0900

개요

tcp 3 way handshake 과정에서 실제로 헤더에 어떤 정보가 담기는지 확인하기 위한 방법을 알아보던 중

tcpdump를 통해 패킷 헤더의 내용을 확인할 수 있다는 사실을 알게되었다.

그러나 tcpdump를 활용한 예시들이 전부 'eth0'이라는 네트워크 인터페이스를 통한 접근을 기본으로 하는데,

내 맥북에는 그런 이름의 인터페이스가 존재하지 않았다.

따라서 ifconfig(interface configuration) 명령어를 통해 확인한

맥북의 네트워크 인터페이스와 각각의 역할에 대해 이해한 바를 정리하는 목적으로 작성하는 글이다.

명칭과 역할

먼저, 모든 네트워크 인터페이스의 이름만을 확인하기 위해 아래와 같은 명령어를 사용할 수 있다.

$ ifconfig -l

해당 명령어를 내 터미널에 실행했을 때 실제로 출력된 결과는 아래와 같다.

각 인터페이스의 자세한 정보를 확인하기 위해서는 아래의 명령어를 실행한다.

$ ifconfig -v [인터페이스이름]

### 예시
$ ifconfig -v lo0

각각의 의미와 역할을 정리해보았다. 역할을 이해하는 정도의 피상적인 수준에서 작성했다.

출처: http://newosxbook.com/bonus/vol1ch16.html

lo0

Loopback인터페이스. 루프백이라는 용어 자체는 전기신호나 디지털 데이터 스트림 등이 원래의 장치로 돌아가는 것을 의미하며, 주로 전송 시설의 테스트 수단으로 사용된다고 한다. TCP/IP에서 루프백은 웹서버를 띄우고 테스트할 때 자주 사용하는 127.0.0.1이라는 IP주소나 localhost라는 도메인 네임이 자기 자신(접근을 시도한 호스트)으로 되돌아 가게 해주는 역할을 한다. 이는 '물리적으로 존재하는 NIC(Network Interface Card)가 아니라 논리적인 인터페이스'이며 인터넷 프로토콜(IP)이 지원하는 기능이다.

루프백 인터페이스가 동작하는 방식에대해 이해한 내용은 다음과 같다.

L7(애플리케이션)에서 주소가 포함된 데이터를 L4(TCP)로 내려주면,
TCP는 Encapsulation 후 이를 L3(IP)로 내려준다.
이 때 IP 주소가 127.0.0.1(IPv4) (또는 ::1(IPv6) 또는 도메인 이름이 localhost)이라면 해당 패킷이 NIC를 거쳐 L2로 전달되는 것이 아닌, 그대로 L4로 올려보내져서 작업을 수행한다.

결과적으로 TCP/IP의 lo0 루프백 인터페이스란 L2, L1와 네트워크를 거치지 않고 OS의 네트워킹 소프트웨어만을 통하며, 같은 기기에서 클라이언트와 서버가 동작할 때 통신할 수 있는 간단한 방법을 제공하는 것이 그 목적인 네트워크 인터페이스라고 할 수 있겠다.

gif0

Generic Tunnel Interface

네트워크의 일반적인 터널링 의사 장치(pseudo-device)라고 하는데, 정확히 어떤 의미인지 잘 와닿지는 않는다.다만 GRE(Generic Routing Encapsulation)라는 프로토콜과 유사하다는 설명이 있어 이를 참고하였다. 자세한 내용은 여기서 확인할 수 있다.

터널링(Tunneling)은 해당 네트워크에서 지원하지 않는 프로토콜을 사용하여, 한 네트워크에서 다른 네트워크로 패킷을 이동시키는(전송하는) 방법이라고 한다. '__지원하지 않는 프로토콜' 을 이용하기 위해 패킷을 캡슐화하는데, 여기서 말하는 캡슐화란 OSI 계층 구조의 상위 계층에서 하위 계층으로 데이터를 전달하며 일어나는 캡슐화와 같은 의미로 원본 패킷을 페이로드로 하는 새로운 패킷을 만드는 방식을 말한다. 다만 터널링에서의 캡슐화가 항상 상위-하위 계층간의 전송만을 위한 것은 아니다. 터널링은 같은 계층 간의 데이터 전송을 위해서도 캡슐화를 사용한다.

GRE는 이러한 터널링 프로토콜로 암호화 없이 두 호스트 간에 트래픽을 터널링하는 수단이며, GIF는 GRE와 유사하지만 덜 범용적이고 몇가지 세부적인 특징에서 차이가 있는 프로토콜이라고 이해했다.

이 부분은 네트워크에 대해 좀 더 공부해야 정확히 알 수 있을 것 같다.

stf0

6(six)to4(four) tunnel interface

IPv4의 캡슐화를 통해 "6to4" IPv6를 지원하는 인터페이스이다.

6to4는 IPv4에서 IPv6로의 마이그레이션을 위한 인터넷 전환 메커니즘이다.

IPv4와 IPv6가 공존하는 동안 두 프로토콜간의 통신을 지정한 RFC3056의 매커니즘을 구현하며,

캡슐화를 통해 IPv4의 주소를 IPv6네트워크에서 이용할 수 있도록 바꿔준다.

출처: By Mro - Own work, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=10461514

stf0는 이를 위한 인터페이스로, 위 그림처럼 IPv6 Island의 경계에 있는 6to4 라우터에서 사용되는 인터페이스 이다.

anpi#(0~1)

식별자의 유래가 정확히 무엇인지, 또한 어떠한 인터페이스인지 알 수 있는 사용 예시나 설명을 찾아보았지만 확인하지 못했다.

리눅스/유닉스 계열의 네트워크 인터페이스 카드(NIC)를 나타내는 인터페이스 이름 중 하나라는 것 정도만을 알 수 있었다.

en#(0~4)

Ethernet

이더넷 네트워크 인터페이스. IP를 사용하여 이더넷을 통해 인터넷과 연결하는 네트워크 인터페이스이다.

내가 찾던 eth# 인터페이스와 같은 역할을 하며

이더넷을 전송 매커니즘으로 사용하여 컴퓨터를 LAN(Local Area Network)에 연결한다.

각각의 타입은 다음과 같았다.

en0: WI-FI

en1, en2: IP over Thunderbolt

en3, en4: USB Ethernet

bridge0

브릿지 네트워킹 인터페이스

리눅스 계열에서 제공하는 가상 네트워크 인터페이스이며 맥에서는 기본적으로 Thunderbolt 브릿지로 설정되어있다.

BSD는 Berkeley Software Distribution의 약자로 버클리에서 개발한 유닉스 운영체제를 의미한다.

브릿지는 두 개 이상의 네트워크를 연결하고, 연결된 네트워크간에는 패킷을 전달 할 수 있다.

여러 네트워크를 연결할 수 있기 때문에 다양한 작업이 가능하다.

외부와 연결을 위해 항상 브릿지를 거쳐가게 하며 패킷 필터링 등을 통해 브릿지 방화벽을 구축하는것도 가능하며

모든 내부 네트워크를 모니터링 하기 위한 수단으로 사용하기도 한다.

또 브릿지를 이용해서 하나의 장치에서 동작하는 여러 가상 머신(또는 컨테이너)이 네트워크 통신을 할 수 있다고 한다.

맥에서는 브릿지를 이용해서 실제 인터페이스인 Thunderbolt를 통해 서로 다른 두 Mac 기기간의 IP 통신을 가능하게 해준다고 설명한다.

다른 네트워크 인터페이스와 다르게 member라는 프로퍼티(?)를 가지며, 기본적으로 en1, en2 두개의 인터페이스를 멤버로 하고 있는것으로 보아 두개의 물리적인 인터페이스를 이용해서 네트워크 통신이 가능하도록 구성함을 확인 할 수 있었다.

ap1

Access Point

장치(맥북)의 연결을 공유하기 위해서 장치(맥북)를 무선 호스트로 사용할 때 이용하는 인터페이스라고 한다.

출처: https://networkencyclopedia.com/access-point/

그림과 같이, 유선 LAN에 무선 스테이션이 연결할 수 있도록 _접근 가능한 지점_으로서 기능하기 때문에 Access Point라는 이름을 가진다.

awdl0

Apple Wireless Direct Link(AWDL) 기술에서 사용되는 인터페이스이다.

AirDrop, AirPlay, Handoff, Continuity 등의 Apple의 기능을 사용할 때 사용되는 애플의 자체적인 인터페이스이다.

llw0

Low-latency WLAN Interface. Used by the Skywalk system.

대기 시간이 짧은 특수한 종류의 WiFi 연결을 위한 네트워크 인터페이스라고 한다.

Skywalk system??

아무리 검색해도 관련 정보가 나오지 않았는데,

애플의 개발자 포럼에서 같은 궁금증을 가지는 사람이 쓴 글의 답글에 작성된 링크를 통해 관련된 내용을 확인할 수 있었다.

...
The second is the mysterious Skywalk, and its nexus and channel objects. This is an entire subsystem which is not only undocumented, but intentionally left out of XNU's public sources.
...

재밌는 얘기가 나왔다.

조금 더 확인해본 바로는

애플의 모든 운영체제는 Darwin이라는 운영체제를 기반으로 하고,

Darwin의 커널은 XNU이며, 이 XNU의 네트워크 서브 시스템이 Skywalk라고 한다.

관련 유틸인 skywalkctl(8)의 매뉴얼은 여기서 확인 가능하다.

utun#(0~6)

User Tunneling interface

유저 스페이스(User space)와 커널 스페이스(Kernel space) 간의 터널링을 담당하는 가상 네트워크 인터페이스이며 VPN에 이용된다. utun0 인터페이스를 직접 언급하는 자료는 거의 없었으나, 리눅스의 tun과 유사한 역할과 기능을 지원한다고 하여 리눅스의 tun이라는 가상 네트워크 인터페이스가 어떤식으로 VPN에 이용되는지 같이 알아보았다.

VPN(Virtual Private Network; 가상 사설 망)은 public 네트워크에서 패킷의 암호화 작업과 터널링을 통해 가상의 사설망을 구축하는 방법 또는 그러한 통신망이다. 가상의 사설망을 구축한다는 개념 자체는 터널링만으로도 가능 하지만, 사설망을 구축하는 의도는 외부의 공공 망과의 분리이며, 따라서 전송하는 데이터를 외부에서 확인할 수 없도록 하는 암호화 작업이 대부분 필수적이다.

사이트와 사이트 간의 VPN 구성(Site-to-Site(또는 Gateway) VPN)의 경우에는 연결을 원하는 각 사이트의 게이트웨이 간에 VPN 터널을 생성한다. 같은 회사에서 물리적으로 충분히 떨어져 있는 여러 지점간의 통신을 위해 사설망을 구축하는 상황을 생각할 수 있겠다.

출처 : https://commons.wikimedia.org/wiki/File:Site-to-site_VPN-en.svg

개별 호스트가 사이트에 VPN 연결을 하려는 경우(Host(또는 Client)-to-Site(또는 Host-to-Gateway) VPN)에는 접속자 단위로 VPN 터널이 생성되어야 한다. 이는 원격으로 근무하는 직원이 회사의 로컬망에 접근해서 작업을 진행해야 하는 경우를 예로 들 수 있을 것이다.

출처 : https://www.tp-link.com/kr/blog/1268/vpn-%ED%81%B4%EB%9D%BC%EC%9D%B4%EC%96%B8%ED%8A%B8%EB%8A%94-%EB%AC%B4%EC%97%87%EC%9D%B8%EA%B0%80%EC%9A%94-tp-link-%EA%B3%B5%EC%9C%A0%EA%B8%B0%EC%97%90-vpn-%EC%84%A4%EC%B9%98%ED%95%98%EB%8A%94-%EB%B0%A9%EB%B2%95/

Host-to-Site VPN의 경우 일반 PC의 네트워크 트래픽을 VPN Server로 전송해야 하기 때문에 VPN Client 프로그램의 설치가 필요하다. VPN Client 프로그램이 실행되면, VPN Server와의 터널을 만들고 해당 PC에서 전송하는 모든 네트워크 트래픽을 캡쳐하여 VPN 터널을 통해 VPN Server로 전송한다.

네트워크 트래픽을 캡쳐한다는것은 운영체제에서 발생하는 모든 네트워크 트래픽을 가로채서 VPN 터널을 통해 전송되도록 리디렉션 해준다는 것이다. 이는 User 레벨의 어플리케이션인 VPN Client가 독단적으로 수행할 수 있는 것이 아니며, 커널과의 긴밀한 협력이 필요한 작업이다. 커널과의 협력과 동시에 터널링을 통해 VPN 터널로의 전송을 가능하게 해주는것이 바로 tun과 tap이라는 이름의 가상 네트워크 인터페이스(혹은 디바이스)이다.

어플리케이션과 NIC를 제외한 TCP, IP는 커널 영역에 속하는 네트워크 스택의 레이어이다. (출처 : https://d2.naver.com/helloworld/47667)

tun/tap은 리눅스에서 제공하는 가상 네트워크 인터페이스(디바이스)로서 소프트웨어적으로 구현된 가상의 네트워크 장치이다. tun은 OSI L3(Network)인터페이스의 에뮬레이션이고, tap은 L2(Data Link)인터페이스의 에뮬레이션이다.

즉, tun은 3계층의 패킷을 터널링 할 수 있고 tap은 2계층의 패킷을 터널링 할 수 있다.

출처 : By Ikluft - Own work, CC BY-SA 4.0, https://commons.wikimedia.org/w/index.php?curid=80385349

두 가상 장치는 전송받은 패킷을 사용자 공간(User Space)에서 실행되는 프로세스에게 전달한다. 반대로 사용자 공간의 프로세스가 tun 또는 tap으로 패킷을 전달할 수도 있다.

출처 : https://tttsss77.tistory.com/235

정리하자면, tun은 Host-to-Site VPN에서 VPN Client가 VPN Server와의 통신을 위한 터널링에 사용되며, User Space의 어플리케이션인 VPN Client가 모든 네트워크 트래픽을 컨트롤 하기 위해 커널과 통신하는 가상 네트워크 인터페이스라고 이해할 수 있을 것 같다.

아직은 실제로 VPN을 구성해본적은 없어서, 터널이 구성된 뒤 tun이 실제로 어떤 방식으로 유저-커널 사이에서 패킷을 전송하고 네트워크 트래픽을 캡쳐하는 지 등 구체적인 동작 과정을 알기 위해서는 OpenVPN을 이용한 구현을 직접 해보며 공부가 좀 더 필요할 것 같다.

.

쓰다보니 애매하게 알고있는 것들이 많이 있었다. 잘 모른는건 최대한 알아보려고 했으나 아직까지 모호한 것들이 남아있다.

네트워크도 재밌는것같다.

참고 출처

리눅스 네트워크 관리에 필요한 사용법 11가지 | 와탭 블로그
https://stackoverflow.com/questions/29958143/what-are-en0-en1-p2p-and-so-on-that-are-displayed-after-executing-ifconfig
TCPdump 활용하기 (명령어 및 사용법)
https://www.juniper.net/documentation/kr/ko/software/junos/interfaces-fundamentals/topics/topic-map/loopback-interfaces.html
https://www.cloudflare.com/ko-kr/learning/network-layer/what-is-tunneling/
https://velog.io/@koo8624/Linux-Linux-Virtual-networking-Interface
https://superuser.com/questions/1681992/why-the-bridge0-has-a-ethernet-port-address-it-refers-to-what
https://apple.stackexchange.com/questions/394047/what-is-the-network-interface-llw0
https://www.joinc.co.kr/w/Site/cloud/NetworkVirtualization/tunneling
www.joinc.co.kr](https://www.joinc.co.kr/w/Site/cloud/NetworkVirtualization/tunneling)
https://www.geeksforgeeks.org/tunneling/
https://ebrary.net/26730/computer_science/remote_access_host-to-site
https://www.joinc.co.kr/w/Site/System_management/VPN/OpenVPN
https://m.blog.naver.com/PostView.naver?isHttpsRedirect=true&blogId=rpg2003a&logNo=221209134202

[RBTree lab] ③ Erase

완성 — Tue, 28 Mar 2023 16:43:32 +0900

삭제

노드의 삭제는 다음과 같은 과정을 거쳐서 일어난다.

1. 삭제 대상 노드(target)를 트리에서 제거한다.

2. RBTree의 조건에 맞게 트리를 조정한다.

1. 삭제 대상 노드(target)를 트리에서 제거

삭제 자체는 BST의 삭제와 동일하게 진행된다.

주어진 target이 항상 트리 내에 존재하는, sentinel이 아닌 노드라고 할 때,

target 노드가 제거된다는 것은

target의 연결 관계가 제거되고, 트리에서 target이 차지하고 있던 위치에 다른 노드가 위치하게 되는 것을 의미한다.

RB Tree에서는 3가지 경우를 나누어서 노드의 삭제를 진행한다.

1. target의 오른쪽 자식이 nil인 경우

2. target의 왼쪽 자식이 nil인 경우

3. target의 두 자식이 모두 nil이 아닌 경우

1, 2번의 경우에는 각각 왼쪽, 오른쪽 자식(nil인 자식의 반대쪽 자식)이 target의 위치를 대체하게 한다.

3번의 경우는 조금 복잡한데,

target의 오른쪽 자식을 루트 노드로 하는 서브트리에서 가장 작은 값을 가지는 노드가 target의 위치를 대체하게 하거나,

target의 왼쪽 자식을 루트 노드로 하는 서브트리에서 가장 큰 값을 가지는 노드가 target의 위치를 대체하게 한다.

그 이유는, 위 그림과 같이 BST의 정의에 인한 것인데,

이진 탐색 트리에서 어떤 노드 a의 좌, 우 자식 서브트리의 노드들은 모두 a보다 작은값을 가지거나, a보다 큰 값을 가지기 때문이다.

RBTree 또한 BST의 일종이므로 같은 조건을 만족하고,

여기서 구현한 규칙은 왼쪽 자식은 현재 노드보다 작은 값을, 오른쪽 자식은 현재 노드보다 큰 값을 가지도록 구현하였다.

따라서 "target의 오른쪽 서브 트리에서 가장 작은 값을 가지는 노드"는 바꿔 말하면

"target의 자손 노드 중 target보다 큰 값을 가지는 노드들 중 가장 작은값을 가지는 노드"이고,

반대의 경우인 "target의 왼쪽 서브 트리에서 가장 큰 값을 가지는 노드"는

"target의 자손 노드 중 target보다 작은 값을 가지는 노드들 중 가장 큰값을 가지는 노드"인 것이다.

즉 target의 자손 노드 중 target과 가장 가까운 값을 가지는 노드를 찾아내어

target의 위치를 대체하기 위한 과정이라고 할 수 있다.

구현(6) (transPlant)

먼저 "특정 노드의 위치를 새로운 노드가 대체하는" 기능이 공통적으로 필요하다.

따라서 다음과 같은 함수를 작성한다.

void trans_plant(rbtree *t, node_t *old_node, node_t *new_node) {
    if (old_node->parent == t->nil) {
        t->root = new_node;
    } else if (old_node == old_node->parent->left) {
        old_node->parent->left = new_node;
    } else {
        old_node->parent->right = new_node;
    }
    new_node->parent = old_node->parent;
}

이 함수의 기능은 간단하다,

부모 노드와의 관계 설정을 통해 노드 old_node의 위치를 노드 new_node로 대체한다.

자식 노드는 신경쓰지 않고 단지 부모노드와의 관계만을 변경하는 것이며,

old_node와 new_node의 위치를 바꾸는 것이 아님을 주의해야한다.

구현(7) (subtree_min, subtree_max)

인자로 받은 노드(cursor)를 루트노드로 하는 서브트리에서 가장 작은값 또는 가장 큰 값을 찾는 함수를 구현했다.

노드를 제거하는 경우 중 두 자식 노드가 모두 nil이 아닌 경우에

target노드를 대체할 노드를 찾기 위해 사용된다.

node_t *subtree_min(node_t *cursor, node_t *nil) {
    node_t *min = cursor;
    while (cursor != nil) {
        min = cursor;
        cursor = cursor->left;
    }
    return min;
}

node_t *subtree_max(node_t *cursor, node_t *nil) {
    node_t *max = cursor;
    while (cursor != nil) {
        max = cursor;
        cursor = cursor->right;
    }
    return max;
}

구현(8) (erase) (노드의 삭제만 구현된 형태)

특정 노드를 삭제하는 erase함수이다.

앞서 이야기 한 3가지 경우를 기준으로 삭제 방법이 다른것을 확인할 수 있다.

int rbtree_erase(rbtree *t, node_t *target) {
    node_t *y = target;
    color_t y_color = y->color;

    node_t *x;
    if (target->left == t->nil) {
        x = target->right;
        trans_plant(t, target, target->right);
    } else if (target->right == t->nil) {
        x = target->left;
        trans_plant(t, target, target->left);
    } else {
        /** case 1 **/
        /** 삭제 될 target의 자리를 right subtree의 min node로 대체 **/

        // y는 right subtree의 min node
        y = subtree_min(target->right, t->nil);
        y_color = y->color;

        // y는 BST에서 가장 작은 노드이므로 항상 왼쪽 자식이 존재하지 않음(nil)
        // 따라서, x는 y의 하나뿐인 유효한 자식 노드이거나 또는 nil이다.
        x = y->right;

        if (y->parent == target) {  // y가 target의 오른쪽 자식인 경우
            x->parent = y;
        } else {  // 그렇지 않을 경우
            // y의 자리는 y의 오른쪽 자식(유효한 노드 또는 nil임)이 대체하게 하고,
            // target의 오른쪽 자식과의 관계를 y가 대체한다.
            trans_plant(t, y, y->right);
            y->right = target->right;
            y->right->parent = y;
        }
        // 드디어 target의 부모와의 관계를 y가 대체한다.
        trans_plant(t, target, y);

        // 또한, 왼쪽 자식과의 관계 또한 대체하며
        y->left = target->left;
        y->left->parent = y;

        // target이 제거됨으로서 생기는 규칙의 위배를 막기 위해
        // y의 color를 삭제된 target의 색으로 변경한다.
        y->color = target->color;
    }

    free(target);

    init_nil(t->nil);

    return 0;
}

rbtree_erase 함수에서 사용되는 주요 변수의 이름과 역할은 다음과 같다.

삭제 대상(target의 두 자식 노드 중 하나가 nil일 때) 또는

이동 대상(target의 두 자식 노드 모두 nil이 아닐 때)인 노드이다.

y의 원래 위치로 이동하여 y를 대체할 노드이다.

x는 y의 하나뿐인 유효한 자식이거나, nil이다.

y_color

y의 원래 색상을 저장한다.

y_color를 저장하는 이유에 대해서 CLRS에서는 이렇게 설명한다.

Need to save y’s original color (in y-original-color) to test it at the end, because if it’s black, then removing or moving y could cause red-black properties to be violated.

즉, 삭제에서 제거 또는 이동 대상인 노드 y의 색깔이 BLACK인 경우 RBTree 특성 위반의 원인이 될 가능성이 있기 때문이며

이를 이용해서 뒤이어 설명할 erase_fixup 수행 여부를 결정하기 위함이다.

left subtree의 max node로 대체하는 방식의 구현은 더보기

    node_t *y = target;
    color_t y_color = y->color;

    node_t *x;
    if (target->left == t->nil) {
        x = target->right;
        trans_plant(t, target, target->right);
    } else if (target->right == t->nil) {
        x = target->left;
        trans_plant(t, target, target->left);
    } else {
        /** case 2 **/
        /** 삭제 될 target의 자리를 left subtree의 max node로 대체 **/
        y = subtree_max(target->left, t->nil);
        y_color = y->color;
        x = y->left;
        if (y->parent == target) {
            x->parent = y;
        } else {
            trans_plant(t, y, y->left);
            y->left = target->left;
            y->left->parent = y;
        }
        trans_plant(t, target, y);
        y->right = target->right;
        y->right->parent = y;
        y->color = target->color;
    }

2. RBTree의 조건에 맞게 트리를 조정하기

이 과정이 RBTree의 모든 기능 중 가장 까다로운 부분이다.

y의 원래 색에 따라, 삭제 작업이 완료된 뒤 RBTree의 조건에 맞게 노드 위치의 조정이 필요하다.

조건을 위배하는 경우: y의 원래 색 == BLACK

1. y의 색이 RED
2. y의 색이 BLACK

사용자에게 제공될 모든 operation은 RBTree의 조건을 항상 만족하는 상태에서 시작한다는 전제 하에,

색이 RED인 노드를 삭제하는 경우는 RBTree의 조건을 무너뜨리지 않는다.

양쪽 자식이 모두 BLACK이었을 것이기 때문에(조건 4번)

leaf로 가는 BLACK 노드의 수가 변하지 않고(조건 5번),

또한 삭제로 인해 조건 4번이 깨지는 것도 아니다.

그러나 삭제된 노드의 색깔이 BLACK인 경우에는 조건이 무너지는 경우가 발생할 수 있다.

다시 조건을 보자

1. 모든 노드는 RED 또는 BLACK
2. 루트는 BLACK
3. 모든 리프(NIL)는 BLACK
4. 노드가 RED 이면 그 노드의 자식은 모두 BLACK
5. 각 노드로부터 그 노드의 자손인 리프로 가는 경로들은 모두 같은 수의 BLACK 노드를 포함해야함

만약, y가 BLACK인 노드라면, 각 조건에 대한 위배 여부는 다음과 같다.

1. 문제 없음
2. y가 루트노드, x가 RED인 경우 루트가 RED가 되어 위배됨
3. 문제 없음
4. x와 x의 바뀐 부모노드가 모두 RED인 경우 위배됨
5. y를 포함하고있던 경로에서 BLACK이 1개 부족하게되어 위배됨

2, 4, 5번에서 발생하는 문제를 모두 해결하기 위해서는

x를 BLACK으로 바꿔주면 된다.

2번은 경우 루트가 BLACK이 되어 위배가 사라지고,

3번은 부모의 다른 자식 노드는 조건에 부합할 것이고, x만 BLACK이 되면 해결된다.

5번 또한 BLACK이 하나 생겨서 괜찮다...?

5번은 안괜찮다. 언제 안괜찮냐, x의 색깔이 원래 BLACK인 경우이다.

이 경우는 5번이 위배되는 상황을 해결하지 못한다.

이중 흑색 노드

이런 상황을 일반화 하여 해결하기 위한 개념적인 도구로서, 이중 흑색 노드(doubly black node)가 등장한다.

위에서 2, 4, 5번 조건이 위배되는 상황을 해결하기 위해 'x의 색을 BLACK으로 "바꿔준다"' 고 하였는데,

이를 'x에게 extra BLACK을 "추가한다"'고 바꿔 표현해보자.

이때, extra BLACK이 추가된 노드의 색(상태)은 둘 중 하나이다.

1. doubly BLACK
2. RED & BLACK

x의 색이 doubly BLACK 또는 RED & BLACK이 되면

y를 포함하던 경로에서 BLACK이 하나 부족한 상황이 생기지 않게되고,

5번 조건이 위배되는 상황은 사라지지만 1번 조건 "모든 노드는 BLACK 또는 RED"를 어기게 된다.

이를 해결하기 위해 x의 색이 RED & BLACK 이 되거나 또는 x가 루트 노드가 될 때까지

extra BLACK을 트리의 위로 이동시킨다.

만약 x의 색이 RED & BLACK이라면, 색을 BLACK으로 바꾸고,
x가 루트 노드라면 extra BLACK을 제거한다.

extra BLACK을 트리의 위로 이동시키기 위해 x와 x의 형제노드인 w가 정의된다.

x는 항상 루트가 아닌 doubly BLACK 노드이다.
w는 x의 형제 노드이며, nil이 될 수 없다(x의 부모 노드에서 조건 5번 위배)

x가 왼쪽 자식인지, 오른쪽 자식인지에 따라 2가지 경우가 존재하고

w의 색에 따라서 4가지 경우가 존재하여 총 8가지의 경우가 존재하여, 각 경우에 대한 해결 방법이 다르다.

x가 왼쪽 자식인 경우의 4가지 케이스만을 예로 들면, 다음과 같다.

이제 각 경우에 대해 알아보자

Case 1

먼저, x의 부모노드의 색을 RED로, w의 색을 BLACK으로 바꿔준다.

그 다음, x의 부모를 중심으로 left rotate를 진행한다.

이 상태에서 x의 new w는 rotate전의 w의 자식노드 중 하나이므로, 무조건 BLACK이다.

이제 w가 BLACK인 경우들을 확인해보자.

Case 2

x가 가지고있던 extra BLACK을

w의 색을 RED로 바꾸고, x가 x의 부모를 가르키도록 한다.

Case 3

w의 색을 BLACK으로, w의 왼쪽 자식의 색을 RED로 만들어준다.

그 다음, w를 기준으로 right rotate를 진행한다.

이제 w는 BLAKC이며 오른쪽 자식이 RED인 상태가 된다.

마지막 케이스를 확인하자

Case 4

w의 색을 x의 부모 노드의 색으로 만들어주고,

w의 왼쪽 자식의 색을 BLACK으로 만들어준다.

그 뒤, x의 부모 노드를 기준으로 left rotate 한다.

구현(7) (erase-fixup)

void rbtree_erase_fixup(rbtree *t, node_t *cursor) {
    while (cursor != t->root && cursor->color == RBTREE_BLACK) {
        if (cursor == cursor->parent->left) {
            node_t *sibling_node = cursor->parent->right;
            if (sibling_node->color == RBTREE_RED) {
                sibling_node->color = RBTREE_BLACK;
                cursor->parent->color = RBTREE_RED;
                left_rotate(t, cursor->parent);
                sibling_node = cursor->parent->right;
            }
            if (sibling_node->left->color == RBTREE_BLACK && sibling_node->right->color == RBTREE_BLACK) {
                sibling_node->color = RBTREE_RED;
                cursor = cursor->parent;
            } else {
                if (sibling_node->right->color == RBTREE_BLACK) {
                    sibling_node->left->color = RBTREE_BLACK;
                    sibling_node->color = RBTREE_RED;
                    right_rotate(t, sibling_node);
                    sibling_node = cursor->parent->right;
                }
                sibling_node->color = cursor->parent->color;
                cursor->parent->color = RBTREE_BLACK;
                sibling_node->right->color = RBTREE_BLACK;
                left_rotate(t, cursor->parent);
                cursor = t->root;
            }
        } else {
            node_t *sibling_node = cursor->parent->left;
            if (sibling_node->color == RBTREE_RED) {
                sibling_node->color = RBTREE_BLACK;
                cursor->parent->color = RBTREE_RED;
                right_rotate(t, cursor->parent);
                sibling_node = cursor->parent->left;
            }
            if (sibling_node->left->color == RBTREE_BLACK && sibling_node->right->color == RBTREE_BLACK) {
                sibling_node->color = RBTREE_RED;
                cursor = cursor->parent;
            } else {
                if (sibling_node->left->color == RBTREE_BLACK) {
                    sibling_node->right->color = RBTREE_BLACK;
                    sibling_node->color = RBTREE_RED;
                    left_rotate(t, sibling_node);
                    sibling_node = cursor->parent->left;
                }
                sibling_node->color = cursor->parent->color;
                cursor->parent->color = RBTREE_BLACK;
                sibling_node->left->color = RBTREE_BLACK;
                right_rotate(t, cursor->parent);
                cursor = t->root;
            }
        }
    }
    cursor->color = RBTREE_BLACK;
}

[RBTree lab] ② Insert

완성 — Tue, 28 Mar 2023 16:23:49 +0900

삽입(insert)

insert 자체는 BST와 동일하게 진행되고,
insert 이후 RB트리를 유지시키기 위한 fix up이 진행된다.

먼저 insert부터 확인해보자.

Root node부터 시작해서,
현재 insert하려는 new_node의 key값과 만나는 node의 key값을 비교한 뒤
new_node의 key값이 더 작다면 왼쪽으로, 크다면 오른쪽으로 내려간다.
더 이상 내려갈 수 없을 때(nil을 만날 때) 그 위치가 new_node가 삽입 될 위치이다.

다만,

RB 트리의 1번 조건에 따라, 모든 node는 RED 또는 BLACK의 색을 가져야 하는데,
새로 insert되는 node의 색은 항상 RED 로 고정된다.

이는 RB Tree의 조건 5번을 위배하지 않기 위함이다.

5. 각 노드로부터 그 노드의 자손인 리프로 가는 경로들은 모두 같은 수의 BLACK 노드를 포함해야한다.

만약 추가되는 node의 색이 BLACK 이라면,
어떤 node에서 출발해서 leaf로 갈 때,
추가된 node로 가는 경로의 BLACK 노드 개수가 다른 경로보다 1개 더 많아질 것이고,
이는 조건 5번을 위배한다.

따라서 Insert되는 node의 색은 RED 로 고정된다.

구현(4) (Insert)

node_t *rbtree_insert(rbtree *t, const key_t key) {
    // rbtree에 저장할 new_node 생성
    node_t *new_node = create_new_node(key, t->nil);

    // insert 위치 탐색
    node_t *parent_node = t->nil;
    node_t *cursor = t->root;
    while (cursor != t->nil) {
        parent_node = cursor;
        if (new_node->key < cursor->key) {
            cursor = cursor->left;
        } else {
            cursor = cursor->right;
        }
    }

    // new_node와 parent_node의 자식-부모 관계 설정
    new_node->parent = parent_node;
    if (parent_node == t->nil) {			// 1. parent_node가 nil인 경우 (newNode가 root)
        t->root = new_node;
    } else if (new_node->key < parent_node->key) {	// 2. new_node가 parent_node의 왼쪽 자식 노드인 경우
        parent_node->left = new_node;
    } else {						// 3. new_node가 parent_node의 오른쪽 자식 노드인 경우
        parent_node->right = new_node;
    }

    // rbtree 복구
    rbtree_insert_fixup(t, new_node);

    // 생성 후 insert한 노드의 pointer를 반환
    return new_node;
}

삽입 후 복구

insert가 완료된 후, RBTREE의 특성을 복구하기 위한 insert_fixup이 수행된다.

현재 노드를 기준으로 삼촌 노드를 정의하게 되는데
관계도는 아래와 같다.

그림처럼, 부모 노드의 형제 노드를 삼촌이라고 부를 예정이다.

insert_fixup이 진행되는 경우는 총 6가지로, 아래 그림과 같다.

왜 경우가 6가지일까

조건을 다시 보자.

1. 모든 노드는 RED 또는 BLACK
2. 루트는 BLACK
3. 모든 리프(NIL)는 BLACK
4. 노드가 RED 이면 그 노드의 자식은 모두 BLACK
5. 각 노드로부터 그 노드의 자손인 리프로 가는 경로들은 모두 같은 수의 BLACK 노드를 포함해야함

insert된 node인 x(x의 color는 RED)에 의해
RBTREE의 특성이 위배될 수 있는 상황이 존재한다.

조건 1, 3, 5는 insert에 의해 위배되지 않는다.
조건 2, 4는 위배 될 수 있다.

두 조건이 위배되는 경우 모두 x가 RED 이기 때문이며, 각각의 경우는

조건 2가 위배되는 경우: x가 루트인 경우
조건 4가 위배되는 경우: x의 부모가 RED 인 경우

인 상태일 때 위배된다.

조건 2가 위배되는 경우(x가 루트인 경우)

x의 color를 BLACK 으로 바꿔준다.

조건 4가 위배되는 경우(x의 부모가 RED인 경우)

는 2가지 경우로 구분된다.

1. x의 부모 노드가 조부모 노드의 왼쪽 자식일 경우
2. x의 부모 노드가 조부모 노드의 오른쪽 자식일 경우

또한 2가지의 각 경우는, 또다시 아래와 같은 3가지 경우로 구분된다.

1). x의 삼촌 노드가 RED인 경우
2). x의 삼촌 노드가 BLACK이면서 x가 오른쪽 자식인 경우
3). x의 삼촌 노드가 BLACK이면서 x가 왼쪽 자식인 경우

따라서 먼저 구분된 2가지 경우와 각 경우에서 또 3가지 경우가 존재하므로,
총 6가지 경우에 대한 판단과 각 경우의 해소(RBTREE를 유지 시키는)방법이 존재한다.

구현(5) (insert fix up)

void rbtree_insert_fixup(rbtree *t, node_t *cursor) {
    // 종료 조건: cursor 부모 노드의 color (RBTREE_BLACK or RBTREE_RED)
    while (cursor->parent->color == RBTREE_RED) {
        // 분기 1: cursor 부모 노드의 위치 (left child or right child)
        if (cursor->parent == cursor->parent->parent->left) {
            node_t *uncle = cursor->parent->parent->right;
            // 분기 2: cursor 삼촌 노드(uncle)의 color (RBTREE_BLACK or RBTREE_RED)
            if (uncle->color == RBTREE_RED) {
                cursor->parent->color = RBTREE_BLACK;
                uncle->color = RBTREE_BLACK;
                cursor->parent->parent->color = RBTREE_RED;
                cursor = cursor->parent->parent;
            } else {
                // 분기 3: cursor의 위치 (left child or right child)
                if (cursor == cursor->parent->right) {
                    cursor = cursor->parent;
                    left_rotate(t, cursor);
                }
                cursor->parent->color = RBTREE_BLACK;
                cursor->parent->parent->color = RBTREE_RED;
                right_rotate(t, cursor->parent->parent);
            }
        } else {
            node_t *uncle = cursor->parent->parent->left;
            if (uncle->color == RBTREE_RED) {
                cursor->parent->color = RBTREE_BLACK;
                uncle->color = RBTREE_BLACK;
                cursor->parent->parent->color = RBTREE_RED;
                cursor = cursor->parent->parent;
            } else {
                if (cursor == cursor->parent->left) {
                    cursor = cursor->parent;
                    right_rotate(t, cursor);
                }
                cursor->parent->color = RBTREE_BLACK;
                cursor->parent->parent->color = RBTREE_RED;
                left_rotate(t, cursor->parent->parent);
            }
        }
    }
    t->root->color = RBTREE_BLACK;
}

[RBTree lab] ① 개요, Rotate

완성 — Tue, 28 Mar 2023 16:19:12 +0900

RBTree(Red Black Tree)

RB트리는
전체 트리의 높이를 (은 노드의 개수) 으로 유지하는
이진 탐색 트리이다.

RBTREE의 5가지 조건

1. 모든 노드는 RED 또는 BLACK
2. 루트는 BLACK
3. 모든 리프(NIL)는 BLACK
4. 노드가 RED 이면 그 노드의 자식은 모두 BLACK
5. 각 노드로부터 그 노드의 자손인 리프로 가는 경로들은 모두 같은 수의 BLACK 노드를 포함해야함

각 노드는 자신의 부모, 왼쪽 자식, 오른쪽 자식의 정보와
노드 자신의 key값을 가지고 있다.

구현을 용이하게 하기 위해 sentinel node를 이용하는데,
sentinel node는 부모와 자식 정보를 가지지 않고
색깔이 항상 BLACK인 node로 정의한다.

구현(1) (노드, RB트리)

노드와 트리의 정보를 갖게 될 구조체는 다음과 같이 구현했다.

typedef enum { RBTREE_RED,
               RBTREE_BLACK } color_t;

typedef int key_t;

typedef struct node_t {
    color_t color;
    key_t key;
    struct node_t *parent, *left, *right;
} node_t;

typedef struct {
    node_t *root;
    node_t *nil;  // for sentinel
} rbtree;

node_t

node_t는 RB트리의 노드 구조체이다.
자기 자신의 포인터 변수를 갖는 구조체를 '자기 참조 구조체' 라고 하며,
자기 참조 구조체가 갖는 자기 자신 타입의 포인터 멤버를 링크(link)라고 한다.
node_t는 자기 참조 구조체이고,
*parent, *left, *right는 링크이다.

멤버

color_t color : 노드의 색(RBTREE_RED, RBTREE_BLACK)
key_t key : 노드의 Key값(int)
struct node_t *parent, *left, *right
: 순서대로, 노드의 부모 노드, 왼쪽 자식 노드, 오른쪽 자식 노드

rbtree

rbtree는 RB트리 구조체이다.

멤버

node_t *root : rbtree의 root 노드. 초기값은 nil
node_t *nil : sentinel 노드.
한 노드의 자식 또는 부모가 존재하지 않으면 nil로 채운다.

RB Tree를 복구하기 위한 방법

Insert와 Delete는 트리를 수정한다.
이는 원래 트리를 RB트리의 조건에 위배되는 상태로 만들 수 있다.
따라서, Insert와 Delete 이후에는 RB트리를 복구시키는 과정이 필요하다.

복구를 위해 트리를 일부 수정해주어야 하고,
수정에 공통적으로 사용되는 2가지 방법이 존재한다.

하나는 노드의 연결 정보를 변경시키는 회전 이고,
다른 하나는 노드의 색을 바꿔주는 방법이다.

두 방법 모두 이진 탐색 트리의 특성을 보전한다.

두 가지 방법 중 색을 바꿔주는 것은
말 그대로 각 노드의 색을 조건에 맞게 변경해주는 것으로
이후에 RB트리가 복구 되는 과정에서 조건에 맞게 진행될 것이다.

회전 또한 복구 과정에서 조건에 맞게 사용되나,
우선 회전이라는 것이 어떤 일이 일어나는 과정인지 알아볼 필요가 있다.

회전(Rotate)

우회전(Right-Rotate)과 좌회전(Left-Rotate)이 있다.

왜 할까?

RB 트리는 높이를 (은 노드의 개수) 으로 유지 시키는
이진 탐색 트리라고 설명했다.

RB 트리에 node를 삽입하거나, 기존의 node를 삭제하는 것은
트리 한쪽이 치우쳐지는 형태의 불균형을 초래하고,
이는 이 불균형을 존재하지 않도록 강제하는 RB 트리의 5가지 조건(혹은 특성)을 위배하는 상황으로 이어진다.

어떤 node의 삽입/삭제로 인해
root노드 기준 좌/우 subTree 중 한 쪽의 길이가 상대적으로 짧아진 tree를 생각해보자,

좌우의 균형을 다시 맞춰주기 위해서, 아래처럼 간단한 방법을 생각해 볼 수 있다.

길이가 긴 subtree의 root node 레벨을 올려주어, 전체 트리의 좌/우 서브트리의 높이를 맞춰주는 것이다.
위 그림은 단순한 예시이고, 실제로 Rotate는 저런식으로 동작하지는 않는다(양 subtree의 크기나 Rotate 이후의 형태도 맞지 않다.).
다만 Rotate를 하는 목적에 대한 직관적인 설명은 될 수 있을 것이다.

해도 될까?

Rotate가 RB 트리의 불균형을 조정하기 위한 방법이라면,
최소한 RB 트리가 되기 위한 전제인 "이진 탐색 트리"인 상태를 깨뜨려서는 안 될 것이다.

아래에 Left Rotate와 Right Rotate의 과정을 그려놓았다.
각 과정에서 어떤 방식으로 이진 탐색 트리의 특성을 유지 시키면서
Rotate를 가능하게 하는지 확인해 볼 수 있다.

해보자

코드나 설명을 보면 부분적으로는 이해가 되는데,
전체 과정이 그려지지를 않아서
그냥 진짜로 그림을 그려보았다.

아래는 혹시 몰라서 적어둔 그림의 이해를 위한 설명이다.

회전이 진행되며 두 Node의 사이의 간선이 변경되는 과정을 코드와 그림으로 표현했다.

각 Node는 부모, 왼쪽 자식, 오른쪽 자식의 정보를 가지고 있고,
간선의 방향은 정보를 가진 Node에서 그 정보에 해당하는 Node로 향한다.

예를들어, Node A에서 Node B로 향하는(A에서 출발한 화살표가 B에 꽂힌) 간선이 존재할 때,
Node A는 부모 또는 왼쪽 자식 또는 오른쪽 자식 중 하나의 관계로서
Node B의 정보를 가지고 있다는 의미이다.
(Node A가 Node B의 정보를 가지고 있다.)

각 단계에서 변경된 간선에 대해
변경 이전의 간선은 빨간 점선으로,
변경 이후의 간선은 파란 실선으로 그렸으며
변경 이후의 간선으로 생긴 새롭게 연결된 Node와의 관계를

P = 부모
Left = 왼쪽 자식
Right = 오른쪽 자식
Child = 자식(좌/우 구분을 따로 표현하지 않음)

와 같이 표시했다.

우회전(Right-Rotate)

왼쪽이 right rotate 이전의 상태,
오른쪽이 right rotate 이후의 상태이다.

right rotate 과정을 단계로 구분지어 표현했다.
하나의 단계마다 하나의 Node가 가지는 부모 또는 왼쪽 자식 또는 오른쪽 자식 의 정보가 수정된다.

1번 단계에서

Node x 에서 위쪽(빈 곳)으로 연결된 간선은 x와 x의 부모 노드가 연결된 간선이다.
이후 단계가 진행되면서,
마찬가지로 위쪽의 빈 곳을 향하는 간선은 회전 전의 x의 부모 노드와 연결된 간선이다.

1번, 2번 단계에서

x와 는 부모-왼쪽자식 관계를 갖게된다.

3번, 4번 단계에서

y와 회전 전의 x의 부모 노드 는 자식-부모 관계를 갖게된다.
(4번의 Child 라고 표시된 간선과, 5번의 Right 라고 표시된 간선에 의해)

이는 회전 전의 x와 x의 부모 노드 사이의 관계를 그대로 대체하는 것이다.

y가 x의 자리를 차지할 때
x와 x의 부모와의 관계를 그대로 가져가야 하기 하기 때문에,

y가 회전 전의 x의 부모 노드 의 왼쪽 자식이 되는지, 오른쪽 자식이 되는지는
x가 회전 전의 x의 부모 노드 의 왼쪽 자식이었는지, 오른쪽 자식이었는지 여부를 그대로 따라간다.

회전 전의 상태에서,

x가 x의 부모 노드의 왼쪽 자식이었다면,
4단계의 Child라는 표현은 Left가 될 것이고,

x가 x의 부모 노드의 오른쪽 자식이었다면, Right가 될 것이다.

( x가 root 였다면, y는 root가 된다. )

5번, 6번 단계에서

원래는 부모였던 node x와
원래는 왼쪽 자식이었던 node y의
부모-자식 관계의 역전이 일어난다.

y는 x를 자신의 오른쪽 자식으로 두고,
x는 y를 자신의 부모로 둔다.

구현(2) (right rotate)

void right_rotate(rbtree *t, node_t *x) {
    node_t *y = x->left;
    x->left = y->right;
    if (y->right != t->nil) {
        y->right->parent = x;
    }
    y->parent = x->parent;
    if (x->parent == t->nil) {
        t->root = y;
    } else if (x == x->parent->left) {
        x->parent->left = y;
    } else {
        x->parent->right = y;
    }
    y->right = x;
    x->parent = y;
}

좌회전(Left-Rotate)

right rotate의 과정과 대칭이다.

과정이 right rotate와 완벽하게 대칭이기 때문에, 부연 설명은 적지 않았다.

구현(3) (left rotate)

void left_rotate(rbtree *t, node_t *x) {
    node_t *y = x->right;
    x->right = y->left;
    if (y->left != t->nil) {
        y->left->parent = x;
    }
    y->parent = x->parent;
    if (x->parent == t->nil) {
        t->root = y;
    } else if (x == x->parent->left) {
        x->parent->left = y;
    } else {
        x->parent->right = y;
    }
    y->left = x;
    x->parent = y;
}

rotate

전체 과정을 보았다면, 이진 탐색 트리에서 한 노드의 각 자식들이 가지는 특성은 그대로 유지된다는 사실을 확인 할 수 있을 것이다.

Left Rotate를 예로 들면,
는 y의 왼쪽 자식에서 x의 오른쪽 자식이 된다.

y의 왼쪽 자식이었던 의 대소관계는 이었을 것이고,
이는 x의 오른쪽 자식인 가 이어야 한다는 조건을 항상 만족한다.

x와 y의 부모-자식관계가 변경 가능한 것도 마찬가지이다.

y가 x의 오른쪽 자식일 때의 x, y의 대소관계 ( ) 와
x가 y의 왼쪽 자식일 때의 x, y의 대소관계 ( ) 는 같다.

그렇기 때문에 rotate는 "이진 탐색 트리"의 특성을 유지한 채로 node를 회전시킬 수 있다.

[2023 (상반기) Dev-Matching : 백엔드] 코딩 테스트 후기

완성 — Sun, 26 Mar 2023 11:31:22 +0900

환경

규정

외부 IDE 사용 불가, 인터넷 검색/오픈북 참고 불가

나는 올해 처음 데브 매칭을 신청했지만,
작년 하반기 후기들을 보니 규정이 조금 더 엄격해진 것 같다.
작년에는 인터넷 검색 및 오픈북 참고가 가능했고, 외부 IDE 사용 또한 가능했지만
올해에는 이 두가지 항목이 테스트 이행 중 위반 행동으로 바뀌었다.

응시 환경

화면 공유 + 화상 감독

화면 공유로 현재 화면을 공유한다. 구글 미트에서 사용하는 전체 화면 공유 기능과 동일하다.
테스트를 진행하는 동안 응시자의 얼굴, 허벅지, 모니터, 키보드 등이 나오는 화면을 실시간으로 공유해야 한다. 지원 시 안내되는 모바일 어플리케이션을 설치하고 안내 방법을 확인하면 쉽게 할 수 있다.

코딩 테스트

언어 : 파이썬 사용
문제 : 알고리즘 3문제 + SQL 1문제
결과 : 3솔(알고리즘 3)

1번: 자료구조 이용, 구현

사실 해당 문제에서 요구하는 정해가 이것인지는 잘 모르겠지만,
일단 돌아가게 구현하자는 생각으로 자료구조를 적절히 이용해서 풀었다.
예상하던 1번 문제의 수준 보다는 생각이 필요한 문제였고, 시간을 많이 썼다.

2번: 완전 탐색

경우의 수를 구하는 문제였고, DFS를 이용한 완전 탐색으로 풀었다.
중간에 인자를 잘못 넘겨주는 실수를 해서 조금 해맸다..

3번: DP, 메모이제이션

마찬가지로 경우의 수를 구하는 문제였다.
처음에는 2번과 마찬가지로 완전 탐색으로 구현했지만 예제 입력을 제외하고는 시간 초과가 발생했다.
생각을 조금 더 해보니 이전에 계산한 경우의 수를 이용해서 현재의 경우의 수를 계산할 수 있었고,
DP 테이블을 이용해서 풀었다.
발상의 전환이 조금 필요한 문제였던것 같다.