[카테고리:] 개발자 이야기

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

이 주제에 대해서는 좀 민감하고 해서 안적을까도 생각했는데…

몇번 뵙고 온라인에서 친하게 지내면서… 좋은 정보도 공유해 주시고, 가끔은 냉정한 지적도 해주시고 하면서 여러모로 가르쳐 주셨던 선배 개발자가 급성 심장마비로 돌아가셨습니다. (삼가 고인의 명복을 빕니다.)

그래서 너무 복잡한 데…. 아무래도 개발자와 건강을 안적고 방치하고 하기에는 여러모로 저 또한 감정이 복잡해져서… 일단 좀 적어봅니다.

전 지금까지 이렇게 선배 개발자들 네분이 과로사로 먼저 세상을 떠나는 걸 봤습니다. (이분들은 거의 명백한 과로사..) 그리고 나서 이번 선배의 급성 심장마비… 과로사 아닐까도 싶습니다만… 자세한 건 모르겠습니다.

그러나, 주변에 개발자가 다섯 분이 건강 이상으로 돌아가셨다는 거… 적은 숫자 아닙니다. 그중에는 과로사도 있습니다. 진짜 뭐라 해야 할지….

그 와중에 제가 알던 형님 중 몇몇 분들이 저더러 이렇게 살지 말고, 가망 있을 때 차라리 해외로 나가라고 하시더군요. 뭐 저도 그걸 보니 막막한 데다가 저 또한 좋은 상태도 아니고 그렇게 죽고싶지 않아서 미국행을 선택하였고, 미국에서 정착하기 위해 여러모로 고생하면서 살았습니다. (근데 막상 온 회사의 일이 미친듯 밤새지 않으면 어떻게 끝내기도 어려울 정도로 개판인 소스코드만 남아있을줄은 저도 몰랐죠…)

도중에 좀 이상한 이야기가 섞여있지만… 개발자들이 제일 가까이에서 겪을 수 있는 건강 이상상태의 결과는 의외로 과로사일 수 있겠다는 생각이 갑자기 들더군요. 당장 저만 해도 가만히 앉아만 있으면서 혈액순환 안된다는 걸 여러모로 지적받았고, 이미 순환기 계통 질환을 가지고 있습니다. 좀만 맘만 먹으면 얼마든지 급성 심장마비 혹은 심협증 등 순환기관 질병으로 급사할 수 있고, 그 원인이 과로에 의한 것이라면 저 또한 과로사가 될 수 있습니다. 저 말고도 개발자로 있으면서 여러모로 질병을 가지고 계신 분들이 많을껍니다. 혈압과 당뇨, 간 질환 뿐 아니라 여러모로 말이죠… 그리고 그 종점이 암 같은 큰 병이 아니라 의외로 과로사 같은 형태의 급성 사망으로 이어질 가능성에 대해서 여러모로 생각하게 되었습니다.

개발자로 계시면서 몸 건강해서 아무 문제 없으신 분들은… 제 개인적으로 보기에는 엄청 축복받은 것이라고 생각합니다. 이미 젊을 때부터 건강했던 것이고, 지금 회사에서 급하게 일 몰아쳐서 제아무리 밤새도 멀쩡하다는 것이잖아요. 하지만 제가 볼 때 대부분의 개발자 분들은 무리한 개발 과제 진행하느라 여러모로 지친데다가 일정도 촉박하게 일하고 하면서 여러모로 몸 망치고 있을 분들이 많다고 생각합니다. 건강하다 싶었던 분도 어느 순간 갑자기 돌아가시고 했던 것도 그렇고…

개발자와 건강 시리즈 적으면서 개발자의 건강을 헤치는 여러 가지 질환과 개발자가 건강에 대해서 신경쓰면서 여러모로 겪는 이야기들을 적어봤는데, 사실 여기서 생기는 작은 병들이 의외로 만성질환으로 이어지는 병으로 가기도 쉬울 뿐더러 그 병들을 돌연사를 일으킬 수 있는 유명한 병들로 번지는 걸 확인하니… 과로사라는 건 의외로 가까이에 있는 거 아닌가란 생각을 자꾸 하게 되네요.

회사에서 과로로 일하다가 죽어야지만 과로사라고는 하고 싶지 않습니다. 그렇게 과로로 하면서 알게 모르게 하나 둘 쌓여있던 것들이 어느 순간 확 터져서 견딜 수 없기 때문에 생기는 것이 과로사라고 생각합니다. 사실 당하기 싫으면 평소에 건강 관리 하나하나 할 수 있으면서 살아야 되는데… 그걸 위해서는 개발자들 또한 그런 시간을 만들 수 있어야 하고, 그를 위해 좀이나마 더 실력을 쌓고 자신의 일에 대해서 어느 정도 관리와 컨트롤이 가능한 수준 혹은 그런 곳에서 일을 하는 것이 그나마 건강 관리가 잘 되는 비결일 수 있겠다는 생각밖에 안드네요…

건강 관리 못하는 걸 개개인의 관리 미숙으로 몰아넣는 분들 많은데…. 제가보기엔 그건 이유도 안됩니다. 운동 싫어하는 개인적 성향 가지고 그렇게 몰아가는 거면 모를까 미친듯 일해서 잠잘 시간도 별로 없는 사람한테 잠잘 시간까지 쪼개면서 운동하라고 하는 건 그 사람 병신 만드는 소리밖엔 안되니깐요.

….이 글은 여러모로 좀 맘 복잡한 상태로 적어봤는데…

여러분들 또한 건강 관리 잘 하면서 개발합시다. 남은 사람들 슬퍼하는 걸 몇 번이고 보니 여러모로 맘 복잡하네요….