바이브 코딩할 거면 C로 하지 그래요?

• 바이브 코딩이 실제로 잘 작동하지만, 작성자가 스스로 이해하지 못한 코드가 만들어진다는 점에서 프로그래밍의 본질적 즐거움이 줄어듦
• 모든 프로그래밍 언어는 기계가 아니라 인간의 편의를 위해 설계된 도구이며, 안전성·추상화·가독성 같은 장점도 결국 인간이 사고하기 위한 구조
• 그렇다면 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.” — 요즘 말로 하자면, 같은 바이브죠

[youknowone]

언어모델로 코딩하면서 기계에 가까운 표현을 알아서 마법처럼 만들어줄거라 믿다니 도둑놈 심보네요
제약이 걸려 있을수록 제약 안에서 일을 잘 합니다

[aer0700]

ai가 코드를 작성하더라도, 서비스에 대한 책임은 개발자가 져야 할텐데요. 본인이 이해할 수 없는 코드에 대해 책임을 질 수 있을지 싶습니다.

[dooboo]

"vibe coding을 하더라도, 결과를 검토할 수 있으려면 잘 아는 언어로 해야 함"

댓글에 아주 중요한 문장이 있네요.

[GN⁺]

Hacker News 의견들

• 소프트웨어 개발 직군이 정말 다양함을 새삼 느꼈음
  나는 백엔드, 특히 API 개발을 하는데, 생산성의 가장 큰 병목은 대부분의 사람들이 요구사항을 제대로 정의하지 못함에 있음
  PM에게 물어보면 회피하고, 프론트엔드 개발자는 백엔드가 API를 주길 기다림
  결국 가장 어려운 건 코딩이 아니라 요구사항을 발견하고 해석하는 사고 과정임

  • 네가 겪는 어려움은 프로그래밍 자체의 문제가 아니라 비효율적인 조직 구조 때문임
    진짜 프로그래밍은 자신이 설계한 시스템을 구현해 생명을 불어넣는 행위임
    단순히 회사에서 코드를 쓰는 일을 ‘Programming’이라 착각하면 오해가 생김
  • 나는 인문학 전공 학생들에게 프로그래밍을 가르치는 영문학 교수인데, 글쓴이의 경력은 매우 흥미로움
    다만 대규모 상용 소프트웨어 개발 경험은 많지 않을 듯함
    그가 말하는 “프로그래밍의 미래” 예측은 멋지지만, 산업적 맥락에서는 다소 한계가 있을 수 있음
    (참고: Stephen Ramsay 소개)
  • 나는 백엔드, 프론트엔드, 풀스택, 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”라는 토론이 있었음
  (링크)
  Rust가 vibe coding에 적합한 이유는 타입과 생명주기 보장 같은 무료 검증 기능 덕분임
  이런 검증이 없으면 LLM이 불안전한 코드를 쉽게 만들어냄
  추상화는 인간뿐 아니라 LLM에게도 필요함

  • LLM을 위해 설계된 언어를 상상해봄
    모든 함수, 변수, 타입, 예외를 엄격히 명세해야 하는 언어
    쓰기엔 불편하지만 읽기와 검증이 쉬운 구조일 것임
  • ACM의 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이 아니다”라는 말에 웃음이 나옴
    이제 이런 논쟁이 피곤할 정도로 오래된 개발자임