들어가며

처음 블로그를 만들 때는 기능을 붙이는 데 더 관심이 많았다. MDX가 잘 렌더링되는지, 코드 하이라이팅이 되는지, 좋아요와 댓글이 붙는지 같은 것들. 일단 내가 원하는 기능이 돌아가는지가 더 중요했다.

그런데 막상 글을 채워 넣고 직접 읽어보니 조금 다른 문제가 보였다. 기능은 있는데, 읽는 흐름이 매끄럽지는 않았다. 목차는 어느 순간 시야에서 어긋났고, 플로팅 버튼은 너무 강하게 떠 있었고, 코드블럭이나 링크 같은 작은 요소도 블로그의 분위기와 살짝 따로 놀았다.

그래서 이번에는 새 기능을 크게 늘리기보다 이미 있는 기능을 읽는 경험에 맞게 다시 정리하는 작업을 했다. 사실 말은 거창하지만, 대부분은 직접 스크롤해보면서 거슬리는 부분을 하나씩 줄인 과정에 가깝다.

목차를 다시 만든 이유

처음 목차는 데스크톱 사이드바에 붙어 있는 정도였다. 글이 짧을 때는 별 문제가 없었는데, 글이 길어질수록 현재 어디를 읽고 있는지 감이 조금씩 떨어졌다. 특히 모바일에서는 본문 중간에 목차가 들어가는 방식이 애매했다. 처음 한 번 보고 지나가면 다시 보기 어렵고, 그렇다고 계속 화면에 두기엔 공간을 너무 많이 먹었다.

그래서 모바일과 데스크톱의 목차를 아예 다르게 가져갔다.

모바일에서는 목차를 본문 안에 넣지 않고, 스크롤하면 상단에 작게 떠 있는 오버레이로 바꿨다. 기본 상태에서는 현재 읽고 있는 섹션 이름과 진행 바만 보여준다. 필요할 때 탭하면 전체 목차가 펼쳐진다.

<MobileTableOfContents items={tocItems} />

처음에는 그냥 상단에 고정하면 끝이라고 생각했는데, 실제로는 헤더와 겹치지 않게 offset을 맞추는 일이 더 중요했다. 앵커를 눌렀을 때 제목이 카드 뒤에 숨어버리면 목차가 있는 의미가 없기 때문이다.

데스크톱 목차는 sticky 대신 position: fixed 기반으로 바꿨다. sticky는 자연스럽긴 하지만, 처음 위치까지 따라 올라오는 catch-up 구간이 마음에 걸렸다. 글을 읽는 중에는 목차가 항상 같은 자리에 있는 편이 더 안정적으로 느껴졌다.

대신 fixed로 만들면 글이 끝난 뒤에도 푸터까지 따라오는 문제가 생긴다. 그래서 우측 컬럼의 placeholder를 기준으로 위치를 재고, 본문 영역 끝에서 멈추도록 했다. 목차가 길어질 때는 내부만 스크롤되게 처리했다.

const top = Math.min(DESKTOP_TOC_TOP, r.bottom - toc.offsetHeight);
 
toc.style.position = "fixed";
toc.style.top = `${top}px`;
toc.style.left = `${r.left}px`;
toc.style.width = `${r.width}px`;

조금 투박하지만 지금 구조에서는 이 정도가 딱 맞았다. 별도 라이브러리를 붙일 정도의 문제는 아니었다.

플로팅 버튼은 덜 튀게

좋아요, 댓글, 맨위로 버튼은 글을 읽는 동안 계속 따라다니는 요소다. 그래서 작아 보여도 체감이 크다. 이전 버튼은 진한 원형 버튼이라 기능은 잘 보였지만, 글보다 버튼이 먼저 보이는 순간이 있었다.

이번에는 중앙 하단에 유리 질감의 알약 형태로 바꿨다. 좋아요와 댓글은 한 덩어리로 묶고, 맨위로 버튼만 우하단에 따로 뺐다.

const glass = "bg-warm-bg/80 shadow-lg shadow-black/5 backdrop-blur-md";

좋아요 수는 알약 안에 같이 보여주게 했다. 숫자를 따로 크게 강조하고 싶지는 않았고, 버튼을 눌렀을 때 상태를 확인할 수 있는 정도면 충분했다.

스크롤 동작도 조금 손봤다. 아래로 읽어 내려갈 때는 버튼이 사라지고, 멈추면 반투명하게 돌아오고, 다시 위로 올리면 또렷하게 보이게 했다. 댓글 영역에 도착하면 중앙 알약은 숨긴다. 이미 댓글 위쪽에 좋아요 버튼을 하나 더 두었기 때문에 같은 기능이 계속 떠 있을 필요가 없었다.

이 부분은 구현보다 기준을 정하는 게 더 어려웠다. 버튼은 편해야 하지만, 글을 가리면 안 된다. 지금은 “필요할 때 보이고, 읽을 때는 빠지는” 쪽으로 맞췄다.

헤더는 읽는 중이라는 느낌을 주고 싶었다

헤더도 조금 바꿨다. 글을 읽다 보면 상단의 sngchn.blog 로고보다 지금 어느 섹션을 읽고 있는지가 더 유용할 때가 있다. 그래서 xl 이상 화면에서는 글을 일정 이상 스크롤하면 로고 자리에 현재 섹션 경로가 들어오게 했다.

sngchn.blog → 현재 섹션 경로

예를 들면 이런 식이다.

목차를 다시 만든 이유 › 데스크톱 목차

이 경로는 글 제목 h1은 제외하고, 본문 안의 h1부터 h4까지를 훑어서 만든다. 글마다 헤딩 구조가 완전히 같지는 않을 수 있기 때문에, 특정 레벨 하나에만 묶지 않았다.

처음에는 헤더에 이것저것 넣다 보니 애니메이션이 어색했다. 네비게이션이 사라질 때는 괜찮은데 다시 나타날 때 밀리는 느낌이 있었고, 햄버거 버튼이 생기면서 주변 요소를 살짝 밀기도 했다.

결국 햄버거는 absolute로 빼서 레이아웃을 밀지 않게 했다. 검색 버튼도 읽기모드에서 알약에서 원형으로 줄어드는데, radius가 바뀌면서 끊기는 느낌이 있어 처음부터 rounded-full을 유지하도록 정리했다.

이런 건 코드로 보면 작은 차이인데, 실제 화면에서는 꽤 크게 느껴진다. 애니메이션은 뭔가를 많이 넣는 것보다, 안 밀리고 안 튀는 쪽이 더 중요했다.

코드블럭과 링크의 작은 디테일

코드블럭도 다시 봤다. 이전에는 복사 버튼이 hover에 의존하거나, 상태를 보여주는 방식이 조금 무거웠다. 지금은 복사 버튼을 항상 보이게 하고, 아이콘만 남겼다. 보더도 제거했다. 성공과 실패는 색상으로만 표시한다.

.code-copy-button {
  border: 0;
  background: transparent;
}

개발 블로그에서 코드 복사는 자주 쓰는 기능이다. 숨겨두기보다 그냥 늘 보이는 편이 낫다고 판단했다. 대신 버튼 자체는 최대한 조용하게 만들었다.

링크도 손봤다. 본문 링크는 연한 언더라인을 기본으로 두고, 외부 링크에는 ↗ 표시를 붙였다. PC에서는 링크에 hover하면 커서를 따라 URL 툴팁이 뜬다. 길면 말줄임으로 잘린다.

사실 URL 툴팁은 없어도 되는 기능에 가깝다. 그래도 블로그 글을 읽다가 링크를 누르기 전에 어디로 가는지 살짝 확인할 수 있는 건 나쁘지 않았다. 새 의존성을 붙일 정도는 아니라서 DOM으로 가볍게 처리했다.

레이아웃은 넓히되 본문은 그대로

글 페이지의 전체 컨테이너는 max-w-7xl로 넓혔다. TOC를 오른쪽에 안정적으로 두려면 바깥 공간이 더 필요했다.

하지만 본문 자체는 max-w-[50rem]를 유지했다. 글줄이 너무 길어지면 읽기 힘들다. 화면을 넓히는 것과 본문을 넓히는 것은 다른 문제였다.

<main className="max-w-7xl mx-auto px-4 sm:px-6 py-16 relative">
  <article className="mx-auto w-full max-w-[50rem]">
    ...
  </article>
</main>

기존 상단 reading-progress bar는 제거했다. 모바일 TOC에도 진행 바가 있고, 데스크톱 TOC도 현재 위치를 보여준다. 같은 정보를 여러 곳에서 반복할 필요는 없었다.

마치며

이번 작업은 “기능 추가”라기보다 “덜 거슬리게 만들기”에 가까웠다. 목차, 헤더, 플로팅 버튼, 코드블럭, 링크 모두 이미 있던 요소다. 다만 글을 읽는 동안 어디에 있어야 하는지, 얼마나 보여야 하는지, 언제 사라져야 하는지를 다시 맞췄다.

블로그는 결국 글을 읽는 곳이다. 기능이 많은 것보다 읽는 흐름을 방해하지 않는 게 더 중요하다는 걸 다시 느꼈다. 특히 개인 블로그는 내가 만든 기능을 자랑하고 싶어지기 쉬운데, 막상 읽는 사람 입장에서는 조용히 제 역할만 하는 UI가 더 편하다.

아직 더 고칠 부분은 많다. 검색은 제목과 태그 중심이라 본문 검색이 아쉽고, 좋아요도 Redis 기반이라 언젠가는 GitHub Discussions와 더 잘 엮을 방법을 고민해볼 수 있다. 그래도 지금은 일단 글을 읽는 경험이 이전보다 훨씬 자연스러워졌다.

다음에는 블로그 자체보다는, 이 블로그에 올릴 프로젝트 글을 더 채워볼 생각이다. 블로그를 계속 만지기만 하면 글을 쓰려고 만든 도구가 다시 프로젝트가 되어버리니까.