[SW Engineering] 10. 의존성 시스템(Dependable System)

[SW Engineering] 10. 의존성 시스템(Dependable System)Software 개발/SW Engineering2025. 12. 17. 20:46@BE_개발자

Table of Contents

728x90

우리가 매일 사용하는 뱅킹 시스템, 항공 관제 소프트웨어, 의료 기기 등은 단 한 번의 오류로도 막대한 경제적 손실이나 인명 피해를 초래할 수 있습니다. 이러한 시스템에서 가장 중요한 속성은 바로 의존성(Dependability)입니다.

이번 포스팅에서는 시스템 의존성의 핵심 요소와 이를 달성하기 위한 전략인 중복성, 다양성, 그리고 프로세스적 접근법에 대해 정리해 봅니다.

1. 시스템 의존성 (System Dependability)의 이해

의존성(Dependability)은 사용자가 시스템을 얼마나 신뢰(Trust)할 수 있는지를 나타내는 척도입니다. 단순히 기능이 작동하는 것을 넘어, 시스템이 '실패'하지 않을 것이라는 확신을 주는 것이 핵심입니다.

1) 의존성의 5대 핵심 속성

의존성은 다음의 5가지 상호 의존적인 속성들로 구성됩니다.

가용성 (Availability): 사용자가 서비스를 요청했을 때 시스템이 즉시 응답할 수 있는 능력입니다.
신뢰성 (Reliability): 지정된 시간 동안 명세서에 기술된 대로 오류 없이 서비스를 제공하는 능력입니다.
안전성 (Safety): 시스템 실패가 인명 피해나 환경 파괴 같은 치명적인 결과(Catastrophic failure)를 초래하지 않도록 하는 능력입니다.
보안성 (Security): 외부의 악의적인 공격으로부터 시스템과 데이터를 보호하는 능력입니다. 보안 실패는 가용성과 신뢰성 저하로 직결됩니다.
회복력 (Resilience): 예기치 못한 장애가 발생해도 서비스 중단을 최소화하고 빠르게 정상 상태로 회복하는 능력입니다.

"의존성 시스템 설계가 어려운 이유는 이 5가지 속성이 서로 트레이드오프(Trade-off) 관계에 있거나 긴밀하게 연결되어 있기 때문입니다. 특히 현대 소프트웨어에서 보안(Security)은 신뢰성, 가용성, 안전성 모두를 무너뜨릴 수 있는 가장 치명적인 시작점이 되곤 합니다."

사회에서 흔히 일어나는 몇가지 예시를 살펴볼까요?

시나리오 1: 보안성이 신뢰성에 영향을 미치는 경우

보안성이 무너지면 시스템이 '명세서대로 정확하게' 작동할 수 없으므로 신뢰성까지 함께 무너지게 됩니다.

상황: 온라인 뱅킹 시스템의 데이터베이스가 해킹당해 잔액 정보가 위조되었습니다.
보안성 실패: 해커가 권한 없이 시스템에 침투하여 데이터를 조작했습니다.
신뢰성으로의 전이: 은행 전산망(하드웨어)은 멀쩡히 돌아가고 있지만, 사용자가 잔액 조회를 했을 때 실제와 다른 '잘못된 정보'를 보여주게 됩니다.
결과: 시스템이 명세대로(정확한 잔액 표시) 서비스를 제공하지 못하게 되었으므로, 사용자는 더 이상 이 시스템을 신뢰(Reliability)할 수 없게 됩니다.

시나리오 2: 가용성이 신뢰성에 영향을 미치는 경우

가용성 실패가 신뢰성 저하로 이어질 수 있으며 때로는 신뢰성을 위해 일부러 가용성을 낮추기도 합니다.

① 가용성 실패가 신뢰성 저하로 이어지는 경우

가용성이 낮아지면(자주 끊기면), 시스템이 명세대로 작동하더라도 사용자는 그 결과를 믿지 못하게 됩니다.

예시: 실시간 주식 거래 시스템
상황: 시스템이 과부하로 인해 1분간 멈췄습니다(가용성 상실). 그 사이 주가는 급변했습니다.
영향: 다시 시스템이 복구되어 현재 주가를 정확히 표시하더라도(신뢰성 회복), 사용자는 "아까 멈췄을 때 내가 판 주문이 제대로 체결됐을까?" 혹은 "지금 데이터가 정말 실시간이 맞나?"라고 의심하게 됩니다.
결론: 잦은 가동 중단(Low Availability)은 시스템이 제공하는 정보의 정확도(Reliability)에 대한 사용자의 신뢰를 근본적으로 훼손합니다.

② 신뢰성 확보를 위해 가용성을 의도적으로 낮추는 경우

때로는 '잘못된 서비스'를 제공하느니 차라리 '서비스를 중단'하는 것이 전체적인 의존성을 높이는 길일 수 있습니다.

예시: 은행 점검 시간 (Batch Processing)
상황: 은행이 데이터의 무결성과 정확성(신뢰성)을 100% 보장하기 위해, 매일 새벽 대규모 데이터 동기화 작업을 수행합니다.
영향: 이 작업 동안은 인터넷 뱅킹 접속이 차단됩니다(가용성 저하).
결론: 시스템이 오류 없이 완벽하게 작동한다는 확신(High Reliability)을 주기 위해, 특정 시간 동안 서비스 응답 능력(Availability)을 포기하는 전략적 선택입니다.

2) 보조 속성 (Secondary Properties)

수리 용이성 (Repairability): 장애 발생 시 얼마나 빠르고 쉽게 복구할 수 있는가.
유지보수성 (Maintainability): 새로운 비즈니스 요구사항에 맞춰 시스템을 얼마나 쉽게 수정할 수 있는가.
오류 허용성 (Error Tolerance): 사용자의 실수나 잘못된 입력에도 시스템이 견디고 올바르게 반응하는가.

3) 의존성 확보와 비용의 관계

시스템의 의존성 수준을 높일수록 이를 구현하기 위한 비용은 기하급수적(Exponentially)으로 증가합니다. 따라서 무조건적인 완벽함보다는 서비스의 목적과 경제적 타당성을 고려한 적정 의존성 수준을 설정하는 것이 중요합니다.

2. 사회-기술적 시스템 (Sociotechnical Systems)

현대의 소프트웨어는 독립적으로 존재하지 않습니다. 하드웨어, 인간, 조직, 사회라는 거대한 계층 구조의 일부로 작동합니다. 이를 사회-기술적 시스템이라고 부릅니다.

시스템 계층 구조 (System Layers)

오류는 한 계층에서 발생하여 다른 계층으로 전파(Propagation)될 수 있으므로 전체론적 관점이 필요합니다.

사회 (Society): 법률, 규제 체계, 사회적 문화
조직 (Organization): 비즈니스 전략, 기업 정책
비즈니스 프로세스 (Business Processes): 업무 수행 절차
애플리케이션 시스템 (Application System): 실제 소프트웨어 로직
통신 및 데이터 (Communications and Data): 미들웨어, 네트워크 기술
운영체제 및 장비 (OS & Equipment): 커널, 서버 하드웨어

특히 항공이나 원자력 같은 중요 시스템(Critical Systems)은 국가 기관의 승인(Certification)이 필수이며, 이를 위해 규정 준수를 증명하는 방대한 문서(Safety Case) 작성이 수반됩니다. 또한 소프트웨어 공학에서 시스템을 설계할 때는 코드 그 자체만 보는 것이 아니라, 그 소프트웨어가 속한 사회적 맥락과 조직의 요구사항이 기술에 어떤 영향을 미치는지를 아우르는 '전체론적 관점'이 반드시 필요합니다.

조금 더 현실적인 예시를 통해 살펴볼까요? 다음 두 가지 시나리오는 각각 하위 계층의 문제가 상위 계층으로 전파되는 예시와 그 반대의 예시입니다.

시나리오 1: 쿠팡 해킹과 시스템 계층 간 영향

최근 SKT 정보유출을 화두로 지속적으로 고객 정보 해킹 피해가 증가하고 있습니다. 최근의 쿠팡의 개인정보 유출 이슈를 바탕으로 사회-기술적 시스템(Sociotechnical Systems)의 계층 구조 관점에서 살펴보면 기술적 오류가 어떻게 조직과 사회 전체로 전파되는지 명확히 이해할 수 있습니다.

① 운영체제 및 장비 / 통신 및 데이터 계층 (하위 기술 계층)

영향: 서버의 과부하나 네트워크 설정 오류, 혹은 데이터베이스(DB) 서버의 일시적인 동기화 오류가 발생할 수 있습니다.
상황: 특정 업데이트 직후 서버 패킷 처리 과정에서 데이터 매칭이 어긋나는 기술적 결함이 발생하며 유출의 시발점이 됩니다.

② 애플리케이션 시스템 계층 (소프트웨어 로직)

영향: 실제 '내 정보 보기'나 '주문 내역' 화면에서 본인의 ID가 아닌 다른 사용자의 데이터를 불러오는 로직 결함이 발생합니다.
상황: 보안성(Security)의 핵심인 권한 검증 로직이 실패하면서, 시스템의 **신뢰성(Reliability)**이 무너지고 실제 개인정보가 화면에 노출됩니다.

③ 비즈니스 프로세스 계층 (업무 절차)

영향: 오류 발생 시 즉각적인 서비스 중단이나 모니터링 절차가 미흡할 경우 피해가 확산됩니다.
상황: 배포 전 검증(V&V) 절차에서 해당 오류를 잡아내지 못했거나, 유출 신고 접수 후 시스템 차단까지의 대응 프로세스가 지연되면서 더 많은 사용자가 피해를 입게 됩니다.

④ 조직 계층 (비즈니스 전략 및 정책)

영향: 보안보다 빠른 배포와 성과를 우선시하는 조직 문화나, 개인정보 보호 정책의 부재가 근본적인 원인이 됩니다.
상황: 쿠팡이라는 기업의 대외 이미지와 브랜드 가치가 하락하며, 고객들의 탈퇴(Coupang Exit)로 이어져 경영 전략에 차질을 빚게 됩니다.

⑤ 사회 계층 (법률, 규제 및 문화)

영향: 유출 사고는 단순히 한 기업의 문제를 넘어 국가적 규제와 법적 책임으로 확장됩니다.
상황: 개인정보보호위원회 등 규제 기관의 조사와 막대한 과징금 부과가 이루어집니다. 또한, 사회적으로 "대형 플랫폼도 믿을 수 없다"는 불신이 확산되어 개인정보 보호에 대한 법적 규제가 강화되는 계기가 됩니다.

따라서 이 사건은 애플리케이션 계층의 작은 소프트웨어 버그(전파의 시작)가 비즈니스 프로세스의 대응 미흡을 타고 흘러가, 결국 조직의 경제적 손실과 사회적 규제 강화라는 최상위 계층까지 영향을 미친 전형적인 사회-기술적 시스템의 실패 사례라고 볼 수 있습니다.

때로는 반대로 세상의 변화와 사회적 요구가 거꾸로 기술의 형태를 결정하기도 합니다. 다음 사례를 통해 어떻게 사회 문제가 어떻게 앱 화면의 인터페이스와 로직까지 바꾸게 되는지 살펴봅시다.

시나리오 2: 공유 킥보드의 '무단 주차' 문제

① Society 계층: 문제의 발생 사용자들이 킥보드를 보도 한가운데나 상점 입구에 방치하면서 보행자의 통행을 방해합니다. 이는 곧 대중의 분노와 민원으로 이어지며, "공유 킥보드는 사회적 흉물"이라는 강력한 부정적 여론이 형성됩니다.

② Society → Organization: 규제 압박과 경영 위기 부정적 여론이 거세지면 지자체는 견인 조치나 과태료 부과 등 강력한 규제를 도입합니다. 운영사(조직)는 이미지 실추와 견인 비용 증가라는 타격을 입게 되며, 생존을 위해 "자유로운 반납" 대신 "지정 구역 반납"으로 경영 정책을 긴급히 수정하게 됩니다.

③ Organization → Business Process: 운영 프로세스의 대전환 경영진의 정책 변화에 따라 내부 운영 방식이 바뀝니다. 단순히 킥보드를 배치하는 것을 넘어, "사용자가 지정된 장소에 주차했는가"를 확인하고 검증하는 새로운 업무 절차가 비즈니스 프로세스에 추가됩니다.

④ Business Process → Application System: 기술적 구현 (최종 단계) 변경된 비즈니스 프로세스를 실현하기 위해, 개발팀은 애플리케이션 시스템의 코드를 수정합니다.

인터페이스 변경: 앱 지도 위에 주차 가능 구역(P)과 금지 구역(Red Zone)을 시각적으로 표시합니다.
시스템 로직 수정: GPS 값을 실시간으로 대조하여, 주차 구역 내에 있을 때만 '반납 완료' 버튼이 활성화되도록 로직을 변경(Geofencing)합니다.
기능 추가: 주차 상태를 증명하기 위해 반납 시 반드시 사진을 촬영하여 업로드하도록 카메라 기능을 추가합니다.

따라서 공유 킥보드의 주차 인증 사진 기능이나 주차 구역 안내 지도는 개발자가 어느 날 갑자기 아이디어를 내서 만든 것이 아닙니다. 사회 계층의 갈등(무단 주차) → 조직의 대응(정책 변화) → 프로세스의 수정 → 기술적 구현이라는 흐름을 거쳐 탄생한 결과물입니다.

거리의 무단 주차라는 사회적 문제는 기업의 정책을 바꾸고, 비즈니스 절차를 수정하게 만들며, 최종적으로는 앱의 기술적 기능까지 변화시키는 강력한 전파 효과를 가집니다. 이것이 바로 우리가 소프트웨어를 '사회-기술적 시스템'으로 이해해야 하는 이유입니다.

3. 중복성과 다양성 (Redundancy and Diversity)

시스템의 가용성을 높이고 단일 실패 지점(Single Point of Failure)을 제거하기 위한 가장 강력한 기술적 전략입니다.

1) 중복성 (Redundancy)

정의: 핵심 컴포넌트를 예비(Backup)용으로 하나 이상 더 배치하는 방식입니다.
작동 원리: 메인 시스템에 문제가 생기면 즉시 예비 시스템이 가동되어 서비스 연속성을 보장합니다.
사례: 서버 이중화, 데이터 백업 서버 구축 등.

2) 다양성 (Diversity)

정의: 동일한 기능을 수행하되, 서로 다른 설계나 기술을 사용하여 구현하는 방식입니다.
작동 원리: 공통 모드 실패(Common-mode failure)를 방지합니다. 예를 들어, 모든 서버가 동일한 OS를 사용한다면 특정 OS 취약점에 의해 동시에 마비될 수 있지만, 서로 다른 OS를 사용하면 하나의 공격으로 전체 시스템이 무너지는 것을 막을 수 있습니다.
사례: 서로 다른 제조사의 센서 사용, 다른 프로그래밍 언어로 개발된 다중 버전 소프트웨어.

이중화와 다양성에 대해 최근에 이슈가 된 국가 전산망 화재의 예시를 통해 살펴볼까요?

시나리오: 국가 전산망 화재를 통해 들여다 본 중복성과 다양성

중복성는 시스템의 가용성(Availability)을 높이기 위해 핵심 컴포넌트의 여분(Backup)을 마련하는 전략입니다.

화재 상황 예시: 서울에 있는 데이터센터에 우리 회사의 메인 서버가 있습니다.
- 이중화 적용: 부산에 있는 데이터센터에 서울과 똑같은 사양의 복제 서버를 한 대 더 설치합니다.
- 결과: 서울 데이터센터에 화재가 발생해 서버가 타버리더라도, 부산에 있는 예비 서버가 즉시 가동되어 서비스가 중단되지 않고 계속 유지됩니다.

다양화는 공통 모드 실패(Common-mode failure)를 방지하기 위한 전략입니다. 똑같은 장비만 여러 개 두면, 특정 사고 시 모든 장비가 동시에 고장 날 수 있기 때문입니다.

화재 상황 예시:
- 데이터센터의 전원 공급 장치를 이중화했지만, 모두 **'A 전력사'**의 라인만 사용하고 있습니다.
- 문제 발생: 전력사 A의 변전소에 불이 나면, 이중화된 두 라인이 동시에 끊겨 서버가 모두 꺼집니다.
- 다양화 적용:
  1. 하나는 'A 전력사', 다른 하나는 **'B 전력사'**로부터 전기를 공급받습니다. (전력망의 다양화)
  2. 서버의 운영체제(OS)도 하나는 Windows, 하나는 Linux를 사용합니다. (소프트웨어의 다양화)
- 결과: 특정 전력망에 문제가 생기거나 특정 OS의 보안 취약점을 노린 공격이 들어와도, 다른 방식의 시스템은 영향을 받지 않고 살아남습니다.

4. 의존성 보장을 위한 개발 프로세스

고도의 의존성이 요구되는 시스템을 개발할 때는 일반적인 소프트웨어 개발보다 훨씬 엄격한 프로세스가 적용됩니다.

1) 프로세스 특징

명시적 정의 (Explicitly Defined): 모든 활동이 문서화되어 있고 표준화되어 있어야 합니다.
반복 가능성 (Repeatable): 특정 개발자의 역량에 의존하지 않고, 정해진 절차를 따르면 일관된 품질이 보장되어야 합니다.

2) 주요 활동

정형 명세 (Formal Specification): 수학적 모델링을 통해 요구사항의 논리적 모순을 사전에 제거합니다.
정적 분석 (Static Analysis): 코드를 실행하지 않고 자동화 도구를 통해 잠재적인 런타임 에러나 취약점을 탐지합니다.
프로그램 인스펙션 (Inspection): 동료 검토(Peer review)를 통해 설계와 코드의 결함을 다각도에서 검증합니다.

3) 애자일(Agile) 방식과의 관계

의존성 시스템은 규제 승인을 위해 방대한 문서화와 철저한 사전 분석(Up-front Analysis)이 필수입니다. 이는 빠른 변화와 코드 중심의 애자일 철학과는 다소 상충되는 면이 있습니다. 따라서 안전 최우선 시스템에서는 순수 애자일보다는 엄격한 문서 관리가 결합된 하이브리드 프로세스를 주로 사용합니다.

마치며

의존성은 단순히 '버그 없는 코드'를 의미하지 않습니다. 시스템이 사회적, 조직적 맥락 안에서 실패 없이 가치를 제공하도록 설계하는 거시적인 설계 철학입니다. 보안이 신뢰성에 영향을 주고, 중복성이 가용성을 뒷받침하는 이러한 상호 관계를 이해하는 것이 안정적인 시스템 구축의 첫걸음입니다.