기술의 딜레마

예전에 WebFlux 도입 여부를 두고 꽤 긴 논쟁을 했었다. 나의 주장은 WebFlux 도입이 필요한지 따져봐야겠지만 아직 대부분의 팀원이 잘 모르기 때문에 WebFlux만 볼 게 아니라 관련된 사전 지식의 수준을 먼저 높인 뒤에 도입해야 할 것 같다 였고, 상대방의 주장은 일단 적용하고 시행착오를 거치면 되지 않겠느냐는 입장이었다.

 

나 역시도 관심을 많이 두고 있고 출시 이후부터 개인적으로 꾸준히 샘플프로젝트도 만들어보고 스터디를 해왔기 때문에 성향상 평소 같았으면 일단 적용하는 쪽에 손을 들어줬을 테지만 이 상황은 좀 다르다고 생각했다. 기존에 작성하던 개발 패러다임을 완전히 바꿔야 하는 수준이라고 생각했고, 충분히 학습하지 않은 상태에서 도입하는 것은 독이 될 수도 있겠다고 보았다. 실제도 가이드 문서에도 대부분 프로젝트에는 적합하지 않을 수 있다는 언급도 나온다. 적합한 프로젝트에 적용하라는 얘기이다.

 

예전에 여러 사이트를 돌아다니며, SI 프로젝트를 개발하던 당시 c, cpp, java, c# 할 것 없이 프로젝트에 따라 개발을 했었는데, 그때 과제 중의 하나가 c로 되어 있는 것을 java로 바꾸는 작업이었다. 처음에는 간단하겠지 하고 시작했는데 꽤 힘들었다. 그런데 같이 프로젝트를 진행하던 동료는 빠르게 진도가 나갔다. 보니까 그냥 단순하게 c function을 java method로 바꾸고 method 들은 몇십 개의 변수 선언으로 시작되었으며, 길이가 엄청나게 길었다. 중간 과정이겠거니 했지만, 최종 코드에서 변한 건 없었다. 문제를 몇 번 지적했지만, 문제라고 생각하지 않는다고 하시고 프로젝트가 너무 바쁘게 진행되고 있었기에 더는 얘기는 하지 않았다.

 

Angular 를 도입하기 시작했을 때도 비슷한 상황이 발생했다. Angular 도 일종의 웹 애플리케이션 개발 방식의 패러다임 전환을 요구한다. 하지만 jQuery와 같은 방식에 익숙해져 있던 개발자들은 뭔가 select 해야 할 것만 같은 생각에 프레임워크는 Angular인데 jQuery를 추가하거나 getElementById 코드들이 생겨났다. 확실히 이러한 변화들은 팀의 수준이 일정 부분까지 올라갔을 때 진행되는 것이 좋을 것 같다는 생각이 들었다.

 

WebFlux 도입은 결국 적용하여 서비스로 나갔다. 나는 다른 모듈 개발이 진행되어 해당 프로젝트에는 참여하지 않았다. 예상대로 오픈 이후에 다양한 오류들이 빈번하게 발생하였으며, 각종 제약사항이 추가되었다. 수정본을 보니 코드에는 block이 남발되어 있었고, 나중에 안 사실이지만 block의 의미를 잘 모른 채 그냥 추가해야 코드가 작성되길래 썼다고 하더라. 아마도 그 분의 기술 스택에는 webFlux 로 서비스 개발 이력이 추가되지 않았을까..

 

물론 기술의 정도는 없다고 생각한다. 미처 생각하지 못한 상황 속에 다양한 솔루션들이 제시되고 그에 따른 새로운 기술들도 적용된다. 도구와 기술에 초점을 맞추는 게 아니라 비즈니스에 더욱 초점을 두어야 하긴 하지만, 올바르게 도구와 기술을 충분히 이해하고 사용한다면 더 나은 결과물과 자신의 발전도 있을 거란 생각을 해본다.