개발팀 인계

이 문서는 사이트의 「개발팀 인계」 화면에서 그대로 뽑은 것이다. 화면이 진실이므로, 내용이 바뀌면 다시 내려받으면 된다.

넘기는 것

[그대로 가져간다] 조회 API 초안 한 벌

• 위치: docs/api-proposal/
• 매퍼 SQL(권한 확인·일정 조회·호출 기록), 컨트롤러, 서비스, 매퍼 인터페이스, 요청·응답 샘플, 신규 옵션 정의. 제품과 같은 스택(Java·MyBatis·Oracle)으로 짜여 있어 브랜치에 넣고 바로 컴파일할 수 있다.
• 주의 — 참고자료가 아니라 초안 코드다. 다만 한 번도 컴파일·실행해 본 적이 없다 — 개발서버가 없어 검증하지 못했다. 첫 작업이 곧 검증이다.

[보기만 한다] 연동 콘솔 화면

• 위치: 이 사이트 1~4단계
• 고객사가 구글 쪽 설정을 스스로 끝내도록 만든 화면이다. 계정 종류가 왜 방식보다 먼저인지, 개인 지메일이면 무엇이 달라지는지, 무엇이 캘린더에 나가고 무엇이 가려지는지가 전부 화면에 나온다. 문서보다 빠르게 읽힌다.
• 주의 — Next.js·TypeScript라 제품 스택과 다르다. 이 코드를 고치거나 옮기지 않는다 — 눌러 보는 명세로 쓴다.

[보기만 한다] 결정과 그 이유

• 위치: 5240 준비사항(/prep)
• 9개 항목이 「왜 필요한가 / 확인한 사실 / 5240에서 할 일」로 나뉘어 있다. 「반드시」 배지가 붙은 것은 놓치면 사고가 나는 판단이다.
• 주의 — 규칙에 이유가 함께 적혀 있는 까닭은, 이유 없는 규칙이 개발 중에 「합리적으로」 바뀌기 때문이다. 규칙을 바꾸려면 여기 적힌 이유부터 반박해야 한다.

[보기만 한다] 개발기획문서

• 위치: docs/handoff/
• 기능정의서를 시작으로 인터페이스 정의서·데이터 매핑·비기능·테스트 시나리오·테스트 자동화 전략을 둔다.

[5240이 계속 운영한다] 온보딩 도구로서의 이 사이트

• 위치: google.insapien.co.kr
• 연동이 제품에 들어가도 고객사는 여전히 구글 쪽 설정(클라이언트 생성·동의화면·캘린더 공유·직원 공지)을 스스로 해야 한다. 그 창구가 이 콘솔이다. 제품은 동기화를 맡고 콘솔은 셋업과 진단을 맡는다.

개발팀이 만들 것

먼저 할 세 가지

1. API 초안을 컴파일·실행해 본다 — 미실행 상태이므로 여기서 시작한다. 매퍼를 등록하고 신규 옵션을 정의한 뒤, 샘플 요청으로 응답이 나오는지까지 확인한다.
2. ORGF_LINE 실행 계획을 잰다 — 조직 범위 계산이 행마다 함수를 부르는 구조다. 직원 수가 많은 고객사에서 여기서 느려진다 — 제품에 넣기 전에 실데이터로 재야 되돌리는 비용이 작다.
3. 콘솔 미리보기와 응답을 대조한다 — 같은 기간·같은 설정으로 뽑아 결과가 일치하는지 본다. 미리보기가 「무엇이 나가야 하는가」를 이미 보여주므로, 이 대조가 그대로 인수 기준이 된다.

교체 지점

연동이 제품에 들어가도 이 콘솔은 온보딩 도구로 남는다. 아래 세 군데만 바꾼다.