하지 말아야 되나? – 사용자한테 사용자 경험을 묻는다…?

…..리치 클라이언트 프로그램 개발은 두 종류가 있다. 아예 처음부터 새로 개발하는 경우와 기존의 프로그램을 아예 새로운 버전으로 업그레이드 하는 경우다. 대부분은 후자의 경우가 많다. 전자는 정말 설계가 튼튼해야 한다. 그래서 어느 정도 정형화된 형태에서 수정하는 형태로 사용자 경험을 만들어내는 경우가 많다보니 후자에 가까운 케이스로 되는 경우도 많이 존재한다.

뭐, 어떠한 형태가 되었던 간에 기존 시스템을 바탕으로 구현해야 할 의견을 찾게 된다. 이때에 사용자에게 기존 시스템에서 사용하기 어려웠던 점을 묻는 경우가 많은데, 내가 보기에는 물어서는 안된다고 본다. 이런 경우에는 대부분 부분적인 개선에 대해서 하나 하나 이야기를 하게 되는데, 사실 이런 경우에는 근본적인 해결이 아니라 그냥 자잘한 노가다 혹은 그만도 못한 작업을 해서 개선이 되는 요소가 존재하지 않게 된다.

예를 들어서, 여러 단계로 작성되는 웹 폼 화면을 개발하는데, 사용자에게 어려운 점을 물었더니 “2단계에서 물어보는 입력에 마지막 단계는 해당하지 않는데 이걸 그냥 놔둬야 하는지, 필수 입력인지 혼란스럽다.” 라고 해보자. 이런 경우에는 그냥 이 입력은 필수가 아닙니다 하는 형태로 설명을 달아주고 하는 형태로도 수정을 할 수 있다. 그러나 이런 식의 해결이 과연 근본적인 해결이었을까? 과연 이 마지막 입력이 정말 필요한 입력인지 아닌지를 묻고 필요한 입력이면 이전 단계의 값을 확인하여 동적으로 입력 폼을 보여주는 것이 더 좋은 해결책이 될 수 있는 거 아닐까? 표시되지 않는다면 사실 입력할 필요 자체가 없는 것이 된다.

하지만 이 일련의 과정을 사용자가 대답한다고 해서 좋은 해결책이 나올 수 있었을까?

사용자의 작업이 어느 화면에 어느 조작에서 막히거나 문제가 되는지를 알아내기 위해서 사용자가 사용하는 것을 캡쳐하거나 영상으로 찍어두고 분석하면 이런 해결책에 대한 해결 방법 중 하나가 되기도 한다. (고객센터에서 계속 원격으로 확인하면서 하는 게 이런 작업임…) 이런 식으로 사용자가 어떤 조작을 진행하였고, 어떤 조작을 요구하는지를 생각하면서 업무 순서와 내용을 분석한다. 그러면 부분적인 분석이 아닌 전체적인 분석을 하고 생각하면서 최선의 해결책을 찾는 것으로 이어지게 된다.

그리고 이런 건 사용자에게 물어서 확인할 수 있는 영역이 아니다. 사용자는 사용하다가 그냥 불편한 것에 대해서만 제공할 뿐, 이런 내용에 대해서 깊게 생각할 기회나 경험 자체가 없다. 리치 클라이언트에서의 사용자 경험에 우러난 조작성은 일련의 흐름을 갖고 있다. 그렇기 때문에 전후의 화면 사이에서도 깊은 의미를 가지고 있다. 이런 걸 특정 화면, 특정 기능에만 주목해서 보게 되는 사용자의 시점에서는 일련의 전체적인 흐름에 대해 보지 못해서 프로그램 개선을 망치게 될 수 있다.

그리고 이건 사실 사용자 뿐 아니라 영업 관점에서도 여러모로 말 나오는 이야기일 수 있다. 영업 입장에서는 사용자쪽을 이해 혹은 설득하는 듯한 작업 수순을 통해서 설명하고 그에 따른 이야기들을 듣고 오다보니 사용자쪽 시선에 갖춰져서 시선이 좁아지는 경우도 생기기 마련이기 때문에다. 그래서 영업과 개발이 싸우기도 하고…./먼산

하지 말아야 되나? – 사용자 경험을 무조건 다 집어넣을 수는 없다. 요건이 아니다.

오늘은 블로그 글을 여러모로 적으면서 볼일 보는 걸 기다리고 있다만… 리치 클라이언트 관련 이야기를 하다 보면 여러모로 하고 싶었던 이야기가 있었다. ;ㅅ; 그 중에서도 사용자 경험에 대해서도 여러모로 하고 싶은 말도 있다. 나도 과거에 실수했던 내용이기도 하고 해서..ㅠㅠ

리치 클라이언트가 주목받는 가장 큰 이유는 보다 나은 사용자 경험을 표현하여 개발할 수 있다는 것이다. 사용자 경험에 대한 부가 설명을 간단하게 하면 인지 심리학자 도널드 A 노먼씨가 미국 애플에서 UI를개발하고 있었을 때 만든 개념으로, 이를 통해 다른회사의 제품과 차별을 두기 위해 생각한 개념인데 이게 널리 퍼졌다.

이 개념에 중심에 있어서 외관을 먼저 디자인 하는 것이 아니라 사용자 시점에서 사용하기 쉽게 한다는 점에 목적을 두고 설계를 하는 사용자 중심의 설계를 기반으로 하고 있다.

리치 클라이언트에서는 지금까지 본 적도 느껴본 적도 없는 조작 위주의 UI를경험할 수 있다. 그러나 이것을 구현하기 위해서는 사용자에게 어떤 서비스를 어떻게 제공해 주어야 감동을 줄 수 있는지에 대해 충분히 검토한 후에 디자인 해야 하는 것이 중요하다. 이러한 디자인을 사용자 경험 디자인이라고 하며, 사용자의 분석, 컨셉의 명확화, 테스크 분석, 실물 모형을 촬영한 동영상 제작, 프로토 타입 제작, 목표 명확화 등 여러 스텝을 밟고 해야 한다. 자세한 건 UX관련 서적들이 자세히 써놓았다.

근데 이러한 작업들은 노력도 시간도 많이 들기 때문에 기본적으로 비용 증가로 연결된다. 그래서 승산 없이 사용자 경험을 마구잡이로 포함시켜서는 안된다.

오히려 사용자 경험에 대한 건 기능적 요건이 아니라 부가가치적 개념으로 들어가야 한다.

사용자 경험은 리치 클라이언트에서 반드시 필수인 것은 아니다. 즉, 기능 요건이 아니라 부가 가치인 것이다. (이걸 헷갈리면 진짜 프로그램 개발 산으로 간다)

응용 프로그램에서 사용자 경험을 적용하면 사용자의 지원 및 비용을 줄일 수 있거나 조작 오류를 감소시킬 가능성이 높다. 경우에 따라서는 몇 번 사용해 보고 기분 좋은 경험을 고객에게 전달해 줌으로써 제품을 계속 사용하게 만들는 효과를 가져올 수 있다. (애플은 이걸 정말 잘 아는 기업이다. 그리고 요즘의 마이크로소프트도 이에 대한 도전을 많이 하고 있다.) 이러한 부가 가치의 금액을 정확하게 산출하는 것은 일반적으로는 어려운 일이다. 그러나 가능한 한 금액으로 환산하여 사용자 경험을 구축하는 데 드는 비용과 비교하여 도입 유무를 잘 검토하는 것이 중요하다.

그리고 이 글 작성하면서 도중에 적었다만, 이걸 정말 잘 하는 기업이 애플이라고 했다. 그리고 앱스토어에 있는 수많은 앱들 중 에디터의 초이스로 선택된 앱들 또한 그런 것들을 가지고 있다. (애플 디자인 어워드에 있는 앱들 또한 마찬가지..) 그 앱들 중에서는 비슷한 기능을 가지면서도 더 기능 많은 앱들이 앱스토어에 있는 거 같은데도 뽑힌 이유는 바로 그 앱들이 가지는 고유의 사용자 경험이 애플의 에디터들을 만족시킨 것이다. 그래서 앱 개발에 있어서 여러모로 난이도가 올라간 것들이 없지 않게 존재한다.

하지 말아야 되나? – 화면 디자인이나 화면 이동, 변경에 대해서 이게 최선이다라고 생각하고 하면 안된다.

지금은 되게 당연하게 받아들이게 된 이론인 MVC, MVVM 같은 녀석들을 왜 이용하는지에 대해서는 솔직히 이런 걸 먼저 가르치면서 해야 한다고 생각은 하는데… 사실 이런 내용은 현업에서 하다보면 나중에 되어서야 알게 되는 참 힘든 내용인 듯 하다.

개발 초기 단계에서 회의 끝에 초기의 UI 모양이나 조작에 대한 사양은 정해진 거 같으면서도 정해져 있지 않다고 보면 된다. (즉, 나중에 미친 듯 갈릴 수 있다는 것이다.) 그래서 리치 클라이언트 응용 프로그램의 경우에는 어플리케이션 설계 시에 계층 구조를 가지고 개발을 하는 것이 좋다. 전통적으로 보는 계층 구조는 다음과 같은 것들이 있다.

  • 자산: 주로 이미지 소재 같은 가공된 내용물들임.
  • 상호작용: 이벤트 등에 대한 시스템이 반응하는 녀석
  • 컨트롤, 레이아웃: 그래픽 컨트롤들과 그를 배치한 레이아웃
  • 이벤트: 사용자 인터페이스에 대한 조작 관련 이벤트들
  • 비즈니스 로직: 응용 프로그램이 처리할 처리 내용이나 그에 대한 기준 데이터들

이런 것들을 우리는 어디서 비슷한 녀석을 본 거 같다. 바로 이 글의 맨 앞에서 이야기 한 응용 프로그램 개발할 때 프로그램 구조에서 이야기하는 디자인 패턴들, MVC, MVVM 같은 녀석들 설명 듣고 할 때 많이 본 것들이다. 리치 클라이언트에서는 뷰에 대한 요구와 수정이 주로 일어나기 때문에 뷰에 대한 것과 뷰를 구성하고 실행하는 것에 대해서 분리하여 처리하는 여러 과정들 중 일부들… 바로 이런 것들 땜에 나오는 이야기인 거다.

여기서는 좀 전통적인 로직에 맞춰서 설명을 하겠다. (규링은 이런 내용에 기반한 걸 먼저 배운 관계로…ㅠㅠ) 최하층의 비즈니스 로직과 이벤트는 사실 개발 도중에 변경 사항이 나오기 상당히 드문 것들이다. 이게 바뀐다는 건 사용하는 데 있어서 필요한 비즈니스 로직 자체가 바뀌었다는 내용이 되기 때문이다. 그리고 이것들은 중간에 있는 컨트롤, 레이아웃에 의해 호출되어 결과만 제대로 나와주면 되기 때문에 컨트롤과 레이아웃에 대해서는 어느 정도의 사양만 제대로 갖춰지기만 해도 충분히 맞춰 개발할 수 있다.

문제는 상위에 있는 자산, 상호작용 부분들인데, 이 부분들에 대해서는 할 말이 없다….;ㅅ; 사실 끝의 끝까지 가서도 바뀔 수 있는 녀석들이다. 그래서 이 영역의 코드들은 마지막의 마지막까지 그냥 “튜닝한다” 라는 내겸을 가지고 가야 한다. 그래서 코드 분리의 개념이 엄청나게 잘 되어있고 그걸 당연한 듯이 설명하고 그걸 잘 이용하기 위한 프레임워크들을 이용하는 것이지만….ㅇㅂㅇ;;;;

하지 말아야 되나? – 어플리케이션의 리치화, 함부로 하면 안된다. 잘 계획해서 해야 한다.

전글에서 리치 클라이언트에 대한 이야기를 하면서 리치화에 대한 이야기를 간단하게 했다. 그러면서 디자이너 이야기를 적었는데….

리치화는 바로 디자인과 사용자 경험에 대한 결합을 통해 어플리케이션을 더욱 돋보이게(제일 비슷한 뜻일듯..) 하는 작업이라고 보면 된다. 나도 이걸 어디 책에서 본 내용 기반으로 설명하려 하니 어려운데… 흔히 말하는 디자인, 사용자 편의성따위 없는, 누가 봐도 개발자가 자기 생각만 하고 짠 듯한 그런 응용 프로그램 보면 이게 뭐야? 하는 게 리치화가 안된 프로그램이다.

리치 클라이언트 응용 프로그램 개발에는 많은 비용과 시간이 들어간다. 나의 천적 오씨가 화면만 3년 걸려(노는 시간 합쳐서) 화면만 만들고 튄 것도 좋게 보면 프로그램을 리치화 시켰다고 할 수 있다. (그렇다고 그양반이 잘했다는 거 아니다.)

또 이걸 이용하는 기술에 따라서는 읽기나 별도의 렌더링 처리에도 시간과 자원이 들어가는 일이 발생한다. 그렇게 해서 런타임 환경과 버전 관리하고 하는 운용 관련 시간도 추가로 들어가게 된다. 그래서, 리치 클라이언트는 사실 만들었다고 해서 사용이 쉽거나 관리가 쉽거나 하는 게 아니다. 여기에 특히 기존 어플리케이션에 대해서 리치 클라이언트화를 검토할 때에는 사용자의 사용 환경(PC 사양)이나 기존 응용 프로그램의 익숙도를 충분히 고려한 작업을 해야 한다.

규링의 간접 경험을 예로 들면, 건강 정보 관리하는 어플리케이션을 만들 때 좀 더 리치 클라이언트화하여서 입력 기능을 좀 더 상향화(라고 할 수 없긴 했다만…)하고 싶다는 이야기를 받았따. 기존 화면은 그냥 기본 제공되는 UI 프레임워크에 이미지와 약간의 애니메이션만 넣어서 프로토타입화 하고 있던 녀석인데, 이걸 입력하는 화면하고 보여주는 화면하고의 느낌을 안드로이드 화면과 비슷하게 만들라는 것이었다. 당시 난 걍 iOS 4 버전대에 그 회사에서 안드로이드로 이미 개발되어 있던 녀석을 아이폰에서 똑같은 화면과 기능으로 개발을 하는 녀석이었는데… 화면 뒤로가는 버튼 없는 것부터 시작해서 여러모로노 안드로이드만 생각하고 만들어진 녀석을 아이폰 사용자가 그나마 덜 이상하게 생각할 수 있도록 하는 거였다만.. 안드로이드 개발자한테 가서 이상한 기능을 더 추가하고 하는 바람에 쓸데없는 부하가 걸리고 했다. 게다가 몇몇 기능은 아이폰 3GS 화면에서 처리하기 좀 무리가 가는 녀석도 있었다.

그래서 프로그램 이용에는 방해가 되고, 난 시간이란 시간 다 빼먹고, 이걸 나름 잘 해보겠다고 해서 리치화 시킨 아이디어였지만 결국은 업무를 방해한 녀석이 되었다. 그래서 안드로이드 개발하던 선배와 이야기 한 결과, 특정 화면만 좀 더 디자인 더 넣고 해서 리치해 보이게 만드는 그런 작업을 했었다…

이런 거 잘못 생각하면 진짜 쓸모없는 쓰레기 만들기 딱 좋은 환경 된다. ㅠㅠ

하지 말아야 되나? – 리치 클라이언트를 개발할 때, 실물 모형과 프로토타입을 혼동하면 안된다.

하지 말아야 되나 시리즈를 작성하다 보면 여러모로 용어들이 막 튀어나올 것인데, 그 중에서는 진짜로 이런 용어가 있어? 하는 듯한 것이나 버즈워드(여러곳에서 막 이용되는 용어)에 대해서 혼동하는 경우를 많이 보게 될 것이다. 지금 것도 그 중 하나라고 보면 된다.

리치 클라이언트라는 것은 사용자가 헤메지 않고 조작할 수 있는 것은 물론이면서 인터페이스 측면에서도 사용하기 좋은 클라이언트를 가리켜서 말하는 용어이다. 여기서 말하는 리치화에 대해서는 이 다음에 별도로 설명할 시간이 있을 것이다.

근데 이 리치 클라이언트 형태의 응용 프로그램을 개발할 때에는 사용자의 경험을 살려 동작하도록 하는 것을 일반적으로 보게 된다. 근데 최적의 조작을 생각하다 보면, 지금까지 해본 적 없는 사용자 조작을 만들어야 하고, 이를 위해 디자이너와 사용자(실제 사용자, 혹은 발주를 넣은 고객사 사람. 발주 내용을 확인하고 최종 승인하는 대상이 될 것이다.)와의 인식을 맞춰야 한다. 이때, 디자이너는 일회용을 전제로, 단시간에 작성하여 자신이 만든 이미지를 상태에게 전달하여 실물 모형을 만들어 쓰기도 한다. 그러나 한편으로는 프로토타입은 실물 모형(모델)을 기반으로 사용하여 확장시킨 UI를 컨셉으로 구현한 것을 이용한다. 그러다보면 실제 사양에 대한 확장 개념으로 이용할 뿐, 그래픽이나 조작 방법에 대해서는 많은 노력과 시간을 들여서 계속 수정해 나가야 한다.

이러한 경우, 양쪽의 차이를 이해 안하고는 그냥 검도 단계로 들어가게 되면 그대로 싸우게 된다. 검토하는 과정에 이르러서야 어느 정도 서로간의 관점차이가 보이기 시작한다. 이때 잘 해결해서 실물 모델에 의한 프로토타입의 이해를 디자이너에게 의뢰해서 처리할 경우에는 이러한 실패가 덜 들어갈 수 있으나, 그냥 프로토타입을 요구하게 되면 뜬금없는 수준의 디자인을 받게 되고, 이는 비용에 대한 낭비로 이어지게 된다.

글이 어려운데… 간단히 말하면 디자이너에게도 어느 정도의 프로토타입과 실물 모델에 대한 이해를 시켜야 한다는 뜻이다.

…..아 근데 언제부터 이런 내용 생각할 때 딱딱한 내용부터 적기 시작한 거지….ㅠㅠ

하지 말아야 되나? – 고객의 실제 데이터나 파일을 주고받는 거… 해도 되는 건가?

교과서적 내용으로는 사실 이런 상황은 있으면 안된다고 한다. 협력사나 고객에게 요구사항 분석 등을 하거나 할 때, 실제 데이터가 들어있는 엑셀이나 워드 파일을 받아서 그 파일 내용을 가지고 개발하고 하는 경우가 빈번하게 있다. 나도 그런 적 실제로 있고….

흔하게 일어날 수 있는 일이다. 근데 하면 안된다고 한다. 진짜 교과서적인 내용으로는 하면 안된다고 한다. 프로젝트 매니지먼트 관련된 곳에 이런 말들이 주로 말들이 나와있다.

교과서적 이야기는 좀 들으면 이런 반응하기 쉽다. ㅇㅅㅇ;;;

근데 그 이유는 좀 간단한 이유이다. 파일 안에 해당 고객이 이용하는 중요한 정보나 정보에 관한 노하우(고유 함수정보 등), 고객 정보, 작성자 정보나 부서 등 회사 정보 등 여러 정보가 속성값 혹은 함수 매크로 등으로 남아있을 수 있기 때문에 하면 안된단 거다. 즉 보안적인 측면 때문이다. 그래서 pdf 혹은 그림 파일로 하여 속성들을 전부 지우고 보낼 수 있도록 하여 보안에 신경쓰라는 좀 고전적인 내용이다만…..

당연히 이렇게 반응할꺼다….

보안 관련된 사항이면 첨부터 주고받고 하는 데 조심하란 말이다….

그 외에는 그냥 개발에 필요한 일반 자료의 경우에는 자료의 형식이 있으면 형식 정보를 받으면 처리하기 더 편할 것이고, 그리고 그에 따라 왔다갔다 해도 되는 데이터들이면 좀 받아도 문제 없다. ㅡㅅㅡ

하지 말아야 되나? – 걍 외부 솔루션 사서 해. 도입하면 개발 기간 줄어들 수 있어. -> 응? 누가그래?

(미친 잡소리로 시작합니다.)

옛날 옛날~ 아주 먼~ 옛날에~ 호랑이가 담배 피다가 폐암으로 곪아 죽던 시절에~

선인 개발자들께서는 말씀하셨지.

“걍 외부 솔루션 도입해서 붙여. 그러면 그 기능 덜 개발해도 되잖아.”

라고 하시면서 ocx, active x 등 여러 플러그인이나 솔루션으로 개발하는 프로그램을 떡칠을 하셨고…

개발 세상에 약간의 편함을 추구하며 즐겁게(?) 개발하시고…

세상은 그들의 솔루션으로 YES만 누르면 다 해결되는(?) 세상으로 발전을 하였었지만…

도입한 솔루션, 플러그인들이 하나 둘 개발이 중단되고…

회사들은 어느순간 없어지면서 프로그램 업데이트를 하면 안되는 상황이 도래하고…

윈도우 xp와 ie 6를 평생 써야 하는 세상이 당연한 세상은 저물어가고…

그분들의 하나 둘 개발 세상에서 하산하시고 닭과 기름과 함께하는 인생을 하시고…

윈도우는 7, 8, 10이 나와 세상이 바뀌어가고…

아이폰과 안드로이드가 또 다른 세상을 보여주면서…

그 솔루션들은 더 이상 사용될 일 없이 다른 솔루션들이 새로이 새로이 개발되어가고..

세상은 하나 하나 발전되거 가고 있다.

라는 쓸데없는 글로 시작해봅니다.

SI 개발과 연구에 좀 계시던 분들 중에서는 당시에 상용 솔루션들의 기술들만큼 개발하기 힘들어서 상용 솔루션이나 플러그인은 사서 쓰시는 걸 당연하게 생각하시는 분들이 좀 계신다. 그만큼의 성능과 개발 시간을 덜 써도 된다고 생각하기 때문이다.

그리고 그와는 별개로 요즘은 추가로 오픈소스를 접한 친구들의 경우에는 오픈소스 솔루션을 가져다 쓰면서 어느 정도 좀 수정하고 그러면 어느 정도 성능이나 개발 시간을 먹고 들어간다고 생각하는 친구들도 존재한다.

이들의 공통점은 바로 외부 솔루션을 도입해서 솔루션 개발을 하면 개발 기간을 단축하고 어느 정도의 성능을 보장할 수 있다는 것이 해당하는 전제 조건이다. 그러면 내부에서 처음부터 개발하는 것보다 개발을 빨리 할 수 있다는 거… 개발자들이 되게 쉽게 생각하는 것이다.

그러나, 내부 개발에서는 해당하는 솔루션에 대한 조사를 통해서 요건 정의가 되는 부분에 부가적으로 추가되는 기능이 있다는 것을 잊고있게 된다. 바로 도입하려는 솔루션의 적합성과 차이점에 대한 분석 작업이다. 이 작업이 도입되는만큼, 오히려 내부에서 전부 개발하여 솔루션을 만들어내는 것이 외부 솔루션을 도입하는 것보다 개발 기간이 단축되는 경우도 적지 않게 발생하게 된다.

이에 대해서 당연하게 이야기 되는 경우와 실제로 엔지니어들이 생각하는 것에 대해서 정리해서 왜 이런 상황이 발생하는지에 대해서 좀 생각해 보려고 한다. 사실 좀 고민을 해야 하는 상황이 온다.

좀 교과서적인 이야기를 적어보자면 몇 가지가 있다. 첫 번째로는 솔루션의 기본 기능이나 데이터 구조, 소스코드 등을 상세하게 파악해야 하고 이걸 반드시 실 데이터를 사용하여 검증하면서 내부 구조를 파악해야 하는 데 있어서 많은 시간이 필요하게 된다는 점이다. 사실 이건 좀 게을이 하면 안되는 중요한 내용이다.

두 번째 내용으로는 기능 정의 결과를 바탕으로 어느 정도의 표준 기능을 사용할지, 이걸 기능을 추가로 개발해야 할 지, 그리고 그에 따른 적합성과 차이점을 분석할 때 사용자나 경영자 등 다양한 사람들의 이해 관계까지 조정하고 논의되어야 하는 데 시간이 필요해진다. 이로 인해서 그들이 사용하는 데 있어서 제약 사항이 발생하는 경우도 있을 수 있기 때문에 이를 결정할 수 있게 해줘야 한다.

세 번째 내용으로는 의외로 잊기 쉬운 메인 모듈의 안정적 동작에 방해가 되는지 안되는지를 검증해야 한다. 어느 정도의 부가 기능이라면 모를까 메인 기능에 대해 어느 정도의 결합과 그에 따른 안정적 동작을 위한 개발 기간이 추가로 들어간다.

네 번째 내용으로는 위의 적합성 및 차이점 분석으로 인해 추가 기능이 필요하게 되면 이것이 메인 모듈에 기능이 더 늘어나야 하는 내용이 될 수 있게 된다는 것이다. 메인 모듈을 개발하는 데 있어서 이로 인해서 개발 기간이 더 늘어날 수도 있기 때문이다.

다섯 번째 내용으로는 테스트 기간에 대한 추가적인 소모 시간이 생긴다는 것이다. 이미 완성되어 있는 것이 있다고 해서 그걸 테스트 하는 것이 필요 없는 것은 아니다. 우리가 필요로 하는 기능대로 돌아가지 못해서 이상한 값이나 결과를 만들어 내는 것이 외부 모듈이라면 이것 또한 여러모로 문제가 되고 이를 해결하기 위한 시간이 소모된다. 또한 사용되지 않는 기능이라 할 지라도 기능으로 들어가 있기 때문에 전부 다 테스트를 하긴 해야 하는 상황도 발생한다.

마지막으로 기존 데이터를 마이그레이션(이전, 이행)하기 위한 작업이 필요하면 그에 따른 추가 기간이 필요하게 된다. 마이그레이션 데이터가 도입된 솔루션에 적합하게 되어 있다는 것은 있을 수 없다. 반드시 어딘가에서 변경 작업이 필요할 수 있고, 이를 위해 많은 시간이 들어간다. 이를 데이터 정화(data cleaning) 작업이라고 한다.

근데 이런 상황들이 있는데도 불구하고 개발자들은 왜 이런 생각들을 예나 지금이나 가지게 되는 걸까..? 사실 옛날에는 잘 모르겠다. 그냥 개발하기 어려울 거 같아서 보증된 걸 이용하여 개발하고자 하는 심리가 있지 않았나 싶기도 하다. 근데 그게 대부분이 유료라서… 여러모로 돈 들어가고 돈 문제 로 이어지고 하다보니 여러모로 좀 힘든 상황을 만들어서 그렇지….ㅡㅅㅡ

근데 요즘은 오픈소스 솔루션 플러그인들이 상당이 많은 모듈화가 이루어져 있다. 그레서 메인 모듈의 기능을 헤치는 것보다는 해당하는 자료나 기능 중 일부 기능에 대해서는 특정 플러그인, 솔루션을 이용하여 빠르고 깔끔하게 만들어내고 그걸 조합해서 만들어내는 작업들이 이루어지고 있다보니 갖다 쓰는 것에 대해서 별 의심을 하지 않고 쓰게 되는 것도 없지않아 있게 되는 듯 하다.

그러나 솔루션에 추가해야 할 기능이 너무 많다면 이 모든 것들에 대해서 맞아 떨어지거나 그렇게 만들기 쉽게 된 솔루션이라는 것이 존재할 수 없게 된다. 그럴 경우에는 내부에서의 개발과도 좀 비교를 해봐야 할 것이다. (특히 오픈소스들..) 그리고 어느 방법이 더욱 효율적이고 좋은 선택일지에 대해서 고민을 하고 그에 따라 도입을 해야 한다. 안그러면 돈날리면서 개발하게 되고 여러모로 속아픈 상황을 끌어안고 개발해야 하는 상황들이 발생할 수 있다.

하지 말아야 되나? – 솔루션 개발에서 우선순위 상위에 부가기능이 섞이면 안된다.

이건 좀 제목이 어려우려나…. 어려운 이야기는 아니다.

패키지 솔루션을 개발할 때, 사실 컨설팅 경험이 있던 없던 간에 개발 단계에서 중요한 녀석이 있다면 바로 개발의 우선순위를 두는 것이다. 사실 기능은 이런 저런 기능들 다 요구된다. 그리고 그 중에서 우선순위를 정해서 해야 할 텐데, 부가 기능(없어도 되는 기능이지만 요구사항에 의해서 새롭게 혹은 확장되어 만들어진 기능들. 사원의 출결 관리 기능이 개발의 주 기능인데 여기에 더해서 사원의 출결 이외에 교육 수료내용을 관리하거나 한다면 그런 것들은 부가 기능이 될 것이다.) 보다는 주 기능(솔루션의 본래 역할을 하는 기능. 사원의 출결 관리라면 사원 정보와 사원의 출근과 퇴근 정보에 대해서 기록하고 관리하는 기능이 될 것이다.)의 개발하는 데 프로젝트의 리소스를 우선적으로 두고 시작해야 한다. 즉 해당하는 솔루션 패키지의 마스터 데이터나 인증 방법, 각종 파라미터, 설정 내용, 메인 모듈 설계에 대한 안정화가 가장 기본이 되어야 한다. 그리고 이 기능이 프로토타입으로 만들어져야 한다. 그 다음에 부가적인 기능들을 하나 둘 만들어 나가는 것이 중요하다.

이렇게 적으니 뭔가 되게 당연해 보인다. 당연한 이야기를 왜 굳이 이렇게까지 적어야 하냐고 물을 수 있을 것이다.

왜냐면 메인이 되는 모듈들이 개발이 완료되어 안정화까지 된 후에, 부가 기능을 개발하다 보면 어딘가에서 메인 모듈 자체에서도 모순점이 발견되어 메인 모듈이 수정되고 할 수 있다. 실제로 테스트 단계에서 트랜잭션이 원활하게 동작하지 않거나 추가 처리에 대해서 연산 결과에 이상한 현상이 일어나는 경우가 생겨서 메인 모듈부분까지 다 검토해야 하는 상황이 일어나기도 한다. 이러한 이유는 본래 기능과 부가 기능 중 어딘가에서 문제를 일으키고 있는 것이라는 내용이지만 사실 어디서 문제가 일어나는지 판단하기 어려운 문제이다. 그냥 각각을 개발하면서 각각에 대한 테스트 케이스는 다 만들어겠지만 실제로 이 모듈들을 붙여보니 문제가 터지고 하는 건 여러모로 발생할 수 있다. 이에 따른 테스트 프로젝트 또 만들어서 해보고 해보고 하다보면 어떻게든 알아내겠지만… 일단 여러모로 쉬운 일은 아니다. 예상 이상의 시간을 잡아먹는 일이 발생한 것이므로….

게다가 이게 개발하는 패키지 솔루션이 규모가 크게 되면 하루라도 빨리 개발해야 하므로 일정 단축을 위해서 부가 기능을 같이 개발하고 그럴 수 있다. 이건 개발자 뿐 아니라 매니저들까지도 프로젝트 초기 단계에서 아예 부가 기능을 포함하여 일정을 막 짜고 그렇게 될 수 있다. 일정이라는 이유만으로….

생각만 해도 체한다….

이러다가 뭐 하나 꼬여서 맞냐 아니냐를 따지게 되면…. 그 뒤에 생길 지옥은 생각도 하기 싫다…

그러나 일단 프로젝트 도입쪽에 대해서는 메인 모듈을 만들어서 어느 정도 안정화를 시키는 것에 중점을 두면 부가 기능에 대해서는 프로젝트 관리에 따라 다르겠지만 일단 프로젝트 전체에 대한 실패를 하진 않게 된다.

가장 기본적이고도 당연한 내용이지만, 사실 의외로 맞추기 힘든 일이기도 하다. 특히 자기 솔루션을 개발하면서도 머리가 여럿이 되거나 하면 아주 쉽게 발생할 수 있다…ㅠㅠ

하지 말아야 되나? – 납품 문서만 남겨두면 된다?

이건 정말 어려운 이야기다…. 개발자들은 사실 문서 쓰는 거 싫어한다. 안다 잘… 그래서 여러모 이건 좀 골때리는 내용일꺼다. 그래도 그나마 개발 좀 막 하면서 느낀 걸 이야기해보려 한다.

“문서는 납품 대상이 되는 최종 문서만 남기면 된다.” 라는 건 개발하다보면 여러모로 듣는 이야기다. 사실 진짜 바쁘기 때문에 개발하면서 문서까지 쓰고 그러려면 진짜 힘들다.

게다가 그넘의 애자일 개발 방법론에 따르면 개발 문서보다는 소프트웨어가 중요하다는 항목이 있다. (이거 적으면서도 솔직히 좀 머리 아프다.) 이 말 그대로 받아들여서 소프트웨어 소스코드만 중요하다고 생각하면 진짜 안되는데…. 안되는데….

애자일을 잘못 알아들은 인간들은 이런 표정 지을꺼다 분명…. 진짜로….. (그넘의 오씨라던가…)

그리고 슬프게도, 실제로 프로젝트 중간중간에 작성했던 모든 문서에 대해서 버전까지 관리하면서 있는 개발 현장은 거의 없을 것이다. 한국에서는 학위논문(특히 박사학위 혹은 연구노트 쓰고 있으면 그거라도 되겠네…), 정부 프로젝트 외에는 거의 없을꺼라고 장담한다.

많은 개발 현장에서 소스코드는 형상관리가 되고 있지만 문서의 경우에는 형상 관리가 되지 않는 것이 일반적이다. 그나마 위키라도 되어 있으면 칭찬해야 한다고 해야하나…;ㅅ; 테스트 시나리오나 테스트 데이터 또한 마찬가지일 가능성이 높다. (단 테스트는 테스트 프로젝트 별도로 계속 만들어서 테스트가 더 많다면 그나마 다행일지도..) 근데 여기에 추가로 개발 기간까지 짧아서 시간도 없다면..? 더 이상의 내용은 생략한다.

하지만, 아키텍쳐 설명서나 회의록 등 납품하지 않아도 되는 중간 성과물에 대한 형상관리는 굉장히 중요하다. 괴거 버전의 문서가 남아 있으면 왜 이런 아키첵쳐가 되어있는지, 왜 이런 사양으로 되었는지, 프로젝트 중간 중간의 의사 결정에 대한 이유라던지를 알 수 있다. 그것은 운영 이후에 유지 보수 과정에서도 도움이 된다. 특히 개발할 때의 다양한 상황을 이해하기 위해 중간 성과물 문서에 대한 형상 관리는 상당히 중요하다.

스타트업이나 중소기업에서는 개발자가 적은 데다가 그 개발자들이 그대로 가기 때문에 이걸 더더욱 작성 안한다. 그 개발자가 알 것이라고 생각한다. 그러나 그들도 사람이다. 그들의 기억도 한계가 있다. 그리고 그게 몇 번씩 뒤집어지면… 제대로 기억 못할 가능성 높다.

초기 개발지 짧아지면서 점점 유지보수에 관한 업무가 중요하게 여겨지므로 문서 등의 내용을 관리하는 것이 상당히 중요해지고 있다. 그리고 그걸 굳이 문서 이외의 방법으로 남기는 방법들 또한 다양해지고 있다. 문서들을 일일이 다 수작업으로 관리한다면 솔직히 엄청 힘든 내용들이긴 하다. (근데 그렇게 해야 하는 곳들도 있긴 하다…ㅠㅠ) 그렇지만 우리는 형상관리 툴들에 대해서 여러모로 널리 퍼져있고 지원되는 기능들도 다양하다. 그러므로 중간 결과물에 대해서 관리하는 것에 대해서는 여러모로 꼭 하자.

하지 말아야 되나? – Use Case를 상세하게 적는 것에 관하여…

쓰고 싶었던 시리즈의 내용이다. 잡소리 그만하고 이건 바로 시작할 것이다.

요즘 내가 기술 문서를 정리하면서 기능 요구조건에 대한 use case(유스 케이스)를 정리하고 분석하여 설계한 설계서를 찾아내었다. 이걸 보면서 내가 배웠던 내용이면서 다른 사람들이 했던 실수가 기억나서 블로그에 적어봤다. 보통 많은 사람들이 유스 케이스를 적으면서 비즈니스 케이스에 대해서 하나하나 다 추가하거나 if then 같은 로직수준까지 넣는 경우도 있는다. 이런 정보는 사실 요구조건에 대해서는 불필요한 정보가 상세화되는 케이스가 될 수 있다.

요구조건 분석 문서를 가지고 여러 의견이 나뉘는 건 어쩔 수 없다. 왜냐면 이건 상세화의 레벨을 어디까지 해야 되느냐에 따라서도 개발 프로세스를 담당하는 사람에 따라서 다르게 받아들이기 때문이다. 어느 아키텍트는 분석 마비(analysis paralysis), 즉 상세화 하지 않으면 불안하다면서 모든 유스 케이스에 구축을 위한 목적을 표편하는 것보다 기능 자체에만 집중을 하는 경우가 생긴다.

그러나 실제로 유스 케이스를 상세하게 작성하면 분석하고 설계할 때 오히려 방해가 된다. 실행 조건과 종료 상태 정도만 정확하게 작성하면 사실 그걸로도 끝난다. 그런데 왜 그러질 못할까..?

잘못된 유스 케이스는 메인 시나리오에서는 문제가 없지만 대체 시나리오, 변경 정보, 비즈니스 룰까지 포함되어 있다. 이는 개발 프로세스 문서에서의 정보의 혼재와 버전 관리를 힘들게 하며, 서로간의 결합도가 너무 높아지는 구조를 그대로 가지고 개발 단계에서 개발을 하게 되므로 프로그램 또한 나중의 유지 보수가 상당히 힘들어지게 된다.

그래서 올바른 유스 케이스를 작성하는 것은 메인 시나리오, 대체 시나리오, 변경 정보에 대해서는 전부 어느 정도 구분해서 작성하고 있으며, 시나리오 분석할 때에도 불필요한 비즈니스 부분(비즈니스 룰)에 대해서는 별도의 카탈로그화 해서 작성하게 된다. 특히 비즈니스 룰의 경우에는 동일한 비즈니스 분야라 할지라도 해당하는 회사에 따라 룰이 다르게 적용될 수 있는 부분이므로 이 부분은 확실하게 나눠서 처리하지 않으면 안된다. 별첨 꼭 해야 하는 이유이기도 하다.