Odoo의 한 가지 수정으로 하루에 12분을 절약하는 방법

Odoo Community는 리드에서 이메일을 보낼 때 저장된 연락처를 받는 사람으로 자동으로 넣지 않습니다. 찾고, 입력하고, 선택하기: 이메일당 약 15초가 걸립니다. 별것 아닌 것 같지만 CRM에서 영업팀이 하루에 보내는 이메일 수와 곱해보면 달라집니다. 계산식은 아래에 있습니다; 실제 고객 사례가 아니라 산술적 계산이며, 고객님께서 자신의 계산을 하시려면 한 가지 숫자만 필요합니다.

이 글은 왜 Odoo 표준 동작이 영업팀에 불리하게 작용하는지, 수정 방법이 무엇인지, 그리고 언제 시스템 교체보다 목표된 수정이 더 나은 해답인지 보여드립니다.

문제: 비어 있는 수신자 필드

Odoo Community Edition을 CRM으로 사용하시는 분은 아마 경험하셨을 것입니다: 리드를 열고 "E-Mail senden"을 클릭하면 메일 작성기가 열리는데 수신자 필드가 비어 있습니다.

리드에 연락처가 저장되어 있고 이메일 주소도 있습니다. 하지만 작성기가 그것을 가져오지 않습니다.

결과는 매번 동일합니다:

1. 수신자 필드에 연락처 이름을 입력합니다
2. 드롭다운 목록에서 올바른 연락처를 선택합니다
3. 그제야 실제 이메일을 작성합니다

이 작업은 이메일당 약 15초가 걸립니다. 별것 아닌 것처럼 들립니다.

아무도 하지 않는 계산

하지만 계산해보면: CRM에서 하루 약 50통의 이메일을 보낸다면 하루 약 12분의 시간 손실입니다 — 원래 이미 존재하는 수신자를 수동으로 입력하는 데만 걸리는 시간입니다.

한 달로 보면 4시간 이상입니다. 연간으로 환산하면 직원당 약 50시간입니다.

연 50시간. 시스템이 자동으로 처리해야 할 작업 때문에 발생하는 시간입니다.

그리고 이건 측정 가능한 부분에 불과합니다. 실제 손해는 더 미묘합니다: 클릭 하나하나는 산만해지거나 흐름을 잃거나 이메일을 아예 작성하지 않게 만드는 지점입니다. 특히 영업에서는 속도가 중요하므로 모든 불필요한 장애물이 계약 손실로 이어질 수 있습니다.

당연해 보이는 해결책 — 그리고 왜 틀린가

명백한 답은: Odoo Enterprise를 구매하는 것입니다. 그쪽은 메일 작성기가 더 잘 작동하고 기능과 지원이 더 많습니다.

하지만 Odoo Enterprise는 사용자당 월별 라이선스입니다. 10명 팀이라면 월 수백 유로 이상이 금방 나갑니다 — 핵심적으로는 누락된 한 줄의 코드 때문에요.

이것이 Odoo Enterprise에 반대하는 주장은 아닙니다. 업그레이드가 타당한 경우도 많습니다. 그러나 문제의 전부가 비어 있는 수신자 필드 하나라면 라이선스 전환은 과잉 대응입니다.

우리의 해결책: 한 개의 Python 파일

문제를 분석한 결과: Odoo Community의 메일 작성기는 CRM 리드에서 열릴 때 리드에 저장된 연락처를 고려하지 않습니다. 이는 전형적인 버그라기보다 해당 로직 자체가 빠져 있는 상황입니다.

해결책은 최소한의 Odoo 모듈로, 한 가지 일만 합니다: 메일 작성기가 CRM 리드에서 열리면 그 리드의 연락처를 자동으로 수신자로 입력합니다.

그게 전부입니다. 새로운 메뉴도, 새로운 데이터베이스 필드도, 설정도 없습니다. 메일 작성기의 CRM 리드에 대한 동작을 확장하는 단 하나의 Python 파일뿐입니다. 그 외에는 전혀 변경이 없습니다.

이전

"E-Mail senden"을 클릭하면 작성기가 열리고 — 수신자 필드가 비어 있습니다. 연락처 이름을 입력하고 드롭다운을 기다렸다가 올바른 항목을 클릭합니다. 그제야 작성할 수 있습니다.

이후

"E-Mail senden"을 클릭하면 작성기가 열리고 — 수신자가 이미 입력되어 있습니다. 바로 작성할 수 있습니다.

왜 이 얘기를 하는가

기술적으로 대단해서가 아니라 정반대의 이유로 말합니다. 이 사례는 우리가 반복해서 보는 패턴을 보여줍니다:

작고 구체적인 문제가 큰 비용의 결정으로 이어집니다.

• "메일 작성기가 귀찮다"가 "Odoo Enterprise가 필요하다"로 변합니다
• "표가 복잡하다"가 "새 ERP가 필요하다"로 변합니다
• "리포팅이 부족하다"가 "BI 플랫폼이 필요하다"로 변합니다

때로는 큰 해결책이 맞습니다. 그러나 흔히 먼저 물어볼 가치가 있습니다: 정확히 무엇이 문제이며, 그것을 해결하는 가장 작은 방법은 무엇인가?

언제 수정으로 충분하고 언제 새 소프트웨어가 필요한가?

목표 수정으로 충분한 경우:

• 문제가 명확히 한정되어 있고 — 기능 누락이나 프로세스 결함인 경우
• 기존 소프트웨어가 기본적으로 적합하고 팀이 수용하는 경우
• 수정이 유지보수 가능하고 취약한 특수해결책이 아닌 경우
• 수정 비용이 시스템 교체 비용보다 훨씬 낮은 경우

새 소프트웨어가 적절한 경우:

• 여러 근본적 요구사항이 충족되지 않는 경우
• 기존 시스템이 더 이상 개발되지 않는 경우
• 아키텍처가 구조적으로 맞지 않는 경우 — 예: API 부재, 멀티테넌시 미지원
• 우회로 작업 비용이 라이선스 비용을 초과하는 경우

결론

이 예시는 의도적으로 작게 잡았습니다. 혁명이 아니라 태도에 관한 것입니다: 새 소프트웨어를 찾기 전에 이미 가진 것을 자세히 살펴볼 가치가 있습니다.

우리는 이 수정을 매일 사용합니다. 시간과 스트레스를 절약해주며 분석과 개발에 들인 몇 시간 외에 비용은 들지 않았습니다.

참고로 이 모듈은 Odoo App Store에 오픈 소스로 무료로 제공됩니다 — 이런 기본적인 워크플로우 수정은 모든 Odoo Community 사용자가 이용할 수 있어야 한다고 생각하기 때문입니다.

고객님 시스템에 비슷한 문제가 있으신가요? 종종 한 번의 대화로 목표 수정이 가능한지 판단할 수 있습니다 — 비싼 대안을 고려하기 전에요.