▲

자동 프로그래밍

 (antirez.com)
14P by neo 20시간전 | ★ favorite | 댓글 1개
  • AI 보조를 활용한 소프트웨어 작성 과정을 antirez는 ‘Automatic Programming’이라 정의하며, 이는 곧 소프트웨어 작성의 표준이 될 것으로 전망
  • 같은 LLM을 사용해도 인간의 직관, 설계, 지속적인 방향 조정에 따라 결과물이 크게 달라짐
  • Vibe coding은 큰 이해 없이 AI에 맡기는 방식이지만, 자동 프로그래밍은 개발자의 명확한 비전과 통제를 전제로 함
  • AI가 생성한 코드 역시 인간이 축적한 사전 학습 데이터와 판단을 바탕으로 하며, 결과물의 소유권은 개발자에게 있음
  • 프로그래밍은 점점 자동화되지만, 아이디어와 비전은 여전히 인간의 영역으로 남아 있음

Automatic Programming 개념 정의

  • AI 지원으로 소프트웨어를 작성하는 과정을 자동 프로그래밍(Automatic Programming) 이라 명명함
  • 이 방식이 곧 소프트웨어 작성의 표준 프로세스가 될 것

바이브 코딩과의 차이

  • 바이브 코딩(Vibe Coding) 은 과정에 전혀 참여하지 않고 AI로 소프트웨어를 생성하는 방식
    • 원하는 것을 매우 일반적인 용어로 설명하면 LLM이 학습 데이터와 해당 실행의 특정 샘플링에 따라 자연스럽게 떠오르는 첫 번째 아이디어/설계/코드를 생성
    • 바이브 코더는 기껏해야 작동하지 않거나 기대와 다른 부분을 보고하는 정도
  • 자동 프로그래밍은 고품질을 추구하며 생산자의 소프트웨어 비전을 엄격히 따르는 방식
    • 이 비전은 다층적: 특정 작업을 정확히 어떻게 할지부터, 특정 함수를 어떻게 작성할지 AI에게 직접 지시하는 것까지 포함
    • 무엇을 할 것인가도 핵심 요소

인간 요소의 중요성

  • 같은 LLM이라도 과정을 이끄는 인간의 직관, 설계, 지속적인 방향 조정, 소프트웨어에 대한 아이디어에 따라 결과가 크게 달라짐
  • "Claude가 이 소프트웨어를 바이브 코딩해줬다"는 표현은 적절하지 않음
  • 무슨 일이 일어나고 있는지 알면서 실제 소프트웨어를 생산하는 과정이라면, 그것은 본인이 생산하는 소프트웨어

코드 소유권에 대한 관점

  • 사전 학습 데이터는 LLM이 학습하는 유일한 부분은 아니지만(RL도 큰 비중) 인간이 생산한 것
    • 따라서 다른 무언가를 전용하는 것이 아님
  • AI 생성 코드를 "우리 것"이라 할 수 있으며, 그렇게 할 권리가 있음
  • 사전 학습은 많은 개인이 혼자서는 절대 할 수 없는 일을 할 수 있게 해주는 집단적 선물
    • 마치 어떤 방식으로 집단 정신으로 연결된 것과 유사
  • 자동 프로그래밍으로 생성한 코드는 본인의 코드, 본인의 산출물, 본인의 생산물이며 자부심을 가져도 됨

Redis 사례

  • Redis에는 특별한 기술적 신기함이 많지 않음
    • 시작 단계에서는 유능한 시스템 프로그래머라면 누구나 작성할 수 있는 기본 데이터 구조와 네트워킹 코드의 합에 불과
  • 그럼에도 매우 유용한 소프트웨어가 된 이유는 그 안에 담긴 아이디어와 비전 때문

결론

  • 프로그래밍은 이제 자동화되었지만, 비전은 아직 자동화되지 않음
▲
GN⁺ 20시간전  [-]
Hacker News 의견들

  • 업계 경력 30년 이상으로, 최근에는 명세 기반 개발(spec-driven development) 에 깊이 빠져 있음
    Claude Code와 GPT-5.2(CoPilot)를 활용해 요구사항을 생성하고, 여러 차례 자체 리뷰(self-review) 를 반복하며 명세를 다듬음
    완성된 명세로부터 Claude Code가 구현 계획과 코드를 작성하면, 20분 내 주요 기능이 완성됨
    과거 방위산업 시절의 워터폴 방식을 떠올리게 하지만, AI 덕분에 훨씬 빠르고 정제된 “** 증강된 폭포수(augmented cascade)**” 접근이 가능해졌다고 느낌

    • 워터폴이 잘 작동하려면 장기적 관점과 명세 작성자와 개발자가 동일해야 함
      애자일은 이런 조건이 불가능한 회사들이 생존을 위해 빠르게 제품을 내놓기 위한 대응이었음
    • 나도 프로그래밍의 미래가 명세 중심이 될 거라 생각함
      혹시 참고할 만한 공개 명세(spec) 사례가 있는지 궁금함. 과거 세대가 John Carmack의 Quake 코드를 존경했듯, 다음 세대는 훌륭한 명세를 찬양할 것 같음
    • 아무리 정교한 명세라도 현실과의 충돌을 피하기 어려움
      인간은 모든 복잡성과 예외 상황을 예측할 수 없기 때문임. 실제로 만들어보면 “이건 생각 못 했네” 하는 부분이 반드시 생김
    • 애자일은 요구사항이 변하는 환경에서 점진적으로 올바른 방향을 찾아가는 방법임
      이미 요구사항이 명확하다면 굳이 필요하지 않음
    • 이 접근은 결국 Design by Contract 개념의 현대적 변형 같음
      다만 하위 팀 대신 LLM을 활용한다는 점이 다름
      관련 참고 자료: Design by Contract (Goodreads), 원문 PDF

  • “사전 학습(pre-training)은 인류의 집단적 선물”이라는 표현에 동의하지 않음
    도둑질된 것이라면 선물이 아님
    LLM이 생성한 코드라도 내가 책임지고 관리한다면 그건 내 코드라고 생각함
    문제는 작성자가 책임을 회피할 때 생김

    • “도둑질된 선물”이라는 표현에 본능적으로 거부감이 들었음
    • 지식은 훔칠 수 없는 것임. 수학을 훔쳤다고 말하지 않듯, 지식의 공유 자체가 인간 발전의 본질이라 생각함

  • Claude Code와 Opus 4.5를 써보며 나도 비슷한 결론에 도달했음
    나는 이를 “젠 코딩(zen coding)” 이라 부름. 코드베이스를 선(禪) 정원처럼 다루며, 명세를 세밀히 설계하고 한 줄씩 리뷰함
    AI는 설계자가 아니라 도구로서 동작해야 함
    명확한 명세를 가진 사람은 AI로부터 훨씬 높은 품질의 코드를 얻을 수 있음
    Vibe coding은 직관적 실험이고, Zen coding은 장인의 수련임

  • “Claude가 줬다”는 식의 표현을 들으면 아직 초안 느낌의 코드일 거라는 예감이 듦
    도구를 탓하거나 사과하지 말고, 결과물을 더 좋게 만들면 됨

    • 문제는 이제 아키텍처나 코드 품질을 신경 쓰지 않아도 꽤 멀리 갈 수 있게 된 점임
    • 그렇기에 오히려 기대치를 높이고, 자동화로 vibe-coded 앱의 품질을 끌어올려야 함

  • “사전 학습은 인류의 선물”이라는 표현이 불편함
    많은 오픈소스 개발자들이 자신의 코드가 LLM 학습에 쓰이길 원치 않았음
    LLM이 생성한 코드 중 일부는 내가 본 책이나 블로그의 코드를 거의 그대로 베낀 경우도 있었음
    최소한 출처를 밝히는 게 도의라고 생각함

    • 모든 개발은 선행자의 어깨 위에 서 있는 것임. 완전한 독립 창작은 없음
    • 오픈소스 라이선스와 공개 도메인은 법적으로 다름
      GPL 코드로 LLM을 학습시켰다면, 그 결과물도 GPL로 공개해야 한다는 해석이 가능함
    • 창작자의 의사와 상관없이 작품이 사용된 사례는 역사적으로 많음
      예를 들어 카프카는 자신의 원고를 불태워 달라 했지만, 지금은 문학의 고전이 되었음
    • “퀵소트 구현할 때 Hoare에게 크레딧을 주냐?”는 반문도 있음
    • 지식재산권도 절대적인 것이 아니며, 필요하면 사회적으로 수용(expropriation) 될 수 있음

  • 1950~60년대의 “자동 프로그래밍”은 사실 컴파일러를 의미했음
    1980년대의 4GL은 도메인 특화 고수준 언어였고, 지금의 LLM은 자연어 명세로부터 초안을 생성하는 단계임
    결국 인간은 여전히 반복적 수정과 설계 변경을 통해 완성도를 높여야 함

  • 지금은 장인급 개발자(artisanal coder) 의 마지막 세대를 보고 있는지도 모름
    Antirez 같은 장인은 인간의 한계를 넘어선 개념들을 다루며, Redis처럼 단순하면서도 아름다운 소프트웨어를 만들어냄
    AI는 인간이 할 수 없는 속도로 코드를 만들지만, 그건 붓과 캔버스가 아님
    새로운 세대는 완전히 다른 방식의 장인이 될 것임
    나 역시 두렵지만, 이 새로운 도구들을 받아들이며 새로운 공예의 시대를 실험하고 있음

    • 체스도 인간이 컴퓨터를 이길 수 없지만 여전히 인기가 많음
    • Antirez는 이제 AI 인플루언서에 가깝지만, 여전히 코딩은 즐거운 행위임
    • LLM이 코드를 도와주더라도, 여전히 기초 개념과 구조 이해는 필수임
      AI를 잘 다루는 능력이 추가될 뿐, 기존 지식이 불필요해지진 않음

  • Antirez의 글에서 “vibe coding과 automatic programming의 차이”를 명확히 구분한 점이 인상적이었음
    이는 건축가가 손으로 도면을 그리던 시대에서 BIM, CAD로 전환된 것과 비슷한 변화임
    AI 시대의 개발자는 덜 코딩하는 게 아니라, 가치의 초점이 바뀐 것임

  • “vibe coding vs automatic coding”은 이분법이 아닌 스펙트럼임
    한 프로젝트 안에서도 여러 단계의 접근을 혼합할 수 있음

    • LLM의 출력은 사용자의 기술 수준과 의도에 따라 달라지므로, 결과물은 결국 사용자에게 귀속됨
      중요한 건 도구를 비판적으로 활용하고 지속적으로 개선하는 태도임
    • AI는 다양한 방식으로 연주할 수 있는 악기와 같음
      어떤 이는 이를 “spec strumming”이라 부름
답변달기