AI 에이전트가 전부 비동기로 가고 있다 - 왜 지금 흐름이 바뀌는가

에이전트가 갑자기 '기다림'에 익숙해지고 있어요

요즘 AI 에이전트 관련해서 재미있는 변화가 일어나고 있어요. 지금까지 우리가 써왔던 챗봇이나 코파일럿 같은 도구들은 대부분 '동기(synchronous)' 방식이었거든요. 이게 뭐냐면, 사용자가 질문을 던지면 화면 앞에 앉아서 답이 나올 때까지 기다리는 구조예요. ChatGPT에 뭔가 물어보면 커서가 깜빡이면서 한 줄씩 답이 나오는 거 떠올려보시면 돼요. 사람이 타자 치듯 바로바로 반응이 와야 했던 거죠.

그런데 최근 분위기가 확 바뀌고 있어요. Claude Code, Cursor의 백그라운드 에이전트, OpenAI의 Codex, Devin 같은 도구들이 등장하면서, 에이전트는 이제 '몇 초 안에 답하는 비서'가 아니라 '몇 시간 동안 혼자 일하고 결과물을 던져주는 동료'로 변하고 있거든요. 이걸 비동기(async) 에이전트라고 부르는데, 왜 이런 흐름이 생겼고 뭐가 달라지는지 하나하나 풀어볼게요.

동기 에이전트의 한계가 명확해졌어요

동기 방식의 근본적인 문제는 '사람이 계속 붙어 있어야 한다'는 거예요. 채팅창 앞에서 답을 기다리고, 읽고, 다시 질문을 던지는 루프를 반복해야 해요. 에이전트가 뭔가 10분짜리 작업을 하겠다고 하면 그 10분 동안 우리는 그냥 모니터를 쳐다보고 있어야 하거든요. 이게 사람의 주의력 예산을 엄청나게 소모해요.

게다가 에이전트 자체도 성능 한계가 있어요. 응답이 빨라야 하니까 모델이 충분히 '생각할' 시간을 못 가지고, 도구를 여러 번 호출하면서 검증하는 것도 어려워요. 한마디로 사용자의 인내심이 에이전트의 성능 상한선이 되는 거예요. 사람은 보통 30초만 기다려도 답답해하니까, 모델도 30초 안에 뭔가 만들어내야 했던 거죠.

비동기로 가면 뭐가 달라지냐면요

비동기 에이전트는 완전히 다른 UX를 가져요. 작업을 '던져놓고 다른 일 하다가 나중에 결과를 받는' 구조예요. 깃허브에서 PR 리뷰 요청 던져놓고 다른 일 하다가, 리뷰가 달리면 알림받고 돌아와서 확인하는 거랑 똑같은 패턴이에요. 이렇게 되면 한 사람이 동시에 여러 에이전트에게 일을 시킬 수 있게 돼요. 3개의 에이전트가 각각 다른 기능을 구현하는 동안 나는 또 다른 일을 할 수 있는 거죠.

기술적으로 보면 몇 가지 중요한 변화가 따라와요. 먼저 상태 관리가 핵심이 돼요. 에이전트가 1시간 동안 일하는 중간에 시스템이 죽을 수도 있으니까, 작업 중간 상태를 저장하고 복원하는 메커니즘이 필요해요. 이게 바로 durable execution, 즉 '견고한 실행'이라는 개념인데, Temporal이나 Inngest 같은 워크플로 엔진들이 이미 이런 패턴을 구현해두고 있었거든요. 에이전트 시스템이 점점 이런 전통적인 백엔드 인프라 위에서 돌아가는 모양새가 되고 있어요.

두 번째로 알림과 컨텍스트 전환이 중요해져요. 에이전트가 일을 마쳤다는 걸 사용자한테 알려줘야 하고, 사용자는 돌아왔을 때 '얘가 지금까지 뭘 했지?'를 빠르게 파악해야 해요. 그래서 요즘 도구들이 작업 요약, diff 뷰, 체크포인트 같은 UI 요소에 집중하고 있어요. 세 번째로는 승인 워크플로가 생겨요. 에이전트가 파일을 수정하거나 API를 호출하기 전에 사람의 확인을 받아야 하는 지점들이 있거든요. 이걸 비동기로 처리하려면 에이전트가 대기 상태로 들어갔다가 사용자 응답을 받고 다시 실행되는 구조가 필요해요.

비슷한 흐름이 업계 전반에서 보여요

재미있는 건 이게 단순히 한두 회사의 실험이 아니라는 점이에요. Cognition의 Devin은 처음부터 '자율적으로 장시간 일하는 소프트웨어 엔지니어'를 표방했고, Anthropic의 Claude Code는 터미널에서 긴 작업을 자율 실행하는 방향으로 발전했어요. GitHub Copilot도 이제 단순 자동완성을 넘어 Copilot Workspace 같은 PR 단위 작업 에이전트를 내놓고 있고요. OpenAI의 Codex 재출시도 같은 맥락이에요.

이 흐름을 보면 웹 개발 역사가 떠올라요. 초기 웹은 페이지 리로드 기반의 완전 동기식이었는데, AJAX가 나오면서 비동기 요청이 일반화됐고, 지금은 WebSocket이나 Server-Sent Events로 양방향 실시간 통신이 기본이 됐잖아요. 에이전트도 비슷한 경로를 밟고 있어요. 채팅창 한 줄 답변에서 → 스트리밍 응답 → 백그라운드 장기 작업 → 결국 이벤트 기반 다중 에이전트 협업으로 진화하는 중이에요.

한국 개발자 입장에서 생각해볼 점

실무 관점에서 이 변화가 시사하는 바가 꽤 커요. 첫째, 사내에서 자체 에이전트 도구를 만들고 있다면 아키텍처를 처음부터 비동기 중심으로 설계하는 게 좋아요. 요청-응답 HTTP API 기반으로 짜면 나중에 장시간 작업을 지원하려고 할 때 대대적으로 갈아엎어야 하거든요. 처음부터 큐, 워커, 상태 저장소 구조로 가는 게 훨씬 편해요.

둘째, 이미 사내에 Temporal, Airflow, 카프카 같은 비동기 인프라를 잘 아는 팀이 있다면 에이전트 시스템 구축에서 엄청난 이점을 가져요. LLM 호출만 붙이면 되는 수준이거든요. 반대로 에이전트를 처음 다루는 팀이라면 LangGraph, CrewAI 같은 프레임워크보다 먼저 워크플로 엔진의 기본 개념을 익히는 게 도움이 될 수 있어요.

셋째, 개인 생산성 관점에서도 쓰는 방식을 바꿔볼 만해요. Claude Code나 Cursor의 백그라운드 에이전트를 '대기하면서 쓰는 도구'가 아니라 '여러 개 동시에 돌려놓고 결과물 리뷰하는 도구'로 접근하면 훨씬 많은 일을 할 수 있어요. 마치 주니어 개발자 3명에게 동시에 과제를 주고 리뷰어 역할을 하는 시니어처럼요.

마무리

한 줄로 요약하면, 에이전트의 인터페이스가 '채팅'에서 '작업 큐'로 이동하고 있고, 이건 AI 도구가 진짜로 일을 해내는 방향으로 진화하는 자연스러운 과정이에요. 여러분은 비동기 에이전트를 이미 써보셨나요? 동시에 여러 개를 돌려봤을 때 생산성이 진짜 올라가던가요, 아니면 관리 비용이 더 커지던가요?