2023. 5. 14. 16:52ㆍInternational Sign Lang 프로젝트/기획
예전 개발을 막 시작했을 시절에는 일단 코드부터 작성하고 봤는 데
이제는 코드부터 들입다 작성하는 게 오히려 미래에 프로젝트 진행을
더 더디게 만든다는 걸 알아 기능 리스트업부터 해요.
이번 프로젝트는 저 혼자서 프론트, 백엔드, 인프라까지 전부 다 관리하기 때문에
프론트, 백엔드, 인프라에 관한 모든 일정 및 todo 리스트까지
전부 제가 짜고 관리를 합니다.
노션 관리 페이지
https://devchpark.notion.site/I-S-L-Management-03be7a6c031c4b98b42df1e7129f0143
I.S.L. Management
A new tool for teams & individuals that blends everyday work apps into one.
devchpark.notion.site
오늘은 코드를 치기보다는
프론트, 백엔드, 인프라의 todo 리스트업을 한 노션 관리 페이지를 만들었습니다!
이 글의 제목처럼 일단 코드를 치는 것보다는,
내가 구현할 프로젝트가 개발적으로 요구하는 사항들을 리스트업 하는 게
더 중요하다는 것을 알기 때문에 먼저 작성했습니다!
그리고 노션에서 사용한 템플릿은
아래 링크에서 이메일을 기입하시면 사용 가능합니다!
https://www.notionway.com/free-notion-templates/notion-project-management
Notion Project Management - Notionway
Use this Notion Project Management template to complete your projects faster by having the rights system in place.
www.notionway.com
제 페이지에서 템플릿 복제를 잠가놨으니,
꼭 제작자 분의 템플릿을 사용해 주세요!
기술 스택
아직 기획 중이라서 확정이 나지는 않았습니다만,
머릿속에 구상 중인 사항은 다음과 같습니다.
프론트
- HTML, CSS, JS
- Next.js
- React
- Vue
현재 제 기획상에서 기능적으로 복잡한 사항은 없고
사람들에 최대한 노출이 많이 된다는 게 중요합니다.
따라서 React, Vue와 같은 SPA, CSR이고
프레임워크 같이 무거운 프로그램을 사용할 이유는 없기에
일단 사용하지 않기로 결정했습니다!
근데 React는 프레임워크가 아니라 라이브러리 아닌가요? 공식 사이트에서 그러던데
아주 정확한 지적입니다.
React 는 프레임워크가 아니라 라이브러리죠.
하지만 React 가 프레임워크라고 부르는 사람들이
꽤나 많은 이유 중 하나는 프레임워크처럼 강제되는 규칙들도 많고,
프레임워크 급으로 제공하는 기능들이 정말 많기 때문입니다.
기능들이 많다...? == 프로그램이 무겁다!
고로 사용하지 않기로 결정했습니다!
1번과 2번을 고려 중인데, 추후 next.js에 대해
공부하고 난 이후로
백엔드 & 인프라
이번 백엔드는 node.js를 사용하고,
AWS Lambda에 node.js 코드를 올리기로 결정했습니다.
이렇게 결정하게 된 이유는 다음 2가지입니다.
- 하루 쿼리량이 10,000개 이하라면 AWS Lambda 가 EC2 보다 더 싸다.
- Lambda 에 최적화된 언어는 Python, JavaScript이고
둘 중 JavaScript 가 그나마 더 자신 있어서
1. AWS Lambda vs AWS EC2?
이렇게 정하게 된 이유에는
최근에 수강했던 원티드 백엔드 프리온보딩 때 들었던
멘토님의 말씀 때문입니다.
서버리스에 대한 개념과 배포법에 대해 배우던 중
서버리스로 Lambda를 배포하는 게
EC2 보다 더 좋은 경우가 존재하냐라는 질문을 했는 데
이렇게 답변을 주셨습니다.
정확한 건 사용하는 Lambda 나 EC2의 스펙을 따져봐야 하지만,
보통 하루 평균 쿼리량이 10,000개 이하라면 보통은 Lambda를 사용하는 게
더 싸게 먹힌다.
한 번도 서버리스로 배포를 해본 적이 없어서
이때 당시에는 그려려니 했다 이번에 ISL 기획을 하다 보니
이 말이 떠올라, 초기에는 말씀하신 서버리스로 가는 게 더 좋다는 생각이 들었습니다.
그래도 정량적인 데이터를 따질 수는 없나?
라는 고민을 하다 다음 사이트를 찾고 비교를 해봤습니다.
AWS Pricing Calculator
calculator.aws
위 사이트에서 Lambda와 EC2를 각각 만약
실제로 사용한다면 이 정도 스펙(제일 싼 거)으로 하겠다 싶은 조건을 맞췄습니다.
보시게 되면 EC2는 월 3.8 달러가 나가게 되지만
Lambda는 월 비용이 거의 나오지도 않습니다.
따라서 가난한 주인장에게는 Lambda 가 더 저렴한 솔루션임을 알 수 있고
저는 Lambda를 선택할 생각입니다.
2. Lambda 에는 Javascript?
주인장은 원래 Java를 주로 사용합니다.
평소의 알고리즘 공부도 Java로 하는 편이기도 하고요.
그렇다면 Java+Spring Boot를 Lambda로 띄우면 안 되나?
라는 생각도 해봤습니다만, 이는 Lambda의 두 가지 조건 때문에
할 수 없습니다.
1. Lambda 에는 cold start라는 개념이 존재하고, 언어별로 이 cold start의 latency 시간이 다르다.
위 그래프는 언어별로 Lambda에서 걸리는 cold start에 대한 표입니다.
보시면. Net과 Java는 압도적으로 올래 걸리는 언어입니다.
그중에서도 저의 주 사용언어인 Java 가 오래 걸리는 이유는
바로 Java 가 JVM 위에서 동작하는 언어라는 특성 때문이죠.
평소의 Lambda는 전원이 꺼져있어
Client에서 요청이 Lambda를 통해 들어가야
그제야 Lambda는 시동을 하게 됩니다.
이때 만약 Lambda 안 코드가 Java 라면
해당 언어를 해석하기 위해 Lambda 는 JVM을 먼저 실행시켜야 하고
이 때문에 Lambda에서 Java 가 다른 언어보다 느린 겁니다.
2. Lambda 에 배포할 수 있는 코드의 용량 상한선 존재
AWS Lambda에는 패키지 크기에 대한 제한이 있습니다.
압축되지 않은 경우 패키지의 최대 크기는 250MB, 압축된 경우는 50MB입니다.
따라서 이러한 제한으로 인해 Spring Boot 애플리케이션을 AWS Lambda에 직접 배포하는 것은 어려울 수 있습니다.
여기까지가 주인장이 오늘 하루 ISL에 대해 생각한 기획들입니다.
피드백은 언제나 환영입니다 :)
즐거운 하루 보내세요!