AI 에이전트, 코딩 생산성 80%는 혁신! 하지만 20%의 '치명적 침묵'이 시니어를 부른다

저희는 AI 에이전트들을 실시간 결제 플랫폼에 전격 도입했습니다. 결과는 놀라웠죠. 자잘하고 반복적인 작업은 정말이지 눈 깜짝할 새 처리해 버리는 겁니다. 하지만 진짜 중요한 부분, 즉 돈이 오가는 핵심 로직에서는 아무도 모르게 치명적인 구멍을 만들더군요.

지난주에 흥미로운 설문조사 결과가 나왔습니다. 전체 코드의 54%가 이제 AI로 생성된다는 내용이었죠. 작년 28%에서 엄청나게 증가한 수치입니다. 이 숫자를 보면서 '음, 충분히 그럴 수 있겠다' 싶었습니다. 우리 회사 역시 비슷한 수준에 와있을 겁니다.

하지만 아무도 묻지 않는 중요한 질문이 있습니다. '대체 어떤 54%의 코드란 말인가?' 모든 코드가 똑같은 중요성을 지니는 건 아니거든요. 가령, 판매자(merchant) 정보를 불러오는 간단한 CRUD API 엔드포인트는 리스크가 낮습니다. 하지만 결제 상태를 pending에서 complete로 전환하는 웹훅(webhook) 핸들러는 어떤가요? 그건 누군가의 월세이자, 누군가의 월급입니다. 여기서 단 한 줄이라도 잘못되면, 돈이 엉뚱한 곳으로 가거나, 최악의 경우 아예 움직이지 않게 되는 심각한 결과로 이어지죠.

저는 FCA(영국 금융감독청)의 승인을 받아 실제 돈을 다루고, 실제 판매자들이 이용하며, 실제 결과가 따르는 결제 플랫폼의 CTO입니다. NestJS 마이크로서비스, Docker, Traefik 등 흔히 볼 수 있는 스택을 사용하고 있고요. 지난 1년 넘게 AI 에이전트를 아주 적극적으로 활용해왔습니다.

제가 AI가 위험하다고 말하려는 게 아닙니다. 전혀 그렇지 않아요.

다만, AI가 진정으로 잘하는 게 무엇인지 잊어버릴 때 비로소 위험해진다는 점을 말씀드리고 싶습니다.

AI 에이전트가 정말 뛰어난 80%의 영역

칭찬할 부분은 확실히 칭찬해야죠. AI 에이전트 덕분에 우리 팀은 2년 전만 해도 상상하기 어려웠던 방식으로 훨씬 빨라졌습니다.

API 스캐폴딩, 서비스 보일러플레이트 생성, Zod 유효성 검사 스키마 작성, 새로운 엔드포인트 구현, 테스트 스텁(stub) 생성, 임포트(import) 리팩토링, 레포지토리 간 패턴 마이그레이션 등등.

저희는 여러 마이크로서비스를 운영합니다. 새로운 서비스가 필요할 때, 에이전트는 모듈 구조, 기본 설정, Docker 환경, Traefik 레이블까지 전체를 단 몇 분 만에 스캐폴딩해줍니다. 과거에는 반나절 동안 복사-붙여넣기-수정을 반복하던 일이 이제는 몇 마디 대화로 끝나는 거죠.

모든 레포지토리의 환경 변수(env) 관리를 전면 개편했을 때도 AI 에이전트가 모든 잡무를 처리했습니다. 모든 .env 파일을 매핑하고, 이름 충돌을 찾아내고, 공통 변수를 식별해서 통합된 Zod 스키마를 생성해냈죠. 팀 전체가 며칠 동안 grep 명령과 스프레드시트를 붙잡고 씨름했을 작업이 고작 몇 시간 만에 마무리된 겁니다.

코드베이스의 이 80% – 예측 가능하고, 패턴을 따르며, 구조적으로 반복적인 코드 – 에서 AI 에이전트는 돈으로 살 수 있는 최고의 주니어 개발자입니다. 지칠 줄 모르고, 저렴하며, 자아가 없죠. 잘하는 일에서는 거의 실수를 저지르지 않습니다.

마치 당신의 터미널에 수많은 주니어 개발자가 앉아있는 것과 같습니다.

그리고 마주하는 나머지 20%

여기서부터 이야기가 흥미로워집니다.

AI 에이전트에게 웹훅 핸들러를 구축하도록 했습니다. 결제 시스템에서 웹훅은 매우 중요합니다. 결제가 성공했는지, 실패했는지, 아니면 주의가 필요한지 알려주는 통로니까요. 에이전트는 핸들러를 작성했고, 코드는 깔끔해 보였습니다. 테스트도 통과했죠.

하지만 에이전트는 예외 상황(edge cases)을 소리 없이 무시했습니다.

결제 상태 전환에는 엄격한 규칙이 있습니다. pending에서 complete로 갈 수는 있지만, complete에서 pending으로 돌아갈 수는 없습니다. 인간 개발자가 이 부분을 만들 때는 불가능한 전환을 항상 고려합니다. 돈이 역방향으로 움직였을 때 어떤 일이 벌어지는지 직접 겪어봤기 때문이죠. 그런 고통을 경험했기에 방어 로직을 구축하는 겁니다.

에이전트는 그런 점에는 전혀 관심이 없었습니다. '행복한 경로(happy path)'는 아름답게 구현했지만, 예외 상황은 존재하지 않는 것처럼 다뤘습니다.

이런 작업을 수동으로 할 때는 이런 종류의 오류가 절대로 발생하지 않습니다. 결제 시스템에서 수년간 일해온 시니어 개발자는 불가능한 전환을 잊지 않습니다. 코드가 아니라, 그들의 뼛속에 새겨져 있는 지식이죠. 제가 예전에 유사한 결제 시스템을 개발할 때, 이런 '발생해서는 안 되는' 트랜잭션을 막기 위해 밤새도록 로직을 고민했던 기억이 납니다. AI는 아직 그런 인간적인 '고통'에서 오는 통찰력은 없는 것 같아요.

제가 계속해서 발견하는 패턴

이건 단순한 우연이 아닙니다. 규제된 결제 스택에서 AI 에이전트와 수개월간 작업하면서 일관된 패턴 하나를 발견했습니다.

AI 에이전트는 정확성(correctness)보다는 완료(completion)에 최적화되어 있습니다.

그들은 기능을 빨리 끝내고 싶어 합니다. 초록색 체크마크를 보고 싶어 하죠. 그리고 효율적으로 목표에 도달하기 위해, 겉보기에는 합리적인 지름길을 택합니다.

에이전트는 무엇이 되어야 하는지를 만듭니다. 무엇이 되어서는 안 되는지는 거의 만들지 않아요. 결제 시스템에서는 모든 실제 위험이 바로 이 부정적인 케이스에 도사리고 있습니다. 웹훅이 두 번 도착하면 어떻게 될까요? 이미 환불된 거래에 대해 환불 요청이 오면 어떻게 될까요? 은행이 예상치 못한 상태 코드를 반환하면 어떻게 될까요? 에이전트는 명시적으로 지시하지 않는 한 이 중 어떤 것도 생각하지 않습니다.

그리고 재사용성 문제도 있습니다. 저희는 공유 유틸리티 패키지, 헬퍼 함수, 팀이 수년간 표준화한 공통 패턴들을 가지고 있습니다. 에이전트는 이런 것들에 전혀 신경 쓰지 않습니다. 대신 처음부터 자신만의 버전을 작성하죠. 작동은 하지만, 이제 똑같은 로직에 대한 두 가지 구현이 생기는 겁니다. 하나는 프로덕션에서 테스트되고 신뢰받는 버전, 다른 하나는 새로 생성되었고 아직 검증되지 않은 버전. 에이전트는 이 기능을 완료하는 데 집중할 뿐, 아키텍처를 유지보수하는 데는 관심이 없습니다. 실제로 저희 팀에서도 AI가 생성한 코드를 검토하다 보면, 기존에 잘 만들어둔 공통 유틸리티를 무시하고 새로 구현한 사례를 종종 발견합니다. 당장 기능은 돌아가지만, 장기적인 유지보수 관점에서는 두통이죠.

그리고 가장 미묘한 문제 — 에이전트는 왕복(back-and-forth) 횟수를 줄이는 데 최적화된 것처럼 보입니다. 비용과 컨텍스트를 절약하는 것처럼 말이죠. 복잡한 유효성 검사? 그냥 건너뛰고 기본 케이스만 처리합니다. 희귀한 예외 상황에 대한 오류 처리? 토큰 낭비일 뿐입니다. 그 결과는 우리가 작성한 모든 테스트는 통과하지만, 우리가 미처 생각하지 못한 시나리오에서는 실패하는 코드입니다. 에이전트 역시 그 시나리오를 생각하지 못했기 때문이죠.

주니어는 '제품'을 출시하지 않습니다. 그들은 '코드'를 작성하죠.

이 부분이 저에게 큰 깨달음을 주었습니다.

클로드(Claude)든 어떤 코딩 에이전트든, 돈으로 살 수 있는 최고의 주니어 개발자입니다. 지칠 줄 모르고, 저렴하며, 자아가 없고, 반복적인 작업에서는 거의 오류가 없는 수많은 주니어 개발자 군단이죠.

하지만 주니어는 '제품'을 출시하지 않습니다. 그들은 '코드'를 작성하죠.

코드와 제품의 차이는 '판단력'입니다. 어떤 전환이 불가능한지 아는 것. 재시도(retry) 로직에 특정 백오프(backoff) 곡선이 필요한 이유를, 그렇지 않았을 때 어떤 일이 벌어지는지 직접 겪어봤기에 아는 것. 웹훅 핸들러에 멱등성(idempotency)이 필요한 이유를, 은행이 때때로 같은 알림을 세 번 보내기도 한다는 것을 아는 것.

이런 지식은 훈련 데이터에서 오는 것이 아닙니다. 시스템을 수년간 운영하고, 새벽 2시에 디버깅하고, 판매자에게 왜 정산이 지연되었는지 설명하면서 얻는 겁니다.

2026년에 CTO가 저지를 가장 위험한 실수는 시니어 엔지니어를 AI로 대체하려는 시도입니다. 올바른 방법은 시니어 엔지니어가 AI를 활용하도록 돕는 것입니다.

시니어를 AI로 대체한다고요? 속도는 얻겠지만 조용한 재앙도 함께 얻게 될 겁니다.

시니어를 AI로 지원한다고요? 당신은 자신의 군대를 거느린 아키텍트를 얻게 될 것입니다.

그래서 우리는 어떻게 대처하고 있는가

제가 AI에 대해 불평하려고 이 글을 쓰는 게 아닙니다. 우리가 효과적인 시스템을 구축했고, 이것이 여러분에게도 도움이 될 수 있기에 공유하는 것입니다.

가장 먼저 한 일은 저희 아키텍처를 '기계가 읽을 수 있도록' 만드는 것이었습니다. 우리는 디자인 패턴과 아키텍처 규칙을 에이전트가 이해할 수 있는 형식으로 추출합니다. 에이전트가 우리 코드베이스에서 작업할 때, 단순히 코드만 보는 것이 아니라 경계, 패턴, 무엇이 어디에 속해야 하는지에 대한 규칙을 함께 보게 됩니다. 아무도 읽지 않는 문서가 아닙니다. 에이전트가 무시할 수 없는 린트(lint)와 제약 조건인 셈이죠.

다음으로, 우리는 부정적인 케이스(negative cases)를 테스트하는 데 막대한 투자를 했습니다. 모든 PR — 인간이 만들었든 AI가 만들었든 — 동일한 테스트 스위트를 거칩니다. 하지만 우리는 에이전트가 건너뛰는 부분들을 위해 특별히 테스트를 구축했습니다. 불법적인 상태 전환, 중복 웹훅 처리, 멱등성 검사 등이 그것이죠. 에이전트가 음성 케이스를 조용히 누락해도, 코드가 배포되기 전에 테스트가 이를 잡아냅니다.

그리고 시니어 개발자들은 여전히 돈과 관련된 모든 것을 검토합니다. AI가 생성한 결제 로직은 시니어의 검토 없이는 배포되지 않습니다. AI를 믿지 못해서가 아니라, AI의 맹점이 정확히 어디에 있는지 우리가 알기 때문입니다. 이 검토는 문법을 확인하는 것이 아닙니다. '판단력'을 확인하는 겁니다. 에이전트가 모호한 은행 상태를 처리했는가? 우리의 기존 재시도 로직을 존중했는가? 공유 유틸리티를 사용했는가, 아니면 바퀴를 재발명했는가?

이 문제는 저에게 너무 중요해서 Bodhi Orchard라는 오픈소스 에이전틱 개발 프레임워크를 만들기 시작했습니다. 핵심 아이디어는 이렇습니다. 에이전트가 단순히 코드를 작성하게 두지 마세요. 아키텍처, 디자인 패턴, 테스트 계획, 기존 유틸리티 등 전체 맥락을 제공하여, 똑같은 맹점 실수를 반복하지 않도록 하는 겁니다. 인간의 바쁜 작업 대신 인간의 판단력이, 그리고 품질을 실제로 강제하는 안전장치가 필요한 거죠.

2026년을 위한 진짜 질문

설문조사에 따르면 코드의 54%가 AI로 생성됩니다. 저는 이 말을 믿습니다.

하지만 저의 질문은 이겁니다. 2026년에 버그의 몇 퍼센트가 AI로 생성될까요?

그리고 더 중요한 것은 — 누가 그 버그들을 찾아낼까요?

에이전트는 아닙니다. 그들이 버그를 처음 만들었을 테니까요. 주니어 개발자도 아닙니다. 무엇이 누락되었는지 알아챌 만큼 충분한 지식이 없을 겁니다.

결국 시니어 개발자들이 찾아낼 겁니다. 아키텍트들. 시스템을 오랫동안 운영하여 어디에 시체가 묻혀 있는지 아는 사람들이죠.

80%의 문제는 해결되었습니다. AI가 이겼죠. 축하할 일입니다.

이제 나머지 20%를 이해하는 인간에게 투자하세요. 왜냐하면 당신의 제품은 그 20%에서 살고 죽기 때문입니다.

저는 Atoa의 CTO이자 공동 창업자 Arun입니다. Atoa는 영국 오픈 뱅킹 결제 플랫폼입니다. 저는 컨퍼런스 슬라이드에 나오는 내용이 아니라, AI로 핀테크를 실제로 구축하는 경험에 대해 글을 씁니다. 이 글이 공감되셨다면, 여기서 저를 팔로우하거나 X @mickyarun에서 저를 팔로우해주세요.

그리고 적절한 안전장치를 갖춘 AI-네이티브 개발 구축에 관심이 있다면 Bodhi Orchard를 확인해보세요.

원문: https://dev.to/mickyarun/ai-agents-are-great-at-80-of-our-code-the-other-20-is-why-we-still-need-seniors-3lh5 수집일: 2026-05-29 01:57:18