추후 SW마에스트로에서 협업하기 위해

1. 저장소 아키텍쳐

우린 백/프론트모두 js(ts)로 개발할 예정이다. 따라서 멘토님이 모노레포 아키텍쳐를 추천해주셨다.

멀티레포 아키텍쳐는 변경사항이 배포돼야 다른 저장소에서 접근 가능하다.

하지만, 모노레포는 변화가 실시간으로 반영된다. 이것은 양날의 검이다. 만약 버그가 있는 채 또는 구현 도중 pull을 한다면 동작이 안될 것이다. 

그리고 별도로 공부하고 고민한 결과 모노레포만의 장점들이 존재한다.

1. 모든 서비스에서 적용되는 공용코드들을 여러번 생성할 필요가 없다.

2. 관리엔드포인트가 하나로 줄어든다.

3. 생각보다 프로젝트 생성 후 배포까지 고려해야할 사항들(ci/cd, 환경 구축 등)이 많은데, 이 작업을 줄일 수 있다.

게다가, 소규모협업이고 팀원 모두가 백, 프론트를 넘어들 예정이라 긍정적인 생각이다.

그래도 난 아직 경험해보지 않았고 복잡성에 대한 고민은 추가로 해야할 것이다.

2. 협업툴

jira, github issue를 고려할 수 있다.

jira는 초기 세팅에 대한 고민이 있고, github issue는 관리안되는 포인트가 (우리가 엄청 노력하지 않으면) 많이 생긴다는 것을 고민해봐야한다.

그러다 linear을 추천받았다. 스프린트 기반으로 어느정도 세팅이 주어지고, github과도 호환되는 툴이다. 하지만 이를 사용한다면 우리의 업무 프로세스를 툴에 어느정도 맞춰야할 필요가 있을 것이다.

3.스프린트

프로젝트를 하면서 늘어지지 않는 것은 중요하다. 따라서 스프린트를 고려해볼 수 있다. 게다가 주당 진척도를 파악하기 좋고, 어느정도 빠른 사이클로 업무가 진척되므로 동기부여도 될 것이다.

멘토님이 스프린트의 문제에 대해 이야기해주셔서 생각해봤더니 문제는 스프린트 자체의 특성에 있다.

스프린트는 빠른 사이클로 이루어진다. 따라서 사이클 내 업무파악은 용이하지만 전체 업무파악이 어려워질수도 있다. 

스프린트는 빠른 사이클로 이루어지므로 그만큼 심리적 && 체력적 압박이 주어진다. 특히 업무가 미뤄졌다면 그 감정은 심화될 것이다. 

둘 다 큰 리스크라고 판단한다.

그래서 처음에는 빠른 주기와 자신감 있게 한주의 일을 등록하다가 프로젝트를 진행하고 회고하며 주기와 일의 분할, 양을 조정해야겠다는 마음이 든다.

4.코드 리뷰

대화를 해보니 리뷰 템플릿을 정하는 것 외에도 여러가지 신경쓸 사항들이 있었다.

현업에서는 PR에 description을 깔끔하게 작성하는 것 뿐만 아니라 해당 PR에 해당하는 업무용 툴의 링크를 명시하고, 스크린샷과 비디오같은 멀티미디어도 대폭 활용한다고 한다. 코드 역시도 로컬과 branch가 아닌 commit에서 직접 인용한다고 했다.

실제로, 단순 글과 코드는 코드를 파악하는데 비효율성을 느껴 도입해야할 필요성을 느낀다.

bito와 codeRabbit같은 ai 코드리뷰서비스도 있으나, 개인적으론 아직은 ai 자체의 한계성을 느껴 이것은 그렇게 구미가 당기지 않는다.(도입이 쉽고 싸다면 안할 이유는 없긴 하다.)