Ting 이네 Software 이야기

리더가 팀을 이끌어 과는 과정에서 팀원의 업무 파악은 상당히 중요한 일이다.
업무 파악을 위해서 가장 많이 하는 일은 다음과 같은 것들이 있다.
  - 주간 업무 회의 : 주 1회 정도 정기적인 업무 회의를 통해서 보고 받는다.
  - E-mail 참조 : 업무관련 E-mail 을 주고 받을때, 리더를 CC에 넣도록 한다.
  - 식사/커피 등 함께 하기 : 자연스러운 분위기에서 업무 관련 이야기를 듣고자 한다.

다 좋다. 필수 적이기도 하다.
그렇지만 위의 것들을 모두 잘 하고 있음에도 불구하고, 늘 팀원의 업무 파악이 제대로 되지 않는 것 같다고 느끼는 경우도 있다.
무엇이 문제인가?
내가 생각하기에, 위의 방법들도 좋지만, 가장 중요한 것은 팀원들이 리더에게 도움을 받을 수 있어야 하고, 팀원이 이를 실질적으로 느끼고 있어야 한다는 것이다.

예를 들면, 어떤 문제에 대해서 실무자가 자기 자신의 힘만으로는 해결이 힘들어서 리더에게 보고를 하는 경우를 생각해보자.
이런 문제의 경우 대부분이 내부에서 실무적으로 처리하기는 한계가 있다고 실무자가 판단하는 경우이다.
즉, 외부 혹은 타 부서와의 협력을 통해 문제를 해결할 필요가 있는 문제이다. 

이때, 리더가 취하는 가장 일반적인 자세는, 일단 무엇이 문제인지 문제를 파악하고자 한다. 그래서 실무자에게 관련 문제에 대한 문답이 이루어진다. 여기까지는 자연스러워 보인다.

그런데 이후, 물론 리더에 따라 다르겠지만, 실무적인 가이드를 시작하는 경우가 있다. 그리고 이런 경우는 대부분, 상당한 시간을 소모함에도 불구하고, 리더가 제시한 가이드가 해결에 도움이 되기 보다는, 리더가 문제에 대해 더 잘 이해하는데 도움이 되는 정도로 끝난다.
이 과정이 반복되면, 일단 실무자는 피로를 느끼게 된다.
최악의 경우는, 리더가 실무에 대한 잘못된 가이드를 제시하고, 실무자의 의견에 반하여 그 가이드에 따라 일을 진행시키라고 강요하는 경우다.
이런 리더에게 실무자는 어떠한 도움도 구하고자 하지 않는다.

그리고 이후, 리더는 자신의 실무적인 해결책에 도움이 되지 못하게 됨을 깨닫고, 실무자에게 어떤 도움이 필요한지를 묻게 되고, 실무자는 " xxx가 필요합니다."라는 말을 하게 된다. 이런 도움의 대부분은 타 부서와의 업무 협조, 상위 부서에 보고 등에 대한 문제이다.
실무자가 요구한 사항을 리더가 해결해 주는 것이 정상적이나, 어떤 리더의 경우는 "그래? 그럼 xx씨가 직접 oo한테 연락해서 처리하도록."의 식으로 결국 실무자가 모든 일을 해야 하는 방향으로 결정을 내리기도 한다.

자. 위에서 문제가 된다고 생각하는 과정을 거친 실무자의 입장에서 보면, 본인이 진행하는 업무에 문제가 있어서 리더에게 보고를 했을때, 업무 진행에 도움을 받기 보다는, 시간과 에너지를 소모하고, 결국 자기 자신이 처리해야 하는 방향으로 결론이 난 것이다.
즉, 문제를 보고하는게 하등 도움이 되지 않는 것이다.
실무자가 이렇게 느낀다면, 과연 이후 업무에 대해서 리더에게 보고하려고 할까?
그냥 정기적인 보고 이외 특별히 리더와 업무에 대해 상의하고자 하지 않을 것이다.
어차피 결과적으로는 자기 자신이 모두 처리해야 하니까...

주저리주저리 이야기가 길었다.
간단하게 결론을 정리하면, 리더가, 실무자에게 도움을 줄 수 있고, 또 그렇다고 실무자가 느낀다면, 리더는 자연스럽게 실무자가 가지고 있는 문제를 보고 받게 되고, 팀원들이 업무적으로 가지는 문제가 무엇인지 이해할 수 있게 된다는 말이다.
직설적으로 이야기 하면, 맨날 보고 안한다고 뭐라고 하지 말고, 실무에 도움이 좀 되란 말이다. 그럼 자연스럽게 팀원들이 보고하게 될테니까...
실무적으로 아는게 없다고 해서 팀원들에게 도움을 줄 수 없다는 말은 하지 말자. 외부와의 소통문제, 업무 협조 요청 등등 수많은 일들로 팀원들을 도울 수 있으니... 

회사에서 근무하는 개발자들 가운데, 개발 자체를 좋아하거나, 혹은 기술을 숙련시키는 과정의 한 방법으로 자체적으로 SW를 개발하는 사람들이 있다. 대부분의 경우, 개인이 제한된 시간안에서 prototyping하는 정도일 것이다. 그렇지만, 그 중 몇몇은 조금만 개선/발전 시킨다면, 제법 괜찮은 SW의 근간이 되는 것들도 있을 것이다.
대표적으로, Google의 경우 20%의 시간은 개발자가 자기가 하고 싶은 것을 하도록 두는데, 여기서 나온 산물을 회사차원에서 지원해서 제품으로 발표한 것들도 적지 않은 숫자가 된다고 알고 있다.
그런데, 국내 개발자들 대부분이 자신이 틈틈이 개발한 SW를 회사에 공개하는 것을 극도로 꺼려한다.
왜 그럴까?

근본적으로 지적 재산권 문제가 걸린다.  물론 회사마다 정책이 다르겠지만, 국내 대부분의 회사에서는, 개발자가 자체개발 SW를 회사측에 공개하는 즉시 지적 재산권 전부를 회사에 넘겨준다고 보는 것이 좋다 - 국내 대부분의 회사의 고용계약서의 위의 사항이 명시되어 있다. 따라서, 내가 잠자는 시간을 줄여가며, 여가시간을 희생해 가면서 만든 SW를 아무런 대가 없이 회사에 넘겨 주는 것은 그리 유쾌한 일은 아니다.
그렇지만, 만약 공개한  SW가 회사의 지원을 받게 되고, 개발자 본인이 그 일에 참여할 수 있다면, 지적 재산권을 넘겨주는 손해도 충분히 감수할 만한 경우도 있다. 사실 자신의 SW를 회사에 공개하는 개발자의 대부분은 이런 결과를 기대했었을 것이다.
물론 의도한 대로 진행되면 좋겠지만, 회사의 판단이 개인의 판단과 달라서, 개발자 개인은 충분히 가치있다고 생각되는 SW를 회사에서 사장시키기로 결정했을 경우 문제가 복잡해진다.
이런 상황에서 개발자는 자신의 꿈과 열정이 담긴 SW의 가치를 믿고 계속 발전시켜 나가고자 하지만, 이미 지적재산권이 회사로 넘어간 이후이므로 그렇게 할 수가 없다. 왜냐하면, 개발자 개인이 아무리 많은 열정과 노력을 해당 SW에 쏟는다고 하더라도 모든 권리는 회사의 것이기 때문에 말 그대로 "죽 쒀서 개 주는 꼴" 밖에 되지 않기 때문이다.
즉, 원작자는 눈물을 머금고 자신의 SW가 사장되는 것을 지켜볼 수 밖에 없어진다.
이러니, 어떤 개발자가 자신의 SW를 회사에 공개하려고 하겠는가?

위와 같은 구조는 개인과 회사 모두에게 손해가 된다.
개인이 혼자서 SW개발을 하는 것은 분명히 한계가 있으므로, 개발자는 자신이 생각하는 내용의 SW를 완성시키기 위해 너무 많은 노력이 든다 (회사의 지원을 받을 수 없으므로). 반대로 회사는 충분히 좋은 idea의 SW들을 제공받을 수 있는 통로 하나를 상실한다.
이런 문제를 해결하기 위한 해결책은 없을까? 내 개인적인 생각은 아래와 같다.

기본적으로, SW의 지적 재산권은 회사가 가진다.
그렇지만, 공개된 SW에 대한 특정 심사 기간을 두고 (ex. 3개월), 회사에서 해당 SW를 사장시키기로 결정했다면, 해당 SW에 대한 지적 재산권을 개발자 개인에게 돌려 주는 것이다. 반대로, 만약 SW가 지원할 가치가 있다고 판단되면, 개발자에게 관련 중책을 맡긴다.

위와 같은 정책이 정직하게 운영되는 회사라면 아마도 많은 SW개발자들이 자신의 SW를 회사에 공개하지 않을까... 조심스럽게 생각해 본다.

내 생각에 대한민국은 '조언'의 문화보다는 '훈계'의 문화가 지배적인 것 같다.
'조언'의 문화란, 대등한 관계에서 이루어지는 '제안' 같은 것을 의미하고, '훈계'란 상하관계에서 가르침을 뜻한다.
대한민국에서 부모/자식 관계는 대등하기 보다는 상하관계에 가깝다.
따라서 부모는 자식을 '훈육'하게 되고, 자식입장에서는 가르침을 받게 된다.
'조언'이든 '훈계'든 어떤 것이 낫고 나쁜지는 모르겠다.

그런데 재미있는 것은 '훈계'의 문화에서 사용되는 '가르침'이  '질책'의 의미로 사용되는 경우다.
사실 상당히 많은 경우, 상하관계에서의 '훈계'는 '가르침'보다는 '질책'의 의미를 가진다. '사랑'이 바탕이 되는 부모/자식 관계도 그러할진데, 다른 사회적인 관계에서는 말할 필요도 없겠다. 그래서 그런지, 대한민국이란 나라에서 (다른 나라의 경우는 잘 모르겠다.), 사회적인 관계를 형성하는 사람들 사이에서는 '감사합니다.' 보다는 '죄송합니다.'가 더 익숙한 것 같다.

예를 들어, A 신입사원이 거래처와의 일을, 조금 어설프게 처리했고, 그래서 B대리는 A신입사원의 일처리에서 문제점들을 지적했다고 생각하자. 만약 A가 신입사원이 아니라 대리 혹은 과장이였다면, 위 사안은 '질책'이 될 가능성이 높다. 그렇지만, 신입사원이다. A가 일의 내용을 어설프게 처리할 것은 당연한 일이고, 아마 신입사원에게 맡긴 일이라면, 어느 정도의 실수는 용납될 일이 였을 것이다. 이런 경우, B대리가 A사원에게 하는 말은 '질책'처럼 들릴지라도 '훈계'에 가깝다. 그렇다면, A사원의 대답은 '죄송합니다.' 보다는 '감사합니다.'가 옳지 않을까?
'자신의 잘못된 부분을 지적해주고 가르쳐 주어서 감사합니다. '가 맡는 대답이 아닐까 말이다.
그렇지만, 우리들 대부분은 '죄송합니다.'가 먼저 튀어나온다. 자라온 환경에서 '훈계'보다는 '질책'을 받아왔던 탓이리라.
설사, '질책'이라 할지라도, '감사합니다.'는 여전히 유요한 반응이다.
'질책'했다는 자체가, 관심의 표현이고, 더 잘되라는 뜻이기 때문이다. 그렇지만, 우리는 어김없이 '죄송합니다.'가 나온다.

어찌보면, 문화가 만들어낸 것인 것도 같다. 그리고 사실, 이것이 '잘못되었다!'라고 말할 근거도 용기도 없다.
그렇지만, 내 개인적인 생각으로는 '죄송합니다.'보다는 '감사합니다.'가 듣기도 좋고, 한결 부드러운 것 같다. 아닌가?
'조언'이든 '훈계'든 아니면 그것이 '질책'이든, '죄송합니다.'보다는 '감사합니다.'가 먼저 생각나고 떠오를 수 있는 문화, 그런 문화는 과연 어떨까?

*  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...

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

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

듣기로.. Nokia는.. 어떤 문제에 대해서... 해결 방법을.. 찾을 때...

* 사람들을 모아서 해결책을 찾는 방법론을 listing한다. - brain storming
* 투표를 통해서 상위 2~3개를 뽑아낸다.
* 같은 의견을 가진 사람들끼리 모여서 팀을 형성한다. (2~3개 팀이 생긴다.)
* 각 팀별로.. 해결책을 찾는다....

--> 이 방법.. 상당히 괜찮아 보인다. 사람들은 자신과 신념/비젼을 달리하는 방향에 대해서는 최선을 다하기 힘들다. (무의식적으로 나태해지게 된다.)
그런데 이 방법은 자신이 믿는 바가 옳음을 보이는 형식이므로, 사람들의 적극적인 참여를 기대할 수 있다.

일반적으로, 사람은 의사결정에 본인이 참여한 정도만큼의 열정/책임의식 을 가진다고 한다. 따라서, 사람들의 열정을 이끌어내기 위한 중요한 방법 중 하나가, 의사 결정에 충분히 참여하도록 하는 것이다!

[[ blog 이사 과정에서 정확한 posting날짜가 분실됨. 년도와 분기 정도는 맞지 않을까? ]]
 
======= 같은 실무자로서 일을 맡기기 (ex Lead Programmer) ========
일을 맡기기전에, "What"을 원하는지, 아니면, "What + How"를 원하는지 먼저 물어보고, 일을 시킬 필요가 있는 것 같다. 사람에 따라, "What"을 주고 일을 시킬 경우, 너무 막막해 하는 사람이 있고, "What + How"를 주고 일을 시킬 경우, 단순 노동을 시킨다고 짜증내는 사람이 있다.

따라서 일을 시키기 전에 미리, 이를 물어보고 선택의 여지를 주는 것이 좋아 보인다. 일에 자신이 있고, 자기 나름대로 무언가를 해 보고 싶은 사람 (사실 이런 사람을 원한다.) 에게는 "What"을 주고, 그렇지 않고, 아직까지는 일에 자신이 없고, 구체적인 일의 모습을 원하는 사람에게는 "What + How"를 주는 것이 좋다. 그러나 만약, 계속해서 "What + How"를 아주 상세한 level까지 줘야 하는 사람이라면, 같이 일하지 않는 편이 더 나아 보인다. 이런 사람은 관리하는데, 더 많은 시간이 소모되고, 또 더 많은 스트레스를 받게 된다.

또 한 가지 중요한 점은, 'What'을 주고 일을 시킨다고 할 지라도, 그 'What'의 내용이 너무 포괄적이거나, 추상적이여서는 안된다. 예를 들면, "좋은 코드를 만들어라". 같은건 말이 안된다. "Performance에 초점을 맞추어서 개발해라" 라는 식의 구체적인 모습을 주어야 한다. 이것이 중요한 이유는 일을 진행하는 중에, 서로 다른 가치가 충돌할 때, 어디에 더 비중을 두어야 할 지를 결정하는 기준이 바로, 일의 목적인 'What'의 내용이 되기 때문이다.

더불어 일의 진행상황이나 결과물을 reporting받아야하는데, 이때, deadline과는 조금 여유를 두고 받는 편이 좋다. 왜냐하면, reporting된 결과물이 원하는 형태가 아닐 확률이 높기 때문이다. 따라서, 2~3번 정도의 수정/검토를 염두해 두고 reporting 일정을 계획하는것이 좋다.

========= 실무를 모르는 관리자의 입장에서 일을 맡기기 ==========
실무에서 막 관리자로 역할이 바뀐 사람을 제외하고, 대부분의 경우, 관리자는 실무자에 비해 실무의 내용을 모른다. 또 몰라야 한다. (관리자가 이를 알려고 시간을 낭비하게 되면, 그 만큼 관리자가 해야할 일을 못하게 되기 때문이다.)

그럼, 실무를 모르는 관리자가 실무를 자신보다 더 잘 아는 실무자에게 어떤 식으로 일을 시켜야 하는가?

먼저 관리자는 자신이 실무자에 비해, 실무에 대한 구체적인 지식이 부족함을 인정해야 한다. (종종, 좋지 않은 관리자는, 자신이 실무자보다 실무경험이 더 많다는 점을 내세워 실무에 대한 구체적인 지식이 모자람에도 불구하고 이를 인정하지 않고 잘못된 방법론을 강요하는 경우가 많다.) 이를 전제로 관리자는 실무자에게, 구체적인 실무의 "How"에 대한 부분은 전적으로 맡기는 것이 좋다. 그럼 관리자가 할 일은? 관리자는 실무자에게 일의 방향성과, 요구되는 schedule등을 지시해야 한다. 즉 관리자는 "어떤 일을 언제까지 끝내야 한다."를 지시하는 것이지 "어떻게"를 지시하지는 못한다.(해서는 안된다.)

이때, 많은 경우 "언제까지"를 충족시키기 힘든데, 관리자는 이를 위해 실무자와 논의해서 최상의 결과를 얻을 수 있는 절충안을 찾아야 한다. 필요한 resource, requirement의 수정 등등.

다시 한 번 생각해 보면, 위의 과정은 관리자가 실무자를 신뢰함을 전제로 하고 있음을 알 수 있다. 즉 관리자는 실무자가 자신의 편의를 위해서 관리자를 속이지 않음을 전제한다는 말이다. 그런데 이는 너무 이상적인 가정이다. 많은 실무자가 자신의 편의를 위해, 일의 양을 부풀리거나 더 많은 resource를 요구할 것이다. 그렇다면 관리자는 어떻게 이를 방지할 것인가?

가장 좋은 방법은, 속이지 않는 실무자를 고용하는 것이다. ("인사는 만사") 자신에게 모든 인사권이 있다면 이런 사람을 뽑는데, 대부분의 시간을 할애해야 한다. 그렇게만 된다면, 이 문제는 더 이상 고민할 필요가 없다.

차선은, 실무자의 '도덕적 헤이'를 막기 위해, 해당 실무를 잘 아는 여러명의 실무자에게 같은 질문을 함으로서, 특정 실무자의 진심을 파악하도록 노력하고 이에 맞는 조치를 취해야 한다..

각설하고, 중요한 것은, 관리자가 실무자에게 "How"를 지시해서는 안된다는 뜻이다.!!!
손자병법에서도 전쟁에서 패하는 요인중에 하나를 "군주가 진격하지 말아야 할 때 진격을 명하거나, 후퇴하지 말아야 할 때 후퇴를 명하는 것"으로 뽑았다. 비단 전쟁 뿐이겠는가???

[[ blog 이사 과정에서 정확한 posting날짜가 분실됨. 년도와 분기 정도는 맞지 않을까? ]]
 
!!!사람을 힘들게 하는 것은 "Hard work"가 아니다. "Stress"다
사람들이 일을 즐기면 - 즐기지는 못하더라도 할만하면 -, 열심히 일해도 힘들지 않다.
그러나, 사람들은, 자신이 무엇을 하고 있고, 왜 이 일을 하고 있는지 알지 못하면 일을 즐길 수가 없다.
사람들은 자신이 하고 있는 일의 방향과 타당성을 알고 비젼에 공감하며, 열심히 일한 것에 대한 보상이 있을때, 일을 즐길 수 있고, 이때는 하루에 10시간 혹은 12시간을 일하더라도, "회사일 때문에 힘들다."라는 이야기를 하지 않을 수 있다.

반면, 내 경력에 전혀 도움이 되지도 않고, 왜 이 일이 필요한지도 모르겠는 일을 계속해서 하면서, 다른 사람과의 갈등으로 계속해서 스트레스를 받으면, 아무리 9-6 8시간 근무를 하더라도.."회사일 때문에 힘들다."라는 생각이 들 수 밖에 없다.

음.... 지금 당연한 이야기를 하고 있는 것일 수도 있으나.. 다시 한 번 되새겨 보자는 의미에서 한번 적어 본다....