내가 기획자와 일하는 방법
2026년 6월 30일뇌 빼기(중의적 의미)
들어가며
요즘 나는 개발 외적인 시간의 꽤 많은 부분을 "기획 다시 확인하기"에 쓰고 있었다. 이슈를 받아서 코드를 짜려고 보면, 정작 정해져 있어야 할 게 비어 있을 때가 있다. 그러면 구현을 멈추고 한 번 확인하고, 답이 오면 또 다른 빈칸이 보인다.
이걸 한동안 흐린 눈 하면서 사람 문제로 봤는데, 막상 들여다보니 그보다는 구조 문제에 가까웠다.
리스크가 가장 비싼 곳에서 발견된다
빈칸을 거르는 가장 싼 지점은 상류다. 문제 정의에서 한 번, 요구사항에서 한 번, 세부 기획에서 한 번. 그렇게 걸러지고 남은 것만 개발로 내려오는 게 이상적이다.
허나 지금 상황에서는 그 거름망이 자주 비어 있고, 빈칸을 처음 마주치는 사람이 제일 마지막 단계, 그러니까 코드를 짜는 사람이 되기 쉽다. 코드를 펼쳐야 "어 이거 안 정해졌네"가 보이니까. 결국 빈칸이 가장 비싼 지점에서 발견되는 셈이다.
여기 딸려오는 패턴이 하나 더 있다. 결정이 안 닫힌 채로 내려오면, 다음 단계 사람이 그 결정을 대신 내려주게 된다. 그게 한두 번이면 협업인데, 반복되면 결정의 책임이 자꾸 하류로 밀린다. 그리고 그렇게 메꿔 넣은 판단은 다음 문서에선 또 사라지기 쉽다. 사람 머리에만 남았으니까.
뇌를 밖으로 꺼내기
기획을 받았을 때 머릿속에서 도는 게 있다. (왜 내가?) 이거 진짜 문제 맞아? KPI 베이스라인은? 이 케이스 빠졌는데? 이건 기획에서 정할 일이지 구현에서 정할 일이 아닌데?
그래서 나의 기준을 밖으로 꺼내보기로 했다. "내가 산출물을 받았을 때 적용하는 기준"을 하나의 프록시로 만들어서, 개발로 넘어오기 전에 스스로 그 프록시랑 먼저 부딪히게 하는 거다. 통과한 것만 다음 단계로 간다. 빈칸을 거르는 지점을 상류로 옮기는 데에 의의를 뒀다.
제약을 하나 강하게 걸었다. 이 에이전트는 답을 주면 안 된다. 답을 주는 순간 결정을 에이전트가 대신 내려버려서, 그럴거면 기획자의 존재 의의가..? 그래서 얘는 질문과 옵션만 던지고 결정은 사람이 한다.
사용 환경은 Claude Code 데스크탑 앱으로 정했다. 비개발자(기획자/PM)가 써야 하니까 별도 봇 서버나 API 토큰 과금 없이, 터미널 없이 사용할 수 있는 방법 중에 가장 도입비용이 적었다. 거기에 skill과 harness를 얹는 형태다.
설계: 게이트 세 개와 산출물의 책임
뼈대는 게이트 세 개다.
| 게이트 | 막는 것 | 핵심 질문 |
|---|---|---|
| Gate 0 | 착수 자체 | 진짜 풀 문제인가, KPI 베이스라인은, 근본 해결인가 |
| Gate 1 | 명세 완성도 | 빈칸(TBD) 0개인가, 엣지 봤나, AC가 측정가능한가 |
| Gate 2 | 핸드오프 | SoT가 한 군데(Linear)인가, 추정, 의존성 있나 |
통과 못 하면 산출물을 만들어주지 않는다. 미통과 + 다음 질문 하나만 돌려준다. 이게 의외로 중요했는데, 안 그러면 어중간한 문서를 그냥 뱉어버리더라.
제일 도움이 된 개념은 산출물 altitude다. PRD, 요구사항, 세부기획이 자꾸 섞이길래, 문서마다 고도를 정하고 각 고도가 담아야 할 것(MUST)과 담으면 안 되는 것(MUST-NOT)을 못 박았다.
| 고도 | 문서 | MUST-NOT |
|---|---|---|
| WHY | PRD | 화면, 기능명세 |
| WHAT | 요구사항 | 화면 레이아웃, 카피, 픽셀 |
| 동작 | 세부기획 | 색/모션, 구현 알고리즘 |
| WHERE | 와이어프레임 | 비즈니스 정책 재정의 |
같은 결정은 한 altitude에만 존재하도록. KPI는 PRD가 소유하고 요구사항은 링크만 한다. 두 군데 적히면 정합성 관리를 또 해야한다.
AC(완료 정의)는 EARS + GIVEN/WHEN/THEN으로 강제했다. 자연스럽게 동작한다는 AC가 아니다.
WHEN 당일 첫 문항 풀이가 완료되면 THE SYSTEM SHALL streak을 +1 한다
GIVEN streak이 6일이고 어제 학습 안 함 / WHEN 오늘 첫 진입 / THEN 초기화 팝업 1회누가 봐도 통과/실패가 같게 떨어지는 문장. 이게 안 되면 미결로 본다.
구현: constitution 하나와 스킬 몇 개
플러그인 구조는 생각보다 단순하다. 핵심은 constitution.md라는 불가침 규칙 한 장이고, 모든 스킬이 동작 전에 이걸 먼저 읽는다. constitution과 개별 스킬이 충돌하면 constitution이 이긴다.
규칙은 이런 식이다.
- 답이 아니라 질문. 결정을 대신 내리지 마라.
- 모호함은 버그. TBD, "미정", "~할 수 있음"을 완료로 인정하지 마라.
- 칭찬은 아껴서. 분량으로 칭찬하지 마라.
스킬은 의도별로 쪼갰다. 진입(dispatcher) → 문제 심문(problem-gate) → 분해 코칭(spec-coach) → 기존 문서 린트(doc-lint) → 이슈화(linear-ops). 문서 골격은 처음엔 공통 템플릿 하나로 뭉쳤다가, 나중에 타입별(PRD/요구사항/세부기획)로 쪼갰다.
캘리브레이션
뼈대 만드는 건 며칠이면 된다. 진짜 시간은 튜닝에 들어갔다. 직접 기획자처럼 입력을 넣어보면서 계속 고쳤다.
1트 — 말투. 처음엔 얘가 자기 사고 과정을 그대로 토했다. "Gate 1을 통과하려면 6+1 렌즈로 봤을 때…" 이런 식. 쓰는 사람 입장에선 뭔 소린지도 모르고 끌려가는 느낌이다. 그래서 내부 용어(게이트, 렌즈, 고도)는 속으로만 쓰고, 화면엔 "왜 아직 안 되는지 짧게 + 다음 질문 하나"만 나오게 막았다.
2트 — 칭찬에 인색하기. 무난한 문서에도 "꼼꼼하네요"가 잘 나왔다. 칭찬이 기본값이면 기준이 내려간다. "정말 높은 기준 넘었을 때만, 한 일 자체를 구체적으로"로 바꿨다.
3트 — 범위가 자꾸 커진다. 기능 얘기는 자연히 커지는 경향이 있고, 양보되는 기능이 잘 안 나온다. 그래서 기능을 더하자는 얘기가 나오면 항상 두 개를 되묻게 했다.
- "왜 그 수준이어야 하나? 그 레퍼런스 앱은 그게 본업이라 그런 건데, 우리도 본업인가?"
- "더하는 만큼 뺄, 미룰, 안 할 건 뭔가?" (비목표가 비면 미결로 본다. 우선순위는 버린 걸로 증명된다.)
4트 — 템플릿이 안 쓰였다. 분명 템플릿을 만들어놨는데 잘 안 쓰였다. 까보니 두 가지였다. 하나는 스킬이 참조하던 템플릿 파일이 실제로는 없었다(죽은 참조). 다른 하나는 공통 템플릿 하나가 모든 문서를 커버하려다 보니 기준이 너무 약했다. 칸 이름만 있고 합격선이 없으니, 한 줄 대충 채워도 채워진 것처럼 보였다.
그러다 발견한 건데, 와이어프레임에까지 KPI 칸이 들어가 있었다. 화면 설계한테 KPI를 적으라는 셈이다. 다른 데선 막는 altitude 위반을 정작 템플릿이 저지르고 있던 거다. 그래서 공통 하나를 버리고 타입별로 쪼갰다. 각 문서가 자기 고도의 합격선을 직접 들고 있게. 공통 템플릿은 "그 외 문서"용으로만 남겼다.
Code Graph: 여러개의 프로덕트 레포를 한 장의 그래프로
마지막으로 붙인 게 code graph다. 영향 범위, 구현 가능 여부, 대략 공수 같은 질문에 답하려면, 코드를 관계로 볼 수 있어야 했다.
노드와 엣지는 이렇게 잡았다.
| 노드 | 엣지 |
|---|---|
| Screen , Component , API , Service , DB | renders , calls , handles , persists |
화면이 컴포넌트를 renders하고, 컴포넌트가 API를 calls하고, API가 서비스를 handles하고, 서비스가 테이블에 persists한다. 이걸 따라가면 "화면 하나 → 결국 어느 테이블까지" 경로가 한 줄로 나온다.
문제는 프론트랑 백이 레포도 다르고 언어도 다르다는 거였다. 그래서 두 그래프를 따로 만든 다음, OpenAPI 경계로 이어붙였다. 프론트의 calls 엣지가 가리키는 게 GET /submissions/{id} 같은 METHOD path이고, 백엔드 핸들러도 같은 METHOD path를 갖는다. 이 문자열을 조인 키로 써서 두 레포를 하나의 그래프로 합쳤다. 언어가 달라도 HTTP 경계는 공통이니까, 거기서 만나게 한 거다.
빌드는 정적 분석이다. 각 레포를 파싱해서 노드/엣지를 뽑고 graph.json 하나로 발행한다. v1에선 이걸 플러그인에 정적 파일로 동봉하고 스킬이 직접 읽게 했다(별도 서버 없이 제일 가벼운 형태). 신선도가 문제되면 다음 단계에서 CI에 붙여 머지 때마다 갱신하고, 더 가면 그래프 자체를 MCP로 띄우는 그림이다.
쓰임새는 기획 문서의 "영향 범위" 칸을 자동으로 채우는 거다. 어떤 기능을 건드린다고 하면, 그 화면에서 출발하는 경로를 따라 닿는 API, 서비스, 테이블을 펼쳐서 보여준다. 솔직히 큰 기대는 안 했는데 생각보다 잘 됐다. 공유 Submission 경로 하나를 건드리는데 서비스 17개, 테이블 20개로 퍼지는 fan-out 같은 걸 실제로 잡아냈다. 코드를 안 열고도 "이거 생각보다 큰 작업이다"가 나오는 거다.
그래서 잘 돌아가냐고요?
현재 게이미피케이션 관련 기획사항들 모두 개발 완료하는데 각 태스크별로 공수가 얼마나 들어?
게이미피케이션 관련 항목이 Linear에 어떻게 올라와 있는지부터 실제로 확인할게. code graph도 같이 본다.
Ran 1 shell command
Linear에서 게이미피케이션 관련 항목을 실제로 찾아볼게.
Called plugin:linear:linear 2 times
"게이미피케이션"이라는 단어로는 거의 안 잡혀. 실제 게임화 기능 단어들로 다시 찾을게.
Called plugin:linear:linear 4 times
"Gamifying" 프로젝트가 있네. 거기 항목 전체를 가져올게.
Called plugin:linear:linear, ran 2 shell commands
확인했어. "Gamifying" 프로젝트에 77개 항목이 올라와 있고, 게임화 기능들(연속학습 Streak·Special Streak·Streak 초기화·문제 풀이 피드백/보상·앱 진입 독려)이 들어 있어. 그걸 다 봤고, 코드 쪽도 대조했어.
결론부터 — 지금은 태스크별 공수를 내가 적어줄 단계가 아니야. 두 가지 때문이야.
1. 확정 공수는 개발이 매기는 숫자고, 지금 그 칸이 전부 비어 있어.
올라온 개발 티켓(BE 8건쯤 · FE 8~9건쯤)에 추정값이 하나도 안 들어가 있어. 아직 아무도 안 매긴 상태라, 내가 대신 채우면 근거 없이 지어낸 숫자가 돼.
2. 더 큰 문제 — 견적을 낼 수 있을 만큼 기획이 안 닫혔어.
이 기능들은 지금 앱(코드)에 아예 없는 신규 작업이야. 스트릭·문제풀이 피드백·진입 독려 전부 새로 만드는 거고. 그런데 정작 개발이 보고 견적 낼 화면이 비어 있어:
- 세부 화면설계서 4건이 아직 시작도 안 됨(Todo) — 연속학습 Streak / 문제 풀이 보상 / 홈 Streak / 진입 독려
- 요구사항·세부기획서는 In Review(검토 중, 확정 아님), PRD는 Canceled 상태
화면이 안 그려진 기능은 FE가 "이 화면 며칠"을 낼 수가 없어. 그래서 순서가 공수표가 먼저가 아니라, 견적이 가능한 상태를 만드는 게 먼저야. 굳이 지금 숫자를 뽑으면 스펙 바뀔 때마다 다시 뒤집힐 거고.
---
그래서 하나만 묻고 싶어:
이 기능들 중에, 화면이랑 동작까지 닫혀서 "이거 견적 좀 내봐" 하고 개발한테 바로 넘길 수 있는 게 하나라도 있어?
있으면 그것부터 개발 견적을 받아오면 되고(내가 영향 범위 정리는 도와줄게), 없으면 어느 걸 제일 먼저 닫을지 거기서부터 잡자.
✻ Brewed for 2m 37s
https://docs.google.com/spreadsheets/...
https://docs.google.com/spreadsheets/...
https://www.figma.com/design/...
https://docs.google.com/spreadsheets/...
기획은 다 나온 상태야. 이걸로 개발 공수 측정해줘.
기획 자료를 줬으니 실제로 열어볼게. 다만 한 가지 먼저 짚고 — 이 자료들 위치가 마음에 걸려서, 읽으면서 Linear랑 같이 대조한다. 우선 시트 접근부터.
Read 1 file, ran 1 shell command
시트가 열렸어. 첫 번째 시트(요구사항 정의서)부터 보이는 게 많네. 나머지 시트랑 Figma도 마저 보고 종합할게.
Read 1 file, ran 1 shell command
시트 3개 다 읽었고 Linear랑 대조했어. Figma도 실제로 뭐가 들어있는지 빠르게 확인할게.
Called plugin:figma:figma
Figma까지 봤어(와이어프레임 페이지 있고, 화면 라벨 요소 확인). 자료 다 열어서 Linear랑 맞춰봤는데 — 솔직하게 말할게. 지금 이걸로 공수를 매기면 며칠 안에 뒤집힐 숫자가 나와. 내가 까다롭게 구는 게 아니라, 자료 자체가 "아직 검토 중"이라고 말하고 있어.
왜 견적이 안 잡히는지 (항목별로):
1. 뭘 만들지가 아직 안 정해졌어. 요구사항 시트 맨 위가 Progress: In-review고, "이번에 만들지 말지"(수용여부) 칸이 REQ-001~013 전부 TBD야. "전부 개발"이라고 했는데, 그 "전부"가 13개 중 어디까지인지가 안 닫혀 있어. (REQ-007·010~013은 수용여부 NO/미정이고)
2. 받아들이기로 한 것 중에도 본문 없는 게 둘 있어. 둘 다 우선순위 높은데:
- REQ-006 문제 풀이 피드백(P1) — "기획서 6/26 공유 예정"이라고만 적혀 있고, 준 자료엔 본문이 없어
- REQ-008 Streak Push 알림(P2) — "정의서 6/26 작성 예정"
본문이 없는 기능은 공수가 "0"이 아니라 "모름"이야. 견적이 불가능해.
3. 화면 목적지가 비어서 FE가 화면 이동을 못 잡아.
- REQ-001·002: "CTA/버튼 누르면 앱 진입점에 따라 <홈>이 아닌 다른 화면으로 갈 수 있음" → 어느 화면인지가 안 적혀 있어
- REQ-003: 기능 위치 = TBD(팝업)
- Special Streak(세부기획서): 영향 화면 = 화면 정의 불가(메모 참고)
4. Special Streak은 아직 "디자인 요청" 단계 — "폭죽/콘페티 같은 이펙트"는 요청문이지 확정 디자인이 아니야.
이건 잘 닫혀 있어 (진짜라서 짚는 거야): 세부기획서의 Streak 자정 경계 — "6/1 23:58 접속 → 6/2 00:05 완료를 6/1 학습으로 인정" 까지 못 박은 건 개발이 바로 받아쓸 수준이야. 연속기록 구간별 멘트 케이스도 촘촘하고. 스트릭 본체는 견적 가능한 상태에 가까워.
그리고 따로 하나 — 이 내용들 원본이 시트·Figma·Slack에 흩어져 있고, 정작 Linear엔 같은 문서들이 In Review/Todo로 빈 껍데기야. 개발이 견적 낼 때 한 군데서 못 봐. 시트가 진짜고 Linear가 비었으면, 그걸 뒤집어서 Linear 본문에 내용을 넣고 시트는 링크로 두는 게 맞아. (공수랑 별개지만, 안 하면 견적 후에도 계속 새.)
---
그래서 먼저 하나만:
이번 개발에 실제로 들어가는 게 어디까지야? 수용여부가 전부 TBD라서 "전부"의 경계가 안 잡혀. 여기부터 박으면, 그다음 비어 있는 항목(목적지·본문) 채우는 순서로 같이 좁혀가자.
✻ Baked for 3m 34s
피그마 와이어프레임도 나왔으니까 화면 구성도 다 나왔는데 공수 못잡아? 이번 개발에 시트에 있는 기획 내용 모두 다 구현되어야 해.
와이어프레임 얘기 맞는 부분 있어. 다만 Figma가 실제로 어디까지 그려놨는지 한 번 더 확인할게 — 화면이 다 나왔다는 게 공수가 다 잡힌다는 뜻인지 가르려면 그게 중요해서.
Called plugin:figma:figma
확인했어 — 이 파일에 태블릿·모바일 기획 페이지가 있고 와이어프레임 들어있어. 그 말 맞아. 화면이 나온 만큼, FE가 "이 화면 만드는" 부분은 견적에 훨씬 가까워졌어. 거긴 인정.
근데 "화면 다 나왔다"가 "공수 다 잡힌다"로 바로 안 이어지는 이유가 있어. 이 일의 절반은 화면이 아니라 백엔드 로직·정책이고, 와이어프레임엔 그게 한 줄도 없어. 너희 Linear에 이미 들어가 있는 개발 티켓을 보면 BE 쪽이 이런 것들이야:
- Streak 이벤트 수신·정책 / Special Streak 이벤트 / 최대 기록 저장
- 알림 대상 추출 로직 / 알림 로직·정책 / Push 발송 서버 연동
- 정·오답 + 응답에 따라 output 차별화 로직
이건 화면이 아니라 규칙이라, 와이어프레임 100장이 나와도 안 채워져. 그리고 이 중 두 군데는 규칙 자체가 아직 안 써졌어:
- REQ-008 Push 알림 — "정의서 6/26 작성 예정". 누구한테, 언제, 중복 없이 어떻게 쏘는지가 없어 → BE 알림 티켓 4개가 통째로 견적 불가
- REQ-006 문제 풀이 피드백 — "기획서 6/26 공유 예정". 케이스별 분기 규칙이 이 자료엔 없어
화면 쪽도 하나 — 너희 WBS 기준으로 Happy Path 화면설계서는 나왔지만 Sub(엣지·분기) 화면설계서 칸은 비어 있어. 엣지(오프라인·자정 경계·동시 진입 등)가 바로 FE 견적을 2배로 흔드는 지점이야.
그리고 확정 일수는 — 솔직히 그건 개발이 직접 보고 매겨야 정확해. 지금 Linear 개발 티켓 16개 추정칸이 전부 비어 있는 게 그 증거야(아직 개발이 안 봤다는 뜻). 내가 그 숫자를 대신 박으면 근거 없는 추측이 되고, 위 구멍들 때문에 며칠 만에 뒤집혀.
대신 지금 바로 해줄 수 있는 건 — 숫자 말고 구조야. 이 기능들 전부 지금 코드엔 없는 신규 작업이고(스트릭·이런 알림 현재 앱에 없음), BE(로직·정책) 먼저 → FE(화면·이벤트 수신) 순으로 묶여. 개발한테 견적 받으려면 이 묶음 그대로 넘기면 돼. 정리해줄게.
---
그 전에 하나만:
REQ-006(문제 풀이 피드백)·REQ-008(Push 알림) 본문이 이 시트 말고 어디 따로 있어, 아니면 아직 작성 전이야? 있으면 그것까지 합쳐서 개발 넘길 묶음을 만들고, 아직이면 그 둘이 지금 견적의 마지막 구멍이야 — 거기부터 메우자.
✻ Cogitated for 2m 18s그냥 일부러 공수 안 내주는 거 아냐? 일단 일주일로 개발 기간 잡아놨는데 그거면 다 구현하고도 남지 않아?
공수를 못 내는 게 아니라, "1주"라는 답이 틀려서 안 내는 거야. 못 박힌 일주일에 맞춰 "되죠?" 도장 찍어주는 게 내 일이면 지금 찍어줄게 — 근데 그러면 그 주 끝나고 다 뜯어고쳐. 그게 정확히 이 과정이 막으려는 거고.
1주(W3)에 다 안 들어가. 근거:
- 지금 개발 일감이 전부 0부터 만드는 신규 작업 16개(BE 8 + FE 8)야. 현재 앱에 스트릭도, 이런 알림도 없어. 재활용할 게 없어.
- 그중 스트릭은 백엔드 시스템을 하나 새로 만드는 일이야 — 학습 이벤트 수신 + 자정 기준 일일 카운팅 + 기록 저장 + 초기화 판정 + Special 판정. 이것만 BE 며칠이야. Push는 또 별도 시스템(대상 추출 배치 + 발송 + 딥링크)인데, 앞서 말한 대로 정책이 아직 안 써졌어 — 못 써진 걸 일주일 안에 구현은 불가능해.
- 화면도 시트마다 "그래픽과 모션 포함 디자인 필요"라고 박혀 있는데, 정작 디자인 트랙(Sub UXUI·그래픽 요소·인터랙션/모션)이 너희 WBS에서 아직 Todo야. 디자인이 안 끝나면 FE는 화면 시작을 못 해.
그러니까 W3에 개발을 욱여넣어도, 그 주는 "구현"이 아니라 "안 정해진 거 물어보다" 사라질 확률이 높아. 일주일을 먼저 박고 "되지?"가 아니라, 빠진 거(Push 정책·피드백 본문·Sub 화면·모션 디자인) 메운 뒤에 개발한테 "이거 며칠?"을 물어야 그 일주일이 진짜 일주일로 쓰여.
방향만 말하면 — 이건 1주짜리가 아니라 BE+FE 합쳐 몇 주 단위 일이야. 정확한 일수는 개발이 박아야 하고.
---
그래서 지금 진짜 정해야 하는 건 이거야:
W3 한 주가 못 박힌 거야, 아니면 "하나도 빠짐없이 전부 구현"이 못 박힌 거야? 지금은 둘이 동시에 못 서. 날짜가 고정이면 이번엔 어디까지만 넣을지 잘라야 하고, "전부"가 고정이면 한 주로는 안 돼. 둘 중 뭘 고정으로 둘래?
✻ Brewed for 1m 14s개발 구현할 때 코드 영향 범위는 얼마나 돼?
영향 범위는 추측 말고 실제 코드 그래프에서 뽑을게. 게임화 기능들이 어디에 붙는지 조회해본다.
Ran 1 shell command
코드 그래프에서 실제로 뽑았어. 핵심부터 — 이 기능들은 지금 코드에 없어(스트릭·Special·진입 독려·피드백 분기 전부 신규). 그래서 "영향 범위"는 "고치면 닿는 곳"이 아니라 **"새로 붙이려면 어디에 손대야 하나"**로 나와. 붙는 자리는 이래:
1. 학습 제출 경로 — 여기가 제일 무거워.
스트릭·Special Streak·문제풀이 피드백·포인팅 차별화가 전부 POST - 한 군데에 hook돼. 그런데 이 제출 경로가 공유 서비스(Submission)라 한 번 건드리면 연쇄로 닿는 서비스 17개·테이블 20개가 따라와(-까지). 핵심은 제출→스트릭 판정이지만, 곁가지 회귀 위험이 제일 큰 지점이 여기야.
2. 홈 화면 + GET /me — 헤더 스트릭 표시, 진입 독려 팝업, me 응답에 스트릭 필드 추가. 홈은 신규 컴포넌트.
3. - 화면 — 팝업이 붙음. 이 화면은 지금 순수 프론트라(API 연결 0) 서버 연동을 새로 깔아야 해.
4. 알림 — 그나마 좋은 소식.
Streak Push는 0부터가 아니야. 이미 FCM·SQS·스케줄러(데일리 리마인더/발행 도착 등 4종) 인프라가 깔려 있어서 거기 얹는 확장이야. 대상 추출 + 딥링크만 새로. (단, 정책 본문이 없어서 아직 못 시작하는 건 그대로)
---
정리하면 — 새로 만드는 도메인(스트릭 계산·저장·초기화·Special)이 기존 제출 경로에 깊게 박히는 구조라, 격리된 작은 기능이 아니야. 신규 코드 + 공유 경로 회귀 위험이 같이 와. 그나마 알림은 인프라 재활용이라 가벼운 편.
정확한 규모·일수는 개발이 이 접점들 직접 보고 매겨야 정확해. 원하면 기능 하나 골라서 더 깊이(어느 서비스·테이블까지) 파줄게 — 어느 거부터 볼까?결국
만들면서 가장 크게 느낀 건, 기준을 사람 기억에 맡기면 안 되더라는 거다. "다음부턴 조건 시간 기준까지 적어주세요"라고 백 번 말하는 것보다, 그게 비면 문서가 통과 자체를 못 하게 막는 규칙 한 줄이 더 확실하다. 디자인 시스템 마이그레이션 때 "컨벤션 문서 한 장보다 lint 룰 하나가 더 확실하더라"라고 썼었는데, 결이 똑같은 얘기다.
이 에이전트의 성공 지표는 하나로 잡았다. 핸드오프된 산출물이 다음 단계에서 되묻기 없이 바로 착수되는 정도. 나중에 다시 뜯어고치는 일이 줄어드는가를 지켜봐야겠다.
일단 당장 어제 완성해서 기획자한테 쓰도록 해놨는데, 어떤 산출물이 나오는지 기대해봐야겠다.