아키텍쳐 의사결정 기록(ADR)

아키텍쳐 의사결정 기록이라고 혹시 들어보셨나요? 그야말로 설계 결정 기록들을 쌓아나가는 것을 의미합니다. 일을 하다보면, 특히 역사가 오래된 프로젝트에 참여하게 되면 많이 하는 이야기가 "도대체 이때 왜 이렇게 한거야" 인것 같습니다. 사실 그때 당시때는 그게 최선이였을지도 모르고 혹은 진짜 그냥! 결정했을 수도 있습니다. 늦게 조인한 사람은 그저 전에 일하던 사람에게 물어보거나 혹은 commit history를 보며 대충 짐작하는 수밖에는 없을것입니다. 레거시 코드는 욕먹으라고 있는 것은 아니죠. 지금의 프로젝트를 있게한 어쩌면 완벽하진 않지만 가장 중요한 초석일지도 모릅니다. 또, 기술은 계속 발전하니 당연히 오래된 코드는 지금부다는 성숙할 수 없을 거에요. 개발자에게 중요한 것은 기술 부채를 줄여나가면서 개선해 나가서 더욱 좋은 설계를 만들어 나가는 능력일 것입니다. 하지만 그 기술 부채를 해결하기 위해서는 당시의 결정과 상황을 이해할 수 있어야 합니다. 내가 지금 바꾸려는 결정이 이미 과거에 도전 해보았고 맞지 않은 솔루션일 수 있으니까요. 그렇기 때문에 우리는 기록해두어야 합니다. 당시의 맥락, 고려해보았던 옵션들, 결정에 대한 예측 결과들 그리고 그걸 리뷰했던 사람들의 의견. 이렇게 쌓인 ADR은 시간이 흘러 새로운 혹은 더 발전된되는 아키텍쳐가 필요한 경우 그 결정에 도움이 됩니다. 과거의 학습을 통해 현재의 통찰력을 얻는 것이죠. 또 기록을 남기기 때문에 책임감이 생기고 리뷰어들 역시 더 적극적으로 참여하게될 수 있습니다. 그냥 말로 "DDD"로 할께요~ 라는 말을 들었을 때와 DDD가 필요한 이유와 고려한 것들을 한 페이지에 정리한다면 동료들도 훨씬 농도있는 리뷰를 해줄 수 있을 것입니다. 이렇게 문서를 중심으로 이야기 하다보면 특정 한명이 설계를 결정하는 것이 아닌 팀이 모두가 설계에 참여할 수 있게 됩니다. 따라서, 어떠한 결정이 내려졌을 때, 불만의 여지가 훨씬 적고 모두의 공감대를 형성할 수 있습니다. - AWS ADR 예제 - https://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/architectural-decision-records/appendix.html - UK 정부 AWS 클라우드 아키텍쳐 ADR - https://github.com/alphagov/govuk-aws/tree/main/docs/architecture/decisions - GeekNews ADR을 써야하는 이유 - https://news.hada.io/topic?id=2665 - 아키텍트 서적으로 유명한 Design it! 국내에서는 "개발자에서 아키텍트로" 로 번역된 책의 저자인 마이클 킬링이 과거 IBM 에서 ADR을 활용하여 일을 했을때 좋았던 점 + ADR에 대한 실용적인 팁들을 팟캐스트에서 이야기 해주어 ADR을 이해하는데 더 도움이 될 것 같습니다 :) - https://techleadjournal.dev/episodes/113/