rewriting-technical-prose-naturally 를 서브에이전트 셋으로 나눠 56편에 적용했다. ai-tells.md 의 첫 절대로 다른 표현으로 바꾸는 대신 문장을 통째로 지웠다. 설명한 것의 중요성을 다시 평가하는 꼬리 19 이미 설명한 것을 추상어로 되풀이 19 독자에게 읽는 법을 지시하거나 오해를 가정 9 자료가 뒷받침하지 않는 덧붙인 이득 4 문서군 전체의 문형 편중도 풀었다 — 함께 27→7(한 묶음), 그대로 22→12(두 묶음), 하게 된다 1→0. 한 편에서 세 번 반복되던 「같은 병이 ~에서도 났다」와 두 기록에 같은 문장으로 있던 세 쌍을 갈랐다. 계약 제목 「여덟 자리」가 본문의 「여덟 곳」과 어긋나 있었다. 제목이 spatial-metaphor 규칙에도 걸리므로 계약과 기록을 함께 「여덟 곳」으로 맞췄다. 검사 넷 전부 통과한다 — check_prose 56편 error 0 · check_body PASS · check_evidence --repo 문제 없음 · verify-tech-log-tree error 0 warn 0. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2.5 KiB
2.5 KiB
kind, slug, title, topic, topicName, project, status, decisionStatus, decidedOn, sourceRevision, source
| kind | slug | title | topic | topicName | project | status | decisionStatus | decidedOn | sourceRevision | source | |
|---|---|---|---|---|---|---|---|---|---|---|---|
| PROJECT_DECISION | a-new-route-ships-frontend-first | 새 라우트는 프론트엔드를 먼저 배포한다 | addresses-frozen-at-publish-time | 주소가 만들어지고 굳어지는 곳 | TechLog | 게시 전 | ADOPTED | 2026-09-01 | tech-log@2026-09-02 |
|
새 라우트는 프론트엔드를 먼저 배포한다
새 라우트를 여는 변경은 프론트엔드를 먼저 배포한다. nginx 설정이 라우트 계약에서 생성되므로, 프론트가 배포되기 전까지 그 경로는 엣지에서 404 다. 백엔드를 먼저 배포하면 서버는 이미 그 주소를 내보내고 사용자는 전부 404 인 화면을 본다.
근거
- 축 링크가 자기 자신을 가리켰고, 고친 뒤에는 백엔드를 먼저 배포했다 이 순서를 정하게 된 사건이다. 반대 순서로 배포해 사용자가 네 링크 전부 404 인 화면을 봤다.
- nginx 가 모르는 라우트는 새로고침에서 404 다 엣지가 왜 그 경로를 모르는지가 그 기록에 있다.
- catch-all 라우트는 nginx 패턴으로 번역하지 않는다 이 순서가 필요해진 이유가 그 결정에 있다.
결정문
새 공개 라우트를 여는 변경은 프론트엔드를 먼저 배포하고, 그 주소를 내보내는 백엔드 변경을 다음 배포에 넣는다.
판단 이유
nginx 설정은 라우트 계약에서 생성된다. 프론트 이미지가 배포되기 전까지 그 경로는 서빙 패턴에 없고, 엣지에서 404 로 끝난다.
백엔드를 먼저 배포하면 서버는 이미 그 주소를 링크로 내보낸다. 방문자는 화면에 그려진 링크를 누르고 404 를 만난다. 축 화면을 만들 때 실제로 그렇게 배포했고 사용자가 네 링크 전부 404 인 화면을 봤다.
catch-all 을 서빙 패턴으로 번역하지 않기로 했으므로 이 구간이 soft 200 으로 덮이지 않는다.
영향
새 주소를 내보내는 백엔드 변경이 한 배포 늦게 나간다. 두 저장소를 한 번에 배포하고 싶은 변경에서 그 사이가 벌어진다.
프론트를 먼저 배포한 뒤에는 그 경로가 열려 있지만 서버가 아직 그 주소를 내보내지 않는다. 이 구간에서는 화면에 링크가 그려지지 않으므로 방문자에게 보이는 문제가 없다.
배포 순서를 사람이 기억해야 한다. 이 순서를 강제하는 검사는 없다.