논문을 제출하고...

드디어 끝...?

드디어 근 1년 간 진행하던 프로젝트를 논문으로 완성시켜서 학회에 제출했다!

지난 2학기 중에 바쁠 때는 시간 투자를 별로 못하기도 했고, 올해 초부터는 다른 프로젝트에 팀원으로 참여하기도 해서 모든 시간을 여기에 쏟지는 못했지만, 그래도 정말 오랜 시간 붙잡고 있던 걸 끝내서 너무 후련하다. (사실 너무 오래 끈 것 같다는 느낌이 들기도 하다. 어느 순간부터는 진행이 더뎌져서 힘이 잘 안 나더라... 한 번 할 때 파바박 빠르게 진행해야 추진력도 더 생기고 성취감도 잘 느껴지는 것 같다.)

최근 한 달 동안은 실험들 계속 돌리면서 글쓰기 작업하느라 너무 바빠서 운동도 못하고 사람도 못 만나고 맨날 밤 늦게까지 연구실에만 쳐박혀있었는데, 이제 끝났으니 좀 쉬어볼까?

라고 생각했지만 그 동안 미뤄왔던 각종 연구실 잡일들이 많이 있어서 계속 바쁠 듯하다.

 

 

느낀 점

논문의 퀄리티를 떠나서, 어쨌든 연구의 한 사이클을 쭉 체험해보면서 배우고 느낀 점이 많다.

너무 많아서 여기에 상세하게 다 적기는 힘들고, 몇 개만 정리해보자면...

 

1. Writing

나는 너무 구구절절하게 설명하는 습관이 있다는 걸 깨달았다.

상대를 이해시키는 게 목적이라면 괜찮은 방법이지만, 논문은 설득하는 글이라는 것을 잊지 말아야 한다. 대부분 문단에는 '설명'이 아닌 '주장'이 담겨야 하고, 주장의 핵심 내용을 문단의 첫 문장에 임팩트 있게 드러내야 한다. 즉 top-down 방식으로 작성하도록 하자. (사실 초등학교 국어시간부터 배우는 아주 기본적인 글쓰기 이론인데 생각보다 잘 안되더라...) 설명하는 문단이 너무 많아져버리면 글에 재미가 없어지고 루즈해진다.

그럼에도 불구하고 내가 계속 구구절절 설명하려고 하게 되는 이유는, '그렇게 하지 않으면 독자들이 이해를 잘 못하지 않을까?' 하는 우려 때문이었는데, 그런 우려는 조금 내려놓아도 될 듯하다. 독자들(리뷰어들)은 이 분야에 어느 정도 지식이 있는 사람들이기도 하고, 당장은 이해 안되더라고 뒷부분을 읽다보면 자연스럽게 이해하게 될 것이다. 뒤쪽에서 그렇게 자연스럽게 이해하도록 만드는게 저자의 역할이기도 하고... 사실 내가 논문 읽을 때를 생각해봐도 대다수의 경우, 읽다보니 앞 부분의 말들이 이해되던 때가 많았던 것 같다. 그러니 너무 걱정하지 말 것.

 

2. 차별점 확보하기

작업을 하면서 계속 내 논문의 contribution이 크지 않은 느낌을 계속 받았다. 잘 생각해보니 원인은 크게 두 가지였다.

 

흔한 주제

내 논문의 주제는 object detection & tracking이라는 아주 흔하디 흔한 주제였다. 기술적으로 상당히 성숙한 분야여서, 어지간한 거는 이미 다 나와있고, 웬만큼 신박한 거 아니고서는 임팩트를 주기 어려운 분야이다. 아마 리뷰어들도 제목에 "object detection"이 들어가있으면 '또야...?' 라고 생각할 것이다. 

이런 상황에서 차별점을 만들어내는 방법 중 하나는, 문제 상황을 더 세분화/구체화해서 새로운 문제 상황과 챌린지들을 만들어내고, 그걸 푸는 게 왜 중요한지, 내 시스템이 그걸 얼만큼 해결해주는지 말해주는 거다. 예를 들면, 내 논문은 단순히 object detection 문제를 푸는게 아니라, "리소스 제약이 심한 모바일 디바이스"에서 offloading 없이 "고화질의 비디오"에 대해 실시간으로 처리하는 문제를 푼다. 고화질 + 모바일 디바이스 라는 제약이 생기면서 computationally lightweight 해야 한다는 큰 제약이 생기고, 이로 인한 챌린지들이 생겨나게 된다. 그 챌린지들을 명확하게 제시하고 풀어준다면 조금이나마 novelty가 드러나는 것 같다.

 

핵심 approach의 개념화 부족

열심히 아이디어들을 내서 그럭저럭 괜찮은 시스템을 만들어놨는데, 그걸 잘 설명하지 못하면 말짱 꽝이다. 그게 바로 나에요...

교수님께서 가장 많이 도와주신 부분인 것 같은데, 내가 만든 기술을 개념화하는 것. 예를 들면, 내 기술 중 하나가 고화질의 프레임에서 tracking이 실패하는 부분을 잘 골라내서 해당 부분만 모아 detection을 돌린다는 건데, 이걸 tracking-aware patching이라는 이름을 붙이고 기존 RoI 기반 방식들과 차별화하는 아이디어를 제공해주셨다. 개념화가 확실하게 되니까 기존 논문들과의 차별점도 더 명확하게 보였다. 

어떻게 보면 '포장'하는 거로 보일 수도 있고 실제로 나도 그렇게 생각했는데, 교수님께서는 이건 실체를 바꾸는 게 아니라 있는 그대로를 잘 구조화해서 설명하는 것 뿐이니 포장과는 다르다고 하신다. 그리고 이렇게 개념화를 하지 않으면, (내가 그랬던 것처럼) 스스로의 일이 별 거 아닌 것처럼 느껴지게 되고, 그러면 별로 열정을 다해서 하고 싶지 않아지는 것 같다.

실제 industry에서도 어쩌면 이게 리더들의 역할일듯 싶다. 테크 리드 같은 사람들이 하는 일이 결국 팀 전체가 뭘 해야 하는지 그 방향성을 정하고, CEO/투자자 등에게 이걸 왜 해야 하는지 설득하고 돈을 따내는 일이다. 설득을 잘하려면 팀이 하려고 하는 일을 잘 설명해야 하고, 그게 바로 개념화를 통한 차별화인 것 같다.

 

3. 잘 안되는 원인 찾기

문제를 설정하고 나면, 아이디어를 내고 그게 잘 작동하는 지 실험해보는 iteration을 반복하게 되는데, 보통 대부분의 아이디어들은 잘 작동하지 않는다. 그러다 아주 운 좋게 어쩌다가 하나 잘 되는 거 얻어걸리면 그거로 논문 쓰는 거다. 근데 이 iteration을 줄이려면 중요한 것이 '이게 도대체 왜 잘 작동하지 않는지' 원인을 파악하는 거다. 일종의 디버깅이라고도 볼 수 있는데, search space가 단순히 코드에서의 버그 뿐 아니라 아이디어 자체의 결함 같은 것들까지 포함한다는 점에서 훨씬 크고, 따라서 어렵다.

그 원인을 쉽게 파악하기 위한 몇 가지 방법들을 구르면서 깨달았는데...

 

단순화

문제 세팅을 최대한 단순하고 통제된 세팅으로 만들어라. 원인이 잘 안 보이는 이유 중 하나는 너무 요소들이 많고 복잡해서 걔네가 전부 복합적으로 작용하기 때문이다. 예를 들면 내 기술이, 물체들이 엄청 작고 많고 빨리 움직이고 서로 교차하면서 occlusion까지 많이 일어나는 비디오들에 대해서 잘 작동하지 않았다? 그러면 일단 좀 더 단순한, 소수의 큼직한 물체들이 천천히 움직이면서 occlusion 현상 정도만 발생하는 비디오에 대해서 실험해보는 것이다. 거기서 잘 되면 조금 더 복잡한 비디오에 대해서 해보고... 이런 과정을 반복하다보면 원인이 좀 더 명확해진다.

 

또, 내가 만든 시스템을 최대한 쪼개서 (각 기술 컴포넌트별로 쪼개고, 컴포넌트 안에서도 피쳐별로 쪼개고...) 그 작은 부분들을 바꿔가면서 실험하자.  마치 개발할 때 unit test하듯이...

 

다방면의 실험

실험 결과도 그냥 '성능' 하나만 보지 말고 더 다방면으로 분석해보기. 예를 들면, 아직 tracking되고 있지 않은 새로운 물체가 있는 영역들을 찾기 위해 프레임의 각 영역들에 priority를 매기고 high-priority 영역들을 잘라내는 기술이 있다. 그러면 "새로운 물체를 탐지하기까지 걸리는 평균 시간"만 보는게 아니라, 잘라낸 영역들이 어떤 영역들인지도 살펴보고, 프레임의 여러 영역들의 priority의 분포도 좀 살펴보고 하라는 것이다.

마치 캐글 대회에서 맨 처음에 EDA하면서 데이터를 요리조리 살펴보는 것처럼, 실험도 다방면으로 하다보면 실마리가 보일 때가 있다.

 

 

 

결론

논문 작업은 생각보다 엄청나게 대단한 일은 아니면서도, 생각보다 해야 하는 것 / 고려해야 할 것들이 많은 일이라는 생각이 든다. 

그리고 여기서 배운 것들이 다른 일을 할 때에도 도움이 많이 될 듯 싶다.

다음에는 알고리즘 연구와 시스템 연구의 의미와 차이 등에 대해 정리해봐야겠다.