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

배를 반으로 갈라서 껍질을 벗겨 일자 형태로 자른 다음, 냄비에 자른 배를 넣고, 설탕, 계피와 같이 배가 잠길 정도로 와인을 넣는다. 그리고, 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 신고

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

크리에이티브 커먼즈 라이선스
Creative Commons License
조직마다 규약과 제도를 통해서 업무 프로세스를 수행하게 되며, 이는 조직 구성원들의 행동을 제한하게 됩니다. 이런 규제나 제약에 관련되어서 조직의 특성마다 어떻게 이를 규약할 것인지는 다릅니다. 이번 농협 사태와 한복 사건을 계기로 IT 개발시에도 동일한 문제들이 발생되는 경우들이 있어서 몇가지를 거론하고자 합니다.

조직이 가지는 규약은 최초에 특정한 이유와 사건으로 인해서 생겨난 것이며, 이는 그 시대상을 어느 정도 반영하고 있습니다. 한복 사건의 경우, 어떠한 이유로 인해 생겨났을 것이며, 명시적으로 문서화되어 있지는 않았지만 (혹은 지침과 같은 형태로 문서화가 되었을 수도 있겠지만) 조직 구성원들에게 행동이나 업무 수행을 제약했을 것입니다. 아무튼 이러한 규약을 알고 있고, 마치 모든 기준을 이러한 규약을 통해서 지켜져야 한다고 생각하는 업무들은 행위의 정당성을 부여하게 됩니다. IT 개발 역시 수많은 제약들과의 싸움과 타협을 해야하며, 이러한 수고는 가이드나 템플릿이라는 이름으로 덜어주고자 만들어져 사용되고 있습니다. 하지만, 이러한 가이드나 템플릿을 지키지 않음으로써 손해를 보는 것은 당장 이를 업무에서 수행하는 개인이 됩니다. 만일, 특정 가이드나 템플릿과는 동떨어진 문서를 만들어내면 당장 감리나 인스펙션에서 손해를 보는 것은 뻔합니다.

가이드나 템플릿이 필요없거나 나쁘다는 얘기는 아닙니다. 한복 사태에서도 보듯이 예전의 특정 사건이나 사례로 인해(아마도 전체를 통틀어서 그리 자주 일어나지는 않았겠지만 전체 업무 프로세스에 지대한 영향을 미칠 수도 있는) 한번 정해진 규약의 틀은 조직에 빠르게 확산되고 정착되기 마련입니다. 그리고, 이러한 규약의 틀은 한번 정착되면 이에 대한 인식을 바꾸거나 틀을 없애는 것은 훨씬 더 어렵습니다. 만일, 최초의 규약이나 규제가 그리 강력하지 않은 권고의 수준이거나, 조직이 이해할 수 있고 동의할 수 있는 수준의 규정이었다면, 이를 적용하는데 있어서 다소 유도리가 있게 반응했을 것입니다. (조직이 상명하복식의 특성이 강하면 강할수록 유연성 있는 행동지침을 만들어내기가 어려울 것입니다.) 또한, 그로 인한 손해도 조직 차원에서 흡수하고 이를 융통성있게 받아들일 수 있는 특성을 가진다면 좀 더 매끄러운 업무 처리를 할 수 있을 것입니다. 가이드나 템플릿 역시 모든 프로젝트 관여자들이 지키지 않으면 안되는 것, 혹은 이외에는 아무것도 받아들이지 말아야 할 것으로 인식하게 되는 순간 한복 사태와 같은 일들이 비일비재하게 발생하게 됩니다. 업무 프로세스에 대한 발전이나 다양성을 인정하지 않는 형태의 가이드나 템플릿은 사실 없느니만 못합니다. 오히려 이를 만드는 사람에게 더 많은 고통과 경직성을 가지고 올 뿐입니다.

또한, 관리 조직에서는 가이드나 템플릿이 있다는 것만으로도 관리에 대한 부담을 경감시킨다는 인식을 갖게 합니다. 이는 마치 법이나 규제만이 모든 행동을 규약할 수 있다고 생각하는 위정자와도 같습니다. 법이나 규제가 필요한 부분은 최소로 하고, 교육과 문화를 바꾸어서 인식의 전환을 하게끔 하는 것이 최선이지만, 빠른 시간 안에 효과를 보고 그러한 법과 규제를 만드는 것이 마치 많은 일을 한 것인 양 착각하는 관리 조직으로 인해 더 많은 희생자들이 발생하게 됩니다. 이는 엄격하게 말하면 관리 조직으로써 책임을 그 조직 구성원들에게 미루는 행위와도 같습니다. 그러한 환경에서는 조직 구성원들은 가이드나 템플릿이 없으면 업무를 진행하지도 못하고 거기에 쓰여져 있는 대로 쫓아가는데 바쁘기만 할 뿐 전혀 창조적이거나 새로운 것들을 만들 능력을 점점 소멸하게 됩니다.

이번 농협 사태는 그 결과와 파장이 주목되는 부분입니다. 어떠한 이유로 인해서 문제가 발생되었는지는 자세하게는 알지 못하지만, (그리고 그 안에 얽혀있는 갈등과 문제가 무엇인지도 정확하게 드러나지도 않았지만) 앞으로 그러한 사태를 방지할 수 있는 농협의 대처 방법과 이를 주시하고 영향을 받는 다른 조직의 대처 방법에 대해 상당히 주목이 가는 부분입니다. 사실, 특정 개발자에 의한 데이터 삭제는 (의도적이든 그렇지 않든 간에) 가능한 일입니다. 이는 다른 규제나 가이드, 혹은 아주 비싼 장치(혹은 솔루션/패키지 등)를 통해서 아예 없어질 행위나 업무가 아닙니다. 벌써부터 개발 조직의 노트북 규제가 입방아로 돌고 있는 상태입니다. 이러한 규제가 농협 사태를 막아줄 것이라고 믿는 사람은 아무도 없을 것입니다. 가능한 일을 막는 방법은 그러한 일이 발생했을 때에 (물론 사전에 강압적이거나 일률적인 방법이 아닌 다양한 방법을 통해서 만에 하나 일어날 수 있는 일을 방지해야 겠지만) 이를 얼마나 빨리 그리고 효율적으로 원상태로 되돌릴 수 있는가에 달려 있습니다. 만일 이번 농협 사태로 모든 개발자에게 데이터 삭제 명령어를 금지한다고 강력하게 규제한다면, 어느 개발자가 이를 순순히 규제대로 하겠습니까? 어떤 방법을 동원해서라도 데이터 삭제를 하는 사람들도 분명 있을 것이며, 그냥 난잡하게 데이터를 쌓아놓아 시스템에 더 큰 문제를 발생시킬 수도 있을 것입니다. 

실수나 실패는 어느 누구도 겪으며, 이는 조직에게도 해당됩니다. 이를 어떻게 극복하고 더 나은 상태로 갈 것인지, 혹은 실수나 실패를 용납하지 못하고 아예 그런 일이 없게 강력하게 규제를 할 것인지는 조직이 결정할 사항입니다. 다만, 그러한 결정이 내부 구성원들의 합의와 공감대를 형성한 것인지, 단순히 책임을 전가하기 위한 관리 조직의 일방적인 견해인지가 다를 뿐입니다. 얼마 만큼의 자유를 조직 구성원들에게 부여할 것인지에 대한 해답은 조직이 구성되고 유지되는 한 늘 찾아야하는 합의점입니다. 그리고, 그러한 자유에 대해서 어떻게 책임을 부여하고, 침범된 자유에 대해 어떻게 보상할지에 대한 부분도 늘 고민해야할 부분입니다. 규제나 규약, 가이드나 템플릿은 이러한 노력과 고민을 한번에 해결할 수 있다는 착각을 만드는 신기루와 같습니다.
저작자 표시 비영리 동일 조건 변경 허락
신고

+ Recent posts

티스토리 툴바