[!WARNING] 공사중입니다. 좀 더 정리가 필요한 문서입니다.

연구 생활이란 (연사: 김문주)

오늘 강연은 기술적인 내용보다는 ‘연구 생활이란 어떤 것인가’에 대한 기술 외적인 (non-technical) 이야기입니다. (이 연구에는 홍신 교수님의 기여가 많습니다.)

연사 (김문주)는 이번 주에 50세, 즉 ‘지천명’ (知天命)을 맞았습니다.

10년의 화두: Fault Localization

초창기 (MIP 시절)에는 process algebra와 같은 이론적인 연구를 했습니다. 재밌는 연구를 찾아 창업을 하기도 했습니다.

지도교수님이신 이인섭 교수님은 “대학원생은 인생 처음으로 뭔가를 생산하게 된다"며, “연구실 학풍이 사람에게 중요하게 작용한다"는 가르침을 주셨습니다.

제가 하고 싶었던 것은, 실제 버그를 찾는 것 (finding)보다는 솔루션을 만들어내는 것 (solving)이었습니다. 당시 “사람들이 test case oracle generation을 잘 모르고 만든다"고 느꼈고, 약 10년 전부터 결함 위치 추정 (fault localization) 분야에 관심을 가졌습니다.

기존 접근법의 한계: Spectrum-Based FL (연사: 김윤호)

결함 위치 추정 (FL)의 전통적인 접근법은 Spectrum-Based FL (SBFL) 입니다. 이는 프로그램의 실행 ‘스펙트럼’ (커버리지)을 분석하는 방식입니다.

• 이론: passing test (통과하는 테스트)에서 실행되는 코드 라인과 failing test (실패하는 테스트)에서 실행되는 코드 라인을 비교합니다. “실패하는 테스트에서는 많이 실행되지만, 통과하는 테스트에서는 적게 실행되는 라인"이 버그일 확률이 높다고 추정합니다.

• 비판: 하지만 이 방식은 치명적인 한계가 있었습니다. “오류 확률이 높은 상위 1%를 걸러낸다 쳐도, 그 양이 여전히 수없이 많다. 이걸 개발자가 언제 다 보냐?“는 것이었죠.

• 결과: 이 때문에 2010년대 초반, SBFL은 ‘막다른 길’ (dead end)이라는 비난을 받기도 했습니다.

핵심 아이디어: MUSE (Mutation-Based FL)

바로 이 시점에 홍신 교수님의 핵심 아이디어가 등장했습니다.

“코드 일부를 의도적으로 바꿔서 (mutate), 만약 pass하던 테스트가 fail하게 되거나, 혹은 fail하던 테스트가 pass하게 되면… 그 코드는 버그와 관련이 깊다.”

이 아이디어가 MUSE (MUtation-baSEd Fault Localization)가 되었습니다.

• 이론: 이는 프로그램의 syntatic (구문) 변화 (e.g., a > b를 a >= b로 바꾸는 변이)를 통해, 프로그램의 semantic (의미) 변화 (e.g., 테스트 통과/실패 여부)를 관찰하는 새로운 차원의 접근법입니다.

• 작동:

  1. Failing TC가 Pass가 되면: 그 변이(mutation)가 버그를 고쳤다는 뜻이므로, 해당 라인은 매우 강력한 버그 후보입니다.

  2. Passing TC가 Fail이 되면: 그 변이가 정상 동작을 망가뜨렸다는 뜻이므로, 해당 라인은 버그 로직과 밀접하게 연관된 (정상 코드의) 부분임을 의미합니다.

연구의 진화 1: 비용 절감과 실전 투입 (HybridMUSE & MUSEUM)

MUSE의 강력함에도 불구, ‘mutant’ (변이)를 하나하나 실행하는 것은 시간이 너무 많이 소모되는 비싼 작업이었습니다.

• HybridMUSE: 이 문제를 해결하기 위해, 빠른 SBFL 방식과 강력한 MBFL 방식을 결합했습니다. SBFL로 후보군을 빠르게 줄이고, 유망한 후보에 대해서만 변이를 수행하여 mutant 개수를 획기적으로 줄였습니다.

• MUSEUM (실전 적용): 이 기술을 Java처럼 인터페이스가 많아 분석이 까다로운 실제 프로그램에 적용했습니다. (참고: MUSEUM은 1년 반 동안 개발자들이 해결하지 못하고 헛방 패치만 내놓았던 Eclipse bug 322222의 원인을 쉽게 찾아내는 데 성공)

  • MUSEUM (프로그램)

연구의 진화 2: 기계학습(ML)과의 융합 (MUSIC & PRINCE)

여전히 FL에는 test가 중요합니다. (그동안 고치는거 이야기를 많이 했지만..)

Invasive software testing MUSIC (fault localization 도구)#MUSIC이란 (이런 영감은 어디서 얻었냐는 질문에) 박사 학위 후 홋카이도에 다녀오다가 문득 생각이 들었습니다.

• 아이디어: 기계학습 (ML)과 기존 분석 기능을 50:50으로 섞는 것이 아니라, 수많은 feature를 한 번에 입력받아 학습하는 단일 ML formula를 만들자는 것이었습니다. (관련 도구: PRINCE)

현재와 미래: 비용 문제와 LLM (연사: 유신)

하지만 mutation은 (MUSE든 어떤 방식이든) 근본적으로 비싼 작업입니다.

• 비용 절감 1 (Ahead-of-Time MBFL): 미리 변이를 계산해두는 방식입니다.

• 비용 절감 2 ([Predictive Mutation Analysis]): test_user_login_fail 같은 테스트 케이스의 ‘이름’과 user.password 같은 소스 코드의 ‘identifier’ (식별자)를 엮는, 이른바 **natural language channel**을 이용합니다. 이를 통해 실제로 돌려보지 않고도 유용할 것 같은 변이를 ‘예측’ (predict)합니다.

현재 이 연구는 SBFL, MBFL, APR (자동 버그 수정), LLM 등을 모두 합치는 방향 (예: defect prediction, unified debugging)으로 진화하고 있습니다. (유신 교수 등 여러 사람과 협업)

결론: 하나의 문제와 협력의 가치

“Sticking to a single problem can be fun, if the problem is important.”

(FL에 무슨 큰 뜻이 있어서 시작한 게 아니라) 하나의 중요한 문제를 계속 파고드는 것은 재미있을 수 있습니다. 10년 전만 해도 FL은 발전이 없다고 보는 등 인식이 크게 좋지 않았는데, 계속하다 보니 사람들의 인식이 바뀌는 것이 보였습니다.

콜라보 (Collaboration)는 성공적인 연구의 핵심 (key)입니다.