DongHyeonkaandClaude Opus 5
fd221353a3
SSOT 를 저장소에서 확인해 더 보강하고 그것으로 다시 썼다.
§7.2 참조 검사 SQL 을 문자열로 조립하는 실제 코드 — 컴파일러가 표 이름도
컬럼 이름도 보지 않는다는 것이 그 모양에서 드러난다
§11.2 section-heading-rank 가 미디어 쿼리 값을 먼저 걷어내는 이유(테스트 주석)
§16.1 질문 삭제는 참조가 둘뿐이라 같은 문제가 덜하다는 대조
Case 열 편과 Question 셋을 다시 썼다. Question 은 사실·가정·미지수·제약을 갈라
채우고 선택지마다 무엇을 감수하는지 적었다 — 오류 코드를 나누면 계약과 반입한 두
저장소가 함께 움직인다는 것처럼.
SSOT 62,643 → 68,319 자. 검사 넷 전부 통과한다.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
100 lines
5.3 KiB
Markdown
100 lines
5.3 KiB
Markdown
---
|
|
kind: CASE
|
|
slug: a-link-that-pointed-at-itself
|
|
title: 축 링크가 자기 자신을 가리켰고, 고친 뒤에는 백엔드를 먼저 배포했다
|
|
topic: addresses-frozen-at-publish-time
|
|
topicName: 주소가 만들어지고 굳어지는 곳
|
|
project: TechLog
|
|
status: 게시 전
|
|
lastVerifiedOn: 2026-09-04
|
|
sourceRevision: tech-log@2026-09-02
|
|
source:
|
|
- final/document.md#§9.1
|
|
- final/document.md#§9.3
|
|
---
|
|
|
|
# 축 링크가 자기 자신을 가리켰고, 고친 뒤에는 백엔드를 먼저 배포했다
|
|
|
|
주제 화면의 네 줄은 링크인데 눌러도 아무 일이 없었다. 축의 주소를 주제 화면 안의 앵커로 바꿨더니, 정작 주제 화면에서는 그 링크가 자기 자신을 가리켰다. 결국 축에 자기 화면을 줬고, 그 화면을 만들고 백엔드를 프론트보다 먼저 배포해 사용자가 네 링크 전부 404 인 화면을 봤다.
|
|
|
|
## 관계
|
|
|
|
- **새 라우트는 프론트엔드를 먼저 배포한다**
|
|
이 사건에서 정한 순서다.
|
|
- **우회를 남길 때는 되돌릴 조건을 함께 적는다**
|
|
같은 주제 링크를 다루며 굳힌 기준이다.
|
|
- **축은 주제가 이름을 정하고, 기록은 종류와 아이디의 쌍으로 축에 걸린다**
|
|
축에 자기 화면을 주려면 알아야 하는 구조다.
|
|
|
|
## 문제
|
|
|
|
주제 화면의 네 줄(SPA·Mediator·BFF·Forward-Auth)은 링크로 그려져 있었다. 눌러도 아무 일이 없었다.
|
|
|
|
처음에 `/topics/{주제}/{축}` 이라 적어 두었는데 그런 화면이 없었다.
|
|
|
|
## 결론
|
|
|
|
주소를 두 번 옮긴 끝에 축에 자기 화면을 줬다.
|
|
|
|
1차 : 축의 주소를 주제 화면 안의 앵커로 바꿨다 — 주제 화면에서는 그 링크가 자기 자신을 가리켰다
|
|
2차 : 축에 자기 화면을 줬다 — 목록 조회에 축 필터를 더해 걸러 낸다
|
|
|
|
축 slug 는 주제 안에서만 유일하므로 조회에서 주제까지 맞춘다. 주제를 빼면 다른 주제의 같은 이름 축까지 걸린다.
|
|
|
|
같은 시기에 주제가 없는 기록이 이름 없는 주제 링크를 달고 있던 것도 고쳤다. 문서 머리말의 breadcrumb 과 탐색의 「주제 없음」 묶음 둘 다였고, 프로젝트 조각은 처음부터 조건부였는데 주제 쪽만 아니었다.
|
|
|
|
## 검증 환경
|
|
|
|
tech-log-frontend : 8828005 · 67a5491
|
|
tech-log-backend : 63eb177 · 6d3b68b
|
|
tech-log-design-package : 71bab4c · b93d62a
|
|
확인 방식 : 배포본에서 주제 화면의 네 링크를 눌러 각각 어디로 가는지 확인
|
|
|
|
## 재현 조건
|
|
|
|
1. 주제에 축을 넷 만들고 기록을 각 축에 건다
|
|
2. 주제 화면에서 축 줄을 누른다
|
|
3. 주소가 바뀌는지, 화면이 바뀌는지를 따로 본다
|
|
|
|
## 본문
|
|
|
|
<!-- body:start -->
|
|
|
|
## 주소만 바뀌고 화면은 그대로였다
|
|
|
|
주제 화면의 네 줄은 링크로 그려져 있었는데 눌러도 아무 일이 없었다.
|
|
|
|
처음에 축의 주소를 `/topics/{주제}/{축}` 이라 적어 두었는데 그런 화면이 없었다. 그래서 축의 주소를 주제 화면 안의 앵커로 바꿨다.
|
|
|
|
주제 화면에서 그 링크를 누르면 주소에 앵커가 붙는다. 화면은 이미 그 주제 화면이므로 라우터가 다시 그릴 것이 없고, 앵커가 가리키는 element 도 없으니 스크롤도 일어나지 않는다.
|
|
|
|
## 앵커로 옮긴 것이 왜 나쁘지 않았나
|
|
|
|
앵커는 결정에는 맞는 선택이다. 결정은 프로젝트 화면 안에서만 읽히므로 자기 화면이 필요 없고, 목록 위의 앵커로 충분하다.
|
|
|
|
축은 다르다. 축을 고르면 그 축에 걸린 기록만 보여야 하는데, 앵커는 화면을 바꾸지 않고 위치만 옮긴다. 같은 표기를 쓰지만 두 경우가 요구하는 것이 다르다.
|
|
|
|
## 축에 자기 화면을 줬다
|
|
|
|
목록 조회에 축 필터를 더하고 기록이 어느 축에 걸리는지를 담은 표로 거른다.
|
|
|
|
축 slug 는 주제 안에서만 유일하므로 조회에서 주제까지 함께 맞춘다. 주제를 빼면 다른 주제의 같은 이름 축이 함께 걸린다 — 인증 경계 주제의 `bff` 와 다른 주제의 `bff` 가 구분되지 않는다.
|
|
|
|
## 배포 순서로 만든 2차 사고
|
|
|
|
> **이 건에서 제가 만든 2차 사고:** 축 화면을 만들고 **백엔드를 프론트보다 먼저 배포했습니다.** nginx 설정은 라우트 계약에서 생성되므로, 프론트가 배포되기 전까지 `/topics/x/y` 는 404 입니다. 서버는 이미 그 주소를 내보내고 있었고, 사용자는 네 링크가 전부 404 인 화면을 봤습니다. **순서가 있습니다 — 새 라우트는 프론트가 먼저입니다.**
|
|
|
|
고치기 전과 고친 뒤가 사용자에게는 같아 보였다. 앞에서는 눌러도 아무 일이 없었고, 뒤에서는 눌러서 404 를 만났다.
|
|
|
|
## 주제가 없는 기록
|
|
|
|
같은 시기에 주제 없이 게시된 기록이 이름 없는 주제 링크를 달고 있었다. 문서 머리말의 breadcrumb 과 탐색의 「주제 없음」 묶음 둘 다였다.
|
|
|
|
프로젝트 조각은 처음부터 조건부였다. 주제 쪽만 조건이 없었고, 그 차이가 두 화면에서 같은 모양으로 나타났다 — 값이 없을 때 그 조각을 그리지 않는 판단을 한쪽에만 넣었다.
|
|
|
|
## 확인하지 못한 것
|
|
|
|
축 slug 가 주제 안에서만 유일하다는 전제를 조회에 반영했다. 주제를 빼고 조회하는 경로가 남아 있는지는 세지 않았다.
|
|
|
|
<!-- body:end -->
|