이화여대 캡스톤 프로젝트, AI를 협업 파트너로 만든 초기 세팅 & GSD 활용법

 

이번 학기 이화여대 캡스톤디자인 프로젝트에 참여한 저는, 프론트엔드·백엔드·AI·데이터베이스·배포까지 전 과정을 아우르는 대형 프로젝트를 수행했습니다.

그리고 이 과정에서 단순한 코드 작성보다 체계적인 초기 세팅과 AI를 전략적으로 활용하는 방법이 얼마나 중요한지 깨달았습니다. 이 글을 통해 실제 프로젝트 경험을 바탕으로 한 노하우를 낱낱이 공개합니다.

 

 

 

🛠️ 프로젝트 초기 세팅, 성공의 열쇠

 

많은 학생들이 캡스톤을 시작할 때 “일단 코딩부터” 하는 실수를 합니다.

하지만 협업이 필요한 팀 프로젝트에서는 개발 환경과 규칙을 먼저 통일하지 않으면 후반부에 반드시 큰 충돌이 발생합니다. 우리 팀은 본격적인 구현에 앞서 다음과 같은 사항들을 상세히 문서화했습니다.

 

- 📁 GitHub 레포지토리 구조 및 브랜치 전략

- 🔐 환경변수 관리 규칙 (절대 커밋 금지)

- ☁️ Supabase, Vercel, Railway, GCP 등 외부 서비스 연동 방식

- 👥 팀원별 담당 디렉터리 및 수정 금지 파일

 

이러한 초기 세팅은 눈에 띄는 성과가 아니었지만, 이후 프론트엔드와 AI 기능을 동시에 개발할 때 충돌을 방지하고 배포 시점의 오류를 대폭 줄이는 데 큰 역할을 했습니다. 특히 저는 “환경변수는 반드시 팀 내 공유 폴더로 관리하고, 코드에는 포함시키지 않는다” 같은 원칙을 세웠는데, 보안 측면에서도 안전했죠.

 

 

 

👨💻 AI에게 ‘룰’을 가르친 이유

 

최근 많은 팀이 ChatGPT, Claude, Copilot 등을 코드 작성에 활용합니다.

하지만 무턱대고 사용하면 프로젝트 구조를 무너뜨리거나, 팀원이 모르는 파일을 수정하는 사고가 발생할 수 있습니다. 실제로 초반에 AI에게 “로그인 기능 추가해줘”라고 했다가 백엔드 로직을 프론트엔드에 써버리는 황당한 일도 있었어요.

 

그래서 우리 팀은 AI도 팀원처럼 ‘협업 규칙 문서’를 읽게 하자고 결정했습니다. 프로젝트 루트에 `PROJECT_RULES.md`를 만들고, AI 에이전트가 작업을 시작하기 전에 이 문서를 참조하도록 설정했죠. 문서에는 다음과 같은 필수 규칙이 담겼습니다.

 

1. ✅ 담당 영역을 벗어난 파일 수정 금지

2. ✅ 외부 API 호출 시 실제 응답 구조 확인 후 코드 작성

3. ✅ Supabase Key 중 Service Role Key는 서버에서만 사용

4. ✅ 현재 피처와 무관한 리팩토링은 별도 태스크로 분리

5. ✅ 모든 작업은 새 브랜치에서 진행 후 PR 생성

 

이렇게 룰을 명확히 한 다음에는 AI가 한결 예측 가능하고 안정적인 제안을 하기 시작했습니다. AI에게 단순히 일을 시키는 것이 아니라, “우리 팀의 동료로서 지켜야 할 가이드라인”을 먼저 제시한 것이 핵심이었습니다.

 

 

 

📋 GSD(Get Shit Done)로 작업을 체계화하다

 

이번 프로젝트에서 또 한 가지 강력한 도구는 GSD(Get Shit Done) 방식이었습니다.

GSD는 코드 어시스턴트를 위한 메타 프롬프팅 시스템으로, 프로젝트의 현재 상태를 진단하고 다음 액션을 구체화하는 데 특화되어 있습니다. [GSD 깃허브](https://github.com/gsd-build/get-shit-done)

 

우리는 이 GSD의 단계별 사고 흐름을 도입해 프로젝트를 Phase 0(환경 점검), Phase 1A(핵심 기능 설계), 1B(백엔드 연동), 1C(AI 기능 통합) 등으로 나누었습니다. 각 Phase마다 아래와 같은 프로세스를 반복했습니다.

 

- 🔍 현재 상태 및 완료된 작업 확인

- 📝 이번 Phase에서 해결할 태스크 정의

- ⚠️ 팀원 간 작업 영역 충돌 가능성 점검

- ✅ 검증 방법과 완료 기준 명시

 

이렇게 하자 막연하게 “오늘은 기능 만들어야지”가 아니라, “지금 우리가 어디까지 왔고, 다음엔 무엇을 어떻게 해야 하는지”가 모든 팀원에게 공유되었습니다. 특히 제가 맡은 초기 세팅 파트에서 GSD의 “현재 상태 파악 → 액션 도출” 사이클을 적용하니, 놓치기 쉬운 환경변수나 배포 URL 검증까지 꼼꼼하게 챙길 수 있었습니다.

 

 

 

🔎 AI를 리뷰어로 활용한 팁

 

개인적으로 AI가 가장 빛났던 순간은 코드 작성보다 ‘검토’ 단계였습니다.

저는 초기 세팅 완료 후 AI에게 다음과 같은 질문을 던졌습니다.

 

“현재 프로젝트 세팅에서 보안상 위험 요소가 있을까?”

“프론트엔드 환경변수와 배포 URL이 실제로 매칭되는지 점검해줘”

“Supabase anon key와 service role key가 올바르게 구분되어 있는지 확인해줘”

 

그러자 AI는 제가 미처 생각하지 못한 부분을 콕 집어 경고해주었고, 실제로 몇 가지 설정 미스를 사전에 수정할 수 있었습니다. 물론 AI의 조언을 맹신하지 않고, 반드시 실제 기기에서 테스트하는 습관을 가졌습니다. 우리 팀의 모토가 “동작할 거라는 믿음은 검증이 아니다”였기 때문입니다.

 

 

 

❓ 자주 묻는 질문 (Q&A)

 

1. 📌 AI에게 규칙을 알려주는 게 정말 효과가 있나요?

네, 매우 큽니다. 특히 여러 명이 협업하는 경우 AI가 엉뚱한 파일을 수정하거나 팀 컨벤션과 다른 코드를 생산하는 일이 확연히 줄었습니다. 일종의 “AI 온보딩”이라고 생각하시면 됩니다.

 

2. 📌 GSD가 없으면 안 되나요?

필수는 아니지만, 단계별로 사고하는 틀을 제공해주기 때문에 프로젝트 기간이 짧은 캡스톤에서 방황을 줄이는 데 큰 도움이 됩니다. 직접 GSD 프롬프트를 사용하거나, 그 사고방식만 본떠서 진행해도 효과를 볼 수 있어요.

 

3. 📌 초기 세팅에 시간을 많이 쏟으면 기능 개발이 늦어지지 않나요?

장기적으로 보면 오히려 시간을 절약합니다. 초기에 1-2일 투자하면 후반부 디버깅과 충돌 해결에 들어갈 며칠을 아낄 수 있습니다. ‘느리게 가는 것이 결국 빠른 길’임을 경험했습니다.

 

4. 📌 AI가 제안한 내용을 그대로 적용해도 괜찮을까요?

절대 안 됩니다. 반드시 팀원 리뷰와 실제 환경 테스트를 거쳐야 합니다. AI는 당신의 실수를 줄여주지만, 최종 책임은 팀에게 있습니다.

 

 

 

✨ 마무리: 캡스톤 프로젝트, 이렇게 준비하세요

 

이번 이화여대 캡스톤디자인 프로젝트를 통해 얻은 가장 큰 교훈은 “코드를 잘 쓰는 것보다 팀이 같은 기준으로 움직일 수 있는 구조를 만드는 것이 더 중요하다”는 것입니다.

그리고 그 구조를 만들 때 AI는 훌륭한 보조자 역할을 해낼 수 있습니다. 룰을 정하고, GSD 같은 방법론으로 단계를 나누며, AI를 검토자로 활용한다면 여러분의 프로젝트도 훨씬 안정적이고 효율적으로 진행될 겁니다.

 

저희 팀의 전 과정이 궁금하신 분들은 아래 GitHub 레포지토리를 참고해주세요.

🔗 [https://github.com/puter8/capstone](https://github.com/puter8/capstone)

 

여러분도 AI를 현명하게 활용하여 성공적인 캡스톤 프로젝트를 완성하시길 바랍니다! 혹시 궁금한 점이나 나만의 팁이 있다면 댓글로 공유해주세요 😊

2026.06.17 - [Ai] - 초등학생을 위한 AI 미디어 창작 교육, 강남구립 즐거운도서관에서 시작하세요!

초등학생을 위한 AI 미디어 창작 교육, 강남구립 즐거운도서관에서 시작하세요!