# AI에 반대하는 분위기에 휩쓸리지 마세요 > Clean Markdown view of GeekNews topic #25750. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=25750](https://news.hada.io/topic?id=25750) - GeekNews Markdown: [https://news.hada.io/topic/25750.md](https://news.hada.io/topic/25750.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-01-12T09:42:57+09:00 - Updated: 2026-01-12T09:42:57+09:00 - Original source: [antirez.com](https://antirez.com/news/158) - Points: 9 - Comments: 5 ## Summary 대형 언어 모델의 발전으로 **프로그래밍의 중심이 ‘코드 작성’에서 ‘문제 정의와 설명’으로 이동**하고 있습니다. Redis 창시자 Antirez는 Claude Code를 활용해 UTF-8 지원 추가부터 BERT 임베딩용 C 라이브러리 생성까지, 과거엔 며칠 걸리던 작업을 몇 시간 만에 완성했다고 하면서, 이러한 변화가 **소프트웨어 개발의 민주화**를 앞당기며, 소규모 팀도 대기업 수준의 생산성을 확보할 수 있는 환경을 만들고 있다고 이야기 합니다. 그래서 단순히 AI를 외면하기 보다는 적극적으로 활용해야 한다고 주장합니다. 최근 여러 유명 개발자들이 다 적극적으로 AI를 활용하는 걸 보게 되네요. [DHH 의 AI 에이전트 홍보](https://world.hey.com/dhh/promoting-ai-agents-3ee04945) 나 Linus Torvals가 [Google Antigravity를 이용해 작성했다는 AudioNoise](https://github.com/torvalds/AudioNoise) 처럼요. ## Topic Body - 최근 **대형 언어 모델(LLM)** 이 중간 규모 프로젝트를 거의 **단독으로 완성**할 수 있을 정도로 발전해, **프로그래밍 방식이 근본적으로 변하고 있음** - **코드를 직접 작성하는 행위의 필요성**이 줄고, **무엇을 만들지, 어떻게 설명할지에 대한 사고 능력**이 더 중요한 역량으로 이동 중임 - Redis 창시자 Antirez는 **Claude Code**를 이용해 UTF-8 지원 추가, Redis 테스트 버그 수정, BERT 임베딩용 C 라이브러리 생성, Redis Streams 내부 구조 재현 등 네 가지 작업을 몇 시간 만에 수행 - AI가 **소프트웨어 개발의 민주화**를 촉진하며, 소규모 팀도 대기업과 경쟁할 수 있는 환경을 만들고 있음 - 그러나 **AI 기술의 중앙집중화 위험**과 일자리 감소 문제에 대한 사회적 대응이 필요하며, AI를 외면하지 말고 적극적으로 활용해야 함 --- ### 프로그래밍의 변화와 LLM의 역할 - 최신 **LLM**은 충분한 힌트만 주어도 중간 규모 프로젝트를 거의 독립적으로 완성할 수 있음 - 성공 여부는 프로그래밍 유형과 문제를 명확히 표현하는 능력에 따라 달라짐 - 시스템 프로그래밍처럼 **텍스트로 표현 가능한 작업**일수록 효과가 큼 - 대부분의 프로젝트에서 **직접 코드를 작성하는 것은 비효율적**이며, 이제는 무엇을 만들지와 어떻게 만들지를 이해하는 것이 더 중요함 - 작성자 Antirez는 AI를 이용해 다음 네 가지 작업을 수행함 - **linenoise 라이브러리**에 UTF-8 지원 추가 및 에뮬레이션 터미널 기반 테스트 프레임워크 구축 - 기존에는 테스트 비용 대비 가치가 낮아 포기했던 작업을 AI로 실현 - Redis 테스트의 **타이밍·TCP 데드락 관련 간헐적 실패 문제 해결** — Claude Code가 프로세스 상태를 분석해 버그를 해결 - **BERT 계열 임베딩 모델 추론용 순수 C 라이브러리**를 5분 만에 생성 - PyTorch 대비 15% 느리지만 동일한 결과 제공. 약 700줄 코드 규모 - GTE-small 모델 변환용 Python 도구 포함 - Redis Streams 내부 구조 변경 작업을 **설계 문서만으로 재현** - 검토와 실행 승인 시간을 제외하면 약 20분 내 완료 - 이러한 경험을 통해 **AI가 프로그래밍의 본질을 바꾸고 있음**을 확인함 ### AI와 개발자의 관계 - AI가 코드를 작성하더라도, **개발자의 역할은 사라지지 않음** - 중요한 것은 문제를 정의하고, AI가 생성한 코드를 검토·조정하는 능력 - AI는 **협력자(partner)** 로서 개발 생산성을 극대화함 - AI 기업의 수익성, 주가, CEO 발언 등은 장기적으로 중요하지 않음 - **프로그래밍의 본질적 변화는 되돌릴 수 없는 상태**임 - 본인은 자신이 만든 코드가 LLM 학습에 사용된 것에 대해 **긍정적**으로 평가 - 이를 **지식과 시스템의 민주화** 과정으로 봄 - 오픈소스가 1990년대에 그랬듯, AI도 **소규모 팀의 경쟁력 강화**에 기여할 것으로 봄 ### AI 기술의 민주화와 중앙집중화 우려 - 현재는 **중국 등에서 공개 모델**이 등장하며 일정 수준의 민주화가 이루어지고 있음 - 폐쇄형 연구소의 선도 모델과 비교해도 성능 격차가 크지 않음 - 그러나 이러한 균형이 **영구적이지 않을 수 있음** - AI 기술이 소수 기업에 집중될 가능성에 대해 **우려** 가 있음 - 대규모 신경망은 본질적으로 **놀라운 성능을 발휘**하며, 특정 기업만이 독점할 만큼의 ‘마법’은 존재하지 않음 ### 사회적 영향과 대응 - AI로 인해 **일자리 감소**가 발생할 가능성에 대한 우려는 있음 - 기업이 인력을 줄일지, 더 많은 프로젝트를 추진할지는 불확실 - 일부 산업에서는 인간이 완전히 대체될 위험도 있음 - 이에 따라 **정부의 역할**이 중요함 - 실직자를 지원하고 변화에 대응할 수 있는 정책이 필요 - 해고가 늘수록 **정치적 압력**이 커져 사회적 보호를 요구하는 방향으로 갈 것이라 전망함 ### 개발자에게 주는 조언 - AI를 거부하거나 회피하는 것은 **커리어에 도움이 되지 않음** - 새로운 도구를 **직접 실험하고 장기간 사용**해보는 것이 필요 - 단기 테스트로 결론을 내리지 말고, 몇주 단위의 실험과 함께 지속적으로 시도해야 함 - AI를 통해 **자신의 역량을 확장**할 방법을 찾아야 함 - 코딩의 본질은 ‘작성’이 아니라 **무언가를 만드는 즐거움**이며, AI를 활용하면 **더 많이, 더 잘 만들 수 있음** ## Comments ### Comment 49075 - Author: m00nlygreat - Created: 2026-01-12T15:38:03+09:00 - Points: 3 생각 외로 코드로 해결가능한 문제는 현실에 많지 않습니다. 코드는 꽤 많은 문제를 해결할 수 있지만 대부분의 문제는 코드나 모니터 바깥에 있습니다. ### Comment 49194 - Author: flaxinger - Created: 2026-01-14T11:53:41+09:00 - Points: 2 완고한 불신만큼 절대적 맹신도 잘못됐다 생각해요. 적절히 장단점을 잘 고려해서 쓰는게 중요한데 마냥 FOMO 분위기를 조성하는건 AI 업체의 상술이라고 생각합니다. ### Comment 49053 - Author: neo - Created: 2026-01-12T09:42:57+09:00 - Points: 2 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=46574276) - 내가 밤새 코드를 짜며 프로젝트가 돌아가는 걸 보던 그 **열정**은 ‘무언가를 만드는 즐거움’이었음 사람마다 그 불씨의 형태가 다름. 어떤 이는 “컴퓨터를 내 뜻대로 조종한다”는 감각에서, 또 어떤 이는 “다른 사람의 문제를 해결한다”는 데서, 또 다른 이는 “감정을 불러일으키는 무언가를 만든다”는 데서 동기를 얻음 나의 경우 처음엔 남의 웹사이트를 망가뜨리고 싶어서 프로그래밍을 시작했지만, 만들고 공유하는 과정이 더 즐거워졌음. 그래서 다른 사람의 피드백을 듣는 게 내 불씨가 되었음 결국 프로그래머마다 이유가 다르고, 어떤 사람에게는 LLM이 재미를 더하지만, 어떤 사람에게는 **핵심 재미를 빼앗는 존재**가 됨 - 나에게는 LLM으로 코딩할 때 **몰입 상태(flow)** 가 불가능해짐. 토큰이 출력되길 기다리며 검토하고 수정하는 과정이 너무 힘듦. 직접 코드를 쏟아내며 몰입할 때의 즐거움이 사라짐 - “문자를 직접 입력하는 행위 자체를 좋아하는 프로그래머” 이야기를 듣고, Richard Hamming의 책에 나온 **Symbolic Assembly Program(SAP)** 일화를 떠올렸음. 예전엔 어셈블리를 쓰는 게 ‘진짜 프로그래머’의 상징이었고, 자동화 도구를 쓰는 건 ‘겁쟁이 짓’이라 여겼다는 이야기임 - 처음엔 남의 사이트를 망가뜨리려 했지만 결국 창작의 즐거움을 찾았다니, **나쁜 의도에서 좋은 결과**가 나온 멋진 사례 같음 - 내 피드에는 ‘AI 찬양’이 ‘AI 비판’을 5대1로 압도함. antirez나 simonw 같은 **중도적 시각**이 드물고, 진짜 급진적인 입장은 “AI는 일부에게 점진적이지만 확실한 순이익을 주는 도구”라고 믿는 쪽임 - 문제는 코드 생성이 아니라 **유지보수**임. AI가 만든 코드를 그대로 커밋했다면, 나중에 사람이 수정할 건가? 아니면 AI가 버그를 고쳐줄 걸 믿을 건가? 결국 정리(clean-up)는 누가 할 것인가 하는 문제임 - antirez의 글에 전적으로 동의함. AI는 개발자에게 큰 **이점**을 주고 있으며, 지금은 인터넷 이후 최대의 기술 혁명 한가운데에 있음 다만 그는 AI의 단점이나 반(反)AI 시각의 이유를 분석하지 않았음. 사회적 영향, 특히 **소프트웨어 엔지니어링의 미래**에 대한 우려를 다루지 않은 점이 아쉬움 - 비즈니스 관점에서 보면 **반(反)AI 태도는 자기 발목 잡기**임. 대부분의 경쟁 환경에서는 AI를 활용해 속도를 높이는 게 기업의 이익에 부합함. 지금 LLM을 익혀두면 다음 변화에도 적응하기 쉬움 - “어려운 부분은 없다”고 생각함. 반(反)AI 논리는 진부해졌고, **에이전트형 코딩(agentic coding)** 은 이미 작동하고 있음 - “AI 열차에 올라타지 않으면 뒤처진다”는 말이 이해되지 않음. 아직 내 일에는 큰 도움이 안 되니, 도구가 충분히 좋아질 때 시작해도 늦지 않다고 생각함 - 어떤 일이길래 AI의 도움을 못 받는지 궁금함. API 정보 검색, 비즈니스 로직 설계 검토, 코드 리뷰 등 **AI의 활용 범위**는 매우 넓음. Antirez도 Redis 코드에서 AI로 버그를 찾음 - “몇 주면 따라잡을 수 있다”는 생각은 착각임. 나는 ChatGPT 출시 이후 매일 LLM으로 코드를 다뤄왔고, **직관(intuition)** 을 쌓는 데 몇 달, 몇 년이 걸림. 지금 시작하지 않으면 뒤처질 위험이 큼 - 나도 예전엔 느긋했지만, 이제는 **변화에 빨리 뛰어드는 게 현명**하다고 느낌. 최근 도구들은 3년 전과 완전히 다르고, 멀티 에이전트 오케스트레이션 같은 개념까지 등장함 - 반대로, 도구와 워크플로우가 계속 바뀌는 지금은 ‘뒤처질’ 걱정이 크지 않음. 안정화될 때까지는 **큰 그림만 파악**하는 게 현명함. Palm Pilot의 Graffiti처럼 금세 사라질 기술에 매달릴 필요 없음 - AI 도구에 익숙해지라는 말은 **지평선 효과(horizon effect)** 에 빠진 것 같음. 기술은 계속 변할 것이고, 진짜 필요한 건 **커뮤니케이션 능력**임. 프로젝트의 핵심을 빠르고 명확히 표현할 수 있는 사람이 유리해질 것임 - “반(反)AI 열풍”이라는 표현은 지나치게 단순화된 시각임. 기술적으로는 아직 거칠지만 **유용성은 분명**하고 사라지지 않을 것임 다만 비즈니스 측면에서는 수익 모델이 불분명함. 기술은 남겠지만, 이를 기반으로 한 **스타트업의 붕괴**가 예상됨 5년 후에도 AI는 더 많이 쓰이겠지만, 지금 존재하는 AI 회사 대부분은 사라질 것 같음 - 2000년대 후반에도 “인터넷에서 돈 내는 사람은 없다”는 말이 있었음. 기업이 개발자에게는 수십만 달러를 쓰면서 AI 도구에는 몇 백 달러만 쓰려는 건 **불균형**임 - 블로그 글 제목은 단순히 **AI 열풍을 풍자**한 농담임 - YouTube, Instagram, WhatsApp 인수 당시에도 “돈 낭비”라 했지만, 지금은 **탁월한 결정**으로 평가됨 - 하지만 HN에는 여전히 “LLM은 쓸모없는 쓰레기 생성기”라는 불만이 많음. 불과 6개월 전보다 줄었지만 여전히 존재함 - “AI가 프로그래밍을 영원히 바꿀 것” vs “그냥 머리로 생각하라”는 **끝없는 논쟁**이 있음. 나는 후자 쪽을 선호함. AI의 장점을 말하는 것만으로는 문제를 해결하지 못함 - 엔지니어의 핵심은 시스템의 **이해와 정확성**임. LLM이 작성한 코드를 깊이 검토하지 않으면 목표를 달성할 수 없음 - 사실 전쟁은 없음. 인터넷이 **논쟁적인 이야기만 부각**시킬 뿐임. 대부분의 사용자는 AI의 이점을 인식하면서도 여전히 사고와 리뷰가 필수임을 알고 있음 - 세상에 영원한 전쟁은 없음. “그냥 X를 써라”는 접근은 결국 사라짐 - “최신 LLM이 중간 규모 프로젝트를 거의 혼자 완성한다”는 말은 **과장**임. 도메인 지식이 있는 사람이 구체적인 명세를 주면 생산성이 크게 오르지만, 결과물의 품질은 여전히 사용자의 지식 수준을 반영함 좋은 트랙터를 줘도 **농부의 실력**이 중요하다는 비유가 맞음 - 누군가 8000개 이상의 테스트를 복사해 붙여서 완전한 HTML 파서를 만든 사례가 있음. 그 정도의 힌트라면 가능함 - “대형 프로젝트”의 정의가 모호함. 이미 수많은 GitHub 레포가 있는 영역과 미지의 영역은 전혀 다름 - 만약 이게 10년 이상 경력자에게만 효과적이라면, 오히려 **반(反)AI 주장**처럼 들림. AI는 누구나 쉽게 쓸 수 있다는 약속이 핵심이었으니까 - 나도 그렇게 봄. LLM은 **생산성 배율기**일 뿐, 입력의 질에 따라 결과가 달라짐. 구체적인 기술 명세로 이끌면 마법처럼 작동함 - 개발 도구가 점점 **추상화**될수록 개발자의 영향력과 보상은 오히려 커져왔음. LLM도 그 연장선임 추상화는 일을 쉽게 하지만, 그만큼 더 많은 일을 할 수 있게 하고, 새로운 복잡성이 생김. 결국 **신뢰와 영향력**이 중요해짐. 그래서 CEO가 직원보다 훨씬 많은 보상을 받는 것임 LLM은 개발자의 **힘과 영향력**을 더 키워줄 것임 - 하지만 어떤 이는 LLM을 “신입 인턴”처럼 봄. 즉, 직접 만드는 대신 **지시하고 관리하는 일**로 변함. 경영진이 AI를 찬양하는 이유도 여기에 있음. 프로그래밍을 관리 업무로 바꾸고, ‘프로그래머’라는 직군 자체를 줄이는 방향임 결국 예전처럼 “위로 올라가거나(out) 사라지거나”의 시대가 다시 올 것임. 사람을 다루는 기술과 비즈니스 감각을 익히지 않으면 점점 **무의미한 존재**가 될 위험이 있음 - “Look ma, no hands”식의 **AI 과신**에 빠지지 말아야 함. Antirez + LLM + CFO 조합이면 억달러짜리 Redis 회사를 만들 수도 있겠지만, 그건 그가 Redis를 **완벽히 이해**하고 있기 때문임. 만약 Postgres처럼 낯선 코드베이스라면 같은 성과를 내기 어렵고, 대부분의 개발자는 그런 낯선 환경에서 일함. 결국 LLM의 진짜 가치는 **도메인 전문가**에게 있고, 조직이 AI를 제대로 활용하려면 **직원 교육과 학습 투자**가 필수임 - 블로그 글도 같은 맥락임. 출력의 품질은 **힌트의 품질**, 즉 사용자의 이해 수준에 달려 있음 - AI는 결국 **고급 자동완성**임. 원하는 결과를 상상하고, 맞는 출력을 알아볼 수 있어야 함. 그래서 LLM으로 배우는 건 위험함. 검색엔진은 좋은 자료를 구분할 수 있지만, LLM은 그 **판별 신호**가 부족함 - LLM은 코드 작성뿐 아니라 **이해 과정**도 돕는다고 생각함. “이제 흥미로운 건 코드를 쓰는 게 아니라, 무엇을 어떻게 할지 이해하는 것”이라는 antirez의 말에 공감함 - 많은 경영진이 AI로 미래를 예측하려 하지만, 실제로는 **현장 엔지니어**들이 여전히 프로덕션 코드를 다루고 있음 - “도메인 전문가”의 의미도 변하고 있음. 나는 컴퓨터 비전 분야에 경험이 없었지만, **시각적 피드백 루프**를 통해 빠르게 학습했음. 테스트 이미지를 LLM에 업로드해 대화하며 문제를 해결함 이런 식으로 검증 체계를 잘 세우면, 낯선 분야에서도 성과를 낼 수 있음. 결국 필요한 건 **직관, 비판적 사고, 과학적 사고방식**임 - “LLM이 내 코드를 학습했다는 사실이 기쁘다”는 말엔 동의하지 않음. 나는 그렇지 않음. 오히려 **소프트웨어 품질이 떨어지고 있음**, LLM이 더 나은 코드를 만든다고 생각하지 않음 - “AI를 거부한다고 세상을 멈출 수는 없다”는 말에 공감함. 나도 친구들에게 “**직접 써보고 판단하라**”고 조언함. 5분 만져보고 결론 내리지 말고, 몇 주간 실험해보라 함. 지금 미디어의 대부분은 클릭을 위한 **부정적 서사**를 팔고 있음. 정확한 판단을 하려면 직접 써보는 수밖에 없음. 그리고 지금은 **긍정적 신호**를 더 주의 깊게 봐야 함. “이걸로 이런 걸 해봤다”는 사례가 “아직 이건 안 된다”는 말보다 훨씬 가치 있음 ### Comment 49135 - Author: parkindani - Created: 2026-01-13T10:56:25+09:00 - Points: 1 - Parent comment: 49053 - Depth: 1 아직도 AI 를 안 쓰면서 쓰레기 코드만 생산한다고 하는 개발자들이 꽤 많나 보군요. 신기하네요... ### Comment 49147 - Author: dbs0829 - Created: 2026-01-13T13:08:56+09:00 - Points: 1 한편으로는 문제점에 대해서 지적하는 목소리도 무시해서는 안된다고 생각합니다. 약간의 비판 조차도 그냥 비난 같은 걸로 치부될때도 꽤나 많다고 느껴져요.