이노시뮬레이션 IT직군 약 22명이 이틀 과정 끝에 전원 RAG 챗봇을 코드로 구현했다. 용어는 알지만 써본 적 없는 개발 조직에는 기능 소개 대신 구조 설명·코드·실행 순서가 결과를 냈다. 같은 과정을 들이려면 참가자의 개발자 비율과 구현 경험 유무부터 확인해야 한다.
마곡의 AR 연구 기업 이노시뮬레이션은 개발자 비중이 높은 기술 조직이다. 이노시뮬레이션 교육 기록(2025년 5월 16일)에 따르면 이 조직은 밖에서 보면 이미 기술 친화적이었지만, 안에서는 RAG·LLM·Agent 같은 용어에 익숙할 뿐 직접 구현해 본 경험이 거의 없었다. 교육 중 한 참가자의 말이 그 상태를 보여 준다. "RAG나 LLM이라는 용어는 계속 들었지만, 실제로 써본 적은 없었습니다."
이 조직의 고민은 넷이었다. 개발자와 비개발자 모두 문서 작업·리서치·엑셀 정리 같은 반복 업무가 많았고, 생성형 AI로 자동화하면 좋겠다는 인식은 있었지만 어디까지 가능한지 감이 없었으며, 용어는 알아도 구현 경험은 없었고, 개발 직군에서는 "개발에 AI를 실제로 한 번 적용해보고 싶다"는 요구가 분명했다. 여기에 ChatGPT 기능 소개로 시작하는 교육을 넣으면 참가자는 아는 것을 다시 듣는다.
그래서 목표를 한 줄로 잡았다. "AI를 사용해본 사람이 아니라, AI를 업무와 개발에 실제로 적용해본 사람을 만드는 것"이다.
개발자 80%에 리더 그룹까지 공학적 이해도가 높았던 구성이 순서를 정했다
| 항목 | 내용 |
|---|---|
| 기관 | 이노시뮬레이션(AR 연구·기술 기업, 마곡) |
| 일정·인원 | 2일 과정, 약 22명 |
| 참가자 | 개발자 80%, 일반 직무 20%(리더 그룹 다수, CTO 포함) |
| 방식 | 실습 중심, 코드 작성, 미니 실험 |
| 도구 | Gamma, ImageFx, NotebookLM, VBA, LLM API(RAG·Agent·MCP) |
일반 직무 20%도 공학적 이해도가 높은 리더 그룹이 다수였고 CTO가 자리에 있었다. 원문은 개념에서 구조로, 구조에서 코드로, 코드에서 실제 실행으로 이어지는 방식이 필요했다고 적었다.
기존 생성형 AI 교육의 흐름은 ChatGPT 기능 소개, 활용 사례 설명, 툴 소개로 끝나는 순서다. 이번 과정은 이를 뒤집었다. 왜 이 구조가 필요한지를 먼저 설명하고, 그 구조를 코드로 구현하는 실습을 거쳐, 실제로 실행되어 동작하는 결과물까지 확인하는 순서다. 원문이 짚은 조건은 하나다. AI 개발자가 직접 진행해 제품 설명이 아니라 현업에서 개발하며 쓰는 방식 그대로 전달했다는 것이다.
첫날은 업무 시간이 줄어든다는 체감을, 둘째 날은 '실제로 동작했다'는 경험을 목표로 잡았다
전체 흐름은 AI를 이해하고, 직접 사용하고, 개발에 적용하고, 업무에 활용하는 네 단계였다.
첫날의 관점은 생성형 AI를 질문 도구가 아니라 일을 위임하는 도구로 보는 것이었다. 자동화 파이썬 코드와 GPT 기반 내부 봇 구축 사례를 공유한 뒤, Gamma로 PPT를, ImageFx로 이미지를, NotebookLM으로 논문 요약과 팟캐스트를 만드는 문서·콘텐츠 자동화 실습으로 이어졌다. 첫날의 목표는 "이 정도까지는 바로 업무 시간을 줄일 수 있구나"라는 체감이었다.
둘째 날은 개발에 붙이는 날이었다. 싱글턴과 멀티턴 대화 구조를 직접 설계하는 프롬프트 실습, 생성형 AI와 VBA를 묶어 엑셀·문서 작업을 노코드에 가깝게 자동화하는 실습을 거쳐, API 기반으로 RAG 개념과 Agent 구조, MCP 개념을 다루고 RAG가 적용된 챗봇을 코드로 구현했다. 원문이 둘째 날에서 가장 중요하게 꼽은 것은 "이해했다"가 아니라 "실제로 동작했다"는 성공 경험이다.
결과는 전원의 RAG 챗봇 구현이었고, 확장의 출발점은 감이 아니라 동작한 경험이었다
이틀 뒤 남은 것은 세 가지다. 참가자 전원이 RAG가 적용된 챗봇을 코드 레벨에서 직접 구현했고, 문서 자동화 플로우를 실제로 실행했으며, AR 관련 최신 논문을 NotebookLM으로 수집·요약·정리하는 방법을 익혔다.
한 참가자는 이렇게 말했다. "RAG나 LLM 용어만 듣고 언젠가 써봐야지 했었는데, 수업을 통해 직접 RAG가 탑재된 챗봇을 만들어볼 수 있어서 좋았습니다." 교육 전 발언과 짝을 이루는 문장으로, '들었다'가 '만들었다'로 바뀌었다.
참가자들은 개발에 AI를 어디에 어떻게 붙일 수 있는지 감을 잡았고, 업무 자동화는 아이디어가 아니라 실행 가능한 영역으로 내려왔다. 개발자 비중이 높은 만큼 질문의 깊이가 깊었고 실습 몰입도도 높았다. 원문의 결론은 AI 교육에서 중요한 것이 얼마나 많은 기능을 소개했는지가 아니라 하나라도 직접 구현해 봤는지 여부라는 것이다. 다음 과제로는 조직의 실제 업무 데이터를 더 많이 반영해 한 단계 확장한 형태를 들었다.
가져갈 것
- 참가자의 개발자 비율과 비개발자의 공학적 배경(리더 그룹·CTO 참여 여부)을 교육 전에 파악했는가
- 참가자가 RAG·LLM·Agent를 용어로 아는 단계인지, 코드로 돌려본 단계인지 구분해 두었는가
- 과정 목표가 "AI를 사용해본 사람"이 아니라 "업무와 개발에 실제로 적용해본 사람"으로 적혀 있는가
- 강의 순서가 기능 소개·사례·툴 소개가 아니라 왜 이 구조인지 설명, 코드 구현, 동작 확인으로 짜여 있는가
- 이틀 안에 참가자 전원이 코드 레벨에서 직접 돌리는 결과물(RAG 챗봇 등) 하나가 정해져 있는가
- 강사가 현업에서 개발하며 쓰는 방식 그대로 전달할 수 있는 AI 개발자인가
안 되는 경우
- 원문이 밝히지 않은 것: 교육 실시 일자와 하루 시간, 사용한 LLM API·모델과 벡터 DB, RAG에 넣은 문서의 양, 사전 개발 환경(Python·API 키) 준비 방식, 만족도 같은 설문 수치.
- 원문이 맞지 않는다고 적은 조직: ChatGPT 사용법 같은 기초만 원하거나, 코드를 쓰지 않는 개념 강의를 선호하거나, 당장의 결과물보다 이론 정리를 앞세우는 곳.
- 개발자 80%에 나머지도 공학적 이해도가 높은 리더 그룹이었던 조직에서 확인된 결과다. 비개발자가 다수인 조직에서 같은 순서가 성립하는지는 원문이 다루지 않는다.
- 실습에 조직의 실제 업무 데이터가 얼마나 들어갔는지는 밝히지 않았고, 강사 스스로 다음에는 실제 업무 데이터를 더 반영하고 싶다고 적었다. 사내 데이터로 바로 돌아가는 RAG를 기대하면 조건이 다르다.
이번 주에 바꿀 것은 개발팀 AI 교육 기획서의 첫 줄이다. 다룰 기능 목록 대신 참가자 전원이 마지막 날 직접 돌릴 결과물 하나를 적고, 그 결과물에서 거꾸로 왜 이 구조인지 설명과 코드 실습을 배치한다. 개발 직군 대상 과정을 검토 중이라면 조녁컴퍼니의 교육 구성을 확인할 수 있다. 사업영역 →