Lomo Agent: 창작형·지속 협업 Agent의 아키텍처 설계와 엔지니어링 실천

제품 숏폼 영상 하나를 만들려면 보통 요구사항 협의, 참고 소재 정리, 스토리보드, 이미지 생성, 영상 생성, 그리고 끝없는 수정 과정을 거칩니다. 그중에는 몇 초 만에 끝나는 일도 있고 몇 분씩 기다려야 하는 일도 있습니다. 모델에게 맡겨도 되는 결정이 있는가 하면, 반드시 사용자가 확인해야 하는 결정도 있습니다. 첫 번째 버전을 만들었다고 해서 일이 끝나는 것도 아닙니다.

AI 시대가 온 뒤로 기술 글은 거의 쓰지 않았습니다. 그 시간은 대부분 여러 실제 활용 사례에서 AI를 탐색하는 데 썼습니다.

많은 사람이 AI 시대의 가장 큰 수혜자는 프로덕트 매니저(PM)라고 말합니다. 아이디어와 실행 사이의 거리가 크게 줄었기 때문입니다. 하지만 제가 보기에 AI가 엔지니어에게 주는 힘은 그보다 더 깊을지도 모릅니다. AI는 기술 구현이 창의성을 옭아매던 족쇄를 조금씩 풀어 주고 있고, 엔지니어가 코드와 엔지니어링 디테일에서 한 발 물러나 제품과 아키텍처, 나아가 인간과 기계의 상호작용이 무엇인지 다시 바라볼 기회를 주고 있습니다.

예전에는 기계가 명령을 정확히 수행하게 만드는 방법을 고민하는 데 많은 시간을 썼습니다. 이제는 더 흥미로운 질문에 힘을 쏟을 수 있게 되었습니다. 바로 어떻게 하면 기계가 사람의 의도를 제대로 이해하고, 더 자연스러운 방식으로 사람과 협업하게 만들 수 있을까 하는 질문입니다.

최근 Lomote AI에 Lomo Agent를 출시했습니다. 이 기회를 빌려 구상부터 구현까지 거치며 했던 고민과 아키텍처 설계, 엔지니어링 실천을 이야기해 보려 합니다.

이 글에서는 작업 구성, 메시지 라우팅, 내구성 실행, 비동기 작업, 컨텍스트 엔지니어링, 장기 기억, 자율 진행, 공유 창작 워크스페이스를 다룹니다. 이미 구현된 설계도 있고, 아직 탐색과 검증 중인 설계도 있습니다. DeepSeek, Manus, Claude Code 같은 훌륭한 제품과 기술 사례도 함께 살펴보면서, 여러 방안 사이에서 제가 어떻게 고민하고 선택했는지 공유하겠습니다.

Lomote AI와 Lomo Agent

Lomote AI는 저희가 만든 올인원 AI 창작 플랫폼입니다. 재미있게도 이 프로젝트에서 저는 주로 프로덕트 매니저(PM) 역할을 맡으면서 하부 인프라 아키텍처의 설계와 구축에도 참여했습니다. 덕분에 제품과 기술이라는 두 관점에서 AI 창작 도구가 어떤 형태와 경험을 갖춰야 하는지 다시 생각해 볼 수 있었습니다.

현재 Lomote AI는 다양한 이미지, 영상, 3D 생성·향상 모델을 통합하고 있으며, 에셋 라이브러리, 무드보드, Flows 비주얼 워크플로 같은 기능을 제공합니다. 크리에이터가 하나의 작업 공간에서 소재를 관리하고, 모델을 조합하고, 창작 흐름을 구성할 수 있게 해서, AI 창작이 흩어진 모델 호출에서 완결되고 일관된 창작 경험으로 나아가기를 바랐습니다.

이런 기능들로 AI 창작 도구가 흩어져 있는 문제는 상당 부분 해결했습니다. 하지만 사용이 깊어질수록 도구를 한데 모으는 것은 첫걸음일 뿐이고, 그 도구들이 실제로 맞물려 돌아가며 사용자의 생산성을 해방하게 만드는 것이 더 탐구할 가치가 있는 문제라는 사실을 깨달았습니다.

기존 AI 창작 흐름에서는 여전히 사용자가 직접 단계를 계획하고, 모델을 고르고, 소재를 정리하고, 여러 작업 사이에서 컨텍스트와 중간 산출물을 반복해서 옮겨야 합니다. 창작 흐름이 복잡해지면 각 단계를 조율하는 데만 많은 에너지가 들어갑니다.

Lomo Agent는 바로 이런 배경에서 탄생했습니다. 저는 AI가 단순한 창작 도구를 넘어 의도를 이해하고, 작업을 계획하고, 지속적으로 협업하는 에이전트가 되기를 바랐습니다. 사용자는 목표만 설명하면 됩니다. Agent가 플랫폼의 모델과 도구를 호출해 창작 흐름을 구성하고, 실행 중에도 사용자 피드백에 맞춰 계속 조정합니다.

이런 경험을 구현하려면 기존의 단일 턴 도구 호출로는 분명히 부족합니다. 작업을 어떻게 구성할지, 컨텍스트를 어떻게 관리할지, 비동기 실행을 어떻게 조율할지, 그리고 사용자가 자리를 비운 뒤에도 Agent가 어떻게 일을 계속 진행할지가 모두 저희가 풀어야 할 아키텍처 문제가 되었습니다.

클릭하여 확대

클릭하여 확대

수정을 거듭하는 창작 작업 하나에서 시작해 봅시다

사용자가 월요일에 이렇게 말했다고 가정해 보겠습니다. “레트로 스타일 브랜드 포스터 세트를 만들어 줘.” Agent는 요구사항을 정리하고 참고 이미지를 생성하기 시작합니다. 그 사이 사용자가 다른 작업을 끼워 넣습니다. “그리고 어제 만든 고양이 이미지를 5초짜리 영상으로 만들어 줘.” 수요일이 되자 사용자가 다시 말합니다. “지난번 그 포스터, 좀 더 따뜻한 느낌으로 하고 글자 위치도 조정해 줘.”

사람끼리 협업할 때는 너무나 평범한 일이지만, Agent에게는 그 뒤에 여러 작업의 병렬 관리, 비동기 생성, 컨텍스트 연결, 과거 소재 검색이 얽혀 있습니다. 작업이 진행될수록 취소, 재시도, 예산 통제, 사용자 선호의 변화, 멀티 디바이스 협업 같은 문제도 따라옵니다.

한 달쯤 전부터 저는 이런 질문을 붙들고 있었습니다. Agent는 왜 꼭 세션(Session)을 중심으로 돌아가야 할까?

지금 대부분의 Agent 제품은 여전히 Chatbot의 상호작용 패러다임을 따르고 있어서, 사용자가 직접 세션을 만들고 찾고 관리해야 합니다. 헤비 유저일수록 세션은 계속 쌓이고, 원래 AI가 맡아야 할 컨텍스트 관리가 오히려 사용자의 부담이 됩니다.

하지만 현실에서 사람들은 ‘세션’이라는 것을 의식적으로 관리하지 않습니다. 언제든 화제를 바꿀 수 있고, 며칠이 지나도 자연스럽게 이전 이야기를 이어 갈 수 있습니다. 이상적인 에이전트라면 이런 능력도 갖춰야 하지 않을까요?

그래서 Lomo Agent에서는 사용자 쪽의 세션 개념을 약화하고, 작업 식별, 컨텍스트 격리, 이력 연결을 시스템이 처리하도록 시도했습니다. 물론 이는 전체 아키텍처 설계의 한 부분일 뿐입니다. 지속적인 창작을 제대로 뒷받침하려면 실행 복구, 비동기 스케줄링, 장기 기억, 예산 권한 부여, 공유 산출물 관리 같은 엔지니어링 문제도 함께 풀어야 합니다.

데모를 만들던 중에 마침 DeepSeek 팀이 구상한 Super-agent 아키텍처를 읽게 되었습니다. 흥미롭게도 작업 구성과 컨텍스트 관리에서 비슷한 문제에 부딪히고 있었습니다. DeepSeek 팀의 글 「Super-agent 설계 탐색: 더 자율적인 Agent 시스템을 향하여」에서 제시한 Router / Worker의 역할 분담과 이후의 메시지 라우팅 설계는 많은 영감을 주었고, Lomo Agent의 전체 아키텍처를 다듬는 데도 도움이 되었습니다.

이제 실제 설계와 구현을 바탕으로, 몇 가지 문제에서 제가 어떻게 고민하고 선택했는지 이야기해 보겠습니다.

1. 작업 구성: 사용자 요청에서 지속적으로 진행할 수 있는 작업으로

앞의 예로 돌아가 보면, 사용자는 몇 분 사이에 여러 화제를 오갈 수도 있고, 며칠이 지나서야 어떤 작업을 다시 꺼낼 수도 있습니다. Agent에게 메시지를 받는 것은 시작일 뿐입니다. 더 중요한 것은 그 메시지가 어떤 목표에 속하는지 이해하고, 이전의 실행 진행 상황과 관련 소재를 어떻게 찾아내느냐입니다.

여기서 아키텍처상의 트레이드오프가 생깁니다. 모든 작업이 하나의 컨텍스트를 공유하면 서로 다른 목표의 정보가 간섭하기 쉽고 모델의 컨텍스트 윈도도 빠르게 불어납니다. 반대로 세션 단위로 완전히 격리하면 작업 간의 이력 연결이 끊어집니다.

그래서 Lomo Agent에서는 상호작용 진입점, 실행 컨텍스트, 장기 기억을 비교적 독립적인 세 개의 계층으로 나눴습니다.

사용자는 하나의 진입점에서 자연스럽게 의도를 표현하기만 하면 됩니다. 시스템이 작업의 귀속을 식별하고, 계속 진행해야 하는 일에는 독립된 작업을 만듭니다. 각 작업은 자체 컨텍스트, 실행 상태, 산출물 참조를 가지며, 필요하면 통제된 검색·공유 메커니즘을 통해 다른 작업의 정보를 가져올 수 있습니다.

이 설계에서는 기존 제품들의 여러 사례도 참고했습니다.

예를 들어 ChatGPT는 세션 간 기억으로 대화 사이의 정보 연속성을 높였고, Claude는 Projects 같은 메커니즘으로 사용자가 특정 프로젝트를 중심으로 지식과 컨텍스트를 구성할 수 있게 했습니다. 각각 장점이 있습니다. 명시적인 세션과 프로젝트 경계는 이해하고 관리하고 공유하기 쉬우며, 컨텍스트 범위를 사용자가 더 직접적으로 통제할 수 있게 해 줍니다.

하지만 장기간, 자주 작업을 오가야 하는 창작 시나리오에서는 사용자가 여전히 컨텍스트 정리의 일부를 떠안게 됩니다. 세션 간 기억은 Agent가 사용자의 선호와 이력을 파악하는 데는 도움이 되지만, 지금 실행 중인 작업과 그 진행 상황을 온전히 표현하지는 못합니다.

그래서 Lomo Agent는 작업 구성의 더 많은 부분을 시스템에 맡겨, 사용자가 일상적인 세션 관리에서 최대한 벗어나도록 했습니다. 물론 자동 식별에는 작업 귀속이 잘못될 위험도 따릅니다. 이를 위해 명시적인 작업 진입점과 오류 수정 메커니즘을 남겨 두었고, 목표가 분명할 때는 결정적 라우팅을 우선 적용해 불필요한 모델 판단을 줄였습니다.

flowchart TD
    U["사용자"] --> E["통합 상호작용 진입점"]
    E --> R["작업 식별과 라우팅"]
    R --> A["작업 A: 브랜드 포스터"]
    R --> B["작업 B: 영상 제작"]
    R --> C["간단한 요청: 메인 스레드에서 직접 처리"]
    A <--> M["장기 기억"]
    B <--> M
    C <--> M
    A --> S["공유 소재와 산출물"]
    B --> S

그림 1: Lomo Agent의 작업 구성 모델

2. 시스템 개요: 조율 계층, 실행 계층, 공유 워크스페이스

작업 구성 방식을 정했으니, 다음은 이 작업들을 실제로 굴러가게 만드는 방법입니다.

지속적으로 협업하는 Agent는 사용자의 새 요청을 처리하고, 기존 작업을 진행하고, 외부 생성 결과를 기다리고, 작품에 대한 사용자의 수정 요청에 응답하는 일을 동시에 해내야 합니다. 이 모든 일을 하나의 Agent에게 맡기면 컨텍스트가 빠르게 불어나고 작업끼리 간섭하기 쉽습니다. 반대로 요청마다 독립된 Agent를 만들면 조율 비용이 추가로 생깁니다.

이런 점을 고려해 Lomo Agent에 Main / Task 2계층 구조를 설계하고, 실행 계층에는 내구성 런타임을 도입했습니다. 서로 다른 작업이 독립적으로 진행되면서도 공유 워크스페이스를 통해 창작 산출물에 접근하고 수정할 수 있게 하기 위해서입니다.

2.1 전체 아키텍처

시스템은 크게 네 부분으로 나눌 수 있습니다.

• Main(메인 스레드): 사용자가 계속 상호작용하는 진입점입니다. 새 요청을 이해하고, 기존 작업과 연결하고, 간단한 질문을 처리하며, 여러 작업의 실행과 피드백을 조율합니다.

• Task(작업): 구체적인 창작 목표를 담는 독립 실행 공간입니다. 작업마다 자체 브리프, 컨텍스트, 실행 계획, 메시지 수신함, 실행 상태를 유지합니다.

• Agent Runtime(런타임): 모델 추론, 도구 호출, 비동기 대기, 상태 영속화, 실행 복구를 관리하고, 매 단계마다 예산, 권한, 중지 조건을 확인합니다.

• Shared Workspace(공유 워크스페이스): 이미지, 영상, 3D, 문서, 소재 세트, Flows 워크플로 같은 창작 산출물을 저장하며, 사용자와 여러 작업이 권한 범위 안에서 함께 접근하고 수정할 수 있게 합니다.

역할 분담으로 보면 Main은 주로 Router의 책임을 맡고, Task 내부에서는 Worker가 구체적인 작업을 진행합니다. Router와 Worker는 논리적인 실행 역할일 뿐, 서로 다른 기반 모델을 써야 하는 것은 아닙니다.

flowchart TB
    U["사용자: 자연어 / 카드 조작 / 워크스페이스 편집"] --> UI["통합 협업 인터페이스"]
    UI --> GW["접속 계층: 내부 API / 오픈 API / 실시간 이벤트"]
    GW --> CMD["명령과 메시지 수신"]

    subgraph CORE["Agent Core"]
      ROUTER["Main / Router: 이해와 조율"]
      ROUTING["목표 귀속과 결정적 라우팅"]
      W1["Task A / Worker: 포스터 시리즈"]
      W2["Task B / Worker: 숏폼 영상"]
      CTX["컨텍스트 구성 / 압축 / 온디맨드 도구"]
      RT["내구성 실행 엔진"]
      GUARD["권한 부여 / 예산 / 자율 수준"]
    end

    CMD --> ROUTING
    ROUTING --> ROUTER
    ROUTING --> W1
    ROUTING --> W2
    ROUTER --> RT
    W1 --> RT
    W2 --> RT
    RT --> CTX
    RT --> GUARD
    RT --> TOOLS["창작 도구: 이미지 / 영상 / 오디오 / 3D / 캔버스 / 소재"]
    RT <--> DB[("영속 데이터베이스: 실행 사실과 상태")]
    RT <--> M["장기 기억: 프로필 / 사실 / 에피소드 요약"]
    TOOLS --> ASSET["공유 산출물과 워크스페이스"]
    ASSET --> UI
    DB --> EVENTS["큐 / 이벤트 발행 / 실시간 푸시"]
    EVENTS --> UI

그림 2: Lomo Agent 전체 계층 아키텍처

이 아키텍처의 중요한 특징 하나는 작업 실행과 창작 산출물이 각자 독립된 생명주기를 갖는다는 점입니다.

예를 들어 사용자가 메인 스레드에서 포스터 제작을 요청하면, 시스템은 이를 위한 독립 작업을 만듭니다. 이후의 참고 이미지, 생성 기록, 수정 이력은 이 작업이 관리하고, 최종 산출물은 공유 워크스페이스에 저장됩니다. 사용자가 다른 작업으로 넘어가더라도 포스터 작업은 계속 생성 결과를 기다리다가 필요할 때 실행을 재개할 수 있습니다.

메인 스레드는 작업의 개요와 현재 상태만 유지하면 되고, 모델 호출과 도구 실행 하나하나의 전체 과정을 오래 들고 있을 필요가 없습니다. 덕분에 사용 기간이 길어져도 메인 스레드 컨텍스트가 끝없이 불어나는 일을 막을 수 있습니다.

DeepSeek Super-agent에서 얻은 영감

설계 과정에서 DeepSeek 팀의 Super-agent 아키텍처 구상은 많은 영감을 주었습니다.

Super-agent 역시 조율과 실행을 분리하는 접근을 택해 Router / Worker로 서로 다른 목표를 구성하고, Ticket / Executor 같은 메커니즘으로 작업 귀속을 유지합니다. 이런 설계는 특히 오래 실행되면서 새 지시를 반복해서 받아야 하는 Agent에 잘 맞습니다.

다만 DeepSeek가 공개한 연구 프로토타입은 주로 코드 저장소 시나리오를 겨냥합니다. 저장소 작업은 보통 작업 범위, 파일 변경, 결과물이 비교적 명확하지만, AI 창작 작업은 경계가 훨씬 모호합니다.

예를 들어 간단한 이미지 생성은 수십 초면 끝나지만, 사용자가 이어서 몇 번 수정하다 보면 점점 장기 창작 프로젝트로 발전할 수 있습니다. 게다가 같은 소재를 여러 작업이 참조하고 수정할 수도 있습니다.

그래서 저희는 Router / Worker의 기본 분업은 유지하면서, 창작 시나리오에 맞춰 경량 작업, 공유 산출물 아이덴티티, 비동기 대기 같은 설계를 추가했습니다.

이 방식은 작업 귀속 판단, 공유 객체 권한, 작업 간 상태 동기화 같은 새로운 복잡도도 가져옵니다. 이어지는 장에서 하나씩 다루겠습니다.

2.2 모든 요청에 독립 Worker가 필요한 것은 아닙니다

멀티 Agent 아키텍처는 흔히 이런 함정에 빠집니다. 작업을 쪼갤 수 있으니 가능한 한 모든 일을 독립 Agent에게 맡기려는 것입니다.

하지만 독립 실행 공간에는 그 자체로 비용이 듭니다. Worker를 하나 만들 때마다 컨텍스트, 실행 상태, 메시지 라우팅 관계를 추가로 유지해야 하고, 모델 호출과 조율 비용도 함께 늘어날 수 있습니다.

Lomo Agent의 창작 시나리오를 예로 들어 보겠습니다.

사용자가 “이 영상 모델은 어떤 해상도를 지원해?”라고 물으면 Main이 직접 처리할 수 있습니다.

사용자가 “주황 고양이 이미지 한 장 만들어 줘”라고 하면 생성 작업 한 번이면 충분할 수 있습니다.

반면 “스타일이 통일된 브랜드 포스터 세트를 만들어 줘”는 기획, 소재 관리, 여러 차례의 생성과 이후 수정이 얽혀 있으므로 독립 작업을 만드는 편이 적합합니다.

이를 위해 실행 작업을 다시 경량 작업(Lightweight Task)과 정식 작업(Persistent Task)으로 구분했습니다.

경량 작업은 주로 단발성 생성, 실행 상태, 결과 카드를 담기 위한 것으로, 사용자의 작업 목록을 오래 차지하지 않습니다. 사용자가 생성 결과를 놓고 계속 수정하거나 작업이 점점 복잡한 창작 목표로 발전하면, 시스템은 이를 정식 작업으로 승격해 이후 협업에 필요한 컨텍스트와 실행 기록을 보존할 수 있습니다.

정식 작업은 비교적 완전한 생명주기를 가지며, 계속 메시지를 받고, 계획을 실행하고, 외부 작업을 기다리고, 하루 이상 혹은 더 오랜 시간이 지난 뒤에도 일을 재개할 수 있습니다.

이런 구분은 세션 없는 설계를 보완하는 장치이기도 합니다. 사용자가 세션을 관리하는 부담을 줄이려는 것이니, 결국 그 자리를 또 다른 자주 정리해야 하는 작업 목록으로 바꿔 놓는 것도 원하지 않았습니다.

2.3 한 번의 협업은 어떻게 흘러가는가

앞에서 본 브랜드 포스터와 고양이 영상 예시로 돌아가 보겠습니다.

사용자가 먼저 Main에서 포스터 제작을 요청하면, Router는 이것이 계속 진행해야 하는 목표라고 판단해 해당 작업을 만들고, 이후의 기획과 생성은 Worker가 맡습니다.

포스터를 만드는 동안 사용자가 이전의 고양이 이미지로 영상을 만들어 달라고 합니다. 시스템은 이것이 별개의 독립된 일이라고 식별하고 새 실행 공간을 만듭니다. 두 작업은 각자 컨텍스트를 유지하며 각자의 상태에 따라 독립적으로 진행됩니다.

포스터 시안을 확인받아야 할 때 Agent는 작업 카드로 후보 시안을 사용자에게 보여 줍니다. 사용자가 카드에서 바로 선택하면, 그 메시지는 명확한 작업 아이덴티티를 따라 해당 Worker로 돌아가므로 의미 판단을 다시 할 필요가 없습니다.

며칠 뒤 사용자가 메인 스레드에서 “지난번 그 포스터, 좀 더 따뜻하게 해 줘”라고 말하면, Router는 작업 인덱스와 이력 정보를 함께 살펴 이 새 지시를 원래의 포스터 작업과 연결합니다.

sequenceDiagram
    participant U as 사용자
    participant R as Main / Router
    participant A as Task A / 포스터
    participant B as Task B / 영상
    U->>R: 브랜드 포스터 시리즈를 만들어 줘
    R->>A: 작업과 브리프 생성
    R-->>U: 메인 스레드에 작업 카드 표시
    U->>R: 그리고 어제 고양이를 영상으로 만들어 줘
    R->>B: 다른 작업 생성
    Note over A,B: 독립 컨텍스트, 병렬 진행
    A-->>U: 포스터 시안 확인 요청
    U->>A: 카드에서 시안 B 선택
    B-->>U: 영상 생성 완료
    U->>R: 지난번 포스터 좀 더 따뜻하게
    R->>A: 후속 요청을 기존 작업으로 전달

그림 3: Main / Task 다중 작업 협업 시퀀스 다이어그램

여기에는 눈여겨볼 설계 디테일이 하나 있습니다. 메시지의 귀속과 메시지의 실행은 서로 다른 두 단계라는 점입니다.

Router가 메시지를 해당 작업에 배정하더라도 Worker가 곧바로 처리한다는 보장은 없습니다. 예를 들어 Worker는 영상 생성을 기다리는 중일 수도 있고, 사용자 확인 단계에서 멈춰 있을 수도 있습니다. 새 메시지는 먼저 영속 수신함에 들어가고, 런타임이 현재 상태에 맞춰 소비 시점을 정합니다.

이는 작업 구성이 첫걸음에 불과하다는 뜻이기도 합니다. 작업 수가 늘어날수록 사용자의 후속 의도를 정확히 식별하고, 잘못된 라우팅을 피하고, 실행 중에 끼어든 새 메시지를 처리하는 일이 전체 아키텍처의 중요한 문제가 됩니다.

3. 메시지 라우팅: 모든 메시지가 올바른 실행 단위를 찾아가도록

통합 상호작용 진입점 덕분에 사용자는 자연스럽게 작업을 오갈 수 있지만, 원래 사용자가 하던 일 하나가 시스템으로 넘어옵니다. 바로 새 메시지마다 누가 처리해야 하는지 판단하는 일입니다.

예를 들어 사용자가 방금 이미지 한 장을 생성하고 나서 갑자기 “아까 그거 파란색으로 바꿔 줘”라고 말합니다.

여기서 ‘그거’는 가장 최근에 생성한 이미지일 수도 있고, 이전 포스터 작업에 있던 소재일 수도 있습니다.

귀속 판단이 어긋나면 가볍게는 중복 작업이 생기고, 심하면 Agent가 엉뚱한 작품을 수정하게 됩니다.

따라서 메시지 라우팅의 정확도는 시스템 전체의 신뢰성에 직접 영향을 줍니다. 저희는 모든 메시지의 귀속을 모델이 매번 다시 추측하게 두지 않고, 비교적 단순한 원칙을 택했습니다. 명확한 관계로 확정할 수 있는 것은 프로그램이 직접 처리하고, 명확한 귀속이 없을 때만 모델에게 의미 판단을 맡긴다.

3.1 결정적 라우팅과 시맨틱 라우팅

Lomo Agent의 메시지 수신은 크게 세 단계로 나뉩니다.

첫 번째 계층: 목표가 명확한 직접 라우팅.

사용자가 특정 작업 패널에서 답장하거나, 작업 카드의 액션 버튼을 누르거나, 명확하게 연결된 작품에 수정을 요청하면 시스템은 이미 메시지가 어떤 목표에 속하는지 알고 있습니다. 이때는 Task ID나 객체 연관 관계에 따라 바로 전달하면 됩니다.

이런 상황에서 귀속을 판단하려고 모델을 한 번 더 호출하면 오히려 지연과 오판 위험만 늘어납니다.

두 번째 계층: Router의 의미 판단.

메인 스레드에서 보낸, 명확한 목표 귀속이 없는 메시지라면 Router가 현재 요청, 최근 상호작용, 기존 작업 인덱스를 종합해 판단해야 합니다.

가능한 결과는 다음과 같습니다.

• Main이 직접 처리하는 간단한 요청.

• 생성 한 번이면 되는 경량 작업.

• 기존 작업과 연결할 수 있는 후속 지시.

• 정식 작업을 만들어야 하는 새 목표.

• 귀속이 명백히 모호해 사용자 확인이 더 필요한 경우.

여기에도 놓치기 쉬운 점이 있습니다. Router가 모든 작업의 전체 이력을 읽을 필요는 없다는 것입니다. 보통은 작업의 목표, 요약, 최근 상태, 관련 객체 참조만 제공하고, 후보 목표를 식별한 뒤에 구체적인 정보를 필요한 만큼 읽으면 됩니다.

이렇게 하면 작업 수가 늘어나면서 라우팅 자체가 또 하나의 끝없이 불어나는 컨텍스트로 변하는 것을 막을 수 있습니다.

현재는 최근 활동한 작업 일부를 우선 제공하며, 여기에는 목표, 요약, 상태 같은 인덱스 정보가 포함됩니다. 사용자가 더 이전의 일을 꺼내면 키워드와 요약 벡터 유사도로 검색한 뒤, 관련 후보 몇 개만 Router에 넘겨 판단하게 합니다. 이렇게 하면 작업 수가 늘어나도 주로 영향을 받는 것은 검색 범위이지, 매번 추론할 때 실어야 하는 컨텍스트 길이가 아닙니다.

자주 일어나는 오류가 하나 더 있습니다. 사용자가 원래 이어 가려던 일을 새 목표로 착각하는 것입니다. 이를 막기 위해 시스템은 정식 작업을 만들기 전에 진행 중인 최근 50개 작업과 한 번 더 유사도를 검사합니다. 중복일 가능성이 있는 목표가 발견되면 가장 비슷한 후보 몇 개를 모델에 넘겨, 기존 작업을 이어서 쓸지 새로 만들지 판단하게 합니다. 이런 검사로 중복 생성을 일부 막을 수는 있지만, 모든 의미적 모호함을 해소해 주지는 못합니다. 근거가 부족한 경우에는 여전히 사용자가 명확히 선택하도록 해야 합니다.

세 번째 계층: 실행 전 귀속과 상태 확인.

메시지의 목표를 정한 뒤에도 시스템은 작업이 유효한지, 현재 조작을 받을 수 있는 상태인지, 관련 객체에 아직 접근할 수 있는지를 확인해야 합니다.

예를 들어 사용자가 이미 보관된 작업을 참조하거나, 이미 삭제된 소재를 수정하려 할 수 있습니다. Router가 의미상 올바른 귀속을 내놓았다고 해서 이후 조작이 반드시 실행 가능한 것은 아닙니다.

flowchart TD
    M["사용자 메시지 또는 상호작용 이벤트 수신"] --> A{"명확한 작업 아이덴티티가 있는가?"}
    A -->|예| V["기존 목표와 접근 권한 확인"]
    A -->|아니요| B{"명확한 객체 연관이 있는가?"}
    B -->|예| V
    B -->|아니요| R["Router 의미 판단"]

    R --> Q["간단한 요청: Main이 직접 처리"]
    R --> L["단일 단계 생성: 경량 작업 생성"]
    R --> E["기존 목표: 기존 작업과 연결"]
    R --> N["독립 목표: 정식 작업 생성 준비"]
    R --> C["모호함: 사용자 확인 요청"]
    N --> S{"진행 중인 작업과 중복으로 감지되었는가?"}
    S -->|예| H["유사 후보 제공, 모델이 판단"]
    H -->|기존 작업과 연결| E
    H -->|새로 생성 확인| CREATE["정식 작업 생성"]
    S -->|아니요| CREATE
    CREATE --> NV["새 작업과 조작 권한 검증"]
    L --> NV
    NV --> I["실행 상태 구성 후 입력 전달"]

    E --> V
    V --> D{"기존 목표 상태가 유효한가?"}
    D -->|예| T["해당 작업 Inbox에 기록"]
    D -->|아니요| F["사용자에게 알리거나 목표 재선택"]
    C --> U["사용자 답변 후 다시 판단"]
    U --> R

그림 4: Lomo Agent 메시지 라우팅 흐름.

3.2 메시지가 도착했다고 바로 실행되는 것은 아닙니다

메시지 라우팅에는 놓치기 쉬운 디테일이 하나 더 있습니다. 메시지가 어떤 Worker에 배정되는 시점과 Worker가 실제로 그 메시지를 처리하기 시작하는 시점은 다를 수 있습니다.

예를 들어 Agent가 영상을 생성하고 있는데 사용자가 갑자기 “배경을 실내로 바꿔 줘”라고 덧붙입니다.

이 시점에는 영상 생성 요청이 이미 업스트림 서비스로 넘어가 있어서 바로 수정할 수 없을 수 있습니다. 시스템은 먼저 이 새 지시를 저장해 두고, Worker가 적절한 실행 경계에 도달하면 현재 진행 상황을 고려해 다음 행동을 판단해야 합니다.

그래서 작업마다 영속적인 메시지 수신함(Inbox)을 둡니다. Router는 메시지를 올바른 수신함으로 보내는 일을 맡고, 런타임은 언제 읽을지, 컨텍스트에 어떻게 합칠지, 기존 계획을 조정해야 하는지를 결정합니다.

여기서는 몇 가지 경우를 구분해야 합니다.

• 아직 Worker가 소비하지 않은 메시지는 조건을 만족하면 철회하거나 교체할 수 있습니다.

• 이미 모델 추론에 들어간 메시지는 현재 실행 경계까지 기다려야 합니다.

• 이미 제출된 외부 생성 요청은 현재 바로 철회할 수 없습니다. 새 지시는 Worker가 적절한 실행 경계에 도달할 때까지 기다린 뒤, 작업 진행 상황에 따라 다시 생성할지, 아니면 새 제약을 이후 단계에 적용할지 결정합니다.

이런 분리는 이후의 중단 후 복구, 비동기 작업, 사용자의 수시 개입을 가능하게 하는 기반이 되기도 합니다.

3.3 협업 제품에서 빌려 온 메시지 귀속 설계

상호작용 설계에서는 Slack, Feishu(Lark) 같은 협업 제품의 메시지 구성 방식도 참고했습니다.

Thread(스레드 답글)를 예로 들면, 사용자가 특정 스레드 아래에 답글을 달 때 시스템은 그 메시지가 어느 논의에 속하는지 자연스럽게 알고 있으므로, 대화 전체를 다시 분석해 귀속을 판단할 필요가 없습니다. 이런 명시적 연결은 안정적이고 예측 가능하며, 추가 의미 식별 비용도 거의 들지 않습니다.

하지만 Lomo Agent가 마주하는 상호작용 시나리오는 훨씬 유연합니다. 사용자는 작업 카드에서 바로 답할 수도 있고, 메인 스레드로 돌아와 며칠 전의 일을 무심코 꺼낼 수도 있습니다.

그래서 두 가지 방식을 모두 유지했습니다. 명확한 작업 조작에는 구조화된 아이덴티티로 바로 라우팅하고, 메인 스레드의 자연어는 Router가 과거 작업과 연결합니다.

이 하이브리드 전략은 모델이 라우팅에 관여하는 횟수를 줄여 주지만, 모호함을 완전히 없애지는 못합니다. 예를 들어 사용자가 포스터 두 세트를 동시에 만들고 있는데 “지난번 그거 고쳐 줘”라고만 하면, 시스템이 목표를 판단할 근거가 부족할 수 있습니다. 이럴 때는 가장 관련 있어 보이는 작업을 알아서 고르기보다 먼저 물어보는 편이 대체로 더 안전합니다.

작업 수가 늘어날수록 재현율, 라우팅 정확도, 상호작용 비용 사이에서 어떻게 균형을 잡을지는 실제 사용 데이터를 보며 계속 다듬어야 합니다.

다만 귀속 판단이 전체 경로의 마지막 검사는 아닙니다. 작업이 하나 더 생기는 정도라면 보통 합치거나 닫으면 됩니다. 하지만 메시지가 작품 수정, 소재 삭제, 유료 생성에 잘못 연결되면 대가는 훨씬 커질 수 있습니다. 그래서 메시지 라우팅과 실제 실행 권한 부여를 분리했습니다. 전자는 일을 어느 작업에 맡길지 판단하고, 후자는 그와 별개로 권한과 비용의 경계를 다시 확인합니다.

예를 들어 소재 삭제나 기억 잊기처럼 되돌릴 수 없는 조작은 매번 사용자 확인이 필요합니다. 유료 생성은 먼저 견적을 보여 주고, 확인 없이 진행할 수 있는 한도나 하루 무확인 상한, 또는 승인된 계획 예산을 넘으면 사용자에게 확인을 요청합니다. 공개 API로 시작한 유료 조작도 건마다 확인합니다. Router가 올바른 작업을 골랐다고 해서 사용자가 권한을 준 범위를 넘어서는 실행권을 얻는 것은 아닙니다.

메시지가 올바른 작업에 들어간 뒤에도 실행은 몇 분에서 며칠까지 이어질 수 있고, 프로세스 재시작, 네트워크 타임아웃, 사용자 취소를 겪을 수 있습니다. 안정적인 복구는 내구성 실행 메커니즘이 맡습니다.

4. 내구성 실행: 중단 후 복구, 재시도, 동시성 제어

메시지를 올바른 작업으로 라우팅했다면, 다음으로 풀어야 할 것은 실행 과정의 신뢰성입니다.

일반적인 Chat Completion은 요청 하나가 보통 몇 초에서 수십 초 안에 끝납니다. 하지만 창작 Agent의 작업 흐름은 훨씬 복잡합니다. 영상 하나를 만드는 데 여러 차례의 모델 추론, 수십 번의 도구 호출, 몇 분씩 걸리는 외부 생성 작업 여러 개가 얽힐 수 있습니다. 실행 중에도 사용자는 언제든 요구사항을 바꾸거나 작업을 직접 멈출 수 있습니다.

아주 흔한 장애 시나리오를 하나 생각해 보겠습니다. Agent가 영상 생성 서비스에 요청을 제출했고 업스트림에서는 실제로 작업이 생성되었는데, 응답을 받기 직전에 서비스 프로세스가 재시작되었습니다.

복구 후에는 어떻게 해야 할까요? 바로 재시도하면 중복 생성되면서 요금이 또 차감될 수 있습니다. 반대로 요청이 성공했다고 간주하면, 실제로는 만들어지지 않은 작업을 영원히 기다리게 될 수도 있습니다.

이런 문제를 겪으며, Agent의 실행 과정에는 모델 컨텍스트와 서비스 프로세스로부터 독립된 영속 상태가 필요하다는 것을 깨달았습니다.

그래서 Lomo Agent에 Durable Execution(내구성 실행) 메커니즘을 도입했습니다. 데이터베이스는 핵심 실행 상태, 모델의 결정, 도구 호출 결과를 기록하고, 작업 큐는 실행 스케줄링과 복구를, 실시간 이벤트는 사용자에게 진행 상황을 전달하는 일을 맡습니다. 실행 프로세스가 중단되더라도 시스템은 저장된 사실을 근거로 다음에 무엇을 해야 할지 판단할 수 있습니다.

설계에서는 Temporal의 Durable Execution 접근을 참고했습니다. Temporal은 워크플로 이력, 작업 스케줄링, 재시도 메커니즘으로 비즈니스 프로세스가 단일 프로세스의 생명주기를 넘어 이어지게 하며, 그 장점은 복잡하고 오래 실행되는 워크플로에서 특히 두드러집니다.

다만 범용 워크플로 엔진에는 그에 맞는 모델링 비용과 운영 비용이 따릅니다. Lomo Agent의 실행 과정은 모델 추론, 동적 도구 호출, 창작 상태, 사용자 상호작용까지 관리해야 하므로, Agent 자체의 데이터 구조를 중심으로 실행 원장과 이벤트 스케줄링 메커니즘을 직접 구현했습니다. 여기서 빌려 온 것은 내구성 실행이라는 엔지니어링 사상이며, Temporal의 솔루션을 그대로 썼다는 뜻은 아닙니다.

4.1 결정을 먼저 영속화하고, 그다음 도구를 호출합니다

전통적인 Agent Loop는 보통 단순한 흐름을 따릅니다.

컨텍스트 읽기 → 모델 추론 → 도구 호출 → 결과 획득 → 추론 계속.

짧은 작업이라면 이런 구현으로도 충분히 간단합니다. 하지만 실행 과정이 여러 프로세스, 외부 서비스, 과금 시스템에 걸쳐 있으면 어느 한 단계만 끊겨도 상태가 어긋날 수 있습니다.

저희는 실행 과정을 일련의 Step으로 나눴습니다. 각 Step에는 모델 추론 한 번과, 모델이 제안한 도구 호출 묶음이 포함될 수 있습니다.

도구를 실행하기 전에 런타임은 먼저 모델의 결정 결과와 실행 대기 중인 호출을 영속화합니다. 모든 도구 호출에는 안정적인 비즈니스 식별자가 있고, 실행 원장에 그 상태, 입력, 결과가 기록됩니다.

이렇게 하면 Worker가 복구될 때 원장을 보고 어떤 조작이 끝났는지, 어떤 조작은 재시도해도 되는지, 어떤 조작은 외부 상태부터 확인해야 하는지 판단할 수 있으며, 같은 라운드의 도구 결정을 얻으려고 모델을 다시 호출할 필요가 없습니다.

flowchart TD
    S["Inbox와 현재 실행 상태 읽기"] --> L["모델 추론, 응답과 도구 호출 의도 생성"]
    L --> P["모델 결과와 실행 대기 호출을 원자적으로 커밋"]
    P --> X{"호출에 이미 영속화된 결과가 있는가?"}
    X -->|예| REUSE["기존 결과 재사용"]
    X -->|아니요| K{"이전에 이미 실행되었을 가능성이 있는가?"}
    K -->|아니요| EXEC["도구 호출 제출"]
    K -->|예| I{"멱등 재시도를 지원하는가?"}
    I -->|예| EXEC
    I -->|아니요| UNKNOWN["결과 불명으로 표시, 모델에 반환"]
    EXEC --> SAVE["도구 결과와 비즈니스 상태 영속화"]
    REUSE --> NEXT["다음 호출 또는 Step으로"]
    SAVE --> NEXT
    UNKNOWN --> CHECK["현재 상태를 먼저 조회한 뒤 재시도 여부 결정"]
    CHECK --> NEXT

그림 5: Agent의 내구성 실행 흐름.

여기서 핵심 개념이 하나 등장합니다. 바로 멱등성(Idempotency)입니다.

사용자가 영상 생성을 승인했는데 네트워크 타임아웃 때문에 시스템이 같은 요청을 두 번 제출했다고 해 봅시다. 이상적으로는 두 번의 제출이 같은 생성 주문 하나에 대응해야 합니다. 영상이 두 개 생기면 안 되고, 요금이 두 번 차감되는 일은 더더욱 없어야 합니다.

멱등 키를 지원하는 다운스트림 서비스라면 안정적인 호출 식별자로 중복을 제거할 수 있습니다. 플랫폼 내부의 주문과 과금 흐름에서도 호출 ID, 주문 ID, 유니크 제약으로 중복 요청이 새로운 비즈니스 효과를 내지 않도록 보장할 수 있습니다.

하지만 업스트림 생성 API가 멱등 키도 지원하지 않고 요청 결과도 조회할 수 없다면, 네트워크 타임아웃 이후 시스템은 작업이 생성되었는지 실제로 확인할 방법이 없습니다.

이때 내구성 실행이 Exactly-once(정확히 한 번 실행)를 무에서 만들어 보장해 주지는 못합니다.

여기서는 두 가지 경우를 더 구분해야 합니다. 멱등하지 않은 소수의 도구는 실행 원장에 이미 started가 기록되었는데 끝내 결과가 없으면, 런타임이 곧바로 다시 실행하지 않고 outcome_unknown 표시가 붙은 결과를 모델에 넘깁니다. 모델은 먼저 현재 상태를 확인한 뒤 다음 행동을 결정합니다. 멱등성을 지원하는 호출이라면 원래 호출 식별자를 그대로 써서 재실행할 수 있습니다.

불확실성은 생성 서비스와 업스트림 API 사이에서도 한 겹 더 생깁니다. 여기서는 더 보수적인 전략을 택했습니다. 제출 결과가 불분명하면 그 제출을 실패로 판정하고, 업스트림에 자동으로 다시 요청하지 않습니다. 둘 다 ‘결과 불명’이라고 부르지만, 하나는 Agent 도구 호출의 복구를 다루는 것이고, 다른 하나는 실제로 과금되는 생성 작업이 중복 생성되는 것을 막는 것입니다.

Temporal도 Activity 재시도에서 같은 문제를 안고 있습니다. 워크플로 엔진은 실행을 안정적으로 스케줄링하고 재시도할 수 있지만, 외부 API의 부수 효과에는 여전히 비즈니스 차원의 멱등 메커니즘이 함께 있어야 합니다.

유료 생성 서비스에서는 이 경계가 특히 중요합니다. 실행 실패는 복구할 수 있지만, 중복 과금은 자동으로 메울 수 있다는 보장이 없습니다.

4.2 Worker 인수와 Fencing Token

내구성 실행은 프로세스 중단 이후의 복구 문제를 해결하지만, 더 은밀한 상황이 하나 남아 있습니다. 원래의 Worker가 실제로는 종료되지 않았을 수도 있다는 점입니다.

예를 들어 Worker A가 실행 도중 네트워크 지터 때문에 잠시 연결이 끊겼다고 해 봅시다. 시스템은 타임아웃을 감지하고 Worker B에게 작업을 넘겨 실행을 이어 갑니다. 몇 초 뒤 Worker A가 연결을 회복하고, 방금 끝낸 결과를 커밋하려고 시도합니다.

이 시점에 시스템에는 자신에게 실행권이 있다고 믿는 Worker가 둘 존재할 수 있습니다. 아무 제한도 없다면 이전 Worker가 새 상태를 덮어쓰거나, 이미 중지된 작업을 다시 실행 흐름에 밀어 넣을 수도 있습니다.

이를 막기 위해 Fencing Token(펜싱 토큰)과 비슷한 실행 세대(generation) 메커니즘을 사용합니다.

작업이 새 실행 주체에게 넘어갈 때마다 런타임은 그 작업의 실행 세대를 올립니다. Worker는 상태 변경을 커밋할 때 자신이 가진 세대를 함께 보내 검증을 받아야 합니다.

데이터베이스에 있는 현재 세대가 이미 갱신되었다면 이전 Worker의 커밋은 거부됩니다.

이 메커니즘은 이렇게 이해할 수 있습니다. 시스템은 새 실행 주체가 일을 넘겨받도록 허용하는 동시에, 이전 실행 주체가 내부 상태를 계속 수정할 자격을 박탈합니다.

사용자가 직접 작업을 중지할 때도 실행 상태와 실행 세대를 확인해, 이전 Worker가 복구된 뒤 계속 진행하는 것을 막아야 합니다.

다만 Fencing Token이 보호하는 것은 시스템 내부 상태의 일관성입니다. 이전 Worker가 이미 외부 플랫폼에 영상 생성 요청을 보냈다면, 내부 실행권이 무효가 되었다고 해서 원격 조작이 자동으로 취소되지는 않습니다.

그래서 사용자가 작업을 중지했더라도 앞서 제출한 외부 생성은 계속 돌고 있을 수 있습니다. 생성 서비스는 작업 결과를 계속 추적하고 그에 따른 비용 정산을 마무리하지만, 뒤늦게 도착한 완료 이벤트가 중지된 작업을 다시 깨우거나 이미 취소된 실행 상태를 바꾸지는 않습니다.

4.3 실행 중에 들어온 사용자의 새 메시지는 어떻게 처리하는가

사용자의 실시간 개입에서 비롯되는 문제도 있습니다.

Agent가 모델을 호출해 포스터 세트를 생성하려는 참에 사용자가 이렇게 보냈다고 해 봅시다. “배경은 흰색 말고 짙은 파란색으로 바꿔 줘.”

이 메시지는 모델 추론이 끝나기 전에 이미 서버에 도착했을 수 있지만, 현재 모델 요청은 실제로 그 메시지를 읽지 않았습니다.

시스템이 메시지 생성 시각만 기준으로 이력을 이어 붙이면 상태가 꼬일 수 있습니다. 겉보기에는 모델이 사용자가 요구를 바꾼 뒤에 결정을 내린 것 같지만, 실제로는 새 지시를 전혀 모르는 상태였던 것입니다.

이 문제를 풀기 위해 메시지 수신과 메시지 소비를 분리했습니다.

새 메시지는 먼저 해당 작업의 영속 Inbox에 들어갑니다. Worker는 다음 안전한 실행 경계에서 이 입력들을 읽고, 현재 작업 상태와 함께 모델 컨텍스트로 구성합니다.

시스템은 메시지 전송 시각만으로 선후 관계를 판단하지 않고, 메시지가 실제로 어느 Step에서 소비되었는지를 기록합니다.

이렇게 하면 사용자 지시가 도착한 단계, 모델이 이해한 단계, 관련 조작이 실행된 단계를 명확히 구분할 수 있습니다.

물론 생성 요청이 이미 업스트림에 제출되었다면, 나중에 들어온 수정이 생성 중인 내용을 자동으로 바꾸지는 않습니다. 현재 버전에서는 이런 요청을 철회할 수도 없어서, Worker는 다음 안전한 실행 경계에서 다시 생성할지, 아니면 새 제약을 이후 단계에 적용할지만 결정할 수 있습니다. 사용자가 이미 작업을 중지했다면, 이전 생성이 나중에 완료되더라도 작업이 다시 실행되지는 않습니다.

사용자에게도 인터페이스가 이 상태를 정확히 보여 줘야 합니다. ‘메시지를 받았다’를 ‘지금 생성이 새 요구에 맞춰 조정되었다’로 오해하지 않도록 말입니다.

영상, 오디오, 3D처럼 오래 걸리는 생성 작업에서는 Worker가 외부 결과를 기다리는 동안 실행 리소스를 내려놓고, 이벤트가 도착하면 정확하게 재개해야 합니다.

4.4 실행 원장과 스케줄링 일관성의 경계

앞에서는 모델 결정의 영속화, 그리고 실행 세대로 이전 Worker가 작업 인수 이후에도 상태를 계속 수정하는 일을 막는 방법을 살펴봤습니다. 하지만 실제 운영에서는 놓치기 쉬운 문제가 하나 더 있습니다. 데이터베이스에는 실행 대기 중인 일이 이미 기록되어 있는데, Worker를 깨우는 큐 메시지가 사라졌다면 작업은 어떻게 복구해야 할까요?

Lomo Agent에서는 라운드(Turn)와 도구 호출 원장으로 실행 상태를 관리합니다. 라운드에는 실행 상태, 실행 세대, 리스(lease), 체크포인트(Checkpoint)가 기록되고, 도구 호출은 ‘라운드 + 단계 번호 + 호출 순번’을 안정적인 식별자로 씁니다. 모델이 응답하면 런타임은 결정 결과, 실행 대기 호출, 소비한 Inbox 메시지를 하나의 트랜잭션으로 저장합니다. 도구 실행 전에는 started를 기록하고, 완료되면 결과와 done 상태를 함께 저장합니다. 이렇게 하면 복구할 때 기존 기록을 근거로 결과를 재사용하거나 안전하게 재시도할 수 있고, 이전에 무슨 일이 있었는지 모델이 다시 추측하게 할 필요가 없습니다. 안전하게 재시도할 수 없는 호출은 결과 불명 상태로 남겨 두고 이후의 결정에 맡깁니다.

작업 스케줄링에서는 라운드 큐 투입에 트랜잭션 Outbox를 도입하지 않았습니다. 대신 데이터베이스를 실행 사실의 원천으로 삼고, 큐는 주로 Worker를 깨우는 역할만 맡깁니다. 라운드를 커밋한 뒤 스케줄링 메시지를 보내고, 큐 투입에 실패하면 백그라운드 워치독이 데이터베이스 상태를 보고 작업을 다시 찾아냅니다. 현재 워치독은 10초마다 검사하며, 리스가 만료된 작업, 오래 대기열에 머문 작업, 처리되지 않은 메시지가 있는데 활성 라운드가 없는 작업을 주로 살핍니다. 큐 작업은 라운드 ID와 실행 세대로 식별해 같은 세대의 중복 투입을 줄이고, 중복 스케줄링이 일어나더라도 런타임이 실행 상태와 세대 검증으로 오래된 쓰기를 막습니다. 즉, 제한된 복구 지연을 감수하는 대신 더 단순한 스케줄링 메커니즘을 택한 것입니다. 인터페이스 이벤트 푸시와 외부 생성 작업은 각자의 안정적 전달 및 보상 메커니즘을 그대로 유지합니다.

또 다른 위험은 이전 Worker와 새 Worker의 동시 실행에서 옵니다. Fencing Token은 이전 Worker가 내부 상태를 덮어쓰는 것은 막지만, 이미 보낸 외부 요청을 되돌리지는 못합니다. 그래서 유료 생성의 멱등 키를 ‘라운드 + 단계 번호 + 호출 순번’으로 고정하고 실행 세대는 넣지 않았습니다. 이전 Worker와 새 Worker가 같은 호출을 중복 제출하더라도, 플랫폼 생성 계층은 ‘워크스페이스 + 멱등 키’ 유니크 제약으로 같은 주문에 연결하고 내부 차감도 중복 제거합니다. 이것으로 플랫폼 내부의 중복 주문과 과금은 통제할 수 있지만, 외부 업스트림이 본래 Exactly-once를 보장한다는 뜻은 아닙니다. 반면 모델 결정이 아직 영속화되기 전에 장애가 나면 그 단계를 다시 추론하게 될 수 있습니다. 미디어 생성이 중심인 현재 비용 구조를 고려해, 이 정도의 비교적 제한된 중복 추론 비용은 감수하기로 했습니다.

더 다루기 어려운 것은 업스트림 제출 결과가 불분명한 경우입니다. 요청 타임아웃은 제출 실패를 뜻할 수도 있고, 업스트림에서는 이미 작업이 생성되었는데 응답만 돌아오지 못한 것일 수도 있습니다. 중복 생성을 피하기 위해 현재 생성 서비스는 이런 요청을 자동으로 다시 제출하지 않습니다. 업스트림 작업 ID를 받으면 즉시 영속화해, 중단되더라도 폴링을 이어 갈 수 있게 합니다. 하지만 ID를 받은 시점과 저장하는 시점 사이에 프로세스가 공교롭게 죽으면, 지금으로서는 그 작업을 역으로 조회할 방법이 없습니다. 시스템은 타임아웃 후 규칙에 따라 환불을 처리할 수밖에 없고, 이미 발생했을 수 있는 업스트림 비용은 플랫폼이 부담합니다.

이런 설계로 모든 장애 구간을 없앨 수는 없지만, 상황별 처리 경계는 분명해집니다. 완료를 확인할 수 있으면 그대로 재사용하고, 안전하게 재시도할 수 있으면 계속 실행하며, 확인할 수 없으면 무작정 다시 제출하지 않습니다. 계속 실행되는 Agent에게 신뢰성이란 모든 단계가 실패하지 않는 것이 아니라, 중단이 일어난 뒤에도 시스템이 이미 있는 사실을 근거로 통제 가능한 복구 결정을 내릴 수 있다는 뜻입니다.

5. 비동기 생성: 작업 생명주기와 이벤트 기반 깨우기

앞에서 소개한 내구성 실행은 주로 Agent가 실행 중에 상태를 기록하고, 장애를 처리하고, 실행을 복구하는 문제를 다뤘습니다. 하지만 AI 창작 시나리오에는 피할 수 없는 특징이 하나 더 있습니다. 상당수의 도구 호출 자체가 비동기라는 점입니다.

예를 들어 이미지 생성은 몇 초면 끝나지만, 영상과 3D 작업은 몇 분 혹은 그 이상 걸릴 수 있습니다. 작업을 제출하면 업스트림 서비스는 보통 작업 ID만 돌려주고, 실제 생성 결과는 폴링이나 콜백으로 받아야 합니다.

Worker가 외부 작업이 끝날 때까지 계속 기다리게 하면 실행 리소스를 점유할 뿐 아니라, 모델 추론이 통제할 수 없는 외부 생성 시간과 결합되어 버립니다.

그래서 Agent의 실행 생명주기와 외부 생성 작업의 생명주기를 분리해 관리합니다.

5.1 제출, 대기, 실행 재개

Worker가 생성 도구를 호출하면, 도구는 먼저 해당 서비스에 요청을 제출하고 생성 작업의 식별자를 반환합니다. 이어서 런타임은 작업 ID, 대기 상태, 이후 실행에 필요한 정보 등 생성 작업과 현재 작업 사이의 연관 관계를 저장합니다.

제출을 마치면 Worker는 현재 실행을 일시 중단할 수 있습니다. 모델을 계속 호출할 필요도, 오래 걸리는 추론 요청을 붙잡고 있을 필요도 없습니다.

기다리는 동안 생성 서비스의 진행 상황 변화는 비즈니스 이벤트로 프런트엔드에 바로 푸시되고, 작업 카드가 현재 상태를 보여 줍니다.

작업이 끝나면 런타임은 이후 단계가 생성 결과에 의존하는지에 따라 Worker를 다시 깨울지 결정합니다.

sequenceDiagram
    participant W as Task Worker
    participant G as 생성 서비스
    participant S as 내구성 런타임
    participant UI as 작업 카드

    W->>G: 생성 요청 제출(안정적인 비즈니스 식별자)
    G-->>W: 작업 ID 반환
    W->>S: 작업 연관과 대기 상태 저장
    Note over W,S: 이상은 정상 경로이며, 제출 후 저장하지 못한 예외는 4.4 참고
    S-->>UI: 생성 중으로 갱신

    Note over W: Worker 일시 중단, 실행 리소스 해제

    G-->>S: 생성 진행 이벤트
    S-->>UI: 진행 상황 갱신(모델 추론 불필요)

    G-->>S: 생성 완료 이벤트
    S->>S: 작업 상태 갱신과 산출물 저장
    S-->>UI: 생성 결과 표시

    alt 이후 단계가 생성 결과에 의존
        S->>W: 실행 재개 이벤트 전달
        W->>W: 최신 상태를 읽고 실행 계속
    else 지금은 추론을 이어 갈 필요 없음
        Note over UI: 결과와 작업 상태만 갱신
    end

그림 6: 비동기 생성 작업의 실행 흐름(정상 경로).

이 설계가 주는 직접적인 이점은 리소스 활용률 개선입니다. 영상 생성을 기다리는 몇 분 동안 시스템은 영속 상태와 필요한 이벤트 처리만 유지하면 되고, Agent 추론 리소스를 계속 점유할 필요가 없습니다.

동시에 생성 진행 상황과 사용자 인터페이스도 독립적으로 갱신할 수 있습니다. Worker가 모델을 다시 호출할 때까지 기다리지 않아도 사용자는 작업 상태를 실시간으로 볼 수 있습니다.

5.2 비동기 이벤트도 안정적으로 처리해야 합니다

생성 작업을 이벤트 기반으로 바꾼 뒤에는 이벤트 자체의 신뢰성도 고려해야 합니다.

예를 들어 업스트림 서비스가 네트워크 문제로 완료 알림을 중복 전송할 수도 있고, 어떤 콜백이 실패한 뒤 바로 재시도하지 못할 수도 있습니다. 여러 생성 작업이 동시에 돌고 있다면 진행 이벤트가 순서 없이 도착할 수도 있습니다.

따라서 이벤트 처리를 단순히 ‘콜백을 받으면 실행을 이어 간다’로 이해해서는 안 됩니다.

영속화된 작업 상태를 기준으로 생성 작업의 상태를 갱신하고, 중복 이벤트가 중복 기록, 중복 과금, Worker 중복 깨우기로 이어지지 않도록 보장해야 합니다.

순서가 뒤바뀔 수 있는 이벤트라면 오래된 진행 상황이 최종 결과를 덮어쓰지 않도록 해야 합니다. 예를 들어 작업이 이미 완료되었는데 뒤늦게 ‘생성 중’ 알림이 도착했다면, 상태가 다시 뒤로 돌아가서는 안 됩니다.

또한 외부 콜백은 항상 믿을 수 있는 것이 아닙니다. 오랫동안 결과를 받지 못한 작업은 작업 ID와 업스트림 조회 API로 상태를 대조하고, 필요하면 보상 폴링으로 작업 진행 상황을 복구할 수 있습니다.

이 부분은 앞에서 소개한 Durable Execution과 서로 맞물려 있습니다. 런타임은 신뢰할 수 있는 실행 상태를 유지하고, 비동기 작업 시스템은 외부 생성 과정에서 생긴 변화를 복구 가능한 비즈니스 이벤트로 바꿉니다.

5.3 Worker는 언제 깨워야 하는가

모델 호출 비용과 직결되는 문제가 하나 더 있습니다. 생성 작업이 끝날 때마다 모델을 다시 호출해야 할까요?

답은 그 작업 뒤에 Agent가 결정해야 할 일이 남아 있느냐에 달려 있습니다.

예를 들어 사용자가 “고양이 이미지 한 장 만들어 줘”라고만 했다면, 생성이 끝난 뒤 결과만 보여 주면 됩니다. Worker를 다시 깨워 모델이 방금 생성한 이미지를 또 설명하게 할 필요가 없습니다.

하지만 사용자가 “스타일이 일관된 브랜드 포스터 세트를 만들어 줘”라고 했다면, 지금의 생성 결과가 다음 단계의 입력이 될 수 있습니다. Agent는 기존 산출물을 점검하고, 실행 체크리스트를 읽고, 현재 목표에 비추어 다음에 생성을 이어 갈지 사용자 확인을 기다릴지 결정해야 합니다.

그래서 생성 완료 이벤트와 Agent의 계속 실행 결정을 분리해 처리합니다.

생성 서비스는 결과를 보고하는 일을 맡고, 런타임은 작업 계획, 대기 관계, 권한 부여, 현재 실행 상태를 보고 Worker를 재개할지 판단합니다.

이렇게 하면 수많은 진행 이벤트를 모델에게 그대로 넘기는 일도 피할 수 있습니다. 몇 분짜리 영상 작업에서도 업스트림은 상태 변화를 많이 만들어 내지만, 대부분은 프런트엔드만 갱신하면 되는 것이지 새 추론을 일으킬 만한 것이 아닙니다.

이런 이벤트 기반 설계는 범용 워크플로 엔진이나 작업 큐의 비동기 대기 메커니즘과 비슷합니다. Lomo Agent에서 저희가 한 걸음 더 들어가 고민한 것은 이를 창작 목표, 실행 체크리스트, 사용자 검토 흐름과 어떻게 결합하느냐였습니다.

예를 들어 영상 컷 하나의 생성이 끝났는데 아직 만들어야 할 컷이 남아 있고 사용자가 계속 진행하도록 권한을 줬다면, 런타임은 해당 작업을 재개할 수 있습니다. 반대로 현재 단계에서 사용자 검토가 필요하다면 확인을 기다리는 상태에 머물러야 합니다.

생성이 끝났다는 것은 도구 호출 하나가 끝났다는 의미일 뿐입니다. 창작 작업 전체를 계속 진행할지는 계획, 예산, 권한 부여를 함께 보고 판단해야 합니다.

여기서 이후에 다룰 자율 진행 메커니즘이 등장합니다. Agent가 한 단계를 마치거나 이번 추론 라운드를 끝내려 할 때, 시스템은 작업이 정말 끝났는지, 그리고 실행을 계속해야 하는지를 어떻게 판단할까요?

6. Context 엔지니어링: 한정된 윈도 안에서 유효한 상태 유지하기

Agent가 오래 걸리고 여러 단계로 이루어진 창작 작업을 다루기 시작하면서, 컨텍스트 관리는 실행 품질과 비용을 좌우하는 중요한 요소가 되었습니다.

며칠씩 이어지는 창작 작업에는 수백 개의 메시지, 수십 번의 도구 호출, 그리고 많은 이미지·영상·워크플로 상태가 쌓일 수 있습니다. 모델의 컨텍스트 윈도가 점점 커지고 있다고는 해도, 이 정보를 매번 추론에 모두 밀어 넣는 것은 현실적이지 않습니다.

긴 컨텍스트는 Token 비용과 추론 지연을 높일 뿐 아니라, 지나치게 많은 과거 정보가 현재 목표에 대한 모델의 판단을 흐릴 수도 있습니다. 특히 사용자가 요구를 여러 번 바꾼 경우, 초기에 이미 무효가 된 제약이 컨텍스트에 섞여 있으면 이후 생성에 쉽게 영향을 줍니다.

그래서 컨텍스트 관리를 독립된 엔지니어링 문제로 다룹니다. 추론의 매 단계에서 모델이 충분하고, 관련 있고, 여전히 유효한 정보를 얻게 하려면 어떻게 해야 하는가.

6.1 컨텍스트 계층화와 Prompt Cache

Lomo Agent는 모델 컨텍스트를 몇 개의 계층으로 구성합니다. 비교적 안정적인 시스템 프리픽스, 압축된 이력, 최근 상호작용, 그리고 현재 실행 단계에 필요한 동적 상태입니다.

flowchart LR
    A["안정 프리픽스: 시스템 규칙 / 핵심 도구 / 프로필 스냅숏"] --> B["구간별 이력 요약"]
    B --> C["최근 메시지와 핵심 도구 결과"]
    C --> D["동적 테일: 브리프 / 체크리스트 / 예산 / 객체 변경"]
    D --> E["이번 단계 입력과 온디맨드 리콜"]

그림 7: Lomo Agent의 컨텍스트 구성 방식.

여기에는 실제 추론 비용과 밀접한 요소가 하나 있습니다. 바로 Prompt Caching(프롬프트 캐싱)입니다. 이하에서 말하는 Prompt Cache는 모델 서비스 제공자가 API 계층에서 제공하는 프롬프트 캐시 기능을 가리키며, 구체적인 구현과 재사용 가능한 범위는 제공자가 정합니다.

이 기능을 지원하는 모델 서비스는 자체 캐시 규칙에 맞는 프롬프트 프리픽스를 재사용해 중복 처리 비용을 줄일 수 있습니다. 그래서 시스템 규칙, 핵심 도구, 비교적 안정적인 프로필 정보는 되도록 컨텍스트 앞부분에 두고, 단계마다 바뀔 수 있는 작업 상태는 뒷부분에 둡니다.

변동이 심한 정보를 프리픽스 앞쪽에 끼워 넣으면, 그 뒤의 원래 안정적이던 내용까지 캐시를 제대로 재사용하지 못할 수 있습니다.

다만 Prompt Cache의 실제 적중률은 모델 제공자, 요청 라우팅, 캐시 정책의 영향도 받습니다. 컨텍스트 배치는 캐시 재사용의 조건을 만들어 줄 뿐이고, 최종 효과는 실제 호출 데이터로 검증해야 합니다.

또한 프리픽스가 안정적이라고 해서 프로필을 오래 갱신하지 않아도 된다는 뜻은 아닙니다. 사용자가 선호를 바꾸거나 어떤 정보를 잊어 달라고 하면 관련 프로필 스냅숏은 즉시 무효화해야 합니다. 그래야 캐시 재사용 때문에 낡은 정보가 계속 추론에 끼어드는 일을 막을 수 있습니다.

6.2 온디맨드 도구 로딩: 기능이 많을수록 컨텍스트는 비싸집니다

Lomote AI는 이미지 생성, 영상 생성, 3D, 소재 관리, 문서 편집, Flows 워크플로 등 여러 영역에 걸친 다양한 창작 모델과 도구를 통합하고 있습니다.

모든 도구의 이름, 파라미터, 사용 설명을 매번 모델 요청에 넣으면 Token 소모가 늘어날 뿐 아니라, 모델이 비슷비슷한 수많은 도구 사이에서 잘못 고를 수도 있습니다.

그래서 도구를 두 부류로 나눴습니다. 하나는 항상 보여야 하는 핵심 도구이고, 다른 하나는 기능 영역별로 동적으로 로드하는 도구입니다.

예를 들어 Agent가 스토리보드를 기획할 때는 문서와 소재 관련 도구만 있으면 될 수 있고, 영상 제작 단계에 들어가면 그때 영상 생성과 워크플로 기능을 로드합니다.

더 이상 쓰지 않는 도구 영역은 컨텍스트 압축 경계에서 상세 정의를 제거해, 관련 없는 정보가 이후 추론에 끼치는 영향을 줄일 수 있습니다.

이 설계에도 대가가 있습니다. 도구 집합이 바뀌면 모델 컨텍스트의 구조도 따라 바뀌어 Prompt Cache 적중률에 영향을 줄 수 있고, 이력에 이미 등장한 도구 호출이 현재 보이는 도구 정의와 완전히 일치하지 않을 수도 있습니다.

이 점에서 Manus의 Context Engineering 실천은 곱씹어 볼 만한 반례를 보여 줍니다.

Manus는 도구 정의를 안정적으로 유지하면서, 현재 사용할 수 있는 액션을 제약하는 방식으로 도구 선택의 복잡도를 낮추는 쪽을 택합니다. 이렇게 하면 도구 정의 변경으로 인한 프리픽스 무효화를 줄이는 데 도움이 되고, 과거 도구 호출과 현재 컨텍스트의 일관성도 유지하기 쉬워집니다. 여기서 다루는 것은 안정적인 컨텍스트가 캐시 재사용에 미치는 영향이며, API 계층의 Prompt Caching을 모델 추론 내부의 KV Cache 메커니즘과 같은 것으로 보지는 않습니다.

Lomo Agent가 영역별 로딩을 택한 것은, 창작 플랫폼의 도구 종류와 파라미터 구조가 비교적 방대해 모든 도구 정의를 늘 유지하면 컨텍스트 비용이 높아질 수 있다는 점을 고려했기 때문입니다.

두 전략은 각자 맞는 조건이 있습니다. 안정적인 도구 집합은 캐시와 행동 일관성에 유리하고, 동적 로딩은 관련 없는 도구가 일으키는 Token 비용과 선택 간섭을 줄일 수 있습니다.

저희 방식의 실제 효과는 도구 전환 빈도, 캐시 적중률, 도구 호출 정확도, 전체 추론 비용을 함께 보며 계속 평가해야 합니다. 덧붙이자면, 도구가 모델 컨텍스트에 나타나는지 여부는 모델이 지금 무엇을 고를 수 있는지에만 영향을 줍니다. 실제 도구 실행 권한은 여전히 서버가 통제하며, Prompt 안에서 도구가 보이는지 여부를 보안 경계로 삼아서는 안 됩니다.

6.3 이력 압축: 요약을 넘어 다시 읽을 수 있는 능력까지

오래 실행되는 동안 과거 메시지와 도구 결과는 계속 늘어납니다. 큰 컨텍스트 윈도를 쓰더라도 적절한 시점에는 압축이 필요합니다.

흔한 방법은 모델이 이전 이력을 계속 요약하게 하고, 최신 요약으로 대화를 이어 가는 것입니다. 그런데 이 방식에는 문제가 있습니다. 압축을 반복하는 과정에서 요약이 디테일을 조금씩 잃고, 심하면 모델 자신의 추측을 과거 사실로 굳혀 버릴 수 있습니다.

그래서 구간별 요약 방식을 택했습니다. 오래된 이력은 구간 단위로 압축하고, 최근 상호작용은 전체 내용을 그대로 유지합니다.

새로 만든 요약은 되도록 기존 요약 시퀀스 뒤에 덧붙여, 매번 이력 전체를 다시 쓰지 않도록 합니다.

소재 목록, 워크플로 노드 정보, 복잡한 생성 결과처럼 큰 도구 출력은 현재 컨텍스트에 필요한 요약만 남기고 전체 내용은 외부 저장소에 둘 수 있습니다.

나중에 Agent가 특정 파라미터나 과거 디테일을 확인해야 하면, 그때 검색이나 페이지 단위 읽기로 관련 정보를 되살립니다.

이는 Manus가 제안한, 파일 시스템을 외부 컨텍스트의 저장소로 쓰는 방식과 통하는 데가 있습니다. 모델이 모든 정보를 늘 들고 다닐 필요는 없지만, 필요할 때 믿을 수 있는 원본 근거를 다시 찾을 수 있어야 합니다.

여기서 눈여겨볼 차이가 하나 있습니다. 요약은 현재 추론의 컨텍스트 부담을 줄이기 위한 것이지, 유일한 과거 사실의 출처가 되어서는 안 됩니다. 특히 사용자가 어떤 정보를 정정했거나 과거의 어떤 제약이 이미 무효가 되었을 때, 시스템은 관련 출처를 찾아내 낡은 요약이 이후 실행에 계속 영향을 주지 않도록 해야 합니다.

6.4 현재 작업을 늘 모델의 시야 안에 두기

컨텍스트 압축은 이력이 너무 길어지는 문제를 해결하지만, 그만큼 중요한 문제가 또 있습니다. 실행이 절반쯤 진행되었을 때 Agent가 자신이 어떤 목표를 향해 가고 있는지 여전히 분명히 알고 있느냐는 것입니다.

오래 실행되는 작업에서는 여러 차례 도구를 호출하는 사이에 모델이 처음 목표에서 조금씩 벗어날 수 있습니다. 예를 들어 사용자는 브랜드 포스터 세트를 완성해 달라고 했는데, Agent는 참고 이미지 한 장을 다듬는 데 많은 힘을 쏟다가 전체 결과물을 놓칠 수 있습니다.

그래서 Worker의 동적 컨텍스트에 현재 브리프, 실행 체크리스트, 핵심 제약, 대기 상태, 관련 작품의 최신 변경 사항을 계속 넣어 줍니다.

이 상태들은 앞선 대화 내용을 모델이 요약한 결과가 아니라 내구성 런타임에서 가져옵니다.

예를 들면 다음과 같습니다.

• 브리프는 사용자가 최종 승인한 비주얼 방향을 기록합니다.

• 실행 체크리스트는 어떤 단계가 끝났고 어떤 단계가 남았는지 기록합니다.

• 워크스페이스 상태는 어떤 소재를 사용자가 교체했는지, 현재 문서가 어느 버전인지 모델에게 알려 줍니다.

사용자가 Flows 워크플로나 공유 문서를 직접 수정하면, 다음 실행 라운드에서 객체 변경 알림을 받고 필요할 때 최신 내용을 읽을 수 있습니다.

이렇게 하면 이력의 일부가 이미 압축되었더라도 Agent는 신뢰할 수 있는 작업 상태를 바탕으로 일을 이어 갈 수 있습니다.

이 부분에서는 할 일 목록을 계속 보여 주며 모델이 목표에 집중하게 하는 Manus의 방식에서도 많은 영감을 받았습니다. Lomo Agent는 여기서 더 나아가 이 체크리스트를 런타임 상태와 결합했습니다. 그래서 체크리스트가 모델에게 컨텍스트를 제공하는 동시에, 이후의 자동 계속 실행과 중지 판단도 뒷받침합니다. 이 부분은 자율 진행 장에서 자세히 다루겠습니다.

6.5 컨텍스트 엔지니어링의 실제 트레이드오프

종합하면 Lomo Agent의 컨텍스트 엔지니어링은 크게 세 가지 목표를 중심으로 움직입니다.

• 관련 없는 정보 줄이기

• 추론 비용 통제하기

• 현재 결정의 근거가 되는 정보가 여전히 유효하도록 보장하기

하지만 이 목표들이 늘 같은 방향을 가리키지는 않습니다.

더 공격적으로 압축하면 Token 소모는 줄지만 중요한 디테일을 놓칠 수 있습니다. 동적 도구 로딩은 도구 선택 공간을 좁혀 주지만 캐시 적중에 영향을 줄 수 있습니다. 안정적인 프로필을 오래 유지하면 연속성은 좋아지지만, 선호 변경과 기억 철회를 반드시 처리해야 합니다.

그래서 컨텍스트 관리는 하나의 고정된 전략으로 모든 문제를 풀기 어렵습니다. 작업 상태, 기억 시스템, 도구 권한, 실제 모델 성능과 함께 맞춰 가야 합니다.

Lomo Agent에서 저희가 더 중요하게 보는 것은, 모델이 필요할 때 올바른 정보를 찾아내고 현재 유효한 작업 상태를 바탕으로 일을 이어 갈 수 있느냐입니다. 그런데 협업이 여러 작업과 여러 날짜, 심지어 몇 달에 걸쳐 이어지면 작업 내부의 컨텍스트 관리만으로는 부족합니다. 사용자가 오랫동안 쌓아 온 선호, 과거 프로젝트, 예전에 내린 결정은 또 다른 메커니즘으로 구성하고 검색해야 합니다.

7. Memory 엔지니어링: 출처, 버전, 철회 가능성

앞 장에서는 한정된 컨텍스트 윈도 안에서 정보를 구성하는 방법을 이야기했습니다. 그런데 오래 협업해야 하는 Agent에게는 더 깊은 문제가 있습니다. 어떤 대화가 이미 현재 컨텍스트를 벗어났고, 관련 작업이 끝난 지도 오래되었다면, 시스템은 무엇을 기억해야 할까요?

Lomo Agent의 창작 시나리오에서 사용자는 몇 달씩 플랫폼을 쓰면서 비교적 안정적인 비주얼 선호, 자주 쓰는 창작 흐름, 브랜드 가이드라인을 차츰 형성해 갑니다. 이런 정보를 매번 사용자에게 다시 설명하라고 해서는 안 됩니다.

동시에 사용자의 선호는 바뀌기도 합니다. 어떤 프로젝트에서 쓴 임시 스타일이 이후의 모든 창작에 맞는 것은 아니고, 예전에 유효했던 브랜드 가이드라인도 한 번의 리뉴얼로 완전히 무효가 될 수 있습니다.

그래서 저희는 장기 기억이 작업과 시간을 넘어 연속성을 제공하면서도, 사실의 출처와 유효 범위를 함께 보존하기를 바랐습니다.

7.1 과거 메시지에서 장기 기억으로

장기 기억이 가장 먼저 풀어야 할 문제는 정보 선별입니다.

예를 들어 사용자가 “저는 보통 채도가 낮은 배색을 좋아해요”라고 말하면 장기적으로 저장할 만한 선호일 수 있습니다. 하지만 “이번엔 채도 높은 빨간색으로 한번 해 보자”라고 말한다면, 이는 지금 작품에 대한 국소적인 요구일 가능성이 큽니다.

두 문장 모두 색에 관한 것이지만 적용 범위가 다릅니다. 시스템이 모든 사용자 메시지를 그대로 벡터 데이터베이스에 넣고 시맨틱 검색으로 다시 채워 넣는다면, 장기 선호와 임시 요구, 이미 무효가 된 과거 정보가 쉽게 뒤섞입니다.

이를 위해 Lomo Agent의 기억을 몇 개의 계층으로 나눴습니다.

이 계층들은 서로 어느 정도 연결되어 있지만, 맡는 역할은 다릅니다.

원본 메시지는 추적 가능한 증거입니다. 시스템은 여기서 후보 기억을 추출하고, 출처, 시각, 적용 범위, 기존 기록을 보고 저장할지, 보완할지, 갱신할지를 판단합니다.

에피소드 요약은 한 차례의 협업에서 무슨 일이 있었는지에 더 초점을 둡니다. 예를 들어 사용자가 지난주에 브랜드 포스터 세트를 만들었고, 최종적으로 따뜻한 색 계열 시안을 골랐으며, 이후의 영상 제작은 잠시 미루기로 했다는 식입니다. 이 정보가 모두 장기 프로필에 들어갈 만한 것은 아니지만, 사용자가 다음에 그 프로젝트를 다시 꺼낼 때 쓸모가 있을 수 있습니다.

사용자 프로필은 훨씬 절제해야 합니다. 비교적 안정적인 소수의 정보만 담아, 사용 기간이 길어지면서 또 하나의 끝없이 불어나는 대화 이력이 되지 않도록 해야 합니다.

실제로 리콜할 때 시스템은 현재 작업의 목표와 권한에 따라 모델에 제공할 기억을 고르며, 매 라운드 전체 이력을 불러올 필요가 없습니다.

여기에는 중요한 원칙이 하나 더 있습니다. 기억은 사용자가 명확히 표현한 사실과 모델 자신의 추측을 구분해야 합니다.

예를 들어 사용자가 사이버펑크 이미지를 몇 장 연달아 생성했다고 해서, Agent가 그 사용자가 사이버펑크 스타일을 오래 선호한다고 추론할 수 있습니다. 이는 후보 판단은 될 수 있어도, 사용자가 명확히 표현한 선호와 같은 것으로 취급할 수는 없습니다.

마찬가지로 웹 페이지 내용, 도구 반환 결과, Agent가 직접 만든 요약도 확실한 근거 없이 사용자 개인에 관한 사실로 다시 포장되어서는 안 됩니다.

7.2 기존 기억 아키텍처에서 얻은 영감

장기 기억을 설계하면서 몇 가지 서로 다른 기술 노선을 참고했습니다.

OpenClaw의 기억 방식은 점검하고 유지보수할 수 있는 저장 방식, 그리고 기억과 원본 컨텍스트 사이의 관계를 강조합니다. 투명성이 높아 사용자나 개발자가 무엇이 저장되었는지 확인하기 쉽다는 장점이 있지만, 기억 규모가 계속 커지면 검색, 유지보수, 충돌 처리에 별도의 메커니즘이 필요합니다.

Mem0는 대화에서 가치 있는 정보를 추출하고, 이후 상호작용에서 검색을 통해 관련 기억을 되살리는 데 더 집중합니다. 이 방식은 오랜 기간, 여러 주제에 걸쳐 쓰이는 에이전트에 잘 맞지만, 기억의 품질이 추출 정확도와 리콜 전략에 크게 좌우됩니다. 임시 지시를 장기 선호로 잘못 판단하면 이후 검색이 오히려 오류를 계속 증폭할 수 있습니다.

Zep / Graphiti는 또 다른 접근을 보여 줍니다. 기억 안에서 엔티티 관계와 시간 정보를 명시적으로 유지하는 것입니다. 이는 계속 바뀌는 사실을 다룰 때 특히 가치가 있습니다. 예를 들어 어떤 브랜드가 예전에는 파란색을 메인 컬러로 썼다가 나중에 초록색으로 바꿨다면, 두 기록은 반드시 서로 모순되는 것이 아니라 각각 다른 유효 기간에 대응하는 것일 수 있습니다.

다만 시간적 관계와 지식 그래프는 엔티티 정규화, 관계 갱신, 충돌 처리, 검색 비용 등 더 높은 유지보수 복잡도를 함께 가져옵니다.

Lomo Agent의 창작 시나리오에 비추어 저희는 세 가지 질문에 더 집중했습니다.

1. 사용자 선호에 신뢰할 수 있는 출처가 있는가

2. 과거 사실이 여전히 유효한가

3. 사용자가 정보를 정정하거나 철회했을 때 관련 기억이 함께 갱신되는가

그래서 일반적인 계층형 저장과 시맨틱 검색 외에도, 기억마다 출처, 버전, 파생 관계를 유지합니다.

7.3 ‘잊기’가 ‘기억하기’보다 어려운 이유

장기 기억에는 놓치기 쉬운 문제가 또 하나 있습니다. 사용자가 어떤 내용을 잊어 달라고 명확히 요청하면 시스템은 어떻게 처리해야 할까요?

사용자가 처음에 이렇게 말했다고 해 봅시다. “우리 브랜드의 메인 컬러는 파란색이에요.”

나중에 이렇게 덧붙입니다. “파란색에 아이보리를 매치하면 전체적으로 좀 더 부드러워질 거예요.”

기억 시스템은 두 표현을 합쳐 새로운 브랜드 선호 하나로 정리할 수 있습니다.

“이 브랜드는 파란색과 아이보리 조합을 선호하며, 전체 비주얼은 부드러운 스타일을 지향한다.”

이후 사용자가 처음의 파란색 설정을 잊어 달라고 하면, 첫 번째 원자적 기억만 지우는 것으로는 분명히 부족합니다. 통합된 버전에 관련 정보가 여전히 남아 있기 때문입니다.

시스템이 계속 돌아가면서 이 정보는 에피소드 요약과 사용자 프로필에 들어가거나, 다른 파생 기억에 합쳐질 수도 있습니다.

그래서 기억마다 출처와 파생 관계를 유지해, 어떤 기억이 어떤 과거 증거와 이전 버전에서 발전해 왔는지를 기술합니다.

flowchart TD
    U["사용자가 잊을 내용을 지정"] --> A["관련 증거의 기억 사용 자격 철회"]
    A --> B["영향받는 기억 버전 찾기"]
    B --> C["파생 관계를 따라 후속 버전 탐색"]
    C --> D["영향받은 내용 비활성화, 아직 유효한 증거 확인"]
    D --> E["남은 유효 증거로 다시 추출"]
    E --> F["원자적 기억, 요약, 사용자 프로필 갱신"]
    F --> G["관련 검색 인덱스와 컨텍스트 캐시 무효화"]

그림 8: 기억 철회 흐름.

실제 구현에서는 버전 체인으로 기억이 발전해 온 과정을 관리합니다. 앞의 브랜드 메인 컬러를 예로 들면, 처음 파란색에 관한 표현은 유효 버전 v1이 되고 원본 증거(ORIGIN)와 연결됩니다. 사용자가 아이보리 매치 요구를 덧붙이면 시스템은 새 버전 v2를 만들고, 기존 버전을 SUPERSEDED로 표시하는 동시에 새로 추가된 보정 증거(REFINE)를 기록합니다. 이후 기존 결론을 확인하기만 하는 경우라면 CONFIRM으로 기록하면 되고, 기억을 새로 만들 필요는 없습니다.

사용자가 처음의 파란색 설정을 잊어 달라고 하면, 시스템은 해당 증거의 사용 자격을 철회하고 버전 관계를 따라 영향받는 기억을 찾아냅니다. 그 증거에 의존하는 버전은 삭제되고 내용이 비워진 뒤, 남은 유효 증거로 다시 추출됩니다. 확인 역할만 하던 증거는 연결만 풀면 되므로, 독립적으로 성립하는 기억에는 영향을 주지 않습니다.

이 철회 과정은 사용자 프로필과 에피소드 요약으로도 전파됩니다. 관련 프로필 항목이 무효가 되면 시스템은 프로필 버전을 갱신해 이후 추론에서 이전 스냅숏을 쓰지 않게 하고, 영향받은 요약은 다시 구축해야 합니다. 동시에 해당 검색 벡터를 삭제하고 삭제된 내용이 다시 추출되지 않도록 억제해, 이전 정보가 컨텍스트에 다시 들어올 위험을 줄입니다.

주의할 점은 이미 보낸 모델 요청은 즉시 철회할 수 없다는 것입니다. 그래서 응답과 도구 결과가 어떤 메시지와 기억을 근거로 했는지도 추적해, 이후 추론에서 영향받은 파생 내용을 제외합니다. 잊힌 정보가 Agent 자신의 과거 출력을 통해 다시 들어오는 일을 막기 위해서입니다.

여기서 말하는 ‘잊기’는 주로 장기 기억과 그 파생 컨텍스트의 사용 자격을 대상으로 하며, 원본 채팅 기록, 생성된 소재, 거래 데이터를 모두 삭제하는 것과는 다릅니다. 후자는 별개의 데이터 생명주기와 개인정보 관리 문제에 속하므로 따로 처리해야 합니다.

7.4 기억의 신뢰성과 기능 축소(Graceful Degradation) 전략

출처 추적과 버전 관리는 기억 시스템의 통제 가능성을 높여 주지만, 모델의 이해 오류를 완전히 없애 주지는 못합니다.

예를 들어 하나의 대화에 여러 후보 사실이 동시에 들어 있을 수 있는데, 그중 하나는 저장 조건을 충족하고 다른 하나는 모델이 잘못 이해한 임시 지시일 수 있습니다. 추출 결과 전체를 쪼갤 수 없는 하나의 덩어리로 취급하면, 한 건의 이상 때문에 다른 유효한 기억까지 영향을 받을 수 있습니다.

그래서 후보 기억은 하나씩 검증하고 처리하며, 출처가 뒷받침하지 않는 경우, 내용이 충돌하는 경우, 출력 형식이 이상한 경우를 구분합니다.

기억 서비스에 장애가 나더라도 정상적인 창작 작업이 완전히 멈춰서는 안 됩니다.

예를 들어 리콜이 타임아웃되면 기억 보강을 잠시 건너뛸 수 있고, 백그라운드 추출이 실패하면 나중에 다시 처리할 수 있으며, 후보 하나의 형식이 이상하다고 해서 다른 유효한 기록까지 함께 잃을 필요는 없습니다.

이런 기능 축소 전략 때문에 Agent가 때로는 과거 선호를 온전히 활용하지 못할 수 있지만, 현재 브리프와 기존 실행 상태를 바탕으로 계속 일할 수는 있습니다.

문제가 있는 기억 결과 하나가 작업 전체에 영향을 주게 두기보다는, 정상 실행 경로를 지키고 기억이 복구된 뒤에 관련 배경을 다시 제공하는 쪽을 택합니다.

장기 기억의 가치는 결국 실제 협업으로 검증해야 합니다. 리콜 정확도뿐 아니라 기억이 낡지 않았는지, 출처를 설명할 수 있는지, 사용자가 정정이나 철회를 마친 뒤에도 이전 정보가 이후 결정에 계속 영향을 주지는 않는지도 살핍니다.

클릭하여 확대

기억과 작업 컨텍스트가 갖춰지면서 Agent는 시간을 넘나드는 배경 정보를 얻을 수 있게 되었습니다. 하지만 사용자가 과거에 무엇을 했는지 안다고 해서 지금 작업을 계속해야 하는지 판단할 수 있는 것은 아닙니다.

여러 창작 단계로 이루어진 작업이라면 명확한 실행 계획, 중지 조건, 사용자 권한 부여의 경계도 필요합니다. 이것이 다음 장의 자율 진행 메커니즘이 풀어야 할 문제입니다.

8. 자율 진행: 계획, 중지 조건, 사용자 권한 부여

앞의 메커니즘들 덕분에 Agent는 장기 작업을 유지하고, 중단된 실행을 복구하고, 필요할 때 과거 정보를 되찾을 수 있게 되었습니다. 하지만 계속 진행해야 하는 창작 목표에는 아직 풀리지 않은 문제가 있습니다. Agent는 자신이 계속 일해야 하는지를 어떻게 판단할까요?

예를 들어 사용자가 브랜드 숏필름 제작을 요청했다고 해 봅시다. Agent는 대본과 스토리보드를 마친 뒤 요약을 하나 남기고 현재 라운드를 끝낼 수 있습니다. 모델이 잘못한 것은 아닙니다. 현재 단계의 일은 분명히 끝냈습니다. 하지만 사용자가 최종적으로 원하는 완성 영상까지는 아직 갈 길이 멉니다.

초기 데모와 시나리오 리허설에서 이런 상황을 겪었습니다. 사용자가 “계속”을 몇 번이고 보내야 Agent가 다음 단계로 넘어갔습니다.

반대로 모델에게 “모든 작업을 끝내기 전에는 멈추지 마”라고 단순하게 요구하면 또 다른 문제가 생기기 쉽습니다. Agent가 이미 실패한 조작을 반복해서 시도하거나, 필요 없는 소재를 계속 생성하거나, 사용자 확인 없이 창작 범위를 스스로 넓힐 수 있습니다. 그래서 작업 목표와 실행 진행 상황을 단일 라운드의 모델 응답에서 떼어 내고, 자동 진행의 경계는 런타임이 통제하도록 해야 했습니다.

8.1 계획을 지속적으로 유지되는 실행 체크리스트로 바꾸기

저희는 Execution Checklist(구조화된 실행 체크리스트)를 도입해, 창작 목표 하나가 계획부터 납품까지 거치는 주요 단계를 기록합니다.

모델이 채팅에서 만들어 내는 일반적인 TodoList와 달리, 실행 체크리스트는 시스템이 영속적으로 관리하는 구조화된 상태입니다. 각 단계는 실행 상태, 산출물, 완료 근거, 필요한 사용자 확인 요건과 연결될 수 있습니다.

예를 들어 브랜드 숏필름 제작은 다음과 같이 구성할 수 있습니다.

사용자가 실행안을 승인하면 체크리스트는 이후 진행의 근거가 됩니다. Worker는 현재 단계에 맞춰 계획하고 도구를 호출하며, 런타임은 각 실행 라운드가 끝날 때마다 진행 상황을 확인할 수 있습니다.

주의할 점은 실행 체크리스트가 바꿀 수 없는 고정 계획이 아니라는 것입니다.

창작 과정은 자주 바뀝니다. 예를 들어 사용자가 컷 생성 단계에서 캐릭터 설정을 바꾸기로 하면, 기존 단계와 일부 산출물을 다시 조정해야 할 수 있습니다. 이때 시스템은 사용자의 새 지시에 따라 계획을 갱신하고, 단계와 산출물 사이의 연결을 유지해야 합니다.

실행 체크리스트가 해결하는 것은 목표와 진행 상황의 지속성입니다. 덕분에 Agent는 컨텍스트 압축, 비동기 대기, 프로세스 복구를 거친 뒤에도 현재 작업이 어디까지 실행되었는지 찾아낼 수 있습니다.

8.2 모델이 출력을 멈춘 뒤에도 작업을 계속해야 할까

계획을 영속화하고 나면 더 구체적인 질문에 답해야 합니다. 모델이 현재 라운드를 마쳤을 때 런타임은 어떻게 처리해야 할까요?

이 메커니즘을 설계하면서 Codex Goals와 Claude Code Hooks의 접근 방식을 참고했습니다.

Codex Goals는 목표와 지속 실행 상태를 결합해 Agent가 아직 끝나지 않은 목표를 중심으로 계속 나아가게 합니다. Claude Code의 Stop Hook은 모델이 멈추려 할 때 추가 검사를 실행하고, 그 결과에 따라 현재의 중지 동작을 막을지 결정할 수 있게 합니다.

두 설계에서 얻은 깨달음은 이렇습니다. 모델이 응답 하나를 끝냈다고 해서 작업 전체가 끝났다는 뜻은 아닙니다. 런타임에는 독립된 목표 상태와 중지 검사 메커니즘이 필요합니다.

다만 코드 Agent와 창작 Agent는 완료 기준이 분명히 다릅니다.

코드 작업에서는 테스트 통과, 빌드 성공, 예상한 파일 수정 완료 같은 것이 비교적 명확한 실행 근거가 됩니다. 반면 창작 작업에는 통일된 객관적 기준이 있기 어렵습니다. 영상 하나가 성공적으로 생성되었다고 해서 캐릭터 일관성, 컷의 리듬, 전체 비주얼이 사용자의 기대에 맞는다는 뜻은 아닙니다.

그래서 흐름 진행과 작품 검수를 분리해 처리합니다.

앞의 것은 실행 체크리스트, 도구 호출 기록, 산출물 상태로 판단할 수 있고, 뒤의 것은 멀티모달 이해, 구체적인 작업 요구사항, 필요한 경우 사람의 검토를 함께 거쳐야 합니다.

런타임은 각 실행 라운드가 끝날 때마다 현재 작업에 아직 진행할 단계가 남았는지, 외부 대기가 있는지, 사용자 확인이 필요한지, 실행 한도에 도달했는지를 확인합니다.

flowchart TD
    E["현재 실행 라운드 종료"] --> A{"실행 체크리스트가 완료되었는가?"}
    A -->|예| END["실행 종료, 결과 표시 또는 검수로"]
    A -->|아니요| B{"작업이 일시 중지, 막힘 또는 한도 초과 상태인가?"}
    B -->|예| STOP["자동 진행 중지, 이유 기록"]
    B -->|아니요| C{"외부 이벤트를 기다리는 중인가?"}
    C -->|예| WAIT["일시 중단, 해당 이벤트 대기"]
    C -->|아니요| D{"사람이 확인하는 체크포인트에 도달했는가?"}
    D -->|예| GATE["확인 또는 선택 카드 표시"]
    D -->|아니요| F{"실질적인 진전이 있는가?"}
    F -->|아니요| LIMIT["자동 계속 실행 중지, 헛돌기 방지"]
    F -->|예| NEXT["다음 Worker 실행 라운드 스케줄링"]
    NEXT --> E

그림 9: 런타임은 모델이 출력을 끝냈는지에만 기대지 않고, 영속화된 작업 상태를 바탕으로 실행을 계속할지 결정합니다.

여기서 특히 주의해야 할 것은 실질적 진전(Meaningful Progress)입니다.

예를 들어 쓸 수 있는 창작 산출물이 새로 생겼거나, 체크리스트의 한 단계를 마쳤거나, 새 생성 작업을 성공적으로 제출했다면 모두 실행 진전의 근거로 삼을 수 있습니다.

하지만 Agent가 계획 설명만 거듭 고치거나 단계 상태를 ‘할 일’에서 ‘진행 중’으로 바꾸기만 할 뿐 새로운 유효한 결과를 내지 못한다면, 끝없이 계속 실행되어서는 안 됩니다.

진전 확인과 실행 한도를 통해 이런 헛돌기로 생기는 추론 비용을 최대한 줄이고 있습니다.

물론 이런 판단에도 한계가 있습니다. 새 소재를 생성했다는 것은 시스템이 조작을 실행했다는 증거일 뿐, 소재의 품질이 기준을 충족한다는 증거는 아닙니다. 더 완전한 멀티모달 품질 검수는 앞으로도 계속 탐구해야 할 방향입니다.

8.3 Human-in-the-Loop: 핵심 결정에는 사용자가 참여하도록

창작 과정에서 사용자는 반복적인 조작은 Agent에게 맡기면서도 핵심 창작 방향에 대한 통제권은 쥐고 있기를 원하는 경우가 많습니다.

예를 들어 브랜드 비주얼 방향, 캐릭터 설정, 스토리보드 구성, 최종 컷 선택은 대개 주관성이 강합니다. Agent가 이런 지점에서 스스로 결정하고 생성을 이어 가면, 이후 쓸모없는 비용이 대량으로 생길 수 있습니다.

그래서 Human-in-the-Loop Checkpoint(사람이 확인하는 체크포인트)를 도입해, 사용자 참여가 필요한 단계에서는 자동 진행을 멈춥니다.

체크포인트에 도달하면 Agent는 구조화된 카드로 현재 시안, 후보 결과, 권장 조작을 보여 줄 수 있습니다. 사용자가 ‘확인하고 계속’ 또는 ‘시안 조정’을 바로 고르면, 시스템은 그 명확한 조작 결과에 따라 작업 상태를 갱신합니다.

클릭하여 확대

이런 상호작용은 Claude Code 같은 제품의 권한 확인 방식도 참고했습니다. 뚜렷한 부수 효과가 있는 조작이라면 시스템이 실행 내용을 사용자에게 미리 알리고, 계속할지는 사용자가 결정하는 방식입니다.

다만 창작 시나리오에서 사람의 확인은 권한 문제만이 아니라 미적 판단과 창작 방향의 문제이기도 합니다. 사용자가 Agent에게 영상 생성 권한을 줬더라도, 컷 설계가 끝난 뒤에는 직접 시안을 고르고 싶어 할 수 있습니다. 그래서 체크포인트는 독립된 실행 상태로 저장해야 하며, 모델이 응답에서 ‘확인을 기다리는 중’이라고 말하는 것에만 의존해서는 안 됩니다.

개발 단계의 리허설에서 실제로 비슷한 문제를 겪었습니다. Agent가 이미 사용자 확인이 필요한 단계에 들어갔는데도 “계속할지 확인해 주세요”라고 답하기만 하고 바로 조작할 수 있는 확인 카드를 내놓지 않아, 사용자가 “계속”을 다시 입력해야 했습니다.

그래서 런타임에 안전장치를 추가했습니다. 작업이 체크포인트에 멈춰 있는데 모델이 그에 맞는 질문을 하지 않으면, 시스템이 확인 카드를 자동으로 보충합니다. 사용자 승인 후에 실행되는 생성의 경우, 실행 체크리스트에 아직 남은 단계가 있으면 생성이 끝난 뒤 작업을 자동으로 깨웁니다. 이렇게 하면 확인 대기와 실행 재개가 모델의 상호작용 행동에만 의존하지 않고, 런타임이 작업 상태에 따라 조율하게 됩니다.

물론 체크포인트가 있다고 해서 모든 단계에 사용자가 개입해야 한다는 뜻은 아닙니다. 되돌릴 수 없거나 권한 범위를 넘는 조작에는 시스템이 항상 명확한 확인을 요구하지만, 반복적이고 위험이 낮은 단계는 권한 범위 안에서 연속으로 진행해, 확인이 너무 잦아 창작 흐름이 끊기는 일을 피합니다.

8.4 자율 수준, 예산, 권한 부여의 경계

AI 창작 플랫폼에서 Agent는 여러 모델 제공사의 텍스트, 이미지, 영상, 오디오, 3D 같은 생성 기능을 호출할 수 있으며, 이런 조작에는 대개 실제 비용이 따릅니다. 그래서 자율 수준과 예산 통제는 따로 설계해야 합니다.

사용자가 Agent의 자동 실행을 허용했다고 해서 유료 모델을 무제한 호출하는 데 동의한 것은 아닙니다. 마찬가지로 사용자가 예산 한 건을 승인했다고 해서 모든 조작이 검토를 건너뛰어도 된다는 뜻도 아닙니다.

런타임에서는 세 가지 차원을 각각 관리합니다.

예를 들어 사용자가 영상 세 편 제작을 승인하고, Agent가 예산 범위 안에서 자동으로 끝내도록 허용했다고 해 봅시다.

실행 중에 캐릭터 참고 이미지를 추가로 만들어야 한다는 것을 알게 되면, Agent는 이 조작이 기존 계획과 예산에 포함되는지 판단할 수 있습니다. 실행 범위를 넓히거나 비용을 늘려야 한다면 사용자에게 다시 확인을 요청해야 합니다.

여기에는 중요한 보안 경계가 있습니다. 모델이 제안한 계획도, 모델이 주장하는 권한도 그 자체로 실제 사용자 권한이 될 수는 없습니다.

시스템은 인터페이스에서 사용자가 한 명확한 조작과, 서버에 저장된 권한 상태를 근거로 판단해야 합니다.

도구마다 실제 부수 효과에 맞춰 서로 다른 통제 전략도 적용해야 합니다.

• 읽기 전용 조회는 대체로 위험이 낮습니다.

• 문서 쓰기는 버전과 권한을 처리해야 합니다.

• 유료 생성은 예산을 확인해야 합니다.

• 소재 삭제나 기억 철회처럼 되돌릴 수 없는 조작에는 더 엄격한 확인 메커니즘을 적용해야 합니다.

Coding Agent와 비교하면 창작 플랫폼의 Agent에는 특수한 제약이 하나 더 있습니다. 많은 외부 생성 조작은 일단 제출되면 이미 비용이 발생했을 수 있고, 사용자가 이후에 작업을 멈추더라도 완전히 되돌릴 수 있다는 보장이 없습니다. 그래서 예산과 권한 확인은 실제로 부수 효과가 생기기 전에 이루어져야 하며, 앞에서 소개한 내구성 실행 메커니즘과 결합되어야 합니다.

지금까지의 실천을 보면 자율 실행의 어려움 역시 언제 멈춰야 하는지를 판단하는 데 있습니다. 잔액 부족, 사용자의 일시 중지, 외부 작업 대기, 필요한 사람의 검토, 또는 연속 실행에서 유효한 진전이 없는 경우를 만나면, 런타임은 현재 상태를 보존해 두었다가 조건이 충족된 뒤에 재개해야 합니다.

이는 자율 수준이 높을수록 좋은 것이 아니라는 뜻이기도 합니다. 창작 작업마다 위험, 비용, 검증 가능성이 뚜렷하게 다르므로, Agent는 사용자가 허용한 범위 안에서 불필요한 개입을 최대한 줄이면서도 핵심 지점에서는 사용자의 통제권을 남겨 둬야 합니다.

더 장기적으로는 멀티모달 품질 평가를 통해 시스템이 캐릭터 일관성, 컷의 연속성, 시각 효과를 더 정확하게 판단하게 하고 싶습니다. 자동 검수 능력이 점점 갖춰지면, 원래 사람이 확인해야 했던 일부 단계도 Agent에게 자율적으로 맡길 수 있을 것입니다.

물론 지속적인 협업에는 작업 실행 밖의 또 다른 문제도 있습니다. 사용자는 대화를 거치지 않고 워크스페이스에서 작품을 직접 고칠 수 있습니다. Agent와 사용자가 같은 문서나 워크플로를 동시에 편집할 때, 시스템은 어떻게 상태 일관성을 유지해야 할까요?

이를 위해서는 공유 워크스페이스가 작업 실행과 별개로, 사람과 Agent가 작품에 함께 접근하고 수정할 수 있도록 유지해야 합니다.

9. Shared Workspace: 사용자와 Agent가 같은 작품을 함께 수정하도록

앞에서 다룬 메커니즘은 주로 Agent가 작업을 이해하고, 컨텍스트를 유지하고, 일을 계속 진행하는 방법에 관한 것이었습니다. 하지만 실제 창작 과정에서 사용자와 Agent의 협업은 채팅 창 안에서만 일어나지 않습니다.

예를 들어 Agent가 스토리보드에 따라 영상을 생성하는 동안, 사용자는 오른쪽 워크스페이스에서 어떤 컷의 프롬프트를 고치거나, 참고 소재를 바꾸거나, Flows 워크플로의 모델 노드를 수정할 수 있습니다.

이런 조작은 대화를 거치지 않았지만 작품을 분명히 바꿔 놓습니다. Agent가 여전히 이전 컨텍스트에 따라 실행을 이어 가면, 만료된 파라미터를 쓰거나 사용자가 방금 마친 수정을 덮어쓸 수도 있습니다.

그래서 Lomo Agent에서는 창작 산출물을 대화와 작업 컨텍스트로부터 독립된 영속 객체로 다루고, Shared Workspace(공유 워크스페이스)를 통해 사람과 Agent의 협업을 구성합니다.

9.1 작품에 독립된 생명주기를 부여하기

전통적인 대화형 Agent에서 생성 결과는 대개 특정 채팅 메시지에 붙어 있습니다. 사용자는 보고, 다운로드하고, 후속 질문을 할 수 있지만, 대화가 길어질수록 작품의 관리와 이후 수정은 점점 세션 구조의 제약을 받습니다.

반면 Lomo의 창작 흐름에는 이미지, 영상, 3D 에셋, 스토리보드 문서, 소재 세트, Flows 비주얼 워크플로처럼 오래 관리해야 하는 객체가 많습니다.

이런 객체에는 안정적인 아이덴티티, 버전, 접근 권한이 있어야 하며, 사용자가 직접 편집할 수도 있고 여러 작업에서 참조할 수도 있어야 합니다.

그래서 대화 컨텍스트와 창작 산출물을 따로 관리합니다.

• 대화와 작업 컨텍스트는 사용자 의도, 실행 과정, Agent가 현재 파악하고 있는 정보를 유지합니다.

• 공유 워크스페이스는 계속 편집하고 납품해야 하는 실제 작품을 저장하며, 객체 아이덴티티, 내용, 버전, 관련 참조를 포함합니다.

예를 들어 사용자가 처음에는 Main에서 브랜드 숏필름의 스토리보드를 논의하고, 이후에는 영상 제작 작업이 이를 이어받아 진행합니다. 두 실행 공간은 권한이 허용하는 범위 안에서 같은 스토리보드 문서를 참조할 수 있으며, 각자 사본을 만들 필요가 없습니다.

마찬가지로 어떤 영상 생성 작업이 끝난 뒤에도 그 산출물은 새 워크플로에서 참조할 수 있고, 원래 Worker가 계속 실행 중인지와는 상관이 없습니다.

이 설계 덕분에 작품은 단일 대화 라운드나 단일 작업의 생명주기를 넘어 존재할 수 있고, 이후의 소재 재사용과 다중 작업 협업을 위한 기반도 마련됩니다.

9.2 워크스페이스의 변화를 Agent가 알아차리도록

공유 객체는 작품을 어떻게 저장할지의 문제를 해결하지만, 풀어야 할 문제가 하나 더 있습니다. 작품이 수정되었다는 사실을 Agent는 어떻게 알 수 있을까요?

Agent가 스토리보드 문서를 읽고, 그 안의 컷 설명에 따라 생성을 이어 가려 한다고 해 봅시다. 바로 그때 사용자가 워크스페이스에서 두 번째 컷의 내용을 직접 수정합니다.

시스템이 채팅 메시지만 기록한다면, Agent의 다음 추론 라운드는 이 수정을 알 수 없습니다.

그래서 공유 객체마다 버전 정보를 유지하고, 관련 작업이 마지막으로 그 객체를 읽거나 수정했을 때 본 버전을 기록합니다.

문서, 소재, 워크플로가 바뀌면 시스템은 연관된 작업에 영속적인 변경 알림을 남길 수 있습니다. 예를 들면 다음과 같습니다.

스토리보드 문서가 v3에서 v4로 갱신되었고, 두 번째 컷의 설명이 바뀌었습니다. 실행을 계속하기 전에 최신 버전을 읽어 주세요.

여기서 워크스페이스 편집이 일어날 때마다 즉시 Agent 추론을 트리거하는 방식은 택하지 않았습니다.

이유는 간단합니다. 사용자가 워크플로를 조정할 때는 노드를 연달아 끌어 옮기고, 파라미터를 바꾸고, 소재를 교체할 수 있습니다. 변화가 생길 때마다 Worker를 깨우면 의미 없는 모델 호출이 대량으로 생길 뿐 아니라, 사용자가 편집을 마치기도 전에 Agent가 거듭 끼어들 수 있습니다.

그래서 변경 알림은 주로 Agent가 다음 실행 때 자신의 정보가 낡았다는 것을 알아차리게 하는 데 쓰입니다. 관련 작업을 실제로 계속 진행해야 할 때에만, 런타임이 현재 상태를 보고 실행을 재개할지 결정합니다.

Flows 같은 비주얼 워크플로의 경우에도 Agent가 매 추론 라운드마다 전체 노드 데이터를 읽을 필요는 없습니다. 시스템이 먼저 간단한 변경 정보를 제공하고, 모델이 해당 노드를 실제로 다뤄야 할 때 최신 내용을 필요한 만큼 가져오면 됩니다.

이런 처리 방식은 앞에서 소개한 컨텍스트 엔지니어링과도 이어집니다. 워크스페이스는 작품의 전체 상태를 보관하고, 컨텍스트는 현재 결정에 필요한 정보만 제공합니다.

9.3 버전 충돌과 낙관적 동시성 제어

변화를 알아차릴 수 있다고 해서 동시 수정의 안전성까지 보장되는 것은 아닙니다.

좀 더 구체적인 시나리오를 생각해 보겠습니다.

Agent가 스토리보드 문서 v3을 읽고 세 번째 컷을 조정하려 합니다. 그와 동시에 사용자가 같은 문서를 직접 편집해 v4로 저장합니다.

이후 Agent가 v3을 바탕으로 만든 수정을 그대로 커밋하면, 사용자가 v4에서 방금 마친 내용을 덮어쓸 수 있습니다.

이를 위해 Optimistic Concurrency Control(낙관적 동시성 제어)을 사용합니다.

Agent는 객체를 읽을 때 현재 버전을 받고, 수정을 커밋할 때 근거로 삼은 버전 정보를 함께 보내야 합니다. 서버는 쓰기 전에 객체가 여전히 예상한 버전인지 확인합니다.

버전이 일치하면 수정이 정상적으로 커밋되고, 객체가 이미 갱신되었다면 시스템은 새 내용을 덮어쓸 수 있는 조작을 거부하고 Agent에게 최신 상태를 다시 읽도록 요구합니다.

다만 창작 객체의 종류에 따라 버전 충돌을 판단하는 단위는 서로 다릅니다.

문서의 경우, 전체를 다시 쓸 때는 근거로 삼은 버전을 함께 보내야 합니다. 사용자가 이미 문서를 수정했다면 시스템은 덮어쓰기를 거부합니다. 부분 수정은 정확하고 유일한 텍스트 조각으로 위치를 지정하며, 예상한 치환이 모두 성립할 때만 커밋됩니다.

Flows 워크플로에는 더 세밀한 충돌 검사를 적용했습니다. 사용자가 어떤 컷 노드를 조정하는 동안 Agent는 다른 노드를 수정하고 있을 수 있습니다. 워크플로가 조금이라도 바뀌면 무조건 커밋을 거부한다면, 잦은 자동 저장 때문에 양쪽이 병렬로 편집하기가 매우 어려워집니다. 그래서 시스템은 주로 Agent가 수정하려는 노드가 바뀌었는지를 검사합니다. 같은 노드를 사용자가 이미 수정했다면 Agent에게 다시 읽도록 요구하고, 변화가 다른 노드에서 일어났다면 충돌하지 않는 수정을 최신 워크플로에 적용하도록 허용하면서 관련 변화를 Agent에게 알려 줍니다.

이는 같은 내용에 대한 양쪽의 서로 다른 수정을 자동으로 병합하는 것이 아닙니다. 적절한 버전 단위를 통해 서로 충돌하지 않는 편집은 최대한 독립적으로 마칠 수 있게 하면서, 낡은 상태가 새 내용을 덮어쓰는 일은 막는 것입니다.

sequenceDiagram
    participant A as Agent
    participant O as 공유 작품
    participant U as 사용자

    A->>O: 스토리보드 문서 v3 읽기
    U->>O: 스토리보드를 수정해 v4로 저장
    O-->>A: 버전 변경 알림 기록
    Note over O,A: 변경 알림은 다음 실행 때 읽힘

    A->>O: v3 기준으로 수정 커밋
    O-->>A: 버전 충돌, 덮어쓰기 거부
    A->>O: v4 다시 읽기
    A->>A: 최신 내용에 맞춰 수정안 조정
    A->>O: v4 기준으로 다시 커밋

그림 10: 공유 작품의 버전 관리.

여기에는 서로 맞물려 작동하는 두 메커니즘이 있습니다. 변경 알림은 Agent가 작품 갱신을 제때 알아차리게 하고, 버전 검증은 커밋 시점에 최종 보호를 제공합니다. 알림이 늦어지더라도 Agent는 만료된 상태로 사용자의 수정을 그대로 덮어쓸 수 없습니다.

물론 낙관적 동시성 제어가 해결하는 것은 상태 일관성이지, 창작 의도의 충돌이 아닙니다. 예를 들어 사용자는 컷에 차가운 색조를 쓰고 싶어 하는데, Agent는 여전히 원래 계획대로 따뜻한 색조를 쓰려 할 수 있습니다. 버전 충돌이 일어나지 않았더라도, 최종적으로 어느 안을 택할지는 최신 사용자 의도와 작업 제약을 함께 보고 판단해야 합니다.

9.4 Artifacts와 Canvas에서 공유 창작 공간으로

상호작용 설계에서는 Claude Artifacts와 ChatGPT Canvas 같은 제품의 접근 방식을 참고했습니다.

이 제품들은 생성된 콘텐츠를 일반 채팅 메시지에서 떼어 내, 사용자가 대화 옆에서 문서나 코드를 바로 보고 편집할 수 있게 합니다. 수정 디테일을 자연어로 거듭 설명해야 하는 비용을 줄여 주는 방식입니다.

이런 상호작용 방식은 Lomo Agent에 참고할 점이 많았습니다. 크리에이터는 모든 조작을 Agent에게 다시 설명하기보다, 노드 하나를 직접 끌어 옮기거나 스토리보드 한 대목을 고치거나 이미지 한 장을 바꾸고 싶어 할 때가 많습니다.

다만 Lomo Agent의 공유 워크스페이스는 일반적인 문서 편집과는 다른 시나리오도 처리해야 합니다.

한편으로는 창작 객체의 종류가 훨씬 복잡합니다. 텍스트 외에도 이미지, 영상, 3D 에셋, 노드 의존 관계를 가진 Flows 워크플로가 있습니다. 다른 한편으로는 같은 작품을 여러 작업이 참조할 수 있고, 비동기 생성 작업과 사용자의 직접 수정이 동시에 존재할 수 있습니다. 시스템이 유지해야 하는 것은 작품 내용만이 아니라, 버전, 연관된 작업, 그리고 실행 과정에서 작품 상태를 어떻게 인식하고 있는지까지입니다.

그래서 편집 가능한 워크스페이스를 Agent의 실행 상태와 연결해, 사용자는 작품을 직접 조작하고, Worker는 이후 실행 때 유효한 객체 상태를 다시 가져오도록 했습니다.

클릭하여 확대

지금까지의 실천을 보면 공유 워크스페이스가 가져온 중요한 변화 하나는, 사용자가 자연어와 직접 편집이라는 두 방식으로 같은 창작 과정에 참여할 수 있게 되었다는 점입니다. 하지만 그만큼 시스템이 상태 동기화와 동시성 제어의 책임을 더 많이 지게 되었습니다. 특히 소재 하나가 여러 작업에 동시에 영향을 줄 때, 객체 의존 관계를 어떻게 관리할지, 업스트림이 수정된 뒤 어떤 다운스트림 산출물을 다시 생성해야 할지는 여전히 저희가 탐구하고 있는 방향입니다.

10. 창작 기능 오케스트레이션: 모델 호출에서 완성된 작품 납품까지

Lomote AI 같은 창작 플랫폼에서 Agent가 마주하는 것은 도구를 어떻게 고르고 호출하느냐만이 아닙니다. 서로 다른 창작 기능 사이의 관계도 이해해야 합니다.

이미지 한 장을 생성하는 일은 비교적 간단하지만, 완성된 숏필름 하나를 만들려면 대본, 스토리보드, 캐릭터 설정, 장면 참고, 컷 생성, 후반 작업 등 여러 단계가 얽힐 수 있습니다. 단계마다 다른 모델을 쓸 수 있고, 앞 단계의 결과가 이후 제작에 직접 영향을 줍니다. 더 중요한 것은 개별 생성 작업이 성공했다고 해서 전체 창작 흐름이 순조롭게 끝난다는 뜻은 아니라는 점입니다.

예를 들어 Agent가 이런 제작안을 세웠다고 해 봅시다. 먼저 캐릭터와 배경을 생성하고, 인물을 배경에서 분리(누끼)한 다음, 지정한 영상 화면에 합성한다. 그런데 플랫폼에 현재 그에 맞는 배경 제거나 영상 합성 기능이 없다면, 앞에서 소재를 아무리 잘 생성했더라도 이 계획은 최종 작품으로 이어지지 못합니다.

그래서 Agent가 기획 단계에서부터 플랫폼이 실제로 갖춘 기능, 그리고 도구와 산출물 사이의 의존 관계를 이해하도록 해야 합니다.

10.1 Agent가 창작 흐름과 기능의 경계를 이해하도록

Lomote AI는 이미 다양한 이미지, 영상, 3D 생성·향상 모델을 통합했고, 소재 관리와 Flows 비주얼 워크플로도 제공합니다.

이 도구들은 각자 맞는 시나리오가 있으며, 모델마다 입력 조건, 생성 품질, 비용, 출력 형태도 다릅니다.

Agent가 도구를 고를 때는 현재 창작 목표, 기존 소재, 이후 제작 요구사항을 종합적으로 고려해야 합니다.

예를 들어 고정된 캐릭터가 나오는 숏필름을 만들 때, Agent는 캐릭터 레퍼런스를 어떻게 세울지, 어떤 모델이 참고 이미지 입력을 지원하는지, 컷마다 시각적 일관성을 어떻게 유지할지, 생성 결과가 이후 제작 흐름에 들어갈 수 있는지를 고려해야 합니다. 사용자의 최종 목표만 보고 곧바로 모델을 호출하면, 보기엔 괜찮지만 최종 작품에는 쓸 수 없는 중간 소재가 대량으로 생기기 쉽습니다.

이를 위해 창작 노하우와 도구 기능 제약을 필요할 때 읽을 수 있는 가이드로 정리했습니다. 캐릭터 일관성, 스토리보드 기획, 참고 소재 활용, 워크플로 오케스트레이션, 그리고 플랫폼이 현재 지원하는 제작 기능 등이 포함됩니다. 이 가이드는 관련 작업에서 Agent에게 제공되어 실행 가능한 창작 단계를 기획하도록 돕고, 모든 도메인 지식을 시스템 Prompt에 늘 넣어 둘 필요를 없애 줍니다.

이 설계는 앞에서 소개한 Context Engineering과도 맞물립니다. Agent는 현재 제작 단계에 따라 필요한 도구와 창작 지식을 가져오고, 실제 기능에 맞춰 기획과 실행을 마칩니다.

물론 모델이 도구 설명을 이해하는 데 기대는 방식에는 여전히 한계가 있습니다. 모델은 그럴듯해 보이지만 실제로는 완성할 수 없는 제작안을 내놓을 수 있습니다. 그래서 핵심 도구 기능, 입출력 제약, 실행 조건에 대해서는 여전히 시스템이 명확한 검증 근거를 제공해야 합니다.

10.2 ViMax로 본 멀티 에이전트 영상 제작

창작 기능 오케스트레이션을 탐구하면서 ViMax 같은 영상 생성용 멀티 에이전트 시스템도 살펴봤습니다.

ViMax는 대본, 캐릭터, 스토리보드, 컷 생성, 영상 조립을 하나의 제작 흐름으로 구성하고, 여러 역할이나 실행 단계의 협업으로 영상 창작에서 서로 얽힌 작업들을 처리합니다.

이 접근은 참고할 가치가 큽니다. 영상 제작은 본래 단계적이고, 단계마다 신경 써야 할 문제도 다릅니다. 대본 기획은 서사 구조에, 캐릭터 디자인은 시각적 일관성에 더 집중해야 하고, 컷 생성은 구체적인 모델의 입력 조건과 생성 효과를 고려해야 합니다.

전문화된 실행 분업을 통해 각 단계가 비교적 명확한 책임을 중심으로 일하게 할 수 있고, 복잡한 제작 흐름을 구성하는 데도 유리합니다.

하지만 이런 아키텍처에도 저울질해야 할 부분이 있습니다. 한편으로 멀티 Agent 협업은 컨텍스트 전달, 상태 동기화, 조율 비용을 늘립니다. 다른 한편으로 미리 정의된 제작 파이프라인이 사용자의 계속 바뀌는 창작 요구를 다 감당하지 못할 수도 있습니다.

Lomo Agent가 마주하는 시나리오는 훨씬 열려 있습니다. 사용자는 포스터 한 장만 필요할 수도 있고, 기존 소재로 영상을 만들고 싶을 수도 있고, Agent에게 Flows 워크플로를 바로 수정해 달라고 할 수도 있습니다. 모든 창작 요구에 고정된 멀티 Agent 파이프라인을 도입하면 오히려 불필요한 실행 계층만 늘어날 수 있습니다.

그래서 현 단계에서는 통합된 작업 실행 체계에 온디맨드로 로드되는 창작 가이드와 도구 기능을 결합해, Worker가 구체적인 목표에 맞춰 제작 단계를 구성하는 쪽을 택했습니다. 오래 관리해야 하는 복잡한 창작 작업에 대해서는 더 명확한 전문 분업과 작업 의존성 관리를 차근차근 탐구할 계획입니다. 이 트레이드오프는 앞에서 본 Main / Task 설계와도 일관됩니다. 독립 실행 공간이 실제 이득을 가져올 때에만 추가 조율 계층을 둘 가치가 있습니다.

10.3 제작 의존성 그래프: 선형 실행에서 의존성 관리로

현재 구조화된 실행 체크리스트는 Agent가 창작 진행 상황을 유지하는 데 도움이 되지만, 서로 얽힌 소재와 생성 단계가 많은 작업에서는 선형 체크리스트 구조에 한계가 있습니다.

예를 들어 숏필름 하나에 여러 컷이 들어 있고, 이 컷들이 같은 캐릭터 설정을 공유하면서도 서로 다른 장면과 생성 모델을 쓸 수 있습니다.

어떤 컷은 독립적으로 생성할 수 있지만, 어떤 컷은 업스트림 참고 소재가 완성될 때까지 기다려야 합니다. 사용자가 중간에 캐릭터 외형을 바꾸면 관련 컷은 다시 생성해야 할 수 있지만, 전혀 상관없는 장면에는 영향을 주지 않아야 합니다.

이런 관계는 Production DAG(제작 방향성 비순환 그래프)로 표현하는 편이 더 적합합니다.

flowchart LR
    BR["창작 요구"] --> SCRIPT["대본 / 스토리보드"]

    SCRIPT --> CHAR["캐릭터 설정"]
    SCRIPT --> SCENE["장면 설정"]

    CHAR --> SHOT1["컷 1"]
    CHAR --> SHOT2["컷 2"]

    SCENE --> SHOT1
    SCENE --> SHOT2

    SHOT1 --> REVIEW["검수와 조합"]
    SHOT2 --> REVIEW

    REVIEW --> FINAL["최종 납품"]

그림 11: 구상 중인 제작 의존성 그래프.

이런 구조에서 각 노드는 하나의 제작 단계나 중간 산출물을 나타내고, 노드 사이의 연결은 의존 관계를 나타냅니다.

이 관계를 한 단계 더 구조화하면 시스템은 몇 가지 능력을 갖출 수 있습니다.

• 의존성 스케줄링: 필요한 업스트림 소재가 준비된 뒤에만 해당 다운스트림 단계를 실행합니다.

• 병렬 생성: 직접적인 의존 관계가 없는 컷은 리소스와 예산이 허락하는 범위에서 병렬로 실행할 수 있습니다.

• 변경 전파: 캐릭터나 장면 설정이 바뀌면 영향을 받을 수 있는 다운스트림 결과를 찾아내, 무차별적으로 다시 생성하는 일을 피합니다.

• 증분 제작: 여전히 유효한 소재와 생성 결과를 최대한 재사용해 중복 호출과 불필요한 제작 비용을 줄입니다.

다만 의존성 그래프는 추가적인 엔지니어링 복잡도도 가져옵니다. 특히 창작 작업의 의존 관계는 완전히 확정적이지 않을 수 있어서, 어떤 업스트림 소재가 바뀐 뒤 다운스트림 결과를 반드시 다시 생성해야 하는지는 수정 범위와 구체적인 제작 요구를 함께 보고 판단해야 합니다.

또한 의존 관계가 정확하더라도 생성 결과가 시각적으로 기대에 미친다는 보장은 없습니다. 캐릭터 일관성, 컷의 연속성, 전체 리듬에는 여전히 별도의 품질 평가 메커니즘이 필요합니다.

그래서 Production DAG는 현재로서는 저희가 탐구 중인 발전 방향에 가깝습니다. 현 단계에서는 Agent가 Lomote AI가 이미 갖춘 모델과 도구 기능 범위 안에서 실행 가능한 창작 흐름을 완수하고, 중간 산출물의 비용과 유효성을 통제하는 것을 우선합니다.

작업 의존성, 자동 검수, 멀티모달 이해 능력이 차츰 갖춰지면, 앞으로는 이 메커니즘들을 결합해 Agent가 단계별로 창작 작업을 실행하는 수준을 넘어 전체 제작 흐름을 관리하는 수준으로 나아갈 수도 있을 것입니다. 그리고 이런 설계가 정말 효과적인지 판단하려면 매끄러운 데모 한 번으로는 턱없이 부족합니다. 복잡한 창작 작업에서는 도구 실패, 사용자 수정, 상태 복구, 중복 생성 같은 상황도 생깁니다.

이러한 설계가 실제로 효과가 있는지는 장애 복구와 엔드투엔드 협업 리허설을 통해 검증해야 합니다.

11. 엔지니어링 검증: 장애 복구에서 엔드투엔드 협업까지

Agent 시스템에는 흥미로운 특징이 하나 있습니다. 개별 모듈이 정상적으로 동작한다고 해서 협업 과정 전체가 반드시 믿을 만한 것은 아니라는 점입니다.

예를 들어 메시지는 해당 작업으로 올바르게 라우팅되었고 도구 호출도 성공적으로 반환되었는데, Agent가 생성이 끝난 뒤 실행을 이어 가는 것을 잊을 수 있습니다. 혹은 모든 단계가 예상대로 진행되었는데도 결국 중복 문서가 여러 개 생겨서 사용자가 어느 것이 최신 버전인지 알 수 없게 될 수도 있습니다.

이런 문제는 전통적인 단위 테스트나 간단한 대화 몇 차례로는 발견하기 어렵습니다.

그래서 Lomo Agent를 개발하면서 각 모듈의 정확성을 검증하는 것과 별개로, Agent가 실제와 비슷한 사용 시나리오에서 전체 흐름을 끝까지 수행하게 하고, 여러 메커니즘이 조합된 뒤의 실제 동작을 관찰해 보았습니다.

11.1 런타임 신뢰성 검증

내구성 실행, 메시지 수신함, 비동기 생성, 사용자 권한 부여 같은 메커니즘에서는 많은 문제가 특정 상태 전이 과정에서만 나타납니다.

예를 들면 다음과 같습니다.

• 영상 생성 요청은 이미 제출되었는데, Worker가 결과를 저장하기 전에 재시작되는 경우

• 이전 Worker가 연결이 끊긴 뒤 새 프로세스가 인수했는데, 그 후 이전 Worker가 다시 실행을 재개하는 경우

• 사용자가 중지를 누른 순간 마침 생성 완료 이벤트가 도착하는 경우

이런 상황은 일반적인 데모에서는 거의 나타나지 않지만, 실행 상태와 사용자 작품, 심지어 실제 비용에 직접 영향을 줄 수 있습니다. 그래서 개발 단계에서 장애 주입 테스트를 통해, 이런 이상 상황에서 시스템이 제대로 대처하는지를 중점적으로 검증했습니다.

구체적인 테스트는 다음과 같은 핵심 실행 경계를 다룹니다.

안정적으로 재현할 수 있는 모델 출력은 고정된 결과로 리플레이해 런타임의 상태 전이를 중점적으로 검증할 수 있습니다. 외부 생성 서비스는 타임아웃, 중복 콜백, 순서가 뒤바뀐 이벤트를 시뮬레이션해, 매번 실제 유료 모델에 의존하지 않도록 할 수 있습니다. 이 테스트의 핵심은 시스템 동작의 결정성입니다. 모델 자체에 어느 정도 무작위성이 있더라도, 작업 상태, 실행 권한, 과금 제약에는 명확하고 검증 가능한 규칙이 있어야 합니다.

비교적 대표적인 테스트 하나는 Worker가 도구 실행 도중 갑자기 ‘멈춰 버리는’ 상황을 시뮬레이션하는 것입니다. 테스트에서 모델은 고정된 출력을 사용해 먼저 조회 도구 하나를 호출하기로 결정합니다. 첫 번째 Worker는 모델 결정을 저장하고 도구 호출을 started로 기록한 뒤 인위적으로 멈춥니다. 리스가 만료되면 두 번째 Worker가 인수해 실행 세대를 2로 올리고 checkpoint에서 이어 갑니다. 이 단계의 모델 결정은 이미 저장되어 있으므로 다시 추론할 필요 없이, 같은 멱등 키로 도구 호출을 마칩니다. 마지막으로 첫 번째 Worker를 되살려 뒤늦은 결과를 커밋하려 시도하게 합니다.

테스트 결과는 예상대로였습니다. 라운드는 최종적으로 completed에 들어갔고 실행 세대는 2였습니다. 모델은 한 번만 호출되었고 도구 결과도 하나뿐이었으며, 이전 Worker의 상태 쓰기는 거부되었습니다. 이 밖에도 큐 메시지 유실 후 재전달, 승인 후 생성 작업의 멱등 복구, 취소된 라운드에서 새 작업 생성 차단, 비용 권한 부여 제한, 기억 철회 같은 상황을 통합 테스트로 다루었습니다.

11.2 엔드투엔드 협업 리허설

런타임 테스트로는 시스템이 이상 상태를 올바르게 처리하는지 검증할 수 있지만, Agent의 실제 협업 경험을 온전히 반영하지는 못합니다.

예를 들어 Agent가 스토리보드 기획은 성공적으로 마쳤는데 다음 단계에서 그대로 멈추고, 사용자가 “계속”을 다시 입력해야 비로소 영상 생성을 시작할 수 있습니다. 프로그램 실행 관점에서는 장애가 아닐 수 있지만, 사용자에게는 전체 과정이 분명히 자연스럽지 않습니다.

이를 위해 시나리오 리허설 방식을 도입해 봤습니다.

격리된 환경에서 실제 텍스트 모델을 쓰고, 시뮬레이션된 생성 서비스와 미리 정해 둔 행동을 하는 시뮬레이션 사용자를 붙여, Agent가 비교적 완결된 창작 흐름 하나를 끝까지 수행하게 합니다.

리허설 시나리오에는 포스터 시리즈, 숏필름 제작, Flows 워크플로 수정, 3D 창작, 여러 작업 간 전환, 과거 작업 복구, 기억 정정과 잊기 등이 포함됩니다. 이 시나리오들은 연속적인 모델·도구 호출뿐 아니라 사용자 확인, 비동기 대기, 작업 간 컨텍스트 연결까지 아우릅니다.

예를 들어 숏필름 제작 시나리오에서는 시뮬레이션 사용자가 먼저 창작 목표를 제시하고, Agent는 스토리보드를 구성하고, 소재를 준비하고, 생성 요청을 제출해야 합니다. 실행 도중 사용자는 시안을 조정하거나, 컷을 고르거나, 다른 작업을 갑자기 끼워 넣을 수 있습니다. 저희가 관찰하고 싶은 것은 어떤 한 단계의 성공 여부만이 아니라, 이런 변화를 겪은 뒤에도 Agent가 원래 목표를 중심으로 꾸준히 진행할 수 있느냐입니다.

제가 중점적으로 관찰하는 것은 다음과 같습니다.

• Agent가 올바른 지점에서 멈추거나 계속 진행하는가

• 작업을 진행시키려고 사용자가 “계속”을 반복해서 보내야 하는가

• 불필요한 확인이나 중복 생성이 일어나는가

• 새 메시지를 기존 작업에 올바르게 연결할 수 있는가

• 사용자가 작품을 수정한 뒤 Agent가 최신 상태를 가져올 수 있는가

• 같은 작품이 의도치 않게 여러 사본으로 쪼개지지는 않는가

• 기억을 정정하거나 철회한 뒤에도 이전 정보가 이후 협업에 계속 영향을 주는가

실제 미디어 생성 서비스를 직접 호출하는 것과 비교하면, 시뮬레이션 환경은 테스트 비용을 통제할 수 있고 특정 시나리오를 반복해서 만들기도 쉬워, 모듈 간 상호작용에서 생길 수 있는 문제를 관찰할 수 있습니다.

다만 이 방식에도 분명한 한계가 있습니다. 시뮬레이션된 생성 결과로는 실제 작품의 시각적 품질을 검증할 수 없고, 미리 정한 전략대로 움직이는 시뮬레이션 사용자는 실제 창작의 복잡한 행동을 온전히 반영하지 못합니다. 그래서 이 리허설은 주로 작업 구성, 실행 상태, 협업 흐름의 연속성을 점검하는 데 쓰이며, 실제 사용자 작업의 성공률을 그대로 대변하지는 않습니다. 최종 작품의 품질과 실제 사용 경험은 여전히 실제 생성 결과와 사용자 피드백을 바탕으로 추가로 평가해야 합니다.

11.3 협업의 품질은 어떻게 측정할까

이런 리허설을 거치면서, 모델의 답변이 매끄러운지, 도구 호출이 성공했는지만으로는 오래 실행되는 Agent를 온전히 평가하기 어렵다는 것을 조금씩 깨달았습니다.

사용자가 더 신경 쓰는 것은 아마 다른 질문들일 것입니다.

• 같은 설명을 몇 번이나 반복해야 하는가?

• Agent가 이미 정한 요구사항을 기억하고 있는가?

• 며칠 뒤에도 이전 작업을 자연스럽게 이어 갈 수 있는가?

• 내가 작품을 수정하면 Agent가 무슨 일이 있었는지 아는가?

그래서 전통적인 실행 정확성 외에도 작업 연속성, 사용자 개입 비용, 반복 조작, 산출물 일관성 같은 차원을 보기 시작했습니다.

실제 리허설에서는 모듈을 따로 테스트할 때는 발견하기 어려운 문제들도 드러났습니다.

예를 들어 영어 포스터 시리즈를 만드는 과정에서 Main은 사용자 요구를 올바르게 이해하고 작업을 만들었지만, Worker는 이후 계획 단계에서 중국어로 바꿔 버렸습니다. 문제는 작업 라우팅이 아니라, 작업이 메인 스레드가 정리한 목표 설명만 받아서 사용자의 원래 표현에 담긴 언어 정보가 빠져 있었다는 데 있었습니다. 이후 사용자 언어를 전달하는 방식을 조정해, 작업이 모델에게 작업 설명에서 언어를 추론하게 하는 데 전적으로 기대지 않고 사용자의 실제 입력을 바탕으로 응답 언어를 유지하도록 했습니다.

또 다른 문제는 사람의 확인과 비동기 생성이 맞물리는 지점에서 나타났습니다. Agent가 사용자 확인이 필요한 단계까지 왔는데도 조작 가능한 확인 카드를 내놓지 않거나, 사용자가 생성을 승인한 뒤 외부 작업은 정상적으로 끝났는데 작업이 더 진행되지 않는 경우였습니다. 이런 상황에 대비해 런타임에 확인 카드 안전장치와 생성 완료 후 자동 깨우기 메커니즘을 추가해, 모델의 상호작용 행동에 대한 의존을 줄였습니다.

이 문제들은 하나씩 놓고 보면 뚜렷한 실행 장애로 드러나지 않을 수도 있지만, 사용자가 느끼는 협업의 연속성에는 직접 영향을 줍니다. 덕분에 저는 이 점을 더 분명히 알게 되었습니다. 모델은 의도를 이해하고 단계를 계획하는 일을 맡고, 대기, 권한 부여, 실행 재개 같은 핵심 상태는 런타임이 결정적으로 보장해야 합니다.

물론 이런 차원들이 그 자체로 Agent의 지능 수준을 대변하지는 않습니다. 창작 플랫폼에서는 흐름의 완료와 작품의 품질을 여전히 따로 평가해야 합니다. Agent가 계획대로 모든 컷을 생성할 수는 있어도, 최종 영상이 비주얼 스타일, 캐릭터 일관성, 서사 리듬에서 사용자의 기대에 미친다고 보장할 수는 없습니다. 더 믿을 만한 멀티모달 검수는 저희가 계속 다듬고 싶은 능력입니다.

지금까지의 실천을 보면, 엔드투엔드 리허설은 저희에게 비교적 통제 가능한 검증 방식을 제공해 주었습니다. 모듈 간 협업의 문제를 찾아내는 데 도움이 되었을 뿐 아니라, 아키텍처 설계의 몇몇 원칙이 완전한 실행 흐름 속에서 실제로 검증받게 해 주었습니다. 모델 능력을 키우는 것만큼이나, 그 능력들이 장기 협업 속에서 안정적으로 맞물리게 하는 일에도 꾸준히 투자할 가치가 있습니다.

12. 아직 풀지 못한 문제와 앞으로의 탐구

Lomo Agent는 현재 다중 작업 구성, 내구성 실행, 컨텍스트 관리, 공유 워크스페이스 같은 기본 능력을 갖췄지만, 제가 생각하는 이상적인 창작 에이전트까지는 아직 탐구할 문제가 적지 않습니다.

첫째는 작업 간 협업입니다.

지금의 Router / Worker 구조는 여러 작업이 독립적으로 진행되고, 필요할 때 공유 산출물에 접근하게 해 줍니다. 하지만 여기서 더 나아가 Worker끼리 먼저 도움을 청하고, 작업을 위임하고, 심지어 공유 예산을 협상하게 하려면 더 복잡한 권한, 상태 동기화, 동시성 일관성 문제를 풀어야 합니다.

멀티 Agent 협업은 매력적으로 보이지만, Agent가 많다고 해서 저절로 효율이 높아지는 것은 아닙니다. 추가되는 조율 비용과 컨텍스트 전달이 전문화된 분업의 이득을 상쇄할 수도 있습니다. 저는 먼저 실제 요구에서 쪼갤 가치가 있는 일을 찾아낸 뒤, 협업 범위를 차근차근 넓혀 가고 싶습니다.

둘째는 창작 흐름의 의존성 관리입니다.

앞에서 언급한 Production DAG는 제가 특히 주목하는 방향입니다. 여러 컷, 캐릭터, 장면이 들어간 복잡한 제작 작업에서는 명시적인 의존 관계가 병렬 실행, 증분 갱신, 결과 재사용을 뒷받침하는 데 도움이 됩니다.

하지만 창작 작업의 의존 관계가 늘 확정적인 것은 아닙니다. 사용자가 캐릭터 설정 하나를 바꿨을 때 어떤 컷은 반드시 다시 생성해야 하고 어떤 컷은 그대로 써도 되는지는, 실제 내용을 보고 판단해야 하는 경우가 많습니다.

비동기 생성의 신뢰성도 더 다듬을 여지가 있습니다.

현재 시스템은 이미 업스트림에 제출된 생성 작업을 능동적으로 취소하지 못합니다. 작업은 이미 생성되었는데 업스트림 작업 ID를 저장하기 전에 장애가 나면, 역으로 조회해 연결을 복구하는 기능도 없습니다.

이런 상황에는 이미 그에 맞는 상태 처리와 비용 안전장치가 있지만, 그래도 불필요한 생성 비용이 생길 수 있습니다. 앞으로 업스트림 서비스의 취소 및 작업 조회 기능을 차츰 연동해, 실행 중단이나 사용자의 갑작스러운 요구 변경을 시스템이 더 정확하게 처리할 수 있게 하고 싶습니다.

멀티모달 품질 검수도 어려운 과제입니다.

현재로서는 도구가 성공을 반환하고 체크리스트 단계가 완료되었다는 것은 시스템이 해당 조작을 마쳤다는 증거일 뿐입니다. 진짜 작품 품질에는 시각적 일관성, 움직임의 연속성, 오디오와 영상의 싱크, 사용자의 주관적 미감 같은 요소가 얽혀 있습니다.

멀티모달 모델이 발전함에 따라 이런 평가 능력을 실행 흐름에 차츰 도입해, Agent가 언제 조정해야 하는지, 언제 다시 생성할 가치가 있는지, 언제 결정권을 사용자에게 돌려줘야 하는지를 더 정확하게 판단하게 하고 싶습니다.

그 밖에 장기 기억의 정확성, 작업 라우팅의 신뢰성, 능동적 후속 조치의 경계도 계속 검증해야 합니다.

출처 추적과 버전 관리는 기억의 통제 가능성을 높여 주지만, 모델의 추출 오류나 과거 정보의 잘못된 리콜을 완전히 막지는 못합니다. 마찬가지로 지금의 라우팅 메커니즘은 작업 인덱스, 과거 검색, 유사 작업 중복 검사를 결합해 오판을 줄이고 있지만, 오랫동안 쌓인 대량의 작업에 대해서는 실제 사용 데이터를 통해 작업 연결의 정확도와 사용자가 직접 바로잡아야 하는 빈도를 더 측정해야 합니다.

능동적 후속 조치의 경우, 시스템은 어떤 작업에 아직 남은 일이 있다는 것을 알 수 있어도, 사용자가 지금 방해받고 싶어 하는지까지 알 수 있는 것은 아닙니다. 저희는 앞으로의 Agent가 더 능동적이기를 바라지만, 그 능동성은 사용자의 권한 부여, 작업의 가치, 실제 사용 습관 위에 세워져야 합니다.

이 문제들에 단기간에 모두 성숙한 해법이 나오지는 않을 수도 있습니다. Lomo Agent가 더 많은 실제 창작 시나리오에 들어가면서, 저희도 기존 아키텍처를 계속 다시 살펴보며 어떤 설계가 정말 효과가 있고 어떤 설계를 고쳐야 하는지 검증해 나가겠습니다.

맺으며

Lomo Agent를 처음 구상한 순간부터 출시까지의 과정을 돌아보면, Agent의 발전이 소프트웨어 아키텍처에 꽤 흥미로운 새 문제들을 던지고 있다는 생각이 점점 더 듭니다.

예전에는 소프트웨어를 설계할 때 먼저 명확한 기능, 흐름, 상호작용 경계를 정의하고, 사용자가 그 규칙에 따라 조작을 마치도록 했습니다. 그런데 AI가 의도를 이해하고, 도구를 호출하고, 스스로 결정하는 능력을 갖추기 시작하면서, 원래 사용자가 떠안던 구성과 조율의 일도 차츰 시스템에 넘길 수 있게 되었습니다.

하지만 모델 능력의 향상은 그중 일부일 뿐입니다.

오래 협업할 수 있는 Agent라면 자신이 지금 무엇을 하고 있는지, 이미 무엇을 했는지, 어떤 정보가 여전히 유효한지, 어떤 상황에서 계속하거나 멈춰야 하는지도 알아야 합니다. 현실 시스템의 중단, 동시성, 비용, 권한을 처리해야 하고, 사용자가 언제든 마음을 바꿀 수 있도록 허용해야 합니다.

이번 Lomo Agent의 아키텍처 설계는 바로 이런 문제들을 중심으로 펼친 하나의 실천입니다. 그중 적지 않은 아이디어는 DeepSeek, Manus, Claude Code, Temporal 같은 훌륭한 제품과 엔지니어링 사례에서 왔고, 일부는 저 자신의 창작 시나리오에서 조금씩 더듬어 찾아낸 것입니다.

현재 구현은 아직 초기 탐색 단계로, 이상적인 형태까지는 갈 길이 멀고 많은 설계가 실제 사용자의 검증을 계속 받아야 합니다.

그래도 모델 능력이 계속 앞으로 나아가는 한, 앞으로 소프트웨어와 사람이 상호작용하는 방식에는 여전히 상상할 여지가 크다고 늘 생각합니다.

언젠가는 소프트웨어 사용법을 배울 필요 없이, 우리가 무엇을 하고 싶은지만 말하면 되는 날이 올지도 모릅니다.

그것이 바로 Lomo Agent가 계속 다가가고 싶은 방향입니다.

Agent를 만들고 계신다면 아키텍처 설계와 엔지니어링 실천에서 얻은 경험과 고민을 함께 나누면 좋겠습니다.

크리에이터라면 실제 창작 요구를 들고 와서 Lomo Agent를 직접 경험해 보시기 바랍니다.

Lomo Agent 체험하기: lomo agent

클릭하여 확대

클릭하여 확대

참고 자료와 더 읽을거리

아래 링크는 주로 아키텍처에 영감을 준 출처와 연구 배경을 보여 주기 위한 것이며, 각 프로젝트가 모든 기능에서 Lomo Agent와 같은 구현이나 설계 목표를 갖고 있다는 뜻은 아닙니다.

1. DeepSeek Super-agent Prototype

2. Temporal — Design Patterns

3. OpenAI — Using Goals in Codex

4. Anthropic — Effective Harnesses for Long-Running Agents

5. Claude Code — Hooks

6. Anthropic — How We Built Our Multi-Agent Research System

7. Manus — Context Engineering for AI Agents

8. Mem0: Building Production-Ready AI Agents with Scalable Long-Term Memory

9. Zep / Graphiti: A Temporal Knowledge Graph Architecture

10. LongMemEval: Benchmarking Chat Assistants on Long-Term Interactive Memory

11. OpenClaw — Memory Architecture

12. ViMax — Multi-Agent Video Generation

참고: 본문에서는 ‘이미 구현된 메커니즘’과 ‘발전 방향’을 가능한 한 구분해 표기했습니다. 외부 서비스의 멱등성 보장, 잊기가 다루는 데이터 범위, 모델의 캐시 동작, 자동 검수의 효과 등 실제 능력은 모두 구체적인 구현과 의존 조건의 제약을 받습니다.