Hindsight와 Cascadeflow를 활용한 더 똑똑한 AI 에이전트 구축: AI 장애 대응 어시스턴트 개발 사례를 통한 교훈

인공지능 (Artificial Intelligence)은 대규모 언어 모델 (Large Language Model, LLM)을 애플리케이션에 통합하는 것이 놀라울 정도로 간단해진 지점에 도달했습니다. 단 몇 번의 API 호출만으로 개발자는 질문에 답하고, 문서를 요약하며, 코드를 작성하고, 기술적인 문제를 해결할 수 있는 챗봇을 구축할 수 있습니다.

이것은 인상적이지만, 저는 실제 시나리오에서 잘 작동하는 AI 애플리케이션을 만드는 데는 LLM을 프론트엔드 (frontend)에 연결하는 것보다 훨씬 더 많은 것이 필요하다는 사실을 발견했습니다.

AI 기반 장애 대응 어시스턴트 (Incident Response Assistant)를 개발하는 동안, 저는 모든 프로덕션 AI 시스템이 결국 직면하게 되는 두 가지 주요 과제에 부딪혔습니다.

첫 번째 과제는 메모리 (memory)였습니다.

두 번째는 런타임 효율성 (runtime efficiency)이었습니다.

이러한 과제들은 애플리케이션의 전반적인 아키텍처 (architecture)를 크게 개선해 준 두 가지 기술, 즉 Hindsight와 Cascadeflow를 저에게 소개해주었습니다.

단순히 응답을 개선하는 것을 넘어, 이 기술들은 AI가 행동하는 방식을 바꾸어 놓았습니다. 매 상호작용이 끝날 때마다 모든 것을 잊어버리는 챗봇처럼 행동하는 대신, 시스템은 이전의 장애 사례를 기억하고, 경험으로부터 학습하며, 지능적인 런타임 결정을 내릴 수 있게 되었습니다.

상태 비저장 (Stateless) AI의 문제점

대부분의 대화형 AI 애플리케이션은 상태 비저장 (stateless) 방식입니다.

모든 요청은 독립적으로 처리됩니다.

사용자가 오늘 애플리케이션 오류를 분석해 달라고 요청한 뒤, 내일 매우 유사한 문제로 다시 돌아왔을 때, 해당 컨텍스트 (context)가 수동으로 제공되지 않는 한 모델은 이전 대화에 대한 기억이 전혀 없을 것입니다.

이러한 한계는 엔지니어링 환경에서 특히 두드러집니다.

프로덕션 장애는 종종 반복됩니다. 데이터베이스 타임아웃 (Database timeouts), API 실패 (API failures), 인증 오류 (authentication errors), 설정 실수 (configuration mistakes), 그리고 인프라 문제 (infrastructure issues)는 단 한 번만 발생하는 경우가 드뭅니다.

인간 엔지니어는 자연스럽게 이전 장애를 기억하고 유사한 문제에 이전의 해결책을 적용합니다.

전통적인 AI 시스템은 스스로 이를 수행할 수 없습니다.

모든 응답은 제로(zero) 상태에서 시작됩니다.

그러한 접근 방식은 비효율적입니다.

메모리가 중요한 이유

한 엔지니어가 다음과 같은 로그를 업로드한다고 상상해 보세요:

30초 후 데이터베이스 연결 시간 초과 (Database connection timeout after 30 seconds).

AI는 로그를 분석하고 연결 시간 초과(connection timeout) 설정을 늘릴 것을 권장합니다.

일주일 후, 다른 엔지니어가 다음과 같은 상황에 직면합니다:

PostgreSQL 연결을 설정할 수 없음 (Unable to establish PostgreSQL connection).

표현 방식은 다르지만, 근본적인 문제는 매우 유사할 수 있습니다.

메모리(memory)가 없다면, AI는 처음부터 다시 완전한 분석을 수행해야 합니다.

하지만 지속성 메모리(persistent memory)가 있다면, 시스템은 이와 유사한 사건이 이전에 발생했음을 즉시 인식하고 이전의 해결책을 검색해 옵니다.

처음부터 다시 시작하는 대신, 이전의 경험을 바탕으로 작업을 수행합니다.

이는 일관성(consistency)과 응답 품질(response quality)을 모두 극적으로 향상시킵니다.

Hindsight의 이해

제가 처음에 가졌던 오해 중 하나는 Hindsight가 또 다른 언어 모델(language model)일 것이라고 가정한 것이었습니다.

하지만 그렇지 않습니다.

Hindsight는 언어 모델과 나란히 위치하는 메모리 계층(memory layer)으로서 기능합니다.

응답을 생성하기보다는 다음 세 가지 책임에 집중합니다:

• 중요한 정보 기억하기
• 관련 메모리 검색하기
• AI가 향후 의사결정을 개선하도록 돕기

AI가 장애(incident)를 처리할 때마다, Hindsight는 해당 상호작용에 보존할 가치가 있는 정보가 포함되어 있는지 평가합니다.

모든 문장을 저장하는 대신, 나중에 가치가 있을 수 있는 지식을 기억합니다.

예시는 다음과 같습니다:

• 근본 원인 (Root causes)
• 성공적인 수정 사항 (Successful fixes)
• 인프라 구성 (Infrastructure configurations)
• 이전 장애 요약 (Previous incident summaries)
• 사용자 선호도 (User preferences)
• 해결 이력 (Resolution history)

다른 요청이 들어오면, AI가 응답을 생성하기 전에 Hindsight는 메모리에서 유사한 정보를 검색합니다.

이는 숙련된 엔지니어가 문제를 해결하는 방식과 훨씬 더 유사하게 느껴지는 워크플로(workflow)를 만들어냅니다.

장애 대응 워크플로 설계

이 프로젝트의 주요 목표 중 하나는 엔지니어가 반복되는 운영 환경(production) 문제를 조사하는 데 소비하는 시간을 줄이는 것이었습니다.

워크플로는 놀라울 정도로 직관적이었습니다.

엔지니어가 애플리케이션 로그를 업로드합니다.

시스템은 먼저 Hindsight에서 유사한 장애 사례를 검색합니다.

관련된 메모리 (Memories)가 발견되면, 이는 현재의 에러 로그와 결합됩니다.

그제야 완전한 컨텍스트 (Context)가 언어 모델 (Language Model)로 전송됩니다.

마지막으로, 응답이 생성되면 해당 인시던트 (Incident)를 다시 평가하고, 유용한 지식을 제공한다면 저장합니다.

프로세스는 다음과 같습니다:

엔지니어가 로그 업로드
        │
        ▼
...

워크플로우는 단순해 보이지만, 그 영향력은 상당합니다.

추가적인 인시던트가 처리됨에 따라 AI는 점진적으로 더 많은 지식을 갖추게 됩니다.

비용 문제 (The Cost Challenge)

메모리는 한 가지 문제를 해결했습니다.

하지만 또 다른 과제가 빠르게 드러났습니다.

바로 비용입니다.

대규모 언어 모델 (Large Language Models)은 강력하지만, 모든 요청에 대해 가장 성능이 뛰어난 모델을 실행하는 것은 비용이 많이 듭니다.

모든 작업에 고도의 추론 (Reasoning)이 필요한 것은 아닙니다.

짧은 HTTP 에러 메시지는 수천 줄에 달하는 Kubernetes 스택 트레이스 (Stack Trace)를 분석하는 것만큼의 컴퓨팅 자원을 필요로 하지 않습니다.

두 요청을 모두 동일한 모델로 보내는 것은 비용과 컴퓨팅 자원을 모두 낭비하는 일입니다.

이 지점에서 cascadeflow가 아키텍처의 중요한 부분이 되었습니다.

cascadeflow를 통한 런타임 인텔리전스 (Runtime Intelligence)

애플리케이션 코드 내부에서 언어 모델을 수동으로 선택하는 대신, cascadeflow는 지능형 라우팅 (Intelligent Routing)을 도입합니다.

모든 들어오는 요청은 모델에 도달하기 전에 평가됩니다.

단순한 요청은 더 작고 빠른 모델로 라우팅됩니다.

더 복잡한 작업은 더 깊은 추론이 가능한 더 큰 모델로 자동으로 에스컬레이션 (Escalation)됩니다.

예를 들어:

단순한 타임아웃 에러를 포함하는 짧은 로그는 저렴한 모델을 사용하여 처리할 수 있습니다.

여러 서비스, 컨테이너 및 인프라 로그를 포함하는 긴 운영 환경 인시던트는 더 유능한 모델로 라우팅될 수 있습니다.

이를 통해 애플리케이션은 운영 비용을 절감하면서도 응답 품질을 유지할 수 있습니다.

엔지니어링 관점에서 볼 때, 이러한 지능과 실행의 분리는 시스템을 훨씬 더 확장 가능하게 (Scalable) 만듭니다.

모든 결정에 대한 가시성 (Visibility into Every Decision)

cascadeflow를 사용하면서 제가 높게 평가했던 또 다른 측면은 투명성입니다.

AI 시스템은 종종 블랙박스 (black box)처럼 동작합니다.

개발자들은 답변을 받지만, 그 응답이 어떻게 생성되었는지에 대한 통찰력 (insight)은 거의 갖지 못합니다.

cascadeflow는 다음과 같은 중요한 런타임 (runtime) 정보를 기록하는 감사 추적 (audit trail)을 도입합니다:

• 선택된 모델 (Selected model)
• 응답 지연 시간 (Response latency)
• 예상 비용 (Estimated cost)
• 라우팅 결정 (Routing decisions)
• 런타임 메트릭 (Runtime metrics)

이러한 정보에 접근할 수 있으면 디버깅 (debugging)과 최적화 (optimization)가 훨씬 쉬워집니다.

요청이 왜 느려졌는지 또는 왜 비용이 많이 들었는지 추측하는 대신, 개발자는 라우팅 동작을 직접 조사할 수 있습니다.

프로덕션 (production) AI 시스템을 위해서는 이러한 수준의 관찰 가능성 (observability)이 믿을 수 없을 정도로 가치 있습니다.

메모리와 런타임 지능의 결합

저를 가장 감명 깊게 했던 점은 Hindsight와 cascadeflow가 얼마나 자연스럽게 서로를 보완하는가 하는 점이었습니다.

각 기술은 완전히 다른 문제를 해결합니다.

Hindsight는 과거로부터 배우는 것에 집중합니다.

cascadeflow는 현재 더 나은 결정을 내리는 것에 집중합니다.

이 둘은 결합하여 지능적이면서도 효율적인 아키텍처 (architecture)를 만들어냅니다.

엔지니어가 장애 로그 (incident log)를 업로드하면, 애플리케이션은 구조화된 시퀀스 (sequence)를 따릅니다.

먼저, Hindsight가 유사한 과거의 장애 사례들을 검색합니다.

다음으로, cascadeflow가 요청의 복잡성을 평가하고 가장 적절한 모델을 결정합니다.

선택된 언어 모델 (language model)은 검색된 메모리와 현재의 장애 사례를 모두 사용하여 응답을 생성합니다.

마지막으로, Hindsight는 상호작용 중에 생성된 가치 있는 지식을 저장합니다.

이러한 연속적인 사이클을 통해 AI는 운영 비용을 통제하면서도 시간이 지남에 따라 더욱 유용해질 수 있습니다.

교훈

이 애플리케이션을 개발하면서 AI 엔지니어링에 대한 저의 사고방식이 바뀌었습니다.

처음에 저는 AI 애플리케이션을 구축하는 것이 주로 프롬프트 엔지니어링 (prompt engineering)에 관한 것이라고 믿었습니다.

오늘날 저는 프롬프트 엔지니어링을 단지 하나의 작은 구성 요소로만 봅니다.

프로덕션 수준의 AI 시스템에는 몇 가지 추가적인 역량이 필요합니다.

메모리 (memory)가 필요합니다.

지능적인 모델 선택 (model selection)이 필요합니다.

투명성 (transparency)이 필요합니다.

비용 인식 (cost awareness)이 필요합니다.

이들은 동일한 문제를 반복해서 해결하는 대신, 지속적으로 개선되는 아키텍처 (architectures)가 필요합니다.

조직이 실험적인 AI 프로토타입 (prototypes) 단계를 넘어 엔지니어, 고객 지원 팀, 분석가 및 기업들이 매일 사용하는 시스템으로 나아감에 따라 이러한 개념들은 점점 더 중요해지고 있습니다.

향후 전망

AI 애플리케이션의 미래는 언어 모델 (language models)만으로 정의될 가능성은 낮습니다.

대신, 성공적인 AI 시스템은 추론 (reasoning)을 메모리 (memory), 지능적 실행 (intelligent execution), 그리고 지속적인 학습 (continuous learning)과 결합할 것입니다.

Hindsight와 같은 기술은 AI 에이전트 (AI agents)가 세션 전반에 걸쳐 의미 있는 경험을 유지할 수 있음을 보여주며, cascadeflow는 런타임 최적화 (runtime optimization)가 품질을 희생하지 않으면서도 효율성을 극적으로 향상시킬 수 있음을 보여줍니다.

이들은 함께 단순히 지능적일 뿐만 아니라 실용적이고, 설명 가능하며 (explainable), 프로덕션 준비가 된 (production-ready) AI 시스템을 구축하기 위한 중요한 단계를 나타냅니다.

이 프로젝트를 진행하며 저에게는 중요한 교훈이 강화되었습니다. 가장 효과적인 AI 애플리케이션은 반드시 가장 큰 모델을 사용하는 것이 아니라는 점입니다. 중요한 것을 기억하고, 어떻게 실행할지에 대해 스마트한 결정을 내리며, 모든 상호작용을 통해 지속적으로 개선되는 애플리케이션이 바로 그것입니다.

AI가 계속 진화함에 따라, 이러한 자질들은 현실 세계의 문제를 대규모로 해결하는 신뢰할 수 있는 시스템을 구축하는 데 필수적인 요소가 될 것입니다.