2023-04-16: 개인 프로젝트 도전기 (13주차)
목표 정산
결과적으로는 아래와 같다.
메뉴얼 작성 및 배포프로덕션 단계(3차)에서의 자체 QA 진행 후 발생한 문제점들 수정- 프리 릴리즈 진행
테스트를 해볼 매장에 배치를 진행하고 프리릴리즈를 진행하려고 했으나, 이 사항과 관련하여 사장님과 추가적인 이야기를 오고간 사항이 없어져서 좀 흐지부지되었다.
다만, 그렇다고 배치마저 흐지부지된 것은 아니고 바쁘시느라 이야기할 기회가 없었을 뿐이고 다음주 중에 다시 한 번 더 논의 거쳐서 진행해보려고 한다.
그럼, 이번 주 했던 일들을 끄적여보자.
메뉴얼 작업의 고통
이전에 기획자였던 나에게 메뉴얼 작업은 익숙하면서도 귀찮음과 괴로움을 동반한 작업이었다.
어떻게 쓰이는지를 잘 아는 건 나이고, 만든 것도 나이기에 내가 생각하는 것들을 남에게 이해시키기 위해 작성하는 문서가 기획서이자 가이드, 메뉴얼이기도 하다.
그렇기 때문에 이 문서를 읽는 사람들이 어떻게하면 쉽게 이해할 수 있을지를 고민하면서 적으려고 했는데, 몇 년 동안 했던 작업임에도 여전히 이건 어려운 일이었다.
문서 작업은 링크 공유도 될 수 있는게 좋다고 판단해서 google slide로 작성했다.
디자인이 한정적인 부분들이 아쉽기는 했지만, 그렇다고 읽지 못하는 건 아니기 때문에 이틀을 걸쳐서 열심히 내용들을 작성했다.

작성하다보니까 기능을 어떻게 사용하세요, 보다는 각 화면의 UI 설명만 주구장창 적은 느낌이 있어서 특정 기능들은 이러한 절차로 진행하게 된다는 내용들이 보충되기도 했다.

또한 프로젝트 내에서 아직 개발을 진행하고 있거나, 현재는 고려중이지 않은 사항들에 관해서도 별도로 기록을 해뒀다.

이렇게 차곡차곡 내용을 작성하고 나니까 QA 과정에서 발견하지 못했던 문제점들을 발견하기도 하고, 작성하면서 좀 더 이런 부분이 있으면 좋을텐데 라는 생각도 들었다.
가이드를 작성한다는 게 완성한 뒤에 하나하나 기능들을 다 살펴보는 작업이 되다 보니, 아무래도 이런 데에서도 또 새롭게 발견하는 것들이 있는 것 같다.
작성을 어느 정도 완료한 다음에 내용을 크게 훑어보다가, 요즘 메뉴얼에는 ‘빠른 시작’, ‘간편 메뉴얼’이라고 해서 급한 사람들을 위해 기본만 미리 살펴볼 수 있도록 앞쪽에 가이드를 제시하고 있는 것이 생각났다.
이 서비스를 사용하는 사람들도 분명 읽지도 않고 기능만 빠르게 쓰려고 하는 사람들이 있겠지..라는 생각이 들다보니, 맨 앞 슬라이드에 급한 사람들을 위해 빠른 이용자 가이드를 추가했다.

이틀? 사흘?에 걸쳐 문서 작업을 진행했는데, 완성하고 나니 진짜 기진맥진했지만 그래도 작업하면서 프로젝트를 전체적으로 자세하게 돌아볼 수 있는 기회가 되어서 좋았던 경험이었다.
그리고 다시금, 메뉴얼의 존재가 사용자들에게 왜 필요하고 중요한지도 깨닫게 되기도 했다.
https://docs.google.com/presentation/d/1HN5OPfm7l5S8VCeo8CXRyMxA3dQSdwPnjxFWBrC4Qjk/edit?usp=sharing
Chakra UI의 useBreakPointValue를 활용한 전화번호의 표시 변경
Chakra UI의 useBreakPointValue를 이용하면 반응형에 맞춰서 BreakPoint가 되는 지점에 관련한 내용들을 변경해줄 수 있다.
그럴려면 이제 BreakPoint를 만들어줘야 하는데, Chakra UI가 미리 설정해 둔 BreakPoint가 아니라면 아래와 같이 BreakPoint를 만들 수 있다.
const theme = extendTheme({ breakpoints: { desktop: "30rem", } }); export default theme;
위와 같이 breakpoints에 특정 값을 넣음으로서 반응형 페이지에서 화면에 변화를 줄 지점을 지정할 수 있다.
이렇게 지정한 key 값을 통해 아래와 같이 useBreakPointValue를 활용해 너비에 따라 출력될 내용을 다르게 만들 수 있다.
const userTel = useBreakpointValue({ base: userData.tel.substring(userData.tel.length - 4, userData.tel.length), desktop: userData.tel.replace(/(\d{3})(\d{3,4})(\d{4})/, "$1-$2-$3"), });
base는 기본적인 너비를 가리키고, desktop은 위에서 breakpoints를 지정한 값을 가리킨다.
위의 코드는 화면 너비가 desktop의 너비까지 넘어가지 않을 시엔 뒤의 4자리만 나오도록 하고, 너비가 넓어질 때는 전화번호가 전부 출력되게 설정했다.
이 덕분에 화면 너비에 맞춰 유동적으로 표시할 사항에 변화를 줄 수 있었다.
여담이지만, 이 작업을 진행할 당시에 저장된 데이터는 ‘01012345678’로 되어있기 때문에 이를 관리자나 고객이 볼 때는 ‘010-1234-5678’로 편하게 볼 수 있도록 해주고 싶었다.
이 방법에 대해서 어떻게 처리할 수 있을까 고민했는데, replace() 메소드를 통해서 앞쪽에는 정규식을 붙이고, 뒤에는 정규식 형식을 통해 나온 값을 바꿔줄 값을 적는 형식이었다.
var newStr = str.replace(regexp|substr, newSubstr|function)
따라서, 앞의 정규식을 통해서 뒤의 ${1}-${2}-${3}을 통해 정규식에 맞춰 글자배치를 적용하도록 하니 원하던 대로의 값이 나오게 됐다.
이런 걸 쓰다 보니까 요즘 들어서, JavaScript의 메소드의 중요성을 많이 깨닫기도 했고 좀 더 다양한 메소드를 안다면 다양하게 활용할 수 있겠다 싶어서 기본의 중요성을 다시끔 느끼게 됐다.
메뉴 오픈 시의 매장명을 sessionObject를 활용해 받아오도록 적용
기능 구현을 진행하면서 발생했던 문제 중에, 새로고침을 한 상태에서 관리자 메뉴를 열면 컴포넌트가 전부 리셋되는 문제가 발생했다.
문제의 원인은 useQuery를 쓰는 부분에 있는데, 이는 메뉴에 매장명을 나타내기 위한 목적으로서 받아오게 하는 거였다.
하지만 새로고침을 하게 되면 관리자의 데이터를 다시 받아오다보니, 이 과정에서 메뉴 오픈시에 useQuery가 처음 불러와질 때, 관리자의 데이터가 없다고 판단해 컴포넌트가 망가지면서 페이지가 텅 비어지는 문제가 발생해버렸다.
수정하는 과정에서 어떻게할지 고민하다가 매장명 하나를 받아오기 위해서 useQuery를 쓰는 것도 이상할 뿐더러, 또 DB에 통신을 하는 것 자체도 메뉴창을 여는데 무거움을 줄 수 있다고 판단해서 고민 끝에 로그인에 성공할 때, sessionObject에 매장명 데이터를 저장하도록 했다.
//로그인 로직 내 if (doc.data().firstSetting === false) { userData = { data: doc.data(), uid: doc.id }; } else if (doc.data().firstSetting === true) { // 최초 로그인이 아닌 상황에서 매장명을 storeName으로 세션 스토리지에 저장하도록 했다. sessionStorage.setItem("storeName", doc.data().storeName); setLoadingState(false); return navigate("/adminwaitinglist"); }
그리고 이 내용을 이제 메뉴 컴포넌트에서 아래와 같이 불러오도록 했다.
<Text fontWeight="semibold" margin="0 0.25rem"> {`${data.storeName} 님`} {sessionStorage.getItem("storeName") === undefined ? "" : `${sessionStorage.getItem("storeName")} 님`} </Text>
이 덕분에 불필요한 데이터 통신 횟수를 줄이고, 메뉴 기능도 정상적으로 생각한대로 잘 작동됐다.
날짜가 바뀐 뒤, 데이터를 삭제해도 남아있는 고객 정보의 처리 방법
현재 로직 상에는 날짜가 바뀐 뒤에 오늘이 아닌 데이터들은 전부 삭제하도록 구현되어 있는데, 이렇게 구현되어도 막상 날짜 바뀐 뒤에 접속하면 데이터가 지워져있음에도 useQuery를 받을 때에는 기존 데이터가 남아있는 현상이 있었다.
물론 이 현상은 새로고침을 하든 다른 기능을 켜서 갱신하든 하면 정상적으로 돌아오기 때문에, 처음 페이지를 켜는 그 순간에만 발생하는 이슈라 어떻게 처리할지 고민이 좀 됐다.
더 좋은 방법이 있을 거라고 생각하지만, 당시에 떠오르는 건 날짜를 체크해서 사전에 분류해놓는 것이라고 판단해 useQuery의 코드에 아래와 같은 내용을 추가했다.
const getWaitingData = async () => { const waitingState = await getDocs(waitingCol).then((data) => { const list: any = []; const nowDate = new Date().getDate(); data.forEach((doc) => { if (waitingSetting === "entered") { if (doc.data().isentered === true) { const userData = doc.data(); const dataDate = new Date(userData.createdAt!).getDate(); // 오늘 날짜와 데이터에 있는 생성 날짜와 비교 if (nowDate === dataDate) { // 오늘 생성된 것만 리스트에 넣도록 표시 list.push({ ...userData, uid: doc.id }); } } } else if (waitingSetting === "entering") { if (doc.data().isentered === false) { const userData = doc.data(); const dataDate = new Date(userData.createdAt!).getDate(); // 오늘 날짜와 데이터에 있는 생성 날짜와 비교 if (nowDate === dataDate) { // 오늘 생성된 것만 리스트에 넣도록 표시 list.push({ ...userData, uid: doc.id }); } } } }); list.sort(function (a: any, b: any) { return a.createdAt - b.createdAt; }); return list; }); return waitingState; };
작은 부분이기는 하지만, 그래도 이 덕분에 걱정했던 문제도 해결이 됐다.
다음주에 할 일들
테스트 릴리즈가 연장되면서, 기간이 더 늘어졌는데, 덕분에 프로젝트를 다시금 돌아볼 수 있는 시간이 됐던 것 같다.
다음 주에 할일도 크게 변하진 않을 것 같다.
- 임시 QR 코드 발급창 추가
- 구글 애널리틱스 배치
- 이미지 업로드 기능 구현
- 추가 QA 진행
- 프리 릴리즈 진행
QR 코드 포스터를 건네주기 전까지 QR코드를 발급할 필요가 있을 것 같고, 사용자 통계를 내기 위해서라도 구글 애널리틱스 배치도 필요할 것 같고..
정식 릴리즈 전까지는 이미지 업로드도 구현해서 초기에 생각했던 스펙이 다 완성됐으면 하는 것도 있으니, 조금만 더 분발해서 처음 하고 싶었던 부분까지는 다 완료하고 싶다!