콘텐츠로 이동

AI 시작하기

문서 기준: 2026년 8월

먼저 판단하기: 이 문제에 AI가 적합한가

섹션 제목: “먼저 판단하기: 이 문제에 AI가 적합한가”

인터페이스나 모델을 고르기 전에, 이 문제가 애초에 AI로 풀 문제인가부터 확인합니다. 생성형 AI는 그럴듯한 텍스트·코드·이미지를 만드는 데 강하지만, 검증된 사실, 사내 최신 데이터, 결정론적 계산의 원천이 아닙니다. 다음 네 질문으로 걸러냅니다.

  1. 규칙·계산으로 정확히 풀 문제인가, 아니면 생성·요약·분류처럼 불확실성을 허용하는 문제인가?
  2. 최신 정보나 사내 근거가 필요한가?
  3. 오답이나 잘못된 실행을 사람이 검토하거나 권한으로 제한할 수 있는가?
  4. 성공 기준, 대표 테스트 입력, 비용 상한을 정의할 수 있는가?
문제 성격 권장 접근
결정적 규칙·계산으로 끝남 일반 소프트웨어 (AI 불필요)
정형 데이터 예측·분류 전통 ML (ML 플랫폼)
생성·요약·코딩 보조 생성형 AI (아래 3가지 방법으로)
최신·사내 근거 필요 생성형 AI + RAG·도구 연결
고영향 판단·변경 작업 사람 승인·최소 권한 필수 (AI 보안)

규칙·통계로 끝나는 문제라면 여기서 멈추고 일반 소프트웨어를 쓰세요. AI가 적합하다고 판단했다면, 아래에서 어떤 인터페이스로 사용할지를 정합니다.

AI 도입에서 가장 먼저 정할 것은 “어떤 기술이냐”가 아니라 “우리가 AI를 어떤 인터페이스로 사용할 것인가” 입니다. 크게 세 가지가 있으며, 한 조직이 셋을 병행하는 경우가 많습니다.

사용 방법 무엇인가 주 사용자 대표 예시
① 대화형 AI 앱·플랫폼 완성된 챗봇·코파일럿을 구독해 바로 사용. 노코드 빌더로 사내 봇도 제작 비기술직·일반 임직원, 현업 기획자 ChatGPT, Gemini 앱, Microsoft 365 Copilot, Copilot Studio
② AI 코딩 도구 개발자가 IDE·터미널에서 AI에게 코드 작성·수정을 위임 소프트웨어 엔지니어 GitHub Copilot, Claude Code, Codex, Kiro, Grok Build
③ API·SDK 앱·에이전트가 프로그래밍 방식으로 모델을 호출해 제품에 내장 개발팀, 시스템 통합 Amazon Bedrock API, Azure Foundry SDK, api.openai.com

이 문서는 ①②의 개념과 시작법, 그리고 ③(API로 직접 구축)의 활용 방법을 아래에서 다룹니다.

왜 클라우드에서 AI를 사용하는가

섹션 제목: “왜 클라우드에서 AI를 사용하는가”

프런티어급 파운데이션 모델을 바닥부터 사전학습(Pre-training)하려면 수천만 달러 이상의 대규모 GPU 클러스터, 수조 토큰의 학습 데이터, 수개월의 컴퓨팅 시간이 필요합니다. 대부분의 조직은 이 과정을 직접 수행하지 않고, 클라우드 벤더가 제공하는 준비된 AI 서비스를 사용합니다.

비유하자면, 전기를 직접 발전하지 않고 발전소나 전력망(Power Grid)에서 공급받아 쓰는 것과 같습니다. 우리는 “어떻게 전기를 만들지”가 아니라 “전기로 무엇을 할지”에 집중합니다.

1. 파운데이션 모델 (Foundation Model)

섹션 제목: “1. 파운데이션 모델 (Foundation Model)”

대량의 데이터로 이미 학습된 범용 AI 모델입니다. 대표적으로 LLM (Large Language Model, 대형 언어 모델)이 있습니다. GPT (OpenAI), Claude (Anthropic), Gemini (Google), Nova (Amazon) 같은 이름들이 여기에 해당합니다.

  • 직접 학습할 필요 없이 API를 호출해서 사용합니다.
  • “질문을 하면 답을 하는 똑똑한 비서”라고 생각하면 됩니다.

모델에게 보내는 입력 메시지입니다. “한국의 수도를 알려줘”처럼 자연어로 작성합니다. 어떻게 묻느냐에 따라 답변 품질이 크게 달라집니다.

모델이 텍스트를 처리하는 단위입니다. 대략 단어 한 개가 1–2 토큰입니다. 대부분의 API는 입력/출력 토큰 수로 과금 합니다.

“AI”는 하나의 기술이 아닙니다. 수십 년간 발전해온 여러 기술의 총칭이며, 각 세대가 이전을 대체하는 것이 아니라 공존합니다. 위 3가지 사용 방법은 주로 최신 세대인 생성형·에이전틱 AI를 다루지만, 전통 ML·딥러닝도 여전히 쓰입니다.

세대 핵심 기술 하는 일 클라우드 서비스
전통 ML 회귀, 분류, 클러스터링, 트리 정형 데이터 예측·분류 (이탈 예측, 이상 탐지, 추천) SageMaker AI, Azure ML, Vertex AI, OCI Data Science
딥러닝 CNN, RNN, Transformer 비정형 데이터 처리 (이미지 인식, 음성, 번역) GPU 인스턴스 + ML 플랫폼
생성형 AI 파운데이션 모델 (LLM, 멀티모달) 텍스트/이미지/코드/음성 생성 Bedrock, Microsoft Foundry, Gemini
에이전틱 AI LLM + 도구 호출 + 자율 실행 목표를 주면 스스로 계획·실행·검증 AgentCore, Foundry Agents, Gemini Agent Platform

방법: 무엇으로 AI를 확장하는가

섹션 제목: “방법: 무엇으로 AI를 확장하는가”

같은 파운데이션 모델이라도 어떤 방법으로 우리 문제에 맞추는가에 따라 결과가 달라집니다. 아래 방법들은 특정 사용 방식 전용이 아니라 3가지 사용 방법 전체를 관통합니다 — 예컨대 프롬프트 개선은 ①대화형 앱의 “커스텀 지침”, 내 데이터 연결은 ①의 “파일 업로드”나 노코드 빌더의 지식 연결, ③API의 RAG 파이프라인으로 각각 나타납니다.

아래로 갈수록 비용과 복잡도가 증가하며, 주로 ③(API·SDK)로 직접 구축할 때 단계가 뚜렷합니다.

graph TD
    A[1. 파운데이션 모델 API 호출] --> B[2. 프롬프트 엔지니어링]
    B --> C[3. RAG - 내 데이터 연결]
    C --> D[4. Fine-tuning - 모델 미세 조정]
    D --> E[5. 직접 학습]

가장 간단한 시작점입니다. Amazon Bedrock, Microsoft Foundry, Gemini Enterprise, OCI Enterprise AI 중 하나의 API로 질문을 보내고 답을 받습니다. 챗봇·문서 요약·번역 같은 용도에 바로 쓸 수 있습니다. 벤더별 서비스 비교는 AI 플랫폼과 모델 비교를, 유용한 유스케이스 전반은 이런 상황에서 유용합니다를 참고하세요.

같은 API라도 어떻게 묻느냐에 따라 답이 크게 달라집니다. 역할과 지시를 명확히 주면 코드 작성 없이도 품질이 올라갑니다. 설계 기법 상세는 프롬프트 엔지니어링을 참고하세요.

단계 3: RAG (Retrieval Augmented Generation)

섹션 제목: “단계 3: RAG (Retrieval Augmented Generation)”

파운데이션 모델은 일반 지식은 풍부하지만 내 회사 데이터는 모릅니다. RAG는 내 문서를 검색해 관련 부분을 프롬프트에 포함시킨 후 모델에게 전달하는 기술입니다(비유: “오픈북 시험”). 사내 문서 기반 챗봇, 제품 FAQ, 법률·의료 문서 조회 등에 쓰입니다.

RAG는 벡터 스토어와 함께 동작합니다. 구현 패턴 상세는 RAG 고급 패턴을 참고하세요.

내 데이터로 모델을 미세 조정합니다. 특정 업무에 최적화할 수 있지만 비용과 시간이 크게 증가합니다.

사용 예시:

  • 특정 업계 전문 용어 이해
  • 회사 고유의 말투/스타일 반영
  • 특정 형식의 출력 강제

대부분의 조직에는 필요하지 않습니다. 구글, OpenAI, Anthropic 같은 회사들이 하는 일입니다.

모델 운영·평가·비용 추적은 LLMOps를, AI 보안과 가드레일은 AI 보안을 참고하세요.

아래는 초심자가 학습 순서(단순→고급)로 방법을 고르는 관점입니다. 실무에서 요구사항별로 접근·기술·문서를 바로 찾는 라우팅 관점은 AI 시스템 수명주기 — 기술 태스크별 선택 가이드를 참고하세요.

상황 권장 방법
빠르게 프로토타입을 만들고 싶다 단계 1 (API 호출)
API는 쓰지만 품질이 아쉽다 단계 2 (프롬프트 엔지니어링)
내 회사 문서를 참고해서 답하게 하고 싶다 단계 3 (RAG)
일반 모델이 잘 모르는 전문 도메인이다 단계 4 (Fine-tuning)
모델 자체가 없는 새로운 문제다 단계 5 (직접 학습)

AI 모델을 왜 직접 만들지 않는가

섹션 제목: “AI 모델을 왜 직접 만들지 않는가”
항목 직접 학습 클라우드 API
초기 비용 수천만 달러 규모의 GPU 인프라 API 호출당 수 센트–수십 센트
소요 시간 수개월–수년 수 분 (API 연동)
데이터 수조 토큰의 학습 데이터 필요 모델이 이미 학습됨
전문 인력 ML 엔지니어, 연구자 다수 일반 개발자로 가능
업데이트 재학습 필요 벤더가 자동 업데이트
효과 최첨단 가능 대부분의 업무에 충분
  • 프롬프트 엔지니어링을 건너뛰고 바로 Fine-tuning — 프롬프트 개선만으로 품질이 충분히 올라가는 경우가 많은데, 비용과 시간이 큰 Fine-tuning부터 시도
  • 토큰 비용을 고려하지 않고 설계 — 긴 시스템 프롬프트를 매 요청마다 보내거나, 불필요하게 긴 문서를 컨텍스트에 포함하여 비용 폭증
  • RAG 없이 모델의 내부 지식에만 의존 — 파운데이션 모델은 학습 시점 이후 정보나 사내 데이터를 모르므로 환각(Hallucination) 발생
  • API 호출 → 프롬프트 엔지니어링 → RAG → Fine-tuning 순서로 단계적으로 접근하고 있는가
  • 토큰 사용량과 비용을 모니터링하고 예산 상한을 설정했는가
  • 사내 데이터 기반 답변이 필요한 경우 RAG 파이프라인을 구성했는가