포털의 진입 경로와 오류 처리 개선하기
프로젝트 생성 화면은 헤더의 작은 개발자 포털 링크로 접근해야 했습니다. 이름이 중복되면 별도 오류 화면으로 이동했습니다. 토스의 UX 사례에서 검토 기준을 정했습니다. 핵심은 비개발자가 화면 안내만으로 다음 행동을 결정할 수 있는가였습니다.
토스 사례에서 정한 검토 기준
| 학습한 내용 | 포털에서 확인할 질문 |
|---|---|
| 토스 라이팅 원칙: 다음 화면 예고와 쉬운 언어 | 버튼을 누른 뒤 일어날 일을 예상할 수 있나? |
| 가입 과정 개선: 필요한 이유 설명 | 왜 가입해야 하는지 알 수 있나? |
| Value first, Cost later | 프로젝트 공개를 요청하기 전에 서비스 화면을 보여주나? |
| 좋은 에러 메시지를 만드는 6가지 원칙 | 오류 원인과 입력 수정 또는 재접속 방법을 안내하나? |
쇼케이스에 프로젝트 배포 버튼 추가하기
쇼케이스 상단에 내 프로젝트 배포하기 버튼을 추가하고, GitHub 로그인으로 이동한다는 안내를 보완했습니다.
| AS-IS: 헤더 링크로 진입 | TO-BE: 상단 버튼으로 진입 |
|---|---|
 |  |
프로젝트 상세에 배포 상태와 기능 설명 표시하기
배포 안내와 체험 버튼을 개선했습니다. 용어, 진행 기록, 관리 기능의 배치는 추가 시안으로 정리했습니다.
| AS-IS: 변경 전 | TO-BE: 추가 개선 시안 |
|---|---|
 |  |
| 화면 요소 | 변경 내용 |
|---|---|
| 배포 진행 안내 | 현재 단계를 표시하고 진행 상황을 자동으로 갱신 |
| 서비스 체험 버튼 | 첫 배포가 성공하기 전에는 비활성화 |
| 화면 용어 | Repository는 Git 저장소, Preview는 체험 주소로 바꾸고 용도 설명 추가 |
| 진행 기록 | BUILD_STARTED, INFO 같은 내부 코드 대신 배포 작업과 상태를 설명하는 문장 표시 |
| 프로젝트 관리 | 등록 해제 같은 관리 기능을 접을 수 있는 영역에 배치 |
프로젝트 생성 폼에 Inline error feedback 적용하기
입력값을 보존하고 필드 아래에 오류를 표시하는 Inline error feedback을 적용했습니다. 화면 전환 없이 이름을 수정하고 다시 제출할 수 있습니다.
| AS-IS: 별도 오류 화면으로 이동 | TO-BE: 입력값 보존과 폼 내부 오류 표시 |
|---|---|
 |  |
서비스 교체 중 재접속 안내하기
기본 502 화면을 서비스 교체 안내로 바꿨습니다. 자동 재접속까지 남은 시간과 재시도 버튼을 표시하고, 재접속 후 저장이나 생성 결과를 확인하도록 안내했습니다.
| AS-IS: 기본 502 오류 화면 | TO-BE: 서비스 교체와 재접속 안내 |
|---|---|
 |  |
가입 단계와 배포, 체험 링크 클릭 집계하기
운영 지표로는 가입 과정과 체험 링크 클릭을 파악하기 어려웠습니다. 방문, 클릭, 제출 이벤트를 수집해 배포 기록과 함께 집계했습니다.
| 대상 | 주요 지표 |
|---|---|
| 프로젝트를 배포한 사용자 | 주간 배포 사용자 수, 사용자 배포 횟수 |
| 관람자 | 관람자당 고유 체험 링크 클릭 수(같은 링크의 반복 클릭 제외), 프로젝트별 체험 링크 클릭 수 |
| 조직 가입 경로 | 가입 요청 수, 초대 수락 수 |
| 첫 배포 진입 과정 | 쇼케이스 진입, 로그인 완료, 프로젝트 생성, 사용자 배포 단계별 관측 인원 |
이 집계는 동일 사용자의 순차 이동을 보장하지 않습니다. 단계별 관측 인원을 전환율이나 이탈률로 해석할 수는 없습니다.
ClickHouse로 이벤트와 배포 기록 적재하기
PostgreSQL의 이벤트와 배포 기록을 ClickHouse로 적재할 세 가지 방식을 비교했습니다.
| 검토한 방식 | 장점 | 비용 |
|---|---|---|
| Vector 기반 ETL 프로세스 | 포털 외부에서 적재와 변환 | ETL 프로세스 운영 필요 |
| 포털에서 ClickHouse에 직접 기록 | 주기적 조회 없이 전달 | 포털에 연결 의존성 추가, 배포 기록과 적재 경로 분리 |
| ClickHouse 내부 스케줄러 | 별도 ETL 프로세스 없이 PostgreSQL 원본 조회 | 반영 지연, PostgreSQL 조회와 ClickHouse 쓰기 비용 |
내부 스케줄러 방식을 선택했습니다. 포털은 PostgreSQL에만 기록하고, ClickHouse는 PostgreSQL 엔진으로 원본을 조회합니다.
- 화면 이벤트는 1분마다 최근 10분 범위를 조회해 추가 적재합니다.
- 프로젝트, 배포, 권한 데이터는 10분마다 전체 갱신합니다.
화면 이벤트는 조회 범위가 겹쳐 중복 적재됩니다. ReplacingMergeTree 테이블을 FINAL로 조회해 백그라운드 병합 전에도 중복을 제거했습니다.
적재 주기와 누락 복구 검토하기
적재 주기를 줄이면 반영 지연은 줄지만 PostgreSQL 조회 빈도는 증가합니다.
| 구분 | 문제가 되는 상황 | 대응 방향 |
|---|---|---|
| 반영 지연 | 집계 반영 지연이 필요한 최신성 기준을 초과 | 적재 주기 단축 |
| DB 부하 | 원본 조회로 포털의 DB 응답 시간 증가 | 주기를 늘려 조회 빈도 축소 범위를 조정해 조회량과 쓰기량 축소 |
| 누락 복구 | 적재 성공 간격이 10분을 넘어 일부 화면 이벤트 누락 | 누락 구간 Backfill 적재 실패 감시와 Backfill 자동화 |
Rill에서 배포와 체험 링크 클릭 비교하기
매번 SQL을 작성하는 대신 Rill에서 기간과 필터로 집계를 조회하도록 구성했습니다. 운영자 인증과 ClickHouse 읽기 전용 계정을 적용했습니다.
| 샘플 데이터 | 실제 데이터 |
|---|---|
 |  |