← Docs hub

LLM 업무 역할·책임: A2A 제외 범위

이 문서는 지금까지 함께 진행한 LLM 제품 업무 중 A2A를 제외한 범위를 업무 패키지와 역할 단위로 정리한다. 단순한 작업 목록이 아니라 각 업무의 책임자, 협업 경계, 입력, 산출물, 완료 기준을 명시해 기획·개발·검증·운영 사이의 누락과 중복을 줄이는 기준 문서다.

실제 업무 항목과 담당을 먼저 확인하려면 LLM 업무 목록과 역할·책임에서 87개 업무를 순번 · 수행 책임 · 최종 책임 · 산출물 기준으로 본다. 현재 문서는 그 목록의 구조·시나리오·완료 기준을 설명하는 상세 해설서다.

1. 범위 선언

포함

음성 신호 수신
  -> STT와 전처리
  -> 온디바이스 dictionary / local LLM
  -> Cloud LLM 일반 응답·rewrite·RAG
  -> TTS와 음성 세션 상태
  -> Android system app 배포
  -> E2E 품질·장애·비용·운영

명시적 제외

Cloud LLM을 사용한다는 이유만으로 모든 업무가 A2A가 되는 것은 아니다. 이 문서는 사용자 음성을 안정적인 입력으로 만들고, 로컬·Cloud 모델에서 답변 또는 재진입 표현을 생성하고, TTS까지 안전하게 종료하는 제품 LLM 경로를 소유한다.

2. R&R을 나누는 원칙

3. 업무 패키지 목록

WP-01 · Voice Ingress와 음성 세션

WP-02 · STT, 전처리와 발화 정규화

전처리 개선은 파형이나 dB proxy만으로 완료하지 않는다. 최종 제품 판정은 실제 decoder 결과 또는 제품 E2E 성공률로 닫는다.

WP-03 · Dictionary와 로컬 기능 문장 처리

WP-04 · 온디바이스 LLM Runtime

빈 출력 뒤 재시작 가능한 오류와 JNI fatal crash는 다른 문제다. 전자는 app-level recovery로 다루고, 후자는 tombstone·process death·LMKD evidence로 판정한다.

WP-05 · Cloud LLM 일반 응답, Rewrite와 RAG

Cloud가 기기 기능을 직접 수행했다고 말하지 않는다. 기능 실행이 필요하면 온디바이스가 이해할 수 있는 안정적인 rewrite/token 후보를 반환하거나, 지원하지 않는 경우 명확한 사용자 응답으로 종료한다.

WP-06 · TTS와 사용자 응답 품질

WP-07 · 화자 식별과 LLM Turn 결합

WP-08 · 성능, 메모리와 비용 최적화

WP-09 · Android 통합, 시스템 앱 배포와 보안

WP-10 · QA, 장애 분석, 문서와 운영

4. 실제 세부 프로젝트 포트폴리오

아래 표는 업무 패키지를 실제 릴리즈 과업으로 내린 목록이다. 사용자가 제공한 LLM Release Note의 항목을 기준으로 git history, 현재 source, 기존 설계·검증 문서를 대조했다. 인증이 필요한 Notion 본문은 사용자가 전달한 업무 목록을 입력 기준으로 삼았으며, 구현 여부는 별도로 로컬 코드와 commit evidence에서 확인했다. 상태는 다음처럼 해석한다.

4.1 Schedule, Interaction과 Night Mode

현재 MR8 reference의 NightModeDecisionResolver에는 예약 기본값 20_00~07_00, 상시/시간지정 전환, 상태조회와 중복 분기가 있다. 다만 현재 작업 checkout과 MR8 reference가 다를 수 있으므로 브랜치 존재를 제품 반영 완료로 간주하지 않는다. 대상 release branch에서 다시 정합·검증해야 한다.

4.2 Product Function, UI와 응답 시나리오

4.3 Cloud, Prompt와 입력 계약

원문 전달은 구현 history f9e1851a와 현재 originalSttResult 경로에서 근거가 확인된다. 판정할 때는 “Cloud에 문자열이 보였다”로 끝내지 않고 STT raw, processed, request body, Cloud response, rewrite 재진입을 같은 turn으로 묶어야 한다.

4.4 Quality, Release와 Field Operation

5. 대표 시나리오와 E2E 판정

S-01 · 고정 청정 스케줄 등록

사용자: "평일 오후 5시에 고정 청정해줘"

STT raw/original
  -> dictionary 또는 local LLM
  -> <sk_48>(action=1, day=weekday, start=17:00)
  -> on-device only / Cloud schedule 경로 판정
  -> 동일 시간 중복 조회
  -> 등록
  -> 성공·중복·실패 TTS와 화면 반영

S-02 · 선택 공간 청정 스케줄

사용자: "내일 아침 8시에 거실하고 안방 청정해줘"

이 시나리오는 시간만 해석해서는 완료되지 않는다. 내일, 08:00, 거실, 안방, 선택공간청정 mode와 공간 순서를 보존해야 한다. 등록 공간이 없거나 이름이 불일치하면 임의 공간으로 대체하지 않고 구체적으로 되묻는다. 최종 Gate는 CLMD0003 payload와 backend·Device API 계약이 동일한지다.

S-03 · 인터랙션 스케줄 제어

여기서 웨이크업·릴렉스는 설명 질문과 실행 제어가 다르다. “웨이크업 기능이 뭐야”는 설명이고 “웨이크업 멈춰줘”는 현재 상태를 확인하는 제어다.

S-04 · 나이트모드 상시·시간지정 전환

시작 시간만 말한 경우 07:00 종료를 자동 적용할지 질문할지는 제품 정책이다. LLM이 임의 종료 시간을 창작하지 않도록 prompt와 resolver가 같은 정책 상수를 사용해야 한다.

S-05 · 대기화면 커스텀 공기질

사용자: "대기화면을 커스텀 공기질로 바꿔줘"
  -> SK_39 theme 의미 확정
  -> 현재 theme 조회
  -> custom image 존재 확인
  -> 존재하면 setPuiWaitingScreenTheme
  -> 없으면 앱에서 이미지 등록 안내

가장 큰 리스크는 기존 <sk_39>(theme=2)가 상세 공기질을 의미한다는 점이다. 따라서 dictionary만 추가하면 안 되고 parameter migration, enum, DB mapping, multiturn 문구, API 값, 한국어·영어 regression을 함께 변경해야 한다.

S-06 · 날씨 상태와 번역

사용자: "내일 쿠알라룸푸르 날씨 알려줘"
  -> STT 지명 보존
  -> location/timeframe 전달
  -> Weather API condition code
  -> locale mapping
  -> 온도 단위·최저·최고·습도
  -> 자연스러운 TTS

scattered_clouds 변경은 단순 문구 수정이 아니다. API code, WeatherCondition, 한국어·영어 resource, icon과 prompt context가 같은 의미를 사용해야 한다.

S-07 · Cloud Rewrite 재진입

사용자: "밤 열 시부터 조용하게 나이트 모드 해줘"
  -> originalSttResult를 Cloud에 전달
  -> Case 2 + rewrite_query
  -> local dictionary / local LLM 재진입
  -> 기대 <sk_28> parameter 생성
  -> 사전 검증과 Device API
  -> TTS

Cloud Case가 맞아도 rewrite가 action·type·시간을 잃으면 실패다. 이 시나리오는 Case -> rewrite -> token -> API -> TTS 다섯 결과를 모두 평가한다.

S-08 · 말레이시아 제품 질의와 기능 실행 분리

같은 명사를 포함해도 설명, 상태조회, 실행, 미지원 기능이 다르다. Malaysia set은 영문 positive만 늘리지 않고 서로 충돌하는 negative pair까지 관리한다.

S-09 · STT·LLM 모델 릴리즈

모델 릴리즈는 파일 교체가 아니라 아래 compatibility bundle을 함께 고정하는 프로젝트다.

STT model + language config + preprocessing + substitution
Local LLM model + runtime config + prompt + dictionary/token schema
Cloud prompt/model + response contract + rewrite compatibility
TTS resource + Android release APK

release report에는 model hash, source commit, prompt/dictionary version, APK cert, 기기, latency·memory, 발화셋 결과와 rollback artifact가 함께 있어야 한다.

6. 프로젝트 단위 업무 카드 표준

앞으로 릴리즈 노트의 한 줄 업무는 다음 필드를 가진 카드로 관리한다.

이 형식이면 “나이트모드 개발”, “말레이시아 검증”처럼 범위가 큰 한 줄을 실제 실행 가능한 개발·검증 단위로 나눌 수 있다.

7. 역할별 세부 R&R

8. 현재 협업 기준 책임 분담

이 표는 조직 직책이 아니라 현재 사용자와 구현·검증 지원 사이의 의사결정 경계다.

원칙적으로 구현·검증 지원이 사용자 정책을 임의로 확정하지 않으며, 제품·기술 오너가 코드 근거 없이 구현 성공을 선언하지 않는다.

9. RACI 매트릭스

A는 최종 책임, R은 수행, C는 협의, I는 결과 공유다.

10. 장애 분류와 인계 기준

11. 공통 완료 정의

업무 패키지는 아래 다섯 단계가 모두 충족되어야 완료로 본다.

1. 계약: 입력, 출력, 오류, lifecycle이 문서와 코드에서 일치한다.
2. 자동 검증: unit 또는 instrumentation이 핵심 회귀를 막는다.
3. 통합 검증: 실제 local/Cloud/TTS 경로가 한 turn으로 연결된다.
4. 실기기 증거: release/platform-signed APK에서 로그와 물리 음성 결과를 확인한다.
5. 운영 전달: 변경 목록, 알려진 한계, rollback, runbook과 wiki가 남는다.

12. 주요 저장소와 산출물

13. 우선순위 백로그

결론

비-A2A LLM 업무의 핵심은 모델 prompt 하나가 아니다. 음성 turn을 잃지 않고, STT와 local/Cloud 판단을 안정적으로 연결하고, TTS와 Android lifecycle까지 종료하며, 그 품질·비용·장애를 재현 가능한 증거로 관리하는 제품 실행 체계다.

A2A는 이 입력과 응답 위에서 owner와 plan을 결정하는 별도 계층이다. 따라서 이 R&R을 먼저 명확히 해야 A2A 문제와 음성·LLM runtime 문제를 서로 떠넘기지 않고 각 계층의 성능을 독립적으로 개선할 수 있다.