루프 안의 인간은 지쳤다

• LLM 프로그래밍은 생산성을 높이는 동시에 개발자가 의도와 품질을 계속 통제해야 하는 감독 피로를 키워, 만족감과 지속 가능성을 흔듦
• 모델은 그럴듯한 코드를 빠르게 만들지만 복잡한 변경의 일관된 의도를 놓칠 수 있어, 인간이 늘어난 결과물을 검토하고 수정하는 품질 관문이 됨
• 시작할 수 있는 작업은 급증해도 신중하게 마칠 수 있는 작업량은 인간의 두뇌와 주의력에 묶여 있으며, 코딩의 작은 보상은 줄고 검토의 인지 부하는 커짐
• 깊이 이해한 영역에서는 LLM을 효과적으로 안내할 수 있지만 전문성이 얕은 영역에서는 정확성보다 그럴듯함에 치우치므로, 취향과 아키텍처 판단이 더 중요해짐
• 소프트웨어 엔지니어링은 사라지기보다 축소·재편되며, 희소한 자원은 코드 작성 자체가 아니라 인간의 주의력, 공학적 판단, 시스템의 일관된 비전을 유지하는 능력임

---

유용하지만 불안정한 LLM 프로그래밍

• LLM 프로그래밍은 실질적으로 유용한 동시에 불안정하며, 불안정성을 외면하면 개발자가 번아웃에 빠질 수 있음
• Pydantic 팀도 데이터 검증, AI 에이전트 구축, 프로덕션 관측 도구를 만들면서 같은 혼란을 겪고 있음
• 핵심은 AI가 프로그래머를 대체하는지가 아니라, 현재의 개발 경험이 어떻게 달라졌고 무엇으로 이를 개선할 수 있는지에 있음

손으로 직접 만들던 감각

• 프로그래밍은 논리만으로 무언가를 만들고 깊은 추상화 계층을 직접 다루는 창조의 감각을 제공해 왔음
• 정규 컴퓨터과학 교육 대신 시행착오로 소프트웨어 공학을 익힌 경험에서 아키텍처와 코드 품질 원칙은 교과서 규칙보다 축적된 상처에 가까움
• 2010년대의 로우코드·노코드 도구와 Dreamweaver 같은 제품도 코드 없이 무언가를 만든다는 약속을 내세웠지만, 내부에 스파게티 코드를 생성하며 기대를 완전히 충족하지 못했음
• 현재 AI 도구는 과거와 달리 약속과 현실의 간극을 의미 있는 수준으로 좁혔고, 바로 그 점 때문에 더 불안하게 느껴짐

“코드가 스스로 작성된다”는 실제 경험

• 코드는 어느 정도 스스로 작성되지만, 이를 검토하고 지시하며 방향을 바로잡는 인간의 경험은 오히려 나빠질 수 있음
• Pydantic AI 유지보수자인 Douwe는 다른 사람들의 AI가 밤새 만든 PR 약 30개를 아침마다 검토하며 각각을 즉시 판단해야 했음
  • 검토까지 AI에 맡기고 싶은 유혹이 크지만, 그렇게 하면 인간이 무엇을 하는지에 대한 의문이 남음
• LLM이 실행할 계획을 거의 이틀 동안 작성하고 반복해서 명확화해도, 모델은 React 훅을 Storybook 스토리 파일로 옮기거나 잘못된 계획을 읽고 존재하지 않는 컴포넌트를 만들 수 있음
• 이런 실패는 단순한 능력 부족보다 일관성 부족에 가까움
  • 모델은 그럴듯한 코드를 만들 만큼 영리하지만, 복잡한 변경 전체에서 하나의 의도를 유지하지 못할 수 있음
• 인간은 머릿속에 의도를 보존한 채 대량의 ‘대부분 맞는’ 결과물을 계속 판단해야 하며, 이 과정에서 새로운 형태의 감독 피로가 생김
• 오픈소스에서 실제 사람과 기능을 만들고 상대의 역량 향상을 돕던 보상도 줄어듦
  • 작업이 AI의 블랙박스로 들어가면 반대편에서 배우는 사람이 없으므로 협업의 만족감이 사라짐

작업 강도를 높이는 함정

• Simon Willison이 소개한 Berkeley Haas 연구는 AI 사용이 업무량을 줄이기보다 업무 강도를 높인다고 봄
  • 하루가 끝날 때 프롬프트 하나만 더 입력하거나 기능 하나만 더 완성하려는 압력이 이어짐
  • 계획을 거의 완성했다는 감각 때문에 새벽 2시 가까이까지 프롬프트를 입력하는 상황도 생김
• Pydantic의 Marcelo는 Claude Code 세션이 멈추면 5개 세션을 열라고 농담함
  • 다른 세션에 피드백하느라 바쁘면 한 세션이 멈춘 사실조차 알아차리지 못한다는 의미임
• 병렬 작업으로 시작할 수 있는 일은 크게 늘지만, 신중하게 끝낼 수 있는 일의 수는 달라지지 않음
  • 완료에는 병렬화할 수 없는 자원인 인간의 두뇌가 필요함

인간 보상 함수의 고장

• 머신러닝의 보상 함수가 에이전트에게 좋은 결과를 정의하듯, 수작업 코딩에도 문제 해결, 복잡한 논리 이해, 컴파일 성공, 통제감 같은 작은 보상이 있었음
• LLM 보조 프로그래밍은 이런 도파민 보상을 만들던 작업을 자동화하고, 그 자리를 검토와 감독의 인지 부하로 채움
  • 만족스러운 부분은 줄어듦
  • 소모적인 부분은 늘어남
  • 빈자리를 채울 새로운 보상은 아직 없음
• 생산성이 높아지는 동시에 만족감이 떨어지는 현상은 개인의 결함이 아니라 피드백 루프의 고장이며, 별도의 공학 문제로 다뤄야 함

고립과 가변적 보상

• LLM 프로그래밍은 인간과 기계가 프롬프트, 수정, 검토를 반복하는 매우 고독한 활동이 될 수 있음
• 동료에게 질문하거나 문제를 함께 말로 풀고 해결의 작은 기쁨을 공유하던 순간이 또 하나의 프롬프트로 대체됨
• 기존 협업 문화가 약한 팀에서는 사람 사이의 의사소통이 더 위축되고, 다른 사람도 어려움을 겪는다는 사실을 확인하기 힘들어짐
• 결과가 때로는 훌륭하고 때로는 쓰레기지만 미리 알 수 없다는 점은 Skinner Box와 같은 가변적 보상 구조를 만듦
• 필요할 때 직접 코드를 작성해도 되지만, LLM 보조 작업과 수작업은 사고방식이 크게 달라 전환이 불편함
  • 두 방식을 오갈 수 있도록 스스로 허용하려면 성숙함과 자신감이 필요함

반응형 디자인 전환과의 유사점

• 2009년 무렵 웹이 고정 폭의 픽셀 단위 레이아웃에서 유동적인 반응형 디자인으로 이동했을 때도 디자이너들은 통제력 상실을 경험함
• 정밀한 레이아웃과 완벽한 그리드에 정체성과 전문성을 쌓은 사람들에게 임의의 화면 너비와 기기에 맞춰 디자인이 흐른다는 개념은 근본적인 변화였음
• 전환에 적응한 디자이너들은 기존 기술을 버리는 대신 재구성함
  • 비례 감각과 계층 구조의 이해는 계속 중요했음
  • 픽셀 단위 통제에 대한 집착은 덜 중요해짐
  • 시스템, 적응성, 불확실성을 위한 설계는 더 중요해짐
• 현재 AI 전환은 반응형 디자인보다 훨씬 빠르고 이해관계도 다름
  • 반응형 디자인의 변화는 수년에 걸쳤지만 현재 변화는 수개월 단위로 진행됨
  • 당시에도 에이전시는 고객을, 디자이너는 일감을 잃었지만 현재와 같은 실존적 불안을 동반하지는 않았음
• 그럼에도 기술이 사라지기보다 진화하고 핵심 역량이 더 중요해진다는 패턴은 LLM 기반 코딩에도 적용됨
• 모든 코드를 직접 작성하지 않아도 엔지니어의 가치가 줄어드는 것은 아니지만, 훨씬 많은 결과물의 품질 관문이 된 만큼 좋은 결과를 판별할 능력이 더 필요함

살아남는 전문성과 새로운 작업 방식

• 누구나 그럴듯한 UI와 컴파일되는 코드를 만들 수 있는 환경에서는 취향과 뉘앙스, 성숙한 아키텍처 판단, 실제 전문성에 기반한 비주류 결정이 차별점이 됨
• 코드와 결정, 트레이드오프를 깊이 이해하는 영역일수록 LLM을 성공적으로 안내할 수 있음
• 전문성이 얕은 영역으로 갈수록 결과물은 프로덕션 준비 수준에서 멀어지고, 실제로 맞기보다 인상적으로 그럴듯한 상태에 가까워짐
  • 모델은 자신이 모르는 것을 알지 못한 채 빈틈을 자신감 있게 채우며, 이는 인간에게도 나타나는 실패 방식임
• 복잡한 계획에는 사전 부검(pre-mortem) 을 활용할 수 있음
  • 새로운 LLM 세션에 계획이 참담하게 실패했다고 가정하게 한 뒤 원인을 진단하도록 요청함
  • 세부 사항을 이틀 동안 들여다본 사람이 놓친 명세의 빈틈을 찾는 데 도움이 됨
• Pydantic의 한 엔지니어는 과거 코드 리뷰 댓글 수천 개에서 규칙을 추출해 AGENTS.md 파일의 초기 지침으로 만드는 도구를 개발함
  • 수년간 암묵적으로 축적한 공학적 판단을 LLM이 따를 수 있는 지침으로 바꾸는 전문성의 증류에 해당함
• 변화에 적응하는 사람들은 실무에서 얻은 강한 판단 기준을 갖고, 계속 유효한 원칙과 과거의 대역폭 제약 때문에 생긴 습관을 구분함
• 이들은 기준을 버리지 않으면서도 작업 흐름을 바꿀 의지가 있음

루프 안에서 드러난 희소 자원

• 현재의 AI 흐름이 소프트웨어 엔지니어링 직업을 끝내지는 않지만, 업계의 심각한 축소와 근본적 재편을 가져올 수 있음
• 도태, 역량 퇴화, 충분히 빠르게 움직이지 않으면 뒤처질 수 있다는 두려움은 정당함
  • 마지막 우려는 과장되는 경우가 있지만 완전히 근거 없지는 않음
• 진짜 병목은 코드가 아니라 인간의 주의력, 공학적 판단, 시스템에 대한 일관된 비전을 유지하는 능력이었음
• 코드 작성이 어려운 부분처럼 느껴졌기 때문에 기존에는 이 병목이 잘 드러나지 않았지만, 작성 과정이 자동화되면서 인간의 능력이 실제 희소 자원이라는 점이 선명해짐
• 개발자는 더 생산적이면서도 덜 행복하고 불안정할 수 있으며, 도구를 만드는 팀 역시 같은 문제를 겪으며 보상 함수를 실시간으로 조정하고 있음
• 코드와 개발 방식은 변하고 있지만 인간은 여전히 루프 안에 있으며, 지금의 핵심 상태는 인간 참여자의 피로임

[GN⁺]

Hacker News 의견들

• 수작업 코딩은 어려울수록 문제 해결, 논리 이해, 컴파일 성공, 통제감 같은 작은 보상이 커졌음. 반면 에이전트 코딩은 기능 규모와 무관하게 비슷한 감독을 계속 요구해 처음에는 생산성의 파도를 타는 듯 신나지만, 만족스러운 부분은 줄고 검토의 인지 부하는 커져 금세 지치게 됨

  • 일자리를 잃는 것보다 곧 일 자체를 싫어하게 될까 두려움. 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 자동화에도 적용할 수 있다고 봄