S/W 개발에 대한 몇가지 생각 (01)

필자도 어느덧 S/W 회사에서 개발을 맡은지도 10년이 되었다. 뭐, 정확히 따지자면, 실제로 20년은 된거 같다. 중/고등학교때에도 개발을 해왔으니깐... 아마추어로서 10년, 그리고 직업인으로 10년, 이 즈음해서 개발에 대한 개인적인 생각을 몇개 적고자 하며(다분히 굉장히 주관적인 사실임을 미리 알려둔다), 당연히, 국내 S/W 혹은 새로 입문하려고 하는 분들에게 조금이나마 도움을 주고자 하는 마음으로 정리하였다.

 

우선 S/W 개발에 대한 몇가지 생각 (01)은 개발자 뿐만 아니라 기획자나 경연진까지 포함할 수 있음을 알려둔다. 다음글인 S/W 개발에 대한 몇가지 생각 (02)는 보다 개발자 측면에서의 글임을 알려둔다. S/W 개발 방법론은 시리즈로 구성되므로, 서로 내용이 연관된 것이 많을 것을 미리 알려둔다.

무엇이 목적인가?

몇백년동안 수학자들을 괴롭혔던 "페르마의 마지막 정리"처럼, 뭐든지 가장 어려운 문제중 하나일 것이다. 물론, 이는 딱히 정해진 답도 없는것 같다. 이 답을 찾기 위해 여태까지 고민해 왔고, 그리고 앞으로 노력할 거지만... 일단, 확실한 것 하나는, "모두를 이롭게 하는"이 들어가야 한다고 본다.

S/W 특징상, "stakeholder(이해관계자)"는 "요구자"와 "제공자" 그리고 "사용자"로 나눌수 있을 것이다. 물론, 그 3개는 좀더 세밀한 분류가 가능할 것이다. 이는, 비단, S/W 뿐만 아니라, 다른 산업에도 마찬가지일 것이다. 여하튼, 앞서 말한 "모두를 이롭게 하는"에 "모두"는 위 3개 요소에 해당될 것이다. 다시말해, "요구자", "제공자" 그리고 "사용자" 모두 스스로 이롭게 해야 하는 S/W의 생산, 그것이 목적을 이루는 주요한 부분이 되어야 한다고 생각된다.

우리의 건국 이념도 "홍익인간"이 아니던가. S/W도 "모두에게 이로운"이 된다면, 세상이 좀더 좋아지지 않을까. 즉, 어떤 가치 판단이 필요할 때, 예를 들어, "기능 A의 INPUT은 A0이며, OUTPUT은 A1이며, 이는 기능 B의 INPUT으로 전달된다"와 같은 요구사항이 있을 때, 과연 이러한 기능 A의 가치 판단, 즉, "기술적 가능성 판단"을 고려하기 이전에 "모두에게 이로운"것인지의 판단이 우선해야 한다는 것이다. 즉, 기술적으로 가능성이 있어도, 이롭지 못하다면, 이는 불필요한 기능일 것이다. 또한, "기술적 가능성"은 희박해 보이지만, 이롭다면, 이는 어떤 수단을 고려해서라도 생성해야 한다. 물론 "기술적 불가능"이라면 제외겠지만... 여기서 "이롭"다고 하는 것은 모든 stakeholder를 대상으로 한다. 즉, 임의의 집단, 즉, "요구자"만 이롭다면, 그것은 고려대상에서 제외하도록 한다.

 

여하튼, 최종의 목표는, make the world better, 이것이며, 모든 가치 판단의 최우선 기준이 되어야 한다고 본다. 이러한 가치 판단을 가장 잘 활용한 회사가 Apple이지 않을까?

지금 무엇을 하고 있는가?

앞서, 홍익인간, 즉 모두를 이롭게 하는것이 "목표"라 하였다. 그런데 그것이 과연 일상적으로 잘지켜 지는지는 좀더 두고볼 일이다. 지금 하고 있는 프로젝트나 혹은 소소한 유지보수 작업들은 과연 "모두를 이롭게" 하는지를 한번쯤 반문 해봐야 한다. 특히 "갑"과 "을"이 명확히 구분된 국내 it 환경에서 이는 꽤나 민감한 이슈중 하나일 듯 하다. 

누군가만 + 가 되고 나머지가 - 된다면 이는 장기적으로 좋지 못한 결과가 발생하는것을 자주 봐왔었다. + 의 크기가 작더라도 모두에게 도움이 된다면 시간이 지날수록 그 합한 양은 전자, 즉, + 가 한쪽으로 쏠리는 구조보다 훨씬 크게될 것임을 다들 알고 있을텐데 말이다. 

어떻든 "지금 무엇을 하고 있나?"를 생각해보기 바란다. 아무리 생각해도 그다지 쓰이지 않을 기능이라면 과감히 하지 않아도 된다고 본다. 일반적으로 3개월(혹은 6개월)동안 사용하지 않은 물건은 과감히 버려도 살아가는데 아무런 문제가 없다는 글을 읽은적이 있다. S/W도 마찮가지일거 같다.

"요구자"의 어긋나고 무지한 요구조건도 매우 중요한 이슈이지만, "공급자"의 아무 대안없이 수행하는 경우도 바르지 않다고 생각된다. 요구자는 어떻든 내용을 잘 모른다. 어찌보면 관심도 없는 경우도 많다. 이런 상황에서 산출된 요구조건은 실제 "다른 의미"인 경우일 수 있다. 공식적이지 못한 "사람의 언어"로 정보가 교환되니, 어쩔수 없는 문제이다. 허나, 중요한건, 부정확해 보이는 "언어상 의미 자체"를 그냥 "투덜"대며, 힘들게 제공한다는 점이다. 그러면서 악순환은 시작되는 것이다. 그 악순환을 깰 수 있는건, UML이나 개발 방법론이 아니라 바로 "커뮤니케이션"이라고 본다. 정확하고 명확한 의미를 교환하도록 하는 서로간의 커뮤니케이션, 이것이 가장 핵심일듯 하다. 그것이 잘 지켜지면, "아, 내가 하고 있는 일이 정말 의미있는 일이군."이라고 생각이 들 것이다.

"지금 이렇게 해 놓으면 나중에 뭔가 쓰임이 생길것이다!!!"의 함정

이것도 앞선 "무엇을 하고 있는가?"와 유사할 수 있다. 다만, 이 경우는 stakeholder가 다소 다를 것이다. 요구자가 보통 회사의 내부인인 경우가 많을 것이다.

몇년전의 web 2.0에서 최근의 big data 같이 서구의 it에서는 트렌드를 마구 마구 쏟아내고 있다. 문제는 이러한 것들은 "기술"이라기 보다는 "논리"에 가까운데 이를 기술로 해결하려고 한다는 것이다. 예를 들어, 아무런 대안이나 전략없이 data만 쌓아두는 경우가 많을 것이다. 물론, "언젠가 쓰일때가 생길거다"라고 자위해 보지만 기필코 쓰임은 없을 것이다. 결국 debre나 garbage가 된다. 그 구축을 위한 비용은 결국 기업의 손해가 된다. 그렇다고, 그것의 운영을 위한 know how등은 그다지 잘 축적되지도 않았다. 흔히, 그 요구자는 트렌드를 따르는 것이라 말하면서, big data는 전자신문을 통해 알고 있지만 "data mining"에는 전혀 관심 없거나 아예 그 뜻조차 모룰 것이다. 이러니 실패할 수 밖에. 이와 유사하게 "나중에 어떻게 되겠지" 주제로 수많은 무의미한 프로젝트가 힘겹게 진행되고 있을 것이 눈에 선하다.

이윤도 마찬가지이다. 우선 "이렇게 많들어 놓으면 분명 나중에 이윤이 발생할 것이다"라고 약속했지만 결국 그 끝은 실패가 되리라. 물론, 구글같은 거대 기업에서 장려되는 80:20 규칙으로 야기된 수많은 프로젝트들도 있을 것이다. 그 중에서는, 하다 보니 이윤(혹은 기타 목적)에서 잭팟이 터지는 경우도 실제 많다. 허나, 이는 거대기업에서 가능한 일이거나, sub job같은 개념으로 접근되어 그 실패의 비용자체가 낮게 사작된 것이다. 또한, 그 실패의 경험이 공유되는 문화가 있으므로, 향후의 더 큰 사업의 초석이 되기도 한다. 그렇지만 국내의 it 문화는 아직 그렇게 성숙하지 못하고, 또한 main job으로 주로 진행되어 그 실패의 맛은 매우 쓰거나 자칫 치명적이기도 하다.

결론은 그러하다. 즉, "어떻게 되겠지"는 결국 그 상태로 끝난다는 것이며, 이를 방지하기 위해서는 철저한 사전 검토와 시나리오 작성, 그리고 stakeholder간의 확실한 이해와 설득이 이뤄져야 한다는 것이다. 이러한 전략없이, 우선 "코딩"부터 시작한다면 설사 성공한다 하더라도 그다지 바람직해 보이지 않는다.

 

기능을 추가할 것인가? 확장할 것인가? 의 딜레마.

요구사항 분석, 설계, 개발, 테스트, 그리고 유지보수로 이뤄진 개발 프로세스에서, 유지보수 기간중 무엇을 하는지는 꽤나 중요할 수 있다. 이 기간동안 보통 기능의 확장 보다는 기능의 추가가 익숙한 상황으로 다가온다. 다음은 손쉽게 기획할 수 있는 대표적인 방법중 하나인 기능 대조표이다.

 

	기능1	기능2	기능3	기능4	기능 5	market share	참고
제품a	o					5%	국내기업
제품b	o	o				10%	국내기업
제품c	o	o	o		o	30%	국내기업
제품d	o	o	o	o		50%	외국기업(world best)
제품e	o					5%	우리회사
제품e 2.0	o	o	o	o	o	NA	우리회사. 차기 제품

 

기획자(어떻게 보면 요구자)는 모든 기능을 지원하는 공격적인 기획안으로 3년내 market share 1위를 달성하겠다고 한다. 과연 기획대로 성공할까? 3년동안 다른 제품은 가만히 놀고 있지는 않을터. 결국 3년뒤에는 어떻게 될까? 보통 10% 이내로 유지되다 drop되는 경우가 허다할 것이다. 그리고, 그 기획자는 유사한 방식으로 다른 기획안을 짜고 있을 것이다. 어떻든, 기업은 "일을 해야"하고, "돌아 가야"하니깐... 여하튼, ROI 계산도 하겠지만, 마케팅이나 개발, 운영비용에 따른 이익을 거둘지도 의문이다.

 

약간은 암울하고 negative한 예를 들었는데, 그렇다면, 다들 "그럼 뭐 해야 하나? 가만히 앉아 놀고만 있을 수 없지 않느냐?"라고 반문할 수 있을 것이다. 나는 이런 상황에서 하나 얘기 드리고 싶은건, "자신없고 불필요한 기능을 더하기 보다는, 현재 가장 잘 할 수 있는 기능을 더 확장해 나가 보세요'라고 일침을 놓고 싶다.

 

위와 같은 "기능 대조표"의 함정에서 빠져 나와, 지원하지 않는 기능 2, 3, 4, 5를 지원하기 위해 노력하는 대신, 기능 n이라는 새로운 column을 만드는데 노력해야 한다고 본다. 추가될 column이 1개이든 100개가 되든, "모두를 이롭게 하는" 기능을 추가한다면, 그 갯수는 중요하지 않다고 본다. (실제, 기능 1~5중 많은 부분은 '모두를 이롭게 하는' 기능은 거의 없을 수 도 있다. 업체간의 경쟁으로 인해 서로서로 불필요한, 소수의 수요자만 원하고, 다수의 제공자는 고통을 준 기능들이 대부분일 수 도 있다. 어떻든, 주위를 잘 둘러보고, 조금더 차분하고 멀리 앞을 바라본다면, stakeholder간에 도움을 주는 기능을 찾는건 불가능한 일이 아닐 수 있다. 중요한건 바로 커뮤니케이션이다.)

 

다시, 질문으로 돌아와서, "기능의 추가"는 기능 2~5를 지원하는 과정이고, "기능의 확장"은 새로운 기능 n의 추가를 뜻한다고 할 때, market share가 1등이든, 꼴지이든, 제품에 대한 경쟁력을 가지기 위해서는 기능의 확장이 보다 의미있다고 볼 수 있다. 물론, 세상은 그리 호락호락하지 않음에, "기능의 추가"도 함께 보조를 맞춰줘야 한다는점, 이는 알아두자.