루프 엔지니어링(Loop Engineering)의 상태 관리를 progress.md에서 GitHub Issue로 옮긴 이야기

최근 조금씩 떠오르고 있는 「루프 엔지니어링 (Loop Engineering)」.

AI에게 매번 프롬프트 (Prompt)를 입력하는 것을 그만두고, 알아서 계속 돌아가는 "루프 (Loop)" 측을 설계해 버리자!

라는 생각입니다. 인간은 시작(Kick)만 하면 나머지는 지켜보기만 하면 됩니다.

이것으로 「아이와 공원에서 놀면서 개발하기」를 시도해 보았습니다.

AI가 알아서 Issue를 읽고 구현하여 다음 단계로 진행합니다.

저는 미끄럼틀 벤치에서 스마트폰으로 힐끗 보고 있을 뿐……이라고 하면 듣기에는 좋지만,

옆에서 보면 「공원에서 끊임없이 스마트폰만 만지고 있는 아버지」입니다. 세상의 시선이 따갑네요.

그래서 가장 효과가 있었던 것이 「AI의 기억을 어디에 둘 것인가」입니다. 처음에는 progress.md를 사용했었는데, GitHub Issue로 전환했습니다.

progress.md는 처음에는 괜찮습니다. 처음에는요.

하지만 AI가 매번 덮어쓰기 때문에 과거의 경위가 사라지고, 파일이 커지면 토큰 (Token)이 무거워집니다.

「지금 이 순간」은 쓸 수 있어도 축적하는 데는 적합하지 않았습니다.

Issue로 바꿨더니 다음과 같이 되었습니다.

태스크 입도 (Task Granularity)로 나누어져 있음: Issue 1건 = 작업 1단위. AI는 담당 부분만 읽으면 됨
스마트폰으로 읽을 수 있음: AI가 착수와 완료를 코멘트 (Comment)로 작성하므로, 저는 GitHub 앱으로 바라보기만 하면 됨. close 되면 「오, 끝났네」라고 한눈에 알 수 있음
open/closed 가 상태 관리가 됨: gh issue list로 「아직 끝나지 않은 것」을 가져올 수 있음

기동은 수동입니다. 제가 /start-loop auto를 입력하면, 그때부터 모든 Issue를 자율적으로 소화합니다. 나머지는 AI가,

open Issue를 취득 → 다음에 할 일을 결정
→ 「착수하겠습니다」라고 코멘트 → 구현·리뷰
→ 「끝났습니다」라고 쓰고 close → 다음으로

를 반복할 뿐입니다.

Issue에 대한 쓰기는 AI 스스로가 하고 있습니다. 성실한 후배 같아서 조금 귀엽습니다.

솔직히 한 가지 말하자면 AI는 Issue를 감시하고 있지 않습니다. 읽는 것은 작업 직전의 1회뿐입니다.

그래서 제가 나중에 코멘트를 남겨도 그냥 지나칩니다. 읽씹(Read receipt ignore)조차 아닙니다. 애초에 보고 있지 않습니다.

방향을 바꾸고 싶을 때는 루프를 멈추거나, 다음 기동 전에 Issue의 본문을 수정합니다.

Issue가 커지면 토큰이 무거워짐: 코멘트가 늘어날수록 헤비해짐
기억이 흩어짐: 「그 판단이 어느 Issue였더라」 문제. gh issue search로 지금은 충당하고 있습니다.

Issue로 바꾼 이유를 한마디로 말하면 태스크 단위로 나누어져 있고, open/closed로 상태 관리를 할 수 있기 때문입니다. AI의 기억 저장소로서 의외로 잘 맞습니다.

단, 이것은 아직 「영원히 돌아가는」 루프가 아니라, 준비된 Issue를 자율적으로 소화해 나가는 유한 루프입니다. Issue가 다 떨어지면 멈추고, 어떤 Issue를 세울지는 지금은 제가 직접 결정하고 있습니다.

다음 숙제는 그 자율성입니다. 「백로그 (Backlog)를 준비하는」 부분도 루프 측으로 넘길 수 있다면, 비로소 정말로 「감시만 하면 되는」 상태가 될 것입니다.

아직 완성형은 아니지만, 「아이와 놀면서 루프가 돌아가는」 감각은 충분히 느껴집니다.

참고가 된다면 기쁘겠습니다!