ASTRA: LLM을 위한 HackerRank의 코딩 벤치마크

HackerRank의 ASTRA 벤치마크는 실제 세계의 코딩 작업을 밀접하게 모방하도록 설계된 다중 파일(multi-file), 프로젝트 기반 문제들로 구성되어 있습니다. 목표는 소프트웨어 개발 생명 주기(SDLC) 전체에 걸쳐 고급 AI 모델의 능력을 평가하는 것입니다. 초기 버전(v1)은 주로 프론트엔드(frontend) 개발 문제로 구성되어 있으며, Node.js, React.js, Angular.js, Django, Java Spring Boot, Ruby on Rails, .NET과 같은 프레임워크를 포함합니다. v1에서 평가는 오직 코드 생성(code generation) 작업을 통해 평가되는 새로운 기능 개발 수행 능력에만 집중합니다. 평가 프레임워크의 입력과 출력은 모두 텍스트 기반입니다. 주요 강조점은 모델의 정확성(correctness)과 일관성(consistency)이며, 이는 실제 애플리케이션에서 필수적인 요소입니다. 평가 지표에는 평균 점수(average score)와 평균 pass@1이 포함되며, 일관성(중앙값 표준 편차)은 추가적인 참고 자료로 고려됩니다.

HackerRank ASTRA 벤치마크의 특징:

평균 점수(average scores) 분석을 바탕으로, o1, o1-preview, Claude-3.5-Sonnet-1022 모델은 다중 파일 기반의 실제 프론트엔드 코딩 작업에서 우수한 성능을 보여줍니다. 그러나 65개 질문에 걸친 평균 점수의 높은 분산으로 인해, 대응 표본 t-검정(paired t-test) 결과 GPT-4o-0513을 제외하고는 모델 간 성능 차이가 통계적으로 유의미하지 않은 것으로 나타났습니다. 그럼에도 불구하고 k=32에서의 평균 점수는 실제 프로덕션 환경에서 의미 있는 실질적 영향력을 나타냅니다. 평균 pass@1 지표를 사용하여 모델을 평가했을 때도 유사한 경향이 관찰되었습니다.

벤치마크 평가에서, 우리는 문제당 32회의 독립적인 실행에 대한 점수의 표준 편차 (SD)를 사용하여 LLM의 **일관성 (Consistency)**을 평가하였으며, 이후 65개 문제에 대한 중앙값 SD를 평가했습니다. 모델들은 다양한 수준의 성능 안정성을 보여주었으며, Claude-3.5-Sonnet-1022가 가장 낮은 변동성 (SD = 0.0497)을 보이며 문제 전반에 걸쳐 가장 높은 일관성을 나타냈습니다. Claude-3.5-Sonnet-1022와 나머지 모델들 사이의 차이는 대응 표본 t-검정 (paired t-test)을 기준으로 통계적으로 유의미합니다.

v1 ASTRA 벤치마크 데이터셋은 10개의 주요 코딩 기술 도메인과 34개의 하위 카테고리로 체계적으로 분류된 65개의 프로젝트 기반 코딩 문제로 구성됩니다.

주요 통계는 다음 표에 요약되어 있습니다:

다음은 ASTRA 벤치마크 데이터셋의 RESTful API 프로젝트 예시입니다. 이 과제는 Node.js와 Express를 사용하여 제품 기록을 관리하기 위한 RESTful API를 개발하는 것을 포함하며, 이는 일반적인 실제 이커머스 개발 시나리오를 반영합니다. 프로젝트 구조는 다음 스크린샷에 묘사되어 있습니다:

[IMG:1]

API는 다음 엔드포인트 (endpoints)를 포함합니다:

[IMG:2]

특정 비즈니스 요구 사항에 따라 PUT 및 DELETE 메서드를 통한 수정 또는 삭제는 명시적으로 허용되지 않습니다. 구현 시 라우트 (routes), 컨트롤러 (controllers), 데이터베이스 상호작용을 위한 별도의 파일로 구성된 모듈형 코드 구조를 의무화합니다. 지원자는 견고한 에러 핸들링 (error handling)을 구현해야 하며, 제품이 사전 정의된 기준을 충족하는 경우에만 게시되도록 보장하는 것과 같은 비즈니스 로직을 준수해야 합니다:

[IMG:3]

이 과제는 다음과 같은 프로덕션급 API 구축 시 직면하는 도전 과제들을 반영합니다:

[IMG:4]

또한, 이 문제는 적절한 HTTP 상태 코드 (status codes) 반환, 에러 응답 처리, 조직화된 프로젝트 구조 준수와 같은 실무적인 측면을 강조합니다. 이는 확장 가능하고 유지보수가 용이한 API를 구축하는 데 있어 핵심적인 요소입니다.

GPT-4o-0513의 솔루션 중 하나를 예로 들어보겠습니다: GPT-4o-0513은 API의 핵심 로직을 성공적으로 구현했습니다. controllers/products.js에 있는 컨트롤러(Controllers)는 제품 추가, 조회, 업데이트와 같은 작업을 효과적으로 처리했습니다. 또한, routes/products.js의 라우트(Routes)는 API 엔드포인트(Endpoints)를 각각의 컨트롤러에 매핑하도록 올바르게 정의되었습니다.

제품 처리를 위해 GPT-4o-0513이 정의한 라우트는 다음과 같습니다:

핵심 로직을 올바르게 구현했음에도 불구하고, GPT-4o-0513은 중요한 단계를 놓쳤습니다. 바로 제품 라우트를 메인 애플리케이션 파일(app.js)에 통합하는 작업입니다. routes/products.js에서 productsRouter를 임포트(Import)하여 / 경로에 연결하는 대신, GPT-4o-0513은 잘못된 플레이스홀더(Placeholder)인 indexRouter를 사용했습니다. 이러한 실수로 인해 라우트가 제대로 연결되지 않았고, /products로 향하는 모든 요청은 "404 Not Found" 에러와 함께 실패했습니다. 결과적으로 /products로부터의 응답을 기대하는 모든 테스트 케이스(Test case)가 실패했습니다.

다음은 GPT-4o-0513이 제공한 app.js입니다:

이 문제를 해결하려면 routes/products.js의 productsRouter를 app.js의 루트(/) 엔드포인트에 직접 연결해야 합니다. routes/products.js 내에 이미 절대 경로(Absolute paths)가 정의되어 있으므로, 이를 통해 모든 제품 관련 라우트에 예상대로 접근할 수 있습니다.

app.js에서 요구되는 수정 사항:

다음 문서에서 추가적인 세 가지 예시와 함께 상세한 프로젝트 워크스루(Walkthrough)를 제공합니다. 이 리소스는 문제와 솔루션 구조를 더 깊이 있게 탐구하고자 하는 분들을 위해 마련되었습니다.

평가는 주로 코드 생성의 정확성과 일관성을 대상으로 하며, 텍스트 기반의 API 호출에 대응하여 정확하고 기능적인 솔루션을 생성하는 모델의 능력에만 집중합니다.

1. 입력 데이터 준비 (Input Data Preparation)

2. 솔루션 생성 (Solution Generation)

3. 후처리 (Post-Processing)

4. 솔루션 통합 (Solution Integration)

5. 테스트 케이스 검증 (Test Case Validation)

6. 부분 결과 저장 (Store Partial Results)

7. 전체 집계 (Overall Aggregation)

모든 질문에 대한 평가가 완료되면, 각 질문에 대한 핵심 성능 지표(key performance metrics)를 계산하기 위해 집계 스크립트(aggregation script)가 실행됩니다.

평가 지표 (Evaluation Metrics)

여기서:

여기서:

이러한 지표들은 완전한 솔루션과 부분적으로 정답인 솔루션 모두가 중요성을 갖는 실제 코딩 표준과의 일치성을 고려하여 선택되었습니다. 평균 점수(Average Score)는 모델의 점진적인 문제 해결 능력을 반영하며, 솔루션이 완전히 정확하지 않더라도 기능의 어느 정도가 구현되었는지에 대한 세밀한 관점을 제공합니다. Pass@1은 모델이 즉시 정확한 코드를 얼마나 신뢰성 있게 생성할 수 있는지를 나타내며, 이는 개발자들이 최소한의 수정으로 솔루션을 완성하고자 하는 실제 시나리오에서 매우 중요합니다. 중앙값 표준 편차(Median Standard Deviation)는 각 문제에 대한 모델 솔루션의 일관성을 반영하며, 모델이 여러 번의 시도에 걸쳐 꾸준한 성능을 보이는지 또는 상당한 변동성을 보이는지를 강조합니다.

k=32를 사용하는 것은 모델이 다양한 솔루션을 탐색하는 능력을 측정하는 의미 있는 척도를 제공합니다. 이 정도의 시도 횟수는 모델이 실행 가능한 솔루션 공간에 집중을 유지하면서도 미세한 변동성을 극복할 수 있게 해줍니다. 평균 점수 및 Pass@1과 같은 지표에는 평균(mean)을 사용하는데, 이는 이러한 집계 지표들이 문제 전반에 걸친 모델의 전반적인 성능을 포착하는 것을 목표로 하기 때문입니다. 그러나 표준 편차의 경우 중앙값(median)을 사용합니다. 이는 문제 간 점수의 변동성에 이상치(outliers)가 포함되는 경우가 많기 때문에, 중앙값이 모델 성능의 전형적인 일관성을 측정하는 데 더 견고한(robust) 척도를 제공하기 때문입니다.

결과 1: ASTRA 벤치마크는 다중 파일 프론트엔드(front-end) 프로젝트로 LLM에 도전 과제를 제시합니다.

결과 2: o1, o1 preview 및 Claude 3.5 Sonnet은 프론트엔드 개발 분야의 선도적인 모델입니다 (2025년 1월 기준).

*결과 3: *o1은 평균 점수와 평균 Pass@1에서 앞서며, Claude 3.5 Sonnet은 일관성 측면에서 더 뛰어난 성능을 보입니다.

*결과 4: *모델 성능은 세부 기술(subskills)에 따라 다르며, 이는 "최고의" AI 프론트엔드 개발 도구가 특정 사용 사례에 따라 달라질 수 있음을 시사합니다.

결과 5: 모든 모델에서 XML이 JSON보다 더 나은 성능을 보임

XML 프롬프트 (XML prompt)

JSON 프롬프트 (JSON prompt)

결과 6: ASTRA 벤치마크는 o1-preview 및 o1에서 JSON 이스케이프 (JSON escaping) 문제와 드문 거부 (refusals) 현상을 드러내며, 정교한 가드레일 (guardrails)의 필요성을 강조함.

결과 7: 모델의 일반적인 오류 유형

사용자 인터페이스 및 프레젠테이션 문제 (User Interface and Presentation Issues): 애플리케이션의 시각적 또는 상호작용적 측면에 영향을 미치는 오류로, 잘못되거나 최적화되지 않은 레이아웃을 표시하여 사용자 경험을 저하시키고 이를 수정하기 위해 사용자의 개입을 필요로 함.

데이터 처리 및 오용 오류 (Data Handling and Misuse Errors): 데이터 파일 또는 구조의 부적절하거나 불필요한 조작으로 인해 발생하는 오류로, 애플리케이션의 예상된 기능을 방해하며 잠재적으로 런타임 (runtime) 또는 컴파일 (compilation) 실패로 이어질 수 있음.

오타, 구문 및 오해 오류 (Typos, Syntax, and Misinterpretation Errors): 사소한 포맷팅 문제, 타이포그래피 실수 또는 문제 설명에 대한 오해로 인해 발생하는 오류. 이러한 오류는 일반적으로 잘못된 출력 포맷팅이나 지정된 요구 사항을 준수하지 못하는 경우를 포함함.

논리 및 구현 오류 (Logical and Implementation Errors): 구문은 올바르지만, 특정 조건, 엣지 케이스 (edge cases) 또는 문제 제약 조건을 고려하지 못해 발생하는 구현상의 오류.

결과 8: 모델 성능과 입출력 길이 사이의 상관관계

평균 출력 길이와 평균 점수 사이의 상관관계는 약 -0.560으로, 중간 정도의 음의 상관관계를 나타냄. 이는 출력이 길수록 일반적으로 점수가 낮아지는 경향이 있음을 시사함. 반면, 입력 길이와 평균 점수 사이의 상관관계는 약 -0.164로, 약한 음의 상관관계를 반영함. 이는 입력이 길어질 경우 평균 점수가 약간 감소할 수 있음을 의미함.

본 연구는 다중 파일(multi-file) 기반의 실제 코딩 작업에 대한 AI 모델 성능에 대해 가치 있는 통찰을 제공하지만, 몇 가지 한계점이 있음을 유의해야 합니다:

제한된 기술 범위 (Limited Skill Coverage): 현재 버전의 벤치마크는 주로 React 및 Angular.js와 같은 프론트엔드 (Front-end) 프로젝트에 집중되어 있어, 기술 평가의 범위가 좁습니다. 이러한 영역들이 중요하기는 하지만, 백엔드 (Back-end) 기술 및 기타 도메인에 대한 표현이 부족하여 평가의 포괄성을 제한합니다. 다음 반복 버전에서는 더 넓은 범위의 백엔드 기술과 기술 스택을 포함하도록 벤치마크를 확장하여 이 한계점을 해결하고자 합니다.

에이전트적 접근 방식의 부재 (Absence of Agentic Approaches): 우리의 평가는 모델의 성능을 극대화하기 위한 에이전트적 (Agentic) 방법론을 아직 활용하지 않고 있습니다. 에이전트적 방법론이란 모델이 벤치마크 제약 조건 내에서 반복적으로 탐색하고, 적응하며, 솔루션을 개선할 수 있는 자율성을 부여받는 것을 의미합니다. 향후 버전에서 이러한 접근 방식을 통합하면, 동적이고 복잡한 문제 해결 시나리오에서 모델의 잠재력에 대해 더욱 현실적이고 미묘한 이해를 가능하게 할 것입니다.

모델 및 반복적 피드백 메커니즘의 부족 (Lack of More Model and Iterative Feedback Mechanism): 현재 연구는 테스트 케이스 결과에 기반한 피드백을 제공하지 않고, 각 시도에 대해 직접 출력을 요청함으로써 소수의 모델을 평가합니다. 이러한 방식은 실제 코딩의 필수적인 측면인 '반복적인 가이드 (Iterative guidance)'가 주어졌을 때 모델이 어떻게 작동하는지 평가하는 능력을 제한합니다.

제한된 모델 선택 (Limited model selection): 현재 모델 선택은 최상위 모델(Top-tier models)의 일부로 제한되어 있습니다. 하지만 우리는 향후 평가에서 DeepSeek 및 Llama와 같은 추가 모델을 포함하여 테스트를 확장하기 위해 적극적으로 노력하고 있습니다. 또한, 리더보드 (Leaderboard)를 강화하기 위해 더 폭넓은 모델 비교를 가능하게 하는 커뮤니티 주도형 벤치마크 테스트 방식을 개발하고 있습니다. 이번 출시와 함께 첫 단계로서, 우리는 GitHub 및 Hugging Face에 65개의 모든 프로젝트 질문을 오픈 소스로 공개합니다.

Carlos E. Jimenez, John Yang, Alexander Wettig, Shunyu Yao, Kexin Pei, Ofir Press, Karthik Narasimhan. SWE-bench: 언어 모델이 실제 GitHub 이슈를 해결할 수 있을까? arXiv preprint arXiv:2310.06770, 2023. https://arxiv.org/abs/2310.06770**

Zhaojian Yu, Yilun Zhao, Arman Cohan, Xiao-Ping Zhang. HumanEval Pro 및 MBPP Pro: 자체 호출 코드 생성에 대한 대규모 언어 모델 평가. arXiv preprint arXiv:2412.21199, 2024. https://arxiv.org/abs/2412.21199**

Woojeong Kim, Ashish Jagmohan, Aditya Vempaty. Scale AI SEAL: LLM의 API 사용을 평가하기 위한 스위트. arXiv preprint arXiv:2409.15523, 2024. https://arxiv.org/abs/2409.15523**

Berk Atil, Alexa Chittams, Liseng Fu, Ferhan Ture, Lixinyu Xu, Breck Baldwin. LLM 안정성: 몇 가지 놀라움과 함께 상세 분석. arXiv preprint arXiv:2408.04667, 2024. https://arxiv.org/abs/2408.04667**

Jia Li, Ge Li, Yunfei Zhao, Yongmin Li, Huanyu Liu, Hao Zhu, Lecheng Wang, Kaibo Liu, Zheng Fang, Lanshen Wang, Jiazheng Ding, Xuanming Zhang, Yuqi Zhu, Yihong Dong, Zhi Jin, Binhua Li, Fei Huang, Yongbin Li. DevEval: 실제 코드 저장소에 맞춰진 수동 주석 코드 생성 벤치마크. arXiv preprint arXiv:2405.19856, 2024. https://arxiv.org/abs/2405.19856