이 글의 순서
핵심 내용
기존 회원·주문·관리자를 모두 다시 만들 필요는 없습니다. 현재 시스템을 앱에서도 사용할 수 있다면 기존 기능과 데이터를 활용할 수 있습니다. 다만 앱 화면에서 로그인하고 주문을 조회·처리하려면, 그 화면과 기존 시스템을 연결하는 작업이 필요합니다.
따라서 “홈페이지를 앱으로 만들어 주세요”라고 한 번에 묶기보다 기존에서 활용할 것, 앱과 연결할 것, 새로 개발할 것을 나눠야 합니다. 이 글에서는 회원과 주문이 있는 홈페이지를 기준으로, 견적을 요청할 때 무엇을 구분해야 하는지 살펴봅니다.
회원·주문·관리자를 세 가지 개발 범위로 나눕니다
아래 표는 기존 기능을 앱과 함께 사용할 수 있는 구조를 전제로 한 구분입니다. 실제 활용 범위는 현재 홈페이지의 구조와 수정 가능 여부를 확인한 뒤 정합니다.
| 확인할 기능 | 기존에서 활용할 부분 | 연결 작업 | 새로 개발할 부분 |
|---|---|---|---|
| 회원 | 회원 계정과 회원별 이용 정보 | 앱에서 로그인한 사용자를 기존 회원으로 확인하고 같은 계정에 연결 | 앱의 로그인·내 정보 화면, 기존에 없는 로그인 수단 |
| 주문 | 상품·주문 기록과 기존 주문 처리 규칙 | 앱에서 상품과 본인 주문을 조회하고 주문 요청을 기존 시스템에 전달 | 앱의 상품·주문 화면, 기존에 없는 앱 전용 주문 기능 |
| 관리자 | 기존 상품 관리와 주문 확인·처리 화면 | 앱 주문이 기존 주문 목록에 들어오고 처리 결과를 앱에서도 확인하도록 연결 | 앱 전용 항목이나 처리 업무가 생길 때 필요한 관리 기능 |
기존 주문 기록을 그대로 활용하더라도 앱의 ‘내 주문’ 화면은 새로 만들 수 있습니다. 반대로 기존 웹 화면을 앱 안에서 활용하더라도 로그인 연결이나 알림 같은 추가 작업은 남을 수 있습니다. 데이터를 활용하는 범위와 화면을 만드는 범위는 따로 확인해야 합니다.
같은 회원과 주문이 홈페이지·앱·관리자에서 이어져야 합니다
회원 M204가 홈페이지에서 주문 A1048을 접수했다고 가정해 보겠습니다. 같은 계정으로 앱에 로그인하면, 앱의 ‘내 주문’에도 A1048이 표시돼야 합니다. 새 회원이나 새 주문을 하나 더 만드는 방식으로 처리할 이유는 없습니다.
여기서 연결의 중심은 기존 서버입니다. 앱이 필요한 정보를 요청하면 서버가 로그인한 회원을 확인하고, 그 회원에게 허용된 주문을 반환합니다. 관리자는 기존 화면에서 같은 주문을 처리합니다. 앱이 서버를 거치지 않고 주문 저장소에 직접 접속하는 구조로 생각하면 안 됩니다.
관리자가 A1048을 ‘배송 준비’로 바꿨다면, 앱에서 다시 조회했을 때도 ‘배송 준비’가 보여야 합니다. 화면을 켜 둔 상태에서 즉시 바뀌게 할지, 새로고침하거나 다시 진입했을 때 반영할지는 따로 정합니다. 앱에서 새 주문을 받는다면 기존 관리자 목록에 어떤 상태로 들어갈지도 함께 확인합니다.
같은 아이디로 로그인했다는 사실만으로 주문 연동까지 끝난 것은 아닙니다. 다른 회원의 주문은 조회되지 않는지, 취소 요청이 기존 처리 규칙을 따르는지까지 확인해야 합니다. 주문번호만 바꿔 다른 사람의 주문을 볼 수 없도록 서버에서 권한을 검사하는 것도 연결 작업의 일부입니다. OWASP의 API 권한 확인 기준도 요청한 기록에 접근할 권한을 서버에서 확인하도록 설명합니다.
기존 웹 화면을 쓰는 것과 기존 기능을 연결하는 것은 다릅니다
현재 모바일 홈페이지의 화면을 앱 안에서 활용할 수도 있고, 앱 화면을 새로 만든 뒤 기존 기능에 연결할 수도 있습니다. Android에서도 기존 웹 콘텐츠를 앱 안에 표시하는 방식을 제공합니다. 다만 로그인과 외부 인증은 별도로 고려하도록 안내합니다. Android 공식 웹 콘텐츠 활용 문서
| 비교할 점 | 기존 웹 화면을 활용 | 앱 화면을 새로 만들고 연결 |
|---|---|---|
| 화면 | 현재 웹 화면의 구성과 동작을 활용 | 앱에 맞게 화면과 이동 흐름을 설계 |
| 회원·주문 | 기존 흐름을 활용할 수 있는지 앱 환경에서 확인 | 기존 회원과 주문을 조회·처리하도록 연결 |
| 추가 작업 | 모바일 화면 보완, 로그인·뒤로 가기·첨부 등 필요한 동작 확인 | 화면 구현, 서버 연결, 오류·권한 처리 |
| 견적에서 볼 것 | 유지할 화면과 수정할 화면의 범위 | 새로 만들 화면과 연결할 기능의 범위 |
소개 페이지는 웹 화면을 활용하고 주문 화면은 앱에 맞게 새로 만드는 식으로 일부를 나눌 수도 있습니다. 어떤 방식이든 실제로 자주 쓰는 기능을 기준으로 판단해야 합니다. 화면을 재사용한다는 이유만으로 로그인·결제·첨부 같은 동작이 앱에서도 그대로 된다고 전제하지 않습니다.
기존 시스템을 수정할 수 있는지가 견적을 가릅니다
기존 서버에 앱이 이용할 수 있는 연결 기능이 준비돼 있다면 그 기능을 활용할 수 있습니다. 개발사가 말하는 API는 앱이 서버에 로그인이나 주문 조회를 요청하는 통로라고 이해하면 됩니다. 필요한 통로가 없다면 기존 서버에 추가하거나, 현재 제공되는 기능에 맞춰 앱 범위를 조정해야 합니다.
의뢰 전에 다음 자료를 준비하면 확인이 쉬워집니다.
- 현재 홈페이지 주소와 주요 화면:앱에서도 유지할 흐름과 바꾸고 싶은 화면을 표시합니다.
- 운영·수정 담당:자체 개발인지, 외부 개발사나 홈페이지 제작 서비스를 이용하는지 알려줍니다. 서버와 관리자 수정이 가능한지도 확인합니다.
- 연결 자료:API 문서와 테스트 환경이 있으면 전달합니다. 자료가 없으면 기존 담당자에게 제공 가능 여부부터 확인합니다.
- 대표 업무 한 건:회원이 주문하고 관리자가 처리하는 과정을 실제 개인정보를 가린 화면으로 정리합니다.
관리자에 로그인할 수 있다는 것과 시스템을 수정할 수 있다는 것은 다릅니다. 홈페이지 제작 서비스나 외부 솔루션을 사용한다면 제공되는 연동 기능, 이용 조건과 지원 범위를 먼저 확인해야 합니다. 필요한 기능이 제공되지 않으면 해당 부분의 추가 개발이나 운영 방식 변경이 필요할 수 있습니다.
비밀번호나 운영 서버의 접근 정보를 처음부터 일반 문서나 메신저로 보내기보다, 확인할 자료와 안전한 전달 방법을 개발사와 정하는 편이 좋습니다.
견적에는 활용·연결·신규 개발을 나눠 적어 달라고 요청하세요
‘기존 시스템 연동 포함’이라는 한 줄만으로는 개발 범위를 비교하기 어렵습니다. 어떤 기능을 그대로 쓰고, 어느 화면에서 무엇을 연결하며, 새로 만드는 기능은 무엇인지 결과를 기준으로 적어야 합니다.
기존 홈페이지의 회원·상품·주문·관리자는 가능한 범위에서 함께 사용하고 싶습니다. 앱에서 같은 계정으로 로그인하고 기존 주문을 조회하며, 새 주문은 기존 관리자에서 처리하려고 합니다. 활용 가능한 기존 기능, 추가 연결 작업, 새로 개발할 앱 화면과 관리자 기능을 나눠 견적에 표시해 주세요. 알림과 자동 실시간 갱신은 포함 여부를 별도로 적어 주세요.
납품을 확인할 때도 같은 회원과 주문 한 건을 끝까지 따라가면 됩니다. 홈페이지에서 접수한 주문이 앱에 보이는지, 앱에서 접수한 주문이 기존 관리자에 들어오는지, 관리자에서 바꾼 결과가 앱 재조회에 반영되는지 확인합니다. 서로 다른 회원으로 접속했을 때 다른 사람의 주문이 보이지 않는지도 함께 봅니다.
이렇게 범위를 나누면 기존 기능을 불필요하게 다시 만드는 일과, 필요한 연결 작업이 견적에서 빠지는 일을 함께 줄일 수 있습니다. 출발점은 앱 화면의 개수가 아니라 현재 회원·주문·관리자를 어디까지 함께 쓸 것인지입니다.
