코드에도 미니멀리즘 — "Less, but better"를 상태와 의존성에 적용하기

“Less, but better(적게, 그러나 더 좋게).” 디터 람스의 이 말을, 저는 물건과 화면에만 적용되는 원칙이라 생각했어요.

그런데 개발을 배우며 알았어요.

코드야말로 이 원칙이 가장 잘 통하는 곳이더라고요.

React를 배우다 파생 상태에서 크게 데였어요. 화면에 보이는 값은 다 useState에 담아야 하는 줄 알고 filtered·count를 전부 상태로 뒀거든요.

그랬더니 상태끼리 어긋나고 동기화 코드가 계속 늘었어요.

배운 원칙은 하나였어요.

state는 이것만 있으면 나머지가 전부 계산되는 최소한의 진실이면 되고, 나머지는 거기서 뽑아낸다.

filtered를 상태에서 빼자 동기화 코드가 통째로 사라졌어요.

이게 정확히 미니멀리즘이에요.

덜 가지는 게 아니라 진짜 필요한 것만 남기는 것.

옷장에서 이거 하나면 나머진 조합으로 되는 기본 아이템만 남기는 것과 똑같더라고요.

디자인 시스템을 만들 때도 같은 감각이었어요.

Tailwind·UI 라이브러리를 다 접고 플레인 CSS + custom property로 갔거든요.

가장 안 변하는 공통분모에 짓고 싶어서요.

의존성은 편하지만 짐이기도 해요.

라이브러리 하나를 들이면 그 버전·업데이트·호환성이 전부 내 몫이 되니까요.

그래서 “이거 꼭 필요한가, 브라우저 기본으로 안 되나?”를 먼저 물어요.

요즘 CSS가 워낙 좋아져서 예전엔 라이브러리로 하던 걸 이제 순수 CSS가 해내는 경우도 많고요.

덜어낸 만큼 가벼워지고, 오래가요.

메모이제이션에서도 배웠어요.

”느려질까 봐” useMemo를 여기저기 미리 붙였다가 코드만 장황해졌죠.

최적화는 측정해서 느린 곳만 하는 건데, 저는 추측으로 미리 감쌌던 거예요.

미니멀리즘의 언어로 옮기면 아직 필요하지 않은 걸 미리 들이지 않는 것.

”언젠가 쓸지도 몰라서” 남겨둔 물건이 집을 채우듯, “언젠가 느려질까 봐” 붙인 추상화가 코드를 채워요.

진짜 필요해질 때 넣어도 늦지 않고요.

이건 제 도구 취향과도 이어져요.

기능 많은 풀패키지보다 덜어낸 걸 고르는 것.

코드에서도, 도구에서도, 화면에서도 저는 같은 사람인 거죠.

다만 덜어냄은 게으름이 아니라 판단이에요.

뭘 남기고 뭘 뺄지 아는 건 더 많이 이해해야 가능하거든요.

상태를 줄이려면 무엇이 파생인지 알아야 하고, 의존성을 줄이려면 기본 기능을 알아야 해요.

덜어내려면 오히려 더 알아야 하는 거죠.

Less, but better는 화면 밖에서도 통했어요.

최소한의 상태, 가벼운 의존성, 이르지 않은 추상화.

코드도 결국 덜어낼수록 좋아지더라고요.

그리고 그 덜어냄은, 뺄 것을 아는 눈에서 나와요.