어제보다 한걸음 더

231020 코드스쿼드max 자유 프로젝트 2주차 회고 본문

회고

231020 코드스쿼드max 자유 프로젝트 2주차 회고

지안22 2023. 10. 20. 18:23

또 정신없는 일주일이 지났다.
이번주에 한 일로는 크게 1. 기획 마무리, 2. API 명세서 작성, 그리고 3. 디자이너를 영입 한 일이 있었다.

1. 기획 마무리

기획은 저번주에 마무리를 하는것이 목표였는데, 이런 저런 경우의 수를 고려하고 프로젝트를 함께 진행하는 동료와 서로의 생각을 맞추는 등 생각할 일이 많아서 계획보다 늦어지게 되었다.
하지만 기초를 단단히 한 만큼 중간에 무언가가 갑자기 바뀌게 되는 일이 줄어들 것 같다고 생각했다.

고민한 부분

1. 검색 페이지(피그마 2페이지)
    - 지역과 공연장명 둘 다 검색할 수 있어 지도에서 어떻게 보여줄 지 고민이 생겼다.
        1. 검색한 리스트가 없는 경우
            - 검색 결과가 없는데 지도의 기본 위치를 어디로 할 것이냐..
        2. 검색한 리스트가 많은 경우
            - 지도에서 모든 결과를 보여줄 것이냐, 아니면 한 곳만 포커싱해서 확대해서 보여줄 것이냐

2. 공연장 목록 페이지 - 필터 기능 (피그마 3페이지)
    - 공연 시간만 검색했을 때는 기준되는 날짜가 없어, 제한 조건이 복잡해지는 문제가 발생했다.
        - 또한 현재 날짜 기준으로 검색 할 때는 모든 요일마다 해당 시간만 검색하고 싶은 경우에 불편한 상황이 생겼다.
    - 따라서 공연 일정과 공연 시간 검색을 합쳐서 검색하기로 했다. 공연 시간만 선택할 수는 없다.

2. API 명세서 작성

지도 api 정하기

- 문서화가 잘 되어있는 카카오지도와 고민했지만, 디자인적으로 봤을 때 선호도가 높았던 네이버 지도로 결정
- 지도를 안해봐서 우리가 원하는 api가 있는지 찾아보느라 api 명세 짜는데 오래걸렸는데, 그래도 시오가 정리가 잘 해줘서 살았다! 후후

관리자 페이지

공연과 공연장에 대한 CRD는 일단 관리자(개발자)만 관리하기로 했기 때문에 관리자 페이지가 은근히 api 명세에서 비중을 차지했다.
(+ 문의글에 대한 답변, 수정, 삭제도 관리자만 가능)
- 따라서 관리자 페이지에는 우선순위를 낮게 두고, 주요 기능을 먼저 구현하기로 했다.

SNS(하이퍼 링크)를 위한 테이블

디자인에 따라 링크가 버튼이 되거나 버튼이 링크가 되거나 할 것 같아서 SNS에 대한 테이블을 어떻게 나눠서 관리해야할지에 대한 고민이 있었다.
일단 백에서는 링크를 테이블로 묶어서 관리하기로 했다.
또 종류에 대한 목록은 java에서 enum으로 관리하기로 했다.


3. 디자이너 영입

원래는 디자이너가 잘 구해지지 않는다고 들어서 외주를 맡기려고 했었는데, 렛플에 디자이너 구인 글을 올린지 이틀만에 연락이 왔고, 다행히 함께 프로젝트를 진행할 수 있게 되었다.
우리의 기획서와 피그마로 틀을 잡은 대강의 화면과 와이어프레임을 보시고 며칠만에 뚝딱 시안을 완성해주셨는데 시안일 뿐인데도 너무 예뻐서 역시 전문가는 다르다 싶었다.
디자이너 분께서 디자인 뿐만 아니라 프로덕트 디자이너이시다 보니까 기획도 참여를 하시는데, 기획에 아이디어를 제시해주시면 DB 아키텍쳐를 어떻게 바꿔야할지 바로 생각이 나지 않아서 아쉬웠고, 디자이너와 협업을 한 것이 처음이다보니 사용하시는 용어같은 것이 잘 모르는 것이 있어서 아직 내가 성장할 부분이 많구나 싶었다.

+ 악기 종류에 따라 필터링 된 공연을 보여주는 기능(+추가 고민)

악기 종류에 따른 필터링 기능 추가를 고려하기 앞서, 모든 공연의 목록을 보여주는 기능을 추가하는 것이 보기 편할 수도 있겠지만(지금은 하나의 공연장에 해당하는 공연 목록만 볼 수 있도록 구성했다)
1. 해당 공연에 어떤 악기가 등장하는지 보여주면 좋을 것 같다는 생각이 있었고
2. 원하는 악기가 들어가는 공연만 필터링해서 보여주면 좋을 것 같다는 생각이 있었다.
(색소폰, 보컬 등 메인되는 멜로디 악기가 들어가면, 재즈 입문하기에 좋은(재밌고 신나는 음악 위주의) 공연이 된다.)
일단은 프로젝트 기간 안에 다 구현하지 못할 것 같아 우선순위에서 밀린 기능이지만, 구현하면 좋을 것 같아서 추가로 작성하게 되었다.
또, 추가하게 된다면 DB 구조를 어떻게 가져갈지 고민해보면 좋을 것 같다.
(악기 종류에 대한 데이터를 Java에서 enum으로만 관리하는게 좋을지, 아니면 DB에 넣어놓으면 좋을 지, 해당 공연에 대한 악기 목록을 어떻게 DB에 저장하면 좋을지 고민이 있었다.)

+ 남세의 네트워크 스터디

프론트 마스터이신 남세가 저번주부터 네트워크 강의를 해주고 계신데, 조금 빡세다.
이상적으로는 1. 책으로 예습 2. 강의 들으면서 모르는거 질문 3. 책 다시 읽으며 복습 하면 좋을 것 같은데, 책을 읽는 속도가 느려서 항상 2, 3번만 수행하는 것 같아 아쉬움이 남는다. (2번의 모르는거 질문도 예습 해와야 더 좋은 질문을 할 수 있을텐데 아쉬움이 남는다)
다음주에는 시간 관리를 잘해서 아쉬움이 덜 남도록 노력해야겠다고 생각했다.