[크라운드] #1, 우리는 어떻게 이야기하고, 관리하고 있을까

지난달말부터 디자이너1, 프론트1, 백엔드1의 구성원으로 토이 프로젝트를 시작하게 되었다.
 
주제는 흔히 보이는 멘토멘티를 매칭 서비스로 모집했지만 커피챗 서비스로 약간의 방향만 바꾸었다.
최종적으로 1인 크리에이터를 위한 커피챗 서비스를 만들기로 결정되었다.

https://github.com/cround-team/cround-server

GitHub - cround-team/cround-server: cround server repository

 
 

우리는 어떻게 소통하고 있을까

카카오톡, 노션, 디스코드, 깃허브로 이야기를 나누고 있다.
 
카카오톡은 텍스트로 주고 받아도 괜찮은 공통적인 의논 내용들로 이야기를 나누고 있고, 
노션은 회의록과 공통 문서화 작업과 같은 내용들을 담고 있다.
디스코드는 텍스트가 아닌 음성 회의를 진행할 때 사용하고 있으며,
깃허브는 프론트와 백엔드의 버전 관리를 위해 쓰고 있다.
 
 

나만의 룰은 이렇다.

아무래도 각 분야별 한 명의 인원만 존재하므로
진행 과정(과거, 현재, 미래)을 한눈에 볼 수 있어야 했고,
문서화를 보다 명확히 해야하고,
나의 방식이 적절한지를 검증할 수 있어야 했다.
 
 

진행 과정과 문서화는 깃허브와 노션으로 한다.

꼼꼼히 기록하기 위해 Issues, Pull Requests, 그리고 일정 관리는 Milestones, Projects을 적극 활동하기로 했다.
 
이전에도 위 기능들로 관리하긴 했지만 나사가 빠진 듯한 과정으로 진행됐었다.
그래서 Issues와 Pull Requests를 묶고, Pull Request는 단순히 거쳐가는 과정으로 쓰기보다 의미 있는 내용들을 담아보려고 노력하고 있다.

 
또한, 팀 회의를 통해 일정 조율을 하긴 해도 '나'를 기준점으로 삼아 일정 관리를 하기 위해 스프린트(Sprint)를 위한 마일스톤과 칸반보드 기반의 프로젝트를 적용해보기로 했다.
 
일반적으로 많이 본 스프린트의 주기는 2주였지만, 혼자 진행하기도 하고 무엇보다 나를 믿지 못해서(?) 한 주 더 짧게 스프린트의 주기를 1주로 가져가기로 했다.
 
 

내가 나를 검증한다.

부제의 이름이 나를 검증한다고 했지만 실제 검증은 도구에게 맡기되 검증 과정은 주체적으로 한다는 의미이다.
 
그래서 적용한 것이 '정적 분석 도구'들이다.
구조적으로 큰 개념인 아키텍처나 조금 더 작은 개념은 사람이 리뷰하는 것만큼 할 수는 없겠지만
최.소.한 정적 코드에 있어서는 검증하자는 것에 의의를 두려고 한다.
 
IDE에서 정적 코드 문제를 탐지하는 소나린트(SonarLint)와 ChatGPT로 구동되는 중국인 개발자가 만든 코드 리뷰 봇을 도입했다.
 
소나린트로 정적 분석을 하게 되면 다음과 같이 특정 코드에 개선 사항이 있는지 확인하고

 
어떻게 개선해야 하는지도 알려준다.

 
더 이상 개선점이 없다면 반영(merge) 하기 위해 feat 브랜치에서 dev 브랜치로 Pull Requests를 날리게 되는데
PR이 생성되면 gpt가 또 한 번의 코드 리뷰를 진행해 주게 된다.

다만 변경된 코드의 특정 부분들만 코드 리뷰를 해주다 보니 완벽한 코드 리뷰 형태가 아니라서 정확성은 떨어지지만, 제안해 주는 포인트들을 읽으면서 놓친 부분들이 있는지 확인할 수 있어서 꽤나 유용하게 사용할 듯하다.
 
 

그래도 리뷰어는 역시 '사람'이다

어제 백엔드쪽 이슈가 있어서 단톡방에 의견과 건의를 드려봤는데, 프론트 개발자님 뿐만 아니라 디자이너님도 대안과 같은 아이디어를 내주신 것이 나에게 크나 큰 도움이 되었다.

 
그리고 이 과정에서 '코더는 누구나 될 수 있지만, 엔지니어는 누구나 될 수 없다'는 것을 몸소 알게 되었다.
아마 내가 짰더라면 코더의 코드로 작성했을 것이다.
 
좋은 설계, 좋은 아키텍처, 좋은 아이디어처럼 구조적인 것이 생각보다 더 중요하다고 느꼈다.
이러한 이유로 시니어 개발자나 리드 개발자가 꼭 있어야 한다는 것을 다시 한번 배웠다.
 
여담으로 나에게 어려운 내용이 많긴 해도 최근 들어 개발자이자 저자이신 최범균 님의 유튜브를 종종 보는 편이다.

실무를 경험하는 게 아니라면 아무래도 구조적인 것을 배우기란 여간 쉬운 일이 아닐 것이다.
올해 초에 우연히 최범균 님의 유튜브를 알게 되었는데 구조적인 것을 다룬 영상들이 많아 꽤나 흥미롭게 보고(만) 있다.
 
이것이 언젠간 초석이 되리라 생각하며, 올라오는 영상을 틈틈이 눈에 익히고 있다. (주저리주저리,,)
 
 

앞으로의 크라운드 이야기는

레포를 파서 코드를 작성한 지 1주일채 되지 않은 기간 동안 여러 문제와 해결 과정이 있었다.
처음엔 문제들을 별도로 적어놓고 블로그에 포스팅을 써야지라는 생각이었다.
 
사실 문제와 해결에 정보를 더한 양질의 내용으로 적어야 하지 않을까란 고민 때문에 포스팅까지 이어지는데 꺼려졌다.
지금은 그래도 일단 쓰자란 생각이 강하게 들어서 부족한 내용을 담더라도 쓰는 것을 중점으로 두려고 마음을 다잡았다.
 
 

끝으로

교육 과정을 제외하고 프로젝트를 해본 건 처음이지만 너무나도 만족하고 재밌는 시간들을 보내고 있다.
하나의 결과물을 위해 서로 조율해 나가는 과정과 고민하는 것에서도 드릉드릉(...) 하고 있다.
 
프로젝트 인원을 모집하면서 중요시한다고 쓴 것들이 있다.

• 완벽보다 완성을 한다.
• 잘 소통하고, 빠르게 공유한다.
• 꾸준히 하는 것만큼 기록하는 것도 중요하다.

모든 과정은 이것부터 시작된다는 마음을 잊지 않으려 한다.