흔한 함정: 문제가 아니라 해결책을 명세화하기

한 가지 실패 양상은 따로 짚어둘 만한데, 너무 쉽게 빠지기 때문이다. 명세를 쓰려고 앉으면, 이미 머릿속에 그려둔 해결책을 묘사하고 싶은 유혹이 든다 — "탭이 있는 사이드바", "튀어나오는 모달", "Postgres 테이블". 하지만 해결책으로 가득 찬 명세는 아직 얻어내지 못한 결정들을 슬그머니 못박아 버린다.

이 두 줄을 비교해보라:

Bad:  Add a left sidebar with collapsible sections for each book status.
Good: Let me see my books grouped by status without losing the full list.

첫 문장은 이미 사이드바를, 접히는 섹션을, 그리고 레이아웃을 골랐다 — 그것들이 옳은 선택인지 아무도 확인하기 전에. 둘째 문장은 해야 할 일을 진술하고, AI(그리고 당신)가 그것을 만족시키는 가장 단순한 것을 찾도록 자유롭게 둔다, 그것이 그냥 필터 버튼 세 개일 수도 있다. 원하는 결과를 묘사하라; 구현은 가능한 한 오래 협상 가능한 채로 두어라. 해결책은 명세에서는 바꾸기 싸고 코드에서는 바꾸기 비싸다.