생성형 인공지능은 이미 많은 회사에서 회의록을 정리하고, 고객 문의의 초안을 만들며, 긴 문서를 요약하는 데 쓰이고 있다. 이 단계의 인공지능은 대체로 답을 돌려주는 도구다. 사람이 답을 읽고 다음 행동을 정하므로, 잘못된 답도 대개 사람의 검토 단계에서 걸러진다.

최근에는 답변형 챗봇을 넘어 AI 에이전트에 관심이 쏠리고 있다. AI 에이전트는 필요한 정보를 찾고 여러 시스템을 오가며 정해진 조건에 맞으면 실제 업무를 진행한다. 고객에게 보낼 메일을 초안으로 작성하는 데 그치지 않고 발송까지 수행하며, 재고와 계약 정보를 조회한 뒤 다음 업무를 등록하는 식이다. 이때부터 회사가 고민할 문제는 답변의 품질만이 아니다. AI가 무엇을 할 수 있는지, 누가 그 행동을 통제하는지, 잘못된 행동을 어떻게 되돌릴지를 정해야 한다.

이러한 변화는 눈에 띄지 않는 업무에서 먼저 나타날 가능성이 크다. 문의를 분류하고, 정해진 자료를 찾아 담당자에게 전달하고, 누락된 정보를 다시 요청하는 일은 각각 단순해 보인다. 그러나 실제로는 고객별 약속, 문서의 최신성, 담당자의 권한, 마감 시점이 함께 얽혀 있다. 에이전트의 가치는 대형 언어모델 자체보다 각 회사의 업무 흐름을 얼마나 정확히 읽고 실행하는지에 따라 달라질 수 있다.

같은 모델을 사용하더라도 어떤 자료를 먼저 조회하는지, 어느 단계에서 사람에게 넘기는지, 실패한 작업을 다시 시도할 수 있는지에 따라 결과가 달라진다. 결국 기업이 축적하게 되는 자산은 AI 모델만이 아니라 업무 규칙을 실행 가능한 형태로 바꾼 절차, 권한 구조, 상태 관리와 데이터다. 특허 관점에서도 바로 이 실행 구조를 먼저 살펴볼 필요가 있다.

세계지식재산기구(WIPO)에 따르면 생성형 AI 특허 패밀리 공개 건수는 2023년 약 1만 4,000건에서 2025년 3만 7,808건으로 늘었고, 2024년과 2025년 두 해에 공개된 신규 패밀리는 5만 6,000건을 넘었다. WIPO는 추론 모델과 에이전트형 시스템도 신흥 특허 영역으로 보고 있다. 다만 AI라는 이름만으로 권리가 생기는 것은 아니다. 실제 제품에서 사람이 하던 판단과 실행이 어디에서 나뉘고, 그 과정의 기술적 문제를 어떤 구조로 해결하는지가 중요하다.

답변형 AI에서 행동하는 AI로

답변형 AI와 에이전트의 차이는 생각보다 단순하다. 전자는 질문을 받고 문장이나 자료를 내놓는다. 후자는 그 결과를 바탕으로 다른 도구를 호출하고 다음 단계를 정하며, 때로는 외부 시스템의 상태를 바꾼다. 조회 기능만 제공하던 AI가 일정 등록, 고객 통지, 데이터 입력까지 맡게 되면 서비스의 성격도 달라진다.

물론 모든 자동화가 에이전트인 것은 아니다. 정해진 양식에 숫자를 옮기는 반복 작업도 자동화할 수 있다. 에이전트라면 현재 상태를 읽고 다음 행동을 고르며, 행동의 결과에 따라 다시 판단하는 흐름이 있어야 한다. 고객 요청을 읽고 필요한 자료를 찾은 뒤, 자료가 충분하면 회신을 준비하고 부족하면 추가 자료를 요청하는 식이다.

기존의 업무자동화는 미리 정한 순서를 그대로 실행하는 경우가 많았다. 반면 에이전트는 입력과 상황에 따라 경로가 달라질 수 있다. 같은 고객 문의라도 계약 상태, 첨부된 자료, 담당자의 권한에 따라 조회할 시스템과 다음 행동이 달라진다. 이런 분기와 재판단이 많아질수록 단순한 화면이나 프롬프트보다 상태 판단과 도구 연결 방식이 제품의 핵심으로 이동한다.

이 과정에서는 어느 한 단계가 잘못되어도 최종 결과가 달라진다. 최신 계약서가 아닌 이전 버전을 읽거나, 동명이인 고객을 선택하거나, 외부 시스템의 실패 응답을 성공으로 판단하면 그 뒤의 작업도 틀어진다. 따라서 정확성도 최종 답변 하나가 아니라 자료 선택, 도구 호출, 실행 전 조건 확인, 실행 결과 확인을 나누어 평가해야 한다.

책임의 성격도 달라진다. 챗봇이 틀린 답을 만들면 사람이 그 답을 버리면 되지만, 에이전트가 잘못된 주소로 자료를 보내거나 이미 처리한 요청을 다시 등록하면 실제 업무 상태가 바뀐다. 그래서 실행을 제한하고 확인하며 복구하는 기능은 부가적인 안전장치가 아니라 에이전트 제품의 본체에 가까워진다.

이 지점부터 특허 검토의 대상도 달라진다. 단순한 문장 생성보다 어떤 조건에서 어떤 도구를 선택하는지, 실행 전에 무엇을 확인하는지, 실패하면 어느 상태로 돌아가는지가 더 구체적인 기술 구성으로 드러날 수 있다. AI를 도입할 때 "무엇을 자동화할 것인가"뿐 아니라 "어떤 조건에서 실행할 것인가"를 묻는 이유다.
 

실행 기록은 운영 자산이자 발명 기록이다

실행에는 흔적이 남아야 한다. 사람이 업무를 처리할 때도 누가 어떤 자료를 보고 승인했는지, 언제 고객에게 알렸는지, 왜 예외 처리를 했는지가 나중에 중요해진다. AI가 업무에 들어오면 단순히 "AI가 처리했다"는 기록으로는 부족하다. 어떤 요청을 받았고, 어떤 문서를 근거로 삼았으며, 어떤 도구를 호출했고, 그 결과가 무엇이었는지를 이어서 볼 수 있어야 한다.

미국 국립표준기술연구소(NIST)는 생성형 AI가 그럴듯하지만 잘못된 내용을 만들 수 있고, 배포 뒤에는 모델과 데이터, 외부 시스템의 변화까지 지속적으로 살펴야 한다고 지적한다. AI가 답변을 넘어 실행까지 맡는다면 잘못된 판단이 실제 업무에 반영되기 전에 어디에서 멈출 수 있는지도 확인해야 한다.

배포 뒤의 모니터링이 중요한 이유는 시스템이 고정되어 있지 않기 때문이다. 모델이 바뀌지 않아도 참조 문서가 갱신되고 외부 API의 형식이나 응답 시간이 달라질 수 있다. 사람이 자주 수정하는 단계, 실패가 반복되는 도구, 특정 자료 버전에서 생기는 오류를 기록해 두면 문제가 모델에 있는지 업무 연결 구조에 있는지 구분하기 쉬워진다.

작업 기록은 사후 책임을 따지기 위한 장치에 그치지 않는다. 특정 요청에서 사람의 승인이 반복해서 필요하다면 아직 자동 실행에 적합하지 않다는 신호가 된다. 반대로 같은 조건에서 안정적으로 같은 결과가 나오는 업무라면 자동화 범위를 넓힐 근거가 된다. 입력값, 참조 문서의 버전, 실행 전 조건, 도구의 응답, 승인자의 판단, 최종 상태를 연결해 두면 시스템을 개선할 수 있다.

특허 업무에서도 이러한 기록은 의미가 있다. 개발 과정에서 어떤 오류를 줄이려 했는지, 어떤 조건을 추가한 뒤 중복 실행이나 잘못된 도구 호출이 감소했는지가 남아 있으면 발명의 문제와 효과를 설명하기 쉬워진다. 운영 로그 자체를 모두 공개할 필요는 없지만, 기술적 개선이 만들어진 과정을 기록해 두는 것은 권리화의 출발점이 될 수 있다.
 

AI 에이전트에 어디까지 권한을 부여할 것인가

기업이 AI 에이전트를 도입할 때 가장 먼저 정할 것은 기능 목록보다 권한의 범위다. 문서를 읽는 권한, 초안을 만드는 권한, 외부 시스템에 입력하는 권한, 고객에게 발송하는 권한은 서로 다르다. 한 번에 넓은 권한을 부여하면 시연은 화려해 보일 수 있지만, 실제 업무에서는 작은 예외 하나가 더 큰 오류로 이어질 수 있다.

권한은 사용자 계정의 접근권한만을 뜻하지 않는다. AI가 어떤 조건에서 어떤 행동을 선택할 수 있는지도 권한의 일부다. 예컨대 CRM 전체를 검색하게 하는 대신 현재 처리 중인 고객만 조회하도록 제한하거나, 특정 등급의 문서가 포함되면 자동 실행을 멈추도록 만들 수 있다. 같은 기능이라도 입력 조건과 실행 범위를 얼마나 세밀하게 나누느냐에 따라 위험과 기술 구성이 달라진다.

외부에서 읽어 들인 내용도 주의해야 한다. 메일이나 첨부문서에 섞인 지시문을 에이전트가 처리할 데이터가 아니라 수행할 명령으로 받아들이면 실제 발송이나 정보 유출로 이어질 수 있다. 모델의 판단력을 높이는 것만으로는 이 문제를 없애기 어렵다. 외부 내용은 데이터로 취급하고, 발송이나 결제처럼 되돌리기 어려운 도구의 호출 조건을 별도로 제한하는 구조가 필요하다.

권한을 나눌 때는 사람의 역할도 함께 정해야 한다. 모든 작업을 사람이 마지막에 본다는 원칙만으로는 부족하다. 어떤 조건에서 누구에게 검토를 요청하고, 승인자가 무엇을 확인하며, 승인이 없으면 시스템이 어느 상태에서 멈추는지를 정해야 한다. AI 경영시스템 표준인 ISO/IEC 42001이 역할과 책임, 위험 관리, 투명성, 성능 모니터링을 함께 다루는 것도 기술과 운영 통제를 떼어 보기 어렵기 때문이다.

이러한 권한 분리는 단순한 보안 정책에 머물지 않을 수 있다. 역할별 권한을 확인해 도구의 후보군을 바꾸거나, 문서 등급과 업무 상태에 따라 호출 순서를 변경하거나, 특정 조건에서 자동으로 사람에게 넘기는 방법이 구체적인 처리 구조와 효과를 갖는다면 특허 검토 대상이 된다. 중요한 것은 "권한을 제한한다"는 원칙이 아니라 그 제한을 시스템이 어떻게 판단하고 실행하는지다.
 

승인과 기록은 실행 구조의 일부다

사람의 승인을 넣는다고 해서 자동화가 멈추는 것은 아니다. 승인 단계를 잘 설계하면 담당자는 업무 전체를 다시 처리하지 않고 판단이 필요한 부분만 확인할 수 있다. 내부 일정 등록과 고객에게 계약서를 발송하는 행위에 같은 승인 절차를 적용할 필요도 없다. 되돌리기 쉽고 영향이 작은 업무는 사후 확인으로 충분할 수 있지만, 외부 효과가 크거나 복구가 어려운 업무에는 실행 전 승인이 필요할 수 있다.

승인 화면도 단순한 예 또는 아니오 버튼으로 끝나서는 안 된다. 승인자는 어떤 정보가 근거인지, AI가 어느 규칙을 적용했는지, 승인 뒤 무엇이 바뀌는지를 확인할 수 있어야 한다. 반대로 모든 자료를 그대로 보여 주면 검토 부담이 커진다. 업무 위험도에 따라 핵심 근거와 예외 사유를 먼저 보여 주고 필요할 때 상세 기록으로 내려가게 하는 방식이 현실적이다.

승인과 기록의 설계가 중요한 이유

규제도 이런 방향을 뒷받침한다. EU AI Act는 고위험 AI에 기록과 사람의 감독을 요구하고 있으며, 국내 인공지능기본법도 고영향 인공지능에 대해 위험관리, 설명, 사람의 관리와 감독, 관련 문서의 작성과 보관을 규정한다. 모든 AI 에이전트에 같은 의무가 적용되는 것은 아니지만, 실행을 추적하고 사람이 개입할 수 있는 구조가 실제 제품에서 중요해지고 있다는 점은 분명하다.

2026년 개정된 EU 규정에 따라 고위험 AI의 주요 의무는 유형에 따라 2027년 12월 또는 2028년 8월부터 적용되지만, 기록과 감독을 중시하는 방향 자체는 바뀌지 않았다. 국내 인공지능기본법도 이미 시행 중이다. 다만 이런 규제 일정을 제품 설계의 목표로 삼을 필요는 없다. 규제 준수에 필요한 기능과 경쟁사와 차별되는 기술 구성을 구분해서 보는 편이 좋다.

특허 관점에서는 규제 문구 자체보다 이를 구현하는 기술적 방법을 봐야 한다. 어떤 위험 조건에서 승인을 요청하는지, 승인자에게 어떤 근거를 추려 보여 주는지, 승인 전후의 시스템 상태를 어떻게 연결하는지가 제품마다 달라질 수 있다. 승인은 책임을 사람에게 떠넘기는 버튼이 아니라 에이전트의 실행을 제어하는 기술 구조의 일부다.

복구 구조도 기술적 차별성이 된다

자동화에서 가장 불편한 질문은 "잘못되면 어떻게 할 것인가"다. 같은 요청을 두 번 받아 중복 실행하거나, 실행 뒤 원본 자료가 바뀌거나, 담당자가 승인한 뒤 고객이 요청을 철회하는 경우를 생각해 볼 수 있다. 실행을 멈추고, 이미 한 작업을 취소하거나 보정하고, 필요한 경우 사람에게 넘기는 기능은 편의 기능이 아니라 업무 흐름의 일부다.

복구는 단순히 취소 버튼을 만드는 일이 아니다. 발송한 메일은 완전히 되돌릴 수 없지만 후속 안내를 보내고 업무 상태를 보류로 바꿀 수 있다. 외부 시스템에 입력한 값은 이전 값과 변경 사유를 남겨야 할 수 있다. 결제나 계약처럼 복구에 별도 승인이 필요한 업무도 있다. 따라서 실행 결과를 성공과 실패 두 상태로만 저장해서는 이런 차이를 처리하기 어렵다.

업무 상태를 실행 전, 요청됨, 처리 중, 완료, 실패, 사람 확인 필요 등으로 구분하고 상태 전환 조건을 관리하면 중복 실행과 누락을 줄일 수 있다. 네트워크 응답을 받지 못했다고 바로 같은 명령을 다시 보내는 대신, 같은 요청이 이미 처리됐는지 확인하거나 보류 상태로 넘기는 구조가 필요하다. 실행 요청에 식별자를 부여해 재호출을 통제하는 방식도 한 예다.

예외 상황을 모두 AI가 스스로 해결하도록 만드는 것이 목표일 필요도 없다. 자료가 충돌하거나 권한이 부족하거나 외부 도구의 결과를 신뢰하기 어려운 경우에는 사람에게 넘기는 편이 안전하다. 고객에게 이미 잘못된 안내가 나간 경우에는 내부 데이터만 되돌리는 것으로 끝나지 않고 후속 안내와 재처리까지 연결해야 한다. 복구의 단위가 업무와 고객 경험에 따라 달라지는 셈이다.

이러한 상태 관리와 복구 절차는 특허에서도 중요한 후보가 된다. 외부 도구의 결과를 확인해 중복 여부를 판단하는 방법, 실행 전후의 상태를 비교해 복구 범위를 정하는 방법, 예외 유형에 따라 자동 복구와 사람 개입을 나누는 방법처럼 구체적인 기술 구성이 있기 때문이다. 정상 흐름보다 예외를 어떻게 처리하는지가 오히려 제품의 차이를 드러내는 경우가 많다.
 

AI 에이전트의 IP는 어떻게 구체화 할 것인가

AI 에이전트와 관련된 특허를 검토할 때는 "AI를 써서 업무를 자동화한다"는 설명에서 몇 단계는 더 깊게 들어가는 편이 특허성을 확보하는데 유리하다. 서로 다른 자료의 신뢰도를 비교해 실행 여부를 정하는 방식, 역할과 업무 상태에 따라 도구 호출 순서를 바꾸는 방식, 실행 결과를 읽고 중복이나 오류를 탐지하는 방식, 외부 콘텐츠에 섞인 지시를 걸러 도구 호출을 제한하는 방식, 예외가 생기면 특정 상태로 되돌리고 담당자에게 넘기는 방식에서 기술적 차이가 나타날 수 있다.

실무적으로는 모델, 데이터, 실행 구조를 나누어 보는 편이 유용하다. 범용 모델 자체는 여러 회사가 동일하게 사용할 수 있고, 데이터 역시 계약이나 접근권한에 따라 활용 범위가 달라진다. 반면 회사의 업무 규칙을 어떤 입력과 상태로 표현하고 어떤 도구와 연결하는지는 제품을 만들면서 새로 설계되는 경우가 많다. 에이전트 특허 발굴에서는 실행 계층을 별도의 기술 자산으로 보는 관점이 필요하다.

WIPO가 에이전트형 시스템을 아직 초기 특허 영역으로 보는 만큼, 제품이 완성된 뒤 경쟁사 특허를 살펴보기보다 설계 단계부터 발명 후보를 찾는 편이 낫다. 개발팀이 해결하려 한 예외, 특정 권한을 나눈 이유, 종전 방식에서 느렸거나 불안정했던 부분을 기록하고, 그 문제를 줄이기 위해 어떤 입력과 조건, 상태를 추가했는지를 정리해야 한다.

특허 검토 질문도 구체적이어야 한다. 어떤 상황에서 잘못된 도구가 호출되는가. 권한에 따라 참조할 문서가 달라지는가. 같은 요청이 중복 실행되는가. 외부 도구의 실패를 어떻게 확인하는가. 여러 결과가 충돌할 때 어느 결과를 채택하는가. 이런 질문에 대한 시스템의 처리 방식이 청구항의 후보가 될 수 있다.

물론 이런 구성이 모두 특허가 되는 것은 아니다. 단순한 업무 규칙이나 추상적인 판단 기준만으로는 부족하고, 선행기술과 구별되는 구체적인 기술 구성과 효과가 필요하다. 그래서 서비스 화면이나 기능 이름보다 입력 정보, 판단 조건, 도구 호출, 상태 변화, 오류 처리 사이의 관계를 기술적으로 정리하는 작업이 먼저다.

소스코드와 화면 구성, 데이터베이스 구조처럼 다른 권리와 관리수단이 작동하는 부분도 구분해야 한다. 소스코드 자체는 저작권으로 보호될 수 있지만 동일한 기능을 다른 코드로 구현하는 경쟁사를 막는 데에는 한계가 있다. 반대로 기능을 구현하는 핵심 처리 구조가 특허 요건을 갖추면 구현 언어가 달라도 권리범위를 설계할 수 있다. 학습용 또는 운영용 데이터와 세부 규칙은 비밀관리 조치를 전제로 영업비밀로 관리할 수 있다. 하나의 서비스 안에서도 보호수단을 나누는 이유다.

청구항을 설계할 때는 서비스가 분산되어 있다는 점도 고려해야 한다. 모델이 판단하고, 별도의 서버가 권한을 확인하며, 외부 도구가 실제 실행을 담당한다면 하나의 주체가 모든 단계를 수행하지 않을 수 있다. 어떤 구성요소의 결합을 핵심으로 볼지, 서버 측 처리와 단말 측 처리를 어떻게 나눌지, 경쟁사의 구현에서 어떤 단계를 확인할 수 있을지를 함께 검토해야 실제 권리행사에 유리한 특허가 된다.

이러한 과정은 특허 명세서 작성을 위한 형식적 절차에 그치지 않는다. 기술팀은 도구 호출과 상태 관리를, 운영팀은 승인과 예외 처리를, 보안팀은 접근권한과 기록 보존을 설명한다. 서로 다른 설명을 하나의 기술 구조로 정리하면 제품의 차별성이 분명해지고, 동시에 어떤 부분을 특허로 권리화하고 어떤 부분을 영업비밀로 관리할지도 정리할 수 있다.
 

AI는 실행을, 회사는 판단과 권리를

AI 에이전트를 도입하는 목적은 사람을 업무에서 밀어내는 데 있지 않다. 사람이 모든 화면을 확인하느라 시간을 쓰지 않도록 하되, 책임과 판단이 필요한 순간에는 분명하게 개입하도록 만드는 데 가깝다. 좋은 자동화는 더 많은 실행을 약속하기보다 맡길 실행과 멈출 실행을 구분하고, 그 판단과 결과를 다시 확인할 수 있게 만든다.

이러한 관점은 IP 전략과도 연결된다. 개발이 끝난 뒤 화면에 보이는 기능만 모아 특허를 검토하면 실제 차별성을 놓치기 쉽다. 설계 단계에서 반복되는 오류와 예외, 권한을 나눈 이유, 사람이 개입해야 하는 조건을 함께 기록해야 특허 후보와 영업비밀 후보를 일찍 구분할 수 있다. 제품 로드맵과 출원 로드맵을 따로 만들기보다 주요 기능의 설계 검토 시점에 발명 검토를 함께 넣는 방식이 효율적인 이유다.

비슷한 AI 모델을 누구나 사용할 수 있게 될수록 기업의 차이는 모델 자체보다 회사의 자료를 어떻게 연결하고, 어떤 조건에서 도구를 호출하며, 어디까지 자동 실행을 허용하고, 문제가 생겼을 때 어떻게 정상 상태로 돌아오는지에서 생길 가능성이 크다. 바로 그 실행 구조가 AI 에이전트 시대의 기술 자산이다. 챗봇이 일을 맡는 순간부터 회사는 AI의 답뿐 아니라 AI의 행동을 설계해야 하고, 그중 공개해도 되는 기술은 특허로, 공개하면 경쟁력이 사라지는 운영 노하우는 영업비밀로 남기는 IP 전략이 필요하다.

BLT 칼럼은 BLT 파트너변리사가 작성하며 매주 1회 뉴스레터를 통해 발행됩니다.
뉴스레터 구독신청

필자 소개
유철현 대표 변리사는 서울대 재료공학부를 졸업하고 2007년 44기 변리사 시험에 합격했습니다. 스타트업을 발굴하고 직접 투자하는 ‘엑셀러레이터형’ BLT 특허법률사무소를 시작으로, IT와 BM분야의 전문성을 살려 다양한 기술 기반 기업의 지식재산 및 사업 전략 컨설팅을 수행하고 있습니다. 현재 중소벤처기업진흥공단 심의위원과 한국엔젤투자협회 TIPs 사업 심사를 담당하고 있습니다.

특허법인 BLT
누군가는 특허를 만들 때, BLT는 당신의 사업의 성공을 만들어 냅니다. The Only Firm for Your Success!!

원문 보러가기

#BLT #비엘티 #특허법인 #인공지능 #AI에이전트 #생성형AI #업무자동화 #특허전략 #지식재산 #AI특허 #영업비밀 #HumanInTheLoop #AgenticAI