"취향은 주관적이다"라는 말, 프론트엔드 개발자 사이에서도 꽤 편하게 통용됩니다. 디자인 리뷰에서 "이건 취향 차이니까"라고 하면 논쟁이 끝나거든요. 그런데 솔직히, 사용자 입장에서 8px 여백과 12px 여백의 차이는 '취향'이 아니라 가독성과 시선 흐름의 문제입니다. 최근 GeekNews에서 화제가 된 「창작자를 위한 미적 감각」 아티클은 바로 이 지점을 정면으로 찌릅니다. 좋은 디자인에는 객관적 기준이 있고, 취향이란 훈련을 통해 발전하는 실천적 역량이라는 것이죠. 디자인을 계속할수록 과거의 취향이 열등했음을 인식하게 되는 과정 자체가 객관적 기준의 존재를 증명한다는 논증은, 매일 컴포넌트를 리팩터링하면서 "3개월 전 내가 짠 이 코드 뭐지?"를 경험하는 우리에게 묘하게 와닿습니다.
이 글이 제시하는 좋은 디자인의 14가지 속성—단순함, 시대초월성, 올바른 문제 해결, 암시성, 재설계—을 코드 레벨로 번역하면 어떤 모습일까요? 사실 이건 flexbox 하나로 해결되는 문제가 아니라, 컴포넌트 아키텍처 전체의 설계 철학과 맞닿아 있습니다.
단순함은 컴포넌트의 단일 책임이다. Velog에 올라온 React 컴포넌트 기초 글이 보여주는 Button, Heading, Card의 조합 예시는 교과서적이지만 핵심을 정확히 찌릅니다. 하나의 컴포넌트가 하나의 일만 한다는 원칙은 "장식 대신 실질"이라는 좋은 디자인의 단순함 원칙과 정확히 같은 구조입니다. 피상적 장식의 범람 대신 소수의 신중히 선택된 구조적 요소에 아름다움이 의존해야 한다는 원칙—이걸 코드로 옮기면, 200줄짜리 모놀리식 컴포넌트에 useEffect 5개를 때려넣는 대신, 역할별로 분리된 합성 가능한(composable) 컴포넌트 트리가 됩니다. 초보 개발자가 하나의 컴포넌트에 모든 로직을 구겨넣는 건, 초보 디자이너가 장식적 곡선으로 빈약한 구조를 위장하는 것과 본질적으로 같은 회피입니다.
올바른 문제 해결은 데이터 페칭 패턴에서 드러난다. @nimir/references 라이브러리를 만든 개발자의 고백이 인상적이었습니다. REST 마이크로서비스에서 티켓을 가져오고, 담당자를 가져오고, 담당자의 팀을 가져오고, 팀 리더를 가져오고... Promise.all과 useQueries의 스파게티가 쌓이는 과정은, 가스레인지 다이얼을 일렬로 놓는 것과 같은 "잘못된 문제에 대한 단순한 답"이었습니다. 진짜 문제는 개별 fetch의 최적화가 아니라, 참조 관계 자체를 선언적으로 정의하고 배칭·중복 제거·캐싱을 한 번에 해결하는 것이었죠. source를 한 번 정의하고 필드의 참조 관계를 선언만 하면 10단계 중첩까지 타입 안전하게 해결되는 이 패턴은, "해결책뿐 아니라 문제 자체를 개선"하라는 원칙의 코드 버전입니다. 이 라이브러리 도입 시 번들 사이즈가 걸리긴 하겠지만, null 체크 보일러플레이트 수십 줄이 사라지는 DX 개선은 무시할 수 없어 보입니다.
시대초월성은 렌더링 전략의 선택에서 시작된다. Next.js의 SSG와 SSR 비교 글은 짧지만 본질적 질문을 던집니다. 블로그나 문서 같은 정적 콘텐츠에 SSR을 적용하는 건, 유행에 휩쓸려 불필요한 복잡성을 추가하는 것과 같습니다. 빌드 타임에 한 번 생성된 HTML을 재사용하는 SSG는, "미래에도 멋져 보일 것을 만들면 그 매력은 유행이 아닌 실력에서 비롯"된다는 원칙과 닮아 있습니다. Lighthouse 점수에서 TTFB, LCP 모두 SSG가 압도적으로 유리한 건 우연이 아닙니다. 렌더링 전략 선택은 기술적 트렌드가 아니라, 콘텐츠의 본질—얼마나 자주 변하는가, 사용자별로 달라야 하는가—에서 출발해야 합니다. 이게 "올바른 문제를 해결한다"는 것이고, 이 판단이 시대를 초월합니다.
암시성은 컴포넌트의 합성 가능성이다. 좋은 디자인은 사용자에게 레고처럼 조합할 수 있는 기본 요소를 제공한다는 원칙, 이건 그대로 Headless UI 패턴이나 Radix Primitives 같은 디자인 시스템 철학입니다. 건축가가 작성한 프로그램을 실행하듯 살게 만들지 않는다는 것—컴포넌트 개발에서는 children과 render props, Compound Component 패턴으로 소비자에게 조합의 자유를 주는 것과 같습니다. 기획자가 의도한 하나의 시나리오만 강제하는 컴포넌트는 재사용성이 바닥을 치고, 결국 비슷하지만 미묘하게 다른 복제 컴포넌트가 양산됩니다.
재설계를 받아들이는 태도가 코드 품질을 결정한다. Leonardo의 소묘에 한 선을 맞추기 위해 다섯 여섯 번의 시도가 있었듯, Porsche 911의 아이코닉한 뒷모습이 어색한 프로토타입의 재설계에서 나왔듯, 좋은 컴포넌트도 첫 구현에서 완성되지 않습니다. 여기서 로딩 스켈레톤 넣으면 어떨까요? 하는 세심한 제안, 이 useEffect 의존성 배열 정리하면 리렌더링 3번은 줄겠는데... 하는 투덜거림, 이게 재설계입니다. 오픈소스 소프트웨어가 버그가 적은 이유가 버그 가능성을 인정하기 때문이라는 지적은, PR 리뷰에서 "이건 좀 추한데요"라고 말할 수 있는 문화가 코드 품질의 전제 조건이라는 의미입니다.
결국 이 모든 논의가 수렴하는 지점은 하나입니다. 추함에 대한 불관용. Figma에서 볼 때는 괜찮았는데 실제로 구현하면 어색한 그 미세한 틈, Promise.all 체이닝이 3단계를 넘어가면서 느껴지는 그 불쾌함, SSR이 필요 없는 페이지에서 의미 없이 서버를 태우는 그 비효율—이걸 "뭐 돌아가니까" 하고 넘기지 않는 태도가 좋은 디자인의 시작입니다. 전문가가 되면 "이건 편법이다, 더 나은 방법이 있을 것이다"라는 작은 목소리가 들리기 시작한다는 원문의 표현이 정확합니다. 그 목소리를 무시하지 않는 것, 그리고 그 까다로운 취향을 충족시킬 수 있는 기술적 능력을 갖추는 것. 그 결합이 px 단위의 디테일에서 아키텍처 레벨의 판단까지, 프론트엔드 전반의 품질을 결정합니다.
15세기 피렌체에서 재능 있는 커뮤니티가 관련 문제를 함께 풀었을 때 위대한 작업이 집중적으로 탄생했듯, 디자이너와 개발자가 Design Token으로 공통 언어를 만들고, Figma Dev Mode에서 의도를 정확히 전달하고, 컴포넌트 라이브러리에서 그 의도를 코드로 번역하는 협업의 밀도가—결국 우리 시대의 피렌체를 만듭니다. 취향은 훈련 가능하고, 좋은 디자인의 기준은 객관적이며, 그 기준은 Figma 캔버스에서 멈추지 않고 tsx 파일 안까지 관통해야 합니다.