앞서 URL 설계와 DB 설계를 Claude에게 시켜 받아 보는 방법을 살펴봤습니다. 그런데 그보다 앞서 결정할 것이 있습니다. 백엔드가 정말 필요한가입니다. 이 장의 첫 절에서 백엔드는 만드는 것보다 운영이 무겁다고 했습니다. 이번 절은 백엔드를 만들지 말지 정하는 질문 세 개와, 만들기로 했을 때 Claude에게 건네는 한 문단을 다룹니다. 긴 명세서는 쓰지 않습니다.

1. 백엔드가 필요한지 정하는 질문 세 개

만들고 싶은 것을 떠올리고 아래 세 질문에 예, 아니오로 답해 보세요.

1. 데이터를 저장해야 하나: 방문자가 입력한 것이 다음에 다시 열었을 때 남아 있어야 하나요. 방명록, 주문, 신청서는 예입니다. 가게 소개 페이지, 포트폴리오, 계산기는 아니오입니다.
2. 여러 사람이 같은 데이터를 봐야 하나: 내가 저장한 것을 다른 사람 화면에서도 봐야 하나요. 게시판은 예입니다. 나만 쓰는 메모장은 아니오입니다.
3. 로그인이 필요한가: 누가 누구인지 구분해야 하나요. 내 주문 내역만 보이게 하려면 예입니다. 누구나 같은 화면을 보면 아니오입니다.

2장에서 본 4단계 사다리를 떠올리시면 됩니다. 세 질문에 모두 아니오라면 1단계, 첫 질문만 예라면 2단계, 두 번째까지 예라면 3단계, 셋 다 예라면 4단계입니다. 4단계에 오기 전까지는 백엔드 없이 갈 수 있습니다. 5장에서 구글 시트로 방명록을 받았던 방법이 3단계입니다.

세 번째 질문에서 멈칫하셨다면 한 번 더 생각해 보세요. 로그인이 정말 필요한지, 아니면 관리자인 나만 로그인하면 되는지입니다. 손님은 로그인 없이 주문하고 나만 관리자 페이지에서 확인한다면, Django의 관리자 페이지만으로 충분해서 회원가입 기능을 통째로 뺄 수 있습니다. 기능 하나가 빠지면 검토할 것도 그만큼 줄어듭니다.

2. 한 문단 브리프

백엔드가 필요하다고 판단했다면 Code 탭에 건넬 문장을 씁니다. 10장에서 자세히 다루는 방식과 같습니다. 네 가지만 적으면 됩니다.

• 누가: 이 서비스를 쓰는 사람
• 무엇을: 그 사람이 하는 일
• 저장할 것: 남겨야 하는 데이터
• 안 해도 되는 것: 이번에는 만들지 않는 기능

여기에 이 장에서 정한 기술 한 줄을 덧붙입니다. "Python과 Django로, 관리자 페이지를 쓰고, 순수한 HTML과 CSS로 화면을 만들어줘"입니다. 이 한 줄이 없으면 Claude는 자기 판단으로 기술을 고릅니다.

2.1 감귤 주문 접수

제주에서 감귤 농사를 짓는 우리 집 주문 접수 페이지를 만들어줘.

- 누가: 지인과 단골 손님. 로그인 없이 주문해.
- 무엇을: 감귤 5kg, 10kg 중 골라 수량을 정하고 이름, 전화번호, 주소를 적어 주문해.
- 저장할 것: 주문마다 상품, 수량, 이름, 전화번호, 주소, 주문 시각. 나는 관리자 페이지에서 주문 목록을 보고 '발송 완료' 표시를 할 수 있어야 해.
- 안 해도 되는 것: 결제, 회원가입, 재고 관리. 입금은 계좌로 따로 받아.

Python과 Django로, 관리자 페이지를 쓰고, 화면은 순수한 HTML과 CSS로 만들어줘.

이 서비스는 세 번째 질문이 '나만 로그인'이라 회원가입이 빠졌습니다. 손님용 화면은 주문 폼 하나와 완료 안내 하나, 두 장이면 끝입니다.

2.2 동아리 출석부

대학 독서 동아리 출석부를 만들어줘.

- 누가: 회원 20명과 회장인 나.
- 무엇을: 회원은 모임 날 자기 이름을 눌러 출석해. 회장은 모임 날짜를 만들고 출석 현황을 봐.
- 저장할 것: 회원 이름, 모임 날짜, 누가 어느 모임에 출석했는지.
- 안 해도 되는 것: 회원별 로그인. 이름을 누르는 것으로 충분해. 회장만 관리자 페이지에 로그인해.

Python과 Django로, 관리자 페이지를 쓰고, 화면은 순수한 HTML과 CSS로 만들어줘.

'누가 어느 모임에 출석했는지'는 앞 절에서 본 다대다 관계입니다. 여러분이 그 용어를 쓸 필요는 없습니다. 이렇게 말로 적어 두면 Claude가 알아서 중간 테이블을 만듭니다.

2.3 사내 비품 신청

우리 팀 비품 신청 페이지를 만들어줘.

- 누가: 팀원 12명. 각자 자기 이름으로 로그인해.
- 무엇을: 필요한 비품 이름과 수량, 사유를 적어 신청해. 자기가 신청한 목록과 처리 상태를 볼 수 있어.
- 저장할 것: 신청자, 비품 이름, 수량, 사유, 신청 시각, 상태(대기·승인·구매 완료).
- 안 해도 되는 것: 예산 계산, 구매처 관리, 알림 메일.

Python과 Django로, 관리자 페이지를 쓰고, 화면은 순수한 HTML과 CSS로 만들어줘.

이 서비스는 '자기가 신청한 목록'을 봐야 하므로 세 번째 질문이 예입니다. 그래서 로그인이 들어갑니다. 대신 Django가 로그인을 기본으로 제공하니 여러분이 따로 걱정할 것은 없습니다.

3. 만들기 전에 한 번 물어보기

브리프를 보내기 전에 한 번 더 하는 습관이 있습니다. 바로 만들어 달라고 하지 않고 먼저 물어보는 것입니다. 2장에서 게시판은 Flask로, 로그인은 FastAPI로 만들어졌던 부트캠프 사례를 떠올려 보세요. 처음에 이 질문 하나를 했다면 생기지 않았을 일입니다.

아래 서비스를 만들기 전에 먼저 물어볼게.

[위의 브리프 붙여넣기]

나는 개발을 전혀 모르는 사람이고, 이 서비스를 앞으로 내가 직접 유지보수해야 해.
개발을 전혀 모르는 사람이 유지보수할 수 있는 가장 단순한 기술을 골라 이유와 함께 제안해줘.
그리고 내 브리프에서 빠졌거나 애매해서 네가 마음대로 정하게 될 부분이 있으면 질문해줘.
아직 코드는 만들지 마.

Claude는 보통 두 가지를 돌려줍니다. 하나는 기술 제안입니다. 이 책대로라면 Django와 SQLite를 제안할 것이고, 다른 것을 제안하면 이유를 읽어 보고 납득이 가는지 판단하면 됩니다. 다른 하나는 질문 목록입니다. "주문 취소는 어떻게 하나요", "출석 마감 시간이 있나요" 같은 것들입니다. 이 질문에 답하는 과정이 여러분이 미처 생각하지 못한 부분을 채우는 과정입니다. 답이 준비되면 그때 "좋아, 이대로 만들어줘"라고 합니다.

4. 만든 뒤에 할 일

"이대로 만들어줘"를 보내면 Claude가 폴더에 프로젝트를 만들고, 필요한 것을 설치하고, 서버를 켜서 접속 주소를 알려 줍니다. 여기서부터는 프론트엔드와 다르지 않습니다. 주소를 열고, 눌러 보고, 이상한 곳을 콕 집어 말하는 루프입니다.

백엔드가 있는 서비스라 확인할 것이 두 가지 더 있습니다. 관리자 페이지에 들어가서 데이터가 실제로 저장되는지 보는 것, 그리고 잘못된 입력을 넣어 보는 것입니다. 전화번호 칸에 글자를 넣거나 수량에 0을 넣어 보세요. 이런 검토 방법은 10장에서 하나씩 다룹니다.

설계 문서는 만든 뒤에 남깁니다. 앞 절들에서 URL 표와 ERD를 미리 받아 보는 방법을 설명했지만, 브리프 한 문단으로 바로 만들었다면 그 문서가 없을 것입니다. 그럴 때는 완성된 뒤에 시키면 됩니다.

지금 만든 프로젝트의 URL 목록과 데이터베이스 구조를 표와 Mermaid ERD로 정리해서 설계.md로 저장해줘.

이렇게 나온 문서가 다음에 기능을 추가할 때 붙여 넣을 재료가 됩니다. 만들기 전에 쓰는 명세가 아니라 만든 뒤에 남기는 명세, 10장에서 역방향 명세라고 부르는 방식입니다.