Odoo 20 업그레이드 점검 — 커스텀 모듈이 깨지는 지점

메이저 버전 업그레이드에서 비용이 발생하는 곳은 표준 기능이 아니라 커스텀입니다. Odoo 20은 이 관점에서 최근 몇 개 버전 중 영향이 큰 편입니다.

보도된 기술 변경 중 커스텀 모듈에 직접 영향을 주는 항목이 여러 건입니다. 접근 권한 체계 통합, 프론트엔드 프레임워크 변경, PDF 렌더링 엔진 교체, 아이콘 라이브러리 교체, 서버 요구사항 상향.

각각은 대응 가능한 변경이지만, 합치면 '자동 변환 스크립트로 끝나는 업그레이드'가 아니라 '모듈별 검토가 필요한 업그레이드'가 됩니다.

이 글은 무엇이 깨지는지와 점검 절차를 정리합니다. 확인일은 2026년 9월 25일이며, 내용은 파트너사·전문 매체 보도 기준입니다. 최종 근거는 Odoo 공식 업그레이드 문서입니다.

1. 접근 권한 — 두 파일이 하나로 합쳐집니다

가장 구조적인 변경입니다. 지금까지 Odoo의 권한은 두 곳에 나뉘어 있었습니다. 모델 단위 권한은 ir.model.access.csv, 레코드 단위 규칙은 ir.rule.

Odoo 20에서는 이 둘이 ir.access라는 하나의 모델로 통합된다고 전해집니다. 하나의 파일에서 권한과 도메인 조건을 같은 행에 적는 형식입니다.

권한 표기도 바뀝니다. 읽기·생성·수정·삭제를 개별 컬럼으로 두던 방식에서 CRUD 문자열(r, cru, crud) 방식으로 바뀌고, 레코드 간 접근 의존을 표현하는 새 연산자가 추가됩니다.

표준적인 경우는 자동 변환 스크립트가 처리하지만, 파이썬 코드에서 런타임에 규칙을 만들거나 조작하는 커스텀 모듈은 수작업 검토가 필요합니다. 권한 로직이 들어간 모듈이 있다면 이 항목을 최우선으로 잡으십시오.

2. 프론트엔드 — OWL 3로 올라갑니다

Odoo의 프론트엔드 프레임워크 OWL이 3 버전으로 올라간다고 전해집니다. 커스텀 JavaScript 컴포넌트를 만든 조직에 직접 영향을 줍니다.

전해진 변경은 이렇습니다. t-ref가 시그널 방식으로 바뀌고, props는 useProps로 읽으며, 정적 기본 props 선언이 금지됩니다.

즉 커스텀 컴포넌트는 전수 검토 대상입니다. Odoo가 owl3-migration.py라는 변환 도구를 제공한다고 전해지지만, 변환 도구는 기계적인 부분을 처리할 뿐 동작 검증을 대신해 주지는 않습니다.

위젯, 커스텀 뷰, 대시보드 컴포넌트를 만든 조직이라면 이 항목에 가장 많은 시간이 듭니다. 견적을 받을 때 컴포넌트 개수를 기준으로 공수를 산정하십시오.

3. PDF — wkhtmltopdf에서 Paper Muncher로

보고서·인보이스 출력에 쓰이던 PDF 렌더링 엔진이 wkhtmltopdf에서 Paper Muncher로 교체된다고 전해집니다.

렌더링 엔진 교체는 레이아웃이 미묘하게 달라진다는 뜻입니다. 여백, 줄바꿈, 폰트 렌더링, 페이지 분할 위치가 바뀔 수 있습니다.

국내 기업에서 특히 확인해야 할 것은 한글 폰트 렌더링과 고정 양식입니다. 거래명세서, 견적서, 세금계산서 양식처럼 칸 위치가 정해진 문서는 한 칸만 밀려도 다시 만들어야 합니다.

점검 방법은 단순합니다. 실제로 쓰는 출력 문서를 전부 목록으로 만들고, 업그레이드 테스트 환경에서 하나씩 뽑아 기존 출력물과 비교하십시오. 이 작업은 개발이 아니라 확인이므로 현업이 직접 할 수 있습니다.

4. 아이콘 — Font Awesome에서 Material Symbols로

아이콘 라이브러리가 Font Awesome에서 Material Symbols로 교체된다고 전해집니다.

영향 범위는 커스텀 뷰와 커스텀 템플릿입니다. XML에서 fa- 접두 클래스를 직접 쓴 곳은 모두 깨지거나 빈 칸으로 표시됩니다.

기능이 멈추는 변경은 아니지만 화면이 어색해지고, 사용자는 '업그레이드하더니 이상해졌다'고 느낍니다. 정착률에 영향을 주므로 가볍게 보지 마십시오.

점검 방법은 커스텀 모듈 전체에서 아이콘 클래스 문자열을 검색해 목록을 만드는 것입니다. 기계적인 작업이라 공수는 크지 않습니다.

5. 서버 요구사항 — Python과 PostgreSQL 버전

Python 3.12 이상, PostgreSQL 16 이상이 요구된다고 전해집니다.

자체 서버로 운영하는 조직에 직접 영향을 줍니다. 현재 버전이 낮다면 업그레이드 프로젝트에 서버 작업이 추가됩니다. 특히 PostgreSQL 메이저 버전 업그레이드는 별도 계획과 다운타임이 필요한 작업입니다.

Odoo Online이나 Odoo.sh를 쓰는 조직은 이 부분이 자동으로 처리되지만, 대신 적용 시점을 우리가 정하기 어렵습니다. 어느 쪽이 나은지는 조직의 상황에 따라 다릅니다.

자체 서버 운영 조직이라면 업그레이드 계획에 서버 작업을 별도 단계로 넣고, 데이터베이스 백업·복구 절차를 사전에 검증하십시오.

6. 용어와 데이터 — 결제 상태 표기가 바뀝니다

보도에 따르면 결제 상태 용어가 바뀝니다. 기존의 'In Process'가 'Paid'로, 기존의 'Paid'가 'Reconciled'로 변경됩니다.

이 변경은 화면 표기만의 문제가 아닙니다. 상태값을 조건으로 쓰는 자동화 규칙, 리포트 필터, 외부 시스템 연동 로직이 모두 영향을 받습니다.

특히 외부 시스템이 상태 문자열을 받아 판단하는 구조라면 연동이 조용히 잘못 동작할 수 있습니다. 오류가 나면 차라리 낫고, 오류 없이 잘못된 결과를 만드는 경우가 더 위험합니다.

점검 방법은 결제 상태를 참조하는 모든 지점을 목록화하는 것입니다. 자동화, 리포트, 연동, 커스텀 코드 네 곳을 각각 확인하십시오.

7. 업그레이드 시점을 언제로 잡을 것인가

기술 점검과 별개로 시점 판단이 필요합니다. 여기에 Odoo 약관 조항이 영향을 줍니다.

Enterprise 구독 약관 5.1항은 지원이 종료된 버전을 계속 사용할 경우 연 25% 추가 요금 조항을 두고 있습니다. 즉 업그레이드를 무기한 미루는 선택에는 비용이 붙습니다.

반대로 메이저 버전 공개 직후는 안정화가 진행되는 구간입니다. 일반적으로는 공개 직후가 아니라 몇 개월 뒤가 안전하다고 봅니다.

실무적인 판단은 세 가지를 비교하는 것입니다. 지금 올릴 때의 검증 공수, 한 버전 건너뛸 때의 누적 변경량, 구버전을 유지할 때의 약관상 추가 비용. 세 숫자를 같은 표에 놓고 결정하십시오.

8. 점검 절차 — 다섯 단계

1단계, 인벤토리. 설치된 모듈 전체를 뽑아 표준·서드파티·자체 개발로 분류합니다. 이 목록이 없으면 견적을 받을 수 없습니다.

2단계, 영향 매핑. 각 커스텀 모듈이 위 여섯 항목 중 어디에 걸리는지 표시합니다. 권한 로직, JS 컴포넌트, PDF 템플릿, 아이콘, 결제 상태 참조.

3단계, 테스트 환경 구축. 운영 데이터 사본으로 업그레이드를 시도하고 결과를 기록합니다. 운영 환경에서 처음 시도하는 것은 선택지가 아닙니다.

4단계, 현업 검증. 출력 문서, 주요 화면, 핵심 업무 흐름을 현업이 직접 확인합니다. 개발자가 보는 것과 현업이 보는 것이 다릅니다. 5단계, 전환 계획. 다운타임, 롤백 조건, 공지, 교육을 문서로 정합니다.

9. 확인되지 않은 것

이 글의 기술 변경 내용은 파트너사·전문 매체 보도를 기준으로 한 것이며, Odoo 공식 업그레이드 문서 원문을 직접 인용하지 못했습니다. 실제 작업 전에 공식 문서로 확인하십시오.

자동 변환 스크립트가 처리하는 범위와 수작업이 필요한 범위의 경계는 모듈 구현 방식에 따라 다릅니다. 일반화할 수 없습니다.

버전별 지원 종료 일정과 약관 조항의 적용 방식은 계약 조건에 따라 달라지므로 계약서로 확인해야 합니다.

업그레이드 공수는 커스텀 모듈의 개수가 아니라 복잡도에 좌우됩니다. 모듈 수만으로 견적을 산정하면 실제와 크게 차이 납니다.

커스텀 모듈이 깨지는 지점

출처: 파트너사·전문 매체 보도 (2026.09.25 확인) · 최종 근거는 Odoo 공식 업그레이드 문서입니다 · 자동 변환 범위는 모듈 구현 방식에 따라 다릅니다

업그레이드 시점 비교

업그레이드를 무기한 미루는 선택에도 비용이 붙습니다. 약관 조항의 적용 여부는 계약서로 확인하십시오

자주 묻는 질문

Q. 업그레이드 공수를 어떻게 산정하나요?

모듈 개수가 아니라 복잡도로 산정해야 합니다. 권한 로직이 들어간 모듈, 커스텀 JS 컴포넌트 수, PDF 템플릿 수, 외부 연동 지점 수를 각각 세십시오. 이 네 숫자가 공수를 결정합니다. 모듈 수만으로 받은 견적은 실제와 크게 차이 납니다.

Q. Odoo Online을 쓰면 신경 안 써도 되나요?

서버 요구사항은 자동으로 처리되지만 커스텀 관련 항목은 그대로 적용됩니다. Studio로 만든 화면과 자동화, 연동 로직은 확인 대상입니다. 또한 적용 시점을 우리가 정하기 어렵다는 점을 감안해야 합니다.

Q. 테스트 환경 없이 바로 올리면 안 되나요?

안 됩니다. 운영 데이터 사본으로 업그레이드를 시도하고 결과를 기록하는 단계는 생략할 수 없습니다. 특히 PDF 출력물과 결제 상태 참조 로직은 오류 없이 잘못 동작할 수 있어, 테스트에서 걸러내지 못하면 운영 중에 발견됩니다.

Q. 당장 올릴 계획이 없는데 지금 할 일이 있나요?

모듈 인벤토리를 만드십시오. 설치된 모듈을 표준·서드파티·자체 개발로 분류한 목록입니다. 이 목록은 업그레이드 시점과 무관하게 필요하고, 만드는 데 하루면 됩니다. 이것이 없으면 어느 시점에 결정하든 견적을 받을 수 없습니다.

이 글이 다루지 않는 것

이 글은 Odoo 20 업그레이드 시 커스텀 모듈에 영향을 주는 기술 변경과 점검 절차를 다룹니다. 개별 변경의 구체적인 코드 수정 방법, 버전별 지원 종료 일정, 계약별 약관 적용 조건은 다루지 않습니다. 내용은 파트너사·전문 매체 보도 기준이며 최종 근거는 Odoo 공식 업그레이드 문서입니다.

함께 읽으면 좋은 글

이 글은 P3 구축과 운영 시리즈의 일부입니다.

• Odoo 20 발표 정리 — 실제로 무엇이 바뀌었나 (P1)
• Odoo 20 라이선스 개편 — Custom 인상과 Light User 신설 (P2)
• ERP 구축 전에 정리해야 할 업무 데이터 일곱 가지 (P3)

출처

• Forrester, The State Of Business Buying, 2024 (2024.12) — forrester.com/press-newsroom
• 6sense, 2025 B2B Buyer Experience Report (2025.11) — 6sense.com
• Gartner B2B 구매자 조사 (2025.05 발표, 632명) — gartner.com/en/newsroom
• Salesforce, State of Sales 6th·7th Edition (2024.07 / 2026.02) — salesforce.com
• Odoo 공식 가격 페이지 (2026.09.12 확인) — odoo.com/pricing
• Odoo Enterprise Subscription Agreement 5.1·5.2항 (약관 2025.12.19) — odoo.com/documentation/19.0/legal/terms/enterprise.html
• Odoo 19.3·19.4 릴리스 노트 — odoo.com/odoo-19-3-release-notes, odoo-19-4-release-notes
• Odoo 고객 사례 — odoo.com/blog/customer-reviews-6

본문의 원화 환산은 1 USD = 1,380원, 기준일 2026년 9월 12일을 적용했습니다. 요금과 약관은 변경될 수 있으므로 계약 전 공식 페이지에서 재확인하십시오.