여우비 Software Labs 역량 지도: 웹·모바일·사내SW 풀스택

외부 개발팀을 찾을 때 진짜 물어야 할 질문은 "이 회사가 잘하느냐"가 아닙니다. 더 정확한 질문은 "내 일이 이 팀이 잘하는 영역 안에 들어오느냐, 아니면 가장자리로 비껴나느냐"입니다. 이 글은 여우비의 Software Labs 역량을 바로 그 방식으로 지도처럼 그립니다. 세 갈래 작업 영역을 두고, 각 영역마다 어디까지 맡길 수 있는지, 그리고 그 못지않게 중요한, 어디서 멈추는지를 솔직히 적습니다. Software Labs는 회사의 전문 소프트웨어 개발 영역을 가리키는 내부 사업구분명이지 별도 브랜드가 아닙니다.

세 영역을 한 그림에 놓고 보기

Software Labs는 세 갈래 일을 합니다. 기업용 웹사이트, 모바일 앱, 그리고 회사 안에서 쓰는 사내 소프트웨어입니다. 이 셋은 기술적 뿌리를 공유하기 때문에 한 프로젝트가 한 영역에서 시작해 다른 영역으로 번져도 팀을 바꿀 필요가 없습니다. 여기서 말하는 풀스택은 그런 뜻입니다. "모든 걸 다 안다"가 아니라, 한 팀이 화면에서 데이터까지 하나의 흐름 안에서 갈 수 있다는 뜻입니다.

쓸모 있게 떠올리는 방법은 세 영역을 한 축 위에 놓는 것입니다. 그 축은 최종 사용자에서 내부 시스템까지의 거리입니다. 웹사이트는 외부 고객에게 가장 가깝습니다. 누구나 보기 때문에 모양과 로딩 속도가 중요합니다. 모바일 앱은 한 걸음 더 안으로 들어가 기기와 일상 사용 습관에 붙습니다. 사내 소프트웨어는 반대쪽 끝에 있어 보는 사람은 적지만 직원의 업무 흐름에 곧바로 닿습니다.

세 영역을 한 팀으로 묶는 강점은 이음새에 있습니다. 한 가게가 판매용 웹사이트, 단골용 앱, 그리고 주문을 관리하는 사내 도구를 가졌다면, 보통 이 셋은 같은 데이터 창고를 통해 서로 말을 주고받아야 합니다. 같은 팀이 맡으면 그 이음새가 두 업체 사이의 빈틈으로 떨어지지 않습니다. 많은 중소기업이 일을 쪼개기보다 한 창구를 택하는 실질적 이유가 여기 있습니다.

물론 묶었다고 모든 일이 다 맞는 건 아닙니다. 수십 명이 여러 해 동안 병렬로 붙어야 하는 아주 큰 프로젝트는 작은 팀의 무대가 아닙니다. 이 지도는 모든 일을 맡겨야 한다고 말하려는 게 아니라, 일을 제자리에 놓도록 그린 것입니다.

웹 개발: 어디까지 맡기는 게 합리적인가

웹 영역은 기업 소개 페이지, 캠페인 랜딩 페이지부터 콘텐츠 관리와 사용자 계정이 있는 시스템까지 통째로 받습니다. 짧게 말하면, 중소기업이 운영을 위해 실제로 필요로 하는 웹사이트나 웹 애플리케이션이라면 대부분 가능 범위에 들어옵니다. 진짜 한계는 페이지 종류가 아니라 극단적으로 큰 규모와 특수 인프라 요구에 있습니다.

실무에서 웹 프로젝트는 보통 몇 개의 층으로 나뉩니다. 첫 층은 보여주는 페이지입니다. 회사, 제품, 소식 소개죠. 이 층은 빠르고 명료하며, 핵심 가치는 깔끔한 디자인과 속도에 있습니다. 둘째 층은 콘텐츠가 움직이는 페이지입니다. 블로그, 제품 목록, 다국어 페이지가 여기 들어갑니다. 이쯤부터는 기술을 모르는 사람도 스스로 갱신할 수 있게 콘텐츠 관리 체계가 필요해집니다. 셋째 층은 로그인이 있고, 사용자 역할이 있고, 시간이 지나며 쌓이는 데이터가 있는 웹 애플리케이션입니다. 예약 페이지, 고객 포털, 관리자 대시보드 같은 것들입니다.

웹을 외부 팀에 맡기는 일은 요구사항을 특정 기술이 아니라 원하는 결과로 설명할 때 가장 합리적으로 굴러갑니다. "고객이 양식을 작성하면 영업팀이 바로 알림을 받게 해 달라"는 좋은 요구입니다. "꼭 X 프레임워크를 써 달라"는 보통 기술팀이 제안하도록 두는 편이 낫습니다. 옛 시스템에서 오는 실제 제약이 있는 경우가 아니라면요.

솔직히 말해 둘 영역도 있습니다. 아주 큰 트래픽을 감당하는 성능, 예컨대 하루 수백만 방문이 몰리는 전국 규모 전자상거래 플랫폼은 별도의 인프라 문제입니다. 장기 운영 약속과 시스템 상시 대응 인력이 필요합니다. 개발팀은 그 규모의 구축과 초반은 해낼 수 있지만, 최고 부하 지점에서의 운영은 처음부터 논의해야 할 주제이지 당연히 되는 것으로 가정해선 안 됩니다.

모바일 앱: 직접 개발과 현지 퍼블리싱의 경계

모바일 영역은 두 주요 운영체제용 앱을 화면 설계부터 뒤쪽 데이터 연결까지 만들 수 있습니다. 구분해야 할 경계는 앱을 만드는 일이 아니라, 앱을 시장에 내놓고 돈을 받는 일에 있습니다. 베트남에서는 앱 스토어를 통한 일부 직접 과금 모델이 자체적인 법적·결제 장벽을 가지므로, 퍼블리싱 부분이 현지 파트너를 거치는 경우가 있습니다.

앱을 짓는 부분은 비교적 분명합니다. 앱은 보통 여러 화면, 로그인 층, 데이터를 가져오고 저장하기 위한 서버 연결, 때로 푸시 알림이나 지도 같은 기능으로 이뤄집니다. 당신의 앱이 이 묶음 안에 들어온다면, 명확한 주기 안에 지어지는 일입니다. 더 어려운 건 코드가 아니라 범위 결정입니다. 첫 버전에서 모든 걸 다 하려는 앱은 대개 늦어지고 비싸집니다. 좁게 시작해 넓혀 가는 편이 훨씬 안전합니다.

분명히 짚어야 할 지점은 상업적 운영입니다. 앱이 사용자에게 정기적으로 요금을 매기거나 국내 자금 흐름을 처리해야 할 때, 돈을 받는 명의 주체이자 법적 책임을 지는 쪽은 보통 개발팀이 아닙니다. 실무에서 자주 쓰는 모델은 개발팀이 기술 부분을 맡고, 현지 사업체나 개인 사업자가 과금 주체로 나서 수익을 나누는 구조입니다. 이는 기술 역량의 한계가 아니라 현지 규정을 지키기 위한 사업 구조입니다.

그래서 앱을 맡길지 고민한다면 일찍 물어야 할 질문은 이렇습니다. 누가 앱 스토어에 이름을 올릴 것인가, 누가 돈을 받을 것인가, 자금은 어디를 통해 흐르는가. 이 셋을 처음에 답해 두면 앱이 기술적으로는 끝났는데 과금 모델에 걸려 출시를 못 하는 상황을 피할 수 있습니다. 기술 부분과 퍼블리싱 부분은 순차가 아니라 나란히 계획해야 합니다.

사내 업무 소프트웨어: 회사 안에서 굴러가는 도구

사내 소프트웨어 영역은 외부 고객이 보는 게 아니라 직원이 운영에 쓰는 도구를 만듭니다. 주문 관리 시스템, 업무 추적 보드, 사내 계산 도구, 데이터 입력 포털 같은 것들입니다. 흔히 가볍게 보는 영역이지만 이득이 가장 또렷한 곳이기도 합니다. 매일 시간을 잡아먹는 수작업 스프레드시트와 손으로 하는 단계들을 대체하기 때문입니다.

사내 소프트웨어의 특징은 회사가 실제로 일하는 방식에 맞아야 한다는 점입니다. 일반 템플릿이 가정하는 방식이 아니라요. 빵집의 주문 관리 도구는 기계 공장의 그것과 다릅니다. 둘 다 "주문 관리"라 불려도요. 그래서 이런 프로젝트에서 가장 중요한 부분은 프로그래밍이 아니라, 초반에 앉아서 현재 흐름을 적어 내려가는 단계입니다. 어떤 단계가 지금 수작업인지, 어디서 자주 틀리는지, 어느 단계를 누가 책임지는지를요.

세 영역을 한 팀으로 쓰는 이득이 여기서 가장 또렷합니다. 사내 도구가 판매 웹사이트에서 데이터를 가져와야 하거나, 고객용 앱으로 정보를 밀어 넣어야 할 때, 그 연결 부분이 이미 팀의 손안에 있습니다. 기업이 서로의 시스템을 모르는 두 업체 사이에서 통역 노릇을 할 필요가 없습니다. 조용하지만 관리 시간에서 꽤 큰 절약입니다.

솔직히 말할 한계도 여기 있습니다. 일부 사내 소프트웨어는 업종에 깊이 특화된 종류입니다. 예를 들어 보고 기준을 온전히 따르는 완전한 회계 시스템이나, 분야별 별도 인증 요건이 있는 소프트웨어죠. 그런 경우엔 처음부터 직접 짓기보다 이미 검증된 기성 제품을 쓰는 편이 합리적인 경우가 많습니다. 좋은 개발팀은 언제 짓기보다 사야 하는지 말해 줍니다. 일거리를 위해 모든 일을 받지 않습니다.

맡기기 전에: 알아두면 좋은 한계와 협업 전제

어떤 프로젝트든 맡기기 전에 분명히 해 둘 세 가지는 첫 버전의 실제 범위, 당신 쪽 의사결정자가 누구인지, 그리고 인수인계 이후 유지보수가 어떻게 굴러가는지입니다. 작은 팀은 범위가 분명하고 결정권자가 안정적일 때 잘합니다. 요구가 끊임없이 바뀌거나 고객 쪽에서 아무도 결정을 못 내릴 때 어려워집니다.

첫째 한계는 팀 규모입니다. 군더더기 없는 개발팀은 수백 명짜리 회사가 아닙니다. 그 말은 큰 프로젝트 열 개를 동시에 굴릴 수 없다는 뜻이고, 밤낮으로 시스템 상시 인력이 붙어야 하는 프로젝트는 운영 조건을 따로 논의해야 한다는 뜻입니다. 대신 작은 팀은 더 직접적으로 소통하고, 중간 단계가 적고, 실제 만드는 사람이 당신이 말 섞는 사람입니다. 대다수 중소기업 프로젝트에는 이득이 되는 맞바꿈입니다.

둘째 한계는 데이터와 소유에 관한 것입니다. 인수인계 후 소스 코드를 누가 소유하는지, 데이터가 어디에 보관되는지, 당신이 직접 운영을 이어 갈 수 있는지 아니면 개발팀에 의존하는지를 처음부터 합의해야 합니다. 건강한 협업은 당신이 단단히 묶이지 않는 협업입니다. 자기 코드와 데이터는 되찾을 권리가 있어야 합니다. 끝난 뒤가 아니라 계약 전에 이걸 똑바로 물으십시오.

마지막 협업 전제는 일하는 리듬입니다. 좋은 소프트웨어 개발은 고객 쪽에서 꾸준한 피드백을 필요로 합니다. 과제를 던지고 석 달간 사라지는 게 아니라요. 성공하는 프로젝트엔 보통 고객 쪽에 시안을 봐 주고, 질문에 답하고, 필요할 때 빠르게 결정해 주는 한 사람이 있습니다. 이 역할을 준비할 수 있다면, 외주 프로젝트 위험의 큰 부분은 첫 줄 코드를 쓰기도 전에 이미 해결된 셈입니다. 역량 지도는 무엇이 가능한지만 알려 줍니다. 그 일이 잘 굴러가느냐는 두 쪽 사이의 명료함에 더 많이 달려 있습니다.