▲

나는 당신이 '바이브 코딩'할 때를 알아챌 수 있음

 (alexkondov.com)
6P by GN⁺ 3일전 | ★ favorite | 댓글 2개
  • 최근 팀 내에서 LLM이 생성한 코드임을 쉽게 알아차릴 수 있음
  • 이러한 코드는 프로젝트 컨벤션을 지키지 않으면서도 명확하고 테스트도 잘 되어 있음
  • 여러가지 기존 패턴이나 라이브러리를 무시하고 직접 새로운 구현을 함
  • 소프트웨어 개발에서 속도만을 추구하는 경향에 대한 우려가 커짐
  • 결국 중요한 건 품질과 일관성 그리고 유지보수 가능성임

바이브 코딩의 흔적

  • 최근 팀원이 작성한 코드 중 일부가 명확하고 기능적으로 완벽해 보이지만, 프로젝트 고유의 컨벤션을 지키지 않아 LLM이 생성한 것임을 바로 알 수 있음
  • 예를 들어, 이미 프로젝트에 있는 데이터 페칭 라이브러리가 있음에도 불구하고 모든 예외 케이스를 다루는 HTTP 요청 구현을 직접 작성함
  • 기존에 있는 모듈의 유틸리티 함수들을 반복해서 새로 만들거나, 모듈 단위 설정 변경 메커니즘이 있는데도 불구하고 전역 설정을 바꿈
  • 함수형으로 코드를 작성하는 문화가 정착되었음에도 클래스 기반 코드를 새로 작성함
  • 이런 코드는 사람이 몇 년 전에는 절대 작성하지 않았을 코드 스타일임

유지보수와 소프트웨어 원칙의 중요성

  • 소프트웨어 개발에서는 오랜 시간 유지보수 가능한 패턴과 표준을 정립하는데 노력을 투자해 왔음
  • 실제로 동작만 하는 코드는 누구나 만들 수 있지만, 장기적인 관리와 수정이 쉬운 코드가 진정한 도전임
  • 기능 구현 자체가 아니라, 시간이 지나도 유지할 수 있는 코드베이스가 관건임
  • “바이브 코딩”은 이러한 철학과 기준을 무너뜨릴 수 있음

속도를 최고의 선으로 여기는가?

  • 커피숍에서 신규 바리스타가 서두르다가 커피를 엎지르는 광경에 비유해, 속도에 대한 집착이 올바른 결과를 가져오지 않음을 강조함
  • 요즘 개발팀도 마찬가지로 너무 빠르게 새로운 소프트웨어를 만들려고 하다가 품질 저하가 발생함
  • 사람들이 원래 원하는 것은 약간 더 기다리더라도 제대로 된 결과물임
  • 원래 속도만을 챙기는 건 비개발 직종의 문제라고 생각했으나, 동료 개발자들도 원칙을 버리고 속도만을 추구하는 현실에 실망감을 느낌

진정으로 원하는 것

  • 코드를 IDE에 어떻게 집어넣었는지는 상관하지 않음
  • 중요한 것은 개발자가 품질에 신경쓰는 태도임
  • LLM이 대단한 기술적 혁신임은 인정하지만, 여전히 실제 소프트웨어를 만드는 책임은 개발자에게 있다는 점을 강조함
  • “더 나은 프롬프트 작성”, “올바른 라이브러리 지정”, “예제 제공”, “작은 파일 단위로 작업” 등 구체적인 기존 원칙을 알고 활용할 것을 권유함
  • 코드 품질과 유지보수성을 모델의 ‘가중치’에만 맡기지 말 것을 당부함
▲
GN⁺ 3일전  [-]
Hacker News 의견

  • 아무도 이미 프로젝트 내에 있는 데이터 페칭 라이브러리가 모든 예외 케이스를 커버하고 있다면 HTTP 페칭 구현을 새로 만들지 않음, 이미 존재하는 유틸리티 함수 모듈이 있는데 굳이 새로 구현하지 않음, 전역 설정을 개별 모듈에서 할 수 있는데도 변경하지 않음, 그리고 함수형 방식을 주로 쓰는데 클래스를 새로 만들지 않음 이런 팀에서 일해보고 싶음, 하지만 실제로는 많은 개발자들이 이런 것들을 자주 반복해서 하고 있음

    • 솔직히 말해서, 대형 프로젝트에서 문서화가 부실할 경우 위와 같은 일들이 정말 쉽게 일어남, 내가 일하는 학술 연구 프로젝트의 코드 문서는 코드 자체가 셀프 다큐멘테이션 수준이라고 하고, CMake 설정이나 빌드, 벤치마크 방법 정도만 짧게 언급되어 있음, 내부 규칙이나 관례 같은 건 직접 겪으면서 알아내야 함, 새로운 사람이 오면 이미 구현된 기능을 다시 만들거나 전역 설정을 바꿔버리는 일이 잦음, 결국 코드베이스를 인덱싱하고 LLM에게 직접 묻는 게 최선임(프로젝트 주요 인력들이 떠나거나 한참 뒤에나 답장이 옴)

    • 저자의 요점을 놓치고 있다고 생각함, 만약 속도가 최고의 덕목이라면 그런 일들은 계속 반복됨, 속도가 절대적인 가치라면 생산량이 기하급수적으로 늘어나야 기술 부채를 상쇄할 수 있음, 속도 외에 다른 요소도 중요하다면 현명하게 부채를 관리하고 갚아야 함, 하지만 요즘엔 그냥 부채를 크게 안고 어떻게든 되겠지 하는 느낌임, 그리고 많은 사람들이 실제로 부채 관리에 서툼

    • 기회만 있으면 바퀴를 매번 재발명하고, 예상되는 관례를 무시하거나 혼합된 패턴을 쓰는 경우가 많음, 저자는 이런 걸 'vibe coding'이라고 부르겠지만, 사실 LLM만의 문제가 아니라 누구나 급하게 결과만 내려고 하거나 경험이 부족할 때 다 일어나는 현상임, '팀의 어느 누구도 그렇게 쓰지 않을 코드'라는 표현을 보면 누군가 특정인을 겨냥한 불만일 가능성이 있음, 이런 시각을 다른 곳에 적용하는 건 신중해야 함

    • ORM 라이브러리를 추가로 넣는 개발자도 봄, 첫번째 ORM이 충분한데 '요즘 핫하다'는 이유로 두번째를 넣는 경우임, 개발자든 LLM이든 각자의 편향을 가지고 있음, 프로젝트 내 규칙이나 패턴을 숙지하고 그 틀 안에서 작업하는 건 굉장히 중요함, 문맥 고려 없이 자기 방식대로 만드는 건 매우 위험함, 사람의 경우 코드 리뷰 문화와 코드 읽기를 장려하는 것으로 해결할 수 있지만, LLM의 경우 모든 패턴과 규칙을 명확히 가이드해야 함, 그렇지 않으면 프로젝트와 어긋나는 코드를 만들 위험이 높음, 중요한 것은 가치관과 명확한 기준을 명시적으로 설정하는 것임

    • 내가 그런 좋은 팀에서 일해본 경험이 있음, 작은 규모(2-4명)로 운영되는 중요도 높은 프로젝트가 많았음, 이런 환경에선 품질과 속도를 균형 있게 맞추는 개발 문화와 합의를 만드는 게 쉬움, 그런 팀에선 누구든 사람이든 LLM이든 위와 같은 코드엔 절대 PR을 승인하지 않음

  • 개인적으로 LLM을 아주 주니어 개발자라고 생각함, 일은 잘 하려고 하고 지시를 따르지만, 코드베이스와 패턴 이해도가 부족함, 모든 과정을 직접 안내해야 하고 잠재적 오류까지 설명해줘야 하며, 구체적이고 작은 단위의 작업을 부여하고 코드를 꼼꼼히 검토해야 함, 나처럼 데이터 모델을 먼저 머리로 그려보고 그 다음 코드에 들어감, 구체적 설명이 중요함, 한 가지 불문율은 항상 파일 상단에 블록 주석을 넣어서 파일의 내용을 설명하게 함, 이건 세션 재시작 시 두 번째 프롬프트 역할을 함, 이 방식이 '마법같다'는 느낌 없이 좋게 돌아가지만, 중간에 30% 정도는 코드 정리, 리네이밍, 리팩터링을 해야 보기 좋은 수준이 됨, 그래도 LLM이 있어서 완전히 손으로 짜는 것보다 훨씬 빠르게 일할 수 있음

    • "주니어 개발자" 또는 "코파일럿"이라는 표현이 LLM의 장점과 단점을 모두 제대로 반영하지 못할 때가 있음, 일반 사람과 달리 쉽게 망각하고 아주 기초적인 실수를 하기도 하지만, 나보다 더 잘하는 부분(예를 들면 배열 관련 오프바이원 이슈 같은 것)도 있음, 그리고 인터넷상의 거의 모든 것을 백과사전적으로 알고 있음, 직접 써 본 결과 LLM은 사냥개와 비슷하다는 생각이 듦, 주인이 사냥을 주도하고 직접 마무리해야 함

    • LLM과 주니어 개발자의 차이점은 학습 능력에 있음, 주니어는 점점 배우며 성장할 수 있지만, LLM은 그렇지 않음, 프롬프트에 지시를 많이 넣을수록 더 많이 까먹고 일반적인 답변으로 돌아가버릴 확률이 높음, 프롬프트가 새로 시작될 때마다 처음부터 다시 안내해야 함

    • LLM은 인터넷에서 코드를 검색해서 복붙하는 것과 큰 차이가 없다고 느낌, 결국 개발자가 코드를 직접 점검해서 잘 동작하는지 확인해야 함, 최근에는 눈 건강 때문에 20분 단위로 작업하고 쉬어야 해서 효율이 더 중요해졌음, LLM은 인간보다 코드 생성 속도가 월등히 빨라서 기본적인 영역만 처리하게 해도 큰 이점임, 현재 Unity C#과 LINQ로 SIMD용 구조체를 생성하고 있는데, 단순히 LLM에게 원하는 조건을 말하면 직접 복붙하는 것보다 훨씬 빠르게 원하는 코드나 문자열을 얻을 수 있음, AI를 HUD처럼 쓰는 개념이 실감남, 전체 프로그램을 만드는 AI보다 작은 단위의 강력한 개발 보조 도구가 필요함

    • 나한테 LLM은 StackOverflow보다 훨씬 괜찮은 대체재임, 궁금한 걸 바로 물으면 정확하게 대답해줌, 대답을 참고해서 내 코드로 재작성하거나 함수만 생성하기도 함, 복사하기 전에 반드시 코드를 완전히 이해하려고 함, 때때로 40만 라인의 PR을 잘 모르는 언어로 오픈소스 프로젝트에 올리는 게 솔직하고 품질 지향적으로 일하는 것보다 커리어에 더 이익이 되는 게 아닌가 고민한 적도 있음, 실제로는 연차(Years of Experience)가 스킬보다 더 중요하게 평가되는 현실 때문임

    • LLM에게 성공적으로 작업시키려면 생각이 아니라 실제 코딩 단계로만 한정하는 게 좋았음, 태스크를 세분화하고 구체적인 스펙, 수정 파일, 참고 예시 위치 등까지 최대한 상세히 전달해야 적용률이 높음, 너무 세세할 필요는 없지만, 단서가 많을수록 성공 확률이 높음, 만들어낸 코드도 git add -p로 한 덩어리씩 직접 확인함, 준비와 검토에 시간이 들지만, 혼자서 다 짜거나 엉성한 코드를 그대로 두는 것보단 확실히 시간과 에너지를 아낄 수 있음

  • Vibe coding의 가장 큰 위험은 실력 좋은 개발자가 조금 빨라지는데 그치지만, 실력 부족한 개발자는 훨씬 더 빠르게 많은 나쁜 코드를 생성하는 현상임, 문제는 그런 개발자들이 vibe coding을 통해 실력이 늘 수 있는지 아니면 그냥 거기서 정체되는가임

    • 경험상 mediocore(평이한) 개발자도 아주 빠르게 나쁜 개발자가 될 수 있음, 이유는 잘못된 자신감과 코드 생산량 급증임, AI가 만든 코드는 전체적인 아키텍처나 정보 흐름, 단일 책임 원칙에 대한 고려가 거의 없음, 안전한 코드를 만들기 위해 예외 대신 placeholder를 반환하는 식으로 구성됨, 호출 코드는 결과값이 placeholder인지 아닌지 매번 체크해야 함, 애초에 인풋 파라미터가 좋지 않으면 AI가 알아서 고치려고 해서 gather_parameters → call → process_results 구조를 무시함, 그리고 테스트까지 가면 문제는 훨씬 더 커짐

    • 이제 많은 개발자들이 net-negative programmer(존재 자체가 프로젝트 품질을 떨어뜨리는 개발자)라는 개념을 재발견하게 될 것임

  • 내가 볼 때, 여기서 가장 부족한 자원은 애정(caring)임, vibe coding 자체가 애정 결여의 원인이 아니라, AI는 그냥 도구임, 저자가 말한 모든 이슈는 인간 주니어 개발자와 동일하게 적용되고 좀 더 잘 가이드하거나 소통하면 개선할 수 있음, AI 때문에 품질에 대한 관심이 감소한다고 보진 않음(원래 관심 없는 사람은 예전부터 그랬음), 흔히 반박으로 '주니어 양성 기회를 놓친다'고 하는데, 여력이 없어서 AI를 임시방편으로 활용하는 경우도 많음(채용이 잘 안 되는 내 스타트업도 마찬가지임), AI 도구로 인해 소프트웨어 품질 기준이 달라질 수 있는데, 이 부분은 앞으로 더 변화할 여지가 많다고 생각함

  • LLM이 현재 상태만이 아니라 과거 커밋 내역까지 문맥으로 활용해야 함, 많은 코드베이스가 패턴 A에서 B로 점진적으로 마이그레이션하고 다양한 패턴이 공존함, 마이그레이션이 한 번에 이루어질 수 없어서 보통 오래된 것과 최신 것이 계속 섞여 있음, HTTP 예시처럼 LLM이 패턴을 인식해도 어떤 걸 따라야 할지는 운에 달림

    • 20년 넘게 합병과 이름 변경, 인수 등을 겪은 대형 코드베이스에서 일한 적 있음, 아주 오래된 API 호출 예시가 남아 있고 실제로는 더 최신 코드가 따로 존재하지만, 특정 고객을 위해 남겨둔 게 많음, 문서가 전혀 없는 유사 API도 많아서 어떤 걸 써야 내가 원하는 데이터를 받을지 일일이 찾아야 함

    • CLAUDE.md 같은 파일로 "이 패턴은 따라라, 저건 피하라" 명확히 안내하는 것도 한 방법임

    • 그보다는 각 부분별 작업 방식, 예시를 아주 구체적으로 알려주는 게 더 효과적임

    • 문제는 이런 문맥 인식력 자체가 vibe coding을 하는 사람에게는 많이 부족하단 점임, 많은 사람들이 LLM 이전에 코딩 경험이 부족함

    • 커밋 메시지가 제대로 작성됐을 때만 이런 게 가능함, 실제로는 "이 파일 수정", "버그 수정" 등의 메시지가 대부분임

  • LLM을 활용할 때 린터, 포매터, 엄격한 타입 체크 같은 자동화 툴이 매우 큰 도움을 줌, 특히 코드 스타일이나 암묵적인 규칙을 모르는 사람(또는 LLM 에이전트)에게서 코드 기여가 들어올 때 자동화된 방식으로 코드를 검사하고, 가능한 건 바로 고칠 수 있음, 테스트도 마찬가지임, 자동화된 검증 체계는 인간이든 에이전트든 품질 유지에 매우 유용함

    • 그런 도구들이 실제로는 기사에서 언급한 vibe coding 사례 중 대부분을 막지는 못한다고 생각함

    • 이런 도구들은 문제를 가린 채 표면만 깔끔하게 만들어주는 경우도 있음

  • 모든 주요 AI assistant들은 이미 이런 문제를 완화할 방법을 기본적으로 탑재하고 있음, Claude Code의 /init, Cursor의 /Generate Cursor Rules 등, 단순한 context engineering보다 더 자동화된 방식으로 조직 전체에 적용할 수 있음, 결국 이런 도구들이 개발 커뮤니티를 어떻게 나누는지도 흥미로운 이슈임

    • 실제로는 CLAUDE.md에 아무리 명확하게 정해도 CC(Claude Code)가 무시하는 경우가 많음, 대화가 이어질수록 같은 문제를 반복하는 느낌이고, 아직까지 완전히 만족스러운 해결책을 못찾았음, 그래서 이 아티클을 단순한 AI 반대 논조로 치부하는 건 옳지 않다고 봄

    • Cursor를 다시 평가 중임, 기대만큼 속도를 내지 못하는 이유는 사소한 오류들(LM이 ":"를 ","로 바꾸는 것 등)뿐만 아니라, 코드베이스가 너무 크고 낡고 품질 편차가 커서임, LLM은 결국 가장 흔히 쓰이는(= 안 좋은) 패턴을 더 자주 차용함, 명확하게 "이 부분을 참고해라"라고 지시해도 전체 코드베이스 전반에 영향을 받음, 룰(rule)로 지정해도 프롬프트에 직접 박아넣은 것과 크게 다르지 않은 것 같음, 해결책이 있는지 궁금함

    • 문제의 핵심은 도구가 아니라 vibe을 중시하는 '코더'임, 애정도 없이 코드 작성도 헐렁함

  • 내 경험상 거의 모든 이슈는 한정된 컨텍스트 윈도우와 서브옵티멀한 'context engineering'의 결과임, LLM이 전역 함수 등 중요한 맥락을 제대로 전달받으면 비교적 잘 활용함, 문제는 어떤 맥락을 끊김 없이 계속 유지하며 제공하느냐임, 앞으로 sub-agent 같은 형태로 이 부분에서 많은 발전이 있을 것으로 기대함

    • "에이전트가 전역 함수 설명을 알고 있으면 잘 쓴다"라고 했지만, 사실 '에이전트'라는 존재는 없고, 그저 입력과 출력을 연결하는 수학적 함수에 불과함, LLM을 인간에 비유하는 건 부정확함, 인간과 기계는 전혀 다름

  • 이 모든 내용이 맞다고 생각함, LLM을 활용할 때 가장 좋은 방법은 컴파일러가 어셈블리보다 한 단계 높은 수준을 제공하는 것처럼, 요구사항과 입출력을 명확히 설명하면 논리적 번역으로 코드를 만들어줌, 그렇기 때문에 입력에 혼란(엔트로피)를 최소화해야 함, LLM은 본질적으로 translation engine임, '생성'이 아니라 '번역'하는 데 써야 더 효율적임, 그럼에도 불구하고 주기적으로 더 스마트하고 직관적으로 진화하는 모델이 나오고 있고 그만큼 신경 덜 써도 결과가 좋아짐, 결국 언젠가는 LLM이 어떤 태스크든 인간 개발자보다 나은 결과를 내는 시대가 올 것이며, 인간의 다른 역할도 마찬가지일 것임

    • 잘못된 비유임, LLM은 자연어를 고수준 코드로 '컴파일'하는 엔진이 아님, 프로그래밍 언어와 머신 언어는 명확하고 일관된 의미 체계를 요구하지만, 자연어는 애초에 추상화 계층이 다름, 같은 LLM도 새로운 시드값이나 버전에서는 다른 결과가 나올 수 있음, 반면 컴파일러는 항상 같은 입력이면 반드시 같은 출력을 내야 함

    • LLM이 컴파일러 같은 추상 계층이라는 건 동의할 수 없음, 실제로 LLM은 그저 임의의 토큰 생성기임, LLM을 이용해서 만든 결과물 중 제대로 쓸 만한 것을 본 적이 없음, 싱귤래리티나 데이터 무한확보 같은 테크노 낙관론은 현실적 근거가 부족함, 결국 고품질 데이터 확보는 엄청나게 비용이 드는 일임, 현재로선 희망적 예측은 무의미함

  • "많은 사람들이 좋은 커피보단 빠르고 싼 커피를 더 원한다"는 걸 저자보다 더 늦게 이해했음, 현실에서 다수는 품질보다는 속도와 가격을 중요하게 여김

    • Keurig 커피머신의 유행만 봐도 그 경향성을 알 수 있음
답변달기
▲
dkmin 2일전  [-]

본문보다 HN 글이 더 달달함

답변달기