품질 속성

품질 속성은 시스템이 제 일을 얼마나 잘 해내는지 따지는 잣대입니다. 무엇을 하느냐가 아니라 어떻게 해내느냐를 봅니다. 같은 기능을 만들어도 어느 품질 속성을 앞세우느냐에 따라 설계가 달라집니다.

쉽고 빠른 이해

품질 속성은 기능과 따로 시스템이 얼마나 잘 도는지를 보는 기준입니다. 주문을 받는 것은 기능입니다. 그 주문을 1초 안에 받아내는 것은 품질 속성입니다.

이게 없으면 설계를 고를 근거가 없습니다. 같은 기능을 만드는 방법은 여럿입니다. 「빠르게」나 「튼튼하게」 같은 막연한 바람으로는 어느 방법이 맞는지 가릴 수 없습니다.

어떻게 쓰나:

1. 이 시스템에 중요한 품질 속성을 두셋 고릅니다
2. 각각을 잴 수 있는 문장으로 적습니다. 「사용자가 몰려도 1초 안에 답한다」처럼 적습니다
3. 그 문장을 맞추는 설계를 고릅니다. 다 만든 뒤 재서 맞췄는지 확인합니다

대가도 있습니다. 품질 속성끼리 서로 당깁니다. 하나를 높이는 결정이 다른 하나를 깎는 일이 흔합니다. 전부를 다 높일 수는 없습니다. 무엇을 앞세울지 순서를 정해야 합니다.

상세

자동차 두 대를 떠올려 봅시다. 두 대 모두 사람을 태우고 목적지까지 갑니다. 한 대는 기름을 적게 먹습니다. 다른 한 대는 좀처럼 고장 나지 않습니다. 차를 고르는 사람은 무엇을 하느냐보다 얼마나 잘 하느냐를 두고 망설입니다.

소프트웨어도 같은 구분을 합니다. 시스템이 무엇을 하는지는 기능 요구사항이 적습니다. 주문을 받는다, 결제를 한다, 영수증을 보낸다가 기능입니다.

품질 속성(quality attribute)은 그 기능을 얼마나 잘 해내는지를 가리키는 성질입니다. 주문을 1초 안에 받는지, 서버 한 대가 멈춰도 주문을 계속 받는지가 품질 속성입니다. 결제 수단을 하나 더 붙이기 쉬운지도 품질 속성입니다. 기능 목록이 똑같은 두 시스템도 품질 속성은 크게 다를 수 있습니다.

설계를 가르는 것

기능 하나를 구현하는 방법은 여럿입니다. 주문 시스템을 프로그램 하나로 짤 수도 있습니다. 주문·결제·배송을 서비스 여럿으로 쪼갤 수도 있습니다. 어느 쪽이든 주문은 받습니다.

두 설계를 가르는 것은 기능이 아니라 품질 속성입니다. 결제가 멈춰도 주문은 계속 받아야 한다면 쪼개는 쪽으로 기웁니다. 작은 팀이 한 번에 고쳐 내보내야 한다면 하나로 두는 쪽이 단순합니다. 그래서 소프트웨어 아키텍처를 정하는 일은 대개 품질 속성을 정하는 일에서 시작합니다.

품질 속성을 적어 두지 않으면 설계는 취향으로 정해집니다. 누구는 응답 속도를 떠올립니다. 누구는 고치기 쉬움을 떠올립니다. 그런데 둘 다 「잘 만든 설계」라는 같은 말을 씁니다. 나중에 응답이 늦다는 불만이 나와도 무엇이 기준이었는지 아무도 댈 수 없습니다.

대표적인 품질 속성

품질 속성은 정해진 개수가 없습니다. 시스템마다 중요한 것이 다릅니다. 그래도 자주 꼽히는 이름은 몇 개로 모입니다. 아래 표는 그 이름들이 무엇을 묻고 무엇으로 재는지 보입니다.

표에서 눈여겨볼 칸은 셋째 칸입니다. 「가용성이 높다」는 말만으로는 무엇을 약속했는지 알 수 없습니다. 무엇으로 재는지까지 정해야 품질 속성이 목표가 됩니다.

돌 때 드러나는 것과 고칠 때 드러나는 것

품질 속성은 언제 드러나느냐로 두 무리로 가르기도 합니다. 가르고 나면 누가 그 품질을 느끼는지가 보입니다.

성능·가용성·확장성·보안·사용성은 시스템이 돌고 있을 때 드러납니다. 사용자가 직접 느낍니다. 대개 운영하면서 재서 확인할 수 있습니다.

바꾸기 쉬움·테스트 용이성·이식성은 코드를 고치거나 옮길 때 드러납니다. 사용자는 못 느낍니다. 코드를 만지는 개발팀이 느낍니다. 기능 하나를 붙이는 데 하루가 걸릴지 한 달이 걸릴지가 여기서 갈립니다.

두 무리는 나빠지는 모습이 다릅니다. 돌 때 드러나는 품질은 떨어지면 사용자 불만으로 바로 보입니다. 고칠 때 드러나는 품질은 조금씩 나빠지므로 한동안 눈에 띄지 않습니다.

잴 수 있게 적기

「빨라야 한다」는 품질 속성을 적은 것이 아닙니다. 얼마나 빨라야 하는지, 어떤 상황에서 그래야 하는지가 빠져 있습니다. 그래서 다 만든 뒤에 맞췄는지 못 맞췄는지 가릴 수 없습니다.

품질 속성은 한 장면으로 적습니다. 무슨 일이 일어났을 때, 어떤 상황에서, 시스템이 어떻게 반응하는지를 적습니다. 그 반응을 무엇으로 재는지도 함께 적습니다. 이렇게 칸을 나눠 적은 문장을 품질 속성 시나리오라고 합니다.

flowchart TD
    A["무슨 일이 일어나나 · 사용자 1만 명이 동시에 주문한다"]
    B["어떤 상황인가 · 평소처럼 운영 중이다"]
    C["시스템이 어떻게 하나 · 주문을 받아 저장한다"]
    D["무엇으로 재나 · 요청 100개 중 99개가 1초 안에 끝난다"]
    A --> B --> C --> D

그림은 주문 서비스의 성능 목표를 한 장면으로 적은 것입니다. 화살표는 일이 벌어지는 순서가 아닙니다. 한 문장을 네 칸으로 나눠 읽는 차례입니다.

네 칸이 다 차 있으면 맞췄는지 재 볼 수 있습니다. 일부러 사용자 1만 명만큼의 요청을 걸어 보는 시험이 그 방법입니다. 이런 시험을 부하 테스트라고 합니다.

고칠 때 드러나는 품질도 같은 꼴로 적습니다. 「결제 수단을 하나 더 붙일 때 결제 모듈 밖의 코드는 고치지 않는다」처럼 적으면 됩니다. 새 결제 수단을 붙여 본 뒤 손댄 파일을 세면 맞췄는지 알 수 있습니다.

서로 당기는 품질 속성

품질 속성은 따로 움직이지 않습니다. 설계 결정 하나가 여러 품질 속성을 함께 흔듭니다. 하나를 올리면 다른 하나가 내려가는 일이 흔합니다.

아래 표의 둘째 줄에 나오는 계층은 코드를 맡은 일에 따라 겹겹이 나눈 묶음입니다. 요청은 위 계층에서 아래 계층으로 차례로 지나갑니다. 표는 흔한 결정 셋이 무엇을 올리고 무엇을 내리는지 보입니다.

표의 어느 줄도 틀린 결정이 아닙니다. 무엇을 얻고 무엇을 내주는지가 다를 뿐입니다. 모든 품질 속성을 다 높이는 설계는 없습니다.

하나를 얻으려고 다른 하나를 내주는 관계를 트레이드오프라고 합니다. 트레이드오프를 피할 수 없으니 품질 속성에는 순서를 매깁니다. 이 시스템에 가장 중요한 것 두셋을 먼저 정합니다. 결정이 부딪히면 그 순서대로 고릅니다.

순서를 정하면 고를 설계도 좁혀집니다. 여러 설계 결정을 한 벌로 묶어 이름 붙인 것을 아키텍처 양식이라고 합니다. 양식마다 앞세우는 품질 속성이 다릅니다.

레이어드 양식이 한 예입니다. 표의 둘째 줄 「계층을 하나 더 둔다」를 시스템 전체에 적용한 양식입니다. 표의 그 줄과 같이 바꾸기 쉬움을 얻고 성능을 내줍니다.

비기능 요구사항과 다른 이름

품질 속성 둘레에는 비슷하게 쓰이는 이름이 몇 있습니다. 같은 것을 부르는 이름도 있습니다. 조금 다른 것을 부르는 이름도 있습니다.

요구사항 문서에서는 비기능 요구사항이라는 말을 자주 씁니다. 기능이 아닌 요구라는 뜻입니다. 품질 속성은 성질의 이름입니다. 비기능 요구사항은 그 성질이 넘어야 할 목표값을 적은 요구사항입니다.

앞 그림처럼 품질 속성 시나리오로 적은 문장 하나가 비기능 요구사항 하나가 됩니다. 「요청 100개 중 99개가 1초 안에 끝난다」가 그런 요구사항입니다.

품질 특성은 품질 속성과 같은 것을 부르는 이름입니다. 영어권 개발자들은 ilities 라고 뭉뚱그려 부르기도 합니다. availability · scalability · portability 처럼 이름이 -ility 로 끝나는 것이 많아서 붙은 별명입니다.

언제 따지나

품질 속성은 설계를 시작할 때 정합니다. 뒤늦게 가용성을 높이려 하면 서버를 나누는 방식부터 다시 짜야 할 수 있습니다. 그래서 설계 초기에 중요한 품질 속성 두셋과 그 목표값을 적어 둡니다.

돌 때 드러나는 품질은 운영하면서 계속 잽니다. 이때 실제로 재는 값을 서비스 수준 지표라고 합니다. 1초 안에 끝난 요청의 비율이 그런 값입니다.

그 값이 넘어야 할 선은 서비스 수준 목표로 정해 둡니다. 「100개 중 99개 이상이 1초 안에 끝난다」가 그런 선입니다. 선을 미리 그어 두면 품질이 떨어지는 순간을 사용자보다 먼저 알아챕니다.

모든 품질 속성을 처음부터 높게 잡을 필요는 없습니다. 사용자가 몇 안 되는 사내 도구를 여러 대로 나눠 돌리면 얻는 가용성보다 운영 짐이 더 큽니다. 지금 중요하지 않은 품질 속성은 목표를 낮게 잡고 미룹니다.

관련 항목

품질 속성으로 꼽히는 성질

성능 · 가용성 · 확장성 · 보안 · 바꾸기 쉬움 · 유지보수성 · 테스트 용이성 · 이식성 · 사용성 · 신뢰성 · 상호운용성 · 배포 용이성 · 관측성 · 탄력성 · 내결함성 · 기능 확장성

품질 속성을 재는 지표

응답 시간 · 처리량 · 지연 · 꼬리 지연 · 서비스 수준 지표 · 서비스 수준 목표 · 서비스 수준 계약 · 평균 복구 시간 · 평균 고장 간격

품질 속성을 적고 평가하는 방법

품질 속성 시나리오 · 비기능 요구사항 · 기능 요구사항 · 부하 테스트 · ATAM · ISO 25010 · 아키텍처 결정 기록

품질 속성을 얻으려고 고르는 설계

아키텍처 양식 · 아키텍처 전술 · 레이어드 · 계층 · 암호화 · 복제 · 캐싱

품질 속성끼리 부딪힐 때 따지는 원칙

트레이드오프 · 결합도 · 응집도 · 관심사 분리 · CAP 정리

품질 속성을 다루는 상위 분야

소프트웨어 아키텍처 · 소프트웨어 공학 · 요구사항 공학 · 시스템 설계