빠른 약속 시간 체크할 때, 언제 볼까?
언제볼까? FE ver1 개발이 끝났다.
언젠가는 기술블로그에 정리를 하겠거니... 하며 1월부터 컨벤션이 도입된 김에 PR을 꽤 꼼꼼히 써놨는데 ...어짜피 나 FE 혼자 개발하지만...
그게 ver1이 끝나고나서야 쓸 줄 몰랐지만... 하여튼 지금 안쓰면 FE ver2이 끝나고서야 쓸거 같아, 내 지난 삽질과 어떤 문제를 포착하여 '왜' 어떤 이유로 이렇게 해결했는 지 기록해보고자 한다.
서비스 설명
약속 잡기 힘든 시람들이 만든, 더 많은 만남을 위한 서비스
우선, 설명에 들어가기 앞서 본 '언제볼까?'프로젝트는 위 모토의 웹앱 서비스이다. 모임장이 캘린더에서 날짜와 시작, 종료 시간대를 정하여 약속을 생성하고, 해당 약속의 공유 링크를 받아 모임장과 모임원은 만날 수 있는 시간대를 작성한 뒤, 공동 캘린더에서 이를 확인한다.
서비스의 selling point는 다음과 같다.
1. 원터치로 손쉽게 약속 잡기!
2. 여러 약속들은 서비스 하나에서 한번에 관리!
3. 기존 when2meet같은 약속 서비스보다 접근성 강화되고, 내수 시장에 익숙한 UI, UX!
UI 개발
우선 9월에 막 본 프로젝트에 착수했을 때, React와 CSS라이브러리 자체에 대한 이해도가 낮았고 '왜 써야하나?'에 대한 필요를 못 느꼈다. 사실 당시까지만 해도 그냥 className 다 다르게 하는 식으로 해도 무방한 수준의 짧은 코드였다.
작년 9월부터 12월까지 개발한 Monthview, weekView(개발은 했으나 당장 말고 이후 추가 기능에 넣기로 했음), invite, indivual Calendar, eventCalendar 페이지에는 모두 기본 CSS를 적용했다!
'왜' tailwindCSS? 한계?
작년 9월부터 시작한 교내 IT동아리인 KUIT 4기 WEB 부원으로써, FE 스터디에서 CSS-IN-JS, tailwindCSS 등 CSS관련 여러 기법과 라이브러리에 대해 배웠다.
향후 유지 관리의 용이함 및 협업에 있어 CSS 라이브러리의 사용은 꽤 중요한 점을 깨닫고, 그래서 방학 기념으로 1월에 Landing페이지를 포함한 이전에 개발한 모든 페이지를 tailwindCSS와, 그를 도울 clsx, class-variance-authority 라이브러리를 사용하여 모두 리팩토링 하였다.
tailwindCSS를 선택한 이유는 알아본 결과 문법이 굉장히 쉽고, 꾸준히 업데이트가 잘 되어 여러 복잡한 CSS 기능을 지원한다고 해 선택했다.
그러나 막상 써보니 코드가 깔끔은 한데 더 복잡해지는 느낌이 없잖아 있었고,
그렇다고 현재 하드코딩된 CSS 코드를 그대로 냅둘 수도 없었다.
clsx와 class-variance-authority 도입
딱 className="eventCalendar-header"하는거보다 매번 className="w-2 h-2 어쩌고 저쩌고..."가 가독성 면에서 항상 좋은지는 확신하기 어렵다.
이에 이러한 문제를 해결하고자 조건부 상황에서 동적 클래스를 적용해야할 때 가독성을 높이는 clsx, 코드 재사용성을 높이는 class-variance-authority 라이브러리도 함께 도입했다.
특히 class-variance-authority는, color.ts모듈과 typograhpy.ts에 적용하여 재사용성을 크게 높였다. 이전에 작성된 CSS는 정말 하나하나 #FFFFFF 이런식으로 하드코딩되어 작성되었기에 (...) 리팩토링의 효용을 크게 맛보았다.
모듈화
색상하는 김에 버튼도 모듈화했는데, 처음에는 만들면서도 모든 페이지에서 쓸 총 버튼 개수가 몇 안되는데 이정도 수고를 들여아하나? 생각했다.
그런데 버튼이 단지 selected, unselected 상태 뿐만 아니라 예를 들어disable, hover, focus 이런 상태까지 여러 개 있으므로, 상태를 조합해서 나올 수 있는 가짓수를 생각하니, 생각보다 꽤 되었다. 모듈화 하기 잘했다.
React 기능 개발
사실 가독성에 있어서 UI 개발 -> 기능 개발이 보기 편할 거 같아, 포스트 상에서는 임의로 위와 같이 구성했다. tailwindCSS 도입 이전에 앞서 이러한 PR들이 올라갔고, 새해부터 대략 일주일 넘게 나를 애 먹였던 individualCalendar 스케줄 데이터 처리 관련 버그 이슈 버그에 대해 포스트 해보고자 한다. (Issue는 팀장님이 올리셨긴하나 내용 자체는 Slack에서 내가 제보한 내용이었다)
FE? BE? 어디서 오류가 난걸까...
여러번의 Slack에서 총 107개의 댓글을 빙자한 토론이 오갔고...
이슈의 요지는 다음과 같다.
- FE → BE (http://localhost:8080/api/v1/schedule/updateSchedule) 데이터 전송, BE에서 해당 시간대로 저장
- BE(http://localhost:8080/api/v1/schedule/getUserSchedule?appointmentId=${appointmentId}&userName=${name}) → FE 저장된 데이터 response
- FE에서 UI 렌더링
이 3가지가 모두 정상 작동하는데, 정작 사용자가individualCalendar에서 저장한 시간대 값이랑 이후 재로그인하여 화면에 나타난 individualCalendar의 시간대 저장값이 전혀 달랐다...!!
이에 BE에서 데이터가 가공될 때 뭔가 이슈가 발견한 것으로 확인, 제보했다.
Github Issue 페이지에서 수차례의 논의와 FE,BE 각각의 코드 수정 끝에 사용자가 입력한 시간대보다 9시간의 시차를 가진 시간대가 저장된다로 버그를 규칙성 있게 만드는 데 성공했다! 야호~
그러나 여전히 문제가 해결되지 않아 계속해서 코드를 디버깅해가며 검토하던 중, 팀장님께서 solution을 내놓으셨다.
결론적으로는 Spring 실행 환경에 따른 시간 문제로 결론났다.
왜 똑같은 ec2 서버 주소로 요청을 보내도, public 환경의 https 서버 주소에 요청을 보내도 팀장님 노트북에서는 되고 내 노트북에서는 안될까? 라는 지점이 못내 답답했는데 깔끔하게 해결되는 순간이었다.
앞으로 마주할 버그가 단순히 FE, BE에 있는 거라기보단 이런 식으로 FE와 BE 그 사이 어딘가를 헤매는 버그가 대다수일것이다.
이런 버그가 발생했을 때, 버그의 원인과 버그가 일어나는 상황을 하나하나 테스트해가며 찾다보니 야크 털 깎기에 빠지기 무척 쉬웠다.
이에 여러분이 이런 FE와 BE 사이의 버그를 탐색해야할 때, Slack과 Github Issue, Jira를 활용하여 매순간 내가 무엇을 찾고자 어떤 과정에 있고, 무엇을 발견하며 다시 돌아가서 다시 탐색해볼 건지, 즉 일련의 Issue Tracking과정을 매 순간 다소 강박적으로라도 되새김하며 했으면 한다.
실제로도 이런 태도가 도움이 되었다.
공유하기에 관하여
본 '언제볼까?' 서비스의 핵심은 약속에 참여할 모든 사용자의 겹치는 시간대를 보는 데 있다.
그러기 위해선 약속 링크를 공유해야했고, 당초 나온 계획은 클립보드 링크 복사, 카카오톡 공유, 그리고 마지막으로 다른 앱으로 공유가 있었다.
클립보드 링크 복사는 딱히 언급할 필요도 없이 무척 쉽게 구현했다.
카카오톡으로 공유하기의 경우, 처음 해보기는 했으나 (사실 이 프로젝트에서 하는 모든 게 처음이긴하다...) 공식문서가 꽤 깔끔하게 적혀있기도 하고 카카오 DevTalk에서 역대 토론이 잘 적혀있어서 쉽게 구현할 수 있었다.
다만, 카카오 앱 키를 발급하여 로컬 .env에만 등록하고 정작 Github Actions에서 주입될 앱 키를 Github Secret 기능에 등록을 깜박하여 조금 난항을 겪긴 했다.
제 노트북에서는 돌아가는데요?
그 다음은 그 문제의 다른 앱으로 공유 기능... 프론트엔드 단에서 구현할 때 쓰는 Web Share API로 구현하는데, 해당 라이브러리를 써번 사람은 알겠지만 온갖 이슈가 많다.
당시 발생했던 이슈 상황에서 참고했고 실제로 해결이 됐던 solution이 담긴 기술블로그 글은 다음과 같다.
디버깅(로컬) 환경에서 아예 동작하지 않을때, 공유하기 실패 시,alert 처리를 해주었음에도 불구하고 아무런 반응이 없을때
또, 전체적인 코드의 구조와 쓰임새를 참고할때는 이 글을 참고하였다.
그 외에도 애주가 유저를 위해 술 정보,,,?를 저장하는 기능이 담긴 사이드 프로젝트 기술블로그에서 코드 컴포넌트화의 이해와 Web Share API에 대한 이해도를 얻어갈 수 있었다.
개인적으로 해당 사이드프로젝트 Github을 직접 들어가보고 코드를 모듈화 한다의 필요성을 크게 깨달았고, 아, 남의 코드를 보고 배운다는 게 이런 거구나!!를 느끼게 한 좋은 코드이였는데, 문제는 해당 글과 Github 주소를 저장 안해놔서... 이 글에 꼭 넣고싶었는데 찾지 못했다... 여러분은 꼭 좋은 인사이트를 준 글을 저장해두면 좋겠다. 제발
이러고 이슈를 모두 해결하고 Web Share API를 성공적으로 이식했으면 좋았겠지만 아쉽게도 실패했다. 웹과 네이티브(Android) 간의 상호작용이 무슨 짓을 해도 성공하지 않았다... 안드로이드 웹뷰에서는 본 라이브러리가 동작하지 않음을 인지했으나, 어째서인지 모바일 브라우저(ex Chrome, 삼성인터넷, 파이어폭스 등등)에서도 돌아가지 않았다.
이 블로그에 다 쓰지 못할만큼 이슈 해결을 위해 삽질을 좀 하다가, 다시 본질로 돌아와서 생각해봤다.
이게 정말 필요한가?
결론적으로 당시 내가 낸 결론은 아니었다!
우리의 목표는 코드 짜는 게 아니라 하나의 product를 완성하는 것이다.
이 삽질의 끝이 이 product를 완성하는 데 중요한가?라 생각하니 그렇지는 않았다.
접근성의 측면에서도, 카카오톡 공유하기와 클립보드 링크 복사정도면 그럭저럭 쓸만하다고 판단했다. 이에 팀 내 기획 겸 디자이너님께 의견을 여쭈었고, 공유하기 기능을 모아둔 모달에서 해당 Web Share API기능을 제외하기로 했다.
디자이너와 소통하는 법
사실 제일 걱정했던 부분이다.
2024년도 여름방학에 준비했던 멋쟁이사자처럼 동아리의 해커톤 product의 경우, 기획을 맡은 선배가 컴퓨터공학도였다. 즉, 기획 겸 디자이너 역할을 하면서도 개발에 대한 충분한 이해가 있는 상태였고, 심지어 최종 CSS 수정에 있어 어느정도 검토까지 해주신 전적이 있다.
그런데 본 '언제볼까?' 프로젝트의 경우는 보다 장기적인 프로젝트이고, 기획 겸 디자이너 님이 디자인 전공이시며, 이전에 개발자와 협업한 경험이 있는 분이었다.
정작 나는 진짜(?) 디자인 전공자와 일해본 게 처음이었기에, 혹여나 소통하는 데 있어 폐가 되지않을까 갖은 걱정을 했다.
이에 내 나름대로 다음의 원칙을 갖고 소통에 임했다.
1. 무조건 안된다고 하지않는다. (안되면 왜 안되는지 상황 설명을 한다)
2. 기술 용어를 쓰더라도 쉬운 자연어로 풀어 설명한다.
3. 레퍼런스도 같이 첨부해서 이해를 돕는다.
4. 조금이라도 헷갈릴 때는 기획 의도를 묻는다.
5. 기획자는 기획자의 일을 해야한다.
1번과 2번, 3번은 사실 나 자신을 위한 원칙이기도 했다. 프론트엔드 구현에 대해 잘 모르는 사람을 위해 설명하는 것은, 다시 말해 이걸 말하는 나는 이것을 자연어로 설명할 수 있나? 설명할 수 있어야 잘 아는 거 아닌가?의 지점을 고민하게 했다. 남이 이해할 수 있는 글은 본인을 더욱 이해시킬 수 있다.
나는 프론트엔드 개발을 함으로써 백엔드의 아주 세부적 로직까지는 몰라도 개괄적인 로직(특히 백엔드 API호출 부분, 즉 뭐를 요청했을때 뭐를 응답받아야한다)과 UI, UX를 이해하고있다.
특히 본 프로젝트의 초기 기획은 팀장님(ver1 백엔드 개발)이 내놓으셨고, 세부 UI, UX는 디자이너 님이 들어오고 확정되었다. 디자이너 님께서 모임장, 모임원 각각에 대한 서비스 로직 자체에 대해 살짝 헷갈려 하셔서 직접 동영상 시연을 통해 확실한 이해를 도운 기억이 난다!
4번 역시 중요했다. 기획자의 시선과 개발자의 시선을 같은 듯 하면서도 다르다는 걸 많이 느꼈기에, 기획자의 의도 파악이 중요했다. 명확히 밝히지않고 가면 꼭 마지막에 엎어야하는 상황이 생겼기에... 조금이라도 헷갈리면 물어보는 게 best.
사실 5번에 관해서는 프론트엔드 개발에 임하는 사람들에게 있어 의견이 갈릴 거 같다. 다만 나는 기획자는 기획자대로의, 개발자는 개발자 대로의 일이 있다고 믿는다.
팀 내 기획자가 기획 단계에서부터 이렇게 개발하는 게 편하니까를 염두에 둘 필요는 없다고 생각한다.
물론 개발적으로 전혀 말이 안되거나, 개발 마감이 빠듯하거나 제한된 리소스, 인적 자원을 가진 상태라면 협의를 통해 업무를 조정하는 게 맞다. 앞에서 설명한 Web Share API 사례처럼 말이다.
또, 개인적으로 UI, UX자체는 간편하고 훌륭한데 코드 구현으로는 복잡한 경험도 나름의 훈련이 되었다. 이 또한 만약 기획 단계에서 이렇게 개발하면 편하니까를 고려했다면 하기 어려웠을 것이다.
당시 디자이너님과 주고 받았던 Slack 메시지의 좋은 예시 몇개를 첨부해본다.
박수도 두 짝이 맞아야 소리가 난다는 데, 여러모로 소통에 있어서 항상 깔끔하셔서 좋았던 거 같다. Figma에 작업하신 디테일한 UI, UX를 보면서 항상 감탄하며 정말 많이 배웠다...!
UI와 실제 전송되는 데이터의 차이
개인 일정을 작성하는 individualCalendar 페이지에서, 눈에 보이는 UI와 실제 전송되는 데이터의 차이가 있어야한다.
현재 BE에서 이미 선택된 부분을 한번더 클릭했을 때는 선택되지 않은 부분으로 togglee 되도록 세팅되어 있다. (on 상태면 off, off상태면 on으로 전환)
이에 모든 시간 가능 버튼 클릭시, 이미 선택된 timeslot에도 동일하게 요청을 보내서 오히려 해제 되버리는 식으로 동작되어 이슈가 발생한 적이 있다.
사용자 화면에 보여줄 selected된 timeslot이 담긴 배열과, 정말로 서버에 보낼 상태가 변화한 timeslot을 담은 배열 해서 총 2가지 배열을 만드는 식으로 해결했다.
코드를 쪼개자 (ft. Props 전달)
약속을 만들때의 화면에 대해 팀원들과 논할때, 다음과 같은 MonthView페이지로 통칭했다.
그런데 이는 사실 MonthView.js와 TimePicker.js, 그리고 두 컴포넌트의 데이터가 준비되면 서버에 보내는 로직이 포함된 ParentMonth.js로 구성되어 있다.
ParentMonth.js의 네이밍을 보면 알 수 있듯 React의 Props 전달의 개념에서 따왔다. 데이터의 이동 과정은 다음과 같다.
1.ParentMonth에서 두 컴포넌트에 useState로써 jsonData,startTime, endTime, isFormReady를 내려준다.
2. TimePicker에서 startTime, endTime이 설정 되고 MonthView에서 날짜가 1개 이상 선택되면 MonthView에 내린 isFormReady가 true가 된다.
3. MonthView의 jsonData가 시간대를 UTC시간대에 맞게 변환 및 약속자 이름, 약속 이름 등의 구체적인 약속 정보를 포함하여 입력 된다.
4. 최종적으로 ParentMonth.js에서 isFormReady를 useEffect로 상태변화를 추적하여 서버로 jsonData를 전송한다.
뭔가 이상하지 않은가?
그렇다. 이 코드는 더럽다... 설계의 중요성
정말 Props 전달의 모토에 맞게 할려면 자식 컴포넌트는 부모 컴포넌트인 ParentMonth로부터 꼭 필요한 데이터만 내려 받아야한다. 또, isFormReady는 MonthView에서 startTime, endTime, selectedDates를 확인하여 자체적으로 결정 가능하고, useEffect로 상태 변화를 추적할 수 있다.
즉, 정리하자면 MonthView와 TimePicker단에서는 데이터를 가공하고, 최종적으로 서버에 전송할 때만 ParentMonth에서 하는 식으로 책임을 분리하면 훨씬 가독성이 개선된다.
위 solution은, 추후 기능 확장 등을 이유로 MonthView와 TimePicker 각각 에서 또한번 자식 컴포넌트로 분화한다면 깊은 단계의 자식한테 Props를 전달하는 Props Drilling을 유발할 수 있다.
이런 경우에는 Context API나 Zustand 등의 상태 관리 라이브러리를 활용하여 데이터를 전역 상태로 관리하는 것도 또 하나의 좋은 방법이 될 것이다.
프로모션 페이지 (with framer-motion)
정말 즐겁게 했던 프로모션 페이지 작업 ...! 해커톤 프로젝트 당시에는 별다른 프로모션 페이지 없었고,Framer란 툴을 처음봐서 신기했던 거 같다.
해커톤 당시에는 간단한 인터랙티브 디자인은 직접 구현했는데, 이번에는 본격적으로 인터랙티브 디자인이 복잡하게 많이 들어가기도 하고 Framer는 유명한 회사니까 분명 라이브러리가 있을 거라는 생각이 들었다.
찾아본 결과 정말 Framer motion 라이브러리가 있어서 이것을 사용하여 개발했다.
사용법이 워낙 직관적이고 간편하기도 하여 구현에 큰 어려움은 없었다.
(그냥 <motion div> </div> 안에 속성 좀 부여하고 컨텐츠 내용 작성하면 끝이다)
다만 라이브러리 특성상 인터랙티브 디자인과 많이 연관되어 있는 만큼, 기술블로그 들을 많이 참고하여 다양한 모션 디자인 예시들을 참고해 보는 게 중요했다. 특히 구체적인 모션읭 속도를 지정할 때, 컴퓨터에서는 베지어 곡선(Bezier Curve)개념을 사용한다.
두 개 이상의 제어점을 사용하여 곡선의 형태를 조절하기에 단순한 수 조정으로는 직관적인 이해가 어려울 수 있다.
이럴 때는 요런 사이트를 참고하면 도움이 될 것이다.
SEO 최적화
서비스가 홍보가 될려면 아무래도 일단 검색이 되어야한다.
특히 본 프로젝트는 CRA(Create React App)으로 만들어졌기에, Client-Side Rendering으로 동작한다. Next.js처럼 Server-Side Rendering 되어서 요청 시 서버에서 HTML을 생성하여 즉시 전송되는 게 아니기에, SEO가 잘 되도록 하기 위해서 여러 세팅이 필요했다.
검색엔진 최적화를 위해 적용했던 사항은 다음과 같다.
<div> 태그대신 시멘틱 태그 넣기- react-helmet-async 라이브러리로 각 페이지별 메타태그 넣기
- react-hydratable로 Prerendering을 구현하여 크롤러가 미리 렌더링된 HTML을 가져갈 수 있게 하기
- 구글 서치콘솔, 네이버 웹 마스터에 우리 사이트 주요 path 등록 (색인 요청)
- 크롤러가 읽기 쉬우라고 /Robots.txt , /sitemap.xml 세팅
SEO 최적화를 했는데 전에는 잘되던 초대페이지 접속이 안된다??
이렇게 SEO를 적용시키고 나니, 이런 이슈가 발생하였다.
결론적으로 Prerendering을 구현하는데 있어서, 정적 라우팅을 시키다보니 매 약속마다 구체적인 UUID가 달라지는 invite페이지에서 오류가 났던 것이었다.
이 부분에는 다시 따로 동적 라우팅을 적용시킴으로써 해결했다,
SEO를 넘어 GEO로
요즈음 들어 이전처럼 구글링을 직접 하는 게 아닌, searchGPT 등 AI를 활용해 검색하는 사람들이 늘고있다. 따라서 AI 모델이 정보를 더 잘 이해하고 선택하도록 최적화하는 것 역시 필요하다!
FE ver2 개발하며 같이 진행할 계획이다.
이게 잘하고 있는 걸까?
본 글을 쓰면서, 이전에 기록해둔 KUIT 4기 웹 프로젝트 스터디 정리 자료, 언제볼까? Github FrontEnd 페이지을 참고했다.
본 프로젝트를 막 시작할 때 쯤에는 React에 대한 이해도가 부족하여 위의 Props 전달 예시처럼 초기 세팅 단계에서 제대로된 설계가 부족했음을 뼈저리 느낀다.
당시 전공 5개에 본 사이드 프로젝트와 동아리 스터디를 병행했었기에, 스터디를 하며 React 개념을 열심히 배우고 실습하는데 급급했었다.
'더 좋은 코드에 대한 고민이 없이 짜고 있다... 이게 맞나?'와 '근데 좋은 코드보다는 일단 돌아가기만 하면 되지않을까?'같은 고민의 연속이었다.
학기 내내 주7일간 휴일 없이 학교 과제와 학교 팀프로젝트 개발과 언제볼까? FE 개발과 동아리 강의와 동아리 과제... 뭐 하나 제대로 잘 못해내는 기분이 들었다.
선택과 집중이 필요한가는 고민을 했고 급기야는 동아리 스터디 탈퇴까지 고려하여, 평소 친분이 있던 KUIT 4기 웹 파트장님인 지환님께 말씀을 드렸고 다음과 같은 답을 얻었다. (분량상 일부 생략)
아하.. 현주님이 엄청 잘 따라가고 있는 쪽이었는데 의외네요ㅠㅠ 질문도 매번 열심히 해주셔서 감동이었는데요 ㅠ
벌써 6주차 과제도 잘 제출해 주셨고 이제 4주차 밖에 (사실 상 과제는 3주차 밖에) 안 남았는데 일정 상 많이많이 힘드신가요???
시간이야 항상 없고 저조차도 PR 리뷰도 시간에 쫒기면서 계속 미뤄지고 있는 걸 보면... 많이 공감되네요
저도 지금 우테코나 이것저것 동시에 진행하면서 느끼는 건데, "Done is better than perfect"라는 말이 많이 와닿아요. 좋은 코드에 대한 고민은 일단 나중으로 미루고 먼저 요구사항에 맞는 구현을 빠르게 하는 방향으로 잡아 보는 것은 어떨까요?
충분한 고민 없더라도 조금만이라도 고민하면서 짠다면 코드가 늘어 있을 거고, 짧은 시간에 일단 돌아가는 코드를 짜내는 것도 중요한 실력이라 생각하거든요.
솔직히 강의 듣고 과제 하는 것도 완벽한 수준이 아니라 out 되지 않을 정도 선에서 멈춰도 괜찮다 생각해요.
그래서 이미 충분히 잘 따라와주셨기도 하고, 개념들을 한 번이라도 가볍게 훝어 보는 거랑 아예 모르고 끝내는 거랑도 차이가 있으니 스터디만이라도 완주하는 것을 추천드립니다...ㅠㅠㅠ
이에 마음을 다잡고 스터디를 완주했다. FE ver1이 끝난 와서 생각해보니 정말 잘한 선택인 거 같다. 위에 조언해주신 대로 개념을 한번이라도 훑은 것과 아예 모르고 끝낸 거는 큰 차이가 있었다.
당장 chatGPT에게 질문을 하더라도, 키워드를 알고 구체적인 질문을 하는 것과, 개념을 모른 채 피상적이고 넓은 질문을 할 때 답변 퀄리티 자체가 달라지는 걸 알 수 있다. 사람도 똑같다고 생각한다.
마치며
흔히 사이드 프로젝트의 장점으로 '협업 경험을 쌓을 수 있다'가 꼽히곤 한다.
겉보기에 간단한 UI, UX지만 직접 구현할 때 복잡한 내용들을 구현해보기도 하고, 공식문서와 기술블로그들을 보며 남의 코드를 까보며(?) 배운다를 몸소 배우기도 하고, 왜 설계가 중요한지도 느끼기도하고, 개발자가 아닌 사람과 개발을 논할 때 어떤 태도로 임해야하는 지도 배웠다.
확실히 혼자 공부할 때는 느낄 수 없는 부분들이다.
특히 웹 기술은 하루가 다르게 발전하고, 꽤 많은 부분이 추상화 되었지만 결국 근본적인 이해를 위해서는 low레벨 개념 까지도 확인해야 하는 부분이 있었다.
여러모로 학교 전공 공부에 안주하지 말고, 꾸준히 스스로 찾아가며 공부해나가야한다. 특히 공식문서 꼭 확인하기를 많이 느꼈다.
진짜마치며 
FE ver1을 개발하며 줄곧 정리하고 싶다는 생각을 많이 했는데, 마침내 정리를 하게되어 기쁘다.
이 글을 쓰는 시점에서 디자인 및 백엔드, 인프라 팀원이 열심히 해주신 덕에 ver2이 모두 완료되었다. 으악
FE ver2도 마저 힘내서 열심히 개발해보아야겠다. 파이팅!!
