바이브코딩 Day 6: Codex를 하나의 개발자가 아니라 작은 제품팀처럼 운영하기로 했다

Day 5에서는 SRP 카드 렌더링 오류를 해결했다.

 

처음에는 지도가 안 뜨는 문제라고 생각했다.
공공데이터 로딩 문제일 수도 있고, Leaflet 지도 렌더링 문제일 수도 있다고 봤다.

 

그런데 진짜 원인은 전혀 다른 곳에 있었다.
SRP 카드 안에서 선언되지 않은 변수를 사용했고, 그 한 줄 때문에 카드 렌더링이 실패했다. 더 큰 문제는 카드 렌더링이 실패하면서 전체 render() 흐름이 중단됐고, 지도 마커 렌더링까지 실행되지 않았다는 점이었다.

 

겉으로는 지도 문제처럼 보였지만, 실제로는 목록 카드 문제였다.

 

이 경험은 꽤 강하게 남았다.

 

바이브코딩은 빠르다.
하지만 빠른 만큼 작은 오류도 빠르게 전체 서비스로 퍼질 수 있다.
그리고 내가 코드를 직접 깊게 이해하지 못한 상태에서 오류가 발생하면, 순간적으로 프로젝트 전체가 불안정하게 느껴진다.

 

Day 6에서는 기능을 하나 더 만드는 대신, Codex를 쓰는 방식을 바꾸기로 했다.

 

지금까지는 하나의 Codex 스레드에서 기획, 디자인, 개발, QA, 배포 점검을 모두 이어서 진행했다.
이제부터는 이 방식을 버리고, Codex를 역할별 에이전트로 나눠 운영하기로 했다.

 

한마디로 정리하면 이렇다.

 

Codex를 하나의 개발자로 쓰지 않고, 작은 제품팀처럼 운영하기로 했다.

---

지금까지는 하나의 스레드에서 모든 작업을 했다

처음 바이브코딩을 시작했을 때는 하나의 스레드로 충분해 보였다.

 

오늘수영 프로젝트는 처음부터 거창한 서비스가 아니었다.
내 위치를 기준으로 가까운 수영장을 찾고, 목록에서 정보를 보고, 상세 페이지로 들어가는 간단한 MVP였다.

 

그래서 Codex에게 이렇게 요청했다.

작업	요청 방식
위치 계산	내 위치 기준으로 가까운 수영장을 정렬해줘
데이터 보강	공공체육시설 데이터를 불러오게 해줘
목록 개선	SRP 카드 UI를 보기 좋게 정리해줘
상세 화면	PDP에 수영장 정보를 보여줘
지도	수영장 위치를 지도에 표시해줘
오류 수정	배포 후 지도가 안 뜨는 문제를 고쳐줘

처음에는 이 방식이 효율적이었다.

 

하나의 스레드 안에 맥락이 계속 쌓였고, 매번 프로젝트를 다시 설명하지 않아도 됐다.
Codex도 이전 작업을 어느 정도 이어받는 것처럼 보였다.

 

“이 정도면 PM이 방향만 잡고, Codex가 알아서 만들어주면 되는 것 아닌가?”

 

초반에는 정말 그렇게 느꼈다.

 

하지만 프로젝트가 조금씩 복잡해지면서 이 방식은 한계가 생겼다.

---

하나의 스레드에 모든 맥락이 쌓이면 결국 섞인다

문제는 작업이 늘어나면서 시작됐다.

 

기능이 하나씩 붙었다.
화면도 조금씩 복잡해졌다.
지도, 목록, 상세, 필터, 데이터, 배포까지 서로 연결되기 시작했다.

 

그러자 하나의 스레드 안에 너무 많은 맥락이 섞였다.

섞이기 시작한 맥락	실제 문제
기획 의도	왜 이 기능이 필요한지 흐려짐
디자인 의도	UI 개선 범위가 불명확해짐
개발 맥락	어떤 파일을 왜 수정했는지 추적이 어려워짐
오류 수정 이력	이전 수정이 현재 오류와 섞임
QA 결과	검증된 것과 추정한 것이 섞임
배포 맥락	로컬 문제와 배포 문제가 혼재됨

처음에는 맥락이 많다는 것이 장점이었다.
하지만 어느 순간부터는 오히려 리스크가 됐다.

 

예를 들어 나는 단순히 SRP 카드 하단 디자인을 정리하고 싶었는데, Codex는 그 주변 로직까지 같이 건드릴 수 있다.
나는 지도 오류를 고치고 싶었는데, 실제 원인은 목록 카드에 있을 수 있다.
나는 UI만 수정한다고 생각했는데, 렌더링 흐름 전체에 영향을 줄 수 있다.

 

바이브코딩에서 무서운 점은 바로 이 부분이다.

 

코드가 만들어지는 속도는 빠르다.
하지만 변경 범위를 제대로 통제하지 않으면, 내가 이해하지 못한 변화가 프로젝트 안에 쌓인다.

 

그리고 그 상태에서 오류가 나면 원인 추적이 어려워진다.

---

Day 5 오류가 운영 방식 전환의 계기가 됐다

Day 5의 오류는 단순히 버그 하나를 잡은 일이 아니었다.
내가 Codex를 어떻게 써야 하는지 다시 생각하게 만든 사건이었다.

 

그때 사용자가 보는 화면은 이런 상태였다.

사용자가 본 증상	처음 의심한 원인	실제 원인
지도 안 보임	Leaflet 렌더링 문제	SRP 카드 렌더링 실패로 지도 단계까지 도달하지 못함
목록 안 보임	데이터 로딩 문제	카드 생성 중 런타임 에러
113곳 숫자는 보임	데이터는 일부 로딩된 상태	목록 숫자 갱신 후 카드 렌더링에서 중단
필터 누르면 지도 보임	필터가 지도 문제를 해결한 듯 보임	결과 0건이라 카드 렌더링을 우회했기 때문

이 과정에서 배운 것은 명확했다.

 

문제를 해결하려면 Codex에게 “고쳐줘”라고만 말하면 안 된다.
현상을 구조화해서 전달해야 한다.

 

• 무엇이 보이는지.
• 무엇이 안 보이는지.
• 어떤 조건에서 달라지는지.
• 어떤 기능은 살아 있고, 어떤 기능은 죽어 있는지.

 

이건 코딩보다는 QA와 PM에 가까운 작업이었다.

 

결국 바이브코딩에서 사람의 역할은 사라지지 않았다.
오히려 더 중요해졌다.

 

AI가 코드를 만들수록, 사람은 문제를 더 정확히 정의해야 한다.

---

그래서 Codex를 역할별 에이전트로 나누기로 했다

Day 6에서는 기능을 추가하기보다 운영 방식을 먼저 바꿨다.

 

기존 방식은 이랬다.

기존 방식	설명
하나의 Codex 스레드	모든 작업을 한 대화에서 처리
역할 구분 없음	기획, 디자인, 개발, QA가 섞임
코드 수정 권한 불명확	어떤 요청에서도 코드가 수정될 수 있음
완료 기준 약함	구현 후 검증 기준이 매번 달라짐
오류 발생 시 추적 어려움	어떤 변경이 원인인지 좁히기 어려움

이 방식은 빠르지만 불안정했다.

 

그래서 새 방식으로 바꿨다.

전환 후 방식	설명
역할별 Codex 스레드	PM, Design, Dev, QA, Release 분리
에이전트별 문서	각 역할의 책임과 금지사항 정의
Dev Agent만 코드 수정	코드 변경 권한 제한
작업 템플릿 사용	작업 배경, 범위, AC, QA 기준 정리
단계별 검증	구현 전 정의, 구현 후 QA, 배포 전 점검

핵심은 간단하다.

 

Codex를 하나의 만능 작업자로 쓰지 않고, 역할별 에이전트로 나눠 운영하는 것.

---

에이전트는 총 5개로 나눴다

처음에는 기획, 개발, 디자인 정도만 나누면 될 줄 알았다.
하지만 Day 5 오류를 겪고 나니 QA와 Release도 별도로 필요하다고 판단했다.

 

결국 5개 역할로 나눴다.

에이전트	역할	코드 수정
PM Agent	요구사항, 범위, 우선순위, AC 정의	금지
Design Agent	화면 구조, UX, 컴포넌트 설계	금지
Dev Agent	실제 코드 구현, 버그 수정	허용
QA Agent	회귀 테스트, 오류 재현, 리스크 탐지	금지
Release Agent	배포 전 점검, smoke test, 릴리즈 노트	원칙적 금지

가장 중요한 원칙은 하나다.

 

Dev Agent만 코드를 수정한다.

 

PM Agent는 요구사항을 정의한다.
Design Agent는 화면 구조를 설계한다.
QA Agent는 깨질 가능성을 찾는다.
Release Agent는 배포 가능 여부를 점검한다.

 

하지만 실제 코드는 Dev Agent만 수정한다.

 

이렇게 해야 Codex가 기획 검토나 QA 중에 갑자기 코드를 바꾸는 일을 막을 수 있다.

---

먼저 프로젝트 안에 에이전트 운영 문서를 만들었다

스레드만 나눠서는 부족하다.
Codex가 각 역할을 계속 유지하려면 기준 문서가 필요하다.

 

그래서 프로젝트 안에 에이전트 운영 문서를 만들었다.

AGENTS.md

docs/
  agents/
    pm-agent.md
    design-agent.md
    dev-agent.md
    qa-agent.md
    release-agent.md

  workflow.md
  task-template.md
  decision-log.md
  release-checklist.md

 

각 문서의 역할은 다음과 같다.

파일	목적
AGENTS.md	프로젝트 전체 공통 운영 규칙
docs/agents/pm-agent.md	PM Agent 역할, 금지사항, 산출물
docs/agents/design-agent.md	Design Agent의 UX/UI 설계 규칙
docs/agents/dev-agent.md	Dev Agent의 코드 수정 원칙
docs/agents/qa-agent.md	QA Agent의 회귀 테스트 기준
docs/agents/release-agent.md	Release Agent의 배포 점검 기준
docs/workflow.md	PM → Design → Dev → QA → Release 흐름
docs/task-template.md	표준 작업 지시 템플릿
docs/decision-log.md	주요 의사결정 기록
docs/release-checklist.md	배포 전후 체크리스트

이 문서들은 단순한 기록용 문서가 아니다.
Codex에게 작업을 시킬 때 기준이 되는 운영 규칙이다.

 

특히 AGENTS.md가 중요하다.

 

여기에는 모든 에이전트가 지켜야 할 공통 규칙을 넣었다.

공통 규칙	목적
Dev Agent만 서비스 코드를 수정	코드 변경 권한 통제
PM/Design/QA/Release는 코드 수정 금지	역할 충돌 방지
요청받은 범위 외 파일 수정 금지	변경 범위 확대 방지
데이터 구조 변경 전 영향 범위 보고	데이터 오류 방지
전역 CSS/JS 변경 전 사전 보고	전체 회귀 방지
한 작업에서는 하나의 목표만 수행	작업 단위 통제
기존 기능 삭제 금지	기능 회귀 방지
변경 후 수정 파일/검증 결과/리스크 보고	추적 가능성 확보

AI에게 일을 맡길수록 중요한 것은 “무엇을 하라”보다 “무엇을 하지 말라”다.

 

Codex는 빠르다.
그만큼 잘못된 방향으로도 빠르게 간다.

 

그래서 운영 규칙은 선택이 아니라 안전장치다.

---

Codex 스레드도 역할별로 따로 만들었다

문서 체계를 만든 뒤에는 Codex 안에서 실제 스레드도 나눴다.

스레드명	목적
[PM] 오늘수영 작업 정의/PRD/AC	작업 정의, 범위 설정, AC 작성
[Design] 오늘수영 UX/UI 설계	화면 구조, 정보 계층, 상태별 UI 설계
[Dev] 오늘수영 기능 구현/버그 수정	실제 코드 수정과 검증
[QA] 오늘수영 회귀 테스트/이슈 재현	오류 탐지, 재현 절차, 수정 요청
[Release] 오늘수영 배포 점검	배포 전 체크리스트, 릴리즈 노트

각 스레드의 첫 메시지에는 역할을 고정하는 프롬프트를 넣었다.

 

예를 들어 PM Agent 스레드는 이렇게 시작한다.

너는 오늘수영 프로젝트의 PM Agent다.

반드시 AGENTS.md와 docs/agents/pm-agent.md를 먼저 읽고, 그 규칙을 따른다.

역할:
- 요구사항 정의
- 작업 범위/제외 범위 정리
- 우선순위 판단
- Acceptance Criteria 작성
- Dev/Design/QA Agent에게 넘길 작업 지시문 작성

금지:
- 서비스 코드 수정 금지
- UI/CSS/JS 직접 변경 금지
- 구현 방식 단정 금지
- 불확실한 내용 단정 금지

 

Dev Agent 스레드는 이렇게 시작한다.

너는 오늘수영 프로젝트의 Dev Agent다.

반드시 AGENTS.md와 docs/agents/dev-agent.md를 먼저 읽고, 그 규칙을 따른다.

역할:
- 실제 코드 구현
- 버그 수정
- 최소 변경 원칙 기반 수정
- 빌드/테스트 실행
- 변경 파일과 검증 결과 보고

중요 규칙:
- 요청받은 작업만 수행한다.
- 요청받은 파일 외 수정하지 않는다.
- 리팩토링과 기능 구현을 섞지 않는다.
- 데이터 구조 변경 전 반드시 영향 범위를 보고한다.
- 기존 기능을 삭제하지 않는다.

스레드를 나누는 목적은 정리정돈이 아니다.
각 스레드가 서로 다른 판단 기준을 갖게 만드는 것이다.

 

• PM 스레드는 “이 기능이 맞는가”를 본다.
• Design 스레드는 “사용자가 이해할 수 있는가”를 본다.
• Dev 스레드는 “최소 변경으로 구현 가능한가”를 본다.
• QA 스레드는 “기존 기능이 깨지지 않았는가”를 본다.
• Release 스레드는 “배포해도 되는가”를 본다.

 

같은 프로젝트라도 질문이 달라지면 답도 달라진다.

---

작업 흐름도 바꿨다

이전에는 아이디어가 생기면 바로 구현을 요청했다.

단계	기존 방식
1	아이디어가 떠오름
2	Codex에게 바로 구현 요청
3	화면 확인
4	오류 수정 요청
5	다시 구현 요청

이 방식은 빠르다.
하지만 위험하다.

 

요구사항이 덜 정리된 상태에서 구현부터 들어가면, Codex가 빈칸을 알아서 채운다.
그 빈칸이 맞을 때도 있지만, 틀릴 때도 있다.

 

그래서 이제는 흐름을 바꿨다.

단계	담당 에이전트	작업
1	PM Agent	문제 정의, 작업 범위, 제외 범위, AC 작성
2	Design Agent	화면 구조, 정보 우선순위, 상태별 UI 설계
3	Dev Agent	허용 범위 안에서 최소 변경 구현
4	QA Agent	회귀 테스트, 오류 재현, 리스크 탐지
5	Release Agent	배포 전 점검, smoke test, 릴리즈 노트

이제 Codex에게 바로 “만들어줘”라고 하지 않는다.

 

먼저 이렇게 요청한다.

이 작업을 PM Agent 관점에서 정의해줘.
아직 코드는 수정하지 마.

 

그 다음 Design Agent에게 넘긴다.

이 요구사항을 기준으로 모바일 UI 구조를 설계해줘.
코드는 수정하지 마.

 

그 다음에야 Dev Agent에게 구현을 맡긴다.

정의된 범위 안에서 최소 변경으로 구현해줘.
수정 허용 파일 외에는 건드리지 마.

 

마지막으로 QA Agent에게 확인시킨다.

최근 변경사항 기준으로 회귀 테스트를 해줘.
코드는 수정하지 마.

 

이 흐름은 이전보다 느리다.
하지만 훨씬 안전하다.

 

바이브코딩에서 필요한 것은 무조건 빠른 구현이 아니다.
빠르게 만들되, 통제 가능한 상태를 유지하는 것이다.

---

예를 들어 SRP에 구 필터를 추가한다면

예전 같으면 이렇게 요청했을 것이다.

SRP 목록에서 구 필터를 추가해줘.

이제는 이렇게 하지 않는다.

 

먼저 PM Agent에게 작업을 정의하게 한다.

docs/task-template.md 형식에 맞춰 아래 작업을 PM Agent 관점에서 정리해줘.
아직 코드는 수정하지 마.

작업:
SRP 목록에서 구/지역 필터를 추가하고 싶다.
강남구, 마포구, 송파구 같은 자치구를 선택할 수 있어야 하고,
기존 검색어, 빠른 필터, 거리순 정렬과 함께 동작해야 한다.
모바일에서는 filter chip 또는 select 형태를 검토해줘.

 

그러면 PM Agent는 이런 식으로 작업을 쪼갠다.

항목	내용
문제 정의	사용자가 지역 기준으로 수영장을 좁혀보기 어렵다
목표	SRP에서 자치구 필터 제공
작업 범위	필터 UI, 필터 로직, 기존 검색/정렬과 조합
제외 범위	지도 클러스터링, 위치 기반 추천 고도화
AC	특정 구 선택 시 해당 구 수영장만 노출
리스크	기존 검색어/빠른 필터/거리순 정렬과 충돌 가능
Dev 전달물	수정 허용 파일, 금지 파일, 검증 기준 포함 프롬프트

이후 Design Agent가 UI 구조를 잡고, Dev Agent가 구현하고, QA Agent가 깨질 가능성을 본다.

 

단순히 절차를 늘린 것이 아니다.
Codex가 임의로 판단할 영역을 줄인 것이다.

---

이번 전환으로 얻은 것

아직 이 방식이 완전히 검증된 것은 아니다.
하지만 적어도 지금까지 하나의 스레드로 작업하면서 느낀 불안정성은 줄일 수 있을 것 같다.

얻은 것	설명
역할 분리	기획, 디자인, 개발, QA 판단이 섞이지 않음
변경 범위 통제	Dev Agent만 코드 수정 가능
완료 기준 명확화	AC와 QA 체크리스트 기반 검증 가능
오류 추적 개선	어떤 단계에서 문제가 생겼는지 파악 쉬움
회귀 리스크 감소	QA Agent가 기존 기능 영향 확인
배포 안정성 향상	Release Agent가 배포 전후 점검
PM 판단 강화	기능 범위와 우선순위를 명확히 관리

바이브코딩은 빠르다.
하지만 빠른 만큼 통제 장치가 없으면 쉽게 흔들린다.

 

에이전트 체계는 Codex의 속도를 늦추기 위한 장치가 아니다.
오히려 속도를 유지하면서도 프로젝트를 망가뜨리지 않기 위한 운영 구조다.

---

물론 단점도 있다

이 방식이 무조건 좋은 것은 아니다.
확실히 번거롭다.

단점	설명	대응
초기 세팅 비용	문서와 스레드를 먼저 만들어야 함	프로젝트 초기에 한 번만 세팅
작업 속도 저하	바로 구현보다 단계가 많음	작은 작업은 PM → Dev → QA로 축약
관리 부담 증가	여러 스레드를 오가야 함	task-template으로 전달 형식 표준화
과도한 문서화 위험	문서만 많고 실행이 느려질 수 있음	필요한 문서만 작성
역할 경계 혼선	에이전트가 다른 역할을 수행할 수 있음	첫 프롬프트에서 금지사항 명확화

모든 작업을 5단계로 강제할 필요는 없다.

 

작업 성격에 따라 줄이면 된다.

 

작업 유형	추천 흐름
신규 기능	PM → Design → Dev → QA → Release
단순 버그	QA → Dev → QA
UI 개선	Design → Dev → QA
정책 변경	PM → Dev → QA
배포 점검	QA → Release

핵심은 절차를 늘리는 것이 아니다.
필요한 순간에 필요한 역할을 분리하는 것이다.

---

이번 Day 6에서 배운 것

Day 6에는 새로운 기능을 만들지 않았다.
대신 개발 방식을 바꿨다.

 

겉으로 보면 생산성이 떨어진 것처럼 보일 수도 있다.
하지만 오히려 지금 필요한 작업이었다고 생각한다.

 

Day 5에서 경험한 것처럼, 작은 렌더링 오류 하나가 전체 서비스 장애처럼 보일 수 있다.
그런데 이런 상황을 계속 하나의 스레드에서 해결하려고 하면 맥락은 더 복잡해지고, 변경 범위는 더 불안정해진다.

 

결국 바이브코딩에서 중요한 것은 프롬프트 하나를 잘 쓰는 것이 아니다.

 

더 중요한 것은 Codex가 일하는 구조를 설계하는 것이다.

이전 생각	지금 생각
좋은 프롬프트를 쓰면 된다	좋은 운영 체계가 필요하다
Codex가 구현하면 된다	PM이 변경 범위를 통제해야 한다
하나의 스레드에 맥락을 쌓으면 좋다	역할별로 맥락을 분리해야 한다
오류는 Codex가 고치면 된다	사람이 현상을 구조화해야 한다
AI 개발은 빠른 구현이 핵심이다	빠른 구현보다 통제 가능한 변경이 중요하다

이번 작업을 하면서 PM의 역할도 다시 보게 됐다.

 

AI가 코드를 만들어준다고 해서 PM의 역할이 줄어드는 것이 아니다.
오히려 PM이 해야 할 일이 더 선명해진다.

 

• 무엇을 만들지 정해야 한다.
• 어디까지 만들지 잘라야 한다.
• 무엇을 하지 않을지 명확히 해야 한다.
• 어떤 조건이면 완료인지 정의해야 한다.
• 어떤 기능이 깨지면 안 되는지 계속 확인해야 한다.

 

AI가 빠르게 움직일수록, 사람은 더 명확한 기준을 세워야 한다.

---

결론: 바이브코딩은 코딩 자동화가 아니라 협업 방식의 재설계다

Day 6의 핵심은 기능 추가가 아니었다.
Codex 운영 방식을 바꾼 것이다.

 

기존에는 하나의 스레드에서 모든 작업을 처리했다.
이제는 PM, Design, Dev, QA, Release 에이전트로 역할을 나눴다.

 

이 전환의 목적은 더 복잡하게 일하기 위해서가 아니다.
더 안전하게 만들기 위해서다.

 

바이브코딩은 분명히 강력하다.
하지만 마법은 아니다.

 

AI가 코드를 만든다.
하지만 문제를 정의하고, 작업 범위를 자르고, 변경을 통제하고, 검증 기준을 세우는 일은 여전히 사람의 몫이다.

 

이번 Day 6에서 얻은 결론은 이것이다.

 

Codex를 하나의 개발자로 쓰면 빠르다.
하지만 Codex를 작은 제품팀처럼 운영하면 더 안전하다.

 

앞으로 오늘수영 프로젝트는 이 방식으로 진행해보려고 한다.

 

• PM Agent가 작업을 정의한다.
• Design Agent가 화면 구조를 설계한다.
• Dev Agent가 최소 변경으로 구현한다.
• QA Agent가 깨질 가능성을 찾는다.
• Release Agent가 배포 가능 여부를 확인한다.

 

조금 번거롭지만, 지금은 이 방식이 맞다.

 

바이브코딩은 결국 코딩을 자동화하는 일이 아니라,
AI와 함께 일하는 방식을 다시 설계하는 일에 가깝다.