[Webinar] 첫 웨비나 연사 참여기

☁️ Overview

지난 주 화요일, 9월 20일에 ICT 멘토링에서 주최하는 '2022 ICT 멘토링 GitLab Meetup 2차 웨비나'에 두 번째 세션 연사로 참여하게 되었다. 지금 ICT 멘토링 한이음 프로젝트에서 멘티로 참여하고 있는데 뜻 밖의 좋은 기회가 주어졌다. 8월에 한이음에서 주최하는 깃랩 파이프라인을 이용한 배포 핸즈온 수업을 듣고 우수 수료자로 선정된 적이 있는데, 이때 우수 수료자들을 대상으로 발표 기회를 주셔서 참여하게 되었다. 매번 개발 웨비나나 컨퍼런스에 청중으로 참여할 때면 나도 언젠가는 연사로 참여할 날을 꿈꿔왔는데 생각보다,, 빨리 기회가 찾아와서 기대나 설렘보다 잘할 수 있을까 걱정이 앞섰다...😔

 

---

☀️ Introduction

발표 주제는 ICT 멘토링 참여자들을 대상으로 '우리 팀이 Gitlab으로 협업하는 방식'에 대해 발표를 했다. 약 15분간 진행한 발표였지만 2-300명을 대상으로 진행하는 발표다 보니 보다 완벽하게 준비해야할 필요가 있었고 예상 질문이 들어올 만한 것들을 미리 준비했다.

 

---

💎 Content

발표 내용을 구성하는 데에 있어서, 첫 번째 세션의 연사님과 간략하게 발표 내용에 대해 상의를 했는데, ICT 멘토링에 참여하는 멘티들의 GitLab 사용률이 낮으니, 팀에서 사용하고 있는 GitLab의 기술에 대해 발표할 때 말해주면 좋을 것 같다고 하셨다.

이와 관련해서 우리 팀의 협업 플로우를 큰 발표 주제로 잡고 내용을 구성했다.

1. Git을 이용한 협업
2. GitLab에서 사용 중인 기능들
3. GitLab 사용의 이점

위 순서로 발표를 준비했다.

 

발표 자료 초안 구성

• 🗣 : 발표 중 말로만 설명할 내용

1. 우리팀 소개

• 공개미
  • 언택트 기반의 온라인 스터디 서비스
  • 팀원 구성
    • 🗣 백엔드와 인프라 관리를 맡고 있음
• 스택 아키텍쳐
  • 새로 만들기!!
  • 🗣 프론트 백 ai 묶어서 node.js 런타임 환경
  • “우선 저희팀의 기술 스택으로는 이러한 기술들을 사용하고 있으며 모두 node.js 기반으로 개발하고 있습니다.”
• 레포지토리는 개발용과 배포용 두개를 운영하고 있으며 기존의 Gitflow 방식에서 develop 전에 세 개의 브랜치를 추가한 형태
  • Gitflow 방식 간략하게 소개
  • 보통은 레포지토리를 각 개발 포지션 별로 나눠야하는 게 맞지만 우리팀은 각 포지션당 개발자가 한 명이므로 레포지토리를 하나로 합쳤다.
  • 절대 이게 바람직한 게 아니다!
  • 그냥 우리 팀만의 작업을 편하게 하기위한 특수한 작업 프로세스임을 말하기!

2. 우리팀이 깃랩에서 사용하고 있는 기능들

• 위키, 레포지토리, piplines
• 깃랩을 사용하는 이유
  • 처음에는 그냥 깃랩 활용 여부가 한이음 공모전 평가 기준에 적용 된다고 해서 적용,,!
    • But 팀원 모두가 생소한.. 깃랩..!
    • 간단하게 작업은 깃허브로 진행하고 깃랩으로 작업 이력 반영의 자동화를 구현했다!
• 작업 flow 다이어그램으로 만들기
  • 레포 2, 깃헙 액션즈, 파이프라인 포함
• 그러면 깃랩이 뭐가 좋은가 🆚 github actions
  • 시각화가 잘되어 있다.
  • 깃랩 러너를 원하는 서버에 설치만 하면 CI/CD를 손쉽게 할 수 있다.
  • CI/CD 에디터로 바로 수정하고 파이프라인을 돌려볼 수 있다.
  • job 단위로 직관적으로 보고 작업 다시 돌리기가 가능하다.

 

발표 자료 초안은 이런 식으로 구성했고 발표 자료임을 감안해서 최대한 텍스트는 적게해서 자료를 제작했고 발표 시간을 조절을 위해 설명이 필요한 부분을 추가했다.

 

<🙋 발표 자료 슬라이드>

[0922_ICT 멘토링] 우리 팀이 GitLab으로 협업하는 방

 

발표 스크립트는 완전한 대본 형태보다는 위의 초안처럼 러프하게 어떤 내용들을 해당 슬라이드에서 말할 건지 정리했고 최대한 자연스럽게 전달하려고 노력했다. 우선 우리 팀의 경우 되게 복잡한 방법으로 협업을 진행하고 있어서 이 프로세스를 포인트로 해서 내용을 전달하고자 했다.

 

---

✨ Impression

온라인으로 진행해서 많이 안 떨릴 거라고 생각했지만,, 오히려 더 많은 사람이 내 발표를 보고 있다고 생각하니까 엄청 나게 떨렸다,,,😂 그리고 우리 팀의 작업 프로세스가 되게 특이하다보니 이에 대한 질문이 주를 이뤘고 내가 할 수 있는 최대한으로 답했다.

그 중 웨비나에서 받았던 몇 가지 질문들을 기록해봤다.😆

 

QnA

Q1. GitHub Actions로 GitLab에 업로드하는 과정을 거치는 데, 어떻게 적용했는가?

• GitLab 리포지토리의 url, token, username 등 시크릿 키들은 따로 GitHub Actions의 리포지토리 설정에서 환경 변수 설정을 해줬고 계층적으로 job들이 이뤄지게끔 'push 발생' -> '리포지토리 연결 ' -> '강제 푸쉬'의 과정으로 GitLab 리포지토리와 GitHub 리포지토리가 동기화 되게끔 해주었다.

 

Q2. GitLab의 CI/CD 파이프라인을 위한 yml 파일 작성 방법이나 작성에 도움이 되는 레퍼런스가 있는가?

• 한이음 측에서 주최한 핸즈온 교육에서 익혔고 부족한 부분이나 키워드 설명들은 주로 공식 도큐먼트를 보고 참고했습니다. 주로 job을 간단하게 구성하시려면 제가 작성한 파일처럼 작성해주시면 되고 (발표 자료) CI/CD 탭의 에디터에서 yml 파일 추가를 누르면 이렇게 개발 환경 별로 처음에 시작할 수 있게 GitLab 자체에서 템플릿을 제공한다.

 

Q3. 프로젝트 진행 중 어려움은 없었나?

• 이건 GitHub과 GitLab의 파일 용량 차이때문에,,, 삽질했던 기록을 프로젝트 페이지에 회고록을 작성해둬서 회고록을 참고해서 설명을 해드렸다. 추가로,, GitHub와 GitLab 리포지토리의 용량이 차이가 있으니까 작업하면서 이 점을 유의하면서 작업해달라는 설명을 덧붙여서 답했다.

 

• 관련 포스팅!
  • [BE/Git] Git push 파일 용량 초과 문제 해결하기

 

Q4. 팀원별로 개인 작업 후 메인 리포지토리에 머지하는 과정을 거친다고 했는데, 메인 리포지토리로 머지하는 일정한 기간이나 기준이 있는가?

• 정해진 기간은 없고 주로 1주 정도의 텀을 두고 배포를 진행하는 것 같다. 프로젝트 시작 전에 세운 마일스톤에 해당 하는 굵직한 기능을 완성했을 때 메인 브랜치로 병합하고 배포를 진행한다. 또는 배포 서버에서 기능이 잘 돌아가는 지 확인해야할 필요가 있을 때 배포를 진행한다.

 

Q5. 각 포지션 별로 팀 원 각각이 기술적 이해도가 다를 것 같은 데, 코드 리뷰를 할 때는 어떤 식으로 하는 가?

• 간단하게 회의 때 어떤 기능을 완성했는지, 간략하게 설명을 하고 PR을 올릴 때 더 자세한 설명이 필요한 부분에 대해서는 변경사항에 해당하는 코드 스니펫에 코멘트를 달아서 설명을 추가하는 편이다.

 

기술적인 질문이 있을 까봐 dind 방식이나 yml 파일의 키워드들에 대한 설명을 따로 적어두고 관련 질문이 들어오면 이걸 보고 답해야겠다고 생각했지만.. 기술 관련 질문은 안들어왔고 협업 방식이나 프로젝트 관련 질문들이 들어왔다.

비록 프로젝트 진행에 대한 경험을 공유하는 시간이었지만 웨비나에서 연사로 나선 게 처음이어서 엄청 설레고 떨렸었다. 다음 번에 이런 기회가 또 있으면 참여하고 싶다😃