AI 에이전트를 조금만 오래 붙여보면 금방 드러나는 한계가 있다. 첫 대화에서는 똑똑해 보이는데, 세션이 바뀌면 같은 걸 또 물어보고, 지난번에 정리한 규칙도 쉽게 잊는다. 많은 경우 원인은 모델이 멍청해서가 아니라, 메모리를 사실상 대화 로그 저장소로만 다루고 있기 때문이다.초기에는 나도 대화 기록을 길게 넘기면 어느 정도 해결될 줄 알았다. 그런데 실제로 자동화 흐름을 여러 번 붙여보면, 기록을 더 많이 넣는다고 더 잘하는 게 아니었다. 오히려 느려지고, 중요한 규칙을 놓치고, 불필요한 과거 정보에 끌려가는 경우가 더 많았다.그래서 2026년의 에이전트 설계에서는 메모리가 부가 기능이 아니라 아키텍처 레이어로 취급되기 시작했다. 최근 LangChain이 공개한 조사에서도 이미 57%가 에이전트를 프로..
Computer Engineering/AI
AI 에이전트 얘기를 할 때 아직도 많은 팀이 가장 먼저 프롬프트부터 만진다. 물론 프롬프트는 중요하다. 그런데 실제로 서비스나 자동화 워크플로에 에이전트를 붙여서 며칠만 돌려보면 더 먼저 부딪히는 건 다른 문제다.왜 이 응답이 나왔는지 모르겠다어느 툴 호출에서 틀어졌는지 보이지 않는다배포 후 품질이 나빠졌는데 재현이 안 된다중간에 상태를 잘못 건드렸는데 어디까지 되돌려야 할지 모르겠다결국 운영 단계에서 중요한 건 프롬프트 한 줄보다 eval, trace, rollback이다.최근 개인 자동화 흐름과 에이전트 초안을 몇 번 굴려보면서도 비슷한 걸 느꼈다. 답변 문장을 조금 더 다듬는 것보다, 어떤 툴이 어떤 순서로 호출됐는지 남기고 실패 시 어디서 다시 시작할지 정해두는 편이 훨씬 큰 차이를 만들었다.오..
요즘 AI 에이전트 이야기를 하면 거의 빠지지 않고 등장하는 단어가 있다. 바로 MCP(Model Context Protocol) 다. 툴 연결, 외부 시스템 접근, 에이전트 오케스트레이션을 이야기할 때 MCP가 거의 표준처럼 언급된다.이 흐름 자체는 맞다. 실제로 Anthropic은 MCP를 AI 시스템과 외부 데이터 소스를 연결하는 개방형 표준으로 소개했고, OpenAI도 Responses API 문서에서 remote MCP를 에이전트 구성 요소 중 하나로 직접 다루기 시작했다. 이제 AI 애플리케이션이 파일, 문서, DB, 브라우저, 사내 도구와 연결되는 건 선택이 아니라 기본 전제가 되고 있다.그런데 여기서 한 가지 오해가 생긴다.MCP를 붙이면 에이전트가 잘 동작할 거라고 생각하기 쉽다.실제로는..
요즘 AI 에이전트 글을 보다 보면 대부분 자동화 범위를 어디까지 넓힐 수 있는지에 시선이 쏠린다. 툴을 더 붙이고, 여러 단계를 연결하고, 사람 없이 끝까지 실행하는 데 관심이 많다.그런데 실제로 운영 관점에서 더 먼저 부딪히는 질문은 따로 있다.이 에이전트는 어디서 멈춰야 하는가.질문 하나에 답변만 하는 챗봇이라면 큰 문제가 없다. 하지만 에이전트가 주문을 취소하고, 문서를 수정하고, 셸 명령을 실행하고, 외부 시스템에 쓰기 작업을 시작하는 순간부터는 얘기가 달라진다. 이때 중요한 것은 모델이 똑똑하냐보다 통제 경계를 어떻게 설계했느냐다.최근 OpenAI Agents SDK 문서도 이 지점을 꽤 분명하게 다룬다. 가드레일은 자동 검증을 맡고, human review는 민감한 액션 전에 실행을 멈춘다...
