AI 잘 활용하려고 만든 업무 도구가 확산되지 않는 이유

시연에서는 작동하는데 팀으로 확산되지 않습니다

AI를 잘 활용하려고 업무 도구를 직접 만드는 현업이 늘고 있습니다. 사내 과정에서 Skill이나 앱을 만들어 보고, 자기 업무를 자동화한 시제품을 경진대회에 가져옵니다. 그런데 시연에서 잘 작동하던 도구가 만든 사람의 자리를 넘어 팀과 부서로 확산되지 못하고 멈추는 경우를 현장에서 자주 봅니다.

최근 한 호텔·컨벤션 기업의 사내 AI 경진대회에서 코칭과 심사를 맡았습니다. 예선을 통과한 10개 팀이 근무표, 구매, 매출 분석, 주방 위생 점검 같은 자기 업무의 시제품을 가져왔습니다. 저는 시제품을 볼 때 시연이 되는지보다 이 도구를 매일 여러 사람이 쓸 수 있는지를 기준으로 봤습니다.

그 기준으로 보니 여러 팀에 같은 말을 반복하게 됐습니다. 심사 뒤 메모에 가장 먼저 적은 관찰도 같은 내용입니다. 대부분의 사람은 AI로 무언가를 만들 때 코드가 해야 할 일과 LLM이 해야 할 일을 구분하지 못합니다. LLM은 ChatGPT나 Claude 같은 대규모 언어 모델을 말합니다.

제가 그날 맡은 역할은 AX 실무 리더가 자기 팀에서 맡는 역할과 같습니다. 실무 리더는 사내 과정에서 도구를 직접 만들어 본 뒤 부서의 AX 도입을 이끄는 사람입니다. 동료가 시제품이나 아이디어를 가져오면 실무에 올릴 수 있는지, 어디를 고쳐야 하는지 말해 줘야 하는데, 그 판단에는 기준이 필요합니다.

이어서 도구가 확산되지 않는 원인을 먼저 설명하고, 코드와 LLM과 사람이 할 일을 나누는 기준과 사례를 차례로 정리하겠습니다.

확산되지 않는 원인은 코드가 할 일까지 LLM이 하는 데 있습니다

코드가 할 일까지 LLM에 맡기면 비싸고, 느리고, 정확도가 낮습니다. 이것이 제 메모의 첫 번째 결론입니다. 현장에서 비용이나 속도를 수치로 측정한 것은 아니어서, 여기서는 원리로 설명합니다.

첫째, LLM은 실행할 때마다 호출 비용이 듭니다. 코드는 한 번 작성하면 몇 번을 실행해도 추가 비용이 거의 들지 않지만, LLM에 맡긴 일은 쓸 때마다 비용이 발생하고 처리 시간도 매번 걸립니다. 쓰는 사람이 늘수록 이 차이가 커집니다.

둘째, LLM은 같은 입력에도 결과가 달라질 수 있습니다. 근무표를 예로 들면, 같은 직원 명단과 같은 휴무 신청으로 두 번 요청했는데 오후 근무 다음 날 오전 배치 제한을 지킨 근무표와 어긴 근무표가 나올 수 있습니다. 규칙을 어기면 안 되는 일에서는 이 점이 곧 정확도 문제가 됩니다.

셋째, 결과가 틀렸을 때 어디가 틀렸는지 짚기 어렵습니다. 코드는 틀린 줄을 찾아 고칠 수 있지만, LLM이 한 판단은 근거를 따라가 확인하기 어렵습니다.

이 세 가지는 시제품을 시연할 때는 드러나지 않습니다. 입력 몇 건으로 한 번 실행하면 결과가 그럴듯하게 나오기 때문입니다. 실제 업무에 올려 매일 여러 사람이 쓰기 시작해야 드러납니다.

세 가지가 겹치면 도구는 쓸 때마다 비용이 들고, 결과를 믿기 어렵고, 고치기도 어렵습니다. 그런 도구는 만든 사람 밖으로 확산되기 어렵습니다. 따라서 확산되는 도구를 만들려면 코드가 할 일, LLM이 할 일, 사람이 할 일을 먼저 나눠야 합니다.

나누는 기준은 질문 두 개입니다

팀 과제를 볼 때 저는 질문 두 개로 시작합니다. 첫 번째는 "이 일은 언제나 같은 결과가 나와야 하는가"입니다. 주방 위생 점검 팀에 대한 피드백 메모에도 이 기준을 적었습니다.

구분은 항상 결과가 똑같이 나오면 코드, 달라지면 AI

두 번째는 "규칙을 말로 정확히 적을 수 있는가"입니다. 한 제조 대기업의 실무 리더 수업에서 참가자 산출물을 두 가지로 나눌 때 쓴 기준입니다. 규칙을 말로 정확히 적을 수 있고 같은 입력에 같은 처리를 하면 HTML 웹 도구로 만들기 좋고, 매번 무엇이 중요한지 판단해야 하면 Claude의 판단이 필요한 Skill이 맞았습니다.

예를 들어 매달 같은 양식으로 정산액을 계산하는 일은 두 질문 모두 "그렇다"로 답이 나오므로 코드가 맡습니다. 회의 녹음에서 후속 조치를 정리하는 일은 어떤 발언이 중요한지 매번 판단해야 하고, 결과가 조금 달라도 쓸 수 있으므로 LLM이 맡습니다. 두 질문은 같은 방향을 가리킵니다. 규칙을 적을 수 있다면 같은 결과가 나오도록 코드로 고정할 수 있고, 적을 수 없다면 판단이 필요한 일이므로 LLM이나 사람이 맡아야 합니다. 이 판단을 세 주체로 정리하면 다음과 같습니다.

세 주체를 나눌 때 한 업무를 통째로 하나의 주체에 배정하지 않는 것이 요점입니다. 근무표 한 건 안에서도 배치와 제약 검사는 코드가, 해석이 필요한 요청 메모의 분류는 LLM이, 최종 근무표 확인은 사람이 맡을 수 있습니다.

사람 행의 마지막 항목이 중요합니다. 코드와 LLM 중 무엇에 맡길지, LLM이 한 판단을 어디까지 믿을지는 모두 사람이 정하기 때문입니다. 이후 절은 이 표를 사례에 적용하는 순서로 이어집니다.

근무표 사례: 규칙과 입력을 나눠 적습니다

근무표 팀은 같은 근무표를 자바스크립트, 파이썬, ChatGPT 프롬프트로 각각 만들어 봤습니다. 자바스크립트 구현은 일정 계산을 끝내지 못하거나 느렸고, 파이썬 결과는 정확도가 낮았으며, 프롬프트만 쓴 결과가 상대적으로 나았다고 팀이 설명했습니다. 앞의 기준대로라면 근무표는 코드가 맡아야 하는 일인데 결과는 반대였습니다.

코칭에서 저는 이 팀에게 고정된 규칙과 매달 바뀌는 입력을 나눠 적으라고 권했습니다. 고정 규칙에는 오후 근무 다음 날 오전 배치 제한, 연속 근무와 휴식 조건, 역할별 배치가 있었습니다. 매달 바뀌는 입력은 직원 명단, 희망 휴무, 특정 날짜의 배치 요청, 행사와 체크인이 몰리는 날이었습니다.

"인풋은 계속 바뀌는 값, 규칙은 고정된 것."

코칭 중에는 규칙을 대분류, 중분류, 소분류로 나눌 수 있는지, 숙련도를 직원 명단의 정렬 순서로 표현할 수 있는지도 함께 논의했습니다. 이런 논의는 코드를 짜는 단계가 아니라 규칙을 적는 단계에서 이루어졌고, 현업 담당자가 답할 수 있는 질문이었습니다.

이렇게 나누면 결과가 틀렸을 때 입력의 오류인지, 규칙의 오류인지, 계산의 오류인지 나눠서 확인할 수 있습니다. 나누지 않으면 근무표 전체를 다시 만들어 보는 수밖에 없습니다. 검수는 실제 근무표를 볼 수 있는 담당자가 반복해서 맡아야 합니다.

flowchart LR
    R["고정 규칙<br/>근무 간격, 연속 근무,<br/>역할별 배치"] --> C["코드<br/>배치와 제약 검사"]
    I["매달 바뀌는 입력<br/>직원 명단, 희망 휴무,<br/>행사일"] --> C
    C --> O["근무표"]
    O --> H["사람<br/>검수"]
    H -.-> N["틀리면 입력, 규칙, 계산 중<br/>어디의 오류인지 나눠 확인"]
    style R fill:#e5e7eb,stroke:#6b7280,color:#1f2937
    style I fill:#e5e7eb,stroke:#6b7280,color:#1f2937
    style C fill:#dbeafe,stroke:#3b82f6,color:#1f2937
    style O fill:#ffffff,stroke:#6b7280,color:#1f2937
    style H fill:#fef3c7,stroke:#f59e0b,color:#1f2937
    style N fill:#ffffff,stroke:#9ca3af,color:#1f2937,stroke-dasharray: 4 3

현장에서 본 바로는 근무표 규칙의 80~90%는 코드로 처리할 수 있어 보였습니다. 다만 이것은 제가 현장에서 본 추정이고, 검증한 비율이 아닙니다. 나머지에 대해서는 해석이 필요한 비정형 요청이 실제로 있는지부터 확인하라고 권했습니다.

그러면 이 팀에서 프롬프트만 쓴 결과가 코드보다 나았던 이유는 무엇일까요. 저는 코드가 근무표에 부적합해서가 아니라, 규칙을 빠짐없이 적고 우선순위를 정하기 전에 코드부터 만들었기 때문이라고 해석합니다. 규칙이 불완전한 채로 만든 코드는 불완전한 규칙을 그대로 실행하고, 프롬프트는 빠진 규칙을 LLM이 문맥으로 채우기 때문에 상대적으로 나아 보일 수 있습니다.

그래서 코칭은 언어 선택에 앞서 현업 담당자가 규칙을 빠짐없이 적고 우선순위를 정하는 일을 첫 단계로 봤습니다. 완벽한 규칙을 한 번에 쓰려고 할 필요는 없습니다. 첫 실행 결과를 보고 빠진 규칙을 보완하는 방식이 현실적입니다.

코드로 먼저 거르고, 남은 것만 LLM에 넘깁니다

대부분의 일은 코드와 LLM을 순서대로 조합해야 합니다. 코칭에서 본 패턴은 두 가지였습니다.

첫 번째는 매출 분석 팀입니다. 이 팀의 핵심은 특이사항이 생겼을 때 원인 파악을 LLM에 맡기는 것이었습니다. 저는 원자료를 통째로 넣지 말고, 먼저 규칙 기반(rule base) 코드로 특이사항이 있는 부분만 걸러서 넣으라고 권했습니다.

처음부터 전체를 보게 하면 속도도 느리고 비용도 많이 듭니다. 전체를 보게 하면 정확도는 더 높을 수 있지만, 그 부분은 코드로 보완해야 한다고 봤습니다.

flowchart TB
    subgraph BEFORE["전체를 LLM에 넣는 방식"]
        direction LR
        A1["원자료 전체"] --> A2["LLM<br/>전체를 보고 원인 파악"]
    end
    subgraph AFTER["코드로 먼저 거르는 방식"]
        direction LR
        B1["원자료 전체"] --> B2["코드<br/>규칙 기반으로<br/>특이사항만 거름"]
        B2 --> B3["LLM<br/>걸러진 부분만<br/>원인 파악"]
        B3 --> B4["사람<br/>확인"]
    end
    BEFORE ~~~ AFTER
    style A1 fill:#e5e7eb,stroke:#6b7280,color:#1f2937
    style A2 fill:#fee2e2,stroke:#ef4444,color:#1f2937
    style B1 fill:#e5e7eb,stroke:#6b7280,color:#1f2937
    style B2 fill:#dbeafe,stroke:#3b82f6,color:#1f2937
    style B3 fill:#dcfce7,stroke:#22c55e,color:#1f2937
    style B4 fill:#fef3c7,stroke:#f59e0b,color:#1f2937

두 번째는 주방 위생 점검 팀입니다. 이 팀에는 AI를 쓰기 전에 체크리스트 앱부터 만들라고 권했습니다. 체크리스트가 전문 영역 지식을 담고 있고, 빠짐없이 겹침없이 점검하게 되어 있는지가 먼저입니다. 그다음 단계가 사진 분석으로 자동 점검하는 것이고, 이때는 사진 분석의 정확도가 관건입니다.

두 사례의 순서는 같습니다. 코드가 먼저 처리할 수 있는 만큼 처리하고, 코드로 규칙을 적을 수 없는 부분만 LLM에 넘깁니다. 코드가 할 일이 늘어날수록 LLM 호출이 줄어서 비용과 속도가 함께 좋아집니다. 주방 위생 점검 팀 피드백도 가능한 한 코드가 할 일을 늘려야 비용과 속도를 최적화할 수 있다는 내용이었습니다.

이미 잘 나눈 팀도 있었습니다. 수요(점유율) 예측 팀은 기존 운영 규칙을 규칙 기반으로 두고 AI가 보완하는 구조였고, 실제 매니저들이 쓰고 있다는 점이 가장 큰 강점이었습니다. 이 팀은 시제품을 쓰는 사람의 반응이 긍정적이라고 말했습니다.

구분은 사람이 정하고, 기록을 보고 바꿉니다

코드와 LLM의 구분은 한 번 정하고 끝나지 않습니다. 사람이 먼저 정하고, 사람이 남긴 기록을 보고 바꿉니다.

수요 예측 팀의 담당자는 시스템의 권고를 따랐는지와 그 이유를 로그와 메모로 남기고 있었습니다. 그룹 예약이나 계약처럼 예측과 실제 행동이 달라지는 사건은 자유 서술 메모에 적힙니다. 저는 이 메모의 반복 유형을 찾아 분류하고 데이터베이스에 쌓으라고 권했습니다.

분류는 LLM이 초안을 만들고 사람이 확인하는 순서가 맞습니다. 자유 서술 메모의 분류는 조금 다른 결과가 나와도 되는 일이므로 LLM의 몫이고, 그 분류를 승인하는 것은 사람의 몫입니다. 이렇게 쌓은 예외 데이터로 예측 성능을 검증한 뒤에, 담당자의 실행 판단을 조금씩 위임하자고 권했습니다. 자동으로 요금을 바꾸기로 한 것은 아닙니다.

flowchart LR
    S1["사람<br/>권고를 따랐는지와<br/>이유를 기록"] --> S2["LLM<br/>메모 유형<br/>분류 초안"]
    S2 --> S3["사람<br/>분류 확인"]
    S3 --> S4["예외 데이터로<br/>예측 성능 검증"]
    S4 --> S5["실행 판단을<br/>조금씩 위임"]
    style S1 fill:#fef3c7,stroke:#f59e0b,color:#1f2937
    style S2 fill:#dcfce7,stroke:#22c55e,color:#1f2937
    style S3 fill:#fef3c7,stroke:#f59e0b,color:#1f2937
    style S4 fill:#dbeafe,stroke:#3b82f6,color:#1f2937
    style S5 fill:#e0e7ff,stroke:#6366f1,color:#1f2937

여기에는 트레이드오프가 있습니다. 사람이 많이 하면 안전하지만 느리고, AI에 많이 맡기면 빠르지만 위험합니다. 그래서 기록으로 검증한 범위만큼만 AI에 더 맡기는 방식이 안전합니다. 검증하지 않은 범위를 한꺼번에 넘기면 위험이 먼저 커집니다.

"저는 코드를 못 짜는데요"

이 구분을 팀에 적용하려 하면 팀원이 실무 리더에게 이렇게 되물을 수 있습니다. 코드로 처리하라는데, 저는 코드를 못 짜는데요?

코드도 AI가 작성합니다. 구분은 누가 코드를 쓰느냐가 아닙니다. 실행할 때마다 LLM이 판단하느냐, 정해진 코드가 실행되느냐입니다. AI가 작성한 코드라도 한 번 만들어 두면 이후에는 같은 입력에 같은 결과를 냅니다.

AI가 작성한 코드도 틀릴 수 있으므로 결과를 확인하는 일은 남습니다. 확인의 기준은 사람이 적은 규칙입니다. 따라서 사람이 할 일은 규칙을 적는 것입니다. 코드를 짜는 능력이 아니라, 무엇이 규칙이고 무엇이 입력인지 나누고 우선순위를 정하는 능력입니다. 근무표 팀이 첫 단계로 받은 권고도 이 일이었습니다.

실무 리더가 할 일과 엔지니어가 필요한 지점

실무 리더가 맡는 일은 규칙 정리, 우선순위 결정, 결과 검수입니다. 이 셋은 업무를 가장 잘 아는 현업이 해야 하고, 엔지니어가 대신할 수 없습니다.

다음 단계인 코드와 LLM의 조합 설계는 다릅니다. 대부분의 일은 둘이 섞여 있어서 어디서 나눌지 정하기 어렵습니다. 이 단계에서는 엔지니어가 코멘트해 주면 도움이 됩니다. AI에게 물어보면 답은 나오지만, 답을 들어도 이해하지 못해 맞는지 판단하기 어렵습니다.

바이브 코딩으로 결과물의 품질을 높이려면 결국 소프트웨어 엔지니어링 능력이 필요합니다. 여기서 말하는 능력은 세 가지입니다. 복잡한 현실에서 패턴을 찾아 추상화해 데이터로 만드는 능력, 큰 문제를 적절한 단위로 나누고 순서를 정해 하나씩 해결하는 능력, 코딩으로 어디까지 가능한지에 대한 경험치입니다.

구분은 이렇게 합니다. 규칙 정리, 우선순위, 검수는 현업 리더가 하고, 코드와 LLM의 조합 설계는 엔지니어의 코멘트를 받습니다. 동료에게 줄 피드백도 이 틀로 정리할 수 있습니다. 규칙이 빠짐없이 적혀 있는지, 코드가 할 일을 LLM에 맡기고 있지 않은지, LLM이 한 판단을 사람이 어디서 확인하는지를 순서대로 묻습니다.

앞의 두 질문에서 답이 막히는 지점은 대개 현업 리더가 고칠 수 있습니다. 세 번째 질문에서 막히거나 둘이 섞인 지점의 나누기가 불분명하면, 그때가 엔지니어의 코멘트가 필요한 지점입니다. 엔지니어가 AX에서 어떤 역할을 하는지는 엔지니어 출신이 하는 AX는 무엇이 다른가에서 다뤘습니다.

마치며

AI를 잘 활용하려고 만든 업무 도구가 확산되지 않는 원인은 코드가 할 일까지 LLM에 맡기는 데 있습니다. 코드가 할 일, LLM이 할 일, 사람이 할 일을 나누는 기준은 두 질문으로 정리됩니다. 언제나 같은 결과가 나와야 하는지, 규칙을 말로 정확히 적을 수 있는지입니다. 팀 과제를 볼 때는 먼저 규칙을 적게 하고, 코드와 LLM과 사람으로 나눈 뒤, 첫 실행 결과를 보고 보완하는 순서가 가장 현실적이라고 생각합니다. 조합이 어려운 지점에서는 엔지니어의 코멘트를 받는 것이 가장 빠릅니다. 코드를 직접 짜지 못해도 규칙을 적고 검수하는 일은 현업 리더가 할 수 있으며, 그 규칙이 쌓일수록 코드가 맡는 범위가 넓어지고 LLM에 드는 비용과 시간이 줄어듭니다.