# 안 되는 게 결함인가, 아직 없는 건가
> 버전 문서에서 기능 설명은 6개월이면 반이 틀립니다. 등장 시점은 안 틀립니다. 그리고 판정에 필요한 건 대개 후자입니다.
- 수치: 시점
- 상태: wip
- 사람이 보는 화면: https://aitryed.com/ko/writing/verdicts/version-docs/
- 반대 언어: https://aitryed.com/en/writing/verdicts/version-docs/index.md
- 이 사이트 안내(AI용): https://aitryed.com/ko/llms.txt
---
**「안 되는 것」을 봤을 때, 그게 «결함»인지 «아직 안 만든 것»인지 어떻게 가르나. 답을 버전 문서에서 찾는 이야기입니다.**
## 문제부터
테스트를 하다 안 되는 걸 발견했습니다. **두 가지일 수 있습니다.**
| 가능성 | 그러면 |
|---|---|
| **결함** | 고쳐야 함 → 등록하고 담당자 배정 |
| **아직 안 만든 기능** | **고칠 게 없음** → 등록하면 오히려 민폐 |
**겉으로는 똑같이 보입니다.** 둘 다 「눌렀는데 안 됨」입니다.
그리고 잘못 가르면 비쌉니다. 미구현을 결함으로 등록하면 **개발자가 시간을 써서 「이건 원래 없는 기능입니다」를 확인**해 줍니다.
## 그래서 근거를 어디서 얻나
기획서를 봅니다. 그런데 기획서는 「만들 것」을 적은 것이지 「만들었는지」를 적은 게 아닙니다.
그래서 버전 문서(변경 이력)를 봅니다.
## 그런데 버전 문서도 반은 틀립니다
여기가 이 글의 핵심입니다.
버전 문서에 적힌 것을 두 종류로 갈라야 합니다.
| 무엇 | 6개월 뒤에 |
|---|---|
| **기능 설명** (「이 기능은 이렇게 동작한다」) | **절반쯤 틀림** — 그 뒤에 바뀜 |
| **등장 시점** (「이 기능은 X판에 들어왔다」) | **안 틀림** — 과거는 안 바뀜 |
그리고 **판정에 필요한 건 대개 뒤쪽**입니다.
「이 기능이 지금 어떻게 동작해야 하나」를 알고 싶은 게 아닙니다. 「이 기능이 이 빌드에 들어 있기는 한가」를 알고 싶은 것입니다.
> **설명은 상하고 시점은 안 상합니다. 그리고 결함이냐 미구현이냐를 가르는 건 시점입니다.**
## 그래서 최신 문서가 낡은 문서를 대체하지 못합니다
이게 따라 나오는 결론입니다.
보통은 **최신 문서만** 봅니다. 최신이 제일 정확할 것 같으니까요.
그런데 **최신 문서에는 「언제 들어왔는지」가 대개 안 적혀** 있습니다. 지금 상태만 적혀 있습니다.
**언제 들어왔는지는 그때 문서에만** 있습니다. 그래서 **옛 문서를 버리면 안 됩니다.**
| | 지금 어떻게 동작하나 | 언제 들어왔나 |
|---|---|---|
| 최신 문서 | **있음** | 대개 없음 |
| **그때 문서** | 낡음 | **있음** |
## 정직한 한계
이 방법에도 구멍이 있습니다.
**버전 문서에 안 적히고 들어간 것**이 있습니다. 작은 변경은 기록을 안 남기는 경우가 많습니다.
그래서 이 방법은 「적혀 있으면 확실하고, 안 적혀 있으면 모름」입니다. **「안 적혀 있으니 없다」가 아닙니다.**
그 차이를 지키는 게 중요합니다. **없는 기록을 「없다」의 증거로 쓰면 틀립니다.**
## 여기부터는 자세한 기록입니다
엔진 매뉴얼과 릴리스 노트는 **제일 빨리 낡는 자료**다. 6개월이면 절반은 틀린 문서가 된다 — API 이름이 바뀌고, 동작이 달라지고, 있던 게 없어진다.
그런데 한 가지가 안 낡는다. **언제 생겼는지.**
## 이건 취향이 아니라 판정 근거다
QA에서 "이 기능이 6.4에 추가됨"이 왜 중요하냐면, **재현이 안 될 때 그게 결함인지 아닌지를 가르는 게 이 한 줄**이기 때문이다.
같은 증상이 두 가지를 뜻할 수 있다.
- 있어야 할 게 안 된다 → **결함**
- 이 버전에는 아직 없다 → **결함 아님**
둘을 눈으로는 구분 못 한다. 화면에서 둘 다 "안 된다"로 똑같이 보인다. 로그도 마찬가지다 — 없는 기능은 에러를 안 내고 그냥 아무 일도 안 한다.
그래서 재현이 안 되면 **버전을 먼저 의심한다.** 이 순서를 안 지키면 존재하지 않는 기능에 대한 버그 리포트를 쓰게 되고, 그건 개발자 시간을 쓰는 종류의 오탐이다.
반대 방향도 같다. **사라진 시점**도 안 낡는다. "이건 5.8에서 제거됨"을 모르면 잘 돌던 게 갑자기 안 되는 이유를 못 찾는다.
## 최신 문서가 낡은 문서를 대체하지 못한다
여기가 반직관적인 부분이다. 보통 최신 문서가 옛 문서의 상위집합이라고 생각하는데, **시점 정보에 한해서는 반대**다.
기능이 자리를 잡으면 문서에서 "6.4부터 사용 가능" 같은 표기가 **조용히 빠진다.** 새로 읽는 사람에게는 필요 없는 정보니까. 그래서 3년 지난 문서를 보면 그 기능은 처음부터 있었던 것처럼 쓰여 있다.
그 표기를 갖고 있는 건 **그때 그 릴리스 노트뿐**이다. 낡았다고 버리면 못 되찾는다.
그래서 이 종류의 자료는 "최신으로 갱신"하는 게 아니라 **쌓아 두는 것**이 맞다. 최신 매뉴얼은 지금 동작을 보러 가고, 옛 릴리스 노트는 시점을 보러 간다. 두 문서가 하는 일이 다르다.
## 정직한 한계
**나는 아직 이걸 원장으로 안 쓰고 있다.**
링크는 모아 뒀는데 "우리 빌드가 쓰는 버전 ↔ 그 기능의 등장 시점" 대조표를 만든 적은 없다. 지금은 재현이 안 될 때마다 그때그때 찾아본다.
이 글에 적힌 판단이 옳다면, 다음 단계는 명확하다 — 그 표를 만들고, **TC 작성 시점에 버전 조건을 함께 적는 것.** 판정 시점에 찾는 것보다 앞에 적어 두는 쪽이 싸다.
아직 안 했다. 그래서 이건 실행 보고가 아니라 판단이다.