CRM에 저장했는데 휴대폰엔 없다: SmartNexus Google Contacts 동기화와 배포 알림

CRM에 Lead를 저장했는데 휴대폰 연락처에는 없고, 배포가 실패했는데 브라우저를 열기 전까지 모르는 일이 반복됐습니다. 이번 단계에서는 고객 기록과 운영 알림을 사람이 다시 옮기지 않아도 이어지게 만들었습니다.

SmartNexus 개발일지 ⑩ · 2026년 9월 11일 · 약 6분

고객 기록이 두 곳에 따로 있으면 결국 한쪽이 낡는다

SmartNexus에서 이메일 Lead를 만들고도 전화하려면 Google Contacts에 다시 이름과 번호를 입력해야 했습니다. 반대로 휴대폰에만 저장한 연락처는 CRM의 Listing, NDA와 Follow-up 맥락을 갖지 못했습니다. 두 시스템을 완전히 합치는 대신 SmartNexus를 업무 기준으로 두고 연락에 필요한 최소 정보를 Google Contacts로 보내는 방향을 택했습니다.

이름, 이메일과 전화번호만 같다고 무조건 새 연락처를 만들면 중복이 늘어납니다. 기존 연락처를 먼저 검색하고, 이미 있으면 SmartNexus와 관련된 메모를 보완했습니다. 외부 서비스의 식별자를 CRM에 남겨 다음 동기화가 같은 대상을 찾도록 했습니다.

저장 버튼은 연락처 API를 기다리지 않게 했다

Google API 응답을 기다리는 동안 Lead 저장 화면이 멈추면 사용자는 버튼을 다시 누르기 쉽습니다. 네트워크가 느리거나 권한이 만료됐을 때 CRM의 핵심 저장까지 실패하는 것도 피해야 했습니다. 그래서 Lead 저장을 먼저 끝내고 연락처 동기화는 백그라운드 대기열에서 처리했습니다.

동기화가 실패해도 Lead는 남습니다. 실패 상태와 원인을 확인한 뒤 수동으로 다시 실행할 수 있게 했고, 같은 사용자에 대한 변경 요청은 순서를 지키도록 했습니다. 외부 주소록은 편의를 위한 연결이지 CRM 데이터의 생존 조건이 아니기 때문입니다.

NDA와 OM을 보낸 뒤에도 연락처를 놓치지 않기

처음 Lead가 들어올 때만 동기화하면 수동 등록한 Client나 나중에 보완된 전화번호가 빠질 수 있습니다. Client 상세 화면에서 직접 동기화할 수 있게 하고, NDA나 OM을 보내는 실제 업무 시점에도 연락처 상태를 점검했습니다. 다만 문서 발송 성공 여부와 연락처 동기화 성공 여부는 분리했습니다.

이 구분은 중요했습니다. 연락처 API가 잠시 실패했다고 NDA 발송까지 실패로 표시하면 사용자가 같은 문서를 다시 보낼 수 있습니다. 각 작업의 결과를 따로 남기고, 연락처 실패는 별도의 후속 조치로 보여줬습니다.

배포 알림은 성공보다 실패를 빨리 아는 장치다

Railway 배포 화면을 계속 열어보는 방식은 오래 가지 못합니다. 프로젝트 Webhook이 배포 상태 변화를 SmartNexus로 보내고, 필요한 사건만 Telegram으로 전달하도록 했습니다. 요청 주소에는 추측하기 어려운 보안키를 사용하고 서버 환경변수에서 읽도록 해 코드와 화면에 값을 남기지 않았습니다.

Webhook은 알림의 출발점이지 최종 진실로 보지 않았습니다. 전달 순서가 바뀌거나 재시도가 발생할 수 있어 deployment ID와 상태를 함께 확인했습니다. 알림을 받은 뒤에는 Railway와 앱의 version·commit 표시를 대조하는 흐름을 유지했습니다.

자동화의 핵심은 실패가 서로 번지지 않는 것

CRM 저장, Google Contacts, 문서 발송과 Telegram 알림은 하나의 긴 성공·실패로 묶지 않았습니다. 핵심 데이터는 먼저 보존하고 외부 연동은 각각 결과를 기록했습니다. 덕분에 어느 한 서비스가 느려도 Lead 접수와 다음 업무는 계속할 수 있습니다.

운영 화면에는 “동기화됨”뿐 아니라 마지막 시도 시각과 실패 여부가 필요했습니다. 성공만 보여주는 자동화는 문제가 생긴 순간 조용해집니다. 사용자가 재시도할 수 있는 지점과 지원 요청에 필요한 정보를 함께 두는 것이 실제 운영에서는 더 중요했습니다.

연락처 메모에는 내부 거래정보를 전부 복사하지 않았습니다. 휴대폰에서 상대를 알아보는 데 필요한 출처와 최소 맥락만 남기고, 자세한 Listing·문서 상태는 SmartNexus에서 확인하게 했습니다. 외부 주소록에 데이터를 많이 보내는 것보다 어느 시스템이 원본인지 분명히 하는 편이 수정과 삭제에도 유리했습니다.

어떤 정보를 주소록으로 보낼지도 별도 기준이 필요했다

연락처 동기화라고 해서 CRM의 모든 메모를 휴대폰 주소록으로 복사하지 않았습니다. 거래 상태, 내부 판단과 문서 검토 내용은 SmartNexus에 남기고, 주소록에는 이름·전화번호·이메일과 업무 구분에 필요한 짧은 메모만 보냈습니다. 외부 서비스에 저장되는 정보의 범위를 줄이면 권한을 다시 연결하거나 계정을 바꿀 때도 정리하기 쉽습니다.

기존 연락처와 값이 다를 때의 우선순위도 정했습니다. 비어 있는 항목은 보완하되 사용자가 Google Contacts에서 직접 관리한 값을 무조건 덮어쓰지는 않았습니다. 확실하지 않은 충돌은 자동 병합보다 확인 대상으로 남겼습니다. 자동화가 빠르더라도 사람의 최신 기록을 조용히 지우면 신뢰를 잃기 때문입니다.

알림은 행동할 수 있을 때만 유용했다

Telegram에는 성공·실패라는 단어만 보내지 않았습니다. 프로젝트, 환경, deployment ID, commit과 확인 링크를 함께 넣어 알림을 받은 자리에서 다음 행동을 정할 수 있게 했습니다. 같은 배포의 반복 이벤트는 묶고, 정상적인 중간 상태까지 모두 알리지 않아 중요한 실패가 메시지 사이에 묻히지 않도록 했습니다.

운영 테스트에서는 Google 권한 만료, 중복 연락처 후보, Webhook 재전송과 Telegram 전송 실패를 각각 재현했습니다. 정상 경로만 확인하면 연동은 완성된 것처럼 보이지만, 실제 품질은 외부 서비스가 잠시 멈췄을 때 CRM이 어떤 상태로 남는지에서 드러났습니다.

실무 체크리스트

FAQ

Google Contacts를 CRM 원본으로 사용하면 안 되나요?

연락에는 편리하지만 Listing, Lead, NDA와 Event 관계를 담기 어렵습니다. SmartNexus를 업무 원본으로 두고 연락에 필요한 정보만 동기화하는 편이 안전합니다.

연락처 동기화에 실패하면 Lead도 다시 저장해야 하나요?

아닙니다. Lead 저장과 외부 동기화를 분리하면 기존 기록을 유지한 채 동기화만 재시도할 수 있습니다.

Webhook 알림이 오면 배포 성공이 확정된 건가요?

알림은 상태 변화 신호입니다. 실제 운영 version, commit과 핵심 화면을 확인해 최종 판단하는 것이 좋습니다.

Telegram이 멈추면 배포도 중단되나요?

알림 실패가 배포나 서비스 실행을 막지 않도록 분리해야 합니다. 운영자는 Railway 대시보드에서도 상태를 확인할 수 있어야 합니다.

공식 자료

• Google People API: 연락처 생성
• Railway Docs: Webhooks
• Microsoft Learn: Queued Background Tasks

관련 글

• 점진적 로딩과 백그라운드 처리
• 배포 버전과 Health Check
• Client 검색과 전화번호 표준화