반응형

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


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


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


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


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


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



반응형
블로그 이미지

Bryan_

,