📊 개발자의 업무 추정, 사실은 정치다

 

소프트웨어 업계의 공공연한 비밀

여러분, 혹시 프로젝트 일정 산정할 때 개발자들이 왜 그렇게 난색을 표하는지 궁금하신 적 있으세요? 사실 이 업계에는 모두가 알지만 아무도 말하지 않는 비밀이 하나 있거든요. 바로 "소프트웨어 개발 기간을 정확하게 예측하는 건 불가능하다"는 거예요.

물론 표면적으로는 다들 이렇게 말하죠. "숙련된 개발팀이라면 충분한 시간을 들여 얼마나 걸릴지 예측할 수 있고, 그러면 회사가 좋은 비즈니스 계획을 세울 수 있다." 하지만 이건 일종의 정중한 거짓말이에요. 경험 많은 개발자들은 모두 알아요. 정확한 추정은 애초에 불가능하다는 걸요.

그래서 많은 개발팀이 시간 대신 티셔츠 사이즈로 업무를 추정하잖아요. S, M, L, XL 이런 식으로요. 개발자들한테는 직접적인 시간 단위를 말하는 게 너무 우스꽝스럽게 느껴지니까요. 하지만 웃긴 건 이 사이즈들이 경영진에게 올라가는 순간 바로 시간과 일수로 바뀐다는 거예요.

왜 정확한 추정이 불가능할까

이유는 간단해요. 소프트웨어 개발의 대부분은 사실 "연구"에 가깝거든요. 기존 코드를 살펴보고, 시스템을 충분히 이해하고, 변경사항의 영향을 파악하는 과정이죠. 아주 작은 변경사항이라도 실제로 코드를 들여다보기 전까지는 정확히 무엇을 해야 할지 알 수 없어요.

물론 아주 간단한 작업은 예측 가능해요. 예를 들어 링크 텍스트 하나 바꾸는 작업이라면 45분 정도로 추정할 수 있죠. 변경하는 데 5분, CI 기다리는 데 10분, 배포하는 데 30분. 이 정도는 예측이 되거든요.

하지만 대부분의 실제 업무는 이렇게 단순하지 않아요. 최근 가트너 조사에 따르면 기업 소프트웨어 프로젝트의 약 70% 이상이 초기 일정을 초과하는 것으로 나타났어요. 그리고 프로젝트 시간의 약 90%는 예상하지 못했던 문제를 해결하는 데 쓰인다고 해요. 바로 이 "알 수 없는 부분"이 문제인 거죠.

추정은 사실 개발자가 하는 게 아니다

충격적인 이야기일 수 있는데요, 사실 업무 추정은 개발자를 위한 게 아니에요. 오히려 매니저들이 서로 협상하고 프로젝트 우선순위를 정하는 데 쓰는 정치적 도구에 가까워요.

제 경력 중 가장 생산적이었던 시기들을 돌이켜보면, 사실 추정을 전혀 하지 않았던 팀에서 일할 때였거든요. 반드시 해야 하는 프로젝트라서 일정이 의미 없었거나, 계속 개선하면서 가치를 만들어내는 프로젝트라서 언제 끝날지 정할 필요가 없었던 경우였죠.

실제로 어떤 일이 벌어지는지 말씀드릴게요. 개발팀이 어떤 임원이 원하는 프로젝트에 대해 긴 일정을 제시하면, 그걸 줄이라는 압력을 받게 돼요. 반대로 별로 중요하지 않은 프로젝트나 미래의 예상치 못한 업무를 위한 여유 공간을 확보하려는 프로젝트의 일정이 너무 짧으면, 늘리라는 요청을 받거나 매니저가 알아서 30% 버퍼를 추가하죠.

예외가 있다면 기술적으로 정말 불가능한 프로젝트일 때예요. 매니저가 계속해서 "올바른" 추정치를 받아내는 데 실패하면, 그게 위로 신호를 보내는 거죠. 이 일은 정말 못 하겠다는 신호요.

추정이 업무를 정의한다

일반적으로는 이렇게 생각하죠. 먼저 해야 할 소프트웨어 작업이 정해지고, 그다음 그게 얼마나 걸릴지 파악한다고요. 하지만 실제로는 정반대로 진행돼요. 일정이 먼저 정해지고, 그다음에 그 일정 안에 맞출 수 있는 작업을 찾아내는 거예요.

예를 들어볼게요. LLM 챗봇을 만들고 있는데 디렉터가 "PDF와 대화하기" 기능을 원한다고 해봐요. 6개월이 주어진다면 완벽한 파일 업로드 시스템, PDF를 청크로 나눠 임베딩하는 파이프라인, PDF 페이지를 이미지로 추출해서 서식과 다이어그램을 캡처하는 기능 등을 구현할 수 있을 거예요.

하지만 하루밖에 없다면요? 당연히 더 간단한 방법을 찾게 되죠. 클라이언트에서 PDF를 텍스트로 변환해서 전체를 LLM 컨텍스트에 넣거나, 단순한 텍스트 검색 도구를 제공하는 식으로요. 소프트웨어 문제를 해결하는 방법은 항상 여러 가지가 있고, 개발자들은 어떻게 해낼지 결정할 재량권이 꽤 많거든요.

스탠디시 그룹의 카오스 리포트에 따르면 IT 프로젝트의 단 29%만이 성공적으로 완료되고, 52%는 일정이나 예산 초과로 어려움을 겪는다고 해요. 이런 현실에서 개발자들은 주어진 시간에 맞춰 가능한 범위를 찾는 데 익숙해질 수밖에 없는 거죠.

실무에서 실제로 추정하는 방법

그럼 저는 어떻게 추정할까요? 먼저 코드를 보기도 전에 최대한 많은 정치적 맥락을 파악해요. 이 프로젝트에 얼마나 압박이 있는지, 가벼운 요청인지 아니면 반드시 해야 하는 건지, 제 상위 관리 라인에서 어떤 추정치를 원하는지 말이에요. "CTO가 정말 일주일 안에 원한다"와 "팀 업무를 찾다가 이게 맞을 것 같아서"는 완전히 다르거든요.

이상적으로는 이미 추정치를 머릿속에 가지고 코드를 보러 가요. "이걸 하는 데 얼마나 걸릴까"가 아니라 "일주일 안에 어떤 접근법이 가능할까"를 묻는 거죠.

그리고 알려진 것보다 알려지지 않은 것에 더 많은 시간을 들여요. 앞서 말했듯이 알 수 없는 업무가 항상 소프트웨어 프로젝트를 지배하니까요. 이 기능이 건드려야 하는 코드베이스의 "어두운 숲"이 많을수록 추정치는 높아지죠.

구체적인 수치가 아닌 위험 평가로 답한다

저는 절대 "이건 4주짜리 프로젝트예요"라고 말하지 않아요. 대신 이렇게 말하죠. "일주일 안에 이걸 끝낼 수 있을 것 같지 않은데, 왜냐하면 X, Y, Z가 모두 잘 풀려야 하는데 그중 최소한 하나는 예상보다 훨씬 더 오래 걸릴 게 분명하거든요."

가능하면 여러 계획을 가지고 돌아가요. 하나만이 아니라요. 예를 들면 이런 식이에요.

첫째, X, Y, Z를 직접 다루는 방법이 있어요. 모든 게 순조롭게 진행되면 좋지만, 꼬이면 한 달은 걸릴 수 있어요.

둘째, Y와 Z를 완전히 우회하는 방법도 있어요. 이건 다른 위험을 가져오지만 마감 기한을 맞출 수 있을 거예요.

셋째, X와 Y에 더 익숙한 다른 팀의 도움을 받으면 저희는 Z에만 집중할 수 있어요.

즉, 저는 "얼마나 걸릴지 파악하기 위해 작업을 세분화"하지 않아요. 제 경영진은 이미 얼마나 걸리길 원하는지 알고 있거든요. 제 일은 그 추정치에 맞는 소프트웨어 접근법의 집합을 찾아내는 거예요.

불가능한 것을 말할 수 있는 신뢰

물론 때로는 그 집합이 비어 있을 수도 있어요. 어떻게 잘라봐도 프로젝트가 불가능한 경우죠. 그럴 땐 경영진이 모여서 요구사항을 바꿀 방법을 찾아야 해요.

하지만 제가 항상 "이건 불가능해요"라고 말한다면, 제 매니저들은 추정을 해줄 다른 사람을 찾을 거예요. 제가 그렇게 말할 수 있는 건, 평소에 실용적인 추정을 해서 쌓아온 신뢰의 우물이 있기 때문이에요.

맥킨지의 최근 연구에 따르면 IT 프로젝트의 약 45%가 예산을 초과하고, 17%는 너무 실패해서 회사의 존재 자체를 위협할 수 있다고 해요. 이런 상황에서 현실적이면서도 정직한 추정은 정말 중요한 능력이거든요.

반론에 대한 답변

많은 개발자들이 이런 접근 방식을 못마땅해할 거예요. 불확실한 상황에서 추정하는 걸 싫어해서, 모든 알 수 없는 질문에 미리 답을 얻어야 한다고 주장하죠. 하지만 저는 그게 비겁하다고 생각해요. 추정을 거부하면 결국 덜 기술적인 누군가가 대신 추정하게 되거든요.

어떤 개발자들은 자기 일이 끊임없이 경영진에 맞서는 거라고 생각하고, 매니저를 돕는 기술적 타협안을 찾는 게 신성한 개발자 신뢰를 배신하는 거라고 여겨요. 그렇게 커리어를 보내고 싶다면 괜찮지만, 저는 개인적으로 매니저들과 함께 일할 방법을 찾는 게 더 보람 있다고 생각해요. 제 매니저들은 거의 대부분 좋은 사람들이었거든요.

또 어떤 분들은 디렉터나 임원들로부터 추정치를 바꾸라는 압력을 거의 느껴본 적이 없고, 이건 그냥 역기능적인 조직의 신호라고 말할 수도 있어요. 그럴 수도 있죠. 하지만 제 생각엔 그런 분들은 압력이 별로 없는 "스포트라이트 밖"에서 일하는 거예요. 그것도 나쁘지 않아요. 하지만 실제로 이런 압력을 느끼는 개발자들에게 도움이 되는 조언을 할 자격이 있다고는 생각하지 않아요.

핵심은 맥락을 이해하는 것

결국 소프트웨어 추정은 대부분의 사람들이 생각하는 것과 다르게 작동해요. 매니저가 기술 프로젝트를 제안하고, 팀이 모여서 얼마나 걸릴지 파악하고, 그 정보로 매니저가 인력과 계획 결정을 내리는 게 아니에요.

실제로는 정반대예요. 매니저가 이미 추정치를 가지고 팀에 오고(비록 그걸 인정하지 않을 수도 있지만), 팀은 그 추정치 안에서 가능한 기술 프로젝트가 무엇인지 찾아내야 하는 거죠.

왜냐하면 추정은 개발팀이 만들거나 개발팀을 위한 게 아니기 때문이에요. 매니저들이 계획된 업무에 대해 서로 협상하는 데 사용하는 도구예요. 아주 가끔, 프로젝트가 정말 불가능할 때, 추정이 그 사실을 위로 전달하는 방법이 될 수 있어요. 하지만 그건 신뢰가 필요해요.

프로젝트 관리 협회 PMI의 2024년 보고서에 따르면 애자일 방법론을 적용한 조직의 71%가 더 나은 일정 예측 능력을 보였다고 해요. 하지만 여전히 절반 이상의 조직이 일정 추정에 어려움을 겪고 있다는 게 현실이죠.

마무리하며

저는 추정할 때 매니저가 찾고 있는 범위를 먼저 추출하고, 그다음에 코드를 살펴보면서 그 시간 안에 뭘 할 수 있을지 파악해요. 절대 "2주입니다"라고 단정적으로 말하지 않고요. 대신 각각 자체 위험을 가진 여러 가능성을 가지고 돌아가서, 매니저가 그 트레이드오프를 결정하도록 해요.

소프트웨어 업무를 정확하게 추정하는 건 불가능해요. 프로젝트 시간의 대부분은 알 수 없는 문제와 씨름하는 데 쓰이고, 그건 정의상 미리 추정할 수 없거든요. 잘 추정하려면 알려진 측면은 거의 무시하고, 대신 얼마나 많은 미지수가 있는지, 각 미지수가 얼마나 무서운지 교육받은 추측을 해야 해요. 그리고 그 모든 과정에서 가장 중요한 건 바로 조직 내 맥락과 정치를 이해하는 거랍니다.