읽는 데 약 9분
견적서 자동화 도구를 만들고 있다. 그런데 그 도구 안에서는 AI가 어떤 지원도 하지 않는다. 전부 수식과 코딩이다.
AI를 적극 활용하고자 시작한 접근인데 정작 결과물에는 AI가 없다는 것이, 만들고 나서야 스스로도 이상하게 느껴졌다. 이유는 단순했고 그 이유를 정리하고 나니, 내가 AI를 어디에 쓰고 있었는지도 같이 보였다.
목차
견적서에는 AI가 판단할 것이 없었다
견적서에 들어가는 값은 이미 정해져 있다. 단가는 원가 기준표와 거래 이력에서 나오고, 납기는 재고와 입고 일정을 확인하면 나온다. 만드는 사람이 그 값을 모르는 상태로 시작하는 것이 아니라는 뜻이다.
그러면 AI에게 물어서 새로 얻을 판단이 없다. 남는 것은 정해진 값을 받아 문서 형태로 빠르게 만들어준다는 이점 하나인데, 그 속도는 견적서 자동화로도 가능하다. 자동화를 해두면 AI를 쓰는 쪽과 시간 차이가 거의 없어질 것으로 본다.
비용도 걸린다. 나 혼자 쓰는 것이 아니라 직원 모두가 써야 하니 사람 수만큼 비용이 붙는다. 빠른 견적서 결과물을 얻기 위해 직원 모두에게 AI를 지원한다는 것은 효율 대비 비용이 큰 것으로 판단되었다.
보안은 더 중요 사항이었다. 견적 자료에는 원가와 거래처가 함께 들어 있어서 외부 서비스에 올리는 것 자체가 검토 대상이다. 회사 자료를 어디까지 올려도 되는지에 대한 기준은 AI 데이터 보안을 확인한 글에 따로 정리해뒀다.
다만 AI를 쓸 이유가 생기는 견적도 있다. 기존 데이터와 시장 가격을 분석해서 최적의 금액을 제안해야 하는 경우다. 여기에는 판단이 필요하고, 판단이 필요한 자리에서는 AI가 값을 한다.
반대로 기성품을 기존 납품 가격 기준으로 내는 견적에는 판단할 것이 거의 없다. 우리 회사 견적은 대부분 이쪽이고, 그래서 도구 안은 전부 수식과 코딩으로 채웠다. 값을 넣으면 정해진 계산이 돌고, 정해진 자리에 정해진 이름으로 저장된다.
어떤 방식으로 쓸지도 같은 기준으로 정했다
각자 PC에 프로그램 형태로 설치되면 별도 관리되어, 원하던 동일한 규칙 적용과 이력 관리가 힘들 것이다. 그래서 클라우드에 올리는 방법과 사내용 웹페이지로 만드는 방법도 검토했다.
어느 쪽이든 만드는 것 자체는 가능했지만, 기술적으로 해결해야 할 부분과 추가로 들어가는 비용을 함께 고려해야 했다.
결국 이미 사용하고 있는 방식을 선택하는 쪽으로 생각을 바꿨다. 회사에서 Microsoft Teams를 이미 쓰고 있으니, 여기에 견적 요청 채널을 하나 두면 기술적으로 새로 넘어야 할 것도 추가로 드는 비용도 없다.
이 결론도 혼자 낸 것이 아니다. 방식을 놓고 Claude와 상의하는 과정에서 나온 아이디어였다.
사내에서 여러 명이 같은 양식으로 견적서를 만들어야 한다. 각자 PC에 설치하지 않고 공통으로 쓸 방법을 찾고 있다. 지금 회사에서 쓰는 도구 안에서 할 수 있는 방법이 있는지 검토해줘.
도구가 해결하려는 것은 세 가지다
이렇게 만드는 견적서 자동화의 목적은 셋이다. 빠른 견적, 실수 없는 견적, 그리고 견적 이력 관리.
셋을 고려한 이유는 하나의 원인에서 출발한다. 같은 일을 사람이 매번 하기 때문에 발생하는 세 가지 고려 사항이다.
사람이 하면 느리다. 양식을 열고, 지난 건을 찾아보고, 값을 옮기고, 문구를 다듬는 시간이 건마다 다시 든다.
사람이 하면 실수할 수 있다. 품번 한 칸, 수량 한 자리가 어긋난 채로 나가면 실수한 견적에 대한 수습이 추가로 발생한다.
사람이 하면 관리가 어려워진다. 견적서 자동화를 생각하게 된 계기도 여기에 있다. 예전에 다니던 회사에서 수정 견적을 찾느라 엑셀 파일을 한참 뒤진 적이 있는데, 파일도 있었고 저장 규칙도 있었지만 사람이 실행하다 보니 그 규칙이 매번 지켜지지는 않았다.
규칙을 무시하려는 것이 아니다. 당장 처리해야 할 일이 앞에 있으면 규칙은 자연스럽게 뒤로 밀리고, 한 사람만 무시해도 나중에 찾을 때는 결국 전부 열어봐야 한다.
세 가지를 각각 고치려 들면 답이 안 나온다. 만드는 방식 자체를 바꾸면 셋이 같이 해결된다는 것이 지금 만들고 있는 견적서 자동화의 전제인데, 아직 실제로 적용해보기 전이라 이 부분은 내 기대치이다.
AI는 만드는 쪽에 있었다
견적서 자동화 도구 안에 AI가 없다고 해서 AI를 쓰지 않은 것은 아니다. 오히려 반대였다.
견적서 자동화를 어떤 순서로 구성할지 정할 때 AI와 상의했고, 어떤 데이터가 있어야 돌아가는지 확인하고 그 데이터를 구하고 형태를 고치는 과정에서도 썼다.
사람이 순서를 정해 주는 이 방식이 워크플로우에 해당한다는 것은 AI Agent와 워크플로우를 정리하면서 확인했다.
가장 도움이 된 것은 견적 요청이 들어오는 경우를 나눠보는 일이었다. 품목과 수량만 오는 요청, 예전 견적을 고쳐달라는 요청, 도면이나 사진으로 오는 요청은 처리 방식이 서로 다르다. 이 경우들을 정리하고 각각에 어떻게 대응할지 협의하면서 해결책을 만들어갔다.
견적 요청이 들어오는 형태를 정리하려고 한다. 품목과 수량만 오는 경우, 예전 견적의 수정을 요청하는 경우, 도면이나 사진으로 오는 경우처럼 종류별로 나누고, 각각을 같은 양식으로 받으려면 어떤 항목이 필요한지 검토해줘.
만드는 일 자체도 마찬가지였다. 비전문가인 내가 바이브 코딩으로 만들고 있는 방식이라, 수식과 코드는 모두 AI가 지원하고 만들어 주었다. 바이브 코딩은 코드를 직접 쓰는 대신 무엇을 만들고 싶은지 말로 설명하고 AI에게 코드를 맡기는 방식을 말한다.
정리해보면 견적서 자동화에서 AI가 맡은 일은 만드는 쪽에 몰려 있다. 순서를 설계하고, 빠진 경우를 찾고, 대응 방법을 같이 따져보고, 코드를 짜는 일에는 판단이 필요했기 때문이다.
반대로 만들어진 도구가 매일 돌아가는 실행에는 규칙에 의해 판단할 것이 없고, 그래서 AI도 없다.
AI에게 물어서 만들었지만 AI 없이 돌아가는 도구. 지금 만들고 있는 것을 한 줄로 줄이면 이렇게 된다.

그래서 누구에게 필요한가
다만 이런 방식이 모두에게 필요한 것은 아니다.
| 구분 | 만드는 사람 | 맞는 방식 | 이유 |
|---|---|---|---|
| 개인·일회성 | 한 사람이 가끔 | AI에 초안을 요청한다 | 도구와 규칙을 만드는 준비가 더 번거롭다 |
| 중간 규모 조직 | 여러 사람이 반복 | 규칙으로 고정한 도구 | 담당자가 달라도 결과가 같아야 한다 |
| 큰 조직 | 여러 부서가 상시 | 이미 갖춰진 시스템 | 따로 만들 이유가 없다 |
큰 조직은 주문과 견적이 도는 구조를 이미 갖추고 있다. 혼자 쓰는 경우라면 반대로 엑셀 양식 하나에 값을 바꿔 넣는 것이 가장 빠르고, 조건이 매번 다른 단발성 건이라면 AI에게 초안을 받아 손보는 쪽이 낫다.
이들 사이의 중간이 문제다. 여러 사람이 같은 문서를 반복해서 만드는데, 그 일이 도는 시스템은 아직 없는 조직이다. 중소 조직에서 견적서 자동화가 값어치를 내는 자리가 여기라고 나는 생각한다.
그리고 이런 조직일수록 도구 안에 AI를 넣기 어렵다. 인원수만큼 붙는 비용과 회사 자료를 외부에 올리는 문제가 그대로 남는데, 얻는 것은 속도 하나이기 때문이다. 만드는 쪽에만 AI를 쓰는 방식이 오히려 현실적인 이유가 여기에 있다.
앞으로 AI가 도구 안으로 들어올 자리
견적 요청이 도면이나 사진으로 오는 경우다. 지금은 사람이 보고 옮겨 적어야 하는데, 여기에 사진 속 글자를 그대로 읽어내는 OCR을 붙이면 그림 파일을 읽어 견적 요청 형태로 바꿀 수 있다.
이 자리는 판단이 아니라 읽기다. 사람이 옮겨 적는 것보다 정확하면 그것으로 충분하고, 읽은 결과는 사람이 한 번 확인하면 된다. 견적서 자동화에서 판단이 있는 자리에만 AI를 쓴다는 기준에도 어긋나지 않는다.
견적서 자동화는 지금 요청 양식과 원가 계산·마진율 부분을 만들고 있고, 전부 사용해본 것은 아니다. 기대하고 있는 것은 실수 없이 제출된 견적과 그 이력이 쌓이는 것, 그리고 그렇게 모인 정보를 나중에 영업 판단에 쓰는 것이다.
완성해서 사용해보면 처음 정한 순서가 그대로 갈지, 중간에 바뀔지 알게 될 것이다. 그때 어떻게 됐는지 다시 정리해보려 한다.
다음 글에서는 이 견적서 자동화 도구를 만든 방식 자체를 다뤄보려 한다. 비전문가가 바이브 코딩으로 업무 도구를 만드는 일이 실제로 어디까지 되는지에 대한 이야기다.