만든 것
TDD (테스트 주도 개발, Test-Driven Development) 방식의 Todo 앱을 GitHub Copilot에게 만들게 했습니다.
앱 개요
개발 태스크를 Todo로 등록하고, TDD 워크플로우에 따라 하나씩 해결해 나가는 도구입니다.
기술 스택
| 레이어 | 기술 |
|---|
| 프론트엔드 | React 19 / TypeScript / Vite / TailwindCSS v4 |
| ... | |
| 리포지토리 | |
왜 바이브 코딩(Vibe Coding)을 했는가
GitHub Copilot에게 가능한 한 코딩을 맡겼을 때, 어디까지 개발을 진행할 수 있는지 시험해 보고 싶어서 시작했습니다.
고안한 점
GitHub Copilot에게 테스트 주도 개발 (TDD)을 수행하게 했습니다.
테스트 → 구현 → 리팩터링 (Refactoring)의 흐름을 유지하도록 지시했습니다.
원칙(Principle)으로서 KISS와 같은 짧은 문구를 rules에 기재했습니다.
AI에게 주는 정보량을 가능한 한 줄이고 싶었고, 짧은 규칙이 권장되었기 때문입니다.
좋지 않았던 점 (AI)
해피 패스 (Happy Path)조차 기대대로 작동하지 않는 경우가 많았습니다.
또한, 하나의 기술 기사에 내용을 너무 많이 담으려는 경향이 있었습니다.
게다가 다음과 같은 문제도 있었습니다.
- 주석이 거의 추가되지 않음
- 린트 에러 (Lint Error)나 타입 에러 (Type Error)가 남은 채로 종료됨
.gitignore 하위의 파일까지 push하려고 함hono-openapi를 사용하지 않고 직접 OpenAPI 정의를 작성함
그 결과, 프롬프트(Prompt)로 수정 지시를 내리는 일이 많아졌습니다.
좋지 않았던 점 (본인)
설계서를 거의 작성하지 않고, 프롬프트 지시만으로 개발을 진행했습니다.
인증이나 로그인 화면을 포함하여 화면 설계서도 준비하지 않았습니다.
그 결과, 구현 방향이 흔들리거나 의도한 대로 구현되지 않는 경우가 있었습니다.
다음에 한다면
rules와 skills의 차이를 이해한 상태에서 각각을 적절히 설계하고 싶습니다.
또한, 다음과 같은 점도 개선하고 싶습니다.
- 보안 대책을 고려한 구현을 하게 하고 싶음
- 작은 단위로 커밋 (Commit)하게 하고 싶음
- 적절한 주석을 쓰게 하고 싶음
배운 점
CI에서의 린트(Lint)나 타입 체크(Type Check)는 필수라고 느꼈습니다.
또한, AI는 코드 생성 속도는 높지만, 생성 결과를 그대로 신뢰하면 나중에 수정하거나 리팩터링 (Refactoring)하는 비용이 커졌습니다.
결과적으로 구현보다 수정에 시간을 더 많이 쓰는 경우가 많았습니다.