현장에서 문제 해결을 찾는다.

아주 근사한 가전제품을 만드는 회사가 있다고 하자. 이 회사에는 가전제품을 구성하는 요소들을 설계하는 설계팀과 이를 기반으로 조립 라인을 통해서 하나의 가전제품을 만드는 제조팀으로 구성되어 있다. 설계팀은 제품의 컨셉을 이해하여 명세(specification)를 정하고, 그에 맞게 각 구성 요소들을 설계 도면에 표시한다. 제품의 크기를 휴대성이 편하게 최소한으로 명세했기 때문에 가능한 한 각 구성요소가 최소한의 공간 안에 밀집하게 구성되어야 하며, 때로는 하나의 요소가 여러가지 역할을 수행하게끔 구성품을 만들어야 하는 경우도 있다. 설계팀은 촉박한 일정에서도 제조팀에서 해당 제품을 만들 수 있는 상태의 모든 요소가 설계되었음을 확인했고, 최종적으로 제조팀에게 제품 설계를 넘긴다.

제조팀에서는 설계를 토대로 생산과 조립 라인을 구성하고, 각 구성품들을 만드는 팀과 구성품들을 사용해서 조립하여 최종 기능 점검을 하도록 라인을 셋업한다. 처음에는 설계 도면을 이해하고 이러한 라인을 구성하는데 다소 시간이 걸릴 것이다. 또한, 기존 다른 제품의 라인을 재사용하기 위한 최적의 안을 만들어보고 시험 가동하여 최종 제품을 만들어낸다. 어느 정도의 조정을 통해서 제품을 생산하는 최적의 방법을 찾아낸 제조팀은 제품을 본격적으로 생산한다.

Killbot Assembly Line by pasukaru76

제조팀이 가능한 많은 테스트를 수행하려고 하지만, 현실적인 제약으로 인해서 고객에게 제품을 인도하고 나서 다양한 기능 결함들에 대한 의견이 접수되고 문제의 원인을 파악하기도 한다. 이 과정에서 생산과 조립 라인 내에서만 문제 해결이 안되는 경우도 많다. 즉, 제품을 설계한 설계팀과의 의견 조율이 필요하게 된다. 만일, 설계팀에서는 설계 문서를 보고 무엇이 문제인지를 이야기하고, 제조팀에서는 생산이나 조립 라인에서 문제를 찾아야 한다고 서로가 주장한다면 어떤 결과가 나타날지 예상을 할 수 있다. 설계 문서에는 당연히 제품을 구성하는 구성요소들의 만드는 과정이나 조립하는 과정이 나타나있지 않다. 설계팀에서는 설계 문서를 보고 제조팀에게 문제를 설명하지만, 제조팀은 라인 현장과의 매핑이 안되고 마치 뜬구름 같은 이야기처럼 들리게 된다. 이때에는 설계팀에서 생산이나 조립 라인의 현장을 둘러보고 설계문서와의 매핑을 통해서 문제 해결의 실마리를 찾아야 한다. 왜냐하면 라인 현장이 설계팀과 제조팀이 공통적으로 이해할 수 있고 의사소통할 수 있는 매개체이기 때문이다.

SW를 만들때에 설계팀을 아키텍처팀으로, 제조팀을 개발팀으로 비교해보자. 아키텍처팀은 자신이 만든 설계들을 개발팀에게 전해주며 이를 기반으로 SW를 만들라고 말한다. 개발팀은 이를 토대로 개인의 개발환경(작업장)과 통합/배포, 검증에 관련된 환경들을 만들고 본격적으로 SW를 만든다. 응당 개발팀에게는 문제가 발생되기 마련이고, 이를 해결하고자 하는 욕구를 어딘가에 이야기하길 원한다. 아키텍처팀에서는 개발팀의 이러한 문제를 접수하기도 하지만, 대답은 설계 문서에서 그 답을 찾으려고만 한다. 개발팀은 아키텍처팀에서 이야기한 것이 무엇인지를 이해하고 자신의 문제로 매핑해야 하지만, 도저히 그러한 매핑이 어떻게 이루어져야 하는지를 잘 모른다. 결국 개발팀은 문제를 불거지게 하지 않고(문제를 쌓아두거나 그냥 묻어두는 형태) 최소한의 검증에만 통과할 수 있도록 둔다.

이러한 문제는 결국 시스템을 오픈하는 시점에서야 뒤늦게 발견되고, 아키텍처팀과 개발팀이 서로 얼굴을 대고 으르렁거리는 사태까지도 연결되기도 한다. 아키텍처는 SW가 만들어질 수 있는 최종적인 상태만을 이야기하기 때문에 그러한 과정에서 발생될 수 있는 문제들에 대해서는 모두 포함할 수가 없다. 이는 제조 과정에서 일어나는 것과 비슷하다. 아키텍처팀이 개발의 모든 과정에 참여하기가 현실적으로 힘들지만, 문제 발생시 현장을 개발팀과 같이 살펴야 한다. 물론, SW는 현장이 개발 소스 코드라는 것은 당연하다. 즉, 문제는 소스 코드에서 해결 실마리를 찾아야 한다는 의미이다. 아키텍처가 가지는 많은 장점들이 있지만, 가장 크게 빠질 수 있는 맹점은 현장 적용에 있어서 SW 제품을 만드는 과정의 문제를 모두 포괄할 수 없다는 것이다.

개발자의 환경의 탓으로 인해서 아키텍처에서 만든 프레임워크가 잘 동작되지 않는 경우도 있다. 혹은, 너무 과도하게 생성된 객체들로 인해서 설계에서 만들어놓은 객체 수용 공간의 한계를 넘어서는 경우도 있다. 복잡하게 얽힌 컴포넌트들 간의 관계로 인해서 원활하게 통합이나 배포가 어려운 경우도 있다. 비즈니스 로직이 UI에 너무 많이 몰려있는 관계로 사용자 환경이 해당 SW로 인해서 문제가 발생되는 경우도 있다. 요구사항으로 인해서 너무나 많은 데이터를 필요로 하는 통신으로 인해서 다른 기능의 네트워크 부하에도 영향을 미치는 경우도 있다. 이러한 문제들은 개발 과정에서 비일비재하며 독특한 형태로 나타난다. 이를 설계 문서만을 가지고 해결한다고 하면, 개발자들은 이해하지 못하는 언어로 의사소통하는 경험을 느끼게 되며, 심지어 책임 회피 현상까지도 나타나게 된다.

아키텍처팀과 개발팀의 공통 언어는 소스 코드이어야 한다. 물론, 개발팀에서도 설계를 이해하고 설계할 수 있는 능력을 필요로 한다. 하지만, 설계상의 문제보다 개발 과정의 문제가 훨씬 더 많은 비중을 차지하며, 실제 고객에게 인도되는 SW는 설계문서가 아니라 동작하는 SW가 아닌가. 개발팀이 고민하는 문제를 해결해줄 때에 더 품질이 높은 SW가 만들어질 수 있다. 개발팀에게 더 친숙한 형태로 다가가는게 더 생산성이 날 수 있다. 개발팀이 아키텍처팀에서 일방적으로 정한 것을 따라오는 대상이 아니라, 아키텍처팀에게는 또 다른 이해관계자라는 개념으로 바라보아야 한다. 이해관계자가 가지는 관심사(concern)를 해결해주는게 아키텍트의 임무(role)이지 않은가.