선불 잔액 고지 문구 조사 오류 수정
목차
이커머스 PG 플랫폼 footer에 표시되는 선불 잔액 고지 문구에서 조사 오류를 수정했다. "는"을 "가"로 — 한 글자 변경이지만, 결제 플랫폼에서 사용자에게 직접 노출되는 자리라 그냥 지나치지 않았다.
조사 하나가 왜 신경 쓰이나
한국어 조사 "은/는"과 "이/가"는 겉으로 비슷해 보여도 기능이 다르다. "은/는"은 주제 표지(topic marker)로, 문장의 주제를 설정하거나 대조할 때 쓴다. "이/가"는 주어 표지(subject marker)로, 행위의 주체나 상태의 대상을 가리킨다. 어느 쪽을 쓰느냐에 따라 문장의 초점이 달라지고, 잘못 쓰면 문법적으로 어색해지거나 의미가 미묘하게 틀어진다.
짧은 고지 문구일수록 조사 선택이 더 잘 드러난다. 긴 본문이라면 어색함이 문맥에 묻힐 수도 있지만, footer의 한 줄짜리 안내 문구는 조사 하나가 전체 문장의 자연스러움을 거의 전적으로 결정한다. 결제 플랫폼에서 이 문구를 보는 사람은 본인 잔액이 얼마나 남았는지 확인하는 상황이다. 그 순간에 문구가 어색하게 읽히면 — 기능이 정상이더라도 — 플랫폼이 허술하게 만들어진 것처럼 느껴질 수 있다.
숫자 정합성은 당연히 중요하다. 그런데 사용자가 화면에서 제일 먼저 읽는 건 숫자가 아니라 문구다. 숫자가 맞아도 문구가 어색하면 "이거 제대로 된 거 맞나?"라는 의심이 생긴다. 선불 잔액처럼 민감한 금액 정보를 안내하는 자리라면 더 그렇다. 기능 신뢰와 문구 품질은 생각보다 이어져 있다.
수정 내용
변경 파일은 뷰/스타일 1개다. 고지 문구가 템플릿 내에 정적 문자열로 들어가 있었고, 해당 조사 한 글자를 교체하는 게 수정의 전부였다. 별도 i18n 레이어나 CMS 없이 뷰 파일에서 직접 관리되는 구조여서 범위가 명확했다.
<!-- before -->
<p class="prepaid-notice">선불 잔액는 자동으로 차감됩니다.</p>
<!-- after -->
<p class="prepaid-notice">선불 잔액가 자동으로 차감됩니다.</p>
수정 후엔 해당 화면을 직접 띄워서 문구가 의도대로 렌더링되는지 눈으로 확인했다. footer가 노출되는 진입 경로가 하나가 아닐 수 있어서 — 잔액 정상 상태, 잔액 부족 상태 등 다른 케이스도 같이 돌렸다. 같은 문구를 다른 컴포넌트에서 재사용하는 경우가 있는지도 코드베이스를 grep으로 확인했고, 이번 건은 해당 뷰 파일에만 존재하는 것을 확인했다.
작은 픽스를 다루는 방식
한 글자짜리 수정이라도 처리 흐름은 크게 다르지 않다.
| 단계 | 내용 |
|---|---|
| 수정 전 확인 | 현재 화면에서 잘못된 문구 특정 |
| 범위 탐색 | 같은 문구/패턴이 다른 파일에도 있는지 검색 |
| 수정 | 해당 파일 조사 교체 |
| 검증 | 수정된 화면 재확인, 다른 진입 경로도 같은 케이스로 확인 |
| 커밋 | 무엇이 아닌 왜를 담은 메시지 |
커밋 메시지도 "글자 하나 수정"이 아니라 맥락을 남긴다.
fix: 선불 잔액 고지 문구 조사 수정 (는 → 가)
footer 고지 문구에서 주제 표지(는) 대신 주어 표지(가) 사용이
맞는 문장 구조. 해당 뷰 파일에만 존재 확인.
다른 진입 경로(잔액 부족 상태 포함) 동작도 직접 확인.
이렇게 남겨 두면 나중에 git blame 돌릴 때 "왜 바꿨지?"를 따로 파고들 필요가 없다. 한 달 뒤의 내가, 혹은 다른 팀원이 이 커밋을 보게 될 때 바로 판단할 수 있도록.
작은 커밋을 자주 남기는 것도 같은 맥락이다. 논리적으로 독립된 변경을 쪼개서 커밋해 두면 나중에 문제가 생겼을 때 어느 변경에서 깨졌는지 추적하기 훨씬 쉽다. 이번처럼 뷰 파일에서 문구 한 줄만 건드린 커밋은 그 자체로 완결돼 있어서, 만약 예상치 못한 렌더링 문제가 생기더라도 원인을 바로 좁힐 수 있다.
금융/결제 도메인에서 일하다 보면 숫자 정합성에는 자연스럽게 촉각을 세우게 된다. 집계가 맞는지, 차감이 정확히 들어가는지, 상태가 올바르게 반영됐는지. 막상 UI 문구 품질은 기능 구현 뒤로 밀리는 경향이 있는데, 특히 사내 서비스라면 "어차피 내부 도구잖아"라는 심리가 작동하기 쉽다. 그런데 매일 쓰는 사람이 오히려 그 어색함을 더 자주, 더 오래 마주친다.
사내 서비스를 만들다 보면 기능 하나가 단순히 화면에 요소 하나 추가하는 것으로 끝나지 않는다는 걸 계속 체감한다. SQL 집계, 상태 머신, 예외 처리, 화면 렌더링이 모두 엮여 있어서 어느 하나만 빠뜨려도 숫자가 안 맞거나 특정 상황에서 이상한 화면이 나온다. 그 위에 문구까지 맞아야 사용자가 신뢰를 가지고 쓸 수 있다. 선불 잔액처럼 금액과 직결된 정보를 안내하는 문구는 정확하게 읽혀야 한다. 조사 하나가 틀렸다고 기능이 망가지는 건 아니지만, "이 플랫폼이 꼼꼼하게 만들어졌다"는 인상은 그런 디테일이 쌓여서 만들어진다. 반대로 어색한 문구가 여러 군데 쌓이면 서비스 전체에 대한 인상이 흐릿해진다.
발견했을 때 안 고치면 나중에 반드시 다시 마주친다 — 누군가의 피드백으로, 혹은 내 눈에 다시 걸리는 형태로. 컨텍스트를 이미 들고 있는 지금 고치는 게 가장 싸다.
댓글 0
첫 댓글 달아줘.