최근 우연히 보게 된 당근마켓의 프론트엔드 채용 공고에서 vanilla-extract와 같은 최신 CSS 스택에 대한 사용 경험을 우대한다는 글을 보고 흥분한 나머지 현재 같이 일하고 있는 엔지니어링 팀에 들뜬 마음으로 관련 내용을 소개했었다. 그러나 생각과는 다르게 팀 내부에선 그렇게 화끈한 반응을 얻지는 못했고, 지금은 그냥 혼자서 공부하고 있다… 그러나 덕분에 새로운 스택을 도입할 때 고려해야 할 점들에 대해서 한 번 생각해 볼 수 있었다.
새로 나온 기술들을 무조건 도입해야 할까?
엔지니어라면 기본적으로 새로운 기술에 경도되는 경향이 있는 것 같다. 예를 들어 온라인 강의 사이트의 광고만 하더라도 하나의 강의를 통해서 몇 개의 스택을 배울 수 있는지가 중심이 되어있다. 그러나 지나치게 많은 스택을 적은 이력서는 오히려 역효과를 불러일으킨다는 사실은 이미 잘 알려져 있다.
그렇다면 개발자라는 직업은 왜 이렇게 새로운 기술에 집착할 수밖에 없을까? 개인적인 생각으로는 도태된다는 것에 대한 두려움 때문이 아닐까 싶다. 개발 환경은 빠르게 변화하고 하루가 다르게 새로운 기술이 등장하고 있다. 이러한 변화 속에서 내가 열심히 배웠던 스택이 하루아침에 사라질지도 모른다는 두려움이 있는 것도 사실이다(실제로 사라지고 있다…). 그러나 다시 생각해보면 정말 핵심적인 부분들은 생각보다 그렇게 빠르게 변하지 않았다.
생각해보면 JS에 엄청난 변화가 일어났던 ES6가 등장한 것이 2015년이니까 이제 7년이나 되었다…. 7년이나 지났는데 그사이에 엄청난 변화가 있었을까? 물론 그 뒤로 굵직한 기능들이 추가되었지만 지금도 특정 채용 공고에는 프론트엔드 요구사항에 ES6(혹은 그 이상)에 대한 이해를 명시하고 있다. 또한 JS 대표 라이브러리 리액트는 2013년에 출시되어 벌써 8년이나 지났다. 말 그대로 핵심적인 기술들은 쉽게 없어지지는 않는다는 것이다.
그렇다면 새로운 기술은 어떤 시점에 우리의 프로젝트로 도입되어야 할까? 기술이 완전히 무르익어 안전해질 때까지 기다려야 할까? 그리고 이러한 고민에 관한 기준점은 무엇일까?
스택 도입에 앞서 생각해 볼 것들
새로운 기술 스택을 도입한다고 하면 먼저 다음의 두 부분을 고려해야 한다고 생각한다.
- 기술적 이점
- 협업 환경
1. 기술적 이점
일반적으로 새로운 기술을 도입한다고 하면 그 이유는 보통 기술적인 이점이 있기 때문이라고 생각된다. 특정 기술이 작업 속도를 개선한다던가, 사용성 개선에 도움이 된다고 하는 표면적인 이점이 기존에 비해서 확실하게 있다면 안정성이 떨어지거나 정보가 부족하더라도 도입을 긍정적으로 생각해 볼 수 있다.
이러한 기술적 이점은 프론트엔드 관점에서 다시 다음과 같이 나누어 볼 수 있을 것 같다.
- 현재 존재하는 문제를 해결해 줄 수 있는가?
- 기존에 비해서 사용성이 개선되는가(유저 관점)?
- 기존에 비해서 개발이 편리해지는가(개발자 관점)?
그러나 두 번째 조건인 '협업' 환경에 대한 고민도 매우 중요하다고 생각된다.
2. 협업 환경
"내가 추천한 스택에 대한 팀 반응이 왜 미지근할까?"
이러한 질문 이전에 과연 그 기술이 모두가 동의하고 원했는지는 생각해보아야 할 것 같다. 사실 새로운 기술의 도입은 예측 불가능한 모험을 시도하는 것과 같다. 설사 안정성이 어느 정도 보장된 일반적인 스택일지라도 그것을 팀 내부에 들여오는 것은 또 다른 문제일 수 있다. 성능적인 문제를 떠나서 특정 팀원은 특정 기술이 지향하는 코드 작성 방식에 반감을 품을 수도 있다. 이러한 문제에 대해선 건전한 협업 환경을 만들기 위해서라도 충분한 설득과 배려가 선행되어야 한다고 생각된다.
이런 상황의 대표적인 예가 바로 CSS라고 생각된다. 경험상 개발자들은 주로 CSS-in-JS 방식을 선호하는 편으로 느껴지지만, 디자이너 출신인 나는 CSS 파일을 따로 관리하는 것이 더 편하게 느껴진다. 그래서인지 입사 전에 작성된 인라인 방식의 스타일 코드에 대해 알 수 없는 거부감이 드는 것도 사실이었다. 그러나 두 방식은 무조건 특정 방식을 선택해야 할 정도로 성능 차이가 크지 않기에 오히려 '어떤 방식이 작성하기에 편한가?'라는 선호의 문제로 귀결되는 것 같다. 이러한 경우 합의하에 모두가 편한 방식을 선택하는 것이 좋지 않을까?
원가 제약
마지막으로 이러한 조건을 모두 포괄하는 기본 전제로 '원가 제약'을 생각해 볼 수 있다.
회계학에는 다음과 같은 원가 제약(cost constraint)이란 개념이 있다.
원가는 재무보고로 제공될 수 있는 정보에 대한 포괄적 제약요인이다. 재무정보의 보고에는 원가가 소요되고, 해당 정보 보고의 효익이 그 원가를 정당화한다는 것이 중요하다.
K-IFRS 제1000호 재무보고를 위한 개념체계
쉽게 말하면 어떤 정보를 얻기 위해 드는 비용이 그로 인한 효익을 초과한다면 그 정보는 아무리 유용하더라도 계속 사용하기 어렵다는 것이다. 마찬가지로 우리가 사용할 스택도 그것을 이용하면서 드는 비용(물리적인 시간과 인력 등)이 효익(기술적 이점 등)을 초과하지는 않는지 항상 확인해야 한다.
원가 < 효익 ? adopt : ignore예를 들면 이 세상에 존재하는 모든 스택은 대부분 장점을 가지고 있지만 좋은 기술들을 모두 다 붙이기에는 인적, 물적, 정신적 비용이 너무 크게 든다. 따라서 우리는 적당히 쉽고 효율적인 몇몇 기술들을 묶어서 그것들을 중심으로 개발을 진행한다.
또한 여기에서 말하는 원가는 금전적인 비용 이외에도 필요한 모든 요소를 포함하는 개념이다. 따라서 특정 기술이 정신적으로 너무 큰 스트레스를 준다면(이해할 수 없는 메뉴얼 등…) 그것 또한 '원가'의 범주로 볼 수 있다.
결론
지금까지 새로운 기술 스택 도입 이전에 고려해야 할 기준들에 대해서 다루어 보았다. 마지막으로 본 글의 내용을 정리하면, 특정 스택이 '기술적인 이점'을 확실하게 가지고 있고, 이를 받아들일 '협업 환경'이 조성되어 있다면 이에 대한 도입을 긍정적으로 검토해 볼 수 있을 것이다. 추가적으로 이러한 장점을 가지는 데 필요한 '원가'에 대해서도 고려해 본다면 더욱 체계적인 의사결정이 가능해질 수 있을 것이다.
