Meta의 Muse Wonder 출시 게시물에서는 '액티브 포커스(Active Focus)'라고 부르는 모델의 동작 방식을 소개합니다. 이는 모델이 까다로운 목표를 달성할 때까지 끈기 있게 작업을 이어가고, 대안적 접근법을 시도하며, 장애물을 해결해 나가는 것을 말합니다. 또한 Meta의 표현을 빌리자면, 모델은 필요할 때 명확한 설명을 요청하고 중요한 작업을 수행하기 전에는 확인(check-in)을 거칩니다. Meta는 중대한 영향이 따르는 작업에 앞서 사람의 확인을 받을 것을 권장하며, Meta의 coding-agents guide에서는 Muse Code가 첫 실행부터 승인 기능과 샌드박스가 활성화된 상태로 제공되도록 하고 있습니다.
이는 올바른 설계 방향입니다. 하지만 동시에 에이전트를 병렬로 운용해 본 팀이라면 누구나 이미 겪고 있는 질문을 던지기도 합니다. 바로 '모델이 멈춰서 질문을 던질 때, 누가, 얼마나 신속하게, 어떤 맥락을 파악하고 답변해 줄 것인가?'라는 점입니다. 아무도 보고 있지 않은 터미널에 뜬 확인 요청은 실행 중단으로 이어질 뿐입니다. 반면, 해당 작업(Task)에 연결되어 공유 인박스(Inbox)로 전달되는 확인 요청은 체계적인 검토 단계가 됩니다. 이 글에서는 바로 이 두 번째 방식을 구축하는 방법을 다룹니다.
액티브 포커스가 만들어내는 것
Meta는 세 가지 행동 양식을 중점적으로 학습시켰으며, 이를 자체 벤치마크인 FocusBench로 측정하고 있습니다. 이 벤치마크에서 Muse Wonder Full은 54.2%로 선두를 달리고 있으며, API로 제공되는 Wonder는 44.9%로 GPT-6 Astra와 Claude Opus 5.5의 뒤를 잇고 있습니다. 점수는 차치하더라도, 협업 보드(board) 관점에서 중요한 것은 바로 이 행동 양식들입니다.
- 끈기(Persistence). 모델은 실패를 겪어도 작업을 멈추지 않고 계속 시도합니다. 장시간 실행 코딩 벤치마크인 SWE-Marathon에서 Wonder는 Opus 5.5의 46.3점에 맞서 53.1점을 기록했습니다. 실행 시간이 길어지고 시도 횟수가 늘어날수록 검토해야 할 내용도 많아집니다.
- 명확화 요청(Clarification). 모델은 작업(Task)이 모호할 때 자의적으로 넘겨짚지 않고 질문을 던집니다. 이는 작업 보드에서는 Task에 달리는 댓글이 되고, 터미널에서는 키 입력을 기다리는 프롬프트가 됩니다.
- 확인 절차(Check-ins). 모델은 중요하다고 판단되는 작업을 수행하기 전에 잠시 멈춥니다. Meta의 자체 가이드라인에서도 중대한 영향을 미치는 모든 작업에 대해서는 사람의 확인을 거치도록 권장합니다.
이 세 가지 특성은 각각 검토 큐(review queue)의 형태를 변화시킵니다. 끈기는 작업당 검토량을 증가시킵니다. 명확화 요청은 작업 중단을 유발합니다. 그리고 확인 절차는 누군가 결정을 내릴 때까지 실행을 일시 정지시키는 결정 단계를 만듭니다.
확인 요청이 도달하는 곳
Muse Code에서는 구독자의 터미널에 승인 프롬프트가 표시되며 실행이 일시 중지됩니다. 헤드리스(Headless) 실행(muse exec)에는 대화형 프롬프트가 없으므로, Meta 문서에서는 사람의 개입 없이 완료될 수 있는 정책을 선택하거나 보류된 작업이 미해결 상태로 남을 것을 감수해야 한다고 명시하고 있습니다. 이것이 현실적인 트레이드오프입니다. 사람이 직접 키보드 앞에 앉아 있거나, 승인 옵션을 끄고 모델을 실행하거나, 아니면 작업이 무한정 대기 상태에 머무르게 되거나 셋 중 하나입니다.
Sharkly 보드에서 실행은 컴퓨터(Computer) 상의 에이전트(Agent)에 할당된 작업(Task) 형태를 띱니다. 에이전트가 질문을 위해 멈추면 해당 질문은 Task에 댓글로 등록되어 인박스(Inbox)로 전달됩니다. Task에는 무엇을 요청했는지, 에이전트가 지금까지 무엇을 수행했는지, 도구 호출 및 런타임 이벤트의 실행 로그 등 모든 맥락이 담겨 있습니다. 이 작업을 맡은 사람이 Task에 답변을 달면 실행을 재개할 수 있는 명확한 기준점이 생깁니다. 확인 절차는 여전히 사람의 결정에 의존하지만, 기록이 남고 큐가 존재하며 여러 사람이 분담할 수 있는 형태의 사람의 결정이 됩니다.
이것이 바로 안전장치(safeguard)와 작업 정체(stall)의 차이입니다. 모델의 동작은 동일합니다. 하지만 확인 요청 하나를 처리하는 데 1분이 걸릴지 하루가 걸릴지는 모델을 둘러싼 시스템이 결정합니다.
확인 요청이 유용하게 작동하도록 에이전트 작성하기
확인 요청의 가치는 질문의 질에 달려 있습니다. 좋은 질문을 이끌어내기 위한 기준을 에이전트의 지침(instructions)에 명시하세요:
Stop and ask before anything destructive, anything that sends data outside the
attached repositories, any payment or external account action, and any change
to CI, deploy or access configuration.
When you ask, state in one comment: what you are about to do, why the Task needs
it, what you considered instead, and what happens if the answer is no.
Do not ask about reversible edits inside the repository. Make them, test them,
and report.
If you have waited for an answer and the Task has a deadline, say so in a second
comment rather than proceeding.
첫 번째 규칙은 명확한 경계선을 설정합니다. Meta의 모델은 스스로 무엇이 중요한지 판단하지만, 이 지침을 통해 팀이 중요하게 여기는 기준이 무엇인지 알려줍니다. 두 번째 규칙 덕분에 실행 과정을 지켜보지 않았던 사람이라도 30초 안에 댓글로 답변할 수 있습니다. 세 번째 규칙은 모델이 사소한 것까지 일일이 묻는 것을 방지합니다. 지나치게 모든 것을 묻는 것은 신중한 에이전트를 번거롭고 성가신 존재로 전락시키는 전형적인 실패 패턴입니다. guardrails post for Opus 5.5에서는 프롬프트 인젝션 관점에서 동일한 경계를 다룹니다. 모델이 어떤 약속을 하든, 궁극적인 제어권은 검토 게이트에 있습니다.
검토 큐 규모 산정하기
끈기 있게 작업을 지속한다는 것은 Task당 검토해야 할 작업이 줄어드는 것이 아니라 오히려 늘어남을 의미합니다. 이에 대비해야 합니다.
| 레인 | 일반적인 실행 양상 | 큐에 도달하는 항목 |
|---|---|---|
| 긴 작업(Task)을 수행하는 Muse Wonder | 수많은 단계, 여러 차례 되돌린 시도들 | 더 긴 diff, 더 방대한 로그, 0~3건의 확인 요청 |
| 동일한 작업을 수행하는 Opus 5.5 | 더 적은 단계, 더 결단력 있는 진행 | 더 짧은 diff, 또는 절반만 완료된 채 반환된 작업 |
| 밤새 무인으로 실행된 모든 모델 | 정책이 허용한 범위의 작업 | 보류된 작업이거나, 아무도 확인하지 않은 작업 |
큐가 원활하게 순환하도록 유지하는 세 가지 실천 방법이 있습니다. 첫째, 확인 요청을 전체 그룹에 보내지 않고 레인별로 지정된 담당 검토자에게 라우팅하여 질문이 불특정 다수의 응답을 기다리며 방치되지 않도록 하세요. 둘째, 확인 요청으로 인해 차단된 실행이 몇 시간 동안 실행 중 상태로 머무는 대신 즉각 눈에 띄게 실패 처리되도록 에이전트의 작업별 타임아웃을 설정하세요. 셋째, Wonder를 실행할 때는 diff뿐만 아니라 로그도 함께 확인하세요. 끈기 있는 모델이 실패한 세 가지 접근 방식을 거쳐온 경로야말로 모델이 실제로 추가한 작업 내역이며, 미묘한 오류가 숨어 있는 곳이기 때문입니다. Coding agents while you’re away에서는 야간 무인 실행 사례를 다루고 있으며, human review is the bottleneck에서는 모델의 성능이 향상되더라도 이러한 비용이 줄어들지 않는 이유를 설명합니다.
보드에서 모범적인 확인 요청의 모습
위의 지침을 적용하면 검토자가 스마트폰에서도 쉽게 조치할 수 있는 다음과 같은 형태의 Task 댓글이 생성됩니다:
Check-in before action.
About to: drop the legacy `orders_v1` table in the migration.
Why: the Task says remove v1 read paths; the table is the last reference.
Considered: keeping the table and removing only the code. Rejected because
the nightly job still writes to it and would fail silently.
If no: I will leave the table, remove the code paths, and note the job in
the report for a follow-up Task.
단 네 줄로 결정해야 할 사안을 명확히 제시하고, 두 가지 분기 경로가 이미 계획되어 있습니다. 검토자가 Task에 “yes” 또는 “no, keep it”이라고 입력하기만 하면 실행이 재개되고, 로그에는 누가 결정을 내렸는지가 기록됩니다. 이전 40단계의 과정을 전혀 보지 못한 사람에게 Allow? [y/N] 프롬프트만 덩그러니 보여주는 터미널 환경과 비교해 보십시오.
해당 레인을 1주일 정도 운영한 뒤 적용할 수 있는 두 가지 개선 사항이 있습니다. 특정 검토자가 대부분의 확인 요청을 처리하고 있다면, 오후 회의 등으로 인해 장시간 실행되는 모든 작업이 중단되지 않도록 해당 레인의 에이전트에 보조 검토자를 지정하십시오. 또한 에이전트가 동일한 유형의 작업에 대해 반복해서 질문한다면, 해당 유형은 큐에 올릴 것이 아니라 지침에 상시 승인(standing yes) 또는 상시 거부(standing no) 항목으로 등록해야 합니다.
컴퓨터 제어(Computer-use) 활용 사례
Meta는 브라우저, 데스크톱, 모바일 앱 조작 등 컴퓨터 제어를 Wonder의 주요 역량 중 하나로 내세우고 있습니다. 확인 절차가 가장 중요해지는 지점이자 터미널 프롬프트가 가장 부적합한 지점이 바로 여기입니다. 검토자가 볼 수 없는 화면 위의 버튼을 클릭하는 동작이기 때문입니다. Astra computer-use post의 규칙이 그대로 적용됩니다. 즉, 에이전트는 팀이 지정한 컴퓨터에서 실행되어야 하고, 확인 요청 시 화면과 동작을 명시해야 하며, 승인하는 담당자가 결정을 내리기 전에 Task 로그를 확인할 수 있어야 합니다. 제출(Submit) 버튼을 누를 수 있는지 승인을 요청하는 모델은 그 버튼을 눌렀을 때 어떤 결과가 일어나는지 검토자가 알 수 있을 때에만 안전합니다.
오해하지 말아야 할 점
액티브 포커스는 모델의 행동 양식일 뿐이며, 모델의 행동이 결과를 보장하지는 않습니다. Meta의 자체 모델 카드에서도 낯선 다단계 작업에서는 실수가 발생할 수 있음을 밝히고 있으며, 전체 안전성 보고서도 아직 발표 대기 중입니다. 확인 절차는 훌륭한 검토 시스템을 더 효과적으로 만들어 주는 기능일 뿐, 시스템 자체를 대체할 수는 없습니다. "중요한 작업 전에 확인을 거친다"는 문구를 사람의 관리 없이 무인으로 실행해도 된다는 의미로 해석한다면 큰 오산입니다. 모든 확인 요청에 명확한 Task, 검토자, 타임아웃을 지정하는 팀이야말로 이 기능이 본래 의도된 목적에 맞게 시스템을 구축한 것입니다.
이 모든 과정에서 Sharkly에 추가 비용이 청구되지 않습니다. 모델 사용량은 컴퓨터에 구성된 Meta API 키를 통해 처리됩니다. 모델은 10월 12일에 변경되었습니다. 하지만 요청부터 배포에 이르기까지 맥락, 진행 상황, 장애 요인, 결과, 사람의 검토 과정은 투명하게 유지되었습니다. 워크트리(worktree)를 활용해 이 환경을 직접 수작업으로 구축할 수도 있고, Sharkly를 사용해 워크플로를 관리할 수도 있습니다.
