납품 후 한 달, 고객들이 실제로 겪는 것 — 세 사례에서 본 공통점

자동화 시스템을 처음 받았을 때 고객들의 반응은 대체로 비슷합니다. "잘 되겠지"라는 기대와 "실제로도 될까"라는 의심이 동시에 있는 상태입니다. 이 의심은 악의가 아닙니다. 새 도구는 써봐야 알고, 업무에 실제로 연결되기 전까지는 믿음이 생기기 어렵습니다.

그래서 납품일은 끝이 아닙니다. 오히려 시스템이 진짜 일을 시작하는 날입니다. 코드가 완성됐다고 해서 사람이 실제로 쓰게 되는 것은 아닙니다. 쓰는 방법을 몸에 익히고, 처음 마주하는 예상치 못한 상황들을 넘어가고, "이게 진짜 내 업무를 돕는구나"라는 감각이 생기는 데까지 시간이 걸립니다.

옥수가 지금까지 구축한 세 사례를 기준으로, 납품 이후 한 달 동안 어떤 일이 일어나는지, 그 과정에서 어떤 설계가 중요한지, 왜 세 고객 모두 구축 이후에도 연락이 이어지고 있는지를 정리했습니다.

업종은 보험, 사무·운영, 기술 서비스로 모두 다르고, 자동화한 업무도 PDF 입력, 업무지시 관리, 블로그 발행으로 각기 다릅니다. 그런데도 납품 이후 한 달의 경과에는 공통되는 패턴이 있었습니다. 그 패턴을 공유하는 것이 이 글의 목적입니다.

구축이 끝났다는 것은 무엇을 의미하는가

흔히 "납품"은 시스템을 전달하는 것으로 끝난다고 생각합니다. 개발자 입장에서는 코드가 완성되고 정상 작동을 확인한 순간이 끝처럼 느껴집니다. 하지만 자동화 시스템에서 납품은 사람이 직접 쓸 수 있는 상태까지를 포함합니다. 매뉴얼만 건네고 "이제 알아서 쓰세요"는 실제로 쓰이지 않는 시스템을 만드는 방법입니다.

업무 자동화 도입 사례 연구에서 공통으로 발견되는 문제가 있습니다. 시스템을 받은 직후에는 잘 쓰다가, 첫 몇 주 안에 "검토하는 데 시간이 너무 오래 걸린다"거나 "담당자가 바뀌었는데 쓰는 방법을 아무도 모른다"는 이유로 멈춘다는 것입니다. AI 자동화 도입 후 6~8주가 안정화 기간의 분기점이라는 분석이 나오는 것과 같은 맥락입니다. 이 기간을 함께 넘겨야 시스템이 정착합니다.

옥수의 구축이 끝날 때 반드시 포함되는 것은 세 가지입니다. 첫째, 시스템이 실제 업무 흐름과 연결되어 있는 것. 둘째, 고객이 직접 다룰 수 있도록 인수인계가 이루어진 것. 셋째, 납품 이후에도 궁금한 것이 생기면 바로 연락할 수 있는 것. 이 세 가지가 갖춰졌을 때 비로소 "구축이 끝났다"고 말합니다.

보험설계사님의 경우 — PDF 자동화 이후 첫 달

보험 PDF 자동화 사례에서 보험설계사분은 보험사에서 받는 견적·안내 PDF를 직접 만든 엑셀 템플릿에 일일이 손으로 옮겨 넣는 일을 매일 했습니다. 고객을 만나야 할 시간에 화면 앞에 앉아 숫자를 한 칸씩 옮기는 일이 하루 두 시간씩 반복됐습니다.

구축은 거창한 시스템을 새로 만드는 방식이 아니었습니다. 이미 쓰던 엑셀 템플릿과 Claude를 연결했습니다. PDF를 넣으면 필요한 항목이 템플릿 구조에 맞게 추출되도록 프롬프트 설계와 Claude 세팅을 잡고, 추출된 내용이 기존 엑셀 템플릿에 그대로 들어가는 흐름을 구성했습니다. 결과적으로 하루 두 시간이 3분으로 줄었습니다.

수치만 보면 극적인 변화지만, 실제로 납품 이후 한 달이 중요한 이유가 있습니다.

처음 2주는 시스템이 맞게 돌아가는지 확인하는 시간이었습니다. 새로 오는 PDF마다 결과가 제대로 나오는지 살펴보고, 혹시 다른 양식의 PDF가 오면 어떻게 되는지, 엑셀 템플릿 구조를 바꾸고 싶을 때 어떻게 하면 되는지 차례로 질문이 나왔습니다. 이 질문들에 바로 답할 수 있는 상태였기 때문에 막히는 순간 없이 지나갔습니다.

이 인수인계 과정에서 가장 중요하게 설계한 것은 "본인이 직접 운영할 수 있는 수준까지 전달하는 것"이었습니다. 어떤 원리로 돌아가는지 이해하면, 이후에 환경이 조금 바뀌어도 스스로 판단할 수 있습니다. 전화 한 통 없이 알아서 쓸 수 있다는 것이 제대로 된 납품입니다. "이걸 수정하고 싶으면 이 부분을 바꾸면 됩니다"라는 식으로, 가능한 범위까지 직접 건드릴 수 있게 해드리는 것이 방향입니다.

한 달이 지난 지금도 재구매 의사와 함께 연락이 이어지고 있습니다. 비슷한 자동화를 더 확장하고 싶다는 내용입니다. 처음에 "이게 될까"라고 했던 분이 "이걸 어디에 더 쓸 수 있을까"로 바뀌는 순간이 이 과정에서 일어납니다.

업무 지시 스프레드시트 사례 — 새 도구 없이 바뀐 것들

업무지시 자동화 사례는 조건이 하나 있었습니다. 새 프로그램을 배우게 하지 않는 것입니다.

직원들에게 "이 새 시스템 써야 합니다"라고 하는 순간, 도입 전부터 저항이 생깁니다. 배움의 부담, 기존 방식과의 단절, "왜 바꿔야 하나"라는 질문이 동시에 옵니다. 자동화가 쓰이지 않는 가장 흔한 이유 중 하나가 이 저항을 넘기지 못한 것입니다.

이 사례에서는 이미 쓰던 스프레드시트를 그대로 두고, 거기에 AI가 연결되는 방식으로 구성했습니다. ChatGPT와 Claude를 회사에서 이미 쓰고 있던 스프레드시트에 연결해서, 업무 지시를 평소처럼 말하거나 메모하면 AI가 담당자, 기한, 내용을 구조화해서 스프레드시트에 자동으로 기록하는 흐름이 됐습니다.

납품 이후 첫 달이 편했던 이유는 쓰는 방식이 달라지지 않아서입니다. 직원들은 기존에 쓰던 방식으로 계속 일하면서 자동화가 그 흐름 안에서 작동했기 때문에, "이것 어떻게 쓰는 건가요"라는 질문이 나올 틈이 없었습니다.

"분명히 말했는데"와 "못 들었는데"가 반복되던 상황이 사라지고, "그 일 어떻게 됐지?"를 시트 한 장에서 확인하게 됐습니다. 이 변화는 시스템을 받은 첫 주부터 느껴졌습니다. 구축 이후에도 추가 의뢰로 협업이 이어지고 있습니다.

블로그 자동화 사례 — 어려움이 편함으로 바뀌는 속도

블로그 콘텐츠 자동화 사례에서 T사 대표는 현장 경험을 말로 풀면 블로그 글이 자동으로 만들어지는 구조를 쓰게 됐습니다. "쓸 이야기는 많은데 쓸 시간이 없다"는 문제를 구조로 해결한 것입니다.

납품 직후에는 생성된 초안을 검토하고 발행하는 과정을 처음 해보는 시간이었습니다. 어느 정도가 "완성된" 수준인지, 어느 부분은 직접 손을 대야 하는지 감을 잡는 데 약 2주가 걸렸습니다. 이 2주 동안 나온 질문들에 바로 답하면서, 초안을 검토하는 부담이 적절한 수준으로 줄어들도록 프롬프트를 함께 다듬었습니다.

이것이 중요한 포인트입니다. 납품 이후에도 "검토 부담이 생각보다 크다"는 신호가 오면, 그 신호에 반응해서 같이 조정하는 것이 납품 후 한 달의 실제 작업입니다. 완성본을 건네고 끝이 아니라, 실제로 업무에 녹아드는 과정을 함께 지납니다.

2주가 지나고 나면 "이게 편하다"는 감각이 자리를 잡기 시작합니다. "블로그 해야 하는데"가 "말만 하면 올라가는데"로 바뀌는 전환입니다. 그 이후에는 "이걸 다른 곳에도 쓸 수 있을까"라는 질문이 생겼고, 추가 개선 요청으로 협업이 이어지고 있습니다.

세 사례에서 발견한 공통 흐름

업종도 다르고 자동화한 업무도 다른데, 납품 이후 한 달의 경과에서 공통되는 패턴이 있습니다.

세 사례 모두 이 흐름을 밟았습니다. 2주가 가장 중요한 고비입니다. 이 시기에 "생각보다 검토가 번거롭다"고 느끼면 안 쓰게 되고, "이게 생각보다 편한데"라고 느끼면 신뢰가 생깁니다.

그래서 납품 후 2주를 어떻게 설계하느냐가 시스템이 오래 쓰이는지를 결정합니다. 옥수는 이 시기에 나오는 질문들에 바로 답할 수 있도록 납품 이후에도 연결 상태를 유지합니다.

왜 세 사례 모두 계속 연락이 이어지는가

세 사례에서 공통으로 일어난 일은 이것입니다. 처음에 하나를 해결하고 나면, 다음 문제가 보이기 시작한다는 것입니다.

자동화를 경험하기 전에는 "이런 것도 자동화가 되나?"라는 질문 자체를 못 합니다. 어떤 것이 가능한지 모르기 때문입니다. 그런데 한 번 경험하고 나면 기준이 달라집니다. "저 반복 작업도 비슷한 방식으로 되지 않을까?" 하는 질문이 생깁니다.

이 질문이 추가 의뢰로 이어집니다.

이것은 영업 전략이 아닙니다. 사람이 실제로 자동화를 경험하면 생기는 자연스러운 반응입니다. 그래서 첫 번째 구축을 제대로 하는 것이 중요합니다. 제대로 된 첫 경험이 있어야 다음 질문이 생깁니다.

반대로, 첫 구축에서 시스템이 제대로 쓰이지 않으면 "역시 자동화는 잘 안 맞나"는 결론이 남습니다. 이 결론이 한 번 자리 잡으면 다음 시도가 어렵습니다. 좋은 첫 경험을 만드는 것, 그것이 납품 이후 한 달을 제대로 설계해야 하는 이유입니다.

세 사례에서 두 번째 의뢰가 이어진 것은 이 좋은 첫 경험이 있었기 때문입니다. 한 번 함께 일해본 경험이 있으면, 다음에 새 문제를 가져올 때 처음 상담보다 훨씬 빠르게 진행됩니다. 업무 방식, 시스템 구조, 어떤 방향을 원하는지가 이미 맥락으로 남아 있어서, 같은 설명을 반복하지 않아도 됩니다.

첫 2주 동안 나오는 질문들의 패턴

납품 직후 2주 동안 가장 많이 나오는 질문들이 있습니다. 세 사례에서 공통으로 나온 유형들입니다.

"이 경우는 어떻게 되나요?" — 구축 당시 설계하지 않은 예외 상황이 실제 업무에서 나타납니다. 예를 들어 보험 PDF 사례에서는 기존에 다루지 않던 보험사 양식이 들어왔을 때 어떻게 처리해야 하는지가 나왔습니다. 이 질문에 바로 답하고 빠르게 조정하는 것이 초기 2주의 실제 작업입니다.

"이 부분을 바꿀 수 있나요?" — 실제로 써보니 원래 설계보다 이쪽이 편하겠다는 판단이 생깁니다. 작은 개선 요청들입니다. 이것을 빠르게 반영할 수 있는 구조로 만들어두면, 처음 2주 안에 시스템이 실제 업무에 정확하게 맞는 형태로 수렴합니다.

"이게 안 될 때는 어떻게 하나요?" — 자동화 시스템이 예상치 못한 이유로 멈추거나 결과가 이상할 때 어떻게 대응해야 하는지 물어봅니다. 이 경우를 위한 대응 방법을 인수인계 단계에서 미리 안내합니다. 스스로 판단할 수 있는 수준까지 설명하면, 이후에 소소한 이슈는 혼자 처리할 수 있게 됩니다.

이 질문들에 답하면서 시스템은 점점 실제 업무에 맞게 다듬어집니다. 납품일 기준으로 완벽한 시스템이 나오는 것이 아니라, 납품 이후 2주를 함께 지나면서 진짜로 맞는 형태가 만들어집니다.

인수인계가 구축의 일부인 이유

많은 개발 외주에서 인수인계는 "마지막에 설명 한번 해드리는 것"으로 여겨집니다. 문서 한 장 드리고, 한 번 시범을 보여드리고, "모르면 연락하세요"로 끝납니다.

이 방식의 문제는 실제 업무 상황에서는 처음 쓰면서 나오는 궁금증을 그 자리에서 해결할 수 없다는 것입니다. 한 번 설명은 들었지만 실제로 혼자 써보면서 막히는 것은 다릅니다. 그 순간 연락할 수 있는 구조가 없으면, 막힌 채로 두거나 포기하게 됩니다.

옥수의 인수인계는 구축과 함께 진행됩니다. 단순히 "이렇게 쓰는 겁니다"를 넘어서, 왜 이렇게 만들었는지, 어떤 원리로 동작하는지, 어떤 부분을 직접 수정할 수 있는지를 함께 살펴봅니다. 그래야 나중에 혼자서 판단할 수 있습니다.

세 사례에서 모두 "본인이 직접 운영할 수 있는 수준까지 전달하는 것"이 구축의 일부였습니다. 보험설계사분은 직접 운영 가능한 수준으로 인수인계가 완료됐고, 업무지시 사례에서는 새 도구 없이 기존 방식 그대로 쓸 수 있게 설계됐으며, 블로그 자동화에서는 초안 검토와 발행까지 혼자 진행할 수 있게 됐습니다.

이렇게 설계하면 납품 이후 월 이용료 없이 직접 운영이 가능합니다. 유지비 없는 구조가 가능한 이유는 처음부터 그렇게 설계했기 때문입니다.

납품 후에도 연결이 유지되는 구조

수익 모델 측면에서도 이 접근이 중요합니다. 옥수는 월 이용료를 받지 않습니다. 한 번 만들어서 고객이 직접 운영하는 구조입니다. 그럼에도 세 고객 모두 구축 이후에도 연락이 이어지고 있는 것은, 추가 의뢰가 생겼기 때문입니다.

처음에 하나를 해결했고 → 믿음이 생겼고 → 다음 문제를 다시 들고 왔습니다.

이 흐름이 지속 협업의 구조입니다. "납품 후에 버려지는 것 아닌가"라는 걱정을 하시는 분들이 있는데, 실제로는 납품 이후가 관계의 시작인 경우가 많습니다. 처음 한 달을 같이 지나면서 생기는 신뢰가, 다음 문의를 낯설지 않게 만들어 줍니다.

납품 후 한 달을 쉽게 만드는 설계 원칙들

세 사례에서 공통으로 적용된 설계 원칙들이 있습니다. 납품 이후 한 달을 쉽게 만든 것들입니다.

기존 도구를 바꾸지 않는다: 보험설계사분은 본인이 직접 만들어 쓰던 엑셀 템플릿을 그대로 유지했습니다. 업무지시 사례에서는 이미 쓰던 스프레드시트를 그대로 뒀습니다. 블로그 자동화는 이미 운영 중인 워드프레스에 연결했습니다. 새 도구를 배우는 부담 없이 시스템이 기존 흐름 안에 들어온 덕분에 첫 달이 편했습니다.

직접 운영 가능한 수준까지만 구축한다: 자동화는 많을수록 좋지 않습니다. 고객이 이해하고 직접 건드릴 수 없는 부분은 블랙박스가 됩니다. 블랙박스가 늘어날수록 작은 문제에도 외부 도움이 필요해집니다. 옥수는 고객이 직접 이해할 수 있는 범위에서 구축하고, 그 범위를 최대한 넓히는 방향으로 인수인계합니다.

처음부터 예외 상황을 열어둔다: 어떤 업무든 처음에 설계하지 못한 예외가 생깁니다. 이것을 오류가 아니라 과정으로 봅니다. 납품 이후 2주 동안 나오는 예외 상황들은 시스템이 더 정확하게 맞춰지는 과정입니다. 그래서 이 기간에 연락이 잦아지는 것을 문제로 보지 않고, 오히려 잘 되고 있는 신호로 봅니다.

이 세 가지 원칙이 갖춰졌을 때, 납품 이후 한 달이 불안한 시간이 아니라 시스템이 자리를 잡는 시간이 됩니다.

비슷한 상황에 있는 분들께

자동화 시스템 도입이 망설여지는 이유 중 하나는 "만들어두면 아무도 안 쓸 것 같다"는 걱정입니다. 이 걱정은 충분히 합리적입니다. 실제로 도입 후 방치되는 시스템이 많으니까요. 그 이유의 상당 부분은 납품 직후 2주를 어떻게 설계했느냐에 달려 있습니다.

옥수가 인수인계를 구축 범위에 포함시키고, 납품 이후에도 초기 질문에 응답하는 이유가 여기 있습니다. 시스템이 업무에 실제로 붙어서 쓰이게 되는 첫 2주를 함께 지나는 것이, 구축 자체만큼 중요한 과정이라고 생각합니다.

납품 이후 어떻게 인수인계가 이루어지는지에 대해서는 인수인계까지가 구축입니다 글에서 더 자세히 정리했습니다. 납품 이후에도 혼자 운영할 수 있는 구조를 만드는 것이 옥수의 방향이고, 그 과정이 어떻게 이루어지는지 실제 사례와 함께 확인하실 수 있습니다.

지금 반복하는 업무가 있고 이것을 자동화할 수 있는지 궁금하다면, 30분 무료 진단에서 먼저 살펴볼 수 있습니다. 가능한 것과 안 되는 것을 솔직하게 말씀드립니다. 납품 이후 어떻게 함께 지내는지도 함께 설명드립니다. 영업 전화 없이, 진단만 먼저 받을 수 있습니다.

자동화를 시작하기 전 어떤 업무부터 해야 할지 판단 기준이 궁금하다면 업무 자동화 대상 선정 가이드도 참고해 보세요. 납품 이후를 잘 설계하는 것만큼, 무엇을 자동화할지 처음에 잘 고르는 것도 중요하고, 두 가지가 모두 잘 맞아야 시스템이 오래 쓰입니다.