픽스다인 관리자 교육 · 3차
픽스다인 홈페이지 관리자 교육 · 3차 · 2026. 09. 14
요청 한 건이
화면에 닿기까지
9월 11일 문서의 1장이 어떤 길을 지나
9월 13일 새벽에 스테이징에 올라갔는지
9월 13일 새벽에 스테이징에 올라갔는지
김혜련 · 아르테랩 · 개발 리뷰 뒤 이어서
오늘 따라가는 한 건
9월 12일 밤 10시 45분에 시작해
새벽 0시 19분에 스테이징에 올라간 한 건입니다
내 요청은 어느 칸에서 코드가 되는가사람이 보는 자리는 어디인가안 보일 때 어느 화면을 여는가
아홉 칸입니다. 오늘 코드는 두 조각만 구경합니다.
3.1 · 요청 문서
출발점은
9월 11일 문서의 1장
구연재 주임님이 보내신 프로젝트 등록 문서, 1장 프로젝트 목록의 다섯 항목입니다.
번호→원문 그대로의 문구→두 갈래 검사
원문 · BO_개발 피드백_프로젝트 등록.md · 1장
항목마다 번호가 있고,
지울 문구가 원문 그대로 적혀 있습니다
### 1-2. 정렬 다음 항목은 별도의 정렬 기능 불필요 - 프로젝트명, 클라이언트, 서비스, 산업, 상태 ### 1-3. 목록 표시 개수 Show entries 기능 추가 - 10개, 20개, 50개 기본값은 10개로 설정 ### 1-4. 검색 단축키 - 검색창에 표시된 `⌘K` 단축키 안내 삭제 ### 1-5 필요 없는 문구 삭제 - 상단 `게시 상태는 바로 저장됩니다. 공개 홈페이지에 반영하려면 홈페이지 배포를 실행해야 합니다. …` 문구 삭제 - 하단 `98건 중 1–9 표시` 문구 삭제, Show entires로 대체
고치기 전 화면 · 8월 25일 캡처
지울 것 셋이
이 화면에
있습니다
검색창의 ⌘K, 표 아래 "23건 중 1-9 표시", 프로젝트명 헤더의 정렬 화살표. 고친 뒤 화면은 방금 리뷰에서 보셨습니다.
⌘K→N건 중 표시→헤더 정렬
1-1 · 필터
1-1은 두 갈래로 읽혀
오늘 리뷰 항목으로 뺐습니다
필터 항목은 최대 2개까지 중복 선택 가능하도록 수정
01산업 필터 안에서 둘(금융과 제조)을 고르는 것
02필터 종류 둘(산업 하나 + 상태 하나)을 겹치는 것
03리뷰에서 정한 것: ____________
2차에서 본 "한 줄이 두 갈래로 읽혀 개발이 멈춘 날"과 같은 자리입니다.
3.2 · 작업 목록과 지시문
코드보다 먼저,
지시문을 쓰게 합니다
문서를 받고 처음 한 일은 Claude에게 문서를 읽히고 작업 목록과 지시문을 쓰게 한 것입니다.
문서→작업 11개→지시문 한 장
제가 Claude에게 한 말 · 9/12 16:16 · 22:33
이 두 마디로 작업 목록과 지시문 한 장이 나왔습니다
Output작업지시 문서
16:16 저장 안했으면 저장하고 1번부터 작업할 수 있게 워크트리 따주고, 지시 프롬프트 작성해줘 22:33 정리해둔건 좋은데, 내가 말하면 1개씩 꺼내서 작업진행하자. (…) 워크트리 딴 거 전체 지시프롬프트 넣어야 되는 거 합쳐서 하나로 복사할 수 있게 다시 만들어줘
지시문을 쓰게 하는 요청입니다. 메타프롬프트라고 부르기도 합니다.
작업지시_260912_BO1차피드백_PR별.md · 앞 다섯 줄
23항목이 작업 11개로,
같은 파일을 만지는 것은 순서대로
| 작업 | 들어갈 것 | 크기 | 조건 |
|---|---|---|---|
| 1 목록 손질 | 정렬 제거 · 표시 개수 10/20/50 · ⌘K 삭제 · 안내 문구 삭제 | 0.5일 | 1-1 필터 중복 선택은 넣지 않음 |
| 2 저장 토스트 | "저장되었습니다." 공용 부품 | 0.25일 | 어워드 화면이 같은 부품을 쓴다 |
| 3 Goal 카드 | 순서 번호 · 설명 칸을 제목보다 길게 | 0.25일 | 3-2 드롭다운은 넣지 않음 |
| 4 상세 읽기 모드 | 행 클릭 → 잠근 화면 · '수정하기' → 수정 | 0.5-1일 | 별도 상세 화면을 만들지 않는다 |
| 5 이탈 경고 | "저장하지 않은 내용이 있습니다. …" | 0.5일 | 브라우저 닫기·목록으로·사이드바 셋만 |
2번부터 5번은 등록 화면 파일 하나를 건드려서 순서대로. "넣지 않음"이 표에 적혀 있습니다.
사람과 Claude의 몫
파일 이름과 줄 번호는 Claude가 찾고,
사람은 넷을 정합니다
AdminShell.tsx:158 같은 줄 번호는 Claude가 저장소를 뒤져 넣은 것입니다01무엇을 할지
02무엇은 안 할지
03어느 순서로 할지
04어디서 멈춰서 사람에게 보여 줄지
제가 코드를 읽지 않고도 개발을 시킬 수 있는 이유가 이 한 단계에 있습니다.
3.3 · 지시문 해부 · 공통 규칙 앞 다섯 줄
공통 규칙 열 줄은 작업 11개에 똑같이 붙습니다
- 이 폴더는 git 워크트리 pixdine-wt-bo-list 다. (…) main 에 직접 작업하지 않는다. push·PR 은 하지 않는다. 커밋은 내가 화면을 확인하고 "커밋해" 라고 할 때만 한다.- 커밋 메시지는 한국어 (…) 작성자 표기 줄은 넣지 않는다.- 요청 원문은 (…)프로젝트 등록.md 다. 시작할 때 한 번 읽는다. 원문에 없는 기능을 보태지 않는다. 원문과 내 지시가 다르면 멈추고 묻는다.- 서버(server/)와 DB(supabase/)는 손대지 않는다. 필요해 보이면 멈추고 말한다.- apps/bo 밖의 파일은 손대지 않는다. 특히 apps/fo 는 이 작업과 무관하다.
1줄다른 폴더에서 고치는 것을 막습니다
커밋해첫 번째 멈춤 자리
3줄여러분 문서가 최종 기준입니다
4·5줄울타리. 손대지 않을 곳
3.3 · 지시문 해부 · 공통 규칙 뒤 다섯 줄
뒤 다섯 줄은 문구·주석·확인·보고입니다
- 문구는 원문 그대로 쓴다. 새 문구가 필요하면 짧은 한국어 평상어로, 영어 라벨은 쓰지 않는다.- (…) 고친 자리에는 "왜"를 한 줄 주석으로 남긴다(요청 항목 번호 포함. 예: `// 9/11 피드백 1-2: …`).- dev 서버(3000)와 로컬 API(8080)는 내가 따로 띄워 둔다. 직접 띄우지 않는다. 안 떠 있으면 말한다.- 한 단계 끝날 때마다 http://localhost:3000/projects/ 를 다시 열어 확인하고, 다 됐다고 하기 전에 (…) `npm run build` 가 통과해야 한다.- 답은 존댓말 한국어. 결과 보고는 "무엇을 어디에 고쳤고, 요청과 아직 다른 점" 두 줄로.
6줄"Show entries" 같은 영어가 화면에 붙는 것을 막습니다
7줄석 달 뒤 "이건 왜 이렇게 돼 있지"를 막습니다
9줄말만 "됐습니다"를 막습니다
10줄안 한 것이 긴 보고 속에 묻히는 것을 막습니다
3.3 · 지시문 해부 · 작업 덩어리
작업 덩어리는 건마다 바뀝니다:
파일 · 번호 · 확인 · 커밋 단위
이 브랜치는 (…)projects/page.tsx, (…)AdminShell.tsx, (…)globals.css 세 파일만 고친다. 요청 원문의 1장 중 1-2·1-3·1-4·1-5 네 가지다. 1-1(…)은 이 브랜치에서 하지 않는다.1. 정렬 제거 (원문 1-2 · projects/page.tsx)2. 안내 문구 삭제 (원문 1-5 · projects/page.tsx)3. 표시 개수 (원문 1-3 · projects/page.tsx)4. ⌘K 안내 삭제 (원문 1-4 · AdminShell.tsx:158 · globals.css:157)5. 확인 - 정렬 안 되는 헤더에 커서·화살표가 없는지, (…) 처음 열면 10건인지, (…) 검색창에 ⌘K 가 없는지. - apps/bo 에서 `npm run build` 통과.커밋 단위: 커밋 1 = 1·2·4(지우는 것들) / 커밋 2 = 3(표시 개수). 각 커밋 전에 내가 화면을 본다.
파일세 개만. 울타리
번호항목마다 원문 번호
확인여러분 문서를 "됐다고 판정하는 문장"으로 다시 쓴 것
커밋 단위두 번째 멈춤 자리
지시문의 부품
지시문은 넷으로 되어 있습니다
01
울타리
×
무엇을 안 만지나. 서버·DB·apps/bo 밖
02
원문
1-2
무엇을 하나. 번호와 함께
03
멈춤 자리
2
커밋 전에 사람이 화면을 보는 자리 두 번
04
확인 목록
✓
무엇이 되면 됐다고 하나
2차의 스펙 한 장 다섯 칸이 화면을 만들 때의 부품이라면, 이 넷은 있는 화면을 고칠 때의 부품입니다.
3.4 · 워크트리
작업 하나에
폴더 하나
저장소를 작업 하나를 위해 따로 복사해 둔 폴더입니다. 같은 파일을 건드리는 작업은 앞 것을 합친 뒤에 다음 폴더를 땁니다.
폴더 따기→고치기→합치기→폴더 지우기
9/12 16:20 · 실제 명령 · 합치고 나면 폴더는 지운다
1번을 합친 뒤 2번 폴더를 땄고, 다섯 번 그렇게 했습니다
git worktree add ../pixdine-wt-bo-list -b feat/bo-project-list-cleanup origin/main
| 작업 | 폴더 | 합친 시각 |
|---|---|---|
| 1 목록 손질 | pixdine-wt-bo-list | 9/13 00:17 |
| 2 저장 토스트 | pixdine-wt-bo-toast | 9/13 01:36 |
| 3 Goal 카드 | pixdine-wt-bo-goal | 9/13 11:55 |
| 4 상세 읽기 모드 | pixdine-wt-bo-view | 9/13 23:33 |
| 5 미저장 이탈 경고 | pixdine-wt-bo-leave | 9/14 01:00 |
3.5 · 코딩 세션과 화면 확인
지시문을 붙이고
한 시간 동안 있었던 일
22:45에 붙여 넣고 23:52에 마지막 보고를 받았습니다. 그 사이 기록을 시각과 함께 봅니다.
읽기→고치기→보고→사람 확인
세션 기록 · 9/12 · 원문 그대로
세션은 울타리 안에서만 움직이고,
멈춤 자리마다 보고했습니다
| 시각 | 있었던 일 | 세션의 말 |
|---|---|---|
| 22:45 | 지시문 붙여 넣음 | "먼저 브랜치 확인과 요청 원문·대상 파일을 읽겠습니다." |
| 22:47 | 파악 끝 | "`.toggle-hint` CSS는 지시 범위 밖이라 손대지 않습니다." |
| 22:49 | 커밋 1 범위 보고, 멈춤 | 두 줄 보고 (다음 장) |
| 22:53 | 제가 "localhost가 안 열리는데?" | "규칙대로 제가 직접 띄우지 않고, 포트 상태만 확인하겠습니다." |
| 22:55 | 404 원인 찾음 | "지시서의 URL(`/projects/`)이 basePath를 빠뜨린 것" |
| 23:49 | 화면 확인 뒤 제가 "3번 진행해" | |
| 23:52 | 커밋 2 범위 보고 | "요청과 다른 점: 없습니다." |
붙여 넣은 시각부터 마지막 보고까지 1시간 7분. 화면 본 시간과 서버 헤맨 시간이 다 들어 있습니다.
22:49 · 커밋 1 범위 보고 · 원문
보고는 두 줄: 어디를 고쳤고,
요청과 아직 무엇이 다른가
커밋1 범위(1·2·4) 완료, `npm run build` 통과했습니다.
- 고친 곳: `apps/bo/src/app/projects/page.tsx`(정렬을 연도·등록일만 남기고 나머지 헤더의 sortable/화살표/클릭 제거·SortKey 2개로 축소·page-desc 문구 정정·상단 안내 블록과 IconInfo import 삭제·하단 "N건 중" 문구와 from/to 삭제), `AdminShell.tsx`(검색창 ⌘K 삭제), `globals.css`(안 쓰이게 된 `.topbar-search .kbd` 한 줄 삭제).
- 요청과 아직 다른 점: 표시 개수(1-3, 커밋2)는 아직 안 했습니다 — 지금 table-foot 왼쪽은 빈 자리이고 목록 개수는 서버 기본값 그대로입니다.
여기서 멈춥니다. 사람이 화면을 봐야 다음으로 갑니다.
22:55 · 세션이 찾은 원인 · 원문
지시문이 틀리면
밀어붙이지 않고 원인을 말합니다
원인 찾았습니다. BO는 `basePath: '/admin'`(next.config.mjs)이라 루트가 아니라 `/admin` 아래에서 열립니다. 지시서의 URL(`/projects/`)이 basePath를 빠뜨린 것이고, 실제 주소는 이렇습니다:
- 프로젝트 목록: http://localhost:3000/admin/projects/
확인 주소에 /admin이 빠져 있었습니다. 작업지시 문서를 고쳤고 2번부터는 이 일이 없었습니다.
코드 구경 1 · 1-4 ⌘K 안내 삭제 · AdminShell.tsx
요청 한 항목이 코드에서는 한 줄이었습니다
onKeyDown={(e) => e.key === 'Enter' && search.onSubmit?.()}
/>
- <span className="kbd">⌘K</span>
</div>
요청의 길이와 코드의 양은 비례하지 않습니다. 얼마나 걸릴지는 Claude가 저장소를 읽은 뒤에 나옵니다.
코드 구경 2 · 1-2 정렬 제거 · projects/page.tsx
여러분 문서의 번호가
코드 주석까지 따라갑니다
-type SortKey = 'name' | 'client' | 'year' | 'service' | 'industry' | 'status' | 'created_at';
+// 9/11 피드백 1-2: 정렬은 연도·등록일 두 헤더만. 나머지는 정렬 대상이 아니다.
+type SortKey = 'year' | 'created_at';
// 로 시작하는 줄은 프로그램이 아니라 사람이 읽으라고 남긴 주석입니다.
3.6 · 커밋 · PR · 검토 · 머지
저장하고, 요청서를 열고,
검토받고, 합칩니다
이 네 칸은 코딩 세션이 아니라 관리 세션이 합니다. 결정은 사람이 합니다.
커밋→PR→검토→머지
9/12 23:47 → 9/13 00:17
30분 안에 네 칸을 지났고,
결정은 한 마디였습니다
| 시각 | 칸 | 있었던 일 |
|---|---|---|
| 23:47 | 커밋 1 | 지우는 것 셋(1-2·1-4·1-5)을 한 묶음으로 저장 |
| 23:54 | 커밋 2 | 표시 개수(1-3)를 한 묶음으로 저장. 이어서 저장소에 올림 |
| 23:55 | 이슈 #83 | "이 일을 한다"는 카드를 GitHub에 등록 |
| 23:55 | PR #84 | "합쳐 달라"는 요청서를 열고 이슈 번호를 연결 |
| 00:10 | 검토 | codex가 검토 결과를 PR에 남김 |
| 00:16 | 결정 | 검토를 읽고 제가 한 말: "바로 머지해. codex 리뷰가 수정사항 없데." |
| 00:17 | 머지 | 본줄기에 합침. 이슈 #83이 자동으로 닫힘 |
커밋 이름에도 번호: feat(bo): 프로젝트 목록 표시 개수 10·20·50 (9/11 피드백 1-3)
PR #84 본문 · 발췌
PR 본문에 '하지 않은 것' 칸이 따로 있습니다
Closes #83## 무엇을 했나9/11 구연재 주임 BO 1차 피드백(…) 1장 중 1-2·1-3·1-4·1-5.- 1-2 정렬 정리 · 연도·등록일 헤더만 클릭해서 정렬한다. (…)- 1-4 ⌘K 삭제 · 상단 검색창의 ⌘K 배지와 (…) 스타일을 지웠다.## 하지 않은 것- 1-1 필터 최대 2개 중복 선택은 뜻을 9/14 리뷰에서 확인한 뒤 따로 한다.- 서버는 손대지 않았다.## 확인- 로컬 BO에서 눈으로 확인: (…) 처음 열면 10건, (…) 검색창 ⌘K 없음.- `cd apps/bo && npm run build` 통과.
Closes #83합쳐지는 순간 이슈가 저절로 닫힙니다
하지 않은 것지시문의 "안 함"이 여기까지 따라옵니다
확인지시문 5번 확인 목록과 같은 문장
검토 · codex (OpenAI가 만든 코드 검토 도구) · 00:10 · 원문
검토는 참고입니다.
따르지 않을 때는 이유를 코드에 남깁니다
리뷰 완료했습니다.
- 목록 정렬 대상 축소와 표시 개수(10·20·50) 변경이 API 요청 및 페이지 수 계산에 일관되게 반영됐습니다.
- `apps/bo`: `npm run build` 통과
- `server`: `go test ./...` 통과
차단할 이슈는 발견하지 못했습니다.
9/9 이미지 생성 PR: "10분 6회 제한이 재시작되면 풀린다"는 지적. 서버가 한 대라 해당 없음. 이유 세 줄을 주석에 남기고 합쳤습니다.
아홉 칸 중
사람이 판단하는 자리는 셋,
요청 · 화면 확인 · 합치기
요청을 쓴 자리는 구연재 주임님, 화면을 본 자리는 커밋 전 두 번, 합치기로 한 자리는 검토를 읽은 뒤. 나머지 여섯 칸은 Claude와 도구가 합니다.
3.7 · 자동 배포
합치면
2분 뒤에 올라갑니다
머지 직후 아무도 손대지 않았는데 스테이징 홈페이지가 바뀌었습니다. GitHub Actions가 한 일입니다.
머지→빌드→스테이징
.github/workflows/deploy-fo.yml · 앞부분
본줄기에 합쳐지고 apps/fo·apps/bo가 바뀌면
저절로 돕니다
name: Deploy Site to Staging (FO + BO /admin)
on:
push:
branches: [main]
paths:
- 'apps/fo/**'
- 'apps/bo/**'
- '.github/workflows/deploy-fo.yml'
workflow_dispatch: ← 사람이 버튼으로 직접 돌릴 수도 있다
저장소 안에 "이런 일이 생기면 이렇게 해라"를 적어 둔 파일이고, GitHub가 그대로 실행합니다.
실행 #84 · 00:17:12 → 00:19:15
설치하고, 만들고, 합치고, 올립니다. 2분 3초
01
재료 설치
02
홈페이지 빌드
03
백오피스 빌드
04
/admin 아래로 합침
05
스테이징에 올림
마지막 단계 이름은
Deploy to Cloudflare Pages — STAGING preview. 지금은 여기까지만 갑니다.오픈 때 바뀌는 것은 마지막 단계 한 곳. 스테이징 표시를 손보면 같은 흐름이 실제 주소로 갑니다.
deploy-fo · 실행 기록
다섯 번 다 2분 안팎이었습니다
| 합친 것 | 배포 시작 | 끝 |
|---|---|---|
| #84 목록 손질 | 9/13 00:17:12 | 00:19:15 |
| #86 저장 토스트 | 9/13 01:37:38 | 01:39:18 |
| #88 Goal 카드 | 9/13 11:55:38 | 11:57:42 |
| #90 상세 읽기 모드 | 9/13 23:33:05 | 23:34:54 |
| #92 미저장 이탈 경고 | 9/14 01:00:35 | 01:02:40 |
오픈 뒤에는 백오피스나 홈페이지 코드가 고쳐져 합쳐질 때마다 2분 뒤 실제 홈페이지가 바뀝니다.
오픈 뒤 · 안 보일 때
고쳐졌다는데 홈페이지에 안 보이면
Actions 탭부터 봅니다
GitHub 저장소 → Actions 탭 → 마지막 실행
01초록 체크: 올라간 것
02빨간 표시: 안 올라간 것
03초록이고 끝난 지 몇 분 지났는데도 안 보이면 그때 연락
게시 상태만 바꾼 경우는 코드가 안 바뀌어 여기에 안 걸립니다. 그 경우도 자동으로 올라가게 하는 것은 따로 붙입니다.
3.8 · 같은 길을 네 번 더
지시문이 부족했던 자리 둘:
빠진 것은 화면에서, 넘친 것은 커밋 전에 걸렸습니다
| 작업 | 무엇이 | 어디서 걸렸나 | 그다음 |
|---|---|---|---|
| 3 Goal 카드 | 대외비 폼 파일이 지시문에 없었다 | 화면 확인에서 대외비 폼이 안 바뀐 것을 봄 | 파일을 추가해 같은 커밋에 |
| 4 읽기 모드 | 지시에 없는 변경(게시 가능 조건)이 섞였다 | 관리 세션이 커밋 전 대조에서 골라냄 | 저에게 물은 뒤 따로 커밋 |
울타리는 좁게. 빠진 것은 화면에서 보이지만, 세션이 시키지 않은 곳까지 고친 것은 화면만 봐서는 모릅니다.
3.9 · 실습 · 20분
요청 항목 하나를 써서
지시문이 나오는 것까지
Output지시문 한 장
아래 요청 항목을 읽고, 코딩 세션에 그대로 붙여 넣을 지시문 한 장을 써 줘.- 공통 규칙은 작업지시_260912_BO1차피드백_PR별.md 의 공통 규칙 열 줄을 그대로 쓴다.- 작업 덩어리에는 손대는 파일 이름, 원문 항목 번호, 안 하는 것, 확인 목록, 커밋 단위를 넣는다.- 원문에 없는 것을 보태지 않는다. 두 갈래로 읽히는 줄이 있으면 지시문을 쓰지 말고 먼저 물어봐.- 저장소를 읽고 얼마나 걸릴지(0.25일 단위)와 다른 작업과 겹치는 파일이 있는지 같이 적어.
5분리뷰에서 정한 것 하나 고르기. 추천: 여러 건 삭제의 확인 절차
7분종이에 쓰기: 번호 · 화면 · 지금 · 바라는 것 · 안 할 것 · 판정 문장
5분제가 Claude에 붙입니다. 지시문이 나오는 것을 같이 봅니다
3분나온 지시문에서 부품 넷 찾기
종이에 "적절히·자연스럽게·깔끔하게"가 있으면 지웁니다. 그대로 두면 세션이 알아서 정합니다.
오픈 뒤 요청 · 여섯 줄
2차의 네 줄에 오늘 두 줄을 더합니다
번호 : 어느 화면 : 지금 어떻게 나오나 : 어떻게 나와야 하나 : 이번에 안 해도 되는 것 : 언제까지, 그때까지 답이 없으면 어떻게 :
번호는 코드 주석까지 따라가고, 안 해도 되는 것은 지시문의 울타리가 됩니다.
Checklist
나가실 때 이 여섯 가지에 답할 수 있어야 합니다
아홉 칸을 순서대로 말할 수 있다그림
사람이 판단하는 세 자리가 어디인지 안다3.6
지시문의 부품 넷을 안다3.3
요청에 번호를 붙이고 문구를 원문 그대로 적는 이유를 안다3.1
1-1이 이번에 빠진 이유를 안다3.1
안 보일 때 어느 탭을 먼저 여는지 안다3.7
하나씩 눌러 지워 갑니다.
외울 문장 · 다음 자리
요청에 번호와 원문이 있으면,
뒤의 여덟 칸은 되묻지 않습니다
외울 문장 둘
지시문은 무엇을 안 할지와 어디서 멈출지로 완성됩니다
합쳐지면 2분 뒤에 올라갑니다. 안 보이면 Actions 탭부터 봅니다
4차 · 오픈 뒤
운영 한 달치 요청이 지나간 길
제안요청서 · 클라이언트 문서에 같은 방식 적용
오늘 리뷰에서 정한 것
이슈 한 장 → 지시문 한 장
→ 폴더 하나 → 합치기 → 2분
→ 폴더 하나 → 합치기 → 2분
픽스다인 홈페이지 관리자 교육 · 3차
요청 한 건이
화면에 닿기까지
아홉 칸. 사람이 판단하는 칸은 셋.
오픈 뒤 요청은 여섯 줄로 주십시오.