개발자에서 "개발 감독"으로

지난 글에서 바이브 코딩이 실패하는 패턴을 봤다. 구조 없이 반복하면 망한다고 했다.

그럼 어떻게 해야 하나. 답은 역할을 바꾸는 것이다.

코드를 직접 쓰던 "구현자"에서, AI가 쓴 코드를 검증하고 방향을 잡는 "감독자"로. 이 글에서는 이 역할 전환이 실제로 뭘 의미하는지 정리한다.

---

영화 감독 비유

영화를 만들 때 감독이 하는 일을 생각해보자.

감독은 직접 연기하지 않는다. 카메라도 안 돌린다. 조명도 안 만진다. 근데 영화의 모든 결정은 감독이 한다.

• "이 씬은 더 긴장감 있게"
• "조명 좀 어둡게"
• "여기서 컷, 다시"

배우가 연기하고, 스태프가 장비를 다루고, 감독은 전체를 보면서 방향을 잡는다.

바이브 코딩에서 개발자의 역할이 이거다. AI가 코드를 쓰고, 개발자는 전체를 보면서 "이건 맞아, 이건 아니야"를 판단한다.

---

구현자 vs 감독자

역할 차이를 비교하면 이렇다.

구분	구현자 (전통)	감독자 (바이브)
주요 활동	코드 작성	결과 검증
시간 대부분	타이핑	판단/결정
핵심 스킬	문법, 알고리즘	요구사항 명확화, 품질 판단
병목	구현 속도	판단 속도
책임	코드 품질	시스템 품질

구현자일 때는 "이 함수를 어떻게 짤까"가 고민이었다. 감독자일 때는 "이 결과가 우리가 원하는 건가"가 고민이다.

---

감독자의 4가지 역할

구체적으로 개발 감독이 해야 할 일을 정리하면 네 가지다.

1. 요구사항 명확화

AI한테 "로그인 만들어줘"라고 하면 뭔가 나온다. 근데 그게 내가 원하는 로그인인가?

[모호한 요구사항]
"로그인 만들어줘"

[명확한 요구사항]
"이메일/비밀번호 로그인 폼을 만들어줘.
- 이메일 형식 유효성 검사
- 비밀번호 최소 8자
- 제출 시 버튼 비활성화
- 에러는 각 입력창 아래에 빨간색으로
- 성공 시 /dashboard로 리다이렉트"

두 번째처럼 요구사항을 명확히 해야 원하는 결과가 나온다. 이게 감독의 첫 번째 역할이다.

요구사항이 모호하면 AI도 모호한 걸 만든다. "대충 이런 거"라고 시키면 AI도 "대충 이런 거"를 내놓는다.

2. 구조 설계

전체 아키텍처는 AI가 잡아주지 않는다. 감독이 잡아야 한다.

[잘못된 접근]
"회원 관리 기능 만들어줘"
→ AI가 아무렇게나 구조 잡음
→ 나중에 뜯어고쳐야 함

[올바른 접근]
"회원 관리 기능을 이 구조로 만들어줘:
- API: /api/users/* (RESTful)
- DB: users 테이블 (이미 있음)
- 컴포넌트: src/components/users/
- 상태관리: React Query 사용"
→ AI가 정해진 구조 안에서 구현

구조를 먼저 정하고, 그 안에서 AI가 채우게 한다. 이래야 나중에 유지보수가 된다.

3. 품질 검증

"동작한다"와 "제대로 동작한다"는 다르다고 했다. 감독은 이걸 구분해야 한다.

검증 포인트:

• 해피 패스: 정상 입력 → 정상 동작?
• 에러 케이스: 잘못된 입력 → 적절한 에러?
• 엣지 케이스: 경계값 → 문제없이 처리?
• 보안: SQL 인젝션, XSS 등 취약점?
• 성능: 느리지 않은가?

AI 코드를 그냥 믿으면 안 된다. 검증해야 한다.

처음엔 이게 귀찮았다. "AI가 만들었는데 뭐"라는 생각. 근데 몇 번 터지고 나니까 검증 없이는 무섭더라.

4. 방향 조정

개발하다 보면 처음 계획과 달라지는 경우가 있다. 이때 방향을 잡는 것도 감독의 역할이다.

[상황]
사용자 목록을 테이블로 보여주려 했는데,
AI가 카드 형태로 만들어왔다.

[감독의 선택]
A. "아니, 테이블로 바꿔줘" → 원래 계획 유지
B. "음, 카드도 괜찮은데?" → 계획 수정
C. "둘 다 보여줘, 토글로 전환하게" → 새로운 방향

뭘 선택하든, 의도적으로 선택하는 게 중요하다. AI가 만든 대로 그냥 가버리면 방향 없이 표류하는 거다.

---

필요한 새로운 스킬셋

감독자가 되려면 필요한 스킬이 달라진다.

떨어지는 중요도

• 타이핑 속도
• 문법 암기
• 특정 프레임워크 API 암기
• 보일러플레이트 코드 작성

이건 AI가 대신해준다.

올라가는 중요도

• 시스템 사고: 전체 구조를 보는 능력
• 의사결정: 여러 옵션 중 선택하는 능력
• 커뮤니케이션: 요구사항을 명확히 전달하는 능력
• 검증 능력: 코드가 맞는지 판단하는 능력
• 도메인 지식: 비즈니스 로직을 이해하는 능력

변하지 않는 것

• 논리적 사고
• 문제 해결 능력
• 디버깅 능력 (다만 방식이 달라짐)
• 컴퓨터 과학 기초

코드를 직접 안 쳐도 "이 코드가 뭘 하는지"는 이해해야 한다. 감독이 영화 촬영 기술을 몰라도 되는 게 아닌 것처럼.

---

실수하기 쉬운 부분

역할을 바꿀 때 흔히 하는 실수들이 있다.

1. 검증 생략

"AI가 만들었으니 맞겠지" → 터진다.

아무리 AI가 잘해도 검증은 필요하다. 특히 보안, 에러 처리, 성능 관련해서.

2. 구조 위임

"구조도 AI가 알아서 잡겠지" → 스파게티 코드.

구조는 감독이 잡아야 한다. AI는 주어진 구조 안에서 채우는 역할.

3. 컨텍스트 미전달

"알아서 해줘" → 일관성 없는 코드.

프로젝트 규칙, 기존 패턴, 사용하는 라이브러리... 이런 컨텍스트를 전달해야 한다.

4. 과도한 위임

"다 시켜버리자" → 제어력 상실.

감독이 모든 걸 위임하면 영화가 이상해진다. 핵심 결정은 사람이 해야 한다.

---

도구별 접근

바이브 코딩 도구마다 "감독" 역할을 하는 방식이 조금 다르다.

Claude Code / Cursor

대화형으로 피드백. "이거 말고 저렇게 해줘"가 자연스럽다.

감독 포인트:

• 요구사항을 한 번에 명확히 전달
• 결과 나오면 꼼꼼히 검토
• 수정 사항 구체적으로 피드백

GitHub Copilot

인라인 제안 방식. 감독보다는 "페어 프로그래머"에 가깝다.

감독 포인트:

• 제안 수락 전 코드 확인
• 맥락에 맞는 제안인지 판단
• 필요하면 직접 수정

공통

어떤 도구든 검증은 사람 몫이다. 도구가 달라도 감독의 역할은 같다.

---

실제 워크플로우 예시

내가 기능 하나 만들 때 실제로 하는 흐름이다.

1. 요구사항 정리 (직접)
   - 뭘 만들 건지 글로 정리
   - 입력/출력/에러 케이스 정의

2. 구조 설계 (직접)
   - 어디에 어떤 파일을 만들 건지
   - 기존 코드와 어떻게 연결할 건지

3. 구현 지시 (AI)
   - 정리한 요구사항 + 구조 전달
   - "이 구조로 이 기능 만들어줘"

4. 결과 검토 (직접)
   - 코드 훑어보기
   - 브라우저에서 확인
   - 엣지 케이스 테스트

5. 피드백 (AI)
   - 문제 있으면 수정 요청
   - 4-5 반복

6. 테스트 작성 (AI + 직접)
   - 테스트 케이스 정의는 내가
   - 테스트 코드 작성은 AI
   - 테스트 통과 확인은 내가

7. 코드 리뷰 (직접)
   - 최종 확인
   - 커밋

1, 2, 4, 7은 내가 직접 한다. 3, 5, 6 일부는 AI가 한다. 이게 감독의 역할 분담이다.

---

마무리

바이브 코딩 시대에 개발자는 "코드를 치는 사람"에서 "코드를 검증하고 방향을 잡는 사람"으로 바뀐다.

이게 더 쉬운 건 아니다. 다른 종류의 어려움이다. 코드를 직접 안 치는 대신, 전체를 보고 판단해야 한다. 세부 구현보다 시스템 설계가 중요해진다.

다음 편에서는 감독 역할을 효과적으로 수행하기 위한 구체적인 워크플로우, Spec-First 방식을 다룬다.

바이브 코딩은 자유를 주지만, 책임은 사라지지 않는다.