Mincho 프로젝트의 이번주 #1 - 팀 빌딩하는 방법

소개글

• 새로운 오픈소스 프로젝트 개발을 시작합니다.

주간레터

1. Mincho 프로젝트의 이번주 #1 - 팀 빌딩하는 방법 (현재)

2. Mincho 프로젝트의 이번주 #2 - RFC-TDD 프로세스로 개발하기

3. Mincho 프로젝트의 이번주 #3 - 깃허브 봇들과 함께해요

4. Mincho 프로젝트의 이번주 #4 - JSON 콘솔 디버깅 라이브러리 배포

먼저 기쁜 소식이 있습니다.
제 프로젝트가 트렌딩 프로젝트 1위에 올랐습니다.

#물들어올때_노젓자 는 심산으로 이번주에 한 일을 적어보고, 어떻게 일하는지도 소개해보려 합니다.

1. 계획

2. 실행

3. 홍보

4. 로고 with AI Driven

계획

사실 저 말고 팀원이 한분 더 계시는데요,
회사 분을 꼬셨습니다..ㅋㅋ

때문에 저 혼자 작업할때는 간단한 메모로 남겨두고 진행했던 일도 문서화가 필요해지게 됩니다.

먼저 개발자 대회 일정에 맞추어 전체적인 작업의 마감라인을 정했어요.

그 후에는 해야할 목표를 정합니다.

팀원의 목표와 할 일 또한 정해야 하는데, 역시 모든 시간을 쓰기는 어렵기 때문에 감안하여 정해야합니다.

저는 온보딩을 위해 설계 문서 채우기를 통해, 프로젝트에 대한 이해도를 높히고 구현해야 하는 부분을 미리 고민하도록 할당하였습니다.

또한 어떻게 이루어질지에 대해 프로세스를 안내했죠.

실행

브랜치 병합

먼저 이미 구현되어 있던 기능들을 Merge 합니다.

원래는 리뷰과정을 거쳐야 하나, 현재로서는 피어리뷰까지 거칠만한 리소스가 없기 때문에 PR단위 기록만 남겨두기로 했습니다.

이때 저희는 Fast Forward와 Rebase를 이용한 선형 커밋기록을 선호하는데요.

복잡한 Merge 구조로 인한 혼동이 매우 적기 때문입니다.

따라서 커밋 기록을 보면 Merge branch 어쩌고 from 저쩌고 가 없는 모습을 볼 수 있습니다.

선형 구조를 유지하기 위해서 git-branchless라는 툴을 적극적으로 활용중이고요, 제 블로그 글을 읽어보시는 것도 추천드립니다.

• 더 나은 Git 워크플로우를 향해서

추후 가능하다면 구체적인 방법이나 후기를 더 공유하도록 하겠습니다.

설계 문서 초안 작성

팀원분이 작성할 설계 문서에 대해 스펙을 미리 잡아놔야 병목이 없겠죠?

때문에 설계 문서 초안을 미리 작성해둡니다.

저희는 Rust RFCs와 CSS Working Group의 사례와 같이 실제로 코딩하기전에 미리 RFC를 작성하며 구현이 될 기능, 구현 가능성, 참고할만한 컨텍스트등을 공유하도록 하고 있어요.

여기에는 많은 장점들이 있습니다.

1. 라이브러리의 스펙을 미리 정해두면 오해를 할 가능성이 낮습니다.

2. 구현을 할때도 스펙의 내용을 보면서 작업하여 컨텍스트 전환이 적습니다.

3. 스펙을 이용하면 테스트 코드를 만들때도 편합니다.

4. README나 웹사이트, 각종 문서를 구축할 때도 크게 도움이 됩니다.

5. 팀원과 프로젝트에 대해 이야기할 때도 RFC를 기준으로 참고하고, 내용이 부족하다면 업데이트하기가 쉽습니다.

6. 한국인이 아닌 팀원이 들어온다고 하더라도 확장이 가능하며, 팀원이 아닌사람이라도 스펙을 제안할 수 있는 구조입니다.

7. 프로젝트 설계 히스토리를 독점하는 사람이 없이 공유됩니다.

RFC 문서의 구조는 Rust를 적극적으로 참고하여 만들어졌습니다.

1. Summary (요약)

2. Motivation (동기)

3. Guide-level explanation (사용자가 실제로 사용하는 부분)

4. Reference-level explanation (구현 부분)

5. Drawbacks (접근 방식의 단점)

6. Rationale and alternatives (근거 및 대안)

7. Unresolved questions (풀리지 않는 질문)

8. Future possibilities (추후 가능성)

이번에는 온보딩이 주 목적이기 때문에 목차와 일반적인 부분은 제가 써두고,

상대적으로 많이 알려진 기능이나 기존 RFC를 참고할 수 있는 내용을 위주로 채우도록 만들어두었지요.

홍보

아직 만들어지지도 않은 프로젝트라 역시 고민이 많았는데요.

우선 인플루언서가 아니고, 그렇다고 조회수를 많은 블로그를 가지고 있지 않거든요. ㅠㅠ

그래도 일전에 오픈소스를 하며 얻은 작은 성과로 인해 개발 상황 공유와 빠른 피드백 루프가 중요함은 잘 알고 있습니다. 프로젝트 주간 레터를 발행하는 이유이기도 해요.

• 하루만에 깃허브 스타 500개 모은 이야기

게다가 이런 저런 상황으로 인해 프로젝트의 개발이 미루어질 것을 염려하여 일단 선언하고 따라가야하는 상황을 만들어버리자는 생각이 들어 디스콰이엇에 가입하고 글을 남기게 됩니다!!

• 새로운 오픈소스 프로젝트 개발을 시작합니다.

주간레터용으로 트렌딩 프로덕트 5위에 진입한 스샷을 찍어놨는데..!

1위가 되버려서 매우 기쁩니다!!
특히 처음 들어와 갈팡질팡할때 권도언님이 많이 도와주셨고 디스콰이엇 뉴스레터에도 실리게 되었습니다.

깃허브에는 5분이나 스타를 눌러주셨고요.

이전에 5k 스타를 받은 프로젝트를 운영하고 있는 체감상 100개까지 채우기가 1000개 보다 어렵고요, 1000개가 5000개보다 어렵습니다.

때문에 한분한분 정말 고마운 분들입니다.

프로젝트에 관심가져주신 모든 분들께 감사드립니다.

로고 with AI Driven

그런데 글을 남기고, 프로덕트를 등록하려면 로고가 필요하겠더라고요.

저는 AI를 활용해 1시간 반정도로 로고를 만들었어요.

대부분의 시간은 서비스 검색이나 재생성 시도에서 소모되었습니다.

1. 급하게 Wix Logo Maker라는 AI 아이콘 생성기로 200x200짜리 무료 로고를 만듭니다. (고해상도는 유료)

1. 이런 컬러가 마음에 들지 않았습니다. Phind에서 cluade에게 물어 컬러코드를 #CFFFE5 로 바꿉니다.

1. AI로 업스케일링 하여 800x800으로 사이즈를 키웁니다.

1. 오픈소스 프로그램인 Krita롤 이용해 사이즈가 커지며 깨진 부분을 수정합니다.

이상 귀여운(?) 로고가 탄생한 과정이었습니다.

정리

첫주에는

1. 전반적인 일정을 잡고,

2. 프로세스를 구축하며,

3. 한국어 홍보 파이프라인을 만들어 두었습니다. (영어권은 따로 필요합니다.)

이제는 진짜 본격적인 개발 시작해야죠.

혹시 개발에 관심이 있으시다면 댓글을 달아주시거나 alstjr7375@daum.net에 연락을 주셔도 좋습니다.

하단의 업보트와 깃허브 스타를 찍어주셔도 매우 큰 도움이 됩니다!!

- 첫번째 뉴스레터 끝 -