SIGPL은 Special Interest Group on Programming Languages의 약자로 1년에 2번씩 열리는 PL분야의 행사이다. 올해는 광주광역시의 전남대학교에서 개최되었다. 나는 PL분야의 연구실에서 7월부터 인턴 생활을 시작했는데, 교수님이 인턴들도 본 행사에 참석하기를 원하셔서 운 좋게도 참여할 수 있었다. 고등학교 때는 학회나 비슷한 행사들을 많이 다녀봤었는데, 대학교에 올라오고 나서는 코로나19 때문인지 이런 행사에 참여할 기회가 없었다. 그래서 나름 기대한 채로 기차를 타고 광주에 도착했다.
8/22 (Day 1)
전남대학교에 도착해 등록을 마친 뒤 한동대 홍신 교수님, Google의 윤영석 박사님의 강연을 들었다. 그 내용을 정리해보고자 한다.
지능적 코드 변형을 통한 디버깅 자동화 - 홍신 교수님
이 강연은 Fault Localization 즉, 잘못된 코드의 위치를 찾는 기술에 대한 강연이었다. 나도 코드를 한참 짜놓고 몇몇 줄에 생긴 오류 때문에 디버깅하느라 밤샜던 경험이 많았기에 주제 자체가 매우 흥미로웠다. Fault Localization을 자동화하는 방법은 여러 가지가 있는데, 초기에는 SBFL(Spectrum Based Fault Localization)방식이 유행했다. 이 방법의 아이디어는 매우 간단하다. A라는 코드가 틀렸다고 가정해보자. 프로그램을 실행시키고 어떤 input을 넣어줬을 때, A코드를 지난다면 output이 틀릴 가능성이 매우 높을 것이다. 따라서 여러 TC에 대해서 어떤 라인이 실행되는지 모두 추적한 후에 각 라인별로 이 라인이 실행된 TC 중 FAIL 한 비율을 측정한다. 이 비율이 높을수록 해당 라인이 틀릴 가능성이 높다고 결론지을 수 있다. 언뜻 생각해보기에 굉장히 간단하고 잘 동작할 것 같지만 한계가 있다. FAIL비율을 측정해 라인별로 등수를 매길 때, 공식을 아무리 바꿔도 같은 등수에 랭크된 코드가 굉장히 많아질 수 있다. 왜냐하면 코드들이 모두 independent 한 것이 아니라 correlate 된 경우가 많기 때문이다. 이럴 경우에 여전히 후보군이 좁혀지지 못하고 많은 코드를 일일이 봐야 한다는 단점이 있다.
이런 한계를 극복할 수 있는 것이 MBFL(Mutation Based Fault Localization)방식이다. 이 방법 역시 아이디어는 매우 간단하다. 이름답게 코드를 바꿔가면서(mutate) 오류를 찾아내는 방식인데, 예를 들어 A라는 코드를 B로 바꿨다고 하자. 만약 A가 옳은 코드였다면 PASS 하던 TC들이 FAIL 할 것이다(A를 지나가는 TC한정이지만). 반면 A가 틀린 코드였다면 PASS 하던 TC들은 여전히 PASS 할 가능성이 높고(A를 지나가지 않은 TC일 확률이 높기 때문) FAIL 하던 TC는 여전히 FAIL이거나 운이 좋다면 디버깅이 완료되어서 PASS 할 가능성이 있다. 이렇게 A의 옳고 그름의 여부에 따라 바뀌는 양상은 완전히 다르다는 사실을 이용하여 Fault Localization을 할 수 있다. 그렇다면 어떻게 코드를 바꿔야 할까? 부등호 '>'를 '<'로, 비트 연산자 '&'를 '|'로 바꿔 볼 수 있다. 실제로 이런 방법들을 정리한 표준적인 문서가 존재하는 것으로 안다. 그래서 이 방법을 각 줄에 적용하여 코드를 바꿔본 다음 TC들을 통과시켜 Fault Localization을 할 수 있다. 교수님은 이를 디버깅을 Monkey에게 시킨다고 표현하셨다.
그러나 이 방법에도 단점은 존재한다. 바로 너무 많은 Monkey(자원)이 필요한 것이다. 실제로 이 방법을 적용하면 SBFL방법에 비해 정확도는 우수하지만 시간이 굉장히 오래 걸린다. 그래서 교수님께서는 이 Monkey들을 줄이고자 연구를 하셨고 좋은 성과를 거두셨다. 교수님의 아이디어는 굉장히 간단했지만 정말 놀라웠는데, 간단히 정리해보자면 다음과 같다. 보통 우리가 함수나 변수의 이름을 지을 때 무작정 짓기 보다는 해당 변수나 함수의 기능을 내포하도록 짓는다. 이는 TC의 이름도 마찬가지다. 어떤 기능이나 함수를 테스트해보는지 등의 정보를 내포하도록 짓는다. 때문에 특정 함수나 변수와 TC들의 연관성을 NLP(Natural Language Processing, 자연어 처리)기술을 이용하여 측정한 뒤, 연관성이 높은 TC들만 해당 코드의 mutation test에 활용한다. 결과는 굉장히 놀라웠고, 정확도는 비슷하게 유지한 채로 시간을 크게 절약할 수 있었다. 물론 어떤 코드가 빠져있는 경우(Omission Fault) 등에 대해서는 아직 정확도가 좋게 나오지 못하는 등의 문제가 있지만 정말 좋은 기술이고 매우 흥미롭게 들었다. 결과적으로는 SIGPL 3일을 통틀어 가장 재밌는 강의였다.
MLIR을 통한 머신러닝 모델 최적화 기법 소개 - 윤영석 박사님
IR(Intermediate Representation)은 PL분야에서 중요한 개념이고, 언어를 분석할 때 주로 활용된다. 그렇다면 MLIR은 무엇일까? 나는 당연히 ML이 Machine Learning일 줄 알았다. 하지만 예상을 깨고 ML은 Multi-Level이었다. 그런데 사실상 TensorFlow 등 ML Framework등에 주로 쓰여 Machine Learning으로 이해해도 무방할지도 모른다. 이에 대한 자세한 설명은 여기를 참고해보자. 사실 내가 이해를 잘 못했다. 그런데 이 개념과 관련된 LLVM 등이 굉장히 중요하기에 공부해볼만한 가치가 있다고 생각한다.
이렇게 2분의 강연이 끝난 뒤에 학부생/대학원생분들의 번개발표가 시작됐다. 5분씩 나와서 발표하는 방식이었고, 정말 칼같이 시간을 끊었다. 우리 팀도 여기서 발표를 했다. 당연히 5분 내에 발표자분들이 하시는 연구를 이해하는 것은 역부족이었지만 흥미로운 주제들에 대해서는 후에 포스터 세션에서 자세하게 살펴볼 수 있어 좋은 경험이었다.
8/23 (Day 2)
이날은 Day 1에 비해 일정이 굉장히 널널했다. 오전에 고려대 오학주 교수님, 성균관대 차수영 교수님의 강연을 들었는데, 내가 아직 갈 길이 멀었다는 것을 뼈저리게 느꼈다. 학부 PL수업 수준으로는 감당하기 벅찼다. 나중에 Static Analysis를 공부해보고 다시 들어보고 싶은 강연이었다. 그리고 오후에는 교수님들께서 패널로 참여하셔서 PL교과서를 어떻게 만들어야 하는가에 대한 토론을 진행했다. 나도 PL수업을 들을 때 정형화된 교과서가 있었으면 좋겠다는 생각을 여러 번 했다. KAIST에서는 PL수업의 조교님이 자체 교과서를 제작하여 수업을 진행한다고 하는데, 퀄리티가 상당했다. 내가 수업을 들을 당시 알았다면 큰 도움이 됐을 것 같다.
위 일정이 모두 끝난 뒤에는 담양에 있는 죽녹원을 방문했다. 비가 와서 굉장히 찝찝했지만 풍경은 멋졌다. 다음에 맑을 때도 와보고 싶다.
관광을 마치고 저녁을 먹은 뒤 숙소로 돌아와 일정을 마무리했다.
8/24 (Day 3)
마지막 날에는 오전 강연만 있었다. KAIST 허기홍 교수님의 Bayesian Theory를 이용한 Static Analysis강연과 대학원생 두분의 발표를 들었는데, 역시 상당 부분을 이해하지 못했다. PL분야의 많은 부분이 Static Analysis인 만큼 이 분야를 더 공부해야겠다는 생각이 들었다. 이렇게 모든 일정을 마치고 집으로 돌아왔다. 전체적으로 유익했고, 재미있었고, 공부를 더 해야겠다는 생각이 들게 만든 학회였다.