긴 시간 동안 티스토리를 통해 블로그를 운영해 왔습니다.
중간중간 제 홈페이지를 직접 만들어 보겠다며 여러 번 사이드 프로젝트를 시작했지만, 항상 어느 순간 멈춰 버리고 흐지부지되곤 했습니다.
그러다 문득, “프론트엔드 개발자인데 나를 보여줄 수 있는 홈페이지 하나 없는 게 맞나?” 하는 생각이 머릿속에서 계속 떠나질 않았습니다. 그래서 다시 한 번 마음을 다잡고, 이번에는 끝까지 한 번 만들어 보기로 했습니다.
여러 개발자분들의 홈페이지를 둘러보며, 나만의 색을 어떻게 담아야 할지 고민했고, 그렇게 만든 나만의 홈페이지를 계기로 프로젝트를 진행하며 느꼈던 점들을 이번 글에서 정리해 보려고 합니다.
홈페이지 테마 정하기
이 프로젝트에서 가장 많은 시간을 쓴 부분은 바로 홈페이지 테마를 정하는 일이었습니다.
블로그 형식의 테마는 레퍼런스도 많고 저에게도 익숙해서, 처음에는 자연스럽게 일반적인 블로그 레이아웃으로 UI를 구성해 보기 시작했습니다.
개발 자체는 어렵지 않았습니다. 특별히 복잡한 기능이 있는 것도 아니었고, 이미 익숙한 구조라 손만 움직이면 금방 만들어지는 형태였죠.
하지만 작업을 계속하다 보니, 마음 한구석에서 이런 생각이 들었습니다.
“남들과는 조금 다른, 나만의 무언가를 만들고 싶은데… 지금 만들고 있는 건 어디서든 볼 수 있는 그냥 모던한 홈페이지 아닌가?”
결국 한 달 가까이 개발하던 블로그 형식의 홈페이지를 정리하고, 처음으로 돌아가 테마를 다시 정하기로 했습니다.
그렇게 멍하니 모니터를 보다가, 문득 바탕화면에 놓인 폴더와 프로그램 아이콘들이 눈에 들어왔습니다.
“내 홈페이지에 들어갈 Blog, Project, About을 각각 하나의 폴더라고 생각해 보면 어떨까?
그리고 내가 작성한 글들은 그 안에 들어 있는 프로그램들이라고 생각하면 어떨까?” 하는 생각이 떠올랐습니다.
이 아이디어가 마음에 들었던 이유는 몇 가지가 있었습니다.
- 이미 우리 모두가 익숙한 화면 구성(데스크톱 UI) 이라는 점
- 기본적인 레이아웃이 정해져 있어서, 제 약점인 디자인을 처음부터 다 고민하지 않아도 된다는 점
- 제가 평소에 사용하던 환경을 그대로 웹에 옮겨오기만 하면 되지만 사용하는 사람 입장에선 특별함을 느낄 수 있을 것 같다는 점
무엇보다도, 이런 형태라면 홈페이지에 방문하시는 분들이
“어? 뭔가 다르다”라고 한 번쯤은 느낄 수 있을 것 같았습니다.
물론, 한 달 동안 만들어 온 기존 블로그 형식의 홈페이지를 정리하는 건 쉽지 않은 결정이었습니다.
그래도 그 과정을 통해 제가 정말 원하는 ‘남과 다른 테마’를 찾을 수 있었고,
지금의 홈페이지를 떠올리면 그 선택이 후회되지는 않습니다.
Atomic Design Pattern 맹신론자에서 탈출
혼자 사이드 프로젝트를 진행할 때는 늘 Atomic Design을 기반으로 아키텍처를 구성해 왔습니다.
컴포넌트 중복을 줄일 방법을 고민하던 시기에 유행처럼 번졌던 패턴이었고, 도입 초기에는 폴더를 어떤 식으로 나눌지, 특정 컴포넌트를 어디에 둬야 할지 고민하는 데 시간을 꽤 많이 썼습니다.
그래도 컴포넌트를 계층적으로 나누는 개념 자체는 매력적이었고, “이건 Atom인가, Molecule인가?” 같은 고민을 하면서 자연스럽게 추상화에 대해 더 깊이 생각하게 해준 아키텍처라 애정이 생겼습니다.
그 정도로 마음에 들어서, 다른 프론트엔드 개발자분들에게도 강하게 추천할 만큼 일종의 ‘맹신자’에 가까운 상태였죠.
하지만 요구사항이 복잡해질수록 점점 발목을 잡기 시작했습니다.
Atom, Molecules, Organisms, Template, Page만으로는 도메인을 표현하거나 구조를 나누기 애매한 경우가 많았고, “이 컴포넌트는 Atom인가, Molecule인가, 아니면 Organism인가?”를 계속 고민하는 것 자체가 스트레스가 되었습니다.
물론, 더 깊이 고민해서 규칙을 정리하면 충분히 해결할 수 있는 문제일 수도 있습니다.
하지만 저는 아키텍처의 본질이 ‘개발 편의성’에 있다고 생각했고, 어느 순간부터는 이 패턴을 유지하는 데 드는 정신적 비용이 얻는 이점보다 크다고 느껴졌습니다. 그래서 이번 프로젝트를 계기로 과감히 Atomic 아키텍처를 내려놓기로 했습니다.
그렇다면 다음 아키텍처는 무엇으로 갈 것인가?
이 질문을 가지고 고민하다가, 자연스럽게 FSD(Feature-Sliced Design) 를 후보에 올렸습니다.
이미 많은 프론트엔드 개발자분들이 FSD를 긍정적으로 도입하고 있었고, 저도 관심 있게 보고 있었습니다.
다만, 제 기준에서는 Atomic도 초기에 러닝 커브가 분명히 있었는데, FSD는 그 이상으로 개념을 온전히 이해해야 하는 구조처럼 느껴졌습니다.
혼자 사용하는 아키텍처라면 FSD를 한 번 실험해 봤을지도 모릅니다.
하지만 “이걸 팀원에게 설명하고, 각 도메인의 경계를 설득력 있게 설명할 수 있을까?”를 떠올려 보니 쉽게 자신이 생기지 않았습니다.
그렇게 고민을 거듭하다가, 결국 가장 클래식한 폴더 구조로 돌아가기로 했습니다.
pages/
components/
hooks/
utils/
Atomic 패턴을 도입했던 가장 큰 이유가 중복을 줄이고, 더 잘 추상화된 컴포넌트를 만들고 싶어서였는데, 이제는 그런 고민이 어느 정도 몸에 밴 느낌입니다.
그래서 오히려 이렇게 생각하게 됐습니다.
“결국 중요한 건 폴더 이름이 아니라, 컴포넌트를 만들 때 얼마나 신경 써서 설계하느냐 아닌가?”
어떤 요소를 어디에 넣어야 한다는 규칙이 처음에는 고민을 줄여주는 장치처럼 느껴지지만,
어느 순간부터는 그 자체가 또 다른 고민거리가 될 수도 있다는 걸 이번 프로젝트를 통해 느꼈습니다.
결과적으로 이번 프로젝트는 기존에 맹신하던 Atomic 패턴을 내려놓고, 보다 단순한 구조로 회귀한 첫 번째 사례였지만, 그 선택을 후회하지 않고 만족스러운 개발 경험으로 남았습니다.
이게 정말 완벽할까? 더 이상 문제는 없을까?
“제” 홈페이지이기 때문에, 다른 사람들이 저라는 사람을 이해할 때 꽤 큰 영향을 줄 거라고 생각했습니다.
그래서 프로젝트가
localhost를 넘어 진짜 세상으로 나가는 순간이 많이 두려웠습니다.
제가 미처 발견하지 못한 버그들 때문에, 제 자신에 대한 부정적인 인상이 생길 수도 있다는 생각이 계속 마음에 걸렸습니다.사실 그게 지금까지 만들었던 여러 홈페이지 후보들을
중간에 멈춰 버리고, 결국 완성되지 못한 이유 중 하나였다고도 느낍니다.
지금도 솔직히 말하면, 이 홈페이지를 세상에 공개하는 게 완전히 편하지만은 않습니다.
아주 사소한 버그 하나, 혹은 크게 터지는 문제 하나로 홈페이지가 제 의도와 다르게 동작할 수 있다는 가능성을 알고 있으니까요.
하지만 한편으로는, 저 자신도 완벽한 사람이 아니라는 걸 잘 알고 있습니다.
허술한 부분도 있고, 부족한 점도 분명히 있습니다. 그렇다면 그걸 고치기 위해서 저는 집 안에만 있을 게 아니라, 밖으로 나가서 부딪히고, 피드백도 받고, 때로는 따끔한 말도 듣고, 또 그만큼 칭찬도 들으면서 성장해야 한다고 생각했습니다.
제 홈페이지 역시 마찬가지입니다.
제 눈에는 누구보다 애정이 가는, 재미있고 신기한 홈페이지지만 혼자만 좋다고 생각하는 것에서 끝나지 않고,많은 분들의 의견을 듣고 계속 고쳐 나간다면 더 좋은 형태로 자랄 수 있는 프로젝트라고 믿고 있습니다.
그래서 저는 이 홈페이지를
“처음부터 완벽하게 만든 뒤 세상에 내보내야 하는 결과물”이 아니라, 제가 성장하는 만큼 함께 자라는 하나의 동반자 같은 프로젝트로 두려고 합니다.
아직 이 홈페이지에 넣고 싶은 기능들도 많이 남아 있습니다.
관심을 가지고 공부하고 있는 웹 접근성을 더 잘 반영해서 누구라도 제 홈페이지를 이용할 수 있도록 만들고 싶고, Windows 바탕화면처럼 더 다양한 기능을 얹어서 조금 더 재미있는 상호작용도 넣어 보고 싶습니다.
이 모든 걸 한 번에 완벽하게 구현하는 대신,
조금씩, 하지만 꾸준히 늘려 가면서 저와 함께 천천히 성장하는 홈페이지로 만들어 가겠습니다.