블로그 방문자가 글을 다 읽은 시점은 ‘이탈’과 ‘체류’가 갈리는 중요한 순간이다. 독자가 다음 콘텐츠로 자연스럽게 흐르도록 유도하기 위해 내비게이션 시스템을 설계했다. 단순히 링크를 거는 것을 넘어, 사용자 경험(UX)과 기술적 제약 사항을 어떻게 해결했는지 회고해 본다.

1. 내비게이션 레이아웃의 진화 (Staircase -> Flex Row)

처음에는 Prev(이전) 버튼은 왼쪽, Next(다음) 버튼은 오른쪽에 배치하되, 서로 다른 수직 레벨에 위치하는 ‘계단식(Staircase)’ 레이아웃을 시도했다. 시각적 재미를 주기 위함이었으나, 실제 테스트 결과 두 가지 문제가 발견되었다.

1. 공간 낭비: 수직 공간을 과도하게 차지하여 본문 하단이 불필요하게 길어졌다.
2. 시선 분산: 사용자의 시선이 좌우 위아래로 널뛰기하여 직관성이 떨어졌다.

결국 수평(Row) 배치로 회귀했다. Flexbox의 justify-content: space-between을 사용하여 양 끝에 배치하되, 동일한 수직 선상에 두어 안정감을 주었다. 또한 Light Mode에서의 시인성 문제를 해결하기 위해, 배경색을 조건부로 변경하는 미디어 쿼리를 추가했다. 이는 다크 모드 중심 설계에서 놓치기 쉬운 ‘대비(Contrast)’ 문제를 보완한 조치다.

2. 정적 사이트에서의 추천 알고리즘 한계

Jekyll은 정적 사이트 생성기(SSG)이므로, DB 쿼리를 날려 ‘연관 게시글’을 동적으로 가져올 수 없다. 따라서 빌드 타임에 Liquid 템플릿 언어로 연산해야 한다.

구현한 로직은 다음과 같다:

1. 필터링: 현재 글을 제외한다.
2. 교집합 연산: 모든 포스트를 순회하며 현재 글과 카테고리가 겹치는지 확인한다.
3. 카운팅 & 중단: 루프를 돌며 카운터를 증가시키고, 3개가 차면 멈춘다(Liquid 한계로 break가 쉽지 않아 조건문으로 제어).

이 방식은 포스트 수가 수천 개가 되면 빌드 시간이 느려질 수 있는 O(N^2)(전체 페이지 생성 시)에 가까운 로직이다. 추후 포스트가 많아지면 JavaScript를 이용한 클라이언트 사이드 렌더링이나 관련 플러그인 도입을 고려해야 한다.

3. 개발 워크플로우 실수와 배운 점

작업 도중 CSS가 적용되지 않는 이슈로 시간을 허비했다. 원인은 단순했다. _layouts/post.html은 post.css를 참조하고 있었는데, 나는 습관적으로 blog.css를 수정하고 있었다.

이는 ‘관심사의 분리(Separation of Concerns)’가 파일 단위로 명확히 되어있음에도, 개발자의 습관이 이를 따라가지 못해 발생한 휴먼 에러였다. 이번 경험을 통해 파일 구조와 의존성을 먼저 파악하고 코딩에 들어가는 습관의 중요성을 다시금 깨달았다.