"관리가 무엇인지"를 배우다.

4년간의 SM을 마친다. 그동안 SM을 하면서 진행했던 "개인적인 프로젝트"가 마무리되었다는 의미이다. 조직원들간의 "갈등"과 그리고 조직원들 "불만" 원인의 근본적인 정체가 무엇이고 그 해결책을 알고 싶었다. 공부하다 보니 "IT 관리(IT management)"라는 영역도 접하게 되었다. 이제 프로젝트를 마무리하면서 산출물을 키워드 중심으로 간단히 정리를 해야 할 것 같다. 아래는 달봉이가 4년간의 SM을 하면서 그 가치에 대해서 다시 한번 더 생각하게 된 개념들이다.

 

1) R&R과 업무분장

2) 평가체계

3) IT 관리체계(IT 관리 프레임워크)

4) 계약체계

5) 조직체계

 

모두 일반적인 개념들로서 오다 가다가 많이들 들어본 말들이다. 그러나 사장님이 훈시할때나 적절할 것 같은 말들로서, 우리 일반인들에게는 대부분 이론적, 추상적으로만 인식되는 개념들이다. 그러나 개인적인 프로젝트를 진행하면서 이것들이 얼마나 중요한지 다시 깨닫게 된 것이다. 이 키워드들을 좀 더 정리한다. 

 

■ R&R과 업무분장

 

R&R과 업무분장, 이것들이 제대로 정의되지 않으면, 이것은 팀간 개인간의 "갈등"의 원인이 된다는 것은 우리 모두가 예상할 수 있을 것이다. 이것과 더불어 진짜 중요한 것은 "정의"된 내용을 "문서화"로 남겨야 한다는 것이다. 그래서 모든 사람들간에 공유가 이뤄지고 그 문서의 내용을 같은 의미로 인식하는데 있어서 오해가 없어야 한다는 것을 절감했다. 그리고 구성원은 "왔다 가더라도" 문서는 문화유산으로 남아야 그래야 조직이 객관적인 안정성을 가지고 계속 유지될 것이라는 것이다. R&R과 업무 분장의 "문서화", 이것이 중요하다. 

 

내가 사장님이라면 또는 스스로 "책임감"을 느끼는 관리자라면 이것을 제일 먼서 확립할 것이다. 물론 내가 사장님도 아니고, 스쳐지나가는 사람이라고 스스로를 인식하면, 달봉이가 그랬듯이 이것은 죽어도 못하는 일이다(너무 과격한 표현인가?). 책임감, 주인의식을 느끼지 못하는 사람들이 인정도 평가도 그리고 보상도 못받는 일에 어떻게 열정을 갖게 되겠는가. "특별한" 조직원인 경우는 할 수도 있겠다는 생각을 했다. "특별한 조직원"이란 바로 조직에서 성공하기를 바라는 "야망"이 있는 사람을 말한다. "논리적인" R&R을 제안하고 설득해가는 과정, 그 과정을 통해서 그 개인의 power가 커지는 효과가 있다는 것을 경험했다. "논리적인" R&R을 주도하면 "물리적인" 업무 분장을 할 수 있는 위치가 되는 것이다. 즉 자연스럽게 사람들을 리드하고 관리할 수 있는 위치에 들어서게 되는 것이다. 

 

※ 논리적 vs 물리적 성격 구분

 

앞에서 R&R과 업무분장이라는 용어 앞에 "논리적", "물리적"이라는 말을 덧붙였다: "논리적인 R&R", "물리적인 업무분장". 

 

"논리적", "물리적"인 접두어는 달봉이가 "R&R"과 "업무 분장", 두 개념을 구분하기 위해서 생각해낸 방법이었다. 달봉이를 포함해서 많은 사람들이 "R&R"과 "업무 분장"을 구분하지 못하는 듯 하다. 어디에서고 "R&R"과  "업무분장"을 구분해서 정의해 놓은 문서는 찿지 못했다. 그러나 프로젝트를 진행하면서 느낀것은 이 두 개념은 다르다는 것이다. R&R은 논리적인 성격의 개념이라면 업무분장은 물리적인 성격의 개념이다.

 

달봉이가 엔지니어들에게 설명할때는 데이터베이스 설계 단계와 비유해서 이 개념들을 설명했다. 데이터베이스 설계를 할때는 "논리 설계", "물리 설계" 단계를 거친다. "논리 설계"에서 하는 가장 중요한 일은 "정규화(normalization)"이다. 정규화란 데이터를 중복되지도 않고, 빠지지도 않게 관리할 수 있도록 논리적으로 설계를 하는 것을 말한다. 반면에 역정규화(또는 비정규화)는 실제의 논리적인 설계를 물리적인 환경에 반영할때, 물리적 환경의 제약이 있는 상황에서 성능을 향상시키기 위해서 또는 다른 현실적인 목적을 위해서 데이터의 중복도 허용하는 것을 말한다. 

 

R&R을 정의할때는 "중복되지도 않고 빠지지도 않도록" 즉 논리적으로 완전하게 정의하는 것이 중요하다. 이 논리적인 R&R을 현실에 적용할때 현실적인 제약때문에 예를 들어 사람이 부족하거나 예산이 부족할때 한 사람이 여러 역할과 책임을 담당할 수도 있다. 이것이 업무 분장인 것이다.

 

논리적인 정의(R&R)없이 물리적인 정의(업무 분장)만 있게 되면 ?

 

문제가 발생한다. 외부 환경 즉 예산, 인력, 시간등은 계속 변하게 된다. 이 외부 환경이 변하면 업무 분장에 영향을 주게 되고, 업무 분장의 논리적인 근거인 R&R의 정의가 없으면 결국 팀과 개인간의 갈등의 원인이 될 가능성이 많다는 것이다. R&R의 존재는 현실에서 업무 분장과 관련해서 갈등과 불만이 생기게 될때, 팀과 개인간의 커뮤니케이션과 협상의 논리적인 근거 자료로 사용될 수 있다.

 

참고로 R&R은 어떻게 표현될까? 

 

"XXX업무"의 "관리자" 또는 "수행자"로 표현될 수 있을 것이다. R&R을 함께 표현하면 "XXX관리 업무", "XXX수행 업무" 이렇게. 즉 Role은 "XXX업무", Responsibility는 "RACI" 중의 하나로 표현하면 된다. 

RACI는 아래 포스트를 참고할 수 있을 것 같다.

 

2016.03.30 - [IT 살이/03.관리 - IT 관리] - RACI - 레이키? 레이씨?

 

 

■ 평가 체계

 

조직의 평가 체계는 팀과 개인의 불만, 불평과 직결될 수 있다는 것은 모두가 알고 있다. 어떻게 하면 공정한 평가 체계를 갖추도록 할 것인가가 모든 조직의 관심사일 것이다. 이것과 더불어 이번 SM을 하면서 느낀 것을 요약해 보면 다음과 같다.

 

요즘의 대부분의 조직들은 계층 구조를 갖는다. 특정 조직은 더 큰 조직 트리의 일부로 속하게 된다. 즉 부모 조직이 있고, 때로는 자식 조직들이 있다. 이런 형태의 조직 구조에서 "단일한" 평가 체계를 갖는 것에 대한 불합리를 이번 프로젝트에서 인식하게 되었다. 제일 정점의 조직 예를 들어 경영층 또는 임원층이 정의한 "단일한" 평가 체계를 하위의 모든 자식 조직에 적용하려고 하는 것이 현실적으로 무리가 있다는 것이다. 

 

예를 들어 본사 및 경영층에서 만든 평가 체계는 그 회사, 그 기업의 비전과 목표에 맞는 평가체계일 것이다. 하위 조직이 상위 조직에 속해있는 이상, 부모 조직의 비전과 목표를 달성하는 것도 중요하다. 하지만,  부모 조직의 비전과 목표를 달성하기 위해서 그 하위 조직만이 갖는 비전과 목표가 있다. 따라서 그 하위 조직 자체의 평가 체계도 추가로 정의되어야 한다는 것이다.  부모의 비전과 목표를 상속하고 그 범위안에서 다시 해당 조직 자신만의 비전과 목표가 있어서 그것을 달성하기 위한 평가 체계가 준비되어야 한다는 것이다.

 

그러나 현실에서는 이게 안되고 있다. 각 조직의 비전과 목표를 정하고 평가체계를 레벨별로 정하는 것이 힘들까? 그런 평가 체계를 구축하는 것 자체가 힘들 수도 있지만, 구축의 중요성을 윗 사람들은 모른다는 것, 그것이 더 힘든 요인중의 하나인 듯 하다.  평가를 하는 사람이 평가를 받는 사람들 입장을 이해해서 용기있게 리소스( 시간, 돈, 인력 등)를 투자하는 것은 힘든일이다. 평가를 하는 그 사람도 다른 사람의 평가를 받는 중간 계층의 관리자라면 더욱 더 힘들 것이다.

 

그래서 현실의 조직에서는 "상관의 주관적인 평가"가 객관적인 평가 체계를 대체한다. 즉 상관의 재량으로 팀과 개인의 평가가 진행된다. 만약 그 상관이 실무를 모르거나 실무 이슈에 대한 이해도가 약하게 되면? 또는 "악한" 인간이 그 재량을 부정한 목적으로 사용한다면? 그 "평가 체계"는 공평하게 작동하지 않을 것이고 소속 팀과 개인들의 불평은 높아지게 될 것이다.

 

그러나 평가 체계와 조직의 운영 performance와의 상관 관계에 대한 인식을 갖는 관리자라면, 거기에 모두의 행복을 위하는 좀 더 휴머니즘적인 성향을 갖는 관리자라면 어떻게든 리소스를 마련할 수 있는 기회는 있지 않을까?

 

■ IT 관리 체계( IT 관리 프레워크)

 

IT 시스템을 관리하기 위해서도 앞에서 말한 논리적인 관리 체계를 도입할 필요가 있다는 것을 말하고 싶다: 시스템 관리 체계, 보안 관리 체계, 성능 관리 체계 및 조직 관리 체계.  앞에서 말한 물리적인 조치 이전에 논리적인 관리 체계의 중요성은 이곳에도 적용된다고 할 수 있다. 

 

사실 "체계 도입"이라는 용어를 사용하기 보다는 "사고 방식의 전환"이라고 말하는 것이 경영자나 관리자에게는 덜 부담스러울 것이다. "체계 도입"라고 말하면, 엔지니어적인 마인드가 강한 사람들은 "시스템 도입"과 혼동한다. "시스템 도입"은 다시 "솔루션 도입"으로 오해되어서 결국 "돈이 들어간다"는 것과 마찬가지라고 생각해서 대화가 잘 안되는 경험을 했다. 또는 ITIL같은 커다란 체계를 도입하는 것으로 오해해서 지레 포기하게 되는 것 같다. 

 

사실 "체계 도입"은 앞에서 말한 대로 일을 처리해 나가는 방식 즉 "사고 방식의 전환"이라는 것과 많은 관계가 있다. 이전 포스트에서도 언급했듯이 보안이나 성능을 향상시켜야 한다는 이슈를 해결하기 위해서 Top-down 방식이냐 bottom-up 방식이냐에 따라서 다른 접근 방식을 택하게 된다. 사고방식에 따라서 관리 프레임워크 정비를 우선적으로 할 것이냐 아니면 솔루션 도입 우선으로 해서 일을 진행할 것인가에 대한 선택이 달라진다.

 

특정 시스템이나 어플리케이션이 아니라 보안이나 성능같은 전사적인 이슈( 전문 용어로 하자면 cross-concern적인 이슈)에 대해서는 Top-down 방식의 사고 방식, 즉 "위에서 바라보는 관점 즉 조감을 하는 관점"에서의 이슈 인식이 필요하다. "IT거버넌스, IT 아키텍처, 관리 프레임워크"같은 용어들이 이런 관점을 기반으로 하는 개념들이다. 

 

이 세 용어의 차이점은 "고도(height)"의 문제일뿐 그 개념들이 가지고 있는 속성은, 위에서 내려다보는 "조감"이라는 점에서 유사한 개념들이다. "IT 거버넌스"가 경영층에서의 관점 즉 "1000 feet" 상공에서의 관점이라면 "IT 아키텍처"는 내려다 보는 영역을 "IT"로 좁혀서 좀 더 상세히 볼 수 있는 "100 feet"상공에서의 관점이고 그리고 "IT 관리 프레임워크"는 실제로 업무 수행 결과로 채워가는 데 사용할 수 있는 밑 그림까지 내려다 볼 수 있는 "1 feet" 상공에서의 관점이라고 볼 수 있다. 

 

1000 피트와 100 피트 상공에서의 관점에 대한 이론은 일반 수험 서적이나 이론서들을 통해서 많이들 알고 있다. 기술사, 감리사/CISSA, 보안/CISSP 등 이런 저런 자격증 수험서를 들춰보면 이런 곳에서는 100ft 즉 IT 아키텍처 정도까지는 설명하고 있다. 그러나 현실적인 기업의 관리에 필요한 "IT 관리 프레임워크"에 대한 설명은 그렇게 많지가 않다. 아니 없었다고 보는 것이 맞을 것 같다. 왜냐면 이것은 기업이나 회사의 현실적인 상황이 많이 개입을 하기때문에 1 feet 상공에서의 관점은 일반화가 힘들기때문이다. top-down 방식의 조감하는 관점에서의 관리가 필요하긴 한데, 교과서에서 배운 수준만으로는 현실에 적용하기는 무리다는 것이다. 

 

그러나 이번 프로젝트를 진행하면서 느낀것은 "1000, 100 feet" 상공에서의 수준에서의 개념들을 기반으로 해서 1 feet 수준의 IT 관리 프레임워크가 IT 조직에 만들어져야 한다는 것을 절실히 느꼈다. 이런 관리 프레임워크를 구축하는 데에도 리소스가 투자되어야 하지만, 이 프레임워크는 "중복되지도 않고, 빠지지도 않는" 것을 목표로 한다. 즉 관리자가 노력하면 재무적인 관점에서도 충분히 사장님을 설득할 수 있을 것이다. top-down관점에서의 관리 프레임워크와 관련된 이전 포스트들이다. 

 

2016.07.15 - [IT 살이/03. 관리 - 보안 관리] - 시스템 보안 아키텍처, 그게 뭐고 왜 필요하나요?

2015.11.11 - [IT 살이/03. 관리 - 성능 관리] - 성능관리 전략

 

■ 계약 체계

 

현실의 많은 조직에서는 한 작업장에 직영과 아웃소싱 업체 직원등 다양한 계약 관계의 사람들이 섞여있는 경우가 많다. 이것도 앞에서와 같은 논리적인 개념들을 현실에 적용하는 것이 힘들어지는 이유가 되고 있다. 

 

예를 들어서 이 역할을 수행할 역량이 있는 사람은 "저 사람"이라고 판단되는 것이 "논리"이지만, 그 사람은 외주 업체사람라서 그 사람에게 그 일을 줄 수 없는 것이 "현실"인 것이다. 반대로 내부 직원들 중에는 이 역할을 수행할 수준의 사람이 없지만, 적당한 사람이 없어서 "이 사람"을 그 위치에 앉히는 것이 현실이다.  R&R과 업무 분장 그리고 관리 체계를 구축할때는 논리적인 개념들이 기반이 되어야 하는데, 현실적인 계약 관계로 인해서 논리성이 훼손되고 결과적으로 논리적인 개념이 적용되지 못하게 된다. 말 그대로 "꼬이게" 되는 것이다. 

 

이렇게 계약 체계는 시스템이 아닌 사람에 의존할 수 밖에 없는 현실을 만들어 내는 것 같다.  어쩔 수 없는 현실이긴 하지만 그런 조직에 있는 사람들은 모두가 힘들어지는 듯 하다. 만약 관리자가 "현실적인 계약 관계"보다는 "일의 논리성"을 중요시하는 사람이라면 불행중 다행이라고 할 수 있을 것이다. 

 

현실이 이렇긴 하지만 "의식있는" 관리자라면 그것도 나름의 재량이 있는 관리자라면 자신의 재량 범위 안에서 "계약 구조 체계보다는 IT 관리 프레임워크 상의 역할을 더 중요시할 수 있지 않을까"하는 생각을 해 본다.

 

 

 ■ 조직 체계 

 

앞에서 IT를 어떤 관점에서 보느냐에 따라서 Top-down, bottom-up 관점으로 나눌 수 있듯이 IT를 어떻게 보느냐에 따라서 IT 조직의 조직도도 달라지는 듯 하다. 

 

조직에서의 IT는 앞에서 말했듯이 "거버넌스(아키텍처)"의 역할도 있고, 기업의 본래 비즈니스가 잘 수해되도록 하는 "지원"의 성격이 있다. 이 두가지 측면중에서 어떤 측면을 중요하게 여기느냐에 따라서 IT 부서가 조직도에서 차지하는 위치도 달라지게 된다. 

 

IT의 역할 - 거버넌스(아키텍처) 제공 역할, 업무 지원 역할

 

IT인(人)으로서 이 말이 의미하는 바를 다시 해석하면 "IT가 거버넌스와 아키텍처를 제공하는 역할을 한다"는 이미지를 갖도록 노력하는 것이 IT가 기업에서의 입지를 확보해가는 방법이라고 달봉이는 보는 것이다. 

 

IT 역할을 이렇게 구분하고, 인식하는 것은 추상적인 의미는 아니다. 현실적인 중요성이 있다. IT 역할을 어떻게 인식하느냐에 따라서 전체 조직을 IT가 주도하도록 만들어가느냐 아니면 다른 조직을 지원하는, 즉 속어로 표현하자면 "따까리" 조직으로 전락시키느냐가 결정된다. 

 

IT가 담당하는 "기술적인 작업"은 앞에서 말한대로 속성상 "거버넌스(아키텍처)" 작업과 "지원" 작업으로 나뉜다. IT 기술팀에서의 입지를 확보하려면 "거버넌스(아키텍처)"가 주된 일이고 "지원"은 부수적으로 하는 일이라는 것을, 다른 사람들이 그렇게 인식하도록 노력해야 한다고 본다. 이것은 IT조직이 살아남기 위한 현실적인 방법일 수도 있지만, 논리적으로도 그렇게 되지 않으면 IT 시스템이 통합적으로, 일관되게 관리되지 않는다는 점에서도 중요한 의미가 있다. 일관된, 통일된 관리가 되지 않으면 관리 비용이 늘어나게 되고, 그렇게 되면 관리 담당자 뿐만 아니라 사장님도 싫어하게 될 것이다.

 

다른 사람들이 IT를 "거버넌스(아키텍처) - 정", "지원 - 부"와 같은 인식을 갖도록 하는 구체적인 방법은 "말"로만 해서 될 문제는 아니다. 다른 사람들의 인식을 변화시키기 위한 많은 노력과 "아키텍처"와 "지원"에 대한 능력이 모두 겸비되어야 한다는 것을 절감할 수 있었다. 이런 능력은 개인 차원뿐만 아니라 IT 조직 차원에서도 준비되어야 할 것이다. 

 

간단히 하려고 했는데, 또 길어졌다. 말이 길어지면 수정해야 하는 내용이 또 생기는데.