<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
  <author>
    <name>Reasonofmoon</name>
  </author>
  <generator uri="https://hexo.io/">Hexo</generator>
  <id>https://reasonofmoon.github.io/</id>
  <link href="https://reasonofmoon.github.io/" rel="alternate"/>
  <link href="https://reasonofmoon.github.io/atom.xml" rel="self"/>
  <rights>All rights reserved 2026, Reasonofmoon</rights>
  <subtitle>AI agent lab notes, learning workflows, PKM systems, and blog operations.</subtitle>
  <title>Reasonofmoon Devlog</title>
  <updated>2026-06-28T23:30:12.139Z</updated>
  <entry>
    <author>
      <name>Reasonofmoon</name>
    </author>
    <category term="AI News" scheme="https://reasonofmoon.github.io/categories/AI-News/"/>
    <category term="AI News" scheme="https://reasonofmoon.github.io/tags/AI-News/"/>
    <category term="AI 데일리 브리핑" scheme="https://reasonofmoon.github.io/tags/AI-%EB%8D%B0%EC%9D%BC%EB%A6%AC-%EB%B8%8C%EB%A6%AC%ED%95%91/"/>
    <category term="AI Daily Briefing" scheme="https://reasonofmoon.github.io/tags/AI-Daily-Briefing/"/>
    <category term="Infographic" scheme="https://reasonofmoon.github.io/tags/Infographic/"/>
    <category term="OpenAI" scheme="https://reasonofmoon.github.io/tags/OpenAI/"/>
    <category term="AI Agents" scheme="https://reasonofmoon.github.io/tags/AI-Agents/"/>
    <category term="Anthropic" scheme="https://reasonofmoon.github.io/tags/Anthropic/"/>
    <category term="Google DeepMind" scheme="https://reasonofmoon.github.io/tags/Google-DeepMind/"/>
    <category term="Computer Use" scheme="https://reasonofmoon.github.io/tags/Computer-Use/"/>
    <content>
      <![CDATA[<p>오늘의 세 가지 뉴스는 frontier model이 <strong>용도별 라인업</strong>, <strong>접근 통제</strong>, <strong>실제 컴퓨터 조작</strong>이라는 세 방향으로 동시에 움직이고 있음을 보여줍니다. 이미지 안의 상태 표기와 별개로, 본문에서는 출처 확실성에 맞춰 공식 확인과 부분 확인을 나누어 적었습니다.</p><p><img src="/images/ai-news/2026-06-29.png" alt="AI 데일리 브리핑 2026.06.29"></p><p><a href="/files/ai-news/2026-06-29/">원본 이미지 크게 보기</a></p><table><thead><tr><th>뉴스</th><th>핵심 의미</th><th>실전 영어 표현</th></tr></thead><tbody><tr><td>OpenAI GPT-5.6 Sol &#x2F; Terra &#x2F; Luna</td><td>하나의 범용 모델보다 작업별 모델 라인업과 제한 프리뷰 운영이 중요해진다.</td><td><code>limited preview</code></td></tr><tr><td>Anthropic Claude Mythos 5 접근 복원 메모</td><td>강력한 AI 접근이 국가안보, 핵심 인프라, 신뢰 조직 기준으로 관리되는 흐름을 보여준다.</td><td><code>restore access</code></td></tr><tr><td>Google DeepMind Gemini computer use</td><td>AI가 단순 답변을 넘어 화면을 보고 조작하는 agentic workflow로 이동한다.</td><td><code>computer use</code></td></tr></tbody></table><h2 id="왜-중요한가"><a href="#왜-중요한가" class="headerlink" title="왜 중요한가"></a>왜 중요한가</h2><p>첫 번째 흐름은 OpenAI가 GPT-5.6 계열을 Sol, Terra, Luna처럼 용도별로 나누어 제시했다는 점입니다. 입력 메모 기준으로 Sol은 최상위 모델, Terra는 균형형, Luna는 빠르고 저렴한 모델로 구분됩니다. 중요한 변화는 “가장 센 모델 하나”보다 <strong>작업, 비용, 속도, 안전 요구에 따라 모델을 고르는 제품 구조</strong>가 더 중요해진다는 점입니다.</p><p>두 번째 흐름은 Anthropic Mythos 5 접근 복원 메모입니다. 이 항목은 사용자 제공 메모 기준으로 <code>Partially confirmed</code>로 다룹니다. 핵심은 특정 모델명 자체보다, 최첨단 AI 접근이 국가안보와 핵심 인프라 맥락에서 허용과 차단을 오가며 관리될 수 있다는 점입니다. 기업과 정부가 “누구에게, 어떤 조건으로, 어떤 용도까지 허용할 것인가”를 함께 조정하는 시대가 더 분명해지고 있습니다.</p><p>세 번째 흐름은 Google DeepMind의 Gemini computer use입니다. <code>computer use</code>는 AI가 화면을 인식하고, 클릭하고, 입력하고, 스크롤하는 작업 흐름을 뜻합니다. 개발자에게는 단순 챗봇보다 더 직접적인 변화입니다. 코드 수정, 데이터 정리, 웹 조사, 문서 작성 같은 반복 업무에서 AI가 실제 인터페이스를 다루는 방향으로 이동하기 때문입니다.</p><p>세 뉴스를 한 줄로 묶으면 이렇습니다. <strong>모델은 더 세분화되고, 접근은 더 통제되며, AI는 점점 더 직접 실행하는 도구가 됩니다.</strong></p><h2 id="오늘의-영어-메모"><a href="#오늘의-영어-메모" class="headerlink" title="오늘의 영어 메모"></a>오늘의 영어 메모</h2><ul><li><code>limited preview</code>: 신뢰할 수 있는 파트너나 일부 사용자에게 먼저 여는 제한 프리뷰입니다.</li><li><code>flagship model</code>: 제품군에서 가장 대표적이고 성능이 높은 최상위 모델을 뜻합니다.</li><li><code>in the coming weeks</code>: 정확한 날짜를 못 박지 않고 “앞으로 몇 주 안에”라고 말할 때 씁니다.</li><li><code>restore access</code>: 차단되었거나 중단된 접근 권한을 다시 허용한다는 표현입니다.</li><li><code>redeploy</code>: 중단되었던 시스템이나 모델을 제한 조건 아래 다시 배포한다는 의미로 쓸 수 있습니다.</li><li><code>computer use</code>: AI가 브라우저나 앱 화면을 보고 마우스와 키보드를 조작하는 기능입니다.</li><li><code>agentic AI</code>: 답변만 하는 AI가 아니라 목표를 세우고 실행까지 이어가는 자율 행동형 AI를 가리킵니다.</li></ul><h2 id="개발자-관점의-의미"><a href="#개발자-관점의-의미" class="headerlink" title="개발자 관점의 의미"></a>개발자 관점의 의미</h2><p>개발자에게 이번 브리핑은 AI 제품을 보는 기준이 바뀌고 있음을 알려줍니다. 앞으로는 “어떤 모델이 제일 똑똑한가”만 묻기 어렵습니다. 작업별로 다른 모델을 고르고, 조직별 접근 권한을 관리하고, 실제 UI를 조작하는 에이전트가 어디까지 책임질 수 있는지 따져야 합니다.</p><p>특히 <code>computer use</code>는 자동화의 경계를 바꿉니다. API가 없는 오래된 도구, 내부 웹 시스템, 반복 입력 화면도 AI가 다룰 수 있는 작업 후보가 됩니다. 대신 보안, 감사 로그, 권한 분리, 실패 복구가 함께 설계되어야 합니다.</p><h2 id="미니-연습"><a href="#미니-연습" class="headerlink" title="미니 연습"></a>미니 연습</h2><ol><li><p>빈칸 채우기<br>OpenAI started with a _____ preview of GPT-5.6.<br>정답: <code>limited</code></p></li><li><p>한국어를 영어로<br>“미국 정부가 핵심 기관에만 Mythos 5 접근을 복원했습니다.”<br>모범 답안: <code>The US government allowed restoration of access to Mythos 5 for critical infrastructure organizations.</code></p></li><li><p>말하기 연습<br><code>OpenAI just dropped GPT-5.6 Sol as their new flagship in limited preview. At the same time, Google introduced computer use in Gemini, making AI truly agentic.</code></p></li></ol><h2 id="출처와-신뢰도"><a href="#출처와-신뢰도" class="headerlink" title="출처와 신뢰도"></a>출처와 신뢰도</h2><p>이번 글은 사용자 제공 브리핑 이미지와 원문 메모를 바탕으로 작성했습니다. 공개 포스트에서는 확인 상태를 나누었습니다.</p><ul><li>OpenAI GPT-5.6 Sol &#x2F; Terra &#x2F; Luna: 사용자 입력의 공식 OpenAI 발표와 <code>@OpenAI</code> 메모를 기준으로 정리했습니다.</li><li>Anthropic Claude Mythos 5 접근 복원: 사용자 입력 기준으로는 <code>Partially confirmed</code>입니다. 세부 조건은 공식 링크 확인이 더 필요하므로 본문에서도 부분 확인으로 표시했습니다.</li><li>Google DeepMind Gemini computer use: 사용자 입력의 DeepMind 모델 페이지 기준으로 정리했습니다.</li><li>X 반응 문구: <code>model alone is no longer the product</code>, <code>agentic era is here</code> 등은 관찰 메모로만 다루며 대표 여론처럼 일반화하지 않았습니다.</li></ul><p>자료:</p><ul><li><a href="https://openai.com/index/previewing-gpt-5-6-sol/">OpenAI: Previewing GPT-5.6 Sol</a></li><li><a href="https://www.anthropic.com/news">Anthropic</a></li><li><a href="https://deepmind.google/models/">Google DeepMind: Models</a></li></ul>]]>
    </content>
    <id>https://reasonofmoon.github.io/2026/06/29/ai-news-2026-06-29/</id>
    <link href="https://reasonofmoon.github.io/2026/06/29/ai-news-2026-06-29/"/>
    <link href="https://reasonofmoon.github.io/images/ai-news/2026-06-29.png" rel="enclosure"/>
    <published>2026-06-28T23:12:04.000Z</published>
    <summary>OpenAI GPT-5.6 3종 모델, Anthropic Mythos 5 접근 복원 메모, Gemini computer use를 오늘의 AI 뉴스로 정리했습니다.</summary>
    <title>AI 데일리 브리핑 2026.06.29</title>
    <updated>2026-06-28T23:30:12.139Z</updated>
  </entry>
  <entry>
    <author>
      <name>Reasonofmoon</name>
    </author>
    <category term="YouTube Lab" scheme="https://reasonofmoon.github.io/categories/YouTube-Lab/"/>
    <category term="Agentic Engineering" scheme="https://reasonofmoon.github.io/tags/Agentic-Engineering/"/>
    <category term="AI" scheme="https://reasonofmoon.github.io/tags/AI/"/>
    <category term="Loop Engineering" scheme="https://reasonofmoon.github.io/tags/Loop-Engineering/"/>
    <category term="YouTube" scheme="https://reasonofmoon.github.io/tags/YouTube/"/>
    <category term="Video Notes" scheme="https://reasonofmoon.github.io/tags/Video-Notes/"/>
    <category term="Product Management" scheme="https://reasonofmoon.github.io/tags/Product-Management/"/>
    <category term="Framework" scheme="https://reasonofmoon.github.io/tags/Framework/"/>
    <content>
      <![CDATA[<p>유명 프로덕트 팟캐스트 Lenny’s Podcast의 게스트로 출연한 징가(Zynga) 창업자 <strong>마크 핀커스(Mark Pincus)</strong>의 세션 <strong>&ldquo;성공하는 제품 뒤에 숨겨진 패턴&rdquo;</strong>을 정리하고 분석한 비디오 노트입니다. 글로벌 메가 히트작인 팜빌(FarmVille)과 Words with Friends를 일궈낸 경험을 바탕으로, 검증된 사용자 경험 위에 혁신을 가미하는 PBN 프레임워크와 AI 시대의 애자일 제품 개발 지침을 다룹니다.</p><hr><h2 id="1-Proven-Better-New-PBN-프레임워크의-개요"><a href="#1-Proven-Better-New-PBN-프레임워크의-개요" class="headerlink" title="1. Proven Better New (PBN) 프레임워크의 개요"></a>1. Proven Better New (PBN) 프레임워크의 개요</h2><iframe width="560" height="315" src="https://www.youtube-nocookie.com/embed/7eh9C3TUotc?start=166&amp;end=449&amp;rel=0" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe><div class="obsidian-callout obsidian-callout--quote" data-callout="quote">  <div class="obsidian-callout__title">    <span class="obsidian-callout__icon" aria-hidden="true">“</span>    <strong>자막 근거 · 02:46</strong>  </div>  <div class="obsidian-callout__body"><p>이것은 저희 징가(Zynga)에서 초기에 정립되어 마치 종교처럼 확립된 핵심 원칙입니다. ‘Proven Better New’ 프레임워크는 인간의 직관이 95% 맞고 우리의 아이디어는 75% 틀리다는 철학에서 출발합니다. 여러분이 가진 혁신 영역을 분리하고, 이미 시장에서 검증된(Proven) 핵심 경험을 완벽히 마스터한 뒤, 10명 중 10명이 극찬할 수 있도록 더 나은(Better) 증분 개선을 더하고, 사용자들을 매료할 단 하나의 새로운(New) 요소를 가미해 실패 확률을 낮추는 것입니다.</p></div></div><h3 id="해석"><a href="#해석" class="headerlink" title="해석"></a>해석</h3><p>마크 핀커스가 징가를 창업한 이래 가장 강력한 근간으로 고수한 <strong>PBN(Proven Better New) 프레임워크</strong>는 제품의 성공 가능성을 수학적으로 높이는 방법론입니다.</p><ul><li><strong>Proven (검증된 것)</strong>: 타겟 플랫폼에서 이미 시장 성숙도와 사용자 충성도가 검증된 핵심 메커니즘을 말합니다. 혁신가가 되겠다는 개발자의 자존심을 내려놓고, 철저하게 검증된 패턴을 정교하게 분석 및 모방하는 것에서 제품 설계를 시작해야 합니다.</li><li><strong>Better (더 나은 것)</strong>: 단순히 약간의 개선에 머무르는 것이 아니라, 기존 서비스를 이용하던 충성 고객 10명 중 10명이 입을 모아 훨씬 더 유려하고 편리하다고 동의할 수 있는 수준의 디자인과 사용성을 깎아내는 일입니다.</li><li><strong>New (새로운 것)</strong>: 사용자가 이 제품을 새로 다운로드하고 설치하여 시도해야 할 단 하나의 매력적이고 독창적인 이유입니다 (예: 기존 턴제 스펠링 게임에 페이스북 소셜 그래프를 얹어 친구들과 실시간 소통을 가미한 Words with Friends).</li></ul><p>프레임워크의 핵심은 <strong>&ldquo;검증되지 않은 여러 개의 아이디어를 한꺼번에 제품에 집어넣지 말라&rdquo;</strong>는 것입니다. 혁신의 범위를 제품의 단 한 곳(New)으로만 좁히고, 나머지 기본 뼈대는 철저하게 검증된 규칙(Proven) 위에 안착시킴으로써 제품 설계의 복잡성을 방지합니다.</p><hr><h2 id="2-야망을-내려놓는-겸손함과-Bolt-new-사례"><a href="#2-야망을-내려놓는-겸손함과-Bolt-new-사례" class="headerlink" title="2. 야망을 내려놓는 겸손함과 Bolt.new 사례"></a>2. 야망을 내려놓는 겸손함과 Bolt.new 사례</h2><iframe width="560" height="315" src="https://www.youtube-nocookie.com/embed/7eh9C3TUotc?start=1448&amp;end=1995&amp;rel=0" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe><div class="obsidian-callout obsidian-callout--quote" data-callout="quote">  <div class="obsidian-callout__title">    <span class="obsidian-callout__icon" aria-hidden="true">“</span>    <strong>자막 근거 · 24:08</strong>  </div>  <div class="obsidian-callout__body"><p>처음부터 너무 야심차고 비전 있는 제품을 만들려고 하면 제품-시장 적합성(PMF)을 놓치기 십상입니다. 작고 소박한 출발점에서 시작해야 합니다. 수많은 대히트 상품이나 프랜차이즈들이 처음에는 아주 사소하고 야심 없는 곳에서 시작했습니다. 페이스북 역시 하버드 여학생&#x2F;남학생 평가 앱에 불과했고, 징가의 시작도 단순한 포커 게임이었습니다.</p></div></div><h3 id="해석-1"><a href="#해석-1" class="headerlink" title="해석"></a>해석</h3><p>많은 연쇄 창업가들이 이전의 성공 경험에 취해 다음 프로젝트를 시작할 때 지나치게 거대한 비전(10만 피트 상공의 비전)과 큰 투자금을 안고 출발하려 합니다. 그러나 마크 핀커스는 이러한 <strong>과도한 야망(Over-ambition)</strong>이야말로 제품이 PMF를 잃고 침몰하게 만드는 가장 큰 적이라고 경고합니다.</p><p>위대한 혁신은 아주 작고 미미한 고도(1,000피트)의 구체적인 문제 해결로부터 싹틉니다. 대표적인 최신 사례가 웹 브라우저 기반 코딩 환경인 <strong>Bolt.new (StackBlitz)</strong>입니다. 그들은 웹 브라우저 내에서 가상 개발 환경(WebContainers)을 돌리는 기술 영역을 오랫동안 묵묵히 깎아 나가다가, 적절한 시점에 AI 에이전트를 결합하여 순식간에 프로토타이핑을 해내는 메가 히트 서비스를 만들어냈습니다.</p><p>성공을 이루기 전까지 철저하게 겸손한 태도로 가장 구체적인 고객 병목 하나에 몰입하고, 이력서나 평판 대신 <strong>소비자가 느끼는 실제 가치</strong>에 집요하게 집중하는 것이 생존의 공식입니다.</p><hr><h2 id="3-근거-없는-희망을-죽이고-AI를-‘실패-기계’로-쓰기"><a href="#3-근거-없는-희망을-죽이고-AI를-‘실패-기계’로-쓰기" class="headerlink" title="3. 근거 없는 희망을 죽이고 AI를 ‘실패 기계’로 쓰기"></a>3. 근거 없는 희망을 죽이고 AI를 ‘실패 기계’로 쓰기</h2><iframe width="560" height="315" src="https://www.youtube-nocookie.com/embed/7eh9C3TUotc?start=1995&amp;end=2408&amp;rel=0" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe><div class="obsidian-callout obsidian-callout--quote" data-callout="quote">  <div class="obsidian-callout__title">    <span class="obsidian-callout__icon" aria-hidden="true">“</span>    <strong>자막 근거 · 33:15</strong>  </div>  <div class="obsidian-callout__body"><p>희망이 당신을 죽이기 전에 먼저 희망을 죽이십시오. 희망은 근거 없는 확신이나 막연한 기도에 불과합니다. 많은 창업자와 제품 팀들이 다음 번 릴리스에서는 마법처럼 성공할 거라는 막연한 희망만 갖고 MVP 수준에 머물러 있습니다. AI가 가져온 미래는 제품 개발을 빠르게 해주는 편리함에 그쳐서는 안 되며, 하루에 100개의 아이디어를 끊임없이 분석하고 폐기하는 ‘실패 기계(Failure Machine)’로 사용되어야 합니다.</p></div></div><h3 id="해석-2"><a href="#해석-2" class="headerlink" title="해석"></a>해석</h3><p>마크 핀커스는 <strong>&ldquo;Kill hope before hope kills you (희망이 너를 죽이기 전에 희망을 죽여라)&rdquo;</strong>라는 강력한 경구를 던집니다. 여기서 말하는 희망은 실제 데이터나 사용자의 검증 루프에 기반하지 않은 채, 막연히 “다음 업데이트가 배포되면 잘 풀릴 거야”라며 매몰 비용을 고집하는 어리석은 기도를 뜻합니다.</p><p>오늘날 AI의 등장은 프로덕트 엔지니어링 생태계를 완전히 바꾸어 놓았습니다. AI의 진정한 가치는 3년이 걸리던 MVP 빌드 기간을 3개월로 단축시켜 편하게 안주하게 해주는 마약이 아닙니다. 오히려 <strong>&ldquo;하루에 100가지 아이디어를 실행하여 빠르게 실패를 도출하는 실패 기계(Failure Machine)&rdquo;</strong>로 작동해야 합니다.</p><p>실패 데이터를 수동으로 3개월에 한 번씩 수집하던 느린 루프를 허물고, AI 에이전트를 결합하여 하루에 수십 번씩 비즈니스 가설을 테스트하여 탈락(Discard)시키는 <strong>초고속 실패 피드백 루프</strong>를 구축해야 합니다. 진짜 올바른 신호(Signal)를 획득하기 전까지, 잘못된 가설을 극도로 빠른 속도로 솎아내는 데 AI 에이전틱 리소스를 집중 배치해야 합니다.</p><hr><h2 id="내-생각"><a href="#내-생각" class="headerlink" title="내 생각"></a>내 생각</h2><p>마크 핀커스의 PBN 프레임워크와 실패 기계 철학은 필자가 그동안 추구해온 <strong>루프 엔지니어링(Loop Engineering)</strong>의 방향성을 극명히 시사해 줍니다.</p><p>첫째, <strong>&ldquo;AI 에이전트를 단순히 더 빠른 코드 작성기가 아닌, 테스트 러너(Test Runner)로 재정의해야 한다&rdquo;</strong>는 점입니다. 많은 에이전틱 시도가 화려한 코드 생성 데모에 머무는 우를 범합니다. 에이전트가 진짜 해야 할 일은 우리가 세운 비즈니스 가설과 기능적 스펙을 <strong>극단적으로 좁은 컨텍스트 안에서 고속으로 컴파일하고 검증해 내는 것</strong>입니다. 코드를 많이 짜는 것이 아니라, 실패해야 할 코드를 1초 만에 확인하고 격리시키는 인프라를 가꾸는 것이 엔지니어의 참된 하네스(Harness) 빌드 능력입니다.</p><p>둘째, <strong>겸손한 Bounded Context의 가치</strong>입니다. 10만 피트 상공의 거창한 메타 아키텍처를 AI 에이전트에게 몽땅 쥐어주면, 컨텍스트 용량이 가득 차며 혼동과 에러를 남발하게 됩니다. 1,000피트 상공의 구체적이고 좁은 문제(예: 특정 API의 실패 핸들링, 타겟 유저 온보딩 등)로 바운디드 컨텍스트를 쪼개고, 그 안에서 완벽히 통제된 도구(Proven Tool)를 작동시키는 것이 AI 시대 프로덕트 생태계의 살아남는 규격입니다.</p><p>거창한 희망 대신, <strong>&ldquo;작고 구체적으로 쪼갠 작업대 위에 AI라는 초고속 실패 분석 기계를 얹고 점진적으로 깎아나가는 프로세스&rdquo;</strong>만이 실제 동작하는 살아 숨 쉬는 제품을 완성해 내는 유일한 지름길일 것입니다.</p>]]>
    </content>
    <id>https://reasonofmoon.github.io/2026/06/27/video-note-proven-better-new-framework-lennys-podcast/</id>
    <link href="https://reasonofmoon.github.io/2026/06/27/video-note-proven-better-new-framework-lennys-podcast/"/>
    <published>2026-06-27T10:28:00.000Z</published>
    <summary>징가(Zynga) 창업자 마크 핀커스(Mark Pincus)의 인터뷰를 통해 징가의 종교적 핵심 원칙인 'Proven Better New' 프레임워크와 야망을 내려놓는 겸손한 제품 설계, 그리고 AI를 실패 기계(Failure Machine)로 활용하는 애자일 프로토타이핑 공식을 분석합니다.</summary>
    <title>영상으로 읽기: 성공하는 제품 뒤에 숨겨진 패턴 (Mark Pincus) / 260614</title>
    <updated>2026-06-27T10:28:00.000Z</updated>
  </entry>
  <entry>
    <author>
      <name>Reasonofmoon</name>
    </author>
    <category term="Book" scheme="https://reasonofmoon.github.io/categories/Book/"/>
    <category term="독서" scheme="https://reasonofmoon.github.io/tags/%EB%8F%85%EC%84%9C/"/>
    <category term="책노트" scheme="https://reasonofmoon.github.io/tags/%EC%B1%85%EB%85%B8%ED%8A%B8/"/>
    <category term="독서/책노트" scheme="https://reasonofmoon.github.io/tags/%EB%8F%85%EC%84%9C-%EC%B1%85%EB%85%B8%ED%8A%B8/"/>
    <category term="Book Notes" scheme="https://reasonofmoon.github.io/tags/Book-Notes/"/>
    <category term="Philosophy" scheme="https://reasonofmoon.github.io/tags/Philosophy/"/>
    <category term="A Thousand Plateaus" scheme="https://reasonofmoon.github.io/tags/A-Thousand-Plateaus/"/>
    <category term="Deleuze" scheme="https://reasonofmoon.github.io/tags/Deleuze/"/>
    <category term="Guattari" scheme="https://reasonofmoon.github.io/tags/Guattari/"/>
    <category term="Rhizome" scheme="https://reasonofmoon.github.io/tags/Rhizome/"/>
    <content>
      <![CDATA[<h1 id="책노트-A-Thousand-Plateaus-Reader’s-Guide-1-1-두-사람이-함께-철학을-만든-이유"><a href="#책노트-A-Thousand-Plateaus-Reader’s-Guide-1-1-두-사람이-함께-철학을-만든-이유" class="headerlink" title="책노트: A Thousand Plateaus Reader’s Guide 1-1 - 두 사람이 함께 철학을 만든 이유"></a>책노트: A Thousand Plateaus Reader’s Guide 1-1 - 두 사람이 함께 철학을 만든 이유</h1><div class="obsidian-callout obsidian-callout--abstract" data-callout="abstract">  <div class="obsidian-callout__title">    <span class="obsidian-callout__icon" aria-hidden="true">■</span>    <strong>이 노트의 사용법</strong>  </div>  <div class="obsidian-callout__body"><p>포착 -&gt; 증류 -&gt; 연결 -&gt; 표현 4단계 깔때기로 한 권을 흘려보냅니다.핵심 원칙: 책 노트는 창고, 인사이트 카드는 화폐.</p></div></div><h2 id="L0-·-서지-진입"><a href="#L0-·-서지-진입" class="headerlink" title="L0 · 서지 &amp; 진입"></a>L0 · 서지 &amp; 진입</h2><ul><li><strong>대상 책</strong>: Deleuze and Guattari’s A Thousand Plateaus: A Reader’s Guide</li><li><strong>저자</strong>: Eugene W. Holland</li><li><strong>이번 범위</strong>: Chapter 1, Section 1-1 · A Thousand Plateaus in Context</li><li><strong>핵심 질문</strong>: 왜 이 책은 한 사람의 체계가 아니라 두 사람의 접속으로 시작해야 하는가?</li><li><strong>한 문장 핵심</strong>: 이 책의 첫 단서는 협업이다. 들뢰즈와 가타리는 각자의 전문성을 합쳐 하나의 완성된 이론을 만든 것이 아니라, 서로의 결핍과 과잉을 접속시켜 새로운 사유 기계를 만들었다.</li></ul><div class="obsidian-callout obsidian-callout--note" data-callout="note">  <div class="obsidian-callout__title">    <span class="obsidian-callout__icon" aria-hidden="true">■</span>    <strong>저작권 처리</strong>  </div>  <div class="obsidian-callout__body"><p>이 글은 원문을 길게 옮기지 않고, 핵심 개념을 한국어 해설과 적용 질문으로 재구성한 변형적 책노트입니다.</p></div></div><h2 id="L1-·-발췌함-대신-개념-단서"><a href="#L1-·-발췌함-대신-개념-단서" class="headerlink" title="L1 · 발췌함 대신 개념 단서"></a>L1 · 발췌함 대신 개념 단서</h2><ul><li><strong>개념 단서</strong>: 협업은 합의가 아니라 생산적 불일치다</li><li><strong>맥락 단서</strong>: 어려운 책은 체계보다 접속 방식부터 읽는다</li><li><strong>적용 단서</strong>: 사유의 주어를 개인에서 장치로 옮긴다</li></ul><h2 id="L2-·-챕터-지도"><a href="#L2-·-챕터-지도" class="headerlink" title="L2 · 챕터 지도"></a>L2 · 챕터 지도</h2><p>홀랜드는 『천 개의 고원』을 단독 저자의 사상 체계로 접근하지 않는다. 먼저 들뢰즈와 가타리가 어떤 배경에서 만났는지를 보여준다. 들뢰즈는 서양철학의 깊은 계보를 다루는 철학자였고, 가타리는 정신분석, 라 보르드 클리닉, 정치운동의 현장에서 움직이던 실천가였다.</p><p>이 조합은 중요하다. 한쪽은 개념의 긴 역사를 알고 있었고, 다른 한쪽은 제도와 욕망이 실제 인간을 어떻게 움직이는지 보고 있었다. 그래서 이들의 작업은 추상 이론과 현장 감각이 충돌하며 생긴다.</p><p>읽는 사람에게 필요한 태도도 여기서 나온다. 이 책은 정답을 찾는 교과서가 아니라, 서로 다른 장면을 연결해 보는 실험실이다. 처음부터 모든 개념을 완벽히 이해하려 하면 막힌다. 대신 “이 개념은 어디와 어디를 연결하는가?”라고 물어야 한다.</p><h2 id="L3-·-인사이트-카드"><a href="#L3-·-인사이트-카드" class="headerlink" title="L3 · 인사이트 카드"></a>L3 · 인사이트 카드</h2><ul><li>A Thousand Plateaus - I1.1 협업은 합의가 아니라 생산적 불일치다</li><li>A Thousand Plateaus - I1.2 어려운 책은 체계보다 접속 방식부터 읽는다</li><li>A Thousand Plateaus - I1.3 사유의 주어를 개인에서 장치로 옮긴다</li></ul><h2 id="L4-·-생산-보드"><a href="#L4-·-생산-보드" class="headerlink" title="L4 · 생산 보드"></a>L4 · 생산 보드</h2><div class="obsidian-callout obsidian-callout--todo" data-callout="todo">  <div class="obsidian-callout__title">    <span class="obsidian-callout__icon" aria-hidden="true">■</span>    <strong>오늘 적용할 실험</strong>  </div>  <div class="obsidian-callout__body"><p><ul><li><input disabled="" type="checkbox"> 개념을 한 문장 정의로 고정하지 말고, 연결되는 분야를 세 개 적는다.</li><li><input disabled="" type="checkbox"> 저자 약력을 정보가 아니라 사유의 입력 조건으로 읽는다.</li><li><input disabled="" type="checkbox"> 철학 개념을 삶, 제도, 예술 중 하나의 사례에 붙여 본다.</li></ul></div></div><h2 id="L5-·-연결-복습"><a href="#L5-·-연결-복습" class="headerlink" title="L5 · 연결 &amp; 복습"></a>L5 · 연결 &amp; 복습</h2><ul><li><strong>연결 개념</strong>: 리좀, 탈영토화, 배치, 차이와 반복</li><li><strong>복습 질문</strong>:<ul><li>이 섹션의 개념을 개인 심리 문제가 아니라 관계와 배치의 문제로 다시 설명하면 어떻게 달라지는가?</li><li>오늘 읽은 개념은 기존의 상식적 분류를 어디에서 흔드는가?</li><li>이 개념을 내 글쓰기, 수업, 프로젝트 설계에 적용하면 무엇을 다르게 보게 되는가?</li></ul></li></ul><p><strong>한 문장 최종 정리</strong>: 이 책의 첫 단서는 협업이다. 들뢰즈와 가타리는 각자의 전문성을 합쳐 하나의 완성된 이론을 만든 것이 아니라, 서로의 결핍과 과잉을 접속시켜 새로운 사유 기계를 만들었다.</p>]]>
    </content>
    <id>https://reasonofmoon.github.io/2026/06/27/book-note-thousand-plateaus-reader-guide-ch1-sec01-collaboration/</id>
    <link href="https://reasonofmoon.github.io/2026/06/27/book-note-thousand-plateaus-reader-guide-ch1-sec01-collaboration/"/>
    <published>2026-06-27T05:58:00.000Z</published>
    <summary>들뢰즈와 가타리의 협업을 출발점으로, 어려운 철학책을 한 명의 저자가 아니라 하나의 사유 장치로 읽는 법을 정리합니다.</summary>
    <title>책노트: A Thousand Plateaus Reader's Guide 1-1 - 두 사람이 함께 철학을 만든 이유</title>
    <updated>2026-06-27T05:58:00.000Z</updated>
  </entry>
  <entry>
    <author>
      <name>Reasonofmoon</name>
    </author>
    <category term="Book" scheme="https://reasonofmoon.github.io/categories/Book/"/>
    <category term="독서" scheme="https://reasonofmoon.github.io/tags/%EB%8F%85%EC%84%9C/"/>
    <category term="책노트" scheme="https://reasonofmoon.github.io/tags/%EC%B1%85%EB%85%B8%ED%8A%B8/"/>
    <category term="독서/책노트" scheme="https://reasonofmoon.github.io/tags/%EB%8F%85%EC%84%9C-%EC%B1%85%EB%85%B8%ED%8A%B8/"/>
    <category term="Book Notes" scheme="https://reasonofmoon.github.io/tags/Book-Notes/"/>
    <category term="Philosophy" scheme="https://reasonofmoon.github.io/tags/Philosophy/"/>
    <category term="A Thousand Plateaus" scheme="https://reasonofmoon.github.io/tags/A-Thousand-Plateaus/"/>
    <category term="Deleuze" scheme="https://reasonofmoon.github.io/tags/Deleuze/"/>
    <category term="Guattari" scheme="https://reasonofmoon.github.io/tags/Guattari/"/>
    <category term="Rhizome" scheme="https://reasonofmoon.github.io/tags/Rhizome/"/>
    <content>
      <![CDATA[<h1 id="책노트-A-Thousand-Plateaus-Reader’s-Guide-1-3-가타리-클리닉과-정치-현장에서-온-사상가"><a href="#책노트-A-Thousand-Plateaus-Reader’s-Guide-1-3-가타리-클리닉과-정치-현장에서-온-사상가" class="headerlink" title="책노트: A Thousand Plateaus Reader’s Guide 1-3 - 가타리, 클리닉과 정치 현장에서 온 사상가"></a>책노트: A Thousand Plateaus Reader’s Guide 1-3 - 가타리, 클리닉과 정치 현장에서 온 사상가</h1><div class="obsidian-callout obsidian-callout--abstract" data-callout="abstract">  <div class="obsidian-callout__title">    <span class="obsidian-callout__icon" aria-hidden="true">■</span>    <strong>이 노트의 사용법</strong>  </div>  <div class="obsidian-callout__body"><p>포착 -&gt; 증류 -&gt; 연결 -&gt; 표현 4단계 깔때기로 한 권을 흘려보냅니다.핵심 원칙: 책 노트는 창고, 인사이트 카드는 화폐.</p></div></div><h2 id="L0-·-서지-진입"><a href="#L0-·-서지-진입" class="headerlink" title="L0 · 서지 &amp; 진입"></a>L0 · 서지 &amp; 진입</h2><ul><li><strong>대상 책</strong>: Deleuze and Guattari’s A Thousand Plateaus: A Reader’s Guide</li><li><strong>저자</strong>: Eugene W. Holland</li><li><strong>이번 범위</strong>: Chapter 1, Section 1-3 · A Thousand Plateaus in Context</li><li><strong>핵심 질문</strong>: 가타리는 들뢰즈의 철학에 어떤 현실의 압력을 가져왔는가?</li><li><strong>한 문장 핵심</strong>: 가타리는 철학 바깥의 현장을 가져온다. 정신병원, 정치운동, 제도 비판의 경험은 욕망을 개인 심리 안에 가두지 않고 사회적 배치 속에서 보게 만든다.</li></ul><div class="obsidian-callout obsidian-callout--note" data-callout="note">  <div class="obsidian-callout__title">    <span class="obsidian-callout__icon" aria-hidden="true">■</span>    <strong>저작권 처리</strong>  </div>  <div class="obsidian-callout__body"><p>이 글은 원문을 길게 옮기지 않고, 핵심 개념을 한국어 해설과 적용 질문으로 재구성한 변형적 책노트입니다.</p></div></div><h2 id="L1-·-발췌함-대신-개념-단서"><a href="#L1-·-발췌함-대신-개념-단서" class="headerlink" title="L1 · 발췌함 대신 개념 단서"></a>L1 · 발췌함 대신 개념 단서</h2><ul><li><strong>개념 단서</strong>: 문제는 개인 안에만 있지 않고 배치 속에 있다</li><li><strong>맥락 단서</strong>: 욕망은 해석 대상이 아니라 생산하는 힘이다</li><li><strong>적용 단서</strong>: 현장이 개념을 거칠게 만들 때 철학은 살아난다</li></ul><h2 id="L2-·-챕터-지도"><a href="#L2-·-챕터-지도" class="headerlink" title="L2 · 챕터 지도"></a>L2 · 챕터 지도</h2><p>가타리는 단순히 들뢰즈의 보조자가 아니다. 그는 라캉의 정신분석을 배웠지만 그 궤도에서 벗어났고, 라 보르드 클리닉에서 제도와 치료의 관계를 실험했다. 이 배경이 『안티 오이디푸스』와 『천 개의 고원』의 실천적 날을 만든다.</p><p>중요한 전환은 무의식을 개인의 가족 드라마로만 보지 않는 것이다. 가타리에게 욕망은 제도, 노동, 권력, 언어, 공간과 엮인다. 그래서 치료는 개인 내부를 해석하는 일에 그치지 않고, 개인을 둘러싼 배치를 바꾸는 문제로 확장된다.</p><p>이 관점은 조직과 학습에도 유용하다. 어떤 사람이 계속 같은 문제를 반복할 때, 그 사람의 성격만 볼 것이 아니라 그를 둘러싼 규칙, 공간, 역할, 보상 체계를 함께 봐야 한다.</p><h2 id="L3-·-인사이트-카드"><a href="#L3-·-인사이트-카드" class="headerlink" title="L3 · 인사이트 카드"></a>L3 · 인사이트 카드</h2><ul><li>A Thousand Plateaus - I3.1 문제는 개인 안에만 있지 않고 배치 속에 있다</li><li>A Thousand Plateaus - I3.2 욕망은 해석 대상이 아니라 생산하는 힘이다</li><li>A Thousand Plateaus - I3.3 현장이 개념을 거칠게 만들 때 철학은 살아난다</li></ul><h2 id="L4-·-생산-보드"><a href="#L4-·-생산-보드" class="headerlink" title="L4 · 생산 보드"></a>L4 · 생산 보드</h2><div class="obsidian-callout obsidian-callout--todo" data-callout="todo">  <div class="obsidian-callout__title">    <span class="obsidian-callout__icon" aria-hidden="true">■</span>    <strong>오늘 적용할 실험</strong>  </div>  <div class="obsidian-callout__body"><p><ul><li><input disabled="" type="checkbox"> 개인의 문제처럼 보이는 현상에서 제도적 조건 세 가지를 찾는다.</li><li><input disabled="" type="checkbox"> 반복되는 실패를 성격 문제가 아니라 배치 문제로 다시 설명한다.</li><li><input disabled="" type="checkbox"> 치료, 교육, 조직 운영을 “관계 재배치” 관점으로 읽는다.</li></ul></div></div><h2 id="L5-·-연결-복습"><a href="#L5-·-연결-복습" class="headerlink" title="L5 · 연결 &amp; 복습"></a>L5 · 연결 &amp; 복습</h2><ul><li><strong>연결 개념</strong>: 리좀, 탈영토화, 배치, 차이와 반복</li><li><strong>복습 질문</strong>:<ul><li>이 섹션의 개념을 개인 심리 문제가 아니라 관계와 배치의 문제로 다시 설명하면 어떻게 달라지는가?</li><li>오늘 읽은 개념은 기존의 상식적 분류를 어디에서 흔드는가?</li><li>이 개념을 내 글쓰기, 수업, 프로젝트 설계에 적용하면 무엇을 다르게 보게 되는가?</li></ul></li></ul><p><strong>한 문장 최종 정리</strong>: 가타리는 철학 바깥의 현장을 가져온다. 정신병원, 정치운동, 제도 비판의 경험은 욕망을 개인 심리 안에 가두지 않고 사회적 배치 속에서 보게 만든다.</p>]]>
    </content>
    <id>https://reasonofmoon.github.io/2026/06/27/book-note-thousand-plateaus-reader-guide-ch1-sec03-guattari/</id>
    <link href="https://reasonofmoon.github.io/2026/06/27/book-note-thousand-plateaus-reader-guide-ch1-sec03-guattari/"/>
    <published>2026-06-27T05:58:00.000Z</published>
    <summary>가타리의 정신분석 비판, 라 보르드 클리닉, 정치적 실천이 들뢰즈와의 협업에서 어떤 역할을 하는지 정리합니다.</summary>
    <title>책노트: A Thousand Plateaus Reader's Guide 1-3 - 가타리, 클리닉과 정치 현장에서 온 사상가</title>
    <updated>2026-06-27T05:58:00.000Z</updated>
  </entry>
  <entry>
    <author>
      <name>Reasonofmoon</name>
    </author>
    <category term="Book" scheme="https://reasonofmoon.github.io/categories/Book/"/>
    <category term="독서" scheme="https://reasonofmoon.github.io/tags/%EB%8F%85%EC%84%9C/"/>
    <category term="책노트" scheme="https://reasonofmoon.github.io/tags/%EC%B1%85%EB%85%B8%ED%8A%B8/"/>
    <category term="독서/책노트" scheme="https://reasonofmoon.github.io/tags/%EB%8F%85%EC%84%9C-%EC%B1%85%EB%85%B8%ED%8A%B8/"/>
    <category term="Book Notes" scheme="https://reasonofmoon.github.io/tags/Book-Notes/"/>
    <category term="Philosophy" scheme="https://reasonofmoon.github.io/tags/Philosophy/"/>
    <category term="A Thousand Plateaus" scheme="https://reasonofmoon.github.io/tags/A-Thousand-Plateaus/"/>
    <category term="Deleuze" scheme="https://reasonofmoon.github.io/tags/Deleuze/"/>
    <category term="Guattari" scheme="https://reasonofmoon.github.io/tags/Guattari/"/>
    <category term="Rhizome" scheme="https://reasonofmoon.github.io/tags/Rhizome/"/>
    <content>
      <![CDATA[<h1 id="책노트-A-Thousand-Plateaus-Reader’s-Guide-1-2-들뢰즈-동일성보다-차이를-앞세운-철학자"><a href="#책노트-A-Thousand-Plateaus-Reader’s-Guide-1-2-들뢰즈-동일성보다-차이를-앞세운-철학자" class="headerlink" title="책노트: A Thousand Plateaus Reader’s Guide 1-2 - 들뢰즈, 동일성보다 차이를 앞세운 철학자"></a>책노트: A Thousand Plateaus Reader’s Guide 1-2 - 들뢰즈, 동일성보다 차이를 앞세운 철학자</h1><div class="obsidian-callout obsidian-callout--abstract" data-callout="abstract">  <div class="obsidian-callout__title">    <span class="obsidian-callout__icon" aria-hidden="true">■</span>    <strong>이 노트의 사용법</strong>  </div>  <div class="obsidian-callout__body"><p>포착 -&gt; 증류 -&gt; 연결 -&gt; 표현 4단계 깔때기로 한 권을 흘려보냅니다.핵심 원칙: 책 노트는 창고, 인사이트 카드는 화폐.</p></div></div><h2 id="L0-·-서지-진입"><a href="#L0-·-서지-진입" class="headerlink" title="L0 · 서지 &amp; 진입"></a>L0 · 서지 &amp; 진입</h2><ul><li><strong>대상 책</strong>: Deleuze and Guattari’s A Thousand Plateaus: A Reader’s Guide</li><li><strong>저자</strong>: Eugene W. Holland</li><li><strong>이번 범위</strong>: Chapter 1, Section 1-2 · A Thousand Plateaus in Context</li><li><strong>핵심 질문</strong>: 들뢰즈는 왜 존재보다 생성, 동일성보다 차이를 먼저 보려 했는가?</li><li><strong>한 문장 핵심</strong>: 들뢰즈는 철학을 고정된 본질의 해설이 아니라 차이와 생성의 운동을 붙잡는 작업으로 이해했다. 그래서 그는 스피노자, 니체, 베르그손 같은 비주류적 자원을 다시 불러온다.</li></ul><div class="obsidian-callout obsidian-callout--note" data-callout="note">  <div class="obsidian-callout__title">    <span class="obsidian-callout__icon" aria-hidden="true">■</span>    <strong>저작권 처리</strong>  </div>  <div class="obsidian-callout__body"><p>이 글은 원문을 길게 옮기지 않고, 핵심 개념을 한국어 해설과 적용 질문으로 재구성한 변형적 책노트입니다.</p></div></div><h2 id="L1-·-발췌함-대신-개념-단서"><a href="#L1-·-발췌함-대신-개념-단서" class="headerlink" title="L1 · 발췌함 대신 개념 단서"></a>L1 · 발췌함 대신 개념 단서</h2><ul><li><strong>개념 단서</strong>: 차이는 예외가 아니라 사유의 출발점이다</li><li><strong>맥락 단서</strong>: 개념은 분류표가 아니라 변형 가능성의 지도다</li><li><strong>적용 단서</strong>: 비주류 계보는 낡은 문제를 새 각도로 열어 준다</li></ul><h2 id="L2-·-챕터-지도"><a href="#L2-·-챕터-지도" class="headerlink" title="L2 · 챕터 지도"></a>L2 · 챕터 지도</h2><p>홀랜드가 보여주는 들뢰즈의 핵심은 “차이의 철학자”라는 점이다. 그는 어떤 것이 무엇과 같은지를 묻기보다, 무엇이 어떻게 달라지고 있는지를 묻는다. 이것은 정체성 중심의 사고와 다른 출발점이다.</p><p>들뢰즈가 스피노자, 니체, 베르그손에 주목한 것도 이 때문이다. 이들은 세계를 정지된 실체보다 힘, 욕망, 생명, 생성의 관점에서 보게 만든다. 『천 개의 고원』을 읽을 때도 개념을 사전식 정의로 외우면 흐름을 놓친다.</p><p>개발자나 기획자의 사고로 바꾸면, 이것은 “객체가 무엇인가”보다 “시스템이 어떤 변이를 허용하는가”를 묻는 태도와 닮았다. 좋은 개념은 대상을 박제하지 않고 새로운 변형 가능성을 열어 준다.</p><h2 id="L3-·-인사이트-카드"><a href="#L3-·-인사이트-카드" class="headerlink" title="L3 · 인사이트 카드"></a>L3 · 인사이트 카드</h2><ul><li>A Thousand Plateaus - I2.1 차이는 예외가 아니라 사유의 출발점이다</li><li>A Thousand Plateaus - I2.2 개념은 분류표가 아니라 변형 가능성의 지도다</li><li>A Thousand Plateaus - I2.3 비주류 계보는 낡은 문제를 새 각도로 열어 준다</li></ul><h2 id="L4-·-생산-보드"><a href="#L4-·-생산-보드" class="headerlink" title="L4 · 생산 보드"></a>L4 · 생산 보드</h2><div class="obsidian-callout obsidian-callout--todo" data-callout="todo">  <div class="obsidian-callout__title">    <span class="obsidian-callout__icon" aria-hidden="true">■</span>    <strong>오늘 적용할 실험</strong>  </div>  <div class="obsidian-callout__body"><p><ul><li><input disabled="" type="checkbox"> 하나의 개념을 정의하기 전에 그것이 반대하는 상식을 적는다.</li><li><input disabled="" type="checkbox"> 고정된 명사보다 동사형 질문으로 바꾸어 본다.</li><li><input disabled="" type="checkbox"> 동일한 현상이 반복될 때 무엇이 달라졌는지 찾는다.</li></ul></div></div><h2 id="L5-·-연결-복습"><a href="#L5-·-연결-복습" class="headerlink" title="L5 · 연결 &amp; 복습"></a>L5 · 연결 &amp; 복습</h2><ul><li><strong>연결 개념</strong>: 리좀, 탈영토화, 배치, 차이와 반복</li><li><strong>복습 질문</strong>:<ul><li>이 섹션의 개념을 개인 심리 문제가 아니라 관계와 배치의 문제로 다시 설명하면 어떻게 달라지는가?</li><li>오늘 읽은 개념은 기존의 상식적 분류를 어디에서 흔드는가?</li><li>이 개념을 내 글쓰기, 수업, 프로젝트 설계에 적용하면 무엇을 다르게 보게 되는가?</li></ul></li></ul><p><strong>한 문장 최종 정리</strong>: 들뢰즈는 철학을 고정된 본질의 해설이 아니라 차이와 생성의 운동을 붙잡는 작업으로 이해했다. 그래서 그는 스피노자, 니체, 베르그손 같은 비주류적 자원을 다시 불러온다.</p>]]>
    </content>
    <id>https://reasonofmoon.github.io/2026/06/27/book-note-thousand-plateaus-reader-guide-ch1-sec02-deleuze/</id>
    <link href="https://reasonofmoon.github.io/2026/06/27/book-note-thousand-plateaus-reader-guide-ch1-sec02-deleuze/"/>
    <published>2026-06-27T05:58:00.000Z</published>
    <summary>들뢰즈의 철학적 배경을 통해 차이, 생성, 비주류 철학자 읽기가 왜 『천 개의 고원』의 입구가 되는지 정리합니다.</summary>
    <title>책노트: A Thousand Plateaus Reader's Guide 1-2 - 들뢰즈, 동일성보다 차이를 앞세운 철학자</title>
    <updated>2026-06-27T05:58:00.000Z</updated>
  </entry>
  <entry>
    <author>
      <name>Reasonofmoon</name>
    </author>
    <category term="Book" scheme="https://reasonofmoon.github.io/categories/Book/"/>
    <category term="독서" scheme="https://reasonofmoon.github.io/tags/%EB%8F%85%EC%84%9C/"/>
    <category term="책노트" scheme="https://reasonofmoon.github.io/tags/%EC%B1%85%EB%85%B8%ED%8A%B8/"/>
    <category term="독서/책노트" scheme="https://reasonofmoon.github.io/tags/%EB%8F%85%EC%84%9C-%EC%B1%85%EB%85%B8%ED%8A%B8/"/>
    <category term="Book Notes" scheme="https://reasonofmoon.github.io/tags/Book-Notes/"/>
    <category term="Philosophy" scheme="https://reasonofmoon.github.io/tags/Philosophy/"/>
    <category term="A Thousand Plateaus" scheme="https://reasonofmoon.github.io/tags/A-Thousand-Plateaus/"/>
    <category term="Deleuze" scheme="https://reasonofmoon.github.io/tags/Deleuze/"/>
    <category term="Guattari" scheme="https://reasonofmoon.github.io/tags/Guattari/"/>
    <category term="Rhizome" scheme="https://reasonofmoon.github.io/tags/Rhizome/"/>
    <content>
      <![CDATA[<h1 id="책노트-A-Thousand-Plateaus-Reader’s-Guide-1-6-욕망-생산과-탈영토화"><a href="#책노트-A-Thousand-Plateaus-Reader’s-Guide-1-6-욕망-생산과-탈영토화" class="headerlink" title="책노트: A Thousand Plateaus Reader’s Guide 1-6 - 욕망-생산과 탈영토화"></a>책노트: A Thousand Plateaus Reader’s Guide 1-6 - 욕망-생산과 탈영토화</h1><div class="obsidian-callout obsidian-callout--abstract" data-callout="abstract">  <div class="obsidian-callout__title">    <span class="obsidian-callout__icon" aria-hidden="true">■</span>    <strong>이 노트의 사용법</strong>  </div>  <div class="obsidian-callout__body"><p>포착 -&gt; 증류 -&gt; 연결 -&gt; 표현 4단계 깔때기로 한 권을 흘려보냅니다.핵심 원칙: 책 노트는 창고, 인사이트 카드는 화폐.</p></div></div><h2 id="L0-·-서지-진입"><a href="#L0-·-서지-진입" class="headerlink" title="L0 · 서지 &amp; 진입"></a>L0 · 서지 &amp; 진입</h2><ul><li><strong>대상 책</strong>: Deleuze and Guattari’s A Thousand Plateaus: A Reader’s Guide</li><li><strong>저자</strong>: Eugene W. Holland</li><li><strong>이번 범위</strong>: Chapter 1, Section 1-6 · A Thousand Plateaus in Context</li><li><strong>핵심 질문</strong>: 왜 욕망은 늘 어떤 자리에서 풀려나고 다시 붙잡히는가?</li><li><strong>한 문장 핵심</strong>: 영토화는 에너지가 특정 자리와 코드에 붙는 과정이고, 탈영토화는 그 붙음이 풀리는 과정이다. 재영토화는 풀려난 흐름이 다시 새로운 규칙에 포획되는 과정이다.</li></ul><div class="obsidian-callout obsidian-callout--note" data-callout="note">  <div class="obsidian-callout__title">    <span class="obsidian-callout__icon" aria-hidden="true">■</span>    <strong>저작권 처리</strong>  </div>  <div class="obsidian-callout__body"><p>이 글은 원문을 길게 옮기지 않고, 핵심 개념을 한국어 해설과 적용 질문으로 재구성한 변형적 책노트입니다.</p></div></div><h2 id="L1-·-발췌함-대신-개념-단서"><a href="#L1-·-발췌함-대신-개념-단서" class="headerlink" title="L1 · 발췌함 대신 개념 단서"></a>L1 · 발췌함 대신 개념 단서</h2><ul><li><strong>개념 단서</strong>: 자유는 풀림과 재포획 사이에서 발생한다</li><li><strong>맥락 단서</strong>: 흐름은 언제나 어떤 코드에 붙거나 떨어진다</li><li><strong>적용 단서</strong>: 시장과 제도는 욕망을 억압하면서 동시에 풀어낸다</li></ul><h2 id="L2-·-챕터-지도"><a href="#L2-·-챕터-지도" class="headerlink" title="L2 · 챕터 지도"></a>L2 · 챕터 지도</h2><p>이 장에서 중요한 용어는 욕망-생산과 영토화 계열이다. 욕망은 움직인다. 그런데 아무 곳으로나 흩어지는 것이 아니라 몸, 제도, 시장, 언어, 관계 속 특정 자리에 붙는다. 이것이 영토화다.</p><p>탈영토화는 그 붙음이 풀리는 순간이다. 낡은 규칙, 낡은 신분, 낡은 취향이 더 이상 이전처럼 작동하지 않을 때 흐름은 풀려난다. 하지만 자본주의는 이 흐름을 다시 상품, 제도, 유행, 규범으로 붙잡는다. 이것이 재영토화다.</p><p>이 개념은 추상적이지만 일상적이다. 학교, 회사, SNS, 시장은 모두 사람의 욕망을 특정 방식으로 배치한다. 변화는 완전한 자유가 아니라 풀림과 재포획 사이에서 일어난다.</p><h2 id="L3-·-인사이트-카드"><a href="#L3-·-인사이트-카드" class="headerlink" title="L3 · 인사이트 카드"></a>L3 · 인사이트 카드</h2><ul><li>A Thousand Plateaus - I6.1 자유는 풀림과 재포획 사이에서 발생한다</li><li>A Thousand Plateaus - I6.2 흐름은 언제나 어떤 코드에 붙거나 떨어진다</li><li>A Thousand Plateaus - I6.3 시장과 제도는 욕망을 억압하면서 동시에 풀어낸다</li></ul><h2 id="L4-·-생산-보드"><a href="#L4-·-생산-보드" class="headerlink" title="L4 · 생산 보드"></a>L4 · 생산 보드</h2><div class="obsidian-callout obsidian-callout--todo" data-callout="todo">  <div class="obsidian-callout__title">    <span class="obsidian-callout__icon" aria-hidden="true">■</span>    <strong>오늘 적용할 실험</strong>  </div>  <div class="obsidian-callout__body"><p><ul><li><input disabled="" type="checkbox"> 한 가지 유행이 어떻게 기존 코드를 풀고 다시 상품화되는지 분석한다.</li><li><input disabled="" type="checkbox"> 내 생활에서 가장 강한 재영토화 장치를 하나 찾는다.</li><li><input disabled="" type="checkbox"> 탈영토화가 무조건 좋은 것인지 반례를 들어 본다.</li></ul></div></div><h2 id="L5-·-연결-복습"><a href="#L5-·-연결-복습" class="headerlink" title="L5 · 연결 &amp; 복습"></a>L5 · 연결 &amp; 복습</h2><ul><li><strong>연결 개념</strong>: 리좀, 탈영토화, 배치, 차이와 반복</li><li><strong>복습 질문</strong>:<ul><li>이 섹션의 개념을 개인 심리 문제가 아니라 관계와 배치의 문제로 다시 설명하면 어떻게 달라지는가?</li><li>오늘 읽은 개념은 기존의 상식적 분류를 어디에서 흔드는가?</li><li>이 개념을 내 글쓰기, 수업, 프로젝트 설계에 적용하면 무엇을 다르게 보게 되는가?</li></ul></li></ul><p><strong>한 문장 최종 정리</strong>: 영토화는 에너지가 특정 자리와 코드에 붙는 과정이고, 탈영토화는 그 붙음이 풀리는 과정이다. 재영토화는 풀려난 흐름이 다시 새로운 규칙에 포획되는 과정이다.</p>]]>
    </content>
    <id>https://reasonofmoon.github.io/2026/06/27/book-note-thousand-plateaus-reader-guide-ch1-sec06-desire-territory/</id>
    <link href="https://reasonofmoon.github.io/2026/06/27/book-note-thousand-plateaus-reader-guide-ch1-sec06-desire-territory/"/>
    <published>2026-06-27T05:58:00.000Z</published>
    <summary>욕망-생산, 영토화, 탈영토화, 재영토화를 쉬운 예시로 풀어 읽습니다.</summary>
    <title>책노트: A Thousand Plateaus Reader's Guide 1-6 - 욕망-생산과 탈영토화</title>
    <updated>2026-06-27T05:58:00.000Z</updated>
  </entry>
  <entry>
    <author>
      <name>Reasonofmoon</name>
    </author>
    <category term="Book" scheme="https://reasonofmoon.github.io/categories/Book/"/>
    <category term="독서" scheme="https://reasonofmoon.github.io/tags/%EB%8F%85%EC%84%9C/"/>
    <category term="책노트" scheme="https://reasonofmoon.github.io/tags/%EC%B1%85%EB%85%B8%ED%8A%B8/"/>
    <category term="독서/책노트" scheme="https://reasonofmoon.github.io/tags/%EB%8F%85%EC%84%9C-%EC%B1%85%EB%85%B8%ED%8A%B8/"/>
    <category term="Book Notes" scheme="https://reasonofmoon.github.io/tags/Book-Notes/"/>
    <category term="Philosophy" scheme="https://reasonofmoon.github.io/tags/Philosophy/"/>
    <category term="A Thousand Plateaus" scheme="https://reasonofmoon.github.io/tags/A-Thousand-Plateaus/"/>
    <category term="Deleuze" scheme="https://reasonofmoon.github.io/tags/Deleuze/"/>
    <category term="Guattari" scheme="https://reasonofmoon.github.io/tags/Guattari/"/>
    <category term="Rhizome" scheme="https://reasonofmoon.github.io/tags/Rhizome/"/>
    <content>
      <![CDATA[<h1 id="책노트-A-Thousand-Plateaus-Reader’s-Guide-1-4-1968년-이론이-현실의-파열을-만났을-때"><a href="#책노트-A-Thousand-Plateaus-Reader’s-Guide-1-4-1968년-이론이-현실의-파열을-만났을-때" class="headerlink" title="책노트: A Thousand Plateaus Reader’s Guide 1-4 - 1968년, 이론이 현실의 파열을 만났을 때"></a>책노트: A Thousand Plateaus Reader’s Guide 1-4 - 1968년, 이론이 현실의 파열을 만났을 때</h1><div class="obsidian-callout obsidian-callout--abstract" data-callout="abstract">  <div class="obsidian-callout__title">    <span class="obsidian-callout__icon" aria-hidden="true">■</span>    <strong>이 노트의 사용법</strong>  </div>  <div class="obsidian-callout__body"><p>포착 -&gt; 증류 -&gt; 연결 -&gt; 표현 4단계 깔때기로 한 권을 흘려보냅니다.핵심 원칙: 책 노트는 창고, 인사이트 카드는 화폐.</p></div></div><h2 id="L0-·-서지-진입"><a href="#L0-·-서지-진입" class="headerlink" title="L0 · 서지 &amp; 진입"></a>L0 · 서지 &amp; 진입</h2><ul><li><strong>대상 책</strong>: Deleuze and Guattari’s A Thousand Plateaus: A Reader’s Guide</li><li><strong>저자</strong>: Eugene W. Holland</li><li><strong>이번 범위</strong>: Chapter 1, Section 1-4 · A Thousand Plateaus in Context</li><li><strong>핵심 질문</strong>: 왜 1968년은 이 책의 배경이 아니라 사유의 압력인가?</li><li><strong>한 문장 핵심</strong>: 68년은 기존 정치 언어가 현실의 폭발을 설명하지 못한 사건이었다. 들뢰즈와 가타리의 작업은 이 실패를 배경으로, 욕망과 정치와 제도를 함께 설명하려는 시도다.</li></ul><div class="obsidian-callout obsidian-callout--note" data-callout="note">  <div class="obsidian-callout__title">    <span class="obsidian-callout__icon" aria-hidden="true">■</span>    <strong>저작권 처리</strong>  </div>  <div class="obsidian-callout__body"><p>이 글은 원문을 길게 옮기지 않고, 핵심 개념을 한국어 해설과 적용 질문으로 재구성한 변형적 책노트입니다.</p></div></div><h2 id="L1-·-발췌함-대신-개념-단서"><a href="#L1-·-발췌함-대신-개념-단서" class="headerlink" title="L1 · 발췌함 대신 개념 단서"></a>L1 · 발췌함 대신 개념 단서</h2><ul><li><strong>개념 단서</strong>: 현실은 종종 이론보다 먼저 달린다</li><li><strong>맥락 단서</strong>: 정치는 제도뿐 아니라 욕망의 흐름이다</li><li><strong>적용 단서</strong>: 사건은 기존 언어의 한계를 드러낸다</li></ul><h2 id="L2-·-챕터-지도"><a href="#L2-·-챕터-지도" class="headerlink" title="L2 · 챕터 지도"></a>L2 · 챕터 지도</h2><p>홀랜드는 68년 5월을 단순한 역사적 배경으로 두지 않는다. 학생, 노동자, 정당, 노조, 지식인이 서로 어긋나며 움직인 이 사건은 기존 정치 이론의 설명력을 흔들었다.</p><p>특히 프랑스 공산당과 노조가 사건의 흐름을 충분히 읽지 못했다는 점은 중요하다. 욕망과 운동은 공식 조직의 언어보다 빠르게 움직였다. 『안티 오이디푸스』는 바로 이 지점을 사유하려는 시도였다.</p><p>우리에게도 적용된다. 어떤 변화는 조직도, 계획표, 공식 언어보다 먼저 발생한다. 그 변화를 읽으려면 표면의 선언보다 흐름, 균열, 접속, 이탈을 봐야 한다.</p><h2 id="L3-·-인사이트-카드"><a href="#L3-·-인사이트-카드" class="headerlink" title="L3 · 인사이트 카드"></a>L3 · 인사이트 카드</h2><ul><li>A Thousand Plateaus - I4.1 현실은 종종 이론보다 먼저 달린다</li><li>A Thousand Plateaus - I4.2 정치는 제도뿐 아니라 욕망의 흐름이다</li><li>A Thousand Plateaus - I4.3 사건은 기존 언어의 한계를 드러낸다</li></ul><h2 id="L4-·-생산-보드"><a href="#L4-·-생산-보드" class="headerlink" title="L4 · 생산 보드"></a>L4 · 생산 보드</h2><div class="obsidian-callout obsidian-callout--todo" data-callout="todo">  <div class="obsidian-callout__title">    <span class="obsidian-callout__icon" aria-hidden="true">■</span>    <strong>오늘 적용할 실험</strong>  </div>  <div class="obsidian-callout__body"><p><ul><li><input disabled="" type="checkbox"> 최근 변화 하나를 골라 기존 설명이 놓친 욕망의 흐름을 적는다.</li><li><input disabled="" type="checkbox"> 공식 조직과 실제 움직임이 어긋난 사례를 찾는다.</li><li><input disabled="" type="checkbox"> 사건을 원인 하나가 아니라 여러 흐름의 접속으로 도식화한다.</li></ul></div></div><h2 id="L5-·-연결-복습"><a href="#L5-·-연결-복습" class="headerlink" title="L5 · 연결 &amp; 복습"></a>L5 · 연결 &amp; 복습</h2><ul><li><strong>연결 개념</strong>: 리좀, 탈영토화, 배치, 차이와 반복</li><li><strong>복습 질문</strong>:<ul><li>이 섹션의 개념을 개인 심리 문제가 아니라 관계와 배치의 문제로 다시 설명하면 어떻게 달라지는가?</li><li>오늘 읽은 개념은 기존의 상식적 분류를 어디에서 흔드는가?</li><li>이 개념을 내 글쓰기, 수업, 프로젝트 설계에 적용하면 무엇을 다르게 보게 되는가?</li></ul></li></ul><p><strong>한 문장 최종 정리</strong>: 68년은 기존 정치 언어가 현실의 폭발을 설명하지 못한 사건이었다. 들뢰즈와 가타리의 작업은 이 실패를 배경으로, 욕망과 정치와 제도를 함께 설명하려는 시도다.</p>]]>
    </content>
    <id>https://reasonofmoon.github.io/2026/06/27/book-note-thousand-plateaus-reader-guide-ch1-sec04-may-68/</id>
    <link href="https://reasonofmoon.github.io/2026/06/27/book-note-thousand-plateaus-reader-guide-ch1-sec04-may-68/"/>
    <published>2026-06-27T05:58:00.000Z</published>
    <summary>프랑스 68년의 정치적 충격이 왜 들뢰즈와 가타리의 공동 작업을 이해하는 핵심 배경인지 정리합니다.</summary>
    <title>책노트: A Thousand Plateaus Reader's Guide 1-4 - 1968년, 이론이 현실의 파열을 만났을 때</title>
    <updated>2026-06-27T05:58:00.000Z</updated>
  </entry>
  <entry>
    <author>
      <name>Reasonofmoon</name>
    </author>
    <category term="Book" scheme="https://reasonofmoon.github.io/categories/Book/"/>
    <category term="독서" scheme="https://reasonofmoon.github.io/tags/%EB%8F%85%EC%84%9C/"/>
    <category term="책노트" scheme="https://reasonofmoon.github.io/tags/%EC%B1%85%EB%85%B8%ED%8A%B8/"/>
    <category term="독서/책노트" scheme="https://reasonofmoon.github.io/tags/%EB%8F%85%EC%84%9C-%EC%B1%85%EB%85%B8%ED%8A%B8/"/>
    <category term="Book Notes" scheme="https://reasonofmoon.github.io/tags/Book-Notes/"/>
    <category term="Philosophy" scheme="https://reasonofmoon.github.io/tags/Philosophy/"/>
    <category term="A Thousand Plateaus" scheme="https://reasonofmoon.github.io/tags/A-Thousand-Plateaus/"/>
    <category term="Deleuze" scheme="https://reasonofmoon.github.io/tags/Deleuze/"/>
    <category term="Guattari" scheme="https://reasonofmoon.github.io/tags/Guattari/"/>
    <category term="Rhizome" scheme="https://reasonofmoon.github.io/tags/Rhizome/"/>
    <content>
      <![CDATA[<h1 id="책노트-A-Thousand-Plateaus-Reader’s-Guide-1-5-무의식은-언어가-아니라-생산이다"><a href="#책노트-A-Thousand-Plateaus-Reader’s-Guide-1-5-무의식은-언어가-아니라-생산이다" class="headerlink" title="책노트: A Thousand Plateaus Reader’s Guide 1-5 - 무의식은 언어가 아니라 생산이다"></a>책노트: A Thousand Plateaus Reader’s Guide 1-5 - 무의식은 언어가 아니라 생산이다</h1><div class="obsidian-callout obsidian-callout--abstract" data-callout="abstract">  <div class="obsidian-callout__title">    <span class="obsidian-callout__icon" aria-hidden="true">■</span>    <strong>이 노트의 사용법</strong>  </div>  <div class="obsidian-callout__body"><p>포착 -&gt; 증류 -&gt; 연결 -&gt; 표현 4단계 깔때기로 한 권을 흘려보냅니다.핵심 원칙: 책 노트는 창고, 인사이트 카드는 화폐.</p></div></div><h2 id="L0-·-서지-진입"><a href="#L0-·-서지-진입" class="headerlink" title="L0 · 서지 &amp; 진입"></a>L0 · 서지 &amp; 진입</h2><ul><li><strong>대상 책</strong>: Deleuze and Guattari’s A Thousand Plateaus: A Reader’s Guide</li><li><strong>저자</strong>: Eugene W. Holland</li><li><strong>이번 범위</strong>: Chapter 1, Section 1-5 · A Thousand Plateaus in Context</li><li><strong>핵심 질문</strong>: 무의식을 해석해야 할 텍스트가 아니라 작동하는 기계로 보면 무엇이 달라지는가?</li><li><strong>한 문장 핵심</strong>: 들뢰즈와 가타리에게 무의식은 숨은 의미를 품은 텍스트가 아니라 생산하는 과정이다. 이때 비판은 개인 심리 분석이 아니라 사회적 관계의 재구성으로 확장된다.</li></ul><div class="obsidian-callout obsidian-callout--note" data-callout="note">  <div class="obsidian-callout__title">    <span class="obsidian-callout__icon" aria-hidden="true">■</span>    <strong>저작권 처리</strong>  </div>  <div class="obsidian-callout__body"><p>이 글은 원문을 길게 옮기지 않고, 핵심 개념을 한국어 해설과 적용 질문으로 재구성한 변형적 책노트입니다.</p></div></div><h2 id="L1-·-발췌함-대신-개념-단서"><a href="#L1-·-발췌함-대신-개념-단서" class="headerlink" title="L1 · 발췌함 대신 개념 단서"></a>L1 · 발췌함 대신 개념 단서</h2><ul><li><strong>개념 단서</strong>: 욕망은 결핍보다 생산에 가깝다</li><li><strong>맥락 단서</strong>: 해석보다 작동 방식을 보라</li><li><strong>적용 단서</strong>: 심리 문제는 사회적 형식과 분리되지 않는다</li></ul><h2 id="L2-·-챕터-지도"><a href="#L2-·-챕터-지도" class="headerlink" title="L2 · 챕터 지도"></a>L2 · 챕터 지도</h2><p>홀랜드는 『안티 오이디푸스』의 핵심 전환을 설명한다. 무의식을 언어처럼 구조화된 것으로 보는 대신, 들뢰즈와 가타리는 무의식을 생산하는 힘으로 본다. 욕망은 결핍이 아니라 무언가를 만들고 연결하는 에너지다.</p><p>이 관점에서 정신분석 비판은 단지 치료 기법에 대한 비판이 아니다. 욕망을 가족, 오이디푸스, 개인 내부로 좁히는 방식 자체가 사회적 현실을 가리는 장치가 된다.</p><p>그래서 이들의 비판은 칸트, 마르크스, 니체를 한꺼번에 비틀어 간다. 무엇을 알 수 있는가의 문제가 무엇이 욕망을 억압하거나 생산하게 하는가의 문제로 이동한다.</p><h2 id="L3-·-인사이트-카드"><a href="#L3-·-인사이트-카드" class="headerlink" title="L3 · 인사이트 카드"></a>L3 · 인사이트 카드</h2><ul><li>A Thousand Plateaus - I5.1 욕망은 결핍보다 생산에 가깝다</li><li>A Thousand Plateaus - I5.2 해석보다 작동 방식을 보라</li><li>A Thousand Plateaus - I5.3 심리 문제는 사회적 형식과 분리되지 않는다</li></ul><h2 id="L4-·-생산-보드"><a href="#L4-·-생산-보드" class="headerlink" title="L4 · 생산 보드"></a>L4 · 생산 보드</h2><div class="obsidian-callout obsidian-callout--todo" data-callout="todo">  <div class="obsidian-callout__title">    <span class="obsidian-callout__icon" aria-hidden="true">■</span>    <strong>오늘 적용할 실험</strong>  </div>  <div class="obsidian-callout__body"><p><ul><li><input disabled="" type="checkbox"> 어떤 행동을 “왜 그랬을까”보다 “무엇을 생산했는가”로 질문한다.</li><li><input disabled="" type="checkbox"> 숨은 의미 찾기와 작동 구조 분석을 구분한다.</li><li><input disabled="" type="checkbox"> 개인 감정 뒤의 제도적 회로를 찾아본다.</li></ul></div></div><h2 id="L5-·-연결-복습"><a href="#L5-·-연결-복습" class="headerlink" title="L5 · 연결 &amp; 복습"></a>L5 · 연결 &amp; 복습</h2><ul><li><strong>연결 개념</strong>: 리좀, 탈영토화, 배치, 차이와 반복</li><li><strong>복습 질문</strong>:<ul><li>이 섹션의 개념을 개인 심리 문제가 아니라 관계와 배치의 문제로 다시 설명하면 어떻게 달라지는가?</li><li>오늘 읽은 개념은 기존의 상식적 분류를 어디에서 흔드는가?</li><li>이 개념을 내 글쓰기, 수업, 프로젝트 설계에 적용하면 무엇을 다르게 보게 되는가?</li></ul></li></ul><p><strong>한 문장 최종 정리</strong>: 들뢰즈와 가타리에게 무의식은 숨은 의미를 품은 텍스트가 아니라 생산하는 과정이다. 이때 비판은 개인 심리 분석이 아니라 사회적 관계의 재구성으로 확장된다.</p>]]>
    </content>
    <id>https://reasonofmoon.github.io/2026/06/27/book-note-thousand-plateaus-reader-guide-ch1-sec05-unconscious-production/</id>
    <link href="https://reasonofmoon.github.io/2026/06/27/book-note-thousand-plateaus-reader-guide-ch1-sec05-unconscious-production/"/>
    <published>2026-06-27T05:58:00.000Z</published>
    <summary>라캉식 언어 중심 무의식과 달리, 들뢰즈와 가타리가 무의식을 생산과 배치의 문제로 보는 이유를 정리합니다.</summary>
    <title>책노트: A Thousand Plateaus Reader's Guide 1-5 - 무의식은 언어가 아니라 생산이다</title>
    <updated>2026-06-27T05:58:00.000Z</updated>
  </entry>
  <entry>
    <author>
      <name>Reasonofmoon</name>
    </author>
    <category term="Book" scheme="https://reasonofmoon.github.io/categories/Book/"/>
    <category term="독서" scheme="https://reasonofmoon.github.io/tags/%EB%8F%85%EC%84%9C/"/>
    <category term="책노트" scheme="https://reasonofmoon.github.io/tags/%EC%B1%85%EB%85%B8%ED%8A%B8/"/>
    <category term="독서/책노트" scheme="https://reasonofmoon.github.io/tags/%EB%8F%85%EC%84%9C-%EC%B1%85%EB%85%B8%ED%8A%B8/"/>
    <category term="Book Notes" scheme="https://reasonofmoon.github.io/tags/Book-Notes/"/>
    <category term="Philosophy" scheme="https://reasonofmoon.github.io/tags/Philosophy/"/>
    <category term="A Thousand Plateaus" scheme="https://reasonofmoon.github.io/tags/A-Thousand-Plateaus/"/>
    <category term="Deleuze" scheme="https://reasonofmoon.github.io/tags/Deleuze/"/>
    <category term="Guattari" scheme="https://reasonofmoon.github.io/tags/Guattari/"/>
    <category term="Rhizome" scheme="https://reasonofmoon.github.io/tags/Rhizome/"/>
    <content>
      <![CDATA[<h1 id="책노트-A-Thousand-Plateaus-Reader’s-Guide-1-8-프루스트-삶은-직선이-아니라-패치워크다"><a href="#책노트-A-Thousand-Plateaus-Reader’s-Guide-1-8-프루스트-삶은-직선이-아니라-패치워크다" class="headerlink" title="책노트: A Thousand Plateaus Reader’s Guide 1-8 - 프루스트, 삶은 직선이 아니라 패치워크다"></a>책노트: A Thousand Plateaus Reader’s Guide 1-8 - 프루스트, 삶은 직선이 아니라 패치워크다</h1><div class="obsidian-callout obsidian-callout--abstract" data-callout="abstract">  <div class="obsidian-callout__title">    <span class="obsidian-callout__icon" aria-hidden="true">■</span>    <strong>이 노트의 사용법</strong>  </div>  <div class="obsidian-callout__body"><p>포착 -&gt; 증류 -&gt; 연결 -&gt; 표현 4단계 깔때기로 한 권을 흘려보냅니다.핵심 원칙: 책 노트는 창고, 인사이트 카드는 화폐.</p></div></div><h2 id="L0-·-서지-진입"><a href="#L0-·-서지-진입" class="headerlink" title="L0 · 서지 &amp; 진입"></a>L0 · 서지 &amp; 진입</h2><ul><li><strong>대상 책</strong>: Deleuze and Guattari’s A Thousand Plateaus: A Reader’s Guide</li><li><strong>저자</strong>: Eugene W. Holland</li><li><strong>이번 범위</strong>: Chapter 1, Section 1-8 · A Thousand Plateaus in Context</li><li><strong>핵심 질문</strong>: 삶을 하나의 직선 서사가 아니라 연결들의 패치워크로 보면 무엇이 보이는가?</li><li><strong>한 문장 핵심</strong>: 프루스트는 기억과 삶을 직선적 회상이 아니라 예기치 않은 연결의 패치워크로 보여준다. 들뢰즈와 가타리는 이 이미지를 사유의 형식으로 가져온다.</li></ul><div class="obsidian-callout obsidian-callout--note" data-callout="note">  <div class="obsidian-callout__title">    <span class="obsidian-callout__icon" aria-hidden="true">■</span>    <strong>저작권 처리</strong>  </div>  <div class="obsidian-callout__body"><p>이 글은 원문을 길게 옮기지 않고, 핵심 개념을 한국어 해설과 적용 질문으로 재구성한 변형적 책노트입니다.</p></div></div><h2 id="L1-·-발췌함-대신-개념-단서"><a href="#L1-·-발췌함-대신-개념-단서" class="headerlink" title="L1 · 발췌함 대신 개념 단서"></a>L1 · 발췌함 대신 개념 단서</h2><ul><li><strong>개념 단서</strong>: 삶은 연대기보다 연결망에 가깝다</li><li><strong>맥락 단서</strong>: 주체는 원인이라기보다 연결의 효과일 수 있다</li><li><strong>적용 단서</strong>: 좋은 노트는 직선 요약과 패치워크 연결을 함께 품는다</li></ul><h2 id="L2-·-챕터-지도"><a href="#L2-·-챕터-지도" class="headerlink" title="L2 · 챕터 지도"></a>L2 · 챕터 지도</h2><p>홀랜드는 프루스트가 『천 개의 고원』의 이미지에 기여한 점을 설명한다. 중요한 것은 의지적으로 떠올리는 기억보다, 현재의 감각이 갑자기 과거의 장면을 불러오는 비자발적 기억이다.</p><p>이때 삶은 연대기처럼 정렬되지 않는다. 시간들은 서로 뛰어넘어 접속하고, 하나의 생은 그 접속들의 패치워크처럼 보인다. 주체는 이 모든 것을 지배하는 중심이라기보다, 연결들의 결과로 생기는 잔여에 가깝다.</p><p>이 관점은 독서와 글쓰기에도 유용하다. 책을 처음부터 끝까지 한 줄 요약으로만 정리하면 다중적인 연결이 사라진다. 좋은 노트는 직선 요약과 비선형 연결을 함께 가져야 한다.</p><h2 id="L3-·-인사이트-카드"><a href="#L3-·-인사이트-카드" class="headerlink" title="L3 · 인사이트 카드"></a>L3 · 인사이트 카드</h2><ul><li>A Thousand Plateaus - I8.1 삶은 연대기보다 연결망에 가깝다</li><li>A Thousand Plateaus - I8.2 주체는 원인이라기보다 연결의 효과일 수 있다</li><li>A Thousand Plateaus - I8.3 좋은 노트는 직선 요약과 패치워크 연결을 함께 품는다</li></ul><h2 id="L4-·-생산-보드"><a href="#L4-·-생산-보드" class="headerlink" title="L4 · 생산 보드"></a>L4 · 생산 보드</h2><div class="obsidian-callout obsidian-callout--todo" data-callout="todo">  <div class="obsidian-callout__title">    <span class="obsidian-callout__icon" aria-hidden="true">■</span>    <strong>오늘 적용할 실험</strong>  </div>  <div class="obsidian-callout__body"><p><ul><li><input disabled="" type="checkbox"> 한 기억이 다른 기억을 불러온 최근 사례를 적는다.</li><li><input disabled="" type="checkbox"> 독서 노트 하나를 시간순이 아니라 연결순으로 재배치한다.</li><li><input disabled="" type="checkbox"> 내 삶의 한 사건을 원인-결과 대신 접속-변형으로 설명한다.</li></ul></div></div><h2 id="L5-·-연결-복습"><a href="#L5-·-연결-복습" class="headerlink" title="L5 · 연결 &amp; 복습"></a>L5 · 연결 &amp; 복습</h2><ul><li><strong>연결 개념</strong>: 리좀, 탈영토화, 배치, 차이와 반복</li><li><strong>복습 질문</strong>:<ul><li>이 섹션의 개념을 개인 심리 문제가 아니라 관계와 배치의 문제로 다시 설명하면 어떻게 달라지는가?</li><li>오늘 읽은 개념은 기존의 상식적 분류를 어디에서 흔드는가?</li><li>이 개념을 내 글쓰기, 수업, 프로젝트 설계에 적용하면 무엇을 다르게 보게 되는가?</li></ul></li></ul><p><strong>한 문장 최종 정리</strong>: 프루스트는 기억과 삶을 직선적 회상이 아니라 예기치 않은 연결의 패치워크로 보여준다. 들뢰즈와 가타리는 이 이미지를 사유의 형식으로 가져온다.</p>]]>
    </content>
    <id>https://reasonofmoon.github.io/2026/06/27/book-note-thousand-plateaus-reader-guide-ch1-sec08-proust-patchwork/</id>
    <link href="https://reasonofmoon.github.io/2026/06/27/book-note-thousand-plateaus-reader-guide-ch1-sec08-proust-patchwork/"/>
    <published>2026-06-27T05:58:00.000Z</published>
    <summary>프루스트와 비자발적 기억을 통해 『천 개의 고원』의 시간적 다중성을 이해합니다.</summary>
    <title>책노트: A Thousand Plateaus Reader's Guide 1-8 - 프루스트, 삶은 직선이 아니라 패치워크다</title>
    <updated>2026-06-27T05:58:00.000Z</updated>
  </entry>
  <entry>
    <author>
      <name>Reasonofmoon</name>
    </author>
    <category term="Book" scheme="https://reasonofmoon.github.io/categories/Book/"/>
    <category term="독서" scheme="https://reasonofmoon.github.io/tags/%EB%8F%85%EC%84%9C/"/>
    <category term="책노트" scheme="https://reasonofmoon.github.io/tags/%EC%B1%85%EB%85%B8%ED%8A%B8/"/>
    <category term="독서/책노트" scheme="https://reasonofmoon.github.io/tags/%EB%8F%85%EC%84%9C-%EC%B1%85%EB%85%B8%ED%8A%B8/"/>
    <category term="Book Notes" scheme="https://reasonofmoon.github.io/tags/Book-Notes/"/>
    <category term="Philosophy" scheme="https://reasonofmoon.github.io/tags/Philosophy/"/>
    <category term="A Thousand Plateaus" scheme="https://reasonofmoon.github.io/tags/A-Thousand-Plateaus/"/>
    <category term="Deleuze" scheme="https://reasonofmoon.github.io/tags/Deleuze/"/>
    <category term="Guattari" scheme="https://reasonofmoon.github.io/tags/Guattari/"/>
    <category term="Rhizome" scheme="https://reasonofmoon.github.io/tags/Rhizome/"/>
    <content>
      <![CDATA[<h1 id="책노트-A-Thousand-Plateaus-Reader’s-Guide-1-9-카프카-사유는-뿌리가-아니라-굴이다"><a href="#책노트-A-Thousand-Plateaus-Reader’s-Guide-1-9-카프카-사유는-뿌리가-아니라-굴이다" class="headerlink" title="책노트: A Thousand Plateaus Reader’s Guide 1-9 - 카프카, 사유는 뿌리가 아니라 굴이다"></a>책노트: A Thousand Plateaus Reader’s Guide 1-9 - 카프카, 사유는 뿌리가 아니라 굴이다</h1><div class="obsidian-callout obsidian-callout--abstract" data-callout="abstract">  <div class="obsidian-callout__title">    <span class="obsidian-callout__icon" aria-hidden="true">■</span>    <strong>이 노트의 사용법</strong>  </div>  <div class="obsidian-callout__body"><p>포착 -&gt; 증류 -&gt; 연결 -&gt; 표현 4단계 깔때기로 한 권을 흘려보냅니다.핵심 원칙: 책 노트는 창고, 인사이트 카드는 화폐.</p></div></div><h2 id="L0-·-서지-진입"><a href="#L0-·-서지-진입" class="headerlink" title="L0 · 서지 &amp; 진입"></a>L0 · 서지 &amp; 진입</h2><ul><li><strong>대상 책</strong>: Deleuze and Guattari’s A Thousand Plateaus: A Reader’s Guide</li><li><strong>저자</strong>: Eugene W. Holland</li><li><strong>이번 범위</strong>: Chapter 1, Section 1-9 · A Thousand Plateaus in Context</li><li><strong>핵심 질문</strong>: 리좀은 왜 나무보다 굴, 지도, 통로에 가까운가?</li><li><strong>한 문장 핵심</strong>: 카프카의 세계에서 공간은 위계적 건물이 아니라 예측 불가능한 통로들의 연결망이다. 리좀은 바로 이런 식의 사유 이미지다.</li></ul><div class="obsidian-callout obsidian-callout--note" data-callout="note">  <div class="obsidian-callout__title">    <span class="obsidian-callout__icon" aria-hidden="true">■</span>    <strong>저작권 처리</strong>  </div>  <div class="obsidian-callout__body"><p>이 글은 원문을 길게 옮기지 않고, 핵심 개념을 한국어 해설과 적용 질문으로 재구성한 변형적 책노트입니다.</p></div></div><h2 id="L1-·-발췌함-대신-개념-단서"><a href="#L1-·-발췌함-대신-개념-단서" class="headerlink" title="L1 · 발췌함 대신 개념 단서"></a>L1 · 발췌함 대신 개념 단서</h2><ul><li><strong>개념 단서</strong>: 리좀은 중심 없는 연결의 이미지다</li><li><strong>맥락 단서</strong>: 권력은 조직도보다 실제 통로에서 작동한다</li><li><strong>적용 단서</strong>: 어려운 책은 목차보다 연결 지도로 읽을 수 있다</li></ul><h2 id="L2-·-챕터-지도"><a href="#L2-·-챕터-지도" class="headerlink" title="L2 · 챕터 지도"></a>L2 · 챕터 지도</h2><p>프루스트가 시간적 패치워크를 제공했다면, 카프카는 공간적 리좀을 제공한다. 카프카의 방들은 예상치 못한 문과 통로로 연결된다. 관료제의 권력선도 고정된 조직도처럼 보이지만 실제로는 계속 바뀐다.</p><p>리좀은 뿌리 깊은 나무가 아니다. 중심 줄기에서 가지가 뻗는 구조가 아니라, 어디서든 어디로든 접속 가능한 굴과 지도에 가깝다. 『천 개의 고원』이 여러 고원으로 구성된 것도 이와 관련된다.</p><p>이 읽기법은 어렵지만 해방적이다. 반드시 1장부터 끝까지 하나의 논증을 따라가야만 하는 것은 아니다. 개념과 예시 사이의 통로를 찾는 방식으로 읽을 수 있다.</p><h2 id="L3-·-인사이트-카드"><a href="#L3-·-인사이트-카드" class="headerlink" title="L3 · 인사이트 카드"></a>L3 · 인사이트 카드</h2><ul><li>A Thousand Plateaus - I9.1 리좀은 중심 없는 연결의 이미지다</li><li>A Thousand Plateaus - I9.2 권력은 조직도보다 실제 통로에서 작동한다</li><li>A Thousand Plateaus - I9.3 어려운 책은 목차보다 연결 지도로 읽을 수 있다</li></ul><h2 id="L4-·-생산-보드"><a href="#L4-·-생산-보드" class="headerlink" title="L4 · 생산 보드"></a>L4 · 생산 보드</h2><div class="obsidian-callout obsidian-callout--todo" data-callout="todo">  <div class="obsidian-callout__title">    <span class="obsidian-callout__icon" aria-hidden="true">■</span>    <strong>오늘 적용할 실험</strong>  </div>  <div class="obsidian-callout__body"><p><ul><li><input disabled="" type="checkbox"> 내가 속한 조직의 공식 구조와 실제 영향 경로를 따로 그린다.</li><li><input disabled="" type="checkbox"> 책의 목차를 위계가 아니라 지도처럼 다시 배치한다.</li><li><input disabled="" type="checkbox"> 중심 개념 하나에서 주변 개념 다섯 개로 통로를 만든다.</li></ul></div></div><h2 id="L5-·-연결-복습"><a href="#L5-·-연결-복습" class="headerlink" title="L5 · 연결 &amp; 복습"></a>L5 · 연결 &amp; 복습</h2><ul><li><strong>연결 개념</strong>: 리좀, 탈영토화, 배치, 차이와 반복</li><li><strong>복습 질문</strong>:<ul><li>이 섹션의 개념을 개인 심리 문제가 아니라 관계와 배치의 문제로 다시 설명하면 어떻게 달라지는가?</li><li>오늘 읽은 개념은 기존의 상식적 분류를 어디에서 흔드는가?</li><li>이 개념을 내 글쓰기, 수업, 프로젝트 설계에 적용하면 무엇을 다르게 보게 되는가?</li></ul></li></ul><p><strong>한 문장 최종 정리</strong>: 카프카의 세계에서 공간은 위계적 건물이 아니라 예측 불가능한 통로들의 연결망이다. 리좀은 바로 이런 식의 사유 이미지다.</p>]]>
    </content>
    <id>https://reasonofmoon.github.io/2026/06/27/book-note-thousand-plateaus-reader-guide-ch1-sec09-kafka-rhizome/</id>
    <link href="https://reasonofmoon.github.io/2026/06/27/book-note-thousand-plateaus-reader-guide-ch1-sec09-kafka-rhizome/"/>
    <published>2026-06-27T05:58:00.000Z</published>
    <summary>카프카의 방, 통로, 관료제 이미지를 통해 리좀을 공간적 다중성으로 이해합니다.</summary>
    <title>책노트: A Thousand Plateaus Reader's Guide 1-9 - 카프카, 사유는 뿌리가 아니라 굴이다</title>
    <updated>2026-06-27T05:58:00.000Z</updated>
  </entry>
  <entry>
    <author>
      <name>Reasonofmoon</name>
    </author>
    <category term="Book" scheme="https://reasonofmoon.github.io/categories/Book/"/>
    <category term="독서" scheme="https://reasonofmoon.github.io/tags/%EB%8F%85%EC%84%9C/"/>
    <category term="책노트" scheme="https://reasonofmoon.github.io/tags/%EC%B1%85%EB%85%B8%ED%8A%B8/"/>
    <category term="독서/책노트" scheme="https://reasonofmoon.github.io/tags/%EB%8F%85%EC%84%9C-%EC%B1%85%EB%85%B8%ED%8A%B8/"/>
    <category term="Book Notes" scheme="https://reasonofmoon.github.io/tags/Book-Notes/"/>
    <category term="Philosophy" scheme="https://reasonofmoon.github.io/tags/Philosophy/"/>
    <category term="A Thousand Plateaus" scheme="https://reasonofmoon.github.io/tags/A-Thousand-Plateaus/"/>
    <category term="Deleuze" scheme="https://reasonofmoon.github.io/tags/Deleuze/"/>
    <category term="Guattari" scheme="https://reasonofmoon.github.io/tags/Guattari/"/>
    <category term="Rhizome" scheme="https://reasonofmoon.github.io/tags/Rhizome/"/>
    <content>
      <![CDATA[<h1 id="책노트-A-Thousand-Plateaus-Reader’s-Guide-1-10-철학-과학-예술-사이에서"><a href="#책노트-A-Thousand-Plateaus-Reader’s-Guide-1-10-철학-과학-예술-사이에서" class="headerlink" title="책노트: A Thousand Plateaus Reader’s Guide 1-10 - 철학, 과학, 예술 사이에서"></a>책노트: A Thousand Plateaus Reader’s Guide 1-10 - 철학, 과학, 예술 사이에서</h1><div class="obsidian-callout obsidian-callout--abstract" data-callout="abstract">  <div class="obsidian-callout__title">    <span class="obsidian-callout__icon" aria-hidden="true">■</span>    <strong>이 노트의 사용법</strong>  </div>  <div class="obsidian-callout__body"><p>포착 -&gt; 증류 -&gt; 연결 -&gt; 표현 4단계 깔때기로 한 권을 흘려보냅니다.핵심 원칙: 책 노트는 창고, 인사이트 카드는 화폐.</p></div></div><h2 id="L0-·-서지-진입"><a href="#L0-·-서지-진입" class="headerlink" title="L0 · 서지 &amp; 진입"></a>L0 · 서지 &amp; 진입</h2><ul><li><strong>대상 책</strong>: Deleuze and Guattari’s A Thousand Plateaus: A Reader’s Guide</li><li><strong>저자</strong>: Eugene W. Holland</li><li><strong>이번 범위</strong>: Chapter 1, Section 1-10 · A Thousand Plateaus in Context</li><li><strong>핵심 질문</strong>: 철학은 왜 자기 바깥의 과학과 예술을 필요로 하는가?</li><li><strong>한 문장 핵심</strong>: 들뢰즈와 가타리에게 철학은 개념을 만드는 일이다. 하지만 그 개념은 철학 내부에서만 나오지 않는다. 과학, 예술, 정치, 문학의 사건과 접속하면서 생긴다.</li></ul><div class="obsidian-callout obsidian-callout--note" data-callout="note">  <div class="obsidian-callout__title">    <span class="obsidian-callout__icon" aria-hidden="true">■</span>    <strong>저작권 처리</strong>  </div>  <div class="obsidian-callout__body"><p>이 글은 원문을 길게 옮기지 않고, 핵심 개념을 한국어 해설과 적용 질문으로 재구성한 변형적 책노트입니다.</p></div></div><h2 id="L1-·-발췌함-대신-개념-단서"><a href="#L1-·-발췌함-대신-개념-단서" class="headerlink" title="L1 · 발췌함 대신 개념 단서"></a>L1 · 발췌함 대신 개념 단서</h2><ul><li><strong>개념 단서</strong>: 철학은 개념을 만들지만 개념의 재료는 바깥에서 온다</li><li><strong>맥락 단서</strong>: 분야 간 연결은 장식이 아니라 사유의 엔진이다</li><li><strong>적용 단서</strong>: 좋은 독서는 지식을 모으는 일이 아니라 변환하는 일이다</li></ul><h2 id="L2-·-챕터-지도"><a href="#L2-·-챕터-지도" class="headerlink" title="L2 · 챕터 지도"></a>L2 · 챕터 지도</h2><p>1장의 마지막에서 홀랜드는 『무엇이 철학인가?』를 통해 『천 개의 고원』을 되비춘다. 철학, 과학, 예술은 모두 생각하지만 같은 방식으로 생각하지 않는다. 철학은 개념을 만들고, 과학은 함수와 모델을 만들며, 예술은 감각의 블록을 만든다.</p><p>『천 개의 고원』은 철학책이지만 순수 철학 내부에 갇히지 않는다. 문학, 수학, 인류학, 생물학, 음악, 정치경제학을 끌어들인다. 이것은 잡다함이 아니라 개념 생성의 방식이다.</p><p>독자로서 중요한 기준은 하나다. 이 책을 모든 분야의 정답 모음처럼 읽지 말고, 여러 분야의 사건이 철학 개념으로 변환되는 과정을 읽어야 한다.</p><h2 id="L3-·-인사이트-카드"><a href="#L3-·-인사이트-카드" class="headerlink" title="L3 · 인사이트 카드"></a>L3 · 인사이트 카드</h2><ul><li>A Thousand Plateaus - I10.1 철학은 개념을 만들지만 개념의 재료는 바깥에서 온다</li><li>A Thousand Plateaus - I10.2 분야 간 연결은 장식이 아니라 사유의 엔진이다</li><li>A Thousand Plateaus - I10.3 좋은 독서는 지식을 모으는 일이 아니라 변환하는 일이다</li></ul><h2 id="L4-·-생산-보드"><a href="#L4-·-생산-보드" class="headerlink" title="L4 · 생산 보드"></a>L4 · 생산 보드</h2><div class="obsidian-callout obsidian-callout--todo" data-callout="todo">  <div class="obsidian-callout__title">    <span class="obsidian-callout__icon" aria-hidden="true">■</span>    <strong>오늘 적용할 실험</strong>  </div>  <div class="obsidian-callout__body"><p><ul><li><input disabled="" type="checkbox"> 하나의 철학 개념을 과학, 예술, 정치 사례 각각에 연결한다.</li><li><input disabled="" type="checkbox"> 분야가 다른 자료를 가져와 하나의 질문으로 묶어 본다.</li><li><input disabled="" type="checkbox"> 오늘 읽은 개념이 어떤 새 질문을 만들었는지 적는다.</li></ul></div></div><h2 id="L5-·-연결-복습"><a href="#L5-·-연결-복습" class="headerlink" title="L5 · 연결 &amp; 복습"></a>L5 · 연결 &amp; 복습</h2><ul><li><strong>연결 개념</strong>: 리좀, 탈영토화, 배치, 차이와 반복</li><li><strong>복습 질문</strong>:<ul><li>이 섹션의 개념을 개인 심리 문제가 아니라 관계와 배치의 문제로 다시 설명하면 어떻게 달라지는가?</li><li>오늘 읽은 개념은 기존의 상식적 분류를 어디에서 흔드는가?</li><li>이 개념을 내 글쓰기, 수업, 프로젝트 설계에 적용하면 무엇을 다르게 보게 되는가?</li></ul></li></ul><p><strong>한 문장 최종 정리</strong>: 들뢰즈와 가타리에게 철학은 개념을 만드는 일이다. 하지만 그 개념은 철학 내부에서만 나오지 않는다. 과학, 예술, 정치, 문학의 사건과 접속하면서 생긴다.</p>]]>
    </content>
    <id>https://reasonofmoon.github.io/2026/06/27/book-note-thousand-plateaus-reader-guide-ch1-sec10-philosophy-science-art/</id>
    <link href="https://reasonofmoon.github.io/2026/06/27/book-note-thousand-plateaus-reader-guide-ch1-sec10-philosophy-science-art/"/>
    <published>2026-06-27T05:58:00.000Z</published>
    <summary>『천 개의 고원』이 철학이면서도 과학과 예술을 끊임없이 끌어들이는 이유를 정리합니다.</summary>
    <title>책노트: A Thousand Plateaus Reader's Guide 1-10 - 철학, 과학, 예술 사이에서</title>
    <updated>2026-06-27T05:58:00.000Z</updated>
  </entry>
  <entry>
    <author>
      <name>Reasonofmoon</name>
    </author>
    <category term="Book" scheme="https://reasonofmoon.github.io/categories/Book/"/>
    <category term="독서" scheme="https://reasonofmoon.github.io/tags/%EB%8F%85%EC%84%9C/"/>
    <category term="책노트" scheme="https://reasonofmoon.github.io/tags/%EC%B1%85%EB%85%B8%ED%8A%B8/"/>
    <category term="독서/책노트" scheme="https://reasonofmoon.github.io/tags/%EB%8F%85%EC%84%9C-%EC%B1%85%EB%85%B8%ED%8A%B8/"/>
    <category term="Book Notes" scheme="https://reasonofmoon.github.io/tags/Book-Notes/"/>
    <category term="Philosophy" scheme="https://reasonofmoon.github.io/tags/Philosophy/"/>
    <category term="A Thousand Plateaus" scheme="https://reasonofmoon.github.io/tags/A-Thousand-Plateaus/"/>
    <category term="Deleuze" scheme="https://reasonofmoon.github.io/tags/Deleuze/"/>
    <category term="Guattari" scheme="https://reasonofmoon.github.io/tags/Guattari/"/>
    <category term="Rhizome" scheme="https://reasonofmoon.github.io/tags/Rhizome/"/>
    <content>
      <![CDATA[<h1 id="책노트-A-Thousand-Plateaus-Reader’s-Guide-1-7-반복-속-차이-재즈처럼-생각하기"><a href="#책노트-A-Thousand-Plateaus-Reader’s-Guide-1-7-반복-속-차이-재즈처럼-생각하기" class="headerlink" title="책노트: A Thousand Plateaus Reader’s Guide 1-7 - 반복 속 차이, 재즈처럼 생각하기"></a>책노트: A Thousand Plateaus Reader’s Guide 1-7 - 반복 속 차이, 재즈처럼 생각하기</h1><div class="obsidian-callout obsidian-callout--abstract" data-callout="abstract">  <div class="obsidian-callout__title">    <span class="obsidian-callout__icon" aria-hidden="true">■</span>    <strong>이 노트의 사용법</strong>  </div>  <div class="obsidian-callout__body"><p>포착 -&gt; 증류 -&gt; 연결 -&gt; 표현 4단계 깔때기로 한 권을 흘려보냅니다.핵심 원칙: 책 노트는 창고, 인사이트 카드는 화폐.</p></div></div><h2 id="L0-·-서지-진입"><a href="#L0-·-서지-진입" class="headerlink" title="L0 · 서지 &amp; 진입"></a>L0 · 서지 &amp; 진입</h2><ul><li><strong>대상 책</strong>: Deleuze and Guattari’s A Thousand Plateaus: A Reader’s Guide</li><li><strong>저자</strong>: Eugene W. Holland</li><li><strong>이번 범위</strong>: Chapter 1, Section 1-7 · A Thousand Plateaus in Context</li><li><strong>핵심 질문</strong>: 반복은 왜 때로 습관이 되고 때로 창조가 되는가?</li><li><strong>한 문장 핵심</strong>: 반복은 같은 것을 되풀이하는 일이 아니다. 반복 속에 차이가 얼마나 들어오느냐에 따라 습관이 되기도 하고, 즉흥과 창조가 되기도 한다.</li></ul><div class="obsidian-callout obsidian-callout--note" data-callout="note">  <div class="obsidian-callout__title">    <span class="obsidian-callout__icon" aria-hidden="true">■</span>    <strong>저작권 처리</strong>  </div>  <div class="obsidian-callout__body"><p>이 글은 원문을 길게 옮기지 않고, 핵심 개념을 한국어 해설과 적용 질문으로 재구성한 변형적 책노트입니다.</p></div></div><h2 id="L1-·-발췌함-대신-개념-단서"><a href="#L1-·-발췌함-대신-개념-단서" class="headerlink" title="L1 · 발췌함 대신 개념 단서"></a>L1 · 발췌함 대신 개념 단서</h2><ul><li><strong>개념 단서</strong>: 창조는 반복을 버리는 것이 아니라 반복을 다르게 쓰는 것이다</li><li><strong>맥락 단서</strong>: 일관성과 통일성은 다르다</li><li><strong>적용 단서</strong>: 좋은 즉흥은 자유와 제약을 동시에 다룬다</li></ul><h2 id="L2-·-챕터-지도"><a href="#L2-·-챕터-지도" class="headerlink" title="L2 · 챕터 지도"></a>L2 · 챕터 지도</h2><p>홀랜드는 재즈의 예를 통해 차이와 반복을 설명한다. 악기를 배울 때는 스케일을 반복한다. 이것은 필요한 훈련이지만 차이가 적다. 반면 즉흥연주는 익숙한 구조 위에서 매번 다른 길을 만든다.</p><p>여기서 탈영토화의 정도가 달라진다. 익숙한 코드 안에서 변주하는 것은 상대적 탈영토화에 가깝다. 아예 조성, 곡, 진행을 넘어서는 움직임은 절대적 탈영토화에 가까워진다.</p><p>중요한 것은 무질서가 아니다. 들뢰즈와 가타리가 찾는 것은 통일성을 강요하지 않으면서도 일관성을 유지하는 방식이다. 재즈는 이 점을 감각적으로 보여준다.</p><h2 id="L3-·-인사이트-카드"><a href="#L3-·-인사이트-카드" class="headerlink" title="L3 · 인사이트 카드"></a>L3 · 인사이트 카드</h2><ul><li>A Thousand Plateaus - I7.1 창조는 반복을 버리는 것이 아니라 반복을 다르게 쓰는 것이다</li><li>A Thousand Plateaus - I7.2 일관성과 통일성은 다르다</li><li>A Thousand Plateaus - I7.3 좋은 즉흥은 자유와 제약을 동시에 다룬다</li></ul><h2 id="L4-·-생산-보드"><a href="#L4-·-생산-보드" class="headerlink" title="L4 · 생산 보드"></a>L4 · 생산 보드</h2><div class="obsidian-callout obsidian-callout--todo" data-callout="todo">  <div class="obsidian-callout__title">    <span class="obsidian-callout__icon" aria-hidden="true">■</span>    <strong>오늘 적용할 실험</strong>  </div>  <div class="obsidian-callout__body"><p><ul><li><input disabled="" type="checkbox"> 내가 반복하는 루틴 중 차이가 거의 없는 것을 하나 고른다.</li><li><input disabled="" type="checkbox"> 그 루틴에 작은 변주를 넣어도 유지되는 핵심을 찾는다.</li><li><input disabled="" type="checkbox"> 일관성은 있지만 통일적이지 않은 사례를 찾아본다.</li></ul></div></div><h2 id="L5-·-연결-복습"><a href="#L5-·-연결-복습" class="headerlink" title="L5 · 연결 &amp; 복습"></a>L5 · 연결 &amp; 복습</h2><ul><li><strong>연결 개념</strong>: 리좀, 탈영토화, 배치, 차이와 반복</li><li><strong>복습 질문</strong>:<ul><li>이 섹션의 개념을 개인 심리 문제가 아니라 관계와 배치의 문제로 다시 설명하면 어떻게 달라지는가?</li><li>오늘 읽은 개념은 기존의 상식적 분류를 어디에서 흔드는가?</li><li>이 개념을 내 글쓰기, 수업, 프로젝트 설계에 적용하면 무엇을 다르게 보게 되는가?</li></ul></li></ul><p><strong>한 문장 최종 정리</strong>: 반복은 같은 것을 되풀이하는 일이 아니다. 반복 속에 차이가 얼마나 들어오느냐에 따라 습관이 되기도 하고, 즉흥과 창조가 되기도 한다.</p>]]>
    </content>
    <id>https://reasonofmoon.github.io/2026/06/27/book-note-thousand-plateaus-reader-guide-ch1-sec07-repetition-jazz/</id>
    <link href="https://reasonofmoon.github.io/2026/06/27/book-note-thousand-plateaus-reader-guide-ch1-sec07-repetition-jazz/"/>
    <published>2026-06-27T05:58:00.000Z</published>
    <summary>차이와 반복, 즉흥연주, 상대적/절대적 탈영토화를 통해 들뢰즈식 사유의 리듬을 이해합니다.</summary>
    <title>책노트: A Thousand Plateaus Reader's Guide 1-7 - 반복 속 차이, 재즈처럼 생각하기</title>
    <updated>2026-06-27T05:58:00.000Z</updated>
  </entry>
  <entry>
    <author>
      <name>Reasonofmoon</name>
    </author>
    <category term="Book" scheme="https://reasonofmoon.github.io/categories/Book/"/>
    <category term="독서" scheme="https://reasonofmoon.github.io/tags/%EB%8F%85%EC%84%9C/"/>
    <category term="책노트" scheme="https://reasonofmoon.github.io/tags/%EC%B1%85%EB%85%B8%ED%8A%B8/"/>
    <category term="독서/책노트" scheme="https://reasonofmoon.github.io/tags/%EB%8F%85%EC%84%9C-%EC%B1%85%EB%85%B8%ED%8A%B8/"/>
    <category term="Book Notes" scheme="https://reasonofmoon.github.io/tags/Book-Notes/"/>
    <category term="The Design of Everyday Things" scheme="https://reasonofmoon.github.io/tags/The-Design-of-Everyday-Things/"/>
    <category term="UX" scheme="https://reasonofmoon.github.io/tags/UX/"/>
    <category term="UI" scheme="https://reasonofmoon.github.io/tags/UI/"/>
    <category term="Product Design" scheme="https://reasonofmoon.github.io/tags/Product-Design/"/>
    <category term="Frontend" scheme="https://reasonofmoon.github.io/tags/Frontend/"/>
    <content>
      <![CDATA[<h1 id="The-Design-of-Everyday-Things-5회차-좋은-UX는-예쁜-화면이-아니라-반복-가능한-의사결정-시스템이다"><a href="#The-Design-of-Everyday-Things-5회차-좋은-UX는-예쁜-화면이-아니라-반복-가능한-의사결정-시스템이다" class="headerlink" title="The Design of Everyday Things 5회차 - 좋은 UX는 예쁜 화면이 아니라 반복 가능한 의사결정 시스템이다"></a>The Design of Everyday Things 5회차 - 좋은 UX는 예쁜 화면이 아니라 반복 가능한 의사결정 시스템이다</h1><p>The Design of Everyday Things는 문손잡이와 스위치 이야기로 유명하지만, UX&#x2F;UI를 다루는 개발자에게는 훨씬 실질적인 책이다. 이 책은 “사용자가 왜 헤매는가”를 심리학, 제품 구조, 피드백, 오류 회복, 조직 의사결정의 문제로 나누어 보게 한다.</p><p>이번 글의 질문은 이것이다. <strong>좋은 설계 원칙은 왜 실제 제품 조직에서 자주 밀리는가?</strong></p><p><img src="/images/scribble-covers/book-note-design-everyday-things.svg" alt="The Design of Everyday Things cover"></p><div class="obsidian-callout obsidian-callout--abstract" data-callout="abstract">  <div class="obsidian-callout__title">    <span class="obsidian-callout__icon" aria-hidden="true">■</span>    <strong>이 노트의 사용법</strong>  </div>  <div class="obsidian-callout__body"><p>이 글은 5회로 읽는 <code>The Design of Everyday Things</code> 시리즈의 5회차다. 범위는 <strong>6장 Design Thinking, 7장 Design in the World of Business</strong>이다.</p><p>포착 -&gt; 증류 -&gt; 연결 -&gt; 표현 4단계 깔때기로 UX 원칙을 개발자의 설계 판단으로 바꾼다. 핵심 원칙은 같다. <strong>책 노트는 창고, 인사이트 카드는 화폐.</strong></p></div></div><h2 id="L0-·-서지-진입"><a href="#L0-·-서지-진입" class="headerlink" title="L0 · 서지 &amp; 진입"></a>L0 · 서지 &amp; 진입</h2><ul><li><strong>한 문장 핵심</strong>: 디자인은 한 번의 천재적 해결이 아니라 관찰, 문제 재정의, 실험, 제약 조정이 반복되는 조직적 루프다.</li><li><strong>이 책을 든 이유 &#x2F; 기대한 질문</strong>: UX&#x2F;UI 개발을 “디자인 전달받기”가 아니라 제품의 행동 문법을 구현하는 일로 보기 위해 읽는다.</li><li><strong>읽기 전 가설</strong>: UX를 디자이너의 산출물로만 보면 개발자는 뒤늦게 구현자가 된다. 이 회차는 UX를 제품 의사결정 시스템으로 보게 한다.</li><li><strong>저자 한 줄 컨텍스트</strong>: Don Norman은 인지과학, 인간-컴퓨터 상호작용, 사용자 중심 설계 분야를 대중적 언어로 연결한 연구자이자 설계 사상가다.</li><li><strong>이번 회차 범위</strong>: 6장 Design Thinking, 7장 Design in the World of Business</li><li><strong>관련 도서 &#x2F; 계보</strong>: A Philosophy of Software Design · The Pragmatic Programmer · A Theory of Fun for Game Design · Design System</li></ul><h2 id="L1-·-포착함"><a href="#L1-·-포착함" class="headerlink" title="L1 · 포착함"></a>L1 · 포착함</h2><div class="obsidian-callout obsidian-callout--quote" data-callout="quote">  <div class="obsidian-callout__title">    <span class="obsidian-callout__icon" aria-hidden="true">“</span>    <strong>짧은 핵심어 · #ux</strong>  </div>  <div class="obsidian-callout__body"><p>“design thinking”</p><ul><li><strong>왜 표시했나</strong>: 문제를 다시 정의하고 실험으로 검증하는 과정이다. ^q01</li><li><strong>개발자 반응</strong>: 정답을 바로 구현하기보다 문제가 무엇인지 계속 좁혀간다.</li></ul></div></div><div class="obsidian-callout obsidian-callout--quote" data-callout="quote">  <div class="obsidian-callout__title">    <span class="obsidian-callout__icon" aria-hidden="true">“</span>    <strong>짧은 핵심어 · #ux</strong>  </div>  <div class="obsidian-callout__body"><p>“double diamond”</p><ul><li><strong>왜 표시했나</strong>: 발산과 수렴을 반복하는 문제 해결 구조다. ^q02</li><li><strong>개발자 반응</strong>: 요구사항을 바로 티켓으로 만들기 전에 관찰과 재정의가 필요하다.</li></ul></div></div><div class="obsidian-callout obsidian-callout--quote" data-callout="quote">  <div class="obsidian-callout__title">    <span class="obsidian-callout__icon" aria-hidden="true">“</span>    <strong>짧은 핵심어 · #ux</strong>  </div>  <div class="obsidian-callout__body"><p>“business constraints”</p><ul><li><strong>왜 표시했나</strong>: 좋은 설계를 흔드는 현실 조건이다. ^q03</li><li><strong>개발자 반응</strong>: 일정, 비용, 레거시, 마케팅, 조직 정치가 UX 결정에 영향을 준다.</li></ul></div></div><div class="obsidian-callout obsidian-callout--note" data-callout="note">  <div class="obsidian-callout__title">    <span class="obsidian-callout__icon" aria-hidden="true">■</span>    <strong>저작권 경계</strong>  </div>  <div class="obsidian-callout__body"><p>이 공개 노트는 책의 장문 문장을 재현하지 않는다. 장 제목과 짧은 핵심어만 단서로 삼고, 내용은 UX&#x2F;UI 개발자의 실무 해석과 적용 중심으로 재구성한다.</p></div></div><h2 id="L2-·-챕터-지도"><a href="#L2-·-챕터-지도" class="headerlink" title="L2 · 챕터 지도"></a>L2 · 챕터 지도</h2><table><thead><tr><th>단위</th><th>내가 붙인 이름</th><th>핵심 주장</th><th>개발자 적용</th></tr></thead><tbody><tr><td>디자인 사고</td><td>문제 발견과 해결의 반복</td><td>처음 정의한 문제는 대개 틀렸거나 좁다</td><td>티켓 구현 전 문제 가설을 문서화한다</td></tr><tr><td>프로토타입</td><td>생각을 빠르게 외부화</td><td>완성도보다 학습 속도가 중요하다</td><td>Figma, 스토리북, 더미 데이터로 실험한다</td></tr><tr><td>조직 제약</td><td>비즈니스와 일정의 압력</td><td>좋은 UX도 현실 조건 안에서 설계되어야 한다</td><td>MVP와 후속 개선 루프를 분리한다</td></tr><tr><td>디자인 시스템</td><td>반복 가능한 판단의 축적</td><td>개별 화면보다 의사결정 규칙이 중요하다</td><td>컴포넌트 문서에 사용 의도와 금지 사례를 포함한다</td></tr></tbody></table><p><strong>이번 회차 논증 한 단락</strong>:</p><blockquote><p>마지막 회차는 좋은 원칙이 왜 실제 제품 안에서 흔들리는지를 보여준다. 사용자를 관찰하고, 문제를 재정의하고, 프로토타입을 만들고, 검증하는 과정은 이상적으로 보인다. 그러나 실제 팀에는 일정, 예산, 레거시 코드, 출시 압박, 이해관계자가 있다. 그래서 UX는 예쁜 결과물을 만드는 일이 아니라 제약 속에서 판단을 반복하는 시스템이 되어야 한다. 개발자에게 이 회차가 중요한 이유는 분명하다. 프론트엔드 개발자는 디자인의 끝에서 구현만 하는 사람이 아니다. 상태 모델, 컴포넌트 경계, 에러 처리, 접근성, 성능, 실험 가능성은 모두 UX의 일부다. 개발자가 설계 대화에 늦게 들어가면, 사용성 문제는 코드가 거의 굳은 뒤 발견된다. 좋은 팀은 디자인과 개발을 순서가 아니라 루프로 연결한다.</p></blockquote><h2 id="L3-·-인사이트-카드-색인"><a href="#L3-·-인사이트-카드-색인" class="headerlink" title="L3 · 인사이트 카드 색인"></a>L3 · 인사이트 카드 색인</h2><ul><li>The Design of Everyday Things - I5.1 UX는 산출물이 아니라 학습 루프다 — 좋은 팀은 요구사항을 빠르게 구현하는 팀이 아니라, 문제 정의가 틀렸을 때 빨리 알아차리는 팀이다.</li><li>The Design of Everyday Things - I5.2 디자인 시스템은 화면 공장이 아니라 판단의 메모리다 — 컴포넌트가 왜 그렇게 생겼고 언제 쓰면 안 되는지 남겨야 조직의 설계 품질이 누적된다.</li><li>The Design of Everyday Things - I5.3 비즈니스 제약을 무시한 UX 원칙은 제품을 바꾸지 못한다 — 현실의 제약을 설계 입력으로 삼을 때 원칙은 구호가 아니라 전략이 된다.</li></ul><h2 id="L4-·-생산-보드"><a href="#L4-·-생산-보드" class="headerlink" title="L4 · 생산 보드"></a>L4 · 생산 보드</h2><div class="obsidian-callout obsidian-callout--todo" data-callout="todo">  <div class="obsidian-callout__title">    <span class="obsidian-callout__icon" aria-hidden="true">■</span>    <strong>출력 파이프라인</strong>  </div>  <div class="obsidian-callout__body"><p><ul><li><input checked="" disabled="" type="checkbox"> <strong>블로그 초안</strong>: 5회차를 UX&#x2F;UI 개발자 관점으로 정리</li><li><input disabled="" type="checkbox"> <strong>코드 리뷰 질문</strong>: 좋은 설계 원칙은 왜 실제 제품 조직에서 자주 밀리는가?</li><li><input disabled="" type="checkbox"> <strong>디자인 시스템 카드</strong>: The Design of Everyday Things - I5.1 UX는 산출물이 아니라 학습 루프다</li><li><input disabled="" type="checkbox"> <strong>적용 실험</strong>: 최근 만든 화면 하나에 이 회차의 기준을 적용해 보기</li></ul></div></div><h3 id="바로-적용할-체크리스트"><a href="#바로-적용할-체크리스트" class="headerlink" title="바로 적용할 체크리스트"></a>바로 적용할 체크리스트</h3><ul><li>기능 티켓마다 <code>사용자 문제</code>, <code>성공 기준</code>, <code>실패 가능성</code>, <code>측정 방법</code>을 짧게 적는다.</li><li>스토리북 문서에 사용 예시뿐 아니라 “쓰면 안 되는 상황”을 함께 기록한다.</li><li>출시 후 1주 안에 행동 로그, 오류 로그, CS, 사용자 피드백을 묶어 UX 회고를 진행한다.</li></ul><h2 id="L5-·-연결-복습"><a href="#L5-·-연결-복습" class="headerlink" title="L5 · 연결 &amp; 복습"></a>L5 · 연결 &amp; 복습</h2><ul><li><strong>다른 책&#x2F;아이디어와의 연결</strong>: 이 회차는 A Philosophy of Software Design의 인지 부하 관점과 이어진다. 차이는 코드 내부 복잡성보다 사용자의 행동 복잡성을 다룬다는 점이다.</li><li><strong>미해결 질문</strong>:<ul><li>우리 제품에서 사용자가 가장 자주 “멈추는” 화면은 어디인가?</li><li>그 문제는 교육, 문서, CS로 해결할 일인가, 아니면 화면의 단서와 피드백을 고칠 일인가?</li><li>디자인 시스템에 이 회차의 원칙을 어떤 컴포넌트 계약으로 넣을 수 있을까?</li></ul></li><li><strong>복습 일정</strong>: 1주 □ &#x2F; 1개월 □ &#x2F; 3개월 □</li><li><strong>한 문장 최종 정리</strong>: 좋은 UX는 한 번의 멋진 화면이 아니라, 팀이 계속 더 나은 판단을 하게 만드는 반복 가능한 시스템이다.</li></ul><h2 id="다음-회차"><a href="#다음-회차" class="headerlink" title="다음 회차"></a>다음 회차</h2><ul><li>이전: <a href="/2026/06/27/book-note-design-everyday-things-part-4-error-recovery/">4회차</a></li><li>다음: <a href="/2026/06/27/book-note-design-everyday-things-part-1-discoverability/">1회차</a></li><li>책장으로 돌아가기: <a href="/book/">&#x2F;book</a></li></ul>]]>
    </content>
    <id>https://reasonofmoon.github.io/2026/06/27/book-note-design-everyday-things-part-5-design-thinking-business/</id>
    <link href="https://reasonofmoon.github.io/2026/06/27/book-note-design-everyday-things-part-5-design-thinking-business/"/>
    <published>2026-06-27T04:05:00.000Z</published>
    <summary>디자인 사고와 비즈니스 현실을 개발자 조직의 제품 루프, 디자인 시스템, 출시 의사결정으로 연결한다.</summary>
    <title>책노트: The Design of Everyday Things 5회차 - 좋은 UX는 예쁜 화면이 아니라 반복 가능한 의사결정 시스템이다</title>
    <updated>2026-06-27T04:05:00.000Z</updated>
  </entry>
  <entry>
    <author>
      <name>Reasonofmoon</name>
    </author>
    <category term="Book" scheme="https://reasonofmoon.github.io/categories/Book/"/>
    <category term="독서" scheme="https://reasonofmoon.github.io/tags/%EB%8F%85%EC%84%9C/"/>
    <category term="책노트" scheme="https://reasonofmoon.github.io/tags/%EC%B1%85%EB%85%B8%ED%8A%B8/"/>
    <category term="독서/책노트" scheme="https://reasonofmoon.github.io/tags/%EB%8F%85%EC%84%9C-%EC%B1%85%EB%85%B8%ED%8A%B8/"/>
    <category term="Book Notes" scheme="https://reasonofmoon.github.io/tags/Book-Notes/"/>
    <category term="The Design of Everyday Things" scheme="https://reasonofmoon.github.io/tags/The-Design-of-Everyday-Things/"/>
    <category term="UX" scheme="https://reasonofmoon.github.io/tags/UX/"/>
    <category term="UI" scheme="https://reasonofmoon.github.io/tags/UI/"/>
    <category term="Product Design" scheme="https://reasonofmoon.github.io/tags/Product-Design/"/>
    <category term="Frontend" scheme="https://reasonofmoon.github.io/tags/Frontend/"/>
    <content>
      <![CDATA[<h1 id="The-Design-of-Everyday-Things-4회차-오류-메시지는-사과문이-아니라-구조-개선의-증거여야-한다"><a href="#The-Design-of-Everyday-Things-4회차-오류-메시지는-사과문이-아니라-구조-개선의-증거여야-한다" class="headerlink" title="The Design of Everyday Things 4회차 - 오류 메시지는 사과문이 아니라 구조 개선의 증거여야 한다"></a>The Design of Everyday Things 4회차 - 오류 메시지는 사과문이 아니라 구조 개선의 증거여야 한다</h1><p>The Design of Everyday Things는 문손잡이와 스위치 이야기로 유명하지만, UX&#x2F;UI를 다루는 개발자에게는 훨씬 실질적인 책이다. 이 책은 “사용자가 왜 헤매는가”를 심리학, 제품 구조, 피드백, 오류 회복, 조직 의사결정의 문제로 나누어 보게 한다.</p><p>이번 글의 질문은 이것이다. <strong>사용자가 실수했을 때, 우리는 누구를 고치려 하는가?</strong></p><p><img src="/images/scribble-covers/book-note-design-everyday-things.svg" alt="The Design of Everyday Things cover"></p><div class="obsidian-callout obsidian-callout--abstract" data-callout="abstract">  <div class="obsidian-callout__title">    <span class="obsidian-callout__icon" aria-hidden="true">■</span>    <strong>이 노트의 사용법</strong>  </div>  <div class="obsidian-callout__body"><p>이 글은 5회로 읽는 <code>The Design of Everyday Things</code> 시리즈의 4회차다. 범위는 <strong>5장 Human Error? No, Bad Design</strong>이다.</p><p>포착 -&gt; 증류 -&gt; 연결 -&gt; 표현 4단계 깔때기로 UX 원칙을 개발자의 설계 판단으로 바꾼다. 핵심 원칙은 같다. <strong>책 노트는 창고, 인사이트 카드는 화폐.</strong></p></div></div><h2 id="L0-·-서지-진입"><a href="#L0-·-서지-진입" class="headerlink" title="L0 · 서지 &amp; 진입"></a>L0 · 서지 &amp; 진입</h2><ul><li><strong>한 문장 핵심</strong>: 사용자 오류는 개인의 부주의가 아니라 시스템이 실수를 유도하거나 회복을 어렵게 만든 결과일 수 있다.</li><li><strong>이 책을 든 이유 &#x2F; 기대한 질문</strong>: UX&#x2F;UI 개발을 “디자인 전달받기”가 아니라 제품의 행동 문법을 구현하는 일로 보기 위해 읽는다.</li><li><strong>읽기 전 가설</strong>: 에러 처리를 예외 상황으로만 보면 UX의 절반을 놓친다. 오류는 실제 사용 환경에서 가장 중요한 설계 표면이다.</li><li><strong>저자 한 줄 컨텍스트</strong>: Don Norman은 인지과학, 인간-컴퓨터 상호작용, 사용자 중심 설계 분야를 대중적 언어로 연결한 연구자이자 설계 사상가다.</li><li><strong>이번 회차 범위</strong>: 5장 Human Error? No, Bad Design</li><li><strong>관련 도서 &#x2F; 계보</strong>: A Philosophy of Software Design · The Pragmatic Programmer · A Theory of Fun for Game Design · Design System</li></ul><h2 id="L1-·-포착함"><a href="#L1-·-포착함" class="headerlink" title="L1 · 포착함"></a>L1 · 포착함</h2><div class="obsidian-callout obsidian-callout--quote" data-callout="quote">  <div class="obsidian-callout__title">    <span class="obsidian-callout__icon" aria-hidden="true">“</span>    <strong>짧은 핵심어 · #ux</strong>  </div>  <div class="obsidian-callout__body"><p>“human error”</p><ul><li><strong>왜 표시했나</strong>: 사람 탓으로 보이는 시스템 문제다. ^q01</li><li><strong>개발자 반응</strong>: 반복되는 실수는 교육 부족이 아니라 인터페이스 구조 문제로 봐야 한다.</li></ul></div></div><div class="obsidian-callout obsidian-callout--quote" data-callout="quote">  <div class="obsidian-callout__title">    <span class="obsidian-callout__icon" aria-hidden="true">“</span>    <strong>짧은 핵심어 · #ux</strong>  </div>  <div class="obsidian-callout__body"><p>“slips and mistakes”</p><ul><li><strong>왜 표시했나</strong>: 실행 실수와 판단 실수를 구분한다. ^q02</li><li><strong>개발자 반응</strong>: 잘못 눌렀는지, 잘못 이해했는지에 따라 해결책이 달라진다.</li></ul></div></div><div class="obsidian-callout obsidian-callout--quote" data-callout="quote">  <div class="obsidian-callout__title">    <span class="obsidian-callout__icon" aria-hidden="true">“</span>    <strong>짧은 핵심어 · #ux</strong>  </div>  <div class="obsidian-callout__body"><p>“forcing function”</p><ul><li><strong>왜 표시했나</strong>: 위험한 행동을 안전하게 제한하는 장치다. ^q03</li><li><strong>개발자 반응</strong>: 삭제 확인, 의존성 검사, 단계 잠금, undo 가능성이 여기에 속한다.</li></ul></div></div><div class="obsidian-callout obsidian-callout--note" data-callout="note">  <div class="obsidian-callout__title">    <span class="obsidian-callout__icon" aria-hidden="true">■</span>    <strong>저작권 경계</strong>  </div>  <div class="obsidian-callout__body"><p>이 공개 노트는 책의 장문 문장을 재현하지 않는다. 장 제목과 짧은 핵심어만 단서로 삼고, 내용은 UX&#x2F;UI 개발자의 실무 해석과 적용 중심으로 재구성한다.</p></div></div><h2 id="L2-·-챕터-지도"><a href="#L2-·-챕터-지도" class="headerlink" title="L2 · 챕터 지도"></a>L2 · 챕터 지도</h2><table><thead><tr><th>단위</th><th>내가 붙인 이름</th><th>핵심 주장</th><th>개발자 적용</th></tr></thead><tbody><tr><td>오류 관점</td><td>사람 탓에서 설계 탓으로</td><td>반복 오류는 시스템이 만든 패턴이다</td><td>CS 로그와 프론트 오류 로그를 UX 개선 입력으로 본다</td></tr><tr><td>실행 실수</td><td>하려던 행동과 다른 행동</td><td>근접 버튼, 모호한 아이콘, 작은 터치 영역이 원인이 된다</td><td>위험 버튼 위치와 색, 확인 단계를 재설계한다</td></tr><tr><td>판단 실수</td><td>상황을 잘못 이해한 행동</td><td>개념모형과 설명이 틀렸을 때 생긴다</td><td>에러 메시지는 원인과 다음 행동을 함께 말한다</td></tr><tr><td>회복</td><td>되돌릴 수 있는 시스템</td><td>완벽한 예방보다 빠른 복구가 더 현실적일 때가 많다</td><td>undo, draft, autosave, history를 제공한다</td></tr></tbody></table><p><strong>이번 회차 논증 한 단락</strong>:</p><blockquote><p>개발자는 오류를 try-catch, validation, exception handling으로 생각하기 쉽다. 하지만 UX에서 오류는 단순한 예외가 아니다. 사용자가 시스템을 실제로 이해하는 방식이 드러나는 순간이다. 같은 오류가 반복된다면, 그 오류는 사용자 교육 문제가 아니라 제품의 언어와 구조가 만든 결과일 수 있다. 이 회차를 실무로 옮기면 에러 메시지의 기준이 바뀐다. “오류가 발생했습니다”는 사과처럼 보이지만 아무것도 해결하지 못한다. 좋은 오류 설계는 무엇이 잘못되었는지, 왜 막혔는지, 사용자가 지금 무엇을 할 수 있는지, 데이터는 안전한지까지 알려준다. 더 좋은 설계는 애초에 그 오류가 생기기 어려운 흐름을 만든다.</p></blockquote><h2 id="L3-·-인사이트-카드-색인"><a href="#L3-·-인사이트-카드-색인" class="headerlink" title="L3 · 인사이트 카드 색인"></a>L3 · 인사이트 카드 색인</h2><ul><li>The Design of Everyday Things - I4.1 오류 메시지는 시스템의 자기 진단서다 — 에러 문구가 반복되면 그것은 사용자에게 더 친절하게 말할 문제가 아니라 흐름 자체를 바꿀 문제다.</li><li>The Design of Everyday Things - I4.2 실수 방지는 검증 로직보다 행동 경로 설계에 가깝다 — 좋은 검증은 제출 후 빨간 글씨가 아니라, 실수하기 어려운 기본 경로를 만든다.</li><li>The Design of Everyday Things - I4.3 복구 가능성은 고급 기능이 아니라 신뢰 기능이다 — 되돌릴 수 없다는 두려움은 사용자를 소극적으로 만들고, 제품의 탐색 가능성을 낮춘다.</li></ul><h2 id="L4-·-생산-보드"><a href="#L4-·-생산-보드" class="headerlink" title="L4 · 생산 보드"></a>L4 · 생산 보드</h2><div class="obsidian-callout obsidian-callout--todo" data-callout="todo">  <div class="obsidian-callout__title">    <span class="obsidian-callout__icon" aria-hidden="true">■</span>    <strong>출력 파이프라인</strong>  </div>  <div class="obsidian-callout__body"><p><ul><li><input checked="" disabled="" type="checkbox"> <strong>블로그 초안</strong>: 4회차를 UX&#x2F;UI 개발자 관점으로 정리</li><li><input disabled="" type="checkbox"> <strong>코드 리뷰 질문</strong>: 사용자가 실수했을 때, 우리는 누구를 고치려 하는가?</li><li><input disabled="" type="checkbox"> <strong>디자인 시스템 카드</strong>: The Design of Everyday Things - I4.1 오류 메시지는 시스템의 자기 진단서다</li><li><input disabled="" type="checkbox"> <strong>적용 실험</strong>: 최근 만든 화면 하나에 이 회차의 기준을 적용해 보기</li></ul></div></div><h3 id="바로-적용할-체크리스트"><a href="#바로-적용할-체크리스트" class="headerlink" title="바로 적용할 체크리스트"></a>바로 적용할 체크리스트</h3><ul><li>오류를 <code>실행 실수</code>, <code>이해 실수</code>, <code>시스템 실패</code>, <code>권한/상태 불일치</code>로 분류해 문구와 복구 방법을 다르게 설계한다.</li><li>파괴적 행동에는 undo 또는 지연 삭제를 우선 검토하고, 불가능할 때만 강한 확인을 둔다.</li><li>에러 로그와 사용자 세션 리플레이를 “버그 수정”뿐 아니라 “단서 개선” 회의의 입력으로 사용한다.</li></ul><h2 id="L5-·-연결-복습"><a href="#L5-·-연결-복습" class="headerlink" title="L5 · 연결 &amp; 복습"></a>L5 · 연결 &amp; 복습</h2><ul><li><strong>다른 책&#x2F;아이디어와의 연결</strong>: 이 회차는 A Philosophy of Software Design의 인지 부하 관점과 이어진다. 차이는 코드 내부 복잡성보다 사용자의 행동 복잡성을 다룬다는 점이다.</li><li><strong>미해결 질문</strong>:<ul><li>우리 제품에서 사용자가 가장 자주 “멈추는” 화면은 어디인가?</li><li>그 문제는 교육, 문서, CS로 해결할 일인가, 아니면 화면의 단서와 피드백을 고칠 일인가?</li><li>디자인 시스템에 이 회차의 원칙을 어떤 컴포넌트 계약으로 넣을 수 있을까?</li></ul></li><li><strong>복습 일정</strong>: 1주 □ &#x2F; 1개월 □ &#x2F; 3개월 □</li><li><strong>한 문장 최종 정리</strong>: 사용자 오류를 줄이는 가장 좋은 방법은 사용자를 더 조심시키는 것이 아니라, 실수하기 어려운 세계를 만드는 것이다.</li></ul><h2 id="다음-회차"><a href="#다음-회차" class="headerlink" title="다음 회차"></a>다음 회차</h2><ul><li>이전: <a href="/2026/06/27/book-note-design-everyday-things-part-3-knowledge-mapping/">3회차</a></li><li>다음: <a href="/2026/06/27/book-note-design-everyday-things-part-5-design-thinking-business/">5회차</a></li><li>책장으로 돌아가기: <a href="/book/">&#x2F;book</a></li></ul>]]>
    </content>
    <id>https://reasonofmoon.github.io/2026/06/27/book-note-design-everyday-things-part-4-error-recovery/</id>
    <link href="https://reasonofmoon.github.io/2026/06/27/book-note-design-everyday-things-part-4-error-recovery/"/>
    <published>2026-06-27T04:00:00.000Z</published>
    <summary>인간 오류를 나쁜 설계의 증상으로 읽고, 프론트엔드 오류 방지·복구·관찰 가능성 설계로 변환한다.</summary>
    <title>책노트: The Design of Everyday Things 4회차 - 오류 메시지는 사과문이 아니라 구조 개선의 증거여야 한다</title>
    <updated>2026-06-27T04:00:00.000Z</updated>
  </entry>
  <entry>
    <author>
      <name>Reasonofmoon</name>
    </author>
    <category term="Book" scheme="https://reasonofmoon.github.io/categories/Book/"/>
    <category term="독서" scheme="https://reasonofmoon.github.io/tags/%EB%8F%85%EC%84%9C/"/>
    <category term="책노트" scheme="https://reasonofmoon.github.io/tags/%EC%B1%85%EB%85%B8%ED%8A%B8/"/>
    <category term="독서/책노트" scheme="https://reasonofmoon.github.io/tags/%EB%8F%85%EC%84%9C-%EC%B1%85%EB%85%B8%ED%8A%B8/"/>
    <category term="Book Notes" scheme="https://reasonofmoon.github.io/tags/Book-Notes/"/>
    <category term="The Design of Everyday Things" scheme="https://reasonofmoon.github.io/tags/The-Design-of-Everyday-Things/"/>
    <category term="UX" scheme="https://reasonofmoon.github.io/tags/UX/"/>
    <category term="UI" scheme="https://reasonofmoon.github.io/tags/UI/"/>
    <category term="Product Design" scheme="https://reasonofmoon.github.io/tags/Product-Design/"/>
    <category term="Frontend" scheme="https://reasonofmoon.github.io/tags/Frontend/"/>
    <content>
      <![CDATA[<h1 id="The-Design-of-Everyday-Things-3회차-기억하게-만들지-말고-보이게-하라"><a href="#The-Design-of-Everyday-Things-3회차-기억하게-만들지-말고-보이게-하라" class="headerlink" title="The Design of Everyday Things 3회차 - 기억하게 만들지 말고 보이게 하라"></a>The Design of Everyday Things 3회차 - 기억하게 만들지 말고 보이게 하라</h1><p>The Design of Everyday Things는 문손잡이와 스위치 이야기로 유명하지만, UX&#x2F;UI를 다루는 개발자에게는 훨씬 실질적인 책이다. 이 책은 “사용자가 왜 헤매는가”를 심리학, 제품 구조, 피드백, 오류 회복, 조직 의사결정의 문제로 나누어 보게 한다.</p><p>이번 글의 질문은 이것이다. <strong>사용자가 기억해야 하는 것을 UI가 대신 떠받칠 수는 없을까?</strong></p><p><img src="/images/scribble-covers/book-note-design-everyday-things.svg" alt="The Design of Everyday Things cover"></p><div class="obsidian-callout obsidian-callout--abstract" data-callout="abstract">  <div class="obsidian-callout__title">    <span class="obsidian-callout__icon" aria-hidden="true">■</span>    <strong>이 노트의 사용법</strong>  </div>  <div class="obsidian-callout__body"><p>이 글은 5회로 읽는 <code>The Design of Everyday Things</code> 시리즈의 3회차다. 범위는 <strong>3장 Knowledge in the Head and in the World, 4장 Knowing What to Do</strong>이다.</p><p>포착 -&gt; 증류 -&gt; 연결 -&gt; 표현 4단계 깔때기로 UX 원칙을 개발자의 설계 판단으로 바꾼다. 핵심 원칙은 같다. <strong>책 노트는 창고, 인사이트 카드는 화폐.</strong></p></div></div><h2 id="L0-·-서지-진입"><a href="#L0-·-서지-진입" class="headerlink" title="L0 · 서지 &amp; 진입"></a>L0 · 서지 &amp; 진입</h2><ul><li><strong>한 문장 핵심</strong>: 좋은 인터페이스는 사용자의 기억 부담을 줄이고, 필요한 지식을 적절한 순간 화면과 구조 안에 배치한다.</li><li><strong>이 책을 든 이유 &#x2F; 기대한 질문</strong>: UX&#x2F;UI 개발을 “디자인 전달받기”가 아니라 제품의 행동 문법을 구현하는 일로 보기 위해 읽는다.</li><li><strong>읽기 전 가설</strong>: 사용법 문서와 튜토리얼로 해결하려는 습관은 UI가 세계 속 지식을 충분히 제공하지 못한다는 신호일 수 있다.</li><li><strong>저자 한 줄 컨텍스트</strong>: Don Norman은 인지과학, 인간-컴퓨터 상호작용, 사용자 중심 설계 분야를 대중적 언어로 연결한 연구자이자 설계 사상가다.</li><li><strong>이번 회차 범위</strong>: 3장 Knowledge in the Head and in the World, 4장 Knowing What to Do</li><li><strong>관련 도서 &#x2F; 계보</strong>: A Philosophy of Software Design · The Pragmatic Programmer · A Theory of Fun for Game Design · Design System</li></ul><h2 id="L1-·-포착함"><a href="#L1-·-포착함" class="headerlink" title="L1 · 포착함"></a>L1 · 포착함</h2><div class="obsidian-callout obsidian-callout--quote" data-callout="quote">  <div class="obsidian-callout__title">    <span class="obsidian-callout__icon" aria-hidden="true">“</span>    <strong>짧은 핵심어 · #ux</strong>  </div>  <div class="obsidian-callout__body"><p>“knowledge in the world”</p><ul><li><strong>왜 표시했나</strong>: 환경 안에 놓인 기억 장치다. ^q01</li><li><strong>개발자 반응</strong>: 라벨, 위치, 순서, 예시, 기본값, 제약이 사용자의 기억을 대신한다.</li></ul></div></div><div class="obsidian-callout obsidian-callout--quote" data-callout="quote">  <div class="obsidian-callout__title">    <span class="obsidian-callout__icon" aria-hidden="true">“</span>    <strong>짧은 핵심어 · #ux</strong>  </div>  <div class="obsidian-callout__body"><p>“mapping”</p><ul><li><strong>왜 표시했나</strong>: 조작과 결과 사이의 관계다. ^q02</li><li><strong>개발자 반응</strong>: 슬라이더 방향, 테이블 정렬, 필터 위치처럼 결과를 예측하게 만드는 연결이다.</li></ul></div></div><div class="obsidian-callout obsidian-callout--quote" data-callout="quote">  <div class="obsidian-callout__title">    <span class="obsidian-callout__icon" aria-hidden="true">“</span>    <strong>짧은 핵심어 · #ux</strong>  </div>  <div class="obsidian-callout__body"><p>“constraints”</p><ul><li><strong>왜 표시했나</strong>: 불가능한 행동을 미리 줄이는 장치다. ^q03</li><li><strong>개발자 반응</strong>: 폼 검증, 선택지 제한, disabled 상태, 단계별 입력이 오류 가능성을 낮춘다.</li></ul></div></div><div class="obsidian-callout obsidian-callout--note" data-callout="note">  <div class="obsidian-callout__title">    <span class="obsidian-callout__icon" aria-hidden="true">■</span>    <strong>저작권 경계</strong>  </div>  <div class="obsidian-callout__body"><p>이 공개 노트는 책의 장문 문장을 재현하지 않는다. 장 제목과 짧은 핵심어만 단서로 삼고, 내용은 UX&#x2F;UI 개발자의 실무 해석과 적용 중심으로 재구성한다.</p></div></div><h2 id="L2-·-챕터-지도"><a href="#L2-·-챕터-지도" class="headerlink" title="L2 · 챕터 지도"></a>L2 · 챕터 지도</h2><table><thead><tr><th>단위</th><th>내가 붙인 이름</th><th>핵심 주장</th><th>개발자 적용</th></tr></thead><tbody><tr><td>지식의 위치</td><td>머릿속과 세계 속</td><td>모든 것을 기억시키려 하지 말고 화면이 기억을 나눠 갖게 한다</td><td>반복 사용성이 낮은 기능일수록 화면 단서가 더 중요하다</td></tr><tr><td>매핑</td><td>조작과 결과의 관계</td><td>자연스러운 배치가 설명 비용을 줄인다</td><td>컨트롤과 결과 영역을 가까이 둔다</td></tr><tr><td>제약</td><td>가능한 행동의 축소</td><td>좋은 제약은 자유를 빼앗는 것이 아니라 실수를 줄인다</td><td>불가능한 조합은 선택 전에 막는다</td></tr><tr><td>피드백</td><td>지식의 갱신</td><td>사용자는 결과를 보고 시스템 모델을 고친다</td><td>상태 변화가 늦거나 흐리면 학습이 실패한다</td></tr></tbody></table><p><strong>이번 회차 논증 한 단락</strong>:</p><blockquote><p>개발자가 만든 화면은 사실 작은 기억 장치다. 사용자는 모든 기능의 위치와 규칙을 외우고 싶어 하지 않는다. 자주 쓰지 않는 기능일수록, 복잡한 업무일수록, 낯선 도메인일수록 인터페이스가 더 많은 기억을 대신해야 한다. 이 관점은 폼과 관리자 화면에서 특히 중요하다. 입력 순서, 그룹핑, 예시 텍스트, 단위 표기, 기본값, 비활성화 규칙, 에러 메시지는 모두 지식의 배치다. “사용자가 알아서 입력해야 한다”는 말은 때로 설계자가 화면에 놓아야 할 지식을 사용자 머릿속으로 밀어낸다는 뜻이다.</p></blockquote><h2 id="L3-·-인사이트-카드-색인"><a href="#L3-·-인사이트-카드-색인" class="headerlink" title="L3 · 인사이트 카드 색인"></a>L3 · 인사이트 카드 색인</h2><ul><li>The Design of Everyday Things - I3.1 UI는 사용자의 외부 기억 장치다 — 좋은 화면은 기억력이 좋은 사용자를 가정하지 않는다. 필요한 지식을 필요한 위치에 둔다.</li><li>The Design of Everyday Things - I3.2 매핑이 약하면 문서가 늘어난다 — 조작과 결과가 자연스럽게 이어지지 않으면 설명서, 튜토리얼, CS가 그 비용을 대신 낸다.</li><li>The Design of Everyday Things - I3.3 제약은 사용자를 통제하는 기능이 아니라 실수를 줄이는 배려다 — 잘 설계된 제약은 사용자가 실패한 뒤 혼나는 상황을 줄인다.</li></ul><h2 id="L4-·-생산-보드"><a href="#L4-·-생산-보드" class="headerlink" title="L4 · 생산 보드"></a>L4 · 생산 보드</h2><div class="obsidian-callout obsidian-callout--todo" data-callout="todo">  <div class="obsidian-callout__title">    <span class="obsidian-callout__icon" aria-hidden="true">■</span>    <strong>출력 파이프라인</strong>  </div>  <div class="obsidian-callout__body"><p><ul><li><input checked="" disabled="" type="checkbox"> <strong>블로그 초안</strong>: 3회차를 UX&#x2F;UI 개발자 관점으로 정리</li><li><input disabled="" type="checkbox"> <strong>코드 리뷰 질문</strong>: 사용자가 기억해야 하는 것을 UI가 대신 떠받칠 수는 없을까?</li><li><input disabled="" type="checkbox"> <strong>디자인 시스템 카드</strong>: The Design of Everyday Things - I3.1 UI는 사용자의 외부 기억 장치다</li><li><input disabled="" type="checkbox"> <strong>적용 실험</strong>: 최근 만든 화면 하나에 이 회차의 기준을 적용해 보기</li></ul></div></div><h3 id="바로-적용할-체크리스트"><a href="#바로-적용할-체크리스트" class="headerlink" title="바로 적용할 체크리스트"></a>바로 적용할 체크리스트</h3><ul><li>폼 필드마다 <code>사용자가 기억해야 하는 규칙</code>을 찾아 placeholder, helper text, validation, select option으로 외부화한다.</li><li>필터와 결과, 컨트롤과 미리보기, 설정과 영향 범위를 시각적으로 가까이 둔다.</li><li>불가능한 선택 조합은 제출 후 에러가 아니라 선택 단계에서 제약한다.</li></ul><h2 id="L5-·-연결-복습"><a href="#L5-·-연결-복습" class="headerlink" title="L5 · 연결 &amp; 복습"></a>L5 · 연결 &amp; 복습</h2><ul><li><strong>다른 책&#x2F;아이디어와의 연결</strong>: 이 회차는 A Philosophy of Software Design의 인지 부하 관점과 이어진다. 차이는 코드 내부 복잡성보다 사용자의 행동 복잡성을 다룬다는 점이다.</li><li><strong>미해결 질문</strong>:<ul><li>우리 제품에서 사용자가 가장 자주 “멈추는” 화면은 어디인가?</li><li>그 문제는 교육, 문서, CS로 해결할 일인가, 아니면 화면의 단서와 피드백을 고칠 일인가?</li><li>디자인 시스템에 이 회차의 원칙을 어떤 컴포넌트 계약으로 넣을 수 있을까?</li></ul></li><li><strong>복습 일정</strong>: 1주 □ &#x2F; 1개월 □ &#x2F; 3개월 □</li><li><strong>한 문장 최종 정리</strong>: 좋은 UI는 사용자의 기억력을 시험하지 않고, 기억해야 할 것을 세계 속에 배치한다.</li></ul><h2 id="다음-회차"><a href="#다음-회차" class="headerlink" title="다음 회차"></a>다음 회차</h2><ul><li>이전: <a href="/2026/06/27/book-note-design-everyday-things-part-2-action-feedback/">2회차</a></li><li>다음: <a href="/2026/06/27/book-note-design-everyday-things-part-4-error-recovery/">4회차</a></li><li>책장으로 돌아가기: <a href="/book/">&#x2F;book</a></li></ul>]]>
    </content>
    <id>https://reasonofmoon.github.io/2026/06/27/book-note-design-everyday-things-part-3-knowledge-mapping/</id>
    <link href="https://reasonofmoon.github.io/2026/06/27/book-note-design-everyday-things-part-3-knowledge-mapping/"/>
    <published>2026-06-27T03:55:00.000Z</published>
    <summary>머릿속 지식과 세계 속 지식, 제약과 매핑을 개발자용 정보 구조·폼·내비게이션 설계 원칙으로 정리한다.</summary>
    <title>책노트: The Design of Everyday Things 3회차 - 기억하게 만들지 말고 보이게 하라</title>
    <updated>2026-06-27T03:55:00.000Z</updated>
  </entry>
  <entry>
    <author>
      <name>Reasonofmoon</name>
    </author>
    <category term="Book" scheme="https://reasonofmoon.github.io/categories/Book/"/>
    <category term="독서" scheme="https://reasonofmoon.github.io/tags/%EB%8F%85%EC%84%9C/"/>
    <category term="책노트" scheme="https://reasonofmoon.github.io/tags/%EC%B1%85%EB%85%B8%ED%8A%B8/"/>
    <category term="독서/책노트" scheme="https://reasonofmoon.github.io/tags/%EB%8F%85%EC%84%9C-%EC%B1%85%EB%85%B8%ED%8A%B8/"/>
    <category term="Book Notes" scheme="https://reasonofmoon.github.io/tags/Book-Notes/"/>
    <category term="The Design of Everyday Things" scheme="https://reasonofmoon.github.io/tags/The-Design-of-Everyday-Things/"/>
    <category term="UX" scheme="https://reasonofmoon.github.io/tags/UX/"/>
    <category term="UI" scheme="https://reasonofmoon.github.io/tags/UI/"/>
    <category term="Product Design" scheme="https://reasonofmoon.github.io/tags/Product-Design/"/>
    <category term="Frontend" scheme="https://reasonofmoon.github.io/tags/Frontend/"/>
    <content>
      <![CDATA[<h1 id="The-Design-of-Everyday-Things-2회차-클릭은-행동의-끝이-아니라-해석의-시작이다"><a href="#The-Design-of-Everyday-Things-2회차-클릭은-행동의-끝이-아니라-해석의-시작이다" class="headerlink" title="The Design of Everyday Things 2회차 - 클릭은 행동의 끝이 아니라 해석의 시작이다"></a>The Design of Everyday Things 2회차 - 클릭은 행동의 끝이 아니라 해석의 시작이다</h1><p>The Design of Everyday Things는 문손잡이와 스위치 이야기로 유명하지만, UX&#x2F;UI를 다루는 개발자에게는 훨씬 실질적인 책이다. 이 책은 “사용자가 왜 헤매는가”를 심리학, 제품 구조, 피드백, 오류 회복, 조직 의사결정의 문제로 나누어 보게 한다.</p><p>이번 글의 질문은 이것이다. <strong>사용자가 버튼을 누른 뒤에도 왜 계속 불안해하는가?</strong></p><p><img src="/images/scribble-covers/book-note-design-everyday-things.svg" alt="The Design of Everyday Things cover"></p><div class="obsidian-callout obsidian-callout--abstract" data-callout="abstract">  <div class="obsidian-callout__title">    <span class="obsidian-callout__icon" aria-hidden="true">■</span>    <strong>이 노트의 사용법</strong>  </div>  <div class="obsidian-callout__body"><p>이 글은 5회로 읽는 <code>The Design of Everyday Things</code> 시리즈의 2회차다. 범위는 <strong>2장 The Psychology of Everyday Actions</strong>이다.</p><p>포착 -&gt; 증류 -&gt; 연결 -&gt; 표현 4단계 깔때기로 UX 원칙을 개발자의 설계 판단으로 바꾼다. 핵심 원칙은 같다. <strong>책 노트는 창고, 인사이트 카드는 화폐.</strong></p></div></div><h2 id="L0-·-서지-진입"><a href="#L0-·-서지-진입" class="headerlink" title="L0 · 서지 &amp; 진입"></a>L0 · 서지 &amp; 진입</h2><ul><li><strong>한 문장 핵심</strong>: 좋은 인터페이스는 사용자의 목표 형성부터 결과 해석까지 행동의 전체 루프를 안내한다.</li><li><strong>이 책을 든 이유 &#x2F; 기대한 질문</strong>: UX&#x2F;UI 개발을 “디자인 전달받기”가 아니라 제품의 행동 문법을 구현하는 일로 보기 위해 읽는다.</li><li><strong>읽기 전 가설</strong>: 개발자는 클릭 이벤트를 기능 호출로 보기 쉽다. 이 회차는 클릭 전후의 심리적 간극까지 설계 대상으로 보게 한다.</li><li><strong>저자 한 줄 컨텍스트</strong>: Don Norman은 인지과학, 인간-컴퓨터 상호작용, 사용자 중심 설계 분야를 대중적 언어로 연결한 연구자이자 설계 사상가다.</li><li><strong>이번 회차 범위</strong>: 2장 The Psychology of Everyday Actions</li><li><strong>관련 도서 &#x2F; 계보</strong>: A Philosophy of Software Design · The Pragmatic Programmer · A Theory of Fun for Game Design · Design System</li></ul><h2 id="L1-·-포착함"><a href="#L1-·-포착함" class="headerlink" title="L1 · 포착함"></a>L1 · 포착함</h2><div class="obsidian-callout obsidian-callout--quote" data-callout="quote">  <div class="obsidian-callout__title">    <span class="obsidian-callout__icon" aria-hidden="true">“</span>    <strong>짧은 핵심어 · #ux</strong>  </div>  <div class="obsidian-callout__body"><p>“seven stages of action”</p><ul><li><strong>왜 표시했나</strong>: 목표에서 결과 평가까지 이어지는 행동 루프다. ^q01</li><li><strong>개발자 반응</strong>: 화면 하나가 아니라 사용자 여정 전체를 설계 단위로 보게 한다.</li></ul></div></div><div class="obsidian-callout obsidian-callout--quote" data-callout="quote">  <div class="obsidian-callout__title">    <span class="obsidian-callout__icon" aria-hidden="true">“</span>    <strong>짧은 핵심어 · #ux</strong>  </div>  <div class="obsidian-callout__body"><p>“gulf of execution”</p><ul><li><strong>왜 표시했나</strong>: 무엇을 어떻게 해야 할지 모르는 간극이다. ^q02</li><li><strong>개발자 반응</strong>: CTA, 입력 순서, 기본값, 제약 조건이 이 간극을 줄인다.</li></ul></div></div><div class="obsidian-callout obsidian-callout--quote" data-callout="quote">  <div class="obsidian-callout__title">    <span class="obsidian-callout__icon" aria-hidden="true">“</span>    <strong>짧은 핵심어 · #ux</strong>  </div>  <div class="obsidian-callout__body"><p>“gulf of evaluation”</p><ul><li><strong>왜 표시했나</strong>: 방금 한 행동이 어떤 결과를 냈는지 모르는 간극이다. ^q03</li><li><strong>개발자 반응</strong>: toast, inline status, progress, history, undo가 이 간극을 줄인다.</li></ul></div></div><div class="obsidian-callout obsidian-callout--note" data-callout="note">  <div class="obsidian-callout__title">    <span class="obsidian-callout__icon" aria-hidden="true">■</span>    <strong>저작권 경계</strong>  </div>  <div class="obsidian-callout__body"><p>이 공개 노트는 책의 장문 문장을 재현하지 않는다. 장 제목과 짧은 핵심어만 단서로 삼고, 내용은 UX&#x2F;UI 개발자의 실무 해석과 적용 중심으로 재구성한다.</p></div></div><h2 id="L2-·-챕터-지도"><a href="#L2-·-챕터-지도" class="headerlink" title="L2 · 챕터 지도"></a>L2 · 챕터 지도</h2><table><thead><tr><th>단위</th><th>내가 붙인 이름</th><th>핵심 주장</th><th>개발자 적용</th></tr></thead><tbody><tr><td>목표</td><td>사용자는 기능이 아니라 목적을 가진다</td><td>드릴이 아니라 구멍, 더 나아가 선반을 원한다</td><td>사용자 스토리는 기능명보다 달성하려는 상태로 써야 한다</td></tr><tr><td>계획</td><td>사용자는 가능한 행동을 고른다</td><td>선택지가 너무 많거나 숨어 있으면 행동이 늦어진다</td><td>주요 행동과 보조 행동의 위계를 분명히 한다</td></tr><tr><td>실행</td><td>사용자는 실제 조작을 한다</td><td>입력·클릭·드래그는 시스템 규칙을 시험하는 순간이다</td><td>입력 마스크와 즉시 검증을 신중하게 설계한다</td></tr><tr><td>평가</td><td>사용자는 결과를 해석한다</td><td>피드백이 없으면 사용자는 같은 행동을 반복한다</td><td>성공·실패·대기 상태를 화면 안에서 설명한다</td></tr></tbody></table><p><strong>이번 회차 논증 한 단락</strong>:</p><blockquote><p>2장은 UX를 화면의 문제가 아니라 시간의 문제로 바꾼다. 사용자는 목표를 만들고, 행동을 계획하고, 실행하고, 결과를 해석한다. 개발자는 보통 실행 단계, 즉 버튼 클릭이나 API 호출에 집중한다. 하지만 실제 사용성은 그 앞뒤에서 무너진다. 실행의 간극은 “무엇을 해야 하지?”라는 막힘이다. 평가의 간극은 “이게 된 건가?”라는 불안이다. 둘 다 코드로 해결할 수 있다. 버튼 라벨을 구체화하고, 위험한 행동에는 확인을 두고, 저장 중 상태를 보여주고, 실패한 입력을 어디서 어떻게 고쳐야 하는지 알려주는 일은 모두 개발자의 책임 안에 있다.</p></blockquote><h2 id="L3-·-인사이트-카드-색인"><a href="#L3-·-인사이트-카드-색인" class="headerlink" title="L3 · 인사이트 카드 색인"></a>L3 · 인사이트 카드 색인</h2><ul><li>The Design of Everyday Things - I2.1 이벤트 핸들러는 행동 루프의 한 지점일 뿐이다 — 클릭이 발생했다고 UX가 끝나는 것이 아니다. 사용자는 그 결과를 보고 다음 판단을 해야 한다.</li><li>The Design of Everyday Things - I2.2 좋은 피드백은 장식이 아니라 신뢰의 인프라다 — 시스템이 침묵하면 사용자는 불안해지고, 불안은 중복 제출과 이탈로 나타난다.</li><li>The Design of Everyday Things - I2.3 목표를 기능명으로 번역하는 순간 사용자 맥락이 사라진다 — “파일 업로드”보다 “과제를 제출했다는 확신을 얻는다”가 더 좋은 UX 질문이다.</li></ul><h2 id="L4-·-생산-보드"><a href="#L4-·-생산-보드" class="headerlink" title="L4 · 생산 보드"></a>L4 · 생산 보드</h2><div class="obsidian-callout obsidian-callout--todo" data-callout="todo">  <div class="obsidian-callout__title">    <span class="obsidian-callout__icon" aria-hidden="true">■</span>    <strong>출력 파이프라인</strong>  </div>  <div class="obsidian-callout__body"><p><ul><li><input checked="" disabled="" type="checkbox"> <strong>블로그 초안</strong>: 2회차를 UX&#x2F;UI 개발자 관점으로 정리</li><li><input disabled="" type="checkbox"> <strong>코드 리뷰 질문</strong>: 사용자가 버튼을 누른 뒤에도 왜 계속 불안해하는가?</li><li><input disabled="" type="checkbox"> <strong>디자인 시스템 카드</strong>: The Design of Everyday Things - I2.1 이벤트 핸들러는 행동 루프의 한 지점일 뿐이다</li><li><input disabled="" type="checkbox"> <strong>적용 실험</strong>: 최근 만든 화면 하나에 이 회차의 기준을 적용해 보기</li></ul></div></div><h3 id="바로-적용할-체크리스트"><a href="#바로-적용할-체크리스트" class="headerlink" title="바로 적용할 체크리스트"></a>바로 적용할 체크리스트</h3><ul><li>모든 비동기 액션에 <code>idle/loading/success/error/retry</code> 상태를 명시한다.</li><li>성공 toast만 넣지 말고, 사용자가 다음에 해야 할 행동까지 연결한다.</li><li>폼 제출 후 중복 클릭 방지, optimistic update, rollback, undo 정책을 기능별로 문서화한다.</li></ul><h2 id="L5-·-연결-복습"><a href="#L5-·-연결-복습" class="headerlink" title="L5 · 연결 &amp; 복습"></a>L5 · 연결 &amp; 복습</h2><ul><li><strong>다른 책&#x2F;아이디어와의 연결</strong>: 이 회차는 A Philosophy of Software Design의 인지 부하 관점과 이어진다. 차이는 코드 내부 복잡성보다 사용자의 행동 복잡성을 다룬다는 점이다.</li><li><strong>미해결 질문</strong>:<ul><li>우리 제품에서 사용자가 가장 자주 “멈추는” 화면은 어디인가?</li><li>그 문제는 교육, 문서, CS로 해결할 일인가, 아니면 화면의 단서와 피드백을 고칠 일인가?</li><li>디자인 시스템에 이 회차의 원칙을 어떤 컴포넌트 계약으로 넣을 수 있을까?</li></ul></li><li><strong>복습 일정</strong>: 1주 □ &#x2F; 1개월 □ &#x2F; 3개월 □</li><li><strong>한 문장 최종 정리</strong>: 클릭은 사용자의 행동이 끝나는 지점이 아니라 시스템이 사용자의 신뢰를 얻기 시작하는 지점이다.</li></ul><h2 id="다음-회차"><a href="#다음-회차" class="headerlink" title="다음 회차"></a>다음 회차</h2><ul><li>이전: <a href="/2026/06/27/book-note-design-everyday-things-part-1-discoverability/">1회차</a></li><li>다음: <a href="/2026/06/27/book-note-design-everyday-things-part-3-knowledge-mapping/">3회차</a></li><li>책장으로 돌아가기: <a href="/book/">&#x2F;book</a></li></ul>]]>
    </content>
    <id>https://reasonofmoon.github.io/2026/06/27/book-note-design-everyday-things-part-2-action-feedback/</id>
    <link href="https://reasonofmoon.github.io/2026/06/27/book-note-design-everyday-things-part-2-action-feedback/"/>
    <published>2026-06-27T03:50:00.000Z</published>
    <summary>행동의 7단계, 실행의 간극, 평가의 간극을 UX 플로우·상태 설계·피드백 설계로 번역한다.</summary>
    <title>책노트: The Design of Everyday Things 2회차 - 클릭은 행동의 끝이 아니라 해석의 시작이다</title>
    <updated>2026-06-27T03:50:00.000Z</updated>
  </entry>
  <entry>
    <author>
      <name>Reasonofmoon</name>
    </author>
    <category term="Book" scheme="https://reasonofmoon.github.io/categories/Book/"/>
    <category term="독서" scheme="https://reasonofmoon.github.io/tags/%EB%8F%85%EC%84%9C/"/>
    <category term="책노트" scheme="https://reasonofmoon.github.io/tags/%EC%B1%85%EB%85%B8%ED%8A%B8/"/>
    <category term="독서/책노트" scheme="https://reasonofmoon.github.io/tags/%EB%8F%85%EC%84%9C-%EC%B1%85%EB%85%B8%ED%8A%B8/"/>
    <category term="Book Notes" scheme="https://reasonofmoon.github.io/tags/Book-Notes/"/>
    <category term="The Design of Everyday Things" scheme="https://reasonofmoon.github.io/tags/The-Design-of-Everyday-Things/"/>
    <category term="UX" scheme="https://reasonofmoon.github.io/tags/UX/"/>
    <category term="UI" scheme="https://reasonofmoon.github.io/tags/UI/"/>
    <category term="Product Design" scheme="https://reasonofmoon.github.io/tags/Product-Design/"/>
    <category term="Frontend" scheme="https://reasonofmoon.github.io/tags/Frontend/"/>
    <content>
      <![CDATA[<h1 id="The-Design-of-Everyday-Things-1회차-사용자는-멍청하지-않다-단서가-부족할-뿐이다"><a href="#The-Design-of-Everyday-Things-1회차-사용자는-멍청하지-않다-단서가-부족할-뿐이다" class="headerlink" title="The Design of Everyday Things 1회차 - 사용자는 멍청하지 않다, 단서가 부족할 뿐이다"></a>The Design of Everyday Things 1회차 - 사용자는 멍청하지 않다, 단서가 부족할 뿐이다</h1><p>The Design of Everyday Things는 문손잡이와 스위치 이야기로 유명하지만, UX&#x2F;UI를 다루는 개발자에게는 훨씬 실질적인 책이다. 이 책은 “사용자가 왜 헤매는가”를 심리학, 제품 구조, 피드백, 오류 회복, 조직 의사결정의 문제로 나누어 보게 한다.</p><p>이번 글의 질문은 이것이다. <strong>사용자가 헤매는 순간, 우리는 무엇을 먼저 의심해야 하는가?</strong></p><p><img src="/images/scribble-covers/book-note-design-everyday-things.svg" alt="The Design of Everyday Things cover"></p><div class="obsidian-callout obsidian-callout--abstract" data-callout="abstract">  <div class="obsidian-callout__title">    <span class="obsidian-callout__icon" aria-hidden="true">■</span>    <strong>이 노트의 사용법</strong>  </div>  <div class="obsidian-callout__body"><p>이 글은 5회로 읽는 <code>The Design of Everyday Things</code> 시리즈의 1회차다. 범위는 <strong>개정판 서문, 1장 The Psychopathology of Everyday Things</strong>이다.</p><p>포착 -&gt; 증류 -&gt; 연결 -&gt; 표현 4단계 깔때기로 UX 원칙을 개발자의 설계 판단으로 바꾼다. 핵심 원칙은 같다. <strong>책 노트는 창고, 인사이트 카드는 화폐.</strong></p></div></div><h2 id="L0-·-서지-진입"><a href="#L0-·-서지-진입" class="headerlink" title="L0 · 서지 &amp; 진입"></a>L0 · 서지 &amp; 진입</h2><ul><li><strong>한 문장 핵심</strong>: 사용성 문제의 상당수는 사용자의 능력 부족이 아니라, 인터페이스가 해야 할 일을 드러내지 못한 결과다.</li><li><strong>이 책을 든 이유 &#x2F; 기대한 질문</strong>: UX&#x2F;UI 개발을 “디자인 전달받기”가 아니라 제품의 행동 문법을 구현하는 일로 보기 위해 읽는다.</li><li><strong>읽기 전 가설</strong>: 처음에는 UX를 화면 배치와 스타일의 문제로 보기 쉽다. 이 회차는 UX를 “사용자가 다음 행동을 예측할 수 있게 하는 단서 설계”로 다시 정의하게 만든다.</li><li><strong>저자 한 줄 컨텍스트</strong>: Don Norman은 인지과학, 인간-컴퓨터 상호작용, 사용자 중심 설계 분야를 대중적 언어로 연결한 연구자이자 설계 사상가다.</li><li><strong>이번 회차 범위</strong>: 개정판 서문, 1장 The Psychopathology of Everyday Things</li><li><strong>관련 도서 &#x2F; 계보</strong>: A Philosophy of Software Design · The Pragmatic Programmer · A Theory of Fun for Game Design · Design System</li></ul><h2 id="L1-·-포착함"><a href="#L1-·-포착함" class="headerlink" title="L1 · 포착함"></a>L1 · 포착함</h2><div class="obsidian-callout obsidian-callout--quote" data-callout="quote">  <div class="obsidian-callout__title">    <span class="obsidian-callout__icon" aria-hidden="true">“</span>    <strong>짧은 핵심어 · #ux</strong>  </div>  <div class="obsidian-callout__body"><p>“discoverability”</p><ul><li><strong>왜 표시했나</strong>: 보이지 않으면 없는 기능과 다르지 않다. ^q01</li><li><strong>개발자 반응</strong>: 숨겨진 제스처와 묵시적 규칙은 개발자에게는 우아해 보여도 사용자에게는 막힌 문이다.</li></ul></div></div><div class="obsidian-callout obsidian-callout--quote" data-callout="quote">  <div class="obsidian-callout__title">    <span class="obsidian-callout__icon" aria-hidden="true">“</span>    <strong>짧은 핵심어 · #ux</strong>  </div>  <div class="obsidian-callout__body"><p>“affordance”</p><ul><li><strong>왜 표시했나</strong>: 무엇을 할 수 있는지 몸이 먼저 짐작하게 하는 성질이다. ^q02</li><li><strong>개발자 반응</strong>: 클릭 가능한 것, 드래그 가능한 것, 입력 가능한 것은 말보다 먼저 형태로 보여야 한다.</li></ul></div></div><div class="obsidian-callout obsidian-callout--quote" data-callout="quote">  <div class="obsidian-callout__title">    <span class="obsidian-callout__icon" aria-hidden="true">“</span>    <strong>짧은 핵심어 · #ux</strong>  </div>  <div class="obsidian-callout__body"><p>“signifier”</p><ul><li><strong>왜 표시했나</strong>: 가능한 행동을 알려주는 표식이다. ^q03</li><li><strong>개발자 반응</strong>: 디지털 UI에서는 버튼 모양, 라벨, 커서 변화, 비활성 상태, 마이크로카피가 모두 시그니파이어다.</li></ul></div></div><div class="obsidian-callout obsidian-callout--note" data-callout="note">  <div class="obsidian-callout__title">    <span class="obsidian-callout__icon" aria-hidden="true">■</span>    <strong>저작권 경계</strong>  </div>  <div class="obsidian-callout__body"><p>이 공개 노트는 책의 장문 문장을 재현하지 않는다. 장 제목과 짧은 핵심어만 단서로 삼고, 내용은 UX&#x2F;UI 개발자의 실무 해석과 적용 중심으로 재구성한다.</p></div></div><h2 id="L2-·-챕터-지도"><a href="#L2-·-챕터-지도" class="headerlink" title="L2 · 챕터 지도"></a>L2 · 챕터 지도</h2><table><thead><tr><th>단위</th><th>내가 붙인 이름</th><th>핵심 주장</th><th>개발자 적용</th></tr></thead><tbody><tr><td>1장</td><td>일상 사물의 병리학</td><td>사용자가 실패하는 장면을 통해 설계의 책임을 묻는다</td><td>실패를 사용자 탓으로 돌리기 전에 단서가 충분했는지 확인한다</td></tr><tr><td>핵심 개념</td><td>어포던스와 시그니파이어</td><td>가능한 행동과 그 행동을 알려주는 표식을 구분한다</td><td>컴포넌트는 기능뿐 아니라 행동의 힌트도 제공해야 한다</td></tr><tr><td>개념모형</td><td>사용자의 머릿속 모델</td><td>사람은 화면을 보고 시스템이 어떻게 움직이는지 추정한다</td><td>UI는 내부 구현이 아니라 사용자가 이해할 수 있는 모델을 보여줘야 한다</td></tr><tr><td>피드백</td><td>행동 이후의 반응</td><td>시스템이 지금 무엇을 했는지 알려주지 않으면 불안이 생긴다</td><td>로딩, 저장, 오류, 완료 상태를 명확히 드러낸다</td></tr></tbody></table><p><strong>이번 회차 논증 한 단락</strong>:</p><blockquote><p>개발자가 UX&#x2F;UI를 다룰 때 가장 쉽게 빠지는 함정은 “기능은 있는데 사용자가 못 찾는다”를 사소한 문제로 보는 것이다. 그러나 Norman의 관점에서 그 순간은 핵심 설계 실패다. 기능이 존재한다는 사실과 사용자가 그 기능을 발견할 수 있다는 사실은 전혀 다르다. 프론트엔드 개발로 옮기면 질문은 더 날카로워진다. 버튼은 정말 버튼처럼 보이는가. 비활성화된 이유는 설명되는가. 저장 중인지, 실패했는지, 성공했는지 사용자가 알 수 있는가. 메뉴 안에 숨긴 기능은 사용자의 현재 과업 흐름에서 발견될 수 있는가. 이 회차는 이런 질문을 “디자인 감각”이 아니라 “인터페이스의 책임”으로 바꾼다.</p></blockquote><h2 id="L3-·-인사이트-카드-색인"><a href="#L3-·-인사이트-카드-색인" class="headerlink" title="L3 · 인사이트 카드 색인"></a>L3 · 인사이트 카드 색인</h2><ul><li>The Design of Everyday Things - I1.1 UX 버그는 사용자 행동 로그가 아니라 단서 부족 로그다 — 사용자가 같은 지점에서 반복적으로 멈추면, 그것은 교육 부족보다 시그니파이어 부족일 가능성이 크다.</li><li>The Design of Everyday Things - I1.2 좋은 컴포넌트는 기능과 행동 힌트를 함께 캡슐화한다 — 컴포넌트 API는 색과 크기만 받는 것이 아니라, 상태·금지·위험·다음 행동을 표현할 수 있어야 한다.</li><li>The Design of Everyday Things - I1.3 디자인 시스템은 브랜드 규칙이 아니라 행동 문법이다 — 토큰과 컴포넌트는 예쁜 통일감보다 사용자가 “이것은 이렇게 쓰는 것”이라고 배울 수 있는 일관성을 제공해야 한다.</li></ul><h2 id="L4-·-생산-보드"><a href="#L4-·-생산-보드" class="headerlink" title="L4 · 생산 보드"></a>L4 · 생산 보드</h2><div class="obsidian-callout obsidian-callout--todo" data-callout="todo">  <div class="obsidian-callout__title">    <span class="obsidian-callout__icon" aria-hidden="true">■</span>    <strong>출력 파이프라인</strong>  </div>  <div class="obsidian-callout__body"><p><ul><li><input checked="" disabled="" type="checkbox"> <strong>블로그 초안</strong>: 1회차를 UX&#x2F;UI 개발자 관점으로 정리</li><li><input disabled="" type="checkbox"> <strong>코드 리뷰 질문</strong>: 사용자가 헤매는 순간, 우리는 무엇을 먼저 의심해야 하는가?</li><li><input disabled="" type="checkbox"> <strong>디자인 시스템 카드</strong>: The Design of Everyday Things - I1.1 UX 버그는 사용자 행동 로그가 아니라 단서 부족 로그다</li><li><input disabled="" type="checkbox"> <strong>적용 실험</strong>: 최근 만든 화면 하나에 이 회차의 기준을 적용해 보기</li></ul></div></div><h3 id="바로-적용할-체크리스트"><a href="#바로-적용할-체크리스트" class="headerlink" title="바로 적용할 체크리스트"></a>바로 적용할 체크리스트</h3><ul><li>새 컴포넌트를 만들 때 <code>가능한 행동</code>, <code>행동 단서</code>, <code>상태 피드백</code>, <code>오류 회복</code>을 PR 체크리스트에 넣는다.</li><li>아이콘 단독 버튼은 tooltip, aria-label, hover&#x2F;focus 상태를 기본 계약으로 둔다.</li><li>사용자 행동 로그에서 클릭 실패·되돌아가기·반복 입력이 많은 지점을 “나쁜 사용자”가 아니라 “약한 단서”로 본다.</li></ul><h2 id="L5-·-연결-복습"><a href="#L5-·-연결-복습" class="headerlink" title="L5 · 연결 &amp; 복습"></a>L5 · 연결 &amp; 복습</h2><ul><li><strong>다른 책&#x2F;아이디어와의 연결</strong>: 이 회차는 A Philosophy of Software Design의 인지 부하 관점과 이어진다. 차이는 코드 내부 복잡성보다 사용자의 행동 복잡성을 다룬다는 점이다.</li><li><strong>미해결 질문</strong>:<ul><li>우리 제품에서 사용자가 가장 자주 “멈추는” 화면은 어디인가?</li><li>그 문제는 교육, 문서, CS로 해결할 일인가, 아니면 화면의 단서와 피드백을 고칠 일인가?</li><li>디자인 시스템에 이 회차의 원칙을 어떤 컴포넌트 계약으로 넣을 수 있을까?</li></ul></li><li><strong>복습 일정</strong>: 1주 □ &#x2F; 1개월 □ &#x2F; 3개월 □</li><li><strong>한 문장 최종 정리</strong>: 좋은 UI는 사용자를 똑똑하게 만드는 것이 아니라, 사용자가 이미 가진 직관을 낭비하지 않게 만든다.</li></ul><h2 id="다음-회차"><a href="#다음-회차" class="headerlink" title="다음 회차"></a>다음 회차</h2><ul><li>이전: <a href="/2026/06/27/book-note-design-everyday-things-part-5-design-thinking-business/">5회차</a></li><li>다음: <a href="/2026/06/27/book-note-design-everyday-things-part-2-action-feedback/">2회차</a></li><li>책장으로 돌아가기: <a href="/book/">&#x2F;book</a></li></ul>]]>
    </content>
    <id>https://reasonofmoon.github.io/2026/06/27/book-note-design-everyday-things-part-1-discoverability/</id>
    <link href="https://reasonofmoon.github.io/2026/06/27/book-note-design-everyday-things-part-1-discoverability/"/>
    <published>2026-06-27T03:45:00.000Z</published>
    <summary>UX/UI 개발자의 관점에서 발견가능성, 어포던스, 시그니파이어, 개념모형을 실무 설계 체크리스트로 바꾼다.</summary>
    <title>책노트: The Design of Everyday Things 1회차 - 사용자는 멍청하지 않다, 단서가 부족할 뿐이다</title>
    <updated>2026-06-27T03:45:00.000Z</updated>
  </entry>
  <entry>
    <author>
      <name>Reasonofmoon</name>
    </author>
    <category term="Book" scheme="https://reasonofmoon.github.io/categories/Book/"/>
    <category term="독서" scheme="https://reasonofmoon.github.io/tags/%EB%8F%85%EC%84%9C/"/>
    <category term="책노트" scheme="https://reasonofmoon.github.io/tags/%EC%B1%85%EB%85%B8%ED%8A%B8/"/>
    <category term="독서/책노트" scheme="https://reasonofmoon.github.io/tags/%EB%8F%85%EC%84%9C-%EC%B1%85%EB%85%B8%ED%8A%B8/"/>
    <category term="Book Notes" scheme="https://reasonofmoon.github.io/tags/Book-Notes/"/>
    <category term="Habermas" scheme="https://reasonofmoon.github.io/tags/Habermas/"/>
    <category term="Philosophy" scheme="https://reasonofmoon.github.io/tags/Philosophy/"/>
    <category term="Sociology" scheme="https://reasonofmoon.github.io/tags/Sociology/"/>
    <category term="Communication" scheme="https://reasonofmoon.github.io/tags/Communication/"/>
    <category term="Humanities" scheme="https://reasonofmoon.github.io/tags/Humanities/"/>
    <category term="Modernity" scheme="https://reasonofmoon.github.io/tags/Modernity/"/>
    <content>
      <![CDATA[<h1 id="의사소통행위이론-5회차-사회가-사람의-말보다-시스템의-언어로만-움직일-때"><a href="#의사소통행위이론-5회차-사회가-사람의-말보다-시스템의-언어로만-움직일-때" class="headerlink" title="의사소통행위이론 5회차 - 사회가 사람의 말보다 시스템의 언어로만 움직일 때"></a>의사소통행위이론 5회차 - 사회가 사람의 말보다 시스템의 언어로만 움직일 때</h1><p>마지막 회차는 조금 어둡다. 하버마스는 루카치, 호르크하이머, 아도르노를 거치며 근대 사회의 병을 다시 읽는다. 사람과 사람의 관계가 물건처럼 다루어지고, 삶의 의미가 절차와 시장과 행정의 언어로 번역될 때, 우리는 사회 안에 살면서도 사회에서 밀려난 느낌을 받는다.</p><p>하지만 하버마스는 절망으로 끝내지 않는다. 그는 근대의 문제를 이성 자체의 실패로 보지 않는다. 문제는 이성이 너무 많아서가 아니라, 이성이 한쪽으로 좁아져 사람들의 말과 인정과 합의를 밀어낼 때 생긴다고 본다.</p><div class="obsidian-callout obsidian-callout--abstract" data-callout="abstract">  <div class="obsidian-callout__title">    <span class="obsidian-callout__icon" aria-hidden="true">■</span>    <strong>이 노트의 사용법</strong>  </div>  <div class="obsidian-callout__body"><p>이 글은 <code>의사소통행위이론 1권</code> 5회차다. 범위는 합리화가 물화와 사회 병리로 이어지는 문제, 그리고 하버마스가 그 비관을 어떻게 넘어가려 하는가이다.</p><p>이번 글은 “시스템은 잘 돌아가는데 사람은 왜 지치는가”라는 질문으로 읽는다.</p></div></div><h2 id="1-들어가는-말"><a href="#1-들어가는-말" class="headerlink" title="1. 들어가는 말"></a>1. 들어가는 말</h2><p>어떤 조직은 매우 잘 돌아간다. 결제는 빠르고, 보고서는 정해진 시간에 올라가며, 지표는 매주 업데이트된다. 그런데 그 안의 사람들은 점점 말을 잃는다. 왜 이 일을 하는지, 누구를 위해 하는지, 어떤 기준이 좋은지 묻는 시간이 사라진다.</p><p>이것이 하버마스가 붙잡는 근대의 병이다. 사회가 사람들의 대화로만 굴러갈 수는 없다. 돈, 권력, 행정, 절차는 필요하다. 하지만 그것들이 사람의 말과 관계와 의미의 영역까지 대신하기 시작하면 삶은 딱딱해진다.</p><h2 id="2-물화란-무엇인가"><a href="#2-물화란-무엇인가" class="headerlink" title="2. 물화란 무엇인가"></a>2. 물화란 무엇인가</h2><p>물화는 사람의 관계가 사물처럼 굳어지는 현상이다. 쉽게 말하면 살아 있는 대화가 죽은 절차처럼 보이는 것이다.</p><table><thead><tr><th>장면</th><th>물화된 모습</th><th>되살릴 질문</th></tr></thead><tbody><tr><td>교육</td><td>학생이 점수와 등급으로만 보인다</td><td>이 학생은 어떤 경험 속에서 배우고 있는가</td></tr><tr><td>상담</td><td>학부모가 민원 항목으로만 보인다</td><td>이 사람이 정말 걱정하는 것은 무엇인가</td></tr><tr><td>조직</td><td>직원이 성과 지표로만 보인다</td><td>이 일이 어떤 의미와 부담을 만들고 있는가</td></tr><tr><td>기술</td><td>사용자가 클릭 흐름으로만 보인다</td><td>이 화면은 어떤 관계를 만들고 있는가</td></tr></tbody></table><p>물화는 악의 때문에만 생기지 않는다. 오히려 좋은 의도로 만든 제도와 도구가 너무 강해질 때 생길 수 있다. 관리하려고 만든 것이 이해를 밀어내고, 측정하려고 만든 것이 대화를 줄인다.</p><h2 id="3-생활-장면으로-풀기"><a href="#3-생활-장면으로-풀기" class="headerlink" title="3. 생활 장면으로 풀기"></a>3. 생활 장면으로 풀기</h2><p>학습 리포트가 있다고 해보자. 리포트에는 출석률, 과제 제출률, 어휘 테스트 점수, 독해 속도가 깔끔하게 표시된다. 이 자료는 분명 필요하다. 문제는 이것이 학생 이해의 전부가 될 때다.</p><p>한 학생이 점수는 낮지만 수업에서 질문을 많이 하기 시작했다면, 그것은 중요한 변화다. 다른 학생이 점수는 높지만 점점 말수가 줄고 있다면, 그것도 놓치면 안 되는 신호다. 숫자는 변화의 일부를 보여주지만, 변화의 의미를 완성하지는 않는다.</p><p>하버마스식으로 말하면, 제도와 도구가 생활세계의 대화를 보조해야 한다. 그것이 대화를 대체하는 순간, 사람은 시스템 안에서 관리되지만 이해받지는 못한다.</p><h2 id="4-인문기술학적-읽기"><a href="#4-인문기술학적-읽기" class="headerlink" title="4. 인문기술학적 읽기"></a>4. 인문기술학적 읽기</h2><p>인문기술학적 시선은 기술을 인간화하자는 막연한 구호가 아니다. 더 구체적으로 말하면, 기술이 어떤 언어로 사람을 다루는지 살피는 일이다.</p><p>기술은 사람을 데이터로, 과업으로, 절차로, 지표로 번역한다. 이 번역은 필요하다. 하지만 번역에는 항상 손실이 있다. 관계의 뉘앙스, 망설임, 신뢰, 불안, 성장의 감각은 쉽게 숫자로 옮겨지지 않는다.</p><p>그래서 좋은 운영자는 시스템의 결과를 끝으로 보지 않고 대화의 시작으로 삼는다. “점수가 낮다”에서 멈추지 않고 “어떤 어려움이 있었을까”를 묻는다. “과제를 안 냈다”에서 멈추지 않고 “과제를 낼 수 없는 조건이 있었을까”를 묻는다.</p><p>하버마스가 주는 통찰은 이것이다. 사회가 건강하려면 시스템의 언어와 사람의 언어가 균형을 이루어야 한다. 시스템은 정리하고, 사람의 말은 의미를 회복한다.</p><h2 id="5-인사이트-카드"><a href="#5-인사이트-카드" class="headerlink" title="5. 인사이트 카드"></a>5. 인사이트 카드</h2><ul><li>Habermas - I13 물화는 살아 있는 관계가 죽은 절차처럼 굳어지는 순간이다</li><li>Habermas - I14 지표는 대화의 끝이 아니라 시작이어야 한다</li><li>Habermas - I15 근대의 회복은 효율을 버리는 것이 아니라 대화의 자리를 되찾는 일이다</li></ul><h2 id="6-복습-질문"><a href="#6-복습-질문" class="headerlink" title="6. 복습 질문"></a>6. 복습 질문</h2><ul><li>내 주변에서 사람의 말보다 시스템의 언어가 더 강해진 장면은 무엇인가?</li><li>어떤 지표가 원래의 목적을 잊게 만들고 있는가?</li><li>운영 도구를 대화의 시작점으로 바꾸려면 어떤 질문을 붙여야 할까?</li></ul><p><strong>한 문장 최종 정리</strong>: 하버마스가 보기에 근대의 병은 시스템이 있다는 사실이 아니라, 시스템의 언어가 사람들의 대화와 의미를 대신하기 시작할 때 생긴다.</p>]]>
    </content>
    <id>https://reasonofmoon.github.io/2026/06/27/book-note-communicative-action-part-5-reification-modernity/</id>
    <link href="https://reasonofmoon.github.io/2026/06/27/book-note-communicative-action-part-5-reification-modernity/"/>
    <published>2026-06-27T02:50:00.000Z</published>
    <summary>루카치, 호르크하이머, 아도르노를 거쳐 하버마스가 근대의 병을 어떻게 다시 설명하는지 쉽게 풀어봅니다.</summary>
    <title>책노트: 의사소통행위이론 5회차 - 사회가 사람의 말보다 시스템의 언어로만 움직일 때</title>
    <updated>2026-06-27T02:50:00.000Z</updated>
  </entry>
  <entry>
    <author>
      <name>Reasonofmoon</name>
    </author>
    <category term="Book" scheme="https://reasonofmoon.github.io/categories/Book/"/>
    <category term="독서" scheme="https://reasonofmoon.github.io/tags/%EB%8F%85%EC%84%9C/"/>
    <category term="책노트" scheme="https://reasonofmoon.github.io/tags/%EC%B1%85%EB%85%B8%ED%8A%B8/"/>
    <category term="독서/책노트" scheme="https://reasonofmoon.github.io/tags/%EB%8F%85%EC%84%9C-%EC%B1%85%EB%85%B8%ED%8A%B8/"/>
    <category term="Book Notes" scheme="https://reasonofmoon.github.io/tags/Book-Notes/"/>
    <category term="Habermas" scheme="https://reasonofmoon.github.io/tags/Habermas/"/>
    <category term="Philosophy" scheme="https://reasonofmoon.github.io/tags/Philosophy/"/>
    <category term="Sociology" scheme="https://reasonofmoon.github.io/tags/Sociology/"/>
    <category term="Communication" scheme="https://reasonofmoon.github.io/tags/Communication/"/>
    <category term="Humanities" scheme="https://reasonofmoon.github.io/tags/Humanities/"/>
    <category term="Lifeworld" scheme="https://reasonofmoon.github.io/tags/Lifeworld/"/>
    <content>
      <![CDATA[<h1 id="의사소통행위이론-4회차-말이-통한다는-것은-세계를-함께-세우는-일이다"><a href="#의사소통행위이론-4회차-말이-통한다는-것은-세계를-함께-세우는-일이다" class="headerlink" title="의사소통행위이론 4회차 - 말이 통한다는 것은 세계를 함께 세우는 일이다"></a>의사소통행위이론 4회차 - 말이 통한다는 것은 세계를 함께 세우는 일이다</h1><p>의사소통행위라는 말은 어렵지만, 그 안에 담긴 생각은 우리 모두가 매일 겪는 일이다. 누군가와 말이 통한다는 것은 단순히 문장을 알아듣는 것이 아니다. 같은 상황을 보고, 무엇이 사실인지, 무엇이 정당한지, 누가 어떤 마음으로 말하는지 함께 맞춰가는 일이다.</p><p>하버마스는 이 과정을 사회의 기본 장면으로 본다. 사람들은 말로 서로의 행동을 조정한다. 명령, 돈, 힘만으로 움직이는 것이 아니라, “그 말이 맞다”, “그 규칙은 받아들일 만하다”, “그 사람은 진심이다”라는 인정을 통해 함께 움직인다.</p><div class="obsidian-callout obsidian-callout--abstract" data-callout="abstract">  <div class="obsidian-callout__title">    <span class="obsidian-callout__icon" aria-hidden="true">■</span>    <strong>이 노트의 사용법</strong>  </div>  <div class="obsidian-callout__body"><p>이 글은 <code>의사소통행위이론 1권</code> 4회차다. 범위는 의사소통행위와 생활세계 개념이다.</p><p>이번 글은 “말이 통한다”는 평범한 표현을 사회이론의 언어로 다시 읽는다.</p></div></div><h2 id="1-들어가는-말"><a href="#1-들어가는-말" class="headerlink" title="1. 들어가는 말"></a>1. 들어가는 말</h2><p>우리는 자주 “말이 안 통한다”고 말한다. 이 말은 단순히 상대가 단어를 모른다는 뜻이 아니다. 사실 이해가 다르거나, 기준이 다르거나, 마음을 믿기 어렵다는 뜻이다.</p><p>예를 들어 같은 “성장”이라는 말을 써도 한 사람은 성적 향상을 뜻하고, 다른 사람은 자신감 회복을 뜻하고, 또 다른 사람은 꾸준히 앉아 있는 힘을 뜻할 수 있다. 단어는 같지만 세계가 다르다.</p><p>의사소통행위는 이 세계를 맞추는 작업이다. 같은 상황을 함께 정의하고, 서로의 이유를 검토하고, 행동을 조정하는 과정이다. 그래서 말이 통한다는 것은 세계를 함께 세우는 일이다.</p><h2 id="2-생활세계란-무엇인가"><a href="#2-생활세계란-무엇인가" class="headerlink" title="2. 생활세계란 무엇인가"></a>2. 생활세계란 무엇인가</h2><p>생활세계는 사람들이 당연하게 공유한다고 느끼는 배경이다. 가족, 학교, 직장, 지역, 언어, 습관, 예절, 기억, 기대가 여기에 들어간다. 우리는 대화할 때 이 배경을 모두 설명하지 않는다. 대부분은 이미 통한다고 믿고 말한다.</p><table><thead><tr><th>생활세계의 요소</th><th>쉬운 풀이</th><th>예시</th></tr></thead><tbody><tr><td>문화</td><td>무엇을 의미 있다고 보는가</td><td>공부, 성실, 예의, 성장에 대한 생각</td></tr><tr><td>사회</td><td>어떤 규칙과 관계가 인정되는가</td><td>선생님과 학생, 학부모와 기관, 동료 간 역할</td></tr><tr><td>인격</td><td>한 사람이 어떤 사람으로 자라는가</td><td>책임감, 자존감, 말하는 습관</td></tr></tbody></table><p>생활세계가 튼튼하면 설명이 짧아도 통한다. 반대로 생활세계가 흔들리면 아주 작은 말도 오해가 된다. “조금 더 노력해보자”라는 말이 격려로 들릴 수도 있고, 비난으로 들릴 수도 있다.</p><h2 id="3-생활-장면으로-풀기"><a href="#3-생활-장면으로-풀기" class="headerlink" title="3. 생활 장면으로 풀기"></a>3. 생활 장면으로 풀기</h2><p>수업 후 피드백을 생각해보자. 선생님이 학생에게 말한다.</p><blockquote><p>“이번 글은 구조가 좋아졌어. 다만 근거를 조금 더 구체적으로 써보자.”</p></blockquote><p>이 말이 잘 전달되려면 세 가지가 맞아야 한다.</p><p>첫째, 학생은 “구조”와 “근거”가 무엇을 뜻하는지 어느 정도 알고 있어야 한다. 둘째, 선생님의 평가 기준이 일관적이라고 믿어야 한다. 셋째, 이 말이 깎아내리려는 것이 아니라 성장시키려는 말이라고 느껴야 한다.</p><p>피드백은 정보 전달이 아니다. 작은 사회적 장면이다. 거기에는 지식, 규칙, 신뢰가 함께 들어 있다. 하버마스의 생활세계 개념은 바로 이 보이지 않는 배경을 보게 해준다.</p><h2 id="4-인문기술학적-읽기"><a href="#4-인문기술학적-읽기" class="headerlink" title="4. 인문기술학적 읽기"></a>4. 인문기술학적 읽기</h2><p>많은 시스템은 정보를 전달하는 데 집중한다. 알림을 보내고, 리포트를 만들고, 점수를 보여준다. 하지만 교육과 상담과 조직에서 중요한 것은 정보가 전달되었는가만이 아니다. 그 정보가 어떤 배경 속에서 이해되었는가가 더 중요하다.</p><p>좋은 기술은 생활세계를 파괴하지 않고 보강해야 한다. 학부모에게 리포트를 보낼 때도 숫자만 보내면 충분하지 않다. 그 숫자가 어떤 맥락에서 나왔고, 아이에게 어떤 의미가 있으며, 다음 행동은 무엇인지 함께 설명되어야 한다.</p><p>하버마스를 읽으면 기술은 단순한 전달 장치가 아니라 관계의 배경을 설계하는 장치가 된다. 화면 하나, 문장 하나, 버튼 하나도 사용자의 생활세계 안에서 해석된다. 그래서 인문기술학은 기능보다 먼저 맥락을 묻는다.</p><h2 id="5-인사이트-카드"><a href="#5-인사이트-카드" class="headerlink" title="5. 인사이트 카드"></a>5. 인사이트 카드</h2><ul><li>Habermas - I10 말이 통한다는 것은 같은 배경을 함께 세우는 일이다</li><li>Habermas - I11 피드백은 정보 전달이 아니라 관계 조정이다</li><li>Habermas - I12 좋은 기술은 생활세계를 덮어쓰지 않고 설명 가능한 맥락을 더한다</li></ul><h2 id="6-복습-질문"><a href="#6-복습-질문" class="headerlink" title="6. 복습 질문"></a>6. 복습 질문</h2><ul><li>내가 자주 쓰지만 상대마다 다르게 이해하는 단어는 무엇인가?</li><li>내 조직이나 수업에서 생활세계가 흔들리는 순간은 언제인가?</li><li>정보 전달을 관계 조정으로 바꾸려면 어떤 설명이 더 필요할까?</li></ul><p><strong>한 문장 최종 정리</strong>: 의사소통행위는 말로 세계를 함께 맞추는 일이고, 생활세계는 그 말이 통하게 해주는 보이지 않는 배경이다.</p>]]>
    </content>
    <id>https://reasonofmoon.github.io/2026/06/27/book-note-communicative-action-part-4-communication-world/</id>
    <link href="https://reasonofmoon.github.io/2026/06/27/book-note-communicative-action-part-4-communication-world/"/>
    <published>2026-06-27T02:40:00.000Z</published>
    <summary>의사소통행위와 생활세계 개념을 상담, 수업, 조직 운영의 장면으로 쉽게 풀어봅니다.</summary>
    <title>책노트: 의사소통행위이론 4회차 - 말이 통한다는 것은 세계를 함께 세우는 일이다</title>
    <updated>2026-06-27T02:40:00.000Z</updated>
  </entry>
  <entry>
    <author>
      <name>Reasonofmoon</name>
    </author>
    <category term="YouTube Lab" scheme="https://reasonofmoon.github.io/categories/YouTube-Lab/"/>
    <category term="Agentic Engineering" scheme="https://reasonofmoon.github.io/tags/Agentic-Engineering/"/>
    <category term="AI" scheme="https://reasonofmoon.github.io/tags/AI/"/>
    <category term="Claude Code" scheme="https://reasonofmoon.github.io/tags/Claude-Code/"/>
    <category term="Context Engineering" scheme="https://reasonofmoon.github.io/tags/Context-Engineering/"/>
    <category term="YouTube" scheme="https://reasonofmoon.github.io/tags/YouTube/"/>
    <category term="Video Notes" scheme="https://reasonofmoon.github.io/tags/Video-Notes/"/>
    <category term="Custom Skills" scheme="https://reasonofmoon.github.io/tags/Custom-Skills/"/>
    <content>
      <![CDATA[<p>한국과학기술연구원(KIST)에서 진행된 카카오 FDE(Forward Deployed Engineer) <strong>황민호 님</strong>의 세션 <strong>&ldquo;Claude Code 기초&rdquo;</strong> 강연을 정리하고 분석한 비디오 노트입니다. 터미널 기반의 AI 개발 도구인 클로드 코드의 실전적인 동작 방식과 에이전트 커스텀 스킬 구축, 그리고 컨텍스트 관리 기법을 상세히 다룹니다.</p><hr><h2 id="1-Claude-Code-강의의-시작과-Harness-설계-예고"><a href="#1-Claude-Code-강의의-시작과-Harness-설계-예고" class="headerlink" title="1. Claude Code 강의의 시작과 Harness 설계 예고"></a>1. Claude Code 강의의 시작과 Harness 설계 예고</h2><iframe width="560" height="315" src="https://www.youtube-nocookie.com/embed/pHfDgZ7cll0?start=971&amp;end=1004&amp;rel=0" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe><div class="obsidian-callout obsidian-callout--quote" data-callout="quote">  <div class="obsidian-callout__title">    <span class="obsidian-callout__icon" aria-hidden="true">“</span>    <strong>자막 근거 · 16:11</strong>  </div>  <div class="obsidian-callout__body"><p>starting today, I’m going to begin the Claude Code lectures… two weeks later… the harness, which is called a harness, is now referred to as a horse harness. You will teach me techniques to make the AI agent move as I please.</p></div></div><h3 id="해석"><a href="#해석" class="headerlink" title="해석"></a>해석</h3><p>황민호 님은 카카오 FDE로서 사내 각 조직에 AI 시스템을 신속하게 구축하고 <strong>AX(AI Transformation)</strong> 미션을 지원하는 역할을 설명하며 강연을 엽니다. 특히 터미널에서 동작하는 에이전트인 클로드 코드가 비개발자에게도 매우 강력한 생산성 도구가 될 수 있음을 강조합니다.</p><p>세션 초반에 예고된 <strong>하네스(Harness, 에이전트 고성능 제어 말고삐)</strong> 기법은 단순히 에이전트에게 1회성 프롬프트를 주는 것을 넘어, 스스로 자료를 수집하고 병렬로 글을 쓰고 삽화 이미지를 생성하여 결합하는 자율적인 소프트웨어 컴파일 환경을 제공합니다. 실제로 강연에서는 한 줄의 프롬프트만으로 200~300페이지 분량의 초보자용 책을 단 한 시간 만에 완성하고 웹북 형태로 빌드해내는 자동화 데모를 선보였습니다.</p><hr><h2 id="2-Custom-Skill과-파일-참조를-통한-웹사이트-자동-생성"><a href="#2-Custom-Skill과-파일-참조를-통한-웹사이트-자동-생성" class="headerlink" title="2. Custom Skill과 @ 파일 참조를 통한 웹사이트 자동 생성"></a>2. Custom Skill과 @ 파일 참조를 통한 웹사이트 자동 생성</h2><iframe width="560" height="315" src="https://www.youtube-nocookie.com/embed/pHfDgZ7cll0?start=4210&amp;end=4250&amp;rel=0" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe><div class="obsidian-callout obsidian-callout--quote" data-callout="quote">  <div class="obsidian-callout__title">    <span class="obsidian-callout__icon" aria-hidden="true">“</span>    <strong>자막 근거 · 1:10:16</strong>  </div>  <div class="obsidian-callout__body"><p>In this way, we align the design using the file analyzed in the paper earlier and the My Design skill we created in the design system, and the file becomes the content to create a single website. The @ symbol indicates that the command will reference that file and execute the command based on its contents.</p></div></div><h3 id="해석-1"><a href="#해석-1" class="headerlink" title="해석"></a>해석</h3><p>사용자가 지정한 강연의 핵심 하이라이트 구간입니다. 기존 웹 브라우저 환경의 ChatGPT나 Claude 등은 단순한 챗 인터페이스에 갇혀 로컬 파일 구조를 직접 제어하는 자유도가 낮았습니다. 반면 클로드 코드는 로컬 터미널에서 파일 입출력 및 명령 실행 권한을 획득하여 자율적으로 동작합니다.</p><p>강연자는 디자인 시안에서 CSS를 추출하여 <code>My Design</code>이라는 <strong>커스텀 스킬(Custom Skill)</strong>로 사전에 빌드해 놓은 상태에서, 논문 분석 데이터인 로컬 파일을 <strong><code>@</code> 기호로 직접 참조</strong>하여 클로드 코드에 전달했습니다. 그 결과, 새롭게 작성된 콘텐츠를 기존 디자인 시스템 스펙과 정확히 일치하는 웹 페이지(HTML)로 순식간에 출력해 냈습니다. 이는 AI가 로컬 환경의 자원을 자유롭게 취합하여 재사용 가능한 도구(스킬)와 결합하고, 인간이 일일이 가이드하지 않아도 약속된 디자인 규격에 맞추어 소프트웨어를 자율 컴파일해내는 강력한 메커니즘을 증명합니다.</p><hr><h2 id="3-Context-Window-관리와-Compaction의-중요성"><a href="#3-Context-Window-관리와-Compaction의-중요성" class="headerlink" title="3. Context Window 관리와 Compaction의 중요성"></a>3. Context Window 관리와 Compaction의 중요성</h2><iframe width="560" height="315" src="https://www.youtube-nocookie.com/embed/pHfDgZ7cll0?start=6730&amp;end=6770&amp;rel=0" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe><div class="obsidian-callout obsidian-callout--quote" data-callout="quote">  <div class="obsidian-callout__title">    <span class="obsidian-callout__icon" aria-hidden="true">“</span>    <strong>자막 근거 · 1:52:16</strong>  </div>  <div class="obsidian-callout__body"><p>uses a command called slash context to visualize what content is being sent when we are currently working with this cloth code. … The context window currently provided by the Clod course is 1 million tokens.</p></div></div><h3 id="해석-2"><a href="#해석-2" class="headerlink" title="해석"></a>해석</h3><p>클로드 코드는 세션이 유지되는 동안 <strong>100만 토큰에 달하는 대용량 컨텍스트 윈도우</strong>를 제공합니다. 작업 이력이 쌓이면서 현재 컨텍스트에 포함된 파일 정보, 터미널 스크린샷, 명령어 응답 로그 등이 누적되는데, 사용자는 <code>/context</code> 명령어를 사용하여 이 점유 현황을 모니터링할 수 있습니다.</p><p>여기서 가장 중요한 개념은 <strong>압축(Compaction)</strong>입니다. 컨텍스트가 임계치 이상으로 채워지면 시스템이 이전 히스토리를 요약하여 압축하는 과정을 수행하는데, 이 과정에서 정보 유실이 불가피하게 발생하고 에이전트의 수행 성능 및 정확도가 눈에 띄게 떨어집니다. 또한, 토큰 사용량이 증가함에 따라 사용 요금과 속도 면에서도 손해가 발생합니다.</p><p>따라서 강연자는 필요에 따라 <code>/compact</code> 명령을 수동으로 내리거나, 새로운 세션을 가볍게 열어 컨텍스트 데스크를 항상 깨끗하게 정돈해야 한다고 말합니다. 나아가 단일 세션에 무거운 연산을 모조리 집어넣기보다는, 독립된 컨텍스트를 지닌 서브 에이전트나 가벼운 <strong>커스텀 스킬</strong>을 만들어 연산을 분할 위임(Parallel Processing)하는 구조가 훨씬 효율적임을 역설합니다.</p><hr><h2 id="내-생각"><a href="#내-생각" class="headerlink" title="내 생각"></a>내 생각</h2><p>이번 강연은 로컬 에이전트 시대를 살아가는 개발자들과 AX 리더들이 마주해야 하는 <strong>컨텍스트 엔지니어링(Context Engineering)</strong>의 실전 교과서라고 볼 수 있습니다.</p><p>첫째, <strong>&ldquo;작업대의 경계(Bounded Context)를 끊임없이 나누어야 한다&rdquo;</strong>는 점입니다. 많은 입문자들이 에이전트에 한꺼번에 많은 파일을 집어넣고 마법처럼 완벽한 결과가 나오기를 기대합니다. 하지만 컨텍스트가 무거워질수록 AI는 집중력을 잃고 엉뚱한 실수를 저지릅니다. 강연자가 보여준 것처럼, 디자인 스펙은 독립된 스킬로 떼어내고 콘텐츠는 별도의 참조 파일(<code>@</code>)로 입력하여 <strong>제한된 범위(Bounded Context)</strong> 안에서만 추론이 작동하도록 격리해야 합니다.</p><p>둘째, <strong>스킬화(Custom Skill Building)의 이점</strong>입니다. 단순한 복사 붙여넣기 방식은 동료 엔지니어들에게 전파되기 어렵고 재사용성이 낮습니다. AI와 함께 일하면서 반복적으로 검증된 프로시저와 템플릿은 앤트로픽의 규격에 맞추어 로컬 플러그인(스킬) 형태로 패키징하여 관리해야 합니다. 이는 AI 도구의 실행 안정성을 확보할 뿐만 아니라, 개발 조직 전체의 에이전틱 생산성을 일관되게 상향 평준화하는 유일한 길입니다.</p><p>로컬 에이전트는 결코 마법의 요술봉이 아닙니다. 에이전트가 쾌적하고 정확하게 달릴 수 있도록 <strong>컨텍스트 데스크를 깨끗하게 정돈하고, 정교하게 분리된 마찰 없는 하네스(Harness) 인프라를 가꾸는 엔지니어</strong>만이 극대화된 협업 생산성을 손에 쥘 수 있을 것입니다.</p>]]>
    </content>
    <id>https://reasonofmoon.github.io/2026/06/27/video-note-claude-code-basics-kist/</id>
    <link href="https://reasonofmoon.github.io/2026/06/27/video-note-claude-code-basics-kist/"/>
    <published>2026-06-27T02:37:00.000Z</published>
    <summary>카카오 황민호 FDE의 KIST 강연을 통해 클로드 코드(Claude Code)의 기본 사용법, 컨텍스트 압축 메커니즘, 그리고 @ 기호 참조와 커스텀 디자인 스킬을 결합한 웹사이트 자동 생성 기법을 분석합니다.</summary>
    <title>영상으로 읽기: Claude Code 기초 / 황민호 / 260429</title>
    <updated>2026-06-27T02:37:00.000Z</updated>
  </entry>
</feed>
