회의록을 정리하고, 영수증을 읽고, 고객 문의를 분류하는 일은 대개 누군가의 개인 노하우와 반복 작업에 기대어 돌아갑니다. 이런 업무는 거대한 전사 AI 플랫폼을 기다리기보다 팀 내부에서 쓰는 로컬앱이나 자동화 도구로 먼저 줄일 수 있습니다.
다만 로컬앱의 빠른 제작 속도는 운영 준비가 부족하다는 뜻이 되기도 합니다. 처음에는 한 사람이 자신의 불편을 해결하려고 만든 도구였는데, 어느새 여러 팀이 매일 쓰고 승인·정산·고객 응대까지 연결됩니다. 그 시점부터는 개인 생산성 도구가 아니라 업무 시스템입니다. 그런데도 책임자, 데이터 보관 방식, 오류 처리 절차가 없으면 자동화가 줄였던 시간을 장애 대응과 수기 보정에 다시 쓰게 됩니다.
로컬앱의 출발점은 “AI로 무엇을 만들 수 있는가”가 아니라 “누가 같은 판단을 반복하고 있는가”여야 합니다. 범위가 좁고 사용자 집단이 분명하며, 입력과 결과를 사람이 비교할 수 있는 업무부터 시작하는 편이 실패 확률을 낮춥니다.
로컬앱에 맞는 업무와 맡기면 안 되는 업무
로컬앱은 특정 팀이 반복하는 작업을 빠르게 정리하는 데 강합니다. 특히 다음 조건이 겹치면 후보가 될 수 있습니다.
- 같은 형식의 문서, 이미지, 메일, 표를 반복해서 읽고 옮긴다.
- 작업 결과가 초안, 분류, 요약, 계산 보조처럼 사람이 검토 가능한 형태다.
- 사용자 수와 업무 범위가 제한돼 있어 예외를 가까이에서 발견할 수 있다.
- 기존 SaaS를 도입하기에는 업무 방식이 너무 특수하거나, 필요한 기능이 지나치게 작다.
- 업무 결과가 다른 시스템의 원장이 아니라 참고 정보나 준비 자료로 쓰인다.
예를 들어 회의록에서 결정 사항과 담당자를 뽑아 정리하거나, 정해진 양식의 증빙 자료에서 항목을 추출해 정산 초안을 만드는 일은 로컬앱으로 시험해 볼 만합니다. 결과를 사람이 검토하고 기존 절차로 되돌릴 수 있기 때문입니다.
반대로 다음 업무는 로컬앱만으로 처리하기보다 기존 SaaS, 정식 시스템 개발, 또는 현행 업무 절차를 우선 검토하는 편이 안전합니다.
| 업무 특성 | 우선 검토할 선택지 | 이유 |
|---|---|---|
| 급여, 회계 전표, 세금, 계약 상태처럼 기록 자체가 기준이 되는 업무 | 정식 시스템 또는 검증된 SaaS | 데이터 정합성, 변경 이력, 권한 관리가 핵심이기 때문 |
| 여러 부서와 외부 고객이 같은 상태를 봐야 하는 업무 | 정식 시스템 개발 또는 통합 SaaS | 상태 정의와 연동 규칙을 장기간 유지해야 하기 때문 |
| 예외 처리와 승인 단계가 많은 업무 | 먼저 업무 절차 정비 | 자동화 전에 예외와 책임 경계를 합의해야 하기 때문 |
| 개인정보, 민감정보, 영업기밀을 대량으로 다루는 업무 | 보안 검토 후 제한적 도입 | 입력 데이터, 모델 전송, 보관 위치를 통제해야 하기 때문 |
| 법적 효력이 있는 의사결정이나 대외 통지 | 사람의 최종 승인 체계가 있는 시스템 | 잘못된 결과가 곧바로 분쟁이나 손실로 이어질 수 있기 때문 |
여기서 SaaS가 더 낫다는 말은 기능이 더 많다는 뜻이 아닙니다. 여러 사람이 같은 데이터를 보고, 권한을 나누고, 변경 이력을 남기고, 담당자가 바뀌어도 계속 운영해야 한다면 이미 도구가 감당해야 할 운영 범위를 넘어섰을 수 있다는 뜻입니다.
실패는 대개 모델 오류보다 업무 경계가 흐릴 때 시작된다
로컬앱이 실패하는 첫 번째 경로는 입력 범위가 조금씩 넓어지는 경우입니다. 처음에는 특정 팀의 회의록만 처리하던 도구가 타 부서 문서, 고객 자료, 외부 협력사 파일까지 받기 시작합니다. 파일 형식과 용어가 달라지면서 분류 정확도는 흔들리고, 누가 어떤 자료를 올려도 되는지 알 수 없게 됩니다.
조기 신호는 사용자의 질문에서 드러납니다. “이 파일도 넣어도 되나요?”, “이 결과를 그대로 제출해도 되나요?”, “누가 수정했는지 알 수 있나요?”라는 질문이 반복되면 기능을 더하는 대신 사용 범위를 다시 정해야 합니다.
두 번째 경로는 자동화 결과가 사실상 최종 결정으로 쓰이는 경우입니다. AI가 추출한 영수증 항목, 문의 원인, 담당자 추천은 유용한 출발점이 될 수 있습니다. 그러나 잘못 읽은 금액, 잘못 배정된 담당자, 누락된 예외가 그대로 처리되면 문제의 원인을 사용자가 아니라 도구 탓으로만 돌리기 어렵습니다. 업무 책임이 이미 자동화 흐름 안으로 들어왔기 때문입니다.
이때는 결과 화면에 신뢰도 점수만 붙이는 것으로 충분하지 않습니다. 어떤 결과를 사람이 확인해야 하는지, 확인하지 못한 결과는 어디에 쌓이는지, 수정한 사람의 판단을 다음 처리에 어떻게 반영할지 정해야 합니다. “자동 승인”과 “승인용 초안 생성”은 요구사항부터 다릅니다.
세 번째 경로는 제작자가 유일한 운영자가 되는 상황입니다. 제작자가 휴가를 가거나 부서를 옮긴 뒤에도 도구가 계속 쓰이면, API 키 갱신, 오류 로그 확인, 프롬프트 수정, 데이터 복구를 누가 맡는지가 문제가 됩니다. 화면은 열리지만 결과가 며칠 전 데이터이거나 외부 연동이 끊긴 상태를 늦게 발견할 수도 있습니다.
운영 책임을 기능 요구사항으로 바꿔야 한다
로컬앱을 배포하기 전에는 기능 목록과 별도로 운영 질문을 문서에 남겨야 합니다. 이 문서는 길 필요가 없지만, 답이 비어 있으면 출시 범위를 줄이는 편이 낫습니다.
먼저 업무 소유자를 정합니다. 개발자가 아니라 결과를 사용하는 업무 부서가 “이 결과를 어떤 기준으로 받아들이고, 오류가 나면 무엇을 중단할지” 결정해야 합니다. 개발 또는 IT 운영 담당자는 계정, 배포, 연동, 장애 대응을 맡되 업무 판단의 책임까지 떠안지 않는 편이 역할을 분명히 합니다.
다음으로 데이터 흐름을 그립니다. 사용자가 무엇을 입력하는지, 앱이 어디에 저장하는지, 외부 AI 모델이나 OCR 서비스로 무엇이 전달되는지, 결과가 어느 시스템에 남는지를 한 장으로 확인합니다. 이 단계에서 입력 금지 데이터, 보관 기간, 접근 권한, 삭제 요청 처리 방식을 정할 수 있습니다. 보안이나 개인정보 관련 판단이 필요한 조직이라면 해당 책임자 검토를 이 단계에 붙여야 합니다.
마지막으로 실패했을 때의 업무 흐름을 만듭니다. 자동화가 멈춰도 담당자가 수기로 처리할 수 있는지, 잘못 처리된 결과를 되돌릴 수 있는지, 오류를 누구에게 전달하는지를 정합니다. “앱이 안 되면 개발자에게 연락한다”는 운영 절차가 아닙니다. 연락할 계정, 확인할 로그, 중단 기준, 대체 절차까지 정해져야 합니다.
작은 시험은 기능 검증이 아니라 운영 검증이어야 한다
초기 시험에서 가장 먼저 볼 지표를 처리 시간 단축으로만 잡으면 위험합니다. 시간 절감은 필요하지만, 자동화가 예외를 어디로 밀어냈는지는 보여주지 못합니다.
시험 기간에는 다음 질문을 함께 확인하는 편이 좋습니다.
- 사용자는 결과를 수정할 수 있는가. 수정 이유를 남길 수 있는가.
- 입력이 누락되거나 형식이 달라졌을 때 도구는 멈추는가, 그럴듯한 오답을 내는가.
- 결과가 기존 업무 기록과 다를 때 어느 기록을 기준으로 삼는가.
- 담당자가 아닌 사람이 접근하거나 잘못된 자료를 올렸을 때 차단할 수 있는가.
- 제작자가 없어도 다른 사람이 계정, 데이터, 오류 상태를 확인할 수 있는가.
이 질문에 답하지 못한 상태라면 사용자를 늘리기보다 범위를 좁혀야 합니다. 반대로 답이 명확하고, 예외가 처리되는 경로가 확인되며, 업무 담당자가 결과를 신뢰할 조건을 설명할 수 있다면 다음 팀으로 확장할 근거가 생깁니다.
전사 플랫폼 이전에 남겨야 할 기록
로컬앱은 종종 임시방편으로 취급되지만, 잘 운영하면 정식 시스템의 요구사항을 발견하는 실험장이 됩니다. 다만 그 가치는 앱의 화면이나 코드 자체보다 운영 중 남긴 기록에서 나옵니다.
어떤 입력이 자주 예외가 됐는지, 사용자가 어떤 결과를 반복 수정했는지, 어느 단계에서 승인자가 필요했는지, 어떤 부서가 같은 기능을 요청했는지를 남기면 이후 SaaS를 도입하거나 정식 개발을 할 때 요구사항이 선명해집니다. 반대로 이 기록 없이 사용자가 늘어나면, 개인 도구의 불편을 전사 시스템에 그대로 옮길 가능성이 큽니다.
처음 후보 업무를 고를 때는 팀원이 가장 오래 하는 일을 찾기보다, 결과를 되돌릴 수 있고 오류를 빨리 알아차릴 수 있는 일을 찾으십시오. 그 업무에 대해 사용자 한 명, 업무 책임자 한 명, 운영 담당자 한 명을 먼저 지정해 짧은 범위로 돌려보는 편이 대형 플랫폼 도입 논의보다 더 많은 답을 줄 수 있습니다.
