개발자가 알려주는 기술스택 제대로 된 외주개발사 선택법
개발자가 정리한 채용, 운영까지 보는 외주개발사 기준 기술스택 가이드
안녕하세요!!! 개발빔입니다~
저는 예전에 외주 개발사에서 일했고,
지금은 인하우스 개발자로 외주개발사와 함께 일하기도 하고 있는데요!
두 자리를 다 겪어보니, 외주개발사 선택에서
제일 과소평가되는 요소가 기술스택이라는 생각이 들더라고요...
견적, 포트폴리오만 보다가 나중에
채용·유지보수 지옥을 경험하는 경우를 너무 많이 봤어요 ㅠㅠ
오늘은 개발자 입장에서
외주개발사의 기술스택을 어떻게 보면 좋을지,
그리고 제가 실제로 경험했던 케이스까지 같이 정리해보겠습니다~~ :)
기술스택이란?
단순히 React 쓴다는 말로는 부족하다
기술스택이라고 하면 보통 이렇게 나열하죠.
프론트엔드: React, Next.js, Typescript
모바일: React Native
백엔드: Python + Django, Java + Spring Boot
인프라: AWS
문제는 여기서 끝나버리는 경우예요...
실제로 프로젝트를 해보면 기술스택은 단순 목록이 아니라,
어떤 개발자를 뽑을 수 있는지
유지보수와 기능 확장이 얼마나 버틸 수 있는지
클라우드 비용과 운영 방식이 어떻게 결정되는지
까지 한 번에 묶어버리는 선택이거든요...
그래서 저는 기술스택은 서비스의 체질을 정하는 결정이라고 생각해요!
외주개발에서 기술스택이 중요한 세 가지 이유
1. 인하우스 개발자 채용 가능성
외주 개발사에 있을 때도,
인하우스 개발자로 들어와 있는 지금도
가장 크게 느끼는 포인트가 채용인데요!
프레임워크가 너무 마이너하면
외주 끝난 뒤에 인하우스 개발자를 구하기가 정말 힘들어요...
반대로 Python + Django, Java + Spring Boot 같이
검증된 조합을 쓰면 채용 시장에서 후보를 찾기가 훨씬 수월하거든요.ㅎㅎ
그래서 저는 외주개발사와 미팅할 때 이 점들을 꼭 앞서 점검해요!
이 스택으로 실제로 사람이 잘 구해지는지
유지보수 단계에서 다른 언어로 바꾸고 싶어질 가능성은 없는지
대답을 최대한 구체적으로 듣고 앞으로의 채용에 대해 대비해두는 게 중요해요.
2. 유지보수와 기능 확장 난이도
인하우스 입장에서 가장 중요한 부분이라고 말해도 무방한데요!
React + Next.js에 Typescript, eslint가 같이 들어가 있으면
초기 개발 속도뿐 아니라 이후 리팩토링 속도도 안정적으로 나와요.
백엔드에서도 Django나 Spring Boot를 쓰면서
Swagger(OpenAPI)로 API를 문서화해 두면,
새로운 개발자가 들어와도 구조를 이해하기가 훨씬 쉽구요~
외주개발사에서 이런 최소한의 기준까지 맞춰두면
인하우스 개발자는 코드와 API를 인수받는 순간부터
구조를 이해하는 데 집중할 수 있어요!ㅎㅎ
3. 인프라와 운영 비용 구조
기술스택 이야기를 하다 보면
인프라를 빼먹는 경우가 많아요...ㅜ
하지만 AWS를 어떻게 쓰는지는
장기적인 비용과 안정성에 바로 영향을 주는 부분이에요.
ECS, RDS 같은 매니지드 서비스 활용 여부
CloudWatch, CloudTrail로 모니터링과 로그를 어떻게 구성하는지
IAM으로 권한을 얼마나 세분화하는지
이런 이야기까지 꺼내는 외주개발사는
운영 국면을 실제로 겪어본 적이 있는 경우가 많았어요!
인하우스 개발자는 결국 이 인프라를 매일 보고 살아야 하니까요... ㅠㅠ
서비스 타입별 기술스택과 외주개발사 보는 기준
웹·SaaS 서비스와 프론트엔드 스택
SaaS나 대시보드 같은 웹서비스에는
React + Next.js 조합이 여전히 많이 쓰이는 것 같아요!
Next.js는 서버사이드 렌더링과 정적 사이트 생성을 지원해서
SEO와 초기 로딩 속도에서 이점이 있고,
라우팅 구조도 잘 정리돼 있어요.
여기에 Typescript와 eslint를 붙이고,
chakra-ui, React Query, use-context-selector 같은 라이브러리를 함께 쓰면
디자인 시스템 기반 UI 구성
상태 관리 최적화
코드 스타일 통일
같은 부분에서 운영이 편해지거든요!
그래서 저는 외주개발사와 미팅을 하는 경우에 이런 것들을 꼭 물어봐요.
왜 이 프로젝트에 Next.js를 선택했는지
Typescript와 eslint 규칙을 어떻게 관리하는지
UI 라이브러리를 프로젝트마다 어떻게 커스터마이징하는지
답변이 추상적이면
단순히 트렌드를 따라가는 수준일 수 있고,
구체적인 코드와 레포 구조까지 함께 이야기하면
운영까지 생각하는 팀일 가능성이 크겠죠?
모바일 앱이 필요한 경우의 React Native
웹과 앱을 동시에 가져가야 하는 서비스라면
React Native를 쓰는 팀이 굉장히 많은데요!
웹에서 이미 React를 쓰고 있다면
React Native를 선택했을 때
로직 재사용
디자인 시스템 공유
가 가능해서 인하우스 입장에서는 훨씬 효율적이죠~ㅎㅎ
그래서 저는
웹/앱 사이에서 공통 컴포넌트를 어떻게 나누는지
앱 스토어 배포 경험이 어느 정도 있는지
를 꼭 확인하고 있어요~
데이터·업무 시스템에서의 Django와 Spring Boot
데이터 처리나 내부 업무 시스템 쪽에서는
Python + Django와 Java + Spring Boot가 요즘 많이 보이는 것 같은데요!
Django는
높은 생산성
ORM 기반 데이터 관리
기본 제공 보안 기능
같은 장점 덕분에
빠르게 만들고, 이후 커스터마이징하기 좋았고요.
Spring Boot는
대형 서비스에서의 구조적 안정성
도메인 주도 설계 적용 용이
복잡한 통합 환경에서의 확장성
때문에 엔터프라이즈 도메인에서 특히 유리하다고 느꼈어요!
인하우스에서 이런 스택을 넘겨받으면
레퍼런스와 커뮤니티가 풍부해서
문제를 해결할 때 선택지가 많다는 장점도 있었어요~ :)
기술스택을 함께 설계해준 외주개발사
외주 개발사에서 일할 때는
고객이 선택한 스택으로 그냥 구현만 하는 프로젝트도 많았고,
지금은 인하우스 개발자로서
외주팀이 남기고 간 코드를 인수하는 역할을 맡고 있는데요~
두 경험을 모두 해보니 가장 기억에 남는 팀은
기술스택을 단순 나열이 아니라 설계 대상으로 보는 팀이었어요.
이렇게 운영을 고려한 기술스택을 가진 외주개발사는 똑똑한개발자였는데요!
이 팀과 프로젝트를 할 때는
프론트엔드에서 React, Next.js, Typescript, eslint, chakra-ui, React Query 등을
어떤 기준으로 조합하는지 설명
모바일이 필요하면 React Native로 확장하는 구조까지 함께 논의
백엔드에서 Python + Django와 Java + Spring Boot를
도메인 특성에 맞게 나눠 쓰는 기준을 공유
이렇게 정보를 제공하면서 논의를 통해 가장 최적의 기술스택을 고려해주더라고요!
똑똑한개발자의 프론트엔드 개발 활경 소개입니다
똑똑한개발자의 인프라/백엔드 개발 활경 소개입니다인프라 측면에서는 AWS ECS와 RDS,
CloudWatch 기반 모니터링, IAM 권한 설계 같은 부분을
초기 설계 단계에서 같이 논의해 주셨어요.
함께 협업하는 인하우스 개발자 입장에서는 런칭 이후 내가 받아서 운영해야 할 환경을
미리 같이 그려볼 수 있었다는 점이 특히 좋았어요~ :)
또 하나 인상적이었던 부분은
똑개팀은 Next.js 보일러플레이트를 GitHub에 공개해두고
자체 라이브러리를 npm에 올려 재사용하면서
정기적으로 코드 리뷰를 진행하는 개발 문화였어요!
외주사일 때도 이런 구조를 갖추기 쉽지 않은데,
똑똑한개발자는 뚜렷한 기준을 가지고 스택과 문화를 같이 가져가려는 팀이라
인하우스 개발자로 협업할 때 신뢰가 생기더라구요ㅎㅎ
똑똑한개발자 포트폴리오에서 자세한 기술스택을 볼 수 있어요!
외주개발사를 선택할 때 기술스택을 잘 이해하지 못해서 넘어가는 경우도 많겠지만,
기술스택 부분은 장기적으로 봤을 때 가장 중요한 부분 중 하나예요!
개발을 잘 모르더라도 서비스 운영을 고려해 기술스택을 설명하고 선택해주는 외주개발사를 선택하시면
장기적인 운영 안정성을 보장받을 수 있겠죠?
기술스택으로 보는 외주개발사 선택의 핵심
오늘 설명드린 것 처럼 외주개발사 선택에서
기술스택은 생각보다 훨씬 큰 영향을 주는 부분이에요~!
어떤 개발자를 나중에 뽑을 수 있는지
기능을 얼마나 오래, 안정적으로 확장할 수 있는지
클라우드 비용과 운영 난이도가 어떤 수준이 될지
모두 기술스택에서 시작되죠.
그래서 저는 이제
스택을 왜 그렇게 골랐는지 설명할 수 있는지
프론트엔드, 백엔드, 인프라를 하나의 흐름으로 이야기하는지
인하우스 개발자가 들어왔을 때를 전제로 설계하는지
이 세 가지를 기준으로 외주개발사를 선택하고 있어요!
지금 외주개발사를 찾고 계시다면
견적과 포트폴리오만 보지 마시고,
기술스택에 대한 대화를 한 번 더 깊게 가져가 보시면 좋을거예요 :)
그 과정에서 서비스의 목표와 운영까지 함께 고민해주는 팀을 만난다면,
인하우스 개발자로서도 훨씬 덜 힘든 환경에서
서비스를 키워갈 수 있을 거라고 생각합니다ㅎㅎ
댓글로 더 궁금한 점 말씀해주시면 더 설명드릴게요~
공감도 부탁드리고요!
오늘도 도움이 되셨길 바라면서!
읽어주셔서 감사합니다~
