1번 액션을 덮지 않고 팀 피드를 홈 아래로 내린 AIDRA 홈 개편

문제 정의

팀원이 무엇을 만들었는지 볼 서버 경로 자체가 없었다

AIDRA의 홈은 로그인하면 바로 기획 인터뷰가 뜨는 화면이다. 이 제품의 1번 액션인 기획안 작성, 그 첫 페이지가 곧 홈이었다. 오늘의 기획 현황을 보여주는 대시보드는 그 옆 기획안 탭에 따로 있었다. 인사말과 요약 지표, 이어서 작업할 카드, 내 기획안 목록으로 구성돼 매 진입마다 같은 숫자와 같은 목록이 보였고, 새로 볼 것이 없으니 그 탭에 다시 들어올 이유도 없었다. 죽은 대시보드에 가까웠다.

더 구조적인 문제는 그 아래에 있었다. 팀원이 무엇을 만들었는지 제품 어디에서도 알 수 없었는데, 이건 화면을 안 만들어서가 아니라 타인 콘텐츠를 조회할 서버 경로 자체가 없었기 때문이다. 기획안 목록 조회 함수가 호출자 본인의 계정으로 하드코딩돼 있었고, 완성 기획안을 교차 조회할 수 있는 것은 관리자뿐이었다. 완성한 기획안과 캐릭터와 영상이 팀 안에서 서로 보이지 않았다.

세 번째로 트렌드 허브가 별도 탭에 있어서, 홈에 들어온 사람은 새 트렌드가 들어와도 그걸 놓쳤다. 이 셋을 묶으면 제품 안에 팀이 없다는 뜻이 된다. 각자 자기 기획안을 쓰는 도구는 있는데 서로가 보이지 않았다. 그래서 팀과 내 완성 콘텐츠와 트렌드 소식이 시간순으로 흐르는 뉴스피드를 만들기로 했다. 동료의 작업 히스토리를 확인하고 반응과 댓글을 주고받으면서 체류와 재방문이 늘어나는 것이 목적이었다.

가설 수립

기준선이 없는 채로 목표를 세우고, 보정하기로 했다

가설은 세 갈래였다. 매 진입마다 새 콘텐츠가 보이면 재방문과 체류가 늘고 각 기능 접근성이 오른다는 것, 팀원의 완성 콘텐츠를 읽기 전용으로 노출하면 서로 참고하고 자극받아 제작 사용량이 는다는 것, 트렌드 소식을 섞으면 별도 탭에 안 들어가던 사람도 인입을 인지한다는 것이었다. 목표치는 홈 진입 세션의 60퍼센트 이상이 다른 기능으로 이동하고, 주간 재방문율 70퍼센트, 1인당 타인 콘텐츠 열람 주 5건 이상으로 잡았다.

이 수치들에는 비교할 기준선이 없었다. 계측 자체를 이번에 처음 도입했고, 타인 콘텐츠 열람은 경로가 없었으니 현재값이 0이었다. 그래서 목표치를 초기값으로 명시하고 첫 계측 주기 뒤에 보정하기로 문서에 적었다. 분모인 팀원은 실사용 두 명으로 상정했으므로, 재방문율 70퍼센트는 사실상 두 사람이 모두 쓰면 달성이라는 뜻이었다.

v1에서는 소셜 인터랙션을 범위 밖으로 뺐다. 좋아요와 댓글, 공유는 후속으로 미루고 카드는 열람만 지원하기로 했다. 핵심부터 먼저 세우자는 판단이었는데, 배포하고 검증하던 그날 방향을 바꿨다. 직접 써보니 스레드 계열의 디자인과 활동 알림, 댓글과 좋아요가 있어야 광장이 되겠다 싶어 그것들을 v2로 승격했다.

솔루션 도출

SNS 관례를 따라 만든 것이 주 동선을 해쳤다

구현은 다섯 개의 수직 슬라이스로 나눴다. 각 슬라이스가 스키마와 소비자와 검수 대상을 함께 실어서 독립적으로 배포하고 되돌릴 수 있게 했다. 가장 먼저 배포한 것은 UI가 아니라 신뢰 문제였다. 내가 만들지 않은 완성작이 15시간 전으로 피드 상단에 떠 있었는데, 문서를 통째로 교체하는 저장 방식이 완료 시각을 지워서 열람만 해도 순서가 올라오고 있었다. 피드가 거짓말하면 피드 전체가 불신받으므로 이걸 먼저 잡고 기존 완성작 41건을 소급 보정했다.

그다음에 활동 스트림과 이모지 반응, 댓글과 알림 센터, 카드에서 기능으로 가는 딥링크, 미디어와 사람 중심의 UI 재설계를 차례로 얹었다. 읽기 권한도 이때 개편해서 멤버가 타인의 완성 콘텐츠를 읽기 전용으로 볼 수 있게 했고, 교차 조회는 반드시 게이트웨이를 거쳐 서버가 역할과 완성 상태를 다시 검증하도록 했다. 클라이언트가 보낸 계정 정보는 신뢰하지 않았다. 피드에 보이는 것과 열었을 때 허용되는 것이 어긋나면 사용자에게는 되는데 안 되는 제품이 되기 때문이다.

aidra.web.app

최종 형태. 홈의 주인공은 기획 인터뷰이고, 아래로 내려야 팀 피드가 올라온다

가장 큰 되돌림은 컴포저였다. SNS 관례를 따라 피드 최상단에 기획 입력창을 두고 거기서 새 기획을 시작하게 했는데, 써보니 이게 이 제품의 1번 액션인 기획안 작성 경험을 해치고 있었다. 인터뷰 화면이 이미 그 역할을 하고 있었으므로 입구가 둘로 갈린 셈이었다. 그래서 컴포저를 걷어내고 홈을 원래의 인터뷰 화면으로 되돌린 뒤, 피드에는 전용 탭조차 주지 않고 홈 히어로 아래로 병합했다. 최신소식 머리만 화면 끝에 걸치게 두고 스크롤 넛지로 유도해, 내려야 보이도록 낮췄다. 새로 올라온 콘텐츠가 없으면 넛지까지 함께 숨긴다. 기획안 작성이 이 제품에서 가장 중요한 액션이므로, 피드는 그 동선을 건드리지 않는 선까지만 들어가야 했다.

활동 라벨이 거짓말한 사례도 한 번 더 있었다. 기획안을 조회만 해도 자동 저장이 돌면서 서버가 작업 활동으로 기록해 이어갔다고 표시하고 있었다. 내용이 실제로 바뀐 경우에만 활동을 남기도록 게이팅했다. 두 사건 모두 읽기 경로가 쓰기를 유발하는 구조에서 나왔는데, 활동 피드의 진실성은 결국 무엇을 이벤트로 셀 것인가에 달려 있었다.

결과 & 배운 점

지표를 켜놓고 읽지는 않았다

v1과 v2, 그리고 다섯 개 슬라이스가 전부 프로덕션에 배포됐다. 오귀속 문제는 프로덕션 데이터로 재현 불가를 확인했고, 팀원이 완성 기획안을 열려다 막히던 문제도 뒤늦게 잡았다. 그 문제는 규모가 작지 않았는데, 7일간 발생한 접근 거부 401건 중 390건이 팀원이 타인 완성 기획안을 열려던 것이었다. 피드는 카드를 보여주고 있었고 누르면 막혔다.

정직하게 적어야 할 것은 세운 목표 지표 네 개를 하나도 측정하지 않았다는 사실이다. 계측은 도입했고 로그는 쌓였지만 지표로 읽는 절차를 만들지 않았다. 첫 계측 주기 뒤에 보정하겠다고 문서에 적어둔 항목은 지금도 체크되지 않은 채로 있다. 게다가 네 번째 지표는 측정 대상인 컴포저를 이틀 뒤에 삭제하면서 잴 수 없게 됐는데, 기능을 지우면서 그 목표를 같이 정리하지 않은 것은 놓친 부분이다.

그럼에도 이 개편을 성공으로 보는 이유는 판정 기준이 지표가 아니라 직접 검수하고 써보는 것이었기 때문이다. 팀원이 서로의 완성물을 볼 수 있게 됐고, 7일간 390건이나 발생하던 접근 거부 동선이 뚫렸다. 반응과 댓글로 서로의 작업에 반응하는 것도 가능해졌다. 다만 지표를 읽지 않은 것은 성공 여부와 별개로 남는 부채다. 계측을 켜는 일과 지표를 읽는 일 사이에 아무 절차가 없었다.

가장 크게 배운 것은 관례를 빌려올 때 그것이 우리 제품의 주 동선과 충돌하는지를 먼저 봐야 한다는 점이다. 상단 컴포저는 소셜 서비스에서는 옳은 패턴이지만, 기획 인터뷰가 1번 액션인 제품에서는 입구를 둘로 쪼개는 일이었다. 만들고 이틀 만에 되돌렸는데 그 판단은 지금도 옳았다고 본다. 사용자가 이미 쓰던 동선을 남의 관례로 덮으면, 새 기능이 늘어난 게 아니라 원래 잘 되던 것이 나빠진다.