서문
Odoo를 도입한 것은 시작일 뿐입니다. 어디에, 어떻게 호스팅하느냐는 시스템 구조의 핵심 결정으로서 커스터마이징, 시스템 연동, 업그레이드 전략, 그리고 장기 유지관리성에 직접적인 영향을 줍니다.
호스팅을 단순한 기술적 세부사항으로 여기는 경우가 많지만, 사실 이는 ERP의 유연성, 시간이 흐르며 안전하게 진화하는 정도, 그리고 운영팀이 감당해야 할 운영 복잡도를 규정합니다.
이 글은 현재 실무에서 Odoo가 어떻게 쓰이는지를 바탕으로, Odoo Online, Odoo.sh, 커스텀/온프레미스 배포라는 세 가지 주요 호스팅 선택지을 실용적·구현 중심 관점에서 설명합니다.
호스팅이 생각보다 더 중요한 이유
호스팅 선택이 결정하는 것들:
- 업무 로직을 어디에, 어떻게 구현할지
- 외부 시스템과의 연동 방식
- 버전 업그레이드의 난이도와 전략
- 직접 관리해야 할 인프라의 범위
- 문제 발생 시 책임의 귀속
Odoo Online: 대다수 경우의 기본 권장안
Odoo Online은 Odoo사가 직접 제공하는 완전 관리형 SaaS 서비스입니다.
다솔로에서는 대부분의 프로젝트에 이 옵션을 권장하는 경우가 많습니다.
왜 Odoo Online이 많은 기업에 적합한가
Custom 요금제를 선택하면 Odoo Online에서 API 접근을 활성화할 수 있는데, 이는 적용 가능한 아키텍처를 근본적으로 바꿉니다.
API가 열리면 Odoo Online은 다음을 허용합니다:
- 복잡한 백엔드 업무를 외부 서비스에서 처리
- 서드파티 시스템과의 심층 연동
- AI 서비스, 자동화 엔진, 미들웨어 결합
- Odoo 코어를 수정하지 않는 커스텀 로직 구현
복잡한 로직을 Odoo 내부에 억지로 넣는 대신, Odoo의 API를 안정적이고 구조화된 인터페이스로 삼아 주변에 로직을 배치하는 접근이 가능합니다.
Odoo Online의 주요 장점
- 관리할 인프라가 없음
- 보안 패치 자동 적용
- 예측 가능한 의무적 버전 업그레이드
- 높은 안정성과 신뢰성
- 총 보유 비용(TCO) 절감
특히 Odoo Online을 유지하면 버전 업그레이드가 크게 단순화되는데, ERP 프로젝트에서 이 부분을 과소평가하는 경우가 많습니다.
분명히 이해해야 할 제약 사항
Odoo Online은 커스텀 Python 모듈, 서버·데이터베이스 직접 접근, Odoo 내부의 깊은 프론트엔드 수정을 허용하지 않습니다.
이 제약은 의도된 것입니다. 올바르게 활용하면 Odoo를 운영의 핵심으로 남겨두고 복잡성은 전용 외부 서비스로 분리하는 깔끔한 아키텍처를 유도합니다.
Odoo.sh: 유효한 선택이지만 기본값은 아니다
Odoo.sh는 관리형 호스팅과 Git 기반 개발 워크플로를 결합한 PaaS 제공입니다.
Odoo.sh가 적절한 경우
프로젝트가 Odoo 내부에서 직접 프론트엔드를 광범위하게 커스터마이징해야 할 때 Odoo.sh가 의미를 가집니다. 예를 들어:
- 심층적으로 변경된 Odoo UI 컴포넌트
- Odoo 내부에 직접 구현된 비표준 사용자 흐름
- 특정 성능 또는 런타임 요구 조건
이런 상황에서는 코드베이스 접근과 구조화된 배포 파이프라인이 실질적 가치를 제공합니다.
흔히 오해되는 점
많은 프로젝트에서 커스텀 인터페이스가 반드시 Odoo.sh를 필요로 하지는 않습니다.
외부 웹 애플리케이션이나 Odoo 내부에 iframe으로 삽입되는 인터페이스를 API로 연결하면, Odoo Online의 단순함을 유지하면서 맞춤형 사용자 경험을 제공할 수 있습니다.
Odoo.sh 요약
Odoo.sh는 유효한 호스팅 선택지이나, 본질적인 필요를 해결할 때만 선택되어야 합니다. 무조건 기본값이 되어선 안 됩니다.
커스텀·온프레미스 호스팅: 완전한 자유와 그에 따른 책임
커스텀 호스팅은 클라우드든 사내 서버든 운영자가 인프라를 완전 통제하는 배포 형태입니다.
커스텀 호스팅이 적절한 경우
다음과 같은 상황에서는 커스텀/온프레미스 배포가 필요합니다:
- 데이터를 반드시 로컬 또는 회사 소유 서버에 보관해야 할 때
- 엄격한 규제·컴플라이언스 요구가 적용될 때
- 인프라 수준의 세밀한 제어가 필요할 때
커스텀 호스팅이 열어주는 가능성
커스텀 호스팅은 다음을 제공합니다:
- 인프라에 대한 완전한 제어
- 고급 성능 최적화
- 복잡한 백그라운드 처리
- 상세한 모니터링 및 로깅
- 제한 없는 연동
대가
하지만 이 자유에는 인프라 유지관리, 보안, 백업, 업그레이드, 및 운영 모니터링에 대한 책임이 따릅니다.
적절한 문맥에서는 커스텀 호스팅이 완벽한 해결책이 될 수 있으나, 명확한 소유권과 강한 기술적 규율이 필요합니다.
호스팅, 연동, 그리고 장기 아키텍처
호스팅 선택은 연동 설계 방식에도 직접적인 영향을 미칩니다.
- Odoo Online은 API 우선, 서비스 지향 아키텍처를 선호합니다
- Odoo.sh는 Odoo 내부에서의 밀착 결합을 허용합니다
- 커스텀 호스팅은 복잡성을 감내하는 전면적 통제를 가능하게 합니다
목표는 단순한 유연성이 아니라, 아키텍처의 명확성입니다.
호스팅과 업그레이드: 장기 관점으로 설계하기
업그레이드는 호스팅 선택이 결정적이 되는 지점입니다.
- Odoo Online에서는 업그레이드가 자동적이고 예측 가능합니다
- Odoo.sh에서는 업그레이드가 관리 가능하지만 제약적입니다
- 커스텀 호스팅에서는 업그레이드가 전적으로 귀사의 책임입니다
로직을 Odoo 바깥에 둘수록 장기적으로 업그레이드가 쉬워집니다.
다솔로에서 Odoo 호스팅 결정을 내리는 방식
다솔로는 호스팅을 단순 기술 항목이 아닌 아키텍처적 결정으로 다룹니다.
설정을 권고하기 전에 우리는 다음을 평가합니다:
- 실제 비즈니스 워크플로
- 연동 복잡도
- 예상 성장 규모
- 컴플라이언스 및 데이터 제약
- 내부 기술 역량
대부분의 경우, Odoo Online과 API 중심 아키텍처의 결합이 장기적으로 최선의 선택입니다. 다른 옵션은 습관적으로 선택하지 않고 명확한 이유가 있을 때만 택합니다.
결론
Odoo 호스팅은 ERP 프로젝트의 기술적 토대를 결정합니다.
Odoo Online은 제한된 선택지가 아닙니다. 올바르게 사용하면 가장 깔끔하고 안전하며 확장 가능한 선택인 경우가 많습니다.
Odoo.sh와 커스텀 호스팅도 그 복잡성이 정당화될 때는 유용한 도구입니다.
좋은 호스팅 결정은 통제 그 자체가 목표가 아니라, 명확성, 책임 소재, 그리고 장기 유지관리성에 관한 것입니다.