<?xml version="1.0" encoding="utf-8"?><feed xmlns="http://www.w3.org/2005/Atom" ><generator uri="https://jekyllrb.com/" version="3.10.0">Jekyll</generator><link href="http://prosys.kaist.ac.kr/feed.xml" rel="self" type="application/atom+xml" /><link href="http://prosys.kaist.ac.kr/" rel="alternate" type="text/html" /><updated>2026-04-16T04:42:53+00:00</updated><id>http://prosys.kaist.ac.kr/feed.xml</id><title type="html">Prosys Lab @ KAIST</title><subtitle>Write an awesome description for your new site here. You can edit this line in _config.yml. It will appear in your document head meta (for Google search results) and in your feed.xml site description.</subtitle><author><name>Prosys Lab</name></author><entry><title type="html">PL 연구자가 바라본 MobiCom</title><link href="http://prosys.kaist.ac.kr/dongjae-mobicom/" rel="alternate" type="text/html" title="PL 연구자가 바라본 MobiCom" /><published>2025-11-25T00:00:00+00:00</published><updated>2025-11-25T00:00:00+00:00</updated><id>http://prosys.kaist.ac.kr/dongjae-mobicom</id><content type="html" xml:base="http://prosys.kaist.ac.kr/dongjae-mobicom/"><![CDATA[<h2 id="들어가며">들어가며</h2>
<p>MobiCom은 모바일 컴퓨팅과 네트워크를 다루는 학회로, PL/SE를 주로 다루는 우리 연구실이 참석할 기회는 매우 드물다.
운 좋게도 신인식 교수님 연구실의 이정재 학생과의 공동 1저자 논문이 채택되어 논문 발표자로서 다녀올 기회를 얻었다.
첫 해외 출장이자 혼자 떠나는 출장이면서 동시에 발표자로서 참석하는 첫 국제 학회였기에 나에게는 큰 의미가 있었다.
다만, 당장 다음 주 금요일에 PLDI 논문 제출 마감이었기 때문에 무거운 마음의 짐도 나와 함께 출국했다.
홀로 떠난 출장이기에 최대한 나의 경험과 생각을 구체적으로 공유하여 현장감을 생생하게 전하기 위해 노력했다.</p>

<h2 id="출국">출국</h2>
<p>내가 처음이자 마지막으로 혼자 해외로 떠나는 비행기를 타 본 것은 초등학교 3학년 때였다.
당시 미국에 있는 외삼촌 댁에서 한 달 살기를 하기 위해 홀로 미국행 비행기를 탔었다.
15년이 지나 어엿한 국제 학회의 발표자로서 출국하게 되니 감회가 새로웠다.</p>

<table>
  <thead>
    <tr>
      <th style="text-align: center;"><img src="https://lh3.googleusercontent.com/pw/AP1GczPPh7W5PfaMHlgn6KexuqLBTQAPp7nQxUoHoWJiv6DkjZ2ISUEGUdxri5LaxRzEY02QphjvyPnSsyVNNsXWgd3OEdpTHTlBFPIxQ2Ae1CamcDdxKh5hsvtfK8fiFmjqt8vsywjR9xgSBVWtrPXQOiOt=w695-h926-s-no-gm?authuser=3" alt="" width="80%" /></th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td style="text-align: center"><b>버크셔 돼지 등뼈 K 쌀국수</b></td>
    </tr>
  </tbody>
</table>

<p>여행을 가기 전에는 모름지기 음식을 든든하게 먹어두어야 한다.
게다가, 초저가 항공사인 홍콩 익스프레스를 탑승했기 때문에 기내식이 제공되지 않아 더욱 든든하게 먹어야 했다 (물도 돈을 주고 사야 한다).
내 선택은 압도적인 크기의 등뼈 쌀국수였다.
버크셔 돼지 등뼈 K 쌀국수라는 글로벌한 이름을 가진 메뉴였다 (영국 돼지 + K- + 쌀국수).
아침 9시부터 비닐장갑을 끼고 등뼈를 뜯고 있는 내 모습이 조금 우스웠다.</p>

<p>식사 직후에는 출국 심사와 PLDI 논문 제출을 위한 실험을 돌린 후 발표 연습을 했다.
출국 전 주 금요일에 연구실 내부 리허설을 진행했는데 썩 마음에 들지 않는 상태였다.
이번 리허설을 진행하면서 스스로가 발표에 있어 자신이 없을수록 긴장하게 된다고 느꼈다.
역시 자신감은 실력에서 나오는 법일까?
연구실의 피드백과 주말 동안의 연습을 통해 최대한의 자신감을 확보하기 위해 노력했다.</p>

<h2 id="홍콩-적응기">홍콩 적응기</h2>
<table>
  <thead>
    <tr>
      <th style="text-align: center;">
        <img src="https://lh3.googleusercontent.com/pw/AP1GczOoT7NnsgewFiZOYAgCbYoW5Ww2Uee_wWny3wkQmp9q0nacG24pnMmI85-R7osCH6cnBW5LLZfQyADySwZA_x2nYT-H_X29kfr1FS3YB03ezow9yKtYIxiY655GkXVeIhm3scGLfyJzpG8-G9Zx3U8X=w695-h926-s-no-gm?authuser=3" alt="" width="45%" />
        <img src="https://lh3.googleusercontent.com/pw/AP1GczMz2peSXlyqwcoFxaQ8mQuQx6Gp0DjlTI3hwscICUcVevOZJeg3shRZP9A8AH3HcXb6QENlaWDBSq8EFkKK9cFC02QSrlxp5Bqk2vWf8aG22G7LTa14LliSmm2oHzy6bTiVux3iOKXEXP1ooJLShgJ4=w695-h926-s-no-gm?authuser=3" alt="" width="45%" />
      </th>
    </tr>
    <tr>
      <th style="text-align: center;">
        <img src="https://lh3.googleusercontent.com/pw/AP1GczN88MuheHC0j_gveQrEWOU9S6ge90vczbUgQK5SyxpMF1g6n-IJNSk-aXiT7ZmJkrvxG6wDAxV39D5f-iBmBvGzMgcrd-h9lSPdh5GTZornrmYSN_7pvQY8WQVkpIOARmefOgWEEdLWjtIDT0UXDB2w=w1235-h926-s-no-gm?authuser=3" alt="" width="80%" />
      </th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td style="text-align: center"><b>멋진 호텔</b></td>
    </tr>
  </tbody>
</table>
<p>감사하게도, 연구실의 지원으로 이번 출장에서는 학회가 열리는 Kerry Hotel에서 묵을 기회를 얻었다.
해변 근처의 5성급 호텔이었는데, 방의 크기와 편의 시설 모두 훌륭했다.
특히 밤에 보이는 야경이 장관이었다.</p>

<table>
  <thead>
    <tr>
      <th style="text-align: center;"><img src="https://lh3.googleusercontent.com/pw/AP1GczMstNHL1917Fnqg3hIT6IS60l8usgjMUjQcbUWX6nuVWPpmPMoK18Ds3GrKFVQto4bdir1PXHLL7jy5_LsHc8USeb6ElBQp9dHsZj-TpYOq5mgxAYjAYsZN1UyuW805qFFKfk9y9rRELp1W5dd68KZx=w695-h926-s-no-gm?authuser=3" alt="" width="45%" />
      <img src="https://lh3.googleusercontent.com/pw/AP1GczPuWlqv-Llrea8gCcsh_mphGXi6u-9DMA7L2xgUEl5yF_LT--KrMprKBDcOdSvTVE225imWRVW6Rxe6fNw1lQU1ylm2SZu7wGVLDG9Kx2-03LB_D4dR4Lg3J6XWzfl2jYQdcZMTr4uXgRJ0-TQKYcrX=w695-h926-s-no-gm?authuser=3" alt="" width="45%" />
      </th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td style="text-align: center"><b>호텔로 가는 길</b></td>
    </tr>
  </tbody>
</table>
<p>공항에서 호텔까지는 A25 버스를 타고 갔다.
호텔까지는 총 1시간 15분 정도 걸렸는데, 2층 버스를 타고 경치를 보면서 가니 심심하지는 않았다.
특히 시내 쪽으로 들어갈 때 건너는 거대한 사장교가 인상적이었다.
나는 이런 거대 토목 구조물을 좋아하는데, 커다란 철근 콘크리트 기둥과 케이블이 적절한 조화를 이루어 다리를 떠받치는 모습이 인상적이었다.
콘크리트 기둥이 한국보다는 좀 더 투박한 형태라는 점도 재미있었다.</p>

<table>
  <thead>
    <tr>
      <th style="text-align: center;"><img src="https://lh3.googleusercontent.com/pw/AP1GczOKE5gc6YaNueT4toKF7_9B5IVzCarHpfA1eSnQ7G658mrEK_3PZKYYWYQCES3gIBDVYS7NAvdwnGU1YkOKxfFeO1guqhNYjawLXAVYwrP0lYd9OXGC7WckSDQfoCXl9PEkW7ADpcj7wYtBUCGZa5B2=w695-h926-s-no-gm?authuser=3" alt="" width="80%" /></th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td style="text-align: center"><b>ACM 백팩</b></td>
    </tr>
  </tbody>
</table>

<p>호텔에 도착해서 방에 짐을 둔 후에는 학회 등록을 하러 로비로 내려갔다.
등록은 학회가 시작하는 날부터 하는 줄 알았는데, 나처럼 전날 도착한 사람들을 위해 등록을 먼저 열어두는 것 같았다.
등록하면 여러 가지 기념품을 주는데, 그 중 ACM 백팩이 있었다.
보통 기념품으로 가방을 주면, 에코백을 많이 주는데, 거대한 검은색 백팩을 주어 당황스러웠다.
아쉽게도, 돌아가는 비행기에 수화물 개수 제한이 있어 반입이 어려웠다.
하는 수 없이 호텔방에 그대로 두고 돌아왔다.</p>

<p>등록까지 마치니 벌써 저녁 시간이 되어 딤섬을 먹으러 나갔다.
나는 보통 여행을 떠나면 그때그때 구글 지도에서 맛있어 보이는 식당을 골라 즉흥적으로 가는 편이다.
알아보니 도보 25분 거리에 있는 팀호완이라는 가게가 유명한 것 같아 그곳으로 갔다.
가는 길에는 해가 저물어가는 홍콩의 모습과 러닝을 뛰는 사람들을 볼 수 있었다.
기분 좋은 고독함을 느끼며 딤섬 가게로 가는 길을 걸었다.</p>

<table>
  <thead>
    <tr>
      <th style="text-align: center;">
        <img src="https://lh3.googleusercontent.com/pw/AP1GczNyjAyba4xQe_NXwN6ZcngHAb7_MiSrSBFI4YajAskg3dK65-VNtVwiaHIjhaZ7o5ScAldWUEwxT8Ih5vVz2P0QXgLXccDe6ymMCcB5NoVO7HT4KsyaC8kk73eA3M2hTaqjwKbxdBJBTQDVv5vmcx6R=w695-h926-s-no-gm?authuser=3" alt="" width="45%" />
        <img src="https://lh3.googleusercontent.com/pw/AP1GczOb1WvsbWQ1gbLI6UFjMQPbZGVypIFmra7WVrRzqFkgxB04f-60tx5lCOwuow4qu5NfcM5T2TkX_mniqfknY89agAiiM2NzvHtIzEW3ZttXc_pVDSOH7na8W7mNTkFxa_s2pV0jdOwck63UFyFRqFWq=w695-h926-s-no-gm?authuser=3" alt="" width="45%" />
      </th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td style="text-align: center"><b>맛있는 딤섬</b></td>
    </tr>
  </tbody>
</table>

<p>딤섬 가게에서는 총 세 종류의 딤섬을 주문했다.
시키고 보니 한국에서도 먹을 수 있는 것들이어서 좀 더 도전적인 것을 주문할 걸 하는 생각이 들었다.
하지만 아는 맛이 무서운 법. 홍콩에서의 첫 끼로는 부족함이 없었다.
특히 고추기름 소스가 딤섬의 맛을 훌륭하게 살려주었다.</p>

<table>
  <thead>
    <tr>
      <th style="text-align: center;"><img src="https://lh3.googleusercontent.com/pw/AP1GczMnVUYYKn7C3hBcHnHucoi_uUoMejZaAcsLRFtp3_xSffgAm46YWkzn-IMTDs_7Ib7UH8Q9oXxFjE55sgEzHBEvOJmKtvX9NhXxFVKQr9u3zrmbbSFYEiQ8qTwAgxO3_gN5H0oG5g22RcxsLoiKyVbI=w695-h926-s-no-gm?authuser=3" alt="" width="80%" /></th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td style="text-align: center"><b>가게 이름은 #Hashtag B</b></td>
    </tr>
  </tbody>
</table>

<p>딤섬을 먹고 나서는 홍콩에서 유명한 에그 타르트 가게에 방문했다.
2개의 에그 타르트와 1개의 피스타치오 타르트를 주문했다.
에그 타르트는 파이 기반의 타르트와 패이스트리 기반의 타르트로 나뉜다고 한다.
이곳은 패이스트리 기반의 타르트로, 한국 사람들 입맛에 더 잘 맞는다는 얘기를 들어 이곳으로 방문했다.</p>

<p>짧은 외출을 마치고, 호텔로 돌아와서는 다음 날 있을 VeriSafe Agent 발표 연습을 했다.
5번 정도 처음부터 끝까지 발표를 반복해서 연습했는데, 지난주 금요일 리허설보다는 훨씬 만족스러웠다.
발표 자료를 약간 수정한 후 긴장 반 걱정 반으로 잠자리에 들었다.</p>

<h2 id="나의-첫-해외-학회-발표">나의 첫 해외 학회 발표</h2>

<p>장거리 이동을 해서 발표 당일 컨디션이 나쁠까 걱정했지만, 다행히 컨디션이 좋았다.
마지막으로 발표 연습을 방에서 하고, 아침을 먹으러 근처 맥도날드로 갔다.
지난주부터 맥모닝을 먹고 싶었는데, 배도 채울 겸 맥모닝을 주문했다.
메뉴는 팬케이크가 포함된 디럭스 세트였는데, 팬케이크가 말라비틀어져서 상당히 실망스러웠다.
아쉬운 마음과 함께 호텔로 돌아갔다.</p>

<table>
  <thead>
    <tr>
      <th style="text-align: center;"><img src="https://lh3.googleusercontent.com/pw/AP1GczOv9I-JscNkTqg4fQ5EgAFA51gKQxL0YjMmDWbv0Trr9y5y-cQEvhz120iUe9qYtuLTtnrZ0ZMdIdxoDbw6atgbbaVnwtsQQgdltBVfHkFbWAnWtWBlJpBIdqZEHBrtyLJqaaCAB4Mh0Yd9Ov96_3yb=w695-h926-s-no-gm?authuser=3" alt="" width="80%" /></th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td style="text-align: center"><b>아침밥</b></td>
    </tr>
  </tbody>
</table>

<p>MobiCom은 독특하게도 단일 세션으로 진행된다.
즉, 동 시간대에 여러 개의 세션이 진행되지 않고 하나의 세션만 진행된다.
그렇기 때문에 학회가 진행되는 발표장 역시 다른 학회보다 훨씬 크다.
내 체감상 여름에 다녀온 PLDI의 가장 큰 발표장보다 1.5배 정도 크게 느껴졌다.
스크린의 크기 역시 그에 걸맞게 훨씬 거대했다.
발표 자료도 모든 자리에서 가려지지 않고 잘 보여서 좋았다.</p>

<table>
  <thead>
    <tr>
      <th style="text-align: center;"><img src="https://lh3.googleusercontent.com/pw/AP1GczNPmLWfzj8Tby_HEe1kh96gTR6tvfQVYBPrteUVx4Zx9QIHHkl9kgWkX2FlFcMm6Ew5sNOUOILkqACze7LgfDq165Unt-s9OwOmVtLCvEfWYzi7ZokYYckCYQnCUeofaxuNpJV2xFbvmKeSKwibRF-4=w695-h926-s-no-gm?authuser=3" alt="" width="80%" /></th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td style="text-align: center"><b>학회장으로 가는 웅장한 길</b></td>
    </tr>
  </tbody>
</table>

<p>첫 학회 발표인 데다가 혼자 덩그러니 앉아 있으니 더욱 긴장이 몰려왔다.
하지만, 이런 큰 무대에서 발표할 수 있다는 사실에 설레는 마음도 있었다.
해외 학회에 참석하더라도 이런 큰 무대에서 발표하는 것은 드문 기회이기에 잘 마무리해야겠다는 생각이 들었다.</p>

<p>발표할 때면 긴장을 해소하는 나만의 방법이 있다.
발표를 듣는 청중들을 사람이 아닌 무언가 (강아지, 고양이 등등)이라고 생각하면 긴장이 해소된다.
청중들을 대단한 사람들이라고 생각하고 실수를 안 하려고 신경 쓰면 오히려 실수를 더 자주 저지르게 된다.
반대로, 청중들을 평범한 사람들 혹은 극단적으로 사람이 아닌 무언가라고 생각하면 실수하지 않아야겠다는 생각을 없앨 수 있다.
핵심은 잘 하고자 하는 마음을 없애면 긴장이 풀린다는 것이다.
건전한 방법인지는 모르겠으나 개인적으로 효과는 확실했다.</p>

<table>
  <thead>
    <tr>
      <th style="text-align: center;">
        <img src="https://lh3.googleusercontent.com/pw/AP1GczN3oQQW9flrnuGlqUmf5ziRylDCCw52kcn24FGdiaXDfgOJWiB_exkIqRossSrYPOi9ZmedqkjecXm3gH29u3VKtcNRCcEoCGdJ79ZYB7s57IWlhwxn9dLjzFvbaPbv1bSW_sdsJvZ1QrZvu1fa0fWm=w695-h926-s-no-gm?authuser=3" alt="" width="45%" />
        <img src="https://lh3.googleusercontent.com/pw/AP1GczPSo14oy1-CvNIoNSKSZkVNTVnh7e9gU1ZNve9yZ_ewmhKlNcCHCYf0u5QUiCI94OUssB8xX96fqxkefRbaT-yGKgYFsl1lCAuiUVPQ5YQC28vSK10pv06T_-kJtyMdI5l1faeT6FCoiGZwx2yzRRg6=w694-h926-s-no-gm?authuser=3" alt="" width="45%" />
      </th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td style="text-align: center"><b>발표하는 나. 호텔 직원분께 부탁드렸다.</b></td>
    </tr>
  </tbody>
</table>

<p>첫 발표를 마치고 나서 개인적으로는 만족스러웠다.
전달하고자 하는 내용도 모두 명확히 전달했고, 발표 시간도 이전에 생각해 두었던 12분을 정확히 맞추었다.
집중력의 차이 때문인지 오히려 실전에서 연습 때보다 훨씬 더 잘 해낸 것 같아서 더욱 만족스러웠다.
시간을 잘 지키니 그것 때문인지는 모르겠지만 세션 체어가 나를 흐뭇한 미소와 함께 쳐다보았다.
뿐만 아니라, 꽤 많은 사람들이 내 발표에 대해서 질문을 하기 위해 마이크 앞에 줄을 서 있었다.
내 기억으로는 기조연설을 제외하고 가장 질문자가 많았던 것으로 기억한다.
첫 발표치고는 훌륭한 성과였다.</p>

<p>다만 아쉬웠던 것은 질의응답이었는데, 긴장한 탓에 상대방이 무슨 말을 하는지 정확히 이해를 못 해서 동문서답을 했다.
특히 질문을 하는 사람이 정리된 질문을 하는 것이 아니라 생각나는 대로 이것저것 언급하면 더욱 답변하기가 어려운 것 같다.
영어 공부를 더 열심히 해야겠다는 생각이 들었다.</p>

<h2 id="mobicom에서-보고-들은-것">MobiCom에서 보고 들은 것</h2>

<table>
  <thead>
    <tr>
      <th style="text-align: center;">
        <img src="https://lh3.googleusercontent.com/pw/AP1GczPFIbdKXyShjP-uFay2xksT-sHrqdUIanlv4GT-8QHmmmCVqNvfYDtuVVf-JbXC2uxVRZK2uVtgGU11hXRnHCdidxqYpd_HX96ZLhMlcRIUnhCNqEuPXD8kru-G-YBND3qaJFC4M0wjQU_eXgYzxUfV=w1235-h926-s-no-gm?authuser=3" alt="" width="80%" />
      </th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td style="text-align: center"><b>MobiCom 방문 인증</b></td>
    </tr>
  </tbody>
</table>

<h3 id="운영-방식의-차이">운영 방식의 차이</h3>
<p>PLDI와 MobiCom의 결정적인 차이는 운영 방식에 있었다.
병렬로 각자 관심 있는 세션에 들어가는 PLDI와는 달리 MobiCom은 같은 시간에는 하나의 세션만 운영한다.
장점은 관심 없었던 새로운 분야의 연구도 접해볼 수 있다는 것이지만,
반대로 그 연구를 이해하기 위해서 상당한 에너지를 소모해야 했다.
특히, 통신이나 센서 분야의 경우 내가 전혀 배경지식이 없어서 이해하는 데 애를 먹었다.</p>

<table>
  <thead>
    <tr>
      <th style="text-align: center;">
        <img src="https://lh3.googleusercontent.com/pw/AP1GczOLkv0pZMirwoyFS_oPATpFL38wWMOdyOyjdoAbA67DX0Ura2X784jonI7ZIG_cxt8kDR9D4IIyK-ycYcHcMcSKbnD-lurCCfkyQYYyxSaDpG-nYYPgPCTkPFAKIUJFp4ZUjksPO2Q6MsGLP5PWrhee=w695-h926-s-no-gm?authuser=3" alt="" width="80%" />
      </th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td style="text-align: center"><b>갑자기 등장한 사자</b></td>
    </tr>
  </tbody>
</table>

<p>또 재미있었던 부분은 뱅큇 중간에 진행되는 시상식을 아주 요란하게 한다는 점이다.
올해는 매 시상마다 중국 전통 사자춤을 추는 연출이 있었다.
PLDI의 경우 굉장히 정적이고 엄숙하게 진행되었던 것으로 기억하는데, 이렇게 재밌는 이벤트가 있으면 더 좋겠다는 생각이 들었다.</p>

<table>
  <thead>
    <tr>
      <th style="text-align: center;">
        <img src="https://lh3.googleusercontent.com/pw/AP1GczNh362if-e9ISRwl5hveHa0ZbaVWvNAjKUfGTos-jaMmKsMwtKtWLjmywAhh-auIey_Sbb0zmOUfcvPyy2hsN0tm2WiWh8HGS6OKKD13xHhhLVArfaLSWuI1bicDQGJ4aYV_YaiaRNob0YkLr9GSaPC=w694-h926-s-no-gm?authuser=3" alt="" width="45%" />
        <img src="https://lh3.googleusercontent.com/pw/AP1GczNyb10LvMlo9nQ2W8svPVFvlAkq7-I6EwmOU66ZPCTT7R2IybS1RLG1uGrHASCua2wt8zjTNwRC2Vsxful7xPM2TA2cBoufl1-r7ie1VNbriSmwrJUN-z6ruTy1S16YAbrAZkZtZNT7dmZ7ATpha72b=w695-h926-s-no-gm?authuser=3" alt="" width="45%" />
      </th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td style="text-align: center"><b>뱅큇 음식들. 양 안심은 처음 먹어봤는데 양고기 특유의 향이 거의 없었다</b></td>
    </tr>
  </tbody>
</table>

<h3 id="흥미로운-문제들">흥미로운 문제들</h3>
<p>현실적인 문제를 정면으로 다룬다는 점도 인상적이었다.
PLDI도 현실의 문제를 풀긴 하지만 대부분 소프트웨어 개발 현장(컴파일러, 버그 찾기, 프로그램 수정 등)에 머문다.
연구 분야가 PL/SE니 당연한 결과겠지만, MobiCom은 일반 사용자를 위한 프로젝트가 많아 문제의 동기가 훨씬 폭넓었다.</p>

<table>
  <thead>
    <tr>
      <th style="text-align: center;">
        <img src="https://lh3.googleusercontent.com/pw/AP1GczPtSFXFeCNfUoZZc5PrAuOuVheivvs7wAfY2R3d2L0XQiXN5Vkx5tIcyPCn7K_kvEsyg6lvJK7LW_Cw_21M-eH5YIv_t6s_1v840X_L_sYAIkmLtim7126uPqBruwy0FWmP8ycqcY95sYdXkUTdRKvA=w1235-h926-s-no-gm?authuser=3" alt="" width="80%" />
      </th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td style="text-align: center"><b>Hearable 기기용 음성 처리 AI 연구</b></td>
    </tr>
  </tbody>
</table>

<p>한 가지 사례는 Hearable기기 (보청기와 이어폰의 중간 어딘가)에서 음성 처리를 위한 AI를 개발하는 연구였다<sup><a href="#Hearable">1</a></sup>.
주요 문제는 이어폰에 들어가는 연산 장치 수준으로 실시간 (6ms 미만) 음성 처리를 해야 한다는 것이다.
API를 사용하는 경우 응답 지연이 심해지고, 반대로 직접 연산을 수행하자니 기존 음성 처리 모델들이 너무 크기 때문에 적합하지 않았다.
기존 모델들도 지연 시간이 너무 길고 (25ms) 품질도 떨어졌다.
연구자들은 모델과 디코딩 알고리즘, 하드웨어를 동시에 최적화하는 방식으로 문제를 해결했다.</p>

<p>흥미로웠던 부분은 문제 해결 방식보다 도메인이었다.
모바일 기기들의 특성상 적은 자원을 사용해서 빠른 시간에 좋은 결정을 내려야 하는 경우가 많다.
즉, 최신 대형 모델을 사용할 수 없는 것이다.
이러한 문제야말로 신경-기호 AI가 활약하기 적합한 환경이라는 생각이 들었다.</p>

<table>
  <thead>
    <tr>
      <th style="text-align: center;">
        <img src="https://lh3.googleusercontent.com/pw/AP1GczPtSFXFeCNfUoZZc5PrAuOuVheivvs7wAfY2R3d2L0XQiXN5Vkx5tIcyPCn7K_kvEsyg6lvJK7LW_Cw_21M-eH5YIv_t6s_1v840X_L_sYAIkmLtim7126uPqBruwy0FWmP8ycqcY95sYdXkUTdRKvA=w1235-h926-s-no-gm?authuser=3" alt="" width="80%" />
      </th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td style="text-align: center"><b>AutoIoT</b></td>
    </tr>
  </tbody>
</table>

<p>비슷한 문제의식을 공유하는 AutoIoT<sup><a href="#AutoIoT">2</a></sup> 라는 이름의 연구도 있었다.
AIoT(Artificial Intelligence of Things) 분야에서는 센서 데이터를 받아 “온도가 올라가면 에어컨을 켜라” 같은 의사 결정을 내리는 시스템을 만든다.
하지만 기존 방식처럼 날것의 센서 데이터를 LLM에게 직접 보내면 개인정보 유출, 높은 쿼리 비용, 지연 문제가 한꺼번에 터진다.
AutoIoT는 LLM이 바로 결정을 내리기보다 의사 결정 코드를 작성하게 만들어 이 문제를 우회했다.</p>

<p>IoT나 웨어러블 분야 역시 호출 빈도가 높고 센서 데이터를 그대로 이해하기 어려워 대형 모델을 쓰기 힘든 영역이다.
여기에 신경-기호 AI로 신호 처리와 신경망 모델을 결합하면 실용적인 솔루션을 디자인할 수 있겠다는 생각이 들었다.
특히 PLDI에서 Işıl Dillig 교수님이 소개한 신경-기호 합성기<sup><a href="#NeurosymbolicSynth">3</a></sup>와 엮으면 현실적으로 활용할 수 있으면서도 흥미로운 연구를 할 수 있을 것 같다.</p>

<h3 id="pl의-활용">PL의 활용</h3>

<table>
  <thead>
    <tr>
      <th style="text-align: center;">
        <img src="https://lh3.googleusercontent.com/pw/AP1GczMyluHpuHSuYwwu8lmB52tA9ABOVusD0MaHGVZEvYCRVASx3XCmLYd9yoDWvquGkZXcS8IBKLGtZSbEam7e41YWX9B-v6SiY8vr48H5ujkHwOziebL87W01zBjxC6QuKGenkAsNE0c7iUMkU4l4SxE6=w1235-h926-s-no-gm?authuser=3" alt="" width="80%" />
      </th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td style="text-align: center"><b>스펙의 발전이 더 빠른 독특한 상황</b></td>
    </tr>
  </tbody>
</table>

<p>발표를 듣다 보면 PL 분야의 기본 기술조차 다른 분야에서 꽤 넓은 활동 무대를 가질 수 있다는 사실을 새삼 깨닫게 된다.
대표 사례가 블루투스 명세의 엄밀한 검증(Formal Verification) 연구였다<sup><a href="#FVBluetooth">4</a></sup>.
자연어 명세를 Dafny로 유한 상태 머신(Finite State Machine)으로 옮기고, 구현체도 동일한 형태로 모델링한 뒤 모든 동작이 명세를 지키는지 수학적으로 증명했다.
전형적인 기법이지만 새로운 도메인에 적용했다는 이유만으로도 충분한 가치를 인정받은 셈이다.</p>

<p>내가 발표한 VeriSafe Agent 역시 실행 중 검증(Runtime Verification)과 유사한 기법으로 에이전트의 행동을 검사한다<sup><a href="#VeriSafeAgent">5</a></sup>.
방식 자체는 기초적이지만, 검증의 대상과 문제 설정이 신선해 MobiCom 무대에 설 수 있었다.</p>

<p>글을 쓰다 보니 얼마 전 연구실 회식 자리에서 교수님이 들려주신 이야기가 떠올랐다.
교수님께서 박사 과정을 하던 시절에는 SE 분야에 다루기 좋은 문제가 많지만, 해결 방식이 종종 이론적 토대를 갖추지 못해 PL 기술을 이식할 여지가 많았었다는 내용이었다.
모바일 분야도 아직 PL 기술이 본격적으로 적용되지 않은 미개척지라는 생각이 자연스레 이어졌다.</p>

<p>지금까지 PL 기술이 ‘프로그래밍’에 묶여 있었다면, 앞으로는 현실 문제를 프로그램처럼 모델링해 PL 이론을 접목하는 방식이 가능하다고 본다.
언어 모델 덕분에 비정형 데이터를 정형화하기가 쉬워졌으니, PL 기술을 현실 문제 해결에 직접 투입하는 날도 머지않았다.</p>

<table>
  <thead>
    <tr>
      <th style="text-align: center;">
        <img src="https://lh3.googleusercontent.com/pw/AP1GczMDXmRLaKkTHFaGsVCUrVHg0p4wB1ye2yhDoGKXlMEWIq8yriQOQ198ZNRv0OQflUe-_EzdvMCAhQZq2L2fveaqF9CiS7JNbfbW9oSdRZwBk146rT6QB1fLrIb-E86sh7S0ls-kY4N4sMBoHE-jjDIe=w1235-h926-s-no-gm?authuser=3" alt="" width="80%" />
      </th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td style="text-align: center"><b>온고지신</b></td>
    </tr>
  </tbody>
</table>

<p>MobiCom 개회사에서도 옛것과 새것을 아우르는 융합 연구가 높은 Acceptance Rate를 차지한다는 통계가 소개됐다.
융합 연구는 접근법 자체가 참신하다는 장점이 있고, 연구자 개인에게도 다양한 분야의 지식을 흡수하며 사고 틀을 넓혀 준다.
한 분야만 깊게 파다 보면 사고가 굳어지기 쉬운데, 여러 분야를 넘나드는 공부가 유연한 사고방식을 지켜 준다.
AI 발전으로 지식 습득 장벽이 낮아진 만큼, 나 역시 PL/SE를 넘어 AI, 모바일, 네트워크 등 다양한 도메인에서 새 문제를 찾아보고 싶은 마음이 커졌다.</p>

<h2 id="홍콩-여행">홍콩 여행</h2>

<p>학회를 즐기고 남는 시간에는 학회장 주변 여행을 다녔다.
방문하기 직전 PLDI 준비로 워낙 바빠서 홍콩에 무엇이 있는지 전혀 알지 못한 상태로 방문했지만,
운 좋게도 신인식 교수님 연구실 분들을 만나 함께 여행을 다녔다.</p>

<table>
  <thead>
    <tr>
      <th style="text-align: center;">
        <img src="https://lh3.googleusercontent.com/pw/AP1GczMuoQYU4mOVHXaJmTS4kVFMVDHZwauKRyMfZ13mr1Aqv6eXL9bZ3YzTzLJXzz6GyBdzEqdKBFS0e3BpX4ze05JzIKkl1x4E_nMc55wWkba1zjdAMvqObBv8-60qXpyMvUEb1sJqL9SXFS6mipmhoUYQ=w695-h926-s-no-gm?authuser=3" alt="" width="45%" />
        <img src="https://lh3.googleusercontent.com/pw/AP1GczNwkDriy5zZiuvhGaDLCs02jzRtpPlfFOfttDc2mRYx4tC99WtxPszNabl_JJbvTah4_QUacxLWW-gQVQyfrb9nygFJ9zZSgaRPcf8kDpYSXMrNaDnWY4WKsQhSJUfQlvXGOhrLhuXy7B5qZ2DHQIh8=w695-h926-s-no-gm?authuser=3" alt="" width="45%" />
      </th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td style="text-align: center"><b>우유 푸딩과 토스트</b></td>
    </tr>
  </tbody>
</table>

<p>홍콩은 미식의 도시로 유명하지만, 그중에서도 디저트류와 딤섬이 유명하다고 한다.
그중에서도 우유 푸딩을 먹기 위해서 페리를 타고 바다를 건넜다.
우유 푸딩, 연꽃 푸딩, 생강 푸딩을 주문했다.
연꽃 푸딩은 연꽃 열매가 올라간 푸딩이었는데, 향이 없는 밤 맛이 났다.
전반적으로 우유 향이 진해서 맛있게 먹었다.</p>

<table>
  <thead>
    <tr>
      <th style="text-align: center;">
        <img src="https://lh3.googleusercontent.com/pw/AP1GczOm1gMWs2eQPWd3wvMYQeEGULms7ORAURoAgtTaSwwlDdU5wnnC3la1RJFE2D7-WEwI3JtBhybAzy5GiDyW21W1TeTefqB1MgF4e_P0WuXBU9hIV3f_JX7bqUXJmGiKxuQb_9lzTFfQVoTEgVSZRuxa=w695-h926-s-no-gm?authuser=3" alt="" width="45%" />
        <img src="https://lh3.googleusercontent.com/pw/AP1GczMW588x9GFoodf9rfcWpOYxD0w8qM28wrdEUCTWDO18Athqjwfs7RytT_fQo3xCv-YPwOiBCNle1p_RxdVuBCyQXEJFrGcTCGQ4KzDWkscj4CfWfKgyP7Yq0-hRvpPhn3L7TlAJ0V3GlmGLYTwbuRV-=w695-h926-s-no-gm?authuser=3" alt="" width="45%" />
      </th>
    </tr>
    <tr>
      <th style="text-align: center;">
        <img src="https://lh3.googleusercontent.com/pw/AP1GczNeh2tbQRSm53cuyeTR-wCzhZhTeJkcFbltjAk8mxYMBMCDxZoYJF8H0Tdwznyz_PpF1cx5RRi6mWqUb-33GCEOq81BF76M3RF3-wH79Lf7LRodu9pqAn1LQKaVDY_8CBaXx--VGSv6UzjNLPiD21c4=w695-h926-s-no-gm?authuser=3" alt="" width="45%" />
        <img src="https://lh3.googleusercontent.com/pw/AP1GczN--8fWI7peIV_7r0ycAwuOZDEBIR7J701rIr_IEDg66F3SnAa7zyyvnoaQ689wnoKXN4F_Or0KsGJe8nHKEIJN2Ugq2_3rLROIp_RsqTMwQaLeVQgNrJp0jxKP_fESlh8umpLCeCEgof21OA5yJ_51=w695-h926-s-no-gm?authuser=3" alt="" width="45%" />
      </th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td style="text-align: center"><b>재밌는 것들</b></td>
    </tr>
  </tbody>
</table>

<p>이후에는 영국이 지배하던 시절의 홍콩에 최초로 지어진 감옥을 방문했다.
이런 장소는 역사적 배경을 알고 방문하면 좀 더 재밌는데, 사전 조사가 부족해서 아쉬웠다.
이후에는 호텔로 돌아가는 길에 도교 사원, 길거리 시장을 구경했다.</p>

<p>솔직히 말해서 여행 장소로서 홍콩은 아쉬운 점이 많았다.
대부분의 길거리 모습이 비슷하고 (중국어가 많은 명동 느낌), 관광할 장소도 한정적이었다.
게다가 내가 홍콩 영화에 대해서 아는 게 없다 보니 영화에 나온 장소에 가더라도 크게 느껴지는 것은 없었다.
조금 아쉬웠지만 PLDI 논문 제출 직전이었기 때문에 오히려 유혹에서 벗어날 수 있어 다행이라는 생각이 들었다.</p>

<h2 id="마치며">마치며</h2>

<table>
  <thead>
    <tr>
      <th style="text-align: center;">
        <img src="https://lh3.googleusercontent.com/pw/AP1GczN9FyGFnERrPKRuo-nSLAz8NMycwU6H9UFV7Gz9BYdDT_3fst_WG38ZbSfBbRd-aVbKu47TfWMdok4EXwRFmaWLsybmYS-m3hG4o7_fmF12QKFp_AoOxg5rsYaTzF8_OI7DvJW21UdVzci9qQDN9v0t=w694-h926-s-no-gm?authuser=3" alt="" width="45%" />
        <img src="https://lh3.googleusercontent.com/pw/AP1GczMEyludNZNeEaY9qv3hddrJEflQeAxzhMO9FspTZ6nuskcILeaXaPHlaNEwzwFSGDaNTJOFU-BKOdLKO8-yfDDyga0e7DJe5FNrdUlrtBJw5gVtkGWbK2x_hWKmuYfINOjgY8edAZA9WL7DkUjPI-gm=w695-h926-s-no-gm?authuser=3" alt="" width="45%" />
      </th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td style="text-align: center"><b>MobiCom 안녕~</b></td>
    </tr>
  </tbody>
</table>

<p>이번 출장에서는 여러 가지 고마운 일들이 많았다.
먼저, 처음으로 떠난 출장이자, 혼자 떠난 출장이어서 걱정되는 점도 많았지만 별 탈 없이 돌아온 것에 감사한다.
그리고, 신인식 교수님 연구실 분들이 챙겨주셔서 외롭지 않게 학회와 홍콩을 즐길 수 있었다.
교수님과 연구실 차원에서 좋은 호텔과 학회비를 지원해 주어 좋은 환경에서 머물다 올 수 있었다.
마지막으로 함께 논문을 작성한 모든 저자분들 덕분에 대표로 MobiCom이라는 큰 무대에서 발표할 기회를 얻을 수 있었다.
나에게 귀중한 경험을 제공해 준 모든 사람들에게 감사를 전한다.</p>

<table>
  <thead>
    <tr>
      <th style="text-align: center;">
        <img src="https://lh3.googleusercontent.com/pw/AP1GczOSb2YpIGmLPvdoEIqBtg5zL9Nn_Mj7y9Mo9behDPg6iNj0pufx47BFeZl4X9_YN4vtkC1oWOI-rUPIJEKMe3ZxiCa0vNKPdz7sBB1CeK_SXMDhQqBTLvHx9GiVs4FsFnSMpagsR1JGlCI8hRREHr2l=w1235-h926-s-no-gm?authuser=3" alt="" width="80%" />
      </th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td style="text-align: center"><b>연구 잘하는 법: Stay curious! Keep questioning! Keep exploring!</b></td>
    </tr>
  </tbody>
</table>

<p>이번 연구를 통해 소프트웨어 분야 밖에도 우리가 기여할 수 있는 문제들이 많이 있다는 사실을 새삼 느꼈다.
같은 분야 사람들과의 소통도 중요하지만, 때로는 전혀 다른 분야의 연구자들과 대화하며 시야를 넓히는 일이 큰 자극이 된다는 것도 깨달았다.
하던 것만 하는 지루한 연구자가 되지 않기 위해서 부단히 노력해야겠다.</p>

<h2 id="참고-문헌">참고 문헌</h2>
<p>[<a name="Hearable">1</a>] Itani et al. Wireless Hearables With Programmable Speech AI Accelerators
[<a name="AutoIoT">2</a>] Shen et al. AutoIOT: LLM-Driven Automated Natural Language Programming for AIoT Applications
[<a name="NeurosymbolicSynth">3</a>] Barnaby et al. PhotoScout: Synthesis-Powered Multi-Modal Image Search
[<a name="FVBluetooth">4</a>] Le et al. Formalization, Implementation, and Verification of the Bluetooth L2CAP State Machine
[<a name="VeriSafeAgent">5</a>] Lee et al. VeriSafe Agent: Safeguarding Mobile GUI Agent via Logic-based Action Verification</p>]]></content><author><name>이동재</name></author><category term="Trip" /><category term="MobiCom2025" /><summary type="html"><![CDATA[들어가며 MobiCom은 모바일 컴퓨팅과 네트워크를 다루는 학회로, PL/SE를 주로 다루는 우리 연구실이 참석할 기회는 매우 드물다. 운 좋게도 신인식 교수님 연구실의 이정재 학생과의 공동 1저자 논문이 채택되어 논문 발표자로서 다녀올 기회를 얻었다. 첫 해외 출장이자 혼자 떠나는 출장이면서 동시에 발표자로서 참석하는 첫 국제 학회였기에 나에게는 큰 의미가 있었다. 다만, 당장 다음 주 금요일에 PLDI 논문 제출 마감이었기 때문에 무거운 마음의 짐도 나와 함께 출국했다. 홀로 떠난 출장이기에 최대한 나의 경험과 생각을 구체적으로 공유하여 현장감을 생생하게 전하기 위해 노력했다.]]></summary></entry><entry><title type="html">안전한 정적 분석과 시대정신</title><link href="http://prosys.kaist.ac.kr/dagstuhl/" rel="alternate" type="text/html" title="안전한 정적 분석과 시대정신" /><published>2025-11-24T00:00:00+00:00</published><updated>2025-11-24T00:00:00+00:00</updated><id>http://prosys.kaist.ac.kr/dagstuhl</id><content type="html" xml:base="http://prosys.kaist.ac.kr/dagstuhl/"><![CDATA[<h2 id="들어가며">들어가며</h2>
<p>“시대정신”이라는 말이 있다.
특정한 시대에 큰 영향을 끼치는 중요한 가치를 일컫는다고 한다.
독일의 철학자 헤겔이 그 개념을 처음 고안한 이래 지금까지 이어져 매 선거철이면 우리 귀를 자주 간지럽힌다.</p>

<p>지난 4월 헤겔의 나라에서 이메일을 한 통 받았다.
<a href="https://dagstuhl.de/25421">“현대 SW공학과 안전한 정적 프로그램 분석(Sound Static Program Analysis in Modern Software Engineering)”</a>이라는
주제로 닥스툴 세미나(Dagstuhl Seminar)가 열리는데 참가하지 않겠느냐는 초청장이었다.
닥스툴 세미나는 독일의 작은 마을인 닥스툴의 닥스툴 성(Schloss Dagstuhl)에서 정기적으로 열리는 전산학 분야 전문가들의 모임이다.
일년 내내 각 분야별 다양한 주제로 세미나가 열리는데, 초청받은 연구자들이 모여 3-5일간 집중적으로 토론하고 교류하는 자리다.
닥스툴 세미나가 즐거운 자리라는 것을 익히 들은적 있는데다가, 특히 주제도 매우 마음에 들어서 단숨에 참가한다고 답장을 보냈다.</p>

<p>현대 SW 개발에서 정적분석은 빠질 수 없는 필수 요소가 된지 오래다.
특히, 안전성(soundness)이 보장되는 정적 분석기는 프로그램의 올바름을 증명할 때 필수이다.
정적 분석에서 안전성이란 프로그램의 실제 실행의미를 모두 포섭하도록 분석하는 성질을 뜻한다.
분석기가 실행의미를 모두 포섭하면서 샅샅이 훑어봤는데도 오류가 없는 것으로 밝혀지면 그 프로그램은 올바른 것이다.
가령, 어떤 변수 x의 값이 프로그램 실행 중에 항상 10 이상이라고 하자.
안전한 정적 분석기는 이러한 실제 값을 모두 포섭하면서 x의 값을 실행 전에 예측한다.
예를 들어, x의 값이 “양수”라고 예측한다면 이는 안전하게 실제를 모두 포섭한 것이다.
양수는 10 이상인 수를 모두 포함하므로.
이러한 예측 결과가 있으면, “1/x”이라는 식이 0으로 나누는 오류가 없음을 증명할 수 있다.
예측 결과 “x”는 양수이므로 0이 될 수 없기 때문이다.
실제를 포섭하는 예측 결과로도 오류 발생 가능성이 없다는 것을 보였으니,
실제 실행에서도 당연히 오류가 없을 것임이 자명하다. 증명 끝.
테스팅으로는 유한 시간안에 구석구석 숨어 있는 모든 오류를 찾아낼 수 없기 때문에,
크고 복잡한 시스템 개발에서 이러한 정적 분석은 아주 유용하다.
따라서 SW의 안전성이 매우 중요한 시스템(예: 항공기 제어, 운영체제, 의료기기 등)에서는 안전한 정적 분석기가 필수적이다.</p>

<p>하지만, 안전한 정적 분석이 안전필수 SW가 아닌 일반 응용SW 개발에서 얼마나 실용적인가에 대해서는 여러 의견이 많다.
실행의미를 모두 포섭하기는 하지만 실제가 아닌 상황까지 고려하는 경우도 있다는 문제 때문이다.
너무 보수적으로 프로그램을 분석하다보면 실제 오류가 아닌데도 오류라고 판단하는 경우가 생긴다.
가령, 어떤 변수 x의 값은 실제로 항상 양수만 가능한데도, 분석기가 보수적으로 “0보다 같거나 큰 수”라고 판단하는 경우도 있다는 뜻이다.
그렇다면 “1/x” 같은 식이 있을 때, 분석기는 x가 0이 될 가능성도 있다고 잘못 판단하여 “0으로 나누기 오류”를 보고할 것이다.
이른바 허위경보(false alarm)이다.
안전하지만 허위경보가 절대 없는 정적 분석기를 만드는 것은 이론적으로 불가능하다는 것이 이미 증명되어 있다.
그리하여 사람들은 허위 경보 비율을 줄이기 위해 종종 안전성을 포기하는 선택을 하곤 한다.
그러다보면 당연히 실제 오류를 놓치는 경우도 발생하기 마련이다.
따라서 허위경보와 놓치는 오류 사이에서 적절한 균형을 찾는 여러 기술을 많은 이들이 개발하고 있다.</p>

<p>이번 닥스툴 세미나의 주제는 이른바 “안전한 정적 분석의 시대정신”“을 논하자는 것으로 들렸다.
현대 소프트웨어 개발 현장에서 필요로 하는 정적 분석은 어떤 모습이어야 하는가?
지난 50년간 이 분야가 걸어온 길은 어떠하며, 앞으로는 어떤 방향으로 나아가야 하는가?
우리 연구실도 이에 관해 오랫동안 고민하던 차였다.
마침 최근 재미있는 성과도 나오고 있는 터라 우리 이야기를 들려주면 아주 딱이겠다 싶었다.
참가자들의 전문 분야도 다양해서 사람들이 어떤 반응을 보일지도 무척 궁금했다.
새로운 모험을 떠나는 기분으로 독일행 비행기에 올랐다.</p>

<h2 id="닥스툴-가는-길">닥스툴 가는 길</h2>

<p>모험은 역시 멀고 험난한 법.
전에 닥스툴에 다녀온 분들과 이야기할 때면, 하나같이 빠지지 않는 말이 있었다.
바로 외진 시골 마을이라는 점.
교통이 불편하다고들 했다.
가기 전까지 그저 도시사람(서울사람)들의 엄살이라고 여겼다.
안내서를 보니 프랑크푸르트 공항에서 기차와 택시를 타고 한참 가야한다고 되어 있다.
시간이 좀 걸리기는 한데, 기차와 택시로 갈 수 있는데 웬 엄살인가?</p>

<p>막상 가보니 뒤통수가 얼얼했다. 택시를 타면 갈 수 있다고 했지, 택시를 항상 탈 수 있다고는 하지 않았다는 점을 놓쳤다.
한국에서 독일로 가는 비행기는 보통 독일 시간으로 저녁에 도착하고, 하필 내가 도착한 날은 일요일인 것이 문제였다.
안내서에 적힌 여러 경로 중, 나는 St. Wendel 역에서 택시를 타는 방법을 골랐다.
프랑크푸르트 공항에서 St. Wendel 역까지는 기차로 약 두 시간 걸리고
역 앞에는 정류장이 있으니 거기서 버스나 택시를 타면 된다고 했다.
구글 스트리트 뷰로 미리 역 주변을 살펴보니 정류장도 있고, 역 바로 앞에 건물도 보이는 흔한 마을이었다.
인터넷 검색을 해보니 내가 잘 아는 교수님들의 여행기가 몇 편 보였는데,
다들 St. Wendel 역에서 택시나 버스를 탔다고 하는 것도 안심이 되었다.
안내서에는 다른 역(Türkismühle)에 내리는 경로를 더 추천하긴 했지만, 그 쪽은 역 주변에 대중 교통이 없다며 미리 택시를
예약하라고 되어 있었다.
귀찮았다. 뭐 얼마나 대단한 오지라고? 기차가 다니는 마을인데?
그냥 St. Wendel으로 내질렀다.</p>

<p>St. Wendel 역에 가까워질수록 분위기가 심상치 않다.
창밖에는 아무것도 안보인다. 컴컴하다.
사람들은 거의 다 내렸다. 내리기만 한다.
기차 안에는 나밖에 없다.
밤 9시 반쯤 역에 내리니 작은 마을이 보이지만, 사람은 보이지 않는다.
정류소는 있지만, 버스도 택시도 없다.
역앞 도로가 마을에서 제일 큰 길로 보이지만 드문드문 차가 지나갈 뿐이다.
작은 별의 어린왕자가 이런 삶이겠구나 싶다.</p>

<p>기다려도 오지 않는 택시를 포기하고 방법을 찾아 나서야 했다.
지나가는 가족이 있어 붙잡고 도움을 청해보았다.
고마운 독일인들은 흔쾌히 길가에 서서 직접 택시 회사도 알아봐주고 전화도 해주었지만 어디도 전화를 받지 않았다.
밤은 점점 깊어가고, 어디 호텔이라도 잡아서 다음날 가는 수 밖에 없다고 생각하던 차에
문 닫을 준비를 하는 술집이 보였다.
마지막 희망을 걸고 들어가 사정을 이야기했다.
영업을 마무리하던 친절한 독일 청년은 어딘가에 전화를 걸어서 한참 통화를 했다.
2분 후에 택시가 온다는 반가운 소식.
곧 산신령같은 외모를 지닌 할아버지 택시기사가 도착했고, 칠흑같은 산골짜기를 지나 닥스툴 성에 도착했다.
도착해보니 밤 11시 무렵. 다들 저녁을 먹고 숙소로 들어간 듯했고, 남아서 맥주를 마시던 두세명이 반갑게 맞아주었다.
합류해서 맥주 한 잔을 들이켰다.
평화가 물밀듯 밀려왔다.</p>

<p>그 밤의 고생이 당황스럽긴 했지만, 처음 며칠간 사람들과 안면을 트는 데에 유용한 이야깃거리로 쓰였다.
이야기를 들은 사람들의 반응은 한결같았다.
“아니 왜 택시 예약 안했어요?”
안내서에 예약 안하는 선택지도 있었으니까.
역시 선택지 많은게 항상 좋은 것은 아니다.</p>

<p>다음 번에 닥스툴로 가는 이들을 위해 명심 사항을 정리한다. 비슷한 고생이 없길 바란다.</p>
<ul>
  <li>독일 기차 앱을 미리 준비하여 예매. 프랑크푸르트 공항에서 기차표 파는 자판기만 있는데 찾기도 쓰기도 어려움.</li>
  <li>프랑크푸르트에서는 광역이 아니라 지역 기차를 타야하는데 길 찾기가 어려움. 지하철 아닌가 싶은 플랫폼으로 내려가서 타야함.</li>
  <li>택시는 미리 예약. 안내서에서 가장 추천하는 Türkismühle 역에서 내려서 예약한 택시를 타는 방법이 가장 안전.</li>
  <li>현금 충분히 준비. 택시는 카드가 안됨.</li>
  <li>세미나를 마치고 공항으로 돌아갈 때는 참가자들과 함께 갈 수 있도록 세미나 주최측에서 도와줌.</li>
</ul>

<table>
  <thead>
    <tr>
      <th style="text-align: center"><img src="https://lh3.googleusercontent.com/pw/AP1GczMp_oXFkSfc5NKCMHkFgingq4j6zZJK2npnK_Ji_Gr9wccowNNwq8TeMV9U7vCV2mspyLtJb2wK6HltZGZzPBpdECA0CasHuIOWZTb-hAtwQeYgvGd03UQ0WRLpzM2SEhHpEhhNFIu-SjMxRKOzUVDd=w1262-h1683-s-no?authuser=0" alt="" width="50%" /></th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td style="text-align: center"><b>우여곡절 끝에 밤늦게 도착한 닥스툴 성</b></td>
    </tr>
  </tbody>
</table>

<h2 id="닥스툴-성">닥스툴 성</h2>
<p>닥스툴 성은 1700년대에 지어진 오래된 성이다. 현재는 개조, 보수하여 전산학 세미나 센터로 사용되고 있다.
이 센터의 운영은 <a href="https://www.dagstuhl.de/en">라이프니츠 정보과학 연구소(Leibniz Center for Informatics)</a>에서 맡고 있다.
우리가 잘 아는 그 수학자 라이프니츠의 이름을 딴 기관이다.
이번에 가서 알았는데, 전산학자들의 많이 쓰는 서지 관리 시스템인 DBLP도 이 연구소에서 운영하고 있었다.
매 주 한두개 세미나가 일년 내내 열리는 듯 했다. 우리 세미나가 열린 주에도 다른 세미나가 동시에 진행되고 있었다.</p>

<p>독일 정부의 지원을 받아서 참가자들에게는 굉장히 저렴한 비용으로 숙식을 제공한다.
숙소는 대학 기숙사 같은 느낌인데, 소박했지만 불편함은 없었다.
식사도 성 안에 있는 식당에서 급식처럼 제공되었다.
독일의 가정식(혹은 독일 학생들의 급식)이 이런 것인가 싶은 느낌이었다.
그 이외에 물, 맥주, 와인, 과자 등은 언제든 각자 가져다 먹고 스스로 정산서에 기록한 후,
퇴실할 때 한꺼번에 계산하는 방식이었다.</p>

<p>닥스툴 성은 주변이 온통 숲과 산으로 둘러싸인 외진 곳에 위치해 있다.
주변 자연 경관이 좋을 것 같아서, 달리기를 해볼까 운동화를 챙겨갔지만 헛수고였다.
해가 너무 늦게 뜨고, 일찍 질 뿐더러, 건물 근처를 제외하고는 말그대로 칠흑같은 어둠이라서 나가 뛰어다닐 곳이 없었다.
봄이나 여름이었으면 어땠을지 궁금하다.</p>

<table>
  <thead>
    <tr>
      <th style="text-align: center"><img src="https://lh3.googleusercontent.com/pw/AP1GczPXLrI0k-DxLIFZBtJoyR6pU_NCPbKO7Bg3O3JBgfYurQcIHrmS6grp3hWIO1KJ4u8FEcpbN7nXlXkpa95kncr3Q1yJaLfMGEyD0FQf8ZjR7iPc8aSJOxnCEA6ykgS8-fFmiXB5Hjy6MbidxAwWdidk=w1262-h1683-s-no?authuser=0" alt="" width="75%" /></th>
      <th style="text-align: center"><img src="https://lh3.googleusercontent.com/pw/AP1GczNF00uJTaF-gfgunkZ19GvPAWtwnWIbfMTaMOgC8NuRRdjg0kAgF82cg9addXfEBXkNxvqp-xSOTznTBwL1WDNQgqICTRUKMRiD6GgVfEbQxM2cq5BpD7QjN9V3K6dqwQ7_n3dRMTabxqPXU8zmeRrC=w1262-h1683-s-no?authuser=0" alt="" width="75%" /></th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td style="text-align: center"><b>닥스툴 성</b></td>
      <td style="text-align: center"><b>하리보의 나라에 온것을 환영하는 침대</b></td>
    </tr>
  </tbody>
</table>
<table>
  <thead>
    <tr>
      <th style="text-align: center"><img src="https://lh3.googleusercontent.com/pw/AP1GczMbuvafDEkeUep7YrMmbnHj0Bm_UE5LHjssMfpiz4_V6NDpxKvQ05aE_qy6p_nfOH-2OsDdPh-vuequxxQ13cVqJlNVJz6vgKERTRXX0CmHsNCAbSxW-9r0xWuJ-IS1mQTuz97cGqw-pfrmWOT9tnGc=w1670-h1253-s-no?authuser=0" alt="" width="75%" /></th>
      <th style="text-align: center"><img src="https://lh3.googleusercontent.com/pw/AP1GczPAlhIrKQKFot49rR-JOJyARlH8F7DYMP3Q1GIaKH6BYfSmmhYy4MdOzMHS5Cgr3F-zvWgQJBWJCDeMCM3qwbUrzAq2m3KlZP8GAIIewloUlnUG6uoKXxH3XJIWDJAr4vMCMfvLJQBi5YKaI5gTTC5l=w1262-h1683-s-no?authuser=0" alt="" width="75%" /></th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td style="text-align: center"><b>독일 가정식 같았던 음식</b></td>
      <td style="text-align: center"><b>무인매장식 운영</b></td>
    </tr>
  </tbody>
</table>

<h2 id="세미나-개요">세미나 개요</h2>
<p>우리 세미나는 월요일 아침부터 금요일 점심까지, 매일 오전 9시부터 오후 6시까지 밀도있게 진행되었다.
참가자들의 연령대도 다양했다. 70년대에 박사학위를 받은 분부터, 지금 박사과정에 있는 학생까지. 50년 세월이 모였다.
각 참가자들이 20-30분 정도로 각자 발표하는 것 이외에도, 여러 주제에 관해 토론하는 시간이 많았다.
무작위로 조를 짜서 특정 주제에 관해 토론하는 시간,
이론팀(theory)과 현실팀(practice)으로 나누어 상대팀 사람들과 한명당 10분씩 이야기하는 스피드 데이트 시간을
통해서 참가자들의 연구 방향과 서로 다른 시각을 엿볼 수 있었다.
또한, 매 식사 시간에는 각 식탁에 참가자들이 무작위로 배치되기 때문에 자연스럽게 여러 사람들과 교류할 수 있었다.
매일 저녁에는 맥주와 치즈가 제공되었고, 탁구, 당구, 다트, 보드게임 등으로 즐거운 시간을 보냈다.</p>

<table>
  <thead>
    <tr>
      <th style="text-align: center"><img src="https://lh3.googleusercontent.com/pw/AP1GczPCFWFxtXBnTQGyPUnz6dD1VZ6m0EIobdFum7s13oykf0NJ3kgibU2vUyXllt3X0bjzn0lkoExK09xfRHUzMBFKkhT-UeazsxyuT0vQL4yWyzNSus-WA7XGQP6ej8Ic87Tio9Hf1YywTNLtiAo76GF2=w1262-h1683-s-no?authuser=0" alt="" width="50%" /></th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td style="text-align: center"><b>참가자들이 선정한 토론 주제 후보. 정적 분석 분야의 오랜 문제와 새로운 문제가 모두 모였다.</b></td>
    </tr>
  </tbody>
</table>

<h2 id="지향성-프로그램-분석-의심에서-확신으로directed-program-analysis-from-suspicion-to-witness">지향성 프로그램 분석: 의심에서 확신으로(Directed Program Analysis: from Suspicion to Witness)</h2>

<p>초대장에 적힌 세미나 취지를 읽고는 반가웠다.
같은 고민을 하던 우리 연구실의 연구 방향과도 결이 맞았다.
우리가 하고 있는 일을 소개할 좋은 발표 제목을 생각하다가
위와 같은 제목을 골랐다.
기존 정적 분석이 오류 의심에서 멈추었다면, 우리는 의심을 뛰어넘어 확신에 이르는 결론을 내놓겠다는 포부였다.
긴 여정의 마지막날 마지막 발표 순서인 것이 아쉬웠지만, 그래도 많은 사람들이 관심을 가졌고 여러 질문이 이어졌다.
발표 슬라이드는 <a href="https://kihongheo.kaist.ac.kr/slides/dagstuhl25421.pdf">여기</a>에서 볼 수 있다.</p>

<p>앞서 언급한 허위 경보 문제는 정적 분석이 안고 있는 근본적인 숙제이다.
오랜 시간 동안 수많은 연구자들이 여러 접근법을 시도해왔다. 크게 세 가지 방향으로 나누어 볼 수 있다.</p>
<ol>
  <li>안전성을 유지한 채 더욱 정교한 분석을 설계하여 허위 경보를 줄이려는 방향. 정교한 분석을 현실적인 비용으로 실현하는 것이 관건.</li>
  <li>안전성을 포기하고 허위 경보를 줄이려는 방향. 안전성을 포기하면서도 놓치는 오류가 적은 분석을 설계하는 것이 관건.</li>
  <li>안전성을 유지하되, 사용자를 위해 분석 결과를 후처리하는 방향. 후처리의 정교함과 효율성, 설명가능성이 관건.</li>
</ol>

<p>세 가지 방향 모두가 현실에서 매우 중요하다.
나같은 경우, 박사 과정 중에는 1번과 2번 방향을 주로 연구했고, 졸업후 지금까지는 3번 방향을 주로 연구하고 있다.
발표 주제도 그래서 3번 방향에 초점을 맞추었다.
마침 조별 토론의 주제 중에도 이 방향과 밀접한 “정적 분석 결과의 설명가능성(사용자 편의성)”이 있었다.
토론보다 내 발표가 먼저 있었으면 좋았겠지만, 발표 홍보 기회로 삼기로 했다.
토론 과정에 나온 내용에 맞게 발표 내용을 일부 보완하기도 했다.</p>

<p>조별 토론의 초점은 어떻게 하면 일반 개발자(정적분석 비전문가)에게 정적 분석 결과를 잘 설명할 수 있겠냐는 것이었다.
정적 분석기의 동작이 프로그램의 실행 과정과 다른 경우가 많기 때문에, 일반 개발자들이 결과를 이해하기 어려워하는 경우가 많다.
또한, 반대로 개발자들이 분석결과를 검토하면서 내린 결론(예: 오류 진위 여부)을 다시 분석기가 이해하도록 만드는 것도
중요하다.
이 문제를 해결하기 위해서, 우리 연구실에서는 개발자와 분석기가 손쉽게 상호작용하는 알람 랭킹 시스템을 연구한 적이 있다.
이 시스템은 정적 분석 결과로 나온 오류 후보 지점을 의심도 순으로 정렬하여 개발자에게 편의를 제공하고, 개발자가
검토한 결과를 다시 분석기에 반영할 수 있게 한다.
분석 결과에 관한 자세한 설명은 없지만, 적어도 의심도 순으로 정렬된 목록을 제공한다는 점에서 유용하다.
이를 이용하면 여러 오류 의심 지점이 존재할 때, 고효율 저비용으로 주어진 시간안에 많은 오류를 찾아낼 수 있다.
하지만, 여전히 개별 오류 의심 지점에 대한 설명가능성 문제는 남아 있었다.</p>

<p>반면, 이 발표에서는 어떻게하면 설명을 잘할 것인지가 아니라, 어떻게하면 설명을 안해도 되는지를 이야기하고 싶었다.
의심스러운 오류 후보 지점을 개발자에게 그냥 전달하는 대신, 실제 오류를 증명하는 증거(즉, 오류 유발 입력)를
잘 찾는 방법을 소개하고자 했다.
개발자에게 오류 유발 입력보다 더 좋은 설명은 없기 때문이다.
이를 실현하고자 하는 것이 이른바 지향성 프로그램 분석(Directed Program Analysis)이다.
정적 분석기가 오류 의심 지점을 찾아내면,
각 오류 의심 지점 별로, 해당 지점에서 발생하는 실제 오류 유발 입력을 효과적으로 찾는 기술이다.
이러한 입력을 효과적으로 찾으려면, 정적 분석기가 오류 의심 지점을 찾을 때 사용한 내부 정보를 잘 활용해야 한다.
하지만 이러한 과정은 개발자에게 직접 드러나지는 않고, 오직 마지막에 도출된 오류 유발 입력만이 개발자에게 전달된다.
“확실하지 않으면 승부를 걸지 말라”는 영화 <타짜>의 격언과 맞닿아 있다.</타짜></p>

<p>발표에서는 이러한 지향성 프로그램 분석의 개념과 연구실에서 개발한 세 가지 적용 사례를 소개했다.
아이디어도 재미있어 했지만, 현실 세계에서 널리 쓰이는 SW에 있는 실제 오류를 찾아냈다는 점에서
관심을 많이 받았다.
연구실 학생들이 이루어낸 성과가 자랑스러웠다.
발표에서 소개한 각 사례는 다음과 같고, 구체적인 이야기는 해당 링크에서 살펴볼 수 있다.</p>
<ul>
  <li><a href="http://prosys.kaist.ac.kr/dafl-story">응용 프로그램의 메모리 오류 탐지</a></li>
  <li><a href="http://prosys.kaist.ac.kr/sky-and-star">라이브러리 프로그램의 비정상적 예외 상황 탐지</a></li>
  <li><a href="http://prosys.kaist.ac.kr/high-and-far">컴파일러의 잘못된 최적화 오류 탐지</a></li>
</ul>

<table>
  <thead>
    <tr>
      <th style="text-align: center"><img src="https://lh3.googleusercontent.com/pw/AP1GczNn1Lmczlrv2rYi4CYxhJAK7vH-4GEZehLH2T8Yp8b3o85954ZeJaJu2vr895mK3RKFHY-isW2OJyH9QUwKpaWDx9f0VfcoMA6U1fE8xCK23A6gBTSUz_4cx05oi2GfYrbuaio3Igpq50rHfnGV4Q5W=w1310-h983-s-no?authuser=0" alt="" width="70%" /></th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td style="text-align: center"><b>마지막 날 마지막 발표 중</b></td>
    </tr>
  </tbody>
</table>

<h2 id="기록정신">기록정신</h2>
<p>닥스툴 세미나의 운영에서 매우 인상적이었던 점은 기록정신이었다.
세미나 기간 동안 모든 발표와 토론 내용은 함께 기록했다.
각 발표자는 발표 전후로 요약문을 공책에 직접 기록했고, 세미나 후에는 웹 시스템에 올려서 공유했다.
토론시에도 각 조별로 중요한 논의 내용을 기록하여 전체와 공유했다.
이러한 내용은 세미나가 끝난후 정식으로 웹에 출판되어 누구나 열람할 수 있다.
역대 모든 세미나의 자료는 <a href="https://drops.dagstuhl.de/entities/journal/DagRep">여기</a>에서 볼 수 있다.
좋은 말씀은 누구나 쉽게 접할 수 있도록 널리 퍼트리자는 정신.
역시 구텐베르크의 나라답다.
이 글을 쓰는 시점에는 아직 우리 세미나의 자료가 올라오지 않았지만, 최근에 참가자들의 메일링 리스트를 통해
최종본의 의견을 수렴하는 절차가 진행 중인 것으로 보아 머지 않아 올라올 것으로 보인다.</p>

<p>이 외에도, 여러 방면으로 참가자들의 흔적을 오래된 성에 새겨넣었다.
모든 참가자들은 방명록에 자필로 서명을 남겼다.
또한 도서관에는 각 참가자들이 직접 집필한 책을 비치해놓고 저자에게 직접 한마디씩 남기도록 했다.
우리 세미나 참가자들이 쓴 책도 도서관 입구의 작은 책장에 비치되어 있었다.
물어보니 지난 번에 참석했을 때 남겨놓았다는 사람들이 있었다.
도서관에는 제법 책이 많았는데, 그 작은 입구 책장에 우리 세미나 참석자의 책이 여러권 꽂혀 있는 것으로 보아,
아마 각 세미나 때마다 참가자들의 저작을 입구에 비치해놓는 것 같다.</p>

<p>이러한 기록정신은 참석자들의 가슴에 은은한 모닥불을 지피는 듯 했다.
우리가 나눈 이야기가 이 성처럼 오래도록 남을 것이라는 생각.
우리의 토론과 참여가 존중받고 지원받는다는 느낌.
그런 이유로 여기에 있는 일주일을 더 알차게 보내야겠다는 책임감.
마지막 날 밤 이야기를 나누어보니 나만 든 생각은 아니었다.</p>

<table>
  <thead>
    <tr>
      <th style="text-align: center"><img src="https://lh3.googleusercontent.com/pw/AP1GczOEbmgeUiQfXN1HqyViyW6Lck7t1Rkq2D5TDHpenMWIXrJ82PFN8MuacYb7s4lNF7I4wHuLTCZfbniy5Y9KiNZuJq44qB4Bzo7UthwRNTx6Riq9ZSsVsWXzZo4EsM4TRFZzkvXH3jjHK8zSu-da-Ubp=w1262-h1683-s-no?authuser=0" alt="" width="100%" /></th>
      <th style="text-align: center"><img src="https://lh3.googleusercontent.com/pw/AP1GczOXcQJbS8iAOA_aEYi1sf5D795ETkyxu08KuBQSq5-GxATB5n051v8cTXEUTv3IO4Wq9Xd6SWfPkdui0aQX2_072WeAc_f0xRdFp4fSbkWUcG10sNO7-4MPYycDsDklL9QpxWrVmeT0heKefvPGWLty=w1262-h1683-s-no?authuser=0" alt="" width="100%" /></th>
      <th style="text-align: center"><img src="https://lh3.googleusercontent.com/pw/AP1GczPufA709WlUGEXrPRGruE5e2gX71wCLf54PuOkQkxof4Rorrs9TBnt2mFk9NWJVHM6uF-qXTY0uJQTur4v7zwpqz5MXf6OTdYjEO1wfF-C7TLffpJ1AJloymfl_TBRk0ZPb1MDTErjc9XSeox4DjLgx=w1262-h1683-s-no?authuser=0" alt="" width="100%" /></th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td style="text-align: center"><b>모든 발표자들은 발표 요약이 담긴 책</b></td>
      <td style="text-align: center"><b>내 발표 요약문</b></td>
      <td style="text-align: center"><b>참석자들의 저작물</b></td>
    </tr>
  </tbody>
</table>

<h2 id="마무리">마무리</h2>
<p>잊고 있던 구석의 감각이 근질근질해지는 일주일이었다.
학생때부터 논문으로 만나던 선배 연구자들 그리고 오랜만에 만난 또래 친구들.
이해하고자 곱씹기를 반복했던 그 때 그 아이디어, 예제, 수식.
기억 저편에 있던 논문 제목.
대학생 시절 처음 홀로 떠난 여행지였던 독일.
내재된 많은 기억이 하나둘 떠오르며 귀국 길, 다시 흥겨운 먼 길을 재촉했다.
중세 판타지 영화 세트장 같은 세미나 장소도 묘한 분위기를 더했다.
그 분위기가 익숙할 유럽인들에게는 어떤 느낌일지 모르겠지만.
칼과 마법으로 용을 잡으러 떠나던 그 세계 사람들과, 과학을 연구하는 우리는 닮은 점이 많지 않은가.
여태껏 알지 못했던 세상의 비밀을 캐낸다는 것,
감당하기 어려운 거대한 것에 맞선다는 것,
같은 뜻을 품은 동료들과 힘을 합친다는 것.</p>

<table>
  <thead>
    <tr>
      <th style="text-align: center"><img src="https://lh3.googleusercontent.com/pw/AP1GczMsycGj9gfmyL3fN-Qs9yY-wZZGvUiFjf2lBLL5VFs22rwEps5J36-NhVw3GaM-joLo6vqobOC33Fe7VR-oHzWBR0zLjoUDQDbDpgBbP0h5Hnomrvz0rIe1XMGgTSnTMi5wNaXNW0I47nH3wU9bCDqJ=w1670-h1253-s-no?authuser=0" alt="" /></th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td style="text-align: center"><b>유구한 역사와 전통을 지닌 닥스툴 세미나의 단체사진</b></td>
    </tr>
  </tbody>
</table>]]></content><author><name>허기홍</name></author><category term="정적분석" /><category term="소프트웨어공학" /><category term="프로그래밍언어" /><category term="Dagstuhl Seminar" /><summary type="html"><![CDATA[들어가며 “시대정신”이라는 말이 있다. 특정한 시대에 큰 영향을 끼치는 중요한 가치를 일컫는다고 한다. 독일의 철학자 헤겔이 그 개념을 처음 고안한 이래 지금까지 이어져 매 선거철이면 우리 귀를 자주 간지럽힌다.]]></summary></entry><entry><title type="html">Optimuzz: 안전한 컴파일러를 위한 오번역 자동 탐지 기술</title><link href="http://prosys.kaist.ac.kr/optimuzz/" rel="alternate" type="text/html" title="Optimuzz: 안전한 컴파일러를 위한 오번역 자동 탐지 기술" /><published>2025-10-15T00:00:00+00:00</published><updated>2025-10-15T00:00:00+00:00</updated><id>http://prosys.kaist.ac.kr/optimuzz</id><content type="html" xml:base="http://prosys.kaist.ac.kr/optimuzz/"><![CDATA[]]></content><author><name>장봉준</name></author><category term="Research" /><summary type="html"><![CDATA[]]></summary></entry><entry><title type="html">몰입을 위한 약속</title><link href="http://prosys.kaist.ac.kr/engagement/" rel="alternate" type="text/html" title="몰입을 위한 약속" /><published>2025-09-30T00:00:00+00:00</published><updated>2025-09-30T00:00:00+00:00</updated><id>http://prosys.kaist.ac.kr/engagement</id><content type="html" xml:base="http://prosys.kaist.ac.kr/engagement/"><![CDATA[<p>이번 학기에 강의하는 과목의 <a href="https://github.com/prosyslab-classroom/cs424-program-reasoning"> 소개 페이지</a>에 아래와 같은 문구를 추가했다.</p>
<blockquote>
  <p>몰입을 위한 약속</p>

  <p>모두가 몰입하는 강의를 위해 모든 전자기기(노트북, 타블릿, 핸드폰)는 책상위에 올려놓지 않기로 합시다.
수업 중 전자기기를 사용하는 것이 끼치는 악영향은 이미 널리 알려져 있습니다.
본인의 주의를 산만하게 할 뿐만 아니라 주변 사람들이 수업에 집중하는데도 큰 방해가 됩니다.
모두가 각자 따로 모니터를 보기 보다는 함께 같은 곳을 보며 왁자지껄 난상토론하는 수업이 되길 바랍니다.
필요한 자료는 이 저장소에 있으니 원한다면 미리 인쇄를 해서 오세요.</p>
</blockquote>

<p>오랜 생각이었는데, 지난 방학 때 주위 사람들이 불을 붙여주었다.
학부 교수님들에게 이 생각과 필요성을 공유했더니 공감하는 분들이 많았다.
몇 분들은 이번 학기부터 같은 방식으로 수업을 운영하고 계신다고 한다.</p>

<p>우리 학부의 이러한 움직임이 소문이 났는지, 카이스트 신문에서 인터뷰 요청이 왔다.
이참에 학교 전체에 널리 화두를 던져 보면 좋겠다는 생각에 기쁘게 응했다.
해당 <a href="https://times.kaist.ac.kr/news/articleView.html?idxno=22470">기사</a>가 최근 실렸다.
기자님이 “기술은 항상 이로운가?” 라는 제목을 붙여주었는데, 아주 딱 맞는 제목이다.</p>

<p>지면 제한상 담지 못한 인터뷰 전문을 아래에 싣는다. 기사에는 생략된 인용 자료와 세세한 경험이 담겨있다.</p>

<hr />

<h3 id="먼저-간단한-소개를-부탁드립니다">먼저 간단한 소개를 부탁드립니다.</h3>

<p>안녕하세요. 전산학부에서 학생들을 가르치는 허기홍입니다. 이번 학기에는 <프로그램논증>이라는 과목을 가르치고 있습니다.</프로그램논증></p>

<h3 id="이번-학기부터-수업에서-전자기기-사용을-제한하기로-결정하신-가장-큰-이유는-무엇인가요">이번 학기부터 수업에서 전자기기 사용을 제한하기로 결정하신 가장 큰 이유는 무엇인가요?</h3>
<p>학생들에게 제대로 몰입하는 즐거움을 알려주고 싶었습니다.
더구나 혼자가 아니라 함께 말이지요.
모두가 한 곳을 바라보고 같은 생각에 골몰할 때 피어나는 에너지는 엄청납니다.
밴드의 연주가 합이 맞을 때, 축구장의 응원 소리가 공명할 때를 생각해보시면 될겁니다.
끓어오르는 무언가가 있지요. 수업에서도 전자기기로 분산되던 에너지를 한데 모아보고 싶어서 이런 결정을 했습니다.</p>

<p>이러한 생각을 한 지는 오래 되었습니다만 최근에 방아쇠가 당겨졌습니다.
저희 연구실 학생과 우리 학부 동료 교수님을 통해서 접한 한 <a href="https://www.sciencedirect.com/science/article/pii/S0360131512002254?via%3Dihub">연구 논문</a> 때문입니다 <sup id="fnref:1" role="doc-noteref"><a href="#fn:1" class="footnote" rel="footnote">1</a></sup>.
수업시간에 전자기기를 사용하는 것이 (당연히) 사용자의 주의를 산만하게 할 뿐만 아니라,
주변 학생들에게도 악영향을 미친다는 연구결과였습니다.
이리저리 움직이는 화면, 타자치는 소리가 주변 학생들에게 방해가 되는 것이죠. 마치 간접 흡연 같더라고요.
더 알아보고 싶어서 인터넷을 뒤지다가 펜실베니아 대학의 한 교수님이 쓰신 경험담도 우연히 접했습니다 <sup id="fnref:2" role="doc-noteref"><a href="#fn:2" class="footnote" rel="footnote">2</a></sup>.
단순히 전자기기 사용을 제한하는 것 만으로도 수업 분위기가 눈에 띄게 좋아졌다는 이야기였습니다.</p>

<p>결심이 굳어졌지요. 나만 알지 말고 널리 퍼트려야겠다 싶어서 주위 여러 교수님들께 공유했습니다.
공감하시는 여러 교수님들께서 이번 학기부터 같은 방식으로 수업을 운영하고 있는 것으로 알고 있습니다.</p>

<h3 id="이러한-결정을-내리기-전에-학생들의-전자기기-사용으로-인해-직접-목격하신-문제점들이-있으셨나요-구체적인-사례를-말씀해주실-수-있나요">이러한 결정을 내리기 전에 학생들의 전자기기 사용으로 인해 직접 목격하신 문제점들이 있으셨나요? 구체적인 사례를 말씀해주실 수 있나요?</h3>
<p>노트북 같은 전자기기를 켜놓고 수업을 듣는 학생들이 제대로 집중을 못하는 상황은 아주 흔하죠.
화면을 보고 타자를 치며 씽긋이 미소짓는 학생들은 수업을 하다보면 자주 보입니다.
제가 만든 강의 자료가 그렇게 재미있을리가 없다는 건 제가 잘 아는데 말입니다.
저는 수업시간에 학생들에게 질문을 많이 하는데요.
예를 들어 “여기서 x의 값은 무엇이라고 생각하세요?”, “이 상황에서 가능한 해결책은 뭐가 있을까요?” 같은 것들입니다.
대답이 어려울 때는 간혹 있지만 질문 자체는 쉬운 경우가 대부분입니다.
그런데 간혹 돌아오는 대답이 당황스러울 때가 많습니다.
“아, 제가 질문을 잘 이해 못했습니다.” 주로 전자기기를 들여다보는 학생들이 그런 경우가 많았지요.</p>

<h3 id="전자기기-사용을-제한한-후-수업-분위기나-학생들의-참여도에-변화를-느끼셨나요-특히-교수님께-질문하는-학생들이-더-많아졌는지-궁금합니다">전자기기 사용을 제한한 후 수업 분위기나 학생들의 참여도에 변화를 느끼셨나요? 특히, 교수님께 질문하는 학생들이 더 많아졌는지 궁금합니다.</h3>
<p>변화를 많이 느끼고 있습니다. 학생들의 눈빛이 날카롭습니다. 제가 하는 수업은 전통적인 강의 중심 수업입니다. 하지만 단순, 일방적인 강의가 되지 않게끔 학생들과 소통을 많이 하는 편인데요. 질문과 답변의 수준이 예년에 비해 확실히 높습니다. 몇 년동안 쓰던 강의자료에서 틀린 부분을 집어 내는 학생도 있었고요. 예년과 비슷한 수준으로 학생들과 소통을 해도, 학생들의 이해도가 높아서 수업 진도가 더 빨라졌습니다.</p>

<h3 id="보내주신-기사에서는-이-정책의-장점으로-필기가-학생들의-이해를-돕는다는-점을-꼽았습니다-필기를-하는-학생들이-많이-있는지-궁금합니다">보내주신 기사에서는 이 정책의 장점으로 필기가 학생들의 이해를 돕는다는 점을 꼽았습니다. 필기를 하는 학생들이 많이 있는지 궁금합니다.</h3>
<p>네. 많은 학생들이 필기를 하면서 수업을 듣고 있습니다.</p>

<h3 id="학생들의-반응은-어떤가요-반대-의견이나-불편함을-표현한-학생들이-있었나요-현재-학생들은-이-정책을-어떻게-받아들이고-있나요-적응-과정은-어떠했나요">학생들의 반응은 어떤가요? 반대 의견이나 불편함을 표현한 학생들이 있었나요? 현재 학생들은 이 정책을 어떻게 받아들이고 있나요? 적응 과정은 어떠했나요?</h3>
<p>반응이라고 할 게 없습니다.
불편함을 이야기하는 학생도 없었고요.
첫시간에 제가 취지를 설명했고 모두들 고맙게도 잘 따라주고 있습니다.
그도 그럴 것이 딱히 새로운 것은 없잖아요?
우리는 어릴 때부터 이렇게 칠판 보면서, 선생님 눈 보면서, 공책에 써가면서 공부했듯이.
그냥 하던대로 하는 거니까 불편한 것은 없지요.</p>

<h3 id="수업-중-전자기기-사용-제한을-어떤-방식으로-시행하고-계신가요">수업 중 전자기기 사용 제한을 어떤 방식으로 시행하고 계신가요?</h3>
<p>책상 위에는 전자기기를 올려 놓지 말기로 약속을 했습니다.</p>

<h3 id="이러한-방식으로-수업을-진행하기-위해서는-수업을-위해-추가적인-준비가-필요할-수도-있겠다는-생각이-듭니다-그러한-예시가-있나요-긴급상황이나-특별한-사유가-있는-경우에-대한-예외-규정이-있나요">이러한 방식으로 수업을 진행하기 위해서는 수업을 위해 추가적인 준비가 필요할 수도 있겠다는 생각이 듭니다. 그러한 예시가 있나요? 긴급상황이나 특별한 사유가 있는 경우에 대한 예외 규정이 있나요?</h3>
<p>추가 준비가 필요하지는 않습니다. 늘 하던대로 하는 것이지요.
제 강의 자료는 다 공개되어 있으니 원하는 학생은 인쇄를 해와도 되고요.
특별한 사유나 긴급 상황이라는게 어떤게 있을까요?
영화관이나 콘서트장을 생각해보면 됩니다.
그런 장소에서는 모두의 몰입을 위해 핸드폰을 켜지 않는 것이 예의라는 것을 우리 사회가 합의했죠.
그런데 공연 중에 긴급 상황이 벌어지면 어떻게 하나요?
주위 사람들에게 양해를 구하고 나가서 일을 처리하면 되지요.
이러한 것은 수업시간 전자기기 제한과 상관없이 늘 있는 일이라서 특별할 것은 없습니다.</p>

<h3 id="전자기기를-교육적으로-활용할-수-있는-순기능도-있을-것인데-이러한-부분을-포기하는-것에-대한-아쉬움은-없으신가요">전자기기를 교육적으로 활용할 수 있는 순기능도 있을 것인데, 이러한 부분을 포기하는 것에 대한 아쉬움은 없으신가요?</h3>
<p>전자기기를 활용해서 하는 수업이라면 당연히 순기능을 잘 활용해야지요.
하지만 제 수업은 강의식 수업이라서 전자기기가 도움이 되는 경우는 떠올리기가 어렵습니다.
저도 과거에 수업을 들을 때나 학회 발표를 들을 때 도움이 될까하여 노트북을 가지고 가본 적이 있는데요.
늘 도움이 안되는 것을 깨닫고는 그 뒤로 가져가지 않습니다.</p>

<p>인간의 뇌가 멀티태스킹에 약하다는 것은 많은 뇌과학자들이 지적하는 바입니다.
현대에 들어 아무리 전자기기에 익숙해진 우리라고 해도, 수백만년을 흘러온 물길이 하루 아침에 바뀌지는 않으니까요.</p>

<h3 id="이-정책을-다른-수업이나-다른-교수님들께도-권하고-싶으신가요-그-이유는-무엇인가요">이 정책을 다른 수업이나 다른 교수님들께도 권하고 싶으신가요? 그 이유는 무엇인가요?</h3>
<p>네. 종이를 뚫을 것 같은 학생들의 눈빛을 마주하는 수업이 매우 즐겁습니다.
맞닿는 시선을 가로막는 전자기기를 걷어내니 더 깊은 이해로 빠져듭니다. 모든 교수님들께 권합니다.</p>

<h3 id="앞으로도-이-정책을-지속적으로-유지하실-계획인가요">앞으로도 이 정책을 지속적으로 유지하실 계획인가요?</h3>
<p>네.</p>

<h3 id="마지막으로-교수님의-정책에-대해-학생들에게-전하고-싶은-메시지가-있으신가요">마지막으로 교수님의 정책에 대해 학생들에게 전하고 싶은 메시지가 있으신가요?</h3>
<p>정책이라고까지 말하기에는 너무 거창합니다.
대신 제 수업에서는 “몰입을 위한 약속”이라고 부릅니다.
전자기기 바깥, 현실의 무언가에 한 번 몰입해 보시죠.
그리고 주위에 비슷한 몰입을 하는 사람들과 공명해 보시죠.
무언가 느껴질겁니다. 전기줄과 전자기파를 통해서는 전달되지 않는 무언가가요.</p>
<div class="footnotes" role="doc-endnotes">
  <ol>
    <li id="fn:1" role="doc-endnote">
      <p>Sana et al., Laptop multitasking hinders classroom learning for both users and nearby peers, Computers &amp; Education, 2013. <a href="#fnref:1" class="reversefootnote" role="doc-backlink">&#8617;</a></p>
    </li>
    <li id="fn:2" role="doc-endnote">
      <p><a href="https://www.nytimes.com/2025/08/21/opinion/mobile-phones-college-classrooms.html">https://www.nytimes.com/2025/08/21/opinion/mobile-phones-college-classrooms.html</a> <a href="#fnref:2" class="reversefootnote" role="doc-backlink">&#8617;</a></p>
    </li>
  </ol>
</div>]]></content><author><name>허기홍</name></author><category term="수업" /><summary type="html"><![CDATA[이번 학기에 강의하는 과목의 소개 페이지에 아래와 같은 문구를 추가했다. 몰입을 위한 약속 모두가 몰입하는 강의를 위해 모든 전자기기(노트북, 타블릿, 핸드폰)는 책상위에 올려놓지 않기로 합시다. 수업 중 전자기기를 사용하는 것이 끼치는 악영향은 이미 널리 알려져 있습니다. 본인의 주의를 산만하게 할 뿐만 아니라 주변 사람들이 수업에 집중하는데도 큰 방해가 됩니다. 모두가 각자 따로 모니터를 보기 보다는 함께 같은 곳을 보며 왁자지껄 난상토론하는 수업이 되길 바랍니다. 필요한 자료는 이 저장소에 있으니 원한다면 미리 인쇄를 해서 오세요.]]></summary></entry><entry><title type="html">두 번 가서 배로 좋은 PLDI와 FSE 여행기</title><link href="http://prosys.kaist.ac.kr/sujin-trip-pldifse25/" rel="alternate" type="text/html" title="두 번 가서 배로 좋은 PLDI와 FSE 여행기" /><published>2025-07-28T00:00:00+00:00</published><updated>2025-07-28T00:00:00+00:00</updated><id>http://prosys.kaist.ac.kr/sujin-trip-pldifse25</id><content type="html" xml:base="http://prosys.kaist.ac.kr/sujin-trip-pldifse25/"><![CDATA[<h1 id="들어가며">들어가며</h1>
<p>PL 분야의 큰 학회인 PLDI가 6월 16일부터 20일까지, SE 분야의 큰 학회인 FSE가 6월 23일부터 25일까지 각각 서울과 노르웨이 Trondheim 에서 열렸다.</p>

<p>같은 연구실의 봉준님의 논문이 PLDI 2025에 채택되어 기쁜 마음으로 응원가는 겸, PLDI SRC 2025에 제출했던 내 논문도 채택되어 포스터 발표를 하기 위해 PLDI에 참석하였다.
그리고 연희님, 그리고 지금은 군대를 가신 희원님과 열심히 작성했던 논문이 FSE 2025에 채택되어 학회에 참석하게 되었다.</p>

<p><br /></p>

<h1 id="616-mon">6/16 (Mon.)</h1>
<p>PLDI의 주요 발표들은 수요일부터 이루어졌지만, 교수님의 전폭적인 지원으로 워크샵부터 참여할 수 있는 기회가 주어졌다.
아침 5시 반부터 이동하며 약간 피곤함을 느꼈지만, 최신 프로그램 분석 분야의 논문 발표를 들으면서 학회에 왔다는 것을 실감하기 시작했다.</p>

<p>그리고 맛있는 점심 도시락은 잠을 확실하게 깨워주었다.</p>

<table>
  <thead>
    <tr>
      <th style="text-align: center"><img src="https://lh3.googleusercontent.com/pw/AP1GczM4uZ2boNfNROOOtOCD7nUhyPUxtq69rvQVCu1N2EpXTV5RIT2N52-wd3_zfP-59hRZD2Q62_Frkad4Nsk_F2C_7eTd507Y0oFBpjnB_-BnpMW0KehO19_pfBGczg3-xD5pM_sTznCp_jPHD_DuxYDK=w1230-h923-s-no-gm?authuser=0" alt="" /></th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td style="text-align: center"><b>비싸고 맛있는 도시락</b></td>
    </tr>
  </tbody>
</table>

<p><br /></p>

<p>오후 2시부터는 PLMW라는 학생 연구자들을 위한 친목(?) 활동과 교수님들의 다양한 조언을 들을 수 있는 워크샵에 참석하였다.
친목 활동 중 하나로는 관심 분야의 사람들끼리 조를 짜고 대화하는 활동이 있었는데, 프로그램 합성 분야는 학생 연구자들의 관심이 많이 줄은 것인지 조가 따로 만들어지지 않았다.
그래서 방황하다 타입 시스템 분야에 가서 사람들과 이야기를 나누었다.
간단한 자기소개를 하면서 이야기를 시작했는데, 내가 명찰에 대학원생이라고만 적어두었더니 석사인지 박사인지를 다들 궁금해했다.
그래서 다음부턴 학위 과정을 명확히 써야겠다는 생각이 들었다.</p>

<table>
  <thead>
    <tr>
      <th style="text-align: center"><img src="https://lh3.googleusercontent.com/pw/AP1GczMIlJKnBtl_IIHB_7klN0XKnLP_WveyMaX99UuSCJVa7NeIU7TgswrNKiLmnrh_Cy43soVoGMpTtP8ZUJJZlZydAwPItFijCRw7HEyeHasxEsFTEf15YwU5SzwAUyFsmfamkQ6XSLquKYV-q-luqTZa=w693-h923-s-no-gm?authuser=0" alt="" /></th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td style="text-align: center"><b>다음부턴 박사과정이라고 적자!</b></td>
    </tr>
  </tbody>
</table>

<p><br /></p>

<p>다들 왜 이 조로 왔는지를 이야기 했고, 나는 다른 연구를 하는데 배우고 싶어서 왔다고 이야기 했더니 내 연구에 대해 더 궁금해하여 설명하게 되었다.
그리고 결국 타입 시스템 연구에 대해서는 많이 듣지 못한 채 세션 시간이 끝나 나오게 되었다.
그래도 수요일에 포스터 발표를 한다고 홍보도 하였고, 그때 자리에 함께 있었던 한분이 실제로 포스터를 구경 오시기도 하였다. :&gt;</p>

<p><br /></p>

<h1 id="617-tue">6/17 (Tue.)</h1>
<p>교수님들의 강연으로 PLMW 세션이 가득 채워져있었고, 하루 종일 발표를 들었다.
교수님들은 대학원생 때부터 현재까지 학계에 있으면서 겪은 다양한 경험들을 공유해주셨고, 필드에서 쓰일 수 있는 연구를 하는 게 중요하다는 것을 거듭 강조하셨다.
제안서를 쓸 때도 중요하지만, 회사에 기술을 넘기는 것까지 많은 교수님들이 생각하고 계신 것 같았다.
“지치지 않고 문제를 찾는 것, 그리고 그 문제를 잘 푸는 것” 말은 너무 쉽지만 실행하기는 쉽지 않은게 인생과 참 비슷하다는 생각이 들었다.
어쩌면 연구는 인생을 더 잘 살아가는 방법을 찾는 과정을 배우는 것인지도 모르겠다는 생각도 들었다.</p>

<p>저녁에는 리셉션이 있었고, 비어있는 테이블이 있어 신나하며 자리를 잡았더니 많은(?) 사람들이 인사를 하며 대화를 하러 왔었다.
한번은 교수님과 같이 프로그램 분석 분야 연구의 미래에 대해 이야기를 하고 있었는데, Yizhou Zhang 교수님이 다가오셨다.
Zhang 교수님은 당일 PLMW 에서 발표를 하셨어서 기억하고 있었고, 발표를 들었다는 것을 어필하며 내 연구에 대해서도 간단하게 설명드릴 수 있었다.
간단한 연구 설명만을 준비했어서 조금만 더 궁금해해도 설명하기가 조금 어려웠는데, 여러 번 반복하다보니 더 나중에 만난 사람들에게는 더 잘 설명할 수 있게 된 것 같았다.</p>

<table>
  <thead>
    <tr>
      <th style="text-align: center"><img src="https://lh3.googleusercontent.com/pw/AP1GczP750uzDEWPMe9l-fXnbDOMpcpaoA9-wytFMh9N_6Y41xOroMca-fxDmKmqjrPqotXoGYV5kaIdYVTL6ro0o5x7eWxta9muDGGetHHZrnzGz9YoeY_Ey1VAW5_9fjQG_rblBAvIyUT48RlB6VbGGjGf=w1230-h923-s-no-gm?authuser=0" alt="" /></th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td style="text-align: center"><b>일정 끝난 후 학회 인증 사진</b></td>
    </tr>
  </tbody>
</table>

<p><br /><br /></p>

<h1 id="618-wed">6/18 (Wed.)</h1>
<p>류석영 교수님의 멋진 기조 연설을 시작으로 PLDI의 주요 일정이 시작되었다.
첫 날에는 이 넓은 공간이 가득 채워질 수 있다고? 싶었던 호텔의 그랜드 볼룸이 가득 차고, 의자가 부족해 바닥에 앉아서 연설을 듣는 사람들도 있었다.
이런 멋진 공간에 함께 있을 수 있음에 뭔가 벅차오르는 감정이 들었다.</p>

<p>이 날은 PLDI에서 드물게 볼 수 있었던 프로그램 합성 세션이 있는 날이었다.
PL 분야니까 합성 연구가 좀 많지 않을까? 라고 기대했던 학회 전과 다르게, 합성 연구 논문이 많지 않아서 조금 아쉬웠다.</p>

<p>합성 연구 중 가장 기억에 남는 연구는 2편이 있었다.
한 편은 SyGus 에서 성능을 끌어올리기 위한 연구<sup><a href="#synthesis1">1</a></sup>였는데, 테스트 케이스를 잘 가르는 분기문을 찾고자 하는 연구였다.
Duet<sup><a href="#duet">2</a></sup>이라는 굉장히 잘하는 도구가 있어서 이보다 더 잘할 수 있나? 하는 궁금증이 있었는데, 더 잘할 수 있는 방법이 있다는 것이 놀라웠다.
UnitCon도 다른 사람들이 보기에 이렇게 보이려나 싶긴 했다.</p>

<p>다른 한 편은 반복문 실행 횟수를 정확하게 계산하는 연구<sup><a href="#synthesis2">3</a></sup>였다.
반복문이 종료했을 때 값이 0이 되는 카운터 변수를 두고, 초기 카운터 변수를 계산하는 함수를 합성하는 것을 목표로 하는 연구였다.
실행 횟수의 상한이나 하한 중 하나만을 굉장히 안전하게 계산하던 다른 연구들과 다르게 정확한 실행 횟수를 찾으려고 한다는 점이 더 발전한 연구라는 생각이 들었다.
그리고 특히 카운터 변수를 두어 종료 시점에 항상 0이 되도록 한다는 간단한 조건을 만족하는 함수를 찾는다는 아이디어가 좋다는 생각이 들었다.</p>

<p>저녁 시간에는 PLDI SRC 포스터 발표 시간이 있었다.
포스터를 설치하고 시작 시간이 되자마자 굉장히 많은 사람들이 내 포스터에 관심을 가져주었다.
심사위원 분들이 4분 정도 왔다 가셨고, 많은 학생들과 교수님들이 내 연구에 관심을 가지고 공감해주어 기쁜 시간을 보낼 수 있었다.
설명을 하면서 그 순간에도 연습이 되었는지, 시간이 갈수록 말이 조금 더 쉬워지는 느낌이 들었다.
부족한 영어에도 끝까지 포스터를 이해하려고 노력해준 학생들과 교수님들께 감사드린다.</p>

<table>
  <thead>
    <tr>
      <th style="text-align: center"><img src="https://lh3.googleusercontent.com/pw/AP1GczO02DNwkyS761CaMB6fWc2d7f2LUu0ytTn1wDdqOD5973Kj7T0ZHqTrj_0ONbEMKqlIEcJ6wocJ8-95lXrKB_RSZG9C2seiPWL0oZe5TMq-Po_Oyr0WJQ_6u4lpMiE82FyixxcMFlrHXT03Ool0P3kZYg=w693-h923-s-no-gm?authuser=0" alt="" /></th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td style="text-align: center"><b>유닛콘 스티커를 주고 싶어 파우치를 꼭 손에 쥔 나</b></td>
    </tr>
  </tbody>
</table>

<p><br /></p>

<p>참고로 다른 학회에서도 주는지는 모르겠지만, PLDI SRC는 인증서도 준다.
멀리서 보면 상같기도 해서 기분이 좋다.</p>

<table>
  <thead>
    <tr>
      <th style="text-align: center"><img src="https://lh3.googleusercontent.com/pw/AP1GczMnZRuP9QCeH1BWvAysZXXTykpoEBta40_E_NTX9KMghTA-TZRw2XEIxaO1LUurtjH6gL2S8Cw9kjyeMJxg52D7VVq-AY9bdEJToy_FRrA-9gOKhxdsog51B78XdCcHobgDH3M0G9PennwyZmlTAiUb=w713-h923-s-no-gm?authuser=0" alt="" /></th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td style="text-align: center"><b>SRC 참가자 인증서</b></td>
    </tr>
  </tbody>
</table>

<p><br /><br /></p>

<h1 id="619-thu">6/19 (Thu.)</h1>
<p>학회를 마무리 하며 비즈니스 미팅이 이루어졌었다.
홈 그라운드에서 열린만큼 많은 한국인들이 학회에 참여했었고, 허충길 교수님께서 연산자 오버로딩같은 개념으로 한글을 설명할 때는 다 같이 웃기도 했다.</p>

<p>저녁에는 다양한 상의 수상자들을 축하하며 코스 요리가 제공되었는데, 정말 너무 맛있었다.</p>

<table>
  <thead>
    <tr>
      <th style="text-align: center"><img src="https://lh3.googleusercontent.com/pw/AP1GczN0nGwANTigUAWRqof8FtKTfV1921_gIHfwF_BvZQtMGDT-yCy3kdzYUIJMdtC9O_G3pyoVTonNCNYGc2B54ISLerrWXEit5HIK4i43NDuFpzG6o3TS7H0jdxTKCfqAmkIo3pjyrCADpjTSxWMqS_Ub=w693-h923-s-no-gm?authuser=0" alt="" /></th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td style="text-align: center"><b>보기도 좋은 맛있는 고기</b></td>
    </tr>
  </tbody>
</table>

<p><br /><br /></p>

<h1 id="620-fri">6/20 (Fri.)</h1>
<p>PLDI 학회의 마지막 날이었다.
오전 키노트에서는 Işıl Dillig 교수님이 뉴로 심볼릭 연구에 대한 이야기를 해주셨다.
각 목표에 맞는 DSL (Domain-Specific Language) 를 정의하여 프로그램을 합성하는데, 구체적인 내용을 LLM으로부터 알아오는 연구들이었다.
예를 들어 이미지 수정을 목표로 하는 연구에서는 이미지 수정에 맞게 객체 찾기, 블러처리 하기 등의 동작을 정의한 DSL이 있고, 각 객체를 LLM으로부터 알아오도록 구성이 되어 있었다.
여전히 LLM이 이상한 답을 주면 올바른 프로그램을 못 만든다는 한계가 존재하긴 했지만, LLM을 활용한 연구의 성공적인 사례가 아닐까 생각이 들었다.</p>

<table>
  <thead>
    <tr>
      <th style="text-align: center"><img src="https://lh3.googleusercontent.com/pw/AP1GczPwQsBX8893ej1-SVkGLPbbAzUPTAYfBpwiyoITFh16CvLqF4lq4eygUwVKVen-llvg5APpzzY2UCv7rq9IuAoPeG9ve_isYj_4vrPcJZjsUU0AwSvMEal4EdpB1oRe_cE0jCebhkOYqECP2ktpn9D4=w691-h923-s-no-gm?authuser=0" alt="" /></th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td style="text-align: center"><b>이미지 수정에 사용된 예시</b></td>
    </tr>
  </tbody>
</table>

<p><br /></p>

<p>봉준님은 학회의 마지막 날 <a href="https://prosys.kaist.ac.kr/optimuzz/">Optimuzz</a> 발표를 하셨다.
긴장한 티가 하나도 나지 않으면서 발표를 엄청 잘 하셨는데, 그 모습이 너무 대단하게 느껴졌다.</p>

<p>점심식사 후 월요일에 PLMW에서 만났던 애플에 다니시는 분을 만나 이야기를 나눌 수 있었다.
애플에서는 C에서 Swift로 넘어가려는 작업이 많이 진행되고 있다는 이야기를 들었다.
그리고 실제 기업 입장에서는 오버헤드를 절대 무시할 수 없어 비용을 최소한으로 줄이면서 근본적인 문제를 해결하는 방안에 대해 계속해서 연구하고 고민하고 있다는 이야기도 들었다.
연구자가 보는 작은 오버헤드와 기업 입장에서 보는 작은 오버헤드에는 차이가 있을 수도 있겠다는 생각이 들었는데, 자리를 뜨고 든 생각이어서 질문하지는 못했다.
명함도 받았는데, 근래 본 명함 중 가장 예쁜 명함이라는 생각이 들었다 :&gt;</p>

<p><br /></p>

<h1 id="pldi가-끝나고-fse-시작-전">PLDI가 끝나고 FSE 시작 전</h1>
<p>노르웨이로 가기 위해 재정비 시간이 필요했다.
그래서 금요일 오후에 학회가 끝난 후 대전으로 내려와 짐을 새로 싸고, 토요일 오후에 비행기를 타러 인천으로 갔다.
노르웨이를 가기 전 무엇을 먹어야 가장 좋을까 고민하다가 떡볶이를 먹었는데, 조금 아쉬웠던 것 같다. 돌아오면 다시 떡볶이를 먹기로 하고 비행기에 몸을 실었다.</p>

<p><br /></p>

<h1 id="622-sun">6/22 (Sun.)</h1>
<p>노르웨이에 도착한 이 날은 학회 기간 동안 유일하게 맑은 하루였다.
기온은 20도 안팍으로 한국과 다르게 시원했고, 바닷가 근처여서 그런지 바람은 더 시원했다.
체크인 전까지 시간이 남아 관광을 가기로 했다.
근처에 Munkholmen 이라는 감옥, 수도원, 요새로 그 용도가 계속 변화한 역사가 있는 섬을 방문하였다.
페리를 타고 이동할 수 있었는데, 운행 시간이 정해져있어서 기다리면서 아이스크림도 먹고 마지막 바이킹 동상도 구경했다.</p>

<table>
  <thead>
    <tr>
      <th style="text-align: center"><img src="https://lh3.googleusercontent.com/pw/AP1GczNIoeR5JvUoRAJSlYy0z4kQhjQS7hK2k-pbogxgFfTRLpSwCFplxYSf0EtqmRZtbtklrTNFVuEUlUoB2jO6wtITqKfK2E7kh9hwLhf-yYNIveI4j5mSVycH161BoBVdtV3xckbjvaZKdtPQxUWC0fj4=w693-h923-s-no-gm?authuser=0" alt="" /></th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td style="text-align: center"><b>마지막 바이킹</b></td>
    </tr>
  </tbody>
</table>

<p><br /></p>

<table>
  <thead>
    <tr>
      <th style="text-align: center"><img src="https://lh3.googleusercontent.com/pw/AP1GczNm2XDO_2IrTRaLt9xrssh1kmVTr6FoUgjlA0VCYL0-WUF02buo5YOVJJAAIcJ8Y4QF12DazGUT7rUjacqQEOzmL1JDHk3ufv25AYe8_udJAp81Um6OBkj4_-9oBrZf-5oSVGbD0dDfQqr27dcemnM0=w693-h923-s-no-gm?authuser=0" alt="" /></th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td style="text-align: center"><b>춥지만 아이스크림은 못 참아!</b></td>
    </tr>
  </tbody>
</table>

<p><br /></p>

<p>섬으로 이동해서는 섬의 역사에 대한 설명을 간단하게 듣고 각자 돌아다니는 시간을 가졌다.
어떻게 섬 하나가 감옥, 수도원, 요새로 쓰일 수 있지 하는 의문이 들었는데, 직접 둘러보고 나서는 쓰일만한가? 라는 생각이 자동으로 들게 되었다.</p>

<table>
  <thead>
    <tr>
      <th style="text-align: center"><img src="https://lh3.googleusercontent.com/pw/AP1GczPn4-9Rlh0zbz5OoL_a-0Ye1Z6fpB2TMMH9Mdo4f1zCdkrrwQ7FFsF6iIj_akFLMuVG3rr54-d_ms-juDU-7pa4Rzv0NFhqYGsFIu3PEmS12U-GYph2UHzHIb5alhEjJPSfzYvyIxQ8-n6kjZDv6TD7=w693-h923-s-no-gm?authuser=0" alt="" /></th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td style="text-align: center"><b>공기 좋고 맑은 Munkholmen에서</b></td>
    </tr>
  </tbody>
</table>

<p><br /></p>

<h1 id="623-mon">6/23 (Mon.)</h1>
<p>학회의 첫 날이 밝았다.
<a href="https://prosys.kaist.ac.kr/unitcon/">UnitCon</a> 발표가 첫 날에 있어 너무 긴장한 상태로 하루를 보냈다.
발표 전 청심환도 챙겨먹고 발표장에 갔는데, 예상치 못한 일이 너무 많이 일어나서 당황스러웠다.
발표자료를 넘길 리모컨이 따로 주어지지 않았고, 노트북이 있는 단상은 나에게 너무 높았다.
발표 전 공용 노트북이 잠겨 발표 시간에 촉박함을 느끼기도 했다.
이래저래 당황스러움을 느꼈던 나는 그게 발표에서 다 드러나게 되었다.
아쉬움이 많이 남았었기 때문에 빠른 재도전을 해야겠다는 생각이 들었다.</p>

<table>
  <thead>
    <tr>
      <th style="text-align: center"><img src="https://lh3.googleusercontent.com/pw/AP1GczM-iPIBsADRm1S9Qz8ONsdITH5w9ZrpLHDJuDU6uJzWMhWIQjhtyi_GHsu0xCXTAXov8MfaqLdj9vb4hie8y06NzxsMnl3z_pevhxfuRmkdn_VonSHeZfHsVce4cdwPj2cIdPLCJ3mvJ7z5OhupAzWG2Q=w693-h923-s-no-gm?authuser=0" alt="" /></th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td style="text-align: center"><b>팔이 걸쳐진 이유는 너무 높아서 입니다.</b></td>
    </tr>
  </tbody>
</table>

<p><br /></p>

<p>발표가 끝난 후에는 소문으로만 들었던 따뜻한(?) SE 학회답게 관광을 다 같이 갔다.
트론하임에는 니다로스 대성당이 있는데, 이곳에서 오르간 연주를 보여준다고 하여 성당으로 갔다.
중세 느낌이 물씬 느껴지는 오래된 건물이었다.
웅장했고, 정교했다.</p>

<table>
  <thead>
    <tr>
      <th style="text-align: center"><img src="https://lh3.googleusercontent.com/pw/AP1GczNX5BrWhY7WdPVf2zvNtwjZn7prNDaKBuGTIs4rITnuPmqBB59pKO3MzTq3TqXG2cnVmuaI_hrAgJdhTT6VHhnMzK8h1WP5pW9rXPe4yW6osrtiM9EJ0BaCQOs0dPlQXXGtj77n4_0XeY0zn3uOwcfm=w1230-h923-s-no-gm?authuser=0" alt="" /></th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td style="text-align: center"><b>니다로스 대성당</b></td>
    </tr>
  </tbody>
</table>

<p><br /></p>

<p>그리고 어쩌다보니 백야(?) 기간에 북유럽에 방문하게 되어 하루종일 어둡지 않은 하늘을 볼 수 있었다.
밤 11시에 해가 지고 새벽 3시에 해가 뜬다고 했는데, 백야가 맞는지 아닌지는 정확히 모르겠다.</p>

<table>
  <thead>
    <tr>
      <th style="text-align: center"><img src="https://lh3.googleusercontent.com/pw/AP1GczO2yBrTppgvER-W3qchfjCodI9mBMvOGANSB-J-nsklLoxxq_KPFEtR2KlFdR9sAQ6-RFwHe7kizVZelisdr30FNMNpncPDi6lECcwwENh_CaNiZETXtI4NR3s8Kjvo3ohjOJKB-Qjah67vxUeCDehN=w693-h923-s-no-gm?authuser=0" alt="" /></th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td style="text-align: center"><b>이 하늘이 밤 12시라니!</b></td>
    </tr>
  </tbody>
</table>

<p><br /><br /></p>

<h1 id="624-tue">6/24 (Tue.)</h1>
<p>발표를 끝냈기 때문에 이 날부터는 편한 마음으로 발표를 열심히 들으러 다닐 수 있었다.
분야가 굉장히 다양했고, 리서치 트랙의 논문 뿐 아니라 저널, 인더스트리 논문들이 분야별로 묶여 발표가 진행되어서 발표 시간이 각양각색이었다.
그래서 그런지 교수님들의 발표도 제법 많이 볼 수 있었다.</p>

<p>테스팅은 확실히 인기 있는 분야인지 세션이 4번이나 열렸다.
이 날은 3번째 테스팅 세션이 있었는데, COBOL 테스팅을 자바로 옮기는 연구<sup><a href="#testing1">4</a></sup>와 여러 종류의 테스트 오라클을 한번에 보여줌으로써 디버깅을 용이하게 하는 연구<sup><a href="#testing2">5</a></sup> 등에 대한 발표를 들을 수 있었다.
같은 테스팅 분야에 묶여있었지만, 각 발표가 모두 특색있었다.</p>

<p>저녁에는 뱅큇이 있었고, 각종 상의 수상을 축하하며 코스 요리가 제공되었다.
UnitCon은 우수 논문상을 받아서 많은 사람들의 축하를 받을 수 있었다.
어떤 논문이 우수 논문상을 받는지 기준도 궁금했었는데, 리뷰 점수의 평균이 3.67점 이상인 논문들 중에서 골라진다고 하는 것 같았다.
이때 리비전 후 점수가 변경되었으면 변경된 점수로 계산한다고 했다.
논문을 열심히 쓰고 리비전도 열심히 했더니 좋은 결과가 있었던 것 같다.</p>

<table>
  <thead>
    <tr>
      <th style="text-align: center"><img src="https://lh3.googleusercontent.com/pw/AP1GczNcK8s8X1ZYzAxLbjcFkNu3tKuaFMuBSkj8AIwd_c5cHg0jCiZkcejyNDRWh5m1WYfIQQ7vVggnuxeK30OcaMvKGNJSIeJRMf0QOBWIJsbe4TvILMIN9vlkTdbrNrGVcOOaVm3dGVjIdlU--LYU__OKUw=w1230-h923-s-no-gm?authuser=0" alt="" /></th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td style="text-align: center"><b>3팀씩 사진을 찍었다.</b></td>
    </tr>
  </tbody>
</table>

<p><br /><br /></p>

<h1 id="625-wed">6/25 (Wed.)</h1>
<p>FSE 일정이 끝나면서 ISSTA가 시작되는 날이었다.
새로 등록하는 사람들이 많아지면서 다시 학회장이 북적북적해졌다.
이날도 어김없이 테스팅 세션을 찾아 다녔다.
연산 리소스 관련된 flaky test에 대한 조사 논문<sup><a href="#testing3">6</a></sup>에 대한 발표, 가짜 객체 (mock)을 사용하는 테스트의 특성을 조사한 논문<sup><a href="#testing4">7</a></sup>에 대한 발표를 들었다.
가장 기억에 남는 것은 0.5CPU와 2GiB RAM을 사용하면 연산 리소스의 flaky test를 피할 수 있다는 것이었다.</p>

<table>
  <thead>
    <tr>
      <th style="text-align: center"><img src="https://lh3.googleusercontent.com/pw/AP1GczP6F1sbPQf2ypRWhFG33CFJ3WIahFgP82QVfLAMN4cEz8xHMgmG7RJuZM3CDmMMST7o9nnOxd_-9h6-Rl5PcuvsIw1EcusG6haterrPCWNVfXdlmfntbn8aczkL8WjwNr5qZeG3piDFU-WzhetK1wBI=w1230-h923-s-no-gm?authuser=0" alt="" /></th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td style="text-align: center"><b>연산 리소스의 flaky test를 피하기 위해 참고하자</b></td>
    </tr>
  </tbody>
</table>

<p><br /></p>

<p>점심은 파스타와 샐러드 등을 자유롭게 가져가 먹을 수 있게 제공되고 있었다.
그래서 자리에 앉아 음식을 먹는데 충북대의 기은님과 Stuttgart 대학의 Beatriz Souza가 와서 같이 대화를 하며 밥을 먹었다.
Beatriz Souza가 링크드인을 보여주었는데 팔로워가 엄청 많아서 신기해했더니 웃긴 사람들이라며 엄청 웃었다.
FSE에서도 꼭 스티커를 나눠줘야지 라는 생각으로 PLDI에 챙겨갔던 파우치를 들고 갔는데 드디어 한 개를 나눠줄 수 있었다.
나름 성공적(?)인 교류였다는 생각이 들었다.</p>

<p>FSE 학회 일정이 끝나고는 근처에서 하는 플리마켓 행사를 구경가기 위해 나왔다.
버거 패티 냄새가 유혹했지만, 잘 참고 구경을 다녔다.
밴드 공연도 구경하고, 다양한 상품과 음식들도 구경했다.
그 중 가장 기억에 남는 것은 많은 종류의 치즈가 진열된 곳이었는데, 치즈 종류가 너무 다양해서 신기했다.</p>

<table>
  <thead>
    <tr>
      <th style="text-align: center"><img src="https://lh3.googleusercontent.com/pw/AP1GczO-F3C8PDGZm4glFo9t9ohv6bqtWimsl6qzlET9gfxQ9vb8kQ892tkLmAOgXOue7Ii4mUxrbXtMP3xsWAJY94AxW3XcwbGY9hbq9pyjVv-Nw_8eSA84rRcemansFd7H4PzLorjIJt3UlVpcp5sQq3OJ=w693-h923-s-no-gm?authuser=0" alt="" /></th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td style="text-align: center"><b>녹색 치즈가 신기합니다.</b></td>
    </tr>
  </tbody>
</table>

<p><br /></p>

<p>새로운 도시를 가니, 익숙했던 서울과 다르게 낯선 느낌이 여행에 재미를 불어넣어준 것 같았다.</p>

<p><br /></p>

<h1 id="627-thu">6/27 (Thu.)</h1>
<p>한국으로 돌아가는 날이었다.
오전에는 전날 3배 정도 비싸게 주고 구매한 노르웨이 바세린을 환불하러 다녀왔다.
한국에서도 환불을 잘 하지 않는 편인데, 왠지 지금이 아니면 절대 환불을 할 수 없다는 생각 때문인지 용기가 나서 무사히 환불을 잘 하고 나왔다.
다들 가격 비교를 잘 하고 사자!</p>

<table>
  <thead>
    <tr>
      <th style="text-align: center"><img src="https://lh3.googleusercontent.com/pw/AP1GczNATzqG-O1O2ZSx0a1focHPiCAqbcJOOdkyOfoMYRt1milaM9dS19vF86-JsrvQRxkcLmloYgslvga_EotHbJtE8LlMt8G7uiUjH5OHtaxm_S8LMeqyf9QBBRD3k7nBdB_DuOHMOurAqyvCKb_AN4MP=w693-h923-s-no-gm?authuser=0" alt="" /></th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td style="text-align: center"><b>약국에선 69 크로네, 여기선 24 크로네!</b></td>
    </tr>
  </tbody>
</table>

<p>10시 반에 체크아웃을 하고 교수님, 연희님과는 각자의 시간을 보내다가 점심에 학회장에서 다시 만나기로 하고 흩어졌다.
나는 카페에서 커피를 마시며 조금 쉬기로 하였다.
코르타도 라는 스페인식 카페라떼를 시켜 마셨다.
한국에서는 무조건 아이스 아메리카노를 시켜먹는 나로썬 새로운 도전이었다.
씁쓸하고 부드러운 게 꽤 먹을만했다.</p>

<table>
  <thead>
    <tr>
      <th style="text-align: center"><img src="https://lh3.googleusercontent.com/pw/AP1GczPbF9XumQrN3NfUuT7Kuiu2Ue2lUUWV1KFvC1gCbLIEtIOC-69QYVYgVNvUjL8jS9MyNJn0qoIMiTnNmk0BdhsB21FMBcpySk3yTRrXqv3s6MCMjYmF8vBGCxkCMUmElR9LUA4mOMF5NMt3v68RyR5-=w693-h923-s-no-gm?authuser=0" alt="" /></th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td style="text-align: center"><b>나름 아트도 있다.</b></td>
    </tr>
  </tbody>
</table>

<p><br /><br /></p>

<h1 id="마치며">마치며</h1>
<p>교수님의 전폭적인 지원과 좋은 기회로 큰 국제 학회 두 곳에 참석할 수 있었다.
다양한 연구자들을 만나고, 연구에 대한 열정을 느낄 수 있어서 배운 점이 많았던 일정이었다는 생각이 들었다.
좋은 논문 발표를 해주신 봉준님, 함께 PLDI부터 FSE까지 긴 여정을 함께 해주신 연희님, 마지막으로 출장 준비를 도와주신 김은주 선생님께 감사드린다.
2년 전 내 논문을 가지고 학회에 방문하고 싶다는 꿈을 이루게 되어 기쁘다.
지금 연구도 잘 마무리하여 내 논문을 가지고 다시 학회에 방문하고 싶다.
<br /><br /></p>

<hr />

<h3 id="참조">참조</h3>
<p>[<a name="synthesis1">1</a>] Yuantian Ding and Xiaokang Qiu, “A Concurrent Approach to String Transformation Synthesis”, PLDI (2025) <br />
[<a name="duet">2</a>] Woosuk Lee, “Combining the Top-down Propagation and Bottom-up Enumeration for Inductive Program Synthesis”, POPL (2021) <br />
[<a name="synthesis2">3</a>] Daniel Riley and Grigory Fedyukovich, “Exact Loop Bound Analysis”, PLDI (2025) <br />
[<a name="testing1">4</a>] Sandeep Hans et al., “Automated Testing of COBOL to Java Transformation”, FSE Industry (2025) <br />
[<a name="testing2">5</a>] Matthew C. Davis et al., “TerzoN: Human-in-the-Loop Software Testing with a Composite Oracle”, FSE (2025) <br />
[<a name="testing3">6</a>] Denini Silva et al., “The Effects of Computational Resources on Flaky Tests”, TSE (2025) <br />
[<a name="testing4">7</a>] Hengcheng Zhu et al., “Understanding and Characterizing Mock Assertions in Unit Tests”, FSE (2025)</p>]]></content><author><name>장수진</name></author><category term="Trip" /><category term="PLDI2025" /><category term="FSE2025" /><summary type="html"><![CDATA[들어가며 PL 분야의 큰 학회인 PLDI가 6월 16일부터 20일까지, SE 분야의 큰 학회인 FSE가 6월 23일부터 25일까지 각각 서울과 노르웨이 Trondheim 에서 열렸다.]]></summary></entry><entry><title type="html">두 번 생각하는 두 학회 여행기</title><link href="http://prosys.kaist.ac.kr/yeonhee-pldifse25/" rel="alternate" type="text/html" title="두 번 생각하는 두 학회 여행기" /><published>2025-07-25T00:00:00+00:00</published><updated>2025-07-25T00:00:00+00:00</updated><id>http://prosys.kaist.ac.kr/yeonhee-pldifse25</id><content type="html" xml:base="http://prosys.kaist.ac.kr/yeonhee-pldifse25/"><![CDATA[<p>좋은 기회로 2주 연속으로 큰 국제 학회에 참석하게 되었다. 서울에서 열린 PLDI 와 노르웨이 트론하임에서 열린 FSE 에 연달아 참석하면서 밀도 있게 두 분야의 연구를 접할 수 있었다.</p>

<table>
  <thead>
    <tr>
      <th style="text-align: center"><img src="https://lh3.googleusercontent.com/pw/AP1GczPRkw5zxVhSJPJyAFcLfFwPT6z1byzv67CmRdHGWRbdTRUezoOOq9wukMjtJmOSRKY4zdjc046FdvYtvIIHb9ZdPjZklGUbbDib5g9cGO08n2jOsIQhk9Q4pXnqjdVNAd1iG0RcnoRx1nwIg2ssHn6x=w2486-h1864-s-no-gm?authuser=0" alt="" /></th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td style="text-align: center"><strong>FSE에서 UnitCon 우수 논문상 수상 후 으쓱한 시간</strong></td>
    </tr>
  </tbody>
</table>

<h2 id="pldi-와-fse-에서-언어-모델을-이용하는-방법">PLDI 와 FSE 에서 언어 모델을 이용하는 방법</h2>

<p>두 학회는 각각 PL 과 SE 분야에서 손꼽히는 큰 국제적인 학회다.
두 분야 모두 프로그램 그 자체를 연구 대상으로 본다. 그래서 언어 모델을 사용하는 방식도 큰 틀에서는 비슷한데, 입출력에 프로그램이 사용된다는 점이다.
우선 요구사항이나 실행 예시 등 프로그램과 관련된 정보를 해석하는 데 언어 모델을 사용한다.
예를 들어 PLDI 마지막 날 키노트였던 Işıl Dillig의 발표에서 다양한 도메인에서의 프로그램 합성 기술이 소개되었는데, 비디오로 작성된 입출력 예시와 같이 프로그래밍 언어 외적인 입력을 다루는 데 언어 모델을 사용했다.
FSE에서 발표된 Hossain 등<sup id="fnref:1" role="doc-noteref"><a href="#fn:1" class="footnote" rel="footnote">1</a></sup>의 연구는 자연어로 작성된 개발 문서를 읽는 데 언어 모델을 사용하고, Wang 등<sup id="fnref:2" role="doc-noteref"><a href="#fn:2" class="footnote" rel="footnote">2</a></sup>의 연구는 GUI 입력을 해석하는 데 언어 모델을 사용했다.</p>

<p>다음으로 프로그램 코드를 작성하는 데 언어 모델을 사용한다.
PLDI의 인더스트리 세션에서 있었던 공순호 박사님의 발표에서는 언어 모델을 이용해서 Lean 증명 프로그램을 작성하는 문제가 소개되었다.
언어 모델이 필요한 이유와 Lean 프로그램을 더 잘 작성하기 위해 필요한 강화 학습 등의 학습 방법, 좋은 데이터를 수집하는 방법 등의 문제를 제시하기도 했다.
이 외에도 테스트 케이스<sup id="fnref:3" role="doc-noteref"><a href="#fn:3" class="footnote" rel="footnote">3</a></sup> 나 패치<sup id="fnref:4" role="doc-noteref"><a href="#fn:4" class="footnote" rel="footnote">4</a></sup><sup id="fnref:5" role="doc-noteref"><a href="#fn:5" class="footnote" rel="footnote">5</a></sup> 등 다양한 형태의 프로그램 코드를 작성하는 데 언어 모델을 사용하고 있었다.
다소 당연할 수도 있지만, 이렇게 프로그램을 언어 모델의 입출력으로 사용한다는 점이 두 분야의 공통적인 특징을 보여준다고 생각했다.
내게도 프로그램은 유용한 도구이면서 재미있는 연구 대상이다.</p>

<p>하지만 두 학회의 연구에는 차이도 있었다. 내가 가장 크게 느낀 차이점은 두 분야에서 문제와 해결책을 정의하는 순서가 다르다는 점이다.
언어 모델을 활용해서 해결하고자하는 문제의 범위와 언어 모델의 능력 범위를 설정할 때 우선 순위가 달랐다.
우선 PLDI 에서 접한 연구는 문제의 범위를 먼저 설정하고 그 안에서 언어 모델이 동작하도록 제한하는 방식으로 접근했다.
위에서 언급한 Işıl Dillig의 키노트에서 소개되었던 일련의 연구도 이렇게 볼 수 있다.
언어 모델이 사용할 수 있는 DSL 을 먼저 정의하고, 그 언어 안에서 언어 모델이 프로그램을 작성하게 한다.
또, Mündler 등<sup id="fnref:6" role="doc-noteref"><a href="#fn:6" class="footnote" rel="footnote">6</a></sup>은 타입 시스템 기반의 조건부 생성 (Constrained decoding) 기술을 제안했다.
언어 모델이 작성할 수 있는 코드의 타입 시스템을 정밀하게 정의하고, 언어 모델이 그 범위 밖에서는 코드를 생성할 수 없도록 제한하는 방법이다.</p>

<p>반면 FSE 에서 접한 연구는 다양한 관점에서 폭넓게 언어 모델의 능력을 파악하려고 했다.
리서치 트랙 뿐만 아니라 인더스트리나 아이디어 트랙을 포함해서 언어 모델의 능력을 평가하는 다양한 벤치마크 연구들이 있었다.
예를 들어 COFFEE<sup id="fnref:7" role="doc-noteref"><a href="#fn:7" class="footnote" rel="footnote">7</a></sup>는 기존에 있던 언어 모델 평가 벤치마크를 확장해서 성능 평가를 함께 할 수 있게 만드는 기술이다.
언어 모델의 환각 현상을 평가하거나<sup id="fnref:8" role="doc-noteref"><a href="#fn:8" class="footnote" rel="footnote">8</a></sup> 언어 모델이 작성한 코드의 코딩 스타일을 평가<sup id="fnref:9" role="doc-noteref"><a href="#fn:9" class="footnote" rel="footnote">9</a></sup> 하려는 연구도 있었다.
이렇게 언어 모델의 능력을 먼저 파악하고 나면 풀고자 하는 문제의 범위에 맞는 언어 모델을 선택하거나, 필요한 능력을 끌어올리기 위해 추가 학습을 하기도 한다.
특히 LWO<sup id="fnref:10" role="doc-noteref"><a href="#fn:10" class="footnote" rel="footnote">10</a></sup>는 이런 관점에서 더 나아간 연구였다. 언어 모델을 특정 과제에 적응시킬 때, 더 효율적으로 학습하기 위한 PEFT 방법을 제안했다.</p>

<p>두 학회를 연달아 참석하다보니 언어 모델을 활용하는 방식 차이를 느낄 수 있었다.
물론 두 학회에 발표된 논문들이 내 기준에 따라 명확하게 나뉘는 것은 아니다.
하지만 이런 여러 갈래의 기술들 사이에서 우리가 지금 하고 있는 연구의 위치는 어디인지, 앞으로 하고 싶은 연구가 어떤 방향인지 고민해볼 수 있었다.
특히 FSE에서는 수진님, 교수님과 쉬는 시간마다 다양한 내용에 대해서 토론하면서 생각을 구체화할 수 있어서 좋았다.
이미 PLDI에서 다양한 최신 연구를 접하면서 새로운 관점이 생기기 시작했을때라 더 생각이 발산하고 있었다.
나는 조건부 생성에대해서 고민하고 있었고, 교수님은 언어 모델을 이용한 증명 생성에 관심이 있었다.
셋이 함께하는 연구의 다음 과제에대해서 토론하기도 했다.
가끔은 같이 이야기하고 있지만 집단적 독백 상태에 있다고 느꼈는데, 그런 대화도 즐거웠다.</p>

<h2 id="학회를-가꾸고-지키는-사람들">학회를 가꾸고 지키는 사람들</h2>

<p>PLDI에는 비즈니스 미팅, FSE 에는 타운홀이라는 이름으로 학회의 성과를 공유하고 앞으로 학회의 발전을 논의하는 자리가 있었다.
PLDI 비즈니스 미팅은 2일차 저녁식사 직전에 한시간이 넘는 긴 시간동안 진행되었는데도 참석한 사람이 많았다.
시작할 때 한글의 우수성을 자랑하는 발표가 먼저 있었는데, PL 의 연산자 오버로딩, 오버라이딩 같은 개념을 도입해서 한글의 시스템을 해석한게 재밌었다.
참석자들도 자주 웃었는데 이렇게 기술적인 유머로 다같이 웃을 수 있다는 데에서 결국 비슷한 사람들이라는 친근감을 느끼기도 했다.
학회의 참석자 수나 채택율 등 올해의 학회에대한 통계 보고가 있었고, 내년의 PLDI 소개도 이어졌다.</p>

<p>마지막에는 학회에 있는 문제점과 이를 해결하는 방법에대해 토론하는 시간이 있었다.
몇가지 주제가 있었는데, 모의 리뷰 (Shadow PC) 제도에 관한 내용도 언급되었다.
처음 리뷰를 시작하는 PC 들을 위해 교육이 필요하다는 의견이 있었고, 한 학생이 모의 리뷰 제도를 제안했다.
학회 일정 중 만났던 학생이었는데, 나와 같은 박사 3년차라고 했다.
우리 연구실에서는 나와 태은님이 이전에 모의 리뷰 제도에대해 대화했던 적이 있었다.
비슷한 시기에 있는 학생들끼리 비슷한 일에 관심을 갖게 되는건 자연스러운 일일 것이다.
이게 빨리 어른이 되고 싶은 어린이의 마음인가 생각했다.</p>

<p>FSE 타운홀은 늦게 참석한 탓에 토론의 후반부만 들을 수 있었다.
두 학회의 참석자 통계만 비교하면 FSE 참석자가 백여명정도 많았는데, 타운홀 참석자 수는 훨씬 적었다.
행사가 진행된 장소의 크기가 너무 커서 사람이 더 적어보였는지도 모르겠다.
하지만 적은 인원으로도 활발한 토론이 이어지고 있었는데, 주제는 대체로 PLDI 의 비즈니스 미팅에서와 비슷했다.</p>

<p>두 학회 모두 더 좋은 학회를 만들어가고자하는 분위기를 느낄 수 있었다.
참석자들은 적극적으로 문제를 지적하고 해결책을 제안하고 이에 대한 장단점과 예상되는 효과같은 것들을 다방면에서 토론했다.
학회가 발전하려면 새롭고 의미있는 기술도 필요하지만, 한 사회로서 학회를 유지하고 발전시키려는 노력도 필요하다.</p>

<h2 id="국내에서-열리는-국제-학회">국내에서 열리는 국제 학회</h2>

<p>이번에 PLDI 가 서울에서 열려서 더 좋았던 점은 세계적인 연구자들이 국내에 방문했다는 점이다.
연구자들을 학교로 초대해주신 교수님들 덕분에 학회 전 며칠간은 다양한 발표가 끊이지 않았다.
학회에서의 연구 발표는 시간 제약이 있다 보니 짧고 간결하게 최신 기술 위주로 진행이 된다.
하지만 학교에서 있었던 발표는 한시간이 넘도록 연구 분야의 개요부터 최신 연구까지 다양하고 자세하게 소개가 되어서 더 깊이 배울 수 있었다.
학회 발표 보다 소규모로 진행이 되다 보니 발표 이후에 직접 질문하거나, 연사에게 우리 연구를 소개하면서 이야기 할 기회가 더 있었던 점도 좋았다.
다가오는 가을에 서울에서 국제 학회가 한번 더 예정 되어 있다. 가을에도 좋은 발표들이 있을 것 같아 기대된다.</p>

<p>연구실의 다른 학생들도 여행기에서 언급했지만, 교통이 편리하고 시차가 없으면서 익숙한 도시였던 점도 큰 장점이었다.
익숙한 도시에서 익숙한 교통편을 타고 학회장으로 출퇴근해서 학회에 더 집중할 수 있었다.
PLDI 첫날 처음 대화했던 학생이 서울에서 관광할 거리를 물었는데, 예상하지 못해 당황했다.
하지만 나중에는 이게 장점이라는 것을 알게 되었다. 처음 만나는 사람들과 이야기할 때 좋은 소재로 사용할 수 있었다.</p>

<p>이어서 있을 FSE 여행을 위해 체력을 아끼느라 PLDI 를 더 적극적으로 즐기지 못했던 것은 아쉽다.
다음 일정을 걱정하느라 본 학회 일정 외의 워크샵이나 연구실 회식 등에 참석하지 않았다.
미리 체력을 더 길렀더라면 더 즐길 수 있었을텐데 하는 아쉬움이 남는다.
다음에 이런 일이 있을 때를 대비해서 운동을 더 열심히해야겠다.</p>

<h2 id="unitcon-발표와-여유가-있는-학회">UnitCon 발표와 여유가 있는 학회</h2>

<h3 id="연구-교류">연구 교류</h3>

<p>이번 FSE에서는 저자로 참여한 <a href="https://prosys.kaist.ac.kr/unitcon/">UnitCon</a> 논문이 발표되었다.
특히 우수 논문으로 선정되어 더 좋았다.
발표자인 수진님이 첫날 발표 준비로 바쁜 동안 나는 사람들과 우리 논문에대해 이야기할 기회가 있었다.
아쉽게도 UnitCon과 비슷한 분야를 연구한 사람과 깊이 토의할 기회는 없었지만, 다른 분야의 연구자들이 내 소개를 듣고 연구의 필요성에대해 공감해줄 때 신이 났다.</p>

<p>PLDI 를 포함해 FSE 이전까지의 학회에서 나의 주요 <a href="https://prosys.kaist.ac.kr/networking-guide/">네트워킹 전략</a>은 혼자 커피를 들고 서 있으면 다가오는 사람과 이야기하는 방법이었다.
하지만 FSE 에서는 그게 잘 통하지 않았다.
우선 3개 학회가 연달아 열리는 학회였고, FSE 가 그 중간에 있다 보니 사람들이 지쳐있었다.
한국인이 많아 아는 얼굴들을 만나 인사하다 보면 쉬는 시간이 금새 지나가버리기도했다.
혼자 있을 때 다가오는 사람을 기다리는 수동적인 방법으로는 사람을 만나기 어려웠다.
첫날 점심때는 사교적인 도현님의 도움으로 처음 보는 사람들과 식사하면서 대화할 수 있었는데, 그 외에는 발표자들을 찾아가 질문 몇 번 했던 것 외에 이렇다할 교류 활동이 없었다.</p>

<p>그래서 FSE 마지막 날에는 Doctoral Symposium 에 참석했다.
일단 포스터 발표가 있다는 점이 좋았다.
포스터 발표장에서는 모두가 돌아다니면서 연구 이야기를 하고 있으니, 나도 끼어서 말하기 좋을거라고 생각했다.
포스터 목록에 관심있는 주제들이 있는 것도 좋았다.
언어 모델을 이용해서 코드를 잘 생성하려는 기술이 몇 편 있었다.
가서 보니 작은 방에서 소규모 인원이 이야기를 하고 있어서 더 좋았다.
큰 학회장에 있을 때 보다는 부담을 덜고 다른 사람의 포스터에 다가가서 대화를 시작하기 좋았다.
특히 언어 모델에 취약점을 추가 학습하는 방법에 관한 포스터 발표가 있어서 발표자와 자세히 이야기했다.
비슷한 시기에 비슷한 주제를 연구하는 또래를 만나서 반가웠고, 더 동기부여가 되기도 했다.
이 자리에서 만난 학생들과는 서로 메일이나 링크드인 연락처를 교환하기도 했다.
다음에 기회가 된다면 직접 포스터 발표도 해보고 싶다.</p>

<h3 id="도시-여행">도시 여행</h3>

<table>
  <thead>
    <tr>
      <th style="text-align: center"><img src="https://lh3.googleusercontent.com/pw/AP1GczM_WsoFt3kz_uig5Ul7BkOPDPmlGkRJ3ILA-sGDlxxvwTT0A96XU6PMPiG0WUGMJtQQ7Mhczhrr_A3vmWIX4bVmucaF-0zefq4J-_k73M4TY5pHL1qGzMa1OFh34R2RRk9lNncu3OmruRAoZHSI4aZH=w2486-h1864-s-no-gm?authuser=0" alt="" /></th>
      <th style="text-align: center"><img src="https://lh3.googleusercontent.com/pw/AP1GczOFrF8ISkdPM6GUG2AhbCDhRM7HSBrVMELtTgINhwaRJiqtDWjHUCvJOw92C212fZwDo-73TdfgcJnEtvONHL46PdUdMvvl-YlmNEPIXp4tousO6-ZHnJor-Js6qHpLNNXN4n04VLffFVg9oZeS6wLrmQ=w1992-h2656-s-no-gm?authuser=0" alt="" /></th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td style="text-align: center"><strong>해도 좋고 바람도 좋은 Munkholmen</strong></td>
      <td style="text-align: center"><strong>옛 감옥 체험</strong></td>
    </tr>
  </tbody>
</table>

<p>트론하임에 도착한 첫날에는 호텔 체크인 시간까지 여유가 있어서 관광을 했다.
배를 타고 Munkholmen 이라는 섬을 가서 가이드 투어를 들었다.
천년 전에 수도원으로 지어졌다는 건물이 있었는데, 그래서 이름이 수도사의 섬이 된 모양이다.
천년 동안 수도원은 용도를 바꿔서 요새로도 쓰이고 감옥으로도 쓰였다고 했다.
외벽이 두텁고 무뚝뚝하게 생겨서 어느 쪽이든 어울린다고 생각했다.</p>

<p>학회 첫날 리셉션이 도시의 주요 관광지에서 열렸다.
니다로스 성당에서 오르간 연주를 듣고 옆에 있던 대주교의 궁전에서 스파클링 와인과 핑거 푸드를 먹었다.
도시에 도착한 첫날 혼자 돌아다녔는데, 우연히 도착한 곳이 니다로스 성당이었다.
추모 공원과 높은 고딕 성당이 함께 있는데, 공원의 나무가 크고 울창해서 첫날 날씨가 좋을 때는 정말 예뻤다.
행사 일정으로 다시 갔을 때는 비가 와서 예쁜 풍경을 다시 보지 못한게 조금 아쉽다.
하지만 혼자 갔을 때는 들어가지 못한 성당 내부를 볼 수 있었던 것은 좋았다.
오래된 건물의 냄새가 났고, 스테인드글라스가 화려했다.
오르간 연주도 신기했는데, 악기가 눈앞에 있는데도 어딘가 먼 곳에서 소리가 들려오는 것처럼 들렸다.
UnitCon 발표가 끝나고 즐거운 기분이어서 더 멋있어 보였는지도 모르겠다.</p>

<p>트론하임에 도착한 첫날과 떠나던 마지막 날을 제외하면 거의 항상 비가 내렸다.
학회 일정은 하지가 막 지난 시점이라 해가 정말 길었는데, 밤 11시에 해가 져서 새벽 3시에 해가 떴다.
어느 날은 번화가에서 맥주를 마시다가 해가 진 뒤 자정에 들어갔지만 자정의 하늘도 비 내리는 낮의 하늘과 거의 차이가 없었다.
원래도 트론하임은 365일 중 260일은 비가 내리는 도시라고 한다.
그런 중에 첫날과 마지막날 밝은 해를 봤으니 운이 좋은 셈이다.</p>

<h2 id="마치며">마치며</h2>

<p>이번 두 학회를 통해 다양한 연구를 접하고 세계적인 연구자들을 만나 교류할 수 있었다.
두번의 학회 모두 참석할 수 있게 지원해주신 지도 교수님께 감사드린다.
그리고 PLDI 와 FSE 에 참석할 수 있는 기회를 만들어 준, 멋진 동료 봉준님과 수진님에게도 감사한다.</p>

<hr />

<h4 id="참조">참조</h4>
<div class="footnotes" role="doc-endnotes">
  <ol>
    <li id="fn:1" role="doc-endnote">
      <p>Hossain, Soneya Binta, Raygan Taylor, and Matthew Dwyer. “Doc2OracLL: Investigating the Impact of Documentation on LLM-Based Test Oracle Generation.” FSE 2025. <a href="#fnref:1" class="reversefootnote" role="doc-backlink">&#8617;</a></p>
    </li>
    <li id="fn:2" role="doc-endnote">
      <p>Wang, Chenxu, et al. “LLMDroid: Enhancing Automated Mobile App GUI Testing Coverage with Large Language Model Guidance.” FSE 2025. <a href="#fnref:2" class="reversefootnote" role="doc-backlink">&#8617;</a></p>
    </li>
    <li id="fn:3" role="doc-endnote">
      <p>Kim, Myeongsoo, Saurabh Sinha, and Alessandro Orso. “Llamaresttest: Effective rest api testing with small language models.” FSE 2025. <a href="#fnref:3" class="reversefootnote" role="doc-backlink">&#8617;</a></p>
    </li>
    <li id="fn:4" role="doc-endnote">
      <p>Behrang, Farnaz, et al. “DR. FIX: Automatically Fixing Data Races at Industry Scale.” PLDI 2025. <a href="#fnref:4" class="reversefootnote" role="doc-backlink">&#8617;</a></p>
    </li>
    <li id="fn:5" role="doc-endnote">
      <p>Wu, Susheng, et al. “Mystique: Automated Vulnerability Patch Porting with Semantic and Syntactic-Enhanced LLM.” FSE 2025. <a href="#fnref:5" class="reversefootnote" role="doc-backlink">&#8617;</a></p>
    </li>
    <li id="fn:6" role="doc-endnote">
      <p>Mündler, Niels, et al. “Type-Constrained Code Generation with Language Models.” PLDI 2025. <a href="#fnref:6" class="reversefootnote" role="doc-backlink">&#8617;</a></p>
    </li>
    <li id="fn:7" role="doc-endnote">
      <p>Peng, Yun, et al. “Coffe: A code efficiency benchmark for code generation.” FSE 2025. <a href="#fnref:7" class="reversefootnote" role="doc-backlink">&#8617;</a></p>
    </li>
    <li id="fn:8" role="doc-endnote">
      <p>Yang, Borui, et al. “Hallucination Detection in Large Language Models with Metamorphic Relations.” FSE 2025. <a href="#fnref:8" class="reversefootnote" role="doc-backlink">&#8617;</a></p>
    </li>
    <li id="fn:9" role="doc-endnote">
      <p>Wang, Yanlin, et al. “Beyond functional correctness: Investigating coding style inconsistencies in large language models.” FSE 2025. <a href="#fnref:9" class="reversefootnote" role="doc-backlink">&#8617;</a></p>
    </li>
    <li id="fn:10" role="doc-endnote">
      <p>Wang, Chaozheng, et al. “Beyond PEFT: Layer-Wise Optimization for More Effective and Efficient Large Code Model Tuning.” FSE 2025. <a href="#fnref:10" class="reversefootnote" role="doc-backlink">&#8617;</a></p>
    </li>
  </ol>
</div>]]></content><author><name>류연희</name></author><category term="Trip" /><category term="PLDI2025" /><category term="FSE2025" /><summary type="html"><![CDATA[좋은 기회로 2주 연속으로 큰 국제 학회에 참석하게 되었다. 서울에서 열린 PLDI 와 노르웨이 트론하임에서 열린 FSE 에 연달아 참석하면서 밀도 있게 두 분야의 연구를 접할 수 있었다.]]></summary></entry><entry><title type="html">문제가 문제다(2): 높이 올라가야 멀리 보인다</title><link href="http://prosys.kaist.ac.kr/high-and-far/" rel="alternate" type="text/html" title="문제가 문제다(2): 높이 올라가야 멀리 보인다" /><published>2025-07-03T00:00:00+00:00</published><updated>2025-07-03T00:00:00+00:00</updated><id>http://prosys.kaist.ac.kr/high-and-far</id><content type="html" xml:base="http://prosys.kaist.ac.kr/high-and-far/"><![CDATA[<p><em>(<a href="http://prosys.kaist.ac.kr/sky-and-star">이전 이야기</a>에서 이어진다.)</em></p>

<h2 id="높이-올라가야-멀리-보인다-optimuzz-이야기">높이 올라가야 멀리 보인다: Optimuzz 이야기</h2>
<p>한 가지 문제를 훌륭하게 풀다보면, 여러 좋은 문제들이 눈에 들어온다는 이야기이다.
당면한 문제를 풀 때는 제대로.
잘 되는 것만 쫓지 말고, 안되는 것은 왜 안되는지 확실히 알고 넘어가야 훗날 좋은 문제로 다시 찾아온다.
남들 뒤꽁무니를 따르는 것이 아니라 나만의 길을 제대로 걷고 있다면, 거기서 만나는 풍경도 세상에서 나만 아는 비밀.
거기에 숨겨진 문제는 이 길을 와보지 않은 남들은 발견 못할 신선한 것일 수 밖에.</p>

<p>2023년 한창 <a href="http://prosys.kaist.ac.kr/turbotv/">TurboTV</a>를 만들던 때였다.
졸업한 승완이, 재성이, AWS의 이준영 박사와 함께 작업한 TurboFan의 <a href="https://github.com/prosyslab/pl-wiki/wiki/번역-검산(Translation-Validation)">번역 검산기(translation validation)</a>이다.
번역 검산기란 컴파일러의 최적화가 옳은지 논리적으로 검사하는 기술이다.
컴파일러 최적화는 사용자가 작성한 코드를 좀 더 빠르게 돌아가도록 여기 저기 바꾼다.
하지만 컴파일러에 오류가 있으면 이렇게 바꾸는 과정에서 원래 사람의 의도와 다른 프로그램이 만들어진다.
번역 검산기는 이렇게 바뀌기 전과 후 프로그램이 같은 동작을 하는지를 검사한다.
보통 컴파일러는 매우 크고 복잡한 소프트웨어이기 때문에 현장에서 번역검산기의 도움은 꼭 필요하고, 전세계에서 가장 널리
쓰이는 컴파일러인 LLVM의 개발과정에는 이미 통합되어 있다. (자세한 내용은 <a href="https://github.com/prosyslab/pl-wiki/wiki/TurboTV">여기</a>에)</p>

<p>어느 정도 TurboTV가 완성이 되었다고 생각한 연구 막바지 일이었다.
성능을 평가하고 실제 TurboFan의 오류를 찾기 위해서 마구실행기(fuzzer)와 결합해보기로 했다.
번역검산기의 특성상 오류를 유발하는 입력 프로그램 (즉, 최적화 대상 프로그램) 있어야 해당 오류를 잡아낼 수 있기 때문이다.
TurboFan은 JavaScript 프로그램을 입력으로 받는 컴파일러이다.
JavaScript 프로그램을 자동으로 생성하여 오류를 찾는 기술은 학계에서 제법 오래 발전해 왔기 때문에 최신 기술을 가져다 사용하면 어렵지 않게 우리의 성과를 뽑낼 수 있을거라 생각했다.
마침 구글에서 만들어서 널리 쓰이고 있는 마구실행기가 공개되어 있었다. 아주 제격이라고 생각했다.</p>

<p>하지만 역시 처음엔 쉬워보이는 일도 들여다보면 문제투성이다.
컴파일러의 오류 지점을 이미 알고 있는 실험 상황이었지만, 마구실행기는 그 지점으로 향하는 프로그램을 만들어내지 못했다.
하루를 돌리고, 이틀을 돌려도 오류 근처도 가지 못했다.
컴파일러가 너무나 복잡하고 큰 프로그램인데다가 JavaScript 언어도 복잡해서 탐색 공간이 너무 넓은 것이 문제였다.
마구실행기는 순전히 무작위로 프로그램을 생성하니까 사막에서 바늘 찾는 것과 다를 바가 없었다.
이 연구의 초점은 마구실행기의 성능이 아니었기 때문에 일단은 이 문제를 묻어두기로 했다.
마구실행기를 우리 상황에 맞게 수동으로 튜닝하고 TurboTV의 성능을 평가하는 것으로 실험을 마무리 했다.</p>

<p>2023년 8월에 TurboTV 논문을 ICSE에 제출하고 나서 마구실행기와 번역검산기를 결합하는 문제를 골똘히 생각해 보았다.
제한된 실험 환경에서도 그 정도 탐색 능력이라면, 실제 현장에서 숨은 오류를 잘 찾아내지 못할게 분명했다.
살펴보니 번역 검산기가 현장에서 쓰이고 있기는 하지만 입력은 늘 사람이 만들어 주는 듯 했다.
개발자들이 직접 컴파일러를 수정하고, 변경한 지점을 거치는 입력을 손수 한 두개 만들어 주는게 현실이었다.
그러다보니 숨은 오류를 놓치는 경우도 많았다. 이걸 자동으로 해야하지 않을까?
효율적인 번역검산을 위해서 특정 최적화를 일으키는 프로그램을 마구 생산하는 기술이 필요하지 않을까?
이런 문제는 아무도 제대로 집중하고 있지 않은 듯 했다.
우리가 TurboTV를 만드는 길을 갔기에, 그 와중에 마구실행기와 번역검산기를 결합하는 선택을 했기에 가능했던 흔치 않은 시선이라고 본다.
또한 마침 프로그램의 특정 지점에 집중하는 입력을 만드는 비슷한 연구가 연구실에서 활발히 진행되고 있었다.
<a href="http://prosys.kaist.ac.kr/dafl-story">지향성 퍼징</a>,
<a href="http://prosys.kaist.ac.kr/sky-and-star">지향성 단위 테스트 생성기</a>에 이어
최적화 지향성 컴파일러 입력 생성기까지.
“지향성” 3부작이 완성되는 순간이었다.</p>

<p>우리만의 뚜렷한 시선을 갖추니 새로운 기회도 보였다.
우연히 페이스북에서 본 Amazon 연구상 공고였다.
Amazon 연구상은 정기적으로 몇 개 분야를 정해서 연구제안서를 공모하고 그 중 우수한 연구에 연구비를 지원하는 프로그램이다.
과거 몇 년간 우리 분야의 공모는 없어서 신경을 안쓰고 지냈던 차였다.
그런데 마침 그 해 뜬 자동 검증(automated reasoning) 분야의 공모가 내 눈길을 사로잡았다.
마침 기존 연구비도 다 떨어져가던 차라 새로운 제안서를 써야하기도 했고, 우리의 시선이 얼마나 제대로인지 외부에 확인해보고 싶기도 했다.
기쁜 마음으로 제안서를 써내려갔다.
“최적화 지향성 컴파일러 입력 생성기”를 중심으로 컴파일러 안전성을 효율적으로 검사하는 방법에 관해 밑그림을 그렸다.
TurboTV를 만들었던 학생들과 이준영 박사의 도움 덕분에 일필휘지였다.
그 해 겨울, ICSE에 제출했던 논문도 채택이 되었고, 다음 봄이 되자 예상대로 Amazon에서도 수상작으로 선정해주었다.
문제의 중요성을 모두 인정해 준 것이다.</p>

<p>그 때부터는 거침없는 항해였다.
TurboTV를 함께 만든 <a href="https://doitman.kr">재성</a>이와 당시 학부 연구생으로 들어와 지금은 대학원생이된 <a href="https://bongjunj.github.io">봉준</a>이가 앞장섰다.
번역검산과 컴파일러 전문가인 이준영 박사도 여전히 함께하여 큰 도움을 주었다.
재성이와 봉준이는 거리낌없이 치고나가면서 앞에 놓인 장애물을 매주 차근차근 부수기 시작했다.
그렇게 <a href="https://prosys.kaist.ac.kr/optimuzz/">Optimuzz</a> 프로젝트가 시작되었다.
어느정도 시스템이 성숙하자 야생으로 나가보기로 했다.
세상에서 가장 널리 쓰이는 컴파일러인 LLVM에 우리 기술을 적용해 봤더니 오류가 무더기로 쏟아져 나왔다.
TurboFan에서도 기존보다 월등히 나은 성능을 보였다.
성공적인 기술임을 확신했다. 약 1년 정도 연구를 거쳐 2024년 11월, 결과를 PLDI에 제출했다.
역시나 다들 우리의 시선에 공감했다. 평가는 매우 긍정적이었고 무난하게 채택되었다. 특히, 아래와 같은 심사평이 뿌듯했다:</p>
<blockquote>
  <p>It opens a new direction of compiler fuzzing, i.e., guided compiler fuzzing. (Reviewer A)</p>

  <p>To my knowledge, one of the first (if not the first) work to apply guided fuzzing to test complex software like compiler optimizations. (Reviewer B)</p>
</blockquote>

<p>봉준호 감독은 <기생충>으로 아카데미상을 받았을 때, 우상인 마틴 스코세이지 감독 앞에서 그의 말을 빌려 수상 소감을 전했다.</기생충></p>
<blockquote>
  <p>가장 개인적인 것이 가장 창의적인 것이다</p>
</blockquote>

<p>유명한 사람이 하는 것, 요새 유행하는 것을 쫓는다면 쉽게 2류까지는 될 수 있을 것이다.
하지만 분야를 막론하고 창의적인 생각은 (가령, 영화 감독에게는 영화 주제) 남의 뒤통수에 있지 않은 것이 분명하다.
현재 맡은 일에 충실하면서 내 안의 자그마한 소리에 귀를 기울여야 누구도 발견하지 못한 색을 갖게 된다.</p>

<p>나만의 길을 개척해가는 수레바퀴는 멈추지 않고 돌아갈 것이다. 파고들면 들수록 세상에 나만 아는 비밀로 가득할 것이다.
가슴 벅차지 않은가? 세상에 나만 아는 비밀이 있다는 것. 그리고 곧 그 비밀을 모두에게 자랑스럽게 이야기해 줄 수 있는 기회가 있다는 것.
이번 연구를 통해 우리는 또 다른 비밀 하나를 발견하고 파헤치느라 설레는 중이다. 과학자는 이러한 비밀이 밑천이다.
과연 과학자만 그럴까? 시인 이상도 소설 <실화>에서 이렇게 말했다:</실화></p>
<blockquote>
  <p>사람이 비밀이 없다는 것은 재산 없는 것처럼 가난하고 허전한 일이다.</p>
</blockquote>]]></content><author><name>허기홍</name></author><category term="연구" /><category term="문제찾기" /><category term="Optimuzz" /><summary type="html"><![CDATA[(이전 이야기에서 이어진다.)]]></summary></entry><entry><title type="html">문제가 문제다(1): 하늘을 보아야 별을 딴다</title><link href="http://prosys.kaist.ac.kr/sky-and-star/" rel="alternate" type="text/html" title="문제가 문제다(1): 하늘을 보아야 별을 딴다" /><published>2025-07-03T00:00:00+00:00</published><updated>2025-07-03T00:00:00+00:00</updated><id>http://prosys.kaist.ac.kr/sky-and-star</id><content type="html" xml:base="http://prosys.kaist.ac.kr/sky-and-star/"><![CDATA[<h2 id="들어가며">들어가며</h2>
<p>초보 대학원생을 위한 여러 길잡이 책과 강연에 빼놓지 않고 등장하는 것은 연구 문제를 찾는 방법과 과정이다.
초,중,고, 그리고 대학 학부 과정까지는 주로 주어진 문제를 잘 푸는 능력을 기른다. 반면, 대학원 과정에서는
스스로 좋은 문제를 찾고 정의하는 능력을 기르는 것이 훨씬 중요하다. 인류 지성이 아직 도달하지 못한 저 경계
너머 컴컴한 어둠 속을 탐험하는 것이 석박사들의 역할이기 때문이다. 백미터를 제 아무리 빨리 달리는 사람도
거기서는 소용이 없다. 학창시절 빨리 달리기를 배운 까닭은 그 경계까지 무사히 도달하기 위함일 뿐. 경계를 넘어선
이후부터는 딛고 선 곳이 직선 코스인지, 곡선 코스인지, 물인지, 낭떠러지인지 그 누구도 모르기 때문이다.
대학원에서 좋은 문제를 찾는 것이란, 이러한 어둠 속에서 작은 놀이터를 하나 세워서 인류가 여태껏 도달한 지식의 경계를
확장하는 것이라 할 수 있겠다. 많은 사람이 오랫동안 마음껏 뛰놀 수 있도록 튼튼하고도 놀거리가 가득하면 더욱 좋다.</p>

<p>예상하다시피 좋은 문제를 찾는 것은 쉬운 일이 아니다. 그러다보니 대학원에서 좋은 문제를 찾는 것과 관련된 수많은 지혜가
이미 서점과 인터넷에 널려있다. 그런데도 하루가 멀다하고 또 다른 조언이 나타나고 사람들은 이에 귀를 기울인다.
더 이상 새로운 게 있을까 싶은 데도 어김없이 나오는 다이어트 비법서같다. 사실 다이어트건 연구 문제 찾기이건 핵심 비법은
매우 간단하다.</p>
<blockquote>
  <p>“살을 빼고 싶은 자여, 음식을 적게 섭취하고 운동을 많이 하세요.”<br />
“훌륭한 연구를 하고 싶은 자여, 호기심으로 세상을 보고 과감히 도전하세요.”</p>
</blockquote>

<p>당연히 뼈에 새기고 마음에 새겨야할 만고불변 진리이다. 다만, 현실에서는 그 진리가 다양한 길을 통해 다양한 양상으로 발현이 된다. 공통된 진리를 향해 가더라도 모두 가는 길이 다르고 만나는 풍경이 살짝 다르다. 그래서 비법서에 적힌대로 해도 안되는 경우도 있고, 비법서 없이 덤볐는데 잘 되는 경우도 있다.</p>

<p>이 글에서는 최근 우리 연구진이 더듬어 찾은 길과 그 여정을 이야기하고자 한다.
진리가 담긴 경전도 좋지만, 평범한 사람들의 생생한 실제 이야기가 더 가까이 와닿는 법.
비슷한 길을 가는 사람들에게 소박한 참고서가 되었으면 한다.
아래 두 가지 비슷하고도 다른 연구 이야기이다:</p>
<ul>
  <li><a href="https://prosys.kaist.ac.kr/unitcon/">UnitCon: 목표 지향성 단위 테스트 생성기</a></li>
  <li><a href="https://prosys.kaist.ac.kr/optimuzz">Optimuzz: 최적화 지향성 컴파일러 테스트 코드 생성기</a></li>
</ul>

<h2 id="하늘을-보아야-별을-딴다-unitcon-이야기">하늘을 보아야 별을 딴다: UnitCon 이야기</h2>

<p>가만 있지말고 뭐라도 하자는 이야기이다. 대신 남이 정해준 관점이 아니라 자기만의 시선으로. 새로운 연구 주제를 찾는답시고
논문만 줄기차게 읽고 있는 사람들이 있다. 나는 반대다. 물론 가만히 앉아있는것 보다는 훨씬 낫지만, 그건 남이 만든 렌즈로
세상을 보는 격이다. 이미 정교하게 관점이 튜닝된, 수많은 길 중 그들이 성공했던 길만을 보여주는 지도다.
그래서 우리 연구실에 들어오는 학생들에게 남의 논문 읽으면서 연구 시작하기를 권하지 않는다.
남들이 지나간 길에서 남은 고기가 뭐 없나 뒤지는 하이에나가 되길 원치 않으므로. 대신 넓은 초원, 야생 한복판에서 부지런히
뛰어다니며 근육을 기르길 권한다.
우리 연구 분야로 따지만 유명 소프트웨어 GitHub 저장소의 버그 리포트 뒤져보기, 최신 보안 오류 살펴보기, 혹은 소프트웨어
개발 회사에서 일하는 지인의 고충 들어보기, 다른 분야 사람들의 속사정 들여다 보기. 분명 그들을 빡치게 하는 문제가
있을 것이다 (<a href="https://kihongheo.kaist.ac.kr/recruitment.html">아니 제길 시리즈</a> 참고).
최근 발표된 제 아무리 우수한 논문도 해결하지 못하는, 당장 오늘 개발자 속을 썩이는 문제.
그것이 우리의 사냥감이다. 처음엔 허구헌날 사냥에 실패하여 굶는 날이 많겠지만, 곧 나만의 길을 개척하여 크고 싱싱한 고기를 자주 맛보게 될테니.</p>

<p>이 이야기는 꽤 오래전 2022년 2월로 거슬러 올라간다. 당시 (지금도 마찬가지) 연구실의 관심사는 소프트웨어를 개발해 가는
환경에서 지속적으로 변모하는 (이른 바, CI/CD 환경) 프로그램이 안전한지 늘 검사하는 것이었다. 현장의 프로그램은 하루에도
몇번씩 바뀐다. 다양한 기능 개선, 오류 수정, 코드 정리가 일어난다. 더구나 수많은 개발자들이 협업하며 소프트웨어를 개발하기
때문에, 나도 모르는 새에 동료가 프로그램을 바꿔놓기도 한다. 따라서 그 거대한 프로그램의 시시각각 변화 과정을 사람이 모두
파악하기는 사실상 불가능하다. 자동 도구가 반드시 필요하다.</p>

<p>당시에 이런 문제를 해결하는 기반 기술 중 하나로 <a href="http://prosys.kaist.ac.kr/dafl-story/">지향성 마구실행 기법(directed fuzzing)</a> 연구를 한창 진행중이었다.
오류 의심 지점이 주어지면 그 오류를 발현하는 입력을 자동으로 생성하는 기법이다.
하지만 그 오류 의심 지점을 자동으로 찾는 것은 미뤄둔 상태였다.
당시 갓 석사로 입학한 <a href="https://sujin0529.github.io">수진</a>이가 이를 살펴보기로 했다.
소프트웨어 개발 중 코드가 변했을 때 그 변화 때문에 유발되는 오류 의심 지점을 정확하게 집어낼 수 있는가?
실제 오류는 소수이지만 터무니 없는 후보 지점을 너무 많이 고른다면 (가령 수천개) 실제에서 큰 의미가 없을 것이다.
하지만 정적 분석기를 이용하면 어느 정도 의심도가 높은 지점을 정확하게 골라낼 수 있을 거라고 보았다.
그리고 우리는 향후 1-2년간 그런 분석 기술을 만들고 있을 것 같았다. 그때까진 그렇게 생각했다.</p>

<p>메타에서 개발하여 널리 쓰이고 있는 정적 분석기 Infer를 갖고 현 최고 수준이 어느정도 되는지를 가늠해보기로 했다.
여러 유명 프로그램에 있는 이미 알려진 오류를 Infer가 잘 잡아내는가? 메타에서 발표한 논문에 따르면 성능이 매우 좋다고 한다.
하지만 논문 밖 진짜 세상 이야기가 궁금했다. 처음 다루어 보는 도구가 익숙하지 않았겠지만 수진이가 끈기있게 하나하나 조사해갔다.
꼬박 한학기가 걸렸던 것으로 생각한다. 우리의 관찰에 따르면, 많은 경우 오류를 잡아내지 못하였다. 논문만 들여다 보아서는 알 수 없었을 결과이다. 하지만 이것은 논문의 주장이 잘못되었다는 것이 결코 아니다. 모든 경우에 다 잘 통하는 기술이라면 진작에 연구거리도 아니었을 것. 그들은 그들의 길에서 그들의 문제를 잘 푼 것이고, 우리는 우리의 길에서 또 다른 문제를 만나고 있을 뿐이다. 그리고 이런 것들이 모두 모여 기술이 발전한다.</p>

<p>한 학기동안 세상의 온갖 오류를 한껏 만나보고 나니 우리는 미처 생각치 못했던 것을 보게 되었다.
우리가 살펴본 대부분 프로그램은 라이브러리 프로그램이었다.
이런 프로그램의 오류를 발현 시키기 위해서는 오류가 있는 라이브러리 함수를 사용하는 또 다른 “프로그램”을 만들어내야 했다.
반면, 기존에 우리가 연구하던 지향성 마구실행 기술은 입력으로 “값(예: 문자열, 숫자)”을 만들어 내기 때문에 우리가 본 오류에 직접 적용할 수가 없었다.
이런 문제 때문에 특정 의심지점의 오류를 발현 시킬수 있는 작은 “프로그램”, 즉 <a href="https://github.com/prosyslab/pl-wiki/wiki/단위-테스트">단위 테스트(unit test)</a>를
자동으로 생성하는 일을 해야겠다는 생각이 들었다. 이른 바, “지향성 단위 테스트 생성기”이다. 수많은 오류의 이유와 이를 발현시키는 단위 테스트를 하나하나 뜯어본 수진이의 제안이었다. 큰 프로그램의 한 구석에 있는 오류를 이해하는 것은 결코 쉽지 않은 일이다. 깊은 빡침에서 우러 나왔음이 확실하다.</p>

<p>그 때부터 오류 의심 위치 선정은 잠시 미루어두고 발현 프로그램을 합성하는 것에 몰두했다.
그렇게 시작한 <a href="https://prosys.kaist.ac.kr/unitcon">UnitCon</a> 프로젝트의 첫 커밋을 보니 2022년 8월 4일.
문제를 정의하는데 6개월이 걸렸다. 뜨거운 여름 한 가운데로 기억한다.
사실 단위 테스트 자동 생성 기술은 오랜 역사를 지니고 있다.
하지만 지금까지는 대상 프로그램 전체에 숨어있는 오류를 대상으로 마구 테스트를 생성하는 식이었다.
우리처럼 특정한 의심 지점 (가령, 정적 분석 알람, 최신 변경 지점)을 세밀하게 조준하는 기술은 없었다.
우리가 갖고 있는 정적 분석, 프로그램 합성 기술로 가능하리라고 보았다.
가을학기에 <a href="https://yeonhee-ryou.github.io">연희</a>가 합류한 것도 없어선 안될 행운이었다.
정적 분석기를 만들어 보고, 회사에서 실전 코드를 많이 다루어 본 경험이 기술 개발에 큰 도움이 되었다.
수진이가 한땀한땀 살펴본 문제점과 아이디어 조각을 연희가 짜맞추고 확장된 방식으로 정리하면,
내가 반례를 찾고 다시 문제점을 지적하는 작업이 반복됐다.</p>

<p>늘 그렇듯 목표에 도달하기까지는 쉽지 않은 여정이 기다리고 있었다. 1년간 온 힘을 다해서 시스템을 만들었다. 지향성 기술은 기존에 없었지만 최소 무지향성 기술보다는 우리 기술이 월등해야 수월성을 주장할 수 있었다. 하지만 10년간 학계 최고 수준이었던 무지향성 <a href="https://www.evosuite.org">도구</a>를 밑바닥에서부터 출발해 따라잡기란 쉽지 않았다. 2023년 여름을 불태우고 9월 FSE에 제출할 계획이었지만, 제출 당일까지 성능이 좋지 않아 결국 내지 못했다. 같이 아쉬움을 달래던 연구실 앞 잔디밭 가을 바람이 제법 선선했다.</p>

<p>그 이후로도 꼬박 1년이 더 걸렸다. 시스템을 갈고 닦아서 다음 해인 2024년 3월 ICSE에 드디어 제출했지만 결과는 처참했다.
우리의 문제 의식에 공감하지 못했고, 확장성에 의문을 제기했다. 안타까웠지만 어느 정도 납득이 되는 비판도 있었기에,
지적받은 약점을 보완하기로 했다. 학부 연구생이었던 희원이도 참여하여 실험을 돕기 시작했다.
또 다시 치열한 절차탁마가 9월까지 계속 됐다.
학교 앞 중국집 원탁에 앉아 논문의 설명을 가다듬던 날이 선명하다.
이제는 자신있다고 생각하고 FSE에 다시 제출했는데 중간 결과가 또 별로 신통치 않았다.
학생들이 실망하면 어쩌나 싶은 생각이 잠시 들었으나, “그래도 저번보다는 점수가 낫잖아요”라며 팔을 걷어붙이는 모습을 보고는
금방 떨쳐버렸다. 역시 맷집은 두둑한 편이 좋다.
우리는 기술에 자신이 있었기에 중간 결과에 대한 저자의 응답을 쓸 때도 거침이 없었다.
평소보다 더 강하게 우리의 주장을 펼치고 오해를 바로 잡았다. 어느 정도 주장이 먹혀들었는지, 몇 달 후 주요 부분을 개선 후 재제출 (major revision)하라는 결과를 받았다. 건설적인 비판이 많았기에 결과를 기쁘게 받아들이곤 개선 작업에 돌입했다.</p>

<p>2025년 4월, 최종 채택 연락을 받았다. 3년이 훌쩍 지나있었다.
우리가 갈아넣은 시간과 노력이 고스란히 UnitCon 시스템에 녹아들어 세상에 공개되는 순간이다.
덤으로 한 달 뒤에는 우리의 연구가 최우수 논문으로 선정되었다는 기쁜 소식도 날아왔다.
우리가 개선한 내용을 심사위원들 모두가 높이 평가한 것으로 보인다.
재제출본이 심사중이던 2월 아침, 출근해서 일을 처리하던 차에 문득 떠올라 학생들에게 슬랙 메세지를 보낸 적이 있다. 중간 평가에서 이 정도 박한 평가를 받을 연구가 아닌데 이상하다고, 후속 연구에서는 최우수 논문을 받을 수 있을거라는 예언이었다. 생각보다 빨리 실현 되었다.</p>

<p>이제 이 장의 제목을 거짓으로 지은 것에 대해 사과를 해야겠다.
사실 “하늘을 보아야 별을 딴다”는 것은 지나치게 낭만적인 이야기일 수 있다.
더 현실적인 버전은 “하수구에 기어들어가 봐야 벌레를 잡는다” 일 것이다.
많은 공학 분야가 그렇고, 특히 우리처럼 소프트웨어 오류(bug, 벌레)가 연구 대상인 경우 더욱 그렇다. 도서관에 앉아 밤낮으로 백과사전에 있는 벌레 그림만 들여다보아서는 벌레 잡는 기계를 만들 수 없다.</p>

<p>그러니 우리 그만 책을 덮고 하수구 뚜껑을 열자. 더럽고 냄새나는 오물에 눈을 찌푸리자. 튀어나오는 바퀴벌레에 소스라치게 놀라자. 정말 드러워서 못봐주겠다고, 꼴도 보기 싫다고 크게 소리치자. 그렇게 차곡차곡 분노와 불만이 쌓였다면 크게 기뻐하자. 드디어 내가 진심을 다해 풀어야할 문제를 찾은 것이니.
그리고 곧 뚜껑을 깨고 높이 승천할 날이 멀지 않았으니.</p>

<p><em>(두 번째 이야기는 <a href="http://prosys.kaist.ac.kr/high-and-far">여기</a>에서 이어진다.)</em></p>]]></content><author><name>허기홍</name></author><category term="연구" /><category term="문제찾기" /><category term="UnitCon" /><summary type="html"><![CDATA[들어가며 초보 대학원생을 위한 여러 길잡이 책과 강연에 빼놓지 않고 등장하는 것은 연구 문제를 찾는 방법과 과정이다. 초,중,고, 그리고 대학 학부 과정까지는 주로 주어진 문제를 잘 푸는 능력을 기른다. 반면, 대학원 과정에서는 스스로 좋은 문제를 찾고 정의하는 능력을 기르는 것이 훨씬 중요하다. 인류 지성이 아직 도달하지 못한 저 경계 너머 컴컴한 어둠 속을 탐험하는 것이 석박사들의 역할이기 때문이다. 백미터를 제 아무리 빨리 달리는 사람도 거기서는 소용이 없다. 학창시절 빨리 달리기를 배운 까닭은 그 경계까지 무사히 도달하기 위함일 뿐. 경계를 넘어선 이후부터는 딛고 선 곳이 직선 코스인지, 곡선 코스인지, 물인지, 낭떠러지인지 그 누구도 모르기 때문이다. 대학원에서 좋은 문제를 찾는 것이란, 이러한 어둠 속에서 작은 놀이터를 하나 세워서 인류가 여태껏 도달한 지식의 경계를 확장하는 것이라 할 수 있겠다. 많은 사람이 오랫동안 마음껏 뛰놀 수 있도록 튼튼하고도 놀거리가 가득하면 더욱 좋다.]]></summary></entry><entry><title type="html">홈그라운드에서 열린 PL 학회 탐방기</title><link href="http://prosys.kaist.ac.kr/tae-trip-pldi25/" rel="alternate" type="text/html" title="홈그라운드에서 열린 PL 학회 탐방기" /><published>2025-06-30T00:00:00+00:00</published><updated>2025-06-30T00:00:00+00:00</updated><id>http://prosys.kaist.ac.kr/tae-trip-pldi25</id><content type="html" xml:base="http://prosys.kaist.ac.kr/tae-trip-pldi25/"><![CDATA[<table>
  <thead>
    <tr>
      <th style="text-align: center"><img src="https://lh3.googleusercontent.com/pw/AP1GczP_fBuuWRXSZd0S9d8T9Y4ukbjM6clswok8e0TVxZvJ5BKV9QKLs-sh2Jrt_FvldzAQFPg6MmcDhLM6w_2tOhLZWMhMvo2GdI12Vv_NhTXFsZeMPAH298dzIzQrb6PlPCxxKjHJRr1-2IRZfLwyucwo=w2286-h1714-s-no-gm?authuser=0" alt="" /></th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td style="text-align: center"><b>역사적인 순간: 연구실 전원이 참석한 최초의 국제 학회</b></td>
    </tr>
  </tbody>
</table>

<p><br /><br /></p>

<h1 id="들어가며">들어가며</h1>
<p>프로그래밍 언어 분야의 세계 최고 수준 국제 학회 PLDI가 서울에서 열렸다.
학회 첫날, 대전에서 아침 일찍 출발하여 도착한 서울은 비가 내리고 있었다.
우선 악명 높은 출근시간 1호선 지하철을 통해 서울역에서 숙소로 향했다.
학회장에 캐리어를 들고 다니기는 불편하기에 숙소에 짐을 맡긴 후 도보로 학회장까지 이동하였다.
비와 안개가 어우러진 고층 빌딩 숲은 대전 시민에게 이국적인 풍경이었고 새벽부터 시작된 여행의 피로와 함께 마치 외국에 나온 것 같은 기분을 선사하였다.
덕분에 한국에서 열리지만 충분히 낯선 두근거림으로 학회 일정을 시작하게 되었다.</p>

<p><br /><br /></p>

<h1 id="plmw">PLMW</h1>
<p>이번 PLDI는 월요일과 화요일은 워크샵 및 튜토리얼로, 수요일부터 금요일은 본 학회 일정으로 진행되었다.
특이하게 이번 PLMW(Programming Language Mentoring Workshop)는 2일에 걸쳐 진행되어서 월요일과 화요일 모두 PLMW에 참석하였다.
이런 류의 멘토링 워크샵에 여러번 참석해보았고 이전 글에도 소개한적이 있지만, 이번 PLMW는 특히 유익했다.
첫날은 학생들끼리 서로 친해지고 교류할 수 있는 순서로 구성되었고, 둘째날은 교수님들의 강연으로 구성되었다.
첫날에 다양한 사람들을 만난 덕분에 이후 학회 일정동안 다시 마주칠 때마다 편하게 인사하고 대화할 수 있었다.</p>

<h2 id="plmw-첫째날">PLMW 첫째날</h2>
<p>크게 두 순서가 있었다. PL Cards 와 Skill Exchange.
이름만 봤을 때 무슨 활동인지 짐작이 가는가?
홈페이지에도 순서 이름을 제외하고는 아무 설명도 없어서 전혀 감이 오지 않아서 모두 궁금해했다.</p>

<p>우선 PL Cards는 아이스 브레이킹용 게임이었다.
일종의 몸으로 말해요와 비슷한 게임인데, 프로그래밍 언어(PL) 분야의 다양한 용어를 설명해야 하는 게임이었다.
이 순서를 위해 PL 관련 용어가 적힌 카드가 준비되어 있었는데 각 카드에는 제시어와 5개의 금지어가 적혀 있었다.
이 때, 금지어를 사용하지 않고 자신의 팀에게 제시어를 설명하는 게임이었다.
기억나는 제시어로는 “soundness”, “type”, “lambda calculus” 등이 있었다.
팀을 두 팀으로 나누어 진행하는데, 상대 팀이 제시어를 맞추는 동안은 카드를 볼 수 있기 때문에 관전하는 재미도 쏠쏠했다.
영어로 인해 난이도는 급상승했지만 한국어로 해도 충분히 재미있을 것 같다.
어느 정도 시간이 지나자 학생들이 알아서 새로운 게임을 진행하기도 했는데, 인디언 포커처럼 각자 한장씩 이마에 붙이고 자기 카드가 무엇인지 맞추는 게임이었다.
이것도 재미가 쏠쏠했다.</p>

<p>이 게임의 의의는 크게 세 가지였다.
우선 같은 팀의 학생들끼리 꽤 친해졌다. 아무래도 학회의 첫 일정을 같은 팀으로 함께하다보니 (나름) 돈독한 유대감이 생겼고 이후에도 편하게 말을 걸 수 있었다.
두번째로 PL 용어를 보다 일상적인 용어로 설명해보는 기회가 되었다. 학습의 마지막 단계가 남에게 설명하는 것이라고 하는데, 내가 이 개념을 잘 이해하고 있는지 점검해볼 수 있는 좋은 기회였다.
마지막으로 야 너두? 의 유대감을 느낄 수 있었다. 비록 생긴것도 다 다르고 출신 지역도 다 다르지만 같은 용어를 공유한다는 것은 꽤 재미있는 경험이었다.</p>

<p>두번째 순서는 Skill Exchange였다.
참가자들이 관심있다고 제출한 분야를 진행자들이 적당히 선정하고, 각 분야별로 관심있는 사람들이 모여서 자유롭게 이야기를 나누는 시간이었다.
학회 가면 늘상 하는 일이 모르는 사람 만나서 자기 연구 이야기 하고 남의 연구 이야기를 듣는 것인데, 이번엔 아예 판을 깔아준 것이다.
비유를 하자면 마치 티비 프로그램 “나는 솔로”, 혹은 대전시에서 지원하는 청년만남 지원사업 같은 느낌이다.
나는 프로그램 분석 및 검증 분야를 선택했는데, 약 10명 정도의 학생들과 한 그룹이 되었다.
그 중 기억에 남는 사람은 함수형 프로그래밍 언어(정확히는 하스켈)로 작성된 프로그램을 대상으로 기호 실행을 하는 학생이었다.
기호실행이 필요할 정도의 하스켈 프로그램이 있는 줄도 몰랐지만, 하스켈 프로그램을 위한 기호 실행 기술이 따로 필요하다는 것도 처음 알았다.
학회에 처음 참석하는 학생들이라면 이 순서는 모쏠들에게 “나는 솔로” 프로그램이 유익한 정도로 유익했을 것이다.</p>

<table>
  <thead>
    <tr>
      <th style="text-align: center"><img src="https://lh3.googleusercontent.com/pw/AP1GczPhmV1SK8R9YUkN2cqzQ-hNcrCQKDPZ3Zex4khfnnWDXYIMT19EkfrmGLcFlHuvlzkqpi-brMkYHb9ILpw4HqPZ0Fgz_affibkYykK0wB2lcUYAk8gn5CdHxEQq_FV08Wu2utDrQ8RYNrez72IAPu6W=w868-h651-s-no-gm?authuser=2" alt="" /></th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td style="text-align: center"><b>PL Card 예시</b></td>
    </tr>
  </tbody>
</table>

<h2 id="plmw-둘째날">PLMW 둘째날</h2>
<p>둘째날은 여러 교수님들의 흥미로운 강연으로 구성되었다.
많은 분들이 연구에 대한 각자의 큰 그림과 대학원 생활에 대한 조언을 해주셨다.
유익한 내용이 많았지만 유독 기억에 깊이 남은 몇 가지만 소개하겠다.</p>

<h3 id="mit의-adam-chlipala-교수님">MIT의 Adam Chlipala 교수님</h3>
<p>연구에 대한 상당히 독특한 관점을 가지고 계셨다.
우리가 효과적으로 연구를 하기 위해서는 우리의 사고 방식을 이해할 필요가 있으며, 그 도구는 진화 심리학이라는 것이다.
예를 들어, 인간이 최대로 유지할 수 있는 인간 관계, 즉 Peer Group은 50명 정도라고 한다.
이 때 문제는 인간은 본능적으로 Peer Group의 눈치를 보고 그 안에서의 평판을 중시하는데, 50명의 규모는 혁신적인 아이디어를 수용할만한 다양성이 부족할 수 있다는 것이다.
따라서 이러한 점을 주의하며 연구에 대한 피드백을 최대한 넓은 범위의 사람들에게서 받아야 한다고 조언하였다.
재미있는 점은 이후에도 이 분이 얼마나 이런 관점의 신봉자인지 드러나는 순간이 있었다.
Lean 이라는 증명보조도구 개발자의 키노트 강연 후 질문 시간이었다.
Adam 교수님의 질문은 “수학자들은 마치 운동선수와 같아서 수학 문제 증명의 어려움 그 자체를 즐기는 면이 있는 것 같다. 그런 점에서 Lean이 그 즐거움을 빼았으면 수학자들이 오히려 흥미를 잃지는 않는가?”였다.
나로서는 한번도 생각해보지 않은 신박한 질문이었다.
우리가 풀려는 문제 뿐 아니라 문제를 푸는 우리에 대한 이해도 있어야 문제를 더 잘 풀 수 있다는 관점은 앞으로도 계속 생각해볼 만한 주제인 것 같다.</p>

<h3 id="조지아텍의-qirun-zhang-교수님">조지아텍의 Qirun Zhang 교수님</h3>
<p>이 발표는 컨셉은 대학원을 대학원생을 입력으로, 교수를 출력으로 가지는 함수로 비유하여 대학원 생활을 설명하는 것이었다.
따라서 입력과 출력물을 다양한 관점에서 비교하며 대학원이라는 함수가 어떻게 사람을 바꾸는 지 설명하는데 주안점을 두었다.
그 내용 중 두 가지가 특히 기억에 남았다.</p>

<p>먼저 연구 주제 탐색에 관한 것이다.
Qirun 교수님은 작고 가까운 것에서 시작하고 호기심을 잘 따라가라고 조언해 주었다.
자신의 경우, 처음에는 운영체제 수준의 시스템에 관심이 있었는데 막상 운영체제는 연구할 것이 많이 없어보였다고 한다.
하지만 운영체제같은 큰 프로그램에 발생하는 치명적인 오류가 알고보니 버퍼 오버플로우와 같은 간단한 문제였다는 것을 알게 되었고,
버퍼 오버플로우를 탐지하는 다양한 프로그램 분석 기술이 필요하다는 것을 깨달았다고 한다.
이런 식으로 자신의 최초 관심사에서 시작하여 호기심을 따라가다보면 자연스럽게 연구 주제를 찾을 수 있다는 것이다.</p>

<p>두번째는 글쓰기에 관한 것이다. 조언은 간단했다. 연습만이 살 길이다.
너무나 흔한 조언이지만 Qirun 교수님의 경험이 인상적이라 공유한다.
자신이 첫 논문을 쓸 때는 어떻게 써야 하는 지 전혀 감이 오지 않았다고 한다.
그래서 유명한 논문 몇 편을 선정해서 섹션은 총 몇개인지, 각 섹션에 문단은 몇개인지, 각 문단은 몇 문장으로 이루어져 있는 지 통계를 냈다.
그리고 각 문장의 목적은 무엇인지까지 모두 정리한 후 이를 바탕으로 자신만의 템플릿을 만들어 논문 초안을 작성했다고 한다.
이 방식이 가장 효율적인 방식은 아닐 수 있다.
실제로 이후에도 지도교수님께서 수많은 첨삭을 해주셨다고 한다.
하지만 나는 이 이야기를 들으며 Qirun 교수님이 그 당시에 얼마나 간절했는지 느낄 수 있었다.
얼마나 절실하게 논문을 잘 쓰고 싶었으면 이렇게까지 했을까?
그 간절함이 있었기에 지금 이 자리까지 오신 게 아닐까 생각했다.</p>

<table>
  <thead>
    <tr>
      <th style="text-align: center"><img src="https://lh3.googleusercontent.com/pw/AP1GczP2rpl9xRSpDWAyLZi9UkP4wyXwfgsxuRQdZLGpG30uGzLutkestvZDFH2dkO8pr5qVtOTeSRnU5S9HHUI6yP2UwGBcX0sJZMUY1wFO3MwsQIvqPFKnIoz0pesGs5t2REEucLCa3FDLYkxcI1s9efuN=w651-h868-s-no-gm?authuser=2" alt="" /></th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td style="text-align: center"><b>어마어마한 첨삭 기록.</b></td>
    </tr>
  </tbody>
</table>

<h3 id="퍼듀의-milind-kulkarni-교수님">퍼듀의 Milind Kulkarni 교수님</h3>
<p>발표의 제목은 흥미롭게도 “Regularizing the Irregular”였다.
연구와 인생에 적용되는 요약(Abstraction)이 무엇이며, 요약이 득과 실에 대해 논하는 내용이었다.
요약은 시스템의 세부사항을 숨기고 핵심 원리만 남겨서 이해를 돕거나 요약한 시스템 위에 새로운 시스템을 손쉽게 쌓을 수 있게 하는 것이다.
주로 학술 분야에서 생각하는 요약의 개념을 우리 삶에 빗대어서 함께 다루는 관점이 흥미로웠다.
특히 기억에 남는 것은 요약을 함으로써 우리가 잃는 것에 대한 이야기였다.</p>

<p>먼저 본인은 컴파일러를 연구하는데, 인스트럭션의 재배치를 통한 최적화의 경우, 파이프라이닝 등 숨겨진 하드웨어 수준의 세부 사항이 문제가 되어 오히려 성능이 안 좋아지는 경우가 있다고 한다.
즉 이런 경우는 실제로 필요한 정보가 요약에 의해 가려진 것이다.
따라서 연구자라면 요약을 있는 그대로 받아 들이지 않고 평가할 줄 알아야 하며, 필요한 경우 보다 적당한 수준의 요약을 새로 만들어야 한다고 조언했다.
허기홍 교수님도 항상 다음과 같은 비슷한 조언을 하신다: “사용하는 도구를 블랙박스로 여기지 말고 모든 것을 들춰보고 이해하라”.
내 연구에서 요약으로 인해 숨겨진 것이 무엇인지 파악하고 나도 모르게 있는 그대로 받아들인 요약이 있는지 항상 점검해야겠다.</p>

<p>연구 뿐 아니라 우리 삶에서도 요약이 중요한 정보를 숨기기 마련이다.
예를 들어 Milind 교수님 본인은 학자 집안 출신에, 명문인 코넬 대학을 졸업하였고 현재는 역시 명문인 퍼듀 대학의 교수로 재직 중이다.
이렇게 요약된 정보만 본다면 탄탄대로, 승승장구의 인생이다.
많은 학생들은 이런 커리어를 보며 “나는 이미 시작부터 글러먹었네” 하며 좌절할것이다.
흔히들 말하는 가면 증후군(Imposter Syndrome)을 유발하는 스펙이다.
하지만 실상은 조금 달랐다고 한다.
대학원 시절, 4년간 논문 한편 없었고, 졸업 후에도 미국의 불경기로 인해 2년간 취업이 되지 않았다고 한다.
퍼듀 대학의 면접을 볼 수 있었던 것도 학회에서 만난 인연으로 간신히 기회를 얻은 것이었다.
임용된 이후에도 3년간 과제가 하나도 없었으며 12편의 제안서는 족족 다 떨어졌다고 한다.
우리가 얻을 수 있는 교훈은 무엇일까.
비교를 통해 좌절된다면 우리의 요약 알고리즘을 점검해봐야 한다, 정도가 되겠다.</p>

<h2 id="plmw-소회">PLMW 소회</h2>
<p>벌써 세번째 참석한 멘토링 워크샵인데, 항상 많은 것을 얻어간다.
이번 PLMW는 특히나 학생들끼리의 교류가 많았고 교수님들의 강연도 유익했다.
일정을 마무리해갈 때 즈음 문든 든 생각은 나도 언젠가 이런 멘토링 워크샵을 준비해보고 싶다는 것이었다.
내 경험상 멘토링 워크샵은 다음 두 측면이 어우러질 때 가장 유익한 것 같다.
먼저 연구에 대한 관점을 배우고 고민할 수 있는 장기적인 측면의 도움이다. 교수님들의 진솔한 이야기가 담긴 다양한 발표들이 이런 측면에서 큰 도움이 된다.
그리고 당장 써먹을 수 있는 유용한 기술과 팁이다. 학생들끼리 교류할 수 있는 기회나 발표 잘하는 법, 논문 잘 쓰는 법은 단기적으로 즉각 도움이 된다.
언젠가 나에게 기회가 온다면 이 두 측면을 모두 충족시킬 수 있는 프로그램을 만들고 싶다.</p>

<p><br /><br /></p>

<h1 id="자바스크립트-tc39-그리고-stage-27">자바스크립트, TC39, 그리고 Stage 2.7</h1>
<p>PLMW의 강연 중 10분짜리 짧은 강연이 하나 있었다.
강사는 Mikhail Barash 교수님이었고, 자바스크립트 언어의 표준화 기구인 ECMA-TC39을 소개하는 내용이었다.
배경 설명을 좀 하자면 ECMA는 정보통신 시스템들을 위한 국제 표준화 기구이다.
ECMA 산하에 여러 위원회(Task Committee)가 있는데 그 중 39번째 위원회인 TC39은 자바스크립트 언어의 표준화를 담당하고 있다.
TC39 산하에도 5개의 그룹(Task Group)이 있는데, 그 중 5번째인 TG5는 표준화의 논의와 진행을 담당한다.
그리고 Mikhail 교수님은 TG5의 의장(Convenor)을 맡고 계시다.</p>

<p>ECMA-TC39에 대해서는 류석영 교수님의 ESMETA<sup><a href="#esmeta">1</a></sup>와 그 선행 및 후속 연구들로 인해 몇번 들어보긴 했는데, 제대로 알게 된 것은 이번이 처음이었다.
우선 언어 하나가 성장하고 유지되는데 굉장히 많은 사람의 시간과 노력이 필요하다는 것을 알 수 있었다.
특히 자바스크립트 언어는 브라우저별로 엔진을 따로 개발하기 때문에 표준을 만들어나갈 때 브라우저를 개발하는 산업계의 의견도 굉장히 큰 (사실 제일 큰) 비중을 차지한다.
학계와 산업계가 어우러져 큰 협의체를 구성하고 언어의 발전을 위해 노력하는 모습이 인상적이었다.</p>

<h2 id="자바스크립트-표준화의-이모저모">자바스크립트 표준화의 이모저모</h2>
<p>나중에 Mikhail 교수님께 따로 들은 얘기 중 언어의 표준화 과정에서 발생하는 일들이 특히 흥미로워 소개한다.</p>

<h3 id="표준화-절차">표준화 절차</h3>
<p>우선 표준화 과정은 크게 6단계로 나뉜다. 더 자세한 내용은 TC39 <a href="https://tc39.es/process-document/">공식문서</a>를 참고하면 된다.</p>
<ol>
  <li><strong>Stage 0</strong>: 아이디어 단계. 아이디어가 있으면 누구나 TC39에 제출할 수 있다.</li>
  <li><strong>Stage 1</strong>: 구상 단계. 위원회가 시간을 할애하여 아이디어를 검토하며 구현 방안 및 도입 시 잠재적 문제 등을 살펴본다.</li>
  <li><strong>Stage 2</strong>: 구체화 단계. 어떤 방식으로 아이디어를 구현할 것인지 결정한 상태. 이제 보다 구체적인 디자인과 구현 방안을 논의한다.</li>
  <li><strong>Stage 2.7</strong>: 테스팅 단계. 구현이 완료된 상태로, 스펙도 정의되었다. 예상치 못한 문제가 없는지 이제부터 테스트를 시작한다.</li>
  <li><strong>Stage 3</strong>: 적용 단계. 제안된 아이디어 및 구현을 실제 구현체(브라우저 등에 내장된 엔진)에 적용하기를 제안한다.</li>
  <li><strong>Stage 4</strong>: 완료 단계. 테스트를 모두 통과하는 구현체 2개 이상 등등의 조건을 만족한 상태.</li>
</ol>

<h3 id="의사-결정-과정">의사 결정 과정</h3>
<p>TC39의 의사 결정 과정은 만장일치제를 따른다. 각 단계를 넘어갈 때 마다 위원회가 모여서 논의하고 만장일치로 동의해야 다음 단계로 넘어갈 수 있다.
누군가가 반대한 경우는 매우 적었다고 하는데 (내 기억으로는 1-2 건) 시간이 지난 이후는 모두가 반대한 사람에게 고마워할 정도로 좋은 결정이었다고 한다.
위원회에 사람이 적지 않은데 만장일치제로도 일이 진행된다는 게 의외였다.</p>

<h3 id="대기업의-횡포">대기업의 횡포(?)</h3>
<p>Stage 3의 설명과 Stage 4의 도달 조건을 보면 흥미로운 점이 있다. 여기서부터는 표준화 과정이 위원회의 손을 떠나는 것이다.
왜냐하면 Stage 3은 구현체에의 적용을 <strong>제안</strong> 하는 것이며, 브라우저 만드는 회사들(G사, A사, M사 등등…)이 이를 수용하지 않으면 말짱 꽝인 것이다.
그래서 사실은 기업들이 표준화 과정 최후의 수문장인 것이다.
따라서 자바스크립트의 경우 산업계로부터 외면받는 언어 요소는 구조적으로 표준화될 수 없다.</p>

<h3 id="stage-27-너의-이름은">Stage 2.7, 너의 이름은</h3>
<p>표준화 과정을 보면 뭔가 이상한게 중간에 있다.
그렇다. 2.7이라는 애매한 숫자가 보인다.
Stage 2.7은 가장 최근에 도입된 단계로, Stage 2와 Stage 3 사이에 테스팅을 위한 단계가 필요해서 추가되었다.
그러면 왜 Stage 2.7이 되었을까?
예상외의 매우 긴 논의가 있었지만 간단하게 요약해보겠다. 전체 <a href="https://github.com/tc39/notes/blob/main/meetings/2023-11/november-30.md#continuation-of-the-new-stage-discussion">회의록</a>도 공개되어 있으니 궁금한 사람은 확인해보시길.</p>
<ol>
  <li>우선 2와 3 사이에 추가하는 단계라서 그 사이의 숫자를 고르게 되었다.</li>
  <li>하지만 굳이 따지자면 3단계에 더 가까운 단계라고 생각했기에 2.5보다는 큰 숫자를 주고 싶었다.</li>
  <li>누가 자연상수 e 단계를 제안했다 (2.71…).</li>
  <li>숫자로 된 단계의 통일감을 해치기에 소숫점 첫재 자리만 남긴 2.7이 되었다.</li>
  <li>최종 결정이 된 이후, 누군가 2.62를 생각해냈고 모두가 아쉬워했다 (262는 자바스크립트 표준 문서에 붙은 번호라서 커뮤니티에게 의미있는 숫자다).</li>
</ol>

<p>문제는 이 논의가 3시간이 걸렸다는 것이다. 
테스팅을 위한 단계를 제안한 장본인, Michael Ficarra도 학회에서 만날 수 있었는데, 애초에 Michael은 이제 숫자를 떼고 자연어로 된 단계 이름을 쓰자고 주장했다고 한다.
그리고 저 논의가 이루어진 시간은 자신의 인생에서 가장 비참한 3시간이었다고 농담조로 말했다.</p>

<p>이 이야기의 교훈은 무엇일까?
커뮤니티가 크고 영향력이 큰 언어의 표준화 과정은 신중하고 보수적으로 진행될수밖에 없다는 것이다.
비록 저 3시간은 아까운 시간이었겠지만 TC39 위원회가 일관적으로 가지는 신중한 태도는 분명 지킬 가치가 있다고 생각한다.</p>

<h3 id="다시보는-esmeta">다시보는 ESMETA</h3>
<p>이전까지 류석영 교수님과 박지혁 교수님의 발표를 들을 때는 연구적인 부분에 집중하느라 실제 커뮤니티와 어떻게 협업하였는지는 흘려듣는 경우가 있었는데, 이번에 다시 돌아보는 기회가 되었다.
이 어렵고 까다로운 단계를 모두 거쳐서 자바스크립트 언어 표준의 일부가 된 ESMETA, 그리고 그 과정에 참여한 류석영 교수님과 박지혁 교수님이 더 존경스럽게 느껴졌다.</p>

<table>
  <thead>
    <tr>
      <th style="text-align: center"><img src="https://lh3.googleusercontent.com/pw/AP1GczOJwHSEMdiRegchzBrByuffBNXU4NuCWFJy951V2s2U3MGOc016LmyQ6WVNqlU6wET_Z1w_xyt1QT-Sa7cLhQ9KZG5VegmwR7rf-7wSxR2C2VA_srhlv4-4SDexsUrZHK4kGewjY1c87eWTb2mCN0Ru=w1157-h868-s-no-gm?authuser=2" alt="" /></th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td style="text-align: center"><b>예? 2.7이요?</b></td>
    </tr>
  </tbody>
</table>

<p><br /><br /></p>

<h1 id="흥미로웠던-발표들">흥미로웠던 발표들</h1>

<p><strong>컴파일러 세션</strong> <br />
컴파일러 세션에서 연달아 발표된 두 논문이 매우 흥미로웠다.
논문 제목은 각각 <strong>Exploiting Undefined Behavior in C/C++ Programs for Optimization: A Study on the Performance Impact<sup><a href="#ub">2</a></sup></strong> 와
<strong>Relaxing Alias Analysis: Exploring the Unexplored Space<sup><a href="#alias">3</a></sup></strong> 이다 (발표 영상: <a href="https://youtu.be/ubfPyMCvhXs?list=PLyrlk8Xaylp583e5mz3w2J9fq2u7X2EEB&amp;t=10030">전자</a>, <a href="https://youtu.be/ubfPyMCvhXs?list=PLyrlk8Xaylp583e5mz3w2J9fq2u7X2EEB&amp;t=11237">후자</a>).
미정의 동작 (Undefined Behavior, UB)과 그놈이그놈 분석(Alias Analysis)은 컴파일러 최적화에서 중요한 역할을 한다.
우선 미정의 동작의 경우, 하드웨어 수준에서는 각자 마음대로 구현하되 컴파일러는 미정의된 동작이 일어나지 않는다고 가정하고 최적화를 진행한다.
그 결과 미정의 동작을 일일히 정의하는 것보다 더 폭넓은 최적화가 가능하다. 또한 그놈이그놈 분석을 통해 프로그램의 변수들 간의 관계를 분석하면,
서로 영향을 주는 포인터 변수를 파악할 수 있어 컴파일러가 보다 효율적인 최적화를 진행할 수 있다.
적어도 지금까지 사람들을 그렇게 믿어왔다. 하지만 위 두 논문은 각각의 믿음이 과연 옳은지에 대한 의문을 제기한다.
미정의 동작과 그놈이그놈 분석으로 인한 최적화 이득이 거의 없다는 것을 실험으로 보인 것이다.
기존의 믿음에 대한 도전이라 그런지 질문들도 상당했다. 보통 많아야 두세명인데, 그놈이그놈 분석에 대한 논문의 경우 약 10명의 질문자가 마이크 앞에 줄을 섰다.
이런 반항적이고 도전적인 연구는 항상 존경스러운 것 같다.
이전에 전민석 교수님이 발표한 논문인 <strong>Return of CFA: Call-Site Sensitivity Can Be Superior to Object Sensitivity Even for Object-Oriented Programs<sup><a href="#cfa">3</a></sup></strong> 이 생각이 나기도 했다.</p>

<table>
  <thead>
    <tr>
      <th style="text-align: center"><img src="https://lh3.googleusercontent.com/pw/AP1GczN0Q-RekJYxr7jG6_dfdOn6jTpDQWdgJ-GiBzIm9zuFRa5aSo7HzVXYVhS51a879idg8BDgxw86JCCG96KpCozEP3yZbNO07r2qYbnJL1BT9VIuj7C5dyE6ic2Yx2a6s8eS_BEK1Gt0xTRCvV4iK5O-=w1157-h868-s-no-gm?authuser=2" alt="" /></th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td style="text-align: center"><b>위협적으로 긴 질문 대기줄. 서 있는 사람들이 전부 질문 기회를 기다리고 있다.</b></td>
    </tr>
  </tbody>
</table>

<p><br /></p>

<p><strong>Program Synthesis From Partial Traces<sup><a href="#trace">4</a></sup></strong> : <a href="https://youtu.be/fd59n74kOso?list=PLyrlk8Xaylp583e5mz3w2J9fq2u7X2EEB&amp;t=13622">발표 영상</a> <br />
다른 연구실 동료들도 많이들 흥미롭게 느낀 논문이다.
1 저자인 Margarida가 아마존에서 인턴을 하며 진행한 연구인데, AWS 인스턴스 관리 인터페이스를 기반으로 한 프로그램 합성 연구이다.
직접 사용해본적은 없지만 AWS 인스턴스를 할당 받으면 그래픽 유저 인터페이스를 통해 이를 조작할 수 있다고 한다.
인스턴스를 종료하거나, 재시작하거나, 스크립트를 실행하거나 등등.
이러한 조작 기록들은 연속된 API 호출 기록의 형태로 남는데, 제목의 Trace는 이러한 API 호출 기록을 가리킨다.
일련의 API 호출 기록이 반복되는 경우, 사용자가 반복적으로 같은 목적을 가지고 여러번의 조작을 하고 있다는 것을 의미한다.
따라서 이 논문은 사용자의 편의성을 위해 반복된 API 호출 기록을 기반으로 사용자의 의도를 파악하고 이를 자동으로 수행하는 일종의 매크로를 합성하는 방법을 제안한다.
이 연구에서는 사용 가능한 API를 DSL로 표현하여 프로그램을 합성하였는데, 입력으로 주어진 API 호출 기록을 재현할 수 있는지를 기준으로 결과의 정확성을 평가했다.
자연스레 들었던 의문은 입력으로 주어진 API 호출 기록들이 모두 동일한 의도를 반영하는가였다.
질문해본 결과, 이 연구는 모든 입력이 같은 의도를 반영한다는 가정하에 진행되었다고 한다.
따라서 실생활에 적용하기 위해서는 이 가정을 어떻게 완화할 수 있을 지 고민해봐야 할 것 같다.
API 호출 기록을 사용자 의도 기반으로 잘 묶어내는 기술과, 입력에 노이즈가 섞여 있어도 강건하게 프로그램을 합성하는 기술이 모두 필요할 것 같다.
개인적으로는 아이폰에 있는 단축어(Shortcuts) 앱의 단축어를 자동으로 만들어서 추가해주면 좋겠다는 생각이 들었다.
직접 몇개 추가해본 경험이 있는데, 각 앱마다 사용 가능한 API가 달라서 단축어를 만들기가 쉽지 않았다.</p>

<p><br /></p>

<p><strong>Fast Direct Manipulation Programming with Patch-Reconciliation Correspondence<sup><a href="#6">5</a></sup></strong> : <a href="https://youtu.be/y6zqh2IXcYA?list=PLyrlk8Xaylp583e5mz3w2J9fq2u7X2EEB&amp;t=8872">발표 영상</a> <br />
이 논문은 패치가 적용될 때, 패치가 가져올 결과의 변화를 직접 기존 결과에 적용하여 추가 실행 없이 패치된 프로그램의 결과를 얻을 수 있는 기술을 제안한다.
이렇게만 말하면 꿈만 같은 기술이다. 퇴행 검사 (Regression Testing) 비용이 비싸다는 말은 이제 옛말이다.
아쉽지만 이 기술은 특수한 도메인에만 적용이 가능하다 (물론 여전히 유용한 기술이다).
이 연구에서 타겟으로 잡은 도메인은 방대한 데이터를 처리하는 시각화 프로그램이다 (<a href="https://data-nifc.opendata.arcgis.com/datasets/29185087b4594a35abe059cbdbf97ee4_1/explore">예시</a>).
이런 프로그램은 대개 사용자가 옵션을 선택하여 시각화 결과를 변경할 수 있다.
이 옵션의 조합은 쿼리의 형태로 표현되며 이 쿼리는 일종의 프로그램으로 볼 수 있다.
그렇다면 옵션이 바뀌는 것은? 기존 쿼리에 패치가 적용되는 것으로 볼 수 있다.
따라서 패치로 인한 쿼리의 구문(Syntax) 변화에 따른 의미(Semantic) 변화를 정의할 수 있다면 작은 의미 변화만을 기존 결과에 적용하여 전체 쿼리를 다시 처리하는 것보다 더 효율적으로 결과를 얻을 수 있다.
일반적인 프로그램에 이를 적용할 수 없는 이유는 구문 변화에 따른 의미 변화를 기존 결과에 직접 적용하기 어려운 경우가 많기 때문이다.
이 연구에서는 시각화 프로그램의 쿼리 언어에 대한 구문 변화와 의미 변화를 정의하고, 이를 기존 결과에 적용하는 방법을 제안했기 때문에 한정된 도메인에서 좋은 결과가 있었던 것 같다.</p>

<p><br /></p>

<p><strong>DR.FIX: Automatically Fixing Data Races at Industry Scale<sup><a href="#patch">7</a></sup></strong> : <a href="https://youtu.be/y6zqh2IXcYA?list=PLyrlk8Xaylp583e5mz3w2J9fq2u7X2EEB&amp;t=12357">발표 영상</a> <br />
우버에서 진행한 자동 프로그램 수정 연구이다.
제목은 데이터레이스 오류를 잡는다곤 하지만 딱히 특정 오류 타입에 특화된 연구는 아니었다.
기존에 우리 연구실에서 창공님과 재호가 연구하던 패치 이식 연구와 유사하지만 좀 더 단순한 방식의 기술이었다.
먼저, 오류 코드와 해당 오류가 수정된 코드의 쌍을 데이터 베이스에 모은다.
그 후, 새로운 오류가 검출되면 데이터베이스에서 유사한 오류 코드를 찾는다 (이 때 코드를 벡터화 해서 비교한다).
마지막으로 기존 오류 코드, 수정된 코드, 새로운 오류 코드를 모두 LLM에게 던져주고 알아서 고치게 한다.
우선 LLM을 활용하는 방식이 너무 단순해서 아쉬웠다.
이 기법이 오류를 수정하지 못한 케이스 1위가 여러 파일에 걸친 수정이 필요한 경우라고 하는데, 기존 패치를 잘 요약해서 옯겨오는 기술이 없어서 그런 것 같다.
창공님과 재호의 방식은 오히려 여러 파일에 걸친 패치도 잘 했던 걸로 기억한다.
확실히 패치 및 오류 패턴을 요약하는 기술이 있으면 더 잘할 수 있을것이다.
기술적으로 아쉬운 점은 있었지만 예상치 못한 회사에서 이런 연구를 진행하고 있기에 나름 긍정적으로 생각했다.</p>

<p><br /><br /></p>

<h2 id="홈그라운드에서-진행한-국제-학회">홈그라운드에서 진행한 국제 학회</h2>
<p>정말 감사하게도 지금까지 좋은 기회를 많이 얻어 이번이 벌써 여섯번째 국제 학회 참석이다.
그런데 이번에 유독 이전 학회와 큰 차이를 느낀 바가 있어 이야기를 해보고자 한다.
나는 그리 외향적이지 않은 사람으로써 한계를 극복하기 위해 네트워킹에 상당한 공을 들이고 나름 고민을 많이 한다.
그 결과 연구실에서 네트워킹을 주제로 실습을 곁들인 <a href="https://prosys.kaist.ac.kr/assets/pdfs/networking.pdf">발표</a>도 했으며 최근에는 이를 <a href="https://prosys.kaist.ac.kr/networking-guide/">글</a>로 정리하기도 했다.
하지만 정작 나도 항상 이론과 실재의 괴리를 느끼곤 했다. 일대일은 이제 어느정도 익숙해졌지만, 여러 사람이 모인 자리에서의 네트워킹은 여전히 어렵고 불편했다.
그런데 이번에는 그 어느 때보다도 네트워킹이 쉬웠고 적극적으로 지금까지 상상했던 모든 것을 시도해볼 수 있었다.
자연스럽게 사람들이 앉아 있는 식탁에 앉으며 대화에 참여했으며 여러 사람이 둘러서서 이야기하는 곳에도 가서 은근슬쩍 대화에 참여했다.
그 이유를 곰곰히 생각해본 결과 이번 학회가 국내에서 진행되었기 때문이라는 결론에 도달했다.</p>

<h3 id="소속감이-주는-자신감">소속감이 주는 자신감</h3>
<p>국내에서 진행되는 학회는 어떤 차이가 있을까?
우선 자연스러운 소속감(Sense of belonging)을 느낀다.
좀 더 풀어서 말하자면, 마땅히 이 자리에 있어도 될 자격을 얻은 것 같은 느낌이다.
좀 과장해서 비유하자면 마치 미국 영화에 나오는 파티의 주최자가 자연스럽게 돌아다니며 파티 참가자들에게 말을 걸고 인사를 하는 것과 비슷하다.
이런 소속감은 내가 이 학회에 참석할 자격이 있다고 느끼게 해준다.
이전까지는 무의식적으로 내 자격에 대해 의구심을 가지고 있었던 것 같다.
이런 의구심은 나를 위축시키고, 네트워킹을 시도하는데 방해가 되었다.
이번 여행기를 준비하다가 고려대학교의 오학주 교수님이 작성하신 2012년 PLDI <a href="https://prl.korea.ac.kr/reports/pldi12.pdf">여행기</a>를 읽게 되었는데, 아래와 같은 문구에서 비슷한 심경을 읽어낼 수 있었다.</p>

<blockquote>
  <p>거의 대부분의 논문을 미국대학에서 발표했기 때문에 마치 미국인들만의 잔치에 구경을 왔다는 인상을 받았다</p>
</blockquote>

<h3 id="모두에게-소속감을">모두에게 소속감을</h3>
<p>소속감을 느껴보기 전까지는 나에게 부족한 것이 무엇이었는지조차 몰랐다.
그리고 문득 깨달은 바가 있어 이 또한 이야기를 해보고자 한다.
사실 이전까지는 커뮤니티 내의 소수자들에 대한 다양한 지원의 필요성을 크게 느끼지도, 공감하지도 못했다.
예를 들어 소수자들을 위한 점심식사 등.
그러나 이제는 이런 지원들이 소수자 구성원들에게 소속감을 느끼게 해주고, 그로 인해 자신감을 줄 수 있겠다는 생각이 든다.
개인적인 생각으로 SE 학회들처럼 진취적으로 분야 불모지에 찾아가서 학회를 개최하는 것도 좋고, 소수자들이 커뮤니티 내에서 주도적인 역할을 맡게 하는 것이 소속감과 참여의 당위성을 느끼게 해주는 좋은 방법이라고 생각한다.</p>

<h3 id="감사의-말씀">감사의 말씀</h3>
<p>PLDI가 한국에서 열릴 수 있도록 수고해주신 허충길 교수님, 김지응 교수님, 그리고 다른 많은 분들께 감사의 말씀을 드린다.</p>

<p><br /><br /></p>

<h1 id="잡다한-이야기">잡다한 이야기</h1>

<h3 id="경복궁-러닝">경복궁 러닝</h3>
<p>요즘 러닝에 취미를 들여서 서울에 올라간 김에 경복궁을 돌았다.
누가 말하길 우리 조상들이 후손 러너들을 위해 경복궁 한바퀴를 2.5km의 적당한 업힐-다운힐 코스로 설계했다고 한다.
내 수준으로는 두 바퀴가 적당한 운동이었다.
거리는 적당했으나 내 수준으로는 적당한 업힐이 아니었다. 상당히 가파르다…</p>

<table>
  <thead>
    <tr>
      <th style="text-align: center"><img src="https://lh3.googleusercontent.com/pw/AP1GczPP3OCzKonS4LtHoWusuLv7SlFDf5SWWw2usOQTKN7adA3nm6BSFqPGdxPcPOCSmuGTpypk6Oh9YWMBlyGbruX4nVjXma7G8qvm_aJXnQnjiGiExC7u1RjVnmiJnSnV9jjPiaCq7FUpeB9VB4JbNYUn=w651-h868-s-no-gm?authuser=2" alt="" /></th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td style="text-align: center"><b>광화문 전경</b></td>
    </tr>
  </tbody>
</table>

<table>
  <thead>
    <tr>
      <th style="text-align: center"><img src="https://lh3.googleusercontent.com/pw/AP1GczNRDk0c5ElcKMoDJLLwdKffctS5AisfuS64f119m21ovWNbfLkIYC1_1r3pMe10k2beNbCrm3KsgEGXagSvvTFsbSI8fFh5yRLNoWPG0s-UW07PSRvHIEx6MzMJ7B209hSevi-l9-uf7W_vjJVBZ1aG=w401-h868-s-no-gm?authuser=2" alt="" /></th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td style="text-align: center"><b>5km 러닝</b></td>
    </tr>
  </tbody>
</table>

<h3 id="선방하는-한국">선방하는 한국</h3>
<p>우리나라는 이번에 압도적 참가자 수 1위를 차지했다.
원래 어디에서 개최하던 미국과 중국이 압도적 참가자 수를 기록했는데, 놀랍게도 한국이 1위를 차지했다.</p>

<table>
  <thead>
    <tr>
      <th style="text-align: center"><img src="https://lh3.googleusercontent.com/pw/AP1GczNeJe5ODcAbleXAYJdjXzLaOx4-HfkHv1DQpJQiz4HhYesfCWV1xqxW1RgWBb-ue7AvRDx0duqjpEzRvktcxzRACPpp_gFRV2W3H7NdcGnEDecm9TXmbd6gwWXp_k5GpddkqcgHASXm6QY79MMqP_nP=w1157-h868-s-no-gm?authuser=2" alt="" /></th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td style="text-align: center"><b>참가자 수 1위!</b></td>
    </tr>
  </tbody>
</table>

<h3 id="환상적인-음식">환상적인 음식</h3>
<p>학회 기간 내내 음식이 정말 맛있었다.
듣기로는 참가비가 거의 식비로 나갔다고 한다 (믿거나 말거나).
넉넉한 한국의 인심을 세계에 알리는 좋은 기회가 되었다.</p>

<table>
  <thead>
    <tr>
      <th style="text-align: center"><img src="https://lh3.googleusercontent.com/pw/AP1GczN8hJlDBc2aHK1fwpAzRSLSRWISXqpq-WMEEbBlbyZR0OqyzMjOvRL35I13feWsKsv5ewBVQbvHkrwHKvp-fevhYh5_InruRJAHkEagkGiTvP1ncJQReT8AbIfZCUPyxa34DSx4XGnwIe_tGUwIpzv5=w651-h868-s-no-gm?authuser=2" alt="" /></th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td style="text-align: center"><b>점심 1</b></td>
    </tr>
  </tbody>
</table>

<table>
  <thead>
    <tr>
      <th style="text-align: center"><img src="https://lh3.googleusercontent.com/pw/AP1GczOLF2K-MzHoEwHMeMGxEsVEsRIaYle8YGUaKvHocgb8axQSZklR2DNFdwn1Ijal7rxBgAGBneUiI97W6n8s0b6rXKulIFcySd0NvlPOOnS7jOCFqdTIwvhxPOCehsTs5JIDbOMLB7UZ31T5LmZPw4DY=w651-h868-s-no-gm?authuser=2" alt="" /></th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td style="text-align: center"><b>점심 2</b></td>
    </tr>
  </tbody>
</table>

<table>
  <thead>
    <tr>
      <th style="text-align: center"><img src="https://lh3.googleusercontent.com/pw/AP1GczPL9ggAeH0jDPCMRWSpDPPOX4-zQtYQ-RisnwSi7yLJi1fxa2PH870jjElV-CXtJd8qZ5g-J7NiMyuIhL5RJ_mnvncCNolNHkgCCEgwdP-sOpoJATDtm6spYvYroo-_jRuT1pB2OK1x426DvxUida3i=w1157-h868-s-no-gm?authuser=2" alt="" /></th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td style="text-align: center"><b>뱅큇 코스 요리의 에피타이저. 이후는 너무 맛있게 먹느라 사진을 못 찍었다.</b></td>
    </tr>
  </tbody>
</table>

<p><br /><br /></p>

<h1 id="돌아오며">돌아오며</h1>
<p>연구실 구성원 모두가 함께 할 수 있는 학회였기에 더 특별했던 것 같다.
이번 학회 출장이 가능할 수 있도록 훌륭한 논문을 내주신 교수님과 재성이, 그리고 특히 발표로 수고한 봉준님께 감사드린다.
아낌없이 예산을 지원해주신 교수님께 다시 감사드린다.
지원해주신 덕분에 정말 귀하고 소중한 기회를 얻을 수 있었고, 그 기회를 통해 많은 것을 배우고 느낄 수 있었다.</p>

<p><br /><br />
<br /><br />
<br /><br /></p>

<hr />

<h3 id="각주">각주</h3>
<p>[<a name="esmeta">1</a>] Sukyoung Ryu and Jihyeok Park, “JavaScript Language Design and Implementation in Tandem” CACM (2024) <br />
[<a name="ub">2</a>] Lucian Popescu and Nuno P. Lopes, “Exploiting Undefined Behavior in C/C++ Programs for Optimization: A Study on the Performance Impact” PLDI (2025) <br />
[<a name="alias">3</a>] Michel Weber et al., “Relaxing Alias Analysis: Exploring the Unexplored Space” PLDI (2025) <br />
[<a name="cfa">4</a>] Minseok Jeon and Hakjoo Oh, “Return of CFA: Call-Site Sensitivity Can Be Superior to Object Sensitivity Even for Object-Oriented Programs” POPL (2022) <br />
[<a name="trace">5</a>] Margarida Ferreira et al., “Program Synthesis From Partial Traces” PLDI (2025) <br />
[<a name="recon">6</a>] Parker Ziegler et al., “Fast Direct Manipulation Programming with Patch-Reconciliation Correspondence” PLDI (2025) <br />
[<a name="patch">7</a>] Farnaz Behrang et al., “DR.FIX: Automatically Fixing Data Races at Industry Scale” PLDI (2025) \</p>]]></content><author><name>김태은</name></author><category term="Trip" /><category term="PLDI2025" /><summary type="html"><![CDATA[역사적인 순간: 연구실 전원이 참석한 최초의 국제 학회]]></summary></entry><entry><title type="html">PLDI 2025에 가서</title><link href="http://prosys.kaist.ac.kr/geon-trip-pldi/" rel="alternate" type="text/html" title="PLDI 2025에 가서" /><published>2025-06-29T00:00:00+00:00</published><updated>2025-06-29T00:00:00+00:00</updated><id>http://prosys.kaist.ac.kr/geon-trip-pldi</id><content type="html" xml:base="http://prosys.kaist.ac.kr/geon-trip-pldi/"><![CDATA[<h1 id="들어가며">들어가며</h1>
<p>그간 유튜브로만 접하던 학회. 발표는 몇 명이 듣는 걸까? 식사 시간에는 어떻게 대화가 오갈까? 어떤 분위기에서 진행될까? 카메라 밖의 세계가 궁금했다.</p>

<p>꼭 가보고 싶었던 PLDI에, 그것도 워크샵까지 포함해 5일이나 참석할 수 있었다는 건 더할 나위 없는 행운이었다. 논문을 내고 가는 게 아니었기에, 내 참석은 순전히 교수님께서 경험의 기회를 주셨기 때문이었다. 참석 전 영수증을 받으며, 이 금액이 과연 나에게 투자해도 될 만큼의 가치가 있는지 고민이 들 만큼 큰 비용이 들었다. 그 사실을 잊지 않기 위해, 매 순간 존재의 의미를 되새기고 더 많은 사람을 만나기 위해 애썼다. 학회가 끝날 무렵엔 진이 빠졌지만 돌이켜보면 그만큼 얻은 것도 많았고 다양한 목소리를 들을 수 있었던 값진 기회였다.</p>

<p>이 글에서는 이번 학회의 특별했던 점, 학회를 관통하는 기술적 흐름, 우리 연구 분야와의 접점, 인상 깊었던 주제, 그리고 피부로 느낀 치열한 노력과 준비에 관해 이야기하고자 한다.</p>
<h1 id="서울에서-학회가-열릴-때의-좋은-점">서울에서 학회가 열릴 때의 좋은 점</h1>
<p>학회가 서울에서 열렸다는 점 자체가 홈그라운드 어드벤티지를 안겨주었다.</p>

<p>우선, 한국인 연구자를 많이 볼 수 있었다. 비록 ERC나 SIGPL 같은 PL 분야 행사에서 대학원생들을 자주 만나지만, 이번 PLDI에서는 거기서 보기 어려웠던 순수이론 분야 연구자들도 많이 볼 수 있었고, 그들의 연구 사정과 주제를 더 깊이 알 수 있었다. 연사 중에도 한국인 비율이 높았고, 어떤 주제로 세계에 진출해 연구하고 있는지를 직접 확인하며 자부심을 느낄 수 있는 계기가 되었다. 특히, 증명 보조기 Lean의 초기 개발자 중 한 명인 공순호 박사님이 한국인이라는 사실은 한국인 연구자의 저력을 다시금 실감하게 했다.</p>

<p>또 외국인 친구를 사귈 때 쓸 대화 소재가 풍부했다. 한국 문화와 드라마에 관심이 많던 Md Amit Hasan Arovi님과는 한국에 관한 생각, 음식, 생활 등에 대해 진솔하게 이야기를 나눴다. 지하철 입구까지 길을 안내해 주는 사소한 행동만으로도 자연스레 대화를 이어갈 수 있었고, 주제가 생겼고, 친밀감이 형성되었다. Md님은 긴 연구 경력을 가진 분이었기에, 연구자의 삶, 워라밸, 적극성 등에 대해 많은 조언을 해주었고, 나중에 커피를 사주며 “아주 각별한 친구를 만들어 기쁘다”라는 말로 깊은 감동을 주었다.</p>

<p>또한, 서울이라는 익숙한 공간을 색다르게 조망할 수 있었다는 점도 좋았다. 환구단이 보이는 세미나실에서 발표를 듣거나, 경복궁의 야경을 배경으로 뛰는 경험은 오래 기억에 남을 것이다. 통근 거리가 짧으니 첫 일정을 상쾌하게 시작할 수 있었다는 점도 큰 장점이었다.</p>
<h1 id="pldi-2025를-관통한-핵심-기술-테마">PLDI 2025를 관통한 핵심 기술 테마</h1>
<p>이번 PLDI 2025에서 가장 두드러졌던 기술 테마는 Lean이었다. 안전한 AI를 위한 Lean의 활용은 다양한 세션에서 반복적으로 등장할 정도로 중심 주제였다. 또한 올해의 소프트웨어상도 Lean이 가져갔다.</p>

<table>
  <thead>
    <tr>
      <th style="text-align: center"><img src="https://lh3.googleusercontent.com/pw/AP1GczNp0_QmuknAd-4GkKKILTvToXJiav2SlX3rRA1191X7K34LW51XaprOMd1adPluJA1_6L_aZaQWrw79CGn7ke1BPlgvNHpF6fqL2vONSZc4-95Xukkn_3ldrgOkqrlatv8XwHxtEsU22ZKNtArVw6qk=w2520-h1890-s-no-gm" alt="" /></th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td style="text-align: center"><b> 올해의 소프트웨어상도 Lean이 가져갔다 </b></td>
    </tr>
  </tbody>
</table>

<h2 id="lean">Lean</h2>
<p>보안과 신뢰성을 위한 증명 보조기로 큰 인기를 얻고 있는 Lean의 최초 개발자 Leonardo de Moura와 공순호 박사님이 각각 연사로 참여하셨다.<sup><a href="#moura">1</a></sup> <sup><a href="#kong">2</a></sup></p>

<p>Lean은 Z3와 같은 SMT 검사기 (solver)를 증명 과정에 통합할 수 있는 상호작용형 증명 보조기이다.
Z3에선 코드가 조금만 수정되어도 재검증에 오랜 시간이 소요되는 문제가 있었지만, Lean은 뛰어난 재사용성을 기반으로 유연한 개발 환경을 제공한다.</p>

<p>Lean에서는 타입과 시스템 (모나드, 재작성 규칙 등)을 일반 프로그램 값처럼 다룰 수 있다. 즉, 함수 인자로 넘기거나 리스트에 담는 식으로 조작할 수 있으며, 실행시간 (runtime)에 생성 및 조작도 가능해 메타프로그래밍과 도메인 특정 언어 (domain specific language) 확장에 매우 유리하다. Lean의 뛰어난 확장성과 이에 따른 공동 작업 용이성 덕에, 500명 이상의 기여자가 참여한 거대 수학 라이브러리 Mathlib가 탄생할 수 있었다. Mathlib은 대수학, 해석학, 위상수학 등 광범위한 분야의 검증된 수학적 지식을 담고 있어, AI 모델을 위한 고품질 학습 데이터의 원천이 되거나 새로운 연구의 기반이 된다.</p>

<p>한편, Lean은 Rocq의 핵심 사상 중 하나였던 종속 타입 이론 (dependent type theory)을 그대로 계승한다. 이는 값에 따라 타입이 달라지는 시스템으로, 예를 들어 길이가 0인 리스트와 양수인 리스트가 서로 다른 타입을 가질 수 있게 하는 방식이다. 이러한 특성 덕분에, 타입이 그 자체로 논리를 내포하게 되며, 타입을 만족하는 프로그램은 곧 해당 명제의 증명이 되는 커리-하워드 대응관계를 만족한다.</p>
<h2 id="lean과-뉴로심볼릭-ai">Lean과 뉴로심볼릭 AI</h2>
<p>Lean은 뉴로심볼릭 AI 개발의 핵심 도구로도 활용되고 있다. 예를 들어, AlphaProof는 자연어로 서술된 수학 명제를 AI가 각잡힌 언어 (formal language)로 변환한 뒤 Lean으로 검증하는 방식으로, 국제 수학 올림피아드 은메달 수준의 문제 해결 능력을 보였다. 또 아마존 웹 서비스에서는 AI 훈련을 위한 데이터셋을 인공적으로 합성할 때, 명세에 맞게 생성되었는지를 Lean으로 검증하는 연구를 진행 중이다.</p>
<h2 id="lean을-어떻게-활용할-것인가-나의-관점에서">Lean을 어떻게 활용할 것인가: 나의 관점에서</h2>
<p>발표에서는 Lean을 AI 시스템의 입출력에 대한 검증 도구로 활용하는 방향을 중점적으로 다루었다. 연구자의 자리에 AI를 두고 그 보조 도구로 Lean이 온다. 연구자가 좋은 시스템을 만들고선 그 안전성을 증명 보조기를 통해 입증하듯이, AI의 판단이나 출력 역시 Lean을 통해 검증된다. 실제로 Lean은 뛰어난 확장성 덕분에, 수학 증명과 데이터 검증이라는 전혀 다른 도메인 모두에 사용될 수 있는 거의 범용 도구로 자리 잡고 있다는 인상을 주었다.</p>

<p>반대로, Lean을 중심에 두고 AI를 보조 도구로 활용하는 방향도 상상해 볼 수 있다. Lean에는 복잡하거나 자동화가 어려운 증명을 SMT 검사기에 위임하는 “hammer” 기능이 있는데, 이 역할을 AI가 대체하거나 보완할 수도 있다. 예컨대 방대한 데이터에서 어떤 사건의 원인을 찾고자 할 때, AI가 의미 있는 사실들을 구조화해 제시해 준다면, Lean이 이를 바탕으로 전체 논증을 구성하거나 반례를 도출할 수 있을 것이다.</p>

<p>연구에서 주로 다루는 주제는 귀납적 관찰로부터 연역적 설명을 도출하는 것인데, 현재 AI는 이 설명 능력에 취약하다. AI가 어떤 가설을 세운다 해도, 그것이 형식화되어 Lean에서 다룰 수 있는 형태가 아니면 검증은 불가능하다. 그러나 만약 AI가 추론 가능한 관계들을 정형화된 구조로 정리해 낼 수 있다면, Lean은 그 위에서 증명의 타당성을 판별하거나 가능한 시나리오를 체계적으로 탐색할 수 있을 것이다.</p>
<h1 id="우리-연구의-최전선-정적-분석static-analysis-분야-탐구">우리 연구의 최전선: 정적 분석(Static Analysis) 분야 탐구</h1>
<p>정적 분석의 이론과 응용의 대가들이 한자리에 모인 SOAP (State Of the Art in Program Analysis) 워크샵에 간 건 큰 행운이었다. 개중 인공신경망의 안전성을 따지기 위한 정적 분석 (?)과, 실용적 정적 분석을 위한 기술 개발이 특히 인상적이었다.</p>
<h2 id="static-analysis-from-code-graphs-to-neural-networks---experiences-and-opportunities3">Static Analysis from Code Graphs to Neural Networks - Experiences and Opportunities<sup><a href="#static">3</a></sup></h2>
<p>신경망이 작은 입력 변화 (perturbation)에도 예기치 않게 반응하는 취약성을 해결하기 위한 수학적 검증 기법을 소개했다. 핵심은 주어진 입력 \(x\)에 대해, 그 근방 \(||x'-x||\le \epsilon\)의 모든 입력 \(x'\)에서도 출력 레이블이 항상 같음을 보장하고자 하는 것이다.</p>

<p>여기에는 전체 입력 공간을 잘게 나누는 branch-and-bound 방식이 사용되었다. 입력 공간을 나눈 (branch) 뒤, 각 부분공간의 출력 범위를 근사치로 계산 (bound)해, 이 범위가 모두 같은 라벨을 가리키면 해당 영역은 안전하다고 판정한다. 그렇지 않으면 반례를 찾거나 더 세분화해 더 정밀한 검사를 반복한다. 최근 발표에서는 이때 반례가 존재할 가능성이 높은 순서대로 공간을 탐색해 효율성을 높이는 전략도 제시되었다.</p>

<p>이미 알던 정적분석, 즉 요약 해석 (abstract interpretation)을 기반으로 하고 갈루아 연결 (Galois connection)을 이론적 바탕으로 가지던 정적분석이 아니라서 흥미를 끌었다. 반례의 위치를 찾아내는 기술은 실수 집합 내에서 유계 수열은 수렴하는 부분 수열을 가진다는 Bolzano-Weierstrass 정리의 증명 과정과 유사했다.</p>
<h2 id="building-x-ray-for-enterprise-scale-software4">Building X-Ray for enterprise-scale software<sup><a href="#xray">4</a></sup></h2>
<p>Beacon을 개발한 홍콩과기대 Charles Zhang 교수님의 발표는, 대규모 기업용 (엔터프라이즈) 소프트웨어에 정적 분석을 적용하려는 다년간의 연구 성과를 집약한 세션이었다. 교수님은 안전성 (soundness)은 현실 환경에선 지나치게 보수적이고, 정확도 (precision)는 높이기 어려운 상황에서, 경량화된 경로 민감 (path-sensitive) 분석을 효율적으로 수행하는 방법을 모색해 왔다.</p>

<p>특히 인상 깊었던 개념은 ‘경계 문제 (boundary problem)’였다. 이는 정적 분석이나 대형 언어 모델(LLM) 단독으로는 다루기 어려운, 불완전한 코드, 깊은 반복문, 불명확한 API 사용 등을 말한다. 교수님 연구팀은 이러한 문제를 정적 분석과 LLM의 역할 분담을 통해 해결하려고 한다. 예를 들어, 제어/데이터 흐름 추적과 도달성 분석은 정적 분석이 맡고, API 별명 (alias) 관계 추론이나 의미 기반 함수 해석은 LLM이 담당하는 식이다.</p>

<p>사례로는, 공식 문서를 바탕으로 클래스 계층, 모듈타입 (signature), 설명, 값 이름 등을 비교해 API 간의 별명 관계를 추론하는 연구, 정적 분석으로 인터럽트 핸들러 (ISR) 함수를 식별한 뒤 LLM이 데드락 가능성을 검토하는 연구, 그리고 메모리 할당/해제 함수를 감싸 기능을 추가하는 메모리 감쌈 (wrapper) 함수를 찾는 구조가 소개되었다. 이 중 마지막은 함수 이름을 통한 추론을 LLM이, 도달성 분석 등을 정적 분석이 맡는 방식이다.</p>

<p>우리 연구실에서도 메모리 감쌈 함수를 찾거나, 공식 문서를 참고하는 유사한 주제를 생각하고 있었기에, 
연사님께 해당 연구의 연구 목적을 여쭤보았다. 메모리 감쌈 함수를 찾는 이유는, sanitizing 과정에서 일어나는 실수나 double free 같은 결함이 자주 발생하는 지점이기 때문에 분석 우선순위를 높이기 위함이라고 한다. 
우리 연구실의 접근 목적과는 다르지만, 연구 자체는 유사하며, 우리가 진행하는 논의가 세계적인 수준과 맞닿아 있다는 사실을 실감할 수 있었다.</p>

<p>연사님은 또한 LLM이 테스트 목표 설정부터 입력 생성, 실행 결과 평가까지 수행해 오류 입력을 자동 생성하는 주체적 (agentic) 접근도 실험 중이라고 하셨다. Beacon이 퍼징과 정적 분석의 융합이라면, 이제는 퍼징을 넘어서 (LLM을 활용하는) 오류 입력 생성 기술 전반으로 확장하는 진화의 궤적이 보였다.</p>
<h1 id="새로-알게-된-연구-주제들">새로 알게 된 연구 주제들</h1>
<h2 id="kat-kleene-algebra-with-tests">KAT (Kleene Algebra with Tests)</h2>
<p>조건 검사를 지원하는 클리니 대수 (KAT)는 프로그램의 제어 흐름을 수학적으로 모델링하기 위한 대수 체계다. 클리니 대수 (Kleene Algebra)는 유한 오토마타가 인식하는 문자열 집합을 정규식으로 표현하고, 정규식 간 동등성을 대수적으로 증명할 수 있도록 만든 구조다. +, ·, * 같은 정규식 연산자가 이 대수에 대응한다. 하지만 실제 프로그램에는 <code class="language-plaintext highlighter-rouge">if</code>, <code class="language-plaintext highlighter-rouge">while</code> 같은 조건 분기가 있어 정규식만으로는 부족하며, 이를 위해 조건 검사 (test)를 대수에 추가한 것이 KAT다. 조건 <code class="language-plaintext highlighter-rouge">b</code>에 대한 검사는 <code class="language-plaintext highlighter-rouge">[b]</code>, 그 부정은 <code class="language-plaintext highlighter-rouge">[¬b]</code>로 표현하며, 예컨대 <code class="language-plaintext highlighter-rouge">if b then p else q</code>는 <code class="language-plaintext highlighter-rouge">[b]·p + [¬b]·q</code>, <code class="language-plaintext highlighter-rouge">while b do p</code>는 <code class="language-plaintext highlighter-rouge">([b]·p)*·[¬b]</code>로 나타낸다.</p>

<p>KAT 세션이 따로 있을 만큼 이번 PLDI에서 주목받았지만, 세션 내용은 KAT의 이론적 확장이 많아 따라가기가 쉽지 않았다. 여기에는 확률적 프로그래밍을 다루기 위해 KAT을 확장한 발표를, 이해한 만큼만 소개하고자 한다.</p>
<h3 id="probabilistic-kleene-algebra-with-angelic-nondeterminism5">Probabilistic Kleene Algebra with Angelic Nondeterminism<sup><a href="#kleene">5</a></sup></h3>
<p>확률적 프로그래밍은 프로그램의 상태를 단일 값이 아니라 확률분포로 표현하고, 비결정론적 유한 오토마타 (Nondeterministic Finite Automaton)는 실행 경로가 고정되지 않는 비결정성을 다룬다. 이 발표는 이 둘을 동시에 포함하는 시스템을 수학적으로 정형화하기 위해, 중복집합 (multiset)을 사용하는 확률적 클리니 대수 (Probabilistic Kleene Algebra) 오토마타를 제안한다.</p>

<p>이 오토마타의 핵심은 상태를 단순한 집합이 아니라 중복집합으로 표현한다는 점이다. 오토마타 위를 탐험하는 행위자 (agent)들은 확률 상태에서는 무작위로 다음 상태를 선택하고, 비결정 상태에서는 여러 행위자로 분기해 각각 독립적으로 실행되도록 한다. 동일한 확률 상태에 서로 다른 경로로 도달한 여러 행위자가 존재할 수 있는데, 이들을 집합의 한 원소로 표현하면 각각의 확률 선택이 독립적이지 않게 되어 문제가 된다. 중복집합을 사용하면 행위자들을 구분할 수 있어, 각기 다른 난수 (random bit)를 부여해 확률 선택의 독립성을 보장할 수 있다.</p>

<p>이렇게 가능한 모든 실행 경로를 다 따져볼 수 있는 방식이 ‘천사적 비결정론 (angelic nondeterminism)’이다. 모든 실행 경로를 다 따져보기 때문에 <code class="language-plaintext highlighter-rouge">if</code>, <code class="language-plaintext highlighter-rouge">while</code> 같은 조건 분기를 모델링하는 데 적합하다.</p>

<p>다만 발표에서 아쉬웠던 점은, 천사적 비결정론을 이용해 KAT의 주요 활용 분야인 최적화 검증이나 프로그램 분석이 어떻게 가능한지를 잘 상상하기 어려웠다는 것이다. 또한 천사적 비결정론을 검색해 보면, 비결정론이 항상 원하는 결과에 도달하도록 눈치껏 작동하는 실행이라고 나오는데, 그것과 발표의 정의가 일치하는지도 궁금했다. 발표장에서도 ‘천사적 선택’이 위험하지 않은지, 어디에 쓰일 수 있는지 질문이 나왔지만, 아직 활용 분야를 개척하진 않았고 실제 프로그램에 적용하기 위해 개발 중이라는 답이 돌아왔다.</p>

<p>한편, 이 세션은 구문 중심 코드에 대해 어떤 대수적 접근이 가능한지를 알 수 있게 해주었고, 그 배경에 예상보다 높은 수학적 난도가 있다는 점을 체감할 좋은 기회였다. KAT는 함수 호출이 없는 절차적 프로그램에 적합하므로 일반적인 언어에는 적용이 어렵지만, 제어 흐름을 다루는 새로운 방식이 흥미로웠다.</p>
<h2 id="pl--hci">PL + HCI</h2>
<p>소프트웨어 엔지니어링의 하위 분야로, PL 연구자를 돕는 HCI 기술이나 HCI 기술을 돕는 PL 기술을 다룬다. 배경민 교수님 연구실의 장혁순 님의 소개로 알게 된 분야였는데, PL을 바라보는 전혀 새로운 시각을 제공해 주었다. 기존에 PL 연구의 목표가 안전한 코드, 자동으로 쓰이고 고쳐지는 코드였다면, 이 분야에서는 그 코드를 시각적으로 요약하거나 인터페이스로 조작할 수 있는 방식으로 바꾸는 데 관심이 있다.</p>
<h3 id="fast-direct-manipulation-programming-with-patch-reconciliation-correspondence6">Fast Direct Manipulation Programming with Patch-Reconciliation Correspondence<sup><a href="#recon">6</a></sup></h3>

<p>데이터 시각화나 GUI 인터페이스에서, 사용자 조작이 프로그램에 미치는 영향 (<code class="language-plaintext highlighter-rouge">patch</code>)과 출력에 미치는 영향 (<code class="language-plaintext highlighter-rouge">recon</code>)을 분리해 빠르게 반영할 수 있도록 하는 연구다. 예를 들어 GUI에서 선의 굵기나 색상처럼 시각적 속성을 바꾸면, 원래는 프로그램에서 해당 속성을 바꾼 뒤 재실행하기 위해 데이터를 다시 불러오고 처리해야 하지만, 이 연구에서는 <code class="language-plaintext highlighter-rouge">recon</code>으로 시각적 출력의 변화만 계산해 즉시 반영하고, 프로그램 변경은 <code class="language-plaintext highlighter-rouge">patch</code>로 처리해 나중에 동기화할 수 있도록 한다. 이때 원래 출력에 <code class="language-plaintext highlighter-rouge">recon</code>을 적용한 결과와, 프로그램을 <code class="language-plaintext highlighter-rouge">patch</code>한 뒤 재실행한 결과가 같음을 보장한다. 수식으로는 프로그램 \(P\)와 시각화 연산 \(eval\), 가능한 변화 \(\delta\)를 아우르는 도메인 특화 언어 (DSL) 위에서, \(eval(patch(\delta,P))=recon(\delta,eval(P))\)을 만족하는 <code class="language-plaintext highlighter-rouge">recon</code>을 정의한다. 이는 정적 분석에서 요약 해석 (abstract interpretation)을 위해 요약 연산자 (abstract operator)를 정의하는 방식과 유사하다.</p>

<p>연구는 인구 통계 등 대규모 데이터를 다루는 실무자들이 주로 GUI 기반 프로그램 수정 인터페이스 (direct manipulation interface)를 사용한다는 점을 들어, 사용자 조작에 반응이 빠른 시스템의 중요성을 강조했다. 다만 속도를 높이기 위한 전략으로, 프로그램 변경이 시각화 요소에 끼치는 영향 관계를 분석해 필요한 부분만 갱신하는 방식, 즉 부분 평가 (partial evaluation)로도 충분하지 않을까 하는 의문이 들었다. 출력에 <code class="language-plaintext highlighter-rouge">recon</code>을 적용하는 방식이 빠르다면, 원칙적으로는 부분 평가도 마찬가지로 빠를 수 있기 때문이다. 나름대로 해답을 생각해 보면 시각화에 사용된 언어의 특성상 부분 평가가 어려울 수 있으며, 도커 이미지의 층 (layer)처럼 영향 관계 파악이 거의 불가능할 수도 있을 것 같다. 이 질문을 너무 늦게 떠올리는 바람에 연사를 애타게 찾아다녔으나 끝내 못 만난 씁쓸한 기억이 남는다.</p>

<p>특이한 점은 발표 자료의 완성도였다. 프로그램 흐름을 도식화한 후, 그 사이에 <code class="language-plaintext highlighter-rouge">recon</code>이 개입되는 과정을 직접 도식이 변화하는 애니메이션으로 표현했는데, 역시 HCI 팀답게 시각적 전달력이 매우 뛰어났다.</p>

<table>
  <thead>
    <tr>
      <th style="text-align: center"><img src="https://lh3.googleusercontent.com/pw/AP1GczM63h7AYCsvT56jHZgq6qq_BFjSFfJig_whrvJRjQ8IRmNBezDZ5hGSeUcQNOtRFMPd25Qdmd69cvMcLD5-svxV0n5mM3fNpsJfrv6ciWo87PgSXRLuJoK5uo8Q6v3azOka7-NbYEWU9vYJapyF5l7j=w2520-h1890-s-no-gm" alt="" /></th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td style="text-align: center"><b> 잘 만들었다 </b></td>
    </tr>
  </tbody>
</table>

<h3 id="an-interactive-debugger-for-rust-trait-errors7">An Interactive Debugger for Rust Trait Errors<sup><a href="#debugger">7</a></sup></h3>
<p>연구는 트레잇 기반 타입 추론 오류를 직관적으로 탐색 및 디버깅하기 위한 도구를 제시한다. 기존 컴파일러는 타입 오류 메시지를 구성할 때 타입의 추론 트리를 거꾸로 거슬러 올라가 최초의 문제까지 경로의 모든 지점을 보여준다. 그러나, 트레잇의 연관 타입 (associated type)은 사용자 코드가 아니라 라이브러리 내부의 로직이어서 쓸모없는 경우가 많고, 지나치게 많은 지점 중 정작 사용자가 고쳐야 할 곳이 어디인지를 알아내기가 어렵다.</p>

<p>이 연구에서 제시하는 Argus는 트레잇 추론 트리와 함께 트레잇 인스턴스 검색 과정의 상향식 (provenance) 및 하향식 탐색을 사용자가 할 수 있도록 지원하고, 오류를 없앨 수 있는 최소한의 수정 지점까지 짚어준다. 사용자 연구 (user study) 결과 문제 해결은 3.3배, 찾아낸 오류는 2.2배가 되었다고 한다.</p>

<p>흥미로운 점은, 이 연구가 Rust 언어 자체를 바꾸지 않고 Rust 추론 시스템을 대상으로 상호작용적 시각화만을 제공하지만, 학술적 의미를 갖는다는 것이다. 거꾸로 올라가는 과정의 시각적 제시와 인터페이스 중심의 휴리스틱이 기존 컴파일러 진단 도구의 설계 관행을 재고하게 만들 수 있기 때문으로 보인다.</p>

<table>
  <thead>
    <tr>
      <th style="text-align: center"><img src="https://lh3.googleusercontent.com/pw/AP1GczOtbFEDSQk00sn3U_IzRuHk26Um68t9ZwoeNz7QUddOwOAImH94GygroZxUYM204CKe8yq1uor_cYXFgndSZYJwMue1VU3-48xNLvR94GidHlP6VSrxpPJfb0NHrn1VIwBxJfcOJ0BXUueAw6aw-iaP=w2520-h1890-s-no-gm" alt="" /></th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td style="text-align: center"><b> 역시 잘 만들었다 </b></td>
    </tr>
  </tbody>
</table>

<h2 id="동시성을-고려한-메모리-관리">동시성을 고려한 메모리 관리</h2>
<p>새로 알게 된 연구 주제들에 넣기가 민망한 게 사실 우리 학교 강지훈 교수님 연구실에서 오랫동안 연구하던 주제이기 때문이다. 다만 그동안 제대로 이해하질 못했다가 이번 기회에 좀 깊게 파고들 기회가 되었다.</p>
<h3 id="verifying-lock-free-traversals-in-relaxed-memory-separation-logic8">Verifying Lock-Free Traversals in Relaxed Memory Separation Logic<sup><a href="#lockfree">8</a></sup></h3>
<p>느슨한 메모리 (relaxed memory), 다른 말로 약한 메모리 (weak memory)는 컴파일러 및 하드웨어의 최적화로 인해 명령어가 재배열되는 것을 허용하는 메모리 모델로, 동시성 프로그램에서 가능한 다양한 실행 순서를 모두 안전하게 포함해야 한다. 이 모델의 핵심 특징은, 메모리에서 값을 읽을 때 반드시 가장 최근 값이 아니라 예전에 기록된 값을 읽을 수 있다는 가능성을 허용하는 점이다.</p>

<p>스킵리스트 (skiplist)는 기본적으로 인접 노드만 가리키는 연결 리스트 (linked list)에 여러 층의 도약 포인터를 추가해 탐색 속도를 높인 자료구조다. 특정 노드를 삭제하려면 그 노드를 가리키는 모든 포인터를 비활성화해야 하는데, 여기에 여러 스레드가 동시에 접근하고, 명령어 재배열까지 가능한 환경이라면 어떤 실행이 안전하며 어떤 실행이 오류를 유발할 수 있는지 정형적으로 검증하기가 매우 까다롭다.</p>

<p>이 연구는 스킵리스트 위에서의 락 안쓰는 (lock-free) 탐색 알고리즘을 약한 메모리 모델 위에서 최초로 각잡힌 검증 (formal verification)한 사례이다. 2024년 여름 SIGPL에서 “약한 메모리에서 동시성 탐색 알고리즘 검증하기”라는 이름으로 미리 소개된 바 있었는데, 이렇게 멋진 발표로 다시 볼 수 있어서 매우 좋았다.</p>
<h3 id="verifying-general-purpose-rcu-for-reclamation-in-relaxed-memory-separation-logic9">Verifying General-Purpose RCU for Reclamation in Relaxed Memory Separation Logic<sup><a href="#rcu">9</a></sup></h3>
<p>RCU (read-copy-update)는 동시성 환경에서 데이터를 읽을 때 락을 쓰지 않아, 읽기 성능이 최적화된 동기화 방식이다. 읽고 싶으면 그냥 읽으면 되고, 쓰고 싶을 때는 기존 데이터의 복사본을 만들어 수정한 뒤, 포인터만 한 번에 바꿔치면 된다. 다만 원본 데이터를 해제하기 전에, 이전 데이터를 아직 읽고 있는 스레드가 있다면 그게 끝날 때까지 기다려야 한다. 흡사 참조 횟수 (reference counter)처럼 자신을 참조하는 스레드를 추적하는 방식으로 메모리 안전성을 보장하는 연구들이 있었지만, 이는 순차적 메모리 (sequential memory) 모델에서만 가능했다.</p>

<p>이 연구는 느슨한 메모리에서 RCU를 각잡힌 검증하기 위해, 다음 두 가지 가정을 도입했다. 첫째, 한 스레드가 메모리의 이전 값과 현재 값을 동시에 참조하고 있을 경우, 이전 값의 참조는 무시할 수 있다. 둘째, 뮤텍스와 같은 공유 자원을 한 스레드에서 쓰고 다른 스레드에서 읽는다면, 그 중간에 메모리 장벽 (fence)을 삽입해 접근 순서를 보장한다. 이 두 가정만으로도 느슨한 메모리에서의 RCU를 각잡힌 검증할 수 있다는 것이 이 연구의 핵심이다.</p>

<p>간단하고 명쾌한 아이디어처럼 보이지만, 실제로는 복잡한 사례 연구 (case study)에 기반해 가능함을 입증한 점에서 매우 잘 된 연구라고 느꼈다. 발표 중 누군가 “왜 이런 간단하고 중요한 아이디어를 그전까지 아무도 하지 않았던 거냐”고 묻자, 발표자는 “단순한 아이디어처럼 보이지만 그 아래엔 아주 복잡한 사례 분석이 있었다”고 답했던 게 정말 인상적이었다.</p>

<table>
  <thead>
    <tr>
      <th style="text-align: center"><img src="https://lh3.googleusercontent.com/pw/AP1GczP2l7hezYF7xJjVXYdJWlIhSd0ASzVDNHkJyc9W4aUdjkoTFH8BN-DmkSgP3FzhXr28BKz0AQXxki47b3AR17Bw6wxwpUrJ5OoCfGtuExYxyQ_CnVg5vtyN581YlJg-l2YtL9PN5DXjyvbqNiyP0n6_=w2520-h1890-s-no-gm" alt="" /></th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td style="text-align: center"><b> PLDI 우수논문상을 수상하는 해당 논문 저자들의 모습 </b></td>
    </tr>
  </tbody>
</table>

<h1 id="사람들">사람들</h1>
<p>PL 학회였기 때문일까. 평소에 궁금했지만 멀게 느껴졌던 프로그램 검증 분야 연구자들과 처음 이야기를 나눌 수 있었다. 친구가 허충길 교수님 연구실에 있어 인연이 닿았고, 이번 학회에서 해당 연구실 분들과 처음 인사를 나눴다. 수학적으로 굉장히 깊이 있는 대화가 오가, 솔직히 제대로 알아듣진 못하고 옆에서 고개만 끄덕이기 바빴다. PL에 적용되는 수학이 이렇게 심오하구나 실감했고, 다음 날 점심때 반갑게 인사해 주신 게 기억에 남아 감사한 마음이었다.</p>

<p>뱅큇 전에 오학주 교수님 연구실의 변지석 님을 다시 만났다. Rust에서 컴파일러 내부 오류 (ICE)를 잡기 위해, 의심되는 지점을 목표로 하는 다중지향성 퍼징을 만들기를 연구하시는 분이다. 2024년 여름 SIGPL에서 만났을 때도, 집에 돌아가는 길 버스에서 같은 주제로 한참 이야기를 나눴다. 당시도, 지금도 서로 여전히 다중지향성 퍼징을 연구하고 있었고, 각자가 새로 알아낸 점, 다른 연구들과의 비교, 현재 진행 중인 방향에 대한 고민을 나누며 새로운 관점을 얻을 수 있었다. 난 퍼징 주제로만 벌써 24개월, 다중 지향성이라는 테마로도 꽤 길게 연구 중인데, 많은 사람들이 남긴 조언을 머릿속에 담고 있으면서도 어느새 잊고 있었단 사실도 깨달았다. 내 시야가 좁은 구간에 갇혀 있었음을 다시 느끼고, 넓은 시야로 여러 가지를 다시 조사할 필요를 느꼈다.</p>

<p>또 박지혁 교수님 연구실에 새로 석사과정을 시작하신 김현준 님, 학부생 인턴이신 최민석 님과도 대화를 나눴다. 김현준 님은 자바스크립트 스펙의 오류를 잡기 위해 퍼징을 고민 중이라고 하셨는데, 신선한 접근이라 흥미로웠다. 하지만 그게 진짜 퍼징으로 풀어야 할 문제인지에 대한 변지석 님의 조언도 설득력 있게 느껴졌다. 최민석 님과 김현준 님은 곧 열릴 FSE에서 자신이 만든 자바스크립트 스펙 시각화 도구를 아티팩트 발표하신다고 했는데, 스펙의 항목을 클릭하면 관련 코드 시드를 보여주는 구조였다.<sup><a href="#jsspecvis">10</a></sup> 잠깐 보여주신 도구는 굉장히 직관적이었고, PL과 HCI가 맞닿은 도구로서 개발자들에게 큰 도움이 될 수 있을 것으로 보였다.</p>
<h1 id="치열한-노력과-준비">치열한 노력과 준비</h1>
<p>연단에 오른 사람들은 그 분야의 대가, 구체적으로 자신의 선행 연구를 한 연구자들에게 질문을 받게 된다.
좋은 연구는 대가가 가지 않았던 길을 자신이 간 이유가 타당하고, 
또 그 길이 새로운 연구로 인정받을 수 있을 만큼 중요한 접근을 바꾸어야 한다. 그게 충족되지 못한 경우, 
당신의 연구가 내 연구와 다른 점이 무엇인지 대놓고 질문하는 날카로운 경우도 있었다.
반면 새로운 연구라고 해도 질문은 날카롭다. 앞서 언급한 ‘천사적 선택’ 발표도, 
그런 사용법이 너무 새로웠기에 이해를 못 해서 들어온 질문이 있었다. ‘악마적 선택은 뭔지 아는데, 연구에서 굳이 천사적
선택을 쓸 이유는?’ 내지는 ‘응용 분야가 있는지’ 등, 주제가 많이 새로운 발표들에서는 잘 모르겠는 걸 거리낌없이 질문할 수 있는 분위기였다.</p>

<p>모두들 자신의 분야를 전혀 모르는 남들에게 이해시키기 위해 많은 노력을 기울였다.</p>

<p>가장 놀랐던 점은 발표에서 나오는 핵심 예제 (motivating example)가 논문과 겹치지 않는 새로운 경우가 많았단 것이다. 
논문에서는 상대적으로 길고 엄밀한 에제를 썼다면 
발표에서는 그다지 엄밀하진 않지만 어떤 분야의 어느 내용을 바꾸었는지 이해하기 좋은 비유를 들고 왔다.</p>

<p>또한 소프트웨어 엔지니어링처럼 성능을 끌어올린 연구를 하더라도 그 결과를 앞에 놓지 않고, 최대한 자신의 연구 분야와 
현황을 예제 등으로 주지시킨 다음에 결과를 실었다. 이건 아무래도 서로 어떤 연구를 하는지 쉽게 알기 어려운 학회의 특성상, 
얻어갈 핵심 메시지를 어떻게든 가르치려 노력한 산물이었다. 
그런 의미에서 올해 논문 작성, 발표 초안부터 끝까지 고쳐서 멋진 발표를 해내신 봉준님에게 정말 대단하다는 말을 하고 싶다. 
밤늦게까지 LLVM 이슈를 올리던, 또 예비발표의 피드백을 열심히 챙기던 봉준님의 모습이 어렴풋이 기억난다.</p>

<p>이번에 나는 발표가 없었고, 따라서 연단에 올라갈 일이 없었다. 
하지만 어쨌든 연단에서 사진은 하나 남겼는데, 워크샵 첫날에 일찍 학회장에 도착해 볼 사람이 없는 틈을 타서… 
워크샵의 운영위원이셨던 교수님의 도움을 받아 사진을 남겼다.</p>

<table>
  <thead>
    <tr>
      <th style="text-align: center"><img src="https://lh3.googleusercontent.com/pw/AP1GczOz_j5B2l6lZiTawvHgTAirNwmYiEW_p2zJWAbm62-BtpdSg6V2HeoLfn9JnzDDXrVo-3XDrb3q6FacG0phOjQc0WbyaV6fzHcQXivDxB-roVcX1CAvI7C_c5Majany23H8roRFiGnH1E9qhzvri6S2bg=w2520-h1890-s-no-gm" alt="" /></th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td style="text-align: center"><b> 언젠간 연사로 서리라 </b></td>
    </tr>
  </tbody>
</table>

<h3 id="각주">각주</h3>
<p>[<a name="moura">1</a>] https://pldi25.sigplan.org/details/pldi-2025-papers/98/Lean-Machine-Checked-Mathematics-and-Verified-Programming-Past-and-Future <br />
[<a name="kong">2</a>] https://pldi25.sigplan.org/details/pldi-2025-pldi-events/3/AI-Lean-NeuroSymbolic-AI <br />
[<a name="static">3</a>] https://pldi25.sigplan.org/details/SOAP-2025-papers/9/Static-Analysis-from-Code-Graphs-to-Neural-Networks <br />
[<a name="xray">4</a>] https://pldi25.sigplan.org/details/SOAP-2025-papers/10/Building-X-Ray-for-enterprise-scale-software <br />
[<a name="kleene">5</a>] Shawn Ong et al. “Probabilistic Kleene Algebra with Angelic Nondeterminism” PLDI (2025) <br />
[<a name="recon">6</a>] Parker Ziegler et al. “Fast Direct Manipulation Programming with Patch-Reconciliation Correspondence” PLDI (2025) <br />
[<a name="debugger">7</a>] Gavin Gray et al. “An Interactive Debugger for Rust Trait Errors” PLDI (2025) <br />
[<a name="lockfree">8</a>] Sunho Park et al. “Verifying Lock-Free Traversals in Relaxed Memory Separation Logic” PLDI (2025) <br />
[<a name="rcu">9</a>] Jaehwang Jung et al. “Verifying General-Purpose RCU for Reclamation in Relaxed Memory Separation Logic” PLDI (2025) <br />
[<a name="jsspecvis">10</a>] https://conf.researchr.org/details/fse-2025/fse-2025-demonstrations/6/JSSpecVis-A-JavaScript-Language-Specification-Visualization-Tool</p>

<script src="https://polyfill.io/v3/polyfill.min.js?features=es6"></script>

<script id="MathJax-script" async="" src="https://cdn.jsdelivr.net/npm/mathjax@3/es5/tex-mml-chtml.js"></script>]]></content><author><name>박건</name></author><category term="Trip" /><category term="PLDI2025" /><summary type="html"><![CDATA[들어가며 그간 유튜브로만 접하던 학회. 발표는 몇 명이 듣는 걸까? 식사 시간에는 어떻게 대화가 오갈까? 어떤 분위기에서 진행될까? 카메라 밖의 세계가 궁금했다.]]></summary></entry></feed>