자동화 파이프라인8 분 읽기

영어 계정에서 일부러 뺀 띠는 사실 돌리면 크래시 나는 경로였다

운세 데일리 포스트를 영어 계정으로 넓히면서 띠 축은 서구권에 안 맞는다는 판단으로 뺐습니다. 이후 꿈해몽 축을 추가하면서 영어 띠를 다시 붙여 보니, 띠 이름 테이블에 영어 키가 없어서 그 경로는 원래 크래시가 나는 상태였습니다. 판단으로 뺐다고 생각한 축이 코드에서는 아예 돌 수 없는 축이었던 셈입니다.

#instagram#localization#i18n#automation#content-pipeline
영어 계정의 운세 축 목록에서 띠가 빠져 있고, 그 아래 띠 이름 테이블의 영어 칸이 비어 있어 크래시로 이어지는 흐름을 그린 다이어그램
판단으로 뺐다고 생각한 영어 띠 축은, 이름 테이블에 영어 키가 없어 원래 돌 수 없는 경로였습니다.

판단으로 뺀 줄 알았던 축

운세 데일리 포스트를 한국어·영어·일본어 계정으로 동시에 발행하도록 넓히면서, 로케일마다 다루는 축을 다르게 정했습니다. 한국어는 전체 축, 일본어는 별자리와 띠, 영어는 별자리만. 띠와 사주는 서구권 독자에게 맞지 않는다고 판단해서 영어에서는 뺐습니다.

그 결정을 내릴 때 저는 그게 콘텐츠 판단이라고만 생각했습니다. 측정이 아니라 판단이라는 점은 알고 있었고, 나중에 데이터를 보고 되돌릴 수 있는 선택이라고 여겼습니다.

그런데 이번에 꿈해몽 축을 새로 붙이면서 영어 띠도 같이 열어 보니 사정이 달랐습니다. 영어 계정에서 띠를 발행하려고 하면 크래시가 나는 상태였습니다. 띠 이름 테이블(ZOD_NAME)에 영어 키가 없었고, 캡션 문구(STR)와 해시태그(TAGS)에도 띠 축의 영어 항목이 없었습니다.

당신의 프로젝트에서 '이 언어에서는 이 기능을 안 쓴다'고 정해 둔 곳이 있다면, 그건 정말 안 쓰기로 한 건가요, 아니면 써 보면 터지는 곳인가요?

왜 그동안 아무 일도 없었나

영어 계정의 발행 대상에 띠가 없었으니, 평소 루프가 그 경로를 지나갈 일이 없었습니다. 로케일별 이름 테이블은 키가 빠져 있어도 그 키를 실제로 찾기 전까지는 아무 말도 하지 않습니다. 빠진 매핑은 조용하고, 조용한 이유가 '아무도 안 불러서'일 뿐입니다.

그래서 '영어에서는 띠를 안 한다'는 문장은 두 가지 의미를 동시에 갖고 있었습니다. 겉으로는 콘텐츠 판단이었고, 실제로는 '영어 띠는 돌릴 수 없다'는 코드 상태였습니다. 나중에 성과를 보고 판단을 되돌리려 했다면, 그 순간 처음 마주치는 건 크래시였을 겁니다.

꿈해몽 축은 왜 싸게 붙었나

이번 커밋의 본래 목적은 꿈해몽이라는 새 콘텐츠 축이었습니다. 검색이 많은 상징 8개(뱀·이빨·물·돈·똥·불·아기·돼지)를 DREAM_KEYS로 정하고, 각 상징의 해석을 ko/en/ja 세 언어로 데이터셋에 넣었습니다. 내용은 재미·참고용으로 다룹니다.

렌더는 새로 만들지 않았습니다. spec_dream은 기존 운세 레이아웃을 그대로 재사용하고, 운세 문구 자리에 해몽을, 행운 칩 자리에 해몽과 '오늘의 행운' 관용 표현을 넣습니다. 대상 지정은 dream:<symbol>로 특정 상징을 고르거나 dream:rotate로 돌리게 했고, STR/TAGS에 dream 축을 추가했습니다. 캡션에 붙는 라벨이 로케일 이름으로 나오도록 _disp_name에도 dream 처리를 넣었습니다.

변경은 generate.py 64줄 추가, post_daily.py 10줄 수정 정도였습니다. 레이아웃을 재사용했으니 새 축의 비용은 거의 데이터 쪽에 있었습니다.

같은 자리에서 영어 띠를 열다

꿈해몽 축을 넣으려면 어차피 STR/TAGS의 축 목록을 손대야 했습니다. 그 자리에서 띠 축의 영어 칸이 비어 있는 게 보였습니다.

당신이라면 이번 작업 범위가 아니니 꿈해몽만 넣고 지나가겠습니까, 아니면 판단으로 막아 둔 축을 같은 김에 '돌 수 있는 상태'로 만들어 두겠습니까?

저는 후자를 택했습니다. ZOD_NAME에 영어 이름(Rat부터 Pig까지 12개)을 넣고, STR/TAGS의 띠 축에 en을 추가했습니다. 이걸로 영어 계정에서도 띠 발행이 가능해졌고, 이전의 크래시는 해소됐습니다. 영어에서 띠를 실제로 올릴지는 여전히 별개의 판단이지만, 적어도 이제 그 판단은 코드 사정이 아니라 콘텐츠 사정으로만 내릴 수 있습니다.

검증은 테스트 19개 통과, 그리고 en/ja × 띠/꿈 4개 조합을 렌더해서 눈으로 확인한 것입니다.

자가진단 체크리스트

  • 로케일별로 '이 기능은 안 쓴다'고 정해 둔 곳마다, 그 조합을 강제로 한 번 돌려 봤을 때 끝까지 렌더되는지 확인한 적이 있나요?
  • 이름·라벨·해시태그 같은 로케일 매핑 테이블에서 모든 축 × 모든 로케일 조합의 키가 채워져 있는지 검사하는 장치가 있나요?
  • 새 콘텐츠 축을 붙일 때 레이아웃을 새로 만들지 않고 기존 스펙의 슬롯(문구, 칩)에 데이터만 갈아 끼울 수 있는 구조인가요?

솔직한 부분

이번 커밋이 건드린 파일은 generate.py와 post_daily.py 두 개뿐이고, 테스트 수는 이전과 같은 19개입니다. 즉 영어 띠 크래시를 다시 잡아낼 테스트는 이번에 추가하지 않았고, 확인은 4개 조합을 눈으로 본 것까지입니다. 다른 축 × 로케일 조합에 같은 식으로 빈 키가 남아 있는지는 전수로 확인하지 않았습니다. 꿈해몽 8개 상징을 고른 기준은 '검색이 많은 상징'이라는 것까지이고, 이 축이 실제 계정에서 어떤 반응을 얻을지, 영어 계정에서 띠를 다시 켤지는 이 기록 시점에는 모릅니다.

관련 글