학부생 시절 소프트웨어 공학 과목에서 겉 핥기식으로나마 배웠던 것이 엊그제 일 같은데.
나이 들고 회사에서 교육받으려고 하니 정말 어렵게 느껴진다.
이참에 소프트웨어 아키텍트로서 역량도 키우고, 배운 내용을 정리할 겸 짤막하게 글을 남기려고 한다.
요구공학(Requirements Engineering)은 무엇인가 ?
요구공학은 소프트웨어 집약적 시스템의 목적과 사용 맥락을 식별하고, 커뮤니케이션하는 활동의 집합이다.
… 강의안에 적혀있는 설명이었는데 잘 모르겠다.
우선, 요구공학 이라는 단어의 맥락을 한번 살펴보고 싶다.
네이버 사전의 정의에 따르면, 요구의 정의는 아래와 같다.
받아야 할 것을 청하는 일. 그것이 요구이다.
즉, 고객은 자신이 받아야 할 것(소프트웨어)를 요구하고, 그 요구를 공학적인 프로세스로 추상화하는 일을 요구공학이라고 할 수 있을 것이다.
고객이 원하는 소프트웨어를 설계하고 구현하기 위해, 무엇을 해야할까?
우선, 고객이 가지고 있는 문제가 무엇인지 파악하고, 그 문제를 해결하기 위해 어떤 기능이 필요한지를 명세해야 할 것이다.
단순히 요구사항만 잘 받아적으면 될까 ?
개발자는 보통 자신이 몸 담고 있는 도메인 지식에만 정통한 경우들이 많다.
이해관계자들은 소프트웨어 개발자와 같은 도메인을 공유하고 있을 수도 있지만, 보통은 도메인이 완전히 다른 경우들이 많다.
그리고, 보통 이해관계자들 또한 본인이 원하는것이 정확히 무엇인지 알지 못하는 경우가 많다.
다들 이런 그림 한번 본 적 있지 않은가 ?
바보같다고 생각할지 모르겠지만, 본인의 삶을 잘 돌아보면 알 것이다.
본인도 그런 애매모호한 스탠스를 취하며 살아왔을 수 있다는 것을. (나 역시 내가 진정으로 원하는것이 무엇인지 잘 모르고 선택하거나 행동했던 적이 적지 않았던 것 같다.)
이런 이해관계자들로부터 그들이 원하는 것을 도출하고 정리하기 위해서는 커뮤니케이션 스킬이 필수이고, 늘 열린 마음으로 다른 도메인에 대해 배우고 수용할 준비가 되어있어야 한다.
문서를 예쁘고 맛깔나게 쓰는것도 중요하지만, 결국 사람의 문제를 정확히 정의하고 그것을 주어진 환경과 제약 안에서 해결하고 맞춰나가는 역량이 더 중요하고, 이를 달성하기 위한 과목이 요구공학이다.
현업에선 제품 기획이나 고객사 요구, 실제 운영하는 조직의 요구, 보안 요구, 갑자기 들어올 수 있는 추가기능에 대한 요구, … 물 밀듯이 뒤섞여 들어오기 마련이다.
대충 고객이 뭘 원하는지 물어본 뒤, 주먹구구식으로 대충 설계해서 구현하게 된다면 나중에 큰 재앙을 맞이하게 될 것이다. (그런 경험 많지 않은가?)
이런 재앙을 피하기 위해선, 실제 업무에 착수 전 요구공학에서 중요하게 다루는 고객의 요구사항을 수집하고 분석하는 일에 꽤나 힘을 써야한다.
이 활동이 지루하고 현학적으로 느껴지더라도, 제대로 해두면 나중에 설계를 헤집어 엎거나 프로젝트를 부러트리는 일이 줄어들 것이다.
교안에선 전체 프로젝트의 5~10% 정도 투자하는것을 추천하고 있다.
거 내가 해봐서 아는데~ 지금 거기에 쏟을 시간 따윈 없어!
어이 김씨! 헛소리 하지 말고 와서 코딩이나 해!
라고 윽박지르는 내부 이해관계자들이 있을 수 있다.
하지만 요구공학이 수반되지 않은 설계는 필연적으로 기술부채(Technical debt)를 지게 될 것이고, 그 이자는 해가 지나면 지날수록 매우 무거워진다.
고객이 뭘 원하는지 확실히 알기 위해, 기능 요구사항(Functional Requirements), 비 기능 요구사항(Non Functional Requirements)을 정확히 구분해야 한다.
기능 요구사항: 실제 문제를 해결할 수 있는 기능을 뜻한다. 예를 들면, “전화 앱에서 상대방의 전화번호를 누른 뒤, 통화 버튼을 눌러 상대방에게 전화를 걸 수 있는 기능” 을 기능 요구사항이라 부를 수 있을 것이다.
비 기능 요구사항: 기능 요구사항의 품질을 만족하기 위한 정량적, 정성적인 제약조건을 뜻한다. 예를 들면, “전화 앱에서 전화번호를 입력 후, 통화 버튼을 누르면 0.1초 이내에 전화를 걸 수 있도록 해야한다.” 를 비 기능 요구사항이라 부를 수 있을 것이다.
좋은 요구사항은 추상적이면 안 되며, 완전하고 일관되고, 가능하면 측정 가능해야 한다.
요구공학 활동을 하다 보면, 산출물들이 제법 나오는데, 이 산출물 간 빠진 부분들이 있거나 모순된다면 올바른 요구공학 활동을 진행한 것이 아니라고 할 수 있다.
이런 상태로 프로젝트를 진행하게 되면 결국 고객이 원하는 소프트웨어를 만들지 못하게 된다.
요구사항 분석을 제대로 하지 못한 채 프로젝트를 진행하게 되면, 요구사항 오류 수정 비용은 눈덩이처럼 불어나게 된다.
예를 들면, “로그인 기능이 있어야 한다.” 정도만 대충 잡고 개발에 들어가면 나중에 SSO, 2FA, 다중 인증, 소셜 로그인, 로그인 실패 시 잠금 정책 등등 … 여러가지 기능적, 비기능적 요구사항들이 붙게 되면서 처음 (대충)했던 설계가 부서지게 된다.
한 번 해야할 일을 두번 세번 네번 하다가 프로젝트는 부러지고 결국 심신이 지쳐 회사와 개발을 그만두게 될 수도 있단 것이다.
나름대로 강의안을 보며 공부했던 요구공학의 정의와 중요성에 대해 주저리 주저리 떠들어보았다.
다음 포스트에선 요구공학에서 다루는 주요 프로세스들을 한번 더 세부적으로 파악하고, 여유가 된다면 각 산출물들을 정리해보고자 한다.