<div id="readability-page-1" class="page"><div><figure width="100%" data-origin-width="419" data-origin-height="346" data-ke-mobilestyle="widthContent"><span data-url="https://blog.kakaocdn.net/dn/leHNC/btq3UTRbBtr/U1Yvsciy20lwAKu8mk8rU0/img.png" data-lightbox="lightbox" data-alt=""><img src="https://blog.kakaocdn.net/dn/leHNC/btq3UTRbBtr/U1Yvsciy20lwAKu8mk8rU0/img.png" width="100%" data-origin-width="419" data-origin-height="346" data-ke-mobilestyle="widthContent"></span></figure>
<blockquote>
<p>이 글은 의식의 흐름대로 씁니다.. 참고해주세요.<br>또한, 이 글은 개인적인 회고도 담겨있기 때문에 원하시는 정보가 없을 수도 있습니다.</p>
</blockquote>
<h2>🤔 이 글을 쓰는 이유?</h2>
<ul>
<li>별 이유는 없지만 두 가지 정도가 있다.</li>
</ul>
<h4>🎈 첫 번째 이유</h4>
<p>가장 큰 이유는 1년 동안 무엇을 했고 얼마나 성장했는지에 대해서 자기 회고를 하고 싶어졌다.<br>사실 제대로 된 프론트앤드 개발은 1Day 1Commit을 같이 시작한 1년 전이기 때문에 같이 회고하는 겸 써도 괜찮을 거 같았다.<br>또한, 그로 인해서 자기회고도 할 수 있을 거라 믿고 있다.</p>
<h4>🎈 두 번째 이유</h4>
<p>분명히 이 글을 읽으시는 분 중에 Daily Commit(1일 1커밋)을 시도해보았거나 시도하시고 싶은 분들이 분명 있으실 거로 생각한다.<br>그래서 1년간 진행하면서 느낀 점과 장점 또는 단점을 끄적여보려 한다.<br>별 볼 일 없는 프론트앤드 개발 시작한 지 1년 차 밖에는 안됐지만, 시도하고 싶은 분들에게 그 1년간 같이 시작한 Daily Commit의 느꼈던 점을 공유함으로 도움이 되었으면 좋겠다.</p>

<ul>
<li>Daily Commit을 1년간 진행해오며 어떤 공부를 해오며 잔디밭을 채워나갔을까?</li>
</ul>
<h3>👉 전 아무것도 몰라요</h3>
<p>Github를 시작한 지도 사실 1년이 전부이고 개발이 재밌어서 눈을 떠 프론트앤드를 공부해야겠다고 마음을 먹은 것도 같은 시점이다. 그러므로 초반에 Github와 Git을 사용할 줄도 몰랐으며 가르쳐줄 사람도 없었다. 또한, 리액트 따위도 이름만 들었지 리액트에 대해서도 무지했다. 그래서 처음에는 혼자 무작정 책을 사서 공부했고, 모르는 건 커뮤니티와 구글 친구와 함께 헤쳐나갔다. 그냥 무작정 공부를 진행해오며 느꼈던 점은 너무 재밌다!! 프론트앤드의 매력에 빠졌다는 표현이 적절할 거 같다.</p>
<p>그렇게 닥치는 대로 책과 커뮤니티를 참고하며 배우는 것들과 책의 내용을 따라쳐 가며 Github의 잔디밭을 매일매일 채워나갔다.<br>사실 별것 없었다. 코딩테스트를 위한 알고리즘 문제들도 그냥 풀어서 정리하여 올렸고, 책을 읽으며 정리한 내용도 다 MarkDown 형식으로 작성해서 올렸다. 이렇게 한 이유가 뭐냐고 물어본다면 결국 모든 건 보여야 한다고 생각한다. 예를 들어, 내가 자바스크립트 책을 읽었다. 그리고 아무것도 없는 상태에서 "내가 자바스크립트 책을 한 권 읽었어!"라고 얘기하는 거보단 간단한 책을 읽고 회고를 작성하는 등 증거가 있어야 더 보기 좋지 않을까 생각한다. 그리고 정리를 해서 Github에 올린다든가 정리를 해놓으면 필요한 정보를 책에서 찾는 거 보다 훨씬 찾기 수월할 것이다. 현재도 작성되어있는 책 내용을 많이 참고하는 편이다. 물론 주관적인 생각이다. 그리고 나는 다행히 꾸미고 정리하며 채워나가는 방식에 성취감을 얻고 즐거움을 느낀다.</p>
<h3>👉 프론트앤드 개발자가 되기 위한 방법?</h3>
<p>프론트앤드 개발자고 되고 싶다는 목표가 확고해서 블로그와 같은 커뮤니티와 Github는 빠르게 정보를 얻기 위해 매일 같이 봤던 거 같다.<br>이때 <em>그냥 이렇게 공부하면 되는 건가?</em> 라는 생각이 들었다. 이때, 딱 나한테 좋은 세미나를 찾게 되었다. 지금 생각해보면 어찌 보면 정말 당연한 것들이었지만, 이 시기에 아주 좋은 온라인 세미나였었다. 우아한 형제들에서 주최한 온라인 세미나였는데 주제가 <a href="https://haranglog.tistory.com/9">FrontEnd 개발자가 되기 위한 10가지 방법</a> 이였고 당연히 신청해서 들었다.<br>세미나를 들으면서 느꼈던 점은 그래도 이제 좀 할 줄 안다고 생각했던 나 자신이 한심해졌다는 점과 배워야 할 것들이 산더미구나라는 점이었다.<br>그리고 프론트앤드 로드맵을 보자마자 모르는 것이 너무 많다는 것과 충격 그 자체.</p>
<blockquote>
<p><a href="https://github.com/kamranahmedse/developer-roadmap#frontend-roadmap">2021 프론트앤드 로드맵 (영어)</a><br><a href="https://github.com/devJang/developer-roadmap#%ED%94%84%EB%A1%A0%ED%8A%B8%EC%97%94%EB%93%9C-%EB%A1%9C%EB%93%9C%EB%A7%B5">2020 프론트앤드 로드맵 (한글)</a></p>
</blockquote>
<p>그렇게 세미나를 듣고 중요한 것들을 따라서 공부하려고 했고, 많이 부족했지만, 책을 읽고 배운 것들을 바탕으로 사이드 프로젝트 만들면서 Github 잔디를 채워나갔다. 이때 사실 commit을 어떻게 나눠야 하는지도 몰랐고 commit 컨벤션 같은 것도 몰랐다. 그냥 하루에 공부를 다 하고 전체를 한꺼번에 올렸었다. 또한, 그 사이드 프로젝트도 지금 생각해본 정말 형편없이 구현에만 의존한 개발이었는데 긍정적으로 생각해보면 그만큼 성장한 게 아닌가 싶다.</p>
<h3>👉 우아한 테크러닝 3기</h3>
<p><a href="https://github.com/saseungmin/woowa_tech_learning_react_typescript">우아한 테크러닝 3기</a>는 우아한 형제들에서 주최한 교육으로 4주간 진행되었다. 원래라면 오프라인으로 진행되어야 했지만, 코로나로 인해서 운이 좋게 선발되어서 김민태 님의 좋은 강의를 들었다.<br>이 강의는 기본적으로 React와 TypeScript 기반의 웹앱 개발 교육이었지만, 주제를 벗어나 JavaScript의 내부 원리와 기본적인 중요한 내용도 많이 설명해주셨고 질문도 정말 많이 있었는데 그 질문들을 더 일찍 시작해서 답해주셨고, 심지어 시간이 넘어서까지도 모두 다 답해주셨다.<br>그리고 이 강의에서 가장 좋았던 점은 리액트와 리액트의 상태관리 라이브러리인 리덕스를 직접 JavaScript로 구현해보는 것이었다. 여태까지 별 고민 안 하고 단순히 <strong>쓰는 방법</strong>만 알고 있다고 쓴다고 생각했던 나에게 매우 좋았던 설명이었다. 리액트는 그냥 단순히 개발을 편하게 해주는 라이브러리에 불과할 뿐…. 단순히 사용법만 알면 다 사용할 수 있다는 생각이 들었고 결국 리액트라는 도구가 중요한 게 아니었다.</p>
<blockquote>
<p><a href="https://haranglog.tistory.com/category/%EC%9A%B0%EC%95%84%ED%95%9C%20%ED%85%8C%ED%81%AC%EB%9F%AC%EB%8B%9D%203%EA%B8%B0">우아한 테크러닝 3기 강의 내용을 정리</a></p>
</blockquote>
<h3>👉 코드숨 리액트 2기</h3>
<p>우아한 테크러닝을 진행하면서 같은 시기에 수강하게 된 <a href="https://www.codesoom.com/">코드숨</a> 리액트 2기를 신청했다. 코드숨은 3개월 동안 진행되는 온라인 코딩부트캠프로 다른 부트캠프와 차별화된 점이 있다면 코드리뷰와 TDD를 배울 수 있다는 것이다. 가격은 부담스러울 수는 있지만 정말 만족스러운 부트캠프였다.<br>신청하기 전까지 TDD의 T자 아니, 테스트의 테자도 몰랐던 나에게 지금은 TDD와 테스트 없이는 개발은 안 하려고 한다. 마치 TDD의 예찬론자가 된 거처럼 만족스러웠고 모두 실력 있는 트레이너분들이라 코드리뷰를 통해 3개월이라는 단 시간 동안 정말 많이 성장했다고 생각한다.<br>성과 아닌 성과라고 한다면 마지막 한 달은 개인 프로젝트로 진행되는데 현재까지 테스트 300개 정도와 Code Coverage 99.6%를 유지하고 있다.<br>원래 부트캠프에 대한 안 좋은 선입견이 있었지만, 정말 만족스러웠고 코드숨을 진행하면서 느꼈던 점은 혼자 공부하는 거보다 배우는 속도가 차원이 다르고 내가 절대 혼자서 알 수 없는 인사이트를 알 수 있다는 점을 몸소 느꼈다.<br>코드숨에 대한 자세한 내용은 아래 링크 참고….</p>
<blockquote>
<p><a href="https://haranglog.tistory.com/23?category=943668">코드숨 리액트 2기 후기</a><br><a href="https://github.com/CodeSoom/ConStu">개인 프로젝트</a></p>
</blockquote>
<h3>👉 그 외에 잔디 대상자들..</h3>
<h4>Recoil ToDo 프로젝트</h4>
<p>리액트의 새로운 상태관리 라이브러리인 Recoil을 배워보고 싶어서 간단하게 진행하려 했다가 조금은 커진? To Do 리스트 프로젝트이다.<br>처음 이 프로젝트에서 Recoil을 사용했을 때 기본적인 사용법은 공식문서가 굉장히 잘 되어있어서 거의 공식문서를 참고했지만, 어떻게 프로젝트를 구조를 가져가야 할지에 대한 참고 글이 너무 없어서 너무 많이 헤맸다. 아직도 여전히 맞는 구조인지는 전혀 모르겠다.<br>최근에 velopert 님의 <a href="https://github.com/velopert/velofolio">velofolio</a>가 공개되었는데 이 프로젝트가 Recoil로 사용되어 있어서 이걸 참고하면 될 거 같다.</p>
<p>이 프로젝트도 TDD를 적용하며 테스트를 작성했는데 Recoil 테스트는 또 처음이라 제대로 TDD가 적용되었다고 할 수 없었고, 테스트 작성하는데도 비용이 많이 들었다. 또한, Recoil을 사용하여 API 호출도 해보고 싶었기에 백앤드도 테스트를 작성하며 직접 구현하였다. 여기서 테스트 작성하는데 비용이 많이 들면 왜 하냐고 하겠지만, 현재 테스트 작성하는데 들이는 비용은 당연한 훈련이라고 생각한다. 이렇게 계속 TDD의 훈련을 반복하다 보면 테스트를 작성하지 않고 기술부채가 계속 쌓여 지연되는 거보단 더 빠르게 개발할 수 있고 더 좋은 결과물을 얻을 수 있을 것이다.</p>
<blockquote>
<p><a href="https://github.com/saseungmin/Recoil_ToDo">Recoil_ToDo_Frontend</a><br><a href="https://github.com/saseungmin/Recoil_Todo_Backend">Recoil_ToDo_Backend</a></p>
</blockquote>
<h4>책을 읽고 정리..</h4>
<p>이 Repository는 전공 서적 책들을 읽고 정리하며 스터디를 통해 책을 읽는 것도 포함되어 있다.<br>장점이자 단점이 될 수 있는 방식이라 생각하는데 책을 읽으며 정리하는 건 그냥 읽는 거보다 시간이 오래 걸린다. 장점은 보통 책을 다시 읽기는 힘들고 다시 찾기도 힘들지만 정리해놓으면 지나가면서 계속 보게 되는 장점이 있고 한 권 한 권 읽을 때마다 쌓여가는 성취감도 있다. 하지만 정리하는 게 귀찮고 빠르게 책을 읽고 싶은 분들에겐 추천은 하지 않는다.<br>어쨌든 책을 읽읍시다! 책에는 구글에서 찾고 읽기 힘든 알지 못했던 자세한 내용이 많다는 걸 다시 한 번 깨닫게 되었다.</p>
<blockquote>
<p><a href="https://github.com/saseungmin/reading_books_record_repository">책을 읽고 정리</a></p>
</blockquote>
<h4>TIL(일일 회고)</h4>
<p><a href="https://github.com/saseungmin/codesoom_code_review_retrospective">코드숨에서 회고</a> 의 장점을 느낀 뒤 올해 다짐 중 하나였던 일일 회고를 작성하게 되었다. 처음 목적은 TIL으로 오늘 배우거나 새롭게 알게 된 것들만을 작성하려고 했지만, 추가로 일일 회고까지 작성하게 되었다. 올해 1월 초부터 시작하여 5월 초인 현재까지 지속하여오고 있다. 중간에 한 7번 정도 빼먹긴 했지만 나름 준수하게 잘 지켜나가고 있다고 생각한다.<br>현재 작성하고 있는 형식은 간단하게 어제 정해놓은 계획들을 오늘 잘 실천했는가를 체크하고 배운 점과 알게 된 점을 작성하고 하루 회고를 작성한 뒤 내일 계획을 작성하는 순으로 작성하고 있다.</p>
<p>솔직히 매일 회고 작성하는 것이 어렸을 때 일기 작성하는 것처럼 쉽지만은 않다. 하지만 일일 회고를 작성하면서 하루를 다시 돌아볼 수 있는 계기가 되고 자기반성을 할 수 있으며, 그 반성을 통해 고쳐나갈 수 있는 지름길이라고 생각한다.</p>
<blockquote>
<p><a href="https://github.com/saseungmin/TIL">TIL(일일 회고)</a></p>
</blockquote>
<h2>🦄 1년 간 진행해오며 느낀 1Day 1Commit의 장점과 단점</h2>
<ul>
<li>1년 간 진행해오면서 느낀 <strong>주관적인</strong> 생각입니다.</li>
</ul>
<h3>🐶 장점</h3>
<ol>
<li><strong>꾸준함을 유지할 수 있다</strong>.<br>개발자로서 그 꾸준함을 나타낼 수 있는 지표는 Github의 commit 상태뿐이라고 생각이 든다.<br>보이지 않고서야 누가 알아줄까? 보이는 지표로는 최고라고 생각한다.</li>
<li><strong>포트폴리오가 자연스럽게 만들어진다.</strong><br>개발자로 취업과 이직을 위해서 Github Link는 선택 사항이라고는 하지만 사실상 이제는 이력서에 거의 필수 사항이 되었다.<br>그만큼 Github 관리는 매우 중요하다고 생각이 든다. Daily Commit을 하며 하나하나 쌓아나가면 자연스럽게 포트폴리오가 완성될 수 있으며 좋은 인상을 심어줄 수 있다고 생각한다.</li>
<li><strong>성취감을 얻을 수 있다.</strong><br>자신과의 약속을 지킨다는 다짐으로 시작하면 하루 이틀 계속 시간이 지날수록 초록색으로 변할 잔디를 보면서 <em>내가 이렇게 열심히 하고 있구나!</em> 라는 성취감을 얻을 수 있다.</li>
</ol>
<h3>🐶 단점</h3>
<ol>
<li><strong>커밋을 해야 한다는 압박감에 시달릴 수 있다.</strong><br>이게 제일 큰 단점이라고 생각이 든다. 지금은 당연하듯 해야 할 공부가 많기도 하고 배우는 게 즐거워 신경도 안 쓰고 하고 있지만, 처음에 시작할 때 하루에 커밋을 해야 한다는 압박감을 느낄 수밖에 없었다.<br>예를 들어서 오늘 커밋을 아직 안 한 상태에서 23:50분이 되었다. <em>오늘 00:00 시가 지나가면 잔디가 잘려버려!</em> 라는 생각을 가질 수밖에 없게 되고 그로 인해 의미 없는 커밋을 할 수밖에 없어진다. 이 말이 즉, 단점 2번에 해당하는 말이다.</li>
<li><strong>커밋이 전부가 아니다.</strong><br>아무거나 커밋을 한다고 그 커밋이 제대로 된 커밋일까? 예를 들어 하나의 Repository에 Daily Commit이 잘리기를 보기 싫어서 띄어쓰기 한 칸만 하고 커밋하여 유지하는 게 과연 당당하게 오늘 공부해서 만든 성취감 있는 진실한 커밋이라 할 수 있을까?<br>결국, 2번 단점도 단점 1번에 의해 생긴 단점이다.</li>
<li><strong>악용될 우려가 존재한다</strong><br>사실 Github의 커밋 상태는 조작할 수 있다. Github의 커밋 상태라기보단 커밋의 시간을 조작할 수 있다는 게 맞겠다.<br>커밋의 시간을 조작하여 이전 시간의 커밋으로 변경해 잔디를 채울 수 있다. 다행히도 아직 조작해서 커밋을 채운 적은 없다. 다만, 편법은 쓴 적은 있다. 예를 들어 다음날에는 못할 거 같다고 생각하면 그 전날에 00시까지 넘어서 공부하고 커밋을 하는 방법을 사용하였다. 어떻게 보면 00시가 지났으니 당연할 수 있지만, 양심에는 찔린다.</li>
</ol>
<h2>🚀 마무리하며..</h2>
<figure width="100%" data-origin-width="1596" data-origin-height="400" data-ke-mobilestyle="widthContent"><span data-url="https://blog.kakaocdn.net/dn/co8gj4/btq3S0qtbrC/Aeu4l3oXHub9f6yw197Gtk/img.png" data-lightbox="lightbox" data-alt=""><img src="https://blog.kakaocdn.net/dn/co8gj4/btq3S0qtbrC/Aeu4l3oXHub9f6yw197Gtk/img.png" width="100%" data-origin-width="1596" data-origin-height="400" data-ke-mobilestyle="widthContent"></span></figure>
<p>1년간 진행해오면서 회고를 써야겠다 다짐만 하다가 쓰는데 이 글을 읽고 조금이라도 도움이 되셨으면 좋겠다.<br>Daily Commit을 진행해오면서 다행히도 1년 동안 아프거나 큰일은 없었다. 그래서 이렇게 유지할 수 있던 게 아니었나 싶다. 앞으로도 2년, 3년 상황이 가능하고 몸이 가능할 때까지 계속해서 유지해볼 생각이다. 이제는 그냥 일상이고 습관이라고 생각하며 하니까 별로 어렵지도 않고 오히려 기분이 좋아진다.<br>그리고 Daily Commit을 할 때 한가지 주의할 점은 <strong>필요 없는 repository라도 삭제</strong>하면 큰일 난다. repository를 삭제하면 commit history도 없어지기 때문에 잔디가 사라지게 된다.<br>Daily Commit에 대해 궁금하다면 자세한 내용은 이미 유명하신 개발자분들이 작성해놓은 블로그들이 많이 있다. 아래에 첨부를 꼭! 참고 바란다.</p>
<p>마지막으로 Daily Commit을 할지 고민하고 계신 분들에게 하고 싶은 말은 일단 주저하지 말고 해보시는 것을 추천해 드린다. 눈에 보이는 지표를 보면서 많은 성취감을 얻을 수 있을 것이고 덩달아 성장하고 있다는 걸 느낄 것이다. 물론, 매일 한다는 게 중요하진 않다. 꾸준히 의미 있는 무언가를 했다는 게 더 중요하다고 생각한다. 그렇기에 그 꾸준함을 유지할 수 있는 도구라 생각한다. 리액트도 단순히 프론트앤드 개발을 하기 위한 도구처럼 말이다. 그러므로 매일 해야 한다는 압박감을 가지고 시작하기보단 끊겨도 좋으니까 꾸준함을 유지한다는 생각으로 하면 좋을 거 같다. 또한, 진행하면서 계속 유지할 수 있게 만들어주는 건 자신과의 약속이라고 생각하면 좋다. 늘 그랬듯이 남과의 약속이 아닌 나 자신과 약속을 하고 자신이 정한 목표를 이루고 쌓아간다는 생각으로 하면 충분히 누구나 잘할 수 있다고 생각한다.</p>
<p>저도 했는데 누군 못하겠습니까?<br>끝! 긴 글 읽어주셔서 감사합니다! 🙏🙏🙏</p>
<ul>
<li><a href="https://jojoldu.tistory.com/402">이동욱님의 일일 커밋의 효용성 블로그 글</a></li>
<li><a href="https://blog.outsider.ne.kr/1141">Outsider님의 일일 커밋 블로그 글</a></li>
<li><a href="https://milooy.wordpress.com/2016/07/02/daily-commit-1-year/">진유림님의 일일 커밋 회고 블로그 글</a></li>
</ul>

</div></div>

SaDevelog

Harang

이 글은 의식의 흐름대로 씁니다.. 참고해주세요.
또한, 이 글은 개인적인 회고도 담겨있기 때문에 원하시는 정보가 없을 수도 있습니다.
  이 글을 쓰는 이유?
별 이유는 없지만 두 가지 정도가 있다.
  첫 번째 이유
가장 큰 이유는 1년 동안 무엇을 했고 얼마나 성장했는지에 대해서 자기 회고를 하고 싶어졌다.
사실 제대로 된 프론트앤드 개발은 1Day 1Commit을 같이 시작한 1년 전이기 때문에 같이 회고하는 겸 써도 괜찮을 거 같았다.
또한, 그로 인해서 자기회고도 할 수 있을 거라 믿고 있다.
  두 번째 이유
분명히 이 글을 읽으시는 분 중에 Daily Commit(1일 1커밋)을 시도해보았거나 시도하시고 싶은 분들이 분명 있으실 거로 생각한다.
그래서 1년간 진행하면서 느낀 점과 장점 또는 단점을 끄적여보려 한다.
별 볼 일 없는 프론트앤드 개발 시작한 지 1년 차 밖에는 안됐지만, 시도하고 싶은 분들에게 그 1년간 같이 시작한 Daily Commit의 느꼈던 점을 공유함으로 도움이 되었으면 좋겠다.
  1년 동안 무엇을 했을까?
Daily Commit을 1년간 진행해오며 어떤 공부를 해오며 잔디밭을 채워나갔을까?
  전 아무것도 몰라요
Github를 시작한 지도 사실 1년이 전부이고 개발이 재밌어서 눈을 떠 프론트앤드를 공부해야겠다고 마음을 먹은 것도 같은 시점이다. 그러므로 초반에 Github와 Git을 사용할 줄도 몰랐으며 가르쳐줄 사람도 없었다. 또한, 리액트 따위도 이름만 들었지 리액트에 대해서도 무지했다. 그래서 처음에는 혼자 무작정 책을 사서 공부했고, 모르는 건 커뮤니티와 구글 친구와 함께 헤쳐나갔다. 그냥 무작정 공부를 진행해오며 느꼈던 점은 너무 재밌다!! 프론트앤드의 매력에 빠졌다는 표현이 적절할 거 같다.
그렇게 닥치는 대로 책과 커뮤니티를 참고하며 배우는 것들과 책의 내용을 따라쳐 가며 Github의 잔디밭을 매일매일 채워나갔다.
사실 별것 없었다. 코딩테스트를 위한 알고리즘 문제들도 그냥 풀어서 정리하여 올렸고, 책을 읽으며 정리한 내용도 다 MarkDown 형식으로 작성해서 올렸다. 이렇게 한 이유가 뭐냐고 물어본다면 결국 모든 건 보여야 한다고 생각한다. 예를 들어, 내가 자바스크립트 책을 읽었다. 그리고 아무것도 없는 상태에서 "내가 자바스크립트 책을 한 권 읽었어!"라고 얘기하는 거보단 간단한 책을 읽고 회고를 작성하는 등 증거가 있어야 더 보기 좋지 않을까 생각한다. 그리고 정리를 해서 Github에 올린다든가 정리를 해놓으면 필요한 정보를 책에서 찾는 거 보다 훨씬 찾기 수월할 것이다. 현재도 작성되어있는 책 내용을 많이 참고하는 편이다. 물론 주관적인 생각이다. 그리고 나는 다행히 꾸미고 정리하며 채워나가는 방식에 성취감을 얻고 즐거움을 느낀다.
  프론트앤드 개발자가 되기 위한 방법?
프론트앤드 개발자고 되고 싶다는 목표가 확고해서 블로그와 같은 커뮤니티와 Github는 빠르게 정보를 얻기 위해 매일 같이 봤던 거 같다.
이때 그냥 이렇게 공부하면 되는 건가? 라는 생각이 들었다. 이때, 딱 나한테 좋은 세미나를 찾게 되었다. 지금 생각해보면 어찌 보면 정말 당연한 것들이었지만, 이 시기에 아주 좋은 온라인 세미나였었다. 우아한 형제들에서 주최한 온라인 세미나였는데 주제가 FrontEnd 개발자가 되기 위한 10가지 방법 이였고 당연히 신청해서 들었다.
세미나를 들으면서 느꼈던 점은 그래도 이제 좀 할 줄 안다고 생각했던 나 자신이 한심해졌다는 점과 배워야 할 것들이 산더미구나라는 점이었다.
그리고 프론트앤드 로드맵을 보자마자 모르는 것이 너무 많다는 것과 충격 그 자체.
2021 프론트앤드 로드맵 (영어)
2020 프론트앤드 로드맵 (한글)
그렇게 세미나를 듣고 중요한 것들을 따라서 공부하려고 했고, 많이 부족했지만, 책을 읽고 배운 것들을 바탕으로 사이드 프로젝트 만들면서 Github 잔디를 채워나갔다. 이때 사실 commit을 어떻게 나눠야 하는지도 몰랐고 commit 컨벤션 같은 것도 몰랐다. 그냥 하루에 공부를 다 하고 전체를 한꺼번에 올렸었다. 또한, 그 사이드 프로젝트도 지금 생각해본 정말 형편없이 구현에만 의존한 개발이었는데 긍정적으로 생각해보면 그만큼 성장한 게 아닌가 싶다.
  우아한 테크러닝 3기
우아한 테크러닝 3기는 우아한 형제들에서 주최한 교육으로 4주간 진행되었다. 원래라면 오프라인으로 진행되어야 했지만, 코로나로 인해서 운이 좋게 선발되어서 김민태 님의 좋은 강의를 들었다.
이 강의는 기본적으로 React와 TypeScript 기반의 웹앱 개발 교육이었지만, 주제를 벗어나 JavaScript의 내부 원리와 기본적인 중요한 내용도 많이 설명해주셨고 질문도 정말 많이 있었는데 그 질문들을 더 일찍 시작해서 답해주셨고, 심지어 시간이 넘어서까지도 모두 다 답해주셨다.
그리고 이 강의에서 가장 좋았던 점은 리액트와 리액트의 상태관리 라이브러리인 리덕스를 직접 JavaScript로 구현해보는 것이었다. 여태까지 별 고민 안 하고 단순히 쓰는 방법만 알고 있다고 쓴다고 생각했던 나에게 매우 좋았던 설명이었다. 리액트는 그냥 단순히 개발을 편하게 해주는 라이브러리에 불과할 뿐…. 단순히 사용법만 알면 다 사용할 수 있다는 생각이 들었고 결국 리액트라는 도구가 중요한 게 아니었다.
우아한 테크러닝 3기 강의 내용을 정리
  코드숨 리액트 2기
우아한 테크러닝을 진행하면서 같은 시기에 수강하게 된 코드숨 리액트 2기를 신청했다. 코드숨은 3개월 동안 진행되는 온라인 코딩부트캠프로 다른 부트캠프와 차별화된 점이 있다면 코드리뷰와 TDD를 배울 수 있다는 것이다. 가격은 부담스러울 수는 있지만 정말 만족스러운 부트캠프였다.
신청하기 전까지 TDD의 T자 아니, 테스트의 테자도 몰랐던 나에게 지금은 TDD와 테스트 없이는 개발은 안 하려고 한다. 마치 TDD의 예찬론자가 된 거처럼 만족스러웠고 모두 실력 있는 트레이너분들이라 코드리뷰를 통해 3개월이라는 단 시간 동안 정말 많이 성장했다고 생각한다.
성과 아닌 성과라고 한다면 마지막 한 달은 개인 프로젝트로 진행되는데 현재까지 테스트 300개 정도와 Code Coverage 99.6%를 유지하고 있다.
원래 부트캠프에 대한 안 좋은 선입견이 있었지만, 정말 만족스러웠고 코드숨을 진행하면서 느꼈던 점은 혼자 공부하는 거보다 배우는 속도가 차원이 다르고 내가 절대 혼자서 알 수 없는 인사이트를 알 수 있다는 점을 몸소 느꼈다.
코드숨에 대한 자세한 내용은 아래 링크 참고….
코드숨 리액트 2기 후기
개인 프로젝트
  그 외에 잔디 대상자들..
Recoil ToDo 프로젝트
리액트의 새로운 상태관리 라이브러리인 Recoil을 배워보고 싶어서 간단하게 진행하려 했다가 조금은 커진? To Do 리스트 프로젝트이다.
처음 이 프로젝트에서 Recoil을 사용했을 때 기본적인 사용법은 공식문서가 굉장히 잘 되어있어서 거의 공식문서를 참고했지만, 어떻게 프로젝트를 구조를 가져가야 할지에 대한 참고 글이 너무 없어서 너무 많이 헤맸다. 아직도 여전히 맞는 구조인지는 전혀 모르겠다.
최근에 velopert 님의 velofolio가 공개되었는데 이 프로젝트가 Recoil로 사용되어 있어서 이걸 참고하면 될 거 같다.
이 프로젝트도 TDD를 적용하며 테스트를 작성했는데 Recoil 테스트는 또 처음이라 제대로 TDD가 적용되었다고 할 수 없었고, 테스트 작성하는데도 비용이 많이 들었다. 또한, Recoil을 사용하여 API 호출도 해보고 싶었기에 백앤드도 테스트를 작성하며 직접 구현하였다. 여기서 테스트 작성하는데 비용이 많이 들면 왜 하냐고 하겠지만, 현재 테스트 작성하는데 들이는 비용은 당연한 훈련이라고 생각한다. 이렇게 계속 TDD의 훈련을 반복하다 보면 테스트를 작성하지 않고 기술부채가 계속 쌓여 지연되는 거보단 더 빠르게 개발할 수 있고 더 좋은 결과물을 얻을 수 있을 것이다.
Recoil_ToDo_Frontend
Recoil_ToDo_Backend
책을 읽고 정리..
이 Repository는 전공 서적 책들을 읽고 정리하며 스터디를 통해 책을 읽는 것도 포함되어 있다.
장점이자 단점이 될 수 있는 방식이라 생각하는데 책을 읽으며 정리하는 건 그냥 읽는 거보다 시간이 오래 걸린다. 장점은 보통 책을 다시 읽기는 힘들고 다시 찾기도 힘들지만 정리해놓으면 지나가면서 계속 보게 되는 장점이 있고 한 권 한 권 읽을 때마다 쌓여가는 성취감도 있다. 하지만 정리하는 게 귀찮고 빠르게 책을 읽고 싶은 분들에겐 추천은 하지 않는다.
어쨌든 책을 읽읍시다! 책에는 구글에서 찾고 읽기 힘든 알지 못했던 자세한 내용이 많다는 걸 다시 한 번 깨닫게 되었다.
책을 읽고 정리
TIL(일일 회고)
코드숨에서 회고 의 장점을 느낀 뒤 올해 다짐 중 하나였던 일일 회고를 작성하게 되었다. 처음 목적은 TIL으로 오늘 배우거나 새롭게 알게 된 것들만을 작성하려고 했지만, 추가로 일일 회고까지 작성하게 되었다. 올해 1월 초부터 시작하여 5월 초인 현재까지 지속하여오고 있다. 중간에 한 7번 정도 빼먹긴 했지만 나름 준수하게 잘 지켜나가고 있다고 생각한다.
현재 작성하고 있는 형식은 간단하게 어제 정해놓은 계획들을 오늘 잘 실천했는가를 체크하고 배운 점과 알게 된 점을 작성하고 하루 회고를 작성한 뒤 내일 계획을 작성하는 순으로 작성하고 있다.
솔직히 매일 회고 작성하는 것이 어렸을 때 일기 작성하는 것처럼 쉽지만은 않다. 하지만 일일 회고를 작성하면서 하루를 다시 돌아볼 수 있는 계기가 되고 자기반성을 할 수 있으며, 그 반성을 통해 고쳐나갈 수 있는 지름길이라고 생각한다.
TIL(일일 회고)
  1년 간 진행해오며 느낀 1Day 1Commit의 장점과 단점
1년 간 진행해오면서 느낀 주관적인 생각입니다.
  장점
꾸준함을 유지할 수 있다.
개발자로서 그 꾸준함을 나타낼 수 있는 지표는 Github의 commit 상태뿐이라고 생각이 든다.
보이지 않고서야 누가 알아줄까? 보이는 지표로는 최고라고 생각한다.
포트폴리오가 자연스럽게 만들어진다.
개발자로 취업과 이직을 위해서 Github Link는 선택 사항이라고는 하지만 사실상 이제는 이력서에 거의 필수 사항이 되었다.
그만큼 Github 관리는 매우 중요하다고 생각이 든다. Daily Commit을 하며 하나하나 쌓아나가면 자연스럽게 포트폴리오가 완성될 수 있으며 좋은 인상을 심어줄 수 있다고 생각한다.
성취감을 얻을 수 있다.
자신과의 약속을 지킨다는 다짐으로 시작하면 하루 이틀 계속 시간이 지날수록 초록색으로 변할 잔디를 보면서 내가 이렇게 열심히 하고 있구나! 라는 성취감을 얻을 수 있다.
  단점
커밋을 해야 한다는 압박감에 시달릴 수 있다.
이게 제일 큰 단점이라고 생각이 든다. 지금은 당연하듯 해야 할 공부가 많기도 하고 배우는 게 즐거워 신경도 안 쓰고 하고 있지만, 처음에 시작할 때 하루에 커밋을 해야 한다는 압박감을 느낄 수밖에 없었다.
예를 들어서 오늘 커밋을 아직 안 한 상태에서 23:50분이 되었다. 오늘 00:00 시가 지나가면 잔디가 잘려버려! 라는 생각을 가질 수밖에 없게 되고 그로 인해 의미 없는 커밋을 할 수밖에 없어진다. 이 말이 즉, 단점 2번에 해당하는 말이다.
커밋이 전부가 아니다.
아무거나 커밋을 한다고 그 커밋이 제대로 된 커밋일까? 예를 들어 하나의 Repository에 Daily Commit이 잘리기를 보기 싫어서 띄어쓰기 한 칸만 하고 커밋하여 유지하는 게 과연 당당하게 오늘 공부해서 만든 성취감 있는 진실한 커밋이라 할 수 있을까?
결국, 2번 단점도 단점 1번에 의해 생긴 단점이다.
악용될 우려가 존재한다
사실 Github의 커밋 상태는 조작할 수 있다. Github의 커밋 상태라기보단 커밋의 시간을 조작할 수 있다는 게 맞겠다.
커밋의 시간을 조작하여 이전 시간의 커밋으로 변경해 잔디를 채울 수 있다. 다행히도 아직 조작해서 커밋을 채운 적은 없다. 다만, 편법은 쓴 적은 있다. 예를 들어 다음날에는 못할 거 같다고 생각하면 그 전날에 00시까지 넘어서 공부하고 커밋을 하는 방법을 사용하였다. 어떻게 보면 00시가 지났으니 당연할 수 있지만, 양심에는 찔린다.
  마무리하며..
1년간 진행해오면서 회고를 써야겠다 다짐만 하다가 쓰는데 이 글을 읽고 조금이라도 도움이 되셨으면 좋겠다.
Daily Commit을 진행해오면서 다행히도 1년 동안 아프거나 큰일은 없었다. 그래서 이렇게 유지할 수 있던 게 아니었나 싶다. 앞으로도 2년, 3년 상황이 가능하고 몸이 가능할 때까지 계속해서 유지해볼 생각이다. 이제는 그냥 일상이고 습관이라고 생각하며 하니까 별로 어렵지도 않고 오히려 기분이 좋아진다.
그리고 Daily Commit을 할 때 한가지 주의할 점은 필요 없는 repository라도 삭제하면 큰일 난다. repository를 삭제하면 commit history도 없어지기 때문에 잔디가 사라지게 된다.
Daily Commit에 대해 궁금하다면 자세한 내용은 이미 유명하신 개발자분들이 작성해놓은 블로그들이 많이 있다. 아래에 첨부를 꼭! 참고 바란다.
마지막으로 Daily Commit을 할지 고민하고 계신 분들에게 하고 싶은 말은 일단 주저하지 말고 해보시는 것을 추천해 드린다. 눈에 보이는 지표를 보면서 많은 성취감을 얻을 수 있을 것이고 덩달아 성장하고 있다는 걸 느낄 것이다. 물론, 매일 한다는 게 중요하진 않다. 꾸준히 의미 있는 무언가를 했다는 게 더 중요하다고 생각한다. 그렇기에 그 꾸준함을 유지할 수 있는 도구라 생각한다. 리액트도 단순히 프론트앤드 개발을 하기 위한 도구처럼 말이다. 그러므로 매일 해야 한다는 압박감을 가지고 시작하기보단 끊겨도 좋으니까 꾸준함을 유지한다는 생각으로 하면 좋을 거 같다. 또한, 진행하면서 계속 유지할 수 있게 만들어주는 건 자신과의 약속이라고 생각하면 좋다. 늘 그랬듯이 남과의 약속이 아닌 나 자신과 약속을 하고 자신이 정한 목표를 이루고 쌓아간다는 생각으로 하면 충분히 누구나 잘할 수 있다고 생각한다.
저도 했는데 누군 못하겠습니까?
끝! 긴 글 읽어주셔서 감사합니다!  
이동욱님의 일일 커밋의 효용성 블로그 글
Outsider님의 일일 커밋 블로그 글
진유림님의 일일 커밋 회고 블로그 글

[회고] Github Daily Commit(1일 1커밋)을 시작한지 1년이 지났다..

댓글