행복한 대학원생 되기 9편: 논문 쓰기

행복한 대학원생 되기 연재

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)

대학원 생활의 절정으로 가는 시작, 바로 논문 쓰기이다. 많은 시간을 쏟아 도출해 낸 연구 결과를 공식적으로 세상을 향해 내놓는 최종 단계이다. 연구의 전체 과정을 나무가 과실을 맺어가는 과정에 비유한다면, 논문 쓰기는 꽃이 진 후 보암직도 하고 먹음직도 하고 지혜롭게 할 만큼 탐스럽기도 한 완숙한 열매로 자라게 하는 단계이다. 논문이 저널이나 학술대회에 Accept 되면 사람들은 달고 물 많은 배 인지, 아직 덜 익어서 떫은 감 인지 모른 채 따먹게 되어 있다. 잘 소화된 논문은 씨가 남아 누군가에 의해 새로운 나무로 키워지고 많은 사람들의 관심을 받아 숲을 이룬다. 한 입 베어 먹히고 버려진 떫은 감은 별로 관심은 못 얻을 수는 있겠지만 어딘가에서 거름이 되어 숲을 이루는데 알게 모르게 도움을 준다.

하지만 논문 쓰기는 쉽지 않다. 모국어가 아닌 영어로 쓴다는 부담감. 잘 이해 안가는 지도교수의 빨간펜 코멘트. 완벽하지 못한 문법. 다시 볼 때마다 나오는 오타. 논문 쓰다 연구설계가 잘못된 걸 알게 된 순간의 절망... 데드라인이 없으면, 절대 끝나지 않을 것 같은 작업이 논문 쓰기다.

열심히 논문 쓰던 2013년 2월 어느날...

그렇다고 마냥 괴로운 일만은 아니다.

나에게 있어서 잘 쓴 논문이란, 쉽게 읽혀지는(Easy to read) 논문이다. 아무리 내실있는 연구를 했더라도, 독자에게 정말 좋은 연구인지를 잘 전달하지 못하면 Accept되기가 쉽지 않다. 반대로, 내실이 부족하더라도 심사자에게 잘 어필할 수 있는 논문은 애석하게도 Accept이 될 수도 있다. 현실이 그렇다. 내 연구를 가장 잘 아는 사람은 나이기 때문에, 내가 잘 설명해 주지 않으면  다른 사람이 내 연구 가치를 알리 만무하다. 내실은 없지만 잘 읽혀지는 논문은 심사자들에게 본인이 이 연구를 이해할 만큼 좋은 연구라고 착각하게 만드는 효과가 있다. 네이티브가 아닌 이상 이런 선악과(?) 같은 논문을 쓰는 건 쉽지 않으므로, 내실 있는 연구 후 쉽게 읽혀지는 논문을 쓰고 싶은 분들에게 내 경험이 작게 나마 도움이 되었으면 하는 마음에 몇 자 적어본다.

글쓰기도 기술이라 몇 가지 요령만 익히면 잘 읽히는 논문을 쓸 수 있다. 하지만 요령은 요령일 뿐 논문의 질은 쏟은 시간에 절대 비례함을 명심하자. 아래는 여러 가이드 자료(컴퓨터 공학 논문 쓰기에서 가장 잘 정리된 자료를 꼽는다면: https://goo.gl/003nX2, 다양한 Writing Tips들은 여기 참조: https://goo.gl/NfN58M)와 경험을 통해 중요 하다고 배우고 느낀 논문 쓰기의 요령들이다. 문제를 해결하는 기법들을 제안하는 소프트웨어 공학 학술대회나 저널 논문 작성시 유용할 수 있는 요령들이다. 일부 내용은 다른 분야 논문 쓰기에도 어느 정도 적용될 수 있을 것 같다. 일단 요령 목록부터 보자:

(1) Introduction에 전체 논문 작업 시간의 50%이상 투자하라.

(2) Introduction의 개요는 다음과 같이 진행한다. 도입 >> 배경 >> 문제 >> 논문의 Goal >> 해법 >> 결과 >> Contribution

(3) 문단의 첫 문장 만으로 완벽한 논리를 짜낸다. 퍼즐이라 생각하면 즐겁다.

(4) Generalist가 막힘없이 읽어 내려 갈 수 있을 정도로 친절하게 써라.

(5) 문장은 짧고 간결하게...긴 문장은 피하라.

(6) 지도교수 코멘트에는 분명 이유가 있다. 잘 반영하라. 모르겠으면 끙끙거리지 말고 의도를 여쭈어보라.

(7) 선배 후배 친구 등등 한 번 읽어보라 하고 꼭 코멘트를 받자.

(8) 수식이 들어가는 것만으로, 논문의 질이 올라갈 거란 착각을 하지 말라. 수식은 가능한 직관(intuition, 문제를 해결하는데 왜 수식이 이렇게 돼야 하는지의 이유)을 설명한다. 포괄적이고 직관적인 수식을 시작으로 논리적 흐름에 따라 구체적이고 복잡한 수식으로 진행한다.

구구절절 팁들을 다 설명하기 보단, 습관으로 채득하면 좋을 (1)(2)(3) 위주로 정리했다.

Introduction에 전체 논문 작업 시간의 50%이상 투자하라

논문 심사자는 서문(Introduction)을 읽으면서 당락을 (의식적이든 무의식적이든) 마음 속으로 먼저 결정한다. 그런 후 당락에 대한 자기 결정이 합당한지 확인하는 마음으로 나머지 Section들을 대한다. 사람을 만날 때 첫인상으로 상대방을 대하는 태도가 결정되는 것과 비슷한 이치이다. 첫인상으로 사람들을 판단하는 게 선입견이 될 수 있지만 결국 첫 인상이 좋았던 사람이더라도 오랜 시간을 지내면서 진국인지 아닌지 알게되는 것과 마찬가지다.

그래서 서문에서 선방하고, 이후 Section들이 심사자의 기대를 저버리지 않으면 Accept에 아주 가까이 갈 수 있다. 서문 선방의 왕도는 쏟아붓는 시간이다. 첫 Draft가 나오기 전까지, Related work, Motivation, Approach, Experimental Setup, Result, Discussion, Conclusion 등등 각 섹션을 작업해 갈 때 마다 서문에 추가되면 좋을 내용들이 계속 생각이 난다(날 수 밖에 없다). 생각이 날 때 마다 기존의 서문 내용을 수정/추가/삭제를 반복한다. 이렇게 해서 첫 Draft가 나오면, 모든 섹션들을 반복적으로 수정해 가면서 역시 서문을 반복적으로 수정한다. 데드라인이 다가오고 Draft의 완성도가 높아짐에 따라, 서문 수정 작업에 들어가는 시간은 더욱 늘어난다. 각 섹션 작업 중심에, 늘 서문 수정이 따라 붙는다. 이 건 팁이라기 보단, 서문 작성의 열정과 태도의 중요성을 강조하는 것이다.

시간 싸움은 시간 싸움인데, 그럼 서문의 내용은 어떤 식으로 채우나?

Introduction의 개요는 다음과 같이 진행한다. 도입 >> 배경 >> 문제 >> 논문의 Goal >> 해법 >> 결과 >> Contribution

아래 예제 서문을 보라. 서문 모든 문단의 첫 문장만 나열했고 문단 목적을 표시했다. (2015년 ASE 논문이다. http://lifove.github.io/files/CLAMI_ASE.pdf) 내용을 굳이 알려고 할 필요는 없고, 각 첫 문장에 태그된 문장의 목적만 보라. 다른 분야 논문은 조금 다를 수 있겠지만, 소프트웨어 공학 논문들은 대게 이 흐름을 따른다.

- 도입: Defect prediction plays an important role in software quality.

- 배경1: Researchers have proposed and facilitated various defect prediction algorithms and metrics.

- 배경2: In particular, studies on defect prediction metrics have been actively conducted as the use of software archives such as version control systems and issue trackers has become popular.

- 문제1: However, typical defect prediction techniques based on supervised learning are designed for a single software project and are difficult to apply to new projects or projects that have limited historical data in software archives

- 기존해법1: To address this limitation, researchers have proposed various approaches to enable defect prediction on projects with limited historical data.

- 기존해법1의 문제: However, there is still an issue of different distributions among datasets in existing approaches for cross-project defect prediction (CPDP) and universal defect prediction (UDP)... However, the approaches based on making the different distributions similar between training and test datasets may not always be effective.

- 기존해법1의 문제를 해결하는 기존해법2의 문제: Compared to CPDP and UDP, the existing approaches for defect prediction on unlabeled datasets are relatively less affected by the issue of different distributions among datasets but will always require manual effort by human experts.

- 논문의 Goal과 나의 해법: The goal of this study is to propose novel approaches, CLA and CLAMI, which can conduct defect prediction on unlabeled datasets in an automated manner.  The key idea of the CLA/CLAMI approaches is to label an unlabeled dataset by using the magnitude of metric values.

- 결과 요약: In our empirical study, the CLA/CLAMI approach led to promising prediction performances of 0.636 (average fmeasure) and 0.723 (average AUC), while the typical defect prediction based on supervised learning showed 0.585 and 0.694 in average f-measure and AUC respectively.

- 공헌: The contributions of this study are as follows:

처음부터 이렇게 쓰려고 해서 이렇게 쓴게 아니라, 다른 섹션들 작업하는 중 서문 수정을 계속 반복하면서, 최종적으로 생성된 논리이다. 이 논리 흐름은 하나의 예시일 뿐이지만, 논문 심자사들에게 `아 이 논문은 이러 이러한 문제를 풀려는데 이 문제가 중요해 보이고, 또 잘 해결해서 결과가 이전보다 좋아졌네?' 이 인상을 주기에는 좋은 논리 구조라고 생각된다. 나머지 섹션들이 이 인상을 계속 유지하게 하느냐 마느냐에 논문의 당락이 결정될 것이다. 서문을 잘 쓴다고 논문이 Accept된다는 보장은 없지만, 서문을 못쓰면 떨어질 가능성이 매우 높다.

먼저, 도입과 배경은 논문이 다루는 분야에 대한 중요성과 현재 상태에 대해 요약정리한다.

그 다음, 문제를 정의하는 스토리를 만든다. 문제 스토리를 풀어가는 방식은, 연구 주제에 따라 다르다. 새로운 문제, 독립적인 문제일 경우 바로 문제 정의를 하면 된다. 하지만 많은 연구들이 기존 연구들의 제한점들을 해결하는 연구들이다. 그래서 기존 연구에서 다루던 시작 문제를 먼저 설명하고, 기존 연구들의 해법과 그 해법들이 여전히 가지고 있는 제한점들을 간단히 살펴본다. 그러면서, 내가 해결하려고 하는 문제까지 차근 차근 도출한다. 문제를 설명하는 과정은 연구의 동기(Motivation)를 설명하는 과정이므로, 굉장히 중요한 단계이다. 여기에서 심사자의 마음을 잡지 못하면, 심사자는 논문에 대한 부정적인 첫인상을 가지고 리뷰를 시작하게 된다.

문제 정의가 끝나면, 연구의 Goal이 문제를 해결하는 것으로 자연스럽게 명확해 진다.  명시적으로 논문의 Goal을 반드시 쓴다. 'The goal of this study is..."

추가적으로, 내 해법에 대한 직관적인 설명이 있는 단락을 쓴다. 위 논문에서는 해법을 논문의 Goal을 설명하는 단락에 한줄로 간단히 썼는데, 새로운 단락으로 내 해법의 직관을 잘 설명하면 좋다.

내 해법으로 문제를 해결한 결과과 기존 연구 결과들보다 좋은지 요약정리하는 단락을 추가 한다. 어떤 연구자들은, Research Questions을 나열하고 거기에 맞추어 요약된 결과를 보여주는 경우도 있다. 최근 소프트웨어 공학 논문들에 이런 경향성이 두드러 졌다.

연구의 명시적인 공헌사항을 나열한다.

많은 논문들이 서문에 논문의 구조를 간단히 설명하는 단락을 추가하기도 하는데, 옵션이다. 어떤 연구자들은 불필요한 단락이니 넣지 말라는 사람들이 있고, 어떤 연구자들은 있으면 도움이 된다고 하는 연구자들이 있다. 개인적인 생각으론 넣어도 그만 안넣어도 그만이다. 가끔 논문 페이지 수 제한을 잘 맞추기 위해 넣거나 빼거나 할 때 유용하기는 하다.

문단의 첫 문장 만으로 완벽한 논리를 짜낸다. 퍼즐이라 생각하면 즐겁다.

앞에 서문 예시에서 첫 문장만으로, 논리 흐름이 진행 되는 것을 볼 수 있다. 나머지 Section들도 동일한 방식으로 문단의 첫 문장만으로 논리가 진행이 되도록 작성한다. 전문 용어로 `두괄식'으로 문단을 구성하면 된다. 영어 작문을 가르치는 사람들은 문단의 구성 문장들을 다양하게 나열을 하지만, 단순히 한 문단에서 주제 문장은 첫 문장 그리고 나머지 문장들은 주제 문장을 지원하는 문장(Supporting statement)으로 쓴다고 생각하면 쉽다.

앞의 예시에서 내 분야를 잘 아는 사람이면, 각 문단의 첫 문장만 봐도 뭐하는 논문인지 바로 알 수 있다. 하지만 첫 문장 논리를 만들어 내는 것은 쉬운 일이 아니다. 수정을 반복하면서 문단의 첫 문장만으로도, 논문 처음 부터 끝까지 부드럽게 읽히도록 계속 수정을 해야 한다. 어떨 때는 주제 문장을 처음에 적었는데, 지원 문장 들로 무엇을 쓸지 생각을 해낼 수가 없어서, 주제 문장을 다르게 바꾸거나 앞 단락에 지원 문장을 넣거나 이런 저런 시도를 많이 하기도 한다. 아니면, 2-3문장으로 구성된 초라한 문단을 만들 때도 없지 않아 있다. 주제 문장으로 논리를 만들고, 지원 문장으로 문단을 채워가는 것은 장고의 시간이 걸린다. 첫 문장으로만 논리 만들기를 그냥 퍼즐이라 생각하면서 쓰면 긴 시간 작업할 때 그나마 좀 낫다.

문단의 첫 문장은 가능한 짧고 간결하게 쓴다. 공학 논문은 논지를 간결하고 명확하게 전달하는 것이 무척 중요하다. 부사구 같은 군더더기 표현을 삼가고, 주어 동사 목적어(보어) 등으로 구성된 슥~보면 슥~읽히는 단순한 문장을 많이 쓰도록 하자. 멋지고 눈에 착 들어오는 멋진 문장 구사가 가능한 네이티브가 아니라면, 짧은 문장 글쓰기가 잘 읽히는 논문 쓰기의 좋은 대안이 될 수 있다.

첫 문장으로 논리 만들기를 평소에 연습하자. 일기 쓰기나, 블로그, SNS 등을 하면서 두 문단 이상의 글쓰기를 자주 한다면 문단 첫 문장만으로 논리 만들기 원리를 적용해서 글을 써보자. 도움이 많이 된다. 나 같은 경우는 블로그에 신변잡기 적인 글을 쓸 때도, 퍼즐 삼아 첫 문장 논리 만들기를 자주 적용하는 편이다. 예를들어, http://lifove.tistory.com/28 이런식으로 연습을 하면 알게 모르게 도움이 많이 된다. 또 글을 쓸 때 퍼즐조각 맞추듯이 완성해 가는 재미도 있다.

마치면서...

글쓰기에 왕도는 없지만, 연구자들에게 논문 쓰기는 반복되는 일상이라 유용한 팁들이 있다. 가장 중요한 것은 서문 쓰기이고, 문단의 첫 문장만으로 내용을 파악할 수 있는 논리를 구성한 논문은 잘 읽히는 논문일 확률이 높다. 이런 저런 글쓰기에 문단 첫 문장으로 논리 만들기를 잘 시전할 수 있으면, 잘 읽히고 심사자 들에게 어필하는 논문 작성에 많은 도움이 될 것이다. 시간 투자한 만큼 논문의 질은 계속 올라감을 기억하자.

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