incident-response

You’ve Got (Too Much) Mail: Behind the Scenes of the 3/25/26 Voice Outage (새 탭에서 열림)

2024년 3월 25일, Discord는 일상적인 인프라 설정 변경 중 발생한 실수로 인해 세션 관리 서버의 17%가 동시에 종료되는 대규모 장애를 겪었습니다. 이 사건은 실시간 서비스의 핵심인 세션 시스템의 붕괴가 어떻게 하위 시스템으로 전이되어 음성 및 영상 통화 라우팅 기능을 마비시키는지 보여주는 전형적인 연쇄 장애(Cascading Failure) 사례였습니다. Discord 엔지니어링 팀은 이번 장애를 통해 분산 시스템에서 갑작스러운 부하가 유발하는 병목 현상을 정밀 분석하고, 시스템의 복원력을 높이기 위한 인프라 개선의 계기로 삼았습니다. ### 설정 오류로 인한 세션 관리 서버의 대량 종료 * **장애 발생:** PDT 기준 3월 25일 12:13부터 약 3시간 동안 서비스 성능 저하가 지속되었으며, 사용자들은 통화 연결 시 "Awaiting Endpoint" 메시지와 함께 연결 실패를 경험했습니다. * **근본 원인:** 인프라 설정 업데이트 과정에서 발생한 구성 오류로 인해, Discord 실시간 인프라의 핵심인 세션 관리 서버 중 17%가 일시에 셧다운되었습니다. * **세션의 중요성:** Discord의 세션은 모든 연결된 장치와 서버 간의 상태를 유지하는 '심장 박동'과 같으며, 앱 내에서 사용자가 보고 듣는 거의 모든 활동을 조율하는 필수 구성 요소입니다. ### 하위 시스템으로 전이된 연쇄 장애의 메커니즘 * **병목 현상의 전이:** 대규모 세션 손실은 단순한 서버 중단에 그치지 않고, 하위 시스템인 음성/영상 통화 라우팅 서비스로 막대한 부하를 전달했습니다. * **라우팅 서비스 마비:** 전 세계 사용자들을 적절한 통화 서버로 연결해주는 서비스가 갑작스러운 재연결 요청과 상태 복구 부하를 견디지 못하고 과부하 상태에 빠졌습니다. * **분산 시스템의 취약성:** 분산 환경에서 발생하는 급격한 부하(Sudden load)는 기존의 알려진 병목 지점뿐만 아니라 예상치 못한 새로운 지점의 결함을 찾아내며 시스템 전반을 타격합니다. ### 장애 분석을 통한 시스템 복원력 강화 * **심층 분석:** 사고 이후 팀은 시스템이 연쇄적인 부하 상황에서 왜 제대로 대응하지 못했는지 분석하고, 분산 시스템의 한계를 시험하는 계기로 활용했습니다. * **인프라 레벨업:** 겉보기에 사소한 설정 변경이 여러 단계 떨어진 서비스에까지 영향을 미칠 수 있음을 인지하고, 이를 방어하기 위한 인프라 고도화 작업을 진행 중입니다. * **경험의 자산화:** 장애 상황에서의 실제 데이터를 바탕으로 병목 현상을 해결함으로써, 향후 유사한 대규모 부하 발생 시에도 시스템이 견딜 수 있는 내성을 확보했습니다. 분산 시스템을 운영하는 엔지니어라면 사소한 설정 변경이 가져올 수 있는 연쇄 효과를 항상 경계해야 합니다. 갑작스러운 대량 부하 상황에서도 핵심 기능이 유지될 수 있도록 시스템 간의 격리를 강화하고, 장애 발생 시 부하를 제어할 수 있는 서킷 브레이커나 속도 제한(Rate Limiting) 같은 방어 기제를 인프라 전반에 걸쳐 점검하는 것이 중요합니다.

ROOST, AI 시대를 위한 (새 탭에서 열림)

비영리 단체 ROOST는 AI 시대의 온라인 안전을 위해 오픈 소스 기반의 보안 도구인 'Coop'과 'Osprey'를 공개했습니다. 이 도구들은 막대한 비용이 드는 엔터프라이즈 소프트웨어나 복잡한 자체 시스템 없이도 모든 규모의 기업이 유해 콘텐츠를 탐지하고 대응할 수 있는 기술적 토대를 제공합니다. 이를 통해 안전 인프라를 공공재로 전환함으로써 디지털 생태계 전반의 보안 수준을 상향 평준화하는 것을 목표로 합니다. **전문적인 콘텐츠 검토와 규제 준수를 돕는 Coop** * 콘텐츠 리뷰를 전문가에게 라우팅하고, 검토에 필요한 관련 정보를 시각화하여 즉각적인 조치를 취할 수 있는 인터페이스를 제공합니다. * 아동 성착취물(CSAM)의 의무 신고를 위한 미국 실종학대아동센터(NCMEC) API가 내장되어 있어 관련 법규를 효율적으로 준수할 수 있습니다. * 대규모 유해 콘텐츠 처리에 특화된 기술 기업 'Cove'의 IP를 ROOST가 인수하여 오픈 소스로 전환함으로써, 검증된 기술력을 누구나 무료로 활용할 수 있게 되었습니다. **위협 조사 및 대규모 사고 대응을 위한 Osprey** * 플랫폼 내에서 발생하는 위협을 심층적으로 이해하고 대규모로 대응 조치를 실행할 수 있는 경량화된 사고 조사 도구입니다. * 사용자 친화적인 설계를 통해 소규모 커뮤니티부터 대형 플랫폼까지 인프라 부담 없이 강력한 조사 기능을 수행할 수 있도록 돕습니다. * Discord가 자사 플랫폼뿐만 아니라 인터넷 전체의 안전을 위해 개발한 기술을 ROOST에 기증한 것으로, 업계 내 안전 기술 공유의 핵심 사례로 꼽힙니다. **오픈 소스 안전 생태계의 확산과 협업** * 탈중앙화 소셜 미디어인 Bluesky는 Osprey 도입을 통해 자원 규모와 관계없이 효과적인 안전 인프라 구축이 가능함을 입증할 계획입니다. * Notion과 같은 주요 플랫폼들은 기존 Cove 기술을 통해 확보한 안전 역량을 기반으로, ROOST의 주도하에 더욱 강화된 개방형 보안 생태계 구축에 동참하고 있습니다. * 이 모델은 스타트업의 혁신, 자선 단체의 후원, 그리고 오픈 소스의 협업 정신을 결합하여 피싱 캠페인부터 아동 안전 사고까지 광범위한 위협에 맞서는 새로운 표준을 제시합니다. 온라인 위협이 정교해짐에 따라 안전 도구는 더 이상 경쟁 우위 수단이 아닌, 모든 플랫폼이 갖춰야 할 필수적인 기반 시설이 되어야 합니다. 유해 콘텐츠 대응과 플랫폼 보안 강화가 필요한 서비스 제공자라면, 향후 정식 공개될 Coop과 Osprey를 적극적으로 도입하여 비용 효율적이면서도 전문적인 신뢰 및 안전(Trust & Safety) 역량을 확보할 것을 권장합니다.

Unraveling a Postgres segfault that uncovered an Arm64 JIT compiler bug (새 탭에서 열림)

Postgres 서버에서 발생한 'Segmentation fault(signal 11)' 오류의 원인을 추적하여, 이것이 Postgres 자체의 결함이 아니라 Arm64 아키텍처 환경에서 작동하는 LLVM(JIT 컴파일러)의 버그임을 밝혀낸 과정을 다루고 있습니다. 대규모 파티션 테이블을 조회할 때 JIT가 활성화되면서 크래시가 발생했으며, 이를 통해 업스트림 LLVM의 문제를 해결하는 성과를 거두었습니다. ## JIT 컴파일과 크래시의 상관관계 * **세그멘테이션 폴트 발생**: 최신 버전의 Postgres를 사용 중임에도 특정 쿼리(죽음의 쿼리)를 실행하면 서버가 즉시 종료되는 현상이 발생했습니다. * **스택 오염 확인**: 코어 덤프 분석 결과, 호출 스택(Backtrace)이 비정상적으로 짧고 깨져 있었으며, 이는 JIT 실행 함수인 `ExecRunCompiledExpr` 부근에서 문제가 발생했음을 시사했습니다. * **트리거 조건**: 64개의 파티션과 160만 개 이상의 행을 가진 대규모 테이블을 스캔할 때, Postgres의 비용 기반 휴리스틱에 의해 JIT 컴파일이 활성화되면서 오류가 유발되었습니다. ## Postgres JIT와 LLVM의 역할 * **성능 최적화**: Postgres는 반복적인 SQL 표현식 평가 오버헤드를 줄이기 위해 LLVM을 사용하여 런타임에 네이티브 머신 코드를 생성합니다. * **튜플 디포밍(Tuple Deforming)**: 디스크상의 데이터를 메모리 표현으로 변환하는 과정을 네이티브 코드로 컴파일하여 처리 효율을 극대화합니다. * **컴파일 오버헤드**: JIT는 실행 속도를 높이지만 컴파일 시간이 추가되므로, Postgres는 실행 비용이 높은 쿼리에 대해서만 선택적으로 JIT를 적용합니다. ## 문제 해결 및 근본 원인 파악 * **임시 조치**: `SET jit = off;` 설정을 통해 JIT 기능을 비활성화함으로써 쿼리 지연 시간의 큰 손해 없이 프로덕션 환경의 크래시를 즉시 중단시켰습니다. * **디버깅 결과**: 데이터 복제 및 로컬 환경 재현을 통해 분석한 결과, 특정 조건에서 LLVM이 Arm64 아키텍처용 머신 코드를 잘못 생성하는 버그가 있음을 확인했습니다. * **업스트림 기여**: 이 조사는 단순히 설정을 변경하는 것에 그치지 않고, 어셈블리 수준의 분석을 통해 LLVM 프로젝트의 코드 수정까지 이끌어내는 계기가 되었습니다. ## 권장 사항 Arm64 기반 클라우드 환경에서 Postgres를 운영 중인데 원인을 알 수 없는 Segmentation fault가 발생한다면, 우선적으로 JIT를 비활성화하여 안정성을 확보하십시오. 이후 시스템의 LLVM 라이브러리 버전을 확인하고 관련 아키텍처 패치가 적용되었는지 점검하는 것이 필요합니다.

장인정신과 아름다움 (새 탭에서 열림)

Linear는 서비스 마비 수준의 DDoS 공격을 단순한 보안 위협이 아닌, 시스템 전반의 기술 부채를 해결하고 성능을 극한으로 끌어올리는 기회로 삼았습니다. 공격자가 악용한 비효율적인 쿼리와 아키텍처의 약점을 근본적으로 개선함으로써, 사건 종료 후 Linear는 공격 전보다 훨씬 더 빠르고 안정적인 서비스로 거듭났습니다. 이는 보안 대응이 단순히 방어벽을 세우는 것을 넘어 시스템의 기초 체력을 강화하는 과정임을 시사합니다. ### DDoS 공격의 양상과 초기 대응의 한계 * 단순한 네트워크 트래픽 과부하가 아니라, 데이터베이스에 과부하를 주는 고비용 API 호출을 집중적으로 노린 정교한 애플리케이션 계층(L7) 공격이었습니다. * IP 차단이나 속도 제한(Rate Limiting) 같은 전통적인 방어 수단은 공격자가 패턴을 지속적으로 변경함에 따라 '두더지 잡기'식의 한계에 부딪혔습니다. * 공격이 지속되는 동안 시스템의 가장 느린 부분들이 병목 현상을 일으키며 전체 서비스 중단으로 이어지는 과정을 목격했습니다. ### 데이터베이스 성능 최적화와 쿼리 개선 * 공격자가 검색 및 필터링 기능을 악용한다는 점에 착안하여, 실행 계획(Query Plan) 분석을 통해 인덱스가 제대로 작동하지 않던 지점들을 대대적으로 수정했습니다. * 특히 '소프트 삭제(Soft Delete)' 처리를 위한 필터 조건이 쿼리 성능을 저하시키는 주요 원인임을 파악하고, 이를 최적화하여 데이터 조회 속도를 획기적으로 높였습니다. * Postgres 데이터베이스의 불필요한 Full Table Scan을 제거하고, 가장 빈번하게 호출되는 엔드포인트의 응답 시간을 밀리초 단위로 단축했습니다. ### 동기화 엔진 및 아키텍처 재설계 * Linear의 핵심인 오프라인 우선(Offline-first) 동기화 아키텍처에서 발생하는 오버헤드를 줄이기 위해 동기화 로직을 전면 재검토했습니다. * 클라이언트와 서버 간의 데이터 상태 비교 프로세스를 효율화하여, 동일한 작업을 수행할 때 발생하는 CPU 및 메모리 점유율을 대폭 낮췄습니다. * 결과적으로 인프라를 증설하지 않고도 이전보다 몇 배나 많은 동시 요청을 처리할 수 있는 구조적 회복 탄력성을 확보했습니다. 보안 사고는 시스템의 가장 취약한 고리를 드러내는 가혹한 테스트 베드가 될 수 있습니다. Linear의 사례처럼 공격에 단순히 방어적으로 대응하기보다 시스템 내부의 효율성을 높여 '공격의 가성비'를 떨어뜨리는 전략은, 보안과 성능이라는 두 마리 토끼를 잡을 수 있는 탁월한 접근 방식입니다. 성능 최적화가 곧 최선의 보안 대책이 될 수 있다는 점을 시사합니다.

2023-03-08 incident: A deep dive into our incident response (새 탭에서 열림)

2023년 3월 발생한 Datadog의 사상 첫 글로벌 장애는 대규모 복합 시스템을 운영하는 조직에 있어 장애는 '발생 여부'가 아닌 '발생 시기'의 문제임을 다시 한번 각인시켰습니다. Datadog은 수백 명의 엔지니어가 투입된 이 전례 없는 위기 상황에서 '직접 만든 사람이 직접 운영한다(You build it, you own it)'는 원칙과 체계적인 사고 대응(Incident Response) 프로세스를 통해 시스템을 복구할 수 있었습니다. 이번 장애 대응 과정은 기술적 해결을 넘어, 유연한 조직 구조와 비난 없는 문화(Blameless Culture)가 복잡한 시스템의 장애를 해결하는 데 얼마나 결정적인 역할을 하는지 증명했습니다. ### 데이터독의 상시 모니터링 및 대응 체계 * **다중 모니터링 전략:** 서비스 내부 모니터링뿐만 아니라, 플랫폼 전체가 중단된 상황에서도 작동할 수 있도록 외부 인프라에서 독립적으로 구동되는 '아웃 오브 밴드(Out-of-band)' 모니터링을 운영합니다. * **소유권 중심 모델:** 엔지니어가 자신이 구축한 서비스의 온콜(On-call) 업무를 직접 담당하며, 장애 발생 시 수 분 이내에 응답하는 것을 원칙으로 합니다. * **자동화된 협업 환경:** 장애가 선포되면 Slack 앱이 자동으로 전용 채널을 생성하고 상황을 공유하여, 직접 호출되지 않은 엔지니어도 자발적으로 참여할 수 있는 환경을 제공합니다. ### 고난도 장애를 위한 지휘 체계와 역할 분담 * **인시던트 커맨더(Incident Commander, IC):** 고객 영향도가 크거나 여러 팀의 협력이 필요한 고차원 장애 시, 숙련된 시니어 엔지니어가 IC 역할을 맡아 전체 대응을 진두지휘합니다. * **전담 커뮤니케이션 관리:** IC는 복구 작업에 집중하고, 별도의 커뮤니케이션 리드와 고객 연락 담당자(Customer Liaison)가 내부 상황 전파 및 대외 공지를 전담하여 혼선을 방지합니다. * **경영진의 참여:** 심각한 장애 시에는 엔지니어링 임원이 참여하여 비즈니스 맥락에 따른 의사결정을 지원하고 필요한 자원을 즉각 투입합니다. ### 훈련을 통한 숙련도 향상과 자율성 보장 * **낮은 장애 선포 장벽:** 평소 아주 작은 문제라도 장애로 규정하고 대응 프로세스를 가동함으로써, 엔지니어들이 도구와 절차에 익숙해지도록 유도합니다. * **정기적인 온콜 교육:** 모든 엔지니어는 6개월마다 온콜 교육을 이수해야 하며, 여기에는 기술적 절차뿐만 아니라 비난 없는 조사 방식에 대한 교육이 포함됩니다. * **사람 중심의 프로세스:** 미리 정의된 딱딱한 복구 절차(Runbook)에 의존하기보다, 시스템을 가장 잘 아는 엔지니어가 현장에서 최선의 판단을 내릴 수 있도록 자율성을 부여합니다. ### 3월 8일 글로벌 장애의 기술적 분석 및 교훈 * **장애 원인:** `systemd` 업그레이드 과정에서 발생한 예기치 못한 문제가 '무인 업그레이드(Unattended upgrades)'를 통해 확산되며 쿠버네티스 클러스터 실패를 유발했습니다. * **신속한 초기 대응:** 장애 발생 3분 만에 이상이 감지되었고, 30분 이내에 글로벌 장애로 진단되어 대응 체계가 가동되었습니다. * **심리적 안전감의 중요성:** 극심한 스트레스가 동반되는 글로벌 장애 상황에서 비난 없는 문화는 엔지니어들이 위축되지 않고 창의적인 해결책을 찾는 토대가 되었습니다. **실용적인 결론** 대규모 시스템의 장애는 완벽히 막을 수 없으므로, 조직은 **'사람과 문화'**에 투자해야 합니다. 기술적 자동화도 중요하지만, 장애 상황에서 유연하게 대처할 수 있는 숙련된 엔지니어를 양성하고 이들이 비난받을 두려움 없이 복구에 전념할 수 있는 환경을 조성하는 것이 가장 효과적인 재난 대비책입니다. 또한, 평상시 아주 작은 장애라도 공식 프로세스를 거쳐 대응하고 사후 분석(Postmortem)을 작성하는 습관을 통해 조직 전체의 복원력을 높여야 합니다.

2023-03-08 사건: 우리의 사건 대응에 대한 심층 분석 | Datadog (새 탭에서 열림)

Datadog은 2023년 3월 발생한 사상 첫 글로벌 서비스 장애를 겪으며 자사의 장애 대응(Incident Response) 프로세스와 문화를 실전에서 검증했습니다. 수백 명의 엔지니어가 투입된 이번 사태를 통해 Datadog은 "직접 만든 사람이 직접 운영한다(You build it, you own it)"는 원칙과 비난 없는 사후 분석(Blameless Postmortem)의 중요성을 다시 한번 확인했습니다. 이 글은 전례 없는 대규모 장애 상황에서 유연한 의사결정과 체계적인 협업 시스템이 어떻게 복구를 견인했는지에 대한 기술적 기록을 담고 있습니다. **Datadog의 장애 모니터링 및 대응 체계** * **소유권 기반 모델:** 모든 엔지니어링 팀은 자신이 구축한 서비스의 운영을 직접 책임지며, 24시간 모니터링 경보에 몇 분 내로 응답해야 하는 "You build it, you own it" 모델을 따릅니다. * **대역 외(Out-of-band) 모니터링:** 플랫폼 자체가 중단될 경우를 대비해 인프라 외부에서 API를 호출하여 사용자 관점에서 상태를 체크하는 별도의 독립적인 모니터링 시스템을 운영합니다. * **Slack 기반 협업:** 장애 발생 시 전용 앱이 Slack 채널을 자동으로 생성하며, 관련 없는 엔지니어도 자유롭게 참여하여 도움을 줄 수 있는 개방적인 환경을 조성합니다. **고심도 장애(High-Severity) 관리 및 역할 분담** * **장애 지휘관(Incident Commander):** 대규모 장애 시 숙련된 시니어 엔지니어가 투입되어 전체 대응을 진두지휘하며, 복구 전략과 커뮤니케이션을 총괄합니다. * **전담 커뮤니케이션 팀:** 고객 지원 매니저와 경영진이 포함된 별도 팀이 구성되어 외부 고객 및 비즈니스 이해관계자에게 정확한 상태 정보를 전달합니다. * **지속적인 훈련:** 장애 선언 문턱을 낮게 설정하여 일상적으로 장애 대응 프로세스를 연습하며, 모든 엔지니어는 6개월마다 필수 리프레시 교육을 이수해야 합니다. **자율성과 비난 없는 조직 문화** * **절차보다 사람 우선:** 고정된 복구 매뉴얼은 복잡한 시스템의 변화 속도를 따라갈 수 없으므로, 엔지니어가 현장에서 상황에 맞는 최선의 판단을 내릴 수 있도록 자율권을 부여합니다. * **비난 없는 문화(Blameless Culture):** 장애의 원인을 개인의 실수가 아닌 시스템의 결함으로 간주하여, 엔지니어가 압박감 속에서도 창의적인 해결책을 찾을 수 있도록 지원합니다. * **강화된 사후 분석:** 모든 고심도 장애 이후에는 자동화된 알림을 통해 상세한 포스트모템 작성을 독려하며, 이를 통해 유사 장애의 재발을 방지합니다. **3월 8일 글로벌 장애 타임라인 및 초기 진단** * **장애 트리거(06:00 UTC):** systemd 업데이트가 시작되면서 예상치 못한 인프라 연쇄 반응이 발생했습니다. * **신속한 감지(06:03~06:18 UTC):** 장애 발생 3분 만에 모니터링 시스템이 문제를 감지했고, 15분 이내에 고심도 장애로 격상되었습니다. * **원인 파악(07:20~11:36 UTC):** 쿠버네티스(Kubernetes) 노드 실패가 글로벌 장애의 핵심 원인임을 식별했으며, 최종적으로 '무인 업데이트(Unattended upgrades)'가 트리거였음을 밝혀냈습니다. * **인프라 복구(12:05~19:00 UTC):** EU1 및 US1 리전의 컴퓨팅 용량을 순차적으로 복구하고 재발 방지를 위한 완화 조치를 적용하여 전체 인프라를 정상화했습니다. 대규모 시스템을 운영하는 조직이라면 고정된 대응 매뉴얼에 의존하기보다 엔지니어의 자율성을 존중하고, 장애를 학습의 기회로 삼는 비난 없는 문화를 구축하는 것이 중요합니다. 특히 플랫폼 전체가 마비되는 최악의 상황을 대비해 인프라 외부에서 독립적으로 작동하는 '대역 외 모니터링' 체계를 반드시 갖출 것을 추천합니다.

포스트모템: 20 (새 탭에서 열림)

2020년 4월 29일 발생한 Figma의 서비스 장애는 메인 데이터베이스인 PostgreSQL의 메모리 부족(OOM)으로 인해 발생했습니다. 근본 원인은 시스템 카탈로그 테이블인 `pg_attribute`의 비정상적인 팽창(Bloat)이었으며, 이는 장기 실행 트랜잭션이 데이터 정리를 방해하면서 발생한 연쇄적인 성능 저하의 결과였습니다. 결과적으로 모든 데이터베이스 연결이 지연되고 메모리가 고갈되면서 전체 서비스가 중단되는 사태에 이르렀습니다. ### 시스템 카탈로그(pg_attribute)의 비정상적 팽창 * PostgreSQL에서 테이블 열(column) 정보를 저장하는 `pg_attribute` 테이블이 약 64GB까지 비대해지는 현상이 발생했습니다. * 모든 SQL 쿼리는 실행 계획을 세울 때 이 시스템 카탈로그를 참조해야 하므로, 이 테이블의 성능 저하는 곧 모든 DB 작업의 지연으로 직결되었습니다. * 평소 1ms 미만이던 메타데이터 조회 시간이 수 초 단위로 늘어났고, 이는 데이터베이스 연결(Connection)의 급증과 메모리 점유율 상승으로 이어졌습니다. ### VACUUM 작동 불능과 장기 실행 트랜잭션 * PostgreSQL의 가비지 컬렉션 역할을 하는 VACUUM 프로세스가 `pg_attribute` 내의 불필요한 행(dead tuples)을 정리하지 못하는 상태였습니다. * 장애 발생 당시 며칠 동안 유지되고 있던 '장기 실행 트랜잭션(Long-lived transaction)'이 원인이었습니다. 이 트랜잭션이 특정 시점의 데이터 스냅샷을 붙잡고 있어, VACUUM이 그 이후에 생성된 쓰레기 데이터를 삭제할 수 없게 방해했습니다. * 이 상태에서 대량의 임시 테이블 생성 및 삭제 작업이 반복되자, 정리되지 못한 행들이 기하급수적으로 쌓이며 테이블 크기가 폭발적으로 증가했습니다. ### 장애 전파 및 복구 과정 * 팽창된 시스템 테이블로 인해 쿼리 분석 단계에서 과도한 메모리가 사용되었고, 결국 Primary DB 인스턴스가 OOM(Out of Memory) 상태에 빠져 모든 서비스를 중단시켰습니다. * Figma 팀은 즉각적인 가용성 확보를 위해 DB 인스턴스를 더 높은 메모리 사양으로 수직 확장(Scale-up)했습니다. * 이후 VACUUM의 정상 작동을 가로막던 오래된 트랜잭션들을 강제로 종료하고, 시스템 테이블에 대한 `REINDEX`를 수행하여 비대해진 인덱스를 정리함으로써 성능을 정상화했습니다. ### 재발 방지를 위한 권장 사항 데이터베이스의 안정성을 유지하기 위해서는 사용자 데이터뿐만 아니라 시스템 메타데이터의 상태를 정기적으로 점검해야 합니다. 특히 장기 실행 트랜잭션은 VACUUM 효율을 떨어뜨려 DB 전체에 치명적인 영향을 줄 수 있으므로, 특정 시간(예: 5분) 이상 지속되는 트랜잭션을 자동으로 종료하는 설정(`idle_in_transaction_session_timeout`)을 도입하고 시스템 테이블 크기에 대한 모니터링 알람을 구축하는 것이 권장됩니다.