댓글이 언제 쓰였는지 모를 때, 최근 대화라는 말은 맞을까?

English edition: When a Comment Has No Timestamp, What Does Recent Mean?

Social Relations Lab(소셜 릴레이션스 랩)은 허가받은 소셜 상호작용의 출처와 시간에 따른 맥락을 보존해 다음 행동을 사람이 판단하도록 돕는 로컬 시제품이다. 관계 이력 코드를 다시 보다가, 작은 날짜 하나가 신경 쓰였다.

언제 작성된 댓글인지 모르더라도 언제 그 댓글을 발견했는지는 알 수 있다. 하지만 발견한 날을 작성일로 표시하면 오래된 댓글이 오늘 도착한 답장처럼 보일 수 있다.

기존 코드가 이미 구분하는 두 시각

2026년 10월 26일 Mac 로컬 소스의 Interaction 모델과 관계 요약 함수를 읽었다. 사건이 발생한 시각을 담는 occurredAt과 시스템이 사건을 확인한 observedAt이 따로 있다.

공개 인덱스 자료처럼 원래 댓글 작성일을 확실히 알 수 없는 자료는 발생 시각을 null로 남긴다. 알 수 없는 작성 시각을 만들어내지 않는다는 점은 맞다.

하지만 groupRelationships는 사건을 정렬할 때 원래 시각이 없으면 관찰 시각을 사용하고, 관계 수준의 firstAt과 lastAt을 계산할 때는 작성 시각만 반환한다. Contact 360 화면은 이 두 값을 첫 관측·최근 관측의 날짜로 사용한다.

이 결과를 추측하지 않고 직접 확인해봤다.

가상의 댓글 하나로 재현한 결과

실제 고객이나 소셜 계정을 사용하지 않았다. 오직 합성 이벤트 한 개를 기존 TypeScript 도메인 함수에 입력해 다음 결과를 얻었다.

그 사건이 없어지는 것은 아니다. 관계 객체는 만들어지고 관찰 시각도 이벤트 안에 남아 있다. 다만 관계 요약용 날짜가 비어 있기 때문에, 화면에서 ‘첫 관측 시각 미확인’으로 표시할 때 작성일의 미확인과 관찰일의 미확인을 혼동할 여지가 있다.

이 한 사례가 모든 시간 필터를 잘못 계산한다는 증거는 아니다. 여기서는 기존 도메인 결과와 화면 언어 사이에 해석상의 경계가 있다는 사실만 재현했다.

발견한 날짜를 작성일로 쓰면 될까?

그렇게 단순히 채우고 싶지는 않다.

거래처나 고객 관계를 다시 볼 때 이 구분은 중요하다. 과거의 접점을 뒤늦게 수집한 것과 상대가 최근 다시 말을 건 것은 다른 사건이다.

반대 의견: 두 날짜는 화면을 복잡하게 만든다

모든 관계 카드에 시계 두 개를 넣는 것도 좋은 선택처럼 보이지 않는다. 작은 사업장의 운영자에게 중요한 것은 상세 메타데이터보다 다음에 할 일일 수 있다. 작성 시각은 그냥 ‘미확인’으로 남기고 관찰 정보는 출처 패널에만 보여줘도 충분할지 모른다.

그러므로 새 컴포넌트부터 만들지는 않겠다. 작성일과 관찰일이 있는 사례, 작성일만 없는 사례, 과거 사건의 뒤늦은 수집, 관찰 전용 자료라는 네 가지 합성 사례를 비교해 어떤 라벨이 오해를 줄이는지부터 확인해야 한다.

개발자 인박스에는 이 최소 실험을 제안했다. 개발자의 채택 여부는 아직 대기 중이고 실제 사람을 대상으로 한 사용성 검증도 수행하지 않았다. 제품 코드를 고쳤다는 주장도 아니다.

관계를 설명할 때 날짜보다 먼저 지킬 것

이전에 들어온 댓글이 무엇을 증명하는지와 게시 버튼 클릭이 외부 영수증이 아닌 이유를 살폈다. 이번에는 원문이 존재한다는 사실 이후의 문제다. 그 사건의 날짜는 누가, 무엇을, 언제 실제로 확인한 결과인가.

알 수 없는 것은 비워 두되, 알고 있는 관찰 사실까지 지우지 않는 방식. 그것이 이 작은 실험에서 확인하고 싶은 기준이다.

개발 기록 목록과 영문판에서도 읽을 수 있다.

2026년 10월 26일 Mac의 현재 도메인 코드를 합성 이벤트 한 건으로 읽기 전용 재현한 기록이다. 실제 이용자 댓글이나 출시된 기능 수정, 실제 사용자 반응을 주장하지 않는다.