AI 에이전트는 귀하의 팀이 오랜 시간 동안 쌓아온 지식과 판단을 반영할 때 가장 잘 작동합니다. 그중 일부는 이미 문서화되어 있어 에이전트가 그대로 사용하기 쉬운 조직적 지식 (Institutional knowledge)입니다. 하지만 대부분의 훌륭한 조직은 직원들의 머릿속에 존재하는 암묵적 지식 (Tacit knowledge)에도 의존합니다. 팀들은 이를 자동화하기 위한 AI 에이전트를 구축하려고 시도하기 전까지는, 그 정보가 의미 있는 업무를 수행하는 데 얼마나 중요한지 깨닫지 못하는 경우가 많습니다. 이러한 지혜가 에이전트에 반영되도록 보장하려면 도메인 전문가 (Domain experts)의 입력을 포함하는 개선 루프 (Improvement loop)가 필요합니다.

이 가이드에서는 다음 내용을 다룹니다:

• 에이전트의 어떤 구성 요소가 인간의 판단을 흡수함으로써 이득을 얻을 수 있는지
• 개발 생명주기 (Development lifecycle)의 각 단계에서 에이전트에 인간의 판단을 통합하는 방법

실제 사례에서 영감을 얻은 예시: 트레이더를 위한 Copilot

트레이더들에게 최신 시장 데이터가 필요한 금융 서비스 기업을 상상해 보십시오. 현재 그들은 데이터 과학 (Data science) 팀에 질문을 보냅니다. 데이터 과학자가 SQL 쿼리 (SQL query)를 작성하여 관련 데이터를 검색하고 결과를 다시 보냅니다. LLM (Large Language Models)은 SQL 생성에 능숙하기 때문에, 이 워크플로우 (Workflow)는 AI 에이전트로 자동화하기에 자연스러운 후보입니다. 트레이더는 더 빠른 응답을 얻고, 데이터 과학자는 더 흥미로운 프로젝트에 집중할 수 있습니다.

이 시스템이 안정적으로 작동하려면, 에이전트는 금융 서비스 도메인 (Financial services domain) 수준과 기술적 데이터베이스 (Technical database) 계층 수준 모두에서 컨텍스트 (Context)를 필요로 합니다. 전자는 “오늘의 노출액 (Today’s exposure)” 또는 “최근 변동성 (Recent volatility)”과 같은 요청을 어떻게 해석할지 결정하는 명문화되지 않은 거래 관행을 포함합니다. 후자는 어떤 테이블이 권위 있는 데이터인지 아니면 오래된 데이터인지, 또는 어떤 쿼리 패턴이 잘못되었거나 비효율적인 경향이 있는지와 같은 데이터베이스에 대한 실질적인 지식을 포함합니다. 에이전트가 필요로 하는 모든 명문화되지 않은 컨텍스트를 포함하기 위해서는 적절한 주제 전문가 (Subject-matter experts)와 협력해야 합니다.

우리는 구체적인 구현 사례를 제공하기 위해 이 가이드 전반에 걸쳐 이 예시를 사용할 것입니다. 이 예시는 아키텍처가 단순하며, 에이전트 설계 시 인간의 판단 (Human judgement)을 개입시키는 데 있어 매우 중요한 원칙들을 보여주기 때문에 좋은 예시입니다.

인간의 판단을 통해 개선될 수 있는 에이전트의 다양한 구성 요소들을 살펴보겠습니다.

인간의 입력이 AI 에이전트의 각 구성 요소를 개선하는 방법

에이전트를 구축한다는 것은 원하는 결과를 얻기 위해 언제 LLM (Large Language Model)을 호출할지 결정하고, 각 호출 시 어떤 컨텍스트 (Context, 예: 문서, 메모리, 대화 기록, 도구)를 제공할지 관리하는 것을 의미합니다. 이러한 각각의 설계 선택 사항들은 적절한 이해관계자 (Stakeholders)의 입력을 통해 이득을 얻을 수 있습니다.

워크플로 설계 (Workflow Design)

오늘날의 LLM은 스스로의 행동 순서를 정하는 데 매우 뛰어납니다. 몇 가지 도구와 자연어 지침만 제공하면, 어떤 도구를 어떤 순서로 호출할지 스스로 파악합니다. 하지만, 워크플로의 일부를 결정론적 코드 (Deterministic code)로 정의하는 데에는 다음과 같은 이점이 있습니다: 더 낮은 지연 시간 (Latency), 더 적은 토큰 사용, 그리고 중요한 단계가 실제로 실행된다는 보장입니다. 일부 규제 환경이나 고위험 설정에서는 행동 순서를 엄격하게 제어하기 위해 코드가 필요합니다. 우리의 트레이더 코파일럿 (Trader copilot)에서는 LLM이 자율적으로 SQL 쿼리를 생성하고 실행하도록 허용하되, 최종 답변을 트레이더에게 반환하기 전에 해당 답변이 회사의 리스크 및 컴플라이언스 (Risk and compliance) 요구 사항을 충족하는지 검증하도록 하는 코드를 추가할 것입니다. 회사의 표준을 강제하는 자동화된 점검 항목을 만들기 위해서는 리스크 및 컴플라이언스 전문가의 입력이 필요할 것입니다. 또한, 에이전트가 첫 번째 시도에 유효한 답변을 생성할 확률을 높이기 위해 해당 정보를 에이전트의 사전 로드된 컨텍스트 (Pre-loaded context)에 포함할 수도 있습니다.

도구 설계 (Tool Design)

개발자는 에이전트가 사용할 수 있는 도구(Tools)를 구현해야 하며, LLM이 도구를 호출할 시점을 결정하는 데 의존하는 이름, 파라미터(Parameters), 그리고 설명(Descriptions)을 구성해야 합니다. 워크플로(Workflow)의 각 단계마다 사용 가능한 도구를 다르게 구성하는 것이 유용할 때가 많습니다. 단일 LLM 호출에 대해 도구 세트를 제한하면 모델을 의도된 동작으로 유도할 수 있으며, 관련 없는 옵션을 선택할 가능성을 줄일 수 있습니다.

우리의 코파일럿(Copilot) 도구에는 데이터베이스 스키마 검사(Database schema inspection), 쿼리 실행(Query execution), 데이터베이스 문서 검색(Database documentation retrieval) 등이 포함될 수 있습니다. 핵심적인 트레이드오프(Tradeoff)는 LLM이 생성하는 쿼리에 대한 유연성(Flexibility) 대 제어력(Control)입니다. 일반적인 execute_sql 단계는 유연한 쿼리를 허용하지만 위험성을 높이며, 파라미터화된 쿼리(Parameterized query) 도구는 더 안전하지만 성능은 낮습니다. 비즈니스 제약 조건을 면밀히 검토하면 어떤 옵션이 적합한지 감을 잡을 수 있겠지만, 확실히 알기 위해서는 도구 설계의 성능 및 위험 특성을 결정하기 위한 평가(Evaluations)를 실행해야 하며, 모든 이해관계자가 결과에 만족할 때만 배포해야 합니다.

에이전트 컨텍스트 (Agent Context)

초기 에이전트들은 모델에 단일 시스템 프롬프트(System prompt)와 일련의 도구 정의만을 제공했습니다. 시간이 흐르면서, 업계는 에이전트의 실행 시작 단계에서 훨씬 더 풍부한 컨텍스트(Context)를 제공하는 방향으로 이동해 왔습니다. 10월 출시 이후 빠르게 인기를 얻고 있는 표준인 Anthropic의 Skills가 이러한 트렌드의 대표적인 사례 중 하나입니다.

모든 것을 하나의 시스템 프롬프트에 억지로 밀어 넣는 대신, 팀에서 문서, 예시, 도메인 규칙(Domain rules)을 미리 큐레이션(Curate)한 다음 에이전트가 런타임(Runtime)에 필요한 것을 가져오도록 합니다. 이를 통해 시스템 프롬프트를 비대하게 만들지 않으면서도 에이전트가 훨씬 더 많은 지식을 사용할 수 있게 합니다. 효과적인 에이전트 설계에는 에이전트가 어떤 지식에 접근해야 하는지를 결정하고, 에이전트가 적절한 순간에 적절한 정보를 검색할 수 있도록 이를 조직화하는 과정이 포함됩니다.

최소한, 우리의 트레이더 코파일럿(trader copilot)은 데이터베이스를 사용하는 방법과 그 스키마(schema)를 이해할 수 있어야 합니다. 코파일럿이 필요로 하는 우리 팀의 추가 지식의 성격과 양에 따라, 우리는 단순히 그 지식을 수집하는 것뿐만 아니라, 이를 어떻게 구조화하고 에이전트에게 점진적으로 공개(progressively disclose)할지를 결정하는 데에도 시간을 할애해야 할 것입니다.

에이전트가 시작될 때 사용할 수 있는 정보를 선택하고 구조화하는 것은 컨텍스트 엔지니어링 (context engineering)의 규율 중 일부입니다. 컨텍스트 엔지니어링은 또한 에이전트가 작업을 수행함에 따라 각 LLM 호출 시 제공되는 정보가 어떻게 진화하는지도 다룹니다. 에이전트의 출력물과 평가 점수를 검토할 때 인간 이해관계자(human stakeholders)가 제공하는 피드백은 에이전트를 위한 엔드투엔드 (end-to-end) 컨텍스트 엔지니어링에 접근하는 방식에 영향을 미칠 수 있습니다.

이제 인간의 판단 (human judgment)으로부터 이득을 얻는 에이전트의 구성 요소들을 개괄하였으므로, 그러한 인간의 입력을 수집하는 방법에 대해 다루겠습니다.

에이전트 개선 루프에 인간의 판단 통합하기

LangChain에서 우리는 AI 에이전트를 배포하는 수백 개의 조직과 협력해 왔습니다. 가장 성공적인 팀들은 긴밀한 반복 루프 (iteration loop)를 따릅니다. 즉, 에이전트를 빠르게 구축하고, 이를 프로덕션(production) 또는 프로덕션과 유사한 환경에 배포하며, 각 단계에서 데이터를 수집하여 개선을 유도합니다. 우리는 이를 “에이전트 개선 루프 (agent improvement loop)”라고 부르는데, 이는 대부분의 성공적인 에이전트들이 이 루프를 여러 번 거쳤으며, [여기]에서 더 자세하게 다루었듯이 이 과정을 매우 상세하게 수행했음을 관찰했기 때문입니다.

빠르고 빈번하게 반복하는 것은 매우 중요합니다. 왜냐하면 에이전트의 행동을 결정하는 것은 코드가 아니라 LLM의 실시간 추론 (real-time reasoning)이기 때문입니다. AI 에이전트가 무엇을 할지는 실제로 실행해 보기 전까지는 알 수 없습니다. AI 에이전트 인터페이스는 종종 사용자가 무엇이든 입력할 수 있는 텍스트 박스와 같이 자유로운 형식(free-form)이므로, 사용자와 에이전트 간의 상호작용이 어떤 모습일지 예측하기가 더욱 어렵습니다. 에이전트를 사용자 앞에 내놓는 것이 에이전트를 궁극적으로 성공시키기 위해 필요한 데이터를 수집할 수 있는 유일한 방법입니다.

우리는 인간의 입력을 효과적으로 통합하는 방법을 논의하면서, 플라이휠 (flywheel)의 다음과 같은 단계들을 살펴볼 것입니다:

• 에이전트의 첫 번째 버전 구현
• 에이전트가 라이브 상태가 된 후 모니터링하고, 이를 개선하는 데 도움이 될 프로덕션 데이터 (production data) 수집
• 개선된 버전의 에이전트 구현 및 테스트

본격적으로 시작하기 전에, 전체 개발 라이프사이클 (development lifecycle)에 적용되는 하나의 원칙을 강조할 가치가 있습니다.

인간의 투입 시간 대비 높은 수익을 얻는 핵심: 인간의 판단과 일치하는 자동화된 평가 (automated evaluations)

우리는 팀이 에이전트의 방대한 출력물을 수동으로 검토하는 대신, 인간이 자동화된 평가기 (automated evaluators)를 설계하고 보정 (calibrate)하도록 도울 때 더 큰 레버리지 (leverage)를 얻는다는 점을 관찰했습니다. 팀의 규모가 얼마나 크든, 혹은 자원이 얼마나 풍부하든 관계없이, 광범위한 수동 검토에 의존하는 것은 경제적이지 않은 경우가 많습니다. 확장 가능한 접근 방식은 전문가의 판단을 자동화된 평가로 변환하여, 광범위하고 지속적으로 테스트할 수 있도록 하는 것입니다. 이것이 바로 LangSmith의 Align Evaluator 기능이 도와주는 부분입니다. 이 기능은 선정된 예시와 분야별 전문가 (subject matter experts)의 피드백을 사용하여 LLM-as-a-judge 평가기를 보정할 수 있는 사용자 인터페이스를 제공합니다. 우리는 개발자가 아닌 이해관계자의 판단을 모방하도록 설계된 모든 평가기에 이 기능을 사용할 것을 권장합니다.

가상의 트레이딩 회사의 관점에서 트레이더 코파일럿 (trader copilot)이 개선 루프의 각 단계를 어떻게 거치는지 따라가 보겠습니다. 우리는 인간의 입력을 어떻게 효과적으로 통합할 수 있는지, 특히 그 입력을 어떻게 자동화된 평가로 연결할 수 있는지에 대해 살펴볼 것입니다.

개발: 테스트 스위트 (test suites) 및 평가기 큐레이션

개발을 시작하기 전에, 엔지니어는 프로젝트 요구 사항의 일부로서 최소한 소규모의 유스케이스 시나리오 (use case scenarios) 세트와 기대 동작 (expected behavior)을 보유해야 합니다. 이러한 초기 테스트는 에이전트가 핵심 작업을 올바르게 수행하는지 확인하는 데 도움이 됩니다. 에이전트가 프로덕션 준비 단계에 가까워짐에 따라, 엔지니어는 프로덕트 매니저 (product managers) 및 도메인 전문가 (subject matter experts)와 협력하여 전체적인 동작과 주요 하위 구성 요소 (subcomponents)를 모두 평가할 수 있는 더욱 포괄적인 테스트 스위트 (test suite)를 구축해야 합니다.

우리의 코파일럿 (copilot)의 경우, LangSmith의 데이터셋 (datasets) 기능을 사용하여 자연어 질문과 그에 대한 정답을 쌍으로 묶은 정답 데이터셋 (ground truth datasets)을 수동으로 생성할 것입니다. 또한 우리 데이터베이스의 맥락에서 성능이 좋은 SQL이 어떤 모습인지에 대한 예시를 포함하는 데이터셋도 생성할 것입니다. 개발자가 에이전트를 구축함에 따라, 우리는 LangSmith의 평가 (evaluations) 기능을 사용하여 해당 데이터셋에 대한 테스트를 실행할 것입니다. LangSmith UI를 통해 기술적 역량을 가진 팀원과 그렇지 않은 팀원 모두가 평가 결과를 검토하고 주석을 달 수(annotate) 있으므로, 모든 구성원이 개발자의 다음 단계에 대해 의견을 일치시킬 수 있습니다.

우리는 수동 테스트 중에 마주치는 흥미로운 사례에서 영감을 얻은 예시들로 초기 데이터셋을 보강함으로써, 이 단계에서 미니 플라이휠 (mini-flywheel)을 구축할 수 있습니다. 이는 피드백 루프 (feedback loop)를 점진적으로 자동화하고, 에이전트의 v1을 출시할 준비가 되었을 때 포괄적인 테스트 스위트를 갖출 수 있도록 도와줍니다.

배포 후: 자동화된 평가 및 모니터링을 사용하여 인간의 주의가 가장 필요한 곳으로 유도하기

에이전트가 라이브 상태가 되면, 신뢰성을 보장하고 문제점이나 개선 기회를 신속하게 식별해야 합니다. 사용자 경험 (User experience)을 검증하는 전통적인 방식은 만족도 조사와 사용자 인터뷰이지만, 이 접근 방식의 결함은 사용자가 실제로 무엇을 하는지가 아니라 사용자에게 들은 내용을 측정한다는 점입니다. LLM-as-a-judge 평가자는 훨씬 더 강력한 방법을 제공합니다. 프로덕션 데이터 (Production data)에서 실행되는 자동화된 평가 (Automated evaluations)는 에이전트를 모니터링하고 인간의 주의가 필요한 상황을 드러내는 데 도움을 줄 수 있습니다. 예를 들어, LLM 판사 (LLM judge)는 사용자가 좌절감을 표현할 때 이를 자동으로 감지하고 검토를 위해 해당 상호작용에 플래그를 지정할 수 있습니다. 그러면 팀원이 트레이스 (Trace)를 조사하여 해당 문제가 버그인지, 에이전트 지식의 공백인지, 아니면 워크플로 (Workflow)의 약점인지 결정할 수 있습니다.

{insert-video-here}

데모 트레이더 앱을 확인하고 어노테이션 큐 (Annotation queues)를 설정해 보세요.

우리의 가상 기업은 먼저 트레이더들과의 모든 에이전트 상호작용을 캡처하기 위해 LangSmith **트레이싱 (Tracing)**을 설정할 것입니다. 그다음으로 다음을 위해 LangSmith의 자동화 (Automations) 기능을 설정할 것입니다:

온라인 평가 (Online evaluations): 관측 가능성 (Observability) 데이터가 들어오는 즉시 평가기 (Evaluators)를 실행하도록 LangSmith를 구성합니다. 예를 들어, 느리거나 위험한 SQL 쿼리에 대한 자동화된 코드 체크뿐만 아니라, 사용자가 코파일럿(Copilot)이 제공하는 답변에 만족하는지 확인하기 위해 대화 내용을 검토하는 LLM-as-a-judge 평가기를 활용할 수 있습니다. 알림 (Alerts): LangSmith는 에러, 지연 시간 (Latency), 또는 부정적인 온라인 평가 점수가 급증하는 것을 감지하면 기존의 알림 시스템을 트리거하여, 팀이 근본적인 문제를 신속하게 해결할 수 있도록 합니다. 주석 큐 (Annotation queues): 주목할 만한 트레이스 (Traces)를 LangSmith의 **주석 큐 (Annotation queue)**로 보내 인간의 검토를 받도록 표시합니다. 큐에서는 온라인 평가기가 매우 부정적인 피드백 점수를 반환하여 에이전트에 문제가 있음을 나타내는 사례들을 주제 전문가 (Subject matter experts)가 검토하게 됩니다. 경계선에 있는 피드백 점수는 평가기 자체를 조정해야 함을 시사할 것입니다. LangSmith는 주석 큐를 통해 제출된 피드백을 저장하므로, 향후 자동 및 수동 분석에 사용할 수 있습니다.

Insights Agent: 트레이싱 데이터에서 가치를 얻는 또 다른 방법