콘텐츠로 이동

사이트 업데이트를 로깅하는 방식

맥락 및 문제 설명

사이트 제작을 위해 어떤 고민을 했고 어떤 결정을 했는지 어딘가에 기록해두는 것이 좋을까? 링크드인에 포트폴리오 사이트 제작 소식을 알린 뒤 덧글로 제작 과정을 어떻게 설명하는 것이 좋을까 고민하다가 주된 결정들에 대해서 로깅해두면 앞으로 비슷한 상황에서 잘 활용할 수 있겠다는 생각이 들었다.

결정 동인

  • 꾸준히 로깅을 하기 쉬웠으면 좋겠다. 즉, 로그 관리가 간편했으면 좋겠다.
  • 어떤 결정들이 있었는지 보기 편했으면 좋겠다.

후보안

  • 깃헙 커밋으로 관리(현재의 상황 유지)
  • 깃헙 이슈 및 PR로 관리
  • ADR 문서 작성

선택안

"ADR 문서 작성"을 선택했다. 왜냐하면

  • 사이트 내에 ADR 문서를 공개하면 뒤에 숨겨져있던 github repo까지 보여주지 않아도 된다.
  • ADR 문서 작성에 대한 경험치를 더 쌓는 것이 앞으로 개발 프로젝트들을 진행함에 있어서 도움이 될것으로 판단된다.

후보안의 장단점

깃헙 커밋으로 관리(현재의 상황 유지)

  • Good, 현재 시스템을 유지하는 데에 있어 추가적인 품을 더 들이지 않아도 된다.
  • Neutral, 커밋을 통한 로깅은 나 외의 다른 사람들이 보고 이해하기 쉽지 않을 수 있다.
  • Bad, 커밋에는 내가 선택하지 않은 선택지에 대한 고민과 기록이 존재하지 않는다.

깃헙 이슈 및 PR로 관리

  • Good, 이후 이슈와 PR들만 봐도 어떤 주제를 다뤄왔는지 알 수 있으니 충분한 로깅의 역할을 한다.
  • Good, github에 이미 구현되어 있는 시스템을 활용하는 것이므로 새로운 관리 방식을 구축하지 않아도 된다.
  • Neutral, 개발자들은 이슈 및 PR의 구도만 보고 사이트 관리 방식을 어느 정도 이해할 수 있다.
  • Bad, PR이 사이트 업데이트의 기준이 될 수 있도록 관리 방식을 잘 짜야 하며, 여기에 품이 든다.

ADR 문서 작성

  • Good, 프로젝트에 대해 큰 의사결정을 할 때마다 이에 대해 원하는 수준으로 정보를 정리해둘 수 있다.
  • Neutral, 공개 여부와 별개로 어딘가에 작성해두는 것이 가능하다. 그리고 일반인들이 알아보기에도 어렵지 않다.
  • Bad, 새로 관리 시스템을 갖춰야 하며 여기에 품이 든다.