진보 개발자? 보수 개발자?

오랜만에 다시 글을 쓰는 기념으로 오늘은 좀 가벼운 주제를 다뤄볼까 합니다.
개발자들에게도 진보/보수가 나뉜다는 사실 들어보셨나요?
이번 기회에 스스로의 성향과 주변 팀원들의 성향을 한번 파악해보시는 것도 재밌을 것 같습니다.

여기서 진보 보수는 정치의 진보 보수와는 전혀 관계 없고 소스코드를 대하는 자세에 가깝습니다.
이 진보/보수 급진/온건 네가지 개념은 어디 근거있는 이야기는 아니고
제가 개인적으로 예전부터 생각하던 생각이니 그냥 재미로 보시면 되겠습니다.😉
가벼운 마음으로 보면서 나는 진보 개발자인지 보수 개발자인지 한번 구별해보시기 바랍니다.

진보와 보수를 나누는 기준

기존의 코드, 프로젝트, 아키텍처를 개선/수정하려는 성향이 강하면 진보에 가깝고
반대로 기존의 코드, 프로젝트, 아키텍처를 보존/유지하려는 성향이 강하면 보수에 가깝다고 보시면 됩니다.

이렇게 설명하면 당연히 진보가 좋은거 아닌가?🤔 하는 생각이 드실 수 있습니다.
그러나 `리팩토링이 오히려 새로운 버그를 만들거나 기존의 기능이 제대로 동작하지 않는 등 항상 성공적인 결과를 도출하지는 않습니다.
그런 점을 감안해 본다면 리팩토링은 신중하게 접근해야할 필요가 있습니다.

진보의 문제라고 한다면 리팩토링으로 인한 비용과 리스크를 과소평가한다는 점이 있습니다.
리팩토링이 중요하다고 해서 그 비용이 언제나 값싸지는 않습니다.
예를 들면 리팩토링으로 인한 새로운 버그 발생 리스크와 리팩토링 기간동안 새로운 기능을 개발하지 못하는 기회비용,
또 리팩토링 이후 QA 등을 포함한 테스트비용 등 리팩토링 역시도 비용과 리스크가 따를 수 밖에 없습니다.

심지어는 정작 새로운 기능을 추가하는 것이 아니기 때문에 설령 앞으로의 생산성이 좋아졌다 하더라도
비개발자 동료나 경영진의 입장에서는 굳이 안해도 될 일에 몰두하는 것으로 보일 수 있습니다.

반대로 보수 개발자는 어떤의미로는 SW개발자와는 본질적으로 모순 되는 존재입니다.
다들 아시겠지만 SW의 의미 자체가 고치기 어려운 HardWare의 반대인 유연하고 수정이 쉬운 SoftWare 입니다.
이미 SW의 본질이 ‘수정과 유지보수’라는 의미를 내포하고 있는데 정작 이 수정대신 보존에 더 의미를 둔다면
본질적으로 모순된다고도 할 수 있는 셈입니다.

제가 존경하는 개발자분이 해주신 말씀에 따르면 레거시란

‘어제 짜도 문제가 있다면 그게 레거시’

라고 합니다.

진보는 이 문장을 보고 ‘어제 작성한 코드도 레거시다’ 라고 받아들이고
보수는 이 문장을 보고 ‘문제만 없으면 레거시는 없다’ 라고 받아들입니다.

급진과 온건을 나누는 기준

급진과 온건은 딱 이거다! 라고 정의하기가 쉽지 않은데요,
팀워크, 일정, 비용, 팀컬처 등 개발 외적인 요소에 영향을 적게 받으면 급진, 많이 받으면 온건이라고 정의합니다.
쉽게말해 팀원과의 갈등을 피하기 위해 진보/보수적 성향을 타협한다면 온건에 가깝고
갈등이나 비용 등 다른 요건을 인지했다 하더라도 진보/보수적 성향을 타협하지 않고 밀어붙일 수록 급진에 가깝습니다.

경험상, 보통 온건이신 분들은 팀워크에 중점을 두고
급진이신 분들은 엔지니어로서의 자긍심을 두는 경향이 있는 것 같습니다.
코드를 보고 있는데 보존/수정하는 것이 스스로 용서가 안된다던가 팀원과 이런 문제로 갈등을 겪어보셨다면 급진일 확률이 높습니다.

개발자를 진보/보수 개발자로 만드는 것

한 사람도 프로젝트에 따라 진보/보수적 성향이 다를 수 있습니다.
아무래도 오래되고 레거시가 큰 프로젝트 일수록 아무래도 개발자를 보수적으로 접근하게 만들고
새로운 프로젝트거나 규모가 작은 프로젝트 일수록 진보적으로 만드는 경향이 있습니다.
(물론 케이스 바이 케이스이고, 예외는 언제나 있기 마련입니다.)

팀 문화의 영향을 받기도 하는데
좀 수평적인 분위기일수록 진보성향의 개발자가 많을 확률이 높아지는 부분도 있습니다.
반대로 수평적인 요즘 스타트업이 진보 성향의 개발자를 선호하기도 합니다.

또 재밌는 점은 연차에 따른 차이도 있는데
연차가 높아질수록 보수적으로 변하는 부분도 어느정도 있지만
보통 신입(0년차)->초급(1~2년차)로 넘어가는 단계나 주니어(3년미만)에서 중니어(3~5년차) 개발자로 넘어가는 과정처럼
계단식으로 한단계씩 성장하는 과정에서 갑자기 진보적으로 변하는 경우가 종종 있습니다.
솔직히 저도 비슷한 시기에 진보적으로 변했던 경험이 있습니다.
아마 스스로 성장하는 과정에서 겪는 사춘기와 같은 자연스러운 형상이라고 생각합니다.

다만 이런 것이 나쁜 것은 아니지만 이런 과정에서 만약 디자인패턴 책을 처음 읽고 너무 감명깊게 읽었다던가,
개발자 컨퍼런스에서 너무 획기적인 영감을 얻어서 갑작스럽게 리팩토링을 시작하신다면 조금 신중하게 결정하시기를 권합니다.
책을 안읽은 사람보다 한권만 읽은 사람이 무섭다고들 하지요…. 😂😂😂

가장 중요한 것은 책임감과 테스트

한국말은 언제나 마지막이 중요하드시 오늘의 글도 지금부터가 핵심입니다.
이 글에서 가장 중요한 것은 리팩토링을 하느냐 vs 레거시를 보존하느냐 의 싸움이 아니라
어찌됐든 그 소스코드를 보고 있는 당신이 (설령 작성자가 아닐지라도) 그 코드의 책임을 져야한다는 것입니다.

제 인생에서 가장 경멸하던 개발자는 급진/진보에 가까운 성향이었는데
코드를 몽땅 뜯어고쳐놓고 제대로된 테스트조차 돌려보지 않아서 수많은 버그와 함께 롤백한 사례를 본 적이 있습니다.
그렇다고 보수개발자가 문제가 없냐고 하면 또 그건 아닌게 보수개발자들은 보통 퇴사하고 한두달 뒤에 지뢰가 터지곤 합니다.
결국 레거시가 들고있는 문제들을 후임자들에게 떠넘기게 되는 결과로 이어질 수도 있습니다.

그럼 잘 책임진다는 것은 어떤 것을 의미할까요?

저는 꼼꼼한 테스트와 그것을 테스트코드 혹은 문서로 잘 남기는 것을 의미한다고 생각합니다.

제가 개인적으로 존경하던 개발자중에 급진/진보와 급진/보수 개발자가 모두 있었는데
두분의 공통점은 결국 그분들이 담당한 프로젝트에서 문제가 발생하지 않았다는 점이고
기존 레거시의 문제를 꼼꼼한 테스트코드 혹은 체계화되고 상세한 문서화를 통해 다음 후임자가 그대로 물려받지 않도록 했다는 점입니다.

결론적으로 리팩토링이냐 보존이냐를 두고 어느게 우선인지 따지는 대신
테스트 코드는 잘 작성되어 있는지, 문서화는 꼼꼼히 잘 되어있는지 한번 씩 검토해보시기 바랍니다.