기술 스택 선택은 개발 시작 전에 내리는 가장 중요한 결정 중 하나입니다. 이 결정이 향후 5년간의 유지보수 비용, 인력 확보 난이도, 기능 확장 속도, 보안 패치 대응력을 결정하기 때문입니다. 많은 의사결정권자가 초기 개발 비용에만 집중합니다.

"이 기술로 하면 개발비가 20% 저렴합니다, 지구 최강의 기술로 만들어진 프레임웍입니다. "등의 미사여구로 개발사는 자기들의 주력 기술을 포장 하는 경우가 많습니다.

하지만 정말 저렴하고 그렇게 엄청난 기술일까요?

왜 개발사들은 자기 기술을 그렇게 권할까

개발사가 마이너 기술이나 커스텀 프레임워크를 권하는 이유는 보통 두 가지입니다. 첫째, 자신들이 그 기술을 가장 잘 다루기 때문입니다. 메이저 기술은 경쟁이 치열한 반면, 자기들이 만든 프레임워크나 익숙한 마이너 기술 위에서는 단가도 더 높게 책정할 수 있고, 자신들 외에는 다룰 수 있는 회사도 적어집니다.

둘째, 이전 프로젝트의 자산을 재활용하기 좋기 때문입니다. 비슷한 기능을 빠르게 찍어내야 하는 입장에서는, 매번 클라이언트의 요구에 가장 적합한 기술을 새로 고르는 것보다 자기들이 이미 들고 있는 도구로 만드는 게 효율적입니다. 결과적으로 클라이언트의 비즈니스 요구보다 개발사의 운영 효율이 우선되는 구조입니다.

유지보수 비용을 높이는 선택들

마이너하거나 잘 알려지지 않은 기술을 선택하면 해당 기술을 다룰 수 있는 개발자를 찾기 어렵습니다. 구인 공고를 올려도 지원자가 없고, 인력 수급이 어려우면 단가가 올라갑니다. 교체 인력을 구하는 데만 몇 달이 걸리기도 합니다.

특정 개발자가 독자적으로 만든 커스텀 프레임워크를 사용하면 그 개발자가 떠났을 때 아무도 코드를 이해할 수 없는 상황이 됩니다. 문서화가 되어 있지 않은 경우가 대부분이고, 되어 있더라도 외부 개발자가 이해하기까지 오랜 학습 기간이 필요합니다.

과도한 추상화도 문제입니다. 아키텍처를 지나치게 복잡하게 설계하면 간단한 기능 변경 하나에 여러 계층을 수정해야 하는 구조가 되어 유지보수 효율을 크게 떨어뜨립니다. 버튼 색상 하나 바꾸는 데 5개 파일을 수정해야 한다면 구조에 문제가 있는 것입니다.

실제로 한 회사에서만 쓰던 커스텀 프레임워크로 만들어진 시스템을 인수받은 클라이언트가 있었습니다. 그 프레임워크를 다룰 줄 아는 개발자를 찾는 데만 몇 달이 걸렸고, 겨우 찾은 개발자도 시장 평균보다 훨씬 높은 단가를 요구했습니다. 신기능 하나 붙이는 시간이 일반 프로젝트의 수 배가 되어, 결국 메이저 기술로 다시 만드는 것이 장기적으로 더 저렴하다는 결론에 이르렀습니다.

갑을이 역전되는 순간

마이너 기술이나 자체 프레임워크의 진짜 위험은 비용이 아니라 종속입니다. 그 개발사만 다룰 수 있는 기술 위에 시스템을 올려두면, 어느 시점에 클라이언트는 이런 상황을 마주합니다. 개발사와의 관계를 정리하고 내부 인력으로 전환하고 싶어도 시장에 그 기술을 다룰 수 있는 개발자가 거의 또는 전무하고, 다른 개발사에 유지보수를 맡기려 해도 받아주려는 회사가 없습니다.

결국 울며 겨자 먹기로 기존 개발사와 계속 갈 수밖에 없습니다. 그리고 그 순간 갑을이 역전됩니다. 단가를 올려도 받아들여야 하고, 일정이 늦어져도 항의하기 어렵고, 품질에 문제가 생겨도 개발사를 바꿀 수 없습니다. 클라이언트가 비용을 지불하면서도 협상력은 개발사 쪽으로 완전히 넘어갑니다.

한 번 들어가면 빠져나오기가 매우 어렵습니다. 기술을 새로 다루려면 학습 비용까지 클라이언트가 부담해야 하기 때문에, 차라리 지금의 불편을 감수하는 쪽이 단기적으로는 합리적이라는 계산이 서고, 그렇게 시간이 흐를수록 종속은 깊어집니다. 메이저 기술을 고른다는 건 단지 유지보수 비용을 줄이는 일이 아니라, 비즈니스의 자유도와 협상력을 지키는 일입니다.

유지보수 비용을 줄이는 선택

커뮤니티가 크고 활발한 메이저 기술을 선택하면 문제 해결이 쉽습니다. Stack Overflow에 질문을 올리면 수 시간 내에 답변이 달리고, 공식 문서가 충실하며, 서드파티 라이브러리 생태계가 풍부합니다. 보안 취약점이 발견되어도 빠르게 패치가 배포됩니다.

무엇보다 해당 기술을 다룰 수 있는 개발자가 시장에 많기 때문에 인력 확보가 용이하고, 경쟁에 의해 단가도 합리적으로 형성됩니다. 새로운 팀원이 합류해도 기술 자체의 학습 곡선이 낮아 빠르게 프로젝트에 기여할 수 있습니다.

또한 메이저 기술은 장기적인 지원과 업데이트가 보장되어 기술 단종의 위험이 현저히 낮습니다.

프로덕트 메이커의 기술 스택 선택 원칙

프로덕트 메이커는 특정 스택을 고정해 두지 않습니다. 프로젝트의 요구사항·예산·운영 조건·고객의 기존 자산에 따라 가장 적합한 조합을 선택합니다. 다만 어떤 스택을 고르더라도 다음 원칙을 공통으로 적용합니다.

첫째, 커뮤니티가 큰 메이저 기술을 우선합니다. React, Vue, Svelte 같은 프론트엔드 라이브러리든, Spring Boot, Node.js, Django 같은 백엔드 프레임워크든, 시장에 개발자 풀이 충분한 기술이어야 인력 교체와 확보가 수월합니다.

둘째, 장기 지원이 보장된 기술을 선택합니다. 보안 패치와 업데이트가 지속적으로 제공되어 단종 위험이 낮은 메이저 기술을 우선하고, 소수 개인이 만든 커스텀 프레임워크나 사실상 유지보수가 멈춘 기술은 피합니다.

셋째, 컨테이너 기반 환경(Docker 등)으로 환경 일관성을 확보합니다. 개발과 운영의 차이로 인한 문제를 줄이고, 클라우드 이전이 필요할 때 마이그레이션 비용을 최소화합니다.

클라이언트 입장에서 견적을 받을 때 한 가지만 물어보시면 많은 정보를 얻을 수 있습니다. "이 기술을 다룰 수 있는 개발자가 시장에 얼마나 있나요?" 답을 들으신 뒤 채용 사이트에서 검색해 보시면, 그 견적의 5년 뒤 모습이 어느 정도 그려집니다. 기술 스택은 단순한 기술적 선호가 아니라 비즈니스 의사결정입니다.