AI 에이전트의 인계 방식을 고정하자 무엇이 달라졌나: 판단과 실행의 경계를 긋는 구현 메모

안녕하세요. 작업에 복귀하려고 PC 앞에 앉았는데, 어느새 브라우저 탭 정리만 하다가 30분이 지나 있었습니다. ADHD 사장입니다.

핵심부터 말씀드리겠습니다. 직접 만든 AI 어시스턴트 'Jarvis'에서 '판단하는 역할(thinking role)'과 '실행하는 역할(executing role)'을 분리한 후, 다음으로 효과를 본 것은 역할의 지능 자체가 아니라, 역할 간의 인계 형식과 판단이 필요했을 때 되돌려주는 방식을 고정하는 것이었습니다. AI 에이전트의 역할 분담은 역할을 나눈 순간이 아니라, 경계를 어떻게 운영할지 결정했을 때 비로소 작동하기 시작합니다.

전제: 왜 '나누기만' 해서는 안 되었는가

역할을 두 개로 나눈 직후, 실패의 종류가 바뀌었습니다. 이전에는 '판단과 실행이 뒤섞여 추적 불가능한' 실패였다면, 이제는 '의도가 전달되지 않아 멈추거나 어긋나는' 실패입니다.

구체적으로 발생했던 패턴은 다음과 같습니다. 대상 지정이 모호하여 이름이 비슷한 다른 대상을 처리하는 경우. 결과 출력처가 결정되어 있지 않아 배치 장소가 회마다 바뀌는 경우. 완료 조건이 없어 끝난 것인지 계속 진행 중인 것인지 외부에서 판단할 수 없는 경우.

이 모든 것은 실행 측의 능력 부족이라기보다는, 요청서(지시문)의 부족함이었습니다. 사람 간의 업무에서도 같은 일이 일어나지만, 상대가 시스템일 경우 모호함은 그대로 추측 실행으로 변환됩니다. 게다가 그 추측이 맞고 있는 동안에는 문제가 보이지 않습니다. 어긋났을 때 비로소 경계에 구멍이 뚫렸다는 것을 깨닫게 됩니다. 이 '늦게 보이는' 성질 때문에 인계 방식을 진지하게 다루는 이유가 되었습니다.

인계 형식에서 남긴 항목과 버린 항목

수많은 시행착오 끝에, 요청서에 매번 포함하기로 한 항목을 다음으로 좁혔습니다.

• 처리의 이름과 목적 (한 문장으로 설명 가능한 것)
• 입력 대상 (무엇을 다룰지 유일하게 결정하는 지정)
• 출력처 (결과를 어디에, 어떤 형태로 남길지)
• 완료 조건 (무엇이 갖춰지면 끝이라고 간주할지)
• 실패 시 처리 방식 (어디까지 진행되었는지, 무엇 때문에 멈췄는지)

반대로 버린 것도 있습니다. 실행 절차의 세부적인 지시입니다. 절차까지 요청 측에서 쓰기 시작하면, 판단하는 역할이 실행 내부로 침범해 들어와 경계가 무너집니다. 실행 측의 절차는 실행 측이 가져가고, 요청은 '무엇을, 어디서 어디로, 어떻게 완료되어야 하는지'에 국한합니다. 이 선 긋기 덕분에 요청서가 짧아졌고, 누락된 부분도 찾기 쉬워졌습니다.

형식을 고정하자 부차적인 효과도 있었습니다. 과거의 요청서가 그대로 '무엇을 부탁했는지'에 대한 기록이 되는 것입니다. 나중에 결과만 봐서는 경위는 추적할 수 없지만, 요청과 결과가 한 쌍으로 남아있으면 판단이 잘못되었는지 지정 자체가 잘못되었는지를 분리하여 되돌아볼 수 있습니다. 기록이 다음 개선 재료가 된다는 것은 이 개발 과정에서 여러 번 효과를 본 느낌입니다.

예외 처리: 실행 측은 '추측하지 않는 것'을 사양으로 정하기

또 하나 결정한 것이 예외 상황에서의 움직임입니다. 실행 도중에 판단이 필요한 상황에 부딪히면, 실행 측은 먼저 진행하지 않고 상태를 남겨 반환합니다.

상태 반환 방식의 이미지 (개념도)
- 진척도: 어디까지 완료했는지
- 정지 이유: 무엇을 판단할 수 없는지
...

이 결정은 언뜻 보기에는 비효율적으로 보입니다. 멈추지 않고 추측으로 진행하는 편이 그 자리의 완료율은 더 높기 때문입니다. 하지만 운영해 보니 반대였습니다. 추측으로 진행한 처리는 나중에 검증이 필요하게 되고, 결국 그쪽에 시간이 소요됩니다. 멈춰서 반환하는 처리는 당장 멈추더라도, 판단하는 측에서 개입하여 재개할 수 있습니다. 재개 가능한 실패는 운영상 '저렴한 실패'입니다.

경계의 목적은 실패를 제로화하는 것이 아니라, 실패를 '분리하고, 재개할 수 있는 형태'로 만드는 것이라고 생각합니다. 이 시각을 갖게 된 후로는 멈추는 것에 대한 초조함이 많이 줄었습니다.

경계를 그은 후에 남는, 판단 측의 책임

분담이 작동하기 시작하면, 다음으로 보이는 것은 판단하는 쪽의 약점입니다. 실행이 안정될수록, 우선순위를 정하거나 요청서를 작성하는 방식의 거친 부분이 그대로 결과의 거칠기가 됩니다. 병목 지점이 이동할 뿐이라고도 할 수 있습니다.

하지만 이것이 전부는 아닙니다. 병목 지점이 한 곳에 보이는 형태라는 것은, 고쳐야 할 대상이 명확하다는 의미이기도 합니다. 모든 것이 섞여있던 시절의 '어딘가 전체적으로 문제가 있는' 상태와 비교하면 훨씬 다루기 쉽습니다.

현재까지의 요약은 이렇습니다. 역할 분담에서 중요한 것은 역할을 나누는 것 자체보다, 인계 형식, 예외 발생 시 멈춰서 반환하기로 한 결정, 그리고 요청과 결과를 한 쌍으로 남기는 기록, 이 세 가지를 먼저 확립하는 것이었습니다. 같은 방식으로 에이전트 분담을 시도하는 분들의 경계 운영에 도움이 되기를 바랍니다.

ADHD 사장

Discussion