바이브 코딩 바이블 (Vibe Coding Bible): AI 생성 코드를 위한 소프트웨어 아키텍처의 재고

지난 1년 동안 AI 생성 코드와 함께 작업하면서 한 가지 일관된 현상을 발견했습니다.

AI를 사용하여 코드를 작성하면 할수록, 시스템이 매우 특정한 방식으로 무너지기 시작했습니다:

• 작은 변화가 예상치 못한 부작용 (side effects)을 일으킴
• 리팩토링 (refactoring)이 점점 더 위험해짐
• 컨텍스트 (context)가 관리하기 어려울 정도로 커짐
• AI가 때때로 주변 모듈을 망가뜨리며 "도움"을 줌
• 한 가지를 고치면 종종 다른 것이 망가짐

어느 시점에 저는 이것을 프롬프트 엔지니어링 (prompt engineering)의 문제로 생각하는 것을 멈췄습니다.

그것은 오히려 프로그래밍 모델 자체의 근본적인 불일치처럼 느껴졌습니다.

핵심적인 불일치

오늘날 대부분의 소프트웨어 아키텍처는 한 가지 가정하에 구축됩니다:

인간이 코드의 주요 작성자이다

우리는 다음과 같은 것을 기대합니다:

• 인간이 시간이 지나도 시스템을 이해할 수 있다
• 인간이 거대한 의존성 그래프 (dependency graphs)를 안전하게 리팩토링할 수 있다
• 인간이 복잡성에 대한 멘탈 모델 (mental models)을 유지할 수 있다
• 인간이 모듈 전반에 걸쳐 변경 사항을 조정할 수 있다

인간이 개발의 주된 동력일 때는 이것이 상당히 잘 작동합니다.

하지만 LLM (Large Language Models)이 개입되면 다른 행동 양식이 나타납니다:

모든 상호작용은 사실상 부분적이거나 재구성된 컨텍스트에서 시작된다

전체 코드베이스 (codebase)가 존재하더라도, 모델은 특정 순간에 제한된 가시성(visibility)을 가지고 작동합니다.

시스템이 성장함에 따라, 이는 예측 가능한 패턴으로 이어집니다:

• 결합도 (coupling) 증가
• 취약한 리팩토링 (refactoring)
• 숨겨진 의존성 (dependencies)
• 전역적 일관성 (global consistency)의 상실

바이브 코딩 바이블의 이면에 담긴 아이디어

이것은 저를 다른 질문으로 이끌었습니다:

만약 AI가 주요 코드 작성자이고, 인간은 시스템 설계자라고 가정하고 소프트웨어를 설계한다면 어떨까?

그러한 전환은 많은 가정을 변화시킵니다.

익숙한 관행 중 일부는 다르게 작동하기 시작합니다:

• 유연한 인터페이스 (interfaces)는 추론하기 더 어려워짐
• 깊은 추상화 계층 (abstraction layers)은 취약성을 초래함
• 리팩토링 (refactoring)은 인지적 비용을 증가시킴
• 공유된 가변 구조 (shared mutable structures)는 예상치 못한 동작을 증폭시킴

핵심 원칙: 확정된 인터페이스 (nailed interfaces)

핵심 아이디어는 간단합니다:

인터페이스는 진화해서는 안 된다

한 번 정의되면:

• 수정되지 않습니다
• 확장되지 않습니다
• 리팩터링 (refactoring)되지 않습니다

요구사항이 변경되더라도 인터페이스를 수정하지 않습니다.

새로운 인터페이스를 가진 새로운 블록 (block)을 생성합니다.

설령 그것이 중복처럼 느껴지더라도 말입니다.

AI는 중복을 저렴하게 만들지만, 결합도 (coupling)는 여전히 비용이 많이 들기 때문입니다.

블록 구조 (Block structure)

모든 코드 단위는 하나의 **블록 (block)**입니다:

• interface.py → 불변의 계약 (immutable contract)
• implementation.py → AI가 생성한 로직 (AI-generated logic)
• tests.py → 선택적인 생성된 테스트 (optional generated tests)

핵심 규칙:

인터페이스는 영원히 동결된다

예외는 없습니다.

그래프 대신 트리 (Tree instead of graph)

대부분의 실제 시스템은 자연스럽게 의존성 그래프 (dependency graphs)로 진화합니다:

• 모듈들이 서로 의존함
• 의존성이 여러 방향으로 퍼짐
• 작은 변화가 시스템 전체에 영향을 미침

AI 중심의 개발에서는 이것이 특히 불안정해집니다.

따라서 우리는 대신 더 단순한 구조를 강제합니다:

• 엄격한 트리 계층 구조 (strict tree hierarchy)
• 레벨 기반의 임포트 (level-based imports)만 허용
• 브랜치 간 의존성 금지
• 수평적 결합 (lateral coupling) 금지

이것은 우아하지 않습니다.

하지만 예측 가능합니다.

그리고 AI가 코드의 대부분을 작성할 때는 유연성보다 예측 가능성이 더 중요합니다.

리팩터링 금지 규칙 (No refactoring rule)

이 모델에서는:

무언가 잘못되었다면:

• 리팩터링 (refactor)하지 않습니다
• 교체합니다

동작이 변경된다면:

• 기존 모듈을 확장하지 않습니다
• 새로운 모듈을 생성합니다

인터페이스가 더 이상 적합하지 않다면:

• 수정하지 않습니다
• 새로운 블록을 정의합니다

처음에는 이것이 비효율적으로 느껴질 수 있습니다.

하지만 비용 모델이 변화합니다:

• 새로운 코드를 쓰는 것은 저렴합니다
• 결합도 (coupling)를 관리하는 것은 비쌉니다

따라서 우리는 진화 (evolution) 대신 재생성 (regeneration)을 위해 최적화합니다.

개발자에게 변화하는 점

이 모델에서 개발자는 다음의 역할에서 벗어납니다:

• 리팩터러 (refactorers)
• 의존성 그래프 관리자 (dependency graph managers)
• 대규모 코드베이스 탐색자 (large-codebase navigators)

그리고 다음의 역할이 됩니다:

• 시스템 분해자 (system decomposers)
• 인터페이스 설계자 (interface designers)
• 제약 조건 엔지니어 (constraint engineers)
• AI 운영자 (AI operators)

업무가 코드를 작성하는 것에서 경계(boundaries)를 형성하는 것으로 전환됩니다.

마이그레이션 전략 (Migration strategy)

기존 시스템을 직접적으로 마이그레이션(migration)하지는 않습니다.

대신 다음과 같이 진행합니다:

• 문제가 되는 모듈을 동결(freeze)합니다.
• 레거시 코드(legacy code)의 수정을 중단합니다.
• 그와 병행하여 새로운 AI-네이티브(AI-native) 블록을 구축합니다.
• 시간이 흐름에 따라 점진적으로 기능을 전환합니다.

레거시 코드는 끊임없이 수정해야 할 대상이 아니라, 배경 컨텍스트(background context)가 됩니다.

이것은 보편적인 규칙이 아닙니다

이것은 하나의 실험입니다.

모든 시스템에 적용되지 않을 수도 있습니다.

일부 도메인에서는 여전히 다음과 같은 요소가 필요할 수 있습니다:

• 복잡한 공유 상태 (complex shared state)
• 심층 최적화 (deep optimization)
• 밀접하게 결합된 시스템 (tightly coupled systems)

하지만 AI 비중이 높은 많은 워크플로우(workflows)에서 전통적인 가정들은 무너지기 시작합니다.

내가 이것을 쓰는 이유

나는 이 실험을 다음과 같이 부릅니다:

바이브 코딩 바이블 (Vibe Coding Bible)

이것은 완성된 프레임워크(framework)가 아닙니다.

내가 실무에서 테스트하고 있는 일련의 가정들입니다.

관련 프로젝트

• AI가 작성한 소프트웨어를 위한 프로그래밍 패러다임 (Programming paradigm for AI-written software):
  https://github.com/evgeniykormin86-stack/Programming-Paradigm-for-AI-Written-Software

• 인시던트 기반 AI 시스템 (Incident-driven AI system) (Golden Armada):
  https://github.com/evgeniykormin86-stack/golden_armada

마지막 생각

내가 탐구하고 있는 질문은 단순합니다:

AI가 주요 프로그래머가 될 때, 소프트웨어 아키텍처(software architecture)는 어떤 모습일까?

이것은 하나의 가능한 답변입니다.

최종적인 답변은 아닙니다.

하지만 시작점입니다.