데이터 모델링
FireStore에 적용할 데이터 모델링을 수정했다.
팀원들이 각자 정리한 데이터 모델링을 팀원의 의견에 따라 보기 좋은 형식으로 구성을 해보았는데 - 정리를 하면서 깨닫거나 궁금해지는 포인트들이 있어 남긴다. 
Firestore은 API를 활용해서 데이터를 호출해 오던 방식과 달랐다.
JSON 형식이 아닌 문서 Collection 형식을 가졌기에 데이터 접근 방식이 달라져 보였다.
JSON은 하나의 나무로 데이터가 우후죽순 자라나는 모습을 가졌다면,
collection 문서는 조금 더 정돈된 형식으로 다가왔다. 한 컬렉션 속에 도큐먼트를 통해 세부 데이터를 접근할 수 있었는데 - 어색했던 점은 subCollection이 가능하다는 점이었다. User collection의 review 도큐먼트를 들어가도 subCollection으로 Review collection이 들어갈 수 있다는 점이었다. 이는 도큐먼트는 다른 타입의 데이터들을 담을 수 있기에 한 쪽에서 발생하는 데이터 변화를 기록한다는 점이었다.
쉽게 말해 클래스에서 생성된 객체의 값이 바뀌면 다른 객체들에도 변화를 주듯이 비슷하게 행동한다는 점이다.
초기 데이터는 팀원들끼리 각자 필요한 데이터를 간단하게 서술한 것으로 끝냈었는데, 어떤 기술 혹은 무엇을 채용하는지에 따라 데이터 형식을 바꿔야한다는 점이 인상 깊었다. 그동안 API만 호출해서인지 JSON 형식에 너무 익숙해진 나머지 색다른 경험이라 느껴지게 됐다!
기술적 고민
오늘 윤정현 매니저님으로부터 몇가지 질문을 받았는데 - 받으면서 스스로 개발자가 되기에는 멀지 않았을까라는 생각을 하게 됐다.
그동안 모든 프로젝트에선 구현에만 집중했었다.
나름의 핑계를 둔다면 구현하기에도 바빴었다 생각한다.
하지만 개발자로써 개발을 한다는 점이 '코딩'을 하는 것이 아닌 '관점'을 다르게 둬야 한다는 점을 어깨너머나마 보게 된 것 같다.
한 예로 로그인과 회원가입 시점에서 표현 정규식으로 데이터 유효성 검사 혹은 옳바른 데이터 여부를 확인한다고 한다. 위처럼 특정 패턴으로 검사를 하는 과정을 거친다고 이해하면 되겠다! 이제 구현해야 하는 입장으로써 처음 해당 코드를 봤을 때 이해하기 어려웠다. 그렇기에 만능으로 보여졌는데 - 매니저님은 해당 정규식을 사용하는 입장에서 생각을 한번 더 해보는 과정의 중요성을 알려주었다.
만능으로 보이는 정규식도 단점이 존재하다는 점을 일깨워주지 않았나 싶다.
단순히 구현을 하는 '코더'로써의 입장와 '개발자'의 차이를 본 기분이랄까.
공부를 해봐야겠지만 결과론적으로 해당 정규식을 쓰게 된다하더라도 기술을 채택하게 되는 과정과 내 생각의 중요성을 다시 한번 깨닫게 됐다.
