Project brief
프로젝트 내용
[프로젝트 개요]
- 외식업 프랜차이즈 가맹점에서 사용 중인 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 단말 식별정보
- 주문번호, 주문일시, 주문상태
- 주문·판매 채널 (확보 가능한 경우)
- 메뉴코드, 메뉴명
- 판매수량, 단가, 판매금액
- 주문금액, 할인금액, 실