DHH, 2024년 8월 19일 원문

컴퓨터 시대가 시작된 이래로 인간은 소프트웨어를 구축하는 데 걸리는 시간을 추정하려고 노력해 왔지만, 그 오랜 시간 동안 지속적으로 실패해 왔습니다. 중간 규모의 프로젝트를 예측하는 것조차 매우 어렵고, 대규모 프로젝트를 예측하는 것은 사실상 불가능합니다. 그런데도 업계에서는 60년 동안 효과가 없던 방법이 조금만 더 노력하면 다음 프로젝트에서는 반드시 효과가 있을 것이라고 계속 주장합니다. 이것이 바로 망상입니다.

근본적인 문제는 소프트웨어 개발 유형이 너무 일상화되어 견적이 가능해지면 구축이 아닌 구매가 가능한 제품이나 서비스로 바뀐다는 점입니다. 오늘날 단순한 콘텐츠 관리 시스템이나 이커머스 스토어를 구축할 필요가 있는 사람은 거의 없으며, 워드프레스나 Shopify 또는 다른 대안 중 하나를 사용합니다. 따라서 소프트웨어 개발의 대부분은 새로운 작업에 집중되고 있습니다.

하지만 새로운 작업의 특징은 개발을 시작하기 전까지는 그 누구도 정확히 어떤 모습일지 모른다는 것입니다. 소프트웨어 업계는 오랫동안 제품 개발에 대한 예측에 실패해 왔지만, 동시에 새로운 제품을 미리 지정하면 사람들이 실제로 원하는 것을 만들어낼 수 있다고 착각해 왔습니다.

하지만 우리는 이전에도 여러 번 시도한 적이 있습니다! 그리고 아무도 그 결과를 신경 쓰지 않았습니다. 항상 진짜 문제를 해결하지 못했기 때문입니다. 잘못된 해결책의 절반을 만들고, 방향을 바꾸고, 더 나은 것을 생각해낸 후에야 비로소 명확하게 말할 수 있는 문제들 말입니다.

이제 이를 받아들여야 할 때입니다. 똑똑한 프로그래머들은 수십 년 동안 노력해왔지만, 실패를 거듭해왔고, 오늘날 실패를 거듭하고 있는 것처럼, 사람들이 인간의 독창성을 무시하고 소프트웨어에 추정이 필요하다고 주장할 때 실패하고 있습니다.

해결책은 더 열심히 노력하거나 이번엔 어떻게든 달라지기를 바라는 것이 아닙니다. 전술을 바꾸는 것입니다. 추정하기를 포기하고, ShapeUp 방법론에서 말하는 *budgets 또는 *appetites를 사용하여 소프트웨어를 만드는 대체 방법을 받아들이세요. (budgets와 appetites는 우리가 프로젝트에서 쓰고 싶은 시간을 의미해요.)

개발 과정에서 협상의 여지를 열어두면 프로그래머는 의외로 훌륭한 소프트웨어를 제때에 제공하는 데 능숙하다는 것이 밝혀졌습니다. 요구한 것을 정확히 얻을 수는 없겠지만, 어쨌든 그렇게 되기를 원하지는 않을 것입니다. 왜냐하면, 빌드를 시작하기 전에 요청했던 내용은 문제를 가장 잘못 이해한 상태에서 나온 것이기 때문입니다.

훌륭한 소프트웨어는 발전을 이루기 위한 절충과 양보의 산물입니다. 이것이 바로 인간 본성의 결을 따라가는 방법입니다. 이것이 바로 수십 년 동안 37signals를 이끌어온 핵심 실현 방식이며, 소규모 팀이 자신의 역량을 뛰어넘는 멋진 제품을 만들어낸 원동력이었습니다. 저희는 이를 Shape Up에 통합했지만, 특정 방법론을 사용하든 사용하지 않든 견적을 포기하면 더 빨리 더 나은 제품을 출시하는 데 도움이 될 수 있습니다.

옮기며

저도 10년 정도 서비스 개발을 해오면서 ‘견적’이라는 단어를 자주 사용했어요. 매니저가 된 최근에도 일정 산정에 대해 자주 이야기하게 됐죠. 실무를 할 때도 항상 받던 질문이었고, 저 자신도 나의 능력과 해야 할 일을 고려해 이 정도 시간이 필요하겠다고 늘 계산했어요.

하지만 사람마다 능력과 일에 대한 시각이 다를 수 있기 때문에, 이로 인해 이견이 생기는 경우가 많았어요. DHH가 지적한 것처럼, 저뿐만 아니라 팀 전체도 예측에 실패하는 일이 종종 있었어요.

저는 여전히 최소한의 예측은 필요하다고 생각해요. 이를 통해 나 자신의 역량을 파악하고, 성장의 방향을 설정할 수 있기 때문이에요. 하지만 팀 관점에서의 발상과 전략의 전환은 의미 있는 시도가 될 수 있다고 생각해요. 이런 시도는 덜 중요한 것(=일정 예측)에 매몰되지 않게 하고, 우리가 해야 할 일에 집중할 수 있게 도와줄 거에요.

복직을 3달 정도 남긴 시점에 오랜만에 일하는 방식을 돌아볼 수 있었던 뜻깊은 글이었네요.