「몇 초 안에 응답하면 만족스러운가」를 정하지 않고 넘어가지 않으려면 ── IPA 「비기능 요구 등급」으로 비기능 요건을 정리한다

「화면 전환이 느리다는 지적을 받았는데, 계약서에도 사양서에도 응답 시간에 관한 규정이 없다」

「야간 배치가 아침까지 끝나지 않게 되었는데, 데이터가 몇 년 만에 얼마나 늘어날지 아무도 예측하지 않았다」

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

시스템 개발 트러블이라고 하면 기능에 대한 인식 차이가 먼저 떠오르지만, 실제로 운용이 시작된 뒤에 다툼이 벌어지는 원인은 이러한 기능 이외의 요건, 즉 비기능 요건을 정하지 않고 넘어간 데 있는 경우가 적지 않습니다.

이렇게 정하지 않고 넘어가는 것을 막기 위한 공적인 도구가 IPA(독립행정법인 정보처리추진기구)의 비기능 요구 등급입니다. 이 글에서는 그 구체적인 내용과, 중소기업 업무 시스템에서의 현실적인 사용법을, 발주자도 이해할 수 있는 말로 정리합니다.

1. 먼저 결론

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

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. 3가지 모델 시스템

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

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

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

4. 6가지 대항목 ── 발주자의 언어로 번역하기

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

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

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

항목 일람에는 238개의 메트릭이 있지만, 이를 전부 하나하나 논의하는 것은 중소기업의 안건에서는 현실적이지 않으며, 이용 가이드도 그런 사용법을 상정하고 있지 않습니다. 상정되어 있는 흐름은 다음과 같습니다.

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

중소기업의 업무 앱이라면 단계 2의 「중요 항목 조율」만으로도 효과는 충분합니다. 경험상 적어도 다음 사항만큼은 요건 정의에서 문서로 남겨 두기를 권합니다. 서두에서 든 3가지 사례가 모두 이 표의 어딘가를 건너뛰었기 때문에 일어났다는 점에 주목해 주십시오.

이때 잊지 말아야 할 것이 레벨과 비용의 트레이드오프입니다. 예를 들어 「절대로 멈추지 않는 시스템」을 목표로 하면, 서버 이중화나 모니터링 체제 때문에 비용이 급격히 늘어납니다. 「업무가 다음 날 아침까지 기다릴 수 있다면 당일 중 복구로 충분하다」고 판단할 수 있다면, 그만큼을 다른 곳으로 돌릴 수 있습니다. 비기능 요구 등급의 레벨은 요구를 높이기 위한 도구가 아니라, 업무 영향과 비용의 균형을 논의하기 위한 공통 언어로 사용하는 것이 올바른 거리감입니다.

6. 계약·견적과의 관계

비기능 요건은 계약과도 직결됩니다.

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

다음은 검수와 운용 개시 이후입니다. 응답 시간이나 백업에 관한 합의가 문서로 남아 있으면, 「느리다」「예상 밖이다」라는 식의 소모적인 논쟁은 기준에 비추어 사실을 확인하는 일로 바뀝니다.

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

정리

IPA 「비기능 요구 등급」의 포인트를 정리합니다.

• 비기능 요건은 「어느 정도의 품질·조건으로 동작하는가」에 관한 요건이다. 정하지 않아도 동작은 하지만, 운용 개시 후에 표면화되어 다툼이 된다
• 비기능 요구 등급은 가용성, 성능·확장성, 운용·보수성, 이행성, 보안, 시스템 환경·친환경성의 6대 항목·238개 메트릭을 단계적인 레벨로 조율하는 IPA의 무상 도구 모음이다
• 레벨은 0부터 최대 5까지의 6단계다. 예를 들어 가동률이라면 99%(연간 87.6시간 정지)가 레벨 2, 99.99%(연간 52.6분)가 레벨 4인 것처럼, 말로는 비슷해 보이는 요구의 차이가 숫자로 나란히 드러난다(3장)
• 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 소프트웨어 개발, 기술 상담, 장애 조사를 중심으로 재현이 어려운 장애 조사와 기존 자산이 남아 있는 프로젝트에 강점이 있습니다.