앱 개발사를 고를 때는 포트폴리오의 화려함보다 그 회사가 그 앱에서 실제로 어떤 일을 했는지, 출시 후에도 앱을 계속 관리하고 있는지, 우리 프로젝트를 실제로 누가 만드는지를 확인하는 게 중요합니다. 이건 홈페이지만 봐서는 알 수 없고 미팅에서 직접 물어봐야 나옵니다. 이 글은 개발사 입장에서 저희가 받았을 때 좋은 질문이라고 느꼈던 것들을 중심으로 정리했습니다.

포트폴리오는 "어디까지 했는지"를 물어보세요

포트폴리오에 유명한 회사 이름이 있으면 일단 믿음이 갑니다. 그런데 앱 하나에도 여러 회사가 참여하는 경우가 많습니다. 기획은 한 곳, 디자인은 다른 곳, 앱 개발과 서버 개발이 또 나뉘기도 합니다. 처음 출시는 다른 회사가 하고 이후 유지보수만 맡은 경우도 있고, 반대로 처음 만들고 손을 뗀 경우도 있습니다.

포트폴리오 확인 질문

• 이 앱에서 맡은 범위가 어디까지인지
• 기획과 디자인도 직접 했는지
• 서버도 직접 만들었는지
• 지금도 이 앱을 관리하는지
• 스토어 업데이트 날짜와 최근 리뷰
• 비슷한 분야를 해 봤는지

그래서 포트폴리오를 볼 때는 이렇게 물어보시면 됩니다. 이 앱에서 맡은 범위가 어디까지였는지, 기획과 디자인도 직접 했는지, 서버도 만들었는지, 지금도 이 앱을 관리하고 있는지. 범위를 정확히 말해 주는 회사가 믿을 만합니다. "거의 다 했다"는 식으로 흐리는 답이 나오면 한 번 더 물어보셔도 됩니다.

그리고 포트폴리오에 있는 앱은 직접 설치해서 써 보세요. 스토어에서 마지막 업데이트 날짜, 최근 리뷰, 버전 기록을 보면 그 앱이 지금도 관리되고 있는지 대략 보입니다. 몇 년째 업데이트가 없는 앱만 있다면 이유를 물어볼 만합니다. 계약이 끝나서일 수도 있고, 사업이 접혔을 수도 있으니 무조건 나쁜 신호는 아닙니다.

비슷한 분야 경험도 따져 볼 만합니다. 헬스케어, 블루투스 기기 연동, 결제가 많은 커머스처럼 분야마다 반복해서 부딪히는 문제가 있습니다. 같은 분야를 해 본 회사는 기획 단계에서 그 문제를 먼저 꺼냅니다.

출시 후에도 앱을 운영해 본 회사인가

앱은 출시가 끝이 아닙니다. OS가 해마다 바뀌고, 스토어 정책이 바뀌고, 사용자가 늘면서 처음에는 없던 문제가 생깁니다. 만들기만 해 본 회사와, 만든 앱을 몇 년씩 운영해 본 회사는 처음 설계부터 다르게 합니다. 로그를 어떻게 남길지, 강제 업데이트를 어떻게 걸지, 장애가 나면 어떻게 알아챌지를 처음부터 생각하기 때문입니다.

미팅에서 "출시 후에는 어떻게 관리하세요?"라고 물어보시면 됩니다. 크래시 모니터링, OS 업데이트 대응, 장애 연락 체계 같은 이야기가 구체적으로 나오면 운영 경험이 있는 회사입니다.

실제로 누가 만드는지 확인하기

계약은 A 회사와 했는데 실제 개발은 다른 회사나 프리랜서가 하는 경우가 있습니다. 재하도급이라고 부르는 구조입니다. 이 자체가 불법이거나 무조건 나쁜 건 아닙니다. 특정 분야를 전문 업체에 맡기는 게 나을 때도 있습니다. 문제는 발주하는 쪽이 그 사실을 모르는 경우입니다. 소통이 한 단계 더 거치게 되고, 문제가 생겼을 때 책임 소재가 흐려집니다.

물어볼 것은 이렇습니다.

• 우리 프로젝트에 들어가는 사람은 정규 직원인지, 외부 인력인지
• 앱, 서버, 디자인 중 외부에 맡기는 부분이 있는지
• 실제 담당 개발자를 미팅에서 만날 수 있는지
• 프로젝트 중간에 담당자가 바뀌면 어떻게 인수인계하는지

영업 담당자만 미팅에 나오고 개발 쪽 사람을 끝까지 만날 수 없다면, 적어도 기술 검토 미팅은 한 번 따로 요청해 보세요.

소통 방식은 계약 전에 맞춰 봐야 합니다

외주 프로젝트가 틀어지는 이유를 돌아보면 기술보다 소통 문제가 더 많습니다. 몇 주 동안 소식이 없다가 완성본을 받았는데 생각했던 것과 다른 경우가 대표적입니다.

계약 전에 이런 것들을 물어보세요. 진행 상황은 얼마나 자주, 어떤 방식으로 공유하는지. 중간 결과물을 실제 기기에 설치해서 볼 수 있는지. 질문이나 수정 요청은 어디로 보내고, 보통 얼마 만에 답이 오는지. 기획이나 디자인 확정은 어떤 절차로 하는지.

저희는 화면 단위로 결과물이 나올 때마다 테스트용 앱을 설치해 볼 수 있게 공유하고, 정기적으로 짧게 진행 상황을 맞춥니다. 회사마다 방식은 달라도, 이 질문에 바로 구체적인 답이 나오는지를 보시면 됩니다.

견적은 금액보다 산정 방식을 보세요

여러 곳에서 견적을 받으면 차이가 크게 나는 경우가 많습니다. 금액만 놓고 비교하면 판단이 어렵습니다. 같은 "회원가입" 기능이라도 어디는 이메일 가입만, 어디는 소셜 로그인과 본인인증까지 넣어서 계산했을 수 있기 때문입니다.

견적서 두 가지 유형

총액만 있는 견적

• 기능별 작업량 안 보임
• 서버, 관리자 포함 불명
• 디자인 화면 수 불명
• 출시 후 대응 불명

상세 내역 견적

• 기능 목록별 작업량
• 서버, 관리자 페이지 명시
• 디자인 화면 수 기준
• 출시 후 대응 기간 명시

볼 것은 견적이 어떻게 나왔는지입니다. 기능 목록별로 작업량이 나뉘어 있는지, 서버 구축과 관리자 페이지가 포함됐는지, 디자인이 몇 개 화면 기준인지, 스토어 등록과 출시 후 대응 기간이 들어 있는지를 확인하세요. 상세 내역 없이 총액만 있는 견적은 나중에 범위를 두고 다툴 여지가 큽니다. 견적서를 비교하는 방법은 견적서 확인하는 법에 더 자세히 적어 두었습니다.

견적을 정확하게 받으려면 발주하는 쪽에서도 준비가 필요합니다. 기획서가 거창할 필요는 없지만 누가 쓰는 앱인지, 꼭 필요한 기능이 무엇인지, 참고하는 앱이 있는지 정도는 정리되어 있어야 합니다. 이 정도만 있어도 견적 사이의 차이가 훨씬 줄어듭니다.

소스코드와 계정은 누구 것인가

계약 단계에서 꼭 확인할 부분입니다. 개발이 끝난 뒤 소스코드를 받을 수 있는지, 지식재산권이 발주사로 넘어오는지, 서버와 데이터베이스 접근 권한을 받을 수 있는지를 물어보세요.

계정 명의와 권한 구조

발주사 명의스토어, 서버, 도메인 계정

권한 위임작업에 필요한 권한만 부여

개발사 작업위임받은 권한으로 개발, 출시

Apple 개발자 계정과 Google Play 개발자 계정은 처음부터 발주사 명의로 만드는 게 원칙입니다. 개발사 계정으로 출시하면 나중에 앱을 옮기는 절차가 번거롭고, 개발사와 관계가 끝났을 때 앱 관리가 어려워집니다. 서버 호스팅, 도메인, 푸시 알림 서비스, 결제 대행사 계정도 마찬가지입니다. 개발사는 권한을 위임받아 작업하는 구조가 맞습니다.

이 질문에 "나중에 다 넘겨드려요"라고만 하지 않고 계약서에 어떻게 적는지까지 설명해 주는 회사가 좋습니다.

유지보수 조건은 따로 확인합니다

출시 후 일정 기간 동안 무상으로 오류를 고쳐 주는 하자보수 기간이 있는지, 기간이 얼마인지, 무엇이 하자에 해당하는지를 확인하세요. 버그 수정은 하자보수지만, 새 기능 추가나 디자인 변경은 보통 별도입니다. 이 경계가 계약서에 없으면 출시 직후에 서로 다른 기대로 부딪히기 쉽습니다.

하자보수 기간이 끝난 뒤의 유지보수는 월 단위 계약인지, 요청할 때마다 계산하는지, 장애가 나면 얼마 안에 대응하는지도 미리 들어 두세요. 출시 이후에 어떤 관계를 이어 갈 수 있는지가 이 대화에서 많이 드러납니다.

이런 경우는 한 번 더 생각해 보세요

미팅에서 아래 같은 모습이 보이면 서두르지 마시고 다른 곳과 비교해 보시길 권합니다.

• 요구사항을 거의 묻지 않고 바로 금액과 일정부터 말한다
• 어떤 요청이든 "다 됩니다"라고만 하고 어려운 점이나 대안을 말하지 않는다
• 소스코드 제공이나 계정 명의 이야기를 꺼내면 답이 흐려진다
• 전체 대금의 대부분을 착수 시점에 요구한다
• 실제 작업자를 만나거나 확인할 방법이 없다

반대로 좋은 신호도 있습니다. 이 기능은 처음 버전에서 빼는 게 낫겠다고 먼저 말하는 회사, 일정이 빠듯하다고 솔직하게 말하는 회사는 대체로 프로젝트를 끝까지 책임지려는 쪽입니다.

자주 묻는 질문

견적은 몇 군데서 받는 게 좋을까요?

정해진 숫자는 없지만 두세 곳 정도면 비교가 됩니다. 너무 많이 받으면 미팅마다 설명하느라 시간이 들고, 비교 기준도 흐려집니다. 같은 기획 자료를 보내고 같은 질문을 해야 비교가 공정해집니다.

프리랜서와 개발사 중 어디가 나을까요?

범위가 작고 앱만 만들면 되는 일이라면 프리랜서도 좋은 선택일 수 있습니다. 앱, 서버, 디자인, 출시 후 운영까지 한 번에 맡겨야 한다면 여러 역할을 갖춘 팀이 있는 곳이 관리하기 편합니다. 어느 쪽이든 소스코드와 계정 소유는 똑같이 챙기셔야 합니다.

회사 규모가 크면 더 안전한가요?

꼭 그렇지는 않습니다. 규모보다 우리 프로젝트에 실제로 누가 들어오는지, 그 사람들이 비슷한 일을 해 봤는지가 더 중요합니다. 큰 회사라도 실제 작업은 소수 인원이 하는 경우가 많습니다.

외주로 갈지 직접 개발할지도 아직 못 정했어요.

그 판단이 먼저입니다. 외주 개발과 직접 개발 비교 글에서 회사 상황별 기준을 정리해 두었습니다.

저희가 실제로 맡았던 범위와 결과는 개발 사례에서 보실 수 있고, 위 질문들을 그대로 저희에게 하셔도 됩니다. 상담으로 연락 주세요.