원사이트
커밋 메세지를 먼저 생각해보자는 생각을 적어보자는 생각 💭Github는, 원격 코드 저장소이면서 동시에 협업 플랫폼입니다. 쉽게 말하면 내가 작성한 코드를 반영하는 외부 저장소입니다. 데스크톱이나 랩톱에서 코드가 날아가더라도, 외부 저장소에 내가 작성한 코드가 기록되
커밋 메세지를 먼저 생각해보자는 생각을 적어보자는 생각 💭

Commit?
Github는, 원격 코드 저장소이면서 동시에 협업 플랫폼입니다. 쉽게 말하면 내가 작성한 코드를 반영하는 외부 저장소입니다. 데스크톱이나 랩톱에서 코드가 날아가더라도, 외부 저장소에 내가 작성한 코드가 기록되어 있으니 크게 염려할 일이 줄어들겠죠.
commit이라는 명령어를 통해 변경 사항을 로컬, 즉 내 컴퓨터에 저장합니다. 최종적으로 push 명령어를 통해 해당 변경 사항을 원격 저장소에 반영하게 되지요. 이때 변경 사항에 대한 간략한 설명을 추가하게 되는데, 이를 "commit message"라고 부릅니다.
커밋을 하게 되면, 위 이미지처럼 깃허브에서 날짜에 해당하는 박스에 초록색 불이 들어오는 모습을 볼 수 있습니다. 많은 개발자들이 성실함을 위한 시스템으로써 '1일 1커밋'을 하고, 이러한 행위를 '잔디 심기'라고 부르기도 합니다.
물론 저는 단순히 커밋을 올리는 것보다는, 블로그에 과정을 기록하는 것이 주는 의미가 더 크다고 생각해서 '1일 1커밋'에 동참하고 있지는 않습니다. 오늘 이야기와도 크게 상관없는 주제고요.

단점
최근 스스로의 단점에 대해 생각해 봤습니다. 사실 단점이라기보다는 취약점에 가깝습니다. 어떠한 Task나 Todo가 주어지면, 초반에는 잘 하는가 싶다가도 중반부터 뭔가 흐지부지되는 느낌을 많이 받았습니다.
그냥 "그렇구나" 할 순 없죠. 개발자는 코딩하는 사람이 아니라 문제를 해결하는 사람이기 때문입니다. 곰곰이 생각해 보니 성미가 매우 급한 사람이었던 거랬죠! 밥도 빨리 먹고, 술도 빨리 마시고, 심지어 유튜브도 배속으로 보는!
생각이 너무 빠르게 튀어서, 지금의 행위에 온전히 집중하지 못하고 다른 과업들까지 생각하다 보니, 스스로 뇌의 과부하를 만들어 냈습니다. 정말 literally, 스스로 불러온 재앙에 짓눌리는 녀석이었던 것!
다시 앞으로
보통 커밋 메세지는, 작업을 하다가 "어느 정도 했으니 커밋 하자!"라는 생각이 들 때 작성하곤 합니다. 아! 보통이라고 말할 순 없고, 제가 그래 왔습니다. 성미가 급하고 생각이 빠르게 튀는 사람은, 그 생각에 울타리를 둘 필요가 있다는 결론을 도출하고야 말았더랬죠. 그래서 커밋 메세지를 미리 작성하게 되었습니다.

커밋 할 내용을 미리 지정하고, 실제로 완료한 시점에 이모지를 추가하는 방식입니다. 사실 할 일을 미리 적어두고 완료한 일들을 지워간다는 점에서는, 투두리스트와 크게 다를 바 없습니다. 다만 저렇게 포스트잇에 하나하나 적어놓고 완료하는 과정에서, 너무 많은 것을 예상하지 않게 됩니다. 과도한 시뮬레이션은 병에 가깝죠.
"성미가 급한 게 단점인가?, 성격을 바꾸어야 하나?"라는 식의 문제 해결 접근을 시도하기도 했으나, 사람은 특별한 일이 없고서는 절대 바뀌지 않는다고 믿는 쪽입니다.
"성격이 급한 것이 문제다."에서 "성격이 급해서 작업의 순서가 바뀌는 것이 문제다."로 문제 정의를 다시 하게 되었습니다. 그러면 더 이상 성격은 잘못이 없고, 작업 순서만 보장해 주면 되는 방향으로 문제 해결의 흐름이 바뀌게 되지요.
결론
커밋이라고 해서 단순히 프로그래밍 작업에 국한된 이야기는 아닙니다. 개인적인 공부를 할 때나, 아니면 전혀 다른 일을 할 때에도 비슷한 논리로 '순서'에 목숨을 걸려고 합니다. 실제로 마인드를 바꾼 뒤로 생산성이 크게 향상했음을 느낍니다.
문제가 발생하면 자기 비하를 할 것이 아니라, 문제를 다시 정의해 보고, 그에 맞는 해결책을 모색하는 태도가 바람직하겠습니다. 개발자로서도, 개발자 딱지를 뗀 개인으로서도 그게 더 좋을 것 같다는 생각을 요즘에 좀 해봤슴미다.
유난스러운 성격으로 고통받는, 우연히 이 글을 읽게 될 분이, 되도록 안녕하시길 바랍니다. 저는 이제 다음 커밋 메세지를 완료하러 가보겠습니다.
More to read
Amazon VPC Architecture 이해하기
새로운 프로젝트를 기획하며, 개발에서 무엇을 가장 먼저 고민해야 하는지 다시 돌아보게 되었습니다.한때는 프론트엔드가 모든 설계의 출발점이라고 믿었습니다. 유저가 무엇을 보고, 어떤 흐름에서 머무르고 이탈하는지에 대한 이해 없이 서비스를 만든다는 건 불가능하다고 생각했기
'원사이트'프론트엔드 관점으로 알고리즘 이해하기
오랜만에 방법론에 관한 글을 쓰게 되었습니다. 최근 상황은 이렇습니다. SSAFY에서는 하루에 엄청난 양의 알고리즘 문제들을 과제로 수행하게 됩니다. 그 과정에서, '구현력'이 매우 떨어진다는 생각이 들었습니다. 완전히 어려운 문제라면 '아쉬움'이라는 감정조차 느끼지
SubnetVPC 설계의 시작: IP와 Subnet
반복되는 루틴 속에서 얻은 안정감을 발판 삼아, 이제는 기술적 스펙트럼을 넓히기 위한 개인 프로젝트에 착수하고자 합니다.이번 프로젝트의 목표는 단순한 포트폴리오 구축을 넘어, 실제 서비스 수준의 블로그 시스템 구현과 다국어 처리 적용 등 실무에 가까운 역량을 한 단계