AI가 코드를 빠르게 만들어도 리뷰는 여전히 비싸다. 유지보수 시간을 보호하기 위해 프로토타입과 사람 검토 준비 완료 PR을 명확히 구분하고, 프로토타입 공유‧라벨링 규칙과 메인테이너 생존 가이드를 제안한다.
개발자이자 주요 오픈 소스 프로젝트의 관리자로서, 우리는 AI 코딩 도구가 오픈 소스 메인테이너에게 새로운 문제를 만들고 있음을 지켜보고 있습니다.
GitHub Copilot, Cursor, Codex, Claude 같은 AI 도우미는 이제 몇 분 만에 수백 줄의 코드를 생성할 수 있습니다. 이는 진짜로 유용하지만, 의도치 않은 결과가 있습니다. 기계가 생성한 코드를 리뷰하는 비용이 매우 크다는 점입니다.
핵심 문제: AI 도구는 코드 생성 비용을 싸게 만들었지만, 코드 리뷰 비용은 싸게 만들지 못했습니다. 불완전한 PR 하나하나가, 곧바로 머지할 수 있는 기여를 검토하는 데 쓸 수 있었던 메인테이너의 주의를 소비합니다.
Discourse에서도 이미 기여자 커뮤니티 전반에서 이런 흐름이 가속되는 걸 보고 있습니다. 내년이면 오픈 소스 프로젝트를 유지하는 모든 엔지니어가 같은 도전에 직면할 것입니다.
우리는 메인테이너 시간이 제한적이라는 현실을 인정하는, AI 보조 기여를 위한 더 명확한 프레임워크가 필요합니다.
이럴 때 이진 시스템이 매우 효과적입니다. 한쪽에는 단지 아이디어를 보여주는 프로토타입이 있고, 다른 한쪽에는 프로젝트의 기여 가이드를 충족하며 인간 검토가 가능한 상태의 ‘리뷰 준비 완료 PR’이 있습니다.
새로운 도구 덕분에 변경 집합을 만들고 펜스 너머로 휙 던지는 일이 너무 쉬워졌습니다. 그 결과, 프로젝트 메인테이너가 기여자가 몇 초 만에 만든 불균형한 AI 생성 코드를 리뷰하는 데 과도한 노력을 들이고, 리뷰에는 몇 시간에서 수십 시간이 드는 뒤틀린 시스템이 생길 수 있습니다.
이는 좌절감을 주고, 시간을 잡아먹으며, 의욕을 꺾습니다. 한쪽에는 AI 프롬프트를 몇 분 만져 본 기여자가 있고, 다른 쪽에는 낯선 지능이 만든 것을 해독하느라 몇 시간, 심지어 며칠을 써야 하는 엔지니어가 있습니다.
이건 지속 가능하지 않으며 극도로 파괴적입니다.
Claude Code, Codex, Cursor CLI 등 여러 AI 코딩 에이전트는 ‘새로운 종류’의 변경 집합인 프로토타입을 배포할 수 있는 능력을 열어 주었습니다.
프로토타입은 라이브 데모입니다. 프로젝트의 코딩 표준을 충족하지 않습니다. 당신이 보증하거나 좋다고 말할 수 있는 코드가 아닙니다. 테스트가 없고, 보안 이슈가 있을 수 있으며, 이 상태로 머지하면 엄청난 기술 부채를 초래할 가능성이 높습니다.
그럼에도 불구하고, 아이디어를 더 현실감 있게 만들어 주는 살아 있는 데모입니다. 그리고 엄청나게 재미있습니다.
영화 세트처럼 상상해 보세요.
특히 Discourse처럼 도구가 잘 갖춰진 프로젝트에서는 dv 같은 도구로 프로토타입을 탐색하기가 믿을 수 없을 만큼 쉽습니다.
% dv new my-experiment
% dv branch my-amazing-prototype
% dv ls
total 1
* my-amazing-prototype Running 1 minute ago http://localhost:4200
# 마지막으로 http://localhost:4200 에 접속해 동작을 확인하세요
프로토타입은 아이디어를 탐색하기에 훌륭한 수단입니다. 하나의 문제에 대해 전혀 다른 해결책을 보여 주는 여러 프로토타입을 만들어, 최적의 접근을 결정하는 데 도움을 줄 수도 있습니다.
프로토타입, 영상 데모, 간단한 시각적 목업은 훌륭한 동반자입니다. 프로토타입의 장점은 직접 만져 보며 변경의 동작을 제대로 탐색할 수 있다는 점입니다. 영상은 소비가 더 빠릅니다. 때로는 이 모두가 필요할 때가 있습니다.
바이브 코딩과 프로토타이핑을 한다면 다음의 명확한 규칙을 따르세요.
운이 좋으면 당신의 아이디어가 호응을 얻을 수도 있고, 누군가가 시간을 투자해 프로토타입을 프로덕션 PR로 이끌고 싶어 할 수도 있습니다.
프로토타이핑은 재미있고 엄청나게 접근성이 높습니다. 로컬 코딩 에이전트나 Jules, Codex cloud, Cursor Cloud, Lovable, v0 등 수많은 클라우드 에이전트를 통해 누구나 할 수 있습니다.
이로 인해 프로토타입을 만드는 진입 장벽이 크게 낮아졌습니다. 기획자도, CEO도, 디자이너도 프로토타입을 만들 수 있습니다.
하지만 이 새로운 즐거움은 팀과 함께 고민해야 할 새로운 질문들을 열어 둡니다.
회사에 프로토타이핑을 도입할 때는 이러한 질문들을 신중히 조율해 내부 합의를 형성해야 합니다. 그렇지 않으면 내부 태도의 큰 분열과 반감을 불러일으킬 위험이 있습니다.
프로토타입, 어디에 좋을까요? 확실히 쓸모가 있습니다.
저는 일반적인 개발 실무에서 프로토타입이 믿을 수 없을 만큼 유용하다고 느낍니다.
안타깝게도 올해가 지날수록, 많은 오픈 소스 프로젝트가 ‘프로토타입 급’ PR을 정말 많이 받게 될 거라 예상합니다. 모두가 이 글을 읽는 것도, 동의하는 것도 아니니까요.
외부 기여를 다루는 메인테이너라면:
리뷰 준비 완료 PR은 우리가 전통적으로 제출해 온 그 PR입니다.
생성된 머신 코드를 전부 리뷰했고, 그 전부를 보증합니다. 테스트를 돌렸고 테스트가 마음에 듭니다. 코드 구조가 마음에 들고, 모든 코드를 한 줄 한 줄 꼼꼼하게 읽었습니다. 또한 PR이 프로젝트의 가이드를 준수하는지도 확인했습니다.
과정에서 에이전트들이 만들어 낸 괴상한 코드는 모두 고쳐졌고, 우리는 그 코드에 당당히 우리의 개인 브랜드를 찍을 수 있습니다.
프로젝트는 일반적으로 코드 품질, 코드 조직, 테스트 등과 관련된 다양한 규칙을 갖고 있습니다.
리뷰 준비 완료 PR을 만드는 데 AI의 도움을 썼을 수도 있습니다. 그러나 본질적으로 그건 중요치 않습니다. 우리는 그 코드를 보증하며, 우리 브랜드와 프로젝트 가이드라인을 모두 충족한다고 말할 수 있어야 합니다.
프로토타입에서 리뷰 준비 완료 PR까지의 거리는 겉보기보다 훨씬 멉니다. 복잡한 프로토타입을 프로덕션 준비 상태로 만드는 데는 며칠의 엔지니어링 작업이 필요할 수 있습니다.
이 큰 거리는 Andrej Karpathy가 Dwarkesh 팟캐스트에서도 잘 설명했습니다.
어떤 종류의 작업과 직무에서는, 데모에서 제품까지의 격차가 매우 큽니다. 데모는 아주 쉽지만, 제품은 매우 어렵죠.
…
예를 들어, 소프트웨어 엔지니어링에서는 그 성질이 존재한다고 생각합니다. 많은 바이브 코딩에서는 그렇지 않을 수 있지만, 실제 프로덕션급 코드를 작성하는 경우라면 그 성질이 존재해야 합니다. 어떤 실수라도 보안 취약점 같은 것으로 이어지니까요.
Veracode 설문조사에 따르면 생성 작업의 55%만이 보안 코드를 산출했습니다. (출처)
모델은 나날이 좋아지고 있고, 실제로는 수많은 파라미터에 따라 달라지지만, LLM이 불안전한 코드를 생성할 수 있고 실제로 생성한다는 핵심 메시지는 유효합니다.
프로젝트 가이드라인과 프로토타입 사이의 거리를 만드는 근본 원인은 AI의 ‘외계 지능’입니다.
제가 아는 많은 엔지니어는 두 부류로 나뉩니다. 새로운 LLM 부류를 지능적이고 획기적이며 충격적으로 뛰어나다고 보는 사람들. 그리고 모든 LLM 생성물을 ‘벌거벗은 임금님’이라 여기며, 그들이 생성하는 코드는 ‘벌거벗은’, 근본적으로 결함 있고 독이라고 생각하는 사람들.
저는 그 어느 쪽도 아닙니다. 저는 이 새로운 지능을 ‘외계 지능’으로 생각하길 좋아합니다. 동시에 충격적으로 좋고, 동시에 충격적으로 끔찍합니다.
LLM을 ‘초유능 인턴’ 같은 인간 비유로 틀 짓는 건 잘못입니다. 이 시스템은 외계인이고, 우리가 외계 지능을 엔지니어링 프로세스에 주입할 때 생기는 복잡성을 항해하려면, 이를 인정하는 것이 빠른 길입니다.
지난 몇 달간 저는 AI 에이전트로 많은 실험을 했습니다. 그중 특히 자랑스러운 프로젝트가 dv입니다. Discourse를 위한 컨테이너 오케스트레이터로, 다양한 AI 에이전트를 Discourse와 함께 쓰기 쉽게 해 줍니다.
저는 자주 로컬 머신에서 서로 완전히 다른 일회용 Discourse 환경을 여러 개 띄워 다양한 기능을 탐색합니다. 이런 도구는 vibe engineering 프로토타입에 특화되어 빛을 발합니다.
흥미롭게도 dv는 대부분 AI 에이전트로 만들어졌고, 인간의 개입은 아주 적었습니다. 일부 코드는 다소 제 ‘브랜드’와 어긋납니다. 그렇지만 Discourse나 제가 유지하는 다른 많은 오픈 소스 젬과 달리 dv는 장난감 프로젝트입니다.
본론으로 돌아와, dv는 Discourse에서 프로토타입을 찍어내는 훌륭한 공장이 되었습니다. 저에겐 큰 행운이었습니다. 여러 아이디어를 탐험하면서 동시에 이메일을 처리하고 다양한 Discourse 사이트의 논의도 따라잡을 수 있었으니까요.
먼저, 기여하는 모든 프로젝트의 규칙을 반드시 존중해야 합니다. 기여 전에 찾아 읽으세요. 예를 들어 Cloud Hypervisor는 라이선스 리스크를 피하기 위해 AI 생성 코드 금지를 명시합니다.
그렇다 해도, 많은 개발자 사이에 AI를 금지하려는 흐름이 있습니다. 아예 “여긴 AI 환영 안 함, 다른 프로젝트로 가세요”라고 말하는 경우도 있습니다.
이건 저에겐 극도로 역효과적이며, 근본적으로 집행 불가능해 보입니다. AI가 생성한 많은 코드는 어차피 인간이 쓴 코드와 구분이 되지 않습니다. 인간이 쓴 척하는 프로토타입은 대체로 알아볼 수 있지만, 인간이 AI의 도움을 받아 만든 ‘진짜 PR’은 구분이 어려울 수 있습니다.
새로운 LLM 도구는 파일 내 간단한 코드 리뷰나 단순 리네이밍부터, 변경 집합의 전체 아키텍처 설계까지 엄청나게 다양한 방식으로 쓰일 수 있습니다.
이 혼란과 다양성을 고려하면, 가장 건강한 접근은 명확한 기대치를 세우는 것입니다. 내가 PR을 제출한다면, 그건 내 브랜드에 맞아야 하며 내가 보증하는 코드여야 합니다.
엔지니어로서 우리의 역할은 변경을 올바르게 라벨링하는 것입니다. 우리의 변경이 사람 검토가 준비된 상태인가요, 아니면 단순히 문제 공간을 재미 삼아 탐색한 것인가요?
인간의 코드 리뷰는 소프트웨어 엔지니어링에서 갈수록 주요 병목이 되고 있습니다. 우리는 사람들의 시간을 존중하고, 우리의 엔지니어링 브랜드를 보호해야 합니다.
프로토타입은 재미있고, 문제 공간에 대해 많은 걸 가르쳐 줍니다. 하지만 프로젝트에 기여를 보낼 때는 모든 코드를 당신이 쓴 코드로 대하세요. 무엇이든 소유와 승인 도장을 먼저 찍고, 그다음에 당신이 보증할 수 있는 PR만 보내세요.