VAT 폼 하나로 하루를 다 보냈다
목차
vat 폼 작업이라고 처음 티켓을 받았을 때는 드롭다운 옵션 몇 개 손보는 거라고 생각했다. 특정 기간 고정값으로 박혀 있던 선택지를, 전 기간 기존값에서 동적으로 뽑도록 바꾸는 것 - 아무리 봐도 한두 시간이면 끝날 일처럼 보였다.
근데 이런 게 항상 그렇다. 드롭다운 하나가 풀리니까, 나머지 필드들이 전부 눈에 밟혔다. 사용처, 용도, 결제자, 내용 - 전부 텍스트 자유입력으로 방치돼 있었다. 매번 조금씩 다른 표현으로 같은 값을 입력하게 돼서, 나중에 집계할 때마다 중복 처리가 따로 필요했던 구조다. 이번 기회에 전부 실제 select로 바꿨다.
패턴은 "기존값 목록에서 고르되, 없으면 직접 입력"이다. UX 쪽에서 combobox라고 부르는 형태인데, VAT 데이터처럼 반복 입력이 많은 폼에 특히 잘 맞는다. 자주 쓰는 값은 클릭 한 번으로 끝나고, 처음 나오는 값은 타이핑해서 넣으면 다음번엔 선택지로 올라온다. 별도 마스터 테이블을 관리하지 않아도, 데이터 자체가 자연스럽게 사전이 된다. 입력할수록 편해지는 구조라서 쓰다 보면 효과를 체감하는 타입이다.
구현하고 나서 보니 기존에 구글시트 UI를 통해 입력받던 부분이 사실상 redundant해졌다. 그냥 걷어냈는데 없어도 전혀 아쉽지 않았다. 오히려 왜 이걸 지금까지 붙여뒀나 싶었다. 레거시를 제거했을 때 허전하지 않고 홀가분한 느낌이 오면, 그게 정답이다.
git에 실행비트 빠뜨리는 실수
동기화 래퍼를 짰다. 10분 cron으로 구글시트 pull-push를 도는 셸 스크립트다. 로컬에서 테스트할 때는 아무 이상 없이 돌았다. 배포하고 나서 permission denied가 떴을 때 바로 원인이 떠올랐다. 실행비트.
# 실행비트를 git에 포함해서 커밋
git update-index --chmod=+x scripts/sync_vat.sh
git commit -m "fix: add execute permission to sync script"
로컬에선 내가 직접 chmod +x를 했으니까 돌아가는 거고, core.fileMode를 추적하지 않는 환경에선 서버에 올라갈 때 비트가 날아간다. git ls-files --stage로 보면 100644(실행비트 없음)와 100755(있음)로 구분되는데, 배포 전에 이걸 한 번만 확인했어도 됐다.
# 배포 전 확인
git ls-files --stage scripts/sync_vat.sh
# 100644 이면 +x 없음 → 문제
# 100755 이면 있음 → OK
작은 실수인 건 알겠는데, 배포 후에 발견하면 항상 좀 쪽팔리다. 이번엔 배포 체크리스트에 "셸 스크립트 실행비트 확인" 한 줄 박아뒀다. 같은 실수를 두 번 하는 건 의지 문제가 아니라 구조 문제라서, 체크리스트로 막는 게 맞다.
셸 스크립트를 git으로 관리하다 보면 이 함정에 한 번씩 빠진다. 특히 맥에서 개발하고 리눅스 서버에 배포하는 흐름에선, 로컬 테스트가 통과했다는 게 아무 보증이 안 된다. core.fileMode=false로 설정된 저장소거나, 윈도우 개발자가 섞인 팀이라면 더 자주 만난다. 래퍼 스크립트 하나라면 단순한 문제지만, 여러 스크립트가 얽힌 배포 파이프라인에서 이게 터지면 디버깅이 생각보다 귀찮아진다.
SEO 문서 정리 - 지금 안 하면 몇 달 뒤에 내가 다시 헤맨다
오후엔 코드를 안 건드리고 문서 쪽을 정리했다. PV, GSC(구글 서치 콘솔), 색인, 발행, 애드센스 관련 메모들이 여기저기 흩어져 있었는데, 볼 때마다 뭐가 최신인지 확인이 안 됐다. 계속 같은 맥락에서 헷갈림이 생겼고, FAQ 형태로 단일 문서에 모아뒀다.
| 항목 | 정리 전 | 정리 후 |
|---|---|---|
| PV / GSC 구분 | 혼용, 뒤섞임 | 각각 정의 + 용도 구분 명시 |
| Indexing API | stale 항목 포함, '포기됨' 표시 | 유효 항목만 남기고 deprecated 표기 |
| 애드센스 관련 | 별도 파일에 산재 | FAQ 단일 문서로 통합 |
Indexing API 항목 중에 '포기됨'으로 표시된 stale 항목이 몇 개 있었는데, 그냥 두면 나중에 누군가 - 아니면 미래의 나 - 가 그걸 보고 유효한 정보로 착각할 수 있으니까 정정했다. 문서에서 stale 항목이 특히 위험한 이유가 이거다. 코드는 실행하면 틀렸다고 바로 피드백이 오는데, 문서는 틀려도 아무 일이 안 일어난다. 그래서 더 빠르게 썩는다.
이 작업이 코드 작업보다 가치 있냐고 물으면 솔직히 모르겠다. 단기 결과물이 없으니까. 근데 같은 맥락에서 같은 걸 다시 조사하느라 시간 쓴 기억이 있어서 이번엔 그냥 했다. 일종의 미래의 나한테 쓰는 비용이다. 시간이 좀 아까워도 해두면 나중에 반드시 본전은 나온다.
psy 쪽은 daily 테스트 자동생성이 돌아서 커밋 하나 올라간 게 전부고, 손댄 건 없다. 그냥 정상적으로 돌아가고 있다는 것만 확인했다.
vat 폼은 이제 꽤 쓸 만한 형태가 됐다. 내일은 다른 영역을 보고 싶은데, 아직 남은 vat 이슈가 있는지 아침에 먼저 확인해봐야 할 것 같다. "이제 됐다"고 생각했을 때 항상 하나 더 남아 있더라.
댓글 0
첫 댓글 달아줘.