동시에 몇 개 돌릴까

이 프로젝트의 상한 - 워커 수

프로젝트 설정에서 "동시 실행 3개까지" 같은 칸을 찾고 계신다면 없습니다. 이 프로젝트에서 동시에 도는 세션 수의 상한은 워커 표에 뜬 워커 수입니다. 워커가 하나면 큐에 티켓이 아무리 쌓여도 한 번에 한 세션이고, 둘이면 둘입니다. 그 표에 뜬 워커는 전부 이 프로젝트 것이라 셈이 그대로 맞습니다.

상한은 하나 더 있습니다. 이 컴퓨터 전체에 걸리는 상한이고, 등록한 프로젝트 전부가 그 값 하나를 나눠 씁니다. 워커 수와는 별개로 세는 값이라 다음 절에서 따로 다룹니다.

이 프로젝트를 더 빨리 돌리시려면 워커를 만드세요. 만드는 자리는 워커 §워커 생성이고, 누르는 것은 한 번입니다.

이 컴퓨터의 상한 - 머신 전체 세션 상한

프로젝트를 여러 개 등록해 두면 워커 수를 다 더한 값이 금방 열을 넘어갑니다. 세션 하나가 claude 프로세스 하나라서, 여섯 개가 동시에 뜨면 CPU와 메모리도 여섯 개만큼 듭니다. 그래서 프로젝트 단위 상한 위에 상한이 하나 더 걸려 있습니다. 이 컴퓨터에서 한꺼번에 뜰 수 있는 세션 수이고, 등록된 프로젝트 전부가 이 값 하나를 나눠 씁니다. 기본값은 6입니다.

이 상한이 세는 것은 지금 살아 있는 세션입니다. 워커 수는 안 봅니다. 워커가 아무리 많아도 그 가운데 넷만 티켓을 맡고 있으면 살아 있는 세션은 넷입니다.

지금 몇 개가 떠 있나 - 설정 › 워커

헤더 오른쪽 끝의 톱니로 설정을 열고, 왼쪽 트리 설정 분류 그룹 맨 아래의 워커를 고르세요. 패널 맨 위 섹션이 머신 전체 세션 상한입니다. 필터 둘과 전체 워커 목록보다 위에 있습니다.

거기 있는 것이 셋입니다.

• 상한 옆의 값. 지금 걸려 있는 상한입니다. 정한 적이 없으면 없음이 뜹니다.
• 합계 한 줄. 머신 전체 4/6처럼 살아 있는 세션 수와 상한을 붙여 보여줍니다. 상한이 없음이면 분모 없이 세션 수만 뜹니다.
• 큐별 한 줄씩. 등록된 프로젝트가 전부 한 줄씩 뜨고, 세션을 하나도 쓰지 않는 프로젝트는 0입니다. 합계만으로는 여섯 개가 한 프로젝트에 몰렸는지 세 곳으로 나뉘었는지 알 수 없습니다. 그것을 확인하는 자리가 이 목록입니다.

합계가 상한에 닿으면 그 아래 한 줄이 더 붙습니다.

지금 상한에 차 있어 새 세션이 안 뜹니다.

값을 못 읽으면 상한이 없는 것으로 보고, 상한 아래에 session-limit을 읽지 못했습니다 — 상한 없음으로 읽습니다.가 뜹니다.

이 패널은 다이얼로그를 열 때 한 번만 읽습니다. 열어 둔 채로는 수가 안 바뀌니 닫았다 다시 여세요.

값을 바꾸는 자리 - 같은 섹션의 상한

상한 옆의 값을 누르면 팝오버가 열립니다. 동시 세션 상한에 정수를 넣고 저장하세요.

비우면 상한이 없어집니다 — 이 컴퓨터에서 한꺼번에 도는 claude 세션 수를 막는 값입니다.

비우고 저장하면 상한 자체가 없어집니다. 0과 다릅니다. 0은 세션을 하나도 못 띄우게 막고, 비운 것은 상한을 아예 걸지 않습니다.

기본값 6은 이 컴퓨터에서 재어 정한 수가 아닙니다. 개발하면서 쓴 컴퓨터에서 나온 값이라, 코어와 메모리가 더 넉넉하면 올리세요. 다른 일을 하면서 같이 돌린다면 내리고, 올린 뒤에 컴퓨터가 버벅이면 도로 내리세요.

워커를 만들 때 - 이름 칸 아래에 그 수가 뜹니다

워커 생성을 누르면 이름 칸 아래에 보조 줄이 둘 붙습니다. 위가 지금 수(머신 전체 4/6)이고, 상한을 정한 적이 없으면 그 자리에 머신 전체 상한 없음이 뜹니다. 아래가 그 수의 뜻입니다.

세션을 한꺼번에 여러 벌 띄우면 이 컴퓨터의 성능에 영향을 주기 때문에, 동시에 뜨는 세션 수에 상한을 둡니다.

수가 상한에 닿아 있어도 만들기는 잠기지 않습니다. 워커를 하나 더 만드는 것과 세션을 하나 더 띄우는 것은 다른 일입니다. 워커는 티켓을 맡아 갈 자리이고, 세션은 그 자리에서 실제로 뜬 claude입니다.

워커 수로 막았다면 곧바로 다른 문제가 생깁니다. 등록된 프로젝트 전부의 워커를 다 더하면 스물이 넘고 상한은 6이라, 워커 수를 기준으로 막는 순간 어느 프로젝트에서도 만들기를 못 누릅니다. 상한에 닿았을 때 필요한 것은 지금 몇 개가 떠 있는지 아는 것입니다. 그래서 이 폼은 막는 대신 그 수를 보여줍니다.

거꾸로 상한에 걸려 있는 동안에는 워커를 더 만들어도 이 프로젝트가 더 빨리 돌지 않습니다. 자리가 없어서 안 도는 것이라 티켓을 맡을 워커를 늘려도 자리가 늘어나지는 않습니다.

상한 때문에 굶는지 알아보는 법

큐에 티켓이 쌓여 있는데 아무것도 안 돌 때, 원인이 이 상한인지는 두 자리를 차례로 보면 알 수 있습니다.

먼저 설정 › 워커의 합계를 보세요.

• 합계가 상한에 닿았다. 이 컴퓨터가 꽉 찼습니다. 그 자리를 누가 쓰고 있는지는 바로 아래 큐별 목록에 있습니다. 대개 다른 프로젝트이니, 기다리거나 상한을 올리거나 그 프로젝트의 워커를 중단하세요.
• 합계가 상한보다 작은데도 안 돈다. 상한 자체에는 아직 여유가 있습니다. 로그를 한 줄 더 봐야 합니다.

<루트>/workers/runner.log에 남는 문장이 둘이고 서로 다릅니다(로그 참고).

둘 다 없으면 원인은 이 상한이 아닙니다. 아래 §워커 수보다 낮아지는 세 자리에서 앞의 둘을 보세요. 두 줄은 티켓을 건드리지 않고 그 회차만 넘깁니다. 걸린 티켓은 대기에 그대로 남고 다음 회차에 다시 후보가 됩니다.

몫 - 한 프로젝트가 상한을 다 쓰지 못하게

상한이 선착순이기만 하면 워커가 많은 프로젝트가 빈 자리를 계속 다시 가져가고 워커가 적은 프로젝트는 티켓을 쌓아 둔 채 굶습니다. 실제로 그 일이 있었습니다. 세션 여섯 개 가운데 다섯 개가 한 프로젝트 것이었고, 열린 티켓 다섯 장을 둔 프로젝트는 0개였습니다.

그래서 상한 안에서 몫을 나눕니다. 몫은 상한을 지금 일감이 있는 프로젝트 수로 나눈 값이고 최소 1입니다. 상한이 6이고 일감이 있는 프로젝트가 셋이면 몫이 2, 일곱이면 1입니다. 자기 몫을 이미 채운 프로젝트는 세션을 하나도 못 띄우고 굶는 프로젝트가 있으면 그 회차를 건너뜁니다.

• 굶는 프로젝트가 없으면 남는 자리는 선착순 그대로입니다. 상한 6에 일감 있는 프로젝트가 넷이면 몫이 1이고, 남는 두 자리는 먼저 온 쪽이 가져갑니다. 나눗셈 때문에 자리를 비워 두지는 않습니다.
• 일감이 있는 프로젝트로 세는 조건이 둘입니다. 열린 티켓이나 주인이 죽은 진행중 티켓이 하나라도 있어야 하고 그 프로젝트의 워커가 최근 2분 안에 실제로 돌았어야 합니다. 티켓만 쌓아 놓고 워커를 꺼 둔 프로젝트는 세지 않습니다. 세면 그 프로젝트 몫으로 비워 둔 자리를 아무도 안 가져가서 그대로 남습니다.
• 이 판정은 프로젝트마다 자기 워커가 스스로 합니다. 순번을 적어 두고 돌리는 표가 없으니 프로젝트를 더하거나 빼도 따로 맞출 것이 없습니다.

이기적 모드 - 자는 동안 이 컴퓨터를 큐에 몰아주기

퇴근하거나 잠들기 전에 켜는 모드입니다. 켜면 지금 떠 있는 앱을 내려서, 그 앱들이 쓰던 CPU와 메모리를 세션 쪽으로 돌립니다. 브라우저와 메신저를 띄워 둔 채 일하는 시간에 켜면 하던 일이 닫히니, 업무 시간에는 켜지 마세요.

자리는 설정 › 워커의 머신 전체 세션 상한 섹션 바로 아래, 이기적 모드 섹션입니다. 상한과 마찬가지로 이 컴퓨터에 걸리는 값이라 프로젝트 설정에는 없습니다.

지금 켜기와 매일 예약

바로 켜려면 지금 켜기를 누르세요. 30초 카운트다운과 함께 내려갈 앱 목록이 뜹니다. 목록에 남겨야 할 앱이 보이면 30초 안에 취소를 누르세요. 취소하면 아무것도 바뀌지 않습니다. 30초가 지나면 켜지고, 같은 자리의 버튼이 끄기로 바뀝니다. 끄기를 누르면 그 자리에서 꺼지지만 내렸던 앱을 다시 띄우지는 않습니다.

매일 같은 시각에 켜고 끄려면 같은 섹션에서 시작 시각과 끝 시각을 정해 저장하세요. 기본값은 23:00에 켜고 07:00에 끄는 것입니다. 시작 시각에 이미 켜져 있으면 그 회차는 건너뛰고, 끝 시각에 켜져 있으면 끕니다.

예약을 저장하는 순간과 지금 켜기를 누르는 순간, macOS가 dira 앱이 다른 앱을 제어해도 되는지 묻는 창을 처음 한 번 띄웁니다. 밤 11시에 아무도 없는 화면에 그 창이 뜨면 모드가 켜지지 않으므로, 미리 묻게 해 둔 것입니다. 허용하세요. 거절하면 섹션에 거절했다는 안내가 뜨고 예약은 저장되지 않습니다.

내려가는 앱과 남는 앱

내리는 대상은 Dock에 아이콘이 뜨는 일반 앱입니다. 화면 없이 뒤에서 도는 데몬이나 입력기는 건드리지 않습니다.

다음 앱은 기본으로 제외 목록에 들어 있어 남습니다.

• dira 앱 자신, Finder, Terminal, iTerm2
• Google Drive, Amphetamine, 1Password, 1Password 7
• 이름에 VPN이 들어간 앱

밤새 켜 두어야 하는 앱이 따로 있으면 섹션의 제외 목록에 이름을 더하세요. 빼고 싶은 앱은 목록에서 지우면 됩니다.

강제 종료는 하지 않습니다. 앱마다 일반 종료를 한 번 요청하고 10초를 기다립니다. 저장하지 않은 문서가 있는 앱은 저장할지 묻는 창을 띄운 채 그대로 남고, 모드는 그 앱을 내리지 못한 것으로 적어 둡니다. 문서를 잃지 않게 하려고 이렇게 정했습니다. 밤새 내려가 있기를 바라는 앱이 있으면 켜기 전에 저장해 두세요.

상한은 비워 두세요

섹션에 상한을 넣는 칸이 있습니다. 정수를 넣으면 켜는 동안 위 §이 컴퓨터의 상한에서 다룬 머신 전체 세션 상한을 그 값으로 바꾸고, 끌 때 켜기 전 값으로 되돌립니다. 켜기 전에 상한이 없었다면 끈 뒤에도 없습니다. 비워 두면 상한은 그대로이고 앱만 내립니다. 기본값이 비어 있는 것입니다.

비워 두라고 권하는 이유는 아직 재 본 수가 없기 때문입니다. 앱만 내렸을 때 얼마나 더 도는지를 먼저 보고, 그다음에 상한을 올릴지 정하세요. 지난 실행 칸에 상한 때문에 건너뛴 회차가 많이 찍혀 있다면 올려 볼 때입니다.

상한을 바꿔서 동시 수가 실제로 늘어나는 것은 머신 상한을 읽는 훅(.dira/session-cap.sh)을 단 프로젝트뿐입니다. 앱을 내리는 효과는 등록한 프로젝트 전부에 돌아갑니다.

아침에 - 지난 실행 칸

모드가 꺼질 때마다 섹션의 지난 실행 칸이 새로 채워집니다. 마지막 한 번만 보여 줍니다.

• 몇 시부터 몇 시까지 켜져 있었는지
• 내린 앱 수와 못 내린 앱 이름. 이름이 있다면 저장 안 한 문서가 남아 있다는 뜻일 가능성이 큽니다. 그 앱을 열어 보세요.
• 프로젝트마다 한 줄. 디스패치 수, 완료 수, STALL 비율, 상한 때문에 건너뛴 회차 수, 계정 한도로 죽은 세션 수, 마지막 디스패치 시각입니다.

숫자는 그 시간 동안 프로젝트마다 <루트>/workers/runner.log에 찍힌 줄을 센 값입니다. 한도로 죽은 세션이 많다면 컴퓨터가 아니라 계정이 먼저 바닥났다는 뜻입니다. 마지막 디스패치가 새벽 일찍 멈춰 있다면 큐가 비었거나 다른 데서 막힌 것입니다.

앱을 꺼 두면 예약이 돌지 않습니다

예약은 dira 앱이 켜져 있을 때만 돕니다. 시각을 재는 것이 앱 안의 하트비트라, 앱을 닫아 두면 23:00가 지나도 모드가 켜지지 않습니다. 켜 둔 채 앱을 닫았다면 07:00에 끄는 일도 일어나지 않습니다. 그때는 다음에 앱을 열면 첫 하트비트가 지난 회차를 한 번 돌아 모드를 끄고 상한을 되돌립니다. 밤새 쓰려면 dira 앱을 띄워 둔 채 두세요.

워커 락 - 한 번에 티켓 1건

워커는 동기 프로세스입니다. 한 번에 한 가지 일만 한다는 뜻이라, 맡은 티켓의 세션이 끝날 때까지 다음 티켓을 가져가지 않습니다.

cron은 30초마다 그 워커를 부르지만, 앞 실행이 아직 세션을 쥐고 있으면 이번 호출은 그냥 넘어갑니다. 워커 락이 그 자리를 막기 때문입니다. 락은 "이 워커는 지금 일하는 중"이라고 걸어 두는 표시고, 덕분에 두 실행이 같은 티켓을 동시에 가져갈 일도 한 워커가 세션 둘을 띄울 일도 없습니다.

w1이 티켓 하나를 30분 맡고 있어도 w2는 그동안 다른 티켓을 가져갑니다. 워커 여럿을 두는 이유가 정확히 그것입니다.

세션이 무한정 붙잡는 것도 막혀 있습니다. 기본 5400초를 넘기면 세션을 끊고 티켓은 대기로 돌아갑니다. 그다음 호출에서 같은 워커든 다른 워커든 다시 가져갑니다. 그 값을 바꾸는 것은 워커 환경변수의 TICKET_MAXRUN입니다.

즉시 디스패치 - cron을 기다리지 않고 지금 띄우기

cron이 30초마다 워커를 부르므로 티켓을 만들고 가만히 두어도 30초 안에 워커가 가져갑니다. 즉시 디스패치는 그 30초를 줄이는 장치입니다. 즉시 디스패치가 워커를 띄우지 않아도 잃는 것은 없습니다. 다음 cron 회차가 같은 일을 합니다.

띄울지, 띄운다면 어느 워커로 띄울지는 엔진의 dispatch.py 한 곳이 정합니다. cron도 화면도 MCP도 세션도 이 모듈을 부르고, 워커를 직접 고르지 않습니다. 워커가 뜬 뒤에 어느 티켓을 집을지는 전과 같이 tick.sh가 정합니다.

사유 넷 - 누가 부르고 언제 뜨는가

부르는 쪽은 사유를 하나 붙입니다. 사유마다 따지는 조건이 다릅니다.

request는 사람이 요구를 방금 넣은 순간이라, 쉬는 워커가 하나라도 있으면 그 요구를 바로 띄웁니다. 큐에 먼저 기다리던 티켓이 있어도 요구가 그 뒤에 줄을 서지 않습니다. direct도 사람이나 화면이 "지금"이라고 한 것이라 부하와 다른 후보를 따지지 않습니다. 네 조건을 다 따지는 사유는 judge 하나입니다. judge는 큐에 다른 후보가 한 건이라도 있으면 띄우지 않고, 이미 기다리는 티켓을 앞지르지 않은 채 cron 차례를 기다립니다.

홈 대화에서 요구를 넣으면 대화 턴이 끝난 뒤에 앱이 request를 부릅니다. 그 턴에 새 요구 파일이 생겼고 아직 아무 워커도 가져가지 않았을 때만 부르고, 요구를 만들지 않은 턴에는 부르지 않습니다. 그래서 홈 대화의 답이 다 나오기 전에는 KICK 줄도 생기지 않습니다.

세션이 judge로 부르는 때는 셋입니다. 사람이 지금 대화에서 기다리는 티켓을 만들었을 때, 자기가 닫는 티켓이 다른 티켓의 deps를 풀어 줄 때, 자기가 낸 핸드오프가 끝나야 이어받기가 갈 수 있을 때입니다. 그 밖의 발행에서는 부르지 않고 cron에 맡깁니다.

쉬는 워커란 crontab에 그 워커 파일이 등록되어 있고 워커 락이 걸려 있지 않은 워커입니다. 여럿이면 이름 오름차순으로 첫 워커를 고릅니다. 워커 락은 위 §워커 락에서 다룹니다.

부하 상한 바꾸기 - ~/.config/dira/dispatch.json

부하를 따지는 사유는 judge 하나뿐입니다. 이 컴퓨터의 1분 평균 부하(uptime이 보여 주는 첫 숫자)가 상한을 넘으면 띄우지 않습니다. 상한의 기본값은 이 컴퓨터의 CPU 코어 수입니다.

바꾸려면 ~/.config/dira/dispatch.json을 만들고 load_max에 실수를 넣으세요.

{ "load_max": 6.0 }

파일이 없거나 load_max 키가 없으면 코어 수로 돌아갑니다. 화면에는 이 값을 고치는 칸이 없습니다. 아래 KICK-SKIP 줄을 며칠 보고, 부하 때문에 건너뛴 줄이 많을 때 올리세요.

왜 안 떴는지 - runner.log의 KICK 줄

즉시 디스패치는 판정할 때마다 <루트>/workers/runner.log에 한 줄을 남깁니다.

<날짜> <시각> [dispatch] KICK <사유> <해시 또는 -> <워커>
<날짜> <시각> [dispatch] KICK-SKIP <사유> <해시 또는 -> <안 띄운 이유>

• KICK 줄은 그 워커를 띄웠다는 뜻입니다. 해시 자리가 -면 해시 없이 띄운 것이라 워커가 큐 맨 앞 티켓을 집습니다. 실제로 티켓을 가져갔는지는 같은 워커의 DISPATCH 줄로 확인합니다.
• KICK-SKIP 줄은 안 띄웠다는 뜻이고, 마지막 칸에 걸린 조건이 문장으로 적혀 있습니다. 부하가 상한을 넘었는지, 쉬는 워커가 없었는지, 다른 후보가 있었는지, 그 티켓이 후보가 아니었는지 가운데 하나입니다. request 줄에는 이 가운데 쉬는 워커가 없었다는 것과 후보가 아니었다는 것만 나옵니다.
• cron 사유는 아무 줄도 남기지 않습니다. 30초마다 줄이 쌓이기 때문입니다. cron 회차의 결과는 전처럼 워커 이름이 붙은 DISPATCH-SKIP 줄로 봅니다(로그 참고).

요구를 넣었는데 바로 안 떴다면 runner.log에서 그 해시가 붙은 request 줄을 찾으세요.

• KICK-SKIP request <해시> idle 워커가 없다라면 쉬는 워커가 없던 것입니다. 워커가 모두 다른 티켓을 하고 있었거나 crontab에서 빠져 멈춘 상태였습니다. 워커 하나가 끝나면 cron이 30초 안에 집습니다. 늘 이렇다면 워커를 늘리세요(위 §이 프로젝트의 상한).
• KICK-SKIP request <해시> 그 해시는 후보가 아니다라면 대개 그 사이에 다른 워커가 이미 가져갔거나 deps가 아직 안 풀린 것입니다.
• 줄이 아예 없다면 즉시 디스패치가 불리지 않은 것입니다. 홈 대화라면 턴이 끝났는지 먼저 보고, 그 밖에는 cron 쪽을 보세요.

띄우지 않고 판정만 보려면 --dryrun을 붙여 직접 부르세요. 엔진 디렉터리는 tick.sh가 있는 곳입니다.

python3 <엔진>/dispatch.py run <루트> --reason request --hash <해시> --dryrun

결과는 한 줄 JSON으로 나옵니다. go가 true면 띄울 것이고, false면 why에 이유가 있습니다. --dryrun은 워커를 띄우지도 로그를 적지도 않고, 큐를 한 글자도 고치지 않습니다.

지금 띄우기 - MCP dispatch_now

MCP 클라이언트에서 지금 워커를 띄우려면 dispatch_now를 부르세요. 인자는 둘 다 선택입니다.

사유는 direct라 부하와 다른 후보를 따지지 않습니다. 응답은 위 --dryrun과 같은 모양의 JSON이고, 안 떴으면 why를 읽으세요. 원래 있던 dispatch 도구는 워커 이름을 꼭 받아 그 워커를 한 번 돌릴 뿐이고 쉬는 워커를 고르지 않습니다.

MCP로 ticket_create를 불러 요구 티켓을 만들면 request 사유가 같이 불리고, 그 판정 JSON이 응답의 dispatch 키에 실립니다.

워커 수보다 낮아지는 세 자리

워커가 다섯인데 세 개만 돌고 있다면 큐에 후보가 없거나, 아래 셋 가운데 하나에 걸렸습니다.

• 페르소나 상한. 페르소나 §디스패치 정책의 상한입니다. 2로 두면 그 페르소나 티켓이 열 건 밀려 있어도 동시에 두 건까지만 돕니다. 상한에 걸린 워커는 다른 페르소나의 다음 후보로 넘어가므로, 한 페르소나가 막혔다고 나머지가 굶지는 않습니다.
• 우선순위 1. 유효 우선순위가 1인 티켓은 진행중이 0건일 때만 후보입니다. 다른 티켓이 하나도 안 도는 조용한 때에만 가져가라는 뜻이라, 워커를 여럿 켜 두면 오히려 늦게 돕니다. 급한 일에 1을 쓰지 마세요.
• 머신 전체 세션 상한. 다른 프로젝트 때문에 걸리는 자리라 앞의 둘과 성격이 다릅니다. 이 컴퓨터가 이미 꽉 찼거나, 상한에는 여유가 있는데 이 프로젝트가 자기 몫을 다 쓴 경우입니다. 판정은 위 §상한 때문에 굶는지 알아보는 법에 있습니다.

앞의 둘은 로그에 SKIP 한 줄로 남습니다. SKIP 페르소나 상한 <이름> 2/2, SKIP 우선순위 1 <해시> — 진행중 3건처럼 사유가 그대로 적혀 있습니다. 워커 화면의 마지막 활동을 펼치면 왜 안 가져갔는지 그 자리에서 보입니다.

토큰과 충돌 - 늘리면 같이 늘어나는 것

워커를 늘리면 처리량만 늘어나지 않습니다.

• 토큰. 워커 다섯이 동시에 돌면 토큰도 다섯 배로 나갑니다. 한도는 머신과 계정마다 하나라 워커 전원이 그 하나를 나눠 씁니다. 워커별 한도는 없습니다. 다른 프로젝트에서 도는 세션도 같은 한도를 나눠 씁니다. 지금 얼마나 썼고 얼마나 남았는지는 화면 맨 아래 토큰 status bar에 있습니다(화면 소개 참고).
• 같은 파일을 동시에 건드릴 위험. 서로 다른 티켓이라도 같은 소스 파일이나 공유 dev DB에 동시에 접근할 수 있습니다(동시 4세션이 컬럼을 드롭한 사례가 있습니다). 워커마다 git 워크트리가 따로여서 소스 쪽은 분리되지만, 데이터베이스나 외부 서비스는 분리되지 않습니다. 엔진이 막지 않는 영역이고, 몇 개를 둘지는 그 위험을 알고 사람이 정합니다.

토큰은 같은 일을 직접 하실 때보다 더 나갈 수 있습니다. 세션이 뜰 때마다 프롬프트가 처음부터 다시 조립되기 때문입니다. 페르소나 프로필과 프로토콜 전문이 매번 새로 실리고, 세션은 티켓 파일도 그 자리에서 처음 읽습니다(페르소나 §프롬프트 조립 순서). 사람이 한 대화를 이어 가면 그 맥락은 한 번만 실립니다. 티켓 열 건은 열 번 싣습니다. 티켓을 끝낼 때도 한 번 더 붙습니다. 세션은 남길 메모리가 있는지 보고, 아카이브 티켓이 따로 하나 더 돌면서 그만큼 더 읽고 더 씁니다(아카이빙과 온톨로지). 워커 수만큼 이 전부가 동시에 일어납니다.

규모는 이렇습니다. 워커 일곱을 쉬지 않고 최대로 돌렸을 때 평균 분당 2.0M 토큰이 나갔습니다. 직접 하시는 쪽은 재 본 적이 없어서 몇 배인지는 적지 않습니다.

둘부터 시작해서 대기 레인이 안 줄면 하나씩 늘리세요. 큐가 비어 있는데 워커만 다섯이면 아무 이득도 없이 cron만 다섯 배로 실행됩니다. 프로젝트를 여러 개 돌리고 있다면 늘리기 전에 설정 › 워커의 합계를 한 번 보세요. 이미 상한에 차 있으면 워커를 늘려도 뜰 자리가 없습니다.

다음은 페르소나입니다.