01 / 서비스 소개
근무하던 매장에서 종이 식대장부의 번거로움을 발견하고 사람이 확인하는 불필요한 과정을 줄이고 싶어서 만든, 디지털 식대 장부 서비스입니다.
02 / 선택과 실행
장부 → QR 번거로운 계산 → 한 화면
직원이 장부를 꺼내고, 협력사 직원이 금액을 적고, 매장에서 확인한 뒤 비정기적으로 합산하던 과정이 번거로웠습니다. 종이 장부를 화면으로 옮기는 데 그치지 않고, 기록할 때의 준비 과정과 정산할 때의 계산 부담을 함께 줄이고 싶었습니다.
| 기존 종이 장부 | TIEAT에서 바꾼 흐름 |
|---|---|
| 장부 준비 · 수기 입력 직원이 장부 꺼내기 | QR로 바로 기록 장부를 꺼내거나 건넬 필요 없이, 협력사 직원이 휴대폰으로 금액을 입력합니다. |
| 매장에서 내용 확인 종이 장부에 적힌 금액을 확인합니다. | 매장에서 확인·확정 입력은 간단하게 열되, 장부에 반영할 금액을 확인하는 권한은 매장에 남겼습니다. |
| 기록을 모아 계산 비정기적으로 정산할 때마다 장부 기록을 모아 합산합니다. | 정산 내역을 한눈에 확정된 사용액에 선불 잔액을 적용하고 초과분은 미수금으로 기록해, 정산에 필요한 금액을 한 화면에서 확인하도록 했습니다. |
줄이려 한 것은 장부를 준비하고 기록을 다시 계산하는 일입니다. 금액을 확인하는 사람의 판단은 남기고, 실제 결제는 기존 POS에서 진행하도록 범위를 정했습니다.
03 / 결과와 배움
편리하다는 반응과 사용 의사를 확인했습니다. 장부 이관, 직원 교육, 식대 장부 빈도 수 감소로 지속적인 사용으로 이어지지 못했으나, 현장 문제를 발견하고 개선해 나가며 실시간으로 효과를 눈으로 볼 수 있는 경험이었습니다.
Azure 인프라 구성
거래 · 선불 · 미수금
이미지 빌드부터 배포까지
- GitHub ActionsWeb / API 이미지 빌드
- Azure Container Registry컨테이너 이미지 저장
- Container Apps검증된 이미지 digest로 배포
Bicep으로 기반 리소스와 앱 구성을 정의하고, 배포 전 변경 내용을 확인했습니다.
구현 중 마주한 문제
실시간 갱신: 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 준비 상태를 실사용 전 검증 항목으로 남겼습니다.