How to Think Like a Front-End Architect (Not Just a Developer)

What Does a Front-End Architect Actually Do?

프론트엔드 아키텍처는 단순히 코드를 작성하는 기술을 넘어, **'시스템의 지속 가능성과 팀의 효율성을 위한 설계 철학이자 구체적인 실천 방안'**으로 정의할 수 있습니다.

첫 번째 글은 '왜' 그리고 **'어떻게 생각해야 하는가'**라는 철학적 관점을 제시하고, 두 번째 글은 '무엇을' 그리고 **'어떻게 실행하는가'**라는 실용적 방법론을 보여줍니다. 두 글의 생각을 네 가지 핵심 주제로 정리할 수 있습니다.

1. 관점의 전환: '기능 제작자'에서 '시스템 설계자'로

두 글 모두 아키텍처의 시작은 관점(Lens)의 변화라고 강조합니다. 당장 눈앞의 기능 하나를 완성하는 '제작자'의 시각에서 벗어나, 시스템 전체의 장기적인 건강과 다른 개발자들의 경험까지 고려하는 '설계자'의 시각을 갖는 것입니다.

• 제작자의 질문: "이 컴포넌트를 어떻게 만들지?"
• 설계자(아키텍트)의 질문: "이 컴포넌트는 6개월 뒤 시스템에 어떤 영향을 미칠까?", "이것이 다른 개발자들을 더 혼란스럽게 만들지는 않을까?"

결국 아키텍처는 **"공감을 구조화한 것"**이라는 문장처럼, 미래의 동료와 자기 자신을 포함한 모든 사람을 배려하는 기술적인 결정입니다.

2. 추상화를 통한 질서 부여: '상자'가 아닌 '레이어'와 '계약'으로 보기

성장하는 애플리케이션의 혼돈에 질서를 부여하는 핵심 방법은 '추상화'입니다.

• 레이어(Layers)로 분리: 첫 번째 글에서 강조하듯, 하나의 컴포넌트를 단순히 눈에 보이는 UI '상자'로 보지 않습니다. 대신 책임에 따라 계층을 분리합니다.
  • UI 레이어 (보여주기만 함)
  • 동작 레이어 (상태 변화, 이벤트 처리)
  • 서비스 레이어 (API 통신, 데이터 관리)
• 계약(Contracts)으로 정의: 두 번째 글의 '컴포넌트 표준'이 바로 이 개념의 실천입니다. 재사용 가능한 <Button> 컴포넌트를 만드는 것은, 버튼의 시각적 디자인뿐만 아니라 어떤 props를 받고 어떻게 동작할지에 대한 '계약'을 정의하는 행위입니다. useQuery 같은 서버 상태 라이브러리를 선택하는 것 또한 데이터 통신 방식에 대한 '계약'을 정하는 것입니다.

3. 변화를 위한 설계: '예측'이 아닌 '안전장치' 만들기