핑퐁클래스 웹 애플리케이션 개발을 마치고, aws 서버를 반환하기 전에 어떤 일을 했는지, 뭐가 잘됐는지, 뭐가 아쉬웠는지에 대해서 회고해보고 싶어서 이렇게 글을 작성하게 되었습니다.
목차
0. 팀 컬쳐
부스트캠프 그룹프로젝트기간에 경험했던 내용들을 좀 더 가다듬어서 적용해보고 싶었습니다.
그래서 Notion에 페이지를 만들어서 필요한 내용들을 적어두었습니다.
0.0. 팀 규칙
기본적인 팀 규칙 페이지를 만들고 코딩관련, 복지관련, 기타로 나누어서 각각에 맞는 항목들을 적용했고, 당시 상황과 맞지 않는 여러 요소들 (지각비라든지, PR -> MR이라든지..)은 수정해서 올렸습니다.
0.1. 갤러리
그리고 당시부터 시작해서 지금까지 거의 1년째 이어오고있는 갤러리를 이번 프로젝트에도 도입했는데, 직접 책임지고 매일마다 사진을 찍고 관리까지 맡아서 진행하다보니 더 애착이 갔던 것 같습니다. (고맙다 죠죠야~)
팀원들끼리 빠르게 가까워지고 추억을 남길 수 있는 장치가 되어서 한번쯤 해보길 강추드립니다!
0.2. 바로가기
시간이 흐르면서 자주 확인해야 하는 내용들을 위쪽에 쌓아올리는 방법을 사용했는데, 이것도 나름 괜찮았던 것 같습니다.
기존에는 5개의 대분류로 나눠서 아래에 쭉 쌓아올리는 방식을 선택했는데, 어떻게보면 자주 확인해야 하는 내용들은 몇가지 안되서 이렇게 따로 빼놓는 게 더 효율적이라는 생각이 들었습니다.
0.3. 회의록
또한 매일 회의록을 작성하였습니다.
회의록 내부에는 오늘 해야할 것, 오늘 한 것, 하루의 소감 정도를 담았습니다.
0.4. 삽질게시판
그리고 비교적 잘 사용되었던 게시판중에 하나가 바로 삽질게시판입니다.
자신이 삽질한 내용을 문서화시켜놓음으로써 나중에 같은 문제가 발생했을 때 쉽게 과거의 나(?)를 돌아보고 문제를 처리할 수 있다는 장점이 있어서 만들었는데, 나름 팀원들이 유용하게 작성해준 것 같아 만족스러웠습니다.
0.5. 개선사항
다만 조금 아쉬웠던 것은 대부분의 팀원들이 아직 프로젝트에 익숙해지지 않은 단계여서 그런지 개발 자체에만 과도하게 치중한 점..
다른 팀과의 코드리뷰나 개인공부후 발표 및 문서화와 같은 것들을 이번에는 더 체계적으로 진행해보고 싶었지만.. 개발에 우선순위가 밀려서 아예 시도조차 하지 못했습니다.
저는 프론트엔드가 아닌 백엔드쪽에도 관심이 많아서 같이 공부하고 물어보고 싶었던 부분이 많았기 때문에 정말 많이 아쉬웠습니다 ㅠㅠ
이번 프로젝트는 아무래도 수상이 걸린 문제다보니 코드 공개에 다소 민감한 부분이 있어서 팀간 코드리뷰는 어려운 부분이 있을 수 있겠다고 생각은 했지만, 팀 내 코드리뷰도 제대로 이루어지지 않은 점은 다음 프로젝트에서는 꼭 수정하고 싶은 부분 중 하나입니다.
그래도.. 나름대로 프론트엔드를 담당한 제 입장에서 궁금했고 배우고 싶었던 부분들에 대해서 일부 코멘트를 작성했고, 이에 대해서 담당해준 팀원이 답변을 남겨주었다는 점에서 부분적으로는 성공했다고 볼 수도 있을 것 같습니다. (이게 팀 문화로 이어지지 않아서 그렇지...)
다음 프로젝트에는 이전 공통프로젝트에 대한 경험을 바탕으로 조금 더 부담없이, 그리고 여유있게 이런 프로젝트 이외의 사이드 요소들을 할 수 있었으면 좋겠습니다!
1. 기획단계
다른 팀보다 훨씬 빠른 시점부터 기획이 시작되었다고 생각합니다.
그 덕분에 조금 더 여유있게 개발 시간을 확보할 수 있었습니다.
1.0. 디자인
디자인 작업 협업 툴로는 Figma를 사용했습니다.
개발을 하면서 스케일이 조금 커진 부분이 있고, 기초 스케치 이후에 디자인 Fix를 위해서 다시 한번 갈아엎는 과정이 있어서 피그마 완성에만 약 2주정도의 시간이 들어갔지만, 그만큼 개발 과정에서 디자인적 고민에 대해서 크게 생각하지 않을 수 있었습니다.
1.1. ERD
ERD설계도 동시에 진행했는데, 이 부분은 크게 어렵지 않게 금방 끝낼 수 있었습니다.
다만 발생할 수 있는 여러 오류에 대해서 지적을 받은 부분이 있었고, 그에 따라 ERD와 실제 테이블 사이에 괴리가 발생한 부분은 다소 아쉬웠습니다.
1.2. 기능정의서
마지막으로 기능정의서를 작성하면서 어떤 기능을 개발해야할 지에 대해서 정리를 했습니다.
지라의 형태를 그대로 차용하기도 했고, 실제로 지라도 사용하긴 했지만, 해야할 내용들을 한 눈에 보기에는 이쪽이 조금 더 편해서 저는 기능정의서를 애용했습니다.
실제로 Merge Request를 날릴 때 스토리번호와 태스크번호를 앞에 달아서 어떤 내용을 담은 MR인지 개발자끼리 명료하게 확인할 수 있었습니다.
(나중에는 기능정의서 이외의 부분이 추가되면서 Feature etc...가 많아졌지만....)
1.3. Git
깃 전략은 가장 흔하게 사용하는 git-flow를 사용했습니다.
여기서 필요한 부분만 잘 채용해서, feature, develop, master로 나누어서 진행했습니다.
이번 프로젝트에서 깃 책임자가 저였기 때문에 팀원들에게 다소 엄격하게 develop에 직접 push하는 일이 없도록 잘 단속했습니다. (다만.. 막판에는 몇번 봐줬습니다 ㅋㅋㅋㅋ)
커밋 컨벤션은 딱히 정해두지 않고, 어떤 내용인지 쉽게 확인할 수 있도록 gitmoji만 사용하는 정도로 정리하였습니다.
gitmoji
:truck: Move or rename resources (e.g.: files, paths, routes).
gitmoji.dev
2. 개발단계
2.0. 기술 스택
개발에 필요한 기술 스택 선정은 기획단계에서 거의 대부분 완료되었습니다.
본의 아니게 프론트엔드 파트리더(...)가 되어서 + 다른 팀원들이 리액트를 사용해본 경험이 없었기 때문에 제가 어느정도는 가이드를 잡아야 하는 상황이었습니다.
팀원들이 원하는 React를 사용하기로 마음먹었고, 상태관리 라이브러리로는 Redux를 선정했습니다. (러닝커브가 다소 있는 편이라서 Recoil도 고려했지만, 엄청난 사용량 및 정보량과 더불어 Redux-toolkit을 사용한다면 그래도 충분히 할만할 것이라고 생각했습니다.)
그리고 CSS를 처리하기 위하여 Emotion을 사용했습니다.
이 단계에서는 팀원들이 처음 접하는 것들이 너무 많아서 JavaScript를 사용해야겠다고 마음먹었으나.. 추후에 TypeScript도 도입했습니다.
개발 초기에는 리액트에 대한 약간의 학습시간이 필요했고, WebRTC 적용을 위한 오픈비두를 사용하기 위해서 클래스형 컴포넌트 역시 공부해야 했습니다. (저 역시 클래스형 컴포넌트는 익숙하지 않았기 때문에 적응하는 시간이 다소 필요했습니다.)
다행히 팀원들의 러닝커브가 가파른 편이었고, Redux-toolkit 역시 제가 기본적인 보일러플레이트를 작성해두니 알아서 잘 사용해주었습니다. (처음이라 많이 어려웠을텐데.. 잘 사용해준 팀원들에게 무한한 감사를~~)
개발 중반부의 TypeScript 도입에 대해서 조금 더 이야기를 하자면...
한창 개발을 하던 중 하위 컴포넌트로 props를 건네줄 때 prop-types관련 에러들이 발생하기 시작했고, 이걸 해결하기 위해 라이브러리를 통해서 매번 타입검사를 하는 방식을 사용했습니다.
하지만 어짜피 prop-types 라이브러리를 사용해서 타입을 검사할거라면 그냥 TypeScript를 도입하자는 의견을 제시했고, 이게 받아들여져서 중간에 전환을 하게 되었습니다. (백엔드 담당 팀원들이 프론트엔드로 넘어오기 전에 전환해서 정말 다행이라고 생각했습니다...)
전환 과정에서 많은 에러가 있었으나.. 결국 극복하고 하루만에 전환에 성공했습니다 ㅎㅎ
옥의 티라면, 이미 스켈레톤 코드가 존재했던 OpenVidu쪽은 일부 기능들에만 TypeScript가 적용되었고, 대다수가 JavaScript상태로 남아있게 되었습니다...
그 이외에도 Openvidu, Mui, 그 외에도 다양한 라이브러리를 개발 중간에 도입하고 사용하였으나 일반적인 내용은 아니라고 생각했기에 설명은 생략합니다. (필요하면 그때그때 찾아서 쓰면 되니까요~~)
기술 스택을 선정하고 라이브러리를 사용하는 과정에서 몇 가지 더 도입해보고 싶었던 부분들도 있었지만, (React Query, Recoil 등..)
나 혼자 하는 개발이 아니기 때문에 적극적으로 도입하지 못했던 부분은 다소 아쉽긴 했습니다..
또한 실제로 Redux로 처리하는 내용이 많지 않아서 Props로 모든 상태값을 관리할 수도 있겠다는 생각도 들었습니다.
하지만 상태관리에 대해 고민해보고, 상태관리 라이브러리를 직접 사용해보고 공부했다고 생각하면 그걸로 충분하다고 생각했기에 도입 자체를 후회하진 않습니다.
백엔드쪽은 제가 전혀 관여하지 않았지만, 아는 대로 말해보자면 SpringBoot와 JPA를 사용했고, DB는 MySQL을 사용했습니다.
저는 백엔드쪽 Java 코드를 만질 때도 vscode를 사용하긴 했는데, 백엔드 팀원들은 IntelliJ를 사용했습니다.
그게 편하다나.. 저는 아직 뉴비라 잘 모르겠습니다만 ㅋㅋㅋ
서버는 AmazonAWS에서 제공받았고, 사진 데이터 저장용 서버로는 AmazonS3를 사용했습니다.
그리고 CI/CD를 위해서 Docker와 Jenkins를 사용했고, https 처리와 리버스 프록시를 위해서 NginX를 사용했습니다.
2.1. 실제 개발 과정
실제 개발은 약 3.5주간 진행되었고, 마지막 며칠은 기능 개발을 멈추고 리팩토링을 진행하려고 했으나..
생각보다 많은 버그와 기능으로 인해서 일정이 조금씩 밀려서 리팩토링은 거의 진행하지 못했습니다.
그래도 부스트캠프 그룹프로젝트에서 겪었던 지독한 야근(...)에서는 좀 벗어나서 여유있게 개발했던 것 같습니다.
커밋 시간만 보면 굉장히 늦은 시간까지 개발한 것처럼 보이긴 하는데..
우선 주말에는 개발을 놓고 푹 쉬었고, 평소에는 여유있게 생각하고 어떻게 코드를 짤지에 대해서 고민하다가 개인적으로 집중력이 많이 올라가는 밤시간에 실제 기능 구현을 위한 코드 작성을 했습니다.
일과 시간(9-6)에는 서로 무엇을 하고 있는지 확인할 수 있도록 디스코드 라이브를 켜놓고 개발을 진행했고, 모르는 부분이 있으면 바로바로 팀원들에게 알려서 vscode의 live share를 사용해서 도움을 주는 방식을 사용했습니다.
실제로 리액트에 익숙하지 않은 초반부, 그리고 버그 해결과 리팩토링을 위한 마지막 주에 live share를 집중적으로 사용해서 문제를 해결하고 기능을 구현할 수 있었습니다.
2.2. 폴더 구조
프론트엔드 폴더 구조의 경우 프론트는 components와 pages의 역할을 나누어서, 하나의 page는 각각의 component를 import해온 후에 출력만을 담당할 수 있도록 구성하였습니다.
실제 수업과 관련된 WebRTC 로직을 처리하는 부분은 컴포넌트 폴더로 관리하기에는 너무나 그 비중이 컸기 때문에 별도의 openvidu폴더로 나눠서 구성하였고, 사진과 음성과 같은 미디어 데이터는 assets, 반복해서 사용하는 요소들은 utils로 빼고, 전역 상태관리와 관련된 부분은 store폴더로 분리했습니다.
그리고 storage폴더는 로컬 스토리지를 사용하는 요소들을 담은 폴더입니다.
마지막으로 types폴더 안에 Emotion의 사용을 돕기 위한 파일이 들어있습니다.
백엔드 폴더 구조의 경우 controller(요청을 실제로 받는 곳)와 service(백엔드 로직 처리)로 나뉘는 기본적인 구조를 채택했고, 엔티티와 관련된 부분은 domain에서 관리하고, jwt 인증과 관련된 부분은 jwt폴더에서 관리했습니다.
repository폴더는 JPA에서 제공하는 데이터 검색 기능인 JpaRepository를 사용하는 요소들을 담고 있습니다.
2.3. 담당 개발 기능
실제로 제가 중점적으로 맡아서 개발했던 부분은 WebRTC였습니다.
이미 한번 개발을 진행해봤던 분야이기도 하고, 애플리케이션의 핵심이 되는 부분이었기 때문에 꼭 맡아서 진행해보고 싶었기 때문에 흔쾌히 해당 부분을 담당해서 진행하였습니다.
가장 기억에 남는 부분이 바로 장치 사전 설정창입니다.
해당 부분은 4주차에 처음 개발을 시작했으나, 마지막 주차까지 계속해서 리팩토링을 진행했던 부분중 하나입니다.
처음에는 단순히 장치가 변경될 때마다 Stream(비디오와 마이크를 담은 화상 정보)과 Speaker를 변경해주는 커스텀 훅을 만들고 연결만 해 주면 되겠지 생각을 했는데, 말처럼 쉬운 부분이 아니었습니다.
이전 프로젝트에서는 Redux 내에서 모든 장치들을 관리하고 Redux-saga를 사용해서 비동기처리를 진행했는데, 지금은 단순히 상태값으로 처리했기 때문에 OpenVidu로 설정한 장치 정보들을 넘길 때 사전 설정창에서 연결해뒀던 stream이 정상적으로 종료되지 않아서 중복 연결이 되거나, 선택한 장치 정보가 넘어가지 않는 경우도 발생했습니다.
또한 장치를 변환할 때 새로운 stream이 생성되었는데, 이 때도 기존 stream이 정상적으로 종료되지 않는 문제도 간헐적으로 발생했습니다.
이 문제를 해결하기 위해서 선택한 장치를 담은 상태값들을 상위 컴포넌트(openvidu/App.js)에서 관리했고, 장치를 변환할 때 stream을 매번 새롭게 만드는 것이 아니라 기존 stream을 재활용하는 방식으로 개선하였습니다.
또한 장치를 정상적으로 불러오기 전에 수업으로 이동하는 문제를 없애기 위해서 로딩창을 띄웠습니다.
그리고 추가로 발생한 문제가 바로 로딩시에 마이크가 켜졌다가 꺼지는 문제였습니다.
이 문제는 stream에 해당 장치를 연결하기 전에 해당 장치의 enable속성을 false로 바꿔서 연결하는 방식으로 해결할 수 있었습니다.
아래는 위 설명의 이해를 돕기 위한 사전 설정창 컴포넌트(SetupComponent.js)에 처음으로 접근했을 때 작동하는 stream 초기 연결 로직입니다.
그 외에도 재미있게 개발했던 부분이라면 수업 화면 레이아웃입니다.
채팅창, 질문창, 참여자 목록창이 오른쪽에 뜨면 그만큼 화상 회의를 담당하는 영역은 줄어들어야 했는데, 기존 Openvidu의 스켈레톤코드를 이해하는 데에 꽤 오랜 시간이 걸려서 고생했습니다.
이 기능을 구현하기 위해서 먼저 해당 기능이 on인지 off인지를 나타내는 상태에 대한 boolean 상태값을 생성하고, 해당 상태값이 true가 될 때 css를 조정하여 화면을 담당하는 영역을 축소시켰습니다.
그리고 어떤 요소가 켜져있냐에 따라 자동으로 켜고 꺼지는 요소들을 설정하기 위해서 각 상태값에 맞는 className을 설정하여 각 className에 따라 css를 이용하여 높이를 조정하거나 상태값을 변화시켜서 기능이 정상적으로 작동할 수 있도록 만들었습니다.
실제로 해당 기능을 사용해보면 참여자목록과 채팅은 각각 켜지거나 동시에 켜질 수 있고, 익명질문은 단독으로만 켜질 수 있게 만들었습니다.
그 외에도 통계, 선생님메뉴 및 이모지 등등 WebRTC와 Openvidu쪽 전반적인 모든 요소들을 만질 수 있었습니다.
다만 조금 아쉬웠던 점이라고 한다면 화면단에 신경쓰느라 대시보드쪽에서는 크게 담당해서 만든 부분이 없습니다..
로그인, 상점 등의 기본적인 틀을 잡아주거나 부분적인 기능들의 구현(navbar처리, info메뉴, 프로필 사진 변경, 스크롤바 적용 등), 그리고 최종 리팩토링 과정에서 문제가 있는 부분들을 가다듬는 정도를 맡아서 진행했습니다.
2.4. 번외편 - nginx.conf 뜯어보기
먼저 upstream블록에 프론트 서버 주소 및 포트번호를 넣어둡니다.
동작하는 서버의 주소를 넣어두고, 이 서버의 이름을 client라고 부르겠다고 선언한 거라고 보시면 됩니다!
여기서는 3000번 포트로 서버를 돌리고 있기 때문에 3000번으로 설정을 해 두었습니다.
그리고 맨 아래
location / { proxy_pass http://client }
를 해 두면, 해당 server_name으로 접근하는 경우 전부 client에 정의해둔 서버로 넘어가게 됩니다.
즉 사용자가 해당 주소로 접근하면 자동으로 해당 주소:3000으로 보내버린다는 이야기죠.
이것을 리버스 프록시의 포트포워딩이라고 부릅니다.
아래는 깨알같은 리버스프록시를 정리해둔 레포지토리 홍보입니다 ㅋㅋㅋㅋ
GitHub - alittlekitten/Small_Interview_Handbook: 면접 직전에 짧고 간단하게 읽기 좋은 핸드북을 만들어보려
면접 직전에 짧고 간단하게 읽기 좋은 핸드북을 만들어보려고 합니다 :). Contribute to alittlekitten/Small_Interview_Handbook development by creating an account on GitHub.
github.com
또한 사용자가 80번 포트(http)로 접근하는 경우, 앞에 있는 server의
listen 80;
가 작동하게 되고,
location / { rewrite ^(.*) 서버이름:443$1 permanent; }
에 의해서 https주소로 redirect를 시키게 됩니다.
이렇게 redirect되면 뒤에 있는 server가 작동해서 똑같이 작동하겠죠?
그리고 중간에 있는 $1 permanent가 뭔지 궁금해하실 수도 있는데,
$1은 (.*)이라는 첫 번째 정규식을 가리키는 것으로, 뒤에 별도의 주소(/student 라든지...)가 붙으면 그걸 그대로 가져온 다음에 https만 붙이겠다는 이야기입니다.
permanent는 영구적으로 해당 주소로 리다이렉트 시키겠다는 명령어입니다.
2.5. 아쉬웠던 점
프론트엔드에 있어서 신경을 많이 쓰지 못했던 부분이 바로 TypeScript였습니다.
팀원들의 TypeScript 적응을 돕기 위해 풀어두었던 any가.. 부메랑으로 돌아와서 TypeScript 도입의 의미가 다소 퇴색된 부분이 있었습니다.
이 부분은 추후 프로젝트에서 개선이 되어야한다고 생각하고, 저도 타입체킹에 대해서 보다 엄밀하게 생각하고 적용해야겠다는 반성을 하게 되었습니다.
백엔드에 있어서는 위에서도 설명했지만 백엔드 api도 실제로 제작하고 하나씩 만져보면서 배워보고 싶었는데 그럴 기회가 많지 않았다는 점입니다.
뭐.. 배워보려고 나름대로 발버둥치긴 했습니다만...
백엔드를 담당한 친구들은 프론트엔드도 딥하게 맛보았는데 왜 프론트는 백엔드를...
필요로 하는 api가 있으면 요청하면 되겠지만, 간단한 api라면 백엔드 팀원들 괴롭히지 않고 직접 만들면 더욱 좋을 거라고 생각했기 때문에 여러차례 도전을 했고, 백엔드 팀원들이 많이 도와줘서 소소하게 api 제작 체험도 해볼 수 있었던 점은 정말 좋았고 고마웠습니다.
그래서 다음 프로젝트는 백엔드를 해보겠다고 강하게 주장했고 실제로 백엔드로 프로젝트에 들어가게 되었습니다~~~
그리고 서버와 CI/CD쪽도 직접 경험해보고 싶다는 나름의 목표가 있었는데, 실제 계획된 개발기간에는 옆에서 보기만 했지 실제로 서버에 접근해서 nginx를 만지거나 하는 것들은 거의 실천하지 못했습니다.
이런 제 마음을 읽어주셨는지 백엔드 파트리더님의 도움으로 프로젝트 발표 이후에 직접 도커라이징을 진행하고 서버에서 pull 받아서 수동배포(a.k.a. 인간젠킨스) 하는 방법에 대해 배울 수 있었습니다.
다만 docker-compose 파일이나 nginx를 만진건 아니라서.. 완벽하게 배웠다고는 할 수 없습니다.
이 부분도 다음 프로젝트에서 다른 백엔드 팀원들의 도움을 받아서 도전해보려고 생각하고 있습니다!
이것저것 다 찍어먹어보고 싶은 저.. 욕심쟁이일까요..
3. 종합
정말 오랜만에 진행하는 협업 프로젝트였기 때문에 시간 관리 및 개발 진행에 있어서 다소 미흡한 점도 많았고, 프론트엔드 파트리더라는 다소 막중한(?) 역할을 맡아서 부담이 되기도 했지만 무사히 마칠 수 있어서 다행이었습니다.
파트리더라는 자리가 어떻게 말하면 다소 독단적으로 보일 수도 있는 위치이기에 기술스택 선정부터 git 관리까지 다른 팀원들이 부담을 느끼지 않도록 최대한 노력해봤는데, 기회가 된다면 실제 프론트엔드 팀원들에게 피드백을 받아봐야겠다는 생각이 들었습니다 ㅋㅋㅋ
무엇보다 처음 사용하는 기술스택이었음에도 저보다 훨씬 자유자재로 사용하고 기능을 개발했던 다른 팀원들에게 감사인사를 돌리고 싶습니다.
제가 진행했던 프로젝트 중에서는 가장 큰 프로젝트였고, 멋진 실력을 가진 팀원들과 함께 오랜만에 정말 많은 것들을 배울 수 있었던 소중한 7주 동안의 시간이었습니다.
실제로 1등까지 해버려서.... 기억에 정말 오래 남을 것 같아요 ㅎㅎ
P.S. 해당 애플리케이션의 Git 레포지토리는 조만간 Public처리 승인이 되는 대로 링크 올려두겠습니다!
4. 애플리케이션 화면 사진
5. 참고 자료 및 기술 스택 관련 자료
NGINX에 대한 정리 #Upstream #Reverse Proxy #Proxy_pass
오늘은 웹서버인 Nginx에 대해서 정리해 보도록 하겠습니다. 1. NGINX 의 용도 주로 NodeJS같은 웹 애플리케이션 앞에 배치되어 사용되어 지는 NGINX는 주로 어떻게 사용되어 지는 것 일까요? 개인적으
developer88.tistory.com
우린 Git-flow를 사용하고 있어요 | 우아한형제들 기술블로그
{{item.name}} 안녕하세요. 우아한형제들 배민프론트개발팀에서 안드로이드 앱 개발을 하고 있는 나동호입니다. 오늘은 저희 안드로이드 파트에서 사용하고 있는 Git 브랜치 전략을 소개하려고 합
techblog.woowahan.com
OpenVidu Docs
From here you can search these documents. Enter your search terms below.
docs.openvidu.io
Overview - Material UI
Material UI is a library of React UI components that implements Google's Material Design.
mui.com
Getting Started | Redux Toolkit
redux-toolkit.js.org
Emotion – Introduction
(Edit code to see changes)
emotion.sh
시작하기 – React
A JavaScript library for building user interfaces
ko.reactjs.org
최근댓글