커밋수를 올리려고 의도한건 아니지만, 어느새 1000 커밋을 달성하게 되었다.
이 포스트는 1000커밋 달성 기념으로, 프로그래밍에 대한 어려움과 커밋수에 대한 개인적인 견해를 담고 있습니다.
언제 프로그래밍 하는가
개발하고 싶을때 개발한다. 학생이라는 굉장히 유리한 위치에서 모든 프로젝트를 "학습" 목적으로 시작한다. 그렇기에 내가 만들고싶은 프로젝트만 선택할 수 있고 결정도 다 혼자 한다. 실패에 대한 책임도 없다. 심지어 프로젝트를 중간에 중단하고 다른 프로젝트로 피봇하는것도 편하다. MVP 가설 검증도 재미있게 결정할 수 있고 마감기한에 시달릴 필요도 없다.
그런 자유로운 배경을 바탕으로 해야만, 오래하고 또 즐겁게 프로그래밍할 수 있지 않을까. 프로그래밍을 "일"로 접근하기 보다는 "취미"로 접근하는게 능률 향상에서도 도움이 된다고 생각한다.
빈 캔버스에 그림 그리기
프로그래밍은 빈 캔버스에 그림을 그리는 행위와 유사하다. 아무것도 주어져있지 않지만, 각각의 기능의 세부 구현요소와 관계, 의존성 요소를 생각해가며 유기적으로 개발해야 한다. 보통 프로그래밍을 수학처럼 딱딱하고 정형화된 과정으로 생각하는 사람도 있지만 사실은 그렇지 않다. 많은 부분에서 융통성을 발휘해야하는 부분도 있고 이전과는 다른 패러다임을 적용하거나 Low Level로 내려가야 하기도 한다.
구체적으로 표현하자면 DRY 원칙이 이에 해당한다. 원칙이라고 해서 잘 짜여진 틀을 기대하지 말자. DRY 원칙은 반복하지 말라(Don't Repeat Yourself)의 줄임말이다. 원칙이라는 이름이 무색하게 추상적이기만 하다.
그러나 DRY 원칙은 소프트웨어 개발의 핵심이다. 반복되는 코드를 줄이면 개발 생산성과 코드 가독성을 동시에 높일 수 있다.
문제는 언제 반복을 줄일거냐는거다. 앞서 말했듯 소프트웨어 개발은 유기적이다. 한 번에 설계해서 개발을 끝내는게 아니라 지속적으로 기능을 추가하고 예외나 분기점도 발생한다. 또한 프로젝트 코드를 분할해서 마이크로서비스로 전환이 필요하기도 하다. 이런건 예측할 수 없다. 예상만 가능하다. 언제가 될지 모르지만 기술부채를 줄이기 위해서는 끊임없이 리팩토링 해야한다.
이에 관해서는 잘 정리된 글이 있어 첨부한다.
https://velog.io/@gomjellie/The-Wet-Codebase
프로그래밍은 창조적인 행위다. 그러면서도 여러 원칙을 담고 있다. 보통 창조적인 작업은 제대로된 규칙이 없는 상태를 떠올리기 마련인데, 소프트웨어에서의 원칙은 규칙이 존재한다. 다르게 말하면 답이 있다. 그러나 소프트웨어에서 말하는 답은 상황에 따른 해답이지, 정답이 아니다. 세부 개발 사항은 각 개발자들이 결정해야 한다.
커밋수에 집착하지 말자
필자도 커밋수에 집착하던 순간이 있었다. 2020년 이었는데, 어떻게든 스트릭(연속 커밋 일수)을 끊게 하지 않으려고 개발했던 경험이 있다. 이를 채우려 더미데이터를 추가하기도 하고 꾸준히 한다는 명목으로 몇 일간 지속했지만 잘 안됬다. 당시 나이가 중학생이었는데 뭐... 그럴 수 있다고 생각한다. (성인이면 문제있는거라고 생각한다.)
이후로 개발에 본질에 집중했다. 소프트웨어 개발이 주는 본질적인 즐거움을 추구하기로 마음먹었다. 어떤 제품을 만들든 그 제품이 지닌 정량적인 가치보다는 정성적인 디테일이 집중했다.
그러다보니 개발이 재미있더라.
본질에 집중하면서
소프트웨어 개발의 본질은 "누군가에게 가치있는 경험이나 서비스를 제공하는 행위" 라고 생각한다. 순수하게 프로덕트 관점이다. 물론 사람에 따라 다른 본질을 가질 수 있지만 적어도 필자는 이렇게 정의했다.
반면 소프트웨어 개발의 본질이 아닌건 다음과 같다.
- MAU 수치와 같은 단순 카운팅 집계
- 수익
1번은 상황에 따라 도움이 될 수 있다. 동기부여 관점에서나 사용자 이탈률과 같이 수정해야할 부분을 파악하고 개선하는데 도움이 된다.
2번은 예외다. "우리나라에서 돈돈 거리는거~" 꼰대 마인드라 생각한다. 그러나 적어도 돈에 집중하면 본질을 잃는다고 믿는다. 경험에 따르면 돈을 좀 벌어볼려고 외주 개발을 해본적이 있었다. 클라이언트마다 요구사항이 전부 다 달랐고 이걸 맞추는데 스트레스 받았었다. 자의식 따위는 들어갈 틈이 없었다. 개발자의 생각보다 클라이언트의 생각이 중요하다는 사실을 일찍 깨달았다. 물론 돈은 훌륭한 동기부여가 된다. 하지만 그때 잠깐뿐이다.
돈은 따라온다. 니즈를 충족시키는 소프트웨어와 현명한 마케팅이 만나면 소프트웨어의 가치가 올라가고 사람들은 돈을 지불해서 자신의 니즈를 충족시킨다.
즉, 소프트웨어 자체에 집중하는게 아닌 모든 행위는, 결과의 품질도 떨어지고 개발자 본인도 지속하지 못했다. (고집인가..)
그 중고등학생분들 수학 영어 하세요
솔직히 중학생때만 해도 저 사실을 믿지 않았다. 놀라운건, 수학은 프로그래밍 능률을 올릴뿐 아니라 어디든 쓰이게 되어 있다. 라이브러리 쓰면 끝이라 생각하면 오산이다. 라이브러리 찾는 시간에 구현하는게 빠르다. 심지어 지원하는 라이브러리가 없을 수 있다. 그럴땐 여러 공식 찾아가면서 만들어야 한다.
영어는.. 깃허브 이슈 작성하고 외국 사람들과 문제 없이 소통하고 빠르게 읽고 적용하기만 하면 된다. 학교에서 배우는 영어로는 택도 없다. 영어는 실제로 적용해봐야 안다.
덧붙이자면, 고등학교 레벨에서 배우는 수학 영어를 배우라는게 아니다. 학문적 수학, 실용적 영어를 배우는걸 추천한다. 고등학교 레벨에 안주하지 말고 본질을 생각하자. 절대 문제푸는게 다가 아니다. 수학은 선형대수 수치해석 정도는 개념이라도 공부해놓는게 좋다. 학부에서 배우겠지만, 고등학교 수학보다는 재미있으니 미리미리 알아두자.
자부심
오늘날 소프트웨어 산업은 메이저다. 전 세계 빅 테크 기업이 시가총액 순위권에 있으며, 제조업의 경우에도 소프트웨어를 다루는게 필수가 된 세상이다. 소프트웨어가 들어가지 않은 산업은 없으며 그 예기는 즉, 소프트웨어를 다룰 수 있는 사람은 어느 산업에든 일자리가 있다고 말할 수 있다. 소프트웨어 개발자들은 자부심을 가지자.
