요약 (TL;DR): 우리는 실험을 하려고 시작한 것이 아니었습니다. 6개월 동안 AI 에이전트가 우리 스프린트(sprint)의 더 많은 부분을 차지하게 되었고, 결국 우리 코드의 약 절반을 작성하게 되었습니다. 개발 속도(Velocity)는 올라갔습니다. 하지만 특정하고 예측 가능한 범주의 버그도 함께 늘어났습니다. 바로 기존의 리뷰 프로세스로는 잡아낼 수 없도록 교묘하게 틀린, 매우 확신에 찬 듯 보이는 코드들이었습니다. 해결책은 "AI를 덜 사용하는 것"이 아니었습니다. AI가 작성한 코드를 수용할지 말지가 아니라, 리뷰를 "어떻게" 할 것인지에 대한 방식을 재구축하는 것이었습니다.

이 포스트를 시작하게 된 수치

업계 전반적으로, GitHub 자체 연구에 따르면 Copilot 활성 사용자가 배포하는 코드의 약 46%가 AI의 도움을 받은 것이며, Google과 Microsoft는 실적 발표에서 내부 AI 생성 코드 비중이 20~30% 범위에 있다고 밝혔습니다. 우리가 자동 완성(autocomplete) 스타일의 제안에서 실제 에이전트 워크플로우(agentic workflows) — 즉, 최소한의 도움만으로 작업을 계획하고, 여러 파일에 걸쳐 코드를 작성하며, 테스트를 실행하고, PR(Pull Request)을 생성하는 도구 — 로 전환하자 우리의 수치는 그보다 더 높게 나타났습니다.

6개월이 지난 지금, 이는 일반적인 스프린트에서 병합(merged)된 라인의 거의 절반에 육박합니다. 이 포스트는 우리가 그 과정에서 배운 내용이며, 우리가 시작하기 전에 누군가 우리에게 써주었으면 좋았을 방식으로 작성되었습니다.

진정으로 개선된 점

먼저 공정하게 말하자면, 이곳의 대부분의 "AI 에이전트를 시도해 보았다"는 포스트들은 지나치게 열광하거나 혹은 지나치게 냉소적인 편인데, 둘 다 여러분에게는 유용하지 않습니다.

• 보일러플레이트 (Boilerplate) 및 스캐폴딩 (Scaffolding)의 시간 비용이 사실상 사라졌습니다. 새로운 CRUD 엔드포인트, 테스트 픽스처 (test fixtures), 마이그레이션 파일, 반복적인 설정 등 어차피 아무도 쓰고 싶어 하지 않는 작업들이 오후 내내 걸리던 대신 몇 분 만에 처리되었습니다.
• 초안 단계의 테스트 커버리지 (test coverage)가 낮아지기는커녕 오히려 높아졌습니다. 에이전트는 여러분이 피곤할 때 건너뛰기 쉬운 예외 경로 (unhappy-path) 테스트를 작성하는 데 매우 집요합니다. 다른 어떤 것을 변경하기도 전에 커버리지 수치가 개선되었습니다.
• 익숙하지 않은 코드베이스 부분에 새로운 엔지니어를 온보딩 (onboarding)하는 속도가 빨라졌습니다. 시니어 개발자를 붙잡고 늘어지는 대신, 에이전트에게 설명을 요구하고 실제 코드와 대조하여 설명을 검증할 수 있었기 때문입니다.
• 범위가 잘 정해진 작은 티켓의 첫 PR (Pull Request)까지 걸리는 시간이 눈에 띄게 단축되었습니다. 복잡한 작업에서는 극적인 변화가 없었지만, "이 필드를 추가하고 전체에 적용하라"와 같은 티켓에서는 실제로 반복 가능한 속도 향상이 나타났습니다.

이 중 어느 것도 더 이상 논쟁의 여지가 없습니다. 만약 여러분의 팀이 이 중 최소한 일부라도 경험하지 못하고 있다면, 그 격차는 도구의 문제가 아니라 대개 작업 선택이나 프롬프팅 (prompting) 규율의 문제입니다.

실제로 망가진 것, 그리고 그것은 우리가 예상했던 것이 아니었습니다

우리는 에이전트가 나쁜 코드를 작성할 것에 대비했습니다. 하지만 실제로 일어난 일은 그렇지 않았습니다. 일어난 일은 포착하기에 훨씬 더 나빴는데, 왜냐하면 그것이 맞아 보였기 때문입니다.

1. 정확해서가 아니라 유창하게 읽힌다는 이유로 리뷰를 통과하는 코드.
AI가 생성한 코드에는 특유의 질감이 있습니다. 깔끔한 명명 규칙 (naming), 일관된 스타일, 그럴듯해 보이는 로직 등은 리뷰어가 유능한 인간의 코드를 볼 때 사용하는 "이건 괜찮아 보이네"라는 패턴 매칭을 유발합니다. 우리는 미묘하게 잘못된 엣지 케이스 (edge-case) 처리가 통과되는 것을 보기 시작했는데, 이는 바로 평소의 "뭔가 이상한데"라는 직관을 자극하지 않았기 때문입니다. 2억 줄 이상의 코드를 분석한 GitClear의 분석에 따르면, 업계 전반에서 AI 도입과 함께 코드 턴 (code churn, 2주 이내에 되돌려지거나 다시 작성된 변경 사항)이 급격히 상승했으며, 이는 우리가 내부적으로 목격한 것과 거의 정확히 일치했습니다.

2. 리팩터링 (Refactoring)의 조용한 감소.
에이전트가 작동하는 버전을 몇 분 만에 다시 생성할 수 있게 되면, 근본적인 구조를 실제로 정리하려는 동기가 떨어집니다. 우리는 사람이 직접 작성했다면 순전히 짜증이 나서라도 하나의 함수로 통합했을 논리들이 여러 파일에 걸쳐 중복되어 쌓이고 있다는 사실을 발견했습니다. 에이전트는 짜증을 느끼지 않습니다.

3. 보안 검토 (Security review)가 이론이 아닌 실제 항목이 되었습니다.
에이전트 사용을 확장하기 전에 이 글을 읽는 누구에게라도 제가 가장 강력하게 경고하고 싶은 부분입니다. AI가 공동 작성한 풀 리퀘스트 (Pull Request, PR)에 대한 독립적인 분석 결과, 인간만 작성한 PR에 비해 취약점 발생률이 유의미하게 높다는 것이 밝혀졌습니다. 저희 팀이 특수한 사례라고 생각하지 않습니다. 대부분의 팀이 아직 이를 알아차릴 만큼 자세히 살펴보지 않았을 뿐이라고 생각합니다. 이제 우리는 인증 (Auth)이나 결제 (Payments) 관련 파일을 표시하는 것과 동일한 방식으로, "에이전트가 이 파일을 건드렸는가"를 보안 검토의 일상적인 플래그 (Flag)로 취급합니다.

4. 디버깅 (Debugging)이 "왜 망가졌는가"에서 "왜 이렇게 했는가"로 바뀌었습니다.
사람이 나쁜 코드를 작성할 때는 대개 그들의 논리를 추적할 수 있습니다. 하지만 에이전트가 잘못된 결과물을 만들어낼 때는, 에이전트가 "보고하는" 논리와 실제로 출력을 만들어낸 논리가 항상 일치하지는 않습니다. 이는 우리 대부분이 훈련받았던 것과는 진정으로 다른 디버깅 기술이며, 이를 구축하는 데에는 실제적인 시간이 필요했습니다.

우리가 구체적으로 변경한 사항

• PR(Pull Request)에 에이전트가 생성한 diff(차이점)의 비중만큼 라벨을 부여합니다. 이는 함정을 파기 위한 것이 아니라, 해당 PR에 어떤 종류의 리뷰가 필요한지를 결정하기 때문입니다.
• 인증(auth), 결제(payments), 또는 외부 데이터 경계(external data boundaries)를 건드리는 모든 작업은 에이전트가 유의미한 부분을 작성했을 경우 반드시 두 번째 인간 리뷰어를 배정합니다. 코드가 아무리 완벽해 보이더라도 예외는 없습니다.
• 성공 지표로서 "주당 배포 라인 수(lines shipped per week)"를 측정하는 것을 중단했습니다. 이 지표는 은연중에 더 적은 검토로 더 많은 에이전트 결과물을 수용하도록 보상하고 있었으며, 이는 정확히 잘못된 인센티브였습니다.
• 리팩터링(Refactoring)은 기회주의적으로 수행하는 대신 보호된 시간대를 할당받게 되었습니다. 기회주의적인 리팩터링은 대부분 스스로 일어나지 않게 되었기 때문입니다.

이로 인해 우리가 처한 상황

우리는 이 중 그 어떤 것도 되돌리지 않을 것입니다. 생산성 측면의 이점은 실재하며, 우리는 단순히 보여주기식의 AI 회의론에 관심이 없습니다. 하지만 "이제 AI가 우리 코드를 작성한다"는 부분은 쉬운 부분이었음이 드러났습니다. 실제 작업은 빠르게 작성하고, 자신 있게 작성하며, 지치거나 당황하지 않는 기여자(contributor)를 중심으로 리뷰, 보안 심사, 그리고 코드 건강성(code-health) 습관을 재구축하는 것이었습니다. 그런데 알고 보니, 이러한 특성들은 바로 우리의 기존 리뷰 프로세스가 은연중에 의존하고 있었던 인간적 특성들이었습니다.

저는 6senseHQ에서 엔지니어링을 총괄하고 있으며, 이곳에서 이것은 이제 고객을 위해 제품을 만드는 방식 그 자체입니다. 즉, 에이전트의 도움을 받고, 인간이 소유하며, 마치 중요한 것처럼 리뷰하는 방식입니다. 왜냐하면 그것은 실제로 중요하기 때문입니다.

FAQ

AI 코딩 에이전트를 사용하는 것이 실제로 배포 속도를 높여주나요?
네, 범위가 잘 정해져 있고 상용구 코드(boilerplate)가 많은 작업에서는 유의미하게 그렇습니다. 복잡하거나 모호한 작업에서는 이득이 줄어들거나 때로는 사라지는데, 이는 병목 현상이 타이핑이 아닌 리뷰와 검증(verification)으로 이동하기 때문입니다.

AI가 생성한 코드는 기본적으로 보안에 취약한가요?
AI가 공동 작성한 PR(Pull Request)에 대한 독립적인 연구에 따르면, 인간만 작성한 PR보다 취약점 발생률이 더 높은 것으로 나타났습니다. 다만, 에이전트의 결과물에 특화된 의도적인 리뷰 관행을 적용할 경우 그 격차는 상당히 줄어듭니다.

AI 에이전트를 도입하는 팀을 위해 가장 영향력이 큰 단 하나의 프로세스 변화는 무엇일까요?
에이전트가 작성한 코드를 사람이 작성한 코드와 동일한 방식으로 리뷰하는 것을 중단하십시오. 실패 모드 (Failure modes)가 다르며, 인간의 실수를 잡아내도록 조정된 리뷰 프로세스는 에이전트가 저지르는 실수를 체계적으로 놓치게 될 것입니다.

만약 여러분이 개발 팀의 AI 보조 (AI-assisted) 관행을 검증하고 있다면, 무엇이 더 빨라졌는지가 아니라 무엇이 망가졌는지를 물어보십시오. 속도 향상에 대해서는 누구나 말할 수 있습니다. 채용할 가치가 있는 팀은 무엇이 잘못되었는지에 따라 리뷰 과정에서 구체적으로 무엇을 변경했는지 말할 수 있습니다.