의존성과 재적재 관리

주제 목차 · 이전: function 모듈 실습

이 문서의 결과: 모듈 재적재 절차를 확인하고, 확장 모듈 장애 시 로그를 확인할 우선순위를 정한다.

재적재가 필요한 시점

새 함수나 모듈 설정을 추가·수정한 뒤에는 서버가 이를 다시 읽어야 반영됩니다. 02. 프로젝트 구조와 파일 작업에서 다룬 "저장 후 반영 확인" 절차와 마찬가지로, 반영됐다고 가정하지 말고 실제로 확인합니다.

변경 내용	반영 확인 방법
function 소스 수정	거래를 다시 호출해 바뀐 동작이 나타나는지 확인
featureMeta.json 수정	서버 재기동 후 함수 목록/입출력 정의가 갱신됐는지 확인
새 모듈 추가	서버 시작 로그에 해당 모듈이 로드됐다는 기록이 있는지 확인

모듈 간 의존성 그리기

게시판 예제를 확장 모듈까지 붙이면 다음과 같은 의존 관계가 생길 수 있습니다.

[화면] BOD011 등록
   v
[transact] BOD011.json
   ├─ ID01 (CommandType: D) → dbclient → Board 테이블 저장
   └─ FD01 (CommandType: F) → function → 외부 알림 호출

이렇게 여러 모듈이 하나의 거래 안에서 순서대로 실행될 때는, 어느 하나가 실패하면 전체 거래를 어떻게 처리할지(계속 진행할지, 되돌릴지) 미리 설계해 둬야 합니다. 데이터베이스 저장에는 성공했지만 외부 알림 호출에 실패한 경우를 예로 들어, 이 상황을 오류로 볼지 "일부 성공"으로 볼지 팀 규칙을 정합니다.

장애 시 로그 확인 우선순위

확장 모듈이 얽힌 거래가 실패하면 다음 순서로 로그를 확인하는 것을 권장합니다.

1. 거래 이력(GlobalID)에서 어느 ServiceID(기능 ID)에서 실패했는지 먼저 확인합니다.
2. 실패한 서비스의 CommandType을 보고 dbclient 로그를 볼지 function 로그를 볼지 정합니다.
3. function이라면 함수 자체의 예외 로그를, dbclient라면 SQL 오류 로그를 확인합니다.

이 순서를 미리 정해 두면 여러 로그 파일을 무작정 뒤지는 대신 바로 원인에 접근할 수 있습니다. 더 자세한 진단 절차는 10. 테스트와 디버깅에서 이어집니다.

완료 조건 확인

09. 확장 모듈의 완료 조건을 확인한 뒤 10. 테스트와 디버깅으로 이동합니다.