[csuhak에서 퍼온 글]
* 나의 코멘트 : 나도 이렇게 정리하고 싶었다....

대개 Research 는 다음의 단계들을 거쳐 갑니다. 반드시 1-6 단계 순서로 이루어지는 것은
아니고, 시간을 겪으면서 한 단계씩 더 Refine 해 나가고 앞뒤 단계를 왔다갔다 합니다.

1. 연구분야 결정
2. 배경 지식, 관련 연구 섭렵
3. 나의 Research problem 결정
4. 나의 unique 한 skill / tool 개발
5. Research problem 에 skill/tool 적용해서 해결
6. 논문 작성 / 발표

한가지씩 조금 구체적으로 적어보겠습니다.

1. 연구분야 결정
교수와 일하기 시작하면 연구 분야는 거의 결정났다고 봐야 합니다. 연구 분야에 따라서 해결해야 하는 research problem이 달라집니다.

2. 배경 지식, 관련 연구 섭렵
가장 좋은 소스는 paper 들입니다. 자기 분야에서 top-conference 2-4개 정도에서 나온 지난 5년간의 paper를 *모두* 훑어보면 연구 동향을 대략 파악할 수 있습니다. 그런데 paper들을 읽을때 무작정 paper 한개에서 주장하는 "research problem"-"solution" 만 이해하면 안됩니다. 많은 paper들은 대개 broad 하게 그룹으로 나눌수 있어서, 각각 paper가 남들과 공유하는 커다란 research problem 을 해결하고자 합니다. 그래서 수많은 paper들을 읽고 이를 category 로 만들수 있어야 합니다. 그렇게 category를 알고 paper를 읽어 나가다보면 가끔 정말 기발한 아이디어를 제시하는 seminal paper 를 찾을 수 있습니다. 그럼 그 paper의 방식에서 확장, 개선시켜 나가는 여러개의 children paper들도 찾을 수 있습니다. 이런 식으로 paper들은 tree를 구성해 나가면서 연구 분야가 형성이 됩니다. 이때 좋은 연구를 하기 위해서는 바로 그런 seminal paper를 쓸수 있어야 합니다. 즉, 남이 제시한 방식을 확장/개선하는 child paper를 쓰는게 아니라, 새로운 branch를 형성하게 하는 아이디어를 제시하는 연구가 좋은 연구가 됩니다. 특히 박사를 5년 정도 한다고 하면, 나만의 branch 를 만들고 졸업하는게 보람도 있고 졸업후 진로도 수월합니다.

두번째 중요한 배경 지식은 paper들 보다는 좀 더 broad 하게 지식을 넓혀가면서 얻어집니다. paper에만 매달려 있으면 시선이 좁아질수 밖에 없습니다. 이미 industry에서 다 해결한 문제를 가지고 연구하는 사람도 academia에 많습니다. 예를 들어 얼마전 학회에 가니 O/s checkpointing 을 누가 발표 했습니다 (정말 오래된 topic이죠). 청중에 있던 잘 나가는 교수가 발표 끝나고 한마디 합니다. 요새 VM으로 되는데, 생각 안해봤냐고...발표자는 이것저것 변명을 하긴 했지만, 사실 질문한 교수가 정확히 짚은 겁니다. industry에서 해결한 "죽은" 문제를 가지고 연구하는 사람도 많습니다. 꼭 자기 분야 아니고 cs의 다양한 새로운 tool들을 알고, 떠오르는 application들을 알고 있으면 남들보다 훨씬 compelling 한 스토리를 paper에서 쓸수 있습니다.


3. 나의 Research problem 결정
Research에서는 이것이 가장 어렵고, 또 가장 중요한 파트 입니다. Research problem 은 쉽게 보면 위에서 얘기한 paper들의 한 branch 를 찾아서 그 branch에서 공통으로 이야기하는 problem을 나의 것이라고 이야기 하면 됩니다. 그렇기 때문에 problem 자체를 찾는건 쉽다고 이야기 할수 있습니다. 하지만 나중에 PhD proposal 을 쓰기 시작하면 알수 있는데, 이게 그렇게 간단한 문제가 아닙니다. 좋은 연구는 problem statement 자체가 novel 해야 합니다. 남들 다 이야기하는 방식으로 problem을 서술하면 거기서 나올수 있는 solution도 뻔합니다. 사람들이 잘 알고 있는 problem 을 새로운 시각으로 해석하고, 이전과 유사하면서도 새로운 (혹은 새롭게 보이는) problem statement를 만들어야 합니다. 혹은 새로운 application, academia에서 모르고 있는 industry의 툴을 사용해서 남들과 전혀 다른 problem을 "창조"해내야 합니다. 제가 써놓고 봐도, 이건 난해하고 어려운 문제죠..

problem 을 결정할때 고려해야 하는건,
1) 이게 *솔직하게* 진짜 중요한 문제인가? 얼마나 많은 paper들이 아무도 신경안쓰는 problem 을 해결하려고 하는지 모릅니다.
2) 이게 정말 Hard problem 인가?
3) 내가 해결할 수 있는가? 혹은, "해결할 수 있을 듯 한가?"

4. 나의 Unique 한 skill / tool 개발
Research problem 을 정의했으면 이제 그것을 해결해야 합니다. 이를 위해선 나만의 skill/tool 을 가지고 있어야 합니다. 사람들이 공통적으로 사용하는 cs의 toolset은 이렇습니다.
* logic proof - 이론적인 연구나, 가끔 시스템 분야에서도 logic proof 로 문제를 해결합니다.
* algorithm - 새 알고리즘을 만들어 낸다거나 dynamic programming같은 잘 알려진 알고리즘을 차용하거나 합니다.
* math - cs에서 잘 모르는 math, statistics 이론을 가져다가 해결합니다.
* implementation - 아예 prototype을 구현하고 실험으로 입증합니다.

이론에 재능있는 사람은 proof 방법들을 사용해서 문제를 해결하면 되고, 프로그래밍 좋아하는 사람은 implementation으로 문제를 해결하면 됩니다.

그런데, 여기에서도 역시 남들이 다 쓰는 방법 가져다가 쓰면 연구의 novelty 가 없습니다. 비슷한 research problem 을 가지고 있던 수많은 똑똑한 사람들은 그걸 해결해 보려고 별의별짓 다 해봤을 겁니다. 이미 다 써먹었던 것 가져다가 또 써 먹으면, 연구에 의의가 없습니다. 그래서 사실, 남들은 잘 모르고 있는 나만의 toolset을 개발해야 좋은 연구가 나옵니다. math 를 잘 하면 cs 수업만 듣지 말고 math에서 cs사람들이 모르는 툴을 배워놔야 합니다. statstics 툴을 배워놨다가 cs의 data에 적용하는 것도 사람들이 많이 쓰는 방식입니다.

research problem과 tool은 이런 비유가 적절할 듯 합니다. problem을 찾아내는 건 마치 나무위에 달린 사과를 발견한것과 같습니다. 남들보다 더 크고 먹음직한 사과를 찾아내는 게 좋죠. 그런데 장대도 손에 들고 있어야 따낼수 있습니다. 남들과 비슷한 길이의 막대기를 들고선 남들이 따내고 남은 부실한 사과들만 딸수 있습니다. 높은 장대를 가지고 있어야 남들이 침만 흘리고 바라본 먹음직한 사과를 따낼 수 있죠.

한가지 주의해야 하는 것은, 항상 "problem first, solution second" 마인드를 유지해야 한다는 점입니다. 제한된 tool을 가지고 있으면 모든 problem이 그 tool을 쓰기 위해 존재하는 것 처럼 보입니다. 혹은 "해결하기 위해 문제를 창조"하는 academia에선 정말 흔하고 고질적인 실수를 할 수 있습니다. 이런 말이 있죠. "If the only tool you have is a hammer, you see every problem as a nail".


5. Research problem 에 skill/tool 적용해서 해결.
3번 4번 과정을 잘 했으면 이 과정은 부지런하게 일하는 과정입니다. implementation 하기로 했으면 부지런하게 만들어서 실험하면 됩니다.

6. 논문 작성
이것은 앞의 1-5 과정과는 또 다른 "art" 입니다. 아무리 좋은 problem statement-solution 쌍도, paper writing 을 잘 못하면 빛이 다 바래고 맙니다. paper 를 잘 쓰는 첫걸음은 남들이 쓴 "좋은" paper들을 많이 읽고, 그 paper들에서 공통으로 발견되는 "pattern" 들을 찾아서 흉내를 내면 됩니다. 교수들은 하도 오래 해먹어서 paper 자체를 잘 쓰는 기술들은 다 있으니까, 지도교수가 이건 많이 도와줄 겁니다.