작년부터 Agentic AI가 시장에서 급부상하며 온갖 기술 논의의 중심에 서있습니다. AI 도메인에 종사하지 않는 사람이라도 MCP, Agent라는 말을 많이 들어보셨을 겁니다. 이 글은 지난 1년 반 동안 AI 도메인 최전선에서 개발했던 경험을 다룹니다.
제가 만들던 앱은 순도 99% LLM으로 만들었습니다. 따라서 LLM 기술 영역에서 나오는 모든 트렌드를 레버리지 할 필요가 있었습니다. LLM 앱의 핵심은 품질이고, 품질 개선을 위해선 어떤 노력도 마다하지 않았어야 했으니까요. 따라서 Multi Agent, MCP, Agentic Loop 등 각 개념이 소개될때마다 그 즉시 제품에 녹였습니다. 최전선 기술을 다루다 보니 전통 소프트웨어 엔지니어링 기초 이해가 더 중요해진다는 생각이 들었습니다.
첫번째 예시는 MCP 입니다. MCP는 서로 다른 LLM 앱 간 통일된 규격을 제공했다는 의의를 갖습니다. 제공자가 MCP 규격에 맞는 API를 열어두면, 편리하게 기성 LLM 앱과 연결될 수 있는 이점을 갖습니다. 편리한 통합 경험 덕분에 많은 기업과 제품이 MCP를 지원한다고 앞다투어 발표하고 있습니다. 그렇다면 엔지니어 관점에서 MCP의 리스크는 어떤 게 있을까요?
MCP 서버는 본질적으로 마이크로서비스 서버입니다. 따라서 MCP는 마이크로서비스의 리스크를 그대로 가져갑니다. 단일 서버에서 관리한다면 겪지 않을 네트워크 오류가 발생합니다. 프로덕션 레벨에서는 Retry, Partial output 등 오류 정책을 갖출 필요가 있습니다. 프로덕션 MCP 사이에 LB 등 다른 레이어가 껴있다면 디버깅 복잡도는 더 올라갈 수 있습니다. OpenTelemetry 같은 분산 환경 관측성 도구도 갖추고 있어야겠죠.
MCP 만의 특성은 아니지만 LLM 서버는 때로 스트림 처리를 요구합니다. LLM의 마지막 토큰까지 사용자를 기다리게 할 수 없기 때문에 첫 토큰을 기준으로 응답을 내려줘야 합니다. 이때는 스트림 서버의 관리 문제를 다루게 됩니다. 여러 디바이스에서 접근했을때 어떻게 보여줄지, 스트림 중에 다른 스트림이 끼어들면 어떻게 해야할지, 클라이언트 상황으로 네트워크가 끊어졌을땐 어떻게 재개해야하는지 고민해야합니다.
두번째 예시는 Agentic loop 입니다. ChatGPT나 Claude 앱의 Reasoning 과정을 보면 "생각중.."이라는 말과 함께 백그라운드에서 처리 중인 작업에 대한 상황을 단계 별로 보여줍니다. 이는 기성 소프트웨어 엔지니어링의 Long-running task 를 다루는 문제입니다. 생각해볼수 있는 요구사항은 사용자 화면에 Long-running task의 상태를 실시간으로 노출해야 하는 문제가 있겠지요. "웹 검색 중", "생각 중" 등 여러 구체화 된 상태값이 사용자의 체류 시간 증가를 위해 필요합니다.
이 과정에서 서버 고장으로 인해 Agentic loop가 강제 종료될 수도 있습니다. 그럴 땐 사용자에게 어떻게 노출해야 할까요? 재시도 버튼 제공? 서버 자동 재시도? 정답은 없지만 엔지니어 입장에서 제품 팀과 논의하며 풀어나갈 문제입니다.
LLM은 비결정적이기 때문에 Agentic loop를 언제 끝낼 지도 고민해야 합니다. 그런데 loop가 끝나는 기준은 뭘까요? 사용자의 작업 완료? 그렇다면 작업 완료의 기준은 어떻게 정의할 수 있을까요? 또는, LLM이 100번을 반복해도 작업을 못 끝냈다고 판단할 수 있지 않을까요? 매직 넘버를 포함한 휴리스틱이 필요한 시점입니다. 정확히 어떻게 끝낼지는 서비스 특성에 따라 갈리겠지요.
Agentic AI는 새로운 패러다임이지만, 그 아래엔 검증된 소프트웨어 엔지니어링 원칙이 여전히 유효합니다. 최신 기술을 다루는 것만큼, 기본기에 충실한 것이 중요합니다.
작성일: October 23, 2025
October 23, 2025 기준 구직 중 입니다. 아래는 제 블로그와 레쥬메 입니다. 대용량 트래픽을 받는 서비스 또는 성장하기 시작한 소수 정예 팀에 관심이 있습니다.