문의가 들어왔습니다. 고객이 가격을 물어봤고, 빨리 견적서를 보내야 합니다. 회사 견적서 양식 파일을 열고, 고객 이름과 회사명을 입력합니다. 지난번에 보낸 견적서 파일에서 품목을 복사해 붙여넣습니다. 단가를 찾아서 확인하고, 수량을 수정하고, 합계가 맞는지 계산기로 검토합니다. PDF로 저장하고, 이메일을 새로 열어 첨부해서 보냅니다. 여기에 날짜를 잘못 남기거나 이전 고객 이름이 그대로 있으면 다시 합니다.
"이게 뭐가 어렵나"라고 생각하실 수 있습니다. 한 번만 한다면 어렵지 않습니다. 문제는 이 과정을 월요일마다, 매주, 달마다 반복할 때입니다. 비슷한 품목, 비슷한 형식, 비슷한 단가가 반복되는데도 매번 처음부터 새로 만들고 있다면, 어딘가에서 시간이 낭비되고 있는 것입니다. 그리고 견적서 발행이 늦어질수록 고객이 경쟁사로 먼저 넘어가는 일이 생깁니다.
이 글은 견적서와 거래명세서 발행에서 실제로 시간이 새는 지점을 먼저 짚고, 지금 당장 할 수 있는 반자동 방법부터 전용 도구가 필요한 단계, 그리고 어디서부터 외부 도움이 필요한지를 순서대로 정리합니다. 새로운 프로그램을 바로 도입해야 한다는 이야기가 아닙니다. 지금 하는 방식에서 무엇을 바꾸면 되는지를 단계별로 보여드리는 것이 목적입니다.
견적서 발행에서 진짜 시간이 새는 곳
견적서 하나를 완성하는 데 걸리는 시간은 업종과 회사마다 다르지만, 반복적으로 하다 보면 어느 지점에서 가장 오래 걸리는지가 보이기 시작합니다.
양식 찾기와 초기 설정. 매번 새 파일을 만들거나, 지난 견적서를 복사해서 시작하는 방식이 가장 흔합니다. 복사한 파일에서 이전 고객 이름이 남아 있어 오발송이 생기거나, 날짜와 견적 번호를 수동으로 바꾸다 빠뜨리는 일이 반복됩니다. 담당자가 여럿이라면 양식이 사람마다 조금씩 달라지는 문제도 생깁니다.
품목과 단가 확인. 단가표가 별도 파일에 있거나, 가장 최신 버전이 어디 있는지 불분명할 때 매번 확인에 시간이 걸립니다. 단가를 이메일로 주고받거나, 카카오톡 채팅에서 찾아봐야 하는 상황이 반복되면 견적 하나 보내는 데 생각보다 오랜 시간이 걸립니다. 단가가 중간에 바뀌었는데 일부 직원이 옛날 단가로 계산해서 보내는 실수도 여기서 납니다.
발행·발송과 이력 관리. PDF 저장하고 이메일 작성하고 첨부하는 과정은 짧습니다. 하지만 월말에 "이번 달 견적을 몇 건 보냈고, 그중 몇 건이 계약으로 이어졌는가"를 정리해야 할 때, 이메일 보관함과 엑셀 파일을 뒤적이며 취합해야 한다면 그 시간이 만만찮게 쌓입니다.
거래명세서 재작성. 견적이 계약으로 이어지면 거래명세서를 또 만들어야 합니다. 견적서와 내용이 거의 같은데도 별도 파일을 처음부터 다시 만드는 방식이라면, 같은 일을 두 번 하고 있는 셈입니다. 나중에 세금계산서를 낼 때 또 한 번 같은 내용을 입력해야 한다면 세 번입니다.
월 30건 이상 견적을 발행하는 회사라면 이 네 지점을 합산했을 때 주 수 시간이 여기에 쓰입니다. 규모가 작을 때는 큰 문제로 안 느껴지다가, 거래처가 늘고 담당자가 바뀌면서 갑자기 "이걸 왜 이렇게 하고 있었나"가 되는 경우가 많습니다.
1단계: 지금 당장 할 수 있는 반자동 — 엑셀 구조 개선
새로운 도구 없이도 엑셀만으로 반복을 상당히 줄일 수 있습니다. 핵심은 "매번 새로 입력하는" 구조에서 "골라서 불러오는" 구조로 전환하는 것입니다.
품목 마스터 시트 만들기. 회사에서 자주 쓰는 품목명, 규격, 단가를 별도 시트에 정리해 둡니다. 견적서 작성 시트에서 VLOOKUP이나 INDEX/MATCH 함수를 연결해, 품목 코드를 입력하면 이름과 단가가 자동으로 채워지게 합니다. 단가가 바뀌면 마스터 시트 한 곳만 수정하면 이후 모든 견적에 자동 반영됩니다. 담당자마다 단가를 따로 관리하는 상황이 사라집니다.
거래처 마스터 시트 만들기. 자주 견적을 보내는 거래처의 이름, 담당자, 주소, 사업자 번호를 별도 시트에 정리해 둡니다. 견적서를 새로 만들 때 거래처 코드만 입력하면 나머지가 자동으로 채워지게 하면, 거래처 정보를 매번 새로 입력하면서 생기는 오타와 오발송을 막을 수 있습니다.
견적 번호 자동 부여. 견적 번호를 "26-07-001" 형식으로 설계하고, 연도와 월은 TODAY() 함수로 자동 입력되게 합니다. 일련번호만 수동으로 올리면 되는 구조입니다. 별도 이력 시트에 번호가 자동으로 쌓이게 설계하면 번호 중복이나 누락을 막을 수 있습니다.
견적서와 거래명세서 연결. 같은 파일 안에 "견적서" 시트와 "거래명세서" 시트를 나란히 두고, 거래명세서 시트가 견적서 시트의 값을 참조하게 만들면 견적이 계약으로 이어질 때 별도로 다시 작성하지 않아도 됩니다. 날짜와 서류 종류만 바꾸면 됩니다. 기존에 엑셀로 두 문서를 별도로 만들고 있었다면, 이 구조 변경만으로도 작업 시간이 눈에 띄게 줄어듭니다.
발행 이력 자동 기록. 견적서를 완성하면 이력 시트에 견적 번호, 발행일, 고객사, 품목 요약, 금액 합계, 상태(진행 중·계약 완료·보류·취소)가 자동으로 기록되게 설계합니다. 이 이력이 쌓이면 월말 마감 때 별도로 취합할 필요가 없고, "이번 달 계약 전환율이 어떻게 됐나"도 바로 확인할 수 있습니다.
이 방법들은 엑셀 함수에 익숙하다면 반나절에서 하루 정도면 구조를 잡을 수 있습니다. 익숙하지 않더라도, 한 번 제대로 설계해 두면 이후 수개월간 반복 작업을 줄이는 투자가 됩니다. 엑셀을 잘 모른다면, 지인이나 프리랜서에게 파일 설계만 의뢰해도 됩니다.
단, 이 방식은 담당자가 1~2명이고 월 견적 건수가 그리 많지 않을 때 현실적입니다. 담당자가 여러 명이거나, 외근 중에도 발행해야 하거나, 파일 버전 관리가 이미 혼선을 빚고 있다면 다음 단계로 가는 것이 맞습니다.
2단계: 전용 프로그램 — 엑셀의 한계를 넘어야 할 때
엑셀 개선만으로는 부족한 시점이 있습니다. 담당자가 여러 명이라 같은 파일을 동시에 수정하다 충돌이 생기거나, 외근 중에 스마트폰으로도 견적을 보내야 하거나, 이메일 발송까지 하나의 흐름으로 처리하고 싶을 때입니다.
이 단계에서 선택지는 크게 둘입니다: 견적·거래명세서 전용 프로그램, 또는 견적 기능이 포함된 클라우드 ERP.
견적서·거래명세서 전용 프로그램
국내에는 견적과 거래명세서를 통합 관리하는 소프트웨어가 여럿 있습니다. 거래처 정보와 품목 단가를 미리 등록해두고, 견적 작성 시 드롭다운으로 불러오는 구조입니다. 기능을 보면 대체로 비슷합니다: 견적 번호 자동 부여, 발행 이력 누적, PDF 저장, 이메일·팩스 발송, 계약 전환 후 거래명세서 자동 생성. 일회성 구매 방식도 있고, 소액 구독 방식도 있습니다.
이 수준의 도구로 해결되는 문제는 뚜렷합니다. 여러 담당자가 같은 거래처 정보와 단가를 공유하면서 각자 견적서를 만들 수 있고, 이력이 시스템 안에 쌓이기 때문에 월말 정리가 별도로 필요 없어집니다.
클라우드 ERP
회계·재고·영업을 함께 관리해야 한다면 클라우드 ERP가 현실적인 선택이 됩니다. 국내 중소기업에 가장 많이 쓰이는 이카운트 ERP는 견적서, 발주서, 거래명세서, 세금계산서 발행이 모두 기본 기능으로 들어 있고, 각 문서를 메일·팩스·PDF로 발송하고 수신 확인까지 할 수 있습니다. 2026년 기준 월 9,900원(사용자 1명 기준)부터 시작합니다.
클라우드 ERP의 핵심 강점은 흐름이 연결된다는 점입니다. 견적서에서 수주로, 수주에서 출고로, 출고에서 거래명세서로, 거래명세서에서 세금계산서로, 세금계산서에서 회계 전표로 이어지는 과정이 시스템 안에서 자동으로 연결됩니다. 한 번 입력한 거래처와 품목 정보가 모든 단계에서 공유되므로 이중 입력이 사라집니다.
2026년 현재 클라우드 SaaS 형태의 회계·업무 프로그램 비중이 전체의 약 42%까지 높아졌습니다. 코로나 이후 재택근무와 다중 거점 운영이 일상화되면서 설치형 프로그램 대신 어디서든 접속할 수 있는 클라우드 방식으로 전환하는 회사가 크게 늘었습니다. 설치형 프로그램은 특정 컴퓨터에서만 쓸 수 있지만, 클라우드는 스마트폰으로도 접속해 견적서를 발행할 수 있습니다.
양식 커스텀. 이미 써온 회사 견적서 양식이 있다면, 클라우드 ERP로 넘어갈 때 양식을 아예 버려야 하는 게 아닌지 걱정하시는 경우가 많습니다. 이카운트는 보고서 양식을 최대 50개까지 커스텀 설정할 수 있어서, 기존에 쓰던 형식을 대부분 재현할 수 있습니다. 완전히 동일하게 맞추기는 어려울 수 있지만, 거래처들이 이미 익숙한 핵심 항목들은 충분히 담을 수 있습니다.
3단계: 자동화 구축 — 반복이 완전히 남아 있을 때
클라우드 ERP나 전용 프로그램을 쓰고 있는데도 여전히 수작업으로 남아 있는 반복이 있다면, 그 지점이 자동화를 고민할 때입니다.
고객사별 맞춤 초안 자동 생성. 자주 거래하는 고객사에는 보통 주문 패턴이 있습니다. 같은 품목을 비슷한 수량으로 반복 주문하는 경우, 이 패턴을 기반으로 "이 고객에게 들어갈 품목"을 자동으로 채워 넣는 초안 견적을 만들게 하면, 담당자는 수량과 날짜만 확인하면 됩니다.
문의에서 견적까지 자동 연결. 홈페이지 문의 양식, 이메일, 카카오톡 채널로 들어오는 내용을 자동으로 읽어 초안 견적을 생성하고, 담당자가 검토만 하게 하는 흐름이 기술적으로 가능합니다. 프로그램끼리 자동으로 데이터를 주고받게 연결하는 방식, 흔히 "API 연동"이라고 부르는 구조로 구현합니다.
정기 거래명세서 자동 발행. 월말마다 같은 거래처에 같은 품목으로 거래명세서를 보내야 하는 회사라면, 기준을 등록해두고 날짜가 되면 자동으로 발행하고 이메일로 발송하는 구조도 가능합니다. 담당자가 승인만 하는 방식으로 설계하면 실수를 줄이면서도 수작업을 크게 줄일 수 있습니다.
AI 활용 영역. 이메일이나 팩스로 받은 발주서를 자동으로 읽어서 견적 초안을 만드는 흐름이 이미 실용화되고 있습니다. 단, 고객사별로 문서 양식이 천차만별이라 모든 케이스에서 완벽하게 인식되지는 않습니다. AI의 역할은 초안을 빠르게 만들어 주는 것이고, 인식 결과를 사람이 확인하는 절차는 여전히 필요합니다. AI가 만든 것을 그대로 발송하지 않도록 검토 단계를 반드시 설계에 포함해야 합니다.
이 단계의 자동화는 반드시 전문 개발자나 자동화 전문가의 도움이 필요합니다. 도구 하나 설치해서 되는 수준이 아니라, 회사의 업무 흐름을 파악하고 그에 맞는 연결 구조를 설계하는 작업이기 때문입니다.
어느 단계가 지금 우리 회사에 맞는가 — 판단 기준
모든 회사가 같은 단계에서 시작해야 하는 건 아닙니다. 지금 어떤 상황인지에 따라 시작점이 다릅니다.
엑셀 개선(1단계)이 맞는 경우:
- 견적 건수가 월 30건 미만이고 담당자가 1~2명이다
- 현재 엑셀을 쓰고 있고 새 프로그램 도입이 부담스럽다
- 가장 큰 문제가 단가표 버전 관리나 이력 정리다
- 프로그램 구독 비용을 지불하기 전에 먼저 직접 해보고 싶다
전용 프로그램 또는 클라우드 ERP(2단계)가 맞는 경우:
- 담당자가 여러 명이거나, 출장·외근 중에도 발행해야 한다
- 견적서에서 거래명세서, 세금계산서까지 하나로 묶고 싶다
- 월 30건 이상이고, 수작업 시간이 뚜렷하게 빠지고 있다
- 파일 버전 충돌이나 단가 불일치가 이미 문제가 된 적 있다
자동화 구축(3단계)이 맞는 경우:
- 2단계 도구를 이미 쓰고 있는데도 반복 수작업이 남아 있다
- 정기적으로 동일한 거래명세서를 여러 거래처에 대량 발행한다
- 문의 접수부터 견적 발행까지를 사람 손 없이 연결하고 싶다
- 고객사별 견적 초안을 AI가 생성해 주기를 원한다
한 가지 주의할 점이 있습니다. 어떤 단계를 선택하든, 기존에 거래처가 이미 익숙한 양식과 방식을 가능한 한 유지하는 것이 중요합니다. 납품 후 갑자기 완전히 다른 양식의 문서가 오면 거래처 쪽에서 혼선이 생기고, 기존 방식으로 다시 해달라는 요청이 올 수 있습니다. 거래처 혼선 없이 도입하려면, 양식이 어느 정도 유지되는 도구를 고르거나, 기존 양식을 재현하는 설계 작업이 선행되어야 합니다.
자동화 도입 전에 내부에서 먼저 할 일
외부 도구를 쓰거나 전문가를 부르기 전에, 내부에서 먼저 정리해두면 도입이 훨씬 순탄해지는 것들이 있습니다.
현재 흐름 문서화. 지금 어떤 방식으로 견적서를 만들고, 어떻게 발송하며, 어디에 보관하는지를 한 장짜리로라도 써봅니다. 막상 써보면 사람마다 방식이 조금씩 다른 경우가 많습니다. "A 담당자는 이렇게 하고, B 담당자는 저렇게 한다"는 차이가 도구 설계에서 가장 까다로운 부분이 됩니다.
단가·거래처 데이터 정리. 품목 단가와 거래처 정보가 여러 파일에 흩어져 있거나, 최신 버전이 어디 있는지 불분명하다면 먼저 한 곳에 정리하는 작업이 필요합니다. 어떤 도구를 써도 데이터가 정리되어 있지 않으면 제대로 활용할 수 없습니다.
자동화할 것과 하지 않을 것 구분. 모든 견적을 자동화하면 안 되는 이유가 있을 수 있습니다. 특수 조건이 많은 거래처, 협상이 자주 일어나는 품목, 민감한 단가 정보가 있는 경우 등은 자동화 범위에서 제외하는 것이 낫습니다. 이 구분을 미리 해두어야 자동화 설계를 현실적으로 할 수 있습니다.
자주 묻는 질문
Q. 거래명세서와 세금계산서, 어떻게 다른가요?
거래명세서는 물건이나 서비스를 주고받을 때 그 내역을 기록하는 문서입니다. 법적 의무는 없지만 거래 내역 확인용으로 관행적으로 쓰입니다. 세금계산서는 부가세가 포함된 거래에서 발행하는 공식 세금 관련 문서로, 법적 의무가 있습니다. 현재 연매출 8,000만 원 이상 사업자는 전자세금계산서 의무 발행 대상입니다. 거래명세서 자동화와 세금계산서 자동화는 보통 별도로 설계됩니다.
Q. 엑셀만으로 이메일 자동 발송이 되나요?
기본 엑셀 자체에는 이메일 자동 발송 기능이 없습니다. 매크로(VBA)를 설계하면 아웃룩과 연동해 자동 발송이 가능하지만, 설정이 복잡하고 메일 프로그램이 바뀌면 다시 손봐야 합니다. 이메일 발송까지 자동화하고 싶다면 전용 프로그램이나 클라우드 도구가 더 현실적입니다.
Q. 이미 클라우드 ERP를 쓰고 있는데도 수작업이 남아 있습니다. 어떻게 해야 하나요?
어떤 수작업이 남아 있는지가 중요합니다. ERP가 커버하지 않는 채널(예: 카카오톡 주문, 현장 문의)에서 오는 건을 수동으로 ERP에 입력해야 한다면, 그 채널과 ERP 사이를 연결하는 자동화가 필요합니다. 혹은 ERP의 기능이 있음에도 직원들이 쓰지 않고 기존 방식대로 하고 있다면, 도구보다 업무 방식 정비가 먼저입니다.
Q. 클라우드 ERP 도입 비용이 얼마나 드나요?
구체적인 비교는 요금 안내 페이지를 참고해 주세요.
자동화가 실패하는 흔한 패턴
도입 과정에서 실패하는 경우를 몇 가지 공통으로 봅니다. 이 부분은 미리 알아두면 많은 시행착오를 줄일 수 있습니다.
데이터 정리 없이 도구부터 도입. 클라우드 ERP를 계약하고 나서야, 거래처 정보가 여러 파일에 흩어져 있고 단가 기준이 사람마다 다르다는 걸 발견하는 경우가 있습니다. 도구 도입 전 데이터 정리 작업이 선행되어야 하는데, 이 단계를 건너뛰면 도구는 있는데 제대로 쓰지 못하는 상황이 됩니다.
직원들이 기존 방식으로 계속 하는 경우. 새 도구가 도입됐는데도 "예전 방식이 더 편하다"며 익숙한 엑셀로 계속 하는 경우가 있습니다. 도구 도입보다 "왜 바꾸어야 하는지"와 "어떻게 쓰는지"를 함께 공유하는 과정이 중요합니다. 도구만 바꾸고 사용 방법 안내를 건너뛰면 정착이 안 됩니다.
모든 것을 한꺼번에 자동화하려는 시도. 견적서, 거래명세서, 세금계산서, 영업 이력, 매출 보고까지 한꺼번에 연결하려다가 구축이 복잡해지고 기간이 길어지면 중간에 멈추는 경우가 생깁니다. 가장 시간이 많이 드는 한 지점부터 시작하고, 거기서 효과를 확인한 뒤 다음을 연결하는 방식이 현실적입니다.
정리하며
견적서·거래명세서 자동화는 한 번에 완전 자동화로 뛰어넘는 것보다, 지금의 수작업 방식을 단계적으로 개선해 나가는 편이 실제로 잘 정착됩니다.
1단계는 엑셀 구조 개선으로, 도구 없이 지금 당장 시작할 수 있습니다. 단가 마스터화, 거래처 자동 불러오기, 견적서와 거래명세서 연결 구조만 잡아도 반복 시간이 눈에 띄게 줄어듭니다. 2단계는 전용 프로그램이나 클라우드 ERP로, 담당자가 여럿이거나 건수가 많아질 때 자연스러운 다음 단계입니다. 3단계는 2단계 도구를 이미 쓰면서도 반복이 남아 있을 때 의미가 있습니다.
어느 단계에 있든, 지금 가장 시간이 많이 드는 지점 하나를 구체적으로 특정하는 것이 출발점입니다. "자동화하고 싶다"는 방향보다 "이 작업에 매번 이만큼 시간이 든다"는 문제 정의가 먼저입니다.
비슷한 반복 업무를 실제로 어떻게 개선했는지 궁금하시다면 실제 구축 사례를 참고하세요. 지금 상황이 어떤 단계에 해당하는지 직접 여쭤보고 싶으시면 30분 무료 진단을 신청해 주세요. 영업 전화는 드리지 않습니다.