ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • 에이전트가 세 가지 일을 동시에 돌릴 때 — OpenClaw Workboard가 '지금 뭐가 막혔는지'를 보여주는 방법
    IT 2026. 7. 10. 21:00
    에이전트가 세 가지 일을 동시에 돌릴 때 — OpenClaw Workboard가 '지금 뭐가 막혔는지'를 보여주는 방법

    오픈소스 개인 AI 어시스턴트 OpenClaw의 관리 화면(Control UI)을 뜯어보다 가장 흥미로웠던 메뉴가 Workboard(작업 보드)였다. 채팅으로 한 가지 일을 시킬 때는 문제가 없다. 하지만 에이전트에게 "이 버그 고쳐", "문서 갱신해", "이 PR 리뷰해"를 동시에 던지는 순간, 사람 머릿속에서 지금 무엇이 대기 중이고, 무엇이 돌고 있고, 무엇이 막혔는지가 금세 흐려진다. Workboard는 그 혼란을 칸반(Kanban) 보드 — 할 일을 상태별 세로 칸에 카드로 늘어놓는 작업 시각화 방식 — 로 풀어낸다. 이 글은 그 문제와 OpenClaw가 고른 답을 따라간다.

    배경 — 에이전트는 어느새 "여러 작업을 동시에 굴리는 작업자"가 됐다

    초기의 AI 어시스턴트는 대화 한 줄에 답 한 줄이었다. 그런데 OpenClaw 같은 에이전트는 스스로 도구를 쓰고, 코드를 고치고, 외부 명령을 돌린다. 작업 하나가 몇 분에서 몇십 분씩 걸리고, 그동안 사람은 다른 작업을 또 시킨다. 결국 한 에이전트가 여러 개의 오래 걸리는 작업을 병렬·순차로 들고 있게 된다. OpenClaw는 이 작업 하나하나를 카드로 만들고, 카드가 거쳐 가는 단계를 9개의 상태로 못 박았다.

    diagram

    다이어그램 설명. 위 그림은 작업 카드 하나가 태어나서 완료되기까지 거치는 9단계 흐름을 보여준다. 맨 위 "분류 전" 칸으로 일이 들어오면, "언젠가 할 일"과 "하기로 정한 일"을 거쳐, 예약 시각을 기다리거나 곧바로 "지금 시작 가능" 칸으로 내려간다. 거기서 에이전트가 집어 들면 "작업 중"이 되고, 끝나면 사람이 확인하는 "review" 칸으로, 실패하거나 선행 작업이 안 끝났으면 "막힘" 칸으로 갈라진다. 핵심은 이 단계가 자유 텍스트가 아니라 고정된 9개 값이라는 점이다 — 코드에서 WORKBOARD_STATUSES라는 배열로 못 박혀 있어, 어떤 카드든 정확히 이 중 하나의 상태에 있다. 놓치기 쉬운 점은 흐름이 한 줄로 쭉 이어지지 않는다는 것이다. "막힘"에서 다시 "시작 가능"으로 되돌아올 수 있고, "작업 중"에서 곧장 "막힘"으로 떨어질 수도 있어, 실제로는 여러 갈래의 상태 그래프다. 사람에게 주는 가치는 명확하다 — "그 일 어떻게 돼 가?"라는 질문의 답이 항상 9개 칸 중 한 곳에 있다.

    핵심 문제 — 손으로 적는 목록은 "셋을 동시에 굴릴 때" 무너진다

    가장 단순한 대안은 평범한 할 일 목록이다. 마크다운 체크리스트를 떠올리면 된다.

    - [ ] 이 버그 고치기
    - [x] 문서 갱신
    - [ ] 이 PR 리뷰

    여기에 "막힘: PR 리뷰 대기 중" 같은 메모를 덧붙이는 것도 얼마든지 가능하다. 그래서 단순 목록의 약점은 흔히 말하는 "상태나 원인을 못 담는다"가 아니다 — 정보는 적으면 된다. 진짜 약점은 두 가지이고, 둘 다 작업이 하나일 땐 안 보이다가 셋이 동시에 돌기 시작하면 드러난다.

    diagram

    다이어그램 설명. 위 그림은 단순 목록의 두 약점과, 그것이 언제 터지는지를 보여준다. 첫째, 목록은 사람이 손으로 갱신해야 한다. 그런데 30분씩 걸리는 에이전트 세션(한 작업을 처리하려고 띄운 실행 단위)이 셋씩 병렬로 돌면, 12분째 죽은 세션을 사람이 그 순간 보고 있을 수가 없다. 목록이 틀려서가 아니라, 진실이 움직였는데 내 손이 안 움직여서 낡는다 — 읽는 시점엔 이미 몇 분 전 기록이다. 기록을 못 하는 게 아니라, 갱신하는 노동을 사람이 결국 빼먹는다. 둘째, 목록은 사람이 읽는 메모일 뿐, 시스템이 작업을 굴리는 손잡이가 아니다. 뒤에서 볼 일괄 배차·점유·의존성 게이트는 모두 작업이 "오케스트레이터가 읽고 쓸 수 있는 구조화된 객체"여야 동작한다 — 마크다운 체크박스는 한 번에 배차할 수도, 두 탭이 동시에 집어 가지 않게 점유할 수도, 다른 항목이 끝나야 시작하도록 묶을 수도 없다. 카드는 조정 단위(coordination object)이고, 목록은 메모다. "왜 목록이 아니라 카드여야 하나"의 답이 여기 있다. 함정은 작업이 하나일 때는 이 둘이 다 사소해 보인다는 것이다. 동시에 여러 개가 돌기 시작하는 순간 "지금 뭐가 막혔지?"라는 질문에 사람이 답을 못 하게 된다 — 자율 에이전트의 통제권을 잃는 지점이다.

    해결 방법 — 카드를 살아 있는 시스템 상태에 묶는다

    Workboard의 핵심 발상은 "카드 상태를 사람이 손으로 옮기는 게 아니라, 실제 에이전트 세션의 상태를 읽어 자동으로 맞춘다"는 것이다. 카드에는 그 작업을 실행 중인 세션 키(sessionKey)가 붙고, 보드는 그 세션이 살아 있는지·끝났는지·실패했는지를 주기적으로 확인해(폴링) 카드를 알맞은 칸으로 옮긴다. 즉 보드는 정적인 메모가 아니라 시스템 상태의 거울이다.

    diagram

    다이어그램 설명. 위 그림은 보드가 살아 있는 세션 상태를 읽어 카드를 어느 칸에 둘지 판단하는 규칙을 보여준다. 가운데 판단 단계에서 갈라지는 네 갈래가 핵심이다 — 세션이 돌고 있으면 "작업 중" 칸, 정상으로 끝났으면 사람이 확인할 "review" 칸, 실패·취소·시간 초과로 끝났으면 "막힘" 칸으로 카드를 자동으로 옮긴다. 가장 흥미로운 건 맨 아래 갈래다. 세션이 형식상 "실행 중"이라고 보고하지만 30분(WORKBOARD_STALE_SESSION_MS) 넘게 아무 활동이 없으면, 칸은 "작업 중"으로 두되 카드에 stale(정체) 경고 배지를 붙인다 — "돌고 있다고는 하는데 실은 멈춘 것 같다"를 사람에게 알리는 신호다. 왜 이 패턴인가? 앞서 본 약점 ①(손으로 갱신해야 해서 읽는 순간 이미 낡는 목록)을 뿌리째 없애기 때문이다. 사람이 카드를 옮기는 게 아니라 시스템이 옮기니, 갱신을 빼먹을 사람이 애초에 없고 보드는 항상 진짜 상태를 가리킨다. 놓치기 쉬운 함정은 "자동이니까 사람이 손 못 댄다"는 오해인데, 그렇지 않다. 자동 동기화는 정해진 전이(예: "시작 가능"→"작업 중", "작업 중"→"review")에만 적용되고(shouldSyncCardStatus), 사람이 직접 드래그한 상태는 함부로 덮어쓰지 않는다.

    의존성 — "먼저 끝나야 할 일"이 안 끝나면 시작도 안 시킨다

    작업끼리 순서가 있을 때가 많다. "설계 카드가 끝나야 구현 카드를 시작"하는 식이다. Workboard는 카드 사이에 parent(선행) 링크를 걸 수 있고, 선행 카드가 모두 "done"이 되기 전에는 후행 카드를 자동으로 시작시키지 않는다.

    diagram

    다이어그램 설명. 위 그림은 후행 작업을 언제 시작시킬지 판단하는 의존성 게이트를 보여준다. "지금 시작 가능" 칸에 있는 구현 카드라도, 판단 단계에서 선행 카드 상태를 먼저 확인한다 — 하나라도 "done"이 아니면 시작을 보류하고 카드에 "몇 개의 선행 작업을 기다리는 중"이라는 배지를 붙이며, 전부 끝났을 때만 실행 후보가 된다(getWorkboardDependencyState가 끝나지 않은 선행 카드들을 추려 낸다). 왜 이 패턴인가? 앞서 본 약점 ②(목록은 메모일 뿐 시스템이 굴리는 손잡이가 아니다)에 직접 답하기 때문이다. 카드가 서로를 가리키는 구조화된 객체라서, 시스템이 "선행이 다 끝났나"를 스스로 판정해 시작을 막거나 풀 수 있다 — 체크박스 하나를 다른 체크박스에 묶는 일은 평범한 목록으로는 아예 안 된다. 덤으로, 막혔다는 사실만이 아니라 "무엇 때문에" 막혔는지 — 어떤 선행 작업이 안 끝났는지 — 가 배지로 그 자리에 남는다. 놓치기 쉬운 점은 이 게이트가 "막힘" 칸과 다르다는 것이다. 의존성 대기는 "준비됐지만 차례가 아직 안 온" 상태고, "막힘"은 "시도했는데 실패했거나 명시적으로 차단된" 상태다. 둘을 섞으면 사람이 "이건 손봐야 할 막힘인가, 그냥 기다리면 풀릴 대기인가"를 구별 못 한다.

    핸드오프 — 채팅 세션 하나를 작업 카드로 넘긴다

    흥미로운 기능 하나는 세션 핸드오프다. 채팅 창에서 즉흥적으로 시작한 대화가 "어, 이거 제대로 추적해야 할 작업인데?"로 커지는 순간, 그 세션을 통째로 Workboard 카드로 승격할 수 있다(captureSessionToWorkboard). 임시 대화를 정식 작업으로 인계(handoff)하는 것이다.

    diagram

    다이어그램 설명. 위 그림은 채팅 세션을 작업 카드로 승격하는 핸드오프 흐름을 보여준다. 채팅에서 돌던 세션에 "보드로 보내기"를 실행하면, 보드는 먼저 그 세션에 이미 연결된 카드가 있는지 확인하고 — 있으면 새로 만들지 않고 기존 카드를 돌려주며(중복 방지), 없을 때만 새 카드를 만들어 세션 키와 그동안의 대화 맥락을 붙인다. 그 순간부터 이 작업은 채팅 안의 일회성 대화가 아니라 보드 위에서 상태가 추적되는 정식 작업이 된다. 왜 이 패턴인가? 사람의 실제 작업 흐름이 "처음부터 계획된 작업"보다 "대화하다 발견한 작업"인 경우가 많기 때문이다 — 가볍게 시작한 대화를 버리거나 다시 만들 필요 없이 그대로 작업 큐에 얹는다. 함정은 중복 생성이다. 같은 세션을 두 번 보내면 카드가 두 개 생길 것 같지만, 세션 키로 기존 카드를 먼저 찾아 막아 둔다.

    오케스트레이션 — "준비된 카드"를 한 번에 집어 실행시킨다

    카드가 "지금 시작 가능"으로 모이면, 사람이 하나씩 클릭해 돌릴 필요 없이 dispatch(일괄 배차) 한 번으로 준비된 카드들을 에이전트에게 한꺼번에 넘긴다. 각 카드는 실행 엔진을 고를 수 있다 — Codex(OpenAI 계열)나 Claude(Anthropic 계열) 중 하나, 그리고 자율(autonomous)·수동(manual) 모드 중 하나.

    diagram

    다이어그램 설명. 위 그림은 일괄 배차가 준비된 카드들을 어떻게 처리하는지 보여준다. 배차를 실행하면 "지금 시작 가능" 칸의 카드들을 훑으며, 판단 단계에서 두 조건 — 선행 의존성이 충족됐는가, 그리고 다른 작업자가 이미 그 카드를 점유(claim)하지 않았는가 — 을 확인한다. 둘 다 통과하면 세션을 띄워 "작업 중"으로 승격하고, 이미 점유된 카드는 건너뛴다. 마지막에 "시작 몇 개, 승격 몇 개, 막힘 몇 개, 실패 몇 개, 재회수 몇 개"라는 한 줄 요약이 나온다. 왜 점유 확인이 필요한가? 여러 작업자(또는 여러 브라우저 탭)가 동시에 배차를 눌러도 같은 카드를 두 번 실행하지 않게 막기 위해서다 — 점유에는 소유자 ID와 주기적 하트비트(살아 있음 신호)가 붙어, 점유한 작업자가 죽으면 점유가 풀려 다른 쪽이 재회수(reclaim)할 수 있다. 함정은 "배차 = 전부 실행"이라는 오해다. 실제로는 준비됐고 점유 안 된 카드만 골라 실행하므로, 막힌 카드나 남이 잡은 카드는 자연히 빠진다.

    건강 지표 — "지금 뭘 봐야 하는가"를 숫자 한 줄로

    동시에 여러 작업이 돌 때 사람의 진짜 질문은 "전체 중 위급한 게 몇 개냐"다. Workboard는 보드 상단에 6개의 건강 지표를 띄우고, 각 숫자를 누르면 해당 카드만 걸러 보여 준다.

    diagram

    다이어그램 설명. 위 그림은 보드 상단 건강 지표 6칸이 무엇을 세는지 보여준다. 돌고 있는 작업·막힌 작업·멈춘 듯한 작업의 개수는 물론, "준비됐는데 아무도 안 맡은 작업"(방치 신호), "완료라 표시됐지만 검증 증거가 없는 작업"(성급한 완료 신호), "실패한 시도 횟수"까지 한 줄로 집계한다(summarizeWorkboardHealth). 각 숫자는 버튼이라, 예컨대 "막힘 3"을 누르면 막힌 카드 3장만 걸러 보여 준다. 왜 이 패턴인가? 두 약점이 한꺼번에 터지는 조건 — 작업 셋이 동시에 도는 상황 — 에 답하기 때문이다. 수십 장의 카드를 다 훑지 않고도 "지금 손이 필요한 곳"으로 사람을 곧장 데려간다. 게다가 이 숫자들이 믿을 만한 건 카드 상태가 사람 손이 아니라 시스템이 유지한 값이기 때문이다(약점 ①이 해소된 결과) — 손으로 적은 목록에서 "막힘 3"은 마지막 편집 시점만큼만 사실이지만, 여기선 항상 지금 이 순간의 사실이다. 특히 "완료인데 증거 없음" 지표가 영리하다. 에이전트가 "다 했다"고 카드를 done으로 옮겨도, 테스트 통과 같은 증거(proof)가 안 붙어 있으면 이 숫자로 잡혀, 사람이 "정말 끝난 게 맞나"를 되짚게 한다. 함정은 이 숫자들을 단순 통계로만 보는 것이다 — 실은 각각이 "사람이 개입해야 할 종류"를 가리키는 주의 신호다.

    결과 — 무엇이 좋아졌나

    이 구조가 들어오면서 앞서 본 두 약점이 이렇게 정리된다.

    단순 할 일 목록 Workboard (살아 있는 칸반)
    손으로 갱신해야 해 읽는 순간 이미 낡음 세션 상태를 읽어 카드를 자동으로 알맞은 칸에 배치
    메모일 뿐이라 배차·점유·의존성 묶기를 못 함 오케스트레이터가 배차·점유·게이트하는 구조화된 카드
    동시에 셋 돌면 무엇부터 볼지 모름 건강 지표 6칸으로 위급한 카드만 걸러 보기
    멈춘 작업을 산 작업으로 착각 30분 무응답이면 stale 경고로 정체를 드러냄
    채팅에서 발견한 일을 따로 옮겨 적어야 함 세션을 카드로 핸드오프 — 중복 없이 한 번에 승격

    정리하면, OpenClaw Workboard는 에이전트의 작업 큐를 "사람이 적는 메모"에서 "시스템이 그려 주는 거울"로 바꾼 메뉴다. 카드 9개 상태와 살아 있는 세션 사이를 자동으로 동기화하고, 막힘의 원인을 구분해 보여 주고, 위급한 것만 골라 띄운다. 에이전트가 작업 셋을 동시에 굴려도 사람은 보드 한 장으로 "지금 무엇이 대기·진행·막힘인지"를 통제할 수 있다. 화려한 AI 기능 이전에, 이렇게 "여러 자율 작업을 사람이 한눈에 통제하는 시야"가 사실 멀티태스킹 에이전트의 진짜 전제 조건이다 — 통제할 수 없는 자율은 결국 사람이 다시 하나씩 들여다봐야 하기 때문이다.


    이 글은 생성형 AI의 도움을 받아 작성되었습니다. 원본 자료를 기반으로 AI가 초안을 생성하고, 작성자가 검토·편집하였습니다.

Designed by Tistory.