2026년 1월 인공지능 기본법이 시행된 뒤로, 보유한 자료를 학습용으로 정리해 두려는 기업이 눈에 띄게 늘었습니다. 그런데 데이터 구축을 맡는 쪽에서 반복해서 마주치는 장면이 하나 있습니다. 1년 전에 적지 않은 예산을 들여 만든 데이터셋이 분명히 남아 있는데, 막상 새 모델을 학습시킬 때가 되면 아무도 그 데이터를 꺼내 쓰지 못하는 상황입니다. 라벨이 틀려서가 아닙니다. 데이터셋 명세서 작성 기준이 없었던 탓에, 그 데이터가 어떤 조건에서 만들어졌는지 설명할 수 있는 사람이 조직 안에 남아 있지 않기 때문입니다.
다시 열어 본 데이터셋에서 가장 먼저 막히는 것
데이터는 파일로 남습니다. 그런데 그 데이터를 만들 때 합의했던 조건은 파일로 남지 않습니다. 대부분 담당자의 기억과 메신저 대화 속에 흩어져 있고, 담당자가 바뀌는 순간 함께 사라집니다.
가장 흔한 사고는 규격이 갈린 데이터가 한 폴더에 섞여 있는 경우입니다. 같은 데이터셋 안에서 프레임레이트나 해상도가 다른 자료가 섞이면, 받는 쪽은 한 종류의 데이터를 받은 것이 아니라 두 종류를 받은 셈이 됩니다. 어느 파일이 어느 규격인지 적혀 있지 않으면, 그 데이터셋은 전부 다시 검수해야 쓸 수 있습니다.
클래스 정의가 적혀 있지 않은 경우도 마찬가지입니다. 산업 현장 데이터에서 「샌다」는 말은 한 가지 사건이 아닙니다. 설비에서 기름이 배어 나와 바닥에 고이는 상태와, 배관에서 물이 뿜어져 나오는 상태는 탐지해야 할 대상도 다르고 모델이 배워야 할 단서도 다릅니다. 두 장면을 같은 이름으로 묶어 둔 데이터셋은 나중에 어느 쪽을 학습시키려 해도 쓰기 어렵습니다.
이런 일이 겹치면 결국 역전이 일어납니다. 가지고 있는 데이터를 다시 쓰는 비용이, 처음부터 새로 수집하는 비용보다 비싸집니다. 데이터 자산이라고 불러 왔던 것이 실제로는 자산 목록에 올라가지 못하는 이유가 여기에 있습니다.
공교롭게도 이 문제는 구축 단계에서는 거의 드러나지 않습니다. 납품 직후에는 담당자가 모든 조건을 기억하고 있기 때문입니다. 데이터셋 명세서 작성 기준이 필요한 이유는 지금 기억하고 있는 사람을 위해서가 아니라, 1년 뒤에 그 파일을 처음 열어 볼 사람을 위해서입니다.
데이터의 수명은 라벨 정확도가 아니라 설명서가 결정합니다
데이터 품질을 이야기할 때 대부분의 논의는 라벨이 얼마나 정확한가에 머무릅니다. 그런데 실무에서 데이터셋의 수명을 끊어 놓는 것은 부정확한 라벨이 아니라, 정확하지만 조건을 알 수 없는 라벨입니다.
데이터 품질 모델의 국제 표준인 ISO/IEC 25012는 데이터 품질을 데이터 자체에 내재한 관점과 시스템에 의존하는 관점으로 나누어 봅니다. 데이터의 값이 맞는지와, 그 데이터가 쓰이려는 환경에서 제 역할을 하는지는 다른 문제라는 뜻입니다. 후자는 데이터만 들여다봐서는 판정할 수 없고, 그 데이터가 어떤 전제 위에서 만들어졌는지를 함께 읽어야 판정됩니다.
같은 문제의식에서 나온 제안이 Datasheets for Datasets입니다. 부품에 규격표가 따라붙듯 데이터셋에도 제작 동기, 구성, 수집 과정, 권장 용도와 권장하지 않는 용도를 적은 문서를 붙이자는 내용입니다. 전자부품을 규격표 없이 납품받는 일은 상상하기 어려운데, 데이터는 지금도 상당 부분 그렇게 오가고 있습니다.
정리하면 이렇습니다. 데이터셋에서 사라지는 것은 데이터가 아니라 맥락이고, 명세서는 그 맥락을 파일 옆에 붙잡아 두는 유일한 장치입니다. 그래서 데이터셋 명세서 작성 기준은 문서 서식의 문제가 아니라 데이터 설계의 문제에 가깝습니다. 어떤 항목을 적을지 정하는 순간, 그 항목을 측정하고 통일해야 한다는 제약이 작업 전체에 걸리기 때문입니다.
데이터셋 명세서 작성 기준에서 반드시 적는 3가지
저희가 산업 현장 영상 데이터를 만들고 납품하면서 명세서 항목을 여러 번 고쳐 왔습니다. 처음에는 항목을 늘리는 방향으로 갔다가, 지키지 못할 항목이 늘어날수록 문서가 쓸모없어진다는 것을 겪고 다시 줄였습니다. 지금 남은 것은 세 가지입니다.
어떤 조건에서 만들어졌는지를 규격으로 적습니다
첫 번째는 제작 조건입니다. 여기서 기준은 「잘 만들었는가」가 아니라 「운용 환경과 일치하는가」입니다.
영상 데이터라면 카메라가 고정되어 있었는지, 화각이 어느 정도로 비스듬했는지, 프레임레이트와 해상도가 얼마였는지가 모두 규격입니다. 실제 감시 카메라는 공간 모서리에 달려 비스듬히 가로질러 보는 경우가 많은데, 정면을 마주 보는 구도로 만든 데이터는 아무리 선명해도 그 현장의 데이터가 아닙니다. 중요한 것은 이 규격을 데이터셋 전체에 똑같이 적용하고, 그 값을 문서에 적어 두는 일입니다.
조건을 기록하는 순서는 단순합니다. 수집·생성 조건 합의 → 규격 확정 → 전량 동일 적용 → 명세서 기재. 이 순서가 뒤집혀 납품 직전에 기억을 더듬어 적기 시작하면, 그때부터는 사실이 아니라 추정이 문서에 들어갑니다.
무엇을 넣지 않았는지를 함께 적습니다
두 번째는 데이터셋의 공백입니다. 명세서에서 가장 자주 빠지면서 나중에 가장 큰 문제를 만드는 항목입니다.
- 어떤 장면을 의도적으로 제외했는지 (판정이 갈리는 경계 사례를 뺐다면 그 기준)
- 어떤 조건을 아예 담지 않았는지 (야간, 우천, 특정 설비 상태 등)
- 정상 장면을 어떤 비율로 넣었는지
세 번째 항목은 특히 중요합니다. 위험 장면만 모아 둔 데이터셋으로 학습하면 모델은 「사람이 보이면 위험」에 가까운 판단을 배울 수 있습니다. 크레인 하부 통행을 탐지하려면 하부를 지나가지 않는 정상 통행도 같은 화각에서 필요하고, 누수를 탐지하려면 누수가 없는 정상 배관도 필요합니다. 이 비율은 고객이 먼저 요청하는 경우가 드물기 때문에, 만드는 쪽에서 먼저 제안하고 그 결과를 명세서에 남겨야 합니다.
클래스 경계도 이 자리에 적습니다. 앞에서 말한 기름과 물처럼, 사람 눈에는 비슷해 보이지만 거동이 다른 두 사건은 문장으로 정의를 갈라 놓아야 다음 사람이 같은 기준으로 데이터를 늘릴 수 있습니다.
어디까지 보증하는지를 수치로 적습니다
세 번째는 검수 범위입니다. 전수를 보았는지 표본을 보았는지, 표본이라면 몇 퍼센트를 어떤 방식으로 뽑았는지를 적습니다. 검수를 어떻게 설계하는지는 라벨링 품질 검수 기준, 전수검수를 버리고 얻은 3단계 핵심 설계에서 따로 다룬 적이 있습니다.
여기서 한 가지 원칙이 더 붙습니다. 판단이 갈리는 항목은 전부 수치로 바꿔서 봅니다. 카메라가 아주 느리게 밀려 들어가는 움직임이나 동작 속도의 미세한 차이는 재생해서는 잘 보이지 않지만, 프레임 단위로 측정하면 바로 드러납니다. 눈으로 보고 괜찮다고 넘긴 자료가 측정에서 걸린 적도 있고, 어색해 보였는데 측정상 문제가 없어 그대로 납품한 적도 있습니다.
감각으로 판정하면 사람마다 결론이 달라집니다. 수치 기준을 명세서에 적어 두면 재작업 여부를 두고 다툴 일이 없어지고, 무엇보다 보증하지 않는 범위가 어디인지가 분명해집니다. 명세서의 가치는 보증 범위를 넓게 쓰는 데 있지 않고, 경계를 정확히 긋는 데 있습니다.
실무자가 짚어야 할 지점
명세서를 길게 쓸수록 좋은 문서가 되는 것은 아닙니다. 오히려 지키지 못할 항목을 적어 두면, 그 문서는 품질 보증서가 아니라 분쟁 근거가 됩니다. 적을 수 있는 항목만 적고, 측정하지 않은 값은 측정하지 않았다고 적는 편이 낫습니다.
저희도 처음에는 납품 직전에 명세서를 몰아서 썼습니다. 그렇게 쓰면 기억에 의존하게 되고, 나중에 확인해 보니 실제 작업 내용과 다르게 적힌 항목이 있었습니다. 그 뒤로는 규격을 확정하는 시점에 초안을 먼저 만들고 작업하면서 갱신하는 방식으로 바꿨습니다. 착수 전에 규격을 어디까지 맞춰 두어야 하는지는 합성 영상 규격 합의, 착수 전에 맞춰야 할 4가지 핵심 항목에서 정리했습니다.
그리고 명세서는 한 번 정해 두면 끝나는 문서도 아닙니다. 같은 고객의 후속 프로젝트에서 규격이 조금씩 달라지는 일은 흔하고, 그때 앞 회차의 명세서를 그대로 복사해 쓰면 문서와 실물이 어긋납니다. 저희는 회차마다 달라진 항목을 따로 표시해 두는 쪽을 택하고 있습니다.
한 가지 더 덧붙이자면, 명세서는 데이터를 만드는 쪽만의 문서가 아닙니다. 발주하는 쪽이 착수 단계에서 「명세서에 어떤 항목이 들어갑니까」라고 묻는 것만으로, 그 프로젝트에서 합의되지 않은 채 넘어갈 뻔한 항목들이 대부분 드러납니다. 데이터 라벨링 작업을 외부에 맡기는 경우라면 이 질문 하나가 가장 저렴한 검증 수단입니다.
결론
데이터셋의 수명은 라벨 정확도가 아니라 설명 가능성이 결정합니다. 데이터셋 명세서 작성 기준을 세 가지로 압축하면 이렇습니다. 어떤 조건에서 만들었는지, 무엇을 넣지 않았는지, 어디까지 보증하는지. 이 세 가지가 파일 옆에 남아 있는 데이터셋만이 다음 프로젝트에서 다시 쓰입니다. 나머지는 보관되어 있을 뿐 자산으로 세기 어렵습니다.
정부 지원사업으로 데이터를 구축하는 경우라면 이 점이 더 분명해집니다. 데이터바우처처럼 수요기업과 공급기업이 나뉘는 구조에서는, 사업이 끝난 뒤 데이터를 실제로 운용하는 쪽이 구축 당시의 조건을 알아낼 통로가 명세서밖에 없습니다. 사업 종료가 데이터 활용의 시작이라는 점을 생각하면, 명세서는 부속 서류가 아니라 산출물의 일부에 가깝습니다.
AI 학습 데이터의 가치는 결국 다음 사람이 그 데이터를 다시 쓸 수 있는가로 판가름 납니다. 데이터 구축을 준비하고 계신다면, 가장 효율적인 데이터 구축 방법을 함께 찾겠습니다.