1. 한 줄과 한 문단의 차이

3장의 첫 실습에서 썼던 요청을 다시 보겠습니다.

나는 바이브 코딩을 강의하는 강사야. 바이브 코딩을 소개하고, 수강 신청을 할 수 있는 랜딩 페이지를 만들어줘.

- 접수 폼 링크: https://forms.gle/Ddj742DqPZ5Eb8j79
- HTML, CSS, JavaScript로 만들어줘.
- 휴대폰에서 봐도 깨지지 않아야 해.
- 대문 파일 이름은 index.html로 해줘.

이것을 '랜딩 페이지 만들어줘' 한 줄과 비교하면 무엇이 더 있을까요. 누가 쓰는지(강사), 무엇이 있어야 하는지(소개, 수강 신청), 재료(폼 링크), 조건(기술, 휴대폰, 파일 이름)이 있습니다. 이 네 가지가 브리프의 뼈대입니다.

브리프는 명세서가 아닙니다. 여러분이 확실히 아는 것만 적은 한 문단입니다. 앞선 책의 명세서 템플릿에 있던 '시스템 아키텍처', 'ERD', 'API 명세' 같은 칸은 없습니다. 그 칸을 채우는 것은 Claude의 일이고, 채운 이유를 묻는 것이 여러분의 일입니다.

2. 브리프의 네 줄

2.1 누가, 왜

이 결과물을 누가 쓰는지, 왜 만드는지 한 문장입니다. "제주 감귤 농장 주인인데, 지인들에게 카카오톡으로 링크를 보내 감귤 주문을 받고 싶어." 이 한 문장이 있고 없고의 차이는 큽니다. Claude는 이 문장에서 화면의 톤, 필요한 항목, 굳이 필요 없는 것을 추론합니다. 회원가입이 필요 없다는 것도, 결제가 필요 없다는 것도, 폰 화면이 중요하다는 것도 이 문장에서 나옵니다.

2장에서 말한 AI의 간섭을 떠올려보세요. 여러분이 말하지 않은 여백을 AI가 채웁니다. '누가, 왜'는 그 여백을 가장 넓게 줄이는 한 문장입니다.

2.2 무엇이 보여야 하나

화면에 있어야 하는 것을 위에서 아래로 적습니다. 기능 목록이 아니라 눈에 보이는 순서입니다.

- 맨 위에 농장 사진과 이름
- 그 아래 감귤 종류와 가격 (3종류)
- 주문하려면 이름, 연락처, 종류, 수량, 배송지를 적는 칸
- 맨 아래 농장 연락처

개발을 모르는 분이 가장 잘 아는 것이 이것입니다. 어떤 화면을 원하는지는 여러분이 개발자보다 잘 압니다. 여기에 시간을 쓰세요. 기술 용어는 하나도 필요 없습니다.

2.3 재료

폴더에 넣어둔 파일, 외부 링크, 참고할 서비스를 적습니다. 재료가 있으면 Claude가 지어내지 않습니다.

- 감귤 사진은 폴더의 photos 안에 있어
- 가격표는 폴더의 가격.xlsx에 있어
- 참고할 분위기는 https://example.com 같은 느낌

3장 3절에서 재료를 폴더에 넣어 두라고 한 이유입니다. 재료 없이 "감귤 가격표를 넣어줘"라고 하면 Claude는 가격을 지어냅니다. 그리고 그 지어낸 가격이 검토에서 걸립니다.

2.4 하지 말 것과 조건

이 줄이 앞선 책의 명세서에는 없던 줄입니다. 2장 4절에서 '제약사항 부여'가 배워야 할 것 중 하나라고 했는데, 브리프에서는 여기에 씁니다.

- 회원가입, 로그인 없이
- 결제 기능 없이, 주문은 접수만
- 파일은 index.html 하나로
- 폰에서 봐도 깨지지 않게
- 내가 알려주지 않은 가격, 주소, 전화번호는 지어내지 말고 [확인 필요]라고 적어둬

마지막 줄을 눈여겨보세요. 지어내지 말라고만 하면 Claude는 빈칸을 두기 어려워합니다. 대신 표시를 하라고 하면 검토할 때 그 표시만 찾으면 됩니다.

3. 브리프 예시

위 네 줄을 합치면 아래와 같은 한 문단이 됩니다.

나는 제주에서 감귤 농장을 하는 사람이야. 개발은 전혀 몰라. 지인들에게 카카오톡으로 링크를 보내 감귤 주문을 받는 페이지를 만들고 싶어.

화면 구성:
- 맨 위에 농장 사진과 이름 '한라 감귤 농장'
- 그 아래 감귤 종류와 가격 3종류
- 주문하려면 이름, 연락처, 종류, 수량, 배송지를 적는 칸
- 맨 아래 농장 연락처

재료:
- 사진은 폴더의 photos 안에 있어
- 종류와 가격은 폴더의 가격.xlsx에 있어

조건:
- 회원가입, 로그인, 결제 없이. 주문은 접수만
- 파일은 index.html 하나로
- 폰에서 봐도 깨지지 않게
- 내가 알려주지 않은 정보는 지어내지 말고 [확인 필요]라고 적어둬
- 주문 내용을 어디에 저장할지는 네가 개발을 모르는 사람이 유지보수할 수 있는 가장 단순한 방법으로 골라서 제안하고, 만들기 전에 나한테 먼저 알려줘

마지막 줄이 이 책의 방식을 보여줍니다. 주문을 어디에 저장할지는 개발 지식이 필요한 결정입니다. 여러분이 정하지 않습니다. 대신 기준(가장 단순, 개발을 모르는 사람이 유지보수)을 주고, 만들기 전에 알려달라고 합니다. 그러면 Claude가 "구글 시트에 저장하는 방식을 제안합니다. 이유는..."이라고 답하고, 여러분은 그 이유를 읽고 '좋아, 진행해'라고 하면 됩니다. 모르는 것을 이해하는 순간이 여기서 생깁니다.

몇 가지 예시를 더 보겠습니다. 형식은 같고 내용만 다릅니다.

나는 동네 독서 모임을 운영하고 있어. 매달 모임 날짜와 이번 달 책을 알리고, 참석 여부를 받는 페이지가 필요해.

화면 구성:
- 모임 이름과 이번 달 책 표지, 제목, 저자
- 모임 날짜, 장소
- 참석 / 불참을 누르는 버튼과 이름 칸
- 지난 달 책 목록

재료:
- 책 표지와 지난 책 목록은 폴더의 books.md에 있어

조건:
- 파일은 index.html 하나로
- 참석 여부는 구글 폼으로 받을 거야. 폼 링크는 https://forms.gle/xxxx
- 색은 따뜻한 갈색 계열

나는 사내 총무 담당이야. 직원들이 비품을 신청하는 페이지가 필요해.

화면 구성:
- 신청자 이름, 부서, 비품 종류(드롭다운), 수량, 사유
- 신청하기 버튼
- 아래에 이번 달 신청 현황 표

조건:
- 신청 내용은 구글 시트에 쌓이게. 시트 연결 방법은 단계별로 설명서를 써줘
- 회사 로고는 폴더의 logo.png
- 색은 로고 색에 맞춰서
- 관리자 기능은 이번에는 없이

4. 브리프를 쓰기 전에 물어보기

브리프가 잘 안 써질 때가 있습니다. 무엇이 보여야 하는지조차 정리가 안 될 때입니다. 그럴 때는 채팅 탭에서 먼저 이야기합니다.

나는 감귤 농장을 하는데 지인 주문을 카카오톡 메시지로 받다 보니 정리가 안 돼. 주문 접수 페이지를 만들면 해결될 것 같은데, 개발은 전혀 몰라. 이 페이지에 무엇이 있어야 하는지 나한테 질문하면서 정리해줘. 정리가 끝나면 Code 탭에 붙여 넣을 요청문을 한 문단으로 써줘.

Claude가 "주문을 받으면 어떻게 확인하실 건가요?", "배송비는 어떻게 되나요?" 같은 질문을 합니다. 답하다 보면 자기가 무엇을 원하는지 정리됩니다. 마지막에 나온 한 문단을 복사해 Code 탭에 붙이면 됩니다. 3장 11절의 프로젝트에 이 대화를 묶어 두면 다음 버전을 만들 때 이어서 이야기할 수 있습니다.

5. 브리프에서 하지 않는 것

앞선 책의 명세서와 비교해 이 책의 브리프가 일부러 하지 않는 것을 정리합니다.

기술 스택을 지정하지 않는 것이 불안하다면 이렇게 생각해보세요. 지정할 만큼 알면 지정하고, 모르면 기준을 줍니다. "가장 단순하게", "개발을 모르는 사람이 유지보수할 수 있게", "파일 하나로"가 이 책에서 쓰는 기준입니다. 이 기준을 주면 Claude는 순수한 HTML, CSS, JavaScript를 고릅니다. 8장에서 본 그것입니다.