[회고] OnMyTicket 기능 개발 완료
2023.01.15(월)
이제 내가 원했던 기능들은 모두 구현이 완료 되었다.
백앤드를 담당해주시는 OO님께서 서버 개발 완료 후 배포만 해주신다면 테스트를 진행하고 바로 기능개발 작업은 완료된다.
내가 OMT의 핵심 기능
- 대표 3사 영화사를 한 곳에서 예매하기
- 내가 본 영화를 기록하고 나만의 티켓 만들기
이 프로젝트를 구성하면서 내가 가장 원했던 기능들은 위 두 내용이다.
물론 취업준비를 동시에 하면서 진행했기 때문에 빠른 시간내에 개발을 완료하지는 못했지만 애초에 1인으로 천천히 공부를 위한 프로젝트로 기획을 했던 만큼 정말 많은 것들을 배웠다.
대표 3사 영화사를 한 곳에서 예매하기
이 기능을 넣을 수 있다고 생각했던 이유는 초반 프로젝트와 관련된 자료나 API들을 찾아보았을 때 영화 예매와 관련된 프로젝트가 많았기 때문이다.
하지만 프로젝트를 시작하면서 예매 기능을 개발하기 시작했을 때 존재하지 않는 API를 찾느라 많은 시간을 쏟았다. 관련 프로젝트 자료와 코드들을 모두 찾아보았는데 실제 사용가능하게 예매가 되는 것이 아닌 가상으로 예매가 된 것 처럼 처리하는 것들이 다였다. 기획을 진행할 때 참고할 웹사이트, 사용할 API를 따로 관리해놓았지만 정확하게 대표 3사 영화사에서 사용가능한 API가 있는지는 확인하지 않고 진행했던게 패착이였다.
최대한 실제 예매가 될 수 있는 방법을 찾아봤는데 그마저도 결제에서 해답을 찾지 못했다.
그래서 두번째로 생각해 낸 것이 결제는 가상으로 처리하고 실제 영화관에 남은 좌석이나 상영 시간 등을 알아내고 싶었다. 그것과 관련된 프로젝트를 한 개 찾았는데 그 방법이 바로 크롤링이였다.
크롤링?
나는 크롤링이라는 개념 자체를 위 자료를 찾아보고 알게되었다.
웹 크롤링은 일반적으로 정보나 데이터를 추출할 목적으로 World Wide Web을 체계적으로 검색하는 프로세스
이 개념을 알게 되고 위 자료를 찾아봤을 때 정확하게는 모르겠지만 이게 문제가 될 일이 없을까? 라는 생각이 들었다. 혹시나 문제될 만 한 상황이 있을지도 모르기 때문에 더 찾아보았을 때 이 한 문장을 보고 절대 사용하지 말자는 생각을 하게되었다.
저작권 및 서비스 약관 위반: 무단 크롤링은 웹사이트의 서비스 약관 및 저작권 정책을 위반할 수 있습니다.
이 외에도 서버부하, 대역폭 사용량, 보안문제와 관련된 문제들이 있었지만 저 문장 하나만으로도 하지 않을 이유가 확실했다.
그래서 ?
나는 다른 프로젝트들과 차별점을 두고 싶었지만 결국 그렇게 하지 못했다. 사실 나만의 티켓을 만들고 싶은 생각에서 시작된 프로젝트였지만 기본적으로 예매라는 기능을 탑재하고 싶었다.
다른 프로젝트들과 마찬가지로 가상으로 예매가 되는 현상을 주기로 했다. 대신 최대한 디테일하게 만들고 직접예매와 빠른예매를 나누어 유저의 선택폭의 자유를 보장하려 했다. 예매 방식을 두가지로 나눈 이유는 실제 3사 페이지를 보면 빠른예매라는 기능이 있지만 나는 이것들이 실제로 빠른가? 그냥 기본적인 예매 방법이지 않나? 라는 생각을 가지고 있었다.
[3사 영화관 중 하나 예매페이지 사진 넣기 ]
그래서 내가 생각한 로직은 이렇게였다.
직접 예매는 - 가능한 유저가 모든것을 택할 수 있게
빠른예매는 유저가 선택하는 폭을 최대한 줄이고 나머지는 자동으로 택하게 했다.
` - 현재 시간에서 가장 가까운 영화시간 ( BUT 최소 1시간의 여유시간 )`
` - 남은 좌석중 가장 가장자리 뒷좌석`
자동을 원했지만 하지 못한 것
` - 5KM내의 가장 가까운 영화관 자동 선정 후 리스트업 (MAP API 활용 미숙으로 실패)`
` - 결제 방식을 등록 후 유저가 결제 확인만 누르면 결제가 되게 (TossPayment API 활용 미숙으로 실패)`
그래서 나온 결과물은 [ 링크 ]
결과
애초에 기획했던 내용들과 달라지는 점들이 많았고 더 좋은 방향으로 생각이 많아져서 이런 아이디어가 있을 때 마다 서버를 사용하지 않더라도 백엔드 OO님에게 회의를 요청하고 함께 의논하며 더 좋은 방향으로 나아갈 수 있었던 것 같다. 예매 페이지를 얼추 다 개발하면서 파일 구조에 대해서도 정말 많이 후회했다. page.tsx에는 그 어떠한 내용없이 컴포넌트의 조합만으로 작성하려 했었는데 URL은 다르면서 같은 페이지 구성을 계속해서 공유하고 안의 내용만 바뀌는 예매페이지를 만들다 보니 이 생각이 완전히 깨졌다.
변화하는 내용만 컴포넌트식으로 바꾸고 page.tsx의 기본 틀은 고정하되 페이지별 달라지는 Text나 css들은 page.tsx 자체에 작성하기 시작했다.
[파일트리 변화]
물론 어떤 파일 구조가 맞는 건지 잘은 모르겠지만 ( 변명아닌 변명이지만 next.js 13 버전이 나오면서 파일 구조가 많이 바뀌기도 했고 공식 문서를 제외하면 정확한 정보를 찾는게 생각보다 어려웠다. 🥲 )
현재 프로젝트를 하면서 나는 이렇게 하는 방식이 무언가 나에게 더 맞는 것 같고 useclient를 남발하지 않아도 되서 좋았던 것 같다.
전체적인 리팩토링을 진행하게 되겠지만 역시 TypeScript는 파일 구조만 손봐도 칼같이 오류를 알려줘서 따끔하게 혼나면서 배우게 될 것 같다.