크리에이티브 커먼즈 라이선스
Creative Commons License

대선이 가까와 오면서 보수와 진보의 이념 대결은 이제 뚜렷해지게 나타날 것이다. IT 관점에서도 보수와 진보를 구분할 수 있을까? 이러한 물음에 Amazon에서 일했던 경험을 가지고, 현재 Google에 근무 중인 Steve Yegge이 올린 최근 글이 이슈로 부각되는 것 같다. Steve는 이전에도 구글+ 에 대한 빈판의 글(번역본)을 올려서 외부 유출이 되는 바람에 화제가 되기도 했었는데, 글을 읽어보면 구글+에 대한 비판의 목소리와 함께 플랫폼의 중요성을 아마존이나 다른 서비스에 대해 빗대어서 말한 것 같다. 언론이 일부글들은 인용하면서 그의 글은 본의 아닌 목적으로 사용되기도 한 모양이다.



[출처 : http://www.bablotech.com/2009/01/26/12-wallpapers-in-which-linux-criticizes-windows/]



이번에 작성한 글에서는 '소프트웨어 엔지니어링은 보수(conservative)에서 진보(liberal)까지 그 자체로 정치적인 축을 가진다'는 명제(thesis)에서 출발했다. 물론, 이분법적인 사고에 대한 문제와 실세계의 정치적인 성향과의 관계에 대해서는 논할 부분들이 많을 것이지만(사실, 이를 증명하는게 크게 의미없다고 생각하지만), 실제로 Steve가 생각하는 소프트웨어를 만드는 입장에서 보수(conservatism)와 진보(liberalism)이 무엇인지를 정리하면 다음과 같다.


보수적인 측면

  • 위험관리에 대해 적극적으로 대처하고 사전에 없애려는 노력을 함
  • 유연성(flexibility)과 생산성(productivity)보다 안정성(safety)과 성능(performance)를 더 우선시 함


진보적인 측면

  • 효과적인 변경이 더 강력한 동기이며, 이를 위한 시스템을 만듬
  • 시스템의 유연성을 극대화시키는 동시에, 기능 개발의 속도를 최대화시키는 것을 목적으로 함

이와 같은 관점은 IT에서 SW 개발과 유지보수라는 두가지를 분류해볼때 유사한 접근 방식이기도 하다. 즉, 새로운 시스템을 개발하는 SW 개발 영역에서는 진보적인 성향이 더 강하며, 시스템을 유지하고 운영하는 영역에서는 보수적인 성향이 더 강한 경향이 있다. 즉, 개발자의 보수와 진보적인 성향 역시 어떠한 시스템을 다루는가와 직접적으로 관련이 있지 않을까 싶다.

이러한 보수와 진보적인 측면을 측정하는 기준으로 Steve는 각각 9가지의 사례를 들어서 설명하고 실제 측정을 할 수 있는 웹 사이트를 만들었다. (http://sweaxis.org 에서 자신의 SW를 만드는 이념적 성향을 측정해볼 수 있다.)

보수적인 측면
1. 소프트웨어는 최종으로 인도되기 전에 버그가 없는 상태를 목적으로 해야 한다.
2. 프로그래머는 에러에 대해서 미리 예방할 수 있어야 한다.
3. 프로그래머는 새로운 언어나 기술, 문법에 대해 익히는데 어려움을 겪는다.
4. 제품 코드(운영을 위한 코드)는 컴파일러에 의해서 안전하게 체크되어야 한다. (이를 체크할 수 있는 방법이 없는 경우(예를 들어, 정규식이나, 동적 호출과 같은 실행시에만 검증할 수 있는 것들)에는 특정 절차를 거쳐서 체크되어야 한다.)
5. 데이터 저장소는 정의가 잘 된 형태로 배포된 스키마에 항상 맞아야 한다. (이는 DB와 ERD 뿐만 아니라, UML, XML과 DTD 등이 모두 포함된다.)
6. public 인터페이스는 엄격하게 모델링되어야 한다. (데이터는 문자열이나 타입을 알 수 없는 콜렉션 형태로 저장되어서는 안되며, 엄격한 특정 타입을 갖는 궁극적으로 객체 모델 형태이어야 한다.)
7. 제품(운영) 시스템은 결코 위험한 상태가 되거나 백도어 형태의 공격을 받아서는 안된다. (이는 개발을 위해 디버거나 텔넷과 같은 연결도 허용해서는 안되면 오직 읽기만 가능한 모니터링만 가능해야 함을 의미한다.)
8. 만일 해당 컴포넌트에 대해 안전성에 대한 일말의 의심이라도 있다면, 결코 배포되어서는 안된다. (이는 긴급배포와 같은 시급한 경우에도 동일하게 적용된다)
9. 빠름이 느림보다 낫다. (코드는 성능을 위해서 작성되어야 하며, 코드 자동 생성과 같은 느림을 유발하는 코드를 사용해서는 안된다.)

진보적인 측면
1. 버그가 그렇게 큰 문제가 아니다. (버그는 어떻게든 발생되며, 이를 해결하기 어려운 것과 상관없이 모든 개발자들이 이를 해결하려는 노력을 해야 한다. 이부분이 보수와 진보를 나누는 주요한 부분이다.)
2. 프로그래머는 초반에만 신참일 뿐이다. (프로그래머는 연차나 경험을 하면서 지속적으로 지식과 경험이 풍부해지고 더 현명해질 수 있다.)
3. 프로그래머는 현재 하는 일에 따라서 자신의 능력을 극적으로 빨리 향상시킨다. (새로운 기술에 대해서는 관련 문서를 읽을 시간을 잠시 주면 이를 익힌다)
4. 간결함은 힘이다. (코드는 최소화되도록 유지해야 하며, 정적 분석 도구를 통해서 더 최적화시킬 수 있다)
5. 엄격한 스키마가 유연성을 제약하며 개발 속도를 느리게 한다. (스키마는 보수적인 측면의 5번의 내용을 모두 포함하며, 실제로 데이터가 어떻게 생성되고 어떻게 사용되는지에 따라서 스키마를 이해하기 때문에 코드에 따라서 변경될 수 있다)
6. public 인터페이스는 무엇보다 단순해야 하며, 이전 버전에 대한 호환성 뿐만 아니라 이후 버전에 대한 호환성을 갖춰야 한다. (엄격한 모델링은 인터페이스가 앞으로 변화할 필요가 있는 것을 추측할 뿐이기 때문에 이전/이후 버전에 대한 호환성을 보장할 수 없으며, 최소한 단순화시킨 API로 점증적으로 변경해야 한다)
7. 시스템 유연성은 고객이 원하는 것(계약서 내용)을 얻게 만드는 것과 다른 경쟁자(외부 침입자)들이 이를 가로채는 것 사이의 차이를 의미한다. (보안이나 안정성에 관련된 수많은 검증된 제품들이 많이 있으며, 이를 통해 제어가 가능하다)
8. 기업은 위험을 감수하고, 변화를 수용하고, 경직성에 대해 강하게 반발해야 한다. (피할 수 없는 재앙에 대비해서 좋은 복구 기술을 갖출 필요가 있으며, 이는 위험을 감수하지 않더라도 필요함을 의미한다)
9. 성숙되지 않은 최적화가 악의 근원이다. (동작하는 코드가 우선이며, 성능보다 정확성에 초점을 두고, 정확성보다 반복적인 프로토타입핑에 초점을 둔다. 성능에 대해 가장 우선 순위로 언급될 때에만 프로필을 사용한 최적화로 성능을 향상시킨다)

이와 같이 총 9가지의 항목으로 구성된 보수/진보적인 내용들을 기준으로 개발자의 성향을 점검해 볼 수 있다. 항목들을 자세히 보면 보수적인 측면과 진보적인 측면 모두 동의할 부분들이 있으며, 어느 것을 더 동의할 것인가가 성향을 나타내는 것이지만, 이와 같은 성향이 SW 개발에 있어서 영향을 미치는 것은 사실이다. 즉, 설계에 대한 믿음과 사상이 바로 이러한 성향들이 다소 반영된 형태로 나타나기 때문이다.


이러한 측정 기준의 결과로 "비정치적", "보수적", "중립", "진보적"의 4가지 성향을 분류했고, 양극단의 머리를 두는 중립파를 추가로 분류했다. 또한, 언어에 따라서 어떤 성향을 띠고 있는지에 대해서는 예시를 들었고, 페이스북, 아마존, 구글, MS 등의 기업 문화에 대해서도 사례를 들고 있다.


사실, 국내 현실에서 이러한 보수와 진보적인 측면에 대해서 나누는 것은 큰 의미가 없을 수 있다. 왜냐하면 기술에 너무 종속되어 버린 SW 엔지니어링 분야에서 SW 란 단순히 무엇을 이루기 위한 도구나 수단으로 생각하는 경향이 너무나도 강해서 이러한 보수와 진보를 나누는 것에는 거의 관심이 없는 것처럼 보일 수 있다. 하지만, 무엇보다 그러한 기술을 이루는 아키텍처 설계가 어떠한 관점으로 접근할 것인지가 SW가 가지는 큰 특징을 가진다. 특히, 개발 프로세스에서도 이러한 보수/진보의 성향에 따라서 어떠한 접근법을 취할 것인지가 분명하게 나눌 수 있는 부분이 있기 때문에 설계를 하는 과정에서는 중요한 요인인 것들도 있다.


Steve Yegge는 개발자들이 사고하는 방식을 분류한다는 차원에서 꽤 생각해볼 만한 내용이다. SW 개발을 할 때에 이러한 사고에 대한 절차를 명확하게 보여줄 수 있는 방법과 방식이 필요하며, 해당 설계가 어떠한 관점과 사상에서 출발했는지를 알려줄 필요가 있다. 어느 한쪽이 더 좋고 나쁘다고 말할 수는 없지만, 그리고 이러한 분류에 속한 기술이나 언어들 역시 상황에 따라서 바뀔 수도 있지만, 가장 중요한 내용은 프로그래머라면 자신이 설계하고 구현하고자 하는 SW에 대한 강력한 믿음과 사상을 가져야 한다는 것이다. 그리고, 어떤 형태로든 이러한 내용이 표현되고 설득시키고 가시화시킬 필요가 있다.

저작자 표시 비영리 동일 조건 변경 허락
신고
크리에이티브 커먼즈 라이선스
Creative Commons License

여기에 의사소통을 하는 아주 혁신적인 도구가 있다고 하자. 이 도구는 언어나 텍스트로 표현하지 않아도 생각만으로 사용자의 의사를 표현할 수 있다고 하자. 정말 혁신적이지 않은가. 이제 우리는 더 빠르고 효과적으로 의사소통을 할 수 있게 되었다. 하지만, 과연 그럴까? 의사소통의 본질적인 내용을 보면 결국 쌍방의 의견이 합의해가는 과정이 된다. 아무리 빠르고 효과적으로 내 의견을 표현할 수 있다고 하더라도 이것이 의사소통을 효과적으로 할 수 있는 방법이 아닐 것이다. 의사소통에서는 '빠름'이 정답이 될 수 없음을 의미한다.


IMG_0567
IMG_0567 by illum 저작자 표시동일조건 변경허락



기존 소셜 서비스들이 의사소통에 영향을 미친 것은 빠른 의견의 개진과 더불어서 다수의 다양한 의견이 어느 방향성을 가지고 합의해가는 과정인 것이다. 즉, 이전에는 특정인이나 전문가 집단에 의해 한정된 의견으로 한정된 결정을 했다고 한다면 좀 더 다양하고 폭넓은 의견을 통해서 다수가 원하고 다수가 합의하는 결정으로 선택한다는 것이다. (다수가 선택한다고 꼭 정답이라는 것은 아니다.) 빠른 의사소통을 혁신적으로 할 수 있는 도구가 기존의 합의를 이루는 과정을 대체하기 힘들다는 것이다. 기존의 의사소통을 하는 방식은 수천년 동안 인류가 보편적으로 수행하던 방식이기에 이를 바꾸기는 힘들다. 결국 도구는 이러한 전통적인 의사소통이나 의사결정을 하는 방식을 더 효과적이고 효율적인 형태로 할 수 있게 도움을 주어야 한다.


도구를 도입하거나, 가지게 된다면 혁신적으로 문화를 바꿀 수 있다라는 생각은 SW를 도입하는 기업에서도 늘 발생하는 문제이기도 하다. 물론, 도구가 가지는 특성에 따라서 도구의 도입으로 기존 불편한 부분을 혁신적으로 바꿀 수 있는 영역은 분명 있다. 하지만, 이러한 영역이 문화나 프로세스와 같은 모든 구성원들과 수행 방법에 걸쳐서 스며든 내용까지는 바꾸기는 힘들다. SW를 개발하는 문화 역시 그 나름대로의 조직마다 독특한 문화가 존재하고, 그러한 개발 방식은 최종적으로 SW를 인도하는 시점에 고객의 만족으로 집중될 수 있다. SW 개발을 자동화하여 생산성을 아무리 높여도 고객 만족을 충족시키지 못한다면 이는 도구 도입으로 인해서 오히려 기존의 작업 방식을 저해하는 것이다. 도구가 담당하는 영역이 넓으면 넓을수록 오히려 도구에 한정되어서 기존 프로세스나 절차와의 충돌이 발생될 여지가 많아진다. 결국 이러한 기존 문화나 프로세스의 충돌을 해결하지 못하다면 도구가 가지는 장점보다도 단점의 모습이 더 많이 보이게 되고, 도구 도입의 실효성을 의심하게 된다.


구매나 제조 프로세스를 아우르는 ERP의 도입 역시 기존 프로세스와 상당한 충돌이 발생되면서 한정적 사용의 형태로 도구의 활용의 변형이 발생된다. 도구가 제공하는 기능에 사로잡혀서 모든 것을 도구 중심으로 맞추고 여기에 노력을 해보았지만 다시 원래의 프로세스로 되돌아가는 현상을 목격하는 것은 어렵지 않다. 인류가 발명한 위대한 도구들은 어느날 하루 아침에 번쩍하고 나타난 것들이 아니다. 그 이전에도 수많은 노력과 시도를 통해서, 그리고 여기에 인류가 적응해가면서 나름대로 최적의 방법과 같이 나타난 것들이다.


SW 도구 구매가 쉬워지면서 어느날 반짝하고 나타난 도구들과 같이 우리 삶은 마치 도구에 의존되거나 종속되도록 조정을 받는 경우도 많다. 도구 적응에 얼마나 쉽고 간편하게 접근할 수 있을 것이가, 그리고 도구가 이전에 우리가 수행했던 방식을 얼마나 존중하고 떠 받쳐줄 수 있을 것인가를 따지는 것이 도구를 도입하는 효과를 극대화시키는 방법이다.


도구를 통해서 문화를 형성하고 구성하는 것은 정말 엄청난 노력이 든다. 이러한 노력을 최소화시키는 방법은 강제하는 것도 있다. 즉, 다양한 제약을 통해서 도구에 순응하게 만드는 것이다. 이러한 형태는 도구가 없으면 아무것도 못하게 만드는 결과를 낳기도 한다. 강제하지 못한다면, 도구를 익히고 적응하는데 많은 시간을 들여야 한다. 물론, 도구가 지원하는 범위가 협소하다면 그러한 시간이 아깝지는 않은 경우도 있다. 도구가 지원하는 범위가 넓다면, 가장 효과적으로 적용할 수 있는 영역을 찾아서 적용하는게 낫다. 도구 역시 인간이 만든 것이기에 여기에는 오류를 포함하고 있다. 그러한 오류까지도 문화에서 수용할 필요는 없다.


도구를 도입한다고 하면, 조직 구성원과 문화에 제일 적합한 도구를 선정해야 한다. 문화를 바꿀 목적으로 도구를 도입할 필요는 없다. 오히려 어색한 옷을 입은 모양과 같이 불편한 상황을 연출할 뿐이다. 이러한 상황은 기존의 최선의 원리나 원칙이 도구로 인해서 제약받는 경우에 식별된다. 즉, 도구로 인해서 최선이나 최적으로 생각했던 방식을 바꾸어야 한다면, 도구가 오히려 해당 문화나 절차를 해치는 결과를 초래한 것이다.

저작자 표시 비영리 동일 조건 변경 허락
신고
크리에이티브 커먼즈 라이선스
Creative Commons License

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


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



Killbot Assembly Line
Killbot Assembly Line by pasukaru76 저작자 표시



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


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


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


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


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

저작자 표시 비영리 동일 조건 변경 허락
신고

+ Recent posts

티스토리 툴바