SPECMINE: A Large-Scale Corpus of Spec-Driven Development Artifacts

소프트웨어 생성의 세계에는 오랫동안 프로그램의 아이디어와 프로그램 그 자체 사이의 근본적인 긴장이 존재해 왔습니다. 전통적으로 개발자는 머릿속에 비전을 품거나 냅킨에 메모를 적은 뒤, 그 비전을 코드 라인으로 번역하기 위해 수개월을 보냈습니다. 코드는 가장 중요한 결과물이었으며, 작성되고, 검토되고, 유지 관리되는 대상이었습니다. 그러나 최근에는 이 순서가 뒤집힌 새로운 관행이 등장했습니다. 단 한 줄의 코드가 작성되기 전에, 개발자는 종종 인공지능 도구의 도움을 받아 구축해야 할 대상에 대한 상세하고 구조화된 설명을 초안으로 작성합니다. 평이한 언어로 작성된 이 설명은 청사진 역할을 합니다. 그러면 AI 에이전트가 이 청사진을 읽고 실제 소프트웨어를 생성합니다. 이러한 변화는 프로젝트에서 가장 중요한 문서가 더 이상 코드가 아니라 명세(specification) 그 자체임을 의미합니다. 이러한 명세가 어떻게 작성되는지, 어떻게 변하는지, 그리고 어떻게 최종적으로 작동하는 소프트웨어가 되는지를 이해하는 것은 이제 기술이 어떻게 만들어지는지를 연구하는 모든 이들에게 중요한 질문이 되었습니다.

지금까지는 이 새로운 지형에 대한 명확한 지도가 없었습니다. 개발자들이 이러한 청사진을 작성하도록 돕는 수십 가지의 도구들이 등장했지만, 그 도구들이 실제로 만들어내는 문서들에 대해서는 대규모로 연구된 적이 없었습니다. 카네기 멜론 대학교의 연구원 샤얌 아가르왈(Shyam Agarwal)과 보그단 바실레스쿠(Bogdan Vasilescu)는 명세 문서들과 그 명세가 만들어내는 코드의 거대한 집합체인 SPECMINE을 구축함으로써 이를 변화시켰습니다. 그들은 2025년과 2026년에 이 관행이 태동하던 시기의 스냅샷을 포착하여, GitHub의 공개 프로젝트로부터 약 50만 개의 명세 파일을 수집했습니다. 이 컬렉션에는 명세의 텍스트뿐만 아니라, 해당 프로젝트의 전체 이력, 작성자, 그리고 명세가 업데이트될 때 발생한 구체적인 코드 변경 사항까지 포함되어 있습니다. 이는 소프트웨어 커뮤니티가 AI 시대에 서술된 설명이 어떻게 기능하는 프로그램으로 변모하는지를 상세히 볼 수 있게 된 첫 번째 사례입니다.

연구진은 전체적인 그림을 포착하기 위해 두 가지 주요 방식으로 이 컬렉션을 구축했습니다. 첫째, 그들은 대부분의 새로운 도구들이 사용하는 표준 명칭인 "spec.md" 또는 "specs.md"라는 이름의 파일들을 찾았습니다. 이 검색만으로 73,000개 이상의 서로 다른 저장소에서 470,000개가 넘는 파일을 회수했습니다. 그다음, 요구사항, 설계, 과업(task)을 별도의 파일로 구분하여 사용하는 AWS Kiro라는 특정 도구에 대한 두 번째 별도 검색을 추가했습니다. 이를 통해 98,000개의 파일을 더 확보했습니다. 이 검색들을 결합함으로써, 그들은 현재 사용 중인 거의 모든 도구를 포괄하는 광범위한 센서스를 만들어냈습니다. 이 컬렉션의 모든 파일에는 프로젝트의 스타(star) 수, 사용하는 프로그래밍 언어, 명세를 생성한 특정 도구와 같은 정보가 태그로 붙어 있습니다.

이러한 서술된 계획이 실제로 어떻게 코드로 이어지는지 이해하기 위해, 연구진은 한 단계 더 나아갔습니다. 그들은 인기 있는 소규모 프로젝트 그룹에 집중하여, 명세 파일과 관련된 모든 코드 변경 요청을 추적했습니다. 그들은 개발자나 AI 에이전트가 청사진과 코드를 동시에 업데이트한 약 6,000건의 요청, 즉 풀 리퀘스트(pull request)를 발견했습니다. 이를 통해 아이디어와 구현 사이의 직접적인 연결 고리를 확인할 수 있었습니다. 많은 경우, 명세와 코드가 단일 업데이트에서 함께 변경되었으며, 이는 청사진이 실시간으로 작업을 주도하는 데 사용되고 있음을 확인시켜 주었습니다. 그러나 연구진은 이것이 유일한 방식은 아니라는 점에도 주목했습니다. 때로는 계획이 먼저 작성되고 코드가 나중에 나오기도 하며, 반대로 코드가 먼저 작성된 후 계획이 추가되기도 합니다. 데이터에 따르면 동시 변경이 흔하게 나타나기는 하지만, 그 관계는 복합적이며 프로젝트마다 다르게 나타납니다.

단순히 파일의 수를 세는 것을 넘어, 팀은 이 문서들의 구조를 분석하여 그것들이 실제로 어떤 모습인지 조사했습니다. 그들은 명세가 단순히 무작위적인 메모가 아니라, 인간과 기계 모두가 읽기 쉽도록 명확한 헤딩, 리스트 또는 구조화된 형식을 사용하는 등 특정한 패턴을 따르는 경우가 많다는 것을 발견했습니다. 또한 연구진은 이 문서들 내의 참조(reference)를 추적하는 시스템을 구축했습니다. 만약 명세가 특정 파일이나 수행해야 할 과업을 언급한다면, 시스템은 해당 파일이 실제로 프로젝트에 존재하는지, 혹은 그 과업이 실제로 완료되었는지 확인합니다. 이를 통해 일부 프로젝트에서 발생하는 상당한 격차를 발견했습니다. 수천 개의 명세가 실제 코드에 등장하지 않은 파일이나 과업을 언급하고 있었습니다. 이는 명세를 작성하는 관행은 성장하고 있지만, 해당 명세가 완전히 실현되도록 보장하는 규율은 여전히 진화하는 과정에 있음을 시사합니다.

이 컬렉션은 누가 글을 쓰고 있는지에 대한 창을 제공하기도 합니다. 데이터에 모든 변경 이력이 포함되어 있기 때문에, 연구진은 명세가 인간에 의해 작성되었는지, AI에 의해 생성되었는지, 혹은 둘의 혼합인지 확인할 수 있습니다. 또한 이 문서들이 얼마나 자주 업데이트되는지, 그리고 얼마나 오랫동안 활성 상태를 유지하다가 폐기되는지도 추적할 수 있습니다 잘 작성된 명세가 최종 코드의 오류를 줄이는지, 혹은 특정 유형의 프로젝트가 이 새로운 작업 방식을 채택할 가능성이 더 높은지와 같은, 이전에는 불가능했던 질문들에 답할 수 있게 된 것입니다. 데이터는 이 관행이 빠르게 확산되고 있음을 보여주며, 이 파일들의 대다수가 지난 2년 사이에 등장했다는 점은 소프트웨어 개발의 뚜렷한 새로운 시대가 열렸음을 나타냅니다.

연구진은 이 전체 데이터셋을 누구나 아이디어와 코드 사이의 연결 고리를 탐색할 수 있도록 정리하여 공개했습니다. 그들은 기여자나 프로젝트의 신원을 숨기지 않고(모든 자료가 공개 출처에서 왔으므로), 명세의 원문 텍스트, 프로젝트의 이력, 그리고 둘 사이의 연결 고리를 모두 제공했습니다. 이러한 투명성 덕분에 다른 과학자들은 연구 결과를 검증하고, 새로운 질문을 던지며, 이 관행이 시간이 흐름에 따라 어떻게 변하는지 연구할 수 있습니다. 이 작업은 이 새로운 방법이 완벽하다거나 소프트웨어 개발의 모든 문제를 해결했다고 주장하는 것이 아닙니다. 대신, 이 연구는 이전에 미개척지였던 영역에 대한 첫 번째 견고한 증거 기반이자 대규모 지도 역할을 합니다. 이는 명세를 작성하는 도구들이 갖춰져 있고 작업량도 증가하고 있지만, 인간과 기계가 협력하여 그 단어들을 소프트웨어로 바꾸는 방식은 여전히 한 프로젝트씩 풀어나가고 있는 과정에 있음을 보여줍니다.