하드웨어 분야에서 결함 있는 제품을 출시하면 그 결과는 심각하고 대부분 되돌릴 수 없다. 필자는 반도체 기업 멜라녹스(Mellanox)와 이후 알리바바(Alibaba)에서 검증 업무를 맡으며 수년간 그 세계에 몸담았다. 높은 위험 부담은 업계가 엄격한 검증 문화를 구축하도록 이끌었다. 제품이 공장 밖으로 나가기 전에 설계가 제대로 작동함을 반드시 증명해야 했다.

소프트웨어 분야의 검증 체계는 CI/CD 파이프라인, 정적 분석, 카나리 배포, 관찰 가능성 등으로 구성된다. 그러나 이 시스템들은 사람이 코드를 작성하는 속도, 그리고 사람의 이해를 전제로 설계됐다. AI 코드 생성은 그 전제를 무너뜨렸다. 작성 과정이 기업의 지식과 판단력을 코드베이스에 담아내는 역할을 더 이상 수행하지 못하게 됐다. 업계는 하드웨어 엔지니어들이 수십 년간 실천해온 엄격한 검증 문화를 소프트웨어 개발에도 도입해야 하는 방향으로 나아가고 있다.

기업은 역사상 그 어느 때보다 빠르게 코드를 생성하고 있다. 구글은 최근 신규 코드의 75%가 AI 생성이라고 공개했다. 메타는 2026년 중반까지 엔지니어 대부분이 커밋하는 코드의 상당 부분을 AI 도구로 생성하도록 내부 목표를 설정했다. 속도 향상 효과는 상당하다. 그러나 점점 더 많은 근거들이 업계가 새로운 형태의 기술 부채를 축적하고 있음을 시사한다. 기존 기술 부채보다 눈에 띄지 않고 되돌리기도 어렵다. 예방은 가능하며, 먼저 대응한 기업은 그렇지 않은 기업보다 유의미한 경쟁 우위를 갖게 된다.

이 부채가 다른 이유를 파악하라

AI가 나쁜 코드를 작성한다는 것이 통상적인 시각이다. 그러나 더 정확한 문제는 인지적 부채, 즉 소프트웨어가 어떻게, 왜 그 방식으로 구현됐는지에 대한 이해가 사라지는 것이다.

사람이 코드를 작성할 때는 타이핑 외에 다른 일도 함께 일어난다. 엣지 케이스를 시뮬레이션하고, 의존성을 따져보며, 기능의 비즈니스 요구사항, 팀이 정립한 모범 사례, 과거 아키텍처 선택의 배경 등 기업적 맥락에 기반한 판단을 내린다. 이 인지적 순환 과정이 기업 지식이 구축되는 방식이다. AI가 코드를 작성하면 문법적으로 정확하고, CI를 통과하며, 깔끔하게 배포되는 결과물이 나오지만, 그 논리를 머릿속에 담고 있는 사람이 아무도 남지 않는다. 무언가가 바뀌거나 문제가 생기기 전까지는 코드가 작동하다가, 그 순간 팀은 블랙박스를 파헤치게 된다.

기존의 기술 부채, 즉 지저분한 코드와는 다른 양상이다. 인지적 부채는 작동하지만 아무도 진정으로 소유하지 않는 보이지 않는 코드다. 축적 속도도 더 빠르다. AI 생성을 매력적으로 만드는 바로 그 속도가, 유지보수성에 필요한 이해를 쌓는 작업을 가로막기 때문이다.

코드 분석 업체 깃클리어(GitClear)가 주요 리포지터리에서 2억 1,100만 줄의 변경 코드를 분석한 결과, 2024년 한 해 동안 5줄 이상의 중복 코드 블록이 8배 증가한 반면, 리팩토링은 전체 코드 변경의 25%에서 10% 미만으로 감소한 것으로 나타났다. 리팩토링은 코드베이스를 건강하게 유지하는 느리고 화려하지 않은 작업인데, 개발자들이 훨씬 덜 수행하고 있는 것이다. 구글의 2024년 DORA 보고서에 따르면 AI 도입률이 25% 증가하면 배포 안정성이 7.2% 감소하는 것으로 나타났다. DORA 애널리스트는 근본 원인이 결함 있는 코드 자체가 아님을 지적한다. AI가 묶음(batch) 규모를 키우는데, 더 큰 변경 집합(changesets)은 언제나 배포 위험이 높았다는 것이다.

이 연구 결과 AI 지원 개발에 대한 비판이 아니라 진단이며, 구체적인 해결 방향을 제시한다.

먼저 컨텍스트 격차를 해소하라

지난해 개발자 609명을 대상으로 실시한 설문조사에서 65%가 리팩토링, 테스트 작성, 코드 검토 등 중요한 작업에서 AI가 관련 컨텍스트를 놓친다고 답했다. 컨텍스트는 AI 코드 품질을 좌우하는 핵심 요소이며, 대다수 기업이 여기에 충분히 투자하지 않고 있다.

AI 도구가 기업의 아키텍처 결정 사항, 과거 풀 리퀘스트, 보안 정책, 기존 모듈 패턴에 접근하지 못한 채 코드를 생성하면, 국소적으로는 올바르지만 전체적으로 일관성 없는 결과물이 나온다. 이 격차를 해소하려면 컨텍스트 엔지니어링이 필요하다. 사용하는 도구와 에이전트가 적절한 시점에 올바른 기업 지식에 접근할 수 있도록 보장하고, 특정 작업에 실제로 관련 있는 내용이 무엇인지 판단하는 역량을 갖추는 것이다. 너무 많은 무관한 컨텍스트를 불러오는 검색 시스템은 너무 적은 컨텍스트를 불러오는 시스템만큼이나 결과물 품질을 떨어뜨릴 수 있다. 특정 도구보다 규율이 더 중요하다. 컨텍스트 인프라는 한 번 색인화하고 잊어버릴 것이 아니라 적극적으로 유지 관리해야 한다.

AI 생성 규모를 확장하기 전에 이 인프라를 먼저 구축해야 한다. 나중에 보완하는 것은 훨씬 더 어렵다. CI 파이프라인처럼, 안전한 프로덕션 배포를 위한 전제 조건으로 여겨야 한다.

팀이 컨텍스트 인프라를 잘 구축했을 때 어떤 일이 일어나는지 생각해보자. 코드 검토 도구가 내부 API 폐기 사실을 인지한다. 수개월치 과거 풀 리퀘스트 논의에 담긴 그 폐기 결정이 색인화돼 검토 도구에 연동돼 있기 때문이다. 생성된 코드가 구버전 API를 참조하면 검토 도구가 이를 표시한다. 이 컨텍스트 레이어 없이는 같은 실수가 매번 그냥 통과된다. 사람이 모든 코드 라인을 직접 작성하지 않는 환경에서 사라지는 기업 지식, 그 기업 지식을 적극적으로 보존해야 하는 이유가 여기 있다.

생성 속도에 맞는 검증 레이어를 구축하라

AI 지원 개발 분야 투자의 대부분은 생성에 집중됐다. 검증에 들어간 투자는 극히 적었다. 이 불균형이 기술 부채가 쌓이는 지점이다.

필자는 블루팀과 레드팀으로 나눠 설명한다. 블루팀은 코드 생성, 자동완성, 에이전틱 코딩을 담당한다. 헤드라인을 장식하고, 예산이 집중되며, 제품 출시도 이어진다. 레드팀은 무결성 검사, 행동 커버리지, 기업 표준 준수 여부를 담당한다. 대다수 기업에서는 뒷전으로 밀려 있다. CI 파이프라인은 명백한 오류를 잡아낸다. 코드 검토가 이뤄지기도 하지만, 검토자들은 쏟아지는 AI 생성 코드 물량에 압도돼 전부를 의미 있게 평가할 수 없다. 결과적으로, 누군가가 실제로 이해한 것이 아니라 검토된 것처럼 보이는 코드만 남게 된다.

2024년 사이버보안 업체 크라우드스트라이크(CrowdStrike)의 대규모 장애는 여기서 떠올릴 만하다. AI가 문제 코드를 생성한 것은 아니었지만, 단 하나의 소프트웨어 오류가 충분한 검증 없이 프로덕션 시스템 전반에 퍼져나갈 때 어떤 일이 벌어지는지를 보여준 사례였다. 코드가 사람이 이해하는 속도보다 빠르게 생성되는 환경에서 그 위험성은 배가된다.

진정한 검증 레이어는 생성된 코드가 기업의 모범 사례, 아키텍처 표준, 규정 준수 요건에 부합하는지 평가하는 자동화 분석을 의미한다. AI가 테스트를 생성하면서 선택한 해피 패스만이 아니라, 의도된 동작을 반영하는 테스트 커버리지도 필요하다. 추적 가능성, 즉 요구사항과 구현 사이의 연결고리도 갖춰야 한다. 6개월 후 누군가가 그 코드의 동작 방식과 존재 이유를 파악할 수 있도록 하기 위해서다.

이 분야에 대한 투자를 수치가 뒷받침한다. 같은 개발자 설문조사에서, AI를 코드 검토 워크플로우에 통합한 팀은 81%의 경우에서 품질 개선을 경험한 반면, 통합하지 않은 유사 팀은 55%에 그쳤다.

소유권을 선택 사항으로 두지 마라

프로덕션에 배포된 모든 AI 생성 코드에는, 유지보수를 담당할 수 있을 만큼 충분히 코드를 이해한 책임자가 있어야 한다. 말처럼 쉽지는 않다. 대다수 기업이 부족한 부분이 바로 이 지점이다.

속도야말로 AI 생성의 가장 큰 매력이지만, 바로 그 속도가 진정한 이해를 위한 느리고 고단한 작업을 건너뛰게 하는 주범이 된다. AI가 3분 만에 생성한 500줄짜리 풀 리퀘스트를 검토하는 개발자는 실질적인 선택에 직면한다. 2시간을 들여 코드를 실제로 이해하거나, 제대로 돌아가고 테스트를 통과하니 “문제없어 보이는군”이라며 승인하거나 둘 중 하나다.

진정한 소유권은 의미 있는 검토가 가능할 만큼 생성 속도를 늦추고, 속도보다 이해가 먼저라는 원칙을 팀 내에서 명확히 하는 것을 의미한다. 그렇게 하지 않으면, 오늘의 코드가 내일의 기술 부채로 그대로 굳어진다.

이번 분기에 기업이 할 일

다행히 수년에 걸친 대대적인 변화 없이도 이 문제들은 해결 가능하다. 구조적 문제는 실재하지만 구체적인 해결책이 있으며, 엔지니어링 리더는 다음 예산 사이클을 기다리지 않고도 세 가지 영역 모두에서 의미 있는 진전을 이룰 수 있다.

• 컨텍스트 인프라를 감사하라. AI 도구가 기업의 아키텍처 결정 사항, 폐기된 API, 보안 정책에 접근하지 못한 채 코드를 생성하고 있다면, 생성 규모를 더 키우기 전에 먼저 해결해야 한다. 컨텍스트의 품질이 결과물의 품질을 결정한다.
• 레드팀에 투자하라. 기능적 정확성을 넘어 기업 고유의 기준에 따라 생성 코드를 평가하는 자동화된 코드 품질 및 거버넌스 레이어를 구축하라. 코드 생성 도구와는 별개의 독립적인 투자로 다뤄야 한다.
• 소유권을 명시적으로 지정하라. 프로덕션에 배포된 모든 AI 생성 기능에는 그 기능을 진정으로 이해하는 담당자가 있어야 한다. 공식 요건으로 만들어야 한다.

검증 레이어를 갖춘 AI 생성 코드는 훨씬 더 안정적으로 작동한다. 준비가 된 기업은 그 사실을 직접 확인하게 된다. 그렇지 않은 기업은 시스템에 대한 이해는 줄어드는 상태에서 더 빠른 배포를 이어가다가, 쌓인 부채가 한꺼번에 터지는 상황을 맞게 된다. 해결 가능한 문제다. 지금 해결하느냐, 나중에 해결하느냐의 문제만 남았다.
dl-itworldkorea@foundryco.com