시스템 안정화와 개발자 채용에 대한 고민

시장을 돌아다니면서 "자주 관찰되는 현상"이다.

안 그런 기업도 있지만, 그런 기업들도 아주 많다.

옳고 그름을 가리려는게 아니라,

현상을 기록하기 위해 정리한다.

 

 

01.시스템의 딜레마 Dilemma of System

법칙1 : "모든 시스템은 시간이 지날수록 더러워진다."

 

개발자는 시스템을 깨끗하게 유지하려고 한다.

당연하다. 

깨끗한 시스템이 문제파악하기도 좋고,

장애처리하기에도 빠르다.

 

물론 이럴 때도 있다.

 

"더 이상 안됩니다. 이건 완전히 갈아엎어야 해요."

"이건 이제 수명을 다했어요."

 

음, CEO는 고민이 된다.

새로 만들것인가, 고쳐서 쓸 것인가?

새로 만들면 돈이 많이 들것 같고,

고쳐서 쓰면 돈이 적게 들것 같다.

 

그런데 궁금하다.

시스템을 새로 만들면 진짜 괜찮은걸까?

돈이 한두푼 들어가는 것 아닌데 말이다.

 

그리고, 사실...

시스템을 직접 만지는 개발자도,

기술전략을 짜는 CTO도 궁금해한다.

 

"정말 괜찮아지는걸까?"

 

왜 그런진 모르겠지만,

지난 경험을 뒤적거려보면 이런 결과가 많았다.

 

"사실 시스템을 새로 만들어도 크게 좋아지는 건 없다."

 

물론 더러운 시스템을 그대로 쓴다면 유지보수하기는 괴롭다.

새로 만들면 분명 장애처리가 좀 더 쉬워진다.

작업효율도 분명히 올라간다.

긍정효과가 전혀 없진 않다.

 

하지만, 얼마 지나지 않아 대부분 금방 더러워진다.

왜 그럴까.

궁금했다.

음...

관찰해보면 코드만의 문제가 아니었다.

 

02. 시스템이 복잡해지는 이유

시스템이 복잡해지는 이유는 다음과 같다.

2.1. 시스템 설계사상은 대부분 다음 개발자로 계승되지 않는다.

항상 동일수준의 사람이 채용되지 않는다.

인수인계는 보통 덜 숙련된 개발자에게로 이어진다.

왜냐하면 그 업무의 담당자가 아니기 때문이다.

비숙련자가 숙련자의 코드를 따라갈 순 없다.

 

새로운 사람은 생각이 다르다.

시스템에 대한 이해수준도 다르다.

그래서 설계사상은 계승되지 않는다. 

다른 형태의 코드가 추가되면서 시스템은 급격히 더 복잡해진다.

 

2.2. 사업환경의 변화는 종종 엔지니어의 예측을 넘어선다.

사업환경의 변화는 "룰"을 기반으로 하지 않는다.

사업, 생존은 변칙영역이기 때문이다.

 

"룰기반 엔진"이라는 건 "은행" 같은 분야에만 적용된다.

규제중심으로 사업변화가 적은 분야다.

 

빡빡한 룰엔진을 만들고 나머지를 예외처리하면,

1년쯤 지난후엔 예외 70%, 룰 30%인 엔진을 보게 된다.

 

룰이 걸림돌로 작용함으로써 유지보수 난이도가 올라간다.

매우 올라간다. 매우 난감해진다.

 

2.3. 사업이 안되는 동안 시스템은 종종 방치되기도 한다.

시스템을 오픈했는데 생각보다 사업이 잘 되지 않는다.

그래서 신규기능이 추가되지 않고 그냥 방치된다.

 

5년쯤 지난 후 소스를 뜯어보면

오래된 기술구조가 지저분하게 느껴지기도 한다.

 

5년전 방식으로 코드를 더해보지만,

생각만큼 깨끗하게 기능을 추가할 수 없다.

 

"방치되는 것도 더러워지는 것이다."

 

2.4. 새로 온 개발자가 이전 개발자만큼 훌륭하지 않다.

구관이 명관이다.

이건 개발자의 세계에도 통한다.

 

법칙2 : "새로 온 개발자는 이전의 개발자만큼 훌륭하지 않다."
           (새로 온 개발자 New-comer의 법칙)

 

더 훌륭한 사람을 고용할 수도 있다.

하지만, 기존 개발자가 도망간 거라면 새 사람도 도망갈 확률이 높다.

그 사람을 도망가게 한 문제가 해결되지 않았기 때문이다.

 

CEO가 문제를 올바로 인식하지 못다면 

대개 더 못한 친구가 그 자리를 대체하게 된다.

 

그리고, 이전의 것들을 무턱대고 비판한다.

그렇게 자신에게로 권력을 모은다.

실력이 없기 때문이다.

 

훌륭한 친구는 더 좋은 자리로 가지,

남들이 도망간 자리에는 오지 않는다.

 

훌륭한 개발자를 데려오려면,

CEO가 먼저 공부해야 한다.

 

끝.