대표는 경영 보고를 빨리 받고 싶고, 영업팀은 제안서를 자동으로 만들고 싶습니다. 운영팀은 반복 문의를 줄이는 일이 급하다고 말합니다. 모두 필요해 보이는 상황에서 첫 과제를 고르려면 무엇을 비교해야 할까요? 기대 효과가 큰지와 함께 실제 자료로 시험할 수 있는지, 담당자가 결과를 책임지고 사용할 수 있는지를 봐야 합니다.
가장 눈에 띄는 기능이나 가장 적극적으로 요청한 부서의 일을 고르면 시작은 빠를 수 있습니다. 그러나 준비 자료가 없거나 다른 부서의 결정이 많이 필요한 과제라면 확인해야 할 일이 계속 늘어날 수 있습니다. 반대로 쉽다는 이유만으로 경영 문제와 관계가 약한 과제를 고르면 도입 결과를 설명하기 어렵습니다.
먼저 후보마다 어떤 자료로 어디까지 처리할지 적어 비교할 범위를 맞춥니다. 그다음 기대 효과, 준비된 자료와 담당자, 오류가 났을 때의 영향, 시험에서 확인할 내용을 살펴봅니다. 점수표를 쓰더라도 왜 그 점수를 줬는지와 아직 모르는 조건을 함께 적어야 선택 이유를 설명할 수 있습니다.
후보 과제의 크기부터 맞춰야 비교할 수 있습니다
‘영업 자동화’와 ‘주간 보고 초안 작성’을 나란히 놓으면 비교가 어렵습니다. 전자는 여러 업무를 포함하고 후자는 특정 작업입니다. 범위가 큰 과제는 효과가 커 보이지만 무엇을 만드는지 명확하지 않을 수 있습니다. 후보마다 “어떤 자료를 받아 AI가 무엇을 하고, 직원은 결과를 어디에 쓸 것인가”를 적어보세요. 한 업무에서 시험할 수 있는 정도로 범위를 맞추면 비교하기 쉽습니다.
가상의 기업 서비스 회사를 생각해보겠습니다. 고객 문의를 받아 작업자를 배정하고 완료 보고서를 제공합니다. 이 회사가 첫 AX 과제로 문의 분류, 완료 보고 초안, 경영 현황 요약을 검토한다고 가정합니다. 세 후보 모두 AI를 쓸 수 있어 보이지만 실제로 회사의 어떤 문제를 바꿀지는 각각 확인해야 합니다.
문의 분류 후보는 ‘모든 고객 대응 자동화’ 대신 ‘접수한 문의를 읽고 유형과 필요한 자료를 정리해 담당자에게 전달’로 좁힐 수 있습니다. 완료 보고 초안은 ‘현장 기록으로 고객에게 보낼 초안을 만들고 담당자가 검토’로 적습니다. 경영 현황 요약은 ‘주간 미완료 작업과 지연 사유를 정리해 운영 책임자가 지원할 일을 결정’으로 표현할 수 있습니다.
이렇게 적으면 AI의 결과를 누가 어떻게 사용하는지 드러납니다. 후보마다 업무의 시작과 끝이 달라지더라도 비교에 필요한 요소는 같아집니다. 이후 효과를 볼 때도 ‘문서가 자동으로 나온다’는 설명보다 담당자 재입력, 검토 시간, 배정 대기처럼 구체적인 변화를 논의할 수 있습니다.
후보가 너무 크다면 한 고객군이나 한 요청 유형으로 나누는 방법도 있습니다. 다만 시험 범위를 줄이면서 정작 해결하려던 어려운 작업을 모두 제외하지는 않았는지 확인해야 합니다. 실제로 시간을 쓰는 예외를 전부 제외하면 시험은 쉬워지지만 회사가 겪는 부담과 다른 일을 검증할 수 있습니다.
효과는 대표가 중요하게 보는 운영 변화로 설명합니다
첫 후보 비교에서 정밀한 투자수익률을 계산하기 어려울 수 있습니다. 아직 처리 시간이나 사용량을 충분히 모르기 때문입니다. 대신 무엇이 얼마나 자주 발생하며, 개선되면 누가 어떤 일을 더 잘할 수 있는지부터 설명합니다. 확인한 사실과 기대하는 결과를 구분해서 적어야 합니다.
가상 회사의 문의 분류는 담당자가 여러 문장을 읽고 유형을 정하는 일을 줄일 수 있습니다. 그러나 담당자를 배정할 권한이 있는 사람의 결정을 기다리느라 일이 늦어진다면, 분류가 빨라져도 고객의 대기 시간은 크게 줄지 않을 수 있습니다. 후보의 효과를 평가할 때는 AI가 맡을 단계뿐 아니라 다음 업무까지 살펴봐야 합니다.
완료 보고 초안은 반복되는 문서 작업을 줄이는 후보가 될 수 있습니다. 다만 직원이 결과를 다시 쓰는 시간이 많다면 예상 효과가 작아질 수 있습니다. 회사가 이미 표준 양식으로 빠르게 작성하고 있다면 다른 과제가 더 적절할 수도 있습니다. 힘들다는 인상만으로 정하지 말고 최근 자료와 처리 과정을 함께 봅니다.
경영 현황 요약은 대표의 재질문을 줄이거나 지원 대상을 빨리 정하는 데 도움이 될 가능성이 있습니다. 반면 지연 사유가 기록되지 않고 담당자의 기억에만 있다면 요약 기능보다 기록 정비가 먼저일 수 있습니다. 후보 비교 자료에 “지연 사유를 먼저 기록해야 요약을 시험할 수 있다”고 적어두세요.
‘시간을 줄인다’ 다음에 그 시간을 어디에 쓸지 한 문장을 붙여보세요. 더 많은 요청을 처리할지, 고객 안내를 앞당길지, 검토에 시간을 쓸지 정하면 효과의 의미가 구체적이 됩니다. 실제 지출 감소가 확인되지 않았는데 절약 시간을 곧바로 비용 절감액으로 바꾸지는 않습니다.
사용할 자료, 참여할 담당자, 시스템 연동을 확인합니다
구축 업체가 기술적으로 가능하다고 말하는 것과 회사가 지금 과제를 수행할 준비가 됐다는 것은 다를 수 있습니다. 자료를 제공하고, 맞는 결과를 판단하며, 시험에 참여하고, 바뀐 절차를 운영할 사람이 필요합니다. 이 조건이 없는 후보는 기대 효과가 커도 첫 과제로는 부담이 될 수 있습니다.
자료가 있는지와 시험에 쓸 수 있는지를 구분합니다
문서가 많다는 사실만으로 준비가 된 것은 아닙니다. 실제 업무를 대표하는 최근 자료인지, 결과와 비교할 답이나 완료 기록이 있는지, 필요한 범위에서 사용할 수 있는지 확인합니다. 자료를 모으는 데 얼마나 걸릴지 모른다면 우선 준비 항목으로 표시하고 확인 담당자를 정합니다.
가상 회사의 완료 보고 과제라면 평범한 현장 기록뿐 아니라 내용이 부족한 기록, 고객 추가 요청이 있었던 기록도 필요할 수 있습니다. 좋은 자료만 골라 쓰면 실제 검토 부담을 알기 어렵습니다. 첫 시험에서 모든 예외를 다룰 필요는 없지만 제외한 범위와 이유는 알고 있어야 합니다.
결과를 판단하고 사용할 책임자가 필요합니다
후보를 제안한 사람과 실제로 사용할 사람이 다를 수 있습니다. 경영 현황 요약은 대표가 원해도 지연 사유를 기록할 운영 담당자의 참여가 필요합니다. 문의 분류는 영업이 요청했더라도 실제 배정팀이 결과를 사용할 수 있어야 합니다. 책임자 한 명의 이름만 적기보다 자료를 준비할 사람과 결과를 검토할 사람이 시험에 참여할 수 있는지 확인합니다.
결과를 검토할 시간이 확보되지 않으면 구축이 끝나도 사용 판단을 미루게 됩니다. 담당자가 무엇을 비교하고 어떤 오류를 남길지 간단하게 합의해두면 좋습니다. 첫 과제는 바쁜 직원에게 추가 숙제를 주는 형태가 되기 쉬우므로 시험에 필요한 시간을 일정과 업무 배분에서 인정해야 합니다.
시스템 연동과 부서 간 합의가 먼저 필요한지 봅니다
현재 자료를 내려받아 제한적으로 시험할 수 있는 후보와 여러 시스템의 변경이 필요한 후보는 준비 부담이 다릅니다. 연결할 시스템이 많으면 첫 시험 전에 자료 접근 권한이나 기존 업체의 협조부터 확보해야 할 수 있습니다. 부서 간에 처리 기준을 합의해야 하는지도 확인하고, 이런 준비에 필요한 시간을 후보 비교에 포함합니다.
기술적으로 가장 단순한 후보를 무조건 고를 필요는 없습니다. 회사의 핵심 문제와 가까운 후보가 준비 작업을 요구한다면 작은 선행 과제로 나눌 수 있습니다. 예를 들어 경영 현황 요약 전에 지연 사유를 공통 방식으로 남기는 작업을 먼저 진행하고, 기록이 쌓인 뒤 AI 적용을 검토하는 선택입니다.
점수표에는 모르는 조건을 별도로 남깁니다
후보 비교표는 숫자를 정밀하게 만드는 것보다 서로 다른 판단 근거를 드러내는 데 의미가 있습니다. 처음에는 높음·보통·낮음처럼 단순하게 표시해도 됩니다. 각 평가 옆에 근거와 아직 확인하지 못한 조건을 적어야 합니다. 근거 없는 높은 점수는 비교를 오히려 흐릴 수 있습니다.
다음 표는 앞의 가상 기업 서비스 회사가 작성했다고 가정한 예시입니다. 특정 유형의 과제가 언제나 더 낫다는 평가가 아니며 실제 회사의 자료와 조건으로 다시 작성해야 합니다.
후보 | 기대하는 변화 | 이 예시에서 준비됐다고 가정한 항목 | 아직 확인할 조건 |
|---|---|---|---|
문의 분류 | 유형 정리와 전달 준비 감소 | 문의 기록과 분류 담당자 있음 | 배정 대기가 실제로 줄어드는가 |
완료 보고 초안 | 반복 작성 부담 감소 | 현장 기록과 승인본 있음 | 불완전 기록의 수정 부담은 어느 정도인가 |
경영 현황 요약 | 지원할 업무를 빨리 결정 | 미완료 작업 목록 있음 | 지연 사유가 일관되게 남는가 |
이 표만 보고 첫 후보를 결정할 필요는 없습니다. 중요한 미확인 조건 하나를 짧게 조사하면 순위가 달라질 수 있습니다. 예를 들어 문의 분류의 현재 소요 시간이 매우 짧고 대부분의 대기가 배정 이후라면 기대 효과를 다시 봐야 합니다. 반대로 보고 초안의 검토 부담이 감당할 수준이라면 첫 시험으로 검토할 수 있습니다.
부서별 평가가 다를 때는 점수를 평균내기 전에 근거를 비교합니다. 영업은 응답 지연을, 운영은 검토 부담을 크게 볼 수 있습니다. 어느 쪽이 맞는지 바로 결정하기보다 같은 업무 한 건을 함께 따라가며 실제로 시간이 드는 위치를 확인해보세요. 대표는 이견을 없애는 대신 회사가 먼저 바꾸려는 결과를 정해 선택 기준을 분명하게 할 수 있습니다.
숫자 점수를 사용한다면 항목별 가중치도 대표의 판단임을 밝혀야 합니다. 효과를 중시하는지, 빨리 검증하는 것을 중시하는지에 따라 결과가 달라집니다. 근거가 약한 평가에 소수점까지 붙여 객관적인 순위처럼 보이게 만들 필요는 없습니다. 다른 부서가 납득할 수 있는 선택 이유를 남기는 것이 목적입니다.
모르는 항목은 중간 점수로 감추지 마세요. 자료 접근 여부나 업무 책임자의 참여처럼 시작 가능성을 바꾸는 조건은 ‘확인 필요’로 남기고 선택 전에 확인하는 편이 좋습니다.
점수가 높아도 먼저 해결해야 할 조건이 있습니다
일부 조건은 다른 장점으로 상쇄하기 어렵습니다. 결과를 확인할 사람이 없거나, 필요한 자료를 사용할 수 없거나, 오류가 나도 업무를 이어갈 방법이 없다면 먼저 준비해야 합니다. 이것은 해당 과제가 나쁘다는 평가가 아니라 지금 시작할 수 있는지에 관한 판단입니다.
자동 실행이 포함된 후보는 잘못된 결과가 어떤 행동으로 이어지는지 살펴봅니다. 내부 초안을 만드는 일과 고객에게 확정 안내를 보내거나 실제 발주를 실행하는 일은 다르게 검토해야 합니다. 첫 단계에서 사람의 확인을 남기면 시험할 수 있는지, 결과를 추천으로만 제공해도 가치를 확인할 수 있는지 살펴볼 수 있습니다.
예상한 효과가 나오지 않더라도 이번 시험에서 어떤 운영 정보를 확인할 수 있는지 비교할 수 있습니다. 어떤 자료가 부족했는지, 직원은 무슨 기준으로 결과를 검토했는지, 다음 담당자에게 어떤 정보를 전달해야 했는지 기록하면 다음 과제를 준비할 때 참고할 수 있습니다. 그러나 ‘배울 수 있다’는 이유만으로 끝이 없는 실험을 정당화해서는 안 됩니다. 이번 선택에서 무엇을 알게 되면 계속하거나 멈출지 정해두어야 합니다.
첫 과제에 회사 전체의 문제를 모두 담으려는 압력도 조정해야 합니다. 여러 부서가 사용하는 기능이라도 최초 검증 범위는 명확해야 합니다. 대상이 늘어나면 자료와 기준, 예외도 늘어납니다. 첫 결과를 확인하기 전에 범위가 계속 커지지 않도록 추가 요구는 별도 후보로 관리할 수 있습니다.
선택 회의에서는 순위와 보류 이유를 함께 남깁니다
첫 과제를 골랐다면 선택한 이유뿐 아니라 다른 후보를 보류한 이유도 기록합니다. 자료를 준비한 뒤 다시 볼 후보, 현재 효과가 불명확한 후보, 다른 개선으로 해결할 후보를 구분합니다. 탈락 목록처럼 관리하기보다 어떤 조건이 달라지면 다시 검토할지 남기는 방식입니다.
대표의 선택 메모는 한 장으로 시작할 수 있습니다. 해결할 운영 문제, 시험할 업무 범위, 기대 변화, 사용할 자료, 업무 책임자, 확인이 필요한 조건을 적습니다. 여기에 도입 전후 무엇을 비교할지 적으면 이후 구축 논의가 기능 목록으로만 흐르는 것을 줄일 수 있습니다.
선택 이후에도 새로운 사실이 나오면 판단을 조정할 수 있어야 합니다. 자료를 확인했더니 예상보다 정비가 많이 필요하거나 사용자가 이미 다른 방법으로 문제를 해결했다면 후보를 다시 비교합니다. 처음 고른 과제를 끝까지 유지하는 것보다 선택 당시의 가정이 여전히 맞는지 확인하는 편이 경영 판단에 도움이 됩니다.
FlowOS와 첫 AX 과제를 논의할 때는 후보별로 줄이고 싶은 업무, 현재 쓰는 자료, 결과를 확인할 담당자를 정리해보세요. 아직 확인하지 못한 내용은 빈칸으로 남겨도 됩니다. 이 비교 자료가 있으면 바로 시험할 후보와 자료·기준 정비가 먼저 필요한 후보를 구분할 수 있습니다.
회사 안의 여러 AI 도입 아이디어 중 첫 과제를 정하고 싶다면, FlowOS의 도입 방식을 살펴보세요.