금요일 오후 4시 47분. 견적서는 5시까지 나가야 한다. 안 그러면 일거리가 고객 리스트의 다음 업체로 넘어간다. 스프레드시트는 두 달 전 견적서를 복사한 것이다 — 같은 행, 가격은 "현재 기준"이어야 한다. 시공업자는 타일 수량을 업데이트하고, 고객 이름과 주소를 수정한다. 인건비 단가는 업데이트하는 걸 잊어버린다. 세 번의 클릭을 거쳐야 보이는 숨겨진 탭에 있기 때문이다. 견적서는 그대로 나가고, 고객은 그 자리에서 서명한다. 3주 후, 인건비 항목이 지난 가격 인상 전의 낮은 단가로 계산되어 있었다는 사실이 드러난다. 그 차이는 해당 작업 마진의 수백만 원에 달한다 — 아무도 제때 발견하지 못해서 그냥 사라져 버린 돈이다.
이건 한 고객만의 이야기가 아니다 — 영국과 아일랜드의 건설업체들과 이야기를 나누면서 계속 반복해서 보는 패턴이다. 내가 이 문제를 실제로 해결하는 시스템을 어떻게 만들지 소개한다.
문제는 도구로서의 엑셀이 아니다. 문제는 모든 견적서가 지난 견적서를 수동으로 복사한 것이고, 오늘 어느 행이 여전히 정확한지 아무도 통제하지 못한다는 점이다. 몇 가지가 계속 반복된다:
한 시공업체가 한 달에 약 15건의 견적서를 작성하고, 평균 작업 금액이 1,150만원이라고 가정해보자. 두 달에 한 번꼴로 인건비나 자재비에 3~5%의 오류가 생긴다면, 건당 손실은 약 35만원에서 58만원 사이다 — 그리고 더 심각한 경우는 아직 계산에 넣지도 않았다. 고객에게 과다 청구된 견적서는 아예 서명되지 않고 끝나버리는 경우 말이다.
| 항목 | 정확한 가격 | 발송된 견적서의 가격 | 차이 |
|---|---|---|---|
| 인건비, 욕실 2곳 | 일당 66만원 | 일당 57만원 (구 단가) | −일당 9만원 |
| 단열재, 40㎡ | ㎡당 2만 7천원 | ㎡당 2만 7천원 | 0원 |
| 10% 할인 | 자재비에 적용 | 총액에 적용 | 추가 손실 |
아이디어는 간단하다. 가격표는 책상마다 흩어진 다섯 개의 사본이 아니라 한 곳에만 존재한다. 모든 견적서는 거기서 생성되며, 할인 규칙은 기억에 의존하지 않고 시스템이 자동으로 적용한다.
영국과 아일랜드 건설업체에서 가장 흔히 요청하는 것들: 회계 소프트웨어(Xero, QuickBooks) — 수락된 견적서가 자동으로 초안 청구서가 된다; 보증금을 위한 Stripe나 은행 연동; 견적서를 보내고 링크를 3일 동안 열지 않으면 고객에게 리마인드를 보내는 왓츠앱 또는 이메일. AI가 진정으로 제 역할을 하는 지점이 딱 한 곳 있다 — 여러 개의 숨겨진 탭이 있는 지저분한 옛날 스프레드시트를 읽어서 승인 가능한 깔끔하고 구조화된 가격표로 바꾸는 것. "AI가 알아서 가격을 정하는" 게 아니라 지저분한 데이터를 위한 제2의 눈일 뿐이다.
사전 합의된 범위의 첫 번째 버전(1단계)은 약 580만원~1,150만원. 세 단계를 모두 합치면 약 1,450만원~2,900만원 사이이며, 할인 규칙이 실제로 얼마나 복잡한지, 그리고 현재 가격표를 마이그레이션하는 것이 얼마나 복잡한지에 주로 달려 있다. 실제 숫자는 48시간 무료 평가를 통해 실제 스프레드시트를 본 후에야 나온다 — 보기 전에는 아무도 확정 숫자를 약속해서는 안 된다.
한 달에 2~3건의 견적서만 작성하고 본인이 혼자 그 일을 다 한다면, 엑셀로도 충분히 제 역할을 하고 있는 것이다 — 솔직히 말할 가치가 있는 사실이다. 맞춤 시스템은 견적서가 한 사람 이상을 거쳐갈 때, 물량이 늘어나고 있을 때, 혹은 실수 하나가 이미 실제 일거리나 실제 돈의 손실로 이어졌을 때 그 비용만큼의 가치를 한다.
우리가 작성한 코드는 귀하의 소유다 — 귀하 이름으로 된 저장소, 문서, 모든 접근 권한 자격증명까지. Xero나 Stripe 같은 제3자 서비스는 각자의 라이선스 하에 유지된다. 이 중 어느 것이라도 익숙하게 들린다면, pentimento.pro의 실시간 에이전트에게 한 문장으로 상황을 설명해보라. 대화 속에서 바로 설계되는 것을 지켜보게 될 것이다.
PENTIMENTO