0. 현실의 소프트웨어 문제 어떻게 해결하나요

들어가며

대부분의 사람들이 그렇듯이 자신의 역할이라는 것이 다양하게 있다. 누구의 자녀, 누구의 친구, 누구의 동료, 그리고 누구의 부모. 자신이 하고 있는 업 혹은 회사에서의 역할도 마찬가지다. 나도 그러한데, 이 여러 가지 중 조금 더 애착이 가는 것이 소프트웨어 아키텍트(Software Architect)이다. 나의 공식 직함은 관리자이다. 핸즈온 매니저를 계속하고 싶기는 하였지만, 현실은 그러지 못하고, 내가 필요한 도구 정도 코딩하고, 실제 제품에 포함되는 코드는 리뷰하기도 어려워진 것이 현실이다. 또한, 조금 더 개발자의 업무를 할 수 있는 것이 이 역할이기 때문이기도 하다. 그러면서, 회사 업무를 하며 실무 개발자들과 소프트웨어 아키텍처를 설계를 하는 것이 너무 귀한 기회이기도 하다.

최근에는 외부에서도 알게 된 분들과 함께한 아키텍처 관련 원 포인트 세션, 달리 말해 소프트웨어 문제점 멘토링으로 여러 사례들을 접하게 되었다. 흥미로운 것은 이러한 과정이 소프트웨어 아키텍트인 나에게도 큰 의미가 있지만, 소프트웨어 문제를 가지고 있는 분들에게도 실질적으로 도움이 된다는 사실이다.

우선 이론적으로는 도움을 요청하신 분들 입장에서는 첫 째, 소프트웨어 아키텍처 전문가를 데려다가 활용(How to bring experts)하는 측면에서 도움이 된다. 하지만, 이 부분에 맹점이 있다. 즉, 전문가와 일하되, 조율(Coordination)하고 통합(Integrate)하라는 연구[1]가 있다. 역서도 함정이 있는데, 비협업적으로 일하게 되면 비전문가들이 일하는 것보다 성과가 나쁘다는 내용도 언급되어 있는 것이 매우 흥미롭다. 또 다른 측면에서는 함께 같은 주제에 대해서 살펴보는 것이 페어 프로그래밍(Pair programming)과 같은 효과를 발휘한다. 이에 대한 이론적 배경으로 두 사람이 협력을 통한 추상화(Collaborative Abstraction)를 통해서 다른 시각(perspective)을 받아들일 수 있게 된다고 한다 [2]. 이 두 가지가 원 포인트 세션의 장점이라고 할 수 있겠다.

이와 같이 여러 사람들과 만나서 다양한 이야기를 듣게 되었고 다루는 내용이 현실의 소프트웨어 개발과 관련된 문제들이라는 생각이 들었다. 달리 말해 책에서만 존재하던 있던 내용들이 아니고, 우리가 살고 있는 실제 세상에 있었고 살아 있는 문제들이라는 생각이 들었다. 이 사례들들에 숨어 있는 이 이야기들을 끄집어내어서 내 생각을 조금 더 나누고자 한다.

 

참고 문헌

[1] A. W. Woolley, et al. "Bringing in the experts: How team composition and collaborative planning jointly shape analytic effectiveness." Small Group Research 39.3 (2008): 352-371.
[2] D. L. Schwartz, "The emergence of abstract representations in dyad problem solving", The journal of the learning sciences, 1995