[초안] 레이아웃 컴포넌트 #567
Replies: 17 comments 23 replies
-
|
리뷰 포인트
개선 예정 사항
|
Beta Was this translation helpful? Give feedback.
-
|
@hyoseong1994 님, 초안 공유해주셔서 감사합니다. 먼저 전반적인 글의 인상에 대해서 말씀드리면 이곳 저곳에서 AI가 작성해준 티가 너무 많이 나는 것 같습니다 (아니라면 죄송합니다 ㅠㅠ 원래 효성님 글 쓰는 스타일일까요? ㅎㅎ) 조금만 더 사람 냄새나게 작성해주시면 어떨까요? 효성님만의 관점과 개성이 좀 더 들어난다면 더 좋을 글이 될 것 같습니다. 현재는 블로그 글이라기 보다는 약간 기술 문서의 느낌이 많이 나는 것 같습니다.
실제 글의 내용을 보면 설계보다는 구현 쪽에 많이 치우쳐있는 것 같습니다. 개발자에게 친화적인 컴포넌트 API를 설계하기 위해서 고민하신 부분에 대해서 좀 더 공유해주시면 어떨까요?
테이블로 비교하는 것이 억지스러운 느낌이 드네요. 그냥 글로 설명해주셔도 될 것 같습니다.
블릿 포인트를 사용해서 설명하는 것이 효과적인지 의문입니다. 그리고 컴포넌의 레벨이 이렇게 딱 이분법으로 나눠지지 않을 것 같기도 하고요.
이 섹션이 제목처럼 실제 구현 과정을 담았다기 보다는 단순히 구현 코드와 데모 영상을 보여주는 것 같은데요?
"잘못된 접근"이라는 표현보다는 좀 더 긍정적인 제목을 쓰면 어떨까요? 옮고 그름의 프레임에서 바라보는 것보다는 교훈, 배운 점으로 풀어내시면 더 좋을 것 같습니다. |
Beta Was this translation helpful? Give feedback.
-
|
블로그 작성하는 게 쉽지 않다는 생각이 새삼 들며... 제가 지금껏 봐왔던 기술 블로그가 ㅂㄷㅇㅁㅈ이랑 아마 ㅌㅅ?(이쪽은 기술블로그 보다는 약간 프로덕트 서비스 소개에 가까운 마케팅 글? 같긴 했네요.), ㄴㅇㅂ ㅍㅅㅌ 쪽이었던 거 같은데 그래서인지 스타일에 차이가 많이 느껴졌던 거 같네요. (초성으로 쓴 건 혹시나 모를 서치 방지... ^^) 저희가 디자인 시스템을 개발하는 건 웹 생태에 필요하다는 데에 동의를 하기 때문이긴 하지만 정말 너무 필요해서 만들고야 말겠다는 마음으로 한 건 아니라서 그런지 약간 그런 내용이 담겨있지 않은 듯도 해요. 달레님이 언급하신 거처럼 고민과 그걸 풀어나간 방식에 좀 더 초점을 맞춰 보는 건 어떨까 하는 생각이 들었습니다! 수고 많으셔요! (그렇게 테크니컬 라이팅 아무나 하는 거 아니구나 깨달아버리기...) |
Beta Was this translation helpful? Give feedback.
-
|
@hyoseong1994 님, 오늘(금) 퇴근 후 댓글달겠습니다! 조금 늦어서 죄송합니다! |
Beta Was this translation helpful? Give feedback.
-
|
초안 공유해주셔서 감사합니다 추가로 달레님과 비슷한 의견인데, 설계를 하며 했던 고민들을 조금 더 풀어보면 좋지 않을까 생각합니다..! |
Beta Was this translation helpful? Give feedback.
-
|
@hyoseong1994 님, 초안 작성하시느라 수고많으셨습니다!
여기서 '의문이 생겼다'기 보다는 다른 문장들과의 통일성을 위해 '의문이 생겼습니다'로 하는게 좋을 것 같아요!
여기서 '한국어 친화적이고'는 시맨틱한 구조를 가지는것과는 관련이 크게 없는 것 같아서 뺴는 것도 좋을 것 같습니다! 저도 '실제 구현 과정'을 읽으면서
(+ 사실 저는 읽으면서 AI가 작성한 느낌이 안들었는데 이미 한번 사람냄새(?)나게 수정하신거였군요!ㅎㅎ) |
Beta Was this translation helpful? Give feedback.
-
처음에는 이렇게 from 누구, 로 적은 게 무슨 말인지 이해를 못했습니다. 잘 작성해주셔서 감사합니다. 효성님 덕분에 저도 글 쓸 의욕이 막 생기네요!! |
Beta Was this translation helpful? Give feedback.
-
|
효성님, 초안 작성하시느라 수고 많으셨습니다! 현재 적어주신 세가지 불릿포인트가 조금 추상적으로 느껴져서, 말씀하신 ai 친화적인 레이아웃이나 자주 반복되는 high-level 컴포넌트가 |
Beta Was this translation helpful? Give feedback.
-
이 것이 과연 우리 디자인시스템의 사용자 관점에서 "왜 레이아웃 컴포넌트를 만들까?"의 적절한 답이 될지 모르겠습니다. 저는 마치 디자인시스템를 구현하는 개발자들의 편의를 위해서 만들게 되었다는 것처럼 들려요. 좀 더 사용자들이 체감할 수 있는 레이아웃 컴포넌트의 진정한 가치에 대해서 생각해보시면 더 공감되는 글을 쓰실 수 있을 것 같습니다. |
Beta Was this translation helpful? Give feedback.
-
다이어그램 추가해주셔서 너무 좋네요. 그런데 이렇게 해야 좀 더 정확한 표현이 되지 않을까요?
|
Beta Was this translation helpful? Give feedback.
-
이런 생생한 후기 너무 좋네요 ㅋㅋ 좋은 아이디어인 것 같습니다 👍 |
Beta Was this translation helpful? Give feedback.
-
|
코드 스니핏을 넣을실 때는 구문 강조를 해주시면 훨씬 가독성이 좋아집니다. 예를 들어, BeforeAfter {/* hstack */}
return React.createElement(
Component,
{
className: cx(
hstackVariants({
align,
reversed,
}),
css({ gap }),
className,
),
...rest,
},
children,
); |
Beta Was this translation helpful? Give feedback.
-
|
이전 버전보다는 좀 더 사람 냄새가 나는 것 같은데 여전히 너무 용건만 간단히(?) 느낌이 나는 것 같습니다. 이전 포스팅들 #275, #495 을 보시면 도입부나 끝맫음에 상당한 정성을 썼다는 것을 느껴지실 거에요. 특히 글의 첫인상을 결정하는 도입부에 독자들을 붙잡을 수 있도록 조금만 더 내용을 보완해주시면 어떠실지 건의드리고 싶습니다. 평소 효성님 커뮤니케이션 스타일인 것 같기도 한데 ㅎㅎ 혹시 이 것이 효성님께서 의도하시고 지향하시는 글쓰기 스타일이시라면 편하게 알려주세요. 존중하겠습니다. |
Beta Was this translation helpful? Give feedback.
-
➡️ 달레UI 레이아웃 컴포넌트 개발기 (기존 포스팅에서도 "달레UI"라고 일관성있게 부르고 있음. 다른 곳에도 daleui, Dale UI 등이 섞여 있는데 달레UI로 통일 부탁드립니다.)
➡️ 버튼이나 텍스트는 많은 디자인 시스템에서 이미 정답을 내려주지만, 레이아웃은 매번 개발자가 직접 판단해야 하는 경우가 많습니다. (너무 단언적인 표현인 것 같은데 살짝 순화하면 어떨까요?)
➡️ 이 글은 달레UI에서 레이아웃 컴포넌트를 설계하고 구현하는 과정에서 겪었던 고민과 시행착오
추상화 수준으로 점점 높아지는 방향으로
예제 코드를 보면 독자가 PandaCSS를 쓰고 있다고 가정하고 있습니다. PandaCSS가 우리 프로젝트 팀원에게는 익숙한 기술이지만 외부에서는 그렇게 까지 널리 쓰이는 기술은 아니기 때문에 독자에게
예제 코드에 구문 강조 부탁드리며, 역시 PandaCSS를 사용한 예제는 독자들로 부터 공감을 얻기 힘들 수 있습니다.
선택지를 줄인다는 표현은 얼핏들으면 부정적으로 들려서 경험이 많지 않은 개발자에게는 오해의 소지가 있는 표현인 것 같습니다. 차라리 일관성있는 UI 구현을 돕는다는 식으로 좀 더 긍정적인 표현을 사용하는 편이 어떨까요? |
Beta Was this translation helpful? Give feedback.
-
아래 다이어그램을 보면 2단계가 아니라 High, Mid, Low 이렇게 3단계 추상화 단계로 보이는 것 같습니다.
➡️ 고수준과 저수준 레이아웃을 구분했습니다. 한국어를 사용하는 개발자를 대상으로 하는 글이니, 널리 사용되는 한국어 표현이 있는 경우에는 영어 표현을 피했으면 합니다.
혹시 Breaking Changes를 의미하셨을까요? 반응성 얘기도 아닌데 갑자기 breakpoint가 나와서요.
그냥 "배운 점"이라고 간단하게 제목을 쓰셔도 충분할 것 같은데요?
이 거 너무 AI스러운 표현처럼 들리는데 혹시 직접 생각해내신 표현이실까요?
➡️ 달레UI는 너무 많은 레이아웃 컴포넌트를 제공하기보다는 소수의 필수 레이아웃 컴포넌트만을 제공하여 사용자들이 일관성 있는 UI 구현을 달성하는 데 초점을 맞췄습니다. (부정적으로 들릴 수 있는 표현을 긍정적으로 순화)
➡️ 이 글에 담긴 설계 철학과 시행착오가 레이아웃 컴포넌트를 고민하는 분들, 혹은 디자인 시스템의 역할을 고민하는 분들에게 참고 자료가 되기를 바랍니다. 너무 "기준"이라는 단어를 남발하는 것 같아요. 좀 오버, 과장하는 느낌이랄까? ㅋㅋ |
Beta Was this translation helpful? Give feedback.
-
|
@hyoseong1994 님, 전반적인 피드백을 잘 반영해주셔서 감사합니다. 글 완성도를 높이기 위해서 세부 사항에 대해서 추가 피드백을 드렸어요. 효성님께서 판단하셔서 선택적으로 취하시면 될 것 같습니다. 저는 이 정도면 발행해도 충분하다고 생각하고, 다른 분들 이견이 없으시면 다음 주에 달레UI의 올 해 마지막 포스팅으로 내보내시죠? 😄 |
Beta Was this translation helpful? Give feedback.
-
|
블로그 글이 발행되었으니 초안은 닫도록 하겠습니다. |
Beta Was this translation helpful? Give feedback.



Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
달레UI 레이아웃 컴포넌트 개발기
레이아웃은 UI를 만들 때 가장 많이 작성하지만, 가장 명확한 기준을 갖기 어려운 영역입니다.
버튼이나 텍스트는 많은 디자인 시스템에서 이미 정답을 내려주지만, 레이아웃은 매번 개발자가 직접 판단해야 하는 경우가 많습니다.
이 판단은 코드에 명확히 드러나지 않고, 결국 “이렇게 써도 되나?”라는 질문을 남깁니다.
이 글은 달레UI에서 레이아웃 컴포넌트를 설계하고 구현하는 과정에서 겪었던 고민과 시행착오
Box,Flex,Grid,VStack,HStack같은 기본 레이아웃을 어떤 기준으로 나누고 정리했는지에 대한 기록입니다.단순히 컴포넌트를 나열하는 글이 아니라, 레이아웃의 판단을 어디까지 시스템이 책임져야 하는가라는 질문에 대해 달레UI가 선택한 기준과 방향을 공유하고자 합니다.
🧩 왜 레이아웃 컴포넌트를 만들까?
화면을 구성하는 대부분의 시간은 레이아웃에 쓰입니다
디자인 시스템을 사용하는 개발자분들은 버튼이나 타이포그래피보다 레이아웃 코드를 훨씬 더 많이 작성하게 됩니다. 버튼이나 타이포그래피는 이미 정의된 컴포넌트를 가져다 쓰면 끝이지만 레이아웃은 매번 어떤 방법을 사용할지 판단해야합니다. 어떻게 배치할지에 대한 선택의 연속이기 때문에, 컴포넌트 중에서도 가장 많은 판단과 고민이 필요한 영역입니다.
그리고 그 레이아웃 코드는 보통 아래와 같은 형태로 반복됩니다.
문제는 이 코드만 보고서는 이 레이아웃이 그냥 기본 구조인지, 아니면 누군가 의도적으로 조정한 결과인지 알기 어렵다는 점입니다.
이런 것들을 코드를 읽는 사람이 매번 짐작해야 합니다. 결국 레이아웃을 작성할 때마다 코드를 짜는 시간보다, 의미를 해석하고 판단하는 데 더 많은 시간을 쓰게 됩니다.
같은 레이아웃, 다른 구현
여러 명의 개발자가 함께 작업하다 보면 같은 레이아웃이라도 구현 방식이 조금씩 달라집니다.
겉보기에는 큰 차이가 없어 보이지만, 이런 작은 차이들은 시간이 지날수록 UI 일관성과 유지보수 비용에 영향을 줍니다.
사용자는 매번 다음과 같은 판단을 스스로 내려야 합니다.
이러한 고민이 반복되면, 디자인 시스템을 쓰고 있음에도 오히려 판단 부담은 계속 늘어나게 됩니다.
레이아웃 컴포넌트는 일관성 있는 UI를 구현하는 데 필요한 기준을 제공합니다.
레이아웃 컴포넌트의 목적은 새로운 기능을 제공하는 데 있지 않습니다. 대신 다음과 같은 역할을 합니다.
이 한 줄은 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제공할 컴포넌트 선정
레이아웃 컴포넌트는 종류가 매우 다양합니다. Box부터 AbsoluteCenter까지 선택지가 많았고, 달레UI 팀은 이 중 어떤 컴포넌트를 우선 제공할지 결정해야 했습니다.
초기에는 "가능한 한 많은 컴포넌트를 지원해 사용자에게 다양한 선택지를 제공하자는 생각이 있었습니다." 하지만 실제로 사용되지 않는 컴포넌트를 계속 유지하는 것은 의미가 없을 뿐 아니라, 이후 제거 과정에서 break-change가 발생해 사용자 경험이 떨어질 수도 있었습니다.
이러한 이유로, 과도한 확장보다 실제 사용 빈도를 기준으로 컴포넌트를 선별하는 방향이 더 적절하다고 판단했습니다.
우선 마케팅 페이지 개발에서 가장 많이 사용되는 Box, Flex, HStack, VStack, Grid를 먼저 구현했으며, 이후 필요성이 확인되는 컴포넌트부터 단계적으로 확장해 나가는 전략을 선택했습니다.
접근성에 대한 고려
달레UI는 접근성을 준수한 디자인 시스템을 목표로 하고 있기 때문에, 레이아웃 컴포넌트도 시맨틱한 구조를 가질 수 있어야 했습니다.
처음에는 아래처럼 role을 부여하는 방식으로 시맨틱을 표현하려 했습니다.
하지만 시맨틱 구조는 가능한 한 태그 자체로 표현하는 것이 원칙이기 때문에, 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
결과
🔍 배운 점(개발 우선순위 선택)
유사한 컴포넌트 구성
처음에는 “가장 많이 사용하는 레이아웃부터 만들자”는 판단으로
VStack와HStack을 먼저 구현했습니다.그러나 실제 구현을 진행하면서 세 컴포넌트(
VStack,HStack,Flex)에서 유사한 로직과 스타일 패턴이 반복되는 문제를 경험했습니다.결국,
Flex를 먼저 설계하고 이를 기반으로VStack,HStack을 구성했어야 했다는 아쉬움이 남았습니다.VStack,HStack을 Flex 기반으로 재구성초기 구현에서는 각각을 독립적인 컴포넌트로 관리했지만, 이후 Stack류 레이아웃의 근간을
Flex로 통합하는 방향으로 재구성했습니다.VStack→Flex+direction="column"+align="center"HStack→Flex+direction="row"+align="center"결과적으로
VStack와HStack은 독립적인 구현체가 아닌,Flex를 기반으로 한 명확한 preset 컴포넌트로 정리되었습니다.
코드
결과
🧭 앞으로의 방향
레이아웃 시스템은 앞으로도 확장할 부분이 남아 있습니다.
ex)
AbsoluteCenterScrollArea등 자주 사용되는 UI패턴을 추가할 계획ex) align="top"처럼 의도 중심 네이밍 / “예시 중심” 문서화를 제공해서 AI가 정확한 코드 스니펫을 생성하도록 유도
🏁 마무리
레이아웃 컴포넌트는 눈에 잘 띄지 않지만, 디자인 시스템의 신뢰도를 가장 직접적으로 좌우하는 영역이라고 생각합니다.
개발자가 매번 판단해야 하는 부분이 많아질수록 시스템은 참고용되고, 시스템이 대신해 줄수록 디자인 시스템은 기준됩니다.
달레UI는 너무 많은 레이아웃 컴포넌트를 제공하기보다는 소수의 필수 레이아웃 컴포넌트만을 제공하여 사용자들이 일관성 있는 UI 구현을 달성하는 데 초점을 맞췄습니다.
이 글에 담긴 설계와 시행착오가 레이아웃 컴포넌트를 고민하는 분들, 혹은 디자인 시스템의 역할을 고민하는 분들에게 참고 자료가 되기를 바랍니다.
각자의 제품과 팀에 맞는 기준은 다를 수 있지만, “무엇을 시스템이 책임질 것인가”를 고민하는 출발점이 되었으면 합니다.
앞으로도 달레UI의 레이아웃 시스템은 실제 사용 경험을 바탕으로 계속 다듬어갈 예정입니다.
Beta Was this translation helpful? Give feedback.
All reactions