루프 엔지니어링, 자신의 루프는 '성장' 측에 있는가? - 모든 고리를 세는 도구를 만들다

지난 기사 「루프 엔지니어링에는 두 종류가 있다」에서는 에이전트에게 돌리는 루프를 두 가지로 나누었습니다.

수정(直す) 루프: 목표는 고정되어 있습니다. 목표와의 차이를 측정하여 행동을 수정합니다 (테스트 통과, lint 수정). -
성장(育つ) 루프: 내부 루프의 결과를 사용하여 목표 자체를 다시 쓰는 외부 루프가 존재합니다. 조직 학습에서 말하는 더블루프입니다.

그리고 성장 루프인 척하면서 실제로는 수정 루프처럼 만들어서 돌리면, 무난한 안으로 조용히 기울어지지 않을까라고 적었습니다.

글을 쓰고 난 후에, 문제가 하나 있다는 것을 깨달았습니다. 자신의 루프가 어느 쪽에 있는지, 확인해 볼 방법이 없다는 것입니다. 매뉴얼이나 스킬셋을 다시 읽어보면, 대부분 '결과를 목표로 되돌리는 길'이 있는 것처럼 보입니다. 매뉴얼은 작성자 본인과 AI가 논리적으로 과정을 거치며 쓰기 때문입니다. 하지만 실제로 데이터가 그 경로를 한 바퀴 돌았는지는, 매뉴얼을 읽어서는 알 수 없습니다.

그래서 워크스페이스의 모든 고리를 세는 도구 「loopfinder」를 만들고 공개했습니다. 이 글에서는 그것으로 무엇을 확인할 수 있는지에 대해 쓰겠습니다.

확인하고 싶은 4가지

노트와 스크립트, 그리고 AI 에이전트로 무언가를 돌리고 있다면, 확인하고 싶은 것이 네 가지 있습니다.

어디가 고리(루프)를 이루고 있는가. 데이터가 한 바퀴 돌아 되돌아오는 경로는 무엇인가. -
의도하지 않은 피드백은 없는가. 아무도 설계한 기억이 없는데, 한 바퀴 도는 루프. 예를 들어, AI가 제시한 안이 다음 주 요약에 포함되고, 그 요약을 읽고 AI가 다음 안을 내놓는 경우입니다. 지난 기사에서 쓴 '같은 안의 바꿔 쓰기로 기울어지는 것'은 이런 루프에서 발생할 수 있습니다. -
외부 루프(더블루프)가 있는가. 내부 루프의 결과가 그 루프의 목표(설정, 매뉴얼, 프롬프트)로 다시 기록되고 있는가. -
말단이 회수되었는가. 쓰여졌지만 누구에게도 읽히지 않은 것은 없는가. 루프 도중에 멈춘 출력은, 돌아와야 할 길이 끊긴 장소이기도 합니다.

1과 2, 그리고 4는 세어보면 알 수 있습니다. 3은 센 후에, 루프가 어디를 지나고 있는지 보는 것입니다.

loopfinder가 하는 일

loopfinder는 3단계로 작동합니다.

평소 사용하는 AI 에이전트가 워크스페이스를 조사합니다. 어떤 스크립트가 언제 움직였는지, 사람과 AI가 무엇을 읽고 무엇을 썼는지를 loopfinder/flows.json에 기록합니다. -
스크립트를 실제처럼 실행하여 만진 것을 기록합니다. 다만 쓰기는 모두 중지(기록하고 버림)하기 때문에, 노트는 1바이트도 변하지 않습니다. -
한 바퀴 도는 경로(단순 폐회로)를 전부 셉니다. 사람이 붙인 이름을 붙이고, 나머지는 '이름 없는 고리'로 알려줍니다. 선언했지만 발견되지 않은 루프(절차가 바뀌어 루프가 끊긴 신호)와, 쓰여지지만 어디에서도 읽히지 않는 '말단'도 알려줍니다.

첨부된 데모(정원 가꾸기 노트)를 조립하면 다음과 같이 나옵니다.

2 flows, 24 nodes, 27 edges, 6 loops
reading: Do not show the same item twice
reading: The Reading section is rewritten in place
...

데모의 내용은 다음과 같습니다.

• 매일 아침, 스크립트가 정원 가꾸기 피드에서 신규를 모아 데일리 노트에 나열합니다. 모으는 것은 feed_topics.json에 적은 주제(토마토, 퇴비, 종자 채집)만입니다. -
  본인은 그것을 읽고, 시도하는 것을 태스크나 아이디어 목록에 씁니다.
• 주 1회, 다른 스크립트가 일주일을 요약합니다. 본인은 요약을 보고 다음 주 계획을 세우고, AI는 요약에서 아이디어를 냅니다. 요약 스크립트는 주간 건수도 stats.csv에 추가하고 있습니다. -
  주의 회고를 통해, 무엇을 모을지(. feed_topics.json<br />）를 다시 씁니다.

이렇게 하여, 네 가지를 순서대로 확인해 나갑니다.

1. 어디가 고리를 이루고 있는가

위 출력의 6개가 그것입니다. 가장 작은 것은 '같은 것을 두 번 출력하지 않기' 루프로, 피드 스크립트가 이미 읽은 목록을 읽고 쓰고, 다음 아침에 다시 읽습니다. 의도적으로 만든 루프이며, 이름도 붙어 있습니다.

화면에서는 오른쪽 목록에서 루프를 선택하면, 그 루프에만 색이 칠해지고 위로 점이 흐릅니다.

2. 의도하지 않은 피드백

마지막 1개는 이름이 붙어있지 않습니다. 데모에서 일부러 선언하지 않고 남겨둔 것입니다.

주간 요약(週のまとめ)을 읽고 AI가 아이디어를 내면, 그것이 아이디어 목록에 들어간다. 다음 주 요약은 이 아이디어 목록도 읽기 때문에, AI의 제안이 다음 요약에 실리고, AI는 그것을 읽고 다음 제안을 낸다. 지난 기사의 말로 하자면, 외부에서 재료가 들어오지 않은 채 돌아가는 고리이다. 이 고리가 실제로 안건을 수렴시키는지 여부는 내용물에 달렸기 때문에 도구로는 알 수 없다. 알 수 있는 것은, 그런 형태의 고리가 여기에 존재하며 아무도 이름을 붙이지 않았다는 것이다.

이름 없는 고리가 나오면 에이전트에게 돌려준다. 에이전트는 그것이 의도한 바인지 사람에게 묻는다. 의도한 바라면 이름이 붙고, 의도하지 않았다면 흐름을 바로잡는 계기가 된다.

3. 외부의 고리는 있는가

네 번째 '주간 회고(週の振り返り)가 피드(フィード)가 모으는 것을 변화시킨다'가 데모에 넣은 외부의 고리이다.

왼쪽 상단의 작은 고리(피드 스크립트와 읽음 목록)는 수정하는 루프이다. 목표는 '지정된 주제의 신규 내용을 두 번 출력하지 않고 나열한다'로 고정되어 있다.

외부의 고리는 그 목표가 적힌 feed_topics.json을 통과하고 있다. 매일 아침 신규 내용이 데일리 노트에 들어가고, 주간 요약에 모이며, 그것을 보고 자신이 '무엇을 모을지'를 다시 쓴다. 다음 아침부터는 내부의 루프가 새로운 목표로 돌아간다. 지난 기사의 온도조절기(サーモスタット)로 비유하자면, '왜 자신은 69°F(약 20℃)로 설정되어 있는가'를 되묻는 쪽의 고리이다.

구별법

미리 말해두지만, loopfinder는 '이것은 더블 루프다'라고 판정하지 않는다. 파일이 목표인지, 단순한 데이터인지는 파일을 봐도 알 수 없기 때문이다. feed_topics.json은 내용만 보면 그저 JSON이다.

구별하는 것은 사람이고, 볼 수 있는 곳은 단 한 군데 있다.

그 고리가 다른 루프가 따르고 있는 목표 파일(설정/절차서/프롬프트/스킬)을 거쳐 다시 쓰고 있는지 여부이다.

통과하고 있다면 외부의 고리이고, 통과하고 있지 않다면 아무리 큰 고리라도 내부의 고리이다. 데모의 이름 없는 고리는 크지만, 아이디어 목록은 요약의 재료일 뿐, 어떤 루프의 목표가 아니다. 그래서 외부의 고리가 아니다.

지난 기사의 실례(AI 보안 점검)라면, 고리는 '점검 → 소견 → 재발 패턴 수집 → 점검 절차서 → 다음 점검'이 된다. 절차서를 통과하고 있으므로 외부의 고리이다. 반대로, 소견이 티켓으로 수정될 뿐 절차서로 돌아가지 않는다면, 그 점검은 수정하는 루프만 돌고 있는 것이다.

목표 파일이 그림 위 어디에 있는지 알면, 거기를 지나는 고리가 있을지 한눈에 보인다. 없다면, 그것이 '자신의 루프가 성장하는 쪽이 되어 있지 않다'는 답이 된다.

4. 말단은 회수되고 있는가

마지막은 고리(loop)가 되지 않고 멈춰있는 것이다. 출력의 마지막 줄이 그것이며, 주간 요약 스크립트가 추가하는 stats.csv는 어떤 흐름도 읽지 않는다. 화면에서는 노드 오른쪽에 짧은 세로선이 붙고, 목록 아래에 '쓰여지는데 아무도 읽지 않는 것'으로 나온다.

말단(末端)은, 하나의 흐름 단위가 아니라, 모든 흐름을 합쳐서 판정한다. 어떤 흐름의 끝이라도 다른 흐름이 읽고 있다면 회수된 것이다. 외부로 전송하거나 공개하는 것(챗에 보내기, 사이트에 올리기)은 의도한 출구이므로 세지 않는다.

말단이 나왔을 때 답은 두 가지가 있다.

정말로 아무도 읽지 않는 경우. 회수되지 않은 채 쌓여있는 출력이다. 예를 들어, 두 AI 어시스턴트 사이에서 돌아가는 인계 노트 중 한쪽이 어느새 읽히지 않게 된 경우. 쓰는 쪽은 계속 쓰기 때문에 노트는 성장하지만, 누구에게도 전달되지 않는다.

사람이 읽고 있지만 선언하지 않은 경우. 사람이 읽는 것은 기록에 나오지 않으므로, 읽는 단계를 적어두지 않으면 말단으로 보인다. 이 경우에는 읽는 단계를 선언하면 사라진다.

어느 쪽인지는 에이전트가 사람에게 묻는다. 읽는 척하는 부분을 더해서 없애지는 않는다. 아카이브나 백업처럼, 읽히지 않는 것이 의도한 경우라면, 이유를 적어 ends에 선언하면 말단에서 벗어나 따로 나열된다. 선언했던 것이 다시 읽히게 되었다면, 선언 쪽이 오래된 신호로 알려준다.

외부의 고리와 관련하여 보자면, 말단은 '돌아갔어야 할 길이 끊어진 장소'이기도 하다. 지난 기사의 점검 예에서, 소견을 기록만 하고 절차서로 되돌리지 않았다면, 소견의 자리가 말단으로 나온다. 외부의 고리를 찾지 못할 때, 어디가 끊어졌는지 단서를 얻는다.

시스템에 대해 조금

도구는 AI를 갖지 않는다. 이름은 사람만이 붙인다

loopfinder에는 AI가 들어있지 않습니다. 조사해야 할 것은 평소에 사용하고 있는 에이전트(Claude Code, Codex, Cursor 등)입니다. loopfinder는 실행될 때마다 loopfinder/AGENTS.md (조사할 때의 판단 규칙)를 작성하므로, 에이전트에게 다음과 같이 요청합니다.

loopfinder/AGENTS.md를 읽고 이 워크스페이스를 조사해 줘.

에이전트가 기록할 수 있는 범위는 loopfinder/ 내부로만 한정하며, 노트나 스크립트에는 작성하지 않습니다. 기록 대상은 사용자가 평소에 실행하여 전송, 게시, 결제, 삭제 등의 행위를 하지 않는 스크립트에 한합니다. 사용 방식이 불분명한 스크립트는 사용자에게 물어볼 때까지 실행시키지 않습니다.

가장 중요한 규칙은 루프의 이름을 붙이는 것은 사람만 할 수 있다는 것입니다. 스크립트에 '읽음 처리는 두 번 하지 마라'라는 주석이 있어도, 에이전트는 이를 '의도대로' 확인으로 간주하지 않습니다. 찾고 있는 것은 코드가 실제로 하는 것과 사람이 의도하는 것 사이의 불일치이기 때문입니다. 외부 루프인지 여부도 마찬가지로, 어떤 파일이 목표인지를 아는 쪽은 사람 측에 있습니다.

이 안내서는 아무런 배경지식이 없는 에이전트에게 두 번 조사하게 시도한 결과입니다. 망설였다고 보고된 점을 안내서에 추가했고, 두 번째 시도에서는 결과를 보기 전에 채점 기준 7가지 항목을 작성하여 모두 충족시켰습니다(수정된 것은 flows.json만이며, 전후 파일을 비교하며 확인했습니다).

실제 실행해도 노트가 바뀌지 않는다

기록은 스크립트가 시작하기 전에 입출력 함수를 교체하여 수행합니다. Node는 fs의 쓰기(동기/콜백/Promise/스트림)와 http, https, net, tls, fetch, child_process를 교체하고, Python은 open, os, shutil, socket, urllib, subprocess를 교체합니다. 쓰기는 기록한 후 버리고, 통신과 서브 프로세스는 기본적으로 중단시킵니다. Markdown에 대한 쓰기 기록은 어떤 제목을 수정할 계획이었는지까지 기록합니다.

테스트에서는 쓰기 경로를 임시 폴더에 대해 시도하여 1바이트도 변하지 않음을 확인했으며, 동시에 동일한 스크립트를 후킹 없이 실행하면 실제로 변경된다는 것도 확인했습니다(양성 대조군). 이것이 없으면 검사가 망가져 있어도 '변화가 없었다'고 나와 합격과 구분이 불가능합니다.

사용해 보기

Node 18 이상이면 작동하며 (Python 스크립트를 기록할 경우 Python 3도 가능합니다), 의존 패키지는 없습니다.

git clone https://github.com/MotimotiNotch/loopfinder
dcd loopfinder
npm run demo # http://127.0.0.1:7878/ 에서 열립니다

자신의 워크스페이스에서는:

cd /path/to/your/workspace
node /path/to/loopfinder/bin/loopfinder.js init

에이전트에게 'loopfinder/AGENTS.md를 읽고 이 워크스페이스를 조사해 줘'라고 요청하고, flows.json가 생성되면 조립하여 엽니다.

node /path/to/loopfinder/bin/loopfinder.js build
node /path/to/loopfinder/bin/loopfinder.js serve

화면은 127.0.0.1에서만 대기합니다(그래프에 파일 경로가 나열되기 때문입니다). 외부 루프를 찾으려면, 조립하기 전에 에이전트에게 '이 파일은 ○○의 루프 목표야'라고 알려주면, 루프 이름을 물어볼 때 말이 빠릅니다.

한계점

• 기록할 수 있는 것은 Node와 Python 스크립트에 한정됩니다.
• 기록은 '그날 통과한 분기'만 볼 수 있습니다. 월 1회밖에 지나지 않는 처리는 그날 실행하지 않으면 나타나지 않습니다. 사람과 AI의 선언 및 스크립트 기록으로 서로의 구멍을 메웁니다.
• 더블 루프인지는 판정하지 않습니다(위에 적은 대로).
• 말단은 '기록과 선언에 의해' 아무도 읽지 않은 것이므로, 사람이 읽어도 선언이 없으면 말단으로 보입니다.
• 기록 담당일 뿐, 샌드박스는 아닙니다. 네이티브 확장이나 워커 스레드처럼 교체된 함수를 거치지 않는 처리는 대상에서 제외되며, 스스로 실행시키지 않은 코드는 기록에 걸 수 없습니다.

비슷한 도구로는 Obsidian 플러그인 Automation Graph가 있다. 자동화를 워크플로우 파일에서 그리고, 확인할 수 없는 것을 점선으로 구분한다. loopfinder는 스크립트를 읽는 것과 실행하는 것이 다르고, 루프를 세고 이름을 붙이는 것도 다르다.

loopfinder는 MIT 라이선스로 GitHub에 공개되어 있다. 자신의 루프에 외부 고리가 있는지, 도중에 멈춘 출력이 없는지 한 번 세어봐 주었으면 한다。

Discussion