Retrospective Week1

회고 · Week 1

기간: 2026-05-25 ~ 2026-05-31

이번 주는 코드를 안 짰다. 부트캠프 1주차 요구가 "기능을 서두르지 말고 기획과 워크플로우를 만들라"였고, 평소대로면 pnpm create next-app 부터 쳤을 텐데 한 주를 통째로 결정에만 쓴 게 어떤 차이를 만드는지 보려고 했다. 결과적으로는 — 결정의 절반 이상을 한 번 뒤집었고, 그게 코드를 짜기 전이라 다행이었다.

---

기획이 어떻게 바뀌었나

처음 wiki에 적은 시나리오는 "운영진이 매주 운동 후 부원들의 기록을 일괄 입력" 이었다. 그게 가장 단순해 보였고, 인증도 운영진만 있으면 끝나는 모양이었다.

이 모델을 끝까지 고집했으면 다음 두 가지가 깨졌을 것이다.

1. 부원 본인의 기록이 누락된다. 운영진이 받아 적는 동안 누구는 페이스를 까먹고, 누구는 거리를 정확히 모른다. "어차피 운영진이 받아 적을 텐데" 라는 마찰이 매주 쌓인다.
2. 개인 통계가 정확하지 않다. 본인이 적은 기록이 아니라면 누적 거리·페이스 추이가 본인 데이터로 신뢰되기 어렵다.

GJC와 인증 옵션을 정리하다 부원이 본인 행을 직접 적는 흐름이 자연스럽지 않냐는 결론에 다다랐고, 사용자(나) 입장에서 봐도 그 쪽이 게시글-댓글 모델로 깨끗하게 정리됐다. 호스트가 그날의 페이지를 만들고, 참여자는 그 페이지에 본인 행만 추가 — 권한 매트릭스도, 데이터 모델도 한 번에 단순해졌다. 이걸 처음에 못 보고 "운영진 일괄"로 잡은 게 1주차 가장 큰 가설 오류였다.

연결해서 인증 모델도 바뀌었다.

• 매직링크(Resend 무료 티어) → 이메일 발송 SaaS가 끼는 게 자체 서버 방향과 안 맞았고,
• 단일 비밀번호(운영진만) → 참여자가 본인 행을 적는 모델과 안 맞았다.
• 최종: SNU 구글 OAuth + @snu.ac.kr 도메인 강제 + 화이트리스트(관리자 승인). 부원이 이미 가진 계정 그대로 쓰고, 이메일 발송 의존이 0이 된다.

---

기술 스택이 어떻게 자리잡았나

N100 서버를 구매하면서 한 번의 큰 결정이 도미노로 나머지 결정을 끌고 갔다.

도미노 0 — 자체 서버. Vercel/Supabase 무료 티어 한도 신경을 안 써도 되고, 동아리 사진/페이스 기록이 외부 사업자에 안 나간다. 부트캠프 종료 후에도 운영 가능한 형태라는 점이 결정적이었다. 대가는 SPOF, 가정 회선의 업로드 속도, 인증서·포트포워딩 운영 부담. 받아들이기로 했다.

도미노 1 — DB. Postgres 컨테이너를 쓰자니 동아리 30명 규모에 명백히 과한 도구였다. SQLite 파일 1개로 결정 — 백업이 cp 한 번이라는 것 자체가 단일 운영자한테 큰 가치였다.

도미노 2 — 인증. 자체 호스팅이라 Supabase Auth는 자연스럽게 빠졌고, Auth.js v5 + Google OAuth로 안착. 위에 적었듯 매직링크 → 단일 비번 → OAuth로 두 번 갈아탔다.

도미노 3 — 사진 저장. Supabase Storage 대신 로컬 볼륨. 한참 클라이언트 리사이즈(1600px)를 넣을지 고민했는데, N100 디스크 여유와 next/image의 자동 webp 캐싱을 따져보니 원본을 그대로 보존하는 게 맞다는 결론이었다. 사진 품질에 대한 책임을 코드에서 빼고 사용자한테 돌려주는 결정이다.

도미노 4 — 리버스 프록시. Caddy / Nginx / Traefik 비교는 길게 했는데 결국 "Caddyfile 10줄로 자동 HTTPS"가 솔로 운영에 압도적. Nginx는 certbot + cron + reload 훅을 따로 운영해야 하고, Traefik의 컨테이너 자동 감지는 서비스 1~2개에 과했다.

도미노 5 — 프레임워크. Vite + Hono 같은 SPA 조합으로 갈지 고민했는데, 카톡 공유 OG 이미지(opengraph-image.tsx)와 단체사진 갤러리(next/image)와 호스트 폼(Server Action) — 세 가지가 모두 Next.js에 기울어 있는 도메인이라 Next 유지. 자체 호스팅은 output: 'standalone'으로 단일 Node 프로세스 모드면 Vercel 없이도 충분하다는 걸 확인했다.

대가로 학습 측면에서 "FE/BE 경계를 직접 설계해 보는 경험"은 다음 프로젝트로 미뤘다.

---

워크플로우 측면에서 배운 것

처음 06-Checkpoints에 적었던 항목들 — "375px 가로 스크롤 없음", "label htmlFor 연결됨", "next/image 사용" — 이런 건 CI와 lint가 잡아야 할 일이지 사람이 회의처럼 매번 자문할 일이 아니라는 걸 도중에 알았다. 사람만 잡을 수 있는 건 다른 결인데, "AI가 내 지시를 잘못 해석한 부분을 잡는 가이드라인" 이 더 맞다는 방향으로 06을 재작성했다. 7개로 줄였다. 이게 1주차에 가장 큰 워크플로우 측면 학습.

다른 워크플로우 정리:

• Spec → Plan → Implement 3단계가 모두 끝나야 코드 변경이 시작된다. Plan 단계에서 Agent에게 "표만 그리고 코드는 만들지 마라"고 시키는 패턴이 한 번도 손해를 끼치지 않았다.
• Agent에게 위임 금지 항목을 명시: migration 적용, main 머지, env 변경, 외부 서비스 콘솔. 적어두지 않으면 알아서 했을 일들이다.
• .gjc/skills/murun-feature/SKILL.md 1개로 매 프롬프트마다 동일 컨텍스트를 다시 붙여넣지 않게 됐다.

자잘하게 발견한 것도 있었다. docs/wiki/Home.md에 다른 wiki 페이지를 (./01-Project-Plan.md)로 박았는데, GitHub Wiki는 URL이 /wiki/01-Project-Plan (확장자 없음)이라 전부 404가 됐다. 확장자를 빼고 절대 URL을 섞어 쓰는 방식으로 정리했고, repo 내 README의 docs/wiki/*.md 링크는 그대로 둬도 됐다 — 두 surface가 링크 규칙이 다르다는 걸 처음 알았다.

---

1주차 끝 시점의 산출물

• 기획서 / 기술 스택 / 화면 흐름 / Agent 워크플로우 / 프롬프트 패턴 / Checkpoints / 회고 — wiki 7개
• GitHub issue 15건 (Week 1~3 task)
• README + 이슈/PR 템플릿 + .gitattributes
• .gjc/skills/murun-feature/SKILL.md agent skill 초안
• dev 브랜치로 모든 변경 통합

---

2주차에 들고 가는 것

기획·워크플로우는 코드 없이 정리했고, 다음 주는 결정한 것을 실제로 끼워 맞추는 주차다.

1. N100에 Docker + Caddy + Next.js standalone 컨테이너 셋업
2. Auth.js v5 + Google OAuth + 화이트리스트 가입 흐름
3. 호스트 = 세션 생성, 참여자 = 본인 행 입력의 vertical slice 1개를 staging에 띄움
4. 매 feature 시작 전 .gjc/specs/<feature>.md 부터 — 1주차에 정한 규칙을 지키는지가 2주차의 진짜 시험
5. 06-Checkpoints 7개를 PR마다 자문 — 첫 번째 PR에서 어색하면 그 자리에서 수정

기획 결정이 한 번 더 뒤집힐 가능성도 인정한다. 권한 매트릭스가 실제 호스트/참여자 흐름을 막아버리거나, OAuth 콜백 도메인 등록이 늦어서 로컬 인증만 동작하는 채로 한 주가 가거나. 그래도 이번 주에 한 번 뒤집어 본 경험으로, 다음 번에 뒤집을 때 더 빨리 결정할 수 있을 거라 본다.

---

다르게 한다면 (2주차에서 바꾸는 것)

1주차의 결정/습관 중 다음은 의식적으로 바꿔본다.

1. 결정을 코드 짜기 전에 한 번 더 의심하기. 1주차에 인증 모델을 매직링크 → 단일 비번 → Google OAuth로 두 번 갈아탔는데, 그게 코드가 없을 때라 비용이 0이었다. 2주차엔 spec 작성 직후 "이 결정 한 번 더 뒤집을 여지가 있나"를 명시적으로 30초 생각하고 들어간다. 코드 작성 후 뒤집는 비용이 훨씬 크다.
2. spec/plan 강제를 첫 PR부터 적용. 1주차엔 룰만 적었지 적용 대상 코드가 없어서 검증을 못 했다. 2주차 첫 feature에서 .gjc/specs/ 없이 시작하면 그 자리에서 멈추고 spec 먼저 쓴다. 룰 어긴 채 진행하면 나머지 주차도 무너진다.
3. 결정 시점에 issue 즉시 갱신. 1주차엔 결정이 바뀔 때마다 issue가 outdated 됐고, 끝에 update-issues.sh 짜는 비용이 발생했다. 2주차엔 결정 직후 issue도 같은 PR에 수정.
4. Wiki ↔ repo sync 자동화. 매번 docs/wiki/* 를 수동 복사하는 동선이 번거롭다. 2주차 인프라 작업에 dev push → wiki repo 자동 sync 워크플로우 1개 추가.
5. PR 본문에 06-Checkpoints 7개를 진짜로 자문. 1주차엔 박아두기만 했다. 첫 PR에서 체크리스트가 어색하면 그 자리에서 06을 다시 쓴다 — 문서 위해 룰을 지키는 게 아니라 룰이 PR을 더 낫게 만들 때만 가치가 있다.