Odoo 20은 오프라인 모드를 확장하여 사용자가 활성 연결 없이 기록을 생성, 수정, 보관, 보관 취소, 삭제할 수 있게 합니다. 이전에 실행한 검색도 오프라인에서 실행할 수 있습니다. 연결이 복구되면 동기화 대기열이 변경 사항을 처리하며, 오프라인 인터페이스와 관리 도구로 진행 상황을 모니터링할 수 있습니다. (Odoo 20 Release Notes; Odoo Goes Offline) 이는 오프라인 접근을 보기용 대체 수단에서 비즈니스 데이터를 변경할 수 있는 작업 모드로 전환합니다. Odoo 20을 평가하는 조직은 장애 시 기록이 계속 접근 가능한지만이 아니라, 이러한 변경 사항이 동기화될 때 어떻게 동작하는지도 검토해야 합니다.
Odoo Nightly는 Odoo 20을 안정적이고 권장되는 Community Edition 릴리스로 표시하며, 날짜는 2026년 9월이고 Odoo 23까지 지원됩니다. (nightly.odoo.com) 이 표시는 Community Edition 계획과 관련이 있지만, 모든 플랫폼, Enterprise 환경 또는 사용자 정의된 데이터베이스에서 동일한 오프라인 범위를 보장하지는 않습니다. 범위는 예정된 배포 환경에 맞춰 확인해야 합니다.
Odoo 19에서 무엇이 달라졌나
Odoo 19 오프라인 모드에서는 연결이 끊기기 전에 열어 둔 기록을 볼 수 있지만, 오프라인 상태에서 수정할 수는 없습니다. Odoo 20은 기록 생성, 수정, 보관, 보관 취소, 삭제를 추가합니다. (Odoo 19.0 Docs: General Offline Mode; Odoo 20 Release Notes) 이는 이전 캐시에 대한 새로운 명칭이 아니라 기능적 확장입니다. Odoo 19에서는 사용자가 관련 기록을 미리 열어 연결 끊김에 대비할 수 있지만, 해당 기록을 변경하는 작업은 연결이 복구될 때까지 기다려야 합니다. Odoo 20은 오프라인 상태에서도 새 기록과 기존 기록의 변경을 모두 지원합니다. (Odoo 19.0 Docs: General Offline Mode; Odoo 20 Release Notes)
버전 평가는 캐시된 정보에 대한 접근과 기록 작업을 완료하고 대기열에 넣는 기능을 구분해야 합니다. 참조 데이터만 필요한 워크플로는 데이터 입력, 상태 변경, 삭제가 포함된 워크플로와 요구사항이 다릅니다. (Odoo 19.0 Docs: General Offline Mode; Odoo 20 Release Notes)
확인된 오프라인 작업
확인된 Odoo 20 기능은 기록 수명 주기의 다섯 부분, 즉 생성, 편집, 보관, 보관 취소, 삭제를 포괄합니다. 이전에 실행한 검색도 오프라인에서 사용할 수 있습니다. (Odoo 20 Release Notes) 승인 테스트에는 각 작업별로 최소 한 가지 시나리오를 포함하고, 재연결 및 동기화 후 예상한 기록 상태가 표시되는지 확인해야 합니다.
Odoo의 Experience 세션은 전용 오프라인 인터페이스, 동기화 대기열, 그리고 동기화를 모니터링하고 관리하는 도구를 설명합니다. (Odoo Goes Offline) 이러한 기능은 사용자 교육과 운영 절차에 포함되어야 합니다. 사용자는 대기열 항목이 어디에 표시되는지, 해결되지 않은 항목을 어떻게 식별하는지, 누가 이를 검토하는지 알아야 합니다. 제공된 자료는 관리 도구가 존재함을 확인하지만, 전체 워크플로 또는 관리 권한을 정의하지는 않습니다.
캐싱 및 검색 범위는 확인이 필요합니다
Odoo 19 문서는 오프라인 접근을 연결이 끊기기 전에 열어 둔 기록의 관점에서 설명합니다. Odoo 20은 이전에 실행한 검색을 오프라인에서 실행할 수 있다고 별도로 확인합니다. (Odoo 19.0 Docs: General Offline Mode; Odoo 20 Release Notes) 제공된 출처는 관련 데이터가 얼마나 보존되는지, 얼마나 오래 이용 가능한지, 저장 한도가 적용되는지, 캐시된 기록과 관련된 모든 필드를 사용할 수 있는지 명시하지 않습니다. 또한 오프라인에서 검색을 다시 실행할 때 원래 결과 집합이 반환되는지, 아니면 기기에 이미 저장된 데이터만 반환되는지도 확인하지 않습니다.
오프라인 워크플로를 승인하기 전에 팀은 각 역할에 필요한 검색과 기록 유형을 식별해야 합니다. 테스트는 온라인 상태에서 관련 검색을 실행하고 필요한 기록을 여는 것으로 시작해야 합니다. 그런 다음 테스터는 연결을 끊고, 첨부 파일, 연결된 기록, 필수 필드의 사용을 포함해 의도한 작업을 반복할 수 있습니다. 이는 확인 지점이며 확인된 제한 사항은 아닙니다. 제공된 릴리스 정보에 해당 동작이 설명되어 있지 않기 때문입니다. (Odoo 20 Release Notes)
충돌 처리에는 테스트가 필요합니다
동기화 대기열과 관리 도구는 확인되었지만, 제공된 자료에는 Odoo 20이 동일한 레코드에 대한 경쟁 변경, 재연결 후 검증 실패, 또는 대기열 작업 간의 의존성을 어떻게 처리하는지 설명되어 있지 않습니다. (Odoo Goes Offline) 대기열이 존재한다고 해서 충돌 정책이 확립되는 것은 아닙니다. 해당 동작은 의도한 Odoo 빌드와 구성에서 입증되어야 합니다.
충돌 테스트에서는 한 사용자가 오프라인에서 레코드를 수정하는 동안 다른 사용자가 같은 레코드를 온라인에서 변경할 수 있습니다. 재연결 후 팀은 결과 값, 대기열 상태, 사용자 알림을 검토해야 합니다. 별도의 테스트에서는 다른 곳에서 보관 처리되거나 삭제된 레코드에 대한 오프라인 편집과, 서버 측 규칙에 실패하는 새로 생성된 레코드를 다뤄야 합니다. 테스트 문서에는 업데이트가 우선하는지, 병합이 발생하는지, 아니면 수동 개입이 필요한지를 기록해야 합니다. (Odoo Goes Offline)
접근 제어와 파괴적 작업
Odoo 20에는 오프라인 보관, 보관 해제, 삭제 기능이 포함되므로, 평범한 데이터 입력을 넘어서 평가해야 합니다. (Odoo 20 Release Notes) 조직은 오프라인 작업이 발생할 때, 동기화 중에, 또는 두 단계 모두에서 접근 권한, 레코드 규칙, 승인 요구사항이 적용되는지 확인해야 합니다. 릴리스 노트는 사용 가능한 작업을 확인해 주지만, 연결이 없는 상태에서 각 보안 제어가 어떻게 작동하는지는 설명하지 않습니다.
테스트는 관리자 계정만이 아니라 대표적인 사용자 역할을 사용해야 합니다. 각 역할은 연결된 상태와 연결이 끊긴 상태에서 허용된 작업과 금지된 작업을 시도해야 합니다. 그런 다음 테스터는 대기 중인 변경 사항이 계속 표시되는지, 거부 메시지가 명확한지, 보관되거나 복원되거나 삭제된 레코드가 의도한 최종 상태에 도달하는지 확인해야 합니다. 삭제로 인해 중대한 결과가 발생하는 프로세스는 배포 전에 문서화된 오프라인 절차를 갖춰야 합니다. (Odoo 20 Release Notes; Odoo Goes Offline)
맞춤형 모듈에는 집중적인 테스트가 필요합니다
확인된 기능은 Odoo 20의 오프라인 레코드 작업과 동기화 기능을 포함하지만, 제공된 자료에는 모든 맞춤형 모듈, 서드파티 모듈, 자동화 작업 또는 외부 통합이 오프라인 작업과 호환된다고 명시되어 있지 않습니다. (Odoo 20 Release Notes; Odoo Goes Offline) 따라서 맞춤형 배포는 데이터베이스 전체에 오프라인 모드가 일괄적으로 적용된다고 가정하지 말고 모듈별로 지원 여부를 평가해야 합니다.
테스트는 조직의 워크플로에서 사용되는 사용자 정의 필드, onchange 동작, 필수 값, 계산 값, 서버 측 검사를 포함해야 합니다. 일반적으로 레코드 생성이나 편집에 반응하는 통합도 대기 중인 변경 사항이 동기화된 뒤 관찰해야 합니다. 목적은 실패를 가정하는 것이 아니라, 각 요소가 오프라인에서 실행되는지, 재연결을 기다리는지, 거부된 대기열 항목을 생성하는지, 아니면 다른 프로세스가 필요한지를 확인하는 것입니다. (Odoo 20 Release Notes; Odoo Goes Offline)
배포 전에 해결해야 할 질문
Odoo 20은 대기 중인 작업을 위한 전용 인터페이스와 동기화 도구로 지원되는, Odoo 19보다 더 광범위한 확인된 오프라인 기능을 제공합니다. (Odoo 19.0 Docs: General Offline Mode; Odoo 20 Release Notes; Odoo Goes Offline) 이러한 기능을 신뢰하기 전에 조직은 어떤 애플리케이션과 레코드 유형이 포함되는지, 연결을 끊기 전에 사용자가 무엇을 열거나 검색해야 하는지, 충돌이 어떻게 표시되는지, 그리고 실패하거나 지연된 동기화를 누가 모니터링하는지 확인해야 합니다.
롤아웃 결정에는 지원되는 장치와 배포 환경, 저장 및 보존 동작, 접근 제어 결과, 맞춤형 모듈 결과, 그리고 삭제 또는 그 밖의 중대한 변경에 대한 절차도 기록해야 합니다. 제공된 릴리스 자료는 이러한 구현 질문에 답하지 않지만, 확인된 기능이 특정 오프라인 워크플로에 적합한지는 이를 통해 결정됩니다. (Odoo 20 Release Notes; Odoo Goes Offline)
커뮤니티 에디션 계획의 경우, Odoo Nightly의 stable 및 recommended 목록은 명시된 버전 상태를 제공하며, 지원은 Odoo 23까지 이어집니다. (nightly.odoo.com) 운영 승인 여부는 여전히 사용자가 오프라인으로 사용할 정확한 빌드, 모듈, 권한, 워크플로를 테스트한 결과에 따라 결정되어야 합니다. 확인된 변경 사항은 Odoo 20이 큐에 넣은 오프라인 생성 및 수정을 허용함으로써, Odoo 19의 이전에 열어 둔 레코드에 대한 읽기 전용 접근을 넘어선다는 점입니다. 테스트는 해당 기능이 조직의 구성에서 어떻게 동작하는지 입증해야 합니다. (Odoo 19.0 문서: 일반 오프라인 모드; Odoo 20 릴리스 노트; Odoo 오프라인 전환)