Recto, 내가 만든 검증을의심한 데서 시작된 도구

안타깝게도 매번 UI 디자인을 개선할 때 A/B 테스트를 할 수 있는 기반이 마련되지 않은 상태였어요. 어느 UI 요소 하나를 바꿔보려 의견을 제시해도, 확실한 근거를 주장하는 게 아니라 추측에 의한 변경을 하게 됐어요.

이런 문제는 기획자·디자이너·개발자의 의견이 상충되면서 커뮤니케이션 비용을 키웠고, 예측이 빗나가면 그대로 리소스 낭비로 이어졌어요. 아무리 회의를 해도 결국 모두 확신 없는 주장이 됐고, 방향성을 잡아줄 지표가 필요했어요.

→ 그래서 UI 분석 툴을 만들기로 했어요.

처음에는 분석요정이라는 대화형 분석 툴을 만들었어요. 슬랙 채널에 이미지 2개를 업로드하면, 슬랙봇이 두 이미지를 분석해 결과를 텍스트로 알려주는 방식이었죠.

하지만 봇은 대조군과 실험군의 무엇을 봐야 하는지를 인식하지 못했고, 결국 한 줄짜리 평면적인 분석만 돌려줬어요. 어떤 항목을 더 섬세하게 조절하고, 여러 차원을 입체적으로 볼 수 있는 툴이 필요하다고 느꼈어요.

→ 이 결심이 Recto의 출발점이 됩니다.

Recto는 두 디자인의 픽셀을 분석해 예측 CTR을 만들고, 그걸 기반으로 시뮬레이션을 돌려 어느 쪽이 우세할지 보여주는 도구로 발전했어요. AI와 함께 30개가 넘는 요인을 점수화하고, 통계 검정까지 붙여 “데이터 기반”의 톤을 갖췄죠.

겉보기엔 완성도가 높았어요. z-test로 p값·신뢰구간·필요 표본 수까지 계산해 “통계적으로 유의함”을 출력했으니까요.

“A/B 테스트 검증 결과가 정말 실효성이 있냐”는 의심이 들었어요. 그냥 넘기지 않고 코드까지 내려가 점검했더니, 시뮬레이션 경로 자체가 순환논리였어요.

z-test 공식 자체는 수학적으로 정확했어요. 문제는 ②단계가 ①에서 내가 손으로 정한 CTR을 정답으로 두고 가짜 데이터를 만든다는 점이었어요. 그러니 표본만 키우면 검정은 내 가정을 거의 100% “유의”하다고 되돌려줬죠. 실사용자는 0명이고요.

“A/B 테스트 검증 결과가 정말 실효성이 있냐”는 의심이 들었어요. 그냥 넘기지 않고 코드까지 내려가 점검했더니, 픽셀 분석으로 산출한 예측 CTR을 기준으로 가짜 데이터만 만들어내고 있었어요. 즉, 의미 없는 난수 생성기를 만들었던 거죠.

난수 대신 가상 퍼널을 추가했어요. 시뮬레이션 속 임의 사용자가 유입 → 이탈 → 스크롤 도달 → 주목 → 클릭의 5단계 행동 퍼널을 거치도록 설계하고, 영역의 화면 내 위치와 픽셀 주목도(채도·밀도)가 단계별 전환율을 좌우해 전체 클릭률이 창발하도록 했어요. 실측으로 보증되지 않은 ‘연구’ 기반 가상 시뮬레이션임을 명시하고, 절대 수치가 아닌 A/B 상대 비교로 정직하게 제시했습니다.

이 프로젝트에서 진짜로 남은 건 도구가 아니라 판단하는 방식이었어요. 세 문장으로 정리하면 이래요.

• 예측에 검증의 언어를 빌려 쓰지 않아요. 입력으로 만든 데이터를 같은 입력으로 검증하는 건 순환이에요. ‘우세 예상’과 ‘유의함’은 다른 단어예요.
• 허점은 덮는 게 아니라 구조로 고쳐요. 난수 생성기를 의미 있는 행동 퍼널로 바꾸자, 같은 화면도 변호할 수 있는 예측이 됐어요. 대신 ‘연구 기반 시뮬레이션’임을 정직하게 못 박았어요.
• 가장 날카로운 검증은 스스로 거는 검증이에요. 남이 지적하기 전에 내 결과물의 허점을 먼저 찾는 근육이, 이번에 제품을 살렸어요.

다음 과제는 이 자기검증을 습관으로 만드는 것, 빠르게 만든 직후 한 번은 반드시 스스로 점검하는 루틴으로. 약점을 의지가 아니라 구조로 메우는 방식, 그게 이번에 가장 크게 배운 점이에요.