영문 포트폴리오에 블로그 피드 추가하며 배운 다국어 지원의 함정

포트폴리오 사이트 영문 버전(/en/)에 블로그 최신글 피드 섹션을 추가했다. 단순해 보이지만, 다국어 지원하는 사이트에서 기능을 추가할 때의 전형적인 실수를 피하는 과정이었다.

당시 상황: 한국어만 있고 영문은 없었다

포트폴리오 사이트는 기본적으로 한글 버전과 영문 버전을 별도로 운영하고 있었다. 어느 순간부터 한글 메인 페이지에 "최신 블로그 포스트" 섹션이 들어갔는데, 그것을 영문 페이지에는 추가하지 않았다. 그러다 누군가(아마 나)가 영문 방문자가 보는 페이지가 한글 버전보다 너무 성글어 보인다는 피드백을 받으면서, "어? 영문 페이지도 이 기능 넣어야 하는 거 아닌가?" 하고 깨달았다.

이런 상황은 생각보다 자주 생긴다:
- 새 기능을 추가할 때 "우선 메인 버전부터"라고 시작함
- 영문/다국어 버전은 "나중에 하자"로 미루다가 자꾸 까먹음
- 결국 방문자 입장에서는 언어마다 경험이 달라지는 상황 발생

두 파일의 역할: 구조와 데이터 생성

이번 작업은 두 가지 레이어를 함께 건드렸다.

한 가지 배운 점은, 단순히 HTML에 섹션을 추가하는 것만으로는 부족하다는 것이다. 실제로 "최신글"이 어떻게 수집되고 정렬되는지 생성 스크립트를 함께 수정해야 한다. 즉:

영문 페이지에 피드 표시
  ↓
피드 데이터가 어디서 오는가?
  ↓
gen_blog_feed.py가 이를 생성해야 함
  ↓
영문 포스트 필터링/정렬 로직 추가

이 흐름을 놓치면, 결국 페이지는 있는데 항상 비어 있거나, 한글 포스트만 섞여 나오는 버그가 생긴다.

다국어 지원의 숨은 비용

포트폴리오나 블로그 같은 개인/팀 사이트에서 다국어를 지원하기로 결정하는 순간, 모든 기능에 "배로 관리해야 한다"는 책임이 생긴다.

예를 들어:
- 디자인 변경 → 한글/영문 버전 모두 수정
- 새 섹션 추가 → 양쪽 다 고려
- 스크립트 로직 추가 → 다언어 필터링 로직도 함께

실제로 대형 서비스에서는 이를 줄이기 위해:
- 템플릿 엔진(Jinja2, EJS 등) 써서 한 곳에서 관리
- i18n 라이브러리로 문자열은 분리, 구조는 공유
- CI에서 모든 언어 버전 자동 빌드 & 검증

우리 포트폴리오는 규모가 작았지만, 그래도 같은 원칙을 따랐어야 했다.

회고: 다국어 지원은 초기에 시스템으로

이 작업을 하면서 느낀 것:

1. 다국어는 "나중에"가 없다
기능을 추가할 때 한 언어만 먼저 하겠다고 하면, 대부분 나중에 까먹는다. 차라리 처음부터 "한글과 영문 동시에" 또는 "템플릿으로 동시 지원" 방식으로 설계하는 게 낫다.

2. 스크립트 로직도 다국어 고려
페이지 마크업을 수정하는 것만으로는 부족하다. 데이터를 생성하는 스크립트, DB 쿼리, 필터 로직 등이 모두 다언어를 처리해야 한다. 이 부분을 간과하면 "페이지는 이쁜데 내용이 없다"는 웃기는 상황이 생긴다.

3. 검증도 배가 된다
한 기능을 추가할 때 한글/영문 모두 잘 나오는지 확인해야 한다. 팀이 작으면 코드리뷰에서 "영문 페이지도 확인했나요?"를 체크리스트에 넣어야 한다.

지금은 이 교훈을 바탕으로, 새 기능을 제안받을 때 첫 질문이 "언어별로 모두 고려했나?"가 됐다.

🛒 이 글과 어울리는 추천 상품

• 외장SSD 쿠팡에서 보기 →
• 기계식키보드 쿠팡에서 보기 →
• 모니터 쿠팡에서 보기 →

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.