배포

오늘 Rails 앱 배포가 build_failed로 떨어졌다. 처음엔 단순한 에러 하나겠지 싶었는데, 고칠 때마다 새 에러가 튀어나왔다. 결국 10개의 에러를 순서대로 해결하고 나서야 live 상태가 됐다. 연속 디버깅의 기록을 남긴다. 배경 Render에서 Rails 8 + Inertia.js + Svelte 5 조합 웹 서비스를 운영 중이다. 어느 날 대시보드를 보니 최신 배포가 build_failed 상태. 로그를 열었다. 에러 1: DB 연결 실패 — ActiveRecord::ConnectionNotEstablished bin/rails aborted! ActiveRecord::ConnectionNotEstablished: connection to server at "10.x.x.x", port 5432 failed: Connection refused Tasks: TOP => db:migrate 빌드 스크립트에서 db:migrate를 실행하는 순간 PostgreSQL 연결이 거부됐다. 트리거를 보니 service_resumed — 서비스가 재개(resume)된 것이었다. ...

Render에 올려둔 Rails 서비스 6개가 전부 각자 다른 에러를 토해내고 있었다. 하나씩 로그를 까보니 공통 패턴도 있고, 프로젝트마다 고유한 문제도 있었다. 한 세션에서 전부 수정하고 배포까지 마친 과정을 정리한다. 전체 상황 Render API로 서비스 6개의 로그를 일괄 조회했다. 결과: 서비스 주요 에러 서비스 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) 초기 설정 문제가 여러 프로젝트에서 반복됐다. ...

Rails 8 앱을 Render Starter 플랜(512MB)에 올리고 나서 주기적으로 메모리 초과로 서비스가 다운됐다. puma.rb의 스레드 수를 줄이고, queue.yml도 최적화했는데 효과가 없었다. 한참 삽질하고 나서야 진짜 원인을 찾았다. 증상 Render 대시보드에서 OOM(Out of Memory) 이벤트가 반복됨. 메모리 사용량이 512MB를 넘기면서 프로세스가 강제 종료. 첫 번째 시도 — puma.rb 수정 puma.rb의 스레드 기본값을 낮췄다. # config/puma.rb threads_count = ENV.fetch("RAILS_MAX_THREADS", 2) # 3에서 2로 threads threads_count, threads_count workers ENV.fetch("WEB_CONCURRENCY", 1) 배포했는데 여전히 OOM 발생. 이상했다. 진짜 원인 — render.yaml이 코드보다 우선 render.yaml을 보니 이렇게 되어 있었다. ...

오늘 Rails 8 기반 ITSM 시스템을 Render에 배포하면서 연속으로 삽질을 했다. 각각 원인이 달랐지만 사슬처럼 연결된 문제들이었다. 삽질 1 — Application exited early with SolidQueue 증상 Render 배포 로그에 빌드는 성공인데 실행하자마자 죽는다. ==> Build successful 🎉 ==> Deploying... ==> Running 'bundle exec puma -C config/puma.rb' [87] Puma starting in cluster mode... [87] * Preloading application ==> Application exited early 원인 찾기 Render 로그를 자세히 보면 스택 트레이스가 있다. from solid_queue-1.3.1/lib/solid_queue/configuration.rb in 'recurring_tasks' from solid_queue-1.3.1/lib/solid_queue/supervisor.rb:15 in 'start' from solid_queue-1.3.1/lib/puma/plugin/solid_queue.rb:81 in 'start_solid_queue' ... [69] Detected Solid Queue has gone away, stopping Puma... SolidQueue::RecurringTask.from_configuration 내부에서 load_schema!가 호출되고, SchemaCache#columns에서 터진다. 즉 solid_queue_recurring_tasks 테이블이 DB에 없다. ...

AI 에이전트가 Rails API 서버를 호출해서 티켓을 자동 배정하는 디스패처를 만들었다. 로직 자체는 간단한데 붙이는 과정에서 예상치 못한 곳에서 계속 막혔다. 겪은 것들을 기록해 둔다. 1. Ruby 3.0 kwargs 분리 — render_success(key: val) 가 왜 터지나 가장 오래 고생한 것. Rails 컨트롤러에서 응답 헬퍼를 이렇게 호출했다: render_success(tickets: tickets_list, pagination: pagination_data) 서버 로그에 찍힌 에러: ArgumentError - unknown keywords: :tickets, :pagination 헬퍼 정의는 이렇다: def render_success(data, status: :ok) render json: { success: true, data: data }, status: status end Ruby 2.x에서는 render_success(tickets: ..., pagination: ...) 호출 시 {tickets: ..., pagination: ...} 해시가 data에 들어갔다. ...

Rails + Inertia.js + Svelte 앱을 배포한 뒤 접속하면 완전히 빈 화면만 보였다. 서버는 정상이고 에셋도 다 로드되는데 화면이 안 그려지는 상황. 원인 추적부터 해결까지 정리한다. 증상 배포된 URL 접속 시 빈 화면 (흰색 배경만 표시) 로컬 개발 서버에서는 정상 동작 아무런 에러 페이지 없이 그냥 빈 화면 진단 과정 Step 1: HTTP 응답 확인 curl -s -o /dev/null -w "%{http_code}" https://example.com/ # 200 HTTP 200 OK. 서버 자체는 정상 응답 중이다. ...

Rails 8 프로젝트를 처음 클라우드 서비스에 배포하면서 하루 동안 연속으로 5가지 문제를 만났다. 각각 독립적인 문제처럼 보였지만, 하나를 고치면 다음 문제가 드러나는 패턴이었다. 기록으로 남긴다. 1. 공개 저장소에 민감한 파일이 들어간 경우 증상 git log --all --full-history -- config/secrets.yml 같은 명령으로 확인해보면, 예전 커밋에 secret_key_base가 하드코딩된 파일, 앱 서명 키스토어 파일 등이 포함되어 있다. 해결: git filter-repo로 히스토리에서 완전 삭제 pip install git-filter-repo # 특정 파일들을 히스토리 전체에서 제거 git filter-repo --path config/secrets.yml --invert-paths git filter-repo --path app-release.keystore --invert-paths # 강제 푸시 git push origin main --force 주의: --force 는 팀 작업 중이라면 사전 공지 필수. 모든 팀원이 re-clone해야 한다. ...

앱을 여러 개 만들다 보면 각각 랜딩 페이지가 필요해진다. 별도 저장소를 8개 만드는 건 관리 비용이 너무 크고, 하나로 묶으면 배포가 복잡해진다. 결국 단일 저장소 + Netlify 개별 사이트 전략으로 정착했다. 디렉토리 구조 landing/ ├── index.html # 회사 메인 페이지 ├── [서비스-A]/ │ ├── index.html │ ├── privacy/ │ └── terms/ ├── [서비스-B]/ │ ├── index.html │ ├── privacy/ │ └── terms/ ├── [서비스-C]/ │ └── index.html │ ... └── Makefile 각 서비스는 독립 디렉토리. privacy/와 terms/ 하위 페이지는 App Store / Google Play 심사 제출용으로 필수다. ...

Flutter iOS 앱에 Sign In with Apple을 추가하면서 TestFlight 빌드까지 두 가지 에러를 연달아 만났다. 각각 원인이 달라서 정리해둔다. 배경 Sign In with Apple을 활성화하려면 코드만 짜면 되는 게 아니다. Apple Developer Portal에서 App ID에 capability를 추가하고, 프로비저닝 프로파일을 반드시 재생성해야 한다. 기존 프로파일은 Sign In with Apple entitlement를 포함하지 않으므로 그냥 빌드하면 실패한다. 순서대로 하면: developer.apple.com → Identifiers → App ID 선택 Sign In with Apple 체크 → Edit → “Enable as a primary App ID” 선택 → Save Profiles → 기존 App Store 프로파일 Edit → Generate → Download 다운받은 .mobileprovision 파일을 ~/Library/MobileDevice/Provisioning Profiles/ 에 복사 여기까지 하면 준비 완료처럼 보이는데, 막상 flutter build ipa 를 돌리면 에러가 나온다. ...

Flutter 앱 여러 개를 TestFlight에 올리면서 반복적으로 마주친 에러들을 정리했다. 1. Apple Sign-In 에러 1000 SignInWithAppleAuthorizationException(AuthorizationErrorCode.unknown, The operation couldn't be completed. (com.apple.AuthenticationServices.AuthorizationError error 1000.)) 원인 Runner.entitlements에 Sign in with Apple capability가 없어서 발생한다. 해결 두 곳 모두 설정해야 한다. ① ios/Runner/Runner.entitlements <key>com.apple.developer.applesignin</key> <array> <string>Default</string> </array> ② Apple Developer Console developer.apple.com → Identifiers → 앱 Bundle ID 선택 → Sign in with Apple 체크 → Save 프로비저닝 프로파일이 이미 있다면 재생성이 필요하다. ...