Claude Opus 5는 몇 시간 동안 스스로 코딩할 수 있습니다. POS의 어떤 부분에 여전히 코드 이상의 것이 필요할까요?

POS에서 여전히 코드 이상의 것이 필요한 부분은 자금 및 물리적 환경과 접해 있는 부분입니다. 즉 결제 정산 대행 계약, PCI 컴플라이언스(카드 데이터 처리를 위한 카드 업계의 보안 규칙), 인증된 실물 카드 결제 단말기, 매번 정확해야 하는 장부 기록 등입니다. 2026년 7월 24일에 출시된 Claude Opus 5는 최소한의 감독만으로 몇 시간 동안 코딩 세션을 실행할 수 있습니다¹. 하지만 아무리 많은 시간이 지나도 가맹점 계정 승인이 저절로 생성되지는 않습니다.

이 글에 언급된 모델 버전 및 날짜는 게시 시점 기준이며, 관련 세부사항은 현황 참고용입니다.

Claude Opus 5는 실제로 무엇을 바꾸었나요?

Anthropic은 이 모델을 장시간 실행되는 에이전트를 위해 구축했다고 설명합니다. 기존 Opus 모델보다 신중하게 계획하고 작업 내용을 자체 검증하며 더 오랫동안 자율적으로 실행됩니다². Anthropic의 가장 어려운 소프트웨어 엔지니어링 벤치마크 평가에서 이전 모델의 점수를 두 배 이상 경신했습니다¹. 초기 테스터들은 기존에 여러 단계로 나누어 전달해야 했던 작업을 한 번에 맡겨도 완전한 결과를 얻을 수 있다고 전합니다.

이는 실질적인 변화이며 GPT-5.6이 출시되었을 때 다루었던 패턴을 한층 강화합니다. 즉, 단 하나의 프롬프트로 얻을 수 있는 작동 가능한 소프트웨어의 양이 몇 달마다 크게 증가하고 있습니다. 작년에는 프롬프팅에 일주일이 걸렸던 결제 인터페이스를 이제는 반나절 만에 완성할 수 있으며, Opus 5를 사용하면 자리를 비운 동안에도 모델이 작업을 계속 진행합니다.

코딩 시간이 늘어나도 작업이 완성되지 않는 이유는 무엇일까요?

POS의 가장 어려운 부분들이 코드 형태의 문제가 아니기 때문입니다. 자율 실행 모델은 더 많은 코드와 더 철저히 검증된 코드를 작성할 수 있습니다. 하지만 아무리 오랫동안 실행되더라도 심사 승인, 하드웨어 인증, 보안 감사 결과를 만들어낼 수는 없습니다. 이러한 요소는 컴파일러가 아닌 기관과 규제 단체에서 나오기 때문입니다.

두 번째의 미묘한 한계도 존재합니다. Opus 5의 핵심 장점은 스스로의 작업을 검증하는 능력이며, 검증에는 '기준점(Ground truth)'이 필요합니다. 모델은 결제 계산 로직이 정확한지 테스트할 수 있지만, 실제 카드 네트워크, 실제 정산 주기(카드 대금이 실제로 은행에 입금되는 시점), 실제 세무 당국과의 연동을 검증할 수는 없습니다. 이러한 환경은 코딩 샌드박스 내부에는 존재하지 않기 때문입니다. 코드가 완벽히 작동하더라도 실무 카운터에 적용되는 순간 비로소 현실과 마주하게 됩니다.

POS의 어떤 부분에 여전히 코드 이상의 것이 필요할까요?

주로 다음 네 가지입니다.

• 자금 이동: 카드를 결제하려면 결제 대행업체(카드 대금을 은행으로 정산해 주는 회사)와의 계약, 즉 가맹점 심사, 정산 주기 설정, 이상 거래 탐지, 분쟁 처리가 필요합니다. 코딩 세션을 아무리 돌려도 승인된 가맹점 계정이 출력되지는 않습니다.

• 카드 데이터 보안: PCI 컴플라이언스는 카드 번호를 다루는 모든 시스템에 적용됩니다. 카드 데이터를 다루는 생성된 결제 코드는 해당 감사 부담을 사용자에게 전가합니다. 인증된 결제 인프라가 존재하는 이유는 가맹점을 이러한 감사 대상 범위에서 제외하기 위함입니다.

• 실물 카드 단말기: 탭 및 칩 결제는 임의로 작성할 수 없는 보안 펌웨어가 탑재된 인증 단말기에서 실행됩니다. 이는 바이브 코딩된 결제 앱이 App Store에서 거부되는 이유와 동일한 장벽입니다. 장애물은 권한 및 인증의 문제이지 코드 품질의 문제가 아닙니다.

• 오차 없는 기록: 동시 결제 상황에서도 정확히 유지되는 재고 및 실제 입금액과 일치하는 보고서 정산은 기술적으로는 코드이지만 항상 정확해야 하는 코드입니다. 저희는 POS 바이브 코딩하기에서 이 한계를 정리한 바 있습니다. Opus 5는 이전 어떤 모델보다 이러한 코드를 잘 작성하지만, 첫 실전 테스트가 주말 피크 타임이 되는 것은 원치 않으실 것입니다.

그렇다면 Claude Opus 5에게 무엇을 구축하게 해야 할까요?

기준선 위의 모든 것, 즉 화면, 플로우, 로직, 템플릿 대신 비즈니스 특성에 맞게 POS를 최적화하는 업종별 맞춤 동작입니다. 이 레이어는 코드에 해당하며, Opus 5는 현재 이를 처리할 수 있는 가장 강력한 도구라 할 수 있습니다.

실용적인 접근 방식은 MCP(Model Context Protocol, AI 도구가 다른 소프트웨어에 연동할 수 있도록 지원하는 개방형 표준)를 활용하는 것입니다. 모델에게 결제 시스템을 처음부터 재구축하도록 요청하는 대신 자금 이동, 하드웨어 인증, 컴플라이언스가 이미 구축된 플랫폼에 연동하고, 그 위에서 결제 화면을 구축하도록 하는 것입니다. 저희는 이전에 AI가 운영할 수 있는 플랫폼과 AI가 기반으로 구축할 수 있는 플랫폼의 차이에 대해 다룬 적이 있습니다. 자율 모델의 발전으로 후자의 범주가 훨씬 중요해졌습니다. 이제 모델이 사람의 개입 없이도 구축 작업을 크게 진행할 수 있기 때문입니다.

Final의 Build는 이러한 방식으로 작동합니다. 빌더는 프롬프트 기반으로 작동하며, 원하는 플로우를 설명하거나 MCP를 통해 자체 AI를 연결하면 Final Pay, 인증 단말기 및 기본 장부 관리가 이미 처리되어 있는 인프라 위에 플로우가 배포됩니다. Claude Fable 5를 사용하여 실제 작동하는 POS를 구축하는 방법에서 Opus 5의 상위 모델을 활용한 예시를 확인하실 수 있습니다.

그렇다면 POS의 어떤 부분에 여전히 코드 이상의 것이 필요할까요?

계약, 인증, 대금 정산으로 귀결되는 부분입니다. 즉 결제 대행, PCI 컴플라이언스, 실물 카드 단말기, 그리고 매번 정확해야 하는 거래 기록입니다. Claude Opus 5는 한 번의 코딩 세션으로 구축할 수 있는 POS의 범위를 바꾸어 놓았습니다. 하지만 코딩 세션이 생성할 수 있는 본질적 한계를 바꾸지는 못했습니다. 유용한 기본 원칙: 작업의 결과물이 코드로 끝난다면 모델에게 맡기고, 계약·인증·자금 이동으로 끝난다면 기존 인프라에 맡기세요.

실제 현장에서 이 경계가 어떻게 적용되는지 확인하고 싶다면 MCP를 통해 나만의 AI를 Build에 연결하여 모델이 가장 잘하는 영역을 직접 실행해 보도록 하세요.