거의 동일해 보이는 작업 요청(brief)에 대해 두 개의 제안서가 도착했습니다. 하나는 다른 하나보다 세 배나 비쌉니다. 어느 팀도 거짓말을 하고 있지 않습니다.

이런 일은 끊임없이 발생하며, 창업자들은 대개 비싼 쪽은 비용이 부풀려졌다고 가정하거나 저렴한 쪽은 경험이 부족하다고 가정함으로써 이 문제를 해결하려 합니다. 때로는 그것이 사실일 수도 있습니다. 하지만 더 빈번한 경우는 두 팀이 서로 다른 양의 작업에 대해 가격을 책정했을 때입니다. 왜냐하면 그들이 귀하의 시스템을 열었을 때 무엇을 발견하게 될지에 대해 서로 다른 가정(assumptions)을 세웠고, 어느 쪽도 그 가정을 문서화하지 않았기 때문입니다.

비용 수치를 실제로 움직이는 요인은 다음과 같습니다.

1. 아키텍처(Architectural) 시작 조건

이것은 가장 큰 변수이며, 작업 요청서(brief) 상에서는 보이지 않습니다.
두 제품 모두 정상적으로 작동하고, 실제 고객에게 서비스를 제공하며, 외부에서 보기에는 동일해 보일 수 있지만, 한 제품이 확장하는 데 세 배 더 많은 비용이 들 수 있습니다. 그 차이는 원래의 아키텍처(architecture)가 현재 귀하가 나아가려는 방향을 예측했는지 여부에 달려 있습니다.

테넌트 격리(tenant isolation)를 위한 단일 강제 지점(single enforcement point)으로 구축된 시스템은 프로젝트로서 격리 모델을 변경할 수 있습니다. 반면, 격리가 올바른 필터(filter)를 포함한 모든 쿼리(query)에 의존하는 시스템은 먼저 한 줄씩 감사(audit)를 수행해야 하며, 비용이 많이 드는 부분은 변경 자체가 아니라 바로 그 감사 과정입니다.

이를 점검하지 않고 견적을 내는 팀은 추측치를 제시하는 것입니다. 이를 점검한 후 발견한 내용을 설명해 주는 팀은 견적 그 이상의 가치가 있는 정보를 귀하에게 전달하고 있는 것입니다.

2. 데이터 모델의 어느 정도가 하중을 견디는 부채(load-bearing debt)인가
모든 기술 부채 (technical debt)의 비용이 동일한 것은 아닙니다. 아무도 사용하지 않는 기능의 부채는 비용이 들지 않습니다. 데이터 모델의 부채는 존재하는 부채 중 가장 비싼 종류입니다. 왜냐하면 모든 것이 그 위에 구축되어 있으며, 이를 변경한다는 것은 단 하나의 데이터 손실 없이 라이브 고객 데이터를 마이그레이션(migration)해야 함을 의미하기 때문입니다.
여기서 비용을 유발하는 구체적인 요소들은 다음과 같습니다: 안정적으로 유지되도록 설계되지 않은 식별자(identifiers), 소스(source)와의 합의에서 벗어나 비정규화(denormalised)된 데이터, 상태 필드에 따라 여러 가지 의미를 갖게 된 컬럼(columns), 그리고 과거의 값을 재구성할 수 없게 만드는 이력 기록(historical record)의 부재입니다.
귀하의 스키마(schema)를 열어보고 침묵에 빠지는 팀은 까다롭게 구는 것이 아닙니다. 그들은 단지 예산이 어디로 흘러가고 있는지를 발견했을 뿐입니다.
3. 통합 표면 (The integration surface)
귀하의 제품이 접촉하는 모든 외부 시스템은 비선형적으로 확장되는 비용의 원천입니다. 이는 통합(integration)을 작성하는 것이 어렵기 때문이 아니라, 각 통합이 귀하가 통제할 수 없는 의존성(dependency)이기 때문입니다. 각 시스템은 고유의 속도 제한(rate limits), 고유의 장애 동작(failure behaviour), 고유의 버전 관리 일정(versioning schedule), 그리고 귀하의 가장 바쁜 시간에 무언가 고장 났을 때의 고유한 지원 대응 속도를 가지고 있습니다.
5개의 통합은 1개 통합 비용의 5배가 아닙니다. 그것은 5배의 표면적(surface area)에 더해, 동시에 둘 이상의 시스템이 연루된 장애가 발생했을 때의 조정 비용(coordination cost)이 추가된 것입니다.
두 개의 제안서를 비교할 때는, 두 팀 모두 동일한 통합 항목들을 계산에 넣었는지, 그리고 각 통합 시스템을 사용할 수 없을 때 어떤 일이 발생하는지에 대해 질문했는지 확인하십시오.
4. 컴플라이언스(Compliance), 그리고 그것이 도래하는 시점
컴플라이언스 요구사항은 설계 단계에서 포함되면 저렴하지만, 사후에 맞추려 하면 매우 비쌉니다. 이는 이 카테고리 전체에서 가장 예측 가능한 비용적 돌발 변수입니다.

감사 로그(Audit logging)가 가장 명확한 예시입니다. 감사 추적(audit trail)을 해당 기능을 위해 설계되지 않은 쓰기 경로(write path)에 연결하려면 상태를 변경하는 모든 작업을 건드려야 합니다. 만약 그러한 작업이 100개 있다면, 고객에게 보여줄 새로운 기능 하나가 생기기 전에 검토와 테스트가 필요한 변화가 100개가 있다는 의미입니다.

데이터 거주지(Data residency)도 같은 형태를 가집니다. 삭제할 권리 역시 마찬가지입니다. 만약 아무도 이를 위해 설계하지 않았고 개인 데이터가 캐시, 로그, 백업 및 분석에 전파되었다면 더욱 그렇습니다.

만약 기업 고객이 올 것을 알고 있다면, 규정 준수(compliance) 작업은 지금 하는 것이 나중에 할 때보다 저렴합니다.
5. 내부의 의사결정 지연 시간(Decision latency)
제안서에 아무도 포함시키지 않지만, 실제로는 가장 큰 비용 동인 중 하나입니다.
엔지니어링 작업이 결정 대기 상태로 멈춥니다. 이 두 가지 행동 중 어느 것이 올바른가? 레거시 가져오기 형식(legacy import format)을 지원할 것인가? 새로운 권한 모델에 누가 승인할 것인가? 매일 해결되지 않은 결정은 생산 가능한 용량으로 적게 벌어들이는 하루를 의미합니다.

이전에 이러한 경험을 한 팀들은 계획 단계부터 의사결정 지점을 포함시키고 각 주체(owner)가 누구인지 명시합니다. 만약 눈앞의 제안서가 우리 측에서 누가 무엇을 결정할지 식별하지 못한다면, 그것은 가격 책정이 되지 않은 위험을 떠안는 것입니다.
시간당 요율이 거의 아무것도 알려주지 않는 이유
시간당 요율(hourly rate)은 한 시간이 얼마의 비용인지 측정하는 것이지, 작업에 얼마나 많은 시간이 걸리는지를 측정하는 것이 아닙니다. 매우 다른 요율을 가진 두 팀도 비슷한 총액에 도달하는 경우가 흔한데, 이는 더 경험이 풍부한 팀이 이미 그 문제를 겪어봤기 때문에 그것을 발견하는 데 몇 주를 낭비하지 않기 때문입니다.

더 나쁜 것은 시간당 청구 방식(hourly billing)이 귀사와 공급업체를 같은 질문의 양쪽 끝에 세운다는 것입니다. 절약되는 매시간은 그들에게 손실된 수익입니다. 이 배열에서 아무도 의도적으로 부정직한 사람은 없지만, 인센티브가 잘못된 방향을 가리키고, 장기간의 계약에서는 의도보다 인센티브가 승리합니다.

요율 대신 물어봐야 할 것은 다음과 같습니다: 결과물(outcome)은 무엇인가, '완료'는 어떻게 정의되는가, 예상보다 오래 걸리면 어떻게 되는가, 그리고 누가 그 책임을 지는가.

이 네 가지 질문에 대한 답변은 첫 페이지에 적힌 그 어떤 숫자보다도 공급업체에 대해 더 많은 것을 알려줍니다.

두 제안서를 정직하게 비교하는 방법
두 팀 모두 시스템을 직접 점검했는지, 아니면 단순히 요약서(brief)만 읽었는지 확인하십시오. 둘 중 하나만이 진정한 견적(quote)입니다.
범위(scope)가 실제로 일치하는지 확인하십시오. 항목별로 하나씩 대조해 보십시오. 대개 일치하지 않으며, 그 차이가 종종 전체 가격 차이의 원인이 됩니다.
각 제안서가 무엇을 발견할 것이라고 가정하고 있는지 확인하십시오. 만약 어느 쪽도 가정을 명시하지 않았다면, 질문하십시오. 그 답변이 많은 것을 드러낼 것입니다.
아키텍처 결정(architectural decisions)의 소유권이 누구에게 있는지, 그리고 결정이 내려지는 즉시 문서화되는지 아니면 마지막에 설명되는지 확인하십시오.
무엇이 제외되었는지 확인하십시오. 제외 사항(exclusions) 목록은 포함 사항(inclusions) 목록보다 더 많은 정보를 제공합니다.

예산 질문을 하기 전에 던져야 할 가치 있는 질문
비용이 얼마인지 묻기 전에, 시스템이 실제로 어떤 상태에 있는지에 대해 방어 가능한(defensible) 답변을 얻으십시오. 그것 없이는 여러분이 받는 모든 숫자는 스프레드시트(spreadsheet)를 입고 있는 추측에 불과하며, 제안서들 사이에서 선택할 근거가 없게 됩니다.

시작하는 대략적인 방법은 현재의 부채(debt) 상태에 대해 스스로 수치를 매겨보는 것입니다. 정확하지는 않을 것입니다. 하지만 막연한 느낌보다는 훨씬 유용할 것이며, 이후 어떤 공급업체와 대화를 나누더라도 그 대화의 질을 바꿔놓을 것입니다.