AI 에이전트는 우리 코드의 80%를 훌륭하게 처리합니다. 나머지 20%가 우리가 여전히 시니어 개발자를 필요로 하는 이유입니다.

우리는 결제 플랫폼에 AI 에이전트를 풀어놓았습니다. 그들은 지루한 작업들을 완벽하게 해냈습니다. 그러더니 중요한 부분들을 조용히 망가뜨려 놓았습니다.

지난주에 한 설문조사 결과가 발표되었습니다. 현재 모든 코드의 54%가 AI에 의해 생성됩니다. 작년의 28%에서 상승한 수치입니다.

나는 그 숫자를 읽고 생각했습니다. '그래, 일리가 있네. 우리도 아마 그 범위 안에 있을 거야.'

하지만 여기서 아무도 묻지 않는 문제가 있습니다. 바로 '어느 54%인가?' 하는 점입니다.

모든 코드가 동일한 비중을 갖는 것은 아닙니다. 가맹점 상세 정보를 가져오는 CRUD 엔드포인트(CRUD endpoint)? 리스크가 낮습니다. 결제를 pending(대기) 상태에서 complete(완료) 상태로 전환하는 웹훅 핸들러(webhook handler)? 그것은 누군가의 월세입니다. 누군가의 급여입니다. 그것을 잘못 처리하면 돈이 엉뚱한 곳으로 움직이거나, 더 나쁘게는 돈이 전혀 움직이지 않게 됩니다.

나는 결제 플랫폼의 CTO입니다. FCA(영국 금융감독청)의 승인을 받았으며, 실제 돈과 실제 가맹점을 처리하며, 실제적인 결과(consequences)를 수반합니다. 우리는 NestJS 마이크로서비스(microservices), Docker, Traefik 등 일반적인 스택을 운영하고 있습니다. 그리고 우리는 1년 넘게 AI 에이전트를 공격적으로 사용해 왔습니다.

나는 AI가 위험하다고 말하러 여기 온 것이 아닙니다. 그렇지 않습니다.

나는 AI가 실제로 무엇을 잘하는지 잊어버릴 때 위험해진다는 사실을 말하러 왔습니다.

AI 에이전트가 진정으로 탁월한 80%의 영역

공정하게 평가해 보겠습니다. AI 에이전트는 2년 전만 해도 터무니없어 보였을 방식으로 우리 팀의 속도를 높여주었습니다.

API 스캐폴딩(scaffolding). 서비스 보일러플레이트(boilerplate) 생성. Zod 검증 스키마(validation schemas) 작성. 새로운 엔드포인트 구축. 테스트 스텁(test stubs) 생성. 임포트(imports) 리팩토링. 리포지토리(repos) 전반에 걸친 패턴 마이그레이션(migrating).

우리는 여러 개의 마이크로서비스를 운영합니다. 새로운 서비스가 필요할 때, 에이전트는 모듈 구조, 기본 설정, Docker 설정, Traefik 레이블 등을 포함한 전체 스캐폴딩을 몇 분 만에 완료할 수 있습니다. 예전에는 반나절 동안 복사해서 붙여넣고 수정해야 했던 작업이 이제는 대화 한 번으로 끝납니다.

모든 리포지토리에 걸쳐 환경 변수(env) 관리 방식을 전면 개편했을 때, AI 에이전트가 힘든 작업(grunt work)을 수행했습니다. 에이전트들은 모든 .env 파일을 매핑하고, 명명 충돌을 찾아내고, 공통 변수를 식별하며, 통합된 Zod 스키마를 생성했습니다. 팀이 며칠 동안 grep 명령어를 쓰고 스프레드시트를 붙잡고 씨름해야 했을 작업이 단 몇 시간 만에 끝났습니다.

이 코드베이스의 80% — 즉, 예측 가능하고, 패턴을 따르며, 구조적으로 반복되는 코드 — 에 있어서 AI 에이전트는 돈으로 살 수 있는 최고의 주니어 개발자입니다. 지치지 않고, 저렴하며, 자존심도 없습니다. 자신들이 잘하는 분야에서는 거의 실수를 하지 않습니다.

당신의 터미널에 앉아 있는 주니어 군단과 같습니다.

그리고 나머지 20%에 부딪혔을 때

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

우리는 에이전트에게 웹훅 핸들러 (webhook handler)를 구축하도록 시켰습니다. 결제 시스템에서 웹훅 (webhooks)은 매우 중요합니다. 결제가 성공했는지, 실패했는지, 혹은 주의가 필요한지를 알 수 있는 방법이기 때문입니다. 에이전트는 핸들러를 작성했습니다. 코드는 깔끔해 보였고, 테스트도 통과했습니다.

하지만 에이전트는 엣지 케이스 (edge cases)를 조용히 무시했습니다.

상태 전이 (Status transitions)에는 규칙이 있습니다. 결제는 pending에서 complete로 갈 수 있습니다. 하지만 complete에서 다시 pending으로 돌아갈 수는 없습니다. 인간 개발자가 이를 구축할 때는 불가능한 전이에 대해 생각합니다. 돈이 거꾸로 움직일 때 어떤 일이 발생하는지 이미 경험해 보았기 때문입니다. 그들은 그것이 없을 때 겪게 될 고통을 알기에 방어 기제 (guard)를 구축합니다.

에이전트는 그런 것에 신경 쓰지 않았습니다. 에이전트는 해피 패스 (happy path)를 아름답게 구축했지만, 엣지 케이스는 존재하지 않는 것처럼 취급했습니다.

우리가 이 작업을 수동으로 할 때는 이런 종류의 오류가 절대 발생하지 않습니다. 결제 분야에서 수년간 일한 시니어 개발자는 불가능한 전이를 잊지 않습니다. 그것은 코드에 적혀 있는 것이 아니라, 그들의 뼈에 새겨져 있습니다.

내가 계속 목격하는 패턴

이것은 일회성 사건이 아닙니다. 규제 대상인 결제 스택 (payment stack)에서 AI 에이전트와 수개월 동안 작업한 결과, 한 가지 일관된 패턴이 나타났습니다.

AI 에이전트는 정확성 (correctness)이 아니라 완료 (completion)를 위해 최적화합니다.

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

에이전트는 일어나야 할 일을 구축합니다. 일어나지 말아야 할 일을 구축하는 경우는 드뭅니다. 결제 (Payments) 분야에서 실제 모든 리스크가 존재하는 곳은 바로 부정적인 케이스 (Negative cases)입니다. 웹훅 (Webhook)이 두 번 도착하면 어떻게 될까요? 이미 환불된 트랜잭션 (Transaction)에 대해 환불 요청이 들어오면 어떻게 될까요? 은행이 예상치 못한 상태 코드 (Status code)를 반환하면 어떻게 될까요? 당신이 명시적으로 지시하지 않는 한, 에이전트는 이 중 그 어떤 것도 생각하지 않습니다.

다음은 재사용성 (Reusability) 문제입니다. 우리에게는 공유 유틸리티 패키지 (Shared utility packages), 헬퍼 함수 (Helper functions), 그리고 팀이 수년간 표준화해 온 공통 패턴 (Common patterns)이 있습니다. 에이전트는 이에 신경 쓰지 않습니다. 에이전트는 자신만의 버전을 처음부터 새로 작성합니다. 작동은 하겠지만, 이제 당신은 동일한 로직에 대해 두 가지 구현체를 갖게 됩니다. 하나는 프로덕션 (Production) 환경에서 테스트되고 신뢰할 수 있는 것이고, 다른 하나는 갓 생성되어 테스트되지 않은 것입니다. 에이전트는 아키텍처 (Architecture)를 유지하는 것이 아니라, '이' 기능을 완료하는 데만 집중합니다.

그리고 가장 미묘한 문제 — 에이전트는 주고받는 대화 횟수 (Back-and-forth turns)를 줄이는 방향으로 최적화하는 것처럼 보입니다. 비용을 아끼고 컨텍스트 (Context)를 절약하는 것처럼 보이죠. 복잡한 검증 (Validation)? 건너뜁니다. 기본 케이스가 작동하니까요. 드문 엣지 케이스 (Edge case)에 대한 에러 핸들링 (Error handling)? 토큰 (Tokens)을 쓸 가치가 없다고 판단합니다. 그 결과, 당신이 작성한 모든 테스트는 통과하지만 당신이 테스트할 생각을 하지 못했던 시나리오에서는 실패하는 코드가 만들어집니다. 왜냐하면 그 시나리오들이 바로 에이전트 역시 생각하지 못한 시나리오들이기 때문입니다.

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

이 사실을 깨닫게 해준 프레임워크가 있습니다.

Claude — 또는 그 어떤 코딩 에이전트라도 — 돈으로 살 수 있는 최고의 주니어 개발자입니다. 주니어들의 군단이죠. 지치지 않고, 저렴하며, 자아(Ego)가 없고, 일상적인 업무에 대해서는 에러율이 거의 제로에 가깝습니다.

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

코드와 제품의 차이는 판단력 (Judgment)입니다. 어떤 전이 (Transitions)가 불법인지 아는 것. 재시도 로직 (Retry logic)이 특정 백오프 곡선 (Backoff curve)을 가져야 한다는 것을 아는 것 — 왜냐하면 그렇지 않았을 때 어떤 일이 벌어지는지 직접 겪어봤기 때문입니다. 웹훅 핸들러 (Webhook handler)에 멱등성 (Idempotency)이 필요하다는 것을 아는 것 — 왜냐하면 은행이 가끔 동일한 알림을 세 번씩 보내기도 하기 때문입니다.

그러한 지식은 학습 데이터 (Training data)에서 오는 것이 아닙니다. 그것은 수년간 시스템을 운영하고, 새벽 2시에 디버깅(Debugging)을 하며, 가맹점에게 왜 정산이 지연되었는지 설명하는 과정에서 얻어지는 것입니다.

2026년에 CTO가 저지를 수 있는 가장 위험한 실수는 시니어 엔지니어를 대체하기 위해 AI를 도입하는 것입니다. 올바른 선택은 그들을 지원(Enable)하기 위해 AI를 도입하는 것입니다.

시니어를 AI로 대체한다고요? 속도와 함께 조용한 재앙을 얻게 될 것입니다.

시니어를 AI로 지원한다고요? 군대를 거느린 아키텍트(Architect)를 얻게 될 것입니다.

우리가 실제로 하고 있는 일

저는 AI에 대해 불평하려고 이 글을 쓰는 것이 아닙니다. 우리가 실제로 작동하는 시스템을 구축했기 때문에, 이 글이 여러분에게도 도움이 될 수 있다고 생각하여 쓰고 있습니다.

우리가 가장 먼저 한 일은 우리의 아키텍처 (Architecture)를 기계가 읽을 수 있는 형태 (Machine-readable)로 만드는 것이었습니다. 우리는 디자인 패턴 (Design patterns)과 아키텍처 규칙을 에이전트 (Agent)가 소비할 수 있는 형식으로 추출합니다. 에이전트가 우리의 코드베이스 (Codebase)에서 작업할 때, 에이전트는 단순히 코드만 보는 것이 아닙니다. 에이전트는 경계 (Boundaries), 패턴 (Patterns), 그리고 무엇이 어디에 속해야 하는지에 대한 규칙을 봅니다. 아무도 읽지 않는 문서가 아니라, 에이전트가 무시할 수 없는 린트 (Lints)와 제약 조건 (Constraints)을 보는 것입니다.

그다음 우리는 부정적인 케이스 (Negative cases)를 테스트하는 데 집중적으로 투자했습니다. 사람의 작업이든 AI의 작업이든, 모든 PR (Pull Request)은 동일한 테스트 스위트 (Test suite)를 거칩니다. 하지만 우리는 에이전트가 건너뛰기 쉬운 항목들, 즉 잘못된 상태 전이 (Illegal state transitions), 중복 웹훅 처리 (Duplicate webhook handling), 멱등성 (Idempotency) 체크 등을 위해 테스트를 특별히 구축했습니다. 만약 에이전트가 부정적인 케이스를 조용히 누락시킨다면, 테스트가 배포 (Ship)되기 전에 이를 잡아냅니다.

그리고 시니어들은 여전히 돈과 관련된 모든 것을 검토합니다. AI가 생성한 결제 로직은 시니어가 확인하지 않고는 절대 배포되지 않습니다. 이는 우리가 AI를 신뢰하지 않아서가 아니라, AI가 어디에서 눈이 먼 상태인지 정확히 알고 있기 때문입니다. 리뷰 (Review)는 구문 (Syntax)을 확인하는 것이 아닙니다. 판단력 (Judgment)을 확인하는 것입니다. 에이전트가 모호한 은행 상태를 제대로 처리했는가? 기존의 재시도 로직 (Retry logic)을 준수했는가? 공유 유틸리티 (Shared utility)를 사용했는가, 아니면 바퀴를 다시 발명 (Reinvent the wheel)했는가? 를 확인하는 것입니다.

이 문제는 저를 충분히 괴롭혔고, 그래서 저는 오픈 소스 에이전트 기반 개발 프레임워크 (Agentic development framework)인 Bodhi Orchard를 만들기 시작했습니다. 핵심 아이디어는 이렇습니다. 에이전트가 단순히 코드만 작성하게 두지 마십시오. 아키텍처 (Architecture), 디자인 패턴 (Design patterns), 테스트 계획 (Test plans), 기존 유틸리티 (Existing utilities)와 같은 전체 컨텍스트 (Full context)를 제공하여, 그들이 똑같은 사각지대 실수를 반복하지 않도록 하는 것입니다. 인간의 단순 반복 업무 (Busywork) 대신 인간의 의사결정에 집중하게 하고, 실제로 품질을 강제할 수 있는 가드레일 (Guardrails)을 구축하는 것입니다.

2026년을 향한 진짜 질문

설문 조사에 따르면 코드의 54%가 AI에 의해 생성된다고 합니다. 저는 그 말을 믿습니다.

하지만 제 질문은 이것입니다. 2026년에는 버그 (Bugs)의 몇 퍼센트가 AI에 의해 생성될까요?

그리고 더 중요한 것은 — 누가 그 버그를 찾아낼 것인가 하는 점입니다?

에이전트가 아닙니다. 그들은 애초에 버그를 작성한 당사자들이니까요. 주니어 개발자들도 아닙니다. 그들은 무엇이 빠졌는지 찾아낼 만큼 충분한 지식을 갖추지 못할 것입니다.

결국 시니어 개발자 (Seniors)들이 하게 될 것입니다. 아키텍트 (Architects)들 말입니다. 시스템이 어디서 어떻게 문제가 발생하는지(where the bodies are buried) 알 수 있을 만큼 오랫동안 이 시스템들을 운영해 온 사람들 말입니다.

80%의 문제는 해결되었습니다. AI가 승리했습니다. 그것을 축하하십시오.

이제 나머지 20%를 이해하는 인간들에게 투자하십시오. 왜냐하면 바로 그 지점에서 여러분의 제품의 생사가 결정되기 때문입니다.

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

그리고 적절한 가드레일 (Guardrails)을 갖춘 AI 네이티브 개발 (AI-native development) 구축에 대해 궁금하시다면, Bodhi Orchard를 확인해 보세요.