Skip to content
··11분 읽기

저는 이제 Claude Code를 coding 말고 거의 모든 일에 쓰고 있어요

Claude Max를 해지한 지 19일. 제 패턴은 이제 꽤 분명해졌어요. xHigh의 GPT-5.4를 올린 Codex가 coding 자리를 가져갔고, xHigh의 Opus 4.7을 올린 Claude Code가 제 책상에 남은 나머지 자리를 전부 가져갔습니다.

2026년 4월 3일, 저는 Claude Max를 해지한 뒤 실제로 무슨 일이 벌어졌는지 30일 뒤에 돌아와 솔직하게 말하겠다고 썼어요.

그런데 저는 11일 먼저 돌아왔습니다.

조급해서가 아니에요. 패턴이 이미 굳었고, 5월 2일까지 답을 묵혀 두는 건 거의 연출에 가깝기 때문이에요.

처음 들으면 결론이 좀 이상하게 들립니다. Claude Code라는 이름의 툴이 이제는 제가 code를 제외한 거의 모든 일에 쓰는 툴이 됐거든요.

짧게 말하면 이렇습니다.

  • xHigh thinking의 GPT-5.4를 올린 Codex가 coding 자리를 가져갔어요.
  • xHigh의 Opus 4.7을 올린 Claude Code가 제 책상에 남은 모든 자리를 가져갔어요.
  • "저렴한 Codex면 충분하다"는 이야기는 실제 limits를 맞닥뜨리는 순간 깨졌어요.

가장 깔끔한 thesis로 줄이면 아마 이 말일 거예요.

code와 관련된 일은 전부 xHigh의 Codex-GPT-5.4로. 그 외의 모든 일은 xHigh의 Claude Code with Opus 4.7로.

19일 전의 제가 예상했던 것보다 훨씬 더 선명한 분리예요.

그리고 제가 생각했던 것보다 더 비싸고, 동시에 제 workflow의 심리를 더 많이 드러내는 답이기도 했어요.

처음 깨진 건 code quality가 아니었어요

해지 글을 쓸 당시에는 이야기가 단순해 보였어요.

  • Claude Max: 월 200달러
  • Codex / ChatGPT: 월 20~25달러
  • execution quality 차이는 빠르게 줄고 있었고
  • OpenAI 쪽 reliability가 더 강해 보였어요

그래서 쉬운 downgrade처럼 보였죠.

그런데 실제로는 아니었습니다.

처음 무너진 건 architecture도, plan quality도, execution discipline도 아니었어요.

무너진 건 limits 이야기였어요.

제 실제 타임라인은 더 정확히 말하면 이랬습니다.

  • Apr 6: ChatGPT Business seat 두 개를 월 25달러씩, 월별 결제로 등록했어요.
  • Apr 6: 이미 그날부터 workaround 관점으로 생각하고 있었어요. 예전과 비슷한 coding pace를 유지하려면 Codex를 돌릴 수 있는 account가 세 개쯤 필요할지도 모른다고 느꼈거든요.
  • Apr 10: 그 setup으로 며칠 살아 본 뒤에는, 이제는 확실히 말할 수 있을 만큼 증거가 쌓였어요. 저렴한 account 세 개를 써도 Claude Max가 가장 좋을 때 주던 경험은 재현되지 않았어요.
  • Apr 12: 월 100달러짜리 ChatGPT Pro를 샀어요. pure coding에 Codex를 더 많이 쓸수록, high나 xHigh reasoning의 GPT-5.4를 더 많이 원하게 됐지, 덜 원하게 되지 않았기 때문이에요.

이게 4월 3일 글에 대한 첫 번째 솔직한 수정입니다.

대체재는 "$200짜리 Claude Max가 $20짜리 Codex로 바뀌었다"가 아니었어요.

오히려 이런 쪽에 가까웠습니다.

  • "예전과 똑같은 Anthropic plan은 이제 필요하지 않다."
  • "하지만 저렴한 tier가 주는 것보다 더 많은 Codex capacity는 여전히 필요하다."
  • "진짜 비교 대상은 benchmark 스크린샷이 아니라, 실제 limits 아래에서의 workflow quality다."

지금 제 판단으로는 OpenAI가 market share를 위해 limits에 꽤 공격적으로 나서고 있을 가능성이 커 보여요. 이건 추론이지 내부 정보는 아닙니다. 만약 그게 맞다면, 이 창이 영원히 열려 있지는 않을 수도 있어요.

그래서 오늘의 20달러 economics만 보고 전체 결정을 내린다면, 적어도 이 pricing environment가 안정적이라기보다 전술적일 수 있다는 점은 인정해야 해요.

Codex가 coding 자리를 가져갔어요

제가 배운 가장 큰 점은 xHigh thinking의 GPT-5.4가 coding specialist처럼 느껴진다는 거예요.

아주 카리스마 있는 specialist는 아니고요.

따뜻한 specialist도 아니에요.

굳이 친구가 되려 드는 타입도 아닙니다.

하지만 specialist인 건 분명해요.

Codex에는 예상보다 더 마음에 들었던 어떤 건조함이 있어요. 쓸데없이 personality를 과시하지 않고, 조심스럽고, methodical하게 일하는 엔지니어와 함께 있는 느낌이거든요.

긴 workday에서는 그게 생각보다 더 중요했습니다.

제게 가장 분명했던 순간은 4월 17일이었어요. xHigh의 Codex-GPT-5.4에게 이미 합의한 plan을 건네고 그대로 일을 맡겼습니다. 그러자 30분에서 45분 동안 한 session 안에서 계속 움직이면서 plan을 아주 충실하게 따라가고, local에서 unit tests, integration tests, browser tests를 쓰고 돌렸어요. 제가 옆에서 계속 붙어 있지 않아도 됐습니다.

이 정도 일관성으로 그걸 해 준 다른 툴은 아직 못 봤어요.

그 경험으로 Codex를 보는 방식이 바뀌었습니다. 이제는 "작은 일엔 충분히 괜찮다" 정도가 아니에요. plan만 명확하면 길고 disciplined한 execution을 해낼 수 있어요.

pure coding work에서는 이제 거의 항상 Codex로 갑니다.

  • architecture
  • implementation
  • debugging
  • eval design
  • test framing
  • pipeline cleanup
  • production-minded한 product logic

4월의 가장 좋은 예시는 Prova예요.

Prova에서 정말 유용했던 일의 대부분은 화려하지 않았어요. "모델이 얼마나 똑똑한지 보라"는 류의 일이 아니었죠. 오히려 이런 일이었어요.

  • composable sprint 평가
  • onboarding logic 정리
  • roadmap generation과 assigned sprint state 사이의 모순 찾기
  • 실제 user row와 실제 production behavior를 바탕으로 제품 개선하기

이런 종류의 일에 Codex가 굉장히 잘 맞더라고요.

특히 일이 다음과 같을 때요.

  1. contradiction 찾기
  2. logic bug 분리하기
  3. correctness와 RFC territory 구분하기
  4. 가장 작지만 방어 가능한 다음 수를 제안하기

가장 분명한 예시 중 하나는 builder intent를 가진 user의 Prova production row 하나에서 나왔습니다.

그때 시스템은

  • builder intent user에게 marketing_vp 라벨을 붙였고
  • table-stakes-diagnostic를 할당했고
  • journey의 더 뒤에서 시작하는 roadmap을 만들었고
  • onboarding 직후 Context Check card를 보여 주고 있었어요

이 에피소드가 유의미했던 이유는 diagnosis 자체보다도 cross-review loop에 있었어요.

Opus 4.7은 저를 첫 세 가지 문제까지 데려갔습니다.

  • track calculation bug 하나
  • timing bug 하나
  • builder-opener / RFC question 하나

그다음 GPT-5.4가 분석을 더 밀어붙여서, Opus가 놓친 모순을 잡아냈어요.

  • assigned first sprint와 generated roadmap이 같은 user에게 이미 서로 다른 두 진실을 말하고 있었다는 점이죠

이건 중요했어요. 논의가 "Builder RFC를 지금 ship할까?"에서 "우선 live contradiction부터 고치고, 그다음 RFC로 돌아가자"로 바뀌었거든요.

그건 저를 감탄시키려는 모델처럼 느껴지지 않았어요. 오히려 "지금 있는 contradiction부터 고치고, product theory는 그다음에 이야기하자"라고 말하는 senior SWE처럼 느껴졌어요.

이 패턴이 이번 달에 충분히 자주 반복되면서, 저는 Codex를 더 이상 "더 저렴한 대안"으로 보지 않게 됐어요. 이제는 제 primary coding instrument로 보고 있습니다.

Claude Code가 남은 모든 자리를 가져갔어요

만약 이야기가 거기서 끝났다면 답은 단순했을 거예요. Codex로 갈아타고 계속 가면 되니까요.

하지만 실제로는 그렇게 되지 않았습니다.

Opus 4.7을 올린 Claude Code는 output이 taste에 달린 일, 혹은 loop가 길고 iterative하며 context-heavy한 일에서는 여전히 더 낫습니다.

이 지점에서 이 글의 제목은 더 이상 모순처럼 들리지 않고 오히려 정확하게 들리기 시작해요. 예전엔 code를 쓸 시간만 되면 instinct처럼 손이 가던 Claude Code가, 이제는 code를 쓰는 것 말고 거의 모든 일을 할 때 손이 가는 tool이 됐으니까요.

여기서 말하는 "다른 모든 일"은 이런 것들입니다.

  • 제 목소리처럼 들려야 하는 writing
  • structure와 rhythm에 대한 반복 작업
  • naming과 positioning
  • tagline과 brand phrasing
  • blog cover art를 위한 image prompt
  • logo와 identity exploration
  • 단순한 functional UI가 아니라 visual judgment가 필요한 /frontend-design
  • 여러 session에 걸쳐 point of view를 쌓아 가는 긴 research thread

지난 19일 동안의 경험으로 볼 때, 이건 계속 반복해서 사실로 남아 있었습니다.

차이는 feedback loop가 있을 때 특히 선명해져요.

Claude와 Codex 둘 다 과거 post를 읽고, 이전 prompt를 살피고, 기존 작업을 reference로 쓸 수 있습니다. 하지만 제가 여러 차례 refinement를 돌리고, 각 시도 뒤에 feedback를 줄 때는, Claude가 제가 원하는 방향을 더 안정적으로 이해해 줍니다.

이건 writing에도 해당돼요.

image prompting에도 해당되고요.

naming에도 마찬가지예요.

가장 분명한 product example은 Prova입니다. 저는 그 이름을 Codex로 얻지 못했어요. 그런 종류의 일에는 Opus가 필요했거든요. brand language exploration에서도 비슷했어요. GPT-5.4는 solid하고 competent한 답을 줍니다. Opus는 더 강한 creative range를 줬어요.

같은 패턴은 site design에서도 보입니다.

Superpowers의 /frontend-design workflow는 일이 engineering-led가 아니라 design-led일 때, 저에게는 GPT-5.4보다 Opus에서 여전히 더 잘 작동해요. Codex는 functional한 결과물을 줍니다. Claude는 제가 실제로 자부심을 갖고 ship하고 싶은 결과물을 더 자주 줍니다.

그래서 질문이 이거라면,

"Codex가 Claude를 전부 대체했나요?"

답은 아니요입니다.

대체한 건 coding 자리예요. 전부는 아닙니다.

이 구분은 중요해요.

익숙함은 진짜였고, 금단감도 진짜였어요

저는 Claude Code를 거의 13개월 써 왔습니다.

그 정도 시간이 쌓이면 바뀌는 건 선호 목록만이 아니에요. 일할 때의 몸의 감각 자체가 바뀌죠.

Codex 쪽으로 더 강하게 옮겨 갔을 때, 저도 분명히 일종의 금단 같은 느낌을 받았어요.

Codex가 나빠서가 아니에요.

그냥 달랐기 때문이에요.

마찰 지점은 작았지만 계속 누적됐습니다.

  • 몇몇 permission confirmation
  • 어떤 순간에는 질문을 하나 더 하는 느낌
  • sterile한 응답 톤
  • loop 안에 익숙한 Claude "voice"가 없다는 점

이건 객관적인 결함이 아닙니다.

workflow 차이예요.

그리고 익숙함은 그 차이를 어떻게 체감하는지까지 바꿔 놓습니다.

저는 이 전환을 순수하게 합리적인 경제학자처럼 통과했다고 가장하고 싶지 않아요.

그렇지 않았거든요.

어느 순간 저는 second opinion이 필요해서가 아니라, 그냥 extra safety-net review를 받고 싶어서 Claude에 일을 다시 태우는 제 자신을 발견했어요. "깔끔하게 갈아타는 중"이라는 제 내러티브보다 그 끌림이 더 강했던 거죠.

그 경험이 가르쳐 준 건, 진짜 dependency가 Claude의 raw capability에만 있던 게 아니라는 점이었어요. 거기에는, 다른 종류로 trust하는 또 하나의 intelligent system이 loop 안에 있다는 안전감 도 포함돼 있었어요.

그래서 저에게 최종 답은 처음부터 "하나를 영원히 고르자"가 될 수 없었습니다.

workflow의 심리도 중요해요.

Codex에도 Codex만의 failure mode가 있어요

이 구간은 Codex의 연승 행진이 아니었습니다.

저 역시 현실적인 문제들을 만났어요.

진짜로 Codex 특유의 문제처럼 느껴졌던 첫 사례는 4월 14일이었습니다. 두 개의 terminal session에서 이런 오류를 맞았어요.

{
  "error": {
    "message": "Unknown parameter: 'prompt_cache_retention'.",
    "type": "invalid_request_error",
    "param": "prompt_cache_retention",
    "code": "unknown_parameter"
  }
}

이런 종류의 문제는 reasoning layer가 아니라 harness layer에 대한 trust를 깨기 때문에 중요합니다.

또 Codex는 deploy나 production touch와 관련해서, 같은 session 안에서 이미 approval이 있었더라도 모델이 무엇을 할 수 있는지에 대해 더 엄격해 보일 때가 있었어요.

그게 좋을 때도 있고요.

짜증 날 때도 있어요.

하지만 분명 실제 user experience의 일부예요.

Codex 쪽에서 제가 진짜로 선호하는 작은 예 하나는, main flow를 끊지 않고 status와 limits를 볼 수 있다는 점입니다. 현재 작업이 끝날 때까지 기다리지 않고 /status를 칠 수 있다는 건 작은 차이 같지만, 19일 동안 쌓이면 그런 ergonomics의 차이가 꽤 커져요.

제가 두 도구가 output quality만 다른 게 아니라고 말하는 건 이런 뜻입니다. 둘은 harness의 감촉 자체도 달라요.

reliability는 여전히 중요하고, 4월은 Claude에 도움이 되지 않았어요

애초에 제가 이 전환을 시도할 만큼 편하게 느꼈던 이유 중 하나가 reliability였습니다.

저는 이미 3월 31일 follow-up에서 Anthropic과 OpenAI의 90일 status 차이에 대해 쓴 적이 있어요. 큰 그림은 지금도 중요합니다.

claude.ai, platform, API, Claude Code 전반의 partial outage를 보여 주는 Anthropic 90일 uptime status 이미지

API 99.99%, ChatGPT 99.91% uptime을 보여 주는 OpenAI 90일 system status 이미지

그리고 4월은 여기에 또 하나의 현실적인 reminder를 더했습니다.

4월 15일, Claude는 Claude.ai, API, Claude Code 전반에서 다시 elevated errors를 겪었어요. login에도 영향이 있었습니다. API가 먼저 회복됐고, 이미 로그인되어 있던 Claude Code user는 계속 일할 수 있었지만, login 자체는 한동안 깨져 있었어요.

이게 Claude의 강점을 지우는 건 아니에요.

하지만 workflow 전체를 한 vendor에만 걸지 말아야 한다는 실무적인 근거는 더 강하게 만들어 줍니다.

이건 여전히 이 experiment 전체에서 가장 durable한 교훈 중 하나예요.

dual-wielding은 사치가 아니라 operational resilience예요.

한 provider가 나쁜 오후를 보내도, 당신은 계속 ship할 수 있어요.

Opus 4.7은 패턴을 더 날카롭게 만들었지, 뒤집지는 않았어요

Claude Opus 4.7은 4월 16일에 나왔어요. 이걸 진지하게 돌려 보지 않고 honest verdict를 내리는 건 공정하지 않았을 겁니다.

그래서 저는 거의 바로 Prova의 실제 coding diagnostic에 붙였습니다.

Opus 4.7은 꽤 solid한 first pass를 줬어요. track bug, timing이 어긋난 Context Check card, 그리고 더 넓은 Builder-opener question을 잡아냈습니다.

그다음 저는 그 diagnosis를 GPT-5.4에 critique pass로 다시 돌렸어요. blind second opinion이 아니라, Opus가 쓴 분석을 읽는 reviewer처럼요. GPT-5.4는 Opus가 놓친 더 날카로운 contradiction을 잡았습니다. product는 이미 하나의 first sprint를 assign하고 있었는데, generated roadmap은 다른 곳에서 시작하고 있었거든요. 이건 단순한 Builder-fit 이슈가 아니라 live correctness problem이었어요.

그 revised diagnosis를 다시 Opus에 넣자, 그쪽에서는 수렴했습니다.

그런데 놀라움은 반대 방향에서 왔어요.

4월 19일, 저는 예상하지 못한 사실을 봤습니다. 더 단순한 task, 예를 들어 짧은 code review pass나 작은 변경에 대한 focused execution에서는 xHigh의 Opus 4.7이 xHigh의 Codex-GPT-5.4보다 눈에 띄게 느리다는 점이었어요. 저는 오히려 반대일 줄 알았거든요.

그 한 가지 디테일이 제 패턴을 다시 고정시켰습니다.

Opus가 여전히 분명히 이기는 지점은 위에서 말한 taste-heavy하고 iterative하며 long-context인 작업입니다. Codex가 분명히 이기는 지점은 deep coding diagnosis 예전 같으면 Claude를 불렀을 everyday coding turn입니다.

그래서 솔직한 버전은 이렇습니다.

  • Opus 4.7은 더 깊은 code analysis에서는 지금도 좋은 first pass를 줘요
  • 하지만 lighter coding turns에서는 지금 GPT-5.4보다 느리게 느껴진다
  • 그리고 4월 17일의 continuous execution experience와 합쳐져서, coding seat는 tie 쪽이 아니라 더 Codex 쪽으로 기울었다

제가 실제로 도착한 곳

drama, pricing screenshot, outage screenshot, social-post framing을 다 벗겨 내면, 4월 22일 기준 제 working pattern은 이렇게 정착했습니다.

code와 관련된 모든 일

저는 먼저 xHigh thinking의 Codex with GPT-5.4 를 집습니다.

이유는 이렇습니다.

  • specialized하게 느껴진다
  • methodical하다
  • careful하다
  • architecture와 execution을 모두 잘 다룬다
  • unit, integration, browser tests를 포함한 agreed plan을 30~45분 동안 계속 돌릴 수 있다
  • everyday coding turn에서는 지금 xHigh의 Opus 4.7보다 빠르다
  • deep coding work에서도 믿기가 쉬워졌다

그 외의 모든 일

저는 xHigh thinking의 Claude Code with Opus 4.7 을 집습니다.

여기에는 이제 이런 일들이 들어갑니다.

  • 제 목소리처럼 들려야 하는 writing
  • cover art용 image prompt
  • naming, positioning, brand language
  • visual judgment가 필요한 /frontend-design
  • 여러 session에 걸쳐 point of view를 쌓는 긴 research thread
  • Codex에 넘기기 전 제 own plan review
  • 이 blog post

이유는 이렇습니다.

  • 제 style을 더 잘 따라간다
  • feedback-driven creative iteration을 더 잘 다룬다
  • brand taste와 design taste가 더 강하다
  • 일이 execution이 아니라 judgment 일 때, 여전히 제가 가장 trust하는 model이다

중요한 coding plan에 대해서

저는 여전히 cross-review loop를 좋아합니다.

  • 한쪽에서 plan을 뽑고
  • 다른 쪽에 critique를 시키고
  • 거기서 다시 더 조입니다

이 workflow는 여전히, 아무리 좋은 model이라도 한 모델의 첫 답에만 거는 것보다 더 견고하게 느껴져요. 위에서 다룬 builder-intent row가 바로 그 이유입니다.

pricing에 대해서

저는 단순한 cheap switch로 끝나지 않았어요.

제가 도착한 곳은 여기입니다.

  • 예전의 월 200달러 Claude Max 구조 는 더는 원하지 않는다
  • 원하는 건 더 많은 Codex capacity 다, 더 적은 게 아니라
  • coding plan에 대한 더 현실적인 답으로 월 100달러의 ChatGPT Pro 를 받아들였다
  • 그리고 code가 아닌 일에는 Claude를 loop 안에 남겨 두고 있다

shipping에 대해서

이 전환의 핵심 목적은 계속 ship하는 것이었어요. 이건 아무 결과도 없이 19일 동안 tool benchmarking만 한 게 아니었습니다. 같은 기간에 Prova의 Operator/Builder split은 실제 Builder execution lane과 함께 live로 나갔고, substantial한 blog post 두 편이 나갔고, 저는 12 locale에 걸친 full translation pass도 돌렸습니다. 이 experiment가 제 output을 줄였느냐는 질문의 답은 아니요예요.

가장 압축해서 말하면 이렇습니다.

저는 Claude Max를 해지했지만, Claude Code를 제 일에서 제거하지는 않았어요. 다만 primary coding seat에서 빼고, 책상의 나머지를 맡겼습니다.

이게 제가 드릴 수 있는 가장 진실한 요약이에요.

그렇다면, 같은 결정을 다시 할까요?

네.

하지만 지금은 다르게 설명할 거예요.

4월 3일의 framing은 이랬습니다.

"Claude Max를 해지했고, Codex가 그걸 대체할 수 있는지 테스트하고 있다."

4월 22일의 framing은 오히려 이쪽에 가깝습니다.

"Claude Max를 해지했고, 지금 제게는 Codex가 더 강한 coding specialist라는 걸 확인했다. 그래서 이제 저는 Claude Code를 책상의 다른 모든 일에 쓰고 있다. 그 자리에서는 여전히 제가 가진 최고의 tool이다."

이 답은 덜 이분법적이고, 단순한 social-post 버전보다 더 비싸며, 훨씬 더 진실에 가깝습니다.

자주 받는 질문

Codex가 정말 coding에서 Claude를 대체했나요?

저에게는 네입니다. pure coding work에서는 xHigh thinking의 Codex with GPT-5.4가 default seat가 됐어요. xHigh의 Opus 4.7은 깊은 diagnosis에서는 지금도 유용한 first pass를 주지만, 저에게는 더 이상 primary coding seat가 아니고, lighter coding turn에서는 지금 Codex보다 느리게 느껴져요.

"저렴한 Codex" 이야기는 유지됐나요?

완전히는 아니에요. 실제 볼륨으로 쓰는 순간, low-tier economics만으로는 이야기가 다 설명되지 않았어요. 실험이 실패해서가 아니라, 더 많은 capacity가 필요해서 더 비싼 OpenAI plan으로 갔습니다.

그래도 Claude는 여전히 필요한가요?

네. writing, design, naming, image prompting, 긴 research thread, 또는 taste나 judgment가 많이 필요한 loop가 업무에 포함되어 있다면 필요해요. 지금 제 workflow에서 code가 아닌 모든 일의 default는 xHigh의 Opus 4.7입니다.

reliability는 어떤가요?

reliability gap은 여전히 중요합니다. 4월이 그걸 더 강화했어요. 답은 panic이 아니라 backup coverage입니다.

왜 11일 일찍 publish했나요?

패턴이 이미 settled됐기 때문이에요. 원래 headline의 숫자를 지키기 위해 5월 2일까지 붙들고 있는 건 연출이었을 거예요. 지금 제가 실제로 무엇을 하고 있는지 말하고 넘어가는 쪽이 더 솔직했어요.

그럼 오늘은 어떤 plan을 사겠어요?

일이 대부분 coding이라면, 저는 먼저 Codex / GPT-5.4를 아주 진지하게 볼 거예요. coding과 함께 taste-heavy한 creative work가 많다면, 저는 Claude 없이 가고 싶지 않을 거예요. 그리고 지금 월 100달러가 부담스럽다면, 20달러 Codex tier도 더 작은 개인 프로젝트에는 여전히 쓸 수 있어요. 다만 sustained한 multi-project work에서는 limits를 더 빨리 맞을 거라고 생각해야 합니다. 적어도 지금의 제 답은 single-tool answer가 아니에요.


이게 19일 후의 솔직한 update입니다.

Codex가 coding 자리를 가져갔어요.

Claude Code가 남은 모든 자리를 가져갔어요.

그래서 문자 그대로 Claude Code라는 이름의 tool이, 이제는 code 이외의 일을 맡기는 tool이 됐습니다.

그리고 진짜 lesson은, 다시 한번, fandom보다 workflow가 더 중요하다는 거예요.

이번 달에 비슷한 switch를 해 보셨다면, 어디에 도착했는지 정말 듣고 싶어요. 한 tool이 완전히 이겼나요, 아니면 여러분의 split도 더 선명해졌나요?

감사합니다,
Chandler

계속 읽기