[19호] "사샤는 왜 상위기획은 AI로 똑똑하게 잘 짜놓고, 상세기획은 손으로 노가다 하고 있어요?"

1. "하네스 하나 만들면 끝날 일인데 왜 그러고 있어요?"

요즘 주변을 보면 웬만한 기획자분들은 다 AI와 함께 기획서를 쓰는 것 같습니다. 단순히 질문과 답변을 반복하는 수준을 넘어, 마크다운(md) 파일로 캐노니컬 문서^[1]​를 만들어두고 "이거 참고해서 기획서 초안 써줘"까지는 다들 무리 없이 해내시더라고요.

그런데 그렇게 멋지게 상위기획까지 뽑아놓고 나서 실제 구현을 위한 상세기획서 단계로 넘어가면 결국 다시 손노가다로 돌아가는 기획자들을 정말 많이 봅니다. 상위기획의 큰 그림 이후 단계까지 AI를 제대로 레버리지하는 기획자는 생각보다 드문 것 같아요.

예를 들어, 상세 기획 단계에서 추가되는 스펙이 생겨 "이 문서 참고해서 기획서 수정해줘"라고 요청해 보신적 있죠? 이때 대부분의 AI는 갑자기 맥락을 잃고 탈주해서 엉뚱한 소설을 써내려 갔을 거예요. 기획자는 그 황당한 답변을 정제하고 걸러내는 데 오히려 더 많은 시간을 쓰며 피로감을 느낍니다. 게다가 상세기획 단계는 특유의 반복 노가다 작업들도 많은데 — 예를 들어 정렬 맞춰서 시퀀스 다이어그램 그리기, 한땀한땀 유저 플로우 그리기, 업데이트된 스펙 요약해서 개발팀에 공유하기 같은 — 대부분 기획자가 손으로 꾸역꾸역 하고 있습니다.

저 역시 다르지 않았습니다. 모니터 앞에서 엣지 케이스와 다이어그램 화살표 꼬인 것을 붙잡고 멘탈이 바스러지기 직전, 옆자리 개발자 동료가 제 화면을 보더니 툭 한마디를 던졌습니다.

하네스라니요? 강아지 산책할 때 채우는 가슴줄 말씀하시는 건가? 개발자들이 자기들끼리 모여서 "하네스 엔지니어링이 어쩌구..." 할 때마다 코딩 테스트나 자동 검증할 때 쓰는 그들만의 전유물인 줄 알고 귓등으로 흘려들었는데, 그게 왜 내 상세기획 프로세스에서 튀어나오는지 도무지 이해가 가지 않았습니다.

그런데 반신반의하며 한 번 구축해 보니까 알겠더라고요. 왜 기획자에게 하네스가 필요한지 말이죠. 그래서 이번 글에서는 그냥 적당히 AI한테 문서 참고하라고 던져주는 것과, 제대로 '하네스'를 구축하고 기획서를 쓰는 것이 도대체 뭐가 다르고 왜 좋은지, 그리고 비개발자 기획자도 10분 만에 컴퓨터에 심을 수 있는 실전 가이드를 이야기해 보려고 합니다.

2. '기획 하네스(Harness)'란?

1. 왜 기획자에게 하네스가 필요해요?

많은 기획자가 챗GPT 창에 기획서(md) 파일을 첨부하며 "이거 읽고 다음 상세기획 짜줘"라고 지시합니다. 하지만 이건 똑똑한 인턴에게 "우리 회사 매뉴얼 대충 읽어보고 눈치껏 일해봐"라고 부탁하는 느슨한 대화일 뿐입니다. 인턴은 금세 매뉴얼을 까먹거나 자기 생각을 섞어 사고를 치게 되죠.

하네스는 이 느슨한 대화를 '철저하게 통제된 자동화 공장'으로 바꾸는 시스템입니다. AI가 딴짓을 하지 못하도록 컴퓨터 폴더 안에 단단한 가드레일과 장비를 물리적으로 깔아주는 방식을 뜻해요.

기획 하네스는 크게 아래 4가지를 책임집니다.

💡 기획 하네스의 역할

그냥 파일 하나 던져주는 게 매번 초기화되는 AI의 변덕에 기댄 '일회성 부탁'이라면, 기획 하네스는 AI를 내 로컬 폴더에 가두고 언제 켜도 똑같은 고품질의 산출물을 뱉어내게 만드는 '프로덕트 논리의 절대적인 파이프라인'이라고 생각해요. 이 시스템이 갖춰져야 비로소 AI가 변덕스러운 말싸움 상대가 아닌, 완벽히 통제된 '기획 실행 엔진'으로 작동합니다.

2. "그냥 이 파일로 된 기획서 읽고 참고해줘"라고 하는 거랑 뭐가 달라요?

많은 분들이 여기까지 읽으시고 역으로 질문하실 것 같아요.

비교 불가능한 결정적 차이가 있습니다.

첫째로 기획 파이프라인이 상시 대기합니다. 일반적인 방식은 기획자가 매번 “이 파일 읽어, 저 규칙 참고해”라고 수동으로 자료를 쥐여주고 그때그때 애원해야 합니다. 반면 하네스를 구축하면 아예 내 시스템적으로 세팅이 되어 있어서 내가 구구절절 말하지 않아도 AI가 규칙을 상시 인지하고 대기합니다.

둘째로 실제로 실행해 줄 수 있어요. 챗GPT에게 시퀀스 다이어그램을 그려달라고 하면 대화창에 코드만 뱉고 끝나죠? 반면 하네스 환경에 갇힌 AI는 내 노트북 폴더에 직접 spec.md, flow.mermaid 같은 파일을 생성할 수 있는 File I/O 권한을 가지고 있기 때문에, 파일을 직접 수정할 수 있습니다. 기획자는 산출물이 실시간으로 로컬 파일에 업데이트되는 자동화를 경험하게 됩니다.

셋째로 팀의 자산으로 만들 수 있어요. 혼자 프롬프트를 잘 짜서 메모장에 들고 다니는 건 개인의 역량에 가깝습니다. 하지만 하네스를 구축해 두면 폴더 통째로 깃허브(GitHub) 같은 곳에 올려서 팀 전체가 공유할 수 있습니다. 새로운 기획자가 합류해도 길게 인수인계할 필요 없이, "이 폴더 다운받아서 Claude Code 켜고 명령어 치시면 우리회사 규격대로 나옵니다"가 가능해지니 개인의 자산이 팀의 자산이 됩니다.

그리고 무엇보다, 가장 중요하게, 일정 부분 기획 자동화가 가능합니다.

3. 핵심은 자동화까지 된다는 것

하네스를 사용하면 내 기획 워크플로우를 통째로 자동화하는 강력한 파이프라인이 생깁니다. 하네스 환경에서는 AI가 실제 내 노트북의 파일을 읽고 쓸 수 있는 권한을 가지기 때문이에요.

그래서 기획자가 상세기획 단계에서 매번 반복적으로 겪는 고질적인 노가다들—새 기능 스펙 쓸 때마다 같은 구조로 문서 만들기, 설계 바뀌면 일일이 찾아서 수동으로 업데이트하기, 지라(Jira) 티켓 쪼개서 등록하기 같은 일들—을 일부 자동화하는 것이 가능해집니다. 

그리고 이 자동화의 비결은 바로 하네스 안에 심어두는 '스킬(Skill)'에 있습니다. 하네스를 "업무를 실행하는 큰 틀"이라고 본다면, 스킬은 그 안에서 호출되는 "전문 기능"입니다.

기획 하네스에 심어둘 수 있는 대표적인 스킬 예시는 다음과 같습니다. 이 중 몇 가지는 아래에서 직접 시연을 해볼게요.

💡 기획 하네스에 심어두는 스킬 예시 (※ 스킬은 모두 예시이며 자유롭게 지정하실수 있어요.)

4. 10분 만에 기획 하네스 만드는 법

"하네스를 만들려면 거창한 코딩이 필요한 것 아닐까?"라는 걱정은 접어두셔도 좋습니다. 비개발자라도 폴더 하나 파고 규칙 파일 하나만 세팅하면 그 자체로 완벽한 하네스가 됩니다. 혼자 쓰는 로컬 하네스부터 팀원들과 공유하고 다운받아 쓰는 Github 배포 하네스까지 모두 가능하죠. 많은 PM이 애용하는 클로드 코드를 기준으로, 초보자의 눈높이에 맞춰 소개할게요.

📁 만드는 방법

🌐 사용하는 방법

이렇게 폴더 안에 파일 세팅을 끝내 두었다면, AI에게 일일이 "이 파일 참고해"라고 말할 필요가 없습니다. 우리가 클로드 코드를 켜는 순간 하네스가 자동으로 작동하기 때문입니다.

5. 실제로 기획 하네스를 이용해서 한 번 만들어봐요.

지난 호에서 클로드 코딩으로 메모 앱을 하나 뚝딱 만들었었는데요. 귀여운 메모 앱에 '댓글 기능'을 새로 추가한다고 가정해 보겠습니다. 기획 하네스를 구축해서 복잡하고 귀찮은 상세기획 단계를 단 한 줄의 명령어로 일부 자동화해 볼게요.

1. 폴더를 만들어요.

위의 방법대로 바탕화면에 local-harness라는 이름으로 빈 폴더를 하나 만듭니다. 

2. 규칙서를 작성하며 스킬을 정의해줄게요.

local-harness 폴더 안에 CLAUDE.md라는 이름으로 빈 텍스트 파일을 하나 생성합니다. (확장자를 .md로 만드는 게 포인트입니다.) 그리고 그 안에 내가 어떤 기획서 업무들을 자동으로 연쇄 실행하길 원하는지 규칙을 적어줄 거예요.

저는 새로 추가될 댓글 기능에 대해 [1단계: 백엔드 로직 시퀀스 다이어그램 그리기 → 2단계: 유저 플로우차트 그리기 → 3단계: 이 결과물들을 한눈에 볼 수 있는 깔끔한 HTML 웹페이지로 배포하기]까지의 워크플로우를 통째로 자동화해 보겠습니다.

이를 위해 하네스 규칙서 파일 안에 /sequence_diagram, /user-flow, /make-html이라는 3가지 커스텀 스킬을 자연어로 정의할게요.

3. 클로드가 참고할 상위 기획문서(spec.md)도 넣어줄게요.

local-harness 폴더 안에 클로드가 진실의 원천으로 삼고 기준을 잡을 상위 기획 문서도 넣어줍니다. 지난 호에서 작성했던 '메모 앱 기획서'(링크: Github)를 텍스트 파일로 다운받아서 넣어줄게요.

4. 이제 클로드에 폴더를 지정해 줄게요.

세팅은 완료됐고 이제 한번 실행해 볼게요. 클로드 코드를 열고 '폴더' 버튼을 선택해 클로드 코드의 실행 위치를 local-harness 폴더로 지정해줍니다.

그러면 아래와 같이 local-harness 폴더로 실행위치가 지정됩니다.

6. 이제 자동화를 한 번 요청해 봐요.

이제 요청해 볼게요. "메모 앱에 댓글 기능을 추가할 거야"라는 밑도 끝도 없는 기능 추가 요청을 해보겠습니다. 예전 같으면 "이거 해줘, 그다음 저거 해줘, 파일은 뭐 참고하고 포맷은 어떻게 해줘"라며 구구절절 수동으로 명령을 날려야 했겠죠?

하지만 하네스를 구축해 둔 지금은 그럴 필요가 전혀 없습니다. 단 한 번의 툭 던지는 요청만으로, 클로드는 CLAUDE.md에 설계해 둔 파이프라인 프로세스를 기계처럼 밟아나갑니다.

하네스를 정의하고 요청한 결과

세부 항목의 퀄리티가 떨어지지도 않아요. CLAUDE.md에서 정의된 대로 클라이언트-서버-DB 간에 데이터가 어떻게 흐르는지 텍스트 로직을 읽어, 선 꼬임이 없는 Mermaid 시퀀스 다이어그램을 바로 구워냈고요. 

유저의 진입부터 도달까지 촘촘한 유저 플로우차트(User Flow)를 화면에 자동으로 렌더링해 줬네요. 

최대한 간단한 예시로 보여드리기 위해 하네스의 기능 중 '컨텍스트 고정'과 '도구 정의'만 아주 살짝 세팅해 봤는데도 벌써 손노가다가 획기적으로 줄어들었습니다. 여기에 나머지 하네스의 역할인 '가드레일'과 '자동 검증' 규칙까지 촘촘하게 채워 넣는다면 더 압도적인 산출물이 나왔을 거예요.

7. 만약에 하네스를 쓰지 않았다면?

만약에 하네스 없이 spec.md 문서만 주고 참고해서 기획해 달라고 했으면 어땠을까요? 기획서 내용이 나오면 그걸 보고 다시 "이 내용으로 시퀀스 다이어그램 그려줘"라고 프롬프트를 쳐야 했겠죠. 클로드가 텍스트 코드를 뱉으면, 그걸 복사해서 다른 Mermaid 뷰어 툴을 찾아 붙여넣어야 했을겁니다. "자 이제 유저 플로우 그려줘"라며 다음 단계 명령을 또 새로 생각해서 지시해야 합니다.

하네스를 삭제하고 동일한 요청을 한 결과

지나치게 많은 에너지가 소모되는 지루한 '프롬프트 핑퐁 게임'이자 또 다른 손노가다의 연장이었을 것입니다. 하네스는 기획자가 명령어를 고심하고 툴을 옮겨 다녀야 하는 인지적 비용을 '제로'로 만들고, 내 기획 프로세스 자체를 하나의 견고한 자동화 공정으로 만들어주는 완벽한 해결책입니다.

6. 와이어프레임 노가다를 넘어, AI가 가져올 미래의 기획서를 꿈꿉니다.

물론 지금 시점의 하네스가 모든 것을 완벽하게 해낼 수는 없습니다. 여전히 세부적인 와이어프레임을 예쁘게 그리는 등 UX적인 영역은 아무래도 구조가 마크다운(Markdown) 형태인 클로드 코드만으로는 직관적으로 처리하기 어렵습니다. 시각적인 이미지 작업이 필수적이니까요.

하지만 클로드 디자인(Claude Design)이나 Figma MCP를 비롯해서, 요즘 엄청난 속도로 발전 중인 다양한 AX툴들이 하네스 파이프라인에 달라붙고 있습니다. 머지않은 미래에는 이 비주얼 작업들조차 하네스 안에서 완벽하게 자동화가 되지 않을까 생각합니다.

동시에, 저는 이번 변화를 계기로 기존의 '디자인 기반' 기획서 형태도 완전히 바뀌어야 한다고 생각합니다. 특히 한국 IT 업계에서는 예전부터 디자인 문서와 기획 문서가 완벽히 분리되어 있었고, 그로 인해 UX 정의가 양쪽 문서 모두에 파편화되어 적히는 비효율이 존재해 왔습니다. 기획서에도 박스를 그리고, 디자이너도 피그마에 똑같은 박스를 또 그리는 낭비였죠.

이 기회에 기획자 문서의 변화가 일어나면 어떨까요? 화면 구조와 시각적 UX의 정의는 온전히 디자인 자산(Figma)에 귀속시키고, 복잡한 시스템 로직과 예외 처리 스펙은 하네스 안에서 클로드 코드로 완벽하게 뽑아내어 관리하는 흐름으로 말이죠. 이처럼 프로덕트의 논리와 시각적 컴포넌트가 완벽히 분리되어 시스템화되는 순간, 기획자가 일하는 패러다임 역시 완전히 다른 차원으로 도약하게 될 거라고 생각합니다.

이 거대한 패러다임 시프트의 초입에서, 이제 기획자는 챗GPT 창을 열고 "이것 좀 고쳐줘, 예외 케이스 좀 다시 써줘"라며 매번 빌고 애원하는 불안한 '바이브 기획'이나, AI가 뱉어낸 자잘한 환각을 감시하고 뒤처리하는 'AI 시터' 역할에서 과감하게 벗어나야 합니다. 우리 서비스의 절대적인 규칙을 정의하고, AI가 그 안에서 안전하게 날뛸 수 있도록 완벽한 업무 파이프라인을 짜주는 '기획 하네스 엔지니어'가 되어야 하죠.

무작정 AI와 대화하며 시간을 버리는 대신, 나만의 단단한 가드레일을 설계해 보세요. 박스 그리던 시간에 커피 한 잔 더 마시면서, 서비스의 진짜 예외 정책과 시스템 구조를 고민하는 진짜 설계자로 진화할 타이밍입니다.

📮 다음 호 예고

[20호] Product Builder 시대 PM의 생존 전략

요즘 PM 채용 공고가 이상합니다. 같은 회사, 같은 직급인데 달라진 PM의 JD.
온 우주가 PM에게 요구하고 있는 게 뭔지 뜯어봅니다.

✉️ 다음 호가 궁금하신 분들은 아래 [구독하기] 버튼을 눌러주세요.