133. 비기능 요구사항 (Quality Attributes) - 성능, 보안, 가용성, 신뢰성 등

핵심 인사이트 (3줄 요약)

본질: 비기능 요구사항 (Non-Functional Requirements, NFR)은 시스템이 제공하는 특정 동작(기능)이 아닌, 시스템 전체가 동작하는 과정에서 준수해야 할 품질 속성(Quality Attributes)과 기술적/운영적 제약사항을 정의한다.

가치: 기능 요구사항이 사용자 만족도를 결정한다면, 비기능 요구사항은 시스템의 생존(Survival)과 확장성(Scalability)을 결정한다. NFR을 조기에 식별하고 정량화하지 않으면 시스템은 첫 트래픽 폭주 시 즉각 붕괴한다.

융합: NFR은 소프트웨어 아키텍처 설계의 가장 강력한 제약(Constraint)으로 작용하며, 개발 단계의 기술 스택(프레임워크, DB, 클라우드 인프라) 선택과 테스트 단계의 부하/보안 테스트 기준을 직접적으로 지배한다.

Ⅰ. 개요 및 필요성 (Context & Necessity)

개념: 비기능 요구사항 (NFR)은 '시스템이 무엇을 해야 하는가(What)'가 아니라 '시스템이 어떻게 동작해야 하는가(How)'를 명세한 것이다. 성능, 신뢰성, 보안성, 가용성, 유지보수성 등 시스템의 '품질(Quality)'과 관련된 모든 제약을 포함한다.
필요성: 개발자가 아무리 완벽한 '결제 기능'을 만들었더라도, 결제 버튼을 누르고 1분을 기다려야 하거나(성능 실패), 서버가 하루에 한 번씩 다운되거나(가용성 실패), 해커에게 고객 카드 정보가 유출된다면(보안성 실패) 그 시스템은 폐기 처분된다. 비기능 요구사항은 이러한 치명적인 실패를 막기 위한 '보이지 않는 방패'다.
비유: 기능 요구사항이 스마트폰의 '카메라, 메신저, 게임' 기능이라면, 비기능 요구사항은 스마트폰의 '배터리 지속 시간, 방수/방진 등급, 무게, 발열 제어'와 같다. 기능이 아무리 많아도 배터리가 10분 만에 방전되면 그 폰은 쓸 수 없다.
발전 과정: 과거에는 개발 완료 후 테스트 단계에서 비기능(성능 등)을 점검하고 튜닝하는 방식이 주류였으나, 구조적 결함은 후행 튜닝으로 해결할 수 없다는 뼈아픈 교훈(소프트웨어 위기)을 얻은 후, 현재는 초기 아키텍처 설계 단계부터 NFR을 핵심 동인(Driver)으로 삼는다.

  ┌─────────────────────────────────────────────────────────┐
  │                 기능 vs 비기능 요구사항                 │
  ├─────────────────────────────────────────────────────────┤
  │                                                         │
  │  [상황] "ATM 기기에서 현금을 인출한다."                 │
  │                                                         │
  │  [기능 (What)]                                          │
  │  - 카드 삽입 시 비밀번호 입력을 요청한다.               │
  │  - 잔액이 충분하면 현금을 지급한다.                     │
  │                                                         │
  │  [비기능 (How well)]                                    │
  │  - 비밀번호 검증은 1초 이내에 완료되어야 한다. (성능)   │
  │  - 통신은 256비트 종단간 암호화되어야 한다. (보안)      │
  │  - ATM은 1년 365일 99.9% 가동되어야 한다. (가용성)      │
  └─────────────────────────────────────────────────────────┘

📢 섹션 요약 비유: 건물(시스템)을 지을 때, 엘리베이터(기능)를 설치하는 것도 중요하지만, 지진 강도 7.0을 견디는 내진 설계(비기능 요구사항)가 되어 있지 않으면 그 건물은 모래성일 뿐입니다.

Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)

품질 속성 트리 (Quality Attribute Tree)

ISO/IEC 25010 (과거 9126) 표준에 따르면 시스템의 품질(비기능)은 크게 8가지 주 속성으로 나뉜다. 그중 시스템 아키텍처에 가장 큰 영향을 미치는 핵심 4가지는 다음과 같다.

핵심 속성	의미	정량적 지표 (Metric) 예시
가용성 (Availability)	시스템이 정상적으로 서비스를 제공하는 시간의 비율	"SLA 99.99% 보장 (연간 장애 시간 52분 미만)"
성능 (Performance)	특정 작업에 소요되는 응답 시간 및 단위 시간당 처리량	"동시 접속자 10,000명 기준 응답시간 2초 이내"
보안성 (Security)	불법적인 접근으로부터 데이터와 시스템을 보호하는 능력	"비밀번호는 SHA-256 + Salt로 해싱하여 저장할 것"
확장성 (Scalability)	사용자 증가 시 시스템 자원(서버)을 늘려 성능을 유지하는 능력	"트래픽 2배 증가 시 Auto-Scaling으로 1분 내 서버 증설"

정량화(Quantification) 메커니즘

비기능 요구사항의 가장 중요한 원칙은 **"측정할 수 없으면 관리할 수 없다"**는 것이다. 애매모호한 형용사는 아키텍트에게 아무런 정보도 주지 못한다.

  ┌───────────────────────────────────────────────────────────────┐
  │                 비기능 요구사항의 정량화 변환                   │
  ├───────────────────────────────────────────────────────────────┤
  │                                                               │
  │  ❌ 나쁜 요구사항 (모호함)       ✅ 좋은 요구사항 (정량화)      │
  │  "시스템이 빨리 켜져야 한다"   → "시스템 부팅 및 첫 화면 표시가 │
  │                                  95% 확률로 3초 이내에 완료"  │
  │                                                               │
  │  "해킹당하면 안 된다"          → "OWASP Top 10 취약점 스캔을   │
  │                                  통과하고, DB 데이터 암호화"  │
  │                                                               │
  │  "사용자가 늘어나도 안 끊기게" → "TPS(초당 트랜잭션) 5,000 도달 │
  │                                  시 CPU 사용률 70% 이하 유지" │
  └───────────────────────────────────────────────────────────────┘

[다이어그램 해설] "빨리", "안전하게", "많이"라는 단어는 이해관계자(고객 vs 개발자) 간의 심각한 인식 차이를 낳는다. 정량화된 수치(3초, OWASP, TPS 5000)가 존재해야만 비로소 성능 테스트 도구(JMeter, nGrinder)를 통해 합격/불합격(Pass/Fail)을 판정할 수 있다.

NFR 간의 상충 관계 (Trade-off)

비기능 요구사항들은 서로 충돌하는 경향이 있다. 하나를 극대화하면 다른 하나가 희생되는 트레이드오프(Trade-off) 관계를 아키텍트가 조율해야 한다.

보안성 vs 성능: 데이터를 최고 수준으로 암호화(보안성↑)하면, 암복호화 연산에 CPU가 과도하게 사용되어 응답 시간(성능↓)이 느려진다.
가용성 vs 비용: 서버를 3중화(Active-Active-Active)하여 절대 죽지 않는 시스템(가용성↑)을 만들면 인프라 비용(비용 제약 위반)이 3배로 뛴다.
📢 섹션 요약 비유: 레이싱 카를 만들 때, 차를 무겁고 튼튼하게(안전성) 만들면 속도(성능)가 떨어지고, 너무 가볍게(성능) 만들면 코너에서 날아가는(안전성 실패) 것과 같이 NFR은 끝없는 줄다리기입니다.

Ⅲ. 융합 비교 및 다각도 분석

비교: 제약사항 (Constraints) vs 품질 속성 (Quality Attributes)

비기능 요구사항은 크게 '품질 속성'과 '제약사항'으로 다시 나뉜다.

구분	성격	예시	아키텍처 영향
품질 속성	시스템이 도달해야 할 목표치 (조율 가능)	성능, 가용성, 확장성, 사용성	설계의 형태를 변화시킴 (예: 캐시 도입)
제약사항	절대적으로 지켜야 하는 법적/물리적 조건 (조율 불가)	"반드시 Java 17을 사용할 것", "예산 1억 원 이내", "개인정보보호법 준수"	설계의 선택지를 좁힘 (예: 다른 언어 불가)

품질 속성은 돈과 기술을 투자하면 목표를 바꿀 수 있지만, 제약사항은 외부 환경(법, 회사 표준)에 의해 강제되므로 시스템 설계 시 가장 먼저 '배제할 옵션'을 결정하게 만든다.

📢 섹션 요약 비유: 품질 속성이 "100m를 12초에 뛰어라(노력하면 가능)"라면, 제약사항은 "반드시 빨간 운동화만 신고 뛰어라(규칙, 선택 불가)"입니다.

Ⅳ. 실무 적용 및 기술사적 판단

실무 시나리오

한 대학교의 수강신청 시스템 개발 프로젝트. 학교 측은 평소 접속자 수가 100명 수준이므로 클라우드 도입 없이 교내의 저렴한 물리 서버 1대(단일 DB)로 시스템을 구축해 달라는 제약조건(예산 제약)을 걸었다. 그러나 수강신청 첫날 오전 9시, 2만 명의 학생이 1초 만에 동시 접속하자 서버는 즉각 다운되었다.

판단 기준 및 아키텍트의 대응

문제 진단: 평상시 트래픽과 피크 트래픽의 편차가 극심한 도메인(수강신청, 티켓 예매)에서 '확장성(Scalability)' NFR을 무시하고 예산 제약만 따른 결과다.
해결책:
1. 요구사항 협상: "물리 서버 1대로는 수강신청 당일 2만 명의 트래픽(성능 NFR)을 절대 감당할 수 없습니다."
2. 아키텍처 제안: 수강신청 기간 3일 동안만 AWS 클라우드의 Auto-Scaling을 이용해 서버를 100대로 늘리고 평소엔 1대로 줄이는 하이브리드 아키텍처를 도입하여 비용 제약과 성능 목표를 동시에 만족시킨다.
📢 섹션 요약 비유: 평소에는 손님이 없는 식당이라도 명절 당일에는 수백 명이 몰릴 것을 예상하여, 평소에는 접어두었다가 명절에만 펼칠 수 있는 야외 임시 테이블(클라우드 확장성)을 설계에 반영하는 것이 실무 NFR 관리입니다.

Ⅴ. 기대효과 및 결론

정량/정성 기대효과

구분	내용	개선 효과
정량	성능 지표의 테스트 기준선화	오픈 전 부하 테스트를 통한 병목 구간 100% 사전 식별 및 튜닝
정성	아키텍처(구조)의 정당성 확보	고비용의 기술(MSA, Redis 등)을 도입해야 하는 명확한 논리적 근거 제시

미래 전망 및 결론

클라우드 네이티브와 마이크로서비스 아키텍처(MSA) 시대가 도래하면서 시스템은 수백 개의 작은 조각으로 쪼개졌다. 이제 기능의 구현 자체는 오픈소스와 라이브러리로 매우 쉬워졌으나, 쪼개진 수백 개의 서비스 간의 네트워크 지연(성능), 장애 격리(가용성), 분산 추적(유지보수성) 등 비기능적 요구사항의 복잡도는 과거와 비교할 수 없이 상승했다. 따라서 NFR은 더 이상 '기능'을 보조하는 조연이 아니라, 현대 소프트웨어 엔지니어링 전체를 이끌어가는 핵심 주연(Driver)이다.

📢 섹션 요약 비유: 비기능 요구사항은 화려한 무대 위의 아이돌(기능)이 빛날 수 있도록, 무대 뒤에서 묵묵히 조명, 음향, 안전줄을 관리하는 총괄 무대 감독(아키텍처)의 대본과 같습니다.