부스트캠프 3주차 - 서울살이

0. 회고

부스트캠프 3주차가 되면서 많은 조들이 자신만의 어플리케이션의 모습을 하나 둘 잡아갔습니다.

저희 서울살이조 또한 서비스를 사용해 볼 수 있을 정도의 단계까지 만들어졌다고 생각합니다.

서울살이를 시작하는 사람들에게 제공하는 매물 정보 서비스

해당 주제에 걸맞게 장소를 검색하고 -> 지도를 통해서 매물과 상권 정보를 확인하고 -> 구체적인 매물 정보를 확인하는

심플한 서비스 로직을 갖고 있습니다. 그와 동시에 직방, 호갱노노, 다방등 부동산 서비스를 제공하는 각종 기업의

어려움과 자체적인 서버를 구축하고 있다는 것의 노고를 간접적으로 느낄 수 있게 되었습니다.

저는 3주차를 진행하면서 아래와 같은 어려움을 겪었습니다.

- 모션레이아웃의 불안정함

- 서버의 속도에 대한 문제

- 불완전한 주소를 통해서 위치 찾기

1. 모션레이아웃의 불안정함

모션레이아웃에는 위와 같이 6가지의 기능이 사용되고 있습니다.

모션레이아웃에 이처럼 많은 기능이 사용되다 보니 프로젝트 내에서 가장 많은 이슈가 있었습니다.

- 모션레이아웃과 리사이클러뷰의 스크롤뷰 겹침 현상

- 모션레이아웃의 이벤트 캐치 문제

- 모션레이아웃의 앵커속성을 지정 안함으로 인한 떨림 현상

이처럼 프로젝트에서 가장 많은 이슈와 가장 많은 시간을 사용하게 되었고,

모션레이아웃을 충분히 공부할 수 있었습니다.

3주차에는 특히, 모션레이아웃과 리사이클러뷰의 스크롤뷰 겹침 현상을 해결하기 위해서 노력했습니다.

문제로는 리사이클러뷰의 nestedscrollingenabled 속성에 대한 이슈였습니다.

리사이클러뷰의 nestedscrollingenabled 속성을 false로 할 경우에는 스크롤에 대한 이슈를 해결하는 대신에

리사이클러뷰의 재활용성에 대해서 잃게 되고, 그렇지 않을 경우에는 뷰의 움직임에 큰 이슈가 있었습니다.

그래서 해결방안으로는 각종 xml값을 정적으로 setting을 한 후에, TouchEvent를 모션레이아웃의 상태값에 따라서

가변적으로 변경을 했고, 또한, nestedscrollingenabled 속성 또한 가변적으로 해서 사용하게 되었지만,

리사이클러뷰의 재활용성을 해결하지 못했습니다.

하지만, 우리가 알고 있는 바텀시트레이아웃과 여러 이벤트들을 모션레이아웃으로 구현할 수 있었습니다.

2 & 3. 서버의 속도에 대한 문제와 불완전한 주소를 얻을 경우 어떻게 매물을 찾아야할까?

 Firebase Hosting과 Firebase Function은 webapp을 타겟으로 나왔다기 보다 쉽게 사용하기 때문에 속도에 대한 이슈가 있을 것이라고 생각했습니다.

확실한 결과값은 없지만, 속도를 더 빠르게 하기 위해서는 Azure나 GCP 같이 Web App을 타겟으로한 호스팅이 필요하다고 생각을 하게 되었습니다.

그래서 Azure를 사용하게 됐고, Azure의 장점은 github의 코드를 자동으로 빌드해서 사용하기 때문에 github 소스코드만 바꾼다면 쉽게 서버를

관리할 수 있다는 장점이 있었습니다.

 

 이렇게 서버를 구축하게 되고, 비교적 빠른 속도를 얻게 되었습니다.

https://seoul42-api-seoul.azurewebsites.net/

호스팅을 하고 난 후에, 새로운 API가 필요해졌습니다.

팀원이 Google Place API를 통해서 얻어온 auto complement 값의 불완전한 주소 값을 갖고 있는 Kakao의 주소 api에 대응 시킨 후에

해당 값을 다시 GeoAPI로 값을 넣고, 그것을 부동산 API에 사용해야 했습니다.

저는 그래서 불완전한 주소값을 매칭시키기 위해서 기존의 API에 추가적인 API를 하나 더 입히게 되었지만,

여기에서 풀지 못 한 이슈를 발견하게 되었습니다. 그것은 바로, 불완전한 주소값과 완전한 주소값이 1:1로 매칭되지 못 해서

완벽하게 해당 주소를 검색할 수 없는 이슈가 만들어졌고, 해당 문제는 해결중에 있습니다.

4. 3주차의 느낀점

3주차 때는 다른 팀들의 프로젝트와 우리 프로젝트를 객관적으로 볼 수 있었던 주차였습니다.

그러면서, 상대적으로 불안해지게 되었고, 어떤 기능을 더 입힐까? 라는 생각을 하게 되었습니다.

하지만, 팀원분의 조언으로 3주차에 현재 기능을 어떻게 더 안정적으로 다듬어야할까? 를 고민해야 한다는 시기라는 것을

알게 되었고, 그에 따라서 현재의 기능을 더 탄탄하게 하고, UI/UX를 다듬고, 어플리케이션을 꾸준하게 유지보수 해서

죽지 않고 깔끔한 어플리케이션을 4주차 때 만들어야겠다는 방향을 잡을 수 있었습니다.

100가지의 많은 기능들보다 1가지의 오류가 눈에 띈다는 좋은 교훈을 얻을 수 있었습니다.