저는 현재 회사에서 실무자로 일하고 있습니다. 일을 하며 관리자들에게 종종 아쉬움을 느낄 때가 있습니다. 이런 아쉬움은 여러 가지 사건들을 경험하며 생기는데요, 저는 앞으로 이러한 아쉬움들을 제 시각에서 정리해보자 합니다.

첫 글로써, 최근에 생각해보았던 '관리자의 의견과 대립하는 실무자의 의견'라는 주제에 대해 써보고자 합니다. 때때로 실무자와 관리자 사이에 논쟁이 벌어질 때가 있습니다. 예를 들어 실무자는 A라는 안으로 일을 추진해야 한다고 강력히 주장하는 데, 관리자는 B라는 안으로 일을 추진해야 한다고 주장하는 경우를 생각해볼 수 있습니다. 왜 이런 일이 발생을 할까요?

제가 보기에 관리자의 의사결정은 보통 추상적인 수준에서 이루어집니다. 관리자는 현실적 여건상 세부적인 것들을 모두 상세히 알기가 힘듭니다. 따라서 마치 어떠한 현상을 숫자로 간단히 표현하는 것처럼, 세부적인 것을 좀더 단순한 형태로 변환하여 개념적으로 바라보고 그것을 바탕으로 의사결정을 합니다. 하지만 이로인한 부작용이 생깁니다. 왜냐하면 추상화라는 것은 사고할 때는 유용하지만 어찌됐던 세상은 구체적인 상황 속에서 돌아가고 있기 때문입니다. 관리자는 시간이 지남에 따라 추상적인 사고에 익숙해지고,  결국 구체적인 부분에 대한 감각을 잃어버리게 됩니다. 이 경우 제가 보아왔던 관리자들이 취하는 행동은 크게 두 가지 정도가 있었습니다.

하나는 실무자의 의견을 존중하는 것입니다. 즉, 비록 실무자의 의견에 대해 깊이 이해할 수는 없지만 본인이 관리자로써 가지는 한계를 인정하고 이해를 시도하며 의사결정을 하는 것입니다. 이것은 관리자가 실무자를 현장 전문가로써 인정하고 신뢰한다는 것을 의미합니다.

다른 하나는 이해를 할 수 없기 때문에 실무자의 의견을 받아들이지 않고 추상적인 수준의 사고를 통해 나온 본인의 주장만을 거듭하는 것입니다. 이 경우 실무자는 포기하고 관리자의 의견을 따르거나, 아니면 관리자가 이해할 수 있게하기 위해 근거를 계속적으로 제시합니다. 하지만 저는 이러한 성향을 가지는 관지자가 실무자의 의견을 채택하는 경우를 거의 보지 못했습니다.

첫 번째 실무자를 인정하고 신뢰하는 관리자의 경우는 제가 보아온 가장 좋은 사례로써 저는 더 이상 할 얘기가 없습니다. 물론 실무자의 의견에 근거하여 의사결정을 한후 잘못된 방향으로 갈 수도 있습니다. 어쨌든 관리자는 실무자보다 더 많은 정보를 가지기 때문에 의사결정에 있어 더 나은 통찰력을 가지는 경우가 많기 때문입니다. 하지만 비록 때로 실패가 있다 하더라도 관리자가 실무자를 인정하고 신뢰한다면 실무자는 어떠한 형태로든 그것을 보답한다고 봅니다. 그것이 강한 책임감의 형태로 나타나든 혹은 자신감으로 인한 적극적인 업무자세로 나타나든 말입니다. 결국 실패로 잃어버린 것보다 더 많은 유익을 얻을 수 있을 것입니다.

두 번째 본인의 주장만을 거듭하는 관리자의 경우가 참 어려운 경우입니다. 이 경우 다행히 합리적인 관리자는 본인이 이해할 수 있도록 근거를 요구합니다. 하지만 이 때도 두 가지 정도의 문제점이 있습니다. 첫째는 근거를 제시하는 것에 미숙한 실무자들이 많다는 점입니다. 이것은 실무자의 문제로써 다른 말로 하자면 의사소통 능력이 떨어진다고 볼 수 있습니다. 둘째는 실무자가 근거를 잘 제시함에도 불구하고 관리자가 받아들이지 않는 경우입니다. 이런 경우는 관리자가 실무를 제대로 이해하지 못하기 때문에 발생합니다. 첫째 문제에 대해 제가 생각하는 해결책은 실무자가 노력해야 한다는 것입니다. 의사소통은 실무자가 신경 쓰지 않아도 될 부분이 아니라고 생각합니다. 오히려 실무자들이 의사소통 능력의 중요성을 인식하고, 본인이 갖춰야 할 매우 기본적인 능력 중 하나로 생각하는 것이 필요하다고 봅니다. 둘째 문제는 관리자의 변화가 필요하다고 생각합니다. 가장 이상적인 모습은 관리자가 실무에 대한 이해의 폭이 넓어 실무자와 원활한 의사소통을 하는 것이라고 봅니다. 하지만 현실적 여건으로 인해 실무를 제대로 이해하지 못한다면 본인의 한계, 즉 추상적인 사고의 한계를 겸허히 인정하고 구체적인 것을 항상 다루는 실무자의 의견을 존중하는 것이 해결책이 될 수 있을 것이라 생각합니다.

주경야독 : 낮에는 농사짓고, 밤에는 글을 읽는다는 뜻으로, 어려운 여건 속에서도 꿋꿋이 공부함을 이르는 말

In computer science, divide and conquer (D&C) is an important algorithm design paradigm based on multi-branched recursion. A divide and conquer algorithm works by recursively breaking down a problem into two or more sub-problems of the same (or related) type, until these become simple enough to be solved directly. The solutions to the sub-problems are then combined to give a solution to the original problem.

출처 : http://en.wikipedia.org/wiki/Divide_and_conquer_algorithm

(위 위키 페이지에서는 나누어 해결하기가 가진 여러 가지 장점들을 얘기하고 있습니다. 이 글은 그 중 'Solving difficult problems' 에 대한 상세한 내용이라고도 볼 수 있습니다.)

- 모든 자연수는 짝수 아니면 홀수이다.
- 짝수는 2로 나누었을 때 정확히 나누어 지는 즉 0이 남는 수이다.
- 홀수는 2로 나누었을 때 1이 남는 수이다.
- 자연수 끼리의 덧셈과 곱셉은 항상 자연수이다.(닫힘 성질)

짝수는 아래와 같이 2에 곱으로 표현되는 모든 자연수이다.

n = 자연수
짝수 = 2 * n

따라서 짝수와 짝수의 합은 아래와 같이 나타낼 수 있다.
= 2 * n + 2 * m
= 2 * (n + m)

(n + m)의 결과는 자연수의 덧셈에 대한 닫힘 성질에 따라 자연수가 된다. 이 식은 결국 '2 * 자연수'의 형식을 갖게되며 이 형식은 짝수의 정의를 만족하기 때문에 짝수와 짝수의 합은 항상 짝수라는 것이 증명된다.

홀수는 아래와 같이 짝수에 1을 더한 수라 할 수 있다.

n = 자연수
홀수 = (2 * n) + 1

따라서 홀수와 홀수의 합은 아래와 같이 나타낼 수 있다.
= (2 * n) + 1 + (2 * m) + 1
= (2 * n) + (2 * m) + 2
= 2 * (n + m + 1)

따라서 정리1에서 언급했던 것처럼 짝수의 정의를 만족시키기 때문에 홀수와 홀수의 합은 항상 짝수임이 증명된다.

짝수와 홀수의 합은 아래와 같이 나타낼 수 있다.
= (2 * n) + (2 * m + 1)
= 2 * (n + m) + 1

위에서 (n + m)은 정리1에서 언급한 자연수의 덧셈에 대한 닫힘 성질에 따라 자연수가 된다. 따라서 정리2에서 업급한 홀수의 정의를 만족시키기 때문에 짝수와 홀수의 합은 홀수이다.

예전 어린 시절 소프트웨어 개발자라는 것은 제게 동경의 대상이였습니다. 그때는 소프트웨어 개발에 대해서 잘 몰랐습니다. 때때로 막연하게 제가 소프트웨어 개발을 하는 모습을 상상해보았습니다. 낭만적인 상상들이 제 머리를 지나가고 상상만으로도 너무 즐거웠습니다. 가끔 게임 잡지나 PC전문잡지에서 유명 개발자들의 인터뷰 내용을 보았습니다. 이런 사람들을 닮고 싶다라고 생각했고 마음속에 열정이 타올랐습니다. 제게 있어 소프트웨어 개발자가 되는 것은 꼭 이루고 싶은 꿈 중 하나였던 것이였습니다.

놀랍게도 꿈이 이루어졌습니다. 저는 지금 소프트웨어 개발자로 일하고 있습니다. 소프트웨어 개발자가 되어 일해보니 제가 예전에 상상했던 것처럼 모든 것이 낭만적이지 않긴 합니다. 그렇지만 여전히 소프트웨어 개발은 멋진 일이라 생각됩니다. 또한 저는 소프트웨어 개발을 통해 많은 즐거움을 느끼고 있습니다.

그리고 최근 새로운 동경에 대상이 생겼습니다. 새로운 대상은 바로 수학입니다. 이 느낌은 어린 시절 소프트웨어 개발자가 되고 싶어했던 마음과도 유사합니다. 저는 학창시절 게으른 시간을 보낸탓에 기초적인 수학 능력이 매우 부족합니다. 어쩌면 아는 것이 거의 없을지도 모릅니다. 그렇지만 수학을 배우는 것이 제게 큰 기쁨을 줄 것 같고 수학을 이용해서 무엇인가 가치있는 일을 할 수 있을 것 같은 느낌이 듭니다.

얼마 전 저는 하디라는 수학자가 쓴 수필 집을 읽고 있었습니다. 그리고 그 책에 통해 2,000년전 유클리드가 증명한 '소수는 무한히 존재한다'라는 증명에 대해 이해할 수 있었습니다. 사실 책에서 밝히기로는 일반인도 이해할 수 있는 매우 쉬운 정리라고 합니다. 하지만 제게는 이 증명에 대한 이해가 매우 의미있는 한 걸음으로 느껴졌습니다. 마치 예전에 아무것도 모르면서 무작정 GW베이직을 띄우고 짦은 코드를 만들어 무엇인가를 출력한 후에 느꼈던 기쁨과도 유사한 것 같습니다. 별거 아닌걸 알면서도 무척이나 자랑스럽다고 해야할까요?

솔직히 제가 수학에 뭔가 재능이 있다는 생각은 들지 않습니다. 그렇지만 흥미가 있고 관심이 간다는 것이 자꾸 수학을 곁눈질하는 유일한 이유인 것 같습니다. 인터넷을 돌아다니다보면 매우 기초적인 내용을 꾸준히 블로그에 올리는 블로거들이 있습니다. 저 역시 이와 같이 앞으로 별거 아니겠고 매우 초보적인 내용이겠지만 수학에 대해서 느끼고 배우는 것을 블로그를 통해 자주 정리해보고자 합니다. 새롭게 생긴 동경이 좋은 열매를 맺었으면 좋겠습니다.

추신. 이 글은 2008년 9월 경에 썼던 글인데, 지금 마무리 하게 되네요. 지금도 제 마음은 변하지 않았으며 최근에도 대수학을 열심히 공부 중입니다. 다만 글을 많이 올리지는 못했네요. :)

2008/09/04 ~ 2009/03/16

최근 주위를 보면 개발자들 사이에서 코드 가독성에 대한 관심이 높아지고 있는 것 같습니다. 아마 켄트벡이나 마틴 파울러 같은 대가들이 자신의 블로그를 통해 코드 가독성의 중요성을 강조하고 있기 때문일 것입니다. 켄트벡이 최근에 쓴 Implmentation Pattern을 관통하는 핵심 아이디어 중 하나는 다른 개발자들과의 의사소통입니다. 즉, 내가 만든 코드에 담겨있는 의도를 다른 개발자에게 잘 전달할 수 있어야 한다는 것입니다. 또한 이에 관한 마틴 파울러의 명언이 있습니다. 바로 '좋은 프로그래머는 사람이 이해할 수 있는 코드를 만든다.'입니다.

저는 올해 들어 개인적으로 프로젝트를 시작했습니다. 프로젝트를 시작하게 된 여러 동기 중 하나는 이렇습니다. 저는 최근에 출시된 스포츠카를 사고 싶었습니다. 그런데 가격을 알아보니 제가 버는 돈으로는 구매는 하더라도 유지가 힘들다는 판단이 들었습니다. 힘이 빠졌습니다. 어떻게 하면 스포츠카를 살 수 있을까 생각해보았습니다. 제가 내린 결론은 스스로 더 많은 가치를 산출 해야한다는 것이였습니다. 결국 저는 재미 있으면서도 이후 저의 작은 꿈을 이루는 데 도움이 될 만한 것으로 Robust-Task개발을 생각해냈습니다. 좀 세속적이긴 하지만 재밌는 동기죠? ㅋ

동기야 어찌됐든 창의적인 코딩에 굶주려 있던 저는 저는 너무도 즐겁게 개발을 진행했고, 개발을 하며 여러 지인들에게 의견을 구했습니다. 여러 지인들의 보편적 의견은 아이디어는 괜찮다(하지만 난 참여 안 하겠다 ㅋ)는 것이였습니다. 그래도 괜찮아 보인다는 말에 힘을 얻어 진행하다보니 어제 'Robust-Task 0.1 concept' 버전을 릴리즈하게 되었네요.

Robust-Task의 주요 의도는 복잡하고 긴 업무흐름(Business Flow)을 가독성 좋은 코드로 표현하자는 것입니다. 예를 들어 어떤 작업을 실행하는데 3번 이상 실패하면 뭔가 특별한 처리를 해주어야 한다고 가정해봅시다. 머리 속에 어떤 유형의 코드가 떠오르시나요? Robust-Task를 이용하면 이런 작업을 구현할 때 아래와 같이 두 가지 유형의 표현이 가능합니다.

new ToBeFailedTask()
  .wrapByRetryFailover()
    .failover(new LoggingFailoverTask())
    .retryCount(3)
  .execute();
    
retryFailOver(
    task(new ToBeFailedTask()),
    failover(new LoggingFailoverTask()),
    retryCount(3)
).execute();

어떤가요? 간단한가요?

또한 순차적인 작업의 흐름에 대해 아래와 같은 표현도 제공합니다.

new TaskChain()
  .add(new GenesisCoupeTask())
  .add(new TuscanyCoupeTask())
  .add(new TiburonCoupeTask())
.execute();

위 코드는 추가된 순서대로 정확히 실행이 됩니다.

더욱 재밌는 것은 이 두 가지 형태를 결합할 수 있다는 점입니다. 예를 들어 아래와 같은 표현이 가능합니다.

new TaskChain()
  .add(new GenesisCoupeTask())
  .add(new TuscanyCoupeTask())
  .add(new TiburonCoupeTask())
.wrapByRetryFailover()
  .failover(new LoggingFailoverTask())
  .retryCount(3)
.execute();

retryFailOver(
    task(new TaskChain()
              .add(new GenesisCoupeTask())
              .add(new TuscanyCoupeTask())
              .add(new TiburonCoupeTask())),
    failover(new LoggingFailoverTask()),
    retryCount(3)
).execute();

위 예제는 RetryFailover라는 Robust-Task에서 제공하는 Task Decoration을 이용하여 순차적인 흐름을 가지는 Task Chain에 대해 RetryFailover 기능을 부여해주는 것입니다. Task Decoration은 0.1 concept 버전에서 4개 정도가 제공되고 있는데요. 아래와 같이 전처리 후처리를 처리해주는 Task Decoration도 있습니다.

new GenesisCoupeTask()
  .wrapByAspect()
    .before(new TiburonCoupeTask())
    .after(new TuscanyCoupeTask())
  .execute();

aspect(
    beforeTask(new TiburonCoupeTask()),
    mainTask(new GenesisCoupeTask()),
    afterTask(new TuscanyCoupeTask())
).execute();

결론적으로 Robust-Task는 Task와 Task Chain 그리고 Task Decoration을 이용하여 업무흐름을 쉽고 이해하기 쉽게 표현하기 위한 프레임웍이라 할 수 있겠습니다.

이렇게 간단하지만 예제 위주로 소개를 드렸습니다. 전달이 잘 되었는지는 모르겠네요. 현재 Robust-Task는 오픈소스로 개발되고 있으며 구글코드에서 호스팅을 받고 있습니다. 오픈소스이기 때문에 소스에 패치를 해주시거나 혹은 메일링에서 의견을 제시함으로써도 프로젝트 참여가 가능합니다. 관심이 가는 분들의 많은 참여와 의견 부탁드립니다.

[프로젝트 홈 바로가기]
[프로젝트 한국 메일링 리스트 바로가기]
[Robust-Task 0.1 concept 소개 문서 바로가기]