오피사이트라는 말을 들으면 사람마다 떠올리는 장면이 다르다. 어떤 이는 오래된 커뮤니티형 게시판을, 다른 이는 지도를 중심으로 정리된 디렉터리형 페이지를 떠올린다. 누군가는 앱 같은 반응형 인터페이스를 기대하고, 누군가는 PC 시대의 무거운 스킨을 먼저 기억한다. 내가 지난 10여 년간 실제로 운영과 컨설팅에 관여하며 겪은 바를 정리하면, 오피사이트는 '무엇을 보여주느냐'가 아니라 '어떻게 버전업되었느냐'에 따라 사용자 경험, 안정성, 노출 전략, 수익 모델이 완전히 달라진다. 겉으로 비슷해 보여도 버전마다 철학이 다르다. 이 글은 그 차이를 현장에서 체감한 사례와 함께 풀어낸다.
버전을 나누는 방법, 연대기보다 기능 전환으로
연도별로 1.0, 2.0, 3.0이라 표기하면 간단하지만, 실제로는 기능 전환점이 경계를 만든다. 내가 주로 쓰는 분류는 다음 네 갈래다. 초기 게시판형, 디렉터리형, 하이브리드형, 플랫폼형. 각 단계는 이전 세대의 문제를 해결하려고 등장했고, 동시에 새로운 비용과 리스크를 가져왔다. 흐름을 이해하면 선택과 투자가 쉬워진다.
게시판형 - 속도와 익명성이 강점인 첫 세대
초기 오피사이트는 카페나 포럼에 가까웠다. PHP 기반의 게시판 스킨, 닉네임과 간단한 인증, 텍스트 중심의 글과 댓글. 데이터 스키마가 단순해 운영이 편했고, 트래픽이 몰려도 서버 한 대와 캐시 정도로 버텼다. 새로운 글이 올라오면 사용자들이 실시간으로 반응했고, 반응이 반응을 불러 커뮤니티가 자랐다.
다만 게시판형은 정보가 흐른다. 하루가 지나면 금쪽같은 후기와 좌표가 타임라인 아래로 가라앉는다. 도리어 오래된 루머가 재순환되기도 했다. 검색 기능은 있었지만 제목 검색 정도가 전부였고, 필터는 태그에 의존했다. 태그는 사람이 붙이니 품질 편차가 컸다. 운영 측면에서는 신고 처리와 게시글 정리가 벅찼다. 삭제 요청이 들어오면 관리자 계정으로 들어가 직접 게시물을 찾아 지워야 했고, 비슷한 분쟁이 반복되면 커뮤니티 피로도가 치솟았다.
또 하나, 게시판형은 봇과 스팸에 취약했다. 캡차를 붙이고도 새벽 시간에 광고가 쏟아졌다. 사용자를 보호하려면 승인제나 레벨제를 적용해야 했는데, 그러면 신규 유입이 줄었다. 양날의 검이었다. 공지로 룰을 정해도 해석의 여지가 생기면 종종 말싸움으로 번졌다. 결국 운영자가 중립을 지키는 것이 핵심이었고, 이때의 공정성 평판이 이후 버전으로 넘어갈 때까지 영향을 줬다.
디렉터리형 - 구조화와 탐색의 세대
검색성에 목마른 운영자들은 디렉터리형으로 전환했다. 지도를 연동하고 구/군 단위로 카테고리를 만들고, 필터를 빼곡하게 달았다. 전화번호, 영업 시간, 가격대, 후기 요약, 방문 사진을 정리하면 사용자들은 시간 낭비 없이 선택할 수 있었다. 구조화된 데이터는 SEO에도 강했다. 스키마 마크업을 붙이면 검색 결과에 별점과 위치가 노출되면서 자연 유입이 늘었다.
하지만 정돈의 대가가 만만치 않았다. 데이터 최신화가 숙제였다. 영업 시간이 바뀌거나 이전, 휴무, 폐업 같은 변동이 1년에 수천 건씩 발생한다. 크롤러로 공식 사이트와 지도 정보를 긁어도 정확도는 80% 언저리에 머문다. 남은 20%를 보정하려면 현장 피드백과 운영진 검수가 필요하다. 내가 관리했던 디렉터리형 사이트는 하루 평균 30건의 수정 요청이 들어왔다. 그중 절반은 중복, 나머지 절반에서 실제 변경이 확인됐다. 결국 지역 담당 에디터를 두거나, 사용자 보상 시스템을 설계해 자발적 업데이트를 이끌어야 했다.
디렉터리형은 디자인도 고려할 것이 많다. 필터가 많아질수록 선택 마비가 온다. 초기에 필터 18개를 노출했다가 이탈률이 12%포인트나 상승한 적이 있다. 최종적으로는 필터를 네 가지로 줄이고, 상황별 프리셋을 제공해 이탈을 5%포인트 개선했다. PC에서는 측면 필터, 모바일에서는 바텀시트를 쓰는 패턴이 체감상 가장 깔끔했다. 지도를 기본 뷰로 할지 리스트를 기본으로 할지도 고민해야 한다. 도시 밀집 지역에서는 지도 초기화면이 성능과 가독성에서 불리했다. 웬만하면 리스트 우선, 지도는 상세 보기에서 띄우는 방식을 추천한다.
수익 모델도 바뀐다. 게시판형이 광고 배너와 제휴 배너에 의존했다면, 디렉터리형은 노출 순위와 스폰서드 슬롯이 핵심 상품이다. 물론 표시를 명확히 해야 한다. 스폰서 표시가 애매하면 커뮤니티 신뢰가 흔들린다. 나쁜 예로, 강조 색을 유사 색상으로 처리해 눈속임을 시도했다가 항의 메일이 폭발했던 사례가 있었다. 이후로는 스폰서 라벨을 텍스트로 박아서 논란을 줄였다.
하이브리드형 - 소셜과 구조의 절충
하이브리드는 디렉터리의 구조 위에 커뮤니티의 자유도를 얹은 형태다. 항목은 정돈되어 있고, 그 아래에 후기, 사진, 단문 코멘트가 연속해서 쌓인다. 좋아요, 북마크, 공유 링크 같은 소셜 기능이 붙는다. 여기서는 사용자 프로필의 무게가 달라진다. 익명성은 보장하되 활동 이력이 신뢰 신호가 된다. 사진 촬영 EXIF, 방문 시간, 리뷰 길이, 신고 이력 등을 기준으로 신뢰 점수를 산정하면 노출 품질이 눈에 띄게 좋아진다.
다만 신뢰 점수는 차별 논란의 불씨가 된다. 자동 필터가 특정 사용자의 글을 묻으면 "검열" 비판이 따라붙는다. 나는 점수의 관여도를 낮추고, 노출에 미치는 영향을 20% 이내로 제한했다. 나머지는 최신, 가까운 순, 맞춤 선호도로 분산했다. 그리고 사용자에게 자신의 신뢰 점수 대략치를 밴드로 보여주었다. 기준을 투명하게 적어두고, 이의 신청 버튼을 붙이니 분쟁이 크게 줄었다. 이 과정에서 사람이 들어가는 큐레이션은 여전히 중요하다. 모니터링 팀이 태그 오분류, 중복 점포, 전단광고성 후기 등을 주기적으로 정리해야 하니 비용이 든다. 반대로 정리된 느낌은 체류 시간을 늘려 광고 효율을 끌어올린다.
커뮤니티 기능이 붙으면 알림 설계가 열쇠다. 좋아요, 댓글, 멘션, 북마크 업데이트 알림이 쏟아지면 앱을 지워버리는 사람들이 나온다. 기본값을 보수적으로 두고, 알림 타입을 세분화해서 사용자가 스스로 묶음 빈도를 선택하도록 하자. 서버 부하도 간과하면 안 된다. 한때 푸시 스파이크로 알림 큐가 지연되어, 이벤트가 30분 뒤 몰아서 도착한 적이 있다. 그날 활성 사용자가 7% 감소했다. 이후에는 큐 분산과 리트라이 백오프를 붙였고, 야간에는 딥 슬립 모드로 알림을 하루 두 번만 묶어 보냈다.
플랫폼형 - 예약, 결제, 메시징까지 들어오는 완성 단계
플랫폼형은 정보 제공을 넘어 거래가 이루어진다. 예약, 보증금 결제, 취소와 환불, 리뷰 검증까지 풀 스택으로 붙는다. 장점은 명확하다. 사용자는 한 곳에서 발견하고, 예약하고, 평가한다. 운영자는 매출과 재방문 데이터를 보유하며, 그 데이터로 다시 추천 모델을 고도화한다. 매출이 발생하면 CS의 성격도 달라진다. 후기 중재에서 결제 분쟁으로 중심이 이동한다.
이 단계에서 가장 큰 변화는 신뢰 장치다. 방문 인증을 해야 리뷰를 남길 수 있게 하거나, 예약 후 실제 방문 여부를 자동으로 체크한다. 노쇼를 줄이려면 보증금 제도를 들여오는데, 취소 정책과 환불 속도에서 이용자 만족도가 갈린다. 보증금을 걸 때는 수수료 구조를 투명하게 알리고, 부분 취소가 가능한 조건을 세밀하게 적어야 한다. 내 경험상 취소 규정을 세 줄로 단순화했을 때 CS 문의가 일시적으로 줄었지만, 분쟁 시 조정의 여지가 없어 만족도가 오히려 떨어졌다. 결국 케이스별 가이드라인을 준비해 상담사가 1차에서 80%를 해결하도록 만드는 편이 낫다.
결제 시스템은 장애에 민감하다. 한 번의 결제 실패율이 2%를 넘으면 고객의 신뢰가 급격히 낮아진다. 결제 실패는 카드사 이슈, 3DS 인증 타임아웃, 네트워크 단절 등 원인이 다양하니 실패 사유를 상세 표기하고 대체 수단을 바로 제시해야 한다. 나는 결제 실패 시 메시징을 이렇게 정리했다. “3분 뒤 자동 재시도, 다른 카드 사용, 가상계좌로 전환” 세 가지 버튼을 순서대로 보여주고, 실패 로그를 곧바로 서버에 올려 카드사와 공유했다. 이 단순한 흐름만으로도 성공률이 1.4%포인트 개선됐다.
플랫폼형은 법적 준수도 복잡해진다. 전자금융업 연계, 개인정보 암호화, 통신판매중개업 신고, 약관 고지, 청소년 보호고지 등 체크리스트가 길다. 데이터 보관 기간을 과하게 잡으면 리스크가 누적되니, 수집 목적별로 폐기 스케줄을 자동화하자. 암호화 키 관리와 접근 로그는 외부 감사를 염두에 두고 준비해야 한다. 실무에서는 이상징후 탐지를 간단히라도 구성해두면 도움이 된다. 새벽 시간대 특정 IP 블록에서 예약 취소를 반복하는 패턴이 감지되면, 보증금 환불을 지연해 수작업 검수 단계를 넣는다.
버전이 바뀌면 사용자도 바뀐다
게시판형에서 활발하던 '글쓴이'는 디렉터리형에 오면 '검색자'가 된다. 하이브리드형은 '기여자'를 늘린다. 플랫폼형에서는 '구매자'가 중심이 된다. 동일한 사람이라도 맥락이 바뀌면 행동이 바뀐다. 그래서 버전 전환 시 KPI도 달라져야 한다. 게시판형의 핵심은 일평균 게시글 수와 반응 속도였다. 디렉터리형은 검색-상세-전화/지도 클릭으로 이어지는 전환율, 하이브리드는 후기 생산과 검수 통과율, 플랫폼형은 예약 성공률과 재방문율이 중심 지표다. 팀이 같은 지표를 붙잡고 있으면 기능 개발 우선순위가 맞춰진다.
마케팅 채널도 세대마다 다르게 먹힌다. 게시판형은 자생적 바이럴이 강했고, 디렉터리형은 검색 유입이 압도적이었다. 하이브리드는 인플루언서와 UGC가 잘 붙는다. 플랫폼형은 리마케팅이 수익에 직결된다. 현장에서 느끼기에, 성숙기 플랫폼형에서는 신규 유입 1보다 재방문 0.3이 더 값졌다. 예약 경험이 매끄러웠다면 푸시 하나로 다시 움직인다. 이때 쿠폰은 신중히 써야 한다. 할인에 길들이면 정가 전환이 어렵다. 대신 혜택을 빠른 시간, 좋은 슬롯, 선접근 같은 비금전적 인센티브로 설계하면 수익성이 유지된다.
기술 스택과 유지보수, 버전에 맞게 가볍게
가끔 초기부터 마이크로서비스를 도입해 아키텍처를 복잡하게 만드는 팀을 본다. 게시판형이나 초창기 디렉터리형에는 단일 리포지토리와 모놀리식 서버가 오히려 빠르다. 글쓰기, 댓글, 알림이 얽혀 있어 트랜잭션 일관성이 중요하고, 팀도 작기 때문이다. 성장이 시작되고 동시 접속이 늘면 읽기와 쓰기를 분리하고, 검색을 엘라스틱 같은 외부 엔진으로 빼는 정도가 1차 확장 포인트다.
하이브리드형부터는 이미지와 동영상 처리가 비용을 끌어올린다. 원본 저장 정책을 고민하자. 실무에서는 원본을 S3 같은 오브젝트 스토리지에 냉동, 게시용은 리사이즈해 CDN으로 제공한다. 저장비를 아끼려고 한참 지나 원본을 지웠다가 분쟁 시 증거가 없어 곤란했던 기억이 있다. 민감한 데이터는 기간을 정해 암호화된 별도 버킷에 보관하는 절충이 안전했다.
플랫폼형에서는 메시지 큐, 예약 스케줄러, 상태머신 같은 것들이 필수다. 예약 상태가 대기, 확정, 취소, 환불대기, 환불완료로 흘러가는데, 상태 전이가 꼬이면 CS 폭탄이 터진다. 상태 전이를 코드로 고정하지 말고, 테이블로 설정화해 배포 없이 정책을 수정할 수 있게 해두면 야간 이슈 대응이 빨라진다. 모니터링은 사용자 여정 기준으로 잡자. 목록 조회 - 상세 보기 - 예약 시도 - 결제 성공까지의 퍼널에 에러율과 지연 시간을 붙이고, 임계치 초과 시 자동 롤백을 건다. 특정 버전에서 상세 조회가 2초를 넘어가면 예약 전환이 8% 가까이 떨어지는 경향을 여러 번 확인했다.
검색과 추천, 숫자보다 감각이 이길 때
디렉터리형과 하이브리드형에서 검색과 추천의 품질이 사용자 만족을 갈라놓는다. 수치 모델을 돌려도 마지막에는 감각이 필요하다. 특정 지역에서 평점이 비정상적으로 높게 나오는 경우, 후기 길이나 사진 개수를 가중치에 넣으면 균형이 맞는다. 텍스트 임베딩을 써서 비슷한 취향을 묶을 때, 설명 문구를 과하게 믿지 말자. 복사-붙여넣기 홍보 문구가 벡터 공간에서 가까워져 상위에 몰리는 일이 발생한다. 나는 후기 작성 시간을 정상화하고, 긴 글 중에서도 고유 문장을 찾아 점수를 주는 방식으로 보정했다.
추천에서 가장 중요한 것은 실패했을 때의 부작용이다. 취향이 다른 결과를 보여줘도 유저는 한 번 더 스크롤한다. 오피사이트 하지만 완전히 동떨어진 결과, 예를 들어 위치를 무시하고 반대편 끝을 추천하면 바로 이탈한다. 그래서 추천에서 위치 가중치는 최종 점수의 40% 이상을 유지했다. 취향 적합도는 30%, 신뢰 신호 20%, 신선도 10%로 조정했는데, 이 구성이 체감상 가장 무난했다. 계절성과 날씨도 변수다. 장마철에는 이동 반경이 줄어든다. 비 예보가 있을 때는 반경 기본값을 3km에서 1.5km로 줄이는 실험에서 클릭률이 9% 상승했다.
신뢰와 안전, 규칙을 적고 지켜야 지킨다
버전이 올라갈수록 신뢰 이슈가 중요해진다. 후기 조작, 허위 정보, 악성 신고, 사진 도용 등 케이스가 늘어난다. 운영팀의 첫 원칙은 일관성이다. 규칙을 문서로 만들고, 내부 교육을 반복하고, 사용자에게 룰을 공개하자. 룰의 핵심은 간단해야 한다. 사진 합성 금지, 후기 대가성 표기 의무, 개인정보 노출 금지, 명예훼손성 표현 금지 같은 원칙을 예시와 함께 명시하면 분쟁의 70%는 초기에 걸러진다. 남는 30%는 회색지대다. 이때는 복수의 운영자가 합의로 결정하고, 이의 제기 창구를 열어두는 편이 공정하다.
악성 신고를 걸러내려면 반복 패턴을 본다. 특정 사용자나 특정 지역을 표적으로 삼아 연속 신고를 넣는 계정은 신속히 제한한다. 반대로 진짜 신호를 놓치지 않으려면 가중치가 필요하다. 과거에 유효 신고를 많이 한 사용자에게는 신고 효력을 높여 일시 노출 제한을 걸 수 있게 한다. 나는 유효 신고율 60% 이상 사용자에게만 임시 블라인드 권한을 주었고, 오탐이 반복되면 권한을 회수했다. 현장에서 이 균형이 체감 만족도를 좌우한다.
수익 모델, 버전과 함께 성숙시키기
광고는 여전히 중요하지만, 버전이 진화하면서 수익 모델도 다변화해야 한다. 디렉터리형에서는 스폰서 슬롯과 지역 배너가 기본이다. 하이브리드형에서는 프로필 강화, 후기 상단 고정 같은 크리에이터형 상품이 붙는다. 플랫폼형에서는 예약 수수료, 보증금 정산, 프로모션 툴, CRM 도구가 주력이다. 판매는 계절과 이벤트에 민감하다. 명절 전후, 급격한 변동이 온다. 성수기에는 과도한 할인 경쟁을 피하고, 노출 보장과 데이터 리포트를 묶어 가치를 강조하자. 나는 30일간의 검색어 리포트와 고객 동선 분석을 제공하는 패키지로 평균 객단가를 1.7배 높였다.
수익과 사용자 경험은 당겨 놓으면 한쪽이 내려간다. 화면 상단을 광고로 채우면 단기 수익은 좋아지지만, 장기 체류와 후기 생산이 떨어진다. 어느 지점에서 균형을 잡을지 수치로 미리 정해두자. 예를 들어, 유료 슬롯 비율이 리스트의 20%를 넘으면 추천 품질 만족도가 하락하는 경향이 반복되었다. 15%를 상한으로 고정해놨더니 중장기 지표가 안정됐다.
이행 전략, 버전 사이를 안전하게 건너는 법
게시판형에서 디렉터리형, 또는 하이브리드형으로 넘어갈 때 가장 위험한 구간은 중간 단계다. 기능이 늘어났지만, 사용자에게 왜 좋은지 아직 전달되지 않았을 때 이탈이 발생한다. 전환은 스위치를 한 번에 내리는 일이 아니다. 구버전과 신버전을 한동안 병행하는 게 안전하다. 데이터 구조가 바뀔 경우에는 마이그레이션에 인내심이 필요하다. 태그를 카테고리로 전환할 때 자동 매핑의 정확도가 70%를 넘기 어렵다. 나머지 30%는 사람 손이 필요하다. 커뮤니티에서 힘을 빌리자. 참여자에게 한 항목당 소액의 크레딧을 제공하고, 검수자에게는 더 높은 보상을 주는 2단계 작업 흐름을 만들면 품질이 성큼 올라간다.
프런트에서는 A/B 테스트를 작게 여러 번 돌리는 편이 UX 충격을 완화한다. 지도 우선 레이아웃, 카드형 리스트, 스크롤 깊이에 따른 필터 고정 위치 등 세부를 다듬어야 한다. 실수로 필터 초기화 버튼을 상단에 둔 적이 있는데, 사용자가 스크롤 도중 오작동해 검색어가 사라지는 일이 잦았다. 버튼을 하단 모서리로 옮기고, 두 번 탭해야 초기화되게 바꾸니 일이 해결됐다.
데이터 프라이버시, 보이는 것보다 보지 않는 것이 더 중요하다
로그 수집은 유용하지만, 불필요한 것을 모으면 위험만 쌓인다. 정확한 목적을 정하고 최소한으로 수집하자. 위치 데이터는 좌표 그대로 저장하지 말고, 격자 단위로 라운딩해 보관하면 개인정보 노출을 줄일 수 있다. 사용자 식별자는 가능한 한 일회용 토큰으로 바꾸고, 결제 정보는 전용 결제대행사에 위탁하자. 접근 권한은 직무별로 나누고, 일시 권한을 발급하는 절차를 시스템화하는 것이 실무에서 가장 효과적이었다. 내부에서 일어난 오남용은 외부 공격보다 무섭다. 로그 열람 기록을 남기고 무작위 샘플로 감사를 돌리면 억제력이 생긴다.
성능과 접근성, 느린 사이트는 신뢰를 잃는다
모바일 웹에서 LCP가 2.5초를 넘는 순간, 사용자는 신뢰를 잃는다. 오피사이트는 이미지가 많고 지도 SDK가 무겁다. 지도를 초기 로드에서 빼고, 스크롤 400px 아래에서 지연 로딩하면 첫 화면이 빨라진다. 이미지도 화면 크기에 맞춰 서빙하자. 4K 사진을 그대로 내려받는 바람에 데이터 요금 폭탄을 맞게 했던 적이 있다. 이후에는 WebP와 AVIF로 포맷을 전환하고, 네트워크 상태에 따라 해상도를 조절했다. 저대역폭 모드에서는 리스트 썸네일을 회색 블러로 대체하고, 사용자 상호작용 시 고해상도를 불러오게 하니 체감 속도가 크게 개선됐다.
접근성은 과제라기보다 기회다. 색 대비, 키보드 탭 네비게이션, 스크린리더 레이블, 터치 타깃 크기. 이런 기본기가 갖춰지면 사용자층이 넓어진다. 작은 변화로도 결과가 나온다. 버튼 라벨에 구체 동사를 쓰고, 에러 메시지에 해결 방법을 함께 적으면 CS가 줄어든다. “예약 실패” 대신 “예약이 완료되지 않았습니다. 다른 결제 수단을 선택하거나 3분 뒤 재시도하세요.” 같은 문장이 도움을 준다.
지역성과 규제, 맥락을 존중해야 오래간다
오피사이트는 지역성이 강하다. 같은 기능이라도 서울과 지방 중소도시의 사용자 행동이 다르다. 대중교통이 편한 지역은 반경 필터가 넓고, 차가 필요한 지역은 주차 여부가 결정적이다. 지역마다 신고 문화도 다르다. 어떤 곳은 느슨하고, 어떤 곳은 엄격하다. 운영팀에 지역 담당을 두고 로컬 피드백을 받아 반영하면 불필요한 마찰을 줄일 수 있다.
규제는 변한다. 특정 키워드 사용 제한, 광고 표기 강화, 이용자 보호 장치 요구, 심지어 영업시간 노출 방식까지 권고가 내려온 적이 있다. 정책 변경이 감지되면 규칙 페이지를 업데이트하고, 알림으로 공지하자. 변경 이유를 짧게라도 설명하면 납득이 빨라진다. 현장에서는 규칙을 남의 탓으로만 돌리는 메시지가 오히려 반발을 키웠다. "법이 바뀌어 어쩔 수 없다" 대신, "안전하게 이용하실 수 있도록 일부 노출 방식을 조정했다" 같은 톤이 부드럽다.
어떤 버전이 우리에게 맞을까
운영 자원, 기술 역량, 목표 수익, 리스크 감수 성향을 냉정히 보자. 초기 팀이라면 하이브리드의 유혹을 잠시 미루고 디렉터리형에 집중하는 편이 안전하다. 구조를 먼저 잡고, 후기 생산은 커뮤니티와 파트너십으로 천천히 늘려도 늦지 않다. 일정 수준의 신뢰와 트래픽이 쌓였을 때 플랫폼형으로 넘어가는 것이 비용 대비 효율이 좋다. 반대로 이미 커뮤니티가 강하고 자발적 후기 풀이 탄탄하다면 하이브리드로 전환해 가치를 살리고, 광고 의존도를 낮추는 전략이 현명하다.
초심은 단순하다. 사용자가 시간을 아끼고, 불확실성을 줄이는 경험을 주는가. 버전이 바뀌어도 이 질문은 변하지 않았다. 화려한 기능보다 발견 - 비교 - 결정의 세 단계를 매끄럽게 만드는 것이 우선이다. 그 다음이 거래, 그 이후가 자동화다.
빠르게 점검하는 버전 선택 체크리스트
- 현재 핵심 지표가 무엇인가. 게시글 수, 검색 전환, 후기 생산, 예약 성공률 중 어디에 투자해야 하는가 운영팀이 하루에 처리할 수 있는 신고, 수정, CS 티켓 수는 얼마인가. 그 한도 내에서 기능을 설계했는가 검색과 추천에서 위치 가중치, 신뢰 신호, 신선도 비율을 수치로 정했는가 수익 모델의 상한선을 정했는가. 유료 슬롯 비율, 광고 노출 영역, 할인 정책의 범위가 문서화되어 있는가 알림과 메시지의 기본값이 보수적으로 설정되어 있는가. 사용자 제어권을 충분히 제공하는가
마무리의 자리에서, 현장에서 배운 작은 디테일들
공들여 만든 기능이 의외의 이유로 외면받을 때가 많다. 지도 마커가 너무 촘촘해 손가락으로 눌러지지 않는다든가, 리뷰 쓰기 버튼이 스크롤을 조금만 내려도 사라진다든가. 모니터 앞에서 발견하기 어렵다. 그래서 나는 현장 테스트를 종종 했다. 번화가 카페에 앉아 처음 쓰는 사람 옆에서 화면을 바라보면 한숨 섞인 터치가 어디에서 나오는지 보인다. 30분이면 열 가지는 고칠 게 보인다.
데이터는 방향을 알려주고, 사람은 속도를 만든다. 버전은 형태가 아니라 약속이다. 사용자에게 어떤 길을 제시하겠다는 약속, 파트너와 어떤 정보를 교환하겠다는 약속, 팀이 어떤 리듬으로 개선하겠다는 약속. 그 약속을 지키기 쉬운 버전을 고르자. 그러면 다음 버전으로 넘어갈 때도 자연스럽다.