동작한다와 쓸 수 있다는 다른 문제입니다.
당시 화면에는 이런 요소가 있었습니다.
☐ 🟢 퍼블릭 페이지에 바로 발행 (체크하지 않으면 비공개 임시저장)
작은 체크박스 하나와, 그 옆에 붙은 긴 설명 문장. 이게 발행 스위치의 전부였습니다. 기술적으로는 완벽했습니다. 체크하고 저장하면 발행되고, 해제하고 저장하면 임시저장됩니다. DB의 값도 정확히 바뀌고, 목록 화면의 뱃지도 그에 맞게 표시됩니다. 자동 검증이 PASS를 준 건 거짓이 아니었습니다.
문제는 제가 이 화면을 처음 봤을 때 이렇게 물었다는 겁니다.
"저장한 글을 발행↔임시저장 전환을 어떻게 해야 하는지 방법을 모르겠어."
만든 사람이 못 찾는 버튼을, 방문자는 찾을 수 있을까요.
체크박스를 토글 스위치로 바꾸고, 설명문을 현재 상태를 말해주는 라벨로 교체했습니다.
켜짐: 🟢 발행됨 — 퍼블릭 페이지에 공개됩니다 꺼짐: ⚪ 임시저장 — 나만 볼 수 있는 비공개 상태입니다
바뀐 건 세 가지입니다. 첫째, 조작 대상이 명확해졌습니다. 체크박스는 "네모칸"이지만 토글은 "스위치"입니다. 켜고 끄는 물건이라는 게 형태로 전달됩니다. 둘째, 설명이 아니라 상태를 보여줍니다. 이전 문구는 "체크하지 않으면 비공개 임시저장"이라는 조건문이었습니다. 사용자가 머릿속에서 조건을 계산해야 합니다. 지금은 "지금 임시저장 상태입니다"라는 현재 상태 선언입니다. 읽는 순간 끝납니다. 셋째, 상태가 색으로도 전달됩니다. 켜면 초록, 끄면 회색. 글자를 읽기 전에 시야로 먼저 들어옵니다.
기능은 한 줄도 바뀌지 않았습니다. 저장되는 값도, 서버 동작도 그대로입니다. 바꾼 건 사람이 그것을 인지하는 방식뿐입니다.
관리자 화면에 글 발행 기능을 만들었습니다. AI가 돌린 자동 검증은 "발행 상태 전환 PASS"를 보고했습니다. DB 값도 바뀌었고, 목록의 뱃지도 정상적으로 갱신됐습니다.
그런데 제가 직접 화면을 열었을 때, 글을 발행하는 방법을 찾지 못했습니다.
기능은 있었습니다. 다만 그게 발행 스위치라는 걸 알아볼 수 없는 모습이었습니다. 이 글은 자동 검증이 통과시킨 기능이 왜 사람에게는 실패했는지, 그리고 그 간극에서 기획자가 무엇을 해야 하는지에 대한 기록입니다.
자동 검증이 통과시킨 이유 자동 검증 스크립트가 확인한 것은 이런 항목들입니다.
해당 요소가 화면에 존재하는가 클릭했을 때 값이 바뀌는가 바뀐 값이 DB에 반영되는가 목록 화면의 표시가 갱신되는가
전부 통과했습니다. 그리고 이 목록에 없는 것이 하나 있습니다. 사람이 그 요소를 발행 스위치로 인식할 수 있는가.
자동 검증은 요소를 좌표와 속성으로 찾습니다. 이미 답을 알고 있는 상태에서 확인하는 겁니다. 처음 보는 사람이 화면을 훑으며 "발행하려면 어디를 눌러야 하지?"라고 헤매는 과정은 스크립트에 존재하지 않습니다.
시험 문제를 낸 사람이 그 문제를 푸는 것과 같습니다. 항상 만점이 나오지만, 그게 문제가 쉽다는 증거는 아닙니다. 이건 버그가 아니라 UX 문제입니다
처음 이 상황을 마주했을 때 저는 "고장 났나?"라고 생각했습니다. 하지만 확인해보니 기능은 정상이었습니다.
이 구분이 중요합니다. 버그라면 고쳐야 합니다. UX 문제는 고칠지 말지를 판단해야 합니다. 당장 사이트가 망가지지 않고, 방법을 알면 쓸 수 있으니까요.
그래서 처음엔 미루려 했습니다. "지금은 기능을 다 갖추는 단계니 화면 다듬기는 나중에 몰아서" 라는 논리였고, 일반적으로는 맞는 판단입니다.
그런데 다시 생각해보니 이건 나중에 다듬을 장식이 아니었습니다. 제가 앞으로 이 사이트에 글을 쓸 때마다 매번 거치는 화면이었습니다. 하루에 한 번 여는 문의 손잡이가 헐거우면, 그건 인테리어가 아니라 생활의 문제입니다. 그래서 바로 고쳤습니다.
판단 기준은 이렇게 정리됐습니다. 사용 빈도가 높은 지점의 UX 문제는 기능 완성 단계에서도 즉시 고친다. 어쩌다 한 번 쓰는 화면이라면 미뤄도 됩니다.
왜 AI가 이렇게 만들었는가 AI에게 준 지시는 "발행/비공개 토글"이었습니다. 그리고 AI는 정확히 그 기능을 만들었습니다. 체크박스도 토글의 일종이니까요.
부족했던 건 그 요소가 사용자에게 어떻게 보여야 하는가에 대한 지시였습니다. AI는 기능 명세를 받으면 기능을 만듭니다. 명세에 없는 것은 만들지 않습니다. 그게 중요한지 판단하지도 않습니다.
기능 명세와 사용 경험은 다른 언어입니다. 그리고 후자를 말하는 건 기획자의 일입니다.
AI가 만든 결과물을 사람 기준으로 검수할 때 쓰는 방법입니다.
처음 보는 사람처럼 화면을 연다 만드는 과정을 지켜봤기 때문에 어디에 무엇이 있는지 이미 알고 있습니다. 그 지식을 잠시 내려놓고, "내가 이 화면에 처음 왔다면 무엇을 하려 할까"부터 시작합니다. 찾는 데 3초 이상 걸리면 그건 신호입니다.
자동 검증 PASS와 사용 가능은 분리해서 판단한다 자동 검증은 "동작한다"를 증명합니다. "쓸 수 있다"는 사람만 판단할 수 있습니다. 두 개를 같은 칸에 적지 않습니다.
설명문이 길면 UI가 잘못된 것이다 "체크하지 않으면 비공개 임시저장" 같은 안내가 필요하다는 건, 그 요소만 봐서는 이해가 안 된다는 뜻입니다. 설명을 다듬는 대신 설명이 필요 없는 형태를 찾습니다.
조건문이 아니라 현재 상태를 보여준다 "~하면 ~됩니다"는 사용자에게 계산을 시킵니다. "지금 ~입니다"는 읽는 순간 끝납니다. 상태를 다루는 UI는 거의 항상 후자가 낫습니다.
수정 범위를 좁게 지정한다 UI만 고치고 싶을 때는 "이 파일의 이 필드만, 데이터 처리 로직은 건드리지 말 것"이라고 명시합니다. 벽지를 바꾸는데 배관을 건드리면 안 되니까요. 실제로 이 원칙 덕분에 정상 동작하던 발행 로직은 한 줄도 손상되지 않았습니다.
관련 프로젝트
프로젝트 개요 기획자(PM)로서 AI를 활용한 업무 자동화(AX) 사례를 문서화하는 개인 포트폴리오 사이트입니다. 국내 기업의 AX 기획자/AI PM 직군으로의 커리어 전환을 목표로, 사이트 자체가 채용 지원용 스토리텔링 자료로 실사용되고 있습니다. 핵심 패턴: 업무 병목 발견 → AI로 워크플로우 재설계 → Before/After·근거·재현 가능성 문서화 전체 서사는 '실행하지 않은 아이디어 나열'이 아니라, 하나의 검증된 자동화 패턴과 도메인별 확장 블루프린트를 갖춘 재사용 가능한 엔진을 보유하는 방향으로 수렴하고 있습니다. 기술 스택 Next.js 16, Tailwind CSS v4, TypeScript Supabase (개발/운영 환경 분리), Vercel, Resend Claude API 기반 기술 자문 및 프롬프트 설계 보안 아키텍처 관리자 CRUD는 세션 기반 인증과 RLS(Row Level Security)로 보호 공개 읽기 전용 경로는 별도의 익명 클라이언트로 분리 서비스 롤 키는 애플리케이션 코드에서 완전히 배제 권한 검증은 마이그레이션 파일 및 대시보드 검토를 통해서만 진행 작업 방식 (에이전틱 IDE 협업 워크플로우) AI 에이전트 기반 IDE가 파일/버전관리 작업을 담당하고, LLM은 기술 자문 및 프롬프트 작성 역할을 수행하는 협업 구조를 운영합니다. AI 자문 → 에이전트용 프롬프트 작성 → 실행자가 붙여넣기 → 계획 확인 → 자문 검토 → 실행 승인 → 로그 검토 → 직접 클릭 테스트 → 명시적 지시 시에만 커밋 통제 규칙 실행 전 계획 검토 필수 요약 보고가 아닌 직접 클릭 테스트로 검증 개발 환경 우선 적용 후 명시적 승인 하에 운영 환경 반영 커밋은 명시적 지시가 있을 때만 수행 DB 자격증명 직접 연결 및 범위 외 삭제 금지 브랜치 전략: 개발 브랜치에서 작업 후 운영 브랜치는 배포 전용으로 직접 커밋 금지, 병합 전 변경 범위 검증 현재 진행 상황 고객사 미팅 브리핑 자동화 사례: 1단계 완료, 개발/운영 환경 배포 및 실데이터 테스트 완료 범위 변경 감지 자동화 사례: 상태 확인 진행 중 리스크 조기 경보 자동화 사례: 운영 환경 배포 완료 보안 사고 관련 포스트: 'AI 리스크 거버넌스 사례'로 재구성 예정 AI 활용 관련 콘텐츠 시리즈 초안 작성 완료, 게시 미확정 핵심 학습 원칙 보고가 아닌 검증: 버그·보안 이슈는 항상 직접 로그/브라우저 검토를 통해서만 발견되며, 에이전트의 자체 결과 요약을 그대로 신뢰하지 않음 보안 사고의 콘텐츠화: 실제 발생한 권한 관련 이슈 사례를 케이스 스터디로 재구성하여 콘텐츠화 커밋 의미 분리: 기능 단위/변경 유형별로 항상 분리 커밋 자동화하지 않는 것도 스토리: 저사용 빈도 기능을 의도적으로 고도화하지 않은 결정 자체를 AX 스토리텔링 소재로 활용