칼럼 | AI가 만든 코드, 실전에 투입하려면 왜 이렇게 어려울까?

개발자들은 이제 대규모 언어모델(LLM)을 활용해 엄청난 양의 코드를 빠르게 생성하고 있다. 정확한 집계 방식을 밝힌 것은 아니지만, 스태빌리티 CEO는 깃허브에 올라온 레포지토리를 기준으로 전체 코드의 약 41%가 AI에 의해 작성됐다고 추정했다. 업계 최고의 개발자들이 일하고 있는 구글조차 자사 코드의 25% 이상을 AI에 맡기고 있다. 언뜻 보면 개발자들이 해변에서 여유를 즐기며 코드를 더 많이, 더 빠르게 만들 수 있는 이상적인 세상이 열린 듯하지만 현실은 다르다. 실제 서비스를 위한 코드를 작성해 본 사람이라면 누구나 알고 있다. 코드를 만들어내는 것보다, 그 코드가 제대로 작동하게 만드는 일이 훨씬 더 어렵다는 사실을 말이다. 필자가 이전 칼럼에서 ‘LLM이 만든 코드는 마법처럼 버그가 없거나 스스로 관리되는 것이 아니다’라고 지적했듯, 실제로는 오히려 그 반대에 가깝다.

실제로, 코드를 빠르게 생성할수록 서비스 수준으로 끌어올리는 데 더 많은 시간이 걸릴 수 있다. 생성된 코드를 다듬고, 디버깅하고, 운영 환경에 맞게 보완해야 하기 때문이다. 오픈소스 시뮬레이션 인프라 플랫폼 업체 네이티브링크(NativeLink)의 최고경영자 마커스 이건은 링크드인을 통해 “AI 에이전트는 저마다 독립적인 판단을 하기 때문에, 테스트 환경과 실제 운영 환경 사이의 행동 변화 폭을 파악하고 통제하는 것이 중요하다”라고 설명했다. 개발 단계와 운영 환경 간의 간극은 AI 기반 개발의 가장 큰 난제로 꼽히며, 결국 누가 이 AI 코드들을 컴파일하고, 테스트하며, 서비스 수준으로 다듬을 것인가 하는 문제가 핵심으로 떠오르고 있다.

여전히 사람의 몫으로 남은 핵심 작업

AI가 우리의 모든 업무를 대신해주길 바랄 수는 있지만, 현실은 다르다. 코드를 작성한 이후의 어려운 작업, 즉 테스트와 검증, 보완 작업은 여전히 인간의 몫이다. 생성형AI는 잘못된 라이브러리를 사용하거나 빌드 제약 조건을 무시하고, 미묘한 논리적 오류를 간과하기도 한다. 최근 엔지니어링 리더 500명을 대상으로 한 설문조사에 따르면, AI 모델은 생성하는 보일러플레이트 코드와 함께 미묘한 버그와 보안 취약점을 끼워 넣는 경향이 있다. 또한 해당 조사에서 응답자의 59%는 AI가 작성한 코드가 절반 이상의 확률로 오류를 유발한다고 답했으며, 67%는 사람이 작성한 코드보다 AI가 만든 코드를 디버깅하는 데 더 많은 시간을 쓰고 있다고 밝혔다. 또한 68%는 AI가 제안한 보안 취약점을 수정하는 데 추가적인 노력이 필요하다고 응답했다.

이 말은 곧, AI가 개발자의 업무를 줄이기보다는 품질관리(QA)와 운영 단계에서 부담을 더 키운다는 뜻이다.

AI와 함께라면 개발 이후 후속 작업이 더 어려워질 수도 있다. 이제 개발자들은 자신의 실수를 고치는 대신, 낯선 코드를 다뤄야 하는 상황에 놓이고 있다. 실제로, 20년 경력의 개발자인 다니엘 벤치스는 AI 에이전트에게 코드 작성과 수정 작업 전부를 맡기고 27일간 실험을 진행했다. 그 결과, 1700건이 넘는 커밋이 거의 인간의 개입 없이 생성되었다. 이 과정에서 그는 단순한 버그 하나를 수정하는 데에도 AI에게 정확한 지시를 내리느라 몇 시간이 소요되는 경우가 많다는 사실을 발견했다.

그는 블로그를 통해 “사람이라면 5분 만에 고칠 문제도, AI에게는 몇 시간에 걸쳐 일일이 가이드를 해줘야 했다”라며 “기존 문제를 해결하려다 새로운 문제를 유발하거나, 엉뚱한 방향으로 흐르기 쉬운 AI의 특성 때문”라고 설명했다.

결국 AI가 사람을 대체하기보다는, 인간 개발자의 역할과 업무 방식을 바꾸고 있다. 개발자는 AI가 만든 코드를 감시하고, 가이드를 제공하며, 검토하고 수정하는 관리자의 역할을 수행하게 된다. 코드를 작성하는 일이 사라지는 게 아니라, 새로운 방식으로 진화하고 있는 셈이다.

기계가 만든 코드를 다시 기계가 다듬는다

이 같은 문제를 해결하기 위해 기업과 오픈소스 프로젝트들은 AI 코드를 점검하고 테스트하는 과정을 자동화하려는 시도를 이어가고 있다. 흥미롭게도, 이들 도구 역시 AI를 활용해 AI의 한계를 보완하고 있다. 주요 사례는 다음과 같다.

• AI 기반 품질 점검 도구: 소나큐브(SonarQube)와 스닉(Snyk) 같은 도구는 AI가 만든 코드에서 버그나 보안 문제를 탐지하고 수정한다. 소나는 프로젝트에 병합되기 전, 흔히 발생하는 코딩 실수를 AI로 찾아내고 자동으로 수정해주는 기능을 새롭게 선보였다.
• 자동 테스트 생성: 디프블루 커버(Diffblue Cover)는 AI로 자바 코드를 위한 단위 테스트 코드를 생성해 테스트 속도를 최대 250배까지 향상시킨다. 네이티브링크는 오픈소스 기반 원격 실행 서버로, 빌드 시간을 수일에서 수 시간으로 줄이는 데 도움을 준다. 이러한 도구는 AI 코드 생성 속도를 따라잡는 데 필수적이다.
• AI 기반 코드 리뷰: 깃허브의 코파일럿은 자동 풀 리퀘스트 리뷰 기능을 선보이며, 사람 리뷰어가 보기 전에 코드 내 오류나 보안 취약점을 먼저 검토한다. 아마존웹서비스(AWS)의 코드구루(CodeGuru), 소스그래프(Sourcegraph)의 코디(Cody)도 AI 기반 디버깅과 코드 분석 기능을 제공하고 있다.
• 에이전트 기반 파이프라인: 젠코더(Zencoder)와 같은 프로젝트는 여러 AI 봇이 협업해 코드를 생성, 테스트, 개선, 리뷰하는 방식의 멀티 에이전트 파이프라인을 실험하고 있다. 처음부터 운영 수준의 품질을 확보하기 위한 접근이다.
• 보안 실행 테스트 환경: E2B 등 일부 플랫폼은 격리된 샌드박스 환경에서 AI가 작성한 코드를 실행하며 컴파일 또는 런타임 오류를 자동으로 점검한다. 사람이 코드에 손대기 전 오류를 걸러낼 수 있는 방식이다.

개발팀을 위한 AI 실전 활용팁 6가지

AI 기술이 발전해도 고품질 소프트웨어는 여전히 숙련된 개발자 손에서 완성된다. 사실 인간의 창의성과 기계가 생성한 코드의 압도적인 힘을 결합하는 데는 좋은 방법도, 나쁜 방법도 있다. 그렇다면 오늘날 개발팀은 AI가 쏟아내는 코드의 홍수를 어떻게 관리하고, 이를 실제 프로덕션 환경에 투입할 수 있을 만큼 완성도 높은 상태로 만들 수 있을까? 꼭 짚고 넘어가야 할 질문이다. 필자는 이에 대해 다음 6가지 제안을 하고자 한다.

첫째, AI가 작성한 코드는 최종 결과물이 아니라 초안으로 간주해야 한다. AI가 만들어낸 코드를 그대로 받아들이기보다는, 의심하고 검토하는 문화가 필요하다. 마치 신입 개발자의 코드를 리뷰하듯, AI가 작성한 코드도 반드시 리뷰를 거치게 해야 한다. 시니어 개발자나 해당 코드의 책임자가 꼼꼼하게 살펴야 하며, 테스트 없이 바로 배포하는 일은 절대 없어야 한다.

둘째, 품질 점검을 개발 파이프라인에 통합해야 한다. 정적 분석, 린팅(linting), 보안 스캐닝 등은 AI 코드가 포함된 경우라면 더욱 필수적인 CI(지속적 통합) 요소가 되어야 한다. 젠킨스, 깃허브 액션, 깃랩 CI와 같은 CI/CD 도구는 소나큐브(SonarQube), ESLint, 밴딧(Bandit), 스닉등 다양한 품질 점검 툴을 커밋마다 실행할 수 있다. 이러한 품질 확인 기능을 모든 코드에 활성화하고, 특히 AI가 생성한 코드에 철저하게 적용해야 조기에 오류를 잡을 수 있다. 소나의 슬로건처럼, ‘코드가 어디서 왔든 모든 코드는 품질과 보안 기준을 충족해야 한다’는 원칙을 지켜야 한다.

셋째, 코드 작성뿐 아니라 테스트에도 AI를 적극 활용해야 한다. AI는 단위 테스트 코드를 생성하거나 테스트 데이터를 만들어주는 데 유용하다. 예를 들어, 깃허브의 코파일럿은 특정 함수에 대한 단위 테스트 작성을 도와주고, 디프블루 커버는 레거시 코드를 위한 테스트 케이스를 대량으로 자동 생성할 수 있다. 테스트를 자동화하면 시간을 절약할 수 있을 뿐 아니라, AI 코드가 스스로 신뢰성을 증명해야 하는 환경이 마련된다. ‘신뢰하되 검증하라’는 자세로 접근해야 한다. AI가 함수를 작성하면, 테스트 케이스도 함께 생성하게 하고 이를 자동 실행해보는 식이다.

넷째, 아직 가이드라인이 없다면, 개발자들이 AI 코딩 도구를 어떻게 활용할 수 있고 어떤 방식은 피해야 하는지에 대한 내부 정책을 수립해야 한다. 보일러플레이트 같은 반복적인 코드나 예시 작성 같은 용도는 허용하되, 민감한 로직이나 보안 관련 정보는 금지하는 식으로 용도를 명확히 규정해야 한다. 개발자가 풀리퀘스트에 AI 생성 코드임을 주석으로 표시하도록 유도하면, 리뷰어가 해당 코드에 더욱 신중하게 접근할 수 있다. 또한, 라이선스 관련 사항도 고려해야 한다. AI로부터 파생된 코드가 기존의 코드 라이선스 정책을 위반하지 않도록 사전 점검이 필요하다.

다섯째, 필자가 이전 칼럼에서도 언급했듯이, AI를 제대로 활용하려면 특정 영역에서 더 높은 수준의 개발 실력이 필요하다. 개발팀이 코드를 읽고 디버깅하는 능력을 강화해야 한다. AI가 SQL 인젝션이나 버퍼오버플로 같은 보안 취약점을 포함시켰을 때 이를 식별할 수 있어야 하기 때문이다. 테스트 중심의 사고방식도 중요하다. 개발자는 코파일럿이 제공한 함수를 그대로 신뢰하기보다, 테스트 코드를 먼저 작성하고 검증하는 습관을 들여야 한다. 결국 개발자들에게 필요한 것은 AI 도구의 기능과 한계를 모두 이해하는 ‘AI 리터러시’다.

여섯째, 새롭게 떠오르는 AI 도구들을 직접 시험해보며 실전 감각을 익히는 것도 중요하다. 예를 들어, 깃허브 코파일럿의 자동 풀 리퀘스트 리뷰 기능을 일부 저장소에 시범 적용해 보는 것도 좋은 출발점이 될 수 있다. 혹은 오픈소스 도구인 E2B를 샌드박스 프로젝트에 도입해 AI 에이전트가 스스로 코드를 실행하고 테스트하게 해볼 수도 있다. 목표는 단순하다. 팀의 부담을 줄여주는 도구를 찾고, 오히려 혼란을 늘리는 기능은 걸러내는 것이다.

앞으로 업계는 코드 검증 과정에서 AI 자동화가 더 정교해지는 방향으로 진화할 가능성이 크다. 여러 AI 에이전트가 컴파일, 테스트, 디버깅, 보안 검사를 독립적으로 수행하는 멀티 에이전트 시스템이 보편화될 수 있다. AI가 스스로 품질 검증까지 해내는 수준에 이르면, 개발자는 반복적인 수정 대신 전략적 기획에 집중할 수 있게 된다. 다만 지금까지의 현실은 다르다. 결국 중요한 작업은 여전히 사람이 맡고 있다. 그리고 어쩌면 앞으로도 계속 그럴 가능성이 크다. 미래의 개발자는 직접 코드를 쓰는 일은 줄어들겠지만, AI가 따라야 할 명세, 제약 조건, 검수 기준을 설계하는 데 더 많은 시간을 쓰게 될 것이다.
dl-ciokorea@foundryco.com