첫 번째 전의 모든 견적은 추측이야
앱 넷이 공용 컴포넌트 하나로 수렴해야 했어. 하나도 안 했을 때 정직한 지식 상태는 이랬지. 변환이 얼마인지 아무도 모른다. 다들 의견은 있었고, 전부 코드를 옮겨본 게 아니라 읽어서 나온 거였고, 코드 읽기는 체계적으로 적게 잡아. 일의 모양은 보여주고 쌓인 예외는 감추거든.
그래서 순서를 일부러 싼 것부터로 잡았고, 첫 변환을 자세히 적었어. 공용 컴포넌트로 뭐가 옮겨갔는지, 앱에서 뭘 지워야 했는지, 공용 컴포넌트가 뭘 길러야 했는지, 그리고 알고 보니 아예 문제가 아니었던 게 뭔지.
그 기록이 결과물이야
그 기록이 세 번 더 진짜 일을 했어. 이어진 변환마다 그걸 읽고 어느 값이 여기 해당하는지 묻는 걸로 시작했지. 어떤 땐 답이 "하나도 없음"이었어. 똑같은 아키텍처 질문이 뒤따른 셋 전부에서 나왔고 어디서도 값이 0 이었어. 그 컨트롤을 사용자한테 실제로 내보낸 건 첫 앱뿐이었으니까.
그 기록이 없었으면 그 질문이 세 번 처음부터 다시 논쟁됐을 거야. 매번 누가 확인 대신 추론하면서. 있으니까 질문이 일 분 걸렸어. 이 앱이 그 컨트롤을 내보내? 아니. 그럼 이 값은 해당 없음.
마지막이 제일 쌌고, 그건 모순이 아냐
순서는 예상 비용 순이었고, 그 예상이 끝쪽에서 틀렸어. 플랫폼이 다르고, 자기 설정 저장소가 있고, 에디터로 가는 다리가 있어서 다들 제일 나쁠 거라고 가정한 앱이 넷 중 제일 싸게 나왔어. 무서워하던 것 대부분이 접촉을 못 견뎠거든.
막힘돌이라던 건 컴포넌트를 갈아끼우면 에디터 다리가 깨진다는 거였어. 파일을 읽으니 정리됐어. 그 다리는 window 에서 듣고 메시지 이벤트의 source 로 답해. 프레임 요소를 아예 쥐지 않으니까 갈아끼워도 못 건드려. 그리고 그 앱 배치는 이미 공용 컴포넌트의 구조 요구사항을 아무 변경 없이 만족하고 있었고.
일반화할 값이 있어. 두려움에서 나온 비용 견적이 제일 못 믿을 종류고, 반증하기는 제일 싸. 마음에 걸리는 바로 그 파일을 한 시간 읽으면 두려움이 없어지거나 진짜로 크기가 있는 문제가 되거나 둘 중 하나야. 그리고 둘 중 어느 결과든 그걸 안 따져본 웃돈으로 지고 있는 견적보단 나아.