개발 기간은 왜 항상 늦어질까? - 일정 산정의 비밀

"2주면 되죠?"

비개발자 대표님들이 가장 많이 하는 질문입니다.

 

"로그인 기능 추가하는 거, 2주면 되죠?"

 

"결제 시스템 붙이는 거, 1주일이면 충분하지 않나요?"

 

"이거 그냥 버튼 하나 추가하는 건데, 하루면 되는 거 아닌가요?"

 

그리고 개발자는 난처한 표정으로 대답합니다.

"음... 최소 한 달은 봐야 할 것 같은데요."

 

대표님은 속으로 생각합니다. '개발자들은 왜 항상 일정을 길게 잡을까? 여유부리는 건가?'

 

개발자도 속으로 생각합니다. '대표님은 왜 항상 일정을 짧게 생각하실까? 개발이 뭔지 모르시나?'

 

이 간극이 스타트업의 가장 큰 갈등 중 하나입니다.

개발은 빙산이다

한 대표님이 실제로 했던 말입니다.

 

"로그인 기능이요? 네이버도 있고, 카카오도 있고, 구글도 있잖아요. 그냥 복붙하면 되는 거 아닌가요?"

 

그 대표님이 본 것은 로그인 화면 하나였습니다. 하지만 개발자가 본 것은:

• OAuth 2.0 인증 구현
• 사용자 세션 관리
• 토큰 갱신 로직
• 보안 취약점 대응
• 에러 핸들링
• 다중 소셜 로그인 통합
• 데이터베이스 스키마 설계
• API 엔드포인트 구현
• 프론트엔드 상태 관리
• 테스트 코드 작성
• 문서화

눈에 보이는 건 빙산의 일각입니다. 실제 작업은 수면 아래 90%에 숨어 있습니다.

왜 항상 늦어질까? - 7가지 이유

이유 1: 요구사항이 애매하다

"소셜 로그인 기능을 만들어주세요."

 

개발자 입장에서는 질문이 100개 생깁니다.

• 어떤 소셜 로그인? 카카오? 네이버? 구글? 애플? 다?
• 기존 회원이 소셜 로그인하면 계정 통합? 별도 계정?
• 이메일 없는 사용자는 어떻게 처리?
• 소셜 계정 연동 해제 기능도 필요?
• 한 사용자가 여러 소셜 계정 연동 가능?

이런 질문들이 명확하지 않으면, 개발하다가 막힙니다. 그리고 대표님께 다시 물어보고, 답변 기다리고, 수정하고... 일정은 늘어납니다.

 

한 스타트업은 "간단한 검색 기능"을 요청했습니다. 개발자가 2주 걸린다고 했고, 대표는 3일이면 된다고 했습니다.

 

알고 보니 대표가 원한 건:

• 자동완성
• 오타 교정
• 동의어 검색
• 검색 기록 저장
• 인기 검색어
• 필터링

"간단한 검색"이라는 말 속에 이 모든 게 들어있었습니다. 결국 한 달이 걸렸습니다.

이유 2: 기술 부채가 쌓여있다

"버튼 하나 추가하는 데 왜 일주일이나 걸려요?"

 

겉보기엔 버튼 하나지만, 그 버튼을 누르면:

• 레거시 코드와 충돌
• 기존 API 구조가 맞지 않아서 수정 필요
• 데이터베이스 스키마 변경 필요
• 다른 기능들과의 연동 확인
• 예전에 임시로 만든 코드 리팩토링

새 집에 방 하나 추가하는 건 쉽습니다. 하지만 30년 된 낡은 집에 방을 추가하려면? 기초부터 다시 봐야 합니다.

 

어떤 회사는 "간단한 알림 기능" 추가에 3개월이 걸렸습니다. 알고 보니 알림 시스템 자체가 없어서 전체 인프라를 새로 구축해야 했습니다.

이유 3: 예상하지 못한 문제가 생긴다

개발자의 하루:

오전 9시: "오늘은 로그인 기능 완성한다!"
오전 10시: 테스트해보니 iOS에서만 버그 발생
오전 11시: 버그 원인 찾느라 스택오버플로우 검색
오후 12시: 원인 발견. 외부 라이브러리 버전 문제
오후 1시: 점심
오후 2시: 라이브러리 업데이트하니 다른 기능이 깨짐
오후 3시: 깨진 기능 고치느라 코드 수정
오후 4시: 테스트 중 새로운 버그 발견
오후 5시: 긴급 회의 - 서버 다운 이슈
오후 7시: 서버 복구 완료, 다시 로그인 기능 작업
오후 9시: 70% 완성... 내일 이어서

 

계획대로 되는 날이 거의 없습니다. 소프트웨어는 살아있는 생명체처럼 예측 불가능합니다.

이유 4: 테스트와 버그 수정을 빼먹는다

많은 비개발자 대표님들은 "코딩 = 개발"이라고 생각합니다.

하지만 실제 개발 시간 배분은:

• 코딩: 30%
• 테스트: 20%
• 버그 수정: 25%
• 코드 리뷰: 10%
• 문서화: 10%
• 회의 및 커뮤니케이션: 5%

"2주면 코딩 끝나요"라는 말은 "2주면 첫 번째 버전이 나와요"라는 뜻입니다. 그 다음 2주는 고치는 시간입니다.

 

한 회사는 "거의 다 됐어요, 90% 완성이에요"라는 말을 한 달 내내 들었습니다. 나중에 알고 보니 마지막 10%에 버그 수정과 예외 처리가 몰려있었습니다.

이유 5: 외부 의존성이 있다

"결제 시스템 붙이는 거 하루면 되죠?"

 

이론상으로는 맞습니다. PG사 API 문서 보고 연동하면 하루 컷입니다.

 

현실은:

• PG사 심사 신청: 3~5 영업일
• 서류 보완 요청: 2~3일
• 테스트 계정 발급 대기: 2일
• 실제 연동 작업: 1일
• 테스트 중 API 오류 발견, PG사 문의: 3일
• 본인 인증 추가 요청: 2일
• 최종 검수: 2일

총 2~3주가 걸립니다. 그것도 순조롭게 진행됐을 때입니다.

 

외부 API, 제3자 서비스, 법적 심사, 보안 검토... 개발자가 컨트롤할 수 없는 영역이 의외로 많습니다.

이유 6: 개발자도 사람이다

어떤 대표님은 이렇게 말씀하셨습니다.

 

"개발자가 하루 8시간 일하면, 8시간 내내 코딩하는 거 아닌가요?"

 

현실의 개발자 하루:

• 9:00-9:30: 이메일 확인, 슬랙 메시지 읽기
• 9:30-10:00: 데일리 스탠드업 미팅
• 10:00-12:00: 코딩 (집중)
• 12:00-1:00: 점심
• 1:00-2:00: 어제 코드 리뷰 피드백 반영
• 2:00-3:00: 코딩
• 3:00-3:30: 갑자기 생긴 버그 수정
• 3:30-4:00: 대표님과 기획 미팅
• 4:00-5:00: 코딩
• 5:00-5:30: 동료 코드 리뷰
• 5:30-6:00: 내일 할 일 정리

실제 코딩 시간: 4~5시간

 

개발자는 코딩 기계가 아닙니다. 생각하고, 고민하고, 소통하고, 학습하는 데도 시간이 필요합니다.

이유 7: 처음 해보는 일이다

"이거 비슷한 거 전에 만들어봤죠? 그럼 빠르게 할 수 있겠네요?"

 

개발에서 "비슷한 것"은 없습니다. 모든 프로젝트는 다릅니다.

• 전에는 React였는데 이번엔 Vue
• 전에는 소규모였는데 이번엔 대용량 트래픽
• 전에는 B2C였는데 이번엔 B2B
• 전에는 모바일 앱이었는데 이번엔 웹

매번 새로 배우고, 새로 시도하고, 새로 실수합니다. 그게 개발입니다.

일정 산정, 개발자도 어렵다

그렇다면 개발자는 정확히 일정을 예측할 수 있을까요?

 

아닙니다. 개발자도 어렵습니다.

 

유명한 "호프스태터의 법칙"이 있습니다:

"일은 항상 예상보다 오래 걸린다. 이 법칙을 고려하더라도."

 

베테랑 개발자들도 일정 산정을 틀립니다. 왜냐하면:

• 낙관 편향: "이번엔 문제없을 거야"
• 미지의 미지: 모르는 게 있다는 것도 모름
• 범위 확장: 만들다 보면 더 좋은 아이디어가 떠오름
• 완벽주의: "이 정도면 되겠지" → "좀 더 개선하자"

실리콘밸리에서는 이런 말이 있습니다.

 

"개발자가 2주 걸린다고 하면, 4주로 잡아라."

 

"4주로 잡으면, 8주 걸린다."

그래서 어떻게 해야 할까?

1. 요구사항을 구체화하라

"소셜 로그인 만들어주세요" (X)

 

"카카오, 구글 소셜 로그인을 만들어주세요. 기존 이메일 회원과는 별도 계정으로 관리하고, 프로필 사진과 이름만 가져옵니다. 계정 연동 해제 기능은 v2에서 추가합니다." (O)

 

구체적일수록 일정이 정확해집니다.

2. MVP를 정의하라

"완벽한 검색 기능" (X)

 

"일단 제목만 검색되고, 정확히 일치하는 것만 나오는 버전을 먼저 만듭시다. 자동완성과 오타 교정은 나중에." (O)

 

최소 기능부터 시작하면 빠르게 출시하고 개선할 수 있습니다.

3. 버퍼를 두어라

개발자: "2주 걸립니다."

 

대표: "그럼 3주로 잡겠습니다."

 

이게 현명한 대표입니다. 일정에 30~50% 버퍼를 두세요. 그래야 일정을 맞출 수 있습니다.

4. 단계별로 쪼개라

"회원 관리 시스템 만들기 - 4주" (X)

 

"1주: 회원가입/로그인
2주: 프로필 수정
3주: 비밀번호 찾기
4주: 관리자 페이지" (O)

 

큰 덩어리를 작은 단위로 쪼개면, 진행 상황을 파악하기 쉽습니다.

5. 우선순위를 정하라

모든 기능을 동시에 빠르게 만들 수는 없습니다.

 

"이번 달에 꼭 필요한 기능 3개만 골라주세요."

 

선택과 집중이 답입니다.

6. 기술 부채 상환 시간을 주어라

"이번 스프린트는 새 기능 말고, 리팩토링에 쓰겠습니다."

 

개발자가 이런 말을 하면, 허락해주세요. 지금 투자하지 않으면 나중에 더 큰 대가를 치릅니다.

 

한 스타트업은 1년간 신규 기능만 만들다가, 시스템이 너무 복잡해져서 3개월간 리팩토링만 했습니다. 매출은 멈췄지만, 그렇게 하지 않으면 회사가 망할 상황이었습니다.

7. 커뮤니케이션을 자주 하라

"2주 뒤에 완성본 보여드릴게요" (X)

 

"매일 30분씩 진행 상황 공유할게요" (O)

 

문제는 초기에 발견할수록 고치기 쉽습니다. 2주 후에 "원하시던 거랑 달라요"라는 말을 듣는 것보다, 3일차에 방향을 수정하는 게 훨씬 낫습니다.

대표님께 드리는 현실적인 조언

개발자를 재촉하지 마세요

"더 빨리 할 수 없나요?"

 

이 질문은 도움이 되지 않습니다. 오히려 개발자는:

• 테스트를 건너뜁니다
• 버그가 많은 코드를 만듭니다
• 기술 부채를 쌓습니다
• 번아웃이 옵니다

결과적으로 장기적인 속도가 더 느려집니다.

대신 이렇게 물어보세요

"어떻게 하면 더 빨리 출시할 수 있을까요?"

 

이 질문은 다릅니다. 개발자는 이렇게 답할 수 있습니다:

 

"A 기능을 빼면 2주 줄일 수 있어요."

 

"외부 라이브러리를 쓰면 3주 단축 가능해요."

 

"디자인을 간소화하면 1주 절약할 수 있어요."

 

함께 해결책을 찾는 겁니다.

정말 급하면 범위를 줄이세요

일정은 세 가지로 결정됩니다:

• 범위 (얼마나 많은 기능)
• 품질 (얼마나 완벽한가)
• 시간 (언제까지)

세 가지를 모두 잡을 수는 없습니다. 하나를 선택해야 합니다.

 

빠르게 출시하고 싶다면:

• 기능을 줄이거나 (범위 축소)
• 완벽함을 포기하거나 (품질 저하)

둘 중 하나입니다.

개발자에게도 할 말이 있다

개발자분들도 이 글을 읽고 계신다면, 여러분도 반성할 부분이 있습니다.

명확하게 설명하세요

"기술적으로 복잡해서 오래 걸려요" (X)

 

"외부 API 연동에 1주, 데이터 마이그레이션에 3일, 테스트에 3일 필요합니다" (O)

 

비개발자도 이해할 수 있게 쪼개서 설명하세요.

대안을 제시하세요

"4주 걸립니다" (X)

 

"완벽한 버전은 4주 걸립니다. 하지만 핵심 기능만 있는 버전은 2주 만에 만들 수 있어요. 어떤 게 좋을까요?" (O)

 

선택지를 주세요.

리스크를 미리 말하세요

"아마 2주면 될 거예요"
→ 3주 후: "예상보다 복잡해서 1주 더 걸립니다" (X)

 

"2주 걸릴 것 같은데, 외부 API 문서가 불완전해서 막히면 3주까지 걸릴 수 있어요" (O)

 

불확실성을 솔직하게 공유하세요.

결국 신뢰의 문제

왜 개발 일정이 항상 늦어질까요?

 

기술적인 이유도 있지만, 근본적으로는 기대의 차이 때문입니다.

 

대표는 "빠르게"를 원하고, 개발자는 "제대로"를 원합니다. 이 둘 사이의 균형점을 찾는 게 중요합니다.

 

그 균형점은 신뢰에서 나옵니다.

 

개발자가 "한 달 걸린다"고 하면, 정말 그럴 만한 이유가 있습니다. 대표가 "이번 주까지 필요하다"고 하면, 정말 그만큼 급한 겁니다.

 

서로의 입장을 이해하고, 솔직하게 소통하고, 함께 해결책을 찾으세요.

 

일정은 맞추는 것도 중요하지만, 팀이 망가지지 않는 것이 더 중요합니다.

 

개발이 늦어지는 건 회복할 수 있습니다. 하지만 신뢰가 깨지면 회복하기 어렵습니다.

---

이 글은 '모두의 CTO' 시리즈의 아홉 번째 글입니다. 다음 글은 이번 시리즈의 마지막, "개발자가 싫어하는 대표의 5가지 습관"에 대해 다루겠습니다.