1인 회사 콕핏 데이터를 오늘 화면으로 모으는 백엔드 설계

1인 회사의 오늘 화면은 할 일 목록만 보여주는 페이지가 아니에요. 매출, 문의, 배포 상태, 콘텐츠 발행처럼 흩어진 데이터를 같은 기준으로 읽게 만드는 작은 운영 화면에 가깝습니다. 문제는 데이터를 많이 모으는 데 있지 않아요. 서로 다른 시간대와 형식의 데이터를 안전하게 묶는 백엔드 설계에 있습니다.

직접 만들어 보니, 첫 API부터 외부 서비스 응답을 화면에 그대로 넘기면 금방 관리가 어려워졌어요. 서비스마다 날짜 형식, 상태값, 식별자가 달라서 프론트엔드가 예외 처리 장소가 되기 때문이에요. 그래서 수집 데이터는 원본과 화면용 요약을 분리하는 편이 낫습니다.

수집 API 또는 n8n→정규화 테이블→오늘 화면 API

먼저 events처럼 공통 이벤트 테이블을 둡니다. 최소한 source, event_type, occurred_at, payload, dedupe_key 5개 필드를 정하면 출처가 달라도 같은 흐름으로 저장할 수 있어요. payload에는 원본 일부를 보관하고, 화면에서 필요한 제목·상태·링크는 별도 컬럼이나 조회 모델로 꺼냅니다. 5개 필드가 모든 문제를 해결하지는 않지만, 새 데이터원을 붙일 때 기준점이 됩니다.

적용해 봤더니 중요한 것은 중복 방지였어요. 수집 작업이 재시도되면 같은 이벤트가 2번 들어올 수 있습니다. source와 외부 식별자를 조합한 dedupe_key에 고유 제약을 두고, 저장은 upsert로 처리하면 반복 실행에도 결과가 안정적이에요. 24시간 집계와 최근 7일 추세도 원본을 매번 계산하기보다 요약 테이블에 미리 적재하면 오늘 화면 API가 단순해집니다.

인증은 수집 권한과 조회 권한을 나눠야 해요. 수집용 토큰은 서버 또는 자동화 도구만 사용하고, 브라우저에는 전달하지 않습니다. 조회 API는 로그인한 사용자 기준으로 데이터를 제한하며, 조직 단위 확장이 필요하다면 모든 테이블에 소유자 식별자를 둡니다. 테스트해 보면 권한 없는 사용자가 다른 사람의 이벤트 ID를 요청하는 경우를 먼저 막아야 한다는 점이 분명해져요.

• ✓원본 보존
• ✓중복 방지
• ✓조회 권한 분리

n8n은 수집과 알림을 연결하는 역할로 두고, 업무 규칙은 API와 DB 제약에 남기는 구성이 좋아요. 예를 들어 3단계 수집 흐름이 실패했을 때도 마지막 성공 시각, 실패 사유, 재시도 횟수는 DB에 남겨야 운영 화면에서 원인을 확인할 수 있습니다. 돌려 보니 자동화 실행 이력만 보고 상태를 판단하는 방식은 누락된 데이터를 발견하기 어려웠어요.

라이프케어로그가 플랜씨(plan-c), 플랜비(plan-b), 플랜엘(plan-l)처럼 서로 다른 제품을 다룰 때도 같은 원칙을 적용할 수 있어요. 제품별 세부 데이터는 분리하되, 오늘 확인할 운영 신호는 공통 이벤트 계약으로 모으는 방식입니다. 화면 하나를 먼저 만들기보다 데이터 계약 1개를 먼저 고정하면 이후의 API 추가가 훨씬 예측 가능해져요.