Skip to main content

소프트웨어의 요구사항

소프트웨어 개발자(software developer)로써 일을 하다 보면 기획자와 많은 시간을 보내게 된다. 여기서 기획자란 말은 소프트웨어의 요구사항을 만들어내는 사람이라고 봐도 좋겠다. 혹은 드물겠지만 기획자라고 부를 만한 사람이 없다면 소프트웨어를 사용하는 사용자를 떠올리기 바란다. 요구사항을 만들어내는 사람들은 개발자를 곤혹스럽게 하곤 한다. 그것은 근본적으로 개발자가 하고 싶지 않은 일을 시키기 때문이라고 생각한다. 개발자는 성능을 중시하고 코드가 얼마나 간결한지를 중시하곤 하는데 복잡한 요구사항들은 이런 코드를 지저분하고 복잡하고 느린 모습으로 바꾸곤 하기 때문이다. 하지만 자신의 소프트웨어가 살아 있는 한, 자신의 소프트웨어를 사용해주는 사용자가 있는 한, 요구사항이 있는 한 이러한 일은 끊이지 않을 것이다.

같은 요구사항이라도 기획자에 손을 어떻게 거치느냐에 따라 어렵고 시간이 오래 걸리는 것이 있는 반면 간단하면서 빨리 끝낼 수 있는 일도 있었던 것을 많이 보아왔다. '실력 있는 개발자라면 오래 걸리는 개발도 쉽게 끝낼 수 있을 않느냐?' 라고 반문하실 지도 모르겠다. 하지만 이건 실력하고는 별개의 문제라고 생각한다. 나의 경험을 비춰 봤을 때 똑같은 기능이라도 어떤 기획서는 작업하기 쉬웠던 반면에 어떤 기획서는 작업하기 힘들었던 적이 분명히 있었기 때문이다. 이것은 기능의 많고 적음을 얘기하는 것은 결코 아니다.

어려운 기획서의 가장 큰 부분은 기존에 이미 요구돼있던 기능의 기본적인 틀의 변경이 여러 번 번복되어서 가해지는 부분이다. 한번 이렇게 바꿔보고 또 아니다 싶으면 다르게 바꿔보는 식이다.

이것이 어려운 이유는 간단해 보이는 요구사항일지라도 소프트웨어 설계 전체에 대한 수정이 가해져야만 적용될 수 있는 부분이 있기 때문이다. 웹 어플리케이션을 예로 들면 대부분 데이터베이스와 밀접한 관계를 가지고 그것의 설계에 기초 하는 것들이 많기 때문에 데이터베이스의 설계가 심하게 변경 되어야만 했을 때 데이터베이스 레이어(Database layer)부터 프레젠테이션 레이어(Presentation layer)까지 수 많은 부분들이 변경되어야만 한다. 기획자는 기존 요구사항에 대한 수정 또는 요구사항 번복에 대해 충분히 신중해야 할 것이다. 사실 이것이 내가 실제로 일을 하면서 기획자들에게 가장 불만을 갖고 있는 부분 이기도 하다.

사실 기획자들이 이런 변경에 대한 요구를 끊임없이 해오는 이유는 고객의 요구사항을 제대로 파악하지 못해서 생긴 일이 대부분 이라고 생각한다. 일반 고객들이 바로 요구사항을 만들어내는 상황의 소프트웨어라면 이런 잦은 요구사항 수정에 책임은 요구사항을 제대로 파악하지 못한 개발자에게 있다 것이다. 또 기획자에 의도를 제대로 파악하지 못해 엉뚱한 것을 만들어 내고 있었다면 이것 역시 개발자 책임일 것이다. 그냥 한번 만들어보고 그게 아니면 또 바꾸는 식의 해결방법은 곤란하다. 하지만 이런 문제를 해결할 수 있는 방법은 얼마든지 있다.

프로토타입(Prototype)을 이용해 해결할 수 있다. 프로토타입이란 어떤 구조물이나 장비에 대하여, 형상이나 설계, 적합성 또는 성능 등을 평가하기 위해 만든 실물 크기의 모형을 말한다.(http://terms.co.kr) 즉, 기획자가(고객이) 무엇을 원하는지 제대로 모를 때 프로토타입을 빠르게 만들어서 보여주고 ‘이게 맞습니까?’ ,’이 정도면 되겠습니까?’ 이렇게 물어볼 수 있는 것이다. 요구사항이 명확히 파악된다면 그걸 기반으로 더 잘된 설계를 이끌어 낼 수 있을 것이다.

또는 그 소프트웨어를 가지고 일하는 사람들과 같이 지내 봄으로써도 해결할 수 있다. 요구사항을 제대로 파악하지 못하는 이유 중에 하나가 자신의 소프트웨어를 자신이 실제로 써보지 않아서 어떤 것이 어떻게 불편한지 제대로 알지 못해서 일 것이라고 나는 확신한다. 웹 메일 서비스라면 자신이 직접 웹 메일을 써봐야 어떤 점이 업무를 불편하게 하는지 알 수 있을 것이고 게임을 만든다면 직접 그 게임을 해봐야 어떤 점이 재미없는지도 알지 않겠는가?

나는 개발자들이 개발에만 열중할 것이 아니라 고객(또는 요구사항을 만들어내는 기획자)과 소통하는데 더 노력을 기울일 것을 권하고 싶다. 이것이 바로 자신의 소프트웨어를 성공 시킬 수 있는 진정한 one way 인 것이다. 코드가 깔끔한 소프트웨어라고 성공하는가? 자신의 소프트웨어가 사용하기 불편한 대신 코드가 깔끔하다고 광고할 생각인가? 심지어는 버그가 많은 소프트웨어가 다른 경쟁 업체들을 제치고 성공하기까지 하는 이유는 바로 요구사항을 다른 경쟁 업체들 보다 제대로 파악했기 때문이 아닐까?

Popular posts from this blog

클라우드 컴퓨팅(Cloud Computing) 기술 정리

1. 클라우드 컴퓨팅(Cloud Computing)이란?

클라우드 컴퓨팅에 대해서는 현재 매우 다양한 정의가 존재한다. 이 중 몇 가지를 정리하면 다음과 같다. 첫 번째 정으로 클라우드 컴퓨팅은 다양한 클라이언트 디바이스에서 필요할 때 언제든지 인터넷을 이용한 공유 풀에 있는 서버, 스토리지, 어플리케이션, 서비스 등과 같은 IT 리소스에 쉽게 접근할 수 있게하는 모델이다.

또 다른 정의로는 서로 다른 물리적 위치에 존재하는 컴퓨터들의 리소스를 가상화 기술로 통합해 제공하는 기술이라고도 생각할 수 있다. 개인적으로 클라우드 컴퓨팅의 개념을 이해는데 세일즈포스닷컴(www.salesforce.com)[1]이 만든 이 동영상[2]이 전반적인 이해를 돕는데 매우 유용하다. 아래 그림은 여러 대표적인 클라우드 서비스들의 사용 예를 보여주고 있다.



1.1. 클라우드 컴퓨팅의 장점[4]

사용자가 자신의 필요에 따라 무한정의 컴퓨팅 자원을 사용할 수 있다는 환상(Illusion)을 제공한다. 그러므로 사용자는 하드웨어와 소프트웨어 시스템을 제공하는 계획을 미리 세울 필요가 없다. 사용자는 작은 시스템으로부터 시작할 수 있고 시스템 자원에 대한 요구가 증가함에 따라 시스템 자원을 증가시키면 된다. 필요에 따라 짧은 시간을 단위로 (예를 들어 프로세서를 시간 당 또는 스토리지를 날짜 당) 사용하고 비용을 지불하면 되고 필요가 사라지면 자원을 더 사용하지 않을 수 있다.

1.2. 기존 클라우드 컴퓨팅 사례1.2.1. 아마존
EC2(컴퓨팅 서비스)Auto Scaling(자동으로 서버 생성 가능)Elastic Load Balancing(소프트웨어 로드벨런싱 기능)CloudWatch(모니터링 정보 제공)Amazon Elastic Block Store(EBS, 빠르고 안정적인 스토리지)Amazon Simple Storage Service(Amazon S3, 스토리지 서비스)SimpleDB(데이터베이스 서비스)
1.2.2. 구글
GFS(구글파일시스템, 대용량 파일 처리 가능 시스템)MapR…

규칙기반 전문가 시스템 (Rule-based expert system)

컴퓨터로 어떤 일을 시킬 때 보통은 명확한 규칙에 따라서 처리하게 된다. 그 이유는 아직 컴퓨터는 인공지능을 갖지 못하였다. 인간처럼 여러 가지 지식과 현상을 조합해 사고하지 못한다는 말이다. 그 때문에 사람이 컴퓨터의 능력을 이용해 어떤 일을 처리할 때는 일련의 규칙이 필요했다. 예를 들면 IF … Then … Else로 표현되는 규칙을 적용하는 것이다.

하지만, 실생활의 문제들은 이것들도 표현할 수 없는 것들이 너무 많다. 인간이 생각하는 거의 모든 것들이 이런 모호함의 집합이다. “오늘 날씨 너무 덥다. 시원하게 에러컨좀 틀어!”라고 했을 때 “너무 덥다.”, “시원하게” 등의 말들은 컴퓨터가 처리할 수 없는 것들이다. 몇 도로 온도를 유지했을 때 시원하다고 느끼는지 컴퓨터 자체만으로는 알 수가 없다. 컴퓨터는 정확히 수치화된 데이터만 가지고 처리하는 기계이기 때문이다. 이런 문제들을 처리하는 여러 방법의 하나인 규칙기반 전문가 시스템(Rule-based expert system)에 대해 얘기해 보겠다.

이처럼 컴퓨터가 처리해야 하는 문제들은 어떤 분야의 전문가가 처리하던 것을 컴퓨터가 대신하는데 의미가 있다. 나는 이것을 전문가의 지식을 처리한다고 정리한다. 그리고 전문가라고 불리는 사람들은 어떤 지식에 대해 규칙을 만들 수 있는 사람이고 규칙이란 앞서 얘기했던 대로 IF … Then … Else 형태로 표현할 수 있는 것을 말한다.

규칙기반 전문가 시스템은 관련주제에 지식이 풍부하고 관련 문제를 푸는데 능숙한 주제 전문가(domain expert), 전문가 시스템을 테스트하고 규칙을 추론할 수 있는 지식공학자(knowledge expert), 전문가 시스템의 개발 리더인 프로젝트 관리자(project manager), 프로그래머(programmer) 그리고 최종사용자(end-user)로 구성되어 있다.

또한, 규칙기반 전문가는 기반지식(knowledge base), 데이터베이스(Database), 추론 엔진(Interface engine), 해설설비…

인터넷이 우리 사회에 미치는 영향

믿기 어렵겠지만 몇 년 전만 해도 간단한 정보를 검색하기 위해선 백과사전이 필요했고 적은 분량의 백과사전에서 찾을 수 없을 땐 도서관에 가야 했고 또 작은 도서관에서 찾을 수 없을 땐 좀더 큰 도서관으로 가야 했었다. 과연 지금의 중학교, 고등학교 학생들은 과연 몇 명이나 이래야만 했던 사정을 이해해줄지 모르겠다.

하지만 이제는 사정이 달라졌다. 인터넷의 등장으로 예전처럼 정보검색에 수많은 시간과 노력을 쏟지 않아도 더 쉽게 더 좋은 자료를 검색할 수 있고 그를 여러 가지 형태의 미디어로 접할 수 있는 시대가 되었다. 예전에 ‘팀 버너스 리(Tim Berners-Lee)’ 가 처음으로 구체적으로 주장했던 하이퍼미디어(Hypermedia)와 그로 이루어진 인터넷으로 인해 우리 생활은 많이 변화했고 또 이제는 없어서는 안될 것으로 멀티미디어 환경으로 진화해 왔다는 사실은 아무도 부인하지 못할 것이다.

사실 인터넷의 등장만으로도 우리에겐 막대한 영향을 끼쳤다. 하지만 여기서 인터넷의 멀티미디어로서의 역할을 배제한다면 그 영향력을 전부 얘기하지는 못할 것이다. 멀티미디어로서의 인터넷은 위에서 얘기한 것처럼 빠른 정보검색은 물론이고 보다 효율적인 방법으로 정보전달의 기능을 가지고 있다.

대학교 1학년 때 처음 컴퓨터를 공부할 때 일이다. 네트웍에 대해 공부하고 있었는데 마침 네트웍을 설명하고 있는 동영상을 인터넷에서 발견했다. ‘The dawn of the Net’ 이라는 동영상 이였는데 네트웍 패킷이나 라우터, 라우터 스위치 등등 전체적인 네트웍에 대해서 알기 쉽게 설명한 동영상이었다. 이 동영상은 너무 쉽고 직관적이어서 누구라도 이것을 본 사람이라면 네트웍에 대해 모두 안 것 같은 착각을 하게 만들 정도였다. 하지만 대략적인 네트웍에 대해서 안다고 해서 전문가가 되었다고 말할 수는 없을 것이다. 간단해 보이는 현상 뒤에 숨겨져 있는 지식들을 모두 이해하고 설명할 수 있을 때 비로소 전문가라 부를 수 있을 것이다.

이런 멀티미디어적인 환경은 대부분에 사람들에게 보다…