기술 선택의 이유

되게 오랜만에 글을 쓴다. 이직하고 나서 너무 정신없이 살다 보니, 글을 쓰는 행위 자체를 잊어버린 것만 같았다. 다시 글을 쓰는 이유는 그냥 글을 쓰고 싶어졌다.

기술 선택의 이유라고 거창하게 지었지만,

사실 어떤 기술을 선택하는 나의 기준이 점점 변하고 있다는 것을 느껴서 이 글을 쓰게 되었다.

어렸을 때는 내가 공부한 기술을 쓰고 싶었던 것 같다. 따끈따끈한 피자 마냥 빨리 내가 어제 테스트해 본 것을, Getting Started에서 따라 해 본 것, 혹은 컨퍼런스나 세미나에서 발표로 들은 것을 프로덕트에 적용해 보고 싶었던 것 같다. 새로운 라이브러리나 프레임워크도 한몫을 했던 것 같고. 그것들이 내 모든 문제를 해결해줄 것만 같았다.

조금 지나서는 내가 익숙하고 잘 아는 기술을 선택했던 것 같다. 이유는 새로운 기술에 대한 적용에서 몇번 피를 본적이 있었고, 오픈소스들을 적용하면서 사이드 이펙트를 몇번 겪으면서 확실하게 아는 기술에 대해서 좀 더 선호하게 된 것 같다. 희한한 것은 이런 사이드 이펙트는 개발하는 과정에서나 테스트 프로세스 동안에는 발생하지 않고 꼭 실제 운영환경에서 간헐적 으로 발생하곤 했고, 나를 줄곧 괴롭혀 왔다. 물론 그 과정에서 운이 좋게 오픈소스를 고치고 기여를 하는 과정도 있었지만, 프로덕션 환경에서의 아찔했던 기억은 그리 좋은 기억은 아니다.

지금은 어떨까?

예전에는 내가 속한 개발팀, 회사에서 쓰는 언어/기술을 당연히 따라 썼다. 유지보수 측면에서도 그게 맞다. 지금도 그렇긴 하지만 세세한 기술을 선택할 때, 지금 내가 속한 조직에서 이것을 유지보수 할 수 있는가? 혹은 관리 포인트 가 더 생기지는 않는지에 대해서 좀 더 고민하게 되는 것 같다. 어제 본 테크 유투버가 소개한 기술이나, 팟캐스트에 나온 기술, 관심 있는 기술은 개인적으로 간직하게 되는 것 같다. 아니면 때로는 회사 내 테스트 서비스나 일회성 무엇인가를 만들 때 쓰게 되는 것 같다.

최근에 fastapi 라는 매력적인 프레임워크를 찾았지만, 당장 이것을 회사의 프로덕트에 도입하지는 않았다. 나는 여전히 flask, sanic 을 쓰고 있지만, fastapi 는 프로젝트를 하는 데 도움이 되는 테스트 클라이언트를 쓰는 데 사용을 했다. 그렇게 조금씩 테스트를 해보고 장단점을 파악하고, 언젠가는 프로덕트에 쓰일 수도 있고, 안 쓰일 수도 있을 것 같다.

기술 선택의 이유는 또 바뀔 수 있을 것 같다. 지금의 나에겐 이런 수준이지만, 좀 더 큰 그림을 보거나 장기적인 안목이 필요할 때, 그리고 더 성장한다면, 바뀔 수 있을 것 같다.