파일 시스템, 감으로 만들면 안 되는 이유 — 스탠포드의 Jai 프로젝트

파일 시스템이 왜 이렇게 어려운 걸까요?

여러분이 코드에서 파일을 저장하는 건 아주 간단해 보여요. write()를 호출하면 끝이니까요. 그런데 그 뒤에서 실제로 무슨 일이 벌어지는지 생각해 본 적 있나요? 운영체제의 파일 시스템은 여러분의 데이터가 디스크에 안전하게 기록되도록 보장해야 하는데, 이게 정말 보기보다 훨씬 복잡한 문제거든요. 특히 파일을 쓰는 도중에 전원이 나가거나 시스템이 크래시되면 어떻게 될까요? 데이터가 반쯤 써진 상태로 남아서 파일이 깨질 수도 있어요.

스탠포드 대학 연구팀이 공개한 Jai(Just-in-time Automated Inconsistency detection) 프로젝트는 바로 이 문제를 정면으로 다루고 있어요. "파일 시스템을 YOLO로 만들지 마라"는 제목 자체가 핵심 메시지를 담고 있는데요, 여기서 YOLO는 우리가 흔히 쓰는 "한 번 사는 인생" 그 뜻이 아니라, "대충 감으로 짜고 잘 되겠지 하고 넘어가는 것"을 의미해요.

크래시 일관성이라는 난제

파일 시스템에서 가장 까다로운 문제 중 하나가 크래시 일관성(crash consistency)이에요. 이게 뭐냐면, 시스템이 예기치 않게 죽었다가 다시 켜졌을 때 파일 시스템이 여전히 정상적인 상태를 유지하느냐는 거예요. 예를 들어볼게요. 여러분이 문서 파일을 저장할 때, 파일 시스템 내부에서는 사실 여러 단계가 순차적으로 일어나요. 파일의 메타데이터(크기, 수정 시간 등)를 업데이트하고, 실제 데이터 블록을 디스크에 쓰고, 저널(일종의 기록장)에 이 작업을 로깅하고... 이 과정 중간에 전원이 나가면, 메타데이터는 업데이트됐는데 실제 데이터는 안 써진 상태가 될 수 있어요. 그러면 파일을 열었을 때 이전 데이터나 쓰레기 값이 보이는 거죠.

전통적으로 파일 시스템 개발자들은 이런 문제를 저널링(journaling)이나 COW(Copy-on-Write) 같은 기법으로 해결해왔어요. 저널링은 말 그대로 "작업 일지"를 먼저 써놓고 실제 작업을 수행하는 방식이고, COW는 기존 데이터를 덮어쓰지 않고 새 위치에 쓴 다음 포인터만 바꾸는 방식이에요. 하지만 이런 메커니즘을 올바르게 구현하는 건 정말 어려운 일이에요. 실제로 ext4, Btrfs 같은 유명 파일 시스템에서도 크래시 일관성 관련 버그가 계속 발견되어 왔거든요.

Jai는 어떻게 이 문제를 풀까요?

Jai의 핵심 아이디어는 파일 시스템의 크래시 일관성을 자동으로 검증하는 거예요. 기존에는 파일 시스템 개발자가 머릿속으로 "이 시점에서 크래시가 나면 이런 상태가 될 거고, 복구하면 이렇게 되겠지"라고 추론했다면, Jai는 가능한 크래시 시나리오를 체계적으로 탐색해서 문제가 될 수 있는 상태를 자동으로 찾아내요.

구체적으로 보면, Jai는 파일 시스템 연산이 디스크에 쓰는 명령들을 추적하고, 그 명령들 사이의 모든 가능한 크래시 지점을 시뮬레이션해요. 그리고 각 크래시 지점에서 파일 시스템을 복구한 뒤 결과가 올바른지 검사하는 거죠. 이게 마치 게임에서 모든 분기점을 다 플레이해보는 것과 비슷해요. 사람이 일일이 하면 경우의 수가 너무 많아서 놓치기 쉬운 케이스를, 도구가 자동으로 다 뒤져보는 거예요.

이 접근법의 강점은 파일 시스템 코드 자체를 수정할 필요 없이, 외부에서 블랙박스처럼 테스트할 수 있다는 점이에요. 새로운 파일 시스템을 개발하든, 기존 파일 시스템에 패치를 적용하든, Jai를 돌려서 크래시 일관성이 깨지는 시나리오가 없는지 확인할 수 있어요.

왜 지금 이게 중요할까요?

파일 시스템 연구가 갑자기 주목받는 데는 이유가 있어요. 클라우드 환경에서 분산 스토리지의 중요성이 계속 커지고 있고, NVMe SSD 같은 새로운 스토리지 하드웨어가 기존의 가정들을 바꾸고 있거든요. 예전에는 HDD 기준으로 설계했던 파일 시스템이, 수십 배 빠른 SSD 환경에서는 다른 종류의 크래시 시나리오를 만들어낼 수 있어요. 쓰기 순서가 달라지거나, 캐시 플러시 타이밍이 바뀌거나 하면서요.

비슷한 맥락에서 ALICE(Application-Level Intelligent Crash Explorer)나 CrashMonkey 같은 기존 도구들도 파일 시스템 크래시 테스팅을 다뤄왔는데요, Jai는 이전 연구들의 한계를 보완하면서 더 실용적인 접근을 취하고 있다는 평가를 받고 있어요. 특히 실제 워크로드에서 발생할 수 있는 시나리오에 집중한다는 점이 차별화 포인트예요.

한국 개발자에게 주는 시사점

"나는 파일 시스템 개발자가 아닌데?"라고 생각할 수 있지만, 이 연구가 주는 교훈은 모든 개발자에게 해당돼요. 데이터베이스를 직접 만들거나, 로그 시스템을 구현하거나, 심지어 설정 파일을 쓰는 코드를 작성할 때도 크래시 일관성 문제는 발생할 수 있어요. 예를 들어 설정 파일을 업데이트할 때 직접 파일을 덮어쓰는 대신, 임시 파일에 먼저 쓰고 rename()으로 원자적(atomic)으로 교체하는 패턴이 있거든요. 이런 디테일을 모르면 운이 나쁜 날 데이터가 날아갈 수 있어요.

또한 국내에서도 카카오, 네이버, 토스 같은 서비스들이 대규모 스토리지 인프라를 운영하면서 파일 시스템 수준의 안정성이 점점 더 중요해지고 있어요. 특히 금융 서비스처럼 데이터 유실이 곧 사고인 영역에서는 이런 연구가 직접적인 실무 가치가 있죠.