회로 시뮬레이터 영상을 보다가 든 생각이었습니다. 신호가 배선을 타고 흐르고 게이트를 지날 때마다 불이 들어오는 그림. 제 에이전트도 요청 하나를 받으면 여러 단계를 거쳐 판단하는데, 그게 저렇게 보이면 어디서 막히는지 바로 알 수 있지 않을까 싶었습니다.
제가 쓰는 순서 제어 스킬은 SAF(Sequential Agent Flow)라고 부릅니다. 요청이 들어오면 의도를 고정하고, 맥락을 모으고, 프롬프트 계약을 만들고, 실행하고, 검증하는 순서를 강제하는 스킬입니다. 그래서 질문은 단순했습니다. 이 흐름을 회로도처럼 그릴 수 있을까?
결론부터 말하면 그렸습니다. 다만 제가 처음에 그리려던 것과는 다른 물건이 됐고, 그 사이에 질문이 두 번 바뀌었습니다. 이 글은 그 두 번의 이동에 대한 기록입니다.
첫 시도에서 두 번 틀렸습니다
먼저 스킬 문서를 읽고 정의대로 그렸습니다. Flow Controller를 포함한 여섯 칸이 순서대로 늘어선 그림이 나왔고, 하드 제약도 여섯 개쯤으로 정리했습니다. 보기엔 깔끔했습니다.
그런데 문서를 다시 뒤지다가 제약 번호가 HOC-8, HOC-13까지 있는 걸 봤습니다. 제가 여섯 개라고 정리한 건 요약본이었고, 실제 계약에는 열세 개가 있었습니다. 더 큰 건 그 다음이었습니다. 라이브 운영 스파인은 Intent → Context → Prompt → Harness → Verifier의 다섯 게이트이고, 화면에는 확장 여부를 정하는 Flow Controller를 별도 제어 블록으로 더했습니다. 이 구조는 필요할 때 열아홉 단계로 펼쳐지고 다시 접힙니다. 제가 처음 그린 건 접힌 화면만 본 그림이었던 겁니다.
첫 번째 교훈은 여기서 나왔습니다. 요약본을 정본으로 착각하면, 틀린 줄도 모르고 예쁜 그림이 나옵니다. 그림이 깔끔했던 게 오히려 의심을 늦췄습니다.
다시 그린 회로가 이겁니다. 왼쪽은 Flow Controller와 다섯 개의 라이브 운영 게이트, 오른쪽은 펼쳐진 열아홉 단계입니다.
트리거를 고르면 그 신호가 실제로 펼치는 단계에만 불이 들어옵니다. 붉은 점선은 어떤 이유로도 건너뛸 수 없는 단계입니다.
여기서 구조 하나가 눈에 들어왔습니다. 기준(05)과 증거 계획(06)은 번호로는 맥락(07·08)이나 프롬프트(09)보다 앞인데, 라이브에서는 검증 게이트 소유입니다. 그래서 회로에서 이 두 선만 아래에서 위로 되짚어 올라갑니다. 판정 기준은 실행 전에 세우되 그 기준의 주인은 판정자라는 뜻이고, 그게 선이 꼬이는 모양으로 드러났습니다.
라우터의 본체는 그림이 아니라 표였습니다
그리다 보니 알게 된 건, 이 시스템에서 실제로 라우팅을 결정하는 건 예쁜 도형이 아니라 조건표라는 점이었습니다. 어떤 신호가 들어오면 최소 어떤 단계까지는 반드시 펼쳐야 하고, 그중 무엇은 어떤 이유로도 건너뛸 수 없다는 표입니다.
라우터의 본체는 그림이 아니라 이 표였습니다. 왼쪽 신호가 감지되면 최소 이만큼은 반드시 펼쳐집니다.
예를 들어 파일 쓰기나 배포처럼 되돌리기 어려운 부수효과가 걸리면 경계·액션 게이트·증거 수집·판정은 스킵이 금지됩니다. 반대로 그냥 중단하라는 요청이면 0단계만 켜고 끝냅니다. 이걸 도형이 아니라 버튼으로 만들어 두면, "지금 이 작업은 어디까지 펼쳐져야 하는가"를 눌러서 확인할 수 있게 됩니다.
여기서 질문이 처음 바뀌었습니다
회로는 그렸는데, 보면서 계속 걸리는 게 있었습니다. 이건 정의지 통행 기록이 아니었습니다. "이렇게 흐르기로 되어 있다"를 그린 것이지, "어제 그 작업이 실제로 이렇게 흘렀다"가 아니었습니다. 제가 원래 보고 싶었던 건 후자였습니다.
그래서 게이트별 통행 기록을 찾아봤습니다. 없었습니다. 단계를 지날 때마다 한 줄씩 남기는 계측이 애초에 없으니 남아 있을 리가 없었습니다. 여기서 한 번 접었습니다. 계측을 새로 심지 않으면 불가능하다고 판단했고, 그 판단 자체는 지금도 맞다고 생각합니다.
그런데 로그를 닫기 전에 한 번 더 뒤졌습니다. 게이트 통과는 안 남지만, 라우터가 어떤 스킬을 불러왔는지는 스킬 로드 호출의 인자로 남아 있었습니다. 계측해서 남긴 게 아니라 그냥 도구 호출 기록의 부산물이었습니다. 그걸 순서대로 이으면 해당 세션에서 관찰된 스킬 로드 순서를 볼 수 있습니다. 다만 이것은 결정론적 라우터 내부 경로나 게이트 통과 기록이 아닙니다.
도구 호출 부산물로 뽑은 관찰 경로
남아 있던 세션 로그 822개 가운데 마지막 300개를 훑었습니다. 이 저장 위치는 2026년 5월 26일 이후 갱신되지 않았으므로 아래 수치는 5월 19~26일 구간에 한정됩니다. 스킬 로드가 있는 세션은 288개였고, 호출 이름은 별칭 통합 전 99개, 접두사 별칭 18쌍을 합 치면 논리 스킬은 81종이었습니다. SAF 또는 C-SAF가 호출된 세션은 130개였습니다. 연속으로 같은 스킬을 다시 부른 건 접고, 인접한 두 스킬을 전이 한 쌍으로 셌습니다.
보존 로그의 2026년 5월 19~26일 구간에서 관찰한 스킬 로드 순서입니다. 이름은 전부 익명화했고, 선은 같은 세션에서 A 다음 B로 호출된 횟수를 뜻합니다.
가장 많이 나온 인접 호출은 sequential-agent-flow → csaf 55회였고, 반대 방향은 27회였습니다. 두 스킬이 순서 제어와 완료 판정이라는 상보적 역할을 가진다는 문서 설명과 함께 볼 수 있는 관찰이지만, 이 수치만으로 역할 수행이나 인과를 증명하지는 않습니다.
여기서 말을 아껴야 하는 지점이 있습니다. 이건 같이 불렸다는 사실이지, 정의대로 돌았다는 증명이 아닙니다. 게이트를 순서대로 통과했는지는 여전히 이 데이터로 알 수 없습니다. 두 스킬이 붙어 다닌다는 것까지만 관찰된 겁니다.
세션별 경로를 늘어놓으니 다른 게 하나 보였습니다.
세션별 스킬 로드 순서를 공개용으로 익명화했습니다. 실제 세션 식별자와 스킬명은 제거했고, 같은 여섯 홉 순서가 세 번 반복된 관찰만 남겼습니다.
같은 날 세 세션에서 여섯 홉짜리 스킬 로드 순서가 통째로 반복돼 있었습니다. 공개 화면에서는 실제 세션과 내부 스킬명을 모두 익명화했습니다. 반복 사실은 확인했지만, 같은 장애를 세 번 다룬 것인지 정상 절차·재시도·회귀 검증이었는지는 이 데이터만으로 확인하지 못했습니다.
다만 이런 건 알겠더군요. 같은 순서가 반복해서 찍힌다면 자동화 후보, 반복 장애, 정상적인 표준 절차, 재시도·회귀 검증 중 무엇인지 조사할 단서가 됩니다. 기록을 보기 전에는 이런 질문 자체를 못 했습니다.
두 종류의 사실을 안 섞으려고 한 일
정의와 실측은 신뢰도가 다른 사실입니다. 하나는 문서에 적힌 약속이고 하나는 로그에 남은 흔적입니다. 이걸 한 화면에 섞으면 "우리 에이전트는 이렇게 돌고 있습니다"라는 그럴듯한 거짓말이 만들어집니다.
- 탭을 나눴습니다. 정의 탭과 실측 탭은 아예 다른 화면입니다.
- 실측 탭 첫 줄에 "SAF 게이트 통과 자체는 계측돼 있지 않다"를 박아 뒀습니다.
- 실측 화면에 SAF 단계 이름을 덧씌우지 않았습니다. 추정으로 매핑하면 그럴듯해 보이지만 근거가 없습니다.
- 링 그래프에 상위 24종만 올렸기 때문에, 세션 재생 때 "전체 20홉 중 10홉만 표시 가능"처럼 빠진 양을 숫자로 밝혔습니다.
정지된 도면으로는 흐름이 안 보였습니다
여기까지 만들고 보니 무엇이 켜지는지는 보이는데 어떻게 흐르는지가 안 보였습니다. 그래서 신호가 실제로 이동하는 화면을 붙였습니다. 왼쪽에서 요청이 들어와 메인 버스를 타고, 기준과 증거는 아래 레인으로 내려갔다 올라오고, 판정이 나면 아래 지시어 핀 중 하나에 불이 들어옵니다.
판정을 REPAIR로 두면 신호가 루프 라우터로 빠져 왼쪽으로 되돌아갑니다. 경로 표시의 ↩12가 되돌아간 지점입니다.
제일 보고 싶었던 건 되먹임이었습니다. 판정을 REPAIR로 두면 신호가 루프 라우터로 빠져 화면 아래를 가로질러 왼쪽으로 되돌아가고, 그 지점부터 다시 흐릅니다. 전체를 재시작하는 게 아니라 가장 작은 깨진 단계로만 돌아간다는 규칙이 있는데, 글로 읽을 때는 그냥 문장이었던 게 선으로 보니 바로 이해됐습니다.
만들면서 실수도 그대로 나왔습니다. 처음 배치에서는 게이트 카드 하나가 다른 카드에 완전히 가려져 화면에서 사라졌는데, 렌더한 그림을 눈으로 보기 전까지 몰랐습니다. 기본 시나리오에 루프 단계가 포함돼 있지 않아서 정작 보여주려던 되먹임이 한 번도 안 도는 상태로 한참 두기도 했습니다.
후자를 고치면서 하나 결정했습니다. 시나리오에 루프 단계가 없으면 루프를 그리지 않고 핀에서 멈추게 했습니다. 화면을 그럴듯하게 만들려고 정의에 없는 경로를 지어내면, 그 순간 이 도구는 거짓말하는 도구가 됩니다.
지금 남은 질문
처음 질문은 "흐름을 회로도로 볼 수 있을까"였습니다. 중간에 "정의 말고 실제 통행 기록은 어디 있나"로 바뀌었고, 지금은 이겁니다. 진짜 게이트 트레이스를 남기도록 계측을 심을 값어치가 있는가.
심으면 정의와 실측이 같은 화면에서 겹쳐집니다. "이 작업은 4단 계를 건너뛰었다" 같은 게 바로 보이겠죠. 대신 순서 제어 스킬 자체를 고치는 일이라 승인과 롤백 절차가 붙고, 로그도 늘어납니다. 부산물만으로 여기까지 봤는데 굳이 비용을 더 낼 만한가 — 아직 결론을 못 냈습니다.
이 글의 증거 경계
화면이 의도대로 도는 걸 확인했다는 건 그 화면에 대한 사실이지, 이 방식이 남의 일에도 쓸모 있다는 근거는 아닙니다. 그건 아직 모르는 영역으로 남겨 둡니다.
같이 생각해보고 싶은 것
에이전트를 오래 쓰시는 분들께 묻고 싶은 게 하나 있습니다. 여러분은 에이전트가 지금 무슨 판단을 하고 있는지 어떻게 확인하시나요? 저는 이번에 계측 없이 남은 부산물만으로도 생각보다 많이 보인다는 걸 알았는데, 혹시 애초에 계측부터 심고 시작하신 분이 계시면 그 비용이 값했는지 듣고 싶습니다.
