바이브 코딩을 넘어 AI 시대 개발 프로세스

2025년 2월, Andrej Karpathy가 X(트위터)에 짧은 글을 올렸다. “바이브 코딩(Vibe Coding)”이라는 표현이었다. AI에 완전히 몸을 맡기고, 코드가 존재한다는 사실조차 잊어버리는 새로운 개발 방식. 그 글은 며칠 만에 수백만 건의 조회 수를 기록했고, 이후 뉴욕타임스·가디언·아스 테크니카가 연달아 보도했다. 콜린스 영어사전은 2025년의 단어로 ‘vibe coding’을 선정했다.

이처럼 AI와 협업하는 개발 방식은 빠르게 확산되고 있다. 개발자는 이제 코드를 직접 작성하기보다 AI와 함께 생산하는 환경에 놓이게 되었다. Karpathy가 2023년 남긴 말처럼, “The hottest new programming language is English.” 코딩 도구의 발전이 아니라 소프트웨어 개발 방식 자체가 달라지고 있다.

그런데 바이브 코딩으로 프로젝트를 키워가다 보면 새로운 문제가 나타난다. 기능 하나는 빠르게 구현되지만, 기능이 쌓일수록 코드 구조가 무너진다. 대화 세션이 끊기면 어제의 맥락이 사라지고, AI는 같은 질문에 다른 구조의 코드를 내놓는다. 결국 “빠르게 만들었지만 유지보수할 수 없는 코드”가 쌓이는 상황이 반복된다. 문제의 본질은 AI의 코드 생성 능력이 아니라, 프로젝트 상태를 어떻게 유지하느냐에 있다.

AI 협업 개발의 흐름을 돌아보면, 단순한 도구 발전이 아니라 문제를 해결하기 위한 패러다임의 연쇄적 진화임을 알 수 있다. 현재까지의 흐름은 네 단계로 정리된다.

중요한 점은, 이 네 단계가 서로를 대체하는 관계가 아니라 레이어처럼 쌓이는 관계라는 것이다. 하네스 엔지니어링을 도입하더라도 좋은 프롬프트와 정교한 컨텍스트는 여전히 필요하다. 각 단계는 AI가 수행할 수 있는 역할의 확장이자, 이전 단계의 한계를 보완하는 새로운 층이다.

AI 코딩 초기에 가장 널리 사용된 방법이다. 개발자가 자연어 프롬프트로 AI에게 역할과 행동 규칙을 전달하는 방식이다.

너는 시니어 소프트웨어 엔지니어야.
클린 아키텍처 원칙에 따라 해당 기능을 구현하는 TypeScript 코드를 만들어줘.

프롬프트 엔지니어링의 한계를 극복하기 위해 등장한 접근이다. 프롬프트 대신 프로젝트 문맥을 구조적으로 제공하는 방식으로, 규칙 파일(`.cursorrules`), 에이전트 규칙(`agent.md`), 스킬 정의(`skills.md`) 같은 파일을 통해 프로젝트 아키텍처, 코드 스타일, 사용 가능한 도구, 개발 규칙을 AI에게 전달한다. 이 접근은 AI가 단순한 코드 생성 도구를 넘어 프로젝트 맥락을 이해하는 협업 도구로 동작하도록 만들었다.

다만 컨텍스트 엔지니어링도 완전한 해결책은 아니다. 컨텍스트 파일을 사람이 직접 작성하고 유지해야 하고, 프로젝트가 커질수록 관리 비용이 늘어난다. 컨텍스트 윈도우 제한으로 모든 정보를 전달하기 어렵다는 근본적인 제약도 있다. 맥락 제공 문제는 개선했지만, 실행 자동화 문제는 여전히 남아 있었다.

LLM 기술이 발달하면서 AI가 스스로 작업을 수행하는 에이전트 기반 개발 방식이 등장했다. 에이전트는 단일 응답을 넘어 파일 탐색 → 코드 수정 → 테스트 실행 → 오류 분석 → 코드 수정이라는 작업 루프를 반복하며 개발을 진행한다. 개발자의 작업 흐름과 유사한 형태다.

개발 생산성은 크게 향상되었다. 그러나 에이전트 기반 개발도 새로운 문제를 낳는다. 실행 비용이 증가하고, 결과를 예측하기 어려우며, 프로젝트 구조가 붕괴될 위험이 생긴다. 권한 관리 문제도 따라온다. 에이전트는 실행 능력을 크게 확장했지만, 개발 과정 자체를 통제하는 메커니즘은 여전히 부족했다.

개발 과정 통제 문제를 해결하기 위해 등장한 접근이 하네스 엔지니어링이다. 이 개념은 2026년 2월 OpenAI가 Codex 팀의 내부 실험 결과를 공개하면서 급속히 확산됐다. Codex 에이전트가 5개월간 수동으로 작성된 코드 없이 100만 줄 규모의 프로덕션 소프트웨어를 구축한 사례로, AI가 작업을 수행하는 환경 자체를 제어하고 검증하는 실행 프레임워크를 의미한다.

AI 개발 환경에서 하네스는 실행 환경 관리, 도구 호출 제어, 실행 결과 검증, 작업 루프 제어, 안전 장치 제공의 역할을 수행한다. AI 에이전트를 직접 통제하기 위한 운영 레이어다. 랄프 모드(Ralph Mode)와 같은 실험적 개발 패턴과 결합되면서 AI 기반 개발 환경을 보다 안정적으로 운영할 수 있는 기반도 마련되고 있다.

이 흐름을 한 줄로 정리하면 이렇다.

프롬프트 엔지니어링(자연어 인터페이스) → 컨텍스트 엔지니어링(프로젝트 맥락 제공) → 에이전트 엔지니어링(자율 실행) → 하네스 엔지니어링(실행 환경 제어)

AI가 할 수 있는 일이 늘어날수록, 개발자의 역할은 점점 설계와 운영으로 이동한다.

AI와 협업하는 개발 환경에서는 기존 개발 프로세스만으로 충분하지 않다. AI는 코드 생성 능력은 뛰어나지만, 문제 정의와 구조 유지에는 약점이 있기 때문이다. 이를 보완하기 위해 다음과 같은 7단계 프로세스를 정의해 사용한다.

1. 정의(Define): 무엇을 만들고 무엇을 만들지 않을지 정의한다.
2. 설계(Design): 코딩 전에 구조를 설계한다.
3. 완료 기준(DoD): Definition of Done, 완료 기준을 정의한다.
4. 빌드(Build): 작은 단위로 구현한다.
5. 검증(Verify): 테스트·보안·구조 검증을 수행한다.
6. 기록(Record): 다음 세션을 위해 결과를 기록한다.
7. 실패 처리(Recovery): 실패 원인을 분류하고 복구한다.

이 프로세스의 핵심은 “AI를 잘 사용하는 법”이 아니다. AI가 약한 부분을 프로세스로 보완하는 것이다.

프로세스가 작동하려면 컨텍스트를 저장하는 인프라가 필요하다. 이를 위해 고정 파일 4개를 사용한다.

• project_context.md: 문제·범위·리스크를 고정한다.
• architecture.md: 구조 규칙을 고정한다.
• acceptance.md: 완료 기준(DoD)을 고정한다.
• session_context.md: 세션 단위 목표·태스크·결과를 휘발성으로 관리한다.

앞의 세 파일(`project_context.md`, `architecture.md`, `acceptance.md`)은 프로젝트 전체에 걸쳐 고정되는 컨텍스트이고, `session_context.md`는 세션 단위로 갱신되는 휘발성 컨텍스트다. 세션 컨텍스트는 짧아야 하고, 프로젝트 컨텍스트는 고정되어야 한다. 이 파일들을 기반으로 각 단계를 어떻게 하는지 설명한다.

단순 바이브 코딩이 얼마나 위험한지, 그리고 7단계 프로세스가 그 위험을 어떻게 해결하는지 연속 출석체크 시스템을 만들며 살펴본다.

게임에서 “7일 연속 접속 시 전설 아이템 지급!” 같은 이벤트는 흔하다. 단순해 보이기 때문에 “유저가 매일 접속할 때마다 출석 일수가 1씩 오르는 코드를 짜줘. 하루라도 안 들어오면 0으로 초기화해”라고 AI에 맡기면 그럴싸한 코드가 나온다.

이 코드를 검수 없이 라이브 서버에 배포하면 대참사가 일어난다. 코드는 한국 서버 시간을 기준으로 작성되었을 가능성이 크고, 뉴욕에 사는 유저가 현지 시간으로 같은 날로 인식되어 출석이 인정되지 않거나 연속 출석이 끊겨버린다. AI가 시간대(Timezone)와 글로벌 서비스 맥락을 스스로 유추하지 못하기 때문이다.

이제 동일한 기능을 7단계 프로세스로 구현해 보자.

기능의 목적과 범위를 명확히 전달한다.

목표
글로벌 유저 대상 연속 출석체크 API 구현

성공 기준
출석 상태 계산이 모든 시간대에서 일관되게 동작한다.

비범위
아이템 지급 로직
보상 이벤트 관리 시스템
관리자 페이지

AI가 문제 범위를 잘못 확장하는 것을 방지한다. 문제 정의가 어렵다면 AI와 소크라틱 대화를 활용하는 것도 방법이다. 5분간 인터뷰 형식으로 질문을 주고받으면 오류 케이스를 사전에 정리하는 효과가 있다.

코드를 작성하기 전에 시스템 구조를 먼저 정의한다.

/features/attendance
 ├ attendance.controller.ts
 ├ attendance.service.ts
 ├ attendance.repository.ts
 └ attendance.model.

데이터 모델도 함께 정의한다.

attendance
  user_id
  current_streak
  last_check_date
  timezone

핵심 설계 규칙은 다음과 같다. 날짜 계산은 서버 시간이 아닌 유저 타임존 기준으로 한다. 하루 기준은 UTC 날짜 변환 후 비교한다. 출석 체크는 하루 한 번만 허용한다. 이 구조는 architecture.md에 기록한다.

1. 출석 체크 API 정상 동작
2. 하루 2회 요청 시 중복 출석 방지
3. 타임존 테스트 통과
4. 에러 처리 구현
5. 테스트 코드 작성
6. API 문서 업데이트

AI의 “완료”와 개발자의 “완료”는 다르다. AI는 코드가 동작하면 끝이라고 판단하지만, 실제 개발에서는 다양한 완료 기준이 있다.

이 기준은 acceptance.md에 저장한다.

Task 1 — attendance model 생성
Task 2 — attendance repository 구현
Task 3 — 출석 streak 계산 로직 구현
Task 4 — attendance API 생성

기능을 작은 단위로 나누어 구현한다. 각 작업은 독립적으로 테스트 가능해야 한다.

기능 테스트  — 연속 출석 증가 확인
경계 테스트  — 하루 차이 계산 / 타임존 변경
예외 테스트  — 동일 날짜 중복 요청 / 과거 날짜 요청

단순한 코드 리뷰 요청 대신 자동 검증을 수행한다.

완료
 - attendance API 구현
 - streak 계산 로직 구현

남은 작업
 - 보상 지급 로직

다음 작업
 - reward service 설계

AI와의 대화 세션은 언제든 끊길 수 있고, 끊기면 맥락이 사라진다. 다음 세션에서 맥락을 다시 구축하는 비용을 줄이기 위해, 세션이 끝날 때마다 session_context.md에 결과를 기록한다.

기록은 단순한 회고가 아니다. 다음 세션을 위한 컨텍스트를 생성하는 작업이다.

AI 작업이 실패했을 때 무작정 재시도하는 것은 같은 실패를 반복할 뿐이다. 실패 원인을 먼저 분류하고, 원인에 맞는 복구 전략을 택해야 한다.

• 컨텍스트 부족: AI가 타임존 정보를 고려하지 않았다면 project_context.md에 “출석 계산은 유저 타임존 기준으로 한다.”를 추가한다.
• 방향 부족: AI가 출석 시스템 대신 보상 시스템까지 구현했다면 Define 단계로 돌아가 범위를 다시 고정한다.
• 구조 충돌: AI가 기존 아키텍처와 다른 구조를 생성했다면 /features/attendance 구조 규칙을 재적용한다고 알려준다.

단순 바이브 코딩의 흐름이 “기능 요청 → 코드 생성 → 배포 → 글로벌 버그 발생”이라면, 7단계 프로세스는 AI의 코드 생성 능력을 통제 가능한 개발 프로세스로 변환한다.

AI 코딩 도구는 개발 생산성을 크게 향상시켰다. 그러나 AI가 코드를 잘 작성한다고 해서 개발 프로세스가 자동으로 정리되는 것은 아니다.

AI 협업 개발의 핵심은 “코드를 생성하는 능력이 아니라 프로젝트 상태를 유지하는 능력”이다. 개발자는 타이핑하는 역할에서 벗어났을 뿐, 엔지니어링 자체는 여전히 필요하다.

이번 세션은 아래 프로세스를 따른다.

1. Define   — 목표 / 성공 기준 / 비범위 정의
2. Design   — 코딩 없이 설계와 구조 정리
3. DoD      — 완료 기준 정의
4. Build    — 작은 태스크로 구현
5. Verify   — 테스트 / 보안 / 구조 검증
6. Record   — 세션 결과 기록
7. Recovery — 실패 원인을
              컨텍스트 부족 / 방향 오류 / 구조 충돌
              로 분류하고 수정한다.

지금은 1단계(Define)부터 시작한다.

• 에이전틱 엔지니어링 생존 스킬 9가지
• 에이전틱 엔지니어링 패턴
• Harness engineering: leveraging Codex in an agent-first world
• 명세 우선 방식의 AI 개발 시스템
• 에이전틱 코딩을 위한 도구
• The 8 Levels of Agentic Engineering
• everything is a ralph loop
• ralph github