루프 안의 인간은 지쳤다

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