본문으로 이동
SK-INTELLIX / ENGINEERING전체 모듈 Atlas ↗

시나리오·정책·변경 영향 범위

기능 하나의 수정 범위는 파일 개수보다 공유하는 상태·정책·통신 계약에 따라 넓어진다. 아래는 현재 소스에서 확인한 연결을 바탕으로 한 영향 분석 지도다. 영향 가능성은 변경 결과가 이미 입증됐다는 뜻이 아니다.

세 단계로 영향 범위를 결정한다

① 직접 동작 변경 → ② 같은 상태·정책을 쓰는 다른 기능 → ③ Binder·MQTT·저장 데이터·장치 계약. 뒤 단계의 의미가 바뀌면 검증과 협업 범위를 넓힌다.

현재 시나리오와 수정 위치

시나리오 현재 판단·실행 경로 변경 시 직접 분석 연관 영향과 권장 회귀
S1 수동 청정 시작 MainApi → newClean → BaseCleaning → Basic/Moving 청정 작업표 예약/야간/복귀 중단, 새 START와 동작 중 변경
S2 시간·GPS 예약 DB 재조회 → 시간 → 일반 조건 → Security 예외 → Launcher 예약 작업표 청정/인터랙션/보안, 삭제·휴일·중복·재부팅
S3 S02 오류 복귀 ErrorHandler 지연 → CmdPolicy → RobotMovement 이동 작업표 청정·순찰 선점, S03 중첩·도킹·privacy 예외
S4 설정 변경 Settings 저장 + 장치/서비스 적용 → 후속 정책 조회 설정 작업표 화면·음량·Vision·LLM·예약·IoT/PUI
S5 보안 시작 WSS caller 검증 → 가용성 → trigger mask → 세션 WSS 작업표 basic/patrol·예약/LLM·이동·녹화·이벤트
S6 클라우드 제어 MQTT 해석 → DeviceAgent → callback → 응답 클라우드 작업표 동일 API의 UI 요청, 실패/지연 완료·구버전 payload
S7 센서 상태 갱신 AMR callback → 도메인 상태 → 정책·표시 장치 작업표 단위·초기값·미수신·오류 분류·복귀
S8 OTA 요청 IotAgent 조건 → UpdateAgent → 엔진 callback OTA 작업표 local/job 경로·일반 API 차단·예약·WSS·재부팅

S1–S5의 상세 단계는 현재 실행 시나리오에 있다. S6–S8의 계약과 수정 위치는 각 작업표에 수록했다.

정책별 적용 범위

각 셀은 동일한 결과를 뜻하지 않는다. 일반 명령, 예약, WSS는 별도 입구이고 같은 설정에서도 예외가 다르다. 조건식을 수정할 때 옆 열의 기대 결과까지 결정한다.

정책·상태 일반 명령/청정·이동 예약 WSS 주요 변경 소유자
제품 모드·UPGRADE MainApi 모드 라우팅, StateManager 특정 API 차단 triggerScheduleAction의 UPGRADE 우선 반환 operation 상태 판단 MainApi / StateManager / Receiver / WssPolicyChecker
S02 저전력 새 동작 제한과 정거장 복귀 예외 S02+station은 Security 재판정에서 허용 가능 basic/patrol에서 battery reason 마스킹, LLM 추가 예외 ErrorHandler / CmdPolicy / Receiver / WssManager
S03 임계 배터리 commonCheck 차단, S02 지연 처리와 우선관계 직접 숫자 비교로 단순화하지 말고 호출 경로 확인 WSS의 critical reason 명명은 S03과 일대일 동일하지 않음 ErrorHandler / 각 기능 정책
Privacy 이동 검사에 S02 복귀 예외 일반 검사에서 차단; Security 재판정도 함께 확인 common policy에서 reason Settings / CmdPolicy / Receiver / WssPolicyChecker
Home lock AirCleaningPolicy 앞부분 차단 일반 검사에서 차단; Security 경로 별도 lock/PIN reason Settings / 청정 Policy / Receiver / WSS
Night LCD·LED·음량·청정 동작 변경 일반 검사에서 차단; Security 재판정 존재 일반 정책의 night 차단과 동일하다고 가정하지 않음 Settings / Receiver
station·map·area BASIC on-station 조기 허용, 이동 area 검사 OffStation BASIC 차단, area 조건 basic/patrol 선택·map 조건 CmdPolicy / MapManager / Receiver / WSS
기존 동작 충돌 newClean/setMoveTo/returnToStation 각각 다름 follow-me/liveview 조건, 복귀 중 검사 생략 operation reason / trigger 예외 CmdPolicy / Receiver / WssManager
호출자 권한 API별 실제 검사 확인 Receiver manifest·callback 경계 SYSTEM_UID + FRONT/REMOTE Manifest / WssPackageValidator / Stub
OTA 다운로드 입장 IotAgent의 jobid 있는 요청에 검사 제품 UPGRADE 상태 소비 제품 UPGRADE 상태 소비 IotAgent / UpdateAgent / 제품 상태

정확한 조건·순서·행 번호는 정책 조건표에 있다. Streaming은 예약 Receiver 안에서 로그만 남기는 구간이 있고, AirCleaningPolicy는 계산한 mPolicy와 실제 반환값이 다르다. 정책 수정 시 이 차이를 의도된 동작으로 유지할지 수정할지 먼저 명시한다.

공유 요소를 바꾸면 어디까지 전파되는가

수정 대상 직접 소비자 연관 영향 분석 범위가 넓어지는 조건
Settings의 Privacy Vision·tilt·SoundFlow·LLM, 저장 값 CmdPolicy·예약·WSS의 재판정 값 형식/기본값/적용 시점 변경
Settings의 Night LCD·LED·음량·청정·보정·IoT/PUI 예약 실행과 실행 중 청정 시간/enable 의미·즉시 적용 정책 변경
Settings의 Lock SoundFlow·LLM, 저장 값 청정·예약·WSS/PIN UI 값과 정책 허용 의미가 달라질 때
CmdPolicy.commonCheck 이를 호출하는 청정·이동·복귀·예약 경로 일반/airsensor/오류 복귀 예외와 호출 순서 공통 조건 추가·조기 반환 위치 이동
CleaningTransaction 청정 Manager·상태 조회·보고 야간 처리·예약·이동 완료와 stop 상태 값·완료 시점·mode 의미 변경
RobotMovementController 청정·WSS·인터랙션·일반 이동/복귀 선점·pause/resume·late callback 공통 우선순위·정지·도착 의미 변경
Schedule 필드 DB·Bundle/JSON·Receiver·Launcher 클라우드 생성·UI 편집·구데이터 복원 타입 코드/저장 스키마 변경
WSS reason bit allowed 계산·상태 조회·클라이언트 표시 LLM trigger mask·예약 후 시작 bit 의미/마스크/SDK 계약 변경
MainService 수신 값 Battery/Moving/Map 등 상태 객체 정책·화면·클라우드·보고서 단위/유효성/초기값/수신 순서 변경
AIDL/Bundle/MQTT 송신자와 수신자 SDK·Launcher·IotAgent·외부 backend signature/필수 필드/완료 의미 변경

근거: DA/settings/Settings.java:329, :433, :913; DA/policy/CmdPolicyManager.java:265; DA/main/MainService.java:79; DA/schedule/ScheduleAlarmReceiver.java:134; DA/wss/WssManager.java:520. DA/는 수정 위치 문서의 패키지 경로 약칭이다. 표의 소비자 관계는 영향 분석 출발점이며 전체 호출 그래프를 대체하지 않는다.

예제 · 야간에도 특정 청정 예약을 허용하려면

요구사항 예시: “야간 모드에서 BASIC 예약만 허용한다.” 이는 새 제품 요구사항 예시이며 현재 구현 사실이 아니다.

  1. 직접 수정 후보: ScheduleAlarmReceiver의 night 조건. 허용 대상 타입/clean type을 좁혀야 하며 단순히 return을 제거하면 다른 예약에도 적용된다.
  2. 예약 특례 검토: Security 재판정이 일반 검사 실패를 재허용하는 현재 구조와 모순되지 않는지 확인한다. UPGRADE 차단은 그 이전 단계다.
  3. 후속 실행 검토: Launcher가 전달받은 예약을 기능 요청으로 바꾸는 분기와 MainApi → newClean → BaseCleaning 경로를 확인한다. 예약 통과만으로 청정 시작을 보장하지 않는다.
  4. 실행 중 영향 검토: Settings.applyNightMode()가 청정·화면·LED·음량에 적용하는 동작을 확인한다. 예약만 허용할 것인지 야간 청정 강도도 바꿀 것인지 요구사항을 분리한다.
  5. 조건부 연관 수정: 기존 예약 필드만으로 표현되면 DB/AIDL 변경은 불필요하다. 새 사용자 옵션을 저장해야 하면 Settings/Preferences·Launcher·필요한 cloud 계약을 추가 검토한다.
  6. 회귀 조합: 야간 on/off × BASIC/이동/보안/인터랙션 × station 안/밖. lock/privacy·S02·UPGRADE 동시 조건과 실제 fan/화면/음량·보고서도 확인한다.

근거: DA/schedule/ScheduleAlarmReceiver.java:193, :291, :301, :334; DA/main/api/MainApi.java:636; DA/settings/Settings.java:433.

검증 수준을 나누어 기록한다

수준 이 단계에서 확인할 것 완료로 주장할 수 없는 것
코드·단위 검증 정책 입력별 결과, serializer 호환, 상태 전이와 예외 Binder 호출자 정체·실제 장치 완료
모듈·통신 검증 release 빌드, Binder/callback, MQTT payload, DB migration 물리 주행·충전·녹화/업로드 완료
기기 검증 fan·도착·도킹·센서·녹화·OTA 결과 및 로그 관찰하지 않은 동시성/장시간 시나리오

문서 개편에서는 위 검증을 실행했다고 주장하지 않는다. 실제 기능 개발에서는 영향받는 계약에 맞춰 검증 범위를 선택한다. 기기 교체가 필요한 경우 MR6 체크아웃의 인증서 확인·백업·해시 대조 지침을 적용한다.

Connections

개발 지도 · 수정 위치 · 영향 범위 · 정책 근거 · 현재 시나리오