'설계'에 해당되는 글 2건

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

내 개인연구 실험을 위해서 개발하고 있는 서비스 인지 네트워크 아키텍처에서, flow 기반 라우팅 모듈과 traffic shaping 모듈 각각의 모듈 테스트를 성공한 지 어느새 2주 정도가 지났다. 그 외에도 이웃 노드들의 link quality를 실시간으로 측정하는 모듈은 진작에 몇 개월 전부터 완성되어 있었고, 서비스의 요구사항을 인식하는 부분도 오래 전부터 조금씩 완성도가 높아져 있는 상태였다.

하지만 이 모든 것을 연동해서 실제로 서비스가 요청하는 경로 하나를 만들어 내는 것까지 검증하는 연동 테스트에서 계속 시간을 소비하고 있다. ㅜㅜ 모듈 테스트에서 예외상황을 처리한 줄 알았는데 알고 보니 잊고 처리하지 못한 부분에서 기다렸다는 듯이 에러가 발생하고, 미처 생각지 못한 파라미터 값의 불확실성으로 인해서 예외 상황도 새로 생겨났다.

나름대로는 최선을 다해서 치밀하게 코드를 짜려고 했지만, 그리고 최대한 모듈들 간에 인터페이스를 미리 맞춰 두려고 했지만, 결국 실제로 모듈의 기능을 구현/개선하는 과정에서 미리 약속해 둔 인터페이스가 변경되는 일도 발생한다.

설계 단계에서부터 명확하게 잘 하는 것이 중요하다는 것을 피상적으로는 알고 있지만, 현장에 뛰어들어서 직접 코딩하다 보면 그게 말처럼 쉽게 되지 않는다. 설계를 잘 하려고 해도, 커널에 근접해 있는 각종 네트워크 기능들을 충분히 이해하는 상태라야 가능한 영역이 있어서 어려움을 겪곤 한다. 일단 요구사항만 주어진 채 달려들어서 user level 프로그램의 입장에서 구현을 시작하다 보면, (나는 서비스를 도와 주는 미들웨어를 개발하는 입장이니까 일차적으로 user level API에서 Kernel level로 메세지가 전달되는 구조이다.) 커널 영역에서는 실제로 더 많은 세부사항들을 정의해 주어야 하고, user level에서 제시하는 정보가 부족하기 때문에 제대로 작동하지 못하는 경우가 생긴다. 결국 다시 user level 모듈부터 재설계를 해서 다시 Kernel level에 제대로 모든 정보가 흘러들어가는지 확인해야 한다.

두세 번 이렇게 반복하면 설계 단계에서 무슨 정보를 줘야 하는지는 확실해지긴 하지만, 그 다음으로 겪는 어려움은 실제로 주어진 정보를 가지고 원하는 기능이 작동하도록 구현을 하는 것이다. 더 자세히 얘기하자면, 원하는 기능이 "효율적으로" 작동하도록 구현하는 것이다. 사실 효율성이라는 것도 겪어보지 않은 작동 과정을 상상하면서 어디서 어떤 비효율이 발생하는지 예상할 수 있어야 하는데, 그게 잘 상상이 되지 않는 것이 문제다. 실제로 어느 정도 의미 있는 데이터의 범위를 갖고 돌려 보고 나서야 어느 과정에서 비효율이 발생하는지 알 수 있게 된다.

내가 1년 정도만 더 일찍 지금과 같은 노력을 시작했으면 좋았겠다는 후회가 될 때도 있지만, 지금이라도 제대로 실험환경을 구축하고 역량도 키워가는 과정이라는 것에 위안을 삼으며 마음을 다잡곤 한다. 박사과정 학생 신분으로 연구를 자유롭게(?) 계속할 수 있는 기한도 이제 많지 않은데, 그 전에 최대한 경험치와 역량을 쌓고 싶다. 그 동안의 더디게만 올라가던 learning curve가 이제 조금 가파르게 상승할 것 같은 기대감이 생기는 시기에 와 있는데, 이번에 실험환경 구축이 잘 되면 꼭 좋은 논문을 만들어 내야겠다. 일단은 급하게 써야 하는 논문부터 먼저 만들어 내고... ㅜㅜ