소프트웨어공학 바이브코딩 과제
260514 회의 내용 (SW 선정 & 바이브코딩 인공지능 선정)
금일 수업 내용인 Saga 패턴에 대해 조금 더 공부해보고 싶어, 관련 SW 후보를 선정하였다. 후보는 다음과 같다.
팀원들이 발제한 총 7개의 후보군에 대해 사가 패턴 적용 적합성, 바이브코딩 난이도, 소프트웨어 공학적 서사(Lessons Learned) 도출 가능성을 기준으로 검토를 진행하였다.
- 후보 1: 항공권 + 호텔 연쇄 예약 시뮬레이터
- 특징: 사가 패턴의 표준적 예시. 항공권 예약 후 호텔 예약 실패 시 항공권을 환불(보상 트랜잭션)하는 직관적인 흐름.
- 평가: 구조가 단순하여 에이전트가 코드를 한 방에 짜기 유리하나, 실제 도메인 볼륨이 다소 작아 프로토타입에 그칠 우려 있음.
- 후보 2: 기프티콘 선물하기 및 잔액 차감 시스템
- 특징: 포인트 차감 서비스와 쿠폰 발급 서비스 간의 트랜잭션 제어.
- 평가: 커머스 환경의 롤백 로직을 상태 메시지와 로딩바로 시각화하기 좋아 바이브코딩의 산출물 캡처용으로 적합.
- 후보 3: 대학 축제 티켓 예매 시스템
- 특징: 재고 차감/복구, 결제 실패 시 보상 처리, QR 발급 실패 시 예매 취소 처리 등 사가 패턴의 흐름이 매우 촘촘함.
- 평가: 동시성 이슈(재고 초과 방지)가 포함되어 "바이브코딩 시 AI가 놓치기 쉬운 Edge Case를 인간이 공학적 설계로 제어했다"는 서사를 쓰기 가장 좋음.
- 후보 4: 도서관 좌석 예약 및 이용 관리 시스템
- 특징: 좌석 상태 흐름(AVAILABLE, RESERVED, IN_USE 등) 관리 중심.
- 평가: 사가 패턴보다는 단일 DB 상태 머신(State Machine)에 가까워 이번 과제의 핵심 스펙인 분산 트랜잭션 표현에는 아쉬움이 있음.
- 후보 5: 대학 축제 부스 예약 시스템
- 특징: 예약 ➡️ 승인 ➡️ QR 발급으로 이어지는 비즈니스 흐름. 승인 실패 시 보상 처리.
- 평가: 실제 결제 연동이 없어도 사가 패턴을 자연스럽게 녹일 수 있고, 대학 축제라는 도메인이 직관적이라 발표 및 산출물 구성에 유리.
- 후보 6: 스터디룸 예약 시스템
- 특징: 타임 슬롯 관리 및 자동 만료 사가(Saga) 적용.
- 평가: 예약 실패 시 롤백 프로세스가 명확하며 타임 슬롯 충돌 처리를 에이전트와 티키타카하며 풀어나가는 재미가 있음.
- 후보 7: 병원 진료 예약 시스템
- 특징: 의사 스케줄 조회, 알림 발송 실패 시 보상 처리.
- 평가: "예약 성공 후 알림 발송 실패" 같은 외부 API 예외 흐름을 시뮬레이션하기 좋음.
Claude와 Codex중 고민하였으나, Claude는 바이브코딩 중간에 토큰 문제로 인해 중단되는 문제가 있어, CodeX로 선정하였다.
260516 회의 내용 (기능 구체화)
초기에는 실제 대학 축제에서 겪었던 불편함을 바탕으로, 축제 부스 예약 시스템을 우선적으로 고려하였다. 특히 인기 부스의 긴 대기열, 현장 선착순 운영으로 인한 혼잡, 부스 이용 정보를 한눈에 확인하기 어려운 문제 등을 해결하고자 하였다.
논의를 진행하며 단순 부스 예약 기능만 구현하기보다, 대학 축제 전반을 관리할 수 있는 통합 플랫폼 형태로 서비스를 확장하기로 결정하였다.
이에 따라 공연 티켓 예매, 축제 타임라인, 축제 안내도 등의 기능을 함께 포함하기로 하였으며, 각 기능 간의 상태 변화와 실패 상황을 Saga Pattern 기반으로 관리하는 방향으로 설계를 진행하기로 하였다.
특히 예약, 승인, QR 발급, 취소 등의 과정에서 발생하는 상태 전이와 보상 처리 흐름을 통해 분산 트랜잭션 구조를 자연스럽게 표현할 수 있다고 판단하였다. 또한 바이브 코딩을 활용해 기능 구현 속도를 높이되, 상태 관리와 예외 처리 등 핵심적인 공학적 설계는 직접 검토하며 개발을 진행하기로 하였다.
- 대학 축제 통합 운영 플랫폼 : 축제 공연 예매, 부스 예약, 축제 일정 관리, 안내도 기능 등을 하나의 플랫폼에서 제공하는 서비스.
[기능]
- 공연 목록 및 상세 조회
- 선착순 티켓 예매
- 잔여 좌석 확인
- QR 티켓 발급
- 예매 취소
[Saga 흐름]
- 좌석 선점 → 예매 확정 → QR 발급 → 예매 완료
[보상 처리]
- 좌석 선점 실패 시 예매 취소
- QR 발급 실패 시 좌석 복구 및 예매 취소
Claude와 Codex중 고민하였으나, Claude는 바이브코딩 중간에 토큰 문제로 인해 중단되는 문제가 있어, CodeX로 선정하였다.
[기능]
- 부스 위치 조회
- 부스 신청 및 승인
- QR 기반 체크인
- 예약 상태 관리
[Saga 흐름]
- 부스 신청 → 승인 → QR 발급 → 예약 완료
[보상 처리]
- 승인 실패 시 예약 취소
- QR 발급 실패 시 승인 상태 롤백
[기능]
- 날짜별 행사 조회
- 공연 및 이벤트 일정 안내
[기능]
- 공연장 및 부스 위치 표시
- 축제 지도 제공
개발 프로세스
본 프로젝트는 대학 축제 통합 운영 플랫폼을 바이브코딩으로 개발하되, 단순히 AI에게 코드를 생성하게 하는 방식이 아니라 소프트웨어공학의 개발 프로세스를 적용하여 진행한다. 특히 요구사항이 개발 중 변경될 가능성이 있고, 기능을 점진적으로 구체화해야 하므로 애자일 방법론을 기반으로 반복적·점진적 개발 방식을 적용한다.
본 프로젝트는 전통적인 폭포수 모델처럼 모든 요구사항을 초기에 완전히 확정한 뒤 순차적으로 개발하기보다, 짧은 개발 주기를 반복하며 기능을 개선하는 애자일 방식을 적용한다.
대학 축제 플랫폼은 공연 예매, 부스 예약, 타임라인, 안내도 등 여러 기능으로 구성되어 있으며, 개발 과정에서 기능 우선순위나 세부 요구사항이 변경될 수 있다. 따라서 기능을 작은 단위로 나누고, 각 기능을 구현한 뒤 테스트와 피드백을 통해 개선하는 방식이 적합하다고 판단하였다.
본 프로젝트에서는 애자일 방법론 중 스크럼의 일부 요소를 차용한다. 다만 실제 산업 현장의 완전한 스크럼 체계를 적용하기보다는, 과제 규모에 맞게 간소화하여 다음과 같이 운영한다.
- 기능 단위로 백로그 작성
- 짧은 개발 주기 설정
- 주기별 구현 목표 설정
- 회의록과 이슈를 통한 진행 상황 기록
- 구현 후 테스트 및 회고 진행
본 프로젝트의 개발 프로세스는 다음 순서로 진행한다.
요구사항 분석
→ 백로그 작성
→ 우선순위 선정
→ 설계
→ 바이브코딩 기반 구현
→ 테스트
→ 품질 점검
→ 회고 및 개선
이 흐름을 한 번만 수행하는 것이 아니라, 기능 단위로 반복한다. 예를 들어 먼저 공연 티켓 예매 기능을 분석·설계·구현·테스트한 뒤, 다음 반복 주기에서 부스 예약 기능을 개발한다.
가장 먼저 실제 대학 축제에서 발생하는 문제를 분석한다. 초기 아이디어는 축제 부스 예약 시스템이었으나, 팀 논의를 통해 공연 예매, 축제 일정, 안내도 기능까지 포함하는 통합 플랫폼으로 범위를 확장하였다.
요구사항 분석 단계에서는 다음 내용을 정리한다.
- 사용자가 겪는 불편함
- 필요한 주요 기능
- 기능별 사용자 흐름
- 정상 상황과 예외 상황
- 기능 간 우선순위
요구사항을 바탕으로 구현해야 할 기능을 백로그 형태로 정리한다. 백로그는 GitHub Issues를 활용하여 관리한다.
예시 백로그는 다음과 같다.
[공연 예매] 공연 목록 조회 기능 구현
[공연 예매] 잔여 좌석 확인 기능 구현
[공연 예매] 티켓 예매 기능 구현
[공연 예매] QR 티켓 발급 기능 구현
[공연 예매] QR 발급 실패 시 좌석 복구 처리
[부스 예약] 부스 목록 조회 기능 구현
[부스 예약] 부스 예약 신청 기능 구현
[부스 예약] 관리자 승인 기능 구현
[타임라인] 날짜별 행사 조회 기능 구현
[안내도] 축제 지도 화면 구현
백로그를 작성함으로써 개발 범위를 명확히 하고, 어떤 기능을 먼저 구현할지 결정할 수 있다.
모든 기능을 한 번에 구현하지 않고, 핵심 기능부터 우선 개발한다. 본 프로젝트에서는 다음 순서로 우선순위를 정한다.
1순위: 공연 티켓 예매
2순위: 부스 예약
3순위: 축제 타임라인
4순위: 축제 안내도
공연 티켓 예매와 부스 예약은 상태 전이와 예외 처리가 중요하며, Saga Pattern을 적용할 수 있는 핵심 기능이다. 따라서 이 두 기능을 먼저 구현한다.
타임라인과 안내도는 상대적으로 단순 조회 기능에 가깝기 때문에 후순위로 개발한다.
구현 전에 기능별 흐름과 상태를 먼저 설계한다. 바이브코딩은 빠르게 코드를 생성할 수 있지만, 명확한 설계 없이 사용하면 상태 관리와 예외 처리 로직이 누락될 수 있다.
따라서 설계 단계에서는 다음 내용을 정리한다.
- 사용자 흐름
- 도메인 구조
- 데이터 구조
- 상태 전이
- Saga Pattern 흐름
- 실패 시 보상 처리
예를 들어 공연 티켓 예매 기능은 다음과 같이 설계한다.
좌석 확인
→ 좌석 선점
→ 예매 생성
→ QR 티켓 발급
→ 예매 완료
실패 상황은 다음과 같이 처리한다.
좌석 선점 실패 → 예매 실패 처리
QR 발급 실패 → 좌석 복구 및 예매 취소
예매 취소 → 좌석 복구
구현 단계에서는 AI를 활용해 코드를 생성하되, 전체 시스템을 한 번에 만들도록 요청하지 않는다. 기능을 작은 단위로 나누어 프롬프트를 작성하고, 생성된 코드는 사람이 검토한 뒤 반영한다.
바이브코딩 적용 원칙은 다음과 같다.
1. 요구사항과 설계를 먼저 작성한다.
2. 기능 단위로 AI에게 구현을 요청한다.
3. 생성된 코드를 바로 신뢰하지 않고 검토한다.
4. 상태 전이와 예외 처리 누락 여부를 확인한다.
5. 테스트를 통해 정상 흐름과 실패 흐름을 검증한다.
예를 들어 단순히 “티켓 예매 기능을 만들어줘”라고 요청하지 않고, 다음과 같이 구체적으로 요청한다.
공연 티켓 예매 기능을 구현해줘.
예매 흐름은 좌석 확인 → 좌석 선점 → 예매 생성 → QR 발급 → 예매 완료 순서야.
QR 발급에 실패하면 좌석을 복구하고 예매 상태를 CANCELED로 변경해야 해.
이처럼 프로세스를 명확히 한 뒤 바이브코딩을 사용함으로써 코드 생성의 정확도를 높인다.
각 기능 구현 후에는 테스트를 수행한다. 테스트는 단순히 정상 동작 여부만 확인하는 것이 아니라, 실패 상황과 보상 처리까지 확인한다.
주요 테스트 대상은 다음과 같다.
공연 예매 성공 여부
잔여 좌석 부족 시 예매 실패 여부
QR 발급 실패 시 좌석 복구 여부
예매 취소 시 상태 변경 여부
부스 예약 승인 여부
부스 QR 발급 실패 시 승인 롤백 여부
타임라인 조회 여부
안내도 조회 여부
테스트 결과는 문서와 GitHub Issue에 기록한다.
테스트 이후 품질 점검을 수행한다. 품질 점검은 기능이 동작하는지뿐만 아니라, 요구사항을 제대로 만족하는지, 코드 구조가 적절한지, 예외 처리가 충분한지를 확인하는 과정이다.
품질 점검 기준은 다음과 같다.
요구사항이 구현에 반영되었는가?
정상 흐름과 실패 흐름이 모두 처리되었는가?
Saga Pattern의 보상 처리가 적절히 구현되었는가?
상태값이 일관성 있게 관리되는가?
중복 코드가 과도하지 않은가?
테스트 케이스가 요구사항을 검증하는가?
README와 실행 방법이 정리되어 있는가?
각 개발 주기가 끝난 뒤에는 간단한 회고를 진행한다. 회고에서는 다음 내용을 정리한다.
이번 주기에 구현한 기능
잘된 점
문제가 발생한 부분
AI가 생성한 코드에서 수정이 필요했던 부분
다음 주기에 개선할 점
이를 통해 바이브코딩의 효과와 한계를 분석하고, 다음 개발 주기에 반영한다.
예를 들어 다음과 같은 교훈을 정리할 수 있다.
AI는 기본 CRUD 구현에는 효과적이었지만, 상태 전이와 보상 처리처럼 도메인 규칙이 중요한 부분에서는 명확한 설계가 선행되어야 했다.
본 프로젝트는 기능별로 반복 주기를 나누어 개발한다.
| 반복 주기 | 개발 내용 | 주요 산출물 |
|---|---|---|
| 1차 반복 | 요구사항 분석, 서비스 범위 확정 | 요구사항 정의서, 회의록 |
| 2차 반복 | 공연 티켓 예매 기능 설계 및 구현 | Saga 설계서, 예매 기능 |
| 3차 반복 | 부스 예약 기능 설계 및 구현 | 부스 예약 기능, 승인 흐름 |
| 4차 반복 | 타임라인, 안내도 기능 구현 | 조회 기능, 화면 캡처 |
| 5차 반복 | 테스트, 품질 점검, 회고 | 테스트 결과, 품질 체크리스트, 회고록 |
GitHub에서는 다음 항목을 관리한다.
소스 코드
요구사항 문서
설계 문서
회의록
테스트 계획서
품질 체크리스트
회고록
기능별 Issue
커밋 이력
브랜치 전략은 다음과 같이 운영한다.
main
develop
feature/frontend/기능명
feature/backend/기능명
docs/문서명
fix/수정내용
test/테스트내용
커밋은 기능 단위로 나누어 기록한다.
docs: 요구사항 정의서 작성
docs: 공연 예매 saga 흐름 설계
feat: 공연 목록 조회 기능 구현
feat: 티켓 예매 기능 구현
fix: QR 발급 실패 시 좌석 복구 로직 수정
test: 예매 실패 보상 처리 테스트 추가
docs: 1차 개발 회고 작성
본 프로젝트에서 개발 프로세스를 적용하는 이유는 바이브코딩의 한계를 보완하기 위해서이다. 바이브코딩은 빠르게 코드를 생성할 수 있지만, 요구사항이 불명확하거나 설계가 부족하면 기능 누락, 상태 불일치, 예외 처리 부족 등의 문제가 발생할 수 있다.
따라서 본 프로젝트에서는 애자일 기반의 반복 개발 프로세스를 적용하여 요구사항을 기능 단위로 나누고, 설계와 테스트를 거쳐 점진적으로 시스템을 완성한다. 이를 통해 바이브코딩의 생산성은 활용하되, 소프트웨어공학적 프로세스를 통해 품질과 일관성을 확보하고자 한다.