이 콘솔을 어떻게 이어받나
이 사이트는 5240 근태 일정을 구글 캘린더로 내보내기 위해 고객사가 할 설정과 5240이 열어 줄 것을 미리 만들어 본 것입니다. 실제 연동은 제품에 새로 개발해야 하고, 그 출발점이 여기에 있습니다. 무엇을 가져가고 무엇을 보기만 하는지부터 보시면 됩니다.
넘기는 것
성격이 셋으로 갈립니다. 이것을 오해하면 옮길 필요 없는 코드를 옮기거나, 반대로 그대로 쓸 수 있는 것을 처음부터 다시 짜게 됩니다.
docs/api-proposal/매퍼 SQL(권한 확인·일정 조회·호출 기록), 컨트롤러, 서비스, 매퍼 인터페이스, 요청·응답 샘플, 신규 옵션 정의. 제품과 같은 스택(Java·MyBatis·Oracle)으로 짜여 있어 브랜치에 넣고 바로 컴파일할 수 있다.
참고자료가 아니라 초안 코드다. 다만 한 번도 컴파일·실행해 본 적이 없다 — 개발서버가 없어 검증하지 못했다. 첫 작업이 곧 검증이다.
이 사이트 1~4단계고객사가 구글 쪽 설정을 스스로 끝내도록 만든 화면이다. 계정 종류가 왜 방식보다 먼저인지, 개인 지메일이면 무엇이 달라지는지, 무엇이 캘린더에 나가고 무엇이 가려지는지가 전부 화면에 나온다. 문서보다 빠르게 읽힌다.
Next.js·TypeScript라 제품 스택과 다르다. 이 코드를 고치거나 옮기지 않는다 — 눌러 보는 명세로 쓴다.
5240 준비사항(/prep)9개 항목이 「왜 필요한가 / 확인한 사실 / 5240에서 할 일」로 나뉘어 있다. 「반드시」 배지가 붙은 것은 놓치면 사고가 나는 판단이다.
규칙에 이유가 함께 적혀 있는 까닭은, 이유 없는 규칙이 개발 중에 「합리적으로」 바뀌기 때문이다. 규칙을 바꾸려면 여기 적힌 이유부터 반박해야 한다.
docs/handoff/기능정의서를 시작으로 인터페이스 정의서·데이터 매핑·비기능·테스트 시나리오·테스트 자동화 전략을 둔다.
google.insapien.co.kr연동이 제품에 들어가도 고객사는 여전히 구글 쪽 설정(클라이언트 생성·동의화면·캘린더 공유·직원 공지)을 스스로 해야 한다. 그 창구가 이 콘솔이다. 제품은 동기화를 맡고 콘솔은 셋업과 진단을 맡는다.
개발팀이 만들 것
1~4단계 화면과 준비 상태 점검은 이미 됩니다. 없는 것은 제품 쪽 조회 API와 실제 동기화입니다.
- F-075240 일정 조회 API
docs/api-proposal/가 초안이다. 매퍼 등록과 신규 옵션(TAA_CAL_INF_YN) 정의가 함께 필요하다. 조회 범위를 요청값이 아니라 연동 계정의 조직조회권한이 정한다는 것이 이 API의 핵심이다.
- F-08캘린더 동기화
기간 창 전체를 읽어 캘린더와 대조한다 — 없어진 것은 지우고 달라진 것은 고친다. 취소도 옵션 1426 변경도 모두 「응답에서 사라짐」으로 나타나므로 훅이나 변경분 조회가 필요 없다. 지우는 쪽 안전장치가 이 기능의 전부라 해도 된다.
- F-09동기화 결과 통지
실패와 중단(삭제 임계 초과)을 담당자에게 알린다. 조용히 멈추면 아무도 모른다.
먼저 할 세 가지
받자마자 무엇부터 할지 정해 두면 킥오프가 헛돌지 않습니다.
- API 초안을 컴파일·실행해 본다
미실행 상태이므로 여기서 시작한다. 매퍼를 등록하고 신규 옵션을 정의한 뒤, 샘플 요청으로 응답이 나오는지까지 확인한다.
- ORGF_LINE 실행 계획을 잰다
조직 범위 계산이 행마다 함수를 부르는 구조다. 직원 수가 많은 고객사에서 여기서 느려진다 — 제품에 넣기 전에 실데이터로 재야 되돌리는 비용이 작다.
- 콘솔 미리보기와 응답을 대조한다
같은 기간·같은 설정으로 뽑아 결과가 일치하는지 본다. 미리보기가 「무엇이 나가야 하는가」를 이미 보여주므로, 이 대조가 그대로 인수 기준이 된다.
이 콘솔은 버려지지 않습니다
연동이 제품에 들어가도 고객사는 여전히 구글 쪽 설정을 스스로 해야 합니다. 그 창구가 이 콘솔입니다. 교체 지점을 미리 스위치로 박아 두었습니다 — 세 군데만 바꾸면 그대로 운영 도구가 됩니다.
| 어디 | 지금 | 개발 완료 후 |
|---|---|---|
lib/oracle.ts | 데모 DB를 직접 조회한다(어댑터 경계로 끊어 두었다) | 제품 조회 API 호출로 교체한다 — 이 파일 하나만 바꾼다 |
demoOnly() | 데모 서비스영역(300) 외에는 조회를 막고 그 사실을 화면에 알린다 | 삭제한다 — 전 고객사 조회가 열린다 |
SYNC_READY | false — 「내보내기 준비 중」 문구가 화면 곳곳에 뜬다 | true로 바꾼다 — 화면 문구가 저절로 따라 바뀐다 |
규칙은 어디에 있나
연동 규칙과 그렇게 정한 이유는 5240 준비사항에 있습니다. 지금 1건이 닫혔고 8건이 열려 있습니다. 「반드시」 배지가 붙은 항목은 놓치면 사고가 나는 것들입니다 — 조직 권한 경계와 근무일정 제외가 거기 있습니다.
규칙에 이유를 함께 적어 둔 까닭이 있습니다. 이유 없는 규칙은 개발 중에 “합리적으로” 바뀝니다. 규칙을 바꾸어야겠다 싶으면 거기 적힌 이유부터 반박해 주세요 — 대개 그 이유가 고객사 사고 사례이거나 개인정보 문제입니다.
docs/handoff/(개발기획문서)와 docs/api-proposal/(API 초안)에 있습니다.