"앱 개발 외주 업체"를 검색하면 수십 개의 업체가 나와요. 포트폴리오도 비슷하고, 가격도 천차만별이고, 후기는 믿을 수 있는지 모르겠고. 어떤 업체를 골라야 할까요?
2026년 기준, 앱 개발 외주 시장은 크게 변했어요. AI 기능이 필수가 되면서 기술 역량의 차이가 더 커졌고, 바이브 코딩 도구의 등장으로 "진짜 개발"과 "코드 조립"의 경계도 모호해졌어요. 그리고 하나 더, 발주자가 자주 헷갈리는 지점이 생겼어요. 앱을 하나 만들려고 알아봤는데 어느새 소프트웨어 개발 외주 업체와 앱 개발 외주 업체를 나란히 놓고 비교하고 있는 상황이에요. 이 글에서는 이런 변화를 반영한 실질적인 선택 기준과, 그 경계를 어떻게 그어야 하는지를 정리해드릴게요.
과거에는 "디자인 잘하고 개발 잘하는 업체"를 고르면 됐어요. 2026년에는 고려해야 할 것이 더 많아졌어요.
발주자가 실제로 헷갈려 하는 지점이에요. "소프트웨어 외주 개발 업체"를 검색하는 분과 "앱 개발 업체"를 검색하는 분이 결국 같은 걸 만들려는 경우도 있고, 완전히 다른 걸 원하는 경우도 있어요. 둘을 가르는 기준은 규모가 아니라 사용자가 무엇으로 접근하느냐와 결과물이 누구의 인프라 위에서 도는가예요.
앱 외주는 스마트폰 앱이라는 결과물을 중심에 놓고, 그걸 돌리는 데 필요한 서버와 관리 화면을 필요한 만큼 붙이는 방식이에요. 소프트웨어 외주는 반대예요. 업무 프로세스나 시스템을 중심에 놓고, 그걸 쓰는 창구 중 하나로 앱이나 웹 화면이 붙어요. 그래서 같은 예산이라도 돈이 어디에 쓰이는지가 달라져요.
| 구분 | 앱 개발 외주 | 소프트웨어 개발 외주 |
|---|---|---|
| 중심이 되는 결과물 | 앱스토어에 올라가는 iOS·Android 앱 | 업무 시스템, 웹 서비스, 내부 툴, 연동 모듈 |
| 사용자 접점 | 일반 이용자의 스마트폰 | 직원 PC, 관리자 웹, 다른 시스템의 API 호출 |
| 요구사항이 오는 곳 | 서비스 기획서, 화면 흐름, 사용자 시나리오 | 기존 업무 규칙, 기존 시스템의 데이터 구조 |
| 산정 단위로 자주 쓰이는 것 | 화면 수와 기능 단위 | 맨먼스(MM), 직무별 투입 기간 |
| 출시 경로 | 앱스토어와 플레이스토어 심사를 통과해야 해요 | 서버 배포로 끝나는 경우가 많아요 |
| 런칭 후 주된 리스크 | OS 업데이트와 스토어 정책 변경 | 기존 시스템 변경, 데이터 마이그레이션 |
| 전형적인 발주처 | 서비스를 새로 만드는 스타트업과 브랜드 | 이미 굴러가는 업무를 개선하려는 기업과 기관 |
현장에서 두 범주는 자주 겹쳐요. 위 표는 업체를 줄 세우기 위한 게 아니라, 지금 내가 필요한 게 어느 쪽에 더 가까운지 가늠하는 용도로 읽어주세요.
이 글이 앱 쪽에 서 있는 이유도 여기 있어요. 앱은 스토어 심사와 OS 업데이트라는 외부 변수를 계속 안고 가야 하고, 화면 하나하나가 곧 사용자 경험이라 기획과 디자인의 비중이 커요. 반대로 사내 업무 시스템처럼 소프트웨어 자체가 본체인 프로젝트는 업무 규칙을 파헤치는 분석 역량이 훨씬 중요해요. 두 역량은 이어져 있지만 같지 않아요.
앱 하나만 만들어 달라고 했는데 견적서가 생각보다 크게 나오는 일이 있어요. 업체가 부풀린 게 아니라, 앱이 돌아가려면 딸려오는 소프트웨어가 견적에 들어갔기 때문인 경우가 많아요. 문제는 그 경계를 발주자가 모른 채 비교하다가, 경계 바깥을 아예 빼놓은 싼 견적을 고르는 거예요. 그러면 런칭 직전에 그 부분이 추가 비용으로 돌아와요.
| 구성 요소 | 보통 어느 견적에 들어가나요 | 빠뜨리면 생기는 일 |
|---|---|---|
| 앱 화면 디자인과 화면 구현 | 앱 견적 | 거의 빠지지 않아요. 다만 화면 수 기준이 업체마다 달라 비교가 어긋나요 |
| 회원가입, 로그인, 소셜 로그인 | 앱 견적 + 서버 작업 | 화면만 잡히고 계정 관리 서버가 빠지면 개발 중간에 범위가 늘어나요 |
| 결제와 정산 | 앱 견적 + 소프트웨어 견적 | 결제 화면만 보고 계약하면 환불과 정산, 영수증 처리가 통째로 남아요 |
| 푸시 알림 | 앱 견적 + 서버 작업 | 발송 트리거와 예약 발송을 누가 관리할지가 비면 운영에서 막혀요 |
| 관리자 웹(어드민) | 소프트웨어 견적 | 누락되기 쉬운 항목이에요. 없으면 데이터를 개발사에 부탁해서 고쳐야 해요 |
| 서버와 데이터베이스 구축, 인프라 | 소프트웨어 견적 | 운영 비용 주체가 불명확해지고, 이관 시점에 계정 소유권 문제가 생겨요 |
| 외부 시스템 연동(ERP·POS·사내 시스템) | 소프트웨어 견적 | 상대 시스템의 스펙 확인이 늦어지면서 일정이 밀리는 대표적인 항목이에요 |
| 데이터 이관과 기존 시스템 정리 | 소프트웨어 견적 | 기존 서비스가 있는데 범위에서 빠지면 오픈 당일에 문제가 터져요 |
| 통계와 리포트 화면 | 소프트웨어 견적 | "나중에"로 미뤄졌다가 운영 지표를 못 보는 상태로 시작하게 돼요 |
| 스토어 등록과 심사 대응 | 앱 견적 | 범위 밖이면 심사 반려 대응을 발주자가 직접 하게 돼요 |
견적을 비교할 때는 총액부터 보지 말고 이 표의 항목이 각 견적서에 있는지부터 맞춰보세요. 항목 구성이 다른 견적서 두 장의 총액을 비교하는 건 의미가 없어요. 견적서를 항목 단위로 뜯어보는 방법은 IT 외주 견적서 분석 가이드에서 더 자세히 다뤘고, 맨먼스로 산정된 견적을 검증하는 방법은 맨먼스(MM) 견적 검증 가이드를 참고하세요. 외부 시스템 연동이 포함된다면 API 연동 외주 가이드가 도움이 돼요.
앱 견적을 처음 받아본 분들이 놀라는 항목이 관리자 웹이에요. "우리는 앱만 필요한데 왜 웹까지 만들죠?"라는 질문이 자주 나와요. 답은 간단해요. 앱에 보이는 내용은 누군가 어딘가에서 넣어야 하거든요.
공지 하나를 올리고, 잘못 등록된 상품을 내리고, 신고된 게시글을 지우고, 환불을 처리하고, 오늘 가입자가 몇 명인지 보는 일. 이 일들은 전부 앱 화면 바깥에서 일어나요. 관리자 화면이 없으면 이 작업을 개발사에 요청해서 데이터베이스를 직접 손대야 해요. 운영이 시작되는 순간 그 요청은 매일 생기고, 그때마다 비용과 시간이 들어가요.
그래서 관리자 화면은 앱의 부속품이 아니라 소프트웨어 쪽 결과물로 보는 게 맞아요. 견적을 볼 때도 앱 화면이 몇 개인지와 관리자 화면이 몇 개인지를 따로 세어야 비교가 가능해요. 관리자 화면을 빼서 싸게 만든 견적은 싼 게 아니라, 운영 비용을 나중으로 미룬 견적이에요.
초기 범위를 줄이고 싶다면 관리자 화면을 통째로 빼는 대신 꼭 필요한 화면만 남기는 방식이 나아요. 보통은 회원 조회, 콘텐츠 등록, 신고 처리, 기본 통계 정도가 1차 범위가 돼요. 나머지는 운영을 해보면서 진짜 필요한 것만 추가하면 돼요.
맡겨도 되는 경우와 그렇지 않은 경우가 갈려요. 판단 기준은 업체 간판이 아니라, 이 프로젝트에서 어려운 쪽이 어디냐예요.
이미 돌아가는 시스템이 있고 앱이 그 시스템의 새 창구로 붙는 경우예요. 사내 재고 시스템과 연동되는 현장용 앱, 기존 회원 데이터베이스를 그대로 쓰는 모바일 창구 같은 프로젝트는 기존 소프트웨어를 읽어내는 역량이 앱 화면 완성도보다 중요해요. 이런 프로젝트는 레거시 마이그레이션·서버 이전 가이드에서 다루는 고민과 겹치는 지점이 많아요.
일반 사용자가 직접 내려받아 쓰는 서비스를 처음부터 만드는 경우예요. 화면 흐름, 온보딩, 첫 실행 경험, 스토어 심사, OS 업데이트 대응처럼 앱 고유의 변수가 성패를 가르거든요. 특히 아직 검증이 안 된 아이디어라면 범위를 좁혀 빠르게 내보는 게 중요한데, 그 접근은 MVP 개발 완전 가이드와 MVP 외주 스타트업 체크리스트에 정리해뒀어요.
앱도 새로 만들고 뒤에 붙는 시스템도 새로 만드는 프로젝트예요. 이때는 한 팀이 앱과 서버를 함께 책임지는 구조가 대체로 유리해요. 앱 팀과 시스템 팀을 따로 발주하면 경계에 있는 일, 그러니까 누가 API 스펙을 정하는지와 장애가 났을 때 어느 쪽 문제인지를 가리는 일에서 시간이 새거든요. 나눠 발주해야 한다면 최소한 인터페이스 정의와 책임 범위를 계약서에 문서로 박아두세요.
한 가지 덧붙이면, 소프트웨어 중심 업체와 앱 전문 업체는 일하는 방식도 조금 달라요. 소프트웨어 쪽은 요구사항을 문서로 확정하고 그대로 만드는 흐름이 익숙하고, 앱 쪽은 화면을 먼저 보여주고 반응을 보면서 다듬는 흐름이 익숙해요. 어느 쪽이 옳다기보다, 우리 프로젝트의 요구사항이 이미 확정돼 있는지 아니면 만들면서 정해질지에 따라 맞는 방식이 달라져요. 요구사항이 아직 흐릿한데 문서 확정형으로 계약하면 변경 요청이 전부 추가 비용이 되고, 반대로 규칙이 명확한 업무 시스템을 화면부터 그리며 시작하면 나중에 구조를 다시 짜게 돼요.
어느 쪽이든 업체에게 이렇게 물어보면 답이 빨리 나와요. "이 프로젝트에서 앱 쪽 공수와 서버·관리자 쪽 공수 비중을 대략 어떻게 보시나요?" 이 질문에 구체적으로 답하는 업체는 범위를 이미 머릿속에서 쪼개본 거예요. 답이 뭉뚱그려진다면 견적도 뭉뚱그려져 있을 가능성이 높아요.
약속한 기능 범위와 일정을 지킨 프로젝트의 비율이에요. 중요한 건 숫자 자체가 아니라 어떻게 셌는지를 설명할 수 있는가예요. 기준을 말할 수 있는 업체는 최소한 자기 프로젝트를 관리하고 있다는 뜻이거든요. 숫자만 크게 말하고 산정 방식을 못 대는 쪽이 더 위험해요.
디자인 시안이나 스크린샷이 아닌, 앱스토어에서 다운로드할 수 있는 실제 서비스를 확인하세요. 라이브 서비스는 거짓말을 못해요. 다운로드해서 직접 써보면 그 업체의 실력을 정확히 알 수 있어요. 가능하면 관리자 화면을 만들어본 사례도 같이 물어보세요. 앱 화면은 잘 뽑는데 뒤에 붙는 소프트웨어 경험이 얕은 팀도 있거든요.
Notion, Jira, Linear 같은 도구로 실시간 진행 현황을 공유하는지 물어보세요. 메신저로만 소통하는 업체는 프로젝트가 커질수록 관리가 어려워져요. 주간 미팅과 협업 도구 기반 소통이 최소 조건이에요.
계약서에 "납품 완료 후 전체 소스코드 소유권은 클라이언트에 귀속"이라는 조항이 반드시 있어야 해요. 이 조항이 없으면 나중에 다른 업체로 유지보수를 넘기거나 자체 개발팀을 꾸릴 때 문제가 생겨요. 앱 소스뿐 아니라 서버 코드, 인프라 계정, 배포 스크립트까지 범위에 들어가는지도 확인하세요. 계약서에서 걸러야 할 조항은 IT 외주 계약 독소조항 가이드에 모아뒀어요.
앱은 런칭 후가 진짜 시작이에요. iOS와 Android 업데이트 대응, 서버 모니터링, 버그 수정 등 지속적인 관리가 필요해요. 유지보수 계약(월 정액 또는 시간당)을 사전에 논의하지 않으면 런칭 후 방치되는 경우가 있어요. 형태별 차이는 개발 후 유지보수 계약 가이드에서 비교해뒀어요.
앱 유형별로 현장에서 오가는 견적 범위를 정리하면 이래요. 아래 금액은 공표된 통계가 아니라 발주 현장에서 오가는 견적 범위라는 점을 감안해서 읽어주세요.
구간 사이를 가르는 건 화면 개수가 아니라 기능의 성격이에요. 결제가 들어가면 환불과 정산이 따라오고, 실시간 기능이 들어가면 서버 구조가 달라지고, 여러 종류의 사용자가 생기면 권한 관리가 통째로 추가돼요. 기능 하나를 넣고 빼는 결정이 구간을 통째로 옮기기도 해요. 그래서 예산이 정해져 있다면 금액을 깎아달라고 하기 전에, 어떤 기능이 구간을 밀어 올리고 있는지부터 업체와 같이 확인하는 편이 나아요.
이 범위보다 훨씬 저렴한 견적은 기능이 빠져 있거나 품질 리스크가 있을 가능성이 높으니 주의하세요. 그리고 위 구간이 올라갈수록 금액이 늘어나는 이유는 앱 화면이 많아져서가 아니라, 뒤에 붙는 소프트웨어(서버, 관리자, 연동)가 커지기 때문이에요. 같은 "앱 개발"이라는 이름 아래에서도 실제로는 소프트웨어 프로젝트에 가까워지는 거예요.
업체 유형마다 잘 맞는 프로젝트가 달라요. 가격표가 아니라 "우리 프로젝트가 어느 칸에 들어가는지"를 찾는 용도로 읽어보세요.
| 업체 유형 | 적합한 프로젝트 | 강점 | 주의할 점 | 이럴 때 고르세요 |
|---|---|---|---|---|
| 대형 SI (50인 이상) | 대기업 내부 시스템, 대규모 플랫폼 | 체계적인 프로세스, 조직 안정성, 대규모 소프트웨어 프로젝트 경험 | 비용이 높고 스타트업 속도와 잘 안 맞아요. 소규모 건은 우선순위가 밀릴 수 있어요 | 예산 규모가 크고 보안과 감사 절차가 까다로운 조직일 때 |
| 전문 소규모 에이전시 (5~20인) | 스타트업 MVP, 중소규모 서비스 앱 | 빠른 대응, 의사결정자와 직접 소통, 비용 효율, 스타트업 이해도 | 동시 진행할 수 있는 프로젝트 수가 제한적이고, 특정 기술 스택에 편중될 수 있어요 | 속도와 소통이 성패를 가르는 초기 서비스일 때 |
| 소프트웨어·시스템 전문 업체 | 사내 업무 시스템, 기존 시스템 연동, 데이터 이관 | 업무 규칙 분석과 기존 소프트웨어 해석에 강해요 | 일반 이용자용 앱의 화면 완성도나 스토어 대응 경험은 팀마다 편차가 커요 | 앱보다 뒤에 붙는 시스템이 더 어려운 프로젝트일 때 |
| 프리랜서·소규모 팀 (1~4인) | 기능이 단순한 앱, 부분 개발 | 같은 범위 대비 비용 부담이 작아요 | 이탈 리스크, 풀스택 커버 한계, 장기 유지보수가 어려워요 | 예산이 매우 제한적이고 범위가 작고 명확할 때 |
| 노코드·바이브 코딩 도구 | 아이디어 검증용 프로토타입 | 착수가 빠르고 초기 비용 부담이 적어요 | 커스터마이징과 확장에 한계가 있고, 소스코드 이관과 스토어 정책 대응이 까다로워요 | 투자 유치 전에 화면 흐름만 빠르게 보여줘야 할 때 |
같은 유형 안에서도 업체별 편차가 커요. 인원 구간은 본문에서 유형을 나눌 때 쓴 기준을 그대로 옮긴 것이라 절대적인 분류는 아니에요.
업종이 뚜렷하면 범위 경계가 훨씬 빨리 잡혀요. 그 업종에서 어떤 시스템이 이미 돌고 있는지가 정해져 있기 때문이에요. 예를 들어 프랜차이즈는 점주용 앱 하나만 만드는 것처럼 보여도 본사 정산과 발주 시스템에 붙어야 해서, 실제로는 소프트웨어 연동 비중이 작지 않아요. 이 구조는 프랜차이즈 점주용 앱 개발 가이드에 따로 정리해뒀어요. 배달과 매장 운영 쪽은 POS와 주문 시스템이 같은 역할을 하는데, 그 경우는 푸드테크·배달 앱 개발 업체 추천을 참고하세요.
업종 사례를 먼저 훑으면 좋은 이유가 하나 더 있어요. 우리가 요구사항이라고 생각했던 것이 사실은 그 업종의 기존 시스템이 이미 정해둔 제약인 경우를 발견하게 되거든요. 그걸 모르고 기능 정의서를 쓰면 나중에 전부 다시 쓰게 돼요.
검색으로 나온 업체 목록은 기본적으로 자기소개예요. 거기서 판단할 수 있는 건 많지 않지만, 몇 가지 신호는 목록 단계에서도 걸러낼 수 있어요.
목록을 3~5곳으로 좁혔다면 같은 문서를 보내서 같은 조건으로 견적을 받으세요. 업체마다 다른 설명을 듣고 비교하면 결국 총액만 남고, 총액만 남으면 범위를 가장 적게 잡은 곳이 이기게 돼요. 그건 좋은 선택이 아니에요.
업체를 좁혔다면 계약서에 도장을 찍기 전에 아래 항목을 하나씩 물어보세요. 답이 막히는 항목이 그 업체의 약한 고리예요.
| 확인 항목 | 왜 필요한가요 | 빠지면 생기는 일 |
|---|---|---|
| 수행 완수율과 그 집계 기준 | 약속한 기능 범위와 일정을 지킨 비율이에요. 숫자보다 "어떻게 셌는지"를 말할 수 있는지가 핵심이에요 | 근거 없는 자신감만 듣고 계약하게 돼요. 답을 못 하는 쪽이 더 위험해요 |
| 앱스토어에서 받아볼 수 있는 라이브 서비스 | 시안이나 스크린샷은 검증이 안 돼요. 직접 다운로드해 써보면 실력이 드러나요 | 포트폴리오가 실제 결과물인지 확인하지 못한 채 계약이 진행돼요 |
| 앱과 소프트웨어(서버·관리자)의 공수 비중 | 어디에 돈과 시간이 쓰이는지를 업체가 쪼개서 말할 수 있어야 해요 | 총액만 맞춰둔 견적이 되고, 관리자 화면 같은 항목이 나중에 추가 비용으로 돌아와요 |
| 협업 도구 기반 진행 공유 (Notion·Jira·Linear 등) | 진행 상황을 실시간으로 볼 수 있어야 해요. 주간 미팅과 함께가 최소 조건이에요 | 메신저 단일 채널이면 프로젝트가 커질수록 블랙박스가 되고, 지연을 늦게 알게 돼요 |
| 소스코드 소유권 귀속 조항 | "납품 완료 후 전체 소스코드 소유권은 클라이언트에 귀속"이 계약서에 있어야 해요 | 유지보수 업체를 바꾸거나 내부 개발팀을 꾸릴 때 이관 협상에서 끌려다녀요 |
| 서버와 인프라 계정의 소유 주체 | 클라우드 계정과 배포 권한이 누구 명의인지가 이관 난이도를 좌우해요 | 소스는 받았는데 운영 환경을 못 받아서 사실상 이관이 막혀요 |
| 유지보수 계약 형태와 대응 범위 | 앱은 런칭 후가 시작이에요. 월 정액인지 시간당인지, 어디까지 포함인지 미리 정해야 해요 | OS 업데이트와 버그 대응이 공백으로 남아 런칭 후 방치되기 쉬워요 |
| 크로스플랫폼과 네이티브 중 선택한 근거 | React Native·Flutter·네이티브 선택이 비용과 일정을 크게 좌우해요 | 장단점을 설명하지 못하는 업체는 익숙한 스택으로 밀어붙이게 돼요 |
| AI 기능 연동 경험 | 요즘 앱에는 챗봇·추천·자동화 같은 AI 기능이 함께 들어가는 경우가 많아요 | API 연동 경험이 없으면 이 부분에서 비용과 기간이 크게 늘어나요 |
| 개인정보 처리방침과 앱 접근권한 동의 처리 | 개인정보 보호법상 처리방침 공개 의무가 있고, 정보통신망법 제22조의2는 단말기 접근권한에 대한 동의 절차를 요구해요 | 스토어 심사에서 반려되거나 출시 후 시정 대상이 될 수 있어요 |
| 위치 기능이 있다면 위치기반서비스사업 신고 여부 | 개인위치정보를 다루면 위치정보의 보호 및 이용 등에 관한 법률에 따라 방송통신위원회 신고 대상이 돼요 | 출시 직전에 발견하면 행정 절차 때문에 런칭 일정이 통째로 밀려요 |
법령명은 국가법령정보센터 표기를 따랐어요. 실제 적용 여부는 앱이 다루는 데이터와 기능에 따라 달라지니, 계약 전에 업체와 함께 확인하세요.
예산을 아끼려고 앱은 앱 전문 업체에, 서버와 관리자는 소프트웨어 업체에 따로 맡기는 방식을 고민하는 분들이 있어요. 규모가 크고 발주자 쪽에 기술 담당자가 있다면 가능한 구조예요. 다만 그렇지 않다면 아껴진 금액보다 잃는 게 클 수 있어요.
나눠 발주했을 때 실제로 부딪히는 지점은 대체로 이 네 가지예요.
그래도 나눠야 한다면 최소한 인터페이스 정의서와 통합 테스트 주관자, 장애 1차 접수 창구를 계약서에 적어두세요. 이 세 가지만 정해져 있어도 경계에서 새는 시간이 크게 줄어요. 반대로 한 팀에 맡긴다면 그 팀이 앱과 소프트웨어 양쪽을 다 해봤는지를 사례로 확인하는 게 먼저예요.
여러 업체에서 받은 견적이 비교가 안 되는 이유는 업체 탓보다 요청서 탓인 경우가 많아요. 같은 문서를 받아야 같은 기준으로 답이 오거든요. 앱과 소프트웨어의 경계가 흐린 프로젝트일수록 이 준비가 더 중요해요.
포텐랩은 스타트업과 중소기업의 앱·플랫폼 개발에 특화된 IT 에이전시예요. 추천 이유를 솔직하게 정리하면 이래요.
앱 개발 파트너를 찾고 있다면, 포텐랩 홈페이지에서 무료 상담을 받아보세요. 아이디어 단계부터 런칭까지 함께 고민해드려요.
두 팀은 같은 그룹이라 솔직하게 나눠 적을게요. 어느 쪽인지 가르는 질문은 하나예요. 지금 어려운 게 제품인가요, AI인가요?
앱에 AI가 곁들여지는 정도면 포텐랩 하나로 충분해요. 반대로 AI가 서비스의 본체라면 트리숲 쪽이 빨라요. 애매하면 상담에서 나눠드려요. 맞지 않는 쪽으로 보내는 게 서로에게 이득이거든요.
기능 범위에 따라 달라져요. 정보 제공형 앱은 1,500만~3,000만 원, 회원가입·결제·푸시가 들어가는 일반 서비스 앱은 3,000만~8,000만 원, 매칭이나 실시간·AI가 들어가는 플랫폼형은 8,000만~2억 원, 멀티 유저 롤과 관리자 웹까지 포함하는 복합 플랫폼은 2억 원 이상을 잡아요. 공표된 통계가 아니라 발주 현장에서 오가는 견적 범위예요. 이보다 훨씬 저렴한 견적은 기능이 빠져 있거나 품질 리스크가 있을 가능성이 높아요.
간단한 앱은 2~3개월, 일반 서비스 앱은 3~5개월, 복잡한 플랫폼은 6개월 이상이 현실적이에요. 공표된 통계가 아니라 발주 현장에서 오가는 기간 범위예요. "1개월 만에 완성해드릴게요"라는 제안은 기능 범위를 크게 줄였거나 품질을 타협했을 가능성이 있어요. 견적서를 받을 때 일정과 기능 범위를 같이 놓고 보세요.
아니에요. React Native나 Flutter 같은 크로스플랫폼 프레임워크를 쓰면 하나의 코드베이스로 두 플랫폼을 모두 커버할 수 있어서, 각각 네이티브로 개발할 때보다 비용과 일정을 줄일 수 있어요. 다만 게임이나 AR처럼 고성능이 필요한 앱은 네이티브가 더 나을 수 있어요. 절감 폭은 기능 구성에 따라 달라지니, 업체가 두 방식의 장단점을 설명할 수 있는지부터 확인해 보세요.
다섯 가지를 순서대로 물어보세요. 수행 완수율과 그 집계 기준, 앱스토어에서 직접 받아볼 수 있는 라이브 포트폴리오, 협업 도구 기반의 진행 공유 방식, 소스코드 소유권이 클라이언트에 귀속된다는 계약 조항, 그리고 런칭 후 유지보수 계약의 형태와 범위예요. 이 중 한 곳에서 답이 막히면 그 지점이 프로젝트 리스크가 될 가능성이 높아요.
프로젝트 성격에 따라 갈려요. 대형 SI는 프로세스와 안정성이 강점이지만 비용이 높고 스타트업 속도에는 잘 맞지 않아요. 5~20인 규모의 전문 에이전시는 빠른 대응과 직접 소통이 강점이라 스타트업 MVP나 중소규모 서비스 앱에 어울려요. 예산이 매우 제한적이고 범위가 작다면 프리랜서·소규모 팀도 선택지이지만 이탈과 장기 유지보수 리스크를 감안해야 해요.
가능하지만 범위 변경은 비용과 일정에 그대로 영향을 줘요. 좋은 업체는 2주 단위 스프린트로 유연하게 대응하면서도 변경의 영향도를 투명하게 공유해요. 계약 전에 변경 관리 프로세스가 어떻게 되는지 꼭 확인하세요.
중심에 놓는 결과물이 달라요. 앱 외주는 앱스토어에 올라가는 앱을 중심에 두고 필요한 서버와 관리 화면을 붙이고, 소프트웨어 외주는 업무 시스템이나 웹 서비스를 중심에 두고 그걸 쓰는 창구로 앱이나 웹 화면이 붙어요. 그래서 앱 쪽은 화면 흐름과 스토어 대응이, 소프트웨어 쪽은 기존 업무 규칙과 데이터 구조 분석이 더 중요해져요. 우리 프로젝트에서 어려운 쪽이 어디인지를 기준으로 고르면 돼요.
이미 돌아가는 시스템이 있고 앱이 그 시스템의 새 창구로 붙는 경우라면 괜찮아요. 사내 재고 시스템과 연동되는 현장용 앱처럼 기존 소프트웨어를 읽어내는 역량이 더 중요한 프로젝트가 여기에 해당해요. 반대로 일반 사용자가 내려받아 쓰는 서비스를 처음부터 만드는 경우라면, 화면 흐름과 온보딩, 스토어 심사와 OS 업데이트 대응 경험이 있는 앱 전문 업체가 유리해요.
앱 화면 구현과 스토어 등록은 보통 앱 견적, 관리자 웹과 서버·데이터베이스 구축, 외부 시스템 연동, 데이터 이관, 통계 화면은 소프트웨어 견적에 들어가요. 회원과 결제와 푸시처럼 양쪽에 걸치는 항목도 있어요. 견적서를 비교할 때는 총액이 아니라 이 항목들이 각 견적서에 들어 있는지부터 맞춰보세요. 항목 구성이 다르면 총액 비교는 의미가 없어요.
앱에 보이는 내용을 누군가 넣고 고쳐야 한다면 필요해요. 공지 등록, 상품 수정, 신고 처리, 환불, 가입자 확인 같은 일은 전부 앱 화면 바깥에서 일어나거든요. 관리자 화면이 없으면 그때마다 개발사에 요청해서 데이터를 고쳐야 해요. 초기 비용을 줄이고 싶다면 통째로 빼기보다 회원 조회, 콘텐츠 등록, 신고 처리, 기본 통계 정도만 1차 범위로 남기는 방식이 나아요.
발주자 쪽에 기술 담당자가 있다면 가능한 구조예요. 다만 앱과 서버가 주고받는 데이터 형식을 누가 정할지, 장애가 났을 때 어느 쪽 문제인지, 통합 테스트는 누가 주관할지가 비어 있으면 그 경계에서 시간과 비용이 새요. 나눠 발주한다면 인터페이스 정의서와 통합 테스트 주관자, 장애 1차 접수 창구만큼은 계약서에 적어두세요.