바이브 코딩 실전 8화: AI에게 매번 설명하지 마세요

지난 편에서는 Git이라는 안전장치를 만들었습니다.

이제 AI가 코드를 잘못 수정하더라도 이전 상태로 돌아갈 수 있습니다.

제법 든든합니다.

그러면 드디어 AI에게 마음껏 일을 시키면 될 것 같습니다.

그런데 실제로 며칠 정도 바이브 코딩을 해보면 새로운 문제가 하나 나타납니다.

매번 비슷한 이야기를 반복하고 있는 겁니다.

처음에는 괜찮습니다.

열 번째쯤 되면 슬슬 이런 생각이 듭니다.

"이 정도면 AI가 나보다 이 프로젝트 설명을 더 많이 들었는데 왜 또 말하고 있지?"

오늘은 이 반복을 줄여보겠습니다.

AI에게 프로젝트의 규칙을 매번 설명하는 대신,

프로젝트 안에 AI가 참고할 업무 매뉴얼을 만들어두는 방법입니다.

1. AI는 똑똑하지만 매번 같은 출발선에 설 수 있다

우리가 지금까지 AI에게 꽤 많은 것을 알려줬습니다.

MyLog가 어떤 앱인지,

이번 MVP에 어떤 기능이 포함되는지,

어떤 기능은 제외하는지,

작업 완료 기준은 무엇인지,

Git을 어떻게 사용할 것인지까지 정했습니다.

문제는 새로운 작업을 시작할 때 이 정보가 항상 자동으로 완벽하게 이어진다고 가정하면 안 된다는 것입니다.

특히 코딩 에이전트는 현재 프로젝트의 파일을 읽을 수 있더라도

우리가 왜 이런 구조를 선택했는지

까지 코드만 보고 모두 알아내지는 못합니다.

예를 들어 AI가 MyLog 프로젝트를 살펴봅니다.

검색 기능이 없습니다.

AI가 생각합니다.

친절하게 추가할 수도 있습니다.

하지만 우리는 #04에서 검색을 MVP 범위에서 일부러 제외했습니다.

AI가 틀렸다기보다 배경을 모르고 있는 것입니다.

그래서 필요한 것이 Project Context, 프로젝트 컨텍스트입니다.

2. 컨텍스트는 AI에게 주는 프로젝트의 기억이다

컨텍스트라는 말을 어렵게 생각할 필요는 없습니다.

AI가 현재 작업을 제대로 이해하기 위해 알고 있어야 할 정보입니다.

예를 들면 이런 것들입니다.

이 프로젝트는 무엇인가?

현재 어떤 단계인가?

어떤 기술을 사용하는가?

어떤 구조를 유지해야 하는가?

이번 버전에서 하지 않을 것은 무엇인가?

코드를 수정할 때 어떤 원칙을 따라야 하는가?

작업이 끝났다고 판단하는 기준은 무엇인가?

이 정보가 충분하면 AI는 우리가 원하는 방향으로 움직이기 쉬워집니다.

반대로 컨텍스트가 부족하면 AI는 빈칸을 추측하게 됩니다.

바이브 코딩에서는 AI에게 더 긴 프롬프트를 쓰는 것보다

필요한 컨텍스트를 필요한 순간에 정확하게 제공하는 것

이 훨씬 중요할 때가 많습니다.

3. 그런데 PRD가 이미 있지 않나요?

맞습니다.

#05에서 우리는 PRD.md를 만들었습니다.

그러면 이런 의문이 생깁니다.

가능합니다.

하지만 역할이 조금 다릅니다.

PRD는 주로

무엇을 만들 것인가

를 설명합니다.

프로젝트 규칙은

어떻게 만들 것인가

를 설명합니다.

예를 들어

PRD에는 이런 내용이 있습니다.

사용자는 제목과 내용을 입력해서 기록을 저장할 수 있다.

프로젝트 규칙에는 이런 내용이 들어갑니다.

기존 프로젝트 구조를 임의로 변경하지 않는다.

큰 변경 전에는 먼저 작업 계획을 제시한다.

새 패키지를 추가하기 전에 필요성을 설명한다.

작업 완료 후 flutter analyze와 테스트를 실행한다.

둘은 서로 비슷해 보이지만 역할이 다릅니다.

정리하면 이렇습니다.

PRD

무엇을 만들 것인가

Project Rules

어떻게 작업할 것인가

이 구분을 해두면 프로젝트가 커질수록 훨씬 관리하기 편해집니다.

4. AI 코딩 도구들도 이미 이런 방식을 사용한다

이런 접근은 특정 도구 하나만의 방식이 아닙니다.

현재 Claude Code는 프로젝트의 CLAUDE.md 파일을 통해 프로젝트별 지속 지침을 제공할 수 있습니다. Anthropic 공식 문서에서도 프로젝트 구조, 빌드 명령, 코딩 규칙 같은 내용을 이런 파일에 담아 Claude가 작업할 때 참고하도록 안내하고 있습니다.

Cursor도 Project Rules, User Rules, Team Rules와 AGENTS.md 등 지속적인 지침을 제공하는 방식을 공식적으로 지원합니다.

Codex 역시 저장소에 AGENTS.md를 두어 프로젝트별 지침을 제공할 수 있으며, 디렉터리별 지침을 계층적으로 적용할 수 있습니다.

파일 이름과 기능은 도구마다 조금씩 다르지만 핵심 아이디어는 같습니다.

바이브 코딩이 단발성 실험을 넘어 제품 개발로 갈수록 이 방식의 가치가 커집니다.

5. 그렇다면 특정 AI 도구의 파일만 만들면 될까?

여기서 저는 한 단계 더 나눠보는 것을 권합니다.

프로젝트의 중요한 원칙을 처음부터 특정 AI 제품의 파일에만 넣지 않는 것입니다.

우리가 Claude Code를 쓰다가 나중에 Codex로 바꿀 수도 있고,

Cursor를 사용하다 다른 도구를 병행할 수도 있습니다.

그래서 먼저 도구와 무관한 기준 문서를 만들어두겠습니다.

예를 들면

docs/
 ├── PRD.md
 └── PROJECT_RULES.md

이렇게 만들 수 있습니다.

PRD.md

무엇을 만들 것인지

PROJECT_RULES.md

어떻게 개발할 것인지

를 담당합니다.

그리고 사용하는 AI 도구에 따라

CLAUDE.md

또는

AGENTS.md

등에서 이 문서들을 기준으로 작업하라고 알려주는 방식입니다.

이렇게 하면 AI 도구가 바뀌어도 프로젝트의 뇌까지 갈아엎을 필요는 없습니다.

6. MyLog의 프로젝트 규칙을 직접 만들어보자

이제 실제로 MyLog에서 사용할 PROJECT_RULES.md를 만들어보겠습니다.

처음부터 거창한 개발 표준을 만들 필요는 없습니다.

우리에게 필요한 내용부터 넣겠습니다.

# MyLog Project Rules

## 1. 프로젝트 목적

MyLog는 개인적인 기록을 작성하고
기기에 저장한 뒤 다시 확인할 수 있는
간단한 Flutter 모바일 앱이다.

세부 제품 요구사항은 docs/PRD.md를 기준으로 한다.

## 2. 현재 개발 단계

현재는 MVP 개발 단계다.

MVP 범위를 벗어난 기능을
임의로 추가하지 않는다.

## 3. 기본 작업 원칙

- 기존 기능을 최대한 유지한다.
- 요청받지 않은 기능을 임의로 추가하지 않는다.
- 한 번에 너무 많은 기능을 수정하지 않는다.
- 기존 프로젝트 구조를 이유 없이 변경하지 않는다.
- 복잡한 설계보다 현재 MVP에 필요한 단순한 구조를 우선한다.

## 4. 코드 변경 전

큰 변경이 필요한 경우 바로 수정하지 않는다.

먼저 다음 내용을 설명한다.

1. 변경 목적
2. 수정할 파일
3. 변경 방법
4. 기존 기능에 미치는 영향
5. 예상되는 위험

## 5. 패키지 추가

새로운 외부 패키지를 임의로 추가하지 않는다.

패키지가 필요하다면 먼저

- 패키지 이름
- 필요한 이유
- 패키지 없이 구현 가능한지
- 프로젝트에 미치는 영향

을 설명한다.

## 6. 보안

- API Key를 코드에 직접 작성하지 않는다.
- 비밀번호나 인증정보를 소스 코드에 저장하지 않는다.
- 민감정보가 Git에 포함되지 않도록 한다.

## 7. 작업 완료 기준

작업 완료 전에 다음을 확인한다.

- 앱이 정상적으로 빌드되는가
- 요청한 기능이 동작하는가
- 기존 기능이 깨지지 않았는가
- 불필요한 기능을 추가하지 않았는가
- 분석 또는 테스트에서 새로운 오류가 발생하지 않는가

## 8. 작업 완료 보고

작업 후 다음을 설명한다.

1. 수정한 파일
2. 주요 변경 내용
3. 추가한 패키지
4. 실행 또는 테스트 결과
5. 남아 있는 문제
6. 다음 작업에서 주의할 내용

사용자가 확인하기 전에는
임의로 Git Commit 하지 않는다.

이제 우리가 매번 반복하던 이야기가 상당 부분 문서 안으로 들어갔습니다.

7. 규칙은 많을수록 좋은 것이 아니다

여기서 욕심이 생길 수 있습니다.

AI에게 이것도 지키게 하고,

저것도 지키게 하고,

코드 스타일도 40개쯤 정하고...

그러다 보면 프로젝트 규칙 문서가 회사 취업규칙처럼 두꺼워집니다.

AI 입장에서도 모든 규칙이 똑같이 중요해 보이면 정작 중요한 지침이 묻힐 수 있습니다.

좋은 프로젝트 규칙은

짧고, 구체적이고, 실제 행동으로 연결되는 규칙

입니다.

예를 들어

별 도움이 되지 않습니다.

대신

는 행동으로 확인할 수 있습니다.

또

보다는

가 훨씬 구체적입니다.

8. 규칙과 취향도 구분하자

또 하나 중요한 점입니다.

우리가 선호하는 모든 것을 절대 규칙으로 만들 필요는 없습니다.

예를 들어

변수 이름은 의미를 알 수 있게 작성한다.

는 비교적 좋은 프로젝트 원칙입니다.

하지만

모든 버튼은 반드시 파란색으로 만든다.

는 UI 정책이 바뀌면 금방 쓸모없어질 수 있습니다.

그래서 문서를 나눠볼 수 있습니다.

PRD.md
제품 요구사항

PROJECT_RULES.md
개발 작업 원칙

UI_GUIDE.md
디자인 및 UI 원칙

프로젝트가 아직 작다면 두 파일만으로 시작해도 충분합니다.

문서도 코드와 같습니다.

필요해졌을 때 나눕니다.

첫날부터 문서 폴더가 정부 기록원처럼 되어 있을 필요는 없습니다. 📚

9. 중요한 결정은 채팅창에만 남겨두지 않는다

바이브 코딩을 하다가 꽤 중요한 결정을 했다고 해보겠습니다.

AI와 오랫동안 대화한 끝에

라고 결정했습니다.

그런데 이 결정이 채팅에만 남아 있습니다.

며칠 뒤 새로운 대화를 시작합니다.

AI에게 저장 기능을 만들어달라고 했더니

Supabase 연결부터 시작합니다.

AI가 잘못한 걸까요?

꼭 그렇지는 않습니다.

중요한 결정이 프로젝트에 기록되어 있지 않았기 때문입니다.

프로젝트에서 오래 유지되어야 하는 결정은 채팅창 밖으로 꺼내야 합니다.

예를 들어 PRD에 이렇게 남깁니다.

MVP 데이터 저장 방식

첫 번째 MVP에서는 서버와 클라우드를 사용하지 않는다.

모든 기록 데이터는 로컬에 저장한다.

클라우드 동기화는 이후 버전에서 검토한다.

이제 결정이 대화가 아니라 프로젝트의 일부가 됩니다.

이 습관은 프로젝트가 커질수록 굉장히 중요해집니다.

10. AI의 기억보다 프로젝트 문서를 믿자

요즘 AI 도구에는 대화 기억이나 자동 메모리 같은 기능도 발전하고 있습니다.

예를 들어 Claude Code 공식 문서에서는 CLAUDE.md를 이용한 명시적인 지침과 자동으로 축적되는 메모리를 서로 보완적인 방식으로 설명하고 있습니다.

Codex 역시 프로젝트 지침과 메모리 같은 여러 계층의 사용자 지정 방식을 제공하고 있습니다.

하지만 제품 개발에서 중요한 요구사항까지

에만 맡기지는 않겠습니다.

사람도 회의 끝나고 나면 기억이 조금씩 달라집니다.

AI라고 해서 프로젝트 회의록 담당자에게 무제한 기억력 배지를 달아줄 필요는 없습니다.

중요한 결정은 문서에 남깁니다.

기억은 편의 기능이고, 문서는 기준입니다.

11. 그렇다고 모든 문서를 매번 AI에게 읽히면 될까?

여기서 또 다른 극단이 등장합니다.

프로젝트 관련 파일 30개를 전부 AI에게 던지고

라고 할 수 있습니다.

하지만 좋은 컨텍스트 관리는

많은 정보를 주는 것

과 다릅니다.

필요한 정보를 주는 것입니다.

예를 들어 기록 목록 UI를 수정하는 작은 작업이라면

주요 프로젝트 규칙,

관련 PRD,

현재 UI 파일

정도면 충분할 수 있습니다.

결제도 없는 앱인데 미래의 결제 정책 문서까지 읽힐 이유는 없습니다.

컨텍스트도 여행 가방과 비슷합니다.

혹시 필요할까 싶어서 모든 것을 넣으면 결국 캐리어가 닫히지 않습니다. 🧳

12. 그래서 문서의 역할을 명확하게 만든다

MyLog에서는 당분간 이렇게 가져가겠습니다.

docs/
│
├── PRD.md
│
└── PROJECT_RULES.md

그리고 각각의 역할은 명확하게 합니다.

제품 목표

사용자

핵심 흐름

기능 요구사항

제외 범위

완료 조건

개발 원칙

변경 절차

패키지 추가 기준

보안 원칙

검증 방법

작업 결과 보고 방식

이렇게만 나눠도 AI가 참고해야 할 정보가 훨씬 정돈됩니다.

13. AI 도구별 지침 파일에는 무엇을 적을까?

예를 들어 Claude Code를 사용한다면 프로젝트 루트의 CLAUDE.md에 지속적인 프로젝트 지침을 둘 수 있습니다.

여기에 모든 PRD 내용을 복사할 필요는 없습니다.

핵심 역할만 적을 수 있습니다.

# MyLog AI Instructions

이 프로젝트는 Flutter 기반 MyLog 앱이다.

작업 전 아래 문서를 먼저 확인한다.

- docs/PRD.md
- docs/PROJECT_RULES.md

PRD의 MVP 범위를 벗어난 기능을
임의로 구현하지 않는다.

큰 변경은 바로 수행하지 말고
먼저 계획을 제시한다.

작업 완료 후 프로젝트 규칙에 정의된
검증 절차와 결과 보고 방식을 따른다.

Codex를 사용한다면 같은 목적의 지침을 AGENTS.md에 둘 수 있습니다. OpenAI 공식 문서에 따르면 Codex는 작업 전에 AGENTS.md 지침을 읽고 프로젝트별 규칙을 적용할 수 있습니다.

Cursor에서도 프로젝트 규칙을 지속적으로 적용하도록 Rules 기능을 사용할 수 있습니다.

도구마다 설정법은 달라도 우리가 관리하는 원본 원칙은 동일하게 유지하는 것이 포인트입니다.

14. 모든 AI에게 같은 역할을 줄 필요도 없다

프로젝트가 조금 커지면 AI를 여러 역할로 사용할 수 있습니다.

예를 들어

AI 1

기능 구현

AI 2

코드 리뷰

AI 3

테스트 관점 검토

를 맡길 수도 있습니다.

이때 모두에게 같은 프롬프트를 주는 것보다 역할에 맞는 컨텍스트를 주는 것이 좋습니다.

기능 구현 AI는

PRD + 프로젝트 규칙 + 관련 코드

를 봅니다.

리뷰 AI는

요구사항 + 변경 Diff + 리뷰 기준

을 봅니다.

테스트 AI는

Acceptance Criteria + 사용자 흐름

을 중심으로 봅니다.

그러면 AI를 그냥 여러 개 켜놓는 것이 아니라

역할이 다른 작은 개발팀처럼 사용할 수 있습니다.

15. 컨텍스트가 오래되면 오히려 독이 된다

이 부분도 중요합니다.

프로젝트 초반에는 이렇게 결정했습니다.

서버는 사용하지 않는다.

그런데 #13까지 진행한 뒤 클라우드 DB를 사용하기로 바뀌었습니다.

그런데 PROJECT_RULES.md에는 여전히

서버 사용 금지

라고 적혀 있다면?

AI는 최신 요구사항과 오래된 규칙 사이에서 충돌하게 됩니다.

그러면 우리는 또 AI를 혼냅니다.

AI 입장에서는 문서대로 했을 뿐입니다. 😶

따라서 기능이 바뀌면 코드만 수정하지 말고

관련 문서도 함께 수정해야 합니다.

앞으로 변경 흐름을 이렇게 가져가겠습니다.

요구사항 변경

↓

PRD 수정

↓

프로젝트 규칙 영향 확인

↓

코드 수정

↓

테스트

↓

Git Commit

문서 역시 제품의 일부입니다.

16. 프로젝트 문서도 Git으로 관리한다

여기서 #07의 Git과 또 연결됩니다.

PRD.md와 PROJECT_RULES.md 역시 Git에 포함시킵니다.

그러면

언제 요구사항이 바뀌었는지,

왜 새로운 규칙이 생겼는지,

어떤 코드 변경과 함께 문서가 바뀌었는지

확인할 수 있습니다.

예를 들어

feat: 기록 수정 기능 추가

커밋에서

코드뿐 아니라

PRD.md

도 함께 바뀌었다면,

나중에

를 추적하기 쉬워집니다.

Git이 코드의 타임머신이었다면 이제는 프로젝트 의사결정의 타임머신도 되는 셈입니다.

17. 프로젝트 규칙에 명령어도 적어두면 편하다

AI가 작업 후 무엇을 실행해야 하는지도 프로젝트 규칙에 넣을 수 있습니다.

우리 MyLog에서는 앞으로 예를 들어 이런 기준을 사용할 수 있습니다.

작업 완료 후 가능한 경우 다음 검증을 실행한다.

flutter analyze
flutter test

이렇게 해두면 매번

라고 말하지 않아도 됩니다.

다만 중요한 점이 있습니다.

검증 명령을 실행했다고 해서 실제 스마트폰 사용 테스트까지 끝난 것은 아닙니다.

AI가

All tests passed

라고 보고하더라도,

우리는 직접 앱을 실행해서 사용해봅니다.

자동 검증과 실제 사용 검증은 서로 다른 역할입니다.

18. AI에게 무조건 규칙을 지키라고만 하지 말자

프로젝트 규칙을 너무 강하게 만들면 예상하지 못한 상황에서 문제가 생길 수도 있습니다.

예를 들어

새로운 패키지는 절대로 추가하지 않는다.

라고 해버렸다고 생각해보겠습니다.

정말 필요한 기능이 생겨도 AI가 이상한 자체 구현을 만들 수 있습니다.

그래서

금지

보다는

승인 절차

를 두는 것이 좋은 경우가 많습니다.

나쁜 예:

패키지 추가 금지

조금 더 좋은 예:

새 패키지를 임의로 추가하지 않는다.

필요한 경우 이유와 대안을 먼저 설명하고
사용자 확인 후 추가한다.

이 차이가 중요합니다.

좋은 프로젝트 규칙은 AI의 손발을 묶는 것이 아니라

위험한 변경 앞에서 한번 확인하도록 만드는 신호등입니다. 🚦

19. 컨텍스트 문서에 비밀정보를 적지 않는다

프로젝트 컨텍스트 파일은 AI가 읽을 수 있도록 만들어놓은 파일입니다.

따라서 여기에

API Key,

DB 비밀번호,

서비스 계정 인증정보,

개인 토큰

같은 값을 적어서는 안 됩니다.

예를 들어 이런 내용은 위험합니다.

Supabase Password = XXXXXXXX

프로젝트 규칙에는 실제 값이 아니라 원칙을 적습니다.

인증정보는 환경변수를 통해 관리한다.

구체적인 보안과 환경변수 관리는 뒤의 #16에서 제대로 다루겠습니다.

지금부터 습관만 잡아두겠습니다.

설명은 컨텍스트에, 비밀은 비밀 저장소에.

20. 오늘 바로 사용할 수 있는 시작 프롬프트

이제 새로운 작업을 시작할 때 매번 긴 프로젝트 설명을 할 필요가 없습니다.

예를 들어 이렇게 시작할 수 있습니다.

프로젝트의 PRD와 Project Rules를 먼저 확인해줘.

아직 코드를 수정하지 말고
현재 요구사항과 프로젝트 상태를 기준으로

1. 이번 작업의 범위
2. 수정할 파일
3. 구현 방법
4. 기존 기능에 미칠 영향
5. 확인해야 할 위험

을 먼저 정리해줘.

내가 요청하지 않은 기능은 추가하지 마.

이제 상세한 프로젝트 설명은 문서에 있습니다.

프롬프트는 이번 작업에 집중할 수 있게 됩니다.

이것이 프로젝트 컨텍스트를 만들어두는 가장 큰 장점입니다.

21. 세션이 바뀌어도 프로젝트가 이어지게 만들자

바이브 코딩을 하루 만에 끝내는 경우는 많지 않습니다.

오늘 작업하고,

내일 다시 열고,

며칠 뒤 버그를 고치고,

다음 주 기능을 추가합니다.

그때마다 새로운 대화가 시작될 수 있습니다.

좋은 프로젝트라면 새 세션을 열었을 때도

PRD
+
Project Rules
+
Git History
+
현재 코드

만으로 현재 상태를 상당 부분 복원할 수 있어야 합니다.

이것을 저는 프로젝트의 외부 기억장치라고 생각합니다.

AI의 채팅 기록에 프로젝트가 종속되는 것이 아니라

프로젝트 폴더 자체가 필요한 기억을 가지고 있는 상태입니다.

제품 개발까지 생각한다면 이 구조가 훨씬 건강합니다.

22. 오늘의 삽질 방지 팁 🛠️

AI가 계속 같은 실수를 한다고 매번 채팅으로 혼내지 마세요.

예를 들어 AI가 자꾸 요청하지 않은 패키지를 추가한다고 해보겠습니다.

첫 번째는 이렇게 말할 수 있습니다.

두 번째 작업에서도 또 생깁니다.

다시 말합니다.

세 번째에도 반복됩니다.

그렇다면 이제 대화의 문제가 아니라 프로젝트 규칙의 문제입니다.

PROJECT_RULES.md에 적습니다.

새 외부 패키지는 사용자 승인 없이 추가하지 않는다.

필요한 경우 패키지명, 이유, 대안을 먼저 설명한다.

이제 일회성 잔소리가 팀 규칙으로 승격됐습니다.

개발팀에서도 같은 문제가 반복되면 회의 때만 이야기하는 것이 아니라 개발 가이드에 넣습니다.

AI 개발팀도 별반 다르지 않습니다. 🤖📋

23. 프로젝트 컨텍스트에는 세 종류의 정보를 남긴다

오늘 내용을 조금 더 단순하게 정리하면 앞으로 프로젝트에 남길 정보는 크게 세 가지입니다.

PRD.md

무엇을 만드는지,

어떤 기능이 필요한지,

무엇은 제외하는지 기록합니다.

PROJECT_RULES.md

어떤 방식으로 코드를 변경하고,

어떻게 검증하며,

어떤 행동은 사용자 확인이 필요한지 기록합니다.

Git

실제로 무엇이 바뀌었고,

언제 정상 상태였으며,

어떤 기능이 언제 추가됐는지 기록합니다.

이 세 가지가 함께 있으면 AI에게 상당히 좋은 작업 환경을 만들어줄 수 있습니다.

PRD
무엇을 만들지

+

Project Rules
어떻게 만들지

+

Git
무엇이 바뀌었는지

꽤 괜찮은 삼총사입니다.

24. 그렇다고 문서 작성만 하다가 개발이 늦어지면 안 된다

여기까지 읽고 이런 생각이 들 수도 있습니다.

맞습니다.

하지만 우리가 만드는 문서는 모두 짧습니다.

그리고 반복되는 설명과 실수를 줄이기 위해 존재합니다.

문서 자체가 목적이 아닙니다.

문서를 쓰느라 개발 속도가 더 느려진다면 잘못 사용하고 있는 겁니다.

처음에는

PRD.md
PROJECT_RULES.md

두 개면 충분합니다.

필요할 때만 추가합니다.

바이브 코딩의 장점인 속도는 살리되,

제품 개발에 필요한 기억은 프로젝트 안에 남기는 것.

그 정도의 균형을 가져가겠습니다.

25. 오늘 MyLog 프로젝트는 이렇게 달라졌다

지금까지 MyLog에는 코드만 있었습니다.

이제는 프로젝트를 설명하는 문서가 함께 들어갑니다.

mylog/
│
├── docs/
│   ├── PRD.md
│   └── PROJECT_RULES.md
│
├── lib/
│
├── test/
│
├── android/
├── ios/
├── macos/
│
└── pubspec.yaml

그리고 사용하는 AI 에이전트에 따라 프로젝트 지침 파일을 연결할 수 있습니다.

예를 들어

CLAUDE.md

또는

AGENTS.md

등입니다. 현재 Claude Code, Cursor, Codex 모두 프로젝트 수준의 지속 지침을 제공하는 방식을 지원하고 있습니다.

이제 프로젝트를 열고 AI에게 한마디 합니다.

설명의 상당 부분이 끝났습니다.

26. 오늘의 완료 조건

이번 편 역시 완료 기준을 확인해보겠습니다.

[ ] PRD와 Project Rules의 차이를 이해했다.

[ ] docs/PRD.md를 프로젝트에 두었다.

[ ] docs/PROJECT_RULES.md를 만들었다.

[ ] 현재 MVP 개발 원칙을 문서에 기록했다.

[ ] 요청하지 않은 기능을 임의로 추가하지 않는 규칙을 넣었다.

[ ] 큰 변경 전 계획을 먼저 제시하도록 규칙을 만들었다.

[ ] 새 패키지 추가 전 확인 절차를 만들었다.

[ ] 작업 후 검증과 결과 보고 기준을 정했다.

[ ] 프로젝트 문서를 Git으로 관리하기 시작했다.

[ ] 사용하는 AI 코딩 도구의 프로젝트 지침 방식과 연결할 준비를 했다.

여기까지 끝났다면 이제 AI에게 프로젝트를 설명하는 시간보다

실제로 기능을 만드는 시간

이 더 길어질 겁니다.

드디어 준비운동이 거의 끝났습니다.

27. 이제 화면부터 만들면 될까?

다음 편에서는 드디어 MyLog의 실제 화면을 설계합니다.

그런데 바로 AI에게

라고 하지는 않겠습니다.

먼저 사용자가 앱을 열어서 기록을 작성하고 다시 확인할 때까지

어떤 화면을 어떤 순서로 이동하는지

정리하겠습니다.

그리고 더 중요한 것이 하나 있습니다.

화면을 그리기 전에

각 화면에서 어떤 데이터가 필요한지

함께 생각해볼 겁니다.

왜냐하면 앱에서 화면과 데이터는 따로 놀지 않기 때문입니다.

기록 목록 화면이 있다면 어떤 데이터를 보여줄지 알아야 하고,

상세 화면이 있다면 어떤 값을 전달할지 알아야 합니다.

다음 편에서는 코드보다 먼저 이 흐름을 설계합니다.

[바이브 코딩 실전 #09] 화면부터 예쁘게 만들지 마세요 | 사용자 흐름과 데이터 구조 먼저 설계하기

이제부터 MyLog의 모습이 조금씩 눈에 보이기 시작합니다.

하지만 버튼 색깔부터 고르지는 않겠습니다.

먼저 사용자가 어디로 가고, 데이터가 어디로 움직이는지부터 길을 내겠습니다.

인테리어보다 수도관을 먼저 놓는 셈입니다. 🔧

연재 기준: 2026년 8월AI 코딩 도구의 프로젝트 지침 파일명과 적용 방식은 업데이트될 수 있습니다. Claude Code, Cursor, Codex 등 특정 도구에 실제 규칙을 적용할 때는 해당 시점의 공식 문서를 다시 확인하는 것을 권장합니다.

#바이브코딩 #VibeCoding #AI코딩 #AI에이전트 #프로젝트컨텍스트 #프로젝트규칙 #PRD #ClaudeCode #Cursor #Codex #AGENTSmd #Flutter #비개발자앱개발 #MVP개발 #MyLog #바이브코딩실전