전문가반을 수료한 당신은 지금 '부품'을 만들 줄 압니다. RAG(20회차)·에이전트(21회차)·평가와 서빙(22회차)·신뢰성 운영(23회차)·자체 모델(24회차)까지, 각각을 코드로 만들어 봤어요. 그런데 현업에서 이 부품들은 따로 떨어져 있지 않습니다. 회사 전체가 매일 쓰는 하나의 '내부 플랫폼'으로 엮여서 돌아가죠. 이 마지막 회차는 새 기술을 배우는 자리가 아니라, '지금까지 만든 것들이 실제 직무로 어떻게 묶이는가'를 보는 에필로그입니다. 모델이 아니라 '조직이 일하는 방식'을 설계하는, 'AI Native 엔지니어'의 하루를 따라가 봅니다.
🏢 AI Native Engineering이란 — 'AI를 기본값으로 일하는 팀'
AI Native Engineering은 기획-개발-QA-배포-운영으로 이어지는 소프트웨어 생애주기(SDLC) 전체의 확장성·안정성·생산성을 끌어올리되, 그 모든 일을 'AI Native'하게 — 즉 AI를 특별한 이벤트가 아니라 일상의 기본값으로 — 해내는 팀을 말합니다. 'AI를 가끔 쓴다'가 아니라 '모든 업무의 디폴트가 AI'라는 전제에서 일하는 방식 자체를 다시 설계하는 거예요. 그 중심축이 셋입니다.
- Platform Engineering(확장성) — 임직원이 매일 쓰는 워크플로우·업무 솔루션을 '플랫폼'으로 만들어, 한 번 만든 걸 모두가 재사용하게 한다(22회차 '플랫폼화'의 전사판).
- SRE(안정성) — 그 플랫폼이 사람 없이도 매일 안 죽고 돌아가게 한다(23회차 신뢰성·운영의 전사판).
- Productivity Engineering(생산성) — AI Agent를 SDLC 전반과 전사 업무에 녹여 '누구나 빠르게 랜딩하고 더 빠르게 끝내는' 일하는 방식을 설계한다.
이 팀이 만드는 '내부 플랫폼'은 결국 업무의 시작부터 종료까지를 하나의 흐름으로 잇는 뼈대예요. 흩어진 도구 모음이 아니라, 아래처럼 네 개의 층이 세로로 연결된 한 줄기입니다.
# 내부 플랫폼의 뼈대 — 업무의 시작부터 끝까지를 '하나의 흐름'으로
#
# ① 업무 진입점 (슬랙·사내 포털 등 '일을 시작하는 곳')
# │
# ② 표준 프로세스 (SDLC · 결재/컴플라이언스 · 인프라 · 플랫폼)
# │
# ③ 산출물 / 지식 레이어 (문서·코드·로그가 쌓이는 곳 = RAG의 원천)
# │
# ④ AI Agent Overlay (①~③ 위에 얹혀, 중간중간 끼어들어 돕는 에이전트들)
#
# 이 네 칸을 하나로 이으면 — 업무의 '시작 → 종료'가 가시화·자동화·측정 가능해진다.
# AI Native 엔지니어의 일 = 이 흐름을 설계하고, 그 위에 에이전트를 얹는 것.🧩 멀티에이전트 오케스트레이션 — 21회차의 '한 명'에서 '팀'으로
21회차에서 '에이전트 한 명'을 코드로 만들었죠(툴 호출 + 루프 + 하네스). 현업 플랫폼에는 그런 에이전트가 여럿 들어갑니다. 각자 역할이 다르고, 서로 일을 넘겨주며 협업해요. 이걸 조율하는 게 멀티에이전트 오케스트레이션입니다. 비유하면, 혼자 다 하는 만능 직원 대신 '기획·개발·리뷰·배포 담당'으로 나뉜 작은 팀을 꾸리고, 그 사이에 업무 지시서가 오가게 만드는 일이에요.
- 역할 정의 — 각 에이전트가 '무엇을 책임지고, 어떤 툴을 쓸 수 있는가'를 명확히 쪼갠다(한 에이전트에 다 몰면 21회차에서 봤듯 금방 헷갈린다).
- 오케스트레이션 — '누가 먼저, 누구에게, 무엇을 넘기는가'의 흐름을 설계한다(순차·병렬·조건 분기).
- 서브에이전트 협업 — 메인 에이전트가 하위 작업을 전문 서브에이전트에게 위임하고 결과를 모은다(사람 팀의 '담당자에게 맡기고 취합'과 똑같다).
🧭 비즈니스 문제를 'AI 문제'로 번역하기
현업에서 가장 값진 역량은 모델을 돌리는 손이 아니라, '이 문제를 AI로 풀어야 하는가, 푼다면 어떻게?'를 판단하는 머리예요. 서비스·업무 쪽에서 들어온 문제를 받아, 독립적으로 분해하고 제안하는 일이죠. 11회차의 'RAG vs 파인튜닝', 24회차의 '프롬프트 → RAG → 파인튜닝' 순서가 바로 이 판단의 도구입니다.
- ① 진짜 문제 찾기 — 요청받은 '증상'이 아니라 그 뒤의 '목표'를 캔다('챗봇 만들어줘'가 아니라 '상담 대기시간을 줄이고 싶다').
- ② AI 문제인지 판정 — 규칙·검색·대시보드로 풀리면 AI를 쓰지 않는 게 정답일 때도 많다.
- ③ 접근법 선택 — AI라면: 지식이 문제면 RAG, 여러 단계 작업이면 에이전트, 말투·형식 고정이 핵심이면 파인튜닝(보통 조합).
- ④ 성공 기준 먼저 — '무엇이 되면 성공인가'를 숫자로 먼저 정의한다(22회차 eval). 이게 없으면 끝을 모르는 프로젝트가 된다.
🗄️ 단위 AI 서비스의 아키텍처 — 수집 → 전처리 → 서빙
접근법을 정했으면 하나의 AI 서비스로 조립합니다. 핵심은 데이터가 흐르는 전체 파이프라인을 그리는 것 — 데이터 수집 → 전처리 →(필요하면 학습)→ 서빙까지요. 그리고 각 단계에 맞는 '저장소(스토리지)'를 고르는 안목이 필요합니다. 데이터 성격에 따라 넣을 서랍이 다르거든요.
- 벡터DB(예: pgvector·Qdrant 등) — '의미가 비슷한 것'을 찾는 RAG 검색용(20회차의 임베딩이 사는 곳).
- 관계형DB(예: PostgreSQL) — 사용자·주문·권한처럼 '정확한 표 데이터'와 트랜잭션용.
- 오브젝트 스토리지(예: S3·GCS) — 원본 문서·이미지·로그 파일처럼 '큰 덩어리'를 싸게 쌓아두는 곳.
- 캐시/큐 — 반복 호출 결과를 재사용하거나(비용↓), 무거운 작업을 비동기로 밀어넣을 때.
그리고 이 서비스의 심장인 '단위 에이전트'는 세 가지로 고도화합니다. 전부 전문가반에서 이미 만든 부품이에요. 툴 호출(Tool calling, 21회차)로 외부와 행동하고, 메모리(Memory, 23회차)로 맥락을 기억하며, RAG(20회차)로 우리 지식을 참조합니다. 이 셋을 한 에이전트에 결합하면 '검색하고, 기억하고, 행동하는' 제대로 된 일꾼이 됩니다.
🔁 평가·개선 루프 — 22회차 eval의 '현업판'
만들었다고 끝이 아니라, '정말 나아졌나'를 숫자로 닫아야 합니다(22·24회차의 그 원칙). 현업에서는 이걸 한 번이 아니라 '계속 도는 루프'로 만들어요. 성능 검증용 데이터와 평가지표를 스스로 설계하고, 운영에서 나온 결과를 분석해 모델·프롬프트의 개선 방향을 도출하고, 다시 반영하는 사이클입니다.
- ① 평가셋 설계 — 우리 문제에 맞는 골든셋과 지표를 직접 만든다(정답률·형식 준수·지연·비용).
- ② 측정 — 배포 전/후를 같은 잣대로 잰다('좋아진 것 같다' 금지, 'X%→Y%'로).
- ③ 분석 — 틀린 사례를 모아 '왜 틀렸나'를 분류한다(검색 실패? 프롬프트? 데이터 부족?).
- ④ 개선 → 반영 → 다시 ① — 원인에 맞는 처방(프롬프트 수정·RAG 보강·파인튜닝)을 하고 재측정.
☁️ 운영 인프라 — 왜 쿠버네티스·클라우드인가 (쉬운 비유)
사내 모두가 매일 쓰는 플랫폼은 '내 노트북에서 돌아갑니다'로는 안 됩니다. 수백~수천 명의 요청을, 누가 안 봐도, 끊김 없이 받아내야 하죠. 그래서 클라우드(AWS·GCP)와 쿠버네티스(Kubernetes, 흔히 K8s)가 등장합니다. 어렵게 느껴지지만 역할은 단순해요.
- 클라우드(AWS·GCP) — 서버·GPU·DB를 '내가 사서 두는' 대신 '필요한 만큼 빌려 쓰는' 곳. 트래픽이 늘면 더 빌리고, 줄면 반납해 비용을 맞춘다.
- 쿠버네티스(K8s) — 수많은 '일꾼(컨테이너)'을 자동으로 세우고·죽은 걸 되살리고·요청량에 맞춰 수를 늘렸다 줄이는 '매니저'. 점심에 주문이 몰리면 알바를 더 부르고 한가하면 돌려보내는 매장 관리자에 가깝다.
- 성능 최적화 — 대용량 트래픽에서 느려지지 않게 캐시·배치·양자화 모델(24회차)·vLLM 서빙(22회차)을 조합해 '같은 돈으로 더 빠르게'를 만든다.
🙋 Human-in-the-loop & 거버넌스 — 금융에서 특히 중요한 이유
전사 자동화의 마지막 열쇠는 '사람을 어디에 남길 것인가'입니다. 모든 걸 에이전트에게 맡기는 게 아니라, 중요한 길목마다 사람이 승인·개입하는 Human-in-the-loop(HITL)를 설계해요. 플랫폼에는 '누가 무엇을 할 수 있는가(권한)', '무슨 일이 언제 일어났는가(감사 로그)', '민감정보는 어떻게 지키는가(보안)'가 함께 박혀 있어야 합니다. 자동화의 속도와 안전의 제동을 같이 거는 거죠.
증권·금융은 규제 산업이라 이게 특히 절실합니다. 에이전트의 잘못된 자동 실행 하나가 곧바로 고객 자산 손실이나 규제 위반, 컴플라이언스 사고로 이어질 수 있거든요. 그래서 '사람이 반드시 승인하는 단계'와 '모든 행동이 추적되는 감사 기록'은 금융 도메인에서 선택이 아니라 기본값입니다. AI Native 엔지니어는 자동화를 밀어붙이는 동시에, 어디에 사람의 손을 남겨야 사고가 안 나는지를 아는 사람이에요.
🧰 프레임워크 지형 한눈에 — LangChain·LlamaIndex
위의 에이전트·RAG·오케스트레이션을 처음부터 다 짜지는 않습니다. 바퀴를 다시 만들 필요가 없을 땐 프레임워크를 씁니다. 어디에 뭘 쓰는지 지도만 잡아두세요.
- LangChain / LangGraph — 에이전트·워크플로의 '배관'. 여러 LLM 호출·툴·분기·상태·멀티에이전트 흐름을 엮는 뼈대(21회차의 그 역할을 프레임워크로).
- LlamaIndex — 문서를 읽혀 RAG를 세우는 데 특화(20회차). '지식 레이어 → 검색'을 빠르게 붙일 때 강하다.
- 프레임워크 없이(직접 SDK 호출) — 흐름이 단순하면 프레임워크가 오히려 군더더기. '복잡해질 때만 도입'이 건강한 기본값이다.
📌 25회차 핵심
- AI Native Engineering = SDLC 전반을 Platform(확장성)·SRE(안정성)·Productivity(생산성) 세 축으로, 'AI를 기본값'으로 끌어올리는 일.
- 내부 플랫폼의 뼈대 — 업무 진입점 → 표준 프로세스 → 지식 레이어 → Agent Overlay를 하나로 이어 '가시화·자동화·측정'.
- 직무의 핵심 = 멀티에이전트 오케스트레이션 + 비즈니스 문제의 AI 번역 + 파이프라인/스토리지 설계 + 평가 루프 + HITL·거버넌스 + K8s·클라우드 운영.
- 전문가반의 부품(RAG·에이전트·평가·서빙·파인튜닝)이 이 직무 안에서 하나로 합쳐진다 — 당신은 이미 그 부품들을 만들어 봤다.
🎓 전문가반을 닫으며 — 다음은 '현업'입니다
18회차에서 코드 토대를 잡고 24회차에서 모델까지 만들며, 당신은 흩어진 '부품'을 손에 쥐었습니다. 이번 회차가 보여준 건, 실제 회사에서 그 부품들이 'AI Native 엔지니어'라는 하나의 직무로 묶인다는 사실이에요 — 모델을 넘어 '조직이 일하는 방식'을 설계하는 자리죠. 다음에 무엇을 더 준비하면 좋을지 네 방향으로 정리합니다.
- 멀티에이전트 — 에이전트 '한 명'을 넘어 '팀'을 조율해보기(LangGraph 등으로 서브에이전트 협업 플로우 한 번 설계).
- 플랫폼 사고 — '내가 쓸 기능'이 아니라 '남들이 재사용할 플랫폼'으로 만드는 연습(22회차 플랫폼화 확장).
- HITL·거버넌스 — 권한·감사·승인 흐름을 넣은 '안전한 자동화'를 작게라도 설계해보기(특히 규제 도메인 지망이면 필수).
- 운영 인프라 — Docker → Kubernetes → 클라우드(AWS/GCP)의 기초 흐름을, 23·24회차에서 만든 서비스를 올려보며 체득.