Ting 이네 Software 이야기

*  leader가 담당자의 기술적인 능력을 신뢰하지 않을때.

보통, leader가 기술적으로 뛰어나거나, 실무자가 기술적으로 미숙한 경우 많이 볼 수 있다. 이 경우, leader는 담당자가 report하는 사항에 대해 기술적인 detail을 모두 다 알려고 하고, 기술적인 문제에 대한 guide를 하길 원한다.
실제로 leader의 해당 분야에 대한 기술적인 역량이, 담당자보다 뛰어난  경우, 이런 방식이 효과적일 수 있다. (예. 신입사원과 경력사원의 사수-부사수, 혹은 멘토-멘티 의 관계.)
그렇지만 (실무자의 역량이 조금 부족하다고 하더라도) 실무자 보다 leader가 해당 분야의 기술적인 역량이 뛰어난 경우는 거의 없다.
그럼에도 불구하고, leader가 해당 실무자의 기술적인 능력을 신뢰하지 못하게 되면, 실무적인 보고 사항에 대한 세세한 부분까지도 알고자 하게 된다.
따라서, 실무자는 실무의 상세한 부분을 leader에게 설명해서 이해시켜야 하게 되고, leader의 '미숙한' 기술적인 질문에 답해주어야 한다. 이는 실무자에게 상당한 overhead로 작용하게 된다.
이런 관계의 reporting line이 길어지면 길어질수록, 효율은 급격하게 떨어지게 된다.

의사결정을 해야할 경우는 leader는 reporting을 받으면서 - 담당자를 믿지 못하므로 - 좀 낫다고 생각되면 몇몇 다른 실무자들을 동반할 지도 모른다.
이 경우 문제는 좀더 심각해진다. 올바른 방향으로 의견이 잘 정리되어 모아 진다면 좋겠지만, 그렇지 않은 경우, 참석한 모든 사람들 사이에 공감대가 형성되기 전까지는 회의가 계속되는 비효율이 발생하게 된다.
특히, 중간 중간에 사람을 좀더 불러 들이는 것은 더욱 안 좋다. 회의에 참석하게되는 실무자들 역시 문제의 기술적인 detail까지 알고 싶어할 것으므로, 담당자는 이들 모두에게 또 다시 반복적으로 기술적인 설명을 해야 한다.
Leader의 요청에 의해 참석한 실무자가 기술적으로 뛰어날 수도 있겠으나, 해당 분야에 대해서 담당자 보다 더 잘 아는 경우는 거의 없다.
따라서, 담당자는 leader를 위해서 그러했듯이 다시 회의에 뒤늦게 합류한 실무자를 위해 같은 설명과정을 계속해서 반복해야 한다.
그러므로, 이런 경우는 회의하는 사람의 숫자를 될 수 있으면 줄이는 편이 좋다.
"좀더 많은 사람의 생각이 모이면 좀더 좋은 생각이 나온다."라는 말은 평등한 구조의 회의에서 성립되는 말이다.
보통의 회사에서 "평등한 구조"는 존재 하지 않는다. 노파심에서 많은 사람들을 불러 들이기는 하나, 실제로 의사결정에 관여하는 사람은 소수일 뿐이다.
실제로 회사에서 다수의 사람들을 모아 놓고 회의가 진행되는 모습을 보면 소수 (이것도 20:80 법칙을 적용 받는지는 모르겠지만...)의 사람들이 발언권을 독점하고 나머지 사람들은 꿔다놓은 보릿자루처럼 머릿수만 채우고 않아 있는 경우가 대부분이다.
왜 이런 문제가 발생하는지는 여기서 논의하지 않기로 하자. 단, 현실이 그러하다는데는 큰 이견이 없을 거라고 본다.
따라서, 차라리 의사결정에 필요한 최소한의 인원으로 회의를 진행하는게 오히려 나아 보인다.
실무자가 기술적인 내용을 일일이 설명해야할 비용도 줄어 들고, 회의 참석자들간 공감대를 만들어 내기도 더 쉽기 때문이다. 잘못될 결정을 할 가능성은? 필자가 보기에는 별 차이가 없다.

* leader가 자기 자신의 기술적인 역량이나 실무적인 역량에 자신감이 없을 때.

실무를 떠난지 오래된 leader에게서 종종 볼 수 있다. management가 주 업무가 되면서 실무에 대한 '감'을 잃어버리게 된 경우다.
이 경우, leader는 기술적인 지식이 필요한 모든 회의/논의에 실무자들을 불러 들인다.
예를 들면, 2시간의 회의에, leader한명, 실무자 10명이 들어가서, 실무자들은 말 그대로 그냥 '듣고만' 나오는 경우다.
leader는 언제 나올지 모르는 기술적인 문제를 상의하기 위해서 실무자들을 전부 이끌고 들어간다. 그렇지만, 실제 이런 문제에 답해 줄 수 있는 기회를 갖는 실무자는 한 두명 뿐이다. 나머지는 말 그대로 "시간만 때우고 머릿수만 채우는" 겪이 된다.
이런 일이 반복될 경우, 실무자는 시간을 뺏기는 것은 물론, 업무에 집중하기도 힘든 상황이 된다.

to be updated...

이라는 유명한 말이 있다...
오늘 갑자기 든 생각인데... 마찬가지 내용이 회의에도 적용되지 않을까?
회의에서, 윗사람의 주장을 반대하는 사람보다 나쁜 사람이 아무 반응이 없는 사람이 아닐까?
관심 자체가 없다는 이야기니...

내가 어떤 회의를 이끌 때는 이 점을 항상 염두해 두어야 할 것 같다....
반대하는 사람은 찬성하는 사람과 마찬가지로, 관심도 있고 잘 해 볼려는 열정도 있는 사람이란걸...

* common

+ '-rdynamic' is not supported.
  android dynamic linker allows 'undefined symbol' only for weak symbol.(See (*1))
+ 'tmpfile()' function always returns NULL. "No such file or directory!"
+ 'strtod()' doesn't support '0xXXXX' format.

* NDK 8

'regex.h' exists in 'include'. But function bodies are not in library.

* NDK 9

'pthread_rwlock_xxxx' is declared in 'pthread.h'. But body is missing in library.
'pthread_exit' is declared without 'noreturn' attribute.
'regex' functions doesn't work as it should be. (bug? or not-implemented yet?? I have no idea.)

to be continued...

===== Details =====

(*1) : '-rdynamic' and 'weak' symbol (Updated at 2011-Aug-29)

Here is sample code to for testing 'weak' symbol at Android.

[ main.c ]
#include <dlfcn.h>
#include <stdio.h>

int g_d;

void
main() {
    void* handle;
    void  (*prf)(void);

    g_d = 369;

    handle = dlopen("/data/libgtst.so", RTLD_LAZY);
    if (!handle) {
        printf("Fail to load library\n");
        return;
    }

    prf = dlsym(handle, "print_g");
    if (NULL != dlerror()) {
        printf("Fail to get symbol print_g\n");
        return;
    }

    (*prf)();
    printf("=== DONE! ===\n");
}

[ lib.c ]
#include <stdio.h>

extern int g_d __attribute__((weak));

void
print_g(void) {
    printf("==> %d\n", g_d);
}

[ Android.mk ]
LOCAL_PATH := $(call my-dir)

include $(CLEAR_VARS)
LOCAL_MODULE := libgtst
LOCAL_SRC_FILES := lib.c

LOCAL_CFLAGS :=
LOCAL_C_INCLUDES += $(NDK_PROJECT_PATH)
include $(BUILD_SHARED_LIBRARY)

include $(CLEAR_VARS)
LOCAL_MODULE := test
LOCAL_SRC_FILES := main.c
LOCAL_CFLAGS :=
LOCAL_LDFLAGS :=
LOCAL_C_INCLUDES += $(NDK_PROJECT_PATH)
include $(BUILD_EXECUTABLE)

----- Test Steps -----
* build above codes at Android NDK
adb push libgtst.so /data/libgtst.so
adb push test /data/test
adb shell /data/test
==> 369
=== DONE! ===

to be continued...

아래는 모두 필자 개인의 생각임을 미리 밝힌다.

우리나라에서 SW산업은 그 역사가 짧다. 그래서 아직 제대로 된 체계가 잡혀있지 않다.
또한 SW 프로젝트에 대한 성과를 측정하는 방법 또한 체계적으로 정리되어 있지 않은 관계로, SW쪽 경력을 가지고 승진을 하는 것도 쉽지 않은 것이 현실이다.
(SW쪽에서 대단한 일을 했다고 내세울 수 있고 받아 들여질 수 있는 판단 기준이 정립되어 있지 않기 때문이다.)
이련 현상은 SW개발이 주가 되지 않는 embedded쪽에서 더욱 극명하게 나타나는데,  어떤 제품이 크게 성공했을 때에도 SW쪽에서 특진을 하거나 노고를 치하 받는 경우는 드물다는 것이 이를 잘 반영해 주고 있다.

앞서 이야기한 바와 같이 이런 모든 부작용의 근본 원인은, 합리적인 측정기준이 없다는데 있다. 측정할 방법이 없기 때문에, 성과에 대한 보상을 할 수도 없고, 잘한 것 못한 것을 구별할 수도 없다. 한 마디로, 주먹구구식으로 진행될 수 밖에 없다는 것이다.
싫으나 좋으나 그래도 측정이란 것을 해야하니 이런 저런 방법들이 동원되는데, 일단 논의의 대상을 '각 개인의 성과에 대한 측정'으로 한정해서 생각해 보기로 하자.

SW R&D 쪽에서 보면, 회사 차원에서 SW 엔지니어의 성과를 측정하는 구체적인 기준이 마련된 곳은 거의 없다.
그냥 개발 팀의 팀장의 주관에 맡기는 것이 현실이다.
쉽게 말하자면, 회사차원에서 측정 방법에 대한 가이드 라인을 줄 수가 없으니까 그냥 손놓고 있다는 말이다.
그리고, 요즘 SW 연구소에서 팀장의 직급을 맡고 있는 분들의 상당수는 예전에 IT 붐이 일어났을때 IT업계에서 실무를 담당해서, 대단히 이른 시기에 관리자의 역할을 했던 그런 분들이다.
즉, 실제 실무 SW개발 경력보다는 관리 쪽 경력이 풍부한 분들이다.
그런 관계로, 모든 분들이 그러하진 않겠지만 필자가 보아온 대다수는,  기술적인 측면에서 상당한 아쉬움이 있었다.
문제는, 기술적인 면이 부족한 사람이 기술력이 가장 중요한 엔지니어의 성과를 측정한다는 것이다. 제대로 될 리가 없다.
일 예로, 야근을 얼마나 많이 했느냐? 주말에 얼마나 많이 출근했느냐? 버그 수정 개수 - 얼마나 많은 수의 버그를 수정했는가? - 등으로 로 엔지니어의 성과를 측정하기도 한다.
이게 말이 되는가?
그런데 놀라운 사실은, 내부적으로 이런 식의 측정기준을 가진 팀/연구소가 내가 평소에 생각했던 것보다 많다는데 있다.
실무에 대한 경험이 부족하니, 엔지니어의 성과를 측정하는 제대로된 기준을 만들 수도 없는 것이다.

이런 저런 이야기를 쓰다보니 횡설수설하게 되었는데, 요점을 미리 말하자면, 마땅한 측정 기준이 없다면, 이런 측정 기준은 어떤가?

"테스트&디버깅 단계에서 나온 버그 수(1), 마지막 배포 버젼에 남아 있는 버그 수(2)" 이 두 가지가 적은 것! 단 (1)이 (2)에 우선한다.

SW개발에서 가장 잘못된 믿음이 "열심히 하는 것"이다. 열심히 버그 만들고, 고치고, 고치면서 또 만들고...
SW개발에서 상책은 버그를 가능하면 만들지 않는 것이다.
"열심히 하는 것이 미덕" 이라는 생각이 "버그 수정 개수 = 성과" 라는, 얼핏 생각하면 그럴 듯 하지만,  SW실무에서 봤을때 말도 안되는 공식을 만들어 내는 것이다.
능력이 부족한 엔지니어의 대부분이 버그 수정 개수가 많다. 자기가 버그를 만들고 자기가 수정하는 과정을 반복하니까.
특히 하루에 버그를 2~3개 잡아 냈다는 것은 자기가 만든 버그를 자기가 잡았다는 말이다. 자랑할게 아니고 부끄러워 해야할 것이다.
남이 만든 버그는 하루에 1개 잡아내기도 힘들다.

그렇다면, 왜 (1) - 발견된 버그 수 - 이 (2) - 남아 있는 버그 수 - 에 우선해야 하는가?
버그의 수정은 반드시 검증의 과정을 필요로 한다. 그런데 이 비용이 작지가 않다. 오히려 버그 수정 그 자체에 드는 비용보다 검증에 드는 비용이 더 큰 경우가 많다. 하나의 사소한 버그 수정이 만들어 낼 수 있는 side effect가 모두 검증되어야 하기 때문이다.
또한, 만약 버그 수정이 모듈의 interface,  심하게는 software 전체 구조의 변경을 요구한다면, 엄청난 추가 비용을 요구하게 될 수도 있다.
즉, 버그의 수정에 드는 비용은 해당 팀/개인 의 비용 뿐만이 아니라, 부수적으로 상당히 많은 양의 추가 비용을 포함하기 때문에, 될 수 있으면 피해야 하는게 옳다.
따라서, 버그를 많이 수정해서 남아 있는 버그 수를 작게 유지하는 것도 중요하지만, 그 보다 더 중요한 것이, 버그 자체를 적게 만드는 것이다.

글을 쓰다보니 약간 흥분한 듯 하다. 차후 내용을 정리하도록 해야겠다...

추가적인 생각들...

* 개발이 아니라 maintenance feature의 경우, 넘겨 받은 부분이 거의 완벽해서 아무일도 하지 않아도 버그가 없는 경우.
-> 일을 적절히 나누어 주는 것은 관리자의 몫이다. 이런 feature들은 그 이전의 history로 부터 파악이 가능하다.

In Linux, read or write side of pipe is automatically closed if there is no reference for the other side - file is really closed.
But I faced with strange case when implementing a 'ylisp' function - pipe is automatically closed even if there is still valid file descriptor that references that pipe.
Here is simpler version of issued code.

/* function */
{
    int   fd[2];
    pid_t cpid;
    pipe (fd);
    cpid = fork();
    if (cpid == 0) {
        close (fd[0]); /* close read end */
        dup2 (fd[1], STDIN_FILENO);
        /* --- (*a) --- */
        close (fd[0]); /* <-- (*1) */
        /* --- (*b) --- */
        ...
        execvp (...)
    } else {            /* Parent writes argv[1] to pipe */
        close (fd[1]); /* close write end */
        ... /* read end is used */
    }
    ...
}

ylisp is multi-threaded program. And building/running environment is

OS : Linux 2.6.35-24-generic-pae #42-Ubuntu SMP Thu Dec 2 03:21:31 UTC 2010 i686 GNU/Linux
Compiler : gcc (Ubuntu/Linaro 4.4.4-14ubuntu5) 4.4.5
libc : Ubuntu EGLIBC 2.12.1-0ubuntu10.1

For testing, I put test code to check whether STDIN_FILENO is valid file descriptor or not.
Interestingly, sometimes, STDIN_FILENO is invalid at (*b), even if it is valid at (*a).
I don't have any idea what happens to this code.
Fortunately, commenting out (*1) seems to be a walk-around for this issue, but it's just temporal solution.
'fd[0]' is never closed in this walk-around.

I need to look into this with more time... very interesting...

Remind! :
'make' can tell difference between normal line and command only by using 'tab'.

It's same in GNU Automake.
Here two simple 'Makefile.am' - A, B.

[A]
...
if COND_X
[spaces]VARX=xxx
endif
...

[B]
...
if COND_X
[tab]VARX=xxx
endif
...

Only difference is leading spaces [A] and leading tab [B].
But, in case of [B], make regard 'VARX=xxx' as command.
So, 'Makefile.in' generated by 'automake' looks like follows.

[A]
...
(usually, at the head of Makefile.in)
VARX=xxx
...
(start rules)
all: config.h ...

[B]
...
(usually, at the end of Makefile.in)
.PHONY
[tab]VARX=xxx
...

So, in case [B], 'VARX' cannot be used as a variable at the 'rule' part!
The point is, "'Tab' means 'Command' in 'Make'!".
Keep this in mind!

Model : HP EliteBook 8530w
Host : Linux hbg683-laptop 2.6.35-24-generic-pae #42-Ubuntu SMP Thu Dec 2 03:21:31 UTC 2010 i686 GNU/Linux

Current state : 'nvidia-xxx' is installed at 'synaptic package manager'. And then driver is updated by 'NVIDIA-Linux-x86-260.19.12.run' installer.
=> visual effect doesn't work.

Actions done : uninstall all 'nvidia-xxx' packages from 'synaptic package manager'. And then install driver by running 'NVIDIA-Linux-x86-260.19.12.run' installer.
=> Some errors are raised. (something like cannot copy xxx-260.19.06 bla... bla...)

Now visual effect works very well!!

들어가는 글:
수학문제같은 것이 아니고서야 '정답'은 있을 수 없다. 또, 어떤 명제든 '예외'는 항상 존재하는 법이다.
따라서, 앞으로의 논의는 모두 일반적인 상황에 대한 '나' 자신의 주관적인 견해일 뿐임을 미리 밝힌다.

앞서 SW Engineer의 능력을 측정하는 두 가지 기준 - Domain Knowledge(DK), Programming Skill(PS) - 에 대해 이야기 한 적이 있다.
여기에서 한발짝 더 나아가, 어떤 Engineer를 채용할 것인가를 고민해 보고자 한다.
아니, 아직까지 개인적으로 어떤 사람을 채용해 평가해 본 경험이 없으므로, 아마도 "어떤 Engineer와 일하고 싶은가?"에 대한 고민이라고 하는게 옳겠다.

이미 앞선 글에서 잠시 언급한 것과 같이, DK와 PS의 비중은 어떤 분야에서 일하느냐에 따라 다르다.
Debugging분야는 DK가  PS보다 중요한 대표적인 예이고, 반대로 Graphic User Interface의 구현은 PS가 DK보다 중요한 대표적인 분야이다.
업무의 특성에 따라서, DK와 PS의 가중치가 달라지겠지만, 일반적으로 PS를 향상시키는 비용이 DK에 비해 비싸다.
(이에 대한 어떠한 통계적인 근거가 있는지는 모르겠지만, 개인의 경험에 비추어 봤을때 그러하다.)
따라서, DK와 PS의 비중에 대한 확신이 없을 경우에는 PS에 무게를 두는 편이 실패 확률이 적다.
한편, DK에 대한 측정기준은 분야마다 다르므로 여기서 논의할 수 있는 사항이 아니다. 따라서 PS의 측면에 논의의 초점을 맞추고자 한다.

Programming에서 가장 중요한 두가지는, 'Algorithm'과 'Design'이다. 기타 나머지는 이 두가지에 비해 그 중요도가 크게 떨어진다.
물론, Data Structure도 무척이나 중요하지만, 이는 넓은 의미에서 Algorithm에 포함된다고 할 수 있다.
나쁜 Algorithm이나 Design이 SW에 어떤 영향을 미치는지는 굳이 설명하지 않겠다.

Alg.과 Design은 속성이 좀 다른데, "전략과 전술"간의 관계와 유사하다.
Design이 전략 - 전쟁의 전체적인 측면에서 작전 - 이라면, Alg.은 전술 - 전투 상황에서의 작전 - 이라고 할 수 있다.
전략과 전술 어느 것 하나라도 부족하면 전쟁에서 이길 수 없듯이, Alg.과 Design 어느 한 쪽이라도 부족하면, 제대로된 SW가 나올 수 없다.

그런데, 재미있는 것은 Algorithm의 경우에는 선천적인 재능이 후천적인 노력에 우선하는 경향이 있다.
무슨 말이냐 하면, '똑똑한 사람이 노력한 사람보다 잘 한다.'는 의미다.
후천적인 노력이 전혀 반영되지 않는 것은 아니지만, 선천적인 능력이 더 큰 비중을 가진다.

반면, Design의 경우는 Algorithm의 경우와 반대이다. Design은 후천적인 경험/노력이 선천적인 능력이 우선한다.
왜냐하면, 요구사항, 개발환경 등에 대한 풍부한 이해와 경험이 바탕이 되어야 좋은 Design이 나올 수 있기 때문이다.
아무리 천재적인 사람이라도, 충분한 경험이 없다면 좋은 Design을 만들 수 없다.
좋은 Design은 풍부한 지식에서 나오는 것이 아니라, 느끼고 이해했을때 비로소 만들어 낼 수 있는 것이다.

Alg. Design 양쪽 모두에 뛰어나다면, 두말할 필요도 없다. Alg.쪽에 뛰어나다면, 이 역시 굉장히 탐나는 사람이다.
Design쪽 능력은 가르치고 다듬어서 발전시킬 수 있지만, Alg.쪽 능력은 이런식의 향상이 굉장히 힘들기 때문이다.
그렇지만, Alg.쪽에 정말로 뛰어난 사람을 찾기는 힘들 것이다. 대부분 학계쪽 혹은, 다른 어떤 곳에 몸담고 있을 가능성이 높다.
우리가 접할 수 있는 대부분은 사람은, 아주 낮은 수준 부터 중상 정도 수준까지일 것이다.
그런데 이런류의 재능은, 아주 뛰어난 몇몇 사람들만 눈에 띌 뿐, 그 외에는 잘 한다고 느끼기가 어렵다.
뿐만아니라, 합리적인 측정방법을 찾는 것도 거의 불가능에 가깝다.
따라서, Alg.에 대한 측정은, "좋은 사람을 찾겠다."가 아니라, "낮은 수준의 사람을 걸러낸다."는 접근 방법을 취해야 한다.
이건, 몇몇 기본적인 함수 작성 문제들을 제시해서 알아 볼 수 있다. recursion을 사용해야하는 문제라면 더욱 좋다.

이제, Design쪽 능력을 검증해야 한다. 이번 경우는 위의 경우와 접근 방법이 달라져야 한다.
Alg.의 경우는 '걸러내는' 방법이 사용되었다면, Design쪽은 '골라내는' 방법이 사용되어야 한다.
(신입사원을 채용하는 경우는 예외다. 신입사원에게 경험을 필요로 하는 답을 기대하는 것은 무리가 있다.)
좋은 Design은 SW 개발을 충분히 이해하고 가슴으로 느꼈을 때 나타날 수 있다.
이것은 '절대' 경력에 비례해서 성장하지 않는다. 너무 짧은 경력을 가진 사람이 좋은 Design을 하는 것은 힘들지만, 충분한 경력을 가진 사람이 좋은 Design을 할 것이라는 보장은 없다. Design능력은 실무에서 경력을 쌓는 동안, SW에 대해서 고민하고, 연구하며, 자기 나름대로의 철학을 구축해 나가는 과정에서 성장해 나간다.
즉, '제대로'된 경력을 가진 사람만이 좋은 Design을 만들어 낼 수 있는 것이다.
나는 감히, "경력과 Design능력과의 관계는, 그 사람의 성실성을 측정할 수 있는 좋은 척도가 된다." 라고 말하고 싶다.
Design능력을 검증하는 test는 Alg.의 그것과는 엄연히 다르다.
Alg.의 경우는 함수 내부의 구현에 집중한다. 그렇지만  Design의 경우는, API의 정의, encapsulation / modulization 등의 주요 concept에 대한 반영, 개인이 가지는 programming 철학 등에 집중해야 한다. 함수 내부의 구현이 정확하냐 안하냐 - correctness - 는 부수적인 측정 대상일 뿐이다. 극단적으로 pseudo code로 test할 수도 있다 - 물론 좋은 선택은 아니지만.
그리고, coding test시 사용하는 language로는, 가능하다면, OOP language를 피하는 것이 좋다 - C++, Java 같은 것 보다는 순수 C 같은 언어.
도구의 이점을 최소화하면, 뛰어난 사람과 그렇지 않은 사람간의 차이를 더욱 쉽게 볼 수 있기 때문이다.
아마도, 간단한 "재사용 가능한 linked list library"를 만들어 보라고 시켜 보는 것만으로도, Engineer의 Design 능력에 대한 많은 정보를 얻을 수 있을 것이다.

to be continued...

⚫ From VM Spec

⚬ In particular, x != x is true if and only if x is NaN, and (x<y) == !(x>=y) will be false if x or y is NaN.
⚬ round towards zero
⚬ Multibyte data items are always stored in big-endian order.

⚫ Java VM Type Signature

Signature        Java Type
Z                             boolean
B                             byte
C                             char
S                             short
I                             int
J                             long
F                             float
D                             double
L fully-qualified-class ;     fully-qualified-class
[ type                        type[]
( arg-types ) ret-type        method type

to be continue ...

야근, 초과근무, 휴가 등은 직장생활에서 많은 이슈가 되는 것들 중에 하나다.
앞선 몇몇 글에서도 언급한 바가 있었던 것 같은데, 한국에서는 야근, 초과근무는 당연시 되고, 휴가는 다 쓰지 못하는게 당연시 된다.
일단, "열심히 일하는 것이 미덕." 인 문화가 가장 큰 이유 중에 하나다. 이건 너무나 많이 이야기 되어 왔고, 논쟁이 되어온 내용이라 더 이상 언급하지 않겠다.
또 다른 근거로 제시되는 것은,  "다른 사람들도 (야근/초과근무/휴가 다 못쓰기를)하는데, 너만 안 하면, 다른 사람들이 어떻게 생각하겠느냐?"라는 것이다. 즉, 다른 사람들과의 형평성에 대한 이야기다. 여기에 대한 여러가지 시각이 있을 수 있겠으나, 내가 보는 시각은 좀 다르다. 난 개인적으로 위의 논리가 잘못 되었다고 생각한다.

위의 논리는 바꾸어 이야기 하면, "다 같이 힘들고 고생하자!"의 논리다. 왜 "다같이 편하고 행복하자!"의 논리를 만들어 내지 못하는가?
"많은 사람들이 초과 근무/야근을 하고 휴가도 못가니 너도 그래라."가 반복 적용되면, 결국 "모든 사람은 초과 근무/야근을 해야 한다."로 바뀐다. 이렇게 되면, "어차피 야근해야 할꺼, 근무시간에 열심히 일하면 뭐하냐? 천천히 하자." "어차피 휴가도 못쓰는거 오늘 끝낼 필요있나? 천천히 하지 뭐." 이렇게 된다. 이런 악순환의 고리가 현재 한국에 만연되어 있다고 본다. "일이 없으니, 일찍가지. 일이 없으니 휴가 가지."라고 말한다면, 일찍 퇴근하고/휴가가기 위해서 열심히 일해 일을 빨리 끝마치는 사람은 "일이 없는 사람"으로 매도 된다. 만약 정말로 업무 부담이 가벼운 경우라면, 그건 업무 분배를 제대로 하지 못한 사람에게 책임이 있는 것이다.
설사, 정말로 일의 부담이 적은 경우라면, 괜시리 야근 시키고, 휴가를 금지 시켜서 쓸데 없이 회사에 나오게 만드는 것 보다, 재충전의 시간을 보장해 주는 것이, 직원들의 사기를 높이는 방법일 것이다. (어차피 할일 없이 회사에 나와봤자, 생산적인 일을 할리가 만무하다.)

물론 위의 이야기를 이상적인 이야기, 비현실적인 이야기라고 평하는 사람들도 있을 수 있다. 그리고 나도 어느 정도 동의한다. 몇몇 사람들의 경우, 강제로 일을 시키지 않으면 - 반 강제적인 야근, 초과 근무 등등 -  제대로 맡은 일을 하지 않는 사람들도 많다. 이런 사람들에게 위와 같은 자유를 허락한다면, 제대로 된 생산성을 기대할 수 없을지도 모른다. 그렇다고 해서, 현재와 같은 방식을 유지하면, 이는 직원의 생산성을 하향 평준화 시킬 여지가 다분하다. 뛰어난 생산성을 가진 사람들은 이런 근무 환경을 견디기 힘들어 할 것이고, 결국 떠나게 될 것이다.

이게 어제 오늘의 문제는 아니다. 난 이런 현실이 어째서 바뀌지 않는 것인지에 대한 의문과, 과연 바뀌기는 할 것인지에 대한 회의를 함께 가진다.