Salesforce 콜로깅(Log a Call) 하면 오늘 날짜로 찍히는 이유: Task 데이터 모델의 구조적 문제
결론 요약입니다.
Salesforce에서 어제 한 Log a Call을 오늘 입력해도 Activity Timeline에는 오늘 날짜로 찍힙니다.
CompletedDateTime이 시스템 자동 생성 read-only 필드이기 때문입니다. 수동 수정은 불가능하며, 우회책은 Due Date(ActivityDate) 필드를 Log a Call 레이아웃에 추가해 영업사원이 직접 과거 날짜를 입력하게 하는 것 뿐입니다. 이 글은 그 우회가 왜 존재하는지, 이 문제가 왜 기능 결함이 아니라 1999년 Task 데이터 모델이 만든 구조적 한계인지를 다룹니다.
하루에 전화를 열 번 하는 날이 있습니다.
중요한 딜이 여러 개 동시에 돌아갈 때는 그게 당연합니다. 통화하면서 메모하고, 끊고 나면 다음 전화 준비하고, 어느새 저녁입니다. CRM 업데이트는 그다음입니다. 영업을 해본 사람이라면 이 순서가 낯설지 않을 겁니다. 통화 직후마다 Salesforce 열고 Log a Call 누르는 사람은 없습니다. 있다면 통화보다 입력에 더 신경 쓰는 사람이거나, 하루에 통화를 두 번 하는 사람입니다.
Salesforce State of Sales 리포트에 따르면 영업사원은 일주일의 28%만 실제 영업에 씁니다. 나머지 72% 중 상당 부분이 CRM 입력입니다. 이게 의지의 문제가 아니라는 방증이고, 소급 입력이 예외가 아니라 기본값이 된 이유입니다.
며칠 뒤 파이프라인 정리하다 발견했습니다. 중요한 딜의 팔로업 통화가 CRM에 빠져 있었습니다. Log a Call을 열고, 날짜를 통화 날짜로 맞추고, 내용을 입력하고 저장했습니다. Activity Timeline을 확인했더니 — 오늘 날짜가 찍혀 있었습니다.
통화는 3일 전에 했는데, 타임라인은 오늘 날짜로 찍혀 있었어요.
처음엔 내가 뭔가 잘못한 줄 알았는데 날짜 필드를 다시 확인해봤는데 맞게 입력되어 있었습니다. 다시 저장해봤는데도 여전히 오늘 날짜더라고요. 버그가 아니었습니다.
ActivityDate와 CompletedDateTime: 둘 다 실제 통화 시각을 담는 필드가 아닙니다
하나는 ActivityDate. 화면에는 "마감일(Due Date)"로 표시됩니다. 사용자가 직접 입력할 수 있습니다.
다른 하나는 CompletedDateTime. Salesforce Winter '22 릴리즈에서 추가된 이 필드는 Task의 Status가 "Completed"로 바뀌는 순간 시스템이 현재 시각을 자동으로 기록합니다. 공식 API 문서에 read-only로 명시되어 있습니다. 사용자는 수정할 수 없습니다.
이 두 필드 중 어느 쪽에 "실제로 통화가 일어난 시각"을 넣어야 할까요.
공식 문서에 답이 없습니다. Log a Call 퀵 액션의 기본 레이아웃에는 두 필드 중 어느 것도 노출되어 있지 않습니다. 수동 입력이든 Fireflies 같은 자동화 도구를 통한 API 동기화든 소급 로깅을 시도하는 사람들이 수년간 Salesforce 커뮤니티에 올린 질문들에도 명확한 답이 나온 적이 없습니다. 매번 돌아오는 답은 "수정할 수 없다" 또는 "우회하라"입니다.
둘 다 실제 통화 시각을 담기 위해 설계된 필드가 아닙니다.
전화 통화를 Task로 분류한 순간 벌어진 일
Salesforce가 전화 통화를 어떻게 취급하는지 이해하려면, Task라는 단어 자체를 먼저 봐야 합니다.
Task는 할 일 목록의 항목입니다. 체크리스트의 단위입니다. Task의 본질은 완료 여부입니다. "이걸 했는가, 안 했는가." 어떻게 했는지, 그 과정에서 무슨 일이 있었는지는 Task라는 개념 안에 처음부터 존재하지 않습니다.
"고객에게 전화한다" — Task. 체크. 끝.
그 통화에서 고객이 뭐라고 했는지, 어떤 반응이었는지, 경쟁사 얘기가 나왔는지, 목소리 톤이 이번 달 들어 처음으로 부드러워졌는지. 이 모든 것은 Task가 담도록 설계된 정보가 아닙니다. Task는 처리해야 할 일을 처리했는지 확인하는 도구입니다. 내용을 기록하는 도구가 아닙니다.
ActivityDate는 "마감일"입니다. Task 철학 — "언제까지 해야 하는가" — 에서 나온 필드입니다. 실제 발생 시각을 담기 위한 그릇이 아닙니다.
CompletedDateTime이 read-only인 것도 이 철학과 완벽하게 일관됩니다. Task에서 중요한 건 "언제 완료했는가"가 아니라 "완료했는가"입니다. 시스템이 체크된 순간을 자동으로 기록해주면 충분합니다. 정확한 완료 시각은 Task의 관심사가 아니었습니다.
Salesforce가 1999년에 전화 통화를 Task로 분류한 순간, 설계 차원에서 이미 선언한 겁니다. 전화 통화는 처리해야 할 일이다. 그 안에서 무슨 대화가 오갔는지, 언제 실제로 일어났는지는 우리 관심 밖이다.
Salesforce의 Activity 데이터 모델은 두 개의 버킷으로 나뉩니다. Event와 Task입니다. Event는 "언제 일어났는가"가 핵심인 객체입니다. StartDateTime과 EndDateTime이 first-class 필드로 존재하고, 둘 다 사용자가 자유롭게 설정할 수 있습니다. 캘린더 미팅을 3일 전으로 만들면 3일 전 이벤트로 정확하게 기록됩니다. 미팅에 대해서는 "언제 실제로 일어났는가"가 객체의 정체성이라는 걸 Salesforce도 인정한 겁니다.
그런데 유독 20년 넘게 전화 통화만 인정하지 않았습니다.
IdeaExchange에 수년째 쌓이는 같은 불만
Salesforce 커뮤니티가 수년간 호소해온 불만들은 모두 같은 뿌리에서 나옵니다.
IdeaExchange에 올라온 요청들 — "CompletedDateTime을 수정 가능하게 해달라", "Activity Timeline이 실제 통화 날짜 기준으로 정렬되어야 한다". Trailblazer 포럼에 반복되는 불만 — "로그 날짜가 오늘로 나온다", "소급 입력이 왜 안 되냐". 이들이 수년째 받고 있는 답은 한결같습니다. CompletedDateTime은 read-only 시스템 필드입니다. 수정 방법이 없습니다.
대신 공식 커뮤니티에서 통용되는 우회책이 하나 있습니다. "Due Date 필드를 Log a Call 퀵 액션 레이아웃에 추가해서, 영업사원이 과거 날짜를 직접 입력하게 하라."
이 우회가 의미하는 바를 보세요. 영업사원들은 수년째 "마감일"이라는 의미의 필드에 "실제 발생 시각"을 구겨 넣고 있습니다. 데이터 모델이 현실과 맞지 않기 때문에, 사용자가 필드 의미를 왜곡하는 방식으로 시스템을 쓰고 있는 겁니다. 이 우회가 수년간 사실상의 기본 대응책으로 통용되고 있다는 사실 자체가, 이 글이 말하려는 구조적 문제의 가장 선명한 증거입니다.
Winter '22에 CompletedDateTime 필드가 추가된 건 사실 IdeaExchange 커뮤니티 요청의 결과였습니다. Salesforce 공식 블로그는 "여러분이 요청했고 우리가 들었습니다. 이 기능은 Winter '22 릴리즈에서 14,000포인트 이상을 받은 최고 득표 아이디어였습니다"라고 발표했습니다. 커뮤니티의 원래 요청 취지는 "실제 완료 시간을 수동으로 입력할 수 있게 해달라"는 것이었습니다. Salesforce는 그 요청을 듣고, "시스템이 자동으로 기록해줄게"로 해석해서 read-only 필드로 만들었습니다.
들었지만 이해하지 못한 셈입니다. 정확히는, Task 프레임 안에서 해석한 겁니다. Task 프레임 안에서는 "사용자가 완료 시간을 직접 입력한다"는 요청 자체가 성립할 여지가 없습니다. Task는 체크리스트이고, 체크는 찍는 순간 시스템이 자동으로 기록하는 것이지 사용자가 소급해서 입력하는 것이 아니니까요.
Gong, Salesloft, Outreach 같은 세일즈 인게이지먼트 툴들도 동일한 벽에 부딪힙니다. 이들 툴이 Salesforce에 통화를 동기화할 때도 결국 Task로 밀어 넣을 수밖에 없고, CompletedDateTime은 동기화 시점으로 자동 고정됩니다. 세계에서 가장 많이 쓰이는 세일즈 인텔리전스 툴들이 수년간 이 Task 프레임 안에서 작동하고 있었습니다.
1999년, 통화를 Task로 분류한 건 합리적 선택
Salesforce가 설계된 1999년에 전화 통화를 Task로 분류한 건 당시 맥락에서는 합리적인 선택이었습니다.
그 시대에 통화는 휘발되는 것이었습니다. 음성인식 기술이 없었고, 실시간 녹취와 트랜스크립션은 존재하지 않았습니다. 통화가 끝나면 그 대화 안에서 오간 내용은 영업사원의 기억 속에만 남았습니다. 기억은 희미해지고, 그 기억을 토대로 입력한 메모는 불완전했습니다.
그 환경에서 CRM이 할 수 있는 최선은 "이 고객에게 언제 전화했다"는 사실을 기록하는 것이었습니다. 대화 내용을 구조화된 데이터로 남기는 건 기술적으로도 현실적으로도 불가능했습니다. 전화 통화는 고객을 향한 루틴한 팔로업 행위였고, 그 행위를 체크리스트 방식으로 추적하는 Task 모델은 당시엔 충분했습니다.
통화 직후 자리에 앉아 CRM을 업데이트하는 것이 가능한 환경 — 사무실 전화기로 전화하고, 책상에서 바로 기록하던 시대 — 을 가정하면, 소급 로깅이 문제가 되지 않았습니다. 통화하고 바로 입력하면 날짜가 맞으니까요.
그 전제가 깨지면 이 모델 전체가 깨집니다.
2026년, AI 시대의 통화 데이터는 Log a Call, 즉 Task가 담을 수 없음
지금은 다릅니다.
Fireflies, Gong, Chorus 같은 도구들은 통화를 실시간으로 녹취하고 트랜스크립트를 만듭니다. AI는 그 트랜스크립트에서 고객이 언급한 경쟁사, 예산 규모, 의사결정 구조, 다음 스텝, 감정적 온도를 자동으로 추출합니다. 하나의 전화 통화 안에 수백 개의 구조화된 데이터 포인트가 존재합니다.
대화는 더 이상 휘발되지 않습니다. 통화가 끝나도 원본이 남습니다. 그 원본을 AI가 분석하면 CRM 필드가 자동으로 채워질 수 있습니다. 통화 안에서 고객이 한 말이 딜의 가장 신뢰할 수 있는 데이터 소스가 됩니다.
이 변화는 전화 통화의 본질적인 위상을 바꿔놓습니다. 통화는 수백 개의 데이터 포인트를 담고 있는 원본 인터랙션입니다. 난중일기가 2,539일치 기록을 남겼을 때의 가치와 "오늘 전투했음" 한 줄의 차이처럼, 통화 트랜스크립트 전체와 "전화했음" 한 줄의 차이는 이제 데이터의 차원이 다릅니다.
그런데 Salesforce의 데이터 모델은 여전히 "전화했음" 한 줄을 담기 위한 Task입니다. 언제 그 통화가 실제로 일어났는지조차 정확하게 기록할 수 없는 구조입니다.
CRM 데이터 정합성이 깨지면 일어나는 일
매니저가 월요일 아침 대시보드를 엽니다. "이번 주 영업 활동" 위젯에 통화 23건이 찍혀 있습니다. 숫자는 맞습니다. 그런데 그 23건 중 실제로 이번 주에 일어난 건 몇 건입니까? 파이프라인 리뷰 미팅에서 "영업사원이 일주일 동안 연락을 안 했다"고 지적합니다. 영업사원은 매일 통화했다고 합니다. 누구 말이 맞는 걸까요? CRM 데이터가 틀렸을 가능성을 아무도 먼저 생각하지 않습니다.
딜이 끝나고 회고를 합니다. 어느 시점에 고객의 반응이 식었는지, 어느 통화에서 경쟁사 얘기가 처음 나왔는지 분석하려 합니다. 타임라인이 왜곡되어 있으면 이 분석은 의미가 없습니다. 잘못된 타임라인을 기반으로 한 학습은 잘못된 패턴을 만듭니다.
예측(forecasting)에도 영향을 줍니다. 마지막 고객 접촉이 언제인지는 딜 헬스의 핵심 지표 중 하나입니다. 접촉 날짜가 실제와 다르면 딜 health check 판단이 틀립니다.
AI 에이전트가 CRM 데이터를 바탕으로 의사결정을 내리기 시작하는 순간, 틀린 타임스탬프는 단순 시각 왜곡이 아니라 AI 추론의 전제 자체를 오염시킵니다. "이 딜은 식고 있으니 개입해야 한다"를 AI가 판단할 때, 근거가 되는 "마지막 접촉일"이 실제와 다르면 잘못된 개입이 자동으로 실행됩니다. 잘못된 시점에 팔로업 이메일이 나가고, 잘못된 딜이 at-risk 리스트에 올라갑니다. Salesforce가 Agentforce를 전사적으로 밀고 있는 지금, 이 문제는 "불편함"에서 "신뢰할 수 없는 자동화"로 급이 바뀝니다.
틀린 데이터 위에서 내리는 의사결정은 없는 것보다 나쁠 수 있습니다. 그 의사결정을 AI가 자동으로 내리기 시작하면, 나쁨의 규모가 달라집니다.
Salesforce가 고치기 전, 지금 당장 적용할 수 있는 대응 방법
Salesforce가 데이터 모델을 바꾸는 데는 시간이 걸립니다. 바꾼다는 보장도 없습니다. 지금 Salesforce를 쓰는 조직이 할 수 있는 것들입니다.
Due Date 필드를 Log a Call 퀵 액션 레이아웃에 추가합니다.
현재 공식 우회책입니다. 영업사원이 통화 날짜를 직접 입력할 수 있게 하고, 팀 전체가 이 필드에 "실제 통화 시각"을 입력한다는 규칙을 공유합니다. 필드 의미가 왜곡되는 건 감수해야 하는 비용입니다.
리포트와 대시보드는 CompletedDateTime이 아니라 ActivityDate 기준으로 구성합니다.
기본 설정을 그대로 쓰면 시스템 자동 기록 시각이 기준이 되어, 소급 입력한 통화가 전부 오늘로 몰립니다. 관리자가 대시보드 기준을 명시적으로 Due Date로 바꾸지 않는 한 데이터는 왜곡된 상태로 표시됩니다.
가능하다면 Custom 필드를 하나 더 만들어 "Actual Call Time"을 명시적으로 관리합니다.
Due Date 필드가 두 가지 의미(마감일 / 실제 발생 시각)를 가지면 혼선이 생깁니다. Custom 필드를 추가하면 의미가 명확해지고, 이후 Salesforce가 모델을 바꿀 때 마이그레이션도 수월합니다.
Conversation Intelligence 도구의 call start time을 진실의 원천으로 삼습니다.
제가 가장 추천하는 방법입니다. Fireflies, Gong, Chorus는 통화가 실제로 일어난 시각을 정확하게 기록합니다. CRM은 활동 조회용으로 두고, 실제 통화가 언제 일어났는지의 원본은 Conversation Intelligence 툴에서 관리하는 아키텍처를 고려할 만합니다.
Salesforce가 Conversation Intelligence를 인수, 하지만 Task는 그대로
Salesforce는 대화 데이터의 중요성을 비즈니스 결정으로는 일찍 인식했습니다. Einstein Conversation Insights를 직접 개발해 통화를 자동으로 녹취하고 트랜스크립트를 분석합니다. 경쟁사 언급, 다음 액션, 코칭 포인트를 AI가 추출합니다. 그런데 그 분석 결과가 CRM에 저장되는 방식은 여전히 Task입니다. Salesforce가 자체 개발한 Conversation Intelligence 제품의 인사이트를 담는 그릇이 Task인 겁니다.
그리고 2026년 3월, Conversational Intelligence 플랫폼 Momentum을 인수하며 여기서 더 나아갔습니다. 세일즈포스가 Momentum에 베팅한 이유는 명확합니다. Momentum의 CEO는 인수 당시 이렇게 말했습니다. "우리는 구조화되지 않은 대화와 구조화된 액션 사이의 간극을 메우기 위해 Momentum을 만들었습니다."
Forrester는 이 인수를 이렇게 분석했습니다. "CRM 플랫폼은 오랫동안 영업사원의 의도를 반영하는 필드로 채워졌다. 구매자 관심의 진짜 신호는 구매자와 판매자 사이에 실제로 오간 대화 안에 있다."
구매자 관심의 진짜 신호가 대화 안에 있다면, 그 대화가 언제 일어났는지는 CRM에 정확하게 남아야 합니다. 전화 통화는 2026년에도 Task고, 통화가 실제로 일어난 시각은 여전히 기록할 수 없습니다. Momentum 인수까지 했는데, 데이터 모델은 손대지 않았습니다.
CompletedDateTime을 수정 가능한 필드로 만들어야 합니다. 감사 목적의 원본 기록은 별도 필드에 보존하면 됩니다. 더 나아가 전화 통화와 미팅은 Task가 아니라 독립된 Activity 객체로 정의되어야 합니다. Event처럼 시작 시간과 종료 시간을 first-class 필드로 가져야 하고, 녹취와 트랜스크립트를 native하게 연결할 수 있어야 합니다. Conversation Intelligence를 CRM 안으로 가져오겠다면, 그 대화를 담을 그릇부터 바꿔야 합니다.
1999년의 설계는 1999년의 현실에 맞았습니다. 통화는 휘발됐고, 남길 수 있는 건 사실뿐이었습니다. 2026년의 통화는 휘발되지 않습니다. 그 안에 딜의 진실이 담겨 있습니다.
그 진실을 담을 그릇이 Task인 한, Salesforce가 어떤 Conversation Intelligence 제품을 인수해도 데이터 정합성은 깨진 채로 남아 있습니다.