▲

AI 코딩

 (geohot.github.io)
1P by GN⁺ 1일전 | ★ favorite | 댓글 1개
  • 프로그래밍용 AI는 기존 컴파일러와 비슷한 역할 구조임
  • 영어 프롬프트는 프로그래밍 언어로서 부정확하고 비효율적 특성 가짐
  • AI의 생산성 향상 효과는 실제로 과장되거나 잘못 인식되는 경향 존재함
  • AI 도구는 개발 과정을 바꾸지만, 진정한 혁신은 더 나은 언어와 툴에서 출현 가능함
  • LLM 도입이 개발자 대체를 의미하지 않으며, 오히려 현 개발 환경의 한계 반영임

AI와 컴파일러의 유사성

  • 필자는 나이가 들면서 더 이상 다른 이들을 설득하려는 시도를 포기함
  • 많은 사람들이 진실에는 관심이 없고, 본인에게 이득을 주는 신념만을 따르는 현상 강조함
  • 'Perception is reality(인식이 곧 현실)'을 주장하는 이들에 대한 비판 제시함
  • 자율주행차에 투자된 수십억 달러가 잘못된 믿음에 의한 낭비임을 지적함
  • AI가 코딩을 할 수 있다고 믿는 시각은, 컴파일러가 코딩을 한다고 생각하는 관점과 유사함

AI 코딩은 컴파일러와 같은 모델

  • 프로그래밍 AI의 최적 모델은 컴파일러라는 주장 설명
  • 사용자는 프롬프트(코드)를 입력하고, 그 결과로 컴파일된 출력을 받게 됨
  • Frprompt를 영어로 입력하는 점에서 차이가 있으나, 영어는 명확성 부족, 명세가 없음 등 여러 단점을 가짐
  • 새로운 일이나 복잡한 작업을 할 때, 결국 프롬프트의 장황함이 증가함
  • AI의 출력은 비결정적이고, 프롬프트의 일부분 변경이 전체 결과에 영향을 미침

AI 코딩에 대한 비판적 시각

  • AI 코딩이 긍정적으로 보이는 이유는 현재 툴, 언어, 라이브러리의 열악함 때문임
  • "AI" 기술로 인해 이전보다 더 좋은 검색, 최적화, 패턴 추출 도구가 가능하게 됨
  • 실제로 코딩이 이루어지는 것은 프로그래머 자신이며, 코드 작성이라는 행위의 언어만 달라진 것임
  • LLM이 개발자를 대체할 수 있는 회사라면 회사 코드베이스와 채용 기준이 매우 낮은 상태임을 의미함
  • AI는 컴파일러나 스프레드시트처럼 점진적으로 일부 업무를 대신할 수 있음

AI는 도구, 궁극적으로 더 나은 언어·라이브러리 필요

  • AI에 대한 도구적 관점에서 많은 생각과 주의가 필요함을 강조함
  • 잘못된 기대 또는 허상에 투자함으로써 수십억 달러의 낭비가 일어나고 있음
  • “vibe coding”과 같은 허위 생산성 툴에 대한 시장의 과잉 반응 언급
  • AI가 실제로 생산성을 20% 높인다는 착각이 있지만, 실제로는 19% 느려진다는 연구(논문) 결과 인용함
  • 진정한 발전은 프로그래밍 언어, 컴파일러, 라이브러리 혁신에서 발생할 수 있음
▲
GN⁺ 1일전  [-]
Hacker News 의견

  • 나는 거의 50살이고, 90년대 후반부터 전문적으로 코드를 작성해옴. 머릿속에 프로젝트가 바로 그려져서 무엇을 만들어야 할지 정확히 알고 있음. 급여도 꽤 높게 받는 편임. 겉으로 보기엔 AI 반대론자의 전형일 것 같지만, 사실 아님. 무엇이든 만들 수 있지만, 온갖 기본 작업에 질릴 때가 많음. 그래서 AI를 활용해 지루한 부분을 빠르게 통과하고 내가 좋아하는 핵심 작업에 집중할 수 있다는 점이 정말 마음에 듦. AI 개발은 주니어와 미드 레벨 사이에 있는 개발자에게 몇 문장으로 생각을 전달해서 한 시간치 작업을 시키는 것과 비슷함. 다만, 실제 주니어가 성장하지 못하게 되어 미래의 시니어 개발자 풀이 줄어드는 점은 진지하게 고민할 문제지만, 이건 별개의 문제임

    • 내가 AI를 써서 지루한 부분을 속전속결로 처리한다고 했는데, 경험 많은 시니어 개발자 중엔 오히려 험난한 부분이 두려워 AI에 부정적인 사람도 있음. 많은 개발자가 지루하고 쉬운 파트에서 심리적 안전함을 찾는데, AI가 도입되면 일 자체가 끊임없는 어려움의 연속이 되어버릴 수 있음. 오랜 경험만 있고 실력은 부족한 시니어라면 연달아 도전적 일을 계속 맡다가는 금방 탈진함. 기업들은 AI를 도입해 무조건 속도만 빠르게 하려고 하는데, 사람에게는 인지적 휴식이 필요하다는 점을 간과함. 너무 힘든 일만 남기면 사람에게 좋지 않음. 물론 반복적이고 쉬운 일에 싫증을 내는 개발자는 AI와 함께 갱생할 수 있음. 결국 개인별로 다르게 접근할 필요가 있음

    • 나도 당신보다 약간 어리지만, 생각은 거의 완전히 같음. 오히려 더 심할 수도 있음. 흥미로운 아이디어를 실현하는 코드를 쓰는 게 아니라, 아이디어 내고 실험하는 것 자체가 재미라고 느끼게 됨. 그래서 코딩은 해야만 해서 했지, 본질적으로 하고 싶은 일은 아님. 내 아이디어를 실현해보고 싶으면 어쩔 수 없이 코드를 써왔음. AI는 브레인스토밍 파트너로서 아주 훌륭함. 아부하지 않도록 요청을 하면, 정말 솔직하게 내가 오버엔지니어링할 때 지적해줌. 디버깅도 정말 잘함. 그래서 컴퓨터에게 말로 설명하며 아키텍처와 방법을 브레인스토밍하고, 스펙을 만든 다음 AI에게 구현을 맡김. 만약 생각이 틀렸으면 AI와 반복적으로 빠르게 개선함. 반복이 너무 빨라서 실수해도 상관없음. 잘못된 설계를 이전에는 코드 전체를 바꿔야 해서 그냥 참고 살았지만, Agentic coding 도구 덕분에 전체 코드베이스 변경도 문제없음. 새로운 기술 분야도 전문가가 아니었지만, AI 덕분에 효과적으로 진입하고 금세 실력을 키웠음. 솔직히 지금이 프로그래머 인생에서 제일 행복함. 도구들은 매주, 때로는 한 주에 여러 번씩 더 좋아지고 있음

    • 내 경험과도 완전히 일치함. 나도 비슷한 연차임. 나는 AI를 개인 작업과 회사 업무에 둘 다 적극적으로 활용함. 첫째, AI는 편견이 덜한 아이디어 상담역할을 해줌. 빠른 피드백 루프와 경로 검증이 정말 필수로 느껴짐. 둘째, 타이핑과 시간을 아껴줌. ‘기본 작업’은 한 번에 시켜서 최소 80%는 완벽하게 처리해줌. 100% 완성은 아니지만, 절약된 시간이 훨씬 커서 절대적으로 이득임. AI를 쓸 때 항상 가드레일을 두고, 지시를 최대한 구체적으로 자세히 전달하고, 항상 작업물을 직접 검토하는 습관이 생기고 있음

    • 10년 정도 덜 경험했지만 비슷한 입장임. 근데 나는 잘 공감이 안 됨. 어떤 파트가 지루해질 때쯤이면 바로 자동화, 일반화하는게 워낙 어렵고 챌린지라서, 실제로 지루한 일이 거의 없게 됨. 오히려 내가 직접 타이핑하는 게 더 빠름. 비중간, 비단순 파트에서 직접 코드를 쓰면서 더 나은 구조나 자동화 아이디어를 떠올림. 덕분에 오히려 넘기고 싶은 코드는 거의 없음. 그리고 이런 생각을 할 수 있었던 건 한 회사에 오래 있었기 때문인 듯. 만약 새로운 코드 작업을 계속해야 했다면 생각이 달랐을 것 같음

    • 나도 50대고 90년대부터 코딩해서 평생 세 번은 넘게 쓸 수 있을 만큼 돈도 많이 벌었음. 30년 경력 동안 최고의 개발자들에게 공통된 특징이 있었는데, 바로 ‘완벽한 게으름’임. 좀 이상할 수 있지만 뛰어난 엔지니어의 공통된 특성이 게으름밖에 없었음. 게으름이 어떻게 생산성으로 이어지는지 신기할 정도임. 이유는 반복 작업을 무조건 자동화하기 때문임. 두 번 같은 걸 한다면 무조건 세 번째 자동화가 필요하다는 철칙을 배움. AI의 등장으로 자동화 수준 자체가 완전히 달라짐. 예전에는 할 수 없던 모든 작업까지 자동화 가능해짐. AI 활용법을 수없이 찾아내고, 나뿐 아니라 게으른 동료들도 정말 잘 활용함. 지금 AI 없이는 일 자체를 상상할 수 없게 됨. ‘마법’이어서가 아니라, 나처럼 게으른 사람이 모든 자동 가능한 작업을 AI가 대신해주기 때문임

  • 이건 Hacker News에서 흔히 보이는 AI 관련 집단사고의 극단적인 예시라고 생각함. Geohot는 99.999% 상위 개발자이지만, 그가 이해 못하는 99.999%의 개발자는 계속 더 기본적인 일을 하고 있음. 전문가 패러독스임. 만약 모두가 전문가 수준이었다면 그들은 전문가가 아니었을 것임. AI처럼 행동하는 개발자들을 많이 봤음. 자신이 만든 코드베이스도 설명하지 못하고, 일관성 있게 관리하지 못함. 마치 항공우주 엔지니어가 킨더 서프라이즈 장난감 만드는 사람에게 유체 시뮬레이션을 모른다고 놀라는 듯함

    • AI에 대해 HN이 부정적이라고 생각해서 놀라움. 내가 보기엔, 댓글이나 인기 글들을 보면 HN 전체가 기술에 아주 낙관적이라고 느낌

    • 자율주행 회사를 창업한 사람이 이런 입장을 보이는 것도 매우 일관성이 없어 보임. 만약 AI 모델이 코드를 못 쓴다면, 운전이라는 훨씬 어려운 일을 대체할 수 있을지 의문임

    • 글 초반에 이미 이 부분에 대한 설명이 나옴. 여러 가지 일반적인 프로그래밍 워크플로우는 워낙 흔하기 때문에 가능한 것이지, 새로운 일을 하려면 언어 수준만큼 상세하게 설명해야 한다는 게 요지임

    • 항공우주 분야에서 일하는데, 여기 엔지니어들도 딱히 더 나은 경우가 아님. 하지만 너무 걱정할 필요는 없음. 회사에서 이런 사람들은 아무런 피해를 주지 않는 자리로 보내고, 대부분 관리직이 됨

    • Geohot가 정말 99.999% 최고의 개발자인지 모르겠음. "프로그래밍 AI의 최적 모델이 바로 컴파일러다. 프롬프트(=코드)를 주면, 컴파일된 코드를 내놓는다. 대부분의 IDE처럼 피드백 주고 인터랙티브하게 쓰는 것보단, 프롬프트 조정→재컴파일이 더 낫다." 이게 진짜 맞는지 의문임

  • 논의의 핵심 중 하나는 “프로그래밍의 종류”를 좀 더 구체적으로 정의할 필요가 있다는 것임. 로봇이 뭔가를 만드는 데에 “로봇이 좋은가, 나쁜가?”라고만 물으면 의미가 없듯, “무엇을 대상으로?”라는 질문이 전제되어야 논의가 발전함

  • 이 글에 대해 여러 가지 문제가 있다고 생각함. 첫째, “AI 코딩은 컴파일러이다”라는 주장인데, 컴파일러는 규격에 따라 언어를 결정적으로 변환하지만 LLM 코딩 도구는 제약(테스트/타입/린터/CI 등) 하에서 반복적으로 코드를 검색, 생성, 수정하는 프로그램 합성기임. 실제로 SWE-bench Verified 같은 대규모 오픈소스 이슈도 엔드-투-엔드로 해결함. 둘째, “프로그래밍 언어는 영어다”라는 주장. 현실은 코드, 테스트, 스펙, API, JSON 스키마, diff, IDE 도구 등 조합이고, 영어는 그저 접착제 역할일 뿐임. 저자는 가장 약한 인터페이스만 쏙 집어서 공격함. 셋째, 비결정성이 문제라는 주장. 현실에서는 fuzzing, SAT/SMT 등에 확률적 요소가 많지만, 최종 결정성과 정확성은 외부 스펙(테스트, 타입시스템, CI 등)에서 옴. 그리고 LLM이 인기 있는 게 언어나 라이브러리가 나빠서라는 건 잘못된 이분법임. 예를 들어 Rust, TypeScript처럼 언어가 좋아져도 LLM은 여전히 API 검색, 레포 트레이싱, 반복 코드 작성, 마이그레이션, 테스트 작성, 리팩터 등에서 도움을 줌. 마지막으로, "더 좋은 언어나 컴파일러를 만들어라"라는 대안만 제시하지만 이미 현대 팀은 AI와의 조합에서 큰 가치를 얻고 있음. 그래서 AI 코딩과 LLM을 "프롬프트로 조작하는 마법 같은 영어-컴파일러"로 무작정 믿는 게 아니라, 나만의 제약(타입, 테스트, CI 등)을 기준으로 도와주는 "주니어 페어 프로그래머"처럼 활용하는 게 훨씬 현실적임

    • (작성자 본인) 이 의견에 동의함. 만약 블로그 글을 이렇게 썼으면 인기가 없었을 것 같음. “LLM 코딩 도구는 탐색 기반 프로그램 합성기”라는 설명은 내 생각으로도 사실상 컴파일러의 정의에 가까움. 다만 대다수 컴파일러는 충분한 탐색을 안 하고 휴리스틱에 많이 의존하는 건, 런타임 통합이 안 돼 있어서 그런 것뿐이라고 생각함. “엔지니어링 도구 중 비결정적인 게 많다”는 건 맞지만, 예를 들면 SAT 솔버에서 무작위성이 도입되어 해결 시간은 달라져도 정답성에는 영향을 주지 않음. 퍼저(fuzzer)는 테스트 목적이라 본질적으로 완벽을 기대하지 않음. 프로덕션에 도입된 퍼저는 본 적 없음. “결정성은 외부 테스트나 스펙에서 온다”는 주장에는 완전 공감함. 내가 꿈꾸는 건 구현 방법이 아니라 동작을 스펙으로만 명시하는 언어임. Halide의 schedule 개념을 더 일반화한 느낌. 컴퓨터가 구현 방법을 알아서 찾는 것임. 이런 도구를 AI가 제공할 수 있다고 봄. 그게 꼭 LLM일 필요는 없고, 엄격한 스펙이 반드시 필요함. 그 자체가 결국 프로그래밍임. 이런 관점에서 AI를 "마법의 영어 컴파일러"로 보는 건 반대함. 도구의 강점과 한계를 인지하며 작업 보조 수단으로 활용하면 정말 좋은 워크플로우임

    • 탁월한 답변임. 전적으로 동의함

    • 이런 문제가 있는 글을 쓴 게 놀랍지 않음. 작성자가 George Hotz, 즉 Geohot임

  • 나는 Openpilot도, claude code도 자주 씀. 두 도구를 거의 동일 선상에 두고 봄. Openpilot은 고속도로 등 단순한 상황에서 수시간 동안 정말 잘 주행함. claude code는 직관적 리팩터, 보일러플레이트, 스캐폴딩, 깃 바이섹트 등 반복적 작업을 내 입력 없이도 해냄. 둘 다 결국 ‘운전자’를 대체하진 못함. claude code는 프로그래밍의 레벨 2 자율주행 같은 존재임

  • METR 연구는 제목 때문에 엄청나게 인기를 끔. 실제로 정독한 사람은 드물 듯—상당히 길었기 때문임. 하지만 데이터에서는 Cursor나 AI 활용 경험이 가장 많은 한 명만 50% 속도 증가가 관찰됨. 익숙해진 뒤에나 성과가 두드러지는 걸 암시함. 또 소규모 샘플에서 통계 변동도 큼. 이후 다른 한 명의 속도차가 잘못 기록된 것으로 정정됐지만, 여전히 결과의 의미를 놓고 의문이 들게 만듦. 연구에서 측정한 비효율 요소들은 개선된 LLM, 병렬 에이전트 등 발전된 기술로 충분히 해소될 수 있는 부분임. 연구 당시 사용된 건 기존 Claude 3.7 시대, Claude Code 이전 시점임. 실제로 20% 덜 일한 듯한 ‘체감’도 충분히 중요한 가치임. 즐겁게 일하면 시간은 금방 감

  • AI 랩들이 지금까지 AI를 너무 과장해서 팔아온 문제임. “AI가 진짜 생각한다, 그냥 패턴 매칭만 하는 게 아니다”라는 구호가 많음. 나는 AI 툴을 만들고 쓰는 입장에서, 오히려 패턴 매칭 기반의 ‘다음 토큰 예측기’로 대한다는 관점이 훨씬 쓸모 있다고 느낌. 문맥에 쓸데없이 정보를 많이 넣으면 AI가 일반화에 실패하는 경우가 많음. 이건 결국 패턴 매칭, 다음 토큰 예측과 동일함. “AI 기술이 오늘날 매우 좋은 도구에 기여할 수 있다”고 생각하지만, 이건 대량의 탐색/최적화와 기존 패턴의 재활용에 의한 결과임. 예를 들면, Claude code에게 단순한 CRUD API를 작성하라고 시키면 1분 만에 나와서 내 시간을 1시간이나 아껴줌. 수십만 번 이미 구현된 알고리즘을 요청하면 곧바로 정확한 코드를 뽑아줌. AI를 자기 전문 영역에서만 쓰면 정말 잘 작동함. 그 외에는 결과가 별로임

    • 이건 지능(intelligence)의 단계 차 문제임. 지식이 아니라, 근본적인 사고력 차이임. 우리는 특정 일에 드는 인지적 노력을 과소평가함. 하지만 때때로 AI가 생각보다 ‘사려 깊은’ 행동을 보여줄 때도 있음. 이럴 땐 정말 마법처럼 느껴짐

    • CRUD나 보일러플레이트는 사실 도구화로도 어느 정도 해결 가능함. 그런데 AI로만 가능한 일도 많음. 예를 들면, 내가 트레이스 레벨 로그 전체를 테스트하며 분석해야 할 때, 수백 줄을 직접 눈으로 보면 엄청 시간이 드는데, AI에게 “테스트 실행하고 원인 찾아줘”라고 하면 충분히 쓸만한 결과가 나옴. 요즘은 이게 늘 첫 단계가 됨

  • 당신 의견에도 일정 부분 진실이 있다고 봄. 하지만 비즈니스 세계는 ‘질서 재편에 대한 열망’이 아주 큼. 수많은 자금이 짧은 기간 강한 수익을 원하고, 펀드 매니저들은 트렌드를 못 쫓으면 잘림. CIO나 CEO도 마찬가지. AI 도입 경쟁은 핵무기 경쟁처럼 이미 멈출 수 없음. 본질적으로는 누구에게도 좋은 일이 아님. 하지만 남들이 다 뛰어들기에 나도 안 할 수 없음. 자동차가 등장하기 전에도 인간은 충분히 행복했음. 하지만 자동차가 오면서 도시가 재편되고, 건물과 건물 사이가 점점 멀어졌고, 통근도 일상이 됨. AI도 마찬가지로 우리가 일하는 맥락 자체를 바꿔버림. 이제 모두가 AI를 써야 한다는 기대가 생기고, 어느 순간엔 ‘기본 필수’처럼 느껴짐. 더 나아가면, 과학기술이 만들어낸 상품 중 진짜 인간의 “필수”였던 것은 거의 없음. 기술이 문제를 만들어놓고 해결책으로 포장하는 것임. 문제는 원래 없었는데, 솔루션이 나오고 나서야 문제가 됨. 이게 바로 비즈니스를 움직이는 핵심 동력임

  • AI 코딩에 관한 오피니언 글 상당수가 아주 경험 많은 소프트웨어 엔지니어, 소위 ‘아이보리 타워’의 시각에서 쓰인 듯함. (해당 연구도 “경험 많은 오픈소스 개발자 16명”만을 대상으로 함) 하지만 비전문가에게는 이런 도구가 엄청나게 가치 있음. 나 역시 약간의 코딩 경험이 있긴 한데, 본업은 아님(시각예술가임). 예전엔 며칠 걸릴 일을 오후 한나절 사이에 끝낼 수 있음. 두 달 전에 일을 그만두고 게임 개발에 집중 중인데, 예산이 넉넉지는 않지만 Claude, ChatGPT는 반드시 유지함. 또 밤 1시에 침대에서 어떤 아이디어를 써보고, 바로 Codex로 던져놓고, 아침에 일어나 실행해보는 게 진짜 마법 같음. 예전엔 “이게 정말 최선의 방법인가?” 하는 걱정 때문에 시작을 망설였지만, 이제는 리팩터가 쉬워서 그런 걱정이 사라짐. 코드를 직접 쓰는 데에서뿐만 아니라, 심리적 장벽을 낮춰주는 효과도 큼. 물론, 비판 대부분은 실제로 이 도구의 마케팅 과장이랑 “이제 엔지니어 다 잘릴 것”이라는 담론에 대한 것임을 이해함

  • 나는 72살이고, 40년간 개발자로 일함. 예전만큼 초집중은 힘들지만 AI 덕분에 여전히 뭔가를 만들고 있음. 내가 프로젝트의 스펙을 짜고 에이전트가 구현, 테스트까지 맡음. 이제는 즐거움으로만 코딩함

    • 나 역시 AI로 시제품을 빠르게 만드는 방식을 좋아함. 예전에 브라우저 확장 기능을 만들고 싶어서 Claude로 10분 만에 간단한 버전을 만들었음. 이후 직접 UI를 조금씩 다듬었고, 주말 아침을 보내며 더 얇고 예측 가능한 고도화된 확장 프로그램을 완성함. 내 확장 프로그램은 반복 응답 목록을 보여주고, 어떤 응답을 localhost API로 넘길지 토글할 수 있음. 거기서 작업 큐 처리가 들어가고, sqlite db 업데이트, LM Studio GPT-OSS 20b로 주요 정보 분석, 마지막엔 텔레그램으로 요약도 전송함. 머릿속 아이디어가 뚜렷하지만 실험이나 PoC 단계가 분 단위로 줄어드는 게 정말 유용함. 나처럼 충분히 역량있는 개발자에게는 이 덕분에 혼자서도 예전보다 더 많은 일을 소화하게 되었음
답변달기