Ting 이네 Software 이야기

* 가장 중요한 것은, 내가 맡은 업무가 무슨 업무인지 이해하는 것이다. 따라서 업무를 할당할때, 그리고 할당해 줄때 모두 내가/타인이 주어진 Project와 그에 따른 할일을 제대로 이해하고 있는지 확인하는게 중요하다.

* 그렇다면 위의 내용을 확인하는 가장 좋은 방법은 무엇인가?

Project에 대한 내용을 말로 설명하고 말로 확인하는거? 당연히 그렇게 해야 한다. 그렇지만 단순히 여기에 그칠 경우 한계가 명확하고, mis-communication도 종종 생긴다.

따라서 좀더 확실한 방법은, "난/넌 어떻게 내/니 일이 완료되었다는 것을 확인할래?"라는 질문을 던지는 것이다.

여기서 '어떻게'를 좀더 기술적인 용어로 변환해 보면, 'Test/Verification'이 될 수 있다.

즉, '어떤 Test/Verification을 통과하면, 이 일을 완료되었다고 확신할 수 있나?'가 된다.
(Project Management 쪽에서는 이것을 'Definition of done' 이라고 표현하고 있다.)

* 위의 과정의 핵심은 '어떤 Test/Verification'이다. 즉 Test design이다.

정리하면, 해당 업무를 '완료'했다고 말할 수 있는 'Test'를 design할 수 있다면, 그 업무를 완전히 이해했다고 볼 수 있다.

따라서, 업무를 받을때/할때 모두, 다음과 같은 질문/확인 을 통해서 업무에 대한 이해도를 확인할 필요가 있다.

업무를 할당 받았을때: "제가 <이런이런>시험을 했을때 문제가 없으면 되는거죠?"

업무를 할당할때:

(저급)1. <이런이런>시험을 했을때 문제가 없으면 됩니다.

- 문제의 본질을 이해하지 못하고, 단순히 시험에 통과하기위한 업무만을 진행할 가능성이 있음.

(고급)2. 업무는 <이러이러>합니다. 자, 당신은 어떻게 이 업무가 완료되었다는 것을 확인할 예정입니까?

- 제대로 된 답을 한다면, 이 사람은 업무를 완전히 이해하고 있다고 볼 수 있다.

직장생활을 하다보면, 제목과 같은 현상을 경험할 수 있다.

이게 '일반적'이라고 말하기에는 근거가 부족하지만, 개인적으로는 위와 같은 경험을 많이 해 본거 같다.

왜 그럴까?

가장 쉽게 생각할 수 있는 것은, 회사의 고정비를 줄이기 위해서 인력을 감축시키기 때문일 것이다.

업무량은 변하지 않았는데, 일하는 사람이 줄어드니, 남은 직원들은 더 바빠진다.

그런데, 개인적인 의견으로, 이것보다 더 중요한 요인은 "살아남기 위해서 일을 벌리기 때문" 이라고 생각한다.

회사의 고위층은, 실적이 나빠지면 살아남기 위해서 실적을 만들어야 한다.

그리고, 보통 '실적'은 '기존에 해 오던 일을 잘 하는 것' 보다는 '새로운 일을 해 내는 것'이 더 높은 평가를 받기 마련이다.

그렇다보니, 소위 '윗선'에서 자꾸 새로운 일을 만들어 내게 된다.

생각하기에 따라서는, 긍정적인 시각으로 이런 현상을 바라볼 수 있겠지만, 난, 부정적인 측면이 더 많다고 생각한다.

회사의 실적이 안 좋아지고, 고정비를 줄여야 하는 상황이라면, 일을 만들어 내는 것 보다는, 기존 일들에 대해서 우선순위를 정하고 "선택과 집중"을 통해서 어디에 회사의 역량을 집중할 것인가를 판단하는게 더 중요한 일이 아니겠는가?

물론, '기존에 해 오던 일을 잘 하는 것' 보다는 '새로운 일을 해 내는 것'에 대해서 압도적으로 높은 평가를 하는 것이 이런 현상의 근본 원인이긴 하겠지만, 그것과 별개로, 위기상황이라면, 좀더 합리적인 선택 - 선택과 집중 - 을 해야하지 않을까?

그렇지 못할 경우, 아마도 회사는 더 빠른 속도로 몰락의 길을 걷게 될 것이라고 본다.

익히 알려진 바와 같이, 인사평가가 100% 공정 - 공정이라는 단어의 정의를 어떻게 하느냐에 따라 달라질 수도 있겠지만 - 할 수는 없다.

일례로, 기왕이면 진급 대상자에게 상위고과를 주는 것이 어찌보면 '인지상정'이라고 할 수도 있을 것이다.

이런 것이 '좋다' 혹은 '바르다'라고 이야기 하는 것이 아니다. 평가는 100% 공정한 것이 좋다. 그렇지만, '공정'이라는 것이 그 속성상 100% 객과적일 수가 없기 때문에, 주관적인 판단이 반드시 개입된다는 것을 인정해야 한다.

그리고, 이런 '주관적인 판단'에는 주변의 환경적인 요소가 포함되기 마련이다.

예를 들면, "같은 성과라면, 기왕이면 진급이 절실한 사람에게 손을 들어 준다던가."라는 것들 말이다.

비슷한 이유로, 상위고과가 다른 이들보다 절실한 사람이 있기 마련이다.

그렇다고 해서, 인사평가 시즌에 무턱대로, 이런 사람에게 아무런 이유없이 상위고과를 줄 수는 없는 일이다.

이런 경우, 어떻게 해야 합리적인 방법으로 무리없이 이런 문제를 처리할 수 있을까?

내가 보기에, 인사평가는 "일을 얼마나 잘 하였느냐?"보다는, "어떤 일을 하였느냐?"가 더 많은 부분을 차지하는것 같다.

SW의 분야의 경우 예를 들어보면, 기존일을 '유지/보수'하는 일은 정말 압도적인 '실력/성과'를 보이지 않고서는 최상위 평가를 받기는 거의 볼가능하다.

그렇지만, 회사가 주요하게 추진하는 새로운 제품을 개발한다던가, 새로운 기능을 추가 구현하는 일은 일단 무사히 업무를 마치기만 해도 상위 평가를 받을 가능성이 높다.

이 두가지 업무 중 어느 쪽이 더 힘들고, 덜 힘든지는 경우에 따라 다를 것이지만, 일을 마쳤을 때 받을 수 있는 평가의 차이는 상당하다.

다시, 앞의 이야기로 돌아가 보자.

어떤 사람에게 '기왕이면' 상위고과를 주고 싶은 경우는 위에서 언급한 내용을 응용하는 것이 좋다.

그 사람에게, '상위고과를 받을 수 있는 일'을 할 수 있는 기회를 주는 것이다.

'좋은'일이 생겼을 때, 소위 '챙겨줘야'할 사람에게, 먼저 "이 일을 할 것인지?"에 대한 의사를 물어보는 것이다. 그리고, 이 일을 잘 해내었을때 좋은 평가를 받을 수 있다는 것도 같이 언급하는 것이 좋다.

이렇게 먼저 기회를 주고, 무사히 일을 잘 해내었을 경우 큰 물의를 일으키지 않고 필요한 사람에게 '상위고과'를 줄 수 있게 된다.

한편, 이런 기회에도 불구하고, 일처리가 미숙했다면, 그 사람은 거기까지가 한계인 것으로 볼 수 있다.

지금까지 어찌보면 굉장히 '부당'하다고 생각할 수도 있는 이야기를 했다.

읽는 사람에 따라서 상당히 불편하게 받아들일 수도 있을 것이다.

그렇지만, 사람이 사는 곳이라면 이런 문제가 반드시 발생하고, 실제 많은 조직에서 이런 문제가 심심치 않게 보인다는 것에 이견을 가진 사람은 없으리라 생각한다.

따라서, 이런 일을 피할 수 없다면, 최대한 합리적인 방법으로 처리할 필요가 있고, 내 개인적인 생각으로는 위과 같은 방법이 무난하다고 여겨진다.

여기서 다시 한번 강조하고 싶은 내용은, 상당히 많은 경우 "그 사람이 얼마나 일을 잘 했느냐?"가 아니라, "그 사람이 어떤 일을 했느냐?"가 평가에 더 많은 비중을 차지한다는 것이다.

Software분야에서 소위 '성과 평가'에 대한 문제는 아주 오래되고, 또 진부한 문제다.

여러가지 한계를 이야기 하고 있고, 그럼에도 불구하고, "평가를 하지 않는 것 보다는 하는게 낫다."라는 이론(?)을 근거로, 여전히 다양한 형태의 '평가'가 행하여 진다.

이 글은 '대안'을 제시 - 가장 어려운 부분 - 하는 것이 아니고, 기존 '평가' 방식이 가지는 여러가지 문제 중 하나를 언급하기 위해 작성된 것이다.

Software분야의 여러가지 연구 중 아래와 같은 것이 있었던 것으로 기억한다. (출처는 기억이 잘...)

"Software engineer에 개인의 기술적인 역량은, '어떤 group에 속해 있느냐'에 따라 상당히 많이 좌우된다."

즉, 좋은 group에서 좋은 경험을 쌓은 engineer가 기술적으로 뛰어난 engineer가 될 확률이 높다는 뜻이다.

그리고 또 재미있는 연구 중 하나는 (이것도 출처가 잘...)

"Software engineer 개인의 성과 차이는 100배까지도 발생하지만, 조직의 성과 차이는 10배 정도까지 밖에 차이가 나지 않는다."

관점에 따라서, 80:20 법칙을 생각나게 하기도 한다.

개인의 역량차는 심하게 나지만, 조직의 역량차는 그렇게까지 크지 않다는 뜻이다.

아마, [역량이 '1'인 엔지니어들의 group] vs. [역량이 '100'인 엔지니어들의 group] 과 같은 극단적인 조건에서가 아니라, 현실세계에 존재하는 일반적인 group을 대상으로 한 조사였을 것이라 생각된다. 

그리고 또, 일반적인 '회사'에서 똑같은 일을 두 곳 이상에서 하는 경우는 거의 없다.

내가 하고 싶은 말은, 

"조직의 역량 차는 각 개인의 역량차에 비해 크지도 않고, 또 같은 일을 하는 조직이 없기 때문에 SW조직의 역량을 비교 평가하는 것은 상당히 어려운 일이다."

라는 것이다.

특히, 같은 일을 하는 조직이 없다는 뜻은, 그 조직의 역량과 무관하게, 해당 분야의 history / 경험/ domain knowledge 등에 따라 진입장벽이 만들어 진다는 말이다. 그리고, 이 진입장벽으로 인해, 조직간 역량 평가는 결국 무의미해 진다."

즉, 개인의 성과 평가보다도 SW 조직(개발 조직)의 평가가 더 어렵다.

SW조직의 평가가 어렵다는 것을 받아 들인다면, 독립된 두 조직이 있을때 어느 조직이 더 나은 조직인지 알지 못한다는 뜻이다.

A, B 두 조직 중 실제 A 조직이 더 우수하지만, 조직 평가의 어려움 때문에 A, B 조직의 평가가 같게 나온 상황을 가정하자.

이 상황에서, 우수한 조직에서는 우수한 engineer가 배출될 확률이 높고(앞서 언급했다.) A 조직과 B조직의 역량차는 계속해서 커진다.

그렇지만, 여전히 조직간 평가의 문제점/어려움 때문에 이 부분이 보여질 가능성은 극히 낮다.

이런 상황에서, 일반적인 '회사'에서는 '상대평가'를 수행한다.

각 조직에서 상위 성과자와 하위 성과자를 구분하는 것이다.

개인의 역량평가를 정확히 실시하는 것도 사실 거의 불가능 하지만, 개인간 정확한 성과 평가가 가능하다는 것을 가정하더라도, 이미 조직의 평가에서 정확성을 잃어 버렸으므로, 개인간 평가의 정확성은 상당부분 희석될 수 밖에 없다.

뛰어난 조직의 하위 성과자가, 다른 조직의 상위 성과자 보다 더 나은 성과를 보였을 가능성도 무시하기 힘들다.

별다른 통일성이 없는 글이였는데... 정리하면...

SW분야에서 개인의 역량 평가에 대한 연구도 중요하지만, 조직의 역량 평가에 대한 연구도 동등 혹은 그 이상으로 중요하다.

"다른 사람을 blame하는 말을 할때, 주어가 '나'가 되고, 나를 blame하는 문장으로 바꾸어 구성하자."

아래와 같은 예를 보면 명확하게 이해될 것 같다.

* "너는 왜 아빠 말은 안듣니?"

=> "OO야, 아빠가 OO가 이해하기 어렵게 말했니?"

* "OO부장님께 말씀드렸습니다만, 받아들여지지 않았습니다."

=> "제가, OO부장님께 드린 설명이 부족했나 봅니다."

MVC Pattern에 대한 다양한 종류의 해석/적용이 있긴 한데... 일단, 내가 생각하기에, 일반적인 SW에서 좋다고 생각하는 구조는 아래와 같다 (Web SW나 기타 여러 case가 존재하고, 각각에 맞는 다양한 해석이 존재할 수 있으니, 정답은 없다.)
물론, 아직 나 자신이 MVC Pattern에 대해 미숙하기 때문에 확신할 수는 없으나...


+-----------+     Query(write/read)         +------------+
|           | <--------------------------   |            |
|   Model   |                               |   Control  |
|           | --------------------------->  |            |
+-----------+   Response/Data for query     +------------+
   |                                          |       ^
   |                                          |       |
   |        Feedback to user(ex. select view) |       | User interaction event
   |                                          v       |
   |                                        +------------+
   |                                        |            |
   +--------------------------------------> |    View    |
  Read data / (Observe changes - optional)  |            |
                                            +------------+

Pros : MVC간 연결이 최소화 되어 있어 각각에 대한 독립성이 잘 보장되어 있다.
       Model부분이 최소화 되므로, Data 부분에 대한 안정성을 높이기 유리하다.
Cons : Control부분의 역할이 Model, View에 비해 압도적으로 복잡할 가능성이 높다.
       따라서, 복잡한 UX를 가질 경우, Control 부분의 통제가 상당히 어려워질 수 있다.
일단 가장 좋은 점은, Model에 대한 update가 Control로 제한되어 있기 때문에
(View -> Model로 write path가 없다.), Data에 대한 관리가 일원화 되어 있다.
또한, Control이 Model의 data를 update하므로, View는 Model의 Data가 바뀌는지 아닌지 굳이 Observing할 필요가 없다.
(필요에 따라 Observing하는 것도 괜찮다.)


.
.

조직 변경의 2가지 방법 - 역할 변경 vs. 사람 변경 - 에 대한 고찰.

먼저, "역할의 단위와 조직의 단위가 정확히 일치할 때 효율은 극대화 된다는 것"을 가정할 필요가 있다 - 이후 논의는 이 가정에 기반한다.

(물론, 필자가 이에 대한 논문을 찾아 본적도 없고, 연구결과가 있는지도 모르겠으나, 직관적으로 대부분의 사람들에 의해 그렇게 받아들여지고 있는 것 같다.)

또한, 큰 조직의 변경에 대해서 논할 만큼 나 자신이 경험이 많거나 연구를 많이 한 것이 아니라서 일단 고려하지 않고, 이 글에서는 소규모 조직 - 인원 50명 이하 정도가 4-5 개의 하위 조직으로 다시 나누어진 형태 - 의 변경에 대해서만 이야기 하고자 한다.

조직의 형태는 항상, 다양한 방식으로 변경된다.

많은 경우, 10명 이내/내외 의 인원이 가장 작은 단위의 조직이 되고, 이런 조직들이 다시 적게는 4-5개 많게는 10여개가 모여 다시 차 상위 조직이 되는 구조가 반복적으로 사용되어 하나의 큰 조직이 구성된다.

(옛날, 군대 조직 역시, 10부장, 100부장 등 10 단위로 조직이 구성되는 형태를 종종 볼 수 있다.)

그리고, 이런 소조직 별로 독립적인 역할이 부여되고, 이런 조직들의 유기적인 결합에 의해 다시 차상위 조직의 역할이 결정되는 구조를 가진다.

그런데, 업무와 역할이 항상 고정적일 수는 없고 변화가 생기게 마련이다.

어떤 역할은 그 규모가 확대되기도 하고, 또 어떤 역할은 그 규모가 축소되거나 혹은 아예 사라지기도 한다.

그리고, 이런 일들이 벌어질 때마다 소위 말하는 '조직변경'이라는 것이 생긴다.

'조직변경'의 생기게 되는 이유는 결과적으로 말하면, 역할의 단위와 조직의 단위가 잘 맞지 않기 때문이다.

역할은 내/외부 환경에 의해 계속 해서 바뀌게 되는데, 이때, 요구되는 역할의 단위가 현재 조직의 단위와 맞지 않다면, 조직의 효율을 높이기 위해, 기존 조직을 역할의 단위에 맞게 수정할 필요가 있다.

이때, "어떤 식으로 기존 조직을 변경할 것인가?"라는 문제가 생기게 되는데, 필자는 크게 두 가지 방법이 있다고 생각한다.

첫째, 역할의 변경.

둘째, 사람의 변경.

용어의 모호성을 없애기 위해 '조직 변경'을 '조직역할 변경'과 '조직원 변경'으로 구분하여 사용한다.

'조직역할 변경'이란, '조직'이 수행하는 역할이 변경되는 것을 뜻한다.

'조직원 변경'이란, '조직'의 사람(구성원)이 바뀌는 것을 의미한다.

[역할의 변경]

조직원을 기준으로 역할을 조정하는 방법이다.

즉, 조직 구성원의 변경을 최소화하고, 역할을 조정한다.

[사람의 변경]

역할을 기준으로, 조직원을 변경하는 방법이다.

위의 '역할의 변경'과 반대되는 개념이다.

일반적으로 '사람의 변경'이 '역할의 변경'보다 더 자주 사용되는 경향이 있는데, 내 생각에는, '사람의 변경'에 필요한 비용이 '역할의 변경'에 필요한 비용보다 예측하기 쉽고, 대부분의 경우 비용이 더 적게 들어가기 때문인 것 같다.

예를 들어, 아래의 상황을 가정해 보자.

* A팀(7명)과, B팀(10명) 이 존재한다.

* A팀은 kernel관련 업무를, B팀은 App.관련 업무를 맡고 있다.

* Kernel 업무는 많이 늘어나고 있어서 10명 정도의 인원이 필요한 반면, App. 업무는 줄어들고 있어서 7명 정도면 가능한 상황이다.

이와 같은 경우, 각각 아래와 같이 적용된다.

* 사람의 변경 : B팀의 인원 3명을 A팀으로 옮긴다.

* 역할의 변경 : B팀이 Kernel업무를 담당하고, A팀이 App. 업무를 담당하도록 한다.

어느쪽이 더 효율적이라고 보이는가?

아마, 대부분의 사람들이 아무런 의심이 없이 '사람의 변경'쪽을 택할 것이고, 나 역시, 높은 확률로 '올바른 선택'이 될 것이라고 생각한다.

그럼, 정말 '항상' 이와 같은 선택이 올바른 선택일까?

난, 여기에 의심을 품어 본다.

그렇다면, '왜' 대부분 '사람의 변경'쪽을 택하게 된 것일까?

아마도 아래와 같은 생각 때문이였을 것이다.

'사람의 변경'의 경우, 3명만, 새로운 업무에 적응하면 된다. 반면, '역할의 변경'의 경우 10 + 7 = 17 명 모두가 새로운 업무에 적응해야하고, 새로운 기술을 습득해야 한다.

상당히 합리적이로 옳은 판단의 근거라고 생각한다.

그렇지만, 정말로, 판단의 근거가 위의 내용밖에 없을까?

3명이 빠져 나감으로 인해서 발행하는 B팀의 사기 저하는? B팀의 인원이 A팀으로 옮길 시, 기존 팀원간의 불화에 따른 조직 문제는?

즉, 사람의 문제는 위의 판단에서 완벽하게 배제되어 있다.

다시 한번 말하지만, 위의 '예'의 경우는 '사람의 변경'이 높은 확률로 옳은 선택이라고 나 역시 생각한다.

그렇지만, '항상'은 아니라고 말하고 싶다.

'사람의 문제'에 따른 비용으로, 특수한 경우는 '역할의 변경'이 오히려 더 나은 경우도 분명히 존재할 것이다.

다만, 앞서 언급한 '사람의 문제'에 따른 비용이 예측되지 않기 때문에 사용되지 않을 뿐이라고 생각한다.

이런 종류의 연구를 좀더 조사해 볼 필요가 있어 보인다...

[ 내 개인적인 생각임을 미리 밝힌다. ]

HLD이든 LLD(Low Level Design)이든 결국 block diagram의 형태 (Component 단위든, Class단위의 UML이든...)일 수 밖에 없고, 얼마나 작은 단위의 block까지 명세하느냐에 따라 구분되어 질 것이다.

그럼 이런 block diagram에서 가장 중요한 요소는 무엇인가?

결국 'Design'이라는 측면에서 본다면, 각 block의 input과 ouput을 정의하는 것이다.

그리고, input/output(IO)를 정의한다는 것은, "이 모듈의 역할을 명확히 정의"하는 것과 같다.

더 나아가, block diagram이라는 것 역시 결국,이런 block간 IO의 연결일 뿐이다.

IO를 명확히 하는 것이 왜 SW design에 중요한가?

SW design은 결국 block 간 IO 연결의 형태로 표현되게 된다. 예를 들면,

"A block은 B block의 output을 input으로 받아서 C block과 D block에서 사용할 값들을 만들어 낸다"

같은 형태가 될 것이다.

이때, 내부 구현의 문제는 해당 block하나에만 영향을 끼친다. 즉 A block의 내부 구현이 문제라고 한다면, A block 만 열심히 다시 구현/설계하면 되는 것이다.

그런데, A block의 IO로 정의된 내용이 틀리다면, 예를 들면, "이 input으로는 기대하는 output을 만드는 것이 불가능 혹은 현실적이지 않다."하다면?

그렇다면, A와 연결된 이후 모든 block의 설계다 전부 연쇄적으로 변경되어야 한다.

즉, 소위 "설계 변경"이 일어날 수 밖에 없게 된다.

일반적으로, 내부 구현 문제는 논란의 여지도 많고, 개선의 여지도 많지만, "A라는 input으로, B라는 output을 만들어 낼 수 있느냐?"의 문제는 내부 구현에 대한 고민과 관계없이 판단 가능한 경우가 많다. 혹은 '불가능'하다는 판단은 못하더라도, '가능하다'라는 판단은 명확히 할 수 있다.

따라서, HLD는 이런 block의 IO정의에 대한 잘못된 판단 요소를 조기에 찾아서, 나중에 설계전체에 영향을 주게되는 일을 미리 방지하는게 목적이 된다.

비단 HLD뿐만 아니라, LLD 및 기타 모든 SW 설계역시 마찬가지일 것이다.

얼마나 큰 단위의 block으로 IO를 설계하느냐의 문제이지 block의 IO를 명확히 하는 것이 무엇보다 중요하다.

그럼, 여기서 좋은 설계자는 어떤 차이를 만들어 내는가?

좋은 설계자는, block간 R&R을 명확히 하고, block의 내부 구현에 대한 어느 정도 '감' 을 가지고 있어서, performance및 resource 사용을 최소화 할 수 있는 형태로 block을 나눌 수 있다.

특히, 여기서, '내부 구현에 대한 감'역시 상당히 중요한데, 때로는 이론적으로 상당히 뛰어난 설계를 했음에도 불구하도, 특정 block이 설계에 정의된 IO를 만족하기 위해 너무 많은 비용 - performance, memory 등 - 이 들어가는 경우가 발생할 수도 있다. 불가능 하다는 말이 아니다, 단지 현실적이지 않다는 뜻이다.

이럴 경우, HLD에서는 IO가 타당하다고 Review되었겠지만, 실제 구현단계에서 설계변경이 필요해지는 경우가 발생하게 되는 경우이다.

이때, 경험이 많은 설계자라면, HLD시점에서, 이런 구현단계의 구체적인 문제를 알지는 못하겠지만, "이런 식의 IO로 module을 설계하면, 뭔가 문제가 발생할 여지가 많아 보이는데... 찝찝하다..."라는 소위 '감'을 가질 수도 있고, 이 '감'에 따라서, 이런 '문제 발생 가능성이 높은 설계'를 피할 수 있을 것이다.

project전체에 대한 개괄적인 schedule이 "주 단위 (혹은 2 주 단위), 아주 큰 project라면 한달 단위"로 나올 수 있다면 HLD가 끝났다고 볼 수 있을 것이다. "schedule이 나왔다."는 말은, "어떤 식으로 개발 할 것이다." 라는 것이 정했졌다는 말이고, 그 말은, "전체적인 Design(큰 그림)이 그려졌다."라는 뜻이기 때문이다.

뭐, 이런 식의 기준이 틀렸을 수도 있지만... 일단 난 이 기준으로 판단하고자 한다.

LLDR은 아마도, 2~3일 단위 정도로 schedule이 나왔을 때 끝났다고 이야기 할 수 있지 않을까?

물론, 이 모든 것은 project 의 규모에 따라, flexible할 것이다....

회사 생활을 하다보면 제목과 같은 말을 듣는 경우가 종종 있다.

실무 선에서의 문제가 첨예한 의견대립으로 상위선까지 번지게 되는 경우가 있는데, 이런 문제가 자주 나타나게 될때, 상급자들이 하는 대표적인 말 중 하나일 것이다.

"왠만하면, 실무선에서 해결하라. 그런 문제를 해결하는 것 또한 실무 능력이다." 의 의미를 내포한다고 볼 수 있다.

분명, 이러한 의견대립을 잘 해결하는 것 엮시 실무 능력의 중요한 요소 중 하나이다.

너무 많은 의견 대립이 생기고, 상급자(관리자)가 관여해야 할 문제들이 너무 자주 발생한다면, 실무자의 업무 능력이나 태도에 대한 세밀한 관찰이 필요한 것도 사실이다.

그렇지만, 그 부작용 또한 만만치 않다.

예를 들어, A팀 실무자와 B팀 실무자가 서로 협력해서 일해야 하는 경우를 가정해보자.

R&R이 아무리 잘 나뉘어져 있더라도 모호한 부분은 항상 있게 마련이고, 이런 부분에 대한 처리 문제로 의견이 대립하는 경우가 엮시 종종 발생하게 된다. 혹은, 극단적으로는 한쪽에서 다른 쪽으로 너무 무리한 요구를 계속해서 하는 경우도 있을 수 있을 것이다.

이때, A팀 팀장은 실무자를 적극적으로 support하고 있고, B팀 팀장은 실무자에게 '제목'과 같은 이야기를 했다고 가정해보자.

자... 어찌 되겠는가?

B팀 실무자가 A팀 실무자로부터 무리한 요구를 받거나, 혹은 R&R에서 벗어난 요구를 받았을때 - 물론, A팀 실무자는 이것이 무리한 요구라고 생각하지 않을 것이다. 입장차이가 존재하므로... - B팀 실무자가 이를 거부한다면, A팀 실무자는 팀장의 도움을 요청할 것이고, A팀 팀장은 실무자를 적극적으로 support할 의사가 있으므로, B팀 팀장에게 업무 협조 요청을 할 것이다.

자, 이제 B팀 팀장은 실무자에게 상황을 보고 받고, 판단에 따라 '수락' 혹은 '거부' 의사를 전할 것이고, 실무자에게는 질책과 함께, '제목'과 같은 지시를 다시금 전할 것이다.

위와 같은 일이 몇차례 반복되면, B팀 실무자는, 의견대립으로 인해 A팀 팀장이 나서서 B팀 팀장과 연락하게 되는 것에 대한 거부감(혹은 두려움)이 생기게 마련이고, 정말 심하게 무리한 요구가 아니라면 왠만하면 '의견대립'에서 A팀의 요구를 받아 들이는 방향으로 결정하게 될 것이다. 왜냐하면, 그래야만이 관련 문제가 팀장에게까지 전달되는 것을 막을 수 있기 때문이다. 그와 함께, 이러한 "의견 대립"도 줄어 들게 된다.

자... 그럼 결과적으로 어떤 그림이 그려지는가?

관련 일에 대한 의견 대립이 줄어들었으므로, 이에 대한 상급자의 평가는 두 실무자 모두에게 같은 정도의 "이익"으로 돌아가게 된다.(혹은 그 동안의 의견 대립에 대해서 같은 정도로 "피해"가 갈 수도 있겠다.)

하지만, A팀 실무자는 R&R이 명확한 본인의 일만을 처리하면 되므로 업무의 부하가 줄어들게 되는 반면, B팀 실무자는 본인 업무 + R&R이 불명확한 기타 업무 까지 해야하게 되므로 업무 부하가 늘어나게 된다.

두 실무자의 역량이 같다고 가정하면, A팀 실무자는 같은 일을 적은 업무 부하로 해결하고 있으므로 뛰어난 성과를 보일 것이고, B팀 실무자는 반대의 상황에 놓이게 될 것이다.

여기서 필자가 하고 싶은 말은, 팀장이 잠깐 고생하면, 팀원의 업무부하를 상당량 줄여줄 수 있고, 그것은 곳 팀의 업무 성과로 연결된다는 것이다.

반면, 팀장이 어떠한 이유가 되었건 - 귀찮아서, 아니면 본인이 바빠서, 기타 등등 - 위와같은 태도를 취하게 되면, 팀원의 업무 만족도 및 성과는 떨어지게 되고, 그 피해는 결국 팀장 자신에 돌아오게 된다.

어떤 팀의 팀원들이, 협력상대가 되는 팀에 비해 전반적으로 모두 업무 부하가 심하고, 업무성과가 저조하다면, 팀장이 위와 같은 태도를 취하고 있는 것은 아닌지 한번쯤 확인해 볼 필요도 있어 보인다.

지급이 높아질 수록 다른 사람에게 책임/권한을 부여해야할 일이 생기게 된다. (혼자서 모든 일을 할 수 없으므로, 누군가에게 일을 맡겨야 한다.)

이때, 조직의 공식적인 관계(결재/인사평가 에 직접적인 영향을 주지 못하는 관계 - ex. 직급에 차이가 있다 하더라도, 팀장/팀원의 관계가 아닌, 팀원/팀원의 관계)로 맺어지지 않은 사람들을 한 그룹으로 묶어야 하는 경우가 종종 생기게 된다.

예를 들어 아래와 같은 상황을 가정해 보자.

ex. 팀장(수석): A책임 B 선임 데리고 이 일좀 맡아서 해!

이때, A, B는 모두 팀장에게 평가를 받는 같은 위치의 팀원일 뿐이다. 비록 한명은 책임이고, 한명은 선임일 지라도...

아래와 같은 세 가지 경우를 생각해 보자.

경우 1. A에게만 위와 같은 이야기를 전하고, A에게 맡겨 둔다.

경우 2. A, B가 같이 있는 자리에서 두 사람에게 동시에 이 이야기를 전달한다.

경우 3. 팀 회의에서 이야기를 전달한다.

세가지 경우, 모두 특별한 문제가 생기지는 않겠으나, '1' 보다는 '2', '2' 보다는 '3'의 경우가 A에게 '힘'을 실어준다는 측면에서 더 나아 보인다.

그리고, 이 후 팀장이 B와 개인적인 대면을 통해서, A에 대한 칭찬(비록 약간 과장 되었다고 할지라도) - 'A는 충분히 B를 리드할 만 하고, 따를만한 가치가 있는 사람이다.' 라는 생각을 B에게 심어 주기 위해 - 과 함께 , A를 잘 따르라는 이야기를 전달함으로서 더욱 A에게 힘을 실어 줄 수 있다.

또한, 필요하다면, '팀장이 B에 대한 인사평가에 A의 의견을 적극 반영하겠다.'라는 이야기까지 진행함으로써 , A가 B와 함께 일함에 있어서 생길 수 있는 관계상의 문제에 마침표를 찍을 수도 있을 것이다.

어찌보면, 회사에서 '인사평가 line 혹은 report line으로 대표되는 공식적인 관계'를 만들어 두는 것 역시 위에서 언급한 '팀장' 이 A에게 힘을 실어주는 방식과 원칙적인 측면에서 다르지 않다고 볼 수 있다. 즉, 회사차원에서 힘을 실어주는 행위일 것이다.

다만, 여기서 언급하고자 하는 것은, 조직 전체라는 큰 그림에서만 이런 '힘을 실어주는 행위'가 필요한 것이 아니라, 작은 조직, 크게는 '서열'이라는 관계를 형성하는 모든 경우에, 위와 같은 '힘을 실어주는 행위'가 필요하다는 점이다.

단! 여기서 주의할 점이 하나 있다. 위의 예시의 경우에서, "A책임이 팀장의 편애"를 받고 있다고 B선임이 생각해 오고 있었다면, 위와 같은 "힘을 실어주기"는 오히려 '반발'을 불러 올 수도 있다!