AI에게 뼈대를, 사람이 디테일을: Conductor + Cursor 워크플로우

Conductor를 어떻게 하면 더 잘 쓸 수 있을까?

Conductor는 Claude Code의 데스크탑 인터페이스다.

에디터가 아니라 AI에게 채팅으로 명령을 내리는 방식이라, 처음엔 어디에 쓸지 감이 잘 안 왔다.

이전 글에서 병렬 작업 관점으로 Conductor를 소개했는데, 그 이후로 '어떻게 하면 더 잘 쓸 수 있을까'를 계속 고민했다.

 

-> AI 시대 병렬 작업: 인간의 컨텍스트 스위칭을 설계하라: https://developer-dreamer.tistory.com/224

 

그 고민 끝에 내린 결론은 이와 같다.

AI가 잘하는 영역(로직 설계, 코드 스캐폴딩)과
사람이 잘하는 영역(디자인 디테일, UX 판단)을 분리한다.

 

크게 보면 두 단계로 나눌 수 있다.

1. Conductor에서 claude code 모델로 전체적인 설계도를 그린다
2. Cursor IDE에서 세부 구현을 진행한다

 

이 단계를 어떻게 진행했는지 아래에서 더 세부적으로 정리하겠다.

---

1단계 - 전체 설계 with Conductor

1-1단계: 상태 머신을 선택한 이유

최근 캐주얼 게임을 구현했다.

지난 1년 간 꽤 많은 게임들을 구현하면서 항상 느꼈던 병목은 '전환 시점'을 어떻게 제어하는가였다.

 

제일 간단한 건 setTimeout으로 n초 뒤에 다음 단계를 트리거하는 것이다.

하지만, 이 방법은 변경에 닫힌 구현을 하게 만든다.

 

이 단계는 n초 뒤에, 이건 n*2초 뒤에... 이런 식으로 구현하다보면,

출시 직전 갑작스럽게 '여기 화면 하나만 더 추가해주세요' 같은 제안이 들어오면 멘붕이 온다.

그래서, 이걸 근본적으로 해결하고 싶어서 '상태 머신 설계'에 더 주의를 기울이게 되었다.

 

나는 xState라는 라이브러리를 사용했다.

 

애니메이션 효과나 단계 전환을 상태 머신의 step으로 묶어서 관리하니까,

단계 변경에 대한 요청이 와도 당황하지 않고 상태 머신 사이에 새 state를 껴넣고 앞 뒤 관계를 조정하면 된다.

 

모든 코드를 와르르 건드리지 않아도 된다.

(이거 정말 중요한 포인트다...)

---

1-2단계: Conductor로 상태 머신 설계하기

 

저번 글에서도 말했지만, Conductor는 에디터가 아니다.

AI에게 채팅으로 명령을 내려 간접적으로 코드를 수정할 수 있다.

 

처음에는 불편해서 자꾸 cursor IDE를 켜고 cursor chat을 찾게 됐는데,

생각해보니 이 점이 '설계에 특화된 UX'라는 생각이 들었다.

 

파일 각각을 직접 뜯을 수 없으니, 여러 개의 파일을 대략적으로 훑어보게 되었다.

자연스럽게 '큰 그림'을 그릴 수 있었다.

 

Claude Code MCP에 figma와 notion을 연결한 후 기획서와 디자인을 함께 분석했다.

 

UIUX 전체를 담은 Figma 페이지의 링크를 갖다 줬는데, 이건 너무 커서 읽지를 못했다.

결국 내가 flow 별로 figma 노드를 쪼개서 갖다줬다. (귀찮)

 

자, 이건 1단계고~ 이건 2단계고~ 이게 클릭이야 ^^

---

 

기획서랑 figma 맥락을 다 먹인 후에는 이해한 바를 나에게 설명해보라고 했다.

 

Opus4.6은 열심히 설명을 뱉었다...

 

많은 화면이 있지만, 나눠보자면 크게 두 단계로 추상화할 수 있지 않나?

AI의 응답 맥락을 읽다보니 추상화 할 수 있는 관점들이 보였다.

 

'두 단계'를 주축으로, 기획서의 화면 흐름을 state와 event로 맵핑했다.

 

기획서를 기반으로 굵직한 상태 머신 step을 잡고,

디자인을 기반으로 세부적인 step을 덧붙였다.

이 단계에서 다음 단계로 넘어갈 때는 어떤 애니메이션이 트리거되어야 한다던가...

 

만약 다음 단계 트리거가 버튼 클릭처럼 명확하다면,

onClick에서 send({type: '특정 단계'})로 보내버리면 된다.

 

하지만, n초 후 다음 단계로 이동 같은 시간 의존 트리거가 필요하다면

xState의 after를 사용하면 된다.

AI는 기획서의 모호한 부분에 대해 질문하고,
사람은 디자이너의 의도를 해석해 모호함을 채운다.

 

집중요정 프로젝트로 예시를 든 그림. 본문 내용과는 좀 차이가 있다.

 

여기에서 신기술을 하나 더 껴넣어서 사용해봤는데,

Conductor의 우측 Terminal 탭에 opencode를 실행시키는 것이다.

 

opencode의 기능 중 하나는 멀티 모델을 사용해 최적의 답변을 내놓는 것이다.

가운데 채팅창에서 어느정도 굵직한 답변이 만들어지면,

우측 터미널에 붙여넣어서 opencode에게 검증 자동사냥을 맡기곤 했다.

 

근데, Conductor 채팅 → 터미널 복붙 → opencode 응답 확인 → 다시 채팅으로 복귀,

이 과정 자체가 컨텍스트 스위칭이라 본말전도가 됐다.

스위칭 비용 대비 효과를 보지 못해서 아직 많이 쓰진 않았다.

 

이것도 몇 번의 연습을 거쳐 잘 쓰게 되면 별도의 글로 다시 가져오겠다.

 

---

1-3단계: 코드 구조 논의

 

Conductor와 상태 머신 설계를 어느정도 마친 후,

코드 구조 설계까지 진행했다.

 

매번 UI를 보면 흥분해서(;;) 눈에 보이는 대로 막 만들고 싶은 욕망이 있는데,

이렇게 하다보면 나중에 폴더 구조가 발목을 잡는 경우가 있다.

(복잡한 UI를 볼수록 구현하고 싶다는 흥분을 느끼는 사람은 저밖에 없나요?)

 

그렇다고 또 뭐 엄청나게 고도화된 구조를 만들겠다는 건 아니고,

구현 시작 시점의 기능을 반영한 최소한의 구조를 잡겠다는 것이다.

적당한 추상화가 제일 어려운 법이다.

 

코드 구조는 AI가 10초면 잡아준다.

그게 끝이 아니다.

여기서 핵심은 '계속 질문하고 판단해야 한다'는 것이다.

 

컴포넌트 분리 기준을 어떻게 할지, props drilling을 최소화하는 설계가 무엇인지,

일단 내 쪽에서 먼저 질문을 던져서 구조를 구체화했다.

 

내 질문이 다 동난 후에는, AI에게 반대로 질문을 시켰다.

자 이제 너가 질문해봐

 

AI는 나에게 다섯 가지 질문을 던졌는데,

디자인과 기획 맥락을 가지고 있는 '사람'이 대답할 수 있는 질문이었다.

 

명시적으로 문서에서 지시하지는 않았지만,

'사람'이라면 '통상적으로 이렇게 되겠거니'하고 판단하는 빈 부분들을 AI에게 채워줬다.

 

---

1-4단계: 상태 머신 코드 구현 및 UI 뼈대(스캐폴딩) 생성

 

상태 머신은 순수 로직이라 AI가 정확하게 작성할 수 있는 영역이다.

1-3단계에서 검증을 빡세게 했기 때문에 이 부분은 믿고 맡겼다.

 

그리고, 그 상태 머신을 기반으로 디자인 없이 컴포넌트 구조만 만들어 달라고 지시했다.

 

필요한 props, 상태머신과 연결하는 이벤트 핸들러, 레이아웃의 대략적인 구조만 잡았다.

 

민둥맨둥한 네모들이 화면에 잔뜩 올라갔다.

---

2단계: 디테일 구현 with Cursor IDE

2-1단계: 디자인 디테일 완성

이제 직접 뛸 차례가 됐다.

Command+Shift+O -> Command+O

 

Conductor 위에서 Command+Shift+O를 하면, 이 워크트리를 열 수 있는 툴들이 나온다.

이 상태에서 Command+O를 누르면 이 워크트리를 Cursor IDE로 열 수 있다.

 

이제 Conductor가 깎아준 민둥맨둥 네모 위에 디자인을 입히자.

-> MCP로 생산성 3배 올리는 법: https://developer-dreamer.tistory.com/216

 

전반적인 방법은 저번에 쓴 MCP 글의 내용과 마찬가지다.

 

구체적인 디자인 적용이 필요한 코드 부분을 Cursor chat에 붙여넣는다.

해당 영역에 대응되는 figma frame을 선택+우클릭해서 copy link to selection을 하고, Cursor Chat에 붙여넣는다.

 

이미 스캐폴딩이 다 짜여져 있어서 30분도 안 돼서 그럴싸한 ui가 만들어졌다.

만약 cursor chat과 0 to 1 했다면 2시간은 썼을 것이다.

야호!

---

2-2단계: 애니메이션 디테일 완성

캐주얼 게임에서 가장 어려운 부분이다.

(내 힘들다)

 

이를 극복하기 위해 디자이너님과 나는 정말 많은... 대화를 했다.

 

한때 우리는 '슝~쇽~샥~'으로 대화를 했다.

하지만, 우리는 이것을 '수치화'하는 것에 대한 필요성을 느꼈다.

'느낌' 말고 '숫자'로 이야기해보자.

 

'둥둥~'이 아니라 'translate y -20 to 20'으로,

'샥~'이 아니라 'fade out, duration 200ms'으로...

 

그리고, 디자이너님은... 최종적으로 진화하여

Claude code로 직접 원하는 애니메이션이 담긴 코드 zip 파일을 만들어서 가져오셨다.

코드 내부에는 html css js가 들어있었다.

 

figma node와 함께 이 zip 파일을 Cursor Chat에 넣었다.

 

우리 코드는 framer-motion을 쓰고 있기 때문에 코드를 그대로 적용할 수는 없었다.

 

하지만, '느낌' 만으로 주고 받던 것에 비하면

정말 쉽고 빠르게 '디자이너가 원하는 느낌'을 '코드로 재현'할 수 있었다.

 

자연어로 설명하는 것보다, 코드로 이야기하는 게 확실히 효율적이긴 했다.

 

이건 별도의 글로 더 길게 이야기해보고 싶다.

---

2-3단계: 전체 흐름 검증 -> 재설계

실제로 ui 상에서 동작을 테스트하면서 상태 머신이 의도에 부합하는지 검증한다.

 

잘못된 상태 전환을 고치기 위해 상태 머신을 수정하는 상황도 있었다.

처음에 설계 고도화를 거듭해서 나름의 최선을 만들어놓은 상태였기 때문에,

구조를 완전히 부수는 수준이 아니라 세부 스텝을 건드리는 선에서 해결할 수 있었다.

 

새로운 요구사항이나, 개발 중 디자인이나 기획이 수정되어도 유동적으로 반영할 수 있었다.

---

결론

1. 상태 머신을 먼저 설계하자

- UI 구현 중 '어... 이 상태 다음에 어디로 가야하지?'라고 판단하면 늦다

 

2. AI에게 뼈대를, 사람이 디테일을

- 세부적인 디자인은 사람이 직접 개입하는 게 효율적이다

 

AI가 잘하는 것과 사람이 잘하는 것을 구분하면
더 완성도 높은 기능을 만들 수 있다.

 

AI가 잘하는 것

상태 머신 설계 - 복잡한 조건부 전환

리팩토링 - 연쇄적으로 영향받는 파일 일괄 수정

보일러 플레이트 - 반복적인 switch-case 누락된 부분 없이 구현

맥락 기반 질문 생성 - 사람이 놓친 빈 부분 찾기

 

사람이 잘하는 것

디자인 해석 - Figma 시안의 의도를 코드로 재현

엣지케이스 판단 - 실제 화면을 보면서 유저가 잘못된 경로로 이탈하는 것을 막는 로직 제시

UX 판단 - 유저가 직관적으로 이해할 수 있도록 디자인 수정 제안

아키텍처 결정 - 통상적으로 나은 방법과 우리 코드에 나은 방법은 다를 수 있다

 

---

(번외) Conductor를 쓴 또 다른 이유: 워크트리 관리

-> AI 시대 병렬 작업: 인간의 컨텍스트 스위칭을 설계하라: https://developer-dreamer.tistory.com/224

 

이전 글에서 다뤘듯이,

worktree를 하나의 IDE에서 전환하면 커밋이 꼬이고, IDE를 여러 개 열면 관리가 번거로웠다.

 

Conductor는 이걸 하나의 창에서 해결해준다.

협업자가 같은 레포, 다른 브랜치 작업에 대한 코드 리뷰를 요청했을 때
새 워크트리를 만들어서 코드 리뷰 지점을 분석 돌리고, 그 사이에 다시 내 작업 워크트리로 돌아와 작업을 이어나갈 수 있었다.

작업을 마친 후 다시 코드 리뷰를 맡긴 워크 트리로 돌아가 AI의 코드 리뷰 사항을 읽으면서 질문을 던졌다.

그 과정에서 협업자의 코드 의도를 파악할 수 있었고, 유의미한 리뷰를 판단해서 코멘트를 남길 수 있었다.

 

작성: 2026.03.18 01:18