<?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/@@eaQ7" />
  <author>
    <name>taekil</name>
  </author>
  <subtitle>문학을 공부하고 디자인으로 먹고 살고 있습니다. 직무와 도메인을 넘나드는 메타 참견을 좋아합니다.</subtitle>
  <id>https://brunch.co.kr/@@eaQ7</id>
  <updated>2022-05-22T03:19:39Z</updated>
  <entry>
    <title>디자인 팀이 1명일 때 벌어지는 일들 (1) - 혼자 시작한 신입 디자이너가 가장 먼저 겪는 일들</title>
    <link rel="alternate" type="text/html" href="https://brunch.co.kr/@@eaQ7/59" />
    <id>https://brunch.co.kr/@@eaQ7/59</id>
    <updated>2026-02-24T13:02:28Z</updated>
    <published>2026-02-24T11:37:26Z</published>
    <summary type="html">최근 오픈채팅방에서 반복해서 보게 되는 질문들이 있다. &amp;ldquo;디자인 팀이 저 혼자인데 어떻게 해야 할까요.&amp;rdquo; &amp;ldquo;대표님이 디자인에 계속 개입합니다.&amp;rdquo; &amp;ldquo;신입인데 어디까지가 제 역할인지 모르겠습니다.&amp;rdquo; 질문의 형태는 조금씩 다르지만, 맥락은 거의 비슷하다. 팀이 아니라 혼자인 상태에서, 기준 없이 판단을 내려야 하는 상황에 놓여 있다는 점이다.이 시리즈는 그 질문&lt;img src= "https://img1.kakaocdn.net/thumb/R1280x0/?fname=http%3A%2F%2Ft1.kakaocdn.net%2Fbrunch%2Fservice%2Fuser%2FeaQ7%2Fimage%2FXxghZkaycOIWUwnQnfk81K7Vvm4.png" width="500" /&gt;</summary>
  </entry>
  <entry>
    <title>기획이 애매할 때 디자이너가 먼저 해야 할 것 - 애매하다고 디자이너가 다 하는 건 어리석인 짓이다</title>
    <link rel="alternate" type="text/html" href="https://brunch.co.kr/@@eaQ7/58" />
    <id>https://brunch.co.kr/@@eaQ7/58</id>
    <updated>2026-02-23T07:42:11Z</updated>
    <published>2026-02-23T03:56:21Z</published>
    <summary type="html">실무에서 가장 흔하면서도 피로를 크게 만드는 상황은 기획서가 '틀리진 않았는데 바로 디자인하기엔 애매한 상태'일 때다. 요구사항은 정리되어 있고, 기능 목록도 있고, 대략적인 사용자 흐름도 적혀 있다. 얼핏 보면 시작해도 될 것 같다. 그런데 막상 화면으로 옮기려 하면 어딘가 계속 비어 있는 느낌이 든다. 단계가 하나 빠진 것 같고, 예외 상황이 빠진 것 &lt;img src= "https://img1.kakaocdn.net/thumb/R1280x0/?fname=http%3A%2F%2Ft1.kakaocdn.net%2Fbrunch%2Fservice%2Fuser%2FeaQ7%2Fimage%2FWhPwLtzwTh-4EdTp3s1TvOChjcg.png" width="500" /&gt;</summary>
  </entry>
  <entry>
    <title>&amp;ldquo;다들 어떻게 하세요?&amp;rdquo;라는 말부터 멈춰야 한다 - 평균을 따르는 습관이 디자이너를 약하게 만드는 이유</title>
    <link rel="alternate" type="text/html" href="https://brunch.co.kr/@@eaQ7/57" />
    <id>https://brunch.co.kr/@@eaQ7/57</id>
    <updated>2026-01-18T07:54:35Z</updated>
    <published>2026-01-18T07:54:35Z</published>
    <summary type="html">&amp;ldquo;이런 경우 보통 어떻게 하시나요?&amp;rdquo;라는 질문은 누군가와 의견이 부딪힌 순간에만 나오는 말은 아니다. 오히려 디자이너가 혼자 결정을 내려야 하는 상황을 마주했을 때 더 자주 등장한다. 피그마 파일을 어떻게 백업하는지, 라이브러리를 어디까지 나누는지, 컴포넌트 네이밍 규칙을 어느 정도로 가져가는지 같은 질문들이 그렇다. 기술적으로 복잡하지도 않고, 팀마다 답</summary>
  </entry>
  <entry>
    <title>디자이너가 코딩을 배워야 하나요 v. 2026 - 배워야 할 건 기술이 아니라 경계다</title>
    <link rel="alternate" type="text/html" href="https://brunch.co.kr/@@eaQ7/56" />
    <id>https://brunch.co.kr/@@eaQ7/56</id>
    <updated>2026-01-13T06:34:24Z</updated>
    <published>2026-01-13T06:34:24Z</published>
    <summary type="html">이전에 디자이너가 ㅇㅇ도 해야 하는지에 대한 글을 쓴 적이 있다. 그 글에 관점을 새로 더해 2026년 버전으로 개편한 내용을 적어본다.    디자이너들이 모여 있는 오픈채팅방을 보고 있으면, 가끔 질문들이 묘하게 겹쳐 보일 때가 있다.  &amp;ldquo;디자이너도 코딩을 배워야 할까요?&amp;rdquo;라는 질문이 올라오고, 그 아래에는 &amp;ldquo;기획이나 마케팅까지 알아야 하나요?&amp;rdquo;라는 말이</summary>
  </entry>
  <entry>
    <title>버튼 안의 아이콘은 죄가 없어 - 벡터 정리나 Flatten이 중요한 게 아니다</title>
    <link rel="alternate" type="text/html" href="https://brunch.co.kr/@@eaQ7/55" />
    <id>https://brunch.co.kr/@@eaQ7/55</id>
    <updated>2026-01-12T16:20:32Z</updated>
    <published>2026-01-12T16:20:32Z</published>
    <summary type="html">피그마에서 버튼 컴포넌트를 만들다 보면 한 번쯤은 이런 순간을 만나게 된다. 아이콘 컴포넌트를 따로 만들고, 그 아이콘을 버튼 안에 넣고, 버튼 색상에 맞춰 아이콘 색도 같이 바뀌도록 설정해 두었는데, 어느 날 갑자기 버튼 인스턴스에서 아이콘을 바꾸자 색상이 전혀 따라오지 않는 상황이다. 어제까지만 해도 잘 되던 게 오늘은 안 되고, 설정을 다시 열어봐도</summary>
  </entry>
  <entry>
    <title>주니어 디자이너의 취업 고민이 자주 어긋나는 이유 - 비전공&amp;middot;늦은 시작&amp;middot;부족함 앞에서 흔들리지 않는 법</title>
    <link rel="alternate" type="text/html" href="https://brunch.co.kr/@@eaQ7/54" />
    <id>https://brunch.co.kr/@@eaQ7/54</id>
    <updated>2026-01-09T07:15:17Z</updated>
    <published>2026-01-09T07:15:17Z</published>
    <summary type="html">&amp;ldquo;비전공자인데 디자인 시작한 지 얼마 안 됐어요. 이런 상황에서도 취업이 가능할까요?&amp;rdquo; &amp;ldquo;29살에 디자이너로 취업하려고 하는데 너무 늦은 건 아닌지 걱정돼요.&amp;rdquo; &amp;ldquo;포트폴리오는 만들고 있는데 부족한 것 같고, 이력서를 넣어도 연락이 한 군데도 안 와요.&amp;rdquo;  이 질문들은 서로 다른 것처럼 보이지만, 사실상 같은 지점에서 나온다.&amp;nbsp;지금의 내가 채용 시장에서 유효</summary>
  </entry>
  <entry>
    <title>연봉이 아니라 커리어를 판단해야 할 시점 - N년차 평균 연봉과 인상률에 자꾸 목매지 말지어다</title>
    <link rel="alternate" type="text/html" href="https://brunch.co.kr/@@eaQ7/53" />
    <id>https://brunch.co.kr/@@eaQ7/53</id>
    <updated>2026-01-10T08:11:04Z</updated>
    <published>2026-01-09T02:20:11Z</published>
    <summary type="html">커뮤니티를 조금만 둘러보면 비슷한 결의 질문들이 계속해서 올라온다. &amp;ldquo;3년차 UXUI 디자이너인데 연봉 3천 중반이면 어떤 편인가요?&amp;rdquo; &amp;ldquo;이 정도 경력에 이 연봉이면 이직을 고민해야 할까요?&amp;rdquo; &amp;ldquo;연봉 협상에서 5% 인상됐는데, 보통 이 정도가 평균인가요?&amp;rdquo; &amp;ldquo;주변 디자이너들은 다 4천은 넘긴 것 같은데 저만 뒤처진 느낌이에요.&amp;rdquo;  표현은 조금씩 다르지만,</summary>
  </entry>
  <entry>
    <title>AI 이후 UXUI 디자이너에게 사라진 일들 - 더 이상 붙잡지 않아도 되는 역할에 대하여</title>
    <link rel="alternate" type="text/html" href="https://brunch.co.kr/@@eaQ7/52" />
    <id>https://brunch.co.kr/@@eaQ7/52</id>
    <updated>2025-12-22T06:36:04Z</updated>
    <published>2025-12-22T06:36:04Z</published>
    <summary type="html">어느 순간부터 디자이너의 하루는 이상하게 바빠졌다. 화면은 더 빨리 만들어지는데, 결정은 더 늦어졌고, 도구는 점점 똑똑해지는데 회의는 줄지 않았다. 예전보다 덜 그리는데 더 지치는 상태, 아마 많은 UXUI 디자이너들이 이미 익숙하게 느끼고 있을 장면이다. 그래서 AI 이후를 이야기할 때는 남는 역할만큼이나 함께 정리해야 할 것이 있다. 이미 사라졌거나,</summary>
  </entry>
  <entry>
    <title>AI 시대, UXUI 디자이너의 역할 - 도구가 바뀐 뒤에도 사라지지 않는 역할</title>
    <link rel="alternate" type="text/html" href="https://brunch.co.kr/@@eaQ7/51" />
    <id>https://brunch.co.kr/@@eaQ7/51</id>
    <updated>2025-12-18T12:17:56Z</updated>
    <published>2025-12-18T11:43:54Z</published>
    <summary type="html">AI가 디자인을 한다는 말을 처음 들었을 때, 많은 디자이너들이 느꼈던 감정은 대체로 비슷했을 것이다. 또 하나의 툴이 나왔다는 가벼운 기대보다는, 뭔가 오래 붙들고 있던 의자의 다리가 하나 빠지는 듯한 불안에 가까웠다. 화면을 잘 만드는 사람이 필요 없어지는 건 아닐까, 우리가 쌓아온 숙련이라는 게 한순간에 무력해지는 건 아닐까 같은 생각들이 자연스럽게</summary>
  </entry>
  <entry>
    <title>만능 컴포넌트는 오래 버티지 못한다 - 만능이 되려는 순간 시스템은 무거워진다</title>
    <link rel="alternate" type="text/html" href="https://brunch.co.kr/@@eaQ7/50" />
    <id>https://brunch.co.kr/@@eaQ7/50</id>
    <updated>2025-12-18T09:24:43Z</updated>
    <published>2025-12-18T09:22:24Z</published>
    <summary type="html">피그마에서 컴포넌트를 만들 때 가장 흔하게 생기는 착각은 하나의 컴포넌트가 최대한 많은 상황을 대응해야 한다는 생각이다. 버튼이면 버튼으로서 등장할 수 있는 모든 상태를 담아야 할 것 같고, 카드면 카드로서 나올 수 있는 모든 변형을 하나로 묶어두는 게 더 체계적인 관리처럼 느껴진다. 그래서 처음에는 단순했던 컴포넌트가 점점 살이 붙고, Variant는 하</summary>
  </entry>
  <entry>
    <title>기술적 제약이 오히려 필요할 때 - 불편함을 이유로 구조가 정교해지는 과정</title>
    <link rel="alternate" type="text/html" href="https://brunch.co.kr/@@eaQ7/49" />
    <id>https://brunch.co.kr/@@eaQ7/49</id>
    <updated>2025-12-11T14:15:46Z</updated>
    <published>2025-12-11T14:15:46Z</published>
    <summary type="html">디자인을 하다 보면 기술적 제약이라는 것이 단순히 제한의 언어가 아니라는 걸 점점 더 실감하게 된다. 처음에는 당연히 불편함으로 다가온다. 여기서 이걸 할 수 없다고 하고, 저 기능은 이번 스프린트에 넣기 어렵다고 하고, 특정 인터랙션은 성능 때문에 구현이 어렵다고 말하면, 디자인은 계획해둔 흐름을 계속 수정해야 하고, 문장의 톤이나 버튼의 위치까지 다시</summary>
  </entry>
  <entry>
    <title>좋은 UX는 설명하지 않는다 - 말로 풀어야 하는 순간부터 이미 무언가 어긋나기 시작한다</title>
    <link rel="alternate" type="text/html" href="https://brunch.co.kr/@@eaQ7/48" />
    <id>https://brunch.co.kr/@@eaQ7/48</id>
    <updated>2025-12-12T05:52:37Z</updated>
    <published>2025-12-11T14:11:30Z</published>
    <summary type="html">서비스를 만들다 보면 어느 순간부터 화면에 붙는 설명이 점점 늘어나는 때가 있다. 처음에는 간단한 안내 문구 하나만 달아두면 충분할 것 같았지만, 기능이 늘어나고 흐름이 복잡해질수록 설명이 필요한 위치가 자연스럽게 많아지고, 어느 순간에는 거의 모든 주요 행동 옆에 작은 보조 문장이 따라붙어 있다. 이런 화면을 오래 바라보고 있으면 묘한 감정이 든다. 설명</summary>
  </entry>
  <entry>
    <title>사용자는 항상 개발보다 앞서 움직인다 - 예상 밖의 행동이 제품을 다시 설계하게 만드는 순간</title>
    <link rel="alternate" type="text/html" href="https://brunch.co.kr/@@eaQ7/47" />
    <id>https://brunch.co.kr/@@eaQ7/47</id>
    <updated>2025-12-10T01:00:26Z</updated>
    <published>2025-12-10T01:00:26Z</published>
    <summary type="html">서비스를 만들다 보면 어느 순간부터 사용자가 우리가 의도한 흐름보다 훨씬 빠르게 움직이고 있다는 사실을 실감하게 된다. 기획 단계에서 그려놓은 이상적인 사용자 여정은 늘 흐름이 깔끔하게 이어지고, 필요한 정보는 적절한 위치에 나타나며, 사용자는 우리가 준비해둔 방향대로 하나씩 진행할 것 같지만, 실제 상황은 거의 늘 다른 방식으로 진행된다. 사용자는 우리가</summary>
  </entry>
  <entry>
    <title>템플릿 시대의 디자이너는 무엇을 만드는가 - 여전히 남아 있는 사람의 역할</title>
    <link rel="alternate" type="text/html" href="https://brunch.co.kr/@@eaQ7/46" />
    <id>https://brunch.co.kr/@@eaQ7/46</id>
    <updated>2025-12-09T09:00:18Z</updated>
    <published>2025-12-09T09:00:18Z</published>
    <summary type="html">요즘은 디자인을 시작하는 사람도 전문적인 배경을 가진 사람도 모두 비슷한 고민을 하고 있을 것이다. 도대체 어디까지가 내가 만든 것이고 어디부터가 도구가 만들어낸 것인지, 그리고 템플릿과 자동화가 점점 늘어나는 환경에서 디자이너는 무엇을 기준으로 자신이 무언가를 &amp;lsquo;창작했다&amp;rsquo;고 말할 수 있는지 같은 문제들이다. 예전 같았으면 화면의 구성을 직접 그리고, 구조</summary>
  </entry>
  <entry>
    <title>모든 것은 결국 조율에서 시작된다 - 디자인이 생각보다 더 많이 다루는 것들</title>
    <link rel="alternate" type="text/html" href="https://brunch.co.kr/@@eaQ7/45" />
    <id>https://brunch.co.kr/@@eaQ7/45</id>
    <updated>2025-12-09T07:27:44Z</updated>
    <published>2025-12-09T07:27:44Z</published>
    <summary type="html">디자인 일을 오래 하다 보면 어느 순간부터 화면을 만드는 일이 전체 업무의 극히 일부라는 사실이 분명하게 느껴지는 시점이 온다. 처음에는 어떤 기능을 어떻게 보여줄지, 어떤 구조가 더 이해하기 쉬울지, 어떤 문장이 가장 자연스러울지 같은 문제들이 일의 중심이라고 생각하지만, 막상 실무에 들어가면 이런 문제들은 전체 과정 중에서 비교적 다루기 쉬운 축에 속하</summary>
  </entry>
  <entry>
    <title>디자인이 갑자기 어려워지는 순간들 - 익숙함이 깨질 때 필요한 마음의 여유</title>
    <link rel="alternate" type="text/html" href="https://brunch.co.kr/@@eaQ7/44" />
    <id>https://brunch.co.kr/@@eaQ7/44</id>
    <updated>2025-12-08T06:31:04Z</updated>
    <published>2025-12-08T06:31:04Z</published>
    <summary type="html">일을 하다 보면 어느 순간 갑자기 어제까지 아무렇지 않게 하던 일이 유독 낯설게 느껴질 때가 있다. 며칠 전까지만 해도 자연스럽게 흐르던 화면이 오늘은 어딘가 어색해 보이고, 손가락 끝에서 매끄럽게 이어지던 인터랙션이 갑자기 잘 이어지지 않는 것처럼 느껴지는 순간들이다. 디자인이라는 일이 원래 일정한 리듬을 타야 편안해지는 작업이라 그런지, 이 리듬이 조금</summary>
  </entry>
  <entry>
    <title>의심이 일의 속도를 지켜주는 순간 - 확신보다 점검이 먼저일 때</title>
    <link rel="alternate" type="text/html" href="https://brunch.co.kr/@@eaQ7/43" />
    <id>https://brunch.co.kr/@@eaQ7/43</id>
    <updated>2025-12-05T09:34:19Z</updated>
    <published>2025-12-05T09:34:19Z</published>
    <summary type="html">일을 오래 하다 보면 의심이라는 말이 처음과는 다른 결로 다가오는 순간이 있다. 처음에는 의심이 자신감 부족처럼 느껴지고, 스스로를 불신하는 태도로 보이기도 한다. 하지만 실무를 오래 겪다 보면 의심은 불안이 아니라 리듬을 지키는 기술이고, 확신을 견제하는 장치이며, 문제를 사전에 줄이는 가장 현실적인 방법이라는 사실을 자연스럽게 깨닫게 된다. 의심이 없는</summary>
  </entry>
  <entry>
    <title>답이 없어도 일은 움직여야 한다 - 정답을 서둘러 붙잡지 않는 사람들의 일하는 방식</title>
    <link rel="alternate" type="text/html" href="https://brunch.co.kr/@@eaQ7/42" />
    <id>https://brunch.co.kr/@@eaQ7/42</id>
    <updated>2025-12-05T09:30:50Z</updated>
    <published>2025-12-05T09:30:50Z</published>
    <summary type="html">문제를 해결하는 일이라고 하면 우리는 흔히 일정한 단계를 차례로 밟아가면 도착할 수 있는 일종의 목적지처럼 상상하곤 한다. 문제를 정의하고, 원인을 분석하고, 해결책을 찾고, 실행하고, 검증하는 식의 익숙한 절차가 머릿속에 자리 잡고 있기 때문이다. 하지만 실제 실무에서 문제는 그렇게 단순하게 모습을 드러내지 않는다. 문제의 형태는 늘 어딘가 불명확하고,</summary>
  </entry>
  <entry>
    <title>완벽하지 않아도 계속 움직일 수 있는 이유 - 일의 흐름을 지키는 마음에 대하여</title>
    <link rel="alternate" type="text/html" href="https://brunch.co.kr/@@eaQ7/41" />
    <id>https://brunch.co.kr/@@eaQ7/41</id>
    <updated>2025-12-05T01:58:55Z</updated>
    <published>2025-12-05T01:58:55Z</published>
    <summary type="html">디자인 일을 시작한 초반에는 완벽이라는 단어가 무척 선명하게 보인다.  화면을 조금만 더 깔끔하게 만들면 좋을 것 같고, 문장을 조금만 더 매끄럽게 다듬으면 더 정교해질 것 같고, 컴포넌트 구조를 한 번 더 정리하면 훨씬 설득력 있는 결과물이 나올 것 같은 기대가 자연스럽게 생긴다. 완벽은 손을 조금만 더 뻗으면 닿을 것처럼 보이는 목표이고, 그 목표를 향</summary>
  </entry>
  <entry>
    <title>정답보다 확률을 선택하는 마음 - 불확실함 속에서 일하는 사람의 사고 방식</title>
    <link rel="alternate" type="text/html" href="https://brunch.co.kr/@@eaQ7/40" />
    <id>https://brunch.co.kr/@@eaQ7/40</id>
    <updated>2025-12-01T13:17:58Z</updated>
    <published>2025-12-01T13:17:58Z</published>
    <summary type="html">디지털 제품을 만드는 일을 여러 해 동안 하다 보면 어느 순간부터 스스로 이런 질문을 멈추게 되는 시점이 찾아온다. 지금 이 선택이 과연 정답이 맞는가, 혹은 이 화면이 정말로 최선인가 같은 의문들인데, 이 질문들을 멈춘다는 건 답을 찾았다는 뜻이 아니라, 그런 질문이 더 이상 올바른 방향의 질문이 아니라는 사실을 깨닫는다는 의미에 가깝다. 디지털 환경에서</summary>
  </entry>
</feed>
