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

S/W 개발에 대한 몇가지 생각 (01)을 뒤로 하고 이제 좀더 개발부분에 대한 내용을 다루고자 한다. 즉, 개발자나 개발 PM이 읽어보았으면 하는 내용에 해당될 것이다. 물론, 앞선글, 즉, S/W 개발에 대한 몇가지 생각 (01)의 연장선이므로, 이전글을 미리 읽어두는것을 추천한다. 여하튼 S/W 개발 방법론은 시리즈로 구성될 것이니, 서로 연계된 내용이 많음을 미리 알려둔다.

 

프로젝트는 실험실이 아니다.

 

개발자가 한명으로 구성된 간단한 프로젝트라 하더라도, 전체를 본다면, 한명으로 구성되지는 않는다. 많은 다른 프로젝트들의 구성원들로 부터 영향을 받을 수 있으며, 영향을 줄 수도 있다. 연관된 구성원들이 많아지게 되어 작업의 network가 복잡해진다면, 흔히 부수적이라 생각되는 '커뮤니케이션" 비용 증가를 고민하게 된다. 한명에게는 1분정도 직접 구두로 설명가능한 내용을, 열명에게 전달하는 것은, 꽤나 힘든 일이다.

 

"프로젝트는 실험실이 아니다"라고 했으면서 왜 갑자기 구성원이나 커뮤니케이션을 언급했냐고 의아해 할 지 모른다. 이는 '실험실"이라는 부분이 불명확하기 때문이다.

 

"실험실"이란,

- 공공화(Public) 보다는 개인화(Private)한 성향

- 보다 진보적이라 자부하는 성향

- 본인이 좀더 많이 알고 있다는 자기 우월

- 성취 욕구

로 구성된 내용이라 가정하였다. 즉, 일반적으로 알고있는 "실험실" 즉, laboratory가 아닌 것에 주의하자.

 

수많은 구성원으로 이뤄진 집단에서, "이것은 잘 못된 부분이야"와 "혁신"을 외치고, "왜, 이 집단은 이렇게도 움직이지 않을까?"를 혼자만 생각하며, 고치려고 하는 구성원이 있을 것이다. 이들은 결국, 자기에게 Ownership이 있는 프로젝트를 "실험실"로 만들어 버린다. 문제는 이러한 "실험실"은 고립될 확률이 많아진다(이는 앞서서  언급한 개인화(Private)와 연결된다).

 

만일, 몇가지 "문제"를 발견했을 때, 이를 해결 하기 위해, 여러명의 의견을 청취하고, "그렇게된 원인"을 정확히 판단하여, 함께 문제를 해결해 나가려고 한다면, 이는 "실험실"이 아니다. 왜냐하면, 그것 자체가 Public이 되었기 때문이다. 혹은, "더좋은 방법"이 있다면, 이또한 여러명의 의견을 듣고, 공유하며, 이전에 이런 시도가 없었는지, 그때 실패한 이유는 무엇이며 극복할 대안을 만들고 공유한뒤, 서로 협의가 되었다면 이또한 "실험실"이 아닐 것이다.

 

여하튼, 앞서 설명한 "실험실" 분위기의 프로젝트는 결국 성공하지 못함을 봐왔었다. 회사 사정상 구성원은 늘 바뀌기 마련이고, 개인화된 구성요소는, 다른 공적(Public)인 사람들을 거치게 되면서, 그 성격과 목적이 퇴색된다. 물론, 업무의 인수인계가 이뤄진다고는 하지만, 그만의 개인화(Private)한 성향마저 인수인계 할 수 없는 노릇이다. 그렇다면, "실험실" 분위기의 발전이란 없을 것인가? 언제나 이렇게 보수적으로 살아야 하는가?

 

여태껏 "실험실"을 "프로젝트"로 연결하였다. 만일 "실험실"을 "프로젝트"가 아닌 비 공식적인 기술 모임이나 idea 제안, 혹은 간단한 proto-typing과 같은 다소 비 업무적인 부분으로 연결한다면, 얘기가 달라질 수 있다. 즉, 無 -> 有를 만드는 과정에는 언제나 "실험실"이 있어야 하며, 이는 매우 재미있는 일일 것이다. 하지만, 이것이 실제로, 많은 구성원과 연결되고, 프로세스를 다뤄야 하는 "프로젝트"로 승격 되는 순간, 이때 부터는 좀더 "보수적"인 시야로 돌아와야 할 것이다. 예를 들면, idea 제안때에는 전체 고객의 10%만 타게팅하였다면, 프로젝트에서는 최소 50%이상의 고객을 타게팅해야 할 필요성이 있을 것이다. 또한 有 -> new 有인 경우, 이전의 관계자들과 충분한 검토가 이뤄져야 한다. 앞선 글(S/W 개발에 대한 몇가지 생각(01))의 "목적"과 "무엇"등을 잘 생각해야 한다. 만일 기존 有에 큰 문제가 없는데, 혼자만의 Very private한 성향을 넣고 싶다면 과감히 포기하고, 다른 無 -> 有를 만드는데 집중하기 바란다. 그것이 성공의 비결이며, 주변으로 부터 인정받는 길이다.

누군가는 위 생각들이 "선진 it기업인 google의 beta 정신과 같은 혁신과 상충되는것 같다"라고 비판할지 모르겠다. 나는 이에 대해, "결과와 과정을 혼돈하지 말라"라고 대응하고자 한다. google의 beta와 같은 창조/혁신에게 있어 우리는 주로 수요자나 사용자이다 보니 그 결과만 생각하는 경향이 있다. 새로운 기능이나 구성은 매우 진보적으로 시작했겠지만, 그것이 "프로젝트"화 되고 고객 delivery가 결정되었다면, 그 결정 과정도 많은 의견으로 Public으로 진행되었을 것이며 결정된 이후는 re-organization되어 철저히 오류 없도록 전달되려고 노력할 것이다. 즉, 고객에게 전달된 가치나 결과는 철저히 혁신으로 구성되지만 그 개발 과정이나 고민 그리고 의사 결정 과정은 그와 다르게 보수적이거나 전략적일 수 있다는 것이다. 이것을 혼돈하면 안된다는 뜻이다.

 

다시 앞으로 돌아와서, 아무리 간단한 프로젝트라 하더라도, 그것을 개인화해버린다면, 그것은 바람직 하지 않다. 다른 누군가가 그 업무를 받았을 때, 그가 "이건 왜 일반적인 우리 회사 방법론과 왜이리 달라?"하면서 얘기가 나오는것이 좋지 않다는 것이다. "이것봐, 당신의 그 보수적인 입장이 문제일세. 그러니 발전이 없는 거야. 나처럼 혁식적으로 뭐든 해봐, 적극적으로"라고 애기한다면, 오히려, 그가 좀더 모자란 사람이다. 세상은 혼자서 살아가는 곳이 아니기 때문이다.

 

누구를 위한 Framework인가?

 

흔히 개발을 진행하다보면 "뭔가에 홀린듯" 그 구조를 Framework으로 만들려고 하는 경우가 발생한다. 이에 대한 의견에 대해, 결론 부터 애기하자면, "참아라"이다.

 

뉴튼에 대해서 다들 잘 알것이다. 스티브잡스의 애플 처럼, 뉴튼도 사과가 연상되기도 하지만, 그는 주로 만유인력의 법칙을 집대성한 물리학자로 알려져 있다(물론, 더 많은 업적도 있다). 그 시기가 "절대 물리"와 연결되어, 해당 법칙은 거시적인 지구, 태양과의 관계에도 해당되며, 미시적인 원자, 전자와의 관게에도 수식이 적용되었다. 즉, 만유 인력 공식은 모든 "자연 현상'을 설명할 수 있었으며, 만유 인력 상수 G는 신비하게 표현되기도 하였다. 어떻든, 그것은 그 시대 과학의 Framework이 되어 버렸다.

 

그러나 시대가 흘러, 해당 만유 인력으로 설명되지 않는 현상이 발견되었으며, 결국 아인슈타인에 의해 "상대 물리"가 발전하게 되었다. 만유 인력도 하나의 자연 현상이지만, 그 것 이외에도 또다른 자연 현상도 알려지게 된 것이다(뭐, 이제는 양자 물리같은 불확정성 현상까지도 발전되기도 한다). 즉, 여태껏 알려진 Framework이 들어맞지 않게 된 것이다(물론, 대부분의 현상은 기존 Framework으로도 설명 가능하다).

 

왜 갑자기 물리 얘기를 했는지 이해가 되는가? 이는 절대적인 Framework은 존재하지 않는다는 것을 보여주기 위함이다. Framework은 그 자체가 하나의 "틀"이 되므로, 그것을 벗어나기란 쉬운 일이 아니다. 만일, Framework을 개발하게 된다면, 그 자체가 하나의 거대한 "틀"이 되며 '제약"이 되는건 당연한 일이다. 만일, 그 Framework이 정말 대단하게 모든 미래의 요구 사항을 수용할 수 있다면 문제가 없으나, 앞선 "만유 인력"의 경우 처럼, 세상은 그리 호락호락하지 않다. 언젠가 그 틀을 벗어나는, 상상조차 하지 못한 요구 조건은 반드시 발생한다는 것이다. 그러나, Framework은 그것을 수용하지 못해 많은 난관(Branch의 발생 혹은 Spec Out 처리)에 봉착하는 경우가 많이 발생한다.

 

물론, Framework을 개방적으로, 미래의 요구 조건을 쉽게 수용할 수 있게 설계했다고 애기 할 수 있으나, "만유 인력"도 깨어진 마당에, 그리고 우리가 "존티토"같은 예언자가 아니기 때문에, 그 것은 이뤄질 수 없는 일이다. 참으로 슬픈 일이다.

 

Framework의 개발에 대해 부정적인 부분만 집중했다고, 누군가는 공격할 지 모르겠다. 물론, 장점도 있지만, 나는 단점을 훨씬 많이 봐왔었다. 쉽게 구현할 수 있음에도 불구하고, 과거의 잘못된 Framework으로 인해 매우 어렵고 위태롭게 개발된 항목들도 분명 발생한다. 이런 부분들은 너무 치명적이였기 때문에, 다소 부정적인 관점이 생긴 것이다.

 

잘 생각해 보라. 만일 MFC 개발자라 한다면(MFC 자체도 Framework이라 가정하자), 수많은 OnXXXX와 같은 함수, 그리고 수많은 Virtual 함수, Afx 함수 등등이 있을 것인데, 내가 예상하지 못한 순서로 호출을 받거나, 아니면 호출을 받지 못하는등, 예외적 경우를 많이 경험했을 것이다. 그렇기 때문에, MSDN을 열심히 봐야 하거나, 두꺼운 MFC 레퍼런스 책을 학습, 또는 MFC 소스 코드를 디버깅해야 하는 부담마져 생겨버린다. 여하튼, 정작 일주일간 공부한 결과, "MFC 구조상 요구된 기능은 구현할 수 없음"을 결론맺은 경우도 발생한다. 힘든 노릇이다. 이런 것들이 Framework이 주는 단점이 된다(물론, MFC를 사용하면, 일반적으로 개발은 수월하다. 이는 장점이다).

 

만일 회사내 프로젝트를 임의의 Framework으로 만들어 버린다면, 이는 또하나의 MFC를 만들어 버린 것이다. MFC 보다 버그도 많을 것이고, MSDN 처럼 잘 문서화도 이뤄지지 않는다. 결국, 그 Framework은 누구나 쓸 수 없는, 하나의 프로젝트에서만 사용하는 반쪽자리밖에 되지 못한다. 그럴거 같으면 처음부터 Framework을 만들 필요가 없을걸... 그것을 유지하느라, 빙빙 돌아가며 힘들게 개발만 했을 것이다. 후회는 언제나 치명적이다.

 

Framework은 어떻게 보면 "따라올테면 따라와. 쓰기 싫으면 사용하지 말고. 시킨대로 잘 써"의 정신이 베어있다. 협업이 중요화된 개발 환경에서는 다소 적합해 보이지는 않는다. 많은 개발자의 개성과 창의성, 그리고 기획을 적용하는데 도움이 되지 못한다.

 

Framework이란, 결국, "따라올테면 따라올 수 밖에 없는" 경우에 사용될 것이다. 뭐, boost library, MFC, QT, 그리고 Spring이나 Django같은 Web Framework도 그럴 것이다. 어차피 쓸수 밖에 없다. 그러면서 세월이 지나 내공이 생기는 것이다. 어차피 이런 것들은 Global한 적용으로 인해, 수많은 예외 case에 대한 대비가 마련되어 있다.

 

그러나, Global하지 않는 사내의 Local 프로젝트에서 Framework 개발은 추천하지 않는다. 만일, 현재 이미 진행된 프로젝트를 Framework을 만들어 겉멋을 잔뜩 들인 경우, 한단계 호출이면 되는것이 Framework으로 인해 몇단계 거치는 경우가 많아진다. 이전에는 쉽게 Method를 추가할 수 있었는데, 하나하나 추가할 때 마다 뭔가 다른 작업을 해줘야 한다. 만일 그런 경우는 많지 않겠지만, 인기있는 Local Framework이 있다고 가정하고, 그것이 수정해야 되는 경우가 발생한다면, 해당 Framework을 사용하고 있는 다른 프로젝트의 영향에 대해 살펴보기도 해야하 되는데, 이는 QA 항목이 몇배로 증폭시키는 원인이 된다. 여하튼, 이런저런 이유로 다른 프로젝트에서 그다지 그 Framework을 사용하지 않으려 할 것이다. 그러면 결국 Framework을 만들 필요가 없었던 것이며, 비용만 늘어났을 뿐이다. Framework을 만들때 이유는 누군가가 이 Framework을 사용하여 회사 전체의 Resource의 절약을 노리지 않았을까? 결론은 쉽게 절약되지 않거나, 오히려 증가한다.

 

미래가 두려운가?

프로젝트가 진행되어, 개발 부분을 진행,설계, 코딩 그리고 테스트 과정에서 지나치게 미래에 대한 걱정을 하는 경우가 있다. 흔히 인류가 다른 동물과 다르게 이렇게 발전을 할 수 있었던 것은 "걱정을 할 수 있는 능력" 때문 이라고 들은적 있는데, 그것도 지나치면 "독"일 듯 하다.

앞선 Framework 부분에서, "미래"의 불화실성을 언급했다. 그러다 보면, 걱정이 생기기 마련이고, 이를 대비하기 위해 몇몇 대응 기능들이 추가되기도 한다. 즉, 그 대응 기능은 "현재"에는 해당되지 않으며, "미래"의 그 상황이 발생했을 때 들어가는 부분이 될 것이다. 그 대비를 위해 많은 부분의 희생이 필요하게되는데, 정작 그 "미래"는 오지 않으며, 오더라도 예상과 달라 대비했던 부분과는 상이하여 다시 만들어야 하는 경우가 허다하다.

이런 경우를 보더라도, 지나친 미래의 걱정은 잠시 접어두고, 오로지 "현재"의 문제를 보다 잘 해결하는데 집중하는 것이 중요하다고 본다. 그렇다고 너무 걱정없이 현재에만 머무르는 경우는 없길 바란다. 적당한 조정. 그것이 필요하다.

몇몇에 대해서는 이러한 걱정이 매우 중요하기도 하다. 그 중 하나가 "보안"인데, 이는 철저히 구성되도록 해야 한다. 어차피 폰노이만 방식의 0/1로 구성된 컴퓨팅 시스템은 보안에서 절대 안전이란 있을 수 없다. 그렇지만, 어떠한 방식이든 예상하지 못한 접근은 사전에 차단하는 것이 "필수"가 되어 버렸다. 그래서, 보안에 대해서는 철저히 걱정하고 대응하라. 그러나, 미래에 발생할지도 모르는 "고객의 요구"나 "타팀과의 협업"에 대한 기능은 잠시 접어두고, 현재에만 집중하자. 그리고, 욕구나 협업이 들어오는 경우, 그 때 대응하자.