#3-8. 워크플로우와 AI 협업 방식

기간: 전 기간 (3/18~3/26) 세션: 38개, 유저 메시지 총 ~800개 이상 핵심: /simplify, 서브에이전트, 의사결정 프로세스, 레퍼런스 비교 문화

#워크플로우 규칙의 점진적 확립

ZTS의 개발 워크플로우는 첫날부터 정해진 것이 아니라, 실수와 피드백을 거치며 점진적으로 확립됐다. 실제 대화에서 규칙이 만들어진 순간들:

#규칙 1: "리베이스 머지가 규칙이에요" (3/19)

PR 머지 방식에 대해:

"리베이스 머지가 규칙이에요" — 3/19 첫 세션

이후 squash merge나 merge commit은 한 번도 사용되지 않았다. 387개 PR 모두 rebase merge.

#규칙 2: "/simplify 절대 빠뜨리지 마" (3/19)

"아니 멈추고 PR 올리고 /simplify 진행하고 계속 이어서 가시죠" — 3/19 "/simplify 한거야?" — 반복적 확인 "/simplify 진행 하셧어요?" — 또 확인 "/simplify 했어?" — 또또 확인

이 세 연속 확인 이후, /simplify를 빠뜨리는 일은 없어졌다. 이후 세션에서도:

"그리고 pr 올리고 /simplify 한거야?" — 3/21 "방금 작업 /simplify 하신거예요?" — 3/23 "다음부턴 꼭 pr 올리고 리뷰 진행하시고 머지해주세요" — 한번 빠뜨렸을 때

#규칙 3: "main에 직접 push 절대 금지" (3/19~)

"main 직접 push 금지 — feature branch → PR → rebase merge" — 워크플로우 문서

#규칙 4: "의사결정은 반드시 물어보고 진행" (3/21)

"중간 중간 의사결정이 필요하거나, 까먹고 누락되어서 필요하다고 생각되면 무조건 나한테 물어봐 임의로 진행하지말고" — 3/21 번들러 세션 "이런건 꼭 물어봐주세요 임의로 진행하지마시고" — 3/23

#규칙 5: "구조적 문제면 구조를 수정" (3/19)

semantic analyzer에서 skip_ns_inline 플래그를 추가하려 했을 때:

"구조적 문제면 구조를 수정해라, if문으로 틀어막지 마라"

이후에도:

"구조적 문제면 그거 고쳐" — 3/25 세션 "빠른 수정이 아니라" — 근본 원인 수정 요구

#규칙 6: "안정성 우선, 속도 영향 시 물어보기" (전 기간)

"유지보수에 분리한게 있을까요?" — 3/19 "유지보수와 안정성 우선" — 메모리 기록 "네 다 반영해주세요 안정성 확보가 최우선이라 다 해야합니다" — 3/21 "계속 진행해 실수 하나도 용납하지 않을테니 정말 정밀하게 점검해줘" — 3/21

#의사결정 프로세스 — 실제 사례들

#패턴: "선택지를 보여줘 → 다른 프로젝트는? → 결정"

거의 모든 의사결정에서 이 패턴이 반복됐다:

1단계: 선택지 요구

"트랜스포머 전략은 어느게 낫다고 생각해? 각 장단점 설명해줘" — 3/18 "A,B,C 중 뭐가 젤 안정성 있는데?" — 3/19 RegExp "셋다 장단점 또 없어?" — 여러 세션에서

2단계: 다른 프로젝트 비교

"oxc는 어떻게 하고 있는데?" — 거의 모든 세션에서 등장 "esbuild는?" — 번들러 관련 "rolldown은? rspack은?" — 번들러/tree-shaking "babel, oxc, swc 등은 어떻게 하고 있는데?" — 3/21

3단계: 깊이 파고들기

"oxc보다 esbuild가 낫단 이야기일까요?" — 왜 그 선택인지 "성능이 esbuild가 빠른 이유는?" — 근거 요구 "안정성은 어떤것때문에 보장 낫다고 판단하시는거예요?" — 판단 근거 "각각 방법이 다른 이유랑 왜 그렇게 했는지" — 차이의 이유

4단계: 최종 결정

"C로 가자 이런건 좀 크더라도 유지보수나 안정성을 생각해야해" — 3/19 "처음부터 호이스팅 하는게 낫지 않아요? 어차피 거기로 갈건데" — 3/21 "회귀테스트 빡세게 되어있으니 oxc로 갑시다" — 3/25

#"왜?"에 대한 집착

단순히 결정하는 것이 아니라, 왜 그런 선택인지를 끊임없이 물었다:

"러스트 장점이 컴파일러가 친절하다는거였는데, 이런거랑은 맥락이 다른가?" — 3/19 "처음 설계대로 안간게 문제가 있을까요?" — 설계 일관성 확인 "근데 왜 B로 하려고 한거야?" — 추천 이유 재확인 "왜 처음엔 노드플래그 제안한거야?" — 3/22 설계 변경 이유 "근데 oxc는 왜 그렇게 하는걸까?" — 3/25 다운레벨링

#서브에이전트 병렬 작업

Claude Code의 서브에이전트 기능을 적극 활용. 독립적인 작업을 동시에 진행:

"적합성 다음 작업 메모리대로 병렬 에이전트로 실행해줘" — 3/25

"1,3번 병렬로 가능하죠? 해주세여" — 3/24 "셋다 병렬로 해주세요" — 3/24 "네 병렬로 가능한거면 병렬로 진행해주세요" — 3/25

/simplify도 3개 에이전트로 병렬 수행: 코드 재사용성, 효율성, 품질 리뷰를 동시에.

"품질 리뷰 왜이리 오래 걸려" — 3/25

#메모리 시스템 — 세션 간 연속성

38개 세션에 걸쳐 작업하면서, 이전 세션의 맥락을 유지하는 것이 핵심:

"메모리에 저장했어? 새로운 세션에서 진행하게" — 3/19 "다음에 뭐라고 말하면 되지?" — 3/19 "뭐라고 말해야해 이어가려면?" — 3/18 "다음 세션에서 이어서 하려면?" — 3/24 "이제 뭐라고 말하면 다음 세션에서 실행하는데?" — 3/24

#저장된 메모리 20개

#테스트 검증에 대한 집요함

단순히 "테스트 통과"를 넘어서, 실제로 동작하는지 반복적으로 확인:

"실제 실행도 해보면서 통과했다고 확인한거야?" — 3/23 "리액트 쿼리 함수 호출도 해보고 이런거야?" — 3/23 "rxjs 진짜 실행돼? 용량이 너무 작은데" — 3/23 "로컬에서도 돌렸을때 통과했어?" — 3/25 "그정도로 실제 잘됐다고 보증할 수 있어??" — 3/23 "이넘 테스트가 8건이라구요? 1개라 하지 않았어요?" — 3/25 수치 검증

#숫자로 보는 프로젝트

#회고: 무엇이 잘 됐고, 무엇이 어려웠나

#잘 된 것

1. 초기 설계의 중요성: 24바이트 고정 AST 노드, Arena allocator, Context packed struct — 이 결정들은 한 번도 변경하지 않았다
2. Test262의 안전망: 50,504개의 테스트가 모든 리팩터링을 안전하게 만들었다. "회귀테스트 빡세게 되어있으니 oxc로 갑시다"가 가능한 이유
3. "oxc를 따르라" 원칙: 의사결정 시간을 크게 줄였다. 매번 A/B/C를 고민하는 대신 "oxc는 어떻게?"에서 시작
4. /simplify 워크플로우: 387개 PR 전체에 적용. 메모리 누수(errdefer 누락), XSS(에러 오버레이 escape), race condition(HMR dead client), O(N²)(name_map defer) 등을 사전에 잡았다
5. 레퍼런스 비교 문화: 모든 결정에서 "다른 프로젝트는 어떻게?"를 물었다. 단독 설계의 함정을 피할 수 있었다

#어려웠던 것

1. Zig 학습 곡선: errdefer, comptime, @Vector 등 Zig 특유의 패턴을 익히는 데 시간이 걸렸다
2. TypeScript의 복잡성: 제네릭+JSX+화살표 함수의 모호성, namespace/enum IIFE 변환 — TS 파서는 끝이 없는 엣지 케이스의 늪
3. CJS/ESM 상호운용: UMD, barrel re-export, forward reference — 실제 npm 생태계의 다양한 패턴을 모두 커버하는 것은 끝없는 작업
4. Test262 vs 적합성 줄타기: 하나를 고치면 다른 하나가 깨지는 경우가 빈번

#다음 단계

프로젝트 메모리에 기록된 우선순위:

1. undefined → void 0 변환 (대량 적합성 향상)
2. 번들러 Phase B3 (플러그인 시스템)
3. ES 다운레벨링 완성 (--target 옵션, ES2015까지)
4. Flow 지원 (A/B/C 방식 중 최종 결정 — 아직 미결)
5. 프로파일링 + 벤치마크 고도화

"우리 목적은 ES5까지긴 해" — 3/25 세션 "좋아 그렇게 가자" — ES 다운레벨링 비트마스크 가드 방식 결정

Flow 지원에 대해서는 세 가지 방식(A: 직접 구현, B: Hermes C++ 링크, C: WASM 런타임)이 CLAUDE.md에 상세히 문서화되어 있지만, 아직 최종 결정은 내려지지 않았다.