Claude Code를 활용한 AI 우선 통합 엔지니어링: 실제 디버깅 세션

대부분의 "AI가 내 코드를 작성했습니다" 이야기는 깔끔한 프롬프트와 깔끔한 결과물을 보여주는 데모에 그칩니다. 하지만 이 글은 다릅니다. 실제 APIANT 통합 제품을 사용한 실제 세션으로, 실제 프롬프트, 잘못된 선택, 수정 과정, 그리고 인간의 기억력이 기계를 이긴 순간까지 모두 담겨 있습니다.

핵심은 AI가 인상적이라는 점이 아닙니다. 핵심은 실제로 함께 앉아서 작업을 할 때 협업이 어떤 모습인지입니다.

설정

해당 제품은 당사의 CRMConnect 통합 솔루션 중 하나입니다. Mindbody에서 HubSpot으로한 고객이 여러 결제 수단으로 결제된 매출이 제대로 동기화되지 않는다고 보고했습니다. 8,400달러의 매출이 세 가지 결제 수단으로 분할 결제되었는데, HubSpot에서는 400달러짜리 단일 거래로 표시되고 나머지 8,000달러는 파이프라인에서 누락되었습니다.

저희는 GitHub 이슈에서 엔지니어링 작업을 추적합니다. 고객과의 대화는 HubSpot Service Hub에 저장됩니다. 세션은 개발자가 AI에게 작업 내용을 알려주는 것으로 시작되었습니다.

즉각적인: "지불 문제를 살펴보세요."

AI는 해당 저장소의 GitHub 이슈를 검색하여 미해결된 문제를 찾아 전체 내용을 읽어주었습니다. 내용은 두 개의 프로덕션 실행 ID가 증거로 제시된 다중 결제 판매 버그였습니다. 별도의 안내 없이도 AI는 추측하는 대신 다음 단계를 명확하게 요청했습니다.

즉각적인: "논리 로직은 어떤 역할을 하며, 어떤 자동화/액션이 수행되나요?"

AI는 플랫폼에서 관련 자동화 기능을 불러와 단계별로 구조를 분석하고 오류 원인을 정확하게 설명했습니다. 해당 자동화 기능은 각 HubSpot 거래에 대해 중복 제거 키를 생성합니다. 여러 결제 방식이 사용되는 판매의 경우, Mindbody는 결제 방식별로 한 행씩 반환하는데, 모든 행이 동일한 키를 공유합니다. 따라서 두 번째 행과 세 번째 행이 첫 번째 행에서 생성된 거래와 충돌하여 해당 금액이 자동으로 삭제되었습니다.

유용하긴 하네요. 하지만 건설업체가 이미 더 유리한 위치에 있었습니다.

모든 것을 바꿔놓은 힌트

즉각적인: "이 거래의 고유 식별자를 CRMConnect-MindBody-Zoho 프로젝트에서 사용하는 방식과 비교해 보세요. 저는 그 부분에서 이미 해결했다고 생각했는데요. 아주 집중해서 비교해 보세요."

이 한 문장이 작업의 방향을 바꿔놓았습니다. 시공업자는 해결책을 제시하지 않았습니다. 그는 유사 제품을 가리키며 사실상 "가서 읽어보세요"라고 말했습니다.

그래서 인공지능은 그렇게 했습니다. 인공지능은 문을 열었습니다. Mindbody에서 Zoho로 통합 기능은 완전히 별개의 제품으로, 과거 판매 내역을 처리하는 자동화 기능을 찾아 읽어냈습니다. 그런 다음 결제 기록을 작성하는 서브루틴을 찾아 읽어냈습니다. 요약 기록이 아니라, 실제 자동화 로직을 단계별로 읽어낸 것입니다.

집중적인 비교 분석 결과가 나왔습니다. Zoho 통합을 통해 이 문제는 해결되었지만, 아키텍처는 달랐습니다.

• HubSpot 제품은 Mindbody의 기존 판매 엔드포인트를 사용하여 판매 라인당 하나의 고정 거래를 기록하며, 이 엔드포인트는 분할 전 결제 행을 반환합니다.
• Zoho 제품은 Mindbody의 최신 엔드포인트를 사용하여 상위 구매 기록과 품목별 및 결제에 대한 별도의 하위 기록을 작성하며, 각 결제에는 고유한 실제 결제 ID가 부여됩니다.

AI는 Zoho가 아키텍처적으로 더 깔끔하다고 판단했고, 처음에는 세 가지 객체 모델 전체를 HubSpot으로 이식하는 것을 제안했습니다.

건설업체가 사업 범위를 축소합니다.

바로 이 지점에서 인간이 균형을 잡아주었다.

즉각적인: "아직 4.0 버전을 출시할 준비가 되지 않았습니다. 나중에 다시 시도해 주세요. 지금은 고객이 신고한 거래 누락 문제를 해결해야 합니다."

AI는 만족스러운 아키텍처 재설계 방향으로 나아가고 있었습니다. 하지만 개발자는 문제를 다시 원래대로 되돌렸습니다. 고객에게 필요한 것은 새로운 데이터 모델이 아니라 정확한 거래 금액이었습니다. AI는 이에 동의하고 재설계 제안을 향후 작업으로 보류한 후, 기존 거래 자동화 기능을 정밀하게 수정하는 데 초점을 맞췄습니다.

그 수정 사항은 중요합니다. AI는 우아하고 일반적인 해결책을 찾는 데 능숙합니다. 하지만 그 우아한 해결책이 상황에 필요한 것보다 과한지 판단하는 데는 항상 능숙한 것은 아닙니다. 개발자는 단 한 문장으로 그 판단을 내렸습니다.

AI는 Zoho 디자인의 기본 원칙을 적용하되 구조를 그대로 복사하지는 않았습니다. 즉, 판매 품목별로 하나의 거래를 정산하고, Mindbody의 더욱 풍부한 엔드포인트에서 데이터를 가져오며, 첫 번째 결제가 나머지 결제를 덮어쓰지 않도록 모든 결제 수단의 금액을 정확하게 집계하는 것입니다. 플랫폼은 다르지만, 실행 방식은 다르고, 근본적인 아이디어는 동일합니다.

직감

중복 제거 키를 재작업하는 동안 AI는 키 구성 요소 중 하나인 날짜를 살펴보았습니다. AI의 추론은 명확했습니다. 판매 ID와 판매 상세 ID만으로도 키가 고유해지므로 날짜는 중복된다는 것입니다. 따라서 AI는 키를 단순화하고 두 자동화 시스템 간의 취약점을 제거하기 위해 날짜를 삭제할 것을 권장했습니다.

건축업자는 반박할 만한 건축법규 근거가 없었다. 그에게는 기억력이 있었다.

즉각적인: "제가 날짜를 추가했던 이유는 필요했기 때문인 것 같아요 (같은 거래에 두 번 결제하는 경우였나, 아니면 그와 비슷한 특이한 경우였나)?"

현재 자동화 시스템으로는 둘 다 이를 증명할 수 없었습니다. 그래서 AI는 자동화 시스템의 버전 기록을 살펴보았습니다. 해당 자동화 시스템에는 2021년까지 거슬러 올라가는 93개의 저장된 버전이 있었습니다. AI는 관련 변경 사항을 찾을 때까지 변경 설명을 읽었습니다.

2022년 1월부터:

"동일 품목에 대해 여러 번 결제가 이루어질 때 거래 ID가 고유하게 유지되도록 데이터베이스에 거래 ID 저장 시 EPOCH MILLIS를 추가했습니다."

2022년 2월부터:

"사용자 지정 부동산으로 거래를 찾을 때 판매 날짜를 추가하여 이전 판매에 대한 결제가 처리되도록 했습니다."

건설업체의 설명에 따르면, 그 거래는 4년 전에 이루어졌습니다. 고객이 이전 구매 건에 대해 나중에 대금을 지불하면, 마인드바디는 새로운 날짜에 해당 판매 내역을 다시 전송합니다. 키에 날짜가 없으면 나중에 지불된 금액이 원래 거래와 충돌하여 별도의 기록을 생성할 수 없습니다. 날짜는 불필요한 것이 아니었습니다. 할부 및 자동 결제를 처리하기 위해 의도적으로 추가된 핵심적인 요소였습니다.

인공지능은 즉시 권고 사항을 철회하고 분명하게 다음과 같이 응답했습니다.

"기억을 믿으세요. 날짜를 의도적으로 추가했다면 중요한 정보이므로 삭제하는 것은 고려 대상이 아닙니다. 버전 기록에서 찾았습니다."

여기서 더 나아가, 날짜는 그대로 유지되어야 했기 때문에 두 자동화 시스템은 정확히 동일한 날짜 값을 생성해야 했습니다. 그렇지 않으면 키가 일치하지 않아 중복 거래가 발생했기 때문입니다. 기존 자동화 시스템은 Mindbody의 특정 필드에서 날짜를 생성합니다. AI는 새로운 자동화 시스템이 동일한 API 호출과 동일한 시간대 변환을 통해 동일한 필드를 읽도록 수정했습니다. 입력값도 같고 출력값도 같으므로 키 일치가 보장됩니다.

할부 결제 처리 기능을 조용히 망가뜨릴 뻔했던 회귀 오류는 발생하지 않았습니다. AI가 신중해서가 아니라, 한 사람이 직감을 기억해냈고 AI는 그 직감을 4년간의 기록과 대조해 몇 초 만에 검증할 수 있었기 때문입니다.

화려하지 않은 부분: 빌드, 실행, 트레이스 읽기, 수정

설계가 확정되자 반복적인 엔지니어링 작업이 시작되었습니다. 개발 환경에서 변경 사항을 빌드하고 실행한 다음 실행 추적을 읽고 다음 문제를 찾아 수정하고 다시 실행했습니다. 실제 버그는 평범한 것들이었습니다.

• 거래 성사 단계에서 16건의 오류가 발생했습니다. PROPERTY_DOESNT_EXIST 필드 바인딩에 HubSpot의 내부 속성 이름이 포함되지 않아 오류가 발생했습니다. AI는 추적 정보를 읽고 커넥터의 필드 스키마를 가져와 모든 필드를 올바른 ID로 다시 바인딩했습니다.
• 플랫폼이 소스 데이터에서 가장 긴 배열을 기준으로 반복 횟수를 계산했기 때문에, 결제 배열이 품목 배열보다 길어서 루프가 한 번만 실행되어야 했는데 두 번 실행되었습니다. AI는 명시적인 반복 제어를 삽입하여 루프가 품목만 계산하도록 했습니다.
• "거래 찾기" 단계에서 거래가 아직 존재하지 않을 경우 전체 실행이 중단되었습니다. 기본 오류 모드가 "찾을 수 없음"을 치명적인 오류로 처리했기 때문입니다. AI는 이를 "오류 발생 시 계속 진행"으로 변경하여 생성 분기가 실행될 수 있도록 했으며, 이는 기존 자동화 기능에서 오류를 처리하는 방식과 일치합니다.

이 모든 과정은 결코 화려하지 않습니다. 이것이 바로 통합 작업의 실제 모습입니다. 달라진 점은 반복 작업 속도입니다. AI는 단계별 실행 추적 데이터를 읽고 오류가 발생하는 단계를 즉시 찾아낼 수 있었기 때문에 수정 주기가 몇 분밖에 걸리지 않았습니다. 개발 테스트가 통과될 때까지는 고객에게 어떤 제품도 출시되지 않았습니다.

이것이 건설업자들에게 의미하는 바는 무엇일까요?

서술적인 부분을 제거하면 다음과 같은 작동 모델이 나타납니다.

• AI의 강점은 읽기 능력입니다. 이 시스템은 전체 형제 통합 과정을 연구하고, 우리가 이미 해결했던 문제를 교차 참조하고, 두 개의 서로 다른 플랫폼에 걸쳐 아키텍처를 적용하고, 하나의 설계 결정을 검증하기 위해 90가지 버전의 기록을 샅샅이 뒤졌습니다. 사람이 하루아침에 이 모든 일을 해낼 수는 없습니다.
• 인간의 강점은 기억력과 판단력이다. "내가 그 기능을 추가한 데에는 이유가 있다고 생각한다"는 말은 어떤 파일에도 없습니다. "아직 4.0 버전을 출시할 준비가 안 됐다"는 말도 어떤 파일에도 없습니다. 둘 다 제품을 직접 사용해 보면서 나온 생각입니다. 각각의 생각이 결과에 영향을 미쳤습니다.
• 속도는 루프에서 나옵니다. 추적 정보를 읽고, 단계를 수정하고, 다시 실행합니다. 일반적으로 디버깅 속도를 늦추는 마찰, 즉 무슨 일이 일어났는지 재구성하는 과정이 사라집니다.

AI 우선 통합 엔지니어링은 AI가 단독으로 작동하는 것도 아니고, 사람이 더 빨리 일하는 것도 아닙니다. AI는 사람이 시간이 부족해서 읽을 수 없는 부분을 읽어내고, 사람은 코드베이스에 기록되지 않은 맥락을 제공합니다. 이 둘을 결합하면 4년 동안 반복되어 온 버그를 단 한 번의 작업 세션으로 이해하고, 수정하고, 검증할 수 있습니다.

그것이야말로 우리가 지향해야 할 워크플로입니다.