AI 없이 일하지 않는 개발자들, 나중에 후회할까

연구 결과가 불편한 이유: 결제 현장은 평균값이 없다

TechCrunch가 2026년 5월 보도한 연구 결과는 간단하다. 개발자들이 AI 코딩 어시스턴트 없이는 일하기를 거부할 만큼 의존도가 높아졌지만, 정작 코드 품질은 그 속도를 따라가지 못하고 있다는 것. 일반 소프트웨어 개발이라면 "그래도 빠르니까 감수할 만하다"는 논리가 성립할 수 있다. 하지만 결제·정산·자동화 시스템에서 이 논리는 처음부터 틀렸다.

우리 HEDVION이 하는 일을 구체적으로 말하면 이렇다. 가맹점 정산 배치를 돌리고, 결제 게이트웨이와의 인터페이스를 관리하고, 규칙 기반 자동화 워크플로우를 운영한다. 이 세 가지 모두 '평균적으로 맞는' 코드가 아니라 '100%의 경우에 맞는' 코드가 필요한 영역이다. 통계적 정확성이 아니라 결정론적 정확성을 요구한다. AI가 생성한 코드의 품질 문제가 결제·정산 팀에 유독 뼈아픈 이유가 바로 이것이다.

수치로 보는 트레이드오프: 빠른 개발의 숨은 비용

IBM의 Systems Science Institute 연구를 오래된 기준으로 쓰더라도, 프로덕션에서 발견된 버그의 수정 비용은 설계 단계 대비 6~100배다. 결제 시스템에서 이 배수는 더 올라간다. 단순 수정 공수 외에 거래 취소 처리, 정산 차액 조정, 가맹점 CS 대응, 감사 로그 재구성, 경우에 따라선 금융당국 보고까지 붙는다. HEDVION 규모의 팀에서 정산 로직 하나를 잘못 배포했을 때 실질적으로 동원되는 인시(人時)를 계산해보면, 초기 개발 공수의 열 배가 나오는 경우가 어렵지 않다.

AI 코딩 어시스턴트가 생산성을 높인다는 건 사실이다. GitHub Copilot 관련 연구에서 개발자 속도가 최대 55% 빨라진다는 수치가 나왔고, 우리 팀도 반복 패턴 구현, 보일러플레이트 생성, 단순 API 연동 작업에서 체감 속도 향상을 경험한다. 문제는 이 속도 향상이 어디서 나오느냐다. 상당 부분이 '검토 시간 단축'에서 온다. 코드를 빨리 짜기 때문이 아니라, 짜고 나서 덜 들여다보기 때문에 빠른 것이다. 그 줄어든 검토 시간이 나중에 정산 오류나 결제 실패율 증가로 청구서가 되어 돌아온다.

AI가 결제 코드에서 틀리는 방식: 패턴이 있다

AI 코딩 어시스턴트가 틀리는 방식에는 패턴이 있다. 일반적인 CRUD, 표준 REST 엔드포인트, 흔히 쓰이는 라이브러리 조합에서는 꽤 정확하다. 하지만 결제·정산 도메인에서 자주 등장하는 비표준 요구사항에서 무너진다. 예를 들어, PG사마다 다른 응답 코드 체계와 재처리 정책. 대부분의 학습 데이터에는 "표준적인" 결제 처리 흐름이 담겨 있지, 특정 PG의 부분 승인 처리나 네트워크 타임아웃 후 이중 청구 방지 로직이 담겨 있지 않다. AI가 생성한 결제 재시도 로직이 idempotency key를 제대로 다루지 않는 경우를 실제로 마주쳤다면, 그건 AI가 멍청해서가 아니라 해당 케이스가 학습 데이터에서 충분히 대표되지 않았기 때문이다.

정산 로직에서 더 위험한 건 부동소수점 처리와 통화 반올림 정책이다. AI는 대부분 float이나 double로 금액을 다루는 코드를 자연스럽게 생성한다. 스택 오버플로우 예시, 튜토리얼, 오픈소스 코드 대부분이 그렇게 되어 있으니까. 결제 업계에서는 BigDecimal이나 정수 기반의 최소 단위(예: 원화는 원 단위 정수) 처리가 필수인데, AI는 그 컨텍스트를 프롬프트에 명시하지 않으면 모른다. 0.1원 차이가 수백만 건 정산에서 수십만 원 차이를 만들고, 그게 감사에 걸리는 순간 팀 전체가 밤을 새운다.

HEDVION이라면 어떻게 할 것인가: 실제 시나리오

구체적인 시나리오로 말해보자. 우리 팀이 새로운 정산 배치 스크립트를 개발할 때 AI 어시스턴트를 활용하는 흐름은 이렇게 설계해야 한다고 판단한다.

첫 단계에서 AI 활용 범위를 명확히 제한한다. 데이터베이스 스키마 설계, 배치 프레임워크 보일러플레이트, 로깅 구조, 알림 발송 로직—이런 영역은 AI에게 초안을 맡긴다. 반면 정산 금액 계산 로직, 수수료율 적용 규칙, 예외 거래 처리(취소, 부분환불, 분쟁 보류), 가맹점별 정산 주기 분기—이 부분은 AI가 생성한 코드를 출발점이 아닌 참고 자료로만 쓴다. 팀원 중 도메인 지식이 있는 사람이 처음부터 직접 작성하거나, AI 코드를 라인 바이 라인 전수 검토한다.

두 번째 단계는 AI 코드 전용 검증 체크리스트를 따로 운영하는 것이다. 일반 코드 리뷰와 AI 생성 코드 리뷰는 다르게 접근해야 한다. AI 코드는 "이 코드가 왜 이렇게 생겼나"가 아니라 "이 코드가 우리 비즈니스 규칙의 어떤 케이스를 놓쳤나"를 보는 관점으로 읽어야 한다. 실제로 우리가 지금 내부 논의 중인 체크리스트 항목을 일부 공개하면: 금액 연산에 부동소수점 타입을 쓰지 않았는가, 결제 상태 전이 로직이 우리 PG 계약서의 응답 코드 맵과 일치하는가, 타임아웃 예외가 재처리 로직으로 연결되는가 아니면 묵살되는가, 분산 락(distributed lock) 없이 동일 거래를 동시에 처리할 수 있는 경로가 있는가. 이 질문들은 AI가 자동으로 처리하지 못하는, 우리 비즈니스 컨텍스트에서 나오는 것들이다.

세 번째 단계는 자동화 테스트의 경계선 케이스 커버리지를 명시적으로 측정하는 것이다. AI가 코드를 짜줬을 때 테스트도 함께 짜달라고 요청하는 개발자가 많다. 이 자체는 나쁘지 않다. 하지만 AI가 생성한 테스트는 해피 패스와 일반적인 에러 케이스는 잘 커버하지만, 도메인 특화 경계선 케이스를 놓친다. "13개월치 정산이 한꺼번에 들어오면", "동일 거래가 PG로부터 승인과 취소 응답이 0.3초 간격으로 오면", "가맹점 계좌가 정산 배치 실행 도중 변경되면"—이런 케이스는 우리 팀이 직접 써야 한다.

의존 심화가 만드는 조직 리스크: 지식의 블랙홀

팀 차원에서 더 무서운 문제가 있다. AI 의존도가 높아질수록 도메인 지식이 코드베이스가 아닌 프롬프트 히스토리 속에 묻혀버린다는 것이다. 개발자 A가 AI와 수십 차례 대화를 통해 완성한 정산 모듈이 있다고 하자. 그 코드를 개발자 B가 6개월 후에 유지보수해야 한다면, B는 코드를 읽어서 로직을 이해할 수 있어야 한다. 하지만 AI가 생성하고 개발자 A가 대충 검토한 코드는 '왜 이렇게 짰는가'에 대한 맥락이 없다. 코드 자체가 비즈니스 규칙을 설명하는 문서 역할을 하지 못한다.

작은 팀일수록 이 문제는 치명적이다. HEDVION처럼 결제·정산 도메인에서 소수 인원이 전체 시스템을 커버하는 구조에서, 핵심 로직의 '이해 가능성'이 사라지면 그 자체가 운영 리스크가 된다. 새로운 PG 연동이 필요할 때, 정산 정책이 바뀔 때, 감사 대응을 해야 할 때—코드가 설명되지 않으면 팀 전체가 멈춘다. AI 의존 코드베이스가 쌓일수록 이 리스크는 기하급수적으로 커진다.

지금 당장 쓸 수 있는 실행 시사점

뜬구름 없이, 내일 아침부터 바꿀 수 있는 것들로만 정리한다.

① AI 활용 구역도를 명시적으로 만들어라. "이 레이어는 AI 초안 가능", "이 레이어는 인간 주도 필수"를 팀 내 문서로 확정한다. 결제 금액 계산, 상태 머신 전이, 외부 PG 응답 파싱—이 세 영역은 AI 코드를 참고만 하고 최종 작성은 도메인 담당자가 한다는 룰을 지금 당장 만들 수 있다.

② 코드 리뷰 체크리스트에 "AI 생성 여부" 항목을 추가하라. AI가 생성한 코드임을 PR에 명시하고, 리뷰어가 그에 맞는 집중도로 검토하도록 프로세스를 분리한다. 동일한 리뷰 시간이라면 AI 코드에 더 많은 시간을 써야 한다—직접 짠 코드보다 컨텍스트 이해 없이 만들어졌을 가능성이 높으니까.

③ 정산·결제 관련 경계선 테스트를 팀 자산으로 축적하라. AI가 놓치는 케이스들을 발견할 때마다 테스트 케이스로 만들어 공유 레포에 보관한다. 6개월만 하면 우리 도메인에 특화된 테스트 라이브러리가 생긴다. 이것이 AI가 만들 수 없는, 팀만의 진짜 지식 자산이다.

④ 월 1회 "AI 없는 디버깅 세션"을 운영하라. 기존 코드에서 실제 버그나 개선 포인트를 찾는 작업을 AI 도움 없이 한다. 목적은 도구 거부가 아니라, 팀원이 코드베이스를 직접 읽고 이해하는 근육을 유지하는 것이다. 도메인 지식과 코드 독해력이 살아있어야 AI 코드도 제대로 검증할 수 있다.

AI 없이 개발하자는 말이 아니다. AI가 빠르게 만들어준 것을 우리가 느리게, 정확하게 확인하는 구조를 만들자는 것이다. 결제·정산에서 속도는 수단이지 목표가 아니다. 단 한 건의 정산 오류도 내지 않는 것이 목표다. AI는 그 목표를 위한 도구로만 남아야 한다.

원문 참고: Coders are refusing to work without AI — TechCrunch (2026.05.29)