IL-0576 CareNet · 2025-10-07 (게시일)databasegcp
테스트 코드가 운영 BigQuery 데이터 웨어하우스의 데이터셋을 전부 지웠다
CareNet 은 BigQuery 를 운영 데이터 웨어하우스로 쓴다. 이 데이터 웨어하우스는 사용자가 쓰는 서비스와 연결되어 있지 않다. 여러 부서가 Google Cloud 프로젝트 하나를 함께 쓰며 데이터 분석용으로 데이터를 모은다. 2025년 8월 어느 날, AI 기술 개발실이 수정하던 테스트 코드가 설정 실수로 운영 환경을 대상으로 실행됐다. 이 코드는 테스트 데이터를 초기화하려고 데이터셋을 지우고 같은 이름으로 다시 만드는 코드였고, 그 결과 운영 환경의 데이터셋이 전부 지워졌다. 삭제를 실행한 것은 AI 기술 개발실의 서비스 계정이었고, 이 서비스 계정에는 필요 이상의 권한이 있었다.
10:41 에 시스템 개발 본부가 장애를 처음 알렸고, 11:47 에 원인이 된 서비스 계정을 찾았다. 데이터셋을 되살리는 UNDROP SCHEMA 쿼리는 같은 이름의 데이터셋이 이미 새로 만들어져 있어서 동작하지 않았다. 13:06 에 AI 기술 개발실이 복원 방법을 알아냈다. BigQuery 의 타임 트래블 기능은 지난 7일 안의 특정 시점 상태를 되살릴 수 있고, Cloud Shell 에서 bq cp 명령에 장애 전 시점을 지정하면 같은 이름의 데이터셋이 다시 만들어진 뒤에도 테이블을 복원할 수 있었다. 팀은 테이블을 하나씩 복원했고 16:00 까지 테이블 대부분이 돌아왔다. 이 방법으로는 뷰와 테이블 함수를 되살릴 수 없어서 저장된 쿼리에 남아 있던 생성 쿼리로 다시 만들었다. 그 뒤 AI 기술 개발실은 포스트모템을 열어 원인과 재발 방지책을 정리하고 다른 부서에 공유했다.
- 심각도
- –
- 영향 범위
- All datasets of the production BigQuery data warehouse used for data analysis by several departments; it is not connected to user-facing services
- 영향 사용자
- –
- 지역
- –
- 감지까지
- –
- 복구까지
- –
증상
2025년 8월 어느 날 10:41 에 시스템 개발 본부가 Slack 에 BigQuery 에서 장애가 났다는 첫 보고를 올렸다. 운영 데이터 웨어하우스의 데이터셋이 모두 지워져 있었다.
11:00 에 AI 기술 개발실 회의에서 이 장애가 화제에 올랐지만, 이 팀은 자기들이 원인이라고 생각하지 못하고 지켜보기만 했다. 11:47 에 시스템 개발 본부가 조사해 AI 기술 개발실의 서비스 계정이 운영 환경의 데이터셋을 지운 것을 밝혀냈다.
12:44 에 시스템 개발 본부가 데이터셋을 되살리려고 실행한 UNDROP SCHEMA 쿼리가 동작하지 않는다고 알렸다. 지워진 데이터셋과 같은 이름의 데이터셋이 곧바로 새로 만들어져 있어서, BigQuery 가 복원할 대상 데이터셋이 없다고 판단한 것으로 보였다.
13:06 에 AI 기술 개발실이 Cloud Shell 에서 bq cp 명령을 쓰면 테이블 단위로는 복원할 수 있을지 모른다는 것을 알아냈다.
증상 데이터 유실
원인
원인 운영 실수
- 촉발
- 수정 중이던 테스트 코드가 테스트 환경의 데이터를 초기화하려고 데이터셋을 지우고 같은 이름으로 다시 만드는 처리를 했는데, 설정이 잘못되어 이 처리가 운영 환경의 모든 데이터셋에 실행됐다.
감지
10:41 에 시스템 개발 본부가 Slack 에 BigQuery 에서 장애가 났다는 첫 보고를 올렸다. 11:47 에 시스템 개발 본부가 조사해 AI 기술 개발실의 서비스 계정이 운영 데이터셋을 지운 것을 찾았다.
조치
- Cloud Shell 에서 bq cp 명령에 장애 전 시점을 지정해 타임 트래블로 테이블을 하나씩 복원했고, 데이터 대부분을 잃지 않고 되살렸다.
- bq cp 로 되살릴 수 없는 뷰와 테이블 함수는 BigQuery 의 저장된 쿼리에 남아 있던 생성 쿼리로 다시 만들었다.
후속 조치
- 테스트 코드가 운영 환경에 접근하지 못하게 확실히 막는다.
- 서비스 계정에 주어져 있던 과한 권한을 정리한다.
- bq cp 로 복원하려면 테이블 이름을 알아야 하므로, 데이터셋과 테이블 정보를 메타데이터로 관리한다.
- bq cp 로는 뷰와 테이블 함수를 복원할 수 없으므로, 그 생성 쿼리를 GitHub 같은 곳에서 관리한다.
- BigQuery 의 백업 방식을 검토한다.
교훈
bq cp 로 복원하려면 테이블 이름을 알고 있어야 하고, 이 방법으로는 뷰와 테이블 함수를 되살릴 수 없다. 글쓴이의 팀은 BigQuery 의 타임 트래블 기능과 bq cp 명령 덕분에 데이터 대부분을 되살릴 수 있었다고 정리했다.
출처
관련 사례
같은 원인 · 공통 데이터베이스
IL-0242primary 와 secondary PostgreSQL 데이터베이스를 모두 잃어 matrix.org homeserver 가 약 24시간 동안 멈췄다Matrix.org Foundation · 2025같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
IL-0531West US 의 Azure Database for MySQL Single Server 와 MariaDB 일부 서버로 가는 새 연결이 모두 거부됐다Microsoft Azure · 2024같은 원인 · 공통 데이터베이스
IL-0565쿠키런: 킹덤의 CockroachDB 클러스터가 노드 24대 중 16대의 파일 시스템을 잃고 멈춰 게임이 36시간 넘게 점검에 들어갔다Devsisters · 2022같은 원인 · 공통 데이터베이스
IL-0207로컬 개발 환경에서 돌린 작업이 운영 컨텍스트로 넘어가 Kubernetes 클러스터의 Consul 릴리스를 통째로 지웠고, Patroni 가 무너져 GitLab.com 전체가 5XX 오류를 냈다.GitLab · 2022같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
IL-0506UC Berkeley DataHub 의 JupyterHub sqlite 데이터베이스가 빈 데이터베이스로 덮어써져 로그인이 실패하고 홈 디렉터리가 비어 보이고 다른 사용자로 로그인되는 문제가 났다UC Berkeley · 2017같은 원인 · 공통 데이터베이스
IL-0218복제를 다시 맞추다 PostgreSQL 프라이머리의 데이터 디렉터리가 지워지고 백업이 작동하지 않아 GitLab.com 이 약 18시간 멈추고 데이터를 잃었다GitLab · 2017같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
IL-0319mysql2 를 다시 적재하려고 데이터베이스를 지우는 동안 mysql1 의 데이터베이스도 함께 지워졌다Oregon State University Open Source Lab · 2015같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
내 클러스터에도 있는지 확인하기
AI 도구와 스크립트용
- 이 사례의 JSON: https://incidentlib-api.benchlet.com/cases/IL-0576
- 가장 비슷한 사례들: https://incidentlib-api.benchlet.com/cases/IL-0576/similar
- MCP 서버(Streamable HTTP, 키 없음):
https://incidentlib-mcp.benchlet.com/mcp
API 는 키가 필요 없습니다. MCP 서버는 search_incidents, get_incident, list_incidents, get_topic, vocab 도구를 내놓습니다. 사용법은 API 와 MCP.