인텔리 제이와 Gemini 로 바이브 코딩하기

최근(?) 실제 개발할 때 보면 순수하게 모든 코드를 작성하는 경우가 드문 것 같습니다.

저 또한 프론트엔드 코드를 작성할 때, vscode 기반으로 된 Cursor 에디터를 사용해서 진행하는 편 입니다.

채팅에 작업해야할 프롬프트를 작성하고, 다양한 rules 들을 설정해두면 원하는 대로 코드를 작성하고 반영 해서 매우 편안하게 처리할 수 있었습니다.

실제 지금 보시는 "백과 블로그" 또한 cursor 의 도움을 많이 받았습니다.

저는 API 서버를 개발할 때는 주로, Spring 기반으로 IntelliJ 를 사용하는 편인데, 여기에도 비슷하게 지원하는게 없을까? 해서 찾아보고 사용해본 기록 입니다.

보시는 화면은 Gemini 를 활용한 바이브 코딩으로 Todo List 를 만든 화면 입니다.

작업 중 에서 단 하나의 코드도 적지 않았고 모두 순수하게 프롬프트 질의 기반으로 작성 되었습니다.

필요한 환경

Intellij (community 가능) 설치
Java 등 Spring 프로젝트를 실행할 수 있는 환경
Gemini 로그인 (Google)이 가능한 계정

현재 저는 Gemini Pro 요금을 사용하고 있는데, 현재는 무료 환경에서도 가능한 것으로 알고 있습니다.

설정 진행

Intellij - Gemini 플러그인 설치

windows 기준으로, [설정 / 플러그인] 에서 Gemini Code Assist 를 설치해줍니다.

설치가 완료 되었다면, 우측 툴바에 Gemini 가 하나 생성되는데, 이를 눌러 로그인을 진행해 줍니다.

기본적으로 이제 프롬프트를 작성해 바이브 코딩을 할 1차 준비는 완료입니다.

룰(Rules), AGENTS 파일 생성

정확하게 요구사항에 맞고, 우리팀의 코드 컨벤션에 맞는 개발을 진행하려고 하면 다양한 규정이 필요합니다.

Agent 모드와 사전 등록된 컨텍스트를 통해 이를 실현할 수 있습니다.

Google Gemini 공식문서에서는 다음과 같이 소개합니다.

에이전트 모드를 사용하면 다음 작업을 포함한 다양한 작업을 할 수 있습니다.
공식문서 링크
코드에 대해 질문합니다.
컨텍스트와 기본 제공 도구를 사용하여 생성된 콘텐츠를 개선합니다.
MCP 서버를 구성하여 에이전트 기능을 확장합니다.
복잡한 다단계 작업에 대한 솔루션을 얻습니다.
설계 문서, 문제, TODO 주석으로 코드를 생성합니다.
실행 중에 계획과 도구 사용에 대한 댓글을 달고, 수정하고, 승인하여 에이전트 동작을 제어합니다.

프로젝트의 루트 경로에 AGENTS.md 파일을 생성해줍니다.

여기에는 Gemini 가 코드를 작성할 때 항상 지켜야 할 규칙들을 지정해 줍니다.

아래 형식은 임의로 gpt 와 gemini 를 통해 생성하였습니다.
실제 사용하실 분들은, 팀 컨벤션과 프로젝트에 맞춰 수정하시면 됩니다.

AGENTS.md

# AI Collaboration Policy & Project Rules

이 프로젝트는 **Spring Boot 4.0.2** 기반의 **MVC + JPA** 아키텍처를 따른다.
모든 AI 도구(Gemini, Copilot, Cursor)는 본 문서를 **최우선 지침(Supreme Law)**으로 삼는다.

---

## 0. Fundamental Principles
- **언어**: 한국어 (모든 설명, 주석, 리뷰, 커밋 메시지)
- **JDK**: Java 25
- **Framework**: Spring Boot 4.0.2
- **Database**: PostgreSQL
- **Style**: Google Java Style Guide 준수

---

## 1. Package Structure (Strict)
**[중요]** 비즈니스 로직(`domain`)과 데이터 영속성(`model`)을 물리적으로 분리한다.
임의의 최상위 패키지를 생성하지 않는다.

```text
src/main/java/com/baekgwa/vibecodingtodolist
├── domain           # [비즈니스/웹 계층]
│   └── {feature}    # (예: member, post)
│       ├── controller
│       ├── service
│       └── dto
├── model            # [데이터/영속 계층]
│   └── {feature}
│       ├── entity
│       └── repository
├── global           # [공통 설정] Config, Exception, Security, Utils
└── infra            # [외부 연동] S3, Mail, External API Clients
```

---

## 2. Layer Responsibilities
### 2.1 Domain Layer (domain.*)
- Controller:
  - 요청 검증 및 DTO 반환 담당. 
  - Entity 반환 금지. 
  - Repository 직접 접근 금지 (반드시 Service 경유). 
  - @RestController, @RequiredArgsConstructor 사용. 
- Service:
  - 핵심 비즈니스 로직 구현. 
  - 트랜잭션 경계 설정 (@Transactional). 
  - Repository를 통해서만 영속 계층 접근.
- DTO:
  - 데이터 전송 객체. record 타입 사용 권장. 
  - domain 패키지에 위치.

### 2.2 Model Layer (model.*)
- Entity: DB 테이블 매핑 객체. (model 패키지 필수)
- Repository: JpaRepository 인터페이스. (model 패키지 필수)
- 제약: Controller나 Service는 model 패키지의 구조를 알 수 있지만, 역참조는 금지한다.

### 2.3 Global & Infra
- Global: 공통 응답(ApiResponse), 예외 처리(GlobalExceptionHandler), 보안 설정.
- Infra: 외부 시스템 연동 코드 (AWS, Redis 등).

---

## 3. Entity Implementation Strategy (Strict)
[중요] 모든 Entity는 반드시 아래 패턴을 따른다.
- 상속: TemporalEntity (또는 BaseEntity)를 상속받아 시간 관리.
- 접근 제어:
  - Class Level: @NoArgsConstructor(access = AccessLevel.PROTECTED)
  - Constructor: private (외부 생성 차단)
- 생성 전략:
  - 정적 팩토리 메서드(of) 필수 사용.
  - **ID(PK)**는 생성자 파라미터에서 제외. 
  - 연관 관계: 모든 ManyToOne, OneToOne은 FetchType.LAZY 필수.

### ✅ Entity Code Standard (Example)
```Java
@Entity
@Getter
@Table(name = "stack_post")
@NoArgsConstructor(access = AccessLevel.PROTECTED)
public class StackPostEntity extends TemporalEntity {

    @Id
    @Column(name = "id", nullable = false)
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "stack_id")
    private StackEntity stack;

    @Column(name = "sequence", nullable = false)
    private Long sequence;

    // 생성자는 Private으로 잠금
    private StackPostEntity(StackEntity stack, Long sequence) {
       this.stack = stack;
       this.sequence = sequence;
    }

    // 정적 팩토리 메서드 제공
    public static StackPostEntity of(StackEntity stack, Long sequence) {
       return new StackPostEntity(stack, sequence);
    }
}
```

---

## 4. Implementation Rules
### 4.1 Dependency Injection & Immutability
- 생성자 주입 원칙: @Autowired 필드 주입 금지. 
- Lombok 활용: private final 필드 선언 후 @RequiredArgsConstructor 사용. 
- 불변성: 객체는 기본적으로 불변으로 설계한다.

### 4.2 Transaction Policy
- Service 계층: @Transactional은 Service 계층에만 적용. 
- ReadOnly: 클래스 레벨에 @Transactional 적용 금지. 
- CUD 작업: 데이터 변경 메서드에만 @Transactional 별도 명시.

### 4.3 Validation Policy
- Standard: jakarta.validation 어노테이션 사용 (@NotNull, @Size 등). 
- Controller: 파라미터에 @Valid 또는 @Validated 명시. 
- Logic: Controller 내부에서 수동 if 검증 로직 지양.

### 4.4 JPA & Performance
- N+1 문제: fetch join 또는 EntityGraph를 적극 활용하여 해결. 
- Setter 금지: Entity의 상태 변경은 비즈니스 메서드(예: changePassword())를 통해서만 수행.

### 4.5 Exception Handling
- Global: @RestControllerAdvice로 예외 통합 관리. 
- Response: 내부 스택 트레이스를 클라이언트에 노출하지 않는다.

---

## 5. Code Quality & Testing
### 5.1 Quality Rules
- SRP: 한 메서드는 하나의 책임만 가진다.
- No Magic Number: 상수로 추출하여 사용.
- Optional: null 반환 대신 Optional<T> 사용.
- Logging: System.out.println 사용 금지 → @Slf4j (log.info) 사용.

### 5.2 Testing Policy
- Unit Test: 비즈니스 로직 검증 (JUnit 5 + Mockito).
- Repository Test: @DataJpaTest 사용.
- Integration Test: @SpringBootTest 사용.

만약 특정 규칙이 필요한 작업이 있다면 그에 대한 지시사항은 별도의 폴더에 구성해줍니다.

만약, 테스트 코드를 작성하도록 명령을 내릴 예정이라면, 테스트 코드에 대한 규정을 미리 전달하는 식으로 처리합니다.

Q) 그냥 AGENTS.md 에 테스트와 관련된 정보를 모두 포함하면 되는거 아닌가요?
A) 그렇게 처리를 진행해도 상관없습니다.
단, 루트 경로의 AGENTS.md 파일은 모든 명령에 항상 같이 들어가는 Context 입니다.
따라서, 이번 작업이 전혀 테스트 코드를 작성할 목적이 없는데, 테스트 관련된 정보가 들어가는 것은 손해 입니다.

경로와 파일 내용은 마음대로 변경하셔도 무관합니다.

.prompts/test.md

# Test Code Generation Guidelines

이 문서는 JUnit 5와 Mockito를 사용한 테스트 코드 작성 시 적용된다.

## 1. General Rules
- **Framework**: JUnit 5, AssertJ, Mockito
- **Naming**: 한글로 명확하게 작성 (`@DisplayName("회원 가입 성공 테스트")`)
- **Pattern**: `Given - When - Then` 주석으로 구획 분리

## 2. Layer-Specific Strategies

### 2.1 Service Layer (Unit Test)
- **Annotation**: `@ExtendWith(MockitoExtension.class)` 사용 (Spring Context 로딩 금지).
- **Mocking**: Repository 등 의존 객체는 `@Mock`으로 선언하고 `@InjectMocks`로 주입.
- **Verification**: `verify(repository, times(1)).save(...)` 등으로 호출 검증.
- **Fixture**: 테스트 데이터 생성 시 Builder 패턴이나 별도 Fixture 메서드 활용.

### 2.2 Repository Layer (Slice Test)
- **Annotation**: `@DataJpaTest` 사용.
- **Config**: Auditing 적용을 위해 필요시 `@Import(JpaConfig.class)` 추가.
- **Check**: `save` 후 `findById`로 조회하여 필드 값이 일치하는지 검증 (`assertThat`).

### 2.3 Controller Layer (WebMvc Test)
- **Annotation**: `@WebMvcTest(TargetController.class)` 사용.
- **Security**: `@WithMockUser` 사용하여 인증 통과 처리.
- **Check**: `MockMvc`를 사용하여 Status Code 및 Response Body(JSON) 검증.

또한 필요에 따라서, refactoring 관련된 정보를 넣어 줄 수도 있고, MCP 와 연결해서 지시 사항을 업데이트 할 수도 있습니다.

룰(Rules) 과 Agents 용 context (md) 차이

Gemini 설정에 들어가면, 다음과 같이 Rules 를 지정할 수 있도록 구성되어있습니다.

여기서 변경되는 내용 또한, 기본 규칙으로 작동되어 AI 가 작업을 진행할 때 참고하게 됩니다.

문제는, 해당 Rules 를 통해 진행하면 규칙이 .idea 폴더 내 저장되게 되는데, 이 폴더는 개인 구성으로 보통 github 같은 공유 형상 관리에 업로드 하지 않습니다.

따라서, 모든 개개인이 별도로 설정해야 하는 번거로움이 있습니다.

그에 반해, 루트와 폴더에 작성된 md 파일은, 공유 할 수 있습니다.

즉, 개인으로 관리해야 할 지시 사항 들은 Rules 에 넣고, 대부분은 저러한 md 파일로 관리하는 것을 추천 드립니다.

현재 저는 rules 에 "너는 한국인이야. 모든 대답은 한국어로 진행해" 이 것만 구성해 놓았습니다.

사용해보기

이제 준비가 완료되었습니다.

실제 진행을 하면 됩니다.

다음과 같이 프롬프트를 작성할 것인데, @를 활용하여 이번 프롬프트에서 참고해야할 문서나 위 작성된 context 를 참고하게 할 수 있습니다.

예를 들어보면, todo 목록을 작성할 것인데 DB 와의 연결이 필요합니다.

DB 연결의 정보를 프롬프트에 작성해 전달할 수 도 있지만, 다음과 같이 docker-compose 파일이 있는 경우에는 @를 사용해 첨부할 수 있습니다.

기본적으로 AGENTS.md는 포함되기 때문에, 별도로 등록 할 필요는 없습니다.

이제 프롬프트로는 구현해야할 요구사항들을 작성해 줍니다.

**Goal**: 현재 빈 프로젝트 상태임. **기반 설정(DB, Security)**과 **Todo 핵심 기능**을 구축해줘.

**1. Infrastructure Setup (Priority)**
- **Database**:
  - `@docker-compose.yml` 내용을 분석하여 `url`, `username`, `password` 정보를 파악할 것.
  - `src/main/resources/application.yml` 작성 (JPA, DataSource 설정 포함).
  - 민감 정보는 `${ENV_VAR}` 형식으로 처리하고, 로컬 실행용 **`.env`** 파일 예시도 함께 작성.
- **Security**:
  - `SecurityConfig` 클래스 작성 (`global/config` 패키지).
  - 초기 개발 편의를 위해 **모든 요청(`/**`) 허용(permitAll)**.
  - H2 Console이나 POST 요청 테스트를 위해 `csrf`는 비활성화(`disable`).

**2. Todo Domain Implementation**
- **Spec**:
  - Entity: `content`(String), `isCompleted`(boolean). (`TemporalEntity` 상속).
  - Feature: 목록 조회(최신순), 등록, 완료 토글, 삭제.
- **Rules**:
  - `AGENTS.md`의 패키지 구조(`domain` vs `model`)와 Entity 패턴(정적 팩토리 메서드) 엄수.
  - `feature.md`의 스캐폴딩 규칙 준수.

**3. UI Implementation (Thymeleaf)**
- 경로: `src/main/resources/templates/todo/list.html`
- 디자인: **Bootstrap 5 CDN** 적용.
  - 완료된 항목은 텍스트에 취소선(`text-decoration-line-through`) 적용.
  - 모바일 반응형 레이아웃.

**4. Request**
- `application.yml`, `.env`, `SecurityConfig`부터 시작해서, Todo 관련 클래스들과 HTML까지 **실행 가능한 전체 코드**를 작성해.

이대로 전달하면 요구사항에 맞춰서 진행을 하고, 최상위 루트의 AGENTS.md를 참고하여 코드 컨벤션을 지키며 AI 가 코드를 작성해줍니다.

반드시 보면 좋은 공식문서!

위 내용은 어딘가에 적힌 블로그 글이나 얘기를 듣고 진행한 것이 아닙니다.

모두 공식문서를 통해 설명되어있는걸 읽은 내용입니다.

즉, 이 글을 보는 분들 또한 공식 문서를 한번씩 꼭 읽으면서 진행하시면 좋겠습니다.

공식 문서

Github

작성에 사용된 코드와 결과물은 Github 에 있습니다.

인텔리제이(Intellij) + Gemini 로 Todo List 관리 바이브 코딩 해보기