한국 SI 1티어가 '바이브 코딩은 안 된다'고 선언했다 — Cline Spec Driven이 그어 놓은 5가지 한계선

핵심 요약 (TL;DR)

LG CNS가 미국 오픈소스 코딩 에이전트 Cline과 손잡고 'Cline Spec Driven for Enterprise'를 정식 출시했습니다. PR Newswire 보도자료 헤드라인이 그대로 "Going Beyond Vibe Coding". 자연어 지시 → 사양 → 코드 → 검증으로 단계를 쪼개 단계별 전담 에이전트가 릴레이로 처리하는 구조입니다. 인디 바이브코더에게 이 신호는 "spec 단계 한 줄을 끼워 넣는 사람과 안 끼워 넣는 사람이 갈라진다"는 뜻이에요.

한국 1티어 SI가 자기 회사의 코드네임에 "vibe coding을 넘어"를 박는다는 건 보통 일이 아닙니다. 6월 8일 LG CNS가 Cline과 함께 발표한 'Cline Spec Driven for Enterprise'(LG CNS 내부 브랜드 'DevOn AIND')의 PR Newswire 헤드라인이 "Going Beyond Vibe Coding: Agentic AI Takes on Large-scale System Development"였거든요. (출처: https://cline.bot/blog/cline-and-lg-cns-partner-to-develop-agentic-ai-solution-for-enterprise-development , PR Newswire 헤드라인은 Morningstar·Manila Times 와이어 게재본 기준)

인디 메이커 입장에선 "내가 즐겁게 쓰던 vibe coding을 부정한 거 아니야?"로 읽힐 수 있죠. 그런데 한 단계 더 들어가 보면, 이건 부정이 아니라 "vibe coding의 다음 챕터"를 한국 SI가 먼저 명명한 사건에 가깝습니다.

그어 놓은 5가지 한계선

Cline Spec Driven이 사실상 "vibe coding이 안 되는 영역"으로 그어 놓은 선은 다음과 같이 정리됩니다.

1. 수백만 줄 규모 레거시 시스템 변환 — Cline·LG CNS는 COBOL→Java 자동 변환을 대표 사례로 제시합니다. 자연어 직답으로는 컨텍스트가 끊겨 일관성 유지가 어렵죠.
2. 규제 산업의 감사 추적 요구 — 금융·공공·국방·제조. 어떤 코드가 "왜" 생성됐는지 spec 단위로 기록되지 않으면 감사에서 통과 불가.
3. 여러 단계의 검증이 필수인 시스템 — 자연어 한 줄에서 코드까지 직진하면, 중간에 "이 사양이 맞나?"를 확인할 지점이 없습니다.
4. 여러 팀이 동시에 손대는 동기화 작업 — spec이 공유 계약이 안 되면 팀별로 다른 해석으로 발산.
5. 모델 교체에도 살아남아야 하는 워크플로우 — 모델이 바뀔 때마다 결과가 흔들리지 않으려면, spec이 모델보다 위에 있어야 합니다.

LG CNS는 이 다섯 선을 한꺼번에 만족시키려고 spec-driven을 채택했다고 봐도 됩니다.

인디 메이커에게 의미하는 건

한국 1인 메이커가 이 발표를 "대기업 이야기"로 흘려보내면 두 가지를 놓칩니다.

첫째, 한국 대기업·금융권 RFP에 들어갈 때의 차별점이 바뀝니다. 지난 1년간은 "Cursor·Claude Code 잘 다룹니다"가 셀링 포인트였죠. 이제 "자연어 → spec → 코드 워크플로우를 어떻게 잡고 계신가요?"가 새 면접 질문이 됩니다. spec 단계 한 줄을 평소에 끼워 두는 사람과 안 끼워 두는 사람이 같은 SI 발주에서 갈립니다.

둘째, 본인이 만드는 SaaS의 "엔터프라이즈 진입 채비"가 바뀝니다. 인디 SaaS가 한국 대기업에 팔리려면, 이전엔 "Claude로 만들었어요"가 통했지만 이제는 "spec 변경 시 변경 이력 어떻게 추적하나요?" 같은 질문이 들어옵니다. Cline·LG CNS 사례가 그 질문을 표준화한 거죠.

한 명짜리 프로젝트에서 spec 단계 끼워 넣는 법

그렇다고 LG CNS처럼 풀스택 spec-driven 시스템을 1인 메이커가 따라 만들 필요는 없습니다. 작게 시작하는 방법이 있어요.

# 평소 워크플로우
자연어 지시 → Claude Code → 결과

# spec 한 줄 끼운 워크플로우
자연어 지시 → [SPEC.md에 3~5줄 사양 적기] → Claude Code → 결과 → spec 대비 검증

SPEC.md에 적는 건 거창할 필요 없습니다. "입력은 X, 출력은 Y, 절대 안 되는 케이스는 Z" 정도면 충분해요. 이 한 단계가 추가됐을 때 변하는 건 세 가지인 거죠. (1) 한 달 뒤 같은 코드를 다시 봤을 때 "왜 이렇게 짰지?"가 사라집니다. (2) 모델을 갈아탔을 때도 같은 spec으로 같은 결과를 재현할 수 있습니다. (3) 고객·동료에게 "이게 무엇을 한다"를 설명할 시간이 절반으로 줍니다.

"vibe coding 끝났다"는 오해

LG CNS·Cline의 발표를 "vibe coding 시대 끝"으로 읽는 건 정확하지 않습니다. 발표문 자체가 "Going Beyond Vibe Coding"이지 "Replacing"이 아니에요. 인디 메이커의 즉답형 vibe coding은 여전히 가장 빠른 프로토타이핑 방식입니다. 다만 그 위에 "엔터프라이즈로 가야 하는 워크플로우"가 한 단계 더 올라간 거죠.

동남아 영미권 인디 커뮤니티 일부는 "spec-driven은 결국 SI 컨설팅 단가 보호용 마케팅 아니냐"는 회의 톤도 있습니다. 그 비판도 일리는 있어요. 다만 한국 대기업 영업을 진지하게 고민하는 메이커라면, 회의는 회의대로 두고 spec 단계 한 줄 끼우는 실험은 한 번 해보는 게 맞습니다.

자주 묻는 질문

Q. spec-driven이랑 그냥 PRD 작성이랑 뭐가 다른가요?

전통 PRD는 사람이 읽고 사람이 코드로 옮기는 문서입니다. spec-driven에서 spec은 에이전트가 읽고 다음 단계 에이전트에게 넘기는 계약서입니다. 자연어이긴 하지만 "입력·출력·검증 기준"이 명확해야 다음 에이전트가 받을 수 있는 거죠.

Q. Cline은 오픈소스인데, LG CNS 버전은 별도인가요?

오픈소스 Cline은 그대로 유지됩니다. LG CNS의 'Cline Spec Driven for Enterprise'는 엔터프라이즈 거버넌스·감사 로그·spec 자동 생성 모듈이 얹힌 OEM 트랙이라고 보시면 됩니다. 1인 메이커는 오픈소스 Cline에서 SPEC.md 패턴을 흉내내는 정도로 시작 가능합니다.

Q. 어떤 프로젝트부터 spec-driven으로 갈아탈지 모르겠어요.

"한 달 뒤에 다시 손댈 때 헷갈릴 것 같은 프로젝트"부터 적용하세요. 일회성 자동화는 vibe coding이 빠릅니다. 1년 이상 유지보수가 예상되거나, 다른 사람이 인수받을 가능성이 있는 프로젝트는 spec 한 단계가 무조건 남는 장사입니다.

바이브 코딩은 끝난 게 아니라 한 챕터를 끝낸 거예요. 다음 챕터에 먼저 들어간 사람이 한국 대기업 RFP를 가져갑니다. spec 단계 한 줄을 본인 워크플로우 어디에 끼워 넣을지, 오늘 안에 결정해 볼 만한 시점입니다.