'분류 전체보기'에 해당되는 글 375건

OS: Ubuntu 16.04 (amd64)

우분투에 와인을 설치해 두고 쓰다 보면 몇몇 확장자의 파일에 wine에서 작동하는 어플리케이션들이 "Open With" 메뉴에 선택 항목으로 표시된다.

몇 가지 예를 들어 보면:

txt 파일에서 Open With에 notepad (윈도우 메모장)이 연결되고, 

png, jpg 같은 이미지 파일에는 Internet Explorer가 연결되고,

hwp 파일에는 리눅스용 한컴뷰어 대신 wine에 내장된 한글 워드프로세서가 연결

그외 다수...

우분투에서 wine을 적극적으로 사용하는 경우에는 편리할 수 있지만, 단순한 텍스트 문서를 열고 싶을 때 굳이 wine에 연동된 메모장을 쓰고 싶지는 않을 것이다.

Open With 에 나타나는 wine 기반 윈도우용 어플리케이션 목록을 제거하려면,

텍스트 에디터로 ~/.local/share/applications/mimeinfo.cache 파일을 열고,

"wine-extension-" 문자열이 들어가 있는 라인을 모두 제거한다.

예를 들어, txt 파일에는 wine-extension-txt.desktop과 wine-extension-htm.desktop이 쓰여져 있을 텐데, 이 라인들을 지우고 mimeinfo.cache 파일을 저장한다. 그러면 이후 txt 파일을 마우스 오른쪽 버튼으로 클릭했을 때, Open With에서 더이상 notepad는 보이지 않게 된다.

<참고자료>

[1] https://askubuntu.com/questions/186494/remove-wines-notepad-from-open-with-options

네트워크 시뮬레이터로로 예전부터 1년반쯤 전까지는 QualNet을 써 오다가, 작년부터는 줄곧 ns-3만 쓰고 있는데, 둘 사이에 장단점을 간단히 비교해 볼 수 있을 것 같았다.

주의사항: 주관적인 관점이라서 다른 사용자 입장에서는 의견이 다를 수 있음.

<비용>

*QualNet

 - 대학교에서 University license로 기본 라이브러리만 구매하면 약 1000만원

 - 기본 제공이 안되는 라이브러리 추가 시 약 100~250만원 정도 예상 (LTE, Zigbee 같은 것들이 여기에 해당 ㅜㅜ)

 - 한 번 라이선스 구입하면 무제한 사용

 - 대신 버전 업그레이드 기간에는 제한이 있음. 문제는 시간이 지날 수록 최신 버전을 써야 할 필요가 생긴다는 것. 2010년쯤에 구입했던 5.1 버전에는 기본 제공하는 와이파이 표준이 802.11a/b/g 밖에 없어서 802.11n이나 ac를 테스트할 수가 없었다. 구 버전 사용자가 최신 버전을 쓰려면 본사에 1000달러를 내면 된다고 한다.

 - 멀티코어를 잘 지원해서 시뮬레이션 성능을 높일 수는 있는데, 라이선스 하나에 코어 2개가 최대임. 코어 수 늘리려면 라이선스 더 사야 함(...)

*ns-3

 - 무료 (오픈소스)

 - 버전 업그레이드 되면 그냥 새로 다운받아서 쓰면 됨

 - 오픈소스라서 실시간으로 수정되는 코드를 버전 관리 시스템에서 바로 받아쓸 수도 있다. (물론 그만큼 버그에는 취약. 공식 릴리즈 공지되는 버전만 써도 무방)

<그래픽 유저 인터페이스(GUI)>

*QualNet

 - ns-3에 비해 월등히 좋음.

 - 마우스 클릭만 가지고 가장 기본적인 시뮬레이션 실행이 가능한 수준 ㄷㄷ.

 - 파워포인트에서 도형 배치하고 선 긋듯이 노드들 배치하고, 트래픽은 보내는 곳과 받는 곳 사이에 선을 drag & drop으로 죽 그어 주면 만들어짐. 그 선을 더블클릭해서 패킷 사이즈, 보내는 양, 시작시간 등등 다 설정하면 됨. 각 노드도 더블클릭해서 각각의 네트워크 인터페이스, 프로토콜, IP주소, 그외 각종 설정들 다 바꿀 수 있음.

 - 그림 그리기(?)를 끝내고 시뮬레이션 시작(play 버튼)을 누르면 노드와 노드 사이에 패킷 전달되는 과정, 노드의 움직임, 무선일 경우에는 전송 범위까지 실시간으로 시뮬레이션 시간에 맞춰서 다 표시됨. 보여주는 정보의 종류를 조정할 수 있고, 재생되는 속도도 조정 가능. (물론 최고속도는 컴퓨터의 하드웨어 성능에 비례함)

 - 시뮬레이션 끝나면 결과를 그래프로 볼 수 있는데, L1/L2/L3/L4/어플리케이션 계층 각각에 대해서 통계치를 다 볼 수 있음. 예를 들어 PHY 계층에서 signal 발생시킨 수와 에러율 확인, MAC 계층에서 프레임 전송 수와 실패 재전송 수, 라우팅 계층의 경로 탐색 시도 수, 응용 계층에서의 실제 throughput 이 모든 것을 모든 노드에 대해서 다 확인 가능.

 - 물론 GUI만으로 논문 실험에 쓸 만한 자기만의 방법을 설정해줄 수는 없고, 그 부분은 어쩔 수 없이 코드 수정을 해야 함.

*ns-3

 - GUI가 큰 의미가 없음 (...)

 - 애초에 ns-3에는 시뮬레이션 환경 자체를 설정하는 GUI가 존재하지 않음.

 - C++ 코드로 일단 뭐가 됐든 시뮬레이션을 돌려 본 뒤에야 자신이 만든 네트워크 토폴로지가 어떻게 생겼는지 GUI에서 확인 가능. 왜냐하면 ns-3에서 제공하는 NetAnim 이라는 GUI는 실시간으로 시뮬레이션을 시각화하는 것이 아니고, 시뮬레이션 결과 파일을 읽어들여서 재생하는 역할이기 때문. (스타크래프트의 지난 경기 리플레이로 보는 것과 차이가 없음)

 - 앞으로도 눈으로 보는 대로 시뮬레이션 환경을 만들 수 있도록 돕는 GUI가 나올 확률은 낮음. ㅜㅜ 왜냐하면 퀄넷은 시뮬레이션 환경 자체는 별도의 스크립트 파일로 처리하고, 실제 L1/L2/L3/L4 계층의 행동은 C/C++ 코드로 처리하기 때문에 GUI에서 스크립트 파일을 만들어 주는 것이 가능한 반면에, ns-3는 그냥 모두 다 C++로 코딩해야 되기 때문에.

 - 그나마 ns-3 입장에서 위안이 되는 점은, 토폴로지를 눈으로 확인할 필요가 없고 환경을 조금씩 바꾸면서 수많은 반복 실험을 해야할 때가 되면 GUI를 쓸 필요 없이 커맨드 라인에서 배치(batch)를 돌리게 되니까 퀄넷이나 ns-3나 별 차이가 없게 될 것이라는 점. (퍽이나 ㅠㅠ)

<시뮬레이션 성능(scalability, running time 측면)>

*QualNet

 - 애초에 퀄넷이 처음부터 내세우는 장점이 scalability이고, 기본적으로 모든 코드에 MPI 적용이 되도록 만들었기 때문에 (사용자가 새로 만드는 코드까지 전부) 멀티 프로세서 지원의 편의 측면에서 ns-3를 압도함.

 - QualNet 판매하는 회사 이름도 심지어 Scalable Networks임 (...)

 - GUI에서는 시뮬레이션 시작 버튼 옆에 프로세서 개수 칸이 있는데 그냥 숫자 써주면 끝.

 - 커맨드 라인에서는 "-mp 2"라고 쓰면 알아서 듀얼코어 써서 돌림.

 - 그냥 싱글코어로 돌려도 꽤 빠른 편임.

 - 다만 GUI에서 실시간으로 시뮬레이션 진행 중인 애니메이션 화면을 봐 가면서 실행하면 당연히 느림. (...) GUI에서 눈으로 확인이 되었으면 커맨드 라인에서 돌려야 함.

 - 유일한 단점이 있다면, 코어 개수도 현질을 해야 3개 이상 쓸 수 있다는 점.

 - 또한 라이선스 때문에 한번에 여러 머신에서 여러 프로세스를 돌리는 것이 불가능함. (라이선스 서버 1개가 라이선스 1개를 프로세스 1개에 할당하는 방식이고, 그 동안에는 다른 프로세스가 실행될 수 없는 구조 ㅠㅠ 동시에 여러 머신에서 시뮬레이션을 돌리려면 머신 개수만큼 라이선스가 있어야 함.)

*ns-3

 - ns-3도 퀄넷처럼 이벤트 기반 처리 방식으로 시뮬레이션을 실행하고, MPI 라이브러리를 통해서 멀티코어를 사용할 수 있기 때문에, 구조적인 측면에서는 퀄넷과 큰 차이가 없음. 하지만 사용의 편의가 떨어지는 게 문제.

 - ns-3에서 멀티코어를 쓰려면 사용자가 수동으로 mpi 관련 라이브러리를 미리 설치해야 하고, 자신의 시뮬레이션 코드에 MPI를 쓰겠다는 설정을 또 별도로 작성해 줘야 함. 단순히 argument에 숫자 추가만 하면 되는 QualNet에 비해 쓰기 어려울 수밖에 없음. (인터넷에도 MPI 적용이 안돼서 질문하는 글이 많음)

 - 모든 코드가 다 MPI가 되는 것도 아님. 특히 와이파이 같은 무선 쪽은 MPI가 아직 안돼서 무조건 싱글코어로 돌려야 함. 이게 특히 심각해지는 부분이 ns-3가 가상 머신들을 연동해서 돌아갈 때.

 - 다만 ns-3가 퀄넷에 비해 유리한 상황이 있기는 한데, 똑같은 시뮬레이션 인스턴스를 1개가 아니라 조건이 조금씩 다른 수백~수천 개의 시나리오를 순차적으로 처리해야 할 때. 퀄넷은 라이선스 1개당 1개 프로세스만 존재할 수 있지만, ns-3는 오픈소스니까 그런 거 없다. 원하는 만큼 클러스터에 복제해서 원하는 만큼 얼마든지 프로세스를 돌릴 수 있음. 즉, 개별 시뮬레이션 처리 시간이 오래 걸리는 문제를 동시에 여러 머신과 프로세스를 써서 얼마든지 전체 시뮬레이션 시간을 줄일 수 있음.

<외부 프로그램과의 확장성>

*QualNet

 - 외부 프로그램에서 패킷을 만들어서 퀄넷의 시뮬레이션 네트워크에 주입하는 것이 가능한데, 방법이 편하지 않음. 외부 프로그램과 퀄넷 사이에 패킷을 서로 전달해 주는 코드를 하나 더 만들어야 함. (이것도 C언어로)

*ns-3

 - 리눅스 컨테이너(lxc)를 써서 VM을 만들어서 그 VM들 사이의 네트워크를 ns-3가 시뮬레이션할 수 있음!!

 - ns-3 시뮬레이션 코드 위에 아예 실제로 작동하는 프로그램 소스코드를 그대로 컴파일해서 돌리는 것(Direct Code Execution; DCE)도 가능!!

 - 그러나 위 2개 다 아직 한계가 있음 ㅠㅠ

 - VM 방식은 호스트 머신(리눅스)에 브릿지 인터페이스에 tap을 붙여서 ns-3와 연결되는데, 여기서 약간씩 딜레이가 발생함. VM들은 자기들만의 clock을 갖고 있는데 ns-3에 약간이나마 늦게 패킷이 흘러들어오면 그걸 ns-3 프로세스가 시뮬레이션으로 처리하고 다시 VM들에게 돌려주는 과정에서 각 VM은 이미 자기 시간이 흘러가고 있음. 결국 실제 환경에 비해서 delay가 커질 수밖에 없는 구조.

 - 게다가 설상가상으로, 와이파이 같은 무선 네트워크 환경에 저렇게 VM을 붙이면 ns-3가 아직(2017.04.15 기준) 무선 환경을 멀티코어로 처리하지 못하기 때문에 무선 환경의 신호 세기, 간섭, fading, propagation 이런 것들을 다 싱글코어에서 계산해야 됨(......)

 - 그래서 VM 10개를 만들고 와이파이 애드혹 네트워크를 시뮬레이션했더니, 각자 1초에 하나씩 hello 메세지를 broadcast하기만 하는데도 그 상태로 ping을 날리면 20초가 넘어가는(...) 도저히 실험 불가능한 상태가 됨. 지못미 ㅠㅠ

 - VM에 대한 대안으로 나온 것이 DCE인데, 이것도 사실 C++로 개발된 프로그램만 취급함. C++ 소스코드를 가져와서 ns-3에서 호환될 수 있게 g++ 옵션을 조금 추가해서 빌드하면 되는데, 그렇다고 모든 시중의 C++ 프로그램이 다 빌드되는 것도 아님. ns-3 커뮤니티 얘네들은 자랑스럽게 iperf를 소스코드 수정 없이 그대로 빌드해서 갖다쓸 수 있다고 자랑하는데, tcpdump 같이 더 심각한 일을 하는 소스코드는 아예 컴파일 불가능 ㅜㅜ

 - 내가 직접 소켓 프로그래밍으로 C++ 프로그램을 만들어서 돌리려고 해도 생각보다 지원 안되는 코드가 많아서 코딩에도 제약이 있음. 이게 뭐야...

 - 결론적으로, 분명히 확장성이 좋아 보이는데 결국 실제로 제대로 써 보려고 달려들면 퀄넷이나 ns-3나 안되는 건 마찬가지임 ㅠㅠ

<통계(Statistics)>

시뮬레이션 결과에 대한 통계를 내 주는 부분은 양쪽 다 방식도 다르고 장단점도 분명해서 어느 한 쪽이 유리하다고 볼 수는 없다.

*QualNet

 - 위의 GUI 부분에도 언급되어 있듯이, 물리 계층부터 응용 계층까지 각 계층에서 낼 수 있는 모든 통계를 항상 만들어 줌. GUI에서 그래프를 그려줄 때 참고하는 파일이 .stat 파일이고, 시뮬레이션 1개를 실행하고 나면 자동으로 생성되기 때문에 이 .stat 파일을 직접 파싱해서 원하는 통계치를 계산하는 것도 가능.

 - 모든 계층에 대한 통계가 다 나오는 점이 의외로 디버그에 유용할 때도 있음. 가령 응용 계층에서 패킷을 모두 전송 실패했는데 물리 계층에서 받는 signal이 분명히 기록되어 있다면 중간의 라우팅 계층 같은 부분에서 기대와 다르게 패킷을 drop했을 수 있으므로, 라우팅 계층의 logic을 살펴보는 식의 접근이 가능함.

*ns-3

 - 시뮬레이션 환경에서 생성하는 노드 각각에 대해서 .pcap 파일을 자동으로 만들도록 설정할 수 있는데 (코드에 pcap output을 만들어 달라고 1줄 추가하면 됨), 이 pcap 파일을 Wireshark에서 바로 보거나 그래프를 볼 수도 있고, tcpdump에서 약간의 규칙을 적용해서 원하는 정보를 원하는 포맷으로 만들어 쓸 수 있음.

 - pcap 파일을 기반으로 패킷을 분석하고 통계를 내는 부분은 오픈소스 도구들도 여럿 존재하기 때문에 퀄넷의 자체 포맷(stat)에 비해 유리한 점이 있음.

FireChat이라는 모바일 앱은 스마트폰들이 블루투스와 Wi-Fi P2P 기술을 이용해서 통신망 인프라스트럭쳐(3G, 4G/LTE, Wi-Fi 액세스 포인트 등) 없이도 서로 연결된 기기들끼리 메세지를 주고받을 수 있게 도와준다.

FireChat은 홍콩에서 한창 시위가 진행될 때 갑자기 유명해졌는데, 그 당시에 좁은 지역에 사람들이 집중적으로 모여들면서 셀룰러 망이 감당할 수 있는 수준을 넘어서면서 통신이 잘 되지 않자 시위대 구성원들 사이에 인프라 없이 서로 통신하기 위해 설치하기 시작하면서 단기간에 50만 다운로드를 기록했다.

Wired 기사 [1]에 의하면, FireChat의 개발사인 OpenGarden에서 필리핀 지역에 메쉬 네트워크를 실현하기 위해 노력하고 있다.

그런데 전통적인 무선 메쉬 네트워크(Wireless Mesh Network; WMN)의 개념에서는 어딘가에 고정적으로 설치되는 메쉬 라우터(mesh router)가 필요하다. 기존의 AP와 비슷하면서 AP들 사이에 무선 링크가 존재하는 것이 차이점이다.

그런데 태풍 때문에 재난상황이 자주 발생한다는 필리핀 도시 지역에 고정된 메쉬 라우터를 설치한다면, 셀룰러 망과 같은 인프라가 망가질 때 메쉬 라우터도 함께 망가질 가능성이 높을 텐데 어떻게 메쉬 네트워크를 구현하는 것일까?

알고 보니, 일부 사람들이 GreenStone이라고 부르는 중개기를 들고 다니면서 메쉬 네트워크를 유지하는 개념이라고 한다.

(GreenStone, image from TechInAsia [2])

GreenStone은 현재 필리핀의 Makati 지역에서 시범적으로 운영되고 있는 듯 하다.

ISM 대역의 블루투스 라디오를 쓰고 주변의 FireChat 앱에서 발생하는 메세지를 모아 뒀다가, 이동하면서 새롭게 연결된 FireChat 사용자들에게 저장된 메세지를 전달하는 역할을 갖는다.

이것은 어떤 의미에서 보면 "지연 허용 네트워크(Delay-tolerant Network; DTN)"에 더 가깝다. 메세지가 마치 물리적인 편지와 같이, 실시간으로 즉시 전달될 수는 없더라도 언젠가 당사자(destination node)를 만나게 되면 비로소 전달되게 하는 기술이다.

홍콩 시위대들이 FireChat을 사용할 때에는 밀집되어 있는 수많은 사용자들이 인프라 없이 메세지를 서로 전달하는 것(일종의 flooding)이 강조되었다면, GreenStone은 밀집되어 있지는 않지만 도시 전역에 퍼져 있는 FireChat 사용자들이 시간이 좀 걸리더라도 서로 메세지를 교환할 수 있도록 하는 데 초점을 맞추고 있다.

DTN 기술은 처음 소개된 이래로 지금까지 꾸준히 연구자들의 주목을 받아 왔지만, 항상 실제로 어디에 쓰이는지에 대해서 의문점이 따라다녔었다. 그런데 필리핀에서 메쉬 네트워크와 DTN이 결합된 듯한 형태로 실제 사용 예가 나타나는 것은 고무적인 일이다.

OpenGarden 사는 통신사의 입장에서는 눈엣가시 같은 존재감을 점점 나타내고 있지만, 사용자들의 입장에서는 안정적인 성능(QoS 같은 것)을 포기하는 대신 무료로 주변과 통신할 수 있는 기회를 제공하는 고마운 대상이 될 수 있다. (항상 그렇다는 것은 아니다. 특히 우리나라처럼 셀룰러 망이 지나치게 잘 되어 있는 곳에서는 굳이 이런 느리고 불안정한 메세징 앱을 쓰려고 하지 않을 테니까.)

하지만 적어도 스마트폰에 기본적으로 내장된 ISM 대역의 라디오 기술을 이용해서, 가끔 통신망 인프라 없이 직접 무선 라디오를 가지고 필요한 사람들과 통신이 가능하게 해 주는 것은 중/장기적으로 사용자에게 좋은 영향을 끼칠 수 있다.

분명히 내 눈앞에 있는 전자기기가 내 스마트폰과 마찬가지로 와이파이/블루투스를 내장하고 있는데, 그냥 서로 직접 얘기하게 만들어서 원하는 일을 할 수는 없을까? 이 질문에 대한 여러 해답 중의 하나가 OpenGarden의 사례가 될 것으로 기대한다.

<참고자료>

[1] https://www.wired.com/2015/10/giant-network-for-free-messaging/

[2] https://www.techinasia.com/firechat-messaging-app-disaster-tool

(ㅇ.ㅇ)

유튜브에서 지난 방송을 찾아서 보다가 중간에 나오는 광고를

건너뛰기 하지 않고 끝까지 본 건 이게 처음이다. 

애니메이션 광고는 일본에서 워낙 많이 있지만

우리나라에서도 이런 고퀄 애니메이션 광고를 보다니 신기함.

알고보니 이것 말고 전편도 있던데,

유튜브 댓글을 보니까 전편 주인공이 여기에도 나온다고 함. ㅋㅋ

오늘따라 받지 않아도 될 스트레스를 받는다.

대수롭지 않게 생각하고 넘어가면 넘어갈 수도 있지만, 괜히 오늘따라 굳이 기억 속에서 끄집어 내서 생각하며 혼자 답답해진다.

뭐 이런 날도 있는 거지.

공대 대학원 연구실이 운영의 대상인지부터 먼저 결정해야 하겠지만,

적어도 우리 연구실은 "운영"의 대상이 맞다.

과제는 정부과제와 산학과제를 막론하고 대부분이 여러 연구실이 한데 모여서 만드는 (대학교 치고는) 중형~대형의 과제인데, 지금껏 해온 그러한 과제들 중에서 95% 정도는 우리 연구실이 총괄을 맡아 왔다. 즉, 과제에 참여하는 교수님들은 여러 명이지만, 그 중에서 총괄책임자는 항상 우리 지도교수님이라는 의미다.

지금도 3개의 과제 중에서 총괄의 역할을 해야 하는 과제가 2개이다.

내 기준에서도 지금껏 내가 직접 제안 단계부터 종료 때까지 운영한 과제 1개, 제안 단계부터 이제 곧 종료 예정인 과제 1개, 중간에 연구실 선배로부터 이어받은 총괄 과제 1개, 이외에 떨어졌지만 총괄 연구실로써 제안했던 과제들만 해도 매년 2개 정도는 됐으니까 도대체 몇 개야...

박사과정이 되고 나면 과제 말고 석사과정 학생도 "운영"을 해야 한다. 같은 처지의 학생이 무슨 운영일까 하는 의문이 들겠지만, 우리 연구실은 석사과정들이 서로 겹치는 연구주제 없이 모두 단독으로 하고 있고, 이 전통은 예전부터 지금까지 있어 왔다.

당연히 석사를 거쳐 온 지금의 박사과정들도 서로 각각 자기 주제를 갖고 있으며, 그 주제가 또 석사과정들과 다르다. 즉, 연구실 학생 전원이 자기 연구주제를 들고 있는데, 문제는 그 범위가 상당히 넓은 것이다.

분산 시스템을 하는 연구실이다 보니 IoT 시스템, 네트워크 아키텍처, 상황인지, 인공지능, 사회심리학(신뢰도, 공간의 사회성) 등 시스템에 필요한 굵직한 컴포넌트, 그 안에서도 중요한 주제 하나하나를 다 다루고 있다. 전체 시스템 구축에 필요한 중요한 연구주제를 다루는 것은 좋은데, 서로 겹치는 주제가 없다 보니 지식이 누적된다기보다는 매번 그 연구를 처음 시작하는 석사 2년차 학생이 죽어라 공부해서 기반을 만들어야 한다. 그리고 이제서야 연구를 처음 해보는 석사과정 입장에서 뭘 어떻게 해야할 지도 잘 모르는 상황이니까 박사과정이 "사수" 개념으로 붙어서 연구 방법부터 진행 상황 하나하나를 살펴 보고 알려 줘야 한다. 그 뒤에 지도교수님이 확인하시고 코멘트를 주신다.

박사과정이 본인 주제 안에서 커버할 수 있는 내용 중 하나를 석사과정이 연구한다면 이런 구조는 오히려 장점이 되겠지만, 우리 입장에서는 석사과정이 거의 매년 그 때의 IT 트렌드에서도 새롭다고 느끼는 부분을 맡아서 연구하기 시작하면 박사과정은 자기 졸업연구 주제와 단기적으로는 관련이 없는 내용을 같이 공부할 수밖에 없는 상황이 된다.

게다가 그렇게 봐줘야 하는 석사과정이 1명도 아니고 2-3명 정도 된다면? 여기에 또 때때로 학부생 인턴을 모집해서 연구과제에 필요한 구체적인 일을 시키려면 또 그 인턴도 어느 정도 가르쳐야 한다.

당연히 이 모든 일을 지도교수가 직접 하는 것은 불가능하기 때문에 박사과정이 할 수밖에 없는 것은 맞는데, 하더라도 박사과정 본인의 영역 안에서 잘 하는 부분에 대해서 지식을 전수하는 것도 아니고 같이 공부해 나가는 과정에서 이끌어야 하니까 시간과 노력이 많이 들 수밖에 없다.

뭐 지금 좀 힘들어도 내가 졸업하고 나서는 할 줄 아는 것도 많고, 연구과제 제안서와 운영도 이제 익숙하고, 내 연구주제가 아닌 분야까지 이해할 수 있게 되니까 직장에 가면 좋은 자산이 될 것이라는 기대감 정도는 갖고 있다.

하지만 내 분야에서 SCI 저널 하나 제대로 써내는 데에만 해도 상당히 많은 집중력과 시간이 투입되는데, 일주일 중에 절반 이상을 과제 관리와 학생들 관리에 소비하고, 남은 시간 중의 절반 정도는 가정에 최소한으로 충실해야 하고, 그제서야 남은 시간(그마저도 피곤에 쩔어 있는 상태로 확보하게 되는 시간)을 가지고 내 개인연구를 해야 한다. 가끔은 이렇게 내가 희생해야 하는지에 대해서 정말 속상하기 그지없을 때가 있고, 그게 바로 오늘이다.

시스템을 다루더라도 그 중에 정말 중요한 주제 1-2개만 가지고 연구실 전체가 집중적으로 연구를 해서 세계적으로 좋은 성과도 만들어 내고, 그 좋은 논문 실적으로 다음 과제를 따오는 데애도 도움을 얻으면 얼마나 좋을까? 그런데 우리는 정말 중요한 주제가 지나치게 많다. 이쯤 되면 지도교수님의 욕심이 아닌가 하는 생각이 들기도 한다.

기본적으로 연구실에 박사과정이 한 6명 정도가 된다면 해결될 것 같은데, 지금은 그 절반밖에 있지를 않으니, 그 소수의 박사과정들에게 더 큰 무게가 지워지는 꼴이다. 게다가 그러한 박사과정들 중에서 가장 연차가 높은 내가 연구실 "운영"에 대해서 걱정을 안 할수가 있을까?

더 허탈한 점은, 그렇게 열심히 연구실을 "운영"한다고 해서 그렇게 많이 남는 게 없다는 점이다.

석사과정들은 1년차 때는 연구에 대해 거의 모를 뿐더러 수업을 열심히 들어야 하니까 한계가 있고, 본격적으로 자기 졸업연구를 수행하는 2년차부터 본격적으로 가르치기 시작해서 6개월~1년 정도 지나면 이제 스스로 국제학회 논문 한 편 정도를 쓸 수 있는 상태가 된다. 하지만 그렇게 키워놓으면 거의 다 취업하러 나간다.

차라리 회사라면 신입사원을 교육시키고 키워서 활용하기도 하고, 그들이 승진해서 회사에 보탬이 될 텐데, 연구할 수 있는 상태로 만들어 놓으면 요즘은 전산 분야가 취업도 잘 되고 연구에 대한 관심을 갖는 학생이 많지가 않으니까 거의 다 나가고 없다. 이러니 연구실을 열심히 "운영"해 봐야 무슨 보람이 있는가? 차라리 지도교수님 입장에서는 본인의 제자가 어디에 가서든지 성공하면 보람이 있지만, 선배 입장에서 후배가 같은 연구실에서 연구활동으로써 도움을 주지 않는 이상 졸업해서 나가면, 나 또한 졸업생이 되기 전까지는 아무 의미가 없는 것이다.

그럼에도 불구하고 운영이라는 행위를 안 할수가 없는 이유는, 내가 책임감을 갖고 돌보지 않으면 결국 교수님이 석사과정 2년차부터 다른 후배들까지 직접 개입해서 잘못된 부분을 지적하셔야 하는데 그게 그렇게 평화롭게(?) 이루어지지는 않는다는 것이다. 여기서 교수들 각자의 성격의 차이에 따라 그 지도의 강도에 차이는 있을지언정, 어느 교수나 속으로 느끼는 심정은 마찬가지일 것이다: "도대체 왜 이따구야?" 그러한 "이따구" 소리를 최대한 줄이고 그나마 서로 토의를 할 만하게 중재하는 게 결국 박사과정의 역할이 될 수밖에 없다.

답답하다.

언젠가 기회가 된다면 분명히 지도교수님께 내 의사를 전달할 것이다.

시스템을 다루더라도 선택과 집중을 좀 하자고.

과제도 2개 정도 선정됐으면 거기서 더 늘리지 좀 말자고.

내 졸업연구와 멀어도 너무 지나치게 먼 과제에 총괄 좀 맡지 말자고.

석사과정들 연구 주제 통제 좀 해서 그냥 박사과정의 sub-item으로 집중해서 일단 그 안에서 실험도 같이 하고, 박사과정의 논문 작성에도 공동저자로 참여해서 써 보고, 그 다음에 같은 주제에서 파생되는 문제를 찾아서 자기 연구주제로 쓰도록 만들자고.

...사실 지금 당장에라도 때려치고 나가면, 차라리 알고리즘과 코딩 연습 조금 해서 최근 트렌드에 맞는 기술들 조금 익히면 뭐라도 할 수 있을 것 같다. 소프트웨어 엔지니어가 지금처럼 호황인 시대에 나 자신이 썩어가는 것 같은 기분이 들 때도 많다. (나는 교수 될 생각은 그다지 없다. 그나마 연구원 쪽이나 회사에서도 박사급으로 갈 수 있는 직군에는 생각이 좀 있어서 참고 남아 있는 거지.)

도대체 박사학위가 뭐라고, 정말 더러워서 지금까지 공부한 게 아까워서 내가 참고 이거 끝장을 내겠다고 남아 있는 이 상황에서, 연구실 운영에 대한 정답을 찾아낼 수 없는 어느 박사과정의 한탄이다.

같은 연구실 내의 박사과정들 말고 누가 내 고민을 이해해 줄 지 모르겠다.

그래도 가능하다면 우리 연구실과 후배들을 위해서, 내가 진짜 마지막 남은 운영에 대한 책임감마저 버리고 "나만 졸업하면 끝"이라는 생각을 갖기 전에 박사학위를 받고 나갈 수 있기를 간절히 바래 본다.