TL;DR1. 추상화 수준을 어느 정도로 할 것인가?Ts기반이며, 추상화 수준을 낮게 가져간다 => tRPC언어가 독립적이며, 추상화 수준을 낮게 가져간다 => gRPC추상화 수준을 높게 가져간다 => Rest, GraphQL2. Interface의 주도권을 누가 가질 것인가(client Or server)?client가 주도권을 가진다 => GraphQLserver가 주도권을 가진다 => Rest(Code-gen, Type-sharing)동등하게 주도권을 가진다 => Rest(ts-rest기반 zod계약) 3. 현재 상황과 기술적 특성을 고려했는가?팀의 러닝 커브, 마이그레이션 여부프로젝트 구조 (MonoRepo, MultiRepo, Stack..)Caching, Auth, Performance..데이..

TL;DRFront에 재사용 컴포넌트가 많이 생기는 경우, 컨벤션이 난잡해지는 경우Front와 Back의 타입을 공유하려는 경우 MonoRepo는 유용하다. Pnpm이 도입도 쉽고 성능도 준수하다. MonoRepo란?Project 여러개를 하나의 버전관리 시스템으로 관리하는 것이다. 프로젝트 각각 snap-shot이 남는지,프로젝트의 뭉치단위로 snap-shot이 남는지의 차이다. 프로젝트가 3개 Repo로 나누어져 있는데, 합치면 MonoRepo인가요? 내 책상의 서랍장 처럼,하나의 시스템에 우겨넣는다고 MonoRepo가 되지는 않는다.하나의 시스템에 여러개의 프로젝트를 넣으면 마법이 일어나는게 아니다.그렇게 했을 때, 이득을 보는 시나리오가 존재하기 때문에 사용하는 것이다. 여러 프로젝트를 뭉쳤을 ..

TL;DRAgile은 은탄환이 아니다.팀이 Agile할 준비가 되지 않았는데, 방법론만 무작정 도입한다고 되는게 아니다. 우리 팀에는 어느 정도의 Agile이 필요한지,애초에 Agile이 필요한지 고민해보도록 하자. 그리고 수단이, 목적이 되지 않도록!  Agile인 '척' 했던 지난날들Agile을 처음 알았을 때는, 은탄환처럼 보였다.백로그를 만들고, 추정을 하고, 스프린트를 하면 될거라 생각했다.데일리 스크럼을 하면, 플래닝 포커를 하면, 회고를 하면 될거라 생각했다.  도입하면 모든 문제가 해결되고, 프로답게 일할 수 있을 것이라 생각했었다. 지난 2개의 프로젝트를, Agile인 '척' 해본 결과는 썩 좋지 않았다.소소한 변화는 있었지만, 전혀 Agile하고 있지 않았다. 정말로 필요했던게 아니였다..