나는 어떻게 개발 공부를 했나, 2편

이 글은 제가 지난 1년 6개월 간의 개발에 몰두했던 경험에 대한 회고글 중 두번째 글입니다.

2편, 보다 실질적이고 구체적인 이야기(가 되길 바라며)

지난 글에서는 아름다운 이상향에 대한 이야기를 하다보니 그저 그런 글이 되버리고 말았습니다. 이번 편에서는 다소 편협한 시각의 글이 될지라도 보다 실질적인 이야기를 해보고자 합니다.

  1. 배출의 경험
  2. Git과 Github
  3. Daily commit or Today I Learned
  4. Clone Coding

0. 배출의 경험이 중요하다.

대부분의 사람들은 “습득”에 매우 익숙해져 있습니다. 초등학교 6년, 중학교 3년, 고등학교 3년 동안 그저 수업을 듣기만 해왔으니 이것은 당연합니다. 하지만 “배출”에는 익숙하지 않습니다. 자신이 학습한 내용을 공유하거나 가르쳐본 경험을 할 기회가 그리 많지 않았습니다. 저는 습득한 내용에 대해서 배출하는 경험이 중요하고 생각합니다. 습득하여 머리 속에 있는 내용물들을 배출해보면 무엇이 맞고 무엇이 틀린 것인지 확인할 수 있으며 내가 지금 정말 알고 있긴 한 건지 확인할 수 있습니다.

배출의 종류

‘배출’에도 여러 가지 종류가 있습니다. 말 그대로 자신이 학습한 내용을 정리하여 공유하는 것도 한 가지 방법일 수 있습니다. (정리하는 것도 어려운데 공유까지…) 또한 자신이 학습한 내용을 토대로 프로젝트를 기획하여 직접 코드를 작성하는 것도 일종의 배출입니다.

이번 글에서는 이 배출에 대해서 이야기를 해보려고 합니다.

그럼, 기술 들어갑니다.

1. Git과 GitHub을 우선적으로 공부한다.

가깝고도 먼 Git과 GitHub처음에 Git은 정말 어렵습니다. 하지만 정말 필수적인 녀석이니 꼭 숙달하면 좋겠습니다. 학습을 위한 좋은 자료는 정말 많습니다. 배우고자하는 의지만 있다면 얼마든지 익힐 수 있습니다. GitHub이 배출하는데 있어 “어디에”라는 이슈와 “누구한테”라는 이슈를 해결줄 수 있습니다. GitHub에 정리한 내용을 올리면 누군가는 보게 됩니다. (이제 공부만 하면 되네요.) 한 가지 짚고 가자면, Git과 GitHub을 혼동하지 마세요. 정말 아쉽게도 Git과 GitHub을 혼동하는 경우를 너무 많이 보았습니다. 물론 서로 밀접한 관련이 있는 것은 사실이지만, 다른건 다른거니까요. 이 두 가지에 대해서 익숙해지시면 앞으로 개발하는데 있어서는 물론이고 여러 면에서 정말 좋습니다. GitHub을 어느 정도 이해하셨으면 이제 본격적으로 들어갑니다.

1–1. 일단 Create Repository

만약 프로젝트를 하게 되면 일단 GitHub에 repository(public)를 만들고 시작합니다. 그리고 작성되는 코드들을 모두 commit 해준 다음에 GitHub에 push 해줍니다. 벌써 배출을 했습니다. 코드를 공유한거나 다름없습니다.

1–2. 필요없는 건 필요없어요.

개발할 때만 필요한, 나한테만 필요한, 공유할 필요가 없는, 그런 것이 있습니다. 그런 건 Repository에 포함시키지 말아야 합니다. 다른 사람이 봤을 때, Git과 GitHub에 대한 이해는 물론 프로그래밍 전반에 대해 이해도가 떨어지는 사람이라고 보이기 쉽습니다.

.gitignore를 적극적으로 활용하여 필요없는 파일은 제외한 뒤 push 해줍니다. gitignore.io(https://www.gitignore.io/)라는 친절한 사이트도 있습니다. 적극적으로 사용하여 필요없는 파일을 제외해줍시다.

1–3. 의미없는 커밋 메세지는 의미없다.

  • 잘 나가는 오픈소스 프로젝트의 Commit message rule을 따라서
  • 영어로
  • 프로젝트의 처음부터 끝까지 일관성 있게
  • husky라는 도구를 사용하면서

커밋 메시지를 작성하는건 바라지 않습니다. 그저 temp, s, t, … 등 아무 의미 없는 커밋메세지만 아니면 됩니다. 한글로 작성하더라도 의미있는 커밋 메세지를 남기는 습관을 들인다면 좋을 것입니다.

1–4. GitHub을 잘 활용해봅시다.

GitHub은 다음과 같이 훌륭한 것들을 기본적으로 제공해줍니다

README.md

자신의 프로젝트를 잘 설명하기 위해서는 README.md 만한게 없습니다. (어서 마크다운 문법에 익숙해지도록 합시다.)

Issue, labels

프로젝트를 진행하면서 앞으로 해야할 일들을 Issue로 등록해보는건 어떨까요?

Pull Request

무조건 master branch로 push하지 말고 다른 branch로 체크 아웃하여 작업을 한 뒤 PR을 보내는 방식으로 진행해보는 것은 어떨까요? 한 발 더 나아가 코드 리뷰를 진행한다면 금상첨화일 것입니다.

Wiki

팀 프로젝트에서 공유해야 하는 내용이 있다면 Wiki를 활용해도 좋을 것 같습니다. 이것들을 잘 활용하면 보다 체계가 잡힌 repository를 구성할 수 있습니다. 이외에도 GitHub을 잘 활용하면 보다 재밌는 프로젝트를 진행할 수 있습니다 :)

2. Daily commit or Today I Learned

일일커밋(daily commit)이라고 한 번 쯤은 들어보셨을 겁니다. TIL도 한 번 쯤은 들어보셨을 거구요.

구글에 ‘일일 커밋’이라고 검색만 해도 관련된 여러 글이 검색됩니다. 그런데 왜 이 지겨운 이야기를 또 할까요?

제 얘기를 먼저 해보겠습니다.

저는 개발 공부를 시작하면서 블로그를 시작했습니다. 블로그를 하면서 1일 1포스팅을 했었는데요, 정말 많은 도움이 되었습니다. 그만큼 학습한 내용에 대해서 정리하고 배출해보는 경험이 중요합니다.

하지만 블로그에 1일 1포스팅하는 것보다 TIL이 접근성 면에서 더 좋다고 생각합니다. 일단 부담스럽지 않고, 블로그를 개설한다는 어마어마한 장벽이 존재하지 않습니다. (다만 git에 대한 이해가 선행되야 합니다.)

TIL의 좋은 예시로 두 블로그를 소개합니다.

자주 받는 질문 두 가지가 있습니다.

“제가 올린 내용이 틀리면 어떡하죠?”

틀리면 뭐 어떤가요? 틀려도 됩니다. 다만 잘못된 정보를 공유하지 않기 위해 많이 노력해야 합니다. 이 경우, 가장 좋은 Case는 제대로 알고 있는 사람이 와서 댓글을 달아주는 겁니다. (그거 아니고 이거예요! 이렇게 말이죠)

그런데 사실, 처음 블로그 또는 TIL을 시작하게 되면 페이스북 그룹에 공유하지 않는 이상 아무도 보지 않습니다. 혹시 자신이 열심히 TIL을 작성했는데 공유하고 싶다면 저에게 알려주세요. 제 페이스북 페이지에 소개해드리겠습니다! :)

“블로그는 하고 싶은데 쓸 게 없어요ㅜㅜ”

우리는 모두 코딩하다가 막히고, 검색을 합니다. 대부분의 경우 하나의 검색 결과로 해결되지 않습니다. 처음 본 A라는 블로그의 내용이 부족했기 때문입니다. 그래서 B도 보고 C도 봅니다. 해결했습니다. 그리고 바로 넘어갑니다.

잠깐!여기서 부터 시작해보세요. 어떠한 상황에서 문제를 만났고, 여러 블로그에서 취합한 정보를 정리하여 문제 해결 방법을 제시하는 것부터 시작하면 됩니다. 처음부터 대단한 Tutorial을 작성하는 것만이 블로그하는 것이 아닙니다. 바로 거기서 부터 시작하시면 됩니다 :)

3. 클론 코딩

말 그대로 그대로 코딩해보는 겁니다. 물론 코드는 보지 않고 외관 모습만 보고 만들어봅니다. 저도 처음에는 디자인이 잘 된 여러 페이지들을 따라 만들면서 HTML/CSS를 공부했던 기억이 있습니다. 우리에게는 개발자 도구라는 엄청난 친구가 있어서 많은 도움을 받을 수 있기도 합니다.

클론 코딩하기에 가장 좋은 녀석으로는 TodoMVC가 있습니다. 정말 많은 version으로 만들어져 있기 때문에 참고하며 진행하기 좋습니다.

평소에 자주 사용하는 서비스를 만들어 볼 수도 있고 서비스를 이용하다가 마음에 드는 인터랙션을 발견했을 때 기록해두었다가 그것을 그대로 만들어보셔도 됩니다.

소스 코드가 엉망인 것은 신경쓰지 말고 일단 따라 만들어보는 겁니다. 물론 이 클론 코딩하며 연습한 소스 코드도 GitHub에 push해줍니다. 자신만의 서비스를 만들어 보는 것도 좋지만 기획부터 디자인까지 하다가 정작 개발에는 많이 신경 못쓰는 경우를 보았는데요, 개발 실력을 기르기 위해서는 클론 코딩을 추천드려봅니다.

마무리

실질적인 이야기가 되기를 바랬지만 이번에는 두서없는 이야기가 된 것 같습니다. 개발을 시작하는 분들께 조금이나마 도움이 되었으면 좋겠습니다 😃 그럼, 자세한 이야기는 만나서 합시다!(ㅋㅋ)

감사합니다.


Written by@Jbee
Web Engineer Interested in 설계.테스트.생산성.자동화.멘토링. FEConf Organizer @FEDG

GitHubTwitterFacebook