사용자 마찰 UI를 한 번 건드리면, 제품팀이 떠올리는 건 보통 두 가지다. 디자인이 더 깔끔해질까, 전환율이 오를까.
그런데 운영하는 입장에선 다른 게 먼저 온다. “이거 바꿨다가 지원 티켓이 늘면 누가 받지?”, “오탐이 늘면 누가 새벽에 깨지?”, “되돌릴 버튼은 있어?”
Cloudflare가 Turnstile/Challenge 페이지를 다시 설계한 글을 읽다가, 계속 같은 단어가 머릿속에 남았다. UI는 화면이 아니라 운영 비용이다. 하루에 엄청나게 많이 노출되는 화면이면, 문구 한 줄이 ‘이탈’과 ‘CS’와 ‘보안 오탐’으로 바로 바뀐다. (참고자료)
이 글은 “이 UI가 예쁘다” 같은 이야기를 하지 않는다. 대신 그 감각을 큐(Queues)와 에이전트(Copilot CLI, 오케스트레이션) 쪽으로 그대로 옮긴다. 화면이든 백그라운드 작업이든, 결국 사고는 기능이 아니라 재시도·로그·권한·롤백 같은 규칙에서 난다.
“왜 막혔는지”를 못 알아듣는 순간, 지원 티켓이 폭발한다
Turnstile/Challenge 같은 보안 UI는 이상하다. 사용자가 좋아서 보는 화면이 아니다. 문제는 이 화면이 ‘지나치게 자주’ 등장한다는 점이다. 많이 보면 많이 싫어진다.
여기서 팀이 자주 놓치는 건, UI 변경이 디자인 변경이 아니라 운영 변경이라는 사실이다.
- 문구를 바꾸면 “왜 막혔는지”를 이해하는 비율이 바뀌고
- 정보구조를 바꾸면 “어디로 문의하는지”가 바뀌고
- 접근성/일관성이 무너지면 ‘불만’이 아니라 ‘차단 우회’로 이어진다
Cloudflare 글을 보고 내가 챙긴 결론은 단순했다. 문구/구조/접근성은 결국 “지원 티켓 라우팅 비용”으로 돌아온다.
사용자 마찰을 줄인다는 건, 보안 강도를 낮추는 게 아니라 ‘불필요한 문의/오해’를 줄이는 운영 작업이다. (참고자료)
재시도가 조용히 쌓이다가 한밤중에 터진다
Vercel Queues 글을 보며 느낀 건, 큐가 “백그라운드로 밀어넣는 기술”이 아니라 “실패를 다루는 규칙”이라는 점이다. 특히 at-least-once는 구현이 아니라 약속이다. 딱 한 번만 실행되길 기대하면, 언젠가 중복 실행이 난다.
큐를 넣는 순간부터 이건 ‘코드’가 아니라 ‘정책’이 된다. (여기서 한번 삐끗하면 중복 실행/중복 과금 같은 걸로 바로 튄다.)
- 실패하면 몇 번 재시도할 건가?
- 재시도 간격은? (바로? 지수 백오프?)
- visibility timeout은 얼마나 잡을 건가?
- 중복 실행이 나도 안전한가(멱등성)?
큐가 터질 때는 “느려서”가 아니라, 재시도가 조용히 쌓이다가 한 번에 표면으로 올라와서다. 지연이 아니라 누적이다.
그래서 큐를 붙일 때는 기능보다 규칙부터 박는다.
- at-least-once면 멱등성 키를 강제(핸들러 공통 미들웨어에서 없으면 실패 처리)
- visibility timeout은 “평균 처리시간×3” 같은 식으로 시작값을 박아두기
- 재시도는 3~5회로 제한하고, 그 뒤엔 DLQ(혹은 사람 호출)
(참고자료: Vercel Queues)
자동 실행은 빠르지만, 책임 소재가 흐려지는 순간 끝난다
GitHub Copilot CLI가 보여주는 흐름은 명확하다. /plan으로 의도를 먼저 만들고, diff를 보고, 승인 후 실행으로 간다. 여기서 핵심은 모델이 아니라 “승인”이다. 어떤 범위까지 자동으로 실행할지, 누가 승인했는지, 실패하면 어디서 멈추는지.
여기서도 작은 신호가 겹치면 사고가 된다. toxic combinations을 우리말로 바꾸면 그냥 이 조합이다.
이게 웃긴 게, 각각은 별거 아닌데 금요일 밤엔 한 번에 다 뜬다. 그때부터는 “누가 승인했지?”부터 찾다가 시간을 다 쓴다.
- 밤에 올라온 변경
- 작아 보이는 diff
- 근데 위험 경로를 건드림
- 자동 실행이 켜져 있음
- 로그가 안 남음
이 조합이 금요일 밤에 한 번만 떠도, 다음 주 월요일은 회고로 시작한다. (참고자료: GitHub Copilot CLI, Cloudflare toxic combinations)
오케스트레이션 도구가 sub-agent로 작업을 쪼개고 다른 에이전트를 돌리는 내러티브도 결국 같은 함정이 있다. 더 잘게 쪼갤수록 “누가 무엇을 언제 실행했나”를 놓치기 쉽다. 사람이 보는 건 결과뿐이다. 원인은 흩어져서 찾기 힘들어진다. (참고자료: Computerworld)
내가 위키 상단에 박아두는 6줄(진짜로 6줄)
반듯한 문서 만들기 전에, 아래부터 붙여놓는다. 나중에 팀이 싸우더라도 기준점이 생긴다.
- Challenge 문구는 “왜 막혔는지/다음 행동/문의 경로” 3요소 고정
- UI 변경은 A/B 전에 롤백 스위치부터
- at-least-once면 멱등성 키 없이는 배포 금지
- 재시도 3회까지만, 이후는 DLQ(또는 사람 호출)
- 에이전트 기본값은 ‘제안’, 실행은 예외 + 승인 범위 기록
- 위험 경로(/auth,/billing,/payments) touched면 Draft + 승인 2명 + 로그 4필드(주체/리소스/시간/권한) 고정
다 지키긴 어렵다. 그래도 몇 줄만 제대로 박아도, 금요일 밤에 터지는 패턴이 바뀐다.
참고자료
- Cloudflare Blog — The most-seen UI on the Internet? Redesigning Turnstile and Challenge Pages
- https://blog.cloudflare.com/the-most-seen-ui-on-the-internet-redesigning-turnstile-and-challenge-pages/
- Vercel Changelog — Vercel Queues now in public beta
- https://vercel.com/changelog/vercel-queues-now-in-public-beta
- GitHub Blog — From idea to pull request: A practical guide to building with GitHub Copilot CLI
- https://github.blog/ai-and-ml/github-copilot/from-idea-to-pull-request-a-practical-guide-to-building-with-github-copilot-cli/
- Cloudflare Blog — Toxic combinations: when small signals add up to a security incident
- https://blog.cloudflare.com/toxic-combinations-security/
- Computerworld — Perplexity’s new Computer agent will run other agents for you
- https://www.computerworld.com/article/4138723/perplexitys-new-computer-agent-will-run-other-agents-for-you.html
댓글
댓글 쓰기