woosday를 작은 도구가 있는 블로그로 키운 기록
woosday는 글과 프로젝트와 작은 도구를 한 곳에 모아 둔 개인 사이트다. 처음부터 거대한 서비스로 시작하기보다, 내가 만든 것을 공개하고 직접 사용하면서 불편한 지점을 하나씩 고치는 방식으로 확장했다.
처음 세운 기준
기술 스택은 Spring Boot 3.5.16, Java 21, Thymeleaf, Gradle이다. 글은 데이터베이스 대신 posts/의 Markdown 파일로 관리하고, 지원 자료와 오류 기록도 파일 기반으로 분리했다. 이 선택은 개인 사이트에 필요한 운영 복잡도를 낮추고 Git diff로 콘텐츠 변경을 바로 확인할 수 있다는 장점이 있었다.
대신 파일 기반 구조에서는 다음을 직접 챙겨야 했다.
- front matter의 제목·날짜·카테고리·태그 형식 유지
- Markdown HTML 렌더링 전 정화
- 새 글을 추가한 뒤 sitemap과 RSS에 자동 반영되는지 확인
- 글 목록의 카테고리·태그·검색·페이지네이션 일관성 유지
기능을 추가할 때 바꾼 것
개발 도구와 생활 도구는 단순히 개수를 늘리는 방향으로 만들지 않았다. 입력값과 결과의 역할을 분리하고, 모바일에서도 한 화면에서 다음 행동을 알 수 있게 카드와 안내 문구를 통일했다. 모임 정산기는 참석자와 차수를 동적으로 추가할 수 있도록 만들고, 차수별 참석 여부와 공지용 복사를 제공했다.
운세 기능은 사주·별자리·포춘쿠키로 나뉘어 있다. 결과를 서버에 저장하지 않고 브라우저에서 계산하는 원칙을 유지해, 생년월일이나 입력값이 서비스에 남지 않도록 했다.
운영하면서 배운 점
가장 큰 변화는 “만든 기능”보다 “다시 확인하는 과정”이었다. 모바일 320px·360px·390px 화면에서 공개 경로를 확인하고, 입력 포커스 확대와 긴 제목 줄바꿈을 점검했다. Markdown과 QR 코드처럼 외부 입력이나 외부 라이브러리가 연결되는 기능은 정상 동작뿐 아니라 CSP·정화·무결성 검증까지 함께 봐야 했다.
작은 사이트라도 공개되는 순간 운영 대상이 된다. 그래서 기능을 추가할 때 다음 질문을 기록하고 있다.
- 입력값이 서버에 꼭 필요한가?
- 실패했을 때 사용자가 다음에 무엇을 해야 하는가?
- 좁은 화면에서 같은 작업을 끝낼 수 있는가?
- 외부 스크립트와 사용자 입력을 어디까지 신뢰할 것인가?
- 나중에 다시 고칠 수 있도록 상태와 배포 방법을 문서화했는가?
다음 개선 방향
앞으로는 기능 수보다 글과 프로젝트 사이의 연결을 강화하려 한다. 도구를 만든 이유와 실패한 시도, 배포 중 확인한 지표를 글로 남기고, 글에서 실제 도구로 이동할 수 있게 연결하면 사이트를 방문한 사람이 읽고 끝나지 않고 직접 사용해 볼 수 있다.
함께 읽기: