고객이 전문가

우리나라의 소프트웨어 환경의 문제점 중 하나가 고객이 잘 모른다는 것이다.

예를 들어 공공 SI 프로젝트의 경우 발주처인 공공기관의 담당자가 SI회사의 개발자들보다 업무를 잘 모르는 경우가 종종 있다. 공무원들은 몇년만다 한번씩 자리를 옮기기 때문에 자신의 업무를 빠삭하게 알지 못하고 SI회사에 많이 의지하게 된다. SI회사에서는 해당 분야의 업무만 오랫동안 개발해온 개발자들이 있어서 현업 담당자보다 더 잘 알곤 한다. 외국의 경우 몇십년씩 한자리에서 공무원이 최고의 전문가가 되는 경우와는 사뭇 다르다.

그래서 공공프로젝트를 진행할 때 SI회사가 많이 주도를 한다. 심지어는 발주처에서 해야 할 일도 다 SI회사가 해주곤 한다. 어떻게 보면 SI회사에 좋기도 하지만 문제도 많다. 요구사항 분석 때 충분한 정보를 주지 않아 나중에 요구사항이 많이 바뀌기가 일쑤이고 그로 인해서 프로젝트에서 손해도 많이 난다.

비단 공공분야만이 아니다. 소프트웨어 선진국에서는 기업이 소프트웨어 외주를 줄 때 해당 기업에서 충분히 분석, 설계 역량이 있고 스펙을 제대로 작성해서 외주를 주곤한다. 즉, 직접 개발할 역량도 충분히 있는데 비용이나 시간 상 외주를 주는 것이다.

그런데 우리나라에서 외주를 주는 형태를 보면 고객이 잘 모르기 때문에 대충 외주를 주고 개발 업체가 이거저거 정말 알아서 다 해줘야 할 때가 많다. 그러다 보니 계약도 불분명하고 다툼도 많다. 법정까지 가는 다툼도 많이 발생하지만 엉성한 계약서를 가지고 누구의 자잘못인지 따지기도 어렵다.

개발업체에서 스펙을 제대로 작성하기 위해서 고객 인터뷰를 하고 요구사항 분석을 해도 협조가 잘 되지 않는다. 정확한 인터뷰 대상 선정도 쉽지 않다. 업체에서 나름대로 최대한 노력해서 스펙을 작성해도 고객이 스펙을 충분히 검토해서 확인을 해주는 일도 드물다. 

일단 고객이 스펙을 충분히 잘 검토할 수 있는 실력이 부족한 경우가 많다. 그래서 스펙을 봐도 잘 모르기 때문에 잘 보지 않으려고 한다. 또, 개발해 놓으면 언제든지 바꿔달라고 하면 되는 것으로 착각을 해서 개발 전에 스펙을 잘 보지 않아도 된다고 생각한다. 심지어는 스펙을 잘 검토해서 확인을 해주면 나중에 바꿔달라고 못할지도 모른다는 생각도 한다.

이런 비전문가적인 고객들은 개발업체를 엄청 괴롭히지만 프로젝트에도 긍정적이지 않다. 이런 환경에서 좋은 아키텍처의 소프트웨어가 나오기 어렵다. 개발업체도 제대로 개발하고 싶겠지만 그냥 어떻게 검수만 나도 된다는 식으로 개발하기 쉽다. 서로에게 모두 손해가 되는 것이다.

외주, 즉 아웃소싱이 제대로 되려면 고객이 전문가가 되어야 하는 것이다.

회의록 작성 문화를 보면...

회의를 하면서 회의록을 작성하는 문화를 가지고 있는 회사들이 매우 많다. 회의록을 아예 작성하지 않는 회사도 있고, 작성을 해도 전혀 뒷처리가 안되는 회사도 있다.

회의는 회사의 가장 중요한 업무 중 하나이며 중요한 결정을 하고 부서간의 의견을 조정하고 업무를 나누고 서로 협업을 하기 위한 수단이다. 그런데 회의는 회의대로 진행하고 후속 조치를 제대로 하지 않는다면 반쪽 짜리 회의가 된다. 하지만 많은 회사들이 아직 회의 문화와 회의록 작성 문화가 아직 부족한 것이 현실이다.

아래 회의록에 관련된 질문 중에 우리 회사는 어디쯤 와 있을까? 

• 회의록은 따로 작성하지 않는다. 그냥 알아서 처리한다.
• 회의 참석자 중에 우연히 꼼꼼한 사람이 있으면 작성하기도 한다. 하지만 대대분 작성하지 않는다.
• 회의 시작전에 회의록 작성자를 꼭 지정하여 회의록을 작성한다.
• 회의록을 녹취록처럼 작성한다. 
• 회의록에는 회의에서 논의된 주요한 내용을 기록하고 결정사항, Action Item을 별도로 정리한다.
• 회의록에 결정 사항이 있기는 하지만 언제까지 누가 해야 하는지 적지는 않는다.
• Action item은 누가 언제까지 해야하는지 구체적으로 명시한다.
• 회의가 끝난 후 결정사항과 Action item을 참석자들에게 다시 한번 상기시킨다.
• 회의록은 회의 종류 후 바로 보내지 않고 별도로 정리해서 다음날 또는 그후에 보낸다.
• 회의록은 회의 참석자들에게만 Email로 배포한다.
• 회의록을 회의 참석자 외에도 관련자 모두에게 배포한다.
• 회의록의 Action item은 별로도 챙기지 않는다. 담당자가 알아서 진행한다.
• 회의록은 시스템에 저장이 되어서 철저하게 추적하고 챙긴다.

질문은 이것 저것 섞여 있지만 그 속에 어느 정도 힌트가 있다.

회의록에는 결정사항, Action item이 담당자와 due date까지 포함해서 적혀야 하며 회의가 끝나자마자 관련자 모두에게 배포를 해야하며 Action item은 잘 추적이 되어야 한다.

이렇게 하기 위해서 그냥 Email로 배포를 하는 것도 좋은 방법이지만 이슈관리시스템을 쓰는 것도 좋다.

일단 이슈관리시스템에 등록이 되면 보통 전직원에게 공유가 되고 Action item은 하나씩 sub-task나 이슈의 형태로 등록을 해 놓으면 철저하게 추적이되고 누락되는 일이 없다. 대충 처리하지 않고 뭉개고 싶은 일들도 이슈관리시스템에 등록된 이상 무시할 수 없는 일이 된다. 이슈관리시스템을 이용하는 것은 회의록을 잘 활용하기 위한 하나의 Tip이고 중요한 것은 회의와 회의록 문화이다.

이는 다른 개발 문화들보다 좀더 쉽게 정착할 수 있는 일이니 아직 부족하다고 생각하면 시도를 해보자.

Technical Career Path를 보장하는 방법

그 동안 개발자 경력에 대한 글들을 여러 건 작성했다. 많은 독자들이 문제 인식에 공감을 했지만 여전히 해결책은 쉽지 않다. 그래서 여기 방법을 제시하고자 한다. 소프트웨어 회사들이 어떻게 하면 Technical Career Path를 보장할 수 있을까?

첫째, 경영자 의식의 변화이다.

경영자가 개발자의 경력을 보장하는 것이 회사에 얼마나 큰 이득이 되는지 깨닫지 못한다면 개발자가 꾸준히 개발만 할 수 있도록 노력할 리가 없다.

축구는 체력이 떨어지는 30대 중후반이면 더 이상 선수로 뛰기 어렵지만, 소프트웨어 개발자는 체력과 상관없이 평생 시간이 흐를수록 점점 더 뛰어난 개발자로 일할 수 있다. 이렇게 뛰어난 선수로 일할 수 있는 개발자들을 관리나 하라고 낭비하지 않고 계속 선수로 뛸 수 있도록 회사에서 지원을 해야 한다는 것을 경영자들이 절실히 깨달아야 한다.

아직은 경영자들이 이같은 인식이 부족하거나 막연히 개념만 인지하고 현실은 다르게 행동을 하는데 주위에서 설득하려는 노력이 필요하다. 이 칼럼들을 공유해도 좋고 외국의 사례를 보여주는 한 방법일 것이다. 이는 회사를 위하고 개발자도 위하는 길이다.

둘째, 개발 조직의 변화이다.

개발 조직은 워낙 회사마다 서로 달라서 하나의 형태를 지켜야 한다고 말할 수는 없다. 하지만 개발 조직이 전문 개발자들이 제대로 일할 수 있는 구조가 되어야 한다. 우선 개발팀장, 개발리더, 매니저 등 구분 없이 마구 섞여서 일하는 것은 지양해야 한다.

조직이 아주 작아서 혼자 다해야 하는 경우를 제외하고는 관리자와 개발자는 구분을 하자. 팀이 커져서 관리 일이 점점 많아지면 더 이상 개발자가 개발을 겸해서 하기는 어렵다. 전문 관리자를 두는 것이 좋고, 프로젝트에서도 프로젝트매니저를 따로 두는 것이 좋다. 개발자는 개발에 전념할 때 가장 높은 성과를 낸다. 개발 외의 일은 관리자나 프로젝트매니저가 맡아야 한다.

셋째, 공정한 평가이다.

소프트웨어 개발자로 공정한 평가를 받기 매우 어렵다. 그래서 평가 대상보다는 평가자가 되려고 하는 경향이 있다. 공정한 평가가 대단히 어려운 일이지만 나름대로 객관적인 근거에 의한 평가를 위해서 노력해야 한다. 개발자가 어찌 해볼 수 없는 이유로 평가에서 불이익을 받는다면 개발을 계속 하기가 싫어질 것이다. 소스코드관리시스템과 이슈관리시스템의 기록을 활용하고 개발 일정 준수 등의 지표를 활용하는 것도 좋은 방법이다.

넷째, 적절한 대우이다.

많은 회사에서 팀장이 되고 관리자가 되어야 더 높은 연봉을 받을 수 있다. 그 주된 이유는 관리와 개발의 분리가 안되어 있어서 구분이 안되기 때문이다. 관리를 하지 않고 평생 개발을 한다고 해서 연봉이나 대우에서 불이익을 받아서는 안된다. 오히려 동일 경력에서 개발자가 관리자보다 더 높은 연봉을 받는 것이 맞을 수 있다. 관리자나 개발자나 자신의 전문분야에서 회사에 기여하는 만큼의 적절한 대우를 받아야 한다.

다섯째, Career Path 제공이다.

회사에서 다양한 Career Path를 제공해야 한다. 개발자는 이들 중에서 적절한 시점에 선택을 할 수 있어야 한다. 계속 개발자로 경력을 발전시켜 나갈 수도 있고 관리자나 프로젝트매니저가 될 수도 있다. 또는 다른 일을 맡을 수도 있다. 한번 개발자 경력에서 벗어나면 다시 돌아오기 어려우므로 신중하게 결정해야 한다.

여섯째, 개발문화, 개발 프로세스, 기반시스템이다.

너무 광범위한 내용이라서 다 설명하기는 어렵다. 개발자가 제대로 일하기 위해서는 공유를 기반으로 한 투명한 개발문화와 적절한 개발 프로세스가 필요하다. 또한 개발에 필요한 기반시스템을 제대로 갖추고 있어야 한다. 아무것도 갖추지 못한 회사에서는 개발자가 아무리 개발을 오래해도 가치를 높이기가 어렵다.

일곱째, 롤모델이 필요하다.

롤모델이 있다면 개발자들에게 확실한 길을 보여줄 수 있다. 하지만 무늬만 개발자가 아닌 진짜 개발자를 외부에서 영입하기는 쉽지 않다. 내부에서라도 개발자들의 롤모델을 만들도록 노력해 보자. 회사에서 가장 뛰어난 개발자들에게 관리 일은 덜어내고 개발에 전념할 수 있도록 해주고 회사의 제도가 이를 뒷받침하도록 하자. 회사의 개발 조직이 더욱 탄탄해 질 것이다.

개발자 경력 보장 문화는 개발자들의 인생이 달린 일이다. 아직은 척박하지만 우리가 하나씩 바꿔나가야 한다. 가장 어려운 일은 경영자를 설득하고 깨닫게 하는 일이다. 고양이 목에 방울달기 같은 일이지만 어렵다면 주변이나 전문가의 도움도 받아보자. 지금은 3D 취급하는 사람들도 있는 소프트웨어 개발이 좀더 좋은 대접을 받기 위해서는 개발자 경력 보장이 중요한 단초가 될 것이다.

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

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

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

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

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

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

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

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

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

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

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

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

1. 시장 상황의 변경

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

3. 기술 환경의 변화

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

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

6. 경영진의 변덕

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

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

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

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

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

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

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

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

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

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

주먹구구식 개발이 통하는 이유

우리나라의 많은 소프트웨어 회사들은 주먹구구식 개발에 대한 환상이 있다.

특히, 첫번째 시스템을 주먹구구식으로 개발을 해서 성공했는데 지금은 좀더 체계를 갖췄는데 더 개발이 잘 안된다면 과거 진짜 주먹구구식으로 개발할 때를 그리워하고 그 때로 돌아가고 싶어 한다.

여기 이와 관련된 과거 글이 있다. 

2012/07/26 - [소프트웨어이야기] - 옛날에는 개발을 더 잘했는데

주먹구구식으로 개발을 하다가 현재 체계를 갖추려고 노력하고 있다면 아직은 불완전할 뿐더러 반쯤은 주먹구구인 것이다. 그럼 주먹구구식 개발은 어떤 것인지 정의를 내려보자. 크게 5가지로 설명할 수 있다.

첫째, 스펙/설계 없이 개발을 하는 것이다. 또는 기능명세서, 시방서 등의 문서에 기능만 정리하여 개발하는 것이다. 이 방법은 프로젝트 전체 범위를 알 수 없을 뿐더러 좋은 아키텍처를 만들 수도 없고, 개발자들이 효과적으로 일을 나눠서 개발할 수도 없으며 프로젝트 진척상황을 거의 파악할 수 없다. 일정 지연은 일상이고 그야말로 끝나봐야 아는 것이다.

둘째, SVN, Git 등의 소스코드관리시스템과 Jira, Mantis, Redmine 등의 이슈관리시스템 없이 개발하는 것이다. 둘중 하나라도 사용하지 않으면 심각한 문제이다. 일단 쓰기만 하더라도 다행이지만 제대로 쓰는 것은 정말 어렵다. 대부분은 10% 정도의 기능밖에 사용하지 못하지만, 100% 기능을 활용해야 한다.

셋째, 혼자 북치고 장구치고 다하는 것이다. 일을 전문적으로 나눠서 하는 것이 아니고, 혼자서 기획, 분석, 설계, 코딩, 테스트, 빌드 등등 다 하는 것이고 이런 개발자가 여럿이고 서로 중복되서 일을 하기도 한다. 첫째에서도 언급했듯이 스펙이 제대로 작성되어야 일을 효과적으로 나눌 수 있는데 스펙이 없거나 부실하면 이런 현상이 벌어진다. 또, 회사의 조직이 소프트웨어 개발에 알맞게 효과적으로 구성되어 있지 않아도 이런 일이 벌어진다. 소프트웨어는 전문가들이 협업하여 개발하는 것이다.

넷째, 프로세스 없이 대충 개발하는 것이다. 흔히들 프로세스는 개발을 더 느리게 만든다고 주장하곤 한다. 그러면서 회사에서 프로세스를 만들려고 하면 반대 주장을 펼친다. 과거에 개발하던 방법을 서로 암묵적으로 알고 있다가 대충 개발을 하고 서로 이심전심으로 문제를 해결해 나간다.

다섯째, 리뷰, 공유 없이 개발하는 것이다. 가끔은 대충 기능목록 작성해서 마케팅이나 영업, 경영진과 리뷰를 하기도 하지만 제대로 된 리뷰는 아니다. 개발자를 제외하고는 지금 어떤 제품을 만드는지 정확하게 파악이 안된다. 심지어는 개발자들도 잘 모른다. 다 만들어봐야 어떤 제품을 만들었는지 알게 된다. 그러니 만들기 전에는 무슨 문제가 발생할지 몰라서 만드는 도중에 수많은 문제가 발생하고 재작업은 수시로 이루어 진다. 심지어는 80%쯤 만들었다가 아키텍처가 잘못된 것을 발견하고 다 버리고 다시 만들기도 한다.

정도의 차이는 있을 수 있다. 다섯가지 중에서 하나 이상이면 아직 주먹구구식 개발에서 완전히 벗어난 것이 아니다. 스스로도 주먹구구식으로 개발을 하고 있는지 평가를 해보자.

2008/10/29 - [소프트웨어이야기] - 소프트웨어 회사의 개발 역량 평가표

그럼에도 불구하고 주먹구구식 개발이 여전히 통하는 이유는 무엇일까?

첫째, Software의 크기가 아주 작다.

빌딩은 제대로 된 분석/설계 없이, 프로세스 없이 만드는 것은 불가능하다.

하지만 개집은 그런 것 필요 없다. 대충 만들어도 문제 없이 만들 수 있다. 한 사람이 머리 속으로 모든 것을 설계해서 만들 수 있는 정도의 규모라면 주먹구구식 방법도 훌륭한 방법이다.

둘째, 이직률이 극도로 낮다.

한번 개발을 해 놓으면 개발자들이 절대로 퇴사를 하지 않고 끝까지 책임져준다. 

셋째, 회사 규모가 작다.

개발자도 몇 명 안되서 서로 너무 잘 알고 모든 이슈가 더 구두로도 공유가 되고 급한 이슈는 자리에서 바로 일어나서 공유가 되고 논의할 수 있다. 가족적인 분위기에서 주먹구구식 방법이 훌륭하게 작동한다.

넷째, 소프트웨어 업그레이드가 없다.

한번 개발해 놓은 시스템이 업그레이드가 필요 없는 경우이다. 어떻게 든 첫번째 개발을 해 놓으면 문제가 없다.

그럼, 주먹구구식 개발이 앞으로도 계속 통할까?

회사가 잘되면 회사는 커지게 되어 있다. 개발자 수는 많이 늘게 되고 더 이상 자리에서 일어나 뒤로 돌아도 모든 개발자의 얼굴을 볼 수 없게 된다. 과거처럼 공유가 그렇게 잘 되지 않는다.

개발자들이 영원히 이직하지 않고 직원으로 있기를 바란다면 너무 큰 욕심이다. 개발자들은 언젠가는 이직을 하게 마련이고, 개발자들이 이직을 해도 개발은 잘 돌아가도록 되어 있어야 한다. 주먹구구식으로 계속 개발을 하게 된다면 아무리 가족적인 분위기라고 하더라도 직원이 Risk 요인이 된다.

Software 회사의 경영자라면 지금 대충 잘 굴러가는 것 같다고 해서 방심하면 안된다. 회사가 잘 되면 회사는 커지고 직원도 늘고 더 복잡해질 것이다. 문제를 모르고 방심하다가 문제가 터지고 나면 터진 댐을 막으려고 하는 것처럼 어렵다. 항상 미리 준비를 해야 하는 것이다.

물론, 처음부터 제대로 하는 것이 가장 빨리 개발하는 방법이고 좋지만 그것을 깨닫기는 매우 어렵다. 대부분은 문제가 터진 후에 우왕좌왕 한다. 주먹구구식 개발이 지금은 통할지도 모른다. 하지만 곧 주먹구구식 개발이 문제가 되는 상황이 올 것이고 이미 문제가 되고 있다면 너무 늦지 않았기만 바랄 뿐이다. 늦었다고 생각할 때가 가장 빠른 때이다.

소프트웨어 회사에서의 관리란?

소프트웨어 회사가 경쟁력을 가지려면 전통적인 관리와는 좀 다른 관리 방법이 필요하다.

첫째, 상하관계 탈피이다.

전통적으로 관리자는 윗사람이고 팀원들은 관리자의 지시를 따르고 관리자가 거의 모든 것의 결정권을 가지고 있다. 하지만 소프트웨어 회사에서 관리자는 기술적인 결정을 할 수 없다. 개발자 출신이라고 기술적인 결정도 하려 하는 경우도 있지만, 기술적인 결정은 개발자의 몫이다. 그리고 전사적인 중요한 기술적인 결정은 CTO나 회사의 최고 개발자들이 하는 것이다.

관리자는 위에서 지시하는 사람이 아니고 개발자들이 개발에 매진할 수 있도록 회의, 보고서 작성, 보고, 의견 조정 등 힘든 일을 도와주는 역할을 해야 한다. 물론 경험이 많은 사람들이 잘할 수 있는 일이기 때문에 평균 개발자보다는 나이가 더 많을 수는 있다. 그렇다고 하더라도 상하 관계보다는 개발자를 지원하고 경영자를 보좌하는 역할로서의 관리자가 더 필요하다.

둘째, 투명한 관리이다.

소프트웨어는 인류가 만들어낸 가장 복잡한 지식산업이다. 너무 복잡하고 이슈가 많기 때문에 모든 이슈를 시스템에 저장해서 관리하고 모두 투명하게 오픈하지 않으면 감당하기 어렵다. 버그, 기능, 프로젝트 일정, 개발 현황 등 모든 것은 한눈에 볼 수 있도록 해야 한다. 내용을 채우는 것은 개발자 및 전직원이지만 관리자는 이런 모든 정보가 빠짐없이 시스템화 되어서 제대로 공유가 되는지 확인을 해야 한다. 

경영자도 이런 시스템을 통해서 개발현황을 훤히 볼 수 있어야 하고 관리자는 시스템을 이용하여 보고서를 작성하여 시간을 절약할 수 있다.

셋째, 자율이다.

소프트웨어 개발은 관리자가 하나하나 시켜서 진행하기에는 너무 복잡하다. 그렇게는 일이 진행되지 않는다. 큰 그림에서는 PM이나 관리자가 파악하고 도와주지만 자세한 일은 개발자 스스로가 해야 할 일을 정하고 일정을 조정하고 해나가야 한다. 이렇게 일을 진행하더라도 혼자서 알아서 진행하는 것이 아니고 모두 이슈관리시스템에 기록을 하고 진행해야 한다.

개발자들이 윗사람이 일을 시키기만 기다리고 있다면 개발 프로젝트는 효율적으로 진행되지 않는다. 이슈관리시스템은 이런 자율적인 개발진행에 큰 도움을 준다. 일단 이슈가 등록되면 전사 이슈가 되어서 수많은 사람들의 의견을 더해서 이슈의 우선순위가 정해지고 진행 상황을 훤히 파악할 수 있다.

물론 전통적인 관리자의 모습에서 하루아침에 바뀌기는 어렵다. 하지만 소프트웨어 개발문화와 충돌이 있는 부분은 엄연히 존재하며 조금씩 바꿔나가야 할 부분이 있다. 큰형님처럼 보살펴주고 모든 것을 무한 책임지며 진행하고 도전적인 일정을 달성하기 위해서 무조건 쪼는 모습에서 조금씩 바꿔보자.

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

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

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

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

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

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

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

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

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

둘째, History의 부재이다.

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

셋째, 복잡한 Architecture이다.

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

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

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

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

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

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

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