안녕하세요, 구독자님. 여의도에 서식 중인 몽글c입니다.
여러분들은 최근 프로덕트 기획과 디자인, 혹은 개발하는 방식에 어떤 변화들이 있으신가요?
저는 보안이 제일 중요한 금융권에 근무 중이기도 하여 AI를 자유롭게 활용하기가 쉽지만은 않습니다. 🥲
하지만 허락된 환경 안에서 적극적으로 활용해보려 노력하고 있는데요. 오늘 이야기해보고 싶은 주제는 그 과정에서 비롯되었습니다.
기획안을 만들고, 구조를 설계하고, 화면을 디자인하는 일련의 과정에서 AI를 어떻게 활용할 수 있는지, 그리고 실제로 활용해보며 어떤 가능성과 한계를 느꼈는지에 대해서 차근차근 이야기해보려고 합니다.
1. "와이어프레임 그려줘"가 실패하는 이유
AI에게 바로 화면을 요청하면 어떤 일이 일어나는지 살펴보겠습니다.
🙋🏻♂️ 휴먼: "카드 추천 서비스의 홈 화면 와이어프레임 만들어줘."
🤖 AI: (3초 뒤) 아래와 같은 구성으로 와이어프레임을 구성하겠습니다.
🙋🏻♂️ 휴먼: 응, 좋네. 와이어프레임 그려줘.
🤖 AI: 네, 그럼 와이어프레임을 구성하도록 하겠습니다. (이미지 구성하는 중..)
그리고는 아래와 같은 이미지를 '짠'하고 그려줍니다.
깔끔하고 그럴듯합니다. 하지만 이 화면에는 다음이 빠져 있습니다.
- 누구를 위한 건지: 첫 카드 발급자? 카드 갈아타기 유저? 혜택 극대화 유저?
- 왜 만드는지: 기존 카드 비교 사이트의 어떤 불편함을 해결하려는 건지?
- 비즈니스 목표: 카드사 제휴 수수료? 광고 수익? 다양한 콘텐츠에 대한 프리미엄 구독?
- 핵심 시나리오: 사용자가 이 서비스에서 하는 가장 중요한 행동 3~5가지는?
이 질문들에 대한 답 없이 만들어진 화면은, 어떤 카드 추천 서비스에나 붙일 수 있는 범용적인 화면입니다. 내가 고민하고 있는 서비스만의 이유가 담겨 있지 않아요.
메이커스 노트 17호에서 소개한 와이어프레임 생성기도 이 문제에서 자유롭지 않았습니다. 프롬프트를 아무리 구체적으로 써도, 문제 정의 없이 만든 화면은 결국 다시 처음부터 논의해야 했습니다. (물론 이미지 중심의 아이디어 발산 측면에서는 의미가 있다고 생각은 합니다만)
결국 결론은 다시 돌고돌아 아래와 같은 내용으로 귀결되었습니다.
좋은 와이어프레임은 좋은 화면 구성에서 나오는 게 아니라, 좋은 문제 정의에서 나온다. 👀
2. 하네스 엔지니어링 활용하기
워낙에 빠른 AI트렌드 안에서 '하네스 엔지니어링(Harness Engineering)'이라는 용어 자체도 유행이 지난 것만 같습니다. 하지만 여전히 그럴듯한 할루시네이션을 만들어내고 정확히 가이드하지 않으면 어디로 튈지 모르는 똑똑한 AI에게 보다 명확하게 지시하고 효율적인 답변을 얻고자 할 때는 여전히 유효한 방법론 입니다.
다시 이야기하면, AI에게 "화면을 그려라"가 아니라 "일하는 순서와 판단 기준"을 설계하는 것이지요.
(이미 알고 계시겠지만) 하네스(Harness)는 원래 마구(馬具) — 말이 일정한 방향으로 힘을 쓸 수 있도록 잡아주는 장비잖아요. AI도 마찬가지로, 방향 없이 달리면 에너지만 낭비하고, 하네스를 채우면 원하는 방향으로 힘을 집중할 수 있는 것이지요.
22호에서는 Skill의 개념을 소개한 적이 있습니다. "AI가 특정 작업을 어떻게 수행해야 하는지 이해할 수 있도록 만든 지시사항과 참고 자료의 집합"이라고요. 하네스 엔지니어링은 이 Skill의 개념을 확장한 것입니다. 단일 스킬이 아니라, 여러 에이전트가 역할을 나눠 파이프라인으로 작동하는 구조를 설계하는 것이죠.
우리가 평소 프로덕트를 만드는 과정은 사실 하나의 화면을 그리는 일이 아니라,
문제를 이해하고 → 구조를 설계하고 → 화면으로 만들고 → 연결하고 → 다시 검증하는 과정의 연속입니다. 아래 그림은 이 과정을 하네스 엔지니어링 관점에서 하나의 시스템으로 구조화한 내용입니다.
각 개념의 역할을 정리하면 아래와 같습니다.
| 개념 | 역할 | 비유 |
|---|---|---|
| Skill | 명령어로 Agent를 깨운다 | 시동 버튼 (여기선 /wire) |
| Agent | 누가 일하는가, 무엇을 아는가 | 담당자 |
| Playbook | 어떻게 일하는가 (재사용 가능) | 매뉴얼 |
| Context | 무엇을 알아야 하는가 | 배경 지식 |
| Rules | 무엇을 지켜야 하는가 | 원칙 |
| Evaluation | 제대로 만들었는가 | 체크리스트 |
핵심은 Agent → Playbook → Context의 분리입니다. Agent는 역할만 알고, 구체적인 절차는 Playbook에, 배경 지식은 Context에 분리되어 있어요. 새로운 기능을 추가할 때 Playbook 하나만 끼워넣으면 됩니다.
하지만 한 가지 짚고가면 좋을만한 점이 있습니다. Agent 파일(planner.md, wireframe.md 등)을 만들어두면 AI가 알아서 읽고 실행하는 게 아니거든요. Agent 파일은 기획자의 역할과 와이어프레임을 만드는데 필요한 행동 지침이 적힌 '지시서'라고 할 수 있고, 이것을 언제, 어떤 순서로 읽을지를 정하는 건 별도의 Skill 파일(wire.md)입니다.
이 하네스의 전체 구조와 파일은 GitHub에 공개해두었습니다. 클론해서 바로 사용하실 수 있어요.🎁 https://github.com/pentaxzs/productdesign_harness
/wire 스킬 — 파이프라인 오케스트레이션! 🧙🏻
지금까지 소개한 하네스의 진입점인 /wire 는 Claude Code의 커스텀 슬래시 명령어입니다. 해당 스킬을 설치(Read.me파일의 빠른 설치 참고)한 이후, /wire 를 통해 클로드나 코덱스에서 스킬을 실행해볼 수 있습니다.
그리고 이 스킬을 실행시키게 되면 .claude/commands/wire.md 파일에서 부터 시작하게 됩니다.
(이 하네스를 설치하셨다면, 숨김처리되어 보이지 않을텐데요. 폴더의 숨김을 해제하시면 보실 수 있습니다. 아니면 공개해둔 깃허브를 직접 확인하셔도 됩니다)
.claude/commands/wire.md
전체 파이프라인을 실행하는 순서가 담긴 '지시서'입니다.
Plan > Wireframe > Prototype > Critique > Refine > Human Review
이 파일이 하는 일은 중요하지만 단순합니다. 어떤 Agent가, 어떤 순서로, 어떤 Playbook을 실행하는지 적어둔 것 파일이에요. 지휘자가 악보를 보고 각 파트에게 순서대로 신호를 보내듯, /wire 가 트리거가 되어 Agent들을 순서대로 깨워 일을 시킵니다.
정리하면 이런 관계입니다:
Skill이 오케스트레이션을, Agent가 역할 판단을, Playbook이 구체적 절차를 담당합니다. 이 파일 하나를 수정하면 파이프라인의 순서나 구성을 바꿀 수 있어요.
나머지 개별 스킬(/plan-wire, /wireframe, /proto, /critique)도 각각 하나의 Phase만 실행하는 명령어입니다. 전체 파이프라인이 아니라 특정 단계만 다시 돌리고 싶을 때 사용합니다.
3. 파이프라인: Discovery에서 Critique까지
/wire 를 실행하면 6단계 파이프라인이 순서대로 돌아갑니다.
각 Phase를 조금 더 자세히 살펴보겠습니다.
Phase 1: Plan — "질문 먼저, 기획 나중"
Planner Agent는 PM의 역할을 합니다. 가장 중요한 원칙은 '질문 먼저, 기획은 나중'입니다.
"카드 추천 서비스 만들어줘"라고 요청하면, 바로 화면을 그리지 않고 이렇게 질문합니다:
선택지를 제시해서 답하기 쉽게 만드는 것이 포인트입니다. 이 Discovery 과정을 거치면 product-context.md 가 채워지고, 그 다음에 Figma에 1-Pager를 생성합니다.
1-Pager가 와이어프레임 바로 옆에 있으면, 화면을 보면서 "이 화면이 왜 이런 구조인지"를 바로 확인할 수 있습니다. 맥락과 결과물이 한 공간에 있는 겁니다.
실제로 카드 추천 서비스(가칭: CardFit)를 대상으로 이 파이프라인을 돌린 결과입니다. 좌측에 1-Pager가 배치되어 있고, 우측으로 홈, 검색, AI 분석 결과, 카드 비교, 카드 상세 화면이 Mobile(375px)과 Desktop(1440px) 쌍으로 생성되어 있습니다.
Phase 2: Wireframe — Figma에 직접 그리기
Wireframe Agent는 UX Designer 역할을 합니다. Screen Spec을 받아 Figma MCP를 통해 직접 피그마에 와이어프레임을 그립니다.
- Design System 컴포넌트를 우선 사용 (여기서는 figma simple design system 반영) ㄴ 각자 원하는 디자인 시스템을 반영하시면 됩니다.
- Mobile(375px) + Desktop(1440px) 쌍으로 생성
- 정보 계층, 버튼(CTA) 배치, 컴포넌트 구성을 결정
처음에는 HTML로 와이어프레임을 만들었는데, 디자이너가 바로 수정하고 발전시킬 수 있는 환경이 아니었기 때문에, Figma로 전환하며 이 문제를 해결해보고자 시도해보았습니다.
Phase 3: Prototype — 경험을 연결하기
Prototype Agent는 Interaction Designer 역할입니다. Figma 와이어프레임을 참조해서 HTML/CSS/JS로 Interactive Prototype을 만듭니다.
- 실제 API 없이 Mock 데이터로 동작
- 화면 간 네비게이션, 상태 변화, 인터랙션 구현
- 목표: "이 경험으로 개발 논의를 시작할 수 있는가?"
실제로 만들어진 프로토타입은 아래 링크에서 직접 확인해볼 수 있습니다.
(현재 프로토타입은 Figma의 Simple Design System을 참조한 Wireframe 구조이지만, 사내에서 사용 중인 디자인 시스템이 있다면 해당 시스템으로 변경해서 적용하시고 수정하시면 됩니다)
👉 https://proto-cardfit.vercel.app/
Phase 4~6: Critique → Refine → Human Review
Critic Agent는 Design Reviewer 역할입니다. 새로운 디자인을 제안하지 않고, 기존 기준(요구사항, UX 원칙, Design System)에 비추어 문제만 찾습니다.
판정 기준:
- Pass: Critical Issue 0건, Major Issue 2건 이하 → 사람이 최종 확인
- Revise: Critical Issue 1건 이상 또는 Major Issue 3건 이상 → 수정 후 재검증 (최대 3회)
4. 만들면서 배운 것 — 3번의 개선
이 하네스는 처음부터 완성된 형태가 아니었습니다. 실제로 사용하면서 3번의 큰 개선을 거쳤어요.
1차 개선: Discovery 추가
문제: /wire 를 실행하면 Planner가 정보 부족해도 가정으로 바로 User Flow를 만들어버렸습니다.
(AI는 정보가 부족하면 그럴듯한 가정을 만들어 채워넣습니다. 사람처럼 "잠깐, 이거 먼저 확인해야 하지 않아?"라고 멈추지 않더라고요)
해결: discover-context.md 플레이북을 추가하고, Planner Agent에 "질문 먼저, 기획 나중" 원칙을 명시했습니다.
2차 개선: Figma 1-Pager
문제: Discovery로 맥락을 확보했지만, 와이어프레임과 분리되어 있어서 "이 화면이 왜 이런 구조인지" 제대로 참조가 안되었습니다. (맥락과 결과물이 같은 공간에 있어야 좀 더 명확한 것 같아요)
해결: create-figma-onepager.md 플레이북을 추가해서, Figma 파일 안에 1-Pager 프레임을 만들고 와이어프레임 좌측에 배치했습니다.
3차 개선: Wireframe을 Figma로
문제: HTML로 만든 와이어프레임은 디자이너가 바로 수정하고 발전시키기 어려운 지점이 있습니다. 와이어프레임의 목적은 "개발 논의를 시작하는 것"인데, 디자이너가 직접 수정할 수 없으면 결국 계속 HTML을 수정해야 하거든요. (아직 의도를 디테일하게 수정하는 것은 사람의 손이 더 명확하다고 생각해요)
해결: build-wireframe-figma.md, implement-responsive-figma.md 플레이북을 추가하고, Wireframe Agent를 Figma MCP 기반으로 전환해두었습니다. (물론 Figma 사용이 어려운 경우엔, HTML로도 확인 가능하도록은 해두었어요)
핵심은 이 구조입니다. 하네스의 구조가 Agent → Playbook → Context로 분리되어 있기 때문에, 새로운 기능을 추가할 때 Playbook 하나만 끼워넣으면 됩니다. 전체를 다시 만들 필요가 없어요. 마치 레고 블록을 끼우듯이요.
5. 디자이너가 하네스를 만들 수 있을까
여기까지 읽고 "이거 결국 개발자가 해야 하는 거 아냐?"라고 생각할 수 있습니다. 하지만 실제로 이 하네스의 모든 파일은 마크다운(.md) 입니다. 코드가 아니에요.
하네스를 이루는 파일들을 보면:
Agent 파일의 핵심은 이런 내용입니다:
코드를 짜는 게 아닙니다. 'AI가 어떤 역할을 맡고, 어떤 순서로 일하고, 어떤 기준으로 판단해야 하는지'를 글로 쓰는 것입니다.
22호에서 'Skill을 만드는 일은 개발자만의 영역이 아닙니다'라고 이야기한 적이 있습니다. 하네스 엔지니어링도 마찬가지입니다. 기획자가 기획 프로세스를 문서화하듯, 디자이너가 디자인 프로세스를 문서화하는 것과 같아요. 다만 그 문서의 독자가 사람이 아니라 AI라는 점이 다를 뿐입니다.
처음부터 전체를 만들 필요는 없습니다
하네스 전체를 한 번에 만들어야 한다고 생각하면 부담스럽습니다. 하나의 Playbook(에이전트라기 보단 지침서에 해당)부터 시작하면 됩니다.
- 1단계: 자주 하는 작업 하나를 Playbook으로 만든다 (예: 디자인 크리틱 체크리스트)
- 2단계: 그 Playbook을 실행하는 Agent를 정의한다 (예: "나는 시니어 디자이너처럼 검증하는 역할이다")
- 3단계: Agent를 깨우는 Skill을 등록한다 (예:
/critique)
이 세 개면 최소한의 하네스가 됩니다. 나머지는 필요할 때 하나씩 추가하면 됩니다.
🙋🏻♂️ 휴먼: OO기능에 대한 Skill을 만들고 싶어.
로 시작해도 충분합니다.
6. 한 걸음 더, 와이어프레임에서 디자인까지
여기까지의 파이프라인은 와이어프레임 → 프로토타입이었습니다. 화면의 구조와 흐름을 잡는 것이 목표였죠. 하지만 한 가지 실험을 더 해봤습니다.
얼마 전 피그마에서 새로 소개한 Specs 기능을 활용해서, 1-Pager의 내용을 별도의 Specs 문서로 작성해보았습니다. 제품 배경, 타겟 유저, 핵심 시나리오, 톤 & 무드까지, Discovery에서 확보한 맥락을 구조화된 문서로 정리했어요. 그리고 Figma Agent에게 이 Specs 문서를 참조해서 와이어프레임이 아니라 디자인을 해달라고 요청했습니다.
결과는 나쁘지 않았어요. 와이어프레임 수준에서 크게 벗어나진 않았지만, 컬러, 타이포그래피, 컴포넌트 스타일링까지 반영된 디자인 초안이 나왔습니다. 물론 바로 쓸 수 있는 최종 디자인은 아닙니다. 하지만 디자인 논의를 시작하기에 충분한 수준이었어요.
Figma 파일
👉 https://www.figma.com/design/TEKQGoo6LR0KKXFl1XipOe/CardFit---Prototype?node-id=0-1
디자인 초안을 기반으로 만든 인터랙티브 프로토타입도 직접 체험해볼 수 있습니다.
👉 https://protodesign-cardfit.vercel.app/
이것이 가능했던 이유는 1-pager의 맥락이 충분했기 때문입니다. Discovery → 1-Pager → Specs로 이어지는 과정에서 제품의 방향, 사용자, 톤이 이미 정의되어 있었고, Agent는 그 위에서 디자인에 대한 판단을 통해 초안을 그려내는 구조입니다.
하네스 엔지니어링의 핵심이라고 생각해요. AI에게 "디자인해줘"라고 하면 범용 디자인이 나오지만, 맥락이 쌓인 상태에서 "이 Specs를 기반으로 디자인해줘"라고 하면 우리 제품다운 디자인이 나올 수 있습니다.
마무리. AI에게 그려달라고 하지 말고, 질문하게 하세요
이 하네스를 만들면서 가장 크게 배운 내용은 아래와 같습니다.
AI에게 결과물을 요청하면 그럴듯한 결과물이 나옵니다. 하지만 AI에게 질문하게 만들면, 좋은 결과물이 나옵니다.
"와이어프레임 그려줘"라고 하면 AI는 바로 화면을 그립니다. 정보가 부족해도 가정으로 채워서요. 하지만 "먼저 질문해"라고 하면 AI는 빠진 맥락을 찾아내고, 그 맥락 위에 화면을 그립니다.
결국 좋은 도구는 바로 결과를 주는 게 아니라, 좋은 질문을 먼저 던지게 만드는 도구입니다. 하네스 엔지니어링은 바로 그것을 설계하는 일이에요.
"Skill은 AI가 아니라 우리의 일하는 방식을 설계하는 도구"이고, "하네스는 그 일하는 방식을 파이프라인으로 연결한 것"입니다. 혼자 쓰는 프롬프트에서 시작해서, 여러 에이전트가 협업하는 시스템으로 발전시킨 거예요.
지금 AI에게 "와이어프레임 그려줘"라고 말하고 있다면, 한 번쯤 "먼저 질문해줘"로 바꿔보시는 건 어떨까요. 결과물의 수준이 달라지는 걸 느낄 수 있을 거예요. ✍️ 🤖 🎨
📮 다음 호 예고
[40호] Notion·Stripe·Intercom은 AI와 어떻게 개발할까?
AI가 코드를 작성하고, 테스트를 수행하며, PR까지 생성하는 시대가 됐습니다. Notion, Stripe, Intercom은 이미 AI와 개발자가 협업하는 방식을 바꾸고 있습니다. 그렇다면 개발자의 역할은 어떻게 달라지고 있을까요? 그리고 PM은 무엇을 준비해야 할까요?
다음 호에서는 Lenny's Newsletter에 소개된 세 기업의 사례를 통해 AI 코파일럿이 바꾸고 있는 개발 현장의 이야기를 살펴봅니다.
✉️ 다음 호가 궁금하신 분들은 아래 [구독하기] 버튼을 눌러주세요.
의견을 남겨주세요