Introduction
5240 근태 ↔ 구글 캘린더 연동
5240에 쌓인 휴가·출장·교육 일정을 구글 캘린더로 내보내는 연동입니다. 이 사이트는 두 가지 일을 합니다 — 고객사가 구글 쪽 설정을 스스로 끝내게 돕고, 실제 시스템을 만들 개발팀에 무엇을 어떻게 만들지 넘깁니다.
지금 어디까지 와 있나
4단계고객 온보딩 — 동작합니다
1/9연동 규칙 — 닫힌 결정 / 전체
6/6개발기획문서 — 작성됨 / 전체
미구현실제 내보내기 — 개발팀 몫
지금 이 사이트는 설정하고 확인하고 안내하는 데까지입니다. 캘린더에 일정을 실제로 만드는 기능은 아직 없습니다 — 제품 쪽 조회 API와 동기화가 개발팀의 몫입니다.
사이트 구성
구역마다 보는 사람이 다릅니다. 고객사 표시가 붙은 곳만 고객에게 안내하시면 됩니다.
고객사고객용 온보딩 도구→고객사 인사담당이 구글 쪽 설정을 스스로 끝내는 곳입니다. 계정 종류 판별 → 연동 방식 선택 → 구글 연결·5240 구성 → 미리보기 → 직원 안내문까지 네 단계입니다.연동이 제품에 들어가도 고객사는 여전히 구글 쪽 설정을 직접 해야 합니다. 그 안내를 제품 화면에 다 넣기는 어렵습니다.개발팀인수 기준점→「무엇이 캘린더에 나가야 하는가」의 기대값입니다. 같은 설정·같은 기간으로 뽑은 결과를 내려받아 개발한 API의 응답과 대조합니다.테스트 시나리오를 쓸 때 가장 어려운 것이 “그래서 정답이 뭔데”입니다. 이 사이트는 그 답을 이미 화면으로 내놓고 있으므로, 인수 판정이 사람 눈이 아니라 대조로 끝납니다.개발팀개발팀 킥오프→연동 규칙과 그렇게 정한 이유입니다. 항목마다 「왜 필요한가 / 확인한 사실 / 할 일」로 나뉘고, 「반드시」가 붙은 것은 놓치면 사고가 나는 판단입니다.이유 없는 규칙은 개발 중에 “합리적으로” 바뀝니다. 규칙을 바꾸려면 여기 적힌 이유부터 반박하게 만드는 것이 이 구역의 목적입니다.개발팀개발기획문서 6종→기능정의서·인터페이스 정의서·데이터 매핑 사양·비기능정의서·테스트 시나리오·테스트 자동화 전략. 사이트에서 읽고 내려받습니다.개발 착수에 필요한 명세를 한곳에 둡니다. 저장소 접근이 없어도 사이트만으로 받아 갈 수 있습니다.개발팀개발팀 인계→무엇을 그대로 가져가고 무엇을 보기만 하는지, 개발팀이 만들 것은 무엇이고 먼저 할 일은 무엇인지 정리한 곳입니다.이것을 오해하면 옮길 필요 없는 코드를 옮기거나, 반대로 그대로 쓸 수 있는 것을 처음부터 다시 짭니다.