잡담

좋은 생각 습관

yanggit 2021. 6. 28. 01:41

 

기준

좋은 공부법에 대해서 종종 생각해보고는 한다.

좋음의 기준은

1) 얼마나 효율적으로 학습할 수 있는지

2) 주어진 내용을 얼마나 깊이 있게 학습할 수 있는지

3) 학습을 통해 얼마나 지능 및 사고력 발달에 도움이 되는지

등 여러 가지가 있다.

 

 

"왜 굳이 이렇게...?"

공부를 할 때 항상 능동적인 사고를 하는 것이 중요하다고 느낀다.

눈에 보이는 지식을 그냥 머릿속에 넣는 게 아니라,

해당 내용의 다양한 측면들을 요리보고 저리봐보기도 하고,

기존 머릿속 지식들과 비교하여 모순이 없나 확인해보기도 하고,

abstraction된 low-level detail들은 어떻게 구현되어 있을까 궁금해하기도 하고...

이렇게 머리를 굴리는 과정에서 해당 내용을 더 깊이 있게 이해하게 된다.

 

그 중 특히 내가 도움이 많이 된다고 느끼는 것은,

"이걸 왜 굳이 이렇게 만들었을까?", "나라면 어떻게 만들었을까?" 생각해보는 것이다.

해당 시스템이 만들어진 이유, 만드는 과정에서의 챌린지들을 예측해보는 것.

 

예를 들어, 이번 1학기에 데이터 통신 수업을 들으면서 이걸 많이 해봤다.

컴퓨터 네트워크는 오랜 시간에 걸쳐 만들어진, 거대하고 수많은 디테일들이 들어가있는,

그리고 그 디테일들 하나하나마다 다 나름대로의 실용적/역사적 이유가 있는 시스템이기 때문에 

이런 생각을 계속해서 하게 된 것 같다.

대표적인 몇 가지 예시는 다음과 같다.

 

1. CSMA/CA의 SIFS

WLAN의 CSMA/CA에서 프레임을 전송할 때,

데이터 프레임인 경우 DIFS만큼 대기 후 전송하고, ACK 프레임인 경우 SIFS만큼 대기 후 전송한다.

SIFS는 layer 1을 거치고 ACK프레임을 생성하는 데 걸리는 시간의 상한으로 넉넉잡아 설정해둔다.

또한, DIFS > SIFS로 설정함으로써 ACK 프레임에 우선순위를 준다.

그런데 "ACK프레임이 그렇게 중요하면 ACK 프레임이 만들어지는 대로 바로 보내면 되지 않나? 왜 굳이 넉넉잡아서 SIFS만큼 기다리나?"

하는 의문이 든다.

 

그 이유는 virtual carrier sensing을 위해서이다.

계속해서 physical carrier sensing을 통해 채널이 프리한지 감시하는 일은 에너지 소모가 크다.

만약 "이만큼의 시간 동안은 다른 station 간의 전송이 일어나고 있을테니 그냥 잠자고 있어라"라고 미리 알려줄 수 있다면

굳이 그 시간동안 계속 sensing하는 대신 잠자고 있으면 에너지를 아낄 수 있다.

따라서 ACK 프레임 보내기까지의 시간을 SIFS로 고정해놓고, "propagation delay + SIFS + ... 동안은 채널이 바쁠 거다"라고 선언해놓는 것이다.

이 시간을 NAV라고 한다.

 

2. IP 주소와 MAC 주소

왜 굳이 IP 주소와 MAC 주소를 따로 뒀을까? 그냥 IP 주소로 모든 걸 다 하면 안되나?

  • 물론 둘의 역할이 약간 다르긴 한데, 초기에 설계할 때 하나만으로 모든 것을 다 할 수 있도록 설계하는 것도 가능하긴 했을 거다.
    근데 layer2 와 layer3가 각자 개발되다 보니, 유기적으로 연결된 전체 시스템을 생각하지 못하고, 약간의 중복이 발생한 듯하다.
    근데 이제와서 그 수많은 네트워크 디바이스들을 IP만 사용하도록 바꾸기에는 너무 오버헤드가 크다.
  • layer3 입장에서는 layer2가 MAC 프로토콜이 아닌 다른 프로토콜을 사용할 수도 있고, layer2 입장에서도 마찬가지로 layer3가 IP가 아닌 다른 프로토콜 사용할 수 있다.
    따라서 각자 addressing 기능을 넣은 것.

 

3. Layer 2의 error control과 Layer 4의 error control

왜 굳이 layer2에서도 error control을 하고 layer4 (TCP) 에서도 error control을 할까? 한 곳에서만 하면 안되나?

  • 이것도 마찬가지로 layer2와 layer4가 각자 개발되다 보니까 발생한 중복인듯하다.
    그냥 layer4에서 아주 강력한 error detection을 해주면 layer2의 error control을 없애는 것도 가능할 듯하다.
  • 각자의 local optimum를 찾다보니 global optimum을 놓친 느낌?
    하지만 이렇게 모듈화해야 개발과 유지보수가 쉽게 때문에 어쩔 수 없기도 하다.

 

 

교육 방식

위와 같이 생각하면서 공부를 하다보니,

애초에 교육 방식을 좀 바꿔서, 위와 같은 생각들을 끊임없이 할 수 밖에 없게 해주면 어떨까? 라는 생각이 든다.

현재 대부분의 교육 방식은 수많은 개념들을 쭉 나열하며 가르쳐주면 그걸 이해하는 식이다.

맨 위에 언급했던 "좋은 공부법의 기준" 중 첫 번째인 효율성을 극대화하는 방식이다.

만약 두번째와 세번째 기준을 극대화하는 것이 목표라면 아래와 같은 교육방식을 사용해보는 게 어떨까?

 

예를 들어, 네트워크에서 하나의 layer에 대해 교육해준다고 가정하면...

  1. layer의 세부적인 디테일들을 설명해주기 전에, 해당 layer의 motivation / 목적 / 제약 등만 알려준다.
  2. 해당 목적과 제약에 알맞는 시스템을 학생들이 직접 디자인해본다.
  3. 본인의 디자인을 가지고 시뮬레이션해보며 얼마나 목적에 부합하고 제약을 잘 지키는지 실험해본다.
  4. 시뮬레이션을 통해 발견한 문제점을 개선하고 다시 시뮬레이션하는 과정을 반복한다.
  5. 실제로 현재 시스템은 어떻게 구현되어있는지 확인하고, 본인의 디자인과 비교해본다.

더 크게는, 네트워크가 layer로 나뉘어져있다는 설명도 해주지 말고,

아예 전체 시스템을 만들어보는 것부터 시작할 수도 있겠다.

근데 이렇게 너무 크게크게 시작하면 너무 막막해서 학생들이 밑바닥부터 나만의 시스템을 디자인해내기 힘들 수도 있을 것 같다.

어디까지 알려주고, 어디부터 학생들이 직접 디자인해보게할지를 잘 정해야 할 듯 싶다.

 

이렇게 하면, 현재 시스템이 왜 굳이 그렇게 설계되어있는지 아주 명확하게 이해할 수 있을 것이다.

더 나아가서, 미래에 해당 시스템을 개선하는 일을 하게 될 때, 더 좋은 방향을 제시할 수 있을 것이다.

단점은 이렇게 교육하면 시간이 매우 오래 걸릴 거라는 점...