출시를 막는 게 코드가 아니라 결정일 때: '왜 아직 못 내보내나'를 세 번 다시 물은 하루
몇 주 만든 도구를 왜 아직 공개 못 하는지 세 번 다시 캐물었더니, 매번 '이래서 못 낸다'던 이유가 틀렸고 진짜 이유는 훨씬 단순했다.
3줄 요약
- 몇 주 동안 만든 로컬 법률 문서 정리 도구를 두고, 왜 아직 대중에게 공개하지 못하는지 하루에 세 번 다시 물었다.
- 그때마다 "이래서 못 낸다"고 내놓은 이유가 앞선 이유를 뒤집었고, 마지막에 남은 진짜 이유는 처음 생각과 완전히 달랐다.
- 빌더에게 남는 교훈은 하나다. 출시를 막는 건 대개 안 끝난 코드가 아니라 아직 안 내린 결정이다. 그 둘을 구분하는 순간 다음에 할 일이 바뀐다.
첫 번째 답은 "아직 전략상 열면 안 된다"였다
공개를 막는 첫 번째 이유는 기술이 아니라 순서였다. 처음에는 제품이 이미 살아 있으니 이제 유통과 마케팅만 남았다고 생각했다. 그런데 한번 무료로 대중에게 풀면 되돌릴 수 없다. 유료화든 대상 한정이든, 나중에 쓸 수 있는 카드가 그 순간 전부 타 버린다.
그래서 프레임을 다시 잡았다. 이 도구는 아무에게나 뿌리는 무료 웹앱이 아니라, "누구에게 어떤 조건으로 열지"를 먼저 정해야 하는 자산이다. 마케팅 콘텐츠 초안까지 만들어 둔 상태였지만, 그건 순서를 앞질렀다고 판단하고 전부 멈췄다. 대상과 조건을 정의하는 일이 홍보보다 앞선다.
두 번째 답은 "코드가 아니라 사인오프가 남았다"였다
여기서 한 겹 더 벗겨 보니, 공개를 막는 실체는 미완성 코드가 아니었다. 실제 코드를 문서에 적힌 공개 전 필수 조건과 하나씩 대조했다. 결과 표현을 단정하지 않게 바꾸는 것, 금지 표현을 하드 게이트로 막는 것, 고정 고지문을 넣는 것은 이미 다 닫혀 있었다.
진짜로 남은 건 코드가 아니라 검증 사인오프였다. 그것도 소유자가 나뉘어 있었다.
- 내 몫: 오염 변형 사례 전체를 마감하는 일
- 협업 검토자 몫: 구현자가 아닌 사람이 결과를 독립적으로 재현하는 검증
- 나 자신이 만든 사람으로서 아닌, 최종 사용자 관점의 사인오프
핵심 재프레임은 이거였다. 공개를 막는 건 덜 만든 기능이 아니라 아직 안 찍힌 도장 몇 개다. 그렇게 정리하니 "코드를 더 짜야 한다"가 아니라 "누가 무엇을 검증해서 닫아야 한다"로 할 일이 바뀌었다.
세 번째 답은 "그 도장도 이미 다 찍혀 있었다"였다
마지막 한 겹이 제일 아팠다. 협업 기록을 다시 열어 대조하다가, 내 직전 보고가 틀렸다는 걸 발견했다. 독립 재현 검증을 아직 안 끝난 것으로 적었는데, 사실은 전날 이미 종결돼 있었다. 비구현자가 직접 실행해서 결과가 정확히 일치했고, 검토자도 통과를 선언한 상태였다.
내가 틀린 이유가 중요하다. 나는 검증 상태를 프로젝트 안의 기준값 파일에서 읽었다. 그 파일은 검증이 끝난 뒤 갱신되지 않은 낡은 값이었고, 나는 그걸 최신으로 착각했다. 상태를 편한 곳에서 읽으면 편하게 틀린다.
정정하고 나서야 진짜 그림이 보였다. 기술 검증 관문은 안전장치도 독립 재현도 전부 닫혀 있었다. 대중 공개를 막는 마지막 실체는 코드도, 검증도 아니라 순수하게 나의 출시 결정 그 자체였다.
오늘 배운 것
검증 상태에는 정본이 있다. 코드 옆에 놓인 기준값 파일이 아니라, 결정이 오간 협업 기록이 정본이다. 편한 파일에서 상태를 읽으면 이미 닫힌 일을 열려 있다고 보고하게 된다.
그리고 더 큰 교훈은 하루 전체를 관통한다. 출시를 막는 이유를 처음 물으면 대개 "코드가 덜 됐다"는 답이 나온다. 한 번 더 물으면 "검증이 안 끝났다"가 나온다. 세 번째로 물으면 남는 건 자주 "내가 아직 결정을 안 내렸다" 하나다. 만든 사람은 자기가 안 내린 결정을 자꾸 못 끝낸 작업으로 착각한다. 그 둘을 구분하는 게 오늘의 진짜 작업이었다.