인디 계열은 기본적으로 버티컬 슬라이스 하라는 이야기를 많이 하던데 그것도 개인 프로젝트의 방향성에 따라서 다르듯


방법론도 애자일이니 워터폴이니 데브옵스니 RAD니 하지만 결국 프로젝트에 맞게 개인의 재량에 맞게 조직의 요건에 맞게 수정해야하는거고


데이터 아키텍쳐 패턴도 거의 비슷하고


코딩 패턴 또한 매한가지.


반대로 말하자면 패턴, 아키텍쳐를 쓰지 않기 위해서 또 패턴과 아키텍쳐를 배우게 됨


하지만 결국 또 따지고보면 OOP니 DOP니 원칙에 따르면 자연스레 일정한 개념이 나오게됨.


실제로 그게 패턴이며 개발방법론이고 결국 어떤 원칙에 따르면 수많은 사람들이 거의 대부분은 어떠한 형태를 띄게 되는데


그걸 정리해놓은 것뿐이니 그걸 굳이 맹신할 필요가 없는듯


따라서 실제적으로 아키텍쳐 패턴, 코딩 패턴 또한 결과적으로 선대 프로그래머들의 작업방식을 구체화 시켜서 남겨 둔 것뿐


그거에 집착해서 교조화될 필요가 없는듯.


OOP니 DOP, AOP 등등 결국 어떤 것을 지향하느냐에 대한 관점적 차이일뿐이고 그런 관점에 따라서 당연히 만들어지는 구조가 다를뿐.


그리고 어떤 지향점, 패러다임이 맞느냐라는게 아니라 그냥 자기 제반 상황을 고려해서 유동적으로 선택하는 것뿐.


패턴과 아키텍쳐는 결국 어떤 관점을 지향하느냐에 따라 나오는 재사용가능한 솔루션일뿐. 효율적이게 도와줄 순 있지만 항상 정답은 아니라는 개념으로 접근해야하는게 맞는듯.


다만 그렇다고해도 아예 그런것들을 배우지 않아야하는가도 아닌것이


반대로 패턴과 방법론을 알아야만이 패턴을 쓰지 않아야 할 상황, 패턴을 써야할 상황을 구분 할 수 있고


아키텍쳐에 대해서 생각해봐야만이 그게 자주 나타나는 형상의 한 종류일뿐 무조건 집착할 대상이 아니라는 걸 깨닫게 되는듯.


요즘은 그런 생각을 한다.