요구사항을 "명확하게" 썼는데, 왜 여전히 문제가 생길까요? - 소프트웨어 비기능 요구사항의 적절성

 

비기능 요구사항 작성은 항상 어렵습니다. 

표현은 애매하고, 해석은 다르고, 검증은 어렵습니다.

비기능 요구사항을 설명하고자 "안정적이게", "빠르게", "사용자 친화적으로"라는 모호한 표현들이 수반되고,

이들이 반복될 수록 개발 현실에서는 더 많은 질문들이 쏟아집니다.

 

"얼마나 빠르게?"

"얼마나 안정적으로?"

"사용자 친화적이라는 누구를 기준으로 하나요?"

 

그래서 비기능 요구사항 작성을 위한 한걸음 더 들어가보면, 결국 비기능 요구사항은 시스템이 무엇을 해야 하는지보다, 어떻게 동작해야 하는지를 규정하는 것인데, 일반적으로 다음과 같은 품질 속성과 관련된 요소들을 포함하게 됩니다. 

• 성능: 응답 시간, 처리량
• 가용성: 가동 시간, 중단 시간
• 보안: 인증, 권한, 암호화
• 사용성: 직관성, 접근성
• 유지보수성: 수정 용이성, 로그 추적
• 이식성: 플랫폼 간 호환성 등
• 등등

하지만 이러한 품질 속성들은 대부분 정량화가 어렵고, 정성적 표현에 의존하는 경우가 많습니다. 그래서 많은 실무자들은 비기능 요구사항을 명확하게 만들기 위해 수치를 강제로 삽입하거나 벤치마크 기준을 가져와 사용합니다.

 

그 결과, 우리는 이런 모호한 말들을 수치로 바꾸는 데 집중하게 됩니다.

“1초 이내 응답”, “99.95% 가용성”, “90% 이상 사용자 만족도”…

하지만 이 수치들은 정말로 고객이 필요로 하는 니즈에 부합하는 것일까요?

 

[참고사항]

도대체 "빠르게"가 얼마나 빨라야 하나요? - 소프트웨어 비기능 요구사항의 명확성

도대체 "빠르게"가 얼마나 빨라야 하나요? - 소프트웨어 비기능 요구사항의 명확성

 

하지만, 다음과 같이 또 다른 질문들이 생겨납니다.

 

"이게 정말 이렇게 써도 되는걸까?"

"이 정도 수준으로 써야 맞는걸까?"

 

실제 개발 현실에서 요구사항 엔지니어들이 느끼는 이 막연한 불안감의 정체는 다름아닌 요구사항이 "적절한 수준에서 작성되지 않았다"는 본능적 인식에서 비롯됩니다. 또한 품질 속성을 기반으로 비기능 요구사항을 명확하게 작성했다는 이유만으로 좋은 요구사항이 되는 것은 아닙니다.

 

이때 반드시 짚고 넘어가야 할 특성이 INCOSE 가이드에서 정의하고 있는 니즈 및 요구사항 명세의 15가지 특성 중 바로 적절성(Appropriate, C2)입니다.

 

INCOSE 요구사항 작성 가이드(GWR): Appropriate (C2)

INCOSE 요구사항 작성 가이드(GWR): Appropriate (C2)

반응형

명확성(Unambiguous, C3)보다 적절성이 먼저입니다

많은 문서 작성 가이드에서 요구사항의 명확성을 강조합니다. 해석의 여지가 없도록, 수치를 넣고, 조건을 제한하고, 테스트 가능하게 만들라고 말합니다.

 

하지만 여기서 놓치기 쉬운 점이 있습니다.

명확성은 "어떻게 표현했는가"의 문제지만, 적절성은 "무엇을 표현했는가"의 문제입니다.

 

즉, 아래와 같은 사례는 “명확하게 썼지만 적절하지 않은” 대표적 예시입니다.

1. 시스템은 100ms 이내에 모든 요청을 처리해야 한다.
2. 주요 거래 요청은 정상 트래픽 하에서 95% 이상 500ms 이내에 응답해야 한다.

 

첫번째 사례는 수치는 명확하지만, 현실적 제약이나 실제 고객 니즈와 괴리되어 있을 수 있습니다. 

 

또한, 시스템 차원에서 보아야 할 요구사항을 하위 컴포넌트에 똑같이 배분하는 경우, 설계상의 강제나 구현상 제한으로 이어질 수 있습니다. 이는 오히려 기술적 부채(technical debt)를 야기합니다.

 

“적절성(C2)“은 단지 맞는 내용이 아니라, 맞는 수준을 의미합니다

INCOSE에서 말하는 적절성(C2)은 단순히 “그 내용이 맞느냐”의 문제가 아닙니다.

그 요구사항이 시스템 계층 구조 상 어디에 위치하며, 해당 수준에서 충분히 의미 있고 유효한 방식으로 표현되었느냐를 판단하는 기준입니다.

 

즉, 같은 요구사항이라도 시스템 레벨(System Level), 서브시스템 레벨(Subsystem Level), 컴포넌트 레벨(Component Level)에 따라 표현 방식과 구체화 정도가 달라져야 합니다.

 

예를 들어 다음과 같은 사례를 살펴보겠습니다.

• 서비스는 월 평균 99.95% 이상의 가용성을 유지해야 한다. (시스템 수준)
• 데이터 처리 서버는 장애 발생 시 10초 이내에 예비 서버로 자동 전환되어야 한다. (서브시스템 수준)
• 헬스 체크 모듈은 3초 추기로 상태 신호를 송신해야 하며, 3회 실패 시 경고 이벤트를 발생시켜야 한다. (컴포넌트 수준)

이처럼 시스템 전체의 기대 수준은 상위에서 정의하고, 하위 레벨로 내려갈수록 실행 가능한 기술적 조치로 구체화되는 방식이 요구됩니다. 이것이 바로 적절한 수준에서의 요구사항 표현입니다.

 

그럼 요구사항의 적절한 수준은 어떻게 결정할 수 있을까요?

요구사항을 잘 쓴다는 것은 사실상 "어디까지 써야 하는가"를 아는 것입니다. 그 감을 키우기 위해서는 단지 형식이 아닌 시스템 구조와 설계 흐름에 대한 이해가 필요합니다. 이것이 요구사항 정의가 단순한 문서 작업이 아니라, 시스템 전체를 설계하는 첫번째 단계인 이유이기도 합니다.

 

또한 다음과 같은 고려사항을 통해 요구사항을 적절하게 작성하는데 있어 어느 정도의 기준을 마련할 수 있을 것이라 생각됩니다. 

 

1. 요구사항의 수준(Level)을 명확히 해야 합니다. 

요구사항이 시스템 전체에 관한 것인지, 아니면 서브시스템에 관한 것인지, 컴포넌트에 관한 것인지에 따라 표현 방식이 달라져야 합니다.

• 이 요구사항은 시스템 전체에 대한 것인가요?
• 아니면 서브시스템, 컴포넌트, 혹은 기능 단위에 대한 것인가요?

2. 그런 다음 해당 수준에서 “검증 가능”한 단위로 표현해야 합니다. 

적절하더라도 검증할 수 없다면 그것은 요구사항이라 할 수 없습니다. 

• 시스템 수준: SLA, 사용자 체감 기준, 법적 요구 등
• 컴포넌트 수준: 처리 시간, 신호 전송 주기, 상태 변화 조건 등

3. 또한 상위 니즈와의 정합성을 따져보아야 합니다. 

즉, 이 요구사항이 왜 필요한가에 대한 질문에 답을 할 수 있어야 합니다. 

• 이 요구사항이 상위 요구사항이나 니즈와 논리적으로 연결되는가?
• 또는 상위 요구사항의 일부를 구성하는가?

4. 너무 과도하거나 기술적인 내용은 설계로 남겨 둘 필요가 있습니다. 

요구사항은 “무엇을 만족해야 하는가”를 정의하고, “어떻게 만족할 것인가”는 설계 단계에서 결정된다는 사실을 기억해야 합니다. 즉, 너무 낮은 수준으로 기술된 요구는 요구사항이 아니라 설계 명세가 되어 버리게 됩니다.

 

---

마치며... "적절하다"는 말이 가장 어렵다는 걸, 저도 잘 압니다.

요구사항을 적절하게 작성한다는 건, 말처럼 쉽지 않습니다. 시스템의 구조를 충분히 이해하고, 상위 니즈를 해석하며, 세부 설계와의 경계를 의식하면서 적절한 수준과 표현을 결정해야 하기 때문입니다.

 

그런데 실무에서는 그보다 훨씬 복잡한 현실이 존재합니다. 요구사항의 작성자는 시스템 구조 전체를 알지 못할 수도 있고, 상위 니즈 자체가 명확하게 주어지지 않는 경우도 많습니다. 때로는 일정에 쫓겨, “일단 명확하게 수치만 넣자”는 식으로 문서를 마무리해야 할 때도 있습니다.

 

그래서 “적절성”은 늘 애매하게 느껴집니다. 하지만 그렇기 때문에 오히려, 이 모호한 영역을 붙잡고 고민하려는 관심과 태도가 중요합니다.

요구사항을 적절한 수준에서 쓴다는 건, 단순히 문장을 잘 쓰는 문제가 아니라 시스템 전체를 설계적으로 바라보는 관점을 갖는 일이며,

동료 개발자와 여러 이해관계자들과의 공감과 협업의 첫걸음이기도 합니다.

 

물론 완벽한 적절성은 어렵습니다.

하지만 “적절하게 쓰려고 노력한 흔적”은 결국 프로젝트 전반의 품질로 드러납니다. 요구사항이 실현 가능하고, 검증 가능하고, 상위 니즈와 자연스럽게 연결될 때 우리는 더 이상 문서를 고치는 데 시간을 쓰지 않고, 시스템 그 자체를 만드는 데 집중할 수 있을 것입니다.