p-hermes강의 01 · 매니저와 워커
강의 01 · 두 역할01 / 16

매니저는 판단하고, 워커는 끝까지 수행합니다. 이 강의는 두 역할이 무엇을 주고받는지 봅니다.

사용자가 일을 맡기는 길은 두 가지입니다. 매니저를 거치거나, 워커에게 직접 맡기거나.

매니저가 워커에게 맡길 때 둘 사이에 오가는 것은 요청서와 응답서, 두 파일입니다.

요청보고직접 요청같은 대화로 답 · 응답서 없음요청서응답서같은 ID·상태사용자매니저판단·위임·판정워커실행사용자는 매니저와 대화하거나, 워커와 직접 대화합니다매니저가 맡길 때는 요청서와 응답서, 두 파일로만 주고받습니다
사용자
매니저: 판단
요청서 ⇄ 응답서
워커: 수행

강의의 출발점전체 흐름에서 지금 볼 구간을 정합니다.

다음 질문에이전트 하나로는 왜 부족할까요?

나누는 이유02 / 16

에이전트 하나가 모든 것을 기억하며 하기에는, 한 번에 읽을 수 있는 양이 부족합니다.

에이전트 하나가 계획부터 실행 로그까지 모두 들고 있으면, 맥락 창이 차면서 처음 목표와 완료 조건이 밀려납니다.

그래서 목표를 붙드는 쪽과 실행하는 쪽을 나눕니다.

요청서응답서같은 ID·상태사용자매니저판단·위임·판정워커실행목표·경계만요청서 + 실행 로그혼자 다 하면 — 맥락 창 하나에 전부목표·완료 조건로그 1로그 2로그 3로그 4로그 5로그 6로그 7
혼자: 목표가 밀려남
나누면: 매니저는 목표·경계
워커: 요청서 + 로그

이어받은 질문에이전트 하나로는 왜 부족할까요?

다음 질문맡긴 일과 결과는 어떻게 주고받을까요?

파일로 주고받기03 / 16

그래서 일을 나누고, 나눈 경계를 파일로 주고받습니다.

매니저가 요청서 파일을 쓰면, 워커가 그 파일을 읽고 수행한 뒤 응답서 파일을 씁니다.

파일은 세션이 끊겨도 남아, 무엇을 약속했고 무엇이 돌아왔는지 다시 확인할 수 있습니다.

요청보고직접 요청같은 대화로 답 · 응답서 없음요청서응답서같은 ID·상태사용자매니저판단·위임·판정워커실행파일은 세션이 끊겨도 남습니다누가 언제 읽어도 같은 내용 — 약속(요청서)과 결과(응답서)를 다시 대조할 수 있다통신은 파일로만, 대화 채널에 직접 게시하지 않는다
요청서 전달
산출 생성
같은 ID로 응답

이어받은 질문맡긴 일과 결과는 어떻게 주고받을까요?

다음 질문사용자는 언제나 매니저를 거쳐야 할까요?

두 길04 / 16

워커에게는 직접 맡기는 길도 있습니다. 이때는 요청서 없이 같은 대화에서 판단부터 실행까지 이어집니다.

워커에게 직접 맡기면 워커가 그 대화 안에서 판단하고, 고치고, 기록하고, 같은 대화로 답합니다.

요청서와 응답서는 매니저를 거칠 때만 오갑니다. 길이 바뀌어도 워커는 같은 워커입니다.

요청보고직접 요청같은 대화로 답 · 응답서 없음요청서응답서같은 ID·상태사용자매니저판단·위임·판정워커실행요청보고직접 요청같은 대화로 답 · 응답서 없음요청서응답서같은 ID·상태사용자매니저판단·위임·판정워커실행① 매니저에게 맡기기② 워커에게 직접① 매니저에게② 워커에게 직접판단매니저워커실행워커워커주고받는 것요청서 · 응답서없음답매니저가 판정 후 보고같은 대화로 바로
① 매니저에게: 판단은 매니저, 요청서 · 응답서
② 워커에게 직접: 판단도 워커, 같은 대화로 답

이어받은 질문사용자는 언제나 매니저를 거쳐야 할까요?

다음 질문매니저를 거치면 무엇이 달라질까요?

매니저를 거치면05 / 16

역할을 나누면 세 가지가 지켜집니다. 판단의 맥락이 보존되고, 맡긴 일은 끝까지 수행되고, 확인이 따로 이루어집니다.

매니저는 실행 로그 없이 목표와 경계를 붙들고, 워커는 요청서 하나에 집중합니다.

결과 확인은 일을 만들지 않은 매니저가 따로 맡습니다.

요청서응답서같은 ID·상태사용자매니저판단·위임·판정워커실행① 맥락 보존매니저는 실행 로그 없이목표와 경계를 붙든다③ 확인 분리만든 쪽이 아닌 매니저가응답서를 실물과 대조② 끝까지 수행워커는 요청서만 보고응답서까지 한 번에
목표 유지
실행 집중
결과 독립 대조

이어받은 질문매니저를 거치면 무엇이 달라질까요?

다음 질문매니저는 무엇을 직접 하고 무엇을 맡길까요?

핵심 문장

매니저가 판단하고, 워커가 실행합니다.

품질을 좌우하는 판단은 위에 남기고, 오래 걸리는 실행만 아래로 내려보냅니다.

직접 할까, 맡길까07 / 16

무엇을 직접 할지는 일의 무게와 판단의 종류로 정합니다. 읽고 조사하고 작게 고치는 일은 매니저가 직접 합니다.

오래 걸리거나 결과가 큰 일은 워커에게 맡기고, 읽기·조사·작은 수정은 매니저가 직접 합니다.

설계·정책·글의 완성도·시각 결과처럼 품질을 좌우하는 판단은 매니저가 맡고, 실행량만 나눕니다.

위임 판단의 예

수백 개 파일 일괄 변환

긴 실행·큰 산출 → 워커에게 맡김

매니저는 목표와 결과 판정을 맡음

이어받은 질문매니저는 무엇을 직접 하고 무엇을 맡길까요?

다음 질문사용자는 어떤 길을 고를까요?

사용자의 선택08 / 16

사용자도 같은 기준으로 길을 고릅니다. 간단하고 되돌릴 수 있는 일은 워커에게 직접, 어렵거나 창의적인 일은 매니저에게 맡깁니다.

판단이 어렵거나 여러 단계에 걸치는 일은 매니저에게 맡겨, 판단과 확인을 따로 받습니다.

간단하고 되돌릴 수 있는 일은 워커에게 직접 맡겨 바로 결과를 봅니다.

요청보고직접 요청같은 대화로 답 · 응답서 없음요청서응답서같은 ID·상태사용자매니저판단·위임·판정워커실행매니저에게어렵거나 창의적인 일여러 단계에 걸치는 일결과를 따로 확인해야 하는 일워커에게 직접간단한 일되돌릴 수 있는 일결과를 바로 볼 수 있는 일
어렵거나 창의적 → 매니저
간단하고 되돌릴 수 있음 → 워커

이어받은 질문사용자는 어떤 길을 고를까요?

다음 질문역할마다 어울리는 모델의 무게는 어떻게 다를까요?

모델의 무게09 / 16

어울리는 모델의 무게도 역할마다 다릅니다. 가벼운 모델로 워커 일을 맡기면 비용을 아끼고, 무거운 모델로 판단을 맡기면 대화가 쾌적해집니다.

매니저는 사용자와 대화하며 판단하므로, 생각이 깊은 무거운 모델이 어울립니다.

워커는 정해진 일을 길게 실행하므로 가벼운 모델로도 충분합니다. 직접 대화하는 워커는 일의 난이도에 맞춰 고릅니다.

요청서응답서같은 ID·상태사용자매니저판단·위임·판정워커실행무거운 모델 → 매니저판단과 대화가 깊어주고받기가 쾌적하다가벼운 모델 → 워커정해진 일을 길게 실행해도비용이 적게 든다
무거운 모델 → 매니저: 대화가 쾌적
가벼운 모델 → 워커: 비용 절약

이어받은 질문역할마다 어울리는 모델의 무게는 어떻게 다를까요?

다음 질문맡긴다면 요청서에는 무엇을 적을까요?

요청서10 / 16

맡길 때 요청서에 적을 것은 네 칸이면 충분합니다. 목표, 완성 기준, 참조 경로, 금지 범위입니다.

요청서에는 목표, 완성 기준, 참조 경로, 금지 범위를 적습니다. 판단이 필요한 항목은 매니저가 미리 정해 둡니다.

사용자가 말하지 않은 범위 축소나 요청과 무관한 일은 넣지 않습니다.

요청보고직접 요청같은 대화로 답 · 응답서 없음요청서응답서같은 ID·상태사용자매니저판단·위임·판정워커실행목표무엇을 끝낼지완성 기준어떻게 확인할지참조 경로무엇을 읽을지금지 범위무엇은 하지 않을지사용자가 말하지 않은 범위 축소나 요청과 무관한 일은 넣지 않는다
목표
완성 기준
참조 경로
금지 범위

이어받은 질문맡긴다면 요청서에는 무엇을 적을까요?

다음 질문등록된 요청은 어떻게 실행될까요?

등록과 실행11 / 16

등록된 요청에는 한 번의 시도를 뜻하는 요청 ID가 붙고, 작업 실행기가 이어받습니다.

요청서는 정해진 등록 경로 한 곳으로 들어가고, 이때 시도 한 번을 가리키는 요청 ID가 붙습니다. 작업 실행기가 이를 워커에게 넘기고 시간 제한을 지켜봅니다.

같은 목표를 다시 시도하면 새 요청 ID를 받습니다. 실행기가 함께 붙이는 자료 묶음은 강의 03에서 다룹니다.

요청보고직접 요청같은 대화로 답 · 응답서 없음요청서요청 등록ID 발급작업 실행기실행·시간 제한응답서같은 ID·상태사용자매니저판단·위임·판정워커실행유일한 등록 경로작업 전 자료 묶음관련 교훈 · 이전 결정등록할 때 요청 ID가 붙는다응답서도 같은 ID로 돌아온다
요청 등록
참조·교훈 묶음
워커 실행

이어받은 질문등록된 요청은 어떻게 실행될까요?

다음 질문요청 ID를 받은 실제 요청은 어떤 약속을 담고 있을까요?

요청서의 약속12 / 16

실제 요청서 한 장으로 이 네 칸이 무엇을 약속하는지 함께 읽습니다.

네 칸은 각각 하나의 약속입니다. 무엇을 끝낼지, 어떻게 확인할지, 무엇을 읽을지, 무엇은 하지 않을지.

약속이 분명해야 응답서가 돌아왔을 때 무엇과 대조할지 정해집니다.

요청보고직접 요청같은 대화로 답 · 응답서 없음요청서응답서같은 ID·상태사용자매니저판단·위임·판정워커실행요청서 · 요청 ID R-예시-01목표무엇을 끝낼지완성 기준어떻게 확인할지참조 경로무엇을 읽을지금지 범위무엇은 하지 않을지응답서가 오면이 네 약속과하나씩 대조한다
목표: 무엇을 끝낼지
완성 기준: 어떻게 확인할지
참조 경로: 무엇을 읽을지
금지 범위: 하지 않을 것

이어받은 질문요청 ID를 받은 실제 요청은 어떤 약속을 담고 있을까요?

다음 질문완성 기준 칸에는 실제로 무엇을 적을까요?

실물 예시13 / 16

완성 기준은 확인 방법을 약속합니다

완성 기준에는 원자료를 어떻게 계산하고 대조할지를 씁니다.

20%라는 원하는 답을 완성 기준으로 미리 정하지 않습니다.

목표문의 회고 초안을 만든다
완성 기준배송·전체 건수를 집계·계산·대조하고, 주장 3개에 근거를 연결한다
참조문의.csv 원자료
금지 범위외부에 게시하지 않는다

교육용 합성 요청서

이어받은 질문완성 기준 칸에는 실제로 무엇을 적을까요?

다음 질문응답서의 처리 상태는 각각 무엇을 뜻할까요?

응답서14 / 16

응답서에는 그 요청 ID와 처리 상태가 적혀 돌아옵니다.

워커는 응답서에 자기 요청 ID와 네 가지 처리 상태 중 하나를 적어 돌려줍니다.

검증이 실패해도 만든 산출은 지우지 않고, 일부만 끝났으면 산출과 남은 일을 함께 적습니다.

요청보고직접 요청같은 대화로 답 · 응답서 없음요청서응답서같은 ID·상태사용자매니저판단·위임·판정워커실행완료필수 항목이 쓸 만함일부 완료누락 · 시간 부족실행 실패오류로 산출 실패진행 보류승인·입력·권한 필요
완료
일부 완료
실패
진행 보류

이어받은 질문응답서의 처리 상태는 각각 무엇을 뜻할까요?

다음 질문응답서를 받은 매니저는 무엇을 할까요?

판정과 복구15 / 16

응답을 받으면 판정하고, 막혔다면 원인을 고쳐 새 요청으로 다시 보냅니다.

완료 보고를 받으면 핵심 수치 하나를 원천과 대조합니다. 일부만 끝났으면 한 번 이어 가고, 같은 사유로 두 번 막히면 멈추고 알립니다.

시간이 모자랐다면 같은 크기로 다시 보내지 않고, 범위를 나누거나 시간을 늘립니다.

완료 보고를 대조한 예

보고: 배송 문의 25%

원자료: 전체 200건·배송 40건

40÷200=20% → 보고 수정

이어받은 질문응답서를 받은 매니저는 무엇을 할까요?

다음 질문누구도 스스로 승인할 수 없는 일은 무엇일까요?

승인 경계16 / 16

한 가지 더 있습니다. 누구도 스스로 승인할 수 없는 일이 네 가지인데, 그 승인은 언제나 사용자의 문장으로 남습니다.

영구 삭제, 외부 전송·게시, 자격증명·보안 설정, 운영 원칙 수정은 사용자만 승인합니다. 사용자의 원문이 있어야 실행합니다.

워커와 직접 대화할 때도 같습니다. 무응답이나 경과 시간은 승인이 아닙니다.

요청서응답서같은 ID·상태사용자매니저판단·위임·판정워커실행승인 요청원문직접 대화 워커도 같다사용자 원문이 있어야 실행 — 매니저도, 직접 대화 워커도 대신 승인하지 않는다영구 삭제되돌릴 수 없는 삭제외부 전송·게시보내거나 게시자격증명·보안권한·보안 설정운영 원칙원칙 개정그 밖의 결정근거·가정을 기록하고스스로 진행무응답 ≠ 승인
영구 삭제
외부 전송·게시
자격증명·보안 설정
운영 원칙 수정