Claude 4 시리즈를 도입한 4주 후기

결제·정산 팀이 LLM 도입을 다르게 봐야 하는 이유

HEDVION은 가맹점 정산, 수수료 계산, 외부 PG 연동 자동화를 소규모 팀이 직접 운영한다. 이 구조에서 코드 한 줄의 오류는 단순 버그가 아니다. 소수점 반올림 로직 하나가 수천 건 정산에 누적 오차를 만들고, 예외 처리 누락 하나가 이중 청구 또는 미청구로 이어진다. 그래서 우리가 Claude 4 시리즈를 도입할 때 첫 번째로 정한 건 "어디까지 맡기고, 어디서는 사람이 반드시 한 번 더 보는가"라는 신뢰 등급의 경계선이었다. 도구 선택보다 이 경계 설정이 먼저였다.

4주 전 팀 워크플로우에 본격 투입하면서 세운 기준은 간단했다. 모델이 틀렸을 때의 비용이 어느 수준인가? 코드 리뷰 초안이나 문서 구조화는 틀려도 사람이 잡을 수 있다. 하지만 금액 계산이 포함된 디버깅이나 세율 적용 해석은 다르다. 그 기준 위에서 4주를 돌렸고, 예상이 맞은 부분과 완전히 빗나간 부분이 생각보다 명확하게 갈렸다.

코드 리뷰: 정산 로직에서 설계 의도의 어긋남을 짚어낸 순간

가장 먼저 바꾼 것은 PR 리뷰 흐름이다. 이전에는 팀원 두 명이 번갈아 코멘트를 달았는데, 이제는 PR을 올리면 Claude에 초안 리뷰를 먼저 돌리고 그 결과를 토대로 사람이 최종 판단을 내린다. 도입 2주차까지 약 23개 PR에 이 흐름을 적용했다. 모델이 지적한 이슈 중 실제 수정이 필요했던 비율은 약 61%였다. 나머지 39%는 과도한 주의나 맥락 없는 스타일 지적이었다.

그런데 진짜 가치는 수치 밖에 있었다. 정산 금액 계산 함수에서 서로 다른 두 반올림 방식이 혼재한다는 사실을 모델이 "설계 의도가 일관되지 않아 보입니다"라는 형식으로 짚어줬다. 각자 기능은 했기 때문에 사람 리뷰에서는 그냥 통과됐을 코드였다. 한쪽은 Math.round(), 다른 쪽은 Math.floor()를 쓰고 있었고, 건수가 적을 때는 차이가 티 나지 않는다. 이 하나의 발견으로 정산 배치가 스케일됐을 때 발생할 수 있었던 누적 오차를 사전에 잡았다. PR 리뷰 자동화를 계속할 이유가 생긴 건 그 순간이었다.

디버깅의 절반: 원인 후보 나열과 실제 원인 특정은 전혀 다른 일이다

"이제 디버깅도 맡길 수 있겠다"는 기대는 정확히 절반만 맞았다. 에러 메시지와 스택 트레이스를 넣으면 가능한 원인 후보를 빠르게 나열해준다. 이 구간에서 체감 속도는 확실히 빠르다. 혼자 삽질할 때 20~30분 걸리던 "뭐가 문제일까" 단계가 5분 내외로 줄었다. 하지만 그다음이 문제였다.

정산 파이프라인에서 특정 배치가 침묵하며 실패하는 오류를 디버깅하던 중, 모델은 "데이터베이스 커넥션 풀 고갈", "타임아웃 설정 불일치", "외부 PG API 응답 포맷 변경" 세 가지를 후보로 제시했다. 실제 원인은 세 번째였는데 모델이 첫 번째로 제시한 건 첫 번째였다. 우선순위를 바로 잡은 건 최근 배포 이력과 해당 PG사의 변경 공지를 알고 있던 팀원이었다. 모델은 컨텍스트를 모른다. 에러만 던져 넣으면 일반적인 가능성을 나열할 뿐이다. 최근 배포 이력, 외부 API 변경 공지, 관련 로그 구간을 함께 넣어야 의미 있는 결과가 나오는데, 그 컨텍스트를 정리하는 것 자체가 이미 디버깅의 절반이다.

자신감 과잉 함정: 금융 도메인에서 이건 노이즈가 아니라 리스크다

모델이 틀릴 때 머뭇거리지 않는다는 건 쓰는 사람이라면 누구나 안다. 일반 개발 팀과 결제·정산 팀의 결정적 차이는, 후자에서는 자신감 있게 틀린 답이 실제 금전 손실로 이어질 수 있다는 것이다. 특히 세금 계산, 부가세 처리, 환율 기준 적용처럼 법령이 얽힌 영역에서 모델은 "일반적으로는 이렇게 합니다"를 매우 설득력 있게 말한다. 그게 우리 시스템의 실제 계약 조건이나 특정 PG사 정산 규칙과 맞지 않을 때도 어조는 전혀 바뀌지 않는다.

우리가 만든 대응은 단순하지만 명시적이다. 금액, 세율, 정산 규칙이 포함된 AI 출력은 반드시 원본 계약서 또는 공식 문서와 대조한다는 규범을 문서로 박았다. 구두로 "검증해야 해요"라고 말하는 것과, PR 템플릿에 "AI 제안 중 채택 항목 / 거부 항목 / 출처 확인 여부" 칸이 있는 것은 현실에서 전혀 다르게 작동한다. 이 내부 프로세스를 정립하는 데 2주가 걸렸다. 모델 도입을 결정하는 것보다 훨씬 더 많은 시간이 들었고, 더 중요한 작업이었다.

문서화: 빈 페이지 공포를 없애는 데는 충분히 작동했다

기술 스펙 문서를 대화 형식으로 구조화하면 초안이 빠르게 나온다는 건 기대한 대로였다. 한 사람이 개발과 운영을 동시에 담당하는 구조에서 "나중에 쓰지"라며 쌓여가던 문서들이 줄었다. 외부 PG 연동 명세서와 정산 배치 처리 흐름 문서를 각각 작성할 때, 초안 작성 시간이 이전 대비 약 40% 단축됐다. 쓰기 시작하는 데 걸리는 시간이 짧아진 것만으로도 체감 부담이 크게 다르다.

다만 한계는 명확하다. 초안이 골격을 잡아줘도 내용이 자동으로 채워지지는 않는다. 우리 시스템에만 존재하는 예외 케이스, 특정 PG사와의 히스토리, 과거 장애 대응 기록은 모델이 알 수 없다. "AI가 문서를 써줬으니 완성"이라고 착각하면, 정작 중요한 맥락이 빠진 채 형식만 갖춘 문서가 나온다. 골격은 AI, 살은 사람이라는 분업을 팀 안에서 명확히 해두지 않으면 이 함정에 빠진다.

지금 당장 써먹을 수 있는 운영 지침 네 가지

4주간의 경험을 결제·정산·자동화를 운영하는 팀 기준으로 압축하면 다음과 같다.

1. 용도별 신뢰 등급을 미리 문서로 정하라. 코드 리뷰 초안·문서 구조화는 높은 신뢰로 써도 된다. 금액 계산·세율 적용·외부 규정 해석은 낮은 신뢰로 다뤄야 한다. 이 구분 없이 투입하면 생산성이 오르는 게 아니라 검증 피로가 누적된다.

2. 디버깅에 쓸 때는 컨텍스트 정리부터 하라. 에러 메시지만 붙여 넣는 건 반쪽짜리다. 최근 배포 이력, 외부 API 변경 공지, 관련 로그 구간을 함께 구성해서 넣어야 의미 있는 결과가 나온다. 이 준비 과정 자체가 이미 디버깅이다.

3. AI 결과 검증을 체크리스트 항목으로 박아라. 구두 합의는 흐릿해진다. 우리는 PR 템플릿에 AI 리뷰 결과 중 채택한 항목과 거부한 항목, 금액 관련 출력의 출처 확인 여부를 기록하는 칸을 추가했다. 이 한 칸이 팀 문화를 바꾼다.

4. 에이전트 워크플로우는 이미 검증된 단위 작업부터 연결하라. 다음 달 우리는 정산 배치 이상 감지 → Slack 알림 → 담당자 확인 요청의 파이프라인을 에이전트로 연결할 계획이다. 처음부터 복잡한 자율 에이전트를 만들려 하지 않는다. 현재 사람이 수동으로 반복하고 있는 작업 하나를 먼저 자동화하고, 그 신뢰도를 확인한 뒤 연결 범위를 넓히는 방식이다. 순서를 거꾸로 하면 디버깅할 수 없는 블랙박스가 생긴다.

모델보다 사용 방식이 중요하다는 말은 진부하게 들릴 수 있지만, 결제·정산 현장에서 그건 곧 리스크 관리다. 4주 뒤에 에이전트 파이프라인 후기로 돌아오겠다.

— by slecs