모델은 전체에서 작은 부분일 뿐입니다. 데이터를 쓸 수 있는지, 인터페이스가 명확한지, 업무 흐름이 제대로 이어지는지, AI가 틀렸을 때 누가 처리할지 같은 문제가 한꺼번에 나타납니다.
gptpmt 튜토리얼을 마친 뒤 여러 일에 쫓기다 보니, 차분히 앉아 체계적인 글 한 편을 쓴 지 오래됐습니다.
2022년에 ChatGPT를 접하고, 2023년에 gptpmt를 쓰기 시작했으며, 이후에는 기업 AI 실무에도 참여했습니다. 3년이 넘는 동안 여러 시도를 했고 기업이 AI를 도입할 때 마주치는 많은 문제를 보았습니다.
최근 주변에서 이런 질문을 자주 받습니다. 이미 많은 업무 시스템을 가진 기업은 AI를 어떻게 연결해야 할까요?
겉으로는 기술 문제처럼 보입니다. 어떤 모델과 프레임워크를 고를지, API를 어떻게 호출할지 묻는 문제입니다.
하지만 실제로 시작해 보면 모델은 오히려 작은 부분에 불과합니다. 내부 데이터를 사용할 수 있는가, 기존 인터페이스가 명확한가, 여러 업무 프로세스를 어떻게 연결할 것인가, AI가 잘못했을 때 누가 처리할 것인가가 동시에 문제로 떠오릅니다.
가장 흔한 고객 지원 사례부터 보겠습니다. 사용자가 상담 창을 열고 묻습니다.
“제 주문은 왜 아직 배송이 시작되지 않았나요?”
AI는 배송이 늦어질 수 있는 일반적인 이유를 길게 설명한 뒤 주문 번호를 요청합니다. 사용자가 번호를 줘도 조회하지 못하고 결국 상담원에게 넘깁니다.
기업은 AI 고객 지원을 만드는 데 많은 시간을 썼지만 상담원의 업무량은 줄지 않았습니다. 오히려 AI를 대신 설명하는 일이 추가됐습니다.
왜 그럴까요?
문제는 모델이 아닐 수 있습니다. 질문에 답하기만 하는 시스템을 조회, 판단, 실행, 위험 부담이 필요한 작업에 곧바로 투입한 것이 문제입니다.
기초 공사를 하기 전에 꼭대기 층 인테리어를 논의하는 건물과 같습니다. 단순히 공사가 늦어지는 것이 아니라, 중간에 아래 구조가 지탱하지 못한다는 사실을 알게 됩니다.
기업 레거시 시스템에 AI를 도입할 때도 역량을 한 층씩 갖춰야 합니다. 크게 Chatbot(대화로 질문에 답하는 시스템), AI + Tools(AI가 명확한 업무 기능을 호출하는 구성), Copilot(목표를 향해 여러 단계를 연결하되 불확실한 지점은 사람에게 넘기는 보조 시스템), Agent(합의된 경계 안에서 자율적으로 실행하는 시스템)라는 네 단계로 나눌 수 있습니다.
이는 업계 표준이 아니라 역량을 점검하는 프레임워크입니다. 기업이 모든 중간 버전을 정식 출시할 필요는 없지만 데이터, 도구, 작업, 거버넌스라는 기반 역량은 건너뛸 수 없습니다.
네 단계, 네 겹의 역량.
1단계: Chatbot—먼저 질문에 정확히 답하기
질문을 단순하게 바꿔 봅시다.
사용자가 자신의 주문 대신 “보통 결제 후 언제 배송하나요?”라고 묻습니다.
이때 AI는 업무 시스템에 들어갈 필요가 없습니다. 기업이 배송 규정, 환불 정책, 제품 정보, 자주 묻는 질문을 정리했다면 답할 수 있습니다.
이 단계의 Chatbot은 기업 지식을 바탕으로 일반적인 질문에 답합니다.
영업시간, 제품 소개, 경비 규정, 사후 지원 규칙 같은 답은 대개 이미 사내 문서에 있습니다. 전에는 직원이 직접 검색했지만 이제는 자연어로 질문하고, AI가 관련 내용을 찾아 답으로 정리할 수 있습니다.
문서를 넣기만 하면 되는 것처럼 보입니다.
하지만 특정 주문에 관한 질문이 나오면 Chatbot은 알지 못합니다. 사용자가 누구인지, 어떤 주문을 했는지, 주문의 현재 상태가 무엇인지 모릅니다. 계속 답하면 일반 규칙에 기대 추측할 뿐입니다.
따라서 1단계의 경계는 분명합니다. 기업 지식에 이미 있는 질문에는 답할 수 있지만 현재 진행 중인 업무 사실을 아는 척해서는 안 됩니다.
0단계에서 1단계로: 핵심은 모델이 아니라 데이터 거버넌스
많은 기업은 수백만 자에 이르는 Lark 문서, 제품 설명서, 상담 기록을 한꺼번에 AI에 주면 문서가 많을수록 답도 좋아질 것이라 생각합니다.
그러나 문서가 많다고 지식을 쓸 수 있는 것은 아닙니다.
주방에 똑같이 생긴 양념통 수십 개가 라벨도, 정해진 자리도 없이 놓여 있다고 상상해 보세요. 소금, 설탕, 식초, 후추가 있다는 사실은 알지만 필요할 때마다 하나씩 열어 냄새를 맡아야 합니다.
기업 문서도 흔히 이렇습니다.
같은 환불 규정이 세 버전으로 남아 있고, 단종된 제품의 예전 안내 문구가 살아 있습니다. 같은 단어가 부서마다 다른 뜻이고, 한 업무 명칭이 몇 년 사이 여러 번 바뀌기도 합니다.
사람이 찾기 어려우면 AI도 잘못 찾습니다.
더 큰 문제는 AI의 답이 유창하다는 점입니다. 예전 정책과 새 정책을 섞어도 일반 사용자는 알아차리지 못할 수 있습니다. 틀린 답이 맞는 답처럼 보일수록 위험은 더 큽니다.
첫 번째로 보완할 역량은 데이터 거버넌스입니다. 최소한 다음을 명확히 해야 합니다.
- 어떤 내용이 정확하고 무엇이 만료됐는가.
- 문서를 어떻게 분류하며 각 질문은 어디에서 검색할 것인가.
- 같은 개념이 시스템마다 무엇이라 불리며 통합 용어집이 필요한가.
- 신원과 역할에 따라 어떤 내용을 볼 수 있고 민감한 정보는 어떻게 분리하는가.
- 누가 업데이트하고 오래된 버전은 언제 내리는가.
- 무엇을 올바른 답으로 보며 오류를 계속 어떻게 발견할 것인가.
AI가 분류, 중복 제거, 정리를 도울 수는 있지만 분류 체계, 유지 책임, 검수 기준은 기업이 정해야 합니다.
데이터 거버넌스는 한 번의 대청소로 끝나지 않습니다. 업무 규칙, 제품, 조직은 바뀌고 지금 맞는 내용도 반년 뒤에는 틀릴 수 있습니다. 지식 베이스에는 지속적인 유지 경로가 필요합니다.
여기까지 오면 고객 지원은 단순히 ‘대규모 모델을 연결한’ 것이 아니라 유효한 기업 지식에 근거해 답할 수 있습니다. 근거를 찾지 못하면 그럴듯한 답을 꾸며 내지 말고 모른다고 해야 합니다.
1단계의 완료 여부는 준비한 질문 몇 개에 답하는 시연으로 판단하지 않습니다. 실제 사용자가 표현을 바꾸고, 연달아 질문하고, 권한 경계를 물어도 올바른 근거를 찾는지 확인해야 합니다. 이 단계가 안정된 뒤에야 업무 시스템 안쪽으로 들어갈 이유가 생깁니다.
2단계: AI + Tools—AI가 이 주문을 조회하게 하기
2단계에서는 질문이 특정 주문과 연결됩니다.
첫 질문에 답하려면 AI가 주문 조회 도구를 호출해 사용자의 주문과 배송 상태를 가져와야 합니다. 주문이 아직 창고에 있다는 사실을 확인한 뒤에야 실제 이유를 말할 수 있습니다.
사용자가 이어서 환불을 요구하면 환불 도구도 호출해야 합니다.
AI는 이제 기업 지식을 읽는 데 그치지 않고 업무 시스템을 사용해 구체적인 일을 합니다. 이것이 AI + Tools입니다.
Tools는 기업이 AI에 제공하는 역량의 입구입니다. 주문 조회, 배송 정보 조회, 환불 금액 계산, 실제 환불 제출은 각각 다른 도구입니다.
AI는 사용자 말을 이해하고 알맞은 도구를 고른 뒤, 반환된 데이터를 사용자가 이해할 수 있는 결과로 정리합니다.
간단해 보이지만 문제가 따라옵니다.
레거시 시스템에는 환불 API가 열 개 넘게 공존할 수 있습니다. 구버전, 쿠폰만 돌려주는 것, 내부 필드가 필요한 것, 실패 이유를 명확히 반환하지 않는 것이 섞여 있습니다.
이 모두를 AI에 넘겨 스스로 고르게 해도 레거시 시스템이 똑똑해지지 않습니다. 감춰졌던 복잡성만 드러납니다.
전에는 시스템을 잘 아는 개발자가 호출했습니다. 어떤 것이 작동하고, 어떤 것이 오래된 흔적이며, ‘선택’이라고 적힌 어떤 인수가 사실상 필수인지 알고 있었습니다. AI에는 이런 암묵지가 없고 제공된 설명만 보고 판단합니다.
도구 이름이 모호하고 인수 정의가 불완전하며 반환 형식이 제각각이면 강한 모델도 잘못 고를 수 있습니다.
1단계에서 2단계로: 핵심은 도구 거버넌스
도구 거버넌스는 기존 API를 단순히 포장하는 일이 아닙니다. 기본 질문을 다시 답하는 일입니다.
- 이 도구는 정확히 어떤 문제를 해결하고 언제 사용하면 안 되는가.
- 필수 인수는 무엇이고 어디서 얻는가.
- 성공, 실패, 부분 성공은 각각 어떤 구조로 반환되는가.
- 어떤 역할이 호출할 수 있고 어떤 데이터를 읽거나 바꿀 수 있는가.
- 조회 작업은 몇 번까지 가능하며 수정 작업은 확인이 필요한가.
- 같은 요청이 반복될 때 이중 환불이나 이중 주문을 어떻게 막는가.
- 호출 주체, 입력, 결과를 모두 추적할 수 있는가.
쉽게 놓치는 특성이 멱등성입니다.
환불 도구가 네트워크 시간 초과를 일으키면 AI는 성공 여부를 알 수 없어 다시 호출할 수 있습니다. 중복 방지 장치가 없다면 같은 주문이 두 번 환불될 수 있습니다.
이는 모델의 지능 문제가 아니라 도구가 자동 호출에 준비됐는지의 문제입니다.
시스템을 관리하는 사람이 도구 사용법을 명확히 설명할 수 있게 한 뒤 AI에 제공해야 합니다. 도구 수가 적고 책임이 명확할수록 AI가 정확히 쓰기 쉽습니다. 여러 역사적 API는 소수의 안정된 업무 기능으로 수렴시키는 편이 좋습니다.
여기서 지시 하나를 실행하는 것과 작업 하나를 완수하는 것을 구분해야 합니다.
주문 조회, 배송 정보 읽기, 환불 시작은 각각 명확한 지시입니다. 사용자가 한 단계 말하고 AI가 한 도구를 호출한 뒤 멈추면 AI + Tools입니다.
최종 목표만 알려 주고 먼저 무엇을 할지, 다음에는 무엇을 할지, 중간 문제를 어떻게 처리할지까지 스스로 판단하게 하면 다음 단계로 넘어갑니다.
3단계: Copilot—작업을 계속 앞으로 진행하기
조건을 하나 더 붙입니다. “이 주문을 확인하고, 아직 배송 전이면 바로 환불해 주세요.”
도구 하나를 호출하고 끝나지 않습니다. 시스템은 사용자와 주문을 확인하고, 배송을 조회하고, 환불 조건을 판단하고, 금액을 계산하고, 환불을 신청한 뒤 결과를 알려야 합니다.
AI + Tools가 사람이 한 단계 말하면 AI가 한 단계 움직이는 방식이라면, Copilot은 사람이 목표를 주고 AI가 여러 단계를 연결하는 방식입니다. 불확실하거나 위험이 큰 지점에서는 멈추고 사람에게 넘깁니다.
AI는 현재 목표 이해, 다음 단계 판단, 도구 호출, 결과 읽기, 새 결과에 따른 후속 행동 결정을 반복합니다.
이미 배송된 주문은 미배송 환불로 가면 안 됩니다. 환불 금액이 이상하면 멈춰야 하고, 사용자 신원이 확인되지 않으면 주문을 바꿀 수 없습니다. 각 단계의 결과가 다음 행동을 바꿉니다.
이것이 닫힌 작업 루프입니다.
2단계와 3단계의 차이는 여러 도구를 한 번에 호출할 수 있는지, 읽기에서 쓰기로 바뀌는지가 아닙니다. 목표를 향해 작업이 완료되거나 실패하거나 사람이 맡아야 할 때까지 계속 실행할 수 있는지가 핵심입니다.
도구를 연결하면 새로운 문제가 생깁니다.
첫 번째 문제: 의도 거버넌스
어려운 문제는 특정 도구를 못 쓰는 것이 아니라 처음부터 잘못된 흐름에 들어가는 경우가 많습니다.
사용자가 배송 상태가 사흘 동안 갱신되지 않았다며 민원과 환불을 동시에 요구했다고 합시다.
이 요청에는 배송 이상, 민원, 환불이 함께 있습니다. 민원만 인식하면 사용자를 달래기만 하고 환불은 처리하지 않을 수 있습니다. 곧장 환불하면 주문 상태와 환불 조건을 빠뜨릴 수 있습니다.
먼저 업무 영역을 판단한 뒤 모호한 표현을 실행 가능한 구체적 의도로 나누고 순서를 정해야 합니다.
왜 수백 개 선택지를 가진 거대한 의도 분류기 하나를 만들지 않을까요?
실제 기업 업무는 시연보다 훨씬 복잡합니다. “이것 좀 바꿔 주세요”가 주문 시스템에서는 주소 변경, 출장 시스템에서는 예약 변경, 인사 시스템에서는 직원 정보 수정을 뜻할 수 있습니다. 업무가 늘어날수록 모든 의도를 한 층에 놓은 분류는 혼란스러워집니다.
더 적합한 방법은 계층형 라우팅입니다.
첫 단계에서 주문, 배송, 사후 지원, 계정을 구분합니다. 주문으로 들어간 뒤 조회, 변경, 취소, 환불을 나눕니다. 한 문장에 여러 의도가 있으면 분리하고 의존성에 맞춰 순서를 정합니다.
호출 차량 사례를 보면 더 분명합니다. “내일 아침 공항으로 데려다 줘”에는 출발지, 항공편 시간, 도착 여유 시간이 필요합니다. “동행자 차도 한 대 불러 줘”가 더해지면 두 번째 승객, 두 번째 출발지, 다른 차종까지 생길 수 있습니다. 모든 정보를 단순한 ‘차량 호출’ 의도에 넣으면 이후 흐름이 섞이기 쉽습니다.
의도 거버넌스는 문장에 라벨 하나를 붙이는 일이 아닙니다. 사용자가 실제로 이루려는 일을 시스템이 실행 가능한 작업으로 단계적으로 좁히는 일입니다.
한 문장에서 실행 가능한 작업으로.
두 번째 문제: 상태 관리
변화를 하나 더 추가해 봅시다.
시스템이 주문 조회를 마치고 환불하려는 순간, 사용자가 마음을 바꿔 “환불은 잠시 멈추고 배송 주소를 바꿔 주세요”라고 말합니다.
그대로 환불을 밀어붙여도, 앞선 결과를 모두 버려도 안 됩니다. 현재 흐름을 중단하고 이미 가져온 주문과 배송 정보를 유지한 채 주소 변경이 가능한지 판단해야 합니다.
상태 관리가 필요한 이유입니다. 시스템은 앞선 대화뿐 아니라 작업이 어디까지 진행됐는지, 어떤 도구를 호출했는지, 어떤 동작을 되돌릴 수 있는지 알아야 합니다. 환불이 이미 제출됐다면 아무 일도 없었던 것처럼 굴지 말고 취소 또는 보상 흐름에 들어가야 합니다.
맥락은 적어도 두 종류입니다. 대화 맥락은 ‘이 주문’이 무엇이고 무엇을 확인했는지 알려 줍니다. 작업 맥락은 환불 절차의 현재 단계, 성공한 도구, 확인 대기 동작을 기록합니다.
대화 기록만 저장해서는 부족합니다. 대화에 ‘환불 준비 중’이라고 써 있어도 실제 명령을 제출했는지 별도로 알아야 합니다. 도구 상태만 저장해도 부족합니다. 사용자의 “아무래도 그만할게요” 한마디가 목표를 바꾸기 때문입니다.
Copilot은 다음 변화를 다뤄야 합니다.
- 작업이 중단돼도 완료한 결과를 계속 사용할 수 있다.
- 사용자가 정보를 보충하면 올바른 지점에서 재개한다.
- 여러 의도 사이에 의존성이 있으면 순서대로 실행한다.
- 부수 효과가 생긴 작업이 실패하면 롤백하거나 보상 절차로 간다.
- 능력 밖이거나 정보가 부족하거나 위험이 크면 전체 맥락과 함께 사람에게 넘긴다.
의도 거버넌스는 맞는 길을 골랐는지 결정하고, 상태 관리는 상황이 바뀐 뒤 길을 잃지 않는지 결정합니다.
여기까지 되어야 AI가 도구 몇 개를 감싼 대화 상자를 넘어 실제 업무 프로세스에 참여하기 시작합니다.
4단계: Agent—경계 안의 결과는 누가 책임지는가
Copilot 단계의 AI는 목표를 이해하고 단계를 배치하고 계속 도구를 호출합니다. Agent와의 차이는 무엇일까요?
책임입니다.
AI 상담 시스템이 환불할 수 있다고 합시다. 원래 50위안만 환불해야 하는 주문에서 사용자가 시스템을 유도해 5,000위안을 환불받았다면 누가 그 결과를 감당할까요?
업무 담당자가 모든 건을 계속 확인하고 문제가 나면 ‘검토자가 놓쳤다’고 한다면 여전히 Copilot입니다. AI가 실행하고 사람이 옆에서 브레이크를 밟습니다.
Agent는 다른 약속을 뜻합니다. 양측이 합의한 운영 경계 안에서는 업무 담당자가 매 건을 검토하지 않아도 됩니다. 시스템의 자율 판단이 잘못되면 Agent를 제공한 팀이 합의된 범위 안의 결과를 책임집니다.
Agent가 무한정 책임진다는 뜻은 아닙니다.
주행 자동화의 L2와 L3는 이 변화를 이해하는 데 도움이 됩니다. L2는 운전자의 지속적인 감독을 요구합니다. L3는 제한된 조건에서 시스템이 더 많은 주행 작업을 맡되 인수 요구도 남겨 둡니다. 이 비유는 작업과 감독 책임의 변화를 설명할 뿐 특정 사고의 법적 책임을 결정하지 않습니다.
실제 책임은 현지 법률, 제품 약속, 운영 조건, 구체적 사실에 따라 달라집니다. Agent도 경계를 미리 명시하고, 경계를 벗어나면 거부하거나 안전하게 축소하거나 사람에게 넘겨야 합니다.
예를 들어 환불 Agent는 금액이 200위안 이하이고 주문 상태가 명확하며 사용자 신원이 확인된 일반 사후 지원만 처리할 수 있습니다. 금액을 넘거나 이상 계정이 감지되거나 규칙이 충돌하면 바로 사람에게 넘깁니다.
범위 안에서는 스스로 끝내되, 범위 밖에서 완료율을 높이려고 추측을 계속해서는 안 됩니다.
Copilot에서 Agent로: 핵심은 체계적 감독
사람이 매 건을 확인하지 않아도 감독은 사라지지 않습니다. ‘사람이 매 단계를 지켜보는 방식’에서 ‘시스템이 자동으로 위험을 통제하는 방식’으로 바뀝니다.
무인 운영은 무감독 운영이 아닙니다.
최소한 다음을 통제해야 합니다.
- 권한: 접근할 시스템, 읽을 데이터, 수정할 수 있는 내용.
- 예산: 작업당 최대 도구 호출 수, 자원 사용량, 처리 금액.
- 모니터링: 현재 행동, 목표 이탈 여부, 이상 징후의 적시 발견.
- 위험 통제: 우회할 수 없는 규칙과 신원을 다시 확인할 조건.
- 서킷 브레이커: 연속 실패, 비용 이상, 통제 상실 시 즉시 멈출 수 있는가.
- 롤백과 보상: 작업이 절반만 실행됐을 때 안전한 상태로 돌아가는 방법.
- 감사와 평가: 모든 판단을 추적하고 극단 사례를 반복 시험하는가.
- 책임 체계: 누가 대응하고 복구하며 합의 범위의 결과를 책임지는가.
어려운 점은 직원 경험에 있던 판단을 시스템이 실행할 규칙으로 바꾸는 것입니다.
상담원은 이상한 환불을 보고 경험상 ‘뭔가 이상하다’고 느낄 수 있습니다. Agent에는 그런 암묵적 공감대가 없습니다. 금액, 횟수, 계정, 주문 상태와 신청 사유의 불일치 가운데 무엇이 이상한지, 어떤 경우를 거절하고 재확인하거나 사람에게 넘길지 기업이 구체화해야 합니다.
이 경험을 명확히 표현해야 체계적 감독이 실제로 존재합니다.
평가도 평균 정확도만 봐서는 안 됩니다. 정상 주문을 잘 처리해도 극단 입력에서 권한을 우회하거나 연속 실패 뒤 계속 도구를 호출하면 무인 환경에 둘 수 없습니다.
신뢰할 수 있는 Agent에는 좋은 모델뿐 아니라 명확한 운영 범위, 지속적인 모니터링, 사람의 인수, 사고 대응, 복구 능력이 필요합니다.
이 프레임워크에서 Agent는 Copilot에 붙인 유행하는 새 이름이 아니라 경계 안의 자율적 결과를 책임지겠다는 약속입니다.
기업은 어느 층부터 시작해야 할까?
‘Agent를 어떻게 만들까?’부터 묻지 말고 현재 시스템에 무엇이 부족한지 보세요.
가장 약한 층을 찾아 그곳에서 시작합니다.
기업 지식이 부정확하면 먼저 데이터를 정리하고 AI가 모든 것에 답하게 서두르지 마세요.
Chatbot이 정확히 말할 수 있다면 혼란스러운 기존 API를 명확하고 안전하며 추적 가능한 도구로 정리하세요.
도구를 쓸 수 있다면 의도 거버넌스와 상태 관리를 보완해 올바른 워크플로를 계속 진행하게 하세요.
Copilot이 다단계 작업을 안정적으로 마친다면 사람의 감독에 있던 효과적인 규칙을 실행 가능한 권한, 위험 통제, 서킷 브레이커, 감사, 책임 체계로 만드세요.
네 층의 행동을 구체적으로 정리하면 다음과 같습니다.
첫째: 지식부터 정리한다
경계가 분명하고 질문이 모인 업무 하나를 고릅니다. 처음부터 회사 문서를 모두 넣지 마세요. 신뢰할 출처, 분류 방식, 권한, 관리자를 확인한 뒤 실제 질문으로 반복 시험합니다.
둘째: 도구를 정리한다
조회 도구부터 시작해 입구와 반환 결과를 안정화합니다. 데이터를 바꾸는 도구는 문제가 생기기 전에 권한, 확인, 멱등성, 감사를 먼저 갖춥니다.
셋째: 닫힌 작업 루프를 만든다
단계가 너무 많지 않고 결과를 확인하기 쉬운 흐름을 골라 의도 분해, 작업 상태, 중단과 재개, 사람의 인수를 검증합니다. 미완성 열 개보다 안정적으로 끝나는 흐름 하나가 더 가치 있습니다.
넷째: 자율 경계를 점진적으로 넓힌다
무인 실행을 허용할 작업을 먼저 적고 그 범위에 예산, 모니터링, 위험 통제, 서킷 브레이커, 보상, 책임자를 설정합니다. 안정성을 확인한 뒤 조금씩 넓히며 처음부터 모든 것을 자동화하려 하지 않습니다.
중간 버전을 정식 출시하지 않을 수는 있지만 그 뒤의 역량 구축과 검증은 건너뛸 수 없습니다.
모든 기업이 마지막 단계까지 갈 필요도 없습니다. Chatbot만으로 충분한 업무가 있고, 위험이 큰 작업은 장기적으로 사람 확인을 유지하는 편이 더 적절할 수 있습니다.
맺으며
Chatbot, AI + Tools, Copilot, Agent는 모든 기업이 따라야 할 업계 표준이 아니며 4단계에 도달해야 성공이라는 뜻도 아닙니다.
이 구분이 답하려는 질문은 더 실용적입니다. AI 프로젝트가 막혔을 때 실제로 무엇이 부족한지 볼 수 있는가?
답이 부정확하면 지식과 데이터를, 도구를 자주 잘못 고르면 API와 권한을, 흐름이 끝나지 않으면 의도와 상태를, 자율 운영이 불안하면 감독과 책임을 살펴봅니다.
한 단계 나아갈 때마다 사람이 가리고 있던 다음 층의 문제가 드러납니다. 직원 경험에 있던 규칙은 데이터 문제가 되고, 개발자의 암묵지로 호출하던 API는 도구 문제가 되며, 업무 담당자가 지켜보던 예외는 거버넌스 문제가 됩니다.
더 강한 모델을 연결한다고 이런 문제가 자동으로 사라지지 않습니다.
모두가 여전히 탐색 중이고 여러 개념의 경계도 계속 바뀔 것입니다. Agent를 만들었다고 서둘러 증명하기보다 실제 사례 하나를 골라 시스템이 질문 하나에 정확히 답하고, 도구 하나를 잘 쓰고, 흐름 하나를 안정적으로 끝내게 하세요.
실천이 다음에 부족한 것을 알려 줍니다.
현재 어느 층에 있는지 판단하고 그 층을 제대로 갖추세요. 그래야 레거시 시스템의 AI 도입이 똑똑해 보이는 대화 상자를 하나 더 붙이는 데 그치지 않습니다.
참고 자료
- NHTSA, Automated Vehicle Safety; SAE, J3016 Levels of Driving Automation.
- NIST, AI Risk Management Framework Core.
- Anthropic, Building Effective AI Agents.
WeChat 공식 계정 팔로우
기업 AI, Agent, 실제 업무 도입에 관심이 있다면 WeChat 공식 계정 ‘刘路飞’를 팔로우해 주세요. 앞으로도 이 문제들을 계속 다룰 예정입니다.
Luffy Liu · 刘路飞는 독립 제품 빌더로서 기업 AI, Agent, 실제 워크플로를 꾸준히 기록합니다.
이어서 읽기
Independent product builder · AI, agents and real workflows.