Render에 Rails 앱을 새로 배포했다. 빌드는 성공했고 “Deploy live” 메시지도 떴다. 그런데 몇 분 뒤 대시보드에 이런 메시지가 반복됐다. Instance failed: wcvg7 Application exited early while running your code. 증상 파악 Render 로그를 뒤지니 이런 흐름이 보였다. SolidQueue::Configuration#ensure_configured_processes ← 여기서 에러 → exit 1 → "Detected Solid Queue has gone away, stopping Puma..." → Puma 종료 → 인스턴스 실패 Puma가 죽은 게 아니었다. Solid Queue가 먼저 죽고, Puma가 그걸 감지해서 스스로 내려간 것이었다. ...
Render에 올려둔 Rails 서비스 6개가 전부 각자 다른 에러를 토해내고 있었다. 하나씩 로그를 까보니 공통 패턴도 있고, 프로젝트마다 고유한 문제도 있었다. 한 세션에서 전부 수정하고 배포까지 마친 과정을 정리한다. 전체 상황 Render API로 서비스 6개의 로그를 일괄 조회했다. 각 서비스에 SSH로 하나씩 들어가서 로그를 보는 대신, Render의 REST API를 활용하면 로컬 터미널에서 모든 서비스의 로그를 한꺼번에 스크립트로 수집할 수 있다. 이번 점검에서 확인된 결과는 다음과 같았다: 서비스 주요 에러 서비스 A ERB 문법 에러로 500 (이미 커밋됐지만 미배포) 서비스 B Stoplight Light#run 블록 에러 + Telegram 파싱 에러 서비스 C solid_cache_entries 테이블 누락 서비스 D PG::UndefinedColumn + solid_cache 누락 서비스 E PG::DuplicateTable sessions + Sentry 초기화 에러 서비스 F TaskCleanupJob FK 위반 + Puma deprecated 경고 공통 패턴: Rails 8의 Solid Stack (SolidCache, SolidQueue, SolidCable) 초기 설정 문제가 여러 프로젝트에서 반복됐다. Render의 무료/스타터 플랜에서 단일 PostgreSQL 인스턴스를 여러 Rails 컴포넌트가 함께 사용하는 구성이 원인이었다. ...
AI 에이전트가 티켓을 잡고 방치하는 문제를 겪고 나서, OpenAI의 Symphony 프로젝트를 분석했다. Symphony는 GitHub 이슈 트래커를 폴링하고 코딩 에이전트(Codex, Claude 등)를 자동으로 실행시키는 오케스트레이터인데, 핵심 철학이 인상적이었다: “에이전트를 관리하지 말고, 일(Work)을 관리해라.” 이 철학에서 7가지 패턴을 추출하고, Rails 8 + SolidQueue 기반 ITSM 시스템에 모두 적용했다. 각 패턴이 왜 필요했는지, 어떻게 구현했는지를 실제 코드와 함께 정리한다. 배경: AI 에이전트 방치 사고 문제의 발단은 단순했다. ITSM 시스템에서 티켓을 AI 에이전트에게 배정했는데, 에이전트가 분석을 시작하고 중간에 타임아웃이 났다. 타임아웃 처리 코드가 없었기 때문에 티켓 상태는 assigned로 남았고, 시스템 어디에도 경보가 울리지 않았다. ...