부서의 기술스택을 익히고, 서비스 하나를 구현하면서 각 기술스택에 대한 느낀점을 정리해보았다.

MongoDB

장점

• 비동기적으로 DB와 연동을 하여 사용할 수 있다.

  • FastAPI 와 굉장히 잘맞는다.

• Document 형식의 DB지만, 그 구성이 RDB와 비슷하여 개념을 받아들이는데 큰 어려움이 없었다.
  (Collection은 Table에 대응
  Document는 row에 대응
  Field는 Column에 대응)

• 저장의 형태가 JSON 과 유사한 문서로 저장하기 때문에, 직관적으로 사용이 가능하다. (웹 개발에 굉장히 유리하게 느껴진다.)

• 스키마가 없다

  • 개발이 완료된 상태가 아니라, 새로운 기능들이 계속 많이 추가되는 개발 시점에서는 스키마를 고칠 때마다 그 비용이 굉장히 큰데, MongoDB는 스키마가 존재하지 않기 떄문에, 유동적으로 상황에 따라 스키마의 구조를 변경하며 최적의 구조로 변화가 쉽다.
  • 물론 이렇게 변환하는 경우 바뀐 형태로 이전 데이터들을 migration 하는 작업은 필요하다,

• 빠르다.

  • 과거 내가 RDBMS에서 했던 작업들을 MongoDB에서 구현했을 경우 정말 딜레이가 적었다. 그런데 이것이 FastAPI의 영향인지, 진짜 DB가 빠른지 정확하게 말할 수 없는 애매모호한 포인트들이 좀 있다.
  • 빠를 수 밖에 없는 이유 중 하나가 RDBMS에서는 중복되는 자료를 줄이기 위해 JOIN을 사용하지만, MongoDB는 내가 가져가야할 자료들을 한 공간에 딱 저장해두고 빼와서 쓰는 방식이기 떄문에 로직을 처리하는데는 시간이 덜 걸릴 수 밖에 없는 구조라고 생각한다. 하지만, 이 특성 때문에 더 많은 저장공간을 사용해야 할 수도 있는 것 같다.

단점

• [ 중요 ] 스키마가 없다.

  • 스키마가 없다는 소리는, 지금 내가 보고 있는 Document의 정보에 내가 원하는 Field가 없을 수도 있다는 뜻이다.

    이것 때문에 backend에서 에러가 날 수 있어, 방어코드를 계속 넣어줘야한다. 작은 양의 코드지만, DB를 참조할 때마다 넣어줘야하기 때문에 그 중복성도 늘어나고, 코드량도 많아지는 불편함을 가져왔다.

• 저장의 비효율성

  • 기본적으로 mongoDB는 입력되는 데이터와 출력되는 데이터 그대로를 저장해서 빠르게 입출력을 하는 게 가장 큰 장점이다. 그렇기 때문에 1번 에서 쓰이는 데이터와 2번에서 쓰이는 데이터가 형태가 다르면 중복 데이터가 있더라도 따로 저장해서 각자 쓰이게 된다.
  • 여기서 데이터 동기화의 문제와 데이터 중복 저장으로 용량을 더 많이 쓴다는 문제가 발생한다.
  • SQL의 join과 비슷하게 mongoDB에도 aggregation에 lookup이 있지만, 사실 mongoDB를 쓰는 본 목적에서 벗어난 행동이라고 생각해 꼭 필요한 때가 아니면 쓰지 않는 것이 좋다고 생각한다. 잘못쓰면 속도가 엄청 느려지기도 한다.

FastApi

장점

• Flask와 같은 단순함과 Flask에 비해 엄청난 속도를 가지고 있다.
  • 같은 로직을 Flask에서 수행할 때랑, FastAPI에서 실행할 때랑 확실히 차이가 있다.
• API를 만들기만 하면, 자동으로 swagger가 지원되어 문서화가 자동으로 되는 어마어마한 장점이 있다.
• 비동기 방식을 기본으로 하기 때문에, 좀더 램 자원을 효율적으로 사용할 수 있다.
• Pydantic을 기본으로 사용하고 있기 때문에 JavaScript에서 TypeScript를 쓰는 것과 같은 편안함을 느낄 수 있다.
• background-task 를 사용하기 위해서는 다른 프레임워크는 Celery같은 모듈을 사용해야하는데, 얘는 그냥 지원이 되고, 사용하기도 굉장히 편리했다.
  • 물론, 이메일 보내는 단순작업에는 활용성이 굉장히 높으나 더 비용이 큰 작업을 할 떄는 Celery와 같은 모듈을 사용하라고 FastAPI 문서에 적혀있긴 하다.

단점

• 부족한 Best Practiction들
  • FastAPI는 문서도 굉장히 잘되어 있는 편이다. 하지만, 아직까지는 사용자가 너무 적어 어떤 방식으로 구조화해서 사용하고 있는 지에 대한 Best Praction들을 개인적으로 찾아보기가 힘들었다.
  • 지금 내가 만들고 있는 프로젝트 구조와 비교해가면서 어떤 부분이 나을지 판단해보고싶었는데, 예시를 찾는데 너무 어려움을 느꼈다.

Redis

장점

• 빠르다.

  • 난 처음에 MongoDB 를 사용하고 있는데도 불구하고, 비슷한 기능을 제공하는 Redis를 왜 따로 사용하고 있는지 이해하지 못했다.
    사실 지금도 완벽하게 이해했다고 말할 수는 없다고 생각하지만, 자주 참조하는 자료에 대한 MongoDB의 부하를 줄여주는 역할(캐싱) 정도와 race-condition의 해결책으로 사용가능하다고 이해하고 있다.
    그리고, MongoDB도 빨라서 거의 내가 눈치를 못챌 정도긴 한데 MongoDB보다는 빠르긴 빠르다.

• Atomic하다

  • Redis는 single-thread 특성을 가지고 있기 떄문에 atomic 하여 race-condition을 피할 수 있다.
  • 이것은 동시에 여러 API에서 같은 테이블에 대한 수정과 조회를 실행하거나 할 때 오류를 방지해 줄 수 있는 좋은 역할이 되었다.

단점

• 단점이라고 느낄 부분이 거의 없었다. 굳이 뽑자면 내가 redis로 DB를 캐싱해 놓고, DB를 수동으로 수정한다음 기능들을 테스트할 일이 가끔 있는데 redis key를 삭제하는 것을 까먹고 해서, 왜 작동을 제대로 안하지? 하면서 시간을 날린 일이 있다... ㅠ

Docker

장점

• M1 맥의 부족한 호환성을 커버할 수 있는 좋은 수단이 되었다.

  • 인공지능 쪽에서 사용하는 모듈 중에 몇 가지가 python을 로제타로 돌려도 알 수 없는 에러를 반환하면서 돌아가지 않는 것들이 있다. 이것들의 오류를 하나하나 해결하는 것보다 그냥 docker로 띄워버리고, 코드 수정 후 docker로 다시 띄우고 하는 방식으로 처리해버리고 넘어간 것도 있다.

• 윈도우의 VirtualBox로 가상환경을 띄우는 것보다 효율적으로 자원을 사용할 수 있었다.

  • VirtualBox를 띄울 때는 고정적으로 얼마만큼의 RAM. hdd 이렇게 원래 컴퓨터에서 가져가서 구현이 되는데, Docker같은 경우 필요에 따라서 자원을 할당받고, 그것을 제한할 수도 있기 때문에 조금 더 사용이 원활했다.

• MSA구조에서 로컬환경에서 테스트를 하기 위해 띄워야하는 다른 부가적인 API들을 쉽게 올리고 테스트가 가능했다.

  • 하나하나 Pycharm에 띄우고 테스트하는 것도 굉장한 고역인데, 이런 쓸모없는 노동력을 줄이게 해주는 아름다운 툴이다.

단점

• 지금까지 단점을 느낀 부분이 아무것도 없다!

React

장점

• 장점을 못느끼겠다.. 도대체 이게 왜 주류인걸까?

단점

물론 Vue는 프레임워크이고, React는 프레임워크는 아니다. 하지만, 비슷한 역할을 하고 있다고 생각하기에

• 속도
  • Vue를 사용하다와서 그런가? 너무 느리다.
    일단, 코드 변경사항이 있을 때 반영되는 속도, 처음 yarn start 하여 랜더링 시작까지 걸리는 속도 전부 Vue보다 느리다.
    최적화도 마찬가지이다. Vue보다 최적화하는 방식도 어렵기도 하고 더 까다로운 부분들이 존재하는데, 속도는 Vue보다 안나온다...
• 개발자만 좋아하게 생긴 구조..
  • Vue 는 퍼블리셔와 함께 작업하기 편하게 하기위해 로직과 디자인의 구분에 신경을 굉장히 많이 썼다. 하지만, React는 디자인도 코드처럼 컴포넌트에 혼합되어 있어 그냥 웹프론트 혼자서 다해야하는 구조이다.
• 획일화되지 않은 구조
  • Vue 는 Router, Vuex(상태관리) 등등 전부 공식 모듈이 있어서 획일화되게 구조가 짜여질 수 있는데, React는 가장 큰 예로 상태관리에 Redux, Recoil, context, Mobx 정말 다양하게 사용되며 선호도 순위가 바뀌는 텀이 너무 빠르다.
  • 물론 이 것은 Vue는 프레임워크이고, React는 프레임워크가 아니라서 생기는 차이긴 하다.
• JavaScript를 굉장히 잘 써야한다.
  • React를 쓰면서 드는 생각이 이건 Vanilla JS를 잘하는 만큼 퍼포먼스가 나올 수 있는 프레임워크라고 느껴졌다. 그렇기에 Vue보다 훨씬 진입장벽이 높다고 느껴졌다.
  • Vue는 커피콩을 잘 가공하여 만들어진 커피라면, React는 커피콩을 씹는 것과 같은 날 것과 같은 맛이 강하다.