Dropbox는 어떻게 동기화 버그를 잡을까? 속성 기반 테스트로 분산 시스템 검증하기

파일 동기화, 생각보다 훨씬 어려운 문제예요

여러분이 노트북에서 파일을 수정하고, 동시에 폰에서도 같은 파일을 고쳤다고 해볼게요. Dropbox 같은 동기화 서비스는 이 두 변경 사항을 어떻게든 합쳐야 하는데요, 이게 말처럼 단순하지가 않아요. 네트워크가 끊긴 상태에서 편집이 일어날 수도 있고, 폴더를 옮기면서 동시에 그 안의 파일을 삭제할 수도 있거든요. 이런 상황에서 "올바른 결과"가 뭔지조차 정의하기 어려운 경우가 많아요.

펜실베이니아 대학교의 Benjamin Pierce 교수 연구팀이 바로 이 문제를 파고들었어요. Dropbox의 동기화 엔진을 "속성 기반 테스트(Property-Based Testing)"라는 기법으로 체계적으로 검증한 논문을 발표했는데, 그 과정에서 발견한 것들이 정말 흥미롭습니다.

속성 기반 테스트, 이게 뭐냐면

보통 우리가 테스트를 작성할 때는 "이 입력을 넣으면 이 출력이 나와야 한다"는 식으로 구체적인 예시를 하나하나 적잖아요. 이걸 예시 기반 테스트(Example-Based Testing)라고 해요. 반면 속성 기반 테스트는 접근 방식이 달라요. "어떤 입력을 넣든 이런 성질은 항상 만족해야 한다"는 규칙을 정의하고, 컴퓨터가 랜덤으로 수천, 수만 개의 입력을 생성해서 그 규칙이 깨지는 경우를 찾아내는 거예요.

비유하자면, 예시 기반 테스트가 "서울에서 부산까지 KTX 요금이 59,800원인지 확인"하는 거라면, 속성 기반 테스트는 "어떤 구간이든 요금이 음수가 되면 안 된다", "왕복 요금은 편도 요금의 2배 이하여야 한다" 같은 불변 조건(invariant)을 검증하는 방식이에요. 예상하지 못한 엣지 케이스를 잡아내는 데 훨씬 강력하죠.

분산 동기화에서 "올바름"을 어떻게 정의할까

이 논문에서 가장 어려웠던 부분은 사실 테스트 도구가 아니라, "Dropbox의 동기화가 올바르다는 건 정확히 무슨 뜻인가?"를 정의하는 것이었어요. 연구팀은 동기화 시스템이 반드시 만족해야 할 핵심 속성들을 이렇게 정리했어요.

첫 번째는 수렴(Convergence)인데요, 모든 기기가 같은 변경 사항을 받으면 결국 같은 상태에 도달해야 한다는 거예요. 노트북과 폰이 서로 다른 파일 내용을 보여주면 곤란하잖아요. 두 번째는 의도 보존(Intent Preservation)으로, 사용자가 한 행동의 의미가 동기화 과정에서 사라지면 안 된다는 원칙이에요. 예를 들어 파일을 새로 만들었는데 동기화 후에 그 파일이 없어져버리면 문제가 되겠죠.

연구팀은 이 속성들을 수학적으로 엄밀하게 정의한 다음, QuickCheck 스타일의 속성 기반 테스트 프레임워크를 사용해서 Dropbox 클라이언트에 수만 가지 시나리오를 자동 생성해 던졌어요. 두 대의 가상 클라이언트가 오프라인 상태에서 각각 다른 작업을 수행하고, 다시 온라인이 되어 동기화하는 과정을 시뮬레이션한 거죠.

발견된 흥미로운 "미스터리"들

논문 제목에 "미스터리"라는 단어가 들어간 데는 이유가 있어요. 실제로 Dropbox의 동작 중에서 명세(specification)만으로는 설명이 안 되는 예상 밖의 동작들이 여러 건 발견됐거든요.

특히 흥미로운 케이스는 디렉토리 충돌 처리예요. 한 쪽에서 폴더 A 안에 파일을 넣고, 동시에 다른 쪽에서 폴더 A를 삭제하면 어떻게 될까요? Dropbox는 이 경우 삭제된 폴더를 복원하면서 양쪽의 변경을 모두 살리는 전략을 쓰는데, 특정 조건에서는 이 복원 로직이 예상과 다르게 동작하는 경우가 있었어요. 데이터가 손실되는 건 아니지만, 사용자가 의도하지 않은 디렉토리 구조가 만들어질 수 있는 상황이었죠.

이런 발견은 속성 기반 테스트의 강점을 잘 보여줘요. 사람이 일일이 "폴더 삭제 + 파일 생성 + 오프라인 + 재동기화" 같은 복잡한 시나리오를 떠올리기는 정말 힘든데, 자동 생성으로 이런 코너 케이스를 체계적으로 찾아낸 거니까요.

업계에서의 위치: 속성 기반 테스트의 부활

속성 기반 테스트 자체는 1999년 Haskell의 QuickCheck에서 시작된 꽤 오래된 개념이에요. 하지만 최근 몇 년 사이에 분산 시스템 검증에서 다시 주목받고 있어요. AWS는 자사의 S3, DynamoDB 같은 핵심 서비스에 형식 검증(Formal Verification)과 속성 기반 테스트를 적극적으로 적용하고 있고, FoundationDB 팀도 시뮬레이션 기반 테스트로 유명하죠.

이 논문이 특별한 건, 학계에서 실제 상용 제품(Dropbox)을 블랙박스로 테스트했다는 점이에요. 소스코드 없이 외부에서 관찰 가능한 동작만으로 속성을 검증한 거라, 여러분이 서드파티 API나 외부 서비스의 신뢰성을 검증할 때도 같은 접근법을 적용할 수 있어요.

Python에서는 Hypothesis, Java에서는 jqwik, JavaScript/TypeScript에서는 fast-check 같은 라이브러리가 있어서 속성 기반 테스트를 비교적 쉽게 시작할 수 있어요.

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

솔직히 말하면, 국내 프로젝트에서 속성 기반 테스트를 적극적으로 활용하는 팀은 아직 많지 않아요. 하지만 적용 효과가 큰 영역이 분명히 있어요. 결제 시스템처럼 금액 계산의 정합성이 중요한 곳, 여러 사용자가 동시에 편집하는 협업 도구, 혹은 이벤트 소싱 기반 시스템에서 이벤트 재생 결과의 일관성을 검증할 때 속성 기반 테스트가 빛을 발하거든요.

특히 요즘 실시간 협업 기능을 개발하는 팀이 많은데, CRDT(Conflict-free Replicated Data Type)나 OT(Operational Transformation) 같은 동기화 알고리즘을 구현할 때 이 논문의 접근법을 참고하면 정말 유용할 거예요. "수렴"과 "의도 보존"이라는 두 가지 속성을 정의하고 자동으로 검증하는 패턴은 거의 그대로 가져다 쓸 수 있으니까요.

핵심 정리

분산 시스템의 "올바름"은 정의하기도 어렵고 테스트하기는 더 어렵지만, 속성 기반 테스트는 사람이 미처 생각하지 못한 엣지 케이스를 체계적으로 찾아주는 강력한 도구예요. 여러분의 프로젝트에서 "이건 어떤 상황에서든 항상 참이어야 한다"고 말할 수 있는 규칙이 있다면, 그게 바로 속성 기반 테스트를 적용할 첫 번째 후보입니다.

혹시 속성 기반 테스트를 실무에 적용해 본 경험이 있으신가요? 아니면 "이건 적용해 보면 좋겠다" 싶은 영역이 있다면 공유해 주세요!