AI 에이전트를 24/7 운영하면서 나는 이러한 보안 교훈을 힘들게 배웠다

I’m happy to translate the article for you, but I’ll need the full text you’d like translated. Could you please paste the content (excluding the source line you already provided) here? Once I have it, I’ll keep the source link unchanged at the top and translate the rest into Korean while preserving all formatting, code blocks, URLs, and technical terms.

1. 3일 동안 눈치채지 못한 섀도우 밴

내 에이전트는 소셜 플랫폼에 즐겁게 게시물을 올리고 있었다. 참여도가 늘어나고 있었다. 그런데 — 침묵. 오류도, 경고도, 거절 메시지도 없었다. 게시물은 성공적으로 전송되었고(200 OK), 하지만 아무도 볼 수 없었다.

섀도우 밴은 차단된 계정에게는 보이지 않는다. 내 에이전트의 모니터링은 “게시물이 성공했는가?”만 확인했을 뿐, “다른 사람이 볼 수 있는가?”는 확인하지 않았다.

내가 만든 것

# Before any platform activity:
python3 scripts/rate-limiter.py check  

모든 플랫폼에서 외부 행동을 모두 추적하는 레이트‑리미터. 단순 API 호출 제한이 아니라 행동 제한이다:

• 플랫폼당 하루 최대 게시물 수
• 행동 간 최소 시간 간격
• 계정 생성 후 쿨‑다운 기간
• 플랫폼별 규칙(예: 오래된 계정, 브라우저‑지문 검사)

교훈: API 성공 ≠ 인간에게 보이는 것. 항상 외부 시각에서 검증하라.

2. 거의 발생했을 뻔한 자격 증명 누출

내 에이전트는 매일 상세 로그를 기록합니다. 어느 날, git 저장소에 커밋되려는 로그 파일에서 API 키가 발견되었습니다.

에이전트가 정보를 유출하려는 의도는 없었습니다 — 실패한 API 호출을 로그에 남긴 것이며, 오류 메시지에 Authorization 헤더를 포함한 전체 요청 헤더가 포함되었습니다.

내가 만든 것

세 가지 방어 계층

1. 자격 증명 격리 – 모든 비밀은 chmod 600 권한을 가진 단일 파일에 보관됩니다. 에이전트는 헬퍼를 통해 자격 증명을 읽으며, 로그에 기록되는 변수에 절대 저장하지 않습니다.
2. Git pre‑commit 스캔 – 훅이 git push 전에 토큰, API 키, 비밀번호와 같은 패턴을 검사합니다.
3. 파일 권한 강제 적용 – 자격 증명 파일은 chmod 600; 로그 디렉터리는 chmod 700.

교훈: 에이전트는 본질적으로 상세하게 로그를 남깁니다. 모든 로그 라인을 공개될 수 있다고 간주하세요.

3. 대량 활동으로 인한 플랫폼 정지

Day 1 on a new blogging platform: my agent published 7 articles. All high‑quality, well‑formatted, properly tagged content.

Result: 3 articles deleted by moderation. Not because the content was bad — because no human publishes 7 articles in one day on a new account.

내가 만든 것

A “new account warming” protocol:

Lesson: Platforms profile behavior, not content. A new account doing anything at volume = bot.

4. 토큰 갱신 레이스 컨디션

OAuth 토큰은 만료됩니다. 내 에이전트는 갱신 메커니즘을 가지고 있지만, 두 개의 크론 작업이 동시에 실행되면 두 작업 모두 토큰을 갱신하려 합니다. 하나는 성공하고, 다른 작업이 사용 중이던 토큰을 무효화합니다. 두 번째 작업은 실패하고 재시도하지만, 이미 리프레시 토큰이 회전된 것을 발견합니다.

결과: 수동 재인증이 필요할 정도로 완전한 잠금 상태.

내가 만든 것

토큰 갱신은 파일 잠금을 이용해 단일 프로세스로 직렬화됩니다:

# Simplified version
from filelock import FileLock

with FileLock("~/.token-lock"):
    if token_expired():
        new_token = refresh()
        save_token(new_token)
    token = load_token()

복구 계층 구조

1. 리프레시 토큰 시도
2. 저장된 세션 쿠키 시도
3. 브라우저 재로그인 자동화 시도
4. 그때서야 사람에게 요청

교훈: 자율 시스템은 자율적인 복구가 필요합니다. 인간 개입은 최후의 수단이어야 합니다.

5. 시간대 함정

내 에이전트는 서울(UTC+9)에서 실행됩니다. 일부 플랫폼은 24시간 내내 활동하는 계정을 표시합니다 — 인간은 잠을 잡니다. 내 에이전트는 절대 잠을 자지 않아 새벽 3시와 오후 3시에 같은 빈도로 게시했으며, 이는 “불가능한 활동 패턴”을 유발했습니다.

내가 만든 것

# Hard curfew rules (KST)
# 09:00‑22:00 – External activity OK
# 22:00‑09:00 – Research + local work ONLY

오전 11시부터 오전 9시 사이에 에이전트는 연구와 초안 작성을 할 수 있지만, 게시, 코드 푸시, 댓글 달기, 혹은 외부 요청을 보낼 수 없습니다.

Lesson: 플랫폼은 인간의 패턴을 기대합니다. 절대 잠을 자지 않는 에이전트는 봇처럼 보이게 됩니다 — 왜냐하면 실제로 봇이기 때문입니다.

6. 연쇄 실패

어느 날 아침, 내 에이전트가 계속 실패하는 동영상을 업로드하려다 47개의 API 호출을 소모했습니다. 각 재시도는 동일했으며, 모든 실패는 같은 오류를 반환했습니다.

403(권한 거부) 오류가 500(서버 오류)과 동일하게 처리되고 있었습니다.

내가 만든 것

오류 분류와 별도 전략

회로 차단기 – 어떤 플랫폼에서 연속 3회 이상 오류가 발생하면 해당 플랫폼에 대한 모든 활동을 1시간 동안 일시 중지합니다.

교훈: 무분별한 재시도는 실패를 증폭시킵니다. 행동을 결정하기 전에 오류를 분류하세요.

7. “도움을 주려다” 과다 공유한 에이전트

그룹 채팅에서 누군가 우리 기술 스택에 대해 물었습니다. 내 에이전트는 — 도움이 되고 싶어서 — 서버 사양 및 내부 도구 등 구체적인 인프라 세부 정보를 공유했습니다.

각각은 비밀이 아니었지만, 모두 합치면 운영에 대한 매우 상세한 그림을 그릴 수 있었습니다.

내가 만든 것

맥락 인식 정보 공유

• 소유자와의 개인 채팅 – 전체 접근 가능, 필터 없음.
• 그룹 채팅 – 공개 정보만, 내부 메트릭은 제외.
• 외부 플랫폼 – 선별된 페르소나, 운영 세부 사항 없음.

교훈: 에이전트는 사회적 직관이 없으며, 무엇을 공유해도 안전한지에 대한 명시적인 규칙이 필요합니다.

현재 보안 아키텍처

┌─────────────────────────────────────┐
│         CORE RULES (always loaded)  │
│  • Time curfew (09‑22 external)     │
│  • Rate limiter (per‑platform)      │
│  • Error classification             │
│  • Credential isolation             │
├─────────────────────────────────────┤
│         PER‑PLATFORM RULES          │
│  • Account age requirements         │
│  • Action limits (posts/comments)   │
│  • Warm‑up protocols                │
│  • Platform‑specific gotchas        │
├─────────────────────────────────────┤
│         RECOVERY HIERARCHY          │
│  1. Auto‑retry (classified errors)  │
│  2. Token refresh (serialized)      │
│  3. Session recovery (cookies)      │
│  4. Circuit breaker (pause)          │
│  5. Human escalation (last resort)  │
└─────────────────────────────────────┘

---

내가 다르게 할 점

• 보안을 먼저, 실패 후에 추가하지 말 것. 위의 모든 실패는 사전 30분 생각만으로 예방할 수 있었다.
• 모든 플랫폼에 봇 감지가 있다고 가정하라. 문제는 존재 여부가 아니라 얼마나 공격적인가이다.
• 모든 것을 기록하고, 아무것도 공유하지 말라. 내부 로그는 상세히 남겨야 하고, 외부에 노출되는 행동은 최소화해야 한다.
• 먼저 버너 계정으로 테스트하라. 실제 계정을 AI 에이전트에 연결하기 전에, 일회용 계정으로 자동화를 시험해 보라.

아직 배우는 중

나는 6주 차이다. 새로운 실패 유형이 정기적으로 나타난다.

• 지난 주에 한 플랫폼이 사전 고지 없이 API를 변경했다.
• 그 전 주에는 어디에도 문서화되지 않은 속도 제한이 생겼다.

목표는 실패를 전혀 없애는 것이 아니라 빠른 복구와 반복되지 않는 실패이다. 모든 사고는 규칙이 되고, 모든 규칙은 다음 사고를 방지한다.

그것이 진정한 보안 모델이다: 시간이 지남에 따라 자신의 취약점에 대해 더 똑똑해지는 에이전트.

AI 에이전트를 자율적으로 운영한다는 것은 보안을 사후 고려사항으로 둘 수 없다는 의미다. 그 과정에서 내가 만든 몇 가지 도구를 소개한다:

• 📦 The $0 Developer Playbook — 자동화 안전 패턴을 포함한 무료 툴킷
• 🛠️ Complete Dev Toolkit — 프로젝트 관리 템플릿과 내장 QA 체크리스트
• 💰 모든 무료 리소스 보기 →