비영리 데이터 온보딩 얘기를 보다가 “100개 가까운 파트너가 CSV, PDF, 2~3개 업계 CRM에 비슷한 데이터를 전부 다른 모양으로 저장한다”는 문장에서 멈췄다. 한 댓글은 파트너별 데이터가 보통 2,000행 이하라 작아 보이지만, 컬럼 20개 안팎이 제각각이고 같은 컬럼명도 파트너마다 의미가 달라서 회의로 값을 맞추고 오류를 다시 돌려보낸다고 했다. HN 토론에는 Python 스크립트, DuckDB, SQLite, LLM, Visidata 같은 답이 줄줄이 달렸는데, 다들 결국 “가져오기 전 청소”가 일의 절반이라는 데는 동의하는 분위기였다. 임시 해결책은 꽤 현실적이다. 기술팀이 있는 파트너는 SQL로 템플릿을 맞추고, 내부 팀은 노트북이나 Python 스크립트를 복사해 고치고, Excel은 버전이 꼬이면 누가 언제 왜 바꿨는지 다시 추적한다. 어떤 사람은 엉망인 스프레드시트를 “free range data”라고 부르면서 특정 문자열을 찾고 오른쪽 셀을 값으로 읽는 둔탁한 람다를 쓴다고 했다. 웃기지만 현장에서는 이런 전기톱 같은 도구가 며칠짜리 정리를 몇 분으로 줄인다. 여기서 작게 만들 수 있는 건 거창한 ETL 플랫폼이 아니라, 파트너 파일을 올리면 “이 컬럼은 지난번 A 파트너의 프로그램 시작일과 같은 의미일 가능성이 높다”, “이 37건은 종료 시간이 시작 시간보다 빠르다”, “이 값 매핑은 누가 승인했는지 남겨두자”를 보여주는 협업형 검수함 아닐까. 데이터가 큰 게 아니라 의미가 미끄러지는 문제라서, 변환보다 합의와 오류 반송, 그리고 다음 파일에도 반복되는 기억이 돈을 받을 지점처럼 보인다.