요약
- 12장. 데이터 시스템의 미래의 나머지 부분에 대해 이해함.
- 정확성을 목표로
- 믿어라. 하지만 확인하라.
- 소프트웨어 버그가 발생해도 무결성 유지하기
- 약속을 맹목적으로 믿지 마라.
- 검증하는 문화
- 감사 기능 설계
- 다시 종단 간 논증
- 감사 데이터 시스템용 도구
- 옳은 일 하기
메모
믿어라. 하지만 확인하라.
- 시스템 모델은 실제 상황을 가정하고 이를 기반으로 시스템을 설계하며, 여기에는 프로세스의 실패, 장치의 전원 중단, 네트워크 지연 등의 가능성이 포함됨.
- 그러나 디스크에 쓴 데이터는 fsync 이후에 안전하며, 메모리 상의 데이터는 손상되지 않고, CPU의 계산은 정확하다는 가정도 함.
- 이러한 가정은 대체로 합리적이며, 시스템 모델은 전통적으로 결함에 대한 이원 접근법을 사용하여 어떤 상황은 발생할 수 있고, 다른 상황은 절대 발생하지 않는다고 가정함.
- 그러나 실제로는 확률적 문제로, 어떤 것은 가능성이 높고 어떤 것은 가능성이 낮음.
- 디스크에 아무 일도 없는 상황에서 데이터 손상이 계속 발생하며, TCP 체크섬에서 걸리지 않는 네트워크 상의 데이터 손상도 발생함.
- 또한, 메모리의 무작위 비트 플립(bit-flips)이 발생하는 상황도 간혹 보고되었음.
- 이러한 상황은 매우 드물지만, 소프트웨어를 실행하는 장치가 많을 경우 이런 드문 사건들이 발생할 수 있음.
- 결함이 없는 메모리에서도 비트 플립을 발생시킬 수 있는 병적인 메모리 접근 패턴이 존재하며, 이러한 효과는 보안 메커니즘을 무력화하는 데 사용되곤 함.
- 실제로 하드웨어는 완벽한 추상화를 제공하지 않으며, 무작위 비트 플립은 현대 하드웨어에서 거의 발생하지 않지만, 그럼에도 이 문제가 완전히 가능성의 영역을 벗어나지 않는다는 것에 주의를 기울여야 함.
소프트웨어 버그가 발생해도 무결성 유지하기
- 소프트웨어 버그는 항상 존재하는 위험성이며, 이는 저수준 네트워크, 메모리 또는 파일 시스템 체크섬으로는 발견할 수 없음.
- 심지어 널리 사용하는 데이터베이스 소프트웨어에서도 버그가 발견되며, MySQL이 유일성 제약 조건을 올바르게 유지하는 데 실패하는 경우, PostgreSQL에서 쓰기 스큐 이상 현상이 발생하는 경우 등이 그 예임.
- 설계, 테스트, 리뷰에 신중을 기하더라도 버그는 여전히 발생하며, 버그가 발견되고 수정되는 동안에 데이터가 손상될 가능성이 있음.
- 애플리케이션 코드에서는 더 많은 버그를 각오해야 함.
- 대부분의 애플리케이션은 데이터베이스 코드만큼 리뷰와 테스트를 받지 못하며, 많은 애플리케이션이 외래키나 유일성 제약 조건 같은 데이터베이스가 무결성 보장을 위해 제공하는 기능을 올바르게 사용하지 않음.
- ACID에서 일관성은 데이터베이스가 일관성 있는 상태로 시작해서 트랜잭션이 데이터베이스를 일관성 있는 어떤 상태에서 일관성 있는 다른 상태로 바꾸는 개념을 기반으로 함.
- 그러나 이는 트랜잭션에 버그가 없을 때만 통하며, 애플리케이션에서 데이터베이스를 정확하게 사용하지 않을 경우, 데이터베이스 무결성은 보장되지 않음.
약속을 맹목적으로 믿지 마라.
- 하드웨어와 소프트웨어는 항상 이상적으로 동작하지 않기 때문에 데이터 손상은 반드시 발생함.
- 이러한 이유로, 버그를 수정하고 오류의 원인을 추적하기 위해 데이터가 손상되었는지를 확인할 수 있는 방법이 필요하며, 이를 감사(auditing)라고 함.
- 감사는 회계 애플리케이션에만 국한된 것이 아니며, 특히 재무에서는 매우 중요함.
- 이는 실수가 항상 발생하며, 모든 이슈를 감지하고 해결할 필요가 있다는 인식이 공통적으로 있기 때문임.
- 성숙한 시스템들은 가능성이 낮더라도 문제가 발생할 수 있다는 점을 고려하고, 이를 위한 위험 관리 방안을 마련한다.
- 대규모 저장소 시스템들, 예를 들어 HDFS나 아마존 S3는 디스크를 완전히 신뢰하지 않으며, 데이터 손상 위험을 줄이기 위해 지속적으로 파일을 읽어 다른 복제본과 비교하고 이동시킴.
- 데이터가 아직 존재하는지 확인하기 위해서는 실제로 파일을 읽어 확인해야 하며, 백업이 제대로 작동하는지 확인하기 위해 때때로 백업을 복구해보는 것이 중요함.
- 모든 것이 잘 동작한다고 맹목적으로 믿지 않아야 함.
검증하는 문화
- HDFS와 S3와 같은 시스템은 대부분의 시간 동안 디스크가 정확하게 작동한다는 가정을 함.
- 그러나 이 가정은 항상 정확하게 작동한다는 가정과는 다르며, 많은 시스템이 "믿어라, 하지만 확인하라"는 접근법을 쓰지 않음.
- 대부분은 정확성 보장이 절대적이라고 가정하며, 데이터 손상 가능성에 대비하지 않음.
- 미래에는 자가 검증(self-validation) 또는 자가 감사(self-auditing) 시스템을 더 많이 볼 수 있기를 바라며, 이는 스스로 무결성을 지속적으로 확인하는 시스템임.
- ACID 데이터베이스의 문화는 트랜잭션 메커니즘에 기초해 애플리케이션을 개발하며, 감사 기능을 가볍게 보는 경향이 있음.
- 이는 기술이 오랜 시간 동안 잘 작동하고 신뢰를 받아 왔기 때문에 감사 메커니즘에 투자할 가치가 없다고 생각했기 때문임.
- 데이터베이스 지형이 변했으며, NoSQL의 등장과 함께 완화된 일관성 보장이 표준이 되었음.
- 덜 성숙한 저장소 기술이 널리 사용되기 시작했으나, 아직 감사 메커니즘을 개발하지 않았음.
- 이러한 상황에서는 감사 기능 설계에 대한 고려가 필요함.
감사 기능 설계
- 트랜잭션이 데이터베이스 내의 여러 객체를 변경할 때, 이 트랜잭션이 무엇을 의미하는지 파악하기는 어려움.
- 트랜잭션 로그를 캡처하더라도, 다양한 테이블에서 발생한 삽입, 갱신, 삭제만으로는 왜 이런 변경이 이루어졌는지 명확하게 알 수 없음.
- 이 변경을 결정한 애플리케이션 호출은 일시적이므로 재현할 수 없음.
- 반면에, 이벤트 기반 시스템은 더 나은 감사 기능을 제공함.
- 이벤트 소싱 접근법에서 시스템의 사용자 입력은 단일 불변 이벤트로 표현되며, 모든 상태 갱신 결과는 이벤트에서 파생될 수 있음.
- 이 파생 과정은 결정적이며 반복 가능하므로, 같은 버전의 파생 코드를 통해 같은 이벤트 로그를 실행하면 동일한 상태 갱신 결과를 얻을 수 있음.
- 데이터 플로우를 명시적으로 만들면, 데이터의 유래(provenance)가 더욱 명확해져 무결성 확인이 좀 더 수월해짐.
- 이벤트 로그의 경우 이벤트 저장소가 손상되었는지 확인하기 위해 해시를 사용할 수 있음.
- 모든 파생 상태는, 같은 결과가 나오는지 확인하기 위해 일괄 처리와 스트림 처리를 재실행해서 이벤트 로그에서 파생할 수 있으며, 심지어 병렬로 중복 파생 과정을 실행할 수도 있음.
- 결정적이고 잘 정의된 데이터 플로우를 사용하면, 디버깅과 시스템이 왜 그렇게 동작했는지 판단하기 위한 추적이 쉬워짐.
- 예상치 못한 상황이 발생한 경우, 해당 상황이 된 정확한 환경을 재현하는 분석 능력을 갖는 것이 중요함.
- 이는 일종의 시간 여행 디버깅 능력이라고 할 수 있음.
다시 종단 간 논증
- 시스템의 모든 개별 구성 요소가 절대로 손상되지 않는다고 완전히 믿기 어렵다면, 최소한 데이터의 무결성만이라도 주기적으로 확인해야 함.
- 이를 하지 않으면, 손상이 너무 오래 지속되어 다운스트림에 어떤 피해를 야기할 때까지 손상을 발견하지 못할 수 있음.
- 이런 상황에서는 문제를 추적하기가 너무 어렵고 비용도 훨씬 많이 듬.
- 데이터 시스템의 무결성을 확인하는 방법 중, 종단 간 방식이 최선임.
- 무결성 확인이 가능한 시스템이 많을수록 처리 과정의 어떤 단계에서도 손상이 발견되지 않을 가능성이 줄어듬.
- 종단 간 전체 파생 데이터 파이프라인의 정확성을 확인할 수 있다면, 파이프라인을 따르는 디스크와 네트워크 서비스, 그리고 알고리즘들이 이 검증에 암묵적으로 포함됨.
- 종단 간 무결성 확인을 꾸준히 수행하면, 시스템의 정확성에 대한 확신이 높아져 더 빠르게 진행할 수 있게 됨.
- 테스트 자동화와 마찬가지로, 감사 기능은 버그를 빠르게 발견할 가능성을 높여, 시스템이나 새로운 저장 기술에 대한 변경이 손상을 일으킬 위험을 줄임.
- 변화를 두려워하지 않는다면, 변하는 요구사항에 대응하기 위해 애플리케이션을 훨씬 잘 개선할 수 있음
감사 데이터 시스템용 도구
- 현재 감사 기능을 최고 수준으로 고려하는 시스템은 많지 않음.
- 애플리케이션 중 일부는 스스로 감사 메커니즘을 구현하기도 하는데, 이는 감사 테이블에 모든 변경 사항을 로그로 남기는 방식임.
- 하지만, 감사 로그와 데이터베이스 상태의 무결성을 보장하는 것은 어려움.
- 트랜잭션 로그는 하드웨어 보안 모듈을 사용해 주기적으로 서명하게 만들 수 있지만, 이 방식이 올바른 트랜잭션이 로그에 들어갔는지를 보장하지는 않음.
- 암호화 도구를 사용하여 시스템의 무결성을 증명하려는 시도는 흥미로움.
- 이는 하드웨어, 소프트웨어 문제와 악의적인 행동에도 견딜 수 있는 방식으로 암호화 도구를 활용함.
- 비트코인, 이더리움, 리플, 스텔라 등 다양한 암호화폐, 블록체인, 분산 원장 기술이 이 분야를 탐구하고 있음.
- 이 기술들은 본질적으로 데이터 모델과 트랜잭션 메커니즘을 사용하는 분산 데이터베이스로, 서로 신뢰하기 어려운 조직에서 다른 복제본을 호스팅할 수 있음.
- 이 복제본들은 지속적으로 각각 다른 복제본의 무결성을 확인하고, 실행해야 할 트랜잭션에 동의하는 합의 프로토콜을 사용함.
- 암호화 감사 기능과 무결성 확인은 종종 머클 트리에 의존함.
- 머클 트리는 해시 트리로, 특정 데이터셋 및 다른 몇 가지 내에 나타나는 레코드를 효율적으로 증명하는 데 사용됨.
- 암호화폐의 과대 광고 외에도, 인증서 투명성은 머클 트리를 사용하여 TLS/SSL 인증 유효성을 확인하는 보안 기술임.
- 무결성 확인과 감사 알고리즘이 인증서 투명성과 분산 원장 알고리즘처럼 데이터 시스템에서 일반적으로 널리 사용될 것이라는 상상을 함.
- 성능 불이익이 낮고 암호화 감사 기능이 없는 시스템과 동등한 수준으로 확장 가능하려면 추가 작업이 필요할 것임.
- 이러한 작업은 앞으로 흥미로운 연구 영역이 될 것으로 보임.
옳은 일 하기
- 책 전반에 걸쳐 데이터 시스템의 다양한 아키텍처와 각각의 장단점을 살펴봤음.
- 또한 신뢰할 수 있고, 확장 가능하며 유지보수하기 쉬운 애플리케이션을 구축하는 기술에 대해 설명했음.
- 그러나 아직 중요하고 근본적인 부분이 남았음.
- 모든 시스템은 목적을 가지고 구축됨.
- 의도한 결과와 의도하지 않은 결과가 모두 있을 수 있으며, 그 결과는 때때로 원래의 목적을 초월할 수 있음.
- 시스템을 구축하는 엔지니어는 이런 결과를 신중하게 고려해야 함.
- 많은 데이터셋은 인간과 관련된 것이며, 이런 데이터는 인간애와 존경심을 가지고 다뤄야 함.
- 사용자도 인간이며, 인간의 존엄성은 매우 중요함.
- 소프트웨어 개발에 윤리적 선택이 중요해지고 있음.
- ACM의 소프트웨어 공학 윤리 강령과 같은 지침이 있지만, 실제로는 거의 논의되지도, 적용되지도, 강제되지도 않았음.
- 때로는 제품에서 발생할 수 있는 사생활이나 잠재적인 부정적 문제에 대해 무시하는 경우도 있음.
- 기술 자체는 좋거나 나쁜 것이 아님.
- 중요한 것은 기술을 어떻게 사용하고 기술이 사람들에게 어떤 영향을 주는지임.
- 이는 소프트웨어 시스템이 무기와 비슷하게 작동할 수 있다는 점에서 중요함.
- 소프트웨어 엔지니어는 기술의 영향을 무시하지 않고 윤리적 책임을 져야 함.
- 윤리에 대한 논의는 어렵지만 중요해서 무시할 수 없음.
예측 분석
- "빅데이터" 판촉에 중요한 부분인 예측 분석은 날씨 예측이나 질병 확산 예측 분석에서 데이터를 사용함.
- 하지만 채무자의 채무 불이행 가능성 또는 보험 고객의 고액 청구 여부를 예측하는 것은 개인의 삶에 직접적인 영향을 줌.
- 지불 네트워크가 사기 거래를 방지하고, 은행이 불량 채권을 피하고, 항공사가 공중 납치를 피하며, 회사가 비효율적인 사람을 고용하는 것을 꺼리는 것은 자연스러운 일임.
- 조직은 놓친 사업적 기회 비용은 작지만, 불량 채권이나 골칫거리 종업원 때문에 발생하는 비용은 크기 때문에 이러한 문제에 신중하게 접근함.
- 그러나 알고리즘에 의한 의사 결정이 보편화됨에 따라, 특정 알고리즘에 의해 위험하다고 판정된 사람은 많은 "아니오" 결정으로 고통받게 됨.
- 이로 인해 사람들은 직업, 항공 여행, 보험 보장 범위, 부동산 임대, 금융 서비스 등 사회의 주요 부분에서 배제되며, 이를 "알고리즘 감옥"이라 부름.
- 인권을 존중하는 나라에서는 범죄 판결 시스템이 유죄로 증명될 때까지는 무죄로 가정함.
- 반면, 자동화 시스템은 시스템적이거나 임의로 유죄 증명 없이 그리고 변론할 기회도 거의 없이 사람을 사회 참여에서 배제시킬 수 있음.
편견과 차별
- 알고리즘이 내린 결정이 사람이 내린 결정보다 반드시 좋거나 나쁜 것은 아님.
- 사람은 편견을 가지기 쉽고, 차별 관행은 문화적으로 제도화될 수 있음.
- 하지만 데이터를 기반으로 하는 결정이 전통적인 시스템에서 간과되기 쉬운 사람들에게 더 나은 기회를 제공할 수 있다는 희망이 있음.
- 예측 분석 시스템을 개발할 때는 인간의 결정을 자동화하는 규칙을 규정하는 소프트웨어를 사용하며, 이 규칙 자체가 데이터로부터 추론되게 놔두기도 함.
- 하지만 시스템으로 학습한 패턴은 투명하지 않고, 데이터에서 상관 관계가 나왔어도 왜 그런지를 알지 못할 수 있음.
- 알고리즘에 투입된 입력에 시스템적 편견이 있다면 시스템은 그 편견을 학습하고 증폭해서 출력을 내보낼 가능성이 높음.
- 많은 나라에서는 차별 금지법으로 사람을 인종, 나이, 성별, 성 정체성, 장애, 신앙 등의 특징으로 다르게 대우하는 것을 금지함.
- 이러한 개인의 여러 특징을 분석할 수 있지만, 이 특징이 민감한 특성과 상관관계가 있다면 문제가 될 수 있음.
- 예를 들어, 인종적으로 분리된 지역에서는 우편번호나 IP 주소는 강력한 인종 예측자가 될 수 있음.
- 특정 알고리즘이 입력으로 치우친 데이터를 받아 공평하고 치우침 없는 출력을 내기를 바라는 것은 터무니없음.
- 예측 분석 시스템은 오직 과거로부터 추정함.
- 과거가 차별적이라면 예측 분석 시스템은 차별을 성문화함.
- 과거보다 나은 미래를 원한다면 도덕적 상상력이 필요하며, 이는 단지 인간만이 제공할 수 있음.
- 데이터와 모델은 도구여야지 주인이 돼서는 안 됨.
책임과 의무
- 의사결정 자동화는 책임과 의무 문제를 아직 해결하지 못했음.
- 알고리즘이 실수하면 책임을 누가 져야하는지 확실하지 않음.
- 신용점수는 개인의 실제 차용 내역에 근거하여 생성되지만, 머신러닝 기반 점수 알고리즘은 더 넓은 입력 범위를 사용하고 과정이 불투명해, 그 결정의 이유를 이해하기 어려움.
- 예측 분석 시스템은 "누가 당신과 비슷한지"와 "당신과 비슷한 사람들이 과거에 어떤 행동을 했는지"에 기반하여 작동함.
- 이는 사람들을 고정된 관념에 맞추고, 잘못된 데이터로 인한 오류는 거의 구제가 불가능함.
- 풍부한 데이터는 본질적으로 통계적임.
- 개별 사례가 전체적인 확률 분포와 일치하지 않을 수 있음.
- 데이터 주도 의사결정의 맹목적인 믿음은 망상이며, 위험함.
- 알고리즘의 설명 가능성과 투명성을 확보해야하며, 편향 강화를 방지하고 실수를 수정하는 방법을 찾아야함.
- 데이터는 사람들을 해치지 않아야 하며, 긍정적 잠재력을 실현하는 방법을 찾아야 함.
- 이는 가장 필요한 사람들을 돕는 데 집중하거나, 악질적인 사업체가 취약층을 골라내고 위험한 상품을 팔기 위해 사용되는 것을 방지하는 데 사용될 수 있음.
피드백 루프
- 추천 시스템과 같은 예측 애플리케이션은 에코 챔버 현상을 일으킬 위험이 있음.
- 이는 서비스가 사람들이 선호하는 콘텐츠만을 보여주게 되어, 사용자의 고정관념을 강화하고 양극화를 촉진할 수 있음.
- 예측 분석이 사람들의 삶에 영향을 미치면서, 자기 강화 피드백 루프 문제가 발생할 수 있음.
- 예를 들어, 신용 점수가 낮아지면 일자리 찾기가 어려워지고, 이로 인해 신용 점수가 더욱 떨어지는 악순환이 발생할 수 있음.
- 피드백 루프가 언제 발생할지는 항상 예측 가능한 것이 아님.
- 하지만 전체 시스템(컴퓨터화된 부분과 시스템과 상호작용하는 사람들)을 고려하면 많은 결과를 예측할 수 있음.
- 이것을 시스템 사고라고 함.
- 데이터 분석 시스템이 어떻게 다른 행동과 구조, 특성에 반응하는지 이해하는 노력이 필요함.
- 이 시스템이 사람들 간의 차이를 강화하고 증폭시키는지, 아니면 불의에 맞서는지를 생각해볼 필요가 있음.
- 최선의 의도였더라도 의도하지 않은 결과를 반드시 주의해야 함.
- 이는 피드백 루프의 부정적인 영향을 최소화하는데 중요함.
댓글