queensac 프로젝트의 아이디어를 얻게 된 과정이 궁금하다면 이전 글을 읽어봐주세요
queensac 기술 스택을 정하게 된 스토리를 따라가보자.
기능 분리
프로젝트의 기능은 나눠보자면,
- 사용자가 등록한 Repository에서 링크를 추출하는 로직
- git clone 한 후 파일에서 정규표현식으로 URL 파싱
- 추출된 링크가 유효한지 체크하는 로직
- GET 요청에 대한 응답 확인하기
- 유효한 링크를 찾는 로직
- 알고리즘 만들어서 대체할 링크 찾기
- 유효한 링크로 변경하는 PR 작성 로직
- 적당히 파일 수정하고 GitHub API 사용해서 PR 작성하기
이렇게 작업이 나눠지게 되는데 링크를 추출하는 로직과 추출된 링크가 유효한지 체크하는 로직을 비동기 병렬처리 할 수 있을 것 같았다. 그리고 일단 처음부터 하나의 언어로 개발할 생각은 없었다. 각각의 로직 / 서비스가 서로 독립적으로 보여서 잘 알지도 못하는 MSA 아키텍쳐로 만들어봐도 좋겠다는 생각을 잠깐 했다가 다시 집어넣었다.
언어 선정
기능이 정해졌으니 이제 구현할 언어 스택을 정할 차례였다.
후보에 있던 언어는 4가지 정도였다.
- Java: 4가지 후보 중에서 가장 경험이 많은 언어였고 개발한다고 했을 때 가장 빨리 MVP를 만들어 낼 수 있을 거라고 예상됐다.
- Kotlin: 우테코에서 어깨너머로 본 안드로이드 테코톡에서 코틀린의 코루틴이 병렬 처리에 뛰어나다고 들었던 기억이 있어 나쁘지 않을 것 같다는 생각을 했다.
- Python: FastAPI 프레임워크와 같이 짝짝꿍해본다면 이것도 역시 꽤 빠르게 개발해볼 수 있을 것 같았다.
- Rust: 통학 지하철 안에서 GeekNews를 보는데 여기서 보는 성능최적화 관련 글중 절반이 저희 Rust 사용해서 성능 최적화 했어요~ 라거나 Rust 기반의 번들러 출시!! 이런 글들이다. 그래서 이 프로젝트도 Rust로 구현해보면 좋겠다라고 생각을 했다.
사실 가장 끌리는 건 러스트였고 그래서 러스트를 선택했다.🥰
프레임워크 선정
학습희망 언어 만년 1위인 러스트를 구현 언어로 정하고 난 후, 이제 프레임워크를 선택할 차례였다. 자바 같은 경우에는 스프링이 굉장히 일반적인 선택이다. (자바 스프링을 공부했을 때도 내가 자바를 공부하는 건지 스프링을 공부하는 건지 애매했을 때도 많았다. 사실 이쯤되면 자바는 그냥 스프링 컴파일러에 불과할지도,,,)
반면 Rust에서는 Spring 처럼 가장 대표적인 프레임워크가 없다. Axum, Actix-web, Rocket 정도가 현재 많이 사용되고 있는 프레임워크이다. 이중 선택해야 했기에 깃허브 이슈나 PR을 살펴보고 공식문서를 살펴보았다.
Rocket은 위 세 프레임워크 중 GihHub 스타가 가장 많았지만, 1인 개발자가 개발해서인지 다른 프레임워크에 비해 개발이 느렸고 마지막 릴리즈도 작년이였다. Actix-web도 나쁘지는 않아보였는데, Axum이 tokio에서 개발한 프레임워크라 비동기 프로그래밍에 더 적합해보였다.
링크 체크 로직은 아예 lychee에게 맡기고, 우리 서비스에서는 이 유효하지 않은 링크를 적절한 링크로 대체하는 서비스로 만들 수도 있었다.
그러나 기술 스택을 정할 당시 lychee는 2달동안 개발되고 있지 않았었다. 내가 올린 PR도 몇주가 지나도 아무런 리뷰가 없어서 개발이 멈춘 오픈소스에 기대기보다는 바퀴를 재발명하는 느낌으로 직접 만들어서 사용하는게 좋다고 판단했다.
DB 선정
DB에는 어떤 정보를 담게 될지는 아직 명확하게 정해지지는 않았지만, 어떤 DBMS를 선택할지가 고민이 되었다.
자바만 사용했을 때는 MySQL만 사용해봤었고, 다른 언어들도 RDBMS는 대부분 MySQL을 사용하는 줄로만 알았다. 하지만 스택 오버플로우 설문조사를 보면 MySQL보다 PostgreSQL이 더 인기가 많은 것을 확인할 수 있다.
러스트 생태계에서도 PostgreSQL을 더 많이 사용하고 있는 것으로 보여 PostgreSQL을 사용하기로 하였다.
