전체 글 97

[LangChain 함수 8] Human-in-the-Loop 구현하기 (Middleware)

Middleware를 활용한 Human in the Loop 구현 Agent가 상황을 해결하기 위해 인간의 개입이 필요한 경우가 종종 있다.이를 Human-in-the-Loop 구조로 처리할 수 있다. 우는 Agent를 정의할 때, 어떤 Tool Calling에 대해 인간의 Feedback을 받고 싶은지 지정할 수 있다.이러한 도구 중 하나가 호출되면, Interrupt가 발생하여 인간의 응답을 요청하게 된다.우리는 승인, 거절, Edit의 허용 등 여러가지 응답을 생성할 수 있다. Example Code우선 Chinook DB에 연결하고 Runtime Context를 정의한다.RuntimeContext와 execute_SQL Tool과 System Prompt도 마찬가지로 정의한다.from la..

[LangChain 함수 7] Agent Customizing하기 (Middleware를 활용한 Dynamic Prompt)

기본적으로 LangChain의 기본 Agent는 많은 문제를 해결할 수 있다.그러나 기본 Agents로 우리의 needs를 충족하지 못한다면, 일부 Customizing이 필요하다.Customizing 방법에는 Middleware, Dynamic Prompt, Human in the loop 등이 있다. Middleware Middleware를 사용하면 ReAct 루프의 주요 지점에 Agent에 특화된 코드를 삽입할 수 있다.LangChain은 2가지 유형의 hook을 제공한다.보라색으로 표시된 Node hook과 흰색으로 Node를 감싸는 Intercepter hook이다.이러한 hook의 일반적인 사용 사례로는 Summarization, Guardrails, Dynamic Prompt, Tool..

Cloud Network가 세계를 하나로 묶는 방법 (Data Center, Region, Backbone)

AWS, Google Cloud, Microsoft Azure와 같은 하이퍼스케일 클라우드 사업자들이 구성하는 Network Topology를 이해하는 것은 Network를 공부하는 데 있어 중요하다. 이들의 네트워크는 단일 데이터센터 수준을 넘어, 물리적 Data Center에서 시작해 전 세계 Region을 연결하는 초대규모 광섬유 Backbone 위에 계층적으로 설계된 구조다. 이는 단순히 서버를 연결하는 네트워크가 아니라, 전 세계 사용자에게 서비스를 전달하기 위해 구축된 하나의 통신 인프라에 가깝다. 이 구조는 크게 Data Center, Region, 그리고 Global Backbone이라는 세 단계로 나누어 이해할 수 있다. Data Center 먼저 Data Center는 가장 기본 ..

Context Isolation 관점에서 본 Multi-Agent 구조의 한계와 Sub Agent Delegation

Multi Agent 구조의 취약점멀티 에이전트 구조는 복잡한 문제를 병렬로 처리할 수 있다는 점에서 분명한 이점을 가진다.그러나 실제로 장시간 실행되며 높은 신뢰성이 요구되는 에이전트 시스템에서는, 오히려 가장 취약한 선택이 되는 경우가 많다.이 취약점의 원인은 성능이나 병렬성 자체가 아니라, Context와 의사결정의 일관성 붕괴에 있다. 에이전트의 신뢰성 이슈장시간 실행되는 에이전트의 가장 중요한 요구사항은 신뢰성이다.단 한 번의 정답보다, 긴 시간 동안 일관된 판단을 유지하는 것이 더 중요하다. 이 신뢰성의 핵심에는 Context Engineering이 있다.에이전트는 매 순간 Context를 기반으로 행동을 선택한다.Context에는 단순한 입력뿐 아니라, 지금까지 내려진 결정, 사용한 도구,..

Context를 효과적으로 설계해야 하는 이유 (Context Offloading)

점점 길어지는 Context와 나타나는 한계들대규모 언어 모델의 Context Window는 빠르게 확장되고 있다.수십만 토큰은 이제 기본이고, 최근에는 수백만에서 Llama 4 Scout처럼 수천만 토큰 컨텍스트를 지원하는 모델까지 등장했다.그러나 “컨텍스트만 충분히 길면 에이전트는 자연스럽게 똑똑해질 것”이라는 기대와 달리 그러나 실제 에이전트 시스템에서 긴 컨텍스트는 기대만큼 잘 작동하지 않는다.오히려 컨텍스트가 길어질수록 새로운 실패 양상이 구조적으로 발생한다. 긴 Cointext가 대표적으로 실패하는 방식은 아래와 같이 4가지로 정리된다. (https://www.dbreunig.com/2025/06/26/how-to-fix-your-context.html) 컨텍스트 오염(Context Pois..

Context Management의 중요성 (긴 Context는 반드시 실패한다)

긴 Context는 실패한다 최첨단 LLM의 Context Window는 빠르게 확장되고 있다.최근 모델들은 최대 100만, 심지어 1000만 토큰까지 처리할 수 있다.이로 인해 “이제는 Context만 충분히 길다면 우리가 꿈꾸던 에이전트를 만들 수 있다”는 기대가 자연스럽게 따라붙는다.충분히 긴 컨텍스트 창만 있다면, 도구 설명, 문서, 지시사항, 히스토리까지 전부 프롬프트에 넣고 모델이 알아서 판단하게 하면 된다는 생각이다. 검색도 필요 없고, 선택도 필요 없으며, 그저 모든 것을 넣으면 된다는 접근이다.하지만 이 기대는 여러 한계에 부딪힌다. Context Window가 커진다는 것의 의미 LLM에서 Context Window는 모델이 한 번에 처리할 수 있는 최대 토큰 수를 의미한다.이것이 ..

AI Agent Architecture에서 Planning이 중요해진 이유

AI Agent 아키텍처의 Planning 구조 최근 등장한 거의 모든 고급 에이전트 시스템을 관통하는 공통 키워드는 Planning이다.Manus는 컨텍스트 엔지니어링의 핵심으로 Todo list를 활용한 Planning을 흡수했고, Claude는 Plan Mode와 Research 시스템을 통해 계획과 실행을 분리했다. Gemini Deep Research는 Research 전용 Planning 파이프라인을 공식 기능으로 도입했고, Open Deep Research와 Perplexity는 Plan-and-Execute를 서비스 수준에서 채택했다. Planning은 “더 똑똑해지기 위해”가 아니라, “서비스 가능한 에이전트를 만들기 위해” 필연적으로 등장한 구조다.이 글에서는 AI Agent에서 P..

작업의 길이 관점에서 본 AI Agent (METR Evaluation)

AI Agent 연구의 핵심 트렌드최근 AI Agent 연구의 흐름은 크게 두 가지 방향으로 수렴하고 있다.첫째는 다양한 작업을 하나의 에이전트가 수행할 수 있는 범용 에이전트의 등장이다.둘째는 단일 질의에 응답하는 수준을 넘어, 더 긴 시간 동안 상태를 유지하며 지속적으로 작동하는 에이전트로의 진화다.이번에는 두 번째 트렌드에 대한 흥미로운 평가 지표에 대해 설명하고자 한다. 현재 최전선 AI 모델들은 텍스트 예측과 지식 기반 과업에서 이미 인간을 크게 능가하고 있다.특히 의사, 변호사 시험과 같은 전문가 수준의 시험형 문제 대부분에서 훨씬 적은 비용으로 인간보다 나은 성과를 낸다.이러한 점은 AI Agent가 다양한 응용 분야에서 매우 유용한 도구로 활용될 수 있음을 보여준다. 그러나 이와 동시에..

Anthropic Research로 살펴보는 General-Purpose Agent로의 진화

AI Agent 연구의 핵심 트렌드최근 AI Agent 연구의 흐름은 크게 두 가지 방향으로 수렴하고 있다.첫째는 다양한 작업을 하나의 에이전트가 수행할 수 있는 General Agent의 등장이다.둘째는 단일 질의에 응답하는 수준을 넘어, 더 긴 시간 동안 상태를 유지하며 지속적으로 작동하는 에이전트로의 진화다.이 글에서는 이 중 General Purpose Agent의 관점에서 최근 공개된 대표적인 사례와 그로부터 도출되는 설계 원칙을 정리한다.특히 Anthropic의 Research 기능 구축 과정에서 공유된 교훈은, 현재 AI Agent 연구가 어디로 향하고 있는지를 잘 보여준다. 최근 AI 에이전트 시장에서는 Anthropic의 Claude Code가 단순한 개발 도구를 넘어 General ..

[Git 기초 2] Directory의 변경 이력 확인하기 (git diff, Git Graph)

디렉토리의 변경 이력 확인하기 - git diff요즘에는 터미널에서 직접 git add와 git commit 명령어를 입력하는 방식이 반드시 필요한 것은 아니다.대부분의 최신 코드 에디터에는 Git 기능이 기본적으로 내장되어 있어,GUI를 통해 훨씬 편리하게 버전 관리를 수행할 수 있기 때문이다. 대표적으로 Visual Studio Code에서는 왼쪽 사이드바의 Git 탭을 통해 변경 사항을 한눈에 확인할 수 있다.파일을 수정하고 저장하면 해당 파일 옆에 M 표시가 나타나며, 이는 파일이 수정되었음을 의미한다. 이 상태에서 + 버튼을 누르면 해당 파일을 Staging Area에 올리는 것으로, 이는 git add와 동일한 동작이다.반대로 - 버튼을 누르면 staging을 취소할 수 있다.즉, 터미널 명..