세 번 실패해야 보이는 것
'30초 만에 퀴즈를 만들어 준다'는 기능을 붙이는 데 총 세 번의 시도가 필요했다. Quizzy 개발자가 dev.to에 공유한 이 사례는 단순한 개발 후기가 아니다. AI를 실제 프로덕트에 녹여 넣을 때 맞닥뜨리는 UX·비용·기술 마찰이 압축된 실전 지도다.
첫 번째 시도는 'BYO-AI 폼'이었다. 사용자가 직접 ChatGPT나 Claude에 프롬프트를 붙여넣고, AI가 뱉은 JSON을 다시 앱에 붙여넣는 구조. 이론적으로는 비용도 없고 우아하다. 현실에서는 여덟 살짜리 아이가 스트리밍이 끝나기 전에 응답을 복사해 붙여넣었고, 절반짜리 JSON 객체가 에러 배너를 만들었다. 개발자가 만들고 싶었던 것은 기능이었지만, 실제로 배포한 것은 '개발자용 인터페이스'였다.
두 번째 시도는 AI가 직접 /api/generate-quiz에 POST 요청을 보내게 하는 방식. 사용자가 프롬프트를 붙여넣으면 퀴즈가 마법처럼 앱에 나타나는 흐름이었다. 멋진 아이디어지만, 대부분의 AI 에이전트는 임의의 외부 URL로 POST 요청을 허용하지 않는다. 세 번째는 퀴즈 데이터를 URL 쿼리스트링에 구겨 넣어 GET 요청으로 우회하는 방법이었다. 브라우저와 프록시의 URL 길이 제한(2k~8k)이 10문항 퀴즈를 가볍게 초과했다. 영리한 파이프라인은 두 번 모두 출시되지 못했다.
결국 살아남은 것은 '관대한 파서'
세 번의 실패 끝에 실제로 배포된 해법은 놀랍도록 단순하다. JSON 대신 JSONL(줄 단위 JSON)을 요청하고, jsonrepair 라이브러리로 사용자가 붙여넣은 지저분한 텍스트를 조용히 복원한다. 절반만 복사해 붙여넣으면 에러 대신 짧은 퀴즈가 나타난다. AI 응답 앞뒤에 붙는 '물론입니다! 아래에 퀴즈를 준비했습니다'라는 친절한 문장도 파서가 알아서 걷어낸다.
이 결론이 시사하는 바가 크다. 좋은 UX는 영리한 아키텍처가 아니라 관대한 파서처럼 보일 때가 많다. 사용자의 도구(외부 AI)가 만드는 거친 엣지케이스를 사용자 탓으로 돌리지 않고 제품이 흡수하는 것—그것이 이 사례가 세 번의 실패에서 건진 핵심 원칙이다.
스크린샷은 증거가 아니다: AI 에이전트의 디버깅 문제
같은 맥락에서 dev.to에 게재된 또 다른 글은 AI 에이전트가 브라우저를 '보는' 방식의 근본적인 한계를 짚는다. 스크린샷은 체크아웃 버튼이 비활성화됐다는 사실을 보여줄 수 있다. 하지만 어떤 API 요청이 실패했는지, 응답 코드가 401인지 500인지, CSP 규칙이 스크립트를 차단했는지, 하이드레이션이 실패했는지는 알려주지 않는다.
Chrome for Developers가 Chrome DevTools MCP를 안정화 버전으로 발표한 것은 이 맥락에서 의미 있는 진전이다. 콘솔 로그, 네트워크 요청, 퍼포먼스 트레이스, Lighthouse 리포트를 에이전트가 직접 읽을 수 있게 됐다. 스크린샷은 증상을 보여주고, 브라우저 상태는 원인을 알려준다. 에이전트에게 필요한 것은 예쁜 스크린샷이 아니라 런타임 증거다.
더 나아가 이 글은 '로그인된 브라우저 세션'이라는 차원을 새로 열어젖힌다. 에이전트가 로그인 상태의 Chrome 세션을 제어할 수 있다면, 그것은 단순한 검사 도구가 아니라 위임된 권한(delegated authority)이 된다. 청구 설정 변경, CMS 포스트 발행, CRM 레코드 수정—이런 작업은 에이전트가 '브라우저를 사용하는' 것이 아니라 '사용자를 대신해 행동하는' 것이다.
여기서 핵심 명제가 나온다. '조심해'라는 프롬프트는 권한 체계가 아니다. 어떤 세션이 노출되는지, 어떤 동작이 읽기 전용인지, 어떤 쓰기가 승인을 요구하는지, 변경 후 무엇이 증거로 남는지—이 제어 레이어를 명시적으로 설계하지 않으면 AI 에이전트의 브라우저 작업은 신뢰할 수 없는 블랙박스가 된다.
Claude Code 위임 철학: 정리하지 말고 위임하라
MODAY를 공개적으로 구축하고 있는 개발자 Yoskee의 경험은 또 다른 각도에서 같은 주제를 건드린다. 그의 Claude Code 활용 원칙은 단 한 문장으로 압축된다. '정리하지 말고, 위임하라.'
CLAUDE.md 파일을 손수 작성하는 대신, Claude Code에게 직접 유지하게 했다. 세션을 목적별로 나누지 않고 작업의 흐름에 따라 느슨하게 분기한다. 기술적 지시보다 비즈니스 맥락만 전달하고, 에이전트가 판단을 돌려줄 때는 '직접 결정해'라고 답한다. 매일 GA4 데이터를 순찰하고 개선안을 제안받은 뒤 GO/NO-GO만 결정한다.
이 워크플로우의 핵심은 '정리하는 행위' 자체를 위임한다는 데 있다. 개발자가 구조를 설계하는 게 아니라, 에이전트가 컨텍스트를 스스로 축적하고 유지하도록 권한을 넘긴다. 인간이 하는 일은 판단의 방향을 가리키는 것, 그리고 위험한 계약(은행 계좌, API 키 발급 등)만 직접 처리하는 것이다.
세 사례가 가리키는 하나의 설계 원칙
퀴즈 생성기, Chrome DevTools MCP, Claude Code 위임—세 이야기는 표면적으로 다르지만 같은 질문을 공유한다. AI와 사용자(혹은 개발자) 사이의 경계를 어떻게 설계할 것인가.
Quizzy 사례에서 경계는 'AI가 만든 출력물과 우리 앱 사이의 파싱 레이어'였다. 그 경계를 엄격하게 두면 JSON 에러가 사용자를 막아섰고, 관대하게 두자 퀴즈가 완성됐다. Chrome DevTools MCP 사례에서 경계는 '에이전트가 볼 수 있는 것과 행동할 수 있는 것 사이의 승인 라인'이다. 그 경계가 없으면 에이전트의 브라우저 작업은 감사할 수 없는 행동이 된다. Claude Code 위임 사례에서 경계는 '인간이 판단을 내려야 하는 최소 영역'이다. 그 경계를 명확히 하자 나머지 모든 것이 위임 가능해졌다.
프로토타입이 아니라 프로덕트를 만들 때
빠른 프로토타이핑은 AI 덕분에 훨씬 쉬워졌다. 하지만 프로토타입이 프로덕트가 되는 순간, 마찰은 기술적 한계가 아니라 설계 결정에서 온다. 어떤 에러를 사용자에게 보여줄지, 어디서 에이전트의 행동을 멈추게 할지, 무엇을 위임하고 무엇을 직접 쥘지.
Quizzy 개발자가 세 번째 시도 끝에 발견한 것은 더 영리한 알고리즘이 아니었다. 사용자의 불완전한 행동을 제품이 흡수하는 구조였다. Chrome DevTools MCP가 진짜로 여는 것은 에이전트의 '시야'가 아니라 에이전트와 신뢰 가능한 위임 체계를 구축하기 위한 인프라다. Yoskee가 MODAY를 운영하며 체득한 것은 도구의 사용법이 아니라 판단을 위임하는 기술이다.
AI 도구를 프로덕트에 통합하는 실전 루프는 결국 이 세 동사로 돌아온다. 위임하고, 디버깅하고, 반복하라. 순서보다 중요한 것은—각 단계에서 경계를 먼저 설계하는 것이다.