행복한 대학원생 되기 - 8편: 논문 리뷰

행복한 대학원생 되기 연재

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)

최근 몇 달 사이 소프트웨어 공학 저널에서 리뷰(Review)요청을 여러개 받아, 거의 일주일에 한 편씩 리뷰를 하고 있다. 아마도 소프트웨어 공학 관련 탑티어/세컨티어 저널들은 한 편 이상 리뷰를 하는 것 같다. 한국에 돌아가려면, 나도 어서 저널에 논문을 내야 하는데, 리뷰 요청만 들어오는 안타까운 상황이다;;; 리뷰해야 할 논문이 넘쳐나는 요즘의 경험을 잊기 전에, 연재 8편 부터 먼저 작성해 본다.

연구의 시작은 비판적 사고(Critical thinking)에서 출발한다. 비판적 사고를 통해, 기존 연구들을 깊이 있게 답습하여, 아직 해결되지 못한 문제들이나 개선이 필요한 부분들을 찾아야 한다. 또 문제를 해결하는 과정과 해법이 타당한지도, 비판적 사고를 통해 끊임 없이 검증 해야 한다. 다시 말해, 연구의 시작과 끝은 비판적 사고에서 나오는 다양한 질문들에 답을 하는 과정이라 할 수 있겠다. 철이 철을 날카롭게 하듯(Proverbs 27:17), 비판적인 사고로 무장한 연구자들이 서로의 연구들을 비평하여 발전시켜 가면서 학문의 영역은 넓어지고 밝아지는 것이다.

대학원 생활 중 비판적 사고를 기를 수 있는 길이 바로 논문 리뷰(평가)이다. 문제를 정의하고 해결하는 다른 연구자의 논문들을 처음부터 끝까지 세밀하게 살펴보는 것이다. 그래서 해당 연구가 정의한 문제가 중요한 문제이고, 문제의 해법이 타당한지를 검증한다. 물론 본인의 연구도 같은 태도로 검증을 해야 한다.

논문을 읽을 때, 이 논문을 합격시킬 것인지 불합격 시킬 것인지의 관점에서 리뷰를 작성하면 비판적 사고 훈련에 많은 도움이 된다. 하지만, 대학원생 초년차 때는, 논문을 읽고 이해하는 것만으로도 벅차다. 연구의 `연'자도 모를 때, 해당 분야의 논문을 한 번도 써본적이 없는 내가, 어떻게 논문을 비평할 수 있겠는가?라는 생각을 은연 중에 많이 했다. 세상에는 다양한 사람들이 있어서, 누군가의 업적에 작은 장점이라도 있으면, 격려해주고, 칭찬해주는데 익숙한 사람이 있는 반면, 작은 실수와 모자람에도, 비판을 하고 지적을 많이 하는 사람들이 있다. 전자를 보고 착한 사람이다 후자를 보고 못된 사람이다라고 이야기 할 수 없다. 단지, 그 사람의 성격과 다른 사람을 대하는 스타일일 뿐이다. 전자와 후자의 특성들을 잘 조합하면 금상첨화겠지만, 뭇 사람들은 그러기가 쉽지 않다. 한 가지 이야기 하고 싶은 것은, 학문의 세계는 논리적이고 냉정해서, 후자의 경우가 학문 세계에 더 적응하기 쉽다는 사실이다. 나는 후자 보다, 전자에 가까운 사람이라, 속된 말로 논문을 까야 할 때, 좀 힘들었다. 특히 학술대회나 저널에 이미 발표된 논문을 읽을 때면, 검증 받은 논문일 텐데 무슨 문제가 있으려나라는 선입견을 가지고 읽기 때문에, 더욱 비판적인 사고를 하기가 힘들었다. 하지만, 훌륭한 연구자가 되기 위해서는 반드시 갖추어야 할 '미덕'이, 내가 한 연구 포함 모든 연구물에 대해서, 적나라한 비판적 사고를 할 수 있어야 한다는 점이다.

나의 경우, 지도교수님의 부탁으로, 아직 출간되지 않는 논문들의 리뷰 작성 훈련을 많이 했고, 이를 통해 나도 모르게 비판적 사고를 계속 키워갈 수 있었다. 지도교수들이 학술대회 committee라 불리는 위원회에 속해 있으면, 짧은 기간 동안 여러 편의 학술대회 논문을 심사 해야 한다. 혹은, 저널의 편집 위원이거나 특정 분야의 전문가일 경우, 저널의 투고된 논문들을 리뷰 하기도 한다. 이 때 지도교수가 할당 받은 논문을 연구 그룹에 있는 대학원생들에게 보내, 리뷰를 작성하라고 요청을 한다.

지도교수가 학생에게 아직 출간되지 않은 논문의 리뷰를 요청하는 가장 큰 이유는, 대학원생의 비판적 사고를 키우는 훈련을 하기 위함이다. 초년차 대학원생에게, 리뷰를 부탁하는 것은, 시간도 많이 걸리고, 아직 비판적 생각의 부족으로 도움이 그렇게 많이 되지는 않는다. 나의 지도교수님의 경우, 초년차 때는 내 리뷰를 받으신 후 본인의 리뷰를 늘 보여주셨다. 그래서 교수님 리뷰와 나의 리뷰를 비교하면서, 내가 미처 생각하지 못한 비평에 대해 참조했고, 선배 연구자의 비판적인 사고를 자연스럽게 습득할 수 있었다. 그리고 초년차를 지나 특정 분야의 연구들을 많이 이해하고 있을 즈음에는, 교수님께서 본인의 리뷰에, 나의 리뷰 중 납득이 되는 부분을 추가하셨다. 아마도, 교수님께서 미처 생각하지 못한 해당 논문의 약점을 내가 잘 찾아 비평을 했던 모양이다. 의견이 맞지 않는 부분은 서로 토론하기도 했다. 또 언제부턴가는, 나의 리뷰를 기본으로 두고, 본인의 리뷰를 추가하셨다. 졸업 할 때 쯤에는, 내가 리뷰를 보내 드리면, 따로 피드백이 없으셨다. 어떤 때는, 교수님께서 편집위원으로 있는 저널에 공식 리뷰어로 초청해주시기도 했다.

나의 경우를 돌아보면, 지도교수님이 부탁했던 논문들을 리뷰하면서, 정말 자연스럽게 비판적 사고 훈련이 된 것이 아닐까 싶다. 앞에서 처럼 초년차 부터 졸업 때 까지, 내 리뷰에 대한 교수님의 대처 방식이 달라진 것을 보면 확실히 그런 것 같다. 모든 지도교수가 그런 것은 아니겠지만, 왕성한 학회활동을 하시는 지도교수님 밑에 있었기에 누릴 수 있었던 훈련이 아닐까 싶다. 물론, 지도교수가 본인의 일을 학생에게 떠 넘기는 것 아니냐고, 불만을 가지는 대학원생들이 있을 수도 있다. 설사 지도교수가 그렇다 하더라도, 리뷰를 통해 비판적 사고를 키울 수 있는 기회는 놓치지 말자. 그리고, 본인의 리뷰가 터무니 없으면, 지도교수도 대학원생의 리뷰를 있는 그대로 쓸 수는 없을 것이다. 리뷰의 질이 결국 지도교수 본인의 연구 명성과도 연결되기 때문이다. 지도교수가 연구 커뮤니티에서 인지도가 있고 열심히 활동하신다는 것은, 대학원생으로 감사해야 할 일이다. 좋은 연구자가 된다는 것은, 좋은 연구 성과를 만들어 내는 것과, 다른 사람들의 연구를 잘 평가하여 (peer-review) 양질의 연구 커뮤니티가 유지 될 수 있도록 봉사하는 것도 포함한다. 그렇기에, 내가 어떤 학술대회와 저널 논문의 리뷰 경력이 있는지가 연구 이력의 중요한 부분이 될 수 있다. 출간되지 않은 논문 리뷰의 장점은, 정말 따끈 따끈한 새 연구들을 미리 맛볼 수 있다는 점도 있으니, 지도교수의 논문 리뷰 부탁은 기쁨으로 수락해야 할 일이다. 하지만, 지도교수도 학생들의 리뷰에 있는 문장을 가져다 쓰는 것이라면, Sub-reviewer로 학술대회 proceedings에 acknowledge하는 것을 잊지 말아야 하겠다. 요즘 웬만한 학술대회 논문집에는 Sub-reviewer들의 이름 목록이 나온 페이지를 첨부한다. 아니면, 리뷰 시스템을 통해, sub-reviewer를 공식적으로 초청할 수도 있다. 그래야 학생들이 이력서에 리뷰 경력을 한 줄이라도 더 넣을 수 있지 않겠나...

8편: 논문 리뷰에서는 내가 받은 리뷰와 내가 했던 리뷰 경험들을 바탕으로, 몇 가지 논문 리뷰 작성하는 팁을 정리해 보았다. 아래 항목에 순서대로 답을 하는 방향으로 리뷰 할 수 있으면, 리뷰의 기본적인 내용을 채울 수 있을 것이다.

먼저, 학술대회 논문 리뷰가 어떤식인지 한 번 살펴보자. 2년 전에 Reject을 받았던 논문의 3개의 리뷰 중 첫 번째 리뷰이다. 내용을 읽을 필요는 없다. 구조만 보면 된다.

First reviewer's review:

          >>> Summary of the submission <<<

The paper tackles the issue of heterogeneity in defect prediction datasets.

There has been a lot of recent research in cross-project defect prediction, but

these approaches work only if the datasets that are used have the same metrics.

If a dataset defines additional metrics that the other datasets do not define,

they will be dropped from the cross-project defect prediction approach. To

address this, the approach presented here proposes to analyze the metrics in the

datasets to determine if they have behave similarly. If they do behave similarly

(according to a given metric and a given threshold), the approach then links the

metrics, regardless of whether they are the same or not. In this way the defect

prediction approach is not forced to drop as much data as previously.

The approach is then evaluated extensively. Five groups of datasets are used for

the evaluation, for a grand total of 28 datasets. The approach is compared both

to within-project defect prediction, and to cross-project defect prediction with

only the common metrics included. The results show that in a number of cases,

this approach outperforms within-project defect prediction, and cross-project

defect prediction. Taking all results in account, it outperforms both

approaches. On the other hand, the performance is less stable than

within-project defect prediction (but it is slightly better than cross-project

defect prediction with common metrics). The results also show that the approach

is able to be executed in the majority of cases, but not in all the cases (as

sometimes the metrics are just too dissimilar). Finally, a win/tie/loss analysis

is performed against the two baselines, and the approach wins more often than it

loses. The losses are analyzed, and it is found that a reason for losses are

metrics that have a similar distribution, but a different correlation with the

defect metric.

          >>> Evaluation <<<

Points in favor:

- This is a good idea, that is well motivated and well-explained (in general the

paper is mostly well written). It is very novel as I don't recall seeing it

before. Actually, I was curious whether this idea has been explored in the

machine learning community at large. If so, a reference to this would be

welcome.

- The approach is well-detailed, as is the experimental design. The experimental

design shows that care was taken to pick a large number of datasets, and three

different but complementary evaluation scenarios, and hence shows the

seriousness of the evaluation.

- This convincing evaluation shows the potential of the approach, in terms of

performance improvement. It also shows its pitfalls, especially the issue shown

in figure 6 of metrics with similar distributions, but a widely different

correlation with bugginess.

Points against:

- I would have liked a more thorough evaluation of the frequency of the metric

matching problem. Right now the paper only quotes a few numbers extracted from

references. An in-depth study of the percentage of common metrics between

datasets would have significantly strengthened the motivation.

- The paper has a lot on the different normalization metrics (nearly a page),

but very little of that is reflected in the results (as only one of the metrics

is used throughout the paper, the other 3 are mentioned only towards the end).

- There is a missing paper in the related work that should be mentioned:

Feng Zhang, Audris Mockus, Iman Keivanloo, Ying Zou: Towards building a

universal defect prediction model. MSR 2014: 182-191

Minor comments:

- As a validation it would be great to see how much you can improve on the 18

percent figure of the PROMISE repository mentioned in the related work.

- The paper states that metrics can be matched even if "[...] the instances of

these datasets are in different granularities including file, class, and

function.". You did not discuss the implications of this. It would be

interesting to do so.

- It would be great to investigate how the "distance" between datasets (e.g.,

the percentage of metrics they have in common before matching, and after

matching) has an impact on the results. Are the best improvements obtained for

datasets that are relatively close together, or ones who are really distant? The

relation of this to the coverage would be interesting.

- It would be interesting to investigate how the approach works using a group of

projects from the same dataset as basis, not only a single project.

다른 분야는 잘 모르겠지만, 소프트웨어 공학 관련 학회나 저널에서 볼만한 일반적인 형태의 리뷰 내용이다. (1) 리뷰어가 이해한 논문에 대한 간단한 요약 정리, (2) 논문에 대한 평가 (합격시켜야 할 이유, 떨어뜨려야 할 이유) (3) 합격 여부에는 영향을 끼치지 않지만, 논문을 완벽하게 만드는데 도움이 되는 모든 것 (질문들과 제안, 오탈자 등등) 등의 순서로 적혀 있다. 리뷰어들은 리뷰 작성 외에, 논문 합격 여부를 최종 결정해야 하는데, 학술대회나 저널마다 선택 옵션이 다 다르다. 예를 들면, 많은 학술대회에서는 Accept/Weak accept/(Neutral)/Weak reject/Strong reject 등, 4~5가지 선택 옵션들이 있고, 저널의 경우는, Accept as is/Conditional accept/Minor revision/Major revision/Resubmit as new/Reject 등 약간 다른 옵션들이 있다. 저널의 경우는, 한 번 제출로 당락이 아닌, 수정/제출의 반복이 가능하기 때문이다.

그러면, 논문 리뷰 항목별로 어떻게 작성하는지 살펴보자.

1) 간단한 요약 정리 (Summary)

논문이 무엇을 했는지 간단하게 작성하면 된다. 문제가 뭐고, 문제 해결이 되면 좋은 점(contribution)이 뭔지, 문제를 해결하기 위해 어떤 방법을 썼는지, 제안하는 방법이 정말 좋은지를 어떻게 평가 했는지, 결과는 무엇인지 등의 질문에 답을 논문에서 설명하는 내용 그대로 간단히 적으면 된다. 위의 예시로 나온 리뷰는 요약이 좀 긴편인데, 아마도, 원래 리뷰어(지도교수)의 대학원생이 작성한 것을, 원래 리뷰어가 참고해서 최종 작성한게 아닌가 싶다. 보통 리뷰 경험이 많은 대가나 연구자는, 요약을 길게 쓰지 않고, 학술대회 의장이 쉽게 알아먹을 수 있도록, 3-4줄짜리 요약 정도만 한다. 요약을 쓰지 않는 사람들도 있다. 논문의 Abstract만 보고 이 논문이 뭐하는 논문인지 알 수가 있는 사람이라면, Abstract을 본인의 말로 paraphrasing할 수 있을 정도면 문제 없다. 

만약에, Abstract만 보고 무엇을 하는 논문인지 이해가 잘 안가면, 저자가 Abstract을 개떡 같이 썼거나, 아니면 내가 해당 논문의 배경지식이 없는 비전문가라는 말이다. 후자의 경우에는, 논문을 리뷰하면서 Related work을 참고해, 해당 분야의 큰 그림을 스스로 공부하고 논문 전체를 읽은 후, 자세한 요약을 작성 해야 한다. 만약 전자라면, 논문 Presentation이 좋지 않음을, 당락에 대한 평가에서 적으면 그만이다. 내가 생각하기로는 위의 예시는 배경지식이 부족했던 대학원생이 논문 관련 배경지식을 공부한 후, 논문 전체의 내용을 차근 차근 잘 정리한 요약이라고 생각이 된다. 초년생 대학원생이라면, 이런식으로 본인이 익숙하지 못했던 연구 분야에 대한 공부도 덤으로 할 수 있다.

2) 당락에 대한 평가 (Evaluation)

먼저, 논문이 합격되어야 할 좋은 점(Points in favor)이 있다면 모두 나열한다. 예를 들어, Novel idea, Good motivation, Easy to read, Reproducible, Convincing results 등등이 있겠다. Novel idea는 해당 논문이 아무도 생각지도 못한 문제를 해결했거나, 기존에 존재하던 어려운 문제를, 더욱 참신한 방법으로 해결을 했는가에 대한 부분이다. 논문 당락에 있어서 가장 중요한 부분이다. 해당 분야를 잘 아는 연구자라면 쉽게 알 수 있지만, 초년차 대학원생들은 좀 평가하기가 어려울 수 있다. 하지만, 좋은 논문이라면 해당 분야를 잘 모르는 사람들에게도 논문이 충분히 novel하다는 것을 잘 서술을 했을 테니, 논문이 잘 읽히고 이야기 하는 바가 수긍이 가면 합격에 가까운 논문이라고 생각해도 큰 무리가 없다. 대개는 Introduction만 보고, Novel idea임을 확신 할 수 있으면, 좋은 논문으로 간주하고 리뷰를 시작해도 좋다. Good motivation은 이 논문이 해결하고자 하는 문제가 정말 의미가 있고 가치 있고 중요한 문제인지에 잘 서술하고 있는지 보는 것이다. 비록 Novelty가 높지는 않지만, 동기가 중요한 연구라면, 합격을 줘야한다(고 생각한다). 논문이 잘 읽히는지도 중요한 부분이다. 아무리 연구 결과가 좋고, 내가 만든 Approach가 Elegant하다고 하더라도, 글을 통해 잘 전달하지 못하면, 읽는 사람에 따라 연구의 내용을 전혀 다르게 받아드릴 수 있다. 마지막으로, 논문의 내용만으로 연구 내용을 내가 똑같이 재현해(Reproducible)낼 수 있을 만큼 구체적인 정보들이 있어야 한다. 그리고 논문이 제시하는 최종 결과과 납득이 되는가(Convincing results)에 대한 부분이다. 나의 경우, 논문을 떨어뜨려야 할 아주 심각한 결점이 없고, 위의 다섯가지 요소를 대체로 충족할 수 있다면, Accept을 준다. 위의 예시에서, 첫번째 리뷰어는  Novel idea, Good motivation, Convincing results 부분에서 그럭저럭 긍적적인 평가를 주었다. 아마도 Weak accept의 결정을 주지 않았을까 추측해 본다. (다시 말하지만, 위 예시는 떨어진 논문의 리뷰이다. 아마도 2번째 3번째 리뷰어가 Reject을 준 것 같다.)

그 다음에, 논문을 떨어뜨려야 할 이유(Points against)를 찾아야 한다. 일단 앞 단락에서 합격해야 할 요건을 충족시키지 못하는 내용들이 있다면, 나열한다. 그리고, 각 요소들에 대한 근거를 저자들에게 납득이 가도록 논리적으로 잘 설명을 해야 한다. 그리고, 논문이 가지고 있는 추가적인 중대한 결함이 없는지 차근차근 살펴보아야 한다. 나는 대게 다음의 내용을 주로 본다: Wrong or too strong assumption, Wrong evaluation/experimental design, Weak evaluation (lack of experimental subjects), Lack of discussion. 

Wrong or too strong assumption: 실험을 하다보면, 모든 여건을 만족시킬 수 없기에, 어떤 상황들은 가정을 하고 진행할 때가 있다. 하지만, 해당 가정이 연구의 Motivation과 상충되는 가정이거나, 현실적으로 수긍하기 어려울 정도로 너무 강한 가정이라면, 위험한 연구이다. 가정이 무너지면, 연구 전체가 무너지기 때문이다.

Wrong evaluation/experimental design: 참신한 아이디어로 새로운 문제를 해결했지만, 해당 아이디어를 올바르게 평가하거나 실험하지 못했다면, 반드시 Reject을 줘야 한다. Weak evaluation (lack of experimental subjects) 부분도 여기에 해당이 될 수 있을 것 같다. 대게 Empirical study를 통해 연구 결과를 일반화 한다는 것은 쉬운 일이 아니다. 결국 내가 선택하는 실험 subject들 안에서 나온 결과이기 때문이다. 반드시, 다른 연구자가 충분히 납득할 만큼(이게 좀 애매하긴 하다. 적어도 기존 연구에서 한 만큼은 해야한다)의 subjects로 실험을 해야 하고, 어떤 위험요소(threats)들로 인해 연구의 결과를 일반화기 어려운지, 또 오류가 있을 수 있는지를 반드시 밝히고 솔직하게 논의해야 한다 (Threat to Validity). 만약 실험의 비용문제로, 충분한 subjects를 확보하기 어렵다면, Case study로도 결과를 보여줄 수 있으니, 리뷰시 참고하도록 하자.

Lack of discussion: 연구 문제가 참신한 방법으로 잘 해결되고, 실험에서도 제안하는 방법이 문제 해결에 좋은 결과를 보여준다고 해도, 왜 이런 좋은 결과가 나왔는지에 대한 이유를 심도 있게 논의해야 한다.

논문을 떨어뜨려야 할 이유를 이야기할 때, 어떻게 하면 논문을 질적으로 개선할 수 있을지에 대한 건설적인 의견을 주면 저자들에게 많은 도움이 된다. 앞에서 떨어진 논문이, 2015년도 FSE에 Accept이 됐는데, 두 번 Reject을 받으면서 받았던 리뷰들이 논문을 개선시키는데 정말 많은 도움을 주었다. 새로운 Approach를 알아보는 시각을 깨닫게 해주기도 했고, 결과들을 잘 논의하는데 필요한 몰랐던 기존 연구들도 알게 되었다. 결국 내가 누군가에 해주는 건설적인 리뷰는, 양질의 연구들을 커뮤니티에 나오게 하는 마중물과 같은 중요한 역할을 한다. 이런 점을 염두하고, 냉철하게 논문을 비평하되, 건설적인 리뷰도 제공할 수 있어야 한다.

연구 분야별로 고려해야 할 평가 항목들이 다를 것이다. 소프트웨어 공학 연구는 개발자를 돕는 새로운 기술 개발 연구가 많기에, 어떤 특정 문제 해결을 위한 새로운 기술을 제안하고, 실험을 통해 기존의 기술보다 좋은지 안좋은지 평가한다. 이런 형식의 연구라면, 위의 평가 항목들이 당락에 중요한 기준이 될 것으로 생각된다. 아래는 Reject 받았던 내 논문의 2, 3 번째 리뷰어의 Evaluation부분의 항목들이다. Motivation과 discussion부분이 큰 약점 이었음을 살펴 볼 수 있다.

Second reviewer's review

...

        >>> Evaluation <<<

+ Thorough analysis

+ Salient research topic

- Lack of discussion of limitations that could make the technique impractical

- Lack of guidance on practical use (i.e. should we abandon using our own

project data for prediction?)

- Use of multiple words/phrases for the same concept made the reading confusing

...

Third reviewer's review

  >>> Evaluation <<<

Favour: The topic is interesting. The work appear to be original in what it

claims. The idea of "cross-domain defect prediction" is intrigging.

Weakness:

1)The motivation of this work is not clearly presented.

...

2)In the Related Work Section, the reference papers may not be sufficient. 

...

3)This paper does not clearly discuss how to select features of source datasets

or how to compute the feature similarity. Without such details, it is difficult

to justify whether this approach can be easily applied in practice.

4)The authors have not clearly demonstrated the reason of choosing CFS

(Correlation-based Feature Subset Selection) on feature selection in source

datasets

...

5)There is not a systematic way to match features of the source and the target

datasets....

3)  논문을 완벽하게 만드는데 도움이 되는 모든 것 (질문들과 제안, 오탈자 등등)

위의 예시에서, 2, 3 번째 리뷰어는 Minor comments를 주지 않았다. 대신 Reject에 대한 이유들과 중요한 논문의 개선점 이외에 작은 문제들까지도 한꺼번에 나열했다. 혹시 Reject을 주고 싶은 논문이지만, 연구가 잠재성이 있다면, 건설적인 의견을 주는 것이 굉장히 중요하다. 그래서 리뷰 작성의 마지막 부분에, 당락에 영향을 주는 큰 문제가 아닌 작은 문제들에 대한 구체적인 의견을 따로 제시하면, 저자들에게 많은 도움이 된다. 이해가 안가는 단락이 있으면, 이해에 도움이 될 만한 관련 질문을 남길 수도 있고, 오탈자는 문법이 틀린 부분에 대해서도 어떻게 수정하면 좋은지 의견을 줄 수 있다.

이상으로, 논문을 리뷰하는 방법을 내 경험에 비추어 간단히 정리해 보았다. 다시 말하지만, 연구에서 가장 중요한 자질은, 비판적 사고이며, 비판적 사고 훈련에 논문 리뷰 만큼 좋은 것은 없다. 초년차 대학원생 때는, 논문을 읽으면 배경 지식 부족으로 이게 좋은 논문인지 안 좋은 논문인지 판단하기 쉽지 않다. 하지만, 좋은 논문이란, 배경 지식이 별로 없는 사람에게도, 잘 읽히는 논문이다. 만약에, 논문이 이해가 잘 안가면, 주눅들지 말고, 논문이 좋지 않다고 생각하며, 어떤 점이 안 좋은지 차근 차근 생각해 보라. 그러다가 보면, 자연스럽게 앞에서 이야기한 Evaluation항목들에 대한 리뷰를 적을 수 있을 것이다.

이 번 포스팅의 결론은 다음과 같다.

1. 비판적 사고를 훈련하기에는, 논문 리뷰 작성 만큼 좋은 것이 없다.

2. 지도교수가 논문 리뷰를 요청하면, 감사함으로 수락하자. 따끈 따끈한 새 연구를 미리 볼 수 있고, 나의 결정이 논문의 당락을 결정하는 짜릿한 경험을 할 수 있다.

3. 논문 리뷰는, 간단한 요약으로 시작해서, 논문의 당락을 결정하는 확실한 이유와 근거를 작성한 후, 논문의 질을 전반적으로 향상시킬 수 있는 제안 등으로 마무리 한다.

4. 내 논문도 동일한 관점으로 비평하면, 더 좋은 논문을 쓸 수 있다.

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