중요한 작업의 상당수는 누군가 열심히 처리하는 동안 실패하지 않습니다. 작업은 그 사이의 틈에서 실패합니다.
공급업체가 아직 답하지 않았습니다. 보고서는 내일 도착하는 숫자에 달려 있습니다. 브라우저 세션은 한 컴퓨터에 열려 있는데, 다음 단계를 승인할 사람은 다른 시간대에 있습니다. 의존 관계가 풀릴 즈음이면 처음의 대화는 묻혀 있고, 일이 정확히 어디서 멈췄는지 기억하는 사람은 없습니다.
항상 켜져 있는 개인 에이전트는 바로 이런 틈에 강해야 합니다. 끊임없이 생각하거나 컴퓨터를 최대 성능으로 계속 돌릴 필요는 없습니다. 필요한 것은 책임을 지키는 일입니다. 어떤 결과를 맡았는지, 이미 무엇을 했는지, 무엇을 기다리는지, 작업 자료가 어디에 있는지, 어떤 이벤트나 결정이 있어야 작업을 이어 갈 수 있는지입니다.
그것이 긴 채팅과 장기 업무의 차이입니다. 긴 채팅은 메시지를 저장합니다. 장기 업무에는 지속되는 작동 상태가 필요합니다.
장기 업무에는 더 긴 채팅이 아니라 지속되는 Task가 필요합니다
대화는 의도를 정하는 데는 유용하지만, 책임을 맡는 단위로는 부족합니다.
재무팀이 월 결산을 마친 뒤 이사회 보고 자료를 준비해 달라고 에이전트에게 부탁했다고 해 봅시다. 쓸모 있는 상태는 처음 요청만이 아닙니다. 이미 정리한 초안, 확인한 원본 문서, 빠진 숫자, 그 숫자를 줄 것으로 예상되는 사람이나 시스템, 회의 마감, 그리고 최종 보고 자료가 갖춰야 할 기준까지 포함됩니다.
Comma에서는 간단한 답변 이상이 필요한 일이 Task가 됩니다. Comma Task 문서에 따르면, Task는 진행 중인 작업을 거쳐, 사람의 결정이 필요하면 검토 필요에서 기다리고, 일이 끝나면 완료에 이릅니다. 중요한 것은 라벨 자체가 아닙니다. 채팅을 닫은 뒤에도 책임이 살아남는다는 점입니다.
지속되는 Task는 언제나 다음 여섯 가지 질문에 답할 수 있어야 합니다.
이 답이 없으면 "나중에 이어서 할게요"는 낙관일 뿐입니다. 답이 있으면 그 말은 계획이 됩니다.
기다림은 실패가 아니라 하나의 상태입니다
쓸모 있는 일의 대부분에는 정당한 기다림이 포함됩니다. 실수는 모든 멈춤을 오류로 보거나, 끝없이 확인을 반복해도 된다는 신호로 받아들이는 것입니다.
에이전트는 자신이 어떤 종류의 기다림에 들어섰는지 알아보고, 분명한 종료 조건을 붙여야 합니다.
이 구분이 중요한 이유는 기다림마다 알맞은 행동이 다르기 때문입니다. 시간 대기인 작업은 체크포인트까지 잠들어 있을 수 있습니다. 이벤트 대기인 작업은 좁게 정의된 변화를 지켜볼 수 있습니다. 환경 대기인 작업은 몰래 다른 곳에서 일을 시도하지 말고 어떤 기기나 도구를 쓸 수 없는지 알려야 합니다. 결정 대기인 작업은 잘 정리된 선택지를 그 결정의 주인에게 돌려줘야 합니다.
멈춤에도 한도가 있어야 합니다. 기다리던 답이 끝내 오지 않으면 에이전트에게는 대안이 필요합니다. 담당자에게 다시 알리거나, 가정을 두고 진행할지 사용자에게 묻거나, Task를 막힌 상태로 닫는 것입니다. 그러지 않으면 백그라운드의 책임이 형식상으로는 열려 있으면서 실제로는 방치될 수 있습니다.
항상 켜져 있다는 것이 늘 방해한다는 뜻이어서는 안 되는 이유도 여기에 있습니다. 어떤 이벤트가 에이전트를 깨울 만하고, 그중 어떤 것이 사용자를 방해할 만한지라는 별도의 질문은 항상 켜져 있는 개인 에이전트는 언제 깨어나야 할까요?에서 다룹니다. 여기서 관련된 원칙은 더 좁습니다. 모든 멈춤에는 눈에 보이는 이유와 일로 돌아가는 정해진 길이 있어야 합니다.
새 브리핑이 아니라 체크포인트에서 재개하기
기다림이 끝나면 에이전트는 흩어진 메시지로 맡은 일을 다시 맞추거나 사용자에게 다시 설명해 달라고 해서는 안 됩니다. 체크포인트에서 재개해야 합니다.
쓸모 있는 체크포인트는 작업 상황을 간결하게 담은 기록입니다.
처음의 결과와 현재의 완료 기준
마지막으로 한 의미 있는 행동과 그 결과
이미 만들었거나 바꾼 산출물
여전히 유효한 가정
멈춤을 일으킨 막힌 지점
그 막힌 지점이 풀리면 하려는 다음 행동
그 행동이 이뤄져야 하는 환경
이것은 개인 기억이 아니라 작업 상태입니다. 기억은 에이전트가 여러 작업에 걸쳐 한 사람의 선호를 기억하는 데 도움이 될 수 있습니다. 체크포인트는 하나의 구체적인 책임이 유휴 시간, 재시작, 인계 뒤에도 정확히 이어지도록 하기 위해 존재합니다.
이 구분은 흔한 두 가지 실패를 막아 줍니다. 첫째, 에이전트는 긴 대화의 모든 세부 사항을 앞으로의 모든 단계에 끌고 다녀서는 안 됩니다. 둘째, 작업을 너무 과감하게 압축해서 중요한 제약이 사라지게 해서도 안 됩니다. 체크포인트는 골라 담습니다. 다음 행동이 의존하는 것을 보존합니다.
Comma의 바탕이 되는 시스템은 이 패턴을 여러 층위에서 반영합니다. Salix Loop는 자기 상태의 체크포인트를 남길 수 있어서, 범위가 정해진 백그라운드 프로세스가 재시작 뒤에 재개할 수 있습니다. 이 인프라가 잘 정의된 Task를 대신하지는 않지만, 같은 연속성 규칙을 보여 줍니다. 복구는 짐작이 아니라 알려진 상태에서 시작해야 한다는 것입니다.
일은 실제로 필요한 환경에 두세요
장기 업무가 추상적인 "AI 작업 공간"에서 일어나는 경우는 드뭅니다. 일은 이메일, 문서, 프로젝트 도구, 브라우저, 로컬 파일, 전문 소프트웨어 안에서 일어납니다. 그래서 연속성에는 일이 있는 장소도 포함됩니다.
Comma는 연결된 앱과 파일, 사용자의 컴퓨터, 또는 자체 클라우드 컴퓨터에서 일할 수 있습니다. Salix 문서에 따르면, 가상 머신은 유휴 상태일 때 잠들 수 있지만 클라우드 컴퓨터의 저장 공간은 사용과 사용 사이에도 유지됩니다. 파일과 도구는 에이전트가 떠난 자리에 그대로 남고, Task가 필요로 하면 컴퓨터가 다시 깨어날 수 있습니다.
어떤 일은 특정 기기에 남아 있어야 합니다. 로컬 디자인 파일, 로그인된 데스크톱 앱, 개발 환경은 연결된 Mac이나 Linux 컴퓨터에만 있을 수 있습니다. Comma의 에이전트 런타임 문서는 이 경계를 분명히 밝힙니다. 지정된 외부 기기가 오프라인이면 일은 기다리거나 실패합니다. Salix가 그 일을 몰래 다른 기기로 옮기지는 않습니다.
이 제한은 신뢰에 도움이 되는 성질입니다. 자동 이전은 편리해 보일 수 있지만, 쓸 수 있는 파일, 권한, 자격 증명, 실행 조건을 바꿀 수 있습니다. 믿을 만한 에이전트는 이 경계를 눈에 보이게 해야 합니다.
다음 단계에는 "Studio"라는 이름의 Mac이 필요합니다. 지금 오프라인입니다. Task는 그곳에서 기다리고 있으며, 클라우드 컴퓨터로 옮긴 작업은 없습니다.
이제 사용자는 진행이 왜 멈췄는지, 무엇이 있어야 풀리는지 모두 압니다. 에이전트는 기기가 돌아왔을 때 다시 시도하거나, 다른 환경도 괜찮은지 물을 수 있습니다. 모든 런타임을 서로 바꿔 쓸 수 있는 것처럼 꾸며서는 안 됩니다.
그 사람에게 속한 결정만 돌려주세요
사람에게 넘기는 것은 자율성의 실패가 아닙니다. 개인 에이전트가 일을 하는 것과 결과를 책임지는 것의 차이를 지키는 방법입니다.
에이전트는 맡은 범위에 드는 일상적이고 되돌릴 수 있는 단계는 계속해야 합니다. 실질적인 모호함, 권한의 경계, 되돌릴 수 없는 외부 행동, 또는 가진 근거가 아니라 사용자의 선호에 달린 선택에 이르면 통제를 돌려줘야 합니다.
인계 자체는 작아야 합니다. 나쁜 인계는 "막혔어요, 어떻게 할까요?"라고 말합니다. 쓸모 있는 인계에는 다음이 담깁니다.
무엇이 바뀌었는지: 이전 계획을 끝낸 새로운 정보나 조건.
무엇이 이미 끝났는지: 묻기 전에 에이전트가 마친 일.
어떤 결정이 남았는지: Task 전체를 다시 관리해 달라는 요청이 아니라 하나의 정확한 선택.
선택지가 무엇을 바꾸는지: 각 경로가 가져오는 의미 있는 결과.
선택이 언제 중요한지: 마감, 또는 기다릴 때의 영향.
다음에 무슨 일이 일어나는지: 답을 받은 뒤 에이전트가 재개할 행동.
예를 들면 이렇습니다. “장소 측은 목요일까지만 이 날짜를 잡아 둘 수 있습니다. 취소 조건을 확인했고 예약 정보를 준비했습니다. 지금 승인하면 계약금이 확정되고, 기다리면 유연성은 남지만 그 시간대를 놓칠 수 있습니다. 예약을 제출할까요?”
Comma는 이런 사람의 결정이 필요한 일에 검토 필요를 씁니다. Task는 그 질문을 중심으로 그대로 유지되므로, 답 하나로 새 계획 세션을 시작하지 않고 다음 행동을 풀어 줄 수 있습니다.
"완료"에는 근거와 마무리가 필요합니다
오래 이어지는 Task는 에이전트가 행동을 멈췄다는 이유만으로 완료되지 않습니다. 시간이 초과되었을 수도, 재시도 정책을 다 썼을 수도, 아직 검토가 필요한 초안을 만들었을 수도, 권한의 끝에 다다랐을 수도 있습니다.
마무리에서는 다음을 밝혀야 합니다.
요청받은 결과
실제로 만들어 낸 결과
만들었거나 바꾼 산출물
수행한 확인
해결되지 않은 제한, 가정, 후속 작업
외부 행동을 실행했는지, 준비만 했는지
이 기록이 있으면 사용자는 전체 이력을 다시 돌려 보지 않고도 일을 점검할 수 있습니다. "Task가 더 이상 실행 중이 아니다"와 “결과가 달성되었다” 사이의 위험한 모호함도 막아 줍니다.
완료는 워크플로 상태이지, 진실의 증명서가 아닙니다. 에이전트는 파일이 만들어졌는지, 명령이 성공했는지, 메시지가 보내졌는지 확인할 수 있습니다. 하지만 상태를 바꾼다고 불확실한 원자료가 확실해지지는 않습니다. 주장에는 여전히 알맞은 근거가 필요하고, 결과가 따르는 일은 여전히 사람의 검토를 받을 만할 수 있습니다.
며칠에 걸친 일을 위한 실용적인 절차
며칠짜리 책임을 맡기기 전에 오케스트레이션 시스템을 설계할 필요는 없습니다. 좋은 요청이라면 몇 줄로 핵심 약속을 정할 수 있습니다.
먼저 결과와 무엇이 “충분히 좋은” 것인지 밝히세요. 움직일 수 없는 마감과 그보다 앞선 결정 시점을 알려 주세요. 에이전트가 묻지 않고 해도 되는 행동과 승인이 필요한 행동을 말해 주세요. 원자료와 작업 파일이 있어야 할 환경을 가리켜 주세요.
그다음 기다림을 분명히 하세요. 어떤 의존 관계를 기다리게 될지, 언제 다시 확인할지, 끝내 오지 않으면 어떻게 할지 알려 주세요. 멈추기 전마다 체크포인트를 남기고, 정말로 사용자가 필요한 결정만 돌려 달라고 하세요. 마지막으로 산출물, 확인한 내용, 남은 불확실성을 담은 마무리 메모를 요구하세요.
간결한 위임은 이런 모습일 수 있습니다.
재무팀이 월말 숫자를 공개하면 최종 이사회 보고 자료를 준비해 주세요. 클라우드 컴퓨터에 있는 기존 초안과 워크북을 쓰세요. 초안을 업데이트하고 합계를 검증하는 것은 괜찮지만, 외부로 무언가를 보내기 전에는 먼저 물어봐 주세요. 화요일 정오까지 숫자가 오지 않으면 어떤 부분이 막혔는지 알려 주고 가장 위험이 적은 대안을 제안해 주세요. 끝나면 문서, 확인한 출처, 남아 있는 가정을 돌려주세요.
가치는 프롬프트를 정교하게 만드는 데서 나오지 않습니다. Task가 거쳐 갈 분명한 상태를 주는 데서 나옵니다. 접수, 작업 중, 대기 중, 검토 준비, 재개, 종료입니다.
자주 묻는 질문
오래 이어지는 Task가 기다리는 동안에는 무엇이 활성 상태로 남습니까?
Task는 결과, 끝낸 일, 현재의 의존 관계, 체크포인트, 재개 조건을 유지합니다. 실행 환경은 잠들 수 있고, 어떤 모델도 계속 추론할 필요가 없습니다. 범위를 좁힌 Loop가 빠진 조건을 지켜보고 있다면, 그것은 조건이 갖춰진 뒤 에이전트가 무엇을 해야 하는지 알려 주는 지속적인 Task 상태와는 별개입니다.
Task에 필요한 컴퓨터가 오프라인이면 어떻게 됩니까?
Task가 그 기기의 외부 런타임에 할당되어 있다면, 기기를 쓸 수 있을 때까지 일은 기다리거나 실패합니다. Salix는 그것을 다른 컴퓨터로 자동으로 옮기지 않습니다. Task는 막힌 환경과 복구 조건을 분명히 보여 줘야 합니다.
Task 상태는 에이전트의 기억과 같은 것입니까?
아닙니다. Task 상태는 하나의 책임, 즉 그 결과, 진행 상황, 산출물, 막힌 지점, 다음 행동을 설명합니다. 개인 기억은 여러 책임에 걸칠 수 있고 오래가는 선호를 포함할 수 있습니다. 오래 이어지는 Task는 작업 세부 사항을 모두 영구적인 기억으로 바꾸지 않고도 재개할 수 있어야 합니다.
에이전트는 다른 사람을 어떻게 기다려야 합니까?
무엇을, 누구에게 요청했는지, 언제부터 답이 늦은 것인지, 어떤 대안을 적용할지를 기록해야 합니다. 이벤트를 지켜볼 수 있다면 사용자를 반복해서 방해하지 말고 그 이벤트를 지켜봐야 합니다. 에스컬레이션 규칙이 없는 무기한 대기는 완전한 계획이 아닙니다.
검토 필요에는 무엇을 넣어야 합니까?
정말로 사용자에게 속한 결정이나 권한에 쓰세요. 결과가 따르는 트레이드오프, 모호한 의도, 되돌릴 수 없는 외부 행동, 민감한 약속, 새로운 권한 같은 것입니다. 에이전트는 끝낸 일을 붙이고, 진행을 풀어 줄 가장 작은 결정을 요청해야 합니다.
완료는 결과가 옳다는 뜻입니까?
완료는 Task가 선언한 완료 조건에 도달했다는 뜻입니다. 얼마나 믿을 수 있는지는 여전히 출처, 확인, 검토의 질에 달려 있습니다. 쓸모 있는 완료 메모는 검증된 사실, 가정, 해결되지 않은 위험을 나눠서 보여 줍니다.
연속성이 곧 제품입니다
항상 켜져 있는 개인 에이전트를 쓸 가장 강력한 이유는 한 번도 끊기지 않는 추론 마라톤을 해낼 수 있어서가 아닙니다. 실제 일에서 흔히 생기는 끊김, 즉 잠드는 컴퓨터, 늦어지는 답장, 예정대로 들어오는 데이터, 바뀌는 조건, 사람이 결정해야 하는 순간을 넘어 책임을 이어 갈 수 있어서입니다.
그 연속성은 눈에 보이는 상태로 만들어집니다. Task는 자신이 무엇을 빚지고 있는지 알고, 기다림에는 이유가 있으며, 환경에는 이름이 있고, 인계에는 범위가 있으며, 완료에는 근거가 따릅니다. 이 조각들이 틈을 견디고 살아남으면, 사용자는 일을 버리지 않고 떠날 수 있고 처음부터 다시 쌓지 않고 돌아올 수 있습니다.
