반응형

연구에 대한 실험 코드를 고쳐 가며 새로 데이터를 뽑고, 또 문제가 있거나 개선할 부분이 보이면 다시 고치기를 반복하고 있다. 이 과정에서 내가 개인적으로 유난히 시간을 많이 소비하는 단계가 있음을 알게 되었는데, 바로 어떤 설계(design)으로 개선해서 목적을 달성할 것인지 결정하는 단계이다.


예를 들어, 라우팅 프로토콜을 고치는 과정에서, source node가 자신이 트래픽을 보내기 위해서 먼저 경로를 탐색(route discovery)하고 선택해야 하는데, 이러한 과정을 자주 하게 되면 그만큼 네트워크 전체에 부정적인 영향을 끼치게 된다. 이러한 route discovery 자체를 줄이기 위해서 먼저 실제로 route discovery를 몇 번씩 했는지 파악을 할 필요가 생겼다. 이것을 어떻게 기록할 것인지 생각을 해 보았는데,

  1. 그냥 각 source node의 ID로 된 텍스트 파일을 만들고, 매 초마다 route discovery를 몇 번 했는지 숫자를 텍스트 파일에 시간 순서대로 한 줄씩 기록하는 방법
  2. Route discovery 전체를 기록하는 텍스트 파일 한 개를 만들고, 모든 source node가 같은 파일 포인터에 접근해서 시간, 노드ID, route discovery를 수행했다는 flag를 한 줄로 기록하는 방법

위의 두 가지 외에도 다양한 방법들로 기록할 수 있어 보였다.


그런데 나중에 통계를 내고 엑셀 파일 같은 곳에 가져다 쓸 것까지 생각을 해 봤을 때 어느 방법이 가장 좋은지 쉽게 판단이 잘 안 되는 것이었다. 이게 깔끔하게 마음 편한 방법으로 잘 정리가 되지 않자, 이것 때문에 하루 종일 다른 작업을 못하고 그냥 고민만 하고 딴짓만 하다가 시간을 보내고 말았다.


사실은 내가 연구 측면에서 정의한 문제를 해결하는 방법이 아니고, 라우팅프로토콜의 성능을 측정하는 데 필요한 작은 통계 생성 방법일 뿐이고 어떤 설계를 따르던지 어차피 시뮬레이션 성능에 큰 영향을 주지는 않기 때문에 무시하고 한 가지를 얼른 정해서 진행을 해도 되는 것이었는데, 어느 한 가지를 고르는 것이 속 시원하지 못하다는 이유로 연구 전체를 진행하지 못하고 마치 트랩에 걸리듯이 꼼짝하지 못했다.


결국 지금 밤이 되어서 그냥 첫 번째 방법으로 진행해서 얼른 경로 탐색에 대한 기록부터 만들어내고, 그렇게 각 source node별로 만들어진 기록을 합산하는 스크립트를 파이썬으로 빨리 만들어서 붙이기로 했다. 사실 이미 각 노드마다 flow 트래픽 사용량에 대한 통계를 똑같은 방식으로 만들어 내고 똑같이 파이썬 코드로 후처리(post-processing)를 하고 있었기 때문에 기존의 코드를 재활용해서 가장 적은 시간을 들여서 통계를 만들어낼 수 있는 것이기도 했다. (지저분하게 파일 개수가 많아지는 것, ns-3 코드 상에서 파일 포인터가 많아지는 것 외에는 그 어떤 문제도 없기도 하고...)


나는 지나치게 조심스러운 것이 단점이므로, 그냥 가급적이면 조금 더 빨리 결정한 다음, 뒤도 돌아보지 말고 밀어붙인 뒤에 나중에 문제가 터지면 그것을 그 시점에서 재빨리 고쳐 나가서 목적부터 달성하기 위해 노력해야겠다.



그러므로 내일 일을 걱정하지 말아라. 내일 일은 내일 걱정할 것이오. 한 날의 괴로움은 그 날의 것으로 충분하다 (마태복음 6:34)





반응형
블로그 이미지

Bryan_

,