사전 공개: 이것은 저의 프로젝트입니다. WPMgr는 오픈 소스이며 셀프 호스팅이 가능한 WordPress 플릿 관리자(fleet manager)입니다. 여러 WP 사이트를 등록하고 하나의 대시보드에서 모니터링, 업데이트, 백업 및 보안을 관리할 수 있습니다. AGPL-3.0 라이선스이며(WordPress 에이전트 플러그인은 MIT), 셀프 호스팅은 무료이고 유료 호스팅 옵션도 있습니다. 제가 저자입니다. 저장소는 GitHub(mosamlife/wpmgr)에 있습니다. 제가 이곳에 글을 올리는 이유는 이 서브레딧(sub)에서 흥미로운 부분은 제품 자체가 아니라, 그것이 어떻게 구축되었는가이기 때문입니다. 스택: Go 컨트롤 플레인(control plane), React 19 + TypeScript 대시보드, PHP WordPress 에이전트 플러그인, Next.js 마케팅 사이트, 그리고 미디어 인코더(media-encoder) 서비스입니다. 실제 모노레포(monorepo)이며 실제 사용자가 있고, 거의 전적으로 Claude Code로 구축되었습니다.

제가 실제로 사용하는 워크플로우는, 얼마 전부터 한 번에 해결하는 방식(one-shot fixes)을 요구하는 것을 그만두었습니다. 이제 보고된 모든 버그는 상시 가동되는 멀티 에이전트(multi-agent) 워크플로우를 거칩니다: 각기 다른 관점에서 실제 코드를 읽는 병렬 조사관(Parallel investigators), 이들을 하나의 순위가 매겨진 근본 원인으로 조정하는 합성(synthesis) 단계, 레이어별로 병렬로 작동하는 전문 빌더(Specialist builders, Go용 하나, PHP 에이전트용 하나, React용 하나), 각각 고정된 설계에 따라 구축합니다. 그리고 적대적 검증(adversarial verify) 단계: 오직 수정 사항을 깨뜨리는 것만을 임무로 하는 별도의 보안 및 정확성 검토자들입니다. 배포(Ship): 테스트, CI, 배포, 이슈 종료.

가장 가치 있는 단 하나의 습관은 적대적 검증(adversarial verification)입니다. 테스트 통과(Green tests)만으로는 충분하지 않습니다. 이번 주에 제가 배포한 백업 버그의 경우, 빌드는 모든 테스트를 통과했지만, 특히 레이스 컨디션(races)을 추적하도록 설계된 검토자 에이전트가 실제 TOCTOU(Time-of-Check to Time-of-Use) 결함을 찾아냈습니다. 감시자(watchdog)가 좁은 시간 범위 내에서 완료된 백업을 실패로 뒤집을 수 있었던 것입니다. 이는 일반적인 테스트 실행에서는 절대 나타나지 않습니다. 두 번째 에이전트가 첫 번째 에이전트의 작업을 공격하게 만드는 것이 제가 하는 그 어떤 것보다 더 많은 실제 결함을 잡아냈습니다. 구체적인 예시(오늘의 버그): 한 사용자의 전체 백업이 업로드 단계에서 HTTP 422 오류와 함께 느린 서버에서 실패하고 있었습니다. 저를 포함한 모두의 뻔한 추측은 S3 프리사인(presign) 코드였습니다.

연구 워크플로우(research workflow)는 422 오류를 추적하여 유일한 가능한 원인을 찾아냄으로써 그 추측을 거부했습니다. 바로 진행 상황 감시 장치(progress watchdog)가 실제로는 느리게 실행 중이었던 백업 작업을 강제로 실패시키고 있었던 것입니다. 실제 해결책은 S3와는 전혀 상관없는, 2단계 감시 장치(two-tier watchdog)와 생존 신호(proof-of-life signal)를 도입하는 것이었습니다. 수정하기 전에 추적하십시오. 증상은 거짓말을 합니다.

작동을 가능하게 만든 다른 요소들은 다음과 같습니다:

• 에이전트가 세션 전반에 걸쳐 유지하는 지속적인 파일 기반 메모리 (결정 사항, 고정 규칙, 주의 사항 등). 이는 매 세션마다 코드베이스를 다시 학습하는 어시스턴트와, 어떤 것이 왜 그런 방식으로 존재하는지를 기억하는 어시스턴트 사이의 차이를 만듭니다.
• 좁은 범위의 전문 서브에이전트 (backend, WP 에이전트, frontend, security, docs). 인증(auth)이나 에이전트 프로토콜에 무엇인가가 닿기 전에 반드시 실행되어야 하는 보안 검토자(security reviewer)는 실제 문제들을 잡아냈습니다.
• 한 번 인코딩된 엄격하고 리포지토리(repo)별로 특화된 규칙 (예: '고정된 바이너리로 이 코드 생성기를 재생성할 것', '생성된 파일을 절대 수동으로 편집하지 말 것', '이 버전 파일들을 일치된 상태로 유지할 것')을 통해 매 세션마다 같은 문제로 싸우는 것을 방지했습니다.

솔직한 한계점: 만약 측정을 하는 대신 증상만을 근거로 추론하게 내버려 둔다면, 에이전트는 그럴듯하게 틀린 수정안을 자신 있게 작성할 것입니다. 되돌릴 수 없는 모든 작업에는 가드레일(guardrails)이 필요합니다. 그리고 대규모 팬아웃(fan-out) 워크플로우는 토큰을 빠르게 소모하므로, 작업의 심각도에 맞춰 적절한 규모로 조정합니다. 워크플로우의 어떤 부분에 대해서든 댓글로 더 자세히 논의할 준비가 되어 있습니다. 무엇을 팔려는 것이 아닙니다; 실제 코드를 읽고 싶다면 모두 오픈 소스입니다.

submitted by /u/Fluffy_Status872 [link] [comments]