# 바이브 코딩할 거면 C로 하지 그래요? > Clean Markdown view of GeekNews topic #24973. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=24973](https://news.hada.io/topic?id=24973) - GeekNews Markdown: [https://news.hada.io/topic/24973.md](https://news.hada.io/topic/24973.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2025-12-10T16:33:27+09:00 - Updated: 2025-12-10T16:33:27+09:00 - Original source: [stephenramsay.net](https://stephenramsay.net/posts/vibe-coding.html) - Points: 14 - Comments: 4 ## Summary **바이브 코딩**은 AI가 코드를 대신 작성해 인간이 결과를 완전히 이해하지 못한 채 작동하는 프로그램을 얻게 되는 방식을 뜻합니다. 글쓴이는 이를 인간의 창의적 성취감을 빼앗는 행위로 보면서도, AI가 이미 **견고하고 복잡한 시스템을 스스로 구성할 능력**을 보여주고 있다고 지적합니다. 모든 언어가 인간 중심으로 설계된 지금, 그는 AI가 이해하기 쉬운 **‘바이브 지향 프로그래밍 언어(VOPL)’** 의 필요성을 제안하며, 이는 소프트웨어 개발 패러다임의 근본적 전환을 예고한다고 주장합니다. 워딩이 좀 강하긴 하지만, 나름 흥미롭네요. ## Topic Body - **바이브 코딩이 실제로 잘 작동하지만**, 작성자가 스스로 이해하지 못한 코드가 만들어진다는 점에서 **프로그래밍의 본질적 즐거움**이 줄어듦 - 모든 프로그래밍 언어는 **기계가 아니라 인간의 편의를 위해 설계된 도구**이며, 안전성·추상화·가독성 같은 장점도 결국 인간이 사고하기 위한 구조 - 그렇다면 **AI가 작성하는 코드에 인간 친화적 언어가 꼭 필요할까?**, 기계 친화적이고 AI 중심의 새로운 언어인 **VOPL(Vibe-Oriented Programming Language)** 를 제안 - 이 언어는 실행 가능한 의사코드, 문학적 프로그래밍의 확장, 혹은 자연어 기반의 특정 문법을 갖춘 형태 등 다양한 가능성을 포함 - 저장 프로그램 컴퓨터 초기처럼, **새로운 계산 패러다임에 대한 저항은 반복되는 역사**이며, 바이브 코딩 역시 그 흐름의 다음 단계일 수도 --- ### 프로그래밍과 바이브 코딩의 긴장 - 프로그래밍은 나에게 **일이 아닌 즐거움**으로, 1990년대 후반부터 지속된 열정의 대상임 - 25년간 프로그래밍을 가르쳐 왔으며, **비전공자를 프로그래머로 바꾸는 일**을 가장 자랑스러워함 - 프로그래밍 할 때 **문제 해결 과정에서 스스로 이해하는 즐거움**을 중요하게 여김 - 반면 **바이브 코딩(vibe coding)** 은 AI가 코드를 대신 작성하는 과정으로, 작성자가 결과를 완전히 이해하지 못하는 상태를 초래함 - “치팅(물론 그런 것도 있지만)” 하는 것 같기도 하지만, 정확하기 표현하기 어려운 방식으로 찝찝한 기분을 들게함 - **코딩 자체의 재미를 많이 앗아가는 것**같음 - 그럼에도 바이브 코딩은 **높은 품질의 실제 시스템을 만들어낼 만큼 잘 작동함** - 검색 대체 수준을 넘어, 직접 해결하기 귀찮은 문제도 정확히 해결함 - **AI가 인간보다 오류 추적과 메모리 관리에 능숙**하며, 프로그램 아이디어를 AI에게 던졌을 때 만들어지는 결과에 놀라움이 반복됨 ### 언어는 원래 인간을 위한 도구 - Abelson & Sussman의 Structure and Interpretation of Computer Programs 에서처럼 **프로그래밍 언어는 인간을 위한 표현 수단**임 - 코드는 “사람이 읽기 위한 것”이며, 기계는 가독성을 필요로 하지 않음 - 모든 프로그래밍 언어는 **인간의 사고와 표현을 돕기 위한 매체**로 설계됨 - Rust의 안전성, C++의 추상화, Go의 동시성 등은 **기계가 아닌 인간의 편의를 위한 기능**임 - 메모리 관리·동시성·타입 안정성 등은 인간의 사고 구조를 돕기 위한 추상화 일뿐 - 따라서 **AI가 코드를 작성하는 시대**에는 인간 중심의 언어 설계가 불필요해질 수 있음 ### 그렇다면 AI에게 이런 언어가 필요한가? : “C로 바이브 코딩하라”는 제안의 의미 - 바이브 코딩 시 인간은 이미 **코드 전체를 온전히 이해하지 못하는 상태**에서 프로그램을 작성함 - 이런 상황에서는 인간 친화적 문법을 유지하는 이유가 약해짐 - 인간 친화적 언어 대신, **기계 친화적 언어(C나 어셈블리)** 로 직접 작성하는 것이 더 합리적일 수 있음 - AI는 C의 undefined behavior, 메모리 해제, 오프바이원 등을 **인간보다 정교하게 관리**할 수 있음 - 컴파일러가 최적화를 더 잘하는 것 처럼, 인간보다 **정확한 코드 실행 관리 능력**을 보임 - 그렇다면 질문: **AI가 사용하기 더 적합한 언어가 필요하지 않을까?** - 왜 굳이 Python·Rust·C++ 같은 “인간 중심” 언어로 바이브 코딩을 해야 하는가? ### VOPL(Vibe-Oriented Programming Language) 제안 - 바이브 코딩을 전제로 한 언어라면 다음과 같은 가능성을 상상해 볼 수 있음 - **실행 가능한 의사코드**에 가까운 **초고수준 언어** - 문학적 프로그래밍의 완전체처럼, **인간은 서술만 하고 AI가 기계 코드를 생성** - 자연어처럼 보이지만 특정 “관용 표현”을 가진 구조 - “goroutine” 대신 **일상 용어 기반의 동시성 표현(slang)** 같은 개념 - AI가 문제를 정확히 이해하고 빠르게 실행 코드를 생성할 수 있도록 **기계 중심의 표현 체계**를 설계하는 방향 - 새로운 언어를 AI에 학습시키는 문제는 존재하지만, 현재 이미 많은 개발자가 AI에게 의사코드를 던져 대화하듯 코드를 만들고 있어 **어떤 형태의 VOPL이 이미 학습되고 있을 가능성도 있음** ### 프로그래밍이라는 행위의 변화 - “손으로 코딩하는 것”이 미래의 바이브 코더 교육에서 **몬테소리식 기초 교육처럼 취급될 가능성**도 있음 - 포토샵 이전의 손그림 훈련이나, 종이에 등식을 풀어보는 훈련이 전자 계산기의 시대에도 교육 과정으로 남아 있는 것처럼 - 새로운 패러다임 도래에 대한 저항은 역사적으로 반복되었음 - 저장 프로그램 컴퓨터 도입 초기의 반발 사례(ENIAC → EDVAC) - **Grace Hopper조차 “기계가 기계의 명령을 작성할 수 없다”는 비판에 맞서 싸웠던 역사**가 있음 ### 결론적 메시지 - 바이브 코딩은 이미 현실이며, 미래의 개발은 **언어 자체의 재설계**를 요구할 수 있음 - 인간 중심 언어의 시대에서, **AI 중심 언어로의 전환 가능성**이 진지하게 논의될 시점임 > “Same vibe, as the kids say.” — 요즘 말로 하자면, 같은 바이브죠 ## Comments ### Comment 47637 - Author: youknowone - Created: 2025-12-12T10:28:40+09:00 - Points: 1 언어모델로 코딩하면서 기계에 가까운 표현을 알아서 마법처럼 만들어줄거라 믿다니 도둑놈 심보네요 제약이 걸려 있을수록 제약 안에서 일을 잘 합니다 ### Comment 47622 - Author: aer0700 - Created: 2025-12-12T05:19:09+09:00 - Points: 1 ai가 코드를 작성하더라도, 서비스에 대한 책임은 개발자가 져야 할텐데요. 본인이 이해할 수 없는 코드에 대해 책임을 질 수 있을지 싶습니다. ### Comment 47579 - Author: dooboo - Created: 2025-12-11T13:00:11+09:00 - Points: 1 "vibe coding을 하더라도, 결과를 검토할 수 있으려면 잘 아는 언어로 해야 함" 댓글에 아주 중요한 문장이 있네요. ### Comment 47524 - Author: neo - Created: 2025-12-10T16:33:27+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=46207505) - 소프트웨어 개발 직군이 정말 **다양함**을 새삼 느꼈음 나는 백엔드, 특히 API 개발을 하는데, 생산성의 가장 큰 병목은 대부분의 사람들이 요구사항을 제대로 **정의하지 못함**에 있음 PM에게 물어보면 회피하고, 프론트엔드 개발자는 백엔드가 API를 주길 기다림 결국 가장 어려운 건 코딩이 아니라 요구사항을 **발견하고 해석하는 사고 과정**임 - 네가 겪는 어려움은 프로그래밍 자체의 문제가 아니라 **비효율적인 조직 구조** 때문임 진짜 프로그래밍은 자신이 설계한 시스템을 구현해 생명을 불어넣는 행위임 단순히 회사에서 코드를 쓰는 일을 ‘Programming’이라 착각하면 오해가 생김 - 나는 인문학 전공 학생들에게 프로그래밍을 가르치는 **영문학 교수**인데, 글쓴이의 경력은 매우 흥미로움 다만 대규모 상용 소프트웨어 개발 경험은 많지 않을 듯함 그가 말하는 “프로그래밍의 미래” 예측은 멋지지만, 산업적 맥락에서는 다소 한계가 있을 수 있음 (참고: [Stephen Ramsay 소개](https://stephenramsay.net/about/)) - 나는 백엔드, 프론트엔드, 풀스택, QA 자동화, DevOps까지 다 해봤음 결국 중요한 건 **마인드셋**과 얼마나 기술에 노출되어 있는가임 LLM이 내 생산성을 크게 높여줌 — 특히 **아키텍처적 사고방식**을 가진 나에게는 예전엔 몇 달 걸리던 걸 몇 시간 만에 만들어냄 요즘은 LLM으로 오래된 Shockwave Lingo 코드를 현대 언어로 번역해 **레거시 게임을 복원** 중임 - 만약 AI가 스스로 **요구사항을 정의할 만큼 똑똑하다면**, 그 시점엔 vibe coding 자체가 불필요해짐 결국 vibe coding이 미래라면, 그건 AI가 완전하지 않다는 전제를 포함함 상상 속 AI의 능력과 한계를 임의로 설정하는 순간, 논의 자체가 모호해짐 - Jira 티켓을 LLM에 넘길 수 없을 정도로 **요구사항이 모호함** 이해관계자들과 네다섯 번은 회의해야 명확해짐 - C로 **vibe coding**을 해봤는데, 여전히 C는 싫음 AI가 사람처럼 메모리 해제를 깜빡하고 나중에 수정함 Rust로 할 때는 훨씬 즐거웠고, 언어의 **의존성 생태계**를 이해하는 게 진짜 실력임 AI는 이런 ‘책 지식’을 빠르게 탐색하는 데 도움을 줌 - Rust 코드 리뷰가 훨씬 **명확함** C에서는 메모리 해제 여부를 일일이 확인해야 했지만, Rust는 그런 걱정이 거의 없음 vibe coding을 하더라도 언어의 **안전 장치**가 있는 Rust가 훨씬 낫다고 생각함 - AI가 Python과 JavaScript는 잘 쓰지만 C/C++은 여전히 **인간처럼 실수**함 Python의 인간 친화적 기능들이 AI에게도 도움이 됨 이제는 AI 덕분에 직접 UI나 유틸리티를 새로 만드는 게 더 쉬워졌고, **C++로 성능 구간만 구현**하는 것도 간단해짐 - 나도 C로 vibe coding을 해봤는데, AI가 **메모리 관리**를 꽤 잘 처리함 GDB로 직접 디버깅했으면 훨씬 오래 걸렸을 것임 문자열 처리나 포인터 관리 같은 불쾌한 부분을 대신해줘서 만족스러움 - 요즘은 어셈블리를 공부하면서 AI에게 같은 문제를 풀게 해 비교함 컴파일러가 생성한 코드가 항상 더 효율적이지만, AI의 실수를 **학습 기회**로 삼고 있음 - 직접 **에이전트를 만드는 법**을 배우길 추천함 로컬 LLM으로도 메모리 해제 같은 검증을 자동화할 수 있음 - 최근 “Why AI Needs Hard Rules, Not Vibe Checks”라는 토론이 있었음 ([링크](https://news.ycombinator.com/item?id=46152838)) Rust가 vibe coding에 적합한 이유는 **타입과 생명주기 보장** 같은 무료 검증 기능 덕분임 이런 검증이 없으면 LLM이 **불안전한 코드**를 쉽게 만들어냄 추상화는 인간뿐 아니라 LLM에게도 필요함 - LLM을 위해 설계된 언어를 상상해봄 모든 함수, 변수, 타입, 예외를 **엄격히 명세**해야 하는 언어 쓰기엔 불편하지만 읽기와 검증이 쉬운 구조일 것임 - ACM의 [Automatically Translating C to Rust](https://cacm.acm.org/research/automatically-translating-c-to-rust/) 글도 흥미로움 코드의 실행 경로가 아니라 **의도**를 보존하는 번역의 어려움을 다룸 - 그렇게 많은 규칙이 필요하다면, 굳이 AI를 쓸 이유가 있을까? **Shellcheck** 같은 도구도 초보를 전문가로 만들어줌 - LLM에게는 **정적 분석이 쉬운 언어**가 더 중요함 RL로 개선하려면 코드의 정합성을 자동으로 판단할 수 있어야 함 **Prolog** 같은 논리 기반 언어의 재조명이 필요함 - Rust도 논리 오류는 막지 못함 LLM이 버그 많은 코드를 낸다면, 언어가 달라도 결과는 비슷함 - 처음엔 vibe coding이 놀라웠지만, 곧 **지속적인 수정 루프**가 정신을 녹임 마치 알고리즘 피드 스크롤처럼 집중력을 빼앗음 지금은 직접 코딩하고, 지루한 부분만 ChatGPT에 맡김 - 정말 **영혼이 빠져나가는 느낌**임 게다가 배우는 것도 없음 - LLM에게 먼저 **명세(spec)** 를 쓰게 한 뒤 수정하는 방법을 써봄 이렇게 하면 요구사항을 명확히 하고, 다른 AI로 쉽게 전환할 수 있음 - 문제를 **작은 단위로 쪼개서 검증**하는 게 가장 효과적이었음 - LLM이 **메모리 누수 없는 C 코드**를 만들 수 있을지 의심스러움 인간 개발자도 실수하는 영역인데, 학습 데이터 품질이 낮은 LLM은 더 위험함 segfault 나는 프로그램을 vibe coding으로 만든다면, 그건 **시간 낭비**임 - 나는 Rust와 LLM을 오래 써왔는데, **cargo check** 덕분에 코드 품질이 매우 높음 거의 깨지지 않고 항상 컴파일됨 - LLM도 스스로 **오류를 탐지**하도록 자원을 할당할 수 있음 인간은 피로하지만 LLM은 그렇지 않음 - LLM은 점점 **고품질 데이터로 미세조정**되고 있음 좋은 C 코드로 재학습시키면 개선될 여지가 있음 - AI가 C에서 **undefined behavior**를 피한다고? 믿기 어려움 인간처럼 실수하도록 훈련된 모델이라면, 같은 버그를 낼 가능성이 높음 - 하지만 최신 모델은 **강화학습과 합성 데이터**로 좋은 코드를 강화함 가장 가능성 높은 토큰을 예측하므로, 흔한 실수는 덜 함 - Copilot Chat의 Sonnet이 **메모리 오류 없는 C++ 코드**를 한 번에 생성해줬음 크래시 원인도 잘 찾아줌 - 인간을 흉내내지 말고 **컴파일러를 흉내내도록** 훈련해야 함 - 그래서 Rust가 LLM 코드 생성에 더 적합하다고 생각함 - Claude로 C 코드를 짜보면, 규모가 커질수록 **pthread나 메모리 버그**가 생김 Zig나 Rust 같은 현대 언어가 훨씬 나음 - vibe coding이 나를 **불편하게 만드는 이유**는 단순히 ‘치팅’ 같아서가 아님 프로그래밍은 **영혼이 담긴 예술**임 문제를 푸는 방식이 사람마다 다르고, 그게 창의성임 vibe coding은 그 창의성을 **기계가 흡수해버리는 행위**처럼 느껴짐 결국 생각도, 결정도, 실수도 모두 기계가 대신함 - “vibe-oriented programming language(VOP)”를 만들자는 제안이 있었음 하지만 LLM을 위한 언어라면 오히려 **엄격하고 장황해야 함** 모든 조건과 예외를 명시하지 않으면 컴파일되지 않아야 함 인간에겐 불편하지만, LLM에게는 **혼란을 줄이는 장점**이 됨 - 사실 출력 언어보다 중요한 건 **입력 언어(프롬프트)** 임 인간이 개념을 설명하고, AI가 그걸 코드로 바꾸는 구조가 필요함 - 그 설명을 들으니 **Ada 언어**가 떠오름 한 번 컴파일되면 거의 항상 제대로 동작했음 - vibe coding을 하더라도, 결과를 검토할 수 있으려면 **잘 아는 언어**로 해야 함 그렇지 않다면 그냥 **brainfuck**으로 실험해보는 게 나을지도 모름 - “그럼 x86 어셈블리로 해보면?”이라는 질문엔, “내가 직접 리뷰하고 확장할 수 있어야 한다”는 이유로 거절함 순수 vibe coding은 **사고 실험**일 뿐, 현실적인 목표가 아님 언젠가 AI가 QA까지 맡을 수 있겠지만, 아직은 **안전한 언어와 인간 검증**이 필수임 - “직접 확장한다면 이미 순수 vibe coding이 아니다”라는 말에 웃음이 나옴 이제 이런 논쟁이 피곤할 정도로 오래된 개발자임