Lumpy Space Princess - Adventure Time
대외활동/GDG Campus Korea x 왓에버 챌린지

[GDG Campus Korea X 왓에버] Whatever You Make - 4주차 회고록

yaebb_82 2023. 10. 10.

 

 

이번주는 좋은 것과 나쁜 것이 무엇이 있었나요?

😃 좋은 것

  • 아무래도 온라인 보다는 오프라인이 소통이 잘 되기 때문에, 서버와 통신을 시도해보기 위해서 강남 카페로 모이기로 했다. 하지만 어쩌다보니 예상치못한 이슈들로 인해 서버 통신을 못하고 헤어지게 되었다.. 그래도 나름 맛있는 저녁을 먹어서 기분전환이 되었던 것 같다 (맛있었으니까 좋았던걸로...^^)

왜 무지 한 마리만 저렇게 돌아가는거지? 의도한건 절대 아님...ㅎㅎ

 

  • 마지막 온라인 모각작을 진행했다. 시간이 얼마 없었기 때문에 각자 할 일을 진행하던 도중, 단체샷 미션이 날라왔다. 이전부터 우리 팀은 매번 포즈를 바꿔가며 사진을 찍어왔기 때문에 이번 미션에 자신이 있었다. 근데 생각보다 참여하는 팀들이 별로 없어서 '우리만 진심인가?' 싶었지만, 씽크빅이 뛰어난 팀이 나타나서 우리는 결국 재치에서 밀려나 랜덤 1팀에 뽑히게 되었다. 그래두 스벅 1잔 꽁으로 받아서 좋았다!

 

 

😟 나쁜 것

  • 이제 개발할 수 있는 기간이 일주일 정도 남았는데, 서버 통신 세팅은 끝났으나 제대로 해보지는 못했다. 팀원들과 회의했을 때, 나는 아무리봐도 일주일 가지고는 턱없이 부족해 보여서 기간 안에 다 못할 것 같다며 부정적인 말만 했었는데, 팀원들은 일주일 안에 할 수 있을 것 같다며 긍정적인 입장이었다. '할 수 있는데 괜히 내가 팀원들의 의지를 꺾는건 아닐까?' 라는 생각이 들기도 했던 것 같다.
  • 마지막 위클리를 진행했다. 역시 내가 생각했던 것과 동일하게 멘토님께서도 기간 안에 다 못할 것 같다고 말씀해주셨다. 시간이 없어도 너무 없는 이 상황을 누가 거짓말이라고 해줬음 좋겠다. 만약 다른 팀들은 기간 내에 다 해냈는데, 우리만 못한 거면 결과물을 못낸 것도 슬프고, 그 원인이 역량 부족이란 소리이기도 하니 그것대로 슬플 것 같았다. 멘토님께서 현시점에서 어떻게 할 건지 고민해보는게 좋을 것 같다는 피드백을 주셨다.

 

 

 

이번주 진행했던 학습/개발 내용은 무엇이었나요?

• 멘토님 원온원

원래 이번주 원온원은 노션으로 진행하는건데, 나는 궁금한 점이 많아서 구글미트로 진행하게 되었다. 원온원을 하면서 신입으로 회사를 들어간다면 어떤 회사가 좋을지, 회사를 고르는 기준 등 현업자 입장에서 많은 조언을 얻을 수 있었고, 멘토님의 일대기(?)도 들으면서 많은 자극이 되었던 것 같다. 그리고 프로젝트 하면서 고민했던 부분들에 대해서도 피드백을 받아볼 수 있었다. 더 열심히 하는 사람이 되야지🔥

영혼 잔뜩 담긴거임.

 

• 본격적인 기능 구현

1) 알림 기능 작업

저번 주차에 Bottom Sheet 구현하느라 꽤나 애를 먹었다. 처음에 Bottom Sheet 내부 버튼들을 전부 TextView/Button으로 구현할까 했다가, 클릭 처리 관련해서 코드가 너무 복잡해져서 RadioButton으로 구현하는 쪽으로 방향을 틀었었다. '완벽하군...' 이라고 생각할 때쯤 다시 디자인을 확인해보니, 알림 간격 설정은 선택을 할 수도 있고, 안 할 수도 있다는 사실을 까먹고 있었다는 걸 깨닫게 되었다. 결국 디자인에 맞춰서 UI 수정 작업을 진행하게 되었다 😇

 

UI 작업이 끝나고 알림 POST, PATCH 작업도 진행했다. 맨 처음 사용자가 알림을 설정할 때에는 갖고 있는 알림이 없기 때문에 POST를 해주었고, 이후에는 한 번 설정해놓은 것을 수정하는 방식이었기 때문에 PATCH를 해주었다. 생각보다 메인 화면에서 진행되는 케이스 분류가 많아지면서 로직이 점점 복잡해져 꽤나 머리가 아팠다.

 

그리고 알림 On/Off 상태를 서버 쪽에 넘겨주는 작업도 했었다. 서버 쪽에서 자동으로 On/Off 해주는 방식으로 구현해놓으셨다고 하셔서 그 로직에 따라 구현을 하게 되었다.

 

 

2) FCM 작업

FCM을 테스트를 위해 FCM 토큰을 서버로 보내는 작업을 진행했다. UUID값과 FCM 토큰 값을 가지고 서버 쪽에서 FCM 메시지를 보내게 되는데, 다행히도 이전에 작업해놓은 FCM 관련 세팅 코드들이 정상적으로 작동해주었다. 에뮬에서 메시지가 너무나도 잘 오는 걸 보고 나도 신기했고, 서버분도 신기해하셨다. (서로 우오오오오- 남발)

 

나는 FCM 메시지만 잘 받으면 되는거라 크게 작업할 것이 없었는데, 서버 쪽에서 로직에 맞춰 알림을 보냈어야 했기 때문에 확인을 위해 계속해서 에뮬에 알림을 보내셨다. 처음에 알림 소리가 너무 커서 올 때마다 깜짝깜짝 놀랬지만...😅 알림 소리를 줄이고 서버분과 계속해서 확인하는 작업을 진행했다.

너무 잘와요...😂 (테스트 중)

 

 

3) 경로 기능 작업

사용자의 현재 위치 + 목적지 정보를 바탕으로 막차 시간 정보와 경로를 보여주게 된다. 처음에 이 부분을 멀티뷰타입 RecyclerView로 구현해야 겠다고 생각하고, 멘토님께 생각한게 맞는지 피드백을 구해봤는데 맞다고 해주셨다.

 

FCM 관련 작업이 끝나고, 피드백까지 받아 확실해진 이후 경로 관련 작업을 진행하게 되었다. 일단 RecyclerView를 사용하고, DataBinding과 ListAdapter를 사용해서 구현하였다. 사실 멀티뷰타입 RecyclerView는 예전에 Header/Footer 구현까지 밖에 해보지 않아서 자신은 없었지만... 여러 우여곡절 끝에 구현해낼 수 있었다. 경로가 화면에 나오는 순간 진짜 진심을 다해 환호성을 질렀던 것 같다. (나 자신 칭찬해ㅠㅠ)

 

 

 

가장 고민을 했던 부분은 무엇이었나요?

• 팀의 진행 방향

멘토님께서 2가지 방법을 제안해주셨다. '데모데이인 26일까지 어떻게든 끝내보겠다'이면 해커톤을 해야할 것 같고, '기간을 늘려서 천천히 해보겠다'이면 데모데이 이후까지 도와줄테니 급박하게 하지 않아도 될 것 같다 였다. 개발 상황이 더딘 현재 상황에서 최선의 선택을 하기 위해 팀원들과 많은 고민을 했고, 최종적으로는 일단 데모데이까지 최선을 다해보고, 그래도 안되면 기간을 늘려서 배포까지는 포기하지 말고 해보자! 라고 결정하게 되었다.

 

• 알림 관련 UI 작업

위에서 언급했다시피, 디자인 시안에서 약간 어긋나게 UI를 작성해놔서 수정이 필요했다. 알림 시간 설정은 여러 개 중에 무조건 하나는 선택해야 되기 때문에 RadioButton이 맞는데, 알림 간격 설정은 CheckBox로 변경해야 될 것 같다는 생각이 들었다. 힘들게 구현을 다 해놨는데, 다시 변경해야 된다는 사실에 순간 아찔했지만... 디자인에 따라야 하기 때문에 눈물을 머금고 바꾸게 되었다. 다행히도 RadioButton 구현할 때 많이 데어서(?) CheckBox는 의외로 쉽게 구현이 가능했다. (휴...😮‍💨) 앞으로는 꼼꼼하게 디자인 시안을 충분히 숙지한 이후에 코드를 작성해야겠다는 생각을 하게 되었다.

 

• 알림 관련 기능 작업

알림 On/Off 관련 작업을 할 때, On/Off 상태값을 서버에 저장해야 했다. 처음에는 당연히 프론트 단에서 직접 On/Off 관련 상태값을 Boolean 값으로 보낸다고 생각을 했었는데, API 명세서를 확인해보니 Request로 넘기는 값이 하나도 없는 것을 확인할 수 있었다. 서버분께 여쭤보니 서버쪽에서 On/Off 상태를 바꾼다고 하셨고, 해당 로직에 따라 구현을 다 해놓으셨다고 전달 받게 되었다. 구현 자체로는 어려울게 없어 서버 로직에 따라 구현을 했지만, 지금 생각해보면 내가 상태값을 서버로 전달해주는게 조금은 프론트 단에서는 더 쉬웠을 것 같다는 생각이 들었다.

 

• 고충 해결

내가 담당한 파트는 아니었지만, 다른 팀원분께서 디자이너님께서 요청하신 대로 적용해보려다 생각한대로 되지 않아 SOS친 부분을 같이 고민해보았다. 화면 크기에 대응해서 View의 크기가 변동되게끔 하는 것이었는데, 나도 처음에 여러 시도를 해봤을 때 잘 되지 않았다.

 

그래도 포기하지 않고 이것 저것 시도를 해본 결과, layout_constriantDimensionRatio를 1:1로 주고, layout_constriantHeight_percent layout_constraintWidth_percent를 각각 0.22씩 주고, 내부 텍스트와 이미지를 묶어서 제약조건으로 가운데에 위치하게 하고, 여러 개의 뷰들을 constraint Flow로 해보니 해결되었다.

 

프로젝트 중에 아무리 바빠도 팀원이 어려워 하는 것이 있다면 한 번이라도 같이 확인해보고, 도울 수 있는 부분이라면 최대한 도와주는 것이 좋다고 생각한다. 이번에 이렇게 같이 고민해보니 오히려 프로젝트의 완성도도 높일 수 있었고, 시간도 단축할 수 있었던 것 같다. 아마 서로에게 좋은 공부가 되지 않았을까 싶다.

뿌듯-😎

 

• 경로 관련 UI 작업

디자인 상에서는 하단에 경로를 다 보여주면 여백이 있게 되는데, 단순히 RecyclerView 자체에 Padding을 주게 되면 스크롤 할 때 굉장히 부자연스럽게 되는 걸 확인할 수 있었다. 뭔가 여백도 별도로 ViewType으로 주어서 처리를 해야 될 것 같았다. 그리고 스크롤을 다 했을 때 회색 영역이 있게 되는데, 이를 고정 값으로 주게 되면 경로가 짧을 때에 이상하게 보여질 것 같아서 고민이었다.

 

멘토님 피드백에 의하면, 동적으로 스크린 사이즈에 맞게 높이를 지정해주면 된다고 하셨는데, 시간적으로 여유가 없어 이 부분까지 고려할 여유가 없을 것 같아 디자이너님과 상의를 해보았다. 회색 영역은 없어도 상관없을 것 같다며, 회색 영역을 제외하고 경로 구현을 우선적으로 하는 방향으로 합의를 하게 되었다.

 

• 경로 관련 데이터 받기

경로 관련 서버 통신을 위해 API 명세서를 받게 되었는데, 예상한 것과는 많이 다른 명세를 받게 되었다.

{
    "code": 200,
    "data": {
        "exWalkTimeList": [
            {
                "exWalkTime": [
                    4
                ]
            }
        ],
        "bodyList": [
            {
                "firstStation": "남영",
                "fastTrainDoor": [
                    "6-3"
                ],
                "laneName": [
                    "1호선",
                    "9호선"
                ],
                "wayName": [
                    "인천.신창",
                    "중앙보훈병원"
                ],
                "lastStation": "흑석"
            }
        ],
        "timeList": [
            {
                "timeList": [
                    "23:25",
                    "23:31",
                    "23:44"
                ],
                "totalTime": "0시간 19분"
            }
        ]
    }
}

처음 받고 살펴봤을 때, 뭔가 비슷한 성질의 데이터들 끼리 묶여있다는 것을 확인할 수 있었다. 나는 ViewType 별로 데이터들을 뿌려줘야 했는데, 과연 이 명세로 가능할까? 라는 고민을 했던 것 같다. 최대한 서버분들께서 작업하신 것들을 변경하지 않도록 하고 싶었으나, 아무래도 힘들 것 같아서 명세 수정을 부탁드렸다.

 

최대한 이해하시기 쉽도록 직접 명세를 어떻게 받고 싶은지 작성해서 드렸고, 그 과정에서 명세 수정 작업이 서버 쪽에서 꽤나 어려운 작업이라는 것을 알게 되었다. 그래도 포기하지 않으시고 요청드린 부분들을 최대한 반영해주시겠다고 하셔서 서버 분들께 정말 감사했다.

 

{
    "code": 200,
    "data": {
        "transferSection": [
            {
                "viewType": "exWalkTimeInfo",
                "data": {
                    "exWalkTime": "3"
                }
            },
            {
                "viewType": "exWalkTimeInfo",
                "data": {
                    "exWalkTime": "4"
                }
            }
        ],
        "bodyList": [
            {
                "viewType": "bodyInfo",
                "data": {
                    "firstStation": "가좌",
                    "lastStation": "용산",
                    "laneName": "경의중앙선",
                    "wayName": "지평",
                    "departTime": "19:48",
                    "arriveTime": "20:01",
                    "fastTrainDoor": "5-1"
                }
            },
            {
                "viewType": "bodyInfo",
                "data": {
                    "firstStation": "용산",
                    "lastStation": "노량진",
                    "laneName": "1호선",
                    "wayName": "인천.신창",
                    "departTime": "20:05",
                    "arriveTime": "20:08",
                    "fastTrainDoor": "6-3"
                }
            },
            {
                "viewType": "bodyInfo",
                "data": {
                    "firstStation": "노량진",
                    "lastStation": "흑석",
                    "laneName": "9호선",
                    "wayName": "중앙보훈병원",
                    "departTime": "20:17"
                }
            }
        ],
        "totalTimeSection": [
            {
                "viewType": "totalTimeSection",
                "data": {
                    "totalTime": "1시간 29분",
                    "departTime": "19:48",
                    "arriveTime": "20:17"
                }
            }
        ]
    }
}

서버 분들과 소통하면서 명세 수정을 계속해서 진행했다. 사실 당시에 멀티뷰타입 RecyclerView를 해본 경험이 없었기 때문에 나조차도 어떻게 명세를 받으면 좋을지 확신이 들진 않았지만, 검색해보니 이런 식으로 받는 것 같아서 이때 서버분들께 이정도면 될 것 같다고 말씀드렸었다. 하지만, 막상 이대로 구현을 해보니 생각했던 것과 다르게 구현되는 것을 확인할 수 있었다.

 

어라... 이게 아닌데... (뒤에는 흐린눈 필수)

 

역시 한 번에 될리가 없지🥲 사실 위의 명세가 고정적으로 똑같이 오는 거면 원하는 대로 구현을 할 수 있었는데, 경로에 따라서 환승 유무와 환승 횟수가 각각 다 달라서 힘들 것 같았다. 죄송하지만 서버분들께 현상황을 공유하고 다시 명세 수정을 부탁드렸고, 마침내 최종 명세가 결정되었다. (우리 서버 체고..🥹)

{
    "code": 200,
    "data": {
        "bodyList": [
            {
                "viewType": "bodyInfo",
                "data": {
                    "firstStation": "가좌",
                    "lastStation": "용산",
                    "laneName": "경의중앙선",
                    "wayName": "지평",
                    "departTime": "19:48",
                    "arriveTime": "20:01",
                    "fastTrainDoor": "5-1"
                }
            },
            {
                "viewType": "exWalkTimeInfo",
                "data": {
                    "exWalkTime": "3"
                }
            },
            {
                "viewType": "bodyInfo",
                "data": {
                    "firstStation": "용산",
                    "lastStation": "노량진",
                    "laneName": "1호선",
                    "wayName": "인천.신창",
                    "departTime": "20:14",
                    "arriveTime": "20:26",
                    "fastTrainDoor": "6-3"
                }
            },
            {
                "viewType": "exWalkTimeInfo",
                "data": {
                    "exWalkTime": "4"
                }
            },
            {
                "viewType": "bodyInfo",
                "data": {
                    "firstStation": "노량진",
                    "lastStation": "흑석",
                    "laneName": "9호선",
                    "wayName": "중앙보훈병원",
                    "departTime": "20:37",
                    "arriveTime": "20:51"
                }
            }
        ],
        "totalTimeSection": [
            {
                "viewType": "totalTimeSection",
                "data": {
                    "totalTime": "1시간 3분",
                    "departTime": "19:48",
                    "arriveTime": "20:51"
                }
            }
        ]
    }
}

 

미리 멀티뷰 RecyclerView를 경험해봤더라면, 서버분들과 명세 관련해서 소통할 때 중간에 이렇게 바뀌는 일 없이 한 번에 처리가 되었을 텐데... 그저 죄송할 뿐이었다...🥲 그래도 이번 기회를 통해 서버분들로부터 받을 데이터를 어떻게 받으면 좋을지 고민해보고, 서로 맞춰보는 경험도 해볼 수 있어서 좋았고, 무엇보다 바뀐 명세를 적용했을 때 성공적으로 구현되어서 너무너무너무 기뻤다!!

만쉐이!!

 

 

 

아쉬운 부분을 개선하기 위해서 필요한 것은 무엇인가요?

새벽 5-6시에 자면서까지 잠을 줄여가며 작업을 하고 있는 요새이지만... 시간이 부족하다는 사실을 어떻게 할 수는 없는 것 같다. 상황적으로 정말 아쉽지만 그래도 최선을 다해 작업하는 팀원들의 모습을 보면서 많이 동기부여를 받았던 것 같고, 나 또한 팀에 민폐를 끼치지 않도록 열심히 했던 것 같다.

 

필요한 개선이라면... 내 작업 속도이지 않을까 싶다. 최대한 삽질을 하지 않고도 구현을 해낼 수 있었으면 좋겠고, 과연 남은 기능들을 기간 내에 완성해낼 수 있을지는 의문이지만... 그냥 다 해냈으면 좋겠다. 현재의 나, 미래의 나 화이텡👊

할 수 있다, 할 수 있다, 할 수 있다!

 

 

다음주는 어떻게 보낼 예정인가요?

다음주는 정말 행사 찐찐찐 마지막이다. 데모데이가 있는데, 작업한 결과물과 현재 상황에 대해서 발표하는 것 같았다. 발표는 팀장님께서 하게 되는데, 우리팀만 배포를 못했을까봐 걱정이다😞 팀장님께서 발표할 때 그래도 무안해 하지 않도록 최대한으로 작업해봐야겠다.

 

 

 

반응형

댓글