공개 데이터를 내려받아 표로 읽었다고 분석 준비가 끝나는 것은 아니다. 한 행이 무엇을 뜻하는지, 값의 단위와 집계 순서는 무엇인지, 예측 시점에 쓸 수 있던 정보인지가 맞아야 한다. Project ProtoStar의 첫 기후 과제는 이 조건들이 실제로 어디서 어긋나는지 살펴볼 수 있는 사례다.
ProtoStar가 바꾸려는 연구의 전달 방식
Hugging Face와 대학·연구기관 등이 2026년 10월 29일 발표한 Project ProtoStar는 공공 연구의 데이터·모델·코드를 다른 연구와 AI 작업에서 발견하고 재사용하기 쉽게 만들려는 협력이다. 첫 과제는 CMU의 Climate Risk Intelligence로, 11월 2일 시작하는 프로그램으로 소개됐다. 핵심은 새 기후 모델 하나의 출시보다 연구 산출물을 다음 사람이 이어 쓸 수 있는 형태로 전달하는 일에 있다. 공식 발표
기업에서도 비슷한 문제가 생긴다. 이전 팀이 남긴 수요 예측 표를 받았는데 날짜가 관측일인지 보고일인지 알 수 없거나, 매출 단위가 원과 천 원으로 섞여 있을 수 있다. 파일을 여는 코드는 정상 동작해도 결과의 의미는 틀어진다. AI가 이 표를 자동으로 찾아 결합할수록 빠진 설명을 그럴듯하게 메우기 쉽다.
이 글은 11월 3일 확인한 공개 문서와 저장소의 분석이다. CMU 데이터 전체를 내려받아 모델을 학습하거나 대회에 제출하지 않았다. 아래 작은 숫자 예제는 직접 만든 가상 자료다. 독자가 가져갈 결과는 데이터를 받아서 첫 분석에 넘길 때 확인할 조건과 재사용 명세다.
발표문과 실제 제출 규격부터 다르다
조사에서 가장 먼저 걸린 것은 모델 선택이 아니라 예측 기간이었다. 발표문과 현재 과제 문서가 같은 연도를 말하지 않는다.
| 확인한 원자료 | 예측·평가 기간 설명 | 이 글에서의 사용 |
|---|---|---|
| 10월 29일 ProtoStar 발표 | 2019년부터 2026년까지, 완전한 2026년 기록 이후 최종 결과 공개 | 사업 소개와 초기 설명 |
CMU 과제 문서, 커밋 7cbdda8 |
예측은 2019년부터 2025년까지. Live는 2019–2021, Final은 2022–2025 | 현재 과제의 평가 설명 |
제출 템플릿, 커밋 9277170 |
210개 도시 × 7개 연도 × 4개 지표 = 5,880행 | 제출 파일이 요구하는 범위 |
어느 문서가 왜 바뀌었는지까지 확인한 것은 아니다. 따라서 두 설명을 합쳐서 “2026년까지 제출한다”고 쓰지 않는다. 현재 파일 준비에는 서로 일치하는 과제 문서와 템플릿의 2025년 범위를 기준으로 삼고, 실제 참여 전에는 과제 페이지의 최신 안내를 다시 확인해야 한다. 확인한 과제 문서에는 리더보드도 아직 열리지 않았다고 적혀 있다. 이미 AI가 기준선을 이겼다는 결과 발표로 읽을 수 없다.
이 차이는 연구 자료를 재사용할 때 흔히 빠지는 조건을 보여 준다. 논문이나 소개 글의 목적 설명, 데이터 파일의 실제 범위, 평가기의 입력 규격을 따로 대조해야 한다. 원자료 URL만 기록하면 나중에 바뀐 내용을 같은 버전으로 착각할 수 있다. URL·커밋·확인일·적용한 규칙을 묶어 남기면 동료가 그때의 판단을 복원할 수 있다.
파일이 읽히는 것과 올바르게 결합되는 것은 다르다
CMU의 학습 데이터 카드는 일별 daily, 연별 annual_indices, 관측소 이력 city_info를 구분한다. 특히 city_info는 도시마다 한 행인 표가 아니다. 여러 관측소의 기록을 이어 붙인 이력을 담아 같은 도시가 여러 행을 가질 수 있다. 데이터 카드는 210개 도시와 이력 표 461행을 함께 명시한다. 데이터 카드, 커밋 43e98eb
다음은 그 관계를 설명하려고 만든 가상 도시 A다. 실제 CMU 행을 추출한 것이 아니다.
- 일별 표: A의 2018년 1월 1일 강수량 1인치, 1월 2일 2인치.
- 이력 표: A의 옛 관측소 구간 1900–1999, 새 관측소 구간 2000–2018.
- 질문: 이틀 동안 A의 강수량 합계는 얼마인가?
도시 ID만으로 두 표를 결합하면 일별 각 행에 관측소 이력 두 행이 붙는다. 일별 2행이 결합 후 4행이 되고, 그대로 합계하면 1 + 1 + 2 + 2 = 6인치다. 원래 합계는 1 + 2 = 3인치다. 파일 읽기와 결합 명령은 성공했지만 같은 관측을 두 번 센 것이다.
이 사례에서는 관측 날짜가 속한 이력 구간을 함께 조건으로 쓰면 새 관측소 한 행만 대응해 2행과 3인치가 유지된다. 단, 날짜 구간이 겹치거나 비어 있다면 다시 중복·누락이 생길 수 있다. 이것은 자체 가상 결합의 계산 결과이며 실제 데이터에 이런 오류가 있다는 주장은 아니다.
연별 집계에는 다른 선택이 필요할 수 있다. 한 해 중간에 관측소가 바뀌었다면 연도 하나에 이력 한 행을 억지로 붙여서는 안 된다. 도시별 유일한 기본 정보와 관측소 이력을 별도로 보관하거나, 일별 단계에서 날짜 관계를 정리한 후 연별로 집계한다. 어떤 방식을 택하든 결합 전후의 행 수와 합계를 비교해야 한다.
| 받는 사람이 정할 것 | 남길 검사 | 실패했을 때의 다음 행동 |
|---|---|---|
| 한 행의 단위 | 일별 표의 도시 ID·날짜 중복 여부 | 중복의 의미를 확인한 뒤 집계 규칙 결정 |
| 표 사이 관계 | 도시당 이력 개수와 유효 기간 | 무조건 중복 제거하지 말고 이력 표 분리 |
| 결합 후 보존할 양 | 날짜별 행 수, 누락 수, 강수량 합계 | 늘거나 사라진 관측의 키를 찾아 대조 |
city_info라는 이름만 보고 도시 목록으로 취급하면 이 관계가 사라진다. AI가 만든 코드의 검토 기준도 문법보다 “어떤 한 행이 몇 번 쓰였는가”에 두는 편이 유용하다.
단위를 알아도 집계 순서를 틀릴 수 있다
과제의 냉방도일(CDD)은 일 최고·최저기온의 평균이 65°F를 넘는 양을 날짜별로 구해 더한다. 데이터 카드의 단위는 °F-days이며, 최고·최저 값이 모두 있는 날짜를 사용한다. 결측일이 많은 해의 합계가 낮아질 수 있다는 한계도 적혀 있다. CDD 정의와 결측 조건
하루 기여 = max(0, (하루 최고기온 + 하루 최저기온) / 2 − 65)
기간 CDD = 그 기간의 하루 기여를 모두 더한 값
가상으로 첫날 최고·최저가 70°F와 50°F, 둘째 날이 90°F와 70°F라고 하자. 하루 평균은 각각 60°F와 80°F다. 첫날은 기준보다 낮아 0, 둘째 날은 15이므로 이틀 CDD는 15°F-days다.
그런데 두 날의 평균기온 70°F부터 계산한 뒤 (70 − 65) × 2를 하면 10이 나온다. 추운 날의 음수 기여를 0으로 바꾸는 연산이 평균을 내기 전과 후에 서로 다른 결과를 만들기 때문이다. 이는 모델 정확도 문제가 아니라 같은 원자료로 서로 다른 목표값을 만든 문제다.
직접 그린 가상 계산 설명도. 실제 기상 관측이나 ProtoStar 모델 성능이 아니다. 일별 계산과 기간 평균의 순서를 비교한다.
비교용으로 두 날 모두 80°F라고 놓으면 두 방법 모두 30이 나온다. 일부 입력에서 값이 같다는 이유로 계산법이 같다고 판단하면 안 되는 이유다. 기준 아래와 위가 섞인 날짜, 결측일, 윤년처럼 정의의 차이가 드러나는 입력을 골라 확인해야 한다.
냉방도일은 여기서 정의한 기온 지표다. 이를 곧바로 건물의 전기 사용량으로 바꾸려면 면적·설비 효율·운영시간 등 별도 관계가 필요하다. 예측 대상이 CDD인데 보고서 제목을 “내년 전기요금 예측”으로 바꾸면 데이터가 답하지 않은 질문까지 넓히게 된다.
예측 입력과 사후 분석에 같은 자료를 써도 될까
CMU의 세부 데이터 안내는 2018년 말까지의 기상 기록을 예측에 쓰도록 하고, 이후 날씨에 반응한 자료를 입력에서 제외한다. 전력 수요나 하천 유량처럼 날씨의 결과를 간접적으로 드러내는 값도 해당한다. 반면 사후 정책 분석에는 그 자료를 사용할 수 있다고 구분한다. 과제의 데이터 규칙과 FAQ
예를 들어 2023년의 냉방도일을 예측하면서 같은 해 실제 전력 사용량을 입력하면, 이미 더웠던 정도가 결과에 스며들 수 있다. 기온 열만 지웠다고 미래 정보를 제거한 것이 아니다. 반대로 예측을 마친 뒤 취약 지역의 지원 정책을 논의하는 데 전력 사용량을 대조하는 것은 다른 분석이다. 자료 이름보다 어디에 투입했는지를 남겨야 한다.
여기에는 한 단계 더 구분할 것이 있다. 이 과제의 상세 FAQ는 해당 연도 날씨에 반응하지 않는 토지피복·인구 등의 자료에 대해 연도 제한을 완화한다. 이것을 “2018년 당시 실제 이용 가능했던 데이터만으로 예측했다”는 증거로 쓸 수는 없다. 대회 규칙상 허용과 과거 시점의 실제 이용 가능성은 다른 조건이다.
업무에서 과거 의사결정을 재현하려면 아래 날짜를 나눈다. 이는 CMU가 요구한 필드가 아니라 이 글에서 제안하는 재사용 명세다.
| 날짜 | 질문 | 가상 예 |
|---|---|---|
| 관측 대상일 | 무엇이 언제 일어났는가? | 2018년 12월의 사용량 |
| 최초 이용 가능일 | 담당자가 언제 알 수 있었는가? | 2019년 1월에 공개된 월간 집계 |
| 수정본의 버전·발행일 | 나중에 값이 고쳐졌는가? | 2020년에 보정된 재공개 자료 |
| 예측 기준 시점 | 어떤 정보까지 허용하는가? | 2018년 12월 31일 마감 |
예시의 2018년 12월 값도 2019년에 처음 공개됐다면 2018년 말의 실제 의사결정 입력으로는 쓸 수 없다. 데이터에 찍힌 연도만 자르는 방법이 놓치는 부분이다. 당시 배포본을 복원할 수 없다면 “현재 수정본으로 수행한 후향 분석”이라고 범위를 적는다.
전처리에도 같은 원리가 적용된다. 평가할 기간을 포함해 결측치 대체값이나 정규화 평균을 학습하면 미래 정보가 들어갈 수 있다. scikit-learn 공식 문서는 학습·평가 분할을 먼저 하고 전처리의 학습도 학습 집합에 한정하도록 설명한다. 데이터 누출 안내
범용 사전학습 모델을 사용한다면 입력 표를 잘랐다는 사실만으로 전체 학습 이력의 정보 누출까지 배제할 수 없다. 학습 자료의 범위를 모르면 그 한계를 남긴다. 과제의 입력 규칙을 지켰다는 주장과 완전히 새로운 시점에 대한 일반화 검증을 분리해야 한다.
다음 팀이 이어 쓸 수 있는 최소 묶음
Hugging Face의 데이터 카드는 저장소 README.md를 바탕으로 표시되며, 라이선스·언어·태그 등의 메타데이터와 사용 맥락을 담는다. 이런 설명은 발견과 이해를 돕지만, 모든 결합과 계산이 올바르다는 보증은 아니다. Dataset Cards 문서
CMU 제출 안내는 예측 파일뿐 아니라 코드와 가공 데이터, 방법 설명을 함께 요구한다. 복사가 어려운 자료는 정확한 버전과 확보 방법을 적도록 한다. 제출 때 기록한 커밋을 사용하므로 파일 수정 후 다시 제출하는 절차도 구분한다. 제출 안내
이 구조를 사내 분석 인수인계에 적용한다면 다음처럼 작게 시작할 수 있다.
- 질문을 고정한다. 어떤 도시·기간·지표를 예측하는지, 결과가 지원할 결정은 무엇인지 적는다. 예측값과 정책 제안을 별도 결과물로 둔다.
- 입력의 의미를 적는다. 원자료 버전, 한 행의 단위, 결합 키와 관계, 수치 단위, 결측 처리, 사용 가능한 시점을 기록한다.
- 가장 작은 반례를 통과시킨다. 두 관측소 이력으로 행이 늘어나는지, 기준 위아래의 날짜에서 CDD가 맞는지 확인한다. 정상 파일을 읽었다는 검사만 남기지 않는다.
- 같은 조건의 비교를 남긴다. 기준 예측과 후보 모델에 동일한 입력·평가 행을 적용하고 지표별 오차를 기록한다. 평가에서 빠진 행과 이유도 함께 적는다.
- 재현 결과를 인계한다. 실행 환경·입력 해시·변환 코드·출력 해시를 연결하고, 다른 환경의 재실행은 원 실행과 구분한다. 미실행 칸은 채우지 않는다.
데이터 재사용 명세 내려받기는 위 조건을 옮겨 적을 빈 양식이다. 공식 제출 양식이나 자동 검사 도구가 아니다. 본문의 가상 예제도 이미 수행한 기후 예측으로 기록하지 않도록 계산 확인과 실제 모델 실행 칸을 나누었다.
이 글의 산술은 Python 표준 라이브러리로 확인했다. 가상 결합의 2행→4행, 3인치→6인치 변화와 날짜 조건을 붙였을 때의 복원, 이틀 CDD 15와 잘못된 집계 10, 반례의 30을 대조했다. 실제 Parquet의 전체 행·결측률·모델 성능·제출 시스템은 시험하지 않았다.
도입 판단은 더 복잡한 모델 앞에서 시작한다
이미 단위·버전·결합 관계가 정리된 자료라면 새 명세를 길게 만드는 대신 기존 데이터 계약을 연결하면 된다. 반대로 파일 수만 많고 이 조건이 비어 있다면 모델을 바꾸기 전에 작은 표 하나를 끝까지 재사용해 보는 편이 낫다. 그 과정에서 재현할 수 없는 부분을 찾는 것도 구체적인 산출물이다.
ProtoStar의 가치는 이후 과제에서 실제로 얼마나 재사용과 재현이 이루어졌는지로 평가해야 한다. 지금 확인할 수 있는 것은 공개 협력과 첫 과제의 구조다. 독자는 그 구조를 자신의 작업에 옮겨 “파일을 받았다” 다음에 남겨야 할 설명과 확인 결과를 정할 수 있다.
공간 자료를 실제 판단에 연결하는 사례는 Earth AI의 입지 분석, 입력이 정리된 다음 예측들을 결합하는 문제는 Granite 시계열 앙상블로 이어진다. 명세를 다시 쓸 때는 상단 저장 기능을, 후속 분석은 AI 시스템 모음과 RSS를 이용할 수 있다.
- AI-ready는 특정 파일 확장자 하나로 결정되지 않는다. 행의 단위·결합 관계·수치 정의·사용 시점이 함께 전달되어야 한다.
- 현재 CMU 제출 문서는 2019년부터 2025년까지를 요구한다. 2026년까지를 소개한 발표문과 차이가 있어, 실행 규격은 확인한 커밋과 함께 남겨야 한다.
- 같은 자료도 예측 입력과 사후 정책 분석에서 역할이 다르다. 허용된 자료인지와 당시 실제로 알 수 있었는지는 별도로 기록한다.
근거와 원자료
자료의 발행 시점과 이번 글에서 참고한 범위를 함께 기록합니다.
- Announcing Project ProtoStar: Making Publicly Funded Science AI-Ready ↗Hugging Face / ProtoStar partners · 2026-10-29
협력의 목적과 첫 과제 소개. 발표의2019–2026범위는 현재 제출 문서와 다름. 성능 달성 주장 아님.
- Climate Risk Intelligence — About ↗CMU-OSPO · commit 7cbdda87fc9387e44b7f14f231669a8f70a6fea6
2019–2025예측과Live/Final분리, 현재 leaderboard coming soon. 발표문과 차이의 원인은 미확인.
- Climate Risk Intelligence — Data & submission ↗CMU-OSPO · commit 7cbdda87fc9387e44b7f14f231669a8f70a6fea6
입력/분석 용도별 허용·비기상 반응 자료의연도 예외·5880행·재현자료·커밋 제출. 실제 제출 미실행.
- Training data to 2018 — Dataset card ↗CMU-OSPO · commit 43e98eb5d1a9bc65ccdb7401ffc422524b98b157
공식 카드의행 단위·단위·461이력행·CDD·결측 한계. 실제 Parquet 전수 검증 아님.
- Protostar Climate Challenge submission template ↗CMU-OSPO · commit 927717061536b7a2b6afb31555746860b3393bf3
2019–2025·210도시·7년·4지표·5880행 및 재현 명세. 로그인·등록·제출 안 함.
- Dataset Cards ↗Hugging Face · current documentation
README 및 YAML metadata의발견/맥락 기능. 사실 정확성 보증이 아님.
- Common pitfalls — Data leakage ↗scikit-learn · 1.9.1 documentation observed
예측 시점 비가용 정보·전처리 fit의학습/평가 분리. scikit-learn 실행 미실시.
갱신 기록
공식 발표·CMU 과제·데이터 카드·제출 템플릿을 고정해 분석했다. 자체 가상 결합·냉방도일 계산만 실행했으며 실제 기상 데이터 예측과 제출은 수행하지 않았다.
오류를 발견했다면 댓글로 알려 주세요 →
이 글에 댓글 남기기
댓글 공개 방식을 확인하고 있습니다. 개인정보나 비밀 값은 적지 마세요.
댓글을 불러오는 중입니다.
내 댓글 확인·수정·삭제
등록 후 안내된 댓글 번호와 비밀번호를 입력하세요. 승인 대기 중인 댓글도 확인할 수 있습니다.