문의 후 무슨 일이 일어나나 — 접수부터 납품까지의 여정

자동화 외주를 처음 고려하는 분들이 가장 많이 갖는 불안 중 하나가 이것입니다. "문의를 하면 어떻게 진행되는 건지 모르겠다." 어떤 서류가 필요한지, 얼마나 걸리는지, 중간에 무엇을 확인해야 하는지, 다 만들어졌을 때 어떻게 받는지. 막연한 것들이 많습니다.

일반적인 IT 외주 개발에서 경험이 있는 분들도 비슷한 질문을 하십니다. "기존에 경험한 것과 어떻게 다른가요?" 자동화 외주가 처음인 분과 IT 프로젝트 경험이 있는 분 모두에게 이 글이 출발점이 됐으면 합니다.

이 글은 그 과정을 처음부터 끝까지 순서대로 정리합니다. 지금까지 완료된 세 건의 프로젝트를 기준으로 씁니다. 만들어졌으면 하는 과정이 아니라, 실제로 그렇게 진행된 과정입니다.

일반적인 외주 개발 vs. 옥수의 방식

자동화 외주가 어떻게 진행되는 것이 일반적인지부터 짚겠습니다. IT 외주 개발 업계에서 프로젝트는 대체로 문의, 요구사항 정리와 계약, 개발, 검수, 인수인계의 흐름으로 진행됩니다. 플랫폼을 통한 업무 자동화 외주는 단순한 업무는 며칠 내로 완료되기도 합니다.

옥수의 방식은 단계 구성은 같지만 각 단계에서 무엇을 하는지가 다릅니다. 특히 세 가지가 다릅니다.

이 차이가 실제로 어떻게 진행 과정에 반영되는지를 단계별로 설명합니다.

1단계: 문의 접수

문의 양식에 지금 어떤 일이 번거로운지 적어서 보내시면 됩니다. 길게 쓰지 않아도 됩니다. "발주서를 매일 손으로 옮기고 있다", "회의가 끝나면 회의록 정리에 한 시간이 걸린다", "거래처마다 양식이 달라서 취합이 힘들다"처럼 상황을 적는 것으로 충분합니다. 기획서나 요구사항 정의서를 준비해 오실 필요가 없습니다.

문의를 받으면 영업 전화 연결이나 자동화 도입을 설득하는 제안서를 보내는 방식으로 이어지지 않습니다. 문의 내용을 확인한 뒤 30분 진단 일정을 잡는 안내를 드립니다. 연락은 이메일이나 메시지로 합니다. 전화를 원하는 분도 계신데, 화면을 보면서 이야기하는 편이 서로에게 훨씬 빠르기 때문에 구글 미트를 기본으로 합니다.

자동화 상담 전에 교육이 맞는지 구축이 맞는지부터 판단하고 싶다면, 교육과 구축의 기준을 정리한 글이 도움이 됩니다. 진단 전에 읽어두시면 30분을 더 효율적으로 쓸 수 있습니다.

2단계: 30분 무료 진단

진단은 구글 미트로 진행합니다. 지금까지 진행된 모든 프로젝트가 이 방식으로 시작됐습니다. 보험설계사분도, 사무·운영 업체 대표님도, 기술 서비스 업체 T사도 모두 구글 미트 원격으로 진행했습니다. 방문이 필요 없습니다.

30분 동안 확인하는 것은 크게 세 가지입니다.

첫째, 지금 어떤 방식으로 업무를 처리하는지입니다. "PDF를 프린트해서 보고 엑셀에 타이핑한다", "메신저 메시지를 복사해서 시트에 붙인다"처럼 실제 흐름을 봅니다. 기술적인 설명은 필요 없습니다. 일이 어떻게 흘러가는지를 말로 풀어주시면 됩니다.

둘째, 어떤 도구를 쓰고 있는지입니다. 엑셀인지, 구글 시트인지, 카카오, 이메일인지, 특정 소프트웨어인지를 봅니다. 쓰던 도구를 버리게 하지 않는 것이 원칙이어서, 현재 도구를 파악하는 것이 설계의 출발점입니다. 어떤 도구든 현재 쓰는 것이 있다면 그것을 중심으로 설계를 잡습니다.

셋째, 가능한지 아닌지를 판단하는 것입니다. 진단의 목적은 "됩니다" 또는 "지금은 어렵습니다"를 말씀드리는 것입니다. 모호한 말을 하지 않으려 합니다. 가능하다면 어떤 방식이 현실적인지까지 말씀드립니다. 가능하지 않다면 왜 어려운지, 무엇이 먼저 되어야 하는지를 설명드립니다.

진단 자리에서 구축 여부를 바로 결정하실 필요가 없습니다. 실제로 진단에서 결론이 나온 뒤 한 달이 지나고 "이제 진행하겠다"고 연락 주시는 경우도 있습니다. 진단 이후 별도 영업 연락을 드리지 않기 때문에, 내부적으로 충분히 논의하고 결정하시면 됩니다.

30분 진단에서 실제로 어떤 질문이 오가는지 궁금하시다면, 진단 자리에서 실제로 무슨 일이 일어나는지 정리한 글을 먼저 읽어두시면 이 단계가 더 명확해집니다.

3단계: 범위 확정과 견적

진단에서 "해볼 만하다"는 판단이 서면 무엇을 어디까지 만들지 범위를 확정합니다. 범위가 확정된 뒤에 견적이 나옵니다. 범위를 정하기 전에 견적을 요청받는 경우도 있는데, 그 경우에는 범위를 먼저 잡아야 한다고 말씀드립니다. 범위 없는 견적은 나중에 반드시 달라집니다.

범위를 잡을 때 함께 정하는 것들이 있습니다.

만드는 것의 범위입니다. 어떤 업무의 어느 단계까지 자동화할 것인지를 명확히 합니다. "이 부분까지는 사람이 판단하고, 이 부분부터 자동화한다"는 선을 함께 그어야 나중에 이견이 없습니다. 범위를 크게 잡을수록 완성까지 오래 걸리고, 완성됐을 때 기대와 다를 가능성도 높아집니다.

인수인계 형태입니다. 담당자가 직접 운영할 수 있게 할 것인지, 완전 자동화로 사람이 개입하지 않는 구조로 만들 것인지를 정합니다. 이 결정이 구축 방식에 영향을 줍니다. 담당자가 직접 운영하는 방식은 작은 변화가 있을 때 대처할 수 있는 자율성이 생기는 반면, 완전 자동화는 담당자의 개입이 없어도 되는 대신 변화가 생겼을 때 수정이 필요합니다.

기간입니다. 옥수는 2주 파일럿을 기본으로 합니다. 범위에 따라 달라질 수 있지만, 실제로 쓸 수 있는 형태가 2주 안에 나오도록 범위를 그렇게 잡습니다. 2주 안에 완성될 수 없는 범위라면, 우선순위 높은 부분 하나를 먼저 2주 파일럿으로 진행하고 나머지는 이후 단계로 넘깁니다.

이 범위와 기간이 확정된 뒤 나오는 견적은 이후에 변경되지 않습니다. 진행 중에 예상치 못한 복잡함이 나오더라도 추가 청구를 하지 않습니다. 범위 안의 일은 견적 안에서 처리하는 것이 원칙입니다. 단, 범위 밖에서 새 요청이 생기면 그것은 다음 프로젝트로 잡습니다.

4단계: 구축 — 2주 파일럿이란 무엇인가

범위와 견적이 확정되면 구축이 시작됩니다. 2주 파일럿이라고 부르는 이 단계는 "완성본 납품"이 아니라 "실제로 써볼 수 있는 첫 번째 버전"을 만드는 것입니다.

구축 중에 진행되는 방식은 이렇습니다. 중간에 한 번 이상 확인을 거칩니다. 처음 설계한 방향이 실제 업무 흐름과 맞는지, 불편한 부분이 없는지를 직접 써보면서 확인하는 자리입니다. 이 자리에서 나온 피드백을 반영해 마무리합니다. 단, 범위 밖의 새 요구사항이 나오면 이번 파일럿에는 담지 않고 따로 기록해둡니다.

모든 구축은 원격으로 진행합니다. 보험설계사분의 PDF 자동화 프로젝트도, 사무·운영 업체의 발주 지시사항 자동화 프로젝트도, 기술 서비스 업체 T사의 워드프레스 블로그 자동화 프로젝트도 모두 구글 미트 원격으로 진행했습니다. 화면 공유로 실제 작동 여부를 함께 확인할 수 있기 때문에 방문보다 오히려 빠릅니다.

쓰던 도구를 버리게 하지 않는 것이 구축의 기본 원칙입니다. 엑셀을 쓰고 있으면 엑셀을 중심으로, 구글 시트를 쓰고 있으면 구글 시트를 중심으로 설계합니다. 사무·운영 업체의 프로젝트에서는 기존에 쓰던 스프레드시트를 그대로 유지하면서 ChatGPT와 Claude를 연결해 자동화를 구성했습니다. 익숙한 도구를 버리면 적응 비용이 생기고, 적응 비용이 생기면 자동화가 현장에서 쓰이지 않게 됩니다.

구축 중 중간 확인 자리는 방향 수정의 기회입니다. 처음 범위를 잡을 때는 "이렇게 하면 될 것 같다"는 예측으로 설계하지만, 실제로 만들어진 것을 보면 "이 부분은 이렇게 하는 게 더 편하겠다"는 판단이 생깁니다. 그 자리에서 방향을 조정하기 때문에 최종 납품이 처음 예측과 크게 다르지 않은 이유이기도 합니다. 중간 확인 없이 처음부터 끝까지 만들어서 납품하는 방식은 기대와 결과가 달라질 위험이 큽니다.

구축에서 가장 주의하는 것은 "정교한 시스템"보다 "실제로 쓰이는 시스템"을 만드는 것입니다. 담당자가 어려워서 안 쓰게 되는 시스템보다, 조금 단순하더라도 매일 쓰이는 시스템이 훨씬 가치 있습니다. 기능을 줄이더라도 쓰임새를 확보하는 쪽으로 방향을 잡습니다.

5단계: 납품과 인수인계

납품은 파일이나 링크를 전달하는 것으로 끝나지 않습니다. 담당자가 직접 쓸 수 있는 상태로 만드는 것까지가 납품입니다. 납품 자리는 일반적으로 구글 미트 원격으로 진행합니다. 화면을 공유하면서 실제로 작동하는 것을 함께 확인하고, 담당자가 직접 써보는 과정을 함께 합니다. 납품 자리에서 처음 보는 것이 아니라, 구축 중간에 이미 한 번 이상 확인을 거쳤기 때문에 납품 자리에서 크게 달라지는 것은 드뭅니다.

인수인계에는 두 가지 형태가 있습니다. 첫 번째는 담당자가 직접 운영하는 방식입니다. 어디서 무엇을 바꾸면 되는지, 오류가 생겼을 때 어디를 확인하면 되는지를 직접 해볼 수 있을 때까지 안내합니다. 보험설계사분의 PDF 자동화 프로젝트가 이 방식으로 마무리됐습니다. 납품 이후 혼자서 운영이 가능한 수준으로 전달된 것이 그분이 만족하신 지점 중 하나였습니다.

두 번째는 완전 자동화 방식입니다. 담당자가 시스템에 개입하지 않아도 자동으로 돌아가도록 만드는 것입니다. 기술 서비스 업체 T사의 워드프레스 자동 발행 시스템이 이 방식에 가깝습니다. 현장 경험을 말로 풀면 자동으로 글이 작성되고 발행까지 이어지는 구조로, 담당자의 별도 조작이 거의 없습니다.

어떤 방식이 맞는지는 범위 확정 단계에서 이미 합의가 된 상태입니다. 납품 단계에서 갑자기 달라지지 않습니다.

한 가지 더 말씀드리는 것이 있습니다. 납품 직후 예외 상황이 생길 수 있습니다. 테스트 단계에서는 없던 데이터 형식이 실제 운영 중에 나타나거나, 거래처가 양식을 바꾸는 경우가 생길 수 있습니다. 이런 예외 상황에 어떻게 대처하면 되는지를 납품 자리에서 함께 확인합니다. 범위 안에서 발생한 문제라면 추가 비용 없이 대응합니다.

월 유지비를 청구하는 구조가 아닙니다. 지금까지 세 건의 프로젝트 모두 납품 이후 유지비 없이 운영되고 있습니다. 유지보수가 필요한 상황이 생기면 그때 별도로 이야기합니다. "구독처럼 매달 요금이 나가는 건 아닌가요?"라고 물어보시는 분들이 많은데, 그런 구조가 아닙니다. 구축 비용을 한 번 내고 시스템을 받는 방식입니다. 이후에 기능 추가나 수정이 필요하면 그 건에 대해서만 별도로 이야기하면 됩니다.

납품 이후 — 세 프로젝트의 공통점

세 건의 프로젝트가 납품으로 완전히 끝나지 않았다는 것이 흥미로운 공통점입니다.

보험설계사분은 납품 이후 재구매 의사를 밝히고 지속적으로 연락을 주고 있습니다. 처음에 자동화한 업무 외에 다른 반복 작업을 추가로 정리하고 싶다는 이야기입니다.

사무·운영 업체의 발주 지시사항 자동화 프로젝트는 납품 이후 추가 의뢰로 협업이 이어지고 있습니다. 첫 번째 자동화가 실제로 쓰이고 효과를 확인하면서 다음 단계로 넘어가는 방식입니다.

기술 서비스 업체 T사도 워드프레스 자동 발행 시스템 구축 이후 추가 개선 요청으로 협업이 이어지고 있습니다.

세 건 모두에서 공통으로 나타나는 패턴이 있습니다. 작은 범위 하나를 완성하고, 그것이 실제로 돌아가는 것을 확인한 뒤, 다음 단계로 확장하는 방식입니다. 처음부터 큰 시스템을 목표로 했다면 이 패턴은 나타나지 않았을 것입니다. 작게 시작했기 때문에 첫 번째 납품이 성공으로 이어졌고, 성공이 다음 프로젝트로 연결된 것입니다.

이 패턴이 중요한 이유는 또 하나 있습니다. 자동화 외주를 처음 해보는 분들은 "한 번에 완성된 큰 시스템"을 목표로 하는 경향이 있습니다. 그 방향은 완성이 오래 걸리고, 완성됐을 때 현장에 맞지 않는 부분이 나올 수 있고, 수정 비용도 커집니다. 반면 작은 것을 먼저 완성하면, 실제로 돌아가는 것을 보면서 "다음에 무엇을 더하면 좋은지"가 구체적으로 보입니다. 그 구체성이 다음 프로젝트를 더 정확하게 설계하게 합니다.

문의 전에 무엇을 준비하면 좋은가

별도로 준비할 서류는 없습니다. 기획서, 요구사항 정의서, 기능명세서, 이런 것들을 미리 만들어 오실 필요가 없습니다. 오히려 그것들을 만들려고 하다가 문의 자체를 미루는 경우가 많습니다.

가져오시면 도움이 되는 것들이 있습니다. 지금 어떤 방식으로 그 업무를 처리하고 있는지 보여줄 수 있는 화면이나 파일입니다. 엑셀 파일, 구글 시트, 현재 쓰는 프로그램의 화면 캡처 같은 것들입니다. 있으면 30분을 더 효율적으로 쓸 수 있지만, 없어도 진단은 진행됩니다.

숫자도 가져오시면 좋습니다. 이 업무에 하루 혹은 주에 얼마나 시간이 걸리는지, 건수가 얼마나 되는지를 알면 자동화가 현실적으로 의미 있는지의 판단이 빨라집니다. 정확한 수치가 아니어도 됩니다. "하루에 한 번 한 시간 정도", "주에 열 건 정도" 같은 어림치도 충분합니다. 거꾸로, "얼마나 걸리는지 세어본 적이 없다"는 것 자체가 진단에서 파악하는 내용 중 하나가 됩니다. 진단 자리에서 함께 계산해보는 경우도 있습니다.

문의 전 준비사항을 더 자세히 확인하고 싶다면, 첫 미팅 전 준비하면 좋은 것들을 정리한 글이 구체적인 체크리스트를 담고 있습니다. 진단 일정을 잡기 전에 한 번 읽어보시면 시간을 아낄 수 있습니다.

진단 자리에서 "이런 것도 가능한가요?"를 여러 개 물어보셔도 됩니다. 가능한 것과 어려운 것을 구분해서 말씀드리겠습니다. "이건 됩니다", "이건 지금은 어렵고 이런 조건이 갖춰지면 됩니다", "이건 자동화보다 다른 방식이 더 낫습니다"처럼 솔직하게 말씀드리는 것이 이 자리의 목적입니다.

지금 문의할지 모르겠다면

"아직 확신이 없다", "정말 우리 업무에 맞는지 모르겠다", "비용을 써도 되는 상황인지 모르겠다" — 이런 상태라면 그대로 문의하셔도 됩니다. 진단의 목적이 정확히 그 판단을 돕는 것이기 때문입니다.

문의할 때 "이 정도 규모는 너무 작지 않나요?"라고 붙여서 보내시는 분들이 있습니다. 규모 기준은 없습니다. 담당자가 반복적으로 하는 작업이 있고, 그게 번거롭다면 진단해볼 이유가 됩니다. "이게 자동화가 되는 건지 모르겠다"는 것이 가장 좋은 문의 이유입니다. 세 건의 프로젝트 모두 그렇게 시작됐습니다.

진단 이후에 "지금은 아닌 것 같다"는 결론이 나올 수도 있습니다. 그게 틀린 결론이 아닙니다. 비용을 쓰지 않아도 된다는 판단이 명확해지는 것도 30분의 가치입니다. 반대로, 진단에서 "이건 생각보다 간단하게 할 수 있다"는 결론이 나오는 경우도 있습니다. 그동안 막연하게 어렵게 느껴졌던 것이 구체적으로 보이면 실행이 빨라집니다. 진단의 결과가 어느 쪽이든, 그 결과를 갖고 판단하는 것이 진단 없이 막연하게 고민하는 것보다 훨씬 빠릅니다.

지금까지 진단을 받은 분들 중 진단 자체가 부담이 됐다고 하신 분은 없었습니다. 30분이 끝나고 가장 많이 나오는 말은 "처음부터 이야기해볼 걸 그랬다"입니다.

진단 이후 영업 연락은 없습니다. 문의 → 진단 → 결정의 흐름에서 중간에 설득하는 단계가 없습니다. 진단에서 나온 결론을 갖고 내부적으로 충분히 논의한 뒤 연락 주시면 됩니다. 진단 후 바로 구축으로 넘어가지 않아도 됩니다. 결정이 내려지는 속도는 각자 다르고, 그 시간을 재촉하지 않는 것이 원칙입니다. 지금까지 진행된 세 건 모두 구축 결정까지 걸린 시간이 달랐고, 그 속도는 전적으로 의뢰하신 분의 상황에 맞게 진행됐습니다.

지금 어떤 업무가 번거로운지, 어느 정도 시간이 걸리는지를 간략하게 적어서 30분 무료 진단 신청으로 보내주시면 됩니다. 긴 설명이 없어도 충분합니다. 영업 전화 없이 일정 안내 메시지로 연락드립니다.