가드레일을 갖춘 바이브 코딩 (Vibe coding): 스스로를 재정의하고 있는 산업에서 소프트웨어를 구축한다는 것

🎵 삽입곡: Architects — Modern Misery

엔지니어링 업계에서는 사람들이 주로 사적인 자리에서 나누는 대화가 있습니다. Slack 스레드에서, 팀 오프사이트에서, 혹은 매니저와의 1:1 면담에서 말이죠. 대략 이런 내용입니다. "우리는 괜찮을까요?"

업계 전반에 걸친 해고는 잔혹했으며, 많은 경우 매우 정교하게 이루어졌습니다. 주니어 직무는 생성되는 속도보다 더 빠르게 사라지고 있습니다. 차세대 인재를 위한 훈련장이 되어주던 엔트리 레벨 (Entry-level) 역할들이 채용 공고에서 조용히 자취를 감추고 있습니다. 이 모든 현상의 밑바닥에 깔린 질문은 이것입니다. 이 중 얼마나 많은 것이 주기적인 현상이고, 얼마나 많은 것이 구조적인 변화인가?

솔직히 말씀드리면, 저 또한 스스로에게 그 질문을 던져왔습니다. 추상적인 관념이 아니라, 코드베이스 (Codebase) 앞에 앉아 AI 에이전트 (AI agent)가 제가 한 번의 스프린트 (Sprint)를 온전히 채워야 했을 작업을 단 20분 만에 만들어내는 것을 지켜보면서 말이죠. 감탄하면서도 동시에 약간의 불안함을 느꼈고, 2년 뒤의 직업은 어떤 모습일지 궁금해졌습니다.

그러다 저는 제대로 된 방식을 도입하기 시작했습니다. 버전 관리 (Version control) 시스템 내의 명세서 (Specs), 결정 기록 (Decision records), 자동화된 게이트 (Automated gates), 그리고 세션 사이에도 실제로 유지되는 컨텍스트 (Context)를 갖추는 것이었습니다. 그 결과는 저조차 예상치 못한 것이었습니다. 더 나은 커버리지 (Coverage), 더 깔끔한 아키텍처 (Architecture), 그리고 설계가 실제로 더 신중해졌습니다. 그 부분은 제가 예상하지 못했던 점입니다. 이를 제대로 수행하면, 순수하게 코딩만 할 때는 조용히 건너뛰게 되는 '구축 전 사고 과정'을 강제하게 됩니다.

업계의 공포는 실재합니다. 다만 저는 우리가 잘못된 곳을 지목하고 있다고 생각합니다. 저는 지난 1년 동안 AI 코딩 어시스턴트 (AI coding assistants)를 실제 프로덕션 (Production) 작업에 통합해 왔습니다. 프로덕션 레벨의 엔터프라이즈 시스템 (Enterprise systems)이 아니라, 제 일상에 실제로 영향을 미치는 것들 말이죠. 제 일일 일정을 관리하고 아젠다가 엉망진창이 되지 않도록 유지해 주는 커스텀 MCP, 집안의 식재료 재고를 추적하고 유통기한을 모니터링하며 냉장고에 있는 재료를 기반으로 식단을 제안해 주는 또 다른 MCP, 지금 출발해야 할지 아니면 커피를 한 잔 더 마셔야 할지 알려주는 교통 상태 모니터, 그리고 LinkedIn을 수동으로 분류하며 시간을 낭비하기엔 인생이 너무 짧기에 편의성 점수가 포함된 채용 공고 스크래퍼 (Job offer scraper) 같은 것들입니다.

이 중 그 어떤 것도 개별적인 결과물로서 인상적이지는 않습니다. 그리고 솔직히 말해서, 대부분은 가드레일 (guardrails) 없이 출시됩니다. 그것들은 작동하지만, 엣지 케이스 (edge case)에 부딪히는 순간 작동을 멈추며, 그럴 때는 보통 소리 없이 실패합니다. 바로 그 점이 저에게 차이점을 가르쳐 주었습니다. 제가 프로덕션 (production) 환경에서 실패하는 것을 목격한 프로젝트들은 모델 때문에 실패한 것이 아니었습니다. 모델 주변에 스캐폴딩 (scaffolding)이 없었고, 관측성 (observability) 또한 없었기 때문에 실패한 것이었습니다. 입력값이 사람이든 에이전트 (agent)든 GIGO (Garbage In, Garbage Out) 원칙은 적용됩니다. "바이브 코딩 (Vibe coding)"이라는 용어는 비하하는 의미로 사용되곤 합니다. 저는 그것이 게으른 생각이라고 생각합니다. AI를 통해 코드를 생성하는 것 자체가 문제는 아니었습니다. 문제는 가드레일 없이, 즉 프로토타입 (prototype)과 유지보수 가능하고, 감사 (audit) 가능하며, 6개월 후에 실제로 디버깅 (debug)할 수 있고, 상황이 잘못되었을 때 새벽 2시에 온콜 (on call) 담당자에게 넘겨줄 수 있는 무언가를 구분해 주는 장치 없이 코드를 생성하는 것입니다. 그것이 문제입니다.

명세 기반 개발 (Spec-Driven Development)
아마도 지난 18개월 동안 가장 큰 워크플로 (workflow)의 변화일 것입니다. GitHub의 SpecKit, Amazon의 Kiro, 또는 OpenSpec과 같은 프레임워크들은 코드가 아닌 명세 (specification)를 신뢰할 수 있는 단일 원천 (source of truth)으로 취급합니다. 당신은 시스템이 무엇을 해야 하는지를 정의하고, 에이전트가 그것을 어떻게 할지를 처리합니다. 이는 폭포수 (waterfall) 모델처럼 들립니다. Hacker News는 2025년 말에 정확히 그렇게 불렀으며, 그 스레드는 읽어볼 가치가 있습니다. 비판이 근거 없는 것은 아닙니다. 자연어 명세는 모호하며, 브라운필드 (brownfield) 프로젝트는 툴링 (tooling)을 빠르게 망가뜨리고, Kiro는 사소한 버그를 아무도 요청하지 않은 12개의 사용자 스토리 (user stories)로 만들어 버립니다. Scott Logic은 기존의 취미용 앱에 SpecKit을 실행해 보았고, 이를 "마크다운 (markdown) 문서의 바다"라고 기술했습니다. 그린필드 (greenfield) 프로젝트라면 이야기가 달라집니다. 누군가는 구현 코드가 단 한 줄도 존재하기 전에 테스트를 작성하여, 90% 이상의 테스트 커버리지 (test coverage)를 가진 TDD (Test-Driven Development) 모드로 완전한 지출 추적기를 출시했습니다. 저는 기존 프로덕션 코드베이스에 SpecKit을 적용해 보려는 PoC (Proof of Concept)를 실행했습니다. 에이전트는 전체 환경 설정을 생성했지만, 중요한 설정을 소리 없이 누락시켰습니다. 그 설정은 그 누구도 기록할 필요를 느끼지 못했기에 헌장 (constitution) 어디에도 문서화되어 있지 않았습니다. 그저 프로젝트가 작동하는 방식이었을 뿐입니다. 저는 그것을 디버깅하는 데 인정하고 싶지 않을 정도로 많은 시간을 보냈습니다.

명세(Spec)가 기계 판독 가능(Machine readable)하다는 점이 경제성을 변화시킵니다. 에이전트(Agent)는 당신이 작성한 것만을 사용하며, 그 이상은 사용하지 않습니다. 당신이 남겨둔 공백 또한 마찬가지입니다.

적합성 함수(Fitness functions)와 결합된 아키텍처 결정 기록(Architecture Decision Records, ADR)
가장 일관되게 생략되는 부분입니다. ADR은 결정이 내려진 이유, 즉 맥락(Context), 트레이드오프(Tradeoffs), 무엇이 거부되었는지를 기록합니다. 적합성 함수(Fitness function)는 이를 모든 커밋(Commit)에 대한 실행 가능한 체크 항목으로 전환합니다. 핵심은 단순히 결정을 기억하는 것이 아닙니다. 코드베이스가 진화함에 따라 아키텍처를 일관되게 유지하고 통제 하에 두기 위해 그 결정을 강제하는 것입니다. InfoQ는 AI 속도에서의 아키텍처 거버넌스(Architectural governance)에 관한 글을 게시하며 이 문제를 직접적으로 다루었습니다. 생성형 AI(GenAI)가 출력을 가속화할 때, 병목 현상은 코드를 작성하는 것에서 정렬(Alignment)을 유지하는 것으로 이동하며, 이러한 거버넌스를 확장할 수 있는 유일한 방법은 인간의 검토에 의존하는 대신 결정론적(Deterministic)으로 만드는 것입니다.

저 또한 개인 프로젝트에서는 ADR을 건너뛰곤 합니다. 이것을 저의 공개적인 TODO로 간주해 주세요. 에이전트는 악의적으로 이탈하지 않습니다. 그들은 학습된 내용에 따라 합리적이라고 판단되는 것으로 공백을 채울 뿐이며, 문서화된 제약 조건이 없다면 그 추론은 검증 없이 실행됩니다. 문제는 에이전트가 저장소(Repository) 경계 내에서 작동한다는 점입니다. 만약 당신의 ADR이 Confluence나 별도의 위키(Wiki)에 있다면, 에이전트는 구현 사항은 볼 수 있지만 그 이면의 추론은 볼 수 없으며, 공백에 대해 스스로 결정을 내릴 것입니다. ADR은 영향을 받는 코드 바로 옆에 존재해야 하며, 규칙은 린터(Linter)와 CI 게이트(CI gates)에 인코딩되어야 합니다. 하나는 가이드를 제공하고, 다른 하나는 규율을 유지합니다.

자동화된 가드레일(Guardrails)과 컨텍스트 엔지니어링(Context engineering)
프리커밋 훅(Precommit hooks), CI 게이트(CI gates), SAST(정적 애플리케이션 보안 테스트), 의존성 스캐닝(Dependency scanning). 이 중 새로운 것은 없습니다. 하지만 AI가 이 정도 속도로 코드를 생성할 때 경제성이 변합니다. Veracode는 2025년에 100개 이상의 LLM(대규모 언어 모델)을 대상으로 80개의 코딩 작업을 수행했으며, 출력물의 45%에서 취약점을 발견했습니다. Java의 경우 그 비율은 70%에 달했습니다. 한 명의 개발자가 실수를 하는 것은 단 하나의 실수입니다. 하지만 에이전트가 동일한 실수를 저지른다면, 그 폭발 반경(Blast radius)은 에이전트가 건드리는 모든 파일에 비례하여 확장됩니다. 쉬프트 레프트(Shift left)는 프로세스에 대한 종교적 신념이 아닙니다. 그것은 해당 공격 표면(Surface area)을 통제 하에 둘 수 있는 유일한 방법입니다.

제가 컨텍스트 엔지니어링 (Context engineering)이라고 부르고 싶은 네 번째 요소가 있습니다. 이는 에이전트 (Agent)가 실제로 사용할 수 있는 형태로, 세션 사이에도 지속되는 프로젝트 컨텍스트 (Project context)를 유지하는 것입니다. CLAUDE.md 파일, .cursorrules, 에이전트 설정 프롬프트 (Agent configuration prompts) 등이 이에 해당합니다. Spotify는 2025년에 Claude Code를 사용하여 수백 개의 리포지토리 (Repositories)에 걸쳐 약 50개의 마이그레이션 (Migrations)을 수행하고 수천 개의 PR을 병합했는데, 그들의 사후 분석 (Postmortem)에서는 프롬프트가 구조화된 평가 (Structured evaluation) 없이 여전히 "시행착오를 통해 진화한다"고 인정했습니다. ETH Zurich는 LLM이 생성한 컨텍스트 파일이 아예 없는 것보다 에이전트의 성능을 더 해칠 수 있다는 연구 결과를 발표했습니다. 도움이 되었던 파일들은 사람이 직접 작성했으며, 에이전트가 스스로 추론할 수 없는 제약 사항들로 제한되었습니다: 커스텀 빌드 명령 (Custom build commands), 특정 툴링 (Specific tooling), 명확하지 않은 아키텍처 결정 (Non-obvious architectural decisions) 등입니다. 여러분만의 CLAUDE.md를 작성하세요. 그것을 생성(Generate)하지 말고, 에이전트가 코드베이스 (Codebase)에서 이미 파악할 수 있는 내용으로 채우지 마세요. 그것이 실제로 대부분의 드리프트 (Drift)가 시작되는 지점입니다.

주니어 파이프라인 (Junior pipeline) 문제는 낙관하기가 더 어렵습니다. 작은 것을 작성하고, 그것을 망가뜨리고, 이유를 배우고, 반복하는 전통적인 경로가 압축되고 있습니다. 일부 기업들은 모델이 신입 사원보다 보일러플레이트 (Boilerplate)를 더 빠르게 생성할 때, 과연 엔트리 레벨 엔지니어 (Entry level engineers)가 필요한지 이미 묻고 있습니다. 저는 이것이 근시안적이라고 생각합니다. 몇 년 후 중요해질 엔지니어는 AI의 출력물을 보고 무언가 미묘하게 잘못되었다는 것을 알 수 있는 사람, 테스트 스위트 (Test suite)를 통해 감지되지 않고 빠져나가는 것을 잡아낼 수 있을 만큼 충분한 프로덕션 경험 (Production experience)을 가진 사람입니다. 그러한 판단력은 프롬프팅 (Prompting)에서 오는 것이 아닙니다. 그것은 자신이 작성하지 않은 것을 디버깅하는 것, 예상치 못한 방식으로 고장 난 시스템을 다루는 것, 그리고 압축될 수 없는 시간으로부터 옵니다. 이 중 그 어떤 것도 현재 이 과정을 겪고 있는 사람들에게 전환을 더 쉽게 만들어주지는 않습니다. 이 업계는 현재 제공하고 있는 것보다 더 많은 정직함을 보여줘야 합니다. 기술 (Craft)은 사라지지 않습니다. 보일러플레이트 (Boilerplate)가 사라질 뿐입니다. 남는 것은 사고(Thinking)이며, 시스템이 실제로 무엇을 해야 하는지, 어떤 제약 사항이 중요한지, 그리고 당신이 어떤 트레이드오프 (Tradeoffs)를 하고 있는지입니다.

단순히 생성하는 것이 아니라, 프로덕션 (Prod) 환경에서도 견딜 수 있는 결과물을 출시하는 것. 이는 다른 차원의 업무입니다. 제대로 해낼 가치가 있습니다.