<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>디자인 허브 읽을거리</title>
    <link>https://designrefs.com/articles/</link>
    <atom:link href="https://designrefs.com/rss.xml" rel="self" type="application/rss+xml" />
    <description>디자인하면서 생각한 것들을 적습니다. AI와 같이 일하는 법, 스타일을 말로 옮기는 법, 레퍼런스와 커뮤니티 이야기.</description>
    <language>ko</language>
    <lastBuildDate>Sat, 26 Sep 2026 09:00:00 +0900</lastBuildDate>
    <item>
      <title>Claude Fable 5.1 vs GPT-6 아스트라, 숫자로 비교해 보면</title>
      <link>https://designrefs.com/articles/claude-fable-5-1-vs-gpt-6-astra/</link>
      <guid isPermaLink="true">https://designrefs.com/articles/claude-fable-5-1-vs-gpt-6-astra/</guid>
      <pubDate>Sat, 26 Sep 2026 09:00:00 +0900</pubDate>
      <category>AI 디자인</category>
      <description>이틀 차이로 나온 두 최상위 모델. 공식 사양, 제3자 평가, 디자이너들의 초기 반응을 출처와 함께 나란히 놓았다.</description>
      <content:encoded><![CDATA[    <p class="ptext">9월 첫 주, 최상위 AI 모델 두 개가 이틀 간격으로 나왔다. 앤트로픽의 Claude Fable 5.1이 9월 1~2일, 오픈AI의 GPT-6 아스트라가 9월 3일이다. 둘 다 자기가 가장 똑똑하다고 발표했고, 공교롭게 가격표까지 같다.</p>
    <p class="ptext">어느 쪽이 낫냐고 물으면 한 줄로 답하기가 어렵다. 공식 사양, 독립 기관의 평가, 먼저 써 본 사람들의 반응을 차례로 놓고 보면 왜 그런지 보인다.</p>
    <p class="ptext"><strong>먼저 밝혀 둘 것.</strong> 벤치마크 가운데 상당수는 모델을 만든 회사가 직접 잰 수치다. 누가 잰 숫자인지 표마다 적었다. 참고로 나는 이 사이트를 클로드 코드로 만들고 있어서, 그만큼 출처가 있는 숫자만 옮겼다. 모든 수치는 2026년 9월 중순 기준이고 빠르게 바뀐다.</p>
    <h2 class="psub">사양: 가격은 같고, 캐시가 다르다</h2>
    <div class="art__tablewrap"><table class="art__table">
      <thead><tr><th></th><th>Claude Fable 5.1</th><th>GPT-6 아스트라</th></tr></thead>
      <tbody>
        <tr><td>공개</td><td>2026년 9월 1~2일</td><td>2026년 9월 3일</td></tr>
        <tr><td>입력 가격 (100만 토큰)</td><td>$10</td><td>$10</td></tr>
        <tr><td>출력 가격 (100만 토큰)</td><td>$50</td><td>$50</td></tr>
        <tr><td>캐시 읽기 (100만 토큰)</td><td><strong>$0.25</strong></td><td>$1</td></tr>
        <tr><td>한 번에 읽는 분량</td><td>100만 토큰</td><td><strong>105만 토큰</strong></td></tr>
        <tr><td>한 번에 쓰는 분량</td><td>12.8만 토큰</td><td>12.8만 토큰</td></tr>
        <tr><td>지식 기준 시점</td><td><strong>2026년 6월</strong></td><td>2026년 4월</td></tr>
      </tbody>
    </table></div>
    <p class="art__note">출처: <a href="https://platform.claude.com/docs/en/about-claude/models/overview" target="_blank" rel="noopener">앤트로픽 모델 문서</a>, <a href="https://developers.openai.com/api/docs/models/gpt-6-astra" target="_blank" rel="noopener">오픈AI 모델 문서</a>. 굵은 글씨가 유리한 쪽.</p>
    <p class="ptext">표만 보면 거의 쌍둥이다. 차이는 두 군데다.</p>
    <p class="ptext">같은 긴 자료를 되풀이해 읽히는 작업이라면 이야기가 달라진다. 한 번 읽은 내용을 다시 불러올 때 내는 캐시 요금이 Fable 5.1은 아스트라의 4분의 1이다. 브랜드 가이드 PDF를 붙여 두고 몇십 번씩 질문하는 식의 작업이 여기에 해당한다. 그리고 Fable 5.1이 두 달 더 최근까지 알고 있다.</p>
    <p class="ptext">속도는 공식적으로 비교할 숫자가 없다. 앤트로픽은 Fable 5.1을 자사 모델 가운데 &quot;느린 편&quot;으로 분류한다.</p>
    <h2 class="psub">종합 점수는 같은데, 비용은 두 배 넘게</h2>
    <p class="ptext">독립 평가 기관인 Artificial Analysis의 종합 지수(9월 9일, v4.3)에서 두 모델은 나란히 53점, 공동 1위다. 코딩 에이전트 지수도 62점으로 같다.</p>
    <p class="ptext">차이는 같은 점수를 내는 데 든 비용에서 난다. 지수 과제 하나를 푸는 데 평균 Fable 5.1은 7.63달러, 아스트라는 3.26달러를 썼다. 토큰 가격이 같은데 비용이 다른 이유는 말의 양이다. 과제 하나에 Fable 5.1은 출력 토큰을 약 7만 8천 개, 아스트라는 약 2만 7천 개 썼다.</p>
    <figure class="art__fig">
      <picture><source media="(max-width: 640px)" srcset="https://designrefs.com/articles/img/fable-astra-cost-m.svg" width="600" height="1205" /><img src="https://designrefs.com/articles/img/fable-astra-cost.svg" alt="같은 점수를 내는 데 든 비용과 말의 양. 막대가 짧을수록 적게 썼다는 뜻이다." width="1200" height="459" loading="lazy" decoding="async" /></picture>
      <figcaption>같은 점수를 내는 데 든 비용과 말의 양. 막대가 짧을수록 적게 썼다는 뜻이다.</figcaption>
    </figure>
    <p class="ptext">한 가지 조심할 점이 있다. 이 지수는 아스트라가 나온 뒤 일주일 사이에 두 번 개편됐고, 그 사이 아스트라는 5위에서 1위로 올라왔다. 아직 자리 잡은 숫자라고 보기는 이르다.</p>
    <h2 class="psub">일의 종류가 바뀌면 순위도 바뀐다</h2>
    <div class="art__tablewrap"><table class="art__table">
      <thead><tr><th>평가</th><th>무엇을 재나</th><th>Fable 5.1</th><th>아스트라</th><th>누가 쟀나</th></tr></thead>
      <tbody>
        <tr><td>Code Arena: WebDev</td><td>웹앱을 만들게 하고 사람이 둘 중 고름</td><td>1758점 (2위)</td><td><strong>1800점 (1위)</strong></td><td>Arena 사용자 투표</td></tr>
        <tr><td>Agent Arena</td><td>도구를 써서 하는 긴 작업</td><td><strong>1위</strong></td><td>2위</td><td>Arena 사용자 투표</td></tr>
        <tr><td>Design Arena 3D</td><td>3D 장면 만들기</td><td>1423점 (3위)</td><td><strong>1481점 (1위)</strong></td><td>Design Arena 사용자 투표</td></tr>
        <tr><td>Terminal-Bench 4.0</td><td>터미널에서 하는 코딩 작업</td><td>55.8%</td><td><strong>57.7%</strong></td><td>오픈AI 발표</td></tr>
        <tr><td>DeepSWE v1.1</td><td>긴 호흡의 실제 개발 과제</td><td>67.4%</td><td><strong>74.1%</strong></td><td>오픈AI 발표</td></tr>
        <tr><td>인류의 마지막 시험 (도구 사용)</td><td>전문가 수준의 문제</td><td><strong>65.0%</strong></td><td>57.2%</td><td>오픈AI 발표</td></tr>
      </tbody>
    </table></div>
    <p class="art__note">출처: <a href="https://runtimewire.com/article/arena-gpt-6-astra-webdev-leaderboard-claude-agents" target="_blank" rel="noopener">Runtime Wire</a> (Arena, 9월 9~13일), <a href="https://betterstack.com/community/guides/ai/kimi-claude-astra-design/" target="_blank" rel="noopener">Better Stack</a> (Design Arena), <a href="https://www.vellum.ai/blog/gpt-6-astra-benchmarks-explained" target="_blank" rel="noopener">Vellum</a> (오픈AI 발표 표).</p>
    <p class="ptext">웹 화면을 만드는 대결에서는 아스트라가 앞서고, 도구를 오래 쓰는 에이전트 대결에서는 Fable 5.1이 앞선다. 사람이 직접 고르는 투표형 평가에서도 결과가 이렇게 갈린다.</p>
    <p class="ptext">눈여겨볼 줄은 맨 아래다. 오픈AI가 직접 낸 발표 표인데도 전문가 수준 문제에서는 Fable 5.1이 더 높게 나와 있다.</p>
    <p class="ptext">두 회사가 서로 다른 시험을 골라 발표한다는 점도 알아 두면 좋다. 앤트로픽은 Fable 5.1의 SWE-bench Pro 점수를 81.2%로 냈지만, 오픈AI는 아스트라의 같은 점수를 내지 않았다. 같은 시험 점수가 나란히 놓인 경우가 생각보다 적다.</p>
    <h2 class="psub">디자이너들의 반응</h2>
    <p class="ptext">오픈AI는 아스트라를 소개하면서 <a href="https://x.com/OpenAIDevs/status/2095596149654868092" target="_blank" rel="noopener">프런트엔드 디자인의 시각적 판단력</a>을 앞세웠다. 스케치나 레퍼런스를 주면 동작하는 화면으로 옮기고 레이아웃, 타이포그래피, 간격을 다듬는다는 설명이다.</p>
    <p class="ptext">먼저 써 본 디자이너들의 평은 한쪽으로 쏠리지 않는다. 한 비교 글(<a href="https://eidosdesign.substack.com/p/claude-fable-51-vs-gpt-6-astra-for" target="_blank" rel="noopener">Eidos Design</a>, 9월 7일)은 이렇게 정리했다.</p>
    <ul class="ptext-list">
      <li><strong>아스트라</strong>: 첫 초안이 이미 완성품에 가깝다. 레이어와 공간을 잘 다루고 3D·CAD에 강하다. 대신 덜어 내야 할 때 더하는 버릇이 있어 화면을 과하게 채우고, 틀릴 때도 자신 있게 틀린다.</li>
      <li><strong>Fable 5.1</strong>: 절제된 쪽이라 실제로 내보낼 화면으로 다듬는 데 낫다. 대신 과감함이 부족해 손을 한 번 더 봐야 한다.</li>
      <li><strong>둘 다</strong>: 진짜 취향은 없다.</li>
    </ul>
    <p class="ptext">다섯 가지 디자인 과제를 나눠 시켜 본 비교(<a href="https://betterstack.com/community/guides/ai/kimi-claude-astra-design/" target="_blank" rel="noopener">Better Stack</a>, 9월 14일)도 결론이 비슷하다. 웹 디자인은 오히려 Kimi K3가 가장 나았고, 3D는 아스트라, 2D 게임은 Fable 5.1이 이겼다. UI 컴포넌트는 셋이 비슷했고, 모바일 앱 디자인은 셋 다 그대로 쓸 수준이 아니었다.</p>
    <p class="ptext">하나 더 있다. Artificial Analysis는 발표 자료 같은 문서의 완성도를 재는 항목에서 아스트라가 이전 모델인 GPT-5.6 Sol보다 오히려 낮게 나왔다고 적었다. 슬라이드를 많이 만드는 사람이라면 참고할 만하다.</p>
    <h2 class="psub">정리하면</h2>
    <p class="ptext">가격표는 같지만 실제 비용은 쓰는 방식에 따라 갈린다. 긴 자료를 붙여 두고 여러 번 묻는 작업은 캐시가 싼 Fable 5.1이, 짧게 한 번에 답을 받는 작업은 말수가 적은 아스트라가 유리하다.</p>
    <p class="ptext">평가에서는 웹 화면과 3D를 빠르게 뽑는 쪽은 아스트라가, 도구를 오래 쓰는 긴 작업은 Fable 5.1이 앞선다. 먼저 써 본 디자이너들이 권하는 방식도 이 결과와 맞닿아 있다. 첫 탐색은 아스트라로, 다듬는 마무리는 Fable 5.1로.</p>
    <p class="ptext">그리고 둘 다 나온 지 한 달이 안 된 모델이다. 순위는 몇 주 안에 또 바뀔 수 있다. 결국 내 작업에 맞는지는 내 작업으로 한 번 돌려 봐야 안다.</p>
    <p class="ptext">AI 툴은 종류별로 <a href="https://designrefs.com/ai/">AI 디자인 툴</a>에 모아 두었다. 어떤 도구든 작업 흐름 어디에 끼워 넣을지는 <a href="https://designrefs.com/articles/ai-design-tools-in-practice/">AI가 시안을 서른 장 뽑아 줘도 일이 줄지 않는 이유</a>에 따로 적었다.</p>]]></content:encoded>
    </item>
    <item>
      <title>AI가 시안을 서른 장 뽑아 줘도 일이 줄지 않는 이유</title>
      <link>https://designrefs.com/articles/ai-design-tools-in-practice/</link>
      <guid isPermaLink="true">https://designrefs.com/articles/ai-design-tools-in-practice/</guid>
      <pubDate>Fri, 25 Sep 2026 09:00:00 +0900</pubDate>
      <category>AI 디자인</category>
      <description>탐색과 양산은 AI에게, 방향과 검수는 사람에게. 한동안 써 보고 나서야 보인 경계에 대하여.</description>
      <content:encoded><![CDATA[    <p class="ptext">프롬프트 한 줄을 넣고 기다리면 몇십 초 만에 시안이 쏟아진다.</p>
    <p class="ptext">처음 그 화면을 봤을 땐 솔직히 조금 무서웠다. 이제 내 일은 어떻게 되는 걸까.</p>
    <p class="ptext">그런데 몇 달을 써 보니 이상한 일이 생겼다. 시안은 훨씬 많아졌는데 퇴근 시간은 그대로다. 어떤 날은 오히려 늦어졌다.</p>
    <p class="ptext">서른 장을 받아 놓고 한참을 넘겨 본다. 다 그럴듯하다. 그런데 클라이언트에게 보낼 만한 건 한 장도 없다. 이 이상한 구간을 한동안 통과하고 나서야 알게 됐다. AI가 줄여 주는 일과 그대로 남는 일은 따로 있다.</p>
    <h2 class="psub">빈 화면 앞의 시간</h2>
    <p class="ptext">제일 크게 달라진 건 시작이다.</p>
    <p class="ptext">아무것도 없는 아트보드 앞에 앉아 있는 시간. 디자인 일에서 가장 막막하고 가장 아까운 시간이다. AI는 이 구간을 잘 메워 준다. 방향이 세 갈래쯤 있을 때 각각 한 장씩 뽑아 놓고 보면, 회의에서 말로 설명하느라 쓰던 삼십 분이 사라진다.</p>
    <p class="ptext">중요한 건 그 이미지를 쓰려고 뽑는 게 아니라는 점이다. 대화를 시작하기 위한 재료다. &quot;이쪽이요, 이쪽은 아니고요.&quot; 그 한마디를 끌어내는 데 이만한 도구가 없다.</p>
    <p class="ptext">손은 많이 가는데 판단은 거의 필요 없는 일도 줄었다. 배경 지우기, 저해상도 이미지 키우기, 같은 배너를 열두 가지 비율로 바꾸기. 한 시간씩 붙잡고 있던 일들이 몇 분이면 끝난다. 이 부분은 누가 뭐라 해도 확실한 이득이다.</p>
    <h2 class="psub">그리고 여기서 막힌다</h2>
    <p class="ptext">같은 걸 한 번 더 만들어 달라고 하면 그때부터 어긋난다.</p>
    <p class="ptext">마음에 드는 캐릭터가 나와서 다른 포즈로 하나 더 뽑으면, 미묘하게 다른 사람이 나온다. 눈매가 조금 다르고 머리 길이가 조금 다르다. 브랜드 일러스트 세트나 시리즈 광고처럼 일관성이 곧 품질인 작업에서는 이게 치명적이다.</p>
    <p class="ptext">&quot;조금만 고쳐 주세요&quot;도 잘 통하지 않는다. 오른쪽 여백만 4px 줄이고 싶은데, 생성 도구는 매번 처음부터 새로 그린다. 디자인 일의 절반이 수정이라는 걸 생각하면, 이 구간에서 툴을 붙잡고 있을 때 시간이 가장 많이 샌다.</p>
    <p class="ptext">한글도 아직 멀었다. 받침이 사라지고 자모가 흩어진다. 글자가 들어가는 결과물은 글자 없이 뽑고, 타이포는 직접 얹는 게 결국 빠르다.</p>
    <p class="ptext">그리고 숫자. 재단선, 실측, 명도 대비 기준처럼 정확히 맞아떨어져야 하는 것들을 AI는 그럴듯하게 틀린다. 대놓고 틀리면 차라리 낫다. 그럴듯하게 틀린 건 검수에서 놓친다.</p>
    <h2 class="psub">그래서 요즘은 이렇게 나눈다</h2>
    <p class="ptext">일의 흐름을 놓고 보면 AI가 들어올 자리가 꽤 분명해진다.</p>
    <p class="ptext">리서치와 탐색에서는 적극적으로 쓴다. 어차피 버릴 결과물이라 부담이 없다. 방향을 정하는 순간에는 쓰지 않는다. 뽑힌 것 중에서 고르는 게 아니라, 뭘 만들지 먼저 정하고 재료를 찾는 순서가 맞다고 생각한다.</p>
    <p class="ptext">실제로 만드는 단계에서는 평소 쓰던 툴로 돌아온다. AI는 옆에서 배경을 정리하거나 해상도를 올리는 조수 역할만 한다. 그러다 여러 규격, 여러 채널로 찍어 내는 단계가 오면 다시 AI의 비중이 올라간다. 마지막 검수는 사람이 한다. 글자, 손가락 개수, 로고 모양, 치수.</p>
    <blockquote class="art__quote">방향을 정하는 일과 마지막에 확인하는 일. 이 두 가지를 넘기면 사고가 난다.</blockquote>
    <p class="ptext">반대로 탐색과 양산을 계속 손으로 하고 있으면 남들보다 느려진다. 결국 어디에 쓰느냐의 문제다.</p>
    <h2 class="psub">툴을 고를 때 먼저 보는 것</h2>
    <p class="ptext">새 툴이 나오면 결과물보다 약관을 먼저 본다. 무료로 만든 이미지와 유료로 만든 이미지의 권리가 다르게 적힌 곳이 있어서다. 내가 올린 파일이 학습에 쓰이는지, 그걸 끌 수 있는지도 본다. 클라이언트 파일을 올리는 도구라면 이게 제일 중요하다.</p>
    <p class="ptext">그다음은 파일이다. PNG 한 장만 주는 툴과 레이어나 벡터를 주는 툴은 그 뒤의 작업량이 완전히 다르다.</p>
    <p class="ptext">마지막으로, 지금 쓰는 툴 안에서 되는지. 피그마나 포토샵 안에서 끝나는 기능은 결국 쓰게 되고, 탭을 하나 더 열어야 하는 기능은 결국 안 쓰게 된다. 종류별로 모아 둔 목록은 <a href="https://designrefs.com/ai/">AI 디자인 툴</a>에 있다.</p>
    <h2 class="psub">고르는 눈</h2>
    <p class="ptext">툴이 좋아질수록 실력의 무게중심이 옮겨 가는 게 느껴진다.</p>
    <p class="ptext">예전에는 머릿속 이미지를 화면에 옮기는 손이 실력이었다. 그 문턱이 낮아졌다. 대신 무엇을 만들지 정하는 힘, 그리고 쏟아진 것들 중에서 하나를 고르는 눈의 차이가 전보다 훨씬 크게 벌어진다.</p>
    <p class="ptext">서른 장 중에 한 장을 고르는 일은 서른 장을 만드는 일보다 어렵다. 이건 프롬프트로 해결되지 않는다.</p>
    <p class="ptext">그 눈은 결국 많이 본 사람에게 생긴다. 그래서 AI를 쓸수록 레퍼런스를 보는 시간이 줄기는커녕 늘었다. 프롬프트에 쓰는 단어도 거기서 나온다. 그 이야기는 <a href="https://designrefs.com/articles/describing-design-style/">‘느낌 있게’를 말로 옮기는 일</a>에 따로 적었다.</p>]]></content:encoded>
    </item>
    <item>
      <title>‘느낌 있게’를 말로 옮기는 일</title>
      <link>https://designrefs.com/articles/describing-design-style/</link>
      <guid isPermaLink="true">https://designrefs.com/articles/describing-design-style/</guid>
      <pubDate>Fri, 25 Sep 2026 09:00:00 +0900</pubDate>
      <category>디자인</category>
      <description>클라이언트에게도, 프롬프트 창에도 결국 말로 설명해야 한다. 스타일을 여섯 겹으로 쪼개서 말하는 방법.</description>
      <content:encoded><![CDATA[    <p class="ptext">&quot;좀 더 느낌 있게 해 주세요.&quot;</p>
    <p class="ptext">처음 이 말을 들었을 땐 속으로 한숨을 쉬었다. 느낌이라니. 어떤 느낌을 말하는 걸까.</p>
    <p class="ptext">시간이 지나고 보니 그 말을 한 사람이 잘못한 건 아니었다. 머릿속 이미지를 말로 옮기는 연습을 해 본 사람은 많지 않다. 문제는 디자이너인 나도 그 연습이 부족했다는 거다. &quot;어떤 느낌을 원하세요?&quot;라고 되묻는 것 말고는 할 수 있는 게 없었으니까. 그러면 회의는 두 시간을 하고도 제자리다.</p>
    <p class="ptext">요즘은 여기에 하나가 더 붙었다. 이제 툴에게도 말로 지시한다. 프롬프트를 쓰는 일은 클라이언트와 이야기하는 일과 놀랄 만큼 닮았다. 스타일을 말로 쪼개는 연습이 그대로 실력이 되는 때다.</p>
    <h2 class="psub">바우하우스 느낌으로 가죠</h2>
    <p class="ptext">스타일 이름은 편리하다. 그리고 위험하다.</p>
    <p class="ptext">같은 &quot;바우하우스&quot;를 듣고 누군가는 빨강, 노랑, 파랑의 기하학 도형을 떠올리고, 누군가는 회색 톤의 산세리프와 격자를 떠올린다. 둘 다 틀리지 않았다. 스타일 이름은 수십 년 치 작업을 한 단어에 욱여넣은 거라 해상도가 낮을 수밖에 없다.</p>
    <p class="ptext">그래서 이름은 출발점으로만 쓰고, 거기서부터 쪼갠다. 나는 보통 여섯 겹으로 나눈다.</p>
    <h2 class="psub">여섯 겹</h2>
    <p class="ptext">첫 번째는 <strong>시대와 양식</strong>이다. 아르데코, 스위스 스타일, 멤피스, Y2K. 여기서 이름보다 중요한 건 그 양식이 무엇에 반대하면서 나왔는지다. 스위스 스타일은 장식을 덜어 내려고 격자를 택했고, 멤피스는 그 금욕적인 태도가 지겨워서 튀어나왔다. 맥락을 알면 어디까지 밀어붙여도 되는지가 보인다. 연대순으로 정리한 목록은 <a href="https://designrefs.com/styles/">스타일 사전</a>에 있다.</p>
    <p class="ptext">두 번째는 <strong>형태</strong>. 기하학적인지 유기적인지, 모서리가 각졌는지 둥근지, 선이 굵은지 가는지. 이 층은 클라이언트도 금방 알아듣는다. &quot;각지게 가면 단단해 보이고, 둥글리면 친근해 보여요.&quot; 형태와 인상을 짝지어 말하면 대화가 앞으로 나간다.</p>
    <p class="ptext">세 번째는 <strong>색</strong>인데, &quot;파란색&quot;으로 끝내면 아무 말도 안 한 것과 같다. 채도가 높은지 낮은지, 배경과 글자의 명도 차가 큰지, 몇 가지 색으로 버티는지까지 말해야 한다. &quot;도파민 컬러&quot; 같은 유행어도 결국 채도와 색 수로 번역해야 손이 움직인다.</p>
    <p class="ptext">네 번째는 <strong>질감과 매체</strong>. 가장 자주 빠뜨리지만 효과는 제일 크다. 리소그래프, 실크스크린, 신문의 망점, 판이 살짝 어긋난 인쇄, 복사기를 여러 번 거친 거친 톤, 필름 그레인. 같은 도형도 어떤 매체로 찍었느냐에 따라 전혀 다른 물건이 된다.</p>
    <p class="ptext">다섯 번째는 <strong>구도와 시선</strong>. 가운데 정렬인지 비대칭인지, 격자가 드러나는지 숨어 있는지, 여백을 구조로 쓰는지 남는 공간으로 두는지. 사진이 들어가면 카메라 높이와 조명 방향도 이 층에 들어온다.</p>
    <p class="ptext">마지막이 <strong>분위기</strong>다. 단정한, 어수선한, 건조한, 비싼, 싼 티 나는. 이 형용사로 대화를 시작하면 &quot;느낌 있게&quot;가 되고, 앞의 다섯 겹을 정한 뒤에 붙이면 미세 조정이 된다. 순서가 전부다.</p>
    <h2 class="psub">사람에게 말할 때</h2>
    <p class="ptext">이름을 꺼냈다면 그 자리에서 이미지를 세 장 띄운다. &quot;이 중에 어느 쪽이에요?&quot; 말로만 주고받으면 서로 다른 그림을 보면서 합의했다고 착각한다. 이 질문 하나가 회의 한 시간을 아낀다.</p>
    <p class="ptext">싫은 것도 같이 묻는다. 원하는 걸 말하기는 어려워도 싫은 건 다들 분명하다. 그라디언트는 안 된다든지, 손글씨체는 빼 달라든지. 금지 목록 세 줄만 받아 둬도 시안이 크게 빗나가지 않는다.</p>
    <h2 class="psub">기계에게 말할 때</h2>
    <p class="ptext">프롬프트도 같은 여섯 겹을 쓴다. 다만 기계는 사람과 조금 다르게 알아듣는다.</p>
    <p class="ptext">형용사보다 매체 이름이 강하다. &quot;빈티지한&quot;보다 &quot;1970년대 오프셋 인쇄, 잉크 번짐&quot;이 훨씬 정확하게 나온다. 부정문은 잘 먹히지 않는다. &quot;텍스트 없이&quot;라고 써도 글자가 나온다. 빼고 싶은 걸 말하기보다 대신 들어갈 걸 말하는 편이 낫다.</p>
    <p class="ptext">한 문장에 다섯 가지를 넣으면 세 가지만 반영된다. 중요한 걸 앞에 두고, 나머지는 결과를 보면서 한 겹씩 얹는다.</p>
    <p class="ptext">살아 있는 작가 이름을 넣으면 결과는 빨리 잡힌다. 하지만 그 화풍을 그대로 가져다 상업 작업에 쓰는 건 다른 문제다. 양식 이름과 매체 이름으로 돌려 말하는 쪽이 마음이 편하다.</p>
    <blockquote class="art__quote">막히는 지점은 대개 감각이 아니라 어휘다.</blockquote>
    <h2 class="psub">결국 단어의 수</h2>
    <p class="ptext">말로 옮기는 힘은 아는 단어의 수에 비례한다. 리소그래프를 모르면 리소그래프 느낌을 요청할 수 없고, 미스레지스터를 모르면 그 어긋남을 일부러 쓸 수 없다.</p>
    <p class="ptext">그래서 요즘은 스타일 이름과 인쇄 용어를 조금씩 의식해서 외운다. 자주 쓰는 서른 개쯤이 손에 붙으니 회의가 눈에 띄게 짧아졌다. 모르는 말이 나오면 <a href="https://designrefs.com/glossary/">용어 사전</a>을 열어 둔다.</p>
    <p class="ptext">&quot;느낌 있게&quot;라는 말을 들어도 이제는 한숨보다 질문이 먼저 나온다. 돌아보면 그게 제일 큰 변화였다.</p>]]></content:encoded>
    </item>
    <item>
      <title>저장만 하고 다시 열지 않는 레퍼런스들</title>
      <link>https://designrefs.com/articles/how-to-collect-references/</link>
      <guid isPermaLink="true">https://designrefs.com/articles/how-to-collect-references/</guid>
      <pubDate>Fri, 25 Sep 2026 09:00:00 +0900</pubDate>
      <category>디자인</category>
      <description>보드는 스무 개가 넘는데 작업할 땐 처음부터 다시 검색한다. 꺼내 쓸 수 있게 모으는 법.</description>
      <content:encoded><![CDATA[    <p class="ptext">핀터레스트 보드가 스무 개를 넘었다. 북마크 폴더는 열두 개, 인스타그램 저장은 세다가 그만뒀다.</p>
    <p class="ptext">그런데 막상 포스터 작업을 시작하면 처음부터 다시 검색한다. 모아 둔 건 그렇게 많은데 쓸 수 있는 게 없다.</p>
    <p class="ptext">한동안은 내가 게을러서 그런 줄 알았다. 정리를 안 해서, 태그를 안 달아서. 그런데 정리를 해도 똑같았다. 문제는 부지런함이 아니라 모으는 방식에 있었다.</p>
    <h2 class="psub">저장 버튼의 착각</h2>
    <p class="ptext">저장 버튼을 누르는 순간은 기분이 좋다. 쓸모 있는 걸 하나 챙긴 것 같다.</p>
    <p class="ptext">사실 그 순간 생기는 건 &#x27;나중에 쓸 수 있을 것 같은 느낌&#x27;뿐이다. 이미지는 다시 꺼내기 어려운 곳으로 들어간다. 저장할 때의 나와 꺼낼 때의 나는 다른 말을 쓰기 때문이다.</p>
    <p class="ptext">저장할 땐 &quot;예쁜 포스터&quot;로 넣는다. 꺼낼 땐 &quot;여백 많은 세로형 편집물&quot;을 찾는다. 넣는 말과 찾는 말이 어긋나 있으니 찾아질 리가 없다.</p>
    <p class="ptext">게다가 왜 저장했는지를 적지 않는다. 여섯 달 뒤에 다시 보면 뭐가 좋았는지 기억이 안 난다. 색이었나, 여백이었나, 폰트였나. 이유가 사라진 레퍼런스는 그냥 예쁜 사진이다.</p>
    <h2 class="psub">이유를 한 단어로</h2>
    <p class="ptext">완벽하게 분류하려던 시도는 매번 실패했다. 폴더를 스무 개 만들어 두면 어디에 넣을지 고민하다가 결국 저장을 안 하게 된다.</p>
    <p class="ptext">그래서 방법을 바꿨다. 이미지 하나에 <strong>저장한 이유 하나만</strong> 남긴다. 여백, 그리드, 색 조합, 질감, 폰트 조합, 카피 톤. 나중에 찾을 때 떠올리는 말이 바로 이 단어들이다.</p>
    <p class="ptext">핀터레스트라면 보드 이름만 바꿔도 충분하다. &quot;포스터&quot;, &quot;웹디자인&quot;처럼 매체로 나눈 보드는 커지기만 하고 열리지 않는다. &quot;여백이 좋은 것&quot;, &quot;두 색으로 버티는 것&quot;처럼 이유로 나눈 보드는 작업할 때 실제로 열린다.</p>
    <h2 class="psub">이미지와 주소는 다르다</h2>
    <p class="ptext">한참 뒤에야 알았는데, 나는 성격이 전혀 다른 두 가지를 한 폴더에 섞고 있었다.</p>
    <p class="ptext">이미지 레퍼런스는 많이 모으고 태그로 찾는 게 맞다. 핀터레스트나 Savee, Are.na는 그 일을 하라고 만들어진 도구다.</p>
    <p class="ptext">반면 사이트 주소는 적게, 늘 같은 자리에 두는 게 맞다. 폰트 받는 곳, 아이콘 받는 곳, 팔레트 만드는 곳. 스무 개면 충분하고, 그 스무 개를 매번 같은 방식으로 여는 게 중요하다.</p>
    <p class="ptext">시간을 제일 많이 잡아먹던 건 오히려 이쪽이었다. 매번 눈누 주소를 검색해서 들어가고, 몇 년 전에 저장한 목업 사이트는 이미 도메인이 사라져 있고. 이 사이트를 만든 것도 결국 그 불편 때문이었다. <a href="https://designrefs.com/ui-ux/">UI/UX</a>나 <a href="https://designrefs.com/graphic/">그래픽·브랜딩</a>처럼 분야별로 나눠 두고, 죽은 주소는 지운다.</p>
    <h2 class="psub">모으는 일과 쓰는 일</h2>
    <p class="ptext">평소에 모으는 일과 작업할 때 찾는 일을 같은 일로 생각하면 둘 다 안 된다.</p>
    <p class="ptext">평소에는 넓고 얕게 모은다. 출퇴근길에 보는 건 분류하지 않고 일단 한곳에 던져 둔다. 이 단계에서 정리까지 하려 들면 피곤해서 오래 못 간다.</p>
    <p class="ptext">작업이 시작되면 좁고 깊게 간다. 모아 둔 데서 고르는 게 아니라 새로 찾는다. 프로젝트 폴더를 하나 만들고, 이번 작업에만 쓸 레퍼런스를 스무 장 남짓 모은다. 쌓아 둔 보드는 그 출발점 정도로만 쓴다.</p>
    <blockquote class="art__quote">레퍼런스는 프로젝트마다 새로 모으는 게 정상이다.</blockquote>
    <p class="ptext">평생 쓸 라이브러리를 만들겠다는 마음이 오히려 수집을 무겁게 만든다. 오래 남는 건 이미지가 아니라 그걸 고른 기준이다.</p>
    <h2 class="psub">버리면서 알게 되는 것</h2>
    <p class="ptext">모은 걸 정리하는 가장 좋은 방법은 결국 버리는 거였다. 한 달에 한 번, 십 분만 보드를 열어서 지금 봐도 좋은지 본다. 아니면 지운다.</p>
    <p class="ptext">지우다 보면 패턴이 보인다. 내가 자꾸 저장하는 것들, 취향이 기우는 방향, 남의 것을 그대로 따라가고 있던 지점. 레퍼런스를 모으면서 얻는 가장 큰 소득은 아마 이것일 거다. 이미지 오백 장보다 &quot;나는 여백이 큰 비대칭 구성을 좋아한다&quot;는 한 문장이 작업을 더 많이 바꾼다.</p>
    <p class="ptext">그다음은 좋아 보이는 이유를 문장으로 써 보는 일이다. &quot;사진을 위쪽 3분의 2에 두고 아래를 비워서 시선이 제목으로 떨어진다.&quot; 이유를 말로 옮길 수 있으면 그 원리를 다른 소재에 가져갈 수 있다. 말로 옮기지 못하면 모양만 가져오게 된다.</p>
    <p class="ptext">그 말을 찾는 법은 <a href="https://designrefs.com/articles/describing-design-style/">‘느낌 있게’를 말로 옮기는 일</a>에 조금 더 적어 두었다.</p>]]></content:encoded>
    </item>
    <item>
      <title>디자이너는 어디서 이야기를 나눌까</title>
      <link>https://designrefs.com/articles/korean-design-community-map/</link>
      <guid isPermaLink="true">https://designrefs.com/articles/korean-design-community-map/</guid>
      <pubDate>Fri, 25 Sep 2026 09:00:00 +0900</pubDate>
      <category>커뮤니티</category>
      <description>읽고 싶을 때, 만든 걸 보여 주고 싶을 때, 급하게 묻고 싶을 때. 국내 디자인 커뮤니티를 쓰임새대로 나눠 봤다.</description>
      <content:encoded><![CDATA[    <p class="ptext">혼자 일하다 보면 가끔 말이 고프다.</p>
    <p class="ptext">이 폰트를 상업용으로 써도 되는지, 이 견적이 적당한지, 다들 요즘 어떤 툴을 쓰는지. 검색하면 답이 나올 것 같은데 막상 찾아보면 몇 년 전 글뿐이다. 이럴 때 필요한 건 정보보다 사람이다.</p>
    <p class="ptext">그래서 커뮤니티를 기웃거리게 된다. 한두 곳 가입하다 보면 어느새 열 곳이 넘고, 알림만 쌓인다. 여기저기 발을 걸쳐 놓았는데 정작 어디에도 속해 있지 않은 느낌.</p>
    <p class="ptext">한참 헤매고 나서 알게 된 건, 커뮤니티마다 잘하는 일이 다르다는 거였다. 다 해 주는 곳은 없다.</p>
    <h2 class="psub">읽고 싶을 때</h2>
    <p class="ptext"><strong>서핏</strong>은 여기저기 흩어진 디자인과 기획 글을 한 화면에 모아 준다. 출근길에 훑기 좋다. 몰랐던 매체를 알게 되는 게 장점이고, 읽은 척하고 넘기게 되는 게 단점이다.</p>
    <p class="ptext"><strong>요즘IT</strong>에는 실무자가 쓴 긴 글이 많다. 디자인만 다루는 곳은 아니지만 기획이나 개발과 걸쳐 있는 주제가 많아서, 협업하다 답답했던 지점을 반대편에서 읽게 된다. 이게 의외로 위로가 된다.</p>
    <p class="ptext">그래픽이나 공간, 산업 디자인 이야기가 그리울 땐 <strong>디자인정글</strong>이나 <strong>월간 디자인</strong>으로 간다. 온라인 디자인 담론이 UI와 프로덕트 쪽으로 기울어 있다 보니, 전시나 공모전, 업계 사람들 인터뷰는 이쪽이 훨씬 풍성하다. <strong>디자인프레스</strong>는 브랜드와 공간 이야기를 사진 위주로 보여 준다.</p>
    <h2 class="psub">만든 걸 꺼내 놓고 싶을 때</h2>
    <p class="ptext"><strong>디스콰이엇</strong>은 사이드 프로젝트를 올리고 만드는 과정을 기록하는 곳이다. 결과물만 거는 포트폴리오 사이트와 달리, 왜 만들었고 어디서 넘어졌는지를 쓰는 분위기가 있다. 혼자 뭔가 만들고 있다면 여기서 첫 반응을 받아 보는 것도 좋다.</p>
    <p class="ptext"><strong>브런치</strong>는 긴 글을 쓰기 편하다. 회고나 일하는 방식을 꾸준히 쓰는 디자이너가 꽤 많고, 검색으로 찾아오는 독자가 따로 있다.</p>
    <p class="ptext">작업을 보여 주고 싶다면 국내에선 <strong>노트폴리오</strong>, 해외는 여전히 <strong>비핸스</strong>와 <strong>드리블</strong>이다. 비핸스는 프로젝트 전체의 흐름을 보여 주는 곳이고, 드리블은 한 장의 완성도로 승부하는 곳이다. 웹 작업이라면 <strong>GDWEB</strong>이나 <strong>디비컷</strong> 수상작을 보는 것만으로 국내 흐름이 읽힌다.</p>
    <h2 class="psub">일을 고민할 때</h2>
    <p class="ptext"><strong>커리어리</strong>에는 현직자의 짧은 글과 질문, 답변이 섞여 돈다. 특정 회사 분위기나 직무 전환처럼 검색으로는 안 나오는 이야기가 여기서 나온다.</p>
    <p class="ptext"><strong>원티드</strong>나 <strong>랠릿</strong> 같은 채용 서비스도 가끔 들여다본다. 당장 옮길 생각이 없어도 직무 설명을 읽다 보면 요즘 시장이 디자이너에게 무엇을 바라는지가 보인다. 반년에 한 번쯤이면 충분하다. 채용 쪽은 <a href="https://designrefs.com/jobs/">디자이너 채용</a>에 모아 두었다.</p>
    <p class="ptext">기업 리뷰는 참고만 한다. 불만 있는 사람이 더 열심히 쓰는 구조라 한쪽으로 기울어 있기 마련이다.</p>
    <h2 class="psub">가장 빠른 곳, 가장 빨리 잊히는 곳</h2>
    <p class="ptext">제일 빨리 답을 받는 곳은 오픈채팅방이나 디스코드다. 인쇄소 추천, 폰트 라이선스 해석, 견적 감각. 이런 건 검색보다 사람에게 묻는 게 훨씬 빠르다.</p>
    <p class="ptext">대신 두 가지는 알고 들어가는 게 좋다. 대부분 광고를 금지한다. 내 작업이나 서비스를 알리고 싶으면 방장에게 먼저 묻는 게 예의다. 그리고 대화가 흘러가 버린다. 좋은 답도 다음 날이면 스크롤 저 위에 묻힌다. 쓸 만한 건 그때그때 따로 옮겨 적어 둬야 한다.</p>
    <h2 class="psub">셋이면 충분하다</h2>
    <p class="ptext">열 곳에 발을 걸치는 것보다 목적마다 한 곳씩, 셋 정도로 줄이는 편이 오래간다. 읽는 곳 하나, 내 이야기를 쓰는 곳 하나, 급할 때 묻는 곳 하나.</p>
    <p class="ptext">그리고 어디든 한 줄이라도 써 보는 게 좋다. 커뮤니티에서 가장 많이 얻어 가는 사람은 대개 뭐라도 쓴 사람이다. 질문 하나, 댓글 하나라도.</p>
    <p class="ptext">이 사이트에도 그런 자리를 하나 만들었다. <a href="https://designrefs.com/talk/">디자인 잡담</a>에 요즘 하는 작업이나 막힌 것을 편하게 남겨 주면 좋겠다. 다른 곳들의 전체 목록은 <a href="https://designrefs.com/community/">커뮤니티·매거진</a>에 있다.</p>]]></content:encoded>
    </item>
    <item>
      <title>AI로 만든 이미지, 클라이언트 작업에 써도 될까</title>
      <link>https://designrefs.com/articles/ai-image-commercial-use/</link>
      <guid isPermaLink="true">https://designrefs.com/articles/ai-image-commercial-use/</guid>
      <pubDate>Fri, 25 Sep 2026 09:00:00 +0900</pubDate>
      <category>AI 디자인</category>
      <description>저작권, 약관, 닮은꼴, 계약서. 실무에서 확인해야 할 것들을 순서대로 적었다.</description>
      <content:encoded><![CDATA[    <p class="ptext">이미지 생성 툴을 한 달쯤 쓰다 보면 어느 날 문득 이런 생각이 든다. 이거, 클라이언트 작업에 넣어도 되나.</p>
    <p class="ptext">답이 간단하지 않다. 저작권이 생기는지, 툴의 약관이 허락하는지, 계약서가 막고 있지는 않은지, 결과물이 누군가의 것을 닮지는 않았는지. 층이 여러 개고 각 층에서 따로 걸린다.</p>
    <p class="ptext">법을 공부한 사람은 아니지만, 실무에서 확인해야 할 순서대로 정리해 봤다.</p>
    <p class="ptext"><strong>먼저 밝혀 둘 것.</strong> 이 글은 법률 자문이 아니다. 관련 법과 판결, 서비스 약관은 계속 바뀌고 있다. 규모가 큰 일이라면 꼭 변호사나 클라이언트 법무팀에 확인하자.</p>
    <h2 class="psub">저작권은 사람에게 생긴다</h2>
    <p class="ptext">우리 저작권법은 저작물을 &quot;인간의 사상 또는 감정을 표현한 창작물&quot;로 정의한다. 열쇠는 &#x27;인간&#x27;이라는 두 글자다. 프롬프트만 넣어서 나온 결과물은 사람이 표현한 것으로 보기 어렵다는 게 지금까지의 기본 해석이고, 문화체육관광부가 낸 AI 저작권 안내서도 대체로 같은 방향이었다.</p>
    <p class="ptext">미국도 비슷하다. 저작권청은 사람의 창작적 기여가 없는 AI 산출물의 등록을 받아 주지 않았다. AI 이미지가 들어간 만화책 사례에서는 이미지는 빠지고, 글과 배치처럼 사람이 한 부분만 인정됐다.</p>
    <p class="ptext">실무로 옮기면 이렇다. AI가 뽑은 이미지를 그대로 납품하면 그 이미지에는 누구의 저작권도 없을 가능성이 크다. 경쟁사가 똑같이 가져다 써도 막기 어렵다는 뜻이다. 그 위에 사람이 구성하고 편집하고 타이포를 얹으면, 사람이 한 부분에는 권리가 생긴다.</p>
    <p class="ptext">그래서 기준은 하나로 모인다. <strong>얼마나 오래, 얼마나 독점적으로 쓸 것인가.</strong></p>
    <p class="ptext">배너 한 장의 배경이라면 크게 걱정할 일이 아니다. 십 년 쓸 로고나 대표 캐릭터라면 이야기가 완전히 달라진다. 지킬 수 없는 자산을 브랜드의 얼굴로 세우는 셈이니까.</p>
    <h2 class="psub">약관은 서비스마다 다르다</h2>
    <p class="ptext">저작권과는 별개로, 각 서비스가 &quot;이렇게 써도 된다&quot;고 정해 둔 조건이 있다. 서비스마다 다르고 생각보다 자주 바뀐다. 가입하기 전에 네 가지는 꼭 본다.</p>
    <ol class="ptext-list">
      <li>상업적으로 써도 되는가. 유료 요금제에서만 허용하거나, 회사 규모에 따라 요금제를 올리라고 하는 곳이 있다.</li>
      <li>결과물의 권리를 넘겨주는 건지, 쓸 수 있게 허락만 하는 건지.</li>
      <li>내가 만든 이미지가 기본으로 공개되는가. 클라이언트 작업이라면 이게 제일 위험하다.</li>
      <li>내가 올린 파일이 학습에 쓰이는가. 시안이나 로고를 올려 작업한다면 끌 수 있는지 봐야 한다.</li>
    </ol>
    <p class="ptext">학습 데이터를 라이선스가 확보된 것으로 제한했다고 밝히는 서비스도 있다. 어도비 파이어플라이가 대표적이고, 일부 요금제에서는 분쟁이 생기면 보상까지 약속한다. 광고나 대기업 인하우스 일에서는 이 조건 하나로 쓸 툴이 정해지기도 한다. 서비스별 성격은 <a href="https://designrefs.com/ai/">AI 디자인 툴</a>에 정리해 두었다.</p>
    <h2 class="psub">누군가를 닮지는 않았나</h2>
    <p class="ptext">저작권도 약관도 통과했는데 여기서 걸리는 경우가 있다.</p>
    <p class="ptext">생성된 이미지가 유명 캐릭터나 로고와 닮았다면 저작권과 상표 양쪽에서 문제가 된다. 프롬프트에 그 이름을 넣지 않았더라도 결과가 닮았으면 마찬가지다. 사람 얼굴이 특정인과 비슷하다면 초상권과 퍼블리시티권 문제가 따라온다. 모델 사진 대신 AI 인물을 쓸 때 가장 조심해야 하는 부분이다.</p>
    <p class="ptext">살아 있는 작가의 이름을 프롬프트에 넣어 상업 작업에 쓰는 건 법적 판단이 엇갈리는 영역이다. 그 전에, 업계에서 쌓아 온 평판의 문제이기도 하다.</p>
    <p class="ptext">납품 전에 이미지 역검색을 한 번 돌려 보는 것만으로도 큰 사고는 대부분 걸러진다. 30초면 된다.</p>
    <h2 class="psub">말하지 않고 쓰는 게 제일 위험하다</h2>
    <p class="ptext">요즘은 계약서에 AI 관련 조항이 들어가는 일이 늘었다. 아예 금지하는 곳도 있고, 미리 알리고 승인을 받으라는 곳도 있고, 출처가 확인된 특정 툴만 허용하는 곳도 있다.</p>
    <p class="ptext">가장 흔한 사고는 말하지 않고 쓰는 것이다. 나중에 알려지면 결과물이 아니라 신뢰의 문제가 된다. 반대로 미리 말하면 대부분 괜찮다고 한다. 배경 텍스처를 AI로 만들었다는 말에 화를 내는 클라이언트는 많지 않다.</p>
    <p class="ptext">말하는 방법도 어렵지 않다. &quot;패턴 배경은 생성형 AI로 만들고 편집은 직접 했습니다.&quot; 이 정도 한 줄이면 된다. 프리랜서라면 이 부분을 계약서 옆에 미리 문서로 만들어 두면 편하다. 표준 계약서 같은 자료는 <a href="https://designrefs.com/freelance/">외주·프리랜서</a>에 모아 두었다.</p>
    <p class="ptext">생성형 AI로 만든 콘텐츠에 그 사실을 표시하도록 하는 규정도 나라마다 생기고 있다. 광고나 공공 프로젝트라면 해당 업종의 가이드라인을 따로 확인하는 편이 안전하다.</p>
    <h2 class="psub">기록이 전부다</h2>
    <p class="ptext">돌아보면 결론은 단순하다. 잠깐 쓰고 버릴 이미지에는 부담 없이 쓴다. 오래 쓸 브랜드 자산에는 AI 단독 생성물을 쓰지 않는다. 사람이 등장하면 한 번 더 확인한다.</p>
    <p class="ptext">그리고 어떤 경우든 기록을 남긴다.</p>
    <p class="ptext">프로젝트 폴더에 텍스트 파일 하나 만들어서 쓴 툴과 날짜, 프롬프트를 적어 두는 습관. 제일 귀찮고, 제일 쓸모 있다. 언젠가 &quot;이거 어떻게 만든 거예요?&quot;라는 질문을 받았을 때, 답할 수 있는 사람과 없는 사람이 여기서 갈린다.</p>]]></content:encoded>
    </item>
  </channel>
</rss>
