헤더만으로 표를 읽는 법, 설명 가능한 39개 타입과 품질 점수까지

An Explainable Header-Centric Framework for Large-Scale Semantic Table Interpretation and Data Quality Assessment는 arXiv 2610.10541 번호로 공개된 표 해석 연구입니다. 제목 아래에 걸어둔 링크에서 원문의 전체 설계와 실험을 확인할 수 있습니다.

이 연구가 내세우는 주장은 셀이 비어 있거나 시끄럽거나 쓰기에 꺼려질 때조차 컬럼 헤더만으로 의미를 판별하고, 그 판별에 타입별 검사를 붙여 데이터셋 수준 품질 점수까지 이어 가겠다는 것입니다. 그래서 이번 글에서는 그 판단이 어떻게 만들어지고 어디까지 믿을 수 있는지 차례로 따라가겠습니다.

헤더만으로 표를 읽겠다는 발상이 왜 낯설게 느껴졌을까

처음 이 발상을 접하면 어색함이 남습니다. 표라면 당연히 셀을 봐야 한다는 생각을 오래 갖고 있었기 때문입니다. 그런데 막상 실무에서 표를 모아보면 셀이 없는 경우가 자주 생깁니다. 접근 권한 때문에 값을 가리거나 크롤링이 깨져 값이 비기도 하고, 개인정보라서 값을 볼 수 없을 때도 있습니다. 이럴 때 파이프라인은 보통 멈춥니다. 값이 없으면 타입도 모르고 품질도 모른다는 전제가 깔려 있습니다.

제가 이 논문에서 가장 흥미롭게 본 부분은 바로 그 전제를 뒤집은 대목입니다. 헤더에도 사람이 남긴 의도가 들어 있으니 그 의도만으로 일차 판별을 끝내보자는 제안입니다. 물론 헤더는 짧고 줄임말이 많으며 팀마다 쓰는 말도 달라서 곧바로 이런 물음이 생깁니다. 그렇다면 짧은 헤더만으로 어떻게 믿을 만한 판별을 만들 수 있을까요. 오늘은 그 물음에 대한 답을 설계와 실험으로 풀어보겠습니다.

셀이 없을 때 남는 것은 무엇일까

셀이 사라지면 보통 두 가지가 함께 사라집니다. 하나는 값의 분포이고 다른 하나는 값에서 읽히는 문맥입니다. 숫자인지 날짜인지, 이메일인지 주소인지, 사람 이름인지 회사 이름인지 같은 판단은 대개 셀 몇 개만 봐도 금방 끝나지만, 셀이 없을 때 판단 근거는 헤더 문자열 하나로 줄어듭니다. 어느 날 아침에 외부에서 받은 CSV 300개를 열었는데 값은 마스킹되어 있고 cust_nm, ord_dt, amt 같은 줄임말만 가득하다고 해보겠습니다. 사람은 감으로 때려 맞히지만 기계는 근거 없이 찍게 됩니다.

연구진이 출발한 지점도 여기와 비슷합니다. 지식 그래프 품질은 그래프를 다듬는 단계에서만 정해지는 것이 아니라 그래프에 넣기 전 표 메타데이터 단계에서 이미 흔들린다고 보는 것입니다. 그래서 셀이 비어 있거나 시끄럽거나 쓰기에 적절하지 않을 때, 헤더는 버려지는 찌꺼기로 남지 않고 추적 가능한 준비 증거가 됩니다. 저는 이 문제 설정이 마음에 들었습니다. 정확도를 올리겠다는 말보다 쓸 수 없는 상황에서 무엇을 할 것인가를 먼저 물었으니까요. 그렇다면 다음으로 궁금해지는 것은 헤더라는 짧은 문자열을 어떻게 다룰 것인가입니다.

서른아홉 개 상자로 나누면 무엇이 달라질까

이 연구는 헤더를 39개 FinalFormat 타입으로 정리합니다. 날짜와 시간, 사람과 조직, 위치와 주소, 금액과 수량, 식별자와 코드, 연락처와 웹 주소처럼 실무에서 자주 부딪히는 범주를 미리 정해둔 셈입니다. 39라는 숫자는 많아 보이기도 하고 적어 보이기도 합니다. 너무 적으면 서로 다른 의미가 한 상자에 뒤섞이고 너무 많으면 헤더 몇 글자로는 도저히 가를 수 없습니다. 연구진이 고른 개수는 그 사이 어딘가에서 설명 가능성과 실용성을 맞추려는 선택으로 읽혔습니다.

여기서 제가 멈칫했던 대목은 타입을 미리 고정했다는 점입니다. 요즘 흔한 방식이라면 모델에게 자유롭게 라벨을 뽑게 하거나 온톨로지 전체를 뒤지게 할 텐데 이 연구는 반대로 갑니다. 대신 사람이 읽고 고칠 수 있는 어휘 자원을 깔고 그 위에서 타입을 고릅니다. 이렇게 두면 나중에 왜 이 타입이 나왔는지 물을 때 답할 말이 생깁니다. 어떤 토큰이 어떤 근거 단어로 연결됐는지 남기니까요. 그렇다면 그 연결은 실제로 어떻게 만들어질까요.

이 방법은 거대 언어모델 분류기와 어떻게 다를까

겉으로 보면 헤더 분류는 언어모델에게 맡기면 끝날 일처럼 보입니다. 짧은 문자열을 던지고 타입을 받아오면 됩니다. 하지만 그렇게 하면 두 가지가 불편해집니다. 하나는 이유를 묻기 어렵다는 점이고 다른 하나는 대규모 표 묶음에서 비용과 재현성이 흔들린다는 점입니다. 프롬프트가 조금만 바뀌어도 답이 달라지고, 같은 헤더인데 어제는 A, 오늘은 B가 나오면 운영에서는 곤란합니다.

이 연구가 고른 길은 정반대에 가깝습니다. 선별해서 다듬은 어휘 자원을 쓰고 토큰 단위 추적을 남기며 규칙으로 검사를 잇습니다. 저는 이 숫자보다 그 뒤의 구조가 더 중요하다고 봅니다. 모델이 똑똑해질수록 이런 규칙 기반 설계는 구식으로 보일 수 있지만 감사나 데이터 거버넌스처럼 이유를 남겨야 하는 자리에서는 오히려 설득력이 생깁니다. 생각해보면 사람도 비슷하게 배웁니다. 처음에는 감으로 맞히지만 남을 설득하려면 근거 단어를 짚어야 하니까요. 일종의 오답 노트처럼요. 그렇다면 이제 진짜 흐름을 따라가 볼 차례입니다. 헤더 한 줄은 어떤 단계를 거쳐 타입 하나가 될까요.

헤더 한 줄이 타입 하나로 바뀌는 과정

흐름을 단순하게 옮기면 세 단계입니다. 먼저 헤더를 토큰으로 나누고 다음으로 토큰을 다듬어둔 어휘 자원과 맞추며 마지막으로 모인 근거를 묶어 39개 중 하나를 고릅니다. 이때 SourceKeywords라는 형태로 어떤 토큰이 판단에 쓰였는지 남깁니다. 이 흔적이 있기에 나중에 누군가 왜 cust가 고객으로 읽혔는지, 왜 ord_dt가 주문 날짜 쪽으로 갔는지 되짚을 수 있습니다.

여기서 실무적인 재미가 생깁니다. 헤더에는 오타와 줄임말과 팀 은어가 섞여 있습니다. amount가 amt로 줄고, customer가 cust나 cstmr로 찌그러지며, date가 dt나 dte로 바뀌지만 사람이야 문맥으로 메우는 반면 기계는 규칙이 없으면 놓칩니다. 그래서 어휘 자원을 미리 다듬는 일이 생각보다 결정적입니다. 동의어와 변형을 얼마나 품고 있느냐가 재현율을 가르는 반면 너무 넓게 품으면 오탐이 늘어납니다.

저는 여기서 조금 의심했습니다. 좋은 어휘집 하나면 다 풀린다는 말처럼 들릴 수도 있었기 때문입니다. 그러나 연구진의 설명을 따라가면 어휘집은 시작일 뿐이고 진짜 몸통은 그다음에 있습니다. 타입이 정해지는 순간 검사 규칙이 함께 켜집니다. 그렇다면 타입과 검사는 어떻게 맞물려 있을까요.

타입이 정해지면 검사가 따라오는 구조

이 설계에서 타입 판별은 끝이 아니라 방아쇠입니다. FinalFormat 타입 하나가 정해지면 그 타입에 맞는 검증 규칙이 활성화되고 정해진 품질 문제 분류에 따라 검사가 돕니다. 빈 값과 중복, 허용 범위를 벗어난 값, 잘못된 데이터 형태, 시간대나 순서가 어긋난 경우처럼 데이터 현장에서 자주 보는 문제들이 그 대상입니다.

예를 들어 컬럼이 날짜 타입으로 판별됐는데 값이 비어 있거나 형식이 제각각이라면, 그건 단순한 표기 차이로 넘기지 않고 시간 불일치나 형태 오류로 기록됩니다. 금액 타입인데 문자가 섞여 있으면 형태 문제로 잡히고, 식별자 타입인데 중복이 많으면 중복 문제로 남습니다. 이렇게 타입과 검사를 묶으면 좋은 점이 생깁니다. 검사 결과가 왜 나왔는지 타입 판별 흔적까지 거슬러 올라갈 수 있습니다.

저희가 새로운 AI 아키텍처를 볼 때도 숫자만 보지는 않습니다. 실제로 무엇이 바뀌었고, 그 변화가 운영에서 어떤 점검으로 이어지는지를 함께 봅니다. 그런 눈으로 보면 이 구조는 꽤 단단합니다. 타입을 붙이는 일과 품질을 재는 일이 따로 놀지 않고 한 줄기로 이어집니다. 그렇다면 개별 컬럼 검사는 데이터셋 전체 이야기로 어떻게 모일까요.

점수 하나로 데이터셋을 재는 감각

연구진은 컬럼별 검출 결과를 HeadersIQ라는 가벼운 데이터셋 수준 지표로 모읍니다. 가중치를 두지 않은 단순한 합산에 가깝고 지식 그래프에 넣기 전 준비 상태를 재는 용도로 설계됐습니다. 무겁지 않다는 대목에서 실용성이 갈립니다. 매번 전체 값을 훑거나 큰 모델을 돌리지 않고도 헤더 판별과 규칙 검사만으로 대략의 준비도를 볼 수 있습니다.

이 감각은 창고에 들어온 박스를 여는 일에 비유할 수 있습니다. 박스를 다 뜯지 않고 겉 라벨만 보고 어디에 쌓을지 정하는 것과 비슷합니다. 라벨이 또렷하고 규칙에 맞으면 그래프 적재 라인으로 보내고, 라벨이 흐릿하거나 검사에서 자꾸 걸리면 따로 모아 사람이 보게 됩니다. 밤사이 외부 데이터가 수백 개씩 들어오는 팀이라면 이런 일차 선별이 하루를 아껴줍니다.

여기서는 조금 조심해서 읽을 필요가 있습니다. 가중치를 두지 않았다는 말은 모든 문제를 똑같이 센다는 뜻이지만 현장에서는 문제의 무게가 다릅니다. 날짜 하나 어긋난 것과 식별자 전체가 비어 있는 일은 파급력이 다르니까요. 연구진도 이 지표를 무거운 최종 판정으로 내놓지 않고 준비 상태 모니터링용으로 자리매김합니다. 저는 그 절제가 오히려 믿음직했습니다. 점수 하나로 모든 걸 말하겠다는 욕심을 부리지 않았기 때문입니다. 그렇다면 이 점수와 판별은 얼마나 넓게 시험됐을까요.

십이만 개 헤더에서 무엇을 확인했을까

실험 규모는 작은 편이 아닙니다. UCI와 Prague, Kaggle, VizNet과 Sato 계열, SOTAB, T2Dv2, 그리고 SemTab 2024 Metadata-to-KG까지 서로 결이 다른 묶음을 합쳐 약 12만 개 헤더 컬럼을 다뤘습니다. 공개 표와 웹 표와 벤치마크용 표가 섞여 있으니 헤더 스타일도 제각각입니다. 줄임말이 많은 실무형부터 잘 정돈된 대회용까지 한데 들어 있죠.

이런 섞음은 일부러 고른 것처럼 보입니다. 헤더만 보는 방법은 깨끗한 곳에서만 통하면 쓸모가 없습니다. 지저분한 현실에서도 흔들리지 않아야 현장에서 쓸 수 있으니까요. 병렬로 마련된 지식 그래프 매핑 경로는 판별된 헤더 타입을 DBpedia와 Schema.org 쪽 개념과 맞추는 일을 맡습니다. 타입 판별을 그래프 적재로 잇는 다리인 셈이죠.

결과를 읽을 때는 두 줄기를 나눠야 합니다. 하나는 여러 묶음에서 헤더 판별과 품질 검사가 대체로 돌아갔다는 줄기이고 다른 하나는 SemTab 2024 Metadata-to-KG의 엄격한 정답 일치 평가에서는 점수가 modest하게 나왔다는 줄기입니다. 후자만 보면 실패처럼 보일 수 있습니다. 하지만 여기서 잠깐 멈추고 평가 조건을 봐야 합니다. 점수가 낮다는 말과 방법이 틀렸다는 말은 같은 말이 아닙니다. 그렇다면 그 낮은 점수는 무엇을 뜻할까요.

점수가 낮게 나왔는데도 변호할 거리가 남는 이유

SemTab 쪽 엄격한 평가가 낮게 나온 뒤 연구진은 가림 처리된 진단 감사를 덧붙입니다. 정답과 어긋난 경우를 모아 왜 어긋났는지 뜯어보기 위해서입니다. 그리고 그 어긋남 상당수가 방법의 오판이라기보다 평가 기준의 결 때문이라고 정리합니다. 기준이 묻는 정밀도가 더 잘거나 같은 개념을 다른 이름으로 부르거나 온톨로지 선택에 따라 답이 갈리는 경우가 많았습니다.

이 대목은 길게 생각해볼 만합니다. 예를 들어 사람을 뜻하는 헤더 하나를 두고 한쪽은 더 구체적인 하위 개념을 정답으로 두고 다른 쪽은 흔한 상위 개념을 고르면 엄격한 일치로는 틀림이 됩니다. 별칭도 비슷해서, 같은 뜻인데 쓰는 말이 다르면 맞히기 어렵고, DBpedia와 Schema.org처럼 서로 다른 온톨로지를 고르는 순간 답이 달라지는 일도 생깁니다. 이런 어긋남을 모두 방법의 실패로 묶으면 평가가 방법을 앞서가는 셈입니다.

연구진은 이 감사를 두고 성능을 고쳐 쓴 것이라고 말하지 않습니다. 불일치 양상을 보여주는 진단 근거라고 선을 긋습니다. 저는 그 태도가 합리적이라고 봅니다. 낮은 점수를 감추지 않으면서도 낮은 점수가 어디에서 왔는지 따로 보여줬기 때문입니다. (참고로 이런 사후 감사는 점수를 올려치기보다 다음에 기준을 어떻게 손봐야 할지 찾는 과정에 가깝습니다.) 그렇다면 실무자의 눈에는 무엇이 남을까요.

그래서 실무에서는 무엇을 들고 가면 될까

실제 시스템 관점에서 보면 다음 질문이 바로 생깁니다. 셀이 없을 때 이 방법을 어디에 두면 좋을까요. 제 답은 입구 쪽입니다. 그래프에 넣기 전 선별과 분류와 우선순위 매기기에 두는 것입니다. 값이 없을 때는 헤더 판별로 타입을 붙이고, 타입별 검사로 위험 신호를 모으며, HeadersIQ 같은 가벼운 점수로 어디부터 볼지 정합니다. 값이 나중에 들어오면 그때 값 기반 검사로 넘기면 됩니다.

이렇게 두면 좋은 점이 또 있습니다. 설명 흔적이 남기에 나중에 다툴 수 있습니다. 왜 이 컬럼이 날짜로 읽혔는지, 어떤 토큰이 근거였는지, 어떤 규칙이 켜졌는지 감사 추적이 가능합니다. 권한 때문에 값을 못 보는 조직이나 외부 데이터를 대량으로 받는 팀에서는 이 흔적이 생각보다 요긴합니다. 문제가 생겼을 때 모델의 감이 아니라 남겨진 근거를 놓고 고칠 수 있습니다.

물론 아쉬운 자리도 분명합니다. 가중치 없는 합산은 현장의 무게를 못 담고 줄임말과 신조어가 많은 조직에서는 어휘 자원을 계속 손봐야 하며 온톨로지 선택이 바뀌면 매핑 결과가 함께 흔들립니다. 제가 앞으로 보고 싶은 것은 그래서 세 가지입니다. 어휘 자원을 얼마나 적은 손으로 최신 상태로 둘 수 있는지, 무게를 달리 둔 점수가 현장 우선순위와 얼마나 맞는지, 그리고 엄격한 일치 너머의 평가를 어떻게 만들지입니다. 그렇다면 사람의 역할은 무엇일까요. 아마도 헤더에 남겨진 의도를 읽어내고, 그 의도가 기계의 손을 거쳐 그래프로 갈 때까지 책임지는 일이겠죠. 그 사이를 잇는 설명 가능한 다리 하나, 이번 연구는 그 다리를 꽤 성실하게 쌓아 올렸습니다.