14 minute read

리스본의 랜드마크인 벨렝 타워 앞에서 단체 사진. 왼쪽부터 나, 재성이, 그리고 허기홍 교수님.



들어가며

명실상부한 세계 최고 권위의 소프트웨어 공학 학회인 ICSE에 다녀왔다. 이번 출장이 가능했던 것은 나의 석사 동기인 승완님이 1 저자로 참여한 논문이 ICSE 2024에 받아들여졌기 때문이다. 승완님은 졸업생이라 발표는 2 저자로 참여한 재성이가 대표로 준비하였다. 나는 비록 논문은 없었지만 감사하게도 출장의 기회가 주어져 소프트웨어 공학 학회를 경험하러, 최신 학계 동향을 파악하러, 그리고 재성이의 발표를 응원하러 포르투갈 리스본으로 떠났다.



ICSE에 대한 전체적인 인상

운이 좋아 벌써 네 번째로 참석하는 해외 학회이지만 ICSE는 처음이었다. 또한 지금까지 보안과 프로그래밍 언어 학회만 참석해왔기 때문에 소프트웨어 공학 학회도 처음이었다. 우선 가장 크게 다가온 특징은 굉장히 모두를 환영하는 분위기라는 것이었다. 매우 포용적인 분위기였고, 새로운 사람들과 학생들에 대한 격려가 넘치는 곳이었다. 특히 멘토링 워크숍을 참석하면서 이를 많이 느낄 수 있었는데, 이후에 더 자세히 설명하도록 하겠다.

두번째 특징은 굉장히 다양한 연구를 한다는 것이었다. 보안 학회에서도 비슷한 점을 느꼈지만, 보안 학회는 기술적으로 다양한 연구를 한다는 느낌이 더 강한 반면, ICSE에서는 더 큰 단위의 분야에서의 다양성을 많이 느꼈다. 우리 연구실에서 발표한 컴파일러 최적화 검증처럼 굉장히 기술적인 연구도 있었지만, 사람을 연구하는 사회과학적인 연구도, 교육학적인 연구도 많았다. 그래서 생각보다 연구적 관심이 일치하는 연구를 찾기가 어렵기도 했다.



멘토링 워크숍

PL(PLDI/POPL/ICFP/OOPSLA)과 SE(ICSE) 학회에는 각각 PLMW(Program Language Mentoring Workshop)와 SMeW(Student Mentoring Workshop)이라 불리는 멘토링 워크숍이 있다. 나는 20년도 온라인 SMeW, 23년도 PLMW@PLDI와 이번 24년도 SMeW에 참석했는데, 단언컨대 이번 SMeW가 가장 좋은 경험으로 남았다. 우선 이번 워크숍 위원회 구성원들이 굉장히 헌신적이며 열정적이었다. 참여하는 학생들에게 실용적인 도움을 최대한 많이 주고 싶어하는 마음이 느껴졌다. 워크숍의 구성은 크게 네트워킹에 대한 발표 및 QnA, 1대 다 멘토링, 1대 1 멘토링, 그리고 패널 QnA로 이루어졌다.

1. 네트워킹

학회에서 가장 중요한 것 중 하나는 다양한 연구자들과 교류하며 친분을 다지는 것이다. 흔히들 네트워킹이라고 부르는 이 활동은 중요한 동시에 대부분의 (특히 영어가 모국어가 아닌) 학생들이 어려워하는 활동이기도 하다. 그러다 보니 이번 워크숍에서는 90분짜리 세션을 통으로 할당해 네트워킹을 다루었다. 먼저 강의로 시작했는데, 일방적인 강의였다면 지루했겠지만 굉장히 실용적인 강의라 재미있게 들을 수 있었다. 예를 들어 중간 중간 위원회 구성원 교수님들이 나와서 짤막하게 상황극도 하시고, 다양한 예시를 통해 대화에 끼어들어도 되는 상황과 그럴 때 쓸만한 멘트를 알려주기도 했다. 가끔 뻔한 예시들도 있었지만 (둘이 노트북을 보면서 심각하게 대화 중이면 그냥 지나쳐야 한다 등) 학생들을 위해 고심한 흔적이 느껴져 고마울 따름이었다. 또한 강의 후에는 엘리베이터 스피치라고도 하는 30초짜리 자기소개를 즉석에서 만들어서 발표해보는 시간도 있었는데, 10명 정도의 학생들이 자원했었다. 나는 쑥스러워서 가만히 있었는데 조금 후회되었다. 그 후 약 10분 동안 주변의 3인을 한 조로 묶어 네트워킹을 연습해보고 이번 학회에서 네트워킹 목표를 정해보는 시간도 가졌다. 마침 옆에 앉은 재성이와 브라질에서 온 친구 한 명과 함께 한 조가 되어 네트워킹을 연습해보았다.

2. 1대 다 멘토링

또 하나의 세션은 1대 다 멘토링 세션이었다. 약 15명 정도 되는 멘토들이 연구 주제보다는 각자의 배경과 경험을 위주로 스스로를 소개하고, 그 후 학생들이 자유롭게 조언을 구하고 싶은 멘토를 찾아가 시간을 보내는 세션이었다. 그리고 정해진 시간마다 다른 멘토로 이동하여 총 3명의 멘토와 이야기를 해볼 수 있었다. 우선 학생들과 이야기를 나누기 위해 기꺼이 시간을 내어준 멘토들이 이렇게 많다는 것이 놀라웠다. 나는 최근 임용 위원회 업무를 맡았기에 수백 편의 지원서를 읽어봤다는 Purdue 대학의 James Davis 교수님, 발표와 글쓰기 등 소통의 중요성을 강조하는 University of Hawai‘i at Mānoa의 Rick Kazman 교수님, 그리고 소프트웨어 공학 분야의 원로이자 유신 교수님의 지도 교수님인 Mark Harman 교수님과 이야기를 나누었다.

2.1. James Davis 교수님

많은 학생들이 교수직에 관심이 있었던 것 같다. 그래서 교수로 임용되려면 어떤 자격을 갖춰야 하는지 물어보는 학생들이 많았다. 유용했던 조언을 세 가지 떠올려 보자면 다음과 같다. 첫 번째, 협력, 혹은 지도 경험이 필요하다. 따라서 의외로 1 저자 논문만 많은 사람은 이런 경험이 부족한 것으로 여겨질 수 있다고 한다. 두 번째, 자신의 연구 주제에 대한 큰 그림을 그릴 수 있어야 한다. 이것은 허기홍 교수님이 항상 말씀하시는 것과 일맥상통한다. 세 번째, 어느 정도 다양한 주제를 연구하는 것이 유리할 수 있다. 각 학교마다 원하는 포지션이 미묘하게 다른데, 최대한 많은 학교에 지원하려면 해당 학교에서 원하는 주제와의 연관성을 보여주는 것이 중요하다.

2.2. Rick Kazman 교수님

모든 내용이 우리 연구실에서 강조하는 바와 동일했다. 발표의 중요성, 연습의 중요성, 그리고 어떤 발표가 좋은 발표인지는 만국 공통인가보다.

2.3. Mark Harman 교수님

Mark Harman 교수님은 모든 질문에 대한 답이 준비되어 있는 현자와 같았다. 특별한 주제 없이 학생들이 빙 둘러앉아 하나씩 고민을 말하면 그에 대한 의견을 즉석에서 말했는데, 지켜보는 것만으로도 재미있었다. 사실 나는 특별히 궁금한 게 있다기보다는 단지 유신 교수님의 지도교수님이 어떤 분일까 궁금해서 찾아갔던 터라 만족스러운 경험이었다.

3. 1대 1 멘토링

1 대 1 멘토링은 따로 시간이 정해진 세션은 아니었고, 번외 프로그램에 가까웠다. 멘토링 워크숍에 참석한 모든 학생은 개인 멘토가 한 명씩 배정되었고, 이번 학회 기간 동안 멘토와 약 30분 정도의 멘토링 시간을 가질 수 있었다. 여기서 나는 또 이렇게 많은 멘토들이 학생들을 위해 시간을 내주는 것이 놀라웠고 감동을 받았다. 나에게 배정된 멘토는 Chinese University of Hong Kong의 Pinjia He 교수님이었다. Pinjia 교수님과는 멘토링 워크숍 당일 점심시간에 약속을 잡아 점심을 함께 먹으며 이야기를 나누었다. Pinjia 교수님은 신임 교원이셨는데, 마침 같은 날, ICSE 신임 교원 워크숍도 있어서 각각 멘토링 워크숍 비슷한 것에 참석하고 있다는 동질감을 느낄 수 있었다. 여기 다 쓸 수는 없지만 우리는 점심을 함께 억으며 나의 이런 저런 고민들과 그에 대한 Pinjia 교수님의 경험과 의견을 주고 받았다. 30분의 대화 이후에도 학회 기간 내내 Pinjia 교수님과는 여러 차례 마주쳤는데, 그때마다 서로 반갑게 인사를 하였고 다음에 만난다면 서로 안부를 물어볼 수 있을 것이다. 이렇게 친절한 멘토와 30분 동안 이야기를 나눌 수 있는 것은 매우 소중한 경험이었다. 아무리 학회장을 돌아다녀도 기꺼이 누군가의 고민을 들어주고, 그에 대한 자신의 이야기를 나눠줄 사람은 찾기 어렵기 때문이다.

4. 패널 QnA

마지막으로 멘토링 워크숍의 마무리를 장식하는 패널 QnA가 있었다. 준비된 패널들이 즉석에서 질문들에 대한 답을 하는 순서였는데 기억에 남는 점은 패널 석에 빈자리가 하나 있어 누구든 올라와서 의견을 말할 수 있다는 것이었다. 확실히 ICSE는 탈권위적이고 다양한 의견에 열려있는 곳이라고 느꼈다. 가장 기억에 남는 것은 영어 발표가 너무 어렵다는 질문이었다. 질문 자체는 특별할 것이 없는 질문이었지만 너무 현실적이고 유용한 답변이 있었기에 여기 공유하고자 한다.

  • Q. 영어로 발표는 어떻게든 하겠는데, 질의응답이 걱정된다.

  • A1. 우선 세션 체어에게 상황을 알리고 도움을 요청한다. 질문을 다시 정리해서 알려주는 방식으로 도움을 줄 것이다.
  • A2. (중요) 미리 그럴싸한 질문과 답을 몇개 준비해놓고, 질문을 이해하지 못한 경우 그 중 아무 답변이나 시작하라. 그러다 제한시간이 다 되면 나중에 따로 얘기하자고 하면 된다. 아무 말도 못하고 버벅거리는 것보다는 낫다.

결론

결론적으로 이번 멘토링 워크숍은 매우 유익했고, 나에게 많은 도움이 되었다. ICSE의 멘토링 워크숍을 모두에게 강력하게 추천한다.

SMeW 단체사진



사람들

이번 ICSE에서 만난 사람들에 대해 얘기해보고자 한다. 비록 멘토링 워크숍에서 네트워킹의 비법을 전수받았지만 여전히 아무나 잡고 얘기하는 것은 너무 어려운 일이었다. 다만 다시 만난 반가운 몇몇 얼굴들과, 너무 만나보고 싶었던 사람들에게는 용기를 내어 다가가 보았다.

다시 만난 얼굴들

먼저 첫 해외 출장에서 만난 Mukund Raghothaman 교수님을 이번에 다시 만났다. 비록 2년 전이지만 모두 외국에서 만나서 그런지 얼마 지나지 않은 것처럼 느껴졌다. 허기홍 교수님의 포닥 시절 동료시다 보니 학문적으로 삼촌 정도의 느낌이 들어 더 반가운 만남이었다. 또한 작년 PLDI에서 만난 Yaniv David도 다시 만날 수 있었다. 그 당시 PLDI에서 ASA (AI and Static Analysis) 워크숍에서 허기홍 교수님과 함께 발표자를 한 계기로 알게 되었고 점심을 먹으며 이야기를 나눈 적이 있었다. 이번에는 둘째 날 저녁 뱅큇에서 함께 어울리며 더 친해질 수 있었다. 처음 해외 학회에 참석했을 때는 아는 사람 하나 없어 주눅들고 어색했는데, 이제는 하나둘씩 반가운 얼굴들이 늘어나는 것이 느껴져 감개무량했다.

만난 적은 없지만 내적 친밀감을 느끼던 사람들

이번 학회에서 가장 만나고 싶은 사람이 있었는데 바로 MPI-SP 연구소의 Marcel Böhme 박사님이었다. Marcel은 2017년, AFLGo 논문을 통해 내가 현재 연구하는 지향성 퍼징의 포문을 열었다. 그리고 AFLGo는 지금까지도 가장 잘 공개되고 유지보수되고 있는 지향성 퍼징 도구이다. 그 까닭은 Marcel의 홈페이지에 명시된 소프트웨어 공학에서의 재현성 선언 때문이라고 생각한다. 아이러니하게도 그 이후에 AFLGo를 기반으로 구현된 몇몇 논문들은 정작 자신들의 코드를 공개하지 않았지만 나는 허기홍 교수님의 가르침과 재현성 선언의 정신을 이어받아 최선을 다해 모든 코드와 실험 환경을 공개하였다. 그런 점에서 Marcel을 만나 내가 연구하는 분야를 시작해줘서 고맙다는 인사를 전하고 싶었고, 도구를 공개해주어 고맙고 리스펙한다는 말도 전하고 싶었다. 다행히 잠시 이야기를 나눌 기회가 있었는데 기쁘게도, 그리고 무섭게도 Marcel은 내 논문 DAFL을 알고 있었다. 학계가 참 좁다는 생각을 새삼 하면서 다음에는 더 멋진 연구로 내 자신을 소개할 수 있도록 노력해야겠다는 다짐을 하였다. 또 다른 친밀감을 느끼던 사람은 CISPA의 Andreas Zeller 교수님이었다. Andreas 교수님의 논문들보다는 블로그의 글을 더 많이 읽었는데 그러다 보니 좀 더 개인적인 친밀감을 느꼈던 것 같다. 이번에 학회장에서 실제로 볼 수 있었지만 특별히 할 말이 없어 그저 먼 발치에서 바라보기만 했다. 워냑 유명인이시다 보니 직접 본 것만으로도 만족스러웠다.



기억에 남는 발표들

퍼징 연구들

FuzzSlice: Pruning False Positives in Static Analysis Warnings through Function-Level Fuzzing1
제목이 모든 것을 설명하는, 즉 제목을 깔끔하게 잘 지은 논문이다. 정적 분석 도구는 보통 모든 가능성을 고려하여 잠재적 결함을 보고하기 때문에 다수의 오탐이 발생할 수 있다. 즉, 실제 결함이 아닌데도 잠재적인 결함으로 보고되는 경우가 많다는 것이다. 따라서 그 중 어떤 것이 정말 결함(정탐)인지 확인하기 위해 퍼징 등을 활용하여 실제로 결함을 발생시키는 입력을 찾기도 한다. 이 논문은 해당 방법이 너무 비효율적이며 깊은 지점에 존재하는 결함은 찾기 어렵다는 문제에 착안했다. 따라서 결함 의심 지점이 포함된 함수 단위로만 퍼징이 가능하도록 프로그램을 변형하고 5분간 퍼징을 시도한 후, 결함이 발견되지 않으면 오탐으로 판단하는 방법을 제안했다.

개인적으로는 이 논문을 쉽게 받아들이기 힘들었다. 모두가 아는 다익스트라의 명언인 “Program testing can be used to show the presence of bugs, but never to show their absence”처럼 어째서 단순히 5분간 결함이 발생하지 않았다고 오탐으로 판단하는 것이 타당한지 이해하기 어려웠다. 물론 실험적으로는 정확도가 꽤 높은 것으로 나왔지만 개념적으로 잘 와닿지 않았다. 저자들도 이것이 개념적으로 새로운 접근인 것을 알고 있는지 논문에도 기여하는 바 중 하나를 “Conceptual Innovation”으로 표현했다. 다만 아쉬운 점은 논문이나 발표가 이런 궁금증을 시원하게 긁어주지 못했다는 것이다. 예를 들어 5분 안에 퍼저가 탐색할 수 있는 공간과, 실험 대상 프로그램의 일반적인 함수의 탐색 공간을 예제를 통해 비교해줬으면 좀 더 이해가 쉬웠을 것이다. 이전에 MC^22 논문에 대해서도 비슷한 생각을 했었는데, 개념적으로 이전과 획기적으로 다른 방법이 사람들에게 쉽게 받아들여지려면 의구심이 드는 포인트를 잘 파악해서 정확하게 긁어주는 것이 중요한 것 같다. 어쩌면 Curse of Knowledge 개념의 연장선에 있는 것일지도 모르겠다. 연구자 당사자에게는 이제 너무 익숙해져서 당연한 개념이지만 듣는 사람에게는 새로운 개념일 수 있기 때문이다.

EDEFuzz: A Web API Fuzzer for Excessive Data Exposures3
이 논문은 과유불급 데이터 노출(Excessive Data Exposures) 문제를 해결하기 위한 퍼징 기법을 제안했다. 가끔 웹 페이지에서 실제로 사용하지도 않을 데이터를 요청하여 받아오는 경우가 있는데, 이런 데이터가 공격자에게 노출되면 보안 문제가 발생할 수 있다고 한다. 따라서 JSON으로 되어 있는 웹 API의 설정 파일을 퍼징하여 웹 페이지가 요청하는 데이터를 임의로 누락시키고, 그 중 결과적으로 생성되는 웹 페이지에는 영향을 주지 않는 데이터를 찾아내는 방법을 제안했다. 이 논문은 최우수논문상을 받았다. 발표도 인상적이었는데, 실제로 호주에서 국무총리(혹은 비슷한 고위 공무원)의 개인 정보가 노출되었던 사례를 들어 이 문제를 설명하고 그 심각성을 강조했다. 덕분에 어떤 문제인지 한 번에 파악할 수 있었고 이후 발표의 내용을 잘 따라갈 수 있었다. 킬러 예제를 매우 잘 사용한 발표였다.

Extrapolating Coverage Rate in Greybox Fuzzing4
이성민 박사님의 논문이었다. 지난 1월에 친히 카이스트까지 오셔서 발표해주신 논문이었는데, 두 번째로 들으니 더 잘 이해가 되었다. 퍼징을 하다 보면 언제까지 돌려야 하는지, 앞으로 더 새로운 커버리지가 달성될 수 있는지 등 다양한 의문이 생긴다. 이때 불투명(blackbox) 퍼징의 경우, 퍼징 과정 내내 생성되는 입력의 분포가 동일하기 때문에 통계적인 방법으로 앞으로의 커버리지 양상을 예측할 수 있다고 한다. 사실 지식이 부족하여 통계적으로 이게 어떻게 가능한지는 모르겠으나 그렇다고 한다. 그런데 불투명 퍼징보다 더 보편적으로 쓰이는 반투명(greybox) 퍼징의 경우, 새로운 커버리지가 발견될 때마다 생성되는 입력의 분포가 다르기 때문에 앞으로의 양상을 예측하기 어렵다. 따라서 이 논문에서는 반투명 퍼징의 기록 중 일부를 이용하여 그에 상응하는 불투명 퍼징의 기록으로 변환하고, 이를 기반으로 앞으로의 커버리지 양상을 예측하는 방법을 제안했다. 사실 반투명 퍼징도 새로운 커버리지 발견의 시점과 시점 사이에는, 즉 새로운 정보가 주어지지 않는 동안에는 불투명 퍼징과 같은 특성을 가지기 때문에 이런 방법이 가능한 것이라고 한다. 도구가 잘 나온다면 연구할 때도 파일럿 스터디를 할 때 더 효율적인 실험 자원 배분이 가능할 것 같다.

Mind the Gap: What Working With Developers on Fuzz Tests Taught Us About Coverage Gaps5
SEIP 트랙의 논문이었는데 (Mozilla), 재미있게도 퍼징으로 찾은 입력을 통해 기능 테스트를 만드는 방법을 제안했다. 퍼징의 주 목적은 커버리지 향상이라서 생성되는 입력의 내용적인 가치는 크게 없는 것이 일반적이다. 그러나 이 논문은 기존에 커버되지 않은 프로그램 지점에 도달하는 입력을 퍼징으로 발견한 경우, 개발자가 이를 기능 테스트로 활용할 수 있도록 도와주는 방법을 제안했다. 물론 이것이 가능했던 이유는 대상 프로그램이 웹 브라우저였고, 대상 입력은 html 파일로서 그 자체가 하나의 입력이자 테스트였기 때문이다. 따라서 개발자는 새로운 커버리지를 발생시킨 입력을 가져다 태그를 몇개 더 달아줌으로써 이를 원하는 방향으로 확장하여 손쉽게 기능 테스트로 활용할 수 있었다. 모든 경우에 적용 가능한 방법은 아니겠으나 재미있는 접근이었다.

그 외

Automated Program Repair, What Is It Good For? Not Absolutely Nothing!6
처음에는 독해를 잘못해서 자동 프로그램 수정이 아무 쓰잘데기 없다는 논문인 줄 알았는데, 알고 보니 그 반대였던 논문이다. 과연 자동 프로그램 수정 도구가 쓸모가 있는지 조사한 논문이었다. 이 논문에서는 실험 대상자를 다음과 같이 네 집단으로 나누어 각 결함당 30분씩 주어 디버깅을 시켰다.

  • 첫 번째 집단: 개발자의 패치 제공
  • 두 번째 집단: 자동 프로그램 수정 도구가 생성한 올바른 패치 제공
  • 세 번째 집단: 자동 프로그램 수정 도구가 생성한 잘못된 패치 제공
  • 네 번째 집단: 아무 패치도 제공하지 않음

결과는 다음과 같았다.

  • 디버깅 성공률: 첫 번째와 두 번째는 비슷한 성공률을 보였지만, 잘못된 패치의 경우 오히려 아무 패치도 제공하지 않은 경우보다 성공률이 낮았다. 즉 방해가 된 것이다.
  • 디버깅 시간: 마찬가지로 첫 번째와 두 번째는 비슷한 시간이 소요되었고 디버깅 시간의 경우 잘못된 패치와 아무 패치도 제공하지 않은 경우도 서로 비슷한 시간이 걸렸다. 논문의 결론은 자동 프로그램 수정 도구가 올바른 패치를 제공할 때는 매우 유용하다는 것이었다.

하지만… 내가 알기로 자동 프로그램 수정 도구는 아직 잘못된 패치를 생성하는 경우가 더 많다. 그렇기에 과연 현재 시점에서 이런 결론을 내려도 되는 것인가 하는 의문이 남는다.

사실 비슷한 문제가 정적 분석 도구에서도 발생한다. 오탐이 너무 많은 것이 문제인데, 요즘은 그 중 정탐을 가려내기 위해 지향성 퍼징등 다양한 연구가 진행되고 있다. 따라서 자동 프로그램 수정 기술을 위해서도 올바른 패치를 확실하게 드러낼 수 있는 기술이 필요한 것으로 보인다.

RogueOne: Detecting Rogue Updates via Differential Data-flow Analysis Using Trust Domains7
Yaniv의 논문이다. 라이브러리 프로그램들은 서로 얽히고설킨 의존 관계를 가지고 있어 하나를 설치하면 수많은 라이브러리가 딸려 오는 경우가 많다. 그런데 이 중 하나라도 악성 코드가 포함되어 있으면 전체 프로그램이 위협에 노출될 수 있다. 문제는 애초에 라이브러리 자체가 악성인 경우도 있지만, 정상적인 오픈 소스 라이브러리에 누군가 잘 위장된 악성 코드를 삽입하는 경우도 있다. 이렇게 악성 코드가 포함된 업데이트를 Rogue Update라고 부르는데, 이를 탐지하는 방법을 제안한 논문이다. 이 논문에서 제안하는 도구인 RogueOne은 우선 각 라이브러리 내의 신뢰 도메인을 파악한다. 신뢰 도메인은 아주 간단히 말해 같은 개발자가 구현하였으며 상호작용하도록 만들어진 단위라고 생각할 수 있다. 이후 RogueOne은 라이브러리의 업데이트로 인해 서로 다른 신뢰 도메인 사이의 데이터 흐름이 생성되었는지를 검사한다. 왜냐하면 어느 정도 성숙한 라이브러리 프로그램에서는 이런 종류의 업데이트가 일어나지 않는다고 하기 때문이다. 안 그래도 최근 xz 라이브러리의 악성 코드 삽입 사건이 발생하였다. 아쉽게도 논문 작성 시점 이후에 발생한 사건이라 논문에서 xz 재현 실험을 보여주지는 못했지만, 매우 시의적절한 발표용 킬러 예제가 알아서 찾아와준 사례라고 할 수 있겠다.



잡다한 이야기

재성이의 발표

석사 3학기째에 세계 최고 수준의 소프트웨어 공학 학회에서 세계 최고 수준의 연구를 세계 최고 수준으로 발표하는 것은 어떤 느낌일까? 이번 ICSE에서는 재성이가 그런 경험을 했다. 단 15분을 위해 정말 오랜 기간동안 발표 자료를 준비했으며 지켜본 바로는 연습도 많이 했다. 덕분에 내용이 잘 전달되어 질문도 많았고, 많은 질문에 답변도 정확하게 잘 했다.

열정적인 발표

멋진 학회장

이번 ICSE는 굉장히 멋진 학회장에서 열렸다. Centro Cultural de Belém이라는 곳이었는데, 강가에 위치하였으며 주변에 다양한 랜드마크가 있는 아름다운 장소였다. 숙소가 좀 멀었지만 매일 학회장에 갈 맛이 났다.

웅장한 학회장 외부
마치 오페라 극장 같은 학회장 내부

굿즈 전문 ICSE

ICSE는 유독 굿즈가 많았다. 에코백도 있었고 물병도 나눠줘서 학회 기간 동안 잘 썼다. 로고도 잘 만들어서 여기저기 다 박아 넣었는데, 굉장히 잘 준비한 학회라는 인상을 주는 효과가 있었다.

ICSE 굿즈
ICSE 플래카드
ICSE 깃발
ICSE 입간판
ICSE 포토존
ICSE 팔찌 및 식권

광란의 뱅큇

둘째 날 저녁, 뱅큇은 충격이었다. 긴 줄을 서서 놀이공원 팔찌 같은 것을 보여주고 입장한 공간에는 현란한 조명과 디제이, 그리고 드라이아이스가 있었다. 역시 ICSE는 인싸들의 학회인 것 같다.

광란의 파티 현장
밴드의 라이브 공연
Yaniv와 단체사진

에그 타르트

모두가 입을 모아 말하던 에그 타르트. 직접 먹어 보았는데, 명불허전. 정말 맛있었다. 리스본의 갓 구워 나온 에그타르트는 황금색의 부드러운 행복 그 자체였다.

달콤한 즐거움

배탈

셋째날 저녁으로는 해산물을 먹었는데, 몸에 안 받았는지 그날 밤부터 몸이 아프기 시작했다 (그래도 먹을 때는 맛있었다). 해산물을 소화하지는 못했어도 다행히 대부분의 학회 일정은 모두 소화한 이후라 출장의 목적은 달성했지만 마지막 날 하루를 꼬박 침대에서 보냈고 귀국하기까지 한 끼도 먹을 수 없었다. 이번에는 시차 적응도 매우 잘해서 이제 슬슬 해외 출장이 익숙하다는 발칙한 생각을 하던 차였는데, 이렇게 예상치 못한 일이 생겨 항상 조심해야겠다는 생각이 들었다.

나를 아프게 하는 것들

리스본의 특산물

돌아오는 길에 공항에서 찰리와 초콜릿 공장의 초콜릿 가게가 연상되는 휘황찬란한 가게를 발견했다. 무엇을 파는 곳인고 가까이 가서 살펴보니, 예상외로 정어리 통조림을 파는 가게였다. 리스본은 정어리가 유명해서 이번 ICSE 로고에도 정어리가 들어있는데, 이렇게 화려한 가게에서 예쁘게 포장된 정어리 통조림을 파는 것까지는 예상하지 못했다.

찰리와 정어리 통조림 공장



돌아오며

감사한 기회로 ICSE 2024에 참석하여 다양한 사람들을 만나도 다양한 연구를 접하고 왔다. 보고 듣고 느낀 것을 잘 소화하여 내 연구에 활용하면 금상첨화일 것이다. 이번 출장이 가능할 수 있도록 훌륭한 발표를 해준 재성이, 기회를 주신 허기홍 교수님, 준비를 도와주신 나은진 선생님께 감사드린다. 여행기를 읽는 누군가에게 재미 혹은 도움이 되길 바라며 글을 마친다.








각주

[1] Aniruddhan Murali et al. “FuzzSlice: Pruning False Positives in Static Analysis Warnings through Function-Level Fuzzing” ICSE (2024)
[2] Shah, Abhishek, et al. “MC2: Rigorous and Efficient Directed Greybox Fuzzing.” CCS (2022)
[3] Lianglu Pan et al. “EDEFuzz: A Web API Fuzzer for Excessive Data Exposures” ICSE (2024)
[4] Danushka Liyanage et al. “Extrapolating Coverage Rate in Greybox Fuzzing” ICSE (2024)
[5] Carolin Brandt et al. “Mind the Gap: What Working With Developers on Fuzz Tests Taught Us About Coverage Gaps” ICSE-SEIP (2024)
[6] Hadeel Eladawy et al. “Automated Program Repair, What Is It Good For? Not Absolutely Nothing!” ICSE (2024)
[7] Raphael J. Sofaer et al. “RogueOne: Detecting Rogue Updates via Differential Data-flow Analysis Using Trust Domains” ICSE (2024) \