Role

Full-Stack Engineer

웹사이트 디자인, 설계, 구현, 유지보수

Platforms

Web

Date

2025.09

Github

https://github.com/reo91004/thumbnail-maker

사진을 클릭하면 서비스로 이동합니다.

🖥️ 시작하며

콘텐츠가 범람하는 시대다. 불과 1~2년 전까지만 하더라도 개발자들 사이에서도 기술 블로그(Velog, Tistory 등)나 유튜브를 통한 지식 공유가 활발했고, 물론 지금도 활발한 편이다. 취업 포트폴리오로도 다들 쓰는 편이었고. 또한 본인은 개발자의 덕목이 정보의 공유라고 생각하기 때문에 나도 티스토리, 노션에 지속적으로 포스팅을 했었다.

아, 사족이지만 요즘엔 생성형 AI 때문에 포스팅의 의미가 크게 퇴색된 느낌이 난다. 그러한 기조이기도 하고.

다시 돌아와서, 이렇게 포스팅을 할 때 가장 불편하고 고민이 많이 되던 점이 “썸네일을 어떻게 하지?” 였다. 기존에는 이분의 서비스를 사용했었는데, 최근 다시 사용하려 하니 오류가 많이 뿜어져나와 이 김에 새로 만들자는 생각을 하게 됐다. 어차피 간단한 기능만 필요했고, 저 분의 방식이 맘에 들었어서 많이 차용했다.

💥 트러블 슈팅?

개발 과정에서 마주친 가장 큰 기술적 난관은 ‘사용자 경험(UX)을 위한 줌(Zoom) 기능과 렌더링 좌표계의 충돌’ 문제였다.

• 문제 상황: 사용자의 편의를 위해 캔버스 확대/축소 기능(transform: scale)을 구현했다. 하지만 html2canvas로 이미지를 추출할 때, 화면에 축소된 상태 그대로(저해상도 혹은 잘린 형태) 캡처되거나, 드래그 앤 드롭 시 마우스 커서와 요소의 이동 거리가 scale 비율만큼 어긋나는 현상이 발생했다.
• 원인 분석: react-rnd는 화면의 픽셀 좌표를 기준으로 동작하지만, CSS transform이 적용된 컨테이너 내부에서는 좌표 계산 로직이 왜곡되었다. 또한 html2canvas는 뷰포트에 보이는 DOM의 현재 상태를 스냅샷으로 찍기 때문에 오류가 발생했다.
• 해결은?:
  1. 좌표 보정: 드래그 이벤트 발생 시 scale 팩터를 역연산하여 실제 이동 거리를 보정하는 로직을 추가해야 했다.
  2. 캡처 전략: 이미지 저장 시에는 순간적으로 캔버스의 scale을 1로 원복하거나, html2canvas의 옵션(scale, windowWidth)을 조절하여 고해상도 원본 크기로 렌더링되도록 처리 흐름을 제어했다.

📝 아쉬웠던 점, 향후 계획

프로젝트는 성공적으로 배포되었지만, 몇 가지 아쉬움이 남는다.

1. 성능 최적화: 처음 웹 진입 후 새로고침하지 않을 시, 글 상자가 이상한 곳으로 배치되는 오류가 존재하지만 사실 혼자 쓰려고 개발한 거라 아직 건드리진 않았다.
2. 실행 취소/다시 실행 (Undo/Redo): 히스토리 관리가 구현되지 않았다. useReducer나 별도의 커맨드 패턴(Command Pattern)을 도입하여 상태 스냅샷을 관리하는 기능을 추가할 계획이 있다.
3. 스마트 가이드 심화: AlignmentGuides.js를 통해 기본적인 정렬 가이드는 구현했으나, 요소 간 자석처럼 붙는(Snapping) 기능은 더욱 정교한 수학적 계산이 필요하다. 이것까지 구현하긴 좀 힘들지 않을까 싶다.