Floating-Point Usage on GitHub: A Large-Scale Study of Statically Typed Languages

이 논문은 정적 타입 언어로 작성된 수백만 개의 GitHub 저장소를 대규모로 분석하여 실제 세계의 부동소수점 연산 사용 패턴을 규명하고, 기존 벤치마크의 대표성을 평가하며 1,000 만 개의 실제 부동소수점 함수 데이터셋을 공개함으로써 향후 부동소수점 자동 추론 기술 개발에 기여합니다.

핵심

🍳 1. 연구의 배경: "요리사들은 정말로 이 레시피만 쓸까?"

컴퓨터 과학자들은 "소수점 계산" (예: 0.1 + 0.2 같은 정밀한 계산) 이 매우 어렵고 오류가 잘 난다는 것을 알고 있습니다. 그래서 이 오류를 찾아주는 '자동 검사 도구'들을 개발해 왔습니다.

하지만 문제는 이 도구들을 테스트할 때 사용하는 **'시험용 레시피 (벤치마크)'**가 너무 이상적이라는 점입니다.

• 현실: 실제 요리사들은 복잡한 재료를 섞고, 불을 조절하고, 상황에 따라 요리를 바꿉니다.
• 시험용 레시피: 연구실에서는 "소금 1g, 설탕 2g"처럼 아주 단순하고 깔끔한 레시피만 사용합니다.

연구자들은 **"우리가 개발한 이 도구들이 실제 요리사들의 복잡한 부엌에서도 잘 작동할까? 아니면 실험실 레시피에만 맞춰진 것일까?"**라는 의문을 가졌습니다. 그래서 전 세계의 공개된 코드 (GitHub) 에서 실제 요리사들이 어떻게 요리하는지 대규모로 조사하기로 했습니다.

🔍 2. 연구 방법: "전 세계 부엌을 훑어보는 거대한 탐정"

이 연구는 GitHub라는 거대한 코드 저장소 (수백만 개의 프로젝트) 를 조사했습니다. 마치 전 세계의 모든 요리 레시피를 한 번에 훑어보는 것과 같습니다.

• 타겟: 요리사가 '정확한 재고'를 쓰는 언어 (C, Java, Go 등) 위주로 조사했습니다. (유동적인 언어는 재고 파악이 너무 어려워 제외했습니다.)
• 방식:
  1. 무작위 샘플링: 모든 레시피를 다 볼 수 없으니, 무작위로 수백만 개의 레시피를 뽑았습니다.
  2. 필터링: "아기들이 놀다가 만든 장난감 레시피"나 "아직 완성되지 않은 레시피"는 제외하고, 진짜 요리사들이 쓴 것만 남겼습니다.
  3. 키워드 검색: "소수점", "sin(사인)", "cos(코사인)" 같은 단어가 포함된 레시피를 찾아냈습니다.
  4. 중복 제거: 똑같은 레시피가 여러 번 올라온 경우 (예: 같은 레시피를 복사해서 여러 블로그에 올린 경우) 는 하나로 합쳤습니다.

📊 3. 주요 발견: "현실은 생각보다 훨씬 복잡하고 다양하다"

조사 결과, 기존에 알고 있던 상식과는 다른 놀라운 사실들이 나왔습니다.

① 소수점 계산은 정말 everywhere (어디에나) 있다!

• 발견: 조사한 프로젝트의 62% 이상에서 소수점 계산이 쓰이고 있었습니다.
• 비유: "요리할 때 소금이나 설탕을 안 쓰는 요리사는 거의 없다"는 뜻입니다. 과학, 게임, 금융, 인공지능 등 거의 모든 분야에서 쓰입니다.

② 실제 레시피는 '시험용 레시피'와 달랐다

• 시험용 레시피 (FPBench): 아주 단순합니다. "A 와 B 를 더하고 C 를 곱해라"처럼 계산만 쭉 나열되어 있고, 조건문 (if) 이나 반복문 (for) 은 거의 없습니다.
• 실제 레시피: 요리사들은 상황에 따라 재료를 바꿉니다.
  • 조건문 (If): "만약 재료가 부족하면 다른 걸로 대체해라" 같은 문장이 매우 많습니다.
  • 반복문 (Loop): "이 재료를 100 번 섞어라" 같은 반복 작업도 자주 나옵니다.
  • 함수 호출: 다른 요리사 (함수) 가 만든 레시피를 가져다 쓰는 경우가 많습니다.
• 결론: 기존에 개발된 '자동 검사 도구'들은 복잡한 조건문이나 반복문을 잘 처리하지 못하도록 만들어졌습니다. 하지만 실제 세상은 그 반대로 복잡합니다.

③ 유명한 '고급 재료'는 잘 안 쓴다?

• 연구자들은 과학자들이 자주 쓰는 'GNU 과학 라이브러리 (GSL)'라는 고급 재료집이 실제 코드에 얼마나 쓰이는지 확인했습니다.
• 결과: 놀랍게도 거의 쓰이지 않았습니다. (0.2% 미만)
• 비유: "요리사들이 전문 요리책에 나오는 고급 소스 대신, 집에서 흔히 쓰는 간장이나 된장을 더 많이 쓴다"는 뜻입니다. 기존 연구들은 고급 소스만 테스트했는데, 실제 세상은 훨씬 더 평범하고 다양한 재료를 쓰고 있었습니다.

🛠 4. 연구의 성과: "새로운 시험용 레시피집을 만들다"

이 연구는 단순히 "현실이 다르다"는 것을 보여주는 데 그치지 않았습니다.

• 1 천만 개의 실제 레시피 공개: 연구팀은 실제 GitHub 에서 찾아낸 1 천만 개의 소수점 계산 함수를 정리해서 공개했습니다.
• 새로운 벤치마크 제작: 이 데이터를 바탕으로, 실제 요리사들이 쓰는 복잡한 상황 (조건문, 반복문 포함) 을 담은 **59 개의 새로운 '실전 시험용 레시피'**를 만들어 공개했습니다.

이제 개발자들은 이 새로운 레시피집으로 자신의 '자동 검사 도구'를 테스트할 수 있습니다. "이 도구가 실험실 레시피만 통과하는 게 아니라, 실제 복잡한 부엌에서도 잘 작동하는가?"를 확인할 수 있게 된 것입니다.

💡 5. 결론: "이 연구가 우리에게 주는 메시지"

이 논문은 **"우리가 연구할 때 쓰는 기준 (벤치마크) 이 너무 이상적이라서, 실제 문제를 해결하는 도구를 만드는 데 방해가 되고 있다"**고 경고합니다.

• 과거: "도구가 복잡한 걸 못 하니까, 복잡한 걸 빼고 단순한 것만 테스트하자."
• 미래 (이 연구를 통해): "현실은 복잡하니까, 도구를 복잡하게 만들어서 현실에 맞춰야 한다."

이 연구는 컴퓨터 과학자들이 현실 세계의 복잡함을 더 잘 이해하고, 더 강력한 도구를 만들 수 있는 발판을 마련했다는 점에서 매우 중요합니다. 마치 요리사들이 실험실 레시피를 버리고, 실제 부엌의 소란과 복잡함 속에서 더 맛있는 요리를 만들 수 있게 된 것과 같습니다.

기술 요약

1. 연구 배경 및 문제 제기 (Problem)

부동소수점 (Floating-point) 산술은 임베디드 시스템, 과학적 계산, 머신러닝 등 다양한 분야에서 널리 사용되지만, 반올림 오차, 무한대 (Infinity), NaN(Not-a-Number) 등의 특수 값으로 인해 그 정확성을 추론하는 것은 매우 어렵습니다.

기존의 자동화된 부동소수점 분석 기법 (정적/동적 분석, 프로그램 수정 등) 은 주로 소규모 벤치마크나 연구자들이 수동으로 선별한 코드를 기반으로 평가됩니다. 그러나 이러한 벤치마크가 실제 개발자들이 작성하는 '실제 세계 (Real-world)' 코드를 얼마나 잘 대표하는지에 대한 실증적 연구는 부족했습니다.

• 핵심 문제: 현재 사용 중인 부동소수점 벤치마크가 실제 코드와 얼마나 다른지, 그리고 자동화 도구가 실제 사용자의 요구 (예: 복잡한 제어 흐름, 라이브러리 사용 패턴 등) 를 충족할 수 있는지 알 수 없음.

2. 연구 방법론 (Methodology)

이 논문은 GitHub 에 있는 공개 저장소를 대상으로 **정적 타입 언어 (Statically Typed Languages)**의 부동소수점 사용 패턴을 대규모로 분석하는 최초의 연구를 제시합니다.

A. 데이터 수집 파이프라인 (Scyros Framework)

저자들은 재현 가능하고 확장 가능한 데이터 마이닝 프레임워크인 Scyros를 개발하여 다음과 같은 다단계 파이프라인을 구축했습니다.

1. 무작위 샘플링 (Random Sampling): GitHub 의 REST API 를 사용하여 저장소 ID 를 무작위로 추출 (포크 제외).
2. 메타데이터 필터링:
   • 저장소 크기 < 50KB, 생성 후 2 개월 미만, 주요 언어가 지정되지 않은 '장난감 (Toy)' 프로젝트 제거.
   • 사회적 지표 (Star 수 등) 로 필터링하지 않음 (편향 방지).
3. 언어 필터링: 정적 타입 언어 (C, C++, Java, Go, C#, TypeScript 등 51 개 언어) 만 선별. 동적 타입 언어는 타입 추론이 어려워 대규모 자동화 분석이 불가능하므로 제외.
4. 다운로드 및 키워드 필터링:
   • 정적 타입 언어 파일 다운로드.
   • 키워드 기반 탐지: 부동소수점 타입 (float, double, real), 초월 함수 (sin, cos, exp), 특수 값 (nan, inf), 임의 정밀도 키워드 등을 정규식으로 검색.
   • 주석 (Comments) 과 문자열 리터럴은 제거하여 오탐지 (False Positive) 최소화.
5. 중복 제거 (De-duplication): 토큰 수준에서 동일한 파일 (Whitespace 제외) 을 제거하여 편향 방지.
6. 파싱 및 함수 추출: tree-sitter 를 사용하여 파일을 파싱하고, 부동소수점 키워드가 포함된 개별 **함수 (Function)**를 추출.

B. 분석 대상

• 최종적으로 447,209 개의 GitHub 프로젝트에서 약 1,000 만 개의 부동소수점 함수를 추출하여 데이터셋을 구성했습니다.

3. 주요 기여 (Key Contributions)

1. 대규모 부동소수점 코드 마이닝: 정적 타입 언어에 대한 최초의 대규모 실증 연구를 수행하여 부동소수점 코드의 실제 사용 현황을 정량화했습니다.
2. 오픈 소스 데이터셋 및 도구:
   • Scyros: 대규모 코드 분석을 위한 재사용 가능한 오픈소스 프레임워크.
   • 1000 만 개 함수 데이터셋: 실제 부동소수점 함수 1,000 만 개를 포함한 데이터셋 공개.
   • 59 개 C 벤치마크: 실제 코드에서 추출된 59 개의 독립적인 C 부동소수점 벤치마크 (Challenge Benchmarks) 제공.
3. 벤치마크 대표성 평가: 기존 문헌의 벤치마크 (FPBench 등) 가 실제 코드와 어떤 점에서 다른지 체계적으로 비교 분석했습니다.

4. 주요 결과 (Results)

RQ1: 부동소수점 코드의 보편성

• 95% 신뢰수준으로 GitHub 의 정적 타입 프로젝트 중 62% 이상이 부동소수점 코드를 포함하고 있음을 확인했습니다.
• 부동소수점 코드는 프로젝트 내에서도 소수의 파일에 집중되어 있는 경향이 있습니다.

RQ2: 부동소수점 코드의 특성

• 구조적 특징:
  • 함수 크기는 일반적으로 작음 (중앙값 약 30 줄).
  • **조건문 (Conditionals)**과 **함수 호출 (Function calls)**이 매우 흔함.
  • **루프 (Loops)**는 조건문과 함께 존재하는 경우가 많음 (실제 코드에서는 루프가 포함된 함수가 일반적임).
  • NaN/Infinity와 같은 특수 값은 드물게 명시적으로 사용됨.
• 정밀도: 단일 정밀도 (32-bit) 와 이중 정밀도 (64-bit) 가 압도적으로 많이 사용되며, 혼합 정밀도 (Mixed-precision) 나 임의 정밀도는 매우 드뭅니다.
• 라이브러리 사용: GNU Scientific Library (GSL) 와 같은 전문 수치 라이브러리는 실제 코드에서 거의 사용되지 않음 (0.2% 미만).

RQ3: 기존 벤치마크의 대표성 (FPBench 등)

• 차이점: 기존 벤치마크 (FPBench) 는 실제 코드와 비교하여 조건문과 루프가 현저히 적고, 초월 함수 (Transcendental functions) 호출이 과대표 (Over-represented) 되어 있습니다.
• 원인: 기존 벤치마크는 현재 분석 도구들이 처리할 수 있는 단순한 구조의 코드로 선별되었기 때문입니다.
• 결론: 기존 벤치마크는 실제 개발자가 작성하는 코드의 복잡도 (제어 흐름, 모듈성) 를 반영하지 못합니다.

5. 의의 및 시사점 (Significance)

1. 연구 방향의 전환: 부동소수점 분석 도구 개발은 단순한 산술 식 분석을 넘어, **모듈성 (Modularity)**과 **비선형 제어 흐름 (조건문, 루프)**을 처리하는 능력에 초점을 맞춰야 함을 시사합니다.
2. 새로운 벤치마크의 필요성: 연구자들이 실제 사용자의 기대에 부응하는 도구를 개발하기 위해서는, 이 논문에서 공개된 데이터셋을 기반으로 한 현실적인 벤치마크가 필수적입니다.
3. 동적 타입 언어의 한계: 정적 타입 언어에서는 타입 어노테이션을 통해 효율적으로 분석이 가능하지만, 동적 타입 언어 (Python 등) 에서는 실행 시 타입 추정이 필요하여 대규모 자동화 분석이 어렵다는 점을 지적했습니다.
4. 실용적 검증: 추출된 59 개의 C 벤치마크를 통해 기존 도구 (NSan, Frama-C 등) 가 실제 복잡한 코드 (포인터, 매크로, 중첩 함수 호출 등) 에서 어떻게 작동하는지 검증할 수 있는 기반을 마련했습니다.

요약

이 논문은 GitHub 의 방대한 코드를 분석하여 "실제 부동소수점 코드는 어떻게 생겼는가?"에 대한 답을 제시했습니다. 그 결과, 기존 연구에서 사용되던 벤치마크는 실제 코드의 복잡성 (조건문, 루프, 모듈성) 을 과소평가하고 있음을 발견했으며, 이를 해결하기 위해 대규모 실증 데이터셋과 새로운 벤치마크를 공개함으로써 부동소수점 분석 기술의 실용적 발전을 이끌고자 합니다.