「몇 초면 만족인가」를 빠뜨리지 않으려면 ── IPA 「비기능 요구 등급」으로 비기능 요구사항을 정리하기

「화면 전환이 느리다는 말을 들었는데, 계약서에도 사양서에도 응답 시간 합의가 없다」

「야간 배치가 아침까지 끝나지 않게 됐는데, 데이터가 몇 년에 걸쳐 얼마나 늘지 아무도 추정하지 않았다」

「서버 장애로 반나절 멈추고 나서야, 『몇 시간 안에 복구할 수 있는 구성인지』를 발주 때 확인하지 않았다는 사실을 알았다」

시스템 개발 분쟁이라고 하면 기능에 대한 인식 차이가 먼저 떠오릅니다. 다만 실제로 운용이 시작된 뒤에 다투는 경우는, 이런 기능 밖의 요구사항, 이른바 비기능 요구사항을 정하지 않은 탓인 경우가 적지 않습니다.

이렇게 빠뜨리는 일을 막기 위한 공적 도구가 IPA(독립행정법인 정보처리추진기구)의 비기능 요구 등급입니다. 이 글에서는 그 내용과, 중소기업 업무 시스템에서 현실적으로 쓰는 법을 발주 측도 알아들을 수 있는 말로 정리합니다.

1. 먼저 결론

• 비기능 요구사항이란 「무엇을 하는가」가 아니라 「어느 정도 품질·조건으로 돌아가는가」의 요구사항이다. IPA 분류에서는 가용성, 성능·확장성, 운용·보수성, 이행성, 보안, 시스템 환경·에콜로지라는 6개 대항목으로 정리된다
• 비기능 요구 등급은 이 6대 항목의 요구 항목을 빠짐없이 목록화하고, 0부터 최대 5까지 6단계 레벨로 발주 측과 개발 측이 맞추기 위한 IPA 도구 모음(무료)이다. 실제 레벨 정의는 3.1절에 발췌했다
• 모든 항목을 채울 필요는 없다. 자사와 가까운 「모델 시스템」을 고르고, 중요 항목부터 자사 실정에 맞게 조정해 가는 사용법이 전제되어 있다
• 비기능 레벨은 올릴수록 비용이 는다. 「그냥 높은 수준을 요구」하는 것이 아니라, 업무 영향에서 거꾸로 계산해 레벨을 고른다
• 정한 결과는 요구사항 정의 문서에 남긴다. 여기서 정한 전제가 견적 비교와, 운용 시작 후의 「말했다·안 했다」를 막는 데 효과가 있다

그림의 실선은 항상 성립하는 관계, 점선은 조건이 붙는 관계입니다(성립 조건은 상세 페이지의 관계별 설명에 적혀 있습니다). 관계 전체 목록(총 16건, 근거와 확신도 포함)과 주요 개념의 정의는 지식 맵 상세 페이지에 정리되어 있습니다(일본어). 데이터: JSON-LD / Turtle

2. 비기능 요구사항이란 ── 「돌아간다」와 「쓸 수 있다」 사이에 있는 것

기능 요구사항은 「수주를 등록할 수 있다」「장표를 인쇄할 수 있다」처럼, 시스템이 무엇을 하는가의 요구사항입니다. 개발 회의는 자연스럽게 이 이야기에 모입니다.

반면 다음 같은 질문은 기능 목록에 나오지 않습니다.

• 이 시스템은 몇 시부터 몇 시까지 돌아가면 되는가. 토·일요일은? 야간 배치 중에는?
• 장애로 멈췄을 때, 몇 시간 안에 복구하지 않으면 업무가 멈추는가. 데이터는 어느 시점까지 되돌리면 허용되는가
• 몇 명이 동시에 쓰고, 하루에 몇 건을 처리하는가. 5년 후면 데이터양은 얼마나 늘어 있는가
• 누가 감시하고, 백업을 받고, 장애 첫 연락을 받는가
• 기존 시스템 데이터는 어디까지 새 시스템으로 가져가는가

이것이 비기능 요구사항입니다. 까다로운 점은, 정하지 않아도 시스템은 일단 「돌아간다」는 것입니다. 문제는 운용이 시작되고 부하가 늘고 장애가 났을 때 비로소 드러납니다. 그 시점에는 서버 구성이나 설계의 뼈대에 걸리므로, 고치는 데 큰 비용이 듭니다.

3. 비기능 요구 등급이란

비기능 요구 등급은 비기능 요구사항을 둘러싼 발주 측과 개발 측의 인식 어긋남을 막는 것을 목적으로 IPA가 공개한 도구 모음입니다. 초판은 2010년 4월에 나왔고, 현재 최신판은 보안과 가상화(클라우드) 쪽 변화를 반영한 「비기능 요구 등급 2018」(2018년 4월 공개)입니다. 지금은 IPA 사이트의 아카이브 페이지에 있지만, 비기능 요구사항의 빠짐을 확인하는 기준으로 실무에서는 지금도 정석으로 쓰입니다.

구성은 다음 도구들입니다.

각 메트릭에는 단계적 레벨 선택지가 정의되어 있어, 「높다/낮다」 같은 모호한 말이 아니라 레벨 선택으로 요구를 표현할 수 있는 것이 특징입니다.

3.1. 레벨이란 무엇인가 ── 등급표 실물을 본다

「단계적 레벨」이라고 해도 감이 잘 안 오니, 실물을 보겠습니다. 레벨은 0부터 최대 5까지 6단계이며, 숫자가 클수록 구현 난이도가 올라가고, 대체로 개발·운용 비용도 올라갑니다. 다만 모든 메트릭이 6단계인 것은 아니고, 선택지가 3개(0~2)뿐인 항목도 있습니다.

예를 들어 가용성의 첫 항목 「운용 시간(통상)」(항목 번호 A.1.1.1)은 다음과 같이 정의되어 있습니다. 괄호 안 시간은 한 예이며, 레벨 선정의 조건 그 자체는 아닙니다.

「우리 시스템은 24시간 돌아갔으면 한다」는 막연한 바람이, 이 표 위에서는 「레벨 5를 고른다」는 구체적인 선택이 됩니다. 그리고 고르는 순간, 운용 교대 인력이나 이중화 구성 비용이 따라온다는 것도 같이 보입니다.

하나 더, 발주 측이 숫자로 말하기 쉬운 「가동률」(항목 번호 A.1.5.1)을 보겠습니다. 이쪽은 등급표 비고에 레벨별 연간 정지 시간 기준까지 적혀 있습니다.

「99%와 99.9%는 거의 같지 않나」 싶을 수 있습니다. 다만 연간 정지 시간으로 보면 87.6시간과 8.76시간, 꼬박 하루와 반나절이 안 되는 차입니다. 비기능 요구 등급의 진짜 효과는, 이 「말로는 가까운데 업무 영향은 10배」를 숫자로 나란히 보여 주는 데 있습니다.

덧붙여 등급표에는 모델 시스템별 기준 레벨도 이미 들어가 있습니다. 위 두 항목에서는 예를 들어 다음과 같습니다.

자사와 가까운 모델 열을 출발점으로, 「우리는 야간 배치가 있으니 한 단계 위」「그 대신 가동률은 여기까지는 필요 없다」처럼 올리고 내립니다. 이것이 등급표 사용법입니다.

3.2. 세 가지 모델 시스템

또 하나의 특징이, 시스템이 멈췄을 때 사회적 영향의 크기로 나눈 세 가지 모델 시스템입니다.

• 사회적 영향이 거의 없는 시스템
• 사회적 영향이 한정되는 시스템(기업 기간 시스템 등)
• 사회적 영향이 매우 큰 시스템(사회 인프라 등)

등급표에는 모델별 기준 레벨이 이미 들어가 있습니다. 즉 처음부터 논의를 시작하는 것이 아니라, 「우리는 이 모델에 가깝다」고 감을 잡은 뒤 실정에 맞게 올리고 내리는 사용법이 가능합니다.

4. 여섯 가지 대항목 ── 발주 측의 말로 옮기기

비기능 요구 등급의 6대 항목을, 발주 측이 답할 수 있는 질문으로 바꾸면 다음과 같습니다.

이렇게 보면 6대 항목의 대부분은 기술 질문이 아니라 업무 질문입니다. 「월말 청구 처리가 반나절 늦으면 무슨 일이 일어나는가」에 답할 수 있는 쪽은 개발사가 아니라 발주 측입니다. 비기능 요구사항의 주도권은 사실 발주 측에 있습니다.

5. 현실적인 사용법 ── 238개 항목을 채우려고 하지 않는다

항목 일람에는 238개 메트릭이 있지만, 전부 하나씩 논의하는 일은 중소기업 프로젝트에서는 현실적이지 않고, 이용 가이드도 그런 쓰기를 전제로 두지 않습니다. 전제된 흐름은 다음과 같습니다.

1. 모델 시스템을 고른다
   (자사 시스템은 어느 영향도에 가까운가)
        ↓
2. 등급표의 중요 항목에 대해,
   모델의 기준 레벨을 출발점으로 자사 실정에 맞게 조정한다
        ↓
3. 필요한 부분만, 항목 일람으로 상세화한다

중소기업 업무 앱이라면 2단계의 「중요 항목 맞추기」만으로도 효과는 충분합니다. 경험상 적어도 다음만큼은 요구사항 정의에서 문서로 남겨 두기를 권합니다. 글머리에 든 세 사례가, 모두 이 표의 어딘가를 건너뛴 탓에 일어났다는 점에 주목해 주십시오.

이때 빼먹으면 안 되는 것이 레벨과 비용의 트레이드오프입니다. 예를 들어 「절대 멈추지 않는 시스템」을 노리면, 서버 이중화나 감시 체제 때문에 비용이 크게 뜁니다. 「업무가 다음날 아침까지 기다릴 수 있으면 당일 복구로 충분하다」고 판단되면, 그 몫을 다른 데로 돌릴 수 있습니다. 비기능 요구 등급의 레벨은 요구를 올리는 도구가 아니라, 업무 영향과 비용의 균형을 이야기하기 위한 공통 언어로 쓰는 것이 맞는 거리입니다.

6. 계약·견적과의 관계

비기능 요구사항은 계약과도 바로 이어집니다.

먼저 견적 비교입니다. 비기능 전제를 맞추지 않은 채 여러 회사에서 견적을 받으면, A사는 이중화 구성, B사는 서버 1대로 견적했을 수 있습니다. 금액 차이가 구성 차이인지 예측이 헐거웠던 것인지, 발주 측은 가릴 수 없게 됩니다.

다음은 검수와 운용 시작 이후입니다. 응답 시간이나 백업 합의가 문서에 있으면, 「느리다」「예상 밖이다」라는 공방은 기준에 비춘 사실 확인으로 바뀝니다.

IPA의 「정보시스템·모델 거래·계약서」에서도 요구사항 정의 공정의 산출물로 비기능 요구사항을 문서화하는 것을 전제로 합니다. 요구사항 정의를 준위임으로 진행하고, 정해진 내용을 바탕으로 개발을 도급으로 계약하는 다단계 계약 흐름 안에, 비기능 요구 등급은 자연스럽게 넣을 수 있습니다. 계약 형태는 IPA 「모델 거래·계약서」 해설 글을 봐 주십시오.

정리

IPA 「비기능 요구 등급」의 핵심을 정리합니다.

• 비기능 요구사항은 「어느 정도 품질·조건으로 돌아가는가」의 요구사항이다. 정하지 않아도 돌아가지만, 운용 시작 후에 드러나 다툰다
• 비기능 요구 등급은 가용성, 성능·확장성, 운용·보수성, 이행성, 보안, 시스템 환경·에콜로지의 6대 항목·238개 메트릭을 단계적 레벨로 맞추는 IPA의 무료 도구 모음이다
• 레벨은 0부터 최대 5까지 6단계다. 예를 들어 가동률이면 99%(연간 87.6시간 정지)가 레벨 2, 99.99%(연간 52.6분)가 레벨 4처럼, 말로는 가까운 요구의 차이가 숫자로 나란히 놓인다(3장)
• 세 가지 모델 시스템의 기준 레벨을 출발점으로, 중요 항목부터 조정한다. 모든 항목을 채울 필요는 없다
• 6대 항목의 내용은 거의 업무 질문이다. 답을 가진 쪽은 발주 측이다
• 레벨은 올릴수록 비용이 는다. 업무 영향에서 거꾸로 계산해 균형을 고르고, 결과를 요구사항 정의 문서에 남긴다

「무엇을 만들 것인가」만큼, 「어느 정도 품질로 계속 돌아가게 할 것인가」를 먼저 정해 두는 것. 그것이 돌아가기는 하지만 쓸 수 없는 시스템과, 그 뒤의 다툼을 막는 가장 값싼 방법입니다.

참고 링크

비기능 요구 등급은 IPA 사이트의 아카이브 페이지에 있어 검색으로 찾아가기 어려우니 직접 링크를 둡니다. 모두 무료이며, 이용 조건 페이지를 거쳐 다운로드하는 형태입니다.

• 시스템 구축의 상류 공정 강화(비기능 요구 등급) ─ IPA 아카이브 안의 입구 페이지. 여기서 각 자료로 이어집니다
• 비기능 요구 등급 소개 페이지 ─ 도구 모음 구성과, 모델 시스템 선정에서 중요 항목 레벨 결정으로 가는 이용 절차 설명
• 비기능 요구 등급 본체(일본어판) 사용 조건 ─ 이용 가이드(해설편·이용편·활용편), 등급표, 항목 일람, 계통도, 활용 시트(Excel) 일체 다운로드. 먼저 받아야 할 것은 이것입니다
• 비기능 요구 등급 2018 이용 가이드 「활용편」 제2판 사용 조건 ─ 2019년 3월에 개정된 활용편
• 비기능 요구 등급 연수 교재 사용 조건 ─ 사내 공부에 쓸 수 있는 교재 일체
• 정보시스템·모델 거래·계약서 ─ 6장에서 다룬, 계약과 요구사항 정의의 관계를 다루는 IPA 자료

이 글 3장에서 인용한 레벨 정의와 연간 정지 시간 기준은, 위의 「본체(일본어판)」에 들어 있는 활용 시트(항목 번호 A.1.1.1 「운용 시간(통상)」 및 A.1.5.1 「가동률」)에 따릅니다.

업무 시스템 요구사항 정리로 막히신 분께

비기능 요구사항을 맞추려면 업무 실정(피크 시기, 데이터양, 멈췄을 때의 영향)과, 그것을 구현하는 시스템 구성 양쪽을 오가는 작업이 필요합니다.

합동회사 코무라소프트에서는 Windows 업무 앱이나 웹 시스템 수탁 개발·개수 상담 때, 이 글에서 소개한 관점에 따라 성능·운용·장애 시 동작을 요구사항 단계에서 함께 정리합니다. 「지금 시스템 처리가 점점 느려졌다」「갱신을 계기로 운용 합의를 다시 보고 싶다」 같은 단계부터도 상담받을 수 있습니다.

관련 기사

같은 태그를 공유하는 최신 기사입니다. 더 가까운 주제로 지식을 넓힐 수 있습니다.

관련 토픽

이 기사와 가까운 토픽 페이지입니다. 기사를 출발점 삼아 관련 서비스와 다른 기사로 이어집니다.

이 주제와 연결되는 서비스

이 기사는 다음 서비스 페이지로 이어집니다. 가까운 입구부터 확인해 주세요.

자주 묻는 질문

이 기사 주제에 대해 상담 시 자주 나오는 질문을 모았습니다.

비기능 요구사항이란 무엇인가요?

시스템이 「무엇을 하는가」(기능 요구사항)가 아니라, 「어느 정도 품질·조건으로 돌아가는가」에 관한 요구사항입니다. 예를 들어 시스템을 언제 쓸 수 있게 할 것인가(가용성), 몇 명이 쓰며 몇 초 안에 응답할 것인가(성능·확장성), 누가 어떻게 운용·보수할 것인가(운용·보수성), 기존 시스템에서 데이터를 어떻게 넘길 것인가(이행성), 어떤 방어를 할 것인가(보안), 어떤 환경에 둘 것인가(시스템 환경) 등이 해당합니다. 정하지 않으면 「돌아가기는 하지만 쓸 수 없는」 시스템이 되기 쉽습니다.

비기능 요구 등급은 무료로 쓸 수 있나요? 어디서 받나요?

IPA 웹사이트에서 무료로 다운로드할 수 있습니다. 등급표·항목 일람·계통도·활용 시트와 이용 가이드(해설편·이용편·활용편)가 한 세트이며, 최신판은 2018년 4월에 공개된 「비기능 요구 등급 2018」입니다. 지금은 IPA 사이트에서 아카이브로 분류된 페이지에 있지만, 비기능 요구사항의 빠짐 확인 기준으로 실무에서는 지금도 널리 쓰입니다.

238개 항목을 모두 정해야 하나요?

아닙니다. 메트릭을 하나하나 모두 논의하는 일은 이용 가이드에서도 전제로 두지 않습니다. 먼저 자사와 가까운 모델 시스템을 골라 전체 기준을 정하고, 등급표의 중요 항목을 중심으로 자사 실정에 맞게 조정한 뒤, 필요한 범위만 항목 일람으로 상세화하는 단계적 사용법이 나와 있습니다. 중소기업 업무 시스템이라면 중요 항목만 맞춰도 「정하지 않아서 생기는 다툼」의 대부분은 막을 수 있습니다.

비기능 요구사항은 언제 정해야 하나요?

요구사항 정의 단계입니다. 가용성이나 성능 목표는 서버 구성과 설계의 뼈대에 걸리므로, 개발이 진행된 뒤의 변경은 비용과 기간에 크게 영향을 줍니다. IPA의 「정보시스템·모델 거래·계약서」에서도 요구사항 정의 산출물로 기능 요구사항뿐 아니라 비기능 요구사항을 문서화하는 것을 전제로 합니다. 견적을 비교하는 단계에서 비기능 전제를 맞춰 두지 않으면, 금액 차이가 구성 차이인지 예측이 헐거웠던 것인지 판단할 수 없게 됩니다.

저자 프로필

기사 저자의 프로필 페이지입니다.

Go Komura

합동회사 코무라소프트 대표

Windows 소프트웨어 개발, 기술 상담, 장애 조사를 중심으로 재현이 어려운 장애 조사와 기존 자산이 남아 있는 프로젝트에 강점이 있습니다.