홈그라운드에서 열린 PL 학회 탐방기
역사적인 순간: 연구실 전원이 참석한 최초의 국제 학회 |
들어가며
프로그래밍 언어 분야의 세계 최고 수준 국제 학회 PLDI가 서울에서 열렸다. 학회 첫날, 대전에서 아침 일찍 출발하여 도착한 서울은 비가 내리고 있었다. 우선 악명 높은 출근시간 1호선 지하철을 통해 서울역에서 숙소로 향했다. 학회장에 캐리어를 들고 다니기는 불편하기에 숙소에 짐을 맡긴 후 도보로 학회장까지 이동하였다. 비와 안개가 어우러진 고층 빌딩 숲은 대전 시민에게 이국적인 풍경이었고 새벽부터 시작된 여행의 피로와 함께 마치 외국에 나온 것 같은 기분을 선사하였다. 덕분에 한국에서 열리지만 충분히 낯선 두근거림으로 학회 일정을 시작하게 되었다.
PLMW
이번 PLDI는 월요일과 화요일은 워크샵 및 튜토리얼로, 수요일부터 금요일은 본 학회 일정으로 진행되었다. 특이하게 이번 PLMW(Programming Language Mentoring Workshop)는 2일에 걸쳐 진행되어서 월요일과 화요일 모두 PLMW에 참석하였다. 이런 류의 멘토링 워크샵에 여러번 참석해보았고 이전 글에도 소개한적이 있지만, 이번 PLMW는 특히 유익했다. 첫날은 학생들끼리 서로 친해지고 교류할 수 있는 순서로 구성되었고, 둘째날은 교수님들의 강연으로 구성되었다. 첫날에 다양한 사람들을 만난 덕분에 이후 학회 일정동안 다시 마주칠 때마다 편하게 인사하고 대화할 수 있었다.
PLMW 첫째날
크게 두 순서가 있었다. PL Cards 와 Skill Exchange. 이름만 봤을 때 무슨 활동인지 짐작이 가는가? 홈페이지에도 순서 이름을 제외하고는 아무 설명도 없어서 전혀 감이 오지 않아서 모두 궁금해했다.
우선 PL Cards는 아이스 브레이킹용 게임이었다. 일종의 몸으로 말해요와 비슷한 게임인데, 프로그래밍 언어(PL) 분야의 다양한 용어를 설명해야 하는 게임이었다. 이 순서를 위해 PL 관련 용어가 적힌 카드가 준비되어 있었는데 각 카드에는 제시어와 5개의 금지어가 적혀 있었다. 이 때, 금지어를 사용하지 않고 자신의 팀에게 제시어를 설명하는 게임이었다. 기억나는 제시어로는 “soundness”, “type”, “lambda calculus” 등이 있었다. 팀을 두 팀으로 나누어 진행하는데, 상대 팀이 제시어를 맞추는 동안은 카드를 볼 수 있기 때문에 관전하는 재미도 쏠쏠했다. 영어로 인해 난이도는 급상승했지만 한국어로 해도 충분히 재미있을 것 같다. 어느 정도 시간이 지나자 학생들이 알아서 새로운 게임을 진행하기도 했는데, 인디언 포커처럼 각자 한장씩 이마에 붙이고 자기 카드가 무엇인지 맞추는 게임이었다. 이것도 재미가 쏠쏠했다.
이 게임의 의의는 크게 세 가지였다. 우선 같은 팀의 학생들끼리 꽤 친해졌다. 아무래도 학회의 첫 일정을 같은 팀으로 함께하다보니 (나름) 돈독한 유대감이 생겼고 이후에도 편하게 말을 걸 수 있었다. 두번째로 PL 용어를 보다 일상적인 용어로 설명해보는 기회가 되었다. 학습의 마지막 단계가 남에게 설명하는 것이라고 하는데, 내가 이 개념을 잘 이해하고 있는지 점검해볼 수 있는 좋은 기회였다. 마지막으로 야 너두? 의 유대감을 느낄 수 있었다. 비록 생긴것도 다 다르고 출신 지역도 다 다르지만 같은 용어를 공유한다는 것은 꽤 재미있는 경험이었다.
두번째 순서는 Skill Exchange였다. 참가자들이 관심있다고 제출한 분야를 진행자들이 적당히 선정하고, 각 분야별로 관심있는 사람들이 모여서 자유롭게 이야기를 나누는 시간이었다. 학회 가면 늘상 하는 일이 모르는 사람 만나서 자기 연구 이야기 하고 남의 연구 이야기를 듣는 것인데, 이번엔 아예 판을 깔아준 것이다. 비유를 하자면 마치 티비 프로그램 “나는 솔로”, 혹은 대전시에서 지원하는 청년만남 지원사업 같은 느낌이다. 나는 프로그램 분석 및 검증 분야를 선택했는데, 약 10명 정도의 학생들과 한 그룹이 되었다. 그 중 기억에 남는 사람은 함수형 프로그래밍 언어(정확히는 하스켈)로 작성된 프로그램을 대상으로 기호 실행을 하는 학생이었다. 기호실행이 필요할 정도의 하스켈 프로그램이 있는 줄도 몰랐지만, 하스켈 프로그램을 위한 기호 실행 기술이 따로 필요하다는 것도 처음 알았다. 학회에 처음 참석하는 학생들이라면 이 순서는 모쏠들에게 “나는 솔로” 프로그램이 유익한 정도로 유익했을 것이다.
PL Card 예시 |
PLMW 둘째날
둘째날은 여러 교수님들의 흥미로운 강연으로 구성되었다. 많은 분들이 연구에 대한 각자의 큰 그림과 대학원 생활에 대한 조언을 해주셨다. 유익한 내용이 많았지만 유독 기억에 깊이 남은 몇 가지만 소개하겠다.
MIT의 Adam Chlipala 교수님
연구에 대한 상당히 독특한 관점을 가지고 계셨다. 우리가 효과적으로 연구를 하기 위해서는 우리의 사고 방식을 이해할 필요가 있으며, 그 도구는 진화 심리학이라는 것이다. 예를 들어, 인간이 최대로 유지할 수 있는 인간 관계, 즉 Peer Group은 50명 정도라고 한다. 이 때 문제는 인간은 본능적으로 Peer Group의 눈치를 보고 그 안에서의 평판을 중시하는데, 50명의 규모는 혁신적인 아이디어를 수용할만한 다양성이 부족할 수 있다는 것이다. 따라서 이러한 점을 주의하며 연구에 대한 피드백을 최대한 넓은 범위의 사람들에게서 받아야 한다고 조언하였다. 재미있는 점은 이후에도 이 분이 얼마나 이런 관점의 신봉자인지 드러나는 순간이 있었다. Lean 이라는 증명보조도구 개발자의 키노트 강연 후 질문 시간이었다. Adam 교수님의 질문은 “수학자들은 마치 운동선수와 같아서 수학 문제 증명의 어려움 그 자체를 즐기는 면이 있는 것 같다. 그런 점에서 Lean이 그 즐거움을 빼았으면 수학자들이 오히려 흥미를 잃지는 않는가?”였다. 나로서는 한번도 생각해보지 않은 신박한 질문이었다. 우리가 풀려는 문제 뿐 아니라 문제를 푸는 우리에 대한 이해도 있어야 문제를 더 잘 풀 수 있다는 관점은 앞으로도 계속 생각해볼 만한 주제인 것 같다.
조지아텍의 Qirun Zhang 교수님
이 발표는 컨셉은 대학원을 대학원생을 입력으로, 교수를 출력으로 가지는 함수로 비유하여 대학원 생활을 설명하는 것이었다. 따라서 입력과 출력물을 다양한 관점에서 비교하며 대학원이라는 함수가 어떻게 사람을 바꾸는 지 설명하는데 주안점을 두었다. 그 내용 중 두 가지가 특히 기억에 남았다.
먼저 연구 주제 탐색에 관한 것이다. Qirun 교수님은 작고 가까운 것에서 시작하고 호기심을 잘 따라가라고 조언해 주었다. 자신의 경우, 처음에는 운영체제 수준의 시스템에 관심이 있었는데 막상 운영체제는 연구할 것이 많이 없어보였다고 한다. 하지만 운영체제같은 큰 프로그램에 발생하는 치명적인 오류가 알고보니 버퍼 오버플로우와 같은 간단한 문제였다는 것을 알게 되었고, 버퍼 오버플로우를 탐지하는 다양한 프로그램 분석 기술이 필요하다는 것을 깨달았다고 한다. 이런 식으로 자신의 최초 관심사에서 시작하여 호기심을 따라가다보면 자연스럽게 연구 주제를 찾을 수 있다는 것이다.
두번째는 글쓰기에 관한 것이다. 조언은 간단했다. 연습만이 살 길이다. 너무나 흔한 조언이지만 Qirun 교수님의 경험이 인상적이라 공유한다. 자신이 첫 논문을 쓸 때는 어떻게 써야 하는 지 전혀 감이 오지 않았다고 한다. 그래서 유명한 논문 몇 편을 선정해서 섹션은 총 몇개인지, 각 섹션에 문단은 몇개인지, 각 문단은 몇 문장으로 이루어져 있는 지 통계를 냈다. 그리고 각 문장의 목적은 무엇인지까지 모두 정리한 후 이를 바탕으로 자신만의 템플릿을 만들어 논문 초안을 작성했다고 한다. 이 방식이 가장 효율적인 방식은 아닐 수 있다. 실제로 이후에도 지도교수님께서 수많은 첨삭을 해주셨다고 한다. 하지만 나는 이 이야기를 들으며 Qirun 교수님이 그 당시에 얼마나 간절했는지 느낄 수 있었다. 얼마나 절실하게 논문을 잘 쓰고 싶었으면 이렇게까지 했을까? 그 간절함이 있었기에 지금 이 자리까지 오신 게 아닐까 생각했다.
어마어마한 첨삭 기록. |
퍼듀의 Milind Kulkarni 교수님
발표의 제목은 흥미롭게도 “Regularizing the Irregular”였다. 연구와 인생에 적용되는 요약(Abstraction)이 무엇이며, 요약이 득과 실에 대해 논하는 내용이었다. 요약은 시스템의 세부사항을 숨기고 핵심 원리만 남겨서 이해를 돕거나 요약한 시스템 위에 새로운 시스템을 손쉽게 쌓을 수 있게 하는 것이다. 주로 학술 분야에서 생각하는 요약의 개념을 우리 삶에 빗대어서 함께 다루는 관점이 흥미로웠다. 특히 기억에 남는 것은 요약을 함으로써 우리가 잃는 것에 대한 이야기였다.
먼저 본인은 컴파일러를 연구하는데, 인스트럭션의 재배치를 통한 최적화의 경우, 파이프라이닝 등 숨겨진 하드웨어 수준의 세부 사항이 문제가 되어 오히려 성능이 안 좋아지는 경우가 있다고 한다. 즉 이런 경우는 실제로 필요한 정보가 요약에 의해 가려진 것이다. 따라서 연구자라면 요약을 있는 그대로 받아 들이지 않고 평가할 줄 알아야 하며, 필요한 경우 보다 적당한 수준의 요약을 새로 만들어야 한다고 조언했다. 허기홍 교수님도 항상 다음과 같은 비슷한 조언을 하신다: “사용하는 도구를 블랙박스로 여기지 말고 모든 것을 들춰보고 이해하라”. 내 연구에서 요약으로 인해 숨겨진 것이 무엇인지 파악하고 나도 모르게 있는 그대로 받아들인 요약이 있는지 항상 점검해야겠다.
연구 뿐 아니라 우리 삶에서도 요약이 중요한 정보를 숨기기 마련이다. 예를 들어 Milind 교수님 본인은 학자 집안 출신에, 명문인 코넬 대학을 졸업하였고 현재는 역시 명문인 퍼듀 대학의 교수로 재직 중이다. 이렇게 요약된 정보만 본다면 탄탄대로, 승승장구의 인생이다. 많은 학생들은 이런 커리어를 보며 “나는 이미 시작부터 글러먹었네” 하며 좌절할것이다. 흔히들 말하는 가면 증후군(Imposter Syndrome)을 유발하는 스펙이다. 하지만 실상은 조금 달랐다고 한다. 대학원 시절, 4년간 논문 한편 없었고, 졸업 후에도 미국의 불경기로 인해 2년간 취업이 되지 않았다고 한다. 퍼듀 대학의 면접을 볼 수 있었던 것도 학회에서 만난 인연으로 간신히 기회를 얻은 것이었다. 임용된 이후에도 3년간 과제가 하나도 없었으며 12편의 제안서는 족족 다 떨어졌다고 한다. 우리가 얻을 수 있는 교훈은 무엇일까. 비교를 통해 좌절된다면 우리의 요약 알고리즘을 점검해봐야 한다, 정도가 되겠다.
PLMW 소회
벌써 세번째 참석한 멘토링 워크샵인데, 항상 많은 것을 얻어간다. 이번 PLMW는 특히나 학생들끼리의 교류가 많았고 교수님들의 강연도 유익했다. 일정을 마무리해갈 때 즈음 문든 든 생각은 나도 언젠가 이런 멘토링 워크샵을 준비해보고 싶다는 것이었다. 내 경험상 멘토링 워크샵은 다음 두 측면이 어우러질 때 가장 유익한 것 같다. 먼저 연구에 대한 관점을 배우고 고민할 수 있는 장기적인 측면의 도움이다. 교수님들의 진솔한 이야기가 담긴 다양한 발표들이 이런 측면에서 큰 도움이 된다. 그리고 당장 써먹을 수 있는 유용한 기술과 팁이다. 학생들끼리 교류할 수 있는 기회나 발표 잘하는 법, 논문 잘 쓰는 법은 단기적으로 즉각 도움이 된다. 언젠가 나에게 기회가 온다면 이 두 측면을 모두 충족시킬 수 있는 프로그램을 만들고 싶다.
자바스크립트, TC39, 그리고 Stage 2.7
PLMW의 강연 중 10분짜리 짧은 강연이 하나 있었다. 강사는 Mikhail Barash 교수님이었고, 자바스크립트 언어의 표준화 기구인 ECMA-TC39을 소개하는 내용이었다. 배경 설명을 좀 하자면 ECMA는 정보통신 시스템들을 위한 국제 표준화 기구이다. ECMA 산하에 여러 위원회(Task Committee)가 있는데 그 중 39번째 위원회인 TC39은 자바스크립트 언어의 표준화를 담당하고 있다. TC39 산하에도 5개의 그룹(Task Group)이 있는데, 그 중 5번째인 TG5는 표준화의 논의와 진행을 담당한다. 그리고 Mikhail 교수님은 TG5의 의장(Convenor)을 맡고 계시다.
ECMA-TC39에 대해서는 류석영 교수님의 ESMETA1와 그 선행 및 후속 연구들로 인해 몇번 들어보긴 했는데, 제대로 알게 된 것은 이번이 처음이었다. 우선 언어 하나가 성장하고 유지되는데 굉장히 많은 사람의 시간과 노력이 필요하다는 것을 알 수 있었다. 특히 자바스크립트 언어는 브라우저별로 엔진을 따로 개발하기 때문에 표준을 만들어나갈 때 브라우저를 개발하는 산업계의 의견도 굉장히 큰 (사실 제일 큰) 비중을 차지한다. 학계와 산업계가 어우러져 큰 협의체를 구성하고 언어의 발전을 위해 노력하는 모습이 인상적이었다.
자바스크립트 표준화의 이모저모
나중에 Mikhail 교수님께 따로 들은 얘기 중 언어의 표준화 과정에서 발생하는 일들이 특히 흥미로워 소개한다.
표준화 절차
우선 표준화 과정은 크게 6단계로 나뉜다. 더 자세한 내용은 TC39 공식문서를 참고하면 된다.
- Stage 0: 아이디어 단계. 아이디어가 있으면 누구나 TC39에 제출할 수 있다.
- Stage 1: 구상 단계. 위원회가 시간을 할애하여 아이디어를 검토하며 구현 방안 및 도입 시 잠재적 문제 등을 살펴본다.
- Stage 2: 구체화 단계. 어떤 방식으로 아이디어를 구현할 것인지 결정한 상태. 이제 보다 구체적인 디자인과 구현 방안을 논의한다.
- Stage 2.7: 테스팅 단계. 구현이 완료된 상태로, 스펙도 정의되었다. 예상치 못한 문제가 없는지 이제부터 테스트를 시작한다.
- Stage 3: 적용 단계. 제안된 아이디어 및 구현을 실제 구현체(브라우저 등에 내장된 엔진)에 적용하기를 제안한다.
- Stage 4: 완료 단계. 테스트를 모두 통과하는 구현체 2개 이상 등등의 조건을 만족한 상태.
의사 결정 과정
TC39의 의사 결정 과정은 만장일치제를 따른다. 각 단계를 넘어갈 때 마다 위원회가 모여서 논의하고 만장일치로 동의해야 다음 단계로 넘어갈 수 있다. 누군가가 반대한 경우는 매우 적었다고 하는데 (내 기억으로는 1-2 건) 시간이 지난 이후는 모두가 반대한 사람에게 고마워할 정도로 좋은 결정이었다고 한다. 위원회에 사람이 적지 않은데 만장일치제로도 일이 진행된다는 게 의외였다.
대기업의 횡포(?)
Stage 3의 설명과 Stage 4의 도달 조건을 보면 흥미로운 점이 있다. 여기서부터는 표준화 과정이 위원회의 손을 떠나는 것이다. 왜냐하면 Stage 3은 구현체에의 적용을 제안 하는 것이며, 브라우저 만드는 회사들(G사, A사, M사 등등…)이 이를 수용하지 않으면 말짱 꽝인 것이다. 그래서 사실은 기업들이 표준화 과정 최후의 수문장인 것이다. 따라서 자바스크립트의 경우 산업계로부터 외면받는 언어 요소는 구조적으로 표준화될 수 없다.
Stage 2.7, 너의 이름은
표준화 과정을 보면 뭔가 이상한게 중간에 있다. 그렇다. 2.7이라는 애매한 숫자가 보인다. Stage 2.7은 가장 최근에 도입된 단계로, Stage 2와 Stage 3 사이에 테스팅을 위한 단계가 필요해서 추가되었다. 그러면 왜 Stage 2.7이 되었을까? 예상외의 매우 긴 논의가 있었지만 간단하게 요약해보겠다. 전체 회의록도 공개되어 있으니 궁금한 사람은 확인해보시길.
- 우선 2와 3 사이에 추가하는 단계라서 그 사이의 숫자를 고르게 되었다.
- 하지만 굳이 따지자면 3단계에 더 가까운 단계라고 생각했기에 2.5보다는 큰 숫자를 주고 싶었다.
- 누가 자연상수 e 단계를 제안했다 (2.71…).
- 숫자로 된 단계의 통일감을 해치기에 소숫점 첫재 자리만 남긴 2.7이 되었다.
- 최종 결정이 된 이후, 누군가 2.62를 생각해냈고 모두가 아쉬워했다 (262는 자바스크립트 표준 문서에 붙은 번호라서 커뮤니티에게 의미있는 숫자다).
문제는 이 논의가 3시간이 걸렸다는 것이다. 테스팅을 위한 단계를 제안한 장본인, Michael Ficarra도 학회에서 만날 수 있었는데, 애초에 Michael은 이제 숫자를 떼고 자연어로 된 단계 이름을 쓰자고 주장했다고 한다. 그리고 저 논의가 이루어진 시간은 자신의 인생에서 가장 비참한 3시간이었다고 농담조로 말했다.
이 이야기의 교훈은 무엇일까? 커뮤니티가 크고 영향력이 큰 언어의 표준화 과정은 신중하고 보수적으로 진행될수밖에 없다는 것이다. 비록 저 3시간은 아까운 시간이었겠지만 TC39 위원회가 일관적으로 가지는 신중한 태도는 분명 지킬 가치가 있다고 생각한다.
다시보는 ESMETA
이전까지 류석영 교수님과 박지혁 교수님의 발표를 들을 때는 연구적인 부분에 집중하느라 실제 커뮤니티와 어떻게 협업하였는지는 흘려듣는 경우가 있었는데, 이번에 다시 돌아보는 기회가 되었다. 이 어렵고 까다로운 단계를 모두 거쳐서 자바스크립트 언어 표준의 일부가 된 ESMETA, 그리고 그 과정에 참여한 류석영 교수님과 박지혁 교수님이 더 존경스럽게 느껴졌다.
예? 2.7이요? |
흥미로웠던 발표들
컴파일러 세션
컴파일러 세션에서 연달아 발표된 두 논문이 매우 흥미로웠다.
논문 제목은 각각 Exploiting Undefined Behavior in C/C++ Programs for Optimization: A Study on the Performance Impact2 와
Relaxing Alias Analysis: Exploring the Unexplored Space3 이다 (발표 영상: 전자, 후자).
미정의 동작 (Undefined Behavior, UB)과 그놈이그놈 분석(Alias Analysis)은 컴파일러 최적화에서 중요한 역할을 한다.
우선 미정의 동작의 경우, 하드웨어 수준에서는 각자 마음대로 구현하되 컴파일러는 미정의된 동작이 일어나지 않는다고 가정하고 최적화를 진행한다.
그 결과 미정의 동작을 일일히 정의하는 것보다 더 폭넓은 최적화가 가능하다. 또한 그놈이그놈 분석을 통해 프로그램의 변수들 간의 관계를 분석하면,
서로 영향을 주는 포인터 변수를 파악할 수 있어 컴파일러가 보다 효율적인 최적화를 진행할 수 있다.
적어도 지금까지 사람들을 그렇게 믿어왔다. 하지만 위 두 논문은 각각의 믿음이 과연 옳은지에 대한 의문을 제기한다.
미정의 동작과 그놈이그놈 분석으로 인한 최적화 이득이 거의 없다는 것을 실험으로 보인 것이다.
기존의 믿음에 대한 도전이라 그런지 질문들도 상당했다. 보통 많아야 두세명인데, 그놈이그놈 분석에 대한 논문의 경우 약 10명의 질문자가 마이크 앞에 줄을 섰다.
이런 반항적이고 도전적인 연구는 항상 존경스러운 것 같다.
이전에 전민석 교수님이 발표한 논문인 Return of CFA: Call-Site Sensitivity Can Be Superior to Object Sensitivity Even for Object-Oriented Programs3 이 생각이 나기도 했다.
위협적으로 긴 질문 대기줄. 서 있는 사람들이 전부 질문 기회를 기다리고 있다. |
Program Synthesis From Partial Traces4 : 발표 영상
다른 연구실 동료들도 많이들 흥미롭게 느낀 논문이다.
1 저자인 Margarida가 아마존에서 인턴을 하며 진행한 연구인데, AWS 인스턴스 관리 인터페이스를 기반으로 한 프로그램 합성 연구이다.
직접 사용해본적은 없지만 AWS 인스턴스를 할당 받으면 그래픽 유저 인터페이스를 통해 이를 조작할 수 있다고 한다.
인스턴스를 종료하거나, 재시작하거나, 스크립트를 실행하거나 등등.
이러한 조작 기록들은 연속된 API 호출 기록의 형태로 남는데, 제목의 Trace는 이러한 API 호출 기록을 가리킨다.
일련의 API 호출 기록이 반복되는 경우, 사용자가 반복적으로 같은 목적을 가지고 여러번의 조작을 하고 있다는 것을 의미한다.
따라서 이 논문은 사용자의 편의성을 위해 반복된 API 호출 기록을 기반으로 사용자의 의도를 파악하고 이를 자동으로 수행하는 일종의 매크로를 합성하는 방법을 제안한다.
이 연구에서는 사용 가능한 API를 DSL로 표현하여 프로그램을 합성하였는데, 입력으로 주어진 API 호출 기록을 재현할 수 있는지를 기준으로 결과의 정확성을 평가했다.
자연스레 들었던 의문은 입력으로 주어진 API 호출 기록들이 모두 동일한 의도를 반영하는가였다.
질문해본 결과, 이 연구는 모든 입력이 같은 의도를 반영한다는 가정하에 진행되었다고 한다.
따라서 실생활에 적용하기 위해서는 이 가정을 어떻게 완화할 수 있을 지 고민해봐야 할 것 같다.
API 호출 기록을 사용자 의도 기반으로 잘 묶어내는 기술과, 입력에 노이즈가 섞여 있어도 강건하게 프로그램을 합성하는 기술이 모두 필요할 것 같다.
개인적으로는 아이폰에 있는 단축어(Shortcuts) 앱의 단축어를 자동으로 만들어서 추가해주면 좋겠다는 생각이 들었다.
직접 몇개 추가해본 경험이 있는데, 각 앱마다 사용 가능한 API가 달라서 단축어를 만들기가 쉽지 않았다.
Fast Direct Manipulation Programming with Patch-Reconciliation Correspondence5 : 발표 영상
이 논문은 패치가 적용될 때, 패치가 가져올 결과의 변화를 직접 기존 결과에 적용하여 추가 실행 없이 패치된 프로그램의 결과를 얻을 수 있는 기술을 제안한다.
이렇게만 말하면 꿈만 같은 기술이다. 퇴행 검사 (Regression Testing) 비용이 비싸다는 말은 이제 옛말이다.
아쉽지만 이 기술은 특수한 도메인에만 적용이 가능하다 (물론 여전히 유용한 기술이다).
이 연구에서 타겟으로 잡은 도메인은 방대한 데이터를 처리하는 시각화 프로그램이다 (예시).
이런 프로그램은 대개 사용자가 옵션을 선택하여 시각화 결과를 변경할 수 있다.
이 옵션의 조합은 쿼리의 형태로 표현되며 이 쿼리는 일종의 프로그램으로 볼 수 있다.
그렇다면 옵션이 바뀌는 것은? 기존 쿼리에 패치가 적용되는 것으로 볼 수 있다.
따라서 패치로 인한 쿼리의 구문(Syntax) 변화에 따른 의미(Semantic) 변화를 정의할 수 있다면 작은 의미 변화만을 기존 결과에 적용하여 전체 쿼리를 다시 처리하는 것보다 더 효율적으로 결과를 얻을 수 있다.
일반적인 프로그램에 이를 적용할 수 없는 이유는 구문 변화에 따른 의미 변화를 기존 결과에 직접 적용하기 어려운 경우가 많기 때문이다.
이 연구에서는 시각화 프로그램의 쿼리 언어에 대한 구문 변화와 의미 변화를 정의하고, 이를 기존 결과에 적용하는 방법을 제안했기 때문에 한정된 도메인에서 좋은 결과가 있었던 것 같다.
DR.FIX: Automatically Fixing Data Races at Industry Scale7 : 발표 영상
우버에서 진행한 자동 프로그램 수정 연구이다.
제목은 데이터레이스 오류를 잡는다곤 하지만 딱히 특정 오류 타입에 특화된 연구는 아니었다.
기존에 우리 연구실에서 창공님과 재호가 연구하던 패치 이식 연구와 유사하지만 좀 더 단순한 방식의 기술이었다.
먼저, 오류 코드와 해당 오류가 수정된 코드의 쌍을 데이터 베이스에 모은다.
그 후, 새로운 오류가 검출되면 데이터베이스에서 유사한 오류 코드를 찾는다 (이 때 코드를 벡터화 해서 비교한다).
마지막으로 기존 오류 코드, 수정된 코드, 새로운 오류 코드를 모두 LLM에게 던져주고 알아서 고치게 한다.
우선 LLM을 활용하는 방식이 너무 단순해서 아쉬웠다.
이 기법이 오류를 수정하지 못한 케이스 1위가 여러 파일에 걸친 수정이 필요한 경우라고 하는데, 기존 패치를 잘 요약해서 옯겨오는 기술이 없어서 그런 것 같다.
창공님과 재호의 방식은 오히려 여러 파일에 걸친 패치도 잘 했던 걸로 기억한다.
확실히 패치 및 오류 패턴을 요약하는 기술이 있으면 더 잘할 수 있을것이다.
기술적으로 아쉬운 점은 있었지만 예상치 못한 회사에서 이런 연구를 진행하고 있기에 나름 긍정적으로 생각했다.
홈그라운드에서 진행한 국제 학회
정말 감사하게도 지금까지 좋은 기회를 많이 얻어 이번이 벌써 여섯번째 국제 학회 참석이다. 그런데 이번에 유독 이전 학회와 큰 차이를 느낀 바가 있어 이야기를 해보고자 한다. 나는 그리 외향적이지 않은 사람으로써 한계를 극복하기 위해 네트워킹에 상당한 공을 들이고 나름 고민을 많이 한다. 그 결과 연구실에서 네트워킹을 주제로 실습을 곁들인 발표도 했으며 최근에는 이를 글로 정리하기도 했다. 하지만 정작 나도 항상 이론과 실재의 괴리를 느끼곤 했다. 일대일은 이제 어느정도 익숙해졌지만, 여러 사람이 모인 자리에서의 네트워킹은 여전히 어렵고 불편했다. 그런데 이번에는 그 어느 때보다도 네트워킹이 쉬웠고 적극적으로 지금까지 상상했던 모든 것을 시도해볼 수 있었다. 자연스럽게 사람들이 앉아 있는 식탁에 앉으며 대화에 참여했으며 여러 사람이 둘러서서 이야기하는 곳에도 가서 은근슬쩍 대화에 참여했다. 그 이유를 곰곰히 생각해본 결과 이번 학회가 국내에서 진행되었기 때문이라는 결론에 도달했다.
소속감이 주는 자신감
국내에서 진행되는 학회는 어떤 차이가 있을까? 우선 자연스러운 소속감(Sense of belonging)을 느낀다. 좀 더 풀어서 말하자면, 마땅히 이 자리에 있어도 될 자격을 얻은 것 같은 느낌이다. 좀 과장해서 비유하자면 마치 미국 영화에 나오는 파티의 주최자가 자연스럽게 돌아다니며 파티 참가자들에게 말을 걸고 인사를 하는 것과 비슷하다. 이런 소속감은 내가 이 학회에 참석할 자격이 있다고 느끼게 해준다. 이전까지는 무의식적으로 내 자격에 대해 의구심을 가지고 있었던 것 같다. 이런 의구심은 나를 위축시키고, 네트워킹을 시도하는데 방해가 되었다. 이번 여행기를 준비하다가 고려대학교의 오학주 교수님이 작성하신 2012년 PLDI 여행기를 읽게 되었는데, 아래와 같은 문구에서 비슷한 심경을 읽어낼 수 있었다.
거의 대부분의 논문을 미국대학에서 발표했기 때문에 마치 미국인들만의 잔치에 구경을 왔다는 인상을 받았다
모두에게 소속감을
소속감을 느껴보기 전까지는 나에게 부족한 것이 무엇이었는지조차 몰랐다. 그리고 문득 깨달은 바가 있어 이 또한 이야기를 해보고자 한다. 사실 이전까지는 커뮤니티 내의 소수자들에 대한 다양한 지원의 필요성을 크게 느끼지도, 공감하지도 못했다. 예를 들어 소수자들을 위한 점심식사 등. 그러나 이제는 이런 지원들이 소수자 구성원들에게 소속감을 느끼게 해주고, 그로 인해 자신감을 줄 수 있겠다는 생각이 든다. 개인적인 생각으로 SE 학회들처럼 진취적으로 분야 불모지에 찾아가서 학회를 개최하는 것도 좋고, 소수자들이 커뮤니티 내에서 주도적인 역할을 맡게 하는 것이 소속감과 참여의 당위성을 느끼게 해주는 좋은 방법이라고 생각한다.
감사의 말씀
PLDI가 한국에서 열릴 수 있도록 수고해주신 허충길 교수님, 김지응 교수님, 그리고 다른 많은 분들께 감사의 말씀을 드린다.
잡다한 이야기
경복궁 러닝
요즘 러닝에 취미를 들여서 서울에 올라간 김에 경복궁을 돌았다. 누가 말하길 우리 조상들이 후손 러너들을 위해 경복궁 한바퀴를 2.5km의 적당한 업힐-다운힐 코스로 설계했다고 한다. 내 수준으로는 두 바퀴가 적당한 운동이었다. 거리는 적당했으나 내 수준으로는 적당한 업힐이 아니었다. 상당히 가파르다…
광화문 전경 |
5km 러닝 |
선방하는 한국
우리나라는 이번에 압도적 참가자 수 1위를 차지했다. 원래 어디에서 개최하던 미국과 중국이 압도적 참가자 수를 기록했는데, 놀랍게도 한국이 1위를 차지했다.
참가자 수 1위! |
환상적인 음식
학회 기간 내내 음식이 정말 맛있었다. 듣기로는 참가비가 거의 식비로 나갔다고 한다 (믿거나 말거나). 넉넉한 한국의 인심을 세계에 알리는 좋은 기회가 되었다.
점심 1 |
점심 2 |
뱅큇 코스 요리의 에피타이저. 이후는 너무 맛있게 먹느라 사진을 못 찍었다. |
돌아오며
연구실 구성원 모두가 함께 할 수 있는 학회였기에 더 특별했던 것 같다. 이번 학회 출장이 가능할 수 있도록 훌륭한 논문을 내주신 교수님과 재성이, 그리고 특히 발표로 수고한 봉준님께 감사드린다. 아낌없이 예산을 지원해주신 교수님께 다시 감사드린다. 지원해주신 덕분에 정말 귀하고 소중한 기회를 얻을 수 있었고, 그 기회를 통해 많은 것을 배우고 느낄 수 있었다.
각주
[1] Sukyoung Ryu and Jihyeok Park, “JavaScript Language Design and Implementation in Tandem” CACM (2024)
[2] Lucian Popescu and Nuno P. Lopes, “Exploiting Undefined Behavior in C/C++ Programs for Optimization: A Study on the Performance Impact” PLDI (2025)
[3] Michel Weber et al., “Relaxing Alias Analysis: Exploring the Unexplored Space” PLDI (2025)
[4] Minseok Jeon and Hakjoo Oh, “Return of CFA: Call-Site Sensitivity Can Be Superior to Object Sensitivity Even for Object-Oriented Programs” POPL (2022)
[5] Margarida Ferreira et al., “Program Synthesis From Partial Traces” PLDI (2025)
[6] Parker Ziegler et al., “Fast Direct Manipulation Programming with Patch-Reconciliation Correspondence” PLDI (2025)
[7] Farnaz Behrang et al., “DR.FIX: Automatically Fixing Data Races at Industry Scale” PLDI (2025) \