요 근래 두문불출(?)하고 바빴던 이유는 OSDI¹ 학회에 poster abstract²를 제출하기 위해 한동안 삽질(...)하고 있었기 때문이다. 여름방학 때부터 이어서 하고 있던 PacketShader의 후속 프로젝트로, 대략 GPU 기반 소프트웨어 라우터에서 forwarding table을 관리하기 위한 구조를 만들 때 생기는 이슈들을 다루는 내용이다.

보통 정식논문과 달리 poster abstract는 형식이 자유로운 편이다. (글꼴 크기, 여백 제한, 분량 정도만 지정해줌) 하지만 학회마다 poster abstract를 쓰는 스타일이 상당히 다른 듯한데, 이번 포스터도 처음에는 거의 소논문 같이 two-column layout에 레퍼런스 달고 엄청 길게 썼다가 아무래도 USENIX 학회들은 심플한 걸 원하는 것 같다는 판단에 따라 one-column으로 고치고 세 문단을 한 문단으로 합치고(...) 하는 삽질을 거쳐 다시 쓰게 되었다.

예전에 블로그에 잠시 한글/영어 혼용 포스팅을 했던 것이나 스웨덴 교환학생 지원하려고 자기소개서 쓴 것, TOEFL CBT 시험을 위해 준비했던 것 말고는 영어로 제대로 글쓰기를 해본 건 이번이 처음이다. 다행히 교수님은 생각보다 잘 쓰는 것 같다고 하시긴 했는데, 역시 처음 써보다보니 실수들이 많았다. 교환학생 시절 스톡홀름 시립도서관에서 영어 소설도 빌려읽고 어쨌거나 영어를 많이 쓰다보니 한국인들이 가장 어려워한다는 관사(a, the)는 그런대로 쓸 만했는데(사실 소유격이나 특정한 걸 지칭하지 않는 복수형은 관사 생략이 가능하다는 점을 이용하면 좀더 쉽게 접근할 수 있다), 대표적으로 단복수 실수부터 시작해서, 맞춤법 검사가 되는 환경에서 작성하던 걸 갑자기 vi로 옮겨 편집하면서 생긴 오타들(moderm, udpate 등), 그리고 몇 가지 문어체 스타일에서 주로 지적을 받았다. 직접 해설을 써주신 경우도 있고 설명은 없지만 '아하, 이건 이래야 하는 거구나' 깨닫는 경우도 있었는데, 특히 also는 피한다든지, usually 대신 typically를 쓴다든지, 주어가 길면 안 되지만 중요한 내용은 앞으로 와야 하고(문장이든 문단이든), 수동태를 피하고, to 부정사를 동사적 용법 말고도 형용사적 용법으로도 적절히 활용해야 하는 점, 문장 자체를 되도록 짧께 끝내는 것 등이 있었다. 간혹 교수님이 아예 문장을 다시 써주시는 경우도 있었는데 문장 표현이 역시 다르긴 다르더라.;; inureyes님은 챗으로 이야기하던 중 '장비나 사물이, 일반적인 개념으로는 사람만 쓸 수 있는 동사를 능동태로 쓰는 것도 생각보다 광범위하게 허용된다'거나, MS Word에서 맞춤법 관련 옵션 다 켜고 한번 넣어보면 꽤 많은 문법 오류 잡아낼 수 있다는 팁을 알려주시기도 했다.

그래도 영어 자체에 관한 건 지적받으면 비교적 쉽게 고칠 수 있는 것들이라 괜찮았는데, 내용 전개가 훨씬 더 어려운 부분이었다. 무언가 하고 싶은 얘기에 집중하다보면, 그 이야기까지 흘러가는 논리적 사고의 흐름에서 무언가 빠뜨리게 되는 경우가 많았다. 특히 한 문장 한 문장이 엮어져 전체적인 근거를 구성해야 하는데 문장들의 연결을 (굳이 접속사를 쓰지 않고도) 자연스럽게 흘러가도록 하는 것이 포인트. 그리고 논문을 목적으로 하는 글쓰기이다보니 역시 대세(?)가 막연히 그렇다고 쓰면 안 되고 실제로 숫자값을 찾아서 구체적으로 레퍼런스를 넣어주는 것이 중요했다. (다만 처음 쓴 버전은 이렇게 했으나 abstract화할 때는 레퍼런스 없이 가긴 했다.) 직접적인 관련이 없는 논문이라도 레퍼런스를 통해 관련 정보를 찾을 수 있는 경우가 많았는데, 검색할 때 직접 원하는 정보가 있는 논문을 바로 찾을 수 없더라도 어떤 논문의 레퍼런스를 보면 그 내용이 있을 것이다라는 감각을 익히는 것이 중요한 것 같다.

어쨌든, 아직 포스터가 뽑힐지 어떨지는 모르겠지만, 영어로 논리적 글쓰기 과정을 통해 논문 쓰는 게 어떤 것이구나 하는 맛보기(?)를 할 수 있어서 큰 도움이 되었다. 특히 이렇게 논리 전개를 해나가려고 하다보면 자연스럽게 실제 코딩하거나 일하는 것도 그러한 논리 전개에 최적화된다는 것을 직접 체험할 수 있었다. 예를 들면 PacketShader의 control plane을 구현할 때 전에는 뭔가 구조적 깔끔함을 고민해가며 진행했다면 이번에는 일단 근거로 제시될 만한 실험을 위한 코딩에 집중하게 되었다. 선배들이 짜놓으신 코드를 보면서 뭔가 구조를 더 깔끔하게 했으면 좋았을텐데 하는 생각을 했는데, 이렇게 놓고 보니 정말 딱 필요한 만큼만 짜고 구조화한 거라는 사실을 알 수 있었다.

한국어로 수필 쓰기에 가까운 블로그를 오래 해와서인지, 논리적 영어 글쓰기는 말의 호흡이 달라서 앞으로 좀더 연습이 많이 필요할 것 같다. 다음 번엔 좀더 나은 글쓰기를 할 수 있었으면 좋겠다.