#설계

List 디자인 시스템 · 11편

List의 공개 범위는 왜 타입만으로 지킬 수 없었을까

exports로 패키지의 공개 경로를 설계하고, JavaScript와 CSS가 줄어드는 단위를 가르기

List 디자인 시스템 · 10편

같은 List를 만들었는데 왜 플랫폼 구현은 달라야 했을까

세 플랫폼이 공유할 의미와 각 플랫폼이 소유할 실현을 나누기

List 디자인 시스템 · 9편

List를 나눈 것은 모양이 아니라 '상태의 소유권'이었다

동일한 화면 구조의 목록을 왜 두 개의 Recipe로 나누어야 했을까

List 디자인 시스템 · 8편

ListRow에서 List로 올라와도 새 Recipe는 생기지 않았다

목록의 공간을 제목과 본문으로 나누고 그 위에 구분선과 배경 두 축을 세우기까지

List 디자인 시스템 · 7편

ListRow마다 유효하던 코드가 List 전체에서는 어긋났다

ListRow와 List의 책임 경계를 다시 긋고 무엇을 List가 소유할지 가르기

List 디자인 시스템 · 6편

ListRow에 열 수 있었던 prop을 왜 열지 않았을까

이 결정을 누가, 어디서, 몇 번 하는지로 갈랐다

AI가 사용할 디자인 시스템은 무엇이 달라야 할까

규칙을 문서에 적는 것과 시스템에 심는 것의 차이

List 디자인 시스템 · 5편

ListRow의 모양과 동작을 왜 하나의 계약으로 묶었을까

화살표와 버튼이 동작 영역, DOM, 접근성까지 결정한 과정

List 디자인 시스템 · 4편

ReactNode 슬롯은 ListRow에 들어올 컴포넌트를 제한하지 못했다

컴포넌트의 정체성을 검사하는 대신 정해진 데이터만 받기까지

List 디자인 시스템 · 3편

List API의 유연성은 어디에 두어야 했을까

같은 ListRow를 Flat, Compound, Recipe로 만들자 잘하는 일이 갈렸다

List 디자인 시스템 · 2편

List를 화면이 아니라 구조로 나누자 Recipe의 기준이 생겼다

화면 사례를 anatomy로 나누고 Recipe와 Variant의 경계를 정한 세 가지 질문

List 디자인 시스템 · 1편

List 디자인 시스템은 왜 자유도를 제한해야 했을까

오픈소스 컴포넌트와 사내 컴포넌트가 다른 답을 고르는 이유

페이지네이션 컴포넌트 · 3편

페이지네이션 컴포넌트, 포커스를 잃지 않게 하기

노드를 지우지 않고 상태만 바꾼다

페이지네이션 컴포넌트 · 2편

페이지네이션 컴포넌트, 헤드리스로 다시 설계하기

커스텀 엘리먼트와 compound 구조, 그리고 SSR

페이지네이션 컴포넌트 · 1편

페이지네이션 컴포넌트, 모듈 경계부터 그리기

라이브러리를 쓰지 않기로 하고 처음부터 설계한 기록

앱 배포 없이 바뀌는 모달 웹뷰를 설계한 이야기

최초 도입은 앱 배포가 필요했다. 그 이후를 웹 배포만으로 바꾸는 것이 목표였다

인앱약정 SDK · 10편

인앱약정 SDK의 최종 구조 정리

아홉 편에서 만든 구조를 한 장에 정리하고, 금융사 30곳으로 가기 위해 남은 배포 문제를 다룬다

인앱약정 SDK · 9편

웹뷰 라우팅과 뒤로가기 핸들링

같은 document인가, 새 document인가

인앱약정 SDK · 7편

오류의 원인을 볼 수 없는데 화면은 어떻게 책임질 것인가

금융사가 삼킨 예외의 원인은 볼 수 없다

인앱약정 SDK · 6편

다음 화면은 누가 정하는가

화면은 우리가 그리지만, 흐름의 책임은 어디에 둘 것인가

인앱약정 SDK · 5편

30개의 금융사를 지원하기 위한 SDK 표준화 설계

차이를 없애지 않고 관리하는 방법

인앱약정 SDK · 4편

외부 환경에서 실행되는 SDK를 설계하는 법

커맨드 큐, 그리고 해시 파일명의 딜레마

인앱약정 SDK · 3편

남의 document 안에서 살아남기

15개 금융사 도메인에서 Shadow DOM을 선택하기까지

인앱약정 SDK · 2편

화면만 그리면 되는 일이라고 생각했다

금융사 도메인 위에서 시작한 SDK의 첫 번째 설계 결정

인앱약정 SDK · 1편

우리는 왜 금융사 웹사이트 안에 SDK를 심었을까

남의 페이지에서 우리 서비스의 품질을 보장하는 방법

FSD에서 배럴 파일 사용 가이드

배럴 파일은 FSD에서 Public API 역할을 하지만, 잘못 쓰면 순환 import와 tree shaking 실패를 부른다. 계층별 사용 기준과 성능 함정을 정리했다

FSD 아키텍처 소개

모노레포 구조의 서비스마다 폴더 구조가 너무 달랐다. 공통 컨벤션이 필요한 상황에서 왜 FSD인가에 대한 이야기

Vanilla Web: You don't need that library

라우팅·상태 관리·템플릿팅·컴포넌트를 라이브러리 없이 브라우저 표준만으로 푸는 방법을 짚은 발표 정리다. 도구를 고르기 전에 그 도구가 가리고 있는 웹 플랫폼을 먼저 보자는 이야기다.

React useState를 언제 작별해야 할까?

useState가 나쁜 게 아니라, 너무 간단해서 복잡한 자리에 잘못 놓인다. 다섯 가지 문제 상황과 각각의 대안을 실무 경험과 함께 정리했다

Next.js 미들웨어의 복잡성을 해결하는 파이프라인 라이브러리 개발기

인증 체크 하나로 시작한 middleware.ts가 500줄이 됐다. Express의 next() 패턴을 Next.js Edge Runtime에 맞게 다시 만들면서 어댑터 패턴과 fail-open을 고른 기록