코드가 싸졌는데 왜 더 어려워졌을까

어제 저녁에 사이드 프로젝트를 하나 만들고 있었어요. 간단한 대시보드 페이지인데요. 예전 같으면 하루는 잡았을 작업이에요. 레이아웃 잡고, 컴포넌트 만들고, API 연결하고, 반응형 처리하고. 근데 Claude Code한테 시켰더니 20분 만에 코드가 나왔어요.

코드가 나왔어요.

근데 그게 "좋은 코드"였느냐는 다른 문제였어요.

에러 처리가 빠져있었고, 로딩 상태가 없었고, 모바일에서 테이블이 깨졌고, 기존 유틸 함수를 안 쓰고 새로 만들어놨고, 테스트는 당연히 없었어요. "작동"은 했어요. 근데 프로덕션에 내보낼 수 있는 상태는 아니었죠.

20분 만에 500줄을 만들었는데, 그걸 "좋은 코드"로 만드는 데 2시간이 걸렸어요.

이 경험을 하고 나서 Simon Willison이 쓴 글을 읽었는데요. 이 사람이 정확히 같은 이야기를 하더라고요. 그리고 제가 몇 달째 뉴스레터를 쓰면서 따로따로 다뤘던 것들이 — CLAUDE.md, 테스트 분리, Plan Mode, 린팅 — 왜 필요한지를 하나의 프레임으로 묶어주는 글이었어요.

오늘은 그 이야기를 해보려고 합니다.

"코드를 짜는 비용"이 사라지고 있어요

소프트웨어 개발에서 가장 비싼 게 뭐였어요? 코드를 짜는 시간이었잖아요. 깨끗하고 테스트된 코드 수백 줄을 만드는 데 보통 하루 이상 걸렸어요. 우리가 알고 있는 개발 습관의 대부분은 이 전제 위에 세워진 거예요.

큰 그림에서 보면요. 왜 기획하고, 일정 추정하고, 프로젝트를 세세하게 계획하냐면 — 코딩 시간이 비싸니까. 그 비싼 시간을 최대한 효율적으로 쓰려고요. 새 기능을 추가할지 말지도 "이거 만드는 데 얼마나 걸려?"로 판단하잖아요. 개발 비용 대비 가치가 몇 배는 돼야 할 만하다고 느끼니까요.

작은 그림에서도 마찬가지예요. 하루에도 수십 번씩 이런 판단을 내리잖아요.

이 판단들의 공통점이 뭐예요? 전부 "시간이 얼마나 드느냐"를 기준으로 결정해요. 코드를 짜는 비용이 비싸니까, 그 비용 대비 이득을 따지는 거예요.

근데 이제 코딩 에이전트가 그 비용을 급격하게 떨어뜨렸어요. "코드를 타이핑해서 컴퓨터에 입력하는 비용"이 거의 공짜가 된 거예요.

이게 단순히 "빨라졌다"가 아니에요. 의사결정의 기준이 흔들리는 거예요. 지금까지 "시간 대비 가치"로 판단하던 수백 개의 일상적 결정들이 전부 재검토 대상이 된 거거든요.

"리팩터링에 1시간이 걸리니까 나중에 하자" → 에이전트가 5분에 하면? 지금 하는 게 맞죠. "테스트를 작성하면 하루가 걸리니까 나중에" → 에이전트가 30분에 하면? 지금 하는 게 맞죠. "문서를 쓸 시간이 없어" → 에이전트가 10분에 하면? 시간이 없다는 게 더 이상 변명이 안 돼요.

Simon Willison은 이걸 한 문장으로 정리해요.

그리고 병렬 에이전트를 쓰면 이 변화가 더 극적이에요. 한 사람이 동시에 구현하고, 리팩터링하고, 테스트하고, 문서화할 수 있으니까요. 제 이전 뉴스레터에서 "터미널 3개면 3명이다"라고 했잖아요. 이건 생산량만 늘어난 게 아니에요. "이걸 할 시간이 있나?"라는 질문 자체가 바뀐 거예요.

근데 "좋은 코드"는 여전히 비싸요

여기서부터가 중요해요. Simon Willison이 핵심적으로 구분하는 게 이거거든요.

코드를 만드는 비용 ≠ 좋은 코드를 만드는 비용

코드를 만드는 건 거의 공짜가 됐어요. 근데 좋은 코드를 만드는 건 여전히 비싸요. 그리고 그 간극이 문제예요.

Simon Willison이 말하는 "좋은 코드"가 뭐냐면요. 이게 꽤 구체적이에요.

첫째, 코드가 작동해야 해요. 해야 할 일을 버그 없이 하는 거요. 당연한 말 같지만, AI가 짠 코드는 "작동하는 것처럼 보이는" 경우가 많아요. 해피 패스에서는 잘 돌아가는데 엣지 케이스에서 터지거든요.

둘째, 코드가 작동한다는 걸 우리가 알아야 해요. 작동하는 것과 "작동한다고 확인한 것"은 다른 거예요. 테스트가 있어야 하고, 그 테스트가 진짜 의미 있는 것을 검증해야 해요.

셋째, 올바른 문제를 풀어야 해요. AI는 시키는 대로 잘 해요. 근데 시키는 것 자체가 잘못된 경우가 있잖아요. "이렇게 만들어줘"라고 했는데, 사실 그게 아니라 저렇게 만들어야 했던 거예요.

넷째, 에러를 우아하게 처리해야 해요. 해피 패스만 생각하면 안 돼요. 실패했을 때 미래의 유지보수자가 뭐가 잘못됐는지 알 수 있을 만큼의 정보를 제공해야 해요.

다섯째, 단순하고 최소한이어야 해요. 필요한 것만 있어야 하고, 사람이든 기계든 이해하고 유지보수할 수 있어야 해요.

여섯째, 테스트로 보호돼야 해요. 지금 작동한다는 걸 보여주는 것도 중요하지만, 미래에 조용히 깨지는 걸 방지하는 회귀 테스트도 있어야 해요.

일곱째, 적절한 수준의 문서가 있어야 해요. 그리고 코드가 기존 동작을 바꿨으면 기존 문서도 업데이트돼야 해요.

여덟째, 미래 변경을 수용할 수 있어야 해요. 근데 여기서 중요한 게 있어요. YAGNI를 지켜야 해요. "나중에 이게 필요할 것 같아서" 미리 복잡하게 만드는 건 대부분 나쁜 코드예요. 반대로, 미래 변경을 불필요하게 어렵게 만드는 것도 나쁜 코드고요.

아홉째, 관련된 모든 "-ility"예요. 접근성, 테스트 가능성, 신뢰성, 보안, 유지보수성, 관측 가능성, 확장성, 사용성. 만들고 있는 소프트웨어의 종류에 맞는 비기능적 품질 기준들이요.

이거 다 합치면요. 코딩 에이전트가 도울 수 있는 영역이긴 해요. 근데 그 도구를 운전하는 개발자한테 여전히 상당한 부담이 있어요. 만든 코드가 "지금 이 프로젝트에 필요한 수준의 좋은 코드"인지를 확인하는 부담이요.

제가 이 뉴스레터에서 다뤘던 것들이 전부 여기로 수렴해요

여기서 좀 개인적인 이야기를 해볼게요.

이 뉴스레터를 몇 주째 쓰면서 다양한 주제를 다뤘잖아요. CLAUDE.md, Plan Mode, Writer/Reviewer 패턴, 린팅, 하네스 엔지니어링, Compound Engineering, 시나리오 테스팅, 병렬 워크트리... 각각 다른 사람의 글을 다루면서, 각각의 실전 팁을 전달했어요.

근데 Simon Willison의 글을 읽고 나니까, 이것들이 전부 하나의 문제를 다른 각도에서 풀고 있었다는 게 보이더라고요.

그 문제가 뭐냐면요.

정리해보면 이래요.

"코드가 작동해야 한다" → 이전에 다뤘던 린팅, 타입체크, pre-commit hook이 여기에요. AI가 만든 코드가 최소한 문법적으로 맞는지를 자동으로 확인하는 거요. Anthropic이 "검증 수단을 줘라"라고 한 것도 여기고요.

"코드가 작동한다는 걸 알아야 한다" → Writer/Reviewer 패턴이 여기예요. 구현한 세션과 다른 세션에서 테스트를 작성하라고 했잖아요. StrongDM의 시나리오 테스팅도 여기고요. AI가 만든 코드를 AI한테 검증시키는 거예요.

"올바른 문제를 풀어야 한다" → Plan Mode, plan.md, Annotation Cycle이 여기예요. 코드를 짜기 전에 "뭘 만들지"를 확정하는 거잖아요. 지난번에 다뤘던 Boris Tane의 "계획 문서가 코드를 이긴다"가 정확히 이 문제를 다루는 거였어요.

"단순하고 최소한이어야 한다" → CLAUDE.md에 제약조건을 거는 것, "불필요한 코드 한 줄이 AI를 망친다"고 했던 것이 여기예요. 컨텍스트 윈도우가 AI의 RAM이라서, 프로젝트가 깔끔해야 AI가 더 좋은 코드를 만든다고 했잖아요.

"테스트로 보호돼야 한다" → 속성 기반 테스트, 테스트 파일 수정 금지 규칙이 여기예요. AI가 테스트를 "치팅"하는 문제를 다뤘었죠.

"미래 변경을 수용해야 한다" → Mitchell Hashimoto의 하네스 엔지니어링이 여기예요. CLAUDE.md에 실패 패턴을 축적하고, 에이전트가 실수하면 시스템으로 막는 거요. Compound Engineering의 "오늘의 삽질이 내일의 자산이 되게 하라"도 같은 맥락이고요.

이렇게 보니까 제가 지금까지 다뤘던 게 전부 "좋은 코드의 조건"을 AI 시대에 어떻게 충족시킬 것인가에 대한 답이었던 거예요. 각각 별개의 팁처럼 보였지만, 하나의 큰 그림 안에 있었어요.

이게 왜 중요하냐면요. 개별 팁을 외우는 것보다, 왜 그 팁이 필요한지를 이해하는 게 훨씬 강하거든요. "CLAUDE.md를 짧게 유지하라"는 팁을 외우면 CLAUDE.md만 짧게 유지해요. 근데 "AI가 만든 코드는 싸지만 좋은 코드는 여전히 비싸다"를 이해하면, CLAUDE.md뿐 아니라 모든 AI 코딩 상황에서 스스로 판단할 수 있게 돼요.

새로운 습관을 만들어야 해요

Simon Willison이 솔직하게 인정하는 부분이 있어요.

이게 좋은 자세인 것 같아요. "이렇게 하면 된다"고 확신 있게 말하는 사람들이 많은데, 솔직히 지금은 아무도 정답을 몰라요. 우리 모두가 실험 중인 거예요.

근데 Simon Willison이 하나 제안하는 게 있어요. "일단 시켜봐라"는 거예요.

이 말이 와닿는 이유가 있어요. 저도 아직 "이건 만들 가치가 없어"라는 판단을 예전 기준으로 내리거든요. "디버그 도구를 만들면 좋긴 한데... 시간이..." 이런 식으로요. 근데 에이전트한테 시키면 10분이면 되잖아요. 10분짜리 투자를 "시간이 없다"고 안 하는 건 합리적이지 않아요.

제가 이전 뉴스레터에서 Mitchell Hashimoto의 이야기를 다루면서 이런 말을 했어요. "내가 일하는 시간을 더 효율적으로 쓰려고 하지 말고, 내가 일 안 하는 시간에 AI가 일하게 하자." Simon Willison이 말하는 것도 같은 맥락이에요. "안 할 이유가 있었던 것들을 다시 생각해봐라. 그 이유가 '비용'이었다면, 그 비용이 사라졌을 수 있다."

이건 개인 수준만의 이야기가 아니에요. 조직 수준에서도 마찬가지예요.

"QA를 더 꼼꼼하게 하면 좋은데 인력이 부족해" → 에이전트가 테스트를 작성하면? "문서화를 잘 하고 싶은데 시간이 없어" → 에이전트가 문서를 작성하면? "코드 리뷰를 더 깊이 하고 싶은데 PR이 너무 많아" → 에이전트가 1차 리뷰를 하면?

이전에는 이런 것들이 "중요하지만 비싸서 못 하는 것"이었어요. 이제는 "중요하고, 싸졌으니까, 안 할 이유가 없는 것"이 됐어요.

근데 함정이 있어요

여기서 제 경험을 좀 더 솔직하게 이야기해야 할 것 같아요.

"코드를 짜는 게 싸졌다"는 말이 사실이에요. 근데 이게 가끔 잘못된 방향으로 작용하거든요.

코드가 싸지니까 코드를 너무 많이 만들게 돼요. 예전에는 "이 기능, 진짜 필요해?"를 심각하게 고민했잖아요. 만드는 데 3일 걸리니까요. 근데 이제 에이전트한테 시키면 30분이면 되니까, "일단 만들어보지 뭐" 하게 돼요.

문제는 뭐냐면요. 코드는 만드는 것보다 유지하는 게 비싸요. 이건 AI 시대에도 변하지 않았어요. 아니, 오히려 더 심해졌을 수도 있어요. AI가 빠르게 만들어낸 코드가 쌓이면 코드베이스가 비대해지잖아요. 비대한 코드베이스는 AI의 컨텍스트 윈도우를 잡아먹어요. 그러면 AI의 성능이 떨어져요. 성능이 떨어지니까 더 많은 코드를 만들어서 보완하려 하고. 악순환이에요.

이전 뉴스레터에서 "AI가 짠 코드를 믿지 마라"를 다루면서 한 말이 있어요. 40년 경력 개발자가 Hacker News에서 이렇게 말했다고요.

이 사람이 하는 건 뭐예요? AI를 "더 많은 코드를 짜는 데" 쓰는 게 아니라 "더 좋은 코드를 만드는 데" 쓰는 거예요. 코드를 더 만드는 게 아니라, 있는 코드를 더 깨끗하게 만드는 거예요.

Simon Willison의 프레임을 빌리면 이렇게 정리돼요.

마지막 줄이 핵심이에요. 예전에는 비용이 자연스럽게 필터 역할을 했어요. 만드는 데 3일 걸리니까 "진짜 필요한 건가?"를 자동으로 묻게 됐죠. 이제 그 자연 필터가 사라졌어요. "진짜 필요한 건가?"를 의식적으로 물어야 해요. 안 그러면 코드가 불어나요.

이전 뉴스레터에서 Every 팀의 Compound Engineering을 다루면서 "코드가 주요 산출물이 아니다"라는 주장을 소개했잖아요. 코드를 생산하는 시스템이 개별 코드보다 가치 있다는 거요. Simon Willison의 글과 맞닿는 지점이 여기예요. 코드 자체가 싸졌으니까, 코드의 양이 아니라 코드의 질이 차별화 포인트가 된 거예요.

실전에서 달라지는 판단들

추상적인 이야기를 많이 했으니, 구체적으로 뭐가 달라지는지 정리해볼게요. 제가 실제로 판단을 바꾼 것들이에요.

"그거 나중에 하자"가 사라졌어요

예전에 코드를 짜다가 "여기 리팩터링하면 좋겠는데, 지금은 시간이 없으니 나중에"라고 생각한 적 많잖아요. 그리고 그 "나중에"는 대부분 안 와요. TODO 주석만 남기고 넘어가죠.

이제는 바로 해요. 에이전트한테 "이 함수를 더 깔끔하게 리팩터링해줘"라고 하면 5분이면 돼요. 심지어 별도의 워크트리에서 병렬로 돌릴 수 있으니까, 본 작업을 중단할 필요도 없어요.

근데 여기서 중요한 게 있어요. 리팩터링의 결과물도 검증해야 해요. "리팩터링해줘"라고 시키고 그 결과를 그대로 커밋하면, 기존에 잘 돌아가던 게 깨질 수 있어요. 그래서 리팩터링을 시킨 후에 테스트를 돌리고, diff를 확인하는 과정은 여전히 필요해요. "코드를 짜는 건 싸지만, 좋은 코드로 만드는 건 여전히 비싸다"가 여기서도 적용돼요.

테스트를 안 쓸 이유가 없어졌어요

이건 진짜 큰 변화예요. 예전에는 테스트를 안 쓰는 가장 큰 이유가 "시간이 없어서"였거든요. 기능 만드는 것도 바빠 죽겠는데 테스트까지 쓰라고?

이제 에이전트한테 "이 모듈의 테스트를 작성해줘"라고 하면 돼요. 물론 이전 뉴스레터에서 다뤘듯이 AI가 짠 테스트를 그대로 믿으면 안 돼요. AI가 치팅할 수 있으니까요. 근데 시작점으로는 충분해요. AI가 만든 테스트를 리뷰하고, 부족한 엣지 케이스를 추가하는 건 처음부터 테스트를 짜는 것보다 훨씬 빨라요.

Simon Willison도 이걸 "좋은 코드의 조건" 중 하나로 꼽아요. "테스트로 보호돼야 한다." 그리고 코드를 짜는 비용이 떨어졌으니까, 테스트를 짜는 비용도 떨어진 거예요. 더 이상 "시간이 없어서"가 변명이 안 돼요.

문서화가 선택이 아니라 기본이 됐어요

이것도 비슷한 맥락이에요. 예전에는 문서화가 "시간이 남으면 하는 것"이었잖아요. Confluence에 열심히 써놔도 6개월 후에 아무도 업데이트 안 하고.

이전 뉴스레터에서 이 이야기를 했어요. "AI는 문서를 다 읽는다." 사람은 안 읽어도 AI는 읽어요. CLAUDE.md에 쓴 한 줄, 코드에 달아놓은 주석 한 줄, 설계 문서의 제약조건 한 줄. AI는 이걸 전부 읽고 코드에 반영하거든요. 문서화의 ROI가 근본적으로 달라진 거예요.

근데 Simon Willison이 한 가지 더 짚는 게 있어요. "코드가 기존 동작을 바꿨으면 기존 문서도 업데이트돼야 한다." 이거 중요해요. AI가 기능을 바꿨는데 README는 옛날 그대로면, 다음에 AI가 그 README를 읽고 옛날 방식대로 코드를 짤 수 있거든요. 문서가 코드와 동기화되지 않으면 오히려 독이 돼요.

이건 실전 팁으로 바로 적용할 수 있어요. CLAUDE.md에 이렇게 넣으세요:

- 기존 동작을 변경하면, 관련 문서(README, 주석 등)도 함께 업데이트하라

이 한 줄이면 AI가 코드를 바꿀 때 관련 문서도 같이 업데이트해요.

"이거 만들 가치가 있나?"를 더 자주 물어야 해요

이건 반대 방향의 변화예요. 위에서 "리팩터링, 테스트, 문서화를 더 많이 하라"고 했잖아요. 근데 동시에 "새로운 코드를 만드는 건 더 신중해야 한다"는 거예요.

모순처럼 들릴 수 있는데, 논리는 이래요.

에이전트한테 "이 기능 만들어줘"라고 하면 20분 만에 나와요. 근데 그 기능이 코드베이스에 추가되면, 앞으로 유지보수해야 할 코드가 늘어나는 거예요. 만드는 건 싸지만 유지하는 건 비싸요. 이전에는 비용이 자연 필터 역할을 해서 "진짜 필요한 것만" 만들게 됐는데, 이제 그 필터가 사라졌으니 의식적으로 물어봐야 해요. "이거 진짜 필요해?"

솔직히 이렇게 느꼈습니다

Simon Willison의 글이 기술적으로 새로운 걸 알려주진 않아요. 새로운 도구도 없고, 새로운 프롬프트 기법도 없고, 새로운 워크플로우도 없어요.

근데 이 글이 가치 있는 이유는요. "왜"를 설명해주기 때문이에요.

저도 뉴스레터를 쓰면서 "이렇게 하세요"를 많이 말했어요. CLAUDE.md를 짧게 유지하세요. Writer/Reviewer 패턴을 쓰세요. 린팅을 자동화하세요. Plan Mode를 쓰세요. 근데 "왜요?"에 대한 통합된 답을 제대로 못 했던 것 같아요.

Simon Willison의 프레임이 그 답이에요. "코드를 짜는 건 싸졌지만, 좋은 코드를 만드는 건 여전히 비싸다. 우리가 하는 모든 실천은 그 간극을 메우기 위한 거다."

CLAUDE.md를 짧게 유지하는 이유? AI가 좋은 코드를 짜게 하려면 깔끔한 컨텍스트가 필요하니까. Writer/Reviewer 패턴을 쓰는 이유? "코드가 작동한다는 걸 아는 것"이 좋은 코드의 조건이니까. Plan Mode를 쓰는 이유? "올바른 문제를 풀고 있는지" 확인하는 게 좋은 코드의 조건이니까. 린팅을 자동화하는 이유? "단순하고 최소한인 코드"를 유지하는 게 좋은 코드의 조건이니까.

전부 "좋은 코드의 조건"을 충족시키기 위한 수단이었던 거예요.

그리고 하나 더 솔직하게 말할게요. Simon Willison이 "이 습관들은 아직 만들어가는 중이다. 나도 아직 답을 찾고 있다"고 한 부분이 좋았어요. AI 코딩에 대해 확신에 찬 목소리가 많잖아요. "이렇게 하면 된다!" "이게 정답이다!" 근데 솔직히 지금은 아무도 정답을 몰라요. 저도 몰라요. 다들 실험하고 있는 거예요. 그 솔직함이 오히려 신뢰가 가요.

오늘 바로 해보세요

1. "안 할 이유" 리스트를 다시 보세요 (5분)

지금 프로젝트에서 "하면 좋은데 시간이 없어서 안 하는 것" 리스트가 있을 거예요. 머릿속에든 TODO 주석에든. 그 중에서 AI 에이전트한테 시킬 수 있는 것을 골라보세요.

이것 중 하나를 에이전트한테 시켜보세요. 안 되면 토큰 좀 쓴 거고, 되면 그동안 미뤘던 빚을 갚는 거예요.

2. CLAUDE.md에 문서 동기화 규칙 추가하기 (1분)

- 기존 동작을 변경하면, 관련 문서(README, 주석, 인라인 설명)도 함께 업데이트하라
- 새 함수를 추가하면, 해당 모듈의 문서에 반영하라

이거 두 줄이면 돼요. AI가 코드를 바꿀 때 문서도 같이 바뀌게 하는 거예요.

3. "이거 진짜 필요해?" 질문을 습관으로 만드세요 (0분)

비용이 아니에요. 습관이에요. 에이전트한테 새 기능을 시키기 전에 3초만 멈추고 물어보세요.

만드는 건 싸요. 근데 만든 걸 유지하는 건 싸지지 않았어요.

마무리

Simon Willison의 글은 짧아요. 기술적 팁이 없어요. 프롬프트 기법도 없고, 워크플로우도 없어요. 근데 제가 최근에 읽은 AI 코딩 관련 글 중에 가장 오래 생각하게 만든 글이에요.

왜냐하면 이 글이 던지는 질문이 근본적이거든요.

제 답은요. "좋은 코드를 만드는 사람"이에요. 코드를 짜는 건 에이전트가 해요. 그 코드가 작동하는지, 올바른 문제를 풀고 있는지, 테스트로 보호되는지, 미래 변경을 수용하는지 — 이걸 판단하고 보장하는 게 개발자의 일이에요.

제 강의에서도 "코드를 치지 마라 — 설계하고, 시키고, 검증하라"를 핵심 메시지로 다루는데요. Simon Willison의 글이 그 메시지에 이론적 뼈대를 입혀주는 느낌이에요. 코드를 치는 비용이 사라졌으니, 설계하고 검증하는 데 더 많은 시간을 쓰는 게 합리적이다. 이건 감이 아니라 경제학이에요.

레퍼런스

매주 바이브 코딩 실전 인사이트를 보내드립니다.

Claude Code로 진짜 제품을 만드는 법이 궁금하시면,

👉 에피코딩 강의 보러 가기 (https://effycoding.pages.dev)

이 뉴스레터가 도움이 됐다면, 동료 개발자에게 공유해주세요.