요약
에이전트의 결과를 따져 보지 않고 받아들이는 '인지적 항복'을 경계하고, 맡길 일을 의식적으로 골라야 합니다.
개발자 쿠날이 개인 블로그에 쓴 에세이입니다. 그는 문제를 깊이 생각하지 않고 코딩 에이전트의 출력을 그대로 받아들이는 방식을 인지적 항복이라고 부릅니다. 이 방식은 빠르고 편해서 빠져들기 쉽다고 경고했습니다.
왜 중요한가
- 에이전트 덕분에 코드를 만드는 속도는 빨라졌지만 코드를 이해하는 속도는 그대로입니다. 병목이 이해 쪽으로 옮겨 갔다는 지적입니다.
- 결과물을 이해하지 못해도 책임은 만든 사람에게 그대로 남는다는 점을 짚었습니다.
- 위임을 거부하자는 글이 아니라, 어디까지 맡길지 정하는 실무 방법을 내놓았습니다.
핵심 내용
- 자신 있게 맡길 수 있는 변경의 복잡도를 '바이브 한계'로 정하고, 중요하고 검증이 어려운 시스템에는 직접 시간을 쓰자고 했습니다.
- "계속 진행"을 습관처럼 누르고 있다면 자동화 편향(기계의 판단을 의심 없이 따르는 경향)의 신호라고 봤습니다.
- AGENTS.md에 에이전트가 파일을 직접 고치지 못하게 하는 규칙을 두고 변경은 손으로 하는 식으로 스스로를 작업에 묶어 두자고 했습니다.
- 1983년 논문 「자동화의 아이러니」를 들어, 쉬운 일을 연습하지 않으면 장애에 대응하기가 더 어려워진다고 했습니다.
- 맡길 때는 관측성(시스템 내부를 밖에서 살필 수 있는 정도), 자동 검증, 빠른 배포 같은 안전장치와 느슨하게 결합된 설계를 갖추자고 했습니다.
HN 반응
- 코드를 원래 읽지 않던 비개발자는 결과로 판단하니 항복이 아니라는 의견에, 보안·백업처럼 눈에 안 보이는 문제에서 결국 탈이 난다는 반론이 붙었습니다.
- 코드 생성이 공짜가 되면서 YAGNI·KISS(필요한 것만 단순하게 만들라는 원칙)를 의지력으로만 지켜야 한다는 경험담에 공감하는 댓글이 많았습니다.
여기엔 역설이 있다고 생각합니다. 코딩을 이미 할 줄 아는 사람일 때만 "인지적 항복"일까요? 세세한 부분을 다 모르는 쪽이 오히려 인간의 기본 상태에 가깝습니다. 대부분의 사람은 수돗물이 정확히 어디서 오는지, 오물이 정확히 어디로 가는지 모르니까요. "물은 수도꼭지에서 나오고, 음식은 가게에서 나온다"는 식이죠.
LLM으로 소프트웨어를 만드는 비개발자들 중 대부분은 제가 보기에 "인지적 항복"을 하고 있지 않습니다.
이들은 전에도 코드를 읽지 않았고 지금도 읽지 않습니다. 하지만 시스템과 아키텍처에 대해 질문하고 이해를 넓히는 일은 예전보다 지금이 더 빠르고 쉽습니다.
이들은 눈에 보이는 것, 즉 결과물을 평가합니다. 자기가 쓸 물건을 만들고, 테스트하고, 필요에 맞을 때까지 고쳐 가며 자기가 그린 모습에 가까워지려고 합니다. 예전에 외주 업체에 맡길 때 밟던 과정과 대체로 같고, 다만 순환 주기가 훨씬 짧아졌을 뿐입니다.
잘 돌아가는 것 같고, 문제는 주로 눈에 보이지 않는 곳에서 터집니다. 보안, 백업, 깨지는 마이그레이션, 성능, 시간이 지나면서 필요한 유지보수(언어·런타임 업데이트, 의존성 업데이트, 서버 업데이트 등) 같은 것들요. 무언가의 가동 시간을 책임져 본 적 없는 사람이 겪는 아픔이 전부 여기 있습니다. 소프트웨어에는 "완성"이 없다는 것을 모르는 거죠. 하지만 주니어 개발자도 똑같은 데서 넘어집니다.
글 후반부에는 동의합니다. 그런 것들을 더 눈에 잘 보이게 해 주는 도구와 프로세스가 있다면 격차가 많이 줄어들 겁니다.
"물은 수도꼭지에서 나온다"는 비유를 이어 가 보면, 이 상황은 배관 경험이 전혀 없는 사람이 작동 원리를 알아볼 생각도 없이 욕실을 통째로 뜯어고치겠다고 나서는 것과 비슷합니다. 겉보기엔 멀쩡한 욕실이 나올 수도 있지만, 나중에 물이 새거나, 배수가 제대로 안 되거나, 수압에 문제가 생기는 일이 벌어지기 쉽습니다.
LLM만으로 소프트웨어를 만드는 사람들 가운데는 이걸 사업으로 삼는 이들도 있는데, 이건 하수처리가 어떻게 돌아가는지 하나도 모르면서 소도시의 하수처리장을 운영하겠다고 나서는 것에 비유할 수 있겠죠. 문제가 눈에 보이지 않는 곳에서 터지는 건 마찬가지여서, 식중독이 생기거나 유입구가 역류해 근처 강으로 넘칠 수 있습니다.
그 비유는 새로운 핵심 요소인 AI가 빠져 있어서 곧바로 무너집니다.
욕실 공사 비유에서 AI는 작업을 맡기려고 고용하는 배관공입니다. 원하는 것을 말하면 그에 필요한 세부 사항은 배관공이 알아서 파악해서 해결합니다. 원하는 게 불가능하거나 큰 변경이 필요하다면, 좋은 배관공은 그 문제를 알려 주고, 자기가 받고 있는 제약을 설명하고, 방향을 묻고, 추천안도 내놓죠.
AI가 가끔 이상하거나 비효율적인 방식으로 일하거나, 나중에 중요해질 세부 사항을 놓치거나, 작업에서 중요한 부분을 잘못 이해해서 원하던 것과 다른 결과가 나오기도 합니다. 하지만 그건 배관공도 마찬가지입니다. 사람들이 보통 집수리나 개선 공사를 할 때 집에 있으면서 일하는 사람들을 지켜보려는 것도 그래서입니다. 고용한 사람이 고장 난 수도꼭지를 바꾸는지, 멀쩡하지만 생김새가 이상한 수도꼭지를 바꾸는지 확인하고 싶으니까요.
배관공에게 처음부터 좋은 설계 구상을 전달할 수 있을 만큼 기반 시스템을 잘 아는 것에는 여전히 가치가 있습니다. 유능한 시공자가 나쁜 아이디어를 구현해 버리는 일은 여전히 가능하고, 그렇게 해서 Groverhaus, Doom Bathroom, McMansion Hell 같은 것들이 나왔습니다. 이것들은 우리가 "슬롭 소프트웨어"를 보고 있는 것과 똑같은 의미에서 "슬롭 건축"의 사례입니다.
LLM 이전에도 형편없는 소프트웨어 개발자는 있었어요. 솔직히 많은 사람에게 AI가 만든 슬롭은 예전에 내놓던 결과물보다 엄청나게 나아진 거예요.
그렇게 대행사를 운영하는 건 정말 뻔뻔하다는 데는 동의해요. 제가 보기에 빠져나갈 길은 면허제나 실질적인 책임 부과뿐이에요.
그래도 날림 집수리를 한 번도 안 해 본 사람만 첫 돌을 던지라고 하죠.
출처가 아주 많이 필요합니다. 그렇지 않으면 나쁜 코드를 쓰던 사람이 갑자기 자기를 위해 생성되는 코드의 품질을 지휘할 수 있는 위치에 서기만 하면 나쁜 코드에 따르는 문제들이 어떻게든 사라진다고 주장하는 셈이니까요.
제 주장은 조금 달라요! 효과가 여러 가지로 나타난다는 거예요. 인용할 출처는 없고 일화만 있어요.
"형편없는 프로그래머"(느슨하게 쓴 표현이고, 저도 가끔 그래요! 사람에 대한 가치 판단이 아니에요. 경험이 부족해서일 수도, 평소 분야 밖에서 일해서일 수도, 그냥 컨디션이 나쁜 한 주여서일 수도 있죠)가 짜는 코드는 "프랙탈처럼 틀려서 어디서부터 뭐가 틀렸다고 설명해야 할지 모르겠고, 지금 무슨 일이 벌어지는지에 대한 멘탈 모델이 분명히 하나도 없다" 수준에서 "코드 자체는 괜찮은데 접근이 틀렸고, 이런 일에 200줄짜리 Python 스크립트를 추가할 필요는 없었다" 수준으로 바뀝니다. 다시 작업하는 과정은 올바른 접근법을 설명하는 건데, 그 설명이 사람을 거쳐 Claude에게 전달되고 Claude는 그걸 제대로 알아들어요.
피드백을 주면 그게 그대로 대리 전달되는 데 많은 분이 당했다는 기분을 느끼는 건 알아요. 상대가 성장하는 게 보이고 같은 실수가 반복되지 않는 _관계_가 없으니까요. "작성자"가 로봇을 이용해 내 시간을 훔치는 것 같겠죠. 그래도 저는 직장에서 가끔 안도감을 느껴요. 지식 격차가 정말 큰 상대에게 세부적이고 복잡한 내용을 설명하려면 시간이 훨씬 더 많이 들 텐데... 그럴 땐 상대에게 Claude라는 인지적 보철물이 있다는 게 오히려 고마워요. 때로는 제가 그 보철물이 필요한 쪽이기도 하고요.
좋은 피드백이 없어도 "틀렸다고 말할 가치조차 없는" 수준에서 "좀 엉망이긴 한데 일은 해낸다" 수준으로 올라가는 경우를 자주 봐요.
다른 곳에서는 "좋은 (하지만 아주 꼼꼼하지는 않은) 개발자 -> 슬롭 발사기" 효과가 더 두드러질 수도 있고요. 제 느낌에 AI는 사람들이 할 수 있는 일의 하한선과 상한선을 둘 다 끌어올리고 있어요(탄탄한 시니어나 전문가는 AI를 채찍질해서 결과물을 정말 좋게 만들 수 있죠). 다만 중간 층에서는 특히 이상한 효과가 나타나요. 사람들이 평소 영역 밖의 일에 도전할 수 있게 해 주고(개발자가 인프라를 하고, SRE가 개발을 더 하고, 백엔드와 프런트엔드가 서로의 일을 하는 식으로요), 제 생각엔 바로 거기서 좋은 피드백이 정말 도움이 돼요.
AI의 잠재적 장점 중 하나는 특정 분야의 전문성이 이미 있는 사람에게는 힘을 배가시키는 도구가 되고, 동시에 나머지 모든 사람의 바닥을 끌어올린다는 점이라고 생각합니다.
국지적인 문제에 대한 독립적이고 즉석적인 해법을 찾는 사람들은 그 문제를 현장에서 해결할 능력이 훨씬 커질 것이고, 깊은 전문성을 가진 사람들은 예전에 만들던 것보다 신뢰성, 성능, 확장성이 더 뛰어난 시스템을 만들 수 있을 겁니다.
그러니 기초적인 영역에서는 중간 단계가 사라지는 이점을, 기초적이지 않은 영역에서는 복잡성을 효과적으로 다룰 훨씬 큰 역량을 얻게 될 겁니다.
지금 맡은 역할에서 제가 만든 것 중에 현재 아키텍처를 파악하고, 문서에 적힌 것, 구현된 것, 실제로 동작하는 것 사이의 차이를 해소하도록 돕는 도구가 있습니다. 문서 갱신을 포함해 여러 곳에 쓰이는데, 가장 효과가 컸던 건 신규 엔지니어 온보딩입니다. 이들은 어떤 것이 어떻게, 왜 그렇게 동작하는지 그냥 물어보고, 필요한 곳마다 설명과 깊이 있는 분석을 받을 수 있습니다.
제가 보기에 가장 큰 과제 중 하나는 과잉 설계와 과잉 구현 경향입니다. 공짜로 되는데 8개짜리 클래스 계층을 만들고 클래스마다 200줄짜리 단위 테스트를 붙이지 않을 이유가 뭐겠어요? 예전 같으면 고심해서 30줄로 줄였을 법한 것이 이제는 수백 줄, 심지어 수천 줄로 부풀어 오릅니다.
예전에는 거의 모두가 YAGNI와 KISS에 동의했습니다. 코드를 만드는 데 비용이 많이 들고 유지하는 데는 더 많이 들었으니까요. 이제 코드 생성은 "공짜"입니다. 하지만 설계 수준에서는 YAGNI와 KISS가 여전히 중요합니다. 다만 지금은 순전히 의지력으로만 지킬 수 있습니다. 원하지 않는 코드는 만들어지지 않도록 적극적으로 막아야 합니다. 나무랄 데 없이 멀쩡한 코드예요. 흠을 잡을 수도 없습니다. 하지만 아직 존재할 필요가 없다면 필요한 때보다 일찍 만드는 건 실수라는 걸 저는 압니다.
어린 왕자의 그 문장처럼, 진짜 지성은 무엇을 만들지 말아야 하는지, 꼭 필요한 것만 남을 때까지 무엇을 덜어낼 수 있는지 아는 겁니다.
그 문장은 사실 같은 작가의 회고록 "Wind, Sand, and Stars"에 나오는 겁니다.
같은 주제로 이런 말들도 있습니다.
바로잡아 주셔서 감사합니다. 저는 그 회고록을 읽어 본 적이 없어서 틀림없이 간접적으로 접한 문장이었나 봅니다. 지금 찾아보니 번역본에서는 책 제목이 다르게 붙어 있을 수도 있겠네요.
Airman's Odyssey ― 앙투안 드 생텍쥐페리
그리고 "더 이상 환원할 수 없는 기본 요소들"에 대한 아인슈타인의 멋진 문장도, 복잡함에 대한 데이크스트라의 말도 잘 읽었습니다. 저는 일하면서 "올바른 기본 요소(primitive)를 찾는 것"을 자주 생각하는데, 같은 생각을 여러 사람이 이렇게 훌륭하게 표현했다니 반갑네요.
감사합니다! 위쪽 댓글의 문장은 어쩐지 어린 왕자답지 않게 느껴졌거든요. 생텍쥐페리의 문장이라면 납득이 돼요.
솔직히 이런 건 세상에서 가장 어려운 제안들이고, 최대한 덜어내는 데 성공하는 개발자는 아주 드뭅니다. 예전에는 컴퓨팅 자원의 한계가 워낙 빡빡해서 어느 정도 강제됐지만, 램과 CPU가 무어의 법칙을 타게 되면서 그런 시절은 오래전에 끝났습니다.
HN에 모이는 사람들만 그런 건지 모르겠지만, 많은 개발자가 꼭 그래야 할 이유 이상으로 자기를 훨씬 높게 평가하는 것 같습니다.
KISS를 시도하는 사람이 있기나 한가요? 대부분의 소프트웨어는 비대하고, LLM은 그걸 베낍니다. LLM은 근본적으로 틀을 벗어난 생각을 할 수 없어요.
저도 늘 그게 걱정이었습니다. 쓰레기 코드가 너무 많은데, 어떤 코드가 잘 짜였고 어떤 코드가 아닌지 알려 주는 신호는 거의 없습니다. 그러니 LLM은 학습한 "그럭저럭 쓸 만한" 코드를 그대로 되풀이할 뿐이죠.
지금이야말로 나쁜 코드가 나올 때 모두가 부정적인 피드백을 줄 최적의 시기지만, 충분히 신경 쓰는 사람이 없을 것 같고, 우리는 늘 그랬듯이 그냥 돌아가는 수준에서 타협하게 될까 봐 걱정입니다.
그게 원인은 아니라고 봅니다. LLM이 다루는 컨텍스트가 그냥 너무 작고, 더 커질 수도 없어요. 하니스와 모델 자체가 그 위에 구조를 수작업으로 덧씌우고 있고, 실제 사람들이 보기보다 훨씬 결정론적인 설계 기계를 발명하고 있으며, LLM은 거기에 내용을 채워 넣을 뿐입니다.
그 설계 기계는 아직 충분히 좋지 않고, 발전 속도도 LLM과는 거의 관계가 없습니다. 컴퓨터 프로그램을 설계하고, 가장 쉬운 유지보수와 유연성과 디버깅을 위한 적절한 추상화 수준을 찾는 일은 그냥 아직 풀리지 않은 문제입니다. LLM을 학습시킬 만한 것 중에 프로그램 전체와 그 코드 변경 이력보다 작은 단위는 없습니다.
그런 사례를 몇 개 모아서 거기 담긴 패턴과 교훈을 분석하고 압축할 방법을 찾아내고, 그걸로 학습시키면 될지도 모르겠습니다. 그 전까지는 특정 추상화가 없을 때 결국 어떤 대가를 치르게 되는지 LLM이 알아낼 방법이 없습니다.
결국 작업물은 자기 작업물입니다. Claude든 뭐든 어떤 일을 하라고 시키면, 시키는 방식 그대로 그 일을 합니다.
세부 사항은 무시하고 무엇을 만들지만 말할 수도 있고, 시간과 노력을 더 들여 어떻게 할지까지 말해 줄 수도 있습니다. 계획을 만들어 달라고 해서 그 계획을 검토하고 수정을 요청할 수도 있고, 구현을 검토하고 거기서 수정을 요청할 수도 있죠. 어떤 기능이 구현된 방식이 마음에 안 든다고 말하고 개선 방법을 제안해 달라고 할 수도 있는데, 어디가 마음에 안 드는지도 함께 적어 주면 방향을 잡는 데 도움이 됩니다.
전부 들이는 노력에 달렸습니다. LLM은 깔끔하고 아름답고 효율적인 코드를 쓸 수 있습니다. 다만 아무 방향 없이 첫 시도에 정확히 원하는 대로 해내지는 못할 뿐입니다. 그러니 원하는 게 뭔지 정리하고, 원하는 것을 요청하고, 정말로 원하는 것을 만들고 있는지 확인해야 합니다.
정말 맞는 말이에요. 너무 많은 일을 하면서도 정작 내세운 목표는 달성하지 못하는 LLM 생성 코드를 계속 보고 있어요. "최대한 유연한" 플러그인 시스템이라는데, 정작 플러그인 하나 빨리 쓰기엔 너무 복잡해요. 필요한 기능은 몇백 줄이면 그냥 내장할 수 있었는데 말이죠.
끝없는 부트스트래핑과 뼈대 세우기가 공짜가 되면, 가장 아름다운 비계를 세워 놓고 그 뒤의 건물은 아예 신경 쓰지 않게 돼요.
저는 이 문제를 한동안 생각해 왔습니다. 저는 러다이트가 아니고, 최신 AI가 가져오는 놀라운 가치와 그 쓸모를 알고 있습니다.
그와 동시에, 이건 우리가 감당하기에 거의 너무 벅찬 게 아닌가 하는 생각을 떨칠 수 없습니다. LLM은 너무 쓰기 쉬워요. 우리는 여기에 문제가 없는 척하는 데 아주 능숙하지만, 인지 능력 저하는 분명히 일어날 겁니다.
우리는 LLM의 출력을 훑어보는 게 우리가 직접 그 변경을 하는 것과 거의 같은 척하고 싶어 하지만, 저는 그 지루하고 수작업인 단계에 상당한 가치가 있다고 생각합니다. 그리고 (저를 포함한) 대부분의 사람은 너무 게을러서 결국 대부분의 일을 LLM에 넘기지 않고는 못 배길 겁니다.
어떤 면에서는 강의를 보면 이해한 것 같은 "인상"을 받지만 그게 현실과 상관없는 경우가 많은 것과 비슷합니다. 우리의 원숭이 같은 뇌를 움직이게 하려면 직접 손을 움직이는 작업과 약간의 수업 과제가 필요합니다.
교육에 이게 어떤 영향을 줄지는 상상만 할 수 있을 뿐입니다.
우리는 수백 년에 걸쳐 인지 능력의 쓰임새를 많이 포기하고 다른 것으로 바꿔 왔습니다.
우리의 인지 능력은 온라인 토론에서 논거를 만들려고 진화한 게 아니라, 조잡한 도구를 만들고 사냥하려고 진화했습니다. 도구 덕분에 그런 용도로 지능을 쓰지 않게 되자, 우리는 그 지능을 전에는 상상도 못 했던 새로운 문제로 돌렸을 뿐입니다.
원시인은 오늘날 대부분의 아이가 배우는 대수학 같은 것에는 별 관심이 없었을 겁니다.
AI가 사소하게 만들어 버린 문제들에 대한 생각은 그만하고, AI가 인간의 능력을 완전히 대체하지는 않으리라는 가정(핵심 가정입니다) 아래 전에는 손이 닿지 않던 문제들을 생각하기 시작해야 합니다. 그러면 교육도 그쪽에 초점을 맞추기 시작하겠죠.
맞는 말이지만, 인지 능력이 쇠퇴한다는 건 예전에는 무엇이 가능했는지조차 알아차리지 못하게 된다는 뜻이기도 합니다.
옷을 예로 들어 보죠. 지금은 그 어느 때보다 옷이 많습니다. 환경과 옷을 만드는 노동자에게는 큰 대가를 치르게 하지만, 입는 사람에게는 거의 비용이 들지 않는 일회용품이죠.
그런데 아마 여러분은 옷, 봉제, 원단의 품질을 평가하지 못할 겁니다. 울이나 리넨 옷을 어떻게 빠는지도 모를 수 있고요. 냄새나는 플라스틱 운동복과 플라스틱 정장만 입어 봤을 수도 있습니다.
몸에 실제로 맞는 옷을 한 번도 입어 본 적이 없을 수도 있고요.
어떤 옷이든 수선할 수 있다는 것도, 예전에는 대부분의 옷이 수선하는 걸 전제로 만들어졌다는 것도 모를 수 있습니다. 옛날 옷이 더 비쌌고 품질도 더 좋았던 건, 가장 중요한 옷은 10년은 입어야 한다고 기대했기 때문이라는 것도요.
러다이트가 자동화에 제기한 핵심 반대는 악화되는 노동 조건(예를 들어 아동 노동에 대한 반대), 낮은 임금, 떨어지는 품질에 관한 것이었습니다. 이들은 자기들이 부순 그 '불쾌한' 기계를 썼던 사람들입니다. 무엇을 잃고 있는지 보았고, 더 나은 것을 요구했습니다(기계를 아예 없애라고 요구한 게 아닙니다).
나중에 노동조합이 커지면서 이들이 수십 년 전에 요구했던 변화 상당수가 이루어졌습니다.
저는 이번 기술 흐름이 패스트 패션이 도달한 곳, 즉 인플루언서가 1년 내내 매일 새 옷 [repo]을 사는 곳에서 끝나지 않기를 바랍니다. 그 자체가 목적인, 아무 개성 없는 슬롭의 소용돌이 말입니다.
정확히 이 주제를 다룬 브라이언 머천트의 책 "Blood in the Machine"도 추천합니다 [0][1].
[0] https://www.hachettebookgroup.com/titles/brian-merchant/blood-in-the-machine/9780316487740/
[1] https://www.bloodinthemachine.com/about
그때는 소득의 10~15%를 옷에 썼다는 점도 얘기하실 건가요? 가치 있는 교환이 이루어진 겁니다.
'제3세계' 아동 노동자들에게 해악을 떠넘기는 게, LVMH의 다음 분기 이익이 투자자 기대에 살짝 못 미치는 것을 막을 만한 가치가 있다고는 생각하지 않습니다.
옷은 지금도 사람 손으로 꿰매고 있고, 저는 엄청난 해악을 뒷받침하고 있지 않다는 걸 알 수 있다면 훨씬 더 많은 돈을 기꺼이 낼 겁니다.
시간당 몇 센트를 받고 그 티셔츠를 꿰맨 사람을 직접 만나야 한다면, 그래도 싼 티셔츠를 기분 좋게 사시겠습니까?
패스트 패션과의 비교가 적절하네요. 값싼 슬롭(옷도 코드도)은 우리 체제가 환경이나 인권보다 이윤을 더 중시하기 때문에만 존재할 수 있어요. 이미 있는 산업들에서도 이런 학대를 막지 못했으니, AI 흐름의 미래에 대해서도 조금은 비관적이 돼요. :~/
맞아요, 하지만 대수학은 공짜입니다. 연필과 종이만 있으면 할 수 있으니까요.
AI는 공짜가 아닙니다. "무료"인 오픈소스 모델조차 복잡한 실리콘이 있어야 돌아갑니다. 그 실리콘과 구리는 복잡한 제조 공장에서 조립되고, 그 공장들은 지정학적으로 적대적인 세력과 아주 가까이 있습니다.
제가 거부하는 건 의존입니다. 단기적인 생산성을 얻으려고 장기적인 의존과 맞바꿀 생각은 없습니다.
그렇다면 당신은 이미 너무 멀리 와서 돌아갈 수 없습니다. 휴대폰과 컴퓨터에서 떠나 보세요. 인프라와 염소 처리된 수돗물에서도 떠나 보세요. 약과 항생제에서도 떠나 보세요. 인류는 이미 스스로에 대한 의존성을 엄청나게 쌓아 왔습니다.
전화망은 국가 소유이고 상수도도 마찬가지입니다. 이런 것들이 무너지는 시나리오는 제 국가 자체가 실제로 붕괴할 때뿐입니다. (그때를 대비한 대책도 세워 놨습니다. 어디로 이민 갈지도 알고 있고요)
문제는 특정한 의존의 비용과 이익입니다.
컴퓨터에 단순 반복적인 정신 노동을 맡긴 덕분에 우리는 과학의 새로운 지평으로 갔고, 우리 대부분은 딱히 생각을 더 못하게 되지도 않았습니다. 컴퓨터 때문에 사고력이 빈약해졌을 수 있는 유일한 집단은 학생들인데, 그건 해당 교육 체계 안에 있는 사람들이 논의할 교육 문제일 뿐입니다.
AI는 범용 지능 계산기입니다. 허락하면 거의 모든 논리적·감정적 임무를 대신 수행해 줄 겁니다. 계산기는 생일 축하 인사를 써 주지도, UFO를 믿지 않는다는 이유로 연인과 헤어진 게 전적으로 옳았다고 안심시켜 주지도 못하죠... 검색이나 코딩 같은 소소하고 실용적인 일에 LLM을 쓰기 시작했다가 점차 감정적 의존과 망상에 빠지는 경우는 기록으로 남은 흔한 경험입니다.
우리가 이런 위안을 찾는 건 생각하는 게 힘들기 때문입니다. 내 선택이 어떻게 평가받을지, 또래에게 뒤처질지, 실수할지를 생각하면 두렵습니다... 하지만 그것들이 없으면 인간을 인간답게 만드는 근본적인 부분을 잃게 됩니다. 자기 감정을 처리하는 데 데이터센터가 필요해서는 안 됩니다.