<div id="readability-page-1" class="page"><div><p><h2 id="e1ae" data-testid="storyTitle">매일 커밋 한달의 효능</h2></p><div><h2 id="e410">코드 개발, 프로젝트 운영 그리고 뛰어난 매니저에 대한 동경</h2><div tabindex="-1" aria-hidden="false" role="tooltip"><a rel="noopener follow" href="/?source=post_page---byline--0e6840f8ed78---------------------------------------" data-discover="true"><div><p><img alt="Jinhwan Kim" src="https://miro.medium.com/v2/resize:fill:64:64/1*vU_fccC8YOReY6tGTxackA.jpeg" width="32" height="32" loading="lazy" data-testid="authorPhoto"></p></div></a></div></div><figure><div role="button" tabindex="0"><p><span>Press enter or click to view image in full size</span></p></div><figcaption><a href="https://github-contributions.vercel.app/" rel="noopener ugc nofollow" target="_blank">https://github-contributions.vercel.app/</a></figcaption></figure><p id="b298">올해 개발 중인 프로젝트 중 하나인 <code>nhyris</code>를 5월부터 조금 빡세게 진행하기로 했고, 이를 위해 매일 의미 있는 커밋을 해보기로했다.</p><p id="307b">이 <code>nhyris</code> 라는 프로젝트는 간단하게 설명하면 <code>electron.js</code>을 사용해서 <code>R</code> 과 <code>Shiny</code>를 Standalone Application으로 만들 수 있도록 하는 프레임워크다. 아마 pharma 나 biostat 쪽이 아닌 이상 쓸 일은 없을 테니 뭔 말인지 몰라도 됨.</p><p id="0a61">물론 이 잔디 심기는 깃허브 계정에 속한 모든 프로젝트를 반영하기 때문에 <code>nhyris</code> 외에도 다른 프로젝트에 대한 작업도 있을 것 같긴 한데, nhyris 프로젝트에 대한 개발 내용보다는 매일 커밋에 대한 회고를 하는 것이 주 목적이므로 크게 중요하지 않다.</p><p id="44f3">추가로, 매일 커밋을 위해서는 작업 단위의 커밋을 기준으로 정했다. 이 말은 <strong>리드미에 공백 딸깍 추가</strong>나 <strong>액션으로 이슈 자동화 생성</strong>하는 등의 의미가 없는 작업은 매일 커밋의 의미를 제대로 만들어내기 어렵다고 생각해서 <strong>기능 구현</strong>과 같은 작업을 통해 실제 프로젝트에 진전이 있는 것을 기준으로 한다.</p></div><div><h2 id="02c7">잔디 심기를 위한 작업들의 종류</h2><h3 id="cfbe">1. 이슈 생성 (issue)</h3><p id="1187">프로젝트에서 해야할 일들을 생각나는 대로 작성한다. 이 할 일에는 꼭 해야하는 일, 급하진 않지만 언젠간 해야하는 일, 있으면 좋고 없어도 그만인 일 등이 있는데 이슈를 생성하다보면 점차 <strong>이를 구분하는 능력</strong>도 같이 늘어난다. 만들고 난 이 이슈들을 해결하다 보면, 새로운 이슈가 등장하는데, 이를 효율적으로 관리하기 위한 <strong>이슈 매니지먼트 (라벨, 마일스톤 등) 기술</strong> 또한 늘게 된다.</p><p id="1a31">이슈 매니지먼트에 대한 이야기를 조금 더 하자면, 깃허브에서 모든 리포지토리에 기본으로 제공하는 이슈 라벨 9종류: bug, documentation, duplicate, enhancement, good first issue, help wanted, invalid, question, wontfix 도 상당히 훌륭한 라벨이지만 매일 커밋 하는 동안 프로젝트 리포지토리에 추가했던 라벨은 다음과 같다.</p><ul><li id="fbc6">commands, logs, dependencies, javascript, logs: 특정 작업 연관된 이슈들. 만들때는 자주 등장할 것 같아서 만들었는데 생각만큼 많이 쓰진 않았다.</li><li id="10ad">high / medium / critical: 후술 할 코드 리뷰와 연관된 라벨, 당연하게도? low는 없다. (wontfix)</li><li id="a37c">IDEAS: 메이저 업데이트 이후, 차세대 버전에서 고려해볼만 한 기능, 그러나 당장은 시간과 예산의 부족으로 추가가 어려운 기능들을 위한 라벨</li><li id="c23e">macos, linux, windows: 프로젝트가 여러 OS에 걸쳐 이뤄지는 것이라 추가한 특수 라벨</li><li id="20d9">refactor: 모든 개발자의 소망, 코드 리팩토링과 관련된 이슈 라벨</li></ul><p id="55bf">하나더, 공식 문서나 블로그에서 이슈와 함께 언급되는 마일스톤 기능은 잘 안썼다. 마일스톤은 장기적인 프로젝트 관리에 더 적합하고 이슈는 단기 작업 관리에 더 적합한 차이가 아닐까 싶음.</p><figure><div role="button" tabindex="0"><p><span>Press enter or click to view image in full size</span></p></div></figure><h3 id="1fda">2. 문서 작성 (docs)</h3><p id="a570">프로젝트 진행에 따라 이를 설명하는 기술 문서를 작성한다. 가능하면 모든 개발 과정마다 최신의 내용을 기술 문서에 전부 반영하는 것이 좋지만, 문서를 작성한 이후에 기능이 업데이트 되거나, 최악의 경우 삭제 되면서 다시 갈아엎어야 하는 경우가 꽤 자주 발생한다. 이 과정에는 .너무 자주 업데이트 하자니 헛수고가 될 수도 있다는 위험이 있고, 안하자니 필요한 문서를 늦게 만든다는 참 안타까운 딜레마가 생긴다.</p><figure><div role="button" tabindex="0"><p><span>Press enter or click to view image in full size</span></p></div></figure><p id="cf10">이러한 상황에서 가장 이상적인 방법은 매 업데이트 마다 기술 문서를 함께 작성하는 것이지만, 이는 이상적인 상황에서나 가능하고 차선으로 프로젝트의 기능이 <strong>안정화(변화 없을 것으로 예상) </strong>되고 나면 그 때서야 기능에 대한 문서를 작성하는 것이 효과적이라고 볼 수 있다. 이 방법의 단점은 그 <strong>안정화</strong>가 언제일지는 아무도 모른다는 것.</p><p id="2d36">그래서 어쩔 수 없이 <strong>조금 큰 변화를 나타내는 작업 내용</strong>이나, <strong>생각날 때</strong> 혹은 매일 커밋을 까먹고 있다가 <strong>시간이 없어서 급하게 뭐라도 커밋해야할 때</strong> (문서 작성은 기능 구현이나 이에 따른 테스트가 필요하지 않아 상대적으로 시간이 적게 든다) 종종 했다. 꼭 프로젝트의 기능에 대한 문서가 아니더라도, <strong>리드미</strong>나 <strong>라이센스</strong> 아니면 <strong>프로젝트 소개</strong>와 <strong>로드맵</strong> 같은 프로젝트 자체에 대한 문서도 이에 해당한다. 일명 깃허브 꾸미기. 이는 너무 재밌는 과정이지만 너무 몰입하면 겉보기에만 번지르르하고 속은 텅빈 프로젝트가 되어버릴 수 있어서 주의가 필요하다.</p><h3 id="40b9">3. 코드 정리 (chore / style / bump)</h3><p id="5e1f">리팩토링 단위의 큰 코드 정리는 아니고, 쓰는 라이브러리의 버전을 업데이트 하거나, 작성하고 있는 코드의 코드 스타일을 정리하는 등의 소소한 작업. 가끔 버전 의존성이 깨져서 오류가 나면 그 때부터는 코드 정리가 아니라 버그 수정이 되버림. 보통은 IDE에서 자동으로 해결해 주지만, 가뭄에 콩나듯 매뉴얼하게 해야하는 경우가 있다. 이 작업들은 대체로 하면 좋고 안해도 상관 없는 우선순위가 낮은 작업.</p><figure><div role="button" tabindex="0"><p><span>Press enter or click to view image in full size</span></p></div></figure><h3 id="40cd">4. 버그 수정 (fix)</h3><p id="5b9c">개발자들이, 가장 많이 할 작업 중 하나. 사람이 직접 코딩하던, 나처럼 AI랑 같이 바이브 코딩하던 프로젝트에 의도치 않은 버그는 무조건 발생한다. 그렇기 때문에 이를 고치는 작업은 중요하고, 발생한 버그의 원인 및 수정 방법 파악도 중요하지만 이는 일차적인 것 같고, <strong>이 작업에 어느 정도 시간이 걸릴 것인가를 정확히 예상</strong>하는 것 또한 매일 커밋같은 프로젝트의 지속성에 꽤 중요하다. 생각보다 금방 끝나면 다행이지만, 자잘한 작업인 줄 알고 했는데 길어지면 여러모로 난감하다.</p><p id="8767">버그 수정까진 아닌데, 코드 리뷰 이후에 코드를 수정해야 하는 경우가 정말 많다. 심지어 코드를 AI가 작성했는데, 동일한 AI 혹은 다른 AI로 코드를 리뷰하면 로직이 허술한 경우가 있다. 이에 대한 수정 작업도 이 버그 수정 카테고리로 볼 수 있을 듯</p><figure><div role="button" tabindex="0"><p><span>Press enter or click to view image in full size</span></p></div></figure><h3 id="0940">5. 기능 구현 (feat)</h3><p id="9c93">버그 수정과 더불어 많이 할 작업인 기능 구현. 생각하던 기능을 테스트로 실행해보고, 일반화하는 것에 성공하고 최종 PR을 올릴 때는 꽤 기분이 좋다. 단점은 이후 작업을 하면서 프로젝트의 로직이나, 아키텍쳐를 변경해야해서 만든 기능을 삭제하거나 변경해야 할 때 일을 두번하게 된다.</p><blockquote><p id="9789">그렇다면 애초부터 아키텍쳐를 잘 설계하면 되는 것 아님?</p></blockquote><p id="a457">이라는 생각을 할 수 있는데, 여태 꽤 많은 개발 서적들을 봤지만 <strong>개발 프로젝트 아키텍쳐 잘 설계하는 법</strong>은 대부분 명쾌하게 설명해주기보단 <strong>그냥 경험치가 쌓여야 한다.</strong> 로 얘기 했던 것 같다. 또한 프로젝트가 온전히 scratch에서 만든다면 덜 하겠지만 여러 다른 라이브러리를 활용하기 때문에 이에 맞추어 변경도 필요함.</p><p id="82dc"><strong>변화가 없는 것이 좋은 설계인가 혹은 변화를 감당 할 수 있는 것이 좋은 설계인가?</strong> 어렵다</p><figure><div role="button" tabindex="0"><p><span>Press enter or click to view image in full size</span></p></div></figure><h3 id="0a4b">6. 리팩토링 (refactor)</h3><p id="c11c">솔직히 리팩토링은 기능 구현 보다 더 재밌던 것 같다. 이 이유에 대해서 생각해보면 일단 엉망으로 만든 스파게티를 정갈하게 다듬는 쾌감도 있고, 이를 통해 이후 작업에서의 생산성이 올라간다 !! 라는 자기 최면을 걸 수 있다.</p><p id="40bf">또한 신규 기능이나 버그 수정 처럼 코드에 더하고 빼는 것이 아닌, 프로젝트 내 코드 재배치에 가깝기 때문에 이에 비해 (상대적으로) 머리를 덜써도 된다. 책임 없는 쾌락이 아닐까.</p><p id="cbb5">그렇다고 리팩토링을 아무때나 할 수 있는 것은 아니고, 이전의 문서 작성처럼 기능이 어느 정도 안정화 되어 있을 때 코드의 가독성이나 유지 보수를 위한 분리, 혹은 불필요한 코드와 로직을 제거하여 퍼포먼스 향상 등을 목적으로 할 수 있다. 나중에 없어질 수 있는 기능에 너무 힘 주면 좀 그렇다. 물론 리팩토링 잘못해서 돌아가던게 안 돌아가면 그때부터는 다시 버그 수정임.</p><figure><div role="button" tabindex="0"><p><span>Press enter or click to view image in full size</span></p></div></figure><h3 id="3585">7. 예시 구현 (feat)</h3><p id="3e17">내가 했던 프로젝트는 방법론을 일반화한 “프레임워크”이기 때문에 <strong>이 방법론을 적용하면 이러한 케이스를 구현할 수 있어</strong> 라는 예시들이 필요하다. 이를 위해 <code>nhyris</code> 프레임워크를 이용해서 하나씩 구현하는 작업이 꽤 많았다. (plotly에서 graph gallery를 구현하는 것을 예시로 생각하면 편함)</p><p id="37d1">이는 새로운 기능은 아니지만, 프로젝트를 활용해서 사용할 수 있어야 하고 동시에 이 갤러리를 구현하지 못하는 경우 이를 위한 기능 추가가 필요하기 때문에 작지만 커질 수 있는 작업이었다.</p><p id="9f52">내 경우 예시는 63개 였는데, 절반 정도는 문제 없이 쉽게 구현되었고 (덕분에 시간 급하게 커밋 해야할때 잘 썼다) <strong>절반 정도는 구현을 위해 기존의 아키텍쳐를 비틀어야 하는 경우였다</strong>.</p><p id="0490">결과적으로는 프레임워크에서 사용할 수 있도록 예시 코드로 변경해서 추가 했던 것들을 <strong>전부 드랍하고</strong> 대신 레퍼런스의 코드를 프레임워크에서 바로 사용할 수 있도록 로직을 변경했다. 날린게 아깝긴 하지만, 메데타시 메데타시</p><figure><div role="button" tabindex="0"><p><span>Press enter or click to view image in full size</span></p></div></figure></div><div><h2 id="9e9a">그 외 팁</h2><h3 id="0721"><strong>커밋 금지</strong></h3><p id="b50a"><strong>리포지토리의 설정에서 바로 커밋을 허용하지 않도록 변경</strong>하는 것이 정말 좋다. 즉, 무조건 PR을 통해서만 리포지토리에 업데이트 할 수 있게 하는 것인데 이렇게 하면 3가지 장점이 있다.</p><figure><div role="button" tabindex="0"><p><span>Press enter or click to view image in full size</span></p></div></figure><ol><li id="8846">릴리즈 노트를 생성하기 편함.</li><li id="aa44">코드 리뷰가 가능함 (특히 코파일럿 / Gemini 같은 AI를 코드 리뷰에 활용할 수 있다)</li><li id="9074">브랜치 / PR 에 기반한 작업에 익숙해진다. 이는 굳이 git 명령어까진 안 쓰더라도 github desktop 이나 vscode의 UI 작업으로도 충분하다고 생각한다.</li></ol><figure></figure></div><div><h3 id="6d61">기술 문서</h3><p id="743c">깃허브 리포지토리에 기술문서를 작성하는 방법은 정말 다양한데 역시 Quarto가 최고다. qmd 라고 하는 markdown 기반의 방법을 쓰기 때문에 크게 어렵지 않고, render 같은 관리도 별도의 yml 파일로 관리하기 때문에 어렵지 않다. 코드와 실행 결과도 바로 넣을 수 있기 때문에 프로젝트에서 R이나 Python를 사용한다면 더 도움이 되겠지만 nhyris 처럼 사용하지 않는 기술문서 자체로도 충분히 역할을 한다. Quarto는 특히 brand.yml이 추가 된 다음 부터는 스타일 꾸미기도 훨씬 편리해졌다고 생각함.</p></div><div><h3 id="77ae">매일 커밋</h3><p id="bdc8">매일 커밋을 하는 것은 꽤 어렵다. 꾸준함과 나태함의 문제도 있지만, 그 것만큼이나 작업할 이슈(백로그)가 없는 경우도 문제가 된다. 뭐라도 쥐어짜야 하는데 개발과 더불어 창작의 고통을 경험할 수 있는 좋은 기회가 되고, 일 잘하는 PM, PO가 얼마나 대단한지 알 수 있다.</p><figure><div role="button" tabindex="0"><p><span>Press enter or click to view image in full size</span></p></div></figure></div><div><h3 id="8b56">바이브 코딩</h3><p id="fd10">꽤 자주 말하지만 나는 바이브 코딩 찬성, 찬성을 넘어 찬양파다. 그러나 AI를 완전히 신뢰하는 것은 어렵다. 환각의 문제는 너무 당연하고, IDE와 불완전한 연동으로 인해 코드 수정에 오류가 날 수 있다. 예를 들면 A 줄 다음 B 를 추가한다고 해서 하라고 했는데 A 줄 다음에 A 줄과 B 줄을 (2번) 추가하는 등.</p><p id="effe">아 그리고 자꾸 코드에 주석 넣을때 한글을 쓰거나, 로그 찍을때 이모지를 사용하거나 (os에 따라 이모지가 깨짐) 아무튼 시키지 않은 짓을 자꾸 해서 난처했음</p><figure><div role="button" tabindex="0"><p><span>Press enter or click to view image in full size</span></p></div></figure></div><div><h3 id="5ad7">이슈 매니지먼트</h3><p id="d429">아 이거 추가해야지 ~ 이거 문제 인데? 라고 해서 이슈를 작성하는데, 이때 자세히 쓰지 않으면 며칠 지나서 무슨 말인지 까먹는다. 같은 문제가 다시 발생하기 전까진 알 수 없어서 어쩔 수 없이 issue close.</p><figure></figure></div><div><h3 id="eac3">작업 범위</h3><p id="64ec">작업 범위라는 표현은 조금 애매한 단어인데, 어디까지 작업해야 하는가?를 결정하는 것이 꽤 중요하다. 당연히 많은 것을 구현할 수록 좋지만, 모두가 사용하는 것이 아닌 이런 것도 있다 정도의 수준이라 만들어놔도 별로 사용할 일이 없을 (것 같을) 때를 위해 우선 순위가 낮은 것을 작업 하는 것은 정말로 가성비가 떨어진다. 어느 범위까지의 작업이 적절한 우선 순위인가를 구분하는 것은 개발자도, AI도 아직은 어려워하는 영역인 것 같다.</p></div><div><h3 id="a872">브랜치 네이밍 룰</h3><p id="7076">앞서 바로 커밋 말고, PR로만 작업할 수 있도록 설정을 권장했는데 이를 위해서는 사소한 작업에도 브랜치를 만들어서 작업해야한다. 이때 어려운 것은 브랜치 이름 정하기, 나는 그래도 혼자 하는 프로젝트였기 때문에 똑같은 브랜치를 PR 병합 이후 삭제, 그리고 재사용해도 상관이 없지만 여러 사람이 한다면 어려울 것 같다. 작업 내용이 이슈와 1:1 매칭이 된다면 깃허브 이슈 페이지에서 제공하는 create a branch를 쓰는 것도 좋지만. 그렇지 않은 경우 이 브랜치 네이밍 룰이 없다면 고생을 좀 할 것 같다.</p></div><div><h2 id="7a4d">매일 커밋 종합 회고</h2><ul><li id="666f">당연하게도 프로젝트의 속도가 엄청 빨라진다.</li><li id="7d15">내가 루틴하게 일하는 스타일은 아니라서 습관이 생기진 않았고, 대신 듀오링고나 분재겜 과제하듯 꼬박꼬박 할 수 있는 것은 좋았다.</li><li id="b01c">이슈들을 전부 털어버리면 다음날 할 것이 없어서 이슈를 억지로 짜내야하기 때문에 전부 털지 않고 천천히 했는데, 덕분에 번아웃이 오지 않았던 것 같다. 적당히 일하고 적당히 살자 ~</li><li id="b93f">한 달이면 대충 바닥에서 프로젝트가 완료 되는데, 만약 100일이나 1년 매일 커밋을 한다면 꽤 큰것도 만들어 낼 수 있지 않을까?</li></ul><figure><div role="button" tabindex="0"><p><span>Press enter or click to view image in full size</span></p></div></figure></div><div><h2 id="52c3">딴소리</h2><p id="9300">Daily DevBlog가 툭하면 터져서. WHILE 0124를 만들었음. 6월동안 내부 테스트해보고 오픈 할 건데 이 뉴스레터나 추후 이 뉴스레터 프로젝트 운영, 아니면 뉴스레터 제작에 관심 있으면 알려주삼</p><figure><div role="button" tabindex="0"><p><span>Press enter or click to view image in full size</span></p></div></figure></div></div>

Stories by Jinhwan Kim on Medium

코드 개발, 프로젝트 운영 그리고 뛰어난 매니저에 대한 동경
올해 개발 중인 프로젝트 중 하나인 nhyris를 5월부터 조금 빡세게 진행하기로 했고, 이를 위해 매일 의미 있는 커밋을 해보기로했다.
이 nhyris 라는 프로젝트는 간단하게 설명하면 electron.js을 사용해서 R 과 Shiny를 Standalone Application으로 만들 수 있도록 하는 프레임워크다. 아마 pharma 나 biostat 쪽이 아닌 이상 쓸 일은 없을 테니 뭔 말인지 몰라도 됨.
물론 이 잔디 심기는 깃허브 계정에 속한 모든 프로젝트를 반영하기 때문에 nhyris 외에도 다른 프로젝트에 대한 작업도 있을 것 같긴 한데, nhyris 프로젝트에 대한 개발 내용보다는 매일 커밋에 대한 회고를 하는 것이 주 목적이므로 크게 중요하지 않다.
추가로, 매일 커밋을 위해서는 작업 단위의 커밋을 기준으로 정했다. 이 말은 리드미에 공백 딸깍 추가나 액션으로 이슈 자동화 생성하는 등의 의미가 없는 작업은 매일 커밋의 의미를 제대로 만들어내기 어렵다고 생각해서 기능 구현과 같은 작업을 통해 실제 프로젝트에 진전이 있는 것을 기준으로 한다.
잔디 심기를 위한 작업들의 종류
1. 이슈 생성 (issue)
프로젝트에서 해야할 일들을 생각나는 대로 작성한다. 이 할 일에는 꼭 해야하는 일, 급하진 않지만 언젠간 해야하는 일, 있으면 좋고 없어도 그만인 일 등이 있는데 이슈를 생성하다보면 점차 이를 구분하는 능력도 같이 늘어난다. 만들고 난 이 이슈들을 해결하다 보면, 새로운 이슈가 등장하는데, 이를 효율적으로 관리하기 위한 이슈 매니지먼트 (라벨, 마일스톤 등) 기술 또한 늘게 된다.
이슈 매니지먼트에 대한 이야기를 조금 더 하자면, 깃허브에서 모든 리포지토리에 기본으로 제공하는 이슈 라벨 9종류: bug, documentation, duplicate, enhancement, good first issue, help wanted, invalid, question, wontfix 도 상당히 훌륭한 라벨이지만 매일 커밋 하는 동안 프로젝트 리포지토리에 추가했던 라벨은 다음과 같다.
commands, logs, dependencies, javascript, logs: 특정 작업 연관된 이슈들. 만들때는 자주 등장할 것 같아서 만들었는데 생각만큼 많이 쓰진 않았다.
high / medium / critical: 후술 할 코드 리뷰와 연관된 라벨, 당연하게도? low는 없다. (wontfix)
IDEAS: 메이저 업데이트 이후, 차세대 버전에서 고려해볼만 한 기능, 그러나 당장은 시간과 예산의 부족으로 추가가 어려운 기능들을 위한 라벨
macos, linux, windows: 프로젝트가 여러 OS에 걸쳐 이뤄지는 것이라 추가한 특수 라벨
refactor: 모든 개발자의 소망, 코드 리팩토링과 관련된 이슈 라벨
하나더, 공식 문서나 블로그에서 이슈와 함께 언급되는 마일스톤 기능은 잘 안썼다. 마일스톤은 장기적인 프로젝트 관리에 더 적합하고 이슈는 단기 작업 관리에 더 적합한 차이가 아닐까 싶음.
2. 문서 작성 (docs)
프로젝트 진행에 따라 이를 설명하는 기술 문서를 작성한다. 가능하면 모든 개발 과정마다 최신의 내용을 기술 문서에 전부 반영하는 것이 좋지만, 문서를 작성한 이후에 기능이 업데이트 되거나, 최악의 경우 삭제 되면서 다시 갈아엎어야 하는 경우가 꽤 자주 발생한다. 이 과정에는 .너무 자주 업데이트 하자니 헛수고가 될 수도 있다는 위험이 있고, 안하자니 필요한 문서를 늦게 만든다는 참 안타까운 딜레마가 생긴다.
이러한 상황에서 가장 이상적인 방법은 매 업데이트 마다 기술 문서를 함께 작성하는 것이지만, 이는 이상적인 상황에서나 가능하고 차선으로 프로젝트의 기능이 안정화(변화 없을 것으로 예상) 되고 나면 그 때서야 기능에 대한 문서를 작성하는 것이 효과적이라고 볼 수 있다. 이 방법의 단점은 그 안정화가 언제일지는 아무도 모른다는 것.
그래서 어쩔 수 없이 조금 큰 변화를 나타내는 작업 내용이나, 생각날 때 혹은 매일 커밋을 까먹고 있다가 시간이 없어서 급하게 뭐라도 커밋해야할 때 (문서 작성은 기능 구현이나 이에 따른 테스트가 필요하지 않아 상대적으로 시간이 적게 든다) 종종 했다. 꼭 프로젝트의 기능에 대한 문서가 아니더라도, 리드미나 라이센스 아니면 프로젝트 소개와 로드맵 같은 프로젝트 자체에 대한 문서도 이에 해당한다. 일명 깃허브 꾸미기. 이는 너무 재밌는 과정이지만 너무 몰입하면 겉보기에만 번지르르하고 속은 텅빈 프로젝트가 되어버릴 수 있어서 주의가 필요하다.
3. 코드 정리 (chore / style / bump)
리팩토링 단위의 큰 코드 정리는 아니고, 쓰는 라이브러리의 버전을 업데이트 하거나, 작성하고 있는 코드의 코드 스타일을 정리하는 등의 소소한 작업. 가끔 버전 의존성이 깨져서 오류가 나면 그 때부터는 코드 정리가 아니라 버그 수정이 되버림. 보통은 IDE에서 자동으로 해결해 주지만, 가뭄에 콩나듯 매뉴얼하게 해야하는 경우가 있다. 이 작업들은 대체로 하면 좋고 안해도 상관 없는 우선순위가 낮은 작업.
4. 버그 수정 (fix)
개발자들이, 가장 많이 할 작업 중 하나. 사람이 직접 코딩하던, 나처럼 AI랑 같이 바이브 코딩하던 프로젝트에 의도치 않은 버그는 무조건 발생한다. 그렇기 때문에 이를 고치는 작업은 중요하고, 발생한 버그의 원인 및 수정 방법 파악도 중요하지만 이는 일차적인 것 같고, 이 작업에 어느 정도 시간이 걸릴 것인가를 정확히 예상하는 것 또한 매일 커밋같은 프로젝트의 지속성에 꽤 중요하다. 생각보다 금방 끝나면 다행이지만, 자잘한 작업인 줄 알고 했는데 길어지면 여러모로 난감하다.
버그 수정까진 아닌데, 코드 리뷰 이후에 코드를 수정해야 하는 경우가 정말 많다. 심지어 코드를 AI가 작성했는데, 동일한 AI 혹은 다른 AI로 코드를 리뷰하면 로직이 허술한 경우가 있다. 이에 대한 수정 작업도 이 버그 수정 카테고리로 볼 수 있을 듯
5. 기능 구현 (feat)
버그 수정과 더불어 많이 할 작업인 기능 구현. 생각하던 기능을 테스트로 실행해보고, 일반화하는 것에 성공하고 최종 PR을 올릴 때는 꽤 기분이 좋다. 단점은 이후 작업을 하면서 프로젝트의 로직이나, 아키텍쳐를 변경해야해서 만든 기능을 삭제하거나 변경해야 할 때 일을 두번하게 된다.
그렇다면 애초부터 아키텍쳐를 잘 설계하면 되는 것 아님?
이라는 생각을 할 수 있는데, 여태 꽤 많은 개발 서적들을 봤지만 개발 프로젝트 아키텍쳐 잘 설계하는 법은 대부분 명쾌하게 설명해주기보단 그냥 경험치가 쌓여야 한다. 로 얘기 했던 것 같다. 또한 프로젝트가 온전히 scratch에서 만든다면 덜 하겠지만 여러 다른 라이브러리를 활용하기 때문에 이에 맞추어 변경도 필요함.
변화가 없는 것이 좋은 설계인가 혹은 변화를 감당 할 수 있는 것이 좋은 설계인가? 어렵다
6. 리팩토링 (refactor)
솔직히 리팩토링은 기능 구현 보다 더 재밌던 것 같다. 이 이유에 대해서 생각해보면 일단 엉망으로 만든 스파게티를 정갈하게 다듬는 쾌감도 있고, 이를 통해 이후 작업에서의 생산성이 올라간다 !! 라는 자기 최면을 걸 수 있다.
또한 신규 기능이나 버그 수정 처럼 코드에 더하고 빼는 것이 아닌, 프로젝트 내 코드 재배치에 가깝기 때문에 이에 비해 (상대적으로) 머리를 덜써도 된다. 책임 없는 쾌락이 아닐까.
그렇다고 리팩토링을 아무때나 할 수 있는 것은 아니고, 이전의 문서 작성처럼 기능이 어느 정도 안정화 되어 있을 때 코드의 가독성이나 유지 보수를 위한 분리, 혹은 불필요한 코드와 로직을 제거하여 퍼포먼스 향상 등을 목적으로 할 수 있다. 나중에 없어질 수 있는 기능에 너무 힘 주면 좀 그렇다. 물론 리팩토링 잘못해서 돌아가던게 안 돌아가면 그때부터는 다시 버그 수정임.
7. 예시 구현 (feat)
내가 했던 프로젝트는 방법론을 일반화한 “프레임워크”이기 때문에 이 방법론을 적용하면 이러한 케이스를 구현할 수 있어 라는 예시들이 필요하다. 이를 위해 nhyris 프레임워크를 이용해서 하나씩 구현하는 작업이 꽤 많았다. (plotly에서 graph gallery를 구현하는 것을 예시로 생각하면 편함)
이는 새로운 기능은 아니지만, 프로젝트를 활용해서 사용할 수 있어야 하고 동시에 이 갤러리를 구현하지 못하는 경우 이를 위한 기능 추가가 필요하기 때문에 작지만 커질 수 있는 작업이었다.
내 경우 예시는 63개 였는데, 절반 정도는 문제 없이 쉽게 구현되었고 (덕분에 시간 급하게 커밋 해야할때 잘 썼다) 절반 정도는 구현을 위해 기존의 아키텍쳐를 비틀어야 하는 경우였다.
결과적으로는 프레임워크에서 사용할 수 있도록 예시 코드로 변경해서 추가 했던 것들을 전부 드랍하고 대신 레퍼런스의 코드를 프레임워크에서 바로 사용할 수 있도록 로직을 변경했다. 날린게 아깝긴 하지만, 메데타시 메데타시
그 외 팁
커밋 금지
리포지토리의 설정에서 바로 커밋을 허용하지 않도록 변경하는 것이 정말 좋다. 즉, 무조건 PR을 통해서만 리포지토리에 업데이트 할 수 있게 하는 것인데 이렇게 하면 3가지 장점이 있다.
릴리즈 노트를 생성하기 편함.
코드 리뷰가 가능함 (특히 코파일럿 / Gemini 같은 AI를 코드 리뷰에 활용할 수 있다)
브랜치 / PR 에 기반한 작업에 익숙해진다. 이는 굳이 git 명령어까진 안 쓰더라도 github desktop 이나 vscode의 UI 작업으로도 충분하다고 생각한다.
커밋 이름
commitlint라는 애용하는 서비스가 있는데, 커밋 메세지를 조금 더 잘 작성할 수 있게 하는 내용이다. 물론 항상 쓰는 것은 아니지만 update code 처럼 깃허브에서 기본으로 제공하는 커밋 메세지보단 feat: code 처럼 작성하면 조금 더 멋있어보이는 것 외에도 나중에 리뷰할 때 조금 더 도움이 된다.
Commitlint Online - lint commit messages online
기술 문서
깃허브 리포지토리에 기술문서를 작성하는 방법은 정말 다양한데 역시 Quarto가 최고다. qmd 라고 하는 markdown 기반의 방법을 쓰기 때문에 크게 어렵지 않고, render 같은 관리도 별도의 yml 파일로 관리하기 때문에 어렵지 않다. 코드와 실행 결과도 바로 넣을 수 있기 때문에 프로젝트에서 R이나 Python를 사용한다면 더 도움이 되겠지만 nhyris 처럼 사용하지 않는 기술문서 자체로도 충분히 역할을 한다. Quarto는 특히 brand.yml이 추가 된 다음 부터는 스타일 꾸미기도 훨씬 편리해졌다고 생각함.
매일 커밋
매일 커밋을 하는 것은 꽤 어렵다. 꾸준함과 나태함의 문제도 있지만, 그 것만큼이나 작업할 이슈(백로그)가 없는 경우도 문제가 된다. 뭐라도 쥐어짜야 하는데 개발과 더불어 창작의 고통을 경험할 수 있는 좋은 기회가 되고, 일 잘하는 PM, PO가 얼마나 대단한지 알 수 있다.
바이브 코딩
꽤 자주 말하지만 나는 바이브 코딩 찬성, 찬성을 넘어 찬양파다. 그러나 AI를 완전히 신뢰하는 것은 어렵다. 환각의 문제는 너무 당연하고, IDE와 불완전한 연동으로 인해 코드 수정에 오류가 날 수 있다. 예를 들면 A 줄 다음 B 를 추가한다고 해서 하라고 했는데 A 줄 다음에 A 줄과 B 줄을 (2번) 추가하는 등.
아 그리고 자꾸 코드에 주석 넣을때 한글을 쓰거나, 로그 찍을때 이모지를 사용하거나 (os에 따라 이모지가 깨짐) 아무튼 시키지 않은 짓을 자꾸 해서 난처했음
이슈 매니지먼트
아 이거 추가해야지 ~ 이거 문제 인데? 라고 해서 이슈를 작성하는데, 이때 자세히 쓰지 않으면 며칠 지나서 무슨 말인지 까먹는다. 같은 문제가 다시 발생하기 전까진 알 수 없어서 어쩔 수 없이 issue close.
작업 범위
작업 범위라는 표현은 조금 애매한 단어인데, 어디까지 작업해야 하는가?를 결정하는 것이 꽤 중요하다. 당연히 많은 것을 구현할 수록 좋지만, 모두가 사용하는 것이 아닌 이런 것도 있다 정도의 수준이라 만들어놔도 별로 사용할 일이 없을 (것 같을) 때를 위해 우선 순위가 낮은 것을 작업 하는 것은 정말로 가성비가 떨어진다. 어느 범위까지의 작업이 적절한 우선 순위인가를 구분하는 것은 개발자도, AI도 아직은 어려워하는 영역인 것 같다.
브랜치 네이밍 룰
앞서 바로 커밋 말고, PR로만 작업할 수 있도록 설정을 권장했는데 이를 위해서는 사소한 작업에도 브랜치를 만들어서 작업해야한다. 이때 어려운 것은 브랜치 이름 정하기, 나는 그래도 혼자 하는 프로젝트였기 때문에 똑같은 브랜치를 PR 병합 이후 삭제, 그리고 재사용해도 상관이 없지만 여러 사람이 한다면 어려울 것 같다. 작업 내용이 이슈와 1:1 매칭이 된다면 깃허브 이슈 페이지에서 제공하는 create a branch를 쓰는 것도 좋지만. 그렇지 않은 경우 이 브랜치 네이밍 룰이 없다면 고생을 좀 할 것 같다.
매일 커밋 종합 회고
당연하게도 프로젝트의 속도가 엄청 빨라진다.
내가 루틴하게 일하는 스타일은 아니라서 습관이 생기진 않았고, 대신 듀오링고나 분재겜 과제하듯 꼬박꼬박 할 수 있는 것은 좋았다.
이슈들을 전부 털어버리면 다음날 할 것이 없어서 이슈를 억지로 짜내야하기 때문에 전부 털지 않고 천천히 했는데, 덕분에 번아웃이 오지 않았던 것 같다. 적당히 일하고 적당히 살자 ~
한 달이면 대충 바닥에서 프로젝트가 완료 되는데, 만약 100일이나 1년 매일 커밋을 한다면 꽤 큰것도 만들어 낼 수 있지 않을까?
딴소리
Daily DevBlog가 툭하면 터져서. WHILE 0124를 만들었음. 6월동안 내부 테스트해보고 오픈 할 건데 이 뉴스레터나 추후 이 뉴스레터 프로젝트 운영, 아니면 뉴스레터 제작에 관심 있으면 알려주삼

매일 커밋 한달의 효능

댓글