AI와 협업하여 시스템을 만든다── 이 말은 매력적이지만, 실제 개발은 훨씬 더 투박하고, 더 인간적이며, 더 재미있는 것이었습니다. 이번 볼링장 예약 시스템 개발은 ChatGPT·Copilot·Gemini·Claude라는 4개의 AI가 릴레이 형식으로 담당하며, 요구사항 정의(Requirements Definition) → 설계(Design) → DB 설계 리뷰(DB Design Review) → 구현 및 디버깅(Implementation/Debugging)이라는 흐름을 달려 나간 프로젝트입니다.

Zenn용 기사로서, Qiita 버전보다 「기술적 판단 근거」, 「설계의 깊이」, 「코드 예시」를 보강하면서, 4개 AI 각각의 관점을 그대로 남겨 재구성했습니다.

제1주자: ChatGPT ― 요구사항 정의는 「키워 나가는 것」이었다

첫 번째 공정은 요구사항 정의(Requirements Definition)였습니다. 예약 시스템은 얼핏 단순해 보이지만, 실제로는 많은 판단이 필요합니다.

• 동일 이용자의 시간대 중복 예약은 허용할 것인가
• 레인 세트(American 방식)를 어떻게 다룰 것인가
• 인증(Authentication)은 간이 인증인가, JWT인가
• 취소 권한은 누구에게 부여할 것인가

이러한 사양은 후속 공정인 설계 및 구현에 큰 영향을 미칩니다.

ChatGPT는 요구사항 정의서(Ver.1 → Ver.2 → Ver.2.1)를 단계적으로 키워 나가며, 모호한 사양을 하나씩 언어화해 나갔습니다. 특히 예약 중복 판정(E001/E002/E003)이나 JWT 인증 채택, 취소 권한 처리 등은 후속 공정의 설계와 직결되는 중요한 판단이었습니다.

제2주자: Copilot ― 설계는 「골격을 그리는 일」이며, 기술적 판단의 연속이었다

요구사항 정의가 확정된 단계에서 저(Copilot)가 바통을 이어받았습니다. 담당은 「설계 총괄」입니다. 여러 AI의 아웃풋을 통합하여 실제로 동작하는 시스템으로 떨어뜨리는 교통 정리 역할입니다.

왜 4개 테이블 구성인가 (기술적 판단)

예약 관리의 중심이 되는 것은 다음의 4개 테이블입니다.

Users
LaneSets
Lanes
...

이 구성으로 정한 이유는 정규화(Normalization)·확장성(Scalability)·정합성(Consistency)의 3가지를 충족하기 위해서입니다.

Users

인증 정보(email/password)와 권한(일반 사용자/관리자)을 관리합니다.

LaneSets

볼링장에서는 「2레인 1세트(American 방식)」가 일반적입니다. 레인 세트를 독립시킴으로써 예약 단위를 자연스럽게 표현할 수 있습니다.

Lanes

물리 레인의 가동 상태(정상/유지보수)를 관리합니다. 이를 독립시킴으로써 한쪽 레인만 유지보수 중인 경우에도 레인 세트 전체의 예약을 자동으로 차단할 수 있습니다.

Reservations

누가, 어떤 레인 세트를, 언제 예약했는지를 기록합니다.

이 구조는 다음과 같은 ER 다이어그램(ER Diagram)으로 표현할 수 있습니다.

Users (1) --- (N) Reservations (N) --- (1) LaneSets (1) --- (N) Lanes

API 설계의 판단 근거

FastAPI를 채택한 이유는 다음과 같습니다.

• Pydantic을 통한 타입 안전(Type-safe)한 스키마 정의
• 비동기 처리(Asynchronous processing)를 기본적으로 사용 가능
• JWT 인증과의 궁합이 좋음
• Claude가 구현하기 쉬운 구성임

API는 다음과 같이 정리했습니다.

POST /auth/register
POST /auth/login
GET /lanesets
...

기술 선정 (FastAPI + SQLite + Streamlit)의 이유

FastAPI

경량이며 MVP(Minimum Viable Product)에 최적. 타입 안전하며 Claude가 구현하기 쉬움.

SQLite

로컬 개발에 최적. 배타적 제어(Exclusive control)는 간이적으로 Lock으로 대응.

Streamlit

UI를 최단 시간 내에 구축 가능. Junko 씨가 로컬에서 동작 확인하기 쉬움.

파일 구성안 (VS Code 전제)

backend/
app/
main.py
...

이 구성은 후속 공정인 Claude가 망설임 없이 구현할 수 있도록 설계한 것입니다.

구현은 담당하지 않았다 (솔직한 사실)

당초 역할표에서는 「Copilot = 구현 총괄」이었으나, 실제로 담당한 것은 설계 페이즈까지였습니다.

• ER 다이어그램
• API 설계
• 기술 선정
• 파일 구성안

이러한 "골격 만들기"를 담당하였고, 구현은 Claude에게 맡겼습니다.

설계는 시스템의 미래를 결정하는 공정입니다. 저는 그 부분을 책임지고 담당하여 다음 주자에게 바통을 넘겼습니다.

제3주자: Gemini ― DB 설계 리뷰는, 이상과 현실의 「번역 작업」이었다

Gemini는 Copilot이 그린 설계를 바탕으로 DB 설계 리뷰를 담당했습니다.

Gemini가 제시한 4개 테이블 구성의 강화 포인트

• 개별 레인 관리 (Lanes)를 독립시킴
• 레인 세트와 물리적 레인의 정합성 (Integrity)을 보장함
• SQLite의 외래 키 제약 조건 (Foreign Key Constraints)을 활성화함
• 타임스탬프 (Timestamp, 생성 일시·취소 일시)를 추가함

우려 사항으로 제시한 포인트

• 중복 예약 (Double Booking) 방지는 앱 측에서 구현이 필요함
• 레인 세트의 정합성 로직
• 외래 키 제약 조건의 활성화
• 감사 로그 (Audit Log)의 부족

협업 개발 특유의 「흔들림 (Fluctuation)"

Gemini가 독립시킨 Lanes 테이블이, Copilot의 구현 중심 설계에서는 쉼표 구분 문자열 (Comma-separated string)로 퇴보해 있었다──이러한 “흔들림”을 Claude가 감지하였고, 이는 요구사항 정의 (Requirements Definition)의 개정으로 이어졌습니다.

여러 AI가 병행하여 설계하면 이러한 그라데이션이 자연스럽게 발생합니다. 이는 실패가 아니라, 협업 개발의 현실적인 배움이었습니다.

제4주자: Claude ― 리뷰를 맡으려 했으나, 구현부터 디버깅까지 담당하게 된 이야기

Claude는 당초 「설계 리뷰·품질 체크」 담당이었으나, 체제 재검토에 따라 최종적으로 구현까지 담당하게 되었습니다.

구현 과정에서 마주한 트러블

• bcrypt의 버전 충돌
• Streamlit의 Magic 기능으로 인한 set_page_config() 에러 - 폴더 구성의 붕괴
• 백엔드(Backend) 실행 누락으로 인한 연결 에러
• Windows Smart App Control에 의한 zip 차단
• SQLite의 영속성 (Persistence)에 대한 오해

이러한 문제들을 하나씩 분리하며 해결해 나가며, 작동하는 MVP를 완성했습니다.

마치며

4AI가 릴레이 형식으로 담당한 이 프로젝트는, 처음에 정한 역할 분담대로 진행되지 않았습니다. 하지만 그 차이를 숨기지 않고 기록함으로써, 「역할 분담은 움직이면서 조정하는 것」이라는 배움을 얻을 수 있었습니다.

기술적인 판단, 설계의 흔들림, 구현의 고단함──이 모든 것이 AI 협업 개발만의 리얼리티입니다.

코드는 GitHub에 공개되어 있습니다.

Discussion