외식업 프랜차이즈 POS 주문·판매 데이터 수집 및 통합 관리 시스템 구축

프로젝트 개요

• 외식업 프랜차이즈 가맹점에서 사용 중인 POS의 주문·판매 데이터를 자동으로 수집하여 본사(가맹본부)에서 통합 관리할 수 있는 시스템을 구축하고자 합니다. 현재 각 가맹점은 서로 다른 POS를 사용하고 있어, 가맹본부가 전체 매장의 판매 데이터를 일괄적으로 확보하고 분석하는 데 어려움이 있습니다.
• 기존 POS를 교체하지 않고, 매장 POS가 설치된 Windows PC에 데이터 수집 Agent를 설치하여 주문·판매 데이터를 수집한 뒤 중앙 서버로 전송하는 방식을 기본 구조로 검토하고 있습니다.
• 데이터 수집 방식은 매장 POS PC에 설치된 POS 로컬 DB를 직접 조회하여 수집하는 방식을 본 과업의 표준 방식으로 합니다. POS 공식 API, Export 파일, 로그 파일, Back Office 서버 등을 통한 수집 방식은 본 과업의 기본 범위에서 제외합니다.

클라이언트 소개

• 외식업 프랜차이즈 가맹본부를 대상으로 서비스를 운영 중이며, 이번에 개발하는 POS 데이터 수집·통합 관리 기능은 기존 서비스에 무료로 추가하는 부가 기능입니다.
• 사내용이 아닌 고객용(가맹본부 사용) 기능입니다.
• 프로젝트 의사결정 구조: 담당자가 요구사항 확인, 후보업체 미팅, 최종 업체 선정을 직접 진행합니다.
• 개발 지식: 사내에 개발자가 있으나 이번 프로젝트는 전적으로 외주로 진행하며, 협업 없이 완전히 위탁합니다.

프로젝트 추진 목적

• 1차 개발의 가장 중요한 목표는 다음 구조를 구축하여 실제 주문·판매 데이터가 누락이나 중복 없이 안정적으로 수집되는 것입니다.
• 매장 POS → 데이터 수집 Agent → 중앙 서버 → 데이터 정규화 → 본사 웹 관리페이지
• 1차에서는 POS 1종을 대상으로 우선 개발하고, 이후 다양한 POS를 추가할 수 있도록 Adapter 또는 Plugin 방식으로 확장 가능한 구조를 희망합니다.
• 현재 실제 외식업 매장의 POS PC를 실사하여 일부 기술조사를 진행하였으며, 조사 환경에서 OKPOS사의 POSMASTER(oakPOS 계열) 및 외부 데이터 수집 Agent로 추정되는 구조를 확인하였습니다.
• 또한 실제 구축 대상 고객사 환경을 조사한 결과, 매장 POS가 사용하는 로컬 DB는 Firebird(파일 기반 .fdb)인 것으로 확인되었습니다. 엔진 버전은 매장 및 POS 버전에 따라 Firebird 2.x 와 3.x 가 혼재할 수 있으므로, 두 버전 모두를 대응할 수 있는 구조가 필요합니다. 관련 세부 자료는 후보업체 미팅 시 필요한 범위에서 공유할 예정입니다.
• 본 프로젝트는 처음부터 장기간 새롭게 기획하는 프로젝트가 아닙니다. 시장에서 이미 운영되고 있는 동일·유사 시스템의 기능과 운영방식을 참고하여, 기능 목록·화면 목록·데이터 흐름·인터페이스 정도를 간단히 확정한 후 빠르게 개발에 착수하고자 합니다.

필수 과업 범위와 결과물

1-1. POS 데이터 수집 Agent 개발

• 매장 Windows PC에 설치되어 POS의 주문·판매 데이터를 자동으로 수집하는 프로그램을 개발합니다.

① POS DB 접근 및 데이터 수집 (핵심 과업)

• 다양한 POS 솔루션 및 버전별로 로컬 PC에 설치된 POS DB에 접근하여 매출 데이터를 수집하는 Windows Agent 개발
• 1차 구축 대상 고객사의 POS 로컬 DB는 Firebird이며, Firebird 환경에 적합한 DB 접근 방식을 적용
• 향후 다른 POS 환경(MSSQL, MySQL, SQLite 등)이 추가될 수 있으므로, DB 종류 및 환경에 따라 접근 방식을 교체할 수 있는 구조를 적용
• POS DB가 제공하는 인증 방식(ID/PW 등)을 활용하되, 접속 계정 정보가 안전하게 보관·관리되도록 구현
• 매장별로 DB 계정·비밀번호가 상이할 수 있는 점을 고려하여, 매장 단위 접속 정보를 관리할 수 있는 구조로 개발
• POS DB의 인증 방식 및 접근 권한에 따라 Agent가 안정적으로 데이터를 조회할 수 있도록 권한 설정 및 설치 절차를 고려
• POS 프로그램의 정상적인 운영에 영향을 주지 않도록 읽기 전용(Read Only) 방식으로 데이터 조회
• POS DB에서 수집한 데이터를 Agent에서 표준화하여 백엔드 서버로 안전하게 전송
• POS별 DB 구조 및 버전 차이를 고려하여 DB 접속 정보, 테이블/컬럼 구조 등의 변경에 대응할 수 있는 구조로 개발
• 특정 POS에 종속되지 않고, 향후 신규 POS 및 POS 버전을 추가할 수 있는 확장 가능한 구조로 개발

본 과업은 POS 로컬 DB를 원천으로 데이터를 수집하는 것을 표준 방식으로 하며, POS 공식 API · Export 파일 · 로그 파일 · Back Office 서버를 통한 수집 방식은 기본 과업 범위에서 제외합니다.

다만, 다른 방법으로 동일한 수준의 효과(실시간성·정합성·확장성)를 낼 수 있는 기술 경험이 있는 경우에는 해당 방식의 입찰 제안도 허용합니다. 이 경우 제안서에 방식과 실제 적용 사례를 명시해 주시기 바랍니다.

② Firebird DB 환경 대응 (필수 준수 사항)

• Firebird 엔진 버전 2.x 및 3.x 를 모두 대응할 수 있는 구조로 개발 (매장별로 버전이 혼재할 수 있음)
• 버전별 클라이언트 라이브러리(fbclient.dll 등) 및 연결 방식의 차이를 Agent가 흡수하는 구조 — 설치 환경의 엔진 버전 자동 판별 또는 설정 기반 선택 방식 제안
• Firebird 2.x 와 3.x 의 인증 체계 차이(Legacy_Auth / Srp 등)에 대응
• Firebird 설치 형태(SuperServer / Classic / Embedded) 및 서비스 구동 여부에 따른 접속 방식 차이를 고려
• 파일 기반 DB(.fdb / .gdb) 특성상 운영 중인 DB 파일을 OS 레벨에서 직접 복사·이동·직접 열기는 금지하며, 원칙적으로 정상적인 DB 접속 경로를 통해 조회
• 운영 부하 분산 등의 사유로 사본을 이용한 조회가 필요한 경우에는, OS 파일 복사가 아니라 Firebird가 제공하는 온라인 백업 수단(nbackup 등)을 통해 정합성이 보장된 사본을 생성하는 방식으로 제안하고, 사본 생성 주기·디스크 사용량·POS PC 부하 영향을 함께 제시
• 문자셋(Character Set) 및 인코딩 차이로 인한 한글 데이터 깨짐이 발생하지 않도록 처리
• Firebird 버전 업그레이드 또는 POS 버전 변경 시에도 Agent 재개발 없이 대응할 수 있도록 DB 접근 계층을 분리·추상화

③ POS 운영 환경에 영향을 주지 않는 데이터 수집 (필수 준수 사항)

• 매장은 영업 중인 실사용 환경이므로, 데이터 수집으로 인해 POS 프로그램의 주문·결제 등 정상 운영에 어떠한 영향도 발생해서는 안 됩니다.
• 읽기 전용(Read Only) 조회만 수행하며, INSERT / UPDATE / DELETE 및 스키마 변경(DDL)은 일절 수행하지 않음
• POS DB의 테이블·인덱스·트리거 등 기존 구조를 변경하지 않음
• 조회로 인한 테이블 잠금(Lock) 및 POS 프로그램의 대기·지연이 발생하지 않도록 잠금 없는 트랜잭션·격리수준을 적용
• 수집 주기, 1회 조회 건수, 쿼리 실행 시간을 제한하여 POS PC의 CPU·메모리·디스크 I/O 점유를 최소화
• 매장 영업 피크 시간대의 부하 조절(수집 주기 조정, 분할 수집 등) 방안을 제시
• 수집 전용 계정을 사용하고 최소 권한(SELECT 전용) 부여를 원칙으로 하되, 환경상 불가한 경우 대안을 제시
• Agent의 오류·중단·비정상 종료 시에도 POS 프로그램 동작에 영향을 주지 않도록 프로세스를 분리·격리
• 검수 시 POS PC 자원 점유율 및 DB 부하 측정 결과를 제출하여 무영향 여부를 확인

④ 데이터 수집 정합성 (필수 준수 사항)

• POS별 DB 스키마 및 데이터 저장방식 분석 후 적합한 조회·수집 로직 설계
• POS 로컬 DB(Firebird)에서 주문·판매정보 수집
• 주문·판매 데이터 증분(Incremental) 수집
• 동일 주문 중복수집 방지
• 마지막 정상 수집시점 관리
• 매출 확정 이후의 사후 변경까지 반영하는 증분 수집 구조 — 이미 수집·전송된 주문의 취소, 환불, 반품, 금액·메뉴 수정, 결제수단 변경 등이 발생한 경우에도 변경 내역이 누락 없이 반영되어야 함
• "마지막 수집시점 이후 신규 생성된 주문"만 조회하는 방식은 불가하며, 변경일시(수정시각) 기준 재수집 또는 최근 N일 재조회 등 사후 변경을 감지할 수 있는 방식을 제안서에 명시
• 매장 일 마감·영업일 정산 이후에 발생하는 정정 데이터도 반영
• POS에서 주문이 물리적으로 삭제되는 경우의 감지 및 처리 방안 제시
• 매장별·일자별 합계를 POS 원천 데이터와 주기적으로 재대사하여, 차이 발생 시 자동 재수집 및 관리자 알림

⑤ 안정성 및 장애 대응

• 인터넷 장애 시 로컬 임시저장 후 연결 복구 시 자동 재전송
• POS PC 재부팅 후 Agent 자동 실행 및 수집 재개
• 중앙 서버와의 인증 및 암호화 통신

⑥ 설치 · 배포 · 운영 관리

• Agent 자동 업데이트 기능 구현
• Agent 최초 설치 관리 방안(설치 배포 방식, 매장 식별 및 초기 설정, 원격 설치 지원 등)을 제안서에 기술 요청
• Agent 버전, 연결상태, 오류로그, 마지막 수집시간 관리

⑦ 확장 구조

• 신규 POS를 추가할 수 있는 Adapter / Plugin 구조
• 향후 여러 POS로 확대할 예정이므로, Agent Core 전체를 다시 개발하지 않고 POS별 Adapter만 추가하면 되는 구조가 중요합니다.

1-2. 주요 수집 데이터

• POS별 제공 가능한 데이터 범위에 차이가 있을 수 있으며, 1차에서는 아래 데이터를 우선 수집하고자 합니다.
• 브랜드 / 매장 / POS 단말 식별정보
• 주문번호, 주문일시, 주문상태
• 주문·판매 채널 (확보 가능한 경우)
• 메뉴코드, 메뉴명
• 판매수량, 단가, 판매금액
• 주문금액, 할인금액, 실제 결제금액
• 취소·환불 여부 및 금액
• 결제수단 등 확보 가능한 결제정보

1-3. 데이터 수집 Backend

• 각 매장의 Agent가 보내는 데이터를 중앙에서 수신하여 통합 관리합니다.
• Agent 데이터 수신 API
• 브랜드 / 매장 / POS 단말 식별
• 중복 데이터 방지
• 동일 주문의 변경 데이터 수신 시 최신 상태로 갱신(Upsert)하고, 변경 이력을 추적할 수 있는 구조
• POS별 원천 데이터 저장 및 추적
• POS마다 다른 데이터를 공통 데이터 구조로 정규화
• 매장별·일자별·시간대별 판매 데이터 집계
• Agent 상태 및 오류 관리
• 향후 다른 내부 시스템과 연동하기 위한 REST API 제공

1-4. 본사용 웹 관리페이지

• 1차에서는 화려한 BI 시스템보다는, 판매 데이터가 정상적으로 수집되는지 확인하고 가맹본부가 필요한 기본 판매현황을 조회하는 것에 집중합니다.

판매현황 조회

• 전체 매장 및 매장별 매출 조회
• 일 / 주 / 월 매출 조회
• 시간대별 매출
• 메뉴별 판매량 및 매출
• 매장별 판매현황 비교
• 주문채널별 조회 (수집 가능한 경우)

Agent 운영 모니터링

• Agent 설치 여부 및 연결상태
• 마지막 데이터 수집시간
• Agent 오류 확인

주문 상세 조회

• 매출 합계에서 매장별 주문 목록으로 이동하여 주문 상세(메뉴·결제·취소 이력)를 확인할 수 있도록 구성

정합성 대사

• 매장·영업일별 POS 원천 매출과 중앙 집계 금액, 차이금액, 대사상태를 확인하고 차이 발생 시 재수집할 수 있도록 구성

Agent 재수집

• 수집 이상이 발생한 매장에 대해 최근 1일·3일 등 지정 기간의 데이터를 관리자 화면에서 재수집 요청할 수 있도록 구성
• 향후 당사의 구매·발주 데이터 및 다른 내부 시스템과 연동하여 판매량과 구매량을 비교하는 기능으로 확장할 예정입니다.

결과물

• 요구사항 정의서
• 화면 설계서
• 전체 소스코드 (발주사 소유 저장소)
• DB 스키마
• 배포·운영 매뉴얼
• Agent 설치 및 배포 절차서 (최초 설치 · 자동 업데이트 포함)
• 매장 POS 실사 결과 보고서 (실사를 수행한 경우, POS별 DB 구조 분석 내역 포함)
• POS 운영 무영향 검증 결과서 (POS PC 자원 점유 및 DB 부하 측정 내역)

오픈 시점과 예산

• 개발 기간: 계약일로부터 약 45일
• 예산: 1,500만~2,000만원 내외 (부가세 별도)

제안 포함 필수 사항

• 지원 내용은 아래 기준으로 검토합니다.

① 기술 제안

• 적합한 기술 스택과 그 선택 이유
• POS 로컬 DB 접근 방식에 대한 기술 제안 (DB 접근 방식, 접속 계정·권한 확보 방안, 읽기 전용 조회 보장 방안)
• Firebird 2.x / 3.x 동시 대응 방안 (클라이언트 라이브러리·인증 체계·설치 형태 차이 처리 방식)
• POS 운영 환경에 영향을 주지 않는 수집 방안 (잠금 회피, 자원 점유 제한, 피크 시간대 부하 조절, 무영향 검증 방법)
• 매출 확정 이후의 취소·수정 데이터 반영 방안 (변경 감지 기준, 재수집 범위, 중앙 서버 갱신 및 이력 관리 방식)
• Agent 최초 설치 관리 방법 및 배포 전략
• Agent 자동 업데이트 구현 방식
• POS 추가 확장 구조(Adapter / Plugin) 설계 방안

② 매장 POS 실사 관련 협조 요청 사항

• 착수 후 POS DB 구조 분석 및 수집 로직 검증 등을 위해 고객사(가맹점) 매장 POS 실사가 필요한 경우, 아래 사항을 제안서에 구체적으로 기술해 주시기 바랍니다. 실사는 영업 중인 가맹점의 협조가 필요한 사안이므로, 사전에 범위와 일정이 파악되어야 합니다.
• 실사가 필요한 사유 및 실사를 통해 확인하고자 하는 항목
• 실사 대상 매장 수, POS 종류 및 단말 대수
• 1회당 예상 소요 시간 및 총 실사 횟수(차수별 목적 포함)
• 실사 희망 시점 (프로젝트 단계별 일정 기준) 및 영업시간 회피 여부
• 실사 시 발주사·가맹본부·가맹점에 요청하는 협조 사항 (현장 출입, 담당자 동행, POS PC 관리자 권한, DB 계정 정보, 원격 접속 허용 범위 등)
• 현장 방문 없이 원격(원격 접속·화면 공유 등)으로 대체 가능한 범위
• 실사 과정에서 취득한 매장 데이터의 취급 및 보안·비밀유지 준수 방안
• 실사에 따른 별도 비용 발생 여부 (견적 포함 / 별도 청구 구분 명시)
• 실사 일정 지연 시 전체 개발 일정에 미치는 영향 및 대응 방안

실사 대상 매장 섭외 및 일정 조율은 발주사가 지원하되, 필요한 실사 범위와 소요 시간은 제안사가 사전에 산정하여 제시하여야 합니다.

③ 프로젝트 완료 기준에 대한 의견

• 파트너님께서 판단하시기에 어떤 부분이 완료되어야 이 프로젝트가 성공적으로 마무리되었다고 보시는지 제안에 포함해 주세요. 전문가로서 이 프로젝트의 결과물에 대한 의견 부탁드립니다.

④ 동일·유사 프로젝트 수행 경험 (최우선 평가 항목)

• 이번 프로젝트에서 가장 중요하게 보는 것은 동일·유사 프로젝트 수행 경험입니다. 지원 시 아래 내용을 함께 제안해 주시면 검토에 도움이 됩니다.
• 가장 유사한 수행 프로젝트 1~3건
• 당시 연동한 POS 또는 매장시스템 종류 및 해당 POS의 DB 환경
• Firebird DB 연동·수집 경험 보유 여부 (보유 시 대상 시스템 및 버전)
• 실제 적용한 데이터 수집방식 (POS 로컬 DB 직접 조회 방식 적용 여부 및 상세 방식)
• 가능할 경우 익명화된 화면, 구성도 또는 데모
• 기존 개발자산을 이번 프로젝트에 활용할 수 있는 범위
• 권장 개발구조 및 기술스택
• 예상 개발기간 및 투입인력
• 예상 견적

업체 선정 절차

• 지원업체 중 관련 경험과 기술력이 적합한 약 3개 업체와 미팅을 진행합니다.
• 미팅을 통해 실제 수행사례와 기술방식을 확인한 후 최종 개발사를 선정합니다.

본 프로젝트는 POS의 매출 데이터를 안정적으로 수집하는 부분을 핵심 과제로 보고 있습니다. 따라서 이를 직접 수행해 본 경험이 있거나, 유사 기술로 동일한 문제를 해결해 본 노하우를 보유한 업체를 우선적으로 찾고 있습니다.

기타 유의 사항

• 업무범위 변경으로 재등록되었습니다.
• 예전 프로젝트 : <a href="https://www.wishket.
• 예전 프로젝트 : <a href="https://www.wishket.com/project/158507/">https://www.wishket.com/project/158507/

/a