Slashpage

이미 통자로 완성된 템플릿 제공은 지양하고, 섹션 단위 중심으로 설계할 것 완성형 템플릿의 한계 겉보기에는 화려하고 쉽지만, 실제 사이트 구축 과정에서는 활용하기 어렵다. 실제 초기에 완성형 템플릿을 제공했을때 이를 수정하지 않고, 만들어보고 그대로 방치하는 경우가 많았기때문에 이런 방식으로 템플릿 제공하는 기능을 삭제했다 사용자의 콘텐츠 타입, 텍스트 길이, 작성 맥락이 모두 달라 그대로 맞춰 쓰기 힘들다. 예: 템플릿의 히어로 영역은 마음에 들어도, 설명 영역은 텍스트가 길어서 맞추기 어렵다. “직접 쌓아올린 듯한 경험” 설계 사용자가 템플릿을 ‘그냥 가져다 쓰는’ 것이 아니라, 단계적으로 쌓아가며 만든 결과물처럼 느끼게 해야 한다. 작은 단위의 선택과 입력을 거치며 **“내가 공수 들여 구축한 사이트”**라는 감각을 주는 것이 중요하다. 이 과정이 사용자에게 애착·만족감을 높여, 결과물의 완성도를 넘어 소유감으로 이어진다. 수정/커스텀의 어려움 통자 템플릿은 일단 가져오긴 쉽지만, 세부 수정 과정에서 서비스 구조나 툴 이해가 필요하다.(요즘 Ai가 쉽게 만들어주는 사이트또한 그런데, 첫 프롬프트의 결과물은 놀랍지만 이걸 원하는대로 수정하는것은 여전히 진입장벽이 높다고 생각이 든다) 비전문가에게는 오히려 수정 과정이 진입장벽으로 작용할 수 있다. 섹션 단위 접근의 필요성 섹션 단위 템플릿을 조합하면, 사용자가 가진 콘텐츠와 기획에 맞게 유연하게 사이트를 구성할 수 있다. 완성본보다 조립 과정에서의 선택과 참여가 사용자 애착과 만족도로 이어진다. 단, 모든 것을 직접 결정하게 하면 진입장벽이 높아지므로, 적절한 수준의 자동화와 선택지 제공이 필요하다. (테스트 필요)

사이트 첫 생성시 '사이트 설정'보다 우측 편집 패널에 있는 '권한' 메뉴에 접근이 더 쉬움 → 이 권한은 해당 페이지에 대한 개별적인 권한이고, 해당 레이어에서 사이트 전체 권한 설정에 대한 인지를 하기 어려워 첫 사용자는 헷깔릴 수 있음 기존엔 루트 페이지 권한값은 사이트 기본 권한값과 연동 돼 있어, 루트에서 설정을 변경하면 사이트 전체 값이 변경 돼 이런 문제가 적었던 것 같은데, →>>> 최근 메인 페이지를 자유롭게 이동하거나 변경 할 수 있도록 사이트와 개념을 분리하며 헷깔려 하는경우가 종종 보임 ( 기존 홈은 루트 페이지로 고정 돼 있었음) → 페이지의 권한 설정에서도 사이트 전체에 해당하는 기본 값을 설정하거나 인지할 수 있도록 변경하면 해결될듯 하다 페이지 개별 설정인지 사이트 전체에 대한 값인지 인지 어려움 페이지에서는 글쓰기 권한이 노출되지 않고, 데이터 베이스 내부에서만 글쓰기 권한 설정을 할 수 있는데 데이터 베이스를 인라인으로 생성하는 과정에서 글쓰기 설정을 하고, 페이지에서 해당 권한이 없으니까 어려워하는듯?

직접 업로드한 이미지에서만 제공되던 편집 기능을, 스톡 이미지를 사용할 때도 동일하게 활용할 수 있도록 구조를 변경했습니다. 선택된 스톡 이미지를 업로드 형식으로 처리하도록 변경하면서 UI를 함께 수정했고, 더 다양한 이미지를 활용할 수 있도록 Unsplash 외에도 Lummi를 추가했습니다. Lummi.ai Lummi는 AI 기반 스톡 이미지 서비스로, Unsplash보다 전반적으로 깔끔하고 정제돼 있습니다. 사진, 일러스트, 3D이미지를 지원하고, 원하는 색상을 지정해 해당 색상에 맞는 이미지만 활용할 수 있어 사이트 제작 시 원하는 분위기를 맞추기 유용합니다. (Pro 요금제를 사용하면 원하는 비율로 이미지를 재생성하거나, 배경 없는 PNG형식으로도 사용할 수 있음) 변경전 기존에는 업로드와 Unsplash 중 하나를 택하는 방식이었기 때문에 탭으로 나누어 제공함 변경 후 미디어 업로더 컴포넌트

슬래시페이지는 페이지 단위로 세밀한 권한 제어가 가능합니다. 사이트 전체 멤버를 기본으로 설정하고, 각 하위 페이지에서 필요에 따라 멤버를 추가,제거하거나, 권한을 개별 설정할 수 있습니다. 이 방식은 자유도가 높다는 장점이 있지만, ‘상속’과 ‘상속 끊어짐’ 이라는 개념을 사용자가 생소하게 느껴 이해하기 어려워하는 경우가 많았습니다. 특히, 하위 페이지에서 멤버 권한을 변경 했을 때 그 변경이 해당 페이지 한정인지 사이트 전체에 영향을 주는지 인지하지 못하는 경우가 있어, 상속 상태를 명확히 구분하고 끊김을 의식적으로 전환하도록 UI 구조를 개선했습니다. 변경 전 편집 모드의 우측 설정 패널의 [멤버] 메뉴나, 공유 레이어 등을 통해 페이지 멤버 관리에 접근할 수 있다. 각 페이지는 부모 페이지의 멤버 설정을 상속 받는다. 부모 페이지에서 개별 초대된 멤버는 하위 페이지에서 '{Page name}에서 초대된 멤버'로 묶어 표시 사이트로 직접 초대된 멤버는 '사이트 멤버'로 표시 하위 페이지에서 상속받은 멤버를 삭제하거나 권한을 변경하면 상속 끊어짐을 안내하는 컨펌을 띄우고 확인시 상속이 끊어진다. 상속이 끊어진 페이지의 멤버는 독립적으로 관리된다 (멤버를 추가하는 경우엔 상속 유지) 상속이 끊어지면 안내 배너가 노출되고, 되돌리기 버튼을 통해 부모 페이지와 다시 연결할 수 있다.

초기 슬래시페이지는 ‘누구나 쉽게 콘텐츠를 웹에 게시’하는 것을 목표로 진입장벽이 낮은 노트 에디터를 채택했다. 에디터 자체는 사용하기 쉬웠으나, 초기 사용자 대부분이 ‘개인 문서 정리 용도’로 활용을 시도했고, 공개용 콘텐츠를 업로드하려는 시도는 드물었습니다. 공개 콘텐츠 기반 서비스 구축이 목표였기에, 사용자들이 우리를 그런 플랫폼으로 인식하게 만드는 것이 핵심 과제였습니다. URL단위의 구분 없는 사이트 트리 루트 페이지의 고유 URL이 UI에 드러나지 않아, 개별 사이트가 아닌 문서 묶음으로 인식됨 → 브랜딩과 독립성 전달 어려움

슬래시페이지를 시작한지 2년이 지나면서 초기보다 방향성이 구체화 됐고, 처음 정의했던 서비스와는 , 기존 브랜드 아이덴티티가 UI 활용과 전개 과정에서 비효율적인 부분이 있었기 때문에, 그간의 불편함을 바탕으로 더 실용적이고 확장성 있는 방향으로 개선이 필요했기때문에 브랜드 재정비를 진행했다. 초기 슬래시페이지 처음 슬래시페이지를 시작할 땐 빠르게 서비스를 만드는게 우선이었기 때문에, 로고와 컬러에 깊은 고민을 하기보다는 단순하고 심플하게 결정했습니다. '슬래시(/)로 블럭을 추가해 페이지를 만든다' 사용 방식을 그대로 반영해 슬래시페이지라고 이름을 정했고, 슬래시 메타포를 그대로 로고에 사용했습니다. 다른 노트 에디터기반 서비스와 차별성 나타내기 위해 그라데이션이나 네온 컬러를 활용해 화려하게 색상을 사용 했습니다. 기존의 노트 에디터나 노트 기반 서비스들은 보통 정갈하고 깔끔하게 글을 쓸 수 있는것을 강조하는 경우가 많았는데, 우리는 좀더 커스텀 가능하고, 개성을 표현할 수 있다는걸 보여주고 싶었습니다. 프로덕트 헌트에서 주간 1위를 했었는데, 이건 나중에 정리 할 예정 ProductHunt - Slashpage

Desktop Bar Chart Details Mobile

As-is Color Shape, shadow, border 등의 요소들이 하나로 묶여있는 Theme프리셋 제공 Shape을 변경하려면 테마자체를 변경해야하고 설정해놨던 값은 변경한 테마로 덮어씌워짐 일부 색상과 shape, Shadow등의 요소는 사용자가 세부조정 할수 없음 복잡한 디자인 에디터를 제공하는것이 비 전문가에겐 툴을 사용하는 허들이 된다고 생각 → 커스텀 요소를 제한하고 프리셋 중심으로 제공해서 선택할 요소를 줄이려 함 To-be AI를 도입하며 서비스 전면에 Ai 어시스던트 채팅 ui를 배치하기로 함 기존에는 비전문 사용자를 배려해 제한된 프리셋 위주로 UI 설정을 제공했음 → 하지만 이제는 AI가 사용자 의도를 파악해 자동으로 세부 설정을 도와줄 수 있으므로,설정 자유도를 제한할 필요가 줄어들었다. 특히 chat UI 같은 인터페이스는 ‘뭐든 해줄 수 있다’는 기대를 유도하기 때문에, 고정된 프리셋만 반환하는 방식은 AI 경험과 어울리지 않음 AI의 도움으로 유저가 직접 복잡한 설정을 숙지할 필요가 없어졌으니 제한했던 자유도를 풀고 유저가 원하는 바를 구현하는 것에만 집중할 수 있도록 개선 → 커스텀 가능 범위를 확장 + 디자인 시스템을 재 정비 2025.7 개편 범위 → 유저 사용성까지 다 고려한 최종 피쳐까지 진행하는지, 일부 요소부터 순차적으로 내보내는 방식이 좋을지? → 섹션 템플릿 배포보다 먼저 해야하나? 커스텀 가능 항목 설정 → 이미 테마에서 제공하고 있는 요소들은 모두 커스텀 가능하게 제공 + 커스텀 영역 확장 Color (커스텀 가능 영역 확장)

서비스 초기에 사이트를 구성하는 가장 작은 단위는 페이지였다. 페이지 단위는 직관적이고 빠르게 결과물을 만들 수 있다는 장점이 있었지만, 실제 사용 과정에서는 몇 가지 불편함이 드러났다. 페이지 단위의 한계 이미 완성된 템플릿을 그대로 활용하기는 쉽지만, 불러온 템플릿의 세부적인 내용을 수정하고 편집하는 과정은 쉽지 않았다. 모든 경우의 수의 템플릿을 제공할 수 없고, 유저마다 원하는 구성이 다르기 때문에 페이지 단위로 템플릿을 제공하는 것엔 한계가 있었음. 실제로 초반엔 블로그/자기소개/... 등 몇가지 케이스로 페이지 단위의 템플릿을 제공했었는데, 해당 템플릿을 수정해서 쓰는 경우는 아주 적었다. 템플릿을 추가해보고 새로 페이지를 만든다거나 하는 경우가 많아서, 예시 사이트인 에이미 올리버 페이지가 무한 증식하는 모습을 보았다. 추가로 웹 사이트의 일반적인 형태를 고려했을때도 섹션 단위로 페이지를 쪼개는것이 유리하다고 판단했는데, 웹 사이트들은 일반적으로 섹션 단위로 구성 돼 있기때문에, 우리가 꼭 노트형 페이지가 아닌 이벤트 페이지나 홈 페이지의 범위까 때문에 유저가 템플릿을 베이스로 두고, 원하는 구성에 맞게 쉽게 페이지를 재 구성하고 유지보수 할 수 있어야 한다고 생각했다 예시로 템플릿에 히어로 섹션이 포함 돼 있는데, 히어로 섹션을 제거하고 싶다거나, 혹은 다른 디자인으로 쉽게 교체하고 싶다거나 페이지 구성 중간에 블로그 섹션을 추가하고 싶다거나 섹션 단위 도입 이 문제를 해결하기 위해 페이지를 더 작은 단위인 섹션으로 분리했다. 섹션 단위 편집을 도입하면서 다음과 같은 변화가 가능해졌다: 페이지 안에서 섹션 순서를 자유롭게 바꾸기

초기의 슬래시페이지 애널리틱스는 페이지 단위 중심 구조로, 사이트 전체의 흐름이나 성과를 종합적으로 파악하기 어려웠습니다. 페이지별로 개별 수치를 볼 수 있었지만, 어떤 페이지가 상대적으로 주목받고 있는지, 사이트가 성장하고 있는지 등의 전체 사이트에 대한 정보를 한눈에 이해하기 힘든 구조였습니다. 이번 개편에서는 페이지 기반 애널리틱스를 사이트 단위로 확장하고, 지표의 기준을 일관되게 정비해 사용자가 직접 해석해야 했던 복잡성을 줄였고, 이를 통해 사용자는 자신의 사이트가 외부에서 어떻게 소비되고 있는지, 콘텐츠가 어떤 영향을 미치고 있는지를 더 직관적으로 인지할 수 있게 되었습니다. 기존 애널리틱스의 문제점 사이트 단위 비교,분석이 어려운 페이지 중심 구조 사이트 단위로 콘텐츠를 운영하는 경우, 사이트의 전체 흐름을 파악하고자 하는 니즈가 자연스럽게 발생한다. 예: 이 사이트의 전체 유입은 얼마나 되는가? 어떤 페이지/포스트가 가장 많이 소비되는가? 등 하지만 기존 애널리틱스는 페이지 단위로 데이터를 보여주는 구조였기 때문에, 콘텐츠 간 성과 비교, 유입 흐름 분석처럼 사이트 전체 지표를 종합적으로 파악하기 어려웠다.

초기 슬래시페이지는 각 사이트를 하나의 독립된 워크스페이스 처럼 다뤘고, DM 기능도 각 사이트에 포함되어 있었습니다. 하지만 실제 사용 방식은 점차 다양해졌습니다. 여러 사이트를 동시에 운영하거나, 관심 있는 사이트를 구독해 소식을 받아보는 등 복수의 사이트에서 활동하는 경우가 늘어났습니다. 이에 따라 사이트 간을 오가며 소통하기 자연스러운 구조로 DM을 개선하고, 그동안 임시 형태로 제공되며 다소 미비했던 기능들도 함께 보완했다. 초기 슬래시페이지는 각 사이트를 하나의 독립된 워크스페이스 처럼 다뤘고, DM기능도 각 사이트에 포함되어 있었습니다. 각 사이트의 페이지 트리에 포함되어 있었는데, 특정 사이트에 진입시 해 기존 DM의 문제점 알림 혼합과 접근 경로 문제 DM 알림이 일반 알림(예: 새 글, 댓글 등)과 함께 표시되어 즉각적인 대응이 어려웠다. 일정 시간이 지나면 알림센터에서 사라지고, 이후에는 메시지 확인을 위해 사용자나 사이트를 기억해 직접 찾아가야 했다. 이로 인해 메시지를 놓치거나 응답이 늦어지는 문제가 발생했다. 사이트 기반 구조로 인한 불편함 DM이 사이트 내부 트리에 위치해 있어, 다른 사이트의 메시지를 확인하려면 사이트를 변경해야 했다. 페이지 전체가 전환되는 구조였기 때문에, 메시지를 확인하는 과정에서 사용 중이던 화면과 맥락이 끊어졌다. 분산된 구조로 인한 실시간성 저하 메시지가 사이트 단위로 분산돼 있어 계정 전체 기준에서의 일괄 관리가 불가능했다. 여러 사이트를 넘나드는 사용자일수록, 커뮤니케이션 흐름이 단절되거나 누락될 가능성이 높았다.

커뮤니티형 사이트를 관리하는 유저들의 '커뮤니티 이용 공지나 이벤트 공지를 하고싶다'는 요청에 따라. 특정 포스트를 Pin 하여 상단에 띠 배너로 노출할 수 있는 기능을 제공했었다. 그러나 해당 기능은 유저가 원하는 다양한 공지의 형태를 모두 대응하기엔 부족한 부분이 있었기에 기존 Pin 기능을 개선하고, 신규 기능을 추가해 더 적극적으로 공지를 안내할 수 있도록 개선했다. 기존 핀 기능의 문제점 발행된 각 포스트의 더보기 메뉴에서 해당 포스트를 ‘핀’으로 지정할 수 있다 핀된 글은 해당 글이 게시된 페이지 상단에 띠배너 형태로 노출됐다. (가장 최근 등록된 게시글이 기본으로 표시되며, 공지가 여러 개 등록된 경우에는 배너 내 핀 영역을 통해 n개의 공지를 레이어 형태로 확인할 수 있었음) 하지만 이런 형태는 여러 개의 글을 동시에 핀했을 때 접혀 있는 글을 인지하는데 어려움이 있었고, 특정 페이지에서만 노출되는 구조라 사이트 전체 공지를 전달하기에 적합하지 않았다.

'활성화된 서비스를 위한 홈 화면 및 구조 개선' 작업 중, 새 글 피드 추가에 대한 내용 상세 페이지 유형에 따라 글 상세의 레이아웃이 다르기 때문에, 다양한 사이트의 글을 한곳에 모아 보여주는 피드를 구성할때 각 글의 상세 화면을 어떤 방식으로 보여줄지에 대한 고민이 있었다. 페이지 타입별 글 상세 슬래시페이지는 데이터베이스 기반으로 다양한 페이지 타입(블로그,갤러리,리스트 등등)을 지원하고 있기 때문에, 각 페이지에 따라 글 상세 화면의 레이아웃도 다르게 보여주고 있다. 블로그 : 하나의 글에 집중할 수 있도록 전체 화면을 덮는 전면형 레이아웃 그리드 : 미디어 영역을 강조하며, 이미지 비율을 유지하는 전면형 레이아웃 채팅,피드 : 페이지 목록과 상세 내용을 함께 보며 연속적으로 소비할 수 있도록 구성된 우측 드로어형 레이아웃 데이터베이스 : 페이지 목록과 상세 내용을 함께 보고, 글을 편집·관리하기 쉬운 우측 드로어형 레이아웃 피드에서의 글 상세 소비 방식 고민 방식 1. 피드 내에서 전용 상세로 글을 보여줌 방식 2. 해당 사이트로 이동하여 본문으로 글을 보여줌

정리 SlashPage의 설정 화면은 사용자 작업 흐름의 연장선이며, 작업 도중에도 안전하고 독립된 공간에서 빠르게 설정을 수정할 수 있어야 한다. 이를 위해 전면 모달 구조를 유지하며, 페이지 전환으로 인한 흐름 단절과 상태 손실 위험을 방지한다. 정성적 데이터 활용 숫자 데이터에 집착말고 다른 지표도 생각 팀원 피드백 유저 문의/클레임 커뮤니티 반응 베타 테스트 결과 가설 → 실행 → 검증 과정 생각하기 작은규모라도 내부 테스트 → 반응 보기 → 반복 개선 으로 접근한거 생각 예시 1 사용자 행동 데이터는 부족했지만, 유사 서비스와 내부 사용성 테스트를 통해 주요 불편 지점을 도출했습니다. 이를 기반으로 최소한의 수정안을 적용했고, 이후 유저 피드백을 통해 긍정적인 반응을 확인했습니다 예시 2 내부 사용성 테스트를 통한 UI 개선 신규 기능 배포 전, 사내 테스트를 진행할때 뒤에서 지켜보기 직원들의 자연스러운 사용 패턴을 관찰했습니다. 특히 [메뉴 위치/플로우]에서 반복적으로 발생하는 헛손질 확인 → 직관적인 플로우로 개선 → 실제 배포 시 유저 혼란을 최소화. 낯설게 보기를 통한 UX 개선 장기적으로 기능을 다루다 보면, 기존 유저 관점은 생각하기 어려우짐→의도적으로 서비스와 거리를 두거나, 얼레벌레한 상황에 서비스 보기 → 낯설고 불편한 지점을 발견. 모든 걸 커버하는 기능이 꼭 좋은 건 아니다 다 커버되는 컴포넌트 (블로그 리스트 과거버전 같은.._

슬래시페이지는 단순히 일방향적인 홈페이지,랜딩페이지를 만드는 사이트 빌더가 아니라, 양질의 콘텐츠를 업로드하고 받아볼 수 있는 사이트 구축을 지향하고 있는데, 기존 홈 화면에서는 이러한 방향성이 충분히 드러나지 않았다. 초기 홈 화면은 사용자의 사이트 리스트를 단순히 나열하는 구조였다. 당시에는 '커뮤니티'보다는 '내 사이트를 만들고 관리하세요'에 가까운 이용 흐름을 가정하고 있었기 때문에, 기존 웹 빌더나 툴처럼 사용자가 자신이 만든 프로젝트를 쉽게 식별할수 있도록 단순 리스트 형태로 홈을 구성했었다. 그러나 점차 '개인 사이트 제작' 중심에서, 사이트를 기반으로 '양방향 소통과 커뮤니티 제작' 중심으로 서비스가 발전해 나가면서, 기존 리스트 형태로는 사이트별 활동성과 변화를 충분히 전달하기 어려운 한계가 드러났다. 이에 따라 사용자가 첫 화면에서 사이트의 변화와 활동을 바로 인지할 수 있도록, 홈 화면과 메뉴 구조를 개선했다. 1. 새 글 피드 추가 및 메뉴 구조 변경 Before 새로운 소식을 확인하려면 알림센터나 사이트 내부로 진입해야 했음 After 알림센터나 사이트 내부로 이동하지 않고, 첫 화면에서 주요 업데이트를 바로 인지할 수 있도록 개선 새 글 알림을 피드 형태의 별도 화면으로 제공 새 글 피드 첫 번째 메뉴(홈 화면)에 배치

작년쯤 사이트 내의 공통 설정들을 사이트 설정에 묶어서 정리했는데,

슬래시페이지의 데이터베이스는 단순히 워크플로우 데이터를 정리를 넘어, 채팅,피드, 블로그등의 커뮤니티형 레이아웃을 지원하며, 지속적으로 컨텐츠를 발행하는 주요 사용자층은 이러한 데이터베이스 기능을 적극적으로 활용하고 있습니다. 초기에는 개인 노트나 간단한 페이지 제작에 활용되는 경우가 많아 커스터마이징 요청이 크지 않았습니다. 그러나 슬래시페이지가 점차 ‘공개 사이트를 위한 공간’이라는 방향성을 강조하면서, 색상·배치·너비 등 디자인 요소를 조정해 사이트를 브랜딩하려는 사용자 요청도 함께 증가했습니다. 주요 변경점 데이터베이스 페이지 너비 커스텀 기존에는 노트 타입에서만 가능했던 페이지 최대 너비 조정 기능을, 이제 모든 데이터베이스 타입에서도 설정할 수 있습니다. 레이아웃 변경 옵션 추가

새 페이지를 생성할때 아이콘과 텍스트로만 표시했을 때 유저가 해당 페이지가 어떤 유형인지 인식하기 어렵다고 생각함. 물론 데이터베이스 서비스를 사용해본 사람이라면 익숙하겠지만 좀더 접근성을 낮추고 싶었음 각 페이지의 프리뷰를 볼 수 있는 형태로 개선 → 리스트에서 각 페이지의 아이콘을 해당 페이지의 기능을 더 파악할 수 있는 그래픽으로 변경 에디터에서 타이핑중에 슬래시로 추가할땐 생략, 메뉴나 사이드바에서 클릭해서 추가하는 경우에만 노출 페이지 유형 선택 → 페이지 설정 [페이지 설정] 타이틀과 설명 권한 멤버 설정 → 테스트 할땐 페이지 생성 과정에서 계속 레이어가 떠서 번거롭다는 의견이 있었는데, 테스트 상황은 실제 유저가 사용하는 패턴과 많이 다르다. (실제 사용의사가 없는 페이지를 계속 생성하기때문에) 그렇기때문에 페이지 생성 레이어를 확실하게 보여주는 방향으로 결정함 각 페이지의 권한에 대해 인식하지 못하는 경우가 많아 페이지 생성 과정에 권한 설정 노출 → 기존엔 기본값이 로그인한 유저로 돼 있었는데, 대부분 불특정 다수가 포스팅하는 케이스가 아닌 화자가 명확하게 있는 케이스였기때문에 기본 권한을 글쓰기 멤버로 올림 → 사실 페이지의 유형에 따라 자연스러운 디폴트 권한이 다름 블로그의 경우 화자가 명확하지만 채팅 페이지는 불특정 다수에게 오픈하는 경우가 많기때문에 각 케이스에 맞춰 초기권한을 설정함

슬래시페이지를 시작한 지 2년이 지나면서 처음 정의했던 서비스와는 방향이 많이 달라졌습니다. 이에 맞춰 구체화된 서비스의 방향성을 담을 수 있도록 브랜드를 재정비했습니다. 기존 로고와 컬러 시스템이 제품 내에서 활용하기에 비효율적이었던 점들이 있어 이 부분을 개선해 더 실용적이고 확장성 있는 방향으로 정리했습니다. 초기 슬래시페이지 슬래시페이지는 '카페노노'를 피봇하며 블록 에디터만을 남기고 새롭게 시작한 서비스입니다. 초기 구조는 좌측의 페이지 트리와 우측의 노트 영역으로, 사실 노션과 거의 유사했습니다. 다만 개인이나 팀의 프라이빗 공간보다는 웹에 게시할 수 있는 공개 페이지에 초점을 맞췄고, 여기에 채팅형 채널을 생성할 수 있다는 점, 커스터마이징이 자유롭다는 차이점을 가지고 있었습니다. 슬래시페이지는 '슬래시(/)'로 블럭을 추가하는 노트 에디터의 사용성을 그대로 반영해 서비스의 이름과 로고를 만들었습니다. 메인 컬러로는 형광빛이 도는 녹색을 사용했습니다. 당시 로고와 이름은 하루도 걸리지 않고 결정했는데, 피봇 이후 새 서비스를 만드는게 더 중요했기때문에 로고에는 많은 시간을 투자하지 않고 진행했습니다.

페이지를 꾸미거나 포스트를 작성할 때, 이미지 규격을 다른 도구를 사용해 편집해야 하는 불편함이 커 편의성을 위해 이미지 편집 기능을 추가했다. (개인적으로 테스트용 게임 블로그 쓸 때마다 매번 포토샵으로 편집하고 사이즈 맞춰서 올리는 게 번거로웠고, 사용자 피드백에서도 종종 요청이 들어왔던 기능이라 이전부터 필요하다고 느꼈는데, 드디어 업데이트 할 수 있어 기쁘다!) 이미지 회전,반전,크롭 기능 추가 기 편집 기능을 우선 제공하고, 추후에 색상 보정,이미지 위 텍스트 추가,그리기 등 확장 될 가능성이 있어 이를 고려해 좌측에 사이드바가 있는 구조로 디자인 공통 이미지 업로드 레이어에 이미지 편집 버튼 추가 직사각형 비율은 마우스 오버시 가로형인지 세로형인지 선택할 수 있는 버튼 제공 모바일 이미지크롭

기존에는 사용자가 다른 사람의 사이트에서 초대를 받은 경우, 초대 내역은 알림센터를 통해서만 확인할 수 있었습니다. 때문에 알림센터를 따로 확인하지 않고 초대받은 사이트에 바로 진입하면, 초대 사실을 인지하지 못하는 경우가 있었습니다. (초대 받은 사용자가 초대 내역을 확인 못하고 사이트에 진입한 경우 → 관리자가 권한을 부여해 초대 했음에도 페이지가 정상적으로 보이지 않는다는 오해가 생길 수 있음.) 이런 문제를 해결하기 위해 초대 내역이 있는 경우에 해당 사이트에 접근했을때 권한을 바로 부여하는 방식도 고려해봤으나, 이 경우엔 해당 사이트가 왜 보이는지, 내가 이 사이트에서 어떤 권한인지 등 맥락을 파악하기 어렵고, 초대 수락,거절 여부를 직접 선택할 수 없다는 한계가 있었습니다. 이에 따라, 사용자가 초대받은 사이트에 진입했을 때 초대 내역을 확인할 수 있도록 안내 단계를 추가했습니다. 초대 내역 안내 모달 추가 사용자가 사이트에 진입했을 때 초대 내역이 있는 경우, 초대 확인 모달을 띄워 초대 정보를 인지할 수 있도록 변경했습니다. 해당 모달에서 이 사이트의 이름, 초대한 관리자 프로필, 받은 권한을 확인할 수 있고, 초대를 수락하거나 거부할 수 있습니다. 초대 건수에 따른 안내 방식 각 페이지마다 다른 권한으로 초대를 한 경우 사이트 내에 여러개의 초대 내역이 존재할 수 있기때문에, 초대 건수가 여러 건일 때는 리스트 형태로 묶어서 안내합니다.

SEO의 중요성 일부 콘텐츠 플랫폼 및 SNS는 콘텐츠의 외부 노출을 제한하거나, 검색엔진 인덱싱에 소극적인 구조를 가지고 있습니다. 예를 들어 인스타그램이나 미디엄은 콘텐츠가 공개되어 있더라도 검색엔진에서 전문을 확인하기 어렵고, 가입을 유도하는 흐름으로 설계되어 있습니다. 네이버처럼 자체 검색엔진 중심의 생태계를 유지하기 위해 외부 검색엔진(예: 구글)에 콘텐츠 노출을 제한하기도 합니다. 반대로 슬래시페이지는 사용자가 생산한 콘텐츠가 외부 검색엔진에 효과적으로 노출되도록 지원합니다. 개인의 콘텐츠가 자산이자 브랜딩 수단으로 점점 더 중요해지고 있기 때문에, 우리는 사용자가 자신의 브랜드와 콘텐츠를 외부에 적극적으로 알릴 수 있도록 다양한 기능을 제공하려 합니다. 이 일환으로 사용자가 생성한 사이트가 더 적극적으로 외부에 노출될 수 있도록 SEO 관련 기능을 개선했습니다. 주요 변경점 SEO 설정 공통화 및 UI 개선 Before 기존 SEO설정은 각 화면마다 따로 구현돼 있었습니다. 공유 레이어, 설정 레이어 등 각 기능의 흐름에 맞춰 진입 지점을 나누고, 해당 위치에서 각각의 UI를 가지고있는 방식이었는데, 표면적으로는 모두 'SEO 설정'이라는 동일한 기능이지만 진입점에 따라 사용자가 매번 새로운 형태의 설정 화면을 마주하게 되므로, 결과적으로 기능 이해해 방해 요소로 작용했습니다. 해당 방식은 개발 및 유지보수 측면에서도 효율적이지 않았는데, 기능 수정이나 개선이 필요할 때마다 서로 다른 위치의 UI를 모두 고려해야 했고, 단순한 변경에도 전체 화면을 반복적으로 확인했습니다. 특히 우리처럼 팀 규모가 작은 상황에서 이런 방식이 불필요한 리소스 소모로 이어졌기 때문에, 동일한 기능은 최대한 통합해 효율적으로 관리할 수 있도록 개선할 필요가 있었습니다.

포스트 상세 페이지에서 작성자 이름과 작성 시간을 숨기고 싶어하는 케이스(예: 기업 블로그 등)가 있어, 해당 정보를 보이지 않도록 설정할 수 있도록 기능을 변경했다. 향후에는 사용자 타입의 커스텀 필드를 활용해, 작성자 정보를 ‘담당자’나 ‘회사 프로필’처럼 사용자가 직접 설정한 값으로 유연하게 대체할 수 있도록 구조를 확장할 계획이고, 이를 위한 준비 단계로, 현재는 기본 작성자 정보를 커스텀 필드와 연동해 구성했다. 커스텀 필드의 작성자, 작성시간과 연동해 해당 커스텀 필드를 삭제하면 포스트 목록에서도 자동으로 숨겨짐