만든 것

TDD (테스트 주도 개발, Test-Driven Development) 방식의 Todo 앱을 GitHub Copilot에게 만들게 했습니다.

앱 개요

개발 태스크를 Todo로 등록하고, TDD 워크플로우에 따라 하나씩 해결해 나가는 도구입니다.

기술 스택

왜 바이브 코딩(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)하는 비용이 커졌습니다.

결과적으로 구현보다 수정에 시간을 더 많이 쓰는 경우가 많았습니다.