git branch 전략 그게 뭔가요...? Git flow 탐구하기

서론

안녕하세요, 저는 IT 협업 동아리 PARD에서 iOS파트 4기로 활동하고 있는 이유현이라고 합니다.

지난 2기, 3기를 웹 파트로서 PARD를 참여하며 이번 4기에도 IOS라는 새로운 파트에 도전하게 되면서 벌써 3주간 기획,디자인, 개발이 모여 프로젝트를 만드는 롱커톤을 앞두게 되었습니다. 

롱커톤을 앞두고 개발자들끼리 협업을 어떻게 해야할지 정말 고민이 많으실텐데요, 저도 지난 롱커톤을 겪어오면서 개발자들끼리의(특히 프론트는 3명이라 더더욱) 협업이 무척 중요하다는 것을 느낄 수 있었습니다.

그래서 이번에 개발자들끼리의 협업할 때 도움이 되는 git branch 전략에 대해 알려드리고 합니다! (또 마침 제가 지난 3기 때 쓰려고 정리해둔 git flow에 대한 정리가 있더라구요 ㅎㅎ)

본론

지금 소개드리는 방식은 git branch 전략으로 유명한 git flow입니다.

Git flow란 5가지 종류의 브랜치가 존재합니다.

• main 브랜치에서 병합하던 것을 develop 브랜치에서 대신 작업한다고 생각하시면 됩니다

• main은 뭐 하느냐? 배포할 때 보여지는 최종 결과물입니다

git flow 사용하기

git flow를 사용하는 두 가지 방법에 대해 설명해드리겠습니다!

첫 번째는 별 다른 설치없이 git 명령어로만 하는 경우

두 번째는 git flow를 지원해주는 도구를 설치해 사용하는 경우 입니다

1. git flow(설치X)

1. main과 develop 브랜치를 만든다. 
		→ 원격저장소와 연결한다
2. 레파지토리에서 develop 브랜치를 default로 만든다. 
		(레파지토리 → settings → General → Default branch 변경 )
3. 각자 로컬에서 feature/(기능요약) 브랜치 만들기 
		→ `git switch -c feature/login develop` 
		: develop 브랜치를 참고하여 만들고 만든 브랜치로 바로 이동
		: develop 브랜치에서 브랜치를 생성한다면 develop을 적을 필요는 없음
4. 작업 후 깃 커밋
5. `git push origin feature/login` 
		→ 원격저장소에 브랜치 추가하고 pr 까지 날림
6. 레포 들어가서 pr 작성
7. 다른 사람이 pr 날렸을 때 
		→ `git switch develop`  → `git pull` 
		7-1. 내 브랜치에 머지하고 싶을 때 -> (내 작업 브랜치에서)'git merge develop'
8. `git branch -d feature/get` 
		→ 작업 다한 로컬 브랜치 삭제, 
		`git push origin --delete feature/login` 
		→ 작업 다한 원격 브랜치 삭제(동일 브랜치임)
9. !!!3번부터!!! 다시 반복

2. git flow(설치 O)

• git flow 도구 사이트

• MacOS 기준

  1.`$ port install git-flow-avh` 혹은 '$ brew install git-flow-avh'
  2. 깃으로 관리하고 있는 경로에 `git flow init`
  
  3-1. 새기능 시작하기
  			deveop 브랜치에서 `git flow feature start (기능요약)`
  				-> 이런식으로 하면 feature/(기능요약) 브랜치가 만들어짐
  				-> 자동으로 해당 기능 브랜치로 전환됨
  3-2. 기능 완료
  			`git flow feature finish (기능요약)` 
  			-> 해당 기능 브랜치를 develop 브랜치에 머지함
  			-> 기능 브랜치를 삭제함
  			-> develop 브랜치로 전환됨
  **기능을 공동으로 만들고 있을 경우
  	**1. 기능을 게시
  			`git flow feature publish (기능요약)`
  			-> 내 로컬에 있는 기능을 원격저장소에 게시
  	**2. 원격저장소에 게시된 기능을 가져오기
  			`git flow feature pull origin (기능요약)`
  4-1. release 시작
  		develop 브랜치에서 `git flow release start RELEASE [BASE]`
  		-> release 브랜치 생성
  		-> [BASE]에 release할 커밋 해시를 넣을 수도 있음
  4-2. release 허용
  		'git fow release publish RELEASE'
  		-> 다른 개발자들의 release commit을 허용하는 것
  		-> 'git flow release track RELEASE' 원격 'release' 브랜치 변경 추적
  4-3. release 완료
  		'git flow release finish RELEASE'
  		-> 'release'브랜치를 'master' 브랜치에 병합
  		-> 릴리스를 릴리스 이름의 태그
  		-> 릴리스를 'develop' 브랜치로 재병합 
  		-> 'release' 브랜치 삭제
  		* 'git push --tags'를 사용해 태그들을 push해야함!
  

결론

사실 저는 git flow 도구보다 git 명령어로 하는게 더 익숙해 2번 보다는 1번을 더 많이 사용하긴 합니다ㅎㅎ

그렇지만, 여러분들은 팀원들과 상의해보면서 더 좋은 방법을 찾길 바랍니다.

또한, 개발자들 간의 협업을 처음 경험하는 분들도 있으실텐데 부디 도움이 되길 바라며, 적절한 브랜치 전략과 컨벤션으로 좋은 협업을 이루시길 바라겠습니다. 감사합니다!

[숏커톤 후기]개발 리더 누구에용? 저요? 저에요? 저라구요?

안녕하세요, 저는 IT 협업 동아리 PARD의 웹파트 파도 이유현입니다.

저는 지난 금요일 PARD에서 진행하는 18시간 무박 2일 해커톤(숏커톤)을 경험하고 왔는데요, 그때의 기억이 휘발되기 전에 얼른 기록하려 합니다.  

1. 개발 리더 누구에용? 저요? 저에요? 저라구요??

나에겐 너무 무거운 개발 리더라는 이름...

시작부터 떨리고 떨리고 떨렸던 숏커톤이 무사히 막을 내렸습니다. 조금 스포일러하자면 저희 팀이 1등을 해서 말이죠ㅎㅎ(숏커톤 한번 해봤다고 긴장이 안 되는건 아닌 것 같아요)

사실 이번 숏커톤은 더욱 긴장이 될 수 밖에 없었는데요, 앞에 잠깐 말했지만 제가.. 부족한 제가 개발 리더?? 라는 역할을 하게 된 덕분이었습니다. 저는 지난 파드2기에서 웹파트 파디였으며, 현재 파드3기 웹파트 파도로서 아무래도 처음 리액트를 배우고 웹개발을 해보는 파디들에 비해 파드2기를 경험한 제가 당연히 그 역할을 맡을 수밖에 없었다고 생각합니다. 실제 실력과는 별개로요. 저는 제 실력에 대해 부족한 점이 많다는 것을 잘 알기에, 어쩔 수 없는 것과 별개로 제가 개발리더를 하기에는 부족하다고 생각했습니다. 

2기 때는 숏커톤 내내 아무것도 모른채 ‘이거.. 어떻게 하지..’ ‘충돌해결해줘요...’ ‘css 한 페이지도 힘든데 이게 맞아??’ 라는 생각이 머리 속에 가득 차있던 사람이 그당시 제가 의지하던 개발 리더의 역할을 해야한다는 사실에 너무 부담이 되었기도 하구요.

그러나, 부족한 제가 팀원들과 함께 1위라는 결과를 만들 수 있었던 건, 저의 리더로서 부족한 부분을 계속 채워주며 서로를 지탱해준 웹파트 팀원들인 채은이, 민규오빠. 기획으로서 열심히 아이디어내주고, 진행해주면서, 틈틈히 상황 조율하며 팀을 이끌었던 예람언니, 시우님. 보자마자 만족스러운 디자인을 빠른 시간 안에 줬던 규희언니. 서버 연결로 서비스의 완성도를 높여준 준현님과 기영님 덕분이라고 생각합니다.

그리고.. 저의 준비성 덕 약간 아닐까요?ㅎㅎ
제 얘기로도, 팀원들 얘기로도 할 얘기가 너무 많은 거 같아요.

2. 숏커톤 시작 전, 긴장이 되면 준비를 하자

숏커톤을 앞두고 제가 개발리더로서 역할을 잘 할 수 있을까? 팀원들에게 피해를 끼치는 것을 아닐까? 하는 생각들에 잔뜩 긴장한 상황이었습니다. 그런데 그렇다고 마냥 바들바들 떨며 숏커톤을 기다릴 수 없는 노릇이니 ‘그럼 내가 숏커톤을 위해 준비할 수 있는 건 준비해가자’ 라고 생각했던 것 같아요.

기본적으로 폴더를 만들어서 리액트를 설치하고, 각종 라이브러리를 설치하는 등 다 준비한 상태에서 바로 개발에 들어갈 수 있도록 노션에 순서를 정리해놓거나, 커밋 컨벤션을 정한다던가, pull request를 사용해서 pull,push를 진행한다던가 웹파트 내에서 개발을 할때 어느정도 준비와 방향성을 많이 고민해서 갔던 것 같습니다.

그리고 숏커톤 당일날, 아무리 생각해도 단순히 개발 세팅 순서를 정하기보다 그냥 프로젝트를 위한 폴더를 미리 만들어놓고 숏커톤을 하는게 나은 것 같아 후다닥 폴더를 만들고 리액트를 설치하기 시작했습니다. 

그리고 만난 에러.

?

??

?????

리액트를 설치하던 도중 지피티 선생님의 말씀으로는 npm 캐시가 충돌이 나서 설치 에러가 났다는데 .. 다 모르겠고 진짜 긴장됐어요. 곧 숏커톤을 하러 버스타러 가야하는데 뭐지? 왜지? 노트북 못쓰나? 개발 못 하나? 나 개발리던데? 라는 불안감이 엄습하기 시작했습니다. 사실 지피티 선생님 말씀만 잘 따라가면 금방 해결할 수 있던 거였는데 말이죠. 곧 숏커톤인데 생각지도 못한 에러에 당황해버렸어요. 해결한 후에 생각했죠. 미리 에러를 발견할 수 있어서 진짜 다행이라고. 그때도 당황했는데, 정신없는 숏커톤 시간이었다면 진짜 너무 떨었을 것 같아요. 

그리고 깃허브 레파지토리에 올리는 과정에서 상위 폴더와 연결하는데 상위폴더와 하위폴더에 git이 있어서 git끼리 충돌이 나는지 제대로 안 올려지더라구요. (저만 몰랐나요? 하위폴더에 rm -rf .git을 하시면 하위폴더에 깃이 지워져서 상위폴더가 깃으로 관리한 상태로 잘 올라가 집니다)

우여곡절 끝에 개발 세팅을 끝나고 저희는 디자인이 나오면 바로 개발에 들어갈 수 있게 되어 약간의 시간절약, 심리적으로 편안함을 느낄 수 있었던 것 같습니다. 미리미리 준비하는 습관이 긴장감을 줄이는 것에도, 시간을 절약하는 것에도 매우 도움이 된다는 것을 실감한 순간이었습니다.

3. 숏커톤, Keep, Problem, Try

숏커톤을 진행하면서 스스로 잘한 점과 부족한 점을 깨달을 수 있었습니다.

Keep

1.    개발 환경과 pull-push 방식(Pull Request)를 미리 준비해간 것

2.    우선순위를 정해 개발하고, 우리의 우선순위를 디자인 파트에 전달하여 중요한 페이지부터 받은 것

3.    기획과 계속 소통하며 시간상 구현이 어려울 것 같은 서브 기능들을 제외하여 최소기능에 집중한 것

1)    미리 개발환경을 세팅해 간 덕분에 정신없는 상황에서 바로 개발에 들어갈 수 있어 집중도도 높아지고, 시간도 아낄 수 있었습니다.

2)    또한, PR로 pull, push를 한 덕분인지 코드 충돌로 인한 문제가 크게 생기지 않아 충돌을 해결하느라 쓰는 시간을 아낄 수 있었습니다.

3)    사실 개발 내내 우선순위에 집중하여 우리가 생각하는 최소기능이 무엇인지 디자인 파트와 기획 파트에게 계속해서 전달하여 시간 안에 최소기능을 완성시킬 수 있었습니다.

Problem

1.    예민한 기분을 숨기지 못한 것.

2.    서버에게 우리가 생각한 우선순위를 제대로 전달하지 못한 것

3.    커밋 컨벤션을 제대로 지키지 못한 것

1)    변명을 하자면.. 개발리더로서 최소기능만큼은 무조건 시간 안에 완성해야한다는 강박과 점점 줄어드는 시간에 초조해져, 팀원이 제게 질문하였을 때 ‘알아서 해’ 라고 말했던 적이 있습니다. 그 말을 내뱉고 5초 정도 멍때리다가 내가 지금 무슨 소리를 한거지? 하고 다시 무슨 일이냐고 물어보긴 했지만, 개발리더로서 그런 말을 한 스스로에 대해 매우 실망스러움을 느끼게 되었습니다. 숏커톤 내내 모르는 것에 있어서 질문을 열심히 해주는 팀원들에 대해서 혼자 끙끙 앓지 않고 공유해준 것에 감사한 생각을 가지고 있었으면서, 예민한 기분을 내보이며 팀원들의 질문을 막는 태도를 보인 스스로의 모순에 반성하게 되었습니다.(잘못했어요. 질문 멈추지 마세요, 제발)

2)    개발을 하면서 우선순위를 다른 파트에게 전달했다고 했는데, 서버 파트에는 말하지 못했던 것 같습니다. 저는 회원 가입 페이지가 당연히 우선순위에서 밀려있고, 중요한 것은 따로 있었는데 어느순간 서버 파트에서 하는 말을 들어보니 회원정보에 대한 개발을 하고 있던 것 같더라구요. 제가 생각하기에는 회원가입까지 만들지 못할 수도 있는데, 서버분들이 회원정보와 관련된 개발을 하고계신 걸 뒤늦게 눈치채 당황스러웠습니다. 사실 그때는 제가 백엔드에 대한 지식이 없으니 서버에서 회원정보를 만드는 게 무조건 필요한 부분인가 싶기도 하고, 열심히 하고 계신데 그거 필요없어요.. 라고 하는게 망설여져 미처 말하지 못했습니다. 사실, 어떤 상황이든 서버와 소통을 했다면 개발 시간을 아끼거나 제가 백엔드에 대한 지식을 더 얻게되거나 했을텐데 그러지 못한 점이 아쉬웠습니다.

3)    커밋컨벤션에 관해서는 제가 먼저 하자고 했는데, 시간이 촉박해지다보니 커밋 메시지를 적는 시간도 아까워져 후반에는 대충 적었던 것 같습니다.

Try

1.    팀원들이 적극적으로 질문할 수 있도록 칭찬하고 장려하기

2.    미흡한 협업 태도, 회고를 보면서 반성하고 되내이기

3.    서버와 지금 어떤 일을 하고 있는지 틈틈이 상황 공유하기

4.    커밋 컨벤션에 더욱 신경써서 커밋 메시지 작성하기

4. 함께한 팀원들에게 해주고 싶은 말

저희 웹파트 팀원들. 부족한 저에게 너무 든든한 사람들이라는 말을 꼭 해주고 싶었습니다. 모두 숏커톤이 처음이고 정신없을텐데 제가 부탁한 일들을 잘 해주다 못해, 저의 부족한 부분까지 채워주었던 최고의 팀원이었다고 생각합니다. 

먼저, 민규 오빠는 억울한 윈도우 이슈로(css로 작업할때 원도우와 맥에서 보이는 화면이 다르거나 깨지는 상황) 오랜 시간동안 그걸 해결하느라 많이 힘들고 지쳤을 텐데 포기하지 않고 계속 방법을 찾고 상황을 공유해줬던 게 정말 대단하다고 느껴졌습니다. 또한, 정신없는 저를 대신해 기획이나 디자인의 이야기를 듣고 저에게 얘기해주는 등 적극적으로 커뮤니케이션하며 중간 다리 역할을 해줬던 게 정말 든든하고 고마웠습니다. 

그리구 채은이. 부탁한 일을 척척 끝내고, 제가 계속 다음 일을 맡겨도 싫은 내색하지 않고 잘 해줘서 너무 고마웠어요. 얘한테 일을 맡기면 어떻게든 완성해서 받을 수 있겠다는 믿음이 있어서 스스로 좀 더 안정감이 생겼던 것 같아요. 그리고 제출기한이 다가오고 점점 초조해져서 약간 예민해졌던 저에 비해 항상 침착한 모습을 보여 저도 보고 조금 예민함을 가라앉힐 수 있었던 것 같아요. 또한, 저대신 잘 안되는 팀원들을 도와준 것과 모르는 부분은 바로바로 물어가며 상황 공유해준 덕분에 문제가 고이지 않고 흐를 수 있게 만들어 준 것에 정말 고마워요.

제가 개발 리더라고 하지만, 우리 웹파트 팀원들 모두 리더의 역할과 팔로워의 역할을 하며 서로의 부족함을 채워 저희가 생각한 최소기능은 완성할 수 있었다고 생각합니다.(기획파트분들은 어떻게 생각하실지 모르겠지만ㅎ...) 그리고 그 짧은 시간 안에 css 다 해보며,사실상 각자 한 페이지씩 다 만들어보고, 서버랑 연결해보고, 안 써봤던 map도 모두 한번씩 다 써봤으니 모두에게 좋은 경험이 될 수 있었다고 생각합니다.

기획파트에 대해서는 조금 미안하고 고마운 부분이 있는 거 같아요. 아무래도 시간 안에 개발을 해야된다는 생각에 기획파트분들이 제안하시는 기능들에 대해 너무 많이 거절한 것 같아 아쉬움과 미안함이 남는 것 같아요. 또한, 아이디어를 낼 때 기획 쪽에서 기능 얘기만 나오면 거절하는 뉘앙스를 보인 게 다양한 아이디어를 발산하는 것을 막지 않았나하는 미안함과 스스로의 부족함을 느끼게 된 시간이었습니다. 저희의 작고 소중한 최소기능 가지고 멋지게 발표해주시고, 그 모든 과정에서 조율하고, 소통하며 신경써주신 기획 파트분들 정말 감사드려요. 

디자인파트에 대해서도 아쉬움이 큽니다. 피그마 프로토타입 영상을 발표에서 보여주진 못해 다른 파드분들은 못 보셨겠지만, 저희 디자이너 너무 유능하고, 디자인 너무 예쁘고, 개발 시간관계상 만들지 못한 여러 페이지들이 존재했습니다. 정말 예쁘게 만들어 주셨는데 보이지 못하고 남겨둔게 너무 아쉽고, css도 피그마랑 완벽하게 맞추지 못해 아쉬운 마음이 듭니다. 근데 진짜 정말.. 최고의 디자이너. css를 하는데 재미를 느끼게 하는 디자이너였던 것 같습니다. 

서버 파트분들 정말 고생 많으셨어요. 서버 연결이 되지 않는 웹서비스가 되는 걸 피하고자 여러 고충이 있으셨겠지만 결국 서버 연결까지 무사히 해주신 서버 파트분들께 감사드려요. 중간중간에 api주소나 변수가 어떤 걸 의미하는지 물어보면 친절히 말씀해주시고, 랜덤 질문 같은 기능을 서버에서 처리해주셔서 감사합니다.. 덕분에 추가해야할 기능이 줄어들어 하고있던 일에 더 집중할 수 있었던 것 같습니다. 

각자의 자리에서 최선을 다하고, 서로 꾸준히 소통하며 맞춰가는 기영이의 Pyo류기 팀. 함께해서 정말 즐거운 숏커톤이었으며, 이 경험을 발판 삼아 더 나은 개발 리더가 될 수 있도록 노력하겠습니다.

시간이 지워진 숏커톤 후기

안녕하세요, 이번 숏커톤 때 '최애의 교수'를 제작한 유니팀에서 웹개발로 참여한 웹파트 이유현이라고 합니다. 

11월 25일에 진행됐던 숏커톤 지금이라도 한번 회고를 작성해 보려고 하는데요, 글 쓰는게 익숙하지 않다 보니 미루고 미루고.. 드디어 지금 적게 되었습니다. 다소 두서없게 작성된 글인 점 미리 말씀드립니다.

시작하기 전

숏커톤이 시작되기 불과 몇 시간 전, 솔직히 그때까지만 해도 숏커톤을 한다는 것 자체를 실감하지 못했던 것 같습니다. 웹 개발끼리 프로젝트 경험 무, 다른 파트와 프로젝트경험 무였던 저는 애초에 숏커톤이 어떤 식으로 흘러가게 될지 전혀 감을 못 잡은 상태습니다. 

몰라서 그랬던 걸까요, 숏커톤 생각보다 떨리지 않은데? 라고 생각했던 저는 숏커톤 시간이 임박하자 초조해지기 시작했던 것 같습니다. 도움이 안 되면 어떡하지? 지금이라도 뭔가 더 공부할까? 등 걱정되는 마음 반 기대 반을 안고 시작한 숏커톤이었습니다.

진행 중

기획 1명, 디자인 1명, 웹 개발 3명, 서버 1명으로 진행된 프로젝트. 처음에는 너무 순조롭게 흘러가는 듯 했습니다. 그러면 안 된다는 것도 모르고.

아이디어를 내는 시간에 다른 팀원분들이 적극적으로 아이디어를 내주셨는데요, 덕분에 피드백을 받기 전 여유롭게 저희는 아이디어를 정할 수 있었습니다. 피드백 받기까지 시간도 좀 남았고, 아이디어는 괜찮게 정해진 것 같고, 이 아이디어로 순조롭게 진행하는 줄 알았습니다.

그런데, 1차 피드백을 받게 되면서 날카롭게 아이디어의 허를 찌르는 운영진분들의 말씀에 '이거면 충분하지'라고 생각하던 아이디어에 대해서 다시 생각해 보게 되었습니다. 너무 우리 팀 내에서 나온 아이디어라 객관적이지 못하게 보고 있던게 아닌가 하는 생각이 들기 시작했습니다. '연결'이라는 주제에 제대로 매칭이 되는지나, 굳이 다른 서비스 말고 이 서비스를 써야 하는 이유가 있는지, 18시간 안에 개발이 가능한지 등 여러 피드백을 듣고 정신을 확 차리게 되었습니다. 

아무튼 그렇게 황급히 아이디어가 수정되고 새로운 아이디어로 정해지면서 개발에 들어가게 되었습니다. 사실 아이디어가 결정되고 바로 웹 개발에 들어가거나 하는 건 많이 어려웠는데요, 아무래도 아이디어 결정과 동시에 디자인을 내야 하다 보니 디자인과 개발을 동시에 할 수밖에 없는 상황이 펼쳐지게 된 것이었습니다. 이때쯤 되니 '시간이 너무 빨리 가는 거 아닌가?'라고 생각이 들었던 것 같네요.

다른 사람들과 협업하여 프로젝트를 하는 경험이 처음이다 보니, 디자인과 동시에 개발하는 상황이 굉장히 신기하기도 했고, 다른 사람들과 함께 일한다는 느낌에 즐겁기도 했었습니다. 그러나, 그런 감상도 잠시 어느 정도 와이어 프레임이 나오고 웹 파트의 사람들끼리 개발할 부분을 나누기 시작했습니다. 저는 메인 페이지와 사용자의 이름을 입력받는 페이지를 하게 되었습니다.

페이지를 구현하면서 스스로의 실력적인 부분에서 많은 어려움이 있었습니다. 사실상 css를 하는 부분이 거의 대부분이었는데 그 css마저 제 화면과 다른 팀원분들의 화면과 보이는 게 다르니, 도대체 뭐가 문제인지도 모르겠고 시간은 훌쩍 몇 시간이 지나버리고 만 것이었습니다. (결국 윈도우와 맥은 보여지는 화면 크기 비율이 다르다는 걸 알게 되어 해결되긴 했습니다) 게다가 git을 다루는 것도 익숙하지 않다 보니 '이게 왜 안되지?' 싶은 부분이 많아 다른 분들을 많이 귀찮게 했던 것 같습니다. 

빠르게 다가오는 제한 시간에 결국 어찌어찌 개발을 끝내고, 다자인 파트를 맡으신 분과 기획 파트를 맡으신 분이 열심히 발표를 준비해주셔서 발표까지 끝난 후, 그렇게 숏커톤을 마무리하게 되었습니다.

후기

18시간이라는 시간 안에 빠르게 프로젝트를 만들어야 하는 숏커톤을 경험하게 되면서 스스로의 부족함을 많이 실감했던 것 같습니다. 특히, 개발하는 시간과 개발 실력 부분에서 스스로의 위치를 제대로 확인했던 것 같습니다.

개발하는 시간은 아무래도 개발 경험이 많지 않아 배운 내용이라도 다루는 게 익숙하지 않은 탓에 시간이 오래 걸리게 된 점. 개발 실력과 관련해서는 기능을 구현하는 부분에서 도움이 되고 싶었는데, 모르는 부분은 따로 검색을 해야 했고 검색을 해서 알게 돼도 제가 개발하게 된다면 시간이 오래 걸릴 게 뻔해 기능 구현에 많은 도움을 주지 못했다는 사실이었습니다. 또한, 웹에서 개발할 부분을 나눌 때 페이지 단위로 나눠서 조금 더 효율적으로 분배하지 못했다는 점이 아쉽기도 했습니다. 

숏커톤을 통해 스스로의 실력에 대해 다시 한번 제대로 깨닫게 되면서, 앞으로 있을 롱커톤을 대비하여 진짜 열심히 공부해야겠다는 생각이 들었습니다. 실력이 부족하면 시간이라도 남들보다 더 투자할 마인드로 노력해야겠다고 다짐했습니다.

여기까지가 제가 숏커톤을 통해 느낀 저의 부족한 부분이었고, 그것 말고도 18시간이라는 짧은 시간 안에 다른 파트들과 협력하여 프로젝트를 만들어 가는 과정이 무척 새롭기도 했고, 즐거웠습니다. 한 공간에 모여 아이디어를 주고받고, 각자 자신이 맡은 일에 전문적으로 참여하는 모습들을 보니 대단해 보이기도 했고, 저도 열심히 해야겠다는 동기부여를 받기도 했던 것 같습니다. 우여곡절이 많고 스스로의 실력을 통감하게 된 숏커톤이었지만, 팀원분들과 함께 프로젝트를 제작할 수 있어서 즐거웠던 경험이었습니다. 

새로운 시작, 파드_설레는 마음으로!

인삿말

안녕하세요! 저는 파드 2기 웹파트로 참여하게 된 21학번 이유현이라고 합니다. 고대하던 파드에 들어와 여러분들과 함께 협업을 해나갈 수 있다는 사실이 꿈만 같습니다ㅎㅎ 스스로 배워야 할 부분과 성장해 나가야 할 부분이 많다는 것을 실감하지만, 파드에 들어온 이상! 파드의 들어오기 전의 저보다 훨씬 성장한 사람이 되기 위해 노력하려고 합니다!! 

협업이란?

제가 생각하는 협업이란 “함께 성장해나가는 것”이라고 생각합니다. 사회를 이루고 살아가는 인간인 이상 다른 사람과의 팀플레이를 빼놓을 수 없는데요, 협업을 하기 위해서는 단순히 함께 '일하는 것'을 넘어 함께 '성장'해나가야 한다고 생각합니다. 저는 함께 성장하기 위해서는 타인을 통해 자신의 부족한 점을 깨닫게 되고, 다른 사람의 부족한 부분을 도와 성장할 수 있도록 도와야 한다고 생각합니다. 그러기 위해서는 각자 자기일만 하는 것이 아니라 서로 대화하고 교류하면서 상대에 대해 알고 이해하기 위해 노력해야 한다고 생각합니다!

OT후기

기다리고 기다리던 합격 통지를 받고 난 후 얼떨떨한 상태에서 내가 진짜 파드에 합격했다고? 하는 상태로 한 주를 보내고 제게 성큼 다가온 파드 OT 날!!! 일찍 장소에 도착해 분주하게 준비하시는 운영팀 분들을 보며 '와... 나 파드 합격했구나. 앞으로 많은 걸 배우게 되겠지?'하며 파드에 들어왔다는 사실을 새삼 실감했던 것 같습니다.

특히, 기억 남던 건 현재 나의 상태와 파드를 끝낸 후 내가 성취했을 것 같은 것에 대해 작성해 보는 시간이었습니다. 현재 나의 상태를 천천히 적는데, 스스로의 현재 상태를 천천히 생각해 볼 수 있는 기회였어서 좋았던 것 같아요. 성취했을 것 같은 것들이 정말 이뤄질까? 싶은 마음 반 이뤄졌으면 좋겠다는 마음 반으로 적긴 했지만, 다 적고 보니 확실한 목표가 생긴 것 같아 의욕이 샘솟는 느낌이었습니다!

맺음말

드디어 시작된 파드, 어디 가서 쉽게 찾을 수 없는 협업을 배우는 기회가 손에 떨어졌으니 이 기회를 허무하게 날려버리지 않도록 열심히 노력하겠습니다. 그리고, 협업을 배우는 만큼 함께 하는 모든 파드분들과 친해질 수 있었으면 좋겠습니다! 함께 멋진 협업을 해나가도록 해요! 감사합니다ㅎㅎ