할아버지 개발자를 만나고 싶다

외국 소프트웨어 회사에서는 할아버지 개발자들을 종종 볼 수 있다. 현재도 프로그래밍을 하고 있는 진짜 개발자들이다. 우리나라가 개발자들은 이런 할아버지 개발자를 만나보거나 이야기를 전해 들으면 많이 부러워한다. 

대부분의 개발자들은 경력이 쌓이면서 자연스럽게 관리 업무를 겸하거나 아예 관리자로 전환된다. 관리와 개발업무를 동시에 하는 개발자들도 관리하랴, 회의하랴 바빠서 본인이 가장 잘하며 좋아하는 개발 업무와는 점점 멀어지게 된다. 또 관리를 하지 않으면 회사에서 파워가 줄어들거나 대우도 안 좋기 때문에 자연스럽게 그리고 본의 아니게 관리 쪽 진로를 선택하지 않을 수 없게 된다. 종종 자신은 끝까지 개발만 하겠다고 고집하는 개발자들은 관리 능력, 커뮤니케이션 능력이 떨어지는 괴짜라고 생각하는 이상한 시각도 존재한다. 

S사의 예를 보자. 이 회사는 오래 전부터 개발자 경력을 보장해주고 있다. 제도적으로는 개발자 트랙을 선택한 사람들은 관리를 하지 않고 개발만 계속 할 수가 있다. 하지만 속을 보면 개발자 트랙을 선택하나 그렇지 않으나 큰 차이는 없다. 개발자 트랙을 선택한 경우에도 개발 일에만 집중할 수 없고 그렇지 않은 경우에도 개발과 관리를 겸하게 된다. 개발과 개발이 아닌 일을 명확하게 구분하지 않고 두루뭉술하게 일을 해서 대부분은 개발 경력이 쌓일수록 개발에 집중할 시간은 점점 줄어들게 된다. 

T사의 경우 10년차 이상이 되면 팀장이 되고 파트장을 맡는다. 대부분 회사에서 가장 뛰어난 개발자들이다. 하지만 관리를 조금이라도 맡은 이상 낮에는 개발에 집중할 시간이 거의 없다. 보고서 작성에 회의 참석, 다른 부서와 의견 조율, 이런 일로 하루를 보내다가 저녁이 되어서야 개발 일을 시작한다. 이런 생활을 몇 년 하다보니 자연스럽게 개발 일에서 손을 놓게 되었다. 

이런 회사에 경영자들에게 왜 회사의 가장 뛰어난 개발자들이 개발을 거의 못하는 관리 일을 시키냐고 물어보면 다음과 같은 얘기를 한다. 

“당연한 것 아닌가? 소프트웨어 개발은 워낙 특수해서 개발을 속속들이 잘 알아야 개발 조직을 관리할 수 있다. 그가 우리 회사에서 소프트웨어 개발을 가장 잘아는 사람이다. 그래서 그에게 개발 조직 관리를 맡기고 있고 본인도 그 자리를 원하고 있는 것으로 알고 있다.” 

주변에서 소프트웨어 업계의 유명했던 롤모델들을 보면 지금도 개발을 하고 있는 사람들은 그렇게 많지 않다. 왕년에 개발을 좀 했던 실력자이지만 현재도 개발을 하고 있는 엔지니어는 만나기 힘들다. 왠만한 뚝심으로는 개발자로 남아 있기가 어렵다. 당사자들이 환경에 순응해서 개발에서 손을 놓게 된 경향도 크다 

우리는 각 기업의 최고 개발자였지만 지금은 관리자인 사람들을 종종 만나게 된다. 이들은 대부분 본부장, 센터장, 부서장, 연구소장 등과 같은 직함을 가지고 있다. 이들 대부분은 과거에는 개발자였을지 모르지만, 그리고 지금도 코드를 잘 읽을 수 있을지 모르지만, 관리자로 몇년만 지나면 더 이상 개발자가 아니다.

개발도 잘하고 관리도 잘한다는 것은 착각이다. 관리자가 된 이상 개발에 대해 특히 아키텍처나 구체적인 기술에 대해서 이러쿵저러쿵 참견하는 것은 매우 위험하다. 관리를 잘하는 것이 본인의 업무이고 그것만도 매우 어렵다. 

나는 블로그를 통해서 자신의 회사에서 개발자 경력을 보장하고 있는지 설문 조사를 한적이 있다. 과거 4년동안의 통계를 보면 개발자 경력 보장 제도가 있는 회사는 14%이다. 물론 제도는 있어도 형식적이거나 현실적으로 개발자로 남기 불가능 회사가 많기 때문에 실제 개발자가 경력을 보장받을 수 있는 비율을 훨씬 떨어지게 된다. 한마디로 20년, 30년 개발자로 남아 있기는 낙타가 바늘 구멍 통과하기만큼 어렵다. 

우리나라는 장인정신보다는 관료주의적인 전통이 자리잡고 있어서 전문가보다는 관리자가 더 높은 자리로 인식된다. 그러다 보니 개발자도 분위기에 순응해서 자연스럽게 관리 쪽으로 슬금슬금 넘어가게 된다. 팀장, 부서장이 되어서도 개발에 집중하고 싶어도 주간보고, 월간보고, 업무 분배, 진척확인, 부서간 소통, 보고서 작성, 채용, 사업계획, 평가, 경영자에게 보고 등등 이런 일이 점점 늘어가고 그러다 보면 점점 관리자로 탈바꿈한다. 

개발자가 개발 일에서 떠나는 이유가 또 하나 있다. 개발 프로젝트가 대부분 합리적이지 못하고 무리한 경우가 많아서 몇 년 구르다 보면 야근과 각개전투가 난무하는 전투현장에서 벗어나고 싶게 된다. 개발이 진짜 즐겁고, 개발자로 충분히 대우도 받고 보장을 받을 수 있다면 관리자가 되려고 할까? 개발이 합리적이고 즐겁고 비전이 있어서 개발자들이 남아 있으려고 할 것이다. 

이렇게 고급 개발자들이 떠나게 되면 소프트웨어 생산성은 극도로 낮아진다. 이것은 회사적으로도 국가적으로도 큰 손해다. 뛰어난 개발자들이 관리를 잘 해준다고 해도 소프트웨어 생산성에는 별로 도움이 안된다. 그럼 소프트웨어 개발이 그렇게 관리가 많이 필요한가? 사실 개발팀은 관리할게 별로 없다. 

관리가 많이 필요한 개발팀은 비효율적 팀이라는 것을 단적으로 나타낸다. 단, 프로젝트 관리는 필요하고 전문 프로젝트 관리자가 있을 수 있다. 큰 조직이나 큰 프로젝트는 이보다 더 많은 전문 관리자가 있을 수 있다. 프로젝트 매니저(Project Manager), 리스크 매니저(Risk Manager), 프로덕트 매니저(Product manager), 프로그램 매니저(Program Manager) 등 다양한 전문 업무로 세분화 되기도 한다. 

외국 소프트웨어 회사와 같이 일해본 개발자들은 종종 할아버지 개발들을 만나게 된다. 이들은 50세가 넘어서도 가끔은 60세가 넘어서도 개발을 한다. 코딩도 직접 한다. 

왜 할아버지 개발자가 중요할까? 소프트웨어 개발자는 물론 예외도 일부 있지만 보통 경력이 쌓일수록 실력이 늘어간다. 그래서 회사의 개발자 층은 피라미드 구조를 이룬다. 그런데 가장 뛰어난 늙은 개발자가 관리를 하고 있으면 개발자 피라미드의 중간부터 꼭대기가 아예 없는 사다리꼴 피라미드가 된다. 이런 회사에서 개발 경쟁력을 기대하기는 어렵다.

개발자 본인은 어떨까? 나도 마찬가지지만 대부분의 개발자들은 관리를 극도로 싫어하고 잘하지도 못한다. 개발자들은 개발을 할 때 가장 행복하다. 행복한 일을 하면서 세상을 바꿀 수 있는 개발자라는 직업은 얼마나 멋진 직업인가? 하지만 40, 50세를 넘은 개발자를 찾아보기 어려운 현상은 개발자의 미래를 불투명하게 하고 직업 안정성을 해치고 있다. 

올림픽 금메달을 딴 선수가 20대 중반에 은퇴한 후 직장의 조직에서 불안해하는 것과 별반 다를게 없다. 이런 현상이 개발자 직업 선호도를 낮추는 원인이 되고 있다. 성공한 소프트웨어 회사에서 사장이나 연구소장이 나와서 브리핑하는 것이 아니고 백발의 진짜 개발자가 나와서 개발 이야기를 들려주는 일들이 뉴스에 자주 나와야 한다. 

소프트웨어 개발자의 경력을 보장하는 일은 개인, 회사, 사회적으로 매우 중요하다. 우리나라 소프트웨어 미래의 사활이 걸려있다고 봐도 과언이 아니다. 여기서 가장 중요한 역할은 회사가 해야 한다. 회사에서 개발자의 경력보장이 왜 중요한지 먼저 인식해야 한다.  왜? 거기에 회사의 소프트웨어 개발 경쟁력의 핵심이기 때문이다. 

먼저 개발자와 비 개발자의 트랙을 명확하게 나눠야 한다. 좋은게 좋은 거라고 두루뭉술해서는안된다. 개발자는 철저하게 관리 업무와 잡무에서 보호를 해야 한다. 

앞에서 언급한 보고서 작성, 사업 계획, 예산, 평가 등에 시간을 허비하지 않도록 해줘야 한다. 이런데 10%라도 시간을 빼앗기면 개발 생산성은 50% 이하로 떨어진다. 관리업무와 잡무는 다른 사람을 시키면 된다. 개발자가 10명 이하인 회사도 업무는 나눌 수 있다. 

회사에 롤모델과 멘토도 만들어야 한다. 내가 지금까지 개발자로 남아 있을 수 있던 이유는 롤모델이 있기 때문이다. 개발자는 어떻게 해야 하는지 보고 따라 할 수 있어야 한다. 눈에 보이지도 않는 요정과 같은 모습은 따라 할 수가 없다. 처음에는 어렵겠지만 개발자 롤모델을 키워내야 한다. 개발자에게 모든 것을 원하는 만능 개발자 위주 정책이 없어져야 한다. 한분야의 전문가라도 개발자로 일할 수 있게 해야 한다. 

회사가 준비가 되었다고 다는 아니다. 개발자 개인들도 생각을 바꿔야 한다. 본인의 성향을 보고 진로를 결정해야 한다. 인간의 두뇌 구조는 개발자와 관리자 모두를 잘할 수 있도록 되어 있지 않다. 물론 사회적 제도적 제한이 있어서 본의아닌 선택을 해야 하는 경우도 있지만 본인의 노력도 매우 중요하다. 개발자로 남고 싶으면 끊임없이 새로운 기술을 익혀야 한다. 시야도 넓혀야 한다. 비즈니스도 잘 알아야 한다. 개발자들이 서로 기술을 공유하고 경험을 나누며 같이 성장하려면 피어리뷰가 필수다. 

최고의 개발자들이 관리자나 다른 분야로 떠나고 신참들만 넘쳐나는 개발현장에서 경쟁력을 기대하기는 어렵다. 이런 관료적인 분위기를 소프트웨어 현장에서 없애지 않으면 우리나라 소프트웨어 미래는 없다. 나는 지금도 소프트웨어 경영자를 만나면 개발자 경력 보장이 얼마나 중요한지 역설 한다. 

물론 말 한마디로 30년차 개발자의 모습이 잘 그려지지 않고 실천하기는 어려울 것이다. 개발자 경력보장의 중요성에 대한 인식이 먼저 필요하다. 생각은 바뀌었는데 방법을 모르는 회사는 얼마든지 도와줄 의향이 있다. 그 중요성을 깨달은 것만으로도 이미 50%는 달성한 것이다. 

우리 주변에서도 할아버지, 할머니 개발자를 흔하게 보는 시기가 되면 소프트웨어 개발자들이 행복하게 일하는 세상이 이미 되어 있을 것이다.

SW개발의 8:2 법칙, 그리고 불편한 진실 (개발문화 시리즈4)

이번 개발문화 이야기는 '가내 수공업식 개발문화'다. 즉, 8:2 법칙에 관한 이야기다.  소프트웨어 개발에 있어 시스템과 개발자에 의존하는 비율이 8:2정도가 되어야 한다는 것이다. 

그럼 다른 분야는 어떨까? 예술적일수록 시스템에 의존하는 비율이 낮고, 체계화되고 규모가 클수록 시스템 비율이 높아져서 인력에 대한 유연성은 증가한다. 

소프트웨어 개발에 있어 가장 중요한 요소는 사람이다. 즉, 개발자이다. 그런데 전적으로 개발자에게 의존하는 개발방식은 효율도 떨어지고 리스크도 높다. 특히 소수 인력에 의존하는 방식은 가내수공업 형태를 벗어나지 못한다.

비단 소프트웨어 분야 뿐만이 아니다. 전통 도자기 등 시스템화로 인해 산업화를 못 이루고 맥이 끊겨 사라져버린 분야가 얼마나 많은가? 임진왜란 때 수많은 도공을 납치해간 일본은 도자기 생산을 체계화해서 산업화에 성공했다. 유럽 수출을 시작으로 부를 쌓아서 선진국이 되는 발판을 마련했다. 

회사 규모가 크나 작으나 회사 시스템에 대한 의존도가 매우 낮고 개별 개발자에 의존하는 회사는 개발자들을 효율적으로 활용하지도 못한다. 개발자들이 퇴사하면 큰 타격을 입고 새로운 개발자가 들어와도 효율적으로 일하는데 많은 노력과 시간이 필요하다. 

개발자들이 실력에 맞는 일을 적절하게 골고루 나눠 하지 못하고 한쪽으로 치우치기 일쑤고 고급 개발자들이 소방수역할을 하는 경우가 많다. 회사 규모는 큰데 여전히 가내수공업 형태를 못 벗어난 결과다. 

이런 현상은 회사가 시스템을 효율적으로 갖추지 못해서 벌어진다. 회사 시스템이란 개별 직원과 대비되는 회사의 전반적인 체계를 말한다.소프트웨어 회사 또는 소프트웨어를 개발하고 있는 모든 회사라면 갖춰야 할 시스템은 다음의 4가지가 있다. 

조직, 프로세스, 문화, 기반시스템이다. 

4가지를 잘 갖추고 있다면 특정 개발자에게 의존하는 리스크는 줄고, 개발자들도 더 효율적으로 일할 수 있다. 개발자가 이직을 해도 빠른 시간 안에 적응이 가능한다. 이것은 개발자와 회사 모두에게 이익이 된다. 

이렇게 되려면 소프트웨어 개발이 시스템에 의존하는 비율이 80%정도는 되어야 한다. 나머지 20%는 도저히 시스템으로 커버가 어려운 부분이다. 하지만 대부분의 회사는 8:2가 아니라 2:8 또는 1:9이기 때문에 문제다.

개인 회사이거나 아주 작은 회사도 지속적으로 성장하려면 시스템에 의존하는 비율을 0%에서 시작하여 20%, 50%, 80%로 차츰 높여가야 한다. 

특정 개발자가 빠져 나가면 대부분의 개발 경험과 지식도 함께 빠져나가게 되는 경우 회사는 매우 불안한 상황에 놓인다. 이런 상황을 개발자가 의도적으로 만든 것은 아니다. 회사의 시스템이 워낙 부실하기 때문이다. 

이런 상황이라면 개발자도 워낙 바빠서 그런 상황에 신경 쓸 겨를이 없다보니, 상황은 더욱 악화된다. 단기적으로는 개발자 가치가 올라가서 더 좋을 것 같다. 하지만 장기적으로 보면 이런 환경에서 개발자는 적절한 성장 기회를 얻지 못한다. 아키텍처는 신경 쓰지도 못하고 여기저기 불려다니면서 재미없고 힘든 문제 해결에 주로 투입된다. 개발자 본인에게도 장기적으로는 손해다. 

여기에는 몇 가지 논란이 있을 수 있다. 

첫째, 그럼 개발자는 교체 가능해야 하는 부품인가? 

회사가 시스템을 갖춰야 하는 이유는 개발자를 교체 가능하도록 하기 위한 것이 아니다. 리스크를 줄이고 좀더 효율적으로 개발하기 위해서이다. 개발 중에는 교체가 쉽게 되는 일이 있고, 어려운 일이 있다. 교체가 쉽게 되는 일까지 회사 핵심개발자들의 시간을 많이 빼앗으면 안된다. 회사 핵심 개발자들은 좀더 중요한 일을 해야 한다. 

그러려면 쉬운 일들, 과거에 해놓은 일들을 다른 사람이 할 수 있는 시스템이 필요하다. 이런 상황에서는 핵심 개발자가 퇴사해도 유지보수에 큰 문제가 없다. 하지만 미래의 중요한 프로젝트에 타격을 입기 때문에 개발자들의 가치는 결국 커진다. 물론 아주 작은 회사는 상황이 다르다. 

둘째, 시스템을 아주 잘 갖추고 있는 대기업이 소프트웨어 개발을 더 잘해야 하는 것 아닌가? 

시스템은 회사의 상황과 역량에 알맞게 적절히 갖춰야 한다. 하지만 큰 회사들은 여기서 큰 불균형을 이루는 경우가 많다. 프로세스를 과도하게 복잡하게 하고 사용하기도 힘든 비싼 시스템들을 구축해 사용을 하기는 하지만 효율성 측면에서의 개발문화는 한참 뒤쳐져 있다. 

이런 상황에서 프로세스는 형식적으로 흐르고 비싼 시스템은 장식물에 그치는 경우가 많다. 개발효율로 따지만 주먹구구보다 더 못한 경우도 있지만, 보험의 성격이 있어서 쉽게 포기하지도 못한다. 

소프트웨어 회사가 갖추어야 할 시스템, 즉, 조직, 프로세스, 문화, 기반시스템은 교과서에 딱 정해져 있는 것은 아니다. 회사 규모, 성격 등에 따라서 계속 바뀌어 나가야 한다. 부족해도 문제고 과도해도 안된다. 

개발자 혼자 회사를 하면 혼자서 모든 것을 다해야 하지만, 10명, 30명, 100명으로 늘 때마다 조직 구성이 달라져야 한다. 하지만 많은 회사들이 큰 규모에 비해서 이런 구분 없이 개발자에게 너무 많은 일을 맡기고 있는 경우가 많다. 

보통은 회사가 커지면서, 테스트, 빌드, 시스템관리, 기술지원, 고객지원, 영업지원 등과 같은 일들은 전문조직으로 분리해야 한다. 어려운 점은 적절한 시점에 적절한 규모로 조직을 변화시켜야 한다는 것이다. 

그럼, 프로세스는 어떤가? 여기에도 극과 극이 있다. 명시적인 프로세스가 아예 없거나 너무 복잡한 경우도 많다. 프로세스는 최대한 단순하고 자유도를 높이면서도 핵심적인 요소들은 빠지지 않도록 해야 한다. 이 또한 회사의 역량이 높아감에 따라서 계속 바뀌게 된다. 

많은 회사들이 열악한 개발 문화와 낮은 역량을 비싼 기반시스템이 해결해 줄 것으로 착각한다. 꼭 필요한 기반시스템도 있지만 오히려 해가 되는 경우가 훨씬 더 많다. 소수의 필수 시스템을 제외하고는 적절한 시점에 필요하면 사용하면 된다. 꼭 비싼 시스템이 아니라도 상관없다. 개발자당 연 사용료가 수백, 수천만원하는 종합선물세트 시스템을 구축해 놓고 극히 일부 기능만 쓰는 경우도 많다. 툴로는 결코 문화나 역량을 극복할 수 없다. 

반대 경우도 문제인건  마찬가지다. 필수 기반시스템 하나 없이 주먹구구로 개발하는 회사라면 좋은 오픈소스 기반시스템들이 있으므로 잘 선택한뒤 제대로 가이드를 받아 사용하면 된다. 과도한 경우보다는 개선하기가 쉽다. 

회사 규모에 맞게 안정적이며 꾸준히 역량을 향상하면서 개발을 하려면 개발자에게만 책임을 지울 것이 아니라 회사가 더 많은 것을 갖추고 있어야 한다. 그러기 위해서 꾸준한 투자와 변화는 필수다. 작년과 올해 조직, 프로세스가 똑같고 변화를 위해 투자를 한 것이 하나도 없다면 회사는 책임을 회피하고 있는 것이다.

리스크를 줄이고 개발자가 보다 효율적으로 일할 수 있는 환경을 만들려면 회사가 80%를 갖출 수 있도록 노력해야 한다.

본 칼럼은 ZDNet Korean에 기고한 글입니다.

부실한 공유문화를 지배하는 개발자의 심리 (개발문화 시리즈2)

본 글은 CNet 코리아에 기고한 칼럼입니다. (http://www.cnet.co.kr/view/25939)

본격적으로 소프트웨어 개발 문화에 대해서 얘기해보자.  첫번째는 ‘공유의 문화’다.

 회사마다  차이는 있지만  소프트웨어  회사에서  부실한  공유 문화는  많은  부작용의  원천이다. 여러 사람과 정보를 공유하는 것에 따른 장점은 여러가지다.  다양한 시각을 가진 이들의 의견이 반영되면서 프로젝트 리스크가 감소되는 건 물론 개발자는 자신이 해왔던 과거업무의 속박에서 벗어날 수 있다.

반대로 공유문화가 부실한 회사는 왜곡된 의사결정으로 프로젝트 리스크가 커지고, 아키텍쳐나 제품은 뒤죽박죽이 되는 경우가 많다. 개발자는 자신이 과거부터 해온 일들에 발목이 잡혀 고참이 되도 유지보수에 바쁘고 신참에게 일 시키기도 어렵다. 본인 스스로 고급개발자로 성장하기 어려운 구조라고 하겠다.

개발자가 수백명, 수천명인 회사나 개발자가 10명인 회사나 효율적인 공유없이 각자 일하는 것은 매한가지이다. 개발자가 수천명인 회사내부에서는 팀이 수백개가 아니고 회사가 수백개 있는 것 같은 현상이 벌어지기도 한다. 팀 내부 인원끼리는 서로 내용을 좀 아는데 다른 팀과는 공유가 매우 어렵다. 이를 개선하고자 개발 프로세스를 점점 복잡하게 만들기도 하지만 문화와 균형을 이루지 않은 개발 프로세스는 형식적으로 작동해서 효율도 떨어지고 개발자들에게는 짐이 될 뿐이다.

 겉으로는 공유를 주장하면서도 속으로는 공유를 꺼리는 개발자가 은근히 많다. 개발 내부의 아키텍처 문제나 골치 아픈 이슈들을 숨기고 시한폭탄으로 놔두는 경우도 있고, 바쁘다는 핑계로 또는 다른 사람은 이해하지 못할 정도로 어렵다는 이유를 대고 정보를 꼭 쥐고 있는 경우도 있다.

 전반적으로 공유문화가 부실하게 된 것은 현재 개발자들의 책임은 아니다. 원래 문화라는게 우리의 선조, 선배들이 만들어 놓은 것을  따르면서 아주 약간씩 바뀌는 것이다. 개발문화도 그렇다. 지금까지 선배들이 그런 환경에서 그렇게 일해 왔기 때문에 그런 문화가 형성되었고 우리도 거기에 적응해서 일하고 있는 것이다.

 문화가 바뀌기 어려운 이유는 나 혼자 노력해서는 안되기 때문이다. 다른 사람들은 공유를 위해서 노력하지 않고 나 혼자 애를 쓰면 나만 두배로 손해를 본다. 이는 ‘죄수 딜레마’와 비슷하다.

두 명의 사건 용의자가 체포되어 서로 격리되어 심문을 받으면 서로 간의 의사소통은 불가능하다. 이들은 자백 여부에 따라 다음의 선택이 가능하며 용의자들은 이를 알고 있다.

둘 중 하나가 배신하여 죄를 자백하면 자백한 사람은 즉시 풀어주고 나머지 한 명이 10년을 복역해야 한다.

둘 모두 서로를 배신하여 죄를 자백하면 둘 모두 5년을 복역한다.

둘 모두 죄를 자백하지 않으면 둘 모두 6개월을 복역한다.

 이 경우 서로를 믿고 협동하면 서로 이익이 되지만 대부분 서로 배신을 선택함으로써 나쁜 결과를 초래한다. 공유문화도 마찬가지다. 혼자서 공유한다고 애를 써도 다른 사람이 공유를 하지 않으면 혼자 고생만 하는 것이기 때문에 결국 서로 공유를 하지 않음으로써 서로 손해를 보는 결과를 선택한다는 것이다.

 공유문화는 소프트웨어 개발에 너무 중요하기 때문에 포기할 수는 없다. 그렇다고 노력하지 않고 효율적인 공유문화를 가질 수는 없다. 그냥 흘러가는 대로 놔두면 ‘죄수딜레마’는 어김없이 찾아온다. 개발자 입장에서는 능동적이고 주도적으로 공유문화를 만들어가기 어렵다. 일단은 습관이 되지 않은 상태에서 공유를 하려면 매우 어렵고 혼자만 공유를 잘하면 개발에 있어서 자신에 대한 의존도가 떨어지기 때문에 고민을 하기도 한다.

반대로 공유를 안하면 자신에 대한 의존도는 높아지지만 본인이 한 일에 발목이 잡혀서 성장이 어렵다. 여기까지 생각하는 개발자는 그리 많지 않다. 경영진이나 개발자나 모두 서로를 위해서 필요성을 깨닫고 제도적으로 의식적으로 오랫동안 각고의 노력을 해야 한다. 일단 문화가 자리잡고 나면 의식하지 않아도 저절로 공유를 하게 된다.

그러면 이제부터 많은 사람들이 왜 노력을 해도 공유에 실패를 하는지 2% 차이는 무엇인지 알아보자.

 첫째, 말로 하는 것보다 글로 적는데 익숙해져야 한다.

말로 대화하면서 개발하는 것이 더 효율적이라고 믿는 사람이 많지만 필자는 글로 적는 것이 더 효율적이라고 믿고 있다. 말은 오해도 많고 매번 다른 사람에게 다시 설명해야 하고 시간이 지나면 잊어버린다. 글로 써야 많은 사람에게 공유가 되고 리뷰가 가능하며 도움을 받을 수 있다. 글로 하는 커뮤니케이션은 기본적으로 공유의 준비가 다 되어 있는 것이다.

대화는 가장 비싼 수단이며 휘발성이 강하다. 대화가 아니면 해결하기 어려운 꼭 필요할 때와 대화가 가장 효율적일 때만 사용해야 한다. 글을 쓰는데 익숙하지 않은 개발자는 무조건 장황하게 쓰거나 개발자만 아는 어려운 용어를 사용해서 다른 사람이 이해하기 어렵게 만든다. 또 외계인의 언어처럼 도저히 이해가 안되는 문장구조를 사용하기도 한다.

처음부터 글쓰는 것은 거부하기도 한다. 개발문서는 소설처럼 감동을 줘야 하는 것이 아니기 때문에 잘만 훈련하면 개발자도 충분히 잘 쓸 수 있다. 신입 때부터 문서를 작성하는데 익숙해지면 된다. 그런 기회 없이 이미 고참이 되었다면 지금이라도 시작하면 된다. 깨닫는 것이 어렵지 지금이라도 노력하면 충분히 가능하다.

 둘째, 과도한 프로세스는 오히려 독약이다.

 대기업에서 많이 벌어지는 일인데, 현재 역량이나 문화수준을 훨씬 뛰어넘는 과도한 시스템과 프로세스를 도입해서 강요하곤 한다. 이런 경우 겉으로는 규칙을 지키고 비싼 시스템을 착실히 쓰는 것 같지만 속을 보면 형식적으로 따르고 흉내만 내서 효율은 오히려 더 떨어진다. 이런 일이 벌어지는 이유는 스스로의 역량이나 문화 수준을 과대평가 하기 때문이기도 하다.

제대로 된 CTO의 부재도 한몫 한다. 실전 경험이 부족한 SW 프로세스팀은 밑져야 본전 식으로 프로세스를 복잡하게 만들고 많은 문서를 요구하곤 한다. SW 프로세스팀도 이렇게 밖에 할 수 없는 많은 고충이 있다. 많은 문서 중에서 프로젝트에 실질적으로 필요한 문서는 한두개에 불과한 경우가 대부분이지만 회사에서는 나머지를 쉽게 포기하지 못한다. 이러다 보니 개발자들은 문서 따로 개발 따로 진행을 하고 문서는 개발에 별 도움도 안되고 공유의 목적으로도 의미가 없게 된다. 이런 식으로 문제가 발생하면 프로세스를 더 복잡하게 만드는 악순환이 진행된다.

 해결책은 스스로의 역량과 문화 수준을 정확하게 진단하는 것이다. 그리고 거기에 걸맞는 시스템, 프로세스를 도입해야 한다. 역량에 비하여 프로세스가 단순한 것은 큰 문제가 안되지만 반대의 경우는 더 비효율적이다. 지금처럼 과도한 프로세스를 계속 발전시키면 악순환에서 벗어나지 못하고 결국에는 10배 비효율적으로 개발을 해야 한다. 결코 프로세스로 모든 것을 해결할 수 없다는 것을 명심하자.

 셋째, 개발자 보고 알아서 잘 해보라고 하면 안된다.

 풀뿌리식으로 개선이 될 수 있는 사안이 아니다. 시스템과 프로세스도 필요하고 경영진의 의지와 후원이 절대적이다. 가장 중요한 것은 공유문화를 이끌 리더가 필요하다는 것이다. CTO급의 인물이 있어서 흐지부지 되기 쉬운 공유 문화 개혁에 꾸준한 추진력을 실어줄 수 있어야 한다. 역량 수준에 따라서 여러가지 시스템도 필요하다.

이슈관리시스템, 형상관리시스템, 코드리뷰도구, 위키, 지식관리시스템, 정보포털 등 여러가지가 있지만 모두 필요한 것은 아니다. 그리고 꼭 비싼 제품이 좋은 것은 아니다. 회사의 규모와 개발하는 소프트웨어의 성격에 따라서도 적절한 시스템이 다르다.

전문가의 도움을 받아서 가장 효율적인 프로세스와 시스템을 도입하는 것이 좋다. 프로세스와 시스템이 있다고 다 되는 것은 아니다. 임직원들의 마인드를 바꾸기 위해서 노력도 해야 하고 공유에 익숙하지 않은 직원들에게 효율적인 공유방법을 꾸준히 교육을 시키고 코칭을 해야 한다. 이는 매우 오래 걸리는 일이고 그래서 내부에 공유 문화 리더가 필요한 것이다.

 넷째, 나중에 몰아서 공유하면 실패한다.

 일기를 몰아서 쓰듯이 공유도 몰아서 하면 실패한다. 공유를 위해서 문서를 만들고 시스템에 기록을 하는 것이 목적이 되면 안된다. 이것들은 소프트웨어를 개발하는 과정이고 이렇게 개발을 해야 가장 빨리 효율적으로 개발할 수 있기 때문에 문서를 만들고 공유를 하는 것이다.

공유를 위해서 숙제를 하듯이 정리를 해서 시스템에 지식을 올리고 공유하는 것보다 매 순간 필요한 것들을 즉시 등록하는 것이 좋다. 공유할 것, 물어 볼 것, 의논해야 할 것들을 일단 적당한 시스템에 올려 놓고 진행을 하는 것이다. 그러면 자연스럽게 과정이 공유가 된다. 즉, 공유는 개발의 과정이고 일부이지 산출물, 부산물들이 아니다.

공유를 위해서 산출물을 만들어야 한다고 생각하는 순간 공유는 실패하고 산출물도 제대로 만들어 질리가 만무하다. 이렇게 만들어진 문서는 나중에 유지보수 시에도 활용도가 뚝 떨어진다. 공유목적으로도 실패한 것이다. 개발과정이 자연스러운 공유의 과정이 되도록 해야 한다.

 다섯째, 모든 사람이 다 너무 바쁘면 안된다.

 모든 개발자가 호떡집에 불난 것 같이 바쁜 회사가 많다. 가끔은 신입 개발자는 한가하고 고참들이 더 바쁜 경우도 있다. 이런 회사는 대부분 공유에 실패한다. 불 끄느라고 정신이 없어서 나머지는 눈에 들어오지도 않는다. 시니어 엔지니어가 될수록 시야도 넓어지고 생각도 많이 하고 여기저기 관여도 많이 해야 하기 때문에 정신없이 바쁘면 안된다.

손이 바쁘면 뇌는 느려진다. 코딩하느라고 바쁜 신입 개발자는 많아도 큰 문제가 없지만 고참들은 창의적인 생각도 많이 하고 타부서의 프로젝트도 파악하고 회사의 비즈니스도 알아야 하기 때문에 충분한 시간적 여유가 있어야 한다.고참 개발자는 공유를 가장 많이 하기도 하고 공유의 수혜자이기도 하다. 모든 사람이 모든 정보를 다 알 수는 없다. 자신의 레벨에서 공유하고 알아야 할 정보가 다르다. 고참 개발자의 손이 한가해지려면 이전에 공유를 잘 해왔어야 한다. 즉, 공유의 선순환이 필요하다.

 여섯째, 보안보다 공유가 우선이다.

 소프트웨어는 설계도면이 핵심이 아니다. 구성원들의 지식 공동체가 핵심이며 문서, 시스템, 경험, 지식의 복합체가 소프트웨어 회사 기술의 실체이다. 대부분의 SW회사는 HW분야에서 설계도면 빼돌리 듯 기술을 빼돌릴 수가 없다. 우리나라에서는 빈약한 공유문화 속에서 소수의 개발자가 거의 모든 정보를 독점하기 때문에 종종 기술을 빼돌리는 일이 벌어진다. 이런 상황에서는 보안을 아무리 강조해도 기술이 새나가는 것을 막을 수는 없다.

드물게 보안이 더 중요한 SW회사도 있기는 하지만 극소수에 불과하다. 보안에 대한 과도한 우려 때문에 공유를 너무 불편하게 하는 회사가 의외로 많다. 보안이 별 이슈도 아닌 회사도 공유에 거부감이 있는 직원의 주장에 넘어가서 공유를 포기한 회사도 많다. 훌륭한 오픈소스가 판치는 마당에 소프트웨어 회사에서는 숨길 것이 그렇게 많지 않다. 특수한 분야의 몇몇 회사를 제외하고는 모든 직원에게 모든 정보를 오픈해도 별 문제가 안된다. 보안을 과도하게 강조하여 공유에 제약을 가하기 시작하면 공유는 반쪽짜리가 되어서 효율은 엄청나게 떨어지게 된다.

 공유문화라는 것이 단어는 다들 잘 알고 있으면서 잘 안되는 대표적인 개발문화이다. 경험해보지 않으면 무엇을, 어떻게, 얼마나 자세히, 누구에게 공유하는데 잘 감이 잡히지 않는다. 위 여섯가지 가이드도 실전 적용을 해보고 자세히 들어가보면 아리송한 부분들이 많을 것이다. 그래도 시작이 반이라고 일단 시작을 해보자. 너무 큰 욕심은 경계하자.

회사에서는 꾸준히 투자를 해야 하며 처음에는 제도적으로 시작을 했다가 점점 습관화를 해 나가야 한다. 오래 걸리는 일이니 너무 근시안적으로 보지 말고 꾸준히 노력해야 한다.

전지전능한 슈퍼 개발자의 역설

필자는 여러 소프트웨어 회사에서 많은 개발자를 만난다. 그러면 보통 회사에 한두명씩 전지전능한 슈퍼 개발자가 있는 것을 보게 된다.

이들은 코딩, 설계, 분석, 테스트, 기획, 고객 전화응대, 고객 지원, 프로젝트 관리, 일반관리, 전략 수립 등 엄청나게 많은 일을 한다. 직책은 대부분 팀장이다.

여러분의 회사에도 이런 개발자가 한두명씩은 있을 것이다. 이들이 여러분의 롤모델인가? “나도 그런 전지전능한 개발자가 되어야지”라는 다짐을 하는가? 아니면 혹시 여러분이 이런 전지전능한 개발자인가?

이렇게 많은 일을 하는 개발자가 One man company에만 있는 것이 아니다. 개발자가 수백명이 넘는 회사에서도 드물지 않게 만날 수 있다.

이런 회사에서는 모든 길이 로마로 통하듯이 모든 기술적인 이슈도 이 전지전능한 개발자를 통해야 해결이 된다. 이 전지전능한 개발자가 모든 기술과 정보를 꽤 뚫고 있어서 문제가 발생하면 즉시 해결해주고 회사는 그럭저럭 굴러간다. 이 개발자가 나가면 회사는 망할 것만 같다.

이런 현상이 좋아보이는 사람도 있을지 몰라도 회사는 인력적으로 큰 리스크를 안고 있는 것이고 뛰어난 개발자를 가장 가치 있는 일에 제대로 사용하지 못하는 손해를 입고 있는 것이다. 전지전능한 개발자는 본인이 선택을 해서 그런 위치가 된 것은 아니다.

회사가 성장과정에서 적당한 때 조직을 전문화하고 변화를 꾀했어야 하는데 그냥 달려만 오다보니 능력이 좋은 개발자가 이거 저거 다 떠 안게 되면서 이런 현상이 벌어지게 되었다. 좀더 잘할 수 있는 분야에 집중했다면 본인 역량 면으로도, 미래 가치면으로도 훨씬 좋은 결과를 가져왔겠지만, 지금은 회사의 맥가이버가 된 상황에 만족할 수 밖에 없다.

다른 회사로 가면 지금의 가치는 대부분 사라지고 만다. 개발자 본인에게도 안타까운 상황이다.

어떤 사람도 서로 완전히 다른 Skill set들을 필요로 하는 일들을 동시에 다 잘 수행해 낸다는 것은 불가능하다. 아주 작은 회사에서나 그렇게 하는 것이다. 이렇게 모든 일을 다하는 전지전능한 개발자는 그 모든 업무를 다 잘 못하고 있다고 봐야 한다. 모든 일을 잘한다는 것은 애초에 불가능하다. 특히 중요한 일은 주 업무인 개발을 할 시간이 확 줄어 든다는 것이다.

대부분의 이들은 예전에는 뛰어난 개발자였다. 하지만, 개발 이외 일들을 하나씩 떠 맡으면서 각 분야의 일들의 전문성이 점점 떨어지게 됐다. 그리고 각 일의 Switching cost가 만만치가 않다. 톰 디마르코는 몰입에는 15분의 시간이 필요하다고 했다. 전화한번만 받아도 15분은 그냥 추가로 까먹는거다.

심지어는 그런 개발자에게 테스트, 고객 응대, 기술 지원까지 하라는 것은 100원주고 20원짜리 일을 시키는 것과 같다. 비효율적일 뿐만 아니라 기획 같은 일은 전문성이 부족하여 제대로 수행하지도 못한다.

이런 슈퍼 개발자는 다른 소프트웨어 회사에 가면 가치가 확 떨어진다. 분야가 달라지면 Domain Knowledge 관련 경쟁력을 잃고, 개발 실력도 경력에 걸맞지 않게 떨어지고 어느 것 하나 특출난게 없게 된다. 관리자가 되어야 하나 고민이 많다. 그래서 회사에 꼭 붙어 있으려고 하고, 정치를 하면서 세력을 키우고, 회사의 개혁이나 변화를 반대하고, 골치덩어리 영웅이 되는 경우도 있다.

회사는 이들에 대한 의존도가 커져서 리스크를 감당할 수 없는 수준에 이르게 된다. 이들이 등돌리면 회사는 휘청거린다.

이것이 개발자 탓일까? 아니면 회사 탓일까? 회사 탓이다. 회사는 개발자가 실력을 발휘할 수 있도록 여건을 조성해주고 훈련도 시켜줘야한다. 그런데 개발자가 맨땅에서 북치고 장구치고 다 하고, 회사에서는 이를 방치하다보니 이렇게 되는 것이다. 하지만 많은 경영자들은 개발자가 잘 하니 그냥 그렇게 개발자가 다 해야 하는 것으로 아는 경우가 매우 많다.

그럼 어떻게 해야 할까?

개발자가 개발에 전념할 수 있도록 항상 여건을 조성해줘야 한다. 회사가 아주 작아서 어쩔 수 없이 개발자가 여러가지 일을 겸해서 하고 있다고 하더라도 회사가 조금만 커져도 개발자의 일에서 개발업무가 아닌 일을 떼어낼 수 있도록 준비를 해야 한다.

조직이 조금 커지면 테스터를 뽑고, 기술지원인력을 보강하는 것이 좋다.

개발자 10명이 이거 저거 모든 일을 다하는 것보다. 개발자 7명에 테스터2명, 기술지원 인력 1명인 조직이 더 낫다. 개발자가 개발에 더 집중할 수 있고 개발자 10명이서 하는 일보다 더 많은 일을 할 수 있다. 물론 조직과 더불어 프로세스, 기반시스템, 개발문화도 뒷받침이 되어야 하지만 이는 기본으로 생각하자.

이렇게 조직이 분리되고 개발자가 개발에 전념을 할 수 있어야 개발이 좀더 체계적으로 진행된다. 다른 조직의 인력과 협업을 하기 위해 필요한 최소한의 문서도 만들어야 하고 프로세스도 자연스럽게 필요하게 된다. 커뮤니케이션을 위한 기반시스템도 잘 활용하게 된다.

조직이 더 커지면 분리해야 하는 역할이 점점 많아진다. 즉 조직이 세분화 된다. 이는 회사 규모에 따라서 다르니 이 일이 개발자가 해야 하는 일인지 잘 생각해보고 결정하면 된다.

여기서 개발자의 업무를 모두 나열할 수는 없지만 회사에서 개발자가 개발에 집중할 수 있도록 노력하는 일은 대단히 중요하다. 개발자가 잘 해낸다고 그냥 방치하면 안된다. 개발자는 개발을 잘할 때 회사의 보물이 되는 것이다. 다른 일들은 여건이 되는 대로 다른 전문가에게 맡기도록 하자.

이 글은 Tech it에 기고한 글입니다.

요구사항이 계속 바뀌기 때문에 스펙을 적을 수 없다.

소프트웨어 개발 프로젝트에서 스펙을 제대로 적지 않는 회사들에게 그 이유를 들어보면 여러가지가 있다.

1. 프로젝트 기간이 너무 짧아서 스펙을 적을 시간이 없다.

2. 프로젝트가 너무 복잡해서 적어야 할 것이 너무 많아서 적을 수 없다.

3. 요구사항을 계속 바꿔서 스펙을 적을 수가 없다.

위의 어떠한 이유도 적절한 이유가 되지는 않는다. 오직 한가지 이유가 될 수 있다면 다음과 같은 것이 있을 수 있다.

"우리는 분석역량이 떨어져서 스펙을 적을려고 해도 제대로 적을 수 없다. 그래서 그냥 개발한다."

위 1,2,3번의 이유 때문에라도 스펙을 적어야 하는 것이다.

이중에서 3번 "요구사항이 계속 바뀌기 때문에 스펙을 적을 수 없다"에 대해서 얘기를 해보고자 한다.

99%의 소프트웨어 프로젝트는 분석 기간은 당연하고 설계, 구현 중에도 요구사항이 계속 바뀐다. 단지 프로젝트마다 바뀌는 정도의 차이가 있을 뿐이다.

스펙을 제대로 적었다는 전제하에 스펙을 결정한 후에도 요구사항이 계속 바뀌는 이유는 다음과 같은 것들이 있다.

1. 시장 상황의 변경

2. 경쟁 업체의 신제품 출시

3. 기술 환경의 변화

4. 미처 파악하지 못한 비즈니스 요구사항 발견

5. 예상치 못한 개발 상의 난관 봉착

6. 경영진의 변덕

7. 영업, 마케팅 부서의 끊임 없는 요구

이런 저런 이유로 요구사항 변경 요구는 계속 되기 마련이다. 스펙을 제대로 적어 놓지 않으면 이러현 변경 요구가 관리되지 않는다. 또한, 변경 프로세스를 적용하면 좀더 합리적인 변경 관리가 가능한다.

프로세스라고 하니까 뭔가 매우 부담스러워하고 특히, 영업과 마케팅 부서는 싫어하는 경향이 있다. 과거에는 코딩 중이라고 하더라도 친한 개발팀장에게 추가로 요구를 하면 잘 들어 줬는데 변경 프로세스를 밟으라고 하면 싫어하기 마련이다. 하지만 중요한 프로젝트의 일정과 품질에 영향을 줄 수 있는 결정에 큰 Risk를 안으면서 그냥 결정할 수는 없다.

변경 프로세스의 핵심은 "변경 영향 평가"이다. 이것도 그렇게 거창한 것은 아니다. 새로운 요구사항이 프로젝트에 어떠한 영향을 주는지 정량화하는 것이다. 일정이 더 필요할 수도 있고, 오히려 줄어들수도 있다.(드물지만) 또한 기술적인 위험이 증가할 수도 있다. 짧게는 10분, 길면 몇시간 걸리는 일이다. 스펙을 제대로 적어 놓지 않았다면 요구사항 변경으로 인해 아키텍처에 어떠한 영향을 주는지 파악하기 어렵고, 일정에 미치는 영향도 판단하기 어렵다. 그래서 스펙이 필요한 것이다.

변경 영향 평가가 되었다면 이러한 영향이 있는데도 불구하고 새로운 요구사항을 반영해야 하는지 투명하게 판단을 해야 한다. 어떤 요구사항은 정말 간단한 것 같은데 프로젝트에 큰 악영향을 주는 것도 있고, 커보이는 요구사항이 프로젝트에 문제 없이 포함될 수 있는 것도 있다. 즉, 요구사항 변경이 합리적으로 결정될 수 있다.

변경이 쉽지 않다는 것을 잘 알기에 스펙을 제대로 적고 철저히 리뷰하는 문화가 더욱 견고해지는 것이다.

이러한 프로젝스와 문화가 정착된다면 개발자들도 터무니없는 기능 추가 요청에 일정은 절대 안바꿔주는 비합리적인 요구는 줄어들게 된다. 스펙을 제대로 적고 변경을 관리하는 것이 회사에도 이익이지만 개발자에게는 더욱 좋은 문화임에도 많은 개발자들이 거부하는 경향이 있다. 이는 개발자들 탓이 아니다. 그동안 개발환경이 근거없는 일정 강요와 야간에 내몰리다보니 하루라도 빨리 코딩을 해야 한다는 생각에 내몰린 것이다.

또한, 무리한 요구사항 변경 요청에 "아키텍처를 너무 많이 바꿔야 한다". "몇달이 더 필요하다"라고 하면 개발자들은 항상 안된다고 주장한다고 치부를 해버리곤 한다. 그래서 무리한 변경 요구에 개발자들이 주로 약자가 되곤 한다.

스펙이 잘 작성된다면 일정, 리스크, 비용 등 모든 것에 근거가 생기고 합리적으로 결정할 가능성이 훨씬 높아지게 된다. 

스펙은 프로젝트가 끝날 때까지 계속 바뀌게 되어 있다. 그래서 스펙은 계속 업데이트가 되어야 한다. 하지만 합리적으로 변경 관리가 되어야 한다.

유지보수의 거미줄에 걸린 고참들

고참은 유지보수를 하고 신참들이 신제품을 개발하는 모습을 어렵지 않게 볼 수 있다.

고참들이 경험도 많고 신제품을 만드는데 더 적임이지만 그럴 수 없는 이유가 있다.

기존 제품의 유지보수에서 도저히 빠져나갈 수 없는 것이 그 한 이유이다. 간단한 업그레이드가 아니고 완전히 새로운 제품을 만들려고 하는 이유도 기존 제품이 유지보수가 너무 복잡하고 기능을 추가하거나 수정하기에 아키텍처가 더이상 감당이 안되기 때문인 경우가 많기 때문이다.

현 제품의 유지보수는 당장 회사의 생존이 달린 문제이기 때문에 신제품이 개발되기 전까지는 고참들이 버텨줘야 한다. 문제는 자칫하면 신제품이 기존 제품보다 훨씬 못하는 경우가 종종 벌어지는 것이다.

이렇게 고참들이 유지보수에서 빠져 나오지 못하는 이유는 무엇인가?

첫째, 유지보수 문서의 부실이다.

고참들은 수시로 기존 제품의 유지보수에서 빠져나오기 위해 온갖 인수인계 노력을 한다. 하지만 쉽지 않고 성공적인 인수인계가 잘 이루어지지 않는다. 인수인계를 위해서 작심을 하고 유지보수에 관련된 모든 내용을 문서화하고 교육도 한다. 하지만 후배들은 그 문서를 보고 유지보수를 잘 해내지 못한다.

개발할 때 개발을 위해서 작성한 문서가 아니고 차후에 유지보수를 위해서 만드는 문서는 제대로 작성하기가 어렵다. 수많은 내용이 빠져도 알아챌 수가 없고 정성껏 작성하기도 어렵다. 문서는 개발 중에 그 때가 아니면 다시 작성하는 것은 거의 불가능하다. 그런데 이미 그 때를 놓쳤기 때문에 유지보수를 위한 제대로 된 문서를 다시 만들어 내기란 몇배 어려운 일이 되어 버렸다.

둘째, History의 부재이다.

또, 그동안 유지보수 History가 잘 기록되어 있으면 다행이지만 그렇지 않은 경우 유지보수 인수인계가 어려워진다. Mantis, Jira, Redmine 등의 이슈관리시스템에 유지보수를 포함한 모든 개발 History가 기록되어야 한다. 이슈관리시스템을 쓴다고 해도 100% 사용하지 않으면 안된다. 소스코드를 한줄이라도 고친 내용은 모두 이슈관리시스템에 기록이 남아 있어야 한다.

셋째, 복잡한 Architecture이다.

첫번째 버전에서 시장의 요구에 따라서 기능이 덕지덕지 붙다보면 어쩔 수 없이 컴포넌트의 구분도 없고 인터페이스가 보통 복잡해지는 것이 아니다. 오랫동안 유지보수를 해온 개발자가 아니면 이를 제대로 파악하기가 어렵다. 그러다보니  고참이 계속 유지보수를 하는 것이다.

이 또한 처음 개발 당시부터 미래의 비즈니스 전략을 고려하여 컴포넌트를 잘 나누어서 깨끗하게 개발을 해야 한다. 그렇지 않으면 아무리 유지보수를 위한 문서를 잘 작성하여도 어려운 상황이 된다.

이런 상황이 계속되다보면 기존에 열심히 일하던 고참들도 즐겁게 일하지 못하고 보람도 떨어지면서 이탈이 많이 일어난다. 

가끔은 이렇게 소수의 핵심인력에 회사가 전적으로 의지하는 시스템을 본인들이 원하기도 한다. 하지만 이런 현상은 나중에 본인들의 발목도 잡고 회사의 큰 리스크가 된다.

해결책은 원인의 반대이다.

개발 당시 스펙/설계 문서를 제대로 작성하고 컴포넌트를 잘 나눠서 개발을 하고 소스코드관리시스템과 이슈관리시스템을 사용해서 모든 기록을 남기고 투명하게 개발하면 되는 것이다. 그렇게 되면 유지보수 단계가 아니라 구현단계에서도 다른 사람들이 얼마든지 도와줄 수 있고 분석이나 설계만 하고 빠져나와 다른 프로젝트를 수행할 수도 있다.

내가 지금 퇴사를 하면 회사에 무슨 일이 벌어지는지 한번 생각해보자. 당장 지금 진행 중인 프로젝트나 유지보수가 문제 없이 진행이 되면 회사에 가장 필요한 인재이다. 그렇지 않고 당장 큰 문제가 되면 당장은 꼭 필요하지만 동시에 회사의 리스크이므로 고민스럽지 않을 수 없다.