이 문서를 통해 아래 질문들에 답할 수 있게 됩니다.
- Non-functional Requirement를 측정 가능한 SLO와 운영 지표로 어떻게 바꾸는가?
- latency, throughput, availability, durability, security, retention은 각각 어떤 설계 결정을 강제하는가?
- 비기능 요구사항은 성능, 정합성, 장애 격리, 운영 복잡도를 어떻게 바꾸는가?
개요
Non-functional Requirement는 “빠르게”, “안정적으로”, “확장 가능하게” 같은 좋은 말의 모음이 아니다.
기능이 어떤 품질로 동작해야 하는지 측정 가능한 기준으로 정하는 일이다.
비기능 요구사항은 설계 선택을 직접 바꾼다.
p95 200ms는 cache, index, 외부 API 호출 위치를 묻게 만든다.
99.9% availability는 장애 허용 시간과 fallback 정책을 묻게 만든다.
데이터 5년 보존은 storage, partition, 분리 보관, 삭제 정책을 묻게 만든다.
품질 속성 분리
비기능 요구사항은 한 문장으로 묶지 않는다.
| 속성 | 질문 | 설계 영향 |
|---|---|---|
| Latency | 사용자는 몇 ms 안에 응답을 받아야 하는가? | cache, index, timeout, 비동기 분리 |
| Throughput | 초당 몇 요청이나 작업을 처리해야 하는가? | scale out, queue, batch, partition |
| Availability | 어느 정도 장애를 허용하는가? | redundancy, failover, degradation |
| Durability | 저장된 데이터는 얼마나 잃으면 안 되는가? | transaction, replication, backup |
| Consistency | 최신성이나 중복 방지가 얼마나 중요한가? | lock, unique constraint, idempotency |
| Security | 누가 무엇을 할 수 있는가? | authn/authz, audit, encryption |
| Retention | 얼마나 오래 보관하고 언제 삭제하는가? | 분리 보관, partition, lifecycle |
| Observability | 무엇을 보고 장애를 판단하는가? | metrics, logs, tracing, alert |
이 표는 기능보다 덜 중요한 부록이 아니다.
실제로는 비기능 요구사항이 아키텍처의 복잡도를 결정하는 경우가 많다.
강의 영상 업로드 예시
강의 영상 업로드 기능의 비기능 요구사항을 다음처럼 정할 수 있다.
업로드 세션 생성 latency = p95 300ms
원본 영상 저장 durability = 99.999999999%
트랜스코딩 시작 지연 = 업로드 완료 후 2분 이내
트랜스코딩 처리량 = peak 500 videos/hour
강의 재생 API availability = 월 99.95%
썸네일 생성 실패율 = 0.1% 이하
원본 영상 보존 = 게시 중 + 삭제 후 30일이 요구는 구조를 강제한다.
업로드 세션 생성은 빠르게 끝내기 위해 실제 파일 전송을 object storage signed URL로 분리한다.
원본 영상 내구성은 DB blob 저장보다 object storage와 checksum 검증을 요구한다.
트랜스코딩 시작 지연은 queue age와 worker capacity를 SLO로 만든다.
강의 재생 가용성은 CDN, fallback 품질, 원본 저장소 장애 격리를 요구한다.
SLO로 바꾸기
비기능 요구사항은 SLO와 측정 방식으로 바꾼다.
| 요구 | SLI | SLO | 제외 범위 |
|---|---|---|---|
| 업로드 세션 생성이 빠르다 | session API latency p95 | 300ms 이하 | 파일 전송 시간 제외 |
| 업로드 원본을 잃지 않는다 | verified object durability | 99.999999999% 수준 | 사용자의 취소 업로드 제외 |
| 인코딩이 제때 시작된다 | transcode queue age | 2분 이하 99% | 비정상 codec 수동 처리 제외 |
| 강의 재생이 안정적이다 | playable request ratio | 월 99.95% | 사용자 네트워크 오류 제외 |
| 원본을 보존한다 | restorable original age | 삭제 후 30일 | 법적 즉시 삭제 요청 제외 |
SLO는 숫자를 쓰는 것으로 끝나지 않는다.
측정 위치와 제외 범위를 정해야 운영 중 논쟁이 줄어든다.
설계 선택으로 연결
비기능 요구사항은 다음처럼 설계 선택으로 이어진다.
| 비기능 요구 | 가능한 선택 | 새 비용 |
|---|---|---|
| 세션 API p95 300ms | signed URL 발급만 동기 처리 | upload 상태 추적 필요 |
| 원본 durability | object storage, checksum, versioning | 저장 비용, lifecycle 운영 |
| transcode 시작 2분 | queue, worker pool, priority | queue age 알림, 재처리 |
| 재생 99.95% | CDN, origin fallback, pre-signed URL 갱신 | cache purge, 권한 만료 |
| 썸네일 실패율 0.1% | 별도 thumbnail worker, retry 제한 | 부분 실패 상태 노출 |
| 원본 삭제 후 30일 복구 | soft delete, lifecycle rule | 삭제 요청 예외 처리 |
성능을 올리면 정합성이나 운영 복잡도가 바뀐다.
정합성을 강하게 잡으면 latency나 throughput이 나빠질 수 있다.
이 trade-off를 숫자와 함께 적는 것이 비기능 요구사항의 역할이다.
Spring 경계 예시
SLO가 있으면 API가 어떤 일을 동기 처리하지 말아야 하는지 보인다.
@PostMapping("/courses/{courseId}/videos/upload-sessions")
public ResponseEntity<UploadSessionResponse> createUploadSession(@PathVariable Long courseId) {
UploadSession session = uploadService.createSession(courseId);
return ResponseEntity.accepted().body(
new UploadSessionResponse(session.id(), session.uploadUrl(), "UPLOAD_PENDING")
);
}202 Accepted는 기능 회피가 아니다.
비기능 요구사항이 “업로드 세션 생성 p95 300ms”와 “파일 업로드와 트랜스코딩은 별도 상태로 추적”으로 나뉘어 있기 때문에 가능한 계약이다.
반대로 API가 파일 전송과 인코딩 완료까지 동기 처리하면 latency, storage 장애, worker capacity가 한 요청에 묶인다.
관측 기준
비기능 요구사항은 관측 지표로 이어져야 한다.
http.server.requests.p95upload.session.create.p95upload.object.checksum_mismatch.counttranscode.queue_age.secondstranscode.worker.throughputplayback.cdn.error_ratethumbnail.failure.ratevideo.lifecycle.deleted_but_restorable.count
지표가 없으면 요구사항은 선언으로만 남는다.
운영자가 볼 수 없는 비기능 요구사항은 장애 때 검증할 수 없다.
위험 신호
- “빠르게”, “많이”, “안정적으로”만 있고 숫자가 없다.
- SLO는 있지만 측정 위치와 제외 범위가 없다.
- latency 목표와 외부 API timeout이 모순된다.
- availability 목표가 있는데 CDN 장애와 origin fallback 정책이 없다.
- retention 요구가 있는데 object lifecycle과 복구 가능 기간이 없다.
- security 요구가 있는데 audit log와 권한 경계가 없다.
개인 프로젝트 기준
개인 프로젝트에서는 모든 SLO를 정교하게 만들 필요는 없다.
하지만 최소한 다음은 숫자로 둔다.
- 핵심 API 목표 p95
- 예상 peak QPS 또는 작업량
- 장애 때 허용할 기능 축소
- 데이터 보존 기간
- object storage timeout
이 정도만 있어도 “좋은 성능”이 아니라 “어떤 성능을 목표로 했는지”를 설명할 수 있다.
기업 운영 기준
기업 운영에서는 비기능 요구사항이 책임과 비용으로 이어진다.
- SLO owner가 있어야 한다.
- error budget을 어떻게 쓸지 정해야 한다.
- alert 기준이 SLO와 연결되어야 한다.
- 용량 계획과 비용 추정이 필요하다.
- 보안과 보존 요구는 감사 증거로 남아야 한다.
- SLO 위반 후 개선 작업과 일정이 기록되어야 한다.
확인 질문
확인 질문
- 확인 질문: Non-functional Requirement를 숫자로 바꿔야 하는 이유는 무엇인가?
- 답변: 숫자와 측정 방식이 있어야 설계 선택의 성공 여부와 운영 알림 기준을 판단할 수 있기 때문이다.
- 확인 질문:
202 Accepted응답이 비기능 요구사항과 연결되는 이유는 무엇인가?
- 답변: 업로드 세션 생성 latency와 파일 전송, 트랜스코딩 완료 시간을 분리해 성능 목표와 비동기 운영을 함께 만족시키기 때문이다.
- 확인 질문: 비기능 요구사항이 바꾸는 설계 축은 무엇인가?
- 답변: 성능과 가용성 목표를 명확히 하지만, 측정, 알림, fallback, 보존, 보안 운영 복잡도를 증가시킨다.