Bongjun Jang

태어나서 처음 논문 제출

이틀 전 태어나 처음으로 학회에 논문을 제출했다. 우리 팀이 생각하기에 꽤나 재미있는 아이디어를 담은 논문인데 통과될지는 아직 잘 모르겠다. 아이디어를 정리하고 실험할 때는 현존하는 기술 중에 가장 진보한 기술이라는 확신이 있었는데, 막상 제출하고 “Submitted”(제출함)이라는 글자를 보니 별 생각이 다 든다. 논문 제출의 여운이 가시기 전에 내가 프로젝트에 10달 동안 참여하며 느낀 점들을 정리해보고자 글을 써본다.

아만보가 아니라 보만안

아는 만큼 보이는 게 아니라 보는 만큼 안다

전체적으로 소프트웨어 공학 연구는 (1) 아이디어 탐색 및 (2) 간단한 도구 작성 후 (3) 벤치마크 대상으로 성능을 평가하는 과정을 거친다. 그리고 아이디어가 충분히 좋다면 도구를 고도화하고 벤치마크를 확장해가면서 더 강력한 아이디어를 탐색한다. 내가 프로젝트에 참여했을 때는 전반적인 아이디어 탐색은 끝나있었고, 도구를 작성하고 벤치마크를 확장해가며 설정한 문제를 더 효과적으로 풀 수 있는 방법을 찾는 단계였다. 그리고 이 과정이 대략 10달이 걸렸다.

지금 돌이켜보면 이 10달의 시간동안 약 1/3은 낭비였는데, 왜냐하면 이미 해결된 문제를 우리만의 방식으로 다시 풀고 있었기 때문이다. 더 효과적인 방법을 생각해냈다고 1~2주동안 혼자 좋아하기도 했었는데, 사실 더 좋은 방법이 세상에 이미 있었고 나는 그 사실을 모르고 있던 거다. (프로그램 실행 과정을 추적하기 위해 조건문 덮이를 사용하고 있었는데, 사실 실행흐름 그래프 덮이를 사용하면 모두 해결되는 문제였다. 게다가 실행흐름 그래프 덮이를 측정하는 구현체도 이미 많이 공개되어 있다.) 만약 제대로 된 배경지식이 있었다면 프로젝트 완성까지 시간을 훨씬 더 단축할 수 있었을 텐데 아쉬움이 든다.

하지만 나의 연구 분야라 하더라도 모든 배경지식을 정확히 알고 이해하고 있는 건 불가능해 보인다. 내가 아무리 전산학을 전공했다고는 하지만 연구를 하다보니 모르는 것들 투성이였고, 같은 연구실 옆자리에 앉은 분들의 프로젝트도 아직도 정확히 이해하지 못하고 있다. 다음에도 이런 일들이 일어나지 않으리라 생각하기 쉽지 않다.

(내 생각이지만) 우리 팀이 이 문제점을 발견하게 된 것은 벤치마크 확장을 통해서 였다. 처음에 가지고 있던 벤치마크에는 다여섯개의 평가 대상 밖에 없었다. 그런데 이를 열개 이상으로 확장하면서 우리가 사용했던 방법이 먹혀들지 않는 경우를 확인했고 이 문제를 해결하려고 점점 더 이상한 방향으로 도구를 고도화했다. 여기에서 왜 이 방법을 굳이 써야하는지 의문이 들 수 밖에 없었고, 교수님도 그걸 느끼셨는지 이미 나와있는 방법을 쓰지 않을 이유가 없다고 하셨다. 조건문 덮이를 활용하기 위해 기상천외한 방법으로 코드를 꼬아가며 해결했던 문제를 실행흐름 그래프 덮이를 사용하자 말끔히 해결되었다.

이 에피소드에서 내가 얻어간 것은 아는 만큼 보이는 것도 중요하지만 보이는 만큼 알게 되는 것도 많다는 것이다. 모든 것을 알고 있는 건 거의 불가능하기 때문에 많은 케이스를 관찰해야 한다. 사실, 이 세상에 없는 아이디어를 발굴해내는 연구라는 과정에서 많이 알고 있는 것보다 중요한 것은 더 많은 케이스를 보고 이해하려는 끈기일지도 모른다.

실험실 여포를 만들지 말자

현실에서 사용가능한 도구를 만들어야 한다

쓰다보니 또 벤치마크 이야기고, 벤치마크 확장을 통해 얻은 교훈이다. 더 자세히 말하면 실험 설정에 관한 이야기이다. 아이디어 발굴, 도구 고도화, 벤치마크 확장이라는 과정을 거치며 연구를 지속하다 보면 떠오르는 모든 아이디어가 보고 있는 벤치마크에 과적합될 수 밖에 없다. (당신을 기계학습 모델이라고 생각하고 학습 데이터만 오랜 시간 보고 있다고 생각해보면 된다.)

이런 식으로 연구가 진행되면 현존 최고(State-of-the-Art, SOTA) 도구를 너무 쉽게 이겨버리는 일도 자주 일어난다. 왜냐하면 우리 도구가 우리 벤치마크에 알맞게 최적화되어 있기 때문이다. 당연히도 내가 유리한 상황에서만 SOTA를 이기는 건 아무런 도움이 되지 않는다. 어떤 상황에서도 강력한 아이디어를 개발하는 것이 우리의 목표이기 때문이다. 게다가 이런 상황에서는 우리 도구가 꽤 괜찮다는 근거없는 자신감이 샘솟아 연구에 진척이 없는 상황도 벌어진다. 이런 답보를 막기 위해서는 현실세계에서 테스트해야 한다. 다시 말해 벤치마크를 확장해야 한다. 실험실에서만 강력한 도구는 쓸모가 없다.

아이디어가 어느정도 괜찮다는 생각이 들고 도구도 꽤 안정적으로 돌아가는 시점이 오면 현실세계에서 테스트도 해보고 과감히 벤치마크를 늘리자. 지금 실험하고 있는 아이디어의 장점과 약점을 모두 들여다볼 수도 있고, 미처 생각하지 못했던 부분도 들여다볼 기회가 될 것이다.

간단한 아이디어 만들기

같은 현상을 설명하는 두 주장이 있다면, 간단한 쪽을 선택하라

<오컴의 면도날>

전공 수업을 들을 때, 사소한 디테일이나 복잡한 내용에 사로잡혀 헤매다가 어느 순간 머리 속에 핵심만 남아 이론을 명쾌하게 이해하기 된 경험이 있는가? 이런 핵심들은 사실 다시 생각해보면 너무나도 단순해서 잊어버리기도 쉽지가 않다. 과학과 공학의 내용들이 자세히 들여다보면 복잡한 것은 사실이지만 대부분 전체적인 내용을 한 문장으로 요약해 말할 수 있다.

예를 들어, 일반상대성 이론은 뉴턴의 만유인력(“질량이 있는 두 물체는 서로 끌어당김”)을 시공간의 왜곡(“질량이 있는 물체는 주변 시공간을 휘게 만듦”)으로 일반화한 것이다. 인류 역사에 남은 두 천재의 이론 또한 한 문장으로 요약이 가능하다. 그렇기 때문에 우리의 아이디어도 한 문장으로 요약할 수 있을만큼 간단해야 한다. 간단하지 않다면 부연설명이 많이 붙기 마련인데 주저리주저리 설명이 많다보면 그에 따라 질문거리도 많아지기 때문에 강력한 주장을 만들어내기가 어렵다. (랩 내부 세미나만 하더라도 질문 하나하나가 날카롭기 때문에 말문이 막히는 경우가 많다.) 이런 경우에는 이렇게, 저런 경우에는 저렇게, 분류가 복잡해지거나 예외 케이스가 늘어나고 있다면 스스로를 의심해보자.

게다가 간단한 아이디어는 좋은 실험 결과를 만들어내기도 하고 재사용하기도 쉽다. 아이디어가 간단하면 실험 결과를 분석하는 것도 쉽다. 따라서 도구를 고도화하고 아이디어를 다듬는 일도 쉬워지니 좋은 실험 결과는 따라오기 마련이다. 연구를 이어서 확장할 때에도 단순함이 도움이 된다. 복잡한 아이디어는 숨겨진 가정이 많아서 적용하는 데 애를 먹게 된다. 우리가 우리의 아이디어를 재사용하는 것 뿐만 아니라, 다른 연구자들이 우리의 연구를 찾아보게 되는 날에도 단순함이 빛을 발할 것이다.

데이터 관리, 듀(Due)의 법칙, 수동조작 없애기

그 외 잡다한 노하우도 배웠고 다음 연구에는 적용하고 싶은 것들도 많이 생겼다. 일일히 설명하는 것은 글이 너무 길어질 것 같아서 단순하게 설명을 해보면 다음과 같다.

마치면서

학부를 졸업하기 전에 열 달이라는 적지 않은 기간동안 이런 경험을 할 수 있던 것은 큰 행운이다. 수업과 연구를 병행하는 데 어려움을 겪기도 했지만 만족스러운 성과와 함께 논문 제출이라는 결실까지 맺었으니 이보다 훌륭한 경험은 없을 것이다. 곧 진학할 석사 과정에서도 좋은 연구성과를 내면 좋겠다. 나머지 기간동안은 다음 연구 주제를 발굴하며 재충전의 시간을 보내야겠다.

저에게 이런 기회를 주신 카이스트 허기홍 교수님과 카이스트 프로그래밍 시스템 연구실 석사과정 권재성님, 그리고 카이스트 프로그래밍 시스템 연구실에 계신 모든 분들에게 감사의 말을 남깁니다.