Pydantic의 엔지니어가 쓴 한 편의 고백 「The Human-in-the-Loop is Tired」가 개발자 세계를 뒤흔들었다. '코드가 알아서 써지는' 시대에 왜 우리는 더 생산적이면서 동시에 더 불행해졌을까? 이 글은 그 답을 찾기 위해 1948년 사이버네틱스의 '키잡이'에서 출발해, 군사 자율무기의 in/on/out-of-the-loop 논쟁, 강화학습의 보상함수, 스키너 상자, 그리고 2026년 버클리·하버드의 노동강도 연구까지 훑는다. '망가진 것은 당신이 아니라 피드백 루프'라는 명제를, 인터랙티브 시뮬레이터 2종과 함께 해부한다.
한 오픈소스 메인테이너가 있다. 이름은 다우어(Douwe). 인기 있는 AI 라이브러리를 관리하는 그는, 요즘 아침마다 같은 장면을 마주한다. 눈을 뜨고 노트북을 열면 밤사이 누군가의 AI가 만들어 보낸 서른 개의 Pull Request가 쌓여 있다. 코드는 대체로 그럴듯하다. 컴파일도 된다. 문제는 그다음이다.
그는 이 서른 개를 하나하나 읽고, 이해하고, 판단하고, 받아들일지 말지를 결정해야 한다. 예전에는 이 과정이 즐거웠다. PR 하나에는 사람이 있었고, 리뷰는 대화였고, 코멘트를 남기면 그 사람이 배웠다. 그런데 지금은 다르다. 그가 정성껏 남긴 리뷰 코멘트는 어디로 가는가?
"내가 쓰는 모든 게 어떤 AI의 블랙홀 속으로 빨려 들어가요. 반대편에서 실제로 뭔가를 배우는 사람이 없어요. …그럼 대체 나는 여기서 뭘 하고 있는 거죠?"
이 장면은 2026년 초, 파이썬 생태계에서 가장 널리 쓰이는 데이터 검증 라이브러리 Pydantic(파이단틱)의 엔지니어 Laura Summers(로라 서머스)가 쓴 글 「The Human-in-the-Loop is Tired(인간은 루프 안에서 지쳤다)」에 나온다. 이 글은 발표되자마자 개발자 커뮤니티를 뒤흔들었다. 놀라운 건 반응의 성격이었다. 논쟁이 아니라 안도였다. 수많은 개발자가 이렇게 반응했다. "아, 이걸 느끼는 게 나만이 아니었구나."
이 글은 AI 예찬도, 종말론도 아니다. 서머스의 핵심 명제는 두 문장으로 요약된다.
"LLM으로 프로그래밍하는 것은 진짜로 유용하다. 그리고 진짜로 사람을 뒤흔든다. 이 두 가지는 동시에 참이다."
생산성은 분명히 올랐는데, 만족도는 떨어졌다. 왜? 이 글은 그 질문에 답하기 위해, 눈앞의 번아웃 현상을 넘어 70년 전으로 거슬러 올라간다. '인간을 루프 안에 둔다'는 이 개념이 어디서 왔고, 왜 하필 2026년의 개발자에게 이토록 아프게 다가오는지 — 사이버네틱스의 키잡이부터, 자율무기 논쟁, 강화학습의 보상함수, 스키너의 비둘기, 그리고 반응형 웹 디자인의 역사까지 함께 짚어보자.
⚠️ 이 글은 원문(Pydantic, Laura Summers)의 논지를 소개·확장하며, 관련 학술 개념과 2026년의 연구·통계를 덧붙인 해설이다. 특정 도구나 회사에 대한 비판·홍보가 아니다.
먼저 용어부터. Human-in-the-Loop(휴먼 인 더 루프, HITL)를 직역하면 '순환 고리(loop) 안에 있는 인간'이다. 어떤 자동화된 시스템이 돌아가는 의사결정의 반복 회로 한가운데에 인간을 남겨두는 설계를 말한다. 시스템이 무언가를 제안하면, 인간이 확인·수정·승인하고, 그 결과가 다시 시스템으로 피드백된다.
그런데 서머스의 글이 건드린 건 이 개념의 불편한 진실이다. 지난 수십 년간 HITL은 대체로 '인간이 통제권을 쥔' 안심의 언어였다. "걱정 마세요, 최종 결정은 사람이 합니다." 하지만 2026년, 그 루프의 무게중심이 뒤집혔다. 이제 생산은 기계가 하고, 인간은 오직 검수만 한다. 만드는 즐거움은 기계에게 가고, 검토하는 피로는 인간에게 남는다. 인간은 여전히 루프 안에 있다. 그런데 그 자리가 즐겁지 않다. 그래서 지쳤다.
이 역전이 왜 그렇게 아픈지 이해하려면, 이 개념이 태어난 곳으로 가야 한다.
'루프'라는 발상의 뿌리는 사이버네틱스(Cybernetics)다. 1948년, 수학자 노버트 위너(Norbert Wiener)는 동명의 책에서 이 학문을 정립했다. 그가 고른 단어 'cybernetics'는 그리스어 퀴베르네테스(κυβερνήτης, kybernetes) — 곧 '배의 키를 잡은 사람(키잡이·조타수)'에서 왔다.
이 어원이 모든 것을 말해준다. 키잡이는 배를 직접 밀지 않는다. 그는 바람과 물살(피드백)을 감지하고, 키를 조금씩 틀어 방향을 유지한다. 위너의 통찰은 이것이었다. 생물이든 기계든, 지능적으로 행동하는 모든 것은 "감지 → 판단 → 행동 → 그 결과를 다시 감지"라는 피드백 루프로 작동한다.
'human-in-the-loop'이라는 표현이 실제로 널리 쓰이기 시작한 곳은 항공이다. 비행기가 너무 복잡해지면서 많은 조작이 자동화되자, 엔지니어들은 물었다. "그렇다면 조종사는 이 제어 루프의 어디에 있어야 하는가?" 자동조종장치(autopilot)가 비행기를 몰 때, 인간은 감시자로 물러난다. 하지만 무언가 잘못되면 순식간에 다시 조종간을 잡아야 한다. 이 '감시하다가 갑자기 개입하는' 어정쩡한 위치야말로, 오늘날 개발자가 놓인 자리의 원형이다.
개념이 가장 날카롭게 벼려진 곳은 자율무기 논쟁이다. 여기서 세 가지 층위가 명확히 갈린다.
이 구분은 원래 "치명적 무기의 방아쇠를 누가 당기는가"라는 윤리적 물음에서 나왔다. 그런데 소름 끼치게도, 2026년의 소프트웨어 개발이 정확히 이 스펙트럼을 따라 이동하고 있다.
서머스가 짚은 고통의 정체가 여기 있다. 우리는 지금 'in'에서 'on'으로 넘어가는 전이 구간에 있고, 이 구간이 인간에게 가장 피곤하다. 통제하기엔 자동화됐고, 놓기엔 못 미덥다.
가장 최근의 층은 머신러닝이다. 여기서 HITL은 오랫동안 긍정적인 단어였다.
여기 결정적인 아이러니가 있다. RLHF(Reinforcement Learning from Human Feedback), 즉 인간의 피드백으로 AI를 길들이는 이 기법이야말로 오늘날의 유능한 코딩 AI를 만들었다. 인간은 AI에게 "이 답이 저 답보다 낫다"고 순위를 매기며 보상 신호를 줬다. 그렇게 인간은 AI의 보상함수(reward function) 역할을 했다.
그런데 이제, 그 잘 길들여진 AI가 코드를 쏟아내고, 인간은 다시 그것을 검수한다. 인간은 여전히 보상함수다. 다만 이번엔 자기 자신의 보상은 아무도 챙겨주지 않는다. 바로 이 지점이 서머스 글의 심장부다.
에이전트에게 일을 시켜본 사람은 안다. 홍보 영상 속 마법 같은 장면과, 실제 작업의 감각은 꽤 다르다.
서머스는 고백한다. 그녀는 꼬박 이틀에 가까운 시간을, LLM이 실행할 '계획서'를 쓰는 데 썼다. 강박적으로 명세하고, 다시 명세하고, 또 다시 명세했다. 그런데도 LLM은 설명할 수 없이 멍청한 짓을 했다. React 훅을 잘못 이식하고, 엉뚱한 계획서를 읽고, 존재하지도 않는 컴포넌트를 발명해냈다.
여기서 그녀는 중요한 구분을 한다. 이것은 능력(capability)의 오류가 아니라 일관성(coherence)의 오류다.
감시 피로. 이 새로운 범주의 노동은 교묘하게 지친다. 왜냐하면 대부분이 맞기 때문이다. 90%가 완벽하면, 우리는 방심한다. 그런데 나머지 10%에 치명적 오류가 숨어 있고, 그걸 잡아내려면 인간은 100%에 대해 경계(vigilance)를 유지해야 한다. 심리학이 오래전부터 안 사실 하나: 인간은 "대부분 잘 돌아가는 자동화를 감시하는 일"에 지독하게 서투르다. 방심하지 않기가, 직접 하기보다 어렵다.
이제 이 글의 가장 독창적인 통찰로 들어가자. 서머스는 머신러닝의 개념 하나를 인간 경험에 빌려온다. 바로 보상함수(reward function)다.
강화학습에서 에이전트는 '보상'을 최대화하도록 행동을 학습한다. 보상함수는 "무엇이 좋은가"를 정의한다. 그런데 인간에게도 보상함수가 있다. 우리 뇌의 도파민 회로다.
직접 코드를 짜던 시절, 이 보상은 작고 촘촘하고 잦았다.
이 잦은 보상이 우리를 계속 앉아 있게 했고, 밤을 새우게 했고, 이 일을 사랑하게 만들었다. 그런데 LLM이 등장하면서 무슨 일이 벌어졌나?
그래서 그녀는 이렇게 재구성한다. 이것은 개인의 나약함이 아니라 시스템의 고장이다.
"당신의 일이 동시에 더 생산적이면서 덜 만족스럽게 느껴진다면, 고장 난 건 당신이 아니다. 고장 난 건 피드백 루프다. 그리고 우리는 이걸 개인의 실패가 아니라, 그 자체로 하나의 엔지니어링 문제로 다루기 시작해야 한다."
이 관점 전환이 왜 중요한가? "요즘 왜 이렇게 번아웃이 오지, 내가 게을러진 건가?"라고 자책하던 수많은 개발자에게, 이 글은 "아니다, 이건 구조의 문제다"라고 이름을 붙여줬기 때문이다. 이름이 붙는 순간, 그것은 디버깅할 수 있는 대상이 된다.
그런데 보상이 사라졌다면, 우리는 왜 그 일을 멈추지 못하는가? 여기 더 교묘한 장치가 있다. 서머스는 LLM 코딩을 스키너 상자(Skinner Box)에 비유한다.
행동심리학자 B. F. 스키너는 상자 안 비둘기가 레버를 쪼도록 훈련시켰다. 그가 발견한 가장 강력한 중독 조건은, 매번 먹이를 주는 것도, 아예 안 주는 것도 아니었다. 언제 나올지 모르게, 불규칙하게 주는 것 — 변동비율 강화(variable-ratio reinforcement)였다. 슬롯머신이 정확히 이 원리로 돌아간다.
LLM 코딩이 딱 이렇다. 어떤 프롬프트는 눈부시게 훌륭한 결과를 낸다. 어떤 프롬프트는 쓰레기를 낸다. 언제 대박이 터질지 모른다. 그래서 우리는 레버를 한 번 더 당긴다. "이번엔 될지도 몰라." 새벽 2시까지.
자동화 비율을 올릴수록 생산성과 만족도가 어떻게 엇갈리는지 직접 조작해보자. 슬라이더를 움직이면, '만드는 즐거움'과 '검수의 피로'가 실시간으로 재분배된다.
"AI가 일을 대신 해주면 더 여유로워지겠지"라는 기대는, 정확히 반대로 실현됐다. 이건 감상이 아니라 연구로 확인된 사실이다.
2026년 2월, 하버드 비즈니스 리뷰(HBR)에 실린 UC 버클리 하스(Haas) 경영대학원의 연구 「AI Doesn't Reduce Work — It Intensifies It(AI는 일을 줄이지 않는다, 강화한다)」(연구자: Aruna Ranganathan, Xingqi Maggie Ye)가 이를 보여줬다. 약 200명 규모의 미국 테크 기업을 8개월간 추적한 현장 연구였다.
연구가 밝힌 강화(intensification)의 메커니즘은 세 갈래였다.
| 메커니즘 | 무슨 일이 벌어지나 | 결과 |
|---|---|---|
| 업무 범위 확장 | 남에게 넘기던 일, 시도조차 안 하던 일을 이제 "내가 할 수 있게" 됐다. PM이 코드를 짜고, 디자이너가 데이터 분석을 한다. | "내 일"의 경계가 계속 넓어진다 |
| 경계의 소멸 | AI는 시작·계속이 너무 쉬워서, 점심시간·회의 전·저녁에도 "프롬프트 하나만 더" 던지게 된다. | 쉼표가 되던 순간들이 사라진다 |
| 주의의 파편화 | 여러 개의 활성 스레드를 동시에 관리한다. 실제로는 끊임없는 주의 전환과 출력 확인의 연속. | 열린 작업만 쌓여간다 |
서머스도 똑같이 고백한다. 그녀는 최근 새벽 2시까지 프롬프트를 붙들고 있었다. 계획서를 '거의 완벽하게' 만들기 직전이었기 때문이다. "하나만 더 프롬프트하면, 이 기능 하나만 더 완벽하게 만들면…" 이 유혹은 끝이 없다.
동료 마르셀로는 농담처럼 말했다. "Claude 세션을 5개 열어. 나머지한테 피드백 주느라 바빠서, 하나가 멈춰도 눈치 못 챌걸." 서머스는 이 병렬성을 "짜릿하고 좀 야생적(feral)"이라고 표현한다. 여러 개를 시작할 수는 있다. 그런데 끝내는 건 더 적어진다. 왜?
에이전트 세션 수를 늘려보라. 이론상의 처리량과, 하나뿐인 뇌가 실제로 감당하는 '유효 처리량'이 어떻게 벌어지는지 보이는가?
이 현상을 조직 차원에서 보면, 병목의 위치가 이동했다는 것이 드러난다. 예전엔 "코드를 쓰는 것"이 병목이었다. 이제는 "코드를 검증하는 것"이 병목이다.
2025~26년의 여러 산업 리포트(GitLab, Sonar 등)가 같은 방향을 가리킨다.
여기에 더 고약한 진실이 있다. AI가 짠 코드를 리뷰하는 것이, 사람이 짠 코드를 리뷰하는 것보다 더 힘들다. 사람의 코드는 "이 사람이 왜 이렇게 짰을까"라는 의도가 읽힌다. AI의 코드는 어떤 경로로 이 결론에 도달했는지 알 수 없다. 리뷰어는 의도를 처음부터 재구성하고, 가정을 검증하고, 엣지 케이스를 혼자 상상해야 한다.
여기서 서머스는 위로가 되는 역사적 유비를 꺼낸다. 반응형 웹 디자인(Responsive Web Design)이다.
시계를 2009~2010년으로 돌려보자. 당시 웹 디자이너들은 잡지처럼 픽셀 단위로 통제된, 고정폭 레이아웃의 장인이었다. 그런데 스마트폰이 폭발하면서, 2010년 Ethan Marcotte(이선 마콧)가 「Responsive Web Design」을 발표한다. 디자인은 이제 하나의 고정된 화면이 아니라, 온갖 크기의 기기에서 물처럼 흘러야(fluid) 했다. 그 경계선이 바로 브레이크포인트(breakpoint)다.
당시 디자이너들의 저항은 격렬했고, 이해할 만했다. 그들이 수년간 쌓은 '픽셀을 통제하는 기술'이라는 전문성이, 근본부터 흔들렸으니까. 존재론적 위협처럼 느껴졌다.
그런데 이 전환을 살아남고 번성한 사람들은 어떻게 했나? 그들은 자기 기술을 재구성(reframe)했다.
| 낡아 사라진 것 | 더 중요해진 것 |
|---|---|
| 픽셀 단위 완벽 통제에 대한 집착 | 비례와 위계에 대한 감각 |
| 단일 화면의 고정된 완성도 | 시스템으로 사고하기 |
| 모든 것을 내가 배치한다는 통제감 | 불확실성을 위해 설계하기 |
핵심 기술은 죽은 게 아니라 진화했다. 서머스는 이것이 AI 코딩에도 그대로 적용된다고 본다.
"당신은 모든 줄을 손으로 쓰지 않았다고 해서 덜 엔지니어가 된 게 아니다. 하지만 당신은 여전히 '좋은 것'이 무엇인지 알아야 한다 — 오히려 그 어느 때보다 더. 왜냐하면 이제 당신은 훨씬 더 많은 산출물의 품질 게이트이기 때문이다."
다만 그녀는 정직하게 차이도 인정한다. 반응형 디자인은 수년에 걸쳐 진화했다. 지금의 전환은 수개월 단위다. 이 속도 자체가 사람을 지치게 하는 새로운 요인이다. 역사가 위로는 되지만, 그 위로가 피로를 없애주진 않는다.
"누구나 그럴듯한 UI와 컴파일되는 코드를 뽑아낼 수 있는" 시대에, 인간의 차별점은 어디서 오는가? 서머스가 관찰한 것은 이렇다.
여기서 그녀는 결정적인 관찰 하나를 던진다. Pydantic 팀이 LLM으로 큰 성공을 거둔 영역은, 그들이 도메인을 깊이 아는 영역이었다. 반대로 전문성이 얕은 영역에서는 산출물이 눈에 띄게 '인상주의적(impressionistic)'으로 변했다. 모델은 "자기가 무엇을 모르는지를 모르기 때문에, 그 빈틈을 자신감으로 채운다." — 매우 인간적인 실패 방식이다.
그렇다면 살아남는 사람은 전문성을 버리는 게 아니라, 전문성을 증류(distill)한다.
AGENTS.md 파일로 만들었다. 수년간 암묵적으로 쌓인 엔지니어링 판단을, LLM이 따를 수 있는 명시적 지침으로 인코딩한 것이다.번성하는 개발자들의 공통점: 실전에서 나온 강한 소신, 원칙과 (그저 시간이 없어서 생긴) 습관을 구별하는 능력, 그리고 기준을 버리지 않으면서 워크플로를 기꺼이 진화시키는 태도.
서머스는 양극단을 모두 거부한다. 이것은 소프트웨어 엔지니어링의 종말이 아니다. 하지만 낭만적인 "그냥 도구가 하나 더 늘었을 뿐"도 아니다. 그것은 일이 무엇인지 자체가 근본적으로 재편되는, 심각한 수축이자 재구성이다.
그녀는 개발자들의 두려움이 정당하다고 인정한다 — 도태에 대한 공포, 실력 퇴화(skill decay)에 대한 불안, 속도 경쟁이 만드는 초조함. 이걸 "괜찮아, 다 잘될 거야"라고 얼버무리지 않는다.
대신 그녀는 관점을 뒤집는다.
자동화는 역설적으로 진짜 희소 자원이 무엇이었는지를 드러냈다. 코드는 이제 흔하다. 흔해진 코드는 값이 싸다. 그러나 주의력·판단·비전 — 이것들은 여전히 하나뿐이고, 희소하다. 그리고 희소한 것은 가치 있다.
이 통찰을 2026년 한국의 현장으로 가져오면 몇 가지 실천적 함의가 나온다.
70년 전, 노버트 위너는 키잡이의 은유로 하나의 학문을 시작했다. 키잡이는 노를 젓지 않는다. 그는 바람과 물살을 읽고, 방향을 유지한다. 어쩌면 우리는 지금, 프로그래밍이라는 배 위에서 처음으로 진짜 키잡이가 되는 법을 배우는 중인지도 모른다. 노 젓기의 즐거움을 잃은 대신, 방향을 결정하는 무게를 떠안으면서.
서머스의 글이 그토록 널리 공명한 이유는, 그것이 해결책을 팔지 않았기 때문이다. 대신 그것은 정직하게 이름을 붙여줬다. 당신이 동시에 더 생산적이면서 덜 행복하다면, 망가진 건 당신이 아니라 피드백 루프라고. 그리고 그 루프는 — 개인의 실패가 아니라 — 디버깅할 수 있는 엔지니어링 문제라고.
그녀의 마지막 문장은 위로가 아니라 동행의 선언에 가깝다.
"코드는 변하고 있다. 우리가 그것으로 하는 일도 변하고 있다. 그게 어떤 느낌인지는… 아직 작업 중이다(a work in progress). 하지만 인간은 여전히 루프 안에 있다. 우리는 그저 지쳤을 뿐이다. 그리고 그건, 이야기할 가치가 있는 일이다."
우리는 지금 실시간으로 각자의 보상함수를 디버깅하는 중이다. 당신만 그런 게 아니다. 당신이 이 순간을 헤쳐 나가려고 쓰고 있는 바로 그 도구를 만든 팀조차, 똑같이 그것을 느끼고 있다.
인간은 루프 안에 있다. 지쳤지만, 아직 고삐를 놓지 않았다.
