우아한스터디-4주차-스터디-회고

만들면서 배우는 클린 아키텍쳐 스터디 4주차 회고

빌드 아티팩트

실무에서 아키텍처 경계를 강제하기 위해 가장 현실적이고 실용적인 방법이 바로 메이븐(Maven)과 그레이들(Gradle)과 같은 빌드 아티팩트를 사용하는 방법입니다.

저는 단일 모듈 프로젝트만 혼자서 진행하다보니 이점이 잘 이해되지 않아서 이에 대해 질문을 하였습니다.

그래서 친절하게도 스터디 리더님이 직접 본인의 인텔리제이 화면을 공유해주시면서 설명을 해주셨습니다.

프로그램이 커지고 복잡해질수록 많은 모듈이 생기는데 각각의 모듈에 대한 의존성을 각 모듈의 build.gradle에 명시해놓으면 한 모듈에서 다른 모듈에 접근하여 다른 모듈의 클래스를 사용할 수 있습니다.

즉, 한 모듈에서 다른 모듈을 사용하려면 빌드 스크립트에 명시를 해야 하기 때문에 이게 진짜 필요한 것인지 한번 더 고민하게 된다고 책에서는 말하지만 실무에서는 고민없이 빌드 의존성을 추가하는 사람도 많다고 합니다.

그래서 주의할 점이 팀과의 협의없이 독단적으로 빌드 아티팩트에 의존성 추가(이게 나쁜 의미의 지름길로 갈 수도 있음)하는 경우입니다.

또한 시간이 부족해 문제를 빨리 해결하기 위해 지름길을 선택할 때(클린아키텍처를 망치지만 당장에 쉽게 문제를 해결할 수 있기 때문에) 문서화(ADR = Architecture Decision Records)를 하지 않으면 나중에 다른 개발자들이 이를 알기가 어려워 집니다.

깨진 창문 이론

어떤 것이 좋은 상태에 있으면 인간은 본능적으로 그것을 망치는 것을 원치 않지만 이미 망가져 있으면 좀 더 망치는 것에 대해 죄책감을 느끼지 않기 때문에 이 좀 더 망치는 것이 누적되어 나중에는 엄청나게 망쳐지게 됩니다.

즉, 이를 프로그래밍에 적용해보면 협의없이 빌드스크립트에 독단적으로 의존성 추가나 지름길을 선택하고 문서화하지 않으면 시간이 지나감에 따라 서서히 프로그램의 아키텍처가 무너지게 됩니다.

어차피 아키텍처는 이미 엉망인데 좀 더 망치더라도 아무도 신경쓰지 않습니다.

그래서 아키텍처가 한 번 무너지기 시작하면 깨진 창문 이론으로 인해 나중에는 더 빠른 속도로 더 심하게 아키텍처가 망하게 됩니다.

즉, 그래서 지름길을 사용할 때 반드시 문서화를 하고, 팀원 간의 충분한 협의를 해야 하며, 상황에 따라서는 지름길을 사용한 방법을 다시 정상적이고 클린 아키텍처 스타일의 방법으로 리팩터링해야만 좋은 아키텍처를 계속해서 유지할 수 있습니다.