실패할 것 같은 프로젝트를 거절하는 기준 — 진단에서 쌓인 판단들

거절도 이 일의 일부입니다

진단 신청이 들어오면 먼저 들어봅니다. 어떤 업무를 자동화하고 싶은지, 지금 어떻게 하고 있는지, 어떤 부분이 가장 불편한지. 이야기를 충분히 듣고 나서 "할 수 있는지 없는지"를 말합니다.

없는 경우도 있습니다. 기술적으로 불가능한 것은 드물지만, "지금 이 상태에서는 시작하면 안 된다"고 판단되는 경우는 꽤 됩니다. 그런 경우엔 솔직하게 거절합니다.

이유 없이 그냥 "안 됩니다"라고 하지는 않습니다. 어떤 조건이 갖춰지면 다시 이야기할 수 있는지, 지금 할 수 있는 더 작은 시작이 있는지를 같이 이야기합니다. 그래도 결론이 "지금은 아니다"이면 그렇게 말합니다.

이 글은 그 기준들을 정리한 것입니다. 옥수가 어떤 경우에 거절하는지, 왜 그런 판단을 하는지를 공개하는 이유는 하나입니다. 의뢰하기 전에 미리 알면 서로 시간을 아낄 수 있기 때문입니다.

"안 됩니다"라는 말이 나쁜 서비스처럼 느껴질 수 있습니다. 그런데 지금 상태로 시작하면 결과가 안 좋을 것이 뻔한 경우에 "됩니다"라고 말하는 것이 더 나쁜 서비스입니다. 구축비가 나가고, 시간이 들고, 결과에 실망이 따라오는 과정은 양쪽 모두에게 손해입니다. 그 판단을 나중에 하는 것보다 처음에 하는 것이 낫습니다.

첫 번째 기준: 데이터가 없거나 정리되지 않은 경우

자동화는 데이터를 가지고 일합니다. 주문이 시트에 쌓이게 하려면 주문 데이터가 어딘가에 있어야 하고, PDF에서 숫자를 꺼내려면 PDF가 읽을 수 있는 형태여야 하며, 재고를 자동으로 집계하려면 재고 정보가 하나의 기준으로 관리되고 있어야 합니다.

진단에서 가장 자주 마주치는 문제가 바로 이 데이터 상태입니다. 엑셀 파일이 담당자마다 다른 형식으로 만들어져 있거나, 주문 정보가 카카오톡 채팅방에만 흩어져 있거나, 구매 내역이 종이 영수증으로만 남아 있는 상황입니다.

데이터 문제가 얼마나 자주 등장하냐면 — 진단을 신청하시는 분 중에 "데이터가 이미 잘 정리되어 있습니다"라고 오시는 경우보다, 이야기를 듣다 보면 데이터 문제가 드러나는 경우가 더 많습니다. 자동화가 안 되는 것이 기술 문제가 아니라 데이터 문제인 경우입니다.

이런 상태에서 자동화를 연결하면 두 가지 문제가 생깁니다. 하나는 자동화가 데이터를 읽지 못해 오류가 나는 것입니다. 다른 하나는 자동화가 돌더라도 틀린 결과를 조용히 내는 것입니다. 두 번째가 더 위험합니다. 오류는 눈에 보이지만, 틀린 결과는 한동안 발견을 못 합니다. 재고 수량이 잘못 집계된 채로 몇 달이 지나고 나서야 문제가 드러나는 경우가 바로 이것입니다.

해외 사례이지만 비슷한 패턴이 반복됩니다. 제조기업이 AI로 재고 관리를 자동화하려 했는데, ERP 품목 코드와 실물 창고 바코드 체계가 달라 재고 수량의 15%가 부정확하게 집계되었고, 결국 프로젝트가 6개월 지연된 사례가 있었습니다. 데이터 문제는 AI나 자동화 기술의 실패가 아닙니다. 기반 데이터의 문제입니다. 인공지능산업 관련 설문에서 기업의 84%가 데이터를 AI 프로젝트의 주요 과제로 꼽는 이유가 이것입니다.

반대로, 데이터가 잘 준비된 경우에는 어떻게 다른지를 이야기하면 더 명확합니다. 보험설계사 업무 자동화 사례(PDF 엑셀 자동입력 사례)에서는 시작부터 "보험사에서 오는 PDF의 구조가 일정하다"는 조건이 있었습니다. 같은 형식의 PDF가 반복적으로 들어오고, 그 안에서 꺼내야 하는 항목이 정해져 있었습니다. 데이터 기반이 분명했기 때문에 구축이 빠르게 됐고, 결과 품질도 안정적이었습니다.

데이터가 정리되지 않은 상태에서 자동화를 먼저 시작하는 것은 내용을 정하지 않고 계약서 양식부터 고르는 것과 비슷합니다. 자동화를 연결하기 전에 어떤 데이터를 어떤 형태로 만들어야 하는지를 먼저 정리해야 합니다. 이 준비가 되어 있지 않으면 구축을 시작하는 것이 의뢰인에게도 손해입니다. 구축비가 나가고 나서 "데이터부터 정리해야 했다"는 결론이 나오는 것이 가장 피하고 싶은 상황입니다.

데이터 준비가 왜 자동화보다 먼저인지는 엑셀 파일이 팀마다 달라서 자동화가 멈추는 이유에서 더 자세히 다뤘습니다.

두 번째 기준: 업무 흐름이 아직 사람 머릿속에만 있는 경우

"견적서 나가는 과정을 자동화하고 싶어요"라는 말 뒤에 "그게 지금 어떻게 되고 있나요?"를 물으면, "그때그때 달라요"라는 답이 나오는 경우가 있습니다.

담당자에 따라 다르거나, 거래처에 따라 다르거나, 그날 상황에 따라 다른 업무입니다. 이런 업무는 지금 상태로는 자동화가 안 됩니다. 자동화는 규칙을 코드로 만드는 것인데, 규칙이 없으면 만들 코드도 없습니다.

이것은 기술 문제가 아닙니다. 업무가 아직 정리되지 않은 것입니다. 사람이 하면 그때그때 판단해서 처리할 수 있지만, 프로그램은 판단 기준이 명확히 정의되어 있지 않으면 동작하지 않습니다.

반대로, 업무 흐름이 잘 정리된 경우의 예는 업무 지시 자동화 사례(업무 지시 자동 기록 이야기)에서 볼 수 있습니다. 이 사례에서 자동화가 가능했던 이유 중 하나는, 업무 지시의 형태가 "담당자·기한·내용"이라는 공통 구조를 갖고 있었기 때문입니다. 구두로 오든 메신저로 오든 내용은 항상 이 세 가지를 담고 있었습니다. 형태가 다양해도 구조가 일정한 경우라면 자동화가 됩니다.

이런 경우엔 자동화보다 먼저 업무 정리가 필요하다는 말을 합니다. "A 거래처는 이 형식, B 거래처는 저 형식"이 문서화되어 있고, 그 규칙이 특정 상황에서 사람이 별도 판단을 끼어넣지 않아도 흐를 수 있을 때, 그때 자동화를 연결하는 것이 맞습니다.

업무 흐름 정리 후에 다시 진단을 받으러 오시는 분들이 있습니다. 그런 경우 대부분 구축이 빠르게 됩니다. 정리된 업무는 코드로 옮기기 쉽기 때문입니다. 처음 진단에서 거절이 나왔더라도, 업무를 먼저 정리하면 두 번째 진단에서 구축으로 이어지는 경우가 많습니다.

세 번째 기준: 기대가 기술의 실제 수준을 벗어난 경우

"AI가 들어오는 메일을 다 읽고 알아서 판단해서 답장까지 자동으로 보내줄 수 있나요?"

가능한 경우도 있고 안 되는 경우도 있습니다. 판단 기준이 명확하고 답장 내용이 정해진 유형의 문의라면 됩니다. "배송 조회 요청이면 운송장 번호 안내, 환불 문의이면 환불 절차 안내"처럼 유형이 분류되고 각 유형의 처리 방식이 정해져 있다면 자동화가 가능합니다.

그런데 "어떤 메일인지에 따라 답이 완전히 달라지고, 내가 직접 보지 않으면 마음에 안 든다"는 경우라면 완전 자동화는 어렵습니다. 사람이 개입하는 단계 — 예를 들어 AI가 초안을 만들고 담당자가 확인·수정 후 발송하는 방식 — 를 포함해야 합니다.

진단에서 기대치를 듣고 조정이 필요하다고 느낄 때, 가장 조심하는 것은 "일단 해봅시다"입니다. 기대와 결과의 간극이 클수록 구축 후 실망도 큽니다. 실망은 자동화 전체에 대한 불신으로 이어지고, "자동화가 우리 회사엔 맞지 않는다"는 결론을 내리게 만듭니다.

처음부터 할 수 있는 것과 없는 것을 정확히 나누는 것이 양쪽 모두에게 낫습니다. "이 부분은 됩니다, 이 부분은 사람이 확인해야 합니다, 이 부분은 지금 기술로는 어렵습니다"를 명확히 하고 시작하면, 결과가 기대에서 크게 벗어나지 않습니다.

생성형 AI가 글을 쓰고 판단하는 능력이 빠르게 좋아지고 있는 것은 사실입니다. 그러나 2026년 현재 기준으로 AI는 "비슷한 상황에서 비슷한 판단"은 잘 하지만, "매번 다른 맥락에서 사람과 같은 수준의 정확한 판단"은 전부 맡기기 어렵습니다. 특히 회사 내부 사정이나 관계를 반영한 판단, 법적 책임이 따르는 결정은 사람이 검증하는 단계가 반드시 필요합니다.

가트너는 기업 AI 에이전트 프로젝트의 40% 이상이 2027년 말까지 취소될 것으로 전망했습니다. 그 이유의 상당 부분은 기술 실패가 아닌 기대치와 현실의 간극입니다. 처음에 기대를 현실에 맞게 조정해두면 이 통계에서 자유로울 수 있습니다.

네 번째 기준: 결과를 검증할 수 있는 사람이 없는 경우

"AI가 알아서 하면 되지 않나요?"

자동화가 내놓은 결과를 누군가는 확인해야 합니다. 특히 숫자, 금액, 고객 정보가 들어가는 업무라면 더욱 그렇습니다.

보험설계사 업무 자동화 사례에서도 이 부분이 핵심이었습니다. 보험사 PDF에서 데이터를 추출해 엑셀에 채워넣는 과정을 자동화했지만, 결과를 담당자가 직접 확인하는 단계는 유지했습니다. AI가 내놓은 값이 PDF 원본과 다를 경우를 사람이 잡아내야 하기 때문입니다. "사람 손이 완전히 빠진" 자동화가 아니라, "확인에 쓰는 시간이 크게 줄어든" 자동화를 만든 것입니다. 수작업으로 전부 옮기던 시간이 사라졌지만, 최종 확인은 사람이 합니다.

"자동화된 뒤에 결과를 확인하는 사람이 없다"는 상황은 위험합니다. 조용히 틀린 데이터가 쌓이다가 나중에 한꺼번에 문제가 터집니다. 자동화 구축 전에 "누가 결과를 언제 확인하는가"를 정하는 것이 설계의 일부입니다. 검증 담당자가 없거나, 결과를 확인할 의지나 여유가 없는 상황이라면 구축을 시작하는 것이 오히려 리스크입니다.

거절이 아니라 "지금은 아직"인 경우

위 기준 중 하나에 걸린다고 해서 무조건 거절하는 것은 아닙니다. 상황에 따라 "지금 당장은 아니지만, 이걸 먼저 하면 다음에 할 수 있다"고 이야기합니다.

데이터가 없다면 → 데이터를 쌓을 방법을 먼저 만듭니다. 업무 흐름이 정리되지 않았다면 → 규칙을 문서로 정리하는 것부터 합니다. 기대치가 높다면 → 처음에는 사람이 검토하는 반자동 방식으로 시작합니다. 검증 체계가 없다면 → 확인 담당자와 확인 주기를 먼저 정합니다.

이런 경우 진단에서 "지금 할 수 있는 첫 번째 단계"를 같이 찾습니다. 구축을 받지 않더라도, 방향을 정하는 데 도움이 되는 30분이 되기를 바라면서 진단을 운영하고 있습니다.

가끔 진단에서 "지금은 아직"이라는 말을 하고 나면 섭섭해하시는 경우도 있습니다. 이해가 됩니다. 기대를 안고 신청하셨는데 시작도 안 된다는 말을 들으면 허탈할 수 있습니다. 그 때문에 거절할 때는 이유와 함께, "이것부터 하면 됩니다"를 최대한 구체적으로 이야기하려 합니다. 빈손으로 돌아가지 않도록.

진단에서 구축으로 이어지는 경우의 특징

반대로 진단에서 구축이 빠르게 결정되는 경우들도 있습니다. 공통점이 있습니다.

업무의 입력과 출력이 명확합니다. "이런 파일이 들어오면, 저런 파일이 나와야 한다"가 미리 정해져 있습니다. 자동화가 해야 할 일이 구체적으로 정의되어 있으면, 구축 범위를 잡기 쉽고 견적도 정확해집니다.

반복 횟수가 측정 가능합니다. "한 달에 약 200번", "매일 아침 1회" 같은 감각이 있습니다. 횟수를 알면 어느 수준의 자동화가 효과적인지 판단이 됩니다.

현재 쓰는 도구가 명확합니다. 구글 시트, 이메일, 특정 앱 등 어떤 도구로 지금 일을 하고 있는지 파악이 되어 있습니다. 새로운 도구를 배우고 싶지 않다는 방향도 명확하면 더 좋습니다.

이 세 가지가 준비된 상태에서 오면 진단 30분이 충분히 구체적인 방향을 잡는 자리가 됩니다. 반면 셋 중 하나라도 불분명하면 진단이 "이걸 먼저 정리해야 한다"는 방향으로 흐르게 됩니다.

판단 기준 한눈에 보기

거절하고 나서 어떻게 되는가

거절한 뒤에 연락이 끊기는 경우도 있습니다. 당연합니다. "가능하다"는 답을 원하셨는데 그렇지 않은 결론이 나왔으니까요.

그런데 몇 달 뒤에 다시 연락이 오는 경우도 있습니다. "말씀해 주신 대로 데이터 정리를 먼저 했더니 이제 될 것 같아서요"라고. 그때 다시 진단을 해보면 처음과 상황이 달라져 있습니다. 구축이 빠르게 됩니다. 인수인계도 수월합니다. 준비가 된 상태에서 시작한 자동화는 안착이 빠릅니다.

거절을 기억하는 분들도 있습니다. "처음에 안 된다고 하셨는데, 그 말을 믿고 준비했더니 결국 됐다"는 피드백을 들은 적이 있습니다. 그 피드백이 이 판단 기준을 유지하게 하는 이유 중 하나입니다.

구축 후 재구매율이 높은 이유도 여기에 있습니다. 처음부터 솔직하게 이야기하면 기대와 결과의 간극이 작습니다. 결과가 기대와 비슷하면 다음 의뢰가 생깁니다. 지금까지 구축한 프로젝트들은 전부 추가 의뢰나 지속 연락으로 이어지고 있습니다. 처음에 필터를 엄격하게 했기 때문에 가능한 결과입니다.

거절이 선물이 되는 경우

이상하게 들릴 수 있지만, 거절이 의뢰인에게 도움이 되는 경우가 있습니다.

진단 신청을 받으면서 이야기를 듣다 보면, 원래 원하시던 자동화보다 더 작고 빠른 해결책이 보이는 때가 있습니다. "급여 계산 자동화를 원하셨는데, 근태 기록 방식만 바꾸면 지금 쓰시는 엑셀로 계산이 훨씬 쉬워질 것 같습니다"처럼. 구축이 아니라 업무 방식의 작은 변경이 더 효과적인 경우입니다.

이런 경우엔 구축을 권하지 않습니다. 그리고 그 이야기가 의뢰인에게 도움이 됩니다. 비용을 쓰지 않고 더 나은 방향을 찾는 것이 진단의 진짜 역할이기 때문입니다.

거절이나 다른 방향 제안 모두, 결국 같은 목표를 향합니다. 의뢰인에게 실제로 작동하는 결과를 만드는 것. 당장 구축 계약을 맺는 것이 그 목표는 아닙니다.

자주 받는 질문들

"한번 해보고 안 되면 그때 그만두면 안 되나요?"

구축비가 이미 들어간 뒤에 "안 됩니다"를 발견하면 양쪽 모두에게 손해입니다. 구축 전에 판단하는 것이 훨씬 효율적입니다. 처음부터 가능 여부를 확인하는 것이 진단의 목적입니다.

"경쟁사는 해준다는데요."

해준다고 하는 것과, 실제로 제대로 돌아가게 구축하는 것은 다릅니다. 자동화를 연결만 해두고 실제로 쓸 수 없는 상태가 되는 경우가 있습니다. 무엇을 기준으로 "됐다"고 판단하는지를 미리 합의하는 것이 중요합니다. 옥수는 "사용자가 실제로 쓸 수 있는 상태"를 기준으로 합니다.

"데이터 정리를 어디서부터 시작해야 할지 모르겠어요."

진단에서 그 방향을 이야기해드릴 수 있습니다. 자동화 구축을 결론으로 내지 않더라도, 어떤 준비가 필요한지를 명확히 하는 자리가 될 수 있습니다.

"이미 비용을 들여서 자동화를 시도해봤는데 잘 안 됐어요."

그런 경험이 있는 분들이 오시는 경우도 있습니다. 이전에 어떤 방식으로 시도했고, 어디서 막혔는지를 들어보면 이번에는 어떻게 접근해야 할지가 보입니다. 이전 실패가 오히려 이번 구축의 방향을 잡는 데 도움이 되는 경우도 많습니다.

마치며 — 진단을 신청하기 전에 확인할 것들

위 기준들을 보면서 "우리 회사는 지금 어느 상태인지"를 먼저 확인해보시길 권합니다.

자동화하려는 업무의 데이터가 어디에 있고 어떤 형태인지, 처리 규칙이 말로 설명될 수 있는지, 결과를 확인할 담당자가 있는지. 이 세 가지가 명확하면 진단에서 더 구체적인 이야기를 할 수 있습니다.

구체적인 이야기가 나오면 견적도 명확해지고, 구축도 빠릅니다. 거절 가능성도 낮아집니다. 무엇보다, 구축 후 사용하면서 "이게 아닌데"가 나올 가능성이 줄어듭니다.

시작 전에 잠깐 멈춰서 확인하는 것이 나중에 돌아오는 수고보다 적습니다. 준비가 됐다고 느껴지시면, 또는 준비가 됐는지 모르겠다면 그것도 확인하러 오셔도 됩니다. 어떤 결론이 나든, 다음에 해야 할 일이 명확해지는 30분이 되도록 운영하고 있습니다.

30분 무료 진단 신청은 여기에서 할 수 있습니다. 가격 문의가 궁금하시면 요금 안내를 먼저 확인하셔도 됩니다. 영업 전화는 없습니다.