작년 말부터 개인 Repository를 위한 템플릿을 만들어 보기로 했습니다.
사건의 발단은 Disquiet에서 본 하나의 댓글이었습니다.
(현재는 원글이 삭제되었습니다.)
댓글 원본
이 댓글은 사실 저를 대상으로 한 댓글은 아니었는데, 여기서 영감을 받아 코드 외의 부수적인 요소를 템플릿으로 만들고, 자동화해 보자는 생각이 들었습니다. Repository를 짜임새 있게 구성하고 README를 잘 작성하기만 해도 그 자체로 완결성이 높아지고 추가적인 작업이 줄어드는 효과를 기대할 수 있기 때문에 가치 있다고 생각했습니다.
하지만… 작업은 생각보다 만만하지 않았고 중간에 핵심을 놓치면서 1달 반 정도의 기간 동안 꽤나 헤맸습니다. 이에 관해 겪었던 시행착오들을 적어 보려 합니다.
일단 만들어 보기
저는 주로 GitHub에 공개 코드를 저장하기 때문에 주 목표는 GitHub Community Standards를 저만의 방식으로 정립하는 것이었습니다. 아무것도 모른 채로 여러 소스를 참고해 기본적인 형식을 완성시켰습니다.
그런데 2번째 Repository에 템플릿을 적용할 때 문제가 떠올랐습니다. 각각 쓰는 언어도 다르고, 현재 활발하게 업데이트하고 있는 경우와 그렇지 않은 경우도 구분이 필요했습니다. 단순히 템플릿 하나를 만들고 붙여 넣는 문제가 아니라는 것을 깨달았습니다.
케이스 나누어 보기
그래서 두 번째로 시도한 것은 Repository를 분류하는 것이었습니다. 고민 끝에 2가지 기준을 정했습니다.
- 현재 배포 여부 (⭕◦❌)
- 코드 유지보수 (지속 관리◦최소한만 관리◦유지보수❌)
이렇게 기준을 나누니 모두 분류가 되는 것 같았습니다.
다시 힘내서 열심히 작업을 하고 README도 더 체계적으로 구성했습니다.
하지만, 진행하다 보니 또 걸리는 점이 생기기 시작했습니다.
- 미세하게 경우의 수를 벗어나는 예외사항이 생겼습니다.
- 성격상 작업사항을 계속 여러 번 확인하는 편이지만, 그걸 감안해도 공수가 너무 많이 들어갔습니다.
무언가 잘못되고 있다는 것을 느꼈습니다.
무엇이 문제인가
기존 작업에서 가장 큰 문제점은 관리 포인트가 너무 많다는 점이었습니다. 왜 이렇게 되었는지 곰곰이 생각해 보았더니 다음과 같은 원인들이 나왔습니다.
- 스스로 복잡도를 늘려 문제를 만들고 있었습니다.
- 분류를 2 * 3 = 6가지로 나누어 놓으니 자연히 신경 쓸 요소가 늘어났습니다.
- 과도한 주석과 설명, 모든 경우의 수를 한 파일에 담아내려고 한 결과 오히려 가독성이 매우 떨어졌습니다.
- 한글과 영어를 모두 템플릿에 담아내려는 것도 욕심이었습니다.
- 템플릿 자체가 확장성이 떨어지고 변경에 너무 취약했습니다.
- 자동화를 좁은 의미로 생각하고 있었습니다.
- 예를 들어, 지금까지 템플릿 파일을 모두 수동으로 동기화하고 있었는데 이것을 자동화 영역에 넣지 않고 있었습니다. 돌아보면 이 부분이 상당한 지분을 차지하고 있었습니다.
- 불필요한 것도 신경을 쓰고 있었습니다.
- 오래된 Repository까지 모두 안고 가려하고 있었습니다.
- 삭제할 대상은 삭제하고, 남겨 둘 것들도 Archive로 만들면 굳이 추가 템플릿을 만들 필요가 없었습니다.
다시 작업하기
위와 같이 문제점을 분석하고 다시 작업을 시작했습니다. 크게 바뀐 점은 다음과 같습니다.
- 단일이지만 확장 가능한 템플릿을 만들고 있습니다.
- 불필요한 관리 포인트는 과감하게 삭제◦병합하고 있습니다.
- Repository 파일을 동기화시킬 수 있는 방법을 찾아 적용했습니다.
- 그 외 복잡도가 높았던 부분을 최대한 단순하게 만들었습니다.
- 템플릿에서 한글을 걷어내고, 주석과 설명도 반드시 필요한 곳만 사용하고 있습니다.
아직 작업 초기이지만 불필요한 작업이 확연히 줄어들었고, 바꾼 README도 좀 더 세련되어 만족도가 높았습니다.
저의 작업 내용은 아래에서 확인하실 수 있습니다.