Odoo의 master 문서는 기존 RPC 데이터베이스 서비스가 Odoo 20에서 제거된다고 명시합니다. 더 넓은 XML-RPC 및 JSON-RPC API는 19.0 버전부터 더 이상 권장되지 않았지만, Odoo 20이 모든 기존 서비스를 제거하는 것은 아닙니다. Odoo 문서에 따르면 common 및 object 서비스는 Odoo 22까지 계속 사용할 수 있습니다. (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API) 따라서 통합 팀은 기존 RPC 지원을 하나의 기능, 하나의 제거 날짜로 보지 말고, 각 외부 연결이 사용하는 서비스를 식별해야 합니다.
Odoo의 Americas 이벤트 페이지에 따르면 Odoo 20은 2026년 9월 2일과 3일 샌프란시스코 이벤트에서 공개될 예정이라고 합니다. (Oxp26 Americas Introduction) 업그레이드 계획은 지금 문서화된 데이터베이스 서비스 제거를 반영할 수 있지만, 실제 운영 결정은 최종 Odoo 20 릴리스 문서를 기준으로 확인해야 합니다.
제거는 특정 서비스에만 적용됩니다
Odoo는 `/xmlrpc`, `/xmlrpc/2` 및 `/jsonrpc`를 19.0 버전부터 더 이상 권장되지 않는 기존 엔드포인트로 지정합니다. 이 API들 안에서 데이터베이스 서비스는 Odoo 20에서 제거되며, common 및 object 서비스는 Odoo 22까지 유지될 예정입니다. (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API) 유지되는 서비스를 사용하는 통합은 Odoo 20 업그레이드 후에도 계속 동작할 수 있지만, 엔드포인트만으로 호환성이 보장되지는 않습니다.
시스템은 기존 RPC 인터페이스를 통해 서로 다른 서비스를 사용할 수 있습니다. 따라서 통합 검토에서는 엔드포인트와 호출된 서비스를 모두 기록해야 합니다. 애플리케이션을 XML-RPC 또는 JSON-RPC 통합이라고만 설명해서는 Odoo 20에서 제거된 작업에 의존하는지 알 수 없습니다. (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API)
common 및 object 서비스의 지속적인 사용 가능성은 임시적입니다. Odoo는 두 서비스 모두 Odoo 22에서 제거할 예정입니다. (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API) 팀은 데이터베이스 서비스 호출에 대한 긴급 작업과 유지되는 서비스의 마이그레이션을 분리할 수 있지만, 둘 다 계획이 필요합니다.
JSON-2는 요청 계약을 변경합니다
Odoo는 JSON-2를 대체 API로 문서화합니다. 엔드포인트 형식은 `/json/2/<model>/<method>`이며, model과 method가 URL에 포함됩니다. (Odoo master Docs: Reference External API) 따라서 마이그레이션은 기존 RPC 클라이언트의 기본 경로만 바꾸는 것 이상을 의미합니다. 각 작업은 적절한 model 및 method 경로에 매핑되어야 합니다.
JSON-2는 위치 기반 RPC 인수 대신 JSON 요청 본문에서 명명된 인수를 요구합니다. (Odoo master Docs: Reference External API) 기존 래퍼, 미들웨어, 생성된 클라이언트는 인수 순서가 의미를 결정한다고 가정할 수 있습니다. 이러한 구성 요소는 개별 검토가 필요합니다. 클라이언트가 계속 위치 기반 매개변수를 구성한다면 기존 요청을 새 엔드포인트로 전달해도 동작하지 않습니다.
마이그레이션된 각 작업에 대해 팀은 JSON-2가 요구하는 대상 model, method, 명명된 인수를 문서화해야 합니다. (Odoo master Docs: Reference External API) 그런 다음 관련 Odoo 20 환경에서 요청을 테스트해야 하며, 특히 공유 통합 라이브러리가 여러 애플리케이션의 호출을 구성하는 경우 더욱 그렇습니다. 정적 페이로드 비교만으로는 서버나 클라이언트가 전체 요청을 어떻게 처리하는지 확인할 수 없습니다.
인증도 변경되어야 합니다
JSON-2는 bearer API-key 인증을 사용합니다. (Odoo master Docs: Reference External API) 마이그레이션 작업에는 키 생성, 안전한 저장, 인증 헤더 처리 및 키 교체가 포함되어야 합니다. 프록시, 게이트웨이 및 클라이언트 라이브러리가 요청을 전달할 때 헤더를 보존하는지 확인해야 합니다. 또한 자격 증명이 노출되지 않도록 로깅, 모니터링 및 오류 처리도 검토해야 합니다.
문서는 인증 방법을 제시하지만, 각 조직은 API 키가 자사의 자격 증명 통제에 어떻게 적용될지 결정해야 합니다. (Odoo master Docs: Reference External API) 여기에는 키에 대한 책임 할당, 사용 가능한 위치 통제, 그리고 키가 교체될 때 영향을 받는 통합을 어떻게 업데이트할지 정의하는 것이 포함됩니다.
바이너리 필드에는 별도의 호환성 변경이 있습니다
Odoo의 ORM 변경 로그에는 또 다른 Odoo 20 RPC 변경 사항이 기록되어 있습니다. 바이너리 필드의 표현에 `BinaryValue.filename`이 추가되었습니다. (Odoo master Docs: Orm Changelog) 이는 서비스 사용 가능 여부가 아니라 반환되는 데이터를 변경하므로 데이터베이스 서비스 제거와는 별개입니다. 바이너리 필드가 포함된 응답을 읽거나 변환하거나 검증하는 애플리케이션은 호환성 테스트에 포함되어야 합니다.
변경 로그는 `filename` 멤버가 추가되었음을 확인하지만, 실제 영향은 클라이언트에 따라 달라집니다. (Odoo master Docs: Orm Changelog) 테스트에서는 엄격한 스키마, 직렬화기, 응답 비교 및 하위 변환이 추가된 멤버를 허용하는지 확인해야 합니다. 알 수 없는 필드를 무시하는 클라이언트는 수정이 필요하지 않을 수 있지만, 그러한 동작은 가정이 아니라 검증해야 합니다.
통합 감사 범위를 정하는 방법
먼저 `/xmlrpc`, `/xmlrpc/2` 또는 `/jsonrpc`를 사용하는 연결을 식별하십시오. Odoo는 이를 사용 중단된 엔드포인트로 표시합니다. (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API) 목록에는 내부 개발 애플리케이션, 미들웨어, 예약 프로세스 및 구성 또는 소스 코드에 접근 가능한 타사 커넥터가 포함되어야 합니다. 각 연결에 소유자를 지정하여 목적과 상태를 확인할 수 있게 하십시오.
다음으로 각 연결을 레거시 서비스별로 분류하십시오. 데이터베이스 서비스 사용은 Odoo 20에 맞게 수정이 필요하지만, common 및 object 서비스 사용은 Odoo 22까지 사용 가능하다고 문서에 명시되어 있습니다. (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API) 이는 단계적 계획을 지원합니다. 먼저 Odoo 20의 비호환성을 해결한 다음, 나머지 사용 중단된 호출의 마이그레이션 날짜를 설정하십시오.
JSON-2로 전환하는 통합의 경우, 대체 인터페이스에서 필요한 `/json/2/<model>/<method>` 경로, 명명된 요청 인자 및 bearer API 키 인증을 기록하십시오. (Odoo master Docs: Reference External API) 테스트 사례에는 성공적인 요청, 거부된 인증, 잘못된 명명 인자 및 반환 데이터의 애플리케이션 처리가 포함되어야 합니다. 해당 필드가 있는 곳마다 바이너리 필드 사례를 추가하십시오.
최종 Odoo 20 동작을 확인하십시오
제거 세부 사항은 Odoo의 master 개발자 문서에서 가져왔으며, 발표된 출시 시점은 Odoo 20이 2026년 9월 Americas 이벤트 기간에 출시될 것이라고 명시한 이벤트 페이지에서 나온 것입니다. (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API; Oxp26 Americas Introduction) 배포 전에 팀은 출시된 Odoo 20 버전과 사용하려는 정확한 에디션 및 빌드에 대한 문서를 다시 확인해야 합니다.
사용 중단된 RPC 엔드포인트를 사용한다고 해서 그 통합이 Odoo 20에서 작동을 멈출 것이라는 뜻은 아닙니다. common 및 object 서비스는 Odoo 22까지 사용 가능하다고 문서에 명시되어 있기 때문입니다. 반대로, 이전 버전에서 성공적으로 동작했다고 해서 데이터베이스 서비스 호출이 제거된 후에도 호환된다는 의미는 아닙니다. (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API)
업그레이드 결정 체크리스트
Odoo 20 업그레이드를 승인하기 전에 의사결정자는 각 사용 중단된 엔드포인트, 호출된 서비스, 소유자 및 계획된 조치를 보여주는 통합 목록을 요청해야 합니다. 데이터베이스 서비스 의존성에는 테스트된 대체 수단이 있어야 합니다. common 또는 object 서비스에 남아 있는 통합은 Odoo 22에서의 문서상 제거를 반영한 별도의 마이그레이션 날짜가 있어야 합니다. (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API)
검토에서는 JSON-2 구현이 모델과 메서드를 URL에 배치하고, 이름이 지정된 JSON 인수를 사용하며, bearer API 키로 인증하는지 확인해야 합니다. 바이너리 필드가 있는 경우, 테스트에서는 `BinaryValue.filename` 추가를 고려해야 합니다. (Odoo master Docs: Reference External API; Odoo master Docs: Orm Changelog) 이러한 확인 항목은 Odoo 20에서 데이터베이스 서비스가 즉시 제거되는 것과, 이후 나머지 레거시 서비스가 종료되는 것을 구분해 줍니다.