▲

AI에 반대하는 분위기에 휩쓸리지 마세요

 (antirez.com)
1P by GN⁺ 1일전 | ★ favorite | 댓글 2개
  • 최근 대형 언어 모델(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를 활용하면 더 많이, 더 잘 만들 수 있음
▲
m00nlygreat 19시간전  [-]

생각 외로 코드로 해결가능한 문제는 현실에 많지 않습니다. 코드는 꽤 많은 문제를 해결할 수 있지만 대부분의 문제는 코드나 모니터 바깥에 있습니다.

답변달기
▲
GN⁺ 1일전  [-]
Hacker News 의견들

  • 내가 밤새 코드를 짜며 프로젝트가 돌아가는 걸 보던 그 열정은 ‘무언가를 만드는 즐거움’이었음
    사람마다 그 불씨의 형태가 다름. 어떤 이는 “컴퓨터를 내 뜻대로 조종한다”는 감각에서, 또 어떤 이는 “다른 사람의 문제를 해결한다”는 데서, 또 다른 이는 “감정을 불러일으키는 무언가를 만든다”는 데서 동기를 얻음
    나의 경우 처음엔 남의 웹사이트를 망가뜨리고 싶어서 프로그래밍을 시작했지만, 만들고 공유하는 과정이 더 즐거워졌음. 그래서 다른 사람의 피드백을 듣는 게 내 불씨가 되었음
    결국 프로그래머마다 이유가 다르고, 어떤 사람에게는 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분 만져보고 결론 내리지 말고, 몇 주간 실험해보라 함.
    지금 미디어의 대부분은 클릭을 위한 부정적 서사를 팔고 있음. 정확한 판단을 하려면 직접 써보는 수밖에 없음.
    그리고 지금은 긍정적 신호를 더 주의 깊게 봐야 함. “이걸로 이런 걸 해봤다”는 사례가 “아직 이건 안 된다”는 말보다 훨씬 가치 있음

답변달기