모뎀 연결음을 기억하시나요? AI가 원하는 걸 다 해주는 지금, 우리가 기계와 맺던 관계 자체가 조용히 사라지고 있다는 이야기입니다.
AI 의존이 커질수록 왜 기계를 더 모르게 될까요?
1990년대에 게임 하나 돌리려면 먼저 컴퓨터와 한판 붙어야 했어요. autoexec.bat을 열어 메모리 설정을 바꾸고, 게임 전용 부팅 디스크를 만들고, 사운드 카드가 어떤 인터럽트(IRQ)에 응답하는지 손으로 맞춰야 했죠. 틀리면 아무것도 안 돌아갔고, 그 실패가 곧 배움이었습니다.
최근 업계에서 화제가 된 <The Last People Who Know How It Works>라는 에세이가 바로 이 지점을 찌릅니다. 저자 Cyrus Lopez는 “어려움이 곧 지식이었다(The difficulty was the knowledge)”는 한 문장으로 그 시절을 압축해요. 저는 커리어를 AI 서비스 개발자로 시작했고, 모델을 어떻게 학습시키고 다듬는지 그 안을 들여다보며 성장했는데요. 그래서 이 글이 유독 오래 남더라고요. 원문을 읽고 제 관점을 더해 정리해봤습니다.
⚡ 이 글의 핵심만 먼저 보기 (Key Takeaways)
- 마찰이 곧 매체였다: 1990년대 컴퓨터는
autoexec.bat·부팅 디스크·IRQ 설정으로 사용자를 밀어냈고, 그 저항을 뚫는 과정이 지식의 통로였습니다. - 사라지는 건 역량이 아니라 친숙함: AI 모델은 사람이 안 읽는 매뉴얼까지 읽었지만, 기계와 싸우고 실패하며 생기는 ‘acquaintance(친숙함)’는 재현되지 않습니다.
- 순응하는 도구의 함정: AI는 조건을 내걸지 않고 문장에 맞춰 스스로를 바꿉니다. 도전하지 않는 기계는 ‘사용의 대상’이 될 뿐 ‘아는 대상’이 되기 어렵습니다.
- 결정성의 상실이 진짜 변화: 이번 추상화 도약이 이전과 다른 이유는, 같은 요청에도 매번 다른 코드가 나오는 비결정성 때문입니다.
- 지식의 이식성이 떨어진다: LLM이 ‘작동했으니 됐다’며 넣은 코드는 왜 그런지 설명이 없어, 한 시스템의 이해를 다른 곳에 옮기기 힘들어집니다.
- 당장 해볼 액션: AI에게 “이거 해” 대신 “이게 어떻게 작동하는지 알려줘”로 물어보세요. 같은 도구가 놀라운 학습 도구로 바뀝니다.
📌 목차
- 어려움이 곧 지식이던 컴퓨터 경험
- 순응하는 AI, 저항하지 않는 기계는 알 수 없다
- 사라지는 건 역량이 아니라 ‘친숙함’이다
- AI 네이티브 세대는 무엇을 잃는가
- AI 서비스 개발자로서 나는 이걸 어떻게 보나
- 이런 분들께 적극 추천합니다
- 자주 묻는 질문 (FAQ)
1. 어려움이 곧 지식이던 컴퓨터 경험
원문에서 가장 인상적인 표현은 “질 수 있는 대상만 알 수 있다”였어요. 기계가 나를 밀어내니까, 그 저항을 이해하려다 결국 기계를 알게 된다는 겁니다. 저항 자체가 지식을 전달하는 매체였던 셈이죠.
① autoexec.bat & boot disk — 설정 파일이 곧 성적표
게임을 켜려면 autoexec.bat과 config.sys를 직접 편집해 확장 메모리를 확보해야 했어요. 게임마다 요구가 달라서 전용 부팅 디스크를 따로 만드는 일도 흔했고요. 이 과정에서 사용자는 원치 않아도 ‘메모리 구조’라는 개념을 몸으로 익혔습니다.
💡 실제 활용 시나리오 예시:
지금도 리눅스 서버에서 부팅이 안 될 때fstab한 줄을 고쳐 살려낸 경험이 있는 사람과 없는 사람은 대응 속도가 완전히 다릅니다. 그 감각의 뿌리가 바로 이 ‘설정 파일과 싸우던’ 경험이에요.
② IRQ & jumper — 손톱으로 맞추던 하드웨어
사운드 카드가 어떤 인터럽트에 응답하는지 모르면 소리가 안 났고, 드라이브 점퍼는 손톱으로 핀을 옮겨 마스터/슬레이브를 지정했죠. 물리적으로 틀리면 물리적으로 안 돌아갔습니다. 지금 보면 불편의 극치지만, 그 덕에 ‘하드웨어는 주소와 신호로 대화한다’는 감을 자연스럽게 얻었어요.
💡 실제 활용 시나리오 예시:
모뎀 협상음을 반복해 듣던 사람은 소리만으로 통화가 끊길 조짐을 알아챘다고 해요. 300보드에서 2400보드로 넘어가던 순간이 ‘마법’ 같았다는 회고가 왜 나오는지, 이 감각을 겪어본 사람이라면 바로 공감할 거예요.
2. 순응하는 AI, 저항하지 않는 기계는 알 수 없다
원문은 오늘날의 AI를 “마지막 편의성(the last convenience)”이라 부릅니다. 설정 파일을 읽게 하지 않고, 조건을 내걸지도 않아요. 내가 원하는 걸 문장으로 말하면 결과가 나오고, 불만을 표하면 사과한 뒤 다시 시도합니다.
1) compliant tool — 나에게 맞춰 스스로를 바꾸는 도구
여기서 저자의 핵심 통찰이 나옵니다. “도전하지 않는 기계는 알 수 없는 대상이다(A machine that cannot challenge you is a thing you cannot know).” 나를 밀어내지 않고 오히려 나에게 순응하는 도구는, 편할수록 ‘사용의 대상’에 머물 뿐 ‘이해의 대상’이 되지 않는다는 거죠.
💡 실제 활용 시나리오 예시:
WireGuard로 직접 VPN을 구성하면 네트워크 경로·방화벽 규칙·키 쌍·systemd 유닛을 다 이해하게 됩니다. 하지만 Tailscale에 맡기면 5분 만에 ‘그냥 된다’는 결과만 남죠. 원문 저자도 결국 후자를 택했다고 고백해요. 편의성이 너무 유혹적이라서요.
3. 사라지는 건 역량이 아니라 ‘친숙함’이다
이 글이 흔한 ‘라떼는’ 푸념과 다른 지점이 여기예요. 저자는 competence(역량)와 acquaintance(친숙함)를 분명히 구분합니다.
| 구분 | 지금 상태 |
|---|---|
| 역량(competence) | 오히려 더 안전해짐. AI는 사람이 안 읽는 매뉴얼까지 다 읽었고, 작동 원리를 설명할 수 있음 |
| 친숙함(acquaintance) | 사라지는 중. 특정 기계와 부딪히고 실패하며 마침내 작동시키는 관계 자체가 줄어듦 |
저자의 표현을 빌리면 손실은 교육적인 게 아니라 관계적(relational, not educational)입니다. 지식은 그 어느 때보다 안전한데, 기계와의 ‘관계’가 끊기고 있다는 거죠.
2) 결정성의 상실 — 이번 도약이 진짜 다른 이유
커뮤니티 토론에서 저도 크게 공감한 지적이 있었는데요. 이전의 추상화(어셈블리→C→고수준 언어)와 이번 AI 추상화가 결정적으로 다른 건 결정성(determinism)의 상실이라는 겁니다. 예전엔 코드를 보고 “왜 이렇게 했어?”라고 물으면 “x, y, z 해봤는데 안 돼서”라는 답이 있었어요. 그런데 LLM은 ‘요청한 일을 했다’는 이유만으로 복잡한 걸 집어넣습니다.
💡 실제 활용 시나리오 예시:
같은 패턴이 코드베이스에 37번, 조금씩 다르게 반복돼도 ‘작동했으니’ 넘어가는 상황. 이러면 한 부분을 이해해도 옆 모듈에 그 지식을 옮겨 쓸 수 없어요. 실무에서 ‘지식의 이식성’이 떨어진다는 건 유지보수 비용으로 직결됩니다.
4. AI 네이티브 세대는 무엇을 잃는가
원문의 결론은 담담하지만 서늘합니다. “한 번도 맺어본 적 없는 관계는 그리워할 수 없다”는 거예요. 다음 세대는 이걸 상실로 느끼지 않을 겁니다. 모든 걸 해주고 아무것도 요구하지 않는 도구를, 전등 스위치처럼 자연스럽게 쓸 테니까요.
③ 무기력 — 지식 부족보다 무서운 것
실무에서 저도 비슷한 장면을 봅니다. 부팅 USB를 건네받고도 시스템 설정을 못 하는 신입이, 2분 안에 안 되면 “안 되는데 뭘 해야 하죠?”라고 바로 물어보는 거죠. 문제는 지식이 아니라 스스로 부딪혀보는 태도의 부재였어요. AI 의존의 진짜 위험은 여기 있다고 봅니다.
💡 실제 활용 시나리오 예시:
2년 전만 해도 브레이크포인트를 직접 잡고 메모리를 보며 최적화하던 개발자가, 지금은 “메모리 많이 먹는데 찾아봐” 한마디로 끝냅니다. 편하지만, 병목이 왜 생겼는지에 대한 감각은 그만큼 무뎌지죠.
④ 그래도 호기심은 꺼지지 않는다 — 반론도 새겨둘 점
다만 저는 지나친 비관에는 반대합니다. 원문에도 등장하는 ‘인구집단 착각’이라는 반론이 설득력 있거든요. 너드는 언제나 재미로 추상화를 뚫고 들어가고, 웹 브라우저가 커널 개발자를 없애지 못한 것처럼 저수준 지식은 사라지지 않습니다. 오히려 DIY 8비트 컴퓨터, 인디·핸드메이드 개발 신은 취미로 다시 붐을 이루고 있어요.
💡 실제 활용 시나리오 예시:
아이에게 Python을 가르치려고 “The Farmer Was Replaced” 같은 게임을 출발점으로 쓰는 부모가 늘고 있어요. 스스로 실수하고 다시 시도하는 ‘마찰’을 일부러 설계해 넣는 셈이죠. 필요하다면 만들 수 있다는 게 핵심입니다.
5. AI 서비스 개발자로서 나는 이걸 어떻게 보나
저는 모델을 어떻게 학습시키고 발전시키는지 그 안쪽을 보며 커리어를 쌓아왔어요. 그래서 솔직한 감정이 좀 복잡합니다. 지금의 LLM은 구조적으로 너무 뛰어나서, 어떤 면에선 이미 넘사벽이거든요. 그런데 저는 이 발전 과정을 ‘보고 이해하며’ 여기까지 왔는데, 지금 어린 세대는 처음부터 완성된 결과물만 만나게 됩니다.
제가 내린 결론은 하나예요. 도구를 얻되 매체에 대한 이해를 잃지 않은 사람이 결국 가장 좋은 걸 만든다는 것. AI에게 “이거 해”라고만 시키는 사람과, “이게 왜 이렇게 작동하지?”라고 되묻는 사람의 격차는 시간이 갈수록 벌어질 겁니다. LLM은 주의를 빼앗는 도구인 동시에, 가장 저평가된 학습 도구이기도 하니까요.
💡 실제 활용 시나리오 예시:
AI가 짜준 라우팅 규칙을 그대로 붙여넣는 대신, “내 네트워크 토폴로지에서 이 규칙이 왜 필요한지 단계별로 설명해줘”라고 물어보세요. 검증 능력이 붙으면 AI 출력의 오류(낡은 링크, 지어낸 API)를 잡아낼 수 있고, 그게 바로 이 시대의 진짜 경쟁력입니다.
더 깊이 파고들고 싶다면 AI 시대 개발자 역량 완벽 정리: 코드가 싸진 시대, 진짜 살아남는 3가지 능력 글도 함께 읽어보시길 추천해요.
6. 이런 분들께 적극 추천합니다
- AI 코딩 도구를 매일 쓰면서 ‘내 실력이 진짜 늘고 있나’ 불안한 주니어/시니어 개발자
- AI 네이티브 신입을 온보딩하며 시스템 이해도 격차를 체감한 팀 리더
- 자녀에게 프로그래밍을 가르치려는데 어디서 ‘마찰’을 남길지 고민인 부모
- 추상화·결정성·기술 부채 같은 개념을 커리어 관점에서 정리하고 싶은 분
- 1990년대
autoexec.bat과 모뎀 협상음의 향수를 공유하는 올드 게이머 - AI 의존이 개인과 사회에 미칠 영향을 진지하게 고민하는 기획자/PM
7. 자주 묻는 질문 (FAQ)
Q. 그럼 AI 코딩 도구를 쓰지 말라는 건가요?
A. 전혀 아닙니다. 원문 저자도 결국 Tailscale과 LLM 에이전트를 잘 쓰고 있어요. 핵심은 도구를 끊는 게 아니라, 가끔은 “어떻게 작동하는지 알려줘” 모드로 바꿔 스스로 이해하는 근육을 유지하는 겁니다. 도구와 이해는 양자택일이 아니에요.
Q. 저수준 지식이 정말 중요한가요? 어차피 추상화되잖아요.
A. 대부분의 일상 업무에서는 몰라도 됩니다. 자동차 운전에 엔진 원리가 필수는 아닌 것과 같죠. 다만 성능을 쥐어짜거나, AI가 만든 코드의 오류를 잡아내거나, 남들이 못 푸는 문제를 풀 때는 ‘한두 계층 아래’를 아는 사람이 압도적으로 유리합니다.
Q. 다음 세대는 정말 ‘작동 방식’을 모르게 될까요?
A. 평균적으로는 그럴 수 있지만, 개인은 선택할 수 있습니다. 지금도 20세 미만 중에 인상적인 어셈블리를 쓰는 사람이 있고, DIY 하드웨어와 모딩 커뮤니티는 살아 있어요. 호기심은 인센티브를 줄일 순 있어도 완전히 끌 순 없다는 게 저의 낙관입니다. 😊
✍️ 글을 마치며
이 에세이가 말하는 상실은 ‘능력’이 아니라 ‘친숙함’이었어요. 지식은 AI 덕에 그 어느 때보다 안전해졌지만, 기계와 싸우고 실패하며 마침내 작동시키던 그 관계는 조용히 사라지는 중입니다. 얻는 속도만큼 빠르게 무언가를 잃고 있다는 걸, 이 글은 아름답게 포착했다고 생각해요.
저는 앞으로 AI에게 코드를 받을 때마다 “왜 이렇게 했어?”를 한 번씩 되묻는 습관부터 다시 들여볼 생각이에요. 검증하는 근육이 이 시대의 마지막 방어선이라고 믿거든요.
여러분은 어떤 부분이 가장 인상적이셨나요? 댓글로 자유롭게 의견 남겨주세요! 😊