프로덕트 소식은 넘쳐나지만 대부분 이런 게 나왔대에서 끝납니다. 그래서 뭘 어떻게 하라고? 내 작업에 어떻게 써먹지? 거기까진 연결이 잘 안 되죠. 따라서 요즘 프로덕트 메이커는 바로 쓸 수 있는 것, 그 중에서도 주목해볼 만한 것을 엄선해서 매주 금요일에 전달드리려 합니다.

요즘 프로덕트 메이커는 매주 세 가지를 골라 전합니다:

써볼 것: /goal - AI에게 목표만 주고 손 떼는 명령어, 제대로 쓰는 법
참고할 것: Gemini Intelligence - 구글이 안드로이드를 AI 에이전트 기기로 바꾸기 시작했다
적용해볼 것: AI가 만든 결과물, 마크다운 대신 HTML로 받아보기

1. 써볼 것: AI에게 목표만 주고 손 떼는 명령어, 제대로 쓰는 법

/goal은 AI에게 완료 조건을 한 번만 알려주면, 그 조건이 충족될 때까지 알아서 작업을 계속하게 만드는 명령어입니다. 원래 OpenAI Codex(코덱스)에 추가된 기능이였으나, 5월 12일 Claude Code(클로드 코드)에도 추가되면서 주요 AI 코딩 도구에서 모두 쓸 수 있게 됐습니다. X(구 트위터)의 klöss(@kloss_xyz)가 이 명령어를 구조적으로 잘 쓰는 방법을 공유했는데, X에서 꽤나 관심을 받았습니다.

왜 관심을 끄는지 이해하려면 먼저 기존의 불편함을 알아야 합니다. AI 코딩 도구로 큰 작업을 시킬 때, 종종 이런 일이 벌어집니다.

AI: (작업 하다가 중간에 멈춤)
사용자: 계속해
AI: (다시 작업하다 또 멈춤)
사용자: ..계속해

이걸 수십 번 반복하다 보면, AI한테 일을 시키는 건지 사람이 AI를 감시하는 건지 구분이 안 되죠.

무슨 문제를 해결해 주나요?

/goal이 해결하는 건 바로 이 반복 입력 문제입니다. 사용자가 완료 조건을 한 번 설정하면, AI는 매 작업 단계가 끝날 때마다 스스로 확인합니다. 조건이 충족됐는지 아닌지. 충족되지 않았으면 다음 단계를 자동으로 시작하고요.

여기서 중요한 점이 하나 있는데요. 작업하는 AI와 완료 여부를 판단하는 AI가 서로 다릅니다. 클로드 코드의 경우, 작업은 메인 모델이 하고, 완료 판단은 Haiku라는 작고 빠른 별도 모델이 맡습니다. 자기 작업을 자기가 평가하는 게 아니라, 제3자가 검증하는 구조인 거죠. 그래서 AI가 스스로 "다 했다"고 착각하고 멈추는 일이 줄어듭니다.

문제는 대부분 /goal을 대충 쓴다는 점입니다

klöss가 지적한 핵심입니다. 대부분의 사용자가 /goal에 목표는 적지만, 완료 조건이 막연합니다. 예를 들어 "인증 모듈을 리팩토링해줘. 에러 없이 깔끔하게"처럼요. 목표는 있는데, AI가 언제 끝내야 하는지, 뭘 건드리면 안 되는지, 어떻게 검증해야 하는지가 빠져 있는 거죠. 그래서 klöss는 /goal에 넣을 프롬프트를 9가지 섹션으로 구조화하는 방법을 제안했습니다.

GOAL → 하나의 명확하고 측정 가능한 목표. 미션은 반드시 하나만
CONTEXT → 현재 상태. 어떤 파일을 다루는지, 어떤 구조인지, 이전에 내린 결정은 무엇인지
CONSTRAINTS → 건드리면 안 되는 것. 지켜야 할 패턴, 절대 하면 안 되는 행동
PRIORITY → 우선순위가 여러 개라면 1, 2, 3순위로 명시
PLAN → 먼저 이해하고, 그다음에 실행하라는 지시. 큰 변경을 하기 전에 이해한 내용을 먼저 정리하게 함
DONE WHEN → 검증 가능한 완료 상태. "테스트가 전부 통과"처럼 확인할 수 있는 조건
VERIFY → 검증 방법. 테스트, 빌드, 수동 확인 등. 검증할 수 없는 항목이 있다면 그 이유도 명시
OUTPUT → 결과물 형식. 변경된 파일, 주요 결정 사항, 후속 작업 목록
STOP RULES → 멈춰야 할 조건. 확신이 없으면 멈추고, 목표 달성 후 범위를 확장하지 말 것

물론, 이 구조가 개발자만을 위한 건 아닙니다. AI에게 복잡한 작업을 맡길 때 목표, 맥락, 제약, 완료 조건, 멈춤 조건을 명확히 설정하라는 원칙은 기획 문서 초안을 AI로 뽑는 상황에서도 그대로 적용할 수 있어요.

어떻게 쓰나요?

클로드 코드 기준으로, 터미널에 /goal 뒤에 조건을 적으면 바로 시작됩니다. 별도 프롬프트를 추가로 보낼 필요가 없어요. AI가 작업 중일 때는 화면에 경과 시간이 표시되고, 매 단계가 끝날 때마다 완료 여부와 이유가 한 줄로 나옵니다. 중간에 멈추고 싶으면 /goal clear를 입력하면 됩니다.

한 가지 유의할 점은 /goal은 완료 조건이 충족될 때까지 AI가 자동으로 계속 작업하기 때문에, 조건을 너무 넓게 잡거나 달성이 어려운 목표를 설정하면, 의도치 않게 토큰 사용이 커질 수 있습니다. 처음 쓸 때는 작은 작업으로 먼저 감을 잡고, 토큰 사용량을 한 번 확인한 뒤 범위를 넓혀가는 게 안전합니다.

공식 문서에서 권장하는 좋은 조건의 기준은 세 가지입니다. 하나의 측정 가능한 완료 상태가 있을 것 (예: 테스트 전부 통과). AI가 스스로 증명할 수 있는 확인 방법이 포함될 것 (예: npm test 결과가 0). 그 과정에서 건드리면 안 되는 것이 명시될 것 (예: 다른 테스트 파일은 수정하지 않기).

klöss는 이 명령어가 특히 효과적인 작업 23가지도 별도로 공유했는데요. 복잡한 코드 리팩토링, 테스트 강화, 보안 감사, 접근성 검수, 문서 자동 생성, 다국어 지원 작업 등이 포함되어 있습니다. 공통점은 전부 완료 상태를 명확히 정의할 수 있고, 여러 단계에 걸쳐 반복 작업이 필요한 유형이라는 것입니다.

누구에게 좋을까요?

AI 코딩 도구(클로드 코드, 코덱스 등)로 큰 작업을 맡기는데, 중간에 자꾸 멈춰서 "계속해"를 반복 입력하는 사람
AI에게 작업을 시킬 때 결과가 들쭉날쭉해서, 목표 설정 방법 자체를 개선하고 싶은 사람
코딩 외에도 AI에게 복잡한 작업을 구조적으로 지시하는 프레임워크가 필요한 기획자, PM

klöss의 원문 트윗: https://x.com/kloss_xyz/status/2054096165055217987

2. 참고할 것: 구글이 안드로이드를 AI 에이전트 기기로 바꾸기 시작했다

스마트폰을 쓰는 방식을 떠올려보면, 10년 전이나 지금이나 크게 다르지 않습니다. 앱을 열고, 화면을 터치하고, 정보를 직접 입력하고, 다른 앱이 필요하면 또 그 앱을 열어야 하죠. 앱 하나하나는 훨씬 좋아졌지만, 앱 사이를 오가는 건 여전히 사용자의 몫이에요. 배달 앱에서 주문하려면 배달 앱을 열어야 하고, 수업에 필요한 책을 사려면 이메일에서 강의 계획서를 찾고, 책 제목을 복사해서, 쇼핑 앱에 가서 검색해야 합니다.

최근 구글이 이 구조를 바꾸겠다고 나섰습니다. 5월 12일 Android Show 2026에서 공개된 Gemini Intelligence(제미나이 인텔리전스)가 그 시작인데요. 사용자가 앱을 하나씩 열어서 조작하는 대신, AI에게 의도만 말하면 AI가 여러 앱을 직접 돌아다니면서 작업을 처리하는 방식입니다.

구글 안드로이드 총괄 Sameer Samat은 CNBC 인터뷰에서 "운영체제에서 지능형 시스템으로 전환하고 있다"고 직접 밝혔습니다. 이는 단순히 AI 기능을 하나 추가한 게 아니라, 안드로이드라는 운영체제의 역할 자체를 재정의하겠다는 선언에 가깝습니다. 구글 I/O 2026(5월 19~20일) 바로 일주일 전에 발표한 것도, 이 방향을 본격적으로 밀겠다는 신호로 읽힙니다.

기존 스마트폰 사용 방식과 무엇이 다른가요?

제미나이 인텔리전스가 바꾸려는 건 바로 이 앱 사이의 이동입니다. 예를 들어 메모 앱에 적어둔 장보기 목록 위에서 전원 버튼을 길게 누르고 "이 목록으로 장바구니 만들어줘"라고 하면, 제미나이가 배달 앱에 들어가서 항목을 하나씩 담아줍니다. 호텔에서 여행 브로슈어 사진을 찍고 "6명이서 갈 수 있는 투어 찾아줘"라고 하면, 제미나이가 야놀자나 네이버 여행 같은 앱에서 알아서 검색하고요. 작업 진행 상황은 알림으로 확인할 수 있고, 최종 확인(결제 등)은 반드시 사용자가 직접 합니다.

어떤 기능들이 포함되어 있나요?

제미나이 인텔리전스라는 이름 아래 발표된 주요 기능은 다섯 가지입니다.

멀티스텝 앱 자동화: 위에서 설명한 것처럼, AI가 여러 앱을 오가며 작업을 수행합니다. 현재는 음식 배달, 차량 호출, 여행 관련 앱에서 먼저 지원되고, 점차 확대될 예정이라 합니다. Galaxy S26과 Pixel 10에서 올여름부터 시작됩니다.
Gemini in Chrome(제미나이 인 크롬): 안드로이드 크롬 브라우저에 제미나이가 들어갑니다. 웹페이지 내용을 요약하거나, 여러 페이지의 정보를 비교하거나, 주차장 예약 같은 작업을 대신 처리하는 Auto Browse 기능이 포함되어 있어요. 6월 말 출시 예정이고, Gemini 3.1 기반입니다.
지능형 자동완성: 기존의 자동완성은 이름, 주소 정도만 채워줬다면, 이제는 제미나이가 연결된 앱의 정보를 활용해서 복잡한 양식도 대신 채워줍니다. 예를 들어 보험 서류에 필요한 정보를 Gmail과 연락처에서 가져와서 자동으로 입력하는 식이에요. 이 기능은 명시적으로 동의해야만 켜지고, 설정에서 언제든 끌 수 있습니다.
Rambler(램블러): 음성 입력의 업그레이드입니다. 기존에도 음성으로 텍스트를 입력할 수 있었지만, 문제는 말하는 방식과 글 쓰는 방식이 다르다는 거예였죠. "음...", "아...", 같은 말 반복, 문장 중간에 고치는 것들이 그대로 텍스트로 입력 되니까요. 램블러는 이런 군더더기를 걸러내고 핵심만 정돈된 문장으로 만들어줍니다. 영어와 힌디어처럼 서로 다른 언어를 섞어서 말해도 맥락을 이해한다고 합니다.
Create My Widget: 자연어로 맞춤 위젯을 만드는 기능입니다. "매주 고단백 식단 3개를 추천해줘"라고 말하면 그에 맞는 위젯이 홈화면에 생기는 식입니다. 기존 위젯은 앱 개발자가 미리 만들어둔 것만 쓸 수 있었는데, 이제 사용자가 원하는 정보를 직접 정의할 수 있게 되는 거죠. Wear OS 시계에서도 작동합니다.

프로덕트 메이커 관점에서 무엇을 눈여겨봐야 하나요?

지금까지 앱은 사용자가 직접 열고, 화면을 탐색하고, 버튼을 눌러서 작업을 완료하는 구조였습니다. UI와 UX가 중요한 이유도 사용자가 직접 조작하기 때문이죠. 그런데 AI가 앱을 대신 조작하는 세상이 오면, 사용자가 앱 안에서 보내는 시간은 줄어들고, AI가 앱의 기능을 얼마나 잘 호출할 수 있는지가 더 중요해질 수 있습니다.

구글 안드로이드 개발자 블로그에 따르면, 앱 개발자가 별도 코드를 작성하지 않아도 제미나이가 앱을 자동으로 탐색하고 조작할 수 있다고 합니다. 하지만 반대로 말하면, 개발자가 적극적으로 AI 연동을 최적화하면 경쟁 앱보다 더 잘 선택받을 수도 있다는 뜻이기도 하죠.

물론 아직 실제로 얼마나 잘 작동하는지는 확인해봐야 합니다. Engadget은 마이크로소프트가 Windows에 AI 기능을 과도하게 집어넣다가 사용자 반발을 산 사례를 언급하면서, 제미나이 인텔리전스도 비슷한 반응을 받을 수 있다고 지적했어요. Digital Trends도 구글이 발표만 하고 실제 출시가 늦어지거나 출시되지 않은 전례가 있다며 신중한 입장을 보였고요.

그럼에도 방향 자체는 명확합니다. 스마트폰의 경쟁이 하드웨어 스펙에서 AI가 사용자의 의도를 얼마나 잘 이해하고 실행하느냐로 옮겨가고 있다는 거예요. 애플도 WWDC에서 Gemini 기반의 Apple Intelligence(애플 인텔리전스) 리부트를 공개할 것으로 예상되는 만큼, 이 흐름은 올해 하반기에 더 뚜렷해질 것으로 보입니다.

3. 적용해볼 것: AI가 만든 결과물, 마크다운 대신 HTML로 받아보기

Anthropic(앤트로픽)에서 클로드 코드를 개발하고 있는 엔지니어링 리드 Thariq Shihipar가 X에 글을 하나 올렸습니다. 제목은 The Unreasonable Effectiveness of HTML. AI 연구자Simon Willison이 공유하면서 화제가 됐고, 해커뉴스에서도 토론이 이어졌어요. Thariq의 핵심 주장은, AI에게 결과물을 받을 때 마크다운 대신 HTML로 받으면 훨씬 낫다는 것입니다.

잠깐, 마크다운과 HTML이 뭔가요?

둘 다 텍스트에 서식을 입히는 방법입니다. 차이는 표현할 수 있는 범위입니다.

마크다운(Markdown) 은 간단한 기호로 서식을 지정하는 방식입니다. # 을 붙이면 제목, ** 로 감싸면 볼드, - 를 쓰면 목록. 가볍고 빠르지만, 표현할 수 있는 게 텍스트 위주로 한정됩니다. AI 도구의 기본 출력 포맷이기도 하고요.
HTML 은 웹페이지를 만드는 언어입니다. 표, 색상, 다이어그램, 탭, 버튼, 심지어 슬라이더 같은 인터랙션까지 한 파일에 담을 수 있어요. 브라우저에서 바로 열리기 때문에 공유도 쉽고요.

왜 마크다운 대신 HTML인가요?

Thariq가 이 글을 쓴 이유는 AI의 결과물이 점점 복잡해지고 있기 때문입니다.

AI가 간단한 질문에 답하거나 짧은 코드를 짤 때는 마크다운으로 충분합니다. 그런데 AI에게 맡기는 작업이 커지면서 상황이 조금 달라졌죠. 기획 문서, 코드 리뷰 보고서, 아키텍처 분석 같은 결과물이 100줄을 넘어가기 시작하면, 마크다운 파일은 그냥 긴 텍스트 덩어리처럼 보여 읽기가 힘들어집니다. Thariq 본인도 100줄이 넘는 마크다운 파일은 실제로 제대로 읽지 않게 됐다고 하죠.

이를 HTML로 받으면 달라지는 것들이 있습니다. 정보를 탭으로 나눠서 필요한 부분만 볼 수 있고, 표와 다이어그램으로 구조를 시각화할 수 있고, 코드 조각에 색상 강조를 넣을 수 있습니다. 심지어 슬라이더를 달아서 디자인 변수를 실시간으로 조절해본 뒤, 마음에 드는 값을 복사해서 다시 AI에게 전달할 수도 있고요.

Thariq가 제시한 구체적인 활용 사례도 여러 가지인데요. 6가지 서로 다른 온보딩 화면 방향을 한 파일에 격자 형태로 비교하기, PR(코드 변경 요청)을 색상 구분된 리뷰 문서로 만들기, 30개의 작업 티켓을 드래그 앤 드롭으로 재정렬하는 임시 보드 만들기 같은 것들이 있습니다. 전부 일회용이지만, 그 한 번의 작업을 훨씬 효율적으로 만들어주는 방식이죠.

그렇다고 마크다운이 쓸모없어진 건 아닙니다

이 글에 대한 반응은 전면 동의와 부분 동의로 나뉘었어요.

부분 동의 쪽에서 나온 가장 설득력 있는 관점은 사람이 읽을 결과물은 HTML이 낫고, AI(기계)가 읽을 파일은 마크다운이 낫다는 것입니다. AI에게 넘겨줄 설정 파일이나 지시 문서(CLAUDE.md 같은)는 마크다운이 효율적이에요. 토큰 소비가 적고, AI가 파싱하기도 쉬우니까요. 반면, 사람이 검토해야 하는 기획 문서, 보고서, 코드 리뷰는 HTML이 더 잘 읽힙니다.

Thariq 본인은 어떤 상황에서든 HTML이 더 낫다는 강경한 입장이지만, 본인도 인정한 단점이 있어요. HTML은 마크다운보다 생성 시간이 2~4배 더 걸리고, git에서 변경 내역을 비교할 때 훨씬 지저분하다는 점입니다. 빠르게 쓰고 버릴 메모나, AI가 대량으로 처리할 파이프라인 같은 상황에서는 여전히 마크다운이 맞습니다.

개인적으로는 상황에 따라 골라 쓰는 게 현실적이라고 봅니다. 핵심 기준은 결과물을 누가 읽느냐입니다. 내가 직접 읽거나 팀원에게 공유할 문서라면 HTML, AI가 다음 작업에 쓸 입력 파일이라면 마크다운 정도로 구분해도 충분할 것 같습니다.

직접 시도해보려면

AI에게 결과물을 요청할 때 "HTML 파일로 만들어줘"라고 형식을 지정해 명령하면 됩니다. 클로드 코드를 쓴다면 터미널에서 바로 HTML 파일이 생성되고, claude.ai의 아티팩트 기능에서도 HTML 결과물을 바로 확인할 수 있습니다.

HTML이 마크다운보다 더 나은 선택지가 될 수 있는 상황:

AI가 만든 결과물이 100줄을 넘어가서, 텍스트만으로는 구조가 한눈에 안 잡힐 때
기획 문서, 코드 리뷰, 비교 분석처럼 결과물을 다른 사람에게 공유해야 할 때
표, 다이어그램, 탭 같은 시각적 구조가 있어야 내용이 제대로 전달되는 작업일 때

다음 주에도 여러분이 놓치지 말아야 할 프로덕트 메이커 소식을 정리해서 찾아뵙겠습니다. 요즘 프로덕트 메이커 콘텐츠가 도움이 되셨다면, 꼭 작가 알림 설정을 부탁드립니다. 콘텐츠 내용 중 잘못된 정보나 정정이 필요한 부분이 있다면 댓글로 알려주세요. 빠르게 수정하겠습니다. 다음 주에 또 만나요!