킥오프 회의
유빈
- 기업에 요구하는 기술 스택을 유의미한 맥락에서 활용하고 싶다.
- 기술 의사결정과 트러블 슈팅에 대한 문서화를 하고 싶다.
한영
- 협업의 요소를 적극적으로 챙겨가고 싶다. (코드 리뷰, 다른 직군과 협업할 때의 깊은 고민)
- 코드 퀄리티가 어느정도 만족스러웠으면 좋겠다. (유지보수성을 고려한다)
- 솔직히 무탈하고 행복하게 잘 끝나는 게 가장 중요하다.
선정 이유
- SEO: 카페 상세 페이지의 SEO가 유입 수단으로서 중요할 것이다. 특정 카페 검색 시 우리 서비스를 노출시켜 자연 유입이 늘어나는 것을 기대한다.
- 초기 로드 속도: 카페 상세 페이지는 정적인 정보를 다루기 때문에 SSR 적용 시 초기 로드 속도 측면에서 이점이 있을 것이다.
예상되는 문제점
-
코드의 복잡도가 올라감: 클라이언트 사이드, 서버 사이드의 구분이 생기므로 코드의 복잡도가 높아질 수밖에 없다.
-> 기능이 무겁지 않아 MVP를 만드는 과정에서 큰 무리가 없을 것. 더불어 그 복잡성을 잘 다루는 게 프론트엔드 개발자로서 중요한 역량이며, 복잡성을 이유로 선택하지 않는 건 어불성설이다. -
SSR 서버 관련 비용이 발생함: SSR을 구동하기 위한 서버가 추가로 필요해지고 이에 따른 비용이 발생한다.
-> Vercel을 사용한다면, 금전적으로나 관리 측면에서나 서버 관련 추가 유지보수 비용이 크지는 않을 것이다.
테일윈드를 고려했으나, 클래스 덕지덕지로 유지보수성이 떨어진다. 선언적으로 스타일링을 표현할 수 있는, styled-components나 emotion 중 하나를 선택하는 것이 좋겠다고 판단했다.
그외의 기술 스택은 필요에 따라 점진적으로 도입한다.
초기에 복잡한 전략은 불필요하다고 판단했다. main, feature 브랜치만 둔다. 이후 필요에 따라서 전략을 고도화한다.
기능 개발 시 플로우
- issue를 판다.
- issue 번호에 따라서 feat/#XXX의 형태로 브랜치를 딴다.
- 해당 브랜치에서 작업을 한다.
- 작업이 완료되면 메인 브랜치로 PR을 보낸다.
- 코드 리뷰 및 점검 후 머지한다.
feat(some.tsx): 내용
- feat: 기능 관련 변경 사항
- fix: 오류나 비정상적인 것을 바로잡기 위한 사항
- docs: README 작성 등 문서화 관련 사항
- chore: 기타 prefix에 포함되지 않는 변경 사항
- config: 구조 세팅, 설정 파일 수정, 라이브러리 도입을 위한 세팅 코드 작성 등 설정 관련 사항
- style: 코드 스타일 관련 사항. 주석 수정, 포맷팅을 위한 수정 등 실질적인 코드의 변경 사항 없이 코드 스타일이 수정되는 등의 사항
- test: 테스트 관련 변경 사항
- design: UI(스타일링) 관련 변경사항
- refactor: 리팩토링 관련 사항. 기능/동작의 변경 없이 코드 퀄리티 향상 등의 이유로 코드를 수정하는 경우
파일 단위, 폴더 단위 등처럼 절대적인 기준에 의해 구분될 수는 없다. 의미 단위로 "적당하게" 나누는 것이 중요하다. 너무 커도, 너무 작아도 기록으로서의 가치가 떨어질 것이다. 판단 기준이 모호하여 구체적인 맥락 속에서 판단하는 것이 중요한 부분이므로, 이후에 커밋 단위에 관하여 자주 소통하면서 합을 맞춰 나가는 것이 중요해 보인다.
모든 PR에 대해서 리뷰를 한다. 일단 이렇게 진행해보고 오래 걸리거나, 비효율적인 면이 크다고 판단되면 점진적으로 줄인다.