출처를 모르는 데이터 파일 백업이 여러 개 있었고 분류하려면 버전을 알아야 했다. dump 도구로 내용을 뽑아 VERSION 레코드를 찾으니 알 수 없는 값 하나가 들어 있었다.
Table of contents
Open Table of contents
문제 — 상수 목록과의 불일치
이 프로젝트는 포맷 세대를 FORMAT_V1 부터 이어지는 상수 목록으로 정의하고 있었다. 뽑은 값은 그 목록 어디에도 없었고 가장 큰 상수보다도 훨씬 큰 숫자였다.
웹에서 그 값을 찾아도 안 나왔고 상수 목록을 다시 대조해도 여전히 안 맞았다. 내가 모르는 최신 상수가 있는지 아니면 다른 구현체인지를 뒤지면서 한참 헤맸다.
판단 기준 — 방향을 바꾼 질문
거기서 멈춰 생각하니 이 필드가 포맷 버전이라는 것 자체가 내 전제였다. 필드 이름이 VERSION 이라고 해서 그것이 포맷 버전이라는 보장은 없다. 두 가지 방법이 있었는데 다른 구현체와 최신 판의 상수 목록을 계속 넓혀 대조하는 것과 전제를 의심하고 소스에서 그 값을 쓰는 코드를 찾는 것이다. 뒤쪽을 골랐다. 이유는 대조가 완전히 실패한 것은 목록 부족이 아니라 대상 착오의 신호라서다. 대신 저장소를 받아 코드를 읽는 시간을 감수했다.
여기서 질문이 바뀌었다. 상수 목록은 그 프로젝트의 소스에 있으므로 부족할 리가 없고 대조가 완전히 실패하면 대조 대상이 틀린 것이다.
해결 — 소스가 준 답
그래서 프로젝트 소스를 git clone 으로 직접 받아 그 값을 저장하는 코드를 grep -rn VERSION 으로 찾았다. 거기서는 포맷 버전이 아니라 CLIENT_VERSION 상수를 쓰고 있었다.
그 상수를 따라가니 major * 10000 + minor * 100 + build 로 조합하는 계산식이었다. 역산하니 특정 판이 나왔고 git checkout 으로 해당 태그의 소스에서 확인했다. 즉 그 값은 이 파일을 마지막으로 연 클라이언트의 버전이었다.
둘이었던 필드
그러면 포맷 세대는 어디에 있는지도 이어서 찾아봤다. MIN_VERSION 을 담는 별도 필드가 있었고 그 값이 FORMAT_V* 상수 목록과 정확히 맞아떨어졌다.
결국 필드가 둘이었고 내가 처음부터 엉뚱한 쪽을 보고 있었던 것이다. 헤맨 흐름을 정리하면 이름을 보고 포맷 버전이라고 가정했고 대조가 실패하자 목록이 부족한지를 물었는데 거기서 전제가 틀렸는지를 물었어야 방향이 맞았다.
결론 — 값을 쓰는 코드가 답이다
검색으로는 안 나오던 것이 소스를 받아 읽으니 30분 만에 풀렸다. 경로는 저장하는 코드를 찾아 무슨 값을 쓰는지 보고 그 값의 정의로 내려간 뒤 계산식이면 역산하는 순서다.
원래 목적으로 돌아가면 이 값이 오히려 유용했다. 그 백업을 마지막으로 연 클라이언트 버전을 알 수 있으므로 출처를 모르는 파일들을 그 값으로 분류할 수 있었다. 틀린 전제로 읽었으면 이 쓸모도 못 봤을 것이다.
정리
- 필드 이름이
VERSION이라고 포맷 버전이라는 보장이 없다 - 상수 목록과 완전히 안 맞으면 대조 대상이 틀린 것이다
- 내가 모르는 값이 있는지보다 전제가 틀렸는지를 먼저 묻는다
- 이 값이 무엇이냐는 그 값을 쓰는 코드에 있다
- 검색보다 소스가 빠를 때가 있다
- 값이
major * 10000 + minor * 100 + build같은 계산식의 결과면 역산한다 - 비슷한 이름의 필드가 둘 이상 있을 수 있다
- 틀린 전제를 버리면 원래 못 본 쓸모가 보이기도 한다