시스템을 만들때에 사용자(user)의 요구를 충족시키는 것이 제일 목적이라고 말한다. 보통 사용자라고 함은 시스템이 제공하는 서비스를 직접 사용해서 원하는 것(가치)을 얻는 행위를 하는 액터를 일컫는다. 이러한 사용자는 불특정 다수가 될 수도 있겠지만, 업무 시스템과 같이 특정 업무를 위한 시스템의 경우에는 명확한 업무 사용자가 정의된다. 어떠한 사용자이든 이들은 시스템을 직접 다루거나 처리하는 형태가 아닌 그저 수동적으로 시스템이 일방적으로 제공하는 서비스를 사용할 뿐이다.


하지만, 최근의 시스템들은 사용자들에게 어느정도는 능동적인 행위를 부여하는 형태로 서비스를 제공하기 시작한다. 예전에는 HTML을 그저 브라우저를 통해 화면에 보여지는 요소를 만드는 형태로만 쳐다보았다면, 지금의 사용자들은 직접 자신만의 HTML을 조작하기를 원하고 많은 시스템들이 그러한 서비스들을 제공하고 있다. HTML 조작이 어려운 사용자들에게는 단순한 형태의 템플릿에서부터 복잡한 조합을 할 수 있는 템플릿까지 제공하여 사용자들의 입맛에 맞게 구성하라고 내어준다. 더 나아간다면 사용자들의 행위나 형태를 분석하여 자동으로 짐작하여 다양한 화면을 보여주기도 한다.



James, I think your cover's blown!
James, I think your cover's blown! by laverrue 저작자 표시



이러한 사용자에 대한 관점(viewpoint)은 점점 시스템을 조작할 수 있는 뷰(view)까지도 확대되고 있는 것이다. 이해관계자(stakeholder)는 이러한 사용자들을 포함하여 시스템을 둘러싸고 있는 다양한 이해관계(interest)와 관심사(concern)를 가지는 모든 사람(요즘에 사람 뿐만 아니라, 여러 시스템이 연계되고 외부에 서비스들을 오픈해주기 때문에 이러한 범주까지도 포괄하는 형태이다.)을 통칭한다. 시스템을 사용하는 사람만 보더라도 단순히 서비스를 제공하는 수동적인 형태가 아닌 능동적으로 시스템을 조작할 수 있는 기능까지도 부여하는 추세로 본다면 그보다 범주가 더 큰 이해관계자들이 원하는 시스템에서의 기능까지를 고려한다면 너무나도 많은 기능들을 시스템에서 제공되어야 할 상황이다.


시스템을 운영하는 사람들은 일일히 그 많은 서버를 관리하지 않고, 한번의 클릭으로 수십, 수백, 수천대의 서비를 관리하기 원한다. 시스템에서 문제가 발생되면 어떤 문제인지, 그리고 누가 해결해야 하는지, 얼마나 빨리 복구될 수 있는지에 대해서 통지받기 원한다. 심지어 시스템의 하드웨어에 대한 수명이나 상태까지도 자동으로 납품업자에게까지 알려주어 구매 프로세스가 자동으로 발생되기까지도 원하는 경우도 있다.


이제 시스템은 가만히 두면 사람들이 알아서 모이는 그러한 서비스를 제공해서는 더 이상 그 가치를 발휘하지 못한 상태까지 진화한 것이다. 이러한 상황에서 시스템을 만드는 아키텍트에게도 여러모로 고민거리들이 점차 늘어가기만 한다. 점점 늘어만 가는 이해관계자들과 이들의 요구는 그 끝을 알기가 점점 힘들어진다.


아키텍트에게 이해관계자들의 관심사는 시스템을 만드는 가장 중요한 요소가 된다. 이해관계자들이 많아지고, 이들이 관심을 갖는 분야가 다양할수록 신경써야 하는 (혹은 만들어야 하는) 아키텍처 요소들이 늘어난다는 것이다. 사실 얼마나 많은 이해관계자들을 만족시킬 것인가에 대한 정답은 없다. 하지만, 이 물음을 역으로 생각해본다면 이해관계자들은 어떠한 시스템에 만족을 하는가로 바꿔볼 수 있을 것이다. 즉, 이해관계자들이 만족하는 시스템을 찾아서 그 속성을 분석해야 됨을 의미한다. 이해관계자들이 만족하는 시스템은 자신들이 예전에 직접 경험했던 것일 수도 있고, 혹은 광고나 컨퍼런스 같은 곳에서 마케팅 요소가 가미된 시스템일 수도 있다. 혹은 최근에 유행하는 트렌드일 수도 있고, 때로는 스스로의 상상에 의해서 만들어낸 것일 수도 있다.


그러나, 무엇보다도 이해관계자들이 만족하는 시스템은 시스템을 사용함으로 인해서 자신의 가치가 더 돋보이게 만드는 것일게다. 즉, 해당 시스템을 사용함으로써 남들보다 돋보이고 더 효과적이고 효율적인 정보를 사용하고 있다는 느낌을 받는 시스템이 이해관계자 입장에서 비용을 들인 가치를 얻게 된다. 개발자 입장에서 시스템을 다루어야 하는데 여러가지 감시 체계나 복잡한 절차를 통해 자신의 작업을 다른 이에게 잘하고 있는지를 증명하게 만든다면 그 스스로 시스템을 다룬다는 자부심보다 남의 물건에 흠집이 나지 않게 조심스럽게 다루어야 한다는 강박관념을 더 받을 것이다. 웹페이지 어디 구석에 쳐박혀 있는 정보를 보기 위해서 다양한 인증 체계와 수많은 브라우저의 종료를 거치고 나서야 원하는 것을 얻는다면 사람을 위한 시스템이 아닌 시스템을 위한 사람으로 만든다는 감정으로 스스로의 자존감에 훼손이 발생되었다는 느낌을 받을 것이다.


시스템의 아키텍처를 만드는 아키텍트로써 이해관계자들의 요구를 충족시키는 것이 가장 큰 임무이다. 그러한 임무는 결국에는 이해관계자의 자존감을 높여줄 수 있는 시스템을 만드는 일이다. 이제 기술의 한계(혹은 기술을 구현할 수 있는 당사자의 한계)를 넘어서 다시 인간답게 살기 원하는 질을 제공하는게 시스템의 목적이 되었다. 얼마나 많은 이해관계자를 만족시켜야 하는지에 대한 물음은 아키텍트 스스로 인간에게 가치를 높여주는 시스템을 만들었는가로 다시 자문하게 만든다.


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

배를 반으로 갈라서 껍질을 벗겨 일자 형태로 자른 다음, 냄비에 자른 배를 넣고, 설탕, 계피와 같이 배가 잠길 정도로 와인을 넣는다. 그리고, 40~50분 정도로 조리면 먹음직한 와인에 절인 배요리(pera cotta)가 완성된다.


Pera cotta alla bella Helène, con cioccolato belga
Pera cotta alla bella Helène, con cioccolato belga by su-lin 저작자 표시비영리변경 금지


요리법(recipe)은 요리를 모르는 사람에게 먹고 싶은 음식을 먹게 만드는 비법을 적어놓고 있는 것 같다. 방송에서 보는 요리 프로그램 역시 금방이라도 따라하면 먹음직스런 요리를 만드는게 쉬워보인다. 하지만, 막상 그러한 요리법을 따라하다 보면 예상과 다른 맛을 지닌 음식이 탄생하곤 한다. 역시 요리를 하는 것을 보는 것과 요리를 직접 하는 것과는 차이가 있는 것이다.


그럼 요리법에는 어떤 요소들이 빠져있어서 원하는 맛을 내는 요리를 만드는게 힘든 것일까. 대부분의 요리책들은 요리에 들어가는 재료와 도구들(식자재)들이 모두 구비된 상태에서 소개되고 있다. 위의 테라 코따라는 요리를 하려면 무엇보다 배와 와인이라는 재료가 먼저 구비되어 있어야 하는게 당연하다. 그럼, 배는 어떤 것을 골라야할까. 그리고, 그렇게 종류가 많은 와인 중에서 어떤 것을 골라야할까. 이를 아는 것 역시 요리를 하는 과정 중에 하나일 것이다. 이러한 식재료를 선택하는 과정은 요리의 맛에 영향을 주는 아주 중요한 과정 중에 하나이다. 즉, SW를 만드는 과정에서 어떤 요소를 가지고 만들 것인지를 식별하고 정의하는 과정이 궁극적으로 필요한 것이다. 이러한 과정을 아키텍처링이라고 하는데, 어떠한 가이드나 방법론에서도 이러한 내용은 포함되어 있지 않다.


요리법에서 소개하는 내용들이 이러한 식재료를 선택하는 과정을 포함한다면 과연 맛있는 요리가 태어날까. 그리고, 식재료가 많고 복잡하다면 이러한 것들을 글로 표현하는게 의미가 있을까. 설사 글로 표현한다고 하더라도 너무나도 복잡해서 거의 몇 권의 책으로 나타날 것이고, 요리 하나를 위해서 얼마나 많은 지식을 갖추어야 하는지는 배보다 배꼽이 더 큰 상황이 연출될 수도 있다.


좋은 식재료를 구비해놓았다면 본격적으로 요리를 할 것이다. 요리법에는 정확한 양이 기록되어 있는 경우가 있는데, 만일 집에 이러한 양을 측정할 수 있는 기구가 없다면 어떻게 할 것인가. 그냥 눈대중으로 하면 어떨까. 혹은 요리 과정에서 간을 맛보면서 양을 맞춘다면...이러한 내용들 역시 요리법에는 없다. 그냥 요리하는 사람의 경험과 눈대중으로 해야 한다. 물론, 기구를 갖춘다면야 좋지만, 한끼 식사를 위해서 그러한 기구를 일부러 산다는 것은 일반 서민들에게는 어쩌면 사치이기도 할 것이다. 중요하고 거창한 요리가 아닌 이상은 대개 눈대중으로 간을 맞추는 정도일 것이다. 만일, 1인분 요리가 아니라 수십 수백인분의 요리를 한다면 1인분 기준의 양은 그냥 배수로 셈해서 해야 하는가. 이것 역시 그때 그때 달라질 것이다. 세밀하게 측정해서 간을 맛춘다고 정말 맛있는 요리가 만들어진다는 보장도 사실 없다.


SW를 만드는 과정에서 절차와 품질 기준을 상당히 강요하고 강조하는 경우가 있다. 이는 마치 요리법에 소개된 양과 절차를 준수해서 요리하는 것과 같다. 결국 요리란 맛있어야 하며, SW는 궁극적으로 동작해야 한다. 물론, 이러한 절차와 기준들이 맛의 품질을 높여주는데 많은 도움이 되는 것은 사실이다. 하지만, 요리사의 경험으로 기준에 맞지 않게 설탕 한 스푼 더 넣거나 덜 넣었다고 해서 그 요리가 맛이 없을 것이라고 판단하기는 힘들다. SW를 만드는 경험이 있는 사람들은 이러한 사실을 경험치로 알고 있다. 왜 요리에 넣는 양과 기준이 그렇게 나와야 하는지를 설명하라고 한다면 그냥 감각적이라고 밖에 설명할 방법이 없다. 음식의 맛은 음식을 구성하는 식재료들이 전반적으로 균형이 맞추어져셔 음식에 맞는 맛을 내는 것이다. SW는 그 구성요소들이 전체적으로 균형이 이루어져서 사용자의 요구에 맞게 동작할 때 의미가 있다. 때로는 정확한 양과 기준으로 인해서 이상한 맛을 내는 음식과 같이 너무나도 기술적인 냄새나 분위기에 의해서 사용자에게 외면을 받는 경우도 있다. 음식은 배고픈 사람에게 맛있게 먹고 포만감을 주는게 목적이듯이 SW는 이를 필요로 하는 사람에게 문제를 해결해주는게 목적이다. (SW를 필요로 하는 사람들은 음식보다 더 다양할 수 있다.)


책이나 가이드에 있는 SW를 만드는 과정은 음식을 만드는 요리법(recipe)에 비유할 수 있다. 요리법은 요리를 만드는 과정에서 참고하는 용도로만 의미가 있는 것이지, 그 이상의 용도로 사용하려고 한다면 더 이상 음식을 만드는 즐거움을 못느낄 것이다. 요리법으로 요리를 하는게 아니듯이 책이나 가이드, 혹은 표준으로 SW를 만드는게 아니다. 만드는 과정은 그보다 더 많은 보이지 않는 과정과 경험 요소들이 작용하기 때문이다. 고객에게 맛있는 요리를 제공하려면 이러한 보이지 않는 과정과 경험 요소를 더 활용할 수 있어야 한다.

저작자 표시 비영리 동일 조건 변경 허락
신고
  1. Favicon of http://swtest.co.kr BlogIcon 최영목 2012.08.31 05:22 신고

    요리법(레시피)는 아주 맛있는 요리를 제공할 수는 없겠지만 요리를 모르는 초보자에게는 아주 좋은 수단입니다.
    그런데 이렇게 적고보니 레시피에만 의존하는 수많은 프로젝트들이 있다는 것은 프로젝트를 수행하는 사람들이 스스로가 초보자라는 것을 인증하고 있는 모양세이고, 그 결과물로 어떻게든 돌아는가는 하는 시스템(맛은 없지만 어쩄든 '사람이 먹을수는' 있는 요리)이 나오게 되는 것이라는 생각도 드네요;;; ㅠㅠ

    • Favicon of http://homo-ware.tistory.com BlogIcon javauser 2012.08.31 11:07 신고

      정말 훌륭한 요리사라면 자신만의 요리를 만들고 레시피까지 만들 수 있어야겠지요....^^

대선이 가까와 오면서 보수와 진보의 이념 대결은 이제 뚜렷해지게 나타날 것이다. 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에 대한 강력한 믿음과 사상을 가져야 한다는 것이다. 그리고, 어떤 형태로든 이러한 내용이 표현되고 설득시키고 가시화시킬 필요가 있다.

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

+ Recent posts