> [!date] published: 2025-04-24 ## 📌 오늘의 주제 - Git - 실무에서 cursor 활용하기 - 좋은 프론트엔드 개발자란 ## 💡 배운 것 ### Git git의 stage에 대해서 잘 이해하고 있으면 좋다. 데뷔 멤버(변경 파일)들을 올리는 무대(stage)라고 이해하면 이해하기 쉽다. stage에 올린 데뷔 멤버들에 대한 기록을 남기는 것이 바로 커밋. > 아래 내용이 짱 신기했다. 진짜 몰랐음... (svn을 사용해 볼 일은 거의 없겠지만...) 비슷한 svn과 다른 git의 차이점이 바로 변경에 대한 **"결과"** 를 저장하고 있다는 것이다. svn은 diff를 저장하고 있기 때문에 복구를 위해서는 다른 원본 파일에서부터 하나씩 거슬러 올라가야 하므로 특정 시점으로 돌아가는 것이 좀 어렵다는 특징이 있다. 하지만 git은 그 결과 (그러니까 현재 무대에 올라간 데뷔조의 사진)을 저장하고 있는 것이기 때문에 바로 사진 그대로를 만들면 되므로... 특정 시점으로 이동하는 것이 쉽다! 변경 결과 자체를 저장하긴 하지만 변경되지 않은 파일은 저장하지 않고 "변경되지 않음"으로 저장하기 때문에 용량 문제도 없다... > git에 대해서 좀 더 알아보고 싶다면 .git 폴더를 뜯어보면 재밌답니다~! 유림님이 느끼시기에 **느좋 개발자**분들은 PR의 커밋도 깔끔하다고 하셨다. 이 때 쓸 수 있는게 **interactive rebase**. cursor나 vscode의 git lense 익스텐션을 쓰면 쉽게 커밋을 합칠 수 있다.(squash) 근데 여기는 살짝 이견이 있었는데 (by 캡팡님) 이렇게 커밋을 정리해주는 방법도 있지만. 이렇게 정리가 필요할 정도로 커밋이 많다면 PR을 쪼개는 것도 방법이 될 수 있지 않겠냐고 하셨다.... (요게 에프랩 멘토님도 말씀하셨던 부분!!) (또 다른 이견...) interactive rebase하는 방법도 있지만 `reset --sort`나 `reset --mixed`를 이용해서 다시 차근히 커밋을 하는 방법도 있다는 얘기가 나왔는데, 이 방법은 덜 번거롭긴 하지만 무조건 파일 단위로 변경 사항을 커밋해야 한다는 단점도 있었다. **어쨌든 PR을 올렸을 때 커밋을 좀 간결하게 만들 필요는 있다는 것!** > [!question] 실무에서 쓰는 머지 전략? > > 토스 프론트엔드 챕터에서는 무조건 스쿼시를 쓰도록 룰을 맞춰두었다. 네이버에서는 스쿼시를 쓰지 않는다. 어디까지나 컨벤션의 문제인 것 같다. ### cursor 커밋 메시지 작성해줍니다. (이건 지금도 너무 잘 쓰고 있는 기능이라...) PR body도 만들어줍니다. (이건 몰랐다...! 채팅에서 git을 참조할 수 있었다.) ### 좋은 프론트엔드 개발자란 이거 사전 조사때 요즘 고민중인 내용이라고 적었었는데, 생각보다 빠르게 답변을 들을 수 있었다...! > **유림님:** > > 프론트엔드 개발자는 특히 다양한 분야에서 강점을 보일 수 있는 포지션이라고 생각한다. 어떤 사람은 도메인 지식에 강점이 있어서 PM, Designer와 소통을 잘한다는 강점이 있을 수도 있고, 어떤 사람은 UI/UX에 강점을 가지고 있을 수도 있고, 어떤 사람은 커뮤니케이션을 잘해서 제품의 성공까지도 이끌 수 있는 강점이 있을 수도 있고. > > 내가 잘하는 부분을 찾아서 그것을 갈고 닦을 생각을 하는 것이 좋은 것 같다. 정말 다양한 분야에 강점을 가진 프론트엔드 개발자가 많기 때문에 6각형이 되려다 오히려 자신의 모양을 잃고 힘들어 질 수 있다. > > 중요한 것은 나의 모양을 잘 찾기! > **캡팡님:** > > 프론트엔드 개발자가 가져야 할 역량이 있긴 하다. (물론 신입이 이 역량을 한방에 기를 수는 없고) > > - 설계 > - 클린코드 > - 프로젝트 툴링 > - 테스팅 > - 언어나 프레임워크 > - 기능 구현 속도나 근성 > > 요런 것들이 있긴 할텐데, 이 항목들을 다 잘하는 사람은 드물고, 빠르게 기를 수 있는 역량은 아니다. 자기가 잘 하고 흥미 있는 것을 찾아서 한개씩 꾸준히 길러가는 것이 중요한 것 같다. 프로젝트와 회사에 도움이 될 수 있는 자기 강점을 찾고 그것을 잘 발전시키고 어필하는 것이 중요하다는 결론을 내렸다...! ## 📝 생각과 메모 2024년 오픈스소 컨트리뷰션 아카데미에 지원할 때에는 실제로 오픈소스에 기여하는 경험을 쌓기 위해서 지원한거였는데, 이번에 참여형에 지원하면서는 프로젝트 경험 보다는 멘토링 프로그램에 좀 더 기대를 했었다. 그래서 chromium 프로젝트와 함께 지망 순위를 고민하다가 next.js 프로그램을 1지망으로 선택 한 것이고. 첫주차 시간부터 고민하고 있었던 "좋은 프론트엔드 개발자란 무엇인가"에 대한 답변을 들을 수 있어서 좋았다. 단순히 답변을 들은 것 뿐 아니라 좀 어떻게 방향을 잡아야 할지도 좀 가닥이 잡힌 느낌이 들었다. 요즘 계속 이도 저도 아닌 것 같아서 고민이 많았는데, 내가 잘하는 것이 무엇인지 다시 한번 생각해봐야겠다는 마음이 들었다. 그냥 요즘 그냥 기능 개발만 할 수 있는 개발자보다는 좀 더 한단계 나아간 개발자가 되고 싶다는 생각을 계속 하고 있었는데, 올리는 PR에서도 느낌 좋은 개발자가 될 수 있겠구나...! 하는 생각이 최근에 확신이 되어 가고 있다. 뭔가 아마추어에서 프로가 되려면 코드를 잘 짜는 것은 너무 당연하고, 커뮤니케이션(개발자는 코드로 말한다...!)에도 신경을 써야 하고, 그것이 티가 나는구나... 하는 생각이 들었다. 그리고 이건 내가 오프라인 발대식에 참여하지 못해서 이제서야 든 생각인데,,, 사실 OSSCA 지원할 때에는 멘토님이 누군지가 그렇게 큰 지원동기가 아니었는데, 뭔가 내 동년배 프론트엔드 개발하는 사람이라면 모르는 사람이 드물 진유림님이랑 캡틴판교님과 줌 회의실에 같이 있으니까 소규모 팬미팅 당첨된 느낌이었다.... 뭐 나는 그냥 보고만 있었지만 왠지 성덕된 느낌,, 들어서 중간 중간 계속 웃겼다. 이게 뭐지 메모 - [브라우저의 작동 방식 \|  web.dev](https://web.dev/articles/howbrowserswork?hl=ko) - [중요 경로 이해  \|  web.dev](https://web.dev/learn/performance/understanding-the-critical-path?hl=ko) - [Server Side Rendering \| Cracking Next.js](https://cracking-next.vercel.app/docs/server-side-rendering)