클린 아키텍처 (5.결론)

선긋기를 잘하고 최대한 모든 결정을 최후의 순간에 할 수 있게 미룬다.

 

이 한마디를 해주기 위해서 긴 여정이 있었다.

물모든 책들이 주제 하나를 말하기 위한 길고 지루한 여정들이 있지만 즐거운 여정이었다.

대부분의 책들은 지겨움이 스며드는데 최근(4~5년)에 읽은 책 중에는 총균쇠 급으로 모든 내용이 흥미진진했다.

 

자바 프로젝트를 할때는 springframework에 얽매이고, jpa에 얽매여서 모든 것을 만드는 방식.

우리의 아키텍처상 entity는 jpa에 강결합되어 있다.

그나마 요즘 유행하기도 하고, 운영/유지보수를 해보니 확실히 생산성이 극대화되는 것을 느끼게 되는 frontend기술의 발전.

우리의 아키텍처상 이마저도 결국 react나 vue에 종속되어 있다.

 

많은 고객들에게는 본인이 이미 구축한 (혹은 어디서 주워들었던) 환경에 맞춰서 많은 것들이 제약되고 시작되는 프로젝트들.

 

나에게 결정권이 있을때마저도 규모와 배포, 유지보수 여부에 따라서 언어와 framework는 고정해버리고 시작한다. (DB는 그나마도 최후의 순간까지 미룰 수는 있다.)

 

마침 지금(20230430) 하고 있는 프로젝트가 안드로이드에서 센서와 연동하여 진행하는 것인데,

중간에 firmware 개발자가 끼어 있다.

정훈님에게

"우리가 개발하는 것들은 AI 개발자가 훨씬 가깝고, firmware 개발자가 하는 일은 hardware랑 동일하다고 보시면 됩니다."

라고 했었는데,

밥 형께서 firmware는 software 라고 하셨다.

이 형님은 특히 hardware를 운영하기 위한 software의 삶부터 살아 오신 분이기에 이 단어가 각별하신 듯 하다.

내가 firmware를 개발한 적은 단 한번도 없지만, 몇 차례 같이 엮인 프로젝트는 해왔었는데,

단 한번도 그들이 software를 만든다고 생각한 적이 없었다.

그들의 구현 기법도 문제지만 나도 그런 제약된 생각을 한 것은 잘못이다.

그리고 너무 당연한 software단어를 접하고 hardware와 싸움을 해본적이 없기에 밥형이 존경스럽다.

 

운동을 하면서 "정석"의 중요성을 느꼈다.

결국에 아사리판이 되는 농구나 야구에서도 결국에 "정석"을 제대로 아는 사람에게는 짓밟힌다.

 

개발에서도 결국에는 변화를 지배하기 위해서는 "정석"을 제대로 알아야하는데 운동보다 어렵다.

누군가가 나에게 운동은 아마추어이고 개발은 프로니까 그런 것 아니냐고 했지만 모르겠다.

 

슬슬 거래처 관리가 귀찮아지고 있어서 관리 프로그램을 만들어보려고 한다.

모든 결정을 최후의 최후까지 밀어보면서 진행해보고자 한다.

어떻게?

전혀 모르겠다.

일단 해보면 알게되겠지.

 

이런 설레임이 너무 좋다.