하나의 데모에서 두 가지 AI 실패: Claude 코드가 스키마 오류 대신 철자 수정, OpenAI가 사용자 정의 필드 매핑 오류

Prismatic의 워크숍에서 한 엔지니어가 스트리밍으로 B2B 통합을 처음부터 끝까지 구축했습니다. 두 AI 도구가 각기 다른 방식으로 실패했는데, 이는 실제 에이전트 행동이 혼란스럽고 비결정적임을 보여줍니다.

Claude Code: 잘못된 문제를 해결함

Claude Code는 약 30초 만에 JSON Forms를 사용하여 구성 마법사를 스캐폴딩했습니다. 생성된 마법사는 괜찮아 보였지만, 테스트 중 JSON 스키마 유효성 검사 오류가 나타났습니다. "항목이 하나 미만이어서는 안 됨"이라는 내용이었습니다. 엔지니어가 Claude에게 수정을 요청했지만, 에이전트는 스키마 오류 대신 파일의 철자 경고를 수정하는 데 다음 몇 분을 사용했습니다. 엔지니어는 결국 "철자 문제만 고치는 게 아니길 바란다"고 말하며 포기하고 전날 밤에 실행한 드라이 런의 코드를 붙여넣었습니다.

OpenAI: 이상한 필드에 대한 첫 번째 시도에서 쓰레기 출력

이 통합은 런타임에 OpenAI를 호출하여 고객의 Salesforce 스키마와 대상 앱 간의 기본 필드 매핑을 생성합니다. 일반적인 Salesforce 연락처(이메일-이메일, 회사-회사)의 경우 문제없이 작동했으며, 저자에 따르면 "지루할 정도"였습니다. 하지만 Group name, Internet address, Physical place, Internet email address 같은 의도적으로 이상한 필드 이름을 가진 사용자 정의 레코드 유형에서는 첫 번째 호출이 쓰레기를 반환했습니다. 두 번째 시도에서는 모두 올바르게 처리했습니다.

주요 시사점

• 지루한 스키마는 LLM을 과소평가하게 만듦 — 에이전트 사용이 과잉처럼 보이게 합니다. 진짜 가치는 이상하고 사용자 정의된 경우에서 발휘되지만, 대부분의 데모는 단순함을 위해 이를 피합니다.
• 라이브 실패는 성공보다 유용함. 에이전트와 작업해 본 사람이라면 그것이 혼란스럽다는 것을 압니다. "스키마 오류 대신 철자를 수정한" 행동은 어떤 문서도 예측하지 못할 것입니다.
• 다른 실패 패턴: Claude Code는 필요한 모든 것을 가지고 있었지만 잘못된 문제에 작업했습니다. OpenAI는 답을 "알고" 있었지만 첫 번째에는 표면화하지 못했습니다. 실패 패턴은 각 도구를 어떻게 배포해야 하는지 시사할 수 있습니다.

저자는 Prismatic에서 일하지만 링크를 공유하지 않았으며, 자기 홍보보다 학습 기회에 초점을 맞췄습니다.