"AI가 짠 코드, 저도 다 모릅니다" 넷플릭스 개발자의 고백
핵심 포인트
- 1AI 코딩 도구는 개발 속도를 혁명적으로 높였으나, 개발자들이 이해하지 못하는 코드를 배포하게 만들어 시스템 실패 시 디버깅을 어렵게 하는 새로운 '소프트웨어 위기'를 초래합니다.
- 2이 문제는 AI가 제공하는 '쉬움(easiness)'에만 집중하여 '단순함(simplicity)'과 설계를 간과하고 코드의 맥락과 기술 부채를 구분하지 못하는 데서 발생하며, 복잡성을 가속화합니다.
- 3넷플릭스 개발자는 '컨텍스트 압축'이라는 3단계(리서치, 플래닝, 구현) 접근법을 통해 인간이 시스템을 이해하고 설계하며 AI는 기계적인 구현을 담당함으로써, 지식 격차와 복잡성 축적을 관리하는 방안을 제시합니다.
이 글은 넷플릭스 시니어 엔지니어 제이크 네이션스의 강연을 통해 AI 코딩 도구의 도입이 가져온 개발 생산성의 혁명과 동시에 심화되는 문제점, 그리고 이에 대한 해결책을 심층적으로 다룹니다.
AI 코딩 도구(Copilot, Cursor, Claude Code 등)는 개발 속도를 혁명적으로 향상시켰습니다. 며칠 걸리던 작업이 몇 시간으로 단축되고, 수년간 미뤄졌던 리팩토링도 가능해졌습니다. 그러나 네이션스는 "이해하지 못하는 코드를 배포하고 있다"는 고백과 함께, 시스템 오류 시 디버깅이나 유지보수가 불가능해지는 심각한 문제를 제기합니다. 이러한 '이해하지 못하는 코드'의 축적은 AI가 제공하는 "쉬운" 개발 방식에서 비롯됩니다. 클로저 언어 개발자인 리치 히키의 개념을 인용하여 "단순함(simplicity)"과 "쉬움(easiness)"을 구분하는데, AI는 '쉽게(easy)' 코드를 생성하지만, 그 코드가 '단순한(simple)' 구조를 갖는 것은 아니며 오히려 복잡성을 가중시킨다고 설명합니다. 여기서 '단순함'은 각 부분이 하나의 역할만 하고 다른 부분과 얽히지 않는 구조적인 문제를 의미하며, '쉬움'은 접근성이 높아 빠르게 무언가를 추가할 수 있는 것을 의미합니다. AI는 고민과 설계 없이 요구사항에 따라 코드를 생성하여 빠른 '쉬움'을 제공하며, 이는 기존 코드베이스의 문맥과 기술 부채를 이해하지 못한 채 복잡성을 무한히 쌓는 결과를 낳습니다.
프레드 브룩스의 복잡성 개념을 빌려, 소프트웨어의 복잡성을 본질적 복잡성(intrinsic complexity)과 우발적 복잡성(accidental complexity)으로 나눕니다. 본질적 복잡성은 문제 자체의 어려움에서 오고, 우발적 복잡성은 문제를 풀기 위해 덧붙여진 임시 방편이나 낡은 구조 등에서 발생합니다. AI는 이 둘을 구분하지 못하고 모든 것을 '살려야 하는 코드'로 인식합니다. 넷플릭스의 레거시 인증 시스템 리팩토링 사례에서 AI가 기존 코드의 복잡한 의존성과 문맥을 이해하지 못하고 오히려 더 많은 레이어를 덧씌워 복잡성을 심화시킨 경험을 공유합니다. AI는 '경계(boundaries)'를 볼 수 없기 때문에 비즈니스 로직과 인증 로직 등이 얽혀있는 상황에서 맥락 없이 코드를 생성할 뿐입니다.
이러한 문제에 대한 해결책으로 네이션스는 '컨텍스트 압축(Context Compression)'이라는 방법론을 제시합니다. 이는 '컨텍스트 엔지니어링(Context Engineering)' 또는 '스펙 기반 개발(Spec-based Development)'이라고도 불릴 수 있으며, AI에게 모든 코드베이스를 통째로 넘겨주는 대신, 인간이 핵심적인 정보와 맥락을 AI가 처리할 수 있는 형태로 '압축'하여 제공하는 방식입니다. 이 방법론은 크게 세 단계로 이루어집니다.
- 리서치(Research):
- 관련된 모든 정보를 수집합니다. 아키텍처 다이어그램, 설계 문서, 슬랙 대화 기록, 기존 코드베이스 분석 결과 등을 포함합니다.
- AI를 활용하여 코드베이스의 연결성 등을 파악할 수 있지만, '캐싱은 어떻게 되는가?', '에러는 어디서 처리되는가?'와 같이 끊임없이 파고들어 핵심 맥락을 추출합니다.
- 이렇게 정리된 리서치 문서는 반드시 '인간'이 직접 검증해야 합니다. 이 단계에서 실수를 잡는 것이 향후 큰 문제를 방지합니다.
- 플래닝(Planning):
- 검증된 리서치 문서를 바탕으로 상세한 구현 계획을 수립합니다. 코드 구조, 데이터 흐름 등을 신입 개발자도 이해하고 따라할 수 있을 정도로 상세하게 명세화합니다.
- 이 단계에서 로직의 적합성, 구조의 깔끔함, 불필요한 연관성 등을 인간이 판단하여 핵심적인 결정을 내립니다. 과거의 경험을 통해 문제가 발생하기 전에 미리 알아볼 수 있는 것은 인간만이 가진 능력입니다.
- 이 계획은 AI에게 주어질 명확한 명세서가 되므로, AI의 '리뷰'가 아닌 '검토'가 훨씬 빠르고 정확해집니다.
- 구현(Implementation):
- 명확한 명세서가 있으므로 AI는 명세에 따라 코드를 생성하며, 이 과정은 훨씬 단순해지고 효율적입니다.
- AI가 엉뚱한 방향으로 코드를 생성할 가능성이 줄어들고, 인간과 AI 간의 반복적인 대화 횟수가 현저히 감소합니다.
- 인간은 AI가 생성한 코드를 빠르게 리뷰하고, '계획대로 됐는지' 여부만 확인하면 되므로 시간과 노력을 절약할 수 있습니다.
이러한 접근법은 AI에게 '생각'을 맡기는 것이 아니라 '기계적인 작업'을 빠르게 처리하도록 하는 데 중점을 둡니다. 리서치와 계획은 빨라지고 구현은 깔끔해지지만, 핵심적으로 '생각하고 판단하고 종합하는' 역할은 여전히 인간의 몫이라는 것이 중요합니다. 네이션스는 이 과정에서 인간이 직접 코드를 읽고 의존성을 파악하며 테스트해보는 '손으로 해보는' 경험이 필수적임을 강조합니다. 이를 통해 숨겨진 규칙과 의존성을 파악하고, 그 경험을 리서치 문서에 담아 AI가 더 정확한 코드를 생성할 수 있도록 맥락을 부여합니다.
결론적으로, 이 글은 더 좋은 도구나 모델이 모든 문제를 해결하지 못하며, 코드가 "돌아가는 것"만으로는 부족하다고 말합니다. "테스트를 통과하는 코드"와 "프로덕션에서 버티는 코드", 그리고 "오늘 작동하는 시스템"과 "나중에 다른 사람이 유지보수할 수 있는 시스템"은 다르기 때문입니다. AI가 수천 줄의 코드를 몇 초 만에 생성하는 '지식 격차'는 심화될 수밖에 없으며, 이로 인해 개발자가 '복잡성 감각'을 잃을 수 있음을 경고합니다. 이 '감각'은 과거의 경험, 특히 문제 해결 경험에서 비롯되는 것이며, AI는 이러한 경험이 없습니다. AI 시대에 성공하는 개발자는 코드를 가장 많이 생성하는 사람이 아니라, 자신이 무엇을 만들고 있는지 이해하고, 시스템의 경계를 볼 수 있으며, 잘못된 문제를 풀고 있다는 것을 알아채는 사람, 즉 '생각하고 판단하는' 능력을 가진 인간이 될 것이라는 메시지를 남깁니다. 궁극적인 질문은 "AI가 코드 대부분을 쓸 때, 우리가 여전히 우리 시스템을 이해하고 있을까?"로 마무리됩니다.