안 되는 게 결함인가, 아직 없는 건가

엔진 매뉴얼과 릴리스 노트는 제일 빨리 낡는 자료다. 6개월이면 절반은 틀린 문서가 된다 — API 이름이 바뀌고, 동작이 달라지고, 있던 게 없어진다.

그런데 한 가지가 안 낡는다. 언제 생겼는지.

이건 취향이 아니라 판정 근거다

QA에서 “이 기능이 6.4에 추가됨”이 왜 중요하냐면, 재현이 안 될 때 그게 결함인지 아닌지를 가르는 게 이 한 줄이기 때문이다.

같은 증상이 두 가지를 뜻할 수 있다.

• 있어야 할 게 안 된다 → 결함
• 이 버전에는 아직 없다 → 결함 아님

둘을 눈으로는 구분 못 한다. 화면에서 둘 다 “안 된다”로 똑같이 보인다. 로그도 마찬가지다 — 없는 기능은 에러를 안 내고 그냥 아무 일도 안 한다.

그래서 재현이 안 되면 버전을 먼저 의심한다. 이 순서를 안 지키면 존재하지 않는 기능에 대한 버그 리포트를 쓰게 되고, 그건 개발자 시간을 쓰는 종류의 오탐이다.

반대 방향도 같다. 사라진 시점도 안 낡는다. “이건 5.8에서 제거됨”을 모르면 잘 돌던 게 갑자기 안 되는 이유를 못 찾는다.

최신 문서가 낡은 문서를 대체하지 못한다

여기가 반직관적인 부분이다. 보통 최신 문서가 옛 문서의 상위집합이라고 생각하는데, 시점 정보에 한해서는 반대다.

기능이 자리를 잡으면 문서에서 “6.4부터 사용 가능” 같은 표기가 조용히 빠진다. 새로 읽는 사람에게는 필요 없는 정보니까. 그래서 3년 지난 문서를 보면 그 기능은 처음부터 있었던 것처럼 쓰여 있다.

그 표기를 갖고 있는 건 그때 그 릴리스 노트뿐이다. 낡았다고 버리면 못 되찾는다.

그래서 이 종류의 자료는 “최신으로 갱신”하는 게 아니라 쌓아 두는 것이 맞다. 최신 매뉴얼은 지금 동작을 보러 가고, 옛 릴리스 노트는 시점을 보러 간다. 두 문서가 하는 일이 다르다.

정직한 한계

나는 아직 이걸 원장으로 안 쓰고 있다.

링크는 모아 뒀는데 “우리 빌드가 쓰는 버전 ↔ 그 기능의 등장 시점” 대조표를 만든 적은 없다. 지금은 재현이 안 될 때마다 그때그때 찾아본다.

이 글에 적힌 판단이 옳다면, 다음 단계는 명확하다 — 그 표를 만들고, TC 작성 시점에 버전 조건을 함께 적는 것. 판정 시점에 찾는 것보다 앞에 적어 두는 쪽이 싸다.

아직 안 했다. 그래서 이건 실행 보고가 아니라 판단이다.