TIEAT

QR 입력과 매장 확인을 연결하는 협력사 식대 장부 서비스

대신 입력하는 일은 줄이고, 확인의 책임은 남길 수 있을까?

프로젝트
TIEAT
기간
2026.08 ~ 진행 중
담당 역할
문제 정의 · Next.js PWA · Spring Boot API · 검증 설계

현장 흐름

매장 직원의 역할을 단 한 단계로 줄였습니다.

01 · 협력사 직원QR로 사용액 입력

공개 QR은 확인 대기(PENDING)만 생성

02 · 매장 직원금액 확인

인증된 매장 세션에서 확인

03 · 장부확정 반영

선불 적용 · 초과분 미수금 기록

01 / 문제 정의

계산대에서 반복되는 전달·대리 입력과 장부 확인

  • 01

    협력사 식대 장부를 다루는 매장 현장에서 불편을 직접 겪었습니다. 입력을 대신하는 일을 줄이면서 매장이 같은 금액 상태를 확인할 방법이 필요했습니다.

  • 02

    입력 즉시 확정하는 흐름이 아닌, 매장 확인을 거쳐 장부에 반영하는 구조로 설계했습니다.

기존 업무에서, 바꾸려는 흐름으로

사용액 입력대리 입력 줄이기
기존 업무

협력사 직원이 전달한 내용을 매장이 대신 입력

TIEAT의 개선 방향

협력사 직원이 휴대폰 QR로 직접 입력

금액 확인확인의 책임 남기기
기존 업무

입력된 금액과 확인 여부를 따로 대조

TIEAT의 개선 방향

PENDING 거래를 직원이 확인한 뒤 확정

장부 반영계산 기준을 서버에 모으기
기존 업무

선불 잔액과 초과 금액을 확인해 장부 정리

TIEAT의 개선 방향

확정 시 선불 우선 적용·초과분 미수금 기록

줄인 단계전달과 매장 대리 입력

협력사 직원이 QR에서 직접 사용액을 입력합니다.

남긴 책임매장의 확인과 확정

입력은 PENDING에 머물고 매장 확인 뒤 장부에 반영됩니다.

분리한 범위결제와 장부 기록

결제는 POS가 맡고, TIEAT은 사용액과 선불·미수금만 기록합니다.

02 / 해결 과정

QR로 직접 입력하고, 매장에서 확인한 뒤 확정하기

  1. 01

    협력사 직원이 개인 휴대폰으로 매장 QR을 열어 식대 사용액을 직접 입력합니다. 첫 파일럿에서는 개인 가입 절차를 두지 않아 전달과 대리 입력을 줄이는 흐름으로 설계했습니다.

  2. 02

    공개 QR은 PENDING 생성만 허용합니다. 원본 토큰은 저장하지 않고 hash로 검증하며, 거래 조회·확정·거절은 인증된 매장 권한에만 둡니다.

  3. 03

    확정 시 선불 잔액을 먼저 적용하고, 초과 금액은 미수금으로 기록합니다. 실제 결제는 POS에서 진행합니다.

  4. 04

    매장 화면이 보이는 동안만 2초 간격으로 조회하고, 실패 시 마지막 화면을 유지하며 backoff합니다. 영업 전 예열과 야간 scale-to-zero 스케줄도 코드에 구성했습니다.

구현 중 마주한 문제

실시간 갱신: SSE 계획에서 visible-only polling으로
발생한 상황

초기 SSE 계획은 전용 연결·heartbeat·연결 종료 처리·proxy 검증을 추가로 요구했습니다. 첫 파일럿 규모에서 이 운영 비용이 필요한지 다시 검토했습니다.

바꾼 부분

기존 GET을 재사용해 화면이 보일 때만 2초 간격으로 갱신합니다. 동시 조회를 합치고, 실패 시 마지막 안전 화면을 유지하며 2→30초로 backoff했습니다.

공개 QR이 장부 권한으로 이어질 수 있는 문제
발생한 상황

가입 없이 쓰는 QR은 현장 단계를 줄이지만, QR을 가진 누구나 요청을 만들 수 있고 입력 즉시 장부에 반영되면 오입력과 악용의 영향이 커지는 상황을 우려했습니다.

바꾼 부분

공개 경로는 매장 범위의 PENDING 생성만 허용하고 조회·확정·거절을 차단했습니다. 토큰 hash 저장, 멱등성 키, 공용 rate limit, 폐기·재발급과 kill switch를 방어선으로 두었습니다.

scale-to-zero 이후 첫 요청이 느려지는 문제
발생한 상황

SweetHome에서 비용 절감을 위해 scale-to-zero를 사용하며 첫 요청 지연을 경험했습니다. TIEAT은 영업 시작 시점의 매장 흐름에 이 지연이 직접 영향을 줄 수 있다는 것을 염두했습니다.

바꾼 부분

07:55에 min replica를 1로 올리고 00:00에 0으로 내리는 예약 작업을 구성했습니다. 5분 예열만으로 준비 완료를 단정하지 않고, 실제 Azure 실행과 08:00 준비 상태를 실사용 전 검증 항목으로 남겼습니다.

현재 결과

QR 입력·매장 확인·선불·미수금 기록까지 구현했습니다.

03 / 회고

매장 실사용을 앞두고.

단계를 줄일 때는 함께 사라질 책임부터 확인해야 한다고 판단했습니다. 그래서 대리 입력은 줄이고 매장 확인은 남겼습니다.

AI와 함께 일하는 방식의 변화

사람의 판단과 AI의 실행 경계

제품의 문제·우선순위·비즈니스 규칙과 보안 기준은 사람이 결정하고, AI는 합의된 범위 안에서 구현하도록 Local Harness를 만들었습니다.

작은 작업은 필요한 범위만 빠르게 검증하고, 범위가 불명확하거나 보안·배포 판단이 필요한 순간에는 사람이 다시 개입합니다. 실제 변경 내용과 명령 결과를 확인하며 실행하지 않은 검증은 NOT_RUN으로 남깁니다.

Local Harness 저장소 보기 ↗개발 방식 한눈에 보기 ↗

다음으로 검증할 질문

현재 설계를 바탕으로 더 확인해야 할 항목입니다.

  • QR 입력부터 매장 확정까지 걸리는 시간과 직원 개입 횟수
  • QR 폐기·재발급과 비정상 입력 제한의 현장 대응
  • 07:55 예약 예열 이후 08:00 준비 상태와 야간 scale-to-zero
  • 실제 휴대폰·태블릿의 네트워크 단절과 재시도 경험