Context Before Code: An Experience Report on Vibe Coding in Practice

이 경험 보고서는 소규모 풀스택 팀이 생산성 환경에서 '바이브 코딩'을 적용한 결과, 초기 구조화 작업은 가속화되었으나 멀티테넌시 및 접근 제어와 같은 핵심 아키텍처 제약은 명시적 설계와 검증이 필수적임을 보여주며, 엔지니어링 노력의 초점이 보일러플레이트 구현에서 제약 조건 명세와 감사로 이동하고 있음을 시사합니다.

핵심

🍳 핵심 비유: "재능 있는 요리사 (AI) vs. 꼼꼼한 셰프 (개발자)"

이 논문에서 말하는 **'바임 코딩 (Vibe Coding)'**이란, 개발자가 직접 코드를 일일이 쓰지 않고, AI(거대 언어 모델) 에게 "이런 요리를 만들어줘"라고 말로 지시하면 AI 가 요리를 만들어주는 방식입니다.

이 연구팀은 핀란드의 작은 팀이 이 방식을 써서 두 가지 복잡한 시스템을 만들었습니다.

1. 여러 팀이 함께 쓰는 학습 플랫폼 (각 팀의 정보가 섞이지 않게 해야 함)
2. 학술 자료 검색 시스템 (정확한 출처를 밝히고 권한을 관리해야 함)

그 결과, AI 는 **요리 재료 준비 (보일러플레이트 코드)**는 정말 빠르게 해냈지만, **식중독 방지 (보안) 와 메뉴판 관리 (아키텍처)**는 개발자가 직접 챙겨야 했습니다.

---

📝 주요 내용 3 가지

1. AI 는 "요리"는 잘하지만 "식당 규칙"은 모릅니다

• 상황: 개발자가 AI 에게 "채소 볶음 만들어줘"라고 하면, AI 는 아주 맛있게 볶아냅니다. (API, 화면, 기본 기능 등 반복적인 작업은 매우 빠릅니다.)
• 문제: 하지만 AI 는 "이 요리는 A 팀 전용이야, B 팀은 절대 건드리면 안 돼"라는 **식당 규칙 (아키텍처 제약)**을 스스로 기억하지 못합니다.
• 결과: AI 가 만든 코드를 보면, A 팀의 데이터가 B 팀에게 노출될 수도 있고, 권한이 없는 사람이 관리자 기능을 쓸 수도 있는 치명적인 구멍이 뚫려 있었습니다. 개발자는 AI 가 만든 요리를 받아서 **"이건 A 팀 전용이라서 B 팀은 못 먹게 문에 자물쇠를 채워야겠다"**라고 직접 수정해 주어야 했습니다.

2. "맥락 (Context)"을 먼저 주지 않으면 AI 는 엉뚱한 걸 만듭니다

• 비유: 만약 요리사에게 "요리해줘"라고만 하면, 그는 아무 재료나 가져와서 요리를 할 것입니다. 하지만 "오늘은 A 팀이 와서, 채소는 신선한 것만 쓰고, 소금기는 적게 해줘"라고 구체적인 맥락을 먼저 알려주면 훨씬 좋습니다.
• 교훈: 이 논문은 **"코드 (요리) 를 만들기 전에 맥락 (규칙과 제약) 을 먼저 정의하라"**고 강조합니다. 개발자가 AI 에게 "이건 다중 사용자 시스템이야, 데이터가 섞이면 안 돼"라고 명확히 지시하지 않으면, AI 는 단순히 작동만 하는 코드를 만들어냅니다.

3. 개발자의 역할이 바뀌었습니다: "요리사"에서 "식당 경영자"로

• 과거: 개발자는 직접 재료를 다듬고, 불을 조절하고, 요리를 만드는 모든 과정을 했습니다.
• 현재 (AI 시대): AI 가 재료를 다듬고 기본 요리를 해줍니다.
• 변화: 하지만 개발자의 일은 사라진 게 아니라 방향이 바뀐 것입니다.
  • 줄어든 일: 반복적인 요리 (코드 작성).
  • 늘어난 일: 식당 규칙을 세우고 (아키텍처 설계), AI 가 만든 요리에 위생 검사 (검증) 를 하고, **비상 대응 (인프라 관리)**을 하는 일.
  • 즉, AI 가 요리를 해주는 대신, **"이 요리는 안전한가?", "누가 먹을 수 있는가?"**를 감시하고 검증하는 일이 훨씬 중요해졌습니다.

---

💡 결론: AI 는 훌륭한 도우미지만, 책임은 인간에게 있습니다

이 논문의 결론은 매우 명확합니다.

"AI 는 빠른 속도로 요리를 만들어주지만, 식당이 안전하고 규칙대로 운영되게 하는 것은 결국 인간 개발자의 몫이다."

AI 가 코드를 짜주는 '바임 코딩'은 매우 유용하지만, 보안, 권한 관리, 데이터 격리 같은 중요한 시스템의 뼈대는 AI 에게 맡길 수 없습니다. 개발자는 AI 가 만든 코드를 무조건 믿지 않고, **"이게 우리 식당 규칙에 맞는지"**를 꼼꼼히 확인하고 수정해야만 실제 서비스로 쓸 수 있습니다.

한 줄 요약:
AI 는 훌륭한 '요리 보조'지만, 식당의 '규칙'과 '안전'을 책임지는 '셰프'는 여전히 인간이 되어야 합니다.

기술 요약

논문 요약: 코드 생성 전 컨텍스트 (Context Before Code) - 실제 환경에서의 'Vibe Coding' 경험 보고서

이 논문은 생성형 AI 를 활용한 대화형 프로그래밍 방식인 **'Vibe Coding'**이 실제 프로덕션 환경 (Production Constraints) 에서 어떻게 작동하는지에 대한 경험 보고서입니다. 저자들은 두 개의 배포 가능한 시스템을 개발하는 과정에서 AI 가 생성한 코드의 한계와 엔지니어링 노력의 변화를 분석했습니다.

1. 문제 정의 (Problem)

• 배경: 대규모 언어 모델 (LLM) 을 활용한 AI 보조 코딩과 'Vibe Coding'(자연어 대화로 코드 생성 유도) 이 프로토타이핑 속도를 높이고 있습니다.
• 문제점: 기존 연구는 주로 개발자 생산성이나 프롬프트 전략에 집중했으나, 실제 배포 가능한 시스템을 구축할 때 발생하는 아키텍처적 제약 (다중 테넌시 격리, 접근 제어, 비동기 처리, 검색 범위 제한 등) 에 대한 연구는 부족합니다.
• 핵심 질문: 대화형 코드 생성이 단순한 기능 구현을 넘어, 엄격한 아키텍처 제약을 준수하는 프로덕션 시스템에서 어떻게 작동하며, 어떤 부분이 자동화되지 않는가?

2. 연구 방법론 (Methodology)

저자들은 2026 년 EASE 컨퍼런스를 위해 2 개의 실제 배포용 시스템을 개발하며 경험 기반 연구 (Experience Report) 를 수행했습니다.

• 개발 대상 시스템:
  1. 멀티 프로젝트 에이전트 학습 플랫폼: 조직 내 여러 프로젝트가 격리된 상태에서 공유 지식을 학습하는 시스템. (구조화된 메모리, 엄격한 테넌트 격리 필요)
  2. 학술용 RAG (Retrieval-Augmented Generation) 시스템: 문서 기반 답변 생성 및 인용 추적, 역할 기반 접근 제어 (RBAC) 가 필요한 시스템.
• 개발 접근 방식 (Vibe Coding):
  • 개발자가 기능 요구사항과 아키텍처 제약을 명시적으로 프롬프트에 포함하여 AI 에게 코드를 생성하게 함.
  • 생성된 코드 (API 라우트, 데이터 모델, 유틸리티 등) 를 반복적으로 수정하고 통합.
• 검증 전략:
  • 구조적 수동 테스트: 다양한 역할과 프로젝트 컨텍스트에서 사용자 상호작용 시뮬레이션.
  • 코드 검토: 데이터베이스 쿼리, 인증 로직, 검색 로직이 의도된 제약을 준수하는지 확인.
  • 런타임 로그 분석: 비동기 파이프라인의 동시 실행 및 백그라운드 작업 모니터링.
• 증거원: 커밋 히스토리, 이슈 토론, 프롬프트 반복 기록, 배포 로그, 내부 구현 노트 등.

3. 주요 기여 (Key Contributions)

1. 실무 경험 보고: 대화형 코드 생성을 사용하여 두 개의 프로덕션 지향 AI 시스템을 구축한 실제 사례와 교훈을 제시.
2. 검증 관행 제시: 테넌트 격리, 역할 분리, 검색 범위 제한, 비동기 실행 등 아키텍처 속성을 확인하기 위한 검증 방법론을 기술.
3. '위임 불가 영역 (Non-Delegation Zones)' 식별: AI 생성 스템플링 (Scaffolding) 에 위임할 수 없고, 반드시 수동 엔지니어링 결정이 필요한 반복적인 아키텍처 작업을 규명.

4. 연구 결과 및 교훈 (Results & Lessons Learned)

• AI 의 강점과 약점:

  • 강점: API 라우트, 데이터 모델, UI 컴포넌트, 유틸리티 함수 등 보일러플레이트 (Boilerplate) 코드 생성과 초기 스템플링 속도를 획기적으로 단축.
  • 약점: 명시적으로 정의되지 않은 **아키텍처 제약 조건 (격리 규칙, 접근 제어, 메모리 정책, 비동기 처리)**을 생성된 코드가 자주 무시하거나 누락함.
    • 예시: 초기 생성된 백엔드 코드는 프로젝트별 필터링을 누락하여 데이터 유출 위험을 초래하거나, 비동기 처리가 필요한 작업을 동기식으로 구현하여 성능 저하를 유발.

• 엔지니어링 노력의 이동 (Shift in Engineering Effort):

  • 감소한 노력: 보일러플레이트 작성, CRUD 스템플링, 기본 라우팅, UI 템플릿 생성.
  • 증가한 노력: 아키텍처 설계, 격리 감사 (Auditing), 정책 명세, 생성 코드 검증 및 모니터링.
  • 결론: 개발자의 역할이 '코드 작성'에서 '제약 조건 정의 및 생성 코드 검증'으로 이동함.

• 핵심 교훈:

  1. 아키텍처 제약의 명시적 정의 필수: 모호한 프롬프트는 지역적으로 정확하지만 구조적으로 불완전한 코드를 생성함. 격리 규칙, 역할 확인, 백그라운드 로직은 명시적으로 지시해야 함.
  2. 정책 및 평가는 인간이 설계해야 함: 메모리 업데이트 시기나 인용 검증 기준과 같은 도메인 특화 정책은 AI 가 추론할 수 없으므로 인간이 정의해야 함.
  3. 인프라 결정은 지연할 수 없음: 초기 프로토타입에서 동기식 처리를 사용하면 재사용 시 불안정해짐. 백그라운드 워커, 캐싱, 모니터링은 초기 설계 단계에서 필수적임.
  4. 위임 불가 영역 (Non-Delegation Zones): 다중 테넌시 격리, 접근 제어, 메모리 업데이트 정책, 배포 구성 등은 AI 에게 위임하기 어렵고 수동 검토가 필수임.

5. 의의 및 시사점 (Significance)

• 실용적 통찰: 생성형 AI 가 프로덕션 환경에서 '만능 도구'가 아님을 보여줌. AI 는 빠른 구현을 위한 도구일 뿐, 시스템 수준의 설계 (System-level Design) 를 대체하지 못함.
• 새로운 개발 패러다임: 성공적인 AI 보조 개발은 명확하게 정의된 아키텍처 경계 내에서 AI 를 활용하는 것이며, 개발자는 생성된 코드의 아키텍처적 무결성을 검증하고 감사하는 역할에 집중해야 함.
• 향후 연구 방향: 대규모 팀과 고규모 배포 환경에서 대화형 코드 생성을 지원하는 개발 관행, 검증 전략, 아키텍처 패턴에 대한 추가 연구 필요.

요약하자면, 이 논문은 "코드 생성 전 컨텍스트 (명시적 아키텍처 제약)"가 없으면 AI 가 생성한 코드는 프로덕션 환경에서 신뢰할 수 없음을 증명하며, 개발자의 핵심 역량이 '코드 작성'에서 '제약 조건 설계 및 검증'으로 이동하고 있음을 시사합니다.