악순환 vs. 선순환

지난번 글 (이 바닥을 못 벗어 난다.)의 추가 글입니다.

회사가 Risk가 큼에도 불구하고 Domain 지식이 점점 더 매달릴 수 밖에 없는 이유와 선순환을 하려면 어떻게 해야 하는지 좀더 현실감 있는 예를 보여주려고 합니다.

회사마다 상황이 모두 다르기 때문에 각자의 상황과 1:1로 다 일치하지는 않지만 참고하실 수는 있을 겁니다.

그럼 악순환과 선순환에 대해서 알아보죠.

Domain 지식에 점점 매달리게 되는 악순환의 고리

• 주먹구구식 개발
• 개발자에 의존한 코딩 중심의 개발 주도
• 없거나 빈약한 개발 프로세스 및 개발 문서
• 회사의 지식은 개발자 머리 속에 보관
• 개발자 간 지식의 공유가 어려움
• 후배 개발자들에게 지식 전달이 잘 안됨
• 프로젝트가 커질수록 협업이 점점 어려워짐
• 점점 더 경험 많은 개발자에 의존하게 됨
• 경험 많은 개발자는 계속 더 바빠짐
• 경험 많은 개발자들도 체계적인 개발은 꿈도 못 꾸고 매일 밑바닥 개발에 매달림
• 개발자들이 Domain 지식은 점점 늘어가는데 소프트웨어 공학지식은 잘 늘지 않음
• 회사에서는 신규 직원을 뽑아도 같이 협업이 잘 안되므로, 동일 Domain의 경험이 많은 개발자를 선호하게 됨
• 경험 많은 개발자들이 퇴사를 해서 회사가 큰 타격을 입기도 함
• 또 고참 개발자들이 퇴사할 까봐 전전긍긍하게 됨
• 회사에서는 개발자들의 머리 속에 있는 지식을 공유하고 체계적으로 개발하고 싶으나 방법을 모름
• 이에 대한 개혁을 해보려고 해도 번번히 고참 개발자들의 방해로 무산됨
• 점점 더 경험 많고 Domain 지식이 풍부한 개발자들에게 의존하게 됨
• 규모 있는 개발을 못하고 인원수에 의존한 개발을 하게 됨
• 회사는 성장을 못하고 정체하게 됨
• 고참 개발자들은 성장을 못하고 매일 밑바닥 코딩과 문제 해결에 매달리게 됨
• 또 주먹구구식, 가내 수공업식 개발을 반복하게 됨

프로세스 중심의 선순환의 고리

• 회사가 소프트웨어 개발에 필요한 적절한 프로세스와 인프라스트럭처 시스템을 갖추고 있다.
• 개발자들은 프로세스 중심으로 개발이 되도록 잘 훈련 되어 있다.
• 프로젝트 진행 시 꼭 필요한 스펙 문서와 설계 문서를 적절하게 만든다.
• 문서와 코드에 대해서 적절히 Peer review가 이루어져서 지식의 전달이 잘 되고 결함이 사전에 제거된다.
• 고참 개발자들은 코딩 보다는 주로 아키텍처와 비즈니스에 대해서 고민하고 해결한다.
• 잘 작성된 스펙 문서와 설계 문서를 보고 후배 개발자들이 코딩하고 테스트 팀이 테스트를 진행한다.
• 고참 개발자들은 오랜 개발 경력으로 Domain 지식도 풍부하지만 소프트웨어 공학 지식 및 경험도 풍부하다.
• 후배 개발자들은 Domain 지식은 부족하지만, 설계 문서를 보고 인프라스트럭처 시스템을 활용해서 프로세스에 따라 개발하는데 별 문제가 없다.
• 신규 개발자를 뽑아도 교육이 용이하고 바로 실무에 투입하기가 쉽다.
• 고참 개발자들이 퇴사를 해도 상당히 많은 지식이 문서화 되고 이미 후배들에게 전파가 되어 있으므로 회사의 타격이 상대적으로 적다.
• 퇴사한 고참 개발자들은 이직이 용이하고 더 높은 연봉으로 타 회사로 옮길 수 있다.
• 회사에서는 Domain 지식이 너무 매달리지 않고, 실제로 Software 공학 지식이 뛰어나고 Software 개발 자체를 잘하는 인재를 선호하게 된다.
• 회사가 성장하고 개발 규모가 커져도 문제 없이 대응할 수 있다.

그럼 악순환에서 선순환으로 바뀌는 방법에 대해서 의문을 가질 수 밖에 없습니다.

이는 참 어려운 숙제입니다.

운동을 안한다. -> 몸이 무거워진다. -> 운동을 더 안한다. -> 몸이 더 무거워진다.

이런 악순환의 고리를 끝는 것은 무엇을 까요? 일단 운동을 시작한다? 99%는 실패할 겁니다.

운동은 습관도 안들어 있고, 제대로 운동하는 방법도 모르고, 또 귀찮아지면 언제든지 포기하고, 잘못된 운동 방법으로 다칠 수도 있습니다. 그러면 운동에 대한 나쁜 기억만 쌓이고 다음번에는 더욱더 운동을 시도하지 않게 될 겁니다.

그래서 악순환의 고리를 끝는 것을 쉽게 얘기를 할 수 있어도 현실적으로 가능한 방법을 제시하는 것은 쉽지 않습니다. 물론 가장 적절한 방법도 회사마다 다릅니다.

하지만, 악순환의 고리를 끝는 방법 중에서 필수 요소는 경영자의 의지입니다. 경영자가 이러한 상황을 전혀 이해 못하고 있거나 의지가 없다면 그냥 계속 악순환의 고리를 돌면서 영업이나 잘하는 수 밖에 없습니다.

개발자들이 으쌰으쌰해서 점진적으로 개혁을 해보려는 시도는 매우 더딜뿐만 아니라 다양한 도전 및 방해로 무산될 가능성이 큽니다. 그래도 그런 과정에서 개발자들이 본인 스스로 공부는 될 수 있겠네요.

경영자가 의지만 있다면, 조직, 시스템, 프로세스적인 다양한 측면에서 효과적이고 적절한 개혁을 시도하여 회사를 바꿔나가서 점점 선순환의 고리로 옮겨 갈 수 있습니다. 

이 바닥을 못 벗어난다.

우리나라 소프트웨어 개발자들은 자신이 처음부터 일해온 바닥을 못 벗어나는 경향이 있습니다.

처음에 게임회사에서 일을 시작한 개발자는 계속 게임회사에서 일하고, 금융회사, 보안회사, 장비회사, SI회사 등 쉽게 그 바닥을 못 벗어나곤 합니다. 

이러다 보니 개발자가 이직 시 선택의 폭이 좁아지고, 분야가 조금만 바뀌어도 자신의 Value가 확 줄어드는 현상이 일어나곤 합니다.이런 일이 비일비재하게 일어나는 것을 보면 개발자의 전문성이란 어디에 있는 것인지 궁금하지 않을 수 없습니다.

금융에 대한 전문지식을 많이 가지고 있고, 게임에 대한 많은 지식을 가지고 있는 것을 개발자의 전문성이라고 볼 수도 있습니다. 또 그러한 Domain 지식이 없으면 개발을 할 수 없다고 단정적으로 얘기를 하는 개발자도 많습니다.

소프트웨어 엔지니어가 소프트웨어를 개발하기 위해서는 크게 2가지의 지식이 필요합니다.

그 중 하나는 이미 앞에서 언급한 Domain 지식입니다.

그리고 또 하나는 Software Engineering 지식입니다.

Domain 지식은 개발 분야가 바뀌면 거의 쓸모가 없는 산업 지식이고, Software Engineering 지식은 개발 분야가 바뀌어도 항상 사용되는 지식들입니다.

Domain 지식은 너무 광범위해서 나열을 할 수는 없습니다.

하지만 Software Engineering 지식은 무엇인지 설명할 수 있습니다.

요구분석, 설계, 구현, 테스트, 소스코드 관리, 버그 관리, 프로세스 등 소프트웨어를 개발하기 위한 일련의 지식들입니다.

물론 소프트웨어를 개발하기 위해서는 Domain 지식과 Software Engineering 지식 모두가 필요합니다. 하지만 흔히 접하는 현상을 보면 개발자들이 점점 Domain 지식이 치중하는 경향이 있습니다. Software Engineering에 대한 전문성을 떨어진 상태에서 Domain 지식만 점점 늘어가니 당장 일은 잘하고 있는 것 같아도, 동료나 후배들과 협업이 잘 안되고, 프로젝트 규모가 조금만 커져도 문제가 있고, 이직 시에는 심각한 가치 하락이 발생합니다.

그럼 어떻게 해야 할까요? 소프트웨어를 개발하면서 자연스럽게 얻게 되는 Domain 지식에만 의존해서는 안됩니다. Software Engineering 지식을 꾸준히 발전시켜서 소프트웨어 전문가가 될 수 있도록 해야 합니다. Software Engineering에 능통한 소프트웨어 전문가가 된다면, 어느 소프트웨어 회사를 가더라도, 여전히 전문가로서 높은 가치를 가지고 개발을 할 수 있습니다. 새로운 분야로 이직을 하더라도 Domain 지식은 일을 하는 과정에서 차츰 배워 나갈 수 있습니다. 

그리고 Domain 지식에 능통한 개발자에게만 의존해서 개발이 진행되는 소프트웨어 회사는 매우 큰 리스크를 안고 있는 겁니다. 그런 개발자가 한 명만 퇴사를 해도 회사는 큰 위험에 봉착합니다.  

결국, 회사를 위해서도, 개발자들을 위해서도 개발 개발자들의 머리 속에 들어 있는 Domain지식에 의존하기보다는 적절한 개발 프로세스 및 시스템을 기반으로 개발을 해야 합니다.