하네스, 의존성 그리고 유지보수성

바이브 코딩으로 사이드 프로젝트를 만드는 것과 실제 회사 제품을 만드는 것은 꽤 다른 문제입니다.

간단한 웹 서비스나 개인용 도구라면 AI에게 요구사항을 설명하고 몇 차례 수정하는 것만으로도 제법 그럴듯한 결과물이 나옵니다. 최근 모델은 화면을 만들고 API를 붙이고, 데이터베이스를 연결하고 테스트 코드까지 생성하는 능력이 상당히 좋아졌습니다.

여기에 AGENTS.md, 프로젝트 규칙, 테스트, 린터, 코드 생성 규칙, 아키텍처 제약 같은 이른바 하네스를 잘 구성하면 결과도 한층 안정적이 됩니다.

그러다 보면 자연스럽게 이런 생각이 듭니다.

좋은 하네스만 만들면 AI가 알아서 좋은 제품을 만들어주지 않을까?

충분히 매력적인 생각입니다.
하지만 실제 제품 개발은 그렇게 단순하지 않습니다.

문제는 AI가 코드를 생성하지 못한다는 데 있지 않습니다.
오히려 지금의 AI는 처음 만드는 작업에는 상당히 강합니다.

진짜 어려운 문제는 그다음입니다.

이미 만들어진 제품을 계속 수정하면서도 기존 구조를 무너뜨리지 않는 것.

바이브 코딩이 프로토타입을 넘어 실제 제품 개발 단계로 들어가면 결국 이 문제와 만나게 됩니다.

---

하네스는 중요하지만 제품 설계를 대신하지 못합니다

먼저 하네스가 필요 없다는 이야기는 아닙니다.
AI 코딩에서 하네스는 꽤 중요합니다.

예를 들면 다음과 같은 것들을 넓은 의미의 하네스로 볼 수 있습니다.

• 코딩 컨벤션
• 디렉터리 및 패키지 구조
• AGENTS.md, CLAUDE.md 같은 저장소 규칙
• 정적 분석
• 린터와 포매터
• 단위 테스트와 통합 테스트
• CI 파이프라인
• 아키텍처 테스트
• API 계약
• 금지된 의존성 규칙
• 변경 가능한 파일 범위
• 코드 리뷰 규칙
• 에이전트가 사용할 수 있는 도구와 권한

이런 장치들은 AI가 프로젝트의 규칙을 무시하거나 엉뚱한 방향으로 코드를 변경하는 것을 어느 정도 막아줍니다.

하지만 전제가 하나 있습니다.

우리가 원하는 소프트웨어 구조가 무엇인지 먼저 알고 있어야 합니다.

AI에게

Controller에서 Repository를 직접 호출하지 마.

라고 지시하려면 왜 그렇게 하면 안 되는지 사람이 먼저 이해하고 있어야 합니다.

마찬가지로

이 기능은 billing 모듈에 넣고 order에서는 인터페이스만 참조해.

라고 지시하려면 현재 시스템의 책임과 의존성 구조를 알고 있어야 합니다.

결국 하네스는 설계를 대신 만들어주는 장치라기보다는 이미 정한 설계와 규칙에서 AI가 벗어나지 않도록 잡아주는 가드레일에 가깝습니다.

좋은 하네스가 좋은 설계를 대신해주지는 않습니다.

---

제품은 처음부터 완전히 정의하기 어렵습니다

여기서 더 근본적인 문제가 하나 생깁니다.

제품 개발에서는 애초에 무엇을 만들어야 하는지 처음부터 완벽하게 알기 어려운 경우가 많습니다.

처음에는 요구사항이 명확해 보입니다.

개발을 시작해서 실제 화면을 만들어보고 사용자에게 보여줍니다.
그러면 이야기가 달라지기 시작합니다.

이건 생각했던 것과 조금 다른데요?

이 기능보다 이게 더 중요한 것 같습니다.

실제로 사용해보니까 이 흐름은 너무 불편합니다.

QA 과정에서는 예상하지 못했던 문제가 나오고, 운영에 올리고 나면 또 다른 문제가 생깁니다.

실제 제품은 보통 이런 과정을 반복하면서 구체적인 모습을 갖춰갑니다.

가설 → 구현 → 검증 → 피드백 → 수정

애자일 개발에서 반복적인 개발이 중요한 이유도 여기에 있습니다.

모든 프로젝트가 큰 피벗을 하는 것은 아닙니다.
하지만 피드백을 받으면서 기능의 우선순위가 바뀌고, 처음 세웠던 가설이 깨지기도 합니다. 경우에 따라서는 제품 방향 자체가 달라질 수도 있습니다.

결국 제품 개발에서 중요한 것은 처음부터 완벽한 설계도를 만들어놓는 게 아닙니다.

변화를 받아들일 수 있는 구조를 만드는 것이 더 중요합니다.

바이브 코딩을 사용한다고 해서 이 과정이 사라지지는 않습니다.
AI가 개발 속도를 높여줄 수는 있어도 사용자의 피드백이나 제품이 가진 불확실성까지 없애주지는 못합니다.

---

처음 잘 만들어졌다고 제품 개발이 끝난 것은 아닙니다

바이브 코딩을 처음 해보면 꽤 강한 인상을 받습니다.

예를 들어 AI에게 이렇게 요청합니다.

로그인 기능 만들어줘.
사용자 목록 화면 만들고 검색 기능 붙여줘.
Supabase 연결해서 CRUD 만들어줘.

얼마 지나지 않아 실제로 동작하는 화면이 나옵니다.

버튼도 눌리고 데이터도 저장됩니다. 이 정도면 제품의 상당 부분이 이미 완성된 것처럼 느껴질 수 있습니다.

하지만 프로토타입의 복잡성과 실제 제품의 복잡성은 다릅니다.

단순한 검색 버튼 하나만 생각해보겠습니다.

처음에는 다음 정도만 구현해도 됩니다.

버튼 클릭
→ API 호출
→ 결과 표시

운영 환경으로 들어가면 고려해야 할 것이 갑자기 늘어납니다.

사용자가 버튼을 여러 번 누르면 어떻게 할까요?

API 요청 중에는 버튼을 막을까요?

동일한 요청이 여러 번 서버에 들어오면 어떻게 처리해야 할까요?

요청이 타임아웃되면 어떻게 해야 할까요?

재시도는 가능한가요?

중복 요청은 어떻게 막아야 할까요?

실패했을 때 사용자에게 어떤 상태를 보여줘야 할까요?

서버가 여러 대라면 동시성 문제는 없을까요?

결국 단순했던 기능 주변에 이런 요구사항이 하나씩 붙기 시작합니다.

동시성
멱등성
재시도
트랜잭션
타임아웃
캐시
권한
감사 로그
예외 처리
모니터링
데이터 정합성
장애 복구

이때부터 실제 제품의 복잡성이 드러납니다.

초기 바이브 코딩이 유독 잘 되는 것처럼 보이는 이유 중 하나도 여기에 있습니다.
AI가 처음부터 완벽해서라기보다 아직 시스템에 쌓인 제약과 변경 이력이 많지 않기 때문입니다.

---

AI는 ‘완성’에는 강하지만 ‘증분 변경’에서는 어려움을 겪습니다

현재 AI 코딩의 특징 중 하나입니다.

AI에게

이 기능을 만들어줘.

라고 요청하면 상당히 적극적으로 목표를 달성하려고 합니다.

필요하면 새 파일을 만들고 기존 코드도 수정합니다. 구조가 다소 거칠더라도 일단 동작하는 결과부터 만들어내는 경우도 있습니다.

문제는 제품 개발이 한 번의 구현으로 끝나지 않는다는 점입니다.

예를 들어 처음에 70% 정도 완성된 시스템이 있다고 해보겠습니다.

개발자가 원하는 것은 매번 새로운 시스템을 다시 만드는 것이 아닙니다.

70 → 73 → 76 → 79 → 82 → 85

기존 시스템을 유지하면서 조금씩 개선해 나가고 싶은 겁니다.

그런데 AI에게 수정 작업을 계속 맡기다 보면 어느 순간 이런 문제가 나타날 수 있습니다.

기능 A 수정
↓
관련 없어 보이던 B 변경

기능 B 수정
↓
C 테스트 실패

C 수정
↓
기존 A 동작 변경

결국 Git으로 되돌리고 다시 시도하는 일이 반복됩니다.

코드베이스가 커질수록 AI가 함께 고려해야 할 문맥도 늘어납니다.

처음에는 몇 개 파일만 파악하면 되지만, 시간이 지나면 수십 개의 모듈과 규칙, API, 테스트, 기존 설계 결정까지 함께 고려해야 합니다.

AI가 어려운 프로그램을 아예 만들지 못한다는 이야기는 아닙니다.

어려운 프로그램을 한 번 생성하는 것과 이미 존재하는 복잡한 프로그램을 수백 번 안전하게 변경하는 것은 서로 다른 문제입니다.

실제 제품 개발에서는 후자가 훨씬 중요합니다.

---

그래서 필요한 것이 ‘수정에 강한 구조’입니다

바이브 코딩으로 유지보수 가능한 제품을 만들려면 결국 전통적인 소프트웨어 설계 문제로 돌아오게 됩니다.

핵심은 오래된 원칙 하나로 정리할 수 있습니다.

변경 이유가 다른 코드는 분리합니다.

흔히 이것을 책임이라고 표현합니다.

책임을 단순히

이 클래스가 무슨 일을 하는가?

정도로만 이해하면 조금 부족합니다.

실무에서는 다음 질문으로 접근하는 편이 훨씬 이해하기 쉽습니다.

이 코드는 어떤 이유로 변경되는가?

예를 들어 보험 가입 가능 연령이 현재 24세 이상이라고 해보겠습니다.

if (age >= 24) {
    // 가입 가능
}

어느 날 정책이 바뀌어 가입 가능 연령이 24세에서 22세로 내려갑니다.

여기에 알고리즘적으로 대단한 이유가 있는 것은 아닙니다.
상품 정책이 바뀌었기 때문에 코드도 바뀐 겁니다.

다른 코드도 생각해볼 수 있습니다.

• 프로모션 정책이 바뀌면 수정되는 코드
• 세법이 바뀌면 수정되는 코드
• 회원 등급 정책이 바뀌면 수정되는 코드
• 외부 PG사가 바뀌면 수정되는 코드
• 개인정보 처리 정책이 바뀌면 수정되는 코드
• 화면 UX가 바뀌면 수정되는 코드

각각 변경되는 이유가 다릅니다.

그렇다면 가능하면 이런 코드들이 한 덩어리로 묶여 있지 않는 편이 좋습니다.

이것이 책임 분리를 실무적으로 이해하는 방법입니다.

---

책임을 ‘변화율’ 관점에서 바라보기

책임을 이해할 때 변화율이라는 관점도 유용합니다.

여기서 말하는 변화율은 단순히 "얼마나 자주 바뀌는가"만 뜻하지 않습니다.

조금 더 정확하게 표현하면 다음 두 가지를 같이 보는 개념입니다.

왜 바뀌는가 + 어떤 주기로 바뀌는가

예를 들어 다음과 같은 코드가 있다고 해보겠습니다.

A: 매주 프로모션 정책 때문에 변경
B: 법령이 바뀔 때 변경
C: 외부 업체 API가 바뀔 때 변경
D: 제품 가격 정책이 바뀔 때 변경
E: 조직 정책이 바뀔 때 변경

각각 변경 원인이 다릅니다.

그런데 이 다섯 가지가 하나의 거대한 Service 클래스 안에 모두 들어가 있다면 문제가 생깁니다.

하나의 정책만 수정해도 다른 코드에 영향을 줄 가능성이 커집니다.

AI에게 수정 작업을 맡길 때는 이 문제가 더 크게 드러날 수 있습니다.
AI가 주어진 목표를 완수하기 위해 주변 코드까지 함께 수정할 수 있기 때문입니다.

반대로 변경 이유에 따라 코드가 잘 나뉘어 있다면 AI에게도 훨씬 구체적으로 지시할 수 있습니다.

회원 등급 정책만 변경한다.

membership-policy 모듈 외의 비즈니스 로직은 수정하지 않는다.

Order와 Payment 모듈의 public contract는 변경하지 않는다.

변경 후 membership 관련 테스트만 먼저 실행하고
전체 회귀 테스트를 실행한다.

이렇게 하면 AI가 탐색하고 수정해야 할 범위가 크게 줄어듭니다.

바이브 코딩에서도 좋은 설계가 중요한 이유입니다.

---

분리만으로는 부족합니다. ‘격리’가 필요합니다

코드를 여러 파일이나 패키지로 나눴다고 해서 유지보수성이 자동으로 생기는 것은 아닙니다.

파일은 나뉘어 있어도 서로 강하게 의존하고 있다면 사실상 하나의 덩어리와 다르지 않습니다.

그래서 책임을 나눈 다음에는 격리가 필요합니다.

격리에서 가장 중요한 요소 중 하나가 의존성입니다.

그렇다고 의존성을 완전히 없앨 수는 없습니다.
소프트웨어의 구성 요소는 결국 서로 협력해야 하기 때문입니다.

중요한 것은 두 가지입니다.

필요한 만큼만 의존하고, 가능하면 의존성의 방향을 명확하게 유지하는 것.

예를 들어 다음과 같은 구조가 있다고 해보겠습니다.

Controller
   ↓
Application
   ↓
Domain
   ↓
Port
   ↑
Infrastructure

중요한 것은 모든 프로젝트를 반드시 이 구조로 만들어야 한다는 이야기가 아닙니다.

핵심은 누가 누구를 알고 있는지 명확해야 한다는 것입니다.

A가 B를 호출하는데 B가 다시 A의 내부 구현을 알고 있다면 변경의 영향을 계산하기가 어려워집니다.

의존성이 여러 모듈을 거친 뒤 다시 원래 모듈을 참조하기 시작하면 순환 의존성도 생길 수 있습니다.

A → B → C → D
↑           ↓
└───────────┘

이런 구조에서는 작은 변경 하나가 어디까지 영향을 미칠지 예상하기 어렵습니다.

사람이 파악하기도 어렵고 AI가 수정 범위를 판단하기도 어렵습니다.

그래서 바이브 코딩에서는 단순한 코드 생성 능력보다 변경 범위를 제한할 수 있는 아키텍처가 중요해집니다.

---

그렇다면 테스트와 하네스는 필요 없는 걸까요?

전혀 그렇지 않습니다.

오히려 AI 코딩에서는 테스트와 하네스의 중요성이 더 커질 수 있습니다.

다만 역할을 정확하게 구분해야 합니다.

테스트가 좋은 설계를 자동으로 만들어주는 것은 아닙니다.

하네스도 마찬가지입니다.

둘의 역할은 대체로 다음과 같습니다.

AI 행동 범위 제한
        +
설계 규칙 검증
        +
변경 결과 검증
        +
회귀(regression) 탐지

단위 테스트를 수천 개 만들어놓는다고 유지보수성이 자동으로 생기지는 않습니다.

테스트가 모두 통과하더라도 코드 구조 자체는 엉망일 수 있습니다.

반대로 구조가 아무리 잘 잡혀 있어도 테스트가 없다면 AI가 기존 동작을 깨뜨렸는지 확인하기 어렵습니다.

결국 실제 제품 개발에서는 세 가지가 함께 필요합니다.

설계 + 하네스 + 피드백 루프

어느 하나만으로 해결할 수 있는 문제는 아닙니다.

---

범용 하네스가 모든 프로젝트에서 통하지 않는 이유

인터넷에는 다양한 AI 코딩 규칙이 공유되고 있습니다.

누군가 만든 AGENTS.md를 내려받거나 유명한 프로젝트의 규칙을 가져와 사용하는 것도 출발점으로는 괜찮습니다.

하지만 그대로 복사했다고 해서 우리 프로젝트의 유지보수성까지 해결되는 것은 아닙니다.

이유는 간단합니다.

제품마다 코드가 변경되는 이유가 다르기 때문입니다.

쇼핑몰과 병원 EMR은 다릅니다.

금융 시스템과 커뮤니티 서비스도 다릅니다.

같은 쇼핑몰이라고 해도 회사마다 프로모션, 주문, 결제, 물류 정책이 모두 다를 수 있습니다.

오랫동안 운영된 시스템이라면 조직 구조와 업무 방식까지 코드에 남아 있는 경우도 많습니다.

범용 하네스가 제공할 수 있는 것은 결국 이런 설계 원칙에 가깝습니다.

순환 의존성을 만들지 않는다.
Controller에 비즈니스 로직을 넣지 않는다.
한 파일을 지나치게 크게 만들지 않는다.
public contract 변경을 최소화한다.
테스트 없는 기능 변경을 금지한다.

이런 규칙은 충분히 유용합니다.

하지만 다음과 같은 질문은 이야기가 달라집니다.

주문 취소 정책은 어느 모듈에 있어야 하는가?

환불 정책과 쿠폰 복원 정책은 같은 책임인가?

외부 PG 장애 대응은 Payment 도메인인가 Infrastructure인가?

이런 문제는 프로젝트의 구조와 도메인을 이해하지 않고서는 판단하기 어렵습니다.

결국 AI에게도 제품별 지도가 필요합니다.

---

바이브 코딩 초반에는 사람이 더 많이 개입해야 합니다

새 프로젝트를 AI와 시작할 때 오히려 조심해야 할 시점이 초반입니다.

아직 코드가 적기 때문에 AI가 상당히 잘하고 있는 것처럼 보입니다.

문제는 이 시기에 만들어진 구조가 이후 기능의 기준이 된다는 점입니다.

초기 코드가 다음과 같이 만들어졌다고 해보겠습니다.

controller
 └ service
    └ repository

AI는 다음 기능을 구현할 때도 기존 코드를 참고해 비슷한 형태를 반복할 가능성이 높습니다.

그러다 보면 어느 순간 Service 하나가 수천 줄짜리 클래스가 될 수 있습니다.

반대로 초기부터

order
 ├ application
 ├ domain
 ├ infrastructure
 └ api

같은 기본 패턴을 만들고 책임을 어떻게 나눌지 기준까지 보여주면, 이후에는 AI가 기존 코드를 예제로 활용할 수 있습니다.

그래서 초반에는 비교적 구체적인 지시가 필요합니다.

단순히

쿠폰 기능 만들어줘.

라고 지시하기보다는 다음과 같이 범위와 구조를 함께 알려주는 편이 낫습니다.

쿠폰 기능을 추가한다.

Coupon 도메인은 Order와 분리한다.

Order는 Coupon 구현 클래스를 직접 참조하지 않는다.

쿠폰 적용 여부를 판단하는 정책은 CouponPolicy로 분리한다.

외부 이벤트 전달은 Port 인터페이스를 사용한다.

기존 public API는 변경하지 않는다.

작업 전에 변경할 파일 목록과 의존성 변화를 먼저 제시한다.

이런 작업이 몇 번 쌓이면 프로젝트 안에 살아 있는 예제가 생깁니다.

그때부터는 AI에게 이런 식으로 요청할 수 있습니다.

기존 membership 모듈의 구조를 기준으로 동일한 패턴으로 구현해.

이런 방식이 긴 프롬프트로 모든 규칙을 매번 설명하는 것보다 효과적인 경우가 많습니다.

코드베이스 자체가 하네스 역할을 하기 시작하는 겁니다.

---

AI에게 코딩보다 먼저 ‘변경 계획’을 요구합니다

AI 코딩에서 유용하게 사용할 수 있는 방법이 하나 있습니다.

바로 코드부터 수정시키지 않는 것입니다.

먼저 다음과 같이 요청합니다.

아직 코드를 수정하지 마.

이번 변경으로 영향을 받는 모듈을 분석하고
다음 내용을 먼저 제시해.

1. 변경 대상
2. 변경 이유
3. 변경하지 않아야 할 영역
4. 의존성 변화
5. 기존 테스트 영향
6. 추가해야 할 테스트

계획을 먼저 확인한 다음 실제 코드 수정을 요청합니다.

이 과정은 단순한 프롬프트 작성 요령으로만 볼 필요는 없습니다.

AI가 목표를 달성하기 위해 곧바로 여러 코드를 건드리는 것을 막고, 변경 범위를 먼저 정하는 장치로 사용할 수 있습니다.

한 번에 수정하는 범위도 가능하면 작게 유지하는 편이 좋습니다.

큰 요구사항
↓
작은 변경 단위
↓
테스트
↓
커밋
↓
다음 변경

AI를 사용하더라도 작은 변경과 짧은 피드백 루프가 여전히 중요한 이유입니다.

---

개발자의 역할은 ‘코드를 작성하는 사람’에서 ‘변경을 설계하는 사람’으로 이동합니다

AI 모델이 발전할수록 단순한 코드 생성 작업의 가치는 계속 낮아질 가능성이 있습니다.

API 하나를 만들거나 CRUD를 구현하고 화면 하나를 만드는 작업은 이미 상당 부분 자동화되고 있습니다.

그 대신 더 중요해지는 질문이 있습니다.

무엇을 만들어야 하는가

왜 이 코드가 변경되는가

어디까지 변경되어야 하는가

어떤 영역은 변경되면 안 되는가

어떤 의존성을 허용할 것인가

어떻게 검증할 것인가

이 질문에 답할 수 있는 능력입니다.

결국 전통적인 소프트웨어 설계와 크게 다르지 않습니다.

SRP, 응집도, 결합도, 정보 은닉, 의존성 역전, 모듈화 같은 오래된 개념이 AI 시대에도 다시 중요해지는 이유가 여기에 있습니다.

AI가 더 많은 코드를 작성할수록 오히려 그 코드가 어디에 들어가야 하는지를 판단하는 능력의 가치가 커집니다.

---

좋은 바이브 코딩은 AI에게 모든 자유를 주는 것이 아닙니다

바이브 코딩을 AI에게 모든 것을 맡기는 방식으로 접근하면 실제 제품 개발 단계에서 빠르게 한계가 나타날 수 있습니다.

그렇다고 모든 구현 방법을 규칙으로 묶어버리면 AI를 사용하는 장점이 줄어듭니다.

결국 둘 사이의 균형이 필요합니다.

AI에게 구현 방법을 탐색할 여지는 주되 다음과 같은 부분은 사람이 관리해야 합니다.

책임의 경계
의존성 방향
변경 가능한 범위
외부 계약
테스트 조건

즉,

What은 명확하게 제한하고 How에는 어느 정도 자유를 주는 방식

에 가깝습니다.

무엇을 만들어야 하고 무엇을 건드리면 안 되는지는 분명히 정하되, 구체적인 구현 방법까지 사람이 모두 지정할 필요는 없다는 뜻입니다.

---

결국 문제는 ‘생성’이 아니라 ‘변화 관리’입니다

바이브 코딩을 이야기할 때는 흔히 모델의 코딩 능력에 관심이 쏠립니다.

어떤 모델이 코드를 더 잘 만드는지, 어떤 프롬프트가 좋은지, 어떤 하네스를 사용해야 하는지가 주요 관심사가 됩니다.

물론 모두 중요합니다.

하지만 실제 제품에서는 더 근본적인 질문을 해야 합니다.

이 코드를 앞으로 100번 수정할 수 있는가?

첫 번째 구현을 성공시키는 일은 점점 쉬워지고 있습니다.

하지만 제품은 첫 번째 구현으로 끝나지 않습니다.

기능은 계속 추가되고 정책도 바뀝니다.

사용자가 새로운 요구사항을 제시하고 외부 시스템도 변경됩니다.

법과 조직도 바뀔 수 있습니다.

이런 변화가 몇 년 동안 계속 쌓입니다.

그래서 AI 시대의 소프트웨어 설계에서 중요한 목표는 단순히 AI가 많은 코드를 작성하도록 만드는 것이 아닙니다.

다음 변경에서도 AI가 안전하게 수정할 수 있는 구조를 만드는 것이 중요합니다.

이를 위해 필요한 원칙도 결국 익숙한 것들입니다.

책임을 나누고, 변경 이유를 분리하고, 의존성을 최소화하고, 방향을 통제하며, 테스트와 자동화된 검증으로 경계를 지키는 것.

하네스는 이 과정을 지키도록 만드는 좋은 도구가 될 수 있습니다.

하지만 하네스가 제품 자체를 이해해주는 것은 아닙니다.

제품이 왜 바뀌는지 이해하고 어떤 구조로 나눌지 결정하는 일은 여전히 개발자의 몫입니다.

그래서 바이브 코딩 시대에 개발자가 사라진다기보다는 개발자의 역할이 조금씩 달라지고 있다고 보는 편이 맞습니다.

코드를 한 줄씩 직접 작성하는 시간은 줄어들 수 있습니다.

대신

무엇을 바꿀 것인지, 어디까지 바꿀 것인지, 무엇과 분리할 것인지 결정하는 능력

이 더 중요해집니다.

결국 바이브 코딩의 경쟁력은 프롬프트를 길게 쓰는 능력에 있지 않습니다.

변경에 강한 소프트웨어를 설계하고, AI가 그 구조를 벗어나지 않도록 지도하는 능력에 있습니다.

결론

이번 내용을 정리하면서 바이브 코딩의 핵심은 결국 ‘얼마나 빨리 코드를 만들어내느냐’보다 ‘만들어진 코드를 얼마나 안전하게 계속 바꿀 수 있느냐’에 있다는 생각이 들었습니다.

처음에는 AI가 코드를 빠르게 생성하고 기능까지 바로 붙여주는 모습이 가장 인상적이지만, 실제 제품 개발은 한 번 만들어서 끝나는 일이 아닙니다.
요구사항이 바뀌고, 정책이 바뀌고, 기존 기능과의 충돌도 계속 생깁니다. 결국 중요한 것은 생성 속도가 아니라 이런 변화가 반복되어도 구조가 무너지지 않는 코드베이스를 만드는 일입니다.

특히 하네스만 잘 구성하면 AI가 알아서 좋은 코드를 만들어줄 것이라는 기대는 조금 경계할 필요가 있다고 느꼈습니다.
AGENTS.md, 테스트, 린터, 아키텍처 규칙 같은 장치는 분명 도움이 되지만, 어떤 책임을 어디에 둘지, 어떤 의존성을 허용할지까지 대신 판단해주지는 못합니다.
결국 하네스도 개발자가 제품과 구조를 이해하고 있어야 제대로 사용할 수 있는 도구입니다.

오히려 AI 코딩이 발전할수록 SRP, 응집도, 결합도, 의존성 방향, 모듈화처럼 예전부터 중요하다고 배웠던 설계 원칙이 더 중요해질 수 있겠다는 생각도 들었습니다.
사람이 직접 작성하는 코드의 양은 줄어들더라도, AI가 만든 코드를 어디에 배치하고 어떤 범위까지 수정하도록 허용할지 판단하는 일은 여전히 개발자의 몫이기 때문입니다.

앞으로는 단순히 “AI에게 코드를 잘 시키는 개발자”보다 변경에 강한 구조를 만들고 AI가 그 경계를 넘지 않도록 관리할 수 있는 개발자가 더 중요해질 것 같습니다.

결국 바이브 코딩을 잘한다는 것은 프롬프트를 화려하게 작성하는 능력보다는, 소프트웨어가 왜 바뀌는지 이해하고 그 변화가 다른 영역으로 번지지 않도록 구조를 설계하는 능력에 더 가깝다고 느꼈습니다.