"한 일주일?"에서 "2.75일이면 됩니다"로

개발자로 커리어를 시작했을 때, 나는 팀의 밑바닥이었다. 목표는 하나였는데, 팀장이 신뢰하는 사람이 되는 것. 그 신뢰의 조건은 생각보다 단순했다. 아무리 사소한 업무라도 할당되면, 내가 견적을 내고 "이 정도 걸릴 것 같습니다"와 함께 티켓에 due date를 기입하는 일이었다. 의외로, 많은 사람들이 이 due date 기입 자체를 어려워했다.

AI로 생산성이 높아진 시대에도, "이 기능 추가하는데 얼마나 걸려요?"라는 질문은 여전하다. 그래서 몇 년간 시간을 재면서 배운 것들을 정리해본다.

(예시가 개발 쪽이긴 한데, 견적이라는 게 직군을 타는 주제는 아닐 거다.)

실제 일한 시간은 생각의 절반이다

뽀모도로를 처음 쓰기 시작했을 때, 하루에 12개는 하겠거니 했다. 25분 집중, 5분 휴식. 8시간이면 넉넉하지 않나.

평균 6개가 나왔다.

3시간. 8시간 근무 중 실제 집중한 시간. 적다고 느낀다면, 일주일만 직접 재보면 된다. 회의, 슬랙, 동료의 잠깐 질문, 컨텍스트 스위칭, "5분이면 된다"던 일이 40분 걸리는 것까지 — 시계 위의 1시간은 뽀모도로 1개 정도의 실제 산출물을 낸다.

하루 6뽀모도로? 괜찮게 집중한 하루다. 8개에서 10개? 한 달에 두세 번 있다. 그날 퇴근할 때는 "아, 오늘 빡세게 일했다"는 보람이 따라온다.

나머지 2시간이 낭비는 아니다. 회의도 하고, 동료랑 잡담도 하고, 커피 한 잔 내리러 가기도 하고, 일을 하기 위한 일 — 문서 정리하고, 티켓 쪼개고, 블로커 확인하고. 생산적으로 느껴지진 않지만, 이게 없으면 진짜 일이 안 돌아간다.

그래서 나는 견적을 낼 때 1일 = 6뽀모도로로 계산한다. "이거 ASAP으로 해주세요!" 하고 울고불고하면, 8뽀모도로로 계산해서 하루치를 잡는다.

견적은 예측이 아니라 순서다

시간을 재는 것보다 더 큰 전환은, 일을 순서대로 쪼개는 법을 배운 거였다.

어떤 일의 견적을 낼 때, 지금 상태에서 목표 상태까지 필요한 모든 단계를 나열한다. 순서대로. 각 단계가 얼마나 걸리는지보다, 뭐가 먼저인지가 더 중요하다.

이사를 생각하면 된다. 열쇠를 받기 전에 이삿짐 트럭을 먼저 보내버린 상황. 짐은 내려졌고, 문은 안 열리고, 비는 오고.

실무에서도 똑같은 일이 벌어진다. 새로 바뀐 화면을 먼저 배포했는데, 서버가 아직 그 데이터를 안 내려주면 유저 화면에 빈칸이 뜬다. 10분이면 고치지만, 그 10분 사이에 문의가 들어온다.

그래서 일을 쪼갤 때 내가 먼저 따지는 건 "얼마나 걸리나"가 아니라 "뭐부터 하나"다.

운영 중인 서비스에 큰 변경을 넣을 때는 특히 그렇다. 달리는 차의 바퀴를 갈아끼우는 일이라, 순서가 틀리면 되돌리기가 어렵다. 어느 시점에는 다른 팀의 액션을 기다려야 하고, 그 대기 시간도 견적의 일부다.

이 과정을 나는 초벌 굽기라고 부르는데 — 본격적인 작업 전에, 수도코드 수준으로 흐름을 한번 써본다. 실제로 돌아가는 코드가 아니라, "여기서 이걸 하고, 다음에 저걸 하고, 여기서 막힐 수 있겠다"를 글로 쓰는 정도. 30분이면 3일짜리 일인지 5일짜리 일인지가 보이기 시작한다.

(어떤 팀에서는 이 초벌이 거의 본작업이었다. 요구사항 문서의 기준이 높아서 버전이 v60까지 간 적도 있는데, 그 정도면 코드로 구현한 것과 다름이 없다. 그 팀에서는 대부분의 티켓이 "~문서 작성", "~초안 작성"으로 끝났다.)

그렇게 단련해왔음에도, 해보지 않은 영역이나 의존성이 많은 일 앞에서는 이 견적을 내는 일의 견적 자체가 만만치 않을 때가 있다. 대표님이나 PM이 "이거 얼마나 걸려요?"를 던졌는데, 솔직히 "그걸 파악하는 데 하루 걸립니다"라고 답해야 할 때.

스코프를 끊는 것도 견적이다

견적에서 가장 어려우면서 사람들이 잘 빼먹는 건, 내 손을 떠난 불확실성이다. 상대방의 피드백, 의사결정 지연, 갑자기 바뀌는 기획. 그렇다고 기한을 무한히 늘릴 수도 없으니, 어딘가에서 선을 그어야 한다.

나는 피드백 라운드에 상한을 정해둔다. 몇 차례든 프로젝트마다 다르지만, 상한 없이 가면 끝이 없다. 정한 횟수를 넘기면 나머지는 다음 버전으로 넘긴다. 오류나 중대한 전환이 아닌 이상 말이다.

견적이란 "이 일이 얼마나 걸리나"의 문제이기도 하지만, "여기까지만 한다"의 문제이기도 하다. 선을 안 그으면 견적은 의미가 없어진다. 끝이 없는 루프를 추정하는 꼴이다. 그래서 티켓을 작성할 때 not-to-dos를 최대한 적어둔다. "이건 이번에 안 합니다"를 미리 써놓으면, 나중에 "이것도 해주세요"가 왔을 때 근거가 된다.

서브태스크들을 쪼개다 보면, 중간에 불확실한 것들이 낀다. 불확실하면서 중요도도 애매한 것들. 이런 건 optional로 표시해두고, 해보고 안 되면 스킵하는 식으로 견적에 넣는다. not-to-do까지는 아닌데, 반드시 해야 하는 것도 아닌 회색 지대. 이걸 미리 표시해두면, 일이 밀렸을 때 뭘 먼저 빼야 하는지가 바로 보인다.

이 optional들은 적극적으로 논의할 필요가 있다. 특히 기한이 확정이고 드라이브가 확실한 프로젝트일수록 효과적이다. 다만 사일로가 심한 조직에서는 어렵고, 어느 정도 개방된 커뮤니케이션이 깔려 있어야 한다.

그리고 여기서 신뢰가 갈린다. optional이라고 "아싸, 안 해도 되네"가 아니라, feasibility를 확인해보고, 다른 작업하면서 같이 쉽게 되는 거면 서비스로 넣어주는 것. 그렇게 하면 보내는 쪽에서도 요구사항을 성심껏 레이어링해서(required/optional) 보내준다. 선순환이다.

그렇다고 견적을 늘 잘 냈던 건 아니다. 안 해본 영역은 곧 불확실성이고, 버퍼는 커진다. 나는 따로 1인 개발을 하고 싶어서 사이드 프로젝트를 많이 만들었는데, 결과적으로 그게 서브태스크 단위의 경험치가 됐다. (통신판매업 신고를 개인으로 해봤더니, 회사에서 같은 일이 왔을 때 견적이 바로 나왔다.) 새 회사, 새 도메인이더라도 해본 일이 많아지니 견적이 꽤 정확해졌다.

그런데 AI가 단위를 바꿔버렸다

요즘은 뽀모도로를 거의 쓰지 않는다. 방법이 안 먹혀서가 아니라, 세션이 너무 짧아졌기 때문이다. 25분짜리 블록을 채우던 작업이 7분이면 끝난다. 짧게는 몇 초짜리 확인도 있고, 길어도 25분을 넘기는 일이 드물다. 단위가 안 맞는다.

더 달라진 건 일의 모양 자체다. AI한테 여러 일을 걸어두고, 돌아와서 결과를 확인하고, 다시 걸어둔다. 병렬로 돌아가는 건 AI 쪽이지, 나는 여전히 한 번에 하나밖에 못 본다. AI가 한 일을 검토하는 것 자체가 할 일이 되고, 일이 더 되긴 하는데, 그만큼 밀도 높은 날은 육체적으로 피곤하다. 집중해서 일할 때와는 다른 결의 피로다.

몇 년을 들여서 내 시간을 측정하고, 견적을 정직하게 내는 법을 익혔다. 풀타임 개발자로서뿐 아니라, 단기 외주 프로젝트와 사이드 프로젝트 전부에서. 그런데 지금은 그 단위 자체가 흔들리고 있고, 뽀모도로를 대체할 무언가를 — 타이머가 아니라, 하루를 가늠하는 척도를 — 아직 찾고 있다.

그리고 더 근본적인 변화 — 견적을 묻는 사람, 환경 자체가 줄고 있다.