웹 서비스 소프트웨어 개발 회사의 효율적인 조직 구조 및 관리

지금까지 두 번의 글을 통하여 조직이 커지면서 생산성이 떨어지는 이유에 대하여 살펴보았다. 첫 번째 글에서는 생산성이 떨어지는 가장 큰 원인이 업무와 조직의 세분화라고 이야기했다. 두 번째 글에서는 이 같은 세분화가 어떠한 문제점을 가지고 있는지는 지난 글에서 다루었다.

그렇다면 소프트웨어 개발 회사는 어떤 형태의 조직 구조와 업무 형태를 가져야할까? 지금부터 내가 생각하는 웹 서비스 소프트웨어 개발 회사의 조직 구조 및 업무 형태에 대한 해결 방법을 제시해보도록 하겠다. 이 해결 방법은 지금까지 나의 경험을 바탕으로 이러한 방향으로 나아가는 것이 바람직하지 않겠느냐는 의견을 제시하는 것이다. 글을 읽으면서 내가 생각하는 방향이 가지는 문제점과 또 다른 대안에 대해서 많은 의견을 주면 좋겠다.

핵심 업무 중심으로 조직이 확대

모든 회사는 회사를 유지하는데 가장 핵심이라고 할 수 있는 업무가 있다. 웹 서비스 소프트웨어 개발 회사라면 회사의 중심에 서비스(또는 프로젝트)가 있을 것이다. 웹 서비스 개발 회사가 성장하면서 급격하게 조직이 커지는데 이 때 중심에 두어야 할 것은 서비스이며, 서비스를 중심으로 조직 구조가 확대된다.

서비스를 중심으로 조직을 확대하다 보면 각 서비스에서 공통적으로 발생하는 문제와 해결책이 빈번하게 발생한다. 이 때문에 업무의 효율화라는 명목과 효율적인 인력 관리를 통한 비용 절감이라는 명목으로 이 업무를 전담하기 위한 조직들이 서서히 등장하기 시작한다.

이 시점이 조직이 커지면서 조직을 재편할 때 가장 중요한 시점이라고 생각한다. 이 시점에 공통 업무를 위한 새로운 조직을 만드는 것에 신중해야 한다. 한번 만들어진 조직을 없애고 새로 재편하기 위해서는 조직을 만들 때보다 몇 배의 비용과 고통이 따르기 때문이다. 이 시점에 조직을 각 업무별로 세분화하고, 공통 작업 단위로 세분화할 경우 발생하는 문제점에 대해서는 앞에서 살펴봤다.

그렇다면 어떤 방법이 가능할까? 나의 관점으로 봤을 때 하나의 서비스를 담당하는 조직이 커지고 공통 업무가 발생한다고 하더라도 서비스의 핵심 업무 단위에 대해서는 세분화하지 않는 전략을 가져가야 한다. 예를 들어 하나의 웹 서비스를 개발하기 위하여 필요한 핵심 업무 단위는 PM, 개발자, 디자이너, DBA, QA라고 판단한다면 이 업무 영역에 대한 세분화는 하지 않는 것이 바람직하다. 또한 각 구성원간의 유기적인 협업이 필요한 경우에도 분리하는 것은 바람직하지 않다. 이 영역에 대한 분리는 신중하게 판단해 마지막 단계에서 분리하는 것이 바람직할 것이다.

조직이 커지면서 조직을 재편할 때 가장 중심에 두어야 한다고 판단하는 부분은 서비스에 중심을 두고 의사 결정을 하는 조직이 만들어져야 한다는 것이다. 조직을 키우더라도 서비스를 중심으로 조직이 커지고, 수직 구조가 만들어 지더라도 서비스를 기준으로 만들어 지는 것이 바람직하다..

서비스 중심으로 조직 구조를 가져갈 경우 각 조직에서 공통적으로 발생하는 문제를 해결하기 위한 방안으로 별도의 조직을 만들고자 하는 경우가 발생한다. 이 같은 요구는 항상 발생하는 것이 아니라 특정 상황에 따라 가끔 발생하는 경우가 일반적이다. 따라서 문제가 발생하는 시점에 해당 문제를 해결하기 위하여 일시적으로 조직(TF 형태)을 만들거나, 만약 공통 문제를 해결하는 상시 조직이 있다면 일정 기간 동안 해당 조직에 참여하여 개발을 진행한 후 원 조직으로 복귀하거나 공통 모듈에 대한 지속적인 지원이 필요하다면 지원 조직으로 남는 형태를 취해야 할 것이다.

예를 들어 A 서비스를 개발하면서 얻게된 지식을 전사적으로 사용하는 것이 좋겠다고 판단된다면 A 서비스에 참여했던 개발자가 사내 프레임워크 개선 조직에 참여하여 해당 기능을 사내에서 범용적으로 사용할 수 있도록 개발하고, 다시 원 조직으로 복귀하는 구조이다.

이와 같이 조직을 유지해야 하는 이유는 지원 업무를 담당하는 조직을 최대한 작은 규모로 유지하기 위해서이다. 지원 업무를 담당하는 조직이 커질 경우 지원 조직은 자체적으로 성과를 만들어야 하는 상황이 발생하는 경우를 종종 본다. 자체적인 성과를 내기 위하여 만들어진 결과물은 실질적으로 각 서비스 조직에서 필요하지 않은 경우가 많다. 그 이유는 지원 조직의 사용자라고 할 수 있는 각 서비스 조직의 요구사항을 수렴하기 보다는 자신의 조직에 성과가 클 것으로 보이는 결과물을 만들어 내기 때문이다. 이와 같이 만들어진 결과물은 서비스에 적용되어야 최종적으로 성과를 낼 수 있다. 따라서 지원 조직은 자신들이 만든 결과물을 서비스에 적용하려는 시도를 끊임없이 시도하게 된다. 이 같은 상황에서 서비스의 목표와 지원 조직의 목표가 충돌하는 상황이 발생한다. 이 같은 상황이 발생하면 어느 조직이 힘이 세냐에 따라서 적용 여부가 결정되는 구조로 치닫게 된다.

따라서 진정 사용자에게 가치를 만들어내는 핵심 업무를 기준으로 조직이 커지는 것이 바람직할 것으로 판단한다. 이 상태에서 특정 문제를 해결하기 위한 지원 조직은 임시 조직으로 유지하거나, 상시 조직으로 유지한다면 최소한의 인력으로 유지하는 것이 바람직하다.

서비스 중심으로 조직이 발전하면 조직 구조가 수직 구조에서 수평 구조로 발전하는 것이 가능하다. 지금까지 국내 거의 모든 회사의 조직 구조는 수직 구조이다. 그러나 수직 구조는 조직이 커지면서 의사 결정자의 단계가 증가하고, 의사 결정자의 수가 많아짐으로써 의사 결정 속도를 더디게 한다. 특히 웹 서비스와 같이 사용자의 요구에 발빠르게 대응하고, 빠르게 변화하는 기술에 대응하기 위해서는 조직이 커지고, 서비스 복잡도가 증가하더라도 빠른 의사 결정을 요구하고 있다. 이 같은 요구에 대응하기 위해서는 수평 구조로 유지하는 것이 더 빠른 의사 결정을 하고 사용자에게 가치를 부여하는 일에 집중할 수 있다.

리소스의 효율적인 사용을 하려면..

각 업무별로 조직 구조를 가져가는 또 하나의 이유는 리소스를 효율적으로 사용한다는 명목이 있다. 한 명의 개발자가 한 서비스를 전담하고 있을 경우 우선 순위가 높은 서비스 또는 프로젝트가 발생했을 때 유연하게 대처하기 힘들다는 것이다. 또 하나는 HTML 마크업이나 디자인 작업과 같이 한 서비스에 100%를 투입할 작업 분량이 되지 않는 경우이다. 이 같은 상황에 대응하기 위하여 업무 단위로 조직을 분리하는 것이 효율적인 리소스 관리가 가능하다고 생각한다.

첫 번째 우선 순위가 높은 서비스에서 새로운 프로젝트가 발생했을 때 어떻게 하면 유연하게 대처할 수 있을까? 업무 단위로 조직을 분리한다고 해서 이 문제를 해결할 수 있을까? 나는 없다고 생각한다. 업무 단위로 조직을 분리하더라도 새로운 업무가 발생하면 똑같은 상황이 발생한다. 따라서 내가 생각하는 해결책은 다음과 같다.

먼저 각 서비스별로 조직 구조를 만들고, 서비스를 운영, 개선하기 위하여 상시적으로 필요한 인원의 적정 규모가 어느 정도인지를 결정한다. 인원 규모는 서비스를 운영하면서 어느 정도가 적정 수준인지를 판단하는 것이 바람직하다. 이와 같이 상시 업무를 담당하기 위한 인원을 제외한 사람들은 별도의 인력풀처럼 관리한다. 이 인력풀에 속해 있는 사람들은 우선 순위에 따라서 자신이 하고 싶은 서비스 또는 프로젝트에 참여하여 업무를 진행하는 방식을 취한다.

인력풀이라고 이야기하니 SI 할 때의 인력 시장과 같은 것 아니냐고 부정적으로 생각하는 사람들도 많이 있다. 하지만 내가 생각하는 인력풀은 인력 시장과는 다르다. 인력풀에 속해 있는 사람들은 자신이 원하는 서비스 또는 프로젝트를 선택할 수 있는 권한을 주고, 서비스 또는 프로젝트가 완료되면 상시 업무를 진행할 것인지, 새로운 서비스 또는 프로젝트를 진행할지에 대한 선택권을 주어야 한다.

한 서비스에서 안정적으로 상시 운영 업무를 하는 것에 따른 장,단점이 있듯이, 인력풀에서 계속해서 새로운 업무를 맡게 되는 사람들에게도 충분한 보상이 주어져야 할 것이다. 예를 들어 하나의 프로젝트가 완료되었는데 바로 다른 프로젝트에 투입하는 형태처럼 하나의 부속품처럼 취급되는 것이 아니라 하나의 프로젝트를 완료하면 자신의 역량을 개발할 시간과 쉴 수 있는 여유 시간에 대한 보상이 뒤따라야 할 것이다.

또한 이 같은 구조를 지속적으로 유지하고 성장시키기 위해서는 서비스 조직, 인력풀 조직, 지원 조직 사이에 유기적인 업무 순환이 있어야 한다.

두 번째는 각 서비스에 한명에게 할당할 업무가 100%가 되지 않는 경우이다. 따라서 한 명이 여러 개의 서비스에 참여해야 효율적인 활용이 가능할 것으로 생각한다.

그런데 정말 이와 같이 관리하는 것이 리소스를 효율적으로 사용하는 방법일까? 한 측면으로 본다면 맞는 맞일 수 있겠지만, 별도의 조직을 만들어 조직을 관리하고 유지하는 비용을 생각한다면 이 또한 만만치 않은 비용이 발생한다. 또한 조직이 분리됨으로써 발생하는 협업 비용 또한 고려해야 할 것이다. 그렇다면 어떻게 하는 것이 합리적인 방법일까? 나 또한 이 부분에 대하여 명확한 해결책을 제시하기는 힘들지만 조직을 분리하는 것만이 좋은 해결책은 아니라고 생각한다.
이상적이기는 하지만 내가 생각하는 첫 번째 해결책은 가능한 한명이 하나의 서비스를 담당하도록 하는 것이다. 한 명이 여러 개의 서비스나 프로젝트를 담당하는 것은 서비스나 프로젝트 간의 이동 비용이 발생하기 때문에 한 명이 여러 개의 서비스를 담당하는 것은 효율적인 방법은 아니다. 하지만 동시에 여러 개의 서비스를 담당하는 상황이 아니라면 괜찮다고 생각한다. 한 명이 여러 개의 서비스를 담당하지만 시간 상으로 겹치는 부분이 많지 않다면 충분히 효율적인 작업이 가능하리라.

각 업무에 대한 역량 강화는?

업무 단위로 조직을 분리하는 이유 중의 하나는 역량을 강화하기 위한 목적이라고 이야기한다. 그런데 정말 업무 단위로 조직을 분리하면 전체적인 역량이 강화될까? 개인의 역량을 강화하는 것이 조직 구조에 따라 달라질까? 물론 일정 부분 영향을 미칠 수 있겠지만, 개개인의 역량 향상에 가장 큰 영향을 미치는 것은 자신의 역량을 강화하기 위한 개인의 노력이다. 개인의 노력이 부족한 사람은 어떤 형태의 조직이 되더라도 큰 효과는 볼 수 없으리라.

업무 단위로 조직을 분리할 경우 오히려 자신의 업무에 대한 이해도와 지식은 높아질 수 있겠지만, 다른 업무에 대한 지식과 이해도는 상당히 낮아지는 것을 느낄 수 있다. 최근 전문화라는 이유로 업무를 세분화해서 자신의 분야에만 관심을 가진다면 이것이 진정 전문가로서 성장할 수 있는 길일까? 진정 전문가로서 성장하려면 자신의 전문 분야 지식도 필요하지만 이와 더불어 서비스(또는 프로젝트)의 전반적인 모습을 같이 볼 줄 알아야 하며, 다른 분야에 대한 지식과 이해도도 필요하다고 생각한다. 그렇게 되었을 때 다양한 분야에 대한 고려가 가능할 것이기 때문이다. "사용자의 입장은 고려하지 않고, 자신의 전문 분야에 빠져 역량만 강화하고 있다면 이것이 진정 전문가의 올바른 길일까?"라는 의구심을 가져본다.

업무 단위로 조직을 분리하던 서비스 단위로 조직을 분리하던 개인의 역량을 강화한다는 것은 쉽지 않은 일이다. 진정 회사가 개인의 역량 강화를 통하여 전반적인 품질 향상을 바란다면 멘토링을 적극 활용하고, 이와 같은 멘토링에 대해서는 개인 성과와 역량에 반영하여 모든 구성원이 적극적으로 참여할 수 있도록 해야 한다. 국내 대부분의 회사를 보면 개인 역량을 강화하고, 교육을 하는 것이 정말 중요하다고 이야기하지만 실상을 보면 신입 사원을 키우고 사원의 역량을 강화하는데 인색한 것이 사실이다. 정말 개개인의 역량 강화가 서비스 품질 향상에 중요하다는 판단을 한다면 단기적인 성과 위주의 전략이 아니라 장기적으로 인내심을 가지고 정책을 펴야할 것이다. 개인의 역량 강화는 단기간에 비용을 투자한다고 해서 해결되는 것이 아니다.

평가는 어떠해야 하는가?

앞의 글에서도 잠시 언급했지만 서비스 기반으로 조직 구조를 가져갈 경우 평가는 서비스 단위로 하는 것이 바람직하다. 하나의 서비스에 여러 업무가 혼재되어 있기 때문에 각각의 개인을 평가하는 것이 힘들 뿐더러 팀워크를 위해서 좋지 않은 방법이다. 업무에 대한 성과는 개인이 아니 서비스를 기준으로, 서비스 지원 조직은 서비스에 대한 기여도를 기준으로 평가하는 것이 바람직할 것으로 판단한다. 물론 내가 생각할 때 평가는 개인이나 조직에 대한 동기 부여 효과는 크지 않을 것이라 생각하지만 그래도 해야 한다면 개인보다는 조직 단위로 하는 것이 불합리한 부분을 최소한으로 줄일 수 있다고 생각한다.

개인에 대한 평가는 개인의 역량에 대한 평가가 되어야 한다. 서비스 기반 조직이고 수직 구조에서 수평 구조로 조직 구조를 유지한다면 과거처럼 좀 더 높은 관리자로 올라가는 것이 승진의 개념이 될 수 없다. 수평 구조에서는 상위 조직장으로 올라가는 것이 의미 있는 것이 아니라 자신의 역량 레벨을 높이는 것을 승진의 개념으로 보아야 할 것이다. 각 업무별 역량에 대한 기준을 세우고 이 기준에 따라서 개인별로 역량 레벨을 평가하는 방식이 되어야 할 것이다.

피터 드러커는 프로페셔널의 조건에서 조직에 대한 공헌의 세 가지 영역에 다음과 같이 이야기하고 있다.

'공헌'은 여러 가지를 의미한다. 모든 조직은 세 가지 주요 영역에서 성과를 올리 필요가 있다. 1) 직접적인 결과를 산출하고, 2)가치를 창출하고 재확인하며, 3)인재를 육성하는 것이 그것이다. 만일 이 세 가지 영역 가운에 어느 하나라도 성과를 달성하지 못한다면, 그 조직은 썩어서 없어지고 말 것이다. 그러므로 조직에 몸담고 있는 모든 지식 근로자의 공헌 활동은 이 세 가지 영역과 연결되어 있어야만 한다. 한편 세 영역의 상대적인 중요도는 조직의 필요에 따라 그리고 지식 근로자 개개인에 따라 상당히 많이 달라진다.
– 피터 드러커, 프로페셔널의 조건 중에서..

위 글에서 피터 드러커가 이야기하고 있듯이 지식 근로자를 평가하고 판단할 때 세 가지 측면에서 회사에 대한 기여도를 판단해야 할 것이다. 하지만 많은 회사에서 "1)직접적인 결과를 산출하고"에 해당하는 직접적인 성과에만 집중하는 경향이 있다. 이와 같이 성과에만 집중하게 되면, 회사 전반적인 분위기가 단기적인 성과에만 집착하게 되는 경향이 있다. 또한 성과 위주의 평가가 우선시되는 많은 조직을 보면 서비스를 안정적으로 운영하는 것보다 새로운 기능을 추가하는 것에 더 큰 가치를 부여하는 경향이 있다. 새로운 결과물을 만들어 내는 것이 성과 측면에서는 더 큰 성과로 보이기 때문이다. 하지만 이 같은 현상은 결과적으로 고객의 목소리에 귀기울이기 보다는 각 조직의 성과에 이익이 되는 업무를 우선시하는 경향이 발생하게 된다. 따라서 조직과 개인을 평가할 때 직접적인 성과 뿐만아니라 "2)가치를 창출하고 재확인하며, 3)인재를 육성" 부분에 대한 기여도 고려해야 할 것이다.

지식 근로자인 우리는 어떻게 대응해야 하는가?

내가 위에서 제시하는 형태로 조직 구조를 가져갈 경우 지금까지 일하던 방식과 다르기 때문에 많은 부분에서 혼란스러움을 느낄 수 있다. 이 같은 변화에 대응하기 위하여 우리 지식 근로자들은 어떻게 대응해야 할까?

지금까지 수직 구조에서는 위에서 시키는 일만 열심히 하고, 조직이 움직이는 데로 따라가기만 하면 되는 수동적인 자세를 가지고 있는 것이 사실이었다. 하지만 수평 구조로 변경된다면 지금보다는 좀 더 적극적으로 자신의 의견을 개진하고, 자신의 역량을 강화하기 위하여 더 많은 노력을 해야할 것이다.

이 같은 노력은 회사를 위한 것이 아니라 결과적으로 우리 자신을 위한 것이다. 좀 더 효율적으로 일함으로써 더 좋은 품질의 서비스를 만들어 회사에 기여하는 바도 크지만 궁극적으로 우리가 시간적인 여유를 가질 수 있으며, 이런 여유 시간을 통하여 좀 더 재미있고, 의미 있는 일들을 해나갈 수 있을 것이기 때문이다.

마치며..

지금까지 세 번에 걸쳐서 글을 작성했다. 이 번 글에서 제시하고 있는 것처럼 조직 구조를 바꾸고, 평가 제도를 개선한다고 지금까지 비효율적이었던 부분이 곧바로 효율적인 구조로 바뀐다고 생각하지 않는다. 내가 세 번의 글을 통하여 이야기하고 싶었던 것은 업무 세분화, 전문화로 인해 비효율적인 부분에 대하여 다룬 것 뿐이다. 업무와 조직을 너무 세분화하는 것은 많은 문제점을 가지고 있기 때문에 신중해야 한다는 것이며, 새로운 방법으로 접근할 수도 있다는 것이다.

실질적으로 업무의 효율화와 생산성을 극대화하기 위한 더 좋은 방법은 바로 우리 개개인의 마음 가짐이다. 어떤 조직 구조를 가지던, 어떤 평가 체계를 가지던 간에 같은 목표와 비전을 가지고 업무에 임할 수 있다면 크게 중요하지 않다. 각 조직의 성과 위주가 아니라 정말 사용자에게 가치를 만들어 내는 것에 집중할 수 있는 환경이라면 어떤 조직 구조라도 상관 없다. 하지만 이런 상태를 유지하는 것은 쉽지 않다. 특히 조직이 커지면서 이와 같은 초심을 유지하는 것은 더더욱 힘들어지게 된다. 이런 상황에서 좀 더 사용자 지향적이고, 목표 중심적인 조직 구조 형태가 어떤 것인지에 대하여 언급했다.

이 글은 내가 포털 회사에 4년 간 몸담고 있으면서 느꼈던 내 나름대로의 생각을 정리한 것이다. 이 글의 내용은 포털과 같이 하나의 소프트웨어를 지속적으로 관리하고 성장시켜 나가야하는 소프트웨어 개발 회사에 도움이 될 듯하다. 나는 지금까지 웹 에이전시, SI 회사에 몸담은 경험이 더 많은데 웹 에이전시, SI와 같이 특정 회사에 업무 의뢰를 받아 단기간에 개발을 완료해야하는 조직에는 적합하지 않을 수 있다.

이 글의 내용은 내가 몸담고 있는 조직의 의견과는 무관하다. 지금까지 소프트웨어 개발 업무를 진행하면서 느꼈던 내 나름대로의 생각을 정리한 것이다. 내가 이 글을 쓰는 가장 큰 이유는 내가 잘못 판단하고 있는 부분도 많을 것이기 때문에 그에 대한 의견을 받아보고 더 바람직한 모습에 대한 논의를 해보고자 함이다.

논리적으로 타당하지 않거나 근거가 부족하다고 생각하는 부분에 대해서는 가차없이 의견 마구마구 날려주기 바란다.

페이지

Posts List

2014년 8월 23일 토요일

오래가는 웹기획 & UX 디자인

2) 웹기획의 기본 - 웹사이트 구축을 위한 조직 형태와 역할

사업 기획

마케팅 기획, 마케팅 실행

사이트 기획

프로젝트 관리

디자인

개발

테스트

사이트 운영

웹 사이트는 소프트웨어일까?

핵심 업무 중심으로 조직이 확대

리소스의 효율적인 사용을 하려면..

각 업무에 대한 역량 강화는?

평가는 어떠해야 하는가?

지식 근로자인 우리는 어떻게 대응해야 하는가?

마치며..

standalone 시기

2 tier 시기

asp의 폭발적인 발전

php의 발전 및 apache httpd의 확장

servlet과 asp .net의 발전

fat client의 발전

3 tier, n tier 시기

script language의 발전

web service의 개발

MVC의 발전

mobile 기기의 발전 및 확산

fat client의 쇠퇴와 HTML5의 대두

Big data와 Cloud 의 대두

Open source의 대두

웹 개발자가 익혀야지 될 기술들 - 2013년 기준

.net보다는 java

spring

DB 기술

Controller 기술

Modeling 기술

개발 방법론

패턴 (Pattern)

단위 테스트 (Unit Test)

2014년 2월 23일 일요일

[튜토리얼/MashUp] 웹 컴포넌트: 차세대 프론트엔드 웹 개발로 가는 관문(Web Component: the Gate to Next Front-end Web Developments)

웹 컴포넌트?

> 골격만큼이나 중요한 다른 것들...

> 무엇이 필요할까?

웹 컴포넌트를 지탱하는 규격들

> 캡슐화와 스코프의 제어 - Shadow DOM

> 런타임에만 활성화되는 복제 가능한 마크업 - HTML Template

> 새로운 엘리먼트의 동적인 등록 - Custom Element

> 웹을 위한 #include - HTML Imports

웹 컴포넌트가 왜 중요한가?

도구들

앞으로를 예상해봅시다.

읽어볼만한 글들

링크모음