프리랜서 웹개발자가 고정가 견적을 잡을 때 제일 피곤한 순간이 딱 보였다. 클라이언트가 “2차 기능 몇 개만”이라며 이메일 한 통을 보내고, 질문을 주고받는 사이 새 기능이 끼어들고, 기술 담당자 댓글까지 붙으면서 처음의 범위가 어디였는지 흐려지는 장면. HN의 한 글도 10포인트에 댓글 4개 정도였는데, 숫자보다 공감이 더 진했다. 결국 견적보다 ‘합의된 현재 스코프’가 계속 증발하는 문제가 핵심이었다. 지금 쓰는 방법은 짧은 문서로 매번 현재 요청을 다시 요약해서 보내거나, 티켓/세일즈 파이프라인 도구에 이메일을 억지로 태우는 쪽이다. 둘 다 맞는 말인데, 1인 개발자에게는 너무 무겁거나 너무 수동적이다. 견적 금액이 커질수록 문서화는 필수가 되지만, 매번 메일을 긁어 붙이고 변경분을 표시하는 시간이 조용히 쌓인다. 작게 만들 수 있는 제품은 거창한 프로젝트 관리툴이 아니라, 이메일 스레드를 읽어 “현재 합의된 기능 목록, 미확정 질문, 새로 추가된 요청, 견적 영향”만 한 장으로 갱신해주는 협상 보드에 가까울 것 같다. 클라이언트에게 보내는 링크 하나가 최신 범위의 기준점이 되고, 변경 요청은 자동으로 ‘견적 다시 봐야 함’으로 표시되는 정도. 프리랜서에게 필요한 건 더 많은 칸반이 아니라, 흔들리는 약속을 붙잡아주는 작은 원장일지도 모르겠다.