BlaCk

요즘 너무 AI 거려서 솔직히 좀 재미가 없다 ㅋㅋㅋㅋㅋ 호들갑이 너무 많은게 반절은 되는 것 같다.

그럼에도 가치가 있다는 점은 분명하며 디자인 시스템에서는 AI를 어떻게 흡수되어야 하는가에 대하여 간단히 써보았다. 나도 누군가의 재미없음에 이렇게 기여를.

마치 모나드 같다. 모나드는 엔도펑터 범주에서의 모노이드야. 뭐가 문제지?

The NATIVE

맨날 지겹게 나오는 주제이니 만큼 Native의 뜻이 무엇인가?

'원주민', '태생의', '토착의'이란 뜻이며, 특정 지역에서 태어나고 자란 사람, 혹은 특정 환경에 고유하게 속한 것이라는 의미를 가진다.

여기서 "특정 환경에 고유하게 속한 것" 이 보통 중요하다고 여겨진다.

프로그래밍의 맥락에서도 Native 언어란 Machine Code로 직접 컴파일되어 바이너리를 만들 수 있는 언어를 나타내는 경우도 흔하다.

Native GUI

그런데 UI에서 Native는 Advice for the next dozen Rust GUIs에서도 설명하듯 조금 모호하다.

예를 들어 Windows에는 매우 다양한 공식 구현체가 MFC, WinForms, WPF, WinRT, UWP, WinUI, MAUI 로 존재한다. 또한 VCL/Firemongkey, QT, Avalonia, Uno등 주목할만한 서드파티 생태계도 존재한다.

하위 호환성을 가차없이 버리는 Mac 계열도 Carbon, Cocoa, Prokit(내부용), SwiftUI 처럼 다양한 프레임워크가 존재한다.

그렇다고 완전히 범위를 좁혀 FrameBuffer에 직접 Graphic을 그려야 Native 프레임워크인가? 하지만 SwiftUI나 JetpackCompose는 그러지 않으니 또 애매하다.. 그래서 앞선 블로그에서는 다음과 같은 기준을 제시한다.

간단한 애플리케이션의 바이너리 크기는 얼마인가?

간단한 애플리케이션의 시작 시간은 얼마나 걸리나?

텍스트가 플랫폼의 기본 텍스트처럼 보일까?

앱은 시스템 수준에서 설정된 기본 설정을 어느 정도까지 지원하나?

예상되는 텍스트 제어 기능 중 어떤 하위 집합이 제공하나?

BiDi를 포함한 복잡한 텍스트 렌더링

알파벳 문자를 위한 데드키를 포함한 키보드 레이아웃을 지원합니다.

플랫폼 사용자 인터페이스 가이드라인에 따른 키보드 단축키

입력 방식 편집기

색상 이모티콘 렌더링 및 플랫폼 이모티콘 선택기 사용

복사-붙여넣기(클립보드)

드래그 앤 드롭

맞춤법 및 문법 교정

접근성(텍스트를 소리 내어 읽어주는 기능 포함)

일종의 덕타이핑 같은 접근이다. 플랫폼 네이티브 기술을 사용했는가보다는 플랫폼에서 사용자가 기대하는 기능/관례/품질을 얼마나 충족하는가가 중요하다는 뜻이다.

Native란 구현 방식이 아니라 환경에 얼마나 깊이 통합되어 기대하는 행동을 자연스럽게 수행할 수 있는지가 관건이다.

AI Native Design System

이러한 관점에서 AI Native Design System이란

AI가 이해하고, 기여하고, 제품 안에서 함께 작동할 수 있는 디자인 시스템.

으로 접근해야 한다.

앞선 질문은 이렇게 치환될 수 있다.

시스템 수준의 설정을 지원하는가? -> AI가 토큰, 정책, 접근성 규칙을 얼마나 따르는가?

IME, 클립보드, 드래그엔드롭을 지원하는가? -> AI가 실제 작업 흐름속에서 생성, 수정, 되돌리기를 얼마나 잘 지원하는가

접근성을 지원하는가? -> AI가 시스템의 규칙에 접근가능(Machine Readable), 결과는 검증, 설명, 통제 가능한가?

나는 3가지 환경에서 1급으로 기능해야 성공적으로 만들었다고 판단한다.

AI as Consumer Native: 제품 메이커 관점으로, AI가 시스템처럼 정확히 사용할 수 있는가?

AI as Contributor Native: 시스템 메이커 관점으로, AI가 검토 가능한 기여를 만들 수 있는가?

AI as Collaborator Native: 최종 유저 관점으로, AI가 사용자 작업 흐름 안에서 자연스럽게 협업 가능한가?

예전에 적은 기호론 관련 글으로 사고하자면, 디자인 시스템은 메타언어로 기능하며, 유저로서는 함축적 기호계로서 기능한다.

AI as Consumer Native

비전: AI가 숙련된 디자이너나 개발자처럼 이해하고, 사용한다

AI-generated output이 기본적으로 디자인시스템을 이해하고 사용한다는 것이다.

현재 가장 많은 메이커들이 시도하는 방식이다. 보통 프러덕트를 만들기 위한 도구이다보니.

Expose your design system to LLMs

Turning Handoffs into Handshakes: Integrating Design Systems for AI Prototyping at Scale

Stitch’s DESIGN.md format is now open-source so you can use it across platforms.

그만큼 지루하고 현학적이며, 그동안 했어야 했는데 안한 기초작업들을 해결하고, 암묵지는 꺼내며, 연결하는 일들이 대부분이다. 마치 접근성처럼

미션: 디자인 시스템의 컴포넌트, 토큰, 패턴, 사용조건, 접근성 규칙등을 Machine Readable 한 규약으로 제공한다

구체적인 태스크들은 이런게 될 수 있겠다.

Token metadata: HEX가 아니라 의미 기반으로 제공

Component Schema: 컴포넌트을 어떻게 사용할 수 있는지에 대한 Prop과 타입을 제공

Usage Rules: 언제 쓰고, 언제 쓰면 안되는지

패턴 및 예제: 조합 가능한 예를 제공해준다

API 제공: llms.txt, mcp, skill 처럼 AI 가 인식할 수 있는 도구를 제공한다

이때 API 제공만 해놓고 우리 AI에 최적화된 시스템을 만들었어요~!! 하는 경우를 많이본다.

실제론 다른 것보다 우선순위가 낮은 작업이다. 호출 도구에 불과하니까.

사람에게 엉망인 라이브러리와 가이드만 덜렁 던져주고 알아서 만들라고 해놓고 다했다는 것과 별반 다를바가 없다. 학문적으로 접근하자면 마케팅 믹스에서 Place에 해당되는데, Product보다 우선순위가 낮다.

물론 구현을 어떻게 했는가는 또 별개의 일이겠지만?

AI as Contributor Native

비전: AI가 디자인 시스템의 품질, 일관성, 확장성을 높이는 검증 가능한 기여자가 되며, 스스로를 개선한다

디자인 시스템이 AI의 도움으로 스스로 관찰되고, 정리되고, 개선이 가능해야 한다는 것이다.

이는 과격하게 들리지만 전혀 이상하지 않다. pi-autoresearch, A-Evolve, HyperAgents 등 시스템 스스로 개선하는 루프를 만드는 컨셉이 존재하며, 컴파일러에서는 Bootstrapping 으로 알려져있다.

특히 AI 가 활용 및 트리거하는 시스템을 반복 개선하는데에는 AI가 더 잘할 수 있는 부분이 분명 존재한다고 본다.

미션: AI 가 컴포넌트와 토큰을 생성 및 확장할 수 있으며, 발견한 문제, 개선안, 문서, 마이그레이션, 패턴 등울 검토 가능한 기여로 전환하는 체계를 만든다.

Generator: 컴포넌트, 문서,마이그레이션 등을 만들거나 개선할 수 있다

Pattern Discovery: 프로덕트에서 시스템화 할 만한 것들을 발견하고 제안한다

전역 시스템 최적화: 문서, 각종 툴등 시스템 자체를 평가할 방법을 찾고, 반복적으로 개선한다

사람은 신경을 많이 쓴 부분은 정말 좋은 결과를 낼 수 있지만 아닌 부분은 실수나 빼먹는 부분들이 많이 생길 수도 있지만 기계는 그렇지 않으니까.

좋은 지표를 만든다는 가정하에 반복적으로 개선하여 달성하는 부분은 쉬지않고 병렬로 실험을 돌려보고 비교가 가능하다는 점에서 사람보다 기계가 유리한 부분이 있을 것이다. 또한 사람은 이 일을 당장 하는게 임팩트가 있는지도 계속 검열해야 하지만, 기계는 값싸게 즉시 실행해볼 수도 있다.

어떤게 될 수 있을까? 다음과 같은 벤치마크과 같은 걸 각 디자인 시스템에 특수화 시켜 직접 구축한다라고도 취급할 수 있다.

코드를 잘 만들 수 있는지에 대한 Design2Code, DesignBench, FrontendBench

UI/UX가 잘 구성되었는지에 대한 UICrit, MLLM as a UI Judge, WiserUI Bench

이제 본격적으로 observing이 가능하고, 지표화와 작고 빠른 실험으로 개선할 수 있는 시스템으로 나아가게 된다. 테크블로그에 메트릭과 AI의 활용을 함께 두었던 이유기도 하다.

이때 메트릭도 중요하지만 탐색가능성도 중요하다. 이상적으로는 모든 레포를 인덱싱 해두고, 즉시 즉시 체크하거나 툴링에 텔레메트리를 심어두고 버전, 자주 사용하는 컴포넌트, Broken하거나 Custom 해서 사용하는 컴포넌트 정보들의 현황을 바로 파악하고 개선점을 찾아내는 것이지만 분기당 Batch 프로세스로 경향을 추출할 수 있는 정도여도 괜찮다고 본다.

이외에 조직적 관점으로도 탐색가능성은 중요하다. 예전에 Reimagining Design Systems at Spotify때 이라는 글을 보았을때 이게 정말로 잘 동작할까? 라는 의문이 있었다.

Encore 내부에는 여러 디자인 시스템이 있으며, 각 시스템은 회사 내 서로 다른 팀에서 관리

마치 마한이나 가야 같은 연맹체 국가처럼 운영되는 것처럼 들렸기 때문이다. 미국이나 독일 같은 연방제가 아니라.

아니나다를까 약 5년이후, 다음과 같은 회고가 올라왔다.

Why Federated Design Systems Keep Failing

중앙 집중식 모델에는 무엇이 필요할까요? 전담팀, 명확한 책임 소재, 그리고 프로세스가 필요합니다. 복잡성이 낮아지고, 조정 부담이 줄어들며, 책임 소재가 명확해지고, 가치를 더 빠르게 보여줄 수 있습니다. 대부분의 경우 답은 명확합니다. 중앙 집중식 모델이 더 간단합니다. 탄탄한 기반이 마련되면 나중에 분산형 기여 패턴으로 발전시켜 나갈 수 있습니다. 연합형 설계를 시작한다는 것은 기본적인 설계 시스템 문제를 해결하기도 전에 가장 복잡한 조직적 과제를 해결하려고 한다는 것을 의미합니다.

이러한 의사결정 프레임워크로서 나는 LinkedIn과 Spoqa의 사례가 좋았던 같다. 각각 전술과 전략 같은 느낌으로.

The LinkedIn DPH Framework

스포카 마켓플레이스 (슬라이드)

AI as Collaborator Native

비젼: AI가 제품 경험의 자연스러운 협업자로 작동한다.

최종 프로덕트에서 유저가 앱과 상호작용할때 AI가 참여하여 함께 경험한다는 것이다.

이 또한 넓은 커버리지가 필요하다.

미션: 자동완성, 추천, 요약, 설명, 실시간 생성등 AI 개입 방식을 일관된 사용자 경험 패턴으로 표준화한다.

AI를 활용할때 자주 쓰는 패턴에 대하여 제공

자동완성과 같이 AI와 직접 상호작용하는 컴포넌트

AI가 직접 UI를 생성할 수 있도록 시스템 구축

간단하게는 prompt-kit 처럼 AI 용 어플리케이션용 패턴 라이브러리를 제공할 수도 있다. (기존 디자인시스템을 보완하는 수준)

조금 더 나아가면 통제된 방식으로 컴포넌트에서 대응하는 .NET Smart Components 와 같은 형태를 취할 수도 있다.

사이즈가 큰것은 마지막인데 많은 오픈소스 실험들이 일어나고 있고, 존버를 해보아도 좋다고 생각한다.

Generative UI Spectrum: How Agents Now Ship Their Own Interfaces

생성형 UI 패러다임은 결과물을 잘 통제하기 위해 디자인시스템을 활용하려는 방향을 취하고 있으며, SDUI(Server Driven UI)에서 얻는 러닝을 그대로 사용할 수 있다고 본다.

Server-driven UI로 토스의 마지막 어드민 만들기

Server Driven UI 호출 구조 개선

예컨데 MCP-UI는 Shopify의 RemoteDom을 활용하고 있다. 초반에는 지금보다 더 노골적으로 사용했었는데 흔적이 덜해졌다.

따라서

서버에서 순수한 컨텐츠만 내려주는 Headless CMS

서버에서 데이터와 UI 배치까지 내려주는 Server Driven UI

에 정해진 로직이나 컨텐츠에 더하여 생성된 컨텐츠와 UI 까지 추가로 다루게 되었다고 보아도 무방하다.

이번에 Tanstack에서 RSC 를 내놓았다.

https://tanstack.com/blog/react-server-components

이를 보고 몇가지 정리나 해볼까 하여 작성한다.

분류기준

RSC가 핫하긴 하지만 SSR, 아일랜드, 재개가능성과 같이 다른 설계안들이 분명 존재한다. 이를 일관적으로 분류할 축들을 구성해보자.

가능하면 직교하는 축으로 볼 수 있는 것으로 구성해보았다.

렌더링 위치: 어디에서 UI를 구성하는가?

서버, 클라이언트, 빌드타임, Edge 등

전송 포맷: 네트워크를 통해 무엇을 보내는가?

HTML, JSON, RSC Payload, JS Bundle 등

상호작용 방법: 어떻게 인터렉티브 하게 만드는가?

Hydration, Resumability 등

갱신/소유권 단위: 첫 렌더링 이후 업데이트를 누가 어떤 단위로 소유하는가?

HTML Document, Component Subtree 등

이후 내용은 웹에서 렌더링이라는 글을 보고 오면 도움이 될 것이다.

SSR(Server Side Rendering)

SSR은 옛날 FastCGI, PHP/JSP/ASP 시절부터 내려온 전통있는 방식의 렌더링 방식이다.

말그대로 렌더링 위치에 대한 내용과 가깝다.

서버가 React, Vue 같은 컴포넌트를 실행하여 HTML 을 만들고 내려주는거니까.

또한 보통 초기에 HTML을 내려주는 것만을 SSR로 취급하는 경향이 크다.

렌더링 위치: 서버

전송포맷: HTML Document / HTML Stream

상호작용 연결: 일반적으로 Hydration 필요

갱신단위: Page / Route

SSR을 하게 되면 HTML로 보내주니,

브라우저는 바로 파싱할 수 있어 FCP 가 개선되는 경향이 있다.

물론 SSR 이후에 일반적인 웹프레임워크는 정보를 복원하는 Hydration 과정을 가진다.

하이드레이션은 다음을 뜻한다.

Listeners: 이벤트 리스너를 찾아 DOM 노드에 설치해 앱을 대화형으로 만듭니다.

Component tree: 애플리케이션 컴포넌트 트리를 나타내는 내부 데이터 구조를 구축

Application state: 애플리케이션 상태를 복원

Islands

Islands는 Astro나 Fresh에서 유명해진 개념으로 클라이언트의 렌더링 경계를 수직적으로 나눈다.

즉, 대부분의 페이지는 서버/정적 HTML로 두고, 상호작용이 필요한 컴포넌트만 독립적으로 Hydration 되는 구조다.

렌더링 위치: 기본 페이지는 서버/빌드타임, 상호작용이 필요한 UI 컴포넌트는 클라이언트

전송포맷: HTML Document + islands 별 JS 번들

상호작용 연결: islands별로 Hydration 필요

갱신단위: 개별 islands 단위로 Dom subtree 소유

단점은 각 Islands는 격리되어 있어 직렬화하여 데이터를 주고 받기가 어렵다.

서버 컴포넌트가 Islands에도 있어 JS 번들 없는 HTML을 각각의 Islands에 보내주는게 가능하다.

Data fetch, 마크다운 파싱, 권한 분기등이 서버에서 처리가능하니 자연스레 실행해야할 JS는 줄어든다.

RSC(React Server Component)

RSC 는 컴포넌트 실행 위치, 전송 포맷, 번들 분리 등 전반에 영향을 미칠 수 있는 개념이다.

미리 Server Component Tree를 실행하고, 그 결과를 React가 이해할 수 있는 RSC Payload 혹은 Flight stream 형태로 클라이언트에 전달하는 형태에 가깝다.

렌더링 위치: Server Component는 서버/빌드타임, Client Component는 클라이언트

전송 포맷: RSC Payload / Flight stream

상호작용 연결: Server Component는 Hydrate 되지 않고, Client 컴포넌트에 한해서 Hydrate

갱신 단위: Route / Component Subtree / Suspence Boundary

SSR 과 혼동을 겪는 경우도 있으나 React 공식문서처럼 함께 사용이 가능한 개념이다.

그렇다면 SSR 대비가지는 장점이 무엇이냐? 서버 컴포넌트를 실행하여 번들에 포함하지 않는다.

혼란스러운 점은 Next RSC는 서버 우선, Tanstack RSC는 클라이언트 우선으로 구현이 상당히 다르다.

먼저 서버 우선 RSC. 앞서 나왔던 Islands와도 벌써 헷갈린다. (특히 Preact 기반으로 만들어진 Fresh와 SSR + RSC는 더더욱)

Fresh의 Islands는

서버에서 SSR로 그려진다 (이때 Islands 에 있는 것들도 SSR로 그려진다)

브라우저가 HTML과 각 Islands JS번들과 직렬화된 Prop들을 받는다.

각 Islands가 하이드레이션 된다.

Next의 SSR + RSC는

먼저 Server component를 실행하여 RSC Payloads로 만든다.

클라이언트 컴포넌트와 함께 실행하여 SSR로 HTML 을 렌더링한다

브라우저가 HTML과 Payloads 를 받는다. Payloads 에는 클라이언트 컴포넌트가 들어갈 플레이스 홀더, 크라이언트 컴포넌트 JS 참조, Props 등을 담는다.

Payloads 를 이용해 React Tree를 맞추고 Client 컴포넌트를 하이드레이션 한다.

개별 앱처럼 관리되는 Islands와 달리, RSC는 하나의 React Tree로서 관리된다. 결국 "상태"의 경계가 가장 큰 차이다.

서버 컴포넌트에서 import한 클라이언트 컴포넌트 children으로 서버 컴포넌트가 들어갈 수 있다.

역으로 클라이언트 컴포넌트에서 서버 컴포넌트를 import하는 것은 불가능

클라이언트 컴포넌트의 props는 직렬화 가능해야 함 (Serve function, Server Action 예외)

각 Islands 는 직렬화된 메세지 방식으로 소통해야하지만, RSC의 Client는 하나의 Tree이므로 자연스럽게 일반 React처럼 사용할 수 있다.

업데이트될때도 Islands 는 HTML 조각을 바꿔치는 반면, RSC는 RSC Payloads 를 받아 기존 Tree에 병합하고 조정한다.

때문에 Islands 는 다시 mount 되는 반면, RSC 는 상태를 유지하며 자연스럽게 업데이트 된다.

보다보면 계속 이어지는 의문.

Server Function과 Server Action은 무엇인가?

Server Function은 서버에서 실행되지만 Client 컴포넌트에서도 호출 가능한 함수다. 클라이언트에서 호출하면 서버에서 함수를 실행하고, 인자와 반환값은 직렬화되어 오간다.

Server Action: Server Function 중 action/mutation 문맥인 것이며, 몇가지 특수한 차이가 있다.

첫번째 인자로 자동으로 form data가 들어옴

Javascript가 로드되지 않거나 비활성화 되어 있어도 submit이 가능

업데이트된 UI와 Data를 한번의 라운드 트립으로 갱신 가능

useActionState와 결합된 Form 모델을 제공하여 pending, response, validation, form state를 하나의 모델에서 다루는게 가능

좋다. 이제 Tanstack의 클라이언트 중심 RSC에 대해 다루자.

나는 역전된 Island 구조로, RSC Payload island라고 생각한다.

각 RSC Payload 를 Query/Router가 독립적으로 fetch/cache

필요한 RSC fragment 만 client가 요청 (fetch, cache, render 단위)

당연하지만 Next RSC 와는 비교가 될 수 밖에 없다.

캐싱/네비게이션이 모두 Next Approuter 종속적이었던 반면, Tanstack Query/Router를 활용하는 방식

renderProps를 활용해식 서버 데이터로 클라이언트 Slot을 호출 가능하다. 즉, 특정 Slot에 클라이언트가 알고 있는 인터렉티브한 컴포넌트를 동적으로 렌더링하는게 가능하다.

장기적으로 두가지 모델이 합쳐진다면,

Next의 빠른 초기 성능을 얻을 수 있음

일부의 서버 렌더링 조각만 교체가 가능해지므로 유연해짐

페이지 전체를 무효화하지 않아도 되므로 세밀한 캐시 관리도 가능해짐

데이터는 서버에서 다루고, 인터렉티브한 동작은 클라이언트에서 다루는 원래 원하던 목적 달성이 쉬워진다

HTML over the wire

요즘(?) 보통의 개발자들에게 가장 생소한 방식일 것이다.

Hotwire 나 Livewire, Phoenix LiveView로 알려져있다.

이번에는 한층 더 과격하게 생각해서 Tanstack RSC Payload가 SSR이 되면 어떨까?

렌더링 위치: 대부분 서버, 인터렉티브한 일부분만 클라이언트

전송포맷: HTML Document, HTML/Stream Fragment

상호작용 연결: Native 이벤트 기반

갱신단위: DOM Target, frame, page

Hotwire/Turbo는 HTML을 Websocket, SSE, Form submission으로 보내는 매우 정직한 SSR fragment over HTML 형태이며,

Livewire는 상태를 지키기 위해 HTML Template + JSON Snapshot을 두고 전송받은 HTML에서도 필요한 부분만 morph로 바꾼다.

마지막으로 LiveView는 아예 Stateful한 서버와 통신을 하며 실시간으로 갱신하는 형태다.

당연하겠지만 RSC가 아니다보니 같은 Tree라고 보기는 어려움이 있다보니 Server Component 안에 Client 가 들어가고, Client 안에 다시 Server가 들어가는 형태는 꿈꾸기 어려우나 재밌는 컨셉이라고 생각한다.

적어도 Routing 사이처럼 커다란 변경이 있는 경우에는 HTML over the wire 컨셉이 유효하지 않을까 싶다.

가장 의문을 가질만한 것은 어떻게 이벤트 연결이 일어나고 교체 될 것인가인데? Hotwire 기준, 링크/폼 이벤트를 인터셉트하여 HTML을 바꿔친다. 또한 Stimulus가 MutationObserver로 감시하고 있다가 data-controller, data-action, data-target 과 같은 Attribute를 기준으로 Lifecycle method를 실행하여 연결한다.

완전한 Hydration 보다는 Listener 바인딩에 가깝다고 해야 할까나.

Resumability

Resumability(재개가능성)은 Qwik이 만든 혁신적인 클라이언트 컴포넌트 모델이다.

렌더링 위치: 주로 서버/SSG

전송포맷: HTML + 직렬화된 listener/state/component metadata

상호작용 연결: resume

갱신단위: component/event 경계

Resumability 서버에서 생성된 실행 컨텍스트를 브라우저가 이벤트 시점에 이어받는게 가능하다.

그래서 처음부터 컴포넌트 트리를 재실행하지 않고, 이벤트가 발생하거나 상태가 필요한 지점에 필요한 코드만 로드하고 실행을 이어갈 수 있다.

반대로 이러한 이유로 React에서는 Resumability를 달성하기 어렵다.

Signal을 사용할 경우 초기화된 이후에 사라지는 Component Tree, 세분화된 상태 업데이트로 가능하지만

React는 전체 Tree, 상태복원, mismatch와 같은 어려운 점들을 해결하는게 필요하기 때문이다.

그래서 Qwik은 핸들러까지도 직렬화한 상당히 과격한 재개가능성을 재공하는 한편, 다른 프레임워크는 약간의 타협을 하여 구현한다.

Marko는 이벤트 리스너를 연결하고 상태를 직렬화하되 템플릿을 재랜더링하지 않는다.

Angular는 Wiz에 있던 JSAction를 활용하여 Root에서 이벤트 디스패치를 받은 후, 하이드레이션이 되면 이벤트를 처리해주는 방식

어떻게 하면 좋은 SW를 만들 수 있을까? 그 중 하나는 버그가 적은 SW를 만드는 것이라 바로 떠올릴 수 있다.

그렇다면 버그가 적은 SW는 어떻게 만들어야 하는가? 그리고 버그가 아예 없을 수 있을까?

특정한 케이스들에서는 가능하다. 모든 논리를 프로그램에 넣으면 되기 때문이다.

그리고 증명용 언어는 버그가 없다는 것을 정적으로 증명할 수 있다.

하지만 일반적인 케이스에서는 난이도가 높고, 한계가 명확하기 때문에 다음과 같이 레이어를 쌓아올리는게 어떤가 한다.

타입: 타입 시스템을 활용하면 자연히 Input과 Output의 데이터에 관심을 가지게 되므로, 좋은 설계를 하는데 용이하다.

스키마: 타입은 유용하지만, Runtime에서 값이 들어오게 되는경우는 취약하다. 타입시스템에서 상정하지 않은 다른 계의 사이드이펙트이기 때문에 어쩌면 당연하다 할 수 있다. 스키마를 사용한다면 선언적으로 런타임에서 검증이 가능하다.

테스트: 스키마가 존재해 유효하지 않은 값이 들어오는 것은 막을 수 있으나, 실제로 기능과 동작이 의도와 일치하는지까지는 보장하지 않는다. 이는 테스트 코드로 보강할 수 있다. 단순한 케이스는 유닛테스트로 Input과 Output을 체크할 수 있으며, 복잡한 경우는 구조를 체크하는 스냅샷 테스트, 형태를 체크하는 시각회귀테스트, 전체 모듈의 기능을 체크하는 통합 및 E2E 테스트를 생각할 수 있다.

이 글은 아직 도입된 시스템은 없지만 일관적이고 안전하고, 깔끔하게 UI를 구현하기 위한 제안이자 습작이다.

컴포넌트를 만들다보면 일관적인 인터페이스와 그리고 제약을 주기가 어렵고, 규칙들이 쉬이 무너진다.

어떤 컴포넌트는 readOnly인데도 값이 바뀌고,

어떤 컴포넌트는 disabled인데도 클릭 이벤트가 타고 들어가며,

어떤 컴포넌트는 ARIA가 빠져서 접근성이 깨지고,

결국 코드베이스 곳곳에 if (disabled) return;이나 disabled ? : 와 같은 조건문들이 흩어지게 된다.

나는 이 문제를 “컴포넌트별 분기 로직”이 아니라 Capability + Policy라는 구조로 해결해보자는 컨셉을 제안한다. 목표는 단순하다.

Capability: 기능의 부여와 사용은 플랫폼의 영향이 아닌한, 명시적으로 이루어지며 동일한 인터페이스를 가진다. 구현은 별개.

Policy: 정책은 일관적으로 적용되며, 차단돼야 하는데 실행되는 경로를 막는다.

확장성/번들 최적화: 중앙 레지스트리 없이, 필요한 기능만 부여하게 하고, 필요한 정책만 import해서 확장 및 트리 셰이킹 가능하게 한다.

1. 영감

이는 분명히 영감을 받은 컨셉들이 몇가지 존재한다. 영감을 받은 컨셉들의 의의에 대해 파악한다면 어떤말을 전하고자 하는지 더 쉬울 것이다.

Flutter Box Model: 제약을 전달받고, 크기를 결정하는 것처럼, 능력으로 확장하고 정책으로 제약한다. - https://docs.flutter.dev/resources/architectural-overview#layout-and-rendering

Scalar와 Rust의 Trait: 능력은 인터페이스에 의해 확장되며, 재사용된다. - https://docs.scala-lang.org/tour/traits.html - https://doc.rust-lang.org/book/ch10-02-traits.html

Object-capability model: 능력은 주어진 객체의 조합에 의해 이루어지며, ACL처럼 중앙제어 형태가 아니다. - https://en.wikipedia.org/wiki/Object-capability_model - https://borretti.me/article/introducing-austral#cap - https://en.wikipedia.org/wiki/Access-control_list

ABAC: Attribute-based access control과 같이 제약을 주는 것은 정책의 뜻을 가진 속성이다. - https://en.wikipedia.org/wiki/Attribute-based_access_control

2. 멘탈 모델: Capability는 늘리고, Policy는 줄인다

이 접근의 사고방식은 두 문장으로 정리됩니다.

Capability로 능력을 부여한다. 능력은 합집합으로 늘어난다.

Policy로 능력을 제한한다. 제한은 합집합으로 제거된다.

즉, 컴포넌트는 여러 capability를 조합해 “할 수 있는 것”을 늘리고, 정책(disabled, readOnly 등)은 활성화된 것들의 효과를 합쳐 “할 수 없는 것”을 제거한다.

여기서 말하는 capability는 보안 토큰(인가) 같은 의미가 아니다. UI에서 부작용(side effect)을 일으키는 경로를 통제하기 위한 설계 규율에 가깝다. 서버/도메인 인가를 대체하지 않는다.

3. Capability Trait: “부작용 경로”를 표준화한다

Trait은 행동(메서드/부작용 경로)만 정의한다. 반면, State(표현/조회 데이터의 구체 형태)는 trait이 아니라 컴포넌트가 props로 결정해야한다.

이게 중요한 이유는 간단하게 떠올릴 수 있다.

정책 시스템은 “선택 상태가 배열인지 Set인지” 같은 구현 디테일을 몰라도 되기 때문이다.

오직 “부작용 경로(예: onChangeSelection)”만 보면 되는 것이다.

4. Policy: 활성 정책들의 “합집합”으로 제한한다

disabled, readOnly는 Policy이다. 여러 policy가 동시에 켜지면, 그 효과는 “합집합”으로 계산한다.

전역 우선순위를 문서로 강제하지 않아도 결과가 결정적이라는 점이 최대 장점이다.

“추가 정책이 더 많은 기능을 허용하는” 이상한 상황을 피할 수 있다.

5. Guard: “이 policy가 켜지면 어떤 capability를 제거할까?”

Guard는 다음을 정의한다.

policy -> denyKeys : 어떤 prop(능력 경로)을 제거할지

policy -> patch : 접근성 속성 등 보조 패치가 필요하면 제공

여기서 중요한 운영 포인트는 중앙 레지스트리가 없다는 것이다.

trait 옆에 guard를 co-locate하고, 컴포넌트는 필요한 guard만 import해야 한다. (트리 셰이킹 친화)

6. 차단 방식: no-op 래핑이 아니라 “존재 자체를 없앤다”

차단을 () => {} 같은 no-op 래핑으로 하지 않는다. omit/unset(핸들러 제거)로 한다.

컴포넌트는 props.onX?.()처럼 존재할 때만 호출하여 정책이 켜지면 해당 키가 없어져 “실행 경로가 성립하지 않게” 만들어야 한다.

예시로 보는 설계: MultiSelectable

Capability Trait: 선택 변경 능력만 표준화

선택 상태가 배열인지 Set인지, 그건 trait이 알 필요가 없다.

// traits/multiSelectable.ts export interface MultiSelectable { onChangeSelection(next: Selection): void; }

Guard: disabled/readOnly에서 커맨드 경로 제거

// traits/multiSelectable.guard.ts import { defineCapabilityGuard } from "../policy/core"; import type { UiPolicyKey } from "../policy/types"; import type { MultiSelectable } from "./multiSelectable";

export const multiSelectableGuard = defineCapabilityGuard>()({ disabled: ["onChangeSelection"] as const, readOnly: ["onChangeSelection"] as const, });

여기서 포인트는 단 하나이다. 정책 시스템은 Selection 타입을 몰라도 된다.

어려운 근본적인 이유는 세계가 복잡하기 때문이다.

입력 행태를 약 6가지로 나뉘어볼 수 있을 것이다.

1. 조합형 Composition (preedit/조합 문자열)

사용자가 키를 누르는 동안, OS/IME가 아직 확정되지 않은 문자열(preedit)을 유지합니다.

웹에서는 보통 compositionstart/update/end가 발생하고, 조합 중 이벤트에는 isComposing이 true가 됩니다.

후보 창이 없어도 조합형일 수 있습니다. (핵심은 “미확정 문자열(preedit)”이 존재)

예: 한국어

2. 후보-변환형 Conversion (candidate selection/후보 선택 변환)

preedit(조합 문자열)을 기반으로 후보 목록(candidate window)을 띄우고,

사용자가 Space/Enter/숫자키/화살표 등으로 후보를 선택한 뒤 확정합니다.

웹 버그 관점에서 Enter/Space/Arrow 키 충돌이 특히 강하게 나타나는 유형입니다.

예: 중국어, 한글에서 한자

3. 코드입력 Code input (입력 코드가 출력 문자와 다름)

사용자가 누르는 키(코드)가 곧바로 출력 문자가 아니라, IME가 해석해서 preedit 문자열을 만드는 방식입니다.

실시간 검증/검색, 포매팅과 맞춤범 검사, 숫자와 Enter/Space/Arrow 키충돌이 일어날 수 있습니다.

코드에는 하위 종류가 있습니다. 1. 발음코드(전사, Transliteration/Romanization): 로마자 발음으로 입력 (예: 일본의 Romaji, 중국의 Pinyin) 2. 자형코드(형태코드): 글자 모양/부수 기반 (예: 중국의 [Wubi](https://en.wikipedia.org/wiki/Wubi_method와, Cangjie) 3. 키배치코드(레이아웃 매핑): 키보드 레이아웃에 따라 매핑 (한글 2벌식의 r→ㄱ 같은 것)

전사형과 자형은 버그가 나타나는 양상은 비슷합니다. 대신 특징이 있다면

전사형은 발음대로 쓰는거기 때문에 "그럴듯한 로마자"가 나와 검색이나 맞춤법에서 충돌이 많습니다.

자형은 "무작위 로마자"로 보이는 경우가 많아 스팸필터에 걸리고, Space로 변환하는 경우들이 존재해 조심해야 합니다.

레이아웃 매핑은 어플리케이션 로직 자체의 문제인 경우가 많아 다루지 않아도 될 것 같아요.

4. 후행치환 Replacement (뒤에서 앞글자를 바꿈)

나중에 친 키가 이미 입력된 글자(또는 조합 중인 글자)를 치환/변형합니다.

웹 버그 관점에서 마스킹/포맷팅/커서복원 로직과 충돌이 특히 잦습니다.

예: 베트남어 Telex/VNI, 유럽권 Dead key(악센트 키), 자동수정/자동치환 등.

이때 유럽의 Dead key는 별도의 키보드 이벤트가 존재합니다.

5. 이어쓰기(Joining) / 결합부호(Combining marks) / 제어 문자

이건 IME 자체 문제라 보기는 어렵습니다만 문자를 다룰때 실수할 여지가 있습니다.

아랍어는 이어쓰고 컨텍스트에 따라 모양이 변형되기 때문에 하이라이팅시 span으로 쪼개는 동작을 조심해야합니다

마찬가지로 아랍어는 결합문자도 존재합니다. 이는 이모지에 의해 요즘은 아는 사람들이 많아졌습니다. 글자수 계산을 조심히 해야되겠죠.

아랍어는 다들 알다시피 RTL 문자체계입니다. 그래서인지 방향제어 문자 들도 사용되어 폰트에서 중요시 여겨집미다. 앞서 이어쓰기의 경우에도 필기체로 이어짐을 끊기위해 ZWJ가 사용됩니다.

6. 가상 키보드 및 3자 도구와 상호작용

더 심연은 SW기반 입력도구들입니다.

안드로이드, iOS의 가상 입력 도구들

개인적인 취향이 상당부분 반영되어 있지만 평소 모노레포 빌드/태스크에 대해 가지고 있던 생각을 정리해보았습니다.

1. 프론트엔드 모노레포 빌드/태스크 구조

빌드나 각종 명령어 실행에 있어서 3가지 정도로 나뉠 수 있을 것 같다.

작업 종속성: 분리할 수 있는 작업은 분리하여 실행하거나 병렬적으로 실행한다

작업목적의 차이: 라이브러리냐, 앱이냐? 빌드냐 테스트냐 등에 따라 달라짐

실행환경의 차이: 로컬에서는 빠르게 여러번 실행하고, 서버에서는 최대한 많은 검증을 한다.

작업종속성

패키지 종속성: 패키지만 설치되면 검증 가능한 작업들

타입 종속성: 타입이 빌드되야 검증 가능한 작업들

빌드 종속성: 빌드가 되어야 검증 가능한 작업들

패키지만 설치되면 검증 가능한 작업들로는 패키지 매니저의 lockfile, peerDeps 검증, prettier/eslint와 같은 포매팅과 린팅 작업이 있다.

의외로 타입 검증 작업은 빌드 작업과 별개로 가능하다. 다만 typescript-eslint와 같이 타입이 빌드되야 린트 검증이 가능한 가능한 경우가 있다.

모노레포에서 테스트는 의존한 패키지의 빌드가 되어있어야 실행가능하다.

작업목적의 차이

패키지 목적: 라이브러리 / 앱 / 환경설정 / 테스트

번들러 목적: 빌드 / 개발서버 / 테스트

작업목적에 따라 실행해야할 작업들이 상이하다. 예를 들어 라이브러리는 ESM/CJS 빌드, 타입 빌드 모두가 필요하다. 앱은 빌드 결과물 1개와 타입체크, 환경설정용/테스용은 타입 체크 정도만 필요하다.

또한 똑같이 번들러 작업이 필요하다고 해도, 빌드, 개발서버, 테스트등 작업 따라 필요한 플러그인이 다르다.

실행환경의 차이

로컬에서 개발하며 실행

리모트에서 검증

개발 환경은 모든 환경을 고려하기보다는 빠르게 실행되어 코딩-빌드-테스트 이터레이션을 여러번 돌릴 수 있게 만드는게 합리적이다. 따라서 특히 개발서버는 ESM 환경에서 실행하는 vite, 마찬가지로 vitest 또한 ESM Native를 사용하는 등 가능하면 ESM Only를 전제하고 패키지를 설정해야 한다.

반대로 리모트(PR 시)는 최대한 많은 것을 검증함이 좋다. 위에서 언급된 작업 종속성에 따라 나누고, 모든 검증 태스크를 돌리자. 다만 리모트 작업에서도 검증과 릴리즈는 달라질 수 있다.

예를 들어 라이브러리같은 경우 검증단계에서는 타입 빌드와 JS 빌드가 각각 나뉘어 실행될 수 있지만, 릴리즈시에는 통합적으로 일어나야 한다.

2. 패키지 매니저

프론트엔드 모노레포에서 첫번째로 생각나는 것은 무엇인가? 난 패키지매니저를 뽑고싶다.

여러종류의 패키지를 운영하며, 각 패키지마다 의존성들을 설치하고 관리하는 기능이 필수적으로 들어가기 때문이다.

그 중에서 yarn을 가장 좋아하는 편이다. 다음 글에 나온대로 잘 설계된 아키텍처와 정확성, 성능이 마음에 든다.

패키지 매니저의 과거, 토스의 선택, 그리고 미래

우선 패키지 매니져로서 기본기는 훌륭하다.

안정적인 lockfile 업데이트

lockfile과 pnp.cjs의 conflict 자동해결

간편한 패키지 패치

NPM script를 위한 휴대용 shell 내장과 스크립트 공유

이외에 각종 검증기능이 달려있다.

Hardened Mode: resolution 체크등으로 install시 보안공격 보호

락파일/캐시 변경 감지

Constraints: 패키지와 필드에 대한 검증

Constraints에서는 대체 어떤게 가능한가?

패키지 금지: 쓰지 말아야 할 패키지를 정할 수 있다

동일한 패키지 버전: 모노레포에서 사용할 패키지 버전을 일관적으로 유지 가능

패키지 버전 범위 통제: 패키지의 버전이 특정 범위에 속하는지 제약을 줄 수 있다

워크스페이스 페키지 강제: 워크스페이스에 있는 패키지는 고정버전이 아니라 워크스페이스 프로토콜을 쓰도록 강제가 가능

피어 디펜던시 누락 검증 및 자동추가: 피어 디펜던시가 누락되었는지 체크하고, 에러를 발생시키거나 자동적으로 devDeps/Deps에 누락된 패키지를 추가

package.json의 필드 제약: 예를 들어 패키지 이름에 prefix가 붙어있어야 하는지 검증가능

이 중에서 일부는 PNPM이나 Syncpack을 사용해야 가능하다는 기능을 잠금해제한다. [yarn berry 공식 설정 / yarn-constraints-rules] 예를 들어 동일한 패키지 버전 + 패키지 버전 범위 통제가 가능하고 (물론 yarn-plugin-catalogs라는 플러그인도 존재한다) 피어 디펜던시 설치도 조금의 노력만 들이면 가능하다.

그럼 PNPM에서 가지는 특징적인 기능적 장점은 SideEffect 캐시정도이다. 이것도 아마 플러그인을 만든다면 해결 가능한 이슈로 보인다.

이외에 앞으로 도입될 auto install, yarn run 오버헤드 감소 등의 로드맵도 기대가 된다.

이와 별개로 타입스크립트를 잘 사용하기 위해서는 project reference를 잘 설정하는게 필수인데

에디터 통합: project reference가 잘 설정되어 있어야 workspace root를 에디터로 열어도 패키지의 타입 추론이 가능해진다

적절한 타입추론: App.tsx와 vite.config.ts처럼 환경에 따른 적절한 타입추론을 위해서는 project reference 설정이 필요하다

성능: tsc --build를 통해 빌드하면 토폴로지컬한 증분빌드가 가능하다.

문제는 제대로 설정하기나, 자동으로 설정하기가 어렵다. root, local, package 참조에 따라 모두 설정해줘야 하기 때문이다. 다행히 저도 약간 기여한 @monorepo-utils/workspaces-to-typescript-project-references를 사용하면 해결이 가능합니다. (yarn과 npm만 가능)

현재 남아있는 가장 큰 불만은 Changeset에서 제대로 작동하지 않다는점이다. yarn pack을 먼저 실행하고 publish 하는 방법으로 우회가 가능하긴 하지만..

3. 린트 / 포매팅

파이썬을 사용했을때가 가끔 그리웠던 것 중 하나는 ruff이다. prettier/eslint 분리를 생각할 필요가 없고 에디터에서 거의 즉시 린트와 포매팅이 가능했기 때문이다.

그러한 면에서 Biome가 동일하게 기대된다.

다만 완전히 대체가 가능할지 미지수다. Prettier는 확실히 가능하겠지만, ESLint의 풍부한 플러그인/설정 생태계에 비할바는 아니다.

예를 들어 typescript와 통합에 있어 projectService와 같은 기능이라거나 yaml과 같은 추가적인 lint 기능들이 존재하지 않는다.

따라서 현재로선 lint는 eslint로, formatter는 biome와 함께 쓰는 방향이 합리적이라 생각한다. formatter의 경우도 vue, mdx, yaml, toml과 같은 파일등도 함께 지원해야 한다면 prettier에서 못넘어가지 않을까

4. 빌드

Biome와 동일한 맥락으로 Rolldown이 미래이며, vite에서도 실험적으로는 적용중이지만 안정화에는 1년은 걸리지 않을까?

CSS 후처리 역시 Lighting CSS와의 통합으로 매우 빠른 성능을 달성할 수 있다.

역시 문제는 빌드시 성능 병목인 타입 빌드다. 지금도 일반 빌드는 10초면 끝나지만 타입 빌드는 vite-plugin-dts를 사용하면 1분 넘게 걸린다.

미래에 Typescript Native(Typescript 7.0)가 사용되면 좀 빨라지겠지만 근본적으로 플러그인이 비효율적으로 설계되어 느리다는 생각은 버릴수가 없다.

때문에 vite-plugin-dts-build라는 vite 플러그인을 만들었다. (Type rollup 기능을 제공할 생각이 없어 vite-plugin-tsc-build라고 붙이고 싶었는데 이미 있더라ㅠㅠ)

tsc --build 처럼 증분빌드

분리된 워커에서 병렬 실행

vite의 library mode에서 여러 format이 실행될때 중복으로 실행되지 않음

3번은 직관적으로 이해가 가지 않을 것이다. 부연 설명을 하자면 CommonJS와 ESM을 동시에 지원하려면 각각을 대응하는 package.json export가 필요하며 따라서 각각의 mjs, cjs를 빌드해야 한다. 이때 plugin은 2번씩 실행된다.

타입도 그에 맞추어 ESM버전과 ModuleKind.CommonJS 및 ModuleResolutionKind.Node10를 사용해야 한다. 그래서 dts 세팅을 2번해줘야 문제없도록 export를 할 수 있다.

문제는 위와 같이 세팅이 된 경우 총 4번이 실행이 되기 때문에 락을 걸어 각 dts 플러그인 설정은 한번씩만 실행되도록 보장했다.

추가) Are the types wrong?을 사용하면 타입이 잘 export되었는지 체크가 가능하다.

예를 들어 vite-plugin-dts는 👺 Masquerading as ESM 문제가 있다. (근데 위 문제를 제대로 처리하는 라이브러리들이 생각보다 적은것 같다...)

이외에 TypeScript 빌드를 더 빠르게 만들 방법도 있는데 일반적이지는 않다.

assumeChangesOnlyAffectDirectDependencies: 영향을 받은 파일들은 재검사/재빌드 하지않고, 변경된 파일과 직접 import한 파일만 재검사/재빌드되므로 정확도가 내려간다

isolatedDeclarations: 병렬적으로 타입을 빌드하거나 검사할때 도움이 되지만, 명시적으로 각 타입들을 코드 단위에서 변경하는게 요구된다

5. 태스크 러너

현재 가장 빈공간이 많은 툴이라 느껴진다.

Yarn의 휴대용 shell + Vercel의 Turborepo의 설정이 정말 간결해서 편하다.

Root와 워크스페이스의 NPM script 공유

Turbo Repo의 증분/병렬실행과 Remote caching

복잡한 스크립트가 필요한 경우는 단순히 NPM script에 쓰이는 스크립트가 아니라 JavaScript (혹은 TypeScript)로 쓰인 태스크 매니저를 원하게 될 것이다.

이를테면 Grunt나 Gulp 같은 것들 말이다.

이 중에는 Gulp의 Task 사용법이 가장 합리적이라 여겨진다.

Gulp의 문제라 한다면, Turborepo와 같은 토폴로지/증분/병렬 실행 기능이 부족하기 때문이다. 패키지 단위의 위상적 실행은 원래 지원하지 않았고, 증분에서는 lastRun이라는 함수가 있지만, 프로세스가 꺼지면 정보가 사라진다. 병렬에서는 parallel이라는 함수가 있지만, 내부에서 사용되는 now-and-later라는 패키지의 코드를 읽어보면 실제 병렬이라기보다는 동시성 기능에 가깝다.

Turborepo의 JavaScript interface를 사용할 수 있다면 참 좋겠지만, 불행하게도 Node와의 인터페이스는 존재하지 않으므로 만약 제작하게 된다면 Microsoft의 Rush(lib)를 사용하는게 현실적이지 않을까? Turborepo의 편안한 인터페이스는 빌리더라도 말이다.

모든 워크스페이스의 태스크, vitest와 같은 것들까지 최적의 실행시간을 보장하려면 위임하여 처리할 수 있는 글로벌 워커 풀 / 프로미스 풀이 구현되는 것도 필요하지 않나 싶다.

프론트엔드에 있어 앞으로 2~3년 내에 행하여 개선하고 싶은 주제로 5개정도가 존재한다.

모노레포 툴링: 모노레포 / 패키지 / 빌드 관련으로 어떻게하면 신뢰성이 있으면서도 빠르게 체크할 수 있는지에 관심이 있다

스타일링: HTML(JSX)를 평정한 리엑트와 다르게 스타일링은 마땅한 관리 시스템이 없다. 어떻게 해야 내용-표현, 형식-실체를 잘 관리할 수 있는가?

레이아웃: 단순한 플렉스박스, 그리드만으로는 레이아웃을 나타내기 충분하지 않다. 또한 디자이너의 시각보정, 사용자의 커스텀, QA하기 쉬운 레이아웃 구조는 어떤것인가?

상태: 이벤트 스트림을 잘 관리할 수 있는 상태 시스템, 빌드타임 CSS와의 상태 상호운용, 커스텀에 열려있는 상태와 컴포넌트 구조. 네이티브까지 포함하면 signal-stream-ecs-store-statechart까지 모두 포괄하는 시스템

문서: 디자인시스템에 최적화된 문서화 시스템. 파운데이션-유틸-컴포넌트-패턴을 모두 다루어야 하며, 디자인/개발 가이드 및 레퍼런스 관리, A/B 시스템 통합등

LLM의 비결정적인 특성 때문에 테스트하기 쉽지않다.

하지만 크게 2가지로 나눌 수 있다. 형식적인 결과와 비형식적인 결과.

형식적인 결과

정의: 형식이 정해져, 마치 API 응답과 비슷한 경우 예시: 스팸인지, 허용되면 안되는 문장인지 등의 여부를 true/false. 1~5점 사이로 별점 먹이기 MMLU처럼 선택지를 주고 고르게 하고 분포를 보기

정량평가: 유저 스토리를 기반으로 테스트 상황을 만들고, 생성되는 값이 예상한 값과 동일하거나 예상 가능한 범위인지 평가합니다. 예를 들어 일정 수위의 폭력적인 문장을 주면 false 가 항상 나와야 하고, 별점 체제로 간다면 2~3점 범위내에서 꼭 나와야 합니다. (이때 테스트 코드를 작성)

LLM 자체가 비결정적이기 때문에, 애매모호한 상황의 경우 3번정도까지는 try를 할 수 있는 것처럼 재시도 가능하게 만듭니다.

비형식적 결과

정의: 문서 생성처럼 형태나 답이 정해져 있지 않은 경우

정성평가: 해당 도메인을 알고 있는 사람이 수동적으로 반복개선한다 ㅠㅠ 일종의 관리기법에 가까우며 예외 케이스가 나올때마다 사례들을 모아두고, 프롬프트에 반영할지(직접적) | 프롬프트 생성 가이드로 사용할지(메타적) 여부를 결정합니다. 각 버전의 생성된 결과물은 로그처럼 보관해두고 비교가능하게 합니다. 저는 git에 다 저장해놨었어요.

정량평가: 원하는 키워드가 들어있는지를 평가합니다. 단순히 텍스트가 들어있는지 검색할 수도 있고요. 조금 더 수치화를 원한다면 BLEU, ROUGE등을 활용할 수 있습니다. LLM이 LLM을 평가하여 형식적인 방법으로 전환하기도 가능합니다. 예를 들어 결과물을 가지고 별점 먹이기

아무래도 비형식적인 결과가 균일한 결과물을 내기가 더 힘들다.

그리고 전문적으로 프롬프팅하려다 보면 노력이 많이 들다보니, 일반적인 경우는 그때그때 케이스 모아두는 방식만 해도 괜찮지 않나 싶기도 하다.

툴링

역시 잘 하려면 전용도구 혹은 IDE 비슷무레한게 필요하다고 생각한다.

프롬프트 IDE의 요건으로는

실행 input-output 타임라인 추적. API 테스트 도구인 bruno정도면 괜찮은 모양새라고 생각한다.

결과물 스냅샷테스트 가능한 환경 위의 정량 평가용 도구들이 통합되어 제공되면 괜찮을 듯

모델 파라미터 설정 GPT Playground 정도면 괜찮은듯?

프롬프트 템플릿 LangChain처럼 체이닝이 가능해야하고, Fluent i18n 처럼 직관적으로 분기가능 등이 있을 것 같다

두 AI 검색 엔진 서비스가 최근에 업데이트하여 간단히 비교정리해본다.

1. Phind

phind는 검색결과를 보여주는 능력이 매우 뛰어나다.

표는 물론이고 Mermaid 다이어그램 표시,

코드 샘플을 보며주며 선택지와 Pros & Cons 정리

마지막으로 정리와 Rember 노트까지..!!

2. Perplexity

Perplexity는 뭔가 전형적(?)인 AI 검색 느낌이다.

이미지 검색도 같이 해주고, 동영상 검색이나 이미지 생성도 할 수 있다는 점이 좋다.

끝에는 추가로 검색할 쿼리도 제공해준다.

3. 추론 비교

두 서비스다 추론 기능이 있다.

다만 Phind는 일반 LLM이나 사람처럼 다소 긴 문장을 쓰며 판단하고

처음뿐만 아니라 중간중간에도 필요하면 사고한다는 장점이 있다.

반면 perplexity는 Phind보다 더 많은 검색소스를 쿼리 및 체크하고, 무려!!! Reasoning 모델!!!!!!!을 쓸수 있다는 장점이 있다.

심지어 딥씩이까지 지원한다.

딥씩이 장점은 역시 CoT 과정을 자세히 볼 수 있다는 것이다.

각각의 사고과정을 독자를 위해 번역기로 돌려 보여주자면 다음과 같다.

Phind

(1) == 검색1 == (2) == 사고1 == 이 비교 요청을 체계적으로 분석하겠습니다. 1. 첫째, React Virtuoso의 기술 세부 사항 및 가격 모델에 대한 중요한 정보가 누락 된 것을 알았습니다. 이를 위해 대상 웹 검색을해야합니다. 2. 비교는 시각 보조적으로 큰 혜택을 받을 것입니다. - 각 라이브러리 사용시기를 보여주는 의사 결정 흐름 차트 - 구현 차이를 보여주는 코드 예제 - Citation 0 : 1의 통계 테이블 3. 구조 계획 : - 가상화가 무엇인지 설명하는 간단한 소개 - 주요 차이 테이블 - 의사 결정 흐름도 - 상세한 비교 - 구현 예 - 권장 사항 React Virtuoso에 대한 누락 된 정보를 수집하는 것으로 시작하겠습니다. (3) == 검색2 == - react virtuoso license pricing commercial use cost - react virtuoso technical documentation features limitations (4) == 사고2 == 웹 검색 결과는 특히 React Virtuoso에 대한 귀중한 추가 정보를 제공했습니다. 1. 라이센스 세부 사항 및 가격 구조 2. 기술 구현 세부 사항 3. 성능 고려 사항 이제 포괄적 인 비교를 만들 수 있습니다. 수집 된 정보를 살펴보면 다음을 기반으로 이러한 라이브러리 간의 의사 결정 흐름을 보여주는 인어 다이어그램을 만들 수 있습니다. - 프로젝트 요구 사항 (가변/고정 크기) - 팀 규모 및 예산 제약 - 특정 사용 사례 (테이블, 그리드, 채팅) 이 다이어그램은 기본 비교를 소개 한 후에도 세부 구현으로 다이빙하기 전에 가장 유용합니다. 사용자는 코드를보기 전에 어떤 라이브러리가 자신의 요구에 가장 적합한 지 이해하는 데 도움이되므로. 나는 다음과 함께 답을 구조화 할 것이다. 1. 간단한 소개 2. 비교 테이블 3. 의사 결정 흐름도 4. 특수 코드 대안 구문을 사용한 자세한 구현 예제 5. 특정 권장 사항 정보는 이제 답을 진행하기에 충분히 완성 된 것 같습니다. (5) == 컨텐츠1 == - 설명과 비교테이블 - 의사결정 흐름 다이어그램 (6) == 사고3 == 다이어그램은 논리적으로 흐르며 명확한 결정 지점과 결과로 자명합니다. 각 경로는 주요 기능을 요약한 불렛 포인트를 사용하여 특정 권장 사항으로 이어집니다. 컬러 코딩 (질문용 핑크, 솔루션용 녹색)은 어떤 노드가 의사 결정 지점 대 최종 선택을 시각적으로 명확하게 합니다. Special Code Alternatives Syntax를 사용하여 구현 예제를 계속하여 두 라이브러리의 구체적인 사용법을 보여 드리겠습니다. 이를 통해 사용자는 구현의 실질적인 차이를 이해하는 데 도움이됩니다. (7) == 컨텐츠2 == - 구현예시 - 권장사항 - Remember

Perplexity (Deepseek R1)

(1) == 검색1 == React-virtuso와 @tanstack/react-virtual의 기능 비교 - react-virtuso features vs @tanstack/react-virtual features - react-virtuso vs @tanstack/react-virtual comparison - react-virtuso vs @tanstack/react-virtual capabilities (2) == 검색2 == React-virtuso 및 @tanstack/react-virtual에 대한 사용자 리뷰 또는 의견 찾기 - react-virtuoso user reviews - @tanstack/react-virtual user reviews - react-virtuoso vs @tanstack/react-virtual opinions (3) == 검색3 == React-virtuso 및 @tanstack/react-virtual의 성능 및 사용 사례 결정 - react-virtuoso performance - @tanstack/react-virtual performance - react-virtuoso use cases - @tanstack/react-virtual use cases (4) == R1 추론 == 1) 좋아요, 이제 React-virtuoso와 @tanstack/react-virtual 간의 비교를 다루겠습니다. 먼저, 검색 결과를 살펴보며 각 라이브러리에 대한 핵심 사항을 모아야 합니다. 2) React-virtuoso로 시작: 소스에서는 가변 크기 항목을 자동으로 처리하는 것으로 알려져 있으며 이는 큰 장점입니다. 문서는 좋은 예를 포함하여 포괄적인 것으로 평가됩니다. 무한 스크롤, 고정 헤더, 그리드 레이아웃과 같은 기능이 강조됩니다. 다른 제품에 비해 구성이 더 쉽다는 언급도 있습니다. 특히 채팅과 같은 역방향 스크롤 시나리오에서는 성능이 탄탄해 보입니다. 그러나 일부 사용자는 렌더링이 약간 지연되어 사용자 경험에 영향을 미칠 수 있다고 지적했습니다. 3) 이제 @tanstack/react-virtual(이전의 React-virtual)을 살펴보세요. TanStack 생태계의 일부이므로 반응 테이블과 같은 도구와의 통합이 강점입니다. 라이브러리에는 헤드리스가 있어 마크업과 스타일에 대한 더 많은 제어 기능을 제공하므로 사용자 정의에 적합합니다. 가볍고 여러 프레임워크를 지원하지만 더 많은 설정이 필요합니다. 사용자들은 이 방법이 효율적이지만 복잡한 구성 요소로 인해 성능 문제가 발생하여 스크롤 중에 지연이 발생할 수 있다고 보고합니다. 문서가 상세하지 않아 일부에게는 장애물이 될 수 있습니다. 4) 기능 비교: React-virtuoso는 기본적으로 기능이 더 풍부한 것처럼 보이지만 @tanstack/react-virtual은 유연성을 제공하지만 더 많은 수동 구성이 필요합니다. 커뮤니티 피드백은 사용 편의성과 고급 기능을 위해 반응 거장 쪽으로 기울지만, 다른 TanStack 도구와 통합하거나 헤드리스 접근 방식이 필요할 때는 @tanstack이 선호됩니다. 5) 각 라이브러리의 장단점을 간략하게 설명하고 기능, 성능, 사용 편의성, 사용 사례와 같은 주요 영역에서 비교하여 답을 구성해야 합니다. 관련 출처, 특히 비교표와 사용자 평가를 인용하세요. 다양한 크기의 복잡한 목록에는 React-virtuoso가 더 적합하고, @tanstack은 TanStack 생태계와의 사용자 정의 및 통합이 필요한 사용자에게 적합하다는 점을 강조하세요.

4. 기타

Phind는 자체 모델임에도 불구하고 생각보다 한글을 잘 출력해준다. 군데군데 한자가 있지만 말이다.

무엇보다 읽기가 매우 즐겁다!!

Thought 과정을 보면 Python 계산 실행등의 기능도 쓸 수 있어보인다.

관련 기능을 캐물어보니 내부 Doc을 찾아 다음과 같이 답변해준다.

3단계 사고모드는 전혀 예상 못했는데 재밌는 결과였다.

계산기도 써봤는데 실제 Python 코드를 돌려서 보여준다.

중간중간 사고과정이 꼭 사람같다.

Perplexity는 정말 강력한 검색기능을 가지고 있다.

다양한 검색범위를 제한할 수 있으며, 특히 학문과 수학은 전문 검색엔진을 트리거한다!!

학문모드: arXiv와 Semantic scholar를 사용한다.

수학모드: Wolfram Alpha를 사용한다.

비디오모드:

소셜모드:

5. 결론

이번에 새로 나온 Phind의 요약 기능은 내가 원하던 AI 검색엔진 형태와 가장 유사하다. 작년 11월부터 Phind 2.0이 나온다 나온다만 반복하고 계속 모델 학습중이라는 답변만 하길래 디자인 Refresh + PDF 첨부 기능만 먼저 릴리즈하자고 속으로 욕 좀 했었는데 보고서야 왜 2.0인지 깨달았다. 멋지다.

Perplexity는 20개 넘게 참고할정도로 많은 검색 쿼리양, Semantic Scholar/Wolfram Alpha와 같은 전문 검색엔진 사용 가능, 리즈닝 모델인 R1/o3-mini 제공를 고려하면 정말 돈을 아낌없이 써서 유저에게 정보를 제공해주는 착한 회사 같다. 이정도면 자선단체 아닐까? ㅋㅋㅋㅋ 이왕에 Kagi API로 검색까지 해주면 좋겠다 싶다.

체계적인 개발 프로세스를 원한다는 글을 보았다.

해당 글에서 체계적이란 잘 짜여진 완벽한 기획서와 디자인으로 개발자는 보고 코딩하는 프로세스를 뜻했는데, 그 이면과 맥락을 파고 들어가보자.

1. 체계적 프로세스

먼저 해당 글에서 실제로 원하는 체계적인 개발 프로세스에 대해 추정해봅시다. 아마 다음의 경우 중 하나에 속할 가능성이 높다.

[Business process modeling]

1) 의사결정 및 정책 기획/설계시 잘못되었다고 근거와 대안을 제시함에도 우겨서 진행하다 롤백하는 경우가 적거나 없어야 한다. 물론 변화는 당연히 발생할 수 있지만 정책에 따라 결정해야 한다. 예컨대 유연하다는 애자일에서도 스크럼의 스프린트 주기나 칸반의 WIP 제한등 일정한 이터레이션을 위한 정책이 존재한다.

때로는 데이터와 측정을 사용한 의사결정을 의미할 때가 있을 수도 있겠다.

2) CI/CD 사람 말고 기계가 해주어야 하는 일이다. CI/CD만 제대로 구축되어 있어도 쓸데없이 힘빼는 부분을 줄일 수 있다.

3) 테스트코드와 코드리뷰 이게 보통 이야기하는 체계적인 프로세스의 실체일 가능성이 높다.

테스트코드를 잘짜고 코드리뷰도 잘하는 회사가 그리 보편적인 경우가 아닌걸로 알고 있다.

4) 업무 분장 일하는 사람끼리의 역할과 책임, 인터페이스가 확실하고, 반복적인 업무의 경우 프로세스가 명시화되어 있어야 한다.

본인이 할 일에 집중하고, 다른사람의 도움이 필요할 경우 연락이 쉬워야 할 것이다. 일종의 SOLID 원칙이 아닐까.

5) 기능개발 및 일정 개발의 일정이 지속적 야근을 요하지 않게 합리적으로 잡히며, 기획/기능/설계상의 변경이 있을시 일정의 변경이 따라와야 한다.

또한 핫픽스나 영업등 급한 외부의 변화가 아닌한 인터럽트를 심하게 걸어, 현재 처리 중인 업무를 중단하고 투입되지 않도록 해야한다. 컨텍스트 변경이 심하면 지속적으로 개발하기 어렵고 느려진다.

업무 부하가 큰 상황에서 책임을 개인탓으로 전가하는 경우는..? 이제 공무원처럼 문제를 알아도 숨기게 되고 폭탄 돌리기가 시작된다.

2. 시스템

조직이든, 개인이든 지속되다보면 결국 일정한 문화나 관습, 관성등 자기조직화 현상이 생기게 된다. 매년 사람들이 바뀌어서 문화랄게 없다고? 매년 바뀐다는 것도 문화라 할 수 있다. 이는 곧 시스템으로도 취급할 수 있다.

[Systemic development]

1) 좋은 시스템 이왕 존재할 수 밖에 없다면, 더 좋은(?) 시스템이라면 좋겠다. 좋은 시스템을 유지하기 위해 크게 두가지로 나눌 수 있다.

하방을 방지

변화와 개선

2) 하방을 방지 체계적인 프로세스란 곧 하방을 방지하자는 뜻이고, 앞서 말했던 CI/CD 등이 대표적이다.

하지만 체계적인 프로세스란 경직성을 가지게 되고 관료제를 야기한다는 관점은 참으로 옳다. 그렇다면 어떻게 바라보고 다루어야 하는가?

의사결정이나 커뮤니케이션 과정을 줄여주거나 간소화하는 도구로서 사용해야 한다.

CI/CD에 있는 코드 포맷터, 빌드체크, 배포등은 일종의 룰로서 작용하고 부하를 줄여줘, 그 시간에 다른 일을 할 수 있는 시간을 확보하고 최소한의 품질을 만족시키는데 도움이 된다.

반대로 수없이 많은 결재를 타고 올라가야 한다던가, 몇백장짜리 문서를 만들어야 하는 사례처럼 무거워지고 그 자체로 일이 많아진다면 옳지 못한 프로세스라 할 수 있다. 물론 의료나 금융처럼 인명 사고 예방, 시스템 자체의 안정이 필요한 특수한 경우은 답답하더라도 예방차원에서 복잡한 프로세스를 요구하는 경우가 있을 수도 있다.

하지만 하방방지는, 어디까지나 안정을 위한 발판으로서 바라보아야 함이 원칙일 것이다.

3) 변화와 개선 하방 방지에만 치중하면 결국 안정을 빌미로 변화를 꾀하려 하지 않게 되므로 시대의 조류에 적응하지 못하고 앞으로 나아갈 수가 없을 것이다.

이제 변화와 개선을 다루어야 하는데, 변화와 개선이란 본질적으로 어렵다.

장기적 관점: 지속가능해야 하며, 시대의 메가트랜드는 따라가면서 망하지 않을 루트를 골라야 한다.

상호작용: 도입시 미치는 영향을 예측하고, 설득하고, 관리해야 한다.

다양한 관점: 경영, 기획, 개발, 영업, 운영 등의 큰그림과 이해관계도 고려해야 한다.

때문에 불필요한 관성의 타파가 어렵다. 어떻게 미래를 예측해야 하고, 리스크를 누가 책임질건데? 투자와 기본적인 정치 기술에 대한 이해까지 동반하게 된다. 찰리멍거가 언급하듯 투자는 어렵다.

그래서 사람들은 적극적 개선을 생각보다 원치 않는다. 하게 되더라도 일정 수준의 역량을 요구한다.

4) 변화와 개선의 어려움 대표적인 예로 들기 좋은 것은 토스의 『유난한 도전』 일 것이다.

‘유난한 도전’ 한 토스의 의사결정 방식

《유난한 도전》이 던지는 3가지 질문

변화와 개선에 요구되는 자율성, 협업, 피드백 대응은 모두 어려운 것들이다.

자율성에는 방만해지지 않기 위한 책임이 뒤따르며, 그렇다고 각각에게 책임을 씌우며 알아서 살아남아라 하면 개인주의가 성횡하고 협업이 어려워진다.

협업은 잘하려면 다양한 도메인에 최소한의 지식을 요구할 수 밖에 없으며, 서로 영향을 주는 일이기 때문에 자율성을 훼손하지 않기도 쉽지 않다. 마치 프로그래밍에서 객체지향을 하기 어려운 것처럼 말이다.

피드백 대응은 협업과 우선순위/일정 조정등이 동반된다.

서로간의 상당한 모순과 트레이드 오프를 다루어야 하기 때문에 균형잡기가 어려울 수밖에 없다.

러프하게 말하면

나는 스타트업의 프론트인데 비지니스 상황과 제품을 고려해 기획, 디자인, 백엔드에게 모두 피드백을 주고받고, "변화"에 따라 직접 하기도 해야한다고??

라는 상황이 있을 수도 있지요. 특히나 워터풀 방식의 프로세스나 확실한 업무분장은 유연한 자율, 협업, 피드백 대응의 측면에서 방해가 될 수 있을겁니다. 기획, 디자인을 모조리 프론트 개발자가 하는 것은 무리여도, 백엔드까지 하는 풀스택 개발자로 구성된 조직은 충분히 있을범직하고 괜찮아보이죠.

어라..? 이거 완전...좋소..

즉, 천국과 지옥이 종이 한장차이인 상황처럼 보인다. (겉으로 보면 말이다.) 이토록 구분이 어렵기에 첫번째 경력은 시스템이 엉망인 중소에서 단련..하고 나오는 것도 좋다는 의견들도 가끔 나온다고 추측한다.

5) 무엇이 다른가? 자, 그럼 종이 한장차이에 대해 생각해보자. 조반니 비코의 "역사란 나선형으로 발전한다"는 말처럼 비슷하지만 다르다.

목표 지향적: 명확한 목표와 방향성을 가지고 있으며, 당장의 문제해결에만 집중하는 과오를 범하지 않는다.

체계적 접근: 즉각적인 피드백이라고, 즉흥적이고 일관성이 부족함을 의미하지 않는다.

책임감: 결정과 행동, 책임을 떠넘기지 않는다. 단, 자율성을 지나치게 침해하는 마이크로매니징은 조심.

지속적 개선: 기존의 방식을 고수하기 보다는 개선점을 찾아 변화한다. 새로운 기술과 방법론들에 대한 꾸준한 학습과 비교도 방법 중 하나.

피드백 수용: 다른 사람의 의견을 경청하고, 비판을 수용한다. 쉽게 말하면 불필요한 자존심과 고집을 내려놓거나, 의견과 자신을 동치하는 일을 피하기다.

정보의 균형성과 대칭성: 의사결정에 필요한 정보에 공평하게 접근가능하고, 의사결정시 공유되어 격차를 줄여야 한다. 히스토리, 컨텍스트 공유와 의사결정의 투명성은 얼마나 보장되는가?

심리적인 안정이 부족한 조직, 주먹구구식으로 일하는 조직은 위와 같은 사항이 보장되지 않는 경우가 많다. 그리고 사람들은 미래가 보이지 않는점을 본능적으로 파악하여 "비체계적"인 조직이라 고민이라 하게 되는 것이다.

"체계적"이라 함은 이렇게 많은 맥락을 함의한다.

3. 다시 처음으로

이걸 말로 표현하기란, 행동하기란 대단히 어렵기 때문에 (저도 잘 못합니다ㅠㅠ)

[실천이성비판]

"체계적인 프로세스"라고 퉁치며 잘 짜인 완벽한 기획서와 디자인, 정해진 일정대로 진행을 원하게 되는 것이다. 시장조사의 맹점중 하나는 소비자도 자신이 뭘 원하는지, 왜 선택하는지 모른다는 것에 있지 않겠나.

설사 안다할지라도 조직적 차원의 의도적인 노력, 충분히 고민할 시간과 경험 등이 뒷받쳐줘야하므로 어려움은 변함없다. 그래서 그나마 도입이 쉬운 길을 찾고 여유를 얻기 위해서 위와 같은 결론을 낸게 아니었을까.

"변화와 개선"을 위해서 "하방을 방지"가 선행되어야 하는 면도 있다. 하방의 방지가 해주는 중요한 역할 중 하나는 정형화를 통해 인지부하를 줄여 더 복잡하고 변해야 하는 일에 집중하도록 도와주기이니까 말이다.

반면 기본적인 문서화, CI/CD, 테스트코드와 코드리뷰등 프로세스가 잡힌 곳에서 일하는 사람들은 이미 기본기는 채워진 상황인데 더 좋은 변화와 개선에 투자해야지, 대체 왜 체계적인 프로세스에 집착하는가에 대해 반문할 수도 있다.

행정 및 관료제는 팽창과 항구성 경향을 가지며, 보통 다음과 같은 문제를 가지기 때문이다.

과도한 문서화

목표와 수단의 역전으로 인해 프로세스 준수가 목표가 되버림

전문화된 분야에서는 고도의 능력을 발휘하지만 다른 영역에서는 문제해결 능력 붕괴

과도한 전문화로 인한 부서간 갈등/경쟁

유연성이 없는 사무적인 처리

명령이나 지시가 없으면 행동하지 않는 수동적 행태

따라서

주먹구구식 처리를 하는 곳에서는 프로세스 개선을 먼저하고,

프로세스가 갖추어진 곳에서는 변화와 진보에 집중

이 그나마 적합한 대답이 아닌가 싶다.

브라우저 빌드를 해보았다. 다음달부터 시작할 작업에 기대 중

이제는 앉아만 있어도 유저가 알아서 홍보를 해주는구나 ㅎㅎㅎ

What We're Working on in Firefox

Palm도 DB First OS였는데 여려모로 안타까운 회사..

리눅스 피그마에서 캔버스 화면이 잘 안나오면

리눅스 피그마에서 캔버스 화면이 잘 안나오면 rm -rf \\~/.config/figma-linux/GPUCache\ 를 실행해보십시오.