728x90

왜 AI 에이전트 레이어가 중요한가

기업 AI 프로젝트가 데모에서 운영으로 넘어갈 때 가장 먼저 부딪히는 문제는 모델 성능이 아니다. 실제 문제는 모델 주변의 시스템이다. LLM은 문장을 생성하고 추론을 보조할 수 있지만, 기업 업무는 그보다 더 복잡하다. 사용자를 식별하고, 권한을 확인하고, 신뢰할 수 있는 데이터를 조회하고, 내부 API를 호출하고, 결과를 기록하고, 필요한 경우 사람에게 승인 요청을 보내야 한다.

이 역할을 맡는 계층이 AI 에이전트 레이어다. 에이전트 레이어는 foundation model과 기업 시스템 사이에서 메모리, 계획, 도구 호출, 상태 관리, 감사 로그, 정책 적용을 조정한다. 즉 모델을 잘 고르는 문제에서 시스템을 안정적으로 설계하는 문제로 논점이 이동한다. 오늘 선정된 Planet PostgreSQL 글도 같은 관점을 제시한다. 엔터프라이즈 AI의 핵심은 모델 자체가 아니라 모델을 둘러싼 실행 계층이다.

에이전트 레이어의 핵심 구성 요소

에이전트 레이어는 보통 네 가지 기능으로 나눌 수 있다. 첫째, 메모리다. 사용자의 이전 요청, 과거 의사결정, 업무 맥락, 조직 지식을 저장하고 검색한다. 둘째, 계획이다. 고수준 목표를 여러 하위 작업으로 나누고 순서를 정한다. 셋째, 도구 호출이다. 데이터베이스 조회, 문서 검색, 티켓 생성, 이메일 발송, 코드 실행 같은 외부 시스템과 연결한다. 넷째, 거버넌스다. 접근 권한, 승인 절차, 감사 로그, 비용 추적, 장애 대응을 포함한다.

이 네 가지가 분리되어 있지 않으면 시스템은 빠르게 복잡해진다. 프롬프트 생성은 한 서비스에 있고, 검색 로직은 다른 곳에 있으며, 도구 호출은 API 핸들러에 흩어지고, 감사 로그는 나중에 붙는 식이 된다. 프로토타입에서는 동작할 수 있지만 여러 팀이 여러 에이전트를 운영하기 시작하면 관리가 불가능해진다. 따라서 에이전트 레이어는 LLM API를 감싼 얇은 래퍼가 아니라 별도의 플랫폼 계층으로 다뤄야 한다.

메모리는 LLM 기능이 아니라 데이터 플랫폼 문제다

LLM은 기본적으로 무상태 시스템이다. 이전 대화를 기억하는 것처럼 보이는 경우도 실제로는 애플리케이션이 이전 대화 내용을 다시 프롬프트에 넣어주는 것이다. 기업 업무에서는 이것만으로 부족하다. 고객 지원 기록, 승인 이력, 장애 대응 기록, 정책 변경 이력, 사용자 선호, 과거 의사결정 같은 정보는 장기간 보존되고 검색되어야 한다.

에이전트 메모리는 네 가지로 나눠 설계하는 것이 실용적이다. 세션 메모리는 현재 작업 중 필요한 단기 정보다. Redis나 인메모리 캐시가 적합하다. 장기 일화 메모리는 과거 의사결정과 사건 기록이다. PostgreSQL과 pgvector 같은 조합이 유용하다. 의미론적 메모리는 문서, 매뉴얼, SOP, 제품 카탈로그처럼 안정적인 지식 베이스다. 절차적 메모리는 승인 흐름과 업무 규칙처럼 버전 관리가 필요한 지식이다.

PostgreSQL과 pgvector가 적합한 이유

엔터프라이즈 에이전트의 장기 기억에는 단순 벡터 검색만으로 충분하지 않다. 검색 대상이 누구의 데이터인지, 현재 유효한 정보인지, 어떤 부서와 민감도에 속하는지, 어떤 시점의 정책이 적용되는지까지 함께 판단해야 한다. 이 때문에 관계형 데이터베이스의 제약 조건, 트랜잭션, 인덱스, 접근 제어가 중요하다.

PostgreSQL은 구조화된 데이터와 메타데이터를 안정적으로 관리하고, pgvector는 의미 기반 검색을 같은 데이터베이스 안에서 처리하게 해준다. 예를 들어 agent_id, user_id, memory_type, created_at, valid_from, valid_to, metadata, embedding을 함께 저장하면 “이 사용자가 볼 수 있고 현재 유효하며 특정 부서에 속한 기억 중 의미적으로 가장 가까운 기록”을 검색할 수 있다. 이는 순수 벡터 DB만으로 처리하기 어려운 접근 제어와 감사 추적을 함께 해결한다.

실무 적용 절차

1. 메모리 유형을 먼저 분리한다

모든 기록을 하나의 memory 테이블에 무작정 넣으면 검색 품질과 거버넌스가 모두 악화된다. conversation, decision, observation, preference, procedure처럼 유형을 명시해야 한다. 유형이 있어야 검색 전략과 보존 기간, 접근 권한을 다르게 줄 수 있다.

2. 벡터 검색 전에 관계형 필터를 적용한다

에이전트가 기억을 검색할 때는 먼저 agent_id, user_id, 부서, 민감도, 유효 기간으로 후보를 제한해야 한다. 그다음 벡터 유사도로 상위 결과를 고른다. 순서를 바꾸면 다른 사용자의 기억이나 만료된 정책이 검색될 위험이 있다.

3. 도구 호출은 승인 경계를 둔다

읽기 도구와 쓰기 도구를 분리하고, 삭제·결제·외부 전송·권한 변경 같은 작업은 사람 승인 단계를 둬야 한다. 에이전트가 판단할 수 있는 범위와 사람이 결정해야 하는 범위를 명확히 나누는 것이 운영 안정성의 핵심이다.

4. 로그와 평가를 기본 기능으로 설계한다

에이전트가 어떤 기억을 조회했고, 어떤 도구를 호출했으며, 어떤 근거로 결론을 냈는지 기록해야 한다. 이 로그는 장애 대응, 비용 분석, 품질 평가, 감사 대응에 필요하다. 운영 환경에서는 답변 품질보다 추적 가능성이 먼저다.

도입 체크리스트

  • 에이전트가 수행할 업무 목표가 한 문장으로 정의되어 있는가?
  • 세션 메모리, 장기 메모리, 지식 메모리, 절차 메모리가 구분되어 있는가?
  • 벡터 검색 전에 사용자·부서·민감도·유효 기간 필터가 적용되는가?
  • 도구 호출 권한이 읽기와 쓰기로 분리되어 있는가?
  • 고위험 작업에 사람 승인 단계가 있는가?
  • 프롬프트, 검색 결과, 도구 호출, 최종 응답 로그가 남는가?
  • 비용, 지연 시간, 실패율, 재시도율을 측정하는가?
  • 정책 변경 시 어떤 버전의 정책이 적용됐는지 추적 가능한가?

주의할 점과 한계

첫째, 메모리를 많이 저장한다고 좋은 에이전트가 되지는 않는다. 잘못된 기억이나 오래된 정책이 검색되면 오히려 더 위험하다. 메모리는 생성, 만료, 삭제, 수정, 감사 규칙을 갖춰야 한다. 둘째, 벡터 유사도는 권한 검사를 대체하지 못한다. 의미적으로 가까운 기록이라도 사용자가 볼 수 없는 데이터라면 검색 결과에서 제외되어야 한다.

셋째, LLM의 출력은 확률적이다. 따라서 최종 실행은 결정론적 시스템이 담당해야 한다. 모델은 계획과 판단을 돕되, 실제 데이터 변경은 명확한 API와 정책 엔진을 통해 수행해야 한다. 넷째, 에이전트 시스템은 비용이 누적되기 쉽다. 긴 컨텍스트, 반복 검색, 다단계 도구 호출이 많아질수록 지연 시간과 비용이 증가한다. 초기 설계부터 캐시, 요약, 검색 범위 제한, 호출 횟수 제한을 둬야 한다.

결론

AI 에이전트 레이어는 LLM을 운영 가능한 기업 시스템으로 바꾸는 핵심 계층이다. 모델의 벤치마크 점수만으로는 실제 업무 자동화가 완성되지 않는다. 메모리, 상태, 도구 호출, 권한, 감사, 정책, 관측 가능성이 함께 설계되어야 한다. 특히 장기 기억은 LLM 기능이 아니라 데이터 플랫폼 문제이며, PostgreSQL과 pgvector는 관계형 통제와 의미 검색을 결합할 수 있다는 점에서 실무적인 선택지가 된다.

현실적인 도입 순서는 작게 시작하는 것이다. 먼저 하나의 업무를 정하고, 어떤 기억이 필요한지 구분하고, 어떤 도구를 호출할지 제한하고, 로그와 승인 절차를 붙인다. 그런 다음 검색 품질, 실패율, 비용, 처리 시간을 측정하면서 범위를 넓혀야 한다. 이 접근이 데모형 챗봇과 운영 가능한 에이전트 시스템을 가르는 기준이다.

참고 자료

728x90
반응형
저작자표시 비영리 변경금지 (새창열림)

+ Recent posts

티스토리툴바