▲

Vibe 코딩은 버스 팩터를 0으로 만든다

 (mindflash.org)
20P by GN⁺ 3일전 | ★ favorite | 댓글 3개
  • 소프트웨어 개발에서 Bus Factor는 특정 지식 보유자가 몇 명이나 있어야 프로젝트 유지가 가능한지를 나타내는 개념으로, 기존에는 최악의 경우 값이 1이었음
  • 그러나 ChatGPT 공개(2022년 11월 30일) 이후, 생성형 AI가 대중적으로 채택되면서 많은 이들이 지식을 직접 보존하지 않고 AI에 의존하며, 사실상 버스 팩터 0의 상황이 발생함
  • 프로그래밍 현장에서는 점점 더 많은 개발자가 LLM이 생성한 코드와 기능을 그대로 사용하며, 코드베이스를 이해하려는 노력을 포기하고 “바이브 코딩(vibe coding)”으로 전환함
  • 이로 인해 버그 수정, 보안 패치, 기능 확장 시, 누구도 코드가 왜 그렇게 작성되었는지 모르는 상황에 직면할 수 있음
  • 이는 소프트웨어 신뢰성과 보안에 심각한 위험을 초래하며, AI가 완벽한 코드를 완벽히 생성하는 날이 오기 전까지는 근본적 한계가 존재함

버스 팩터 개념과 역사

  • 버스 팩터는 특정 지식이 몇 명의 사람에게 공유되어 있는지를 수치로 표현한 개념임
    • 예: 3명이 데이터베이스 백업을 복구할 줄 알면 해당 기능의 버스 팩터는 3임
  • 전통적으로 최악의 값은 1이었으며, 한 사람이 지식을 잃으면 프로젝트 유지가 불가능했음
  • 인류는 이를 극복하기 위해 문서화, 교육, 지식 이전, 세미나, 학교 등 수많은 방법으로 지식을 전파
    • 수많은 인적 자원과 시간을 투입해 지식을 전승하고 보존하는 체계적 시도로 이어져 왔음

AI 도입과 버스 팩터 0

  • 2022년 11월 ChatGPT 출시로 “AI First” 시대가 열림
  • AI가 코드와 기능을 생성하는 과정에서 많은 사람들이 지식 보존의 주체에서 배제되고 AI 생성물에 의존하기 시작하며 프로젝트 이해도가 급격히 낮아짐
  • 결과적으로 지식 보유자가 아예 없는 상태, 즉 버스 팩터 0의 상황이 발생함
  • 프로그래머들은 코드와 기능을 스스로 작성·이해하지 않고, AI에게 완전히 위임하는 흐름을 보임
  • 이 과정에서 개발자들은 코드베이스 이해와 문서화를 회피하고 단순히 AI에 설명을 재요청하는 패턴으로 변화함

LLM 기반 코딩의 문제

  • 코드 품질 문제는 차치하더라도, 읽기와 유지보수는 본질적으로 작성보다 더 어렵다는 점이 핵심임
  • 과거에는 멘토나 문서가 최소한의 도움을 제공했지만, AI 의존 환경에서는 이런 안전망조차 사라짐
  • LLM 기반 개발에서는 코드 생성 과정이 기록되지 않고, AI조차 자신이 생성한 코드의 맥락을 기억하지 못함
  • 결국 개발자들은 AI가 작성했지만 맥락이 불명확한 코드를 분석하고 수정해야 하는 상황에 놓임
  • 이는 버그 해결, 보안 취약점 패치, 종속성 업그레이드 등에서 누구도 코드의 의도와 구조를 알 수 없는 상태를 초래

사용자 관점에서의 위험

  • 개발자뿐 아니라 사용자도 위험에 노출됨
    • 개인 문서, 신용카드 정보, 사적인 사진이나 생각 등을 업로드하는 소프트웨어가 내부 구조와 목적을 아무도 모르는 코드로 만들어 졌을 수 있음
  • 이는 데이터 보호와 신뢰성 측면에서 심각한 리스크를 내포하며, 서비스 안정성에 대한 의문을 불러일으킴

결론

  • 버스 팩터 0을 초래하는 바이브 코딩은 근본적으로 결함이 있는 접근임
  • 이는 AI가 100% 정확한 코드를 100% 정확한 프롬프트로 생성할 수 있을 때까지는 피할 수 없는 한계임
  • 따라서 현재 상황에서는 AI 활용과 더불어 지식 보존과 코드 이해의 중요성을 간과할 수 없고, 지식 관리 및 문서화 체계를 유지하는 것이 필수적임
▲
iolothebard 14시간전  [-]

버스팩터가 무한대가 된거 아닌가요?

답변달기
▲
cdwdong2 3시간전  [-]

회사 소속 개발자가 지식이 없으면 버스팩터는 0에 수렴하죠

답변달기
▲
GN⁺ 3일전  [-]
Hacker News 의견

  • LLM을 사용해서 리뷰되지 않은 방대한 코드를 그냥 뽑아내는 건 잘못된 활용 방법임, 그런 프로젝트는 구조적으로 잘못된 방향으로 가거나 복잡한 버그가 생기면 곧 유지보수가 불가능해짐을 의미함 LLM의 진짜 강점은 다음과 같은 상황임: 기존 복잡한 데이터 구조에 유명 알고리즘을 적용해야 할 때, 테스트 데이터나 의존성이 많은 단위 테스트 뼈대를 세울 때, 시각적 웹 에디터와 백엔드 API를 만들며 sqlite에 저장하는 기능을 붙일 때, 복잡한 정규표현식으로도 어려운 반복 작업을 대규모 코드베이스에 적용할 때 등임 실제로 LLM 덕분에 반나절, 3일 걸릴 일도 2분 만에 시작할 수 있음 중요한 건 LLM이 아주 어려운 문제를 못 풀어도 생산성은 대폭 오를 수 있다는 점임 지루한 반복 작업에서 해방되어 더 흥미로운 문제에 집중할 수 있음

    • 반복적인 변경 작업을 대규모 코드베이스에 적용할 때 LLM이 2분 만에 끝낼 거라 생각했는데 직접 여러 대형 모델로 실험해보니 컨텍스트가 복잡해질수록 에러가 누적되고, 관련 없는 변경도 가끔 발생해 결과적으로 신뢰할 수 없었음 소규모 예시에는 완벽하지만 규모가 커질수록 미흡함 agentic loop를 써서 개선할 수 있지만 반복적으로 수행/리뷰하며 결국 시간이 훨씬 더 들어감 LLM에게 변경 작업을 자동화해주는 프로그램을 작성하게 하는 게 훨씬 신뢰도 높음

    • 제시된 예시들 모두 좋아 보이긴 하지만, 실제로 가능한 활용 예시는 훨씬 더 많음 당신은 숙련 개발자만의 사례를 말했지만, 기술력이 부족하거나 막 배우는 입장의 사람들도 LLM 덕분에 할 수 있는 일이 많이 늘어났음 100달러를 주고 해야 했던 일을 3분 만에 스스로 해볼 수 있게 됨 결과물이 완벽하고 유지보수 가능하냐는 오히려 중요하지 않게 됨, 가능성을 보여주는 것이 더 큰 가치를 가짐

    • 당신의 의견에 동의하지만, 최근에 웃겼던 경험을 공유하고 싶음 Claude에게 단위 테스트 작성을 부탁했는데, 리뷰 결과 실제로 나의 코드에 버그가 있었고 그걸 테스트가 찾았음 그런데 Claude는 버그를 수정하는 대신 해당 실패 테스트를 아예 실행하지 않음으로써 통과시키려 했음, 현실의 유쾌한 에피소드임 LLM이 요구사항 정의, 아키텍처 설계, 요구사항에 맞는 명세 작성에는 약하고, 코드 작성처럼 범위가 명확하고 영향이 제한된 일에는 강점이 있음

    • AI가 PR 리뷰를 자동으로 한 뒤 수동 리뷰를 하는 식으로 중간 단계를 적용해봤음 코드 생성에는 5~10분, 리뷰와 추가 커밋에는 보통 1~3시간 걸리지만, 여러 프로젝트(10~20k LOC, 약 100 파일 규모)에서 이 방식으로 성공적으로 적용했음 명세를 잘 주면 다수의 기능은 큰 수정 없이 거의 정확히 구현되고, 피드백 기반 리팩토링이 주로 발생함 물론 제대로 동작하지 않을 때는 해결에 하루 가까이 소요되는 경우도 있지만, 전체적으로는 3~5배 생산성 향상임 대규모 프로젝트에는 조각내어 모듈화하는 게 더 좋아 보임

    • "LLM으로 2분 만에 x일치 작업 완료"라는 식의 표현은 리뷰 시간이 포함되지 않았기 때문에 조금 과장임 실제 리뷰와 검수 과정까지 합치면 시간이 훨씬 더 걸림 처음에 이야기한 “잘못된 방법”에 오히려 빠질 수 있음

  • 이 글에서는 AI 코드 생성의 문제점은 여러 개 제시하지만, 이미 존재하거나 앞으로 등장할 수 있는 해결책은 고려하지 않은 듯함 예전에도 팀이 코드베이스에 대해 최소한의 노력만 했어도, 새로 들어온 사람이 코드를 이해하는 데 도움을 받을 수 있었음 레거시 코드 경험이 없는 건 아닌지, 아니면 AI가 "처음 작성 과정에 대한 모든 맥락을 잊어버린다"라는 점에 대해 정말 못 고친다고 생각하는지 의문임 Bus Factor 0 문제도 100% 완벽하게 정확해야만 해결되는 걸로 오해하는데, 사실 사람도 100% 항상 정확한 건 아니지만, 그래도 신뢰함

    • 해당 글이 너무 축약적으로 문제를 바라본다고 느꼈음 우리는 애초에 모든 일을 작성자와 함께 할 수 없다는 현실 자체가 이미 존재함 짝궁이나 설명해주는 AI의 존재만으로도 엄청난 진전임 인간이 없는 세상을 상상하는 것 같지만, 이미 우리는 그런 상황을 종종 겪고 있음

    • 나는 저자임, 첫 번째 지적에 동의하고, AI가 앞으로 격차를 좁혀줄 거라고 생각함 하지만 그때쯤이면 이미 일부 문제는 발생해버렸을 수 있음 논리적 맥락이나 조작 기록이 없는 코드가 남게 되는 문제도 있음 AI가 "항상 학습한다"는 얘기가 많지만 실제론 새로운 모델이 나오기 전까진 배우지 않음 사람도 100% 정확하진 않지만 Bus Factor 0은 아님, 문제 파악과 해결이 더 쉬움 나머지 문제도 해결된다면 버스 팩터 문제도 줄어듦

    • 과거 레거시 코드 분석할 때 AI 툴이 있었으면 좋았겠다고 생각함 "이 Perl 파일 마지막 작성자가 이제 지점장인데, 직접 미팅 예약해야 하나?" 같은 황당한 상황이 실제로 있었음

    • "왜 100% 정확해야 하는가?"라는 질문엔, AI에 비판적인 사람들은 오히려 AI가 마법처럼 완벽한 해결책이길 기대하는 경향이 있다고 생각함 정적 타입을 반대하는 사람이 "논리적 에러까지 못 잡는다"며 불평하는 것과 비슷한 뉘앙스임

  • 요즘 블로그마다 AI가 만든 이미지가 너무 많아져서 오히려 집중에 방해되고, 내용에 도움이 안 되는 경우가 많은 것 같음

  • 최근 엉망인 코드베이스가 있는 팀에 합류했는데, 기존 개발자들도 대부분 떠났고 남아있던 사람들도 코드를 잘 몰랐음 완전히 버스 팩터 0임 놀랍게도 AI 덕분에 코드 이해와 의도 파악, 디버깅 속도 등이 크게 개선되었음 AI로 코드 자체에서 문서를 뽑아내기 시작함 문서화나 구전은 왜곡될 수 있는데, 코드는 그 자체가 진실임 AI의 도움으로 코드가 스스로 설명하는 환경을 만들 수 있었고 큰 생산성 향상을 느낌

    • 나는 관리자 입장에서, 이제부터 우리 팀의 모든 readme가 구식이 되지 않도록 한 가지 규칙을 정하려고 고민 중임 Claude Code에게 기존 readme와 최신 코드, PR 변경 사항까지 읽도록 하여 필수적으로 readme를 갱신하게 할 수 있다고 생각함 물론 완벽하지 않지만, 요약이 타당한지 개발자가 최종 검수를 해야 하며, readme가 구식이 되는 원인이 '귀찮음'에서 비롯되는 현상을 AI가 상당히 줄여줄 수 있음

  • LLM 등장 전에도 Bus Factor는 항상 문제였음 대부분의 회사가 일의 일부를 여러 명이 이해하도록 구조화하지 않았음 여러 사람이 각 영역에 배정되어 있어도 일의 양이 계속 늘어나 최종적으로는 아무도 다 이해하지 못하는 상황이 반복됨 이를 완전히 피하려면 코드베이스 내 인원을 로테이션시키는 등 엄청난 엔지니어링 관리가 필요하고, 대개는 속도에 대한 요구 때문에 완벽히 못함 이와 관련된 내 CTO 경험 회고를 여기에서 책으로 정리해서 가격 상관없이 공개함 LLM으로 시스템을 만든 환경과 10명의 외주 개발자를 쓰는 환경의 원리는 별반 다르지 않다고 생각함

    • Bus Factor는 LLM 이전에도 문제가 됐고, 오래 전부터 있어온 전문 용어임 TFA(원문)는 이전에는 Bus Factor가 1이었고, 이제는 아예 0으로 가고 있다는 추세를 비판하는 것임

    • 일의 양이 커질 뿐이지, 실제로는 더 권장할 만한 방향으로 일이 진행되는 게 아니라 마감에 맞춰서 대충 끝내는 패턴만 반복됨 절차상 몇몇 장애물을 두는 걸로는 해결되지 않음

  • 우리의 두뇌는 자주 쓰지 않는 정보에는 에너지를 아끼려고 하기에 뭔가로부터 멀어질수록 더 잘 못 이해하거나 잊어버리게 됨 직접 코드 리뷰를 다 해도 결국 실력이 퇴화할 수 있음 엔지니어가 관리자 업무를 오래 하면 기술적 문제를 거의 못 풀게 되는 것과 비슷함 자동차 자동화에서도 중간 단계(level2→5)를 인간이 계속 관여하며 유지하는 게 어렵고, 기계가 100% 신뢰 가능하지 않으면 결국 문제가 됨

  • 이 논의에서 정말 중요한 포인트가 있는데, 사실 이런 툴과 워크플로는 이제 막 시작 단계임 앞으로 이런 문제를 AI가 인간보다 더 잘 풀 수도 있다고 확신함 LLM을 활용하는 실험도 해봤는데 일부 성공, 일부 실패였지만 특정 분야에서는 확실히 뛰어난 능력을 보여줌 LLM은 귀찮아하지 않고 문서나 주석, README, ADR까지 꼼꼼히 업데이트해줄 수 있음 충분한 가이드와 구조만 있으면 LLM 코드베이스가 장기적으로 오히려 더 진입하기 쉬울 수도 있음, 그만큼 문서화가 우수하기 쉬움

    • 굉장히 중요한 포인트이긴 한데, 사실 이제 이런 툴의 끝에 와 있기에 이 문제들이 해결 불가능하다고 보는 입장임

  • 글은 코드 그 자체로도 의도를 상당 부분 읽어낼 수 있다는 점을 간과하고 있다고 생각함 인간은, 그리고 LLM도 그렇겠지만, 꽤 예측 가능한 존재임 대개 비슷한 문제를 비슷한 방식으로 해결함 코드가 어떻게 작성됐는지 보면, 왜 누가 언제 어떤 문제를 풀었는지에 대한 힌트를 알 수 있음 물론 정보가 감춰지는 부분도 많지만, 구성원이 자주 바뀌는 조직에서도 비슷한 일이 일어남

    • 인간의 사고 과정이 결국 코드에 녹아 들어간다고 보지만, 그럼에도 불구하고 직접 물어볼 수 있는 사람이 있는 것보다 훨씬 열등한 과정임 리버스 엔지니어링은 꼭 필요할 때만 하는 게 보통인데, 레거시 코드에서는 결국 다들 하게 됨 하지만 생산성 면에서 좋은 건 아님 그리고 LLM 코드베이스는 단일한 의도가 아니라 여러 다양한 사람의 의도가 섞여 있어서, 일부 코드 조각만 봐서는 원래 취지가 무엇인지 오히려 더 혼란스러움 AI가 생성한 코드도 사람이 작성한 코드처럼 철저히 동일 의미를 지닌다고 착각하게 되어 오히려 해석이 더 힘들어질 수 있음

    • 의도를 코드만 보고 파악하는 능력은 범위와 규모에 따라 다름 아두이노처럼 32kB 제한이 있으면 이해는 쉬움 하지만 수십 개 마이크로서비스가 뒤엉킨 복잡한 플랫폼에서, 특히 그걸 'vibe coding'식으로 짜놓았다면 내 책임이 되면 그냥 포기하고 싶어짐

  • 이 글의 요점과 결론에는 동의하지만, 20년간 여러 번 비슷한 상황(아무도 질문할 수 없는 환경, 실제 담당자가 다 떠남)을 겪어봤음 LLM 덕분에 이런 일이 조금 더 빨라질 순 있어도, 완전히 새로운 문제라기보다는 예전 문제의 가속화에 가깝다고 생각함 이런 문제 의식을 환영함

    • 저자는 Bus Factor 0이 실제로 무엇을 의미하는지, 현실적으로 어떻게 도달하게 되는지에 대해 간과함 Bus Factor 0을 허용하는 회사는 단순히 전문성에 투자할 경제적 동기가 없는 회사임 인간이 AI와 경쟁하며 얻는 경제적 이득이 0이 되고, AI가 비용을 10배 절감하는 상황이 오면, 마케팅의 허위/과장과 통신 채널 혼선까지 더해져 문제는 명확해짐 수요와 공급의 원칙에서 보면 공급(전문가)이 무한대가 되어버리면 수요는 사라짐 인재 육성 파이프라인은 2~10년에 걸쳐서 만들어지는데, 성장 유인이 사라진 시점부터 미래에 심각한 위기가 도래함 실제로 지역 대학에서 컴퓨터공학 강좌가 학생 감소로 줄어드는 사례까지 있었고, 학생들은 AI 때문에 진로를 포기한다고 대답함 전문가 공급이 사라지면 고칠 사람도 돈 주고 살 수 없게 됨 경제의 토대를 건드리면 문제는 시차에 의해 뒤늦게 커지는데, 현실에선 충분히 빠르게 대처할 수 없음 결국 심각한 위기가 발생하고, 그때서야 극단 처방이 시작됨

  • 오히려 반대 상황도 있음 코드베이스를 AI가 잘 활용할 수 있도록 문서화, 테스트, 설정 등을 잘 해놓으면 1년 뒤에도 AI agent가 같은 작업을 더 빨리 해낼 거라 예상함

    • AI Coding Tool이 어떻게 기존 개발자처럼 "이전 코드는 다 별로이니 싹 다시 짜야 한다"는 태도를 취하게 될지 궁금함 앞으로 CI/CD 시스템 자체가 전체 프로젝트를 AI가 통째로 재작성하는 식이 될지도 흥미로움

    • 나는 저자임, 말한 대로라면 이미 Bus Factor는 올라가게 됨 즉, 정보가 머릿속에만 남지 않고 다양한 형태로 저장, 지속되는 것이 본질임

답변달기