AI 도구를 프론트엔드 MVP 개발 흐름에 넣어본 기록

1. AI를 어떻게 사용하려고 했나

2. AI와 함께 개발하기 위해 사용한 도구들

AI와 함께 개발할 때는 프롬프트만 잘 쓰는 것보다, AI가 만든 결과를 확인할 기준을 갖는 것이 중요했습니다. 저는 도구들을 “코드를 대신 짜주는 것”보다, 제가 놓칠 수 있는 위험을 찾고 판단을 보조하는 용도로 사용했습니다.

실제로 사용한 도구는 react-doctor, typescript-lsp, frontend-design, 그리고 OpenClaw였습니다. context7은 아직 본격적으로 쓰지는 않았지만, 이후 문서 검증 단계에 붙이려고 넣어둔 도구입니다.

react-doctor는 GitHub 트렌드를 보다가 알게 됐고, typescript-lsp, context7, frontend-design은 Claude 플러그인 목록에서 알게 됐습니다.

1
"use client";
2

3
import { useEffect, useState } from "react";
4

5
export default function DashboardPage() {
6
  const [data, setData] = useState<DashboardData | null>(null);
7

8
  useEffect(() => {
9
    fetch("/api/dashboard")
10
      .then((res) => res.json())
11
      .then(setData);
12
  }, []);
13

14
  if (!data) return <div>로딩 중...</div>;
15

16
  return <ChartArea data={data} />;
17
}

1
export default async function DashboardPage() {
2
  const data = await loadDashboardDataOnServer();
3

4
  return <ClientOnlyChart data={data} />;
5
}

1
const reminderText = "2026.05.24 21:00 · 매일";
2

3
// scheduleNotification 내부에서
4
// 이 문자열이 날짜인지, 매일 반복인지, 매주 반복인지 다시 판단해야 한다.
5
await scheduleNotification(reminderText);

1
type ReminderSchedule =
2
  | { kind: "date"; date: Date }
3
  | { kind: "daily"; hour: number; minute: number }
4
  | { kind: "weekly"; weekday: number; hour: number; minute: number };
5

6
const schedule: ReminderSchedule = {
7
  kind: "daily",
8
  hour: 21,
9
  minute: 0,
10
};
11

12
await scheduleNotification(schedule);

1
// client component
2
await fetch("/api/quests", {
3
  method: "POST",
4
  body: JSON.stringify({ title }),
5
});

1
export async function POST(request: Request) {
2
  const { title } = await request.json();
3
  await createQuest(title);
4

5
  return Response.json({ ok: true });
6
}

1
"use server";
2

3
export async function createQuestAction(formData: FormData) {
4
  const title = String(formData.get("title"));
5
  await createQuest(title);
6
}

1
import { createQuestAction } from "./actions";
2

3
export default function QuestPage() {
4
  return (
5
    <form action={createQuestAction}>
6
      <input name="title" />
7
      <button type="submit">추가</button>
8
    </form>
9
  );
10
}

3. AI를 작업 흐름에 넣은 방식

AI를 따로 떼어놓고 “질문에 답해주는 도구”처럼 쓰기보다, 개발 흐름 안에 넣어 사용하려고 했습니다.

처음에는 MVP에 어떤 기술 구성이 맞을지부터 AI와 함께 비교했습니다. 웹앱으로 만들지 앱으로 만들지, Supabase를 쓸지 다른 DB를 쓸지, 별도 Node.js 서버를 둘지 Next.js 안에서 서버 기능을 처리할지 같은 선택지를 먼저 열어두고 봤습니다.

이 단계에서 중요했던 것은 정답을 바로 고르는 것이 아니라, MVP에서 감당할 수 있는 복잡도를 보는 일이었습니다. 빠르게 검증해야 하는 프로젝트라면 별도 서버를 두는 것보다 Next.js 안에서 처리하는 편이 나을 수 있고, 로그인 장벽을 낮춰야 한다면 익명 인증을 먼저 고려할 수 있다고 봤습니다.

그다음에는 레이아웃을 빠르게 그렸습니다. 처음부터 완성도 높은 화면을 만들기보다, 사용자가 어떤 순서로 움직이는지 확인할 수 있는 정도로 먼저 구성했습니다. 이후 frontend-design으로 UI 톤과 시각적 디테일을 한 번 더 다듬고, 그 위에 실제 기능을 붙였습니다.

기능이 어느 정도 붙은 뒤에는 react-doctor로 리팩토링할 지점을 찾았습니다. 서버 컴포넌트로 옮길 수 있는 부분, 접근성 문제, 너무 커진 컴포넌트, 데이터 로딩 위치처럼 눈으로만 보면 지나치기 쉬운 부분을 먼저 확인했습니다.

그다음 typescript-lsp로 타입과 참조 관계를 확인했습니다. AI가 제안한 리팩토링이 실제 타입 정의와 사용처를 깨뜨리지 않는지, 함수나 컴포넌트를 옮겼을 때 연결이 유지되는지 보는 용도였습니다.

4. Emova에서 커맨드와 에이전트를 나눠 쓴 방식

Emova에서는 기능을 어느 정도 붙인 뒤, 작업을 더 잘게 나눠서 다뤘습니다. 이때 /emova-component-split 커맨드와 planner, refactorer 에이전트를 사용했습니다.

먼저 /emova-component-split은 진단과 계획을 위한 커맨드로 사용했습니다. 큰 컴포넌트나 역할이 많이 섞인 파일을 찾고, 렌더링, 상태 관리, API 호출, 모달, 이벤트 핸들러, 순수 로직이 한 파일에 섞여 있는지 확인했습니다. 중요한 점은 이 커맨드가 바로 코드를 수정하는 역할은 아니라는 점입니다. “어디를 어떤 순서로 나누면 안전한가”를 먼저 보는 용도였습니다.

1
Emova의 큰 컴포넌트/파일을 찾아 역할 분리 후보를 제안한다.
2

3
## 목적
4
- 400줄 초과 파일 또는 역할이 과도하게 섞인 파일을 조기에 발견
5
- 리팩토링 전에 안전한 분리 순서 제안
6

7
## 절차
8
1. `find src -type f \( -name "*.tsx" -o -name "*.ts" \) -exec wc -l {} + | sort -nr | head -30` 실행
9
2. 200줄 이상 파일부터 읽고 역할을 분류한다
10
3. 아래 기준으로 판단한다
11
   - 렌더링
12
   - 상태 관리
13
   - API 호출
14
   - 모달/토스트/네비게이션
15
   - 복잡한 이벤트 핸들러
16
   - 순수 비즈니스 로직
17
4. 400줄 초과 파일은 반드시 사용자에게 알린다
18
5. 테스트 가능한 순수 로직부터 분리하는 계획을 우선 제안한다
19

20
## 출력 형식
21
- 파일명 / 줄 수 / 섞인 역할
22
- 위험도: 높음/중간/낮음
23
- 추천 분리 단위
24
- 안전한 작업 순서
25
- 분리 후 실행할 검증 명령
26

27
바로 파일을 삭제하거나 대규모 이동하지 말고, 먼저 분리 계획을 확인받는다.

planner 에이전트는 구현 전 작업 범위를 정리하는 역할이었습니다. 사용자 흐름, 필요한 기능, 엣지 케이스, 우선순위를 먼저 정리하게 해서 바로 코드부터 쓰기보다 어떤 순서로 만들지 잡는 데 사용했습니다.

refactorer 에이전트는 계획이 잡힌 뒤 실제 구조를 고치는 역할이었습니다. component-split이 찾아낸 분리 후보를 바탕으로, 동작은 유지한 채 파일 분리, 네이밍, 타입 정리, 중복 제거를 진행했습니다. 즉 component-split이 “어디를 나눌지 찾는 도구”라면, refactorer는 “정해진 범위 안에서 실제로 고치는 에이전트”에 가까웠습니다.

이렇게 나눠보니 한 에이전트에게 모든 일을 맡기는 것보다 작업 의도가 더 분명해졌습니다. 진단, 계획, 실행을 분리하니 AI 결과를 검토하기도 쉬웠고, 이후 테스트와 빌드로 리팩토링 결과를 확인할 수 있었습니다.

5. 제품 관점에서 배운 점

두 프로젝트를 만들면서 기획적으로 가장 많이 본 것은 퍼널, 전환율, 리텐션이었습니다. 기능을 많이 붙이는 것보다 사용자가 어느 단계에서 멈추는지 확인하는 것이 더 중요하다고 봤습니다.

later-you-said에서는 카드 본문을 서버로 보내지 않았습니다. 제목, 링크, 메모 같은 개인 데이터는 기기 안에 두고, Supabase에는 사용자가 새 카드를 추가했는지, 저장한 링크를 다시 열었는지, 항목을 완료 또는 미완료로 바꿨는지 같은 익명 사용 이벤트와 카테고리·소요 시간 같은 메타데이터만 선택적으로 쌓는 방식으로 설계했습니다. 저장 수보다 중요한 것은 저장한 항목을 다시 열고 완료 처리하는지였습니다.

Emova에서는 감정 선택부터 회고까지 하나의 session_id로 묶었습니다. 익명 인증과 client_id를 사용해 가입 장벽은 낮추되, 감정 선택 → 생각 선택 → AI 추천 → 퀘스트 등록 → 완료 → 회고 흐름이 DB에 남도록 했습니다. 그래야 단순히 “감정을 몇 번 선택했는지”가 아니라 사용자가 어디까지 도달했는지 볼 수 있기 때문입니다.

Emova 대시보드에서는 실제로 이런 지표를 확인하도록 만들었습니다.

• 루프 완주 퍼널: 세션 시작 → 플로우 완료 → 회고 완료
• 전환율: 시작 → 완료, 완료 → 회고, 전체 완주율
• 리텐션 힌트: 기기별 첫 접속, 마지막 접속, 세션 수, 활동 시간대
• 행동 지표: 퀘스트 상태 분포, 감정/생각 선택 분포

이 지표를 보면서 수정할 것도 README의 TODO에 남겼습니다. 예를 들어 회고로 이어지는 액션 버튼 패턴, 첫 화면 선택지 확장, 감정 복수 선택 같은 항목은 단순 기능 추가가 아니라 사용자가 퍼널 중간에서 멈추는 이유를 줄이기 위한 후보였습니다.

결국 제품은 기능 목록이 아니라 사용자가 반복해서 행동하게 만드는 흐름으로 봐야 한다고 느꼈습니다.

6. 결론

이번 프로젝트를 만들면서 AI에 대해 느낀 점은 크게 세 가지였습니다.

첫째, AI를 쓰기 전에 만들고 싶은 것을 먼저 정해야 했습니다. AI는 코드를 빠르게 만들고 아이디어도 많이 제안해줍니다. 하지만 어떤 기능이 꼭 필요한지, 어디까지 만들고 멈출지는 제가 정해야 했습니다. 기준 없이 맡기면 기능은 늘어나지만, MVP는 오히려 복잡해질 수 있었습니다.

둘째, AI가 만든 코드는 다시 확인해야 했습니다. 겉으로는 잘 돌아가 보여도 파일이 너무 커지거나, 상태 관리와 UI가 한곳에 섞이는 문제가 생길 수 있었습니다. 그래서 react-doctor처럼 점수와 진단 결과를 보여주는 도구로 한 번 더 확인했습니다. 덕분에 감으로만 보지 않고, 어디부터 고칠지 정하기 쉬웠습니다.

셋째, AI가 정리한 내용도 제 말로 다시 바꿔야 했습니다. AI가 써준 문장이 그럴듯해도 제가 설명하지 못하면 의미가 없었습니다. 그래서 문서나 코드 설명도 그대로 쓰지 않고, 제가 이해한 이유와 흐름으로 다시 고쳤습니다.

결국 AI는 혼자 제품을 완성해주는 도구라기보다, 제가 만들고 싶은 것을 더 빨리 실험하게 도와주는 도구에 가까웠습니다. 앞으로도 AI를 쓰더라도, 마지막에는 제가 이해하고 설명할 수 있는 형태로 만들고 싶습니다.