AI가 소프트웨어 추정 (estimation)을 끝장낸 것은 아닙니다. 불확실성의 위치를 새로운 곳으로 옮겼을 뿐입니다. 최선의 경우 (best-case) 수치는 정말 좋아졌고, 이는 기분 좋은 일입니다. 하지만 최악의 경우 (worst-case) 수치는 파악하기가 훨씬 더 어려워졌습니다. 그리고 실제로 고객에게 제시하는 중간값, 즉 수치는 그 어느 때보다 불안정해졌습니다. 이것은 3점 추정 (three-point estimation)을 포기해야 할 이유가 아닙니다. 오히려 그것에 더 의지해야 할 이유입니다.

모든 프로젝트는 동일하게 시작됩니다. 누군가는 수치를 필요로 합니다. 제안서를 기다리는 고객이든, 스프린트 계획 (sprint planning)을 위해 다음 기능을 가늠하는 여러분의 팀이든 상관없습니다.

이 작업에 얼마나 걸릴 것이며, 비용은 얼마나 들 것인가. 코드 한 줄을 쓰기 전, 내가 마주하게 될 일의 절반도 알기 전에, 나는 특정 수치를 약속해야 합니다. 때때로 그 수치는 제안서에 들어가 결국 계약이 됩니다. 때로는 스프린트 계획 (sprint plan)에 들어가거나, 누군가 이미 부사장 (VP)에게 보여준 로드맵 슬라이드에 포함되기도 합니다. 낮게 잡아서 틀리면, 그것이 여러분의 마진이든 팀의 다음 몇 주간의 주말이든 그 차액을 여러분이 감당해야 합니다. 높게 잡아서 틀리면, 계약을 놓치거나 더 빨리 배포할 수 있다고 약속한 다른 기능 때문에 해당 기능이 뒤로 밀리는 것을 지켜봐야 합니다.

수년 동안 나는 3점 추정 (three-point estimation)을 통해 이 일을 해왔습니다. 이것은 오래되고 지루하지만 신뢰할 수 있는 기술입니다 (PERT로 알려져 있습니다). 최근 나는 AI가 코드의 큰 부분을 작성하게 된 지금도 이 방식이 여전히 유효한지 궁금해졌습니다.

빠른 복습

만약 사용해 본 적이 없다면, 3점 추정 (three-point estimation)은 간단합니다. 어떤 작업에 대해 하나의 숫자 대신 세 개의 숫자를 도출하는 것입니다.

낙관적 수치 (O, Optimistic). 모든 것이 완벽하게 진행되며, 놀라운 변수가 없는 경우.

가장 가능성 높은 수치 (M, Most likely). 경험에 기반하여 보통 발생하는 경우.

비관적 수치 (P, Pessimistic). 합리적으로 발생할 수 있는 모든 잘못된 일이 발생하는 경우.

그런 다음 이들에 가중치를 부여합니다: (O + 4M + P) / 6. 가장 가능성 높은 경우가 가장 큰 비중을 차지하지만, 양극단의 값들도 여전히 수치를 그 방향으로 끌어당깁니다. 핵심은 단 하나의 추측은 당신을 속이지만, 세 개의 정직한 추측은 덜 속인다는 점입니다.

그 공식이 효과가 있었던 이유는 제가 기억만으로 각 숫자를 보정할 수 있을 만큼 충분히 유사한 작업을 수행해 왔기 때문입니다. 저는 "모든 것이 순조롭게 진행될 때"의 느낌을 알고 있었고, "제3자 API(third-party API)에 문서화가 되어 있지 않고, 배포하기 전에 요구사항이 두 번이나 변경될 때"의 느낌도 알고 있었습니다.

이제 AI는 그 세 가지 숫자 모두를 뒤흔들어 놓았습니다. 하지만 모두 동일하게 뒤흔든 것은 아닙니다.

낙관적인 수치는 개선되었습니다

이 부분은 누구나 가장 먼저 알아차리는 대목입니다. AI가 루프(loop)에 포함되면서, 최선의 시나리오(best-case scenario)는 이전보다 확실히 빨라졌습니다. 스캐폴딩(Scaffolding), 보일러플레이트(boilerplate), 지루한 CRUD 레이어, 테스트 스위트(test suite)의 초안 작성 등 말이죠. 운이 좋은 날이라면 비교조차 되지 않을 정도입니다.

따라서 당신의 O(Optimistic, 낙관적 수치)는 낮아집니다. 타당한 결과입니다. 그 부분은 실재합니다.

그 빠르고 깔끔한 최선의 시나리오는 유혹적일 수 있으며, 누군가가 "그래서 이걸 얼마나 빨리 구현할 수 있나요?"라고 물을 때 당신의 뇌가 붙잡고 싶어 하는 숫자이기도 합니다. 자신의 마감 기한을 쫓는 클라이언트, 혹은 이미 부사장(VP)에게 이 작업이 완료되었다고 말해버린 프로덕트 매니저(product manager) 같은 사람들 말입니다.

그 낙관적인 수치를 인용하지 마세요. 이전에도 그러지 않았고, AI가 그 규칙을 바꾸지는 않았습니다. 단지 그 낙관적인 수치를 더 유혹적으로 만들었을 뿐입니다.

비관적인 수치를 설정하기가 더 어려워졌습니다

여기서부터 흥미로워집니다. AI는 작업을 없애는 것이 아니라, 재분배합니다.

코드를 생성하며 절약한 시간은 다른 어딘가로, 대개는 덜 즐거운 곳으로 다시 돌아옵니다. 직접 작성하지 않은 코드를 읽는 일, 자신감 넘치고 정확해 보이지만 실제로는 그렇지 않은 결과물을 검토하는 일, 그리고 단독으로는 잘 작동했지만 시스템의 나머지 부분과 맞닿는 순간 깨져버리는 무언가를 풀어내는 일 말입니다.

마지막 항목이 진짜 치명적입니다. AI가 생성한 코드는 작동할 때는 아주 아름답게 작동하다가, 어느 순간 작동하지 않는 습성이 있습니다. 특히 고립된 상태에서는 잘 작동하지만, 접합부(seams)에서 마찰을 일으키는데, 바로 그 지점이 문제를 발견하는 데 비용이 가장 많이 드는 곳입니다.

따라서 이제 당신의 비관적인 시나리오(pessimistic case)는 새로운 종류의 실패를 고려해야 합니다.

첫째, 저는 추정치를 분리합니다. 코드를 생성하는 것과 코드를 검토하거나 통합하는 것은 이제 서로 다른 두 가지 작업이며 각각 다른 리스크 프로필(risk profiles)을 가집니다. 따라서 저는 각각에 대해 별도로 3점(three points)을 부여합니다. 생성 단계에는 낙관적인 최선의 경우(optimistic best case)를 적용합니다. 검토 및 통합 단계에는 두터운 비관적 꼬리(pessimistic tail)를 적용합니다. 이들을 하나의 숫자로 묶어버리는 것은 제가 가장 확인해야 할 바로 그 리스크를 숨겨버립니다.

둘째, AI 보조 프로젝트가 완료되어 실제 데이터가 확보될 때까지, 저는 비관적인 경우(pessimistic case)를 의도적으로 보수적으로 유지합니다. 낙관적인 경우가 민망할 정도로 충분히 빨라 보일 때조차 마찬가지입니다. 속도는 실재하지만, 잘못될 위험은 AI의 것이 아니라 저나 제 팀의 책임입니다.

그렇다면, AI 시대에도 여전히 3점 추정(three-point estimation)이 필요할까요?

저는 이전보다 더 필요하다고 생각합니다.

불확실성은 사라지지 않았습니다. 단지 이동했을 뿐입니다. 3점 추정은 제가 불확실성을 정직하게 가리키며 "이 범위 어딘가에 있습니다. 아마도요."라고 말할 수 있게 해주는 여전히 유효한 도구입니다.