루프 안의 인간은 지쳤다

https://pydantic.dev/articles/the-human-in-the-loop-is-tired

또 LLM에 대한 생각 글이냐 싶으실 겁니다. 압니다. 그래도 조금만 참고 읽어 주시길 바랍니다.

이 글은 지금 대부분의 개발자가 겪고 있지만 미처 정리할 시간이 없었던 무언가를 말로 옮겨 보려는 시도입니다. LLM과 함께하는 프로그래밍은 정말로 유용하면서, 동시에 정말로 사람을 흔들어 놓습니다. 이 두 가지는 공존합니다. 두 번째가 없는 척하면 우리는 모두 번아웃되고 말 것입니다.

Pydantic에서 우리는 개발자들이 데이터를 검증하고, AI 에이전트를 만들고, 프로덕션에서 시스템이 무엇을 하는지 관찰하는 데 쓰는 도구를 만듭니다. 말 그대로 LLM 기반 소프트웨어를 더 신뢰할 수 있게 만드는 일이 우리의 업입니다. 그런 우리 역시 요즘 묘한 시간을 보내고 있습니다.

이 글은 AI가 프로그래머를 대체할 것인가를 논하는 글이 아닙니다. 비관론도 아니고 과대 선전도 아닙니다. 지금 이 순간 개발자로 산다는 게 어떤 느낌인지, 그 한가운데에 있는 사람이 쓴 솔직한 기록이며, 실제로 도움이 될 만한 것들에 대한 생각입니다.

우주의 결에 손을 담그다

20대 초반에 처음 코딩을 배울 때, 프로그래밍이 우주의 결에 손을 담가 제 뜻대로 빚어내게 해 준다는 또렷한 감각을 느꼈던 기억이 있습니다. 물론 컴파일 에러를 수없이 맞닥뜨리기 전의 이야기입니다. 하지만 어떤 깊고 근본적인 추상의 층위를 만진다는 느낌, 오직 논리만으로 무언가를 만들어 낼 수 있다는 그 느낌은 지금까지도 마음에 남아 있습니다.

저는 컴퓨터공학 전공자가 아닙니다. 디자이너이자 프로그래머인데, 앞의 것은 정식으로 배웠고 뒤의 것은 독학했습니다. 소프트웨어 공학의 형식과 원칙들은 학교 수업이 아니라 뼈아픈 경험을 통해 익혔습니다. 오히려 그 덕분에, 일단 이해하고 난 뒤에는 그 원칙들을 더 진지하게 받아들이게 됐습니다. 아키텍처와 코드 품질에 대한 견해를 몸으로 부딪혀 얻고 나면, 그것은 교과서의 규칙이라기보다 흉터에 가깝게 느껴집니다.

그 원초적인 창조의 감각. 2010년대의 로우코드·노코드 도구들이 줄곧 약속했지만 끝내 지키지 못했던 게 바로 그것입니다. 저는 Dreamweaver로 웹 페이지를 만들고, Adobe가 겉으로는 코드 없는 디자인을 내세우면서 속으로는 완전히 스파게티 코드를 뱉어 내는 도구들을 요란하게 선전하는 모습을 지켜보던 시절을 기억할 만큼 나이를 먹었습니다. 언제나 거의 다 온 것 같았고, 미래가 코앞에 와 있다고 넌지시 믿게 만들 정도로는 그럴듯했습니다(그걸 붙잡을 만큼 똑똑하기만 하다면 말입니다).

지금의 AI 도구 물결에 냉소적이시라면, 이해합니다. 전에도 이런 약속을 들어 봤으니까요. 하지만 이번에는 약속과 현실의 간극이 실제로, 마침내, 의미 있는 수준까지 좁혀졌습니다. 그리고 바로 그 점이 이토록 불안하게 만듭니다.

"코드가 알아서 써진다"는 건 실제로 어떤 느낌인가

그렇습니다. 코드는 (어느 정도) 알아서 써집니다. 하지만 검토하고, 지시하고, 방향을 바로잡는 인간의 기분은 나아지기는커녕 더 나빠집니다.

최근 동료 Douwe와 이야기를 나눴습니다. Pydantic AI 프레임워크를 관리하는 사람이고, LLM을 오픈소스 워크플로에 접목하는 문제에 관해 제가 아는 가장 사려 깊은 사람 중 하나입니다. 아침마다 눈을 뜨면 밤사이 누군가의 AI가 만들어 올린 PR이 30개씩 쌓여 있고, 그 하나하나에 그 자리에서 판단을 내려야 한다고 했습니다. 리뷰 자체를 AI에 맡기고 싶은 유혹이 엄청났다더군요. 하지만 본인 표현을 빌리면 이렇습니다. "그 지경이 되면, 저는 여기서 대체 뭘 하고 있는 걸까요?"

솔직히 말하면, 지난 몇 달 사이 LLM에게 실행시킬 계획을 쓰는 데 꼬박 이틀 가까이를 쏟은 날들이 있었습니다. 강박적으로 명확히 하고, 명세하고, 다시 명세했는데도 결과는 여전히 설명이 안 되는 바보짓이었습니다. React 훅을 Storybook 스토리 파일에 옮겨 심는다든가. 엉뚱한 계획 문서를 읽는다든가. 존재하지 않는 컴포넌트를 지어낸다든가. 그런데 이것들은 능력의 오류가 아니라 일관성의 오류입니다. 모델은 그럴듯한 코드를 만들어 낼 만큼은 똑똑하지만, 복잡한 변경 전반에 걸쳐 일관된 의도를 유지할 만큼 늘 똑똑하지는 않습니다.

여기서 기묘한 새 종류의 피로가 생겨납니다. 감독의 피로입니다. 기계가 대체로 맞지만 여전히 제 눈과 판단과 안목을 거쳐야 하는 산출물을 대량으로 뽑아내는 동안, 머릿속에 의도를 계속 붙들고 있어야 하는 피로죠. Douwe가 잘 표현했습니다. 예전에는 오픈소스에서 진짜 사람과 멋진 기능을 함께 만들며 도파민이 솟는 순간이 있었다고요. 누군가가 자기 기술을 더 갈고닦도록 돕는 일 말입니다. 그런데 지금은 이렇답니다. "제가 쓰는 모든 게 어떤 AI 블랙홀 속으로 빨려 들어가요. 반대편에서 실제로 뭔가를 배우는 사람이 없어요." 그 상실은 실재하고, 이름을 붙여 둘 가치가 있습니다.

노동 강도의 덫

Simon Willison이 최근 버클리 하스의 연구를 소개했는데, AI 사용이 일의 강도를 어떻게 끌어올리는지를 다룬 연구입니다. "퇴근 전에 프롬프트 하나만 더, 이걸 완벽하게 만들어 줄 기능 하나만 더" 하고 끊임없이 잡아끄는 힘. 뼛속까지 공감했습니다. 얼마 전에도 새벽 2시 가까이까지 프롬프트를 붙잡고 있었습니다. 계획이 거의 다 맞아떨어지기 직전이었으니까요. 적어도 그렇게 믿었으니까요.

또 다른 Pydantic 동료 Marcelo는 Claude Code 세션이 멈추면 어떻게 하느냐는 질문에 이렇게 답했습니다. "그냥 claude 세션을 5개 열어 두세요. 다른 세션들에 피드백 주느라 바빠서 멈춘 줄도 모를걸요." 농담이었습니다. 아마도요. 하지만 지금 이 순간의 진실을 정확히 담고 있습니다. 그 병렬성은 짜릿하고, 어딘가 야생적입니다. 시작할 수 있는 일의 개수는 극적으로 늘었습니다. 하지만 제대로 생각하며 끝낼 수 있는 일의 개수는 전혀 변하지 않았습니다. 그 부분에는 여전히 우리가 병렬화할 수 없는 단 하나의 자원, 즉 뇌가 필요하기 때문입니다.

지금 일어나는 일에 이름을 붙여 보자면 이렇습니다. 인간 보상 함수 문제(the human reward function problem). 머신러닝에서 보상 함수는 에이전트에게 무엇이 좋은 것인지 알려 줍니다. 손으로 코드를 쓰는 일은 결코 쉬웠던 적이 없지만, 작은 보상들로 가득했습니다. 머릿속으로 문제를 풀어내는 순간. 골치 아픈 로직을 이해하게 되는 순간. 코드가 컴파일되는 걸 지켜보는 순간. 통제하고 있다는 감각. LLM 보조 프로그래밍은 그런 도파민을 만들어 내던 작업 대부분을 자동화해 버렸고, 그 자리를 검토와 감독이라는 인지 부하로 채웠습니다. 만족스러운 부분은 줄었습니다. 진 빠지는 부분은 늘었습니다. 그리고 그 공백을 메워 줄 새로운 보상은 없습니다.

일이 전보다 생산적이면서 동시에 덜 만족스럽다고 느껴진다면, 고장 난 것은 사람이 아닙니다. 고장 난 것은 피드백 루프입니다. 그리고 이제는 이것을 개인의 실패가 아니라 그 자체로 하나의 엔지니어링 문제로 다루기 시작해야 한다고 생각합니다.

솔직히 말해, 꽤 외로운 일이기도 합니다. LLM과 함께하는 프로그래밍은 지독하게 고독한 활동입니다.

저와 기계가 주거니 받거니 하며 다듬고, 프롬프트를 넣고, 검토합니다. 동료에게 고개를 돌려 질문을 던지고, 러버덕 삼아 문제를 털어놓고, 마침내 뭔가 맞아떨어진 작은 승리를 나누던 자연스러운 순간들. 그 순간들이 소리 없이 또 하나의 프롬프트로 대체됩니다. 협업 문화가 단단히 자리 잡지 못한 팀에서는 이것이 사람들을 더 갈라놓기 쉽고, 다른 사람들도 이걸 어려워하고 있다는 위안이 가장 절실한 바로 그 순간에 소통을 얼어붙게 만들기 쉽습니다.

게다가 이 일은 고립을 더 악화시키는 방식으로 중독적입니다. 어떨 때는 눈부신 결과가 나오고 어떨 때는 쓰레기가 나오는데, 어느 쪽일지 미리 알 길이 없습니다. 교과서에 나오는 스키너 상자 그대로입니다. 한 걸음 물러나 '그냥... 직접 코드를 써도 된다'는 사실을 떠올리기가 정말로 어려울 수 있습니다. 하지만 LLM 보조 작업과 수작업 사이를 오가는 것은 삐걱거리고 불편한 일입니다. 전혀 다른 두 가지 사고 모드이기 때문이고, 스스로에게 전환을 허락하려면 일종의 성숙함과 자신감이 필요합니다.

브레이크포인트

지금 이 순간은 반응형 디자인이 몰고 왔던 공포와 불안을 떠올리게 합니다. 당시 저는 디자이너 겸 프론트엔드 개발자로 일하면서 남들처럼 Ethan Marcotte와 Zeldman / A Book Apart 진영을 따라가고 있었는데, 우리 모두가 통달해 있던 고정폭 레이아웃이 사실상 끝났다는 말을 들었을 때 얼마나 심란했는지 기억합니다.

젊은 개발자들을 위해 설명하자면, 2009년 무렵 웹사이트가 픽셀 하나까지 맞춘 잡지식 고정 레이아웃에서 유동적인 반응형 레이아웃으로 넘어가던, 진짜 문화적 전환의 순간이 있었습니다. 그리고 디자이너들은 그걸 증오했습니다. 정밀한 레이아웃과 완벽한 그리드를 중심으로 정체성 전체를 쌓아 온 사람들에게 통제력의 상실은 존재를 흔드는 문제였습니다. 사용자가 제 디자인을 아무 너비로나 볼 수 있다고요? 아무 기기에서나요? 제가 공들여 짠 레이아웃이... 흘러내린다고요?

이미지 디자인: Jyotika Sofia Lindqvist

저항은 거셌습니다. 그리고 이해할 만했습니다. 근본부터 뒤흔들리고 있던 그 패러다임 위에 사람들은 진짜 전문성을 쌓아 왔던 것입니다. 그 전환기를 잘 헤쳐 나간 디자이너들은 자기 기술을 새로운 틀로 바라본 사람들이었습니다. 비례를 보는 눈은 여전히 중요했습니다. 위계에 대한 이해도 여전히 중요했습니다. 장인의 기술은 죽지 않았고, 진화했습니다. 덜 중요해진 것은 픽셀 단위 통제에 대한 집착이었습니다. 더 중요해진 것은 시스템에 대한 이해, 적응력, 그리고 불확실성을 전제로 한 디자인이었습니다.

이 비유를 과장하고 싶지는 않습니다. 반응형 디자인은 몇 년에 걸쳐 진행됐습니다. 지금의 전환은 몇 달 단위로 움직입니다. 반응형 전환기에도 에이전시는 고객을 잃고 디자이너는 일감을 잃었지만, 지금 같은 실존적 공포까지는 아니었습니다. 걸려 있는 것의 무게가 실질적으로 다르고, 속도는 반응형 전환기에는 없던 방식으로 사람을 진 빠지게 합니다. 하지만 그 밑에 깔린 패턴, 즉 장인의 기술은 죽는 게 아니라 진화한다는 것, 핵심 역량은 덜이 아니라 더 중요해진다는 것. 그것만큼은 유효하다고 생각합니다.

LLM과 함께 코드를 다루는 지금이 비슷한 변곡점처럼 느껴집니다. 기술이 사라진 게 아니라 이동하고 있는 것입니다. 모든 줄을 손으로 쓰지 않았다고 해서 덜 훌륭한 엔지니어가 되는 게 아닙니다. 다만 무엇이 좋은 것인지 알아보는 눈은 여전히, 어쩌면 그 어느 때보다 더 필요합니다. 이제는 훨씬 더 많은 양의 산출물을 걸러 내는 품질 관문이 바로 우리 자신이기 때문입니다.

살아남는 것

누구나 그럴듯해 보이는 UI와 컴파일되는 코드를 만들 수 있는 시대에는, 사람을 구별 짓는 표지가 달라집니다. 안목, 미묘한 차이를 읽는 감각, 성숙한 아키텍처 견해, 그리고 패턴 맞추기가 아니라 진짜 전문성에서 나오는 남다른 판단이 그것입니다.

눈에 띄는 점이 하나 있습니다. 우리가 LLM을 가장 성공적으로 이끄는 영역은 코드와 결정과 트레이드오프를 가장 깊이 이해하고 있는 영역이라는 것입니다. 자기 역량의 얕은 물가로 나갈수록 산출물은 눈에 띄게 인상주의적으로 변합니다. 프로덕션에 쓸 수 있는 수준에서는 멀어집니다. 더 그럴듯해 보이지만, 실제로 맞는 정도는 떨어집니다. 모델은 자기가 모르는 것을 모르기 때문에, 그 빈틈을 자신감으로 메웁니다. 어디서 많이 들어 본 이야기 아닌가요? 지극히 인간적인 실패 방식이기도 합니다.

하지만 새로운 기술도 생겨나고 있습니다. 저는 복잡한 계획에 대해 이른바 사전 부검(pre-mortem)이라는 것을 돌리기 시작했습니다. 새 LLM 세션을 열어 '이 계획이 처참하게 실패했다고 가정하고 이유를 진단해 보라'고 시키는 것입니다. 이틀 내내 디테일에 파묻혀 있느라 제가 놓친 명세의 빈틈을 이 방법이 잡아냅니다. 우리 엔지니어 한 명은 자신의 과거 코드 리뷰 코멘트 수천 개에서 규칙을 추출해 AGENTS.md 파일의 씨앗으로 삼는 도구를 만들었습니다. 몇 년치 암묵적인 엔지니어링 판단을 LLM이 따를 수 있는 지침으로 옮겨 담은 셈입니다. 이것은 전문성의 죽음이 아닙니다. 전문성이 증류되고 있는 것입니다.

지금 이 시기에 중심을 잡아 가는 사람들은 몇 가지 공통점이 있어 보입니다. 실전으로 벼려 낸 뚜렷한 견해가 있고, 여전히 유효한 원칙과 그저 여력의 한계 때문에 생겼을 뿐인 습관을 구별할 줄 알며, 자기 기준을 버리지 않으면서도 작업 방식을 기꺼이 진화시킵니다.

루프 안에서 본 풍경

지금의 AI 물결이 직업으로서의 소프트웨어 엔지니어링의 종말이라고는 생각하지 않습니다. 다만 심각한 축소이자, 이 일이 무엇인지에 대한 근본적인 재편이라고는 생각합니다. 쓸모없어질지 모른다는 두려움은 정당합니다. 실력이 녹슬지 모른다는 두려움도 정당합니다. 그리고 충분히 빨리 달리지 않으면 뒤처질 거라는 두려움은, 흔히 과장되긴 해도, 전혀 근거 없는 것은 아닙니다.

하지만 병목은 애초에 코드가 아니었습니다. 언제나 인간의 주의력, 엔지니어링 판단, 시스템에 대한 일관된 비전을 붙들고 있는 능력이 병목이었습니다. 코드를 쓰는 일이 어려운 부분처럼 느껴졌기 때문에 눈치채지 못했을 뿐입니다. 이제 그 부분이 자동화되면서, 그런 인간의 역량이야말로 진짜 희소 자원이었다는 사실이 드러나고 있습니다. 그리고 희소 자원은 가치가 있습니다.

그러니 벅차고, 흔들리고, 더 생산적이면서 동시에 덜 행복하다고 느끼고 계시다면, 혼자가 아니라는 것을 알아 두시면 좋겠습니다. 이 시기를 헤쳐 나가는 데 쓰고 계실 바로 그 도구를 만드는 팀도 똑같이 느끼고 있습니다. 우리도 여러분과 마찬가지로, 실시간으로 우리 자신의 보상 함수를 디버깅하는 중입니다.

코드가 변하고 있습니다. 코드로 하는 일도 변하고 있습니다. 그 느낌이 어떤가 하는 문제는... 아직 진행 중입니다.

하지만 인간은 여전히 루프 안에 있습니다. 다만 지쳤을 뿐입니다. 그리고 그것은 이야기할 가치가 있는 일입니다.