행복한 대학원생 되기 - 4편: 문제 찾기

행복한 대학원생 되기 연재

1편: 왜 대학원생이 되었는가? (동기) (2015/05/03)

2편: PhD가 되어가는 단계 (2015/05/10)

3편: 수업 듣기 (Coursework) (2015/06/07)

4편: 문제 찾기 (2015/11/07)

5편: Literature Survey (문헌조사)

6편: 박사 자격 시험

7편: 학회와 저널 (2017/07/07)

8편: 논문 리뷰 (2016/05/13)

9편: 논문 쓰기 (2017/01/23)

10편: 지도 교수

11편: 학위 논문과 디펜스

12편: 졸업 후 진로 (2017/01/10)

어제 집에 돌아오는 길 박사과정 학생 한 명이 고충 하나를 털어 놓았다. 지도교수는 새로운 아이디어를 늘 묻는데, 새로운 아이디어가 잘 떠오르지 않는다는 것이다. 그래서, 나도 졸업할 때 까지 새로운 아이디어를 답변 못해서 늘 항상 힘들었다고 이야기를 해주었다.

Library, University of Waterloo

Do you have any interesting/crazy idea? 박사과정 내내 지도교수님께 들었던 질문이었다. 이 질문을 받을 때 마다, 제일 많이 했던 대답이 I have no idea yet.이었다. 이 것도 한 두 번이지, 매번 이 대답을 하는 것도 스트레스라, 미팅 전에 어설픈 아이디어 하나라도 생각해 갈려고 애는 쓰나, 생각에는 한계가 있고 어설픈 생각은 말하기 조차 부끄러웠다. 혹여나 용기내서 말하면, 아니나 다를까 지도 교수님의 표정만 봐도, 재밌는 idea가 아니라 별로 관심 없어 하심을 금방 알 수 있다. 새로운 연구 주제 / 문제를 찾는 일은 정말이지 곤혼스러운 일이다. 그리고 다른 논문 작업 중에는 거기에 집중하느라 새로운 생각을 하는 것도 여간 쉬운 일이 아니었다. 아마 이것은 완전히 독립적이지 않은 일들을 멀티로 잘 하지 못하는 내 성격 탓인 듯도 하다.

그런데, 내가 풀어야 할 문제가 뭔지도 모르는데, 무슨 아이디어가 있겠는가?

물론 지도교수가 idea가 있냐고 하는 질문은, 흥미로운 문제와 아이디어가 함께 있는가를 묻는 질문이겠지만, idea만 계속 물어보면, 나중에는 문제를 풀기 위한 idea가 아닌, 논문을 쓰기 위한 idea를 생각해 내는 현실에 맞닥뜨리는 나 자신을 보게 된다. 하지만, 연구자란 논문을 쓰는 사람이기 이전에, 문제 해결자이다. 문제를 풀기 위해 고민을 하다가 이런 저런 idea들이 떠오르면 시도를 하면 된다. 그리고, 그 idea가 기존에 딴 사람이 한 idea 보다 문제를 잘 해결할 수 있으면, 혹은 아무도 문제라고 생각지 못한 문제가 알고보니 정말 의미있는 문제이고 이 문제를 해결하는 나의 해법이 다른 연구자가 봤을 때 납득이 되는 해법이라고 생각이 되면, 그 때 논문을 쓰면 된다. 이런 맥락에서, idea가 무엇인지 질문을 하기 전에, `중요하고 흥미로운 문제를 찾았는가?' (Did you identify any interesting problem?) 이라는 질문을 스스로에게 먼저 해야 하지 않을까 싶다.

석사 유학을 가기 1년 전, 한국 인터넷의 대부라 불리는 전길남 박사님과 프로젝트를 같이 한 적이 있었다. 그 때 연구나 논문에 대해서 전혀 지식 없었던 나에게, IEEE이나 ACM, Citeceer라는 컴퓨터 사이언스 관련 논문들을 열람할 수 있는 곳도 알려주시기도 했다. 전 교수님은 굉장히 프로페셔널하게 연구하시는 분이시라, 우리가 신경 쓰지 못하는 부분까지 세세하게 조언을 많이 해주셨다. 한 번은, 전 박사님 박사과정 학생 한명과 같이 미팅에 들어갔는데, 초등학생도 할 수 있는 생각도 못한다며, 우리 생각이 유치원생 수준이라는 이야기도 들었었고....ㅎㅎ

그 와중에, 전 박사님께서 해주신 말씀이 연구의 본질을 깨닫는데 도움이 되는 결정적인 단서가 되었다. `문제를 찾으면 이미 연구의 반은 한 것이나 마찬가지고, 그 만큼 문제 찾는게 연구할 때 가장 어려운 일이다'라고... 사실 대학원 생활 내내 이 말의 의미를 잘 몰랐던 것 같다. 박사공부가 마무리 되어가는 시점에서야 느낌적인 느낌을 얻었다고나 할까?;; 그래서 아마 지도교수님이 crazy idea를 이야기 하실 때, 문제를 풀기 위한 idea를 찾기 보단, 그럴싸한 논문을 쓰기 위한 idea를 생각해 내기 급급했던 것 같다.

문제에 대한 이야기는 1편과 2편에서 어느정도 했지만, 4편에서는 문제의 특성을 다른 관점에서 생각해 보고 싶다.

(1) 많은 연구자들이 풀려고 하는, 이미 잘 알려진 문제

(2) 문제인지 몰랐던 문제 (아무도 시도해보지 않은...)

(3) (2) 유형의 문제인 줄 알았는데, 알고보니 본질적이고 어려운 문제

물론 문제에 대한 다른 유형들도 있겠지만, 박사과정 중에 내가 1저자로 썼던 논문들이, 이 3가지 유형으로 설명될 수 있지 않을까 싶어 이렇게 구분해 보았다. 내가 쓴 학회 논문 이야기를 통해, 3가지 문제 유형에 대해 고민해 보고, 어떻게 이 문제들을 찾아 갔는지 경험을 정리해 보고 싶다. 나의 경험이, 연구 문제 찾기를 고민하는 분들에게 작게 나마 참고가 될 수 있다면 더할 나위가 없다. 글이 또 길어진 것 같다. 결론만 보고 싶으신 분은, 그냥 포스팅 맨 끝으로 가서 요약정리만 보셔도 좋다.

이야기를 시작하기 전에, 내가 하고 있는 버그 예측 연구 분야에 대해 누구나 이해할 수 있도록 간단히 소개하고자 한다. 내가 하는 연구는 컴퓨터나 스마트폰 등 각종 IT장비에서 사용하는 소프트웨어의 버그를 미리 예측해서, 품질보증(Quality Assurance, QA)을 전담하는 개발팀에서 버그가 예측된 소스코드들을 중심으로, 검토(Inspection or Code Review)하고 부족한 테스트 인력들이 가장 문제가 있는 소스코드에 대해서 먼저 테스트(Test)할 수 있도록 돕는 기술이다. 소프트웨어 결함 예측 혹은 버그 예측 (Defect Prediction or Bug Prediction) 이라고 불린다. 예측 모델은 이미 존재하는 기계학습(Machine Learning) 기법들을 이용해 만들어 진다.

다음은 박사과정 동안 버그 예측 분야에서 어떤 문제들을 연구했고 또 어떻게 문제들을  찾았는지에 대한 이야기이다. 다소 전문적인 내용이 포함되어 있지만, 누구나 어렵지 않게 이해할 수 있게 쉽게 쓰도록 노력했다.

1) 많은 연구자들이 풀려고 하는, 이미 잘 알려진 문제

2편에도 설명을 했듯이, 박사과정 학생보다 연구 경험이 많은 지도 교수는 어떤 문제가 Interesting한 문제인지 잘 알고 있다. 지도 교수가 학생들에게 시키는 연구 문제들은 예전 부터 존재하던 문제일 가능성이 많아 참고 논문들도 많이 있고 연구 지도 하기에도 좋다.

내가 버그 예측 연구에 대한 배경지식을 쌓아가고 있는 와중 지도 교수님께서 던져 주신 문제가 교차 프로젝트 버그예측(Cross-project Defect Prediction)에 대한 주제 였다. 쉽게 말하면, 앵그리 버드 버그 및 개발 기록으로 Asphalt8 버그를 예측할 수 있게 해주는 버그 예측 기술이다. 일반 버그 예측 기술은 같은 프로젝트 내에서, 그러니까 앵그리 버드 버그 및 개발 기록으로 그 다음 버전의 앵그리 버드 버그를 예측한다.

이 분야 대가가 2009년에 교차 프로젝트 버그 예측이 정말 어려운 문제라는 것을 보여주는 논문을  발표했고, 다른 연구자들이 해당 문제를 해결하는 논문들을 속속들이 내고 있는 상황이었다. 2편에 설명했듯이, 지도 교수님께서 문제를 던져 주셨고, 또 Transfer Learning을 이용하면 어떨까라는 시작 Idea까지 주셨다. 그렇게 해서 완성한 논문이 ICSE`13에 발표한 Transfer Defect Learning이다. TCA라는 Transfer Learning 알고리즘 중 가장 최신의 방법을 버그 예측에 적합하게 확장하여 제안한 TCA+가 문제 해결을 위한 아이디어였다. 기존의 교차 프로젝트 연구들은, 조금씩 성능을 높이는 방식의 결과들을 보여줬지만, TCA+는 기존의 교차 프로젝트 예측 성능을 넘어, 달성하기 더 어려운 교차 프로젝트가 아닌 일반 버그 예측 성능과도 견줄 수 있는 결과를 보여 주었다. 아마 이런 점이 공헌으로 인정이 되어, 학회 논문에 뽑힌 것으로 생각된다. 교차 프로젝트 버그 예측 연구에 Transfer Learning을 접목한 것이 한 동안, 메너리즘에 빠졌던 버그 예측 연구에 일종의 활력을 불어넣는 계기가 된 것 같다. 추후에 나오는 교차 프로젝트 버그 예측 논문에 TCA+를 baseline로 넣어 비교하는 논문들도 출판 되었고, 리뷰 요청이 들어오는 저널 논문들에도 TCA+를 baseline으로 비교하는 것들이 계속 나오고 있다.

예전부터 존재하던 문제는, 박사과정 학생들이 문제를 이해하는데 필요한 배경지식을 쌓고, 또 다양한 idea를 시도하면서, 연구 과정을 배워갈 수 있는 좋은 문제 유형이라고 생각이 된다. 하지만, 다른 연구자들의 idea보다 월등히 성능을 향상시킬 수 없으면, 좋은 연구로 인정받기가 어렵다. 그럼에도 불구하고, 이미 문제가 분명하다는 점과 어쨋든 연구를 진행할 수 있다는 점에서, 연구를 시작하려는 박사과정 학생들이 꼭 경험해야 할 문제 유형이라고 생각한다. 박사과정 중 이런 문제를 풀다가 2번 정도 실패(논문을 못쓰거나 출판하지 못함)하기도 했다. 실패했지만 연구의 전반을 익히는 중요한 경험이 되었고, 이어 지는 연구의 큰 토대가 되었다.

(1) 유형의 문제를 해결하는 연구들은 시간이 중요하다. 여러 연구자들이 자신만의 해결방법을 계속 제안을 하기 때문에, 내 것을 발표하기 전에, 다른 사람들이 제안한 새로운 방법들이 학회나 저널에 미리 소개가 되면, 이 새로운 방법을 내 방법과 비교해야 하는 추가작업을 계속 해야 하기 때문이다.

2) 문제인지 몰랐던 문제

(1) 유형의 문제를 해결하는 논문을 발표한 후, 새로운 연구 주제를 찾아야 했다. 지도 교수님께서 idea가 있는지 계속 물어보시는 와중, 나는 (1) 유형에 속한 다른 문제를 해결하려고 시도하고 있었다. 버그 예측 연구의 한 가지(Branch)인 Change Classification (Just-In-Time Defect Prediction)부분이었는데, 기존 연구가 검증에 제한이 있던 부분과 또 예측 성능이 좋지 않은 부분을 해결하고 싶었다. 이 문제는, 버그 예측 관련 문헌조사만 좀 하면 예전 부터 존재했던 문제라는 것을 어렵지 않게 알 수 있다. 하지만, 몇 개월 이런 저런 시도를 해봐도, 뚜렷한 개선이 없었고, 중요한 문제이지만, 결국에는 나중에 졸업하고 하라는 지도 교수님의 조언을 듣고, Change Classification 문제는 그만 두게 되었다. (포닥하면서 이 문제에 다시 도전하고 있다.)

그 다음 새로 찾은 연구 주제는 (굳이 한글로 표현하자면) 이종 데이터간 버그 예측 (Heterogeneous Defect Prediction)이다. 교차 프로젝트 버그 예측을 하려면 버그 예측 데이터들이 같은 종류여야 하는, 반드시 지켜야하는 조건이 있다. 그러니까 버그 예측을 위해 앵그리 버드에서 뽑은 데이터와 Asphat8에서 뽑은 데이터 종류가 같아야 한다는 말이다. 그런데 때론 서로 다른 두 소프트웨어에서 같은 종류의 데이터를 뽑지 못하는 경우가 있다. 이렇게 서로 다른 종류의 데이터를 포함하고 있으면, 교차 프로젝트 예측을 바로 할 수 없다는 제한이 있다. 이러한 제한점을 앞에 나온  Transfer Defect Learning 실험을 하다 깨달았다. 또, 관련 연구 문헌 조사(Literature Survey)를 통해 이 문제를 해결하려 시도하는 기존 연구를 찾지를 못했었다. 그러다 보니, 이게 문제같지 않은 문제여서 그런가 보다 라는 생각이 들기도 하고, 이런 제한점을 해결한다는게 가당키나 한 일일까라는 의구심도 들었다. 하지만, 지도 교수님께서 이 문제를 풀어보라고 허락도 해주셨고, 또 새로운 아이디어를 물어보시는 게 부담스러워, 가당치 않은 문제를 풀기 위해 배경지식을 총 동원했다. 그런 와중에 다양한 시도를 해보다가 가능할 수도 있겠구나라는 답변을 줄 수 있는 만큼의 결과를 이끌어 낼 수 있었다. 2013년에 연구를 시작해서 2014년 봄에 FSE라는 학회에 냈다가 떨어지고, 또 여름에 ICSE라는 학회에 냈다가 떨어졌다. 두 번의 Reject 후 받은 다양한 리뷰어(Reviewer)들의 코멘트를 답변하고 처리하는 과정에서, 더 나은 방법을 찾을 수 있었고, 2015년 FSE에 논문을 발표할 수 있는 결과를 얻을 수 있었다.

흥미로웠던 점은, 비슷한 시기에 같은 문제를 풀려고 하는 다른 연구자들이 있었다는 것이다. 2014년 11월 쯤 중국에 있는 어떤 그룹에서, arXiv라는 논문 공유 사이트에 해당 문제를 푸는 첫번째 시도를 한 논문을 게재 했다. arXiv는 다른 연구자들의 심사없이 누구나 논문을 올릴 수 있는 저장소라, 특정 분야를 제외하고는, 논문의 질을 장담할 수 없는 단점이 있다. 중국 연구 그룹도 나와 비슷한 시기에 내가 고민하던 문제를 새로운 문제라고 생각한 것 같지만, arXiv에 올라온 논문이 처음으로 세상에 공개된 해당 문제를 푼 첫번째 논문이기에 내 연구에 인용도 하고 실험의 비교대상(baseline)으로 넣을 수 밖에 없었다. 나의 방식과 비교한 결과 내가 고안한 방식이 더 좋은 결과를 보여주어서, 큰 걱정 없이 논문을 학회에 제출 할 수 있었다.

그 다음으로 흥미로웠던 점은, 2015년 FSE에서 똑 같은 문제를 해결하는 또 다른 논문이 함께 합격하는 일이 벌어진 것이다. 내 논문의 이름은, Heterogeneous Defect Prediction인데, 함께 함격된 논문은 Heterogeneous cross-company defect prediction by unified metric representation and CCA-based transfer learning 라는 타이틀의 논문이었다. 만약에 두 논문 중 하나가 떨어 졌다면, 떨어진 논문은 붙은 논문에 나온 방법을 baseline으로 넣어서 추가로 작업 해야 하는 어려움이 있었을텐데, 다행이 함께 합격이 되어, 두 연구 그룹 모두 그런 부담을 줄일 수 있었다.

한 학회에서 같은 문제를 해결하는 두 논문이 함께 붙은 것은 종종 있을 법도 한 일인데, 아무도 문제라고 생각지도 못했던 문제를 다른 두 연구 그룹이 자기들만의 해법으로 문제를 풀었다는 것은 종종있는 일은 아니지 않을까 싶다. 덕분에, Heterogeneous Defect Prediction (HDP)이라는 새로운 연구 가지(Branch)가 Defect Prediction연구에서 나오게 된 것 같다. 앞으로 이 연구가 어떤 후속 연구들을 이끌어 낼지는 두고 볼 일이지만, 2013년 ICSE에서 발표한 내 첫 논문보다 더 큰 영향력이 있지 않을까 기대해 본다. 개인적으로는 내 논문 타이틀이 이종 데이터간 버그 예측 (Heterogeneous Defect Prediction, HDP) 문제를 잘 표현하는 일반적인 타이틀이라, 앞으로 HDP라는 표현이 다른 논문들에서 계속 인용될 수 있지 않을까 기대하고 있다. 사실 타이틀을 여러번 바꾸었는데, 지도 교수님과 계속 상의 하는 과정에서 최종적으로 저 이름을 선택할 수 있었다. 덕분에 이런 기대도 할 수 있게 된게 아닐까 싶다.

(2) 유형 문제는 문헌 조사(Literature Review/Survey)를 통해서도 찾을 수 있다. 이게 제대로 문제를 찾는 방법이라고 생각한다. 사실 HDP문제는 Transfer Defect Learning이라는 최신 연구에서 발견한 제한점이라는 점에서, 문헌 조사를 통해 찾았다고 볼 수 있다. (내가 쓴 논문이라 그렇다고 이야기 하기 좀 애매할 뿐인다;;; (1) 유형의 문제를 풀어가면서 문헌 조사는 자연스럽게 되어버렸다.) 아마도 HDP문제를 해결한 arXiv에 논문을 올린 연구 팀이나, 같은 학회에서 HDP 관련 논문을 발표한 다른 연구팀도, Transfer Defect Learning논문을 보고 문제를 찾은 것인지도 모르겠다. Transfer Defect Learning논문에 서로 다른 데이터를 가지고 있는 프로젝트에 대해 교차 예측을 할 수 없다고 명시적으로 적은 부분이 있기 때문이다. 물론 어디까지나 내 추측이다;;; 문제 찾기와 문헌 조사는 뗄 수 없는 관계이다. 그냥 같은거라고 보고 싶다. 엄청난 시간과 생각이 필요한 과정이다. (문헌 조사에 대해서는 5편에서 자세히 나누도록 하겠다.)

지도 교수는 박사과정 학생을 돕는 사람이지만, 늘 항상 문제를 던져줄 수 있는 분은 아니다. 수업이나 많은 학생들을 지도해야 하기에 항상 바쁘신 분들이 지도 교수다. 공부를 안하는 게으른 지도 교수나, 내가 관심 있어서 하는 세부 연구 분야를 잘 모르는 지도 교수를 만나면, 박사과정 학생을 위해 문제를 던져주지 못할 수 도 있다. 아니면, 문제 찾는 것 부터 제대로 훈련 시키시려고, 학생들 스스로 문제를 찾아오기 원하는 지도 교수도 있을 수 있다. 이럴 경우, 박사과정 학생 스스로 문헌 조사를 통해, 관심 있는 분야의 논문을 섭렵하고, 해당 분야의 큰 그림을 먼저 그려야 한다. 그런 다음 최신 연구 논문들을 보면서, 어떤 문제점들이 아직도 존재하는지 스스로 찾아야 한다. 대학원에 오면 세미나라고, 논문을 읽고 교수님 앞에서 발표를 하는 일을 거의 매주 해야한다. 바로 이 세미나의 주 목적이 특정 연구 분야를 섭렵해 큰 그림을 그리고, 연구 동향을 이해하며 최신 연구들의 문제점을 찾는데 있는 것이다. 그러면서 교수도 해당 분야를 함께 배워가며, 학생들에게 적시에 조언을 줄 수 있는 것이다.

3) (2) 유형의 문제인 줄 알았는데, 알고보니 본질적이고 어려운 문제

HDP 논문을 출판하고, 역시 새로운 문제를 생각해야만 했다. 또 고뇌의 시간이 돌아온 것이다. 사실은 HDP논문은, 제출하기 몇 개월 전 이미 어느 정도 완성이 되어 있는 상황이었다. 또, 언제나 그랬듯이, 지도 교수님도 새로운 idea를 요구하셔서, 새로운 문제를 생각해야만 했다.

어떤 문제들은 산학협력 프로젝트를 통해 발견하기도 한다. 그 당시, 삼성과 산학 프로젝트를 하고 있었는데, 그 때 발견한 제한점이, 버그예측에 필요한 버그 정보를 모으기가 쉽지 않았다는 점이었다. 그래서 자연스럽게 이어진 생각이, 과거 버그 정보없이 버그 예측을 할 수는 없을까? 였다.

새로운 문제를 찾은 것이었다. 이렇게 보면, 이 때 발견한 문제는 (2) 유형의 문제가 될 수 있다.

내가 찾은 문제가 새로운 문제인지 검증하기 위해 관련 연구 문헌 조사를 했다. 아뿔사 이미 이 문제를 풀려고 하는 연구들이 있는 것이 아닌가? 관련 연구들은 머신러닝의 Unsupervised Learning 기법과 전문가의 지식을 함께 이용하여 이 문제를 해결 하였다. 이런 점에서 내가 문제라고 생각한 문제는, (1) 유형에도 들어갈 수 있는 것이었다.

그런데, 관련 연구들이 가지고 있는 또 다른 제한점이 있었는데, 버그 예측 과정에 반드시 전문가 등 누군가가 수동으로 작업을 해야 한다는 단점이 있었다. 그래서, 이 단점을 해결하고 완전히 자동화 하는 방식을 고안해 냈다. 이 단점을 해결하는 것을 문제라고 생각한 논문을 아직까지 본적이 없다. 이렇게 보면, 내가 푼 문제는 (2) 유형이 맞는 것 같기도 하다.

위 문제를 해결하는 연구를 시작한지 6개월 쯤 뒤에, 2015년도 ASE (Automated Software Engineering)에 논문을 제출하였다. 그런 후, 2개월 후 쯤, 예상하지 못한 독특한 결과를 받았다. Reject도 Accept도 아닌 Conditional accept이 아니던가? 논문을 리뷰어의 요구에 맞게 수정을 하면 Accept하겠다는 조건부 합격이었다. Reject이 아니라서 기뻤지만, Accept이 되기 위해 뭔가 많이 수정을 해야해서, 걱정도 많이 됐다. 혹시라도 수정을 잘 못해서, 조건을 만족시키지 못하면 Reject이 될 수 도 있기 때문이다.

논문 결과가 나왔을 때, 무엇보다 독특했던 것은, 논문을 검토한 리뷰어들의 리뷰 내용 이었다. 요약하자면,

(1) 너가 제안한 방식은, 쓸모없는 것이다. (...I strongly believe CLAMI would be useless to software

engineers.)

(2) 연구의 동기/방법/결과/논의 모두 좋다. 그런데, 제안하는 방법이 실제 개발 프로젝트에 적용이 가능할까?

(3) 대단히 새롭고 성공적인 방법이다. 버그 예측 연구 전체를 바꿀지도 모른다. (...it might be one that changes an entire field...)

정리하면, 첫 리뷰어는 불합격, 두번째 리뷰어는 중간, 마지막 리뷰어는 합격을 준 것 같다. 보통 이런 평가가 나오면, 최종 결정은 불합격이기 마련인데, Conditional Accept이 나온 것이다. 추측하기로는 마지막 리뷰어가 이쪽 분야의 대가인데, 나도 생각지 못한 논문의 중요한 가치를 알아보고 높이 평가해서 가능한 일이 아니었나 싶다. 이렇게 엇갈리는 평가로 인해서 인지, 네 번째 리뷰어가 한 명 더 붙었다. 네 번째 리뷰어는 논문의 장점과 단점을 이야기 한 후, 논문을 개선하는 조언을 많이 남겨주었다.

어쨋든 리뷰어들의 양질의 조언 덕분에, 논문 전체를 뜯어 고치는 작업 후 다시 제출 후 최종 합격하게 됐다.

이 주제를 처음 시작할 때는, (2) 유형의 문제인 줄 알았다가, 나중에는 (1) 유형으로 생각했는데, 잘하면 (3) 유형도 될 수 있지 않을까라는 생각을 해보았다. 세 번째 리뷰어가 내 연구의 가치를 보았던 부분은, 많은 과거 정보를 필요로 하는 수학에 기반한 복잡한 예측 모델이 아닌, 적지만 영향력이 큰 정보와 단순한 방법으로도 버그 예측을 잘 할 수 있다는 점이 아닌가 싶다. 수 많은 연구자들이 해결하려던 문제를, 새롭고 신나는 방법 (novel and exciting way)으로 해결을 했다는 것이다. 아마 세 번째 리뷰어가 대가였기에 불합격 시키는 리뷰가 있었음에도 학회에서 발표할 수 있는 기회를 준 것으로 생각이 든다. 사실 앞에 나온 두 논문들은 여러번 떨어져서 3, 4번 만에 합격한 논문이었는데, 이 논문은 이런 특이한 평가를 받게 되어 한 번에 합격하는 예상하지 못한 결과를 얻은 것이다.

사실 논문을 제출할 당시, 내가 제안하는 방식이, 결과는 잘 나왔는데, 퍼즐을 해결하는 것 처럼 쉬운 방법이라 많이 부끄러웠었다. 그런데, 오히려 복잡한 수학식이 없는 직관적이고 쉬운 방법을, 세 번째 리뷰어가 참신하다고 평가를 한 것이다.

나는 `전문가의 도움과 과거 버그 정보없이 자동으로 버그 예측을 할 수 있는가?' 라는 (2) 유형의 문제를 푸는 것으로 생각을 했는데, 어떤 대가는 내가 미쳐 생각지 못한 (3) 유형의 문제, `많은 정보가 필요한 기존의 복잡한 예측모델이 아닌, 적지만 의미있는 정보와 단순한 방법으로 예측을 할 수 있는가?'라는 더 본질적이고 어려운 문제를 풀고 있는 것 같다고 평가를 해준 것이다. 나는 여전히 이 연구가 (2) 문제를 해결한 것으로 생각하는데, 세 번째 리뷰어가 생각한게 맞다면, 내 연구가 (3) 유형의 문제를 푸는 시작점이 될 수 있지 않을까 기대해 본다. 아마 오랜 시간이 지나서, 인용 횟수를 보면 정말 그런 것인지 알게 되겠지...

많은 문제를 해결해서 논문 편수가 많아지는 것도 중요하긴 하겠지만, 다른 연구자들이 내 연구를 얼마나 참고 했는지를 나타내는 인용 횟수도 중요하다. Google Scholar에서는 등록된 연구자별로 인용회수를 대충 계산해 준다(블로그 주인장의 Google scholar 인용 정보는 여기에서 확인-https://goo.gl/fHpTD1 아직 걸음마 단계다). 어느 학회와 저널에 논문을 출판했는지도 중요한 평가 기준이 되기도 한다. 하지만, 좋다고 여겨지든 학회든 그렇지 않은 학회든 연구자들은 여기 저기에 출판된 논문들을 많이 읽어 보고 읽은 논문들이 내가 하는 연구에 필요한 정보를 가지고 있으면 인용 할 수 밖에 없다. 내가 FSE 논문을 쓸 때,  arXiv에 올려진 논문을 인용할 수 밖에 없었던 것도 같은 이유이다. 즉, 어느 학회나 저널이든 나의 연구가 세상에 나오게 되면, 그 가치는 다른 연구자들에 의해서 결국 평가가 되는 것이다. 물론, 탑 학회에 논문을 내면 나의 연구들이 다른 연구자들에게 더 노출될 가능성이 많겠지만, 정말 주옥같은 논문을 썼다면 그 논문이 어디에 출판 됐는지와 상관없이 시간이 지나면 그 진가를 언젠가는 인정받을 수 있다고 생각한다. 수학이나 물리 쪽에서 arXiv에 올린 세기의 난제들을 푼 논문들이 인정받는 것이 대표적인 예라고 할 수 있겠다.

그런데 연구 세계를 경험해 보면 탑 학회나 저널이라고 인정되는 곳에만 논문을 제출하려는 치열한 경쟁을 보기도 한다. 이러한 경쟁이 좋은 연구를 하게 되는, 긍정적인 자극이 될 수는 있겠지만, 사실 별로 행복하다는 생각을 해본 적은 없다. 대신, 내가 풀려고 하는 문제가 의미 있어서 잘 풀기만 하면 누군가에게 도움이 될 수 있겠구나 라는 생각이 연구에 동기부여가 많이 되고, 그나마 연구를 행복하게 할 수 있는 힘이 되었다. 하지만 현실은 늘 탑 학회의 논문 제출 마감일에 에너지를 쏟을 수 밖에 없는게 현실이다.

연구 경쟁에서 소모적이지 않으려면, 아무도 생각지 못한 (2) 유형이나 풀기가 어려운 (3) 유형의 문제를 찾아 도전하는 것이 좋은 방법일 것 같기도 하다. 아니면, 그냥 (2) (3) 유형의 문제를 연구 집단에 공개하여 다른 연구자가 혹은 함께 문제를 해결해 가는 것도 좋은 방법이 될 수 있지 않을까? 문제가 해결되면, 결국 혜택을 입는 누군가가 있을테니...이게 연구하면서 행복해질 수 있는 본질이 아닐까 싶다.

마지막으로 나의 연구 목표가 탑 학회 논문 제출이라는 표면적인 목표가 아니라, 의미 있는 문제를 해결하려는 본질적인 목표가 되기를 소망해 본다. 연구자로서 앞으로 평생 되새겨야 할 목표가 아닐까 싶다. 이런 목표로 연구 하다보면 좋은 학회나 저널에 논문을 출판 할 수 있는 가치 있는 논문을 쓸 가능성도 당연히 많을 거라 생각된다. 경우에 따라서는 가치 있다고 생각했던 연구가, 이런 저런 이유로 인정 받지 못하는 경우가 생길 수도 있다. 시간이 많이 걸리다 보면, 나보다 먼저 다른 연구자가 더 획기적인 방법으로 같은 문제를 완벽하게 해결할 수도 있다. 그래서 내가 하는 연구를 무력화 시킬 수도 있다. 그런데 완벽한 해결책이 나왔으니, 이 것 또한 감사한 일 아니겠는가? 이때까지 연구한게 아까우면, arXiv에라도 올릴 수 있는 그런 여유가 있었으면 좋겠다.

이번 포스팅에서는, 연구 문제를 찾아갔던 나의 경험에 대해 나누어 보았다. 결론을 간략하게 정리해 본다.

1. 어떤 문제를 풀어야 할지 잘 모르겠으면, 지도 교수가 풀어보라는 (1) 유형의 문제 부터 시작하면 된다. (물론 다 성공하는 것은 아니지만, 경험 자체만으로도 연구에 대해 많은 것을 배울 수 있다.)

2. 그러면서, 진행중인 연구 분야 내에 있는 새로운 제한점을 찾아보라. (2) 유형의 문제일 가능성이 높다.

3. 내 관심 분야가 분명하면, 문헌 조사를 통해 해당 분야 논문을 모두 읽고, 특히 최신 연구논문들의 제한점을 찾아보라. (2) 유형의 문제를 찾을 가능성이 높다. 

4. 산학 프로젝트에 열심히 참여해서, 실제 필드에는 어떤 제한점들이 있는지 찾아보라. (1) 혹은 (2) 유형의 문제일 수 있다.

5. 문제를 찾았으면, 자세한 문헌 조사를 통해 정말 새로운 문제인지, 누군가가 해결한 문제인지, 누군가가 해결한 문제라면 다른 제한점이나 단점은 없는지 확인을 해야 한다.

6. 찾은 문제가 정말 의미있는 문제인지를 지도 교수를 통해 확인 받아야 한다. 지도 교수를 설득시키지 못하면, 별로 중요하지 않거나 의미 있는 문제가 아닐 수 있다. 정말 좋은 문제인데, 지도 교수를 설득하지 못했다면, 다른 논문 심사자들 설득하기는 하늘에서 별따기일 것이다. (좋은 연구란, 좋은 문제 + 좋은 해법 + 좋은 소통이다. 좋은 소통에 대해서는 9편에서 나누도록 하겠다.)

7. (2) 유형의 문제를 전혀 새로운 방식으로 풀다보면, (3) 유형의 문제도 풀 수 있는 열쇠가 될 수 있다.

8. 연구의 본질적인 목표는 문제 해결이다!

 

이 글이 도움이 되셨다면, 공감을 눌러 주세요!