Home 기술 의사결정
Home은 단순한 첫 화면이 아니라, 사용자가 루다 로그의 분위기와 탐색 방식을 자연스럽게 이해하도록 만드는 공간을 목표로 제작하였다.
Landing Runtime 구조
Home에서 가장 중요하게 생각한 것은 프로젝트와 이력을 단순 나열하는 것이 아니라, 사용자가 자연스럽게 루다 로그 내부를 탐색하도록 만드는 흐름이었다.
따라서 과거 CRT 모니터에서 볼 수 있었던 색감이나, 창 닫기 버튼의 동작 방식 같은 작은 요소까지도 실제 시스템 내부를 탐색하는 듯한 분위기를 만드는 방향으로 구성하였다.
또한 자동 배포 구조를 활용하여 다른 프로젝트의 코드 정보가 자동으로 반영되도록 구성하였으며, 단순 정적 페이지보다는 실행 중인 아카이브 시스템처럼 보이도록 설계하였다.
[1]초기에는 사이트 진입 전 분위기를 형성하기 위해 별도의 시작 화면 구조를 고려하기도 하였다.
하지만 루다 로그는 모바일 앱보다는 웹 기반 탐색 흐름에 가까웠기 때문에, 독립적인 시작 화면은 전체 구조와 어울리지 않는다고 판단하였다.
이후 해당 구조는 Popup 기반 안내 방식으로 변경되었다.
자세한 내용은 Popup System 도입 파트에서 이어서 다루게 된다.
CMD 스타일 UI 방향
루다 로그에서 가장 중요하게 생각한 CMD 스타일 UI의 요소는 색감과 글꼴이었다.
초기에는 실제 개발 로그처럼 보이는 강한 터미널 스타일을 고려하였다.
하지만 루다 로그는 개발자만 사용하는 사이트가 아니라, 비개발 직군 사용자 역시 함께 탐색하는 포트폴리오이기 때문에 정보 접근성을 함께 고려해야 했다.
따라서 완전히 영어 중심의 로그 구조 대신, 한글 기반 안내 구조를 함께 도입하였다.
또한 초기에는 검은 화면과 초록색 출력 중심의 구성도 사용하였으나, 가독성이 낮다는 문제가 존재하였다.
이후 사이트 전체 분위기와 통일감을 맞추기 위해, 다크모드에서는 사막의 모래색 계열을 중심으로 색상을 다시 구성하였다.
마지막으로 단순 시각 효과를 넘어서, 작은 동작 역시 실제 시스템처럼 느껴지도록 구성하고자 하였다.
예를 들어 CMD 화면에서 닫기 버튼을 누를 경우, 단순히 창이 사라지는 것이 아니라 곧바로 Workspace 화면으로 이어지도록 흐름을 설계하였다.
[2]초기 구조에서는 실제 개발 로그와 매우 유사한 형태를 사용하였다.
하지만 해당 방식은:
- 아카이브 중심의 분위기와 충돌하고
- 사이트 전체의 테마가 분리되어 보이며
- 비개발자에게는 접근 장벽이 높다는 문제
가 존재하였다.
이후 루다 로그에서는 "실제 개발 화면"보다는 "누구나 탐색 가능한 기록 공간"에 가까운 방향으로 UI를 수정하게 되었다.
P5.js 반응형 연출
p5.js는 일반적인 프론트엔드 개발에서는 비교적 드물게 사용되는 라이브러리이다.
해당 라이브러리는 미디어아트 관련 프로그래밍 수업을 통해 처음 접하게 되었으며, 루다 로그 특유의 분위기와 움직임을 표현하기에 적합하다고 판단하여 도입하였다.
특히 Home과 루다로타에서는:
- 배경 입자 효과
- 부유하는 움직임 연출
- 마우스 움직임에 따른 반응
- 클릭에 따른 화면 변화
등을 구현하는 데에 활용되었다.
[3]물론 일반적인 애니메이션 라이브러리만으로도 유사한 효과를 구현하는 것은 가능하다.
하지만 루다 로그에서는 단순히 화면이 움직이는 것보다, 사용자의 행동에 공간이 반응하는 경험을 중요하게 생각하였다.
예를 들어:
- 마우스를 움직이면 입자가 흩어지거나
- 특정 공간에 가까워지면 분위기가 달라지고
- 클릭에 따라 화면의 흐름이 이어지는 방식
등을 통해, 단순 정적 페이지보다는 살아있는 아카이브 공간처럼 느껴지도록 구성하고자 하였다.
결과적으로 p5.js는 단순 시각 효과를 위한 도구가 아니라, 루다 로그 전체의 분위기와 탐색 흐름을 보조하는 역할로 사용되었다.
Popup System 도입
루다 로그에서 가장 중요하게 생각한 요소 중 하나는 전체적인 테마의 일관성이었다.
루다 로그는:
- 금지된 기록을 탐색하는 듯한 분위기
- 타로 기반 기록 해석 구조
- CMD 스타일 실행 화면
- 운영체제 형태를 참고한 Workspace UI
등을 통해, 하나의 세계관처럼 동작하도록 설계되었다.
하지만 이러한 구조는 사용자가 흐름을 이해하지 못할 경우, 탐색 경험 자체가 크게 달라질 수 있다는 단점 역시 존재하였다.
[4]물론 참여형 예술과 UX 설계는 서로 다른 영역이다.
하지만 사용자가 구조와 맥락을 충분히 이해하지 못했을 때, 의도와 전혀 다른 경험으로 이어질 수 있다는 점에서는 공통점이 존재한다고 생각하였다.
루다 로그는 예술 작품이 아니라 실제 포트폴리오 사이트이기 때문에, 사용자가 구조를 이해하지 못한 채 이탈하는 경험은 치명적일 수 있었다.
따라서 사용자가 현재 어떤 공간을 보고 있는지, 어떤 방식으로 탐색해야 하는지를 자연스럽게 이해할 수 있도록 초기 안내용 Popup 구조를 도입하였다.
[5]초기 단계에서는 Alert와 Toast 구조 역시 사용해보았다.
하지만 Toast는 짧은 상태 전달에는 적합했으나, 사이트 전체의 분위기와 탐색 방식을 설명하기에는 정보량이 부족했다.
또한 Alert는 일반적으로 경고나 오류 전달에 가까운 느낌이 강하다고 판단하였다.
반면 Popup은:
- 사용자의 흐름을 잠시 멈추고
- 현재 공간의 성격을 설명하며
- 다음 탐색 행동을 유도하는 역할
에 더 적합하다고 보았다.
결과적으로 Popup은 단순 공지창이 아니라, 루다 로그 전체 탐색을 위한 안내 구조에 가까운 역할로 사용되었다.
Overlay Runtime 구성
루다 로그에서는 전반적으로 Overlay 기반 구조를 자주 사용하였다.
사용자가 단순히 다른 페이지로 이동하는 것이 아니라, 현재 탐색 중인 공간 위에 새로운 기록이 열리는 감각을 중요하게 보았기 때문이다.
[6]대표적으로:
루다로타내부 공간 이동- Home 진입 시 CMD Overlay
등이 이러한 구조에 해당한다.
일반적인 페이지 이동은 사용자 입장에서 단순 URL 변경이 아니라, 사이트 전체가 갑자기 바뀌는 경험처럼 느껴질 수 있다.
특히 루다 로그처럼:
- 아카이브 시스템
- 터미널 화면
- Workspace UI
등 특정한 분위기와 흐름을 유지해야 하는 구조에서는, 페이지 전환 과정에서 몰입감이 쉽게 끊어진다고 판단하였다.
따라서 주요 탐색 흐름에서는 현재 공간의 분위기를 유지한 채, 새로운 화면을 덧씌우는 방식의 Overlay 구조를 적극적으로 사용하였다.
[7]특히 Home에서는 사용자가 자연스럽게 사이트의 탐색 방식에 익숙해지도록 흐름을 설계하였다.
CMD Overlay에서 닫기 버튼을 누르면 곧바로 Workspace 화면이 나타나도록 구성한 이유 역시, 단순 첫 화면의 역할을 넘어서 사이트 전체의 구조와 탐색 흐름을 자연스럽게 이해시키기 위함이었다.
또한 사용자가 "잘못 클릭하면 망가질 것 같은 사이트"로 느끼지 않도록, 탐색 자체에 대한 부담을 줄이고 다음 행동에 대한 호기심을 유도하는 방향 역시 함께 고려하였다.
기술 스택 선정 이유
루다 로그는 도큐사우루스(Docusaurus)와 React를 중심으로 제작되었다.
도큐사우루스를 선택한 가장 큰 이유는 문서를 중심으로 한 구조를 빠르게 구성할 수 있었기 때문이다.
[8]특히 WIKI테마의 경우 압도적인 생산적 편리성을 자랑하였다. 기존에 사용하던 깃허브 블로그의 경우 하위 카테고리나 검색기능을 직접 구현하였지만, 도큐사우르스에서는 이미 해당 기능들이 모두 테마 형태로 제공된다.
또한 React 기반으로 동작하기 때문에, 일반적인 블로그 형태를 넘어서:
- Workspace UI
- Overlay 구조
- 터미널 스타일 화면
등을 자유롭게 함께 구성하기에 적합하다고 판단하였다.
프론트엔드에서 React를 사용한 이유 역시 도큐사우루스와의 높은 호환성 때문이었다.
[9]p5.js를 선택한 이유 역시 비슷하다.
three.js처럼 높은 학습 난도를 가진 구조보다, 루다 로그의 분위기를 유지하면서도 빠르게 원하는 연출을 구현할 수 있는 방향을 우선적으로 고려하였다.
GitHub Actions는 배포 자동화를 위해 사용되었으며, Home 화면에서 다른 프로젝트의 코드 정보를 자동으로 불러오는 과정에서는 Docker와 자동 배포 구조(CI/CD) 역시 함께 활용되었다.
각주
초기에는 사이트 진입 전 분위기를 형성하기 위해 별도의 시작 화면 구조를 고려하기도 하였다.
하지만 루다 로그는 모바일 앱보다는 웹 기반 탐색 흐름에 가까웠기 때문에, 독립적인 시작 화면은 전체 구조와 어울리지 않는다고 판단하였다.
이후 해당 구조는 Popup 기반 안내 방식으로 변경되었다.
자세한 내용은 Popup System 도입 파트에서 이어서 다루게 된다.
초기 구조에서는 실제 개발 로그와 매우 유사한 형태를 사용하였다.
하지만 해당 방식은:
- 아카이브 중심의 분위기와 충돌하고
- 사이트 전체의 테마가 분리되어 보이며
- 비개발자에게는 접근 장벽이 높다는 문제
가 존재하였다.
이후 루다 로그에서는 "실제 개발 화면"보다는 "누구나 탐색 가능한 기록 공간"에 가까운 방향으로 UI를 수정하게 되었다.
물론 일반적인 애니메이션 라이브러리만으로도 유사한 효과를 구현하는 것은 가능하다.
하지만 루다 로그에서는 단순히 화면이 움직이는 것보다, 사용자의 행동에 공간이 반응하는 경험을 중요하게 생각하였다.
예를 들어:
- 마우스를 움직이면 입자가 흩어지거나
- 특정 공간에 가까워지면 분위기가 달라지고
- 클릭에 따라 화면의 흐름이 이어지는 방식
등을 통해, 단순 정적 페이지보다는 살아있는 아카이브 공간처럼 느껴지도록 구성하고자 하였다.
결과적으로 p5.js는 단순 시각 효과를 위한 도구가 아니라, 루다 로그 전체의 분위기와 탐색 흐름을 보조하는 역할로 사용되었다.
물론 참여형 예술과 UX 설계는 서로 다른 영역이다.
하지만 사용자가 구조와 맥락을 충분히 이해하지 못했을 때, 의도와 전혀 다른 경험으로 이어질 수 있다는 점에서는 공통점이 존재한다고 생각하였다.
루다 로그는 예술 작품이 아니라 실제 포트폴리오 사이트이기 때문에, 사용자가 구조를 이해하지 못한 채 이탈하는 경험은 치명적일 수 있었다.
초기 단계에서는 Alert와 Toast 구조 역시 사용해보았다.
하지만 Toast는 짧은 상태 전달에는 적합했으나, 사이트 전체의 분위기와 탐색 방식을 설명하기에는 정보량이 부족했다.
또한 Alert는 일반적으로 경고나 오류 전달에 가까운 느낌이 강하다고 판단하였다.
반면 Popup은:
- 사용자의 흐름을 잠시 멈추고
- 현재 공간의 성격을 설명하며
- 다음 탐색 행동을 유도하는 역할
에 더 적합하다고 보았다.
결과적으로 Popup은 단순 공지창이 아니라, 루다 로그 전체 탐색을 위한 안내 구조에 가까운 역할로 사용되었다.
대표적으로:
루다로타내부 공간 이동- Home 진입 시 CMD Overlay
등이 이러한 구조에 해당한다.
특히 Home에서는 사용자가 자연스럽게 사이트의 탐색 방식에 익숙해지도록 흐름을 설계하였다.
CMD Overlay에서 닫기 버튼을 누르면 곧바로 Workspace 화면이 나타나도록 구성한 이유 역시, 단순 첫 화면의 역할을 넘어서 사이트 전체의 구조와 탐색 흐름을 자연스럽게 이해시키기 위함이었다.
또한 사용자가 "잘못 클릭하면 망가질 것 같은 사이트"로 느끼지 않도록, 탐색 자체에 대한 부담을 줄이고 다음 행동에 대한 호기심을 유도하는 방향 역시 함께 고려하였다.
특히 WIKI테마의 경우 압도적인 생산적 편리성을 자랑하였다. 기존에 사용하던 깃허브 블로그의 경우 하위 카테고리나 검색기능을 직접 구현하였지만, 도큐사우르스에서는 이미 해당 기능들이 모두 테마 형태로 제공된다.
p5.js를 선택한 이유 역시 비슷하다.
three.js처럼 높은 학습 난도를 가진 구조보다, 루다 로그의 분위기를 유지하면서도 빠르게 원하는 연출을 구현할 수 있는 방향을 우선적으로 고려하였다.
GitHub Actions는 배포 자동화를 위해 사용되었으며, Home 화면에서 다른 프로젝트의 코드 정보를 자동으로 불러오는 과정에서는 Docker와 자동 배포 구조(CI/CD) 역시 함께 활용되었다.