🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

AI 에이전트를 신뢰성 있게 개선하려면 조직 안에 문서화된 지식뿐 아니라 직원들의 암묵지와 판단을 개발·평가·운영 전 과정의 자동화된 개선 루프에 반영해야 한다.

📌 핵심 요약

• 글은 AI 에이전트가 실제 업무에서 잘 작동하려면 단순한 코드나 프롬프트만으로는 부족하며, 조직이 오랜 시간 축적한 도메인 지식과 사람의 판단이 에이전트 개선 루프에 들어가야 한다고 설명한다.
• 금융회사 트레이더용 데이터 조회 코파일럿 사례를 통해, LLM이 SQL 생성에는 강하더라도 ‘오늘의 익스포저’ 같은 업무 표현의 의미, 권위 있는 테이블, 잘못되기 쉬운 쿼리 패턴 같은 암묵적 맥락이 필요하다고 보여준다.
• 인간의 입력은 워크플로 설계, 도구 설계, 에이전트 컨텍스트 구성에 각각 영향을 준다. 특히 고위험 환경에서는 LLM의 자율성을 그대로 두기보다 코드로 필수 검증 단계를 강제하고, 이해관계자가 납득할 수 있는 평가를 거쳐야 한다.
• 성공적인 팀은 빠르게 첫 버전을 만들고, 실제 또는 실제와 유사한 환경에 배포한 뒤, 추적·평가 데이터를 모아 반복 개선한다. 이는 에이전트의 행동이 코드만이 아니라 LLM의 실시간 추론에 의해 결정되므로 실행 전에는 예측하기 어렵기 때문이다.
• 사람이 대량의 결과물을 직접 검토하는 방식보다, 전문가의 판단을 자동 평가기와 테스트 데이터셋에 반영하는 방식이 더 확장 가능하다. LangSmith의 데이터셋, 평가, 추적, 자동화, Align Evaluator 기능은 이 루프를 운영하는 수단으로 제시된다.

🧩 주요 포인트

1. 글은 AI 에이전트가 실제 업무에서 잘 작동하려면 단순한 코드나 프롬프트만으로는 부족하며, 조직이 오랜 시간 축적한 도메인 지식과 사람의 판단이 에이전트 개선 루프에 들어가야 한다고 설명한다.
2. 금융회사 트레이더용 데이터 조회 코파일럿 사례를 통해, LLM이 SQL 생성에는 강하더라도 ‘오늘의 익스포저’ 같은 업무 표현의 의미, 권위 있는 테이블, 잘못되기 쉬운 쿼리 패턴 같은 암묵적 맥락이 필요하다고 보여준다.
3. 인간의 입력은 워크플로 설계, 도구 설계, 에이전트 컨텍스트 구성에 각각 영향을 준다. 특히 고위험 환경에서는 LLM의 자율성을 그대로 두기보다 코드로 필수 검증 단계를 강제하고, 이해관계자가 납득할 수 있는 평가를 거쳐야 한다.
4. 성공적인 팀은 빠르게 첫 버전을 만들고, 실제 또는 실제와 유사한 환경에 배포한 뒤, 추적·평가 데이터를 모아 반복 개선한다. 이는 에이전트의 행동이 코드만이 아니라 LLM의 실시간 추론에 의해 결정되므로 실행 전에는 예측하기 어렵기 때문이다.
5. 사람이 대량의 결과물을 직접 검토하는 방식보다, 전문가의 판단을 자동 평가기와 테스트 데이터셋에 반영하는 방식이 더 확장 가능하다. LangSmith의 데이터셋, 평가, 추적, 자동화, Align Evaluator 기능은 이 루프를 운영하는 수단으로 제시된다.

🧠 상세 정리

1. 문제의식: 에이전트에는 조직의 판단이 들어가야 한다

글의 출발점은 AI 에이전트가 팀이 오랜 시간 쌓아온 지식과 판단을 반영할 때 가장 잘 작동한다는 주장이다. 조직에는 이미 문서화되어 에이전트가 비교적 쉽게 사용할 수 있는 제도적 지식도 있지만, 실제 성과를 좌우하는 많은 지식은 직원들의 머릿속에 암묵지로 남아 있다. 팀들은 업무 자동화를 시도하기 전까지 이런 정보가 얼마나 핵심적인지 자주 인식하지 못한다. 따라서 에이전트를 개선하려면 단순히 모델이나 도구를 붙이는 것이 아니라, 도메인 전문가의 입력을 지속적으로 받아들이는 개선 루프가 필요하다고 설명한다.

2. 트레이더 코파일럿 사례: SQL 자동화만으로는 충분하지 않다

글은 금융 서비스 회사의 트레이더들이 최신 시장 데이터를 얻기 위해 데이터 사이언스 팀에 질문을 보내는 상황을 예로 든다. 기존에는 데이터 과학자가 SQL 쿼리를 작성하고 관련 데이터를 조회해 결과를 돌려줬지만, LLM은 SQL 생성에 강하므로 이 흐름은 AI 에이전트 자동화 후보가 된다. 그러나 안정적으로 작동하려면 금융 도메인 수준의 맥락과 데이터베이스 기술 계층의 맥락이 모두 필요하다. 예를 들어 ‘오늘의 익스포저’나 ‘최근 변동성’ 같은 표현을 어떻게 해석할지, 어떤 테이블이 권위 있고 어떤 테이블이 오래되었는지, 어떤 쿼리 패턴이 부정확하거나 비효율적인지 알아야 한다.

3. 워크플로 설계: LLM 자율성과 결정적 코드의 균형

에이전트를 만든다는 것은 언제 LLM을 호출할지, 각 호출에 어떤 문서·메모리·대화 기록·도구를 제공할지 결정하는 일이다. 글은 LLM이 도구와 자연어 지시를 받으면 스스로 행동 순서를 정하는 데 뛰어나지만, 워크플로의 일부는 결정적 코드로 정의할 이점이 있다고 말한다. 코드로 고정하면 지연 시간과 토큰 사용량을 낮출 수 있고, 반드시 실행되어야 하는 핵심 단계가 빠지지 않도록 보장할 수 있다. 트레이더 코파일럿에서는 LLM이 SQL을 생성하고 실행하도록 두되, 최종 답변이 회사의 리스크와 컴플라이언스 기준을 만족하는지 검증하는 단계는 코드로 강제하는 방식이 제시된다.

4. 위험·컴플라이언스 전문가의 역할: 자동 검증 기준 만들기

고위험 또는 규제가 중요한 환경에서는 에이전트의 행동 순서를 엄격히 통제해야 할 수 있다. 글은 트레이더 코파일럿의 최종 답변이 리스크와 컴플라이언스 요구사항을 충족하는지 확인하기 위해, 위험 관리 및 컴플라이언스 전문가의 입력이 필요하다고 설명한다. 이들의 판단은 자동화된 체크로 구현되어 회사 기준을 집행할 수 있으며, 동시에 에이전트가 처음부터 유효한 답변을 만들 가능성을 높이기 위해 사전 로드된 컨텍스트에도 포함될 수 있다. 즉 사람의 판단은 사후 검토에만 쓰이는 것이 아니라, 에이전트가 답변을 생성하기 전의 지침과 실행 중 검증 장치 모두에 반영된다.

5. 도구 설계: 유연성과 통제 사이의 선택

개발자는 에이전트가 사용할 도구를 구현하고, LLM이 도구 호출 여부를 판단할 때 참고하는 이름·매개변수·설명을 설정해야 한다. 글은 워크플로의 단계마다 사용 가능한 도구를 다르게 제한하면 모델을 의도한 행동으로 유도하고, 관련 없는 도구를 고를 가능성을 낮출 수 있다고 말한다. 트레이더 코파일럿의 도구에는 데이터베이스 스키마 검사, 쿼리 실행, 데이터베이스 문서 검색이 포함될 수 있다. 일반적인 execute_sql 도구는 유연하지만 위험이 커지고, 매개변수화된 쿼리 도구는 더 안전하지만 능력이 제한될 수 있으므로, 실제 성능과 위험 특성을 평가로 확인하고 이해관계자가 결과에 동의할 때 출시해야 한다.

6. 에이전트 컨텍스트: 프롬프트를 넘어 지식을 구조화하기

초기 에이전트는 하나의 시스템 프롬프트와 도구 정의만 모델에 제공하는 경우가 많았지만, 글은 업계가 실행 시작 시 훨씬 풍부한 컨텍스트를 제공하는 방향으로 이동했다고 설명한다. 모든 내용을 하나의 시스템 프롬프트에 밀어 넣기보다, 팀이 문서·예시·도메인 규칙을 미리 정리해두고 에이전트가 런타임에 필요한 것을 가져오도록 하는 방식이 강조된다. 트레이더 코파일럿은 최소한 데이터베이스 사용법과 스키마를 이해해야 하며, 추가 지식이 많다면 이를 수집하는 것뿐 아니라 어떻게 구조화하고 단계적으로 공개할지도 설계해야 한다. 이런 맥락에서 컨텍스트 엔지니어링은 각 LLM 호출에 제공되는 정보가 작업 진행에 따라 어떻게 바뀌는지까지 포함한다.

7. 에이전트 개선 루프: 빠른 배포와 반복이 필요한 이유

LangChain이 여러 조직과 AI 에이전트 배포를 진행하며 관찰한 성공 패턴은, 빠르게 에이전트를 만들고 실제 또는 실제와 유사한 환경에 배포한 뒤 각 단계의 데이터를 모아 개선하는 것이다. 글은 이를 ‘agent improvement loop’라고 부르며, 성공적인 에이전트는 이 루프를 여러 번 거친다고 설명한다. 빠르고 빈번한 반복이 중요한 이유는 에이전트의 행동을 결정하는 것이 전통적 코드만이 아니라 LLM의 실시간 추론이기 때문이다. 사용자가 자유 형식 텍스트 박스에 무엇이든 입력할 수 있는 인터페이스에서는 상호작용을 미리 예측하기 더 어렵고, 결국 사용자가 실제로 사용하는 장면에 놓아야 필요한 데이터를 얻을 수 있다.

8. 평가와 운영: 사람의 시간을 자동 평가 설계에 집중하기

글은 사람이 많은 에이전트 출력을 직접 검토하는 방식보다, 사람이 자동 평가기를 설계하고 보정하는 방식이 더 높은 레버리지를 낸다고 주장한다. 아무리 규모가 크고 자원이 많은 팀이라도 광범위한 수동 리뷰에 의존하는 것은 경제적이지 않으므로, 전문가 판단을 자동 평가로 번역해 넓고 지속적으로 테스트하는 편이 확장 가능하다. 개발 단계에서는 자연어 질문과 정답, 좋은 SQL 예시를 LangSmith 데이터셋으로 만들고 평가 기능으로 테스트하며, 기술·비기술 팀원이 결과를 검토하고 주석을 달아 다음 개발 방향을 맞춘다. 배포 후에는 추적과 자동화를 통해 생산 데이터에 온라인 평가를 실행하고, 사용자 불만이나 느리고 위험한 SQL 같은 검토 필요 상황을 찾아 사람의 주의를 집중시킨다.

🧾 핵심 주장 / 시사점

• 에이전트 개선에서 사람의 핵심 역할은 모든 출력을 직접 검수하는 것이 아니라, 전문가의 판단을 테스트 데이터셋·자동 평가기·워크플로 검증 규칙으로 바꾸는 데 있다.
• LLM이 SQL이나 도구 호출을 잘 수행하더라도, 업무 표현의 의미와 데이터베이스의 실제 사용 관행 같은 암묵지가 빠지면 실무용 에이전트의 신뢰성은 크게 떨어질 수 있다.
• AI 에이전트는 실행 전 행동을 완전히 예측하기 어렵기 때문에, 실제 사용자 상호작용을 추적하고 그 데이터를 평가·주석·개선으로 되돌리는 반복 루프가 제품 품질의 중심이 된다.

✅ 액션 아이템

• 문서화되지 않은 암묵지 규칙을 정리해 업무 표현의 의미, 권위 테이블, 취약 쿼리 패턴을 컨텍스트에 반영한다.
• 고위험 영역에서 LLM 자율 실행 전 필수 검증 단계를 코드로 강제해 이해관계자가 납득 가능한 평가 조건을 둔다.
• 실제 또는 유사 환경 배포 뒤 추적·평가 데이터를 축적해 자동 평가기와 테스트 데이터셋으로 반복 개선 루프를 운영한다.

❓ 열린 질문

• 어떤 업무 표현의 의미가 SQL 생성에서 오류 판단의 핵심 분기점을 만들 것인가?
• 고위험 작업에서 필수 검증 기준은 어떤 이해관계자의 판단을 기준으로 정의해야 할 것인가?
• 자동 평가기와 Align Evaluator에서 어떤 지표 조합이 개선 성과 판단에 가장 적합한가?