이커머스에 진출하려는 모든 기업은 결국 개발을 외주로 맡길지 내부에서 할지 결정해야 해요.
성공과 실패에 큰 영향을 주므로 경영진이 가볍게 다뤄서는 안 돼요. 전담 사내 팀으로 요구에 대응하려는 기업도 있고, 외주의 장점이 단점을 훨씬 넘는다고 보는 기업도 있어요.
사내 개발팀의 장단점
팀을 구성하려면 다음을 고려하세요.
장점
- 빠른 대응: 내부 팀이 있으면 개발 목표를 신속히 달성할 수 있어요. 특히 상세 조사 전에 즉각적인 대응과 수정이 필요한 문제에 유용해요. 작은 문제가 커지기 전에 처리할 안전망이 되며, 바쁘거나 찾는 데 시간이 드는 외주 팀을 오래 기다리지 않아도 돼요.
- 쉬운 소통: 같은 사무실이나 건물에 있으면 대면 대화가 쉬워요. 회사 문화를 이해시키고 정확한 요구를 충족하는 데 도움이 돼요. 비용이 큰 실수와 되돌리기를 피하려면 직접 소통이 중요하며, 내부 팀만이 이런 기회를 제공해요.
- 완전한 통제: 회사의 이커머스 요구에만 집중하는 전문 팀은 사양에 맞는 플랫폼을 만들어요. 사업 요구를 즉시 처리하고 방향과 전략에 맞춰 실제로 수정할 수 있어요. 프로젝트 모든 부분을 통제해 기대에 맞게 만들어요.
- 사내 팀의 유일한 고객이므로 효율을 높일 가능성이 있어요.
- 운영 방식과 작업·프로젝트 양에 따라 내부 팀이 더 저렴할 수 있어요.
단점
- 직원 이직: 기술 업계에서는 개발자 대부분이 회사에 오래 머물지 않는 것으로 알려져 있어요. 전문가 수요가 높아 경쟁사가 유능한 개발자에게 자주 접근해요. 입퇴사로 업무가 자주 끊길 수 있고 새 사람을 찾는 데 시간이 걸려요. 중요한 시기에 이탈하면 비용이 커요. 탐색, 검증, 채용, 온보딩 비용도 고려해야 해요.
- 더 높은 비용: 회사 요구만 맡는 전일제 팀은 특히 소기업에 비싸요. 개발자는 여러 기업에서 높은 보수를 받을 수 있는 전문직이므로 고정 보수로 독점 고용하는 것은 소수 기업만 감당하는 사치예요. 높은 수요 속에서 다른 기회를 찾지 않도록 충분한 보상이 필요해요.
- 시간 효율 부족: 전일제 직원이 하루 매 순간 고급 프로젝트를 하기는 어려워요. 휴식이 나쁘지는 않지만 전문가 급여를 내는 입장에서는 받아들이기 어려울 수 있어요. 크고 작은 작업뿐 아니라 사무실 밖에 있는 시간에도 비용을 내요.
- 소수 내부 팀의 전문성에 의존하면 대형 에이전시처럼 큰 팀이 서로 배우는 이점을 얻지 못해요.
- 성능과 접근성 등을 중시하는 문화를 만들기 더 어려워요.
- 코드 품질을 유지하기 어려울 수 있어요.
내재화의 큰 위험은 품질이 떨어지고 프로세스에서 멀어지는 것이에요. 즉흥적인 출시, 성능에 대한 집중 저하, 품질 보증 축소에 빠지기 쉬워요. 제품 책임자가 과정을 감독하거나 전문 기술 프로젝트 관리자를 지정해 품질을 지키도록 권해요.
사내 팀 구조
팀원 역량, 다른 시스템의 복잡성, Shopify 사이트, 화면 작업량에 따라 구조가 달라져요. 먼저 백로그와 로드맵을 기준으로 분야별 책임과 업무량을 정리하세요. 각자 다른 테마의 간단한 사이트를 여러 개 출시한다면 중급 프런트엔드 개발자의 일이 많아져요.
전체 개발을 한 사람에게 의존하지 마세요. 코드와 지식이 한 사람에게 묶이고 표준과 품질이 낮아질 수 있어요. 풀 리퀘스트와 코드 리뷰가 도움이 되지만 개발자가 둘 이상 필요해요.
많은 기술 기업에서 쓰는 다음 구조를 참고할 수 있어요.
리드 또는 시니어 Shopify 개발자
Shopify를 알고 대형 프로젝트 경험이 있는 풀스택 개발자로 시작하세요. 특히 큰 프로젝트 경험은 체계적인 작업, 현대적인 도구, 개발 흐름 구축 능력을 줘요. 리드는 제품 책임자나 전담 프로젝트 관리자와 자원, 배포, 계획, 우선순위를 관리해요. 통합, 자체 앱, 복잡한 프로젝트의 설계도 담당해요.
프런트엔드 개발자: 중급 또는 주니어 Shopify 개발자
풀스택 개발자가 화면도 맡을 수 있어 항상 필요한 것은 아니에요. 하지만 대부분은 고품질의 시각적으로 정확한 레이아웃을 위해 전담 개발자를 선호해요. 시니어만큼 모든 분야를 알지는 못해도 화면, 앱, 기본 Liquid 로직 관련 백로그를 처리할 수 있어요.
헤드리스 방식을 선택하면 Vue.js나 React.js 경험자를 찾는 방향으로 요구 역량이 바뀔 가능성이 높아요.
시스템 담당 인력
다른 내부 시스템과의 통합을 담당하는 전담 팀도 중요해요.
결정 전에 분야별 업무량을 수치화하세요. 장기 백로그와 로드맵은 필요한 개발 인력과 시간에 따른 변화를 파악하게 해줘요.
도구와 개발 역량
이전 직장에서 같은 역할을 했다고 잘할 것이라 가정하면 안 돼요. 사내 Shopify 팀에는 필수 역량과 있으면 도움이 되는 추가 역량이 있어요.
우선 역량
Liquid 문법
Liquid는 Shopify 프런트엔드 템플릿 언어로, 템플릿에 로직을 적용할 때 필요해요. 데이터 기반 추천처럼 복잡한 기능부터 제품 목록의 할인 표시처럼 간단한 기능까지 만들어요.
Ruby나 JavaScript를 알면 일하며 배우기 어렵지 않지만, 탄탄한 이해와 경험이 있으면 바로 진행하고 학습 때문에 코드 품질이 떨어지지 않게 할 수 있어요.
기본 JavaScript
모든 Shopify 사이트에 JavaScript가 어느 정도 쓰여요. 애니메이션이나 새로고침 없는 양식 같은 동적 기능과 장바구니 추가 등 핵심 기능이 의존해요. 적어도 기본 JavaScript 이해는 필수예요.
HTML5
디자인 재현뿐 아니라 성능, SEO, 접근성에 미치는 영향을 포함해 좋은 마크업을 이해해야 해요. 효율적인 기능을 방해할 디자인을 알아보는 눈도 필요해요.
SCSS
프런트엔드 개발자는 스타일시트 생성과 관리에 흔히 쓰는 CSS 전처리기를 알아야 해요.
추가 역량
Ruby/PHP
Shopify는 그런 의미의 코딩을 요구하지 않아 서버 개발 역량을 필수로 보지 않아도 된다는 장점이 있어요. 앱이나 미들웨어가 필요한 데이터 작업에는 도움이 되지만, 비즈니스 분석이나 Shopify와 ERP 간 데이터 이동 같은 흔한 요구는 기존 앱을 조금 조정하면 해결할 수 있어요.
GraphQL
Shopify는 대부분의 요구를 위한 앱으로 코드 필요성을 줄이면서 GraphQL을 API 개발의 미래로 적극 추진해요. GraphQL은 API용 오픈소스 데이터 조회·조작 언어이자 기존 데이터로 쿼리를 수행하는 실행 환경이에요. 데이터 조작과 서버 기능 확장이 계획돼 있다면 아는 사람이 있으면 좋아요.
React/Vue.js
기존 매장이든 새로 만들 매장이든 개발을 내부로 가져오려면 React나 Vue.js를 사용했는지 먼저 확인하세요. 전문 기능을 추가할 계획이라면 가장 많이 쓰는 두 프레임워크를 깊이 이해하는 것이 유리해요.
개발 프로세스
필요한 기술을 알았다면 적절한 프로세스도 갖춰야 해요. 팀의 작업 방식을 살펴볼게요.
품질 보증 테스트
백로그에서 선택한 프로젝트를 개발한 뒤에는 철저한 테스트로 공개 품질을 보장해야 해요. 내부 팀에서 자동화를 첫 보호 수단으로 사용하는 것이 시작이에요. 다음 중 하나 이상을 사용할 수 있어요.
- 스냅샷 테스트는 화면 일부를 비교해 코드 변경 후 잘못 바뀐 부분을 찾아요.
- 개발자는 GitHub나 Bitbucket의 Pull Requests로 코드 통합 전에 검토하고 피드백을 제공해요.
- Cypresso.io, Jest, Circle 같은 도구로 JavaScript 테스트를 만들어 각 커밋에서 자동 실행하고 모두 통과해야 병합하게 할 수 있어요.
제품 책임자나 기술 프로젝트 관리자는 개발자와 별개여야 하며 결과가 요구사항에 맞는지 확인해야 해요. 작업 설명이 명확할수록 되돌려 보낼 일이 줄어요.
배포
정해진 절차를 체계적으로 따라야 원활해요. 성공적인 팀 경험이 있는 개발자는 대부분 다음을 알아요.
- 큰 작업은 동시 개발의 다른 부분에 영향을 주지 않게 격리할 수 있어요. Shopify에 기능별 테마가 있는 이유예요. 여러 작업을 주 코드에 합칠 때 문제가 없도록 Git에 기록해야 해요.
- 배포는 정해진 조건 안에서 해야 해요. 제품 책임자의 관점도 언젠가 시험받겠지만 큰 문제를 피하려면 팀이 배포 절차를 따르는 편이 안전해요.
- 공개 테마에 배포하기 전에 항상 스테이징 테마에서 기본 확인을 하세요.
작업 관리
여러 도구가 있으며 저는 Trello가 편해요. 다른 도구도 찾아볼 수 있지만 대부분 비슷한 역할을 해요.
모든 작업은 사이트 로드맵이 되는 정리된 백로그에서 시작해야 해요. 일관성과 정보 투명성이 필요하며 최소한 다음을 포함하세요.
- 작업 제목
- 작업 설명
- 완료로 판단할 조건
- 마감일
- 의존하거나 관련된 작업
- 예상 시간
마무리
사내 팀과 외주 중 고르기는 어려워요. 일부 판매자는 내부 팀이 일상적인 핵심 프로젝트를 맡고 복잡한 역량이 필요한 기능은 외주로 주는 혼합 방식을 택해요.
이렇게 하면 큰 위험 없이 더 많은 인재를 활용하고 고정비를 줄일 수 있어요. 다만 함께할 적절한 파트너를 고르는 것이 중요해요.
보편적인 정답은 없어요. 한 기업에 맞는 방식이 다른 기업에는 안 맞을 수 있어요. 요구와 자원을 평가하는 것부터 시작하세요.
