kyusik + 유니버스를 의미하는 큐니버스는 저를 표현할 수 있는 키워드들을 UI로 표현한 웹사이트 입니다. 현재 컨텐츠들이 대부분이 개발 분야에 치중되어 있지만, 비 개발 분야의 유니버스들도 점차 추가할 예정이예요! 😃
기술이라고 표현하지 않고, 도구라고 이야기 한 이유는 결국 기술들은 내가 만들고 싶어하는 서비스를 위한 도구일 뿐이라고 생각해요. 내가 혹은 회사가 출시해야하는 결과물을 가장 쉽게, 그리고 안전하게, 값싸게, 수정하기 쉽게 만들기 위해 많은 도구들 중에 적합한 것을 선택해야 해요. 결과물이 우선이어야 하며, 도구가 목적이 되어서는 안 된다고 생각해요. 물론 선택한 도구에 대해 일정 수준의 학습은 필수적이지만 말이죠.
그래서 Kyu-niverse를 만들기 위해 제가 골랐던 도구 모음 입니다.
큐니버스 컨텐츠들의 성격상, 실시간으로 바뀌어야하는 데이터들이 아니기 떄문에 그리고 매번 데이터를 요청해서 화면을 그려줄 필요가 없어, Next.js의 static exports를 사용하는게 맞다고 판단하였어요. 그 기능을 사용하면 빌드 타임에 필요한 데이터들을 fetch하여 이미 필요한 컨텐츠로 채워진 document를 생성합니다. 그렇기 때문에 SEO의 이점도 챙길수 있고요. 그렇다면, React도 있고, Gastby 같은 정적 사이트 생성기도 있었지만 그럼에도 Next.js를 선택한 이유가 있다면, 앞으로의 확장성 입니다.
실시간으로 업데이트 되야하는 데이터, 그리고 api를 사용한 유저들의 인터렉션 기능 추가가 되면서 백엔드 사이드가 필요해질 순간이 올 것이라 판단하였습니다.
Next.js는 자신들을 이렇게 표현합니다.
Next.js is a React framework for building full-stack web applications.
백엔드 자원을 어떻게 구성할지는 좀 더 고민해봐야겠지만, Next.js의 서버 기능들을 이용하면 별도의 백엔드 프레임워크를 쓰지 않고 풀 스택 웹을 만들 수 있습니다! 👍🏻
tailwind css는 호불호가 갈리는 라이브러리중 하나예요. 누구는 tailwind에서 지시하는 커스텀 classname와 친숙해지면 정말 빠르게 개발을 할 수 있다. 혹자는 렌더링쪽 코드가 classname으로 도배되서 오히려 가독성을 해친다 라고 말합니다. 결론 부터 말하자면 저는 tailwind css를 선택하였습니다.
회사에서는 styled-components라는 css-in-js 방식의 라이브러리를 사용중입니다. 저는 이 라이브러리를 사용하면서
- 오히려 스타일 컴포넌트 이름을 지어줘야함.
- 그 스타일 컴포넌트들을 따로 어느곳에서는 관리를 해줘야한다는 관점에서 불필요한 파일증가에 피로감을 느꼈습니다.
그리고 렌더링쪽 코드에 어떤게 스타일용 컴포넌트인지, 어느게 로직을 다루는 컴포넌트인지 한 눈에 파악하기 어려웠단 점이 있습니다. 하지만 tailwind css는 명확합니다. 애초에 html태그에 스타일이 선언되어있고, 렌더링하는 코드내에서 스타일과 로직이 포함된 컴포넌트가 한 눈에 구분되어 보여집니다.
더구나 styled-components는 js위에서 동작하기 때문에, SSR 환경에서 추가적으로 셋팅 해주어야하는 부분이 존재하지만, tailwind는 정적 css를 사용하기 때문에 그럴필요가 없지요!
그밖에 styled-components와 tailwind css의 성능 차이는 더 좋은글 들이 많기 때문에 그것을 참고해주세요!
처음부터 큐니버스에 표현할 데이터들이 노션에 정리되어 있었기 때문에, 당연히 노션 API를 사용하는것이 개발도 더 빠르게 할 수 있다고 생각했어요!
노션에서는 데이터베이스에 접근할 수 있는 api를 제공해 줍니다. 데이터 베이스에 접근하기 위해 secret key같은게 필요한데, 이것은 github 환경 변수에 넣어놓고 빌드할때, .env.production 파일을 생성하고 그때 secret key를 통해 db에서 데이터를 가져온 후 화면에 컨텐츠를 채웁니다.
앞으로 서버 기능이 추가되더라도 Next.js 서버에서 db 접근을 하기 때문에 브라우저에 노출될 일도 없어요!
Next.js를 사용하고 있지만, 컨텐츠들 특성상 Next.js 서버를 띄우고 실시간으로 요청을 받을 필요가 없다고 판단하여, static exports 라는 기능을 사용하여 현재 정적파일들 서빙하는 방식입니다. (React 배포와 유사)
그렇다고 코드 상에서 Next.js의 서버기능을 아예 사용하지 않는것은 아닙니다. React Server Component를 사용하여 빌드타임때 외부 API에서 데이터를 미리 채워 놓은상태로 정적파일이 만들어집니다.
빌드된 정적파일을 github Action을 통해 S3에 업로드 합니다. S3에서 정적 자원들을 제공하지만, S3에 직접 접근하는건 여러모로 단점이 존재하기 때문에 CDN 서비스인 CloudFront를 두고 유저들은 CloudFront에서 조금 더 빠르게 데이터를 제공받고, S3에서 가져온 데이터를 캐싱해놓고 제공하기 때문에 비용 절감의 이득까지 존재해요.
리소스들을 S3 스토리지에 저장해놓고, 정적 웹 사이트 호스팅 방식으로 웹사이트를 보여주고 있습니다. 이후 나올 CloudFront과 조합하여, CDN에서 좀 더 빠르게 웹사이트를 제공 받을 수 있습니다.
S3 정적 호스팅 주소 대신, 도메인 이름을 설정하여 그 주소를 S3의 정적 호스팅 주소와 연결합니다. 이를 통해 조금 더 직관적이고 기억하기 쉬운 웹사이트 주소를 사용할 수 있습니다. 추가로 서브도메인을 설정하여 www를 앞에 붙여 들어오는 유저들도 웹사이트에 접근할 수 있게 할 수 있게 만들었습니다.
보안 암호화 프로토콜인 HTTPS를 사용하기 위해 SSL/TLS 인증서를 받을 수 있습니다. SSL 인증서를 받고 이를 CloudFront에 적용하여, 데이터 전송 시 보안을 강화할수 있습니다! 이를 통해 사용자와 서버 간의 통신을 안전하게 유지합니다.
CloudFront는 CDN 입니다! 사용할 경우 여러가지 이점이 있는데요! 첫 번째로, 엣지 로케이션에서 리소스를 빠르게 사용자들에게 제공할 수 있어요. 전 세계에 분산된 엣지 로케이션을 통해 지리적으로 가까운 서버에서 콘텐츠를 제공함으로써 지연 시간을 줄이죠~
두 번째로는 리소스를 S3에서 직접 가져오는게 아닌 CloudFront에서 캐싱된 데이터를 가져오기 때문에 비용을 아낄 수 있어요! 좀 더 자세히 말하자면, 캐싱을 통해 반복적인 요청에 대해 더 빠르게 응답할 수 있으며, S3의 트래픽을 줄여 비용을 절감합니다! (생각보다 S3에 직접 접근하는 비용이 많이 나온다고해요.)
kyu-niverse도 CloudFront를 사용해서 정적 리소스를 좀 더 효율적으로 제공하고 있습니다.
개발을 완료하고 Build, Deploy 과정을 수동으로 하는데는 어느정도 시간 소요와 휴먼 에러가 발생할 수 있습니다. 인간은 거짓말을 하지만, 컴퓨터는 99.9%확률로 거짓말을 하지 않습니다. 이를 방지하기 위해 Github에서 제공하는 CI-CD를 사용하고 있습니다.
각 stage별로 명령 등을 수행하고 대표적으로는 Build후 Deploy하는 과정이 포함되어있습니다.
추가적으로 stage단계 중 Github settings에 환경변수로 등록해 놓은 value값들을 불러와 stage에서 env파일을 만들거나, s3 secret key등을 불러와 Deploy때 사용이 가능합니다.
배포가 완료하였는지, 실패하였는지의 유무를 즉각적으로 notice 받기 위해서 Slack incoming webhook을 사용하였습니다. 유무를 알기위해 Github Actions의 파이프 라인을 계속해서 모니터링하고 있는것 또한 시간 소모가 있기 떄문에 완료 혹은 실패시 다음과 같은 메시지를 받고 있습니다.
Deploy가 끝나면 webhook.sh 내부 스크립트를 실행시키고 있습니다.
다음 AWS의 기술들을 사용하여, 개발 후 큐니버스를 웹서비스로 제공하고 있습니다. 지금은 컨텐츠가 간단하여 위의 기술들로 인프라 구성을 할 수 있지만, Next.js의 서버기능들을 점차 사용하게 되면 컴퓨팅 자원이 필요하기 때문에 현재 인프라에서 변경되어야할 구조들이 존재할 것 같아요.
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent