본문 바로가기
메이커로그

AI 시대의 1인 개발, 코딩보다 기획이 먼저다

by 고니누나 2026. 4. 22.
728x90
반응형

클로드(Claude)를 활용해 혼자서도 완성도 높은 프로젝트를 만드는 법

AI 코딩 도구가 쏟아지면서 많은 1인 메이커들이 비슷한 경험을 한다.

"일단 만들어봐야지" → 클로드한테 코드 요청 → 돌아가긴 하는데 뭔가 수상함 → 수정 요청 → 또 수정 → 결국 처음부터 다시.

 

문제는 AI가 부족해서가 아니다. 기획 없이 코딩부터 시작했기 때문.

 

이 글은 클로드를 처음 써보거나, 써봤지만 뭔가 아쉬웠던 1인 메이커를 위해 써봤다. 나 역시 겪어온 과정이다.

핵심은 단순하다: 코드를 짜기 전에 클로드와 함께 기획을 완성할것.

 

왜 기획이 먼저여야할까?

AI는 "시키는 대로" 한다

클로드는 훌륭한 실행자다. 하지만 당신이 "로그인 기능 만들어줘"라고 하면, 클로드는 그냥 로그인 기능을 만들어준다.

 

그 로그인이 소셜 로그인인지, 이메일 인증인지, 사용자 테이블 구조는 어떤지, 나중에 추가할 기능과 어떻게 연결되는지 — 이 맥락이 없으면 클로드도 추측으로 채울 수밖에 없다.

 

그 추측이 쌓이면? 나중에 "이 코드랑 저 코드가 안 맞아요" 같은 상황이 반복된다.

 

기획은 AI와의 "공통 언어"

기획 문서는 단순히 할 일 목록이 아니다. 클로드에게 프로젝트의 전체 맥락을 전달하는 컨텍스트 베이스다.

 

잘 만들어진 전략 문서 하나가 있으면, 매번 코드 요청할 때마다 긴 설명을 반복하지 않아도 된다. 그냥 문서를 붙여넣고 "이 맥락에서 ~를 만들어줘"라고 하면 된다.

 

ChatGPT vs Claude, 기획과 코딩에서의 차이

두 AI 모두 써본결과 모두 뛰어나지만, 1인 개발의 워크플로우에서는 차이가 있었다.

 

항목 Claude Claude 
기획 문서 작성 좋음 매우 좋음 — 구조화된 사고와 논리적 흐름이 강점
코드 품질 좋음 매우 좋음 — 일관성과 가독성이 높고 실수가 적음
긴 맥락 유지 대화가 길어지면 앞 내용을 잊는 경우 있음 긴 문서도 꼼꼼히 읽고 참조함
지시 준수 가끔 임의로 해석 지시한 대로 충실히 따름
기획-실행 일관성 보통 높음 — 기획 문서를 주면 그 틀 안에서 코딩함

 

특히 기획 단계에서의 차이가 크다.

 

클로드는 "이 서비스의 핵심 가치는 무엇인가?", "어떤 사용자 흐름이 필요한가?" 같은 상위 레벨 질문에 대해 단순 나열이 아닌 논리적으로 연결된 답변을 준다. 전략 문서를 함께 만들 때 파트너로서의 깊이가 다르다.

 

실전: 클로드와 함께하는 기획 → 실행 프로세스

STEP 1. 아이디어를 "서비스 정의서"로 만들기

코드 먼저 짜기 전에, 클로드와 대화로 서비스를 정의한다.

클로드에게 이렇게 물어보자

나는 [서비스 아이디어]를 만들려고 해.
다음 항목으로 서비스 정의서를 작성해줘:
1. 서비스 한 줄 설명
2. 핵심 타겟 유저 (1명을 구체적으로 묘사)
3. 해결하는 문제
4. 핵심 기능 3가지
5. MVP 범위 (첫 버전에 꼭 필요한 것만)
6. 제외할 기능 (나중에 해도 되는 것)

 

이 단계에서 "아, 내가 생각한 것과 다르네"를 발견하면 축복이다. 코드를 짠 다음에 발견하는 것보다 훨씬 낫다.

 

STEP 2. 기술 스택과 구조 설계

서비스가 정의되면, 기술 선택도 클로드와 함께 한다.

이렇게 물어보자:

위 서비스를 혼자 개발하려고 해. 나의 조건은:
- 기술 수준: [초급/중급]
- 배포 목표: [웹앱/모바일앱]
- 예산: [무료/소액]
- 타임라인: [2주/한달]

이 조건에서 가장 적합한 기술 스택을 추천하고,
폴더 구조와 데이터 모델 초안을 만들어줘.
 

여기서 나온 기술 스택과 데이터 구조가 이후 모든 코딩의 기준이 된다.

 

STEP 3. 전략 문서(PRD) 완성하기

서비스 정의와 기술 설계가 끝나면, 이것들을 하나의 **전략 문서(PRD: Product Requirements Document)**로 통합한다.

PRD에 들어가야 할 항목은 이렇다:

# [프로젝트명] PRD

## 1. 서비스 개요
- 한 줄 설명
- 핵심 문제
- 타겟 유저

## 2. MVP 기능 목록
- 기능 A: 설명
- 기능 B: 설명
- 기능 C: 설명

## 3. 기술 스택
- 프론트엔드: 
- 백엔드: 
- 데이터베이스: 
- 배포: 

## 4. 데이터 모델
- Users 테이블: 필드 목록
- Posts 테이블: 필드 목록

## 5. 페이지 및 라우팅
- / : 랜딩 페이지
- /dashboard : 메인 대시보드
- /settings : 설정

## 6. 범위 밖 (v2에서)
- 기능 X
- 기능 Y

 

이 문서를 클로드와 함께 만들고, 만족스러우면 저장하자. 마음에 안들거나 궁금한 부분이 있다면 계속 물어보면서 문서를 수정하자. 이제 이 문서가 개발 규칙이 된다.

 

STEP 4. 태스크 추출 및 우선순위 정하기

PRD가 완성되면, 클로드에게 개발 태스크를 추출하도록 요청한다.

위 PRD를 기반으로 개발 태스크를 추출해줘.
규칙:
- 각 태스크는 하루 안에 완료 가능한 크기로 쪼개기
- 의존성 순서대로 정렬 (선행 태스크가 먼저)
- 각 태스크에 예상 소요시간 포함
- 형식: [ ] 태스크명 (예상시간) — 설명

 

 

결과물 예시:

[ ] 프로젝트 초기 세팅 (1h) — Next.js + Tailwind 설치, 폴더 구조 생성
[ ] DB 스키마 생성 (2h) — Supabase에 Users, Posts 테이블 생성
[ ] 인증 구현 (3h) — 이메일 로그인, 세션 관리
[ ] 메인 레이아웃 컴포넌트 (2h) — 헤더, 사이드바, 푸터
[ ] 포스트 작성 페이지 (4h) — 에디터, 저장 기능
...
 

이제 우리에게 명확한 로드맵이 생겼다.

 

728x90

STEP 5. 태스크 단위로 클로드와 코딩하기

앞선 과정을 모두 마친다음 코딩을 시작한다. 각 태스크를 시작할 때마다 이 패턴을 따른다:

[PRD 전체 내용 붙여넣기]

현재 완료된 태스크:
- 프로젝트 초기 세팅 완료
- DB 스키마 생성 완료

지금 할 태스크:
- 인증 구현 (이메일 로그인, 세션 관리)

기술 스택: Next.js, Supabase, TypeScript

코드를 작성해줘.
 

이렇게 하면 클로드는 항상 전체 맥락을 알고 있는 상태에서 코드를 짜기 때문에 이전 코드와 충돌하거나, 나중에 바꿔야 할 결정을 지금 해버리는 일이 줄어든다.

 

흔한 실수와 해결책

실수 1: 기획을 너무 짧게 끝낸다 

"로그인, 게시판, 마이페이지" 이 세 줄이 기획의 전부인 경우. 이 정도면 클로드도 추측으로 채울 수밖에 없다. 기획이 상세할수록 코드가 정확해진다.

 

실수 2: 태스크가 너무 크다

"백엔드 전체 만들어줘"는 태스크가 아니다. "Users 테이블 생성 + 회원가입 API 엔드포인트 하나"가 태스크다. 작게 쪼갤수록 클로드의 응답 품질이 올라간다.

 

실수 3: PRD나 이전 맥락없이 매번 새로 요청한다

새 대화창을 열 때마다 PRD를 붙여넣는 게 귀찮더라도 꼭 해야한다. 클로드는 이전 대화를 기억하지 못한다. PRD가 그 기억을 대신한다.

 

실수 4: 생성된 코드를 이해 없이 붙여넣는다

클로드에게 "이 코드에서 핵심 로직 3줄만 설명해줘"라고 습관적으로 물어보자. 클로드가 나에게 개발을 가르쳐주는 선생님이라고 생각하고, 개발 과정을 스스로 이해하기 위해 노력해야한다. 이해 없이 쌓인 코드는 나중에 수정할 수 없는 블랙박스가 된다.

 

마치며

AI가 코딩을 도와주는 시대에도, 변하지 않는 것이 있다. 무엇을 만들지 명확히 아는 사람만이 좋은 결과를 얻는다는 것.

클로드는 뛰어난 파트너다. 하지만 파트너도 목표와 맥락이 있어야 제대로 일한다. 기획 문서 하나가 수십 번의 수정을 막아준다.

 

새로운 프로젝트를 계획중이라면?

프로젝트를 시작할 때, 코드를 짜기 전 클로드에게 먼저 이렇게 물어보자.

 

"내가 만들려는 서비스가 이건데, PRD 초안 만들어줘."

 

이 한 문장이 1인 메이커인 당신의 개발 방식을 바꾸고 업그레이드할 수 있다.

728x90
반응형