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

「안 되는 것」을 봤을 때, 그게 «결함»인지 «아직 안 만든 것»인지 어떻게 가르나. 답을 버전 문서에서 찾는 이야기입니다.

문제부터

테스트를 하다 안 되는 걸 발견했습니다. 두 가지일 수 있습니다.

가능성	그러면
결함	고쳐야 함 → 등록하고 담당자 배정
아직 안 만든 기능	고칠 게 없음 → 등록하면 오히려 민폐

겉으로는 똑같이 보입니다. 둘 다 「눌렀는데 안 됨」입니다.

그리고 잘못 가르면 비쌉니다. 미구현을 결함으로 등록하면 개발자가 시간을 써서 「이건 원래 없는 기능입니다」를 확인해 줍니다.

그래서 근거를 어디서 얻나

기획서를 봅니다. 그런데 기획서는 「만들 것」을 적은 것이지 「만들었는지」를 적은 게 아닙니다.

그래서 버전 문서(변경 이력)를 봅니다.

그런데 버전 문서도 반은 틀립니다

여기가 이 글의 핵심입니다.

버전 문서에 적힌 것을 두 종류로 갈라야 합니다.

무엇	6개월 뒤에
기능 설명 (「이 기능은 이렇게 동작한다」)	절반쯤 틀림 — 그 뒤에 바뀜
등장 시점 (「이 기능은 X판에 들어왔다」)	안 틀림 — 과거는 안 바뀜

그리고 판정에 필요한 건 대개 뒤쪽입니다.

「이 기능이 지금 어떻게 동작해야 하나」를 알고 싶은 게 아닙니다. 「이 기능이 이 빌드에 들어 있기는 한가」를 알고 싶은 것입니다.

설명은 상하고 시점은 안 상합니다. 그리고 결함이냐 미구현이냐를 가르는 건 시점입니다.

그래서 최신 문서가 낡은 문서를 대체하지 못합니다

이게 따라 나오는 결론입니다.

보통은 최신 문서만 봅니다. 최신이 제일 정확할 것 같으니까요.

그런데 최신 문서에는 「언제 들어왔는지」가 대개 안 적혀 있습니다. 지금 상태만 적혀 있습니다.

언제 들어왔는지는 그때 문서에만 있습니다. 그래서 옛 문서를 버리면 안 됩니다.

	지금 어떻게 동작하나	언제 들어왔나
최신 문서	있음	대개 없음
그때 문서	낡음	있음

정직한 한계

이 방법에도 구멍이 있습니다.

버전 문서에 안 적히고 들어간 것이 있습니다. 작은 변경은 기록을 안 남기는 경우가 많습니다.

그래서 이 방법은 「적혀 있으면 확실하고, 안 적혀 있으면 모름」입니다. 「안 적혀 있으니 없다」가 아닙니다.

그 차이를 지키는 게 중요합니다. 없는 기록을 「없다」의 증거로 쓰면 틀립니다.

여기부터는 자세한 기록입니다

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

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

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

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

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

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

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

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

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

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

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

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

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

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

정직한 한계

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

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

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

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