<?xml version="1.0" encoding="UTF-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
  <title>원빌더</title>
  <link rel="alternate" type="text/html" href="https://brunch.co.kr/@@3xdu" />
  <author>
    <name>novah</name>
  </author>
  <subtitle>UX를 화면 너머, 사람의 선택과 행동을 설계하는 시스템으로 정의합니다. 14년간 글로벌 하이테크 기업에서 비즈니스&amp;middot;기술&amp;middot;사람의 교차점을 설계해왔습니다.</subtitle>
  <id>https://brunch.co.kr/@@3xdu</id>
  <updated>2017-05-11T08:12:11Z</updated>
  <entry>
    <title>디자인 토큰 SSOT : Figma냐 코드냐  - 토큰 거버넌스는 도구가 아닌 합의다</title>
    <link rel="alternate" type="text/html" href="https://brunch.co.kr/@@3xdu/29" />
    <id>https://brunch.co.kr/@@3xdu/29</id>
    <updated>2026-04-17T05:09:48Z</updated>
    <published>2026-04-12T23:00:28Z</published>
    <summary type="html">팀이 도구를 잘 갖췄는데도 토큰이 어긋나는 이유는, 대부분 도구의 문제가 아니라 보이지 않는 합의의 빈틈 때문이다.  예를들어, {design-tokens.json}을 Git에서 관리하기로 합의한 팀이 있다. Tokens Studio가 Value 값을 Figma Variables에 동기화하고, GitHub Actions에서 변경을 감지한다. 파이프라인은 갖&lt;img src= "https://img1.kakaocdn.net/thumb/R1280x0/?fname=http%3A%2F%2Ft1.kakaocdn.net%2Fbrunch%2Fservice%2Fuser%2F3xdu%2Fimage%2F8E58FZu4JRnZU7luTp-1aySeu04.png" width="500" /&gt;</summary>
  </entry>
  <entry>
    <title>Figma와 코드, 진짜 병목은 동기화 - Claude Code&amp;middot;MCP&amp;middot;Git 기반 동기화 구조(2025&amp;rarr;2026)</title>
    <link rel="alternate" type="text/html" href="https://brunch.co.kr/@@3xdu/28" />
    <id>https://brunch.co.kr/@@3xdu/28</id>
    <updated>2026-04-02T03:56:00Z</updated>
    <published>2026-04-02T03:43:44Z</published>
    <summary type="html">UX-개발 협업에서 가장 반복되는 문제는, Figma 디자인과 실제 코드가 어긋나는 순간입니다. 특히 Figma Variables, Design Token, 코드 구조가 서로 따로 관리될 때 이 불일치는 더 심해집니다. 이 글에서는&amp;nbsp;왜 Figma와 코드가 지속적으로 불일치하는지 그 구조적 원인을 설명하고,&amp;nbsp;Claude Code-MCP-Git을 기반으로 동기&lt;img src= "https://img1.kakaocdn.net/thumb/R1280x0/?fname=http%3A%2F%2Ft1.kakaocdn.net%2Fbrunch%2Fservice%2Fuser%2F3xdu%2Fimage%2Fc7g_96023taEjxUjM8VDpNmWXAo.png" width="500" /&gt;</summary>
  </entry>
  <entry>
    <title>UX 디자이너는 왜 기능을 줄일까 JTBD기반 설계 - POC와 System Design으로 AI시대 Product 디자인 검증</title>
    <link rel="alternate" type="text/html" href="https://brunch.co.kr/@@3xdu/26" />
    <id>https://brunch.co.kr/@@3xdu/26</id>
    <updated>2026-03-07T01:18:39Z</updated>
    <published>2026-03-06T09:18:29Z</published>
    <summary type="html">많은 제품이 실패하는 이유는 기능이 부족해서가 아니다. 오히려 기능이 너무 많기 때문이다. 이 장에서는 JTBD, POC, System Design 관점에서&amp;nbsp;기능을 어떻게 줄일 것인지, 그리고&amp;nbsp;그 원리가&amp;nbsp;삶의 선택 설계에 어떻게 그대로 적용되는지 다룬다. 이 장을 다 읽고 나면, 당신은 &amp;quot;무엇을 더 만들지&amp;quot;가 아니라&amp;nbsp;&amp;quot;무엇을 지금 만들지 말지&amp;quot;를 기준으로 &lt;img src= "https://img1.kakaocdn.net/thumb/R1280x0/?fname=http%3A%2F%2Ft1.kakaocdn.net%2Fbrunch%2Fservice%2Fuser%2F3xdu%2Fimage%2F1IqmCEhun8_XMPOuMxpDb3sYM9g.png" width="500" /&gt;</summary>
  </entry>
  <entry>
    <title>선택지를 절반으로  줄여주는 JTBD 설계 - AI 시대, 기능이 아닌 '일'을 고용하라</title>
    <link rel="alternate" type="text/html" href="https://brunch.co.kr/@@3xdu/24" />
    <id>https://brunch.co.kr/@@3xdu/24</id>
    <updated>2026-03-04T03:01:48Z</updated>
    <published>2026-03-03T15:01:04Z</published>
    <summary type="html">B2B 시스템 중에서도 복잡도가 상위에 속하는 영역이 있다. 제조 현장이 대표적이다. 반도체 제조만 해도 수백 개의 공정 단계가 존재하고, 각 단계마다 설비, 품질, 물류, 수율 데이터를 다루는 시스템이 따로 있다. 이 시스템들은 파편화되어 있었기 때문에, 통합 플랫폼을 만들어야 한다는 요구가 자연스럽게 생겼다. 제조 실행 시스템(MES) &amp;sup1;⁾, AI 기반&lt;img src= "https://img1.kakaocdn.net/thumb/R1280x0/?fname=http%3A%2F%2Ft1.kakaocdn.net%2Fbrunch%2Fservice%2Fuser%2F3xdu%2Fimage%2FOTo9OIq2QhEC-y1ADa2NjJl4mqQ.png" width="500" /&gt;</summary>
  </entry>
  <entry>
    <title>프로세스가 당신의 안도감을 결정한다 - 보이지 않는 흐름을 가시화하는 법</title>
    <link rel="alternate" type="text/html" href="https://brunch.co.kr/@@3xdu/23" />
    <id>https://brunch.co.kr/@@3xdu/23</id>
    <updated>2026-03-06T09:37:08Z</updated>
    <published>2026-02-23T13:55:52Z</published>
    <summary type="html">회의가 끝났다. 결정은 내려졌고, 기능도 정의되었고, 일정도 공유되었다. 그런데 이상하게 불안했다. 이유는 단순했다. 다음 단계가 예측되지 않았기 때문이다.  &amp;quot;이번에는 얼마나 걸릴까요?&amp;quot;  대기업에서 내부 투자를 받아 시스템을 개발하는 프로젝트를 다룰 때, 가장 많이 들었던 질문이다. 규모가 큰 조직일수록 사업 기획부터 심의, 계약, 개발, 검증까지 촘촘&lt;img src= "https://img1.kakaocdn.net/thumb/R1280x0/?fname=http%3A%2F%2Ft1.kakaocdn.net%2Fbrunch%2Fservice%2Fuser%2F3xdu%2Fimage%2FCa2csdjd03e7kgyTMqJD1dP-0GU.png" width="500" /&gt;</summary>
  </entry>
  <entry>
    <title>UX는 언제부터 화면만의 일이 되었을까 - 표면(UI)이 아닌 구조(IA)에 집중하라</title>
    <link rel="alternate" type="text/html" href="https://brunch.co.kr/@@3xdu/22" />
    <id>https://brunch.co.kr/@@3xdu/22</id>
    <updated>2026-02-20T08:31:01Z</updated>
    <published>2026-02-19T13:00:10Z</published>
    <summary type="html">&amp;quot;이 버튼 색, 좀 더 트렌디하게 바꿔주세요.&amp;quot; &amp;quot;색을 좀 더 눈에 띄게 바꿔주세요.&amp;quot;  디자인 리뷰에서 가장 자주 듣는 말 중 하나다. 버튼의 색상, 폰트의 무게, 카드 레이아웃의 라운딩 값. 논의는 대부분 '보이는 것'을 중심으로 흘러간다. 눈에 보이니까 쉽게 의견이 나오고, 의견이 나오니까 수정이 반복된다. 결과적으로 팀 전체의 에너지가 원래 의도와는&lt;img src= "https://img1.kakaocdn.net/thumb/R1280x0/?fname=http%3A%2F%2Ft1.kakaocdn.net%2Fbrunch%2Fservice%2Fuser%2F3xdu%2Fimage%2FklkIEiMZJXNEGWh1m-LoqszZtJQ.png" width="500" /&gt;</summary>
  </entry>
  <entry>
    <title>기준은 다짐도 취향도 아닌, 시스템이다 - 감정을 이기는 구조 설계의 힘</title>
    <link rel="alternate" type="text/html" href="https://brunch.co.kr/@@3xdu/21" />
    <id>https://brunch.co.kr/@@3xdu/21</id>
    <updated>2026-02-16T13:45:53Z</updated>
    <published>2026-02-16T13:45:53Z</published>
    <summary type="html">앞에서 우리는 '나답게 살자'는 다짐만으로는 충분하지 않다는 결론에 도달했다. 그렇다면 다짐 대신 기준을 세우면 되지 않을까.  많은 이들이 실제로 그렇게 시도한다. 그리고 그 기준이라는 것은 대부분 이런 형태를 띤다. &amp;quot;나는 워라밸을 중시해.&amp;quot;, &amp;quot;나는 성장할 수 있는 환경이 중요해.&amp;quot; 이 문장들은 기준처럼 보이지만, 실제 판단의 순간에는 거의 작동하지 &lt;img src= "https://img1.kakaocdn.net/thumb/R1280x0/?fname=http%3A%2F%2Ft1.kakaocdn.net%2Fbrunch%2Fservice%2Fuser%2F3xdu%2Fimage%2FlCLMJj9NBP0vS3fEQuBfvwwVAqU.png" width="500" /&gt;</summary>
  </entry>
  <entry>
    <title>지도가 정교할수록 나침반은 무력해진다 - 정보 과잉 시대의 의사결정 외주화</title>
    <link rel="alternate" type="text/html" href="https://brunch.co.kr/@@3xdu/20" />
    <id>https://brunch.co.kr/@@3xdu/20</id>
    <updated>2026-02-12T10:59:19Z</updated>
    <published>2026-02-12T10:59:19Z</published>
    <summary type="html">정교한 지도가 하나였다면 따르면 그만이다. 문제는 그런 지도가 열 개라는 것이다. 각각이 객관적 데이터를 근거로 서로 다른 최적 경로를 주장하는 상황에서, 우리에게 부족한 것은 더 나은 지도가 아니라 어떤 지도를 펼칠지 결정하는 기준이다. ​ 회의실을 나서는 순간 자주 남는 말이 있다. ​ &amp;quot;조금 더 자료를 보고 결정하죠.&amp;quot; ​ 이 말은 종종 신중함의 상징&lt;img src= "https://img1.kakaocdn.net/thumb/R1280x0/?fname=http%3A%2F%2Ft1.kakaocdn.net%2Fbrunch%2Fservice%2Fuser%2F3xdu%2Fimage%2FjLsDUBSYdmj55ReOPKqVnaQMJbk.png" width="500" /&gt;</summary>
  </entry>
  <entry>
    <title>번아웃이 아니라 설계의 부재다 - 잘 살고 있는데도 계속 흔들리는 이유</title>
    <link rel="alternate" type="text/html" href="https://brunch.co.kr/@@3xdu/19" />
    <id>https://brunch.co.kr/@@3xdu/19</id>
    <updated>2026-02-20T08:29:51Z</updated>
    <published>2026-02-08T23:00:43Z</published>
    <summary type="html">오전 9시, 책상에 앉아 메신저를 켠다. 수십 개의 알림 사이로 당장 결정해야 할 사안들이 섞여 있다. 급한 것부터 빠르게 답변을 작성하면서도, 머릿속에는 전혀 다른 질문이 맴돈다.  '안정적인 성과를 내고 있지만, 현재 작업에만 매몰되어 도태되는 것은 아닐까.' '지금이라도 관리자 트랙으로 전환해야 하는 건 아닐까.'  점심 메뉴를 고르는 사소한 일부터 &lt;img src= "https://img1.kakaocdn.net/thumb/R1280x0/?fname=http%3A%2F%2Ft1.kakaocdn.net%2Fbrunch%2Fservice%2Fuser%2F3xdu%2Fimage%2FOYHZ41ra2NBpWptVP2qXC2iyD_k.png" width="500" /&gt;</summary>
  </entry>
</feed>
