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

최동원. 1958년 5월 24일 생, 2011년 9월 14일 대장암으로 54세로 타계. 꼭 일년 전 쯤 한국 야구의 레전드는 우리 곁을 떠나갔다. 최동원이 타계했다는 소식을 듣고, 그의 전기나 관련 책을 읽어보고 싶은 마음에 '거인의 추억'(실크캐슬, 정범준)이라는 책을 집어 들었다. 위키피디아에서는 최동원을 '무쇠팔' 이라는 별병을 싣고 있다. 그가 한국의 대표 간판 투수라는 사실 만큼은 어느 누구도 부인할 수 없을 것이다.


 

사실 남자들은 야구를 좀 해보고, 즐겨본다고는 하지만, 사회/결혼 생활에 야구팬이나 광처럼 지켜보지는 못하는게 현실인 것 같다. 늘 야구장 한번 가봐야겠다라는 마음만 가진채 올 한해도 코리안 시리즈나 WBC같은 경기에 누가 나가는가 정도의 관심만 보일 정도이다.


그런 내가 스스로 이 책을 선택한 이유는 '정범준'이라는 저자의 영향도 있다. 그는 이 책을 쓰고, 이후에 '마흔, 마운드에 서다'라는 책을 출간하는데, 이 책에서 저자는 야구를 하고 싶었던 어릴 적 꿈을 사회인이 되어서 아마 야구를 도전하면서 겪었던 내용을 솔직하게 쓰고 있다. 저자는 아주 평범한 일반 직장인임에도 불구하고 나름대로 더 나은 목표(책을 쓰겠다는 생각과 야구를 해보겠다는 포부)를 하나씩 이루어가나는 모습에 살짝 반한 것도 있다. 이책에 자주 언급되는 이전 책인 최동원의 자칭 전기라고 하는 '거인의 추억'이 작년 최선수의 사망 소식으로 순간 머리에 떠올랐던 것이다.


사실 이책은 그냥 최동원의 관련된 자료들을 수집하여 저자 나름대로의 시각으로 정리한 것에 불과하지만, 야구가 기록의 경기인 만큼 그 자료는 최동원이라는 선수를 보여주기에 충분하다고 느꼈다.

우선 70년대 말 80년대 초를 주름잡았던 최동원의 실력은 그가 중학교/고등학교 시절의 기록만으로 대선수가 될 것이라는 믿음을 주기에 충분했다. 최동원이 고등학교 시절, 그러니까 70년대 중후반은 야구에 대한 인프라 역시 많이 부족한 상황이었고, 특히 밤에 경기를 한다는 것은 있을 수도 없기에 무승부가 9회 이후로 발생하는 경우에는 그 다음날에 이어서 계속하는 경우도 있었단다. 그리고, 팀의 에이스였던 최동원은 그 이전의 경기와 그 다음날의 나머지 경기, 그리고, 그날의 남은 경기를 연속해서 던지는 경우도 있다고 한다.


작년 말에 개봉했던 최동원과 선동렬의 맞대결을 그린 '퍼펙트 게임'. 이 경기에서 양팀의 에이스들은 연장 15회 동안 총 441개의 공을 던진다. (최동원 209개, 선동렬 232개) 지금으로써는 투수가 100개 이상의 공만 던져도 많이 던졌다고 교체를 고려해야 한다고 하는 말을 들어보면 많은 차이를 느낀다. 이들의 자존심을 건 승부는 누구라도 한번쯤은 그러한 승부를 해보고 싶다라는 욕망을 품게 만들기도 한다.


최동원에 대한 평가는 그의 선수 생활 이후의 삶을 보고 평가를 하는 경우도 있다. 특히, 프로야구 선수협회를 만드는 과정과 은퇴 이후 정계나 방송계의 외도를 보고 이런 저런 말들이 많다. 그런 과정은 최동원 스스로가 한계라고 느꼈던 부분들을 나름의 방식으로 그 한계를 넘으려고 했었고, 넘어서기를 주저하지 않으려는 면 때문일 것이라고 본다. 그는 스스로를 한계를 뛰어넘기를 주저하지 않은 것 같다.


야구에 관한 또 다른 영화와 책이 비슷한 시기에 나왔다. '머니볼(moneyball)'은 미국 메이저리그의 한 야구팀 구단장 이야기이다. 돈이 많고 화려한 세계의 내용이 아닌, 돈이 없고 실력이 없다고 평판난 팀의 단장 이야기이다. '빌리 빈' 이라는 '오클랜드 애슬래틱스' 팀의 단장은 돈이 없는 구단을 위해서 아주 저렴한 비용의 선수들을 영입하게 된다.


미국의 프로야구는 거액의 몸값이 증명하듯이 최고의 선수를 영입하는 데에 모든 구단이 초점이 쏠리고 있다. 하지만, '빌리 빈'은 그러한 선수를 영입할 돈이 없기에 새로운 방식을 도입한다. 물론, 영화에서 조연으로 등장하는 아비리그 출신의 직원을 고용하여 기존의 선수 기용 방식을 전혀 다른 각도로 보기 시작한다. 즉, 얼마나 홈런을 많이 치고, 얼마나 빠른 공을 던져 삼진을 잡는 소위 인기에 영합하는가보다 얼마나 출루율과 장타율이 좋은지를 평가한 것이다. 예를 들어, 포볼이나 상대팀의 에러에 많은 루수를 기록한 선수를 더 중요시 본 것이다. 그 결과는 애슬래틱스는 많은 야구팀 중에서 승리 확률을 높이면서 플레이오프에도 여러번 진출하기도 한다.


야구의 기록은 어떠한 관점에서 보는가에 따라서 다양해질 수 있다. 또한, 필드에서 발생하는 모든 내용이 기록되는 것도 아니다. '빌리 빈'은 그러한 기존의 틀과 한계를 다른 시각을 통해서 전혀 새로운 틀을 만들었고, 이는 실제로도 성과가 있었다. '뉴욕 양키스와 같이 하는 것은 이들을 따라잡을 수 없다는 것을 의미한다. 양키스를 이길려면 전혀 다른 룰이 필요하다'라는 신념으로 기존의 다른 팀이 추구하던 방식을 버리고 새로운 게임의 법칙을 만들어낸 것이다.


'빌리 빈'이 만든 방식이 성공을 보장한다고는 할 수 없지만, 자신의 한계를 분명 뛰어넘고자 했고, 또 그렇게 실행했기에 최소한의 좋은 결과를 만들 수 있었다.


한계를 인정하고 느끼는 것은 누구나가 마찬가지이다. 하지만, 한계를 뛰어넘는 사람은 분명 있게 마련이고, 그러한 한계를 뛰어넘은 사람만이 맛볼 수 있는 것이 분명 있다. 하지만, 한계를 뛰어넘는 과정이 상당히 많은 고민과 어려운 과정이 필요로 한다는 것은 사실이다. 그러한 고민과 과정이 설사 한계를 뛰어넘는데 실패했다고 하더라도, 스스로에게는 많은 자산과 경험이 될 것이다. 그리고, 그 다음에 또 다른 한계를 넘을 때에는 분명 그 자산과 경험으로 인해서 이번에는 더 잘 뛰어넘을 수 있을 것이다.

저작자 표시 비영리 동일 조건 변경 허락
신고
크리에이티브 커먼즈 라이선스
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 관점에서도 보수와 진보를 구분할 수 있을까? 이러한 물음에 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

티스토리 툴바