소개
같은 프로젝트에 대해 Vooster.ai + Cursor와 Gemini CLI를 비교했다.
개인적인 경험에 따르면 결론적으로 결국 사용자의 역량이 중요함을 다시 한 번 깨달았다.
진행 방법
Vooster.ai + Cursor
Vooster/Cursor를 사용한 경우에는, FE와 BE를 함께 만들어나갔다. DB 설계는 하찮았지만, 의외로 잘 설계되어서 진행된 것 같다. 하지만 UI적으로 개선을 아무리 하려고 해도, 프로젝트가 자꾸 망가져서 중단하게 되었다.
Gemini CLI
GeminiCLI를 사용한 경우에는 FE와 BE를 따로 만들어나갔다. FE는 디자인은 구려도, 요청한 기능에는 충실한 꽤 그럴듯한 페이지를 만들어내었다. 그러나 BE를 붙이기 시작하자 폭주를 시작하고 제대로 된 어플리케이션을 만들지 못했다.
반대로 BE부터 만들어나가는 방식도 수행하고 있지만, 사용량제한 때문에 진척이 어렵다는 단점이 있다. 이건 추후 업데이트 예정이다.
결과와 배운 점
PRD와 TRD 설계는 Vooster가 정말 정교하게 만들어주는 편이다. 지난번 사례글에서는 그냥 그렇다는 식으로 적었는데, PRD TRD를 한 번 만든 뒤에 수정/추가/삭제하는 것도 편했고, 아예 PRD/TRD를 Vooster에서 만드는 방법으로 진행하고 있다.
추가적인 작업은 Gemini CLI에서 보조로 부족한 점을 추가하면서 사용하니 좋음
GEMINI.md
PRD.md, TRD.md, CODE_GUIDELINE.md 는 별도로 docs에 넣고 프로젝트마다 다르게 사용하고, GEMINI.md는 고정으로 사용한다.
# Gemini Development Guidelines
> **Document Synchronization:** This is the primary guideline document in English. When making changes to this file, you MUST reflect the same changes in the Korean version, `GEMINI.kr.md`.
> **Important:** Before responding to any user request or writing any code, you must first thoroughly read and analyze the following core documents.
>
> * **[Product Requirements Document (PRD)](./docs/PRD.md)**
> * **[Technical Requirements Document (TRD)](./docs/TRD.md)**
> * **[Code Guideline](./docs/CODE_GUIDELINE.md)**
>
> The requirements, architecture, code style, and conventions specified in these documents must be followed with the highest priority.
---
## Table of Contents
1. [Core Documents](#1-core-documents)
2. [Development Principles](#2-development-principles)
3. [Branching Strategy](#3-branching-strategy)
4. [Commit Message Convention](#4-commit-message-convention)
5. [Code Review](#5-code-review)
6. [Deployment](#6-deployment)
---
### 1. Core Documents
* **Product Requirements Document (PRD):** [docs/PRD.md](./docs/PRD.md)
* **Technical Requirements Document (TRD):** [docs/TRD.md](./docs/TRD.md)
* **Code Guideline:** [docs/CODE_GUIDELINE.md](./docs/CODE_GUIDELINE.md)
### 2. Development Principles
#### Code Style & Conventions
- Strictly follow the rules specified in **[Code Guideline](./docs/CODE_GUIDELINE.md)**.
- Adhere to the existing code style, structure, and naming conventions of the project.
- Before writing new code, always analyze the surrounding code to maintain consistency.
#### Libraries & Frameworks
- Use the technology stack defined in **[Technical Requirements Document (TRD)](./docs/TRD.md)**.
- Do not add new libraries or frameworks arbitrarily.
- Check dependency management files like `package.json`, `requirements.txt`, and existing code to understand the currently used tech stack. If a new technology needs to be introduced, it must be discussed with the team and decided upon.
#### Comments
- Comments should briefly explain 'why' the code was written a certain way (for complex business logic or special solutions), rather than 'what' the code does.
- Do not leave comments that converse with the user or describe changes.
#### Testing
- When adding new features or fixing bugs, you must write or update relevant test code.
- Code that does not pass all test cases cannot be merged.
### 3. Branching Strategy
- **main**: The primary branch that is always stable and in a deployable state.
- **release**: The branch for preparing the next deployment, where feature implementation is complete.
- **feature/feature-name**: Branch off from `release` to develop new features. (e.g., `feature/add-dashboard`)
- **bugfix/bug-name**: Branch off from `release` to fix bugs found in the release branch. (e.g., `bugfix/fix-login-error`)
- **hotfix/bug-name**: Branch off from `main` to fix urgent bugs. After fixing, it must be merged into all relevant branches, including `main` and `release`. (e.g., `hotfix/critical-security-patch`)
### 4. Commit Message Convention
All commit messages follow the Conventional Commits format.
#### Format:
```
<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
```
- **Type**: Indicates the type of commit.
- `feat`: A new feature
- `fix`: A bug fix
- `docs`: Documentation only changes
- `style`: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
- `refactor`: A code change that neither fixes a bug nor adds a feature
- `test`: Adding missing tests or correcting existing tests
- `chore`: Changes to the build process or auxiliary tools and libraries such as documentation generation
- **Scope (optional)**: The scope of the commit's changes. (e.g., `api`, `web`, `auth`)
- **Subject**: A concise summary of the commit (under 50 characters). Written in English, capitalized, and without a period at the end.
- **Body**:
- Provides a detailed description of the commit's changes.
- Explains the "what" and "why" rather than the "how".
- **Footer (optional)**:
- `BREAKING CHANGE`: Specifies any breaking changes.
- `Resolves: #issue-number`, `Closes: #issue-number`: References related issues.
#### Example:
```
feat(auth): Implement social login with Google
Improves user convenience by adding Google social login.
Users can now easily sign up and log in using their Google accounts.
Resolves: #45
```
### 5. Code Review
> (To be determined after team discussion)
### 6. Deployment
> (To be determined after team discussion)