기술적 보수주의를 조금은 경계해야 하는 이유.
기술적 보수주의를 조금은 경계해야 하는 이유.
Python은 33년 된 언어입니다. JavaScript는 29년 된 언어입니다. 프론트엔드 패러다임을 바꾸었다고 평가받는 React 라이브러리조차 11년 되었습니다.
현대 소프트웨어를 이끌고 있는 기술은 대부분 오래된 기술입니다. 오래된 만큼 수정을 거듭해 안정적이고, 안정적인 만큼 널리 쓰이게 됩니다.
소프트웨어 개발자는 흔히 진보적인 사람들이라 생각합니다. 신 기술이 나오면 바로바로 적용해 보고 열광하는 모습을 떠올리게 되죠. 그러나 새로운 기술은 사이드 프로젝트에만 국한될 뿐 실제 서비스에 사용되기까지는 오랜 시간이 걸리거나 도태됩니다.
그래서인지 소프트웨어 업계는 기술적 보수주의를 자주 택하곤 합니다. 그렇다면 언제 기술적 보수주의의 관점을 택해야 할까요. 제 답은 아래와 같습니다.
- 비즈니스 가치를 우선시할때.
- 시니어 레벨을 채용하고자 할 때.
- 새로운 기능을 추가함에 있어서 문제가 생기지 않을 때.
그러나 이는 지나치게 비즈니스적인 시야를 낳을 수 있습니다. 소프트웨어가 비즈니스 가치를 극대화하는 건 분명 좋은 방향이지만 기술적 보수주의가 극단화될 경우 편의주의로 치닫게 됩니다.
최근 회사 업무를 하며 데이터베이스 테이블을 본 후 충격 먹었던 경험이 있습니다. 데이터베이스 정규화 원칙을 무시한 채로 개발되어 있었는데요. 데이터 컬럼이 JSON Text 형식으로 저장되어 있었고 프론트엔드 단에서 파싱 후 데이터를 불러오는 상태여서 버그가 생기기 쉬운 구조였습니다.
소프트웨어는 유기체에 가깝습니다. 자주 수정해주어야 하고 주기적인 리팩토링이 필요합니다. 그래야 새로운 기능이 추가되어도 버그가 발생할 확률이 줄고 생산적인 코드를 유지할 수 있기 때문입니다. 장기적으로는 비즈니스 가치를 극대화하는 데에도 도움이 되고요.
극단적인 보수주의는 편의주의를 낳는다고 생각합니다. 편의주의대로 개발한 소프트웨어는 언젠가 구멍이 생기기 마련이고 그때 생긴 구멍도 편의주의대로 처리하면서 문제는 점점 심화되죠.
좋은 코드에 대한 고민은 좋은 아키텍처, 기술을 공부하게 만들고 때때로 비즈니스에 적용되기도 합니다.
예를 들어 저희 회사는 PHP를 백그라운드로 Vue로 개발되어 있습니다. 최근에 개발자분께서 새로 리팩토링한 결과입니다. 과거 PHP로 작성된 프론트엔드&백엔드를 Vue와 Java/Spring으로 마이그레이션 해, 안정적인 구조로 동작하는 모습을 보여주었습니다. 당연하게도 새롭게 앱을 개발함에 있어 백엔드 API와 통신할 수 있으니 개발 기간이 단축되었죠.
어쩌면 미래를 생각하고 현재를 수정하는 일이 지금 무엇보다 중요한지도 모르겠습니다. 당시에 API를 분리하지 않았다면 지금 일이 가중되었을 테니까요.