내 일에 바로 쓰는 방법
1인 빌더 프로젝트 브리프
중요한 작업을 맡기기 전에 제품, 사용자, 제약, 현재 상태, 판단 기준을 한 번에 전달한다.
핵심 아이디어
1인 빌더는 매번 같은 프로젝트 설명을 반복하느라 시간을 잃는다. 프로젝트 브리프는 흩어진 제품 맥락을 재사용 가능한 운영 문서로 바꾼다. 제품 정의, 대상 사용자, 하지 않을 것, 현재 상태, 판단 기준을 한 번에 담는다.
왜 효과적인가
LLM은 컨텍스트에 민감하다. 브리프는 추측을 줄이고 제약을 보존하며, 전략·글쓰기·디자인·코딩 세션이 같은 제품 현실에서 출발하게 한다.
앱 만들고 있어. 개선해줘.
제품: [이름]. 약속: [누가 어떤 결과를 얻는가]. 단계: [MVP/beta/launched]. 사용자: [핵심 사용자]. P0: [반드시 되는 것]. 안티골: [하지 않을 것]. 현재 상태: [완료/이슈]. 판단 기준: [속도/품질/비용] 우선. 검증: [테스트/브라우저/사용자 피드백].
내 일에 맞게 바꾸기
작업 템플릿
목표: [달성하려는 것]
맥락: [배경, 대상, 제약]
사용 패턴: 1인 빌더 프로젝트 브리프
변수: 제품 약속, 대상 사용자, 사업 목표, P0/P1/P2 범위, 취향 레퍼런스, 기술 맥락, 현재 상태, 판단 기준
출력: [정확한 출력 형식]
마무리 전: 한계와 개선점 1개를 적기운영 레시피
- 먼저 약한 버전을 적어 어떤 문제를 고치는지 확인한다.
- 지시문을 무작정 길게 만들지 말고 빠진 변수를 추가한다.
- 모델에게 출력 형식을 한 번 명확히 따르게 한다.
- 첫 답변을 아래 체크리스트로 검토한다.
- 개선된 버전을 재사용 패턴으로 저장한다.
프로젝트 컨텍스트 브리프 다운로드
.md 버전을 전략, 글쓰기, 디자인, 코딩 세션 전에 붙이는 1장짜리 프로젝트 기억 문서로 쓰세요.
품질 체크리스트
- 단순 작업이 아니라 실제 목표를 알려줬는가?
- 답을 요구하기 전에 출력 형식을 정했는가?
- 예시, 제약, 품질 기준을 넣었는가?
- 한계, 불확실성, 실패 케이스를 요구했는가?
- 다음에도 재사용 가능한 패턴으로 남겼는가?
모델별 노트
긴 컨텍스트, 비평, 구조화된 글쓰기에 강합니다. 섹션과 예시를 명확히 주는 편이 좋습니다.
빠른 반복과 일상 템플릿에 강합니다. 출력 형식과 가정을 명확히 적는 편이 좋습니다.
넓은 종합과 Google 계열 리서치에 유용합니다. 출처 요구사항을 명확히 두는 편이 좋습니다.
한계
브리프는 시간이 지나면 낡는다. 제품 피벗, 출시, 사용자 피드백, 스택 변경, 큰 결정 이후 갱신해야 한다. 비밀 정보나 고객 원문 데이터는 넣지 않는다.
다음에 볼 것
이 내용을 재사용 워크플로로 바꾸세요.
프롬프트 디버깅 체크리스트와 솔로 빌더 AI 세팅 팩을 언어별 .md 파일로 받을 수 있습니다.