수집, 처리, 결과 계층은 요구 사항에 따라 다양한 로그 및 모니터링 시스템에 매핑할 수 있습니다. 이를테면 수집 계층에서 파일 로그는 S3, 이벤트 로그는 커스텀, 모니터는 구글 클라우드 작업 및 리대시Redash로 매핑되는 식입니다. 이와 달리 결과 계층은 데이터독DataDog 이벤트 로그와 이벤트 모니터에 매핑될 수 있습니다.

로그 기록 및 모니터링을 고려한 보편적인 파이프라인을 사용하는 경우라면 파이프라인은 로거와 모니터가 DAG 코드와 결합된 DAG 메서드로 구현됐을 겁니다. 이로 인해 작성할 코드의 양이 많아지고 불안정하며 재사용이 어렵고, 단일 책임 원칙Single-Responsibility Principle, SRP, 중복 배제Don’t Repeat Yourself, DRY, 개방-폐쇄 원칙open/closed principle 등의 설계 원칙을 어겨 파이프라인이 전체적으로 불안정해지고 신뢰하기 어려워집니다. 모니터링과 로깅 말고 다른 기능도 같은 방식으로 작업한다면 데이터 품질/검증, 보안/개인 정보 등 다양한 기능 블록에서 비슷한 문제를 겪을 것입니다.

문제가 유사하다면 그 유사성이 공통 주제를 드러내는 지표가 될 수 있습니다. 이에 더해서 구현 간에는 결합도를 낮추고 응집력을 높여야 합니다. 그리고 이런 맥락에 따르면 디자인 패턴(<GoF의 디자인 패턴>(프로텍미디어, 2015) 참고)을 고려해야 할 이유는 충분합니다.