‘2주, 약속합니다’: 우리가 고객과 자신에게 하는 거짓말

Source: Dev.to

개발자라면 “추정(estimate)”이라는 단어가 가장 싫어하는 말일 가능성이 높습니다. 엔지니어에서 점술가—대개는 형편없는 점술가—로 전환되는 순간이기 때문이죠.

제 역할은 시간 추정을 제공하는 사람이고, 동시에 실제 작업을 수행해야 하는 사람입니다. 그래서 제가 완벽한 추정가일 거라고 생각할 수도 있겠지만, 그렇지 않습니다. 오히려 토요일 새벽 3시에 아직 디버깅을 하고 있다면, 비난할 대상이 저 자신밖에 없다는 뜻이죠.

여기 추정이 악몽이 되는 이유와 그 문제를 해결할 수 있는 방법에 대한 진실이 있습니다.

Part 1: The Problems (The “Expectation vs. Reality” Gap)

1. The “I’ll Know It When I See It” Client

클라이언트가 명확한 요구사항 없이 “보면 알겠다”고 할 때 견적을 내는 것은 “뭔가 맛있는 걸 원한다”는 사람을 위해 장을 보는 것과 같다. 추측해서 사면, 그들은 당신이 고른 모든 것이 알레르기 유발 식품이라고 말한다.

• The Reality: 사양이 없으면 “간단한 로그인 페이지”가 순식간에 “소셜 인증, 2단계 인증, 비둘기로 비밀번호 재설정 메일을 보내는 ‘비밀번호 찾기’ 흐름, 그리고 다크 모드”가 포함된 페이지로 변한다.

2. The “Ideal World” Fallacy

우리는 마치 진공 상태에 사는 로봇처럼 견적을 낸다. 우리는 다음을 전제로 한다:

• API 문서는 실제로 정확하다(하지만 절대 그렇지 않다).
• 인터넷이 끊기지 않는다.
• 누락된 세미콜론 때문에 6시간을 쓰지 않는다.
• 우리 뇌는 우리가 영화 속 10배 개발자라고 생각하지만, 실제 생산성은 고양이가 키보드 위를 뛰어다니는 횟수에 좌우된다.

3. The “Life Happens” Factor

프로젝트에 40시간을 견적했지만, 다음을 잊었다:

• 다른 프로젝트를 위한 “짧은” 회의에 사용된 10시간.
• 이전 클라이언트를 위한 “긴급” 버그 수정에 한 오후 전체를 사용한 것.
• 실제로 잠을 자고, 식사하고, 가끔 가족과 대화해야 한다는 사실(그래야 가족이 당신이 어떤 모습인지 기억한다).

Part 2: The Solutions (How to Survive)

1. “애매함 세금”

요구사항이 모호하면 가격이 올라갑니다. 그게 전부입니다.

• 해결책: 클라이언트가 “검색 기능을 원한다”라고 말하고 구체적인 내용을 제시하지 않으면, 견적에 50 %를 추가하세요. 이것이 바로 “실제로 원하는 것이 무엇인지 파악해야 한다”는 세금입니다. 더 저렴하게 원한다면, 더 명확히 말해야 합니다.

2. “버퍼”는 최고의 친구

예전엔 버퍼를 넣는 것이 죄책감이 들었습니다. 마치 “거짓말”을 하는 느낌이었죠. 이제는 버퍼를 넣지 않는 것이 진짜 거짓말이라는 걸 깨달았습니다.

• 규칙: 1.5× 배수 적용. 가장 현실적이고 정직한 견적에 1.5를 곱합니다. 10 일이 걸릴 것 같다면, 15일이라고 말하세요.
• 프로 팁:
  • 12 일에 완료 → 당신은 영웅.
  • 14 일에 완료 → 아직도 일찍 끝낸 셈.
  • 10 일에 완료 → 당신은 신.

3. “비관적” 공식 사용

하나의 숫자만 제시하지 마세요. PERT(Program Evaluation and Review Technique) 공식을 사용하세요. 이 공식은 “비관적” 시나리오를 생각하게 만듭니다.

여기서:

• O = 낙관적: “첫 시도에 모두 성공한다”는 기적 (10 %).
• M = 가장 가능성 높은 경우: 현실적인 중간 지점 (70 %).
• P = 비관적: “모두 고장 나고 인터넷도 안 된다”는 재앙 (20 %).

실제로 모든 것이 잘못될 경우 소요 시간을 적어 보면, 최종값(E)은 현실에 훨씬 더 근접하게 됩니다.

4. “시계 시간” vs. “깊은 작업” 관리

8시간 근무를 기준으로 생각하지 마세요. 코딩을 8시간 연속하는 사람은 없습니다.

• 실제 수학: 하루에 고품질 “깊은 작업”을 할 수 있는 시간은 보통 4시간 정도입니다. 나머지는 이메일, 슬랙 알림, 개인 생활에 잡아먹히죠.
• 해결책: 프로젝트가 40시간 작업이라면, 이는 2주짜리 프로젝트이며 5일짜리 프로젝트가 아닙니다.

견적에서 가장 어려운 부분은 수학이 아니라, 클라이언트에게 그들의 “간단한” 아이디어가 실제로는 복잡한 프로젝트라는 사실을 말할 용기입니다. 프로젝트 시작 전에 일정에 대해 솔직히 대화하는 것이, 마감이 지나고 나서 왜 늦었는지 간절히 변명하는 것보다 훨씬 낫습니다.

다음에 “일주일이면 될 거야”라고 말하려 할 때, 숨을 크게 쉬고, 고양이를 생각한 뒤에 “3주 걸릴 거야”라고 말하세요. 미래의 당신이 고마워할 겁니다.