AI 코딩 골드러시 속에서 경계심 유지하기: 생성에서 전달까지

현장에서 직접 발로 뛰는 개발자와 관리자로서, 우리는 리더십으로부터 어떤 요구를 받든 간에 AI가 생성한 자산(assets)을 배포할 때 이성의 목소리와 안정성을 대변해야 할 고객과 사용자에 대한 의무가 있습니다.

기업 환경에서 일해본 적이 없는 분들을 위해 말씀드리자면, "지표를 보고, 조정하고; 지표를 보고, 조정하는" 끊임없는 탱고는 중간 관리자(mid-level managers)와 디렉터(directors)인 우리가 견뎌내야 함과 동시에 팀원들을 위해 옹호해야 하는 끝없는 순환입니다. 이러한 지표들은 우리 개인의 성과와 팀의 성과에 관한 거의 모든 것을 분석하는 데 사용될 수 있습니다. 우리가 속한 조직이 더 크고 복잡해질수록, 맥락(context)과 인식(awareness, 애플리케이션 및 상황에 대한)은 대개 감소합니다. 이러한 인식은 기능을 전달하고 재무 및 속도(velocity) 목표를 달성하는 데 집중하는 것으로 대체됩니다.

🤔
아이러니한 점은 "맥락(context)"이 바로 품질 높은 AI 프롬프트(prompts)와 명령(commands)이 구축되는 핵심 기둥 중 하나라는 사실입니다. AI가 더 많이 알수록 결과는 더 좋아집니다.

여러분은 스스로에게 "어떤 지표를 말하는 거지?"라고 물을지도 모릅니다. 저는 생산성 지표(productivity metrics), DORA metrics, 더 구체적으로는 '생성된 코드 라인 수(lines of code generated)'를 말하고 있습니다. 작성된 코드 라인 수를 생산성과 동일시하는 것이 논리적으로 보일 것입니다, 그렇지 않나요? 더 많은 코드가 작성될수록 고객에게 더 많은 것이 전달되고, 이는 애플리케이션을 개선하며, 더 많은 기능을 판매할 수 있게 하여 더 많은 수익을 의미합니다. 다시 말하지만, 표면적으로는 이것이 타당해 보이며 제 경험상으로도 강조되어 온 지점이었습니다. 하지만 생각할수록, 우리가 AI를 통해 더 많은 코드를 작성한다고 해서 실제로 더 생산적인 것일까요? 저는 완전히 확신하지 못하겠습니다.

자세히 살펴보겠습니다.

짧은 이야기

최근 저는 AI 지표(metrics)와 그 활용을 주제로 한 일련의 경영 회의에 참석해 왔습니다. 어떤 모델이 어떤 상황에서 작동하는지, 그리고 토큰 소비량(token-spend) 등에 대한 논쟁이 포럼을 지배하고 있습니다. 아마 꽤 전형적인 "기업용 AI (corporate AI)" 회의일 것입니다. 하지만 한 가지 논의 사항이 계속해서 반복적으로 떠오르는 것 같습니다. 바로 사용량(usage)입니다. 각 회의에서 압도적으로 공통된 정서는 우리 에이전트(agents)들에 의해 생성되는 코드 라인이 끊임없이 증가하고 있다는 점입니다. 이 분석과 함께 따라오는 서사는 다음과 같습니다.

우리 팀은 그 어느 때보다 생산적입니다. 우리는 그 어느 때보다 더 많은 코드를 작성하고 있으며, 회사의 역사상 그 어느 때보다 더 많은 기능을 출시(shipping)하고 있습니다.

꽤 성공적이고 축하할 만한 결론처럼 들리지 않나요? 처음에는 저도 그렇게 생각했습니다. 코드는 애플리케이션을 작동하게 만들고, 함수(functions)는 기능을 만들며, 기능은 더 많은 돈을 의미합니다. 그러니 더 많은 코드는 분명 좋은 것이겠죠?

하지만 생각을 거듭할수록, 코드와 기능에는 다른 요소들도 포함된다는 것을 알게 되었습니다. 코드 리뷰(code reviews), 보안 감사(security audits), 단위 테스트(unit tests)와 같은 것들 말입니다. 기술적으로는 이러한 작업들을 수행하는 데 AI를 사용할 수 있지만, (단위 테스트를 제외하고는) 실제로 그렇게 해서는 안 됩니다. 이러한 작업들은 시간이 걸리며, 제대로 수행하려면 더 많은 시간이 필요하고, 프로세스에 여러 사람이 참여하게 되면 훨씬 더 많은 시간이 소요됩니다.

제가 그저 한 명의 관리자/개발자, 보잘것없는 한 명의 관리자/개발자일 뿐이라는 점을 알고 있습니다. 또한 저의 의견이 AI 효율성 논의라는 거대한 사막 속의 작은 모래알 하나에 불과하다는 점도 알고 있습니다. 하지만 소프트웨어 개발 관행에 AI를 도입하면서 나타나는 이러한 엄청난 (MASSIVE) 이득에 대해 회의적인 시각을 갖지 않을 수 없습니다.

더 많다고 해서 항상 더 나은 것은 아니다

작은 면책 조항을 덧붙이자면, 저는 귀하의 회사가 단위 테스트 (unit tests) 작성, 코드 리뷰 (code reviews) 수행 등과 같은 표준 개발 프로세스를 따르고 있다는 가정하에 제 논거의 대부분을 전개하고 있습니다. 만약 이러한 작업들을 수행하지 않고, 아주 작은 검토조차 없이 AI가 생성한 코드를 그대로 운영 환경 (production)에 배포하고 있다면, 행운을 빕니다. 데이터가 랜섬웨어에 감염되었을 때 좋은 보험을 들어두셨기를 바랍니다.

이제 계속해 보겠습니다.

우리가 코드를 빠르게 생성하기 위해 AI를 활용할 때, 그 속도와 정확성에 경외감을 느끼지 않기란 어렵습니다. 일부 매체는 개발자들이 생산성이 최대 55% 증가하고, 작업 리드 타임 (lead time)이 절반 가까이 단축되는 것을 경험하고 있다고 보고하고 있습니다. 대개의 경우, 생성된 코드는 상당히 정확하고 깔끔합니다. 특히 귀하의 에이전트 가이드라인 (agent guidelines)이 명확하고 실행 가능하다면 더욱 그렇습니다. 프롬프트 (prompt)를 입력하고 작동하는 결과물을 얻는 마법 같은 경험은 필연적으로 당신을 이러한 결과 중심적인 혼수상태로 빠뜨릴 것입니다. 저에게도 분명히 그러했습니다. 당신이 선택한 코딩 에이전트 (coding agent)가 제공하는 편리함과 안락함은, 평소 자신의 코드를 위해 따랐을 프로세스와 프로토콜(protocols)을 단순히 건너뛰게 만들기 매우 쉽습니다. 즉, 단위 테스트 (unit tests), 사용자 수용 테스트 (user-acceptance testing), 품질 보증 (quality assurance), 보안 분석 (security analysis) 등을 말이죠. 코드가 작동한다면, 왜 내가 그것을 수정해야 하며 왜 테스트를 해야 할까요?

"구조적 붕괴의 메커니즘 (mechanism of structural decay)"

AI와 함께 충분히 일해 보셨다면, '작성, 생성, 작성, 추가, 작성, 리팩터링 (refactor)'으로 이어지는 트렌드를 눈치채셨을 것입니다. 에이전트(agent)는 프롬프트에 대한 즉각적인 반응으로, 당신이 그것을 필요로 하든 아니든 코드를 작성하려 듭니다. GitClear와 Sonar가 인용한 연구에 따르면 다음과 같습니다:

5개 이상의 중복된 라인을 포함하는 코드 블록의 빈도가 8배 증가했으며, 이는 코드 재사용성 (code reuse)의 상당한 저하를 확인시켜 줍니다. 또한, 2024년은 복사/붙여넣기 된 라인의 수가 이동(리팩터링)된 라인의 수를 넘어선 첫 해였습니다.

이 놀라운 통계가 궁극적으로 가리키는 것은, 주니어 개발자 시절 우리에게 주입되었던 DRY (Do not Repeat Yourself, 반복하지 마라) 원칙을 저버리는, 끊임없이 커져만 가는 코드베이스입니다. 이는 또한 우리의 코드가 점점 더 커지고 있으며, 결과적으로 효율성과 장기적인 유지보수성 (maintainability)을 떨어뜨리고 있음을 의미합니다. Sonar의 기사에 담긴 이 문구는 이를 아름답게 표현하고 있습니다. "구조적 부채 (structural debt)는 LLM이 전역적인 아키텍처 일관성 (architectural coherence)과 장기적인 유지보수성보다 국소적인 기능적 정확성 (local functional correctness)을 우선시하기 때문에 발생합니다."
따라서 코드에 수많은 추가와 증강이 이루어지고 있음에도 불구하고, 우리는 상황을 악화시키고 있을 뿐이며, 결국 우리의 애플리케이션을 변동성 (volatility)의 구렁텅이로 몰아넣고 있는 것일지도 모릅니다.

끝없는 생산성을 대가로 치르는 불안정성

Google 2025 DORA Report에 따르면, Google의 연구진은 AI가 생성한 코드가 90% 증가함에 따라 보고된 버그(bug)는 9% 증가하고, 풀/머지 리퀘스트 (pull/merge request)의 크기는 150% 이상 증가했다는 사실을 발견했습니다. 이 수치들을 액면 그대로 받아들인다면, 여러분의 눈에 띄어야 할 몇 가지 중요한 사항들이 있습니다:

우리의 코드 베이스는 놀라운 속도로 성장하고 있습니다. 최근 저는 GitLab에서 388줄의 순수 신규 코드(변경이나 삭제가 아닌)가 포함된 머지 리퀘스트(merge request)를 검토했습니다. 이 머지 리퀘스트를 작성한 개발자가 일주일 동안 이런 작업을 네 번 더 한다고 가정해 봅시다. 한 달 동안, 이는 단 한 명의 개발자가 한 달 만에 프로젝트에 13,580줄의 순수 신규 코드를 도입하게 된다는 것을 의미합니다. 만약 그 정도 양의 새로운 코드가 그 속도로 작성되어 저장소(repository)에 머지되고 있다면, 저는 중복된 코드와 단순히 불필요한 코드의 양에 대해 진심으로 우려할 것입니다.

버그의 수도 함께 증가할 것입니다. 표면적으로는 보고된 버그가 9% 증가했다는 것이 많아 보일 수 있지만, 저는 실제로는 그보다 훨씬 더 심각하다고 믿습니다. 모든 개발자는 모든 버그가 동일하지 않다는 것을 알고 있습니다. 버그를 분석하고 문제를 해결(troubleshoot)하는 데는 시간이 필요하며, AI를 사용하든 사용하지 않든 수정하는 데는 훨씬 더 많은 시간이 걸립니다. 코드 베이스가 성장함에 따라, 버그를 방지하기 위해 얼마나 많은 테스트나 QA(Quality Assurance)를 수행하더라도 버그의 도입은 불가피합니다 (여러분의 회사 이름이 Linear가 아니라면 말이죠. 그들은 깔끔한 제품을 만드는 법을 알고 있습니다. 박수를 보냅니다). 하지만 이야기가 옆으로 샜군요.

위에서 사용했던 예시로 돌아가 봅시다. 머지 리퀘스트 3개당 1개의 버그가 도입된다고 가정해 보겠습니다. 여기에 추가로, 코드 5,000줄당 또 다른 버그가 하나씩 도입된다고 가정합니다. 이는 이 개발자의 AI 기반 생산성 속도를 유지할 때, 한 달 동안 우리 개발자가 약 8개의 버그를 도입하게 될 것임을 의미합니다. 앞서 암시했듯이, 이러한 문제들은 매우 단순할 수 있으며 여러분의 CI/CD 프로세스에 따라 몇 분 만에 해결책이 배포될 수도 있습니다. 별일 아니죠, 그렇죠? 하지만 이러한 문제 중 일부는 비즈니스에 진행 상황 손실과 매출 손실을 초래하는 치명적인 장애(outage)가 될 수 있으며, 이 모든 것이 단 한 명의 개발자로부터 시작될 수 있습니다.

🤨
위에서 사용한 수치들은 저나 제 팀의 실제 수치가 아님을 알아두시기 바랍니다. 이는 단지 예시일 뿐입니다.

이 코드는 테스트와 리뷰가 필요합니다. 만약 여러분이 전형적인 개발 프로세스를 따르고 있다면, 코드는 인간(QA)과 기계(자동화된 단위/기능 테스트) 모두에 의해 테스트되어야 한다는 사실에 아마 동의할 것입니다. 자동화된 테스트조차도 이 모든 과정에는 시간이 소요됩니다. 애플리케이션의 코드베이스 규모와 테스트 커버리지(Testing coverage)에 따라 이러한 테스트를 실행하는 데 시간이 걸립니다. 그리고 만약 전용 리소스에서 이러한 테스트를 실행한다면 비용도 발생합니다. 인간에 의한 코드 리뷰(Code reviews) 또한 비용이 듭니다. 그렇습니다, 다른 개발자가 코드를 리뷰하고, 테스트하고, 스모크 테스트(Smoke check)를 수행하는 데는 시간이 걸립니다. 여기에는 비용이 따릅니다. 하지만 사람들이 간과하는 점은, 해당 개발자가 코딩을 하지 않음으로써 상실되는 생산성입니다. 따라서 본질적으로, 모든 코드 리뷰는 동일한 시간 동안 개발자가 소모하는 비용의 두 배를 발생시킵니다.

제대로 수행하는 데 드는 비용

기술 및 소프트웨어 산업에 종사하는 우리라면 아마 다음과 같은 밈(Meme)을 알고 있을 것입니다: "좋은 것, 빠른 것, 저렴한 것 중 세 가지를 모두 가질 수는 없다." 품질과 속도는 비용을 수반합니다. 이는 테스트에도 적용되지만, AI가 생성한 코드의 경우에는 더욱 그러합니다.

A 2025년 연구에 따르면, 시니어 엔지니어들은 인간이 작성한 코드를 검토하는 데 평균 1.2분을 쓰는 반면, AI가 생성한 제안을 평가하는 데는 평균 4.3분을 소비하는 것으로 나타났습니다. 한편, AI에 크게 의존하는 팀들은 실질적으로 훨씬 더 많은 풀 리퀘스트(Pull requests, PR)를 제출하고 있습니다. Faros AI가 10,000명 이상의 개발자 데이터를 조사한 결과, PR 볼륨이 98% 증가한 것을 발견했습니다. 결과적으로 코드 생성 프로세스 자체는 빨라졌음에도 불구하고, PR 리뷰 시간은 91% 증가했습니다. Qodo 설문조사에 따르면, 시니어 엔지니어의 68%가 AI를 통해 품질이 향상되었다고 보고했지만, 리뷰 없이 AI 생성 코드를 배포하겠다고 답한 비율은 26%에 불과했습니다 (이 수치가 이렇게 높다는 것이 놀랍습니다).

그럼 이를 실제로 적용해 봅시다. 다음과 같은 시간당 급여를 받는 개발 팀이 있다고 가정해 보겠습니다:

• 주니어/중급 개발자 (Junior/intermediate developers): 시간당 약 $50 (또는 분당 $0.83)
• 중급 개발자 (Mid-level developers): 시간당 약 $100 (또는 분당 $1.67)
• 시니어/리드 개발자 또는 아키텍트 (Senior/lead developers or architects): 시간당 약 $180 (또는 분당 $3.00)

만약 이 개발자들이 자신의 시간당 급여를 기준으로 사람이 작성한 코드를 리뷰한다면 다음과 같은 비용이 발생합니다:

• 주니어/중급 개발자 (Junior/intermediate developers): 코드 리뷰당 약 $1
• 중급 개발자 (Mid-level developers): 코드 리뷰당 약 $2
• 시니어/리드 개발자 또는 아키텍트 (Senior/lead developers or architects): 코드 리뷰당 $3.60

만약 동일한 개발자들이 동일한 시간당 급여를 기준으로 AI가 작성한 코드를 리뷰한다면, 다음과 같은 비용이 발생합니다:

• 주니어/중급 개발자 (Junior/intermediate developers): 코드 리뷰당 약 $3.57
• 중급 개발자 (Mid-level developers): 코드 리뷰당 약 $7.01
• 시니어/리드 개발자 또는 아키텍트 (Senior/lead developers or architects): 코드 리뷰당 $15.48