안드레이 카파시는 IT 업계에서 굳이 걸러 들을 필요가 없는 몇 안 되는 인물로 꼽힌다. 오픈AI의 설립 멤버이자 테슬라의 전 AI 디렉터를 지낸 카파시는 AI 기술과 그 활용 가능성의 최전선에 서 있는 인물이다. 최근 X에서 카파시는 기대와 불안을 동시에 불러오는 시각을 내놓았다. 카파시는 “지난 약 1년 동안 새롭게 사용할 수 있게 된 것들을 제대로만 엮어 활용한다면 나는 지금보다 10배는 더 강력해질 수 있다”라며 “이 정도의 도약을 이루지 못하고 있다면, 그건 도구가 아니라 역량의 문제처럼 느껴진다”라고 전했다.

이 발언을 그대로 받아들이면, 2023년보다 현재의 생산성이 10배 높아지지 않았다면 문제의 원인은 도구가 아니라 개발자 자신이라는 결론에 이른다. 한편으로는 고개가 끄덕여지면서도, 다른 한편으로는 어딘가 불편한 지점이 있다. 현 세대의 LLM 도구가 지닌 잠재적인 활용 가치는 분명 압도적이지만, 카파시의 논지는 한 단어에 크게 기대고 있다.

바로 ‘제대로’다.

코드가 며칠 쓰이고 사라지는 것이 아니라 수십 년 동안 유지되는 엔터프라이즈 환경에서 ‘제대로’라는 것은 말은 쉽지만 실제로 구현하기는 어렵다. 현장에서의 경험과 점점 쌓여가는 데이터가 보여주는 현실은 다르다. 대부분 개발자가 겪는 이른바 ‘역량 문제’는 프롬프트를 얼마나 잘 작성하느냐의 문제가 아니라, 결과물을 얼마나 철저하게 검증하느냐의 문제에 가깝다. AI가 제공하는 속도는 거의 공짜에 가깝지만, 그 결과를 신뢰할 수 있는 수준까지 끌어올리는 데 드는 비용은 생각보다 훨씬 크다.

‘바이브’에 기대는 생산성의 함정

현실에서 AI가 제공하는 속도는 결코 공짜가 아니다. 2025년 초 모델 평가·위협 연구 기관인 METR(Model Evaluation and Threat Research)은 숙련된 오픈소스 개발자를 대상으로 무작위 대조 실험을 진행했다. 참가자들에게 동일한 과제를 부여하고, 절반은 AI 도구를 사용하게 했으며 나머지 절반은 기존 방식으로 작업하도록 했다. AI를 활용한 개발자들은 LLM이 개발 속도를 20%가량 끌어올렸다고 확신했다. 그러나 결과는 정반대였다. AI를 사용한 그룹의 실제 작업 속도는 평균적으로 19% 더 느렸다.

인식과 현실 사이에는 약 40%p에 달하는 격차가 존재했다. 적잖은 충격이다.

왜 이런 일이 벌어질까? 앞서 지적했듯, 개발자는 점점 더 바이브(감)에 기반한 평가에 의존하고 있다. 바이브 코딩으로 생성한 코드는 겉보기에는 멀쩡해 보이고, 눈앞에 즉시 나타난다. 하지만 마지막 단계에서 문제가 드러난다. 생성된 코드가 이미 폐기된 라이브러리를 사용하거나, 존재하지 않는 파라미터를 만들어내거나, 눈에 잘 띄지 않는 경쟁 조건을 슬쩍 끼워 넣는 식이다.

카파시는 “지난 30일 동안의 소식만 놓쳐도 이 주제에 대해 이미 구식 세계관을 갖게 된다”라고 말하며 FOMO를 자극했다. 일리가 없는 말은 아니다. 하지만 AI가 아무리 빠르게 변하더라도 좀처럼 바뀌지 않는 것이 있다. 그중 하나가 품질 관리다. AI 코딩 툴은 본질적으로 생산성 도구라기보다, 검증이라는 비용을 동반한 책임 발생 장치에 가깝다. 이 비용은 미리 지불할 수도 있고, 나중에 치를 수도 있다. 철저한 코드 리뷰와 테스트, 위협 모델링으로 선제 대응할 수도 있으며, 사고와 데이터 유출, 대규모 리팩터링이라는 형태로 뒤늦게 감당할 수도 있다. 선택지는 달라도 대가는 반드시 치르게 된다.

지금도 많은 개발팀은 이른바 ‘신뢰 세금’을 피해 가고 있다고 생각한다. 하지만 실제로는 그렇지 않다. 베라코드의 생성형 AI 코드 보안 보고서(GenAI Code Security Report)에 따르면, AI가 생성한 코드 샘플의 45%가 OWASP의 10대 보안 취약점에 포함되는 보안 취약점을 새로 만들어냈다. 신뢰 세금을 면제받지 못한다는 뜻이다.

엄격한 감사 없이 AI의 제안을 받아들이는 경우, 거의 2번 중 1번꼴로 치명적인 취약점을 코드베이스에 들여놓게 된다. SQL 인젝션, 크로스사이트 스크립팅(XSS), 접근 제어 실패가 대표적이다. 베라코드 보고서 집필팀은 “속도 향상은 축하한다. 이제 침해 사고라는 세금을 납부할 차례”라고 노골적으로 표현했다. 마이크로소프트의 개발자 에반젤리스트 말린 음항가미 역시 “코드를 유지·관리할 수 있고 신뢰할 수 있는 상태로 배포하는 과정은 여전히 가장 큰 병목으로 남아 있다”라고 지적했다.

즉, 우리는 AI를 활용하면서 수동 보안 검토로는 도저히 따라잡을 수 없는 속도로 취약한 코드를 쌓아 가고 있다. 이는 소나소스(SonarSource)가 꾸준히 경고해 온 생산성의 역설을 그대로 입증한다. 품질 관문에 과감하게 투자하지 않는다면, 코드 생성 속도가 빨라질수록 버그와 복잡성, 기술 부채 역시 불가피하게 더 빠른 속도로 누적된다는 주장이다. 소나소스는 현재 우리가 ‘쓰기 전용(write-only) 코드베이스’를 만들고 있다고 지적한다. 비결정적 에이전트가 생성한 코드가 지나치게 방대하고 복잡해지면서, 더 이상 어떤 인간도 시스템 전체를 온전히 이해할 수 없는 상태로 가고 있다는 설명이다.

우리는 점점 장기적인 유지보수성을 단기적인 산출물과 맞바꾸고 있다. 이는 슈가 하이(sugar high) 같은 일시적인 흥분 상태에 지나지 않는다.

개발자에게 진짜 필요한 역량

안드레이 카파시가 틀린 것일까? 그렇지는 않다. 카파시가 말한 ‘10배 더 강력해질 수 있다’는 주장 자체는 맞다. 실제 향상이 정확히 10배일지는 알 수 없지만 AI를 제대로 활용하는 개발자가 얻는 성능 개선 효과가 분명히 존재하며, 최소한 그 가능성은 충분히 현실적이다. 다만 단순히 여러 도구를 잘 이어 붙이는 역량 외에 다른 것이 필요하다.

카파시는 ‘좋은 소프트웨어란 무엇인가’에 대한 깊이 체화된 기준을 갖고 있다. 이 기준이 있기에 불필요한 잡음을 걸러낼 수 있다. AI의 결과가 신뢰할 만한 순간과 환각에 가까운 결과를 내놓는 순간을 구분할 수 있다는 뜻이다. 그러나 카파시 같은 역량을 갖춘 개발자는 극히 드물다. 결국 다시 문제의 단어, ‘제대로’로 돌아오게 된다.

2026년이 갓 시작된 지금, 개발자가 키워야 할 역량은 프롬프트 엔지니어링이 아니다. 검증 엔지니어링이다. 카파시가 말하는 성능 향상을 실제로 자신의 것으로 만들고 싶다면, 개발의 초점을 코드 생성에서 코드 비판과 검토로 옮겨야 한다.

검증은 이제 새로운 코딩이다. 개발자의 가치는 더 이상 얼마나 많은 코드를 작성했느냐로 결정되지 않는다. 머신이 만들어낸 결과물을 얼마나 효과적으로 검증할 수 있는지가 그 가치를 규정한다.

‘골든 패스’는 선택이 아니라 필수다. 앞서 언급했듯, AI를 무제한으로 풀어둘 수는 없다. 표준화되고 보안이 적용된 템플릿, 즉 골든 패스가 필요하다. LLM에 데이터베이스 커넥터를 직접 작성하라고 요구할 것이 아니라, 보안이 확보된 플랫폼 라이브러리에 포함된 인터페이스를 구현하도록 지시해야 한다.

보안 아키텍처는 개발자가 직접 설계해야 한다. 대규모 언어 모델에게 단순히 “이 코드를 안전하게 만들어 달라”라고 요청하는 것만으로는 충분하지 않다. 위협 모델링에 담기는 고수준의 사고는 여전히 AI가 안정적으로 수행하지 못하는 영역이기 때문이다.

사용 가능한 도구를 ‘제대로 엮는다’는 말은 IDE를 챗봇에 연결하는 수준을 의미하지 않는다. 이는 AI를 낙관적으로 대하는 것이 아니라, 체계적으로 다루는 접근을 뜻한다. LLM을 린팅 도구와 정적 애플리케이션 보안 테스트(SAST), 동적 애플리케이션 보안 테스트(DAST), 자동화된 회귀 테스트로 둘러싼 일종의 안전장치 안에 두는 것을 의미한다.

2026년에 실제로 10배 더 강력해질 개발자는 AI를 맹목적으로 신뢰하는 이들이 아니다. AI를 매우 똑똑하지만 아직은 연차가 낮은 인턴처럼 대하는 개발자다. 번뜩이는 아이디어를 내놓을 수는 있지만, 상시적인 감독이 없으면 운영 환경의 데이터베이스를 지워버릴 수도 있는 존재로 인식하는 것이다.

역량의 문제는 분명 존재한다. 그 역량은 속도가 아니라 통제력이다.
dl-itworldkorea@foundryco.com