풀스택 개발자 상주 서비스, 언제 유리한가 — 외주·채용과 비교

개발이 필요한데 사내에 개발자가 없을 때 선택지는 대체로 세 가지입니다. 채용하거나, 외주를 맡기거나, 개발자가 우리 쪽에 상주하며 일하게 하는 것입니다. 어느 쪽이 옳다기보다 상황에 따라 유리한 방식이 다릅니다. 어떤 조건에서 상주 방식이 맞는지 정리했습니다.

세 방식이 실제로 갈리는 지점

비용만 비교하면 판단을 그르치기 쉽습니다. 실제로 갈리는 것은 요구사항이 얼마나 확정돼 있는가와 변경이 얼마나 자주 생기는가입니다.

• 채용 — 장기적으로 가장 저렴하고 지식이 사내에 쌓입니다. 다만 채용까지 수개월이 걸리고, 한 사람이 프런트·백엔드·인프라를 모두 감당하기 어려운 경우가 많습니다. 뽑고 나서 그 사람을 평가·성장시킬 기술 관리자가 없다는 점도 실무에서 자주 걸립니다.
• 외주(도급) — 범위가 명확하고 한 번 만들면 크게 바뀌지 않는 일에 적합합니다. 반대로 중간에 요구가 바뀌면 그때마다 변경 계약이 필요해 속도와 비용이 함께 나빠집니다.
• 상주(투입) — 개발자가 우리 일정과 회의에 들어와 함께 일합니다. 요구가 자주 바뀌거나, 무엇을 만들지 아직 다듬는 중이거나, 기술 판단을 같이 해 줄 사람이 필요할 때 유리합니다.

상주 방식이 맞는 조건

• 요구사항이 진행하면서 구체화되는 단계 — 문서로 다 적어서 넘길 수 있는 상태가 아니라면 도급 계약은 서로 힘들어집니다.
• 담당자에게 기술 배경이 없을 때 — 견적서의 항목이 타당한지, 이 기능이 왜 오래 걸리는지 설명해 줄 사람이 내부 회의에 있는 것과 없는 것은 차이가 큽니다.
• 기존 시스템을 손봐야 할 때 — 이미 돌아가는 서비스에 손을 대는 일은 범위를 사전에 못 박기 어렵습니다.
• 운영과 개발이 섞여 있을 때 — 장애 대응, 데이터 확인 요청, 소소한 수정이 계속 발생하는 조직.

반대로 상주가 맞지 않는 경우

만들 것이 명확하고 한 번 납품하면 끝나는 일, 예를 들어 사양이 확정된 소개 페이지나 정형화된 시스템 도입이라면 도급 외주가 더 저렴하고 관리 부담도 적습니다. 또 개발 물량이 꾸준히 있고 사내에 기술 관리자가 이미 있다면 채용이 장기적으로 낫습니다.

계약 전에 정해 두어야 할 것

상주 방식은 유연한 만큼 범위가 흐려지기 쉽습니다. 다음을 문서로 정해 두면 서로 오해가 줄어듭니다.

• 업무 범위 — 개발 외에 어디까지 맡는지(기획 지원·데이터 확인·장애 대응·문서화). "그때그때 필요한 일"로 두면 반드시 다툼이 생깁니다.
• 근무 형태 — 상주 일수, 원격 병행 여부, 연락 가능 시간. 특히 장애 대응이 야간까지 포함되는지 명시하십시오.
• 산출물과 소유권 — 소스 코드 저장소의 소유 계정, 라이선스, 제3자 라이브러리 사용 원칙.
• 인수인계 조건 — 계약 종료 시 무엇을 남기는지. 최소한 저장소 접근 권한, 배포 절차 문서, 환경 변수와 외부 서비스 계정 목록, 아키텍처 개요는 받아야 다음 사람이 이어받을 수 있습니다.
• 교체 기준 — 투입 인력이 맞지 않을 때의 절차.

비용을 비교할 때

월 단가만 비교하면 채용이 가장 싸 보입니다. 실제 비교는 총 소요 비용과 시작 시점으로 해야 맞습니다. 채용은 채용 비용과 4대 보험·장비·교육 기간이 더해지고 시작까지 수개월이 걸립니다. 도급은 초기 견적은 낮아도 변경이 쌓이면 총액이 올라갑니다. 상주는 단가가 높은 대신 바로 시작되고 변경에 추가 비용이 붙지 않습니다. 어느 쪽이 유리한지는 프로젝트 기간과 변경 빈도로 계산해 보시면 대체로 답이 나옵니다.

정리

상주 방식은 무엇을 만들지 다듬어 가면서 개발해야 하는 조직에 유리합니다. 반대로 사양이 확정된 일은 도급이, 물량이 꾸준하고 관리자가 있는 조직은 채용이 낫습니다. 루미브리즈는 개발과 AI 검색 최적화를 함께 다루기 때문에, 만들면서 검색·AI 인용까지 함께 설계해야 하는 프로젝트에서 이 방식을 제안드리는 경우가 많습니다.