참여 배경: AWS 외면할 수 없던 이유
부트캠프에서 Final Project를 진행하며 그토록 궁금해왔던 AWS DATA PIPELINE을 직접 설계하고 구현하게 되었다.
AWS를 처음 하면서 든 기대감도 있지만, '이거 잘못 누르면 비용 폭탄 맞는거 아니야?'라는 걱정도 있었지만..!
Automation Infrastructure의 개념과 사람이 반복적으로 운영하던 코드를 넘기는 구조에 흥미를 느껴서 이번 웨비나에 참여하게 되었다.
이번 웨비나는...
단순히 개발자용 웨비나가 아니라 앞으로 클라우드 환경에서 일하게 될 사람을 위한 웨비나에 가까워다. 기술 → 운영 → 비즈니스 의사결정으로 이어지는 흐름으로 AI가 어디까지 자동화가 가능하고, 사람은 어느 지점에서 책임을 지고, 중소기업에서 투가지용과 향휴 유지비용에서 어느정도 효과가 있을지 알 수 있었다.
Q&A에서 가장 많이 배운 포인트 정리
1. Bedrock vs RAG vs Nova Forge - 'AI 커스터마이징 레벨 차이'
RAG(Retrieval Augmented Generation)은 모델 그대로 질문 시 외부 문서를 붙여서 참고하는 방식의 말그대로 문서를 기반으로 증강시켜 찾는 것이며,
Fine-tuning은 모델의 가중치를 수정하여 특정 스타일과 업무에는 강해지지만 재앙적 망각(새로운 데이터/작업(Task)를 학습하면서, 이전에 배운 기존 지식을 잃어버리는 현상)의 리스크가 있지만,
Nova Forge는 모델 학습 중간 단계에서 기업 데이터를 직접 통합하여 기존 추론 능력은 유지시키면서 비즈니스 맥락을 강화시킬 수 있다고 하였다.
이 Q&A를 보면서 단순히 RAG를 써봤어요!가 끝이 아니라, 왜 RAG를 썼고, 왜 Fine-tuning이 아닌지를 설명할 수 있어야 한다는 사실을 다시 생각하게 되었다.
2. AI Agent - '자동화의 한계는 기술이 아닌 책임'
AI Agent가 안정적으로 할 수 있는 일과 반드시 사람이 개입해야 하는 일의 기준은?
AI가 잘하는 영역은 통합 데이터 기반 최적화이며 스케줄링, 초안 생성, 반복 작업이다. 여기서 사람은 안전, 신뢰, 최종 책임을 져야 하는데 AI가 다 해주고 신뢰한다는 마인드보단, 제안자 역할로 받아들여야 한다.
강사님께서 말씀하셨듯이 LLM은 숫자, 연산 능력이 뛰어나지만, 이 기술을 사용할 것인가는 사람에게 맡겨져 있다.
3. 보안 자동화 - '자동으로 바뀌는 건 코드가 아닌 PR'
IAM, 네트워크 보안 설정을 AI가 직접 바꾸는 것이 아닌, 문서화된 PR로 생성해서 Git History로 Audit Trail를 확보해서 최종 병합은 사람 승인을 본다면 통제 가능한 자동화가 되면서 Rollback도 가능하다.
PR은 사람과 사람간 체크인 줄 알았는데 AI도 개입한다면 2번에서 말한 것도 가능하면서 보안에도 신경쓸 수 있는 기회가 될 것 같다.
그동안 AWS 써봤어요, ETL 파이프라인을 만들어봤어요에서 끝나는 것이 아니라, 왜 그 선택을 하게 되었고 운영과 책임 구조를 설명할 수 있어야 한다는 것을 알게 되었다. 그리고 KIRO에 대한 내용도 나왔었는데, 6개월 간 KIRO를 사용해보면서 Task 단위로 분리하는데 생산성은 이미 체감했지만, 하나의 Task에서 발생한 변경 사항이 다음 Task에 설계 의도까지 포함해서 정확히 반영되는지에 대한 의구심은 들었따. KIRO도 단순 작업 나열이 아니라 하나의 Pipeline으로 Task 간 명확한 input/output을 정의하고 변경 시 영향받는 Task 범위를 명시하면 변경이 안전하게 전달되는 구조로 사용될 수 있지 않을까하는 생각도 들었다.