# 루프 안의 인간은 지쳤다 > Clean Markdown view of GeekNews topic #31546. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=31546](https://news.hada.io/topic?id=31546) - GeekNews Markdown: [https://news.hada.io/topic/31546.md](https://news.hada.io/topic/31546.md) - Type: GN+ - Author: [xguru](https://news.hada.io/@xguru) - Published: 2026-07-18T18:05:02+09:00 - Updated: 2026-07-18T18:05:02+09:00 - Original source: [pydantic.dev](https://pydantic.dev/articles/the-human-in-the-loop-is-tired) - Points: 2 - Comments: 1 ## Topic Body - LLM 프로그래밍은 생산성을 높이는 동시에 개발자가 의도와 품질을 계속 통제해야 하는 **감독 피로**를 키워, 만족감과 지속 가능성을 흔듦 - 모델은 그럴듯한 코드를 빠르게 만들지만 복잡한 변경의 일관된 의도를 놓칠 수 있어, 인간이 늘어난 결과물을 검토하고 수정하는 **품질 관문**이 됨 - 시작할 수 있는 작업은 급증해도 신중하게 마칠 수 있는 작업량은 인간의 두뇌와 주의력에 묶여 있으며, 코딩의 작은 보상은 줄고 검토의 인지 부하는 커짐 - 깊이 이해한 영역에서는 LLM을 효과적으로 안내할 수 있지만 전문성이 얕은 영역에서는 정확성보다 그럴듯함에 치우치므로, **취향과 아키텍처 판단**이 더 중요해짐 - 소프트웨어 엔지니어링은 사라지기보다 축소·재편되며, 희소한 자원은 코드 작성 자체가 아니라 **인간의 주의력**, 공학적 판단, 시스템의 일관된 비전을 유지하는 능력임 --- ### 유용하지만 불안정한 LLM 프로그래밍 - LLM 프로그래밍은 **실질적으로 유용한 동시에 불안정**하며, 불안정성을 외면하면 개발자가 번아웃에 빠질 수 있음 - [Pydantic](https://pydantic.dev/) 팀도 데이터 검증, AI 에이전트 구축, 프로덕션 관측 도구를 만들면서 같은 혼란을 겪고 있음 - 핵심은 AI가 프로그래머를 대체하는지가 아니라, 현재의 개발 경험이 어떻게 달라졌고 무엇으로 이를 개선할 수 있는지에 있음 ### 손으로 직접 만들던 감각 - 프로그래밍은 논리만으로 무언가를 만들고 깊은 추상화 계층을 직접 다루는 **창조의 감각**을 제공해 왔음 - 정규 컴퓨터과학 교육 대신 시행착오로 소프트웨어 공학을 익힌 경험에서 아키텍처와 코드 품질 원칙은 교과서 규칙보다 축적된 상처에 가까움 - 2010년대의 로우코드·노코드 도구와 Dreamweaver 같은 제품도 코드 없이 무언가를 만든다는 약속을 내세웠지만, 내부에 스파게티 코드를 생성하며 기대를 완전히 충족하지 못했음 - 현재 AI 도구는 과거와 달리 약속과 현실의 간극을 **의미 있는 수준으로 좁혔고**, 바로 그 점 때문에 더 불안하게 느껴짐 ### “코드가 스스로 작성된다”는 실제 경험 - 코드는 어느 정도 스스로 작성되지만, 이를 검토하고 지시하며 방향을 바로잡는 인간의 경험은 오히려 나빠질 수 있음 - Pydantic AI 유지보수자인 [Douwe](https://github.com/DouweM)는 다른 사람들의 AI가 밤새 만든 PR 약 30개를 아침마다 검토하며 각각을 즉시 판단해야 했음 - 검토까지 AI에 맡기고 싶은 유혹이 크지만, 그렇게 하면 인간이 무엇을 하는지에 대한 의문이 남음 - LLM이 실행할 계획을 거의 이틀 동안 작성하고 반복해서 명확화해도, 모델은 React 훅을 Storybook 스토리 파일로 옮기거나 잘못된 계획을 읽고 존재하지 않는 컴포넌트를 만들 수 있음 - 이런 실패는 단순한 능력 부족보다 **일관성 부족**에 가까움 - 모델은 그럴듯한 코드를 만들 만큼 영리하지만, 복잡한 변경 전체에서 하나의 의도를 유지하지 못할 수 있음 - 인간은 머릿속에 의도를 보존한 채 대량의 ‘대부분 맞는’ 결과물을 계속 판단해야 하며, 이 과정에서 새로운 형태의 감독 피로가 생김 - 오픈소스에서 실제 사람과 기능을 만들고 상대의 역량 향상을 돕던 보상도 줄어듦 - 작업이 AI의 블랙박스로 들어가면 반대편에서 배우는 사람이 없으므로 **협업의 만족감**이 사라짐 ### 작업 강도를 높이는 함정 - [Simon Willison](https://simonwillison.net/2026/Feb/9/ai-intensifies-work/)이 소개한 [Berkeley Haas 연구](https://hbr.org/2026/02/ai-doesnt-reduce-work-it-intensifies-it)는 AI 사용이 업무량을 줄이기보다 **업무 강도**를 높인다고 봄 - 하루가 끝날 때 프롬프트 하나만 더 입력하거나 기능 하나만 더 완성하려는 압력이 이어짐 - 계획을 거의 완성했다는 감각 때문에 새벽 2시 가까이까지 프롬프트를 입력하는 상황도 생김 - Pydantic의 [Marcelo](https://github.com/kludex)는 Claude Code 세션이 멈추면 5개 세션을 열라고 농담함 - 다른 세션에 피드백하느라 바쁘면 한 세션이 멈춘 사실조차 알아차리지 못한다는 의미임 - 병렬 작업으로 시작할 수 있는 일은 크게 늘지만, 신중하게 끝낼 수 있는 일의 수는 달라지지 않음 - 완료에는 병렬화할 수 없는 자원인 **인간의 두뇌**가 필요함 ### 인간 보상 함수의 고장 - 머신러닝의 보상 함수가 에이전트에게 좋은 결과를 정의하듯, 수작업 코딩에도 문제 해결, 복잡한 논리 이해, 컴파일 성공, 통제감 같은 작은 보상이 있었음 - LLM 보조 프로그래밍은 이런 도파민 보상을 만들던 작업을 자동화하고, 그 자리를 검토와 감독의 **인지 부하**로 채움 - 만족스러운 부분은 줄어듦 - 소모적인 부분은 늘어남 - 빈자리를 채울 새로운 보상은 아직 없음 - 생산성이 높아지는 동시에 만족감이 떨어지는 현상은 개인의 결함이 아니라 **피드백 루프의 고장**이며, 별도의 공학 문제로 다뤄야 함 ### 고립과 가변적 보상 - LLM 프로그래밍은 인간과 기계가 프롬프트, 수정, 검토를 반복하는 매우 고독한 활동이 될 수 있음 - 동료에게 질문하거나 문제를 함께 말로 풀고 해결의 작은 기쁨을 공유하던 순간이 또 하나의 프롬프트로 대체됨 - 기존 협업 문화가 약한 팀에서는 사람 사이의 의사소통이 더 위축되고, 다른 사람도 어려움을 겪는다는 사실을 확인하기 힘들어짐 - 결과가 때로는 훌륭하고 때로는 쓰레기지만 미리 알 수 없다는 점은 [Skinner Box](https://en.wikipedia.org/wiki/Operant_conditioning_chamber)와 같은 **가변적 보상 구조**를 만듦 - 필요할 때 직접 코드를 작성해도 되지만, LLM 보조 작업과 수작업은 사고방식이 크게 달라 전환이 불편함 - 두 방식을 오갈 수 있도록 스스로 허용하려면 성숙함과 자신감이 필요함 ### 반응형 디자인 전환과의 유사점 - 2009년 무렵 웹이 고정 폭의 픽셀 단위 레이아웃에서 유동적인 [반응형 디자인](https://alistapart.com/article/responsive-web-design/)으로 이동했을 때도 디자이너들은 통제력 상실을 경험함 - 정밀한 레이아웃과 완벽한 그리드에 정체성과 전문성을 쌓은 사람들에게 임의의 화면 너비와 기기에 맞춰 디자인이 흐른다는 개념은 근본적인 변화였음 - 전환에 적응한 디자이너들은 기존 기술을 버리는 대신 재구성함 - 비례 감각과 계층 구조의 이해는 계속 중요했음 - 픽셀 단위 통제에 대한 집착은 덜 중요해짐 - 시스템, 적응성, 불확실성을 위한 설계는 더 중요해짐 - 현재 AI 전환은 반응형 디자인보다 훨씬 빠르고 이해관계도 다름 - 반응형 디자인의 변화는 수년에 걸쳤지만 현재 변화는 **수개월 단위**로 진행됨 - 당시에도 에이전시는 고객을, 디자이너는 일감을 잃었지만 현재와 같은 실존적 불안을 동반하지는 않았음 - 그럼에도 기술이 사라지기보다 진화하고 핵심 역량이 더 중요해진다는 패턴은 LLM 기반 코딩에도 적용됨 - 모든 코드를 직접 작성하지 않아도 엔지니어의 가치가 줄어드는 것은 아니지만, 훨씬 많은 결과물의 **품질 관문**이 된 만큼 좋은 결과를 판별할 능력이 더 필요함 ### 살아남는 전문성과 새로운 작업 방식 - 누구나 그럴듯한 UI와 컴파일되는 코드를 만들 수 있는 환경에서는 **취향과 뉘앙스**, 성숙한 아키텍처 판단, 실제 전문성에 기반한 비주류 결정이 차별점이 됨 - 코드와 결정, 트레이드오프를 깊이 이해하는 영역일수록 LLM을 성공적으로 안내할 수 있음 - 전문성이 얕은 영역으로 갈수록 결과물은 프로덕션 준비 수준에서 멀어지고, 실제로 맞기보다 인상적으로 그럴듯한 상태에 가까워짐 - 모델은 자신이 모르는 것을 알지 못한 채 빈틈을 자신감 있게 채우며, 이는 인간에게도 나타나는 실패 방식임 - 복잡한 계획에는 **사전 부검(pre-mortem)** 을 활용할 수 있음 - 새로운 LLM 세션에 계획이 참담하게 실패했다고 가정하게 한 뒤 원인을 진단하도록 요청함 - 세부 사항을 이틀 동안 들여다본 사람이 놓친 명세의 빈틈을 찾는 데 도움이 됨 - Pydantic의 한 엔지니어는 과거 코드 리뷰 댓글 수천 개에서 규칙을 추출해 `AGENTS.md` 파일의 초기 지침으로 만드는 도구를 개발함 - 수년간 암묵적으로 축적한 공학적 판단을 LLM이 따를 수 있는 지침으로 바꾸는 **전문성의 증류**에 해당함 - 변화에 적응하는 사람들은 실무에서 얻은 강한 판단 기준을 갖고, 계속 유효한 원칙과 과거의 대역폭 제약 때문에 생긴 습관을 구분함 - 이들은 기준을 버리지 않으면서도 작업 흐름을 바꿀 의지가 있음 ### 루프 안에서 드러난 희소 자원 - 현재의 AI 흐름이 소프트웨어 엔지니어링 직업을 끝내지는 않지만, 업계의 **심각한 축소와 근본적 재편**을 가져올 수 있음 - 도태, 역량 퇴화, 충분히 빠르게 움직이지 않으면 뒤처질 수 있다는 두려움은 정당함 - 마지막 우려는 과장되는 경우가 있지만 완전히 근거 없지는 않음 - 진짜 병목은 코드가 아니라 인간의 주의력, 공학적 판단, 시스템에 대한 일관된 비전을 유지하는 능력이었음 - 코드 작성이 어려운 부분처럼 느껴졌기 때문에 기존에는 이 병목이 잘 드러나지 않았지만, 작성 과정이 자동화되면서 인간의 능력이 실제 **희소 자원**이라는 점이 선명해짐 - 개발자는 더 생산적이면서도 덜 행복하고 불안정할 수 있으며, 도구를 만드는 팀 역시 같은 문제를 겪으며 보상 함수를 실시간으로 조정하고 있음 - 코드와 개발 방식은 변하고 있지만 인간은 여전히 루프 안에 있으며, 지금의 핵심 상태는 **인간 참여자의 피로**임 ## Comments ### Comment 61988 - Author: neo - Created: 2026-07-18T18:05:04+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=48942000) - 수작업 코딩은 어려울수록 문제 해결, 논리 이해, 컴파일 성공, 통제감 같은 작은 보상이 커졌음. 반면 **에이전트 코딩**은 기능 규모와 무관하게 비슷한 감독을 계속 요구해 처음에는 생산성의 파도를 타는 듯 신나지만, 만족스러운 부분은 줄고 검토의 인지 부하는 커져 금세 지치게 됨 - 일자리를 잃는 것보다 곧 **일 자체를 싫어하게 될까** 두려움. LLM에 지시해도 시간이 별로 절약되지 않는 작업은 직접 하고, 출력 구조를 사람이 이해하기 좋게 다시 다듬으며 통제감을 유지하고 있음 - 내 동력은 코드를 어떻게 만들었느냐보다 만든 제품을 더 많은 사람이 유용하게 쓰느냐에 있음. 사용자를 먼저 생각해 필요하면 지름길을 택해왔고, **유지보수 가능한 코드**와 출시 속도의 균형은 LLM을 써도 맞출 수 있음 - 개발이 지식 기반 직업에서 임금이 낮은 **공장 노동**처럼 바뀔 수 있음. 직접 작성할 때보다 LLM을 안내할 때 필요한 지식과 경력이 훨씬 적고, LinkedIn에서는 경력이 거의 없거나 주니어 수준인 사람도 AI 엔지니어로 채용되고 있음 - AI가 스스로 출력을 시험하는 루프를 만들 때 도파민을 느낌. Codex가 특정 노트북과 Linux 커널에서 최대 절전 모드를 작동시키도록 네트워크-USB-C 키보드 동글, Fingerbot, 웹캠까지 연결해 원격 제어하게 만든 **루브 골드버그식 자동화**일수록 더 만족스러웠음 - 개인 프로젝트에서는 기능을 더 쉽게 만들면서도 결과가 정교하고 일관돼 오히려 만족감이 커짐. 한 프로젝트에 한 달간 집중하면 꽤 좋은 결과를 얻고, 재작성과 구조 정리가 저렴해져 **설계 공간**을 실제로 더 폭넓게 탐색할 수 있음. 다만 답답할 때도 많으며 절반은 내 맥락 제공 문제, 절반은 모델의 본질적 한계임 - Claude를 업무와 개인 프로젝트에서 즐겁게 쓰고 있으며, 핵심은 **에이전트의 유혹을 피하고 코드 생성기로 다루는 것**임. 세션 하나만 열어 계획을 충분히 다듬은 뒤 단계별 실행을 지켜보고, 각 단계가 끝날 때 검토와 방향 수정을 하면 마지막에도 코드 상태를 잘 파악할 수 있음 원샷에 가깝게 쓰려면 계획 단계에서 아키텍처뿐 아니라 주요 결정을 좌우할 실제 코드까지 구체화해야 함. 리팩터링 비용이 어느 때보다 낮으니 이해하기 어려운 부분은 즉시 LLM과 고치되, **한 번에 하나의 LLM이 한 가지 일만** 하도록 하고 계속 과정에 참여해야 함 - Claude와 몇 달간 작업한 끝에 초반에 세부 사항을 충분히 논의하고 필요하면 골격까지 만든 뒤 실행시키는 흐름을 익혔으며, 이를 [https://github.com/ctomkow/claude/blob/main/README.md]()에 정리했음. 미뤄왔던 레거시 코드를 새 아키텍처로 성공적으로 리팩터링하고 있음 Claude에 전권을 주면 필연적으로 생기는 혼란과 난관이 사람을 소진시킴. 원할 때는 직접 코딩하고 지쳤을 때 Claude에 넘기면 **코드베이스 통제감**도 유지할 수 있음 - 편집기와 완전히 분리된 대화에 필요한 코드 조각만 붙여 넣고 제약과 아이디어를 논의한 뒤, 만족스러우면 편집기로 옮겨 이름과 구현을 더 다듬음. 명확하거나 즐거운 작업은 직접 하고 **아키텍처 결정**에도 관여해야 프로젝트와 연결감을 느끼며 깊이 이해할 수 있음 - 바이브 코딩은 여러 에이전트 루프를 쓰더라도, 출력을 가까이서 보는 **보조 도구 방식**보다 소진되기 쉬움 - 점진적으로 작업해도 다른 사람이 검토할 때는 결과 전체를 처음 보는 눈으로 한꺼번에 살펴야 하므로 **검토 부담**은 줄지 않음 - 작업 흐름은 최대 두 개까지 오갈 수 있지만, 그 이상이면 **맥락 전환** 때문에 머리가 완전히 지침 - 동료나 부하 직원의 코드를 검토할 때는 피드백의 기술적 타당성뿐 아니라 자존심, 아키텍처 관점 차이, 정중한 어조, 추가 업무량, 팀 역학까지 고려하느라 정신력 대부분을 씀. 반면 **LLM은 감정적 영향에 신경 쓸 필요가 없어** 검토와 방향 수정이 훨씬 쉬움 - 동료가 내 피드백을 다시 AI에 넘길 것을 알면 사람보다 **AI를 대상으로 작성**하게 되고, 훨씬 짧고 직설적으로 수정 목록을 전달하게 됨 - 기술 리드로서 PR마다 “이 정도면 충분하다”는 반발을 겪어왔는데, LLM에는 반발 없이 **올바른 방식으로 다시 하라**고 요구할 수 있어 편함 - 직장에서는 human in the loop 대신 **Human on the hook**이라 부르기 시작했음. 잘되면 공을 받지 못하지만 잘못되면 책임 당사자가 되는, 즉 문제가 생길 때만 인간이 중요해지는 구조를 더 정확히 표현함 - 코드를 쓰는 일 자체는 내게 한 번도 어려운 부분이 아니었음. 빠른 타자, Vim 모달 편집, Unix 명령, 스크립트와 단축키, Git, IDE 리팩터링, Java를 익혀 무엇을 만들지 알 때는 생각의 속도로 작업함 멈추는 순간은 타자나 문법 때문이 아니라 코드의 형태와 올바른 변경을 생각할 때이며, 어려워지면 더 나은 추상화나 IDE 도구, `sed`를 포함한 Unix 파이프라인을 만듦. 그래서 **병목은 코드 작성이 아니라 사고와 판단**이었음 AI 코딩이 큰 도약처럼 느껴지는 이유는 훌륭한 도구를 접하거나 숙달하지 못한 개발자가 예상보다 많기 때문일 수 있음. 지금 20대였다면 이런 기술을 익히는 데 시간을 덜 썼겠지만, 내게 소프트웨어 공학이 매력적이었던 순간은 그 어떤 것도 마법이 아님을 이해했을 때였음 - “AI는 **자신이 잘하지 못하는 일**을 잘하는 것처럼 보인다”는 표현이 잘 맞음. 프로그래밍에 미숙하면 AI 출력이 빠르고 훌륭해 보이지만, 숙련된 개발자에게는 지시, 대기, 설득, 수정, 리팩터링까지 합치면 직접 하는 것보다 빠르지 않을 수 있음 내가 그림에 서툴러 AI 그림이 대단해 보이는 것처럼, AI 프로그래밍도 같은 원리로 평가될 수 있음 - 많은 사람이 느끼는 피로는 더 빠른 추진력과 더 큰 혼란이 결합하며 생기는 **통제력 상실**에서 비롯됨. LLM은 천재와 유아 사이 어딘가에 있어 뒷좌석에서 지켜보는 일이 짜릿하면서도 무서움 한동안 빠르게 달린 뒤에는 걷는 것도 나쁘지 않았고, 오히려 원하는 목적지에 도달할 가능성이 높았음을 깨닫게 될 듯함 - LLM 코딩은 **슬롯머신 손잡이**를 당기듯 의식을 치르고 이번에는 되길 바라며 반복하는 느낌임. 일반 프로그래밍의 오류는 일관된 원인이 있고, 그 원인을 이해해 가능하면 영구히 제거하도록 설계돼 있음. 숙련된 개발자는 무작위로 시도해 성공하면 이유를 알 수 없는 일로 치부하지 않음 시스템이 무엇인지조차 합의하지 못하는 여러 이해관계자를 상대하느라 이미 지쳤다면, 인간의 주의력과 공학적 판단이 원래 병목이었다는 사실을 진작 알고 있었을 수도 있음 - 코딩을 처음 배워 웹 앱을 만들 때는 “이걸 해보면 되나?”라며 맹목적으로 추측하고 실행하느라 밤늦게까지 컴퓨터에 붙잡혀 있었음. 실력이 늘고 타입 언어, 컴파일러, LSP를 쓰면서 무엇이 작동할지 이해하게 됐고, 중독적인 추측 대신 만족스러운 **몰입 상태**에 들어갈 수 있었음 Claude 코딩은 그 추측 단계로 돌아가는 느낌이라 원하지 않음. 다만 복잡한 API와 여러 구성요소를 이어 붙이는 DevOps성 작업처럼 원래 맹목적 추측이 많은 영역에서는 LLM 대화가 가장 유용함 - 이제 이해관계자들은 합의하는 대신 LLM으로 설익은 계획과 분기 목표를 만들고, 설계·스토리·기술 세부사항·구현·코드 검토까지 모두 LLM에 맡김. 전 과정에서 **비판적 사고와 검증이 사라지고**, 목적도 불분명한 설계 문서와 코드만 쌓여 따라가기조차 어려움 계획은 언제든 변하고 충동적으로 전부 다시 작성될 가능성도 더 커짐 - 글의 핵심에는 공감하지만 곳곳에 **Claude 특유의 문체**가 묻어나, 누군가 AI로 작성한 글을 읽는 일은 더 피곤함 - AI가 직접 썼다기보다 기업 문체에 맞추는 편집과 검토를 거쳤을 가능성이 큼. LLM 자체도 이런 문체로 학습됐음 - 대부분 AI가 작성했지만 일반적인 AI 글보다 사람의 개입이 훨씬 많아 평소만큼 거슬리지는 않음 - “It’s not” 반복과 대시 사용 같은 문체 지문을 보면 **AI 작성**으로 판단됨 - 직접 쓸 수고를 들이지 않았다면 나도 읽을 수고를 들이고 싶지 않음 - 2021년 글 **The Animal is Tired**가 떠오름: [https://www.robinhobb.com/blog/archives/2021-05]() - 원문 사이트가 IP를 차단하므로 덜 제한적인 미러 [https://archive.is/RWxXP]()에서 볼 수 있음. 자신의 쇠퇴를 느끼는 일은 가장 큰 슬픔일 수 있으며 누구에게나 닥침 몸을 더 아꼈더라도 결국 같은 자리에 도달하면서 소중한 추억은 놓쳤을 수 있음. 몸을 돌보되, 다음 전투에 필요할까 봐 끝까지 쓰지 못하는 **게임 속 물약**처럼 대하면 안 됨. 우리 몸의 각 부분은 더 큰 목적을 위해 한 번 희생할 수 있거나 전혀 희생하지 않을 수 있을 뿐임 이런 생각만 해도 울 정도로 여전히 감정적 위기 속에 있음 - AI 사용이 업무 강도를 높인다는 Berkeley Haas의 **연구 홍보**는 인상적이지만, HBR 글 [https://hbr.org/2026/02/ai-doesnt-reduce-work-it-intensifies...]()과 홍보 자료 [https://newsroom.haas.berkeley.edu/ai-promised-to-free-up-wo...]()가 나온 지 5개월 넘도록 실제 논문이나 사전 공개본을 찾을 수 없음 현재 알려진 것은 단일 산업의 한 회사에서 진행한 약 **40건의 정성 인터뷰**가 전부라, 연구 방법을 확인하지 않고 결과의 신뢰성을 평가하기 어려움 - 자동화 전반을 다룬 **Ironies of Automation** [https://static1.squarespace.com/static/644321e78cd2dd37613af...]()도 읽을 만하며, 같은 원리를 AI 자동화에도 적용할 수 있다고 봄