우리가 직접 만들어 운영하는 제품들: 여우비 포트폴리오 지도

개발사가 자기 제품을 직접 만드는 이유

개발사가 자기 제품을 만드는 이유는 실적 목록을 늘리기 위해서가 아닙니다. 고객 프로젝트는 납품 시점에 끝나지만 자기 제품은 출시가 시작점입니다. 판단이 틀렸을 때 그 비용을 스스로 치르는 자리에 서 봐야 생기는 감각이 있습니다. 여우비 인터랙션은 그 감각을 얻으려고 제품을 만들어 직접 운영합니다.

외주만 하는 팀은 늘 요구사항을 받는 쪽에 서 있습니다. 무엇을 만들지 정한 사람이 따로 있고, 그 결정이 빗나갔을 때 손실은 발주한 쪽이 떠안습니다. 개발팀은 사양대로 만들었다는 사실만으로 자기 몫을 다한 셈이 됩니다. 이 구조가 오래 이어지면 팀은 사양서를 읽는 능력은 좋아지지만 사양서에 적히지 않은 것을 미리 묻는 능력은 자라지 않습니다.

자기 제품은 그 구조를 뒤집습니다. 어떤 기능을 넣을지 결정한 사람과 그 결정의 대가를 치르는 사람이 같습니다. 앱스토어와 플레이스토어 심사에서 반려되는 일, 로케일을 하나 더 얹었더니 화면 절반이 깨지는 일, 사용자가 자기 데이터를 고쳐 달라고 요청했을 때 그 요청을 받아 처리하는 절차가 아예 없는 일. 이런 것들은 기획서에 적히지 않습니다. 겪어야 목록에 들어옵니다.

이 글은 여우비가 만들어 운영 중인 제품들을 세 갈래의 문제 영역으로 정리한 지도입니다. 반복되는 기록을 줄이는 쪽에 출결 관리 서비스 onSpots가 있고, 사람과 사람을 잇는 쪽에 한국어 학습 매칭 서비스 랭토리가 있으며, 시장의 정보 비대칭을 좁히는 쪽에 베트남 구인구직 서비스 Job Connect VN이 있습니다. 여기에 베트남 소상공인의 매장 운영과 디지털 전환을 돕는 위니가 더해집니다. 위니는 다룰 내용이 많아 별도의 글로 따로 정리했으니 이 글에서는 포트폴리오의 한 축으로만 언급합니다.

미리 밝혀 둘 것이 하나 있습니다. 이 글에는 사용자 수나 다운로드 수 같은 숫자가 나오지 않습니다. 자사 제품의 사용 지표는 계측 연동을 마치기 전이라 정확한 값이 존재하지 않고, 없는 숫자를 그럴듯하게 만들어 쓰는 일을 하지 않기 때문입니다. 대신 각 제품에서 어떤 결정을 왜 그렇게 내렸는지를 적었습니다. 개발 파트너를 고르는 자리에서 실제로 판별력이 있는 정보는 성과 숫자보다 판단의 근거 쪽이라고 봅니다.

반복되는 기록을 줄이는 쪽: 출결 관리에서 배운 것

출결 관리는 기능 목록만 보면 단순합니다. 출근을 찍고 퇴근을 찍으면 끝나는 것처럼 보입니다. 실제로 만들어 운영해 보면 제품의 성패는 기록 자체가 아니라 예외에서 갈립니다. 지각 판정, 재택 신청, 위치 조작, 급여 담당자에게 넘기는 마지막 단계가 그렇습니다.

onSpots는 사무실 지오펜스 안에서 한 번의 탭으로 출퇴근을 남기는 구조입니다. 관리자는 지금 누가 사무실에 있고 누가 늦었으며 누가 재택이고 누가 자리를 비웠는지를 한 화면에서 봅니다. 재택과 휴가 신청은 앱 안에서 올라오고 승인과 반려도 같은 자리에서 처리합니다. 전사 공지를 푸시로 내보낼 수 있고, 월 단위 CSV 내보내기로 급여 처리에 쓰는 근태 자료를 만듭니다. 한국어, 베트남어, 영어를 함께 지원합니다.

여기서 얻은 첫 번째 교훈은 규칙이 조직마다 다르다는 사실입니다. 출근 시각을 몇 시로 볼지, 몇 분까지를 지각으로 보지 않을지는 회사마다 다르게 운영합니다. onSpots는 지각과 정시를 자동으로 분류하되 그 판정에 쓰는 유예 시간을 조직이 직접 정하도록 열어 두었습니다. 이 부분을 상수로 박아 두었다면 두 번째 고객사에서 바로 깨졌을 것입니다. 사내 운영 도구에서 정책은 데이터여야지 코드여서는 안 됩니다.

두 번째는 기록이 판정과 이어져야 쓸모가 생긴다는 점입니다. 원시 로그를 아무리 정확히 쌓아도 급여를 계산하는 사람이 그것을 다시 손으로 정리해야 한다면 그 팀의 일은 줄지 않습니다. 오히려 확인할 화면이 하나 더 늘어난 셈입니다. 그래서 월 단위 내보내기를 부가 기능이 아니라 제품의 마지막 구간으로 두었습니다. 사내 도구의 가치는 화면의 완성도가 아니라 그 화면 다음에 남는 사람의 손일이 얼마나 사라졌는지로 재는 편이 정확합니다.

세 번째는 위치 조작을 다루는 방식입니다. 위치를 속이는 앱은 존재하고, 이를 탐지하는 것 자체는 어려운 문제가 아닙니다. 어려운 쪽은 탐지한 다음입니다. 자동으로 출근을 무효 처리하면 통신 환경이 나빠 좌표가 튄 사람까지 결근으로 몰립니다. onSpots는 의심되는 기록에 표시를 남겨 관리자에게 보여주는 쪽을 택했습니다. 기계가 판정하고 사람이 통보받는 구조가 아니라, 기계가 짚고 사람이 판단하는 구조입니다. 사람의 근태를 다루는 도구에서 이 차이는 신뢰의 문제로 직결됩니다.

네 번째는 다국어가 기능이 아니라 전제라는 점입니다. 한국과 베트남 양쪽에서 일하는 조직이라면 같은 회사 안에 서로 다른 언어를 쓰는 구성원이 섞여 있습니다. 언어 전환을 나중에 붙이는 옵션으로 두면 공지 문구, 승인 사유, 상태 라벨처럼 매일 읽히는 문장들이 하나씩 원래 언어로 남습니다. 처음부터 세 언어를 전제로 화면을 설계하는 것과 나중에 번역을 얹는 것은 완전히 다른 작업입니다.

사내 운영 도구를 발주하시는 담당자께 이 절에서 남길 말은 하나입니다. 사양서에 무엇을 기록할지만 적으면 절반만 적은 것입니다. 규칙에서 벗어난 상황이 생겼을 때 누가 무엇을 보고 무엇을 누르는지까지 적어야 실제로 쓰이는 도구가 나옵니다.

사람과 사람을 잇는 쪽: 학습 매칭에서 배운 것

학습 매칭에서 배운 것은 연결의 어려움이 검색이 아니라 조건 정렬에 있다는 점입니다. 랭토리는 한국어를 배우려는 사람과 가르치는 사람을 잇는 매칭 및 맵핑 서비스입니다. 여우비는 수업을 제공하지 않습니다. 가르치는 주체는 플랫폼에 참여하는 개인 교사와 기관이고, 저희가 만드는 것은 그들이 서로를 찾는 구조입니다.

랭토리에서는 학습자가 목적에 따라 선생님을 추립니다. 회화, 문법, TOPIK, 비즈니스, EPS-TOPIK 같은 목적별 분류가 있고, TOEIC과 IELTS, TOEFL, OPIc처럼 다른 언어 시험을 다루는 분류도 함께 있습니다. 지역과 수준과 학습 목표를 놓고 맞춰 보는 맞춤 매칭이 있으며, 수업은 온라인과 오프라인 양쪽으로 열립니다. 하노이나 타이응우옌 같은 지역 표기와 온라인 표기가 함께 노출되고, 잡힌 수업의 일정과 진도는 한 화면에서 관리합니다. 선생님은 자기 수업 페이지를 만들어 소셜에 공유할 수 있고, 프로필에는 학습자가 남긴 후기와 평점이 붙습니다. 한국어와 베트남어와 영어 로케일을 지원하며 주력은 베트남어입니다.

첫 번째로 배운 것은 양면 시장이 사실은 두 개의 제품이라는 사실입니다. 학습자에게 좋은 화면과 선생님에게 좋은 화면은 성공의 정의가 다릅니다. 학습자는 조건에 맞는 사람을 빨리 좁히고 싶어 하고, 선생님은 자기가 잘하는 것을 정확히 드러내고 싶어 합니다. 이 둘을 한 벌의 화면으로 처리하려고 하면 양쪽 다 어정쩡해집니다. 견적서에서는 한 프로젝트로 보이지만 설계에서는 두 프로젝트로 다뤄야 합니다.

두 번째는 필터가 UI 문제가 아니라 분류 체계 설계 문제라는 점입니다. TOPIK을 준비하는 학습자와 EPS-TOPIK을 준비하는 학습자는 목적도 다르고 필요한 선생님도 다릅니다. 이 둘을 한 칸에 묶으면 필터를 아무리 예쁘게 만들어도 매칭 품질이 무너집니다. 도메인을 이해하는 일이 화면을 그리는 일보다 앞선다는 뜻입니다. 개발 파트너가 그 도메인의 용어를 정확히 되묻지 않는다면 그것이 첫 번째 경고 신호입니다.

세 번째는 맵핑에 관한 것입니다. 온라인 수업이 가능하니 위치는 의미가 없을 것 같지만 실제로는 그렇지 않습니다. 대면 수업을 원하는 학습자에게는 이동 가능한 거리가 조건이고, 지역이 같으면 생활 시간대와 학습 목적이 비슷하게 겹치는 경향도 있습니다. 위치를 지운 매칭은 깔끔해 보이지만 사람들이 실제로 고를 때 쓰는 기준 하나를 없애 버립니다.

네 번째는 초기 공급을 다루는 방식입니다. 매칭 서비스는 한쪽이 비면 반대쪽 화면이 아무리 잘 만들어져도 빈 화면입니다. 랭토리는 플랫폼이 모든 공급을 직접 모아 온다는 전제를 버리고, 선생님이 자기 수업 페이지를 만들어 스스로 유통할 수 있는 장치를 넣었습니다. 각자가 자기 학습자를 데려오고 그 학습자가 다른 선생님도 보게 되는 흐름입니다. 완벽한 해법은 아니지만 초기 양면 시장에서 현실적으로 작동하는 방향입니다.

마켓플레이스나 매칭 서비스를 검토하시는 분께 드릴 말씀은 이것입니다. 사양서에 초기 공급을 어떻게 채울지가 적혀 있지 않다면, 기능이 전부 완성되어도 첫날 화면은 비어 있습니다. 이 항목은 마케팅 과제가 아니라 제품 설계 항목입니다.

정보 비대칭을 좁히는 쪽: 구인구직에서 배운 것

구인구직에서 좁히려 한 것은 정보 비대칭입니다. Job Connect VN은 한국어를 쓰는 베트남 인재와 기업을 잇는 베트남 시장 한정 서비스입니다. 공고를 모아 보여주는 데서 그치지 않고 지원자가 자기 지원이 지금 어디쯤 와 있는지 볼 수 있게 하는 데 무게를 두었습니다.

서비스는 공고를 모아 보는 채용 보드를 중심으로 돌아갑니다. 구직자는 프로필과 이력서를 자기 계정에 두고, 지원한 공고의 목록과 관심 있어 저장해 둔 공고를 따로 확인합니다. 인터페이스는 베트남어를 기준으로 만들었고 대상 시장도 베트남으로 한정했습니다.

첫 번째 교훈은 비대칭이 한 방향이 아니라는 것입니다. 구직자는 회사가 실제로 어떤 곳인지, 적은 조건이 그대로 지켜지는지 알기 어렵습니다. 기업은 지원자의 한국어 수준이 이력서에 적힌 그대로인지 확인할 방법이 마땅치 않습니다. 한쪽만 편하게 만들면 반대쪽이 빠져나가고, 결국 남는 쪽도 갈 곳을 잃습니다. 중개 서비스는 양쪽의 불신을 동시에 줄이는 설계여야 성립합니다.

두 번째는 지원 이후의 침묵이 사람을 떠나게 만든다는 점입니다. 지원 버튼을 누른 다음 아무 소식이 없는 상태가 길어지면 사람은 그 서비스를 다시 열지 않습니다. 지원 내역 화면은 겉보기에 부가 기능처럼 보이지만 실제로는 서비스가 신뢰를 유지하는 핵심 구간입니다. 결과가 좋지 않더라도 지금 어느 단계인지 보이는 것만으로 체감은 크게 달라집니다. 채용 서비스를 만들 때 이 화면을 나중 순위로 미루는 결정을 자주 보는데, 저희 판단으로는 순서가 뒤바뀐 것입니다.

세 번째는 시장을 한정한 것이 약점이 아니라 설계 조건이라는 점입니다. 이력서에 무엇을 적는지, 직무를 어떻게 나누는지, 어떤 자격이 실제 채용에서 통하는지는 시장마다 다릅니다. 처음부터 여러 나라를 한 번에 담으려고 했다면 어느 시장에도 맞지 않는 항목 구성이 나왔을 것입니다. 대상을 좁히면 항목을 그 시장의 관행에 맞춰 정확히 짤 수 있습니다. 범용성은 나중에 붙일 수 있지만 부정확한 항목 구성은 데이터가 쌓인 뒤에 고치기 어렵습니다.

네 번째는 이력서를 어떻게 담느냐가 이후 모든 것을 결정한다는 점입니다. 이력서를 파일 업로드로만 받으면 저장은 간단하지만 검색과 매칭에는 거의 쓸 수 없습니다. 항목을 구조화해 받으면 입력이 번거로워지는 대신 그 데이터로 할 수 있는 일이 늘어납니다. 어느 쪽을 택하든 그 결정은 첫 주에 내려지고 그 뒤 몇 년을 지배합니다. 개발 파트너가 이런 결정을 사소한 구현 선택으로 넘긴다면 나중에 비용이 크게 돌아옵니다.

채용이나 중개 성격의 서비스를 준비하시는 분께 남길 말은 이렇습니다. 공고를 등록하고 지원을 받는 기본 동작만으로 사양을 잡으면 대부분 원하는 결과가 나오지 않습니다. 양쪽이 서로를 믿게 만드는 장치가 사양서 안에 항목으로 들어가 있어야 합니다.

제품에서 배운 것이 고객 프로젝트로 돌아오는 길

자체 제품에서 남는 것은 재사용할 코드가 아니라 판단 기준입니다. 다국어를 처음부터 구조로 넣는 습관, 예외 상황을 사양 단계에서 먼저 묻는 습관, 출시 이후의 운영 부담을 견적에 반영하는 습관. 이 셋이 고객 프로젝트로 돌아옵니다.

다국어부터 보겠습니다. 세 제품 모두에서 한국어와 베트남어와 영어를 다루다 보니 문자열을 파일로 분리하는 수준의 대응으로는 부족하다는 것을 반복해서 확인했습니다. 날짜 표기 순서, 이름 표기 순서, 주소 입력 항목의 구성, 숫자와 통화 표기가 모두 언어마다 다릅니다. 서체도 그렇습니다. 베트남어 화면용으로 고른 서체에는 한글 글리프가 없어서 한국어가 섞이는 순간 글자가 깨집니다. Job Connect VN에서는 한글 폴백 서체를 따로 얹어 이 문제를 해결했습니다. 이런 항목은 하나하나는 사소하지만, 겪어 본 팀과 겪어 보지 않은 팀의 초기 설계는 눈에 띄게 다릅니다.

다음은 운영 부담입니다. 저희는 자사 제품의 스토어 배포와 심사 대응, 푸시 알림 발송, 사용자 문의와 데이터 정정 요청 처리를 직접 합니다. 이 일들에 실제로 얼마나 시간이 드는지 알고 있기 때문에 고객 프로젝트에서도 그 구간을 견적과 일정에 넣습니다. 개발이 끝나는 날과 서비스가 안정되는 날 사이에는 간격이 있고, 그 간격을 계산에서 빼놓으면 그 비용은 결국 어느 쪽이든 누군가가 예정에 없이 떠안게 됩니다.

세 번째는 질문의 방향입니다. 자기 제품을 운영해 본 팀은 요구사항을 받을 때 기능보다 먼저 예외를 묻습니다. 이 상태에서 사용자가 취소하면 어떻게 되는지, 승인하는 사람이 자리에 없으면 그 건은 어디에 쌓이는지, 잘못 들어간 데이터를 누가 어떤 화면에서 고치는지. 이런 질문은 초기 회의를 다소 길게 만들지만, 개발 중반에 사양을 다시 여는 일을 줄입니다. 자기 돈으로 그 대가를 치러 본 경험이 이 질문 목록을 만듭니다.

포트폴리오 전체를 놓고 보면 세 갈래는 결국 같은 축으로 모입니다. onSpots는 매일 반복되는 기록에서 사람의 손일을 덜어내고, 랭토리는 흩어진 개인들이 서로를 찾게 하고, Job Connect VN은 양쪽이 서로에 대해 아는 정도의 차이를 줄입니다. 여기에 베트남 소상공인의 매장 운영과 디지털 전환을 돕는 위니가 같은 계열의 운영 경험을 더합니다. 위니는 다룰 내용이 많아 별도의 글에서 따로 정리했습니다.

여우비 인터랙션은 한국과 베트남 두 지역에서 함께 일하는 개발 스튜디오입니다. 자체 제품을 만들어 직접 운영하면서 동시에 고객사 개발을 수행합니다. 이 두 가지를 같이 하는 이유는 한쪽에서 배운 것이 다른 쪽에서 곧바로 쓰이기 때문입니다.

마지막으로, 개발 파트너를 고르는 자리에 계신 담당자께 세 가지 질문을 제안합니다. 첫째, 직접 운영하는 서비스가 있다면 그 서비스에서 무엇이 틀렸다는 것을 알게 되었는지 물어보십시오. 잘된 이야기만 돌아온다면 실제로 운영하지 않고 있을 가능성이 큽니다. 둘째, 출시 이후 3개월 동안 누가 무엇을 하는지 물어보십시오. 이 답이 준비되어 있지 않은 견적은 반드시 나중에 늘어납니다. 셋째, 우리 도메인의 용어를 되묻는지 보십시오. 아무것도 되묻지 않고 바로 견적을 내미는 쪽보다, 분류와 예외를 캐묻는 쪽이 결국 덜 비쌉니다.