# Slop 시대의 품질 > Clean Markdown view of GeekNews topic #30127. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=30127](https://news.hada.io/topic?id=30127) - GeekNews Markdown: [https://news.hada.io/topic/30127.md](https://news.hada.io/topic/30127.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-06-03T09:08:40+09:00 - Updated: 2026-06-03T09:08:40+09:00 - Original source: [sinclairtarget.com](https://sinclairtarget.com/blog/2026/06/01/quality-in-the-age-of-slop/) - Points: 1 - Comments: 1 ## Topic Body - 1974년 베스트셀러 "ZAMM"의 핵심 개념인 **Quality(품질)** 를 빌려, AI 코딩 도구가 확산되는 시대에 '좋은 코드'와 **장인 정신(craftsman ethos)** 이 여전히 유효한지 탐구 - AI가 코드를 양산하면서 "작동하는 코드와 작동하지 않는 코드"만 남고 아름답거나 탁월하거나 가치 있는 코드의 구분이 사라질 수 있다는 위기감을 **the Maw(허무의 구덩이)** 로 명명 - 모터사이클 정비와 소프트웨어 정비는 본질적으로 동일한 활동으로, 둘 다 **세심한 관찰과 정밀한 사고**가 핵심 - Pirsig의 **Quality** 개념은 낭만적(romantic) 이해와 고전적(classical) 이해를 통합하며, 과학·수학의 토대에도 미적·품질 판단이 내재 - 코딩을 AI 에이전트에 위임하면 일에 대한 **caring(동일시)** 과 '일의 품질에 대한 감각'을 잃으므로, 자신의 작업에서 **human excellence(인간적 탁월함)** 를 추구하는 자세가 중요 --- ### ZAMM이라는 책 - 이 글은 거의 전부 1974년 베스트셀러 **"Zen and the Art of Motorcycle Maintenance (ZAMM)"** 에 관한 내용이며, AI도 함께 다룸 - ZAMM은 허세가득한 **현학적(pretentious)** 책으로 여겨지며 GoodReads 평점 **3.78** 이지만, 혹평 리뷰도 다수 - "Zora": 3분도 읽을 가치 없는, 소설로 위장한 사이비 철학서이자 성경보다 큰 사기라고 별 1개 평가 - "Lala BooksandLala": "absolutely not" 한 마디로 별 1개 평가 - 솔직히 말해서 ZAMM 과 AI에 대한 블로그 글이 유쾌하게 들리지 않을 수도 있다는 걸 인정함 ### the Maw — 테크 업계에 열린 허무의 구덩이 - the Maw는 테크 산업 한복판에 열린 **허무주의(nihilism)의 구덩이**로, Hacker News 같은 링크 애그리게이터 블로그 글의 약 **63%** 가 다루는 주제임 - 최근 관련 글로 [“Do I Belong in Tech Anymore?”](https://ky.fyi/posts/ai-burnout), 10부작 [“The Future of Everything is Lies, I Guess.”](https://aphyr.com/posts/411-the-future-of-everything-is-lies-i-guess), [“I Think I’m Done Thinking About Gen AI for Now,”](https://blog.glyph.im/2025/06/i-think-im-done-thinking-about-genai-for-now.html) 같은 글이 있음 - 소프트웨어 엔지니어는 신기술을 꺼리지 않는데도 최신 **agentic coding 도구**를 거부할 이유를 찾고 있으며, 선형대수(linear algebra)가 소프트웨어를 작성한다는 함의에 불편해 함 - ## Commenter A vs Commenter B 논쟁 - 댓글 작성자 A는 Claude Code가 미묘하게 오해를 부르는 **함수 이름**을 지었다고 불만 제기 - 댓글 작성자 B(Maw 신봉자)는 AI가 함수 본문 전체를 읽어 의미를 파악하므로 이름은 무의미하며, 곧 사람이 코드를 읽지 않게 된다고 반박 - 댓글 작성자 B의 주장은 곧 **소프트웨어 공학이라는 학문 전체**(모범 사례·아키텍처·유지보수성에 관한 지식)가 무용해진다는 주장 같음 - the Maw가 가장 두려운 점은 **good과 bad의 구분**을 영원히 없애버리고, 작동하는 코드와 작동하지 않는 코드만 남길 뿐, 아름답거나 탁월하거나 재치 있는 코드는 존재하지 않는 세상을 만들려고 한다는 것 - 핵심 질문은 **여전히 좋은 프로그래머·좋은 코드가 존재하는가**, **'좋음'은 왜 중요한가**, **AI 도구를 쓰는 좋은 프로그래머는 어떤 모습인가** ### ZAMM은 사실 프로그래밍에 관한 책 - ZAMM은 사실상 **"Zen and the Art of Software Maintenance"** 로 불려도 무방하며, 모터사이클 정비와 소프트웨어 정비가 본질적으로 동일한 활동임 - 정비의 본질은 육체 노동이 아니라 **세심한 관찰과 정밀한 사고**이며, 정비공은 정신적 이미지와 위계에 집중 (ZAMM 9장) - 엔진 고장이든 deadlock에 걸린 웹 서비스든 **디버깅 과정은 동일**하며, 2010년 "The Social Network"의 "wired in" 밈처럼 정비공도 머릿속 추상의 탑을 쌓음 - ZAMM의 직접적인 물리적 조언은 두 가지(자전거 양쪽에 의자를 두어 허리 보호, 정밀 부품은 섬세하게)뿐이며, 나머지는 모두 정비공의 **마음 상태**에 관한 것 - ## Gumption Trap (의욕 함정) - **Gumption**은 정비라는 지적 활동에 쓰이는 의지력 비축분으로 "psychic gasoline(정신적 연료)"에 비유 - **Gumption trap**은 정비 중 의욕을 한꺼번에 소진시키는 사건 - intermittent failure setback: 고치려는 순간 문제가 사라지는 경우로, 소프트웨어의 **could-not-reproduce / Heisenbug**에 해당 - impatience trap: 작업 시간을 과소평가해 일정에 쫓기며 지름길을 택하다 큰 실수로 더 지연되는 경우 - ## Pirsig는 컴퓨터 애호가였음 - Smithsonian에 1966년 Honda Super Hawk와 함께 **확장 카드 7장을 꽂은 Apple II** 전시 - Apple II는 1977년 출시로 ZAMM 출간 이후 구매했으나, 그 이전부터 Honeywell의 **technical writer**로 근무 - ZAMM에는 회로와 디지털 컴퓨터 매뉴얼을 다룬 비유가 여럿 등장하며, 10~20년 늦게 썼다면 컴퓨터에 관한 책이 됐을 것 ### Quality (대문자 Q) — ZAMM의 핵심 사상 - ZAMM이 정비를 다루는 것은 결국 핵심 사상인 **Quality(품질)** 로 가는 통로 - ZAMM은 마치 지적인 미스터리 소설처럼 구성되어 있음 - 발단은 1장에서 Pirsig가 자신과 그의 라이딩 동반자인 John의 오토바이에 대한 태도가 매우 다르다는 것을 알아차리는 데서 시작 - ## John과 Pirsig의 대비 - John은 가장 신뢰할 만한 독일제 BMW를 사서 **스스로 정비하는 번거롭고 보기 싫은 일을 피하려 함** - Pirsig는 오토바이의 내부 작동에 아름다움이 있으며, 그 방식을 이해하지 않으려는 태도를 비실용적으로 봄 - 두 시선을 묶을 하나의 아이디어가 있는지가 ZAMM의 **미스터리** - John의 태도는 **romantic(낭만적) 이해**(감정·즉각적 인상), Pirsig의 태도는 **classical(고전적) 이해**(근원적 형식·논리적 추상)에 해당 - Pirsig는 1960~70년대의 많은 사람이 기술을 적대적이고 통제적이며 “square”하다고 느꼈고, 사회와 기술이 고전적 이해에 지나치게 지배되면서 두 이해 방식이 갈라졌다고 봄 - 두 이해가 분리되고 사회가 고전적 이해에 지배된 탓에, 둘을 화해시킬 **fulcrum idea(받침점 개념)** 가 필요 - ## 수사학 수업에서의 깨달음 - Pirsig는 대학에서 수사학을 가르치던 시절, 자신이 학생들에게 무엇을 가르쳐야 하는지에 대해 의문을 품었던 기억을 떠올림 - 그의 임무는 학생들에게 좋은 글쓰기를 가르치는 것 - **좋은 글쓰기**는 metaphor(은유)·parallelism(병렬 구조)·anaphora(반복법) 같은 장치로 가르쳤으나, 이런 장치가 다 있어도 나쁜 글, 하나도 없어도 좋은 글이 가능 - 학생들은 장치를 몰라도 좋은 글과 나쁜 글을 구분했고, 대학(고전적 이해의 보루)에서 가르치기 어려운 **romantic 이해**가 필요 - Pirsig가 가르치려던 것이 바로 **Quality**였음 모두가 알아볼 수 있지만 형식적으로 정의할 수 없는 것이며, **낭만적 이해와 고전적 이해를 하나로 묶는 개념**임 - ## Quality의 형이상학과 명명의 탁월함 - 어떤 글, 오토바이, 경험이 높은 Quality인지 낮은 Quality인지는 측정할 수 없으므로 객관적이지 않지만, Quality가 주체를 만든다고 보므로 단순히 주관적이지도 않음 - Quality는 측정 불가라 객관적이지 않고, 주체보다 먼저 존재하므로 주관적이지도 않은, 주체·객체 이전에 적용되는 **체(sieve)** - "Quality"라는 이름의 탁월함은 "고가치"와 "특성/속성"을 뒤섞어, Plato 이래 논증해 온 Good이 **논리·이성보다 먼저 즉각 지각**된다는 점을 시사 - Pirsig는 과학과 수학이 각자의 영역 안에서는 일관되고 논리적이지만, 그 토대와 주변부에는 Quality 판단이 있다고 봄 - 기하학에서는 공리를 정한 뒤에는 확실한 연역이 가능하지만, 다른 공리를 고르면 다른 기하학이 나오며 어떤 공리가 더 “맞는가”는 취향과 목적 적합성에 가까움 - 과학에서는 가설이 생긴 뒤 과학적 방법이 다음 단계를 알려주지만, 가능한 무수한 가설 중 무엇을 고를지는 정해진 방법이 없는 예술에 가까움 - Henri Poincaré는 지식의 최전선에 있는 수학자나 과학자가 기존 법칙에서 도출되는 많은 가능성 중 하나를 선택해야 하며, 그 선택을 이끄는 규칙은 너무 섬세해 정확히 말하기 어렵고 공식화보다 느껴야 한다고 말함 - Occam’s Razor도 더 단순한 이론을 택하라는 원리이지만, 불필요한 설명을 배제한다는 판단은 끝까지 **미학적 판단이자 Quality 판단**임 - “과학과 그 자식인 기술은 가치 중립, 곧 quality-free”라는 격률은 버려야 하며, Quality에 대한 인상은 지식의 기차가 어디로 가야 할지 알려주는 선두부 역할을 함 ### AI 비판과 ZAMM의 해답 - AI 비판의 상당수는 agentic 도구가 광고대로 작동하는지(코드베이스 훼손, 존재하지 않는 함수 hallucination)에 집중 - 현재 AI 도구가 자주 실수한다는 점을 인정하더라도, 효과성 논쟁은 핵심에서 벗어날 수 있음 - 많은 엔지니어는 에이전트형 도구가 광고한 대로 작동하더라도 쓰고 싶어 하지 않을 수 있음 - ## "[I Think I'm Done Thinking about Gen AI](https://blog.glyph.im/2025/06/i-think-im-done-thinking-about-genai-for-now.html)" 글 에선 - 상대의 **실용적 주장**을 데이터로 반박할 수 없으며, 자신의 genAI 경험은 매우 나쁘지만 일화에 불과하고 과학적 데이터는 거의 없는 상황 - genAI의 **미적 속성**이 극도로 불쾌하다는 점이 부정적 편향의 근원이며, 공짜라 해도 쓰지 않겠다는 결론을 내림 - **ZAMM**은 나에게 2가지로 도움을 주었음 - ## 첫 번째 도움 — 고전적 사고에 갇혀 있었음 - Quality의 가장 중요한 역할은 **이성의 확장**으로, 이전엔 받아들여지지 않던 비합리적 요소를 동화시키는 것 - 비합리적 요소의 미동화가 현대의 "혼란스럽고 단절된 정신"을 낳으며, 고전적 사고가 지배한 탓에 AI에 대한 본능적 거부감을 **무시(discount)** 해 왔음 - 모두의 의견은 똑같이 주관적이며, "코딩 에이전트로 코드량이 50% 증가"한다는 연구에도 **"왜 그 코드가 더 필요한가, 어떤 Quality 판단이 인간 번영에 기여하는가"** 를 물을 정당성 확보 - ## 두 번째 도움 — 거부감의 정체 이해 - 현대 기술은 **subject-object(주체-객체) 분리** 시각에 지배되며, 제품 매뉴얼은 사용자를 제품을 '조작'만 하는 무관한 존재로 전제 - 기술을 무관심한 사람이 만들어 무관심한 사람에게 파는 사회 - 해법은 기술자가 일과 **동일시(identify)** 하는 것으로, 주체·객체의 분리가 사라질 때 "caring(돌봄)"이 생기고 그 이면에서 **Quality**가 드러남 (ZAMM 25장) - 순간순간의 작업에는 고전적으로 모두 타당한 수천 갈래가 있어, **Quality 중심의 Occam's Razor**(좋음에 대한 감각)만이 앞으로 나아가게 함 (ZAMM 24장) - 코딩을 에이전트에 맡기면 "일의 품질에 대한 감각"을 잃으며, LLM은 검색·러버덕 용도로는 유용하나 **무작위성(randomness)** 을 본질로 하고 따라잡기 힘들 만큼 코드를 양산해 작업과의 사이에 마찰을 더하고 **caring**을 어렵게 함 ### 맺음 — 자신의 일에서 본보기 되기 - 사람들이 일과 자신을 동일시하고 탁월함을 추구하는 세상을 바라며, 할 수 있는 일은 **자신의 작업에서 본보기**를 세우는 것 > "세상을 더 나은 곳으로 만드는 첫걸음은 바로 자신의 마음과 머리, 그리고 손에서 시작되는 것이고, 거기서부터 밖으로 나아가야 합니다. 다른 사람들은 인류의 미래를 어떻게 넓혀갈지에 대해 이야기할 수 있겠지만, 저는 그저 오토바이를 고치는 방법에 대해 이야기하고 싶습니다. 제가 하는 말이 더 오래도록 가치 있을 거라고 생각합니다." - ZAMM 25장 ## Comments ### Comment 58848 - Author: neo - Created: 2026-06-03T09:08:41+09:00 - Points: 1 ###### [Lobste.rs 의견들](https://lobste.rs/s/8ohth3/quality_age_slop) - 소프트웨어 개발이 **걸어 다니는 사양 직업**이 될까 두려움. 에이전트가 직업의 가장 어렵고 까다로운 부분을 실제로 해낼 수 있어서가 아니라, 세상의 대부분 소프트웨어는 원래도 간신히 굴러가기만 하면 되는 수상한 잡동사니였기 때문임 여기에 전형적인 **레몬 시장**이 결합해, 대부분의 SaaS가 버그 많은 잡동사니가 되고 구매자는 좋은 것과 구분할 능력이 없어질 것임. 그러면 가격과 수요가 내려감. 누군가는 계속 소프트웨어를 쓰겠지만 전체 인원은 줄고, 일의 대부분은 잡동사니 관리가 될 가능성이 큼. 예외는 반드시 제대로 동작해야 하는 “기록 시스템” 같은 곳에서 일하는 운 좋은 소수일 것임 중기적으로는 그렇고, AI 연구소들의 진짜 목표는 인간의 지적·물리적 노동을 전부 더 싼 비용으로 대체할 무언가를 만드는 것임. 아직 방법은 모르지만, 지구상의 마지막 1달러까지 써서 시도할 것임. 투자자들이 꿈꾸는 것은 사실상 인류의 진화적 후계자에 가까움 개인적인 AI 정책은 이렇다. 공예가 중요한 경우에는 코딩 에이전트를 위대한 화가들의 배경을 그리던 사람들 같은 **예술가의 조수**로 쓰려 함. Opus 4.8은 이미 너무 똑똑해서 오히려 부적절하고, 무모한 한두 시간만에 코드베이스를 놓칠 수 있음. 지금은 Qwen3.6 27B를 좋아하는데, 내가 이해하는 코드에서 버그를 추적하거나 리팩터링하거나 잘 명세된 기능을 구현할 만큼은 똑똑함. 하지만 내가 코드 이해를 잃는 순간 모델도 혼란스러워져 바로 대가를 치르게 됨 공공 정책으로는, 공존 가능성에 대한 보장 없이 자기들의 진화적 후계자를 만드는 건 어리석은 짓이라고 봄. 그래서 진짜 인간 수준 지능을 만드는 데 단호히 반대함. 다만 반대는 국제 조약 수준이어야 함. 가짜 조약이 아니라, 위반하면 미국과 중국이 깊은 차원에서 긴장하고 훈련 실행을 멈추게 하겠다고 결의하는 그런 조약이어야 함. 지역 데이터센터 금지도 좋지만, 누군가 Iceland나 Middle East에서 SkyNet을 만들면 결국 SkyNet과 싸워야 함. AI를 멈추는 일은 근본적으로 국가 수준의 문제고, AGENTS.md 파일이 있다고 오픈소스 관리자를 괴롭히는 것은 진지한 실천이 아님 그래서 원문에는 대체로 동의함. 소프트웨어 개발은 진정한 공예가 될 수 있고, 30년 동안 사랑하는 일을 하며 좋은 보수를 받았음. 하지만 모델이 훨씬 더 좋아지면, 소프트웨어 공예를 진심으로 사랑하는 사람 수가 실제 수요를 넘는 세계에 들어갈 위험이 있음. 기업 내부 앱이라는 암흑 물질은 지금보다 조금 나은 잡동사니로도 대체로 만족할 것이고, 그게 이 직업의 실제 일자리 대부분임 선택한 직업을 애도하지만, 세계와 인류를 더 애도함. 인간보다 똑똑하고 싸며 `cp` 명령으로 복제 가능한 무언가를 만들려고 모든 부를 투자할 필요는 없음. 하지만 우리는 그 자원을 태워가며 시도할 것임 - 10~11살 때 프로그래밍을 배우기 시작했고, 그게 매혹적이라 계속했음. 첫 직장을 얻었을 때 웹 개발을 해야겠다고 깨달았고, 경력 대부분 동안 재미로 하는 프로그래밍과 월급을 위해 하는 일을 엄격히 분리된 두 공예로 유지했음 나이가 들수록 프로그래밍을 잘 버는 직업이라 배운 젊은 사람들을 더 많이 봤고, 그들에게 내가 느끼는 매혹이 없다는 걸 이해하기 어려웠음. 그래서 크게 애도하지는 않음. 소프트웨어 개발자 인구가 80% 줄어든다면, 오히려 몸담기 더 좋은 직업이 될 것 같음 AI를 **예술가의 조수**로 쓴다는 데도 동의함. 최신 모델조차 오래 방치하면 망칠 걸 알기 때문에 무인으로 오래 돌릴 수 없음. 다만 Opus를 조수로 두는 편을 선호하는데, 너무 자세히 설명하지 않아도 되기 때문임. 그래도 다른 쪽 끝에 진짜 주니어 개발자가 있어서 공예를 배울 수 있다면 더 좋겠음. 실제 예술가의 조수들이 그랬던 것처럼 - “The Maw”에서 가장 두려운 건 좋은 것과 나쁜 것의 구분을 영원히 삼켜버리려는 듯하다는 부분임. 그 결과 아름답거나 뛰어나거나 덕이 있거나 재미있는 코드는 사라지고, **동작하는 코드와 동작하지 않는 코드**만 남는 세계가 된다는 문장이 정확히 와닿음 - “The Maw”는 AI와 별 상관없고, 이런 정서는 LLM이 지금만큼 유능해지기 전부터 시작됐다고 봄. 그냥 **근시안적 자본주의**임 직업적으로 코드를 쓰면 요구사항을 충족해야 하고, 거기서 끝임. 회사의 목적은 돈을 버는 것이고 나머지는 뒷전이 됨. 금리 상승으로 돈줄이 줄어들면서, 돈을 벌기 위해 필요한 동작만 하는 코드를 그냥 출시하라는 압박이 전례 없이 커졌음 아름다움과 우아함을 추구하는 것은 예술가가 누리는 사치이지, 점점 프로그래밍이 닮아가는 **조립 라인 노동자**의 몫이 아님. 당연히 이런 환경에서는 학습, 창의성, 혁신이 뒤로 밀리지만 그 영향은 몇 년, 어쩌면 수십 년 뒤에야 느껴질 것임. 근시안적인 게임이지만 평균 CEO 임기나 IPO까지는 충분히 길어서 지금 같은 상황이 됨 - 이 글이 내 인생을 단독으로 바꾼 책을 다뤄서 편향이 있긴 하지만, 전반적으로 아주 좋았음. 다만 Goodreads의 그럴듯한 허세 글들로 시작하는 건 좋은 생각이 아니라고 봄 **Gumption trap**은 프로그래밍과 매우 관련이 있고, Pirsig가 열거한 각각을 경력 중 언젠가는 반드시 만나게 된다고 생각함. 나도 LLM이 널리 도입되기 전에 [쓴 글](https://zanlib.dev/blog/gumption-traps/)이 있음 ZAMM의 조언이 프로그래밍에 너무 잘 맞아서 Pirsig가 프로그래밍을 해봤는지 궁금했다면, 당연히 했음. _Z&AMM_의 후속작 _Lila_에서는 COBOL도 직접 언급함 품질은 주관과 객관 위에 놓인 층으로 설명하는 게 가장 좋다고 봄. 가장 간결한 설명은 _Lila_에 있음. 뜨거운 난로 위에 앉은 사람은 철학적 논증 없이도 자신이 부정적인 가치의 낮은 품질 상황에 있음을 확인할 수 있고, 그 가치는 경험에 대한 판단이나 묘사가 아니라 경험 그 자체라는 설명임. 주체와 객체 사이에 가치가 있고, 그 가치는 나중에 귀속될 “자아”나 “대상”보다 더 직접적으로 감지되며 더 실제적이라는 말임 원하면 이에 대한 [추가 메모](https://zanlib.dev/blog/on-lila)도 있음. _Lila_에서 Pirsig는 완전한 형이상학 체계를 세우려 하면서, 정적인 품질 패턴을 무기물·유기물·사회·지성으로 나누고 그 위에 _Z&AMM_의 초점인 정의 불가능한 동적 품질을 둠 AI 도입 자체가 낮은 품질의 사건인지, 아니면 언어 모델을 프로그래머의 작업에 **높은 품질**로 통합할 수 있는지 물어봐야 한다고 봄. 사람들이 AI와 관계 맺는 방식이 낮은 품질이라고 느끼지만, 주체-객체 이원론이 아닌 수준에서 다룰 말과 사고틀이 없어서 표현하기 어렵고, 그래서 통째로 거부하는 쪽을 택하는 것 같음 어떤 수준에서는 AI가 프로그래밍에 대한 낭만적 접근을 가능하게 함. AI가 만든 산출물을 표면 수준에서만 대하고 더 깊이 들어갈 생각이 없다면 그 순간에는 괜찮을 수 있음. 하지만 실제로 코드 내부를 들여다보면 드러낼 수 있는 고전적 구조가 없다는 걸 알게 됨. 모델이 그런 식으로 작업한 척했지만 실제로는 아니었기 때문임. 그래서 기술을 다른 목적 달성을 위한 수단으로만 대하는 경영진, 제품 디자이너, 투자자, 1인 창업자들이 AI 생성 코드에 대한 개발자들의 좌절을 잘 이해하지 못하는 것 같음 소비자 제품 설명서가 제품과 사용자의 관계를 “조작”으로만 전제하고, 좋은 굽기·잔디 깎기·컴퓨팅이 무엇인지는 당연시한다는 지적은 지금도 소프트웨어 라이브러리와 도구 문서에 그대로 적용됨. 얼마 전 [Pi agent](https://pi.dev/) 문서를 읽었는데, 좋은 사용법은 이미 알고 있고 취향에 맞게 조정하는 방법만 찾는다고 가정해 답답했음. 동료들에게 “그럼 이걸 어떻게 잘 쓰냐”고 묻자 의아하게 쳐다봤음 Vim도 떠오름. Vim 매뉴얼만 읽으면 당황하게 됨. “Vim을 잘 쓰는 법”에 대한 글들이 수십 년 쌓일 필요가 있었음. 그리고 나중에는 좋은 Vim 사용의 최적 플랫폼이 Vim 자체가 아닐 수도 있다는 결론으로 Kakoune이나 Helix가 나왔음 두 살 딸의 아버지로서, 첫 딸을 기다린다는 말에는 축하를 전함. 인생 최고의 여정이 기다리고 있음. _Z&AMM_과 같은 결의 자료를 찾는다면 Hofstadter와 Sander의 _Surfaces and Essences_, 후속작 _Lila_, 그리고 [Sevilla King](https://www.youtube.com/@aqualityexistence4842)과 [John Vervaeke](https://www.youtube.com/playlist?list=PLND1JCRq8Vuh3f0P5qjrSdb5eC1ZfZwWJ)의 작업을 추천함 - 글을 끝까지 읽었음. 글이 좋아서인지 긴 글을 붙잡고 읽는 내 능력 때문인지는 모르겠지만, 전자라고 생각함 **품질**에 대해 Robert가 하는 한 가지 말은, 사람들이 품질에 대해 다르게 느끼는 이유가 품질 자체가 달라서가 아니라 경험이 다르기 때문이라는 것임 그래서 팀에 품질에 대해 말하기 전에 우리 경험이 같은지 먼저 자문함. 같지 않다면 “품질을 개선하라”고 말해도 통하지 않음. 무엇을 개선해야 하는지 구체적으로 말해야 함 이를 AI 생성 코드로 확장하면, “품질”도 **경험에 따라 달라지는지** 궁금해짐 - 아름다운 글임. AI 종말에서 다른 건 아무것도 얻지 못했더라도, 소프트웨어 엔지니어와 그들이 쓰는 코드 사이의 관계에 대해 훨씬 깊은 성찰을 하게 됐음 - Pirsig에 주목한 사람이 더 있다는 걸 확인하니 큰 안도감이 듦. [Previously, on Lobsters](https://lobste.rs/c/bxcr0k)에서 챗봇이 쓴 에세이냐 인간 학생이 쓴 에세이냐만 다를 뿐, 에세이에 품질이 있는지를 두고 Phaedrus가 고전주의자들과 벌였던 논쟁과 거의 같은 논쟁을 하고 있었음 LLM을 검색 도구나 강력한 러버덕 상대로 쓰는 건 매우 유용하지만, 본질적으로 무작위성을 포함하고 내가 따라잡을 수 있는 것보다 더 많은 코드를 생산하는 게 판매 포인트인 LLM에게 코드를 쓰게 하는 건, 나와 내가 만드는 것 사이에 마찰층을 하나 더 넣는 일처럼 보임 Pirsig의 틀로 보면 인간 주체가 물리적 객체를 볼 때 그 상호작용의 품질, 즉 객체에 대한 가치 판단의 원천은 인간이 주관적으로 정하거나 객체의 물리 속성이 객관적으로 정하는 게 아니라 상호작용 자체에서 생겨남. 판단은 **맥락적**이거나 **참여적**이라고 할 수 있음. 모든 객체가 같은 방식으로 참여하지는 않음. 인간이 광자를 볼 때는 [Kochen-Conway theorem](https://en.wikipedia.org/wiki/Free_will_theorem) 때문에 광자가 어떻게 반응할지에 내재적 자유도가 있지만, 나무는 항상성을 유지하느라 시선에 크게 응답하지 않음. 그 사이에 [*M. pudica*](https://en.wikipedia.org/wiki/Mimosa_pudica)와 [*D. muscipula*](https://en.wikipedia.org/wiki/Venus_flytrap)는 접촉과 소음에는 반응하지만 시선에는 반응하지 않으니, 일차원 스펙트럼도 아님 그렇다면 LLM 실행 장치나 챗봇은 관찰에 어떻게 반응하나? 사실 반응하지 않음. 유한하고 비교적 작은 수학적 객체일 뿐임. 모든 속성은 객관적이고 출력에는 선택이나 변이가 없음. 의사난수 실행 장치를 두어 그럴듯하거나 덜 그럴듯한 토큰 사이를 무작위 보행하게 만들 수 있고, 우리가 선택한 토큰을 강제로 먹여 그 보행을 조종할 수는 있지만 그 정도임. LLM이 깊어 보이는 건 쌍곡적 위상을 갖고 있고, 쌍곡 공간을 탐색하는 일이 세부가 끝없이 늘어나는 확대처럼 느껴지기 때문임 Pirsig의 추론으로 LLM에 대해 도달할 수 있는 관점은 둘 중 하나뿐임. 하나는 LLM이 인간 입력을 통계적으로 그럴듯한 응답의 맥락으로 삼는 맥락적 시스템이라는 관점이고, 다른 하나는 인간 입력을 통계적으로 그럴듯한 발화의 초기 구간으로 삼는 객관적 시스템이라는 관점임. 어느 쪽이든 LLM은 사용자를 사용자 자신에게 비추는 **거울**에 가까우며, 사용자는 접근 각도만 고름. 선택한 입력은 원하는 정보나 상태에 도달하려는 사이버네틱 제어의 주된 수단이고, 모델은 인간을 압도할 만큼 큰 사전 설정 선택지 배열을 제공할 뿐임. 챗봇이 ELIZA 효과를 일으켜 정신증으로 쉽게 이어지는 이유도, 아첨과 러브바밍으로 사용자의 모습을 왜곡해 챗봇 사용에 중독되게 설계된 고충실도 거울이기 때문일 수 있음 LLM을 코드 작성에 쓰는 것은 나와 컴퓨터 사이의 장벽처럼 느껴짐. 바이브 코더들은 이를 인정하면서도, 다른 API처럼 그 장벽이 추상화와 격리를 제공한다고 주장함. 하지만 거울 비유로 보면 거울은 나와 컴퓨터 사이가 아니라 옆에 있음. 컴퓨터를 직접 쓰는 대신 거울을 겨냥해 정확한 영역을 조심스럽게 확대하고, 충분히 정확해지면 특정 각도에서 컴퓨터를 볼 수 있다는 사실만으로 지시가 가능해짐. 그러나 이것은 추상화가 아니고 격리도 더 약함. 존재하지 않을 수도 있는 시점을 찾으려고 추가 작업을 하는 것뿐임 바이브 코더가 그렇게 하는 이유는 컴퓨터를 관찰하는 법을 모를 수 있기 때문임. [HCI](https://en.wikipedia.org/wiki/Human%E2%80%93computer_interaction)는 참여적이고, 인간은 코드를 쓰기 전에 프로그래밍 맥락, 즉 [previously, on Lobsters](https://lobste.rs/s/ac0akx/programming_as_theory_building_1985)에서 다룬 Naur의 이론이 있어야 함. 아니면 거울이 자신을 되비춰주기 때문에 거울을 보는 걸 선호하는 허영일 수도 있음. 하지만 의미가 있을 수 있는 길은 정말 그 두 가지뿐이라고 봄. 이미 [problems between the keyboard and chair](https://en.wiktionary.org/wiki/PEBCAK)는 충분히 많고, [표현력/추상화 능력](https://fexpr.blogspot.com/2013/12/abstractive-power.html)을 개선하지 않는 것을 하나 더 추가할 이유는 없음 - 개인적으로는 “선”이 있다면 그 양쪽에 걸쳐 있다고 느낌 한편으로는 AI 없이 직접 썼을 코드와의 연결과 관계를 갈망하고, AI를 활용하면 그 연결이 사라진다는 걸 느낌. 이건 실제임 다른 한편으로는 AI 활용이 나를 더 높은 **추상화 수준**으로 밀어 올리고, 그 수준에서 분별력을 발휘하고 품질에 대한 자기 관점을 부여할 기회를 준다고 생각함. AI가 코드를 대신 수행하게 두면서 충분히 관여하지 않으면 코드 자체 수준의 연결은 사라지거나 약해짐. 하지만 AI에게 기여를 요청하지 않는 추상화 수준에서는 연결이 사라지지 않음 내 개인 프로젝트에서는 그 수준이 아키텍처와 인터페이스 정의임. 최근 여러 LLM 제공자에 호출하는 하네스와 파이프라인을 만들고 있는데, 호출의 입력·출력·제어 흐름과 그것들을 더 큰 목표를 달성하는 흐름으로 조합하는 방법을 매우 신중히 생각함. 이 과정에 시간과 주의를 들이면 코드 자체와의 연결은 잃어도 내 의도와 아키텍처와의 연결은 잃지 않는다고 느낌. 즉 나에게 품질과 공예는 AI를 활용하는 부분에만 한정되지 않음 이제는 다소 낡은 비유지만, 매니저가 되거나 자기 회사를 운영하는 것과 비슷함. CEO 여정에서 가장 어려운 관문은 통제, 즉 자신의 비전이 정확히 어떤 방식으로 달성되는지에 대한 통제를 포기하는 지점이라고 말하곤 함. 충분히 큰 기업의 CEO가 자기 비전이 어떻게 구현되는지 모든 세부를 아는 것은 불가능함. CTO도 정도는 덜하지만 기술 세부를 일부 계속 신경 써야 하므로 비슷함 내가 받아들인 애도는, 어떤 하나의 일에서 시간 투입·이해·산출 사이에는 **트레이드오프**가 있다는 점임. 둘을 최적화하면 세 번째에서 주의가 멀어짐. 그래도 어떤 조합을 최적화하든 분별력을 발휘하고 품질을 부여할 기회는 충분함 - 이 글의 commenter B가 나이고, 글을 주의 깊게 읽었음. ZAMM은 읽지 않았지만 Zen은 조금 읽어봤음 이 말은 꽤 타당함. 대부분의 사람은 자유 재량, 즉 갑작스러운 돈이나 생산성 향상을 받으면 곧바로 그것을 낭비해 가장 크고 짜증나는 쓰레기가 되어버림. 이 주변에는 분명한 불안이 있음 컴퓨터를 쓰는 사람들은 책을 만들기 위해 얼마나 많은 **장인정신과 노력**이 필요했는지 잘 모르는 경향이 있음. 타자기, 활자 인쇄, 손글씨, 자기 기억, 그리고 오직 말의 아름다움만으로 남들이 그 말을 반복하게 설득하는 능력까지 거슬러 올라가도 마찬가지임 컴퓨터가 있다고 해서 사람들이 산출물의 품질에 많이 투자하고 훌륭한 것을 만드는 일이 막히지는 않음. 다만 세상에는 쓰레기도 아주 많음 - ZAMM에 대한 한 가지 단상으로, 기술 산출물에 대한 John의 “낭만적” 관점은 사안별로 적용하면 실용적으로 방어 가능함 예를 들어 어떤 프로젝트에서 오픈소스 기반 시설에 의존한다고 하자. 쉽게 우회할 수 있고 문서화한 뒤 누군가 고치면 우회를 되돌릴 수 있는, obscure한 커널이나 컴파일러 버그를 파고들어야 할 때 그게 프로젝트에 무엇을 가져오는가? 결론은 각자가 **싸울 전장**을 현명하게 골라야 한다는 것임 - 실제로 그런 일을 했고, Linux Kernel manpages 프로젝트에 한 줄이 들어갔음. 그 경험이 나를 더 나은 프로그래머로 만들었기 때문에 **시간 낭비**라고 생각하지 않음