ch4. 설계 접근 (Design Approaches)

개요

시설 설계에서 보안과 신뢰성 요구사항의 기능과 비용 요구사항 적용의 어려움.
설계 프로세스 연구를 통한 아이디어에서 제품 형태로의 구체화 과정과 애플리케이션 개발 속도 유지 방안.

 

 

4.1 설계 목표와 요구사항

기본 개념

• 제품의 기능 요구사항과 보안·신뢰성 요구사항의 상당한 차이점
• 설계 시 마주하는 다양한 요구사항 유형

 

4.1.1 기능 요구사항

정의: 서비스나 애플리케이션의 주요 기능 정의 및 사용자 작업 수행 방법 기술

주요 유형

유형	내용	참조
사용 사례(Use Case) 사용자 스토르(User Story) 사용자 여정(User Journery)	사용자와 서비스 또는 애플리케이션 간 일련의 상호작용 정의	https://oreil.ly/vFvEU
중요 요구사항(Critical Requirement)	기능 요구사항의 하위 집합, 제품/서비스의 기본 요소	-

설계 의사결정의 핵심

• 기능 요구사항의 우선순위
• 사용자 특정 수요 만족을 위한 시스템과 서비스 구현

예시

애플리케이션 웹 UI의 모든 뷰/페이지는 반드시,

• 공통 시간 설계 가이드라인을 따라야 한다.
• 접근성 가이드라인을 준수해야 한다.
• 개인정보 보호정책 및 서비스 이용약관(ToS)에 링크를 가진 바닥글이 있어야 한다.

 

4.1.2 비기능성 요구사항

비기능성 요구사항(Nonfunctional Requirement)은 보안·신뢰성의 밀접한 관련성이 있음.

비기능성 요구사항: 시스템의 특정 동작이 아닌 보편적 특성이나 동작

예시

 

개발 효율성과 속도 : 개발언어, 프레임워크, 테스트 프로세스, 빌드 프로세스를 선택했을때 개발자들은 얼마나 효율적으로 새로운 기능을 구현해내는가?

배포 속도 : 기능 개발 완료 후 실제 사용자 이용까지 어느정도의 시간이 필요한가?

 

 

4.1.3 기능과 이머전트 속성의 비교

기능 요구사항의 특징

• 요구사항, 코드, 테스트 간의 명확한 연결 관계

구현 단계

명세

• 사용자 스토리나 요구사항을 통한 사용자 프로필 데이터 조회/수정 방법 정의

구현

• 프로필 데이터 표현 구조화 타입
• 프로필 데이터 표시/수정 UI 코드
• 데이터 스토어 조회/수정 서버측 RPC 또는 HTTP 액션 핸들러

검증

• 사용자 스토리 단계별 실행 통합 테스트
• UI 테스트 드라이버를 통한 '프로필 수정' 기능 검증
• 데이터베이스 레코드 기록 확인

비기능성 요구사항의 어려움

(신뢰성과 보안 요구사항 같은) 비기능성 요구사항의 명확한 정의의 어려움

 

이머전트 속성 : 평소에는 나타나지 않다가 어떤 특정 상황이 되면 나타나는 특징

https://yeongki0944.tistory.com/179

AWS ELB(ALB) Server 헤더 보안 취약점 조치 방법

 

 

 

4.1.4 예시: 구글 설계 문서

목적: 새로운 기능 설계 안내 및 엔지니어링 프로젝트 시작 전 이해관계자 의견 수집

구글 설계 문서 템플릿의 신뢰성·보안 관련 항목

 

 

4.2 요구사항의 균형잡기

기본 개념

• 보안과 신뢰성 요구사항을 만족하는 시스템 특성: 이머전트 속성
• 기능 요구사항 구현과 다른 이머전트 속성의 연관성

 

기존 시스템의 신뢰성·보안 추가 시 비용

이머전트 속성의 특징

보안과 신뢰성이 이머전트 속성이라는 점에서 관련 고려사항과 선택이 상당히 근본적이고 구조적. 데이터베이스 선택(관계형 vs NoSQL), 아키텍처 선택(모놀로식 vs 마이크로서비스) 등 기본 아키텍처 선택과 유사한 수준.

 

기존 시스템 적용 시 발생 비용:

• 상당한 설계 변경
• 증대된 리팩터링
• 부분적 재구현
• 높은 비용과 긴 소요 시간

 

4.2.1 예시: 결제 처리

시나리오: 온라인 위험 판매 서비스 구축
요구사항: 사용자의 모바일/웹 애플리케이션을 통한 온라인 가맹점 이용

보안과 신뢰성 고려사항

민감한 데이터 처리

• 이름, 주소, 신용카드 번호 등 민감한 개인 데이터의 특별한 보호 조치
• 관리 법령에 따른 시스템 규제 대상
• PCI DSS(https://www.pcisecuritystandards.org) 등 규제적 보안 표준 준수

사용자 식별 정보(PII) 유출 시 결과

• 프로젝트 및 조직/회사에 심각한 결과 초래

서드파티 서비스 프로바이더로 민감한 데이터 처리하기

민감한 데이터 처리 우려 해결 방안: 처음부터 민감 데이터 수용 회피

상용 결제 서비스 API 통합 효과:

• 결제 정보 처리 책임 전가
  
  • 민감한 데이터를 저장할 필요가 없음 > 자사 시스템의 취약점으로 데이터 유출시 책임전가 가능
• 결제 트랜잭션 관련 우려사항(사기 대처 등) 서비스 벤더(vendor)가 책임

 

비용과 비기술적 위험

• 특정 규모 이상으로 트랜잭션이 많이질 경우, 직접 트랜잭션을 처리하는 것이 비용적으로 유리
• 서드파티 밴더의  API 사용법 학습 필요

 

신뢰성 위험

• 서드파티 서비스 제공자가 SLA를 얼마나 준수하는가?
• 서비스 장애를 고려하여 이중화 도입도 고려가능
• 버퍼링 큐 메커니즘(kafka, MQ 등)  > 큐 시스템에 대한 장애도 고려해야 됨
  • 인메모리스토리지(MQ), 영구 디스크 스토리지(kafka)
  • 영구 디스크 스토리지 > 민감데이터를 저장해도 되는지?

 

보안 위험

• 밴더에 대한 평가
• 밴더가 제공하는 라이브러리와 애플리케이션의 취약점이 존재하는지
  • REST, XML, SOAP, gRPC 등의 프로토콜을 사용시 라이브러리가 필요없게됨 > 취약점이 없음

 

4.3 갈등의 관리와 목표의 조정

사전계획을 세우면 기능을 포기하지 않고도 적절한 비용으로 보안과 신뢰성 같은 중요한 비기능성 요구사항을 만족시킬 수 있음.

 

4.3.1 예시: 마이크로서비스와 구글 웹 애플리케이션 프레임워크

구글 내부 프레임워크의 목표: 대규모 조직에서 애플리케이션 및 서비스의 개발과 운영 능률화

부합성 검사(Conformance Check)

정적 및 동적 부합성 검사의 핵심 역할

주요 검증 항목:

• 동시성 실행 콘텍스트 간 전달되는 모든 간이 동시성 비교를 위한 불변 타입(Immutable Type) 검증
• 프레임워크 구현 애플리케이션의 견고성과 구조적 정리
• 새로운 배포의 생성, 지속적 통합(CI) 환경의 자동 생성, 프로덕션 배포의 자동화

결과: 구글 개발자들 사이에서 빠른 인기 확산

 

Google Conformance Check 개발 배경과 목적

Google에서 내부적으로 사용하던 "Conformance" 방법론으로, Google Search, Maps, Photos 등 대규모 웹 애플리케이션 개발 경험을 바탕으로 개발됨. 사용자 경험에 부정적 영향을 미치는 코드 작성을 방지하여 프레임워크가 성능과 애플리케이션 품질 향상에 핵심 역할을 수행하도록 설계됨.

문제 해결 목표: 소수의 깊은 경험을 가진 유지보수자들이 수행하던 광범위한 코드 리뷰(정확성 문제를 넘어 앱 품질과 유지보수성에 영향을 미치는 요소들 식별)를 성장하는 앱 개발팀으로 확장하기 위해 모범 사례를 자동화되고 강제 가능한 방식으로 체계화

핵심 동작 원리

1. 이중 검증 시스템

정적 코드 분석과 동적 체크의 조합으로 작동. 코드 패턴을 평가하는 규칙들이 다양한 표면에 걸쳐 적용됨

2. 다층적 규칙 적용

• 컴파일 시점: Closure Compiler의 JS Conformance Framework에서 특정 속성 접근이나 함수 호출을 금지하는 규칙을 컴파일 중 강제하고 경고/에러로 보고
• 개발 시점: 로컬 개발 환경에서 개발 서버, 브라우저, IDE를 통해 경고를 표시하여 개발자가 작은 코드 변경을 유도
• 런타임: 브라우저 레벨 런타임 시스템을 통한 동적 검증

3. 엄격한 검증 방식

규칙이 엄격하게 강제되며, 타입 정보가 불충분한 경우 "possible violation" 경고를 발생시켜 예상치 못한 곳에서 부족한 타입 정보를 드러내는 부수 효과 제공

비교: SonarQube vs Google Conformance

특징	SonarQube	Google Conformance
목적	코드 품질, 보안, 버그 탐지	프레임워크 아키텍처 패턴 강제
검증 방식	주로 정적 분석	정적 + 동적 검증 결합
적용 범위	범용 코드 품질	특정 프레임워크 생태계
결과	문제점 리포트	예측 가능한 사용자 경험 결과

핵심 가치

Conformance는 모범 사례를 개발자를 위한 간단한 코드 패턴으로 실행 가능한 규칙셋으로 체계화.
Conformance 규칙 준수는 예측 가능한 결과를 가져오며, 높은 사용자 경험 수준 달성이 기술 스택 구축의 부수 효과가 되도록 설계.
팀과 코드베이스가 시간이 지나면서 성장하더라도 팀을 생산적으로 만들고 애플리케이션의 높은 품질 기준을 보장

 

신뢰성과 보안 관점의 프레임워크 장점

견고한 프레임워크 사용의 장점:

• 애플리케이션 개발 단순화
• 공통 기능 재사용

SRE 팀과 보안 팀의 협업:

• 프레임워크 개발 전 과정(설계 및 구현 단계)에서 보안과 신뢰성 권장 사례 적용
• 6장과 12장에서 상세 내용 다룸

 

 

4.4 초기의 속도와 지속적인 속도의 비교

기본 현상

소규모 팀의 보안과 신뢰성 고민 후순위 경향.
초반 개발 속도 우선순위로 인한 장기적 문제 발생.

속도 유형 정의

유형	정의	특징
초기 속도(Initial Velocity)	프로젝트 초반 개발 속도	보안·신뢰성 도입 미고려 시 초반에는 속도가 향상됨
지속적인 속도(Sustained Velocity)	장기적 개발 속도	보안·신뢰성 도입 미고려 시 나중에 심각한 속도 저하 발생

 

보안 및 신뢰성 관련해서 인터넷 초기 역사 사례와 IP, TCP, DNS, BGP 등 기반 프로토콜의 설계 및 진화 과정을 보면 흥미로운 점을 찾을 수 있음.

 

• 네트워크 노드 장애 상황에서의 네트워크의 생존력과 신뢰성을 유지하는 것이 ARPANET 등 인터넷 선구자들의 명확한 최고 우선순위 설계 목표
• 초창기 인터넷과 관련 논문이나 문서에서 보안을 그다지 언급하지 않았음
• IP, UDP, TCP 악의적으로 데이터를 수정하는 것을 탐지하는 방법이 없음
  • 중간자 공격(Man-in-the-Middle, MITM)
  • 패킷 변조(Packet Tampering)
  • ARP 스푸핑
• IP, UDP, TCP 보안을 위해 나온 프로토콜,
  • TLS/SSL: 애플리케이션 레벨 암호화
  • IPSec: 네트워크 레벨 보안
  • HTTPS: HTTP + TLS 조합
  • VPN: 터널링을 통한 보안 연결

 

기능 플래그란

정의: 코드는 배포하되, 기능의 활성화/비활성화를 런타임에 설정으로 제어하는 방식

핵심 원리

코드 vs 설정 분리

// 코드에 기능이 있지만
if (featureFlag.isEnabled('new-payment-system')) {
    // 새로운 결제 시스템 실행
} else {
    // 기존 결제 시스템 실행
}

// 설정으로 제어
config: {
    "new-payment-system": false  // 코드 변경 없이 끄고 켤 수 있음
}

 

보안과 신뢰성 관점

장점:

• 배포 없이 문제 기능 즉시 차단 가능
• 위험한 기능 점진적 검증
• 시스템 안정성 유지하며 새 기능 테스트

주의점:

• 플래그 관리 복잡성 증가
• 코드 복잡도 상승
• 사용하지 않는 플래그 정리 필요

 

 

4.5 마지막

핵심 특징

• 보안과 신뢰성: 전체 개발 및 운영 워크플로의 이머전트 속성
• 안정적이고 신뢰할 수 있는 시스템 설계·구축의 어려움
• 서비스의 주요 기능 요구사항과 무관해 보이는 복잡한 주제들의 고려 필요성

절충안 고려사항

• 보안, 신뢰성, 기능 요구사항 간 수많은 절충안
• 처음에는 무관해 보이나 이후 프로젝트에 상당한 비용과 위험 수반

해결 방안

• 적절한 계획 수립
• 새로 구축하는 시스템 설계 시 세 가지 측면 동시 만족
• 초기 적절한 비용 투자를 통한 시스템 수명 주기 전체의 엔지니어링 노력 절약

 

DevSecOps 

개발 단계

• SonarLint, GitGuardian, Bandit, ESLint, TruffleHog, Gitleaks, Pre-commit hooks

코드 저장소

• CodeQL, Semgrep, Dependabot, Snyk, FOSSA, Branch Protection

CI/CD 파이프라인

• SonarQube, OWASP Dependency Check, Checkmarx, Veracode, Fortify

컨테이너 보안

• Trivy, Aqua, Twistlock, Clair, Cosign, Notary

동적 테스팅

• OWASP ZAP, Burp Suite, Nessus, Rapid7

인프라 보안

• Terraform/Terragrunt, TFSec, Checkov, OPA Gatekeeper, Falco

시크릿 관리

• HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, CyberArk

모니터링/운영

• Splunk, ELK Stack, Datadog, New Relic, Sysdig, Prisma Cloud

Kubernetes 보안

• Kubesec, Kube-bench, Kube-hunter, Polaris, OPA Gatekeeper

취약점 관리

• Qualys, Rapid7, Tenable, JFrog Xray, WhiteSource