DEVOCEAN

"모든 엔지니어링 업무에 AI 에이전트를 쓰면서, 구현 비용의 감소가 기존 업무의 빠른 완료보다 스스로 맡는 업무량의 확대로 이어졌다."

생산성을 높이려고 도입한 AI 에이전트가 도리어 엔지니어의 작업 시간을 늘리는 현상이 나타나고 있습니다. 개발 도구가 생성해 내는 코드와 작업 항목이 폭발적으로 늘어나면서, 엔지니어는 여러 에이전트가 간헐적으로 던지는 질문, 계획 승인 요청, 코드 검토를 계속해서 처리해야 합니다. 개별 구현에 들어가는 시간은 줄었지만, 사람의 집중력을 흐트러뜨리는 맥락 전환 횟수가 늘어나 전반적인 피로도가 커진 것입니다.

이 문제는 개별 엔지니어의 일상에만 그치지 않습니다. 프롬프트나 프로토타입 단계에서 잘 동작하던 AI 에이전트 시스템을 프로덕션 상용 환경으로 옮길 때도 똑같은 형태의 운영 부담이 발생합니다. 시스템이 다루는 작업의 종류가 많아질수록 프롬프트 관리와 상태 관리가 복잡해지고, 이를 감당하기 위한 인프라 재설계가 요구됩니다.

AI 도입으로 발생한 업무량 인플레이션과 운영 환경의 병목을 해결하기 위해서는 에이전트가 도구와 데이터를 소비하는 구조, 그리고 실행 런타임을 정밀하게 분리해야 합니다.

맥락 전환이 가져온 엔지니어의 작업 병목

AI 에이전트는 작성해야 할 코드의 양을 크게 줄여 주었습니다. 과거에 며칠이 걸리던 스케일링 로직이나 파이프라인 수정을 몇 분 만에 작성하는 일이 가능해졌습니다. AI는 일을 줄여준다고 약속했다. 나는 그 어느 때보다 많이 일하고 있다라는 글에서는 이러한 변화 뒤에 숨은 실무적 병목을 지적합니다. 구현 단가가 내려가자 조직이 엔지니어 한 명에게 요구하는 동시 작업 수가 늘어났고, 결국 사람이 판단해야 하는 검토 지점이 급증했습니다.

에이전트는 작업 중간에 계속해서 사람의 확인을 요구합니다. "이 API 키를 사용해도 되는가?", "이 SQL 쿼리의 인덱스 조건이 적절한가?", "테스트 작성 범위를 어디까지 설정할 것인가?"와 같은 질문이 실시간으로 이어집니다. 한 번에 여러 개의 에이전트 루프를 실행해 두면, 엔지니어는 5분마다 다른 작업의 맥락으로 이동하며 승인 버튼을 누르고 코드를 검토해야 합니다.

해석하자면, 업무의 생산성을 떨어뜨리는 진짜 원인은 '작성 속도'가 아니라 '판단 요청의 밀도'입니다. 에이전트가 완벽하게 독립적으로 동작하지 못하고 사람의 중간 개입을 자주 호출할수록, 엔지니어는 자신이 직접 코드를 작성할 때보다 더 큰 정신적 에너지를 소비하게 됩니다.

이 문제를 완화하기 위해 실무에서는 에이전트의 승인 요청을 정책 기반으로 자동화하거나, 사람이 개입하는 인터럽트 단계를 비동기로 모아서 처리하는 규칙을 도입하고 있습니다.

// agent_approval_policy.ts
// 에이전트의 중간 승인 요청을 위험도에 따라 비동기 큐로 보낼지 즉시 승인할지 결정하는 정책 예시

export interface ActionContext {
  actionType: 'READ_ONLY' | 'SCHEMA_CHANGE' | 'DESTRUCTIVE_DELETE';
  targetTable?: string;
  affectedRowsEstimate: number;
}

export interface DecisionResult {
  requiresHumanReview: boolean;
  autoApproved: boolean;
  reason: string;
}

export function evaluateAgentAction(context: ActionContext): DecisionResult {
  // 읽기 전용 작업은 인적 개입 없이 승인
  if (context.actionType === 'READ_ONLY') {
    return {
      requiresHumanReview: false,
      autoApproved: true,
      reason: '읽기 전용 조회 작업 자동 승인'
    };
  }

  // 영향받는 행 수가 100건 이하인 스키마 변경은 검토 큐로 전송하여 비동기 처리
  if (context.actionType === 'SCHEMA_CHANGE' && context.affectedRowsEstimate <= 100) {
    return {
      requiresHumanReview: true,
      autoApproved: false,
      reason: '소규모 스키마 변경: 비동기 검토 큐 배치'
    };
  }

  // 파괴적 작업이나 대규모 변경은 사람의 즉시 개입 필요
  return {
    requiresHumanReview: true,
    autoApproved: false,
    reason: '고위험 작업: 엔지니어 동기 승인 필요'
  };
}

이처럼 위험도가 낮은 단순 작업이나 조회 작업은 시스템 정책을 통해 자동으로 통과시키고, 검토가 필요한 항목만 모아서 알림을 받는 형태의 설계가 필요합니다. 그렇지 않으면 개발자는 에이전트의 질문 알림에 갇혀 원래 해야 할 아키텍처 판단을 내리지 못하게 됩니다.

AI 검색과 사람이 모두 읽는 콘텐츠 구조화: GEO와 Amazon EKS

데이터와 콘텐츠 영역에서도 비슷한 병목이 존재합니다. 사람이 웹 페이지의 이미지를 보며 상품 정보를 이해하는 방식은 AI 검색 에이전트나 LLM 기반 검색엔진에는 통하지 않습니다. 생성형 AI가 브랜드 정보를 정확하게 인용하게 하려면, 텍스트와 구조화된 데이터 형태로 콘텐츠를 노출해야 합니다.

Search OS의 SEO와 GEO 최적화 솔루션: Amazon EKS와 Amazon CloudFront로 구축한 상품 콘텐츠 구조화 시스템에서는 이커머스 기업이 안고 있는 정보 단절 문제를 풀기 위해 GEO(Generative Engine Optimization) 솔루션을 구축한 사례를 설명합니다. 기존 웹사이트는 상품 설명이나 이벤트 내용이 이미지에 들어가 있어 LLM 기반 에이전트가 해당 정보를 제대로 추출하지 못하는 문제가 있었습니다.

Search OS는 기존 애플리케이션 코드를 크게 수정하지 않도록 Amazon CloudFront 엣지 단과 Amazon EKS 기반의 변환 시스템을 조합했습니다. 요청이 들어오면 엣지에서 렌더링 상태를 확인하고, AI 검색 로봇이나 일반 검색엔진 크롤러가 접근할 때 EKS에 위치한 구조화 엔진이 상품 이미지와 동적 페이지 속 데이터를 JSON-LD나 정돈된 HTML 텍스트로 변환해 응답합니다.

그림 1. Search OS GEO 시스템에서 크롤러 요청이 구조화된 응답으로 바뀌는 경로

# eks-geo-converter-deployment.yaml
# Amazon EKS 상에서 동적 상품 콘텐츠를 JSON-LD 및 텍스트로 구조화하는 파이프라인 Deployment 예시

apiVersion: apps/v1
kind: Deployment
metadata:
  name: geo-content-structurer
  namespace: search-os
  labels:
    app: geo-structurer
spec:
  replicas: 3
  selector:
    matchLabels:
      app: geo-structurer
  template:
    metadata:
      labels:
        app: geo-structurer
    spec:
      containers:
      - name: structurer
        image: searchos/geo-structurer:v1.4.2
        ports:
        - containerPort: 8080
        env:
        - name: RENDER_CACHE_TTL
          value: "3600"
        - name: ENABLE_JSON_LD_INJECTION
          value: "true"
        resources:
          limits:
            cpu: "1000m"
            memory: "1Gi"
          requests:
            cpu: "500m"
            memory: "512Mi"
        readinessProbe:
          httpGet:
            path: /healthz
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 10

이 아키텍처의 핵심은 사람이 보는 웹페이지와 AI 에이전트가 수집하는 정보 형태 사이의 간극을 백엔드 인프라 단에서 메워준다는 점입니다. 검색엔진 최적화(SEO)가 단순한 키워드 매칭과 메타 태그 중심이었다면, GEO는 AI가 답변을 생성할 때 참조할 수 있는 정확한 사실(Fact) 단위를 구조화하여 제공합니다.

해석하자면, GEO 솔루션은 단순히 마케팅 도구가 아니라 AI 에이전트 생태계에 데이터를 공급하는 '인프라 레이어' 역할을 수행합니다. 다만 이 시스템을 도입할 때는 Amazon CloudFront에서의 Caching 정책과 EKS 변환 엔진 간의 정합성을 검증해야 합니다. 동적 페이지가 실시간으로 변할 때 Caching된 구조화 데이터가 신속하게 갱신되지 않으면, AI 에이전트가 과거의 잘못된 가격이나 재고 정보를 학습하여 인용할 위험이 생기기 때문입니다.

LangGraph에서 Amazon Bedrock AgentCore Runtime으로의 프로덕션 이관

에이전트 시스템이 커질 때 부딪히는 또 다른 지점은 '실행 런타임의 안정성'입니다. 초기 PoC 단계나 소규모 프로토타입에서는 LangGraph와 같은 프레임워크를 사용해 로컬 또는 단일 서버 환경에서 상태 머신을 구축하기 쉽습니다. 하지만 이를 실제 고객 서비스 단으로 확장하면 워크플로우 상태 저장, 토큰 관리, 장애 발생 시의 복구 로직이 모두 운영팀의 짐이 됩니다.

기존 LangGraph 워크플로우를 Amazon Bedrock AgentCore Runtime으로: 아이지에이웍스 클레어의 프로덕션 이관과 운영 경험 사례는 이 문제를 극복하는 과정을 보여줍니다. 아이지에이웍스의 CDP & CRM 플랫폼인 디파이너리(DFINERY) 내에 탑재된 AI 분석 에이전트 '클레어(Claire)'는 마케터의 자연어 질문을 Text-to-SQL로 변환하고 실행 결과를 해석하는 역할을 수행합니다.

초기 구현에서는 LangGraph를 기반으로 에이전트의 상태를 추적하고 다음 단계를 결정했습니다. 하지만 상용 환경에서는 다음과 같은 한계에 부딪혔습니다.

• 대량의 동시 요청이 들어올 때 에이전트 상태(State) 추적 및 메모리 관리 부담 증가


• 각 도구 호출 단계의 지연 시간(Latency)과 장애 지점 추적의 어려움


• 커스텀 파이프라인 유지보수로 인한 인프라 관리 비용 상승

아이지에이웍스 팀은 기존 워크플로우를 Amazon Bedrock AgentCore Runtime 환경으로 이관했습니다. 관리형 런타임으로 옮기면서 에이전트의 세션 상태 관리와 도구 실행 오케스트레이션을 AWS 인프라 레이어에 위임할 수 있게 되었습니다.

해석하자면, 프레임워크 수준에서 직접 제어하던 에이전트 상태 루프를 서벌리스/관리형 런타임으로 넘기는 전환은 에이전트 개발의 일반적인 흐름입니다. 애플리케이션 코드로 모든 에이전트 상태 체인을 작성하던 방식에서, 관리형 플랫폼이 제공하는 실행 환경 위로 올리는 구조로 변화하는 것입니다.

이관 과정에서 얻을 수 있는 장점은 명확합니다. 에이전트의 추론 단계와 실제 시스템 도구 호출 사이의 로그가 완전히 분리되어, 쿼리 생성 실패나 실행 오류가 발생했을 때 어느 단계에서 문제가 생겼는지 정밀하게 추적할 수 있습니다. 엔지니어가 에이전트 프레임워크의 상태 버그를 고치는 대신, Text-to-SQL의 정확도를 높이는 프롬프트 평가와 데이터 모델 개선에 집중할 수 있게 됩니다.

AI 에이전트 도입 시 실무에서 고려해야 할 기술 판단

오늘 다룬 소식들은 모두 한 가지 결론을 가리킵니다. AI 도입으로 개별 작업의 생성 속도는 빨라졌으나, 이를 제어하고 운영하는 아키텍처가 받쳐주지 않으면 사람과 시스템에 과부하가 걸린다는 사실입니다. 각 항목별로 실무에서 내릴 수 있는 판단과 근거는 다음과 같습니다.

엔지니어 업무 관리에 대한 판단: 지금 써볼 만합니다.

• 판단 근거: AI 에이전트가 코드를 빠르게 생성할수록 개발자의 검토 알림 피로도는 증가합니다. 모든 요청을 즉시 승인받는 구조를 버리고, 위험도별 승인 정책 및 비동기 큐 배치를 도입하여 엔지니어의 맥락 전환 횟수를 제약해야 합니다.

GEO 콘텐츠 아키텍처에 대한 판단: 조건부로 유효합니다.

• 판단 근거: 이커머스나 콘텐츠 플랫폼에서 AI 에이전트 유입 비율이 증가하고 있다면 도입 가치가 큽니다. 다만 기존 웹사이트의 CDN 캐싱 정책과 EKS 파이프라인 간의 데이터 동기화 주기를 먼저 검증해야 합니다. 동기화가 지연되면 AI가 잘못된 상품 정보를 인용할 위험이 있습니다.

Amazon Bedrock AgentCore 프로덕션 이관에 대한 판단: 지금 써볼 만합니다.

• 판단 근거: LangGraph 등 오픈소스 프레임워크로 구축한 프로토타입이 다중 사용자 환경에서 세션 관리 및 성능 한계에 부딪혔다면, Bedrock AgentCore Runtime과 같은 관리형 런타임으로 넘어가 인프라 운영 부담을 줄이는 것이 타당합니다.

도입 전 확인할 것

AI 에이전트를 실무 및 프로덕션 환경에 적용하기 전에 다음 세 가지 기준을 점검해 보시기 바랍니다.

1. 승인 요청 분리 여부: 에이전트가 생성한 결과물 중 '사람의 즉시 확인이 필요한 작업'과 '자동 통과시킬 작업'의 기준이 정책 코드로 작성되어 있는가?
2. GEO 도입 시 Caching 정합성: CloudFront나 CDN 레벨에서 에이전트용 구조화 데이터(JSON-LD)를 캐싱할 때, 원본 데이터 변경 시 캐시 무효화(Invalidation) 스케줄이 제대로 설계되어 있는가?
3. 런타임 상태 관리 주체: 커스텀 에이전트 서버가 세션 상태와 메모리를 직접 들고 있어 트래픽 증가 시 인프라 확장이 어려운 구조는 아닌가?

이 세 가지 질문에 대한 답을 먼저 준비해 둔다면, AI 도입이 가져오는 생산성 역설과 운영 병목을 줄이면서 안정적인 에이전트 시스템을 구축할 수 있습니다.

그 밖의 소식

• Ghostty 1.4.0 출시: 보이지 않는 스크롤백 메모리를 압축하고 Kitty 그래픽 명세를 지원하는 터미널 에뮬레이터 업데이트입니다.
• Anthropic 상용 제품 데이터 학습 정책: Claude for Work 및 API 입력·출력 데이터는 기본적으로 모델 학습에 활용되지 않는다는 정책 안내입니다.
• Flava MCP Hub 개산기: AI 에이전트와 내부 시스템 간 연동을 표준화하기 위한 MCP 허브 구축 경험을 다룹니다.