Claude 4 시리즈 — 6개월 후의 재평가

왜 결제·정산 팀이 AI 모델 버전을 따져야 하나

결제나 정산 업무를 직접 운영해본 팀이라면 안다. 이 영역에서 코드 한 줄의 버그는 단순한 디버깅 티켓이 아니라 오지급, 정산 불일치, 심하면 규제 이슈로 이어진다. 그래서 HEDVION이 새 AI 모델을 평가할 때 기준은 '신기하다'가 아니라 '믿고 쓸 수 있냐'다. Claude 4 시리즈가 출시됐을 때도 같은 잣대로 접근했고, 6개월이 지난 지금 그 평가를 솔직하게 정리한다.

AI 코딩 도구는 결제 팀에 특히 비대칭적 가치를 가진다. PG사 연동, 환불 로직, 정산 집계 쿼리처럼 '패턴은 정해져 있지만 반복이 많은' 작업군이 전체 개발 공수의 30~40%를 차지하기 때문이다. 여기서 생산성이 오르면 고수준 설계와 예외 처리에 더 집중할 여력이 생긴다. 반대로 AI가 만들어준 코드를 무검증으로 배포하면, 잘못된 반올림 로직 하나가 수천 건 정산에 오류를 퍼뜨리는 사고가 난다. 그래서 우리의 핵심 질문은 항상 '어디까지 믿고 쓸 수 있냐'였다.

기대대로였던 것: 보일러플레이트와 긴 컨텍스트

Claude 4의 코드 생성 품질 향상은 우리 실무에서 수치로 확인됐다. 이전 모델에서는 AI가 생성한 결제 연동 코드를 실제로 사용하기 위해 평균 30% 정도를 직접 수정해야 했다. 타입 불일치, 누락된 에러 핸들링, PG사 응답 구조 오해가 주된 원인이었다. Claude 4 Sonnet 기준으로는 그 수정 비율이 10% 이내로 줄었다. '이 PG사 웹훅 페이로드를 파싱하고 실패 케이스별로 분기 처리하는 코드를 TypeScript로 짜줘' 수준의 요청에서 거의 바로 쓸 수 있는 결과물이 나온다. 작은 팀 입장에서 이건 의미 있는 속도 변화다.

긴 컨텍스트는 정산 업무에서 체감이 뚜렷하다. 포맷이 서로 다른 두 PG사 응답을 동시에 붙여넣고 통합 정규화 함수를 요청하면, 이전 모델들은 컨텍스트 중반부에서 앞쪽 내용을 잊거나 혼합하는 오류가 잦았다. Claude 4는 200k 토큰 범위에서 실질적으로 안정적이다. 우리 팀의 월별 정산 검증 스크립트처럼 파일 하나가 2,000줄을 넘어가는 케이스도 끊김 없이 처리된다. 이전에는 파일을 쪼개 여러 번 맥락을 재설명해야 했던 작업이 한 번 요청으로 끝난다.

기대와 달랐던 것: 에이전트 루프의 한계와 추론 일관성

자율 에이전트 루프에 대한 기대는 절반만 맞았다. 단순하고 명확한 작업에서는 실제로 잘 돌아간다. 그러나 결제 도메인의 현실은 더 복잡하다. 환불 처리 파이프라인처럼 외부 API 상태, DB 트랜잭션, PG사 응답 타임아웃이 얽힌 작업에서는 에이전트가 중간에 잘못된 가정을 세우고 그 위에 계속 쌓아 올리는 패턴이 반복됐다. 실패 지점을 뒤늦게 발견하면 롤백 비용이 크다. '이제 AI가 알아서 다 해준다'는 기대는 단순 자동화 작업에만 유효하고, 외부 상태에 의존하는 멀티스텝 파이프라인에서는 아직 조건부 신뢰가 맞다.

추론 일관성 문제는 더 미묘하다. 동일한 정산 로직 코드를 '이 코드가 맞냐'고 물었을 때와 '이 코드의 문제점을 찾아줘'라고 물었을 때 결과가 달랐다. 긍정형 질문에서는 '맞습니다'가 나왔고, 비판형 질문에서는 특정 통화 코드에서 소수점 처리가 잘못된 실제 버그를 찾아냈다. 이건 프롬프트 설계의 문제이기도 하지만, 동시에 중요한 금융 로직 검증에 AI를 단독 심사자로 쓰면 안 된다는 트레이드오프를 명확히 보여준다. 우리는 이후 정산 코드 리뷰에 '비판적 검토 모드' 프롬프트 템플릿을 팀 표준으로 만들었다.

HEDVION의 실제 활용 경계: 경계 설계가 핵심이다

6개월 동안 정착시킨 활용 경계는 세 구간으로 나뉜다. 그냥 쓴다: PG사 연동 코드 초안, 정산 SQL 쿼리 초안, API 문서 드래프트, 반복적인 데이터 변환 로직, 테스트 케이스 생성. 검증 후 쓴다: 금융 계산이 포함된 코드(반올림, 세금, 환율 변환), 에이전트 자율 실행 결과물, 외부 시스템 연동 코드. 쓰지 않는다: 클라이언트 커뮤니케이션 최종본, 아키텍처 최종 결정, 규제 해석, 이상 거래 판단.

지난 분기 새 PG사를 추가 연동할 때 이 경계가 실제로 작동했다. Claude 4로 웹훅 파서·서명 검증 로직·이벤트 핸들러 뼈대를 먼저 생성했고, 작업 시간이 기존 대비 약 40% 단축됐다. 그러나 해당 PG사가 부분 취소 후 재승인 케이스에서 비표준 응답 필드를 보내는 엣지케이스를 AI가 놓쳤다. 실제 트랜잭션 로그 기반 검증 단계에서 잡혔기 때문에 사고로 이어지지 않았다. 이 경험이 'AI 초안 → 인간 코드 리뷰 → 실거래 샌드박스 테스트'의 3단계 워크플로우를 팀 표준으로 굳힌 계기였다. 초안 속도와 검증 안전망을 동시에 확보하는 구조다.

비용 구조도 평가의 일부다

성능만 보고 모델을 고르면 반쪽짜리 평가다. Claude 4 Opus와 Sonnet의 성능 차이가 실무에서 실질적으로 드러나는 작업은 생각보다 좁다. 우리 팀 기준으로 복잡한 다단계 정산 로직 설계, 비정형 에러 디버깅, 설계 검토에서는 Opus가 유의미하게 낫다. 반면 코드 보일러플레이트, 문서 초안, 단순 쿼리 작성에서는 Sonnet으로 충분하다. 가격 차이는 Opus가 Sonnet의 약 5배(입력 토큰 기준)다. 이를 무시하고 Opus를 기본으로 쓰면 같은 예산에서 AI 활용 빈도가 5분의 1로 줄어든다.

이를 해결하기 위해 자동화 파이프라인에 라우팅 레이어를 추가했다. 단순 변환·초안 작업은 Sonnet으로, 예외 케이스 분석·복잡한 코드 리뷰는 Opus로 자동 분기되는 구조다. 작업 복잡도 판단 기준은 요청 프롬프트의 길이·키워드·맥락 변수로 규칙 기반으로 처리했다. 결과적으로 월 AI 비용을 약 35% 줄이면서도 체감 품질 저하 없이 운영 중이다. 모델 선택은 성능 최대화가 아니라 작업 유형별 최적화 문제다.

지금 당장 적용할 수 있는 실행 시사점

① 활용 경계를 문서화하라. 'AI로 뭘 한다'가 아니라 'AI로 뭘 하지 않는다'를 팀 내에 명시하는 게 더 중요하다. 결제·정산 팀이라면 금융 계산 로직, 이상 거래 판단, 규제 해석은 AI 단독 판단 금지 구간으로 명확히 선을 긋는다. 이 경계가 없으면 팀원마다 활용 기준이 달라져 리스크가 조용히 쌓인다.

② 검증 프롬프트를 비판형으로 설계하라. 코드 검토·로직 검증 시 '이게 맞냐'보다 '이 코드의 문제점을 찾아줘, 특히 금융 계산 엣지케이스를 중심으로'가 유의미하게 다른 결과를 만든다. 검증용 프롬프트 템플릿 2~3개를 팀 레벨에서 표준화하면 개인 편차가 줄어들고 리뷰 품질이 균일해진다.

③ 모델을 작업 유형별로 분기하라. 모든 요청에 최상위 모델을 쓰는 건 비용 낭비다. 단순 초안·변환은 Sonnet, 복잡한 분석·설계는 Opus로 라우팅하는 규칙을 파이프라인에 추가하면 비용 대비 효율이 즉시 올라간다. 5배 가격 차이는 무시하기 어렵다.

④ 에이전트 루프에는 반드시 체크포인트를 설계하라. 외부 상태(API, DB, PG사 응답)에 의존하는 자동화 파이프라인에서는 에이전트 자율 실행 구간과 인간 검증 구간을 명시적으로 분리하라. 중간 상태를 로그로 남기고 검증하는 단계를 빼지 않는다. 결제 도메인에서는 사후 대응 비용이 사전 검증 비용보다 훨씬 크다는 걸, 우리는 이미 다른 방식으로 배웠다.