▲

GN⁺: "Vibe Coding" vs 현실

 (cendyne.dev)
18P by neo 5일전 | ★ favorite | 댓글 9개
  • 최근 Andrej Karpathy의 발언이 화제: "Vibe에 몸을 맡기고, 기하급수적인 성장을 받아들이고, 코드가 존재한다는 사실 조차 잊어버리세요."
  • "Vibe Coding"은 명확한 계획이나 코드 작성 없이 AI 도구에 문제 해결을 위임하는 경향을 의미함
  • LLM(대형 언어 모델) 에이전트를 통해 자연어로 명령을 내리면 코드를 생성하고 수정할 수 있게 됨
    • 2022년: ChatGPT에서 코드 복사 및 수정 가능
    • 2023년: IDE와 통합된 Copilot에서 코드 리뷰 및 수정 가능
    • 2024~2025년: 프로젝트의 여러 파일을 수정하고 자체 테스트 및 수정 가능

"Vibe Coding"의 작동 방식

  • 기술 및 비기술 사용자 모두 LLM 기반 에이전트를 통해 프로젝트 설정 가능
  • 단순한 명령으로 웹사이트나 앱 생성 가능 (예: "스키 리조트 웹사이트 만들기")
  • 초기 설정 이후 자동 수정 및 테스트 가능

  • 예제:

    • Cursor, GitHub Copilot Agent Mode 등은 파일 수정 및 명령 실행 가능
    • 자동 수정 및 테스트 수행 → 일관성 부족으로 오류 발생 가능

에이전트의 자율성 문제

  • 에이전트는 자동으로 작업 수행 가능하지만 완전한 자율성은 아님
  • 사용자 승인 없이 실행되면 위험 발생 가능 (예: YOLO 모드에서 명령 실행)
  • 코드 품질 및 정확성 문제 발생 가능

  • 주요 문제:

    • 기존 코드 재사용 실패 → 동일한 컴포넌트 반복 생성
    • 클라이언트 측에서 서버 측 로직 실행 시도
    • 잘못된 코드 수정 후 오류 발생 → 수정 시 실패
    • 유닛 테스트 작성 실패 또는 코드 파괴 발생

현실적인 한계

  • Claude 3.7 Sonnet 등 모델은 훈련 데이터의 한계를 벗어나지 못함
  • 코드 기반에서 문맥을 잃으면 일관성 있는 수정 불가능
  • 코드 크기가 커지면 성능 저하 및 문맥 유지 불가능
  • LLM의 문맥 창 크기 초과 시 일관성 문제 발생

  • 구체적 문제 사례:

    • TypeScript 인터페이스 복제
    • 클라이언트에서 서버 로직 실행
    • 중복 컴포넌트 수정 실패
    • 유닛 테스트 작성 실패
    • 코드 리팩토링 후 오류 수정 실패

문제 해결 시도

  • Claude Plays Pokémon: 에이전트가 실시간 상호작용하며 게임 플레이
  • 메모리 유지 및 반복 오류 수정 시 실패
  • 장기적 기억 구축 실패 → 지속적인 오류 발생

  • 개선 가능성:

    • MCP(Model Context Protocol) 및 메모리 관리 개선 필요
    • 코드 수정 시 LLM이 이전 수정 내용을 정확히 반영해야 함
    • 도메인별 기억 및 작업 내역 보존 필요

결론

  • "Vibe Coding"은 기능적인 개념을 구현하는 데 80%까지 도달할 수 있지만, 신뢰할 수 있고 안전한 제품을 만들기 위해서는 경험 있는 인간의 노력이 필요함
  • AI 에이전트는 숙련된 사람들이 독립적으로 더 많은 것을 창조할 수 있게 해주지만, 경험과 직관이 필요한 어려운 문제를 해결할 수 있는 사람들을 대체할 수는 없음.
  • 현재 수준에서는 "Vibe Coding"이 실제로 유용한 제품으로 이어지기 어렵고, 숙련된 개발자의 도움이 필수적임
  • "Vibe Coding"은 코드 작성의 보조 수단일 뿐, 완전한 대체 수단이 아님
▲
ifmkl 5일전  [-]

제가 AI로 취미활동에 제일 많이 이용하는게 웹게임 제작인데 동감합니다. 일정 이상 규모가 가면 어느 순간 AI가 집중도라고 해야 할 듯한 부분이 현저히 낮아지는 부분이 생기더라구요. 전 이걸 다음과 같은 방식으로 활용하는데, 게임내 전체 트리와 소스코드를 TOC를 포함한 하나의 파일로 합치고, 신규 스레드를 생성하면서 해당 파일을 업로드하고 작업을 이어갑니다. 그리고 질문을 할때는 항상 명확하게 현재 프로젝트의 명을 명시적으로 이야기 하면서 대답을 요구하죠. 그럼에도 불구하고 아직 불만족 스러운 부분들이 있지만.. 과거 현생에 바빠 엄두도 내지 못하던 취미생활을 상대적으로 짧은 시간으로 완성해나가고 있는 부분들은 너무 만족스럽습니다.

답변달기
▲
nicewook 4일전  [-]

"현재 수준" 이라는 부분에 눈이 갑니다. 인간의 시간 개념으로 LLM을 보고 있는게 아닐까요?

답변달기
▲
ng0301 5일전  [-]

AI랑 코딩하면서 느끼는점은, AI에게 코드 일부만 주어도 맥락을 이해할 수 있게끔 단일책임원칙 + TDD 느낌의 단위 쪼개기를 하다보면 큰 맥락을 읽을 필요 없는, 부분의 맥락으로도 충분하게 잡아줘야하더라구요

답변달기
▲
pcj9024 5일전  [-]

대충 만들고 나머지 디테일을 손보는 패턴이 참 좋습니다

답변달기
▲
psguny9 5일전  [-]

여러가지 시도를 하고 있지만 기억력의 한계는 분명 있습니다. PoC 수준으론 좋습니다. 빠르게 가능성/사용성 측면으론 좋습니다.

문젠 더더욱 숙련자가 필요함.

답변달기
▲
colus001 5일전  [-]

코딩에서 대부분의 시간을 보내는 것이 디버깅과 코드읽기 라고 볼때, 좀 과장이 심하다고 생각합니다. AI 만드는 사람들은 다들 이런 논조로 이야기 하지만, 적어도 현재 상황만 봐서는 그렇지 않은 것 같아요. 사람 손이 필요없는 상황에 이르면 굳이 코딩이 필요할까요? 그냥 API 설명을 넣어서 LLM 을 백엔드로 쓰는게 낫지.

답변달기
▲
reagea0 5일전  [-]

실제로 스키마설정해서 받아서 많이 그렇게 쓰기는 합니다.

답변달기
▲
nowdoit7 5일전  [-]

동감합니다. 초반엔 신비에 가까운 개발 속도를 보이지만, 규모가 커지고 파일이 많아 질수록 관리하는 책임자(여기서는 사람)이 이걸 효과적으로 관리하지 못하면, 덩치만 커지고 오류 투성이인 결과물만 받아보게 됩니다. 이미 손쓸 수 없는 지경까지 가면, 크래딧(윈드서프)이나, 리퀘스트(커서)만 낭비하게 됩니다. 점점 좋아지게 되겠지만, 지금은 AI코드를 100% 신뢰하면 안됩니다.

답변달기
▲
neo 5일전  [-]
Hacker News 의견

  • "AI 과장 vs. 현실"의 큰 차이는 사람들이 흔히 말하는 생산성 수치에 있음. 예를 들어, YC 파트너들이 한 회사가 코딩 성능에서 "100배 속도 향상"을 주장하는 것을 인용함. 이런 주장은 외부 관찰자에게 명백히 드러날 것이므로 자가 보고가 필요하지 않을 것임.

    • YC 여름 배치는 84일 동안 진행되며, 데모 데이로 끝남. 100배 속도 향상은 팀이 하루도 안 되는 시간에 데모 데이 수준의 기능을 가진 앱을 만드는 것과 같음. 만약 100배가 사실이라면, 파트너들은 새로운 배치가 "고객과 아침을 먹고, 새로운 것을 배우고, 영감을 얻어 같은 날 앱을 다시 작성하고, 그 결과가 데모 데이 수준의 기능을 갖추고 있다"고 말할 것임. 그러나 그런 이야기는 없으므로 100배는 부정확함.
    • 10배 향상이라도 파트너들은 "이번 배치에서는 사람들이 1주차에 데모 데이 수준의 앱을 프로덕션에 올린다"고 말할 것임. 파트너들은 팀이 얼마나 많은 일을 어느 기간에 완료하는지에 대한 큰 샘플 크기를 가지고 있음. 따라서 10배도 사실이 아님.

  • 현재 우리는 아웃소싱 열풍을 따라가고 있음. 모든 과장된 주장과 함께, 현실은 다름. LLM 코딩 에이전트에 대한 논의는 구별하기 어려움.

  • Go 커뮤니티가 컴퓨터가 인간 Go 플레이어를 이길 수 없다고 말하는 것과 같음. 이미 더 성능이 좋은 정렬을 찾는 모델의 예가 있음. 적절한 인센티브와 시간이 주어지면 컴퓨터가 우리를 이길 것임.

    • "Vibe coding"은 아직 현실이 아님. 경험과 기술로 실수를 수정하고 안내해야 함. 그러나 개선의 궤적을 볼 수 있음.

  • 코딩 LLM에 대한 새로운 문제점 공유. 오프쇼어 개발자들이 팀에 완전히 통합되어 있음. 그러나 LLM 사용이 무분별하고 산발적이어서 제출된 풀 리퀘스트가 악몽이 됨.

    • LLM을 사용하여 코드를 작성하는 데 도움을 받지만, 매우 신중하게 사용함. 시간 절약은 있지만 품질 향상은 아님. 올바르게 요청하는 방법을 알아내는 데 걸리는 시간, 출력 검증 시간, 작은 버그 수정 시간이 이점을 상쇄함.
    • "Vibe coding"을 하지 말고 직업을 잃지 않도록 주의해야 함.

  • "Vibe Coding"은 개념의 80%를 구현할 수 있음. 그러나 신뢰할 수 있고 안전하며 가치 있는 것을 만들려면 경험 많은 인간이 필요함.

    • 80%는 최선의 경우 개념 증명임. 80%는 QA가 바에 들어가는 것과 같음.

  • 최근 Claude와 OpenAI o3-mini를 사용하여 Matlab 코드를 Python으로 변환하려 했으나 성능이 매우 나빴음. 거의 모든 중요한 줄에 오류가 있었음. 자동화가 필요한 작업이지만 실패함.

  • "Vibe-TDDing"을 하면서 테스트가 없는 것보다 나음. 코딩과 테스트에 대한 이해가 있다면 LLM을 사용하여 부정적인 외부 효과를 줄일 수 있음.

  • SaaS를 구축하는 방법을 공유한 이후 이상한 일이 발생함. API 키 사용량이 최대치에 도달하고, 구독을 우회하며, DB에 랜덤한 것이 생성됨. 이것은 장난일 가능성이 있음.

  • 많은 엔지니어들이 AI 코딩 도구의 능력과 생산성을 과소평가하는 것을 보며 직업에 대한 안정감을 느낌. Cursor를 놓지 않을 것임.

    • AI 도구가 잘하는 것: 반복적인 코드 작성, 복잡한 DSA 작업, 단순하고 지루한 작업, 제한된 리팩토링
    • AI 도구가 잘 못하는 것: 제품/비즈니스를 코드에 매핑, 대규모 리팩토링
    • 코드 품질은 문제 아님. AI는 여전히 생산성 향상에 큰 도움이 됨.
답변달기