리뷰 AI의 지적을 전부 반영하면 요구사항 정의가 끝나지 않는다 ― 채택 기준과 REQUIREMENTS.md로 멈추기

• 리뷰 AI(Review AI)는 「구멍을 찾는 것」이 업무이므로, 내버려 두면 무한히 구멍을 찾아낸다. 전부 반영하면 요구사항 정의(Requirements Definition)가 영원히 확정되지 않는다 (= 끝나지 않는 요구사항 정의 루프).
• 원인은 AI의 정밀도가 아니라, 채택 여부를 결정하는 「사령탑」을 인간이 비워두고 있다는 점이다.
• 대책은 두 가지. (1) 채택 기준을 「따르지 않았을 때 실제로 누가 곤란해지는가」로 고정한다. (2) REQUIREMENTS.md의 서두에 「해결할 구멍 / 하지 않을 것 / 리뷰 AI에 대한 지시」를 먼저 작성한다.
• 납품 전에, 코드를 한 줄씩 설명할 수 있는지 확인한다.

AI와 프로그램을 조율하며, 기술적인 문제로 막힌 것이 아닌데도 앞으로 나아가지 못하게 되었다. 요구사항 정의가 끝나지 않는 구조에 빠져 있었다.

구멍을 지적받는다 → 보강한다 → 보강하면 새로운 구멍이 보인다 → 다시 보강한다. 이것이 끊임없이 반복된다. 특히 리뷰 AI(코드나 설계의 구멍을 찾아내게 하는 AI)를 개입시키면 가속화된다. 리뷰 AI의 업무는 구멍을 찾는 것이므로, 내버려 두면 얼마든지 구멍을 찾아낸다. 그것을 전부 반영하면, 완성을 위한 요구사항 정의가 아니라, 미완성을 연명하기 위한 요구사항 정의가 된다.

소위 스코프 크리프(Scope Creep)의 일종이지만, 구멍 → 보강 → 새로운 구멍의 피드백이 자가 발전한다는 점이 특징이다. 이 글에서는 이를 「끝나지 않는 요구사항 정의 루프」라고 부른다.

처음에는 AI의 정밀도 문제라고 생각했다. 하지만 아니었다.

문제는 AI를 「결정을 승인하는 권위」로 취급하고 있었다는 점에 있다. 구멍을 찾아내게 하는 것 자체는 나쁘지 않다. 나쁜 것은, 찾아낸 뒤의 채택 여부를 자신이 중심이 되어 결정하지 않았다는 것이다. 중심이 공석이 되면, AI의 정론(正論)에 그대로 끌려가게 된다.

솔직히 말하면, 정론을 마주하면 그것을 반영하지 않는 것에 죄책감이 생긴다. 「이론상 있을 수 있는 구멍」과 「이번에 막지 않으면 실제로 곤란해지는 구멍」을 나는 제대로 구분하지 못하고 있었다. 막힘의 정체는 기술이 아니라 바로 이곳이었다.

기준은 이것 하나로 좁혔다.

그 지적을 따르지 않았을 때, 실제로 누가 곤란해지는가.

리뷰 AI가 내놓는 구멍의 대부분은 「이론상 있을 수 있는 것」이지만, 아무도 곤란해하지 않는 경우가 있다. 곤란해하는 사람을 이름으로 꼽을 수 없는 지적은, 아무리 옳더라도 이번 요구사항에는 포함하지 않는다. 옳은 지적이라도 이번 완성에 직접적인 영향을 주지 않는다면 「향후 과제」로 보낸다. 추상적인 완벽함으로 판단하지 않는다.

질문의 분류도 효과적이었다.

그 질문에 답하더라도 다음의 구체적인 행동이 바뀌지 않는다면, 그것은 「멈추는 질문」이다.

「또 팽창하는 것은 아닐까」라고 생각만 하는 것이라면 멈추는 질문. 그것을 방지하기 위해 무엇을 쓸 것인지, 무엇을 이번에 하지 않기로 결정할 것인지까지 도달한다면 나아가는 질문이다.

요구사항 정의에서는 기능 요구사항보다 먼저 「완성을 지키기 위한 제약」을 작성한다. 구체적으로는 REQUIREMENTS.md의 서두에 이것을 배치한다.

## 이 시스템이 해결할 구멍 (이 외에는 하지 않음)
1.
2.
...

이러한 제약이 있다면, 리뷰 AI가 10개의 구멍을 찾아내더라도 1, 2, 3에 효과적인 2개만 반영하고, 나머지 8개는 향후 과제로 보낼 수 있다. 완성을 가로막는 것은 코드의 난이도가 아니라, 선긋기의 부재이다.

포인트는 리뷰 AI를 호출하기 전에 이것을 써두는 것이다. 호출한 뒤에 쓰면 이미 증식이 시작된 후다.

AI에게 구현을 맡기더라도, 코드를 눈앞에 두고 한 줄씩 「이것은 무엇인가」를 설명할 수 없다면 납품하지 않는다. 이것은 자신을 책망하기 위해서가 아니라, 지식을 버리지 못하게 하기 위한 장치다. 모르는 줄이 있으면 납품이 멈추기 때문에, 뇌가 그것을 「버려도 되는 정보」로 취급할 수 없게 된다.

• 리뷰 AI를 호출하기 전에 「해결할 구멍 / 하지 않을 것 / 채택 기준」을 작성했는가
• 지적의 채택 여부를 「따르지 않았을 때 누가 곤란해지는가」, 「이름으로 꼽을 수 있는가」로 결정했는가
• 그 질문에 답하면 다음 행동이 바뀌는가 (바뀌지 않는다면 깊게 파고들지 않는다)
• 납품 전에, 코드를 한 줄씩 설명할 수 있는지 확인했는가

AI에게 맡길수록 인간 측의 질문, 의지, 책임은 남는다. 편리해진 만큼 사령탑 의자의 무게는 늘어난다. 그 의자만큼은 비워두어서는 안 된다.