일하는 ai

47. AI한테 코드 맡기면 점점 이상해지는

13 min read

-

이 영상은 code is cheap라는 말이 AI 시대에도 정말 맞는지 다시 묻습니다. 메이커 에반의 결론은 꽤 선명해요. 코드는 싸진 게 아니라, 오히려 나쁜 코드가 훨씬 더 비싸졌고, AI를 잘 쓰려면 코드베이스를 좋게 유지하는 원칙부터 다시 세워야 한다는 쪽입니다.

flowchart LR
A[AI에게 코드 맡기기] --> B[소프트웨어 엔트로피 증가]
B --> C[실패 패턴 분석]
C --> D[DDD·TDD·규칙성으로 코드베이스 개선]

핵심 요약

  • 스펙을 글로 쓰면 AI가 코드로 바꿔주고, 문제 생기면 스펙만 고치면 된다는 spec-to-code 흐름은 매력적이지만, 반복할수록 코드가 점점 이상해지는 함정이 있다고 말한다
  • 그 이유는 AI가 눈앞의 변경에만 집중하고 전체 시스템 디자인을 보지 않기 때문이며, 메이커 에반은 이를 소프트웨어 엔트로피로 설명한다
  • 좋은 코드베이스는 바꾸기 쉬운 코드베이스이고, 나쁜 코드베이스는 바꾸기 어려운 코드베이스라는 정의를 중심축으로 둔다
  • 해결 원칙으로는 공유된 디자인 컨셉, 도메인 주도 개발 DDD, 테스트 주도 개발 TDD, 그리고 규칙성 있는 코드베이스 유지가 제시된다
  • 실전 루틴은 프로젝트 분석, 핵심 용어 마크다운 정리, TDD로 한 번 개발해 보기, 스킬로 규칙성 유지하기 순서로 정리된다

왜 지금 중요한가

AI 코딩 도구가 빨라질수록 오히려 코드베이스 품질 차이가 더 크게 드러납니다. 좋은 구조에서는 AI가 강한 병사처럼 잘 움직이지만, 나쁜 구조에서는 망가진 부분을 더 빠르게 증폭시키거든요. 개발자나 PM 입장에서도 이제는 기능 추가 속도보다, AI가 계속 일해도 무너지지 않는 코드 환경을 만드는 쪽이 더 중요해졌다는 얘기입니다.

주요 내용

spec-to-code는 멋있지만, 반복할수록 엔트로피가 쌓인다

영상 초반에 메이커 에반은 요즘 자주 듣는 말로 코드는 싸다를 꺼냅니다. 그런데 AI 시대를 겪으면서 생각이 바뀌었다고 말해요. 어떤 코드는 오히려 그 어느 때보다 비싸졌다는 거죠.

예시로 드는 게 spec-to-code 흐름입니다. 스펙을 글로 쓰고, AI가 코드를 만들고, 문제가 생기면 코드가 아니라 스펙만 고치고 다시 LM을 돌리면 끝이라는 식의 접근이죠. 처음에는 꽤 그럴듯합니다. 첫 번째 결과물은 그냥저냥 괜찮네 싶고, 두 번째도 버틸 만한데, 세 번째쯤 가면 진짜 이상한 코드가 나오기 시작한다고 말합니다.

메이커 에반도 처음에는 코드를 안 보려고 했다고 해요. 그런데 결국 보게 됐고, 보니까 코드가 점점 쓰레기가 되고 있었다는 거죠. 이걸 소프트웨어 엔트로피라고 설명합니다. 부분 수정만 반복하면 전체 시스템 디자인은 무너지고, AI와 일할 때 정확히 그 일이 벌어진다는 겁니다.

실패 패턴 1과 2는 결국 소통 문제다

첫 번째 실패 패턴은 머릿속에는 분명한 그림이 있는데 AI가 완전히 다른 결과를 만드는 경우입니다. 길게 더 자세히 써도 해결이 안 됐고, 결국 이건 소통 문제라고 정리합니다.

여기서 메이커 에반은 보이지 않는 만들 것에 대해 공유된 이론이라는 표현을 씁니다. 사람끼리 협업할 때도 머릿속에 떠다니는 디자인 컨셉이 있는데, 그건 마크다운 파일 몇 줄로 다 담기지 않는다는 거죠. AI와 사람 사이에는 이 컨셉이 공유되지 않기 때문에, 먼저 공유된 디자인 컨셉을 만들어야 한다고 말합니다.

두 번째 실패 패턴은 AI가 같은 얘기를 너무 많은 단어로 하고, 서로 다른 언어를 쓰는 느낌이 드는 경우입니다. 이건 도메인 전문가와 개발자가 어긋나는 상황과 똑같다고 설명해요. 그래서 답으로 DDD, 도메인 주도 설계를 꺼냅니다.

실제 루틴도 구체적입니다. 도메인이 정의된 파일을 먼저 만들어 두고, 코드도 DDD 기반으로 짠 뒤 AI에게 일을 시킨다고 해요. 그러면 AI가 훨씬 덜 장황하고, 더 정확하게, 처음 계획과 일치하는 구현을 만든다고 말합니다.

실패 패턴 3은 피드백 루프, 그중에서도 TDD가 핵심이다

세 번째 실패 패턴은 AI가 원하는 걸 다 만들었다고 하는데 실제로는 작동하지 않는 경우입니다. 여기서 메이커 에반은 답이 뻔하다고 말합니다. 정적 타입, 브라우저 접근 권한, 자동화된 테스트 같은 피드백 루프가 필요하다는 거죠.

문제는 AI가 이 피드백 루프를 잘 세우지 못한다는 데 있습니다. 한 번에 너무 많은 걸 해 버리고, 거대한 코드를 짠 다음 뒤늦게 테스트를 돌리려 하니 결과가 엉망이 되기 쉽다고 설명합니다. 그래서 TDD, 테스트 주도 개발이 필요하다고 말해요.

테스트를 먼저 쓰고, 그 테스트를 통과하는 코드를 만들고, 그다음에 정리하는 흐름으로 가면 AI도 억지로 작은 단위로 일하게 됩니다. 조금 만들고 검증하고, 다시 조금 만들고 검증하는 식이죠. 메이커 에반은 이 방식이 오히려 더 빠르다고 말합니다. 중간에 큰 실수를 줄이기 때문입니다.

재밌는 건 테스트 자체도 결국 코드베이스 품질과 연결된다는 지점입니다. 테스트 유닛을 얼마나 크게 잡을지, 무엇을 mock할지, 어떤 동작을 테스트할지 모두 연결돼 있기 때문에, 결국 좋은 코드베이스는 테스트하기 좋은 코드베이스라고 정리합니다.

실패 패턴 4는 규칙성 없는 코드베이스다

네 번째 실패 패턴은 AI가 기능을 만들긴 했는데, 규칙성 없는 코드 때문에 전체 기능이 제대로 동작하지 않는 경우입니다. 메이커 에반은 이걸 코드베이스 구조 문제라고 봅니다.

규칙성 없이 작성된 코드에서는 사람도 AI도 모든 정보를 머리에 다 넣어야 하죠. 어떤 함수가 다른 함수를 부르고, 그 함수가 또 어디를 부르는지 계속 추적하다 보면 컨텍스트가 터져 버린다고 말합니다. 그래서 규칙성 있는 코드를 짜야 하고, 그 규칙을 계속 지키도록 유도해야 한다는 거죠.

여기서 리팩토링이 꼭 필요하다고 강조합니다. 본인의 경우 개발이 완료된 뒤에는 항상 스킬로 코드 가이드를 지키는지 확인한다고 말합니다. 즉, 한 번 잘 짜는 것보다 계속 같은 규칙을 유지하게 만드는 운영 루틴이 중요하다는 뜻입니다.

원문 발화 하이라이트

  • [00:07] “지금 AI 시대에 어떤 코드는 오히려 그 어느 때보다 비싸졌습니다.”
  • [01:15] “AI는 눈앞에 변경에만 집중하거든요. 전체 시스템 디자인은 신경을 안 써요.”
  • [01:45] “코드는 싸다가 아니라 나쁜 코드는 그 어느 때보다 비싸다고요.”
  • [03:09] “저는 개발을 할 때 도메인이 정의된 파일을 만들어 두고 코드도 DDD 기반으로 짠 뒤에 AI에게 일을 시킵니다.”
  • [03:55] “답은 TDD입니다. 테스트 주도 개발이에요.”
  • [06:20] “그 위에서 전략적으로 생각하는 사람이 필요하거든요. 큰 그림을 보고 디자인을 결정하고 방향을 잡는 사람이에요.”

바로 실행해 보기

  • 지금 작업 중인 프로젝트 하나를 골라서 먼저 AI에게 코드베이스 분석을 시켜 보세요. 어떤 구조인지, 어떤 특징이 있는지, 어디가 불안한지 끈질기게 다시 물어보는 게 영상의 첫 실전 단계였습니다
  • 팀이나 프로젝트에서 자주 쓰는 핵심 용어를 마크다운 파일 하나로 정리해 보세요. 도메인 개념, 객체 이름, 상태 이름을 먼저 맞춰 두면 AI가 훨씬 덜 장황하고 더 정확하게 움직인다는 게 이 영상의 DDD 포인트였습니다
  • 다음 기능 하나는 꼭 TDD로 시도해 보세요. 테스트를 먼저 쓰고, 통과하는 코드만 만들고, 그다음 정리하는 흐름으로 한 번만 해 봐도 AI가 큰 덩어리 대신 작은 검증 단위로 움직이기 시작하는 걸 체감할 수 있습니다

참고

영상 메타

수집 품질

  • 자막 세그먼트: 208개
  • 자막 문자수: 3769자
  • 챕터 추출: 8개
  • 콘텐츠 생성: Subagent 기반

AI 생성 도구를 활용해 초안을 구성했고, 원영상 발화와 공개 자료를 교차 확인해 정리했습니다.

그래프 뷰

백링크