형식 변경 뒤에 있던 실행 문제
공공기관의 AI 학습·추론 환경을 다루는 고객 과제였다. 회사 업무와는 별도로 진행한 개인 프로젝트에서 데이터 처리와 실행 환경 연계·인수인계를 맡았다. 연구자는 대용량 학습 데이터를 Arrow 형식으로 바꿔 달라고 요청했다. 용량과 메모리가 빠듯했고, 기존 운영 작업도 계속 돌아야 했다.
Arrow를 쓰자는 요구는 고객에게서 왔다. 내가 먼저 판단할 것은 기존 파일과 DB를 누가 어디서 읽고 있는지였다. 운영에 쓰는 JSONL과 학습을 위해 한 번 더 만드는 JSONL은 이름이 비슷해도 역할이 달랐다. 둘을 같이 바꾸면 형식 전환과 상관없는 작업까지 영향을 받을 수 있었다.
남길 원본과 없앨 중간 파일
JSONL은 한 줄에 JSON 데이터 하나를 적는 텍스트 형식이다. 원본을 확인하거나 기존 프로그램이 읽는 데 쓰고 있었다. Arrow는 열 단위로 데이터를 다루는 형식이며, 이 과제의 학습 경로에서는 Hugging Face Datasets로 읽을 데이터에 사용했다. Arrow 형식과 Datasets의 Arrow 사용에 기본 설명이 있다.
모든 파일을 Arrow로 통일하지 않았다. 운영 JSONL·DB는 보존하고, 학습용 중간 JSONL을 전체 생성한 뒤 다시 변환하던 단계만 없앴다. 학습 데이터는 바로 Arrow로 만들도록 바꿨다. 형식을 하나 줄이는 것보다, 어느 경로를 바꿔도 되는지 구분하는 일이 먼저였다.
파일이 생겼다고 학습이 되는 것은 아니었다
raw와 normalized 데이터를 각각 920,544행 생성하고 검사했다. 이 숫자는 실행 규모다. 처리 속도나 모델 정확도가 그만큼 좋아졌다는 뜻은 아니다.
검사는 파일을 읽는 단계에서 끝내지 않았다. NaN·Inf처럼 정상 계산에 쓸 수 없는 값이 있는지, 배열의 shape와 dtype이 학습 코드가 기대하는 것과 맞는지 확인했다. shape는 데이터의 차원과 크기, dtype은 값의 자료형이다. 파일 안에 숫자가 들어 있어도 이 조건이 다르면 다음 계산에서 문제가 날 수 있다.
PyTorch DataLoader로 실제 데이터를 읽고, 학습 파라미터 전달과 checkpoint 재로딩도 확인했다. checkpoint는 학습한 모델 상태를 저장해 다시 불러오는 파일이다. 추론 API의 입력·출력과 Simulink/HMI로 이어지는 규약도 맞췄다. 데이터 생성, 모델 실행, 다른 시스템의 결과 사용을 각각 확인한 것이다.
구현에는 AI 코딩 도구를 사용했다. 의존성을 읽고 바꿀 범위를 정한 뒤, 코드와 실행 결과·파일 해시를 대조했다. 이 작업의 결과를 모델의 정확도 향상이나 현장 자동제어 성과로 설명하지는 않는다.
연구자의 컴퓨터에서 시작할 수 있게
연구자는 코딩에 익숙하지 않았고 Windows에서 실행해야 했다. PowerShell 기준으로 Arrow 생성, 사전 점검, 작은 CPU 학습을 시작하는 순서를 문서에 적었다. 기존 예제를 보존하면서 작은 규모로 연습할 수 있게 했고, 실행·튜닝·검수 방법을 전화로도 설명했다.
많은 자료를 한꺼번에 넘기는 대신 시작할 명령, 정상 출력, 실패했을 때 볼 곳을 구분했다. 내 환경에서 전체 데이터를 돌린 기록과 연구자가 작은 예제로 절차를 익히는 기록도 같은 성과로 합치지 않았다.
1차 과제를 마치고 인계한 뒤, 연구자로부터 직접 실행해 잘 사용하고 있다는 연락을 받았다. 내가 사용 현장을 계속 관찰한 것은 아니며, 문서의 특정 배치가 사용 성공의 원인이었다고 확인한 것도 아니다. 다만 코드를 전달한 다음 실제 사용으로 이어졌다는 피드백은 남길 수 있었다.