자체 제품을 운영해 본 팀은 외주를 어디서 다르게 하나

만들어 본 것과 만들어 준 것은 무엇이 다른가

개발 파트너를 고를 때 포트폴리오만 보면 한 가지가 빠집니다. 그 팀이 만든 결과물을 직접 운영해 봤는지 여부입니다. 납품과 검수로 끝난 프로젝트와, 배포 이후 몇 년을 계속 책임진 서비스는 팀에 남는 경험이 다릅니다. 달라지는 것은 코드 실력이 아니라 무엇을 위험으로 보느냐입니다. 이 차이는 견적서에도 제안서에도 잘 드러나지 않습니다. 그래서 발주자가 따로 물어야 합니다.

납품형 프로젝트의 성공 기준은 명확합니다. 합의한 범위를 기한 안에 넘기고 검수를 통과하면 됩니다. 이 기준 자체는 아무 문제가 없습니다. 다만 검수 도장이 찍히는 순간 관계가 끝나기 때문에, 그 뒤에 생기는 비용은 만든 팀의 학습으로 돌아오지 않습니다. 서버 요금이 왜 어느 달에 갑자기 뛰는지, 사용자가 어느 화면에서 멈춰 서서 전화를 거는지, 반년 뒤 라이브러리 하나가 지원을 끊었을 때 무엇이 같이 무너지는지를 겪지 않습니다.

자체 제품은 그 반대입니다. 배포가 끝이 아니라 시작입니다. 첫 버전을 올린 다음 날부터 스토어 심사 결과를 기다리고, 다음 주에는 특정 기기에서만 나는 오류를 재현하려 애쓰고, 그다음 달에는 아무도 안 쓰는 기능 때문에 지불하고 있던 비용을 발견합니다. 이 과정은 즐겁지 않지만 정직합니다. 설계 단계에서 편하자고 미뤄 둔 결정이 몇 달 뒤에 청구서로 되돌아오는 것을 팀이 자기 돈과 자기 시간으로 겪습니다.

여우비 인터랙션은 고객사 개발과 자체 제품을 나란히 합니다. onSpots는 출결 관리 서비스이고 다국어를 지원하며 특정 국가에 한정되지 않습니다. 랭토리는 한국어를 배우려는 사람과 가르치는 사람을 잇는 매칭 및 맵핑 서비스로, 한국어와 베트남어와 영어 로케일을 지원합니다. 교육의 주체는 플랫폼에 참여하는 개인 교사와 기관이고, 저희는 그 연결을 만드는 쪽입니다. Job Connect VN은 베트남 시장을 대상으로 한 구인구직 서비스입니다. 소상공인 매장 운영을 다루는 위니도 있습니다.

이 제품들의 이용자 수나 리텐션 같은 지표는 여기에 적지 않습니다. 계측을 제대로 붙이기 전이라 저희 손에 아직 그 숫자가 없습니다. 없는 숫자를 그럴듯하게 만들어 적는 순간, 검증 기준을 이야기하겠다는 이 글 자체가 무너집니다. 대신 확인 가능한 사실만 남깁니다. 만들었고, 스토어와 웹에 올려 두었고, 지금도 저희가 직접 돌보고 있습니다.

오해를 막기 위해 한 줄 덧붙입니다. 자체 제품이 있는 팀이 그렇지 않은 팀보다 낫다는 단정을 하려는 것이 아닙니다. 수탁 개발만 오래 해 온 회사 중에도 설계와 인수인계를 훌륭하게 해내는 곳이 많습니다. 운영 경험은 우열이 아니라 다른 근육에 가깝고, 그 근육이 특별히 중요해지는 프로젝트가 따로 있습니다. 한 번 열고 닫을 캠페인 페이지라면 별로 상관없습니다. 반대로 회사의 업무가 매일 그 위에서 돌아갈 시스템이라면, 만든 사람이 운영의 무게를 아는지가 3년치 비용을 가릅니다.

직접 운영해 봐야 보이는 비용: 배포, 장애, 문의 대응

견적서에는 화면 수와 기능 수가 적힙니다. 정작 서비스가 시작된 뒤 매달 나가는 비용은 다른 곳에서 발생합니다. 배포와 심사, 장애 대응, 사용자 문의 처리입니다. 이 셋은 개발 공수로 환산되지 않아서 제안 단계에서 통째로 빠지기 쉽습니다. 운영을 겪어 본 팀은 여기를 먼저 이야기합니다.

배포부터 봅니다. 앱이 포함된 프로젝트라면 스토어 심사가 일정에 들어와야 합니다. 심사는 통과할 때도 있고 반려될 때도 있으며, 반려 사유가 기능이 아니라 설명 문구나 스크린샷이나 권한 안내인 경우도 흔합니다. 다국어 앱이면 이 자료를 언어별로 다시 준비해야 합니다. 여기까지가 개발이 끝난 다음의 일입니다. 저희가 스토어에 올린 제품들을 운영하면서 얻은 실질적 소득 중 하나는, 일정표에 심사 왕복 기간을 처음부터 넣어 두는 습관입니다.

배포는 한 번으로 끝나지도 않습니다. 웹은 고치면 그날 반영되지만 앱은 사용자 기기에 남아 있습니다. 구버전을 쓰는 사람이 계속 남고, 서버는 한동안 옛 버전과 새 버전을 동시에 상대해야 합니다. 언제 강제 업데이트를 걸지, 이전 버전 응답을 언제까지 유지할지는 개발 취향이 아니라 사업 결정입니다. 이 결정을 겪어 본 팀은 계약 전에 그 이야기를 꺼냅니다.

장애 대응은 질문 몇 개로 파트너의 준비 상태가 드러나는 영역입니다. 새벽에 서비스가 멎으면 누가 먼저 압니까. 알림은 어디로 갑니까. 되돌릴 수 있는 지점이 있습니까. 무엇이 잘못됐는지 사후에 확인할 로그가 남습니까. 이 질문들에 구체적으로 답하지 못하는 제안서는 대개 배포 이후를 상상해 본 적이 없다는 뜻입니다. 반대로 감시 도구와 알림 경로와 복구 절차를 항목으로 적어 오는 제안서는, 그 팀이 최소 한 번은 새벽에 깨어 본 적이 있다는 신호에 가깝습니다.

문의 대응은 가장 과소평가되는 비용입니다. 실제로 들어오는 문의의 상당수는 오류가 아닙니다. 어디를 눌러야 할지 몰라서, 안내 문구가 애매해서, 결과가 언제 반영되는지 알 수 없어서 사람이 묻습니다. 운영을 해 보면 이 문의가 개발팀에 대한 고발장처럼 읽힙니다. 같은 질문이 열 번 들어오면 그 화면은 잘못 만들어진 것입니다. 이 감각은 문의 창구를 직접 받아 본 팀에만 생깁니다. 문의를 고객사가 전부 받고 개발사는 티켓만 받는 구조에서는 잘 자라지 않습니다.

베트남과 한국을 함께 상대하는 서비스라면 문의 대응에 언어와 시차가 얹힙니다. 같은 기능이라도 한국 담당자가 묻는 방식과 베트남 사용자가 묻는 방식이 다르고, 답변을 두 언어로 준비해야 합니다. 저희가 두 지역에서 함께 일하는 구조를 유지하는 이유 중 하나가 여기 있습니다. 번역을 한 단계 더 거치면 그만큼 대응이 늦어지고, 늦어진 대응은 대부분 불만으로 바뀝니다.

발주자 입장에서 실행할 수 있는 방법은 간단합니다. 제안 요청에 운영을 명시적으로 넣는 것입니다. 배포와 심사 일정, 장애 시 연락 체계와 대응 시간, 문의 1차 접수 주체와 에스컬레이션 경로를 적어 달라고 요구하십시오. 여기에 성실하게 답하는 팀과 개발 공수만 적어 오는 팀은 첫 장에서 갈립니다.

요구사항을 줄이는 대화가 가능해지는 이유

좋은 파트너를 가르는 신호 하나는 첫 미팅에서 나옵니다. 기능을 더 넣자고 하는지, 빼자고 하는지입니다. 운영을 해 본 팀은 기능 하나가 일회성 개발비가 아니라 서비스가 살아 있는 내내 따라오는 고정비라는 사실을 몸으로 압니다. 그래서 줄이자는 말을 먼저 꺼냅니다.

기능 하나를 추가하면 개발 시간만 늘어나는 것이 아닙니다. 테스트해야 할 경우의 수가 늘고, 번역해야 할 문구가 늘고, 문의가 들어올 지점이 늘고, 다음에 무언가를 고칠 때 확인해야 할 범위가 늘어납니다. 다국어 서비스라면 문구 하나가 세 배로 불어납니다. 이 증가분은 첫 청구서에 안 잡히고 2년에 걸쳐 나눠 청구됩니다.

그런데 발주 자리에서 무언가를 빼자고 말하기는 쉽지 않습니다. 다 해 드리겠다는 답이 협상에서 훨씬 편하기 때문입니다. 요청을 그대로 받아 견적을 키우면 당장의 수주 확률과 계약 금액이 같이 올라갑니다. 문제는 그 계약이 만들어 낸 물건을 나중에 누가 감당하느냐입니다. 자기 제품을 운영해 본 팀은 그 뒷감당을 자기가 해 본 적이 있어서, 요구사항 목록을 볼 때 총량을 먼저 셉니다.

저희 경우 랭토리에서 이 결정을 반복했습니다. 한국어 학습이라는 영역은 손댈 수 있는 범위가 넓습니다. 커리큘럼, 진도 관리, 콘텐츠 제작, 결제와 정산까지 얼마든지 뻗어 나갈 수 있습니다. 저희는 범위를 배우려는 사람과 가르치는 사람을 잇는 매칭과 맵핑으로 좁혔습니다. 교육 자체는 플랫폼에 참여하는 개인 교사와 기관이 맡습니다. 선을 그은 이유는 겸손이 아니라 운영 판단입니다. 넓게 잡을수록 유지해야 할 표면이 넓어지고, 표면이 넓어질수록 어느 것도 제대로 돌보지 못하게 됩니다.

발주자가 이 태도를 확인하는 방법은 어렵지 않습니다. 요구사항 목록을 건네고, 이 중에서 1차 범위에서 빼도 되는 항목이 있는지, 있다면 왜인지 물어보십시오. 답은 세 갈래로 나옵니다. 전부 필요하다고 하는 팀, 근거 없이 아무거나 빼자고 하는 팀, 그리고 어떤 기능이 어떤 후속 비용을 만드는지 설명하며 순서를 다시 짜자고 하는 팀입니다. 세 번째 답이 나온다면 그 팀은 최소한 배포 이후를 상상해 본 적이 있습니다.

한 가지 더 확인할 것은 뺀 것을 언제 다시 넣을지에 대한 계획입니다. 줄이자는 말이 그냥 안 하겠다는 말이면 곤란합니다. 1차에서 무엇을 내고, 실제 사용 데이터를 보고 무엇을 판단하고, 2차에서 무엇을 넣을지가 같이 나와야 제안으로서 성립합니다. 첫 버전을 작게 내는 이유는 돈을 아끼기 위해서가 아니라, 추측으로 만든 기능과 사용자가 실제로 필요로 하는 기능을 구별하기 위해서입니다.

이 대화가 성립하려면 발주자 쪽도 준비가 필요합니다. 기능 목록이 아니라 해결하려는 문제를 먼저 주면 파트너가 대안을 제시할 여지가 생깁니다. 화면 스무 개를 지정해 견적을 받으면 돌아오는 것은 화면 스무 개의 가격표뿐입니다. 이 업무의 병목이 어디이고 하루에 몇 명이 어떤 순서로 처리하는지를 설명하면, 화면 열두 개로 같은 일이 되는 안이 나올 수 있습니다.

유지보수를 전제로 설계하는 습관

유지보수를 전제한 설계는 코드가 예쁘다는 뜻이 아닙니다. 이 시스템을 나중에 다른 사람이 넘겨받아 고칠 수 있는가라는 질문이 설계 단계에 들어가 있느냐의 문제입니다. 여기에는 환경 분리, 설정 외부화, 변경 이력, 로그, 문서, 그리고 계정 소유권까지 포함됩니다. 발주자가 계약서에서 직접 확인할 수 있는 항목입니다.

가장 먼저 볼 것은 환경입니다. 개발용과 운영용이 분리되어 있는지, 운영 데이터를 가지고 테스트하지 않는지, 배포가 사람 손으로 파일을 올리는 방식인지 자동화되어 있는지를 묻습니다. 초기 서비스에 지나치게 복잡한 환경 구성을 요구할 필요는 없습니다. 다만 최소한 개발과 운영이 나뉘어 있고 되돌릴 수 있는 배포 절차가 있어야 합니다.

설정이 코드에 박혀 있는지도 확인할 지점입니다. 접속 정보, 외부 서비스 키, 기능 켜고 끄는 값이 소스 안에 하드코딩되어 있으면 값을 바꿀 때마다 개발자와 배포가 필요합니다. 문구도 마찬가지입니다. 화면에 나오는 문장이 코드에 직접 적혀 있으면 언어를 하나 추가할 때 전체를 다시 손봐야 합니다. onSpots를 다국어로 운영하면서 저희가 처음부터 지킨 원칙이 이것입니다. 문구는 코드 밖에 있어야 하고, 새 언어를 붙이는 일이 개발 프로젝트가 되어서는 안 됩니다.

지역을 넘나드는 서비스라면 확인할 것이 더 있습니다. 시간을 저장할 때 표준시로 저장하고 보여줄 때 지역 시간으로 바꾸는지, 날짜 표기와 이름 표기 순서가 지역에 따라 달라질 수 있는지, 통화와 세금 표기가 나라마다 다르게 처리되는지입니다. 한국과 베트남을 함께 상대하는 시스템에서는 이 부분이 나중에 가장 아프게 돌아옵니다. Job Connect VN처럼 처음부터 베트남 시장 한 곳을 대상으로 정한 제품과, onSpots처럼 여러 지역을 상정한 제품은 이 지점에서 설계가 갈립니다. 어느 쪽이 옳다는 것이 아니라, 어느 쪽인지 정하고 시작했느냐가 중요합니다.

기록도 봅니다. 데이터베이스 구조를 바꾼 이력이 파일로 남아 있는지, 왜 그렇게 바꿨는지 설명이 있는지, 새로 합류한 사람이 반나절 안에 환경을 띄울 수 있는 안내가 있는지 확인하십시오. 인수인계 문서를 프로젝트 종료 시점에 몰아서 쓰겠다는 답은 좋지 않은 신호입니다. 그때 쓰는 문서는 대개 목차만 있습니다.

마지막이 실질적으로 가장 중요합니다. 소유권입니다. 소스 저장소, 도메인, 스토어 개발자 계정, 클라우드 계정, 외부 서비스 계정이 각각 누구 명의인지 계약 전에 문서로 정해야 합니다. 개발 품질과 무관하게, 계정이 개발사 명의로 되어 있으면 나중에 파트너를 바꾸는 일이 기술 문제가 아니라 협상 문제가 됩니다. 이건 파트너를 의심하라는 말이 아니라 양쪽 모두를 보호하는 절차입니다. 저희가 파트너십으로 일할 때도 계약 주체와 계정 주체를 문서로 먼저 맞추고 시작합니다.

정리하면 이렇습니다. 유지보수를 전제로 설계했는지는 추상적인 신뢰의 문제가 아니라 확인 가능한 항목의 목록입니다. 환경 분리, 설정 분리, 문구 분리, 변경 이력, 로그와 감시, 인수인계 문서, 계정 소유권. 이 일곱 개를 제안서와 계약서에서 확인하면 됩니다.

고객이 밖에서 확인할 수 있는 신호는 무엇인가

여기까지의 기준은 파트너의 말을 듣고 판단하는 것이었습니다. 마지막은 말을 듣지 않고도 확인할 수 있는 것들입니다. 공개된 제품, 스토어 기록, 문서, 그리고 제안서에서 무엇을 빼자고 하는지입니다. 이 절차는 특정 회사를 위한 것이 아니라 후보 전부에게 똑같이 적용하는 것이 맞습니다.

첫째, 자체 제품이 있다고 말하는 팀이라면 그 제품을 직접 열어 보십시오. 링크가 살아 있는지, 회원 가입이 실제로 되는지, 오류 없이 첫 화면을 지나가는지 확인하면 됩니다. 데모 영상만 있고 접속할 곳이 없다면 그 제품은 아직 운영 중인 물건이 아닙니다. 저희 것도 그렇게 보시면 됩니다. onspots.app, www.langtori.com, www.jobconnectvn.com이 공개되어 있습니다.

둘째, 앱이라면 스토어 페이지의 업데이트 이력을 보십시오. 마지막 업데이트가 언제인지, 버전이 이어져 있는지, 변경 내역에 실제 내용이 적혀 있는지가 드러납니다. 한 번 올리고 방치된 앱과 계속 손보고 있는 앱은 이력만 봐도 구분됩니다. 이건 홍보 문구로 조작하기 어려운 기록입니다.

셋째, 다국어를 지원한다고 적힌 제품이라면 언어를 실제로 바꿔 보십시오. 전환 후에도 번역이 빠진 화면이 있는지, 날짜와 숫자 표기가 그 언어에 맞는지, 문장이 잘려 나가는 곳이 없는지 보면 됩니다. 다국어는 선언하기는 쉽고 유지하기는 번거로운 항목이라 팀의 성실함이 잘 드러납니다.

넷째, 개인정보 처리방침과 문의 창구가 실재하는지 확인하십시오. 링크가 걸려 있는지가 아니라 열리는지, 그리고 문의 주소로 실제로 답이 오는지입니다. 후보 업체의 자체 제품 문의 창구에 질문 하나를 보내 보는 것은 비용이 거의 들지 않는 검증입니다. 그 팀이 자기 사용자를 어떻게 대하는지가 곧 당신의 사용자를 어떻게 대할지에 대한 예고입니다.

다섯째, 제안서에서 빼자는 말이 나오는지 보십시오. 앞 섹션에서 다룬 그대로입니다. 요구사항 전부를 그대로 받아 적은 제안서보다, 순서를 다시 짜고 근거를 붙인 제안서가 대체로 운영을 겪은 팀에서 나옵니다.

여섯째, 계약 문서에서 인수인계와 계정 소유권 조항을 찾아보십시오. 이 조항이 없다면 넣어 달라고 요청하고, 요청에 어떻게 반응하는지 보십시오. 반응 자체가 정보입니다. 조항을 넣는 데 저항이 없는 팀은 나중에 넘겨줄 것을 전제하고 일하는 팀입니다.

마지막으로 한 가지를 덧붙입니다. 화려한 숫자를 앞세우는 제안일수록 그 숫자의 출처를 물어보십시오. 이 글에서 저희 제품의 이용 지표를 한 번도 쓰지 않은 이유가 그것입니다. 계측을 붙이기 전이라 저희에게 그 숫자가 없고, 없는 숫자를 쓰면 지금 말한 기준을 저희 스스로 어기는 셈이 됩니다. 파트너를 고르는 자리에서 검증 가능한 것과 검증 불가능한 것을 나누는 습관은, 그 프로젝트가 끝난 뒤에도 오래 쓰입니다.

여우비 인터랙션은 한국과 베트남 두 지역에서 함께 일하면서 고객사 개발과 자체 제품 운영을 병행합니다. 이 글이 저희를 고르는 근거가 되기를 바라고 쓴 것은 아닙니다. 위 여섯 가지를 후보 전부에게 똑같이 적용해 보시고, 그중에 저희가 남는다면 이야기를 이어 가면 됩니다.