<div id="readability-page-1" class="page"><div>
 <article>
 

 <div>
 

<h2 id="원문-정보">원문 정보</h2>

<blockquote>
 <ul>
 <li>제목: Taste, Judgment and AI</li>
 <li>출처: Addy Osmani (Google Chrome 엔지니어링 리더 · <a href="https://x.com/addyosmani">x.com/addyosmani</a>)</li>
 <li>발행: 2026년 · 약 6분 분량</li>
 <li>원문 링크: <a href="https://x.com/addyosmani/status/2084354578196443351">https://x.com/addyosmani/status/2084354578196443351</a></li>
 </ul>
</blockquote>

코드 생성이 사실상 공짜가 된 시대에 “그럼 사람은 무엇으로 값을 하는가”라는 질문이 반복해서 돌아온다. 이 글은 그 답을 취향(taste) 과 판단(judgment) 이라는 두 축으로 쪼개고, 둘 중 무엇이 AI에게 넘어가고 무엇이 끝까지 남는지를 선명하게 가른다. Articles의 AI-Essays에 담는 이유다.

<h2 id="한-줄-요약-tldr">한 줄 요약 (TL;DR)</h2>

취향은 근거가 다 갖춰지지 않은 상태에서 품질을 알아보는 능력이고, 판단은 위험을 감수하며 그 선택에 이름을 거는 일이다. 취향은 빌리고 복제하고 에이전트에게서 배울 수 있지만, 판단은 이전되지 않는다 — 판단은 능력(capability)이 아니라 책임(liability), 즉 “결과에 내 이름을 붙이겠다”는 고집이기 때문이고, 에이전트에게는 아직 걸 이름이 없다.

이 글의 척추를 한 장으로 옮기면 이렇다. 취향까지는 에이전트가 함께 올라오지만, ‘서명’ 노드는 사람만 통과하는 게이트다.

<pre><code>flowchart LR
 R["반복(reps)&lt;br/&gt;+ 다양성·마찰&lt;br/&gt;(노출로 복리)"] --&gt; T["취향&lt;br/&gt;후보 중 최선을 골라낸다"]
 AG["에이전트&lt;br/&gt;옵션 생성·랭킹"] --&gt;|"취향은 이전 가능&lt;br/&gt;배우고 복제된다"| T
 T --&gt; G{"서명&lt;br/&gt;결과에 이름을 건다"}
 AG -.-&gt;|"걸 이름이 없다&lt;br/&gt;통과 불가"| G
 G --&gt;|"사람만 통과하는 게이트"| J["판단&lt;br/&gt;선택을 소유·트레이드오프·방어&lt;br/&gt;(책임 · liability)"]
 J --&gt; C["후과에서 배움&lt;br/&gt;judgment compounds"]
 C --&gt;|"다음 하드콜"| J
</code></pre>

<h2 id="왜-이-글을-골랐나">왜 이 글을 골랐나</h2>

AI가 옵션을 잘 만들고 잘 순위 매긴다는 건 이제 논쟁거리도 아니다. 진짜 질문은 “에이전트가 취향까지 갖게 되면, 사람에게 남는 건 무엇인가” 이다. Osmani의 대답이 좋은 이유는, 흔한 “인간은 창의성/공감이 있잖아” 같은 위안이 아니라 구조적으로 이전 불가능한 것을 짚기 때문이다. 판단은 잘해서 남는 게 아니라 책임질 수 있어서 남는다. 이 위키에서 여러 번 다룬 <a href="/2026/06/19/ai-engineer-taste.html">취향(taste)이라는 내부 평가 함수</a>, <a href="/2026/06/23/the-untrainable.html">측정할 수 없는 일에 가치가 남는다는 논증</a>, <a href="/2026/06/22/you-can-just-say-it.html">인간의 몫을 ‘AI보다 잘함’으로 증명하지 말라</a>는 이야기들과 정확히 같은 골짜기를 다른 각도에서 비춘다.

<h2 id="핵심-내용">핵심 내용</h2>

<h3 id="취향taste-근거-없이도-품질을-알아보는-능력">취향(taste): 근거 없이도 품질을 알아보는 능력</h3>

Osmani의 정의는 도발적이다. “취향은 모든 증거가 없는 상태에서 품질과 위대함을 알아보는 것(recognizing quality and greatness in the absence of all the evidence).” 웹페이지나 그림을 보고 “아름답다”, “타협 없이 만들었다”고 느낄 때, 우리는 무언가를 측정한 게 아니다. 이유를 대지 못하는데도 확신하고, 그걸 보는 다른 사람들도 똑같이 확신한다. 누군가 옳다고 증명할 수 없는 일련의 선택들을 했고, 그 장인정신이 배어 나오는 것 — 그게 알아봐지는 것이다.

취향은 타고나는 게 아니라 반복(reps) 으로 쌓인다. 충분히 반복해서 열두 개의 선택지를 앞에 놓고 어느 게 최선인지 짚어낼 수 있을 때, 특히 “최선”이 모호할 때조차 짚어낼 수 있을 때 취향이 있다고 한다. 인류가 만든 최고의 것들에 자신을 노출시키고 그걸 자기 작업에 끌어오려 애쓴다면, 취향에 마음을 쓰게 된다.

<h3 id="취향은-필터다--그리고-다양성이-그-필터를-벼린다">취향은 필터다 — 그리고 다양성이 그 필터를 벼린다</h3>

Osmani는 취향을 필터에 비유한다. 역사의 대부분 동안 만드는 일은 비쌌기 때문에 걸러낼 후보 자체가 적었다. 대개 하나의 버전만 만들 수 있었고, 그 이상을 만들 수 있었다면 다행이었다. (AI가 옵션을 무한히 쏟아내는 지금과의 대비가 여기서 암시된다.)

중요한 건, 같은 것만 반복 소비하는 좁은 피드로는 취향을 얻을 수 없다는 점이다. 질문하게 만들고 새로운 의견을 형성하게 하는 다양성과 마찰(variety and friction) 을 경험할 때 품질을 분간하는 능력이 날카로워진다. 본 적이 없으면 무엇을 놓치고 있는지도 모른다. 진짜 취향을 기르려면 예상 밖의 것에 노출되어야 한다.

<h3 id="판단judgment-선택에-이름을-걸고-책임지는-일">판단(judgment): 선택에 이름을 걸고 책임지는 일</h3>

취향은 중요하지만 그다음 단계가 반드시 필요하다 — 판단이다.

<ul>
 <li>취향은 여러 후보 중 최선을 앞으로 내밀게 해준다.</li>
 <li>판단은 그 선택을 소유하고, 필요한 트레이드오프를 받아들이고, 일이 잘못됐을 때 그 결정을 설명하고 방어하게 해준다.</li>
</ul>

판단이 진짜로 발동하는 순간은 여러 나쁜 선택지 중에서 그나마 옳은 것을 골라야 할 때, 그리고 나쁜 결정에서 그냥 걸어 나갈 수 없을 만큼 판돈이 클 때다. 판단은 “무엇을 출시할 것인가”에 대한 최선의 품질 판정을 내리고, 거기에 자기 이름을 서명하는 의지다.

<h3 id="왜-취향은-넘어가고-판단은-안-넘어가는가">왜 취향은 넘어가고 판단은 안 넘어가는가</h3>

여기가 이 글의 핵심 논증이다.

<ul>
 <li>취향은 이전 가능하다. 빌리고, 복제하고, 남에게서 파생시키고, 에이전트에게서 배우고, 어시스턴트에게서 베낄 수 있다.</li>
 <li>판단은 이전 불가능하다. 판단은 결과에 자기 이름이 붙는다고 고집하는 것이고, 에이전트에게는 아직 이름이 없기 때문이다.</li>
</ul>

에이전트는 점점 커지고 똑똑해지지만 동시에 천장에 부딪힌다. 옵션을 잘 제공하고 잘 순위 매긴다. 그러나 계산이 끝나고 선택이 내려져야 하는 순간, 우리는 여전히 인간에게 손을 뻗는다 — 아직도 책임질 수 있는(answerable) 유일한 존재이기 때문이다. 에이전트는 옵션을 평가하는 능력을 계속 키울 수 있다. 그러니 다음 프론티어는 인간이 판단에서 에이전트보다 더 잘하도록 역량을 키우는 것이다.

그래서 흥미로운 질문은 “에이전트가 취향을 가질 수 있는가”가 아니다 — 그건 가능하다고 가정해야 한다. 진짜 질문은 “에이전트가 취향을 갖게 됐을 때 무엇이 남는가” 이고, 답은 판단이다. 판단은 쉽게 복제되지 않는다. 능력이 아니라 책임(liability) 이기 때문이다.

덧붙여, 판단은 보편 기술이 아니다. 모든 실수를 다 겪어본 사람은 없다. 스킬은 우리가 많은 실수를 보고 살아남은 영역에서 자란다.

<h3 id="사례-apple-그리고-maps라는-서명">사례: Apple, 그리고 Maps라는 서명</h3>

Apple의 디자인 취향은 자주 예외적이라고 인용된다. MacBook, iPhone을 떠올려 보면 사용자에게 얼마나 매끄럽게 작동하고 느껴지는지에 크게 마음 쓴다는 게 분명하다. 그러나 취향과 판단의 책임을 동시에 건드리는 다른 사례가 있다 — Maps다.

2012년 Apple은 iOS에서 Google Maps를 걷어내고 자체 버전을 냈다. 취향은 있었다 — 확대해도 선명하게 유지되는 벡터 렌더링, 훌륭한 타이포그래피. 그러나 더 큰 문제들이 있었다. 다리가 강으로 녹아내리고, “Berlin”을 검색하면 남극으로 데려가고, 호주의 한 마을이 사막 한복판 70km 밖에 잘못 찍혔다.

Osmani가 주목하는 건 그다음이다. Tim Cook이 iOS Maps 팀을 탓하는 대신, apple.com에 1인칭으로 사과문을 올려 여러 해에 걸쳐 큰 조직 전반에서 내려진 결정들에 대한 책임을 스스로 졌다. 당시 보도에 따르면 그가 서명을 요청받은 유일한 사람은 아니었을 수도 있지만, 사실이든 아니든 이름이 올라간 건 그였다. 취향도 실패도 그때 다 명백했다. 값을 치른 건 그 서명이었다.

<h3 id="이것이-당신의-일에-적용되는-방식">이것이 당신의 일에 적용되는 방식</h3>

많은 사람은 그렇게 공개적으로 무언가에 서명하고 책임을 지려 하지 않을 것이다. 하지만 이 구조는 우리 일에도 그대로 적용된다.

<ul>
 <li>테스트가 그리 좋지 않다는 걸 알면서 승인하는 pull request.</li>
 <li>충분한 테스트도, 사용자와의 대화도 없이 서둘러 내보낸 새 UI.</li>
</ul>

이런 것들은 공개 사과문까지 가지는 않지만, 그것들이 가르치는 교훈은 당신이 짊어진다. 취향은 노출을 통해 복리로 쌓이고(taste compounds through exposure), 판단은 후과를 통해 복리로 쌓인다(judgment compounds through the consequences).

<h3 id="닫는-조언">닫는 조언</h3>

<ul>
 <li>취향을 다듬고 싶다면: “좋다 / 싫다” 같은 말을 넘어서 왜 무언가가 성공하거나 실패하는지를 물어라. 같은 것의 여러 버전을 연구하고 그 미묘한 차이를 음미할 수 있는지 보라.</li>
 <li>판단을 기르고 싶다면: 어려운 결정을 직접 내려라(make the hard calls). 무슨 일이 일어날 거라 예상했는지 적어두고, 결과에 충분히 가까이 머물러 내가 맞았는지 — 더 중요하게는 틀렸는지 — 를 배워라. 시간이 지나면 내면의 목소리를, 무엇이 고품질인지에 대한 자신의 진짜 믿음을 신뢰하라.</li>
</ul>

(원문은 말미에 “Pangram 4가 이 글을 100% 사람이 쓴 것으로 판정했다”고 덧붙인다 — AI 글쓰기 시대에 저자가 남긴 반쯤 농담 같은 서명이다.)

<h2 id="분석과-인사이트">분석과 인사이트</h2>

1) “취향 vs 판단”은 “능력 vs 책임”의 프레임으로 바꿔 읽어야 한다. 이 글의 진짜 통찰은 취향의 정의가 아니라, 판단을 능력의 스펙트럼에서 떼어내 책임(liability)의 영역으로 옮긴 것이다. 우리는 흔히 “AI가 인간을 대체하느냐”를 능력 경쟁으로 본다. 누가 더 잘하나. 하지만 Osmani는 판단을 성능 게임 밖으로 끌어낸다. 판단이 남는 이유는 더 똑똑해서가 아니라 서명할 수 있어서다. 이건 AI가 아무리 좋아져도 원리적으로 닫히지 않는 격차다. 책임은 성능이 아니라 주체성(who is answerable) 의 문제이기 때문이다.

2) 이 위키의 다른 논증들과 정확히 맞물린다. <a href="/2026/06/23/the-untrainable.html">The Untrainable</a>는 “측정할 수 있는 일은 학습 가능하고 따라서 commodity가 된다”고 말했다. Osmani의 언어로 옮기면 취향은 벤치마크 가능해지는 쪽이고 — 그래서 넘어가고 — 판단은 벤치마크 자체가 성립하지 않는 쪽이다. 서명은 채점할 수 있는 산출물이 아니라 관계(누가 후과를 지는가)이기 때문이다. <a href="/2026/06/19/ai-engineer-taste.html">Pratik Bhavsar의 taste 글</a>이 “취향 = 내부 평가 함수의 품질”을 강조했다면, Osmani는 거기서 한 발 더 나가 그 평가 함수마저 에이전트가 가질 수 있다고 인정한 뒤, 그럼에도 남는 것을 지목한다.

3) 개발자에게 가장 아픈 구절은 “reps”와 “consequences”다. 취향이 반복으로, 판단이 후과로 복리 성장한다면, 에이전트에게 반복과 후과를 다 위임하는 순간 둘 다 자라지 않는다. 이건 <a href="/2026/07/03/agentic-coding-is-a-trap.html">에이전틱 코딩의 함정</a>과 <a href="/2026/06/23/is-ai-ruining-our-skills.html">탈숙련(deskilling) 연구</a>가 데이터로 보여준 것과 같은 경고다. 코드 생성을 넘기는 건 취향의 reps를 넘기는 것이고, “돌아가니 머지”를 반복하는 건 판단의 consequences를 회피하는 것이다. 둘 다 근육이라 안 쓰면 위축된다.

4) 이견 — “취향은 완전히 넘어간다”는 낙관은 조금 이르다. Osmani는 논지를 강하게 세우려고 “에이전트가 취향을 갖는다고 가정하라”고 못 박는다. 실무적으로는 모델이 흉내 내는 건 취향의 산출물(평균적으로 그럴듯한 선택)이지 취향의 원천(예상 밖의 다양성에 노출되어 새 기준을 세우는 능력)이 아니다. 오히려 모델은 훈련 분포의 중앙값으로 수렴하는 경향이 있어, 이 글이 강조한 “다양성과 마찰”의 반대편에 서기 쉽다. 그래서 “취향도 지켜야 할 인간의 자산”이라는 여지는 생각보다 크다. 판단이 방어선이라면, 취향은 아직 완전히 함락되지 않은 고지다.

5) 조직적 함의 — 책임은 위임되지 않지만 취향은 표준화된다. Maps 사례의 진짜 교훈은 “CEO가 사과했다”가 아니라, 결정이 조직 전반·수년에 걸쳐 분산되어 있어도 서명은 단수(單數)로 수렴한다는 것이다. AI 파이프라인이 옵션을 대량 생산하는 조직일수록, 최종 서명이 누구 이름인지를 명시적으로 설계해야 한다. 취향은 도구·프롬프트·스타일 가이드로 팀 전체에 복제·표준화할 수 있지만, “이게 나간다”에 이름을 거는 자리는 자동화하면 안 된다. 그건 버그가 아니라 기능이다.

<h2 id="적용-포인트">적용 포인트</h2>

<ul>
 <li>취향의 reps를 아웃소싱하지 마라. 에이전트가 코드를 쓰더라도, 여러 후보를 나란히 놓고 “왜 이게 더 나은가”를 직접 언어화하는 훈련은 스스로 하라. “좋다/싫다”를 “왜 성공/실패하는가”로 바꾸는 습관.</li>
 <li>다양성과 마찰을 일부러 섭취하라. 같은 피드·같은 스택만 보면 취향은 평균값으로 수렴한다. 낯설고 불편한, 질문을 강제하는 결과물에 의도적으로 노출되라.</li>
 <li>판단에는 항상 이름을 붙여라. 승인하는 PR, 내보내는 UI에 “테스트가 약하다는 걸 알면서 머지한다”를 명시하고 그 결정을 소유하라. 서명 없는 결정을 만들지 마라.</li>
 <li>예측을 적어두고 후과에 가까이 머물러라. 하드콜을 내릴 때 “무슨 일이 일어날 것 같다”를 기록하고, 실제 결과와 대조해 틀린 경우를 특히 복기하라. 판단은 후과에서만 복리로 자란다.</li>
 <li>파이프라인에서 ‘서명 노드’를 명시적으로 설계하라. AI가 옵션을 대량 생산하는 워크플로일수록, 최종 책임자가 누구인지를 조직도가 아니라 결정 단위마다 분명히 하라.</li>
 <li>취향은 표준화하고, 판단은 자동화하지 마라. 스타일 가이드·프롬프트·리뷰 체크리스트로 취향은 팀에 복제하되, “무엇을 출시하는가”의 서명은 사람에게 남겨라.</li>
</ul>

<h2 id="마무리">마무리</h2>

Osmani의 글이 값진 이유는 위안이 아니라 경계선을 그어주기 때문이다. AI 시대 인간의 몫을 “창의성”이나 “공감” 같은 흐릿한 단어로 방어하는 대신, 그는 책임질 수 있는 유일한 존재라는, 원리적으로 이전 불가능한 지점에 말뚝을 박는다. 취향은 어쩌면 넘어갈 것이다 — 그래도 좋다. 진짜 질문은 그다음에 남는 것이고, 남는 것은 선택에 이름을 걸고 후과를 짊어지는 일이다. 그러니 지금 해야 할 두 가지는 분명하다. 취향의 reps를 계속 쌓고, 판단의 하드콜을 계속 내려서 그 후과로부터 배우는 것. 에이전트가 아무리 좋아져도, 서명란은 여전히 비어 있다.

<h3 id="더-읽어보기">더 읽어보기</h3>

<ul>
 <li><a href="https://x.com/addyosmani/status/2084354578196443351">원문 — Taste, Judgment and AI (Addy Osmani)</a></li>
 <li><a href="/2026/06/19/ai-engineer-taste.html">코드가 공짜가 된 시대의 ‘취향(taste)’ — 30x AI 엔지니어가 되는 법</a> — ‘취향 = 내부 평가 함수의 품질’을 다룬 자매 논의. 이 글은 그 평가 함수마저 에이전트가 가질 때 남는 것을 묻는다</li>
 <li><a href="/2026/06/23/the-untrainable.html">The Untrainable — 측정할 수 없는 일에 가치가 남는다</a> — ‘벤치마크 가능한 것은 commodity가 된다’는 논증. 취향/판단 구분과 정확히 겹친다</li>
 <li><a href="/2026/06/22/you-can-just-say-it.html">그냥 그렇게 말하면 된다 — 인간의 가치를 ‘AI보다 잘함’으로 증명하지 말라</a> — 인간의 몫을 성능 경쟁 밖에 두는 인접 관점</li>
 <li><a href="/2026/07/03/agentic-coding-is-a-trap.html">에이전틱 코딩은 함정이다</a> — reps와 스킬 위축의 문제의식을 코딩 실무로 옮겨 읽기</li>
 <li><a href="/2026/06/23/is-ai-ruining-our-skills.html">AI가 우리의 실력을 망치고 있는가 — 탈숙련(deskilling) 연구</a> — 취향/판단의 reps·consequences를 위임할 때 실제로 실력이 준다는 데이터 근거</li>
</ul>

 </div>

 
 </article>

 
</div></div>

Orc’s WIKI

Orc Hwang

원문 정보
제목: Taste, Judgment and AI
출처: Addy Osmani (Google Chrome 엔지니어링 리더 · x.com/addyosmani)
발행: 2026년 · 약 6분 분량
원문 링크: https://x.com/addyosmani/status/2084354578196443351
코드 생성이 사실상 공짜가 된 시대에 “그럼 사람은 무엇으로 값을 하는가”라는 질문이 반복해서 돌아온다. 이 글은 그 답을 취향(taste) 과 판단(judgment) 이라는 두 축으로 쪼개고, 둘 중 무엇이 AI에게 넘어가고 무엇이 끝까지 남는지를 선명하게 가른다. Articles의 AI-Essays에 담는 이유다.
한 줄 요약 (TL;DR)
취향은 근거가 다 갖춰지지 않은 상태에서 품질을 알아보는 능력이고, 판단은 위험을 감수하며 그 선택에 이름을 거는 일이다. 취향은 빌리고 복제하고 에이전트에게서 배울 수 있지만, 판단은 이전되지 않는다 — 판단은 능력(capability)이 아니라 책임(liability), 즉 “결과에 내 이름을 붙이겠다”는 고집이기 때문이고, 에이전트에게는 아직 걸 이름이 없다.
이 글의 척추를 한 장으로 옮기면 이렇다. 취향까지는 에이전트가 함께 올라오지만, ‘서명’ 노드는 사람만 통과하는 게이트다.
flowchart LR
 R["반복(reps) + 다양성·마찰 (노출로 복리)"] --> T["취향 후보 중 최선을 골라낸다"]
 AG["에이전트 옵션 생성·랭킹"] -->|"취향은 이전 가능 배우고 복제된다"| T
 T --> G{"서명 결과에 이름을 건다"}
 AG -.->|"걸 이름이 없다 통과 불가"| G
 G -->|"사람만 통과하는 게이트"| J["판단 선택을 소유·트레이드오프·방어 (책임 · liability)"]
 J --> C["후과에서 배움 judgment compounds"]
 C -->|"다음 하드콜"| J
왜 이 글을 골랐나
AI가 옵션을 잘 만들고 잘 순위 매긴다는 건 이제 논쟁거리도 아니다. 진짜 질문은 “에이전트가 취향까지 갖게 되면, 사람에게 남는 건 무엇인가” 이다. Osmani의 대답이 좋은 이유는, 흔한 “인간은 창의성/공감이 있잖아” 같은 위안이 아니라 구조적으로 이전 불가능한 것을 짚기 때문이다. 판단은 잘해서 남는 게 아니라 책임질 수 있어서 남는다. 이 위키에서 여러 번 다룬 취향(taste)이라는 내부 평가 함수, 측정할 수 없는 일에 가치가 남는다는 논증, 인간의 몫을 ‘AI보다 잘함’으로 증명하지 말라는 이야기들과 정확히 같은 골짜기를 다른 각도에서 비춘다.
핵심 내용
취향(taste): 근거 없이도 품질을 알아보는 능력
Osmani의 정의는 도발적이다. “취향은 모든 증거가 없는 상태에서 품질과 위대함을 알아보는 것(recognizing quality and greatness in the absence of all the evidence).” 웹페이지나 그림을 보고 “아름답다”, “타협 없이 만들었다”고 느낄 때, 우리는 무언가를 측정한 게 아니다. 이유를 대지 못하는데도 확신하고, 그걸 보는 다른 사람들도 똑같이 확신한다. 누군가 옳다고 증명할 수 없는 일련의 선택들을 했고, 그 장인정신이 배어 나오는 것 — 그게 알아봐지는 것이다.
취향은 타고나는 게 아니라 반복(reps) 으로 쌓인다. 충분히 반복해서 열두 개의 선택지를 앞에 놓고 어느 게 최선인지 짚어낼 수 있을 때, 특히 “최선”이 모호할 때조차 짚어낼 수 있을 때 취향이 있다고 한다. 인류가 만든 최고의 것들에 자신을 노출시키고 그걸 자기 작업에 끌어오려 애쓴다면, 취향에 마음을 쓰게 된다.
취향은 필터다 — 그리고 다양성이 그 필터를 벼린다
Osmani는 취향을 필터에 비유한다. 역사의 대부분 동안 만드는 일은 비쌌기 때문에 걸러낼 후보 자체가 적었다. 대개 하나의 버전만 만들 수 있었고, 그 이상을 만들 수 있었다면 다행이었다. (AI가 옵션을 무한히 쏟아내는 지금과의 대비가 여기서 암시된다.)
중요한 건, 같은 것만 반복 소비하는 좁은 피드로는 취향을 얻을 수 없다는 점이다. 질문하게 만들고 새로운 의견을 형성하게 하는 다양성과 마찰(variety and friction) 을 경험할 때 품질을 분간하는 능력이 날카로워진다. 본 적이 없으면 무엇을 놓치고 있는지도 모른다. 진짜 취향을 기르려면 예상 밖의 것에 노출되어야 한다.
판단(judgment): 선택에 이름을 걸고 책임지는 일
취향은 중요하지만 그다음 단계가 반드시 필요하다 — 판단이다.
취향은 여러 후보 중 최선을 앞으로 내밀게 해준다.
판단은 그 선택을 소유하고, 필요한 트레이드오프를 받아들이고, 일이 잘못됐을 때 그 결정을 설명하고 방어하게 해준다.
판단이 진짜로 발동하는 순간은 여러 나쁜 선택지 중에서 그나마 옳은 것을 골라야 할 때, 그리고 나쁜 결정에서 그냥 걸어 나갈 수 없을 만큼 판돈이 클 때다. 판단은 “무엇을 출시할 것인가”에 대한 최선의 품질 판정을 내리고, 거기에 자기 이름을 서명하는 의지다.
왜 취향은 넘어가고 판단은 안 넘어가는가
여기가 이 글의 핵심 논증이다.
취향은 이전 가능하다. 빌리고, 복제하고, 남에게서 파생시키고, 에이전트에게서 배우고, 어시스턴트에게서 베낄 수 있다.
판단은 이전 불가능하다. 판단은 결과에 자기 이름이 붙는다고 고집하는 것이고, 에이전트에게는 아직 이름이 없기 때문이다.
에이전트는 점점 커지고 똑똑해지지만 동시에 천장에 부딪힌다. 옵션을 잘 제공하고 잘 순위 매긴다. 그러나 계산이 끝나고 선택이 내려져야 하는 순간, 우리는 여전히 인간에게 손을 뻗는다 — 아직도 책임질 수 있는(answerable) 유일한 존재이기 때문이다. 에이전트는 옵션을 평가하는 능력을 계속 키울 수 있다. 그러니 다음 프론티어는 인간이 판단에서 에이전트보다 더 잘하도록 역량을 키우는 것이다.
그래서 흥미로운 질문은 “에이전트가 취향을 가질 수 있는가”가 아니다 — 그건 가능하다고 가정해야 한다. 진짜 질문은 “에이전트가 취향을 갖게 됐을 때 무엇이 남는가” 이고, 답은 판단이다. 판단은 쉽게 복제되지 않는다. 능력이 아니라 책임(liability) 이기 때문이다.
덧붙여, 판단은 보편 기술이 아니다. 모든 실수를 다 겪어본 사람은 없다. 스킬은 우리가 많은 실수를 보고 살아남은 영역에서 자란다.
사례: Apple, 그리고 Maps라는 서명
Apple의 디자인 취향은 자주 예외적이라고 인용된다. MacBook, iPhone을 떠올려 보면 사용자에게 얼마나 매끄럽게 작동하고 느껴지는지에 크게 마음 쓴다는 게 분명하다. 그러나 취향과 판단의 책임을 동시에 건드리는 다른 사례가 있다 — Maps다.
2012년 Apple은 iOS에서 Google Maps를 걷어내고 자체 버전을 냈다. 취향은 있었다 — 확대해도 선명하게 유지되는 벡터 렌더링, 훌륭한 타이포그래피. 그러나 더 큰 문제들이 있었다. 다리가 강으로 녹아내리고, “Berlin”을 검색하면 남극으로 데려가고, 호주의 한 마을이 사막 한복판 70km 밖에 잘못 찍혔다.
Osmani가 주목하는 건 그다음이다. Tim Cook이 iOS Maps 팀을 탓하는 대신, apple.com에 1인칭으로 사과문을 올려 여러 해에 걸쳐 큰 조직 전반에서 내려진 결정들에 대한 책임을 스스로 졌다. 당시 보도에 따르면 그가 서명을 요청받은 유일한 사람은 아니었을 수도 있지만, 사실이든 아니든 이름이 올라간 건 그였다. 취향도 실패도 그때 다 명백했다. 값을 치른 건 그 서명이었다.
이것이 당신의 일에 적용되는 방식
많은 사람은 그렇게 공개적으로 무언가에 서명하고 책임을 지려 하지 않을 것이다. 하지만 이 구조는 우리 일에도 그대로 적용된다.
테스트가 그리 좋지 않다는 걸 알면서 승인하는 pull request.
충분한 테스트도, 사용자와의 대화도 없이 서둘러 내보낸 새 UI.
이런 것들은 공개 사과문까지 가지는 않지만, 그것들이 가르치는 교훈은 당신이 짊어진다. 취향은 노출을 통해 복리로 쌓이고(taste compounds through exposure), 판단은 후과를 통해 복리로 쌓인다(judgment compounds through the consequences).
닫는 조언
취향을 다듬고 싶다면: “좋다 / 싫다” 같은 말을 넘어서 왜 무언가가 성공하거나 실패하는지를 물어라. 같은 것의 여러 버전을 연구하고 그 미묘한 차이를 음미할 수 있는지 보라.
판단을 기르고 싶다면: 어려운 결정을 직접 내려라(make the hard calls). 무슨 일이 일어날 거라 예상했는지 적어두고, 결과에 충분히 가까이 머물러 내가 맞았는지 — 더 중요하게는 틀렸는지 — 를 배워라. 시간이 지나면 내면의 목소리를, 무엇이 고품질인지에 대한 자신의 진짜 믿음을 신뢰하라.
(원문은 말미에 “Pangram 4가 이 글을 100% 사람이 쓴 것으로 판정했다”고 덧붙인다 — AI 글쓰기 시대에 저자가 남긴 반쯤 농담 같은 서명이다.)
분석과 인사이트
1) “취향 vs 판단”은 “능력 vs 책임”의 프레임으로 바꿔 읽어야 한다. 이 글의 진짜 통찰은 취향의 정의가 아니라, 판단을 능력의 스펙트럼에서 떼어내 책임(liability)의 영역으로 옮긴 것이다. 우리는 흔히 “AI가 인간을 대체하느냐”를 능력 경쟁으로 본다. 누가 더 잘하나. 하지만 Osmani는 판단을 성능 게임 밖으로 끌어낸다. 판단이 남는 이유는 더 똑똑해서가 아니라 서명할 수 있어서다. 이건 AI가 아무리 좋아져도 원리적으로 닫히지 않는 격차다. 책임은 성능이 아니라 주체성(who is answerable) 의 문제이기 때문이다.
2) 이 위키의 다른 논증들과 정확히 맞물린다. The Untrainable는 “측정할 수 있는 일은 학습 가능하고 따라서 commodity가 된다”고 말했다. Osmani의 언어로 옮기면 취향은 벤치마크 가능해지는 쪽이고 — 그래서 넘어가고 — 판단은 벤치마크 자체가 성립하지 않는 쪽이다. 서명은 채점할 수 있는 산출물이 아니라 관계(누가 후과를 지는가)이기 때문이다. Pratik Bhavsar의 taste 글이 “취향 = 내부 평가 함수의 품질”을 강조했다면, Osmani는 거기서 한 발 더 나가 그 평가 함수마저 에이전트가 가질 수 있다고 인정한 뒤, 그럼에도 남는 것을 지목한다.
3) 개발자에게 가장 아픈 구절은 “reps”와 “consequences”다. 취향이 반복으로, 판단이 후과로 복리 성장한다면, 에이전트에게 반복과 후과를 다 위임하는 순간 둘 다 자라지 않는다. 이건 에이전틱 코딩의 함정과 탈숙련(deskilling) 연구가 데이터로 보여준 것과 같은 경고다. 코드 생성을 넘기는 건 취향의 reps를 넘기는 것이고, “돌아가니 머지”를 반복하는 건 판단의 consequences를 회피하는 것이다. 둘 다 근육이라 안 쓰면 위축된다.
4) 이견 — “취향은 완전히 넘어간다”는 낙관은 조금 이르다. Osmani는 논지를 강하게 세우려고 “에이전트가 취향을 갖는다고 가정하라”고 못 박는다. 실무적으로는 모델이 흉내 내는 건 취향의 산출물(평균적으로 그럴듯한 선택)이지 취향의 원천(예상 밖의 다양성에 노출되어 새 기준을 세우는 능력)이 아니다. 오히려 모델은 훈련 분포의 중앙값으로 수렴하는 경향이 있어, 이 글이 강조한 “다양성과 마찰”의 반대편에 서기 쉽다. 그래서 “취향도 지켜야 할 인간의 자산”이라는 여지는 생각보다 크다. 판단이 방어선이라면, 취향은 아직 완전히 함락되지 않은 고지다.
5) 조직적 함의 — 책임은 위임되지 않지만 취향은 표준화된다. Maps 사례의 진짜 교훈은 “CEO가 사과했다”가 아니라, 결정이 조직 전반·수년에 걸쳐 분산되어 있어도 서명은 단수(單數)로 수렴한다는 것이다. AI 파이프라인이 옵션을 대량 생산하는 조직일수록, 최종 서명이 누구 이름인지를 명시적으로 설계해야 한다. 취향은 도구·프롬프트·스타일 가이드로 팀 전체에 복제·표준화할 수 있지만, “이게 나간다”에 이름을 거는 자리는 자동화하면 안 된다. 그건 버그가 아니라 기능이다.
적용 포인트
취향의 reps를 아웃소싱하지 마라. 에이전트가 코드를 쓰더라도, 여러 후보를 나란히 놓고 “왜 이게 더 나은가”를 직접 언어화하는 훈련은 스스로 하라. “좋다/싫다”를 “왜 성공/실패하는가”로 바꾸는 습관.
다양성과 마찰을 일부러 섭취하라. 같은 피드·같은 스택만 보면 취향은 평균값으로 수렴한다. 낯설고 불편한, 질문을 강제하는 결과물에 의도적으로 노출되라.
판단에는 항상 이름을 붙여라. 승인하는 PR, 내보내는 UI에 “테스트가 약하다는 걸 알면서 머지한다”를 명시하고 그 결정을 소유하라. 서명 없는 결정을 만들지 마라.
예측을 적어두고 후과에 가까이 머물러라. 하드콜을 내릴 때 “무슨 일이 일어날 것 같다”를 기록하고, 실제 결과와 대조해 틀린 경우를 특히 복기하라. 판단은 후과에서만 복리로 자란다.
파이프라인에서 ‘서명 노드’를 명시적으로 설계하라. AI가 옵션을 대량 생산하는 워크플로일수록, 최종 책임자가 누구인지를 조직도가 아니라 결정 단위마다 분명히 하라.
취향은 표준화하고, 판단은 자동화하지 마라. 스타일 가이드·프롬프트·리뷰 체크리스트로 취향은 팀에 복제하되, “무엇을 출시하는가”의 서명은 사람에게 남겨라.
마무리
Osmani의 글이 값진 이유는 위안이 아니라 경계선을 그어주기 때문이다. AI 시대 인간의 몫을 “창의성”이나 “공감” 같은 흐릿한 단어로 방어하는 대신, 그는 책임질 수 있는 유일한 존재라는, 원리적으로 이전 불가능한 지점에 말뚝을 박는다. 취향은 어쩌면 넘어갈 것이다 — 그래도 좋다. 진짜 질문은 그다음에 남는 것이고, 남는 것은 선택에 이름을 걸고 후과를 짊어지는 일이다. 그러니 지금 해야 할 두 가지는 분명하다. 취향의 reps를 계속 쌓고, 판단의 하드콜을 계속 내려서 그 후과로부터 배우는 것. 에이전트가 아무리 좋아져도, 서명란은 여전히 비어 있다.
더 읽어보기
원문 — Taste, Judgment and AI (Addy Osmani)
코드가 공짜가 된 시대의 ‘취향(taste)’ — 30x AI 엔지니어가 되는 법 — ‘취향 = 내부 평가 함수의 품질’을 다룬 자매 논의. 이 글은 그 평가 함수마저 에이전트가 가질 때 남는 것을 묻는다
The Untrainable — 측정할 수 없는 일에 가치가 남는다 — ‘벤치마크 가능한 것은 commodity가 된다’는 논증. 취향/판단 구분과 정확히 겹친다
그냥 그렇게 말하면 된다 — 인간의 가치를 ‘AI보다 잘함’으로 증명하지 말라 — 인간의 몫을 성능 경쟁 밖에 두는 인접 관점
에이전틱 코딩은 함정이다 — reps와 스킬 위축의 문제의식을 코딩 실무로 옮겨 읽기
AI가 우리의 실력을 망치고 있는가 — 탈숙련(deskilling) 연구 — 취향/판단의 reps·consequences를 위임할 때 실제로 실력이 준다는 데이터 근거

취향과 판단, 그리고 AI — 에이전트가 못 가져가는 것은 ‘이름을 거는 일’이다 (Addy Osmani)

댓글