AI Agent 용어 정리 - apm agent

개요

현재 개인적으로 k8s환경에 lgtm stack (+open telemetry) 을 배포한 후 spring ai기반으로 모니터링을 도와주는 agent를 개발하고 있다. 개발은 바이브코딩으로 진행하며, 전체적인 설계와 구현 결과에 대한 검토는 직접 진행한다.

이 글에서는 agent 환경 구성 중 발생한 이슈와 그에 대한 트러블 슈팅, 그리고 잘 몰랐던 개념/용어에 대한 정리를 진행할 것이다.

 

개념 및 용어 정리

topK란?

백터 데이터베이스는 백터 값의 쿼리가 전달되면 유사도를 검색하여 가장 유사한 것 (가까운 것)부터 순서대로 정렬한다. 이 때에, 상위 몇 개 까지 가져올지를 정하는 정수값이다.

topK값이 지나치게 작을 경우 -> 필요한 데이터가 누락될 위험이 존재

topK값이 지나치게 클 경우 -> 프롬프트 오염 (관련 없는 데이터가 포함될 수 있음)

 

임계값 (threshold)이란?

spring ai framework에서는 similarityThreshold로 표현되는 영역이다.

쿼리 결과가 topK안에 들어오더라도, 임계값을 설정하여 유사도가 낮은 경우 결과에서 제외하도록 설정할 수 있다.

 

VectorDB의 차원이란?

차원이란 임베딩 백터의 길이 (요소의 개수)를 의미한다. 일반적으로 백터db에 데이터를 인덱싱(임베딩) 할 때 차원을 정의한다.

가령 하나의 skill을 임베딩한다면, 차원값 (e.g. 1536)을 기준으로 백터 값을 생성하여 저장한다. 만약 기존 데이터가 인덱싱되어 있는 상태에서 다른 백터db를 사용할 경우 인덱싱을 새로 해야한다. (기존 데이터와 호환되지 않는 문제가 발생함)

백터db의 차원이 높을 수록 표현력 및 정확도가 높아지지만 저장공간이 많이 필요하고 연산 비용이 증가한다는 단점이 있다.

 

이슈 사항 및 해소 과정

VectorDB (qdrant)를 k8s환경에 올리긴 하였으나 애플리케이션에서 연동하는 과정에서 이슈가 발생하였다. qdrant는 http와 grpc port를 지원하는데, 애플리케이션에서 직접 연동할 때에는 grpc 프로토콜을 사용한다. 다만 현재 클러스터에 구성된 ingress는 grpc가 아닌 web 용도의 http port로 라우팅 되고 있다 보니 백엔드 서비스에서 vectordb에 정상적으로 연동되지 않는 이슈가 식별되었다.

 

1차 시도

grpc port로 라우팅하는 ingress를 별도로 생성해준 후 애플리케이션에서 사용하려고 하였으나, http 502 오류가 지속적으로 발생함. grpc 기반의 응답을 traefik controller가 정상적으로 해석하지 못하는 것으로 파악됨.

 

2차 시도

traefik에서 제공하는 IngressRoute CRD를 활용하였다.

apiVersion: traefik.io/v1alpha1
kind: IngressRoute
metadata:
  name: qdrant-grpc
  namespace: qdrant
spec:
  entryPoints:
    - web
  routes:
    - match: Host(`grpc.qdrant.${ip}.nip.io`)
      kind: Rule
      services:
        - name: qdrant
          port: 6334
          scheme: h2c

ingressRoute를 생성한 후 애플리케이션에서 확인해보니 정상적으로 접속이 되는 것을 확인하였다.

 

정리하자면, qdrant는 ui에서 접근하기 위한 http port 외에 indexing, searching을 위한 grpc port를 별도로 관리하기 때문에 진입점을 두 개로 나누어 관리할 필요가 있다.

 

추가 고려 사항

현재 오케스트레이터의 구조는 다음과 같이 구성되어 있다.

사용자 프롬프트 -> 오케스트레이터 -> 모델 -> 모델이 기본적으로 부여된 skills를 활용 
-> skills로 해소가 되지 않는다고 판단이 되면 추론을 통해 tool 형태로 정의된 sub-agent를 호출

 

skills는 개발 당사자가 사전에 workflow를 정의해두기 때문에 model의 추론 능력을 극대화하기 어렵다. 이 지점에서 우리는 agent의 데이터 일관성과 자율성을 명확히 설정해야 한다.

앞선 게시글에서도 잠깐 언급하였지만 agent의 일관성과 자율성은 반비례 관계에 놓여 있다.

자율성은 높고, 일관성은 낮음	자율성은 낮고, 일관성은 높음
자율성이 높고 일관성이 낮은 경우 agent는 model의 추론 능력을 기반으로 스스로 필요한 도구를 찾아 내용을 종합한 후 결과를 만들어낸다. 창의적인 결과가 도출될 수 있지만 결과는 예측 불가능하며 이로 인해 데이터 일관성이 저하될 수 있다.	자율성이 낮고 일관성이 높은 경우는 앞선 사례처럼 도구들을 사전에 정의된 skill 형태로 제공하는 경우이다. 모델은 스스로 추론을 진행하긴 하나, 도구는 모두 개발자가 사전에 의도한 대로 처리된다. 당연하게도 결과는 일관되게 도출된다.

설계의 관점에서 보면 정답은 없다.

만일 금융 서비스와 같이 트랜잭션 및 데이터 정합성이 반드시 보장되어야 하는 작업이라면 데이터(결과)의 일관성을 보존하는 방향으로 설계를 해야할 것이며,

트러블 슈팅과 같이 데이터의 정합성보다는 보다 창의적인 사고를 바탕으로 다방면의 리소스를 검토해야 하는 작업의 경우엔 정적인 처리 방법보다는 모델의 자율성을 보장하여 폭넓은 추론을 할 수 있도록 유도해야 한다. 정적인 skills로 모델을 통제하려 든다면, 극단적인 경우 사용자가 지정한 workflow 내에서 해소되지 않고 영영 unresolved로 남을 수도 있다.

 

위와 같은 배경 하에서, 기존에 정적인 skills로 처리하고 있었던 트러블 슈팅 관련 리소스를 개선하여 모델이 보다 창의적으로 추론을 진행할 수 있도록 변경하고자 한다. 정적인 가이드라인은 정합성 보장이 꼭 필요한 곳에만 사용하도록 제한하고, 기본적인 기능은 모두 도구 형태로 제공하여 모델의 추론 능력을 극대화하는 것이다.

다만 자율성을 보장하는 만큼 그에 대한 검증도 필요할 것이다. 현재는 frontier-model 없이 local model만을 사용하고 있기 때문에 사용자에게 최종 결과를 반환하기 전에 오케스트레이터에서 persona를 구분하여 한 차례 자기 성찰을 진행하는 형태로 검수 작업을 적용할 계획이다. 이 과정에서, 수치화를 위해 기대 결과와 잘못된 결과 등의 프롬프트 템플릿이 필요할 것으로 보인다.