공유 스레드에서 워크플로를 격리하는 에이전트 설계

공유 맥락이 만드는 편의와 오염

Meta Superintelligence Labs가 2026년 9월 2일 공개한 Muse Spark 1.3은 하나의 긴 스레드에서 여러 워크플로를 병행하는 구성을 전면에 내세웠다. 작업마다 세션을 다시 만드는 대신, 공통 맥락 위에 여러 작업 흐름을 올리고 상호 간섭은 제한하는 접근이다.

열린 목표가 주어지면 에이전트는 도구를 이용해 컨텍스트를 구성하고, 계획에서 비어 있는 부분을 교정한다. 공유 스레드에서는 프로젝트 배경, 코드베이스 구조, 규약을 반복 설명하지 않아도 된다는 이점이 있다. 반면 한 작업의 중간 결론이나 실패 경험이 다른 작업의 전제로 흘러들면 판단이 오염된다.

컨텍스트는 유한하다. 병행 작업이 늘어날수록 작업별로 쓸 수 있는 맥락은 줄어들며, 충돌하는 지시에 우선순위가 없다면 시스템은 이를 임의로 해석하게 된다. 판단의 근거가 어느 워크플로에서 왔는지 구분하지 못하면 사후 분석도 어렵다.

워크플로 경계를 시스템에 남기는 방법

분리는 대화 흐름을 추측하는 방식이 아니라, 시스템이 확인할 수 있는 구조로 구현해야 한다.

각 작업 흐름에는 워크플로 식별자를 부여하고 모든 발화와 도구 호출에 연결한다. 식별자가 없으면 분리 규칙을 적용할 대상 자체가 불명확해진다.

목표, 진행 단계, 중간 산출물, 실패 이력은 작업별 상태 슬롯에 저장한다. 슬롯 사이의 직접 읽기는 제한하고, 사전에 정의한 경로로만 참조하게 한다. 공유 영역에는 프로젝트 규약, 코드베이스 구조, 용어 정의처럼 모든 작업에 유효한 항목만 둔다. 공유 대상은 목록으로 관리해야 시간이 흐르며 모든 정보가 공유 영역으로 번지는 일을 막을 수 있다.

다른 작업의 결과가 필요할 때는 명시적 요청과 출처 표기를 요구한다. 출처 없는 전제가 암묵적으로 승계되면 오염의 시작점을 찾기 어렵다. 완료된 워크플로는 즉시 상태 슬롯을 요약으로 축약하고, 상세 이력은 외부 저장소로 옮긴다. 활성 작업의 컨텍스트 예산을 종료 작업이 계속 점유하지 않게 하기 위해서다.

전체 예산은 공유 영역과 작업별 영역으로 구분해 상한을 둔다. 특정 작업이 예산을 독점하면 다른 작업의 품질이 조용히 떨어질 수 있다. 최신 지시, 작업 고유 지시, 공유 규약의 우선순위도 고정해야 하며, 충돌을 감지했을 때는 임의 해석 대신 확인을 요청한다. 작업 전환 시점과 대상 역시 기록해야 오염 발생 시점을 역추적할 수 있다.

⤢✕

운영 정책으로 격리를 굳히기

병행해도 안전한 작업 조합과 반드시 나눠야 하는 조합을 먼저 정한다. 같은 파일을 수정하는 작업은 병행 대상에서 제외한다. 이 경우 충돌을 해소하는 비용이 맥락 재사용으로 얻는 이득보다 커진다.

공유 영역에 넣을 항목은 명시적으로 나열하고, 목록 밖의 정보는 작업 전용으로 처리한다. 새로운 공유 항목은 승인 대상으로 두는 편이 낫다. 교차 참조 규칙도 변경 승인 대상에 포함해야 한다.

운영 중에는 다른 작업의 결론이 잘못 이어진 사례를 수집해 유형화한다. 이런 사례가 쌓여야 교차 참조 규칙을 실제 위험에 맞게 조정할 수 있다. 산출물에 다른 작업 고유의 용어나 전제가 섞이지 않았는지 정기적으로 점검하고, 자동 탐지가 어려운 부분은 표본 검수로 보완한다.

컨텍스트 예산에는 공유 영역과 작업별 영역의 토큰 상한을 정하고, 상한을 넘었을 때 어떤 항목부터 축약할지도 함께 결정한다. 사용자에게 현재 대화 대상 워크플로가 무엇인지 표시하는 전환 UX도 필요하다. 표시가 없으면 사용자가 어느 작업에 지시했는지 혼동할 수 있다.

병행 작업 수, 오염 사례, 예산 초과 빈도는 정기 보고 항목으로 관리할 수 있다.

단일 스레드와 개별 세션의 선택

구분	단일 스레드 병행	작업별 개별 세션
맥락 재사용	높음	없음
간섭 위험	높음	없음
설명 반복 비용	낮음	높음
컨텍스트 경합	발생	없음
작업 간 연계	쉬움	어려움
추적 난이도	높음	낮음

단일 스레드 병행은 프로젝트 배경과 규약을 한 번 설명하면 된다. 앞선 작업에서 확인한 사실을 곧바로 활용할 수 있어 반복 탐색이 줄고, 작업 간 연결도 자연스럽다. 대신 다른 작업의 중간 결론이 전제로 섞여 잘못된 판단을 만들 수 있으며, 여러 작업이 컨텍스트를 나눠 쓰므로 작업별 가용 맥락이 줄어든다. 판단이 어느 맥락에서 나왔는지 추적하기도 어렵다.

작업별 개별 세션은 간섭이 구조적으로 불가능하다. 결과가 깨끗하고 각 작업이 전체 컨텍스트를 쓸 수 있으며, 문제가 생겼을 때 영향 범위도 명확하다. 그러나 배경 설명이 반복되고, 이미 알아낸 사실을 다시 탐색해야 하며, 작업 간 결과를 사람이 옮겨야 한다.

배경 설명 비용이 큰 대규모 코드베이스에서는 단일 스레드 병행의 이점이 크다. 간섭 위험이 높은 조합만 개별 세션으로 분리하는 선택적 격리가 현실적인 방식이다.

명시적 워크플로 분리는 작업 상태를 독립적으로 관리한다. 작업 순서가 바뀌거나 중간에 다른 작업이 들어와도 결과가 흔들리지 않고, 산출물의 소속과 오염 시점을 추적할 수 있다. 그만큼 식별자와 슬롯을 관리해야 하며, 짧은 작업에는 절차가 과할 수 있다.

암묵적 순서 의존은 사용자가 자연스럽게 입력할 수 있고 별도 구현도 필요 없다. 그러나 이전 발화의 맥락이 어디까지 유효한지 모호해 모델이 임의로 해석할 수 있으며, 대화가 길어질수록 오해가 누적된다. 사용자에게는 자연스러운 입력을 허용하되 시스템이 식별자를 추론해 붙이고, 불확실할 때만 확인하는 구성이 사용성과 추적성을 함께 확보한다.

완료 즉시 정리하면 종료 작업이 활성 작업의 예산을 잠식하지 않아 남은 작업의 품질을 유지할 수 있고, 오래된 결론이 새 판단에 섞일 위험도 줄어든다. 다만 나중에 상세 경위를 물을 때 요약만으로는 부족할 수 있고, 축약 과정에서 근거가 빠질 수 있으며 축약 호출 비용도 든다.

전체 이력을 유지하면 감사와 재현에는 유리하지만 컨텍스트가 빠르게 소진된다. 오래된 실패 경험이 새 작업의 판단을 위축시킬 수도 있다. 컨텍스트에는 요약을 남기고 상세 이력은 외부 저장소에 두며 필요할 때 도구로 조회하는 계층 구성이 두 요구를 함께 다룬다.

프로세스·설계·품질 관점에서 보는 분리

워크플로 식별과 상태 슬롯 분리는 프로세스 인스턴스 식별 및 상태 관리에 대응한다. 작업 전환 이력은 프로세스 실행 추적성을 확보하는 장치다.

공유 영역과 작업 영역을 나누는 일은 응집도와 결합도 관점에서 경계를 설정하는 문제이기도 하다. 컨텍스트 예산 배분은 유한 자원을 어떤 정책으로 할당할지 결정하는 설계에 해당한다.

격리 위반 사례의 수집과 오염 탐지 점검은 결함 유형 분석 및 예방 활동으로 볼 수 있다. 교차 참조 시 출처를 표기하는 규칙은 산출물 근거의 추적성을 구현한다.

다중 워크플로 에이전트가 향하는 방향

다중 워크플로 병행은 에이전트 제품의 기본 상호작용 모델로 자리 잡고, 작업 전환 UX는 경쟁 요소가 되는 방향이다. 작업 단위로 컨텍스트 예산을 배분하는 스케줄링도 프레임워크 기능으로 편입되는 흐름이다.

맥락 오염은 에이전트 품질 저하의 주요 원인으로 분류되고 전용 탐지 지표가 정립되는 방향이다. 컨텍스트에는 요약을 두고 외부에는 상세를 두는 계층 저장 구성 역시 표준 패턴으로 확산되는 흐름이다.

공유 스레드는 설명 반복을 줄이지만, 다른 작업의 중간 결론이 현재 작업의 판단에 들어오는 위험을 함께 만든다. Muse Spark 1.3이 긴 스레드 안의 다중 워크플로를 내세운 배경에는 무엇을 공유하고 무엇을 격리할지가 정확도를 좌우한다는 문제가 있다. 식별자와 상태 슬롯, 공유 항목 목록, 종료 작업의 즉시 축약이 최소 구성이며, 공유 항목 추가를 승인 대상으로 관리하는 절차가 실질적인 방어선이 된다.