Aphyr가 던진 질문: 소프트웨어의 '안전'이라는 말, 정말 믿어도 되는 걸까?

"안전합니다"라는 말 뒤에 숨은 것들

분산 시스템 테스트 도구 Jepsen으로 유명한 Kyle Kingsbury(aphyr)가 최근 꽤 도발적인 글을 올렸어요. 핵심 주장은 이래요. 소프트웨어 업계에서 "안전하다(safe)"라는 표현이 너무 가볍게 쓰이고 있다는 거예요. 제품 페이지에 "안전한 동시성", "메모리 안전", "타입 안전"이라고 써놓지만, 정작 그 "안전"이 무엇으로부터의 안전인지, 어떤 조건에서의 안전인지는 명확하지 않은 경우가 너무 많다는 이야기죠.

Aphyr를 잘 모르시는 분을 위해 간단히 소개하면, 이분은 데이터베이스나 분산 시스템이 "우리 제품은 데이터를 안전하게 보관합니다"라고 주장할 때, 실제로 그런지 직접 테스트해보는 일을 하는 사람이에요. 그리고 그 결과, 수많은 유명 데이터베이스들이 광고와 다르게 데이터를 잃어버리거나 일관성을 깨뜨리는 것을 밝혀냈죠.

"안전"의 스펙트럼, 생각보다 넓어요

글에서 aphyr가 짚는 핵심 문제는 "안전"이라는 단어가 맥락에 따라 완전히 다른 의미를 가진다는 거예요.

Rust가 말하는 "메모리 안전"은 메모리 접근 오류(버퍼 오버플로우, use-after-free 등)로부터의 안전을 의미해요. 이건 꽤 명확한 정의가 있고, 컴파일러가 강제하는 수준의 보장이에요. 반면에 어떤 프레임워크가 "스레드 안전"하다고 할 때, 그건 데이터 경합(data race)이 없다는 뜻일 수도 있고, 단순히 뮤텍스를 써서 크래시는 안 난다는 뜻일 수도 있어요. 두 경우의 실질적인 안전성 수준은 하늘과 땅 차이인데, 같은 단어로 포장되는 거죠.

더 넓게 보면 "안전한 AI"라는 표현도 마찬가지예요. 어떤 맥락에서는 편향이 없다는 뜻이고, 다른 맥락에서는 유해한 콘텐츠를 생성하지 않는다는 뜻이고, 또 다른 맥락에서는 인류를 위협하지 않는다는 뜻이에요. 한 단어 안에 이렇게 다른 레벨의 주장이 뒤섞여 있으면, 결국 소비자(개발자)가 혼란에 빠질 수밖에 없어요.

거짓말은 아니지만, 진실도 아닌 것들

Aphyr가 지적하는 더 근본적인 문제는, 이런 "안전" 주장들이 기술적으로 완전히 틀린 건 아니라는 점이에요. 절반의 진실이라고 할까요. 특정 조건 하에서는 정말 안전한데, 그 조건이 실제 운영 환경과 맞지 않는 경우가 많다는 거예요.

예를 들어 "이 데이터베이스는 ACID를 완벽하게 지원합니다"라고 했을 때, 작은 글씨로 "단, 기본 설정이 아닌 특정 격리 수준을 명시적으로 설정했을 때"라는 조건이 붙어있는 경우가 실제로 많아요. Aphyr의 Jepsen 테스트가 여러 데이터베이스에서 이런 괴리를 발견해왔고요.

이건 클라우드 서비스의 SLA(서비스 수준 협약)에서도 비슷한 패턴이 보여요. "99.99% 가용성"이라고 하지만 실제 장애가 나면 보상 조건이 아주 까다롭게 걸려있는 것과 마찬가지죠.

업계에서 이런 논의가 왜 중요한가요?

소프트웨어가 의료, 자율주행, 금융 같은 안전이 정말 중요한(safety-critical) 영역으로 확장되면서, "안전"이라는 단어의 의미를 정확히 하는 게 점점 더 중요해지고 있어요. 항공이나 의료 분야에서는 "안전"을 주장하려면 인증과 검증 과정을 거쳐야 하는데, 소프트웨어 업계에서는 마케팅 문구에 "safe"를 쓰는 데 아무런 제약이 없거든요.

Rust 커뮤니티에서도 unsafe 블록의 경계와 그 안에서의 보장에 대한 논의가 활발하고, 형식 검증(formal verification) 분야에서는 아예 수학적으로 안전성을 증명하려는 시도도 있어요. 하지만 이런 엄밀한 접근은 아직 대부분의 실무 프로젝트에는 적용되기 어려운 상태예요.

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

이 글이 던지는 메시지는 꽤 실용적이에요. 라이브러리나 서비스를 도입할 때 "안전하다"는 주장을 그대로 받아들이지 말고, 구체적으로 "무엇으로부터" "어떤 조건에서" 안전한지를 따져보라는 거예요.

데이터베이스를 선택할 때 "강력한 일관성 보장"이라는 문구만 보지 말고, 기본 설정에서 어떤 격리 수준이 적용되는지, 네트워크 파티션 상황에서 어떻게 동작하는지를 문서에서 직접 확인해보세요. 프레임워크가 "타입 안전"하다고 할 때, 런타임에서도 그 보장이 유지되는지, 아니면 컴파일 타임에서만 그런 건지 구분하는 것도 중요하고요.

결국 좋은 엔지니어는 추상적인 "안전"을 믿는 사람이 아니라, 그 안전의 경계와 전제 조건을 이해하는 사람이라는 거예요.