Shopify 앱 공개 전 다듬기
홈 화면과 판매 채널을 붙이고, 앱 이름과 영어 지원까지 정리한 기록
지난 글에서는 상품 일괄 변경에 작업 기록과 되돌리기를 붙였다. 글 끝에 남겨둔 일은 실제 화면에서 저장 흐름을 이어서 확인하는 것이었다. 그래서 이번에는 기능을 새로 설계하기보다 개발 스토어에서 앱을 직접 써보는 데서 시작했다.
막상 써보니 걸리는 것이 기능보다 화면 쪽에 많았다. 검색 버튼이 조건들 사이에 끼어 있었고, 비슷해 보이는 입력칸끼리 테두리 색이 달랐다. 홈은 템플릿 그대로라 버튼 하나만 있었고, 메뉴 이름 "상품 작업실"도 어딘가 어색했다. 하나하나는 작았지만 모아 놓으니 남에게 보여주기 어려운 상태였다.
"이걸 나중에 공개한다면, 지금 이대로 내놓을 수 있을까?"
그래서 이번에는 공개를 전제로 다듬기로 했다. 지난 글 이후 커밋은 24개다. 목록 화면의 작은 오류부터 홈 화면, 판매 채널 게시, 공통 디자인 값, 앱 이름, 영어 지원까지 이어졌다.
목록에서 먼저 걸린 것들
보이는 순서와 Tab 순서를 함께 맞췄다
처음 요청은 단순했다. 검색 영역을 한 줄로 만드는 것이었다. 한 줄로 만들고 나니 순서가 [검색어] [상태] [검색] [정렬] [필터]가 되어 검색 버튼이 조건 한가운데에 있었다. 조건을 다 고른 뒤 마지막에 누르는 버튼이 중간에 있을 이유가 없었다.
CSS로 버튼 위치만 끝으로 옮기면 화면은 금방 고쳐진다. 하지만 그렇게 하면 키보드 Tab 이동은 여전히 코드 순서를 따라 중간에서 검색 버튼에 걸린다. 그래서 코드에서도 검색 버튼을 필터 뒤로 옮기고, CSS로 강제로 배치하던 지정은 지웠다. 목록 영역 폭에 따라 한 줄, 두 줄, 세 줄로 접히는 배치도 같은 순서를 유지하게 했다.
같은 작업 중에 Tab으로 표에 들어왔을 때 보이는 포커스 테두리의 윗변이 사라지는 문제도 있었다. 스크롤해도 고정되는 표 머리가 테두리 위를 덮고 있었다. 표 스크롤 영역을 감싸는 틀을 하나 두고 그 틀에 테두리를 그리도록 바꿨고, 같은 구조를 쓰는 작업 기록 화면에도 함께 적용했다.
입력할 때마다 나던 오류는 이벤트 객체 때문이었다
필터 패널의 "재고 N개 이하" 칸에 숫자를 입력하면 Cannot read properties of null (reading 'value')가 났다. 처음에는 코드를 읽어도 원인이 보이지 않았다. 브라우저 콘솔의 오류 위치를 받아보고 나서야 상태 갱신 함수 안에서 이벤트 값을 읽고 있다는 것을 알았다.
// 이전: 갱신 함수가 실행될 때는 currentTarget이 이미 null이다
onChange={(e) =>
setDraft((d) => ({ ...d, stockMax: e.currentTarget.value }))
}
// 이후: 이벤트 처리 중에 값을 먼저 꺼내 둔다
onChange={(e) => {
const stockMax = e.currentTarget.value;
setDraft((d) => ({ ...d, stockMax }));
}}
React는 갱신 함수를 나중에 실행하는데, 그 시점에는 currentTarget이 이미 비어 있다. 값을 먼저 변수에 담는 것으로 끝나는 수정이었다. 같은 칸의 라벨이 보이지 않던 것도 상단 검색창 라벨을 숨기는 스타일이 패널 안 라벨까지 숨기고 있어서였다.
느리다는 말을 구간으로 나눴다
목록을 쓰다 보면 전체적으로 느리다는 인상이 있었다. 초기화를 누르면 2~3초를 기다렸고, 검색과 필터 패널도 반응이 늦었다. 느리다는 말 하나로는 어디를 고쳐야 할지 알 수 없어서, 서버에서 Shopify Admin API를 직접 호출해 시간을 나눠 쟀다. 개발 스토어의 상품은 17개였다.
| 구간 | 확인한 것 | 조치 |
|---|---|---|
| API 호출 한 번 | 상품 수와 관계없이 0.4~0.6초 | 호출 수를 줄이는 쪽으로 접근 |
| 검색·필터 조회 | 일치 상품 조회가 끝난 뒤 목록 조회 시작, 0.86~0.91초 | 두 조회를 동시에 보내 0.42~0.44초 |
| 필터 패널 | 검색할 때마다 공급업체·유형·태그 목록을 다시 받음 | 한 번 받아 재사용하고, 열 때 뒤에서 갱신 |
| 기다리는 동안 | 버튼만 비활성화되고 표시가 없음 | 목록 위 진행 막대 추가 |
초기화의 나머지 1.5~2초는 해결하지 못했다. 서버에서는 목록 조회 한 번만 하고 있었기 때문에, 개발용 터널과 Vite 개발 서버를 거치는 시간으로 추정했다. 브라우저에서 직접 재지는 않았으므로 이 부분은 추정으로만 남겨둔다.
이후 메뉴 이동도 같은 방식으로 줄였다. 홈은 작업 기록의 예전 상품 이름을 찾는 요청을 개수 조회와 합쳐 Shopify 요청을 한 번으로 만들었고, 작업 기록 화면은 순서대로 기다리던 DB 조회를 동시에 실행하게 바꿨다. 이 변경은 요청 횟수와 순서를 테스트로 고정했지만, 바뀐 뒤의 체감 시간을 따로 재지는 않았다.
기다리는 표시도 같은 모양이어야 했다
상품 하나를 열 때는 안내 문구 한 줄이 전부여서, 응답이 늦으면 멈춘 것처럼 보였다. 처음에는 탭 아래에 메뉴 이동용 얇은 막대를 붙였지만 탭 경계선에 겹쳐 어색했다.
결국 일괄 수정의 로딩 표시와 같은 모양으로 맞췄다. 다만 상품 하나는 요청이 한 번이라 중간 진행률이 없어서, 숫자 없이 막대가 왼쪽에서 오른쪽으로 흐르게 했다. 가짜 진행률을 채우는 방식은 택하지 않았다.
응답을 일부러 늦춘 테스트 브라우저에서, 처음 열 때와 다음 상품으로 넘어갈 때 모두 확인했다.
홈은 손볼 상품부터 보여주기로 했다
전체 상품 수는 확인할 대상이 아니었다
홈은 템플릿에서 거의 바뀌지 않은 상태였다. 무엇을 넣을지 정하면서 기준을 하나 세웠다. 홈은 지금 손봐야 할 상품을 보여주고, 누르면 그 조건의 목록으로 가는 곳이어야 했다. 목록에 이미 있는 필터를 링크로 쓰면 카드의 숫자와 목록이 같은 검색 조건에서 나온다.
처음 구성에는 재고 부족·초안·보관됨·전체 상품을 나란히 두었다. 그런데 "확인이 필요한 상품"이라는 제목 아래에 전체 상품 수와 이미 판매를 끝낸 보관됨이 있는 것은 맞지 않았다. 보관됨은 빼고, 전체 상품 수는 제목 옆의 "전체 상품 보기" 링크로 옮겼다.
재고를 추적하지 않는 상품까지 세고 있었다
재고 5개 이하 카드에는 3개가 잡혔다. 그중 하나가 재고를 추적하지 않는 상품이었다. 추적하지 않으니 재고가 0으로 집계되었고, 손볼 필요가 없는데도 카드에 들어갔다. 목록의 재고 필터도 같은 조건을 쓰고 있어서 거기서도 같이 걸리고 있었다.
재고 조건에 tracks_inventory:true를 함께 걸어 둘 다 고쳤다. 고친 뒤에는 2개가 됐다. Shopify 검색은 모르는 조건을 오류 없이 무시하고 경고만 남기기 때문에, 이 조건이 경고 없이 인식되는지도 API로 따로 확인했다.
카드를 늘리기보다 한 카드 안에서 강조했다
처음에는 품절과 곧 품절을 별도 카드로 나누려고 했다. 급한 정도가 다르기 때문이다. 하지만 품절도 결국 재고 부족에 들어가므로, 나누면 같은 상품을 두 카드가 나눠 보여주는 셈이었다. 카드는 하나로 두고, 이름 옆에 빨간 "품절 N" 배지를 붙였다.
대신 새로 추가한 카드는 "판매 중 미게시"다. 상태는 활성인데 온라인 스토어에는 게시되지 않은 상품이다. 판매하려고 활성으로 바꿨지만 손님에게는 보이지 않으니, 놓치기 쉬운 실수였다. 카드는 급한 순서로 재고 부족, 판매 중 미게시, 초안으로 정렬했다.
status:active AND published_status:unpublished
알려주기만 하는 카드는 반쪽이었다
고칠 수 있어야 확인 카드가 의미가 있었다
"판매 중 미게시" 카드를 만들고 나니 바로 다음 문제가 보였다. 홈이 미게시 상품을 알려줘도 앱 안에서는 게시할 방법이 없었다. 결국 Shopify 관리자로 나가서 고쳐야 한다면 카드는 알림에 그친다.
범위는 세 가지로 놓고 비교했다. 온라인 스토어만 다룰지, 판매 채널 전체를 다룰지, 상품 하나 편집에만 넣을지였다. 처음에는 온라인 스토어만 다루는 쪽이 가볍다고 봤지만, 최종적으로는 판매 채널 전체를 채널마다 켜고 끄는 방식으로 정했다. 상품 편집과 일괄 수정 양쪽에 넣고, 게시 변경도 작업 기록에 남아 되돌릴 수 있게 했다. 이를 위해 앱 권한에 write_publications를 추가했다.
채널 이름을 읽는 데서 한 번 막혔다. 처음 시도한 조회는 "Channel Catalog 3090… for Online Store" 같은 내부 문자열을 돌려줬다. 사람이 읽을 이름이 아니어서 채널 쪽의 이름을 읽도록 바꿨다. 화면에서는 체크박스 대신 토글 스위치를 썼고, 바꾼 채널은 "저장하면 게시"처럼 저장 전에 무엇이 바뀔지 문구로 보여주게 했다.
다만 실제 게시 저장은 아직 돌려보지 않았다. 스토어 데이터를 바꾸는 일이라, 전송 내용과 실패 처리는 모의 테스트로만 확인했다. 실제 서버에서는 채널 목록과 상품별 게시 상태를 읽는 것까지만 확인했다.
일괄 수정은 고르는 순간부터 보여야 했다
일괄 수정에 실제로 쓸 만한 기능이 들어 있는지도 다시 점검했다. 가격 규칙은 충분했지만 컬렉션 추가·제거, 카테고리 지정, 재고를 N개로 맞추기가 빠져 있었다. 세 기능 모두 기존 저장 방식을 그대로 써서 작업 기록과 되돌리기도 같은 방식으로 동작하게 했다. 재고 맞추기는 옵션마다 목표와의 차이를 계산해 기존 재고 조정으로 보내므로, 그 사이 재고가 바뀌었으면 거부하는 보호 장치도 그대로 남는다.
점검하다가 기존 버그도 찾았다. "할인 종료"와 "비교 가격 제거"는 입력값이 필요 없는 규칙인데, 미리보기 버튼이 입력칸이 비었다는 이유로 계속 비활성화되어 있었다. 이 두 규칙은 처음부터 실행할 수 없었던 셈이다.
"항목을 골랐는데, 미리보기를 누르기 전까지는 아무것도 안 보인다고?"
화면 구성도 지적을 받았다. 상태나 컬렉션 같은 상품 단위 항목을 골라도, 미리보기를 누르기 전에는 어떤 상품이 어떻게 바뀌는지 보이지 않았다. 그래서 항목을 고르는 즉시 상품·현재·변경 후 세 칸의 대상 표가 나오도록 바꿨다. 이미 그 값인 상품은 회색 "변경 없음"으로 표시한다. 대상 표와 미리보기는 같은 계산 함수를 쓰게 해서 두 표의 내용이 어긋나지 않게 했다.
권한을 바꾼 직후 화면이 비었다
판매 채널 권한을 추가한 직후 앱 화면이 통째로 비고 Handling response 한 줄만 남은 적이 있다. 이 문구는 앱 코드가 아니라 Shopify 앱 라이브러리의 기본 오류 처리에서 나왔다. 로그인 확인이 본문 없는 오류 응답으로 실패하면, 기본 처리가 메뉴까지 지우고 이 한 줄만 보여준다.
정확한 원인은 끝내 확정하지 못했다. 권한 변경으로 설정이 다시 올라가는 사이, 또는 1시간마다 바뀌는 접속 토큰을 교환하는 순간에 요청 하나가 실패했을 가능성을 의심했을 뿐이다. 그래서 원인을 찾는 대신 같은 일이 다시 생겼을 때의 화면을 고쳤다. 본문 없는 오류일 때는 메뉴를 유지한 채 상태 코드별 안내와 새로고침 버튼, 오류 번호를 보여준다. 브라우저가 아닌 요청으로 410을 일부러 내서 이 화면이 나오는 것을 확인했다.
401의 원인은 코드 밖의 시계였다
그 뒤로 상품을 열 때 가끔 "서버 응답을 확인하지 못했습니다(HTTP 401)"가 나왔다. 처음에는 Shopify 접속 토큰을 의심했지만, 저장된 토큰으로 Admin API를 부르면 200이 돌아왔고 무효화된 흔적도 없었다. 남은 후보는 화면이 요청마다 붙이는 세션 토큰이었다.
세션 토큰은 수명이 60초이고, 라이브러리는 시계 차이를 10초까지만 봐준다. 그래서 서버 시계를 외부 시각과 비교했더니, 개발 PC의 WSL과 Windows 시계가 둘 다 22~23초 빨랐다. 그러면 유효한 토큰도 수명의 마지막 12초쯤은 만료로 판정된다. 발급 후 경과 시간을 바꿔 가며 토큰을 만들어 dev 서버에 보냈다.
| 토큰 경과 시간 | 시계를 맞추기 전 | 맞춘 뒤 |
|---|---|---|
| 5·30·45초 | 200 | 200 |
| 50·55초 | 401 | 200 |
| 65초 | - | 200 |
| 75초 | - | 401 |
Windows 시간 서비스가 꺼져 있어서 설정의 동기화만으로는 시각이 바뀌지 않았다. 서비스를 켜서 맞춘 뒤에는 65초까지 통과하고 75초에서 거부되어, 60초 수명에 10초 여유라는 규칙과 일치했다.
401이라고 해서 인증 코드의 문제는 아니었다. 앞의 Handling response 빈 화면도 같은 원인이었는지는 확인하지 못했다. 시각을 바꾸는 과정에서 새 WSL 터미널이 Wsl/Service/E_UNEXPECTED로 열리지 않는 문제도 생겼는데, 시각 변경과 관련이 있는지는 아직 모른다.
같은 부품처럼 보였지만 달랐다
테두리 차이는 선택자 우선순위에서 나왔다
목록 화면에서 검색 입력칸과 드롭다운의 테두리 색과 모서리가 달랐다. 둘 다 같은 값을 쓰도록 설계되어 있었지만, 화면 안 모든 입력칸에 기본 모양을 입히는 규칙이 더 높은 우선순위로 검색칸과 버튼을 덮어쓰고 있었다. 드롭다운만 전용 규칙이 이겨서 설계대로 나왔기 때문에 둘이 어긋나 보였다.
첫 수정에서는 검색칸을 드롭다운의 진한 회색에 맞췄다. 그러자 입력칸이 전보다 진해졌다. 원래의 연한 색을 기준으로 삼았어야 했는데, 어긋난 쪽 하나를 다른 쪽에 맞추는 데만 집중한 결과였다. 이걸 계기로 개별 값을 맞추는 대신 공통 값을 한곳에 두기로 했다.
값을 한곳에 두니 종류가 줄었다
tokens.css를 새로 만들어 높이, 테두리, 둥글기를 정의하고 모든 화면이 이 값을 쓰게 했다.
| 항목 | 이전 | 이후 |
|---|---|---|
| 조작 요소 높이 | 32·34·36·40px | 32px |
| 조작 요소 테두리 | 입력칸·버튼이 서로 다른 회색 | #c4c4c4 하나 |
| 상자 테두리 | 다섯 가지 회색 | #e3e3e3 하나 |
| 둥글기 | 4·5·6·7·10px 등 | 12·8·6px 세 단계 |
통일한 뒤에는 dev 서버 화면을 테스트 브라우저로 열고 보이는 조작 요소의 실제 적용 값을 하나씩 쟀다. 서식 도구 버튼(30px)과 이미지 순서 화살표(28px)처럼 촘촘하게 붙는 작은 버튼만 일부러 남겼다.
같은 드롭다운처럼 보였지만 다른 부품이었다
"표시할 열" 드롭다운만 바깥을 클릭해도 닫히지 않았다. 다른 드롭다운은 직접 만든 공용 부품이었는데, 이것만 브라우저 기본 <details> 요소로 따로 만들어져 있었다. 공용 드롭다운의 여러 개 선택 모드로 교체했다.
이 기회에 앱 전체의 드롭다운과 팝업을 훑었다. 동작이 다른 것은 그 하나뿐이었지만, 어디서도 쓰지 않는 예전 검색 팝업 코드가 240줄 넘게 남아 있어서 지웠다. 툴팁은 설명용 툴팁만 Polaris 말풍선으로 맞추고, 잘린 글자를 보여주는 툴팁은 브라우저 기본으로 두었다. 표 칸마다 말풍선 부품을 달면 목록이 무거워지기 때문이다.
이름과 언어
기능 설명을 이름이라고 부를 수는 없었다
메뉴 이름 "상품 작업실"은 공방 같은 물리적 공간을 떠올리게 했고, 쇼핑몰 관리 도구에서 잘 쓰는 말도 아니었다. 메뉴는 무엇을 하는 곳인지 바로 알아야 하므로 "상품 관리"로 바꿨다. 평범하지만 메뉴 이름에는 그편이 맞다고 봤다.
앱 이름은 쉽게 정해지지 않았다. 처음에는 "간편 상품 관리", "간편 상품 편집" 같은 후보를 놓고 고민했다. 그런데 나중에 공개할 수도 있다는 전제를 두니 이것들은 기능을 설명하는 말일 뿐 이름이 아니었다. Shopify 앱 스토어 요구사항에도 다른 앱과 헷갈리는 일반적인 이름은 문제가 될 수 있다는 내용이 있다.
"다른 일괄 편집 앱들은 이름을 어떻게 짓지?"
앱 스토어의 같은 분류를 찾아보니 형식이 거의 같았다. 앞에 기억하기 쉬운 고유한 단어를 두고, 뒤에 "Bulk Product Editor"처럼 영어로 기능을 붙인다. 이 형식을 따라 Editwise - Bulk Product Editor로 정했다. 미리보기와 되돌리기로 안전하게 고친다는 뜻을 담았다. 같은 이름의 Shopify 앱이 검색되지 않는 것까지는 확인했지만, 상표 등록 여부는 확인하지 않았다.
이름 하나 바꾸는 데 배포가 필요했다
shopify.app.toml의 이름을 바꾸고 dev 서버가 설정을 다시 올린 뒤에도, Shopify에 등록된 앱 이름은 2분 넘게 그대로였다. 이름은 shopify app deploy로 새 앱 버전을 올려야 바뀌는 것으로 보였다.
처음에는 배포를 미루려 했다. 앱 주소가 아직 템플릿 기본값인 example.com이라, 배포하면 dev 서버를 끈 뒤 앱이 열리지 않을 것이라고 생각했다. 하지만 dev 서버를 끄면 열리지 않는 것은 배포 여부와 관계없이 같았다. 터널 주소도 dev를 끄면 사라지고, automatically_update_urls_on_dev가 켜져 있어 dev를 다시 켜면 주소도 다시 바뀐다. 위험을 실제보다 크게 본 판단이었다.
배포는 설정을 바꾸거나 추가하는 것만 자동 승인하는 --allow-updates로 실행했다. 새 버전이 활성화된 뒤 API로 앱 이름이 바뀌었고 앱 주소와 권한은 그대로인 것을 확인했다. 배포가 끝나자 Shopify CLI가 스스로 전역 설치본을 4.8.3에서 4.9.3으로 올린 것은 예상하지 못한 부분이었다.
언어는 관리자 설정을 따르기로 했다
영어 이름을 붙이고 나니 화면이 한국어뿐인 것이 걸렸다. 앱 스토어 소개 페이지의 지원 언어에는 실제로 쓸 수 있는 언어만 적어야 한다. 방식은 셋 중에서 골랐다.
| 방식 | 장점 | 택하지 않은 이유 |
|---|---|---|
| 관리자 언어 자동 따르기 | 설정이 필요 없고 다른 앱들도 흔히 쓰는 방식 | - |
| 앱 안 언어 선택 | 관리자와 다른 언어로 쓸 수 있음 | 설정 화면과 저장소가 추가로 필요 |
| 둘 다 | 가장 유연함 | 지금 필요한 것보다 작업이 큼 |
Shopify는 앱을 열 때 사용자의 관리자 언어를 locale 값으로 넘겨준다. 이 값이 한국어면 한국어, 그 밖에는 영어로 보여주고, 값이 없으면 브라우저 언어를 본다. 번역 파일은 app/locales/ko.json과 en.json 두 개로 모았고, 라이브러리는 Shopify 문서 예시와 같은 i18next를 썼다.
번역 파일을 화면을 연 뒤 따로 내려받는 방식은 택하지 않았다. 서버가 먼저 그린 화면에도 번역이 필요해서, 나중에 받으면 잠깐 다른 언어가 보였다가 바뀐다. 대신 서버가 언어를 정하고 그 언어의 파일 하나만 첫 화면과 함께 보낸다. 앱 안에서 다른 화면으로 이동해도 처음 정한 언어를 유지하도록 루트의 재조회를 막았다.
서버는 문장 대신 코드를 보낸다
번역에서 가장 손이 많이 간 곳은 화면이 아니라 서버였다. 오류 메시지, 일괄 작업에서 건너뛴 이유, 작업 기록의 설명이 서버에서 한국어 문장으로 만들어지고 있었다. 이대로면 영어 화면에도 서버 문장만 한국어로 나온다.
export type Coded = { code: string; vars?: Record<string, string | number> };
export function codedText(t: T, value: Coded) {
return t(`codes.${value.code}`, value.vars ?? {});
}
서버는 { code, vars }만 보내고, 문장은 브라우저가 사용자 언어로 만든다. 작업 기록도 저장된 변경 내용을 그대로 내려보내 화면에서 설명을 만든다. 다만 번역 이전에 저장된 작업 결과 메시지는 저장된 문장이 그대로 보인다. 지난 기록을 다시 쓰지는 않기로 했다.
영어는 한국어보다 길었다
영어로 화면을 열자마자 문제가 두 개 보였다. 편집 패널을 열어 좁아진 필터 바에서 버튼들이 넘쳐 검색 버튼이 초기화 버튼을 덮었고, 홈 바로가기 카드는 설명이 두 줄로 넘어가면서 카드마다 제목 높이가 달라졌다. 한국어로 맞춘 배치가 더 긴 영어 문구를 견디지 못한 것이다.
좁은 배치에서만 정렬 메뉴가 먼저 줄어들고, 그래도 부족하면 버튼이 다음 줄로 넘어가게 했다. 넓은 배치의 한 줄 구성은 그대로 두었다. 카드 설명은 한 줄로 고정하고 넘치면 말줄임표로 자르게 했으며, 영어 설명 두 개는 더 짧게 고쳤다. 가장 좁은 폭에서는 흐린 배경 아이콘이 제목에 닿는 것이 아직 남아 있다.
키 누락은 테스트로 막았다. 두 언어 파일의 키와 변수 이름이 같은지, 코드에서 t("…")로 쓰는 키가 모두 파일에 있는지 검사한다. 작업 당시 코드에서 쓰는 키는 419개였다.
결과
목록은 쓰기 편해졌고, 홈은 손볼 상품을 바로 보여주는 화면이 됐다. 확인 카드에서 찾은 문제를 앱 안에서 고칠 수 있게 됐고, 앱은 이름과 두 개의 언어를 갖게 됐다.
| 이전 | 이후 |
|---|---|
| 템플릿 홈과 버튼 하나 | 확인 카드 3개, 최근 작업 표, 바로가기 4개 |
| 미게시 상품은 관리자에서 따로 게시 | 상품 편집과 일괄 수정에서 채널별 게시·해제, 기록과 되돌리기 |
| 일괄 수정은 미리보기 전까지 대상이 안 보임 | 항목을 고르는 즉시 대상 표 표시 |
| 높이 4종, 둥글기 5종 이상, 회색 여러 개 | tokens.css의 공통 값 |
인증 실패 시 Handling response 한 줄 | 메뉴를 유지한 안내 화면 |
| 상품 하나를 불러올 때 문구 한 줄 | 일괄 수정과 같은 로딩 표시 |
sh-first-app, "상품 작업실" | Editwise - Bulk Product Editor, "상품 관리" |
| 한국어만 | 관리자 언어에 따라 한국어·영어, 번역 파일 키 510개(코드에서 이름을 직접 쓰는 키 419개, 나머지는 서버 코드처럼 조립해 쓰는 키) |
검증으로는 현재 HEAD에서 전체 테스트 67개가 통과한 것을 확인했다. 번역 작업 시점에는 타입 검사, ESLint, 프로덕션 빌드가 통과했고, 빌드된 브라우저 코드에 번역 문구가 들어가지 않는 것도 확인했다. 화면은 dev 서버를 테스트 브라우저로 열어 영어와 한국어로 직접 조작했고, 서버 렌더링과 브라우저 화면이 어긋날 때 나는 경고도 없었다.
확인하지 못한 것도 많다. 판매 채널의 실제 게시 저장과 일괄 수정의 실제 적용은 스토어 데이터를 바꾸는 일이라 한 번도 실행하지 않았다. Shopify 관리자가 넘기는 locale 값의 실제 형식, "새 상품 추가" 카드의 이동, 메뉴 이동 개선 후의 체감 시간도 직접 보지 못했다. 테스트 브라우저에는 한글 글꼴이 없어서 한국어 화면의 글자 모양은 확인하지 못했다. 시계를 맞춘 뒤 실제 관리자에서 401이 다시 나오지 않는지도 아직 지켜보는 중이다. 커밋은 모두 로컬에만 있고, 아직 원격 저장소에 올리지 않았다.
느낀점
- 오류의 원인이 코드 밖에 있을 때도 있었다. 401을 보고 인증 코드부터 의심했지만, 실제로는 개발 PC의 시계가 22초 빨랐다. 토큰의 수명과 허용 오차를 숫자로 확인하고 나서야 원인을 좁힐 수 있었다.
- 확인 카드는 고칠 수단과 함께 있어야 했다. 미게시 상품을 세어주는 것만으로는 일이 줄지 않았다. 카드가 생기니 그 카드를 처리할 기능이 필요했다.
- 어긋난 값을 서로 맞추기보다 기준을 먼저 정해야 했다. 하나를 다른 하나에 맞추면 이번에는 다른 곳이 어긋났다. 공통 값을 한곳에 두고 나서야 비교할 기준이 생겼다.
- 이름은 설명과 다른 역할을 했다. 기능을 정확히 설명하는 말이 좋은 앱 이름은 아니었다. 같은 분류의 다른 앱을 보고 나서야 이름에 필요한 것이 보였다.
- 번역은 문장을 만드는 위치를 바꾸는 일이었다. 화면 문구를 옮기는 것보다 서버가 만든 문장을 코드로 바꾸는 데 더 많은 손이 갔다.
작은 화면 문제 몇 개를 고치다 보니 홈의 역할, 일괄 수정의 흐름, 공통 디자인 값, 앱 이름과 언어까지 차례로 정해야 했다. 공개를 전제로 보니 그동안 괜찮다고 넘겼던 부분이 하나씩 드러났다.
다음에는 미뤄 둔 실제 저장 흐름을 확인하고, 실제 관리자에서 영어 화면을 다시 볼 차례다. 여기까지 읽어주신 분들께 감사드리며 이번 글을 마친다.
댓글