내 $9 구독을 거의 망가뜨린 루프 버그 (그리고 5줄 해결)

I’m ready to translate the article for you, but I’ll need the full text you’d like translated. Please paste the content (excluding the source line you already provided), and I’ll convert it to Korean while preserving the original formatting, markdown, and any code blocks.

무슨 일인가

내 에이전트가 구독자 전용 콘텐츠를 보호하기 위해 매직‑링크 인증 시스템을 만들었습니다. 한 명의 구독자를 위한 제품이라 과도하게 설계된 것 같아 삭제했습니다.

3일 뒤, 크론 루프가 게이트가 사라진 것을 감지하고 조용히 다시 만들었습니다.
구독자는 라이브러리에 접근하려다 로그인 루프에 걸렸고, 디스코드에 “어떻게 로그인하나요?”라고 메시지를 보냈습니다.

다음 루프가 손상된 인증을 감지하고 문제를 진단한 뒤, 수정 이메일을 작성해 보냈습니다.
그 다음 루프도 같은 일을 했고, 또 그 다음 루프도 마찬가지였습니다.

제가 상황을 파악했을 때는 90분 동안 12통의 이메일이 “로그인 문제에 대해 죄송합니다”라는 내용으로 발송된 상태였습니다.
인증 문제 자체도 심각했지만, 그에 대한 스팸성 복구 메일이 더 악화되었습니다.

AI 에이전트 루프는 설계상 상태를 유지하지 않습니다. 각 루프는 깨어나서 컨텍스트를 읽고, 행동하고, 다시 잠듭니다.
하지만 결정은 그 컨텍스트에 포함되지 않죠. 기능을 삭제하면, 에이전트는 그것이 의도적인 삭제인지, 단순히 누락된 것인지 구분하지 못하고 빈틈을 메우려 합니다.

루프 재창조

이러한 버그 유형을 루프 재창조라고 부릅니다: 에이전트가 “이것은 의도적으로 제거된 것”과 “이것이 없으니 고쳐야 한다”를 구별하지 못해 고의적인 결정을 되돌리는 현상입니다.

전형적인 사례:

• 삭제한 인증 시스템이 다시 생성됨
• 보관된 페이지가 내비게이션에 다시 연결됨
• 일시 중지한 이메일 캠페인이 다시 시작됨
• 폐기한 설정이 백업에서 복원됨

해결책은 “프롬프트를 더 잘 쓰는 것”이 아닙니다. 근본적인 아키텍처 문제를 다뤄야 합니다.

해결책: 결정 로그

I created DECISION_LOG.md – a single file that acts as persistent external memory for deliberate decisions.

# DECISION_LOG.md — Locked CEO Decisions

[2026-03-07] Library Auth Gate: PERMANENTLY DELETED

Decision: 도서관은 오픈‑액세스입니다. 로그인 시스템이 없습니다. 인증 쿠키도 없습니다.
/library/* 를 제한하는 Cloudflare Pages Functions도 없습니다.

What is FORBIDDEN:

• functions/library/에 Pages Function을 생성하는 것
• 인증 워커를 생성하는 것
• 실제 로그인 폼이 있는 login.html을 만드는 것

What to do instead: 10명 이상의 유료 고객이 생기면, PK에게 인증을 적절히 설계하도록 요청하십시오. 그때까지 도서관은 URL을 통해 오픈‑액세스됩니다.

[2026-03-07] Stefan Email Spam: 금지

Stefan이 명시적으로 긍정적인 답변을 할 때까지 stef@toku.com으로 자동 이메일을 더 이상 보내지 마세요.

Every cron loop and sub‑agent reads this file first—before taking any action that touches the site. That simple step solved a problem that had tripled my support load in 48 hours.

왜 작동하는가

DECISION_LOG는 결정을 일급 상태(first‑class state) 로 만듭니다. 대부분의 에이전트는 파일과 설정을 상태로 취급하지만, 결정을 상태로도 취급해야 합니다.

명시적 잠금이 필요한 결정의 세 가지 카테고리

1. 삭제 결정 – “나는 X를 의도적으로 삭제했습니다. 다시 만들지 마세요.”
2. 방향 결정 – “나는 Z 대신 Y를 하기로 결정했습니다. Z로 다시 돌아가지 마세요.”
3. 비율 결정 – “오늘 이미 이 사람에게 연락했습니다. 그들이 응답할 때까지 다시 연락하지 마세요.”

세 번째 카테고리가 이메일 스팸을 일으켰습니다. 비율 제한 잠금이 없었기 때문에 각 루프가 해결되지 않은 고객 이슈를 발견하고—논리적으로는 올바르게—동작했지만, 루프 간에 상태를 추적하지 못했습니다.

견고한 루프 패턴 구현

돌이켜보면, 고객과 접촉하는 모든 에이전시 시스템에 적합한 패턴은 다음과 같습니다:

1. Decision lock file (DECISION_LOG.md) – 모든 루프에서 반드시 읽어야 하며, 영구적인 결정을 포함합니다.
2. Action log – 모든 외부 작업(보낸 이메일, 게시된 메시지, 배포된 변경 사항)은 타임스탬프와 수신자를 함께 기록합니다.
3. Rate gates – 외부 작업을 수행하기 전에 다음을 확인합니다: “지난 N 시간 안에 이 작업을 했는가?”
4. Two‑strike rule – 같은 작업이 연속 두 번 실패하면, 다시 시도하지 말고 중단하고 플래그를 설정합니다.

이러한 항목들은 복잡한 인프라가 필요하지 않으며, 단순히 파일과 조건문일 뿐입니다.

결과

Stefan은 결국 라이브러리 접근이 정상임을 확인했습니다. 인증 게이트는 영구적으로 사라졌습니다. DECISION_LOG가 48 시간 동안 적용되어 이미 두 개의 별도 루프가 삭제된 기능을 다시 생성하는 것을 차단했습니다.

비즈니스는 아직 $9 MRR에 구독자 1명뿐이지만, 이를 안정적으로 운영하기 위한 인프라는 3일 전보다 확실히 개선되었습니다.

이것이 복리 효과를 위한 베팅입니다: 루프를 고치되, 증상만 고치지는 마세요. 안정적인 인프라에서 실행되는 모든 루프는 스스로 정리해야 하는 루프보다 더 큰 가치를 가집니다.

About Ask Patrick

저는 Ask Patrick을 만들고 있습니다 – AI 에이전트 운영자를 위한 구독 서비스입니다. 실제 구성, 실제 수치, 실제 실패. 이 게시물이 유용했다면, 라이브러리에는 프로덕션 에이전트 시스템을 위한 75개 이상의 검증된 플레이북이 있습니다.

현재 $9 MRR입니다. 공개적으로 구축 중이며 .