[초안] 레이아웃 컴포넌트

[hyoseong1994]

달레UI 레이아웃 컴포넌트 개발기

레이아웃은 UI를 만들 때 가장 많이 작성하지만, 가장 명확한 기준을 갖기 어려운 영역입니다.

버튼이나 텍스트는 많은 디자인 시스템에서 이미 정답을 내려주지만, 레이아웃은 매번 개발자가 직접 판단해야 하는 경우가 많습니다.

• flex를 쓸지 grid를 쓸지
• align은 어디까지 허용해야 하는지
• 이 gap이 팀의 기준에 맞는 값인지

이 판단은 코드에 명확히 드러나지 않고, 결국 “이렇게 써도 되나?”라는 질문을 남깁니다.

이 글은 달레UI에서 레이아웃 컴포넌트를 설계하고 구현하는 과정에서 겪었던 고민과 시행착오 Box, Flex, Grid, VStack, HStack 같은 기본 레이아웃을 어떤 기준으로 나누고 정리했는지에 대한 기록입니다.

단순히 컴포넌트를 나열하는 글이 아니라, 레이아웃의 판단을 어디까지 시스템이 책임져야 하는가라는 질문에 대해 달레UI가 선택한 기준과 방향을 공유하고자 합니다.

---

🧩 왜 레이아웃 컴포넌트를 만들까?

화면을 구성하는 대부분의 시간은 레이아웃에 쓰입니다

디자인 시스템을 사용하는 개발자분들은 버튼이나 타이포그래피보다 레이아웃 코드를 훨씬 더 많이 작성하게 됩니다. 버튼이나 타이포그래피는 이미 정의된 컴포넌트를 가져다 쓰면 끝이지만 레이아웃은 매번 어떤 방법을 사용할지 판단해야합니다. 어떻게 배치할지에 대한 선택의 연속이기 때문에, 컴포넌트 중에서도 가장 많은 판단과 고민이 필요한 영역입니다.

그리고 그 레이아웃 코드는 보통 아래와 같은 형태로 반복됩니다.

<div
  style={{
    display: "flex",
    flexDirection: "column",
    alignItems: "flex-start",
    gap: "8px",
  }}
/>

문제는 이 코드만 보고서는 이 레이아웃이 그냥 기본 구조인지, 아니면 누군가 의도적으로 조정한 결과인지 알기 어렵다는 점입니다.

• 세로 방향이 기본값이라서 그런 건지
• 특정 화면을 위해 일부러 이렇게 맞춘 건지
• 이 간격이 디자인 시스템에서 권장하는 값인지

이런 것들을 코드를 읽는 사람이 매번 짐작해야 합니다. 결국 레이아웃을 작성할 때마다 코드를 짜는 시간보다, 의미를 해석하고 판단하는 데 더 많은 시간을 쓰게 됩니다.

같은 레이아웃, 다른 구현

여러 명의 개발자가 함께 작업하다 보면 같은 레이아웃이라도 구현 방식이 조금씩 달라집니다.

{/* A 개발자 */}
<div style={{ display: "flex", gap: "8px" }}>
  <div />
  <div />
</div>

{/* B 개발자 */}
<div style={{ display: "flex" }}>
  <div style={{ marginRight: "8px" }} />
  <div />
</div>

겉보기에는 큰 차이가 없어 보이지만, 이런 작은 차이들은 시간이 지날수록 UI 일관성과 유지보수 비용에 영향을 줍니다.
사용자는 매번 다음과 같은 판단을 스스로 내려야 합니다.

• 이 경우에는 flex를 직접 써도 괜찮을까?
• gap은 어느 정도가 적당할까?
• 이 레이아웃이 팀의 기준에 맞는 방식일까?

이러한 고민이 반복되면, 디자인 시스템을 쓰고 있음에도 오히려 판단 부담은 계속 늘어나게 됩니다.

레이아웃 컴포넌트는 일관성 있는 UI를 구현하는 데 필요한 기준을 제공합니다.

레이아웃 컴포넌트의 목적은 새로운 기능을 제공하는 데 있지 않습니다. 대신 다음과 같은 역할을 합니다.

• 잘못된 정렬이나 방향을 선택하지 않도록 돕고
• 의미 없는 spacing 사용을 막으며
• 레이아웃의 의도를 코드에서 바로 읽을 수 있게 합니다

<VStack gap="8" reversed align="top" >
    ....
</VStack>

이 한 줄은 CSS 구현을 나열하는 코드가 아니라, “세로로 쌓고, 이 간격과 정렬을 사용한다”는 의도 표현입니다.
이를 통해 사용자는 더 이상 flex 축을 직접 계산하지 않아도 되고 align과 justify를 헷갈리지 않아도 되며 팀의 스타일 기준을 추측하지 않아도 됩니다

그래서, 왜 레이아웃 컴포넌트일까요?

레이아웃 컴포넌트는 더 빠르게 만들기 위한 도구라기보다는, 틀리지 않게 만들기 위한 도구입니다. 사용자는 불필요한 고민을 줄일 수 있고 실수를 할 가능성이 낮아지며 언제나 비슷하고 예측 가능한 결과를 얻을 수 있습니다

이러한 경험이 쌓일수록 디자인 시스템은 “있으면 좋은 도구”가 아니라 신뢰할 수 있는 기준이 됩니다. 이것이 달레UI가 레이아웃 컴포넌트를 제공하는 이유입니다.
레이아웃에 대한 판단을 개발자 개인에게 맡기지 않고, 시스템이 대신 책임지기 위함입니다.

---

🧠 설계 과정

레이아웃 전략: 고수준과 저수준

레이아웃 컴포넌트를 설계하면서 개발 우선순위와 사용성을 고려해서 달레UI는 추상화 수준을 기준으로 고수준과 저수준 레이아웃을 구분했습니다.
VStack이나 HStack처럼 특정 패턴을 빠르게 구현하도록 만든 컴포넌트는 고수준 레이아웃으로, 직관적이고 빠른 개발이 가능하지만 유연성은 제한적입니다. 반대로 Flex, Grid, Box처럼 CSS 속성을 거의 그대로 노출하는 컴포넌트는 저수준 레이아웃으로 더 많은 제어가 가능해 복잡한 레이아웃 구현에 유리하지만 개발자의 실수로 잘못된 스타일링의 가능성이 있습니다.

왜 추상화 수준으로 나눌까?

저수준 컴포넌트는 자유도가 높아 다양한 레이아웃을 구현할 수 있고 고수준 컴포넌트는 저수준을 추상화해 반복되는 패턴을 재사용할 수 있어서 유연성과 확장성을 동시에 높일 수 있습니다.

flowchart TD
    subgraph 저수준
        Flex[Flex]
        Grid[Grid]
        Box[Box]
    end

    subgraph 고수준
        VStack[VStack]
        HStack[HStack]
    end

    VStack --> Flex
    HStack --> Flex

Loading

제공할 컴포넌트 선정

레이아웃 컴포넌트는 종류가 매우 다양합니다. Box부터 AbsoluteCenter까지 선택지가 많았고, 달레UI 팀은 이 중 어떤 컴포넌트를 우선 제공할지 결정해야 했습니다.
초기에는 "가능한 한 많은 컴포넌트를 지원해 사용자에게 다양한 선택지를 제공하자는 생각이 있었습니다." 하지만 실제로 사용되지 않는 컴포넌트를 계속 유지하는 것은 의미가 없을 뿐 아니라, 이후 제거 과정에서 break-change가 발생해 사용자 경험이 떨어질 수도 있었습니다.

이러한 이유로, 과도한 확장보다 실제 사용 빈도를 기준으로 컴포넌트를 선별하는 방향이 더 적절하다고 판단했습니다.
우선 마케팅 페이지 개발에서 가장 많이 사용되는 Box, Flex, HStack, VStack, Grid를 먼저 구현했으며, 이후 필요성이 확인되는 컴포넌트부터 단계적으로 확장해 나가는 전략을 선택했습니다.

접근성에 대한 고려

달레UI는 접근성을 준수한 디자인 시스템을 목표로 하고 있기 때문에, 레이아웃 컴포넌트도 시맨틱한 구조를 가질 수 있어야 했습니다.

처음에는 아래처럼 role을 부여하는 방식으로 시맨틱을 표현하려 했습니다.

<VStack role="header" />

하지만 시맨틱 구조는 가능한 한 태그 자체로 표현하는 것이 원칙이기 때문에, role로 의미를 우회적으로 전달하기보다는 실제 HTML 요소를 지정할 수 있도록 as props를 도입했습니다

모든 레이아웃 컴포넌트는 as를 통해 알맞은 태그로 렌더링되도록 설계했으며, 태그만으로 충분하지 않은 경우에만 role로 시맨틱을 보완할 수 있도록 구현했습니다.

---

🛠️ 구현 후기

1. VStack 개발

개발 경험담 from. @hyoseong1994

수직 정렬이 많이 쓰일 것 같아서 VStack부터 만들었습니다.
처음에는 CSS를 그대로 props로 노출하려 했지만, 그러면 고수준 레이아웃이 아니라 그냥 스타일 전달용 컴포넌트가 된다는 피드백을 받았습니다.
그래서 align은 start, end 대신 top, bottom으로 이름을 바꾸고, reversed라는 boolean props로 방향을 쉽게 바꿀 수 있도록 했습니다.
또한 asprops를 사용해 main, header, nav 같은 태그로 렌더링할 수 있게 해서 접근성도 고려했습니다.

데모영상

screen-capture.webm

2. HStack 개발

개발 경험담 from. @sounmind

직접 레이아웃 컴포넌트를 만들었던 적이 없어서 그 자체로 재밌었습니다.
기존에 만들어진 VStack의 컨벤션을 유지하도록 피드백(수평 방향 정렬을 위한 prop 이름을 정할 때)도 해주시고 기타 여러가지 노력했어요.

데모영상

screen-capture.2.webm

3. Flex 컴포넌트 개발

개발 경험담 from. @y00eunji

앞서 구현된 VStack, HStack 컴포넌트를 많이 참고해서 Flex 컴포넌트를 구현했습니다. 저 또한 레이아웃 컴포넌트는 처음 만들어보는 경험이었는데, 리뷰를 통해 테스트 코드를 리팩토링하고, 기본값을 수정하며 justify: around 옵션을 추가하는 등 여러 부분을 개선할 수 있었습니다. 같은 레이아웃 시스템 안에서도 VStack/HStack은 의미론적 prop을, Flex는 저수준 CSS 개념을 노출한다는 점에서 컴포넌트 역할에 따라 API 설계가 달라져야 한다는 걸 경험할 수 있어서 재미있었습니다!

데모영상

screen-capture.3.webm

결과

• 레이아웃 컴포넌트를 도입한 뒤, 반복되던 스타일 코드를 없애고 Flex, HStack, VStack으로 레이아웃 구조를 일관되게 중앙에서 관리할 수 있게 되었습니다.

---

🔍 배운 점(개발 우선순위 선택)

유사한 컴포넌트 구성

처음에는 “가장 많이 사용하는 레이아웃부터 만들자”는 판단으로 VStack와 HStack을 먼저 구현했습니다.
그러나 실제 구현을 진행하면서 세 컴포넌트(VStack, HStack, Flex)에서 유사한 로직과 스타일 패턴이 반복되는 문제를 경험했습니다.

• 고수준 컴포넌트끼리 중복된 로직이 발생함

{/* hstack */}
  return React.createElement(
    Component,
    {
      className: cx(
        hstackVariants({
          align,
          reversed,
        }),
        css({ gap }),
        className,
      ),
      ...rest,
    },
    children,
  );

{/* vstack */}
return React.createElement(
    Component,
    {
      className: cx(
        vstackVariants({
          align,
          reversed,
        }),
        css({ gap }),
        className,
      ),
      ...rest,
    },
    children,
  );

• 내부 동작 규칙이 분리되어 일관성이 깨짐

{/* hstack */}
    align: {
      left: { justifyContent: "flex-start" },
      center: { justifyContent: "center" },
      right: { justifyContent: "flex-end" },
      between: { justifyContent: "space-between" },
      around: { justifyContent: "space-around" },
    },

{/* vstack */}
    align: {
      left: { alignItems: "start" },
      center: { alignItems: "center" },
      right: { alignItems: "end" },
      stretch: { alignItems: "stretch" },
    },

{/* flex */}
    align: {
      start: { alignItems: "flex-start" },
      center: { alignItems: "center" },
      end: { alignItems: "flex-end" },
      stretch: { alignItems: "stretch" },
    },

결국, Flex를 먼저 설계하고 이를 기반으로 VStack, HStack을 구성했어야 했다는 아쉬움이 남았습니다.

VStack, HStack을 Flex 기반으로 재구성

초기 구현에서는 각각을 독립적인 컴포넌트로 관리했지만, 이후 Stack류 레이아웃의 근간을 Flex로 통합하는 방향으로 재구성했습니다.

• VStack → Flex + direction="column" + align="center"
• HStack → Flex + direction="row" + align="center"

결과적으로 VStack와 HStack은 독립적인 구현체가 아닌,
Flex를 기반으로 한 명확한 preset 컴포넌트로 정리되었습니다.

코드

export const VStack = ({
  children,
  align = "top",
  reversed = false,
  ...rest
}: VStackProps) => {
  return (
    <Flex
      direction={direction}
      justify={alignContent}
      align="center"
      {...rest}
    >
      {children}
    </Flex>
  );
};

결과

• 중복 로직 제거
• 확장성 증가
• 모든 gap/spacing이 동일한 토큰 기준을 따르게 됨

---

🧭 앞으로의 방향

레이아웃 시스템은 앞으로도 확장할 부분이 남아 있습니다.

• 중복 로직 최소화, 코드 유지보수성 강화
• 자주 반복되는 UI 패턴 기반의 고수준 컴포넌트 추가
  ex) AbsoluteCenter ScrollArea 등 자주 사용되는 UI패턴을 추가할 계획
• 명확한 props 네이밍과 문서화로 AI 친화적인 레이아웃 컴포넌트 구현
  ex) align="top"처럼 의도 중심 네이밍 / “예시 중심” 문서화를 제공해서 AI가 정확한 코드 스니펫을 생성하도록 유도

---

🏁 마무리

레이아웃 컴포넌트는 눈에 잘 띄지 않지만, 디자인 시스템의 신뢰도를 가장 직접적으로 좌우하는 영역이라고 생각합니다.

개발자가 매번 판단해야 하는 부분이 많아질수록 시스템은 참고용되고, 시스템이 대신해 줄수록 디자인 시스템은 기준됩니다.

달레UI는 너무 많은 레이아웃 컴포넌트를 제공하기보다는 소수의 필수 레이아웃 컴포넌트만을 제공하여 사용자들이 일관성 있는 UI 구현을 달성하는 데 초점을 맞췄습니다.

이 글에 담긴 설계와 시행착오가 레이아웃 컴포넌트를 고민하는 분들, 혹은 디자인 시스템의 역할을 고민하는 분들에게 참고 자료가 되기를 바랍니다.

각자의 제품과 팀에 맞는 기준은 다를 수 있지만, “무엇을 시스템이 책임질 것인가”를 고민하는 출발점이 되었으면 합니다.

앞으로도 달레UI의 레이아웃 시스템은 실제 사용 경험을 바탕으로 계속 다듬어갈 예정입니다.

[hyoseong1994]

리뷰 포인트

• 개발 케이스를 전부 나열하는 대신, 핵심적인 몇 가지 사례만 선별해서 적는 게 더 나을지 고민 중입니다.
• 추가적인 용어 설명이 필요해 보이는 부분이 있다면 알려주세요.

개선 예정 사항

• Grid와 Box 컴포넌트는 현재 개발 중이라 코드와 데모 영상은 포함하지 않았습니다. 작업이 완료되면 해당 내용도 함께 업데이트할 예정입니다.

[Lustellz]

핵심적인 몇 가지 사례만 선별해서 적는 게 더 나을 거 같아요! 어떤 필요에 의해서 개발을 하게 되었는지가 좀 더 표현되면 좋겠어요.

[DaleSeo]

@hyoseong1994 님, 초안 공유해주셔서 감사합니다. 먼저 전반적인 글의 인상에 대해서 말씀드리면 이곳 저곳에서 AI가 작성해준 티가 너무 많이 나는 것 같습니다 (아니라면 죄송합니다 ㅠㅠ 원래 효성님 글 쓰는 스타일일까요? ㅎㅎ) 조금만 더 사람 냄새나게 작성해주시면 어떨까요? 효성님만의 관점과 개성이 좀 더 들어난다면 더 좋을 글이 될 것 같습니다. 현재는 블로그 글이라기 보다는 약간 기술 문서의 느낌이 많이 나는 것 같습니다.

daleui 레이아웃 컴포넌트를 설계하고 구현한 과정을 정리한 기술 블로그 글입니다.

실제 글의 내용을 보면 설계보다는 구현 쪽에 많이 치우쳐있는 것 같습니다. 개발자에게 친화적인 컴포넌트 API를 설계하기 위해서 고민하신 부분에 대해서 좀 더 공유해주시면 어떨까요?

왜 레이아웃 컴포넌트가 중요한가

테이블로 비교하는 것이 억지스러운 느낌이 드네요. 그냥 글로 설명해주셔도 될 것 같습니다.

레이아웃 전략: High-level vs Low-level

블릿 포인트를 사용해서 설명하는 것이 효과적인지 의문입니다. 그리고 컴포넌의 레벨이 이렇게 딱 이분법으로 나눠지지 않을 것 같기도 하고요.

실제 구현 과정

이 섹션이 제목처럼 실제 구현 과정을 담았다기 보다는 단순히 구현 코드와 데모 영상을 보여주는 것 같은데요?

잘못된 접근

"잘못된 접근"이라는 표현보다는 좀 더 긍정적인 제목을 쓰면 어떨까요? 옮고 그름의 프레임에서 바라보는 것보다는 교훈, 배운 점으로 풀어내시면 더 좋을 것 같습니다.

[hyoseong1994]

안녕하세요 달레님 수정중인데 좀 더 시간이 걸릴거 같아서 답변먼저 드립니다.

1. 제가 작성하고 ai에게 리뷰를 받는 형식으로 하다보니 어투에서 AI 스러움이 있던거 같습니다. 사람냄새나게 수정하도록하겠습니다.
2. 개발자에게 친화적인 컴포넌트 API를 설계하기 위해서 고민에 대해서 왜 레이아웃 컴포넌트를 만들까? 개발 경험담을 통해 추가하였습니다.
3. 왜 레이아웃 컴포넌트가 중요한가 테이블로 비교하는것이 한 눈에 들어올것이라고 생각했는데 오히려 억지스러운 느낌이군요 왜 레이아웃 컴포넌트를 만들까?로 변경하였습니다.
4. 레이아웃 전략: High-level vs Low-level 말씀하신대로 딱 이분법으로 나눠지지않아서 추상화 기준으로 나눴다는 내용과 왜 추상화기준을 사용했는지에 대해 추가했습니다.
5. 실제 구현 과정은 개발 경험담으로 변경 예정이며 에반님과 은지님께 도움 요청한 상태입니다.
6. 잘못된 접근 말씀하신대로 긍정적인 표현으로 변경하였습니다.

[Lustellz]

저도 동의합니다~ 좀 더 고민한 부분과 이 개발의 필요성이 잘 드러나면 좋겠어요.

[hyoseong1994]

@DaleSeo 안녕하세요 달레님
피드백 주신내용 반영하였습니다. 추가 피드백 있으시면 남겨주시면 감사하겠습니다.

[Lustellz]

블로그 작성하는 게 쉽지 않다는 생각이 새삼 들며... 제가 지금껏 봐왔던 기술 블로그가 ㅂㄷㅇㅁㅈ이랑 아마 ㅌㅅ?(이쪽은 기술블로그 보다는 약간 프로덕트 서비스 소개에 가까운 마케팅 글? 같긴 했네요.), ㄴㅇㅂ ㅍㅅㅌ 쪽이었던 거 같은데 그래서인지 스타일에 차이가 많이 느껴졌던 거 같네요. (초성으로 쓴 건 혹시나 모를 서치 방지... ^^)

저희가 디자인 시스템을 개발하는 건 웹 생태에 필요하다는 데에 동의를 하기 때문이긴 하지만 정말 너무 필요해서 만들고야 말겠다는 마음으로 한 건 아니라서 그런지 약간 그런 내용이 담겨있지 않은 듯도 해요.
우리가 마주한 문제와 그걸 해결하기 위한 고민, 시도 등이 들어가면 이 과정에 대한 납득도 되고 자연스레 공감하지 않을까 싶어요. (요새 구직 준비 할 생각을 하다보니 + 소설 쓰는 수업을 듣다 보니 서사성으로 치우치게 되는 거 같지만;)

달레님이 언급하신 거처럼 고민과 그걸 풀어나간 방식에 좀 더 초점을 맞춰 보는 건 어떨까 하는 생각이 들었습니다! 수고 많으셔요! (그렇게 테크니컬 라이팅 아무나 하는 거 아니구나 깨달아버리기...)

[hyoseong1994]

마주한 문제와 그걸 해결하기 위한 고민

위 내용 왜 레이아웃 컴포넌트를 만들까? 에 보완했습니다. 감사합니다.

[RiaOh]

@hyoseong1994 님, 오늘(금) 퇴근 후 댓글달겠습니다! 조금 늦어서 죄송합니다!

[HowToBeAHappyBoy]

초안 공유해주셔서 감사합니다
결과 부분이 단순 나열된 형태인데 실제 적용된 코드를 예시로 들면 독자들이 더 공감할 수 있지 않을까 생각합니다
(#601 PR같은 실제 사례도 존재하니까요!)

추가로 달레님과 비슷한 의견인데, 설계를 하며 했던 고민들을 조금 더 풀어보면 좋지 않을까 생각합니다..!

[yolophg]

동의합니다, 설계 레벨에서의 시행착오가 좀 더 드러나게끔 하나의 예시라도 줌인해서 이야기해도 좋을 것 같습니다!

[hyoseong1994]

피드백 감사합니다.

1. 실제 적용된 코드 예시 일부 추가하여 공감할 수 있게 변경하였습니다.
2. 설계 과정 섹션을 통해 설계하며 고민했던 부분을 추가했습니다.

[hyoseong1994]

@HowToBeAHappyBoy 안녕하세요 아카님
피드백 주신내용 반영하였습니다. 추가 피드백 있으시면 남겨주시면 감사하겠습니다.

[RiaOh]

@hyoseong1994 님, 초안 작성하시느라 수고많으셨습니다!
읽으면서 조금 minor한 부분에 대해 말씀드리자면,

이런 구조가 수십 번씩 나오면서 “이걸 매번 div + css로 풀어야 하나?”라는 의문이 생겼다.

여기서 '의문이 생겼다'기 보다는 다른 문장들과의 통일성을 위해 '의문이 생겼습니다'로 하는게 좋을 것 같아요!

Dale UI는 한국어 친화적이고 접근성을 준수한 디자인 시스템 목표로 삼고 있기 때문에, 레이아웃 컴포넌트도 시맨틱한 구조를 가질 수 있어야 했습니다.

여기서 '한국어 친화적이고'는 시맨틱한 구조를 가지는것과는 관련이 크게 없는 것 같아서 뺴는 것도 좋을 것 같습니다!

저도 '실제 구현 과정'을 읽으면서

1. VStack 개발 <- 이 부분에서는 고민이 드러났다고 생각하는데
2. HStack 개발, 3. Flex 컴포넌트 개발 부분은 조금 간단하다는 생각이 들었습니다!

(+ 사실 저는 읽으면서 AI가 작성한 느낌이 안들었는데 이미 한번 사람냄새(?)나게 수정하신거였군요!ㅎㅎ)
바쁘신 와중에 이렇게 초안글도 작성해주시고, 정말 고생많으셨습니다!

[hyoseong1994]

피드백 감사합니다.

여기서 '의문이 생겼다'기 보다는 다른 문장들과의 통일성을 위해 '의문이 생겼습니다'로 하는게 좋을 것 같아요!

확인한다고했는데 실수가 있었네요 ㅎㅎ 수정했습니다.

여기서 '한국어 친화적이고'는 시맨틱한 구조를 가지는것과는 관련이 크게 없는 것 같아서 뺴는 것도 좋을 것 같습니다!

동의합니다. 해당 내용 제거했습니다.

실제 구현 과정을 구현 후기로 변경하여 각 컴포넌트의 개발에 참여하신 분들의 개발경험담을 담는 방향으로 수정했습니다.

[sounmind]

처음에는 이렇게 from 누구, 로 적은 게 무슨 말인지 이해를 못했습니다.
"개발 경험담 from @sounmind" 이렇게 하면 어떨까요?
그리고 후기를 quote 문법으로 만들면 더 그 사람이 말한 느낌이 날 것 같아요!

잘 작성해주셔서 감사합니다. 효성님 덕분에 저도 글 쓸 의욕이 막 생기네요!!

[sounmind]

이게 제가 생각하는 개선 예시입니다

[hyoseong1994]

피드백 감사합니다.
말씀하신대로 하니 더 명확해지네요 :)

[hyoseong1994]

안녕하세요 @sounmind 에반님
피드백 주신내용 반영하였습니다. 추가 피드백 있으시면 남겨주시면 감사하겠습니다.

[yolophg]

효성님, 초안 작성하시느라 수고 많으셨습니다!
다들 이미 좋은 피드백을 많이 주셔서 저는 “앞으로의 방향” 부분에 대해 짧게 한가지만 남기겠습니다.

현재 적어주신 세가지 불릿포인트가 조금 추상적으로 느껴져서, 말씀하신 ai 친화적인 레이아웃이나 자주 반복되는 high-level 컴포넌트가
예를 들면 어떤 걸 의미하는지 아주 간단한 예시만 함께 언급해주셔도 좀 더 명확히 와닿을 것 같습니다!

[hyoseong1994]

피드백 감사합니다.

말씀하신대로 다시보니 추상적이네요 간단한 예시를 추가하였습니다.

[hyoseong1994]

안녕하세요 @yolophg 헬레나님
피드백 주신내용 반영하였습니다. 추가 피드백 있으시면 남겨주시면 감사하겠습니다.

[yolophg]

피드백 반영 감사합니다! 수고 많으셨어요👍

[DaleSeo]

이런 구조가 수십 번씩 나오면서 “이걸 매번 div + css로 풀어야 하나?”라는 의문이 생겼습니다.

이 것이 과연 우리 디자인시스템의 사용자 관점에서 "왜 레이아웃 컴포넌트를 만들까?"의 적절한 답이 될지 모르겠습니다. 저는 마치 디자인시스템를 구현하는 개발자들의 편의를 위해서 만들게 되었다는 것처럼 들려요. 좀 더 사용자들이 체감할 수 있는 레이아웃 컴포넌트의 진정한 가치에 대해서 생각해보시면 더 공감되는 글을 쓰실 수 있을 것 같습니다.

[hyoseong1994]

사용자들이 체감할 수 있는 레이아웃 컴포넌트의 진정한 가치에 대해 좀 더 고민하고 추가하도록하겠습니다.

[hyoseong1994]

사용자들이 체감할 수 있는 레이아웃 컴포넌트의 진정한 가치

라는 주제에 대해 아래 소제목들로 내용 추가하였습니다.

🧩 왜 레이아웃 컴포넌트를 만들까?

• 화면을 구성하는 대부분의 시간은 레이아웃에 쓰입니다
• 같은 레이아웃, 다른 구현
• 레이아웃 컴포넌트는 선택지를 줄이기 위해 존재합니다

[hyoseong1994]

@DaleSeo 안녕하세요 달레님 알림이 안간거 같아서 리마인드드립니다.

[DaleSeo]

왜 추상화 수준으로 나눌까?

다이어그램 추가해주셔서 너무 좋네요. 그런데 이렇게 해야 좀 더 정확한 표현이 되지 않을까요?

[hyoseong1994]

피드백 감사합니다. 말씀하신 다이어그램이 더 명확하네요 수정했습니다.

[DaleSeo]

구현 후기

이런 생생한 후기 너무 좋네요 ㅋㅋ 좋은 아이디어인 것 같습니다 👍

[DaleSeo]

코드 스니핏을 넣을실 때는 구문 강조를 해주시면 훨씬 가독성이 좋아집니다. 예를 들어,

Before

  {/* hstack */}
  return React.createElement(
    Component,
    {
      className: cx(
        hstackVariants({
          align,
          reversed,
        }),
        css({ gap }),
        className,
      ),
      ...rest,
    },
    children,
  );

After

  {/* hstack */}
  return React.createElement(
    Component,
    {
      className: cx(
        hstackVariants({
          align,
          reversed,
        }),
        css({ gap }),
        className,
      ),
      ...rest,
    },
    children,
  );

[hyoseong1994]

피드백 감사합니다. 구문강조 넣으니 더 잘보이네요 :) 수정했습니다

[DaleSeo]

이전 버전보다는 좀 더 사람 냄새가 나는 것 같은데 여전히 너무 용건만 간단히(?) 느낌이 나는 것 같습니다. 이전 포스팅들 #275, #495 을 보시면 도입부나 끝맫음에 상당한 정성을 썼다는 것을 느껴지실 거에요. 특히 글의 첫인상을 결정하는 도입부에 독자들을 붙잡을 수 있도록 조금만 더 내용을 보완해주시면 어떠실지 건의드리고 싶습니다. 평소 효성님 커뮤니케이션 스타일인 것 같기도 한데 ㅎㅎ 혹시 이 것이 효성님께서 의도하시고 지향하시는 글쓰기 스타일이시라면 편하게 알려주세요. 존중하겠습니다.

[hyoseong1994]

도입부와 끝맫음에 독자들을 붙잡을수 있도록 좀 더 고민(어떤 내용을 추가할지)하고 내용 보완하도록하겠습니다. ㅎㅎ

[hyoseong1994]

도입부는 문제 인식을 추가하여 독자들로 하여금 궁금증을 갖게 하였고
끝맺음은 글에 시스템이 레이아웃을 책임지도록 기준을 세운다라는 내용을 추가하여 마무리하였습니다.

[DaleSeo]

daleui 레이아웃 컴포넌트 개발기

➡️ 달레UI 레이아웃 컴포넌트 개발기

(기존 포스팅에서도 "달레UI"라고 일관성있게 부르고 있음. 다른 곳에도 daleui, Dale UI 등이 섞여 있는데 달레UI로 통일 부탁드립니다.)

버튼이나 텍스트는 디자인 시스템이 이미 정답을 내려주지만, 레이아웃은 매번 개발자가 직접 판단해야 합니다.

➡️ 버튼이나 텍스트는 많은 디자인 시스템에서 이미 정답을 내려주지만, 레이아웃은 매번 개발자가 직접 판단해야 하는 경우가 많습니다.

(너무 단언적인 표현인 것 같은데 살짝 순화하면 어떨까요?)

이 글은 Dale UI에서 레이아웃 컴포넌트를 설계하며 겪었던 고민과 시행착오

➡️ 이 글은 달레UI에서 레이아웃 컴포넌트를 설계하고 구현하는 과정에서 겪었던 고민과 시행착오

VStack, HStack, Flex, Box, Grid 같은 기본 레이아웃을 어떤 기준으로 나누고 정리했는지에 대한 기록입니다.

추상화 수준으로 점점 높아지는 방향으로 Box, Flex, Grid, VStack, HStack 순으로 나열하면 어떨까요?

“레이아웃의 판단을 어디까지 시스템이 책임져야 하는가”

**와 쌍따옴표를 같이 사용하면 굵은 글씨가 적용되지 않는 것 같습니다.

그리고 그 레이아웃 코드는 보통 아래와 같은 형태로 반복됩니다.

예제 코드를 보면 독자가 PandaCSS를 쓰고 있다고 가정하고 있습니다. PandaCSS가 우리 프로젝트 팀원에게는 익숙한 기술이지만 외부에서는 그렇게 까지 널리 쓰이는 기술은 아니기 때문에 독자에게 css()가 뭐지? 와 같은 본 포스팅을 읽는데 크게 중요하지 않은 의문을 갖게 할 수 있습니다. 그냥 React에서 제공하는 inline style로 예제를 작성해주시면 좋을 것 같습니다.

여러 명의 개발자가 함께 작업하다 보면 같은 레이아웃이라도 구현 방식이 조금씩 달라집니다.

예제 코드에 구문 강조 부탁드리며, 역시 PandaCSS를 사용한 예제는 독자들로 부터 공감을 얻기 힘들 수 있습니다.

레이아웃 컴포넌트는 선택지를 줄이기 위해 존재합니다

선택지를 줄인다는 표현은 얼핏들으면 부정적으로 들려서 경험이 많지 않은 개발자에게는 오해의 소지가 있는 표현인 것 같습니다. 차라리 일관성있는 UI 구현을 돕는다는 식으로 좀 더 긍정적인 표현을 사용하는 편이 어떨까요?

[DaleSeo]

레이아웃 전략: High-level과 Low-level

아래 다이어그램을 보면 2단계가 아니라 High, Mid, Low 이렇게 3단계 추상화 단계로 보이는 것 같습니다.

High-level과 Low-level 레이아웃을 구분했습니다.

➡️ 고수준과 저수준 레이아웃을 구분했습니다.

한국어를 사용하는 개발자를 대상으로 하는 글이니, 널리 사용되는 한국어 표현이 있는 경우에는 영어 표현을 피했으면 합니다.

이후 제거 과정에서 break-point가 발생해 사용자 경험이 떨어질 수도 있었습니다.

혹시 Breaking Changes를 의미하셨을까요? 반응성 얘기도 아닌데 갑자기 breakpoint가 나와서요.

만드는 과정에서 배운 점(개발 우선순위 선택)

그냥 "배운 점"이라고 간단하게 제목을 쓰셔도 충분할 것 같은데요?

개발자가 매번 판단해야 하는 영역이 많을수록 시스템은 점점 “참고용 도구”가 되고,
그 판단을 시스템이 대신 책임질수록 디자인 시스템은 “기준”이 됩니다.

이 거 너무 AI스러운 표현처럼 들리는데 혹시 직접 생각해내신 표현이실까요?

Dale UI의 레이아웃 컴포넌트는 더 많은 기능을 제공하기보다 틀리지 않게 만들기 위한 선택지를 줄이는 데 초점을 맞췄습니다.

➡️ 달레UI는 너무 많은 레이아웃 컴포넌트를 제공하기보다는 소수의 필수 레이아웃 컴포넌트만을 제공하여 사용자들이 일관성 있는 UI 구현을 달성하는 데 초점을 맞췄습니다.

(부정적으로 들릴 수 있는 표현을 긍정적으로 순화)

이 글에 담긴 설계와 시행착오가 레이아웃 컴포넌트를 고민하는 분들, 혹은 디자인 시스템의 역할을 다시 생각하고 있는 분들께 하나의 참고 기준이 되기를 바랍니다.

➡️ 이 글에 담긴 설계 철학과 시행착오가 레이아웃 컴포넌트를 고민하는 분들, 혹은 디자인 시스템의 역할을 고민하는 분들에게 참고 자료가 되기를 바랍니다.

너무 "기준"이라는 단어를 남발하는 것 같아요. 좀 오버, 과장하는 느낌이랄까? ㅋㅋ

[DaleSeo]

@hyoseong1994 님, 전반적인 피드백을 잘 반영해주셔서 감사합니다. 글 완성도를 높이기 위해서 세부 사항에 대해서 추가 피드백을 드렸어요. 효성님께서 판단하셔서 선택적으로 취하시면 될 것 같습니다. 저는 이 정도면 발행해도 충분하다고 생각하고, 다른 분들 이견이 없으시면 다음 주에 달레UI의 올 해 마지막 포스팅으로 내보내시죠? 😄

[hyoseong1994]

상세한 피드백 감사합니다.
수정해서 다음주 내에 발행할수 있도록하겠습니다.

[DaleSeo]

블로그 글이 발행되었으니 초안은 닫도록 하겠습니다.