이 글은 [조쉬의 뉴스레터]에서 발행되었습니다.

퀄리티 있는 프로덕트, 창업가, 비즈니스 이야기를 매주 구독해보세요. 
구독 시 100개의 1인 창업 케이스 스터디가 발송됩니다.

[구독하러 가기]

코파일럿, 커서, 클로드 코드 등등. AI 코딩 도구가 개발 속도를 혁명적으로 바꿔놓고 있어요. 며칠 걸리던 작업이 몇 시간으로 줄었고, 몇 년간 손도 못 대던 리팩토링이 드디어 진행되고 있죠.

그런데 시스템이 실패했을 때, 우리가 그 코드를 디버깅할 수 있을까요?

이 질문과 씨름해온 넷플릭스 시니어 엔지니어의 이야기를 들어봤습니다.

"우리는 이제 이해하지 못하는 코드를 배포하고 있습니다"

Q. 먼저 간단한 자기소개 부탁드려요.

저는 넷플릭스에서 AI 도구 도입을 주도하고 있어요. 코파일럿, 커서, 클로드 같은 도구들을 실제 서비스에 어떻게 적용할 수 있는지 연구하는 일을 하죠.

Q. 강연을 고백으로 시작하셨는데요. 이해하지 못하는 코드를 배포한 적이 있다고요.

네, 솔직히 말씀드릴게요.

AI가 만든 코드를 테스트하고 배포했는데, 그게 어떻게 돌아가는지 설명을 못 하겠더라고요.

근데 저만 그런 게 아니에요. 요즘 개발자들 대부분이 비슷한 경험을 하고 있을 거예요.

Q. AI 도구를 쓰고 난 후로 생산성이 얼마나 올랐나요?

확실히 빨라졌어요.

예전에 며칠 걸리던 일이 몇 시간이면 끝나요. 몇 년째 "언젠가 해야지" 하던 리팩토링도 이제 진짜 손대고 있고요.

속도 면에서는 혁명이에요.

Q. 그런데 문제가 있다는 거죠?

네. 큰 시스템은 예상 못 한 방식으로 터질 수 있어요.

최근 클라우드플레어 장애 보셨죠? 이처럼 예상치 못한 문제가 생기면 우선 코드를 뜯어봐야 하는데, 이해를 못 한 상황에서는 손을 댈 수가 없어요. 근데 지금은 코드가 너무 빨리 쌓이고 있어서 미처 다 이해할 수가 없는 경우가 많죠.

저도 그런 상황을 겪어봤어요.

AI가 만든 코드 보면서 '이게 뭐 하는 거지?' 싶을 때가 있었는데, 테스트 통과하고 돌아가니까 그냥 배포했거든요.

Q. 이런 문제가 처음인가요? 예전에도 비슷한 일이 있었나요?

아니요. 소프트웨어가 발달할 때마다 개발자들이 "이제 너무 복잡해서 못 하겠다" 하는 시점이 있었어요. 

우리만 겪는 게 아니에요. 다만 이렇게 빠른 속도를 겪는 건 우리가 처음이에요.

1960년대 후반에 컴퓨터 과학자들이 모여서 "소프트웨어 위기"를 선언했어요. 수요는 폭발하는데 우리가 못 따라간다고요.

다익스트라라는 유명한 학자가 이런 말을 했어요. "컴퓨터가 몇 대 없을 땐 프로그래밍이 별일 아니었다. 그런데 컴퓨터가 강력해지니까 프로그래밍도 엄청 어려워졌다." 하드웨어가 천 배 좋아지니까, 사람들이 원하는 소프트웨어도 천 배 복잡해졌어요.

그 뒤로 70년대에 C 언어, 80년대에 PC, 90년대에 자바, 2000년대에 애자일, 2010년대에 클라우드가 나왔어요.

그리고 지금, AI가 등장했죠. 

코파일럿, 커서, 클로드, 코덱스, 제미나이까지. 이제 코드를 말로 설명하는 속도로 생성할 수 있어요. 

패턴은 같은데, 규모가 달라요. 이제는 무한대예요.

Q. 도구는 계속 좋아졌잖아요. C 언어, 자바, 클라우드, AI까지. 근데 왜 복잡성 문제는 해결되지 않을까요?

진짜 어려운 부분은 그게 아니었거든요.

프레드 브룩스라는 학자가 1986년에 "은탄환은 없다"라는 논문을 썼어요. 은탄환은 늑대인간을 한 방에 죽이는 총알인데, 소프트웨어에는 그런 게 없다는 거예요. 생산성을 한 번에 10배 올려줄 마법 같은 건 없다고요.

어려운 건 타이핑이 아니거든요. 문법 맞추고 코드 치는 건 기계적인 일이에요.

진짜 어려운 건 "뭘 만들지?", "어떻게 설계하지?" 이런 물음들이에요.

이 문제는 도구가 아무리 좋아져도 똑같이 어려워요.

Q. 그런데 현실에서는 어떻게 만드는지에 대한 설계보다 어떤 도구를 쓰느냐에 대한 얘기가 더 많잖아요. 왜 그럴까요?

왜냐하면 설계하는 건 어렵고, 도구를 사용하는 건 쉬우니까요. 

근데 여기서 "쉽다"는 게 뭔지 생각해볼 필요가 있어요. 

"단순함"이랑 "쉬움"은 완전히 다른 개념이거든요.

클로저라는 프로그래밍 언어를 만든 리치 히키라는 개발자가 이 차이를 잘 설명한 적이 있어요.

"단순함"은 얽힌 게 없는 거예요. 각 부분이 딱 하나의 일만 하고, 다른 것과 안 엮여 있는 거죠.

"쉬움"은 손에 잡히는 거예요. 복사해서 붙여넣으면 바로 돌아가는 거요.

단순함은 구조의 문제고, 쉬움은 접근성의 문제예요.

Q.  단순함과 쉬움을 구분해야 한다는 게 흥미롭네요. 실무를 할 때에도 이러한 구분이 중요한가요?

엄청 중요해요. 

단순하게 만들려면 머리를 써야 하거든요. 설계하고, 고민하고, 얽힌 걸 풀어야 해요.

근데 쉽게 만드는 건 금방이에요. 패키지 설치하고, AI한테 시키고, 스택오버플로우에서 복사하면 끝이니까요.

사람은 당연히 쉬운 길을 택해요. 검색해서 복사? 3초면 돼요. 프레임워크 설치? 한 줄이면 끝이죠. 근데 쉽다고 단순한 건 아니에요.

쉬움은 "빨리 뭔가 추가할 수 있다"는 뜻이고, 단순함은 "내가 만든 걸 이해할 수 있다"는 뜻이에요.

Q. 그렇다면 계속 쉬운 길을 선택하면 어떻게 되나요?

쉬운 길을 택할 때마다, 지금 당장의 속도와 함께 나중에 올 복잡성을 쌓는 거예요. 

솔직히 말해서 예전에는 이 방법이 꽤 잘 먹혔어요. 복잡성이 천천히 쌓이면서, 필요할 때 리팩토링하고 정리할 시간이 있었거든요.

하지만 지금은 AI가 그 균형을 깨뜨려버렸어요. AI는 궁극의 "쉬운 길" 버튼이거든요. 

너무 쉬우니까 "잠깐, 이게 맞나?" 생각할 틈이 없어요. 코드가 바로 나오는데 왜 설계를 고민하겠어요?

Q. 실제로 그런 상황을 겪어보신 적이 있나요?

물론이죠. 이건 하나의 예지만 개발자라면 누구나 겪을 수 있는 상황이에요.

앱에 로그인을 추가하고 싶어요. AI한테 "구글 로그인 추가해줘" 하면 깔끔한 코드가 나와요. "카카오도 추가해줘" 하면 또 나오고요.

몇 번 반복하면 세션이 꼬이고 에러가 터져요. 20번쯤 대화하면 더 이상 토론이 아니에요. 나도 기억 못 하는 조건들이 얽혀서 그냥 맥락 관리하고 있는 거죠.

중간에 버린 코드, 대충 만든 테스트, 여러 가지 다른 방식의 잔해가 섞여 있어요. "아, 잠깐만, 그게 아니라..." 하면서 바꿨으니까요.

"로그인 되게 해줘" 하면 해요. "에러 고쳐줘" 하면 고쳐요.

AI는 "이 설계 별로인데요" 같은 말 안 해요. 시키는 대로 만들 뿐이에요.

AI한테 뭔가 시킬 때마다 단순함 대신 쉬운 길을 선택하는 거예요. 그리고 쉬운 길을 선택할수록 복잡성은 계속 쌓이는 거죠.

Q. 그걸 알면서도 멈추기 어려운 건가요?

그렇죠. 머리로는 알아요. 이렇게 반복되면 언젠가 문제가 생길 거라는 걸. 

근데 AI가 너무 빨리 답을 주니까, 고민하기 전에 일단 시켜보게 돼요. 안 되면 또 시키고, 또 시키고. 그러다 보면 복잡성이 쌓여있는데 언제 쌓였는지도 몰라요.

문제는 AI가 코드베이스를 볼 때 모든 걸 똑같이 취급한다는 거예요. 잘 짠 코드나 5년 전에 급하게 때운 코드나 다 똑같은 "패턴"이에요.

AI에게는 기술 부채가 부채로 안 보여요. 그냥 더 많은 코드일 뿐이에요.

Q. AI는 잘 짠 코드와 급하게 때운 코드를 똑같이 본다고 하셨는데요. 그러면 구체적으로 어떤 문제가 생기나요?

복잡성이 걷잡을 수 없이 커져요. 

복잡성은 코드가 얽힌 거거든요. 뭔가 복잡하면 하나 건드렸는데 열 개가 같이 움직여요.

아까 말한 프레드 브룩스 얘기를 다시 할게요. 그는 복잡성을 두 가지로 나눴어요.

첫째는 본질적 복잡성. 풀려는 문제 자체가 어려운 거예요. 결제를 처리하고, 주문을 관리하고. 소프트웨어가 존재하는 이유에서 오는 복잡성이에요.

둘째는 우발적 복잡성. 문제를 풀기 위해 우리가 덧붙인 것들이에요. 임시 우회로, 방어 코드, 예전에는 말이 됐던 구조들. 코드를 돌아가게 만들려고 조립한 것들이죠.

실제 코드에서는 이 둘이 뒤섞여 있어요. 

뭐가 진짜 필요한 거고 뭐가 덧붙인 건지 구분하려면 맥락을 알아야 해요. 

AI는 이걸 구분 못 해요. 전부 다 살려야 하는 코드로 봐요.

Q. 넷플릭스에서도 이런 문제를 경험하신 적이 있나요?

네. 제가 작업하던 시스템에 중간 다리 같은 게 있었어요. 5년 전에 만든 인가 코드랑 새 인증 시스템 사이를 연결하는 거였죠. 전체를 다시 짤 시간이 없어서 임시로 만든 거예요.

비유하자면, 오래된 아파트 전기 배선에 스마트홈을 연결하고 싶은데, 전체를 뜯을 순 없으니까 중간에 변환 장치를 끼워 넣은 거예요. 돌아가긴 하는데 내부는 복잡해요.

AI가 있으니까 이걸 깔끔하게 정리할 기회라고 생각했어요. 간단해 보이잖아요?

아니었어요. 전기 배선이 수도관이랑 엮여있고, 가스관이랑도 연결돼 있고, 인터넷 선까지 묶여있는 상황이었어요. 하나 바꾸려면 전부 건드려야 하는 거죠. 인증 코드가 수백 개 파일에 흩어져 있었어요.

AI한테 리팩토링을 시켜봤어요. 처음 몇 개 파일은 잘 처리했는데, 어느 순간 꼬이기 시작하더니 결국 포기했어요.그리고 더 나쁜 경우도 있었죠. 기존 코드는 그대로 두고 그 위에 새 코드를 덧씌우는 거예요.

정리하려고 시킨 건데 오히려 더 복잡해진 거죠.

Q. AI는 왜 이 문제를 풀지 못한 걸까요?

AI는 경계를 볼 수 없어요. 비즈니스 로직이 어디서 끝나고 인증 로직이 어디서 시작하는지 구분을 못하는 거죠. 모든 게 너무 얽혀있어서, 완벽한 정보가 있어도 깔끔한 경로를 못 찾아요.

우발적 복잡성이 이렇게 얽히면, AI가 더 좋게 만들어주지 않아요. 그냥 위에 레이어를 더 추가할 뿐이에요.

하지만 우리는 구분할 수 있어요. 생각할 시간만 있으면요.

뭐가 진짜 필요한 거고 뭐가 옛날에 누가 급하게 만든 건지 알거든요. AI는 그 맥락이 없어요.

Q. 그래서 어떻게 해결하셨어요?

제가 다루는 코드베이스가 자바로 백만 줄이에요. 토큰으로 치면 5백만 개 정도. 어떤 AI도 이걸 한 번에 읽고 기억 못 해요. 

처음에는 코드 덩어리를 AI한테 주고 알아서 파악하게 했어요. 엉망이었어요. AI는 곧 복잡한 코드에 파묻혀버렸죠.

그래서 방법을 바꿨어요.

전부 다 주는 대신, 핵심만 골라서 주기로 했어요. 설계 문서, 아키텍처 다이어그램, 핵심 인터페이스. 이것들을 정리해서 하나의 명세서로 만들었어요.

5백만 토큰이 2천 단어짜리 문서가 됐어요. 요구사항, 패턴, 제약 조건을 다 담은 문서요. 이러니까 훨씬 깔끔한 코드가 나왔어요.

저는 이걸 "컨텍스트 압축"이라고 불러요. "컨텍스트 엔지니어링"이나 "스펙 기반 개발"이라고 불러도  되지만 이름은 중요하지 않아요.

중요한 건 코드를 짜기 전에 생각하고 계획하는 게 일의 대부분이라는 거예요.

Q. 컨텍스트 압축을 어떻게 하는 건지 좀 더 구체적으로 설명해 주실 수 있나요?

저는 세 단계로 나눠서 해요.

첫 번째 단계는 리서치예요. 관련된 모든 걸 모아요. 아키텍처 다이어그램, 설계 문서, 슬랙에서 나눈 대화까지. 그리고 AI로 코드베이스를 분석해서 뭐가 뭐랑 연결됐는지 파악해요.

이건 한 번에 끝나는 게 아니에요. "캐싱은 어떻게 돼?", "에러 나면 어디서 처리해?" 이런 식으로 계속 파고들어요. 분석이 틀리면 고치고, 빠진 맥락이 있으면 추가하고. 이렇게 반복하다 보면 하나의 정리된 리서치 문서가 나와요.

여기서 중요한 건 이 문서를 사람이 직접 검증해야 한다는 거예요. 

이 단계에서 실수를 잡으면 나중에 큰 사고를 막을 수 있거든요.

Q. 두 번째, 세 번째 단계는요?

두 번째 단계는 플래닝이에요 검증된 리서치를 바탕으로 상세한 구현 계획을 짜요. 코드 구조, 데이터 흐름, 다 적어요. 신입한테 줘도 그대로 따라하면 돌아갈 정도로요.

이 단계에서 중요한 결정을 많이 내려요. 로직이 맞는지, 구조가 깔끔한지, 불필요하게 엮인 건 없는지. 우리는 겪어본 적 있으니까 문제가 터지기 전에 알아볼 수 있어요. AI는 그런 경험이 없어요.

이 단계의 핵심은 리뷰가 빨라진다는 거예요. 계획을 몇 분 만에 검토하고 뭐가 만들어질지 정확히 알 수 있어요.

마지막 단계는 구현이에요. 여기까지 오면 단순해요. 그게 핵심이에요. 

명확한 명세가 있으니까 AI가 딴 데로 안 새요. 50번 왔다 갔다 하는 대신 세 번의 집중된 작업으로 끝나요.

Q. 이렇게 하면 뭐가 좋아지나요?

진짜 보상은 여기서 나와요.

미리 생각해놨으니까 AI한테 구현을 맡기고 다른 일을 할 수 있어요. 돌아와서 리뷰하면 되는데, 이 리뷰가 빨라요. "이게 대체 뭐지?" 하면서 코드를 해석하는 게 아니라, "계획대로 됐나?" 만 확인하면 되거든요.

여기서 핵심은 AI한테 생각을 맡기는 게 아니라는 거예요. AI는 기계적인 작업을 빠르게 처리해주고, 이해하는 건 여전히 제가 해요. 리서치가 더 빨라지고, 계획이 더 철저해지고, 구현이 더 깔끔해지지만, 생각하고 판단하고 종합하는 건 여전히 우리 몫이에요.

Q. 앞서 말씀하신 인가 리팩토링은 결국 어떻게 됐나요?

지금 작업 중이고 잘 되고 있어요. 근데 더 좋은 프롬프트를 찾아서는 아니에요.

사실 처음에는 리서치-플래닝-구현으로 바로 들어가려고 했는데 안 됐어요. 먼저 직접 손으로 해봐야 했어요.

AI 없이 코드를 읽고, 의존성을 파악하고, 직접 바꿔보면서 뭐가 터지는지 확인했어요. 어려운 과정이었지만 결정적인 순간이기도 했어요. 그제서야 숨겨진 규칙들이 보이기 시작했거든요. 어떤 코드를 건드리면 어디서 문제가 터지는지, 코드만 읽어서는 절대 알 수 없었던 것들이요.

이렇게 직접 해본 경험을 리서치 문서에 담았어요. 그랬더니 AI가 "깔끔한 마이그레이션"이 어떤 건지 이해하기 시작했어요.

물론 그래도 한 번에 되지는 않았어요. 항목마다 상황이 달랐거든요. 어떤 데이터는 암호화돼 있고 어떤 건 아니고. 그래서 하나씩 확인하면서 "이건 이렇게 처리해야 해"라고 맥락을 계속 추가해줘야 했어요.

그러고 나서야 한 번에 될 수도 있는 계획이 나왔어요. "될 수도"가 핵심이에요. 아직도 검증하고 조정하고 있거든요.

세 단계 접근법도 마법이 아니에요. 먼저 손으로 해봤으니까 되는 거예요.

Q. 결국 더 좋은 도구가 나와도 이 문제는 해결되지 않는 건가요?

네, 한 방에 문제를 해결할 수 있는 방법은 없어요. 더 좋은 프롬프트를 찾거나 더 좋은 모델이 나온다고 해결될 문제가 아니에요. 핵심은 내가 이 시스템을 충분히 이해해서 안전하게 바꿀 수 있느냐예요.

코드가 "돌아간다"는 것만으로는 부족해요. 테스트를 통과하는 코드랑 프로덕션에서 버티는 코드는 달라요. 오늘 작동하는 시스템이랑 나중에 다른 사람이 유지보수할 수 있는 시스템도 다르고요.

진짜 문제는 지식 격차예요. AI는 몇 초 만에 수천 줄의 코드를 만들어내는데, 그걸 이해하려면 몇 시간이 걸려요. 복잡하면 며칠, 심하면 영영 이해 못 할 수도 있어요.

Q. 지식 격차 말고 또 우려되는 부분이 있나요?

있어요. 사람들이 잘 얘기 안 하는 건데요. AI의 생성 속도를 따라가려고 생각을 건너뛸 때마다, 이해 못 하는 코드가 쌓이는 것만 문제가 아니에요. 문제 상황을 알아채는 능력 자체가 무뎌져요.

개발하다 보면 "이거 점점 복잡해지는데?" 하는 감이 오잖아요. 근데 내 시스템을 이해 못 하면 그 감각이 안 생겨요.

그 감각은 경험에서 와요. 제가 위험한 구조를 알아보는 건, 새벽 3시에 그거 때문에 장애 대응 해본 적이 있어서예요. 제가 단순한 방식을 고집하는 건, 복잡하게 만든 코드를 나중에 유지보수 해본 적이 있어서예요.

AI는 그런 경험이 없어요. 시키면 시키는 대로 만들 뿐이에요.

세 단계 접근법이 이 문제를 해결해요.

내가 이해한 걸 빠르게 검토할 수 있는 형태로 정리하는 거죠. 

이런 과정 없이는, 복잡성이 쌓이는 속도가 이해하는 속도보다 빨라져요.

Q. AI가 코딩을 근본적으로 바꿨다고 보세요? 그럼 해결책은 뭘까요?

AI가 코드 짜는 방식은 완전히 바꿨어요.  

하지만 소프트웨어가 왜 실패하는지에 대해서는 아무것도 안 바꿨다고 생각해요.

모든 세대가 자기만의 소프트웨어 위기가 있었어요. 다익스트라 세대는 소프트웨어 엔지니어링이라는 분야를 만들어서 대응했죠.

이제 우리는 무한한 코드 생성으로 위기에 직면하고 있어요.

해결책이 또 다른 도구나 방법론이라고 생각하지 않아요.

우리가 원래 알고 있던 걸 기억해 내는 거예요. 소프트웨어는 결국 사람이 하는 일이에요. 어려운 건 코드 치는 게 아니라, 뭘 만들어야 하는지 아는 거예요.

성공하는 개발자들은 코드를 가장 많이 생성하는 사람이 아닐 거예요. 

자신이 뭘 만들고 있는지 이해하고,  경계를 볼 수 있고, 잘못된 문제를 풀고 있다는 걸 알아채는 사람일 거예요.

그건 여전히 우리예요. 그건 오직 우리뿐이에요.

Q. 마지막으로 남기고 싶은 말이 있으신가요?

질문을 하나 남기고 싶어요.

AI를 쓸지 말지는 이제 질문이 아니에요. 그건 이미 결론이 난 문제예요.

제 질문은 이거예요.

AI가 코드 대부분을 쓸 때, 우리가 여전히 우리 시스템을 이해하고 있을까?

오늘 레터가 좋았다면, 조쉬의 뉴스레터를 주변에 알려주시거나, 구독을 해주세요. 소중한 노력이 들어간 글을 널리 알려주세요. 

이 기사가 좋으셨다면, 보상을 해주세요. 

가장 좋은 보상은 ‘조쉬의 뉴스레터 구독’입니다. :) 

구독을 하시면 100개의 1인 창업가 데이터베이스를 발송해드립니다.

[구독하러 가기]