"이 화면 얼마나 걸려요?"

"이틀이요."

그리고 닷새가 걸려요. 흥미로운 건 틀리는 방향이 항상 같다는 점이에요. 프론트엔드 추정은 넉넉하게 잡았다가 남는 경우가 거의 없어요. 항상 모자라요.

한쪽으로만 틀리면 그건 실력 문제가 아니에요. 세는 방법이 잘못된 거죠. 그래서 감으로 얘기하는 대신, 제 저장소를 열어서 확인해봤어요.

커밋이 말해주는 것

hanui의 OTP 인증 블록이에요. 만든 날과 그 이틀 뒤의 기록이에요.

3월 1일에 만들었어요. 그날 기준으로 이 블록은 완성이었어요. 인증번호 입력하고, 확인 버튼 누르면 검증되고, 다 동작했어요.

이틀 뒤 파일이 269줄이 됐어요. 거의 두 배예요. 그리고 커밋 메시지가 늘어난 게 뭔지 그대로 말해줘요 — 타이머, 접근성, 에러/로딩 상태.

기능이 추가된 게 아니에요. OTP 입력이라는 일은 3월 1일에 이미 다 됐어요. 늘어난 141줄은 전부 그 일이 잘 안 풀릴 때 화면이 뭘 해야 하는가였어요. 인증번호가 틀렸을 때, 시간이 다 됐을 때, 서버가 응답을 안 할 때, 키보드로만 쓰는 사람이 왔을 때.

"이틀이요"라고 답했을 때 제가 센 건 136줄이었어요. 269줄짜리 일을요.

저 하나만 그런 게 아니었어요

한 사례로 결론 내면 안 되니까 블록 전체를 세어봤어요.

열에 넷은 "완성" 후에 다시 열렸어요. 그 커밋들이 무슨 일을 했는지 보면 성격이 비슷해요.

새 기능이 없어요. 전부 처음에 안 세었던 상태들이에요. 입력이 덜 됐을 때, 겹쳐 뜨는 요소가 있을 때, 색 대비가 모자랄 때.

참고로 이 42개 중 테스트 파일이 있는 건 15개예요. 나머지 27개는 "동작하는 걸 눈으로 확인함" 상태로 완료 처리된 거고요. 테스트를 안 썼다는 게 문제라기보다, 완료 기준이 사람마다 다른 채로 추정이 오갔다는 뜻이에요.

우리가 세는 건 화면 하나가 아니에요

정리하면 이래요. "사용자 목록 화면"을 추정할 때 머릿속에 그려지는 건 데이터가 차 있는 테이블이에요. 그런데 실제로 만드는 건 그것 말고도 이만큼이에요.

로딩 중일 때. 데이터가 0건일 때. 검색 결과가 0건일 때 — 이건 데이터 0건과 문구가 달라야 해요. 에러가 났을 때. 권한이 없을 때. 이름이 40자인 사람이 있을 때. 모바일에서 테이블이 화면을 넘칠 때.

여섯 개 넘게 있는데 그중 하나를 세고 이틀이라고 답한 거예요. 닷새는 추정이 틀린 게 아니라 원래 닷새짜리 일이었어요.

OTP 블록의 141줄이 이걸 그대로 보여줘요. 해피 패스는 136줄, 나머지 상태들이 141줄. 대략 반반이에요.

재고를 모르면 추정이 아니라 점이에요

또 하나 빠지는 게 있어요. 같은 화면이라도 이미 뭐가 있느냐에 따라 완전히 달라져요.

hanui에는 지금 컴포넌트 104개, 블록 42개가 있어요. 이 상태에서 "사용자 목록 화면"은 Table과 SearchBar와 Pagination을 조립하는 일이에요. 아무것도 없는 프로젝트에서 같은 화면은 컴포넌트 세 개를 새로 만드는 일이고요. 앞은 하루, 뒤는 나흘이에요.

그래서 "이 화면 얼마나 걸려요?"에 바로 답할 수가 없어요. 재고를 모르면 그건 추정이 아니라 점이에요. 2편에서 컴포넌트 인벤토리 얘기를 한 게 이것 때문이에요. 인벤토리가 있으면 "신규 1개, 나머지 조립"이라고 말할 수 있고, 그건 꽤 정확해요.

그래서 뭘 바꿨냐면

숫자를 잘 맞히려고 하는 대신 두 가지를 바꿨어요.

하나. 화면이 아니라 상태를 세요. "사용자 목록 2일" 대신 "조립 + 로딩 + 빈 상태 2종 + 에러 + 권한 + 모바일". 이러면 숫자가 커지는데, 커진 숫자는 어디를 깎을지 대화가 되는 숫자예요. "모바일은 다음 스프린트로" 하면 하루가 빠져요. "2일에 해주세요"보다 훨씬 생산적이에요.

둘. 모르는 건 모른다고 숫자에 넣어요. 가장 많이 틀리는 건 아직 안 정해진 것인데, 우리는 그걸 추정에 안 넣고 "일단 되겠지" 하고 넘겨요.

이게 "5일이요"보다 나은 건 정확해서가 아니에요. 공을 넘기기 때문이에요. 기획자가 이 표를 보면 두 개를 오늘 정해줘요. 그러면 3.5일로 확정돼요. "5일이요"라고 하면 아무도 아무것도 정하지 않고, 닷새 뒤에 "권한 정책이 아직인데요"라는 대화가 시작돼요.

추정이 하는 진짜 일은 미래를 맞히는 게 아니라 지금 뭘 모르는지 드러내는 것이에요.

확인해보세요

이 글에서 제일 쓸모 있는 건 제 숫자가 아니라 방법일 거예요. 본인 저장소에서 이걸 돌려보세요.

두세 개만 봐도 팀의 패턴이 보여요. 저는 38%였어요. 그 말은 다음 추정에 1.4배를 곱해야 한다는 뜻이고, 더 정확히는 상태 처리를 처음부터 세었어야 한다는 뜻이에요.

"이 화면 얼마나 걸려요?"에 바로 답하지 마세요. "상태가 몇 개예요?"라고 되물으면, 그 순간부터 추정이 맞기 시작해요.

시리즈: 애자일과 프론트엔드

1편: UI 개발자는 디자인을 기다리지 않는다
2편: 스프린트에서 컴포넌트 먼저 만드는 이유
3편: 프론트엔드 추정은 왜 항상 틀릴까 ← 현재 글
다음 편: 디자이너와 싸우지 않는 협업법

프론트엔드 추정은 왜 항상 틀릴까

애자일과 프론트엔드 시리즈