UI 문구 통일, 상태당 용어 하나: e2e 테스트까지 같이 고친 이유

라이프케어로그에서 만드는 농구 동호회 매니저 플랜비(plan-b)의 회비 화면을 만지던 날 이야기예요. 어제 10월 9일 하루에 플랜비에 커밋 6건을 올렸는데, 그중 마지막이 "회비 용어를 평이한 말로, 상태당 용어는 하나"라는 수정이었어요. 기능을 더한 게 아니라 글자를 고친 커밋인데, 이게 하루 중 가장 생각할 거리가 많았어요.

왜 문구부터 손댔나

회비 화면은 "냈다"와 "아직"처럼 상태를 구분해 보여줘야 하는 화면이에요. 같은 상태를 화면마다 다른 말로 부르면 운영자도 헷갈리고 멤버는 더 헷갈려요. 예를 들어 한 화면에서 "미납"이라 쓰고 다른 화면에서 "안 냄"이라 쓰면, 같은 걸 가리키는 건지 한 번 더 생각해야 하죠. 이건 설명용 예시지만, 실제로 만지다 보니 이런 식의 어긋남이 쌓이기 쉬운 구조였어요. 그래서 규칙을 하나로 정했어요. 상태 하나에 용어 하나, 그리고 한자어보다 입말에 가까운 쪽.

커밋에 묶인 파일을 보면

직접 고쳐 보니 수정 범위가 생각보다 넓었어요. 커밋에 함께 묶인 파일을 보면 회비 목록과 내 회비, 화면 2개만이 아니었거든요. e2e 스펙 2개(flows.spec.ts, roles.spec.ts)와 DESIGN.md 1개가 같은 묶음에 들어 있어요. 화면 2개는 당연한데, 나머지 3개가 이 글의 핵심이에요.

문구 규칙 정하기→화면 2개 수정→e2e 스펙 2개 갱신→DESIGN.md에 규칙 기록

e2e 스펙이 같이 열린 이유

e2e 테스트는 화면에 보이는 글자로 요소를 찾는 경우가 많아요. 버튼 이름, 상태 라벨 같은 것들요. 그러니 문구를 바꾸면 그 문구를 찾던 테스트도 같이 바꿔야 해요. 실제로 같은 날 오후 2시 41분에 역할별 시나리오와 핵심 흐름 e2e 스펙을 커밋했고, 약 1시간 뒤인 3시 46분 문구 수정 커밋에서 그 스펙 두 파일을 다시 열었어요.

돌려 보니 이건 나쁜 신호가 아니었어요. 테스트가 사용자 눈에 보이는 글자를 기준으로 삼고 있다는 뜻이고, 문구가 바뀌면 테스트가 바로 알려주니까요. 다만 교훈 하나는 남았어요. 문구 규칙이 먼저 정해져 있었다면 스펙을 한 시간 만에 두 번 쓰는 일은 없었을 거예요.

DESIGN.md에 적은 이유

그래서 규칙을 코드 주석이 아니라 DESIGN.md에 적었어요. 다음에 회비 말고 출전 로테이션이나 멤버 관리 화면을 만질 때 같은 질문을 또 하지 않으려고요. 1인 개발은 어제의 나와 오늘의 내가 다른 결정을 내리는 일이 잦아요. 적어 두고 보니 그 간격이 줄어요. 같은 날 디자인 문서에 주 색상 예산과 위계 규칙을 넣은 커밋도 따로 있었는데, 결국 둘 다 "다음 화면에서 고민을 반복하지 말자"는 같은 목적이었어요.

• ✓상태 하나에 용어 하나
• ✓문구와 e2e 스펙은 한 묶음
• ✓규칙은 DESIGN.md에

정리

• 문구 수정은 화면만 고치는 일이 아니에요. 테스트와 문서까지 세 군데를 같이 건드리는 일이에요.
• 테스트해 보면 문구 기반 셀렉터는 자주 깨지는 대신, 사용자 관점을 지켜 줘요. 깨지는 걸 비용이 아니라 신호로 보기로 했어요.
• 규칙은 처음 정할 때 문서로 남겨요. 두 번째 화면부터 시간이 줄어요.

최근 7일 커밋 40건 중 플랜비가 22건인데, 그중 e2e 테스트 커밋이 5건, 문서 커밋이 3건이에요. 새 기능보다 "같은 말을 같은 자리에서 쓰는 일"에 시간을 쓰는 중이에요. 동호회 운영 화면에서는 이런 일관성이 기능만큼 중요하다고 보고 있어요.