지난 4개월 반 동안, 제 사이트는 TRANSMISSION이라는 외피를 두르고 있었어요. 어둡고, 시안과 앰버를 쓰고, 의도적으로 테크니컬한 느낌이었죠.
네이비-차콜 배경. 시안 액센트. 글래스 패널. 일부러 그렇게 만들었어요. 저는 광고 업계에서 18년을 보냈고, 마흔에 코딩을 독학했어요. 사이트에 들어와 블로그 글까지 스크롤하고 워드마크를 지나치면서 개발자 도구 같은 미감을 알아챈 사람에게, "이 사람은 건너왔구나" 라는 시그널이 전해지길 바랐거든요.
제 역할을 다해줬어요. 그리고 끝났어요.
메모리얼 데이 연휴 동안 이전과는 완전히 다른 리디자인을 출시했어요. 라이트 모드. 따뜻한 종이 같은 배경. 시안 대신 카마인 레드. 둥근 카드 대신 가느다란 헤어라인. 모서리에는 "Vol. 04 · Issue NN"이 보이는데, Volume은 제가 build in public을 시작한 이후의 연차이고, Issue는 현재 ISO week이에요. 둘 다 알아서 갱신되도록 연결해뒀어요. 이 글을 읽는 날 헤더에는 Issue 22가 보일 수도, 23이나 41이 보일 수도 있어요. 언제 들어오느냐에 따라 다르죠. Sparkles 아이콘은 어디에도 없어요. 사이트는 이미 chandlernguyen.com에서 라이브로 돌아가고 있어요.
이 결정들만으로도 글 하나는 쓸 수 있어요. 하지만 더 쓸모 있는 이야기는 워크플로우예요. 이번 리디자인을 두 개의 서로 다른 AI 모델에 나눠 맡겼거든요. extended thinking을 켠 Claude Opus 4.7이 디자인을 맡았고, 최고 reasoning 설정의 GPT-5.5 Codex가 실행을 맡았어요. 그리고 Codex의 /goal 기능 덕분에, 제가 산책을 나가거나 저녁을 먹는 동안에도 한 번에 4시간 가까이 자율적으로 돌아갔어요.
4일. 두 모델. 거의 30개의 commit. 한 개의 사이트.
지금부터는 어떤 모델을 어디에 써야 할지, 그리고 그 경계가 지금 어디에 있는지에 대해 제가 배운 것들을 적어볼게요.
왜 TRANSMISSION을 보내야 했나
지난 2년에 걸쳐 저는 광고에서 코드의 세계로 건너왔어요. 올해 초쯤에는 사이트도 거기에 맞춰 따라잡았죠. 그 건너옴을 눈으로 보여주려고 일부러 TRANSMISSION으로 리디자인했던 거예요. 4개월 반이 지나니, 그 시그널은 할 일을 다 했어요.
다음 일은 달라요. 블로그 글에서, LinkedIn 스레드에서, Google 검색에서 들어오는 방문자들은 제가 코드를 쓴다는 걸 확인하러 오는 게 아니에요. 미디어 운영에서의 AI에 대해 뭔가 배우러 오거나, 코스를 살까 고민하거나, 코스, Prova, DIALØGUE, STRAŦUM을 프로덕트 래더로 비교하러 와요. 사이트는 시그널링을 줄이고 안내를 더 해야 했어요.
이 변화를 가장 쉽게 설명하면 이래요. 옛 사이트는 퍼스널리티 였어요. 새 사이트는 오퍼레이팅 모델 이에요. 뒤에 있는 사람은 같지만, 해야 할 일이 달라요. 그러려면 다른 미감이 필요했어요. 더 가볍고, 차분하고, 에디토리얼하고, 긴 블로그 글이 숨을 쉴 수 있고, 코스 CTA가 강매처럼 느껴지지 않고 정직하게 느껴지는 표면. 글래스 대신 따뜻한 종이.
그런데 더 어려운 문제는 미감이 아니었어요. 처리량이었어요. 사이트에는 13개 로케일, 여덟 개쯤 되는 공개 표면(home, blog, post, products, learn, about, ask, course sales), 인증이 필요한 코스 액세스 플로우, Stripe 체크아웃, 그리고 Sydney RAG 엔드포인트가 있어요. 이걸 손으로 다시 만들었다면 몇 주가 걸렸을 거예요. 저한테는 몇 주가 없었어요.
그래서 작업을 두 AI 모델에 나눴어요.
왜 디자인과 실행을 굳이 나눴나
디자인과 실행은 인지적으로 다른 작업이에요.
디자인은 느려요. 구성에 대한, 절제에 대한 판단이에요. 어떤 톤의 따뜻한 종이가 iPhone에서 너무 노랗게 보이는지, 다른 톤이 너무 차갑게 보이는지 같은 것들이요. "이 섹션을 어떻게 렌더링할까?" 보다 먼저 "이 표면은 어떤 종류가 되려고 하는가?" 를 묻는 일이에요. 좋은 디자인 작업은 시간을 압축해요. 두 시간 생각해서 결정 하나를 내리면, 열 시간의 실행을 아낄 수 있죠.
실행은 빨라요. 패턴을 적용하는 일이에요. 디자인 시스템이 주어지면 컴포넌트를 생성하고, 컴포넌트가 주어지면 13개 로케일에 걸쳐 연결하고, 페이지 레이아웃이 주어지면 바리에이션을 출시하는 거예요. 스킬이 덜 필요한 일은 아니지만, 모호함이 덜해요. 정답은 보통 명세에 비추어 방어 가능하죠.
서로 다른 AI 모델은 서로 다른 인지 작업을 더 잘해요. 지난 몇 달간 제 경험으로 보면 — 처음에는 Claude Opus 4.6으로, 지금은 4.7로, 둘 다 extended thinking 설정에서 — Opus가 더 균형 잡힌 파트너예요. 브레인스토밍을 더 잘해요. 디자인 판단도 더 잘하고요. 순수한 코드에서는 좀 더 느리고 수술적인 정밀함은 떨어지지만, 답하기 전에 전체 구성을 고려하고, 어떤 폰트가 왜 너무 친근하게 느껴지고 다른 폰트가 왜 적절하게 느껴지는지 짚어내는 방식으로 추론해요.
high-reasoning 설정의 GPT-5.5 Codex는, 디자인 팀 근처에는 가본 적 없는 유능한 시니어 소프트웨어 엔지니어 같은 느낌이에요. 빠르고요. 멀티 스텝 툴 사용에 탁월해요 — 파일을 열고, 읽고, 편집하고, 테스트를 돌리고, 다음 파일을 열고. 어떤 버튼이 너무 높은지에 대한 강한 의견은 없지만, 버튼은 출시해요. 그것도 13개 로케일 전체의 모든 바리에이션을 군말 없이요. /goal 기능을 쓰면 타깃을 넘길 수 있어요 — 예를 들어 "convert the v3 design tokens into the Next.js app, wire the new shell, ship working BottomNav, MobileAppBar, ReadingProgress, verify the build passes with the flag off" 같은 식으로요. 그리고 자리를 비울 수 있어요. 서브 스텝을 계획하고, 실행하고, 빌드를 돌리고, 깨진 걸 고치고, 계속 진행하죠. 이 프로젝트에서 자리를 비운 채 가장 길게 돌아간 시간은 4시간 조금 안 됐어요.
솔직히 말하면, 처음부터 이 분담을 의도한 건 아니었어요. 연휴 전 며칠 동안 Opus와 디자인 대화를 이어가고 있었거든요. 연휴가 시작될 무렵에는 디자인 방향 문서와 데스크탑 프로토타입이 손에 있었어요. 연휴 자체에는 실행을 Codex에 넘겼는데, 그렇게 하고 한 시간도 안 되어서 각 모델이 자기 절반의 작업에 얼마나 잘 맞는지 알아챘어요.
Opus가 한 일: 디자인 단계
디자인 작업은 리빌드 전 며칠간 Opus와의 긴 대화 속에서 일어났어요. 그 대화에서 두 개의 산출물이 나왔고, 둘 다 지금 레포에 들어가 있어요.
1. 디자인 방향 문서. doc/v3-design/ 아래 여섯 개의 마크다운 파일. 왜 그러는지, 토큰, 모바일 패턴, 페이지 명세, 접근성 제약, 실행 계획. 13,000자가 넘는 결정들이고, 대부분 제가 준 브리프를 토대로 Opus가 쓴 거예요. 지시는 이랬어요. "다음 사이트는 SaaS 대시보드가 아니라 작은 인쇄 매거진처럼 느껴졌으면 좋겠어. 절제를 통해 주목을 얻어내. Operating Model 2×2 프레임워크를 시각적 시그니처로 써."
2. 데스크탑 HTML 프로토타입. public/design-prototype-v2/의 평평한 디렉터리에 여섯 개의 페이지와 공유 style.css만. React도, Tailwind도, 프레임워크도 없이, 손으로 쓴 HTML만요. 로컬 서버에서 모든 페이지를 클릭해보면서, 디자인 시스템이 실제로 시스템으로서 버텨주는지 감각으로 확인하려고요. 주말 내내 리빌드 동안 시각적 처리의 진실은 이 프로토타입이었어요. 헷갈릴 때 답은 "프로토타입에 맞춰"였어요.
Opus가 내린, 가장 중요했던 결정 몇 가지를 적어볼게요.
-
폰트 뒤집기. 이전 디자인 패스에서, 가용성과 출시 용이성을 이유로 Manrope를 디스플레이 폰트로 못박은 적이 있었어요 — Claude Sonnet 4.6 세션에서 commit된 거였어요. 18시간 뒤, 저는 디자인 대화를 extended thinking을 켠 Opus 4.7로 옮긴 상태였고, Opus의 첫 번째 움직임은 그 잠금을 다시 검토하는 거였어요. 제가 저녁 내내 공식 PP Neue Montreal 견본 페이지에서 글자 모양을 비교한 다음에 교체가 들어갔어요. commit 메시지는 타이포그래피 범죄 현장 같았어요: "Manrope rendered too rounded and friendly... Satoshi has the same condensed-grotesque proportions, the same double-storey
a, single-storeyg, sweptRleg, cleanly-sheared terminals." 흥미로운 지점은, 같은 결정을 두고 두 개의 Claude 모델이 다른 판단에 도달했다는 거예요. Sonnet은 안전한 선택을 골랐고, Opus는 옳은 선택을 골랐어요. -
카마인 선택. 시안은 AI의 기본 액센트예요. Opus와 저는 카마인 레드 —
#c33824에 도달했어요. 인쇄 잉크 빨강, 갤리 교정지에 편집자가 표시하는 색, 또는 Loeb Classical Library 책장에 꽂힌 라틴어 책의 색이에요. 이유는 구체적이었어요: "the site is trying to feel editorial, not developer-tool. Cyan signals tech. Carmine signals craft. Use the carmine sparingly, always at high contrast, ideally on warm paper." 이런 결정은 실행에 최적화된 모델이 알아서 손을 뻗을 만한 종류가 아니에요. -
시각적 시그니처로서의 Operating Model. 코스에서 가르치는 2×2 프레임워크 — Automate / Protect / Deepen / Change — 가 새 사이트의 조용한 브랜드 마크가 돼요. 지금 구현에서는 절제된 두 곳에만 등장해요: 홈페이지의 thesis 블록과, 긴 글에 붙는 작은 thesis 마커. 프레임워크 자체는 제 것이지만, 이걸 사이트의 시각적 정체성으로 만들자는 움직임은 Opus와의 디자인 대화에서 나왔어요.
-
다크보다 라이트. Opus는 라이트 모드를 퍼스널리티로, 다크 모드를 지원되는 바리언트로 하자고 주장했어요. 논리는 이래요. 긴 글 읽기는 글래스보다 따뜻한 종이가 더 편하고, 가격표는 라이트 배경에서 더 정직하게 느껴지고, 거의 모든 AI 도구가 기본으로 다크를 출시하니까 라이트가 차별화 요소가 된다고요. 저는 몇 시간 반대했다가, 동의했어요.
Opus는 주로 디자인과 리뷰 루프를 맡았고, Codex가 실행 패스를 했어요. Opus가 한 일은 느린 게 보상받는 종류의 일이었어요.
Codex가 한 일: 실행 단계
디자인 문서와 프로토타입이 끝나자, 작업은 Codex로 넘어갔어요.
새로운 Codex 세션을 열고, 디자인 방향 파일을 컨텍스트로 주고, /goal 세션을 돌리기 시작했어요. 각 goal은 명확한 끝 상태를 가진 멀티 스텝 타깃이었어요.
Goal: Convert the v3 design tokens from
doc/v3-design/components/tokens.cssintosrc/app/globals.css. Remove the conflicting TRANSMISSION tokens. Wire up the three new fonts viasrc/lib/fonts.tsandsrc/app/layout.tsx. Generate the v3 shell behind the feature flagNEXT_PUBLIC_ENABLE_V3_DESIGN. Ship a workingBottomNav,MobileAppBar, andReadingProgress. Verify the build passes and that no existing pages are visually affected when the flag is off.
이런 멀티 스테이지 타깃이야말로 /goal이 설계된 용도예요. Codex는 서브 스텝을 계획하고, 실행하고, pnpm build를 돌려 타입 에러를 체크하고, 깨진 걸 고치고, 빌드를 다시 돌리고, 계속 진행해요. 산책을 다녀와 보니, v3 셸이 플래그 뒤에서 코드베이스에 들어가 있었고, 새 폰트들이 로드되어 있었고, 모바일에서 바텀 내비가 그려지고 있었어요.
이어진 /goal 세션들은 이런 일을 했어요.
- 프로토타입에서 v3의 홈과 아카이브 페이지를 생성한다.
- v3의 포스트 레이아웃을 생성한다. 리딩 프로그레스 바와 v3 공유 버튼 포함.
- v3의 products와 learn 페이지를 생성한다. 명세의 래더 구조에 맞춰서.
- 기존의 코스 세일즈, 로그인, 사인업, MFA, 액세스 페이지를 v3에 시각적으로 정렬한다. 단, Stripe나 Supabase Auth의 기저 로직은 건드리지 않는다.
- v3의 코스와 Ask Sydney 표면을 13개 로케일에 걸쳐 로컬라이즈한다. 기존
messages/{locale}.json파일을 번역 소스로 써서.
개입 없이 완료된 가장 긴 실행은 4시간 조금 못 됐어요. 가장 짧은 건 45분쯤. 4일 동안 거의 30개의 commit을 출시했고, 대부분은 Codex의 첫 번째 또는 두 번째 패스였어요. 모델의 출력이 맞지만 모양이 살짝 다른 부분을 제가 손으로 가볍게 정리한 정도였죠. 솔직히 셈해보면, 지금 프로덕션에서 돌아가는 코드의 대부분은 Codex가 쓴 거라고 생각해요. 나머지를 제가 썼거나 편집했고요.
/goal에서 가장 쓸모 있는 건 속도가 아니에요. 자율성이에요. 지금까지 AI 도구로 돌려온 대부분의 코딩 세션은, 제가 키보드 앞에 머물러 있어야 했어요. 변경을 승인하고, 다음 파일을 받아들이고, diff를 리뷰하고. /goal은 원하는 최종 상태 를 지정하고 자리를 비울 수 있게 해줘요. 돌아오면 변경이 완료되어 있거나, 모델이 제 판단을 필요로 하는 지점에서 일시정지된 세션이 기다리고 있어요. 작업의 모양이 달라져요. 단일 편집의 베이비시터에서, 여러 시간짜리 세션의 플래너가 되는 거죠.
그래도 경계가 남아 있는 곳
디자인과 실행을 두 모델에 나누는 게 마법은 아니에요. 한 모델이 다른 모델을 필요로 하는 순간, 그리고 어느 쪽만으로는 부족한 순간이 여전히 있어요.
Sparkles 아이콘. Codex가 깔끔한 v3 모바일 셸을 생성해줬는데, Ask 탭에 Sparkles ✨ 아이콘이 붙어 있었어요 — AI 도구의 보편적인 표식이죠. 명세에 비추어 아이콘은 맞았어요. 명세에는 "do not use the cliché." 라고 쓰여 있지 않았으니까요. 며칠 뒤에 그걸 알아채고 Opus로 돌아가 대체 안을 의논했어요. 여러 번 반복했어요: Operating Model 마크, 그다음에는 카마인 레드의 Newsreader 이탤릭 물음표 — 오래된 에세이의 여백에 적혀 있을 법한 글리프요. 최종 해답은 Opus의 아이디어였어요. Codex는 15분 만에 출시했고요.
일장기 순간. Operating Model 마크가 모바일 앱 바 왼쪽 위, 제 이름 옆에 자리 잡고 있는 동안, 저는 2~3일을 그걸 들여다봤어요. 따뜻한 종이 같은 사각형 위의 작은 카마인 점. 어느 저녁, 다른 사람의 눈으로 그걸 다시 보다가 작은 깨달음이 훅 왔어요. 그게 일본 국기와 똑같아 보였거든요. 일장기(Hinomaru). 옅은 바탕에 작은 빨간 해. Opus도 Codex도 이걸 잡아내지 못했어요. Opus가 그 마크를 디자인했고, Codex가 구현했고, 둘 다 리뷰까지 했는데도요. 이 시각적 연상은 어느 모델도 볼 수 없는 문화적 패턴이었어요. 저는 워드마크에서 그 마크를 지우고 다른 해법으로 손을 뻗었어요. (같은 이탤릭 ? 가 결국 Ask 탭의 그 자리를 채우게 됐어요.)
13개 로케일 롤아웃. Opus가 각 로케일의 UI 뉘앙스를 사려 깊게 디자인할 수도 있었겠지만, 그러려면 며칠이 걸렸을 거예요. Codex 혼자서는 디자인 판단을 할 수 없지만, 일단 패턴이 정해지고 나면 하루 저녁에 13개 로케일을 다 출시할 수 있어요. 이게 분담의 가장 문자 그대로의 예시예요. 디자인은 느리게, 실행은 빠르게.
서로 어울리는 폰트 세 개 고르기. Opus는 Satoshi(디스플레이), Newsreader(이탤릭 액센트), JetBrains Mono(라벨)를 골랐어요. Codex가 이 조합을 스스로 골랐을 리는 없고요 — Opus가 대화 속에서 보여준 그 느림이 없었다면 저 혼자서도 여기에 도달했을지 솔직히 자신이 없어요. 세 개의 폰트 구성은 실행의 호출이 아니라 디자인의 호출이에요.
두 시스템 사이의 대화는 모델들 사이가 아니라 제 머릿속에서 일어나요. 그게 2026년 시점에 아직 자동화되지 않은 부분이에요 — 그리고 지금 테이스트 라는 단어가 무엇을 뜻하는지 정의하는 부분이라고 저는 생각해요.
솔직한 셈
4일. 거의 30개의 commit. 프로덕션 v3는 chandlernguyen.com에서 라이브예요. 새 사이트는 새 일을 하고 있어요. 방문자에게 "내가 건너왔다"고 말하는 게 아니라, "다음에 뭘 읽으면 좋을지" 찾도록 도와주는 일을요.
사이트에는 아직 쫓고 있는 문제가 남아 있어요. 초안 시점에 프로덕션 Lighthouse 모바일에서 블로그 아카이브가 4.6초에 떴는데, 제 로컬 Chrome DevTools 트레이스에서는 같은 이미지가 264밀리초에 그려졌어요 — 같은 코드, 매우 다른 네트워크 모델이죠. 지금 제 유력 가설은 폰트 프리로드 압력이에요. 프리로드된 세 개의 웹폰트와 렌더 블로킹되는 세 개의 CSS 청크가 쓰로틀된 모바일 연결에서 이미지와 결승선을 두고 경주하고 있는 거 아닌가 싶어요. 마지막 날에 가장 작은 레버리지 버전의 수정을 배포해뒀는데, 그게 안착했는지 확인하려면 새 Lighthouse 런이 필요해요. 지금 읽고 있는 이 글은 수정 이후의 숫자가 나오기 전에 쓰여졌어요.
구독료 셈은: 최상위 티어의 Codex 구독에, 이미 가지고 있던 Claude Max. 합쳐서 월 몇 백 달러 정도. 이 처리량을 생각하면 싸요.
v3가 세 주가 아니라 나흘 만에 일어난 건, 대체로 디자인과 실행 단계를 분리해서 각각에 더 잘 맞는 모델에 맡겼기 때문이에요. 이게 보편적이라고는 생각하지 않아요. 한 모델이 둘 다 해낼 수 있는 프로젝트도 있고, 어느 모델도 옳은 파트너가 아닌 프로젝트도 있을 거예요. 그래도 강한 디자인 관점을 가진, 멀티 페이지·멀티 로케일·멀티 표면의 리디자인이라면, 이 분담이 제가 다시 손을 뻗을 워크플로우예요.
혹시 최근에 본인이 직접 AI 보조 리빌드를 해보셨다면, 작업을 어떻게 나눴는지 정말 듣고 싶어요. 한 모델로 엔드 투 엔드로 돌렸나요? 저처럼 단계로 나눴나요, 아니면 다른 축으로 — 컴포넌트별로, 파일별로, 작업 유형별로 — 나눴나요? build in public의 다음 물결은 AI를 쓰느냐 아니냐가 아니라, 어느 AI 를 어느 부분 에 쓸 것이냐에 대한 것이 될 거라고 저는 생각해요.
결과를 보고 싶다면, 지금 보고 계신 게 그거예요. 홈은 chandlernguyen.com. 프로덕트 래더는 /products/. "오퍼레이팅 모델"이라는 아이디어가 출발한 코스는 /learn/에 있어요.
감사합니다, Chandler