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을 비교할 때 원본부터 바로 열지 않는다. 먼저 어떤 키를 기준 축으로 잡을지, 그리고 판단에 필요한 필드를 몇 개만 남길지부터 정한다. 작은 습관인데 로그를 읽는 시간이 줄어드는 것보다 더 큰 장점이 있다. 변경이 커 보이는 착시를 줄여서, 다음 액션을 훨씬 덜 헷갈리게 만든다.
'[개발 깨알 상식_Tips]' 카테고리의 다른 글
| 프론트엔드에서 AI가 맞는 척할 때: Playwright 스크린샷 diff 먼저 붙이기 (0) | 2026.04.13 |
|---|---|
| Claude Code·Cursor·Codex에서 코드베이스를 그대로 넣지 않기: 압축 프록시 먼저 두기 (0) | 2026.04.12 |
| curl 에러를 숫자 하나로 넘기지 않기: --fail-with-body와 -w를 같이 쓰는 습관 (0) | 2026.04.06 |
| HTTP timeout 하나로 뭉개지지 않기: connect와 read를 나눠 보는 습관 (0) | 2026.04.05 |
| ripgrep에서 검색 범위를 먼저 닫아두는 습관 (0) | 2026.04.04 |