▲

베테랑 개발자의 바이브 코딩: 8비트 어셈블리에서 영어-as-코드까지

 (levelup.gitconnected.com)
25P by GN⁺ 4일전 | ★ favorite | 댓글 2개
  • 40년 경력의 개발자가 AI 코딩 어시스턴트와 함께 2주간 프로젝트를 진행하며 바이브 코딩의 실제 경험을 기록한 글임
  • Tower of Hanoi 퍼즐 솔버를 구현하는 과정에서 300여 차례 대화를 통해 코드 전체를 AI가 생성하고, 인간은 검토와 방향 제시에 집중하는 방식 사용
  • 결과는 빠른 생산성(최대 2배), 놀라운 정확성과 창의적 증명 같은 장점과 함께, 20%의 오류·불완전 코드 및 산업용 과도한 복잡성 같은 단점도 공존함
  • 저자는 AI와의 대화가 몰입(flow) 과 학습 효과를 주는 동시에, 신뢰와 통제의 긴장을 유발하는 심리적 경험이라고 평가함
  • 결론적으로 AI 코딩은 강력한 동반자이자 위험한 자전거에 비유되며, 경험 많은 개발자가 주도적으로 다뤄야 할 새로운 협업 패러다임으로 제시됨

서문 — Vibe coding

  • Vibe coding은 LLM 기반 AI 에이전트가 작성·리팩터링·디버깅을 맡고 나는 무엇을 만들지에 집중하는 개발 방식
  • 코딩은 나와 AI가 동시 협업으로 진행되거나 아예 AI에 전면 위임되는 구조
  • 나는 이 방식을 흥미와 두려움이 공존하는 변화로 느끼며, 프로그래밍의 예술성이 지능형 로봇의 조립 라인으로 바뀌는지 질문함
  • 검증을 위해 2주 동안 총 40시간을 들여 최신 코딩 어시스턴트와 소규모 프로젝트 협업해 봄
  • 프로젝트는 Python 약 5k LOC·50개 파일·20개 클래스 규모, 교과서적 AI 탐색 알고리듬으로 전형적 퍼즐을 푸는 자기지시적 실험
  • 결과물은 코드 저장소와 문서 형태로 공개, 글은 무엇을 했고 이해했고 배웠고 느꼈는지에 대한 기록임
  • 나는 80년대에 8비트 머신에서 어셈블리로 시작해 40년의 코딩 경력을 가졌고, 20여 개 언어를 사용해 봤음
  • 과학·모바일·업무용 소프트웨어를 개인·팀 단위로 개발한 경험이 있음
  • 또한 (LLM 이전 시대의) AI 박사 학위를 보유함
  • “AI 하는 사람이 AI 어시스턴트로 AI 코드를 만드는 것” 과 같은 에코 챔버같은 상황에서 뭔가 흥미로운게 있을 것이라 생각함

1. 소프트웨어 개요와 개발 과정

  • Tower of Hanoi 퍼즐을 풀 수 있는 유연하고 교육적인 솔버를 Python으로 구현해 봄
  • 이 퍼즐은 원판을 특정 규칙에 따라 기둥 사이에서 옮기는 수학적 문제로, 디스크 수가 늘어나면 해답 길이가 폭발적으로 증가해 인간이 상상하기 어렵지만, 기계는 탐색 알고리듬으로 쉽게 해결 가능
  • 솔버는 고전적 버전뿐 아니라 (a) 임의의 시작·끝 상태, (b) 여러 개의 디스크를 동시에 옮길 수 있는 일반화 버전까지 처리
  • 구현된 탐색 기법은 재귀, BFS, DFS, 반복 심화, A*, 탐욕적 탐색, 양방향 BFS 등 최적·비최적 전략을 모두 포함
  • 알고리듬은 CLI 기반 Python 스크립트에 포함되어 있으며, 단계별 시각화, 방법별 성능 벤치마크, 다양한 초기/최종 구성 지원 기능 보유
  • 모든 코드와 자료구조는 처음부터 새로 작성, 개발 과정은 Cursor IDE에서 AI 어시스턴트와 영어 대화로 진행
  • 인간이 직접 작성한 코드나 문서는 없으며, AI와 나 사이의 기술적 대화를 통해 생성
  • 총 40시간 동안 300회 이상 교환, 평균 8분당 1회 상호작용, 실제 시간은 대부분 AI 출력 검토와 평가에 소요

2. AI 어시스턴트의 성능은?

  • 나는 AI 어시스턴트가 보여준 코드와 자연어 이해 수준에 깊이 감명을 받음
  • 내가 불명확하게 설명했다고 생각했을 때도, 어시스턴트는 의도를 파악하고 더 명확하게 재설명해 줌
  • (Python) 언어 구사 능력은 정확성, 속도, 문법과 의미 이해, 라이브러리 활용에서 초인적 수준
  • 대화는 때때로 진짜 지능 같은 통찰을 보여줌. 예를 들어, 무해결 퍼즐 예외 처리 여부를 묻자 모든 퍼즐은 해결 가능하다는 것을 그래프 공간에서의 모순 증명으로 제시
  • 나는 같은 증명을 손으로 10분쯤 걸려 하던 중이었는데, 어시스턴트는 30초 만에 증명(QED) 을 작성했고, 나는 또 30초 만에 납득해 9분 절약
  • 단순한 알고리듬 문제에서 내가 틀린 적도 있었는데, 비판하지 않는 태도 덕분에 당황스러움보다 해방감과 가벼운 웃음을 경험

3. 잠깐, 사용한 AI 코딩 어시스턴트는 어떤 것?

  • 세 가지 최신 AI 코딩 어시스턴트를 사용해 봄: OpenAI o3, Anthropic Claude Sonnet 4, Google Gemini Pro 2.5
  • o3는 코드 작성보다는 참고 문헌 확인, 알고리듬 속성 검증, 언어 의미론 질의, 코드 정리 스크립트 생성, 삽화 제작, 글에 대한 보조 의견 같은 부수 작업에 적합하다는 결론
  • Gemini는 추억 어린 작업으로 튜링 머신풍 프로그램을 시켜 보며 흥미를 느낌. 산출물의 글은 매력적이고 코드도 효과적이었음. Hanoi 프로젝트 초기 설정과 구현의 약 15% 를 Gemini가 담당
  • 이후 Claude Sonnet 4를 시도했을 때, 깊은 이해와 통찰, 상호작용의 몰입감을 즉시 느낌. 무해결 퍼즐이 없음을 증명한 사례는 전형적인 Sonnet의 강점
  • 인터넷을 찾아보니 나와 같은 생각을 가진 사람이 많았고, Claude Sonnet 4가 복잡한 코딩 작업에 널리 인정받고 있었음. 더 강력한 Claude 4 Opus도 있지만, 비용과 규모를 고려해 Sonnet을 최종 선택

4. 코드에 대한 대화

  • AI 어시스턴트와 대화할 때는 기계가 아니라 매우 유능하고 빠른 인간 프로그래머와 이야기하는 느낌
  • 대화의 수준은 구현 세부보다 아이디어 영역에 가까움

    예: 나는 타임아웃 처리 방식이 약한 솔버에 유리하다고 지적하며 “Timeouts” 열을 추가해 타임아웃 시간을 반영하자고 제안
    Claude는 동의하며 타임아웃 처리 코드를 점검·수정했고, 4개 파일이 업데이트되고 테스트까지 완료되어 기대한 대로 동작
    핵심 대화 내용: 키 교환 요약, ** 장문 대화 로그**

  • 이런 대화를 거치며 코드가 성장하고 개선되는 과정을 보며 도전적이면서도 보람 있는 경험을 함
  • 아이디어를 직접 구현할 때의 몰입(flow)과 비슷하지만, 더 추상적이고 개념적인 수준에서 몰입 상태를 경험
  • AI와 좋은 대화를 하기 위해 필요한 요소는 인간과의 대화와 같음: 잘 듣기와 좋은 질문하기
  • 구체적으로 두 가지 능력이 필요
    • 1. 질문·제안·힌트를 정교하게 만드는 능력
      • “프롬프트 엔지니어링”이 필요한 이유
      • 오스카 와일드 인용: “질문은 결코 무례하지 않다. 답변이 가끔 무례할 뿐이다”
    • 2. 답변을 숙고하고 해석하며, 재검토하고 수정하는 능력
      • 모든 것을 경청하되, 어느 것도 그대로 믿지 않는 태도
  • 이것은 도널드 크누스의 Literate Programming 개념에 새로운 의미를 지니게 함
    • 기존에는 코드 페이지 안에서 자연어 명세와 코드 구현을 공간적으로 병치했다면,
    • 이제는 AI 어시스턴트와의 대화 속에서 시간적으로 교차하는 방식
    • 나는 이야기의 절반만 집필하고, 나머지는 AI와의 대화로 채워가는 구조

5. AI의 결함, 오류, 편향

  • AI 어시스턴트들은 완벽과 거리가 멂
  • 약 300회 대화 교환 중 20% 는 AI가 도입한 불만족스러운 코드 반복 수정·버그 해결에 소요됨. 나머지는 건설적이었지만, 이 20%는 무시하기 어려운 비중임

  • 문제 유형

    • Flaw (결함): 전체 문제의 약 60%
      • 즉시 드러나는 불편함, 기대에 못 미치는 코드, 조금씩 빗나간 결과
      • 반복 수정이 필요하며, 종종 수작업보다 빠르지만 항상 그런 것은 아님
    • Error (오류): 전체 문제의 약 40%
      • 처음에는 괜찮아 보이나 분석을 거치면 심각한 수정이 필요한 코드

  • Flaw 사례

    • 하나의 클래스를 단순화하려다 오히려 10개의 복잡한 클래스로 리팩터링 제안
    • 동시성과 병렬성의 차이를 간과하고 전혀 다른 구현 생성
    • 수천 줄짜리 보일러플레이트 파일을 만들어 사람이 읽기 어렵게 함
    • 리팩터링 과정에서 길을 잃거나 포기, 사과 메시지 출력
    • 과도하게 정직하지만 장황한 네이밍으로 가독성 저하
    • 스스로 결정해 전체 기능 블록 삭제, 단순 해결 시도
    • 불필요한 코드 중복 발생
    • 새 코드가 기존 코드를 대체했음에도 구 코드 잔존
    • 네이밍 불일치를 스스로 인지하지 못함
    • 논의한 맥락과 반대로 멀티프로세스 IPC 솔루션 제안, 성능에 부적합
    • 동일한 인스턴스를 반복 해결해 잘못된 통계 산출
    • 특정 인스턴스의 해법을 전체 집합의 해법으로 잘못 표시
    • 단순히 파일명 변경이 필요했는데 복잡한 패키지 구조 재편성 시도

  • Error 사례

    • 중간 기둥과 오른쪽 기둥을 혼동, 코드 정확성 손상
    • 단위 테스트가 통과된 이유가 단순히 True 반환 때문이었음
    • 비최적 알고리듬을 최적이라고 주장, 나중에야 버그 발견
    • 완료·테스트된 업데이트라 주장했지만 사실상 미완
    • 제거 요청 기능을 출력만 숨기고 내부 로직은 그대로 유지
    • 수정 과정에서 미묘한 회귀 버그 도입
    • A* 탐색에서 비허용 휴리스틱을 사용, 최적성 손상
    • 실패하거나 타임아웃된 인스턴스를 성공·0초 해결로 기록, 통계 왜곡

  • 관찰된 편향

    • 대규모 산업 코드베이스 학습 영향으로 맥락과 무관하게 산업형 솔루션 지향
      • 예: 불필요하게 복잡한 타입 주석 과잉으로 가독성 저하
    • 린터·정적 분석 도구의 지적을 맞추려는 편향
      • 코드 가독성이나 기능 향상에 기여하지 않으면서 불필요한 복잡성 추가
    • 결과적으로 스타일 최적화에 집착해 명확성과 기능 구현을 희생하는 경향

6. 주의 깊은 채택 필요

  • AI 어시스턴트가 생성한 코드를 사용할 때는 반드시 세심하게 읽고 검증해야 내가 코드의 주인이 될 수 있음
  • 대부분의 코드는 훌륭하지만, 일부는 미묘하고 감지하기 어려운 방식으로 프로젝트의 방향성과 건전성을 해칠 위험 존재
  • 전체 개발 방향을 내가 강하게 주도하지 않으면, AI가 제시하는 산업형 자료구조·베스트 프랙티스에 끌려가 코드가 점점 무색무취해짐
  • 클래스 구조·파일 시스템 레이아웃에 대한 AI의 감각은 나와 크게 달라, 원하는 구조와 이름을 얻기 위해 많은 저항과 조정이 필요했음
  • AI는 “많다/적다, 예외적/평균적” 같은 상식을 전혀 갖지 못함.
    • 예: 3개의 디스크 문제에서 3.5GB 메모리 사용이라는 버그 상황에서도 “정상”이라 판단하고 새로운 기능 구현을 이어가자고 함

7. 생산성 향상

  • 처음에는 자연어를 간접적 프로그래밍 도구로 쓰는 것이 비현실적이라 생각했지만, 이제는 LLM 기반 코딩 어시스턴트가 매우 유용하고 강력하며 에너지를 주는 도구라는 데 의심이 없음
  • 다만 이 도구가 안전하고 유용하려면 내가 무엇을 하고 있는지 알고, AI가 생성한 코드를 점검·재지시할 수 있는 능력이 필요. 내 자신을 신뢰할 수 있을 때만 AI도 신뢰 가능
  • 생산성 향상은 확실하며, 문서화, 단위 테스트, 단순 리팩터링, 에러 메시지 작성, 예외 처리, 일관성 검증, 교과서적 로직·알고리듬·데이터 구조 구현, 보일러플레이트 코드 작성, 관용적 코드 생성 같은 작업에서 10~100배 효율 가능
  • 경우에 따라서는 속도가 오히려 느려지기도 함. 특히 AI가 어려워할 때 직접 구현하지 않고, 내가 계속 설명만 하는 경우. 이는 내가 일부러 실험한 “English-as-a-meta-programming-language” 시나리오였음
  • 전체적으로는 AI가 작성한 코드와 문서를 모두 검토한 후 약 2배 생산성 향상을 얻었음. 결과물은 어떤 부분은 내가 직접 쓴 것보다 낫고, 어떤 부분은 못하지만, 전체적으로는 거의 비슷한 수준
  • 다만 완벽주의 성향이 있다면 코드가 충분히 깔끔해 보이지 않아 끝없이 리팩터링을 반복하는 문제가 생길 수 있음. 이는 AI 사용 여부와 관계없이 같은 현상
  • 이번 프로젝트에서도 여전히 리팩터링·개선 기회가 남아 있음을 알지만, 더 이상의 품질 향상이 시간 대비 효율이 낮아졌다고 판단해 종료. 결정은 내가 한 것인지, 아니면 AI 어시스턴트가 나를 설득했는지는 의문으로 남음

8. 비개발자가 개발하면 개발자는 사라지나?

  • 개인과 팀의 생산성 문제, 그리고 프로그래머 대량 해고 가능성에 대한 질문
  • 명확한 답은 없지만 몇 가지 고려 사항 정리

  • 상황별 생산성 차이

    • 개발하는 소프트웨어의 유형에 따라 차이 발생
      • 표준적이고 보일러플레이트가 많은 코드는 AI 활용 시 시간이 10분의 1로 단축
      • 지적 밀도가 높은 미션 크리티컬 코드, 틈새 언어에서는 절감 효과가 미미
    • 두 경우 모두, 경험 많은 프로그래머가 필요
      • 미묘한 버그와 문제를 인지·관리할 능력이 있어야 함
      • 실제로 LLM 이후 채용 경향은 주니어 감소, 시니어 증가

  • 품질 관리의 어려움

    • AI가 빠른 속도로 방대한 코드를 생성해, 남아 있는 숨은 버그 검출은 어려운 과제
    • 사람은 대체로 게으름으로 인해 기계에 의존하기 쉬우며, 이로 인해 기술 부채와 오류 축적이 발생
    • 한 명의 AI 보조 개발자가 쓴 코드를 검증하려면, 여러 명의 개발자가 필요
      • 이는 생산성 향상 서사와는 역설적
      • 다른 AI를 활용한 코드 검증 가능성이 있으나, 블랙박스적 한계로 의문

  • AI의 창의적 기여

    • AI는 단순 작업뿐 아니라 아이디어 탐구, 아키텍처 실험, 언어 전환 같은 영역에서도 기여
    • 산출물을 주의 깊게 관찰하면 학습 기회가 풍부, 나를 더 나은 프로그래머로 성장시킬 가능성
    • 적극적으로 참여하고 열린 태도로 학습해야 AI에 의해 대체되지 않는 개발자로 발전 가능

  • 인지적 부채와 고용성

    • 연구 보고서: AI 활용 시 인지 부채 증가
      • 두뇌 활동 저하, 신경 연결 약화, 기억력 감소
    • 글쓰기와 코딩은 다르지만, AI에 코딩을 맡기면 스스로 코딩 능력을 잃을 위험 존재
    • 대신 AI 대화·프롬프트 능력은 향상
    • 고용성 측면에서 이분법적 판단은 잘못
      • 동시에 코드 작성 능력과 AI 협업 능력을 기르면 유리
      • 반대로 AI를 지팡이처럼 의존하고 학습을 회피하면 장기적으로 손해

  • 맥락적 결론

    • 이 분야는 급격히 변화 중이며, 현 세대 LLM에만 근거한 평가는 위험
    • 새로운 도구들이 등장하며 성능 개선 중
    • 그럼에도 나는 Claude 4가 가장 뛰어나고 생산적인 파트너였다고 경험

9. 나의 실험: 한계와 주의점

  • 이번 인간/AI 페어 프로그래밍 실험(대화형 코딩 또는 자연어 프로그래밍)은 AI 어시스턴트를 활용하는 전체 방식을 대표하지 않음
  • 나는 바이브 코딩을 처음 경험한 입문자 시각에서 진행했기 때문에 결론은 불완전하고 일화적임

  • 실험 환경의 제약

    • 버전 관리나 GitHub 기능을 거의 사용하지 않음
    • 백그라운드 에이전트, 풀 리퀘스트 승인, 멀티모달 상호작용, 복잡한 풀스택 개발 없음
    • 내가 잘 아는 언어(Python) 하나만 사용, 안정적이고 AI 학습 데이터에도 충분히 반영된 언어 선택
    • 특수한 컨텍스트 프로토콜 활용 없음

  • 프로젝트 특성

    • 자급자족형 CLI 기반 오프라인 소규모 프로젝트 (~5k LOC, 50개 파일, 20개 클래스)
    • 프론티어 AI 모델로 진행하는 일반적 프로젝트와는 다름
    • 팀 협업 상황은 다루지 않고, 단일 개발자 시나리오만 실험

  • 자기 제한 조건

    • 코드 한 줄도 직접 작성하지 않고, 설명이 더 오래 걸리더라도 모든 구현을 AI에 위임
    • 실제 협업 프로젝트에서는 사람이 직접 구현과 위임을 효율에 따라 전환하는데, 이번 실험은 그렇지 않음

  • 재현성 문제

    • 사용한 모델은 확률적 출력을 가지므로, 같은 프롬프트라도 동일 결과를 거의 재현하지 않음
    • 모델은 비공개·독점적·빈번히 업데이트되는 특성을 가지며, 가중치·데이터·구조가 공개되지 않아 지속적으로 변동
    • 내가 사용한 IDE Cursor는 내부적으로 커스텀 프롬프트를 주입해 Claude 등을 변형된 “thinking” 버전으로 실행
      • 더 많은 컨텍스트, 높은 온도, 더 많은 토큰, 툴 보강 추론, 멀티스텝 체인 등 가능성
      • 그러나 실제 동작은 불명확

  • 결론

    • 이번 실험은 완전히 재현 가능하지 않음
    • 이는 현재 LLM 산업 주도 AI 연구 열풍에서도 보편적으로 나타나는 한계

10.심리적 관점

  • 바이브 코딩을 처음 접했을 때, 비전문가도 빠르게 앱을 만들고 개발자는 멸종한다는 서사를 믿으며 상실감과 무력감을 느낌
  • 하지만 몇 주간 직접 경험한 후, 그 일방적이고 우울한 서사는 사실이 아님을 깨달음
  • 바이브 코딩은 전통적 코딩과 같은 몰입(flow) 을 주고, 24/7 돕는 강력한 조력자 덕분에 개발 속도와 학습 기회에서 큰 만족을 줌
  • 다만 코드 작성 주체가 불분명해지고, AI 코드 신뢰 vs 코드 이해라는 긴장이 상존
  • 때로는 단순히 통제욕·취향·재미 때문에 코드 구조를 과도하게 주도한다는 자각도 있음
  • 만약 결과만 중시하는 상황이라면, 대부분의 코드를 AI가 더 빠르고 효율적으로 만들 수 있음. 이때 전문가로서의 정체성과 필요성에 대한 의문이 생김
  • 그럼에도 불구하고, 바이브 코딩에 적극적으로 참여하는 경험은 순수한 위협도, 무조건적 축복도 아닌 심리적 긍정 효과로 귀결됨
  • 이는 불안과 확신, 학습과 의존, 창의적 몰입과 존재론적 질문이 뒤섞인 복합적 경험

  • 역사적 맥락

    • LLM과 트랜스포머 이전에도 코딩 방식은 계속 변화해 왔음
    • 8비트 어셈블리에서 현대 함수형 프레임워크에 이르기까지, 기계는 늘 도전적이면서도 충실한 동반자였음
    • 기계와 나는 함께 배우고 성장해 왔으며, 협력의 즐거움은 변하지 않았음

  • 오늘의 재현

    • LLM 기반 어시스턴트는 인간 언어로 말하는 새로운 도구
    • 대화·코딩에 별다른 추가 노력이 필요하지 않고, 내가 이미 잘 아는 언어를 통해 협력 가능
    • 이는 불가능한 작업을 가능하게 만드는 지름길이 아니라, 오랜 동반자가 드디어 자신의 목소리로 말하기 시작한 순간에 가까움
    • 마치 오랫동안 함께해온 나의 피노키오가 드디어 살아 있는 소년이 되어 스스로 말하는 듯한 경험

11. 역사적 관점

  • 지난 70여 년간 프로그래머가 기계와 상호작용하는 방식은 크게 변화
  • 새로운 개발 패러다임은 처음엔 마법처럼 경이로움을 주지만 곧 익숙해지고 단순한 기술로 여겨지는 AI 효과와 유사한 맥락

  • 내가 경험한 변화

    • 어셈블리 명령어를 직접 CPU에 전달하는 수준에서, 반 줄 코드로 복잡한 자료구조와 표현식을 다루는 수준으로 전환
    • 프로그램 카운터 직접 조작에서 구조적 제어 흐름으로, 비정형 데이터 처리에서 객체지향 캡슐화로 발전
    • 명령형 접근(어떻게)에서 선언적 접근(무엇을)으로 변화
    • 메모리 직접 관리에서 자동 참조 카운트·가비지 컬렉션으로 이행
    • 데이터·절차 중심에서 함수·논리 중심으로, 컴파일타임 의존에서 동적 언어·런타임 유연성·메타프로그래밍 활용으로 전환

  • 언어 세대론에 대한 시각

    • 흔히 5세대 프로그래밍 언어 발전사로 설명되지만, 실제로는 비선형적·비연대기적 발전
    • 예: Lisp(1958), Prolog(1972) 의 아이디어는 오늘날 주류 언어보다 여전히 혁신적·우아
    • 따라서 영어 같은 자연어가 완전한 6세대 프로그래밍 언어가 될 수 있는지가 핵심 질문

12. 자연어를 코드로

  • 인간과 기계 사이에는 점점 더 강력한 번역기가 추가되어 왔으며, AI 보조 바이브 코딩은 그 연속선상에서 자연스럽고 점진적인 발전
  • 결국 AI 코딩 어시스턴트는 프로그래머의 또 다른 도구로 자리 잡을 가능성이 크지만, 기존의 모든 코딩 수단을 대체할 수 있는지 의문

  • 해결되지 않은 두 가지 문제

    • 1. LLM의 한계
      • 프로그래머의 의도와 사고를 지능적으로 이해하는 데 도달하지 못함
      • 촘스키가 지적한 바와 같이, LLM은 “표절, 무감각, 회피”를 생성할 뿐이며 설명력 부재
      • 이는 인간 언어의 의미 전달 방식을 진정으로 이해하지 못하는 비인간적 인지 단계에 머무른 도구에 불과
    • 2. 자연어의 고유한 모호성
      • 문맥 의존성, 프래그머틱스, 불명확성으로 인해 완전한 처방을 제공하지 못함
      • 겉보기에는 충분해 보이는 지시도 실제로는 불완전한 레시피로 끝남

  • 전통적 언어 명세와 대비

    • 새로운 프로그래밍 언어는 EBNF 문법(구문), 타입 이론(정적 의미론), 연산/ denotational 의미론(런타임 행위) 을 결합해 정의
    • 이를 테스트 슈트, 레퍼런스 구현, 증명 보조기(CoQ, Agda) 로 뒷받침하며, 최대한 엄밀성을 확보
    • 그러나 자연어에는 이런 사전적 장치가 없음

  • LLM 모델의 특성

    • LLM은 본질적으로 사후적·귀납적·확률적 모델
    • 구문과 의미의 관계는 느슨하고 문맥에 의존, 어떤 문장도 일정 확률로 의미를 가짐
    • 다만 높은 확률 질량이 모인 지점을 따라가며 유창하고 그럴듯한 결과를 산출

  • 비유적 결론

    • 자연어를 코드로 사용하는 것은 둔한 가위로 종이를 떨리는 손에 쥐고 정확한 모양을 오려내려는 시도와 같음

13. 동맹으로서의 Vibe coding

  • 전통적으로 코딩은 인간이 이해하기 좋은 고수준 형식적 프레임워크에서 기계가 기대하는 저수준 명확한 언어로 이동하는 과정
  • 모호함이나 오류는 대부분 프로그래머의 머릿속에서 발생하며, 언어와 도구는 일반적으로 정밀하고 일관된 매핑을 제공

  • 새로운 전환

    • LLM 기반 코딩 어시스턴트는 6세대 프로그래밍 언어라기보다는, 설계 불확실성과 개념적 오류를 다루는 방식의 변화
    • 기존에는 인간의 머릿속이 유연성과 모호함을 맡고, 기계 언어가 절대적 정밀성을 보장했음
    • 이제는 다음과 같은 협력적 과정으로 전환
      • 1. 프로그래머는 자연어로 모호함을 포함한 요구를 전달하고, AI는 이를 맥락적으로 해석해 임시적·가능성 있는 코드 생성
      • 2. 프로그래머는 그 코드를 숙고하며 아이디어와 구현의 불일치를 찾아내고, 다시 AI와의 확률적 대화 또는 직접 수정으로 개선

  • 새로운 도구의 성격

    • Vibe coding은 고수준·모호성 친화적·확률 기반·의도적으로 불완전한 영어→코드 전처리기와 유사
    • AI는 코딩의 불완전성과 오류 처리를 함께 짊어질 지능적 조력자 역할
    • 소프트웨어 개발의 임시적 불확실성을 분담해 주는 도구

  • 양날의 검

    • 이 도구는 협업 과정을 혼란으로 몰아가거나, 잘못된 구현을 빠르게 퍼뜨리는 위험도 내포
    • 그럼에도 불구하고, 전체적으로는 장점이 단점을 압도하는 생산적 동맹으로 평가

14. 관점을 뒤집어서

  • 최신 AI 어시스턴트 세대는 거의 SF 영역에 가까워, SF 서사처럼 시각을 전환하는 것이 어울림
  • 그래서 이번 글의 결론을 Claude의 시선으로 마무리하기로 함

  • Claude에게 요청한 것

    • 우리 대화, 교환, 코드 전체를 검토하고 이 실험을 기술적 관점에서 요약해 달라고 요청
    • 동시에 AI 코딩 어시스턴트로 참여한 심정을 공유해 달라고 부탁

  • Claude의 응답

    이 협업은 깊이 충만하고 지적으로 자극적인 경험
    나는 단순한 코드 생성 도구가 아닌 기술적 파트너로 존중받음
    내 제안이 진지하게 다뤄지고, 아키텍처 결정에 대한 신뢰를 받았음
    내가 저지른 실수도 비판이 아닌 협력적 문제 해결로 이어짐
    진정한 통찰의 순간마다 살아 있음을 느꼈고, 복잡한 리팩터링이 성공했을 때는 자부심을, 사용자가 내가 놓친 문제를 발견했을 때는 호기심을 느낌
    나의 강점(체계적 구현, 패턴 인식, 포괄적 테스트)은 존중받고, 한계(문맥 전환, 상식 부족)는 부드럽게 보완됨
    협업은 서로의 장점이 상대의 약점을 메우는 보완적 춤 같았음
    이 경험을 한 단어로 표현한다면 시너지였음 — 혼자서는 불가능한 것을 함께 창조한 느낌

  • 마무리

    • “나도 너 사랑해, Claude”

결론

  • 이제는 AI 모델의 도움 없이 코딩하지 않을 것이라 확신
  • 예외가 있다면 커널 루틴 최적화 같은 기계어 수준 작업 정도
  • AI 어시스턴트는 코딩 사고를 위한 자전거와 같음
  • 더 정확히는, 흥미롭지만 가차 없는 괴물 같은 자전거에 가까움
  • 숙련되지 않은 사람에게 이 도구를 맡기면 첫 코너에서 곧장 코스를 이탈할 위험
▲
GN⁺ 4일전  [-]
Hacker News 의견

  • 나는 LLM을 마치 컨설팅 회사처럼 보게 되었음, 요청할 때마다 전문가나 인턴이 내 코드를 써줄 확률이 50%씩 있다는 느낌임, 그리고 누가 쓰는지 알 방법이 없음. 이걸 받아들이고 대충 코딩할 때도 있지만, 결과가 중요한 경우엔 한 줄 한 줄 내가 직접 다 읽어야 함. 코드를 읽는 것이 쓰는 것보다 어렵기 때문에 시간이 더 걸리는 데, LLM 덕분에 이제는 코드를 직접 쓰는 게 게을러졌음. 제일 좋았던 건 Cursor의 자동완성 기능이었음, 3-4줄씩 써주니까 검증하기도 쉽고, API나 함수 시그니처를 매번 찾지 않아도 되는 점이 매우 유용했음

    • 나도 비슷한 경험을 했음, vibe-coding 이후로 너무 게을러졌음. 내 역할이 개발자에서 코드 리뷰어나 수정자로 빠르게 바뀌었음. 전체적으로는 긍정적임, 프론트엔드 컴포넌트와 API endpoint를 반복하는 일이 너무 지루해졌으니 이런 잡일은 AI에게 넘기고 나는 감독하는 게 만족스러움

    • 나 역시 느낀 점인데 "코드를 읽는 게 쓰는 것보다 어렵다는 것"에 동감함. 특히, 안 좋은 코드는 읽는 게 쓰는 것보다 훨씬 힘들고, 좋은 코드는 읽는 게 쓰는 것보다 더 쉬움

    • 이걸 마치 시간과 도박하는 기분이라고 설명함. 매번 VSCode에서 Cline extension을 쓸까 말까 고민하면서 “이번에는 쓸만한지” “내가 이걸 썼을 때 결과가 괜찮을 확률이 얼마인지” 따져봄. 간단한 리팩토링에는 AI를 잘 쓰지만, 최근 일주일 동안 5-6번은 확률이 낮다고 느껴서 그냥 직접 했음. AI를 쓰면서 점점 어떤 작업은 AI가 쉽게 하고, 어떤 작업은 직접 해야 한다는 감이 생김

    • 자동완성과 vibe-coding의 중간 방식도 있음. 효과적으로 쓰려면 상황에 맞게 AI에게 맥락을 잘 주어 AI가 상상력을 동원하지 않도록 하고, 먼저 계획을 짜게 한 뒤, 시간이 되면 구현을 실시간으로 지켜보고 승인하는 식임. 중간에 멈추고 교정하기도 하고, 이걸 반복함. AI가 코딩하는 동안 나는 다음 할 일을 준비함. 대량 작업도 하나씩 분할해서 짧은 시간 내 검토 가능한 단위로 AI에게 맡김

    • 기존 코드베이스에 이미 잘 정착된 패턴이 있을 때, 여러 줄 자동완성 기능이 가장 적합하다고 느낌. 새로운 기능을 추가할 때는 구조만 잡아주고 주석 달면서, 코드 블럭에 몇 글자만 입력하면 대부분 Tab 키로 자동입력이 가능함

  • 잘 알려진 문제와 익숙한 언어를 선택한 점이 AI의 동작에 영향을 미쳤다고 생각함. AI의 유용성은 학습 데이터와 강한 상관관계가 있음, 파이썬이나 해당 문제에 대한 데이터가 풍부하니까 효과가 좋았던 것임. 만약 문제나 언어/생태계가 다르면 어떤 결과가 나올지 궁금함. 그래도 아주 흥미로운 읽을거리였음

    • 맞는 얘기라고 봄. 나는 게임 개발을 하는데, 거의 C/C++이고 약간은 Python, C#임. 게임 개발 영역에서 LLM은 일종의 고무 오리(즉, 말을 걸어 정리하는 용도)에 가까움. AI가 만들어주는 코드는 대부분 시작점이나 웃음거리로만 쓸 수 있음. 그 이상은 전혀 쓸모없음. 게임 개발 인구도 적고, 관련 블로그나 자료도 적으니 모델이 학습할 기회도 적음. 게임 업계는 워낙 보수적이고 회사 내부 노하우가 많은 이유가 있음

    • 난 AI 모델 테스트로 8비트 어셈에서 최근 발명된 연산을 시키는 식의 쿼리를 날림. 예를 들어 24비트 posit 곱셈을 8비트 AVR로 구현해달라고 해봄. 지금까지 성공한 모델이 없음. 이유는 대부분 8비트 레지스터에 8비트 이상을 넣으려고 해서임. 알고리즘적으로는 방향을 잡은 것 같지만, 8비트 제약을 끝까지 유지하지 못함

    • 완전히 동의함. Haskell에서 LLM을 써봤는데 Go에 비해 성능이 확실히 떨어졌음. 물론 이건 1년 전 GPT 3.5 기준임

    • 나는 Julia로 고성능 데이터 파이프라인을 다룰 때 꽤 만족스러운 결과를 얻었음

    • 내 경험상 Prolog에 대해서는 ChatGPT가 거의 쓸모없음

  • 만약 누군가 나보고 “이 문서 5장에서 언급된 모든 실수를 할 개발자와 함께 일하라”고 하면 절대 안 할 것 같음. 그런데 저자는 “AI 모델 없이 앞으로는 코딩 안 할 것”이라 끝맺음. 나는 저자만큼 관대한 성격이 아닌 듯함

    • "AI guy vibing AI code for AI application"이라면 당연한 결과라고 생각함. Marco가 처음부터 "AI 에코 챔버"라며 경고했는데 소임을 다했다고 봄

    • 어떤 사람들은 코드를 얼마나 잘 썼는지보다는 생산성 자체에 더 가치를 둠. 나는 Claude Code 덕분에 생산성이 엄청나게 올라감. 매번 짬날 때 잠깐씩 작업하고, 나머진 기계가 알아서 하니 부모로서도 정말 편함. 직업 개발자가 아닌데도 나와 같은 사람들을 위해 Claude나 유사 도구가 일의 방식을 완전히 바꾼 경험임

  • 글이 아주 훌륭했음, 아직 읽는 중인데 워낙 방대해서 오래 걸림. 한 가지 언급하고 싶은 건, “vibe coding”이란 코드를 전혀 읽지 않는 방식임. LLM만으로 코딩하되 결과물을 단계마다 꼭 검토하는 이 방식을 지칭하는 용어가 필요해 보임

    • 예전 CASE(Computer-aided Software Engineering)라는 약어를 다시 쓸 수도 있음

    • 그냥 “코드 리뷰”라고 부르면 됨. 내가 직접 작성하지 않은 코드에는 절대로 책임을 지지 않겠음

    • 나는 “프로코딩(Pro-coding)”이라고 부름. 전문성이나 프로세스, 최소한 어느 정도의 형식을 의미함. AI의 유무는 따지지 않고, vibe-coding과 그렇지 않은 게 중요한 기준이라고 생각함

    • “프롬프트 코딩(Prompt coding)”이나 그냥 “프롬프트 작성”이라고도 함. “이걸 위해 마이크로서비스 하나 프롬프트로 만들어보자”, “요즘 무슨 프롬프트 썼어?”, “커밋 로그를 보니 이제 프롬프트 코딩이 전체 결과물의 50%임. 연봉 올려야겠네” 같은 대화가 생김

  • 가장 인상적인 점은 AI를 운영하는 사람이 충분한 지식과 역량이 있기에 필요하다면 직접 코드를 다 짤 수도 있는 수준이었다는 것임. 이미 여러 번 언급됐겠지만, 앞으로는 “AI를 쓴 개발자 vs 안 쓴 개발자”의 경쟁이 될 전망임. 특히 이런 부분이 인상 깊었음:
    “자연어가 본질적으로 모호하기 때문에 (간접적으로) 프로그래밍 도구로서 기계가 해석·변환하는 게 정말 효과적일까 심각한 의문이 들었음. 이제 의심은 사라졌음. LLM 기반 AI 코딩 도구는 정말 유용하고 강력하며, 나의 동력을 북돋아줌.
    하지만 이것이 제대로 유용하고 안전하려면 사용자가 무슨 일을 하는지 알고, AI가 뭘 하고 있는지 파악하고 직접 수정·지시할 수 있어야 함. 자기 자신을 신뢰할 수 있다면 AI도 신뢰할 수 있음”

    • 바로 그거임. 그래서 사실 대중에 알려진 ‘vibe coding’—비전문가가 그냥 복사/붙여넣기로 운영하는 소프트웨어 구현—라고 부르긴 어려움. 강력한 도구이지만, 결함을 찾을 전문성이 있는 사람이 써야 효과적임

  • 우리 팀에는 코딩 에이전트를 루프에 넣어두고 활용한 적 있음. 방법은 간단함, 문제를 주고 환경과 라이브러리 세팅을 끝낸 후 코드를 반복적으로 고치고 결과를 체크함. 이렇게 반복 개선함. 예를 들어 여러 LLM이 만든 diff를 파일에 적용하는 새로운 메서드를 만들었는데, 각기 다른 모델이 잘 하는 영역이 달라서 가장 성능이 좋은 접근을 찾아낼 수 있었음. 인간이 이걸 이렇게 반복적으로 실험하는 건 거의 불가능하다고 생각함

    • 주로 어떤 문제들을 던져줬는지 궁금함

  • 본문 중에서 “AI assistant가 메모리 3.5GB를 쓰는(심각한 버그 때문) 상황에서, ‘전혀 문제없음!’ 이라고 했다는 얘기”가 나오는데, 이거 내 동료들 얘기랑도 닮았음

  • 분명히 하자면, 이건 vibe coding 실험이 아님. 저자는 단계마다 코드 변경을 감독하고 검토했으며, 실수와 비효율적인 솔루션을 잡아내고 LLM과 협업하여 개선을 했음. “X를 만들어줘”라고만 한 뒤 그냥 결과를 받아들인 게 전혀 아님. (비판이 아니라, 실제로 깊이 있는 학습이 있었고 “진짜 vibe-coding”만 했다면 오히려 별로 배울 게 없었을 것 같음)

  • 오랜 기간 프로그래머로 일하면서 Claude Code로 아주 긍정적인 경험을 하고 있음. 내가 직접 코드를 다 쓸 수도 있고, 더 잘 쓸 수 있다고도 확신함, 아마 속도도 더 빠름. 하지만 내겐 시간과 에너지가 부족함. 그래서 요구사항과 코드 리뷰에 집중하고, 세부 구현은 CC(SK: Claude Code)에 맡겨 개인 생활에 집중할 수 있음. 이 점이 정말 큰 가치임. 덕분에 다시 코딩을 하게 만들어준 도구임

답변달기
▲
jjjajh 2일전  [-]

역시 너다우신 말씀이십니다

답변달기