새로운 팀이 가진 문제점
FSD: Feature Sliced Design
FSD는 횡단 관심사 분리 목적의 정리법으로 보인다. 이는 값비싼 함수 호출을 양산하는 방식으로 소프트웨어 설계 및 디자인의 안티패턴이다. 아키텍처의 목적인 의존성 제거를 위한 경계 만들기는 분명 아니다. 디자인의 목적 중 안전하고 유연한 소프트웨어 개발을 담보하는 OCP를 반영하지도 않는다. FSD는 형용하자면 ‘곤도 마리에’씨가 설파하는 예쁜 수납의 기술이고 이는 가정용, 혹은 사무실 책상용이다. 소프트웨어 엔지니어링을 수납장 정리하듯이 하면 양말을 어느 칸에 정리했는지 아는 사람만이, 어느 수납칸을 빼야 연결된 속옷 수납칸이 나오는지 아는 사람만이 개발할 수 있는 시스템이 된다. 곤도 마리에씨가 갑자기 팀에서 사라진다면? 모든 수납 케이스를 다 빼서 그곳에 무엇이 들어있는지 일일이 다 파악하는 수밖에 없다. 새로운 팀원이 들어온다면? 속옷칸에 양말을 넣기 시작할 것이다. 1, 2년 된 트렌디한 방법론이 만드는 수납 구조로 코드를 쌓아가면 그 코드는 1, 2년 짜리이다. 50여 년 쌓인 소프트웨어 엔지니어링의 정수인 아키텍처, 디자인 패턴에 맞는 설계 및 디자인을 적용해 오래가는 집을 만들어야 한다. 쌓여있는 건축 자재들을 아무렇게 이어 붙여 기능하는 것을 보이도록 만들어 두었다. 이제 집을 만들어갈 설계를 할 차례이다. 자재들은 설계를 하며 연결을 다 뜯어내야 한다. 설계가 끝나고 자재들 연결이 다 뜯어지면 설계에 따리 신속히 집을 만들면 된다. 이렇게 하면 당연히 속도는 담보된다.
덧,
FSD가 잘못된 아키텍처인 가장 큰 이유는 개념적 포함관계가 역전되어 있기 때문이다. 애플리케이션의 개념적 아키텍처 경계는 다음과 같다.
엔티티 > 유스케이스, 요청모델, 응답모델 > 컨트롤러, 프레젠터, 뷰모델 > 뷰
프론트엔드 개발의 저수준 매커니즘은 다음과 같다.
API 인터페이스 > 상태관리 시스템 > UI 라이브러리
개발 시 해야 할 일은 저수준의 매커니즘을 아키텍처 구성요소에 적절히 분류해 넣는 일이다. 표준화된 아키텍처 구성요소와 그 경계를 두고 일부 진영이 효과적이다고 '마케팅'하는 표준이 아닌 '정리방법'을 아키텍처보다 우선하여 반영해 불필요한 해석 레이어를 만들 필요는? 글쎄, 없다고 본다.
프레임워크는 매커니즘이다. 매커니즘은 아키텍처 구성요소 중 일부의 필요에 따라 부분적으로 사용하는 도구이다. 저수준 매커니즘에 아키텍처를 넣으려 하면 표준화된 아키텍처 경계가 사라진다. 아키텍처 경계는 사라지고 코드는 '마케팅 된 정리방법'을 따라 사방팔방 흩어져 결국 응집도 낮고 결합도 높은 하나의 거대한 '코드덩어리'가 양산된다. 흔히들 이런 '코드덩어리'를 '스파게티코드'라고 한다. 복잡도는 기하급수적으로 높아져 있고 유지보수 비용 역시 기하급수적으로 높아진다. 새로운 기능을 넣거나 기존 기능을 수정하는데 엄청난 리소스가 낭비된다. 이런 코드덩어리는 임계점을 지나면 더 이상 확장/변경이 아예 불가능해진다. 성능은 바닥으로 떨어져 프로세스가 죽는 일이 허다해진다. 결국 이런 코드덩어리는 버려진다. 경험상 2년이면 이런 코드덩어리가 양산되기에 충분한 기간이다. 어떤 개발자도 이걸 바라지는 않을 것이다. 하지만 만나온 대다수의 개발팀을 둔 조직이 이런 상황을 맞이하고 있었다.
정상과학의 생성은 동일한 철학적 줄기를 가지는 이론들이 함께 모여 과학자 집단에서 널리 사용되고, 그 과정에서 수 없이 많은 반증을 견뎌내며 그 유효성을 검증한다. 이러한 과정을 통해 이론은 '법칙'의 지위를 가지게 되고, 결국 정상과학이 된다. 응용과학인 컴퓨터 사이언스의 역사는 튜링머신이 등장한 1945년 이후부터라고 보인다. 약 80년 정도의 역사를 가진 학문이다. 80년 간 쌓여온, 그리고 유효성을 검증하여 정상과학의 지위를 부여받은 이론은 현재로선 객체지향의 개념적 토대와 그 활용법 말고는 존재하지 않는다. 함수형은 아직 독립 이론으로 불리기는 어렵다고 보인다. 객체지향의 개념적 토대와 실제적 유용성을 바탕으로 일부 편리함을 덧붙여 사용되는 정도이다.
정상과학을 뒤집을 만큼 반증사례가 가득 쌓이고 새로운 이론이 옳다는 증거가 가득 쌓여 대다수가 기존의 법칙을 버리고 온전히 독립적인 이론으로 갈아탈 때 새로운 정상과학을 맞이할 수 있다. FSD는? 과학자의 시선으로 볼 때 이건 이론도 뭣도 아니다. 정상과학을 논할 필요도 없다. 그냥 Next.js 사용자들이 만들어낸 잠깐 흘러가는 트렌디한 폴더정리방법 정도에 불과하다.
Reference copy
React Hooks를 순수 함수로 사용하지 않고 레퍼런스를 자유롭게 함수 내에서 가져와 사용하고 또 이를 반환하게 하는 방식이 일상으로 사용되고 있다. 레퍼런스를 아무 데서나 가져오고 아무 데서나 반환하게 하는 건 코드 내에서 컨텍스트를 제한하지 않아 잘못된 코드가 나오기 쉬워진다. 순환참조, 참조 끊김, 숨은 의존성, 응집도는 약하고 결합도는 강해지는 코드들. 이런 방식은 코드 복잡도를 늘려 변경과 확장비용이 크게 늘어난다. 한 곳을 수정하면 예상치 못한 곳에서 예상치 못한 시기에 사이드 이펙트가 발생한다. 순수 함수 내 참조는 모두 제거하고 순수함수가 아닌 Hook들은 모두 제거해야 한다. Mixin 패턴은 쉽게 아무 곳에나 접근할 수 있게 해서 개발자에게 단기적으로 무언가 되는 것처럼 보이게 해서 꿀맛을 주지만 중장기적으로는 개발을 포기하게 만드는 주요 요소가 된다. 설계를 마친 후 자재들을 적합한 곳에 쌓아 올려야 하는데 자재들이 이상하게 연결되어 있으면 안 된다. 차근차근 연결을 다 뜯어내서 설계 이후 준공을 준비해야 한다.
그래서
잠시간 관망했지만 이제 시니어로서 참전해야 할 시기가 된 것 같다. 믿을 수 없는 무지에 맞서 공학적 원칙을 고수해야 한다.
