왜 생각한대로 구현이 안될까? (Logical view vs Physical view)

2022년 가을학기 UIUC에서 CS425(distributed systems) 수업을 듣고 있다. 이 수업은 학부 4학년 과목이지만, 학부때 분산 시스템 수업을 듣지 못한 대학원생들도 많이 수강한다. 나도 그중 하나이다. 특히나 Indy의 CS425는 잘 가르친다고 인기가 많다.

해당 과목은 4개의 Machine Project(MP)를 해야한다. coding intensive한 과목이라고 보면 된다. Shivram Gowtham이라고 하는 인도 친구와 같이 팀으로 MP를 하고 있다. 엔지니어링 실력이 정말 좋은 친구이다. 이번에 Meta에서 오퍼 받았고, Apple하고도 면접을 봤다고 한다. 학부때 거의 중독 수준으로 Algorithm problem solving을 했다고 한다. 그리고 그 친구와 나의 엔지니어링 능력은 확연히 차이가 났다.

 

 

나는 항상 구현이 어려웠다. 지금도 어렵다. 항상 수업에서 설명을 듣고 해당 데이터 구조나 알고리즘을 구현하려고 하면 안되었다. 분명 뭔가 설명은 이해를 한거 같은데, 구현은 안됐다. 계속 코딩을 하다보니 그 이유를 조금은 알 거 같다. 결론부터 말하면 physical view(당신이 이해한 컨셉)를 logical view(구현)으로 transfer하는 능력이 부족하기 때문이었다. 우리는 어떤 컨셉에 관해 설명을 들을때 물리적인 관점으로 설명을 듣는다. 예를 들어 Red black tree 같은 경우 이러한 물리적인 뷰로 배우고 이해를 한다. 가장 직관적인 구현은 노드 클래스를 만들고 노드 클래스는 left child, right child를 가리키는 포인터를 가지고 있고 하는 방식으로 구현을 하는 것이다. 그러나 그냥 1차원 배열만으로도 인덱싱만 잘하면 로지컬하게 동일한 구현을 할 수 있다. 너무 직관적인 구현은 물리적인 뷰를 따라가게 되어있고 나의 경우 종종 구현이 잘 안되는 것을 발견했다.

 

 

이번에 MP2에서 Full membership list를 구현하면서 나는 OOP 방식으로 구현을 하고자 했다.

 

Message, Event, EventQueue를 각각 data structure로 표현했고,

Three Successors는 IP를 가지고 있음으로서 관리를 하려고 했다.

Event를 푸쉬하는 method, Consume하는 메소드를 그대로 Queue를 통해 구현하려고 했다. (직관적으로 생각하면 Queue가 알맞은 데이터구조다.)

Failure detection(time out) 기능은 핑을 날리고 Ack이 날라올때까지 시간을 재서 threshold를 넘으면 failure로 간주하고 등등.

 

physical view를 그대로 logical world에서 구현을 하려고 했다. 여기서 그대로 라는 말의 의미는 physical view를 1대1로 맵핑시켜서 logical 하게 구현을 하려고 했다는 뜻이다. 이 레벨에서 벗어나지 못하면 아직 레벨1 인것이다. 그리고 나는 아직 레벨1.

 

예시 1

Message를 struct로 만드는게 매우 당연해보인다. 그러나 그냥 string으로 Delimiter를 넣어서 만들 수도 있다. 왜 Message라는 physical view는 logical view에서도 struct Message라는 것으로 딱 구현이 되야하는가. 그럴 필요가 없다.

 

좀 더 확 와닿는 예시 2

time out을 timestamp1 - timestamp2로 구현을 하면 어려워진다. 왜냐하면 ping은 계속 날리고 있고 어떤 핑은 ack 오기도 하고 어떤 핑은 ack안오기도 하고 t=1 ping에 대한 ack이 t=2 ping에 대한 ack 보다 늦게 오기도 하기 때문이다. 그래서 time out은 여기서 현재 시간 - 마지막으로 기록했던 시간 으로 하면 안된다. ts2 - ts1 으로 구현을 하며녀 ping을 하나만 던지고 앉아서 ack이 올때 까지 기다리는 구현이 되는 건데, 이건 그냥 다른 방식의 구현이 아니라 잘못된 구현이다. 알맞은 구현 중 하나는 ping은 ping interval로 계속 날리고 연속된 x개의 ping에 대해서 ack이 하나도 안날라오면 time out 인 것으로 구현을 하면 된다. 그리고 연속된 x개를 또 말 그대로 구현을 해서 index를 넣고 incremental하게 올것이라고 기대하고 ping을 보낼때마다 ++를 하고 70이 되면 time out으로 하는 것도 그냥 잘못된 구현이다. 이렇게 직관적으로 생각을 하면 구현이 틀려진다. 알맞은 구현은 내가 받은 ack에 대해서 max ack number를 기록하고 있고, 지금 보내고자 하는 최신(가장 높은 핑 number)를 빼서 그게 70을 넘어가면 time out인 형태로 구현이 되면 physical view를 예쁜 logical view로 구현한 것이라고 할 수 있겠다.

 

좀 더 확 와닿는 예시 3

2번, 3번, 4번 노드가 1번 노드의 Successors(주황색 화살표) 이다. 계속해서 3,4,5 노드는 2번의 successors, 그리고 4,5,6 노드는 3번의 successors(파란색 화살표). 이게 physical view이다. 이걸 그대로 1대1 맵핑하여 logical view에서 구현을 하려고 하면 좀 복잡해진다. 

그냥 아래와 같이 successor 라는 object를 하나 만들어서 각 노드가 가지고 있는 것이다. 실제로 해당 successor와 통신을 하는 것은 ping과 ack 만하고 status update는 successor라고 하는 따로 분리된 data structure에 한다. 각 successor와 해당하는 노드가 같은 ip로 표시만 잘되면 physical view를 여전히 잘 표현하는 logical view인 것이다. Ping은 녹색 object들에게 실제로 socket을 통해 날리지만, 누가 나의 successor인제는 주황색 데이터 구조로 관리를 하고 나의 successor status에 대해서도 successor(주황색) 데이터 구조를 통해 관리를 하면 된다. 이게 구현이 훨씬 깔끔하다. 위와 같은 physical view에서 아래와 같은 logical view를 잘 생각해내는 능력이 부족하면 구현이 어렵다. Shivram은 그걸 매우 잘했다. 많이 부족한 나에게는 이번이 배울 수 있는 매우 좋은 기회이다. 나는 그냥 무작정 physical vie를 많은 data structure와 각각의 행위를 전부 function들로 하나씩 구현을 하려고 했다. physical view는 logical view로 그대로 옮기는 것이 안된다. 우리가 이차원 삼차원으로 하는 생각은 코드로는 그대로 되지 않는다. 

 

나는 이 physical view to logical view 전환이 아직 많이 부족하다. 이번 글에선 programming은 언어를 배우는 것과 비슷하다고 하는 말을 좀 더 어렵게 나만의 관점으로 해석을 해보았다. Problem defining을 잘해야 solving도 효율적이다라는 점에서 problem defining을 해봤다고 생각하면 되겠다.