5240 내부용
5240 준비사항
구글 쪽은 고객사 담당자가 화면을 보고 스스로 끝낼 수 있습니다. 그러나 5240에서 열어 주어야 하는 것이 따로 있고, 그중 하나는 열리지 않으면 운영 전환 자체가 막힙니다. 이 화면은 고객사에 보이는 화면이 아닙니다.
2 막힘6 확인 필요1 준비됨
휴가·근무일정·출장 조회 API막힘 — 이게 열려야 진행
- 왜 필요한가
- 지금 콘솔은 데모 DB를 직접 읽는다. 읽기 전용 MCP가 SERVAREA_ID=300에 고정돼 있어 고객사 운영에는 그대로 쓸 수 없다. 운영은 제품 JSON API(SYS/API json, 서버 간 POST)로 옮겨야 한다.
- 확인한 사실
- 엔드포인트가 없다는 것을 확인했다(2026-08-11). JSON API 컨트롤러 URL 24개를 전수 확인한 결과 근태 쪽은 근태기 적재·PC-OFF 처리뿐이고, 조회 계열은 조직·직원·SSO·발령·결재다. 가장 가까운 결재 3종도 못 쓴다 — 기안자·결재자 조건이 박혀 개인 단위이고, 기간 필터가 기안일(APPL_YMD)이며, 휴가 기간·휴가코드가 컬럼이 아니라 렌더링된 문서 본문(CLOB) 안에 있다.
- 5240에서 할 일
- 신규 개발이 필요하고, 그것이 이 연동의 실제 착수 조건이다. 아래에 별도로 구현해 두었다 — 제품 반영 시점(브랜치·릴리스·WAS 재기동·고객사 설치본)이 정해져야 넣을 수 있다. 앱 쪽은 lib/oracle.ts 하나만 갈아끼우면 되도록 어댑터로 끊어 두었다.
별도 구현 — 제품 미반영제품에 넣을 신규 API 한 벌을 별도로 구현했다. 반영·배포는 하지 않았다.
lcy_google/docs/api-proposal/
만든 것
TaaCalendarApi_SQL.xml신규 매퍼 SQL 3개 — 권한 확인, 일정 조회(휴가·근무일정·출장 한 번에), 호출 기록(CMMT_MSG_LOG)TaaCalendarController.javaPOST /getTaaCalendarApiList.do — 기존 24개 URL과 같은 모양TaaCalendarServiceImpl.java입력 확인 → 키 확인 → 조회 → 기록TaaCalendarMapper.java매퍼 인터페이스sample-request.json / sample-response.json요청·응답 형태option-TAA_CAL_INF_YN.md가정한 신규 옵션(연동 사용여부·사이트ID·인터페이스 키)의 정의README.md왜 새로 만드는지, 무엇을 판단했는지, 무엇을 확인하지 못했는지
내린 판단
- 엔드포인트는 하나로 묶고 kindCds로 갈래를 고른다. 셋으로 나누면 키 확인도 세 번, 기간·조직 조건도 세 곳에서 관리해야 한다.
- 조회 범위는 연동 계정의 조직조회권한(AUTT_SRCH_BASE 111 + ORGF_LINE)이 정한다. 제품 홈 화면이 쓰는 바로 그 패턴이다. 요청의 orgCd는 그 안에서 더 좁히기만 한다 — 키가 새도 전사 인사정보가 통째로 나가지 않는다.
- 옵션 1426(HIDE_LEAV_CDS)은 API에서 적용한다. 미표시 코드는 응답에 넣지 않고, 마스킹 코드는 MASK_YN으로 표시해 내보낸다. 연동 쪽에 규칙을 복사하면 제품과 기준이 갈린다.
- 기간은 겹치면 뽑는다. 지금 콘솔의 데모 조회는 시작일만 봐서 달을 걸친 휴가가 빠지는데, 이 API에서는 고쳤다.
- 상태 기본값은 결재요청(20)·결재완료(30). 임시저장·반려는 캘린더에 나가면 안 된다.
- 조회 실패와 빈 결과를 구분한다. 빈 배열을 "휴가가 없다"로 읽으면 이미 등록한 일정을 몽땅 지운다.
아직 확인하지 못한 것
- 실행해 보지 않았다 — 컴파일도 쿼리 실행도 하지 않았다. 검증하려면 kiwibox 빌드 환경과 WAS가 필요하다.
- 조직 범위 계산이 행마다 ORGF_LINE을 부르는 구조라, 직원 수가 많은 고객사에서 느려질 수 있다. 실데이터 실행 계획을 재 봐야 한다.
- 근무일정은 기간별 신청(TAAT_WKTYPE_REQ)만 담았다. 변경·조직 단위·근무조 신청은 테이블이 따로라 캘린더에 무엇을 실을지 정한 뒤 분기를 더해야 한다.
- 취소·삭제 통지는 여전히 없다(change 항목 그대로). 연동 쪽이 기간 전체를 다시 받아 대조해야 한다.
OAuth 동의화면 게시·검증막힘 — 이게 열려야 진행
- 왜 필요한가
- 동의화면이 「테스트」 상태면 테스터 목록에 넣은 계정만 로그인된다. 목록은 100명이 한도이고, 이 상태에서 받은 리프레시 토큰은 7일 뒤 만료된다 — 주기 동기화가 일주일마다 끊긴다는 뜻이다. 고객사 담당자가 화면대로 따라와도 마지막 로그인에서 막히면 앞 단계가 모두 헛일이 된다.
- 확인한 사실
- 테스터가 아닌 개인 지메일(tykwon210@gmail.com)로 로그인하니 「액세스 차단됨: insapien.co.kr은(는) Google 인증 절차를 완료하지 않았습니다 / 403 오류: access_denied」로 끊겼다. 화면 갈무리는 refer/액세스차단.png에 있다.
- 5240에서 할 일
- 동의화면을 프로덕션으로 게시한다. 캘린더 쓰기 스코프는 민감 스코프로 분류돼 구글 검증을 거쳐야 하고(개인정보처리방침·서비스 약관 주소, 도메인 소유 확인, 사용 흐름 영상), 심사에 수 주가 걸릴 수 있으므로 착수를 앞당겨야 한다. 검증 대상 등급과 소요는 실제 신청으로 확인한다. 그 전까지 시연은 테스터 등록으로만 가능하다. OAuth 클라이언트를 고객사가 아니라 5240이 소유하기로 하면 이 게시·검증도 5240이 한 번만 하면 되므로, 소유 주체를 먼저 정한다.
직원 ↔ 구글 계정 매핑확인 필요
- 왜 필요한가
- 도메인 전체 위임 방식은 직원 각자 캘린더에 일정을 넣는다. 5240 직원과 구글 계정을 이을 열쇠(회사 메일 주소)가 있어야 한다.
- 확인한 사실
- PRCT_STAFF에서 EMAIL·EMAIL_ADDR·MAIL·EMAIL_ID·E_MAIL·EMAIL_ADR을 모두 조회해 봤으나 하나도 없다(대조군 STAFF_ID 조회는 정상). 사용자 계정 테이블로 짐작되는 것들은 MCP 가드에 막혀 확인하지 못했다.
- 5240에서 할 일
- 다른 테이블에 메일 주소가 있는지 확인. 없으면 매핑 항목을 어디에 둘지 정해야 한다. 공유 캘린더 방식은 이 매핑이 필요 없으므로, 이것이 열리기 전까지는 공유 캘린더를 권한다.
서비스영역 ID 파라미터화확인 필요
- 왜 필요한가
- 고객사마다 SERVAREA_ID가 다르다. 지금은 데모값 300이 코드에 박혀 있다.
- 확인한 사실
- 조회 문장마다 SERVAREA_ID = '300'이 최상위 WHERE에 강제돼 있다(MCP 가드 요건).
- 5240에서 할 일
- 고객사별 값을 설정에서 받도록 바꾼다. API로 옮기면 함께 정리되는 부분이다.
옵션 1426 값 검증확인 필요
- 왜 필요한가
- 무엇을 캘린더에서 감출지는 옵션 1426(HIDE_LEAV_CDS)이 정한다. 연동은 이 값을 그대로 따르므로, 값이 틀리면 감춰야 할 휴가가 그대로 나간다.
- 확인한 사실
- 데모 설정값 중 239는 휴가코드표(TAA_LEAV_CD)에 없다 — 난임휴가(유급) 250의 오타로 보인다. 콘솔은 이런 값을 무시하고 경고로 표시한다.
- 5240에서 할 일
- 고객사 도입 시 1426 값이 실제 휴가코드와 맞는지 점검하는 절차를 둔다. 출산·유산·난임·경조처럼 민감한 종류가 빠져 있지 않은지도 함께 본다.
연동 계정의 조직조회권한확인 필요
- 왜 필요한가
- 조회는 연동 계정의 조직조회권한 범위 안에서만 이뤄진다. 화면에서 전사를 골라도 권한 밖 직원은 나가지 않는다 — 즉 권한 설정이 곧 동기화 범위다.
- 확인한 사실
- 리버스 문서로 확인한 제품 동작이다. 데모는 DB 직접 조회라 이 제약이 드러나지 않는다.
- 5240에서 할 일
- 연동용 계정을 어느 조직까지 열어 줄지 고객사와 정하고, 계정 발급 절차를 정리한다.
변경·취소를 알리는 방법확인 필요
- 왜 필요한가
- 휴가가 취소·반려되면 캘린더에서도 지워야 한다. 담당자가 뒤늦게 어떤 코드를 미표시로 바꾸면 이미 나간 일정도 찾아 지워야 한다.
- 확인한 사실
- 지금 설계는 주기적으로 기간 창 전체를 다시 읽어 비교하는 폴링 전제다. 창이 넓을수록 조회가 늘어 느려진다.
- 5240에서 할 일
- 제품이 변경 알림(훅·이벤트·변경분 조회)을 줄 수 있는지 확인한다. 있으면 폴링을 줄일 수 있다.
근무일정·출장 어댑터확인 필요
- 왜 필요한가
- 세 갈래가 서로 다른 신청 마스터에 쌓인다. 갈래마다 읽는 코드가 따로 필요하다.
- 확인한 사실
- 휴가(TAAT_LEAV_REQ)만 구현했다. 근무일정(TAAT_WKTYPE_REQ)·출장(TAAT_BSTRIP_REQ)은 화면에 체크박스만 있고 "어댑터 준비 중"으로 표시된다.
- 5240에서 할 일
- 두 갈래의 표시 규칙(상태 필터·기간·민감도)이 휴가와 같은지 확인한 뒤 어댑터를 붙인다.
옵션 1426 읽기 경로준비됨
- 왜 필요한가
- 연동이 제품과 같은 기준을 쓰려면 옵션값을 실행할 때마다 다시 읽어야 한다.
- 확인한 사실
- CFGT_VAL에서 CNFG_ID=HIDE_LEAV_CDS를 읽어 미표시·마스킹·마스킹 명칭 세 항목을 그대로 적용하는 것까지 동작 확인했다. 미리보기 화면이 현재값을 읽기 전용으로 보여준다.
- 5240에서 할 일
- API 경로로 옮길 때 이 조회도 함께 옮긴다. 기준을 연동 쪽에 복사해 두지 않는다.
확인한 것과 확인이 필요한 것을 섞지 않았습니다. “확인한 사실”에 적힌 것은 실제로 조회하거나 문서로 확인한 내용이고, 나머지는 아직 열어 보지 못한 것입니다.