TCP/IP
개발조직문화에 대해 - 회사, 문화, 그리고 프로세스
프로그램의 구조는 그것을 제작하는 조직의 구조를 반영한다 - 멜빈 콘웨이
개발문화라는 단어가 조금은 생소할수도 있겠다. 다수의 인원이 하나의 조직을 이루면 고유의 방식과 행태가 생겨나게 된다. 이것이 그 조직의 문화다. 조직의 특성과 조직을 이루고 있는 각 개인별 특성이 아우러져서 조직문화가 형성된다. 회사인 경우 기업문화다. 개발조직의 문화를 개발문화라고 한다면, 그 특성에 대해 살펴볼 필요가 있다. 조직이 일을 처리하는 합의된 방식을 프로세스라고 부른다. 회사과 기업문화, 그리고 프로세스는 유기적인 관계다. 관점에 따라서는 회사, 그리고 기업문화, 프로세스를 하나의 큰 덩어리로 볼 수도 있다. 프로이센군의 정치가였던 게르하르트 폰 샤른호르스트는 군대가 똑똑한 지휘관에게 너무 많이 의존하는 것은 매우 위험하다고 믿었다. 그래서 그는 유능한 부관들이 지휘관에게 독립적인 조언을 할 수 있는 참모 시스템을 개발했다. 오늘날 모든 기업에서 활용하고 있는 조직원리가 바로 이 참모 시스템에 뿌리를 두고 있으며, 이 참모시스템 자체가 하나의 프로세스다. 직급체계로 상향식 업무보고가 이루어지는 것은 하나의 프로세스다. 오늘날 이런 일반적인 회사 체계를 프로세스라고 말하기는 어렵다. 오늘날 프로세스는 회사의 체계보다는 사업의 종류에 따라 일을 처리하는 과정을 의미한다. 회사와 기업문화, 프로세스의 관계를 먼저 이해해야 각각에 대한 심화가 가능하다.
첫번째로 질문할 수 있는 것이 '회사, 기업문화, 프로세스 중 무엇이 우선인가'이다. 이 질문에 대한 대답은 단연 '회사가 우선'이다. 회사가 없는 상태에서는 그 문화도, 일을 하는 프로세스도 언급조차 될수 없다. 조직이 있으면 그 조직이 가지고 있는 고유의 문화가 형성되게 된다. 프로세스는 그 다음 생겨나게 된다. 자연발생적으로 형성된 조직문화에 맞춰 프로세스는 대부분 인위적으로 만들어진다. 따라서 회사와 기업문화와 프로세스 중 최우선은 회사, 그 다음은 기업문화, 그리고 맨 마지막이 프로세스다. 이를 단순화해서 표현하면 다음과 같다.
TCP/IP - Team, Culture, Process Is Proper order
개발자들에게 TCP는 익숙한 용어다. TCP는 일종의 네트워크 프로토콜로 IP 프로토콜을 기반으로 동작한다. 역의 관계는 성립할 수 없다. 조직, 문화, 프로세스의 순서는 맨처음 조직의 탄생에 있어서는 순차적인 방향으로만 전개가 가능하다, 하지만 조직의 라이프사이클동안 역으로의 변화 또한 가능하다. 맨 나중에 형성되는 프로세스가 조직의 존망에 직접적인 영향을 준다. 하지만 근본은 조직과 조직문화에 있다. 구축된 프로세스가 역으로 조직문화, 나아가서는 조직에 영향을 끼친다. 좋은 프로세스는 좋은 영향을 추고, 나쁜 프로세스는 나쁜 영향을 준다. 좋은 프로세스로 인해, 조직의 문화가 개선되고 나아가 회사가 성장하는 사례는 심심찮게 볼 수 있다. 프로세스로 인해 조직의 문화가 망가지고 회사를 해를 끼치는 경우는 그보다도 더 많이 볼 수 있다. 이는 잘못된 프로세스가 원인인 경우가 태반이며, 잘못된 프로세스는 기존 조직과 조직문화를 고려하지 않은 결과로 생겨나게 된다. 나중에 프로세스를 다루는 글에서 살펴보겠지만, 원래의 프로세스 자체가 좋지 않아서 생기는 문제는 없다. 다 맞지 않는 옷일 뿐이다. 사람은 도구의 탓을 하지만, 실제 문제는 잘못된 도구를 사용한 사람의 탓이다. 실제 회사와 조직, 그리고 프로세스의 관계가 전도됨으로 인해 생기는 문제가 잘못된 프로세스 적용 사례의 대부분의 원인이다.
조직에는 고유의 문화가 존재한다. 그것은 의도적으로 만들어진 것일수도, 초기 조직원들의 영향으로 자연스럽게 정착된 것일수도 있다. 기업의 문화라고 함은 쉽게 얘기하면, 일을 할 때 의식적이거나 무의식적이거나 따라할 수 밖에 없는 환경이라고 말할 수 있다. 조직의 문화와 궁합이 맞는 프로세스들이 있다. 인원이 적은 회사에서는 프로세스보다는 문화적인 관습에 의한 업무처리가 더 효율적일 수 있다. 빡빡하고 거창한 프로세스보다는 유연한 소규모 프로세스가 적합하다. 안드로이드 앱을 만드는 스피디한 소규모 소프트웨어 개발회사에 인공위성을 만드는 프로세스와 방법론을 적용할 수는 없다. 10년 가까운 기간을 프로젝트 기간으로 설정하는 국방부 대규모 프로젝트의 폭포수 모델을 영세 소프트웨어 회사에서 따라한다고 하면 미친 짓이다.
소규모의 회사들은 흔히 프로세스 없이 일하는 것처럼 보이지만, 실상 이들에게도 엄연히 프로세스가 존재한다. 스티브 맥코넬의 명저 <프로페셔널 소프트웨어 개발>에서는 소규모 회사의 소프트웨어 개발 방식을 일컬어 '책임 기반 개발'이라고 소개한다. 책임기반 개발은 흔히 "영웅 중심 개발"이나 "개별 권한 부여"등으로 불리운다. 프로세스라고 보기에는 정형화되어 있지 않으며, 자유도도 극히 높다. 소규모로 게임을 개발하는 한국 회사들이 대부분 이런 회사들이다. 한국의 대다수 회사들이 책임 사칭 조직이다. 책임을 중시한다고 사칭하는 조직들 - 쉽게 말해 프로세스 없는 변변찮은 회사들은 직원들을 어떻게 하면 밤 늦게까지 붙잡아놓고 일을 시킬수 있을지를 중요하게 생각한다. 맥코넬은 '책임 사칭 조직'은 결과(긴 근무시간)와 원인(높은 동기부여)를 혼동한다고 말한다. 이러한 책임 사칭 조직은 결국 '착취 조직'으로 전락하는 경우가 태반이다.
반면 프로세스 기반 개발은 오랜 경험을 통해 습득한 프로세스와 프로세스에 녹아있는 여러 소프트웨어 공학 기법들을 가지고 프로젝트를 수행하는 것이다. 얼핏 책임기반 개발보다 그럴듯하게 보이지만, 성공적으로 정착시키기에는 고난이도의 개발 방식이다. 그렇기에 많은 회사들은 결국 책임기반 개발을 선호할 수 밖에 없다. 프로세스 기반 조직 역시 책임사칭 조직과 마찬가지로 프로세스 사칭 조직으로 전락하는 경우가 많다. 이런 프로세스 사칭 조직은 관료 조직에서 흔히 볼 수 있다. 프로세스 사칭 조직들은 조직이 아닌 프로세스 자체를 위한 프로세스에 투자하는 어리석은 짓을 되풀이하게 되고, 이 결과로 원래의 프로세스들의 장점이 단점이 되어버리는 경우가 비일비재하다. 프로세스에 대한 더 자세한 이야기는 뒤에서 다루기로 하자.
스티브 맥코넬은 책임기반 개발과 프로세스 기반 개발은 공존할 수 있다고 말한다. 당연한 얘기다. 얼핏 두가지가 상반된 것처럼 보이지만, 실상은 그렇지 않다. 두가지는 상호보완적인 관계다. 책임기반 개발이 비효율적인 경우가 있고, 프로세스 기반 개발이 비효율적인 경우가 있다. 서로의 비효율성은 다른 방식으로 보완 가능하다. 프로세스만을 추종하면 뛰어남은 포기해야 한다. 소프트웨어 개발은 공장에서 붕어빵 찍어내는 것과는 다르다. 실수가 없고 정형화할수 있다는 것만이 성공적인 개발프로젝트를 만들어 내지 못 한다. 책임과 사람만을 추종하면 안정성은 포기해야 한다. 들쭉날쭉해진다. 위험도가 커질수록 프로젝트의 실패 확률 또한 증가하게 된다.
진정한 개발문화는 프로세스와 사람이 서로 공존한다. 서로가 서로의 위에 군림하지 않고 유기적으로 맞물려 돌아간다. CTO,. CEO와 같은 최상의 접점에 있는 사람들의 역할이 더욱 중요해진다. 결국 가장 중요한 것은 사람이다. 프로세스는 인위적으로 정착될 수 없다. 개발 문화는 더더욱 그렇다. <처음처럼>에서 고 신영복 선생이 했던 말을 빌리면, 문화는 공산품이 아니라 농산품이다. 대지에 심고 손으로 가꾸는 것, 그리고 최종적으로 사람에게서 결실되는 것이다.
