관리자 페이지 개발, 견적서에서 가장 자주 빠지는 항목 — 발주 전에 정의할 6가지

관리자 페이지 개발이 빠진 견적서는 언제나 싸 보입니다. 같은 요구사항을 주고 두 업체에서 견적을 받았는데 한쪽이 눈에 띄게 저렴하다면, 총액을 비교하기 전에 항목을 한 줄씩 대조해 보시기 바랍니다. 사용자 화면은 회원가입, 로그인, 목록, 상세, 결제, 마이페이지까지 화면 단위로 촘촘하게 적혀 있는데, 운영 화면은 아예 없거나 “관리자 페이지 1식”이라는 한 줄로 끝나 있는 경우가 많습니다.

그 한 줄에 무엇이 들어가는지 물어보면 답은 대체로 비슷합니다. “기본적인 CRUD는 포함됩니다.” 그런데 실제 운영에 필요한 것은 기본적인 CRUD가 아닙니다. 누가 어떤 데이터를 볼 수 있는지, 가격과 정책을 개발자 없이 바꿀 수 있는지, 환불 요청을 누가 승인하는지, 고객이 전화로 문의했을 때 담당자가 어느 화면에서 이력을 확인하는지가 필요합니다. 이 항목들은 “1식” 안에 들어 있지 않습니다.

그래서 같은 문장이 오픈 직전에 반복됩니다. “이건 어디서 바꾸나요?” 이 시점에 추가되는 관리자 기능은 이미 확정된 데이터 구조와 권한 설계 위에 얹어야 하므로, 처음부터 반영했을 때보다 비쌉니다. 관리자 기능이 뒤늦게 붙으면서 초기 견적을 넘기는 일은 드물지 않습니다. 이건 개발사가 부정직해서 생기는 문제가 아닙니다. 정의하지 않은 것을 견적에 담을 방법이 없기 때문에 생기는 문제입니다.

디비컨설팅은 100건 이상의 프로젝트를 수행하면서, 관리자 화면이 사실상 제품의 본체인 시스템을 여러 번 만들어 왔습니다. 삼성물산 홈닉 주거 플랫폼, GS건설 엘리시안 리조트 웹·앱, LS일렉트릭 테크스퀘어 산업 B2B 거래 플랫폼, 가천대학교 학사관리 시스템, 센터필드·센트로폴리스 프라임 오피스 빌딩 관리 시스템이 그렇습니다. 이런 시스템은 사용자 화면보다 운영 화면에서 승부가 납니다. 아래 내용은 그 관점에서 정리한 것입니다.

왜 관리자 페이지는 항상 견적에서 빠지는가

발주사는 사용자 화면만 상상한다

기획 회의에서 그려지는 화면은 거의 예외 없이 고객이 보는 화면입니다. 서비스를 처음 구상할 때 우리는 사용자 입장에서 앱을 켜고, 상품을 고르고, 결제하는 장면을 떠올립니다. 반면 운영자가 매일 아침 무엇을 확인하고 무엇을 눌러야 하는지는 상상 대상이 아닙니다.

사용자 화면은 겪어 보지 않아도 그릴 수 있지만, 관리자 화면은 실제로 운영해 본 사람만 정의할 수 있습니다. 그리고 신규 서비스에는 아직 운영해 본 사람이 없습니다. 백오피스가 견적에서 빠지는 첫 번째 이유가 여기 있습니다.

개발사는 “관리자 페이지 1식”으로 방어한다

개발사도 이 항목이 위험하다는 것을 압니다. 그런데 발주사가 운영 시나리오를 주지 않았으므로 공수를 산정할 근거가 없습니다. 이때 개발사가 택할 수 있는 방법은 두 가지입니다. 넉넉하게 잡아서 견적을 올리거나, 최소한으로 잡고 나중에 협의하거나.

경쟁 견적 상황에서는 후자가 이깁니다. 그래서 “관리자 페이지 1식”은 게으름의 결과가 아니라 방어의 결과입니다. 범위가 정의되지 않은 항목을 크게 잡으면 수주에서 밀리기 때문에, 최소한으로 잡아 두고 착수 후에 다시 이야기하는 구조가 만들어집니다. 발주사는 싼 견적을 골랐다고 생각하지만, 실제로는 정의되지 않은 범위를 나중에 협상하기로 하고 계약한 것입니다. 같은 요구사항인데 견적이 크게 갈리는 다른 이유는 홈페이지 제작 비용, 왜 업체마다 열 배씩 다른가에서 따로 정리했습니다.

운영 시나리오는 오픈 직전에야 드러난다

관리자 기능의 필요성은 개발 중에 발견되지 않습니다. 운영을 실제로 시작하는 순간 발견됩니다. 배너를 교체해야 하고, 특정 회원의 등급을 수동으로 바꿔야 하고, 잘못 올라간 상품을 내려야 하고, 어제 결제 취소가 몇 건인지 세어야 합니다.

이 요청들이 한꺼번에 쏟아지는 시점은 대체로 오픈 2주 전입니다. 개발 일정은 이미 끝나 가고, 데이터 구조와 권한 체계는 확정되어 있습니다. 이 상태에서 관리자 기능을 추가하면 화면 하나를 새로 그리는 일이 아니라 설계를 건드리는 일이 됩니다. 비용과 일정이 함께 움직이는 이유입니다.

발주 전에 정의해야 할 6가지

아래 여섯 가지는 기획서가 없어도, 회의 한 번이면 대부분 답할 수 있는 질문입니다. 발주 전에 이 정도만 정리해 두면 견적서의 “1식”은 대부분 화면 단위로 쪼개집니다. 요구사항 문서를 어느 수준까지 준비해야 하는지는 요구사항 정의서, 어디까지 써야 할까에서 별도로 다뤘습니다.

1. 누가 쓰는가 — 권한 등급

관리자 페이지를 사용할 사람의 역할을 나열하고, 각 역할이 볼 수 있는 데이터와 할 수 있는 행위를 구분해야 합니다. 운영자, 고객 응대 담당자, 정산 담당자, 외부 협력사, 시스템 관리자는 각각 다른 화면을 봐야 합니다. 정의하지 않으면 모든 계정이 전체 권한을 갖게 됩니다. 아르바이트 인력이 전 회원의 개인정보와 매출 데이터를 열람할 수 있는 상태로 오픈하게 되고, 이걸 나중에 나누는 작업은 화면 수정이 아니라 재설계입니다.

2. 무엇을 직접 바꿔야 하는가 — 콘텐츠·가격·정책의 수정 범위

배너, 공지, 약관, 상품 가격, 할인율, 배송비 기준, 알림 문구 중에서 개발자 없이 바꿔야 하는 항목을 지정해야 합니다. 기준은 하나입니다. 한 달에 한 번 이상 바뀌는가. 정의하지 않으면 그 값들은 코드나 DB에 고정되고, 문구 한 줄을 바꾸는 데도 유지보수 요청과 배포가 필요해집니다. 운영 속도가 개발사 일정에 묶이는 상태가 여기서 시작됩니다.

3. 무엇을 봐야 하는가 — 통계와 리포트의 실제 사용 목적

“통계 화면 필요합니다”는 요구사항이 아닙니다. 그 숫자를 누가, 얼마나 자주, 무엇을 결정하기 위해 보는지가 요구사항입니다. 주간 회의에 올릴 매출 추이인지, 마케팅 채널별 유입 대비 가입 전환인지, 정산을 위한 기간별 거래 내역인지에 따라 필요한 집계 구조가 전혀 다릅니다. 목적 없이 만든 대시보드는 오픈 후 아무도 보지 않고, 정작 필요한 숫자는 매번 개발팀에 쿼리를 요청해서 받게 됩니다.

4. 무엇을 승인해야 하는가 — 결재·검수·상태 변경 흐름

환불, 입점 승인, 게시물 검수, 정산 확정처럼 담당자가 판단해서 상태를 바꾸는 흐름을 정리해야 합니다. 누가 요청하고, 누가 승인하고, 반려되면 어디로 돌아가고, 그 기록이 어디에 남는지까지가 한 세트입니다. 이 흐름은 화면 하나가 아니라 상태 값과 이력 테이블 설계에 직접 영향을 줍니다. 나중에 추가하면 이미 쌓인 데이터를 마이그레이션해야 하므로 비용이 가장 크게 뛰는 항목 중 하나입니다.

5. 문제가 생기면 어디서 확인하는가 — 로그, 이력, 고객 문의 대응

고객이 “결제했는데 처리가 안 됐다”고 전화했을 때, 담당자가 어느 화면에서 무엇을 보고 답할 수 있어야 하는지를 정해야 합니다. 주문 상태 변경 이력, 관리자 조작 로그, 결제 대사 내역, 발송된 알림 기록이 여기에 해당합니다. 이 화면이 없으면 모든 고객 문의가 개발팀 확인 요청으로 넘어갑니다. 운영 인력이 아니라 개발 인력이 고객 응대에 묶이는 구조가 됩니다.

6. 밖으로 내보내야 하는가 — 엑셀 다운로드, 기존 시스템 연동

데이터를 시스템 밖으로 꺼내야 하는지, 꺼낸다면 어떤 형태인지 확인해야 합니다. 실무에서는 엑셀 다운로드가 거의 항상 필요하고, 그다음이 기존 ERP·회계·CRM과의 연동입니다. 연동은 상대 시스템의 규격에 맞춰야 하므로, 우리 쪽 설계만으로 끝나지 않습니다. 발주 시점에 언급되지 않으면 이 작업은 통째로 견적 밖에 있습니다.

여섯 가지 중에서 견적을 가장 크게 흔드는 항목은 3번, 4번, 6번입니다. 통계는 집계 구조를, 승인 흐름은 상태 설계와 이력을, 외부 연동은 상대 시스템 규격을 건드리기 때문입니다. 나머지 항목이 화면을 늘리는 일이라면, 이 세 가지는 구조를 바꾸는 일입니다.

세 가지 발주 방식의 차이

	국내 개발사	해외 직접 발주	한국 PM + 글로벌 개발팀
개발 단가	높음	낮음	낮음
요구사항 정의 책임	개발사	발주사 본인	한국 PM
커뮤니케이션 언어	한국어	영어	한국어
발주사 담당자 투입 시간	보통	매우 많음	적음
재작업 리스크	낮음	높음	낮음
총비용 관점	비쌈	기대만큼 안 싸다	실질 절감

세 방식의 진짜 차이는 개발 단가가 아니라 요구사항을 정의하는 책임이 어디에 있는가입니다. 국내 개발사에 맡기면 정의 작업의 상당 부분을 개발사가 대신하지만, 그 인건비가 단가에 포함되어 있습니다. 해외에 직접 발주하면 단가는 확실히 내려가는 대신, 정의 책임 전체가 발주사 담당자에게 넘어옵니다.

이 차이가 가장 선명하게 드러나는 지점이 관리자 페이지입니다. 사용자 화면은 참고할 서비스가 많아서 영어로 설명하기가 비교적 수월합니다. 반면 백오피스는 우리 회사의 업무 방식 그 자체입니다. 정산 담당자와 운영자의 권한이 어떻게 다른지, 환불 승인 절차가 어떤 단계를 거치는지, 세금계산서 발행 시점이 언제인지를 영어 문서로 옮겨서 시차를 두고 합의해야 합니다. 이 과정이 한 번에 끝나는 경우는 거의 없고, 오해가 발견되는 시점은 대체로 산출물을 받은 뒤입니다.

결론은 단순합니다. 사내에 운영 시나리오를 정의하고 문서로 만들 사람이 없다면, 해외 개발팀을 직접 관리하는 방식은 관리자 페이지에서 반드시 무너집니다. 절감한 단가는 재작업과 담당자의 시간으로 되돌아 나갑니다. 디비컨설팅의 IT 아웃소싱 구조는 이 지점을 겨냥합니다. 개발은 검증된 글로벌 팀이 맡아 국내 채용 대비 평균 40~60%의 비용을 절감하되, 요구사항을 한국어로 정의하고 결과에 책임지는 역할은 한국인 PM이 프로젝트 안에서 수행합니다.

디비컨설팅은 이 부분을 어떻게 통제합니까

아래는 디비컨설팅이 웹 개발 외주 프로젝트를 진행하는 5단계이며, 각 단계에서 관리자 페이지가 어떻게 다뤄지는지 함께 정리했습니다.

1. 상담 및 요구 분석 — 사업 목표와 기술 요건을 한국어로 문서화합니다. 이 단계에서 사용자 화면보다 운영 시나리오를 먼저 뽑아냅니다. 앞의 여섯 가지 질문을 그대로 물어 권한 등급표와 상태 변경 흐름을 먼저 확정하고, 그 결과를 견적서에 화면 단위로 반영합니다. “관리자 페이지 1식”이라는 항목이 남지 않도록 하는 작업이 여기서 끝납니다.

2. 개발팀 구성 — 프로젝트 성격에 맞는 전담팀을 2~4주 내에 구성합니다. 관리자 화면의 비중이 큰 프로젝트, 예를 들어 권한 체계가 복잡하거나 기존 시스템과 연동해야 하는 경우에는 백엔드와 데이터 설계 인력의 비중을 그에 맞춰 잡습니다.

3. 프로젝트 개발 — 애자일 방식으로 진행하고 진행 상황을 투명하게 공유합니다. 관리자 화면은 사용자 화면과 함께 스프린트에 배치해서, 오픈 직전에 몰리지 않게 합니다. 발주사 담당자는 개발팀과 시차를 두고 조율하는 데 하루를 쓰지 않습니다. 확인해야 할 사항은 한국인 PM이 정리해서 전달합니다.

4. 테스트 및 배포 — QA를 거쳐 릴리즈합니다. 테스트 범위에 관리자 계정별 권한 검증을 포함합니다. 각 등급이 볼 수 없어야 할 데이터를 실제로 볼 수 없는지, 승인 흐름이 반려와 재요청까지 정상 동작하는지를 확인합니다.

5. 운영 및 유지보수 — 문서와 함께 인계하고 장기 지원을 제공합니다. 관리자 페이지 사용 방법, 권한 부여 절차, 데이터 내보내기 방법을 포함한 운영 문서를 함께 넘깁니다. 담당자가 바뀌어도 인수인계가 가능한 상태로 남기는 것이 목적입니다.

이런 기업에 적합합니다

• 운영자가 매일 사용하는 백오피스가 서비스의 핵심인 경우 — 커머스, 예약, 정산, 회원 관리, 시설·자산 관리 시스템
• 사내에 IT 담당자는 있지만 요구사항 정의와 일정 관리를 전담할 PM이 없는 경우
• 국내 견적이 예산을 넘어서지만, 요구사항을 영어로 직접 관리할 여력은 없는 경우
• 기존 ERP·회계·CRM과 연동해야 해서 규격 협의와 검수 책임을 맡길 창구가 필요한 경우

반대로 권하지 않습니다

• 관리자 화면이 사실상 필요 없는 단순 소개형 홈페이지 — 워드프레스나 국내 빌더가 더 빠르고 저렴합니다. 두 가지를 어떻게 구분하는지는 웹 플랫폼 개발과 홈페이지 제작의 차이를 참고하시기 바랍니다
• 사내에 운영 기획자와 PM이 모두 있어 요구사항 정의부터 검수까지 직접 감당할 수 있는 조직 — 해외 개발팀에 직접 발주하는 편이 비용상 유리합니다
• 기존 SaaS의 어드민 기능으로 충분히 해결되는 경우 — 커머스 솔루션이나 예약 SaaS로 커버되는 범위라면 신규 개발이 필요하지 않습니다
• 요구사항이 2주 단위로 바뀌는 초기 검증 단계 — 이 구간은 최소 기능만 빠르게 만들어 검증한 뒤 발주하는 편이 낫습니다

자주 묻는 질문

관리자 페이지도 처음부터 만들어야 하나요? 오픈소스 어드민을 쓰면 안 되나요?

써도 됩니다. 데이터 조회와 기본 등록·수정 수준이라면 오픈소스 어드민 프레임워크로 개발 기간을 줄일 수 있고, 실제로 그렇게 구성하는 경우도 있습니다. 다만 권한 등급이 여러 단계로 나뉘거나 승인·반려 같은 상태 흐름이 들어가면 기성 도구를 커스터마이징하는 비용이 직접 만드는 비용을 넘어서는 구간이 옵니다. 판단 기준은 도구 자체가 아니라 앞서 정리한 여섯 가지 항목의 복잡도입니다. 상담 단계에서 이 부분을 먼저 검토하고 방식을 정합니다.

해외 개발팀인데 의사소통은 어떻게 하나요?

발주사는 한국인 PM하고만 한국어로 소통합니다. 개발팀과 직접 영어로 회의하실 필요가 없습니다. 요구사항 정의, 일정 관리, 산출물 검수는 PM의 책임입니다. 개발팀에 전달할 명세를 작성하고, 결과물이 요구사항과 맞는지 확인한 뒤 발주사에 보고하는 것까지가 PM의 업무 범위입니다. 관리자 페이지처럼 국내 업무 관행이 그대로 반영되어야 하는 영역일수록 이 구조의 차이가 크게 나타납니다.

기획서가 없는데 견적을 받을 수 있나요?

가능합니다. 완성된 기획서나 화면 설계서가 없어도 개략 견적을 드릴 수 있습니다. 해결하려는 문제, 주요 사용자, 반드시 필요한 기능 3~5개, 희망 일정과 예산 범위 정도만 있으면 됩니다. 상담 과정에서 운영 시나리오와 권한 구조를 함께 정리하며 범위를 구체화하고, 그 결과를 반영해 정식 견적을 작성합니다. 기획서를 먼저 만들어야 문의할 수 있는 것은 아닙니다.

오픈 후에 관리자 기능을 추가할 수 있나요? 팀 규모 조정이 가능한가요?

둘 다 가능합니다. 오픈 이후 운영하면서 필요해지는 관리자 기능은 유지보수 또는 추가 개발로 진행합니다. 초기 단계에서 권한 구조와 데이터 설계를 잡아 두기 때문에, 나중에 화면을 추가하기 쉬운 상태로 남습니다. 계약 형태는 전담팀, 장기 협업, 인력 단위, 프로젝트 단위 중에서 선택하실 수 있고, 진행 중에 팀 규모를 늘리거나 줄이는 조정도 가능합니다.

소스코드는 누가 소유하나요?

소스코드는 발주사에 귀속됩니다. 코드뿐 아니라 API 명세, DB 스키마, 배포 절차 문서까지 함께 인계합니다. 이후 다른 개발사에 유지보수를 맡기거나 사내 개발팀이 이어받는 것도 가능합니다. 특정 업체에 묶여서 시스템을 계속 맡길 수밖에 없는 상황을 만들지 않는 것이 인계의 기준입니다. 계약서에서 이 조항을 어떻게 확인해야 하는지는 개발 외주 계약서, 서명 전에 반드시 확인할 7가지 조항에 정리해 두었습니다.

정리

관리자 페이지 개발이 견적에서 빠지는 것은 가격의 문제가 아니라 정의의 문제입니다. 누가 쓰고, 무엇을 바꾸고, 무엇을 승인하고, 어디서 확인하는지를 발주 전에 문서로 만들어 두면 견적은 비교 가능한 형태가 되고, 만들지 않으면 그 비용은 오픈 직전에 청구됩니다. 그리고 이 정의는 개발 단가를 깎아서 해결되는 영역이 아닙니다. 운영 시나리오를 한국어로 묻고 정리하고 검수까지 책임지는 한국인 PM이 프로젝트 안에 있는지가 결과를 가릅니다.