배포 뒤 프로젝트 이어가기 | Follow-up & Context

Overview

배포 URL에서 Feedme가 동작하면 이번 사용자 결과는 완성됐습니다. 하지만 Lesson 3에서 follow-up으로 분리한 문제와 이번 작업을 위해 만든 Spec까지 같은 상태로 계속 쌓아 두면 다음 작업이 무엇을 믿어야 하는지 흐려집니다.

이번 Lesson에서는 배포 뒤 저장소에 남은 상태를 구분하고, 해결할 문제와 정리할 맥락을 각각 맞는 경로로 넘깁니다.

학습 목표

• 근거가 남은 문제와 배포가 끝난 작업 맥락을 구분합니다.
• 남은 상태에 맞춰 resolve-follow-ups와 maintain-project-context를 사용합니다.

배포 뒤 남은 상태 구분하기

Lesson 3에서 현재 결과를 막지 않지만 실제 근거가 있는 문제는 docs/follow-ups/에 남겼습니다. follow-up은 막연한 TODO가 아니라 이번 결과와 분리해 다시 확인할 열린 문제 기록입니다. 이제 각 기록을 해결할 수 있는지, 결정이나 근거가 더 필요한지 판단합니다.

두 Skill은 배포 뒤 반드시 차례로 실행하는 단계가 아닙니다. 현재 저장소에 무엇이 남았는지에 따라 필요한 경로만 고릅니다.

docs/follow-ups/의 문제를 실제로 확인했고 의도한 동작도 이미 정해졌다면 별도 수정으로 이어갈 수 있습니다. 반대로 어떤 동작이 맞는지 결정해야 한다면 코드를 고치지 않고 shape-idea로 돌아갑니다.

배포가 확인된 spec.md는 현재 동작을 계속 지시하는 문서가 아닙니다. 다음 작업에서도 재사용할 결정만 프로젝트 결정 문서에 남기고, 완료된 작업 기록은 Git에서 확인할 수 있게 정리합니다.

resolve-follow-ups: 남은 문제를 별도 PR로 해결하기

resolve-follow-ups는 docs/follow-ups/*.md에 기록된 문제를 먼저 재현합니다. 아직 기록되지 않은 문제를 추측해 만들거나 제품의 의도까지 정하지 않습니다.

실행하면 먼저 기록된 방법으로 증상을 재현합니다. 재현되고 의도한 동작이 이미 정해진 문제만 수정과 검증을 거쳐 항목별 ready-for-review PR로 올립니다. PR은 자동으로 merge하지 않습니다.

증상이 재현되지 않거나 제품 결정이 더 필요하거나 검증 환경을 갖출 수 없다면 follow-up을 지우지 않습니다. 대신 재시도에 필요한 근거나 shape-idea에서 정할 선택을 결과로 돌려줍니다.

maintain-project-context: 완료된 작업 맥락 정리하기

maintain-project-context는 새로운 서비스 방향이나 결정을 만들지 않습니다. 이미 확정된 의미를 유지하면서 PRODUCT.md, GLOSSARY.md, 결정 문서, Spec과 프로젝트 지침 사이의 중복과 충돌을 정리합니다.

배포가 확인된 Spec에서는 다음 작업도 재사용할 결정부터 알맞은 결정 문서에 보존한 뒤 Spec 폴더를 지웁니다. 문서끼리 뜻이 다르거나 실제 배포 여부가 분명하지 않으면 어느 쪽이 맞는지 추측하지 않고 파일을 그대로 둔 채 사람에게 묻습니다.

[미션] Feedme 작업 닫기

Lesson 5에서 배포한 feedme-clone 저장소를 다음 작업이 시작할 수 있는 상태로 정리합니다.

Step 1: 배포 완료 확인하기

Lesson 5의 .vercel.app 주소에서 URL 변환과 결과 내보내기를 다시 실행합니다. docs/specs/<slug>/spec.md에 해당하는 변경이 이 주소에 배포됐는지 확인합니다.

Step 2: 실제 follow-up 확인하기

docs/follow-ups/에 .md 파일이 있는지 확인합니다. 파일이 있다면 각 항목의 증상, 근거, 추정 원인, 시도한 내용과 다음 단계를 읽고 다음 중 어디로 보낼지 이유와 함께 구분합니다.

• 증상을 재현할 방법과 의도한 동작이 정해져 있으면 resolve-follow-ups
• 올바른 동작을 결정해야 하면 shape-idea
• 필수 기록이 빠졌거나 지금 검증할 수 없으면 파일을 유지하고 필요한 근거부터 보완

resolve-follow-ups로 분류한 실제 항목이 있을 때만 다음 명령을 실행합니다.

/resolve-follow-ups

생긴 PR이나 남겨진 결과를 확인합니다. follow-up 파일이 없다면 “현재 별도 해결할 문제가 없다”고 판단하고, 연습을 위해 새 문제를 만들지 않은 채 이 Step을 건너뜁니다.

Step 3: 배포가 끝난 Spec 정리하기

Step 1에서 배포 완료를 확인한 상태로 다음 명령을 실행합니다.

/maintain-project-context

변경 내용을 확인합니다. 다음 작업에서도 사용할 결정이 docs/decisions/의 알맞은 문서에 남았는지, 새로운 의미를 임의로 만들지 않았는지, 배포된 Spec 폴더가 삭제됐는지 봅니다. 판단할 수 없는 충돌을 그대로 남기고 질문했다면 답을 정하기 전에는 파일을 더 고치지 않습니다.

Step 4: 정리 결과 반영하기

검토한 결과가 맞다면 Claude Code에 다음과 같이 요청합니다.

확인한 프로젝트 맥락 정리 결과를 커밋하고 main 브랜치에 push해줘.

GitHub에서 완료된 Spec 폴더가 사라지고 다음 작업에 필요한 현재 맥락만 남았는지 확인합니다. 삭제된 Spec의 내용과 변경 이력은 Git 기록에서 다시 확인할 수 있습니다.

핵심 포인트 정리

1. 상태에 맞는 경로: 근거와 의도한 동작이 있는 문제는 resolve-follow-ups, 제품 결정이 필요한 문제는 shape-idea, 배포 완료 Spec과 중복 맥락은 maintain-project-context로 보냅니다.
2. 독립된 문제 해결: follow-up은 먼저 재현하고 항목별 PR로 해결하며, 재현하거나 검증하지 못한 문제는 지우지 않습니다.
3. 완료된 맥락 정리: 배포 완료 Spec의 재사용할 결정은 보존하고 작업 폴더는 지워, 다음 대화가 현재 기준만 읽도록 만듭니다.

이어서 배울 내용

Feedme의 방향 정의부터 배포 뒤 정리까지 한 흐름으로 완주했습니다. 다음 개인 프로젝트 챕터에서는 같은 판단을 본인의 아이디어에 적용합니다.