TL;DR: "바이브 코딩"(AI가 소프트웨어를 구축하도록 자연스럽게 안내하는 방법)이 유행하고 있습니다. 하지만 구조가 없으면 필연적으로 '컨텍스트 드리프트'와 스파게티 코드로 이어질 수밖에 없습니다. AI로 엔터프라이즈급 소프트웨어를 구축하려면 엄격한 컨텍스트 아키텍처가 필요합니다. Mercury에서는 이를 "코덱스 프로토콜"이라고 부르며, 이는 문서를 제안이 아닌 AI가 코드 한 줄을 작성하기 전에 반드시 참조해야 하는 불변의 법칙으로 취급합니다.
머큐리 테크놀로지 솔루션의 CEO 제임스입니다.
인터넷이 "바이브 코딩"으로 들썩이고 있습니다 인공지능에게 아무렇지 않게("바이브") 말을 걸면 인공지능이 앱을 만들어준다는 매력적인 약속입니다.
개발 업계에서 널리 사용되는 워크플로를 검토해 보았습니다. 프로토타입에는 훌륭하지만 심각한 엔지니어링에는 치명적인 결함이 있습니다: <바로 AI가 "큰 그림"을 기억한다고 가정한다는 점입니다 그렇지 않습니다.
LLM은 엔트로피로 인해 어려움을 겪습니다. 대화가 길어지면 AI는 40개 메시지 전에 합의한 데이터베이스 스키마를 잊어버립니다. 새로운 패턴을 만들어내기 시작합니다. '바이브'는 혼돈으로 변합니다.
Mercury에서는 이를 엄격한 워크플로로 개선했습니다. 우리는 이를 바이브 코딩이라고 부르지 않습니다. 우리는 이를 컨텍스트 엔지니어링이라고 부릅니다
다음은 우리가 '코덱스'라고 부르는 단일 진실 소스를 사용하여 AI로 소프트웨어를 구축하기 위한 '머큐리 프로토콜'입니다.
핵심 철학: "코덱스"
비밀은 모델이 아닙니다(Claude 대 GPT-5). 비밀은 외부화된 메모리입니다
프로젝트 폴더를 단순히 코드를 저장하는 공간이 아니라 AI의 '두뇌'로 생각해야 합니다. 저희는 /codex라는 엄격한 폴더 구조를 적용하고 있습니다.
왜 '코덱스'인가요? 권위를 의미하기 때문입니다. 이것은 메모가 아니라 법률입니다. AI가 한 줄의 코드를 작성하기 전에 반드시 코덱스를 참조해야 합니다.
구조
루트 디렉터리에 /codex라는 폴더를 만듭니다. 이 폴더에는 5개의 변경 불가능한 파일이 들어 있습니다:
- product-vision.md(이유): 높은 수준의 목표. (예: "ThreeJS를 사용하는 3D 멀티플레이어 공중전 게임").
- tech-stack.md(방법): 특정 도구. (예: "네트워킹에는 WebSockets, 물리학에는 Rapier. React 없음, 바닐라 JS만 사용").
- architecture.md(맵): 파일 구조 및 데이터베이스 스키마입니다. 가장 중요한 파일입니다.
- 실행 계획.md(경로): 단계별 작업 목록입니다. 각 단계에는 확인 테스트가 <필수> 있어야 합니다.
- progress.md(로그): 완료된 작업, 보류 중인 작업.
워크플로 아키텍처 --> 실행 --> 검증
그냥 채팅을 열고 코딩을 시작하지 마세요. 이 루프를 따라하세요.
1단계: 아키텍트(모델: 클로드 오퍼스 4.5)
<가장 똑똑하고 느린 모델을 사용하여 법률을 작성합니다.
액션: 제품 관리자 역할을 합니다. 채팅에 머리를 쏟아붓습니다.
프롬프트: "시스템 설계자 역할을 하세요. 제 아이디어를 바탕으로 제품 비전.md 및 기술 스택.md에 대한 항목을 만듭니다. 그런 다음 architecture.md를 제안합니다. 아직 코드를 작성하지 마세요. 이 파일들은 코덱스에 들어갈 것입니다."
결과: 디자인을 고정합니다. 나중에 AI가 아키텍처 결정을 내리지 못하도록 명시적으로 금지합니다.
2단계: 서기(모델: 클로드 소네트 4.5 / 코덱스)
우리는 빠른 '에이전트' 모델을 사용하여 법을 집행합니다.
황금률: 모든 새로운 채팅 세션은 반드시 AI 컨설팅 The Codex와 함께 시작해야 합니다.
프롬프트: "/codex/@architecture.md 및 /codex/@implementation-plan.md 참조. 현재 3단계에 있습니다. 코덱스에 정의된 아키텍처를 엄격하게 준수하여 3단계를 구현하세요. 4단계로 진행하지 마세요."
AI가 매번 /코덱스를 읽도록 강제하면 "컨텍스트 드리프트"를 제거할 수 있습니다 1번 프롬프트에 있든 100번 프롬프트에 있든 상관없이 AI는 동일한 사실에 근거합니다.
3단계: 검증자(모델: 사람 + 브라우저 도구)
이것이 당신의 일입니다.
인기 있는 가이드에서는 자동화를 사용할 것을 권장하지만 저는 사람 검증을 고집합니다.
액션: AI가 "3단계가 완료되었습니다."라고 말합니다
You: 코드를 실행합니다. 로그를 확인합니다. 3D 비행기가 실제로 비행하나요?
중요한 단계: 작동하면 AI에 "/codex/@progress.md 업데이트하여 3단계 완료를 표시하세요."라고 명령합니다. 새 파일을 추가한 경우 /codex/@architecture.md 을 업데이트하세요."라고 명령합니다
그래야만 Git에 커밋할 수 있습니다. Git이 저장 지점입니다. 4단계에서 AI가 환각을 일으킨다면 --하드 리셋을 하고 다시 시도하세요.
"반중력" 이점: 모델 차익거래
원래 가이드에서는 하나의 도구를 선택할 것을 제안합니다. 저는 동의하지 않습니다.
모델 차익거래를 사용합니다:
- 계획(아키텍트): Opus 4.5를 사용합니다. 엣지 케이스에 대해 깊이 생각하고 강력한 코덱스를 작성합니다.
- 코딩(The Scribe): Sonnet 4.5를 사용합니다. 지침을 따르고 더 저렴합니다.
- 리팩토링(사서): Gemini 3 Pro를 사용하세요. 상황이 복잡해지면 전체 코드베이스를 한 번에 읽을 수 있는 대규모 컨텍스트 창이 있습니다.
결론 "바이브"에서 "비전"으로의 전환
'바이브 코딩'은 AI가 작동하는 동안 가만히 있어도 된다는 뜻입니다. 이는 잘못된 생각입니다.
이 워크플로는 입력에서 관리로 작업을 전환합니다.
- 당신은 더 이상 벽돌공이 아닙니다.
- 당신은 코덱스의 수호자입니다.
여러분의 임무는 코덱스가 깨끗하게 유지되도록 하는 것입니다. 아키텍처.md가 지저분해지면 코드도 지저분해집니다. 구현계획.md가 모호하면 AI가 막히게 됩니다.
코덱스를 마스터하면 혼자서도 엔터프라이즈급 소프트웨어를 구축할 수 있습니다. 이를 무시하면 깨진 스크립트로 가득 찬 폴더만 남게 됩니다.
머큐리 기술 솔루션: 디지털 가속화
