이 스킬이면 어떤 프로젝트든 계획할 수 있습니다

• 채널: Tech Bridge (@TechBridge-KR)
• 원제/자막 표기: [한영자막] 이 스킬이면 어떤 프로젝트든 계획할 수 있습니다
• URL: https://www.youtube.com/watch?v=HVUH5F1FHlM
• 영상 길이: 884초 (약 14분 44초)
• 발행일 추정: 처리일 기준 2026-08-06 (원본 발행일 미상 — 채널 자막 최근 업로드분으로 추정)
• 처리일: 2026-08-06

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

에이전트와 함께라면 규모에 상관없이 어떤 프로젝트든 계획할 수 있는 방법을 찾았다며, 발표자는 자신이 만든 ==Wayfinder(웨이파인더)== 스킬을 소개한다. 기존에 쓰던 단일 세션 기반 계획 도구(Grill Me / Grill with Docs)는 컨텍스트 창 한계 때문에 큰 작업을 계획하기에 근본적으로 부족했고, Wayfinder는 이 한계를 없애기 위해 지도(Map)와 티켓(Ticket) 개념으로 여러 세션에 걸친 계획을 조율한다.

• 기존 도구들은 단일 세션에 얽매여 있어 야심찬 계획을 세우기 어려웠음
• Wayfinder는 "전쟁의 안개(fog of war)"를 걷어내듯, 목적지까지의 불확실한 경로를 단계별로 밝혀 나가는 방식
• 소프트웨어 개발자로서 AI 이전 시대에 배운 기획의 기본 원리에 기반해 설계됨

발표자는 이 방법론이 코딩 작업뿐 아니라 정원 사무실 건축 같은 비(非)코딩 프로젝트에도 적용 가능하다고 강조하며, 실제 사용 사례(커맨드 팔레트 기능 개발)를 통해 구체적인 작동 방식을 시연한다.

---

1. Wayfinder의 탄생 배경

기존 계획 도구의 한계를 극복하기 위해 다중 세션을 조율할 수 있는 새로운 접근 방식이 필요했다.

1.1. 기존 방식(Grill Me / Grill with Docs)의 한계

1. 단일 세션 종속성

   1. 컨텍스트 창의 물리적 제한: 어떤 작업은 에이전트의 컨텍스트 창, 특히 "스마트 존"에 담을 수 있는 양보다 크다
   2. 사전 작업 분할의 비효율: 이 한계를 알기 때문에 AI 세션 전에 미리 작업을 작은 단위로 쪼개는 습관이 생겼지만, 결국 계획 도중 답할 수 없는 질문에 부딪히거나 "안개 속에 갇힌" 느낌을 받게 됨
   3. 토큰 관리 부담: 스마트 존을 관리하면서 토큰을 너무 많이 쓰지 않으려 계속 신경 써야 하는 비효율

2. 야심의 축소

   1. AI에 맞춘 제한: 발표자는 스스로 "충분히 야심적이지 못했다"고 느꼈고, 만들고 싶은 것을 AI가 다룰 수 있는 범위로 축소하는 경향이 있었다고 고백
   2. Grill with Docs는 여전히 중요한 기본 요소: 다만 실질적으로 단일 세션에만 국한된다는 한계는 그대로 남음

1.2. 새로운 접근: 지도(Map)와 안개(Fog of War)

1. 경로의 본질적 불확실성

   1. 시작점은 있지만 경로는 모호함: 큰 프로젝트는 출발점과 대략적인 목적지는 알지만, 그 사이의 과정이 안개처럼 흐릿한 경우가 대부분
   2. 공학을 넘어선 보편성: 이는 소프트웨어 공학뿐 아니라 삶에서 야심찬 계획을 세우는 모든 영역에 해당한다고 언급

2. 지도 개념의 도입

   1. 경로를 시각화: Wayfinder는 목적지까지 가는 경로를 "지도"로 만들어 보여준다 — 그래서 이름이 "길을 찾는 사람(Wayfinder)"
   2. 개별 세션 = 티켓: 지도 위의 각 항목은 "티켓"이며, 각 티켓은 에이전트와의 개별 세션을 필요로 함 (프로토타입 제작 세션, 그릴링/질의응답 세션, 리서치 세션 등)
   3. 단일 스킬, 모든 코딩 에이전트 호환: 이 모든 기능이 하나의 스킬로 패키징되어 있으며 특정 코딩 에이전트에 종속되지 않음

---

2. Wayfinder의 작동 원리

지도는 이미 알려진 결정(프론티어)과 아직 알 수 없는 결정(안개)을 함께 추적하며, 안개가 모두 걷히면 목적지에 도달할 충분한 결정이 내려진 상태가 된다.

2.1. 지도와 이슈 트래커 통합

1. 프론티어와 안개의 추적

   1. 프론티어(frontier): 지금 당장 결정 가능한 티켓들의 최전선
   2. 안개(fog): 아직 연구가 안 됐거나, 살펴볼 프로토타입이 없거나, 충분한 논의가 없어서 결정을 내릴 수 없는 항목들
   3. 조사와 작업까지 포함: Wayfinder는 리서치 관리뿐 아니라 실제 작업(설정 구성, 사람과의 통화, 심부름 등)도 알아서 처리하도록 조율

2. 이슈 트래커 위에서 동작

   1. GitHub 이슈로 구현된 실제 사례: 발표자의 공개 강의 영상 관리 저장소에 최근 만든 Wayfinder 지도들이 존재 — 큰 지도(부모 이슈) 아래 12개의 하위 이슈(티켓)로 구성된 예시를 직접 보여줌
   2. 결정의 양방향 기록: 하위 티켓에서 결정이 내려지면(예: "게시 경쟁 중 클립 닫기" 이슈를 몇 주 전 논의로 해결) 그 해결 내용이 상위 지도에도 요약되어 다시 기록됨
   3. 이슈 트래커 종류 무관: GitHub뿐 아니라 Linear, Jira 등 원하는 어떤 이슈 트래커와도 사용 가능하며, setup.map.skills를 통한 약간의 설정만 필요

2.2. 4가지 티켓 유형

1. 조사(Research) 티켓
   1. 정보 수집 목적: 에이전트가 현장에 나가 정보를 찾아와야 할 때 발급되며, 대개 즉시 시작되어 사람이 지켜볼 필요 없이 하위 에이전트가 작업 후 결과를 보고
2. 프로토타입(Prototype) 티켓
   1. 폭포수 방지 장치: 일부 사람들은 Wayfinder를 보고 "계획이 너무 많다, 폭포수 모델 아니냐"고 반응하지만, 프로토타입이 바로 저품질 대규모 사전 계획(폭포수)이 되는 것을 막아주는 장치
   2. 고충실도 피드백 확보: 프로토타입은 실제로 만들고 있는 제품에 대한 피드백을 얻는 매우 효과적인 방법이며, 별도 영상에서 다룬 프로토타입 제작 기법을 재사용
3. 그릴링(Grilling/BBQ) 티켓
   1. 논의가 필요한 순간: 실행 세부 사항이나 계획의 특정 측면에 대해 토론이 필요할 때 사용되는 티켓 (Grill Me/Grill with Docs 스킬 계열)
4. 작업(Task) 티켓
   1. 현실 세계의 할 일: 에이전트가 직접 할 수 없는 일이거나, 할 수는 있지만 다른 작업에 우선순위가 밀린 일들을 담당

2.3. 티켓 간 차단(Blocking) 관계

1. 의사결정의 순서 관리
   1. 선행 결정에 종속되는 후행 결정: 일부 결정은 다른 결정이 먼저 내려진 뒤에야 내릴 수 있으므로, Wayfinder는 티켓 간 차단 관계를 설정해 순서를 관리
   2. 실제 진행률 예시: 발표자가 보여준 지도는 17개 티켓 중 14개가 완료된 상태 — 다만 지도 전체의 핵심이 되는 스킬 자체는 아직 구축되지 않아, 그 스킬이 완성되면 다른 항목들을 다시 검토해야 하는 상황이 남아있었음
   3. 반복적 프론티어 갱신: 티켓 하나를 해결할 때마다 "이제 새로운 티켓이 어떻게 생기는지, 어느 방향으로 나아가고 있는지" 확인하는 것이 Wayfinder 작업의 일반적인 패턴

---

3. 실전 사용 예시 — 커맨드 팔레트 기능 개발

발표자는 자신의 애플리케이션(CVM 다이어그램 창)에 커맨드 팔레트 기능을 추가하는 실제 과정을 통해 Wayfinder 사용법을 시연한다.

3.1. 목적지 정의와 그릴링

1. 원하는 결과물 설명
   1. 초기 요청: "CVM에 아이콘 선택기를 추가하고 싶다", "다른 다이어그램을 검색할 수 있으면 좋겠다", "다이어그램의 특정 부분을 복사해서 큰 덩어리로 저장하고 싶다"는 식으로 Wayfinder 스킬을 호출하며 원하는 바를 설명
   2. 목적지로 spec을 선택: 결국 원했던 최종 결과물은 "제작 가능한 사양서(buildable spec)"였음
2. 자동 탐색과 인터뷰
   1. 저장소 탐색 후 그릴링 발동: Wayfinder가 저장소를 살펴본 뒤 그릴링 스킬을 발동시켜 "완료된 모습이 어떤 것인지", "사양서가 필요한지" 등을 질문 공세로 확인 (사양서를 추천받음)
   2. 첫 지도와 티켓 생성: 몇 가지 초기 질문 후 첫 번째 지도와 티켓을 생성하고, 이어서 다른 티켓들을 하위 이슈로 추가 생성

3.2. 티켓 처리 흐름

1. 즉시 처리 가능한 티켓 선별
   1. 7개 중 3개만 착수 가능: 처음부터 7장의 티켓이 생성됐지만 그중 3개만 당장 처리 가능한 상태였음 — 아이콘 이름의 유래, 컴포넌트 저장 방식, 팔레트 정보 아키텍처/그리드 키보드 탐색 방식(발표자가 정확히 기억하지 못한 항목)
2. 티켓별 개별 세션
   1. 티켓 이름으로 Wayfinder 재호출: 각 티켓을 새로운 세션에서 처리하기 위해 해당 티켓 이름으로 Wayfinder를 호출
   2. 핸드오프 스킬로 자동화: 발표자는 좀 더 세련된 방식으로, 프롬프트를 자동 생성하고 Claude 하위 에이전트를 만들어내는 "인계(handoff) 스킬"을 사용 — 본질적으로는 특정 지도와 특정 티켓에서 Wayfinder를 호출하는 것과 동일 (예시 티켓: "Lucid SVG 지오메트리를 경로 생성기로 트랜스파일링")

3.3. 결과 — 17개 중 14개 완료

1. 높은 완료율에도 남은 과제
   1. 핵심 스킬은 미완: 많은 티켓이 처리됐지만 지도 전체의 핵심이 되는 스킬 자체는 아직 만들지 못한 상태였고, 이 스킬이 완성되면 그 결과를 바탕으로 다른 항목들을 재검토해야 함

---

4. 지도 완성 후 — 스펙 생성과 활용

지도가 완성되면 그 지도를 기반으로 사양서(spec)를 만들고, 이를 다시 티켓으로 전환해 구현하는 것이 발표자의 표준 워크플로우다.

4.1. Wayfinder → Spec → Tickets 워크플로우

1. 지도에서 사양서로
   1. 명령 하나로 스펙 생성: Wayfinder 지도에서 "사양(to spec)"을 호출하면, 지도에서 나온 모든 결정 사항이 담긴 거대한 문서가 GitHub 이슈로 생성됨
   2. 문서 크기의 방증: 초안이 너무 길어서 GitHub의 글자 수 제한을 초과했을 정도로 방대했다는 일화 소개(웃음)
2. 평소와 동일한 후속 프로세스
   1. 스펙 → 티켓 → 구현 → 코드 리뷰: 사양서 작성 후 평소처럼 티켓을 발행하고, 각 티켓을 구현한 뒤 마지막으로 코드 리뷰를 진행
   2. Grill with Docs와 동일한 위치: Wayfinder는 발표자의 기존 워크플로우에서 Grill with Docs가 있던 자리에 정확히 들어간다 — 다만 Grill with Docs 대신 Wayfinder에서 훨씬 많은 시간을 들여 거대한 지도를 만들고, 그 지도를 기반으로 스펙과 티켓을 생성하는 방식으로 확장된 것

4.2. Grill with Docs와의 차이점

1. 원본 자료로의 직접 접근
   1. 모든 스펙 항목이 결정 티켓과 연결: Wayfinder가 만드는 스펙은 매우 상세하며, 각 항목이 원래의 결정 티켓과 링크로 연결되어 있어 에이전트가 혼란스러울 때 원본 자료를 직접 확인 가능
   2. Grill with Docs의 약점 보완: 기존 Grill with Docs의 가장 큰 약점은 스펙에 전적으로 의존해야 했다는 점 — 스펙은 회의에서 실제로 나온 발언의 요약본에 불과했음. Wayfinder는 원본 자료(primary source)에 직접 접근할 수 있게 해준다는 점에서 차별화됨
2. 스펙의 비영구성
   1. 완료 후 스펙 삭제: 발표자는 스펙이 포함된 이슈를 닫으면 그 스펙을 저장소에서 아예 삭제하며, 이후 거의 다시 참조하지 않음 — "일단 코드에 명세가 반영되면 명세 부분은 지워버리면 된다"

---

5. 자주 묻는 질문 (FAQ)

5.1. 언제 사용해야 하나 — 절차가 너무 무겁다는 반응

1. 판단 기준: 단일 세션 완결 가능 여부
   1. 한 번의 회의로 끝날 일이면 그냥 한 번에: 목적지까지 가는 길을 이미 어느 정도 안다면 Wayfinder 없이 단일 세션으로 바로 길을 찾아가면 됨
   2. Wayfinder는 "전쟁의 안개" 상황을 위한 도구: 어디로 가야 할지 전혀 감이 안 잡히고, 일단 시작해서 어디까지 가게 되는지 지켜봐야 하는 경우에 유용

5.2. 코딩 외 활용 사례

1. 정원 사무실 건축 프로젝트
   1. 비(非)코딩 작업에도 적용: 발표자는 정원에 간이 사무실을 짓는 프로젝트에도 Wayfinder를 사용 중 — 부지 조사 의뢰, 필요한 것 파악, 연락할 사람 알아내기, 시공 가능한 여러 업체 조사 등을 조율

5.3. SDD(Spec-Driven Development)와의 차이

1. 스펙의 성격이 다름
   1. "스펙 = 다중 세션 작업의 목적지 문서": 발표자가 생각하는 스펙은 여러 세션에 걸쳐 진행되는 작업의 최종 목적지 문서일 뿐 — 예를 들어 너무 커서 여러 에이전트 세션에 걸쳐 예약해야 하는 작업이 있을 때, 마지막 단계에 이르러 "우리가 어디로 가고 있었는지" 파악하기 위한 문서
   2. 의사결정 티켓 vs 구현 티켓: Wayfinder 초심자들이 자주 혼란스러워하는 지점 — Wayfinder가 처음 만드는 티켓들은 "의사결정 티켓"이고, 이후 스펙에서 파생되는 것은 "구현 티켓"으로 서로 다른 개념
   3. 핵심 차이 — 영구 보관 여부: 일반적인 스펙 기반 개발(SDD)에서는 사람들이 스펙을 완료 후에도 어딘가에 계속 보관하며 나중에 다시 돌아가 수정·보완한다. 반면 발표자의 Wayfinder 스펙은 비영구적(non-persistent)이며, 여러 SDD 접근법이 있을 수 있음을 인정하면서도 이 차이를 명확히 함

---

주요 발언 모음

"에이전트와 함께라면 규모에 상관없이 모든 종류의 프로젝트를 계획할 수 있는 방법을 알아낸 것 같아요."

"저는 제 자신이 충분히 야심적이지 못하다고 느꼈고, 그 때문에 제가 만드는 것들을 AI에 맞춰 제한하는 경향이 있었는데, 그건 옳지 않다고 생각합니다."

"그것은 당신이 목적지까지 깔끔하게 갈 수 없다는 것을 알고 있습니다. 전쟁의 안개를 걷어내야 합니다."

"프로토타입은 대규모의 저품질 사전 계획 작업이 진행되는 폭포수 모델처럼 되는 것을 방지하는 방법입니다."

"Grill with Docs의 가장 큰 약점은 바로 사양서에 전적으로 의존해야 한다는 점이었는데, 사양서는 회의에서 실제로 나온 발언을 요약한 것에 불과하다는 것이었습니다. 반면 Wayfinder를 사용하면 이제 그 원본 자료에 직접 접근할 수 있게 되었는데, 정말 놀라운 일입니다."

"만약 당신이 하고 있는 일이 한 번의 회의로 완료되고 계획될 수 있다고 생각한다면, 한 번의 회의로 계획하라는 것입니다."

"새로운 웨이파인더 세션을 시작할 때, 뭔가 멋진 것을 보게 될 거라는 기대감과 동시에 어떻게 그 멋진 장면을 보게 될지 정확히 알지 못하는 설렘보다 더 즐거운 느낌은 없을 겁니다."

핵심 데이터 & 수치

• 티켓 완료율 예시: 실제 지도 사례에서 17개 티켓 중 14개 완료 (핵심 스킬 자체는 아직 미완성)
• 초기 생성 티켓 수: 커맨드 팔레트 예시에서 첫 그릴링 후 7장의 티켓이 즉시 생성되었으나, 당장 착수 가능한 것은 3장뿐이었음
• 스펙 문서 크기: Wayfinder 지도에서 생성한 초안 스펙이 GitHub 이슈 글자 수 제한을 초과할 정도로 방대했음
• 티켓 유형 4종: 조사(Research) / 프로토타입(Prototype) / 그릴링(Grilling) / 작업(Task)

결론 및 시사점

1. 큰 프로젝트는 지도(Map)와 티켓(Ticket) 단위로 쪼개 여러 세션에 걸쳐 조율하라: 컨텍스트 창 한계 때문에 어쩔 수 없이 작업을 축소하지 말고, Wayfinder처럼 다중 세션을 오케스트레이션하는 방식으로 야심찬 계획을 세울 수 있다.
2. 불확실성이 클 때만 사용하라: 목적지까지 가는 길을 이미 안다면 굳이 Wayfinder를 쓸 필요 없이 단일 세션(그릴링)으로 충분하다. "안개가 낀" 상황, 즉 시작은 하지만 정확히 어디로 갈지 모를 때 가치가 극대화된다.
3. 프로토타입을 적극 활용해 폭포수 계획을 방지하라: 방대한 사전 계획이 저품질 폭포수 모델로 전락하지 않도록, 실제로 만들고 있는 것에 대한 고충실도 피드백을 프로토타입 티켓을 통해 자주 확보해야 한다.
4. 스펙을 원본 결정과 연결하고, 완료 후에는 미련 없이 버려라: 스펙이 원래의 결정 티켓과 링크로 연결되어 있으면 에이전트가 혼란스러울 때 원본 자료를 확인할 수 있다. 또한 스펙은 코드에 반영되고 나면 영구 보관할 필요 없이 삭제해도 된다는 관점은 SDD 방식과 다른 실용적 선택지다.
5. 코딩 외 프로젝트(예: 건축, 인테리어 등 오프라인 프로젝트)에도 동일한 프레임워크를 적용할 수 있다: 이슈 트래커 기반의 지도·티켓 개념은 소프트웨어를 넘어 실생활의 복잡한 프로젝트 관리에도 확장 가능하다.