서막..

현재 버X킹에서 사용 중인(내가 일하던 매장..) 프로젝트에 대한 회고를 진행하려고 합니다.

아! 프로젝트에 대해 간단하게 설명해보자면 입력 값 검증 및 사용자 편의 제공을 위한 서비스로 Burgerput이라는 귀여운 이름의 서비스입니다...

프로젝트 배경..

저는 무려 3년간 해당 매장에서 발바닥에 불이 나도록 햄버거를 만들어왔습니다... 이 프로젝트를 함께 진행한 백엔드 개발자인 Yellta씨도 마찬가지 ㅋㅋ.

근데 이 버거X에는 매일 오전과 오후에 나누어 수행해야만하는 과업이 존재합니다... 바로 Zenput.

Zenput은 오전과 오후에 걸쳐 햄버거(대표적인 예시)에 들어가는 패티가 덜 익지 않았는지, 혹은 과조리 되었는지, 냉장고 내부의 식품들이 신선하게 보관되고 있는지 등등 온도를 체크하고 기록하는 시스템입니다.

즉 고객에게 올바른 제품의 품질을 제공하기 위해 식품 및 사용하는 기기의 온도를 기록하는 시스템입니다..

여기까진 좋습니다.. 식품 업장이라면 당연히 해야 될 일이니까요. 근데.. 이 Zenput에는 치명적인 문제점이 하나 있는데 예를 하나 들어보겠습니다.

1. Zenput 사이트 내에 너X킹의 온도를 기입하려고 한다.
2. 너겟X을 조리한 후 해당 식품의 온도를 탐침 온도계를 이용해 체크한다.
3. 175ºF가 나와 Zenput에 입력하려고 한다!
4. 해당 항목에 대한 최소 값은 140ºF로 제품의 품질은 양호하다는 것을 확인했고 이제 입력하려고 한다!
5. 아차차! 손가락이 미끄러지며 1755ºF를 입력해버려 지옥에서 온 용암 X겟킹이 탄생했다.

그렇습니다.. 온도를 기입하는 과정에서 최소 값은 제공하나 최대 값을 제공하지 않는다는 점입니다.

이는 상식적으로 나올 수 없는 온도가 입력될 수 있으며 시스템은 이를 크게 신경 쓰지 않는다는 점입니다.

아니 뭐 여기까진 상관 없지 않나? 어차피 정상적인 온도는 내가 직접 확인했으니 식품의 품질은 이상이 없지 않냐고 생각할 수 있는데..

문제는 이렇게 잘못 기입 된 온도는 REV 심사에서 치명적인 감점 요인으로 작용합니다.

아니 REV는 무엇인가요??

REV는 매장의 운영 상태를 불시 점검하는 시스템으로 간단하게 설명하겠습니다.. 사실 안 궁금하실 수 있는데 읽어주세요!!!!!!!!예!!! 제가 3년간 고생했습니다.

하여튼 해당 심사에서 25점 감점 시 심사 위원은 해당 매장에 F를 부여하는데 F 등급을 3회 연속 수집할 경우… 폐점인 것으로 알고 있습니다.

그런데 여기서 문제가 하나 발생하는데 Zenput 오기입은 25점 감점 중 무려 16점에 해당하는 그냥 걸리면 손 발 벌벌 떠는 요인 중 하나입니다..

위는 실제로 프로젝트 제안서를 제작할 때 90일간의 Zenput 입력 데이터를 직접 눈알이 빠져라 확인해서 수치화한 오기입률 입니다.

아니 X거킹에 밥 먹으러 가봤으면 모두 아는 사실인데.. 진짜 바쁩니다. 내가 3년간 어떻게 그곳에서 버텼는지 모를 정도로 너무 바쁘고 사람을 미치게 하는 곳입니다.

근데 그 속에서 어떻게 여유롭게 티타임을 즐기며 온도를 기입하겠습니까? 그렇게 바쁘게 입력한 결과 우리 매장의 오기입률은 상상을 초월할 정도로 높아졌습니다..

이런 배경 속에서 오기입 방지와 편의성 제공을 위해 등장한 프로젝트가 바로 Burgerput입니다..

개발 과정..

개발은 WBS에 근거해 진행했습니다.

1. 프로젝트 기획 - 프로젝트의 배경, 목적, 기대 효과, 시스템 구축 환경 및 Role 분배 등 전체적인 구조 기획.
2. 분석 및 설계
   • Zenput 시스템의 문제점과 이를 해결하기 위한 요구 사항을 분석해 요구 사항 명세서 제작
   • 요구 사항에 따른 유저 플로우 및 로직 플로우 제작
   • 화면 설계
   • 클라이언트와 서버 간의 데이터 통신을 위한 API 명세 정의
   • DB 구조 정의
   • 아키텍처 구성
3. 개발
   • 프로젝트 일정을 시각적으로 명확하게 보여주는 간트 차트 사용
   • branch를 이용해 기능 개발 및 정상 작동 확인 후 merge
4. 배포
   • 처음 배포 과정은 백엔드와 프론트엔드 gradle을 이용해 모두 한번에 빌드한 후 jar 파일을 EC2에 올려 nohup을 사용해 배포했습니다.. ALB를 이용한 https 적용 등 이 과정이 정말 고난의 연속이었는데 지금 생각해보면 성장하는 재미가 있었네요..
   • 현재는 프론트와 백이 분리되어 S3 버킷의 정적 웹 호스팅 기능을 이용해 프론트 단을 배포한 후 cloudfront로 캐싱하고 있으며 서버 단은 분리하여 EC2로 배포해 통신 중입니다.
5. 배포 자동화
   • github actions를 이용한 지속적 배포

간단하게 위와 같이 진행했습니다..

뭔가 간단해 보이는데 정말 다사다난 했고 중간에 포기하기 직전까지도 갔던 기억에 정말 눈물이 앞을 가리는데 숨 고르기겸 이쯤에서 글을 마무리해보려고 합니다..

예고..

crontab과 curl을 이용한 로딩 로직 자동화하기