일정 2배로 불러도 야근하는 이유

소프트웨어 개발에서 일정 예측은 영원한 숙제입니다. 정확한 예측은 사실상 불가능하지만, 예측의 정확도를 높이는 방법은 있습니다.

관리자는 일정을 원합니다

관리자가 "언제 끝나요?"라고 물을 때, 그것은 단순한 호기심이 아닙니다. 언제 끝나는지 알아야 다음 일을 계획할 수 있기 때문입니다.

이것은 관리자의 잘못이 아닙니다. 사업에서는 생존과 직결되는 필수적인 정보입니다. 마케팅 일정, 영업 약속, 파트너십 계약 등 많은 것들이 개발 일정에 연동되어 있습니다.

개발자로서 우리는 이 요구를 이해하고 협력해야 합니다. 문제는 "예측을 하지 않는 것"이 아니라 "어떻게 더 나은 예측을 할 것인가"입니다.

빨리 대답하고 싶은 욕심을 버리세요

유능한 사람으로 보이고 싶거나, 부족한 모습을 드러내고 싶지 않아서 해야 할 일을 정확히 파악하지 않고 일정을 빠르게 확정 짓지 마세요. 완료 일정을 최대한 빨리 알려주는 것보다 약속한 기한 내에, 또는 조금 더 빨리 일을 완료시키는 게 더 신뢰를 얻는 길입니다.

저도 커리어 초반에 종종 이런 실수를 저질렀습니다. 결국 밤늦게까지 일하는 날들이 많았습니다. 인정받고 싶은 욕망으로 똑같은 실수를 저지르기도 했죠.

관리자는 그럼에도 즉시 일정을 바랄 수도 있습니다. 그때 무조건 입을 다물기보다는 이렇게 해보는 걸 권장합니다. "X와 Y, Z의 불확실성이 해소되면 XX일 걸릴 것이지만, 그렇지 않은 경우 더 길어질 수 있습니다. 불확실성이 있는 A, B 기능을 제외하면 XX일 걸릴 것 같습니다." 이 답변은 당신이 최대한 일정을 알려주려고 하고 있고, 불확실성을 줄이려 노력하고 있다는 것을 보여주는 태도입니다.

흔히 실패하는 일정 추산 방법

많은 팀들이 다음과 같은 방법으로 일정을 추산하지만, 대부분 실패합니다.

1. 화면 단위 합산법

화면별로 N일씩 잡고 모두 합산하는 방식입니다. 문제는 화면 간 연동 로직, 공통 컴포넌트 개발, API 통합 등의 시간이 누락된다는 것입니다. 또한 화면마다 복잡도가 다른데 일률적으로 계산하면 오차가 커집니다.

UI와 API 통합이 완료된 화면을 "완료"라고 가정한다면, 한 엔지니어가 소위 풀스택 개발을 하지 않는 이상 정확한 추정은 힘듭니다. 많은 경험에서 느낀 건, API의 불완전성이 프론트엔드에서의 더 많은 작업을 야기하거나, 프론트엔드에서의 잘못된 API 통합으로 인해 추가적인 디버깅 비용을 만들기도 합니다.

여기서 끝이 아닙니다. 디자이너와의 의견 충돌로 UI를 다시 수정해야 할 수도 있고, 개발 막바지에 보안 이슈나 인프라 문제가 터질 수도 있습니다. 화면 단위 추산은 이런 협업 과정에서 발생하는 변수들을 전혀 반영하지 못합니다.

2. 시니어 의존법

경험 많은 시니어 엔지니어에게 물어보는 방식입니다. 많은 경우에 그들은 매우 바쁜 상황에서 일하고 있습니다. 제품에 대한 문서와 관련 맥락을 모두 이해할 시간이 없습니다. 이 가운데 추산한 일정은 틀릴 가능성이 높습니다. 처음부터 의존하기 보다는 직접 추산을 시도하고왜 이렇게 추산했는지 추산 과정에 대한 조언을 받는 것이 더 낫습니다.

3. 버퍼 추가법

예측 불가능성을 위해 20% 버퍼를 추가하거나, 아예 2배로 잡는 방식입니다. 근거 없는 버퍼는 정확도를 높이지 못합니다. 문제의 본질을 해결하지 않고 숫자만 늘리는 것이기 때문입니다. 특히 초반 추산에서 버퍼를 너무 많이 잡으면 추후 일정 조율에서 문제가 발생할 수 있습니다.

스크럼 포커가 도움이 될까?

스크럼 포커(Planning Poker)는 팀원들이 각자 작업량을 추정하고, 차이가 있으면 토론하는 방식입니다. 많은 애자일 팀에서 사용하지만, 한계가 있습니다.

한계점

• 요구사항의 불완전함: 정확한 요구사항은 관리자만이 알고 있는 경우가 많습니다. 문서나 화면으로 모든 것을 담지는 못하죠. 엔지니어끼리 추산한 일정이 실제와 맞을까요?
• 역량 차이: 개인별 역량 차이가 있습니다. 그리고 서로의 역량을 완전히 알기 어렵습니다. 시니어 엔지니어가 5일을 이야기했다고 해도 주니어에게는 10일이 필요할 수 있습니다.
• 숫자의 의미: 지식 공유 차원에서는 도움이 되지만, 다른 사람이 제시한 숫자가 정확하다고 말하기 어렵습니다.

그래도 장점은 있습니다

스크럼 포커는 작업에 대한 동일한 이해도를 가지는 데는 도움이 됩니다. "이 작업이 왜 복잡한지"에 대한 토론이 이루어지기 때문입니다.

다만, 스크럼 포커 자체도 비용이 듭니다. 구성원들의 시간과 집중력이 필요합니다. 매번 모든 작업에 스크럼 포커를 하는 것이 효율적인지는 팀 상황에 따라 다릅니다.

개발 일정 예측을 어렵게 만드는 요소들

일정 예측이 어려운 근본적인 이유가 있습니다.

1. 외부 의존성

외부 API, 서드파티 라이브러리, 다른 팀의 작업에 의존하는 경우입니다. 외부 API가 예상대로 동작하지 않거나, 문서화가 부족하거나, 응답 속도가 느릴 수 있습니다. 이런 변수들은 예측하기 어렵습니다.

2. 구체화되지 않은 요구사항

"알아서 예쁘게 해주세요", "사용자 친화적으로 만들어주세요" 같은 요구사항은 해석의 여지가 너무 많습니다. 개발을 시작한 후에야 "이건 아닌데..."라는 피드백이 올 수 있고, 그때마다 방향을 수정해야 합니다.

3. 다른 작업의 인터럽트

긴급 버그 수정, 예정에 없던 회의, 동료의 코드 리뷰 요청 등 계획에 없던 작업들이 끼어듭니다. 하루 8시간 중 실제로 집중해서 코딩하는 시간은 얼마나 될까요?

예측 불가능성을 최소화하기

완벽한 예측은 불가능하지만, 불확실성을 줄이는 것은 가능합니다.

1. 외부 의존성 줄이기

• 안정된 라이브러리 선택: 새롭고 화려한 것보다 검증된 것을 선택합니다.
• 간단한 기능은 직접 구현: AI를 활용하면 간단한 유틸리티는 빠르게 만들 수 있습니다. 외부 의존성을 추가하는 것보다 나을 수 있습니다.
• 외부 팀과의 인터페이스 조기 합의: API 스펙, 데이터 형식 등을 미리 합의하면 나중에 발생할 변수를 줄일 수 있습니다.

2. 요구사항을 최대한 구체화하기

• 프로토타입 활용: 개발 없이 프로토타입으로 먼저 검증합니다. Figma나 AI 도구를 활용하면 클릭하면 다음 화면으로 넘어가는 수준의 프로토타입을 빠르게 만들 수 있습니다.
• 엣지 케이스 사전 정의: "입력값이 비어있으면?", "네트워크가 끊기면?", "동시에 여러 번 클릭하면?" 같은 질문들을 미리 정리합니다.
• "이런 경우에는?" 질문 미리 정리: 개발을 시작하기 전에 애매한 부분을 질문 목록으로 만들어 확인받습니다.

3. 업무 집중 환경 만들기

• 여러 업무 병렬 진행 지양: 컨텍스트 스위칭 비용은 생각보다 큽니다. 하나에 집중하는 것이 전체적으로 더 빠릅니다.
• 명확한 우선순위 설정: 무엇이 가장 중요한지 명확해야 인터럽트에 대응할 수 있습니다.
• 선택과 집중, 필요시 위임: 모든 것을 혼자 하려고 하지 말고, 위임할 수 있는 것은 위임합니다.

4. 큰 프로젝트는 여러 작은 프로젝트로 쪼개기

2주에서 1개월 정도가 하나의 스프린트로 적절한 수준입니다. 너무 긴 기간은 집중력을 떨어뜨리고 피로도가 쌓이게 합니다. 팀의 컨디션도 퍼포먼스에 영향을 미칩니다.

작은 단위로 나누면 이전 스프린트에서의 경험을 발판으로 다음 추산의 정확도가 올라갑니다. 한 번에 6개월짜리 프로젝트를 추산하는 것보다, 2주짜리 스프린트를 여러 번 거치면서 보정하는 게 훨씬 현실적입니다.

요약

개발 일정의 정확한 예측은 불가능합니다. 하지만 불확실성을 줄이는 것은 가능합니다.

• 빠른 대답보다 정확한 대답: 유능해 보이려고 급하게 일정을 확정짓지 마세요. 불확실한 부분을 명시하며 답하는 것이 신뢰를 얻는 방법입니다.
• 흔한 실수 피하기: 화면 단위 합산, 시니어 의존, 근거 없는 버퍼 추가는 예측 정확도를 높이지 못합니다.
• 불확실성의 원인 파악: 외부 의존성, 모호한 요구사항, 업무 인터럽트가 일정을 틀어지게 만드는 주요 원인입니다.
• 작은 단위로 쪼개기: 6개월짜리 프로젝트를 한 번에 추산하기보다, 2주 스프린트를 반복하며 보정하는 것이 현실적입니다.

일정은 약속이 아니라 현재 상황에서의 최선의 추정치입니다. 관리자와 개발자가 함께 불확실성을 인정하고 관리하려는 자세가 중요합니다.