ADR(Architecture Decision Record)에 대하여
2024. 06. 27.
ADR(Architecture Decision Record)은 프로젝트의 아키텍쳐에 대한 결정 사항들에 대한 기록을 뜻한다. 여기서 관점에 따라 architecture decision을 아키텍쳐에 영향을 주는 온갖 결정들이라고 넓게 보기도 하는 것으로 보아, 꼭 엄밀하게 정의된 것이라고 생각하지는 않아도 괜찮은것 같다. 각각의 기록은 하나의 문서로 이루어져있고, 상황마다 다르겠지만 보통 한 프로젝트 내에서 ADR의 포맷은 쭉 일정하게 관리된다. ADR에는 어떤 주제에 대한 결정을 해야 하는지, 어떤 선택지를 고려해봤고, 각 선택지마다 어떤 장단점이 있으며, 이 중에서 왜 특정 선택지를 택했는지에 대해 명확하게 기술되어 있어야 한다. 그렇다면 ADR을 왜 쓰는 것일까? ADR을 사용하면 다음과 같은 장점이 있겠다.
- 명확한 의사소통. 앞선 설명을 보면 알겠지만, ADR의 내용을 보면 어떤 결정을 얼마아 세심한 고민 끝에 내렸는지(혹은 대충 뭉개고 넘어갔는지) 알 수 있다. 작성자 및 의사결정을 하는 사람들은 독자를 위해 명확하게 결정을 내리고 이를 글로 잘 정리해야 하고, 독자는 ADR을 읽으면서 명료하게 프로젝트에 대해 이해할 수 있게 된다.
- 히스토리 로깅. ADR은 현 프로젝트 구성원들 뿐만 아니라, 이후에 들어올 구성원들을 위한 것이기도 하다. 새로운 구성원이 추가되었을때 ADR을 읽으면 어떻게 프로젝트가 현재의 상태가 되었는지 쉽게 파악할 수 있다.
위의 설명만 보면 ADR은 여러 사람들로 이루어진 프로젝트에서 그 진가가 발휘되는 것처럼 보일 수 있다. 그런데 돌이켜 생각해보면, 열심히 구글링해서 찾은 무언가를 활용해서 기능을 개발했다가 며칠 뒤에 다시 돌아와서는 이게 내가 짠 코드인가 흐린 눈을 하고 다시 처음부터 코드를 읽는 경험을 다들 해보지 않았던가? 이렇게 보면 며칠 뒤의 나와 현재의 나는 분리된 존재라고 생각하는 것도 무리가 아닌 것이다. 그러므로 지금의 나는 미래의 나를 위해서 현재 어떤 결정을 했는지 잘 기록해둘 필요가 있고, 이때 ADR을 매우 유용하게 활용할 수 있다.
그런 의미에서 이 사이트를 만든 과정에 대한 ADR을 새로운 카테고리를 파서 관리해볼까 한다.