본 글은 <CS524 Program Analysis>의 첫 번째 과제로 작성된 에세이이다.

Abstract

본 글은 정적 분석기(static analyzer)의 ‘정적’이 분석 방법의 성질일 뿐, 실제 기술의 작동 방식까지 정적이어서는 안 된다는 점을 논의한다. 산업 사례들은 정적 분석의 효과가 분석의 정교함뿐 아니라 개발자의 작업 흐름(workflow)과의 통합과 사용자와의 상호작용에 크게 좌우된다는 사실을 보여준다. 이를 바탕으로 본 글은 정적 분석을 포함한 소프트웨어 기술의 평가가 기존의 수학적 지표 중심 접근을 넘어 개발자의 이해 가능성, 수정 가능성, 신뢰성과 같은 인간 중심 요소를 함께 고려해야 한다고 주장한다. 궁극적으로 정적 분석기는 프로그램을 실행하지 않는다는 의미에서 정적이지만, 실제 개발 과정에서는 인간과 상호작용하며 능동적으로 개입하는 동적인 기술로 이해되어야 한다.

본문

정적 분석기(static analyzer)의 ‘정적’은 분석의 성질일 뿐, 분석기의 성질이 되어서는 안된다. 정적 분석기에서 ‘정적’은 기술적으로 프로그램을 실행하지 않고, 소스 코드만을 통해 오류를 추론한다는 의미를 지닌다. 그러나 페이스북과 구글은 역설적으로 ‘동적 과정’의 부재로 인한 정적 분석기의 한계를 마주하는 문제를 겪었다. 대시보드(dashboard) 한편에 조용히 쌓여 있는 경고, 개발자의 작업 흐름 밖에서 늦게 도착하는 보고, 신뢰를 잃어 무시되는 결과는 ‘정적’이 아닌, 정지된 분석을 낳는다.

페이스북과 구글의 사례는 정적 분석의 종단에는 개발자가 있음을 시사한다. 페이스북의 Infer와 Zoncolan은 깊은 절차간분석(interprocedural analysis)을 수행하지만, 이러한 분석 결과를 개발자가 작업 중인 시점인 diff-time이나 코드 리뷰 단계에서 제시함으로써 불필요한 맥락전환(context switch)을 줄이고 높은 수정률을 얻었다. 구글 역시 FindBugs를 대시보드나 별도의 리포트 형태로 제공했을 때는 거의 사용되지 않았지만, Error Prone을 컴파일 단계에 통합하고 Tricorder를 코드 리뷰 과정에 연결하자 개발자가 실시간 대응할 수 있는 형태로 문제가 제시되었고 수천 건의 수정이 이루어졌다. 개발자는 작업의 맥락에서 벗어나는 것에 큰 피로를 느끼며, 기술의 종단에는 결국 사람이 있다.

애플의 Xcode에 내장된 정적 분석기는 이러한 맥락에서 인상적인 사례를 보여준다. 애플의 제품과 애플리케이션에는 일관된 곡률 설계가 적용되어 있다. 흥미롭게도 이는 단순한 원이 아니라 곡률에 정규분포를 적용한 형태로, 사용자에게 더 큰 안정감을 주도록 설계되어 있다. 사용자 경험(UX) 기반의 설계 철학으로 유명한 애플답게, Xcode는 코드의 버그 리포트를 ‘동적’인 화살표로 시각화하여 제시한다. 이러한 표현 방식은 개발자에게 즉각적인 피드백을 제공하고 문제의 맥락을 직관적으로 이해하도록 돕는다. 최근 발표된 클로드(Claude AI)의 show me 기능 또한 같은 시사점을 찌른다. 사용자는 그래프를 직접 조정하고 막대(bar)를 조작하며 클로드의 답변과 상호작용할 수 있다. 이처럼 사람이 결과와 상호작용할 수 있도록 돕는 도구가 점점 중요해지는 상황에서, (특히 현대인이 취약한) 글과 코드만을 일방적으로 전달하는 보고 형태의 기술은 점차 가치를 잃어가고 있다.

우리는 정적 분석기를 포함한 소프트웨어 기술을 평가할 때 기존의 수학적 지표를 넘어 사람이 포함된 벤치마크를 고민해야 한다. 대학원 과정인 500번대 수업의 첫 과제가 에세이라는 사실은 첫 단추를 끼우는 연구의 방향을 성찰해 보라는 신호처럼 보인다. 정적 분석기는 버그를 탐지하는 기술이지만, 그 오류를 실제로 수정하는 주체는 결국 개발자이다. 기본적으로 우리가 수행하는 연구는 ‘정적’이다. 이론적 정밀함을 중시하는 연구 공동체에서 우리는 위양성(false positive), 정밀도(precision), 재현율(recall)과 같은 지표로 기술을 평가하며, 이러한 기준 역시 중요한 의미를 지닌다. 그러나 이제는 이러한 지표만으로 기술의 가치를 충분히 설명할 수 있는지 질문할 필요가 있다. 분석 결과가 이해 가능한가, 수정 가능한가, 작업 흐름(workflow)에 자연스럽게 통합되는가, 그리고 개발자가 그 결과를 신뢰하는가와 같은 인간적 요소 역시 기술의 실제 효과를 좌우한다. 다시 말해 정적 분석은 프로그램만을 분석하는 기술이 아니라, 조직의 협업 방식과 개발자의 주의까지 함께 고려해야 하는 기술이다. 기술은 정적일지언정 사람과 함께하는 기술은 동적이므로, 우리의 평가는 더 동적인 관점을 포함해야 한다.