| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | ||||||
| 2 | 3 | 4 | 5 | 6 | 7 | 8 |
| 9 | 10 | 11 | 12 | 13 | 14 | 15 |
| 16 | 17 | 18 | 19 | 20 | 21 | 22 |
| 23 | 24 | 25 | 26 | 27 | 28 | 29 |
| 30 | 31 |
- docker
- CKA 기출문제
- MySQL
- 공부
- aws
- Java
- SRE
- Kubernetes
- Spring
- 코틀린 코루틴의 정석
- kotlin coroutine
- 오블완
- tucker의 go 언어 프로그래밍
- AI
- minikube
- PETERICA
- CloudWatch
- Network
- go
- AWS EKS
- Rag
- 정보처리기사 실기 기출문제
- golang
- LLM
- CKA
- kotlin
- 기록으로 실력을 쌓자
- Claude
- 바이브코딩
- 티스토리챌린지
- Today
- Total
피터의 개발이야기
[바이브코딩] 04. AI에게도 SDLC가 필요하다 - ChatGPT, Claude, Codex를 팀처럼 일하게 만든 방법 본문
[바이브코딩] 04. AI에게도 SDLC가 필요하다 - ChatGPT, Claude, Codex를 팀처럼 일하게 만든 방법
기록하는 백엔드개발자 2026. 8. 5. 22:17
AI는 혼자 일하는 도구가 아니라 역할을 나누어 협업하는 팀원이 될 수 있다.
ㅁ 들어가며
AI 코딩을 처음 시작하면 대부분 하나의 AI에게 모든 일을 맡긴다.
기획해줘.
설계해줘.
구현해줘.
리뷰해줘.
문서도 작성해줘.
처음에는 꽤 잘 동작한다.
하지만 프로젝트가 커질수록 이상한 점을 발견하게 된다.
AI가 자신이 만든 설계를 스스로 검토하고,
자신이 작성한 코드를 스스로 리뷰하며,
자신이 내린 결론을 다시 자신이 승인한다.
사람이라면 설계자와 개발자, 리뷰어를 분리하는데 AI에게는 모두 같은 역할을 맡기고 있었던 것이다.
이번 글에서는 ContextBase 프로젝트를 진행하면서 AI를 하나의 개발팀처럼 운영한 방법을 정리해 보려고 한다.
ㅁ 개발팀은 왜 역할을 나눌까?
실제 개발 조직을 생각해 보자.
기획자는 요구사항을 정의한다.
개발자는 코드를 작성한다.
리뷰어는 구현이 설계와 일치하는지 확인한다.
QA는 테스트를 수행한다.
모든 역할을 한 사람이 수행할 수도 있지만, 규모가 커질수록 역할을 분리하는 것이 품질과 생산성을 높인다.
AI도 마찬가지였다.
ㅁ AI도 역할을 나누기 시작했다
ContextBase에서는 AI를 세 명의 팀원처럼 사용했다.
ChatGPT
↓
Codex
↓
Claude
각 AI는 서로 다른 책임을 가진다.
ChatGPT
- 프로젝트 전체 이해
- 요구사항 분석
- 설계
- 다음 작업 계획
- 프롬프트 작성
즉, Technical Lead 역할이다.
Codex
- 설계 구현
- 테스트 작성
- 결과 문서 작성
즉, Senior Developer 역할이다.
Claude
- 구현하지 않는다.
- 설계를 변경하지 않는다.
- 코드 리뷰만 수행한다.
즉, Principal Reviewer 역할이다.
ㅁ ContextNote 활용기
Context Note — AI 대화의 컨텍스트는 왜 “쌓지 않고 구조화”해야 할까?
일전에 ChatGPT와 대화를 하면서 컨텍스트를 정리하기 위해 ContextNote만들었다.
대화를 진행하면서 중요한 컨텍스트는 문서로 정리하고, 문서의 일부를 선택하여 대화를 집중적으로 수행할 수 있었다.
말로 전하는 것보다 문서를 보면 맥락을 ChatGPT가 잘 알 수 있어서 대화가 딴방향으로 가는 것을 많이 막을 수 있었다.
무엇보다 대화 중 핵심내용을 정리하여 문서로 바로 옮길 수 있어서 편리하고 사용 중이다.

ChatGPT Atlas를 사용하고 있다. 웹과 함께 대화를 이어가면서 아이디어 구상, 작업 검토 등을 수행하였다.
실제로 프로젝트의 md파일들을 직접 contextNote에 연결하여 활용하면 claude와 codex의 지시사항을 문서로 바로 등록이 가능하였다.
무엇보다 이렇게 쓰는 이유는 chatGPT가 대화를 통해 활용하면 Token의 제약을 거의 받지 않기 때문이다.
아쉽게도 이 Atlas는 26.08.09에 종료된다.
ㅁ 처음에는 너무 느렸다
초기에는 품질을 높이기 위해 모든 단계를 검토했다.
Plan
↓
Plan Review
↓
Implementation
↓
Code Review
↓
Completion Report
↓
Document Alignment
품질은 매우 높았다.
하지만 기능 하나를 구현하는 데 AI가 여러 번 왕복하면서 개발 속도가 크게 떨어졌다.
처음에는 이것이 맞는 방식이라고 생각했다.
하지만 프로젝트가 진행될수록 병목이 보이기 시작했다.
ㅁ 중요한 것은 검증이 아니라 역할이었다
프로젝트가 P3, P4, P5를 거치면서 느낀 것은 의외였다.
문제는 AI의 성능이 아니었다.
문제는 같은 AI가 모든 역할을 수행하는 구조였다.
역할이 분리되자 각 AI는 자신의 책임에만 집중할 수 있었다.
ChatGPT는 설계를 고민하고,
Codex는 구현에 집중하며,
Claude는 객관적으로 리뷰한다.
사람의 개발 프로세스를 AI에게 그대로 적용한 셈이다.
ㅁ 그래서 개발 방식도 바뀌었다
현재는 훨씬 단순한 흐름을 사용한다.
설계
↓
구현
↓
최종 리뷰
ChatGPT가 설계를 확정한다.
Codex가 구현과 테스트를 수행한다.
Claude가 최종 승인한다.
불필요한 중간 검토를 줄이면서도 설계와 구현, 리뷰의 책임은 유지했다.
ㅁ AI에게도 SDLC가 필요했다
많은 사람들이 AI 활용 능력을 프롬프트 작성 능력이라고 생각한다.
하지만 프로젝트를 진행하면서 얻은 결론은 조금 달랐다.
AI가 아무리 뛰어나도 역할이 명확하지 않으면
설계와 구현, 리뷰가 서로 섞이기 시작한다.
결국 중요한 것은 프롬프트가 아니라 프로세스였다.
사람에게 SDLC가 필요하듯,
AI에게도 SDLC가 필요했다.
ㅁ 네트워크 비유로 생각해 보면
네트워크에서 TCP는 모든 일을 하나의 패킷이 처리하지 않는다.
전송은 Packet이 하고,
경로 선택은 Router가 하고,
오류 복구는 TCP가 담당한다.
각 계층이 자신의 역할만 수행하기 때문에 복잡한 네트워크도 안정적으로 동작한다.
AI 협업도 비슷하다.
ChatGPT는 설계를 담당하고,
Codex는 구현을 담당하며,
Claude는 검증을 담당한다.
역할이 명확해질수록 프로젝트는 더 안정적으로 진행된다.
ㅁ 핵심 정리
- AI 하나에게 모든 역할을 맡기면 객관적인 검증이 어려워진다.
- 사람의 개발 조직처럼 AI도 역할을 분리할 수 있다.
- ChatGPT는 설계, Codex는 구현, Claude는 리뷰를 담당했다.
- 프로젝트가 안정된 이후에는 Gate 기반으로 프로세스를 단순화했다.
- 중요한 것은 AI 모델이 아니라 역할과 책임을 정의하는 개발 프로세스였다.
'AI > 바이브코딩' 카테고리의 다른 글
| [바이브코딩] 03. Claude 5는 왜 Context Engineering을 이야기할까? - Prompt에서 Context로 (0) | 2026.07.27 |
|---|---|
| [바이브코딩] 02. AI와 오래 협업하려면 어떻게 해야 할까? - Plan Mode, 문서화, 컨텍스트 (0) | 2026.07.26 |
| [바이브코딩] 01. AI와 일할 때 왜 문서가 필요할까? - SSOT, MECE, 컨텍스트 (0) | 2026.07.25 |
| [AI][Prompt] 바이브 코딩(Hackathon Vibe Coding Prompt)으로 1시간 앱만들기 (0) | 2025.09.03 |
| [AI] 백엔드 개발자가 본 바이브코딩 - 일할맛 in 판교 세미나 리뷰 (1) | 2025.09.01 |
