왜 풀 리퀘스트가 아닌 이슈인가
VMark는 풀 리퀘스트를 수락하지 않습니다. 이슈를 환영합니다 — 상세할수록 더 좋습니다. 이 페이지는 그 이유를 설명합니다.
간단한 버전
VMark는 바이브 코딩되었습니다. 전체 코드베이스가 한 명의 관리자 감독하에 AI가 작성했습니다. 누군가 풀 리퀘스트를 제출할 때 근본적인 문제가 있습니다: 한 사람이 다른 사람의 AI가 생성한 코드를 의미 있게 검토할 수 없습니다. 리뷰어는 기여자의 코드를 이해하지 못하는데, 두 사람 모두 전통적인 의미에서 코드를 작성하지 않았기 때문입니다 — 그들의 AI가 작성했습니다.
이슈는 이 문제가 없습니다. 잘 작성된 이슈는 무슨 일이 일어나야 하는지 설명합니다. 그러면 관리자의 AI가 프로젝트의 규약, 테스트 스위트, 아키텍처에 대한 전체 컨텍스트로 코드베이스를 수정합니다. 결과는 일관되고, 테스트되고, 유지 가능합니다.
"바이브 코딩"이 실제로 의미하는 것
"바이브 코딩"이라는 용어는 Andrej Karpathy가 2025년 초에 자연어로 원하는 것을 설명하고 AI가 코드를 작성하게 하는 프로그래밍 스타일을 설명하기 위해 만들었습니다. 방향을 안내하지만 모든 줄을 작성하거나 종종 읽지도 않습니다.[1]
VMark는 이것을 대부분의 프로젝트보다 더 나아갑니다. 저장소는 다음과 함께 제공됩니다:
AGENTS.md— 모든 AI 도구가 시작 시 읽는 프로젝트 규칙.claude/rules/— TDD, 디자인 토큰, 컴포넌트 패턴, 접근성 등을 다루는 15개 이상의 규칙 파일- 슬래시 명령어 — 코드 감사, 수정, 검증을 위한 미리 만들어진 워크플로우
- 교차 모델 검증 — Claude가 작성하고, Codex가 감사합니다 (교차 모델 검증 참조)
AI는 단지 임의의 코드를 생성하지 않습니다. 코드베이스를 일관되게 유지하는 규약, 테스트, 자동화된 검사의 촘촘한 웹 안에서 운영됩니다. 하지만 이것은 하나의 AI 세션이 그런 제약에 대한 전체 컨텍스트를 가질 때만 작동합니다.
이해 격차
AI가 생성한 풀 리퀘스트의 핵심 문제는 아무도 완전히 읽지 않는다는 것입니다.
ACM 소프트웨어 엔지니어링 기초 컨퍼런스의 연구에서 개발자들 — 특히 코드를 직접 작성하지 않은 사람들 — 이 LLM이 생성한 코드를 이해하는 데 어려움을 겪는다는 것을 발견했습니다. "나였다면 다르게 코드를 작성했을 것이다": 초보자들은 LLM이 생성한 코드를 이해하는 데 어려움을 겪는다는 제목의 연구에서 기술적으로 유능한 개발자조차 AI가 작성했을 때 자신이 만들지 않은 코드에 대해 추론하는 데 어려움을 겪는다는 것을 문서화했습니다.[2]
이것은 초보자만의 문제가 아닙니다. CodeRabbit의 500,000개 이상의 풀 리퀘스트 분석에서 AI가 생성한 PR이 인간이 작성한 PR보다 이슈가 1.7배 더 많다 는 것을 발견했습니다 — 논리 및 정확성 오류가 75% 더 많은 것을 포함하여. 가장 큰 우려는? 이것들이 바로 코드를 단계적으로 따라가지 않는 한 검토 중에 합리적으로 보이는 오류입니다.[3]
두 측면 모두 AI를 사용할 때 수학은 더 나빠집니다:
| 시나리오 | 리뷰어가 코드를 이해? |
|---|---|
| 인간이 작성, 인간이 검토 | 예 — 리뷰어가 의도에 대해 추론할 수 있음 |
| AI가 작성, 원저자가 검토 | 부분적 — 저자가 AI를 안내하고 컨텍스트를 가짐 |
| AI가 작성, 다른 인간이 검토 | 나쁘게 — 리뷰어에게 저작 컨텍스트도 AI 세션 컨텍스트도 없음 |
| AI가 A를 위해 작성, AI가 B를 위해 검토 | 어떤 인간도 코드를 깊이 이해하지 못함 |
VMark는 마지막 행에 해당합니다. 기여자가 자신의 AI가 생성한 PR을 열고, 관리자의 AI가 그것을 검토할 때, 루프에 있는 두 사람은 어떤 시나리오에서도 가장 적은 이해를 가지고 있습니다. 이것은 품질 소프트웨어를 위한 레시피가 아닙니다.
AI가 생성한 PR이 인간 PR과 다른 이유
전통적인 코드 검토는 공유 토대 때문에 작동합니다: 저자와 리뷰어 모두 프로그래밍 언어, 패턴, 관용구를 이해합니다. 리뷰어는 코드의 실행을 정신적으로 시뮬레이션하고 불일치를 발견할 수 있습니다.
AI가 생성한 코드에서, 그 공유 토대가 침식됩니다. 연구에서 여러 가지 특정 실패 모드를 보여줍니다:
규약 표류. AI는 "저장소 내에 기존 규약이 무엇인지 이해하지 못하는 압도적인 경향"이 있어, 문제를 해결하는 방법에 대한 약간 다른 버전을 생성합니다.[4] 각 기여자의 AI 세션은 격리된 상태에서 작동하지만 프로젝트의 패턴과 충돌하는 코드를 생성합니다. VMark에서 특정 Zustand 스토어 패턴, CSS 토큰 사용, 플러그인 구조를 강제하는 곳에서 규약 표류는 파괴적일 것입니다.
컨텍스트 격리. 바이브 코딩된 기능은 종종 "AI가 각 프롬프트에 대한 합리적인 구현을 만들지만 이전 세션의 아키텍처 결정에 대한 기억이 없는 격리에서 생성됩니다."[5] 기여자의 AI는 VMark의 15개 규칙 파일, 교차 모델 감사 파이프라인, 또는 특정 ProseMirror 플러그인 규약에 대해 모릅니다 — 기여자가 그 모든 것을 고통스럽게 구성하지 않는 한.
검토 병목. AI를 사용하는 개발자들은 21% 더 많은 작업을 완료하고 98% 더 많은 풀 리퀘스트를 병합하지만 PR 검토 시간이 91% 증가합니다.[6] AI 코드 생성 속도는 인간 검토 용량을 압도하는 코드 소방 호스를 만듭니다. 혼자 관리하는 사람에게 이것은 감당할 수 없습니다.
SQLite 선례
VMark는 기여를 제한하는 최초의 프로젝트가 아닙니다. SQLite — 세계에서 가장 광범위하게 배포된 소프트웨어 라이브러리 중 하나 — 는 전체 역사 동안 "오픈 소스, 기여 개방 아님"이었습니다. 프로젝트는 인터넷의 임의의 사람들로부터 패치를 수락하지 않습니다. 기여자들은 변경 사항을 제안하고 개념 증명 코드를 포함할 수 있지만, 핵심 개발자들은 일반적으로 패치를 처음부터 다시 작성합니다.[7]
SQLite의 이유는 다릅니다 (공개 도메인 상태를 유지해야 합니다), 하지만 결과는 동일합니다: 품질은 전체 컨텍스트를 가진 단일 팀이 모든 코드를 작성함으로써 유지됩니다. 외부 기여는 직접적인 코드 변경이 아닌 버그 보고서와 기능 제안을 통해 채널됩니다.
다른 주목할 만한 프로젝트들도 유사한 입장을 취했습니다. 자비로운 종신 독재자 (BDFL) 모델 — 역사적으로 Python (Guido van Rossum), Linux (Linus Torvalds) 등이 사용 — 은 아키텍처 일관성을 보장하는 한 사람에게 최종 권한을 집중시킵니다.[8] VMark는 단순히 이것을 명시적으로 만듭니다: "독재자"는 관리자가 감독하는 AI입니다.
이슈가 더 잘 작동하는 이유
이슈는 구현이 아닌 명세서 입니다. 특정 솔루션에 커밋하지 않고 무엇이 잘못되었거나 필요한지 설명합니다. 이것은 기여자와 AI가 유지 관리하는 코드베이스 사이의 더 나은 인터페이스입니다:
| 기여 유형 | 제공하는 것 | 위험 |
|---|---|---|
| 풀 리퀘스트 | 이해하고, 검토하고, 테스트하고, 유지해야 하는 코드 | 규약 표류, 컨텍스트 손실, 검토 부담 |
| 이슈 | 원하는 동작 설명 | 없음 — 관리자가 행동할지 여부와 방법을 결정 |
훌륭한 이슈를 만드는 것
최고의 이슈는 요구 사항 문서처럼 읽힙니다:
- 현재 동작 — 지금 일어나는 것 (버그에 대한 재현 단계 포함)
- 예상 동작 — 대신 일어나야 하는 것
- 컨텍스트 — 이것이 왜 중요한지, 무엇을 하려고 했는지
- 환경 — OS, VMark 버전, 관련 설정
- 스크린샷 또는 녹화 — 시각적 동작이 관련될 때
이슈를 작성하기 위해 AI를 사용하는 것을 환영합니다. 실제로 권장합니다. AI 어시스턴트는 몇 분 안에 상세하고 잘 구성된 이슈를 구조화하는 데 도움을 줄 수 있습니다. 아이러니는 의도적입니다: AI는 문제를 명확하게 설명하는 데 탁월하고, AI는 명확하게 설명된 문제를 수정하는 데 탁월합니다. 병목은 흐릿한 중간 — 다른 사람의 AI가 생성한 솔루션을 이해하는 것 — 인데, 이슈가 깔끔하게 우회합니다.
이슈를 제출한 후 일어나는 일
- 관리자가 이슈를 읽고 분류합니다
- AI는 코드베이스에 대한 전체 지식과 함께 이슈를 컨텍스트로 받습니다
- AI가 TDD로 수정을 작성합니다 (테스트 먼저, 그 다음 구현)
- 두 번째 AI 모델 (Codex)이 수정을 독립적으로 감사합니다
- 자동화된 게이트가 실행됩니다 (
pnpm check:all— 린트, 테스트, 커버리지, 빌드) - 관리자가 컨텍스트에서 변경 사항을 검토하고 병합합니다
이 파이프라인은 다음 코드를 생성합니다:
- 규약 준수 — AI가 모든 세션에서 규칙 파일을 읽습니다
- 테스트됨 — TDD가 필수; 커버리지 임계값이 강제됩니다
- 교차 검증됨 — 두 번째 모델이 논리 오류, 보안, 죽은 코드에 대해 감사합니다
- 아키텍처 일관성 — 많은 세션의 조각이 아닌 전체 컨텍스트를 가진 하나의 AI 세션
더 큰 그림
AI 시대는 오픈 소스 기여가 어떻게 작동하는지에 대한 재고를 강요하고 있습니다. 전통적인 모델 — 포크, 브랜치, 코드, PR, 검토, 병합 — 은 인간이 코드를 작성하고 다른 인간들이 그것을 읽을 수 있다고 가정했습니다. AI가 코드를 생성할 때, 두 가지 가정 모두 약화됩니다.
2025년 전문 개발자 설문에서 그들은 "바이브 코딩을 하지 않고; 대신 계획과 감독을 통해 에이전트를 신중하게 제어한다"는 것을 발견했습니다.[9] 강조점은 제어와 컨텍스트 에 있습니다 — 정확히 외부 기여자의 관련 없는 AI 세션에서 PR이 도착할 때 잃어버리는 것.
우리는 AI 시대 오픈 소스의 미래가 다르게 보인다고 믿습니다:
- 이슈가 주요 기여가 됩니다 — 문제를 설명하는 것은 보편적인 기술입니다
- 관리자가 AI를 제어합니다 — 전체 컨텍스트를 가진 한 팀이 일관된 코드를 생성합니다
- 교차 모델 검증이 인간 검토를 대체합니다 — 대립적 AI 감사가 인간이 놓치는 것을 잡아냅니다
- 테스트가 신뢰를 대체합니다 — 자동화된 게이트가, 리뷰어 판단이 아닌, 코드가 올바른지 결정합니다
VMark는 개방적으로 이 모델을 실험하고 있습니다. 모든 프로젝트에 적합한 접근 방식이 아닐 수 있습니다. 하지만 AI 도구를 사용하는 한 사람이 유지 관리하는 바이브 코딩 코드베이스에서, 이것이 최고의 소프트웨어를 생성하는 접근 방식입니다.
기여 방법
이슈를 제출하세요. 그것이 전부입니다. 더 많은 세부 사항을 제공할수록 수정이 더 좋아질 것입니다.
여러분의 이슈가 AI의 명세서가 됩니다. 명확한 이슈는 올바른 수정으로 이어집니다. 모호한 이슈는 주고받기로 이어집니다. 설명에 투자하세요 — 결과의 품질을 직접 결정합니다.
Karpathy, A. (2025). Vibe coding. 소셜 미디어 게시물에서 처음 설명된 용어로, 빠르게 주류 개발자 어휘에 들어갔습니다. Wikipedia는 바이브 코딩이 "자연어 프롬프트에서 코드를 생성하기 위해 AI 도구에 의존하며, 개발자가 수동으로 코드를 작성할 필요성을 줄이거나 없앤다"고 언급합니다. ↩︎
Jury, J. et al. (2025). "I Would Have Written My Code Differently": Beginners Struggle to Understand LLM-Generated Code. FSE Companion '25, 제33회 ACM 소프트웨어 엔지니어링 기초 국제 컨퍼런스. 연구에서 AI 프롬프트를 작성하지 않은 개발자들이 생성된 코드를 이해하고 추론하는 데 상당한 어려움을 겪었다는 것을 발견했습니다. ↩︎
CodeRabbit. (2025). AI-Assisted Pull Requests Report. 500,000개 이상의 풀 리퀘스트 분석에서 AI가 생성한 PR이 각각 10.83개의 이슈를 포함하는 것을 발견했습니다 대 인간 PR의 6.45 (1.7배 더 많음), 논리 및 정확성 오류가 75% 더 많고 중요 이슈가 1.4배 더 많습니다. ↩︎
Osmani, A. (2025). Code Review in the Age of AI. AI가 생성한 코드가 기존 코드베이스와 어떻게 상호 작용하는지 분석하며, AI가 확립된 프로젝트 규약과 다른 일관되지 않은 패턴을 만드는 경향을 언급합니다. ↩︎
Weavy. (2025). You Can't Vibe Code Your Way Out of a Vibe Coding Mess. 격리된 AI 세션에서 생성된 바이브 코딩된 기능이 각 세션이 다른 세션의 결정에 대한 인식이 없기 때문에 결합될 때 아키텍처 충돌을 만드는 방법을 문서화합니다. ↩︎
SoftwareSeni. (2025). Why AI Coding Speed Gains Disappear in Code Reviews. AI 보조 개발자들이 21% 더 많은 작업을 완료하고 98% 더 많은 PR을 병합하지만 PR 검토 시간이 91% 증가한다고 보고합니다 — AI가 병목을 작성에서 검토로 이동시킨다는 것을 드러냅니다. ↩︎
SQLite. SQLite Copyright. SQLite는 처음부터 "오픈 소스, 기여 개방 아님"이었습니다. 프로젝트는 공개 도메인 상태를 유지하고 코드 품질을 유지하기 위해 외부 기여자의 패치를 수락하지 않습니다. 기여자들은 변경 사항을 제안할 수 있지만 핵심 팀은 구현을 처음부터 다시 작성합니다. ↩︎
Wikipedia. Benevolent Dictator for Life. Python, Linux 등 많은 프로젝트에서 사용하는 BDFL 거버넌스 모델은 일관성을 유지하기 위해 한 사람에게 아키텍처 권한을 집중시킵니다. 주목할 만한 BDFL에는 Guido van Rossum (Python), Linus Torvalds (Linux), Larry Wall (Perl)이 있습니다. ↩︎
Dang, H.T. et al. (2025). Professional Software Developers Don't Vibe, They Control: AI Agent Use for Coding in 2025. 전문 개발자 설문에서 그들이 계획과 감독을 통해 AI 에이전트를 엄격하게 제어하며, 방임적인 "바이브 코딩" 접근 방식을 채택하지 않는다는 것을 발견했습니다. ↩︎