# 자동 프로그래밍 > Clean Markdown view of GeekNews topic #26334. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=26334](https://news.hada.io/topic?id=26334) - GeekNews Markdown: [https://news.hada.io/topic/26334.md](https://news.hada.io/topic/26334.md) - Type: news - Author: [neo](https://news.hada.io/@neo) - Published: 2026-02-02T11:16:02+09:00 - Updated: 2026-02-02T11:16:02+09:00 - Original source: [antirez.com](https://antirez.com/news/159) - Points: 26 - Comments: 1 ## Summary **자동 프로그래밍(Automatic Programming)** 은 AI가 코드를 작성하더라도 **개발자의 비전과 통제**가 중심이 되는 새로운 프로그래밍 패러다임입니다. Redis 창시자 antirez는 이를 단순한 ‘바이브 코딩’과 구분하며, 같은 LLM을 사용하더라도 인간의 **직관과 설계, 지속적인 방향 조정**이 결과의 품질을 결정한다고 강조합니다. 프로그래밍의 자동화가 가속되더라도, **소프트웨어의 핵심 가치**는 여전히 인간이 정의하는 **아이디어와 비전**에 남아 있습니다. ## Topic Body - **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에는 특별한 기술적 신기함이 많지 않음 - 시작 단계에서는 유능한 시스템 프로그래머라면 누구나 작성할 수 있는 **기본 데이터 구조와 네트워킹 코드의 합**에 불과 - 그럼에도 매우 유용한 소프트웨어가 된 이유는 그 안에 담긴 **아이디어와 비전** 때문 ### 결론 - **프로그래밍은 이제 자동화되었지만, 비전은 아직 자동화되지 않음** ## Comments ### Comment 50435 - Author: neo - Created: 2026-02-02T11:17:01+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=46835208) - 업계 경력 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)](https://www.goodreads.com/book/show/15182720-design-by-contr...), [원문 PDF](https://se.inf.ethz.ch/~meyer/publications/old/dbc_chapter.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**”이라 부름