Linkuni

2022년 8월 24일(수)부터 8월 29일(월)까지 진행했던 테오의 스프린트의 후기입니다!

정말 즐겁고 뜻 깊은 경험이었어요! 우리 “쿠니스”들과 이 기회를 만들어주신 테오에게 감사의 말씀을 전합니다 😆!

본문에선 크게 다음과 같은 내용이 진행됩니다.

  1. 스프린트 참여 계기와 진행.

  2. 스프린트를 하며 배운 점.

왜 참여하게 되었나요?

열정도 살리고 협업도 경험할 목적으로 신청했습니다! (개인적인 이유로 간절했거든요!)

슬럼프?

올해, 7월 코로나에 걸려 체력적으로 정신적으로 매우 힘든 시기였습니다. 🫠

하필이면, 코로나 후유증도 길고 강하게 남아 하루하루가 너무 지쳐서 7월, 8월 동안 회사 일 이외엔 그 어떤것도 제대로 해내기 힘들었습니다. 😢

그 때 마침 스프린트 공지를 보고, 이건 즐겁고 빡세게 개발하면서 슬럼프를 빠져나올 수 있는 기회다! 라고 생각해서 바로 지원했습니다!

협업 경험이 간절했다…

회사에서 1인 개발로 반년정도 일하다 보니, 기술적으로, 협업적으로 고여있다는 느낌을 많이 받았습니다.

상황에 따라 적당히 main 브랜치에 push해도 아무도 뭐라 할 사람 없는 환경…!

뭐든 할 수 있어 좋은 환경이라고 할 수 있지만,

반대로 로직에 대한 막중한 책임감과 누가 봐주지 않기 때문에 어떻게든 의식적으로 스스로 다시 돌아봐야되는 상황에 피로가 쌓여 함께 개발할 동료가 간절했습니다. 😭

(스프린트를 신청하고 얼마 후 잘하는 FE 동료분이 오셔서 재밌게 일하고 있습니다 😆)

스프린트 진행

8월 25일 (수) 대망의 스프린트가 시작되었습니다!

쿠니스들과의 만남

전 11기 2조가 되어 “쿠니스”라는 팀이 되었습니다.

10명 모두 개발에 열정적인 분들이고 성격도 너무 좋으신 분들이라 마찰도 거의 없이 즐겁게 진행했던것 같습니다! 😆

매일 새벽 3시 정도까지 힘든 상황에서도 재밌고 웃음을 잃지 않던 자랑스런 우리 쿠니스들!

(정말 진심으로 좋았어요! 함께 해줘서 고마워요 쿠니스들! 🙌)

kunis

링쿠니 LinKuni

개발 서비스는 “링쿠니” 링크 + 바구니의 합성어입니다!

개발 공부를 하면서 인터넷에 유용한 아티클 주소들을 많이 모으는 편인데, 모으다 보면 텍스트로 줄줄이 이어진 뭉치들이 점점 많아져 관리가 불편했습니다. (그렇게 다시 안보게 되는건 함정,,,)

마침 링크들을 편리하게 관리해 줄 수 있는 아이디어가 있어 이에 깊이 공감해 함께하게 됐습니다!

idea

PL (Project Leader)

스프린트에서 PL은 기술 총괄이라고 할 수 있습니다.

현업에서 일하고 있고, 경력도 팀원 중에서 높은 편이라서 그런지 팀원들의 지지속에 팀 내 FE 경력 왕고 “티리”와 함께 PL이 되었습니다,,,ㅎㅎ

role

협업 경험이 많이 없어서 굉장히 불안하고 미숙했는데도, 끝까지 믿고 호응해 주셔서 진심으로 감사합니다. 🙏

(BDD와 SDD, 태스크 분배와 프로젝트 세팅은 하면서도 너무 엉망이라 스스로 정말 걱정을 많이 했습니다,,, ㅠㅠㅠ 😭 ㅎㅎㅎ 😇)

taskSetting

개발 과정들

(치열했던 브레인 스토밍 과정! 🔥)

brainStorming

(컴포넌트의 UI와 UX 회의)

componentSetting

(구체적인 와이어프레임 그리기 🏞)

wireFrame

결과물

kunisResultInKakao

Linkuni 서비스 link

Linkuni 깃허브

우선 서비스는 기획대로의 완벽한 정도는 아니지만, 어느정도 완성도 있게 나왔다고 생각합니다.

쿠니스의 갓갓 디자이너 “태태”와 “무지”의 서비스 디자인이 예뻣던 게 크다고 생각해요!

(고마워요!! 태태 무지! 🙌)

후에 기획을 정비하고 리팩토링을 거쳐 본격적으로 chrome extension으로 출시해도 재밌을 것 같습니다!

배운 것들

개인적으로 이번 협업 경험을 하면서 배운 것들이 정말 많습니다.

누구나 머리로는 아는 내용이고, 저 또한 익히 들어 알고 있는 사실이지만, 직접 경험해보니 정말 피부로 와닿는 느낌이었습니다. (절대 잊지 못할 것 같습니다.)

최근까지 코로나로 제대로 된 협업 기회를 얻기 쉽지 않았는데, 정말 행운이었다고 생각합니다.

구체적이고 명확히 볼 수 있어야 이해할 수 있다.

레퍼런스를 모으고, 구체적으로 서비스를 만들어가는 과정에서 시각적 자료의 힘을 깨달았습니다.

팀원중에서 와이어 프레임과 시각적 툴로 깔끔하고 명확하게 시각적 자료를 준비해오신 분들이 더 간단한 설명으로 명확히 팀원들을 이해 시켰고 팀원들의 호응을 더 많이 받았기 때문입니다.

(우기의 wireFrame, 저 캥거루 캐릭터가 저희 링쿠니 마스코트의 전신이 되었습니다! 👍)

ugi_wireframe ugi_wireframe2

(태태의 wireframe, 귀여운 캐릭터와 함께 모든 컴포넌트들이 한 눈에 들어옵니다!)

tete_wireframe

(로베의 wireframe, 템플릿들을 적절히 조합해, 최단시간에 시각적으로 보기좋고 명확한 와이어 프레임을 만들었습니다!)

평소 익숙하지 않은 것들에 대해 수고를 덜어줄 수 있는 것들을 잘 찾아놓는 것도 좋은 것 같습니다…!

robe_wireframe robe_wireframe2

책임지지 않는 의견은 의미가 없다.

초반에 Link 분류 기능을 어떻게 할까 논의하던 당시,

Notion같은 멀티 태그 방식과 전통적인 Tree구조의 카테고리 방식의 의견이 부딪쳤습니다.

모두 익숙한 툴이 다르고, 최선이라고 생각하는 방법이 다르니, 거기에서 파생되어 나온 UI 아이디어도 제각각이었습니다.

여러 의견들이 난립할 때, 테오가 개입하면서 다음과 같이 조언해주었습니다.

  지금 이 상황은 책임자가 없기 때문이며,
  이렇게 서로의 의견만 내세우면 감정만 상할 뿐이다.
  따라서 그동안 서로 소개도 하고 대화도 많이 하면서
  각자의 장점을 파악했을 테니, 이 부분에 가장 적합한 사람을 합의를 통해
  책임자를 정하고 나머지는 이에 따르는 것이 중요하다.

늦은 시간까지 서로 대화를 많이 했던 “쿠니스”들, 테오의 조언대로 디자인을 공부했었던 “태태”를 책임자로 시각적으로 간편하고 이쁜 UI 형태를 결정한 것을 시작으로 분류 기능을 구체화하기 시작했습니다!

최종적으론 멀티 태그 방식과 카테고리 방식이 절충된 훌륭한 결과물이 나왔습니다. 👍

linkuni_demo

이전까지는 모두 평등한 상태로 시간을 들인 치열한 토론을 통해 가장 최선을 고르는 것이 최고라고 생각했습니다.

하지만, 이번 경우에는 시간이라는 자원은 한정되어 있고 사람들의 장점은 제각각이기에 모든 의견이 최선이라고 할 수 없기에 책임자를 둠으로서 좀 더 효율적으로 문제를 헤쳐나갈 수 있었다고 생각합니다.

잠깐 고생해서 영원히 효율적이다! lint와 협업 규칙의 중요성

lint 규칙과 branch 제한 설정 등의 협업 규칙 시스템은 복잡하고 시간이 들지만, 그 이상으로 팀원들을 편리하고 명확하게 해주어 팀원들의 효율성과 협업 효율성에 큰 영향을 미친다는 것을 깨달았습니다.

쿠니스 팀원 중엔 현업에서 일하는 사람도, git을 처음 써보는 사람도 있었습니다.

코딩하기에 앞서 cra 및 여러 config 베이스를 준비 및 배포하고, 구체적인 브랜치 전략과 협업 방식을 설명했습니다.

하지만,,,,,,,,, lint와 branch restriction 등의 제약 등을 준비하지 않은 댓가로 엄청난 conflict 및 git history가 꼬이는 사태가 발생했습니다. 😭 (conflict resolve는 Project Leader의 몫…😇)

뒤늦게나마 8월 4일(토) 밤을 꼬박 세워 프로젝트에 lint + prettier를 적용해 코드 스타일을 통일했습니다.

lint

거기에 PR description에 익숙하지 않은 팀원을 위해 PR template을 만들어 형식에 대한 고민하지 없이 자세한 description을 쓸 수 있도록 했습니다.

PR_template

(template대로 멋지게 PR description을 작성해주신 쿠니스의 “로베” 👍)

good_pr good_pr

코드의 일관성을 지킨다는 것.

코드의 일관성은 가독성 뿐만아니라 merge와 code review에도 크게 영향을 미친다는 사실을 알았습니다.

Lint를 적용하기 전엔 분명 같은 코드인데 다른 코드 스타일로 인해 conflict가 여러번 발생했었는데, 이런 것을 일일히 확인하는 것은 굉장한 비효율이었습니다…

후에, Lint를 적용하고 코드 스타일이 통일 되어 conflict가 확연하게 줄었고, 덕분에 다른 코드 리뷰와 피쳐 개발에 집중 할 수 있었습니다.

(conflict와 사투를 벌였던 commit 기록 ㅎㅎ)

conflict

중요한 협업 규칙은 시스템으로 강제되어야 하고, 팀원들이 사용하기 편리해야 한다.

git으로 처음 협업해보는 팀원 중에 PR이 익숙치 않아 main 브랜치에 그대로 push하는 팀원이 있었습니다.

치명적이진 않았지만, rebase와 그에 따른, conflict로 시간이 많이 지체됐었습니다.

(너무 무분별하게 push되는 것을 막기 위해 restiction을 두었습니다.)

branchrule

또한, 문제가 발생할 때마다, 협업 규칙을 다시 설명하고 해결 해줬었는데, lint와 규칙을 설정함으로 이 설명을 시스템에 위임하여 커뮤니케이션 비용을 크게 줄일 수 있다는 것을 배웠습니다.

많은 기업과 단체들이 branch 수정 및 접근 권한을 철저하게 두는데, 이번 기회로 협업 규칙 시스템의 중요성을 경험했습니다.

마무리

5일간의 새벽 코딩으로 체력적으론 굉장히 힘들었지만, 정신적으론 정말 충만한 시간이었다고 생각합니다.

테오와 쿠니스들 덕분에 강의로도 배울 수 없는 갚진 경험과 함께 다같이 개발하는 즐거움을 다시금 느꼈습니다. 😄

감사합니다!

앞으로의 협업에 있어 배웠던 점을 다시금 생각해보고 적용하면서 더욱 효율적이고 즐거운 협업을 할 수 있을 것 같다는 생각과 이를 이뤄내기 위해 더 노력해야겠다는 생각을 합니다!

🍀