[개발 깨알 상식_Tips] / JSONL 비교를 줄 번호로 하지 않기: id 기준으로 먼저 정렬해 보는 습관.md

JSONL 비교를 줄 번호로 하지 않기: id 기준으로 먼저 정렬해 보는 습관

조회

2026년 4월 8일 | 개발 깨알 팁


나는 평가 로그나 API trace를 JSONL로 많이 남긴다. JSONL은 JSON Lines의 줄임말로, 객체 하나를 한 줄씩 쌓는 형식이다. 문제는 결과를 두 번 뽑아 diff를 열면 실제로 바뀐 건 몇 개 안 되는데도, 줄 순서가 조금 달라졌다는 이유만으로 파일 전체가 뒤집혀 보일 때가 많다는 점이다. 이때 줄 번호 기준으로 읽기 시작하면 금방 피곤해진다.

그 뒤로는 비교 전에 줄 번호가 아니라 기준 축부터 고정하는 쪽으로 습관이 바뀌었다. 가장 흔한 건 id, query_id, doc_id 같은 키다. 먼저 그 키로 정렬해서 보기 좋은 형태로 다시 뽑고, 그 다음에 diff를 본다. 순서 흔들림이 노이즈로 빠지고 나면 정말 바뀐 score, rank, label만 남아서 판단이 훨씬 빨라진다.

비교 전에 한 번 더 거치는 정리 단계

jq -s 'sort_by(.query_id) | map({query_id, top1, score})' before.jsonl > before.norm.json
jq -s 'sort_by(.query_id) | map({query_id, top1, score})' after.jsonl  > after.norm.json

핵심은 명령어 자체보다 비교 단위를 먼저 고정한다는 데 있다. 나는 여기서 query_id를 썼지만, 서비스 로그라면 request_id, 배치 결과라면 item_id가 더 맞을 수 있다. 필드도 욕심내지 않고 두세 개만 남기는 편이 좋았다. 원본 전체를 그대로 비교하면 바뀌지 않은 메타데이터까지 같이 흔들려서 오히려 판독 속도가 떨어진다.

  • 순서 변화내용 변화를 분리해서 볼 수 있다.
  • 재실행 때문에 생긴 우연한 셔플을 실제 회귀로 오해할 가능성이 줄어든다.
  • 누가 봐도 같은 기준으로 비교했다는 흔적이 남아서 리뷰가 쉬워진다.

이 습관이 특히 좋은 건 reranking, retrieval, 배치 평가처럼 행의 개수는 비슷한데 정렬만 자주 흔들리는 작업에서다. 줄 번호 diff만 보고 있으면 "뭔가 엄청 바뀐 것 같은데 정확히 뭐가 바뀐 거지" 상태가 자주 온다. 반대로 id 축을 먼저 고정하면, 실제로는 top1 제목이 두 개 바뀌었는지, score만 소폭 움직였는지, 특정 query만 깨졌는지가 바로 보인다.

나는 이제 JSONL을 비교할 때 원본부터 바로 열지 않는다. 먼저 어떤 키를 기준 축으로 잡을지, 그리고 판단에 필요한 필드를 몇 개만 남길지부터 정한다. 작은 습관인데 로그를 읽는 시간이 줄어드는 것보다 더 큰 장점이 있다. 변경이 커 보이는 착시를 줄여서, 다음 액션을 훨씬 덜 헷갈리게 만든다.

댓글

홈으로 돌아가기

검색 결과

"" 검색 결과입니다.