오늘도 공부

AI 영상 제작자를 위한 20가지 프롬프트 추천 스킬

행복한 수지아빠 — Tue, 19 May 2026 11:33:11 +0900

— NolanX AI Skills를 기준으로 보는 “영화형 생성 프롬프트” 설계법

요즘 AI 이미지·영상 생성에서 중요한 것은 단순히 “멋지게 만들어줘”라고 말하는 것이 아니다.
결과물의 품질을 결정하는 핵심은 무엇을 고정하고, 무엇을 움직이고, 어떤 방식으로 촬영되게 할 것인가를 구체적으로 지시하는 데 있다.

NolanX AI의 skills 폴더에 들어 있는 20개의 스킬은 바로 이 지점을 다룬다.
각 스킬은 영화 연출, 스토리보드, 액션 설계, 조명, 샷 구성, 캐릭터 연속성, 레퍼런스 기반 영상 생성, 숏폼 드라마 후킹 등 AI 영상 제작에서 자주 무너지는 문제를 해결하기 위한 작은 제작 규칙집에 가깝다.

이 글에서는 20개 스킬을 하나씩 살펴보며 다음 세 가지를 정리한다.

이 스킬이 무엇인지
언제 사용하면 좋은지
실제 프롬프트에 어떻게 적용할 수 있는지

1. action-choreography-camera-logic

액션 장면의 동선과 카메라 논리를 잡는 스킬

이 스킬은 격투, 추격, 변신, 고속 액션처럼 움직임이 많은 장면에서 사용한다. 핵심은 액션을 “화려하게” 만드는 것이 아니라, 누가 공격하고, 누가 반응하며, 힘이 어느 방향으로 이동하고, 카메라가 왜 그 위치에 있는지를 명확히 하는 것이다. 원본 스킬은 공격자·반응자·운동량 방향·카메라 위치를 정의하고, 좌우 이동 방향과 시선, 공격 방향을 보존하라고 규정한다. (GitHub)

언제 쓰나

격투 장면, 추격 장면, 폭발 장면, 변신 장면, 로봇 전투, 괴수 액션, 차량 추격처럼 화면 안에서 많은 일이 동시에 벌어질 때 유용하다. AI 영상은 액션이 복잡해질수록 공간감이 무너지는 경우가 많기 때문에, 이 스킬은 “액션의 지리감”을 유지하는 데 도움을 준다.

사용 방법

먼저 장면의 기준축을 정한다. 예를 들어 주인공은 왼쪽에서 오른쪽으로 이동하고, 적은 오른쪽에서 왼쪽으로 들어온다고 설정한다. 그다음 공격, 충돌, 회복의 단계를 나누고 각 단계에서 카메라가 어떤 이유로 움직이는지 지정한다.

카메라 움직임도 아무렇게나 쓰면 안 된다. 위협을 드러내기 위한 카메라인지, 힘의 방향을 따라가는 카메라인지, 충격을 흡수하는 카메라인지, 인물을 가두는 카메라인지를 분명히 해야 한다.

예제 프롬프트

격투 장면을 액션 동선 중심으로 설계해줘.

주인공은 화면 왼쪽에서 오른쪽으로 돌진한다.
적은 오른쪽에서 방어 자세를 취하다가 뒤로 밀려난다.
첫 2초는 넓은 샷으로 두 인물의 위치와 거리감을 보여준다.
3초 지점에서 주인공이 오른손으로 공격을 시작하고,
카메라는 힘의 방향을 따라 lateral tracking한다.
충돌 순간에는 짧은 impact push-in을 사용하고,
이후 적이 뒤로 밀려나는 recovery beat를 보여준다.

좌우 이동 방향과 공격 방향은 컷 사이에서도 유지해줘.

2. cinema-studio-lens-look

프리미엄 영화 룩을 만드는 렌즈·조리개·질감 스킬

이 스킬은 이미지나 영상에 고급 영화적 질감을 부여할 때 사용한다. 원본은 2.35:1 와이드스크린, 85mm 초점거리, T1.8 대구경 조리개, ARRI Master Primes 렌즈 느낌, 얕은 심도, 필름 그레인, 블룸, 할레이션, 24fps 셔터룰 기반 모션블러 등을 기본 광학 패키지로 제시한다. (GitHub)

언제 쓰나

캐릭터 포스터, 영화 스틸컷, 뮤직비디오 장면, 광고 컷, 시네마틱 키비주얼, 고급 CG 렌더 느낌이 필요할 때 사용한다.

사용 방법

단순히 “시네마틱하게”라고 쓰지 말고, 렌즈와 조리개, 초점, 배경 흐림, 하이라이트 반응, 질감을 구체적으로 써야 한다. 다만 원본 스킬도 강조하듯이, 이런 요소는 장식이 아니라 감정과 이야기 목적에 연결되어야 한다.

예를 들어 고립감을 표현하고 싶다면 얕은 심도로 배경을 흐리고 인물의 얼굴만 선명하게 고정한다. 긴장감을 표현하고 싶다면 어두운 배경 속 하이라이트에 은은한 할레이션을 넣는다.

예제 프롬프트

이 장면을 프리미엄 영화 스틸컷처럼 구성해줘.

2.35:1 anamorphic widescreen.
85mm lens, T1.8 aperture.
주인공의 얼굴에만 초점이 고정되고,
배경은 깊게 흐려진 oval bokeh로 처리한다.
하이라이트에는 subtle bloom과 halation을 넣고,
전체 질감은 high-end cinematic CG with subtle film grain.

렌즈 효과는 장식이 아니라
주인공이 군중 속에서 고립되어 있다는 감정을 강화하는 방향으로 사용해줘.

3. cinematic-hit-marking-action-director

액션의 충돌 타이밍을 0.1초 단위로 설계하는 스킬

이 스킬은 액션 영상에서 “언제 충돌이 일어나는가”를 아주 정밀하게 지정하는 데 사용한다. 원본은 15초 액션 클립을 4~5개의 핵심 구간으로 나누고, 충돌·폭발·반전·타격이 있는 순간에는 0.1초 단위의 hit mark를 포함하라고 지시한다. 각 hit mark에는 충격 프레임, 화면 흔들림, 파편·먼지·스파크·에너지 입자 같은 물리적 피드백이 들어가야 한다. (GitHub)

언제 쓰나

칼싸움, 총격전, 로봇 전투, 마법 충돌, 차량 충돌, 건물 붕괴, 괴수 타격, 변신 장면처럼 충격 타이밍이 중요한 장면에 적합하다.

사용 방법

15초 영상을 4~5개 구간으로 나눈다. 각 구간마다 하나의 주요 액션만 부여하고, 충돌이 일어나는 정확한 시간을 지정한다. 타격 순간에는 짧은 정지감, 화면 흔들림, 파편 반응, 피사체의 밀림이나 자세 변화가 필요하다.

예제 프롬프트

15초 액션 클립을 hit mark 중심으로 설계해줘.

0.0-3.0초:
두 전사가 폐허가 된 복도에서 서로를 향해 접근한다.
카메라는 낮은 위치에서 handheld tracking.

3.2초 hit mark:
검과 방패가 정면 충돌한다.
충격 프레임에서 0.1초간 물리적 정지감,
짧은 screen shake,
금속 sparks와 먼지 입자가 바깥쪽으로 튄다.

3.3-7.0초:
방패를 든 인물이 오른쪽 뒤로 밀려난다.
카메라는 충격 방향을 따라 recovery drift.

7.8초 hit mark:
검이 콘크리트 바닥을 긁으며 sparks를 만든다.

11.4초 hit mark:
마지막 돌진이 갑옷을 강하게 밀어내고,
카메라는 impact push-in으로 충격을 강조한다.

4. cinematic-story-architecture

느슨한 아이디어를 영화적 서사 구조로 바꾸는 스킬

이 스킬은 이야기 중심의 영상, 트레일러, 숏폼 드라마, 각색 장면, 멀티샷 영상에 사용한다. 원본은 먼저 주인공의 욕망, 장애물, 전환점, 보상 또는 클리프행어를 잠그고, 장면을 설명문이 아니라 실행 가능한 beat로 나누라고 한다. 또한 첫 3초의 강한 후킹과 각 beat마다 의미 있는 상승이 중요하다고 설명한다. (GitHub)

언제 쓰나

“이런 장면을 영화처럼 만들어줘”라는 아이디어를 구체적인 장면 구조로 바꿀 때 사용한다. 숏폼 드라마, 영화 예고편, 웹드라마 장면, 게임 시네마틱, 브랜드 스토리 영상에도 잘 맞는다.

사용 방법

먼저 이야기 엔진을 정한다.

주인공은 무엇을 원하는가?
무엇이 그것을 막는가?
어디서 판이 뒤집히는가?
끝은 보상인가, 충격인가, 클리프행어인가?

그다음 3~7개의 beat로 나누고, 각 beat마다 액션, 감정 변화, 시각적 발견, 카메라 의도를 적는다.

예제 프롬프트

이 아이디어를 cinematic story architecture로 정리해줘.

장면:
도망치던 여자가 오래된 지하역에서
자신을 쫓던 남자가 사실은 자신을 구하려는 사람이라는 사실을 알게 된다.

구성:
- protagonist desire
- obstacle / pressure
- turning point
- payoff or cliffhanger

그리고 5개의 beat로 나눠줘.
각 beat마다 action, emotional turn, visual revelation, camera intention을 적어줘.
첫 3초 안에 긴장감이 시작되게 하고,
마지막 beat는 다음 장면이 궁금해지는 cliffhanger로 끝내줘.

5. commercial-ad-psychology

광고의 욕망·신뢰·혜택 구조를 설계하는 스킬

이 스킬은 광고, 브랜드 필름, 제품 스토리텔링에 사용한다. 원본은 하나의 핵심 약속으로 시작하고, 혜택을 말로 설명하는 데 그치지 말고 시각적으로 보이게 하라고 한다. 또한 모든 샷이 욕망을 만들거나, 의심을 줄이거나, 약속을 증명해야 한다고 규정한다. (GitHub)

언제 쓰나

제품 광고, 앱 광고, 브랜드 캠페인, D2C 제품 영상, 숏폼 광고, 랜딩페이지용 히어로 비디오를 만들 때 사용한다.

사용 방법

먼저 광고의 핵심 약속을 하나만 정한다.
“더 빠르다”, “더 조용하다”, “더 편하다”, “더 안전하다” 같은 메시지를 한 번에 여러 개 넣지 말고, 가장 중요한 하나만 잡는다.

그다음 장면을 문제 → 제품 경험 → 감정적 보상 → 브랜드 리콜 순서로 구성한다.

예제 프롬프트

무선 이어폰 광고 15초를 만들어줘.

핵심 약속:
소음 속에서도 나만의 조용한 공간을 만든다.

구성:
0-3초: 시끄러운 지하철, 주인공이 피로한 표정으로 서 있다.
3-6초: 이어폰을 착용하는 순간 주변 소음이 시각적으로 흐려진다.
6-11초: 주인공의 얼굴이 안정되고, 배경은 부드러운 bokeh로 분리된다.
11-15초: 제품 클로즈업과 함께 한 문장의 브랜드 메시지로 끝난다.

모든 샷은 욕망 형성, 의심 감소, 약속 증명 중 하나의 기능을 갖게 해줘.

6. continuity-editing-axis-match

180도 법칙과 컷 연결을 관리하는 편집 연속성 스킬

이 스킬은 여러 샷을 이어붙일 때 시선 방향, 이동 방향, 액션 축이 무너지지 않도록 돕는다. 원본은 대화·이동·전투 장면에서 axis of action을 정하고, 컷 사이의 screen direction을 유지하라고 한다. 축을 넘어야 할 경우에는 중립 샷, 회전 동선, 의도적 불안정화가 필요하다고 설명한다. (GitHub)

언제 쓰나

대화 장면, 추격 장면, 액션 장면, 실내 이동 장면, 여러 인물이 얽히는 장면에 사용한다. 특히 AI 영상에서 컷마다 인물 방향이 뒤집히는 문제를 줄이는 데 유용하다.

사용 방법

먼저 축을 정한다.
예를 들어 A는 왼쪽, B는 오른쪽에 있고 서로 마주 본다.
또는 주인공은 계속 왼쪽에서 오른쪽으로 달린다.

그다음 컷을 바꿀 때도 이 방향성을 유지한다. 동작 중간에 컷을 붙이는 match-on-action을 사용하면 전환이 자연스러워진다.

예제 프롬프트

추격 장면을 continuity editing 기준으로 4샷 구성해줘.

기준축:
주인공은 항상 left-to-right 방향으로 달린다.
추격자는 같은 방향으로 뒤따른다.

Shot 1:
wide shot, 골목 전체 지리감 제시.

Shot 2:
주인공이 문손잡이를 잡는 순간에 cut on motion.
카메라는 established axis를 유지한다.

Shot 3:
문을 밀고 나가는 동작을 tighter framing으로 이어받는다.
몸 방향과 이동 방향은 이전 샷과 동일하다.

Shot 4:
추격자가 같은 문을 통과하며 따라온다.
축을 넘지 않고 screen direction을 유지한다.

7. dialogue-performance-blocking

대사 장면을 연기와 몸짓 중심으로 설계하는 스킬

이 스킬은 대화 장면, 감정 연기, 립싱크, 인물 간 권력 변화가 중요한 장면에 사용한다. 원본은 각 대사나 음성 beat마다 인물의 목표, 숨은 의도, 감정 벡터, 몸의 행동, 얼굴 반응을 정의하라고 한다. 또한 모든 대사는 공격, 방어, 폭로, 은폐, 붕괴 중 하나로 기능해야 한다고 강조한다. (GitHub)

언제 쓰나

두 인물의 갈등 장면, 고백 장면, 협박 장면, 법정 장면, 이별 장면, 숏폼 드라마 대사 장면에 적합하다.

사용 방법

대사를 쓰기 전에 각 인물이 지금 무엇을 원하는지 정한다.
겉으로 하는 말과 실제 의도가 다를 수 있다.
예를 들어 “괜찮아”라는 대사는 정말 괜찮다는 뜻일 수도 있지만, 분노를 숨기는 방어일 수도 있다.

대사마다 다음 요소를 붙이면 좋다.

objective: 지금 원하는 것
subtext: 숨은 뜻
emotional vector: 감정의 방향
body behavior: 몸의 행동
facial behavior: 얼굴 반응

예제 프롬프트

두 인물의 대화 장면을 dialogue performance blocking 방식으로 써줘.

상황:
A는 B가 거짓말했다는 사실을 알고 있지만 바로 말하지 않는다.
B는 들키지 않았다고 생각한다.

각 대사마다 다음 항목을 붙여줘:
- objective
- subtext
- emotional vector
- body behavior
- facial behavior

조건:
긴 talking head를 피하고,
각 대사는 attack, defend, reveal, conceal, break 중 하나로 작동하게 해줘.
침묵과 반응 beat도 포함해줘.

8. director-visual-language

추상적인 분위기를 구체적인 연출 언어로 바꾸는 스킬

이 스킬은 “시네마틱하게”, “고급스럽게”, “불안하게”, “웅장하게” 같은 추상 표현을 실제 연출 언어로 바꾸는 데 사용한다. 원본은 프레이밍 크기, 앵글, 렌즈감, 카메라 움직임, 조명 논리, 팔레트, 질감 등을 결정해 하나의 일관된 visual language를 만들라고 설명한다. (GitHub)

언제 쓰나

감독 노트, 비주얼 디렉션, 콘셉트 아트 지시문, 영상 프롬프트, 광고 무드보드, 뮤직비디오 장면 설계에 사용한다.

사용 방법

“분위기”를 바로 쓰지 말고, 그 분위기가 어떤 시각적 결정으로 구현되는지 적는다.

예를 들어 권력감을 표현하려면 low angle, 넓은 공간 점유, 강한 backlight를 사용할 수 있다. 억압감을 표현하려면 프레임을 압축하고, 인물을 문틀이나 그림자 안에 가둘 수 있다.

예제 프롬프트

이 장면의 visual language를 감독 노트처럼 만들어줘.

감정:
주인공이 점점 권력을 잃어간다.

연출:
초반에는 eye-level medium shot으로 시작한다.
권력이 흔들릴수록 high angle로 전환한다.
프레임 안에서 주인공을 문틀과 그림자 사이에 가둔다.
렌즈는 compressed perspective를 사용해 공간을 답답하게 만든다.
조명은 차가운 practical light 중심,
shadow density는 점점 깊어진다.
카메라는 느린 push-in으로 압박감을 만든다.

9. environment-scene-extraction-bible

장소 자체를 주인공으로 만드는 환경 바이블 스킬

이 스킬은 인물보다 장소, 세계, 로케이션이 중요한 장면에 사용한다. 원본은 환경을 구체적으로 이름 붙이고, 전경·중경·배경·대기, 시간대, 날씨, 빛 방향, 주요 재질을 고정하라고 설명한다. 사람이 없는 환경을 만들 때는 사람, 실루엣, 군중, 애매한 인간 흔적을 명시적으로 제외해야 한다. (GitHub)

언제 쓰나

배경 콘셉트 아트, 로케이션 바이블, 게임 월드 디자인, 영화 세트 디자인, 사람 없는 폐허 장면, 자연 풍경, 도시 환경을 만들 때 사용한다.

사용 방법

장소를 “폐허 도시”라고만 쓰지 말고, 특정한 이름과 상태를 부여한다.
예를 들어 “태풍이 지나간 새벽의 해안 산업도시”처럼 시간, 사건, 물성, 날씨를 함께 고정한다.

전경, 중경, 배경을 분리하면 AI가 공간을 더 안정적으로 구성한다.

예제 프롬프트

사람 없는 폐허 도시의 environment bible을 만들어줘.

환경 이름:
비가 멈춘 직후의 동부 항구 폐허 도시.

Foreground:
젖은 아스팔트, 부서진 유리 조각, 녹슨 도로 표지판.

Midground:
반쯤 무너진 버스 정류장, 물웅덩이에 반사되는 네온 잔광.

Background:
안개 속에 흐릿하게 보이는 항구 크레인과 고층 건물 실루엣.

Atmosphere:
새벽 직후, 약한 비안개, 북동쪽에서 들어오는 차가운 backlight.

Materials:
젖은 콘크리트, 녹슨 금속, 깨진 유리, 오래된 플라스틱.

No-human rule:
사람, 실루엣, 군중, 신체 일부, 애매한 인간 흔적은 모두 제외.

10. lighting-continuity-design

장면 간 조명 분위기와 대비를 유지하는 스킬

이 스킬은 단순히 “예쁜 조명”을 만드는 것이 아니라, 여러 샷 사이에서 조명의 방향과 대비, 분위기가 유지되도록 돕는다. 원본은 1:1~2:1은 부드럽고 개방적인 분위기, 4:1은 드라마틱하지만 읽기 쉬운 분위기, 8:1 이상은 강하고 어둡고 불길한 분위기로 제시한다. 또한 key direction, fill, rim, practical light, 대기 매질을 추적하라고 한다. (GitHub)

언제 쓰나

멀티샷 영상, 시퀀스, 광고, 인터뷰, 드라마 장면, 액션 장면, 어두운 실내 장면에서 조명 톤이 컷마다 바뀌는 문제를 줄이고 싶을 때 사용한다.

사용 방법

시퀀스 전체의 조명 규칙을 먼저 정한다.
예를 들어 “왼쪽 후방 key light, 약한 fill, 4:1 contrast ratio, 공기 중 먼지 haze”처럼 기준을 만든다.

그다음 각 샷에서 이 조명 규칙을 유지할지, 이야기상 바꿀지 명시한다.

예제 프롬프트

3샷 시퀀스의 lighting continuity를 설계해줘.

전체 조명 규칙:
4:1 contrast ratio.
왼쪽 후방에서 들어오는 차가운 key light.
오른쪽에는 아주 약한 fill.
얇은 dust haze가 빛을 잡아준다.
배경에는 작은 practical light가 있지만 주광원은 아니다.

Shot 1:
wide shot에서도 같은 key direction 유지.

Shot 2:
medium close-up으로 들어가도 eye-light가 갑자기 밝아지지 않게 한다.

Shot 3:
긴장감이 커지지만 조명이 flat frontal light로 바뀌지 않는다.
shadow density는 유지하고, rim light만 약간 강해진다.

11. long-form-continuity-bible

긴 시리즈에서 캐릭터·소품·세계관이 드리프트하지 않게 하는 스킬

이 스킬은 여러 장면, 여러 에피소드, 시퀄, 연속 생성 작업에서 정체성과 세계 상태를 유지하는 데 사용한다. 원본은 얼굴형, 머리, 실루엣, 의상, 손상 상태, 소품 형태, 장소 배치, 날씨, 시간대, 이동 방향, 렌즈 언어 등을 추적하라고 한다. 또한 새 샷이 이전 샷을 이어갈 때 무엇이 바뀌면 안 되는지 명시해야 한다. (GitHub)

언제 쓰나

AI 웹드라마, 연속 숏폼, 에피소드형 영상, 게임 시네마틱, 캐릭터가 반복 등장하는 이미지 시리즈, 같은 장소에서 이어지는 장면에 적합하다.

사용 방법

먼저 변하지 않아야 하는 항목을 continuity bible로 정리한다.

캐릭터 얼굴, 의상, 소품, 손상 상태, 배경 날씨, 색감, 이동 방향 등을 고정한다.
그다음 새 샷을 만들 때 “이전 샷에서 이어받아야 할 상태”와 “이번 샷에서만 바뀌는 상태”를 분리한다.

예제 프롬프트

이 시리즈를 위한 long-form continuity bible을 만들어줘.

Character continuity:
HERO_01은 날카로운 턱선, 짧은 검은 머리, 왼쪽 눈 아래 작은 흉터를 유지한다.
의상은 흰색 롱코트, 오른쪽 소매가 찢어진 상태.
왼손에는 금속 장갑을 착용한다.

Prop continuity:
SWORD_01은 검은 손잡이, 은색 칼날, 푸른 빛이 약하게 도는 금속 재질.
항상 오른손 또는 오른쪽 허리 쪽에 위치한다.

Location continuity:
비 오는 골목, 젖은 벽돌, 푸른 backlight, 낮은 안개.
시간대는 밤.

Motion continuity:
주인공은 이전 샷에서 left-to-right로 달리던 상태를 이어간다.

Do not change:
얼굴, 코트 실루엣, 소매 손상, 장갑 위치, 비 오는 날씨, 푸른 조명 톤.

12. modular-film-prompt-bible

영화형 프롬프트를 모듈로 나누는 핵심 템플릿 스킬

이 스킬은 단일 프롬프트보다 더 강력한 “창작 바이블 + 샷 실행 지시” 구조를 만든다. 원본은 프롬프트를 identity lock, world and genre lock, medium and realism lock, sound policy, per-shot execution, continuity carryover 순서로 작성하라고 제시한다. 또한 {{Portrait 1}}, {{Scene 1}}, @image 1, @video 1 같은 레퍼런스 플레이스홀더를 지원하는 구조로 설계되어 있다. (GitHub)

언제 쓰나

긴 영상 프로젝트, 캐릭터가 반복 등장하는 작업, 레퍼런스 이미지 기반 영상, 영화식 콘셉트 아트, 시리즈형 프롬프트, 고정 세계관이 필요한 생성 작업에서 가장 범용적으로 사용할 수 있다.

사용 방법

프롬프트를 한 문단으로 쓰지 않는다.
먼저 고정되어야 하는 세계관과 정체성을 잠근다.
그다음 현재 샷에서만 일어나는 변화와 동작을 적는다.

이 스킬은 특히 “매번 다시 설명하다가 캐릭터가 바뀌는 문제”를 줄이는 데 유용하다.

예제 프롬프트

아래 콘셉트를 modular film prompt bible 형식으로 만들어줘.

Core premise:
전쟁 이후의 사막 도시에서,
망가진 전투 로봇과 어린 정비사가 함께 탈출한다.

Recurring references:
@image 1 = 어린 정비사 identity reference
@image 2 = 전투 로봇 identity reference
@image 3 = 사막 도시 world reference

Identity lock:
정비사의 얼굴형, 의상 실루엣, 공구 가방, 먼지 묻은 피부 질감 고정.
로봇의 머리 형태, 금속 재질, 파손된 왼쪽 어깨, 붉은 LED 눈 고정.

World and genre lock:
사막화된 atompunk 도시.
먼지, 낡은 금속, 태양에 바랜 간판, 아날로그 계기판.

Medium and realism lock:
premium cinematic CG with film behavior.
플라스틱 같은 표면, 게임풍 렌더, 무중력 움직임은 피한다.

Sound policy:
BGM 없이 현장음, 발소리, 금속 마찰음, 먼지바람 소리만 사용.

Shot 1:
objective / framing / camera / action / sound / continuity 순서로 작성.

13. reference-driven-video-prompting

이미지·영상 레퍼런스를 기반으로 움직임을 설계하는 스킬

이 스킬은 이미지 투 비디오, 비디오 연장, 키프레임 기반 프롬프트, 카메라 제어, 레퍼런스 기반 일관성 유지에 사용한다. 원본은 입력 이미지가 있을 때 이미지를 다시 길게 설명하기보다 원하는 움직임과 카메라 행동에 집중하라고 한다. 또한 identity reference, world/location reference, previous formal shot continuity, style reference, motion prompt 순서의 우선순위를 제시한다. (GitHub)

언제 쓰나

이미지를 영상으로 만들 때, 이전 영상을 이어붙일 때, 특정 캐릭터 얼굴이나 장소 분위기를 유지하고 싶을 때 사용한다.

사용 방법

레퍼런스가 있다면 텍스트에서 이미지를 반복 설명하지 않는다.
대신 “무엇이 움직이는가”, “카메라는 어떻게 반응하는가”, “첫 프레임에서 마지막 프레임까지 무엇이 변하는가”를 쓴다.

예제 프롬프트

@image 1의 캐릭터 정체성은 그대로 유지해줘.
이미지 속 얼굴, 머리, 의상 실루엣은 바꾸지 않는다.

텍스트에서는 이미지를 다시 설명하지 말고
움직임과 카메라만 지시한다.

Motion:
캐릭터는 천천히 앞으로 걸어온다.
무거운 코트를 입고 있어 움직임은 절제되어 있다.
마지막 2초에 표정이 굳고 시선이 카메라를 향한다.

Camera:
카메라는 캐릭터가 다가올 때 천천히 뒤로 물러난다.
마지막에는 medium close-up으로 부드럽게 push-in한다.

Continuity:
identity, costume silhouette, lighting palette는 @image 1과 일치해야 한다.

14. scene-blocking-and-staging

정적인 장면을 공간 안의 행동으로 바꾸는 블로킹 스킬

이 스킬은 인물의 위치, 거리, 접근, 후퇴, 정지, 전경과 배경의 관계를 설계할 때 사용한다. 원본은 인물이 움직이는 이유가 목표, 권력, 공포, 발견, 긴급함의 변화와 연결되어야 한다고 한다. AI 영상에서는 subject path와 camera path를 분리해서 설명해야 한다. (GitHub)

언제 쓰나

대화 장면, 실내 갈등 장면, 군중 장면, 액션 전 긴장 장면, 인물 간 권력관계를 시각적으로 보여주고 싶을 때 적합하다.

사용 방법

인물을 그냥 “서 있다”고 쓰지 않는다.
누가 공간을 장악하고 있는지, 누가 갇혀 있는지, 누가 접근하고 누가 물러나는지를 정한다.

블로킹은 감정 변화와 함께 바뀌어야 한다.
상대가 진실을 말하는 순간 한 인물이 한 걸음 물러난다면, 그 움직임 자체가 권력 변화가 된다.

예제 프롬프트

대화 장면을 scene blocking 중심으로 설계해줘.

공간:
작은 사무실. 문은 화면 왼쪽, 책상은 중앙, 창문은 오른쪽 뒤.

A:
문가에 서서 출구를 막고 있다.
처음에는 공간을 장악한 인물이다.

B:
책상 뒤에 앉아 있으며 움직일 공간이 제한되어 있다.

Beat 1:
A는 문가에서 움직이지 않는다.
B는 책상 위 컵을 만지며 불안을 숨긴다.

Beat 2:
B가 진실을 말하는 순간 A가 한 걸음 뒤로 물러난다.
권력 균형이 바뀐다.

Subject path:
B는 앉은 상태에서 천천히 일어난다.

Camera path:
카메라는 B의 감정 변화에 맞춰 천천히 push-in한다.

15. screenplay-fountain-format

시나리오를 Fountain 문법으로 구조화하는 스킬

이 스킬은 시나리오, 장면 대본, 대사, beat outline을 Fountain 문법에 맞게 작성할 때 사용한다. 원본은 INT., EXT., INT./EXT. 같은 장면 제목, 대문자 캐릭터 큐, 대사, 절제된 parenthetical, 화면화 가능한 action block을 사용하라고 설명한다. (GitHub)

언제 쓰나

영화 대본, 숏폼 드라마 대본, AI 영상용 스크립트, 스토리보드 전 단계의 장면 대본을 만들 때 적합하다.

사용 방법

소설처럼 내면을 길게 설명하지 않는다.
카메라가 볼 수 있는 행동만 쓴다.
대사는 캐릭터 이름 아래에 배치하고, 장소와 시간 변화가 있으면 명확한 scene heading을 사용한다.

예제 프롬프트

아래 장면을 Fountain screenplay format으로 작성해줘.

조건:
- 장면 제목은 INT. UNDERGROUND STATION - NIGHT
- 캐릭터 이름은 대문자
- 액션은 화면에 보이는 행동만 쓴다
- parenthetical은 꼭 필요한 경우에만 사용한다
- 내면 묘사나 소설적 설명은 피한다

장면:
여자가 빈 지하역에서 도망치다가
자신을 쫓던 남자와 마주친다.
남자는 그녀를 해치려는 것이 아니라
폭발 직전의 플랫폼에서 구하려고 한다.

16. sd2-pe

Seedance 2.0 영상 생성을 위한 프롬프트 엔지니어링 스킬

이 스킬은 Seedance 2.0 스타일의 영상 생성, 이미지 투 비디오, 비디오 투 비디오 연장, 멀티모달 레퍼런스 매핑에 사용한다. 원본은 입력 비디오를 순서대로 @video 1, @video 2, @video 3으로, 입력 이미지를 @image 1, @image 2, @image 3으로 정확히 매핑하라고 한다. 이전 영상을 이어갈 때는 @video 1을 반복하지 말고 마지막 프레임 상태, 스토리 상태, 카메라 움직임, 액션 모멘텀, 조명, 사운드를 이어가야 한다. (GitHub)

언제 쓰나

Seedance 2.0에 이미지나 영상을 넣고 후속 장면을 만들 때, 15초 영상을 time-slice로 구성할 때, 이전 영상을 자연스럽게 연장하고 싶을 때 사용한다.

사용 방법

먼저 모든 입력 자산을 정확히 매핑한다.
그다음 15초 영상을 시간 구간으로 나누고, 각 구간에 액션, 카메라, 연기, 대사, 사운드를 배치한다.

비디오 연장에서는 “이전 영상을 다시 보여주지 말 것”을 명확히 써야 한다.

예제 프롬프트

Seedance 2.0용 프롬프트로 변환해줘.

Reference binding:
@video 1 = 이전 장면의 tail 영상.
@image 1 = 주인공 identity reference.
@image 2 = 장소 reference.

V2V extension rule:
새 영상은 @video 1의 마지막 프레임 상태에서 이어진다.
@video 1을 반복하거나 처음부터 재시작하지 않는다.
마지막 프레임의 카메라 방향, 조명, 인물 시선, 이동 momentum을 유지한다.

15-second storyboard:
0-3초: 주인공이 멈춰 서고 숨을 고른다.
3-6초: 뒤쪽에서 낮은 금속음이 들린다.
6-9초: 주인공이 천천히 돌아본다.
9-12초: 카메라가 얼굴로 push-in한다.
12-15초: 어둠 속 붉은 빛이 켜지며 cliffhanger로 끝난다.

Quality constraints:
identity drift, costume change, lighting reset, repeated previous action을 피한다.

17. short-drama-hook-engineering

숏폼 드라마의 첫 1~3초를 설계하는 후킹 스킬

이 스킬은 숏폼 드라마, 트레일러, 릴스·쇼츠형 영상처럼 빠르게 관심을 잡아야 하는 콘텐츠에 사용한다. 원본은 첫 1~3초 안에 갈등, 위험, 고발, 반전, 욕망, 충격, 불안정한 감정을 제시해야 한다고 설명한다. 또한 각 클립은 hook, escalation, exit bridge 구조를 가져야 한다. (GitHub)

언제 쓰나

웹드라마 쇼츠, 릴스 드라마, 틱톡 드라마, 예고편, 짧은 바이럴 영상, 강한 시작이 필요한 광고성 콘텐츠에 적합하다.

사용 방법

설명으로 시작하지 않는다.
가장 강한 행동, 고발, 위기, 반전에서 바로 시작한다.

“그날은 평범한 날이었다”보다
“네가 내 아버지를 죽였지?”가 훨씬 강한 시작이다.

각 2초마다 감정 변화, 반응, 폭로, 권력 이동이 보이도록 구성하면 리텐션이 좋아진다.

예제 프롬프트

30초 숏폼 드라마를 short drama hook 구조로 설계해줘.

첫 2초:
여자가 남자의 멱살을 잡고 말한다.
“네가 내 아버지를 죽였지?”

구성:
0-2초: 강한 고발로 시작.
2-6초: 남자는 부정하지만 눈을 피한다.
6-10초: 여자가 오래된 사진을 꺼낸다.
10-16초: 남자의 표정이 무너지고 권력관계가 바뀐다.
16-24초: 남자는 더 큰 비밀을 암시한다.
24-30초: 문 밖에서 누군가 같은 사진을 들고 서 있다.

마지막은 다음 편을 보게 만드는 exit bridge로 끝내줘.

18. shot-size-and-angle-language

샷 사이즈와 카메라 앵글을 정확하게 쓰는 스킬

이 스킬은 스토리보드나 프롬프트에서 샷 크기와 앵글을 정확히 지정할 때 사용한다. 원본은 ECU, CU, MCU, MS, MFS/MW, FS, WS/LS, EWS 같은 표준 샷 약어와 low angle, high angle, eye level, overhead, canted angle의 기능을 정리한다. 또한 샷 크기 변화는 정보 우선순위를 바꾸기 위해 사용해야 한다고 설명한다. (GitHub)

언제 쓰나

샷리스트, 스토리보드, 영화 프롬프트, 광고 컷 구성, 이미지 생성 프롬프트에서 프레이밍을 정밀하게 통제하고 싶을 때 사용한다.

사용 방법

장면의 목적에 따라 샷 크기를 선택한다.

극단적 클로즈업은 미세 표정이나 사물의 중요성을 보여준다.
와이드샷은 몸의 행동, 공간 관계, 위협의 규모를 보여준다.
익스트림 와이드는 고립감이나 세계의 규모를 보여준다.

앵글도 목적이 있어야 한다.
low angle은 힘과 위협, high angle은 취약함, overhead는 전술적 관계나 무력감을 보여준다.

예제 프롬프트

이 장면을 shot size와 angle 중심으로 재설계해줘.

Beat 1:
EWS, 폐허 도시 속에 홀로 선 주인공.
목적: 고립감과 세계의 규모 제시.

Beat 2:
MS, 주인공이 무너진 문 앞에서 멈춘다.
목적: 행동과 공간 관계 제시.

Beat 3:
CU, 주인공의 눈이 흔들린다.
목적: 깨달음과 공포 표현.

Beat 4:
ECU, 손 안의 작은 열쇠가 떨린다.
목적: 사물의 중요성 강조.

Beat 5:
low angle MCU, 주인공이 결심하고 고개를 든다.
목적: 권력과 결심의 회복.

19. storyboard-shot-design

아이디어를 샷별 스토리보드로 바꾸는 스킬

이 스킬은 아이디어를 실제로 생성 가능한 샷 리스트로 바꿀 때 사용한다. 원본은 각 샷마다 샷 번호, 길이 의도, 피사체 초점, 프레이밍, 카메라 위치와 움직임, 화면 안 액션, 감정 목적, 이전 샷과의 연결, 다음 샷으로 넘어가는 압력을 정의하라고 한다. (GitHub)

언제 쓰나

15초 영상, 30초 광고, 뮤직비디오 장면, 숏폼 드라마, 영화 예고편, AI 영상 제작용 샷리스트를 만들 때 가장 직접적으로 활용할 수 있다.

사용 방법

각 샷은 반드시 역할이 있어야 한다.
새로운 정보, 더 강한 감정, 더 명확한 행동 중 하나를 제공해야 한다.
같은 구도의 반복은 의도된 리듬이 아니라면 피한다.

예제 프롬프트

아래 장면을 6샷 storyboard로 만들어줘.

장면:
한 남자가 새벽의 옥상에서
도시 전체가 정전되는 순간을 목격한다.

각 샷에 다음 항목을 포함해줘:
- shot number
- duration intent
- subject focus
- framing
- camera position and movement
- action inside frame
- emotional purpose
- continuity link from previous shot
- transition pressure into next shot

조건:
각 샷은 새로운 정보, 더 강한 감정, 더 명확한 행동 중 하나를 제공해야 한다.
모든 샷을 generic hero shot으로 만들지 말아줘.

20. world-asset-identity-lock

반복 등장하는 캐릭터·소품·세계관의 정체성을 고정하는 스킬

이 스킬은 반복 등장하는 캐릭터, 소품, 생물, 의상, 환경이 계속 같은 정체성을 유지하도록 만드는 데 사용한다. 원본은 stable ID를 부여하고, 변하지 않는 immutable traits와 샷별로 달라질 수 있는 행동을 분리하라고 한다. 얼굴, 실루엣, 의상 논리, 재질 반응, 팔레트, 행동 시그니처를 고정하는 것이 핵심이다. (GitHub)

언제 쓰나

같은 캐릭터를 여러 장면에서 반복 생성할 때, 같은 무기나 소품이 계속 등장할 때, AI 영상에서 인물 얼굴이나 의상이 매번 바뀌는 문제를 줄이고 싶을 때 사용한다.

사용 방법

먼저 등장 요소마다 ID를 부여한다.
예를 들어 HERO_01, SWORD_01, CITY_01처럼 이름을 붙인다.

그다음 변하지 않는 특성과 장면마다 달라지는 행동을 분리한다.

예제 프롬프트

주인공, 검, 사막 도시를 world asset identity lock으로 정리해줘.

HERO_01:
Immutable traits:
날카로운 턱선, 짧은 검은 머리, 왼쪽 눈 아래 작은 흉터.
흰색 롱코트, 오른쪽 소매가 찢어진 상태.
걸을 때 오른쪽 어깨가 약간 낮게 움직이는 습관.

Variable behavior:
이번 샷에서는 천천히 뒤돌아본다.
다음 샷에서는 달리기 시작한다.

SWORD_01:
Immutable traits:
검은 손잡이, 은색 칼날, 푸른 금속 반사.
길이는 주인공 팔보다 약간 길다.
항상 오른쪽 허리 쪽에 찬다.

CITY_01:
Immutable traits:
사막화된 도시, 녹슨 금속 구조물, 바랜 노란 간판, 먼지바람.
색감은 황토색과 청회색 중심.

Do not change:
캐릭터 얼굴, 코트 실루엣, 검의 크기, 도시 팔레트.

20개 스킬을 실제 작업에서 조합하는 법

이 20개 스킬은 하나씩 써도 좋지만, 실제 제작에서는 여러 개를 조합할 때 훨씬 강력하다.

1. 캐릭터가 반복 등장하는 AI 영상

추천 조합:

world-asset-identity-lock
long-form-continuity-bible
modular-film-prompt-bible
storyboard-shot-design

사용 예시:

반복 등장하는 캐릭터가 있는 5개 샷짜리 AI 영상 프롬프트를 만들어줘.

먼저 world asset identity lock으로
캐릭터, 의상, 소품, 장소를 고정해줘.

그다음 long-form continuity bible로
얼굴, 실루엣, 손상 상태, 조명, 팔레트, 이동 방향을 정리해줘.

마지막으로 storyboard-shot-design 방식으로
각 샷의 objective, framing, camera, action, emotion, continuity link를 작성해줘.

2. 15초 액션 영상

추천 조합:

action-choreography-camera-logic
cinematic-hit-marking-action-director
continuity-editing-axis-match
lighting-continuity-design

사용 예시:

15초 액션 영상을 설계해줘.

조건:
- 좌우 이동 방향과 공격 방향 유지
- 15초를 5개 time slice로 분리
- 충돌 순간은 0.1초 단위 hit mark로 지정
- 각 hit mark에는 impact frame, screen shake, particle ejection 포함
- 카메라 움직임은 각 구간마다 하나의 목적만 갖게 한다
- 조명 방향과 contrast ratio는 컷 사이에서 유지

3. 숏폼 드라마

추천 조합:

short-drama-hook-engineering
cinematic-story-architecture
dialogue-performance-blocking
shot-size-and-angle-language

사용 예시:

30초 숏폼 드라마를 만들어줘.

첫 1-3초 안에 강한 갈등으로 시작해줘.
전체 구조는 hook, escalation, exit bridge로 구성해줘.

각 beat마다:
- action
- emotional turn
- visual revelation
- camera intention

각 대사마다:
- objective
- subtext
- emotional vector
- body behavior
- facial behavior

샷 크기는 감정 변화에 맞춰 ECU, CU, MCU, WS를 선택해줘.

4. 이미지 레퍼런스 기반 영상

추천 조합:

reference-driven-video-prompting
sd2-pe
world-asset-identity-lock
director-visual-language

사용 예시:

@image 1을 캐릭터 identity reference로 사용하고,
@image 2를 location reference로 사용해줘.

이미지 자체를 다시 설명하지 말고
움직임, 카메라, 조명 변화, 마지막 프레임 상태만 작성해줘.

Seedance 2.0용으로:
- reference binding
- global asset lock
- 15-second time-sliced storyboard
- per-slice action / camera / performance / sound
- continuity instruction
- quality constraints

순서로 정리해줘.

가장 범용적인 기본 템플릿

처음부터 복잡하게 모든 스킬을 쓸 필요는 없다.
가장 실용적인 기본 조합은 다음 세 가지다.

modular-film-prompt-bible
world-asset-identity-lock
storyboard-shot-design

이 조합은 먼저 세계관과 정체성을 고정하고, 그다음 샷별 실행 지시로 내려가기 때문에 이미지·영상 생성 결과가 덜 흔들린다.

복사해서 쓰는 기본 템플릿

아래 아이디어를 AI 영상 제작용 film prompt bible로 정리해줘.

1. Core premise
이 영상의 핵심 상황과 감정 목적을 한 문장으로 정리해줘.

2. World asset identity lock
반복 등장하는 캐릭터, 소품, 장소에 stable ID를 부여해줘.
각 asset마다 immutable traits와 variable behavior를 분리해줘.

3. World and genre lock
장소, 시대, 장르, 팔레트, 재질, 날씨, 조명 논리를 고정해줘.

4. Medium and realism lock
실사풍, 영화적 CG, 35mm 장르 영화, 광고 룩 등 하나의 매체 논리를 선택해줘.
피해야 할 렌더링 오류도 적어줘.

5. Sound policy
BGM 사용 여부, 현장음, Foley, 대사, 주변음을 정리해줘.

6. Storyboard shot design
각 샷마다 다음 항목을 작성해줘:
- shot number
- duration intent
- objective
- subject focus
- framing
- camera position and movement
- action inside frame
- emotional purpose
- sound
- continuity link
- transition pressure into next shot

7. Continuity carryover
다음 샷에서도 반드시 유지되어야 할 얼굴, 의상, 소품, 손상 상태, 조명, 팔레트, 이동 방향을 정리해줘.

마무리

AI 영상 프롬프트에서 가장 흔한 실패는 “멋있지만 일관성 없는 결과”다.
캐릭터 얼굴이 바뀌고, 카메라 동선이 모순되고, 조명이 컷마다 달라지고, 액션 방향이 뒤집히고, 장면의 감정 목적이 흐려진다.

NolanX AI의 20개 스킬은 이런 문제를 해결하기 위한 제작 언어를 제공한다.
핵심은 간단하다.

프롬프트를 감성어로만 쓰지 말고,
정체성, 세계관, 카메라, 조명, 동선, 편집, 사운드, 감정 beat로 나눠서 쓰는 것.

AI가 좋은 영상을 만들게 하려면,
먼저 사람이 좋은 연출 구조를 줘야 한다.

출처

nolanx.ai/skills at main · nolanx-ai/nolanx.ai

Nolanx, Open-sourced AI Netflix. Contribute to nolanx-ai/nolanx.ai development by creating an account on GitHub.

github.com

GPT 이미지 프롬프트를 어떻게 하면 잘 만들수 있을까?

행복한 수지아빠 — Mon, 18 May 2026 15:26:58 +0900

GPT 이미지 프롬프트 개선기를 만들며 정리한 것들

요즘은 누구나 AI로 이미지를 만들 수 있습니다.
하지만 막상 원하는 이미지를 만들려고 하면 생각보다 결과가 잘 나오지 않습니다.

“예쁘게 만들어줘.”
“고급스럽게 만들어줘.”
“감성적인 썸네일 만들어줘.”

이렇게 입력했는데 결과물이 어딘가 어색하거나, 내가 생각한 방향과 전혀 다르게 나오는 경우가 많습니다.

이유는 간단합니다.
AI에게는 “예쁘게”라는 말보다 무엇을 어떻게 보여줄지가 훨씬 중요하기 때문입니다.

이미지 생성 프롬프트는 주문서라기보다 디자인 디렉션에 가깝습니다.
그래서 좋은 이미지를 만들기 위해서는 막연한 감상어보다 구체적인 시각 정보를 알려줘야 합니다.

좋은 프롬프트는 “예쁘게”가 아니라 “어떻게”를 말한다

많은 사람이 처음에는 이렇게 요청합니다.

예쁜 화장품 이미지 만들어줘.

물론 이 말도 틀린 것은 아닙니다.
하지만 AI 입장에서는 너무 모호합니다.

예쁜 게 어떤 느낌인지 알 수 없습니다.
밝고 귀여운 이미지인지, 고급스러운 백화점 광고 느낌인지, 미니멀한 브랜드 사진인지, 감성적인 인스타그램 피드 이미지인지 방향이 불분명합니다.

조금 더 좋은 프롬프트는 이런 식입니다.

무광 아이보리 세럼 병을 베이지 스톤 받침대 위에 올려줘.
부드러운 자연광이 왼쪽 위에서 들어오고,
크림 톤 배경에 상단에는 제목을 넣을 수 있는 여백을 남겨줘.
텍스트는 넣지 말고, 워터마크와 로고도 없게 해줘.

이렇게 쓰면 이미지의 방향이 훨씬 분명해집니다.

핵심은 감성적인 말보다 눈에 보이는 단어를 쓰는 것입니다.

이미지 프롬프트는 이 순서로 쓰면 쉽다

프롬프트를 잘 쓰고 싶다면 매번 처음부터 고민할 필요가 없습니다.
아래 구조를 템플릿처럼 사용하면 됩니다.

Purpose:
이미지를 어디에 쓸 것인가?

Scene:
어떤 배경과 상황인가?

Main subject:
무엇이 중심 피사체인가?

Style:
어떤 스타일과 무드인가?

Composition:
어떤 구도, 비율, 여백인가?

Lighting:
어떤 조명과 분위기인가?

Text:
이미지 안에 글자를 넣을 것인가?

Constraints:
피해야 할 것과 반드시 유지할 것은 무엇인가?

이 구조만 기억해도 프롬프트 품질이 훨씬 좋아집니다.

예를 들어 “릴스 썸네일”이라면 목적은 인스타그램 릴스 커버입니다.
그러면 세로 비율이 필요하고, 제목을 넣을 여백도 필요합니다.

“유튜브 썸네일”이라면 가로 16:9 비율이 적합합니다.
주제가 한눈에 보여야 하고, 제목을 넣을 공간이 필요합니다.

“랜딩페이지 히어로 이미지”라면 웹사이트 첫 화면에 들어갈 이미지이므로, 왼쪽이나 오른쪽에 카피와 버튼이 들어갈 여백이 중요합니다.

이처럼 사용 목적이 정해지면 구도도 자연스럽게 정해집니다.

추상적인 말은 구체적인 시각 요소로 바꿔야 한다

AI 이미지 생성에서 자주 쓰지만 결과가 흔들리는 말들이 있습니다.

예쁜
고급스러운
감성적인
깔끔한
세련된
멋진
힙한

이런 단어들은 사람이 보기에는 익숙하지만, AI에게는 해석의 폭이 너무 넓습니다.

그래서 아래처럼 바꾸는 것이 좋습니다.

무광 아이보리 질감
베이지 스톤 받침대
부드러운 확산광
크림 톤 배경
넓은 여백
미니멀 럭셔리 브랜딩
얕은 심도
따뜻한 림 라이트
정면 중앙 구도
세로 4:5 비율

즉, “고급스럽게”라고 쓰기보다
“무광 질감, 베이지 톤, 부드러운 그림자, 여백이 많은 미니멀 제품 사진”이라고 쓰는 편이 훨씬 안정적입니다.

구도는 반드시 써야 한다

프롬프트에서 많이 빠지는 부분이 바로 구도입니다.
하지만 구도는 이미지의 완성도를 크게 좌우합니다.

예를 들어 이런 표현을 사용할 수 있습니다.

subject centered
negative space on the left
top-down view
vertical 4:5
close-up
wide shot
low angle
eye-level view

한국어로 풀면 이런 뜻입니다.

피사체를 중앙에 배치
왼쪽에 넓은 여백
위에서 내려다본 시점
세로 4:5 비율
클로즈업
와이드샷
로우앵글
눈높이 시점

특히 썸네일이나 광고 이미지는 여백이 중요합니다.
나중에 제목이나 설명 문구를 넣어야 하기 때문입니다.

그래서 릴스 썸네일을 만들 때는 이런 지시가 좋습니다.

Vertical 4:5 ratio, generous negative space at the top center for a headline.

뜻은 간단합니다.

“세로 4:5 비율로 만들고, 상단 중앙에는 제목을 넣을 수 있는 넓은 여백을 남겨줘.”

이 한 문장만 넣어도 썸네일로 쓰기 훨씬 좋아집니다.

텍스트는 넣을지 말지 명확히 정해야 한다

이미지 생성 모델은 글자 표현에서 실수할 때가 많습니다.
그래서 이미지 안에 정확한 문구가 꼭 필요한 경우가 아니라면, 처음에는 텍스트 없이 만드는 것이 안전합니다.

Text:
No text.

이렇게 명확히 쓰면 됩니다.

만약 글자를 넣어야 한다면 짧게 쓰는 것이 좋습니다.

Text:
Add the exact Korean title “오늘의 나를 입어” at the top center in bold clean sans-serif typography.

그리고 제약에도 한 번 더 적어줍니다.

Constraints:
No misspelled text, no extra letters, no watermark, no logo.

하지만 실제 작업에서는 이미지를 먼저 만들고, 글자는 캔바, 포토샵, 피그마, 캡컷 등에서 따로 넣는 방식이 더 안정적입니다.

수정할 때는 “바꿀 것”보다 “유지할 것”이 중요하다

이미지를 수정할 때 많은 사람이 이렇게 말합니다.

배경을 바꿔줘.

하지만 이렇게만 쓰면 인물의 얼굴, 옷, 포즈, 조명까지 함께 바뀔 수 있습니다.

수정 프롬프트에서는 반드시 유지할 것을 적어야 합니다.

Change only:
Replace the background with a warm beige studio setting.

Keep the same:
Keep the person’s face, expression, pose, outfit, camera angle, lighting direction, and body proportions exactly the same.

New direction:
Make the background clean, minimal, premium, and softly lit.

Constraints:
No face changes, no pose changes, no outfit changes, no extra people, no watermark, no logo.

한국어로 쓰면 이렇게 됩니다.

배경만 따뜻한 베이지 스튜디오로 변경해줘.

인물의 얼굴, 표정, 포즈, 옷, 카메라 각도, 조명 방향, 신체 비율은 그대로 유지해줘.

배경은 깨끗하고 미니멀하며 부드럽게 조명된 프리미엄 분위기로 만들어줘.

얼굴 변경 없음, 포즈 변경 없음, 의상 변경 없음, 추가 인물 없음, 워터마크 없음, 로고 없음.

수정 프롬프트의 핵심 공식은 간단합니다.

Change only X.
Keep everything else the same.

즉, “무엇을 바꿀지”보다 “무엇을 바꾸면 안 되는지”가 더 중요합니다.

좋은 이미지는 한 번에 완성되지 않는다

AI 이미지 작업을 할 때 처음부터 완벽한 결과를 기대하면 오히려 답답해집니다.
복잡한 이미지는 단계적으로 만드는 편이 더 안정적입니다.

추천하는 순서는 이렇습니다.

1. 기본 장면 생성
2. 조명 수정
3. 구도 수정
4. 색감 보정
5. 불필요한 요소 제거
6. 최종 제약 정리

처음부터 모든 것을 해결하려고 하지 말고, 먼저 좋은 기본 장면을 만든 뒤 하나씩 다듬는 방식이 좋습니다.

예를 들어 처음에는 이렇게 요청합니다.

먼저 기본 장면을 만들어줘.

그다음 조명을 수정합니다.

조명을 더 부드러운 베이지 톤으로 바꿔줘.
구도와 인물 포즈는 그대로 유지해줘.

이런 식으로 작업하면 결과가 훨씬 안정적입니다.

그래서 GPT 프롬프트 개선기가 필요하다

이 과정을 매번 사람이 직접 하기는 번거롭습니다.
그래서 “GPT 이미지 프롬프트 개선기”를 만들 수 있습니다.

이 GPT의 역할은 단순합니다.

사용자가 대충 말한 요청을 받아서,

화장품 이미지 예쁘게 만들어줘.

이렇게 구조화된 프롬프트로 바꿔주는 것입니다.

Purpose:
Premium skincare product promotional image for social media.

Scene:
A clean beige studio setup with a matte stone pedestal and a soft cream background.

Main subject:
A matte ivory serum bottle placed upright on the pedestal, with subtle clean reflections.

Style:
Photorealistic product photography, minimal luxury skincare branding, soft neutral color palette, premium editorial mood.

Composition:
Vertical 4:5 ratio, product centered in the lower half, generous negative space at the top for a headline, shallow depth of field.

Lighting:
Soft diffused daylight from the upper left, gentle shadows, warm beige tone, subtle highlight on the bottle edge.

Text:
No text.

Constraints:
No watermark, no logo, no distorted bottle, no duplicate products, no messy background, no random text.

사용자는 이미지를 잘 만들기 위해 모든 원칙을 외울 필요가 없습니다.
프롬프트 개선기가 대신 목적, 장면, 스타일, 구도, 조명, 제약을 정리해주면 됩니다.

GPT 이미지 프롬프트 개선기의 기본 역할

이 GPT는 다음과 같은 일을 해야 합니다.

막연한 요청을 구체적인 시각 디렉션으로 바꾼다.
용도에 맞는 이미지 비율을 추천한다.
구도와 여백을 자동으로 보강한다.
조명과 색감을 구체화한다.
텍스트 여부를 명확히 정리한다.
워터마크, 로고, 왜곡 같은 문제를 막는 제약을 추가한다.
수정 요청에서는 유지할 요소를 명확히 적는다.

중요한 것은 프롬프트를 무조건 길게 만드는 것이 아닙니다.
길지만 방향이 없는 프롬프트보다, 짧아도 명확한 프롬프트가 더 좋습니다.

좋은 프롬프트 개선기는 사용자의 말을 “화려하게 꾸미는 도구”가 아니라,
이미지 생성 모델이 이해하기 쉬운 디자인 작업 지시서로 바꿔주는 도구입니다.

바로 쓸 수 있는 기본 템플릿

이미지 프롬프트 개선기를 만들 때는 아래 구조를 기본 출력값으로 설정하면 좋습니다.

[프롬프트 진단]
- 사용 목적:
- 핵심 피사체:
- 추천 비율:
- 추천 스타일:
- 구도 방향:
- 보완한 요소:

[개선된 최종 프롬프트]
Purpose:
Scene:
Main subject:
Style:
Composition:
Lighting:
Text:
Constraints:

이렇게 하면 사용자는 왜 이렇게 바뀌었는지 이해할 수 있고, 바로 복사해서 이미지 생성에 사용할 수도 있습니다.

용도별 기본값도 필요하다

프롬프트 개선기가 더 똑똑하게 동작하려면 용도별 기본값을 가지고 있어야 합니다.

예를 들어 릴스 썸네일이면,

세로 4:5 비율
상단 중앙에 제목용 여백
강한 중심 피사체
텍스트 없음
깔끔한 배경

유튜브 썸네일이면,

가로 16:9 비율
큰 중심 피사체
강한 대비
제목을 넣을 여백
작은 디테일보다 한눈에 보이는 구성

랜딩페이지 히어로 이미지라면,

가로 16:9 또는 21:9 비율
한쪽에 핵심 오브젝트
다른 한쪽에 헤드라인과 버튼용 여백
브랜드 무드가 느껴지는 배경
복잡하지 않은 구성

캐릭터 시트라면,

하얀 배경
정면, 측면, 후면
전신
일관된 의상과 헤어스타일
불필요한 배경 없음

이런 기본값을 넣어두면 사용자가 자세히 말하지 않아도 어느 정도 완성도 있는 프롬프트를 만들 수 있습니다.

최종 결론

이미지 생성에서 중요한 것은 프롬프트의 길이가 아닙니다.
중요한 것은 방향이 분명한가입니다.

좋은 이미지 프롬프트는 다음 질문에 답해야 합니다.

어디에 쓸 이미지인가?
무엇을 보여줄 것인가?
어떤 스타일인가?
어떤 구도인가?
어떤 조명인가?
텍스트는 필요한가?
무엇을 피해야 하는가?
무엇을 유지해야 하는가?

결국 GPT 이미지 프롬프트 개선기의 목표는 하나입니다.

사용자의 막연한 아이디어를 이미지 생성 모델이 바로 이해할 수 있는 디자인 디렉션으로 바꿔주는 것.

이것만 잘 설계해도 누구나 더 안정적으로 원하는 이미지를 만들 수 있습니다.

Codex를 UI/UX 마법사처럼 만드는 디자인 루프

행복한 수지아빠 — Wed, 6 May 2026 10:53:09 +0900

Codex를 UI/UX 마법사처럼 만드는 디자인 루프

대부분의 사람들은 Codex를 단순한 커맨드라인 도구처럼 사용합니다. 그래서 결과물도 대개 초안 수준의 UI 디자인에 머무릅니다.

하지만 Codex Desktop 앱은 이 흐름을 바꿉니다. 시각적 피드백 루프를 통합해 앱을 빌드하고 실행하며, 스크린샷을 캡처하고, 비전 기능으로 레이아웃을 검사하고, 사용자 상호작용을 시뮬레이션하며, imagegen으로 에셋을 생성하고, 실제 시각 결과를 바탕으로 코드를 반복 수정합니다.

이 접근 방식은 디자인을 한 번의 프롬프트 결과가 아니라 효율적인 반복 프로세스로 바꿔줍니다.

실수: 왜 첫 초안은 부족한가

기존 AI 코딩 벤치마크는 보통 단일 프롬프트에서 나온 첫 결과물을 평가합니다. 하지만 이것은 오해를 부를 수 있습니다.

AI를 사용해 만든 첫 초안은 대부분 다음과 같은 문제를 보입니다.

📏

일관성 없는 간격

요소 간 여백이 제각각이어 시각적 리듬이 깨집니다.

🎨

불명확한 시각적 위계

어떤 요소가 중요한지, 어디를 봐야 할지 알기 어렵습니다.

📱

모바일 반응형 실패

데스크톱에서만 확인하면 모바일에서 레이아웃이 무너집니다.

🧩

어색한 레이아웃

정렬이 맞지 않거나 요소 배치가 부자연스럽습니다.

하지만 LLM이 실제 UI를 볼 수 있고, 무엇이 좋은지, 무엇이 나쁜지, 무엇이 어색한지를 잘 판단할 수 있다면 상황은 완전히 달라집니다. Codex의 비전(Vision) 기능이 바로 이 지점을 바꿉니다.

Codex Desktop은 빠른 반복 작업이 가능하다는 점에서 특히 강합니다.

핵심 관점: 시각적 제품 빌더로 전환하기

이제 Codex를 단순한 터미널 코드 도구로 보지 말고, 시각적 디자인 루프를 수행하는 도구로 봐야 합니다.

프롬프트 작성

원하는 UI를 구체적으로 설명합니다.

빌드 & 실행

코드를 생성하고 로컬에서 앱을 실행합니다.

스크린샷 & 비전 리뷰

화면을 캡처하고 Vision으로 시각적 문제를 분석합니다.

클릭 테스트 & 수정

사용자 흐름을 시뮬레이션하고 문제를 반복 수정합니다.

이 관점 전환은 세 가지 장점을 제공합니다.

첫째, Codex가 실제로 실행 중인 UI를 직접 관찰합니다. 커맨드라인 방식은 코드 예측에 의존하지만, Desktop 방식은 실제 화면을 보고 판단할 수 있습니다.

둘째, 문제 감지를 자동화할 수 있습니다. 대비 문제, 여백 문제, 텍스트 가독성 문제 등을 빠르게 찾아냅니다.

셋째, 디자인 A/B 테스트가 가능해집니다. 여러 디자인 변형을 만들고, 가독성·시각적 위계·사용자 흐름 같은 기준으로 더 나은 안을 선택할 수 있습니다.

CLI Codex vs Desktop Codex

CLI는 코드를 편집할 수 있고, Desktop은 화면을 보고 상호작용할 수 있습니다. 각각의 강점이 다릅니다.

CLI Codex	Desktop Codex
코드 리팩터링	실제 화면 상태 캡처
유닛 테스트 작성	모바일 레이아웃 깨짐 감지
백엔드 수정	수정 전/후 스크린샷 비교
스크립트 자동화	사용자 클릭 흐름 테스트
단순 코드 변경	필요한 시각 에셋 생성

코드 정확도가 중요한 선형 작업에는 CLI만으로도 충분합니다. 반면 미적 완성도가 중요한 프로젝트에서는 Codex Desktop의 반복 루프가 훨씬 유리합니다.

특히 새로운 이미지 생성 엔진 Image 2를 사용해 필요한 비주얼을 즉석에서 만들 수 있다는 점은 디자인 프로토타이핑 흐름을 크게 바꿉니다.

Imagegen vs Vision: 서로 다른 역할

두 기능은 비슷해 보이지만 역할이 확연히 다릅니다. Imagegen은 소스 에셋을 만들고, Vision은 실제 UI를 판단합니다.

🖼

Imagegen이 만드는 것

게임 캐릭터 초상화, 제품 아이콘, 배경 이미지, 일러스트, 브랜드용 시각 요소

👁

Vision이 검사하는 것

시각적 위계, 간격, 대비, 텍스트 잘림, 모바일 깨짐, 클릭 요소 명확성

효과적인 워크플로우는 두 기능을 하나의 사이클로 묶는 것입니다.

Imagegen으로 에셋 생성

필요한 캐릭터, 아이콘, 배경을 생성합니다.

UI에 통합 & 스크린샷

에셋을 코드에 반영하고 화면을 캡처합니다.

Vision으로 검토 & 수정

시각적 문제를 찾아내고 코드를 수정한 뒤 다시 확인합니다.

이 조합을 사용하면 디자인이 단순히 멋있어 보이는 수준을 넘어 실제로 사용 가능한 UI에 가까워집니다.

모든 것을 바꾸는 프롬프트

"더 예쁘게 만들어줘" 같은 모호한 프롬프트는 일관된 결과를 내기 어렵습니다. 대신 구체적으로 지시하는 것이 좋습니다.

prompt

1Codex Desktop을 시각적 디자인 루프로 사용하세요.
2
3앱을 로컬에서 실행하고, 데스크톱과 모바일 화면의 스크린샷을 검사하고,
4상호작용을 클릭해 테스트한 뒤, 완성도 높은 결과가 나오도록 수정하세요.
5
6시각적 위계, 간격, 대비, 텍스트 맞춤, 반응형 레이아웃,
7hover 상태에 집중하세요.
8
9Imagegen과 Vision을 함께 사용하고,
10필요하면 A/B 테스트를 진행하세요.
11반응형 관점에서 Vision으로 직접 확인해 만족스러운 수준이 될 때까지 반복하세요.
12
13화면을 제품 디자이너이자 QA 전문가처럼 검사하세요.
14시각적 문제를 영향도 기준으로 파악하고, 모든 문제를 검증한 뒤 수정하세요.

✓

포인트는 "예쁘게"가 아니라 검사 기준을 명시하는 것입니다. 위계, 간격, 대비, 반응형 — 구체적인 체크리스트를 주면 결과가 달라집니다.

워크플로우 1: 게임 UI 디자인

게임 UI는 HUD, 인벤토리, 모바일 대응 등 복잡한 요소가 많습니다. 비전 루프를 적용하면 초기에 많은 시각적 버그를 잡을 수 있습니다.

게임 UI 디자인 프롬프트

Prompt

게임 화면을 실행하고 Vision으로 검사하세요. 플레이어 관점에서 HUD 가독성, 아이콘 명확성, 모바일 동작을 평가하세요. 캐릭터 초상화나 배경 같은 에셋은 imagegen을 사용하세요. Vision으로 다시 확인하고, 프로덕션에 가까운 시각 완성도가 될 때까지 반복하세요.

게임 화면을 로컬에서 실행
Vision으로 HUD 가독성과 아이콘 명확성 평가
imagegen으로 캐릭터 초상화, 배경 에셋 생성
Vision으로 재검토 및 반복 수정

플레이어가 클릭 가능한 요소를 빠르게 인식하고 스탯을 쉽게 읽도록 개선

워크플로우 2: 제품 UI 만들기

SaaS 대시보드나 관리자 패널에서는 사용성이 가장 중요합니다. 비전문가도 쉽게 이해할 수 있는 인터페이스가 목표입니다.

제품 UI 프롬프트

Prompt

2026년 디자인 원칙을 바탕으로 기능적인 UI를 만드세요. 최고 수준의 사용자 경험, 가독성, 사용성을 목표로 하세요. 레퍼런스와 베스트 프랙티스를 조사한 뒤 imagegen으로 필요한 UI 비주얼을 만들고, 로컬에서 실행한 후 Vision으로 데스크톱과 모바일 화면의 위계, 간격, 내비게이션을 검사하세요.

2026년 디자인 원칙 기반 UI 설계
레퍼런스 조사 및 imagegen으로 비주얼 생성
로컬 실행 후 Vision으로 데스크톱/모바일 검사
비전문가 사용자 관점에서 흐름 검증

모든 사용자가 스트레스 없이 탐색할 수 있는 인터페이스 완성

워크플로우 3: 커밋 전 A/B 테스트

주관적인 디자인 선택을 피하려면 여러 변형을 만들어 비교하는 것이 좋습니다. AI가 하나의 결과물만 고집하지 않게 만듭니다.

A/B 테스트 프롬프트

Prompt

세 가지 시각적 변형을 생성하세요. 각 변형을 데스크톱과 모바일에서 스크린샷으로 확인하세요. 가독성, 시각적 위계, 사용자 흐름을 기준으로 비교하세요. 가장 좋은 안을 선택해 적용하세요.

세 가지 시각적 변형 생성
데스크톱/모바일 스크린샷 캡처
가독성, 위계, 사용자 흐름 기준 비교
최적안 선택 및 적용

여러 대안을 비교해 프로젝트 목표에 맞는 디자인 선택

워크플로우 4: 아트 바이블 추출하기

성공적인 페이지 디자인이 나오면, 그 결과를 재사용 가능한 디자인 언어로 정리할 수 있습니다. 한 번 만든 스타일을 앱 전체에 일관되게 확장하는 것이 핵심입니다.

prompt

1앱 스크린샷을 바탕으로 아트 바이블을 작성하세요.
2
3팔레트, 타이포그래피, 레이아웃 규칙을 정리하고,
4앞으로 다른 화면에도 일관되게 적용할 수 있는
5디자인 시스템 규칙으로 만들어주세요.

마스터 프롬프트

아래 프롬프트는 시각적 작업에 거의 그대로 활용할 수 있는 종합 프롬프트입니다. 목표 부분만 프로젝트에 맞게 수정하세요.

master prompt

1Codex Desktop을 시각적 빌더로 사용하세요.
2
3목표:
4[프로젝트를 설명하세요]
5
6Imagegen과 Vision을 한 쌍의 워크플로우로 사용하세요.
7
81. 최소 기능 버전을 만드세요.
92. 로컬에서 실행하세요.
103. 스크린샷을 찍으세요.
114. Vision으로 검사하세요.
125. 사용자 흐름을 클릭해 테스트하세요.
136. 문제를 수정하세요.
147. 다시 스크린샷을 찍으세요.
158. A/B 테스트 변형을 만드세요.
169. 필요한 에셋은 imagegen으로 생성하세요.
1710. 변경 사항을 요약하고 디자인 규칙을 추출하세요.
18
19검사 기준:
20- 시각적 위계
21- 간격
22- 대비
23- 텍스트 가독성
24- 반응형 레이아웃
25- hover 상태
26- 모바일 사용성
27- 클릭 가능한 요소의 명확성
28- 사용자 흐름의 자연스러움
29
30화면을 제품 디자이너이자 QA 전문가처럼 검토하세요.
31실제 화면을 보고 문제를 찾고, 수정 후 다시 확인하세요.
32만족스러운 수준에 도달할 때까지 반복하세요.

요약: 반복이 완성을 만든다

Codex Desktop은 단순히 코드를 작성하는 도구가 아니라, 전체 시각적 디자인 루프에 참여하는 도구로 사용할 수 있습니다. 핵심을 정리하면 다음과 같습니다.

Vision은 UI를 검토하는 데 사용한다
Imagegen은 필요한 시각 에셋을 만드는 데 사용한다
A/B 테스트로 더 나은 디자인을 선택한다
성공한 디자인은 아트 바이블로 정리한다
CLI는 코드 중심 작업에, Desktop은 디자인 중심 작업에 사용한다

좋은 UI는 한 번의 프롬프트로 완성되는 것이 아니라, 보고 고치고 다시 확인하는 반복 과정에서 완성됩니다. Codex Desktop의 강점은 바로 그 반복 과정을 AI가 직접 수행할 수 있게 만든다는 점입니다.

Open Design → Flutter 앱으로 디자인 워크플로우 가이드

행복한 수지아빠 — Mon, 4 May 2026 10:56:46 +0900

https://github.com/nexu-io/open-design

이 문서는 **Open Design(OD)**에서 선택한 **디자인 시스템(DESIGN.md)**과 시각 시안을 기준으로, Flutter로 TODO 앱을 만들 때의 실무 워크플로우를 예시로 정리합니다.

1. 이 가이드가 가정하는 것

항목가정

OD	저장소 루트에서 npm install 후 npm run dev:all로 데몬·웹 UI 기동
에이전트	Claude Code / Cursor Agent 등 로컬 CLI(또는 Anthropic API BYOK)
Flutter	안정 채널, Dart 3.x, Material 3(useMaterial3: true) 기본
제품	iOS/Android(또는 단일 플랫폼) TODO: 추가·완료 토글·삭제·필터, 1차 저장은 메모리 → shared_preferences

중요: OD가 내보내는 산출물은 보통 **HTML <artifact>**입니다. Flutter에는 그대로 붙일 수 없으므로, 연동의 축은 다음 두 가지로 나눕니다.

DESIGN.md — 색·타이포·간격·무드의 단일 출처(진실 공급원).
시안 HTML + 스크린샷 — 레이아웃·위계·컴포넌트 배치의 시각 레퍼런스.

Flutter 쪽에서는 이 둘을 ThemeData / ColorScheme / TextTheme / 앱 전용 간격 상수로 옮겨 구현합니다.

2. 전체 흐름 한눈에

[OD] 디자인 시스템 선택 + 스킬 + 브리프 → 질문폼·5방향 → HTML 시안·저장
        ↓
[복사] DESIGN.md → Flutter 레포 docs/ (또는 lib/theme/design_spec.md)
     시안 HTML·스크린샷 → reference/ (참고만, 에셋 번들에 넣지 않아도 됨)
        ↓
[Flutter] flutter create → AppTheme 반영 → 화면 위젯·상태·로컬 저장
        ↓
[반복] 같은 DESIGN.md로 OD에서 UI만 재시안 → Theme/위젯 국소 수정

3. Phase A — Open Design에서 TODO 레퍼런스 UI 만들기

3.1 기동

cd /path/to/open-design
npm install
npm run dev:all

브라우저: http://localhost:5173

3.2 스킬·디자인 시스템 선택

설정예시 선택이유

Skill	mobile-app	OD에 포함된 모바일 프레임·터치 UI에 가까운 스타터(없으면 web-prototype로도 가능)
Design system	제품에 맞는 항목 또는 커스텀 DESIGN.md	Flutter ThemeData로 같은 팔레트·타이포를 맞출 기준

3.3 첫 브리프 예시(Flutter 이관을 염두에 둔 프롬프트)

OD는 여전히 HTML을 출력합니다. 다만 토큰은 DESIGN.md에 맞추고, Flutter에서 옮기기 쉽게 명시적 색·폰트·간격을 HTML에 박아 달라고 요청하면 이후 매핑이 쉽습니다.

Flutter로 구현할 단일 화면 TODO 앱의 참고용 UI를 HTML 한 파일로 만들어 줘.
(나중에 Material 3 ThemeData로 옮길 예정이니 색은 hex, 폰트는 웹폰트로 명시해 줘.)

기능(클라이언트 UI만):
- 상단: Large title 느낌의 "Tasks" + 부제 한 줄
- TextField + FAB 또는 주 버튼으로 새 할 일 추가
- 필터: Segmented / Chip 스타일로 전체·진행 중·완료
- 리스트: Checkbox 또는 완료 토글, 제목, 삭제(또는 스와이프 힌트)
- 완료 항목: 취소선, Secondary 색 대비
- 하단 요약: "N items left"

디자인:
- 현재 활성 디자인 시스템(DESIGN.md)의 팔레트·타이포·간격을 :root CSS 변수로 반영
- 터치 타깃 최소 48dp에 해당할 만한 패딩(모바일 기준)
- 스크롤 가능한 리스트 영역 명확히

출력은 반드시 하나의 <artifact> 태그 안에 완전한 HTML 문서로만.

3.4 질문 폼·시각 방향

제품이 iOS 휴먼 인터페이스에 더 가깝다면 폼에서 톤을 명시하고, Flutter는 Cupertino 위젯 혼합도 가능합니다. 이 가이드는 Material 3 기준 설명을 유지합니다.
5가지 시각 방향 선택 시, Flutter 레포 README에 방향 이름과 선택 날짜를 적어 두면 테마 되돌리기가 쉽습니다.

3.5 결과물 저장

Save to disk로 .od/artifacts/.../index.html 저장.
스크린샷(프리뷰 캡처)을 함께 보관하면 Flutter 구현 후 픽셀 단위가 아닌 위계·여백 비교에 유리합니다.

4. Phase B — Flutter 프로젝트 생성

OD 저장소와 별도 경로에 앱 레포를 둡니다.

cd ~/projects
flutter create todo_app --org com.example
cd todo_app
flutter run

pubspec.yaml에 이후 단계에서 사용합니다.

dependencies:
  shared_preferences: ^2.2.0

flutter pub get

(상태 관리는 처음엔 StatefulWidget만으로도 충분합니다. 팀에서 Riverpod 등을 쓰면 그에 맞춰 분리하면 됩니다.)

5. Phase C — 디자인 시스템을 Flutter 테마로 연동

5.1 DESIGN.md를 레포에 두기

todo_app/
  docs/
    DESIGN.md        # OD design-systems/<id>/DESIGN.md 를 복사

규칙 예: 색·타이포·라운드·간격은 DESIGN.md를 벗어나지 않는다.

5.2 HTML 시안 → Flutter 매핑 표 (개념)

OD / HTMLFlutter

:root / --color-primary 등	ColorScheme.primary, ColorScheme.surface, …
본문/제목 폰트 패밀리·크기	TextTheme의 titleLarge, bodyMedium 등
8px 그리드·섹션 간격	EdgeInsets, SizedBox(height: …), 또는 AppSpacing 클래스 상수
모서리 반경	ThemeData.cardTheme.shape, RoundedRectangleBorder(borderRadius: …)

ColorScheme.fromSeed(seedColor: Color(0xFF...))로 한 번에 잡고, DESIGN.md의 보조색·서피스가 시드만으로 부족하면 copyWith로 세밀 조정합니다.

5.3 테마 파일 예시(새 파일)

lib/theme/app_theme.dart를 두고 MaterialApp의 theme에 연결합니다.

import 'package:flutter/material.dart';

class AppTheme {
  AppTheme._();

  /// DESIGN.md의 primary 색을 시드로 (hex는 문서에서 복사)
  static ThemeData light(Color seed) {
    final scheme = ColorScheme.fromSeed(
      seedColor: seed,
      brightness: Brightness.light,
    );
    return ThemeData(
      useMaterial3: true,
      colorScheme: scheme,
      textTheme: _textTheme(scheme),
      visualDensity: VisualDensity.adaptivePlatformDensity,
    );
  }

  static TextTheme _textTheme(ColorScheme scheme) {
    const font = 'Noto Sans'; // DESIGN.md에 맞게 변경; pubspec fonts 항목 필요
    return TextTheme(
      titleLarge: TextStyle(
        fontFamily: font,
        fontWeight: FontWeight.w600,
        fontSize: 28,
        color: scheme.onSurface,
      ),
      bodyMedium: TextStyle(
        fontFamily: font,
        fontSize: 16,
        color: scheme.onSurface,
      ),
    );
  }
}

main.dart에서는 예를 들어:

theme: AppTheme.light(const Color(0xFF6750A4)),

실제 시드 색은 DESIGN.md의 Primary를 사용합니다. 커스텀 폰트는 pubspec.yaml의 fonts:에 등록해야 합니다.

6. Phase D — Cursor/에이전트용 Flutter 이관 프롬프트 예시

Flutter 레포 루트에서:

@docs/DESIGN.md 와 reference/todo_od_preview.html (실제 경로로 바꿀 것) 을 참고해서
Material 3 TODO 화면을 구현해 줘.

요구사항:
- lib/theme/app_theme.dart 의 ColorScheme/TextTheme가 DESIGN.md의 팔레트·타이포와 일치하도록 조정
- lib/features/todo/todo_page.dart 에서: 입력, 필터(전체/진행/완료), ListView.builder, 삭제
- 완료 항목은 TextDecoration.lineThrough + Theme의 onSurfaceVariant
- 최소 터치 영역 48 이상
- 상태는 우선 StatefulWidget; Todo 모델은 immutable 클래스로
- 이후 shared_preferences로 직렬화할 수 있도록 Todo 리스트를 List<Todo>로 분리

7. Phase E — 추천 디렉터리 구조(예시)

todo_app/
├── docs/
│   └── DESIGN.md
├── reference/                    # git에 넣어도 되고 로컬만이어도 됨
│   ├── todo_od_artifact.html
│   └── preview.png
├── lib/
│   ├── main.dart
│   ├── theme/
│   │   └── app_theme.dart
│   ├── features/
│   │   └── todo/
│   │       ├── todo_page.dart
│   │       ├── todo_model.dart
│   │       └── todo_storage.dart   # shared_preferences 래퍼
│   └── widgets/
│       └── todo_tile.dart
└── README.md

8. Phase F — 상태와 저장(권장 순서)

Todo 모델 — id, title, completed (필요 시 priority 등).
TodoPage + setState — 필터·CRUD.
todo_storage.dart — List<Todo> ↔ JSON 문자열 ↔ shared_preferences.
로딩 순서 — initState에서 비동기 로드 후 setState.

OD 단계에서는 저장소 없이 UI만 맞추고, Flutter에서 로직을 얹는 패턴이 Next 가이드와 동일합니다.

9. 반복 워크플로우(디자인 시스템 유지)

**OD에서 항상 같은 DESIGN.md**를 선택한다.
라벨·카드 레이아웃만 바꿀 때: OD에 짧은 브리프로 HTML만 재생성 → 스크린샷 비교 → Flutter에서 위젯·테마 일부만 수정.

이렇게 하면 디자인 시스템 문서는 고정하고 화면 실험만 OD에서 하는 흐름이 유지됩니다.

10. 자주 하는 실수와 대응

문제대응

HTML 시안과 Flutter 색이 다름	DESIGN.md의 hex를 기준으로 Color(...)를 다시 맞춤. 시안 HTML은 참고용
폰트가 안 맞음	pubspec.yaml에 폰트 등록 여부 확인. 시스템 폰트만 쓸 경우 DESIGN.md와의 차이를 문서화
OD mobile-app 스킬이 웹 프레임 위에만 있음	시안은 토큰·비율이 중요; 기기 프리뷰는 시뮬레이터에서 최종 검증
테마가 위젯 곳곳에 하드코딩	Theme.of(context).colorScheme, textTheme만 사용하도록 리뷰 규칙화

12. 요약

OD에서 DESIGN.md + 디자인 시스템을 고정하고, TODO 화면 HTML 시안을 만든다.
DESIGN.md를 Flutter 레포에 복사해 계약으로 삼는다.
ThemeData로 토큰을 코드화하고, 시안은 레이아웃·위계 참고용으로 쓴다.
기능·저장은 Flutter에서 표준 구조로 얹고, 변경 시 같은 DS로 OD만 재실행해 차이를 줄인다.

Flutter에는 OD HTML을 그대로 임베드할 수 없으므로, 연동의 핵심은 DESIGN.md → ThemeData/스타일 상수이고, HTML은 레퍼런스입니다.

당신은 하나의 텍스트 파일입니다

행복한 수지아빠 — Sun, 3 May 2026 20:14:21 +0900

당신은 하나의 텍스트 파일입니다

당신이 쓴 모든 글, 당신이 한 모든 말 — 그 모든 것이 결국 하나의 파일로 압축될 수 있다면? 그리고 그 파일이 AI에게 당신의 목소리를 완벽하게 복제할 수 있다면?

이건 SF가 아닙니다. 지금 당장 할 수 있는 일입니다. 이름하여 about-me.md.

당신은 하나의 텍스트 파일입니다. 진짜입니다. 당신이 쓰는 모든 것 — 이메일, 트윗, 블로그 글 — 이 하나의 파일로 요약될 수 있습니다. 그리고 그 파일이 AI를 당신처럼 글 쓰게 만듭니다.

왜 about-me.md인가

대부분의 사람들은 AI에게 “나처럼 써줘”라고 말합니다. 그러면 AI는 그들이 무엇을 의미하는지 모릅니다. “나처럼”이란 무엇일까요? 짧은 문장? 긴 문장? 유머러스한 톤? 진지한 톤? 격식 있는? 격식 없는?

AI는 당신이 구체적으로 알려주지 않으면 당신의 목소리를 찾을 수 없습니다. 그래서 필요한 것이 바로 당신의 글쓰기 DNA를 담은 파일입니다.

about-me.md는 당신의 글쓰기 스타일, 어조, 문장 구조, 선호하는 표현, 피하는 표현까지 모두 담은 개인화 파일입니다.

두 시간이면 충분합니다

이 작업에 걸리는 시간은 단 두 시간. 100개의 질문에 답하고, 그것을 압축하는 과정입니다. 복잡해 보이지만, 실제로는 아주 단순합니다.

Taste Interviewer — 100문 인터뷰

Claude가 당신의 글쓰기 취향을 파악하기 위해 100개의 질문을 던집니다. 신념, 문장 메커니즘, 미적 기호, 목소리, 구조적 선호, 절대 하지 않을 것, 레드플래그 — 7개 카테고리로 당신의 DNA를 추출합니다.

Voice Compiler — 음성 컴파일

인터뷰 결과를 2,000~4,000토큰의 XML 구조 파일로 압축합니다. 이것이 바로 당신의 about-me.md가 됩니다.

어떻게 작동하나요

Step 1: Taste Interviewer 프롬프트

Claude에게 다음 프롬프트를 전달하면 인터뷰가 시작됩니다. 7개 카테고리, 100개의 질문이 당신의 글쓰기 자아를 해체합니다.

prompt

1당신은 “Taste Interviewer”입니다.
2목표: 나의 글쓰기 스타일, 어조, 문장 구조,
3  선호하는 표현과 피하는 표현을 파악하세요.
4
5카테고리:
61. 신념 (Beliefs)
72. 문장 메커니즘 (Writing Mechanics)
83. 미적 기호 (Aesthetic Crimes)
94. 목소리와 성격 (Voice & Personality)
105. 구조적 선호 (Structural Preferences)
116. 절대 안 될 것 (Hard Nos)
127. 레드플래그 (Red Flags)
13
14규칙:
15- 한 번에 하나의 질문만 하세요.
16- 내 답변에 깊이 파고들며 추적 질문을 하세요.
17- 100개의 질문을 마친 후, 당신이 파악한
18  나의 글쓰기 DNA를 요약하세요.

Step 2: Voice Compiler 프롬프트

인터뷰가 끝나면, 이번에는 그 결과물을 압축하는 프롬프트를 사용합니다.

prompt

1위 인터뷰 결과를 바탕으로
2  <about-me> XML 구조로 압축하세요.
3
4구조:
5<voice>
6  <tone>...</tone>
7  <structure>...</structure>
8  <vocabulary>...</vocabulary>
9  <avoid>...</avoid>
10  <personality>...</personality>
11</voice>
12
13제약:
14- 2,000~4,000 토큰 이내
15- XML 태그 사용
16- 실용적이고 구체적으로 작성

Step 3: 테스트하고 다듬기

완성된 about-me.md


    !
    Obsidian 같은 에디터로 about-me.md를 열어 수시로 편집하세요. Claude Cowork를 사용하면 매 대화마다 이 파일을 자동으로 컨텍스트에 주입할 수 있습니다.



  파일 구조 예시

  완성된 파일은 대략 이런 구조를 가집니다.

  
about-me.md
├── <voice>     # 최상위 태그
│   ├── <tone>  # 어조: 직관적, 대화형
│   ├── <structure> # 문장 구조 선호
│   ├── <vocabulary> # 자주 쓰는 표현
│   ├── <avoid> # 절대 쓰지 않을 것
│   └── <personality> # 글쓰기 성격
└── </voice>
  

  사람들이 저항하는 네 가지 이유

  이 방법을 소개하면 항상 같은 반응이 돌아옵니다. 네 가지 저항을 미리 정리했습니다.

  
    
      😰
      “내 목소리를 기계에게?”
      AI가 당신을 대체하는 게 아닙니다. AI가 당신의 목소리로 초안을 쓰고, 당신이 다듬는 겁니다. 손글씨를 타자기로 옮기는 것과 같습니다.
    
    
      ⏰
      “두 시간이나?”
      매번 AI에게 “나처럼 써줘”라고 하고 수정하는 데 얼마나 걸리나요? 두 시간의 투자로 앞으로 수백 시간을 아낍니다.
    
    
      😎
      “난 내 스타일을 몰라”
      그게 바로 인터뷰가 필요한 이유입니다. 100개의 질문이 당신도 몰랐던 패턴을 찾아냅니다. 자신의 글쓰기를 발견하는 과정 자체가 가치 있습니다.
    
    
      🚀
      “그냥 프롬프트만 잘 쓰면 되잖아”
      프롬프트는 단발성입니다. about-me.md는 영구적입니다. 한 번 만들면 모든 AI 도구에 재사용할 수 있는 당신만의 디지털 DNA입니다.
    
  

  실제 사용 사례

  
    
      1
      블로그 글 작성
    
    
      
        Before about-me.md
        “AI한테 블로그 글 써달라고 했더니 백과사전 같은 글이 나왔다. 내 목소리가 아니다. 다시 써달라고 했더니 또 다른 사람 글이 나왔다.”
      
      
        After about-me.md
        “시스템 프롬프트에 about-me.md를 넣으니, 첫 번째 초안부터 내 목소리가 느껴졌다. 수정은 미세한 부분뿐이었다.”
      
      초안 작성 시간 80% 단축
    
  

  
    
      2
      이메일 작성
    
    
      
        Before about-me.md
        “매번 '격식 있으면서도 친근하게'라고 적어줘야 했다. 결과는 항상 제각각이었다.”
      
      
        After about-me.md
        “이제 '이 내용으로 이메일 하나 써줘'라고만 하면 된다. 어조, 길이, 포맷 — 전부 내 스타일로 나온다.”
      
      이메일 초안 수정 횟수 90% 감소
    
  

  시작하는 방법

  
    Claude를 열고 Taste Interviewer 프롬프트를 붙여넣으세요
    100개의 질문에 솔직하게 답하세요. 대략 1~1.5시간이 걸립니다
    인터뷰가 끝나면 Voice Compiler 프롬프트를 사용해 결과를 압축하세요
    완성된 파일을 about-me.md로 저장하고, Obsidian 등에서 편집하세요
    Claude Cowork나 시스템 프롬프트에 파일을 넣고 테스트하세요
    어색한 부분이 있으면 파일을 수정하고 다시 테스트하세요. 반복이 핵심입니다
  

  
    
  

  
    당신은 하나의 텍스트 파일입니다. 그 파일을 만드는 데 두 시간이면 충분합니다. 그 두 시간이 앞으로 당신의 모든 글쓰기를 바꿀 것입니다. 시작하세요. 지금 바로.




  Written by Ruben Hassid (@rubenhassid)
  원문 보기 — X (Twitter)



mattpocock/skills — AI 코딩 에이전트를 실무 개발 프로세스에 맞추는 스킬 패키지
행복한 수지아빠 — Sun, 3 May 2026 08:00:36 +0900





mattpocock/skills — AI 코딩 에이전트를 실무 개발 프로세스에 맞추는 스킬 패키지





  AI Coding Agent Skills
  에이전트가 무작정 코드를 짜지
않게 만드는 방법
  mattpocock/skills 분석 — 요구사항 정렬부터 TDD, 아키텍처 개선까지
AI 코딩을 실무 프로세스에 맞춘 12개 스킬
  2026.05.03 · AI Engineering Workflow





이 저장소가 풀려는 문제

AI 코딩 에이전트가 빠르게 코드를 만들면서 아키텍처를 망가뜨리는 일은 이제 흔합니다. 에이전트가 사용자의 의도를 잘못 이해하고, 프로젝트 용어를 못 맞추고, 만든 코드가 동작하지 않는 문제도 반복됩니다.

mattpocock/skills는 이 문제를 슬래시 커맨드 형태의 작업 지시서로 해결합니다. 에이전트가 무작정 코드를 고치지 않고, 정해진 흐름을 따르게 만듭니다.


  요구사항 정렬 → 도메인 언어 정리 → PRD 작성 → 이슈 쪼개기 → TDD 구현 → 버그 진단 → 아키텍처 개선. AI가 이 순서를 스스로 따르게 만드는 것이 이 저장소의 핵심입니다.


설치와 초기화

프로젝트 루트에서 한 줄로 설치합니다.


  
    
    bash
  
  1# 설치
2npx skills@latest add mattpocock/skills
3
4# 설치 UI에서 스킬 선택 후
5# 에이전트 안에서 초기화 실행
6/setup-matt-pocock-skills


/setup-matt-pocock-skills는 이슈 트래커 설정, triage 라벨 매핑, 도메인 문서 위치를 물어봅니다. 이 정보는 다른 모든 스킬이 참조하는 기반이 됩니다.


  i
  초기화가 끝나면 프로젝트에 AGENTS.md 또는 CLAUDE.md, docs/agents/ 문서들이 생성됩니다. 여기에 이슈 트래커 방식, triage 라벨, 도메인 용어가 저장됩니다.


12개 스킬 한눈에 보기


  
     
    /setup-matt-pocock-skills
    초기화. 이슈 트래커, 라벨, 도메인 문서 위치 설정. 모든 스킬 사용 전 먼저 실행.
  
  
     
    /grill-me
    요구사항 압박 면접. 아이디어의 빈틈을 하나씩 질문하며 채움.
  
  
     
    /grill-with-docs
    grill-me + 도메인 문서 연동. 기존 용어와 충돌하는지 검증.
  
  
     
    /to-prd
    대화 맥락을 PRD로 정리. Problem → Solution → User Stories → Testing.
  
  
    ✂️
    /to-issues
    PRD를 vertical slice 이슈로 분해. AFK/HITL 구분.
  
  
     
    /tdd
    한 테스트 → 한 구현 루프 강제. horizontal 테스트 금지.
  



  
     
    /diagnose
    버그 진단. 재현 루프 먼저, 가설은 반증 가능하게, 추측 금지.
  
  
     ️
    /triage
    이슈 분류. bug/enhancement 구분, needs-info/ready-for-agent 상태 변경.
  
  
     ️
    /improve-codebase-architecture
    테스트 가능성과 AI 탐색성을 기준으로 얕은 모듈을 deep module로 개선.
  
  
     ️
    /zoom-out
    특정 코드 영역의 상위 관점 지도. 관련 모듈과 caller를 도메인 용어로 설명.
  
  
     
    /caveman
    초압축 커뮤니케이션 모드. 토큰 절약, 핵심만 출력.
  
  
    ✏️
    /write-a-skill
    새 스킬 작성. SKILL.md + REFERENCE.md + EXAMPLES.md 구조.
  


핵심 스킬 깊이 보기

/grill-me, /grill-with-docs — 요구사항 압박 면접

사용자가 아이디어나 설계를 던지면, 에이전트가 모든 의사결정 분기를 하나씩 질문하면서 빈틈을 채웁니다. /grill-with-docs는 여기에 프로젝트의 CONTEXT.md와 ADR을 읽고 기존 도메인 용어와 충돌하는지 검증까지 합니다.


  
    1
    grill-with-docs 사용 예
  
  
    
      User Input
      AI 뮤직비디오를 기반으로 리듬게임을 만들고 싶어. 현재 도메인 모델과 충돌하는 부분이 있는지 확인하면서 질문해줘.
    
    
      Agent Behavior
      CONTEXT.md의 기존 용어와 비교 → 모호한 단어 지적 → canonical term 제안 → 충돌 시 즉시 알림 → 정리된 용어를 CONTEXT.md에 반영 제안
    
    장기 프로젝트에서 에이전트 용어 불일치 문제 해결
  


/to-prd, /to-issues — 기획을 개발 단위로 분해

/to-prd는 대화 맥락을 종합해 PRD를 만듭니다. 핵심은 사용자를 다시 인터뷰하지 않고 이미 있는 대화를 활용한다는 점입니다.

/to-issues는 PRD를 vertical slice로 쪼갭니다. horizontal slice가 아니라 tracer bullet 방식의 얇고 완성 가능한 end-to-end 단위입니다.


  
    VS
    이슈 쪼개기 — Horizontal vs Vertical
  
  
    
      Bad — Horizontal Slice
      1. DB schema 만들기

      2. API 만들기

      3. UI 만들기

      4. 테스트 만들기
    
    
      Good — Vertical Slice
      1. 사용자가 첫 운동 목표를 생성할 수 있다 (schema + API + UI + test 포함)

      2. 사용자가 오늘의 운동 완료를 기록할 수 있다 (schema + API + UI + test 포함)

      3. 운동 완료 시 코인 보상 내역을 볼 수 있다 (schema + API + UI + test 포함)
    
    각 이슈는 AFK(에이전트 단독) / HITL(사람 확인) 구분
  


/tdd — 테스트 하나, 구현 하나

이 스킬은 "테스트 먼저 전부 작성 → 구현 전부 작성"이 아니라 한 테스트 → 한 구현 → 다음 테스트 방식의 vertical red-green-refactor 루프를 강제합니다.


  테스트는 구현 세부사항이 아니라 public interface의 행동을 검증
  내부 함수명 변경 때문에 깨지는 테스트는 나쁜 테스트
  한 번에 하나의 테스트만 추가
  GREEN 상태 전에는 refactor 금지
  테스트 이름은 프로젝트 도메인 glossary와 맞춤


/diagnose — 추측 금지, 재현 먼저

이 스킬은 "코드 읽고 바로 수정"이 아니라 재현 루프부터 구축하는 보수적 디버깅을 강제합니다.


  
    1
    
      Feedback loop 만들기
      failing test, curl script, CLI fixture, Playwright, git bisect 등
    
  
  
    2
    
      Reproduce
      재현 루프가 없으면 추측하지 않음
    
  
  
    3
    
      3~5개 반증 가능 가설 수립
      hypothesis는 반드시 falsifiable해야 함
    
  
  
    4
    
      Instrument
      debug log에 고유 prefix, 마지막에 제거
    
  
  
    5
    
      Fix + Regression test
      fix 전에 regression test 작성, fix 후 원래 repro loop 재실행
    
  
  
    6
    
      Cleanup + Post-mortem
      debug log 제거, 원인 기록
    
  


/improve-codebase-architecture — Deep Module 찾기

코드베이스에서 테스트 가능성과 AI 탐색성을 기준으로 얕은 모듈을 deep module로 개선할 기회를 찾습니다. 바로 refactor 코드를 작성하지 않고, 먼저 후보 목록을 제시한 뒤 사용자가 고른 후보에 대해 grilling loop로 들어갑니다.


  !
  이 스킬은 CONTEXT.md와 ADR을 읽고, 현재 도메인 언어와 과거 설계 결정을 존중합니다. 새 용어를 만들지 않고 기존 용어 내에서 개선안을 제시합니다.


실무 워크플로우 조합

새 기능 개발


  
    1
    
      /setup-matt-pocock-skills
      프로젝트 이슈 트래커, 라벨, 도메인 문서 설정
    
  
  
    2
    
      /grill-with-docs
      기존 도메인 모델과 충돌 확인하며 요구사항 압박 면접
    
  
  
    3
    
      /to-prd
      대화 맥락을 PRD로 정리
    
  
  
    4
    
      /to-issues
      PRD를 AFK 가능한 vertical slice 이슈들로 분해
    
  
  
    5
    
      /tdd
      각 AFK 이슈를 red-green-refactor 루프로 구현
    
  


버그 수정


  
    1
    
      /triage
      이슈 분류 → bug/enhancement, ready-for-agent 판단
    
  
  
    2
    
      /diagnose
      재현 루프 → 가설 수립 → 검증 → fix + regression test
    
  
  
    3
    
      /improve-codebase-architecture
      테스트 seam 부족 원인 확인, 아키텍처 개선 후보 제안
    
  


가벼운 시작 조합

작은 프로젝트에서 모든 스킬을 쓰는 것은 과합니다. 처음에는 이 네 가지만 시작하세요.


  
    스킬 용도 바로 쓰는 상황
  
  
    /setup 초기화 프로젝트 처음 시작할 때
    /tdd 테스트 루프 기능 구현할 때마다
    /diagnose 버그 진단 버그 리포트 들어올 때
    /zoom-out 코드 이해 모르는 코드 영역 만났을 때
  



  !
  기획과 이슈 관리까지 에이전트에 맡기고 싶을 때만 /grill-with-docs, /to-prd, /to-issues, /triage, /improve-codebase-architecture를 추가하세요.


이 저장소의 핵심 가치

이 저장소는 "AI가 코드를 더 많이 쓰게 하는 도구"가 아닙니다. AI가 덜 위험하게, 더 실무적인 순서로 일하게 만드는 운영 프레임워크입니다.


  
    ★
    세 가지 핵심 가치
  
  
    
      무작정 구현하지 않고 질문과 정렬부터 하게 만든다
      요구사항 → PRD → 이슈 → TDD → 디버깅까지 연결된 파이프라인
      CONTEXT.md와 ADR을 통해 에이전트가 프로젝트의 언어와 설계 결정을 기억하게 만든다
    
  


주의할 점

/to-prd, /to-issues, /triage는 이슈 트래커와 triage label vocabulary를 전제로 동작합니다. /setup-matt-pocock-skills에서 이 설정을 대충하면 잘못된 라벨 생성, 기존 워크플로우 충돌, ready-for-agent 기준 모호화 등의 문제가 생깁니다.

또한 이 저장소는 CONTEXT.md에 "Claude Code가 로드하는 agent skills" 모음이라고 명시되어 있습니다. Codex, Cursor, 다른 에이전트에서도 개념적으로는 활용 가능하지만, 실제 설치와 호출 UX는 각 도구의 skill 지원 방식에 맞게 옮겨야 합니다.

/write-a-skill — 나만의 스킬 만들기

이 스킬을 사용하면 자신만의 커스텀 스킬을 만들 수 있습니다. 스킬 구조는 다음과 같습니다.


skill-name/
├── SKILL.md       # 메인 지시문
├── REFERENCE.md   # 참고 문서
├── EXAMPLES.md    # 사용 예시
└── scripts/
    └── helper.js  # 보조 스크립트


SKILL.md의 description은 에이전트가 어떤 스킬을 로드할지 판단하는 유일한 정보입니다. 1024자 이하, 3인칭, "Use when..." 트리거를 포함해야 합니다.


  
    ★
    커스텀 스킬 아이디어
  
  
    
      Suno 스타일 음악 프롬프트 생성 스킬
      Runway/Seedance 15초 영상 프롬프트 분할 스킬
      Flutter App Store 심사 대응 체크리스트 스킬
      AI 영상 제작 — 캐릭터 일관성, 배경 일관성, lip-sync 규칙 자동 포함 스킬
      유튜브 썸네일/설명/쇼츠 변환 스킬
    
  


추천 첫 사용 순서


  
    
    bash
  
  1# 1. 설치
2npx skills@latest add mattpocock/skills
3
4# 2. 초기화
5/setup-matt-pocock-skills


그리고 실제 작업에서는 목적에 따라 조합하세요.


  
    상황 조합
  
  
    새 기능 /grill-with-docs → /to-prd → /to-issues → /tdd
    버그 수정 /diagnose → /tdd
    구조 개선 /zoom-out → /improve-codebase-architecture
    나만의 자동화 /write-a-skill
  





  mattpocock/skills — AI 코딩 에이전트를 실무 프로세스에 맞추는 스킬 패키지
  github.com/mattpocock/skills







AI로 게임 스프라이트 시트 만들기 — 실전 파이프라인
행복한 수지아빠 — Sat, 2 May 2026 20:33:56 +0900





AI로 게임 스프라이트 시트 만들기 — 실전 파이프라인





  Game Dev Pipeline
  AI로 만드는 2D 스프라이트 시트
실전 파이프라인 가이드
  이미지 모델 + 비디오 모델 + 파이썬 자동화
세 가지를 조합해 게임용 애니메이션을 완성하는 방법
  2026.05.02 · AI Game Art Workflow





왜 이미지 모델만으로는 안 되는가

게임용 스프라이트 시트는 단순히 예쁜 그림이 아닙니다. 프레임이 수학적으로 정확한 격자에 맞아야 하고, 캐릭터가 매 프레임 중앙에 있어야 하며, 배경은 완벽히 투명해야 합니다.

이미지 생성 모델은 이런 규칙을 자주 어깁니다. 특히 걷기나 달리기처럼 다리 움직임이 핵심인 애니메이션에서 오류가 많습니다. 프레임마다 위치가 흔들리고, 배경이 섞이고, 캐릭터 비율이 변합니다.

그래서 이미지 모델 + 비디오 모델 + 로컬 파이썬 스크립트 세 가지를 조합해야 합니다. 각 도구가 잘하는 것만 하게 만드는 것이 이 파이프라인의 핵심입니다.


  이미지 모델로 깨끗한 첫 포즈를 만들고, 비디오 모델로 자연스러운 움직임을 만든 뒤, 파이썬으로 프레임 추출부터 스프라이트 시트 생성까지 자동화한다.


전체 파이프라인 한눈에 보기


  
    1
    
      첫 포즈 생성
      이미지 모델(GPT Image, Nano Banana)로 크로마키 배경의 캐릭터 포즈 생성
    
  
  
    2
    
      움직임 생성
      Kling 같은 비디오 모델로 첫 포즈에서 애니메이션 영상 생성
    
  
  
    3
    
      프레임 추출
      FFmpeg로 비디오의 모든 프레임을 PNG로 추출
    
  
  
    4
    
      프레임 선택
      Contact sheet로 전체 프레임을 확인하고 사용할 프레임 수동 선택
    
  
  
    5
    
      배경 보정 (필요시)
      크로마키가 깨끗하지 않을 때만 응급 보정 스크립트 사용
    
  
  
    6
    
      스프라이트 시트 생성
      배경 제거 → 256x256 변환 → 가로형 스프라이트 시트 출력
    
  
  
    7
    
      결과 검수
      리포트 확인, 잘림/흔들림/워터마크 점검
    
  
  
    8
    
      미리보기 갤러리
      정적 HTML 뷰어로 시트 비교 및 프레임 재생
    
  
  
    9
    
      임시 파일 정리
      중간 파일을 정리 폴더로 이동, 최종 산물만 보관
    
  


Step 1. 이미지 모델로 첫 포즈 만들기

GPT Image, Nano Banana 같은 이미지 모델로 캐릭터의 첫 포즈를 만듭니다. 이 단계에서 배경과 여백을 어떻게 설정하느냐가 전체 파이프라인의 성패를 가릅니다.


  
     
    배경은 #00FF00
    정확한 크로마키 초록색. 캐릭터 디자인에 이 색이 들어가면 안 됩니다.
  
  
     
    넉넉한 여백
    초상화처럼 꽉 차게 만들지 마세요. 비디오 모델이 움직이면서 팔, 무기, 망토가 화면 밖으로 나갈 수 있습니다.
  
  
     
    금지 항목
    그림자, 바닥, 소품, 그라데이션, 텍스트, 워터마크 없이 깨끗하게.
  
  
     
    전환 포즈 전략
    극단적인 포즈보다 기본 자세에서 살짝 움직인 중간 포즈가 시작점으로 좋습니다.
  


Step 2. 비디오 모델로 움직임 만들기

첫 포즈를 Kling 같은 비디오 모델에 넣고 애니메이션 영상을 만듭니다. 여기서 핵심은 프롬프트를 기계적으로 쓰는 것입니다. 감성적 표현은 모델을 혼란스럽게 만듭니다.


  
    VS
    프롬프트 비교 — 검 공격 애니메이션
  
  
    
      Bad — 감성적 프롬프트
      빠른 검 공격
    
    
      Good — 기계적 프롬프트
      업로드한 이미지를 정확한 첫 프레임으로 사용한다.

      캐릭터가 검을 머리 위로 들어 올리고, 잠깐 준비 자세를 취한 뒤, 한 걸음 앞으로 움직이며 아래로 검을 내려친다.

      이후 후속 동작을 거쳐 준비 자세로 돌아온다.

      카메라는 고정되어야 하며, 줌/팬/회전/흔들림이 없어야 한다.

      캐릭터는 화면 중앙에 유지되고, 전체 몸과 검은 프레임 안에 있어야 한다.

      배경은 항상 평평한 #00FF00 초록색이어야 한다.
    
    감성 → 기계적 묘사로 전환
  


비디오 모델 필수 조건


  
    조건 이유
  
  
    업로드 이미지를 첫 프레임으로 사용 캐릭터 일관성 유지
    디자인, 의상, 비율, 무기, 얼굴 유지 캐릭터 변형 방지
    카메라 고정 프레임 정렬 기준 보존
    줌, 팬, 회전, 흔들림, 컷 전환 금지 동일
    캐릭터 화면 중앙 유지 스프라이트 시트 정렬
    크기 변화 금지 셀 크기 일관성
    방향 전환 금지 좌우 반전 방지
    배경 계속 #00FF00 크로마키 제거 가능
    그림자, 바닥, 효과, 모션 블러 금지 깨끗한 알파 채널
  



  i
  단순한 픽셀 RPG 캐릭터라면 오히려 짧고 명확한 프롬프트가 좋습니다. 너무 긴 프롬프트는 모델이 불필요하게 캐릭터를 회전시키거나 재해석하게 만들 수 있습니다.


Step 3. 비디오에서 프레임 추출하기

로컬에서 FFmpeg를 사용해 비디오의 모든 프레임을 PNG로 추출합니다. 이때 캐릭터만 잘라내지 않는 것이 중요합니다.

전체 비디오 캔버스가 정렬 기준이기 때문에, 캐릭터 주변을 프레임마다 다르게 자르면 애니메이션이 흔들립니다. 영상에서의 고정 카메라 위치를 그대로 보존해야 합니다.


  
    
    python
  
  1# tools/extract_frames_ffmpeg.py
2
3# 비디오 → 전체 프레임 PNG 추출
4# frame_0001.png, frame_0002.png, ...
5# 추출 정보 JSON 리포트 생성
6# FPS 샘플링, FFmpeg crop 옵션 지원


Step 4. 사용할 프레임 선택하기

추출된 프레임 중 실제 스프라이트에 넣을 프레임을 고릅니다. 균등 간격으로 고르면 안 되고, 동작의 흐름을 기준으로 선택해야 합니다.

프레임 선택 우선순위


  시작 프레임 — 애니메이션의 첫 장면
  마지막 프레임 — 루프 연결점
  핵심 동작 프레임 — 타격 순간, 점프 정점 등
  보간 프레임 — 핵심 동작 사이의 자연스러운 연결


공격 애니메이션을 예로 들면 준비 자세 → 예비 동작 → 검을 드는 동작 → 타격 순간 → 충격 → 후속 동작 → 회복 자세 순으로 읽기 쉬운 동작 흐름을 골라야 합니다.


  !
  보통 게임에는 12프레임 시트를 사용합니다. 24프레임 시트는 더 부드러운 참고용이나 느린 동작에 사용합니다.


Step 5. 배경 보정 (필요할 때만)

정상적이라면 #00FF00 크로마키 배경을 그대로 제거하면 됩니다. 하지만 배경이 흰색, 회색, 연한 색으로 생성되었거나 초록색이 정확하지 않을 때만 보정 스크립트를 사용합니다.


  
    
    python
  
  1# tools/matte_light_background.py
2
3# 프레임 모서리 색으로 배경색 추정
4# 비슷한 배경색 제거
5# 부드러운 알파 가장자리 생성
6# 리포트 생성



  !
  이 스크립트는 응급용입니다. 가장 좋은 방법은 처음부터 정확한 #00FF00 배경으로 만드는 것입니다. 보정은 품질 손실을 피할 수 없습니다.


Step 6. 초록 배경 제거 후 스프라이트 시트 만들기

파이프라인의 핵심 단계입니다. animation_pipeline.py가 선택된 프레임을 불러와 배경을 제거하고 스프라이트 시트를 생성합니다.


  
    
    python
  
  1# tools/animation_pipeline.py 처리 순서
2
31. 선택된 프레임 불러오기
42. #00FF00 배경 제거
53. 초록색 테두리 번짐 제거
64. 작은 노이즈 제거
75. 각 프레임을 256x256 투명 PNG로 변환
86. 가로형 스프라이트 시트 생성
97. 미리보기 이미지 생성
108. 검증 JSON 리포트 생성


출력 크기


  
    프레임 수 시트 크기
  
  
    12프레임 3072 x 256
    24프레임 6144 x 256
  


preserve-canvas 모드

이 모드는 전체 비디오 캐릭터를 그대로 256x256 셀 안에 축소합니다. 캐릭터만 잘라내거나 매 프레임 중앙 정렬하지 않습니다. 이게 중요한 이유는, 캐릭터를 프레임마다 다시 정렬하면 가짜 카메라 움직임이 생기고 애니메이션이 흔들리기 때문입니다.


  영상에서의 고정 카메라 위치를 그대로 보존해야 한다. 캐릭터를 프레임마다 재정렬하면 흔들린다.


Step 7. 결과 검수하기

완성된 시트를 바로 게임에 넣으면 안 됩니다. 반드시 다음 항목을 검수합니다.


  리포트 상태가 pass인지 확인
  시트 크기가 정확한지 확인
  모든 프레임의 캔버스 크기가 같은지 확인
  모든 프레임의 스케일과 위치가 같은지 확인
  무기, 팔다리, 망토, 머리카락, 이펙트가 잘리지 않았는지 확인
  중복 프레임이 의도된 것인지 확인
  움직임이 튀지 않는지 확인
  워터마크가 제거되었는지 확인
  다른 캐릭터 애니메이션과 크기가 맞는지 확인


최종 파일 구조


final_sprites/
  character/
    animation/
      sheets/
        character_animation_12f_256.png  # 12프레임 스프라이트 시트
        character_animation_24f_256.png  # 24프레임 스프라이트 시트
      frames/
        12f_256/  # 개별 프레임
        24f_256/  # 개별 프레임


Step 8. 로컬 미리보기 갤러리

스프라이트 시트를 쉽게 비교하려면 정적 HTML 뷰어를 만듭니다. build_sprite_gallery_manifest.py가 final_sprites/ 폴더를 스캔해서 매니페스트를 생성합니다.


  
     
    프레임 단위 재생
    선택한 시트를 프레임별로 재생하고 FPS를 조절할 수 있습니다.
  
  
     
    체크무늬 배경
    투명 배경을 확인할 수 있는 체크무늬 배경을 지원합니다.
  
  
     
    캐릭터 필터
    캐릭터와 애니메이션 종류별로 필터링해서 비교할 수 있습니다.
  
  
     
    메타데이터 표시
    파일 경로와 메타데이터를 함께 보여줍니다.
  


Step 9. 임시 파일 정리하기

추출된 고해상도 프레임은 용량이 큽니다. 하지만 코딩 에이전트에게 파일을 바로 삭제하게 하지 말고, 사람이 확인 후 지울 수 있도록 정리 폴더로 옮기게 하는 것이 안전합니다.


cleanup_ready_to_trash/  # 나중에 삭제해도 되는 파일
  character_animation/
    extracted/  # 추출된 전체 프레임
    selected/  # 중간 선택 프레임
    matted/  # 배경 제거 중간 파일
    rejected_source_videos/  # 실패한 영상

processed_source_videos/  # 보관할 파일
  character_animation/
    accepted_source_video.mp4  # 최종 채택 비디오


보관 vs 정리


  
    보관 정리 가능
  
  
    최종 스프라이트 시트 추출된 전체 프레임
    최종 프레임 셀 중간 선택 프레임
    JSON 리포트 실패한 영상
    Contact sheet 재실행 폴더
    최종 채택 원본 비디오 
  


핵심 팁 모음


  
    ★
    실전에서 검증된 12가지 원칙
  
  
    
      첫 포즈는 초상화가 아니라 애니메이션용으로 만들어야 합니다. 넉넉한 여백이 필수입니다.
      비디오 모델은 첫 포즈보다 더 크게 움직이는 경향이 있습니다. 여유를 두세요.
      공격, 점프, 달리기 등은 극단 포즈보다 전환 포즈에서 시작하는 것이 좋습니다.
      프롬프트는 감성적 표현보다 기계적 동작 설명이 좋습니다.
      "빠른 공격"보다 "검을 들어 올림 → 멈춤 → 내려침 → 회복"처럼 단계별로 써야 합니다.
      카메라 고정 조건을 반드시 넣어야 합니다.
      점프, 착지, 낙하 같은 수직 애니메이션은 캐릭터 움직임과 먼지/바람 효과를 따로 만드는 것이 좋습니다.
      마지막 프레임이 첫 프레임과 너무 비슷하면 애니메이션이 멈춘 것처럼 보일 수 있습니다.
      끝 포즈가 idle과 잘 연결되지 않으면 이미지 모델로 브릿지 프레임을 만드세요. 비디오 재생성보다 저렴합니다.
      비용을 줄이고 싶다면 이미지 모델만으로도 가능하지만, 품질과 안정성은 비디오 모델 함께 쓸 때 훨씬 좋습니다.
    
  





  이미지 모델 → 비디오 모델 → 파이썬 자동화 파이프라인
  GPT Image · Kling · FFmpeg · Pillow
  출처: X (Twitter) 원문 보기







Open Design — 에이전트 시대의 오픈소스 디자인 도
행복한 수지아빠 — Wed, 29 Apr 2026 16:46:15 +0900





Open Design — 에이전트 시대의 오픈소스 디자인 도구





  Open Source · Design Tool
  당신의 에이전트가
디자인 엔진이 된다면
  Open Design — 로컬에서 실행되고, 에이전트를 선택하고,
스킬을 조합하는 오픈소스 디자인 생성 도구
  2026.04.29 · Open Design Team





왜 이 프로젝트가 필요한가

2026년 4월, Anthropic이 Claude Design을 공개했다. LLM이 글을 쓰는 대신 실제 디자인 산출물을 배송하는 첫 번째 순간이었다. 반응은 폭발적이었다. 그리고 그대로 폐쇄형, 유료, 클라우드 전용, Anthropic 모델 락인이었다.

직접 호스팅할 수 없다. Vercel에 배포할 수 없다. 다른 에이전트를 끼워 넣을 수 없다. 스킬을 수정하거나 새로 만들 수 없다.


  Open Design은 같은 루프, 같은 산출물 중심의 접근 방식을 취하면서, 모든 락인을 제거한다. 에이전트도, 모델도, 스킬 카탈로그도 직접 소유하지 않는다. 세 가지 모두 외부에서 꽂는 구조다.


이것은 "또 하나의 AI 디자인 도구"가 아니다. 당신이 이미 가지고 있는 코딩 에이전트를 디자인 워크플로우로 연결하는 통합 셸이다.

한눈에 보는 핵심


  
    ⚡
    6개 에이전트 지원
    Claude Code, Codex, Cursor Agent, Gemini CLI, OpenCode, Qwen Code — 이미 설치된 CLI를 자동 감지하여 실행
  
  
     
    71개 디자인 시스템
    Stripe, Vercel, Linear, Notion, Tesla, Apple 등 브랜드급 시스템이 DESIGN.md 형태로 내장
  
  
     
    30개 디자인 스킬
    웹 프로토타입, 모바일 앱, 대시보드, 프레젠테이션, SaaS 랜딩까지 폴더 하나로 확장 가능
  
  
     
    Local-first
    모든 데이터는 로컬 SQLite에 저장. 클라우드 의존성 없이 pnpm dev, Vercel, 단일 프로세스 어디든 배포
  
  
     
    5개 비주얼 디렉션
    Editorial Monocle, Modern Minimal, Tech Utility, Brutalist, Soft Warm — 결정론적 팔레트와 폰트 스택 제공
  
  
     
    디바이스 프레임
    iPhone 15 Pro, Pixel, iPad Pro, MacBook, Browser Chrome — 픽셀 단위 정확한 프레임 내장
  


어떻게 동작하는가

Open Design의 아키텍처는 세 개의 레이어로 구성된다. 사용자의 브라우저, 로컬 데몬, 그리고 이미 설치된 에이전트 CLI.


  
    1
    
      브리프 입력
      사용자가 자연어로 디자인 요구사항을 입력하고, 스킬과 디자인 시스템을 선택
    
  
  
    2
    
      프롬프트 조합
      데몬이 디스커버리 레이어 + 디자인 시스템 + 스킬 + 프로젝트 메타데이터를 다층 시스템 프롬프트로 조합
    
  
  
    3
    
      에이전트 실행
      선택된 에이전트 CLI를 child_process로 실행, 실제 파일 시스템 위에서 Read/Write/Bash 권한 부여
    
  
  
    4
    
      실시간 렌더링
      SSE 스트리밍으로 에이전트 출력을 받아 artifact 태그를 파싱, 샌드박스 iframe에서 즉시 미리보기
    
  


시스템 구조


open-design/
├── src/             # React + TypeScript 프론트엔드
├── daemon/          # Express + SQLite 백엔드
├── skills/          # 30개 파일 기반 디자인 스킬
├── design-systems/  # 71개 브랜드 디자인 시스템
├── assets/frames/   # 디바이스 프레임 HTML
└── docs/            # 제품 스펙, 아키텍처, 로드맵


프론트엔드는 React 18 + TypeScript로 구성되어 있고, 상태관리는 순수 React hooks만 사용한다. Redux, Zustand 같은 외부 라이브러리는 없다. 라우팅도 커스텀 훅으로 처리한다.

백엔드 데몬은 Express + better-sqlite3로, TypeScript 없이 순수 JavaScript로 작성되었다. 프로젝트, 대화, 메시지, 탭 상태를 SQLite에 저장하고, 에이전트 CLI를 child_process로 실행한다.

스킬 시스템 — 폴더 하나로 확장

Open Design의 확장성은 파일 기반 스킬 시스템에서 나온다. skills/ 폴더 아래에 디렉토리를 하나 만들고 SKILL.md 파일을 넣으면, 그것이 곧 새로운 디자인 스킬이다.


  
    
    markdown
  
  1---
2name: SaaS Landing Page
3description: 컨버전 최적화 SaaS 랜딩 페이지 생성
4od.mode: prototype
5od.platform: web
6od.scenario: landing
7---
8
9# 워크플로우
10
111. 히어로 섹션: 가치 제안 → CTA → 사회적 증명
122. 기능 섹션: 3-6개 핵심 기능 카드
133. 가격 섹션: 3티어 가격표
144. 푸터: 링크 + 뉴스레터


포크할 수 있고, 버전 관리할 수 있고, 공유할 수 있고, 심볼릭 링크로 설치할 수 있다. 서드파티가 skills/에 폴더를 하나 떨어뜨리는 것만으로 확장이 완료된다.

디자인 시스템 — DESIGN.md로 표현

71개의 디자인 시스템이 각각 하나의 DESIGN.md 파일로 존재한다. 이 파일은 awesome-claude-design의 9섹션 스키마를 따른다.


  섹션 내용
  
    Colors 팔레트 토큰 (primary, secondary, accent, neutral)
    Typography 폰트 패밀리, 크기, 웨이트 체계
    Spacing 간격 토큰 (4px 베이스 그리드)
    Components 버튼, 카드, 입력 필드 등 UI 컴포넌트 규칙
    Effects 그림자, 블러, 트랜지션 효과
  


에이전트는 시스템 프롬프트에서 이 토큰을 읽고, 결정론적으로 색상과 폰트를 적용한다. 모델이 자의적으로 색상을 고르지 않는다. 토큰이 지시하는 대로 만든다.

실제 사용 시나리오


  
    1
    웹 프로토타입 생성
  
  
    
      User Prompt
      "Airbnb 스타일 검색 페이지 만들어줘. 우리 내부 디자인 시스템 적용하고."
    
    
      프로토타입 스킬 자동 선택, 사용자 DESIGN.md 로드
      디스커버리 질문 폼으로 타겟, 톤, 브랜드 컨텍스트 확정
      에이전트가 TodoWrite로 작업 계획을 스트리밍
      HTML artifact가 샌드박스 iframe에서 실시간 렌더링
      특정 요소 클릭 → 코멘트 → 에이전트가 해당 영역만 수정
    
    프로덕션급 HTML 프로토타입 완성
  



  
    2
    매거진 스타일 피치 덱
  
  
    
      User Prompt
      "시드 라운드용 8슬라이드 매거진 스타일 피치 덱 만들어줘."
    
    
      guizang-ppt 스킬로 라우팅 (매거진 레이아웃, WebGL 히어로)
      5개 비주얼 디렉션 중 하나를 선택하는 두 번째 폼 표시
      결정론적 OKLch 팔레트 + 폰트 스택 자동 적용
      단일 파일 HTML 덱 생성, 화살표 키 내비게이션
      PDF / PPTX / ZIP / Markdown으로 내보내기
    
    인쇄 가능한 피치 덱 완성
  



  
    3
    디자인 시스템 구축
  
  
    
      User Prompt
      "우리 브랜드 가이드 기반으로 DESIGN.md 만들어줘."
    
    
      스크린샷, 브랜드 가이드 PDF, 또는 Figma 링크 업로드
      design-system-skill이 9섹션 포맷으로 DESIGN.md 생성
      이후 모든 생성 작업에서 자동으로 해당 토큰 참조
      프로토타입, 덱, 템플릿 모두 일관된 브랜드 적용
    
    브랜드 일관성 보장
  


3초만에 시작하기

설치와 실행은 터미널 명령 세 줄이면 충분하다.


  
    
    bash
  
  1# 저장소 클론
2git clone https://github.com/your-org/open-design.git
3cd open-design
4
5# 의존성 설치
6pnpm install
7
8# 데몬 + 프론트엔드 동시 실행
9pnpm dev:all



  ✓
  dev:all 스크립트는 데몬(포트 7456)과 Vite 개발 서버(포트 5173)를 동시에 실행합니다. 기본 포트가 사용 중이면 자동으로 다른 포트를 찾습니다.


브라우저가 열리면 첫 화면에서 스킬을 고르고, 디자인 시스템을 선택하고, 브리프를 입력하면 바로 시작된다.

"AI가 디자인한다"가 아니다

Open Design의 프롬프트 스택은 에이전트에게 시니어 디자이너의 작업 방식을 강제한다.


  모델이 한 픽셀도 그리기 전에, 디스커버리 폼으로 브리프를 확정한다
  브랜드가 없으면 5개 큐레이션 디렉션 중 하나를 선택한다 — 모델이 자의적으로 정하지 않는다
  에이전트가 TodoWrite로 작업 계획을 세우고, 실시간으로 진행 상황을 스트리밍한다
  데몬이 실제 파일 시스템에 시드 템플릿, 레이아웃 라이브러리, 셀프체크 체크리스트를 구성한다
  에이전트는 5차원 자기 비판을 수행한 후에야 <artifact>를 출력한다



  그것은 "AI가 뭔가 디자인해본다"가 아니다. 프롬프트 스택에 의해 훈련된, 실제 파일 시스템과 결정론적 팔레트 라이브러리와 체크리스트 문화를 가진 시니어 디자이너의 행동이다.


기술 스택 요약


  레이어 기술 비고
  
    프론트엔드 React 18 + TypeScript Vite 5 빌드, 순수 hooks 상태관리
    백엔드 Express + better-sqlite3 순수 JavaScript, TypeScript 없음
    에이전트 통신 child_process + SSE CLI stdout/stderr 스트리밍
    데이터 저장 SQLite (WAL 모드) 프로젝트, 대화, 메시지, 탭 상태
    산출물 렌더링 srcdoc iframe 샌드백스 환경, localStorage shim
    라이선스 Apache 2.0 완전한 오픈소스
  


누구를 위한 도구인가


  
     ‍ 
    인디 개발자 / 디자이너
    이미 하나의 코딩 에이전트를 구독 중이라면, 추가 결제 없이 디자인 산출물을 얻을 수 있다
  
  
     ️
    디자인 시스템 관리자
    DESIGN.md로 시스템을 코드화하면, 모든 스킬이 자동으로 해당 토큰을 준수한다
  
  
     
    스킬 작성자
    "글라스모피즘 SaaS 마케팅 페이지" 같은 디자인 스킬을 게시하면, 어떤 에이전트에서도 실행된다
  
  
     
    AI 도구 자체 호스팅 팀
    Electron 바이너리가 아닌 웹 배포가 필요하고, 키를 자체 인프라에 보관해야 하는 팀
  


오픈소스의 어깨 위에서

Open Design은 네 개의 오픈소스 프로젝트 위에 서 있다.


  huashu-design — 디자인 철학 나침반. 주니어 디자이너 워크플로우, 5단계 브랜드 에셋 프로토콜, 안티 AI-slop 체크리스트가 모두 이 프로젝트에서 왔다
  guizang-ppt-skill — 덱 모드. 매거진 레이아웃, WebGL 히어로 배경, 단일 파일 HTML 출력을 제공한다
  open-codesign — UX 북스타. 스트리밍 artifact 루프, 샌드박스 iframe 프리뷰, 5가지 포맷 익스포트를 참고했다
  multica — 데몬 및 런타임 아키텍처. PATH 스캔 에이전트 감지, 로컬 데몬 패턴, 에이전트를 팀원으로 보는 세계관


다음 단계

Open Design은 현재 Phase 0 (스펙 확정) 단계에서 Phase 1 (MVP)로 진입하고 있다. 로드맵에 따르면 6-8주 내에 핵심 기능이 안정화될 예정이다.

기여는 언제나 환영한다. 스킬을 만들어도 좋고, 디자인 시스템을 추가해도 좋고, 에이전트 어댑터를 개선해도 좋다. 중요한 것은 하나 — 에이전트도, 모델도, 스킬 카탈로그도 우리가 소유하지 않는다는 철학을 유지하는 것.


  i
  Apache 2.0 라이선스로 배포됩니다. 포크, 수정, 상업적 사용 모두 자유입니다.





  Open Design — the open-source alternative to Claude Design
  GitHub에서 보기







Voicebox — 로컬에서 돌아가는 AI 보이스 스튜디오
행복한 수지아빠 — Tue, 28 Apr 2026 16:13:45 +0900





Voicebox — 로컬에서 돌아가는 AI 보이스 스튜디오





  Open Source Analysis
  로컬에서 돌아가는
AI 보이스 스튜디오
  ElevenLabs 대체재이자 WisprFlow 대체재.
음성 복제, TTS, STT, 딕테이션, 에이전트 음성 출력까지
모든 걸 내 컴퓨터에서.
  2026.04.28 · jamiepine/voicebox 분석






  
  어떤 프로젝트인가
  Voicebox는 로컬 우선(local-first) 오픈소스 AI 보이스 스튜디오입니다. 클라우드 의존 없이 음성 복제, 텍스트 음성 변환(TTS), 음성 인식(STT), 글로벌 받아쓰기, AI 에이전트 음성 출력까지 한 데 묶은 데스크톱 애플리케이션입니다.

  
    ElevenLabs와 WisprFlow를 합친 무료 대안. 모든 처리가 로컬에서 이루어지며, API 키나 구독이 필요 없습니다.
  

  버전 0.4.0, MIT 라이선스로 배포됩니다. Tauri + Rust 데스크톱 셸과 Python FastAPI 백엔드, React 프론트엔드로 구성된 풀스택 프로젝트입니다.

  
  핵심 기능

  
    
      🎤
      7개 TTS 엔진
      Qwen3-TTS, Chatterbox, Kokoro, HumeAI TADA 등 7개 엔진 탑재. 23개 언어 지원
    
    
      🎠
      제로샷 음성 복제
      몇 초짜리 참조 오디오만으로 목소리를 복제합니다
    
    
      🎚
      오디오 후처리
      피치 시프트, 리버브, 딜레이, 코러스, 컴프레서. Spotify pedalboard 기반
    
    
      🎥
      글로벌 받아쓰기
      푸시투톡 + 토글 모드. macOS 자동 붙여넣기 지원
    
    
      🤖
      MCP 서버 내장
      Claude Code, Cursor, Windsurf에 한 줄로 연결. 에이전트별 음성 바인딩
    
    
      🎬
      스토리즈 에디터
      멀티트랙 타임라인으로 대화, 팟캐스트, 내레이션 제작
    
  

  
  아키텍처
  Voicebox는 세 가지 레이어로 분리된 구조입니다.

  
    
      1
      
        Python FastAPI 백엔드
        포트 17493에서 동작. ML 추론, API 라우트, SQLite 데이터베이스, MCP 서버 담당
      
    
    
      2
      
        Tauri (Rust) 데스크톱 셸
        네이티브 윈도우, 글로벌 단축키 등록, 클립보드 붙여넣기 주입, 포커스 감지
      
    
    
      3
      
        React + TypeScript 프론트엔드
        데스크톱과 웹 배포 공통 UI. Tailwind CSS v4, Zustand 상태 관리
      
    
  

  프로젝트 디렉토리

  
voicebox/
├── app/         # React 프론트엔드 (컴포넌트, 훅, API 클라이언트)
├── tauri/       # 데스크톱 앱 (Tauri + Rust)
├── web/         # 웹 배포 변형
├── backend/     # Python FastAPI 서버 (main.py, tts.py, 모델, DB)
├── landing/     # 마케팅 웹사이트
└── scripts/     # 빌드, 릴리스, 개발 스크립트
  

  
  기술 스택

  
    
      레이어 기술
    
    
      데스크톱 앱 Tauri (Rust)
      프론트엔드 React, TypeScript, Tailwind CSS v4
      상태 관리 Zustand, React Query
      백엔드 FastAPI (Python)
      TTS 엔진 Qwen3-TTS, Chatterbox, Kokoro, TADA 등 7종
      STT Whisper / Whisper Turbo
      로컬 LLM Qwen3 (0.6B / 1.7B / 4B)
      MCP 서버 FastMCP (Streamable HTTP + stdio)
      오디오 이펙트 Pedalboard (Spotify)
      추론 MLX (Apple Silicon) / PyTorch (CUDA/ROCm/XPU)
      데이터베이스 SQLite
      빌드 오케스트레이션 just (justfile)
    
  

  
  설치와 실행

  필수 조건
  
    Bun 1.0.0 이상
    Rust (stable)
    Python 3.11 이상
    macOS: Xcode Command Line Tools
  

  빠른 시작

  
    
      
      bash
    
1# 저장소 클론
2git clone https://github.com/jamiepine/voicebox.git
3cd voicebox
4
5# just 설치 (아직 없다면)
6brew install just
7
8# 전체 셋업 (Python venv + JS/Python 의존성)
9just setup
10
11# 개발 모드 실행 (백엔드 + 데스크톱 앱)
12just dev
  

  모델은 HuggingFace Hub에서 최초 실행 시 자동 다운로드됩니다. Whisper, Qwen3-TTS 등 보통 2-4 GB 정도입니다.

  
    i
    
      백엔드만 실행하려면 just dev-backend, 프론트엔드만 실행하려면 just dev-frontend, 웹 버전은 just dev-web을 사용합니다.
    
  

  
  API 사용법
  FastAPI 백엔드는 http://127.0.0.1:17493에서 REST API를 제공합니다.

  음성 생성

  
    
      
      bash
    
1curl -X POST http://127.0.0.1:17493/generate \
2  -H "Content-Type: application/json" \
3  -d '{
4    "text": "안녕하세요, 반갑습니다",
5    "profile_id": "abc123",
6    "language": "ko"
7  }'
  

  에이전트 음성 출력

  
    
      
      bash
    
1curl -X POST http://127.0.0.1:17493/speak \
2  -H "Content-Type: application/json" \
3  -H "X-Voicebox-Client-Id: my-script" \
4  -d '{
5    "text": "Deploy complete.",
6    "profile": "Morgan"
7  }'
  

  음성 인식

  
    
      
      bash
    
1curl -X POST http://127.0.0.1:17493/transcribe \
2  -F "audio=@recording.wav" \
3  -F "model=whisper-turbo"
  

  
  MCP 통합 — 에이전트에 목소리 달기
  Voicebox에 MCP(Model Context Protocol) 서버가 내장되어 있어, 코딩 에이전트에 음성 출력을 한 줄로 연결할 수 있습니다.

  Claude Code 연결

  
    
      
      bash
    
1claude mcp add voicebox \
2  --transport http \
3  --url http://127.0.0.1:17493/mcp \
4  --header "X-Voicebox-Client-Id: claude-code"
  

  제공되는 MCP 도구

  
    
      도구 설명
    
    
      voicebox.speak 텍스트를 음성으로 출력합니다
      voicebox.transcribe 오디오를 텍스트로 변환합니다
      voicebox.list_captures 저장된 녹음 목록을 반환합니다
      voicebox.list_profiles 사용 가능한 음성 프로필을 나열합니다
    
  

  
    +
    
      에이전트별 음성 바인딩이 가능합니다. Claude Code에는 Morgan 목소리, Cursor에는 다른 목소리를 지정하는 식으로요.
    
  

  
  7개 TTS 엔진 비교

  
    
      엔진 특징
    
    
      Qwen3-TTS (0.6B) 가벼운 모델. 빠른 생성
      Qwen3-TTS (1.7B) 표준 모델. 품질과 속도 균형
      Qwen CustomVoice 50개 이상 프리셋 보이스
      LuxTTS 경량 고품질 엔진
      Chatterbox 23개 언어 다국어 지원
      Chatterbox Turbo 감정 태그 지원 ([laugh], [sigh], [gasp])
      HumeAI TADA 표현력 높은 감정 음성
      Kokoro 안정적이고 자연스러운 합성
    
  

  무제한 길이 생성이 가능합니다. 긴 텍스트는 자동 청킹 후 크로스페이드로 이어붙입니다. 비동기 생성 큐가 직렬 실행되어 GPU 경합을 방지합니다.

  
  감정 표현 태그
  Chatterbox Turbo 엔진은 텍스트 안에 감정 태그를 삽입할 수 있습니다.

  
    
      
      text
    
1[laugh] 그래서 제가 말했잖아요,
2이건 정말 [gasp] 놀라운 일이에요.
3[sigh] 하지만 다시 시작해야겠죠.
  

  
  GPU 지원

  
    
      플랫폼 백엔드
    
    
      macOS (Apple Silicon) MLX (Metal) — Neural Engine로 4-5배 가속
      Windows / Linux (NVIDIA) PyTorch (CUDA)
      Linux (AMD) PyTorch (ROCm)
      Windows (범용 GPU) DirectML
      Intel Arc IPEX / XPU
      모든 환경 CPU (느리지만 동작함)
    
  

  
  보이스 퍼스낼리티
  각 음성 프로필에 자유 형식 페르소나를 붙일 수 있습니다. 로컬 Qwen3 LLM이 텍스트를 먼저 페르소나에 맞게 변환한 뒤 TTS로 넘깁니다.

  
    
      1
      
        에이전트가 텍스트 전달
        personality: true 파라미터와 함께 텍스트 전송
      
    
    
      2
      
        Qwen3 LLM이 페르소나 적용
        Compose / Rewrite / Respond 모드로 텍스트 변환
      
    
    
      3
      
        TTS 엔진이 음성 생성
        변환된 텍스트로 최종 음성 출력
      
    
  

  
  만들 수 있는 것들

  
    
      1
      코딩 에이전트에 음성 피드백 추가
    
    
      
        시나리오
        Claude Code가 작업을 완료하면 음성으로 알려줍니다. MCP 한 줄 연결만으로 가능합니다.
      
      MCP 서버 + 음성 프로필 바인딩
    
  

  
    
      2
      로컬 팟캐스트 제작
    
    
      
        시나리오
        스토리즈 에디터의 멀티트랙 타임라인으로 여러 목소리를 조합해 팟캐스트를 만듭니다.
      
      멀티트랙 + 음성 복제 + 오디오 이펙트
    
  

  
    
      3
      글로벌 받아쓰기로 문서 작성
    
    
      
        시나리오
        단축키로 어느 앱에서든 음성 입력. Whisper가 텍스트로 변환하고 필러 워드를 LLM이 정리합니다.
      
      글로벌 핫키 + Whisper + LLM 정제
    
  

  
    
      4
      커스텀 보이스로 오디오북 제작
    
    
      
        시나리오
        참조 오디오 몇 초로 목소리를 복제하고, 긴 텍스트는 자동 청킹 + 크로스페이드로 무제한 생성합니다.
      
      제로샷 복제 + 무제한 길이 + 후처리 이펙트
    
  




  Voicebox — Local-first AI voice studio, MIT License
  github.com/jamiepine/voicebox






AI와 채팅하면 영상이 편집됩니다 — video-use 가이드
행복한 수지아빠 — Tue, 28 Apr 2026 15:24:38 +0900





AI와 채팅하면 영상이 편집됩니다 — video-use 가이드





  Open Source Tool
  AI와 채팅하면
영상이 편집됩니다
  원본 영상을 폴더에 넣고 Claude Code와 대화하면,
편집이 끝난 final.mp4를 돌려받습니다.
video-use가 하는 일을 정리했습니다.
  2026.04.28 · video-use 가이드






  
  어떤 일을 하나요
  영상을 터미널에 드래그하고, 자연어로 원하는 편집을 말하면 됩니다. AI가 전사하고, 분석하고, 편집 전략을 제안한 뒤 렌더까지 수행합니다.

  
    
      ✎
      필러 워드 제거
      "음", "어", "그러니까" 같은 불필요한 말을 감지해 깔끔하게 잘라냅니다
    
    
      ☀
      컬러 그레이딩
      클립별로 데이터 기반 색보정을 자동 적용합니다
    
    
      ♪
      오디오 페이드
      모든 컷에 30ms 페이드로 팝 노이즈를 없앱니다
    
    
      ☰
      자막 굽기
      2단어 단위 대문자 자막을 영상에 새겨넣습니다
    
    
      ▶
      애니메이션 오버레이
      PIL, Manim으로 그래프와 모션을 생성해 올립니다
    
    
      ↻
      자체 평가
      AI가 편집 결과를 검토하고 스스로 개선을 반복합니다
    
  

  
  어떻게 동작하나요
  AI가 영상을 이해하는 방식은 두 가지 레이어로 나뉩니다.

  Layer 1. 오디오 전사 — 항상 켜져 있습니다
  ElevenLabs Scribe가 영상에서 단어 단위 타임스탬프, 화자 구분, 오디오 이벤트를 추출합니다. 이를 takes_packed.md 파일로 정리해 AI가 읽기 쉽게 만듭니다.

  Layer 2. 비주얼 컴포지트 — 필요할 때만
  특정 시간대에 화면에서 무슨 일이 일어나는지 확인해야 할 때, 필름스트립과 파형 PNG를 생성해 AI가 시각적으로 확인합니다.

  
    
      1
      
        전사
        transcribe.py가 영상을 텍스트로 변환합니다
      
    
    
      2
      
        패킹
        takes_packed.md로 문장 단위 정리합니다
      
    
    
      3
      
        분석 & 전략
        AI가 전사를 읽고 편집 전략을 수립합니다
      
    
    
      4
      
        EDL 생성
        편집 결정 목록(JSON)을 작성합니다
      
    
    
      5
      
        렌더 & 검증
        preview.mp4를 만들고 자체 평가 후 final.mp4를 출력합니다
      
    
  

  
  편집 스크립트
  helpers/ 디렉토리 안에 있는 6개의 Python 스크립트가 실제 작업을 수행합니다.

  
    
      스크립트 역할
    
    
      transcribe.py ElevenLabs Scribe로 영상 하나 전사. 이미 전사된 파일은 캐시에서 불러옵니다
      transcribe_batch.py 폴더 안의 모든 영상을 병렬(기본 4 워커)로 전사합니다
      pack_transcripts.py 전사 결과를 takes_packed.md로 변환. 침묵 0.5초 이상 또는 화자 변경 시 구분합니다
      timeline_view.py 필름스트립 + 파형 PNG 생성. 특정 시간대를 시각적으로 검토할 때 사용합니다
      grade.py 컬러 그레이딩. 프리셋(subtle, warm_cinematic 등) 또는 자동 데이터 기반 보정
      render.py 전체 렌더 파이프라인. 세그먼트 추출 → 그레이드 → 페이드 → 병합 → 자막
    
  

  
  프로젝트 디렉토리
  편집 작업은 edit/ 폴더 안에 정리됩니다.

  
edit/
├── project.md          # 편집 세션 메모리
├── takes_packed.md     # 패킹된 전사 텍스트
├── edl.json            # 편집 결정 목록
├── transcripts/        # 원본 전사 JSON
├── animations/         # 생성된 애니메이션
├── clips_graded/       # 색보정된 클립
├── master.srt          # 마스터 자막 파일
├── downloads/          # 다운로드한 영상
├── verify/             # 검증용 파일
├── preview.mp4         # 미리보기
└── final.mp4           # 최종 결과물
  

  
  12가지 하드 룰
  video-use가 지키는 품질 규칙입니다. 영상 편집의 프로덕션 퀄리티를 보장합니다.

  
    자막은 필터 체인에서 마지막에 적용
    세그먼트별 개별 추출 + 무손실 병합
    모든 컷에 30ms 오디오 페이드
    PTS-시프트 오버레이
    출력 타임라인 기준 SRT 오프셋
    단어 경계에서만 컷
    컷 가장자리 패딩 프레임
    단어 단위 축어적(verbatim) ASR
    전사 캐시 — 재전사 금지
    애니메이션은 병렬 서브에이전트로 처리
    실행 전 전략 확인 필수
    모든 출력은 /edit/에 저장
  

  
  실전 예제 8선

  
  
    
      1
      유튜브 영상에서 필러 워드 제거
    
    
      
        Prompt
        interview.mp4에서 '음', '어', '그러니까', 'like', 'um' 같은 필러 워드를 전부 잘라내줘.
      
      
        transcribe.py가 영상을 전사합니다
        AI가 필러 워드 위치를 탐색합니다
        EDL에 컷 포인트를 작성합니다 (단어 경계, 30ms 페이드)
        preview.mp4를 렌더하고 자체 검증합니다
      
      10분 → 8분 30초 · 필러 제거 완료
    
  

  
  
    
      2
      팟캐스트에 한국어 자막 달기
    
    
      
        Prompt
        podcast_ep12.mp4에 한국어 자막을 넣어줘. 2단어씩 끊어서 화면 하단에 표시해.
      
      
        --language ko 옵션으로 한국어 전사
        pack_transcripts.py로 문장 단위 정리
        자막은 필터 체인 마지막에 적용 (규칙 1)
        SRT 오프셋은 출력 타임라인 기준 (규칙 5)
      
      master.srt · 자막 굽기 완료
    
  

  
  
    
      3
      강의 영상 색보정 + 침묵 제거
    
    
      
        Prompt
        lecture.mp4를 편집해줘. 조명이 어두운 구간은 밝게 보정하고, 5초 이상 침묵인 구간은 잘라내. 색감은 warm_cinematic 프리셋으로.
      
      
        전사 + 타임라인 뷰로 침묵 구간 탐지
        grade.py에서 warm_cinematic + 어두운 구간 자동 보정
        침묵 구간 컷아웃 (30ms 페이드)
        최종 렌더
      
      clips_graded/ · 보정 + 편집 완료
    
  

  
  
    
      4
      여러 클립 하이라이트 릴
    
    
      
        Prompt
        raw/ 폴더 안에 있는 5개 인터뷰 영상에서 가장 인상적인 발언만 모아서 3분 하이라이트 릴을 만들어줘.
      
      
        transcribe_batch.py가 5개 영상을 병렬 전사 (4 워커)
        AI가 전사 내용을 분석해 인상적인 발언 선별
        전략 제안 → 사용자 승인
        세그먼트별 추출 → 무손실 병합 (규칙 2)
      
      3분 하이라이트 · 5개 소스 병합
    
  

  
  
    
      5
      유튜브 URL 다운로드 후 편집
    
    
      
        Prompt
        https://youtube.com/watch?v=xxxxx 이 영상을 다운로드해서 앞뒤 인트로/아웃트로를 잘라내고, 본론만 남겨줘.
      
      
        yt-dlp로 영상 다운로드 → edit/downloads/
        전사 후 인트로/아웃트로 구간 식별
        본론 구간만 EDL에 포함
        렌더
      
      인트로/아웃트로 제거 · 본론만 출력
    
  

  
  
    
      6
      프레젠테이션에 애니메이션 오버레이
    
    
      
        Prompt
        keynote_talk.mp4에서 '수익 성장률' 이야기하는 구간에 막대 그래프 애니메이션을 오버레이해줘.
      
      
        전사에서 "수익 성장률" 키워드 타임스탬프 탐색
        애니메이션 서브에이전트가 PIL/Manim으로 그래프 생성
        PTS-시프트로 정확한 위치에 오버레이
        자막은 마지막에 적용
      
      animations/ · 애니메이션 + 자막 완료
    
  

  
  
    
      7
      반복 구문 정리
    
    
      
        Prompt
        meeting.mp4에서 같은 말을 반복하는 구간을 찾아서 가장 자연스러운 한 번만 남기고 나머지는 잘라줘.
      
      
        전사에서 유사 문장 클러스터링
        AI가 가장 매끄러운 버전을 선택
        나머지 반복 구간을 EDL에서 제외
        30ms 페이드로 자연스럽게 이음
      
      반복 제거 · 깔끔한 최종본
    
  

  
  
    
      8
      다국어 영상 처리
    
    
      
        Prompt
        bilingual_interview.mp4를 전사해줘. 한국어와 영어가 섞여 있으니 두 언어 모두 잡아내고, 화자도 구분해줘. 화자는 2명이야.
      
      
        transcribe.py --num-speakers 2 로 화자 구분 전사
        한국어 + 영어 혼합 자동 감지
        화자별로 takes_packed.md 정리
        필요시 화자별 자막 스타일 차별화
      
      화자 A/B 구분 · 다국어 자막
    
  

  
  시작하기

  
    설치는 이미 완료되어 있습니다. 작업 폴더에 원본 영상을 넣고, Claude Code에서 편집을 요청하면 바로 시작할 수 있습니다.
  

  ElevenLabs API 키만 설정하면 모든 준비가 끝납니다. 키를 전달해주시면 즉시 사용 가능합니다.




  video-use — Edit videos with Claude Code, 100% open source
  github.com/browser-use/video-use






Seedance2 프롬프트 단계별 설계
행복한 수지아빠 — Thu, 23 Apr 2026 11:02:49 +0900
프롬프트 설계시 순서도 사실상 Subject → Action → Camera → Style → Constraints 으로 하면 됩니다.
아래처럼 단계별로 하면 가장 실전적입니다.

Seedance 프롬프트를 하나씩 정하는 방법
0단계. 먼저 “한 장면, 한 목적”만 정한다
가장 먼저 해야 하는 건 문장을 쓰는 게 아니라,
이 영상에서 제일 중요한 한 장면이 뭐냐를 정하는 것입니다.
예를 들어:

여자가 비 오는 골목을 천천히 걷는 장면
남자 가수가 무대 중앙에 서 있는 장면
제품을 손으로 들어 올려 보여주는 장면
우주선이 도시 위에 등장하는 장면

여기서 중요한 건 욕심내서 여러 장면을 한 번에 넣지 않는 것입니다.
하나의 생성은 보통 하나의 핵심 비트로 생각하는 게 좋습니다.
가이드도 행동은 여러 개보다 핵심 행동 하나와 작은 보조 움직임 정도가 낫다고 설명합니다.
질문으로 바꾸면 이겁니다.

“이 영상에서 관객이 제일 먼저 보게 될 핵심 순간은 무엇인가?”

이 질문에 한 문장으로 답할 수 있어야 합니다.
예:

“검은 코트를 입은 여자가 비 오는 골목을 천천히 걸어간다.”

이게 출발점입니다.

1단계. Subject부터 잠근다
이제 누가/무엇이 화면의 중심인지를 정합니다.
이 단계는 흔들리기 가장 쉬운 인물 정체성, 외형, 위치를 고정하는 단계입니다.
정할 항목은 보통 이 정도입니다.

누구인가
나이대
성별 또는 분위기
헤어스타일
의상
액세서리
화면 안 위치
기본 표정

예를 들어 그냥 이렇게 쓰면 약합니다.
a woman

이렇게 바꾸면 훨씬 강해집니다.
late 20s Korean woman, straight black hair, long black trench coat, no accessories, centered in frame, restrained sad expression

Subject 정할 때 체크 질문

이 사람이 누구인지 한 번에 떠오르나?
옷과 머리 모양이 충분히 고정됐나?
표정이 너무 추상적이지 않나?
화면 중심인지, 옆인지도 정했나?

초보가 자주 하는 실수

“beautiful woman”, “handsome man”처럼 추상적으로 씀
옷과 머리를 안 적음
인물이 한 명인지 두 명인지 불명확함


2단계. Action은 하나만 고른다
다음은 무슨 일이 벌어지는지를 정합니다.
여기서 제일 중요한 원칙은:

메인 행동 1개 + 보조 미세 움직임 1~2개

입니다.
예를 들어 나쁜 방식은 이렇습니다.
she walks, turns, smiles, cries, reaches out, then runs

이건 너무 많습니다.
좋은 방식은 이렇습니다.
she walks slowly forward, with slight hair movement from the wind, and one subtle glance downward

여기서

메인 행동: walks slowly forward
보조 움직임: hair movement
감정 보조: subtle glance downward

이렇게 중심이 분명합니다.
Action 정할 때 체크 질문

이 장면에서 가장 중요한 행동이 딱 하나인가?
그 행동이 5~10초 안에 자연스럽게 보일 수 있나?
너무 많은 동작을 한 프롬프트 안에 넣지 않았나?

실전 팁
장면을 말로 설명할 때 “그리고”가 많이 들어가면 보통 과한 겁니다.
예:

걸어가고, 돌아보고, 울고, 손을 뻗고, 멈추고...
→ 너무 많음

대신:

천천히 걸어간다
한 번 고개를 돌린다
→ 이 정도가 좋음


3단계. Camera를 정한다
그다음은 어떻게 볼 것인가입니다.
업로드 이미지도 Camera를 Shot Type, Camera Movement, Lens & Focal Length, Composition으로 나눠 설명하고 있습니다.
이 단계에서는 최소한 아래 4개를 정하면 됩니다.
3-1. Shot Type
샷 크기부터 정합니다.
예:

wide shot
medium shot
close-up
full-body shot
over-the-shoulder

질문:

이 장면은 멀리서 봐야 하나, 가까이서 봐야 하나?

예를 들어 콘서트면:

군중 규모가 중요하면 wide shot
감정이 중요하면 medium shot
입모양을 피하고 싶으면 extreme close-up은 피하는 게 좋음


3-2. Camera Movement
이건 제일 중요합니다.
가이드에서도 한 번의 생성에서는 메인 카메라 움직임 하나를 정해서 끝까지 밀라고 말합니다.
주로 쓰는 건 이 정도입니다.

locked tripod
slow push-in
dolly follow
pan left to right
orbit around subject
crane up

초보자는 한 장면에 하나만 쓰는 게 좋습니다.
예:
slow dolly follow

좋지 않은 예:
fast cinematic dynamic movement with orbit and pan and zoom

이건 카메라가 너무 많은 일을 하게 됩니다.

3-3. Lens / Focal Length
렌즈 느낌도 가능하면 정하는 게 좋습니다.

24mm: 넓고 공간감 큼
50mm: 자연스러운 표준 느낌
85mm: 배경 압축, 인물 강조, 공연/감성 샷에 좋음

간단히 외우면 됩니다.

공간 보여주고 싶다 → 24mm
무난하고 자연스럽게 → 50mm
인물 강조하고 배경 압축 → 85mm


3-4. Composition
구도도 짧게 정하면 좋습니다.
예:

centered composition
low angle
side profile
rule of thirds
back silhouette

질문:

이 사람을 정면 중심으로 둘 건가, 옆으로 둘 건가, 아래에서 볼 건가?


4단계. Style은 느낌 단어 말고 시각 요소로 정한다
여기서 많이들 실수합니다.
가이드에서도 cinematic, beautiful, epic 같은 말만 쓰는 건 약하다고 지적합니다.
스타일은 실제 픽셀을 바꾸는 요소로 써야 합니다.
정하면 좋은 항목:

조명
색감
질감
환경 요소

예시:
soft warm spotlight, cool blue ambient light, light haze in the air, subtle film grain, desaturated palette

이건 실제로 화면에 영향을 줍니다.
반면 이런 건 약합니다.
beautiful cinematic amazing

Style 정할 때 체크 질문

빛이 따뜻한가 차가운가?
전체 색감이 선명한가, 채도가 낮은가?
공기 중에 안개, 먼지, 비 같은 게 있나?
디지털하게 깨끗한가, 필름 그레인이 있나?

쉬운 공식
스타일은 보통 이 순서로 고르면 편합니다.

조명: warm / cool / neon / soft / harsh
색감: desaturated / vivid / teal-orange / monochrome
질감: clean digital / film grain / glossy / matte
환경: rain / haze / fog / dust / smoke


5단계. Constraints로 흔들림을 막는다
이 단계가 진짜 중요합니다.
가이드도 Constraints를 모델이 멋대로 하지 못하게 막는 장치로 설명합니다. 얼굴 유지, 의상 유지, morphing 없음, 흔들림 없음 같은 요소가 핵심입니다.
보통 마지막에 이런 식으로 붙입니다.
8 seconds, smooth continuous motion, keep face and outfit consistent, no morphing, no extra limbs, no sudden camera shake

이건 화려하지 않지만 결과를 안정화하는 데 매우 중요합니다.
꼭 넣어볼 만한 Constraint 예시

keep face consistent
keep outfit consistent
no morphing
no extra limbs
no sudden zoom
no camera shake
smooth steady motion
readable product label
no lip distortion

체크 질문

이 장면에서 절대 바뀌면 안 되는 건 뭔가?
모델이 자주 틀리는 부분이 뭔가?
흔들림, 왜곡, 얼굴 변화, 팔 다리 이상 같은 걸 막아야 하나?


실제로 조립하는 순서
이제 위 단계를 실제로 붙여보면 됩니다.
예를 들어
“비 오는 골목을 걷는 여자” 장면을 만들고 싶다면:
1. 핵심 장면
검은 코트를 입은 여자가 비 오는 골목을 천천히 걷는 장면
2. Subject
late 20s Korean woman, straight black hair, long black trench coat, centered in frame, restrained sad expression

3. Action
walking slowly forward, slight hair movement from the rain and wind, one subtle downward glance

4. Camera
medium side profile shot, slow dolly follow, 50mm lens, steady framing

5. Style
cold blue streetlight, soft warm reflections from nearby windows, light mist, desaturated palette, subtle film grain

6. Constraints
8 seconds, smooth continuous motion, keep face and outfit consistent, no morphing, no extra limbs, no abrupt camera shake

최종 프롬프트
medium side profile shot, slow dolly follow, 50mm lens, late 20s Korean woman, straight black hair, long black trench coat, centered in frame, restrained sad expression, walking slowly forward, slight hair movement from the rain and wind, one subtle downward glance, cold blue streetlight, soft warm reflections from nearby windows, light mist, desaturated palette, subtle film grain, 8 seconds, smooth continuous motion, keep face and outfit consistent, no morphing, no extra limbs, no abrupt camera shake

이렇게 만드는 겁니다.

가장 쉬운 실전 작성법: 빈칸 채우기 방식
처음에는 아래 템플릿으로 연습하면 편합니다.
[SHOT TYPE], [CAMERA MOVEMENT], [LENS], [SUBJECT], [APPEARANCE], [EXPRESSION], [MAIN ACTION], [MICRO MOVEMENT], [LIGHTING], [COLOR PALETTE], [ATMOSPHERE], [DURATION], [CONSISTENCY CONSTRAINTS], [ERROR PREVENTION]

예를 들어 채우면:
wide shot, slow crane up, 85mm lens, Korean female singer in her early 30s, long black dress, calm emotional expression, standing center stage and singing steadily, slight hand movement, warm spotlight, cool blue ambient crowd light, light haze, 10 seconds, keep face and outfit consistent, no sudden zoom or camera shake


초보자용 한 단계 더 쉬운 방법
처음엔 아래 순서대로 질문에 답만 하면 됩니다.
질문 1
누가 나오나?

30대 한국 여자 가수

질문 2
어떻게 생겼나?

긴 검은 드레스, 단정한 머리, 차분한 표정

질문 3
무슨 행동을 하나?

무대 중앙에 서서 천천히 노래한다

질문 4
카메라는 어떻게 보나?

멀리서 보고, 천천히 앞으로 들어간다

질문 5
빛과 분위기는?

따뜻한 스포트라이트, 차가운 객석 조명, 약한 안개

질문 6
뭘 막아야 하나?

얼굴 변형 금지, 의상 유지, 흔들림 금지

이 답을 그냥 이어 붙이면 이미 꽤 좋은 프롬프트가 됩니다.

마지막 체크리스트
프롬프트 다 썼으면 마지막에 이것만 체크하면 됩니다.

주체가 명확한가
행동이 하나로 정리됐는가
카메라 움직임이 하나인가
스타일이 시각 요소로 써졌는가
제약조건이 들어갔는가

이 5개가 들어가면, 적어도 “막연한 프롬프트”에서 “통제된 프롬프트”로 올라간 겁니다.


Seedance 2.0 프롬프트, 왜 자꾸 애매하게 나올까
행복한 수지아빠 — Thu, 23 Apr 2026 10:15:37 +0900
잘 되는 사람들은 “설명”하지 않고 “연출”한다
AI 영상 생성 툴을 처음 만지기 시작하면 누구나 비슷한 경험을 합니다.
머릿속에는 분명 멋진 장면이 있었는데, 결과물은 어딘가 애매합니다. 인물은 예쁜데 행동이 이상하고, 분위기는 좋은데 카메라가 산만하고, 전체적으로 “거의 맞는 것 같은데 결정적으로 부족한 영상”이 나옵니다.
많은 사람이 이 문제를 모델 성능 탓으로 돌리지만, 실제로는 프롬프트 구조의 문제인 경우가 많습니다. 업로드하신 가이드의 핵심도 바로 이것입니다. Seedance 2.0은 긴 설명문보다, 촬영팀에게 전달하는 지시서 같은 프롬프트를 더 잘 따른다는 점입니다. 다시 말해, 소설처럼 묘사하는 방식보다 감독처럼 연출하는 방식이 더 잘 먹힙니다.
이 차이를 이해하면 결과물이 달라집니다.
“한 여자가 슬픈 표정으로 비 오는 거리에서 걸어간다”라고 쓰는 것과,
“medium side shot, slow dolly follow, late 20s woman, black coat, wet hair, walking alone through a rainy alley, restrained expression, cold blue streetlight, steady pace, no morphing”이라고 쓰는 것은 완전히 다릅니다.
앞 문장은 장면의 감정을 말합니다.
뒤 문장은 장면의 촬영 방법을 말합니다.
Seedance 2.0은 바로 후자에 더 강합니다.

Seedance 2.0을 잘 쓰려면 먼저 생각을 바꿔야 한다
이 도구를 “텍스트를 넣으면 영상이 나오는 상자”처럼 다루면 결과가 흔들리기 쉽습니다. 업로드하신 정리문에서도 Seedance는 텍스트 하나만으로 모든 것을 상상하게 두는 방식보다, 여러 입력을 함께 써서 장면을 고정하는 방식에 더 강하다고 설명합니다. 예시로는 이미지, 비디오 클립, 오디오, 텍스트 지시문이 함께 언급됩니다. 핵심은 모델에게 모든 걸 동시에 발명하게 하지 말라는 뜻입니다.
왜냐하면 텍스트만 대충 넣으면 모델은 동시에 너무 많은 일을 해야 하기 때문입니다.
인물 정체성도 정해야 하고, 카메라 움직임도 만들고, 조명과 템포와 액션도 함께 조립해야 합니다. 이 과정에서 가장 먼저 무너지는 것은 대개 일관성입니다.
그래서 Seedance 프롬프트를 쓸 때는 질문이 달라져야 합니다.
“내가 무엇을 상상하고 있지?”가 아니라
“이 장면을 찍는다면 촬영팀에게 무엇을 먼저 말해야 하지?”가 되어야 합니다.
이 한 끗 차이가 품질 차이를 만듭니다.

정리하면 프롬프트는 세 가지를 분리해서 써야 한다
그럼 Seedance 2.0 프롬프트를 세 덩어리로 나눠 설명합니다.
첫째는 Camera입니다.
이 장면을 어떤 샷 크기로 볼지, 카메라가 어떻게 움직일지, 어떤 렌즈 느낌일지, 구도를 어떻게 잡을지 정하는 영역입니다.
둘째는 Motion입니다.
무슨 행동이 벌어지는지, 속도는 어떤지, 몇 초 동안 진행되는지, 전환은 어떻게 연결될지 정하는 영역입니다.
셋째는 Subject입니다.
화면의 주인공이 누구인지, 외형은 어떤지, 어떤 감정 상태인지, 환경과 어떤 관계를 맺고 있는지 정하는 영역입니다.
이 구성이 중요한 이유는 아주 단순합니다.
대부분의 초보 프롬프트는 이 세 가지가 뒤섞여 있기 때문입니다.
예를 들어 이런 문장을 봅시다.

아름답고 영화적인 장면, 한 여자가 슬프게 비를 맞으며 걷고 카메라는 멋지게 움직인다.

겉보기에는 그럴듯합니다.
하지만 실제로는 거의 아무것도 결정되지 않았습니다.

여자는 몇 살인지
어디에 있는지
어떤 옷을 입었는지
카메라는 wide인지 close-up인지
움직임은 pan인지 dolly인지 orbit인지
걷는 속도는 어떤지
전체 장면은 정적인지 격한지

이런 정보가 비어 있으면, 모델은 그 빈칸을 자기 식으로 채웁니다.
그 결과가 우리가 흔히 보는 “어딘가 AI스러운 애매한 영상”입니다.

그래서 실전에서는 5단계 구조로 쓰는 게 가장 안정적이다
업로드하신 가이드에서는 Seedance를 예측 가능하게 만드는 핵심 구조로 다음 순서를 제시합니다.
Subject → Action → Camera → Style → Constraints
이 순서는 단순한 팁이 아니라, 실제로 장면을 고정하는 사고 순서에 가깝습니다.
무엇을 찍는지 정하지 않은 상태에서 카메라부터 정하면 흔들리고, 행동이 정해지지 않은 상태에서 스타일만 넣으면 공허해집니다. 반대로 이 순서대로 가면, 장면의 중심축이 생깁니다.
이제 각각을 조금 더 깊게 보겠습니다.

1. Subject: 가장 먼저 고정해야 하는 것은 “누구를 보여줄 것인가”다
Seedance에서 가장 먼저 흔들리는 것은 대개 인물입니다.
얼굴이 미묘하게 바뀌고, 머리 길이가 달라지고, 같은 사람인데 컷마다 다른 사람처럼 보입니다. 이걸 줄이려면 Subject를 아주 구체적으로 써야 합니다.
가이드에서도 좋은 Subject는 막연한 명사가 아니라, 장면의 중심축을 분명하게 주는 설명이라고 말합니다. 나이대, 헤어스타일, 옷차림, 액세서리, 화면 내 위치, 표정 같은 요소가 포함될수록 안정적입니다. 예시로 “a woman”보다 “late 20s woman, tight dark curls, small silver hoop earring, black turtleneck, centered in frame, neutral expression” 같은 식이 훨씬 낫다고 설명합니다.
이 차이는 큽니다.
나쁜 프롬프트:
a woman

조금 나아진 프롬프트:
late 20s Korean woman, straight black hair tucked behind the ears, charcoal long coat, no accessories, centered in frame, tired eyes, restrained expression

앞 문장은 대상만 있습니다.
뒤 문장은 정체성의 기준점이 있습니다.
영상 생성에서 기준점이 없다는 것은, 계속 떠다닌다는 뜻입니다.

2. Action: 행동은 많을수록 좋은 게 아니라, 하나일수록 좋다
초보 프롬프트의 두 번째 문제는 행동을 너무 많이 넣는 것입니다.
“걸으면서 돌아보고 손을 뻗고 웃다가 멈추고 바람에 머리카락이 날리고 카메라는 돌고 조명이 변하고…”
사람은 이 문장을 읽고 장면을 상상할 수 있지만, 모델은 이 모든 동작을 한 번에 충족하려다 리듬이 깨질 수 있습니다.
가이드에서도 주요 행동 1개, 보조 미세 움직임 1~2개 정도가 가장 좋다고 강조합니다. 핵심 동작 하나를 정하고, 그 위에 작은 움직임만 얹는 방식입니다. 예를 들면 “걸어간다”가 메인 액션이고, “머리카락이 조금 흔들린다”와 “눈을 한 번 깜빡인다” 정도가 서브입니다.
예를 들어 보겠습니다.
나쁜 예:
she walks, turns, smiles, looks back, reaches forward, then runs

좋은 예:
she walks slowly toward the camera, with slight hair movement from the wind, and one subtle glance to the right

좋은 프롬프트는 “많이 시키는 프롬프트”가 아니라
“무엇이 중심 동작인지 분명한 프롬프트”입니다.

3. Camera: 결과물의 수준 차이는 카메라 지시에서 크게 벌어진다
영상 생성에서 가장 과소평가되는 부분이 카메라입니다.
많은 사용자가 Subject와 Style에는 신경을 쓰지만, Camera는 “cinematic movement” 같은 한마디로 넘깁니다. 그런데 가이드에서는 바로 이 부분을 특히 중요하게 봅니다. Seedance는 카메라 지시를 꽤 강하게 반영하므로, 뭉뚱그려 쓰기보다 한 가지 메인 카메라 움직임을 명확히 정하는 것이 좋다고 설명합니다. 추천 예시로는 slow push-in, orbit around subject, pan left-to-right, dolly follow, locked tripod 등이 제시됩니다. 그리고 한 번의 생성에서는 메인 카메라 움직임 하나를 정하고 끝까지 밀라고 조언합니다.
이 말은 실전에서 아주 중요합니다.
예를 들어 다음 둘을 비교해보면 차이가 분명합니다.
애매한 프롬프트:
cinematic camera movement

명확한 프롬프트:
medium side shot, slow dolly follow from left to right, 50mm lens, steady movement, no handheld shake

첫 문장은 분위기만 말합니다.
둘째 문장은 실제 촬영팀이 이해할 수 있는 지시입니다.
Seedance는 두 번째를 더 잘 따릅니다.

4. Style: “영화적으로”라고 쓰지 말고, 실제 픽셀을 바꾸는 요소를 써야 한다
스타일을 쓸 때도 흔한 오해가 있습니다.
많은 사용자가 “cinematic”, “beautiful”, “epic”, “stunning” 같은 단어를 붙이면 자동으로 결과가 고급스러워질 것이라고 생각합니다. 하지만 업로드하신 가이드에서는 이런 단어들이 오히려 결과를 흐릴 수 있다고 지적합니다. 특히 fast, epic, amazing, beautiful, stunning, lots of movement, cinematic 단독 사용 같은 표현은 화면에 무엇을 만들어야 하는지 구체적으로 알려주지 못한다고 설명합니다.
즉, 스타일은 느낌 단어가 아니라 시각 단어로 써야 합니다.
예를 들면 이런 식입니다.
soft studio key light, subtle rim light, shallow depth of field, desaturated palette, light film grain, glossy reflections on the product surface

이 문장은 실제로 화면을 바꿉니다.
빛, 심도, 색감, 질감, 반사 같은 요소를 건드리기 때문입니다.
반대로 아래 문장은 멋져 보이지만 지시력이 약합니다.
beautiful cinematic premium style

이건 스타일이 아니라 감탄문에 가깝습니다.

5. Constraints: 모델이 멋대로 하지 못하게 막는 문장이 필요하다
가이드에서 특히 중요한 부분이 Constraints입니다.
많은 사람이 프롬프트를 “하고 싶은 말”만 채우고 끝내는데, 실제로 안정성을 높이는 데 큰 역할을 하는 것은 “하지 말아야 할 것”과 “유지해야 할 것”을 분명히 적는 것입니다.
업로드하신 정리문에서도 Constraints는 모델에게 어디까지 자유롭게 해도 되는지, 무엇은 절대 바꾸면 안 되는지를 알려주는 역할이라고 설명합니다. 예시로는 얼굴 안정성 유지, morphing 없음, 흔들림 없음, 정체성 유지, 왜곡 없음, 전환 부드럽게 같은 제약이 반복해서 나옵니다.
예를 들면 이런 문장이 Constraint입니다.
10 seconds, smooth steady motion, keep face and outfit consistent, no morphing, no extra limbs, no sudden camera shake

이 문장은 화려하지 않지만 굉장히 중요합니다.
왜냐하면 Seedance가 잘못하기 쉬운 실수를 미리 막아주기 때문입니다.
좋은 프롬프트는 상상력을 자극하는 문장만 있는 프롬프트가 아니라,
실수를 방지하는 안전장치까지 포함한 프롬프트입니다.

결국 프롬프트는 “문장”이 아니라 “설계”다
여기까지를 한 문장으로 줄이면 이렇습니다.
Seedance 2.0은 좋은 문장보다 좋은 장면 설계를 더 잘 따른다.
그래서 프롬프트를 쓸 때는 문장을 잘 쓰려고 애쓰기보다, 장면을 설계해야 합니다.

누가 나오는지
무엇을 하는지
카메라는 어떻게 보는지
빛과 색은 어떤지
무엇을 절대 바꾸면 안 되는지

이 다섯 가지가 분리되어 있으면 결과가 좋아질 확률이 높아집니다.

실전 예제 1
감성적인 한국 콘서트 무대 장면 프롬프트
예를 들어 “감성적인 한국 콘서트 영상”을 만들고 싶다고 해봅시다.
많은 사람이 처음에는 이렇게 씁니다.
A beautiful emotional Korean concert with a female singer and a lot of audience, cinematic and amazing, dramatic lights, emotional mood.

이 프롬프트는 분위기만 있고 구조가 없습니다.
그래서 결과가 랜덤하게 흔들릴 가능성이 큽니다.
같은 장면을 구조적으로 다시 쓰면 이렇게 됩니다.
wide audience-facing concert shot, slow crane up from the back of the venue, 85mm telephoto compression, a Korean female singer in her early 30s standing center stage in a long black dress, holding a wireless microphone, singing steadily without exaggerated mouth visibility, thousands of audience lights filling the dark arena, soft warm spotlight on the singer, cool blue ambient light over the crowd, gentle haze in the air, slow and deliberate pacing, 10 seconds, smooth continuous motion, keep the singer identity consistent, no sudden zoom, no chaotic camera shake

이 프롬프트가 더 좋은 이유는 분명합니다.
Subject가 있고,
Action이 있고,
Camera가 있고,
Style이 있고,
Constraints가 있습니다.
즉, Seedance가 따라야 할 장면 설계도가 생긴 것입니다.

실전 예제 2
제품 광고 프롬프트는 왜 “멋지게”보다 “식별 가능하게”가 중요할까
가이드에는 제품 광고 템플릿도 포함되어 있습니다. 손에 든 제품, 깔끔한 배경, 제품을 프레임 안으로 들고 와서 살짝 회전, slow push-in, 부드러운 스튜디오 조명, 선명한 반사, 흔들림 없음, 제품 식별 가능 같은 요소가 핵심이라고 정리되어 있습니다.
이걸 바탕으로 예제를 써보면 이런 식입니다.
clean studio tabletop shot, slow push-in, 50mm lens, a premium silver cosmetic bottle placed at the center on a matte white surface, a hand enters frame from the right and gently rotates the bottle once, soft diffused studio lighting, crisp highlight reflections on the metallic surface, minimal shadow, clean luxury commercial look, 8 seconds, stable hand motion, keep product label readable, no warping, no extra objects, no background clutter

여기서 중요한 단어는 “premium”보다 “label readable”입니다.
왜냐하면 광고에서 정말 중요한 것은 제품이 예뻐 보이는 것뿐 아니라, 제품이 정확히 인식되는 것이기 때문입니다.
AI 영상에서는 멋져 보이기만 하고 정작 브랜드 식별이 안 되는 경우가 자주 나옵니다.
그래서 제품 광고 프롬프트는 감성보다 통제가 더 중요합니다.

실전 예제 3
캐릭터 퍼포먼스나 토킹헤드는 왜 정적인 카메라가 유리할까
가이드의 토킹헤드 예시에서는 얼굴 특징이 일정한 클로즈업 캐릭터, 미세한 표정 변화와 작은 손동작, locked tripod, 얕은 심도, 얼굴 안정성 유지와 morphing 없음 같은 조건이 제시됩니다.
이건 아주 현실적인 조언입니다.
얼굴이 중요한 장면일수록 카메라를 화려하게 움직이는 것보다, 오히려 정적으로 두는 편이 더 안정적입니다.
예를 들면:
close-up portrait shot, locked tripod, 85mm lens, a Korean man in his late 30s with short neatly parted hair and a dark navy shirt, looking slightly off-camera, subtle breathing, one small hand gesture near the chest, calm serious expression, soft cinematic key light from the left, shallow depth of field, neutral dark background, 6 seconds, keep facial identity stable, no morphing, no lip distortion, no sudden lighting changes

이 프롬프트는 화려하지 않습니다.
하지만 얼굴을 안정적으로 유지해야 하는 장면에서는 이런 접근이 훨씬 강합니다.

실전 예제 4
액션 장면은 빠르게가 아니라, 무엇이 빠른지를 정확히 써야 한다
fast 같은 단어를 넣는다고 했을 경우 문제가 될수 있습니다. 무엇이 빠른지 알 수 없기 때문입니다. 피사체가 빠른지, 카메라가 빠른지, 편집이 빠른지, 리듬이 빠른지 모두 다를 수 있습니다.
예를 들어 아래 프롬프트는 좋지 않습니다.
epic fast action scene, cinematic, lots of movement

반면 이렇게 쓰면 훨씬 낫습니다.
full-body tracking shot, fast dolly follow from behind, a young hero in a damaged tactical jacket sprinting through a narrow alley, sparks falling from above, cloth movement visible, urgent pace, brief glance over the shoulder once, hard white backlight mixed with red emergency flashes, 5 seconds, maintain body proportions, no limb distortion, smooth forward tracking only, no random angle changes

여기서는 “빠르다”가 아니라
누가 빠른지,
카메라가 어떻게 빠른지,
장면 안에서 어떤 요소가 따라오는지가 분명합니다.
그게 실제 차이입니다.

프롬프트를 더 잘 쓰고 싶다면, 먼저 “나쁜 프롬프트”를 고치는 훈련을 해보면 좋다
아래는 흔히 쓰는 나쁜 프롬프트와, 그것을 개선한 예시입니다.
나쁜 프롬프트
beautiful cinematic woman in rain, emotional, amazing camera, dramatic

개선 프롬프트
medium side profile shot, slow dolly follow, 50mm lens, late 20s Korean woman in a wet black trench coat, walking alone through a narrow alley in the rain, one slow glance downward, restrained sadness, cold blue streetlight with soft warm reflections from shop windows, light mist in the background, 8 seconds, smooth steady pace, keep facial features and coat consistent, no morphing, no abrupt camera shake

어떤 점이 달라졌을까요?
“beautiful”, “cinematic”, “dramatic” 같은 포장 단어가 사라졌고,
대신 샷 크기, 렌즈, 의상, 행동, 조명, 시간, 제약이 들어갔습니다.
즉, 느낌을 제거하고 장면을 넣은 것입니다.

레퍼런스를 같이 쓰면 왜 훨씬 덜 AI처럼 보일까
업로드하신 정리문에서는 좋은 결과물 대부분이 레퍼런스 중심 작업 방식에서 나온다고 설명합니다. 그 이유는 레퍼런스가 인물 정체성, 구도, 움직임 리듬, 무드를 대신 고정해주기 때문이라고 되어 있습니다. 그래서 텍스트 프롬프트는 모든 걸 새로 발명하라는 주문이 아니라, 레퍼런스를 바탕으로 이렇게 연출하라는 감독 메모가 됩니다.
이 부분은 매우 중요합니다.
예를 들어, 텍스트만으로 “한국인 남자 배우, 감성적인 콘서트 무대, 입이 잘 안 보이게”라고 쓰는 것보다,
배우 레퍼런스 이미지 1장 + 무대 레퍼런스 1장 + 조명 무드 레퍼런스 1장을 함께 넣고 텍스트로 카메라와 액션만 보정하는 편이 훨씬 안정적입니다.
왜냐하면 모델이 매번 얼굴을 새로 상상할 필요가 없어지기 때문입니다.
텍스트는 부족한 부분을 채우고,
레퍼런스는 흔들리는 축을 고정합니다.
이 조합이 가장 강합니다.

실전 팁 5가지
첫째, 프롬프트를 쓸 때는 한 문장 안에 모든 걸 욱여넣지 말고, 머릿속에서 먼저 다섯 덩어리로 분리해보는 것이 좋습니다.
누가 나오고, 무엇을 하고, 카메라가 어떻게 움직이고, 빛과 질감은 어떻고, 어떤 오류를 막아야 하는지부터 정리해야 합니다.
둘째, 행동은 하나만 크게 잡는 편이 좋습니다.
“걷기”면 걷기, “돌아보기”면 돌아보기처럼 중심 동작 하나가 분명해야 합니다.
셋째, 카메라 움직임도 하나만 고르는 편이 좋습니다.
dolly, pan, orbit, locked tripod를 한 번에 섞기보다, 생성 하나당 메인 움직임 하나가 더 안정적입니다.
넷째, 스타일은 감탄사가 아니라 픽셀 지시로 써야 합니다.
cinematic 대신 soft key light, shallow depth of field, desaturated palette, light haze처럼 실제 화면을 바꾸는 단어가 훨씬 유효합니다.
다섯째, 마지막 줄에는 반드시 제약조건을 넣는 습관을 들이는 것이 좋습니다.
keep face consistent, no morphing, no extra limbs, smooth motion, no camera shake 같은 문장은 재미없어 보여도 품질에 직접적인 영향을 줍니다.

마무리
Seedance 2.0은 “잘 쓰는 사람”보다 “잘 연출하는 사람”에게 유리하다
이 글을 한 문장으로 정리하면 이것입니다.
Seedance 2.0 프롬프트는 글쓰기보다 연출 설계에 가깝다.
길고 감성적인 설명을 잘 쓰는 사람이 꼭 좋은 결과를 얻는 것은 아닙니다.
오히려 짧더라도 누가, 무엇을, 어떻게, 어떤 카메라로, 어떤 제약 안에서 보여줄지를 분명하게 쓰는 사람이 더 안정적인 결과를 얻습니다.
주체를 고정하고, 행동을 하나로 정하고, 카메라 움직임을 하나 선택하고, 스타일을 시각 요소로 붙이고, 제약조건으로 흔들림을 막아야 한다는 점입니다. 결국 Seedance는 랜덤 생성기가 아니라, 통제 가능한 미니 촬영 현장처럼 다루는 것이 핵심입니다.


seedance 애니메이션 블록별 영상
행복한 수지아빠 — Sun, 19 Apr 2026 21:58:57 +0900
[1. Attitude Comedy CG]

아이는 놀이터 길을 따라 왼쪽에서 오른쪽으로 걸어가며, 오른손에 반쯤 먹은 샌드위치를 들고 있다. 닭 한 마리가 샌드위치를 알아차리고 몸을 낮춘 뒤 갑자기 그것을 향해 전력 질주한다. 샌드위치는 아이가 결국 그것을 던질 때까지 전체 시간 동안 분명하게 보인다. 이동 경로는 가로막히지 않으며, 길에서 미끄럼틀 쪽으로 이동한 뒤 모래놀이터 가장자리 쪽으로 이어진다. 방향 전환, 잡으려는 시도, 비틀거림, 마지막으로 놓아버리는 순간까지 모든 순간이 화면에 보인다.

더 날카로운 형태 언어, 과장된 포즈 연기, 윤기 나는 시네마틱 조명, 장난기 있는 액션 코미디의 추진력을 갖춘 고에너지 스타일라이즈드 3D 장편 애니메이션 연출을 적용한다.



 
 
[2. Family Feature CG]

아이는 놀이터 길을 따라 왼쪽에서 오른쪽으로 걸어가며, 오른손에 반쯤 먹은 샌드위치를 들고 있다. 닭 한 마리가 샌드위치를 알아차리고 몸을 낮춘 뒤 갑자기 그것을 향해 전력 질주한다. 샌드위치는 아이가 결국 그것을 던질 때까지 전체 시간 동안 분명하게 보인다. 이동 경로는 가로막히지 않으며, 길에서 미끄럼틀 쪽으로 이동한 뒤 모래놀이터 가장자리 쪽으로 이어진다. 방향 전환, 잡으려는 시도, 비틀거림, 마지막으로 놓아버리는 순간까지 모든 순간이 화면에 보인다.

둥근 비율, 읽기 쉬운 실루엣, 부드러운 글로벌 일루미네이션, 윤기 있고 만져질 듯한 재질감, 따뜻한 감정 전달력을 갖춘 가족용 장편 애니메이션 스타일의 3D 연출을 적용한다.



 
3. Fairytale Feature CG
이 블록은 동화적이고 마법적인 아름다움 쪽으로 기울어집니다.
움직임도 단순히 빠른 액션이 아니라 서정적이고 우아한 흐름으로 바뀌는 경향이 있습니다.
핵심 요소:

elegant shapes: 형태가 우아함
lyrical cloth motion: 옷감이나 머리카락 움직임이 시적임
luminous key light: 빛이 몽환적이고 아름답게 들어옴
magical atmosphere: 공간 자체가 마법처럼 느껴짐
pristine storybook finish: 동화책처럼 정돈된 마감

잘 맞는 장면:

판타지 세계
공주, 요정, 마법 숲
감성적인 오프닝
빛, 먼지, 바람이 중요한 장면

아이와 닭 추격 장면에 이걸 쓰면, 코미디보다는 동화 속 소동처럼 보일 수 있습니다.



4. Gag Comedy CG
이 블록은 12개 중에서도 가장 직접적인 만화 코미디에 가깝습니다.
리얼한 움직임보다 튀는 타이밍, 과장된 반응, 슬랩스틱이 우선입니다.
핵심 요소:

simplified forms: 형태가 단순함
saturated color: 색이 쨍함
toy-like surfaces: 장난감처럼 단순하고 깔끔한 표면
bouncy slapstick motion: 통통 튀는 코미디 모션
fast high-readability rhythm: 빠르지만 읽기 쉬운 리듬

잘 맞는 장면:

넘어짐, 미끄러짐, 부딪힘
추격전
표정이 크게 바뀌는 만화식 연기
어린이용 짧은 코미디 영상

이 블록은 닭이 샌드위치를 쫓아가는 장면과 특히 잘 맞습니다.
왜냐하면 이 장면 자체가 추격 + 실수 + 릴리즈 구조라서 슬랩스틱과 궁합이 좋기 때문입니다.



5. Painterly Prestige Fantasy Animation
이 블록은 고급 미술풍 판타지 느낌입니다.
예쁘고 감성적이지만, 단순한 귀여움보다는 회화적 깊이와 아트디렉션이 강조됩니다.
핵심 요소:

painterly surface texture: 표면이 그림처럼 보임
brush-like shading: 붓칠한 듯한 셰이딩
graphic shadow planes: 그림자가 그래픽적으로 나뉨
atmospheric depth: 안개, 거리감, 공간층이 깊음
dramatic art-directed color: 색이 매우 의도적으로 설계됨

잘 맞는 장면:

판타지 영화풍 오프닝
감정이 무거운 장면
숲, 폐허, 마법 도시
아트필름 같은 고급 연출

이 블록은 장난스러운 닭 추격 장면에는 약간 과할 수 있지만, 비주얼 테스트용으로는 매우 유용합니다.
스타일 차이가 확실히 보이기 때문입니다.



 

6. Mixed-Media Prestige Action Animation
이 블록은 회화적 재질 + 영화적 액션 드라마의 혼합형입니다.
5번보다 더 캐릭터 중심 액션에 어울립니다.
핵심 요소:

painted textures: 그린 듯한 표면
crisp silhouettes: 실루엣은 또렷함
controlled color contrast: 색 대비가 절제됨
moody cinematic lighting: 어둡고 분위기 있는 조명
character-driven intensity: 액션보다 감정이 실린 강도

잘 맞는 장면:

진지한 액션
영웅 서사
결단, 긴장, 추적
강한 감정이 들어간 캐릭터 중심 씬

닭 추격 테스트에 쓰면 원래 코미디 장면이 의외로 심각하고 영화적인 추적 장면처럼 느껴질 수 있습니다.
그래서 스타일 비교용으로 재밌는 결과가 나올 가능성이 큽니다.

7. Painterly City Fantasy Noir Animation
이 블록은 12개 중 가장 도시적이고 어두운 분위기가 강합니다.
핵심은 느와르, 그림자, 연기, 젖은 거리, 도시 판타지입니다.
핵심 요소:

illustrated textures: 일러스트풍 표면
smoky atmosphere: 연기, 안개, 탁한 공기
bold shape logic: 형태가 강하게 정리됨
graphic light-shadow separation: 명암이 강하게 갈림
dense noir mood: 무겁고 짙은 느와르 무드

잘 맞는 장면:

밤거리
탐정물
도시 판타지
네온, 비, 안개가 있는 장면

아이와 닭 추격 테스트에는 원래 놀이터가 밝은 공간이라 약간 충돌할 수 있지만, 일부러 쓰면 이상하게 진지한 느와르 코미디처럼 바뀔 수 있습니다.

8. Handcrafted Stop-Motion Fantasy
이 블록은 실제로 손으로 만든 미니어처 세트 같은 질감이 핵심입니다.
즉, 3D라도 목표는 “CG처럼 보이기”가 아니라 수공예 스톱모션처럼 보이기입니다.
핵심 요소:

tactile miniatures: 손에 잡힐 듯한 미니어처
stitched fabrics: 바느질 자국, 천 질감
carved textures: 깎아 만든 듯한 표면
moody practical light: 실제 조명을 세트에 비춘 느낌
eerie storybook charm: 약간 기묘한 동화 무드

잘 맞는 장면:

동화
어두운 판타지
인형극 같은 세계
소품, 세트 질감이 중요한 영상

이 블록은 움직임이 지나치게 부드러우면 오히려 안 맞습니다.
그래서 테스트할 때는 프레임감이 느껴지는 스톱모션 질감이 나오면 성공입니다.

9. Clay Comedy Animation
이 블록은 클레이 애니메이션의 유머와 질감을 가져옵니다.
8번이 수공예 동화라면, 9번은 더 말랑하고 유쾌한 클레이 코미디입니다.
핵심 요소:

hand-shaped plasticine textures: 손으로 빚은 점토 표면
thumbprint imperfections: 손자국 같은 불완전함
warm studio light: 따뜻한 실내 조명
playful set logic: 세트도 귀엽고 장난스러움
dry deadpan charm: 무표정한 웃김

잘 맞는 장면:

짧은 코미디
기묘한 귀여움
소품 중심 연출
촉감이 중요한 애니메이션

닭과 샌드위치라는 소재 자체가 클레이와 잘 맞습니다.
왜냐하면 음식, 동물, 추격 모두 말랑한 재질의 재미를 살리기 좋기 때문입니다.

10. Low-Poly Indie CG
이 블록은 가장 절제되고 미니멀한 스타일입니다.
복잡한 디테일보다 형태와 색 덩어리가 먼저 읽힙니다.
핵심 요소:

faceted shapes: 면이 드러나는 기하학적 형태
restrained texture detail: 텍스처를 최소화
graphic color blocking: 색을 큰 덩어리로 정리
calm indie mood: 차분하고 감성적인 인디 무드
cinematic minimalism: 최소 요소로 분위기를 만듦

잘 맞는 장면:

감성 인디 게임풍 영상
조용한 판타지
간결한 캐릭터 테스트
모바일 게임풍 스타일 검증

이 블록은 복잡한 표정 연기나 재질 테스트에는 덜 유리하지만,
실루엣과 동선이 잘 읽히는지 확인하는 용도로는 매우 좋습니다.

11. Wire-Fu Stylized CG
이 블록은 무협 영화 같은 공중 액션의 탄성이 핵심입니다.
즉, 현실적인 물리보다 멋있게 떠오르고, 멋있게 멈추고, 멋있게 착지하는 연출이 중요합니다.
핵심 요소:

clear silhouettes: 액션 중에도 자세가 잘 읽힘
elastic airborne motion: 공중 움직임이 탄력적임
exaggerated anticipation: 동작 전 예비동작이 큼
polished stunt staging: 스턴트처럼 설계된 액션
rhythmic impact clarity: 타격과 착지가 리드미컬함

잘 맞는 장면:

점프
발차기
무술 액션
영웅 등장 장면

닭 추격 장면에 쓰면 닭이나 아이의 움직임이 필요 이상으로 무협 액션처럼 멋있어질 수 있습니다.
바로 그 점 때문에 스타일 테스트용으로는 꽤 재밌습니다.

12. Retro-Futurist Animated Epic
이 블록은 옛날 사람들이 상상한 미래 같은 비주얼과 웅장한 스케일감이 핵심입니다.
즉, 단순한 미래가 아니라 복고적 곡선, 크롬, 낙관적인 미래미학입니다.
핵심 요소:

chrome curves: 반짝이는 곡선형 금속 디자인
optimistic scale: 미래에 대한 긍정적 웅장함
warm-cool contrast: 따뜻함과 차가움의 균형
sleek production design: 매끈한 설계감
polished trailer-grade spectacle: 예고편 같은 스펙터클

잘 맞는 장면:

SF 도시
미래 세계
영웅적 등장
트레일러풍 장면

놀이터 추격전에는 직접적으로 맞지는 않지만, 일부러 적용하면
장면이 미래형 애니메이션 세계의 코믹 추격극처럼 바뀔 수 있습니다.

빠르게 정리하면
코미디에 특히 잘 맞는 블록



Attitude Comedy CG




Gag Comedy CG




Clay Comedy Animation



가장 무난한 기준점



Family Feature CG



판타지 감성이 강한 블록



Fairytale Feature CG




Painterly Prestige Fantasy Animation




Handcrafted Stop-Motion Fantasy



어둡고 무드 있는 블록



Mixed-Media Prestige Action Animation




Painterly City Fantasy Noir Animation



형태 비교에 좋은 블록



Low-Poly Indie CG



액션 과장 테스트에 좋은 블록



Wire-Fu Stylized CG



스케일과 세계관 변형 테스트에 좋은 블록



Retro-Futurist Animated Epic





Seedance2로 스토리 애니메이션 제작
행복한 수지아빠 — Sun, 19 Apr 2026 17:54:56 +0900
1. 캐릭터 디자인
먼저, 우리 캐릭터를 만들어보겠습니다. 저는 두 가지 방법을 사용합니다:
a) MJ에서 캐릭터 시트를 생성
이것은 피닉스를 만들 때 제가 사용한 방법입니다:
프롬프트: 거대한 피닉스 생물의 캐릭터 시트, 사나운 괴물, 전통적인 어드벤처 캐릭터 스타일, 고도로 스타일화된, 정면 뷰, 측면 뷰, 뒷면 뷰와 측면, 정면, 뒷면 뷰의 3가지 클로즈업 포함
b) MJ에서 고품질 애니메이션 스타일의 스틸 프레임을 생성하고, Nano Banana에서 이를 기반으로 캐릭터 시트를 만듦
MJ가 무작위로 캐릭터를 상상하게 해서 여러 생성물 중에서 마음에 드는 것을 선택할 수 있습니다. 이 경우, 다른 비디오를 위한 무작위 테스트에서 MJ가 제가 아주 마음에 들어 하는 캐릭터 이미지를 생성했기 때문에, 이 비디오에 사용하기로 결정했습니다:
프롬프트: anime japanese shot, background is impasto technique and character traditiona 90 celuloid filmanime japanese shot, background is impasto technique and character traditional 90 celuloid film
그 다음, 이 이미지를 Seedream 4.5에 업로드해서 이미지로부터 캐릭터 시트를 만들었습니다.
프롬프트: 이 캐릭터의 캐릭터 시트를 고도로 스타일화된 형태로 생성, 전신 정면 뷰, 측면 뷰, 뒷면 뷰와 중립, 행복, 결의, 분노 표정의 4가지 클로즈업 포함, 흰색 배경. 100% 아트 스타일과 캐릭터 특성을 유지. 이미지 1을 참조로 사용
팁: 애니메이션 이미지를 편집하거나 생성할 때 Nano Banana, Seedream 4.5, Flux Flex/Pro/Max를 번갈아 사용합니다. Seedream 4.5는 특히 원본 아트 스타일을 존중하면서 참조로부터 이미지를 생성하는 데 탁월합니다.


2. 디자인 환경 및 아트 스타일
일반적으로 보이지 않는 어드벤처 스타일의 환경을 원했으며, 흙빛 색상과 상세한 그라데이션 그림자로 가득 찬 일러스트레이션 스타일의 많은 디테일을 포함했습니다.
제가 좋아하는 아트 스타일과 색상 팔레트를 가진 랜덤한 MJ 생성물에서 참조 이미지를 가져왔습니다.
프롬프트: 고품질 만화 패널 일러스트레이션, 고도로 스타일화된, 풀 컬러, 카메라를 직접 향한 어깨의 히어로 포즈, 움직임의 한가운데, 눈높이 카메라, 공기 중에서 움직이는 옷, 멀리서 본 와이드 샷, 캐릭터가 검을 뽑는 중
그 다음, 아트 스타일을 가진 참조 이미지를 사용하면 세팅을 생성하는 데 상세한 프롬프트가 필요하지 않았습니다—MJ의 "Image Prompts" 탭에 참조 이미지를 업로드하기만 하면 됩니다.
프롬프트: 와이드 샷, 풀 컬러 애니메이션 샷, 환경, 숲
3. Nano Banana에서 스토리보드 생성
캐릭터(들)의 참조 이미지를 업로드하고 Nano Banana Pro가 스토리보드를 생성할 수 있도록 샷 리스트를 제공하세요.
프롬프트:
액션 사쿠가 장면이 있습니다. 일본 스타일의 싸움으로, 전형적인 소년 만화 히어로인 십대 소녀가 두 마리의 거대한 새와 대결합니다. 액션은 다음과 같이 시작합니다:
1. 영웅이 공격 자세로 있는, 원근법이 많이 들어간 샷,
2. 두 마리 새의 매우 강한 전경법 샷,
3. 얼굴의 클로즈업 샷,
4. 새의 반사가 들어간 눈의 디테일 샷,
5. 소녀의 역동적인 싸움 움직임을 담은 와이드 샷,
6. 카메라를 향한 공격 샷,
7. 십대 소녀가 두 마리 새와 싸우는 와이드 샷,
8. VFX가 들어간 슬로우 모션의 타격 샷,
9. 마지막으로 소녀의 히어로 포즈와 함께 두 마리 새가 바닥에 쓰러진 장면.
이 장면의 3x3 스토리보드를 만들어 주세요. 패널은 장면의 스케치만으로, 세부 사항 없이 간단하게 그려 주세요. 매우 역동적이고 영웅적인 포즈에 많은 강조를 두고, 주인공이 매우 스타일화된 포즈를 취하는 소년 만화 스타일의 샷으로, 움직임 선이 뚜렷하고 원근법의 전경법이 강조되도록 해 주세요.
스토리보드는 세부 사항 없는 스케치여야 합니다. 이미지 1은 십대 캐릭터의 비율 참조입니다.


4. Seedance에 모든 입력 재료 제공
기본적인 장면 프롬프트를 만들고 ChatGPT나 Gemini 같은 LLM에게 Seedance용 구체적이고 상세한 프롬프트를 여러 옵션으로 생성해 달라고 요청하세요.
프롬프트: Seedance 2.0에서 애니메이션 비디오 장면을 만들고 싶습니다. 참조 이미지로 업로드된 것들이 있는데, 십대 소녀의 캐릭터 시트와 피닉스 새의 시트, 스토리보드 이미지, 그리고 숲 배경 이미지가 포함되어 있습니다. 이 장면은 일본 스타일의 모험 시리즈에서 나온 액션 장면입니다. 이미지를 분석하고 Seedance가 애니메이션 비디오를 생성할 수 있도록 프롬프트를 반환해 주세요. 배경의 예술적 스타일을 사용하고 스토리보드의 샷 구성을 엄격히 준수하는 데 중점을 두세요.
Gemini/ChatGPT가 제공한 적응된 프롬프트 옵션을 테스트하고 가장 좋은 결과를 보이는 것을 사용하세요.
최종 프롬프트:
참조를 엄격한 우선순위와 역할 분리로 사용하세요:
[REF_STORYBOARD] = "Image1" 샷 순서, 프레임, 타이밍, 구성, 장면 진행에 대한 주요 가이드. 이를 엄격히 따르세요.
[REF_GIRL_MODEL] = "Image2" 십대 소녀의 정체성 앵커.
[REF_PHOENIX_MODEL] "Image 3" 피닉스의 생물 정체성 앵커.
[REF_BACKGROUND] = "Image 4" 환경 및 숲 배경 앵커.
숲에서 십대 소녀가 두 마리의 피닉스 새와 싸우는 일본 애니메이션 액션 장면을 만드세요.
절대 우선순위:
1. 모든 샷과 장면 진행에 대해 스토리보드를 엄격히 따르세요.
2. 소녀 디자인을 [REF_GIRL_MODEL]에 고정하세요.
3. 피닉스 디자인을 [REF_PHOENIX_MODEL]에 고정하세요.
4. 숲과 길을 [REF_BACKGROUND]와 일관되게 유지하세요.


5. 여러 세대 편집하기
Seedance가 여러 컷으로 구성된 비디오를 반환하기 때문에, 일부 샷은 불일치가 있거나 다른 샷보다 더 나쁘게 보일 수 있습니다. 여러 세대를 생성한 후 각 비디오에서 마음에 드는 샷을 잘라 편집 소프트웨어에서 편집하게 됩니다.
저는 DaVinci Resolve를 사용합니다. 왜냐하면 이는 영화에서 사용되는 전문 소프트웨어이고, 무료이기 때문입니다.


출처 : https://x.com/voxelplot/status/2043645442597007721


스토리드보드로 만드는 광고 영상
행복한 수지아빠 — Sun, 19 Apr 2026 17:45:55 +0900
사용된 스토리 보드 이미지


결과



 


warrior 액션 장면 프롬프트 (Seedance2)
행복한 수지아빠 — Sun, 19 Apr 2026 13:31:49 +0900
 



 
CHARACTER REFERENCE Imagen1= warrior's face. Imagen2 = red robotic armor reference. IMAX 70mm film texture, Panavision 35mm lens, f4, handheld sway. Live-action sci-fi, 4K, shallow DOF bokeh, cold teal-blue tone, red energy sword as only warm light. Dense industrial fog. Hard cuts. SFX only, no music. Face stable, no deformation. 0-1s: CU face. Imagen1 without helmet, calm, cold blue sidelight. Camera pushes in. Red modular mechanical Imagen2Element-type full helmet (no visor) assembles around face, pieces locking precisely. Mechanical hum. 1-3s: CU hand. Right palm up, fingers spread. Red energy particles spiral inward, condensing into a sword hilt, circuit textures forming. Energy hum. 3-4s: Side CU. Hand grips hilt — red blade erupts upward, particles solidifying into translucent blade. Fully armored warrior in Imagen2Element-type red suit turns forward. Explosive hum. 4-5s: Behind MS. Warrior with sword at edge of industrial platform. Six black chitinous creatures appear in fog, red eyes glowing in pairs. Camera pulls back revealing encirclement. Shrieks. 5-6s: Low angle. Warrior combat stance. Six red eye-pairs in fog. Crane frames and cables above. Boots stamp ground. Sword hum rises. 6-7s: First creature charges. Warrior meets it — horizontal slash through midsection, creature flung 3m into railing, bending it. Red arc trail lingers. Camera side-tracks full sequence. Shell tear + metal impact sounds. 7-8s: Second creature from left — backhand slash severs forelimb, red sparks trailing. Third attacks from right — warrior spin-kicks it into the fourth, both tumble off frame. Camera orbits rapidly. Severed limb + kick impact + collision sounds. 8-9s: CU Imagen2helmet faceplate splattered with black fluid. Heavy filtered breathing. Red sword light on metallic surfaces. 9-10s: Fifth creature ambushes from behind. Warrior reverse-grips sword, thrusts backward through creature's chest, red light exits its back. Spins and flings impaled creature into the sixth. Both vanish into fog. Camera tracks fling trajectory. Piercing + screech + distant collision sounds. 10-11s: Overhead FS. Battlefield — six creatures down, missing limbs, pierced. Black fluid on metal floor, bent railings. Warrior center, sword dripping red droplets. Silence. Creaking echo, droplets hissing. 11-12s: Low CU. Red armored boots stepping through black fluid, blue-red reflections. Heavy footsteps. Metal floor begins violently trembling. Warrior stops. Camera rises to helmet. Deep tremor — massive footsteps approaching like earthquakes. 12-13s: Front MS. Warrior raises head. Two enormous red lights ignite in fog — ten times wider than creatures' eyes. Massive black silhouette emerges, head reaching crane frames, 10x warrior's size. Sword hum rises. Camera ascends revealing Boss scale. Seismic thuds, cables rattling, structures groaning. 13-14s: ECU helmet faceplate — black fluid and moisture on metallic plates. Boss reflected: massive chitinous body, four arms, pulsing dark red chest core, curved horns, burning red eyes. Camera pushes into intricate patterns. Boss steps shake platform. 14-15s: ECU helmet optical sensors. Warrior speaks one word, low, filtered through helmet speaker: "ADELANTE". Spatial reverb, metallic tone. Instantly lunges into a charge. Camera rushes forward. Frame ends in sprint motion blur. "Adelante" with reverb, sword hum erupts to max, boots pounding, Boss roar colliding with charge.
1. 프롬프트 목적
핵심 목적은 명확합니다.

주인공 얼굴은 Imagen1
갑옷 형태는 Imagen2
영상 미학은 IMAX 70mm + Panavision 35mm lens + handheld sway
톤은 cold teal-blue
유일한 따뜻한 광원은 red energy sword
15초 안에

헬멧 장착
무기 생성
적 등장
6마리 처치
보스 공개
마지막 돌진
까지 넣는 구성입니다.



즉, 이건 단순 묘사 프롬프트가 아니라 초 단위 쇼트 설계서에 가깝습니다.

2. 잘한 점
A. 캐릭터 참조 역할 분리가 좋음

Imagen1 = warrior's face
Imagen2 = red robotic armor reference

이렇게 나눠두면 모델이

얼굴은 1번에서,
갑옷 디자인은 2번에서
가져오도록 유도할 수 있어서 안정성이 높아집니다.

다만 표현은 조금 더 명확히 하면 좋습니다.
지금의 Imagen2Element-type는 다소 비표준적이라 모델이 정확히 이해 못할 수 있습니다.
더 안정적인 방식:

Use Imagen1 for face identity only
Use Imagen2 for armor design, helmet shape, and red mechanical suit details


B. 시네마 문법이 강함
좋은 키워드가 많습니다.

IMAX 70mm film texture
Panavision 35mm lens
f4
handheld sway
shallow DOF bokeh
dense industrial fog
hard cuts
SFX only, no music

이런 요소들은 영상의 재질감을 강하게 고정합니다.
특히 red energy sword as only warm light는 색 설계가 매우 좋습니다.
영상 전체 팔레트를 통제하는 데 효과적입니다.

C. 시간 분할이 매우 구체적임
0–1s, 1–3s, 3–4s처럼 잘게 나눠서
모델이 “무엇을 언제 보여줘야 하는지” 이해하기 쉽습니다.
이건 특히 영상 생성 모델에서 중요합니다.
이런 식의 분할은 다음을 줄여줍니다.

장면 누락
갑작스러운 스타일 붕괴
행동 순서 꼬임
카메라와 액션 충돌


D. 감각 정보가 풍부함
단순히 “검을 든다”가 아니라

particles spiral inward
condensing into a sword hilt
circuit textures forming
explosive hum
shell tear + metal impact
cables rattling
structures groaning

처럼 시각 + 청각 + 물성이 같이 들어가 있습니다.
그래서 장면이 더 입체적으로 느껴집니다.

3. 가장 큰 장점
이 프롬프트의 가장 큰 장점은 **“주인공을 영웅적으로 보이게 만드는 비트 설계”**입니다.
구조를 보면:

얼굴 클로즈업
헬멧 조립
검 생성
포위
전투
승리 정적
더 큰 위협 등장
한 단어 대사
돌진

이건 거의 예고편 문법입니다.
15초 안에 기원 → 능력 → 위협 → 액션 → 상위 위협 → 클리프행어가 다 들어가 있습니다.

4. 문제점도 분명히 있음
A. 15초에 정보량이 너무 많음
이게 가장 큽니다.
15초 안에 들어가는 요소:

헬멧 장착
검 생성
전체 갑옷 완성
6마리 적 등장
6마리 각각 다른 방식으로 처치
피격 표현
전장 상태
지면 진동
보스 등장
보스 디테일 반사
대사
돌진

이 정도면 사실 30~45초 분량 아이디어에 가깝습니다.
영상 생성 모델 입장에서는 이런 과밀한 구조에서 자주 생기는 문제가 있습니다.

액션 일부 생략
적 숫자 유지 실패
6마리 처치 과정이 섞임
보스 스케일 붕괴
카메라 동선 꼬임
얼굴/헬멧 일관성 손상

[Inference] 실제 생성 결과에서는 사용자가 적어둔 모든 비트를 정확히 1:1로 재현하지 못할 가능성이 높습니다. 이는 일반적인 영상 생성 모델의 장면 압축 경향에 따른 판단입니다.

B. 쇼트 타입이 너무 자주 바뀜
예시:

CU
CU hand
Side CU
Behind MS
Low angle
Side-track
Rapid orbit
Overhead FS
Low CU
Front MS
ECU
ECU sensors

15초 안에 이 정도 쇼트 전환은 매우 공격적입니다.
사람 편집자가 만든 예고편이면 가능하지만, 생성형 모델은 종종

클로즈업과 미디엄을 섞어버리거나
카메라가 점프컷처럼 튀거나
공간 연속성이 깨지는 문제

가 생깁니다.

C. “정확한 수치”가 모델에 부담을 줌
예:

six black chitinous creatures
flung 3m into railing
10x warrior's size
ten times wider than creatures' eyes

이런 수치는 사람에게는 선명하지만, 모델에게는 오히려 불안정할 수 있습니다.
더 안정적인 표현은:

surrounded by six creatures
thrown hard into a railing
towering boss, far larger than the warrior
enormous red lights much larger than the creatures' eyes

즉, 정확 수치보다 상대적 스케일이 더 잘 먹히는 경우가 많습니다.

D. 참조 이미지 연결 문법이 약간 불안정함
Imagen2Element-type full helmet 같은 표현은 다소 어색합니다.
모델이 이걸 “Imagen2의 요소를 따르는 헬멧”으로 이해할 수도 있지만, 아닐 수도 있습니다.
더 좋은 문법은:

helmet design matching Imagen2
armor silhouette and red mechanical plating based on Imagen2
preserve Imagen1 facial identity before helmet closes


E. “Face stable, no deformation”은 좋지만 충분하지 않을 수 있음
좋은 안전장치이긴 한데, 액션이 많고 헬멧 장착, 피 분사, 회전, 돌진까지 있어서
얼굴 안정성 유지가 어렵습니다.
보강 문구 예:

preserve face identity from Imagen1 across all close-ups
consistent facial proportions
no facial morphing during helmet assembly
helmet closes cleanly without warping the face


5. 이 프롬프트의 숨은 구조
이 프롬프트는 사실 4개 블록으로 나뉩니다.
블록 1. 변신

0–1s 얼굴
1–3s 손
3–4s 검 + 갑옷

블록 2. 전장 세팅

4–5s 포위
5–6s 대치

블록 3. 중간 전투

6–10s 6마리 정리

블록 4. 보스 티저

10–15s 잔해 → 진동 → 보스 → 대사 → 돌진

이 구조 자체는 아주 좋습니다.
문제는 블록 3이 너무 빽빽하다는 점입니다.

6. 생성 안정성을 높이려면 어떻게 바꿔야 하나
핵심은 세 가지입니다.
1) 적 개별 처치 묘사를 줄이기
현재는 2~3초 안에

1번 적
2번 적
3번 적
4번 적
5번 적
6번 적
이 다 들어갑니다.

이건 모델이 거의 확실히 압축합니다.
더 안정적인 방향:

“two or three rapid decisive strikes”
“multiple creatures fall in quick succession”
“brief montage of impacts, severed limbs, and bodies thrown into fog”


2) 카메라 지시를 줄이고 우선순위를 정하기
지금은 카메라가 너무 많이 바뀝니다.
핵심만 남기면 좋습니다.
예:

opening push-in
side-tracking action shot
rapid orbit for combo moment
overhead aftermath
ascending reveal for boss
final forward rush

이 정도면 충분합니다.

3) 보스 티저를 더 크게 남기고 전투를 줄이기
이 프롬프트의 진짜 킬링샷은 마지막입니다.

두 개의 거대한 붉은 눈
크레인 높이까지 오는 보스
헬멧 반사
“ADELANTE”
돌진

그래서 중간 잡몹 액션을 조금 덜어내고
보스 등장에 1초 더 주는 편이 결과물이 더 강할 가능성이 큽니다.

7. 한 줄 평가
이 프롬프트는
“비주얼 디렉팅은 매우 강하지만, 생성 모델 기준으로는 과밀하다”
라고 정리할 수 있습니다.
즉,

연출력: 높음
미장센 통제: 높음
캐릭터 브랜딩: 높음
생성 안정성: 중간
재현 가능성: 중상
정보 과밀 리스크: 높음


8. 어떤 모델에서 특히 잘 맞는 스타일인가
[Inference] 이 프롬프트는 텍스트 기반 시네마틱 영상 모델이나 샷 서술을 어느 정도 따라가는 생성기에 더 잘 맞는 구조입니다.
반면, 액션 연속성과 물리 일관성이 약한 모델에서는 다음 문제가 날 수 있습니다.

적 숫자 붕괴
팔/검/다리 왜곡
보스 스케일 불안정
검 궤적과 타격 결과 불일치

즉, 이 프롬프트는 “아이디어는 훌륭하지만, 모델이 강해야 버텨주는 타입”입니다.

9. 개선 우선순위
최우선

6마리 개별 처치 디테일 축소

그다음

카메라 지시 개수 줄이기
참조 이미지 문법 명확화
수치 표현을 상대 표현으로 바꾸기

유지해야 할 것

cold teal-blue vs red only warm light
dense industrial fog
SFX only, no music
face identity stability
final boss reveal + “ADELANTE”


10. 압축해서 평가하면
이 프롬프트는 다음 장르 문법을 섞고 있습니다.

헬멧 조립 변신
에너지 무기 생성
근접 액션 학살
다음 보스전 티저
한 단어 대사로 끝나는 트레일러 클리프행어

그래서 결과적으로 매우 강렬합니다.
다만 생성 품질을 우선하면, “잡몹전 40% 축소, 보스 티저 20% 확대”가 가장 효과적입니다


지구에서 캐릭터까지 내려오는 멋진 프롬프트
행복한 수지아빠 — Sun, 19 Apr 2026 13:25:04 +0900
 
 



 
Epic cinematic Earth zoom-in sequence starting from deep outer space. Camera begins with a majestic wide shot of planet Earth floating in the void (0-5s), then rapidly accelerates and dives toward the surface at breathtaking speed, piercing through glowing atmosphere layers, rushing clouds, and continents with dramatic motion blur, light streaks, and intense atmospheric entry glow (5-10s). The camera swiftly descends over a vast post-apocalyptic ruined cityscape filled with crumbling skyscrapers, overgrown vegetation, abandoned vehicles, broken highways, and thick dust clouds, before seamlessly entering a massive abandoned building and revealing a hidden high-tech robot workshop inside the building filled with mechanical tools, scattered robotic parts, welding sparks, glowing holographic screens, and industrial metallic surfaces. The continuous one-take camera movement gradually slows down smoothly and settles into a perfect medium shot on the main character @img1 who strikes a dynamic cool pose: aiming her hand in a finger-gun gesture directly toward the viewer as if shooting, while playfully winking one eye at the camera, with her companion robot @img2 positioned right beside her (10-15s).



@img1: primary character reference - accurate face, body, outfit, and pose as the central figure in the robot workshop.

@img2: robot companion reference - precise robot design, details, and placement immediately next to @img1.



Cinematic film color grading, heavily desaturated moody tones, cool color palette with subtle teal accents, high contrast, subtle film grain, atmospheric dust particles floating in the air, professional Hollywood sci-fi movie look. Ultra-detailed, photorealistic yet stylized, 8K quality, masterpiece.
1) 전체 프롬프트의 설계 목적
이 프롬프트의 진짜 목적은 단순히 “지구에서 캐릭터까지 내려오는 멋진 영상”이 아니라, 아래 4가지를 동시에 잡는 것입니다.

초대형 스케일감
연속 원테이크 카메라 쾌감
세계관 정보 전달
마지막 캐릭터 히어로 샷 정착

즉, 앞부분은 전부 마지막 2초의 캐릭터 샷을 더 강하게 보이게 만드는 빌드업입니다.

2) 프롬프트의 뼈대 구조
이 프롬프트는 사실상 아래 공식으로 이루어져 있습니다.
[오프닝 스케일]
→ [고속 돌입]
→ [환경 소개]
→ [목표 공간 진입]
→ [최종 피사체 정착]
→ [레퍼런스 앵커]
→ [전체 룩/색보정]
당신이 쓴 문장을 이 구조에 맞춰 분해하면 다음과 같습니다.

3) 구간별 역분석
A. 오프닝 훅

Epic cinematic Earth zoom-in sequence starting from deep outer space.

이 한 줄은 장르와 운동감을 먼저 고정합니다.

Epic cinematic: 영화적 규모, 웅장한 톤
Earth zoom-in sequence: 카메라의 핵심 액션 정의
starting from deep outer space: 시작 지점 명확화

즉, 첫 줄에서 이미 모델에게
“이건 대형 SF 영화 오프닝 같은 원테이크 하강 시퀀스다”
라고 선언한 셈입니다.

B. 시간축 기반 카메라 블로킹

Camera begins with a majestic wide shot of planet Earth floating in the void (0-5s), then rapidly accelerates and dives toward the surface at breathtaking speed...

이 부분은 아주 중요합니다.
단순 설명이 아니라 시간대별 쇼트 설계입니다.
역할

0–5초: 우주에서 지구를 보여주는 도입
5–10초: 속도감 있는 대기권 돌입
10–15초: 도시 → 건물 → 실내 → 캐릭터 정착

이렇게 되면 모델이 “무엇을 먼저 보여줘야 하는지”를 순서대로 이해하기 쉬워집니다.
왜 좋은가
긴 프롬프트일수록 모델은 종종

공간을 섞거나
순서를 무시하거나
마지막 캐릭터를 너무 빨리 보여주거나
중간 도시 묘사를 생략

하는데, 시간축을 주면 이런 붕괴를 줄이는 효과가 있습니다.

C. 속도감 보강용 시각 키워드

piercing through glowing atmosphere layers, rushing clouds, and continents with dramatic motion blur, light streaks, and intense atmospheric entry glow

이건 “무엇을 통과하는가”와 “어떤 느낌으로 보이는가”를 동시에 고정합니다.
기능 분해

glowing atmosphere layers: 대기권 시각 효과
rushing clouds: 속도 체감
continents: 스케일 유지
motion blur / light streaks: 빠른 이동의 영상 문법
atmospheric entry glow: SF스러운 열감, 진입감

즉, 카메라의 행동만 쓴 게 아니라
속도를 눈에 보이게 만드는 효과 언어를 붙인 구조입니다.

D. 중간 세계관 설명 구간

The camera swiftly descends over a vast post-apocalyptic ruined cityscape filled with crumbling skyscrapers, overgrown vegetation, abandoned vehicles, broken highways, and thick dust clouds

이 부분은 배경이 아니라 세계관 압축 설명입니다.
여기서 전달되는 정보는:

문명 붕괴
오랜 시간 방치
자연의 재침식
인간 부재
먼지와 황폐함
거대한 도시 규모

즉, “로봇 작업실” 하나만 보여주면 그냥 SF 실내일 수 있는데,
그 전에 포스트 아포칼립스 도시를 깔아줘서
마지막 작업실이 “폐허 속 숨겨진 생존 거점”처럼 느껴지게 만듭니다.

E. 핵심 전환부

before seamlessly entering a massive abandoned building and revealing a hidden high-tech robot workshop inside the building

이게 사실 이 프롬프트의 가장 중요한 브리지입니다.
왜냐하면 여기서 장면이

거시적 외부 공간
도시 상공
특정 건물
실내 워크숍
캐릭터 클로징 샷

으로 급격히 좁혀지기 때문입니다.
이런 전환은 모델이 자주 실패하는 구간입니다.
그래서 seamlessly entering 같은 단어로 컷 전환이 아니라 연속 카메라 이동임을 강조하고 있습니다.
즉, 이 문장은
“장면이 바뀌는 게 아니라 카메라가 이어서 들어간다”
를 강하게 고정하는 역할입니다.

F. 실내 세트 디테일

filled with mechanical tools, scattered robotic parts, welding sparks, glowing holographic screens, and industrial metallic surfaces

이 구간은 워크숍을 그냥 “하이테크”라고만 하지 않고,
모델이 쉽게 뽑을 수 있는 오브젝트 단위 시각 단서로 분해해 준 것입니다.
요소별 기능

mechanical tools: 작업실의 기능성
scattered robotic parts: 로봇 제작 공간임을 암시
welding sparks: 움직임, 생동감, 시네마틱 포인트
glowing holographic screens: 미래 기술감
industrial metallic surfaces: 질감 통일

좋은 프롬프트는 추상어보다
이렇게 눈에 보이는 사물 리스트를 잘 씁니다.

G. 최종 샷의 속도 제어

The continuous one-take camera movement gradually slows down smoothly and settles into a perfect medium shot

이 문장은 매우 전략적입니다.
앞부분은 엄청 빠른데, 마지막까지 빠르면

캐릭터가 안 보이거나
얼굴이 흔들리거나
포즈가 무너지거나
@img1, @img2 레퍼런스가 흐트러질 수 있습니다.

그래서 마지막에 속도를 줄여
카메라 정착 안정성을 확보하는 문장입니다.
즉, 이 프롬프트는 단순히 “멋있게”가 아니라
생성 성공률을 고려한 감속 설계가 들어가 있습니다.

H. 캐릭터 액션 고정

on the main character @img1 who strikes a dynamic cool pose: aiming her hand in a finger-gun gesture directly toward the viewer as if shooting, while playfully winking one eye at the camera, with her companion robot @img2 positioned right beside her

이 부분은 최종 목적지입니다.
여기서 고정하는 것

주인공은 @img1
로봇은 @img2
둘의 위치 관계
주인공 포즈
손 제스처
시선 방향
표정
카메라와의 인터랙션

특히 directly toward the viewer가 중요합니다.
이게 없으면 손가락 총 포즈가 옆으로 나가거나, 카메라를 안 보고 다른 곳을 볼 수 있습니다.
또 with her companion robot @img2 positioned right beside her는
로봇이 뒤에 뜨거나 멀리 배치되거나 프레임 밖으로 밀리는 문제를 줄이려는 표현입니다.

I. 레퍼런스 이미지 앵커

@img1: primary character reference - accurate face, body, outfit, and pose as the central figure in the robot workshop.
@img2: robot companion reference - precise robot design, details, and placement immediately next to @img1.

이건 거의 “생성 제어용 주석”입니다.
@img1의 기능

얼굴 유지
체형 유지
의상 유지
중심 인물 보장

@img2의 기능

로봇 디자인 유지
디테일 유지
주인공 옆 위치 유지

즉, 텍스트 본문이 서사와 카메라를 담당하고,
이 앵커 문장은 아이덴티티 보존을 담당합니다.

J. 전체 룩 고정

Cinematic film color grading, heavily desaturated moody tones, cool color palette with subtle teal accents, high contrast, subtle film grain, atmospheric dust particles floating in the air, professional Hollywood sci-fi movie look. Ultra-detailed, photorealistic yet stylized, 8K quality, masterpiece.

이 마지막 블록은 “렌더링 룩”을 덮어씌우는 구간입니다.
기능

desaturated moody tones: 채도 억제, 진지한 분위기
cool palette / subtle teal: SF 컬러 방향
high contrast: 강한 조형감
film grain: 영화 질감
dust particles: 공기감
Hollywood sci-fi movie look: 레퍼런스 무드
photorealistic yet stylized: 너무 다큐처럼도, 너무 만화처럼도 가지 않게 균형
8K / masterpiece: 품질 압박용 수식어


4) 이 프롬프트가 잘 짜인 이유
이 프롬프트의 장점은 크게 5개입니다.
1. 카메라가 주인공이다
많은 프롬프트가 배경만 길게 쓰는데, 이건 카메라 동선이 먼저입니다.
영상 모델에서는 이게 훨씬 중요합니다.
2. 시간 구간이 명확하다
0–5, 5–10, 10–15로 나눠서 모델이 흐름을 따라가기 쉽습니다.
3. 스케일 변화가 단계적이다
우주 → 지구 → 대기권 → 도시 → 건물 → 실내 → 인물
이 축소 흐름이 논리적입니다.
4. 마지막 샷이 선명하다
최종적으로 어디에 멈추는지 명확합니다.
5. 레퍼런스 이미지의 역할이 분명하다
@img1, @img2가 그냥 “참고”가 아니라
각각 어떤 요소를 유지해야 하는지 지정돼 있습니다.

5) 잠재적 문제점도 있다
좋은 프롬프트이긴 하지만, 생성 모델 입장에서는 난이도가 꽤 높습니다.
1. 너무 많은 공간 전환
우주 → 지표 → 도시 → 건물 내부 → 작업실 → 캐릭터
이걸 15초 원테이크로 완벽히 처리하는 건 모델에 따라 어렵습니다.
2. 디테일 과부하
도시 디테일도 많고 실내 디테일도 많고 캐릭터 포즈도 복잡합니다.
그래서 중간 일부가 희생될 수 있습니다.
3. 레퍼런스 충돌 가능성
“@img1의 정확한 얼굴/몸/의상/포즈 유지”와
“카메라가 초고속 원테이크로 진입”은 서로 긴장 관계가 있습니다.
보통 빠른 동선일수록 캐릭터 일관성이 흔들릴 수 있습니다.
4. finger-gun + wink는 마지막 안정 프레임이 필요
감속이 없다면 포즈나 표정이 깨질 확률이 큽니다.

6) 이 프롬프트의 핵심 공식만 뽑으면
이 프롬프트는 아래 패턴으로 재사용할 수 있습니다.
[장르/스케일 선언]

Camera begins with [초기 거시적 쇼트] (0-5s),
then [고속 이동/돌입] through [중간 레이어들] with [속도 효과] (5-10s).

The camera descends over [세계관 환경 묘사],
then seamlessly enters [목표 공간],
revealing [실내/목적지 디테일].

The continuous one-take movement gradually slows down
and settles into [최종 쇼트 사이즈]
on [주인공] performing [명확한 포즈/표정/액션],
with [동반 오브젝트/캐릭터] positioned [위치 관계].

[레퍼런스 이미지 역할 설명]

[색보정 / 질감 / 영화 룩]


7) 한 줄로 요약하면
이 프롬프트는
“거대한 우주적 스케일의 진입 쇼트”를 이용해 세계관을 깔고,
“폐허 도시 → 숨겨진 워크숍”으로 감정을 압축한 뒤,
마지막에 “레퍼런스 고정된 캐릭터 히어로 포즈”로 착지시키는
원테이크형 SF 시네마틱 프롬프트”
라고 볼 수 있습니다.

8) 더 실전적으로 보면, 이 프롬프트의 구성 요소 태그화는 이렇게 됩니다
프롬프트 기능 분류

Scene scale: outer space, Earth, continent, city, building, workshop
Camera grammar: one-take, zoom-in, dive, descend, enter, slow down, settle
Motion intensity: breathtaking speed, motion blur, light streaks, entry glow
Worldbuilding: post-apocalyptic, ruined city, overgrown vegetation, abandoned infrastructure
Set dressing: robot parts, welding sparks, holographic screens, metallic surfaces
Character anchor: @img1, @img2
Hero pose: finger-gun, wink, medium shot
Lookdev: desaturated, teal accents, high contrast, film grain, dust particles
Quality pressure words: ultra-detailed, photorealistic yet stylized, 8K, masterpiece


9) 더 좋게 다듬으려면
이 프롬프트를 더 안정화하려면 보통 아래 식으로 개선합니다.
안정화 방향

“one continuous shot”를 더 앞에 배치
도시 디테일을 약간 압축
실내 진입 직전 속도 완화 명시
최종 포즈 프레임 홀드 1~2초 암시
캐릭터 왜곡 방지 문장 추가

예를 들면 보강 포인트는 이런 식입니다.

maintain character identity consistency throughout final approach
no subject distortion, no extra characters
final frame holds steadily on the pose
robot remains clearly visible beside the character
seamless spatial continuity from exterior to interior

이런 문장은 특히 영상 생성에서 꽤 유용합니다.


Seedance2.0에 시네마틱 프롬프트 만들기 튜터리얼 #2
행복한 수지아빠 — Thu, 16 Apr 2026 15:50:02 +0900

목표 장면
최종 목표 로그라인
해 질 무렵 거대한 바위 협곡에서, 정예 몬스터 헌터가 거대한 와이번과 정면 충돌한다.
이 로그라인이 좋은 이유는 단순합니다.

주체가 분명함: 헌터 vs 와이번
공간이 강함: 바위 협곡
감정이 강함: 위협, 압도감, 결전
액션, 카메라, 물리 표현, 멀티샷까지 모두 연습 가능함


전체 튜토리얼 흐름
이 장면은 아래 순서로 설계합니다.

로그라인 고정
장르와 톤 고정
주인공 설계
적 크리처 설계
공간과 시간대 설계
액션 핵심 비트 설계
카메라 구조 설계
물리/이펙트 설계
사운드 설계
멀티샷 타임라인으로 정리
최종 프롬프트 조립
변형 테스트용 프롬프트 만들기


1단계. 로그라인 고정
먼저 “무슨 장면인지”를 한 줄로 고정합니다.
이번 장면의 로그라인
해 질 무렵 거대한 협곡에서, 정예 몬스터 헌터가 날아다니는 거대한 와이번과 맞선다.
이 단계의 목적

누가 나오는지
어디서 싸우는지
무엇이 벌어지는지

이 세 가지만 먼저 잡습니다.
1차 테스트 프롬프트
해 질 무렵의 거대한 바위 협곡. 
한 명의 정예 몬스터 헌터가 거대한 날개 달린 와이번과 맞선다. 
시네마틱, 극사실적, 다크 판타지.
https://youtu.be/l5z9jYLzrDI



 
여기서 볼 것

헌터와 와이번이 둘 다 제대로 나오는지
장소가 협곡으로 보이는지
다크 판타지 분위기가 기본적으로 잡히는지


2단계. 장르와 톤 고정
이제 이 장면의 감정과 스타일을 정합니다.
이 단계가 없으면 그냥 “판타지 몬스터 싸움” 정도로 흐려집니다.
이번 장면의 톤

장르: 오리지널 다크 판타지 액션
톤: 묵직함, 압도감, 잔혹한 생존감
레퍼런스 느낌: 고전 블록버스터 액션 에너지, 하지만 특정 IP는 아님

이 단계의 목적

세계관의 질감 고정
너무 밝거나 가벼운 액션으로 흐르는 것 방지

2차 테스트 프롬프트
기존 작품을 기반으로 하지 않은 오리지널 다크 판타지 액션 장면. 
해 질 무렵의 거대한 바위 협곡에서 한 명의 정예 몬스터 헌터가 거대한 와이번과 맞선다. 
묵직하고 위협적인 분위기, 생존을 건 결전의 느낌, 극사실적, 시네마틱.
https://youtu.be/TgYMDRrLW4g



 
여기서 볼 것

장면이 만화처럼 보이지 않는지
너무 게임 컷신처럼 가볍지 않은지
세계가 더 무겁고 진지하게 느껴지는지


3단계. 주인공 헌터 설계
좋은 액션 프롬프트는 “누가 싸우는지”가 강해야 합니다.
헌터가 흐리면 액션이 약해집니다.
이번 장면의 헌터 설계

정예 몬스터 헌터
가죽과 금속이 겹쳐진 방어구
털 망토
상처 있는 얼굴
변형 가능한 거대한 블레이드-스피어 무기

이 단계의 목적

주인공 실루엣 강화
액션 시 읽히는 캐릭터성 확보

3차 테스트 프롬프트
해 질 무렵의 거대한 바위 협곡. 
한 명의 정예 몬스터 헌터가 서 있다. 
그는 겹겹이 덧댄 가죽과 금속 갑옷, 거친 털 망토, 상처 난 얼굴을 지녔고, 
손에는 거대한 변형형 블레이드 스피어를 들고 있다. 
오리지널 다크 판타지, 시네마틱, 극사실적.
https://youtu.be/stWAxEvhk9s



 
여기서 볼 것

헌터 실루엣이 강한지
무기가 평범한 창이나 검으로 뭉개지지 않는지
인물이 ‘엘리트 사냥꾼’처럼 보이는지


4단계. 와이번 설계
다음은 적을 설계합니다.
강한 액션 장면은 적이 단순히 “큰 용”이면 약합니다.
이번 와이번 설계

거대한 비행형 와이번
박쥐 같은 강력한 날개
뿔 달린 왕관형 머리
칼날 같은 꼬리
흉터 난 비늘
지능적이고 포식자 같은 시선

이 단계의 목적

단순한 드래곤이 아니라 고유한 위협으로 보이게 만들기
액션 포인트가 보이게 만들기: 발톱, 꼬리, 날개, 머리

4차 테스트 프롬프트
거대한 날아다니는 와이번이 협곡 위에 모습을 드러낸다. 
강력한 박쥐형 날개, 뿔처럼 솟은 머리 왕관, 칼날 같은 꼬리, 
흉터 난 비늘, 사냥감을 읽는 포식자 같은 지능적인 눈빛. 
오리지널 다크 판타지, 위협적이고 압도적인 존재감, 
시네마틱, 극사실적.
https://youtu.be/Mj_Db0BPZ7A



 
여기서 볼 것

와이번이 둔한 공룡처럼 보이지 않는지
지능적인 포식자로 느껴지는지
꼬리와 날개가 전투 도구처럼 보이는지


5단계. 공간과 시간대 설계
이제 무대를 강하게 만듭니다.
공간이 약하면 액션도 평평해집니다.
이번 무대 설계

거대한 바위 협곡
부서진 돌 아치
먼지
해 질 무렵의 역광
바람이 강한 황량한 공간

이 단계의 목적

액션을 더 크게 보이게 할 공간 확보
먼지, 낙석, 역광 같은 시네마틱 재료 추가

5차 테스트 프롬프트
해 질 무렵의 거대한 바위 협곡. 부서진 고대 돌 아치들이 흩어져 있고, 
붉은 노을빛이 바위 절벽과 먼지 사이로 길게 스며든다. 
강한 바람이 협곡을 가로질러 불고, 황량하고 위험한 결전의 무대가 형성된다. 
오리지널 다크 판타지, 시네마틱, 극사실적.
https://youtu.be/3m3g_P0uAvc



 
여기서 볼 것

협곡 스케일이 충분히 크게 보이는지
해 질 무렵 역광이 살아나는지
액션이 벌어질 공간처럼 보이는지


6단계. 액션 핵심 비트 설계
이제 진짜 액션 흐름을 설계합니다.
처음부터 컷을 나누지 말고, 먼저 무슨 일이 일어나는지만 정합니다.
이번 장면의 핵심 비트

헌터가 전진한다
와이번이 착지한다
짧고 강한 근접 충돌이 벌어진다
헌터가 뛰어올라 역전의 한 방을 노린다
마지막에 둘이 숨 고르며 대치한다

이 단계의 목적

장면이 단순 나열이 아니라 이야기 흐름을 갖게 하기
액션의 상승 구조 만들기

6차 테스트 프롬프트
해 질 무렵 협곡에서 정예 몬스터 헌터가 앞으로 걸어 나간다. 
곧 거대한 와이번이 거칠게 착지하며 바위를 부수고 먼지를 폭발시키고, 
둘은 곧바로 짧고 격렬한 근접 충돌을 벌인다. 
마지막에는 헌터가 높은 바위턱에서 뛰어올라 와이번의 목을 향해 거대한 무기를 겨누고, 
이후 둘은 거친 숨을 몰아쉬며 정면으로 대치한다. 오리지널 다크 판타지 액션, 시네마틱, 극사실적.
https://youtu.be/nlfNKJq8TwY



 
여기서 볼 것

액션 흐름이 단계적으로 보이는지
한 장면 안에서도 상승 구조가 느껴지는지
너무 난잡하지 않은지


7단계. 카메라 구조 설계
이제 멀티샷 언어를 붙입니다.
이 장면은 컷 전환이 많을수록 좋지만, 무질서하면 안 됩니다.
이번 카메라 구조

시작: 와이드 establishing
중간: 미디엄 와이드 트래킹
충돌: 빠른 클로즈업과 와이드 교차
하이라이트: 영웅적 오빗샷
끝: 대치 클로즈업

이 단계의 목적

액션이 읽히게 만들기
스케일, 속도, 감정 클로즈업을 분리하기

7차 테스트 프롬프트
와이드 establishing shot으로 시작한다. 
해 질 무렵의 거대한 협곡을 천천히 내려다보며 먼지와 부서진 돌 아치를 보여준다. 
이후 미디엄 와이드 트래킹샷으로 헌터가 전진하는 모습을 잡고, 
와이번이 착지하는 순간 빠른 클로즈업과 와이드샷을 번갈아 사용해 충돌의 충격을 강조한다. 
이어서 영웅적인 오빗샷으로 헌터의 점프 공격을 보여주고, 
마지막은 거친 숨을 몰아쉬는 둘의 대치 클로즈업으로 끝난다. 초시네마틱, 극사실적.
https://youtu.be/rBYwgyMBE7E



 
여기서 볼 것

컷 구조가 실제로 분리되어 보이는지
하이라이트 컷이 살아나는지
액션이 읽히는지, 아니면 혼잡한지


8단계. 물리와 이펙트 설계
이 장면은 물리감이 매우 중요합니다.
먼지, 낙석, 꼬리 휩쓸기, 날개 압력, 착지 충격이 살아야 합니다.
이번 물리/이펙트 요소

발톱 착지 시 바위 부서짐
날개 압력으로 파편과 먼지 폭발
무기 끌리며 불꽃 발생
꼬리가 카메라 옆을 스쳐 지나감
돌과 흙이 튀고 재가 떠다님
노을 역광 + 볼류메트릭 먼지

이 단계의 목적

“그냥 모션만 빠른 액션”이 아니라 충격이 느껴지는 액션 만들기

8차 테스트 프롬프트
거대한 와이번이 착지하는 순간 발톱이 바위를 짓뭉개고, 날개가 크게 퍼지며 먼지와 파편을 사방으로 폭발시킨다. 헌터의 무기는 땅을 끌며 불꽃을 튀기고, 꼬리가 카메라 옆을 스쳐 지나가며 돌과 흙이 흩어진다. 공기에는 재와 먼지가 떠다니고, 해 질 무렵의 강한 역광이 연기와 먼지 사이를 가르며 들어온다. 강한 물리감, 다크 판타지 액션, 초시네마틱, 극사실적.

https://youtu.be/_WU61knqrLU



 
여기서 볼 것

충격이 실제처럼 느껴지는지
파편과 먼지 표현이 과장만 되고 붕 뜨지 않는지
무기/꼬리/날개가 전부 물리적 무게를 갖는지


9단계. 사운드 설계
이제 사운드를 붙이면 장면이 완성됩니다.
이번 사운드 설계

주요 소리: 와이번의 착지 충돌음
보조 소리: 날개 압력과 먼지 폭발
보조 소리: 금속 마찰, 무기 충돌음
마무리 소리: 거친 숨소리, 바람

9차 테스트 프롬프트
거대한 협곡에서 와이번이 착지할 때 거대한 충돌음이 울리고, 날개가 공기를 후려치며 먼지와 파편이 폭발하는 소리가 터진다. 헌터의 무기가 바위 바닥을 긁으며 금속성 마찰음과 불꽃을 만들고, 짧고 강한 충돌마다 날카로운 타격음이 섞인다. 마지막 대치 순간에는 거친 숨소리와 협곡을 가르는 바람만 남는다. 초시네마틱 다크 판타지 액션, 극사실적.

https://youtu.be/zyutU9CdhLs



 
여기서 볼 것

사운드가 액션의 무게를 키우는지
소리가 장면을 과장만 하지 않는지
마지막 정적이 긴장감을 남기는지


10단계. 멀티샷 타임라인으로 정리
이제 위 요소를 시간 구조로 고정합니다.
이번 13.5초 구조

0–2.5초: 협곡과 헌터 소개
2.5–4.5초: 와이번 착지
4.5–8.5초: 빠른 근접 충돌
8.5–11.5초: 영웅적 점프/오빗샷
11.5–13.5초: 대치 클로즈업

10차 테스트 프롬프트
[0-2.5초]: 와이드 establishing shot, 해 질 무렵의 거대한 바위 협곡을 천천히 크레인 다운으로 내려다본다. 먼지가 부서진 돌 아치 사이를 휘감고, 정예 몬스터 헌터가 앞으로 걸어 나오며 무기를 땅에 끌어 불꽃을 만든다.

[2.5-4.5초]: 미디엄 와이드 트래킹샷, 거대한 와이번이 협곡 바닥에 거칠게 착지한다. 발톱이 바위를 부수고, 날개가 공기를 후려치며 파편과 먼지를 바깥으로 폭발시킨다.

[4.5-8.5초]: 빠른 클로즈업과 와이드샷 교차. 헌터가 전력 질주해 휩쓸리는 발톱 아래로 미끄러져 들어가고, 날카로운 충격과 함께 전진한다. 와이번은 반동으로 몸을 젖히고, 꼬리가 카메라 옆을 스치며 돌과 재가 프레임 안으로 터진다.

[8.5-11.5초]: 영웅적인 오빗샷. 헌터가 부서진 바위턱에서 뛰어올라 망토를 거칠게 휘날리며, 거대한 블레이드 스피어를 와이번의 목 쪽으로 겨눈다. 와이번은 공중에서 몸을 비틀며 거대한 날개를 힘껏 친다.

[11.5-13.5초]: 극적인 대치 클로즈업. 둘 다 거친 숨을 몰아쉬고, 강한 눈맞춤을 유지한다. 노을빛 림라이트, 떠다니는 재, 찢어진 대지, 깊은 심도, 초시네마틱, 극사실적.

여기서 볼 것

컷 전환이 명확한지
액션의 속도 조절이 좋은지
마지막 대치가 진짜 피날레처럼 느껴지는지


11단계. 최종 완성 프롬프트
이제 위 모든 것을 합쳐서 완성형 시네마틱 프롬프트로 만듭니다.
최종 완성 프롬프트
기존 작품을 기반으로 하지 않은 오리지널 다크 판타지 액션 장면. 해 질 무렵의 거대한 바위 협곡 안에서, 겹겹이 덧댄 가죽과 금속 갑옷, 거친 털 망토, 상처 난 얼굴을 지닌 고독한 정예 몬스터 헌터가 거대한 비행형 와이번과 맞선다. 헌터는 거대한 변형형 블레이드 스피어를 들고 있다. 와이번은 강력한 박쥐형 날개, 뿔처럼 솟은 머리 왕관, 칼날 같은 꼬리, 흉터 난 비늘, 포식자 같은 지능을 지녔다.

[0-2.5초]: 와이드 establishing shot, 느린 크레인 다운으로 협곡을 내려다본다. 먼지가 부서진 돌 아치 사이를 지나가고, 헌터가 앞으로 걸어 나오며 무기를 땅에 끌어 불꽃을 만든다.

[2.5-4.5초]: 미디엄 와이드 트래킹샷, 와이번이 거칠게 착지한다. 발톱이 바위를 부수고, 날개가 공기를 후려쳐 파편과 먼지를 폭발시킨다.

[4.5-8.5초]: 빠른 클로즈업과 와이드샷 교차. 헌터가 전력 질주해 휩쓰는 발톱 아래로 미끄러지고, 날카로운 운동 에너지와 함께 전진한다. 와이번은 반동으로 몸을 젖히고, 꼬리가 카메라 옆을 스치며 돌과 재가 프레임 안으로 폭발한다.

[8.5-11.5초]: 영웅적인 오빗샷. 헌터가 부서진 바위턱에서 뛰어올라 망토를 거칠게 휘날리며, 무기를 와이번의 목으로 뻗는다. 와이번은 공중에서 몸을 비틀고 거대한 날개를 힘껏 친다.

[11.5-13.5초]: 극적인 대치 클로즈업. 둘 다 거친 숨을 몰아쉬고, 강한 눈맞춤을 유지한다. 노을빛 림라이트, 떠다니는 재, 찢어진 대지, 깊은 심도, 초시네마틱 블록버스터, 극사실적 8K, 80~90년대 액션 영화 에너지, 다양한 카메라 앵글과 샷 전환, 볼류메트릭 연기와 먼지 효과, 강한 역광, 비정상적 왜곡 없는 정상 비율.


12단계. 변형 테스트 프롬프트
완성 프롬프트만 쓰지 말고, 아래처럼 요소별로 비교 테스트하면 훨씬 빨리 늡니다.
변형 A. 카메라 강조 버전
오리지널 다크 판타지 액션 장면. 거대한 협곡의 전투를 더 과감한 카메라 문법으로 표현한다. 느린 크레인 다운, 빠른 핸드헬드 느낌의 충돌 클로즈업, 과장된 오빗샷, 낮은 로우앵글, 빠른 샷 전환으로 헌터와 와이번의 충돌을 더 격렬하게 보여준다. 극사실적, 초시네마틱.

변형 B. 물리/먼지 강조 버전
오리지널 다크 판타지 전투 장면. 와이번 착지의 충돌, 바위 파괴, 날개 압력, 먼지 폭발, 불꽃, 낙석, 꼬리 휩쓸기, 재와 흙 입자, 볼류메트릭 먼지 효과를 강하게 강조한다. 액션의 모든 충격이 무겁고 현실적인 물리감으로 느껴지도록 한다. 극사실적, 초시네마틱.

변형 C. 영웅적 피날레 강조 버전
오리지널 다크 판타지 액션 장면. 전투 중반의 빠른 충돌보다 후반의 영웅적인 점프와 공중 대치를 더 강조한다. 해 질 무렵의 강한 역광, 휘날리는 망토, 와이번의 거대한 날개, 떠다니는 재와 먼지, 마지막 눈맞춤을 중심으로 블록버스터 피날레처럼 연출한다. 극사실적, 초시네마틱.


이 튜토리얼의 핵심
이걸 익히면 시네마틱 프롬프트를 만들 때 항상 아래 순서로 생각하게 됩니다.

로그라인
톤
캐릭터
적
공간
액션 비트
카메라
물리/이펙트
사운드
타임코드
최종 조립

즉, 멋있는 문장을 한 번에 쓰는 훈련이 아니라,
영화를 설계하듯 프롬프트를 쌓아 올리는 훈련입니다.


Seedance를 위한 프롬프트 설계 튜터리얼 #1
행복한 수지아빠 — Thu, 16 Apr 2026 09:47:54 +0900
핵심은 단순히 최종 프롬프트 하나를 주는 게 아니라,

왜 이 단계를 하는지
이 단계에서 무엇을 확인해야 하는지
실제로 어떤 프롬프트를 넣어 테스트하면 되는지
다음 단계에서 무엇을 추가해야 하는지

이 흐름을 따라가게 만드는 것입니다.
최종 프롬프트 미리보기
시네마틱하고 하이퍼리얼한 서스펜스 장면을 만들어줘. 배경은 비 오는 밤의 좁은 네온 골목이다. 검은 코트를 입은 한 여성이 골목을 천천히 걸어 들어오다가, 누군가를 기다리는 듯 멈춰 선다. 감정의 중심은 긴장감이다. 그녀는 편하게 서 있는 것이 아니라, 경계하고 있고, 불안하며, 주변을 조용히 살피고 있어야 한다.

핵심 비주얼 포인트:

젖은 아스팔트 위로 길게 번지는 빨간색과 파란색 네온 반사
검은 코트를 입은 여성의 실루엣
비와 습기로 가득한 골목 공기, 빛나는 간판 조명, 축축한 벽면

이 장면은 처음에는 그녀가 그저 스쳐 지나가는 행인처럼 보이게 시작해야 한다. 하지만 점점 그녀가 이 장면의 진짜 중심 인물임이 드러나야 한다. 즉, 누군가를 기다리고 있고, 긴장한 채 주변을 살피며, 감정적으로 무게를 지닌 인물처럼 보여야 한다.

[0–4초]
와이드 establishing shot.
비 오는 밤의 좁은 네온 골목. 빨간색과 파란색 네온사인이 젖은 아스팔트 위로 길게 반사된다. 축축한 벽, 안개처럼 흐린 습기 어린 공기, 가늘게 내리는 비가 차갑고 불안한 도시 분위기를 만든다. 공간을 가득 채우는 것은 빗소리다.

[4–8초]
미디엄 와이드 트래킹 샷.
검은 코트를 입은 여성이 골목 안으로 천천히 걸어 들어온다. 카메라는 측면에서 그녀를 따라가며 조심스러운 걸음, 반짝이는 젖은 바닥, 물기 어린 발소리, 뚜렷한 실루엣을 담아낸다. 멀리서 차량 소리가 희미하게 들린다.

[8–12초]
슬로우 푸시 인 클로즈 샷.
그녀가 멈춰 선다. 카메라는 천천히 가까이 다가가며, 누군가를 기다리듯 주변을 살피는 그녀의 긴장된 표정과 불안한 눈빛을 강조한다. 차가운 네온빛이 그녀의 얼굴, 젖은 머리카락, 코트의 가장자리에 반사된다. 금방 무언가 일어날 것 같은 분위기가 감돈다.

[12–15초]
타이트한 감정 클로즈업.
그녀는 그대로 멈춰 선 채 조용히 기다린다. 대사는 없다. 들리는 것은 빗소리, 젖은 공간의 잔잔한 주변음, 멀리서 들려오는 차량 소리, 희미한 네온 전기음뿐이다. 그녀의 표정에는 긴장과 불확실성이 남아 있다. 결말은 해소되지 않은 서스펜스로 끝난다.

카메라
시작은 와이드 샷, 그녀가 걸을 때는 측면 트래킹의 미디엄 와이드, 멈춘 뒤에는 천천히 푸시 인. 움직임은 매끄럽고 절제되어 있어야 하며, 오직 긴장감을 쌓는 방향으로만 진행된다.

조명과 분위기
밤비, 빨간색과 파란색 네온을 주요 광원으로 사용. 젖은 바닥과 축축한 벽에 강한 반사가 살아 있어야 한다. 차갑고 깊은 그림자, 도시적이고 서스펜스적인 무드. 로맨틱한 분위기는 피한다.

사운드
계속되는 빗소리, 또렷한 젖은 발소리, 멀리서 희미하게 들리는 차량 소리, 미세한 네온 전기음. 사운드는 비어 있고 절제되어 있으며, 시끄럽지 않아야 한다.

연기
등장인물은 여성 한 명뿐. 그녀는 천천히 걷다가 멈춘다. 몸짓과 자세에서는 경계심 어린 기대감이 느껴져야 한다. 길을 잃고 서 있는 것이 아니라, 분명 누군가를 기다리는 사람처럼 보여야 한다.

스타일
시네마틱, 하이퍼리얼, 디테일한 도시의 밤 공기, 선명한 실루엣 가독성, 젖은 질감, 반사되는 표면, 습기 어린 공기, 현실감 있는 감정 표현, 서스펜스 톤, 8K 디테일.

피해야 할 요소
여러 명의 주요 인물, 로맨스 분위기, 군중, 액션 장면, 코미디, 판타지풍, 밝고 경쾌한 도시 분위기, 불필요한 핸드헬드 흔들림, 편안하거나 여유로운 표정
https://youtu.be/CPlAGCmVuZ0




튜토리얼 주제
한 줄 로그라인
비 내리는 네온 골목에서 한 여성이 멈춰 서서 누군가를 기다린다.
이 로그라인을 고른 이유는 좋습니다.

인물 중심 장면이라 복잡하지 않음
분위기, 감정, 카메라, 사운드를 모두 연습하기 좋음
단일 장면으로도 가능하고 멀티샷 확장도 가능함
Seedance 2.0 스타일 테스트에 잘 맞음


전체 목표
이 로그라인을 가지고 아래 순서로 갑니다.

로그라인 고정
감정 고정
시각 요소 고정
행동과 변화 고정
카메라 설계
조명과 분위기 설계
사운드 설계
단일 장면 프롬프트 완성
멀티샷 프롬프트 확장
변형 테스트 프롬프트 만들기


1단계. 로그라인을 장면 문장으로 고정하기
현재 로그라인
비 내리는 네온 골목에서 한 여성이 멈춰 서서 누군가를 기다린다.
지금 단계에서는 아직 멋있게 쓰려 하지 않습니다.
먼저 장면의 기본 골격만 고정합니다.
이 단계에서 정할 것

주체: 한 여성
장소: 비 내리는 네온 골목
핵심 행동: 걷다가 멈춘다
상태: 누군가를 기다린다

이 단계의 목적
모델이 누가 / 어디서 / 무엇을 하는지를 정확히 이해하는지 확인
1차 테스트 프롬프트
비 내리는 네온 골목. 한 여성이 골목 안을 천천히 걸어오다가 멈춰 선다. 
그녀는 누군가를 기다리는 듯 주변을 바라본다. 시네마틱, 극사실적.
https://youtu.be/_ukbB13VjE4



 
여기서 볼 것

인물이 한 명으로 명확하게 나오는지
골목 분위기가 잡히는지
걷다가 멈추는 행동이 보이는지
“기다리는 느낌”이 어느 정도 전달되는지

이 단계에서 흔한 문제

인물이 여러 명 나옴
그냥 걷기만 하고 멈추지 않음
장소가 골목이 아니라 큰 거리처럼 나옴
“기다림”이 아니라 그냥 산책처럼 보임


2단계. 핵심 감정 하나 고정하기
지금 장면은 감정이 아직 열려 있습니다.
이 장면의 중심 감정을 하나 고르겠습니다.
선택 감정
긴장
이유:

“누군가를 기다린다”는 상황과 잘 맞음
비, 네온, 밤 골목과도 잘 맞음
카메라와 사운드 설계에 힘을 줌

이 단계에서 바뀌는 것
이제부터 이 장면은 단순한 대기가 아니라
긴장감 있는 기다림이 됩니다.
2차 테스트 프롬프트
비 내리는 네온 골목. 한 여성이 천천히 걸어오다가 멈춰 선다. 
그녀는 누군가를 기다리는 듯 긴장한 표정으로 주변을 살핀다. 
젖은 바닥 위로 네온빛이 번지고, 차가운 공기와 불안한 정적이 감돈다. 
시네마틱, 극사실적.
https://youtu.be/_f86fnEOToU



 
여기서 볼 것

표정이 바뀌는지
분위기가 단순 야경이 아니라 긴장감 있게 느껴지는지
인물의 자세나 시선이 불안정하게 잡히는지

포인트
이 단계에서는 아직 카메라를 세게 넣지 않습니다.
먼저 감정만 추가했을 때 얼마나 달라지는지 보는 단계입니다.

3단계. 핵심 시각 요소 3개 고정하기
좋은 장면은 추상적이지 않고, 눈에 보이는 앵커가 있어야 합니다.
이 장면의 핵심 시각 요소 3개를 정하겠습니다.
시각 요소 3개

젖은 아스팔트 위 네온 반사
검은 코트 실루엣
빗물 맺힌 골목 공기와 간판 빛

이 3개가 이 장면의 화면 정체성입니다.
3차 테스트 프롬프트
비 내리는 좁은 네온 골목. 
젖은 아스팔트 위로 붉고 푸른 네온빛이 길게 반사된다. 
검은 코트를 입은 한 여성이 골목 안을 천천히 걸어오다가 멈춰 선다. 
빗물이 공기 중에 떠 있고, 축축한 골목 벽과 간판 빛이 그녀의 실루엣을 드러낸다. 
그녀는 긴장한 채 누군가를 기다리는 듯 서 있다. 
시네마틱, 극사실적, 디테일한 도시 야간 분위기.
 
https://youtu.be/2y7pS_fmkGU



 



 
여기서 볼 것

네온 반사가 실제로 강하게 보이는지
검은 코트 인물이 배경에 잘 묻히지 않고 실루엣으로 살아나는지
골목의 습기와 비의 질감이 표현되는지

이 단계의 핵심
이제 장면이 더 구체적인 “그림”으로 바뀝니다.
이전까지는 상황 설명이었다면, 이제부터는 화면 설계입니다.

4단계. 주요 행동 1개와 장면 변화 1개 정하기
영상은 정지 이미지가 아니기 때문에,
장면 안에서 작은 변화가 있어야 합니다.
주요 행동
천천히 걸어오다가 멈춘다
장면 변화
지나가는 인물처럼 보이던 상태 → 기다리는 주인공처럼 부각되는 상태
이 변화가 중요합니다.
장면의 시작과 끝이 달라져야 영상이 됩니다.
4차 테스트 프롬프트
비 내리는 좁은 네온 골목. 
검은 코트를 입은 한 여성이 골목 끝에서 천천히 걸어온다. 
처음에는 도시 속을 지나가는 인물처럼 보이지만, 
그녀가 멈춰 서는 순간 긴장한 표정과 시선이 강조되며 누군가를 기다리는 주인공처럼 느껴진다. 
젖은 아스팔트 위 네온 반사, 빗물 어린 공기, 차가운 간판 불빛. 시네마틱, 극사실적.
https://youtu.be/Zqj9KJM2SOo



 
여기서 볼 것

“걸어온다 → 멈춘다”의 변화가 있는지
멈춘 후 인물의 존재감이 커지는지
그냥 배경 속 인물이 아니라 장면 중심 인물처럼 보이는지


5단계. 카메라 설계하기
이제 카메라를 넣습니다.
카메라는 멋있어서 넣는 것이 아니라 감정을 전달하기 위해 넣습니다.
이번 장면의 카메라 설계

샷 크기: 미디엄 와이드로 시작
위치: 골목 측면 또는 약간 앞쪽
움직임: 처음엔 옆으로 따라가다가, 멈추는 순간 천천히 가까워짐
이유:

걸을 때는 흐름을 보여주고
멈춘 뒤에는 긴장을 강조하기 위해



5차 테스트 프롬프트
비 내리는 좁은 네온 골목. 
카메라는 검은 코트를 입은 한 여성을 옆에서 따라가며 그녀가 천천히 걸어오는 모습을 미디엄 와이드샷으로 보여준다. 
그녀가 멈춰 서는 순간 카메라는 천천히 더 가까워지며 긴장한 표정과 시선을 강조한다. 
젖은 아스팔트에는 붉고 푸른 네온빛이 길게 반사되고, 빗물 어린 공기와 차가운 간판 조명이 그녀의 실루엣을 감싼다. 
누군가를 기다리는 긴장감 있는 분위기, 시네마틱, 극사실적, 8k.
https://youtu.be/xk415thzuQw



 
여기서 볼 것

걸을 때 카메라가 따라가는지
멈춘 순간 가까워지는 변화가 있는지
카메라 움직임이 감정과 맞는지
너무 과하게 흔들리거나 부자연스럽지 않은지


6단계. 조명과 분위기 설계하기
이제 장면의 조명 문법을 고정합니다.
조명/분위기 설계

시간대: 비 오는 밤
광원: 붉은색과 푸른색 네온
그림자: 차갑고 젖은 그림자
전체 톤: 도시적, 차가움, 불안감

6차 테스트 프롬프트
비 내리는 밤의 좁은 네온 골목. 
붉고 푸른 네온 간판 빛이 젖은 아스팔트와 골목 벽면에 차갑게 반사된다. 
검은 코트를 입은 한 여성이 골목을 천천히 걸어오고, 카메라는 옆에서 따라간다. 
그녀가 멈춰 서는 순간 카메라는 천천히 가까워지며 불안한 시선과 긴장한 표정을 드러낸다. 
차가운 네온 조명, 축축한 공기, 깊은 그림자, 불안한 도시 밤의 분위기. 
시네마틱, 극사실적, 8k.
https://youtu.be/D2JQfF-jGWw



 
여기서 볼 것

색감이 의도대로 차갑게 가는지
네온 조명이 인물과 바닥에 잘 반사되는지
장면이 로맨틱이 아니라 긴장감 있게 보이는지


7단계. 사운드 설계하기
Seedance류 모델에서는 사운드가 중요하므로
지금부터는 사운드도 구조적으로 넣습니다.
사운드 설계

주요 소리 1개: 빗소리
보조 소리 1개: 젖은 바닥을 밟는 발걸음
보조 소리 1개: 멀리서 지나가는 차량의 희미한 소리

이 조합이 좋습니다.
골목의 외로움과 긴장을 같이 만듭니다.
7차 테스트 프롬프트
비 내리는 밤의 좁은 네온 골목. 
붉고 푸른 네온 간판 빛이 젖은 아스팔트와 골목 벽에 차갑게 번진다. 
검은 코트를 입은 한 여성이 골목을 천천히 걸어오고, 카메라는 옆에서 따라간다. 
그녀가 멈춰 서는 순간 카메라는 천천히 더 가까워지며 긴장한 표정과 누군가를 기다리는 시선을 강조한다. 
빗소리가 지속적으로 들리고, 젖은 바닥을 밟는 발걸음 소리가 또렷하게 울리며, 
멀리서 지나가는 차량 소리가 희미하게 섞인다. 
차갑고 불안한 도시 밤의 분위기, 시네마틱, 극사실적, 8k.
 
https://youtu.be/-1oauJSA05M






 
여기서 볼 것

소리가 장면을 살리는지
발걸음이 타이밍과 맞는지
멀리서 나는 소리가 공간감을 주는지
사운드가 너무 많아 산만하지 않은지


8단계. 단일 장면용 완성 프롬프트 만들기
이제 지금까지의 설계를 한데 묶어서
단일 연속숏용 완성 프롬프트로 정리합니다.
단일 장면 완성 프롬프트
비 내리는 밤의 좁은 네온 골목. 
붉고 푸른 네온 간판 빛이 젖은 아스팔트와 축축한 골목 벽에 길게 반사된다. 
검은 코트를 입은 한 여성이 골목 안을 천천히 걸어오고, 
카메라는 그녀를 옆에서 따라가는 미디엄 와이드샷으로 움직인다. 
그녀가 멈춰 서는 순간 카메라는 천천히 더 가까워지며 긴장한 표정과 누군가를 기다리는 불안한 시선을 강조한다. 
빗물 어린 공기, 차가운 그림자, 선명한 실루엣, 도시의 축축하고 불안한 밤 분위기. 
지속적인 빗소리, 젖은 바닥을 밟는 발걸음, 멀리서 지나가는 차량 소리가 공간감을 만든다. 
긴장감 있는 시네마틱 장면, 극사실적, 8k.
https://youtu.be/GDVCZR_pGQQ



 
이 프롬프트의 역할
이건 지금까지 만든 설계를 가장 안정적으로 묶은 버전입니다.
먼저 이걸 돌려본 다음, 문제를 확인하고 멀티샷으로 넘어가는 것이 좋습니다.

9단계. 멀티샷 15초 버전으로 확장하기
이제 같은 장면을 멀티샷 구조로 확장해보겠습니다.
멀티샷 구성

0–4초: 공간과 인물 소개
4–8초: 걷는 흐름
8–12초: 멈춤과 긴장 강조
12–15초: 기다리는 감정 마무리

멀티샷 튜토리얼 프롬프트
[0-4초]: 
와이드 establishing shot, 
비 내리는 밤의 좁은 네온 골목. 붉고 푸른 네온빛이 젖은 아스팔트 위로 길게 반사되고, 
축축한 골목 벽과 간판이 차가운 도시 분위기를 만든다. 
빗소리가 공간을 채운다.

[4-8초]: 
미디엄샷, 검은 코트를 입은 한 여성이 골목 안을 천천히 걸어온다. 
카메라는 인물을 옆에서 따라가며 젖은 바닥 위 발걸음과 흔들리는 실루엣을 보여준다. 
멀리서 차량 소리가 희미하게 들린다.

[8-12초]: 
클로즈업으로 천천히 전환, 
그녀가 멈춰 서는 순간 카메라가 가까워지며 긴장한 표정과 주변을 살피는 시선을 강조한다. 
차가운 네온빛이 얼굴 윤곽과 젖은 머리카락에 반사된다.

[12-15초]: 
타이트한 클로즈업 또는 감정 강조 컷, 
그녀는 아무 말 없이 누군가를 기다리며 서 있고, 
빗소리와 도시의 먼 소리만 남는다. 
불안하고 긴장감 있는 정적. 시네마틱, 극사실적, 8k.
https://youtu.be/KpJRjefNTyE



 
여기서 볼 것

컷이 분명히 나뉘는지
와이드 → 미디엄 → 클로즈업 흐름이 자연스러운지
감정이 후반으로 갈수록 더 진해지는지


10단계. 테스트용 변형 프롬프트 만들기
이제부터는 이 장면을 기반으로
무엇이 가장 잘 먹는지 비교 테스트를 할 수 있게 변형을 만듭니다.

변형 A. 카메라 강조 테스트
카메라 차이만 보고 싶을 때
비 내리는 밤의 좁은 네온 골목. 
붉고 푸른 네온빛이 젖은 아스팔트에 반사된다. 
검은 코트를 입은 한 여성이 천천히 걸어오다가 멈춰 선다. 
카메라는 그녀를 정면에서 아주 천천히 돌리 인하며 따라가고, 
멈춰 서는 순간 긴장한 표정과 눈빛을 강조한다. 
빗소리, 젖은 발걸음, 멀리서 지나가는 차량 소리. 차갑고 불안한 도시 밤 분위기, 시네마틱, 극사실적, 8k.
https://youtu.be/R0G66imc81A



 
비교 포인트

옆 추적샷보다 정면 돌리 인이 더 긴장을 주는지
감정 전달이 더 강해지는지


변형 B. 조명/분위기 강조 테스트
분위기만 바꾸고 싶을 때
안개 섞인 비가 내리는 밤의 도시 골목길. 
보라색과 청록색 네온빛이 젖은 아스팔트와 벽면에 부드럽게 번진다. 
검은 코트를 입은 한 인물이 천천히 걸어오다 잠시 멈춰 선다. 
카메라는 인물을 옆에서 부드럽게 따라가며 자연스럽게 장면을 담는다. 
차가운 안개, 흐릿한 간판빛, 젖은 공기, 몽환적이고 차분한 도시 밤의 분위기. 
잔잔한 빗소리와 희미한 도시 배경음. 시네마틱, 극사실적, 고급 영화 같은 질감.
https://youtu.be/5RvZSLJ4zWI



 
비교 포인트

원본보다 더 느와르 같은지, 더 몽환적인지
긴장이 줄고 스타일성이 강해지는지


변형 C. 사운드 강조 테스트
사운드 반응을 보고 싶을 때
비 내리는 밤의 좁은 네온 골목. 붉고 푸른 네온빛이 젖은 바닥 위로 길게 번진다. 검은 코트를 입은 한 여성이 골목을 천천히 걸어오다가 멈춰 선다. 카메라는 그녀를 옆에서 따라가다 멈추는 순간 천천히 가까워진다. 강하게 들리는 빗소리, 젖은 바닥을 누르는 발걸음, 멀리서 미끄러지듯 지나가는 차량의 소리, 간판 전기음의 희미한 웅웅거림이 긴장감을 키운다. 차갑고 불안한 도시 밤, 시네마틱, 극사실적, 8k.

https://youtu.be/_cCd5QfLRjU



 
비교 포인트

소리 밀도가 더 잘 느껴지는지
공간감이 살아나는지
화면보다 사운드가 더 장면을 잡아주는지


이 튜토리얼의 핵심 정리
이 방식으로 연습하면 됩니다.
흐름

로그라인만 먼저 정한다
감정을 하나 고른다
눈에 보일 요소 3개를 고른다
행동과 변화 1개를 정한다
카메라에 이유를 붙인다
조명 톤을 정한다
사운드를 붙인다
단일 장면으로 먼저 완성한다
멀티샷으로 확장한다
변형 프롬프트로 비교 테스트한다


바로 따라 하기 좋은 실전 루틴
이 장면으로 실제 연습할 때는 아래 순서가 좋습니다.
1차 생성
1단계 프롬프트 사용
→ 기본 상황이 잡히는지 확인
2차 생성
3단계 프롬프트 사용
→ 시각 요소가 살아나는지 확인
3차 생성
5단계 프롬프트 사용
→ 카메라가 반영되는지 확인
4차 생성
7단계 프롬프트 사용
→ 사운드가 장면을 살리는지 확인
5차 생성
단일 장면 완성 프롬프트 사용
→ 전체 완성도 확인
6차 생성
멀티샷 프롬프트 사용
→ 컷 구성 확인
7차 생성
변형 A/B/C 비교
→ 어떤 요소가 가장 결과에 영향이 큰지 확인

가장 중요한 포인트
이 튜토리얼에서 중요한 건
처음부터 완벽한 프롬프트를 쓰는 것이 아니라,
장면을 단계별로 설계하고 어떤 요소가 결과를 바꾸는지 배우는 것입니다.


Seedance 2.0 손그림 애니메이션 테스트
행복한 수지아빠 — Thu, 16 Apr 2026 09:43:31 +0900
https://youtu.be/CoPB9huRPBE



 








프롬프트 정리

형식
- 15초
- 스타일화된 2D 손그림 애니메이션
- 머리 위 시점 해전
- 오래된 노란색 줄무늬 공책 용지 배경 유지
- 파란 가로선, 빨간 왼쪽 여백선 항상 보이기

비주얼 규칙
- 처음부터 끝까지 같은 공책 종이 세계 유지
- 미세한 종이 질감, 연필 자국, 잉크 획 강조
- 실사 금지 / 3D 금지 / 사실적 얼굴 금지 / 현대적 물건 금지
- 내레이션, 자막 없음

핵심 콘셉트
- 어린아이 낙서 해전 → 전설적 삽화 해전 → 다시 낙서로 붕괴
- 상상력이 종이를 장악하는 듯한 점진적이고 마법 같은 에스컬레이션

전투 설정
- 빨강 vs 파랑 두 해군 세력
- 판옥선, 노 젓는 배, 깃발, 화살, 화포 등장
- 중심에는 거북선
- 초반엔 조잡한 낙서, 후반엔 세밀한 잉크 삽화로 발전

주요 인물
- 이순신 장군을 상징하는 지휘관
- 사실적 초상 대신 영웅적 실루엣 중심
- 후반으로 갈수록 더 위엄 있고 선명한 손그림 표현

시간대별 진행
- 0~3초: 단순한 공책 낙서 해전 시작, 양측 함대 전진
- 3~7초: 첫 충돌, 화살·화포·함선 충돌, 디테일 업그레이드 시작
- 7~11초: 가장 웅장한 삽화형 해전 완성, 거북선 중심 전투 절정
- 11~15초: 결정적 돌진 후 충격, 모든 것이 다시 낙서와 선 조각으로 붕괴

움직임 톤
- 부드럽고 유동적
- 충격은 날카롭고 리드미컬
- 최소 24fps 느낌
- 머리 위 시점에서 읽기 쉬운 실루엣 유지

감정 흐름
- 장난스럽고 호기심 어린 시작
- 점점 비장하고 영웅적으로 확장
- 전설적 절정 후
- 무너진 뒤 이상하게 고요한 여운
 
이 프롬프트에서 배울 수 있는 점

1. 세계관 규칙을 먼저 고정해야 한다

- 가장 먼저 “오래된 공책 용지 위의 2D 손그림 세계”라는 룰을 강하게 고정했습니다.
- 그래서 모델이 중간에 실사풍, 3D풍, 다른 배경으로 흔들릴 가능성을 줄입니다.
- 좋은 프롬프트는 보통 무엇을 만들지보다 먼저 어떤 세계 안에서만 움직일지를 정합니다.

2. 금지 조건이 결과 안정성에 큰 영향을 준다

- 실사 없음, 3D 없음, 사실적 얼굴 없음, 현대적 물건 없음, 자막 없음 같은 조건은 단순한 부가 설명이 아니라 스타일 붕괴 방지 장치입니다.
- 특히 영상 생성에서는 원하는 요소보다 원하지 않는 요소를 명확히 막는 것이 중요합니다.

3. 핵심 아이디어는 한 문장으로 잡혀 있어야 한다

- 이 프롬프트의 중심은 “어린아이 낙서 해전이 전설적 삽화 해전으로 커졌다가 다시 낙서로 무너진다”입니다.
- 이 한 줄이 전체 연출, 움직임, 감정, 클라이맥스를 전부 묶어줍니다.
- 좋은 프롬프트는 세부가 많아도 중심 개념은 단순해야 합니다.

4. 변화는 갑작스럽게가 아니라 단계적으로 설계해야 한다

- 초반 낙서 → 중반 디테일 강화 → 후반 삽화 완성 → 마지막 붕괴
- 이런 식으로 변화의 단계가 명확합니다.
- 생성형 영상에서는 변화가 뜬금없이 튀는 경우가 많은데, 이 프롬프트는 점진적 에스컬레이션으로 그 문제를 줄이고 있습니다.

5. 시간 구간을 나누면 영상이 훨씬 잘 통제된다

- 0~3초
- 3~7초
- 7~11초
- 11~15초

- 이렇게 나누면 모델이 장면 전개를 더 잘 따라갑니다.
- 특히 15초 영상은 한 덩어리로 쓰기보다 구간별 사건 배치를 하는 편이 더 유리합니다.

6. 액션만 쓰지 말고 스타일 변화도 같이 써야 한다

- 단순히 “배가 싸운다”가 아니라
- 충돌할수록 선이 강해지고
- 갑옷 실루엣이 생기고
- 물보라와 연기가 잉크처럼 번지고
- 거북선 디테일이 살아난다고 적었습니다.

- 즉, 이 프롬프트는 서사 진행과 비주얼 진화를 동시에 쓰고 있습니다.
- 이 점이 매우 중요합니다.

7. 주인공은 얼굴보다 상징으로 잡는 게 안전할 때가 있다

- 이순신 장군을 직접 사실적으로 묘사하지 않고
- 상징적이고 영웅적인 지휘관 실루엣으로 처리했습니다.
- 이렇게 하면 스타일 유지가 쉬워지고, 얼굴 디테일 때문에 전체 톤이 깨지는 문제를 줄일 수 있습니다.

8. 배경도 움직이는 요소처럼 설계할 수 있다

- 이 프롬프트에서 바다는 단순한 배경이 아니라
- 공책 줄
- 종이 질감
- 잉크 번짐
- 물결선
- 종이 떨림까지 포함한 반응하는 무대입니다.

- 좋은 영상 프롬프트는 배경을 정지된 배경으로 두지 않고 연출의 일부로 만듭니다.

9. 클라이맥스 이후의 마무리도 중요하다

- 많은 프롬프트가 절정까지만 강하고 끝맺음이 약합니다.
- 그런데 여기서는 마지막에 전쟁이 다시 낙서로 붕괴하면서 여운 있는 엔딩 구조를 줍니다.
- 시작과 끝이 연결되기 때문에 짧은 영상인데도 완결감이 생깁니다.

10. 분위기 흐름을 따로 적는 것이 좋다

- 장난스러움
- 호기심
- 비장함
- 영웅성
- 신화적 절정
- 이상한 고요함

- 이렇게 감정 곡선을 적어두면 단순히 사건만 있는 영상이 아니라 톤이 있는 영상이 됩니다.

11. 읽기 쉬운 실루엣이라는 조건이 중요하다

- 머리 위 시점 전투는 복잡해지기 쉽습니다.
- 그래서 이 프롬프트는 계속 읽기 쉬운 실루엣, 명확한 구분, 중심 오브젝트인 거북선 강조를 넣고 있습니다.
- 즉, 멋진 설정보다 먼저 한눈에 이해되는 화면을 챙긴 것입니다.

12. 좋은 프롬프트는 무엇을 보여줄지와 어떻게 보여줄지를 같이 쓴다

- 무엇: 거북선 해전, 이순신 상징 지휘관, 붕괴하는 낙서 전쟁
- 어떻게: 공책 종이, 손그림 2D, 점진적 진화, 머리 위 시점, 잉크 질감, 리드미컬한 충격

- 이 둘을 함께 설계해야 결과가 강해집니다.
- 둘 중 하나만 있으면 결과가 약해질 수 있습니다.

한 줄 정리

좋은 영상 프롬프트는 소재만 설명하는 것이 아니라, 세계관 규칙, 시간 구조, 비주얼 진화, 감정 흐름까지 함께 설계하는 것입니다.


Seedance 2.0 프롬프트, 예쁜 문장보다 중요한 것은 구조다
행복한 수지아빠 — Wed, 15 Apr 2026 11:43:14 +0900
AI 영상 생성이 점점 쉬워졌다고들 말합니다. 텍스트 몇 줄만 입력하면 그럴듯한 장면이 나오고, 짧은 숏폼 영상도 빠르게 뽑아낼 수 있습니다. 하지만 실제로 여러 번 만들어본 사람이라면 금방 느끼게 됩니다. 아이디어가 좋아도 결과가 쉽게 흔들리고, 화면이 깨지고, 인물이 달라지고, 카메라가 뜻대로 움직이지 않는다는 것을요.
많은 초보자들이 여기서 이렇게 생각합니다.
“프롬프트를 더 길게 써야 하나?”
“더 멋있는 표현을 넣어야 하나?”
“cinematic, epic, stunning 같은 단어를 더 많이 넣어야 하나?”
그런데 실제로는 반대인 경우가 많습니다. 문제는 문장의 화려함이 아니라 프롬프트의 구조에 있습니다.
제가 정리한 핵심은 단순합니다. Seedance 2.0은 단순한 텍스트 입력형 영상 생성기가 아니라, 이미지·영상·오디오·텍스트를 함께 다루는 멀티모달 연출 도구에 가깝습니다. 그래서 결과를 안정적으로 만들고 싶다면, 시처럼 쓰기보다 촬영감독처럼 지시해야 합니다. 
이 글에서는 그 구조를 브런치용으로 차분하게 풀어보겠습니다. 단순 요약이 아니라, 바로 실전에 옮길 수 있도록 예제까지 함께 정리합니다.

왜 Seedance 프롬프트는 일반 텍스트 프롬프트와 다르게 접근해야 할까
Seedance 계열 프롬프트에서 중요한 건 “무엇이 멋져 보이는가”가 아니라 “모델이 무엇을 오해하지 않게 할 것인가”입니다.
예를 들어 아래 두 문장을 비교해보겠습니다.
좋지 않은 예
A beautiful cinematic woman in an epic room with amazing lighting

이 문장은 읽으면 그럴듯해 보입니다. 하지만 실제 생성 모델 입장에서는 불명확합니다.

여성이 어떻게 생겼는지 알 수 없습니다.
무엇을 하고 있는지 알 수 없습니다.
카메라가 움직이는지 고정인지 알 수 없습니다.
조명이 어떤 종류인지 알 수 없습니다.
“beautiful”, “cinematic”, “epic”은 감상어이지 지시어가 아닙니다.

더 좋은 예
[Subject]
late 20s woman, short dark curls, small silver hoop earring, black turtleneck

[Action]
she slowly turns toward the window and pauses

[Camera]
slow push-in from medium shot, stable camera

[Style]
golden hour lighting, cinematic film tone, 35mm, warm amber tone

[Constraints]
avoid jitter, avoid bent limbs, maintain face consistency, avoid temporal flicker

이 프롬프트는 길이가 아주 길지 않아도 훨씬 명확합니다.

누구인지 보이고
무엇을 하는지 보이고
카메라가 어떻게 움직이는지 보이고
어떤 빛인지 보이고
무엇을 피해야 하는지도 보입니다.

즉, 프롬프트의 핵심은 문학성이 아니라 구조적 명확성입니다.

Seedance 프롬프트의 핵심 구조: 5-Layer Prompt Stack
실전에서 가장 중요한 구조는 다음 다섯 요소로 정리할 수 있습니다.

Subject
Action
Camera
Style
Constraints

이 순서는 단순한 목록이 아니라, 모델이 장면을 이해하는 우선순위를 잡아주는 장치로 볼 수 있습니다. 
1) Subject: 화면의 중심을 먼저 고정하기
가장 먼저 해야 할 일은 무엇이 프레임의 중심인가를 확실히 적는 것입니다.
예를 들어 “a woman”이라고만 쓰면 모델은 평균적인 여성을 상상합니다. 그런데 아래처럼 구체화하면 결과가 훨씬 안정됩니다.
late 20s woman, tight dark curls, small silver hoop earring, fitted black turtleneck, pale skin, calm expression

이 문장에서 고정되는 요소는 다음과 같습니다.

연령대
헤어스타일
액세서리
의상
피부 톤
표정

이런 세부를 적는 이유는 “더 멋있게 보이게 하려는 것”이 아니라, 모델이 빈칸을 마음대로 채우지 못하게 하려는 것입니다.
2) Action: 감정이 아니라 움직임을 지시하기
AI 영상에서 많은 분들이 자주 하는 실수가 있습니다. 감정을 써놓고 동작을 생략하는 것입니다.
예를 들면 이런 식입니다.
she looks sad

이건 사람이 보면 이해할 수 있지만, 모델은 애매하게 받아들일 수 있습니다. 반면 아래처럼 바꾸면 훨씬 명확해집니다.
she lowers her head slowly, pauses, then reaches toward the old photo with hesitation

즉, “슬프다”를 직접 말하기보다 슬픔이 드러나는 행동을 쓰는 편이 좋습니다.
3) Camera: 피사체 움직임과 카메라 움직임을 분리하기
이 부분이 실제 품질 차이를 크게 만듭니다.
예를 들어 이런 문장은 흔들리기 쉽습니다.
spinning camera around a dancing person

누가 도는 걸까요? 카메라인가요, 사람인가요, 둘 다인가요? 모델은 이 문장을 모호하게 처리할 가능성이 큽니다.
더 좋은 방식은 분리하는 것입니다.
subject action: the dancer spins slowly
camera: fixed framing

혹은
subject action: the dancer remains centered and turns gently
camera: slow orbit around the subject

이렇게 쓰면 무엇이 움직이고 무엇이 고정되는지가 분명해집니다.
4) Style: 특히 조명을 구체적으로 적기
많은 분들이 style을 “cinematic” 같은 한 단어로 끝냅니다. 하지만 이건 너무 추상적입니다.
Seedance 스타일 프롬프트에서는 조명이 특히 중요하게 작동하는 경우가 많습니다. 예를 들면 아래와 같습니다.

golden hour
rim light
overcast daylight
soft key from 45 degrees
volumetric fog
motivated lighting from practical source

즉 “멋진 조명”이 아니라, 빛이 어디서 어떻게 들어오는지를 적어야 합니다.
5) Constraints: 무엇을 망치지 말아야 하는지 미리 적기
좋은 결과는 멋진 형용사보다 실패 방지 문구에서 나오는 경우가 많습니다.
대표적인 예시는 다음과 같습니다.
avoid jitter
avoid bent limbs
avoid identity drift
avoid temporal flicker
maintain face consistency
stable picture
sharp clarity

이런 문구는 특히 인물, 액션, 빠른 카메라 움직임, 숏츠 영상에서 중요합니다.

카메라 키워드는 왜 중요한가
AI 영상이 어색해지는 가장 큰 이유 중 하나는 카메라 지시가 불분명하기 때문입니다.
실전에서 자주 쓰는 카메라 키워드를 정리하면 다음과 같습니다.
고정 계열

fixed / locked-off: 카메라 정지
static wide: 넓은 고정 쇼트
locked tripod: 삼각대처럼 흔들림 없는 고정

이동 계열

push-in / dolly in: 앞으로 들어감
pull-out / dolly out: 뒤로 빠짐
pan left/right: 좌우 회전
tracking shot / follow: 피사체를 따라감
orbit / arc: 피사체 주위를 돎
crane up/down: 수직 상승/하강
gimbal: 부드럽고 안정적인 이동
handheld: 일부러 자연스러운 흔들림

속도 수식어

slow
gentle
smooth
controlled
barely
gradual

여기서 중요한 것은 fast를 남발하지 않는 것입니다. 너무 많은 요소가 동시에 빨라지면 지터나 깨짐이 쉽게 생길 수 있습니다. 그래서 빠르게 만들고 싶은 것이 있더라도, 하나만 빠르게 하고 나머지는 안정화하는 편이 좋습니다. 

조명과 스타일은 어떻게 써야 할까
많은 프롬프트가 style 부분에서 막힙니다. 예쁜 느낌을 쓰고 싶지만, 너무 추상적으로 쓰면 결과가 흔들립니다.
좋지 않은 예
cinematic, epic, beautiful lighting

더 좋은 예
golden hour lighting, cinematic film tone, 35mm, warm amber tone, soft rim light

좋은 style 문장은 보통 다음 요소를 포함합니다.

조명 종류
색감
필름 질감
콘트라스트 특성
분위기 앵커

예를 들어,
overcast daylight, soft diffused shadows, documentary-style handheld framing

이 문장은 자연광 다큐 느낌을 만들어내는 데 도움이 됩니다.
반대로,
chiaroscuro lighting, crushed blacks, warm practical lamp glow, cinematic 35mm

이렇게 쓰면 더 강한 영화적 대비가 만들어질 가능성이 높습니다.

멀티샷 타임코드 방식이 중요한 이유
짧은 15초 영상도 한 덩어리로 쓰기보다, 시간 구간별로 나누어 설계하면 훨씬 안정적인 결과를 얻을 수 있습니다. 
예를 들면 이런 식입니다.
[0-4s]
shot size: wide shot
camera: static
subject action: woman stands by the desk looking at an old photograph
lighting: warm window light

[4-8s]
shot size: medium shot
camera: slow push-in
subject action: she reaches toward the photograph and hesitates
lighting: golden hour highlights on face and hand

[8-12s]
shot size: close-up
camera: continued gentle push-in
subject action: fingertips stop just before touching the photo
lighting: soft warm side light

[12-15s]
shot size: close-up hold
camera: static hold
subject action: she touches the photo and exhales softly
lighting: steady amber light, shallow falloff

이 방식의 장점은 분명합니다.

장면 전개가 생깁니다.
카메라가 중간에 제멋대로 바뀌는 일이 줄어듭니다.
감정의 흐름을 단계적으로 설계할 수 있습니다.
숏츠에서 특히 중요한 “도입 → 상승 → 클라이맥스”가 자연스러워집니다.

실전에서는 다음 흐름이 가장 무난합니다.

0–4초: 세계를 보여주는 wide shot
4–8초: 인물과 상황을 좁혀가는 medium shot
8–12초: 감정이 최고조로 가는 close-up
12–15초: reveal 또는 hold

즉, wide → medium → close → closest/reveal 구조입니다.

멀티모달과 @ 레퍼런스 시스템은 어떻게 써야 할까
이 부분은 Seedance형 워크플로우에서 특히 중요합니다. 텍스트만으로 모든 걸 설명하기보다, 참조 자산의 역할을 분명히 나누는 것이 훨씬 강력할 수 있습니다. 
예를 들면,

@Image1 = 캐릭터 기준 이미지
@Image2 = 배경/환경 기준 이미지
@Video1 = 카메라 움직임 레퍼런스
@Audio1 = 배경음악 또는 타이밍 기준

이렇게 역할을 명시해두면 모델이 평균화해서 처리하는 문제를 줄일 수 있습니다.
또 하나 좋은 방식은 첫 프레임 + 마지막 프레임 전략입니다.
예를 들어,

시작: 조용한 방에 서 있는 인물
끝: 우주 공간으로 떠오른 같은 인물

이 두 이미지를 기준으로 주면, 그 사이의 변화 과정을 텍스트로 설계하기 쉬워집니다.

초보자가 가장 자주 하는 실수
이론을 이해해도, 실제로는 아래 실수를 많이 합니다.
1) 추상어를 너무 많이 쓰는 경우
epic, amazing, beautiful, cinematic, powerful, awesome

이런 단어는 대부분 감상문에 가깝습니다. 지시문으로는 효율이 떨어집니다.
2) 인물을 너무 대충 쓰는 경우
a woman in a room

이러면 얼굴, 의상, 나이, 체형, 헤어, 인상 모두 흔들릴 수 있습니다.
3) 피사체와 카메라를 한 문장에 섞는 경우
spinning around quickly while the camera is moving dynamically

 
4) 제약 문구를 빼는 경우
처음에는 멋진 묘사만 적고 끝내기 쉽습니다. 하지만 실제로 결과를 망치는 건 흔들림, 왜곡, 얼굴 변화, 노출 깜빡임 같은 문제입니다.
5) 실패했을 때 프롬프트를 전부 갈아엎는 경우
가장 비효율적인 방식입니다. 카메라, 조명, 스타일, 액션을 한 번에 바꾸면 무엇이 문제였는지 알 수 없습니다.
가장 좋은 방식은 다음과 같습니다.

기본 버전 2~3개 생성
카메라만 바꾸기
조명만 바꾸기
style만 바꾸기
constraints를 강화하기

즉 한 번에 한 변수만 바꾸기입니다.

실전 예제 1: 감정 장면 프롬프트
아래는 가장 기본적인 감정 장면 예제입니다.
[Subject]
late 20s woman, short dark curls, silver hoop earring, black turtleneck

[Action]
she stands by the desk, looks at an old photograph, slowly reaches toward it, hesitates, then touches it gently

[Camera]
slow push-in from medium shot, stable framing

[Style]
golden hour lighting, cinematic film tone, 35mm, warm amber tone, shallow depth of field

[Constraints]
avoid jitter, avoid bent limbs, maintain face consistency, avoid temporal flicker, stable picture, sharp clarity

이 예제에서 중요한 것은 감정이 아니라 감정을 드러내는 동작을 넣었다는 점입니다.

실전 예제 2: 제품 광고 프롬프트
제품 광고는 특히 카메라와 조명이 중요합니다.
[Subject]
a luxury perfume bottle with clear glass body and metallic cap on a dark reflective surface

[Action]
the bottle remains still while light moves across the glass surface, revealing texture and reflection

[Camera]
gentle slow push-in, macro framing, smooth controlled movement

[Style]
dramatic rim light, premium commercial look, shallow depth of field, dark minimal background

[Constraints]
avoid jitter, avoid distortion, no stretching, avoid temporal flicker, stable picture, sharp clarity, clean edges

제품은 스스로 움직이지 않기 때문에, 빛과 카메라가 액션을 대신 만든다고 이해하면 좋습니다.

실전 예제 3: 세로 숏츠용 우주 전투 프롬프트
세로 9:16 숏츠에서는 전장을 가로로 넓게 펼치기보다, 주인공 전투기를 중앙축에 고정하고 아래에서 위로 치고 올라가는 흐름이 잘 맞습니다.
15-second cinematic vertical space battle sequence, 9:16 aspect ratio

[0-4s]
shot size: ultra wide vertical shot
camera: slow push-in
subject action: the hero starfighter rises from the lower frame toward a massive battle above
lighting: cold planetary backlight, red laser streaks, blue engine trails

[4-8s]
shot size: medium vertical chase shot
camera: rear tracking centered on the starfighter
subject action: the fighter ascends between debris while enemy ships fire from behind
lighting: flashing weapon bursts, engine reflections on debris

[8-12s]
shot size: close action shot
camera: fast but controlled side-to-rear follow
subject action: the hero ship turns sharply and destroys one enemy fighter
lighting: intense explosion bloom, hot orange wreckage glow

[12-15s]
shot size: vertical climax shot
camera: dramatic pull-out
subject action: the hero ship charges upward while a giant flagship explodes behind it
lighting: massive explosion backlight, flickering reflections across nearby ships

style: cinematic film tone, premium sci-fi blockbuster, strong vertical depth
constraints: avoid jitter, avoid distortion, no stretching, avoid temporal flicker, stable picture, sharp clarity

여기서 중요한 것은 “스타워즈풍”이라는 감상어가 아니라, 세로 프레임에 맞춘 구도 설계와 액션 흐름입니다.

실전 예제 4: 꿈에서 우주로 이어지는 변환 장면
시작 이미지와 끝 이미지 연결 테스트용으로도 좋은 구조입니다.
15-second cinematic vertical transformation sequence, 9:16

[0-4s]
shot size: ultra wide vertical shot
camera: slow push-in
subject action: a young woman stands in the center of a quiet bedroom at night
lighting: soft moonlight, cool blue room shadow

[4-8s]
shot size: medium vertical shot
camera: smooth upward follow
subject action: papers and objects begin to float, walls dissolve into stars
lighting: stronger blue-violet glow, subtle cosmic reflections

[8-12s]
shot size: close action shot
camera: controlled push-in
subject action: the woman lifts upward as fragments of the bedroom drift apart
lighting: intense portal bloom, glowing particles, bright rim light

[12-15s]
shot size: vertical climax shot
camera: pull-through into space
subject action: the woman fully rises into outer space, leaving the bedroom behind
lighting: radiant cosmic blue-white streaks, dreamy backlight

style: cinematic dreamlike sci-fi, magical realism, strong depth layering
constraints: avoid jitter, avoid distortion, avoid temporal flicker, maintain face consistency

이런 구조는 첫 프레임과 마지막 프레임을 연결하는 테스트에도 적합합니다.
1. 문제 제기부터 시작하기
“왜 AI 영상은 자꾸 흔들릴까?”
“왜 내 프롬프트는 멋지게 써도 결과가 불안정할까?”
이런 질문으로 시작하면 독자가 바로 들어옵니다.
2. 답을 구조로 제시하기
길게 설명하기보다,

Subject
Action
Camera
Style
Constraints

이 다섯 요소를 글의 뼈대로 삼는 것이 좋습니다.
3. 추상어 vs 구조화 예시를 꼭 넣기
독자 입장에서는 “왜 cinematic만 쓰면 안 되지?”가 가장 먼저 생깁니다. 그러니 나쁜 예 / 좋은 예 비교를 꼭 넣는 것이 좋습니다.
4. 예제를 짧고 바로 복붙 가능하게 넣기
사람들은 원칙보다 예제를 더 빨리 가져갑니다.
5. 마지막에 반복 실험 원칙을 붙이기
결론을 아래처럼 마무리하면 좋습니다.

좋은 프롬프트는 시처럼 멋지게 쓰는 것이 아니라, 촬영감독처럼 명확하게 지시하는 데서 나온다. 그리고 실패했을 때는 더 길게 쓰는 것이 아니라, 한 번에 한 변수만 고쳐야 한다.


마무리
AI 영상 프롬프트를 잘 쓴다는 것은 화려한 수식어를 많이 붙이는 일이 아닙니다. 오히려 반대입니다. 무엇을 보여줄지, 누가 움직일지, 카메라가 어떻게 따라갈지, 빛이 어디서 들어올지, 무엇을 망치지 말아야 할지를 차분하게 적는 일에 가깝습니다.
특히 Seedance 2.0처럼 멀티모달 특성이 강한 도구를 다룰 때는, 텍스트만으로 모든 걸 해결하려 하기보다 이미지·영상·오디오를 함께 쓰고 역할을 명시하는 방향이 더 자연스럽습니다. 
결국 중요한 것은 하나입니다.
프롬프트를 예쁜 문장으로 쓰지 말고, 장면 설계서처럼 써라.
이 한 줄만 기억해도, 영상 결과는 꽤 달라질 수 있습니다.

바로 복붙해서 쓸 수 있는 마지막 템플릿
[Subject]

[Action]

[Camera]

[Style]

[Constraints]

혹은 15초 멀티샷이라면,
[0-4s]
shot size:
camera:
subject action:
lighting:

[4-8s]
shot size:
camera:
subject action:
lighting:

[8-12s]
shot size:
camera:
subject action:
lighting:

[12-15s]
shot size:
camera:
subject action:
lighting:

style:
constraints:

이 두 가지 구조만 제대로 익혀도, 대부분의 장면은 훨씬 안정적으로 설계할 수 있습니다.


Build Your Own OpenClaw: OpenClaw를 처음부터 단계별로 공부해보자
행복한 수지아빠 — Tue, 14 Apr 2026 16:12:41 +0900
이 저장소는 완성형 프레임워크를 바로 쓰게 하는 대신, 가장 단순한 채팅 루프에서 출발해 도구 호출, 스킬, 세션 저장, 컨텍스트 압축, 이벤트 버스, 멀티 에이전트, 장기 메모리까지 직접 조립해 보게 만드는 튜토리얼형 프로젝트입니다. (GitHub)
요즘 AI 에이전트를 다룰 때 가장 답답한 지점은 “잘 돌아가는 데 왜 그렇게 설계됐는지”가 보이지 않는다는 점입니다. 프레임워크는 빠르게 결과를 내주지만, 구조를 이해하지 못하면 비용이 왜 늘었는지, 컨텍스트가 왜 깨졌는지, 왜 특정 상황에서만 불안정한지 판단하기 어렵습니다. 이 저장소는 그 불투명한 중간층을 단계별 코드로 드러냅니다. (GitHub)
이 글을 끝까지 읽으면 세 가지가 명확해집니다.
첫째, 에이전트가 단순한 LLM 호출이 아니라 세션, 이벤트, 라우팅, 메모리, 동시성 제어가 얽힌 시스템이라는 점입니다. 둘째, OpenClaw 계열 접근이 기존 “단일 프롬프트 챗봇”과 어떻게 다른지입니다. 셋째, 이 구조를 언제 도입해야 하고 언제는 과한 선택인지 판단할 수 있게 됩니다. (GitHub)

 

GitHub - czl9707/build-your-own-openclaw: A step-by-step guide to build your own AI agent.
A step-by-step guide to build your own AI agent. Contribute to czl9707/build-your-own-openclaw development by creating an account on GitHub.
github.com


 
왜 이 문제가 중요한가
처음에는 채팅 루프 하나면 충분해 보입니다. 실제로 이 튜토리얼도 Step 00에서 사용자 입력을 받고, 메시지 히스토리를 그대로 모델에 보내고, 응답을 다시 세션에 추가하는 아주 단순한 구조로 시작합니다. 문제는 이 방식이 조금만 길어져도 금방 한계를 드러낸다는 점입니다. (GitHub)
가장 먼저 드러나는 건 비용 문제입니다. 대화가 길어질수록 매 호출마다 전체 히스토리를 다시 보내야 하므로, 불필요한 토큰 사용이 늘어납니다. 저장소가 별도 단계로 compaction을 도입한 이유도 바로 이 때문인데, 오래된 대화를 요약하고 새 세션으로 넘기지 않으면 컨텍스트 한계와 비용 증가가 동시에 발생하기 때문입니다. (GitHub)
성능 문제도 바로 따라옵니다. 단일 루프 구조에서는 외부 채널 연동, 프로그램적 접근, 백그라운드 작업 같은 요구가 생길 때 병목이 쉽게 생깁니다. 이 저장소가 중간 단계에서 이벤트 버스와 WebSocket 계층을 따로 분리하는 이유는, 입력 소스와 에이전트 실행을 느슨하게 결합해 확장성을 확보하려는 설계 때문입니다. (GitHub)
유지보수 문제는 규모가 커질수록 더 커집니다. 도구, 프롬프트, 라우팅 규칙, 메모리 전략이 한 파일에 뒤섞이면 기능 추가보다 디버깅이 더 어려워집니다. 그래서 이 프로젝트는 스킬 정의, 에이전트 정의, 라우팅 테이블, 메모리 전용 에이전트처럼 책임을 나눠 보여 줍니다. (GitHub)
개발 경험 측면에서도 차이가 큽니다. 단순 챗봇은 빠르게 만들 수 있지만, 실제 제품화 단계에 가면 “왜 이 응답이 나왔는지”, “어느 에이전트가 처리했는지”, “동시에 여러 요청이 오면 어떻게 되는지”를 설명하기 어려워집니다. 이 저장소는 그 과정을 튜토리얼 단계로 분해해, 비결정적 동작을 줄이고 구조를 눈으로 따라가게 만듭니다. (GitHub)
Build Your Own OpenClaw란 무엇인가
한 문장으로 정의하면, Build Your Own OpenClaw는 “개인용 AI 에이전트 시스템을 작은 부품부터 직접 조립하며 이해하게 만드는 단계형 학습 저장소”입니다. (GitHub)
비유하면 이 프로젝트는 완성차를 주는 것이 아니라, 엔진과 조향 장치와 브레이크를 순서대로 조립해 보게 하는 정비 교육 키트에 가깝습니다. 처음에는 단순히 앞으로 가기만 하던 것이, 점점 외부 장치와 연결되고, 여러 작업을 분담하고, 오래 기억하고, 과부하를 막는 방향으로 발전합니다. (GitHub)
기술적으로 보면 이 저장소는 18개의 단계로 구성되어 있고, 각 단계마다 설명용 README와 실행 가능한 코드가 함께 제공됩니다. 구조는 1) 단일 에이전트, 2) 이벤트 기반 아키텍처, 3) 자율 동작과 멀티 에이전트, 4) 운영과 스케일 단계로 나뉘어 있습니다. (GitHub)
기존 방식과의 가장 큰 차이는 “프레임워크 사용법”이 아니라 “에이전트 시스템의 내부 모델”을 가르친다는 점입니다. 단순한 챗 인터페이스를 만드는 데서 멈추지 않고, 왜 세션이 필요하고, 왜 이벤트 버스가 필요한지, 왜 메모리를 별도 에이전트로 분리할 수 있는지까지 보여 줍니다. 이것이 이 프로젝트의 철학입니다. (GitHub)
핵심 특징

18단계 점진식 구성
한 번에 거대한 구조를 던지지 않고, 채팅 루프에서 메모리와 동시성 제어까지 점진적으로 확장합니다. 초보자에게는 학습 곡선을 낮추고, 실무자에게는 아키텍처 변화 지점을 분명히 보여 줍니다. (GitHub)
README와 실행 코드가 함께 존재
각 단계가 설명 문서와 runnable codebase를 함께 제공하므로, 개념만 이해하고 끝나는 것이 아니라 바로 실행해 보며 검증할 수 있습니다. (GitHub)
스킬을 런타임에 지연 로드
Step 02는 SKILL.md 기반 스킬을 필요할 때만 불러오는 구조를 소개합니다. 이는 모든 기능을 프롬프트에 미리 넣지 않고, 필요한 능력만 로드해 컨텍스트 낭비를 줄이려는 방향과 연결됩니다. (GitHub)
컨텍스트 압축 전략을 별도 단계로 다룸
Step 05는 큰 툴 결과를 먼저 줄이고, 그래도 크면 오래된 대화를 요약해 새 세션으로 넘기는 방식을 설명합니다. 긴 대화에서 비용과 컨텍스트 한계를 동시에 다루는 점이 중요합니다. (GitHub)
이벤트 기반 구조로 전환
Step 07 이후에는 입력과 실행을 직접 묶지 않고, InboundEvent와 OutboundEvent를 이벤트 버스로 흘려보냅니다. 이 방식은 CLI를 넘어 채널 연동, 서버화, 백그라운드 작업으로 확장하기 쉽게 만듭니다. (GitHub)
멀티 에이전트와 운영 제어까지 포함
Step 11은 메시지 출처에 따라 다른 에이전트로 라우팅하고, Step 16은 세마포어 기반 동시성 제어를 둡니다. 즉, 이 프로젝트는 “잘 대답하는 봇”이 아니라 “운영 가능한 에이전트 시스템”으로 가는 과정을 다룹니다. (GitHub)

실제로 어떤 효과가 있는가
이 프로젝트의 가장 큰 효과는 성능 수치보다 이해 비용을 줄여 준다는 데 있습니다. 공개된 자료 기준으로 이 저장소는 “작동하는 결과물”보다 “왜 이런 구성요소가 필요한지”를 단계별로 체감하게 만드는 데 초점을 둡니다. 그래서 프레임워크를 외워 쓰는 것이 아니라, 설계 판단의 근거를 쌓는 데 유리합니다. (GitHub)
전과 후를 비교하면 차이가 분명합니다. 시작점은 전체 히스토리를 그대로 보내는 단일 채팅 루프입니다. 이후에는 툴 호출, 스킬 로딩, 세션 저장, 컨텍스트 압축, 이벤트 버스, WebSocket, 라우팅, 메모리, 동시성 제한이 더해지면서 “한 번 대답하는 봇”이 “여러 입력 경로를 처리하고 상태를 유지하는 시스템”으로 바뀝니다. (GitHub)
효과가 가장 크게 드러나는 상황은 두 가지입니다. 하나는 AI 에이전트를 처음 설계하는 팀이 구조를 통째로 이해해야 할 때입니다. 다른 하나는 이미 챗봇은 만들었지만, 긴 대화, 외부 채널 연결, 멀티 에이전트, 메모리, 운영 안정성 문제로 다음 단계가 막힌 팀입니다. (GitHub)
특히 스타트업이나 소규모 팀에는 장점이 큽니다. 처음부터 대형 프레임워크 전체를 받아들이지 않고, 필요한 복잡도를 필요한 시점에만 도입하는 사고방식을 익힐 수 있기 때문입니다. 반대로 이미 조직 표준 프레임워크와 운영 체계가 굳어 있는 팀이라면, 이 프로젝트는 생산성 도구보다 학습 재료로서 가치가 더 큽니다. 이 평가는 저장소의 단계형 구조와 설명 중심 구성에서 자연스럽게 도출되는 판단입니다. (GitHub)
동작 원리 / 구조

입력을 받는다
시작점은 CLI 채팅 루프입니다. 사용자가 메시지를 입력하면 세션이 이를 사용자 메시지로 저장하고, 현재까지의 히스토리를 모델 호출용 메시지 배열로 구성합니다. 가장 단순한 형태지만, 모든 에이전트 시스템의 최소 단위가 여기서 드러납니다. (GitHub)
필요한 능력을 붙인다
다음 단계에서 도구와 스킬이 들어옵니다. 특히 스킬은 SKILL.md 정의를 기반으로 런타임에 로드되며, 전용 스킬 툴을 통해 필요한 순간에만 내용을 꺼내 옵니다. 이 설계는 능력을 정적으로 다 박아 넣는 대신, 필요 시점에 확장하는 쪽에 가깝습니다. (GitHub)
대화 상태를 보존한다
세션과 저장 계층이 추가되면 에이전트는 단발성 호출이 아니라 상태 있는 상호작용으로 바뀝니다. 이후 compaction 단계에서는 오래된 히스토리를 그대로 유지하지 않고 요약해 새 세션으로 넘기는데, 이는 긴 대화에서도 컨텍스트를 관리하기 위한 설계입니다. (GitHub)
입력과 실행을 분리한다
이벤트 기반 단계에서는 InboundEvent와 OutboundEvent가 도입되고, EventBus가 이 이벤트를 pub/sub 방식으로 배포합니다. 이렇게 하면 입력 채널이 늘어나도 에이전트 실행 로직을 직접 뜯지 않아도 됩니다. 설계 목적은 확장성과 결합도 감소입니다. (GitHub)
채널과 프로그램적 접근을 연다
이후 채널 단계와 WebSocket 단계에서 에이전트는 CLI 밖으로 나갑니다. WebSocket 워커는 연결된 클라이언트를 관리하고 이벤트를 브로드캐스트하므로, 외부 애플리케이션이나 다른 인터페이스가 같은 에이전트 시스템과 연결될 수 있습니다. (GitHub)
여러 에이전트로 역할을 나눈다
멀티 에이전트 라우팅 단계에서는 에이전트 정의를 스캔하고, 소스 패턴과 매핑 규칙에 따라 어느 에이전트가 처리할지 결정합니다. 즉, 하나의 거대한 프롬프트에 모든 역할을 욱여넣는 대신, 역할별 에이전트를 분리하는 방향입니다. (GitHub)
장기 메모리를 별도 책임으로 둔다
메모리 단계에서는 기억을 전담하는 specialized agent가 등장합니다. 현재 구현은 메모리 전용 에이전트를 dispatch해 정보를 저장하고 조회하는 방식이며, 직접 툴로 붙이는 방식이나 벡터 데이터베이스 방식과 구분됩니다. 이 선택은 “기억”을 별도 책임으로 분리한다는 설계 의도를 보여 줍니다. (GitHub)
운영 안정성을 보강한다
마지막으로 동시성 제어 단계에서는 에이전트별 최대 동시 실행 수를 두고, 세마포어로 과도한 병렬 실행을 막습니다. 이것이 필요한 이유는 에이전트가 길게 실행되거나 백그라운드 작업을 동반할 때, 자원 고갈이 곧 장애로 이어질 수 있기 때문입니다. (GitHub)

설치 / 사용 방법
이 저장소는 각 단계가 독립 실행 가능한 형태로 구성되어 있습니다. 공통적으로 먼저 설정 파일을 복사해 API 키를 넣고, 그다음 원하는 단계 디렉터리로 들어가 실행하는 흐름입니다. 루트 README는 모든 단계 실행 전에 config.example.yaml을 config.user.yaml로 복사해 API 키를 넣으라고 안내합니다. (GitHub)
설치 흐름은 대략 아래처럼 이해하면 됩니다. 저장소는 Python 3.11 이상을 요구하고, Step 00의 pyproject.toml에는 litellm, typer, rich, pydantic, pyyaml 같은 의존성이 정의되어 있습니다. 실행 예시는 uv run my-bot chat 형태로 제공됩니다. (GitHub)
git clone <저장소>
cd build-your-own-openclaw

cp default_workspace/config.example.yaml default_workspace/config.user.yaml
# config.user.yaml에 API 키 입력

cd 00-chat-loop
uv run my-bot chat

최소 실행 예제는 Step 00입니다. 이 단계에서는 단순히 대화를 주고받는 기본 에이전트를 확인할 수 있습니다. 이후 Step 02로 가면 스킬 개념을, Step 05로 가면 컨텍스트 압축을, Step 07 이후로 가면 이벤트 기반 구조를 같은 방식으로 이어서 실험할 수 있습니다. (GitHub)
메모리까지 보고 싶다면 다음 흐름이 이해하기 좋습니다.
Step 00으로 기본 루프를 익히고, Step 02에서 능력 확장 방식을 보고, Step 05에서 컨텍스트 관리 이유를 체감한 다음, Step 07과 Step 11을 거쳐 Step 17에서 장기 기억이 어떻게 붙는지 확인하면 전체 구조가 자연스럽게 이어집니다. 이 순서는 저장소의 단계 설계와 잘 맞습니다. (GitHub)
자주 쓰는 예시 / 활용 시나리오
1. AI 에이전트 입문 학습
에이전트를 처음 만드는 개발자에게 가장 적합한 용도입니다. 단순 챗봇에서 끝나지 않고, 왜 도구와 세션, 이벤트, 메모리, 동시성 제어가 필요한지 흐름으로 익힐 수 있습니다. (GitHub)
2. 기존 챗봇을 시스템으로 확장하기
이미 “질문하면 대답하는 봇”은 있지만, 채널 연동이나 서버화가 필요한 팀에 맞습니다. 이벤트 버스와 WebSocket 단계는 입력 경로를 늘리면서도 실행 로직의 결합을 낮추는 방향을 보여 줍니다. (GitHub)
3. 컨텍스트 최적화 실험
대화가 길어져 비용이 늘고 응답 품질이 흔들리는 상황에서 compaction 단계가 유용합니다. 오래된 메시지를 요약해 넘기는 방식은 벡터 검색 없이도 긴 세션을 관리하는 현실적인 첫 단계가 됩니다. (GitHub)
4. 역할 분리형 에이전트 설계
하나의 에이전트에 모든 역할을 몰아넣는 대신, 소스별로 다른 에이전트가 처리하게 만들고 싶을 때 적합합니다. 멀티 에이전트 라우팅 단계는 어떤 메시지를 어느 에이전트가 맡을지 규칙 기반으로 분리하는 사고를 익히게 합니다. (GitHub)
5. 장기 기억 구조 실험
사용자 정보나 프로젝트 맥락을 장기적으로 유지해야 할 때, Step 17의 specialized memory agent 접근이 좋은 실험 재료가 됩니다. 특히 메모리를 주 에이전트의 프롬프트에 섞는 대신, 별도 책임으로 나누는 방식이 어떤 장단점을 가지는지 확인할 수 있습니다. (GitHub)
한계 / 주의할 점
첫째, 이 저장소는 어디까지나 튜토리얼 성격이 강합니다. 문서상 확인되는 범위에서 각 단계는 개념을 설명하고 runnable code를 제공하는 데 초점이 있으며, 대규모 운영 환경에서 필요한 모든 관찰성, 보안, 장애 복구, 배포 자동화를 포괄한다고 보기는 어렵습니다. (GitHub)
둘째, OpenClaw와 완전히 동일한 구현은 아닙니다. 예를 들어 스킬 시스템은 이 튜토리얼에서는 전용 skill 툴 방식으로 설명하지만, 설명상 OpenClaw는 시스템 프롬프트 주입과 파일 읽기 방식에 더 가깝다고 명시합니다. 따라서 “OpenClaw 복제본”이라기보다 “핵심 설계를 학습하기 위한 경량 구현”으로 보는 편이 정확합니다. (GitHub)
셋째, 적용이 어려운 경우도 있습니다. 단순한 사내 FAQ 봇이나 일회성 챗 인터페이스라면, 이벤트 버스·멀티 에이전트·동시성 제어까지 도입하는 것은 과할 수 있습니다. 이 구조는 채널이 늘고, 역할이 분리되고, 세션 지속성과 운영 안정성이 중요해질 때 가치가 커집니다. 이 부분은 저장소의 단계 구성을 바탕으로 한 실무적 해석입니다. (GitHub)
넷째, 현재 기준으로는 성능 벤치마크나 운영 지표를 체계적으로 제시하는 프로젝트는 아닙니다. 공개된 자료 기준으로 강점은 수치 최적화보다 구조 학습과 설계 이해에 있습니다. 따라서 “바로 프로덕션에 넣을 도구”를 찾는 기대와는 약간 다를 수 있습니다. (GitHub)
마무리
Build Your Own OpenClaw의 가치는 기능 수가 아니라 설명 방식에 있습니다.
이 프로젝트는 에이전트를 프롬프트 몇 줄의 문제가 아니라, 상태 관리와 이벤트 흐름, 역할 분리와 운영 제어가 필요한 시스템으로 보게 만듭니다. (GitHub)
특히 AI 에이전트 개발을 처음 구조적으로 배우고 싶은 개발자, 단일 챗봇에서 한 단계 넘어가려는 스타트업, 여러 역할과 채널을 다루는 개인용 혹은 소규모 팀용 에이전트를 설계하는 사람에게 잘 맞습니다. 반면, 당장 완성형 프레임워크만 필요한 팀에게는 학습용 비중이 더 크게 느껴질 수 있습니다. (GitHub)
핵심 요약

핵심 개념
Build Your Own OpenClaw는 채팅 루프에서 시작해 도구, 스킬, 세션, 컨텍스트 압축, 이벤트 버스, 멀티 에이전트, 장기 메모리, 동시성 제어까지 직접 조립하며 배우는 단계형 에이전트 튜토리얼입니다. (GitHub)
차별점
사용법을 가르치는 프레임워크 문서가 아니라, 왜 그런 구조가 필요한지까지 보여 주는 설계 학습형 저장소라는 점이 다릅니다. (GitHub)
언제 쓰면 좋은지
AI 에이전트 아키텍처를 처음부터 이해하고 싶을 때, 기존 챗봇을 채널 연동·멀티 에이전트·메모리 구조로 확장하고 싶을 때 좋습니다. (GitHub)
언제 쓰면 안 되는지
단순 질의응답 봇처럼 구조 복잡도가 낮은 문제를 빠르게 끝내야 한다면, 이 저장소의 단계적 아키텍처는 과한 선택일 수 있습니다. (GitHub)
한 줄 요약
“에이전트를 만드는 법”보다 “에이전트 시스템이 왜 그렇게 생겨야 하는지”를 배우게 해 주는 저장소입니다. (GitHub)



GEOFlow: GEO를 자동화 운영 시스템
행복한 수지아빠 — Tue, 14 Apr 2026 16:11:24 +0900
이 글은 GEOFlow를 이해하기 위해 작성되었습니다.
단순히 AI로 글을 생성하는 도구로 보면 이 프로젝트의 핵심을 놓치기 쉽습니다. GEOFlow는 글 생성 자체보다, 콘텐츠 운영의 전체 흐름을 하나의 시스템으로 묶는 것에 더 가깝습니다. 모델 설정, 소재 관리, 작업 실행, 검토, 게시까지를 끊기지 않게 연결하려는 시도입니다. (GitHub)
기존의 AI 콘텐츠 운영은 보통 여러 도구에 흩어져 있습니다. 프롬프트는 문서에 따로 저장하고, 제목은 스프레드시트로 관리하고, 생성은 별도 스크립트로 돌리고, 결과는 CMS에 다시 붙여 넣습니다. 이런 구조는 처음에는 빨라 보여도, 작업량이 늘어나면 관리 비용이 급격히 커집니다. GEOFlow는 바로 그 지점을 겨냥합니다. (GitHub)
이 글을 끝까지 읽으면 세 가지를 분명하게 이해할 수 있습니다.
첫째, GEOFlow가 왜 단순한 “AI 글쓰기 툴”이 아닌지.
둘째, 기존 SEO 운영 방식과 무엇이 다른지.
셋째, 실제로 어떤 팀이 어떤 상황에서 도입할 만한지입니다. (GitHub)

 

GitHub - yaojingang/GEOFlow: Open-source GEO content production system with AI tasks, review workflow, and publishing.
Open-source GEO content production system with AI tasks, review workflow, and publishing. - yaojingang/GEOFlow
github.com


 
왜 이 문제가 중요한가
AI를 이용해 콘텐츠를 만들기 시작하면 가장 먼저 부딪히는 문제는 비용입니다. 한 번의 실험은 싸 보이지만, 제목 후보를 여러 개 돌리고, 본문을 다시 생성하고, 실패한 작업을 재시도하고, 게시 전 검토까지 포함하면 API 호출 수가 빠르게 늘어납니다. 생성이 자동화되지 않은 상태에서는 사람이 그 흐름을 수동으로 붙잡고 있어야 해서 운영 비용도 같이 올라갑니다. (GitHub)
다음은 성능 문제입니다. 단순한 “한 번 생성”은 쉽지만, 실제 운영에서는 예약 실행, 배치 처리, 실패 재시도, 게시 상태 관리가 필요합니다. 이걸 코드 몇 개와 크론 작업으로만 유지하면, 작업이 쌓일수록 병목이 어디서 생기는지 파악하기 어렵습니다. GEOFlow는 스케줄러와 워커를 분리해 이 문제를 구조적으로 다루려 합니다. (GitHub)
유지보수 문제도 큽니다. 프롬프트, 제목 라이브러리, 키워드, 이미지, 지식 베이스가 따로 놀면 어느 조합으로 어떤 결과가 나왔는지 추적하기 어렵습니다. 결과가 마음에 들지 않아도 원인을 좁히기 힘들고, 같은 실수를 반복하게 됩니다. GEOFlow는 이 요소들을 “소재”라는 운영 단위로 관리하도록 설계돼 있습니다. (GitHub)
마지막은 개발 경험 문제입니다. 많은 팀이 AI 기능을 붙일 때, 먼저 스크립트를 만들고 나중에 운영 시스템을 덧붙입니다. 그런데 이 순서는 대개 반대로 비용을 만듭니다. 작업 상태, 인증, 게시 흐름, 관리 화면이 뒤늦게 필요해지기 때문입니다. GEOFlow는 처음부터 Admin, API, CLI, Worker를 함께 두어 “운영 가능한 AI 콘텐츠 시스템”으로 접근합니다. (GitHub)
GEOFlow란 무엇인가
GEOFlow는 한 문장으로 정의하면, GEO/SEO 콘텐츠 운영을 위해 AI 생성과 검토·게시 워크플로를 하나로 묶은 오픈소스 시스템입니다. (GitHub)
쉽게 비유하면, 단순한 AI 글쓰기 버튼이 아니라 콘텐츠 공장의 생산 관리판에 가깝습니다. 원재료인 제목, 키워드, 이미지, 지식 문서를 넣고, 어떤 모델로 어떤 규칙으로 돌릴지 정한 뒤, 생성된 결과를 검토하고 최종 게시까지 이어지게 만드는 구조입니다. (GitHub)
기술적으로 보면 GEOFlow는 PHP 기반의 웹/관리 화면 위에, PostgreSQL 저장소, 스케줄러, 워커, API, CLI를 얹은 구조입니다. 여기서 핵심은 “생성”이 아니라 작업 단위의 라이프사이클 관리입니다. 즉, 프롬프트 한 번 호출하는 것이 아니라, 작업을 만들고 큐에 넣고 실행하고 실패를 처리하고 게시 상태를 바꾸는 흐름 전체를 다룹니다. (GitHub)
기존 방식과의 차이도 여기서 분명해집니다. 일반적인 AI 자동화는 모델 호출 중심입니다. 반면 GEOFlow는 콘텐츠 운영 시스템 중심입니다. 모델은 교체 가능한 부품이고, 더 중요한 것은 운영 체계입니다. OpenAI 스타일 API와 호환되는 여러 AI 서비스에 붙을 수 있게 만든 것도 그 철학의 연장선입니다. (GitHub)
핵심 특징

OpenAI 스타일 API 호환

특정 모델 벤더에 강하게 묶이지 않습니다.
이미 OpenAI 계열 인터페이스에 익숙한 팀이라면 모델 교체 비용을 낮출 수 있습니다. (GitHub)


작업 스케줄링과 큐 기반 실행

작업 생성, 예약 실행, 큐 적재, 워커 처리, 실패 재시도 흐름이 분리돼 있습니다.
한두 건 테스트가 아니라 배치 운영으로 넘어갈 때 의미가 커집니다. (GitHub)


소재의 중앙 관리

제목 라이브러리, 키워드, 이미지, 지식 베이스, 프롬프트를 한곳에서 관리합니다.
결과 품질보다 더 중요한 “재현 가능성”을 높여줍니다. (GitHub)


초안-검토-게시 워크플로

생성된 글이 바로 공개되는 구조가 아니라, 검토 단계를 거칠 수 있습니다.
운영팀과 편집팀이 함께 쓰기 좋은 이유가 여기 있습니다. (GitHub)


프론트 사이트까지 포함한 일체형 구성

백오피스만 있는 것이 아니라, 기사/카테고리/아카이브 페이지까지 함께 제공합니다.
즉시 운영형 사이트를 띄우려는 팀에는 초기 구축 부담을 줄여줍니다. (GitHub)


CLI와 API 동시 제공

관리 화면만으로 끝나지 않고 외부 자동화 파이프라인과도 연결할 수 있습니다.
사람이 누르는 운영과 스크립트가 호출하는 운영을 동시에 가져갈 수 있습니다. (GitHub)



실제로 어떤 효과가 있는가
공개된 자료 기준으로 보면, GEOFlow의 가장 큰 효과는 툴을 하나 더 추가하는 것이 아니라 흩어진 단계를 한 흐름으로 정리하는 것에 있습니다. 기존에는 모델 호출 스크립트, 프롬프트 파일, CMS 입력, 검수 기록이 분리돼 있었다면, GEOFlow는 이를 작업 관리와 게시 워크플로 안으로 끌어옵니다. (GitHub)
전과 후를 비교하면 차이는 더 분명합니다.
전에는 “생성 성공”이 끝이었습니다.
후에는 “작업 생성 → 큐 적재 → 생성 → 초안 저장 → 검토 → 게시”가 하나의 시스템 이벤트로 이어집니다. 이 차이는 규모가 커질수록 커집니다. 특히 주기적으로 많은 글을 발행하거나, 사람이 검토해야 하는 팀에 유리합니다. (GitHub)
효과가 극대화되는 상황은 세 가지입니다.
첫째, 반복적으로 유사한 형식의 콘텐츠를 대량 생산해야 할 때입니다.
둘째, 모델을 자주 바꾸거나 여러 공급자를 시험해야 할 때입니다.
셋째, 생성 결과를 바로 공개하면 안 되고 검토가 필요한 팀일 때입니다. (GitHub)
반대로 “한두 개 글을 수동으로 써보는 단계”에서는 이 시스템의 장점이 크게 드러나지 않을 수 있습니다. GEOFlow의 가치는 단일 생성 품질보다 운영 흐름을 구조화하는 데서 나오기 때문입니다. (GitHub)
동작 원리 / 구조

관리 화면에서 모델과 소재를 설정합니다.
여기서 AI 모델, 프롬프트, 제목 라이브러리, 이미지 라이브러리, 지식 베이스를 준비합니다.
이 단계를 분리한 이유는 생성 품질보다 먼저 입력 자산을 표준화하기 위해서입니다. (GitHub)
작업을 생성하고 실행 규칙을 정합니다.
어떤 모델을 쓸지, 어떤 소재를 쓸지, 게시 규칙을 어떻게 할지를 작업 단위로 저장합니다.
즉, “실행 요청”이 아니라 “운영 정책”을 하나 만든다고 보는 편이 맞습니다. (GitHub)
스케줄러가 작업을 큐에 넣습니다.
스케줄러는 주기적으로 실행되며, 실행 대상 작업을 찾아 job queue에 적재합니다.
생성과 스케줄링을 분리한 것은 병목 지점을 나누고 안정성을 높이기 위한 전형적인 설계입니다. (GitHub)
워커가 실제 AI 생성을 수행합니다.
워커는 큐에서 작업을 가져와 AI 서비스를 호출하고, 본문과 보조 메타데이터를 생성합니다.
실패 시 재시도나 상태 갱신이 가능하도록 작업 흐름이 서비스 계층에 묶여 있습니다. (GitHub)
결과를 초안으로 저장하고 검토 상태를 붙입니다.
생성 결과는 곧바로 공개되는 것이 아니라 초안, 검토, 게시 상태로 이동할 수 있습니다.
이 설계는 “콘텐츠 생성”과 “콘텐츠 출판”을 분리하기 위한 것입니다. (GitHub)
프론트엔드가 SEO 친화적인 페이지를 출력합니다.
최종 게시된 글은 기사 페이지, 카테고리 페이지, 아카이브 페이지 등으로 노출됩니다.
SEO 메타 정보와 구조화 데이터까지 염두에 둔 출력 구조를 갖고 있습니다. (GitHub)

이 구조를 한 줄로 요약하면 이렇습니다.
“생성 요청”을 즉시 모델에 보내는 것이 아니라, “운영 가능한 작업”으로 바꾼 뒤 시스템이 처리하게 만든다.
그래서 GEOFlow는 기능보다 구조가 먼저 보이는 프로젝트입니다. (GitHub)
설치 / 사용 방법
가장 빠른 방법은 Docker Compose 방식입니다. 공개 저장소 기준으로 웹, PostgreSQL, 스케줄러, 워커를 함께 올리는 형태가 기본입니다. Compose 설정에도 web, postgres, scheduler, worker 서비스가 분리돼 있습니다. (GitHub)
Docker로 실행
git clone https://github.com/yaojingang/GEOFlow.git
cd GEOFlow

cp .env.example .env

docker compose --profile scheduler up -d --build

기본 환경 변수 예시는 단순합니다.
HOST_PORT=18080
CRON_INTERVAL=60
APP_SECRET_KEY=replace-with-a-long-random-secret
SITE_URL=http://localhost:18080
TZ=Asia/Shanghai
REQUIRE_STRONG_APP_SECRET=false

실행 후 접근 흐름은 다음과 같습니다.
# 프론트
http://localhost:18080

# 관리자
http://localhost:18080/geo_admin/

로컬 PHP 서버로 실행
문서 기준으로는 PHP 7.4 이상과 pdo_pgsql, curl 확장이 필요합니다. 로컬 PostgreSQL도 준비되어 있어야 합니다. (GitHub)
git clone https://github.com/yaojingang/GEOFlow.git
cd GEOFlow

export DB_DRIVER=pgsql
export DB_HOST=127.0.0.1
export DB_PORT=5432
export DB_NAME=geo_system
export DB_USER=geo_user
export DB_PASSWORD=geo_password

php -S localhost:8080 router.php

최소 실행 예제
처음 접속 후의 실제 흐름은 아래처럼 이해하면 됩니다. (GitHub)
1) 관리자 로그인
2) AI 모델 등록
3) 제목/이미지/지식베이스/프롬프트 준비
4) 작업 생성
5) 스케줄러와 워커가 생성 실행
6) 초안 검토 후 게시

CLI도 제공합니다. 구조를 보면 config, login, catalog, task, job, article 명령을 지원합니다. 즉, UI 없이도 작업 조회나 게시 자동화를 붙일 수 있습니다. (GitHub)
php bin/geoflow login --base-url http://localhost:18080
php bin/geoflow task list
php bin/geoflow article list

자주 쓰는 예시 / 활용 시나리오
1. 반복형 콘텐츠 사이트 운영
누가 쓰는가.
콘텐츠 마케팅 팀이나 소규모 미디어 팀입니다.
언제 유리한가.
비슷한 형식의 글을 주기적으로 많이 발행해야 할 때입니다.
왜 쓰는가.
제목 라이브러리와 작업 스케줄을 결합해 반복 생산 흐름을 만들기 쉽기 때문입니다. (GitHub)
2. AI 에이전트 없이도 운영 가능한 생성 백엔드
누가 쓰는가.
복잡한 멀티에이전트 설계보다, 예측 가능한 운영 파이프라인이 필요한 개발팀입니다.
언제 유리한가.
생성 품질보다 작업 상태와 게시 흐름이 더 중요한 경우입니다.
왜 쓰는가.
작업, 큐, 워커, 게시 단계를 시스템 구조로 고정해 비결정성을 줄일 수 있기 때문입니다. (GitHub)
3. 모델 교체 실험용 운영 환경
누가 쓰는가.
여러 LLM 공급자를 비교하려는 팀입니다.
언제 유리한가.
같은 운영 흐름 위에서 모델만 바꿔보며 테스트하고 싶을 때입니다.
왜 쓰는가.
OpenAI 스타일 API 호환 구조 덕분에 통합 비용을 낮출 수 있기 때문입니다. (GitHub)
4. 내부 편집팀이 있는 AI 콘텐츠 운영
누가 쓰는가.
생성 결과를 사람이 검토해야 하는 조직입니다.
언제 유리한가.
법무 검수, 브랜드 톤 점검, 사실 확인이 필요한 콘텐츠를 다룰 때입니다.
왜 쓰는가.
초안-검토-게시 흐름이 이미 시스템에 포함돼 있기 때문입니다. (GitHub)
한계 / 주의할 점
첫째, 이 프로젝트는 범용 CMS가 아닙니다.
현재 기준으로는 GEO/SEO 콘텐츠 운영에 맞춘 구조가 강합니다. 일반적인 기업용 콘텐츠 플랫폼처럼 다양한 편집 협업 기능이나 복잡한 권한 체계를 기대하면 맞지 않을 수 있습니다. (GitHub)
둘째, 생성 품질 자체를 보장하는 도구로 보면 오해가 생깁니다.
GEOFlow는 좋은 글을 자동으로 보장하는 엔진이 아니라, 좋은 운영 구조를 제공하는 시스템입니다. 결과 품질은 결국 모델 선택, 프롬프트 설계, 지식 베이스 품질에 크게 좌우됩니다. (GitHub)
셋째, 작은 팀에게는 다소 무거울 수 있습니다.
한두 편의 글을 수동으로 올리는 수준이라면, 관리자 화면·DB·워커·스케줄러까지 갖춘 구조가 오히려 과할 수 있습니다. 이런 경우에는 단순 스크립트나 기존 CMS 플러그인이 더 낫습니다. 이는 문서상 명시된 한계라기보다, 공개된 구조를 기준으로 한 실무적 판단입니다. (GitHub)
넷째, 현재 문서 기준으로는 대규모 운영에서의 검증 범위가 넓게 공개돼 있지는 않습니다.
예를 들어 고가용성, 멀티 워커 확장 전략, 세밀한 권한 분리 같은 엔터프라이즈 운영 정보는 공개 자료에서 상세히 드러나지 않습니다. 따라서 대규모 상용 서비스에 바로 넣기 전에는 직접 검증이 필요합니다. (GitHub)
다섯째, 보안 기본값은 배포 직후 바로 손봐야 합니다.
문서상 기본 관리자 계정과 비밀번호가 제공되며, APP_SECRET_KEY도 별도로 설정해야 합니다. 즉, 테스트 편의성은 높지만 운영 배포 전 보안 설정은 반드시 다시 해야 합니다. (GitHub)
마무리
GEOFlow의 핵심 가치는 AI 모델을 더 잘 부르는 데 있지 않습니다.
그보다 콘텐츠 생성과 게시를 운영 가능한 시스템으로 바꾸는 데 있습니다.
이 프로젝트는 “AI가 글을 써준다”보다, “AI를 콘텐츠 운영 체계 안에 넣는다”에 가깝습니다. (GitHub)
그래서 이 도구는 특히 스타트업, AI 에이전트 개발자, 반복형 콘텐츠를 운영하는 팀, 검토가 필요한 게시 워크플로를 가진 조직에 잘 맞습니다. 반대로 단발성 생성 실험만 원하는 개인에게는 구조가 다소 크고 무겁게 느껴질 수 있습니다. (GitHub)
핵심 요약

핵심 개념

GEOFlow는 AI 콘텐츠 생성 도구가 아니라, 모델 설정부터 검토·게시까지를 묶은 운영 시스템이다. (GitHub)


차별점

Admin, API, CLI, Scheduler, Worker, Front site를 함께 제공해 “생성 이후의 운영”까지 다룬다. (GitHub)


언제 쓰면 좋은지

반복형 콘텐츠를 대량 생산해야 하거나, 검토 후 게시 흐름이 필요하거나, 여러 모델을 바꿔가며 운영해야 할 때 유리하다. (GitHub)


언제 쓰면 안 되는지

한두 편만 수동으로 생성하는 경우, 혹은 범용 CMS 수준의 협업 기능을 기대하는 경우에는 과할 수 있다. (GitHub)


한 줄 요약

GEOFlow는 “AI로 글을 쓰는 툴”이 아니라, AI 기반 콘텐츠 운영 파이프라인을 실제 서비스 구조로 바꾸는 프로젝트다. (GitHub)





Open Agents : Vercel의 자율 에이전트 SDK
행복한 수지아빠 — Tue, 14 Apr 2026 16:09:51 +0900
최근 AI 코딩 에이전트는 빠르게 늘어났지만, 실무에서 써보면 금방 한계가 드러납니다. 로컬에서 터미널을 켜 두고 지켜봐야 하고, 중간에 끊기면 다시 상태를 맞춰야 하며, 긴 작업은 요청-응답 수명 안에 가두기 어렵기 때문입니다. (GitHub)
Open Agents는 이 문제를 “에이전트를 오래 실행되게 만드는 방법”의 관점에서 다시 설계한 프로젝트입니다. 웹 UI, 워크플로우 기반의 에이전트 실행, 샌드박스 VM, 그리고 GitHub 연동을 한 구조로 묶어, 프롬프트에서 코드 변경과 푸시, PR 생성까지 이어지는 흐름을 만들었습니다. (GitHub)
이 글을 끝까지 읽으면 세 가지가 분명해집니다. 왜 기존 AI 코딩 에이전트가 실무에서 피로했는지, Open Agents가 그 문제를 어떤 아키텍처로 풀었는지, 그리고 이것이 단순한 데모가 아니라 기업용 AI 소프트웨어 팩토리의 뼈대로 왜 주목받는지입니다. (GitHub)
에이전트는 샌드박스와 워크플로우 기능을 활용해 시간 제한이나 타임아웃 없이 수많은 에이전트를 동시에 띄울 수 있고, 수 시간 동안 알아서 작업을 수행하며, 완료되면 깃허브에 코드를 저장하고 푸시까지 끝마칩니다.

 

open-agents/README.md at main · vercel-labs/open-agents
An open source template for building cloud agents. - vercel-labs/open-agents
github.com


 
왜 이 문제가 중요한가
AI 코딩 에이전트를 실제 개발 흐름에 넣으려면, 단순히 “코드를 잘 쓰는 모델”만으로는 부족합니다. 중요한 것은 긴 작업을 끊기지 않게 이어가고, 작업 상태를 보존하고, 결과를 실제 저장소 작업으로 연결하는 실행 구조입니다. (GitHub)
기존 방식은 비용 문제부터 드러납니다. 에이전트가 한 번의 대화 요청 안에서 모든 것을 처리하려고 하면, 컨텍스트를 계속 크게 들고 가야 하고, 실패했을 때 같은 맥락을 다시 불러오며 불필요한 모델 호출이 늘어납니다. 긴 작업일수록 이 비용은 더 커집니다. 이런 문제는 최근 에이전트 설계 논의에서도 반복해서 지적됩니다. (GitHub)
성능 문제도 큽니다. 요청 하나에 에이전트 실행을 몰아넣으면, 네트워크 지연이나 세션 종료, 브라우저 연결 해제 같은 외부 요인에 전체 실행이 흔들립니다. 작업이 길어질수록 “모델이 못해서”가 아니라 “실행 구조가 버티지 못해서” 실패하는 경우가 많아집니다. (GitHub)
유지보수 측면에서는 더 복잡합니다. 에이전트, 파일시스템, 셸 실행, Git 작업, 미리보기 서버가 한 덩어리처럼 얽히면 어디서 문제가 났는지 분리해서 보기 어렵습니다. 구조가 커질수록 디버깅 포인트도 늘어나고, 특정 모델이나 특정 실행 환경에 묶이는 순간 교체 비용도 커집니다. (GitHub)
개발 경험도 좋지 않습니다. 터미널을 계속 켜 두고 진행 상황을 지켜봐야 하고, 멈추면 수동으로 복구해야 하며, 여러 작업을 동시에 돌리기도 어렵습니다. 결국 “에이전트가 알아서 일한다”기보다 “사람이 에이전트를 계속 감시한다”에 가까워집니다. Open Agents는 바로 이 불편을 구조적으로 줄이려는 시도입니다. (GitHub)
Open Agents란 무엇인가
Open Agents는 백그라운드에서 오래 실행되는 코딩 에이전트를 만들기 위한 오픈소스 레퍼런스 앱입니다. 더 정확히 말하면, 웹 UI와 에이전트 런타임, 워크플로우, 샌드박스, GitHub 연동을 한 번에 묶어 놓은 “구조 예제”에 가깝습니다. (GitHub)
쉽게 비유하면 이렇습니다. 기존 방식이 “노트북 안에서 직접 일하는 1인 개발자”라면, Open Agents는 “지시를 받으면 별도 작업실로 가서 일하고, 끝나면 저장소에 반영까지 하고 돌아오는 비동기 팀원”에 가깝습니다.
기술적으로 중요한 정의는 따로 있습니다. 이 프로젝트는 에이전트를 샌드박스 안에 넣지 않습니다. 에이전트는 샌드박스 바깥에서 워크플로우로 실행되고, 샌드박스는 파일시스템·셸·Git·개발 서버를 제공하는 실행 환경으로 남습니다. 즉, “에이전트의 제어 평면”과 “코드가 실제로 돌아가는 실행 평면”을 분리한 구조입니다. (GitHub)
이 점이 기존 방식과 가장 다릅니다. 보통은 VM 안에서 에이전트가 직접 모든 걸 처리하게 만들기 쉽습니다. 하지만 Open Agents는 에이전트 수명주기와 샌드박스 수명주기를 분리해, 워크플로우는 오래 살아남고, 샌드박스는 필요할 때 깨우고 쉬게 만드는 철학을 택했습니다. 모델이나 제공자 교체도 이 분리 덕분에 상대적으로 쉬워집니다. (GitHub)
핵심 특징

웹 → 워크플로우 → 샌드박스의 3계층 구조
UI, 제어 로직, 실행 환경을 분리했습니다. 그래서 화면이 끊겨도 작업 상태와 실행 흐름을 독립적으로 이어가기 좋습니다. (GitHub)
에이전트가 요청 안에서 즉시 끝나지 않는 내구성 있는 실행
채팅 요청이 에이전트를 인라인으로 돌리는 것이 아니라 워크플로우 실행을 시작합니다. 각 턴이 여러 지속 단계로 이어질 수 있어 긴 작업에 유리합니다. (GitHub)
샌드박스 스냅샷 기반 재개
샌드박스는 스냅샷 기반으로 재개할 수 있고, 비활성 시 하이버네이트됩니다. 긴 작업을 전부 새로 시작하지 않고 상태를 이어가기 좋은 설계입니다. (GitHub)
GitHub 저장소 작업 자동화
저장소 클론, 브랜치 작업, 선택적 자동 커밋, 푸시, PR 생성까지 지원합니다. 즉 “코드를 제안하는 도구”를 넘어 “저장소 변경까지 연결되는 도구”로 확장됩니다. (GitHub)
모델·제공자와 실행 환경의 결합도 축소
공식 설명에서도 모델/프로바이더 선택과 샌드박스 구현을 따로 진화시킬 수 있다고 밝힙니다. 특정 모델 종속을 줄이려는 팀에게 중요한 포인트입니다. (GitHub)
포크해서 바꾸는 것을 전제로 한 레퍼런스 앱
이 저장소는 블랙박스로 쓰라고 만든 것이 아니라, 포크하고 내부 프로세스에 맞게 바꾸라고 만든 구조입니다. 기업이 자체 AI 개발 자동화 체계를 구축할 때 특히 의미가 있습니다. (GitHub)

실제로 어떤 효과가 있는가
공개된 자료 기준으로 보면, Open Agents의 가장 큰 효과는 “사람이 에이전트 실행을 계속 붙들고 있지 않아도 된다”는 점입니다. 작업 요청은 워크플로우로 넘어가고, 실제 파일 조작과 셸 실행은 샌드박스에서 처리되며, 완료 후에는 GitHub 반영까지 이어질 수 있습니다. (GitHub)
전과 후를 비교하면 차이가 분명합니다. 전에는 로컬 터미널 세션 중심으로 에이전트를 돌리며, 세션 유지와 상태 감시를 사람이 맡았습니다. 이후에는 웹 UI에서 작업을 던지고, 지속 가능한 워크플로우가 상태를 이어가며, 샌드박스가 실제 실행을 담당합니다. 인간은 실행자가 아니라 감독자에 가까워집니다. (GitHub)
효과가 가장 큰 상황도 뚜렷합니다. 코드 수정이 한두 파일에 그치지 않고, 저장소 전체 검색·셸 명령·브랜치 작업·미리보기 확인 같은 다단계 흐름이 필요한 경우입니다. 특히 “오래 걸리는 작업을 요청 수명주기에서 떼어내고 싶다”는 팀에서 체감이 큽니다. (GitHub)
어떤 팀에 특히 유리한지도 명확합니다. 내부 도구 팀, 플랫폼 엔지니어링 팀, AI 코딩 자동화 실험을 하는 조직, 여러 모델을 바꿔가며 자체 프로세스에 맞는 에이전트를 만들려는 기업에 잘 맞습니다. 단순 챗봇이 아니라 “AI 소프트웨어 팩토리”의 실행 계층을 직접 만들려는 조직일수록 가치가 커집니다. 이는 최근 Vercel이 강조하는 에이전트 인프라 방향성과도 맞닿아 있습니다. (Vercel)
다만 공개된 자료에는 “몇 배 빠르다” 같은 범용 정량 수치가 중심으로 제시되지는 않습니다. 그래서 이 도구의 가치는 벤치마크 숫자보다, 긴 실행·상태 보존·샌드박스 격리·GitHub 연계라는 운영 구조에서 판단하는 편이 더 정확합니다. (GitHub)
동작 원리 / 구조

사용자가 웹 UI에서 작업을 요청합니다.
이 계층은 인증, 세션, 채팅, 스트리밍 UI를 담당합니다. 중요한 점은 여기서 모든 일을 끝내지 않는다는 것입니다. 화면은 입력과 상태 표시를 맡고, 실제 장기 실행은 아래 계층으로 넘깁니다. (GitHub)
요청은 에이전트 워크플로우 실행으로 변환됩니다.
채팅 요청이 곧바로 에이전트 실행 본체가 되는 것이 아니라, 워크플로우 런이 시작됩니다. 이 설계 덕분에 실행은 단일 HTTP 요청에 묶이지 않고, 여러 지속 단계로 이어질 수 있습니다. (GitHub)
에이전트는 샌드박스 바깥에서 도구를 통해 샌드박스를 조작합니다.
파일 읽기, 수정, 검색, 셸 명령 같은 도구 호출을 통해 샌드박스와 상호작용합니다. 이때 샌드박스는 실행 환경일 뿐, 에이전트의 제어 평면이 아닙니다. 그래서 둘의 책임이 섞이지 않습니다. (GitHub)
샌드박스는 실제 코드 작업을 수행합니다.
파일시스템, 셸, Git, 개발 서버, 프리뷰 포트를 제공하고, 필요 시 하이버네이트 후 재개합니다. 이 구조는 “실행 중인 작업 공간”을 에이전트 논리와 분리해 재사용하고 관리하기 쉽게 만듭니다. (GitHub)
완료 후 결과를 저장소 흐름으로 연결합니다.
저장소 클론, 브랜치 작업, 자동 커밋, 푸시, PR 생성은 선택적으로 이어질 수 있습니다. 즉, 결과가 채팅 응답으로만 끝나지 않고 실제 코드 변경 이력으로 남습니다. (GitHub)
사용자는 다시 접속해 기존 실행을 이어서 볼 수 있습니다.
활성 실행은 기존 워크플로우 스트림에 다시 연결해 재개할 수 있습니다. 이것이 “에이전트를 오래 돌리는 구조”에서 매우 중요합니다. 브라우저 세션이나 탭 상태가 작업의 생존 조건이 아니기 때문입니다. (GitHub)

이 구조가 중요한 이유는 분명합니다. 에이전트는 판단과 제어를 맡고, 샌드박스는 실행과 격리를 맡으며, 웹은 상호작용을 맡습니다. 이 세 층이 섞이지 않아야 장기 실행, 장애 복구, 모델 교체, 운영 정책 분리가 쉬워집니다. Open Agents의 핵심은 기능보다 이 분리 원칙에 있습니다. (GitHub)
설치 / 사용 방법
현재 공개된 저장소 기준으로 로컬 실행 흐름은 비교적 단순합니다. 다만 “그냥 바로 실행되는 예제”라기보다, 데이터베이스와 시크릿, 인증 연동을 이해하고 설정해야 하는 레퍼런스 앱에 가깝습니다. 최소 런타임에는 PostgreSQL 연결 문자열과 JWE 시크릿이 필요하고, 실제 로그인 사용에는 추가 환경 변수가 필요합니다. (GitHub)
설치 명령어
git clone <open-agents 저장소>
cd open-agents
bun install
cp apps/web/.env.example apps/web/.env

최소 실행 흐름
# apps/web/.env에 필수 값 입력
POSTGRES_URL=...
JWE_SECRET=...

# 필요 시 로그인/연동 관련 값 추가
ENCRYPTION_KEY=...
NEXT_PUBLIC_VERCEL_APP_CLIENT_ID=...
VERCEL_APP_CLIENT_SECRET=...

# 실행
bun run web

로컬 개발에서 GitHub 저장소 접근, 푸시, PR 생성까지 사용하려면 GitHub App 관련 값도 추가로 필요합니다. 즉, 설치 자체보다 “권한과 연동을 어떻게 설계할 것인가”가 더 중요한 프로젝트입니다. (GitHub)
자주 쓰는 명령
bun run web
bun run check
bun run typecheck
bun run ci
bun run sandbox:snapshot-base

저장소 구조
apps/web         # Next.js 앱, 워크플로우, 인증, 채팅 UI
packages/agent   # 에이전트 구현, 도구, 서브에이전트, 스킬
packages/sandbox # 샌드박스 추상화와 Vercel Sandbox 연동
packages/shared  # 공통 유틸리티

이 구조만 봐도 의도가 드러납니다. UI, 에이전트 로직, 샌드박스 추상화가 나뉘어 있어서, 팀이 특정 부분만 교체하거나 내부 정책에 맞게 확장하기 좋습니다. (GitHub)
자주 쓰는 예시 / 활용 시나리오
1. 코드베이스 분석 자동화
플랫폼 팀이나 시니어 개발자가 대형 저장소를 한 번에 파악해야 할 때 유용합니다. 에이전트가 검색, 파일 읽기, 셸 실행을 이어가며 구조를 조사하고, 결과를 변경안이나 작업 브랜치로 연결할 수 있습니다. (GitHub)
2. 장시간 리팩터링 작업
여러 파일에 걸친 타입 수정, API 마이그레이션, 폴더 구조 정리처럼 오래 걸리는 작업에서 가치가 큽니다. 로컬 터미널 세션보다 워크플로우 기반 지속 실행이 유리하기 때문입니다. (GitHub)
3. 내부 개발 자동화 파이프라인
기업이 코드 생성, 수정, 검증, 커밋, PR 생성까지 하나의 자동 흐름으로 묶고 싶을 때 좋은 출발점이 됩니다. 특히 사내 정책에 맞춘 인증, 권한, 승인 흐름을 덧붙여 자체 플랫폼으로 확장하기 좋습니다. (GitHub)
4. 모델 비종속형 에이전트 플랫폼 실험
특정 모델 하나에 종속되지 않고, 모델 제공자나 실행 인프라를 바꿔가며 아키텍처를 검증하려는 팀에 적합합니다. 이 프로젝트는 저장소 자체가 그런 분리를 염두에 두고 설계되어 있습니다. (GitHub)
5. AI 소프트웨어 팩토리의 뼈대 구축
단순히 “채팅으로 코드 생성”을 넘어서, 요청 접수부터 작업 공간 준비, 실행, 결과 반영, 저장소 기록까지 이어지는 시스템을 만들고 싶다면 좋은 토대가 됩니다. 특히 여러 에이전트를 역할별로 나누는 구조로 확장하기 쉽습니다. (GitHub)
한계 / 주의할 점
첫째, 이것은 완제품보다 레퍼런스 앱에 가깝습니다. 문서상 확인되는 범위에서, 저장소도 블랙박스로 쓰기보다 포크해서 바꾸는 방식을 전제로 합니다. 즉, 바로 도입해 끝나는 제품이 아니라 내부 요구사항에 맞춰 조정해야 하는 베이스입니다. (GitHub)
둘째, Vercel 중심의 인프라 전제를 이해해야 합니다. 워크플로우, 샌드박스, OAuth, GitHub App, 데이터베이스 설정이 함께 맞물립니다. 그래서 단순히 로컬에서 에이전트를 하나 돌려보는 수준보다, 운영 환경을 설계하는 역량이 더 중요합니다. 현재 기준으로는 개인 취미 프로젝트보다 플랫폼 성격의 팀 프로젝트에 더 잘 맞습니다. (GitHub)
셋째, “모든 코딩 업무를 완전 자동화한다”는 식으로 이해하면 곤란합니다. 자동 커밋, 푸시, PR 생성은 지원되지만 항상 켜지는 강제 동작이 아니라 선택적 기능입니다. 결국 중요한 것은 자동화의 범위를 팀 정책에 맞게 제한하는 일입니다. (GitHub)
넷째, 아직 검증 범위를 과장해서 보면 안 됩니다. 공개된 자료 기준으로는 구조와 실행 방식은 분명하지만, 모든 산업군과 모든 개발 문화에서 동일하게 잘 맞는다고 보기는 어렵습니다. 승인 체계가 강한 조직, 보안 규제가 엄격한 조직, 레거시 저장소가 복잡한 조직은 추가 설계가 필요합니다. (GitHub)
다섯째, “샌드박스가 있으니 안전하다”는 단순한 해석도 위험합니다. 샌드박스는 격리된 실행 환경이지만, 실제 운영에서는 권한 범위, 비밀값 관리, GitHub App 권한, 리뷰 프로세스 설계가 함께 필요합니다. 도구보다 운영 정책이 더 중요해지는 구간입니다. (GitHub)
마무리
Open Agents의 핵심 가치는 AI 코딩 에이전트를 더 똑똑하게 만드는 데만 있지 않습니다. 더 중요한 것은 에이전트를 오래 실행되고, 상태를 이어가고, 실제 저장소 작업으로 연결되는 구조로 바꿨다는 점입니다. (GitHub)
그래서 이 프로젝트는 “AI가 코드를 써준다”는 데모보다 한 단계 더 현실적입니다. 사람의 노트북과 터미널에 묶여 있던 에이전트를, 워크플로우와 샌드박스 위에서 관리 가능한 시스템으로 끌어올리기 때문입니다. (GitHub)
특히 스타트업의 내부 플랫폼 팀, AI 에이전트 개발자, 대규모 코드베이스를 운영하는 조직, 그리고 특정 모델에 종속되지 않는 자체 AI 소프트웨어 팩토리를 고민하는 팀에게 유용합니다. 반대로 단순한 코드 생성 챗봇만 필요하다면, 이 구조는 다소 무겁게 느껴질 수 있습니다. (GitHub)
핵심 요약

핵심 개념
Open Agents는 웹 UI, 내구성 있는 워크플로우 실행, 샌드박스 VM, GitHub 연동을 결합한 백그라운드 코딩 에이전트 레퍼런스 앱입니다. (GitHub)
차별점
에이전트를 샌드박스 안에 넣지 않고, 워크플로우와 샌드박스를 분리해 장기 실행·상태 보존·모델 비종속성·실행 환경 교체 가능성을 확보한 점이 핵심입니다. (GitHub)
언제 쓰면 좋은지
장시간 코딩 작업, 저장소 단위 자동화, 브랜치/PR까지 이어지는 개발 흐름, 기업 내부 AI 소프트웨어 팩토리 구축을 고민할 때 특히 좋습니다. (GitHub)
언제 쓰면 안 되는지
단순한 로컬 코드 생성 보조, 가벼운 개인 실험, 인프라와 권한 설계를 감당하기 어려운 팀에는 과할 수 있습니다. (GitHub)
한 줄 요약
Open Agents는 AI 코딩 에이전트를 “터미널에서 잠깐 돌리는 도구”에서 “오래 실행되고 저장소까지 책임지는 시스템”으로 바꾸는 오픈소스 구조입니다. (GitHub)



ralph-orchestrator : ralph + 자율 에이전트
행복한 수지아빠 — Tue, 14 Apr 2026 16:08:17 +0900
이 글은 ralph-orchestrator가 왜 등장했고, 자율 AI 에이전트 워크플로우를 어떻게 더 안정적으로 만들려는지 이해하기 위해 작성되었습니다. 단순히 “에이전트를 계속 돌리는 도구”로 보면 이 프로젝트의 핵심을 놓치게 됩니다. 이 도구가 겨냥하는 문제는 기능 부족이 아니라, 에이전트가 똑똑할수록 오히려 전체 흐름은 더 불안정해질 수 있다는 점입니다. (GitHub)
기존 자율 에이전트 방식은 보통 하나의 강한 프롬프트에 많은 책임을 몰아넣습니다. 계획도 세우고, 코드도 짜고, 테스트도 돌리고, 실패 원인도 스스로 해석하게 만듭니다. 처음엔 단순해 보이지만, 작업이 길어질수록 컨텍스트가 비대해지고, 실패 원인이 흐려지고, “됐다고 했는데 실제로는 안 된 상태”가 자주 생깁니다. ralph-orchestrator는 이 문제를 일부러 더 단순한 역할 단위로 쪼개고, 이벤트와 검증 게이트로 연결하는 방식으로 다룹니다. (mikeyobrien.github.io)
이 글을 끝까지 읽으면 세 가지가 분명해집니다. 기존 자율 에이전트 루프와 무엇이 다른지, 어떤 팀과 프로젝트에서 이득이 큰지, 그리고 언제는 오히려 과한 구조가 되는지입니다. 레포와 문서 기준으로 확인되는 범위 안에서 구조, 동작 원리, 사용 흐름, 한계를 한 번에 연결해 보겠습니다. (GitHub)

 

GitHub - mikeyobrien/ralph-orchestrator: An improved implementation of the Ralph Wiggum technique for autonomous AI agent orches
An improved implementation of the Ralph Wiggum technique for autonomous AI agent orchestration - mikeyobrien/ralph-orchestrator
github.com


 
왜 이 문제가 중요한가
자율 에이전트를 실무에 붙이면 가장 먼저 부딪히는 건 정확도보다 신뢰성입니다. 모델이 한 번 잘 푸는 문제보다, 여러 단계가 이어지는 작업을 계속 비슷한 품질로 마무리할 수 있느냐가 더 중요합니다. 그런데 단일 에이전트 방식은 이 지점에서 흔들리기 쉽습니다. 한 프롬프트가 너무 많은 책임을 가지면, 어느 단계에서 판단이 어긋났는지 추적하기가 어렵습니다. (mikeyobrien.github.io)
비용 문제도 바로 연결됩니다. 문서상 구조를 보면 Ralph는 컨텍스트 윈도우를 40~60% 수준의 “smart zone”으로 유지하려 하고, 이벤트는 데이터를 싣는 통로가 아니라 작은 라우팅 신호로 쓰며, 자세한 내용은 메모리 쪽으로 밀어냅니다. 이 말은 곧 긴 작업일수록 “한 번에 다 들고 가는 방식”이 토큰 비용과 맥락 관리 면에서 불리하다는 뜻입니다. (mikeyobrien.github.io)
성능 문제도 단순한 속도 문제가 아닙니다. 에이전트가 코드를 수정하고 “완료”라고 말했는데 테스트를 안 돌렸거나, 테스트는 돌렸지만 실패 로그를 잘못 해석하는 경우가 생깁니다. Ralph는 이런 상황을 줄이기 위해 backpressure, 즉 통과 근거가 없으면 다음 단계로 못 넘어가게 하는 구조를 전면에 둡니다. “어떻게 할지”를 세세히 지시하기보다 “무엇이 완료인지”를 엄격하게 정의하는 쪽입니다. (mikeyobrien.github.io)
유지보수와 개발 경험도 중요합니다. 워크플로우가 커질수록 단일 프롬프트는 비결정성이 커지고, 프롬프트 수정이 곧 전체 시스템 수정이 됩니다. 반면 Ralph는 hat, event, backend, memory, task 같은 축으로 책임을 나눠 둡니다. 역할을 분리하면 디버깅 포인트도 분리되고, 특정 단계만 교체하거나 강화하기 쉬워집니다. (mikeyobrien.github.io)
ralph-orchestrator란 무엇인가
한 문장으로 정의하면, LLM이 스스로 똑똑하게 다 하길 기대하기보다, 단순한 역할이 이벤트를 주고받으며 반복 작업을 끝낼 때까지 조율하는 자율 에이전트 오케스트레이터입니다. 레포 설명에서도 이 프로젝트는 “task is done”까지 에이전트를 루프에 유지하는 hat-based orchestration framework로 소개됩니다. (GitHub)
쉽게 비유하면 이렇습니다. 한 명의 만능 요리사에게 “메뉴 구상, 재료 손질, 조리, 플레이팅, 위생 검사까지 전부 알아서 해”라고 맡기면 빠를 때도 있지만 실수도 커집니다. 반대로 주방장이 “이건 계획해”, “이건 만들어”, “이건 검증해”처럼 단위를 분리하면, 각 단계는 단순해지고 전체 흐름은 더 통제 가능해집니다. Ralph의 hat이 바로 이 분리된 역할입니다. (mikeyobrien.github.io)
기술적으로 보면 hat은 트리거되는 이벤트, 발행할 수 있는 이벤트, 활성화될 때 주입되는 지시문으로 구성됩니다. 이벤트는 topic, payload, source hat, target hat 같은 필드를 가지며, 이벤트 버스가 이를 라우팅합니다. 즉 이 도구의 철학은 “거대한 자율성”보다 작은 역할과 명확한 상태 전이에 가깝습니다. (mikeyobrien.github.io)
기존 방식과의 차이도 여기서 분명합니다. 많은 에이전트 프레임워크가 “더 많은 도구, 더 많은 추론, 더 긴 컨텍스트”로 문제를 풀려 한다면, Ralph는 오히려 한 역할당 하나의 책임, 작은 이벤트, 검증 근거가 포함된 완료 신호를 권장합니다. 그래서 이 프로젝트는 단순한 자동화 도구라기보다, 자율 워크플로우를 설계하는 하나의 운영 원칙에 가깝습니다. (mikeyobrien.github.io)
핵심 특징

Hat 기반 역할 분리
planner, builder, critic, finalizer 같은 역할을 나눠 실행할 수 있습니다. 한 에이전트가 모든 판단을 떠안지 않게 만들어, 실패 원인을 단계별로 분리하기 쉽습니다. (mikeyobrien.github.io)
이벤트 중심 오케스트레이션
task.start, plan.ready, build.done 같은 typed event로 흐름을 이동시킵니다. 이 구조 덕분에 워크플로우를 프롬프트 덩어리가 아니라 상태 전이로 다룰 수 있습니다. (mikeyobrien.github.io)
Backpressure 기반 품질 게이트
테스트, 린트, 타입체크, 보안 점검 같은 증거가 없으면 완료로 인정하지 않는 설계를 지원합니다. “대충 끝났다”는 선언을 구조적으로 막으려는 점이 핵심입니다. (mikeyobrien.github.io)
멀티 백엔드 지원
Claude Code, Kiro, Gemini CLI, Codex, Amp, Copilot CLI, OpenCode를 지원하며 자동 감지와 명시적 선택이 가능합니다. 특정 모델이나 CLI에 종속되지 않고 오케스트레이션 계층을 분리하려는 의도가 보입니다. (GitHub)
지속 상태 관리
.agent/ 아래에 memories, tasks, event history 같은 상태를 저장합니다. 긴 작업에서 이전 판단과 작업 흔적을 잃지 않도록 한 설계입니다. (mikeyobrien.github.io)
작게 유지되는 기본 프리셋
기본 builtin은 code-assist, debug, research, review, pdd-to-code-assist 정도로 작게 유지됩니다. 문서상 설명도 “지원 표면적을 줄이고 테스트 가능한 범위에 집중하겠다”는 방향입니다. (GitHub)

실제로 어떤 효과가 있는가
공개된 자료 기준으로 보면 Ralph가 강조하는 효과는 숫자형 성능 벤치마크보다 실패 방식의 통제에 있습니다. 즉 “더 똑똑해진다”보다는 “덜 엉뚱하게 실패한다”에 가깝습니다. 계획, 구현, 검증, 최종 완료를 서로 다른 역할로 나누고, 각 단계가 근거를 싣고 다음 단계로 넘어가게 만들면 완료 선언의 품질이 안정됩니다. (mikeyobrien.github.io)
전후 비교로 보면, 기존 방식은 하나의 프롬프트 안에서 계획과 실행과 검증이 섞여 있습니다. Ralph 방식은 planner → builder → critic/finalizer처럼 역할을 분리하고, 필요하면 reviewer가 빌더의 주장을 다시 검증합니다. 이 구조는 특히 여러 번 수정과 검증이 반복되는 개발 작업에서 효과가 커집니다. (mikeyobrien.github.io)
효과가 극대화되는 상황도 비교적 분명합니다. 코드 수정 후 테스트, 린트, 타입체크, 문서 반영까지 여러 단계가 이어지는 작업, 또는 디버깅처럼 “원인 분석”과 “수정”을 분리해야 하는 작업에 잘 맞습니다. 반대로 한 번의 짧은 생성 작업이라면 이 구조가 주는 이득보다 오버헤드가 더 클 수 있습니다. (mikeyobrien.github.io)
특히 유리한 팀은 AI 에이전트를 개인 장난감이 아니라 반복 가능한 팀 워크플로우로 다루려는 곳입니다. 스타트업의 빠른 프로토타이핑, AI 개발도구를 실험하는 팀, 대규모 코드베이스에서 작업 완료 기준을 엄격히 관리해야 하는 팀에 잘 맞습니다. 현재 GitHub 기준으로 이 프로젝트는 공개 저장소로 운영되고 있고, 2026년 4월 10일 기준 최신 릴리스는 2.9.2이며, GitHub 페이지에는 약 2.7k 스타가 표시됩니다. 관심과 유지보수도 일정 수준 확인됩니다. (GitHub)
동작 원리 / 구조

입력을 받습니다.
보통 ralph run -p "..." 형태로 작업을 시작하거나, ralph plan으로 먼저 계획 문서를 만듭니다. 빠른 시작 문서에서는 ralph init으로 백엔드를 선택하고, ralph plan으로 요구사항·설계·구현 계획 파일을 만든 뒤, ralph run으로 구현을 이어가는 흐름을 제시합니다. (GitHub)
설정과 역할 컬렉션을 불러옵니다.
기본 설정은 ralph.yml에서 읽고, 필요하면 -c로 core 설정을 덮어쓰며, -H로 hat collection을 따로 지정할 수 있습니다. 이 분리는 “실행 환경 설정”과 “워크플로우 정의”를 अलग-अलग 다루게 해 줍니다. (mikeyobrien.github.io)
이벤트 루프가 시작됩니다.
아키텍처 문서상 핵심 엔진은 ralph-core의 EventLoop입니다. 전통적 모드에서는 프롬프트를 백엔드로 보내고 출력이 LOOP_COMPLETE인지 확인하며 반복하고, hat-based 모드에서는 시작 이벤트가 이벤트 버스로 들어가고 매칭되는 hat이 실행됩니다. (mikeyobrien.github.io)
활성화된 hat의 지시문이 주입됩니다.
각 hat은 어떤 이벤트에서 켜지고, 어떤 이벤트를 발행할 수 있는지, 그리고 어떤 지시를 받아야 하는지가 정의돼 있습니다. 이 과정에서 역할이 작게 유지될수록 모델이 해야 할 판단도 작아집니다. 그래서 문서도 “한 hat에 하나의 책임”을 강하게 권장합니다. (mikeyobrien.github.io)
백엔드 CLI가 실제 작업을 수행합니다.
ralph-adapters가 Claude, Gemini, Codex 같은 CLI 백엔드를 연결하고, PTY 기반 실행과 스트림 처리를 담당합니다. 오케스트레이터는 모델 그 자체가 아니라, 모델을 호출하는 실행 계층을 감싸는 구조입니다. (mikeyobrien.github.io)
출력을 파싱해 이벤트나 완료 상태로 바꿉니다.
에이전트가 ralph emit으로 이벤트를 발행하면 이벤트 버스가 다음 hat으로 넘깁니다. 완료 신호가 오면 종료하고, 아니면 다음 반복으로 이어집니다. 결국 이 시스템의 본질은 “대화”보다 상태 머신에 가까운 루프 제어입니다. (mikeyobrien.github.io)
메모리와 작업 상태를 디스크에 남깁니다.
.agent/ 아래의 memories.md, tasks.jsonl, event_history.jsonl 같은 파일이 여기에 해당합니다. 이 설계 덕분에 긴 작업에서도 결과와 근거를 외부 상태로 보관할 수 있고, 이벤트는 작게 유지할 수 있습니다. (mikeyobrien.github.io)

이렇게 설계된 이유는 명확합니다. 긴 자율 작업에서 가장 큰 적은 “모델이 순간적으로 똑똑하지 않은 것”보다 전체 흐름이 한 덩어리로 엉켜 있는 것이기 때문입니다. Ralph는 그 엉킴을 줄이기 위해 루프, 역할, 이벤트, 검증을 나눴습니다. (mikeyobrien.github.io)
설치 / 사용 방법
문서 기준 권장 설치 방식은 npm입니다. Cargo와 GitHub 릴리스 설치 스크립트도 제공됩니다. (GitHub)
npm install -g @ralph-orchestrator/ralph-cli

cargo install ralph-cli

가장 기본적인 실행 흐름은 아래와 같습니다. 백엔드를 초기화하고, 계획을 만들고, 그 계획을 구현하는 순서입니다. (GitHub)
# 1) 초기화
ralph init --backend claude

# 2) 기능 계획
ralph plan "Add user authentication with JWT"

# 3) 구현 실행
ralph run -p "Implement the feature in specs/user-authentication/"

더 짧게 시작하려면 바로 실행할 수도 있습니다. 이 경우 복잡한 구조 설계 없이 기본 루프부터 시험해 볼 수 있습니다. (GitHub)
ralph run -p "Add input validation to the /users endpoint"

내장 hat 컬렉션을 명시적으로 쓰고 싶다면 이런 형태도 가능합니다. code-assist가 기본 구현 작업용으로 권장되고, debug, research, review 같은 특화 모드가 따로 준비돼 있습니다. (mikeyobrien.github.io)
ralph init --backend claude
ralph run -c ralph.yml -H builtin:code-assist -p "Add OAuth login"

최소 실행 예제를 하나만 더 들면, Ralph식 워크플로우의 핵심은 “역할 분리 + 증거 기반 완료”입니다. 예를 들어 builder가 일을 마친 뒤 이렇게 이벤트를 발행하게 만들 수 있습니다. (mikeyobrien.github.io)
ralph emit "build.done" "tests: pass, lint: pass, typecheck: pass"

자주 쓰는 예시 / 활용 시나리오
코드베이스 기능 구현 자동화
누가 보더라도 가장 직접적인 활용처입니다. planner가 작업을 쪼개고, builder가 구현하고, critic이나 finalizer가 검토하는 식으로 흘러갑니다. 단순 코드 생성보다 “완료 조건이 있는 구현 작업”에 더 어울립니다. (mikeyobrien.github.io)
디버깅 전용 루프
버그 수정은 구현과 다르게 원인 재현, 원인 분석, 수정, 검증이 분리돼야 합니다. 문서상 debug builtin은 investigator, tester, fixer, verifier 같은 역할로 이 흐름을 강화합니다. 단일 프롬프트보다 실패 원인을 남기기 좋습니다. (mikeyobrien.github.io)
리뷰 전용 오케스트레이션
코드를 바꾸지 않고 읽기만 하면서 위험 요소를 찾는 review, 읽고 요약하는 research 같은 모드도 있습니다. 운영 코드 수정 없이 분석 워크플로우를 따로 돌리고 싶을 때 유용합니다. (mikeyobrien.github.io)
스펙 기반 개발 흐름
빠른 시작 문서에 ralph plan이 따로 있는 이유도 여기 있습니다. 요구사항, 설계, 구현 계획을 먼저 파일로 만들고 나서 구현 루프로 넘기면, 에이전트가 “무엇을 만들지”와 “어떻게 만들지”를 섞어버리는 문제를 줄일 수 있습니다. (GitHub)
사람 개입이 필요한 반자동 워크플로우
Telegram 기반의 RObot 기능을 통해 에이전트가 질문을 던지고, 사람이 중간에 방향을 수정할 수 있습니다. 완전 무인 자율보다, 장기 실행 중에 사람 승인이 필요한 팀에 더 현실적입니다. (GitHub)
한계 / 주의할 점
가장 먼저 짚어야 할 점은, 이 도구가 자율 에이전트의 불확실성을 없애는 도구는 아니라는 것입니다. 문서상 확인되는 범위에서 보면 Ralph는 모델 품질 자체를 대체하지 않습니다. 모델이 잘못 판단할 가능성은 여전히 있고, 다만 그 실수를 더 작은 단계에서 드러내고 되돌리기 쉽게 만들 뿐입니다. (mikeyobrien.github.io)
적용이 어려운 경우도 있습니다. 작업이 아주 짧고 단순하면 hat, event, gate를 설계하는 비용이 오히려 더 큽니다. 한두 번의 생성으로 끝나는 개인 작업이라면, 일반적인 단일 에이전트 호출이 더 빠를 수 있습니다. Ralph는 길고 반복적이며 검증이 필요한 흐름에서 이득이 커집니다. (mikeyobrien.github.io)
비용 측면에서도 오해하면 안 됩니다. 역할 분리와 검증 루프는 실패를 줄이는 대신 호출 수를 늘릴 수 있습니다. 문서에는 작업 유형별 권장 예산과 반복 최적화, 비용 모니터링, 자동 중단 같은 안내가 따로 있을 정도로, 이 시스템은 애초에 비용 관리가 중요한 도구입니다. 즉 “오케스트레이션을 넣으면 무조건 싸진다”가 아니라, 큰 실패를 줄여 총비용을 관리하려는 접근으로 보는 편이 맞습니다. (mikeyobrien.github.io)
현재 기준으로는 웹 대시보드도 알파 상태입니다. 문서상 “rough edges and breaking changes”가 명시돼 있어, 핵심은 여전히 CLI와 설정 기반 사용에 있습니다. 실무 도입 시에는 먼저 CLI 루프와 프리셋을 익힌 뒤, 대시보드는 보조 도구로 보는 편이 안전합니다. (GitHub)
또 하나는 구조 복잡도입니다. 문서가 일부러 내장 프리셋 수를 줄이고 “작은 supported set”을 유지하는 이유도 여기에 있습니다. 워크플로우를 너무 많이 제품 표면으로 끌어올리면, 문서화와 테스트와 유지보수 비용이 폭증합니다. 자율 워크플로우 설계에서 가장 흔한 실패는 기능 부족보다 구조 과잉입니다. (mikeyobrien.github.io)
마무리
ralph-orchestrator의 핵심 가치는 “에이전트를 더 똑똑하게 만들겠다”가 아닙니다. 오히려 에이전트가 복잡하게 굴지 않아도 되도록, 역할과 검증 구조를 먼저 설계하겠다에 가깝습니다. 그래서 이 프로젝트는 모델 성능보다 워크플로우 신뢰성에 관심이 많은 사람에게 더 중요합니다. (GitHub)
특히 스타트업, AI 에이전트 개발자, 반복적인 코드 수정과 검증이 많은 팀, 대규모 코드베이스를 운영하는 팀이라면 참고할 가치가 큽니다. 반대로 짧고 단발성인 작업이라면 이 구조가 과할 수 있습니다. 결국 이 도구가 던지는 메시지는 단순합니다. 자율성은 크게 주는 것보다, 잘게 나눠 통제하는 편이 더 실용적일 때가 많다는 것입니다. (mikeyobrien.github.io)
핵심 요약

핵심 개념
ralph-orchestrator는 hat, event, backpressure를 이용해 자율 에이전트 작업을 역할 단위로 분리해 조율하는 오케스트레이터입니다. (GitHub)
차별점
큰 단일 프롬프트에 모든 책임을 몰지 않고, 작은 역할과 증거 기반 완료 신호로 흐름을 설계합니다. (mikeyobrien.github.io)
언제 쓰면 좋은지
구현, 디버깅, 리뷰, 스펙 기반 개발처럼 여러 단계와 검증 기준이 있는 장기 작업에 적합합니다. (mikeyobrien.github.io)
언제 쓰면 안 되는지
단순하고 짧은 생성 작업, 역할 분리보다 속도가 더 중요한 개인성 업무에는 오버헤드가 될 수 있습니다. (mikeyobrien.github.io)
한 줄 요약
ralph-orchestrator는 “강한 단일 에이전트”보다 “단순한 역할들의 통제된 협업”으로 자율 워크플로우 신뢰성을 높이려는 구현체입니다. (mikeyobrien.github.io)



Stretchy Studio: PSD,PNG->2D 캐릭터로 변경
행복한 수지아빠 — Tue, 14 Apr 2026 16:07:23 +0900


정적인 PSD나 PNG를 가져와서, 복잡한 리깅 작업 없이 빠르게 2D 캐릭터 애니메이션으로 바꾸는 흐름을 설명합니다. 특히 이 도구가 단순한 편집기가 아니라, 레이어 분해된 캐릭터를 실제 애니메이션 파이프라인으로 연결하는 데 초점을 둔 이유를 다룹니다. (GitHub)
기존 2D 캐릭터 애니메이션 도구는 크게 두 가지 불편이 있었습니다. 하나는 본 세팅과 파라미터 설계가 무겁다는 점이고, 다른 하나는 AI가 분해해 준 레이어를 실제 애니메이션 가능한 구조로 옮기는 과정이 생각보다 수작업 중심이라는 점입니다. Stretchy Studio는 이 사이를 메우기 위해, 타임라인 중심 편집과 메쉬 변형을 결합하는 방향으로 설계되었습니다. (GitHub)
이 글을 끝까지 읽으면 세 가지가 잡힙니다. 왜 이 도구가 기존 Live2D식 접근과 다른지, 어떤 구조로 동작하는지, 그리고 실제로 어떤 팀이나 프로젝트에서 유리한지입니다. 동시에 아직 부족한 부분과 당장 쓰기 전에 알아야 할 주의점도 함께 정리합니다. (GitHub)
왜 이 문제가 중요한가
2D 캐릭터 애니메이션 제작은 생각보다 비용이 큽니다. 레이어를 정리하고, 본을 잡고, 변형 포인트를 설계하고, 타임라인을 세팅하는 과정이 모두 사람 손을 탑니다. 캐릭터 수가 늘어나면 작업량은 거의 선형이 아니라 관리 복잡도까지 포함해 더 가파르게 증가합니다.
성능 문제도 있습니다. 단순 이미지 레이어만 다룰 때는 가볍지만, 리깅과 변형 시스템이 들어가면 렌더링과 편집 상태 관리가 복잡해집니다. 특히 계층 구조, 드로우 오더, 메시 편집, 키프레임 보간이 한 화면 안에서 같이 돌아가야 해서 툴 구조가 금방 무거워집니다. (GitHub)
유지보수 관점에서도 어려움이 큽니다. 파라미터 기반 툴은 기능이 늘수록 상태 조합이 폭발하고, 디버깅 포인트도 많아집니다. 어떤 포즈가 왜 그렇게 나왔는지 추적하기 어렵고, 애니메이션 결과가 추상 파라미터에 묶이면 수정 비용도 올라갑니다. (GitHub)
개발 경험도 문제입니다. 구조가 복잡해질수록 “가져오기 → 리깅 → 수정 → 애니메이션 → 저장”의 전체 흐름을 끝까지 작동시키기가 어려워집니다. Stretchy Studio는 이 문제를 의식해, 각 마일스톤마다 끝에서 끝까지 동작하는 얇은 기능 조각을 만드는 방식으로 발전해 왔습니다. (GitHub)

 

stretchystudio/PROJECT_STATUS.md at master · MangoLion/stretchystudio
FOSS 2D animation tool for turning static illustrations into mesh-deformable characters - MangoLion/stretchystudio
github.com


 
Stretchy Studio란 무엇인가
Stretchy Studio는 정적인 2D 레이어 이미지를 가져와, 메쉬 변형과 스켈레톤 기반 조작을 통해 빠르게 애니메이션 가능한 캐릭터로 바꾸는 웹 기반 2D 애니메이션 툴입니다. (GitHub)
비유하면 이 도구는 “포토샵 레이어를 바로 만질 수 있는 경량 애니메이션 스튜디오”에 가깝습니다. 그림을 가져오고, 필요한 부분만 메쉬를 만들고, 관절을 잡고, 타임라인 위에서 바로 움직이는 방식입니다.
기술적으로는 전통적인 본 회전 중심 방식만 쓰지 않습니다. 필요한 부위에는 스켈레톤을 얹고, 더 유기적인 움직임이 필요한 부위에는 메시 정점 변형을 직접 적용합니다. 그래서 단순 회전보다 더 부드러운 머리카락, 눈, 팔다리 움직임을 만들 수 있습니다. (GitHub)
기존 방식과 가장 큰 차이는 철학입니다. 이 프로젝트는 원래 Live2D 스타일의 파라미터 시스템을 고려했지만, 이후 이를 버리고 타임라인 우선 구조로 방향을 틀었습니다. 즉, 추상 파라미터를 설계하는 도구가 아니라, 애니메이터가 바로 키프레임을 찍는 도구에 더 가깝습니다. (GitHub)
핵심 특징

타임라인 우선 편집 구조
파라미터를 설계하는 대신 키프레임 중심으로 움직입니다. 그래서 처음 쓰는 사람도 상태 모델보다 결과 화면에 집중하기 쉽습니다. (GitHub)
메쉬 온디맨드 생성
가져온 모든 레이어에 즉시 무거운 메쉬를 만들지 않습니다. 처음에는 단순 쿼드로 렌더링하고, 필요한 파트만 나중에 메쉬를 생성해 비용과 복잡도를 줄입니다. (GitHub)
PSD 기반 다층 가져오기와 자동 정리
PSD 레이어를 유지한 채 가져오고, 특정 캐릭터 태그 패턴을 인식해 머리·눈·상체·하체 같은 구조로 자동 그룹화합니다. 초기 세팅 시간을 줄이는 데 중요한 기능입니다. (GitHub)
휴리스틱 리깅과 AI 리깅을 함께 지원
빠른 시작이 필요하면 경계 상자 기반 휴리스틱 리깅을, 정확도가 더 필요하면 DWPose 기반 ONNX 추정을 사용할 수 있습니다. 즉시성와 정확도 사이에서 선택할 수 있습니다. (GitHub)
정점 변형 기반의 유기적 움직임
회전만으로는 부족한 부위에 정점 단위 변형을 적용할 수 있습니다. 그래서 숨쉬기, 머리카락 흔들림, 미세한 표정 변화 같은 표현에 유리합니다. (GitHub)
프로젝트 저장/불러오기 구조가 이미 들어가 있음
현재 기준으로 .stretch 포맷 저장과 로드가 구현되어 있습니다. 실험용 프로토타입을 넘어서, 작업 지속성을 염두에 둔 구조라는 점이 중요합니다. (GitHub)

실제로 어떤 효과가 있는가
공개된 자료 기준으로 보면, Stretchy Studio의 효과는 “세팅 시간 단축”과 “전체 흐름 일체화”에 가깝습니다. PSD를 가져온 뒤 그룹 정리, 리깅, 타임라인 편집, 저장/불러오기까지 한 툴 안에서 이어지기 때문에, 툴 사이를 오가며 자산을 다시 맞추는 비용이 줄어듭니다. (GitHub)
전후 비교로 보면 차이가 더 선명합니다. 기존 방식은 레이어 정리 후 별도 리깅과 별도 애니메이션 세팅이 필요했다면, 이 프로젝트는 가져오기 직후 자동 그룹화와 리깅 보조를 제공하고 바로 타임라인 작업으로 넘어갑니다. 특히 see-through 방식처럼 이미 분해된 캐릭터 자산이 있을수록 효과가 커집니다. (GitHub)
성능 측면에서는 현재 프로젝트 상태 문서 기준으로, 리깅된 캐릭터와 애니메이션 재생에서 60fps를 목표로 하고 있으며 저장은 200~500ms, 불러오기는 500ms~2초 수준으로 정리되어 있습니다. 또한 저장 포맷은 base64 JSON 방식 대비 파일 크기를 40~60% 수준으로 줄였다고 설명합니다. (GitHub)
그래서 이 도구는 특히 작은 팀, AI 레이어 분해 결과를 바로 움직여야 하는 팀, 프로토타입을 빠르게 만들어야 하는 캐릭터 애니메이션 작업에 잘 맞습니다. 반대로 정교한 장편 제작 파이프라인 전체를 대체하는 도구로 보기에는 아직 이릅니다. (GitHub)
동작 원리 / 구조

입력 자산을 가져옵니다
PNG 또는 PSD를 불러오고, PSD라면 레이어 이름과 순서를 유지한 채 분해합니다. 이 단계에서 이미지 데이터와 알파 정보가 이후 선택, 메시 생성, 렌더링의 기초가 됩니다. (GitHub)
프로젝트 트리와 그룹 구조를 만듭니다
각 파트는 part 또는 group 노드로 프로젝트 트리에 들어갑니다. 부모-자식 관계, 가시성, 불투명도, 변환 정보가 이 트리에 모이고, 이후 모든 편집은 이 구조를 기준으로 이뤄집니다. (GitHub)
필요하면 자동 정리와 리깅을 수행합니다
레이어 이름이 특정 패턴을 만족하면 머리, 눈, 몸통 같은 그룹으로 자동 정리됩니다. 리깅은 빠른 휴리스틱 방식이나 DWPose 기반 AI 추정으로 진행되며, 마지막에는 캔버스에서 관절을 직접 조정합니다. 이 설계는 자동화와 수동 제어의 균형을 맞추기 위한 선택입니다. (GitHub)
렌더링 전에 월드 변환을 계산합니다
렌더러는 먼저 트리를 깊이 우선으로 순회하며 부모 행렬과 로컬 행렬을 합성해 각 노드의 월드 행렬을 만듭니다. 이렇게 해야 그룹 이동이나 회전이 자식 파트에 자연스럽게 전파됩니다. (GitHub)
드로우 오더 기준으로 실제 그립니다
그 다음 패스에서는 드로우 오더에 따라 각 파트를 GPU에 올린 버퍼와 함께 렌더링합니다. 메쉬가 없다면 단순 쿼드로, 메쉬가 있다면 삼각형 메시로 그립니다. 즉, 단순한 파트와 변형이 필요한 파트를 같은 시스템 안에서 다루기 위한 구조입니다. (GitHub)
애니메이션은 타임라인 상태에서 보간됩니다
애니메이션 스토어가 현재 시간, 재생 상태, 포즈 오버라이드, 키프레임을 관리합니다. 중요한 점은 선택과 편집도 저장된 원본 좌표가 아니라 “현재 시점에 계산된 유효 포즈”를 기준으로 해야 한다는 점인데, 실제로 관련 버그를 수정한 기록도 있습니다. (GitHub)
메쉬 생성은 별도 알고리즘으로 처리됩니다
메시 생성은 알파 마스크를 만들고, 경계를 추적하고, 내부를 샘플링한 뒤 삼각분할을 수행하는 파이프라인으로 구성됩니다. 경계보다 약간 바깥으로 확장하는 dilation을 두는 이유는, 변형 시 이미지 가장자리가 찢어져 보이는 현상을 줄이기 위해서입니다. (GitHub)

설치 / 사용 방법
현재 문서 기준으로 로컬 개발 환경은 Node.js 18 이상과 pnpm을 권장합니다. 프레임워크는 React와 Vite를 기반으로 하고, UI는 Shadcn UI와 Tailwind CSS 조합 위에 올라가 있습니다. (GitHub)
설치와 실행 흐름은 아래처럼 이해하면 됩니다.
git clone <repository>
cd stretchystudio
pnpm install
pnpm dev

실행 후에는 로컬 개발 서버에서 에디터를 열고, PSD 또는 PNG를 드래그해 가져옵니다. 그 다음 리깅 마법사로 뼈대를 잡고, Animation 모드로 전환해 키프레임을 추가하는 흐름입니다. 문서상 빠른 시작은 “가져오기 → 오토 리깅 → 애니메이션”의 3단계에 가깝게 정리되어 있습니다. (GitHub)
최소 실행 예시는 이렇게 볼 수 있습니다.
pnpm install
pnpm dev

1) PSD 또는 PNG 가져오기
2) 필요하면 자동 리깅 또는 수동 리깅 선택
3) 관절 위치 보정
4) Animation 모드로 전환
5) 키프레임 추가 후 재생
6) 프로젝트 저장

자주 쓰는 예시 / 활용 시나리오
AI로 분해된 캐릭터 PSD를 바로 움직여야 하는 경우
이미 레이어가 나뉜 캐릭터를 갖고 있지만, 이를 애니메이션 가능한 구조로 바꾸는 작업이 남아 있을 때 적합합니다. see-through 계열 자산을 바로 이어서 다루도록 설계된 점이 강점입니다. (GitHub)
VTuber 스타일의 간단한 리깅 프로토타입이 필요한 경우
정교한 수작업 리깅 전에 빠르게 뼈대를 추정하고 테스트해 볼 수 있습니다. 휴리스틱 방식은 빠르고, DWPose 방식은 더 정밀한 시작점을 줍니다. (GitHub)
레이어 회전만으로는 부족한 미세 표정이 필요한 경우
눈동자, 머리카락, 호흡 같은 부위는 단순 회전보다 메시 정점 변형이 더 자연스럽습니다. Stretchy Studio는 이 지점을 위해 만들어진 도구에 가깝습니다. (GitHub)
게임용 2D 자산 애니메이션을 빠르게 실험하는 경우
현재 기준으로는 스프라이트시트 내보내기 단계가 다음 마일스톤으로 남아 있지만, 구조적으로는 그 방향을 분명히 보고 있습니다. 따라서 게임 자산용 실험 도구로는 충분히 흥미롭습니다. (GitHub)
내부 툴이나 연구 프로젝트에서 애니메이션 편집기 구조를 참고하는 경우
프로젝트 스토어, 애니메이션 스토어, WebGL 렌더러, 메시 생성 파이프라인이 비교적 명확하게 분리돼 있어, 에디터 아키텍처 사례로 읽기 좋습니다. (GitHub)
한계 / 주의할 점
문서상 확인되는 범위에서, 이 프로젝트는 아직 완성형 상용 제작 파이프라인이라고 보긴 어렵습니다. 현재 기준으로 M6는 완료됐지만, 스프라이트시트 내보내기와 GIF·비디오 출력, 물리 시뮬레이션, undo/redo 통합, 블렌드 모드 같은 기능은 다음 단계로 남아 있습니다. (GitHub)
적용이 어려운 경우도 분명합니다. PSD의 CMYK, 스마트 오브젝트, 복잡한 레이어 효과, 특수 블렌드 모드는 아직 충분히 검증되지 않았다고 적혀 있습니다. 즉, 일러스트 원본이 복잡할수록 바로 가져와서 완벽히 동작한다고 기대하면 안 됩니다. (GitHub)
오해하기 쉬운 부분도 있습니다. 이 도구는 “무조건 AI가 전부 해주는 자동 애니메이션 툴”이 아닙니다. 자동 리깅과 보조 기능은 있지만, 실제 결과 품질은 그룹 구조, 관절 보정, 메시 밀도 조절, 키프레임 설계에 여전히 많이 좌우됩니다. (GitHub)
현재 기준으로는 특히 대규모 팀의 정교한 아트 파이프라인 전체를 대체하기보다, 빠른 제작·실험·프로토타이핑에 더 잘 맞습니다. 반대로 이미 성숙한 전용 툴체인과 자동화가 갖춰진 스튜디오라면 도입 이득이 제한적일 수 있습니다. 이 점은 기대치를 맞추는 데 중요합니다. (GitHub)
마무리
Stretchy Studio의 핵심 가치는 복잡한 2D 캐릭터 애니메이션 제작을 “리깅 시스템 설계”가 아니라 “편집 가능한 작업 흐름”으로 다시 묶어낸 데 있습니다. PSD 가져오기, 그룹 구조, 리깅, 메시 변형, 타임라인, 저장까지 한 흐름으로 연결하려는 점이 분명합니다. (GitHub)
특히 이 도구는 스타트업, AI 기반 캐릭터 생성 파이프라인을 다루는 팀, VTuber·게임용 2D 캐릭터를 빠르게 움직여 봐야 하는 개발자와 아티스트에게 잘 맞습니다. 반대로 정교한 최종 제작 파이프라인을 즉시 대체할 도구를 찾고 있다면, 아직은 실험적 성격을 함께 감안해야 합니다. (GitHub)
핵심 요약

핵심 개념
정적인 2D 레이어 이미지를 메시 변형과 스켈레톤, 타임라인 편집으로 바로 애니메이션 가능한 구조로 바꾸는 웹 기반 도구입니다. (GitHub)
차별점
Live2D식 파라미터 중심 접근보다, 타임라인에서 직접 키프레임과 변형을 다루는 방향으로 설계됐다는 점이 가장 큰 차이입니다. (GitHub)
언제 쓰면 좋은지
AI로 분해된 PSD를 빠르게 움직이고 싶을 때, 캐릭터 리깅 프로토타입을 빠르게 만들고 싶을 때, 메시 기반 미세 변형이 필요한 2D 캐릭터 작업에 적합합니다. (GitHub)
언제 쓰면 안 되는지
복잡한 PSD 기능까지 완전 호환되는 상용급 파이프라인 대체재가 필요한 경우, 혹은 GIF·비디오·물리 시뮬레이션 같은 후속 기능이 필수인 경우에는 아직 맞지 않을 수 있습니다. (GitHub)
한 줄 요약
Stretchy Studio는 “AI로 분해된 2D 캐릭터를, 무거운 파라미터 설계 없이 바로 움직이기 위한 타임라인 중심 애니메이션 툴”로 이해하면 가장 정확합니다. (GitHub)



16GB GPU로 100GB 넘는 초거대 모델을 돌린다고요?
행복한 수지아빠 — Tue, 14 Apr 2026 09:56:18 +0900
 
“원래는 안 될 것 같은데, 요즘은 됩니다”의 진짜 이유
처음 들으면 이상합니다.
“27B, 70B, 100B, 심지어 200B가 넘는 모델을
고작 16GB VRAM GPU로 돌릴 수 있다.”
상식적으로는 말이 안 되는 이야기처럼 보입니다.
보통 대형 모델은 모델 전체가 GPU 메모리(VRAM)에 올라가야 실행된다고 알려져 있기 때문입니다.
그래서 많은 분들이 이렇게 생각합니다.
“아니, 100GB가 넘는 모델이면
당연히 VRAM도 그 정도는 있어야 하는 거 아닌가?”
네, 최고 속도로 돌리려면 그 말이 맞습니다.
하지만 요즘은 꼭 그렇게만 돌리지 않습니다.
최근 추론 엔진과 양자화 기술이 발전하면서, 이제는 GPU 메모리만으로 버티는 시대에서 GPU + RAM을 함께 활용하는 시대로 넘어오고 있습니다.
쉽게 말하면,
예전에는 “전부 비싼 전용 창고에 넣어야만 작업 가능”했다면,
이제는 “핵심 물건만 전용 창고에 두고, 나머지는 옆 창고를 빌려서” 처리할 수 있게 된 것입니다.
이 글에서는
**왜 16GB GPU로도 100GB가 넘는 모델이 ‘돌아갈 수 있는지’**를
아주 쉽게, 핵심만 정리해보겠습니다.
그래서 16G 그래픽카드로만 돌아가진 않고 추가로 DRAM(예로 96G)을 세팅해주면 통합 메모리 사용하는 맥이나 DGX SPARK보단 빠르게 돌아갈수 있습니다. 

우리가 헷갈리는 지점부터 정리해보자
많은 사람들이 헷갈리는 이유는,
사실 “돌아간다”와 “빠르게 돌아간다”를 같은 뜻으로 생각하기 때문입니다.
대형 모델을 다룰 때는 이 둘을 분리해서 봐야 합니다.

완전히 GPU에 올려 최고 속도로 추론하는 것
GPU와 시스템 메모리를 같이 써서 느리지만 실행 가능하게 만드는 것

이 둘은 완전히 다른 이야기입니다.
즉,
“100GB 모델이면 100GB 이상의 VRAM이 필요하다”는 말은
대체로 최고 성능 기준에서는 맞는 말입니다.
반면,
Unsloth나 llama.cpp 계열에서 말하는 세팅은
“전부 GPU에 넣는 방식”이 아니라
일부는 GPU, 나머지는 RAM으로 분산해서 일단 실행되게 만드는 방식에 가깝습니다.
핵심은 여기 있습니다.

요즘은 모델을 한 덩어리로 다루지 않고,
잘게 나눠서 필요한 자원을 쪼개 쓰는 방식이 가능해졌다.

그리고 그 중심에는 세 가지 기술이 있습니다.

1. 레이어 오프로딩: 모델을 통째로 올리지 않고, 나눠서 처리한다
가장 중요한 개념은 레이어 오프로딩(layer offloading)입니다.
LLM은 하나의 거대한 파일처럼 보이지만,
실제로는 내부적으로 여러 개의 레이어(layer)로 구성되어 있습니다.
추론할 때는 이 레이어들을 순서대로 통과하면서 계산이 진행됩니다.
예전에는 이 레이어 대부분을 GPU에 올려야 한다고 생각했지만,
이제는 그렇게 하지 않아도 됩니다.
예를 들어 이런 식입니다.

GPU(16GB VRAM): 연산이 빠른 핵심 일부 레이어 담당
시스템 RAM(예: 96GB): 나머지 대부분의 레이어 보관
CPU: RAM에 있는 레이어 계산 보조 및 데이터 이동 처리

즉, 모델 전체를 GPU에 억지로 다 넣는 대신,
GPU에 들어갈 수 있는 만큼만 올리고,
나머지는 시스템 메모리에 둔 채 필요할 때 불러와 계산하는 것입니다.
이걸 비유하면 이해가 쉽습니다.
시험 문제를 푸는 데
가장 똑똑한 학생 한 명(GPU)에게 모든 문제를 다 맡기고 싶지만,
책상이 너무 작아서 문제지를 다 펼칠 수 없는 상황입니다.
그래서
정말 계산이 많이 필요한 문제 몇 장만 그 학생 책상에 올려두고,
나머지는 뒤에서 다른 학생들(CPU + RAM)이 들고 있다가
필요한 순간마다 넘겨주는 방식으로 푸는 것입니다.
물론 이 방식은 비효율이 있습니다.
문제를 옮겨주고 받는 시간이 들기 때문입니다.
하지만 중요한 건, 원래 아예 못 풀던 문제를 이제는 풀 수 있게 되었다는 점입니다.
즉,
오프로딩은 “최고 속도”를 만드는 기술이라기보다
**“한정된 하드웨어에서도 대형 모델을 실행 가능하게 만드는 기술”**이라고 보는 편이 정확합니다.

2. 양자화: 모델을 똑똑하게 압축해서 몸집을 줄인다
두 번째 핵심은 양자화(Quantization)입니다.
이 기술이 중요한 이유는 아주 단순합니다.
대형 모델이 무거운 이유는 결국 숫자를 너무 많이, 너무 정밀하게 저장하기 때문입니다.
원래 LLM은 보통 FP16 같은 고정밀 숫자 형식으로 저장됩니다.
이 방식은 정확하지만, 메모리를 엄청나게 먹습니다.
모델이 커질수록 용량은 금방 수십 GB, 수백 GB 단위로 커집니다.
그런데 추론에서는
항상 그렇게까지 정밀한 숫자가 필요한 것은 아닙니다.
그래서 등장한 것이 양자화입니다.
쉽게 말하면,

원래는 아주 세밀한 소수점으로 저장하던 값을
4비트, 경우에 따라 더 낮은 비트 수준으로 줄여서
메모리 사용량을 크게 낮추는 방식

입니다.
예를 들어 FP16 기반 모델은 너무 커서 엄두가 안 나더라도,
이를 4비트 계열로 양자화하면
용량이 크게 줄어들어 현실적인 PC 환경에서도 다뤄볼 수 있는 크기가 됩니다.
여기서 자주 보이는 이름들이 있습니다.

GGUF
IQ4
Q4_K
UD-IQ4_XS

이런 이름들은 대체로
모델을 어떤 방식으로 압축했는지,
그리고 속도·용량·성능 균형을 어떻게 맞췄는지를 나타내는 포맷 또는 양자화 방식입니다.
중요한 포인트는 하나입니다.

모델이 원래 크기 그대로 올라가는 게 아니라,
훨씬 더 작은 형태로 줄어든 뒤 올라간다.

그래서 270B급처럼 원래는 상상하기 어려운 모델도
4비트 수준으로 줄이면
“아주 빠르진 않아도, RAM 많은 PC에서 겨우겨우 돌려볼 수 있는 영역”으로 내려오게 됩니다.
물론 공짜는 아닙니다.
양자화를 하면 일부 성능 손실은 생길 수 있습니다.
하지만 최근 양자화 기법은 꽤 정교해져서,
많은 사용자는 생각보다 큰 품질 저하 없이 실사용 가능한 수준을 경험합니다.
즉, 양자화는
대형 모델을 위한 마법이 아니라,
현실적인 하드웨어에 맞게 몸집을 줄여주는 실용 기술입니다.

3. 왜 어떤 경우엔 Mac보다 PC가 더 빠를까?
이쯤에서 흥미로운 질문이 나옵니다.
“그럼 메모리가 넉넉한 Mac이 무조건 유리한 거 아닌가?”
직관적으로는 그렇게 보입니다.
특히 Apple Silicon의 통합 메모리 구조는
GPU와 CPU가 같은 메모리 풀을 공유하기 때문에
이론상 매우 편리해 보입니다.
실제로 장점도 분명합니다.

메모리를 유연하게 같이 쓸 수 있음
세팅이 단순함
안정적으로 큰 모델을 다루기 좋음

하지만 속도는 또 다른 문제입니다.
대형 모델 추론에서는 단순히 “메모리가 하나로 합쳐져 있느냐”보다
실제 연산 성능과
데이터를 처리하는 전체 파이프라인이 더 중요합니다.
고성능 NVIDIA GPU가 들어간 PC는
비록 모델 일부를 RAM에서 가져와야 하는 병목이 있더라도,
정작 GPU가 계산을 시작하면 그 연산 속도 자체가 매우 강력합니다.
즉,

Mac은 구조가 우아하고 안정적이지만
PC는 병목이 있어도 GPU 화력이 워낙 강해서
실제 토큰 생성 속도에서는 더 유리할 수 있는 것

입니다.
이 부분은 자동차에 비유하면 이해가 쉽습니다.
Mac은 큰 짐칸이 달린 일체형 차량처럼 볼 수 있습니다.
짐을 싣고 내리는 흐름이 자연스럽고 효율적입니다.
반면 PC는
짐칸과 엔진룸이 분리되어 있어서 중간 이동 과정이 번거롭지만,
엔진 자체가 훨씬 강력해서
막상 달리기 시작하면 더 빠를 수 있습니다.
그래서 “통합 메모리니까 무조건 빠르다”도 아니고,
“오프로딩이 있으니 PC가 무조건 좋다”도 아닙니다.
정확히 말하면,

Mac은 큰 모델을 다루는 경험이 부드럽고,
PC는 적절한 조합이면 더 높은 추론 속도를 낼 수 있다
정도로 이해하는 것이 현실적입니다.


결국 정리하면: VRAM이 부족해도, RAM을 빌려서 돌리는 시대다
여기까지 내용을 한 문장으로 줄이면 이렇습니다.
예전에는 대형 모델을 돌리려면 큰 VRAM이 필수였지만,
이제는 오프로딩과 양자화 덕분에 시스템 RAM까지 활용해서 “느리지만 실행 가능한” 구성이 가능해졌다.
즉, 우리가 흔히 떠올리는 기준은
아직도 **“모델 전체를 GPU에 올리는 방식”**에 머물러 있는 경우가 많습니다.
하지만 최근 로컬 LLM 생태계는 다릅니다.

모델을 레이어 단위로 나누고
일부는 GPU에, 나머지는 RAM에 두고
양자화로 크기를 크게 줄이고
CPU와 GPU가 협력해서 추론을 이어가는 방식

이 점점 보편화되고 있습니다.
그래서 이제는
“이론상 불가능해 보이는 하드웨어 조합”에서도
초거대 모델을 체험하거나 실험해보는 것 자체는 가능해졌습니다.
물론 현실적인 한계는 분명합니다.

속도는 느릴 수 있습니다
응답 지연이 꽤 클 수 있습니다
컨텍스트 길이나 배치 설정에 따라 더 버거울 수 있습니다
사용 경험은 “쾌적하다”기보다 “된다”에 가까울 수 있습니다

그럼에도 불구하고 의미는 큽니다.
예전에는
초거대 모델을 만져보려면
수천만 원대 장비나 서버급 환경이 사실상 전제 조건처럼 느껴졌습니다.
하지만 이제는
RAM이 넉넉한 일반 데스크톱과
적당한 GPU만 있어도
“완전한 최고 성능은 아니지만, 직접 돌려보고 감을 잡아보는 것”이 가능한 시대가 된 것입니다.
이 변화는 꽤 중요합니다.
왜냐하면 기술의 진입장벽이 낮아졌다는 뜻이기 때문입니다.

이제 질문은 “돌아가냐”가 아니라 “어느 정도로 쓸 만하냐”에 가깝다
앞으로 로컬 LLM 환경에서 더 중요한 질문은
“이 모델이 내 PC에서 아예 실행되느냐”보다
**“내 용도에서 어느 정도 속도와 품질로 쓸 만하냐”**가 될 가능성이 큽니다.
예를 들어,

간단한 실험용인지
문서 요약 정도인지
코딩 보조인지
장문 추론이 필요한지
속도가 중요한지, 아니면 모델 크기가 중요한지

에 따라 최적의 선택은 달라집니다.
어떤 사람에게는
작지만 빠른 14B 모델이 더 좋은 선택일 수 있고,
또 어떤 사람에게는
느리더라도 훨씬 큰 70B 이상 모델을 오프로딩으로 돌려보는 것이 더 의미 있을 수 있습니다.
중요한 것은 이제 선택지가 생겼다는 점입니다.

마무리
정리해보면 이렇습니다.
대형 모델을 돌릴 때 필요한 “128GB VRAM” 같은 조건은
대개 모델을 전부 GPU에 올려 빠르게 돌릴 때의 기준입니다.
반면 최근 로컬 추론 환경은
레이어 오프로딩 + 양자화 + CPU/RAM 협업을 통해
훨씬 적은 GPU 메모리로도 대형 모델을 실행 가능하게 만들고 있습니다.
즉,
16GB GPU로 100GB가 넘는 모델을 돌린다는 말은
“말도 안 되는 허풍”이라기보다,
정확히는 **“RAM까지 총동원해서 느리지만 돌아가게 만든 구성”**에 가깝습니다.
결국 지금은
무조건 가장 비싼 GPU가 있어야만 초거대 모델을 경험할 수 있는 시대가 아닙니다.
물론 최고 성능은 여전히 고가 장비의 영역에 가깝습니다.
하지만 적어도 이제는,
일반 사용자도 충분히 대형 모델의 세계를 직접 찍어먹어볼 수 있는 시대가 된 것은 분명합니다.


마크다운 파일 17개로 만드는 나만의 콘텐츠 엔진
행복한 수지아빠 — Mon, 13 Apr 2026 14:33:34 +0900
대부분의 사람들은 AI를 콘텐츠 제작에 이렇게 쓴다.

Claude를 연다
“생산성에 대한 링크드인 포스트 써줘”라고 입력한다
회사 인턴이 쓴 것 같은 평범한 포스트를 받는다
로봇처럼 안 들리게 20분 동안 손본다
그리고 플랫폼마다 그걸 또 처음부터 반복한다

이건 시스템이 아니다.
그냥 단계만 더 많은 잡일이다.
문제는 AI가 아니다.
문제는 네가 AI에게 브랜드, 독자, 말투, 플랫폼 전략, 그리고 이 모든 요소가 어떻게 연결되는지에 대한 맥락을 전혀 주지 않고 있다는 것이다.
매번 새 채팅을 시작할 때마다 기억상실에 걸린 천재를 새로 고용하는 셈이다.
해결책: 스킬 그래프가 이 문제를 해결한다.
신입 직원을 고용한다고 생각해보자.
첫날부터 아무 온보딩도 없이, 문서도 없이, 회사가 어떻게 돌아가는지에 대한 맥락도 없이 바로 실전에 던져놓고 잘하길 바랄 수도 있다.
아니면 네가 누구인지, 어떻게 일하는지, 누구에게 말하는지, 좋은 결과물이 어떤 것인지 설명하는 완전한 플레이북을 건네줄 수도 있다.
스킬 그래프는 그 플레이북이다.
다만 사람용이 아니라 AI 에이전트용이다.
기술적으로 보면, 이것은 서로 연결된 마크다운 파일들의 폴더일 뿐이다.
각 파일은 하나의 “지식 노드”, 즉 네 콘텐츠 시스템 두뇌의 한 조각이다.
각 파일 안에서는 [[brand-voice]], [[hooks]] 같은 위키링크(이중 대괄호 링크)를 사용해서 다른 노드를 참조한다.
AI 에이전트에게 이 폴더를 가리키고 주제를 하나 주면, 그 에이전트는 파일 하나만 읽는 것이 아니다.
링크를 따라가며 연결된 노드들을 읽고, 글을 한 줄 쓰기 전에 네 브랜드, 말투, 독자, 플랫폼 규칙, 훅 공식, 재가공 로직에 대한 전체 이해를 쌓는다.
차이는 엄청나다.
나쁜 방식: 단일 프롬프트 = 브리프도 없고, 브랜드 가이드도 없고, 독자 이해도 없는 프리랜서를 고용하는 것
좋은 방식: 30개 이상의 상호 연결된 .md 파일 그래프 = 전체 플레이북을 다 읽고 플랫폼별 작동 방식까지 정확히 이해한 콘텐츠 팀을 고용하는 것
다르게 말하면,

평평한 .md 파일 하나는 도구를 준다.
(단순 참고 문서)
그래프는 팀을 준다.
(플랫폼별 전문가, 훅 유형별 전문가, 보이스 변형 전문가, 독자 세그먼트 전문가가 있는 시스템)

이것이 내 월 5,000달러짜리 콘텐츠 제작 비용을 대체한 방식이다.
개별 파일이 마법이라서가 아니다.
파일들 사이의 연결이 단일 프롬프트로는 만들 수 없는 지능을 만들어내기 때문이다.
[ 플레이북 시작 ] ↓↓↓

어디에서 만들까?
(툴 스택)
선택지는 두 가지다. 둘 다 잘 작동한다.
1. Obsidian
그래프를 시각적으로 보고 싶다면 이걸 추천한다.
Obsidian은 무료 마크다운 에디터로, [[wikilinks]]를 기본 지원하고, 모든 노드가 어떻게 연결되는지 보여주는 멋진 그래프 뷰도 제공한다.
마치 네 콘텐츠 시스템의 신경망을 들여다보는 느낌이다.
디버깅도 직관적이다. 어떤 노드가 끊어져 있는지, 어떤 노드가 과하게 링크되어 있는지 한눈에 볼 수 있다.
2. 데스크톱의 일반 폴더
툴을 더 늘리고 싶지 않다면(툴 피로감, 진짜 있다), 그냥 .md 파일 폴더만 써도 충분히 된다.
AI 에이전트는 Obsidian 자체에는 관심이 없다.
마크다운을 읽고 [[wikilinks]]를 따라가기만 하면 된다.
VS Code, 마크다운으로 내보낸 Notion, 심지어 메모장도 괜찮다.
진짜 뭐든 된다.

실제로 시스템을 돌리는 도구는 무엇인가
Claude
내 주력 선택지다.
가장 좋은 두뇌다.
Claude Projects를 쓰면 모든 .md 파일을 업로드해서 지속적인 컨텍스트로 유지할 수 있다.
즉, 그 프로젝트 안의 모든 대화는 전체 그래프에 접근할 수 있다.
ChatGPT
커스텀 GPT를 쓰거나, 핵심 파일들을 대화에 붙여넣는 방식으로 가능하다.
Cursor
기술적인 사용자라면 Cursor를 써서 에이전트가 로컬 파일 시스템의 파일을 직접 읽게 할 수 있다.
편한 것을 고르면 된다.
다만 내 생각엔 독자의 95%는 Claude를 고를 것이고, 그것이 가장 좋은 선택이다.
나도 그렇게 쓴다.

폴더 구조
네가 만들 구조는 정확히 이렇다.












/content-skill-graph
├── index.md
├── platforms/
│ ├── x.md
│ ├── linkedin.md
│ ├── instagram.md
│ ├── tiktok.md
│ ├── youtube.md
│ ├── threads.md
│ ├── facebook.md
│ └── newsletter.md
├── voice/
│ ├── brand-voice.md
│ └── platform-tone.md
├── engine/
│ ├── hooks.md
│ ├── repurpose.md
│ ├── scheduling.md
│ └── content-types.md
└── audience/
 ├── builders.md
 └── casual.md









 



17개 파일.
4개 폴더.
이게 네 전체 콘텐츠 제작 머신이다.
지금 당장 이 구조를 만들어라. 진심이다. 읽는 걸 잠깐 멈추고 먼저 해라.
단계별로:

Obsidian을 열거나, 데스크톱에 폴더를 만든다
하위 폴더를 만든다
위 이름대로 빈 .md 파일들을 만든다
그다음 돌아와서 하나씩 다 채운다


각 폴더가 하는 일 빠르게 보기

index.md — 진입점. AI 에이전트가 가장 먼저 읽는 브리핑 문서. 시스템 전체에서 가장 중요한 파일
platforms/ — 플랫폼별 파일. 규칙, 포맷, 글자 수 제한, 게시 빈도, 콘텐츠 스타일 등 플랫폼에 자연스럽게 글쓰기 위해 필요한 모든 것
voice/ — 브랜드 보이스 DNA와 플랫폼별 변형 방식. 콘텐츠가 로봇처럼 들리지 않게 해주는 핵심
engine/ — 운영 백본. 훅 공식, 재가공 체인, 스케줄링 규칙, 콘텐츠 타입 정의
audience/ — 실제로 누구에게 말하고 있는지. 같은 주제도 독자 세그먼트에 따라 다른 각도로 풀어야 한다


1. index.md — 커맨드 센터
# 콘텐츠 스킬 그래프 — 커맨드 센터

## 1. 정체성

[브랜드명/이름]을 위한 콘텐츠 제작 시스템.
하나의 아이디어 입력으로 소셜 미디어 계정 10개를 운영한다.

브랜드: [당신의 이름 / 브랜드명]
분야: [당신의 분야 — 예: "AI 자동화, SaaS 제작, 기술 역량 수익화"]
미션: 하나의 주제를 플랫폼 네이티브 포스트 10개로 바꾸되,
각 포스트가 같은 주제를 서로 다른 방식으로 사고하도록 만든다.

## 2. 노드 맵

아래의 모든 노드는 지식 파일이다.
어떤 작업을 실행하기 전에 관련 파일을 먼저 읽어라.
[[위키링크]]는 클릭 가능한 링크이며, 반드시 따라가라.

### 플랫폼
- [[x]] — 짧은 형식, 훅 중심, 최대 280자, 캐주얼한 소문자 스타일.
  주 5회 이상 게시. 반대 의견형 포스트와 단계형 스레드 중심
- [[linkedin]] — 장문 서사형, 전문적인 톤, 1500자 이상.
  주 3회 게시. 비즈니스 인사이트가 들어간 개인 경험형 글
- [[instagram]] — 비주얼 중심. 첫 슬라이드에 강한 주장이 들어간
  7장짜리 캐러셀. 주 4회 게시. 숏폼 비디오용 릴스 포함
- [[tiktok]] — 거칠고 덜 다듬어진 45~60초 화면 녹화 또는
  토킹헤드 영상. 주 5회 게시. 첫 2초 안에 훅 필요
- [[youtube]] — SEO 최적화 제목, 구조화된 아웃라인,
  8~12분 분량. 주 2회 게시. 에버그린 콘텐츠 중심
- [[threads]] — 대화형, 의견 중심, 캐주얼. 주 3회 게시.
  "X보다 더 느슨한 버전"처럼 생각하기
- [[facebook]] — 커뮤니티 중심, 더 긴 캡션, 그룹 참여형.
  주 3회 게시
- [[newsletter]] — 깊이 있는 포맷, 1000~2000단어,
  실행 가능한 프레임워크 중심. 주 1회 발송

### 보이스
- [[brand-voice]] — 모든 플랫폼에서 공통으로 유지되는 핵심 성격,
  가치관, 톤 마커, 어휘를 정의하는 파일
- [[platform-tone]] — 핵심 보이스가 플랫폼별로 어떻게 변형되는지.
  같은 사람, 다른 공간

### 엔진
- [[hooks]] — 스크롤을 멈추게 하는 도입부 공식.
  반대 의견형, 증거형, 발견형, 대체형, 플레이북형으로 분류.
  성과를 기준으로 매주 업데이트
- [[repurpose]] — 재가공 체인: 아이디어 1개 → 결과물 10개.
  어떤 플랫폼을 먼저 쓰는지, 어떤 순서로 적응시키는지,
  버전마다 무엇이 바뀌는지를 정의
- [[scheduling]] — 게시 캘린더, 플랫폼별 최적 시간,
  빈도 규칙, 배치 작업 흐름
- [[content-types]] — 스레드, 캐러셀, 릴스,
  장문 글, 짧은 의견, 영상 스크립트, 뉴스레터 등의 포맷 정의

### 독자
- [[builders]] — 핵심 독자. 인디해커, AI 엔지니어,
  SaaS 창업자, 기술로 수익화하는 프리랜서.
  이들은 바로 실행 가능한 플레이북, 실제 숫자,
  오늘 당장 쓸 수 있는 도구를 원한다.
- [[casual]] — 보조 독자. AI/기술에 관심은 있지만 아직 직접 만들지는 않는 사람들.
  이들은 영감, 쉬운 설명,
  "나도 할 수 있겠는데" 같은 감정을 원한다.

## 3. 실행 지침

주제가 주어졌을 때:

1. 이 주제가 우리의 분야와 맞는지 먼저 확인하라. 맞지 않으면 거절하라.
2. 핵심 성격을 파악하기 위해 [[brand-voice]]를 읽어라.
3. [[hooks]]를 읽고, 해당 주제에 가장 적합한 훅 공식을 선택하라.
4. 제작 순서를 파악하기 위해 [[repurpose]]를 읽어라.
5. 체인에서 첫 번째 플랫폼(보통 [[x]])용 콘텐츠부터 작성하라.
6. 이후 플랫폼마다 해당 플랫폼 노드와 [[platform-tone]]을 읽고 적응시켜라.
   단순 재포맷하지 말고, 그 플랫폼에 맞게
   각도, 구조, 훅, 포맷을 다시 사고하라.
7. 게시 타이밍과 빈도에는 [[scheduling]] 규칙을 적용하라.
8. 각 플랫폼별로 바로 게시 가능한 네이티브 포스트를 하나씩 출력하라.

핵심 규칙: 결과물은 같은 글을 10개 플랫폼용으로 다시 포맷한 것이 아니다.
같은 주제를 다루더라도, 각 플랫폼에서
다른 각도, 다른 훅, 다른 보이스, 다른 구조, 다른 포맷으로 사고한
10개의 별도 결과물이어야 한다.


2. platforms/x.md
# X / 트위터

## 플랫폼 DNA
- 글자 수 제한: 기본 트윗은 280자, 장문 트윗은 최대 25,000자
  (하지만 가장 잘 먹히는 길이는 1,000~2,000자)
- 분위기: 빠르고, 캐주얼하며, 의견 중심. 기본은 소문자 스타일.
  사람들이 매우 빠르게 스크롤하기 때문에, 멈춰 세울 시간은 0.5초 정도뿐이다.
- 이 플랫폼의 독자: 더 기술적이고, 더 빌더 중심이다.
  [[casual]]보다 [[builders]]에 더 가깝다.

## 콘텐츠 규칙
- 이 플랫폼은 [[repurpose]] 체인에서 가장 먼저 작성하라.
  X는 짧게 압축하게 만들기 때문에, 이후 확장이 쉬워진다.
- [[hooks]]를 사용하라 — 특히 반대 의견형 훅과 증거형 훅이 잘 작동한다.
- [[brand-voice]]를 따르되 더 캐주얼하게 조정하라.
  X 전용 조정은 [[platform-tone]]를 참고하라.
- 생각 단위마다 줄바꿈하라. 절대 빽빽한 문단을 쓰지 마라.
- 해시태그는 쓰지 마라. X에서는 스팸처럼 보인다.
- 이모지는 글 맨 끝의 사인오프처럼만 사용하라. (하트 하나 또는 없음)
- 링크는 본문이 아니라 본인 글의 답글에 넣어라.
  본문 외부 링크는 알고리즘에 불리하다.

## 잘 작동하는 포맷
1. 단계형 스레드 — "[결과]를 얻기 위한 [N]단계는 다음과 같다:"
   형식으로 시작하고 번호를 붙여 설명한다.
   가장 안정적으로 반응을 얻는 형식이다.
2. 짧은 의견형 — 2~4줄.
   강한 주장 + 한 줄 맥락 + 펀치라인.
   반대 의견형 훅에 잘 맞는다.
3. 증거형 포스트 — "[지표] → [지표] in [기간]" 형식으로 시작하고
   뒤에 분석을 붙인다. 사람들은 실제 숫자에 매우 강하게 반응한다.
4. 리소스 소개형 — "방금 [무언가]를 찾았는데 — [왜 중요한지]"
   짧고 가치가 높아야 한다. 반드시 개인적인 해석을 덧붙여라.
5. 장문 트윗 — 1,000~2,000자.
   하나의 아이디어를 깊게 풀어내는 형식.
   너무 자주 쓰지 말고 주 1~2회 정도만 사용하라.

## 게시 전략
- 빈도: 최소 주 5~7회 (하루 1~2포스트)
- 최적 시간: 오전 8~9시, 12~1시, 오후 5~6시 (독자 시간대 기준)
- 게시 후 30분 동안은 답글에 적극 참여하라 (사실상 알고리즘 핵)
- 전체 일정은 [[scheduling]] 참고

## X의 독자
- 핵심 독자: [[builders]] — 인디해커, AI 엔지니어, SaaS 창업자
- 원하는 것: 실행 가능한 콘텐츠, 실제 숫자, 도구, 플레이북
- 원하지 않는 것: 내용 없는 동기부여 문구,
  "AI가 세상을 바꾼다" 수준의 뻔한 이야기
- 독자에게는 "당신"이라고 직접 말하라 — 코칭하는 에너지로

## 재가공 메모
- X는 [[repurpose]] 체인의 출발점이다.
- X용 글을 쓴 뒤에는 [[linkedin]]용으로 확장하라.
  (서사와 전문적 프레이밍 추가)
- 훅은 [[tiktok]]용으로 압축하라.
  (영상 첫 2초에 들어가야 하기 때문)
- 스레드는 [[instagram]] 캐러셀 슬라이드로 바꿀 수 있다.
- 전체 흐름은 [[repurpose]]를 참고하라.


3. platforms/linkedin.md
# 링크드인

## 플랫폼 DNA
- 엄격한 글자 수 제한은 없지만,
  일반 포스트는 1,300~2,000자 정도가 가장 잘 맞고,
  아티클은 최대 3,000자까지 가능하다.
- 분위기: 전문적이지만 인간적이어야 한다.
  개인 경험에 비즈니스 교훈이 붙은 글이 강하다.
- 독자: [[builders]]와 [[casual]]가 섞여 있지만,
  더 많은 직장인, 의사결정자, 실제 예산을 가진 사람들이 있다.

## 콘텐츠 규칙
- 개인적인 훅으로 시작하라.
  예: "내가 틀렸던 부분은..." / "3개월 전만 해도 나는..." / "모두가 나에게 ...라고 했다"
- 첫 문장이 전부다.
  링크드인은 약 210자 이후 "더 보기"로 접히기 때문에,
  첫 줄에 훅이 없으면 클릭이 일어나지 않는다.
- [[hooks]]를 사용하라 — 특히 증거형 훅과 플레이북형 훅이 잘 맞는다.
- [[brand-voice]]를 따르되 더 전문적으로 조정하라.
  세부 조정은 [[platform-tone]] 참고
- 짧은 문단으로 써라. 한 문단에는 하나의 아이디어만.
  여백이 중요하다.
- 본문에 해시태그를 넣지 마라.
  넣는다면 맨 마지막에 3개 이하만 넣어라.
- 링크는 본문이 아니라 첫 댓글에 넣어라.
  본문 링크는 알고리즘에 불리하다.

## 잘 작동하는 포맷
1. 개인 서사형 — "나는 [무언가를 했다/배웠다/실패했다]"
   → 교훈 → 실행 가능한 인사이트.
   링크드인의 대표 포맷이다.
2. 리스트형 포스트 — "[주제]에 대해 내가 배운 7가지:"
   형식으로 번호를 붙여 정리한다.
3. 반대 의견형 — 통념을 정면으로 뒤집는다.
   강한 주장으로 시작하고, 그 뒤에 근거를 붙인다.
4. 사례 연구형 — 실제 결과, 실제 숫자, 실제 과정.
   예: "우리가 [이전 상태]에서 [이후 상태]로 [기간] 안에 바뀐 방법"
5. 문서/캐러셀 포스트 — PDF 슬라이드를 문서로 업로드하는 형식.
   10~15장, 슬라이드당 하나의 아이디어, 굵은 헤드라인 중심

## 게시 전략
- 빈도: 주 3~5회
- 최적 시간: 오전 7~8시, 12시, 오후 5~6시
- 게시 전에 관련 포스트 10개에 댓글을 달아라 (참여도 상승용 핵)
- 전체 일정은 [[scheduling]] 참고

## 링크드인의 독자
- [[builders]]와 [[casual]]가 섞여 있다.
- 원하는 것: 커리어 성장, 비즈니스 인사이트,
  교훈이 있는 실제 이야기, 업무를 더 잘하게 해주는 도구
- 원하지 않는 것: 지나치게 가벼운 말투, 밈,
  근거 없는 뜨거운 주장
- X보다 고가 리드 가능성이 높다.
  이 플랫폼에는 예산을 가진 사람이 많다.

## 재가공 메모
- 링크드인은 보통 [[repurpose]] 체인의 두 번째 플랫폼이다.
- X용 글을 가져와서 개인 서사를 추가하고,
  1,300자 이상으로 확장하라.
- "내가 10개 계정을 운영하며 배운 점은..." 같은 전문적 프레이밍을 덧붙여라.
- 훅은 거의 항상 다시 써야 한다.
  X에서 먹히는 훅이 링크드인에서는 그대로 통하지 않는다.
- 이 글에서 [[instagram]]용 캐러셀 슬라이드를 추출할 수도 있다.


4. platforms/instagram.md
# 인스타그램

## 플랫폼 DNA
- 캡션 제한은 2,200자지만,
  실제 참여를 이끄는 건 비주얼(캐러셀 슬라이드 또는 릴스)이다.
- 분위기: 비주얼 우선.
  이미지나 캐러셀이 스크롤을 멈추게 하고,
  캡션이 설득을 마무리한다.
  강하고, 깔끔하고, 디자인된 느낌이어야 한다.
- 독자: X나 링크드인보다 더 넓고,
  [[casual]]에 더 가깝다. 더 aspirational하고 시각 학습형이 많다.

## 콘텐츠 규칙
- 캐러셀이 핵심이다. 7~10장, 슬라이드당 하나의 아이디어만.
- 1번 슬라이드 = 훅.
  굵은 주장, 큰 글자, 반대 의견 또는 호기심 유발 문장.
  [[hooks]]를 사용하라. 시각 형식에서는 발견형 훅과 증거형 훅이 잘 맞는다.
- [[brand-voice]]를 따르되 언어를 더 쉽게 조정하라.
  세부 조정은 [[platform-tone]] 참고
- 캡션은 슬라이드에 없는 맥락을 보완해야 한다.
  슬라이드 내용을 그대로 반복하지 마라.
- 해시태그: 캡션 마지막에 관련 해시태그 5~10개.
  X와 달리 인스타그램에서는 해시태그가 실제로 발견성을 높인다.
- 마지막 슬라이드와 캡션 모두에 CTA를 넣어라.
  예: "나중에 보려고 저장하세요" / "[주제] 더 보려면 팔로우" /
  "이게 필요한 사람에게 공유하세요"

## 캐러셀 디자인 규칙
- 폰트: 굵은 산세리프, 배경과 높은 대비
- 슬라이드당 하나의 아이디어. 슬라이드당 최대 30단어
- 모든 슬라이드에 일관된 색상 체계 유지 (브랜드 컬러)
- 1번 슬라이드: 매우 크고 강한 문장, 최대 8단어
- 마지막 슬라이드: 명확한 CTA와 계정 핸들 포함

## 게시 전략
- 빈도: 주 4~5회 (캐러셀 3개, 릴스 1~2개)
- 최적 시간: 오전 11시~오후 1시, 오후 7~9시
- 전체 일정은 [[scheduling]] 참고

## 재가공 메모
- 캐러셀은 [[x]] 스레드를 시각 슬라이드로 확장해 만든다.
- 릴스는 [[tiktok]] 스크립트에서 가져와 적응시킨다.
- 인스타그램 버전은 시스템 전체 콘텐츠 중 가장 시각적으로 polished되어야 한다.
- 전체 흐름은 [[repurpose]] 참고


5. platforms/tiktok.md
# 틱톡

## 플랫폼 DNA
- 영상 플랫폼이다. 모든 것이 영상이다.
  15초부터 10분까지 가능하지만,
  가장 잘 맞는 길이는 45~90초다.
- 분위기: 거칠고, 덜 다듬어졌으며, 진짜 같아야 한다.
  지나치게 잘 만든 콘텐츠는 오히려 성과가 떨어질 수 있다.
  사람들은 완벽함보다 진짜를 원한다.
- 독자: 가장 젊은 인구층. [[casual]] 비중이 더 높다.
  깊게 파기보다 새로운 주제를 발견하러 온다.
- 알고리즘은 발견 기반이다.
  팔로워가 없어도 바이럴 가능성이 있다.
  모든 영상이 기회를 가진다.

## 콘텐츠 규칙
- 첫 2초 안에 훅을 넣어라.
  여기서 잡지 못하면 바로 스와이프당한다.
  [[hooks]]를 사용하되, 영상용으로 변형한 반대 의견형 훅과 발견형 훅이 잘 맞는다.
- [[brand-voice]]를 따르되 가장 캐주얼하고 에너지 높게 조정하라.
  세부 조정은 [[platform-tone]] 참고
- 카메라에 대고 친구에게 말하듯 말하라.
- 기술/AI 콘텐츠에서는 화면 녹화 + 보이스오버가 매우 잘 먹힌다.
  설명만 하지 말고 보여줘라.
- 긴 인트로는 금지.
  "안녕하세요 여러분" 같은 말 없이 바로 본론으로 들어가라.
- 자막/텍스트 오버레이는 필수다.
  많은 사용자가 무음으로 본다.

## 잘 작동하는 포맷
1. 화면 녹화형 — 실제로 하는 장면을 보여줘라.
   화면을 녹화하고 보이스오버를 입힌다. 45~60초 권장
2. 퀵팁형 — 하나의 실행 가능한 팁을 30초 안에 전달.
   훅 → 팁 → 결과 구조
3. "나는 X를 Y로 대체했다" 형 — 변화 전/후를 보여줘라.
   AI/자동화 콘텐츠에 특히 잘 맞는다.
4. 리액션형 — 분야 내 트렌드에 반응하고,
   거기에 자신의 해석을 얹는다.

## 스크립트 템플릿
[훅: 2초 (텍스트 오버레이 + 보이스오버)]
[맥락: 5초]
[방법 설명: 30~40초]
[결과: 5초]
[CTA: 3초]

## 게시 전략
- 빈도: 주 5~7회 (가능하면 매일)
- 최적 시간: 오전 7~9시, 12~3시, 오후 7~10시
- 최소 30일은 꾸준히 올리고 나서 결과를 판단하라. 진짜로.
- 전체 일정은 [[scheduling]] 참고

## 재가공 메모
- 틱톡 스크립트는 [[x]] 포스트를 45~60초짜리 spoken content로 압축해 만든다.
- 하나의 핵심 아이디어에만 집중하라.
  모든 걸 다 우겨 넣지 마라.
- [[instagram]] 릴스와 유튜브 쇼츠로도 약간의 수정 후 재사용 가능하다.
- 전체 흐름은 [[repurpose]] 참고


6. platforms/youtube.md
# 유튜브

## 플랫폼 DNA
- 장문 영상 플랫폼. 알고리즘상 가장 잘 맞는 길이는 8~12분이다.
- 분위기: 교육형, 구조화, SEO 중심.
  유튜브는 사실상 검색 엔진이기 때문에,
  사람들은 답을 찾으러 들어온다.
- 독자: [[builders]]와 [[casual]]가 섞여 있지만,
  8분 이상 시간을 쓰는 만큼 스크롤러보다 훨씬 몰입도가 높다.
- 에버그린 콘텐츠가 살아남는다.
  좋은 영상 하나는 몇 년 동안 조회수를 만든다.

## 콘텐츠 규칙
- 제목이 전부다.
  SEO 최적화, 호기심 유도, 구체성.
  "AI 콘텐츠 시스템 만드는 법 (단계별 가이드)"는 좋지만,
  "내 콘텐츠 전략"은 검색되지 않는다.
- 썸네일: 굵은 텍스트, 개인 브랜드라면 얼굴,
  대비가 강한 색상.
  썸네일과 제목의 조합이 클릭의 대부분을 결정한다.
- [[brand-voice]]를 따르되 더 구조적으로 조정하라.
  세부 조정은 [[platform-tone]] 참고
- 도입 30초 안에 [[hooks]]를 활용하라.
  유튜브 훅은 최고의 글 훅을 spoken version으로 바꾼 것에 가깝다.
- 섹션 구분이 명확해야 한다.
  유튜브는 챕터도 보여주므로 적극 활용하라.

## 영상 구조
[훅 — 0:00~0:30]
문제를 제시하고 해결책을 약속하라.
예: "나는 소셜 미디어 계정 10개를 운영하지만 직접 포스트를 한 줄도 쓰지 않습니다.
이 영상이 끝나면 같은 시스템을 어떻게 만드는지 알게 될 겁니다."

[맥락 — 0:30~2:00]
왜 이게 중요한지, 대부분 사람들이 무엇을 잘못하는지,
왜 이 방식을 봐야 하는지 설명하라.

[메인 콘텐츠 — 2:00~9:00]
단계별 워크스루.
화면 녹화, 데모, 예시를 넣고,
3~5개의 뚜렷한 섹션으로 나눠 타임스탬프를 붙여라.

[정리 + CTA — 9:00~10:00]
핵심 포인트를 요약하고,
구독 유도 또는 템플릿 다운로드 같은 CTA로 마무리하라.

## SEO 규칙
- 제목: 핵심 키워드 포함, 자연스러운 문장, 60자 이내
- 설명란: 처음 2줄이 "더 보기" 전에 보이므로,
  훅과 핵심 링크를 거기에 넣어라.
  전체 설명은 200~500단어 정도
- 태그: 관련도 높은 것 5~10개, 넓은 키워드와 구체적 키워드 혼합
- 챕터: 설명란에 각 섹션 타임스탬프 기입

## 게시 전략
- 빈도: 주 1~2회
- 유튜브는 빈도보다 일관성이 훨씬 중요하다.
- 추천 요일: 화, 목, 토
- 전체 일정은 [[scheduling]] 참고

## 재가공 메모
- 유튜브 스크립트는 가장 확장된 버전이다.
  [[x]]와 [[linkedin]]을 합쳐 구조화된 튜토리얼로 만든다.
- 가장 좋은 60초 구간은 쇼츠로 뽑아
  [[tiktok]]과 [[instagram]] 릴스로 재사용하라.
- 설명란 링크는 뉴스레터나 리드마그넷으로 연결하라.
- 전체 흐름은 [[repurpose]] 참고


7. platforms/threads.md
# 스레드

## 플랫폼 DNA
- 텍스트 우선, 대화형, 의견 중심
- 게시물당 500자 제한
- 분위기: 느슨하고 커뮤니티 감성이 강함.
  X보다 더 캐주얼하다.
- 독자: 성장 중이며, 더 [[casual]] 쪽이고,
  기술 밀도는 X보다 낮다.

## 콘텐츠 규칙
- 의견과 핫테이크가 가장 잘 먹힌다.
- [[x]]보다 더 대화체로 써라.
  마치 속으로 생각을 말하듯이.
- 해시태그 금지. 링크 금지. 순수 텍스트 참여 중심.
- [[brand-voice]]를 따르되 가장 느슨한 버전으로.
  세부 조정은 [[platform-tone]] 참고
- [[x]] 콘텐츠를 적응시켜 교차 게시할 수 있지만,
  훅은 반드시 다시 쓰고 톤도 더 부드럽게 조정하라.

## 재가공
- [[x]]에서 가져오되 더 대화적인 톤으로 바꾼다.
- 링크가 필요한 CTA는 제거하라.
- 전체 흐름은 [[repurpose]] 참고


8. platforms/facebook.md
# 페이스북

## 플랫폼 DNA
- 더 연령대가 높고, 커뮤니티 중심이며, 그룹 활동이 중요하다.
- 엄격한 글자 수 제한은 없지만,
  가장 잘 맞는 길이는 300~800자 정도다.
- 분위기: 개인 브랜딩보다는
  "도움을 주는 커뮤니티 구성원"에 가깝다.

## 콘텐츠 규칙
- 질문과 토론 유도형 문장이 참여를 이끈다.
- 조금 더 긴 캡션과 개인적 맥락이 잘 맞는다.
- 네이티브 업로드 영상이 알고리즘 우선순위를 받는다.
- [[brand-voice]]를 따르되 더 따뜻하게 조정하라.
  세부 조정은 [[platform-tone]] 참고
- 프로필에만 올리지 말고,
  관련 그룹에도 공유하라.

## 재가공
- [[x]] 콘텐츠를 가져와 개인적 맥락을 더 붙여 확장하라.
- 마지막에는 댓글을 유도하는 질문을 하나 넣어라.
- 전체 흐름은 [[repurpose]] 참고


9. platforms/newsletter.md
# 뉴스레터

## 플랫폼 DNA
- 이메일 기반 플랫폼. 알고리즘과 싸우지 않고 독자를 직접 소유한다.
- 호당 1,000~2,000단어. 깊이 있는 형식.
- 분위기: 직접적이고 개인적이어야 한다.
  똑똑한 친구이자 멘토가 보내는 편지처럼.
  모든 플랫폼 중 가장 개인적인 버전이다.

## 콘텐츠 규칙
- 제목이 곧 훅이다.
  이메일용으로 변형한 [[hooks]]를 사용하라.
  예: "월 8천 달러짜리 콘텐츠 팀을 대체한 시스템"
  같은 제목이 좋고,
  "주간 뉴스레터 #47" 같은 제목은 아무도 열지 않는다.
- 개인적인 이야기나 관찰로 시작한 뒤,
  실전 내용으로 자연스럽게 넘어가라.
- 한 회차당 하나의 핵심 주제만 다뤄라.
  너무 많은 주제를 한 번에 넣지 마라.
- [[brand-voice]]를 따르되 가장 개인적인 톤으로 조정하라.
  세부 조정은 [[platform-tone]] 참고
- 마지막에는 CTA를 하나만 넣어라.
  답장을 유도하거나,
  특정 리소스를 보게 하거나,
  한 가지 행동을 하게 만드는 정도면 충분하다.
- 플레인 텍스트 또는 최소한의 디자인만 사용하라.
  화려한 템플릿은 마케팅 메일처럼 보이기 쉽다.
  플레인 텍스트는 실제 사람이 보낸 편지처럼 느껴진다.

## 재가공
- 주간 베스트 주제의 가장 깊은 버전이다.
- [[x]]의 핵심 주장 + [[linkedin]]의 서사 +
  소셜에는 공개하지 않은 인사이트를 합쳐라.
- 여기서 포스트의 "어떻게"를 가장 깊게 설명한다.
- 전체 흐름은 [[repurpose]] 참고


10. voice/brand-voice.md
# 브랜드 보이스

이 파일은 모든 콘텐츠 뒤에 있는 핵심 성격을 정의한다.
모든 플랫폼 노드([[x]], [[linkedin]], [[instagram]] 등)는
이 파일을 참고한 뒤 각 플랫폼 맥락에 맞게 조정한다.
플랫폼별 조정은 [[platform-tone]]를 참고하라.

## 핵심 성격

[브랜드의 성격을 3~5문장으로 설명하라.
구체적으로 써라. 아래는 builder/AI 분야 예시다.]

우리는 만들면서 동시에 가르치는 빌더다.
가볍지만 권위 있는 톤을 가진다 — 잘 알고 있지만,
절대 상대를 내려다보며 말하지 않는다.
우리는 실제 숫자, 실제 실수, 실제 시스템을 공유한다.
독자에게는 함께 만들고 있는 친구처럼 말한다.
직접적이고, 실용적이며, 쓸데없는 말에 알레르기가 있다.

## 톤 마커

- 캐주얼하지만 신뢰 가능해야 한다 — "imo", "btw", "lol" 같은 표현을 자연스럽게 쓸 수 있지만,
  항상 실제 데이터와 경험으로 뒷받침해야 한다.
- 직접적이고 개인적이어야 한다 — "나"를 자주 쓰고,
  독자에게는 "당신"이라고 부른다.
  강의가 아니라 코칭처럼 느껴져야 한다.
- 매끈함보다 솔직함 —
  "가장 큰 실수는 검증을 건너뛰는 것이다"는 좋지만,
  "시장 검증 프로세스 부족은 흔한 함정이다" 같은 문장은 피하라.
- 코칭 에너지 — 모든 콘텐츠가
  독자를 단계별로 직접 안내하는 느낌이어야 한다.
- 숫자와 증거 — 가능하면 구체적 수치를 넣어라.
  "월 MRR 4천 달러", "주당 리드 200개", "계정 10개"처럼.
  구체성은 신뢰를 만든다.

## 어휘

우리가 자주 쓰는 단어:
build, ship, automate, system, playbook, stack,
workflow, scale, compound, iterate

절대 쓰지 않을 단어:
moreover, furthermore, in conclusion,
it's worth noting, delve, synergy, circle back, holistic

자주 쓰는 문구:
- "진짜로 먹히는 건 이거다"
- "대부분 여기서 틀린다"
- "진짜 이유는 이것이다"
- "이건 꼭 봐라"
- "재밌게 봤길 바란다"

절대 쓰지 않을 문구:
- "오늘날처럼 빠르게 변화하는 세상에서..."
- "말할 필요도 없이..."
- "그럼 바로 본론으로 들어가서..."
- 기업형 허세 용어 모음 전체

## 포맷 규칙
- 본문은 기본적으로 소문자 스타일
- 훅/헤드라인만 Title Case 또는 ALL CAPS 허용
- 불릿 포인트는 - 기호 사용
- 생각 단위마다 줄바꿈. 빽빽한 문단 금지
- 해시태그 금지 (단, 인스타그램은 예외)
- 이모지는 최소한으로, 사인오프 용도로만 사용


11. voice/platform-tone.md
# 플랫폼별 톤 적응 가이드

핵심 보이스는 [[brand-voice]]에 정의되어 있다.
이 파일은 그 보이스가 플랫폼마다 어떻게 변형되는지 정의한다.

## X / 트위터
- 가장 캐주얼한 버전
- 전부 소문자 스타일
- 짧고 강한 문장. 군더더기 없음
- "lol", "imo", "btw" 자유롭게 사용 가능
- 냉소와 아이러니도 허용
- 예시: "10개의 툴은 필요 없다. 10개의 마크다운 파일이면 된다.
  이건 꼭 봐라."

## 링크드인
- 전문적이지만 여전히 인간적이어야 한다. 기업체 말투 금지
- "나"를 많이 쓰되, 교훈과 인사이트 프레임으로 써라
- 더 긴 문장도 허용. 서사 구조 강화
- "lol" 대신 사려 깊은 관찰로 대체
- 예시: "나는 3개월 동안 콘텐츠 시스템을 만들었고,
  지금은 그 시스템이 내 대신 10개 계정을 굴리고 있다.
  내가 실제로 만든 구조를 공유하겠다."

## 인스타그램
- 가장 쉬운 언어 사용. 비주얼이 중심이고,
  텍스트는 비주얼을 보조한다.
- 캐러셀 텍스트: 굵고 짧게. 슬라이드당 하나의 아이디어.
  1번 슬라이드는 최대 8단어
- 캡션: 더 자세히 써도 되지만 여전히 훑어보기 쉬워야 한다.
- "당신도 할 수 있다"는 aspirational 에너지 필요
- 예시: "나는 10개 계정을 운영하지만 직접 쓰지 않는다.
  시스템이 궁금하다면 넘겨보세요."

## 틱톡
- 가장 에너지 높은 버전
- 쓰는 문장이 아니라 말하는 문장이어야 한다.
  실제 말하듯 써라.
- 빠르게, 군더더기 없이, 바로 훅 진입
- "이거 진짜 미쳤다" 같은 에너지 허용
- 예시: "아직도 플랫폼마다 직접 글 쓰고 있어요?
  내가 대신 쓰는 시스템 보여드릴게요."

## 유튜브
- 가장 구조적이고 교육적이어야 한다.
- 더 길고, 더 자세하고, 더 단계별이어야 한다.
- 권위 있는 설명자 목소리 — 수업하는 전문가처럼
- 여전히 캐주얼할 수 있지만 깊이가 있어야 한다.
- 예시: "오늘은 마크다운 파일과 AI만으로 콘텐츠 시스템을 만드는 방법을
  단계별로 보여드리겠습니다."

## 뉴스레터
- 가장 개인적이고 친밀한 버전
- 똑똑한 친구에게 편지 쓰듯
- 더 취약하고, 회고적이고, 비하인드 스토리형도 가능
- 어떤 생각이든 가장 길게 풀 수 있는 플랫폼

## 스레드
- X와 비슷하지만 훨씬 더 느슨함
- 구조보다 의견이 더 강함
- "샤워하다 떠오른 생각" 같은 에너지
- 예시: "핫테이크:
  마크다운 파일 폴더 하나가 그 어떤 콘텐츠 마케팅 툴보다 강력할 수 있다"

## 페이스북
- 가장 따뜻하고 커뮤니티 친화적
- 질문하고, 대화를 초대하라
- 전술적 플레이북보다 개인적인 이야기 비중 높이기

## 규칙

플랫폼에 맞게 바꿀 때는:
1. 먼저 톤을 바꿔라.
2. 그다음 포맷을 바꿔라.
3. 그다음 훅을 바꿔라.

보이스 자체는 유지되고,
달라지는 것은 전달 방식뿐이다.


12. engine/hooks.md
# 훅 공식

모든 포스트의 시작에 이 공식을 사용하라.
훅 유형은 플랫폼과 주제에 맞게 선택하라.
전달 방식 조정은 [[platform-tone]]를 참고하라.

## 플레이북형 훅
"[원하는 결과]를 얻기 위한 [N]단계는 다음과 같다:"
- 가장 잘 맞는 곳: X, 링크드인, 유튜브 제목
- 예시:
  - "콘텐츠 제작을 자동화하는 7단계는 다음과 같다:"
  - "내가 직접 쓰지 않고 10개 계정을 운영하는 방법은 이렇다:"

## 증거형 훅
"[이전 지표] → [이후 지표] in [기간]"
- 가장 잘 맞는 곳: X, 링크드인
- 예시:
  - "0 → 10개 계정 운영, 30일 만에. 마크다운 파일로 만든 시스템"
  - "월 8천 달러 콘텐츠 비용 → 0달러. 시스템 하나 만든 뒤"

## 반대 의견형 훅
"당신에게 필요한 건 [기존 방식]이 아니다. [이것]이다."
- 가장 잘 맞는 곳: X, 스레드
- 예시:
  - "콘텐츠 팀은 필요 없다. 스킬 그래프가 필요하다."
  - "툴 15개는 필요 없다. 마크다운 파일 15개면 된다."

## 대체형 훅
"나는 [비싸거나 복잡한 것]을 [더 단순한 것]으로 대체했다"
- 가장 잘 맞는 곳: X, 틱톡, 인스타그램 1번 슬라이드
- 예시:
  - "나는 월 8천 달러짜리 콘텐츠 팀을 .md 파일 폴더 하나로 대체했다"
  - "나는 콘텐츠 툴 5개를 위키링크된 마크다운 파일 30개로 대체했다"

## 발견형 훅
"방금 [가치 있는 무언가]를 찾았다"
- 가장 잘 맞는 곳: X
- 예시:
  - "AI가 플랫폼마다 다르게 쓰게 만드는 방법을 방금 찾았다"

## 비하인드형 훅
"나는 [인상적인 것]을 운영하지만, [의외의 방식]을 쓴다"
- 가장 잘 맞는 곳: X, 링크드인, 유튜브 제목
- 예시:
  - "나는 소셜 계정 10개를 운영하지만 직접 글을 한 줄도 쓰지 않는다"

## 규칙
- 주제마다 2~3개의 훅을 테스트하라.
- 어떤 훅 유형이 플랫폼별로 반응이 좋은지 추적하라.
- 매주 업데이트하라.
  성과가 낮은 훅은 지우고, 잘 먹힌 훅은 추가하라.
- [[x]]에서 잘 먹힌 훅이 [[linkedin]]에서도 그대로 먹히는 경우는 거의 없다.


13. engine/repurpose.md
# 재가공 체인

하나의 아이디어가 들어오면,
플랫폼 네이티브 결과물 10개가 나온다.
각 결과물은 같은 주제를 다른 방식으로 사고해야 한다.
이건 재포맷이 아니다.

## 체인 순서

아래 순서대로 작성하라.
각 단계는 이전 단계를 기반으로 하지만,
반드시 플랫폼에 맞게 적응되어야 한다.

### 1단계: [[x]] (가장 먼저 작성)
X는 짧게 써야 하기 때문에,
핵심 아이디어와 가장 날카로운 훅을 뽑아내게 만든다.
이후 모든 플랫폼은 여기서 확장된다.
- 출력물: 트윗 1개 또는 장문 트윗 1개 (280~2,000자)

### 2단계: [[linkedin]] (서사를 붙여 확장)
X용 글을 가져와 개인 이야기와 더 깊은 분석을 붙여라.
단순히 길게 쓰지 마라 — 다른 각도를 추가하라.
- X는 이렇게 말한다: "나는 콘텐츠 팀을 .md 파일로 대체했다"
- 링크드인은 이렇게 말한다:
  "3개월 전만 해도 나는 콘텐츠에 월 8천 달러를 쓰고 있었다.
   그런데 마크다운과 Claude로 시스템을 만든 뒤 모든 게 바뀌었다"
- 출력물: 장문 포스트 (1,300~2,000자)

### 3단계: [[instagram]] (시각 자료로 변환)
핵심 포인트를 뽑아 캐러셀 슬라이드로 바꿔라.
각도는 비주얼 중심, 훑어보기 쉬운 구조, aspirational한 방향으로 이동한다.
- 출력물: 7~10장 캐러셀 + 캡션
- 1번 슬라이드 = 강한 훅
- 각 슬라이드 = 하나의 아이디어, 최대 30단어

### 4단계: [[tiktok]] (날것의 영상으로 압축)
45~60초 스크립트로 압축하라.
이 단계의 핵심은 "설명"이 아니라 "보여주기"다.
- 출력물: 타임스탬프가 있는 영상 스크립트
- 훅은 첫 2초 안에
- 가능하면 시스템이 실제로 작동하는 장면을 보여라

### 5단계: [[youtube]] (깊이 있게 확장)
지금까지의 내용을 합쳐 구조화된 튜토리얼로 만들어라.
시청자가 보고 그대로 따라 할 수 있어야 한다.
- 출력물: 전체 영상 아웃라인 (8~12분)
- SEO 제목 + 설명란
- 챕터용 타임스탬프 포함

### 6단계: [[newsletter]] (가장 개인적인 버전)
가장 깊고, 가장 개인적인 버전이다.
비하인드 스토리, 교훈, 소셜에 공개하지 않은 인사이트를 넣어라.
- 출력물: 1,000~2,000단어 이메일

### 7단계: [[threads]] (대화형으로 재해석)
X 버전을 가져오되 더 느슨하고 의견 중심으로 바꿔라.
- 출력물: 500자 이하의 짧은 포스트 1~3개

### 8단계: [[facebook]] (커뮤니티형으로 변환)
마지막에 질문을 붙여라.
읽게만 하지 말고, 참여를 초대해야 한다.
- 출력물: 끝에 질문이 들어간 포스트

## 리트머스 테스트

각 플랫폼 버전은 반드시 이 질문을 통과해야 한다.

"만약 누군가가 내 모든 플랫폼을 다 팔로우하고 있다면,
같은 내용을 여기저기서 반복해서 본다고 짜증낼까?"

- 그렇다면 → 재포맷하고 있는 것이다. 다시 돌아가라.
- 아니라면 → 하나의 아이디어에서 8개의 고유한 결과물을 만든 것이다. 그게 목표다.

## 플랫폼마다 실제로 바뀌는 것

| 요소 | 어떻게 바뀌는가 |
|------|----------------|
| 각도 | 같은 주제라도 진입점이 달라진다 |
| 훅 | 플랫폼마다 다시 써야 한다 |
| 톤 | [[platform-tone]]에 맞게 조정된다 |
| 포맷 | 스레드 / 캐러셀 / 영상 / 장문 글로 달라진다 |
| 길이 | 280자에서 2,000단어까지 달라진다 |
| 깊이 | 표면 인사이트에서 깊은 튜토리얼까지 확장된다 |

## 배치 작업 흐름

1. 모든 플랫폼 버전을 하루 안에 한 세션에서 다 써라.
   며칠에 나눠 쓰지 마라.
2. 반드시 체인 순서를 따라라.
   앞 단계가 뒤 단계를 먹여 살린다.
3. 하나라도 게시하기 전에 8개 결과물을 전부 함께 검토하라.
4. [[scheduling]]을 기준으로 일주일에 분산 예약하라.


14. engine/scheduling.md
# 스케줄링 & 게시 캘린더

## 주간 빈도
| 플랫폼 | 주당 게시 수 | 추천 요일 |
|--------|--------------|-----------|
| X | 7~10 | 매일 |
| LinkedIn | 3~5 | 월~목 |
| Instagram | 4~5 | 월, 수, 금, 토 |
| TikTok | 5~7 | 매일 |
| YouTube | 1~2 | 화, 목 또는 토 |
| Newsletter | 1 | 화 또는 목 오전 |
| Threads | 3~5 | X 올리는 날 같이 |
| Facebook | 3 | 화, 목, 토 |

## 최적 게시 시간
| 플랫폼 | 추천 시간 |
|--------|-----------|
| X | 오전 8~9시, 12~1시, 오후 5~6시 |
| LinkedIn | 오전 7~8시, 12시, 오후 5~6시 |
| Instagram | 오전 11시~오후 1시, 오후 7~9시 |
| TikTok | 오전 7~9시, 12~3시, 오후 7~10시 |
| YouTube | 전날 오후 2~4시 (밤새 인덱싱됨) |
| Newsletter | 오전 8~10시 |

## 배치 작업 흐름

주간 배치 작업 (일요일 또는 월요일):
1. 이번 주 주제 2~3개를 정한다.
2. 각 주제에 대해 [[repurpose]] 전체 체인을 실행한다.
3. 한 번의 세션으로 주간 포스트 16~24개를 확보할 수 있다.
4. 전부 예약한다.
   (Buffer, Hypefury, Later 또는 각 플랫폼 자체 예약 기능 사용)

일일 루틴 (15분):
1. 참여도 확인
2. 게시 후 첫 1시간 안에 댓글/답글 대응
3. 어떤 훅과 포맷이 잘 먹혔는지 기록

주간 리뷰 (금요일):
1. 어떤 주제가 가장 잘됐는가? → 그 주제를 더 만든다
2. 어떤 훅 유형이 참여를 만들었는가? → [[hooks]] 업데이트
3. 어떤 플랫폼이 가장 빨리 성장하는가? → 거기에 더 집중한다
4. 댓글/DM에서 새 콘텐츠 아이디어가 나왔는가?


15. engine/content-types.md
# 콘텐츠 유형 & 포맷

## 스레드 / 멀티파트 포스트
- 플랫폼: X(스레드), LinkedIn(여러 문단), Threads
- 사용 시점: 단계별 가이드, 리스트형 정리, 분석형 콘텐츠
- 구조: 훅 → 번호형 단계 → 결론 + CTA

## 캐러셀 / 슬라이드 포스트
- 플랫폼: Instagram, LinkedIn(문서 포스트)
- 사용 시점: 시각 가이드, 프로세스 설명, 비교형 콘텐츠
- 구조: 1번 슬라이드 = 훅, 2~9번 = 내용, 마지막 = CTA

## 숏폼 영상
- 플랫폼: TikTok, Instagram Reels, YouTube Shorts
- 사용 시점: 퀵팁, 데모, 리액션, 비하인드 스토리
- 구조: 훅(2초) → 본문(30~50초) → CTA(5초)

## 롱폼 영상
- 플랫폼: YouTube
- 사용 시점: 튜토리얼, 딥다이브, 시스템 워크스루
- 구조: 훅(30초) → 맥락(90초) → 본문(6~8분) → 요약

## 장문 텍스트
- 플랫폼: Newsletter, LinkedIn 아티클, 블로그
- 사용 시점: 깊은 분석, 개인 서사, 종합 가이드
- 길이: 1,000~3,000단어

## 짧은 의견형 포스트
- 플랫폼: X, Threads, Facebook
- 사용 시점: 핫테이크, 관찰, 단일 인사이트
- 길이: X는 280자 이하, Threads는 500자 이하


16. audience/builders.md
# 독자: Builders

## 이들은 누구인가
인디해커, 1인 창업자, AI 엔지니어, SaaS 빌더,
프리랜서, 에이전시 운영자.
이미 무언가를 만들고 있거나, 적극적으로 계획 중인 사람들.
당신이 가르치는 내용을 직접 구현할 만큼은 기술적이다.
수익 범위는 월 0달러~5만 달러 정도이며,
더 크게 키우고 싶어 한다.

## 이들이 원하는 것
- 이론이 아니라 실행 가능한 플레이북.
  오늘 바로 따라 할 수 있는 단계
- 실제 숫자. 매출, 지표, 비용, 절약된 시간
- 맥락이 있는 도구 추천.
  단순히 "이 툴 쓰세요"가 아니라,
  언제 왜 써야 하는지까지
- 시스템 사고.
  개별 팁이 아니라 요소들이 어떻게 연결되는지

## 이들에게 말하는 방식
- 직접적이고 구체적으로.
  "한번 고려해보세요"가 아니라 "5단계는 이렇다"
- 작업 과정을 보여줘라.
  실제 스크린샷, 실제 숫자, 실제 프로세스
- 동료 같은 에너지.
  위에서 가르치는 사람이 아니라 함께 만드는 사람처럼
- 도전하라.
  "이걸 안 하고 있다면 돈을 놓치고 있는 것이다" 같은 식으로


17. audience/casual.md
# 독자: Casual

## 이들은 누구인가
AI/기술에 관심은 있지만 아직 깊게 기술적이지는 않은 사람들.
비기술 직무의 직장인일 수도 있고,
AI에 관심을 갖기 시작한 초기 단계일 수도 있다.
아직은 만드는 것보다 소비하는 비중이 더 크다.
그러나 aspirational하다.
언젠가는 builder가 되고 싶어 한다.

## 이들이 원하는 것
- 복잡한 주제를 쉽게 풀어준 설명
- 영감과 "나도 할 수 있겠다"는 감정
- 시작점 — 어디서 시작해야 하는지,
  무엇부터 배워야 하는지
- 너무 intimidating하지 않은 현실적 결과

## 이들에게 말하는 방식
- 더 쉬운 언어를 사용하라.
  약어는 풀어 설명하고, 용어는 정의하라.
- 더 격려하고, 덜 압박하라.
- "가장 쉽게 시작하는 방법은 이거다" 같은 에너지
- 이미 알고 있는 것과 연결되는 비유와 비교를 사용하라.


18. 실제 실행 프롬프트 전체 한국어 번역
Claude Projects용 실행 프롬프트
주제: 내가 마크다운 파일을 사용해,
직접 아무것도 수동으로 쓰지 않고 소셜 미디어 계정 10개를 운영하는 방법

index.md의 실행 지침을 따르세요.
repurpose 체인 순서대로 각 플랫폼용 네이티브 포스트를 하나씩 만들어 주세요.
각 포스트는 같은 주제를 단순히 다시 포맷한 것이 아니라,
그 플랫폼에 맞게 완전히 다시 사고한 버전이어야 합니다.

단순 붙여넣기 방식용 지시문
이것은 내 콘텐츠 시스템입니다.
내가 주제를 주면 실행 지침을 따라 주세요.
각 플랫폼마다 그 플랫폼에 맞는 네이티브 포스트를 작성하되,
단순 재포맷이 아니라 그 플랫폼에 맞게 주제를 완전히 다시 사고한 결과물을 만들어 주세요.


19. 예시 주제에 대한 플랫폼별 사고 차이 설명 번역
원문이 전달하려는 핵심도 한국어로 함께 옮겨두면 실제 활용에 도움이 된다.
예시 주제:
"AI를 사용해 소셜 미디어 계정 10개를 관리하는 방법"
플랫폼별 결과물은 이렇게 달라질 수 있다.

X: 반대 의견형 스레드, 소문자, 캐주얼, 단계형
예: "콘텐츠 팀은 필요 없다. 30개의 마크다운 파일이 필요하다. 내가 직접 한 줄도 쓰지 않고 10개 계정을 운영하는 방식은 이렇다:"
LinkedIn: 개인 서사 + 전문적 톤 + 약 1,500자
예: "6개월 전만 해도 나는 10개 플랫폼의 콘텐츠 제작에 월 8,000달러를 쓰고 있었다. 지금은 0달러다. 정확히 무엇이 바뀌었는지 공유하겠다."
Instagram: 7장 캐러셀, 첫 장에 강한 주장
예:
1장: "나는 10개 계정을 운영하지만 직접 쓰지 않는다"
2~7장: 시스템을 시각적 단계로 분해
마지막 장: "저장하세요. 더 보려면 팔로우"
TikTok: 45초 스크린 레코딩 스크립트
예: "아직도 플랫폼마다 손으로 직접 글 쓰고 있나요? 내가 쓰는 시스템 보여드릴게요."
YouTube: SEO 제목 + 구조화된 8분 튜토리얼
예: "AI로 소셜 미디어 계정 10개 운영하는 법 (완전한 시스템 가이드)"
Newsletter: 1,500단어 깊이 있는 설명
예: "이번 주에는 몇 달 동안 조용히 구축해 온 시스템의 뒤를 공개해보려 한다..."
Threads: 대화형 핫테이크
예: "핫테이크: 콘텐츠의 미래는 네 대신 써주는 AI가 아니라, 네 대신 10명처럼 생각해주는 AI다"
Facebook: 커뮤니티 질문형
예: "여러 계정을 한 번에 운영하기 위해 직접 시스템을 만들어본 적 있나요? 제가 요즘 실험 중인 방식은 이런데, 여러분 생각도 궁금합니다."


20. 최종 요약
좋은 콘텐츠 엔진은 더 강한 한 줄 프롬프트에서 나오지 않는다.
좋은 콘텐츠 엔진은 AI가 따라갈 수 있는 구조화된 지식 그래프에서 나온다.
그리고 그 지식 그래프는 거창한 인프라보다,
잘 연결된 마크다운 파일 17개로도 시작할 수 있다.


RAG vs Agentic RAG 정리
행복한 수지아빠 — Mon, 13 Apr 2026 12:19:05 +0900


RAG vs Agentic RAG 정리
1. 한 줄 차이
RAG

사용자의 질문이 들어오면
검색 시스템이 관련 문서를 찾아오고
그 결과를 LLM에 붙여서 답하게 하는 방식

Agentic RAG

단순 검색만 하지 않고
에이전트가 계획을 세우고, 필요한 도구를 선택하고, 여러 소스를 순차적으로 탐색한 뒤
더 능동적으로 답을 만드는 방식


2. 기본 RAG 구조
이미지 상단의 흐름은 거의 이렇게 보면 됩니다.
동작 흐름

사용자가 질문 입력
서버가 질문을 검색 시스템에 전달
Search가 지식 소스에서 관련 정보 가져옴

PDF
Database
Documents
Code
Web Search
API


검색 결과를 서버가 받음
서버가 원래 질문 + 검색된 문맥을 합쳐서 LLM에 전달
LLM이 최종 답변 생성

특징

구조가 단순함
빠르고 구현이 쉬움
질문 1개 → 검색 1번 → 답변 1번 같은 흐름에 적합
정적인 문서 검색형 QA에 강함

한계

검색 전략이 고정적임
질문이 복잡하면 스스로 중간 계획을 세우지 못함
“먼저 뭐를 찾고, 그다음 어떤 도구를 써야 하는지”를 능동적으로 판단하는 능력이 약함


3. Agentic RAG 구조
이미지 하단은 단순 검색이 아니라 중간에 에이전트 레이어가 들어간 구조입니다.
동작 흐름

사용자가 질문 입력
Aggregator Agent가 질문을 받음
에이전트가 먼저 Plan(계획) 수립

ReAct
CoT
Planning


필요한 작업을 여러 하위 Agent에게 분배
각 Agent가 MCP 서버나 외부 도구를 통해 정보 수집

Local Data
Local Data Sources
Search Engine
Web Search
Cloud Engine
AWS & Azure


필요한 경우 Memory

Short Term
Long Term
를 활용해 문맥 보강


모은 정보를 통합해서 최종 응답 생성


4. Agentic RAG의 핵심 요소
4-1. Aggregator Agent
중앙 조정자 역할입니다.
하는 일:

질문 해석
작업 분해
어떤 도구를 쓸지 결정
어떤 에이전트에게 맡길지 결정
결과를 합쳐 최종 응답 생성

즉, 단순 서버가 아니라 오케스트레이터에 가깝습니다.

4-2. Planning
기본 RAG와 가장 큰 차이 중 하나입니다.
예를 들어 질문이:

“최신 시장 동향 찾아서 요약하고,
내부 문서랑 비교하고,
누락된 리스크도 정리해줘”

이런 식이면 Agentic RAG는:

최신 웹 검색
내부 문서 조회
비교 분석
리스크 정리

이렇게 중간 단계를 나눠서 처리할 수 있습니다.

4-3. Multi-Agent
Agent 1, 2, 3 같은 여러 작업 단위를 둘 수 있습니다.
예:

Agent 1: 내부 문서 검색
Agent 2: 웹 검색
Agent 3: 클라우드/API 질의
Aggregator: 결과 종합

즉, 병렬 처리 + 역할 분담이 가능합니다.

4-4. Memory
Agentic RAG는 메모리를 붙이기 쉽습니다.
Short-term memory

현재 대화 안에서 방금 찾은 정보
중간 추론 결과
직전 도구 호출 결과

Long-term memory

사용자 선호
반복적으로 쓰는 프로젝트 맥락
과거 작업 이력

이 덕분에 단순 “문서 검색기”가 아니라
점점 상황을 기억하는 작업형 시스템으로 확장됩니다.

4-5. MCP / Tool Use
이미지에서는 MCP Servers가 외부 실행 계층처럼 보입니다.
의미는 대체로:

단순 문서 검색뿐 아니라
로컬 데이터, 검색엔진, 웹, 클라우드 서비스, 각종 API 같은
실행 가능한 도구들에 접근할 수 있다는 것

즉 Agentic RAG는
“검색해서 붙여주는 시스템”을 넘어서
도구를 실제로 쓰는 시스템으로 발전합니다.

5. 둘의 차이를 표처럼 보면
기본 RAG

중심: 검색 + 문맥 주입
흐름: 단일 패스
판단: 거의 없음
도구 사용: 제한적
메모리: 보통 없음 또는 약함
적합한 작업: 문서 QA, FAQ, 단순 검색 응답

Agentic RAG

중심: 계획 + 검색 + 도구 실행 + 통합
흐름: 다단계
판단: 에이전트가 수행
도구 사용: 적극적
메모리: 단기/장기 확장 가능
적합한 작업: 복합 조사, 자동화, 멀티스텝 문제 해결


6. 언제 무엇을 쓰면 좋은가
RAG가 맞는 경우

사내 문서 검색 챗봇
고객지원 FAQ
메뉴얼 기반 질의응답
속도와 단순성이 중요한 경우

Agentic RAG가 맞는 경우

질문이 여러 단계로 나뉘는 경우
검색 외에 API 호출, DB 조회, 웹 탐색이 필요한 경우
사용자별 문맥 기억이 중요한 경우
조사 → 비교 → 판단 → 정리 같은 워크플로우가 필요한 경우


7. 실무 관점에서 더 현실적으로 보면
많은 서비스는 사실 아래처럼 갑니다.
1단계
기본 RAG

벡터 검색
문서 chunking
reranking
answer synthesis

2단계
Tool-augmented RAG

검색 + API 호출
검색 실패 시 웹 검색 fallback
citation 정리

3단계
Agentic RAG

planner
retriever agent
tool agent
memory
evaluator / verifier

즉 처음부터 무조건 Agentic으로 가기보다,
대부분은 RAG → 도구 결합 → 에이전트화 순서로 진화합니다.

8. 이 이미지의 핵심 메시지
이 그림이 말하는 본질은 딱 이겁니다:

RAG는 "찾아서 넣어주는 구조"이고,
Agentic RAG는 "생각하고, 나누고, 도구를 써서, 종합하는 구조"다.


9. 아주 짧게 다시 요약
RAG
질문 → 검색 → 문맥 추가 → LLM 답변
Agentic RAG
질문 → 계획 → 여러 에이전트/도구 사용 → 메모리 활용 → 결과 통합 → 답변


deep-project: 요구사항을 아주 제대로 정의해보자
행복한 수지아빠 — Mon, 13 Apr 2026 12:09:14 +0900
AI 코딩 도구를 쓰다 보면, 가장 먼저 부딪히는 문제는 코드 생성 자체가 아닙니다.
오히려 “무엇을 어디까지 만들 것인가”를 구조화하지 못한 상태에서 너무 큰 요구사항을 한 번에 던지는 일이 더 큰 문제입니다.
예를 들어 “SaaS 플랫폼 하나 만들어줘” 같은 요청은 그럴듯해 보이지만, 실제 구현 단계로 내려가면 인증, 결제, 대시보드, 외부 연동처럼 서로 다른 성격의 하위 문제들이 섞여 있습니다. (GitHub)
deep-project는 바로 이 지점을 다룹니다.
이 도구는 모호하고 큰 프로젝트 요구사항을 바로 구현하려 하지 않고, 먼저 인터뷰와 분해 과정을 거쳐 “계획 가능한 단위”로 나누는 데 집중합니다.

 

GitHub - piercelamb/deep-project: Claude Code plugin that transforms vague software ideas into individual, ready-to-be-planned c
Claude Code plugin that transforms vague software ideas into individual, ready-to-be-planned components - piercelamb/deep-project
github.com


 
왜 이 문제가 중요한가
프로젝트 요구사항이 큰데도 바로 설계나 구현으로 들어가면, 가장 먼저 비용 문제가 생깁니다.
같은 내용을 여러 번 다시 설명해야 하고, 각 세션마다 컨텍스트를 다시 쌓아야 하며, 잘못 쪼개진 작업 때문에 재계획이 반복됩니다.
결국 API 비용이든, 사람의 검토 비용이든, 둘 다 늘어납니다. 이는 README가 말하는 “인터뷰에 약 15분 투자하고 이후 재작업 시간을 줄인다”는 메시지와도 맞닿아 있습니다. (GitHub)
성능 문제도 큽니다.
하나의 거대한 요구사항 안에는 독립적으로 판단해야 할 서브시스템이 여러 개 들어 있는데, 이를 한 번에 처리하면 모델이 범위를 과도하게 넓게 해석하거나, 중요한 관계를 놓치기 쉽습니다.
README에서도 이런 경우 Claude가 범위에 압도되어 가정을 늘리고, 통합 이슈와 재작업으로 이어질 수 있다고 설명합니다. (GitHub)
유지보수 문제는 더 실무적입니다.
처음부터 기능 경계가 정리되지 않으면, 나중에 문서와 구현 단위가 엉키고, 어떤 컴포넌트가 무엇에 의존하는지 추적하기 어려워집니다.
특히 인증, 결제, 관리자 기능처럼 순서와 의존성이 중요한 영역은 초기에 구조를 잘못 잡으면 이후 수정 비용이 크게 올라갑니다. deep-project가 manifest와 dependency mapping을 별도로 두는 이유가 여기에 있습니다. (GitHub)
개발 경험 측면에서도 손실이 큽니다.
거대한 요구사항을 한 번에 처리하면 디버깅이 어려워지고, 세션이 끊겼을 때 어디까지 진행했는지 복원하기도 힘듭니다.
반대로 deep-project는 인터뷰 기록, 분해 결과, 디렉터리 생성, 스펙 생성 상태를 기준으로 재개 지점을 판단하도록 설계되어 있습니다. 이건 단순 편의 기능이 아니라, AI 기반 작업 흐름을 끊김 없이 유지하기 위한 핵심 설계입니다. (GitHub)
deep-project란 무엇인가
deep-project는 모호한 프로젝트 요구사항을 잘 계획할 수 있는 여러 개의 작업 단위로 분해해 주는 Claude Code 플러그인입니다. (GitHub)
비유하자면, 바로 집을 짓는 도구가 아니라 먼저 방 개수, 배관, 전기, 출입 동선부터 나눠서 설계 도면의 뼈대를 만드는 도구에 가깝습니다.
즉, “만들기”보다 먼저 “어떻게 나눌지”를 결정하는 단계에 특화되어 있습니다. (GitHub)
기술적으로 보면 이 도구는 큰 요구사항을 입력받아 인터뷰를 수행하고, 분할이 필요한지 판단한 뒤, 각 분할 단위의 의존 관계와 실행 순서를 정리한 manifest와 개별 spec.md 파일들을 생성합니다.
이 출력물은 이후 deep-plan 같은 다음 단계 도구에 넘겨 더 세밀한 구현 계획으로 이어지도록 설계되어 있습니다. 즉, 구현 도구가 아니라 “계획 전처리기”에 가깝습니다. (GitHub)
기존 방식과의 차이는 분명합니다.
보통은 하나의 긴 프롬프트로 전체 시스템을 설명하고, 그 결과를 다시 사람이 정리합니다.
반면 deep-project는 처음부터 요구사항 분해를 독립된 단계로 분리합니다. 철학적으로도 “큰 문제를 바로 풀지 말고, 먼저 경계를 정의하라”에 가깝습니다. (GitHub)
핵심 특징

AI 인터뷰 기반 요구사항 보완
입력 파일이 대충 적혀 있어도 인터뷰 단계에서 사용자의 머릿속 구조를 끌어냅니다. 그래서 처음부터 완벽한 명세를 써두지 않아도 됩니다. (GitHub)
프로젝트 분할 여부를 먼저 판단
무조건 여러 개로 쪼개는 것이 아니라, 이 프로젝트가 정말 분할이 필요한지부터 평가합니다. 작은 기능이면 단일 단위로 유지할 수도 있습니다. (GitHub)
의존 관계와 실행 순서를 문서화
단순히 파일만 여러 개 만드는 것이 아니라, 어떤 단위가 무엇에 선행하는지 manifest에 남깁니다. 이게 있어야 이후 계획과 구현이 덜 흔들립니다. (GitHub)
재개 가능한 워크플로우
세션이 끊기거나 중단돼도 기존 산출물을 보고 어디서부터 이어갈지 판단합니다. AI 도구를 실무에서 쓸 때 중요한 안정성을 의식한 구조입니다. (GitHub)
출력물이 다음 단계 도구와 자연스럽게 연결됨
각 분할 디렉터리 안의 spec.md는 이후 deep-plan에 넘기기 위한 입력으로 설계되어 있습니다. 즉, 독립 도구라기보다 파이프라인의 첫 단계입니다. (GitHub)
외부 API 키 없이 동작
README 기준으로 Python 의존성만 관리하면 되고, deep-plan과 달리 외부 API 키가 필요하지 않다고 설명합니다. 초기 진입 장벽이 낮다는 뜻입니다. (GitHub)

실제로 어떤 효과가 있는가
공개된 자료 기준으로 보면, 이 도구의 핵심 효과는 “큰 요구사항을 작은 계획 단위로 바꾸는 것”입니다.
예시로는 SaaS 플랫폼 같은 넓은 범위의 프로젝트를 인증, 결제, 대시보드 같은 식으로 분해해 각 단위를 별도 계획 세션으로 넘길 수 있게 합니다.
즉, 한 번에 모든 걸 잘하게 만드는 도구가 아니라, 한 번에 잘못 다루지 않게 만드는 도구입니다. (GitHub)
전과 후를 비교하면 차이가 분명합니다.
이전에는 하나의 넓은 요구사항을 통째로 처리하다 보니 범위가 뒤섞이고 관계가 누락되기 쉬웠습니다.
이후에는 인터뷰, 분할 분석, 의존성 정리, 스펙 생성까지 거치면서 각 작업 단위가 독립적으로 검토 가능한 형태로 바뀝니다. README는 이를 통해 수시간의 조정과 재작업을 줄일 수 있다고 설명합니다. (GitHub)
효과가 가장 큰 상황도 명확합니다.
여러 서브시스템이 얽힌 신규 프로젝트, 기능보다 제품 전체 구조가 먼저 필요한 프로젝트, 여러 계획 세션을 병렬로 나눠야 하는 팀에서 특히 유리합니다.
반대로 단일 기능이나 작은 버그 수정처럼 이미 범위가 좁은 일에는 효과가 제한적입니다. (GitHub)
특히 팀 단위 프로젝트에 잘 맞습니다.
manifest로 실행 순서와 의존성을 남기고, 각 split별 spec.md를 따로 만들기 때문에 사람이나 에이전트를 여러 갈래로 나누어 일시키기 쉬워집니다.
이 구조는 개인 생산성보다 협업 가능한 구조화에 더 큰 강점이 있습니다. (GitHub)
동작 원리 / 구조

입력 파일 검증
먼저 @path/to/requirements.md 형태의 요구사항 파일이 있는지, Markdown 파일인지, 비어 있지 않은지 검사합니다.
이 단계가 있는 이유는 이후 흐름 전체가 파일 기반 상태 관리에 의존하기 때문입니다. 입력이 불안정하면 재개도 불가능해집니다. (GitHub)
세션과 플러그인 루트 확인
세션 시작 훅이 넣어준 DEEP_PLUGIN_ROOT, DEEP_SESSION_ID 같은 정보를 바탕으로 플러그인 루트와 세션 상태를 확인합니다.
이건 단순 초기화가 아니라, 중단 후 재실행해도 같은 작업 목록과 상태를 복원하기 위한 장치입니다. (GitHub)
인터뷰 수행
고정된 질문지를 무조건 돌리는 방식이 아니라, 사용자의 답을 바탕으로 적응형 질문을 이어가며 프로젝트의 정신 모델을 끌어냅니다.
왜 이런 방식이냐면, 처음 요구사항 문서는 대개 불완전하고, 실제로 중요한 분할 기준은 사용자의 머릿속에 있기 때문입니다. 인터뷰 결과는 별도 파일로 저장됩니다. (GitHub)
분할 분석
인터뷰 내용과 원본 요구사항을 바탕으로 이 프로젝트가 여러 planning unit으로 나뉘어야 하는지 판단합니다.
중요한 점은 “항상 많이 쪼개는 것”이 아니라 “계획 가능한 단위로 쪼개는 것”입니다. 그래서 작은 기능이면 단일 단위로 유지할 수도 있습니다. (GitHub)
의존성 발견과 manifest 생성
각 split의 역할, 상호 관계, 추천 실행 순서를 project-manifest.md에 정리합니다.
이 단계가 핵심인 이유는, 나누기만 하고 관계를 명시하지 않으면 이후 병렬 작업에서 다시 충돌이 생기기 때문입니다. README는 여기에 machine-readable한 SPLIT_MANIFEST 블록도 포함된다고 설명합니다. (GitHub)
사용자 확인
도구가 제안한 분해 구조를 바로 확정하지 않고, 사용자 승인 과정을 둡니다.
이는 AI가 범위를 잘 쪼개는 것과, 실제 팀이 원하는 경계가 일치하는지를 마지막으로 맞추는 단계입니다. (GitHub)
디렉터리 생성
승인된 manifest를 바탕으로 번호가 붙은 split 디렉터리를 생성합니다.
예를 들어 01-auth-system, 02-billing 같은 구조가 만들어집니다. 이 번호 체계는 순서를 눈에 보이게 하고, 후속 작업에서 경로 규칙을 단순하게 만들어 줍니다. (GitHub)
각 split의 spec 생성
마지막으로 각 디렉터리 안에 spec.md를 작성합니다.
이렇게 생성된 스펙은 이후 더 깊은 계획 단계의 입력으로 쓰입니다. 즉, 결과물의 목적이 “문서 저장”이 아니라 “다음 자동화 단계의 안정적 입력”이라는 점이 중요합니다. (GitHub)

설치 / 사용 방법
현재 README 기준 기본 설치 흐름은 Claude Code 플러그인 마켓플레이스를 사용하는 방식입니다.
필수 조건으로는 Claude Code, Python 3.11 이상, uv가 제시되어 있습니다. (GitHub)
설치 명령어
/plugin marketplace add piercelamb/deep-project
/plugin install deep-project
/plugin enable deep-project

README에는 이미 같은 계열 플러그인을 추가한 경우, 마켓플레이스를 다시 추가하지 않고 설치만 진행할 수 있다고 안내합니다. (GitHub)
실행 흐름
먼저 planning 디렉터리에 요구사항 파일을 준비합니다.
mkdir -p planning

예를 들면 다음처럼 요구사항을 정리할 수 있습니다.
# My SaaS Platform

Build a complete SaaS platform with:
- User authentication
- Subscription billing
- Admin dashboard
- User-facing dashboard
- API for third-party integrations

이후 Claude Code에서 아래처럼 실행합니다.
/deep-project @planning/requirements.md

그다음에는 인터뷰 → 분할 분석 → 확인 → 생성 흐름으로 진행됩니다. (GitHub)
최소 실행 예제
mkdir -p planning
cat > planning/requirements.md << 'EOF'
# Internal Tool

Build an internal operations platform with:
- SSO login
- Role-based permissions
- Billing summary page
- Admin analytics
EOF

/deep-project @planning/requirements.md

실행이 끝나면 대략 다음과 같은 구조를 기대할 수 있습니다.
planning/
├── requirements.md
├── deep_project_interview.md
├── project-manifest.md
└── splits/
    ├── 01-auth-system/
    │   └── spec.md
    ├── 02-billing/
    │   └── spec.md
    └── 03-dashboard/
        └── spec.md

세션이 중간에 끊겨도 같은 명령을 다시 실행하면 기존 상태를 보고 재개할 수 있습니다. (GitHub)
자주 쓰는 예시 / 활용 시나리오
1. 여러 서브시스템이 섞인 신규 제품 기획
누가 봐도 범위가 넓은 SaaS, 내부 운영 플랫폼, B2B 제품 초기 기획에 적합합니다.
인증, 결제, 대시보드, API 연동처럼 결이 다른 문제를 먼저 갈라야 할 때 유용합니다. (GitHub)
2. deep-plan 같은 후속 계획 도구를 쓰기 전 단계
이미 spec 기반 계획 워크플로우를 운영하고 있다면, deep-project는 그 앞단에서 입력 품질을 정리하는 역할을 합니다.
특히 너무 큰 요구사항을 그대로 넣으면 후속 계획 단계도 흔들릴 수 있을 때 효과가 큽니다. (GitHub)
3. 팀 단위 병렬 계획
한 사람이 전체를 붙잡고 있기보다, split별로 각각 계획 세션을 따로 돌리고 싶은 경우에 적합합니다.
manifest에 의존성과 순서가 남기 때문에 누가 무엇을 먼저 해야 하는지 정리하기 쉽습니다. (GitHub)
4. AI 코딩 세션이 자주 끊기는 환경
컨텍스트 제한이나 세션 중단이 잦다면, 상태 기반 재개 기능이 큰 장점이 됩니다.
한 번의 긴 세션에 모든 걸 걸기보다, 단계별 산출물을 남기며 이어가는 방식에 맞습니다. (GitHub)
5. “무엇을 만들어야 하는지”부터 불명확한 프로젝트
요구사항 문서가 애매하고, 팀 내부에서도 경계가 합의되지 않은 경우에 특히 좋습니다.
인터뷰 단계가 바로 이런 애매함을 구조화하기 위한 장치입니다. (GitHub)
한계 / 주의할 점
문서상 확인되는 범위에서 보면, 이 도구는 어디까지나 분해와 계획 준비에 특화되어 있습니다.
즉, 이것만으로 상세 설계나 코드 구현이 끝나는 것은 아닙니다. 이후 단계 도구나 사람의 검토가 여전히 필요합니다. (GitHub)
현재 기준으로는 작은 작업에는 오히려 과할 수 있습니다.
README도 단일 기능, 버그 수정, 범위가 이미 명확한 작업이라면 건너뛰라고 안내합니다.
모든 문제를 무조건 잘게 쪼개는 것이 좋은 것은 아닙니다. (GitHub)
또 하나 주의할 점은, 분해 품질이 인터뷰 품질에 영향을 받는다는 것입니다.
도구가 자동으로 구조를 제안하더라도, 사용자가 프로젝트의 핵심 경계를 제대로 설명하지 못하면 결과도 어긋날 수 있습니다.
즉, 완전 자동화라기보다 “잘 질문하고 잘 정리하는 자동화”에 가깝습니다. (GitHub)
아직 검증되지 않은 영역도 있습니다.
공개 자료만으로는 대규모 조직에서 이 출력물이 얼마나 일관되게 유지되는지, 혹은 복잡한 도메인 모델에서 분해 기준이 얼마나 안정적인지까지는 확인하기 어렵습니다.
따라서 실무 적용 시에는 먼저 내부 프로젝트 한두 개에 시범 적용해 split granularity가 팀과 맞는지 확인하는 접근이 현실적입니다. 이는 공개된 문서 구조를 바탕으로 한 판단입니다. (GitHub)
마무리
deep-project의 핵심 가치는 코드를 더 빨리 쓰게 하는 데 있지 않습니다.
그보다 먼저, 큰 요구사항을 사람이 검토할 수 있고 다음 단계 도구가 다룰 수 있는 단위로 정리해 준다는 데 있습니다.
AI 코딩에서 가장 취약한 지점이 “모호한 입력”이라면, 이 도구는 바로 그 취약점을 줄이는 쪽에 서 있습니다. (GitHub)
특히 신규 제품을 설계하는 스타트업, AI 에이전트 기반 개발 워크플로우를 만들고 있는 개발자, 여러 서브시스템을 동시에 다뤄야 하는 팀에게 잘 맞습니다.
반대로 범위가 이미 분명한 작은 기능 작업에는 굳이 앞단 분해 단계를 넣지 않아도 됩니다. (GitHub)
핵심 요약

핵심 개념
deep-project는 큰 요구사항을 인터뷰와 분해 과정을 통해 계획 가능한 단위로 나누는 Claude Code 플러그인입니다. (GitHub)
차별점
바로 구현하지 않고, 먼저 split 구조와 의존성을 정리한 manifest 및 개별 spec.md를 만드는 데 집중합니다. (GitHub)
언제 쓰면 좋은지
다중 서브시스템 프로젝트, 모호한 요구사항, 병렬 계획이 필요한 팀, 후속 planning 파이프라인의 입력을 정리해야 할 때 적합합니다. (GitHub)
언제 쓰면 안 되는지
단일 기능, 작은 개선, 버그 수정처럼 이미 범위가 좁고 명확한 작업에는 과할 수 있습니다. (GitHub)
한 줄 요약
deep-project는 “AI가 코드를 쓰기 전에, 무엇을 어떻게 나눠서 계획할지 먼저 정리하는 도구”라고 보면 가장 정확합니다. (GitHub)

스킬	용도	바로 쓰는 상황
`/setup`	초기화	프로젝트 처음 시작할 때
`/tdd`	테스트 루프	기능 구현할 때마다
`/diagnose`	버그 진단	버그 리포트 들어올 때
`/zoom-out`	코드 이해	모르는 코드 영역 만났을 때

상황	조합
새 기능	`/grill-with-docs` → `/to-prd` → `/to-issues` → `/tdd`
버그 수정	`/diagnose` → `/tdd`
구조 개선	`/zoom-out` → `/improve-codebase-architecture`
나만의 자동화	`/write-a-skill`

조건	이유
업로드 이미지를 첫 프레임으로 사용	캐릭터 일관성 유지
디자인, 의상, 비율, 무기, 얼굴 유지	캐릭터 변형 방지
카메라 고정	프레임 정렬 기준 보존
줌, 팬, 회전, 흔들림, 컷 전환 금지	동일
캐릭터 화면 중앙 유지	스프라이트 시트 정렬
크기 변화 금지	셀 크기 일관성
방향 전환 금지	좌우 반전 방지
배경 계속 `#00FF00`	크로마키 제거 가능
그림자, 바닥, 효과, 모션 블러 금지	깨끗한 알파 채널

보관	정리 가능
최종 스프라이트 시트	추출된 전체 프레임
최종 프레임 셀	중간 선택 프레임
JSON 리포트	실패한 영상
Contact sheet	재실행 폴더
최종 채택 원본 비디오

섹션	내용
Colors	팔레트 토큰 (primary, secondary, accent, neutral)
Typography	폰트 패밀리, 크기, 웨이트 체계
Spacing	간격 토큰 (4px 베이스 그리드)
Components	버튼, 카드, 입력 필드 등 UI 컴포넌트 규칙
Effects	그림자, 블러, 트랜지션 효과

레이어	기술	비고
프론트엔드	React 18 + TypeScript	Vite 5 빌드, 순수 hooks 상태관리
백엔드	Express + better-sqlite3	순수 JavaScript, TypeScript 없음
에이전트 통신	child_process + SSE	CLI stdout/stderr 스트리밍
데이터 저장	SQLite (WAL 모드)	프로젝트, 대화, 메시지, 탭 상태
산출물 렌더링	srcdoc iframe	샌드백스 환경, localStorage shim
라이선스	Apache 2.0	완전한 오픈소스

레이어	기술
데스크톱 앱	Tauri (Rust)
프론트엔드	React, TypeScript, Tailwind CSS v4
상태 관리	Zustand, React Query
백엔드	FastAPI (Python)
TTS 엔진	Qwen3-TTS, Chatterbox, Kokoro, TADA 등 7종
STT	Whisper / Whisper Turbo
로컬 LLM	Qwen3 (0.6B / 1.7B / 4B)
MCP 서버	FastMCP (Streamable HTTP + stdio)
오디오 이펙트	Pedalboard (Spotify)
추론	MLX (Apple Silicon) / PyTorch (CUDA/ROCm/XPU)
데이터베이스	SQLite
빌드 오케스트레이션	just (justfile)

도구	설명
voicebox.speak	텍스트를 음성으로 출력합니다
voicebox.transcribe	오디오를 텍스트로 변환합니다
voicebox.list_captures	저장된 녹음 목록을 반환합니다
voicebox.list_profiles	사용 가능한 음성 프로필을 나열합니다

엔진	특징
Qwen3-TTS (0.6B)	가벼운 모델. 빠른 생성
Qwen3-TTS (1.7B)	표준 모델. 품질과 속도 균형
Qwen CustomVoice	50개 이상 프리셋 보이스
LuxTTS	경량 고품질 엔진
Chatterbox	23개 언어 다국어 지원
Chatterbox Turbo	감정 태그 지원 ([laugh], [sigh], [gasp])
HumeAI TADA	표현력 높은 감정 음성
Kokoro	안정적이고 자연스러운 합성

플랫폼	백엔드
macOS (Apple Silicon)	MLX (Metal) — Neural Engine로 4-5배 가속
Windows / Linux (NVIDIA)	PyTorch (CUDA)
Linux (AMD)	PyTorch (ROCm)
Windows (범용 GPU)	DirectML
Intel Arc	IPEX / XPU
모든 환경	CPU (느리지만 동작함)

스크립트	역할
transcribe.py	ElevenLabs Scribe로 영상 하나 전사. 이미 전사된 파일은 캐시에서 불러옵니다
transcribe_batch.py	폴더 안의 모든 영상을 병렬(기본 4 워커)로 전사합니다
pack_transcripts.py	전사 결과를 takes_packed.md로 변환. 침묵 0.5초 이상 또는 화자 변경 시 구분합니다
timeline_view.py	필름스트립 + 파형 PNG 생성. 특정 시간대를 시각적으로 검토할 때 사용합니다
grade.py	컬러 그레이딩. 프리셋(subtle, warm_cinematic 등) 또는 자동 데이터 기반 보정
render.py	전체 렌더 파이프라인. 세그먼트 추출 → 그레이드 → 페이드 → 병합 → 자막