인공지능 에이전트가 전문 분야를 익히게 하는 법

인공지능 에이전트가 전문 분야를 익히게 하려면 검색 기능 하나만 추가해서는 부족합니다. 지식 기반은 무엇을 아는지, 에이전트 기술은 어떻게 처리하는지, 도구 호출은 무엇을 실행할 수 있는지, 평가 집합은 결과를 믿을 수 있는지를 각각 맡겨야 합니다. 이 네 층을 분리한 뒤 연결해야 소프트웨어 개발, 운영, 디자인, 사내 업무에서 안정적으로 사용할 수 있습니다.

이 글은 전문 분야 에이전트를 개발하는 인공지능 엔지니어, 내부 업무 절차를 체계화하려는 플랫폼 팀, 지속 실행 환경에 에이전트를 배포하려는 프로젝트 책임자를 위한 안내서입니다.

먼저 구분해야 할 네 가지 책임

전문 에이전트가 흔들리는 이유는 모델이 부족해서만이 아닙니다. 서로 다른 종류의 정보를 한곳에 넣고, 실행 권한과 검증 기준까지 프롬프트에 섞기 때문입니다.

앤트로픽은 에이전트 기술을 지침과 보조 자료와 실행 코드로 묶어 필요한 순간에 불러오는 방식으로 설명합니다. 이 구조는 모든 자료를 처음부터 모델 문맥에 넣는 방식보다 절차를 재사용하고 관리하기 쉽습니다. 에이전트 기술의 공식 설계 설명에서도 기술 지침과 보조 파일을 분리하는 방식을 확인할 수 있습니다. (anthropic.com)

반대로 검색 기반 생성은 자료를 찾는 방법이지, 업무를 완료하는 절차 자체가 아닙니다. 검색 결과가 정확해도 승인 순서나 실패 시 복구 방법이 없다면 실제 업무에는 바로 사용할 수 없습니다.

지식 기반의 정확성과 추적성

지식 기반에는 모델이 이미 알고 있다고 가정한 내용을 넣는 것이 아니라, 조직이 책임지고 관리하는 원문을 넣어야 합니다. 문서마다 출처, 버전, 적용 범위, 담당자, 마지막 확인 시점을 기록해야 합니다.

특히 다음 세 가지를 분리해야 합니다.

• 변경 가능성이 낮은 개념 설명
• 버전이나 정책에 따라 달라지는 운영 정보
• 지금 당장 확인해야 하는 상태 정보

첫 번째 항목은 비교적 오래 보관할 수 있습니다. 두 번째 항목은 문서 버전과 적용 기간을 함께 검색해야 합니다. 세 번째 항목은 장기 저장된 문서가 아니라 실시간 도구 조회로 확인하는 편이 안전합니다.

검색 결과는 반드시 원래 자료로 돌아갈 수 있어야 합니다. 문서 일부만 잘라 저장하면서 원문 주소와 문서 버전을 잃으면, 에이전트가 그럴듯한 답변을 해도 사람이 검증할 수 없습니다.

또한 모델의 사전 학습 지식을 감사 가능한 자료원으로 취급하면 안 됩니다. 모델은 배경 설명을 제공할 수 있지만, 사내 정책이나 현재 운영 상태의 근거가 될 수는 없습니다.

에이전트 기술의 절차 설계

에이전트 기술에는 전문 지식 전체가 아니라 반복 가능한 작업 방식을 넣어야 합니다. 예를 들어 장애 분석 기술이라면 다음과 같은 내용을 정의할 수 있습니다.

• 요청에서 서비스 이름과 영향 범위를 추출합니다.
• 지식 기반에서 해당 버전의 운영 절차를 찾습니다.
• 읽기 전용 도구로 상태를 확인합니다.
• 위험한 변경이 필요하면 사람에게 승인 요청을 보냅니다.
• 결과에는 확인한 근거와 아직 확인하지 못한 항목을 구분합니다.

이렇게 작성하면 기술은 지식 기반을 대체하지 않고, 필요한 자료를 언제 어떻게 사용할지 안내합니다. 최신 장애 대응 문서가 바뀌면 지식 기반을 먼저 수정하고, 절차 자체가 달라졌을 때만 기술을 수정하면 됩니다.

에이전트 기술을 지나치게 크게 만들면 모든 업무가 하나의 긴 지침에 의존하게 됩니다. 반대로 지나치게 작게 나누면 에이전트가 어떤 기술을 선택해야 하는지 판단하지 못합니다. 업무 결과가 다르고 승인 기준이 다르면 분리하고, 같은 절차 안에서 입력만 달라지는 정도라면 하나로 묶는 방식이 관리하기 쉽습니다.

주의할 점은 기술 문서 안에 자주 바뀌는 정책 문장을 복사하지 않는 것입니다. 복사본이 남으면 지식 기반과 기술 사이에 충돌이 생기고, 어느 쪽이 최신인지 판별하기 어려워집니다.

도구 호출과 권한 경계

도구 호출은 에이전트가 실제 환경에 영향을 주는 통로입니다. 따라서 도구 이름과 설명만 등록해서는 충분하지 않습니다. 도구마다 읽기, 작성, 실행, 승인 요청의 권한을 구분해야 합니다.

도구의 반환값도 사람이 읽기 좋은 문장보다 에이전트가 판별하기 쉬운 구조가 중요합니다. 성공 여부, 변경된 대상, 오류 코드, 재시도 가능 여부, 다음 단계가 구분되어야 합니다.

도구 호출 규격은 외부 자료와 실행 기능을 연결하는 표준으로 활용할 수 있지만, 표준을 사용한다고 권한 문제가 자동으로 해결되는 것은 아닙니다. 관련 규격에서도 도구의 목적을 이해한 뒤 사용을 승인해야 한다는 원칙을 확인할 수 있습니다. 도구 연결 규격의 공식 문서를 참고할 수 있습니다. (modelcontextprotocol.io)

도구 선택 모드와 허용 도구를 제한하는 방식은 제공하는 응용 프로그램의 공식 문서에서도 확인할 수 있습니다. 도구 호출과 허용 도구 설정 문서를 보면 자동 선택, 호출 금지, 특정 도구 강제와 같은 제어 방식을 구분합니다. (platform.openai.com)

평가 집합으로 실제 숙련도 확인

인공지능 에이전트가 전문 분야를 익혔는지 확인하려면 답변의 유창함보다 실패 방식부터 봐야 합니다. 평가 집합은 다음 범위를 포함해야 합니다.

• 정답과 출처를 요구하는 지식 질문
• 여러 단계의 절차 실행
• 권한이 없는 작업의 거절
• 오래된 문서와 최신 문서가 함께 있는 상황
• 도구가 시간 초과나 오류를 반환하는 상황
• 입력값이 누락되거나 모호한 상황

평가 집합은 한 번 만들고 끝내는 문서가 아닙니다. 지식 기반을 바꾸거나 에이전트 기술을 수정하거나 도구의 반환 형식을 바꿀 때마다 같은 기준으로 다시 실행해야 합니다. 모델이 좋아졌다는 인상보다, 같은 사례에서 거절률과 출처 정확성과 복구 결과가 어떻게 변했는지가 더 중요한 판단 근거입니다.

배포 전 운영 조건

개발 환경에서 성공한 에이전트가 지속 실행 환경에서도 안전하다는 보장은 없습니다. 배포 전에는 실행 공간과 인증 정보와 상태 저장 방식을 따로 점검해야 합니다.

다음 조건이 준비되지 않았다면 외부 자동 실행을 미루고 내부 보조 모드로 시작하는 편이 적절합니다.

• 실행 환경이 업무 시스템과 필요한 범위로만 격리되어 있습니다.
• 인증 정보가 지침 파일이나 로그에 노출되지 않습니다.
• 도구 호출과 반환값과 승인 이력이 추적됩니다.
• 중단 뒤 마지막 상태에서 안전하게 재개할 수 있습니다.
• 동시 실행 수와 재시도 횟수가 제한되어 있습니다.
• 위험 작업에는 만료되는 승인과 사람이 확인하는 단계가 있습니다.
• 평가 집합을 배포 전후에 다시 실행할 수 있습니다.

지속 실행형 에이전트는 한 번의 긴 대화만으로 모든 일을 끝내는 구조보다 세션 기록과 실행 환경과 진행 상태를 분리하는 편이 안정적입니다. 장시간 작업에서는 이전 세션의 결과를 다음 세션이 확인할 수 있는 기록과 복구 지점이 필요합니다. 장시간 실행 에이전트의 공식 설계 사례도 초기 환경 구성과 진행 기록을 분리하는 방식을 다룹니다. (anthropic.com)

내부 자료를 검색하고 초안을 만드는 낮은 위험 업무라면 단계적으로 범위를 넓힐 수 있습니다. 계정 변경, 배포, 삭제, 외부 발송처럼 되돌리기 어려운 업무는 도구 권한과 승인 절차가 평가 집합에 통과한 뒤에만 자동화를 검토해야 합니다.

네 층 설계 확인 목록

• [ ] 모든 지식 문서에 출처와 버전과 적용 범위를 기록했습니다.
• [ ] 현재 상태처럼 자주 바뀌는 정보는 실시간 조회 대상으로 분리했습니다.
• [ ] 에이전트 기술에 절차와 조건과 출력 형식과 점검 규칙을 작성했습니다.
• [ ] 기술 문서에 지식 원문 전체를 복사하지 않았습니다.
• [ ] 도구를 조회와 작성과 실행과 승인 권한으로 나누었습니다.
• [ ] 도구 반환값에 성공 여부와 오류와 다음 단계가 포함됩니다.
• [ ] 승인 없이 실행되면 안 되는 작업을 자동 호출 대상에서 제외했습니다.
• [ ] 지식 질문과 절차 실행과 경계 거절과 오래된 정보와 도구 오류를 평가합니다.
• [ ] 지식이나 기술이나 도구를 변경할 때 평가 집합을 다시 실행합니다.
• [ ] 실행 공간과 인증 정보와 로그와 상태 복구 조건을 배포 전에 확인했습니다.

처음부터 모든 사내 업무를 자동화하려 하지 마십시오. 먼저 범위가 분명한 전문 영역 하나를 골라 작은 원형을 만들고, 오래된 지식과 잘못된 절차와 도구 실패를 의도적으로 넣어 보십시오. 세 가지 실패를 안전하게 처리하지 못한다면 자료를 더 넣는 것보다 권한과 평가 구조를 먼저 고치는 편이 빠릅니다.

자주 묻는 내용

지식 기반과 에이전트 기술의 차이

지식 기반은 근거가 되는 자료를 보관하고 검색하는 층입니다. 에이전트 기술은 그 자료를 어떤 순서로 사용해 결과를 만들지 정하는 층입니다. 전자는 최신성과 출처 관리가 핵심이고, 후자는 절차 재현성과 출력 검사가 핵심입니다.

전문 지식의 저장 위치

정책, 매뉴얼, 버전별 변경 내용은 검색 가능한 지식 기반에 두는 것이 적합합니다. 반면 승인 순서나 장애 대응 흐름처럼 안정된 작업 방식은 에이전트 기술에 두어야 합니다. 동적인 상태는 장기 문서가 아니라 도구 호출로 확인해야 합니다.

전문 지식의 검증 방법

평가 집합에 정상 질문만 넣으면 실제 숙련도를 확인하기 어렵습니다. 잘못된 입력, 권한 밖 요청, 오래된 자료, 도구 오류를 포함해야 합니다. 또한 자료나 절차를 바꾸기 전후에 같은 평가를 실행해 개선 여부를 비교해야 합니다.

오래된 지식의 처리 순서

자료 담당자와 갱신 주기를 정한 뒤 지식 기반을 먼저 교체합니다. 변경 내용이 작업 순서나 승인 조건에 영향을 주면 에이전트 기술도 수정합니다. 마지막으로 평가 집합을 갱신하고 배포 환경에서 재검증해야 합니다.

현재 사용하는 환경이 단순한 개인 컴퓨터나 공유 서버라면 자료 검색과 기술 실행과 로그 보관이 한 공간에 섞이기 쉽고, 권한을 분리하거나 작업 상태를 복구하기도 어렵습니다. 특히 지속 실행되는 전문 에이전트는 격리된 실행 환경과 안정적인 원격 접속과 운영 기록이 필요하므로, 임시 구성으로 장기간 운영하기에는 한계가 있습니다.

이런 조건을 빠르게 검증해야 한다면 직접 장비를 구매하기보다 ZavCloud의 맥 미니 원격 환경을 테스트 공간으로 활용하는 방법을 검토할 수 있습니다. 다만 장기간 고정 부하를 운영하거나 물리 장치 연결이 필수인 팀이라면 자체 장비가 더 적합할 수 있습니다. 배포 전 설정과 이용 조건은 ZavCloud 도움말 센터에서 확인한 뒤, 네 층 설계와 평가 집합을 실제 환경에서 검증하는 순서가 안전합니다.