Next.js 13에서 새로 도입된 React Server Components 관련 공부를 한건 나쁘지 않았지만 딱히 업무에 쓸모는 없었다. 면접관 업무를 볼 때 App Router 관련 어설픈 대답들을 알아보는 수단 정도로만 종종 사용되었다. 제품에도 당장은 도입할 생각이 없고, 일단 원리만 잘 파악해둔 다음 많은 이들이 먼저 뛰어가 지뢰를 밟고 폭사(?)하고 나면 그 때 천천히 진입해도 늦지 않다고 생각한다. 오히려 롱테일보다는 파레토 법칙(80:20)에서 이야기 하는 ‘전체 결과의 80%를 차지하는 20%의 원인’들이 잘 관리될 수 있도록 집중하는 것이 필요한 단계가 아닐까.

회사 코드 베이스에 박혀 있는 스파게티 컴포넌트 때문에 고통을 받았다. 그리고 그 스파게티는 예전에 만들어졌던 스파게티 위에 내가 추가한 사리가 얹어져 있었다. 이제는 투덜대기만 할 게 아니라 개선안과 앞으로 코드 레벨에서 추구해야 할 원칙에 대한 답을 내놔야 할 것 같다는 생각이 들었다. 하지만 어떤 코드를 개선안으로 내놓아야 할지는 고민이었는데, 일단 Composition(합성), Polymorphism(다형성), Inversion of Control(제어의 역전), Open-Closed Principle(개방-폐쇄 원칙), Separation of Concerns(관심사의 분리), Compound Components(컴파운드 컴포넌트) 같은 개념들이 답을 내리는 과정에서 많은 도움이 되었다.

제품을 관리하기 위한 여러가지 도구들에 대하여 생각했다. 제품 품질의 하한을 지키는데 매번 많은 노력이 들어가고, 비효율적인 방법으로 하루종일 VoC를 처리하느라 기능 개발에 시간을 쓰지 못하고, 도구를 매번 재발명하느라 퇴근이 늦어진다면 한번쯤 멈춰서서 생각해볼 필요가 있지 않을까? 엔지니어라면 자신의 업무를 윤택하게 만들어줄 연장통에 대한 갈증이 있어야 하는게 아닐까 싶었다.

비용은 혁신이고, 혁신은 비용이다. 우리 프로덕트가 좋지 않은 이유는 작은 단위의 훌륭함을 비싼 비용을 지불하여 만들어야 하기 때문이다. 유려한 애니메이션이 좋은 거라고 생각 못하는 사람은 없지만 대부분의 상황에서 정해진 리소스 풀 내에서 그 좋음에 대해 지불할 수 있는 예산이 없으므로 그 유려함은 실상 존재하지 않는 것과 같다. “우리 애가 마음만 먹으면 잘하는데…”와 다를 바가 없는 것이다.

회사 코드 베이스에서 비즈니스 로직 관련하여 여러가지 분기들이 많은데, 이 조건들이 리액트 컴포넌트 곳곳에 박혀 있어서 전체적인 그림을 파악하기 힘들었다. 단순히 파악이 어려운 것이 아니라, 정책이 변경될 경우 변경 대상에서 누락되는 경우나 예상하지 못한 사이드 이펙트로 인한 불안감을 구성하는 코드 구조라는 생각이 들었다. 그렇다고 비즈니스 로직을 별도의 문서로 정리하는 것은 SSOT(Single Source Of Truth)를 위배하는 이중장부를 만드는 행위로 볼 수 있다. 또한 진실의 원천이 두 개가 됨으로써 각각을 업데이트 하는데 들어가는 비용을 증가시키는 방법이기 때문에 좋지 않다. 가장 이상적인 상황은 비즈니스 로직이 최종 결과물인 코드로 표현되고, 스스로 “소리치는 아키텍처”가 되는 것이다.

이 과정에서 React로 모든 로직을 작성하는 것은 꽤나 비효율적이기도 하고, 때때로 부당하다는 생각을 하게 됐다. React는 근본적으로 UI Renderer이기 때문에 React에서 제공하는 API나 권장하는 패턴들은, 좋은 비즈니스 로직을 작성하는 방법은 아닐 수 있다. 최근에 이와 관련하여 https://martinfowler.com/articles/modularizing-react-apps.html 라는 좋은 글을 발견했는데, 내가 고민해온 거의 모든 내용들이 한 큐에 잘 정리되어 있다. 비즈니스 로직을 클래스로 분리하고, 이것들을 잘 엮어 모델 형태로 활용하며, UI 로직이 필요할 때 Hooks, React 렌더링 사이클과 연동시키는 방법을 사용해보고 싶다. 가능하다면 각각의 비즈니스 로직에 유닛 테스트를 작성하고 싶다. 결과로서의 테스트가 아니라 과정으로서의 테스트를.

만약 우리가 Todo 앱을 짜야 하는데 화면이 아니라 프로그램이 가져야 하는 논리적인 동작들에 대한 구성을 먼저 작성하고, 최종적으로 화면을 보여줘야 하는 단계가 왔을 때서야 React 컴포넌트를 만드는 방식으로 코드를 짠다면 어떤 느낌이 들까? 사실 그렇게 하지 말아야 할 이유는 1도 없다. 다만 어색하기도 하고, 무엇보다도 React를 벗어나서 어떻게 코드를 짜야 할지에 대한 (알고 있는) 규범이 없기 때문에 선뜻 손이 나가지 않을 뿐이다. React는 우리의 고향이었지만, 모든 로직을 React 컴포넌트 안에서 해결해온 것은 문제라는 생각이 든다. 두렵더라도 한번은 그것을 떠나야만 더 멋진 모습으로 다시 돌아올 수 있을 것만 같다.

모든 것들을 부정하고 처음부터 다시 쌓아 올릴 수는 없다는 사실을 잘 알고 있다. 지금의 내게 그럴 능력이 없기도 하고. 하지만 현실에 제약이 존재하기 때문에, 제약이 없을 때 내가 할 수 있는 최선이 무엇인지에 대해 생각해두지 않을 의무가 사라지는 것은 아니다. 날마다 점진적으로 제품으로부터 개선할 수 있는 포인트를 발견하고, 경험으로부터 인사이트를 뽑아내기 위해 끊임없이 노력하고 있다. 그것들이 항상 준비되어 있어야만 불시에 찾아오는 적절한 시기에 적절하게 시작될 수 있다고 믿고 있다.

이 모든 것들의 실행은 팀원들의 인정과 동참을 이끌어내는 것으로부터 출발한다고 생각한다. 어떤 초인도 모든 일을 혼자 진행할 수는 없고, 심지어 나는 초인조차 아니다. 꽤나 어릴적에 스치듯 지나쳤던 https://youtu.be/Itz8iaORQXM?si=T-L9GvMuO1FS-MUP 리더십 - 팔로워십 관련 영상을 찾아 종종 다시 꺼내어 보고 있다. 개발 문화는 일종의 무브먼트(Movement)라고 생각한다. 공감과 참여란 높은 관여도를 필요로 하는 행동이기 때문에 시작하기도 어렵고, 계속해서 유지시키기는 더더욱 어렵다. 일단은 첫 언덕을 넘는 일이 지금의 내게 있어 가장 큰 챌린지로 느껴진다. 그래도 하나씩 실마리를 찾아나가고 있으니 천천히 도전해봄직한 주제다.

마티스는 이렇게 말한 적이 있다고 한다. “나는 내 노력을 드러내려고 하지 않았고 그 전에 그림들이 봄날에 밝은 즐거움을 담고 있었으면 했다. 내가 얼마나 노력했는지 아무도 모르게 말이다.” 하지만 나는 그런 위인까지는 못되기 때문에 내가 어떤 노력과 고민을 하고 있는지 꾸준히 전시해야만 한다. 나의 노력과 성취를 스스로 알아봐주기 위한 수단이다.

에반게리온 시리즈 극장판인 ‘엔드 오브 에반게리온’ 후반부에 붙은 부제는 <진심을, 너에게 まごころを、君に>다.