Copilot이 코드를 작성했지만, 누가 소유할까? 엔지니어링 팀이 간과할 수 있는 거버넌스 격차

엔지니어가 클라이언트 사이트의 코드를 초안 작성하기 위해 Copilot을 엽니다. 몇 초 만에 이전에 수작업으로 훨씬 오래 걸렸을 코드를 받아봅니다. 웹 개발자와 웹사이트 최적화를 추구하는 기업들에게는 다음과 같은 질문이 자연스럽습니다: 해당 코드가 신뢰할 수 있는가? 보안은 괜찮은가? 구현 전에 검토가 필요한가? 이러한 질문들은 모두 하나의 질문으로 모입니다: AI 지원 코딩에 대한 책임은 누가 질 것인가? 그리고 가장 중요한 것은, 생산성 향상의 소유자는 누구인가?

AI가 엔지니어링 팀이 동일한 시간 안에 더 많은 작업을 완료하도록 한다면, 그 경제적 가치로 모두가 더 큰 혜택을 누릴 수 있습니다. 이는 시간을 절약한 개발자, 절약된 시간을 통해 더 큰 가치를 얻는 고용주, 혹은 여유 시간을 가진 채 비용을 지불한 클라이언트가 될 수 있습니다. 절약된 시간이 어떻게 활용되든, 가장 중요한 것은 작업이 어떻게 관리되고 가격이 책정되는가입니다.

AI와 코딩은 피할 수 없게 되고 있다

AI 코딩 도구가 빠르게 주목받으며 주류 개발에 진입하고 있습니다. 2025 Stack Overflow 개발자 설문조사에 따르면, 응답자의 84%가 AI 도구를 사용 중이거나 사용 계획이 있다고 합니다.

AI를 웹 개발자들의 워크플로에 도입하는 것이 점점 일반화되고 있지만, 여전히 신뢰성에 대한 주저함이 있습니다. 같은 설문조사에서 46%는 AI 출력의 정확성에 완전한 신뢰를 갖지 못했으며, 약 66%는 “거의 맞지만 완벽하지 않은” AI 솔루션을 좌절의 원인으로 꼽았습니다.

형성되고 있는 AI 코딩 논쟁은 그 코드가 더 큰 가치를 창출하는가와 누가 그 가치를 보장할 책임이 있는가보다, 오히려 그 신뢰성에 관한 것입니다.

AI가 시간과 산출물 간의 관계를 깨뜨리고 있다

소프트웨어 개발 보상은 언제나 엔지니어링 산출물이 엔지니어링 노력과 밀접하게 연관되어 있다는 전제에 기반했습니다. 그러나 생성형 AI가 이 방정식을 복잡하게 만들고 있습니다.

95명의 개발자를 대상으로 한 통제 실험에서, GitHub Copilot에 접근 권한이 있는 참가자들이 특정 JavaScript HTTP 서버 작업을 접근 권한이 없는 경우보다 55.8% 더 빠르게 완료했다는 결과가 나왔습니다.

이는 AI가 개발 속도를 가속화할 수 있음을 보여주지만, 품질을 희생하지 않을 경우에만 해당됩니다. 다만 이 수치는 매우 구체적인 프로그래밍 작업에 한정된 실험이었으며, 작업이 더 빨리 완료되었다고 해서 Copilot이 전체 엔지니어링 조직을 55.8% 더 생산적으로 만든다는 의미는 아닙니다.

또 다른 연구는 이 개념을 입증합니다. 96명의 전일제 Google 소프트웨어 엔지니어를 대상으로 한 시험에서 AI를 활용한 개발자는 약 96분에 엔터프라이즈급 작업을 완료했으며, AI를 사용하지 않은 경우는 114분이 걸렸습니다. 연구진이 조정한 추정에 따르면 완료 시간이 약 21% 감소한 것으로 나타났습니다. 그러나 이 연구는 AI 코드의 품질을 조사하지 않았으며, 기술 의존성에 대한 형평성 문제도 다루지 않았습니다.

또한 METR이 수행한 무작위 연구에서는 16명의 숙련된 오픈소스 개발자가 잘 알고 있는 저장소에서 246개의 실제 이슈를 작업했습니다. 2025년 초에 사용 가능한 Claude Sonnet 3.5·3.7 및 Cursor Pro 등 도구를 활용했음에도 불구하고, 작업 완료 시간이 약 19% 더 오래 걸렸습니다. 이는 많은 사람들이 이러한 도구가 시간을 절약할 것이라 기대했음에도 불구하고 실제로는 오히려 지연을 초래했음을 보여줍니다.

이러한 연구들은 AI가 개발자를 더 빠르게 만든다는 기대를 뒤집습니다. 오히려 AI는 웹 작업을 제공하는 기업과 이를 받는 클라이언트 모두에게 개발자 시간과 가치의 예측 가능성을 낮추고 있습니다.

아무도 이야기하지 않는 가격 문제

Time & Material (T&M)은 소프트웨어 구매 시 흔히 사용되는 모델로, 반복되는 산업 문제인 “진행 중인 프로젝트”를 해결합니다.

이 모델에서는 모든 기능이나 작업을 개발 시작 전에 정의할 필요 없이, 프로젝트가 진행·변경되는 동안 클라이언트가 엔지니어링 시간을 지불할 수 있습니다.

하지만 AI는 검증된 이 모델에 문제점을 만들고 있습니다. 보상이 엔지니어링 시간에 직접 연결돼 있기 때문에, 개발 효율성이 높아지면 클라이언트에게 청구되는 시간이 줄어들게 됩니다. AI가 동일한 결과를 더 짧은 시간에 제공한다면 클라이언트에게는 가치가 창출되지만, 청구 가능한 시간이 감소하면 공급자에게는 수익이 감소합니다.

해결책은 개발자에게 작업을 더 천천히 하도록 장려하는 것이 아닙니다. T&M 모델은 이제 가격과 인센티브 설계 방식에서 구조적인 문제에 직면했습니다. 시간당 요금을 가치 판단에 사용하는 방식은 한계가 있습니다. 구매자는 각 엔지니어링 시간의 비용을 정확히 알면서도, 원하는 결과를 달성하기 위해 필요한 총 투자액에 대해서는 불확실성을 가질 수 있습니다.

AI가 엔지니어링 생산성을 바꾸면서 질문은 다음과 같이 변할 수 있습니다:

• “개발자 한 시간의 비용은 얼마인가?” → “개발자 시간이 줄어들 때 가치는 어떻게 변할까?”

METR 연구 결과는 이 질문을 복잡하게 만듭니다. 개발자들이 실제보다 시간을 절약하고 있다고 믿는다면, AI 도입이나 인식된 생산성 향상만으로는 재무적 가치를 입증하기에 충분하지 않습니다. 그래서 조직은 실제 발생한 일을 측정할 수 있는 거버넌스가 필요합니다.

거버넌스 격차에는 네 명의 주인이 있다

AI 지원 개발에 대한 거버넌스를 논의할 때는 개발자가 사용할 수 있는 도구를 규정하는 정책을 넘어서는 논의가 필요합니다.

엔지니어링 조직이 정의해야 할 소유권 유형은 최소 네 가지가 있습니다.

1. 코드의 소유자는 누구인가?

AI가 구현을 생성할 수는 있지만, 책임이 없는 개발을 정당화하는 변명이 될 수는 없습니다. 코드가 프로덕션 단계에 도달할 때까지 검토·테스트·승인에 대한 책임은 여전히 누군가에게 있어야 합니다.

2. 위험의 소유자는 누구인가?

더 빠른 코드는 다른 곳에서 문제가 발생하지 않을 때만 가치가 있습니다. AI 생성 코드에 대한 실증 연구에서는 조사된 Python 스니펫의 29.5%와 JavaScript 스니펫의 24.2%에서 보안 취약점이 발견되었으며, 43개의 Common Weakness Enumeration 카테고리에 걸친 약점도 확인되었습니다.

하지만 연구에 따르면 정적 분석 경고를 Copilot Chat에 다시 입력하면 식별된 보안 문제의 최대 55.5%를 해결할 수 있다고 합니다. 이 연구는 AI가 코딩 문제를 만들고 해결할 수 있음을 보여주지만, 조직은 AI 출력의 검증 방식을 정하는 프로세스를 갖추어야 합니다.

NIST의 SP 800-218A는 생성형 AI와 이중 사용 기반 모델을 다루는 모범 사례를 포함하도록 Secure Software Development Framework를 확장함으로써 이 원칙을 반영합니다.

3. 생산성 향상의 소유자는 누구인가?

초기부터 상업적 계약을 명확히 하는 것이 효율성 향상의 수혜자를 결정하는 데 필수적입니다. AI는 클라이언트가 비용을 절감하도록 돕거나, 팀이 더 많은 소프트웨어를 제공하도록 하거나, 프로젝트 종료 시 재정적 이익을 전혀 제공하지 않을 수도 있습니다.

변함없는 것은 투명한 프로세스와 품질·합의된 작업을 제공해야 한다는 요구입니다.

4. 우선순위 결정의 소유자는 누구인가?

AI가 기능을 더 저렴하고 빠르게 생성할 수는 있지만, 해당 기능이 실제로 필요하다는 판단은 할 수 없습니다.

실제로 개발 역량이 확대되면 우선순위 결정이 더욱 중요해질 수 있습니다. 팀이 더 빠르게 구축·실험할 수 있게 되면, 누군가는 사용 가능한 예산을 정당화하는 결과와 포기해야 할 아이디어를 결정해야 합니다.

AI 거버넌스가 재무 문제로 부상하고 있다

이러한 질문들은 AI 거버넌스를 점점 더 중요하게 만듭니다. 시간당 요금이 비슷한 두 개발 파트너를 상상해 보십시오.

한 파트너는 강력한 엔지니어링 프로세스에 AI를 통합해 요구 결과를 훨씬 빠르게 달성하는 반면, 다른 파트너는 더 오래 걸립니다. 단순히 시간당 요금만 비교한다고 해서 구매자는 그들의 프로세스에 대해 충분히 알 수 없습니다.

구매자는 다음을 평가해야 합니다:

• 예상 총 투자액
• 초과 비용에 대한 책임
• AI 생성 작업에 대한 품질 관리
• 효율성 향상의 공유 방식

양측이 서비스의 불확실성을 인지하고 수용한다면 T&M은 여전히 유용할 수 있습니다. 요구사항과 산출물이 안정적이라면 고정가격 계약도 작동합니다.

하지만 AI는 대안 구조를 검토할 가치도 제공합니다. 한 가지 접근 방식은 범위는 유연하게 유지하면서 최대 재정 한도를 설정하는 것입니다. 그런 다음 해당 모델 내에서 비즈니스 가치에 따라 기능을 우선순위화할 수 있습니다.

엔지니어링 효율성이 높아지면, 그 이득은 추가 청구 시간이 아니라 추가 제품 기능으로 전환될 수 있습니다. 상업적 인센티브는 엔지니어링 인센티브와 동일한 결과를 촉진하도록 설계되어, 가능한 한 효율적으로 더 유용한 소프트웨어를 만들도록 해야 합니다.

같은 AI 대화

엔지니어링 리더는 상업적 인센티브가 전달에 어떤 영향을 미치는지 이해해야 합니다. 재무·조달 팀은 AI 지원 엔지니어링이 주장된 효율성을 실제 측정 가능한 가치로 전환하고 있는지 충분히 파악할 필요가 있습니다.

즉, 성숙한 AI 거버넌스는 승인된 모델 목록, 보안 통제, 데이터 정책, 코드 리뷰 요구사항에 머물러서는 안 됩니다. 책임, 재무 위험, 우선순위 결정 및 생산성 향상 소유권을 다루어야 합니다.

하지만 기술 예산에 훨씬 큰 영향을 미칠 수 있는 두 번째 소유권 질문이 있습니다: AI가 소프트웨어 구축 속도를 바꿀 때 창출되거나 손실된 가치는 누가 소유하는가?

더 빠른 엔지니어링이 실제로 더 나은 제품을 만들고, 투자를 통제하며, 측정 가능한 비즈니스 성과를 달성하는지를 판단하는 조직이 경쟁자를 앞설 수 있을 것입니다.

내일 개발 팀이 AI를 도입한다면, 현재의 거버넌스와 상업 모델이 실제로 전달 가치를 높였는지 알려줄 수 있을까요?