토리토시스템 토리토시스템

개발사와 미팅을 하다 보면 자주 듣는 말이 있습니다. 비슷한 서비스를 이미 운영하고 있으니, 그걸 조금 고치면 금방 만들어 드릴 수 있다는 말입니다.처음부터 만드는 것보다 기간도 짧고 비용도 적게 들 것 같습니다. 그래서 많은 의뢰자분들이 이 제안을 고르십니다. 저희가 넘겨받은 한 플랫폼도 출발은 같았습니다.그 플랫폼은 뉴욕의 한 개발사가 2년 동안 고쳐 가며 만들었지만 완성되지 않았습니다. 저희는 이를 넘겨받아 처음부터 새로 만들었고, 3개월 만에 오픈했습니다.이 글에서는 그 2년이 왜 길어졌는지, 그리고 3개월 안에 마칠 수 있었던 이유가 무엇이었는지 차례대로 정리해 드리겠습니다. 기존 솔루션을 고쳐 쓸지 고민하시는 분들께 판단 기준이 되실 겁니다. 비슷한 플랫폼이 있으니 금방 된다고 했습니다의뢰하신..

견적서에 찍힌 금액은 앱을 세상에 내놓기까지의 값입니다. 정작 출시 버튼을 누른 다음부터 매달 조용히 빠져나가는 돈이 따로 생기는데, 그 가운데 덩치가 가장 큰 것이 서버 비용입니다.여기를 미리 계산해 두지 않으시면 출시 이듬달 청구서 앞에서 당황하시게 됩니다. 게다가 이 비용은 사용자가 늘수록 같이 오르는 구조라, 서비스가 잘될수록 나가는 돈도 커집니다.먼저 답을 드리면, 서버 비용은 매달 같은 금액이 나가는 고정비가 아니라 쓴 만큼 따라 움직이는 변동비입니다. 아래에서 어떤 항목에 얼마가 붙는지, 규모가 커지면 어떻게 뛰는지, 그리고 어디를 손봐야 실제로 줄어드는지 짚어 드리겠습니다. 청구서는 이 여섯 줄로 나뉩니다항목 구분을 알고 계시면 청구서가 그냥 숫자 덩어리로 안 보입니다.서버(컴퓨팅) — 프..

견적서 한 장을 받아 들고 맨 아래 총액만 한참 들여다보신 경험, 아마 있으실 겁니다. 숫자는 분명한데 그 위에 줄줄이 적힌 항목이 무엇을 뜻하는지, 이 값이 비싼 건지 싼 건지 가늠할 잣대가 없으니 답답해집니다.그래서 보통 두세 군데에 같은 내용을 보내고 총액을 줄 세워 보시는데, 여기서 또 한 번 당황하십니다. 분명 같은 요청을 했는데 어느 곳은 다른 곳의 두 배, 세 배를 부르기 때문입니다.이 간극은 대부분 업체들이 서로 다른 것을 견적했기 때문에 생깁니다. 오늘은 앱 개발 견적서가 어떤 뼈대로 짜이는지, 항목 하나하나에서 무엇을 짚어야 하는지, 그리고 여러 장을 놓고 비교할 때 어디부터 맞춰봐야 하는지 순서대로 풀어 드리겠습니다. 견적의 본질은 인력의 시간입니다항목을 보기 전에 이 한 가지만 머릿..

세 군데서 견적을 받았는데 숫자가 전부 다릅니다앱 개발을 처음 알아보시는 분들이 가장 먼저 마주하는 난관이 앱개발비용입니다. 똑같은 기획서를 세 군데 업체에 보냈는데 어떤 곳은 2천만 원, 어떤 곳은 4천만 원, 또 어떤 곳은 8천만 원을 제시하는 상황이 실제로 심심치 않게 벌어집니다.이렇게 업체마다 금액이 크게 벌어지면 의뢰자 입장에서는 어느 숫자를 믿어야 할지 기준이 서지 않습니다. 저렴한 곳은 무언가 빠뜨린 것 같아 불안하고, 비싼 곳은 과하게 부른 것 같아 미심쩍고, 결국 느낌으로 선택하게 되는 경우가 많습니다.그래서 오늘은 앱개발견적이 어떤 계산 과정을 거쳐 만들어지는지, 그 산정 구조를 처음부터 끝까지 풀어드리려 합니다. 이 구조를 알고 나면 견적서에 적힌 숫자가 어디에서 나온 것인지 스스로 ..

서명은 3분, 후회는 6개월외주 계약 자리를 여러 번 지켜보면 비슷한 흐름이 보입니다. 금액과 기간은 몇 번씩 되짚어 물으시는데, 정작 계약서가 앞에 놓이면 서명란까지 넘기는 데 3분이 안 걸립니다.탓할 일은 아닙니다. 문장은 낯선 법률 용어투성이고, 몇 장이나 되고, 여기까지 오면서 이미 상대를 믿기로 마음먹은 뒤입니다. 이제 와서 조항을 따지는 것이 괜히 못 미더워하는 사람처럼 보일까 싶기도 합니다.다만 개발 외주에서 실제로 다툼이 벌어지는 자리를 되짚어 보면 결국 계약서로 돌아옵니다. 적혀 있는 한 줄 때문이거나, 아무것도 적혀 있지 않아서입니다. 프로젝트가 순조로울 때 계약서는 서랍에 있고, 어긋나는 순간부터는 그것만 남습니다.아래는 개발 외주 계약서에서 특히 자주 비어 있는 일곱 자리입니다. 서..

출시만 남았다고 생각한 자리에서 멈추는 일개발이 마무리되고 이제 올리기만 하면 된다고 생각하실 때, 뜻밖의 지점에서 발이 묶이는 경우가 있습니다. 스토어 심사 반려입니다.코드가 잘못된 것도, 기능이 멈춘 것도 아닙니다. 그런데 거부 통보가 옵니다. 사유를 열어보면 개인정보 처리방침 주소가 없다, 앱 안에서 계정을 지울 수 없다, 심사자가 쓸 테스트 계정이 없다 같은 이야기입니다.고치는 것 자체는 어렵지 않습니다. 문제는 시간입니다. 수정본을 다시 올리면 심사는 처음부터 다시 돌아갑니다. 이 과정을 두세 번 반복하면 출시일이 몇 주 밀립니다. 광고 집행이나 오픈 일정을 잡아두셨다면 그때부터 곤란해집니다.그런데 이런 항목은 대부분 개발하는 동안 함께 챙겨두면 되는 것들입니다. 이번 글에서는 애플과 구글 양쪽..

앱 견적서를 처음 받으면 생기는 혼란앱을 만들려고 견적을 요청하면 익숙하지 않은 표현들이 함께 옵니다. 네이티브, 웹앱, 크로스플랫폼 같은 말들입니다. 업체마다 밀고 나오는 방식이 다르고, 금액도 그에 따라 제각각입니다.설명을 듣긴 하는데 머리에 잘 남지 않습니다. 성능이 낫다거나 관리가 수월하다거나 요즘 흐름이 그렇다는 말이 오갈 뿐, 정작 내 서비스에 무엇이 맞는지는 아무도 정리해 주지 않습니다.문제는 이 결정을 되돌리기가 어렵다는 점입니다. 방식이 달라지면 만들어 둔 코드를 대부분 버리고 다시 시작해야 하기 때문입니다. 처음에 며칠 더 고민하는 편이 결과적으로 이득입니다.그래서 이 글에서는 세 가지 방식이 서로 어떻게 다른지, 돈과 시간은 어디서 벌어지는지, 그리고 어떤 기준으로 고르면 되는지를 순..

실패한 외주 프로젝트에는 닮은 구석이 있습니다외주로 앱을 만들다가 반쯤 완성된 결과물과 연락 두절된 담당자만 남았다는 사연, 한 번쯤 접해보셨을 겁니다. 앱개발업체를 잘못 선택해 고생하신 의뢰자 분들의 이야기를 들어보면 놀라울 정도로 흐름이 비슷합니다. 계약 전에 확인했어야 할 사항을 그냥 지나쳤다는 점입니다.포트폴리오가 근사해서, 가격이 저렴해서, 상담이 친절해서 — 계약에 이르는 이유는 제각각이지만 실패의 원인은 대부분 한 곳으로 모입니다. 실제로 개발하는 사람이 누구인지, 결과물의 권리가 누구에게 귀속되는지, 문제가 터지면 누가 책임을 지는지를 계약서에 적어두지 않은 것입니다.그래서 오늘은 외주 개발을 처음 맡기시는 분들을 위해, 어플개발회사와 도장을 찍기 전 반드시 짚어야 할 여섯 가지를 차례로 ..