AI Assistant

이 장에서 다루는 것

PAIO에는 자연어로 모델을 만들고 고치는 AI 기능이 두 가지 있습니다. 이 장은 그 둘이 무엇을 해 주는지, 어떻게 요청해야 원하는 결과가 나오는지, 결과를 어떻게 확인하고 되돌리는지를 다룹니다.

• 대상 독자: 자연어로 모델을 만들거나 고치려는 사용자
• 선행 조건: 활성 라이선스와 LLM 프로바이더 하나 이상(15.2). 모델을 고치려면 프로젝트가 열려 있어야 합니다.

AI가 만들고, 엔지니어가 결정합니다. AI가 내놓는 것은 언제나 초안입니다. PAIO는 형식이 깨진 결과가 모델에 들어가지 않도록 걸러 주고 되돌릴 수단을 주지만, 그 내용이 설계로서 옳은지는 판단하지 않습니다. 반영된 내용은 각 에디터와 14. Validation 패널에서 반드시 확인하세요.

15.1 무엇을 해 주나

기능은 둘이고, 쓰는 상황이 다릅니다.

	AI 채팅	QuickStart 워크플로
언제 쓰나	이미 있는 모델을 손볼 때	백지에서 초안을 만들 때
입력	자유로운 문장	도메인 템플릿 + 변수
범위	요청한 부분만	프로젝트 전체
진입점	상단바 오른쪽 로봇 아이콘	Project ▸ Quick Start

AI 채팅이 손댈 수 있는 것은 다음과 같습니다. 각 에디터에서 손으로 하는 작업 대부분을 문장으로 대신할 수 있다고 보면 됩니다.

• 네트워크 토폴로지 — ECU · HPC · 통신 클러스터 · 커넥터
• 시그널 · PDU · 프레임
• 데이터 타입과 단위
• 포트 인터페이스와 서비스 배포
• SWC와 컴포지션, SWC ↔ ECU 매핑
• ECUC 모듈 정의와 설정값

모델을 고치지 않는 질문도 할 수 있습니다. AUTOSAR 개념이나 용어를 묻거나, 설계 판단을 상의하거나, 프로젝트의 doc 폴더에 문서를 만들어 달라고 할 수 있습니다.

두 기능은 따로 동작하지만 프로바이더는 같은 것을 씁니다 — 채팅에서 고른 프로바이더가 QuickStart에도 그대로 적용됩니다.

15.2 준비 — 프로바이더 연결

AI 기능을 쓰려면 LLM 프로바이더를 하나 이상 연결해야 합니다. 채팅 헤더의 톱니(Manage AI accounts) 버튼이나 명령 팔레트 ▸ Manage AI Accounts... 로 AI Providers 다이얼로그를 엽니다.

프로바이더	준비 방법
Claude [OPUS]	Claude CLI를 설치한 뒤 Log in
Claude [GLM]	API 키 입력
Gemini	Gemini CLI를 설치한 뒤 Log in
Codex	Codex CLI를 설치한 뒤 Log in
Ollama	로컬에서 Ollama 서버를 실행하고 모델을 하나 이상 설치

각 행 앞의 점이 상태입니다 — 초록은 사용 가능, 회색은 사용 불가, 노랑은 확인 중. 사용 가능한 것 중 하나에 Use 를 눌러 활성으로 지정합니다. Log in 을 누르면 터미널 창이 열려 해당 CLI의 로그인 절차가 진행되고(브라우저가 함께 열릴 수 있습니다), 끝나면 점이 초록으로 바뀝니다.

프로바이더마다 지금 무엇을 할 수 있는지가 버튼으로 드러납니다. 맨 위 Claude [OPUS] 는 이미 활성이라 ACTIVE 배지가 붙었고, Gemini 와 Codex 는 사용 가능하지만 활성이 아니라 Use 가 보입니다. Claude [GLM] 은 아직 키를 넣지 않아 Log in, Ollama 는 로컬 서버가 꺼져 있어 Offline 입니다. 이름 앞의 점 색이 같은 사실을 한 번 더 알려 줍니다.

• API 키는 OS 키체인에 암호화되어 이 PC에만 저장되며 화면에 다시 표시되지 않습니다. 워크스페이스를 바꿔도 유지됩니다.
• 활성 프로바이더가 없으면 전송이 LLM provider is not available 오류로 끝납니다.
• Claude 계열은 호출이 연속 3회 실패하면 자동으로 비활성이 됩니다 (Provider deactivated after 3 consecutive failures). 다시 로그인하거나 다른 프로바이더로 바꿉니다.

15.3 AI 채팅 쓰기

상단바 오른쪽의 로봇 아이콘(툴팁 AI Chat Panel)을 누르면 오른쪽에 채팅 패널이 열립니다. 제목은 PAIO Robo 입니다. 같은 버튼이나 헤더의 Close 로 닫고, 패널 왼쪽 경계를 드래그해 너비를 조절합니다. 앱을 다시 켜면 항상 닫힌 채로 시작합니다.

채팅은 에디터를 덮지 않고 오른쪽에 나란히 열립니다. 편집하던 화면을 보면서 요청할 수 있습니다. 아래쪽 입력란에 요청을 적었고, 그 왼쪽에 지금 쓰는 프로바이더(Claude [OPUS])가 표시됩니다. 입력란은 내용에 따라 저절로 늘어납니다. 헤더의 EN 은 답변 언어가 영어로 지정되어 있다는 뜻입니다.

Enter 로 보내고 Shift+Enter 로 줄을 바꿉니다. 답변이 나오는 동안 보낸 메시지는 무시되므로 이전 답변이 끝난 뒤에 다시 보냅니다. 헤더에서 대화 목록(Chat history) · 검색 · 답변 언어 (KO / EN / JA / ZH) · 내보내기(JSON · 텍스트) · 새 대화를 다룹니다. 언어를 고르면 어떤 말로 물어도 그 언어로만 답합니다.

15.3.1 기본 흐름

1. 프로젝트를 열어 둔 상태에서 요청을 씁니다.

2. 답변을 읽습니다. 모델을 고치는 요청이었다면 결과가 파일에 바로 반영되고, 답변 끝에 요약이 붙습니다.

   **Write Complete** | Parsed: 3 | Validated: 3 | Written: 3 | Verified: 3

   실패한 것이 있으면 제목이 **Write Result** 로 바뀌고 실패 목록이 이어집니다.

3. 각 에디터를 열어 결과를 확인합니다. 검증 패널로 제약 위반도 함께 점검합니다.

4. 마음에 들지 않으면 되돌립니다(15.3.3).

반영 전에 PAIO가 걸러 주는 것이 있습니다. 이름이 비었거나 AUTOSAR 이름 규칙에 맞지 않으면 그 문서는 거부되고, 구조가 맞지 않아도 거부됩니다. 거부되면 PAIO가 실패 내용을 정리해 최대 2회까지 자동으로 다시 요청합니다(답변에 [Auto-correction attempt 1/2] 구분선이 나타납니다). 쓰기 자체가 실패하면 재시도 안내가 나오는데, 이때 입력창에 재시도(또는 retry, 네) 한 단어만 보내면 LLM을 다시 부르지 않고 같은 내용을 다시 씁니다. 다른 말을 덧붙이면 일반 질문으로 처리됩니다.

이 검사들은 형식이 깨진 문서를 막아 줄 뿐 내용이 설계로서 옳은지는 보지 않습니다. 검토는 사람의 몫입니다.

15.3.2 어느 프로젝트에 쓰이나

에디터를 열어 두는 것만으로는 대상이 정해지지 않습니다. 대상은 이 순서로 정해집니다.

1. AI가 만든 문서에 적힌 프로젝트 이름이 워크스페이스의 프로젝트와 정확히 일치하면 그 프로젝트
2. 워크스페이스에 프로젝트가 하나뿐이면 그 프로젝트
3. 둘 다 아니면 그 문서는 쓰이지 않고 Cannot determine target project. 오류로 실패합니다

그래서 프로젝트가 둘 이상인 워크스페이스에서는 요청 문장에 프로젝트 이름을 그대로 적는 것이 가장 확실합니다.

15.3.3 되돌리기

파일이 하나라도 쓰였으면 답변 아래에 ↩ 되돌리기 버튼이 붙습니다. 누르면 이전 내용으로 복원되고, 이번 응답이 새로 만든 파일은 삭제됩니다. 복원 자체도 편집 이력에 남습니다.

Ctrl+Z 로도 되돌릴 수 있습니다 — AI가 쓴 변경은 하나의 실행 취소 단위로 기록됩니다.

↩ 되돌리기 가 쓰는 백업은 30분 동안만 보관됩니다. 그 뒤에 누르면 The backup has expired or does not exist 로 실패하므로, 되돌릴지는 그 자리에서 판단하는 것이 좋습니다.

15.4 요청을 잘 쓰는 법

결과의 품질은 대부분 요청 문장에서 갈립니다. 네 가지만 지키면 됩니다.

대상을 이름으로 지목합니다

AI는 화면에서 무엇을 선택했는지 보지 못합니다. 무엇을 어디에 만들지는 문장으로 알려 줘야 합니다.

	요청
✗	여기에 ECU 하나 더 넣어 줘
✓	프로젝트 DoorProject 의 CAN 클러스터 CAN_Body 에 도어 ECU DoorEcu_RL 을 추가해 줘

한 번에 한 가지만 요청합니다

여러 관심사를 한 문장에 담으면 일부만 반영되거나 서로 어긋나기 쉽습니다. 나눠서 요청하고, 각각을 확인한 뒤 다음으로 넘어갑니다.

	요청
✗	도어 ECU 4개 만들고 시그널도 붙이고 SWC까지 매핑해 줘
✓	① CAN 클러스터 CAN_Body 에 도어 ECU 4개를 추가해 줘 ② 그 ECU들이 주고받을 창문 위치 시그널을 정의해 줘

조건을 함께 줍니다

개수 · 비트 길이 · 주기 · 플랫폼처럼 값이 정해져야 하는 것은 미리 적습니다. 적지 않으면 AI가 임의로 고릅니다.

	요청
✗	창문 위치 시그널 만들어 줘
✓	창문 위치 시그널을 만들어 줘. 8비트 부호 없는 정수, 0~100% 범위, 100ms 주기로

확신이 없으면 먼저 물어봅니다

모델을 고치라고 하지 않고 묻기만 하면 파일은 그대로 있습니다. 구조를 정하기 전에 상의하는 데 쓰면 좋습니다.

"도어 도메인을 Classic으로 갈지 Adaptive로 갈지 고민 중이야. 각각 뭐가 달라지지?"

15.5 QuickStart 워크플로

도메인 템플릿을 고르고 변수를 채우면 AI가 여러 단계에 걸쳐 프로젝트 전체 모델을 만들어 주는 기능입니다. 백지에서 초안을 잡을 때 씁니다.

15.5.1 절차

1. Project ▸ Quick Start 를 실행합니다. 워크스페이스가 없으면 먼저 선택 창이 뜹니다.
2. 새 프로젝트 이름을 정합니다. QuickStart_01 처럼 비어 있는 번호가 기본값으로 제안되며, 이름 규칙은 일반 프로젝트와 같습니다(4.3.2).
3. 템플릿 갤러리(Select a Template)에서 템플릿을 고릅니다. 검색창과 도메인 칩으로 좁힐 수 있고, 카드를 클릭하면 곧바로 다음 단계로 넘어갑니다.
4. 변수를 채우고 Start Generation 을 누릅니다. 변수 그룹이 여럿이면 위쪽 탭으로 오갑니다. 필수 항목이 비었거나 숫자가 범위를 벗어나면 버튼이 비활성입니다.
5. 진행 화면에서 단계별 상태를 지켜봅니다. 끝나면 제목이 Generation Complete! 로 바뀌고 Done 으로 닫습니다.

3번 단계의 갤러리입니다. 위쪽 칩으로 도메인을 좁히고(괄호 안이 그 도메인의 템플릿 수), 카드마다 단계 수와 예상 시간이 적혀 있습니다. 왼쪽 STEPS 는 아직 비어 있고, 오른쪽 TEMPLATE DETAIL 도 Select a template to see its step plan 상태입니다 — 템플릿을 고르면 둘 다 채워집니다.

4번 단계입니다. 카드를 클릭하면 갤러리를 거치지 않고 곧바로 이 화면이 됩니다. 위쪽 Door · General · Safety · SWC · Network · Body 가 변수 그룹 탭이고, 왼쪽 STEPS 와 오른쪽 TEMPLATE DETAIL 이 이 템플릿의 9단계로 채워졌습니다. 오른쪽 아래에 Back 과 Start Generation, 상세 패널 아래에 회색으로 비활성인 Generate Project 가 함께 보입니다 — 아래 두 항목이 이 세 버튼을 설명합니다.

생성을 시작하는 버튼은 마법사의 Start Generation 입니다. 오른쪽 상세 패널 아래의 Generate Project 는 항상 비활성이며 동작하지 않습니다.

마법사의 Back 은 이전 그룹으로 가는 버튼이 아니라 마법사 취소입니다. 입력한 변수를 버리고 갤러리로 돌아갑니다. 그룹 이동은 위쪽 탭으로 합니다.

15.5.2 템플릿

7개 도메인 24종이 있습니다.

도메인	템플릿
Body (6)	Airbag SRS, Door Domain, HVAC Domain, Lighting Domain, Seat Control, Wiper and Washer
Powertrain (7)	BMS Architecture, OBC and DC-DC Converter, Engine Management, Exhaust Aftertreatment, Hybrid Coordinator, Inverter and Motor Control, Transmission Control
ADAS (3)	ACC Lane Keep, Parking Assist, Sensor Fusion
Infotainment (4)	Cluster and HUD, Connectivity, Display and Audio, Navigation and Media
Chassis (2)	Brake and Steering, Suspension and TPMS
Gateway (1)	Central Gateway
Diagnostics (1)	UDS and DoIP

15.5.3 생성 중 일어나는 일

IVC → 시그널 → 데이터 타입 → 인터페이스 → SWC → VFB → (서비스) → System 순으로 만들고, 마지막에 점검 단계를 거칩니다. 앞 단계의 결과를 뒤 단계가 이어받으므로 산출물을 내는 단계가 실패하면 그 뒤는 실행하지 않고 멈춥니다.

실패한 단계에는 두 가지가 붙습니다.

• Show error detail — 오류 메시지 전문을 폅니다.
• Retry (단계 행) — 그 단계와 그 뒤 단계를 되돌린 뒤 그 단계부터 다시 실행합니다.

화면 아래쪽의 Retry 는 성격이 다릅니다. 단계 재시도가 아니라 변수 입력 마법사로 되돌아가는 버튼이며, 입력했던 값이 유지되므로 값을 조금 바꿔 다시 돌릴 수 있습니다.

15.5.4 결과 확인

생성이 끝나면 각 에디터에 내용이 채워져 있습니다.

1. 탐색기에서 프로젝트를 펼쳐 에디터를 하나씩 엽니다.
2. 상태바 V 버튼으로 14. Validation 패널을 열어 제약 위반을 정리합니다.
3. 내보내려면 13. 임포트 · 익스포트 절차를 따릅니다.

15.6 알아 둘 한계

• 활성 라이선스가 필요합니다. 만료 상태면 채팅 버튼과 입력창이 잠기고(툴팁 Plan expired), Quick Start는 업그레이드 안내로 이어집니다.
• 대화 내용과 모델 내용은 선택한 프로바이더로 전송됩니다. 사내 정책에 맞는 프로바이더를 고르세요. Ollama는 로컬 서버로만 통신하므로 외부로 나가지 않습니다.
• 큰 프로젝트는 전부 전달되지 않습니다. 모델이 크면 요약과 목록만 전달되므로, 세부를 다루는 요청일수록 대상을 문장에 구체적으로 적는 편이 좋습니다.
• 제품 내부 구조에 대한 질문은 답하지 않습니다. "소스코드", "내부 구조", "플러그인" 같은 단어가 들어간 질문은 고정 안내로 돌아옵니다. 같은 내용을 AUTOSAR 용어로 바꿔 물으면 정상 처리됩니다. 답변 안의 [internal reference removed] 표시도 같은 이유이며 오류가 아닙니다.
• 생성 결과는 초안입니다. 반드시 사람이 검토합니다.