Odoo를 다루다 보면 곳곳에서 context라는 단어를 보게 됩니다. 필드 정의, XML 뷰 속성, 파이썬 코드 곳곳에서 등장하지만, 많은 개발자나 컨설턴트에게는 ‘필요할 때는 알아서 잘 작동하다가’ 갑자기 문제를 일으키는 미묘한 요소로 남아있습니다.
Context를 잘 이해하면 단순한 UI 자동 입력부터 검색·계산 로직의 결과까지 데이터 모델 전반에 미치는 영향을 바로잡을 수 있습니다. 간단한 Odoo 커스터마이징이든, 모듈 개발이든 Context 설계를 제대로 해두면 추후 디버깅 시간이 크게 줄어듭니다.
이 가이드는 Context가 무엇인지, Odoo 전반에서 어떻게 전달되는지, 실무에서 어떻게 안전하게 활용할지 핵심만 정리합니다.
Odoo에서의 Context란 무엇인가요?
Odoo에서 Context는 요청과 함께 전달되는 작은 파이썬 딕셔너리입니다. 전통적인 의미의 필드 타입이 아니며, ORM에 fields.Context() 같은 타입이 존재하지 않습니다. 대신 Context는 필드나 동작의 동작 방식을 바꾸는 보조 정보로 사용됩니다.
쉽게 말하면 눈에 보이지 않는 지시문 세트입니다. ‘이 필드는 이 값으로 미리 채워라’, ‘보관된 레코드도 보이게 해라’, ‘계산할 때 영어가 아닌 프랑스어를 써라’, ‘관련 레코드 선택창에는 이 도메인만 보여라’ 같은 행동을 제어합니다.
Context가 등장하는 위치
Odoo 데이터 모델 전반에서 Context는 주로 세 군데에서 마주칩니다:
- 파이썬에서의 필드 정의: Many2one, One2many, Many2many 같은 관계형 필드의
context파라미터. - XML 뷰 속성: form, list, kanban 뷰의
<field>태그에 붙는context속성. - ORM 환경: 파이썬 코드에서
self.env.context로 읽고,self.with_context(key=value)로 변경할 수 있는 환경 컨텍스트.
세 경우 모두 본질은 같습니다. 런타임에 필드나 레코드의 동작을 규정하는 추가 정보를 함께 전달하는 것입니다.
Odoo 데이터 모델에서 Context는 어떻게 동작하나요?
Context는 사용자가 폼을 열 때부터 레코드를 저장할 때까지 요청 흐름을 타고 전파됩니다. 주요 동작 원리를 실제 예시와 함께 정리하면 다음과 같습니다.
default_*로 기본값 주기
가장 흔히 쓰이는 패턴 중 하나는 default_field_name 형식의 키입니다. default_로 시작하는 키를 전달하면 새 레코드 생성 시 해당 필드를 미리 채워 넣습니다.
예를 들어 버튼이 새 견적 폼을 열면서 {"default_partner_id": 42}를 context로 넘기면 고객 필드가 자동으로 ID 42인 거래처로 채워진 상태로 폼이 뜹니다. 별도 파이썬 로직 없이도 사용자는 미리 채워진 폼을 보게 됩니다.
이 패턴은 레코드 간 스마트한 네비게이션과 워크플로우를 만드는 데 자주 활용됩니다.
관계형 필드의 context 속성
Many2one, One2many, Many2many 필드를 정의할 때 context 파라미터를 줄 수 있습니다. 이 Context는 해당 관계형 필드가 팝업이나 드롭다운으로 레코드를 로드·생성할 때 적용됩니다.
실무 예시: res.partner를 참조하는 Many2one에 context={"default_is_company": True}를 주면, 그 필드에서 새 거래처를 생성할 때 ‘법인 여부’ 체크박스가 기본 선택된 상태로 생성됩니다. 사용자를 특정 방향으로 유도하되 강제하지는 않습니다.
XML 뷰에서의 Context
뷰 XML의 context 속성은 같은 역할을 하지만 동적으로 계산할 수 있습니다. Odoo의 평가 문법을 사용해 다른 필드 값을 참조할 수 있습니다.
이런 방식으로 한 필드의 동작을 다른 필드 값에 따라 바꾸는 지능형 폼을 만들 수 있습니다. 추가 파이썬 코드를 쓰지 않고도 관계형 동작을 제어하는 핵심 기법입니다.
파이썬에서 Context 읽기·수정하기
모델 메서드 내부에서는 self.env.context로 현재 Context 딕셔너리를 읽을 수 있습니다. 호출 시점의 전체 정보를 확인할 수 있습니다.
Context를 변경해 코드를 실행하려면 self.with_context(key=value)를 사용하세요. 이는 원본을 건드리지 않고 변경된 Context를 가진 새로운 레코드셋을 반환합니다. 불변성에 맞는 깔끔한 패턴입니다.
자주 쓰이는 내장 Context 키
Odoo는 자체적으로 몇몇 예약된 Context 키를 사용해 프레임워크 동작을 제어합니다:
lang: 번역된 필드 값을 어떤 언어로 표시할지 지정합니다.active_test:False로 설정하면 보관(archived)된 레코드도 검색에 포함됩니다.no_recompute: 저장된 계산 필드의 재계산을 막습니다.mail_notrack: write 작업 시 채터(변경 이력) 트래킹을 끕니다.allowed_company_ids: 멀티컴퍼니 환경에서 레코드 가시성을 제어합니다.bin_size: Binary 필드에 대해 바이너리 내용 대신 파일 크기를 반환하게 합니다.
이런 내장 키들을 알고 있으면 별도 코드 없이도 Odoo 동작을 제어할 수 있어 핵심적인 Odoo 개발 가이드의 일부분이 됩니다.
업무 적용 사례
Context는 개발자용 도구에 그치지 않고 업무 문제를 해결하는 데 실질적으로 유용합니다. 일반적인 구현에서 자주 보는 다섯 가지 사례를 소개합니다.
1. CRM: 새 리드 작성 시 영업팀 자동 지정
영업 매니저가 자신의 팀으로 필터된 칸반에서 ‘신규’ 버튼을 누르면 해당 팀으로 리드가 자동 배정되길 기대합니다. 액션에 default_team_id를 넘기면 폼이 열릴 때 팀이 미리 채워져 실수 배정이 줄어듭니다.
2. 영업: 고객 세그먼트에 따른 가격표 기본값 지정
영업 담당자가 특정 고객 카테고리에서 견적을 만들면 Context로 default_pricelist_id를 전달해 적절한 가격표가 기본 설정되도록 할 수 있습니다. 선택은 보장하되 사용자가 다른 값을 고를 자유는 남깁니다.
3. 재고: 이동 전표에서 창고별 위치 필터링
창고 운영에서 전표 작성 시 출발지 위치 드롭다운을 특정 창고 소속 위치만 보이게 하려면 Many2one 필드에 Context로 도메인을 전달하면 UI를 깔끔하게 유지하면서 실수를 줄일 수 있습니다.
4. 회계: 다국어 청구서 라인
국제 고객에게 청구서를 발행할 때 lang Context를 넘기면 제품명·설명이 고객 언어로 표시됩니다. 내부 데이터가 영어로 저장되어 있어도 고객에게는 현지어로 보이게 할 수 있습니다.
5. 커스텀 모델: 특정 뷰에서 보관된 제품 함께 보기
운영팀이 단종(보관)된 제품을 활성 제품과 함께 검토해야 할 때, 액션 Context에 active_test: False를 넣으면 해당 뷰에서만 보관된 제품이 나타납니다. 파이썬 코드를 바꾸지 않아도 특정 화면에서만 동작합니다.
필드에 Context 추가·커스터마이즈하기
필드에 Context를 추가하거나 바꾸는 방법은 두 가지 경로가 있습니다: 코드 없이 빠르게 설정하는 Odoo Studio, 또는 파이썬·XML로 완전한 제어를 하는 기술적 방법. 어떤 상황에서 어느 방법을 쓸지 아는 것이 중요합니다.
Odoo Studio 이용하기
Odoo Studio로는 코드 작성 없이 일부 필드 속성을 바꿀 수 있습니다. 관계형 필드에 대해 새 레코드 생성 시 적용할 기본값을 Studio에서 설정할 수 있습니다.
간단한 경우—회사, 팀, 카테고리, 담당자 등—에는 유용하지만, 다른 필드 값을 참조하는 동적 Context는 Studio에서 제한적입니다. 그럴 땐 기술적 접근이 필요합니다.
Studio로 설정한 Context는 뷰 자체에 저장된다는 점을 기억하세요. 나중에 동일 뷰를 기술적으로 확장하면 Studio가 남긴 Context와 충돌할 수 있으니 기존 설정을 반드시 확인해야 합니다.
파이썬에서 필드에 Context 정의하기
커스텀 모듈에서는 필드 정의에 직접 Context를 넣습니다. Many2one의 context 파라미터는 정적인 딕셔너리를 받습니다:
이 정적 Context는 필드가 관련 레코드를 로드하거나 생성할 때마다 동일하게 적용됩니다. 현재 레코드 상태에 따라 바뀌게 하려면 뷰 수준에서 처리해야 합니다.
XML 뷰에서 Context 정의하기
뷰 XML의 context 속성은 런타임에 평가되는 문자열을 받습니다. 다른 필드값, 현재 사용자 ID(uid), 활성 레코드 ID(active_id) 등 다양한 변수를 참조할 수 있습니다:
이 때문에 뷰 수준의 Context는 필드 수준보다 훨씬 유연합니다. 한 필드의 행동이 다른 필드에 따라 달라져야 할 때 표준적으로 쓰이는 방식이며, 사용자에게 자연스러운 동작을 제공하는 핵심 기법입니다.
윈도우 액션으로 Context 전달하기
Context는 ir.actions.act_window 레코드에 설정할 수도 있습니다. 메뉴나 버튼이 여는 뷰로 Context를 전달하는 일반적인 방법이며, 액션의 context가 뷰가 로드될 때 세션 Context에 병합됩니다.
CRM의 팀 자동 배정 사례처럼 네비게이션 맥락마다 다른 기본값을 주려면 액션에 Context를 두는 것이 가장 깔끔합니다. 모델 코드에는 손대지 않고도 화면별 기본 동작을 만들 수 있습니다.
권장 실무 가이드
Odoo에서 Context를 다룰 때 몇 가지 일관된 습관을 들이면 훨씬 안정적으로 작업할 수 있습니다. 모듈 개발이든 간단한 커스터마이징이든 적용 가능한 원칙들입니다.
- Context는 권유용이지 강제용이 되게 하라. Context로 준 기본값은 사용자를 유도하는 데 적합합니다. 강제하려면 도메인이나 onchange, 제약(constraint)을 사용하세요.
- 동적인 Context는 뷰에 두라. 필드 수준의 Context는 정적입니다. 현재 레코드 상태에 따라 달라져야 한다면 뷰 XML에서 처리하는 것이 맞습니다.
- env.context를 직접 변경하지 말고 with_context()를 쓰라. Odoo 환경은 호출 내에서 불변으로 다루는 것이 안전합니다. 변경이 필요하면
with_context()로 새 환경을 만드세요. - 전달하는 키는 신중하게 줄일 것. Context는 호출 체인을 따라 쌓입니다. 불필요한 키를 많이 넣으면 다른 코드의 조건 분기들을 의도치 않게 활성화할 수 있습니다.
- 조건 플래그용으로 Context를 활용하라. 예: 위자드에서 왔음을 표시하는
from_wizard: True같은 불리언 플래그를 넣어 계산이나 onchange에서 분기하면 모델에 상태 필드를 추가하지 않고도 처리가 가능합니다. - 커스텀 Context 키를 문서화하라. Context 키는 UI에 보이지 않으므로 어떤 키를 쓰는지 코드 주석이나 모듈 문서에 남겨두면 나중에 유지보수가 쉬워집니다.
자주 빠지는 함정
Context 관련 버그는 UI상으로 보이지 않아 추적이 어렵습니다. 실무에서 자주 나오는 실수들을 정리하면 원인 파악에 큰 도움이 됩니다.
default_*를 필수값처럼 여기는 실수
Context로 준 기본값은 폼을 통해 레코드를 생성할 때만 적용됩니다. ORM에서 코드로 레코드를 생성할 때 해당 Context를 넘기지 않으면 기본값이 적용되지 않습니다. field의 파이썬 default와 동일하게 동작한다고 기대하면 안 됩니다. 코드에서 레코드를 만들 때는 필요한 Context를 명시적으로 전달하세요.
Context 딕셔너리를 직접 변경하는 실수
Context 딕셔너리는 호출 체인에서 공유됩니다. self.env.context를 직접 변경하면 같은 트랜잭션 내에서 다른 코드에 부작용을 줄 수 있습니다. 항상 self.with_context(new_key=value)로 새 환경을 만드세요.
너무 많은 데이터를 Context에 넣는 실수
추가한 모든 키가 호출 체인을 통과합니다. 일부 Odoo 메서드는 특정 Context 키의 존재 여부로 동작을 바꾸므로 예상치 못한 키가 의도치 않은 분기를 유발할 수 있습니다. Context는 필요한 것만 최소한으로 담으세요.
보관된 레코드 검색 시 active_test를 깜빡하는 경우
기본적으로 search(), search_read() 등은 보관된(active=False) 레코드를 제외합니다. 보관된 레코드까지 처리해야 하면 Context에 active_test: False를 명시적으로 전달해야 합니다. 이 실수는 재고나 제품 관련 커스터마이징에서 자주 발생합니다.
Studio와 커스텀 코드 간 Context 충돌
Odoo Studio가 뷰의 필드에 Context를 설정해 놓은 상태에서 기술적 뷰 확장을 하면 Context가 서로 충돌하거나 XML 병합 순서에 따라 덮어써질 수 있습니다. 뷰를 상속해 수정하기 전에는 기존 Context 설정을 반드시 확인하세요. 이는 Studio와 모듈 기반 커스터마이징을 섞을 때 특히 빈번한 문제입니다.
맺음말
Context는 Odoo 안에서 많은 일을 조용히 처리하는 메커니즘입니다. 필드 정의, 뷰 속성, ORM 환경을 통해 어떻게 전파되는지 이해하면 데이터 모델 동작을 훨씬 더 세밀하게 제어할 수 있습니다.
핵심 요약은 간단합니다. 사용자를 유도하려면 default_* 키를 사용하고, 동적인 Context는 뷰에 두며, Context를 바꿀 때는 with_context()를 사용하고, 불필요한 키는 넣지 마세요. 이렇게 하면 시스템의 다른 부분에 예기치 않은 영향을 주지 않습니다.
Odoo 필드 튜토리얼을 보던 중이든 맞춤 모듈을 만들고 있든, 또는 이상 동작을 디버그하고 있든 Context 이해는 항상 문제 해결의 핵심입니다.
저희 Dasolo는 기업이 실제 업무 흐름에 맞게 Odoo를 도입·커스터마이즈·최적화하도록 돕습니다. Context 관련 설정이 불확실하거나 구현을 논의하고 싶으시면 기꺼이 도와드리겠습니다.
저희 팀에 연락하려면 문의 페이지 를 통해 어떤 솔루션을 만들고 계신지 알려주세요. 다양한 규모의 기업과 협업하며 Odoo가 제 역할을 하도록 돕고 있습니다.