이 자료의 목적은 특정 AI 도구를 외우는 것이 아니다. 서비스를 만드는 전체 과정에서 AI를 어디에, 어떤 방식으로 활용할 수 있는지 이해하고 각 지점마다 무엇을 조심해야 하는지 아는 것이다.
생성형 AI는 코드를 작성할 때만 쓰는 것이 아니다. 개발 → 배포 → 운영으로 이어지는 순환 구조의 여러 지점에서 서로 다른 방식으로 개입한다.
생성형 AI가 언제, 어떻게 개입하는가에 따라 활용법과 리스크가 완전히 달라진다.
이 자료에서는 생성형 AI 활용을 다음 네 가지 관점으로 나눠서 본다.
개발자가 주도하면서 AI와 대화해 설계·코딩·디버깅·문서화를 한다.
AI가 계획 → 코드 작성 → 실행 → 테스트 → 수정의 작업을 직접 반복한다.
완성된 서비스 안에서 LLM이 사용자 응답이나 검색·요약·분류 등을 수행한다.
로그·오류·모니터링 데이터를 AI가 분석해 운영자를 돕거나 일부 작업을 자동화한다.
아래로 갈수록 AI의 주도권이 커지고, 오른쪽으로 갈수록 실수의 영향 범위가 커진다. 그래서 보통 ③ → ② → ① → ④ 순서로 익히는 것이 안전하다.
아래 용어는 이 자료 전체에서 반복해서 등장한다. 몰라도 읽을 수는 있지만, 미리 알고 읽으면 훨씬 빠르게 이해된다.
| 용어 | 한 줄 설명 |
|---|---|
| 토큰 (Token) | 모델이 텍스트를 처리하는 최소 단위. 영어는 약 4글자당 1토큰, 한글은 보통 더 잘게 쪼개진다. |
| 컨텍스트 윈도우 | 모델이 한 번에 참고할 수 있는 입력+출력의 최대 토큰 양. 이 범위를 넘으면 앞부분 내용을 잊는다. |
| 프롬프트 엔지니어링 | 원하는 결과를 얻기 위해 지시문(prompt)을 설계하는 기법. |
| 파인튜닝 (Fine-tuning) | 모델의 가중치 자체를 특정 데이터로 추가 학습시키는 것. 비용·난이도가 높다. |
| RAG | 모델을 재학습하지 않고, 검색된 문서를 프롬프트에 함께 넣어 답변 근거로 쓰는 방식. |
| 임베딩 (Embedding) | 텍스트를 의미가 비슷하면 가까운 위치에 놓이는 숫자 벡터로 바꾼 것. 의미 기반 검색의 기초. |
| 에이전트 / 툴 유즈 | 모델이 스스로 다음 행동을 계획하고, 코드 실행·파일 접근 같은 외부 도구를 직접 호출하는 방식. |
| 환각 (Hallucination) | 모델이 근거 없이 그럴듯하지만 사실이 아닌 내용을 생성하는 현상. |
| 가드레일 (Guardrail) | 모델의 입출력을 제한·검증해 위험하거나 잘못된 동작을 막는 장치. |
두 가지는 서로 다른 경험이다. 왼쪽(③②)은 개발 방법의 변화이고, 오른쪽(①)은 소프트웨어 자체의 변화다. 이 자료는 두 가지를 구분해서 각각 설명한다.
단계마다 AI가 강한 부분과 자주 틀리는 부분이 다르다. 결과를 검증 없이 그대로 받아들이는 것이 가장 흔하고 위험한 실수다.
| 단계 | 잘하는 것 | 흔한 실패 | 학생이 놓치기 쉬운 점 |
|---|---|---|---|
| ③ 개발자 보조 | 보일러플레이트 코드, 설명, 리팩터링 제안 | 존재하지 않는 라이브러리/API를 만들어냄, 오래된 문법 제안 | 설명하지 못하는 코드를 그대로 제출하는 것 |
| ② 에이전틱 개발 | 구현 → 테스트 루프를 빠르게 반복 | 테스트는 통과했지만 요구사항 자체를 잘못 이해, 불필요한 파일 변경 | diff를 확인하지 않고 그대로 merge하는 것 |
| ① 런타임/제품 | 자연스러운 문장 생성, 방대한 정보 요약 | 근거 없이 그럴듯한 오답(환각), 최신 정보 미반영 | 답변에 출처가 없어도 검증 없이 믿는 것 |
| ④ 운영 자동화 | 로그 패턴 요약, 후보 원인 제시 | 상관관계를 인과관계로 단정, 근본 원인을 놓치고 증상만 대응 | AI가 제시한 원인 하나만 보고 바로 조치하는 것 |
가장 쉽게 시작할 수 있는 영역이다. 사람이 설계하고 판단하며 AI를 강력한 개발 보조자로 사용한다. 실수가 발생해도 개발자가 직접 확인할 수 있어 진입 장벽이 가장 낮다.
| 무엇을? | 왜? | 어떻게? | 찾아볼 도구 |
|---|---|---|---|
| 요구사항 정리 | 생각을 구조화하기 위해 | 아이디어를 설명하고 질문·수정 반복 | ChatGPT, Claude |
| 설계 | 구조를 여러 관점에서 검토하기 위해 | API·DB·모듈 구조를 AI와 논의 | ChatGPT, Claude |
| 코딩 | 반복 구현 시간을 줄이기 위해 | 코드 생성 → 읽기 → 실행 → 수정 | Copilot, Cursor, Windsurf |
| 디버깅 | 원인 탐색을 빠르게 하기 위해 | 오류 메시지와 관련 코드를 제공 | ChatGPT, Claude, IDE AI |
참고할 도구: VS Code(무료), GitHub Copilot(학생 인증 무료), Cursor / Windsurf(무료 티어), Claude / ChatGPT(무료 티어)
여기서는 한 단계 더 나아간다. AI에게 코드 한 줄을 물어보는 것이 아니라 하나의 개발 작업 전체를 맡긴다. 사람은 지시하고 승인/거부하는 감독자 역할을 한다.
| 무엇을? | 왜? | 어떻게? | 찾아볼 도구 |
|---|---|---|---|
| 레포지토리 작업 | 여러 파일을 넘나드는 반복 작업 자동화 | 작업 목표와 제약조건을 자연어로 지정 | Claude Code, Codex |
| 버그 수정 | 분석→수정→테스트 반복 자동화 | 버그 리포트 + 테스트 조건 제공 | Claude Code, Aider |
| 에이전트 병렬 작업 | 여러 기능을 동시에 시도 | 작업을 작은 단위로 분리 | Google Antigravity 등 |
개발이 끝났으면 실제 사용자가 접근할 수 있도록 배포해야 한다. 이 단계부터는 코드만 알아서는 부족하고 실행 환경을 이해해야 한다.
| 무엇을? | 왜? | 찾아볼 도구 |
|---|---|---|
| 간단한 웹 배포 | 서비스를 실제 URL로 공개 | Vercel, Render, Streamlit |
| 서버 API 배포 | 백엔드를 외부에서 실행 | FastAPI + Cloud/Server |
| 실행 환경 패키징 | 내 컴퓨터와 서버의 차이를 줄임 | Docker, Podman |
| 여러 컨테이너 관리 | 서비스를 규모 있게 운영 | Kubernetes |
이제 AI를 개발자가 사용하는 것이 아니라 서비스의 사용자가 사용하게 만든다. 사람의 리뷰 없이 실시간으로 사용자에게 직접 노출되므로 리스크가 가장 크다.
사람의 리뷰 없이 실시간으로 응답이 생성되어 사용자에게 직접 전달된다.
| 무엇을? | 왜? | 찾아볼 도구 |
|---|---|---|
| LLM 호출 | 서비스에서 생성형 AI 사용 | OpenAI API, Anthropic API |
| RAG | 내 문서를 검색해 답변에 활용 | LlamaIndex, LangChain |
| Vector Search | 의미가 비슷한 자료 검색 | FAISS, Chroma, Pinecone |
| 로컬 LLM | API 없이 로컬에서 실험 | Ollama + 오픈 모델 |
서비스는 배포했다고 끝나지 않는다. 오류가 발생하고, 사용량이 늘고, 서버 상태가 변한다. 운영 단계에서는 AI가 운영 데이터를 사람이 이해하기 쉬운 정보로 바꾸는 역할부터 시작할 수 있다. 시스템 전체에 즉시 영향을 미치므로 인프라 이해가 필수다.
| 무엇을? | 왜? | 찾아볼 도구 |
|---|---|---|
| 에러 수집 | 서비스에서 발생한 오류 확인 | Sentry |
| Metrics | CPU·메모리·요청량 등의 변화 관찰 | Prometheus |
| 시각화 | 운영 상태를 한눈에 확인 | Grafana |
| CI/CD 자동화 | 빌드·테스트·배포 과정 자동화 | GitHub Actions |
| AI 분석 | 로그·장애 상황 요약 및 분석 | LLM API + 직접 만든 스크립트 |
가장 좋은 이해는 각 카테고리를 따로 보는 것이 아니라 하나의 서비스 안에서 어떻게 이어지는지 보는 것이다. 예: AI 학교 공지사항 Q&A 서비스.
배포·운영 단계로 갈수록 AI가 대신 판단해주지 않는 영역이 커진다. AI는 로그를 요약해줄 뿐, 그 요약이 실제로 타당한지 판단하는 것은 결국 기초 지식이다.
| 수업에서 배운 것 | 실전에서 쓰이는 지점 |
|---|---|
| 운영체제 | 컨테이너가 왜 안 뜨는지, 프로세스/메모리 문제인지 파악 |
| 네트워크 | API 응답이 느린 이유가 네트워크 지연인지 타임아웃 설정인지 구분 |
| 데이터베이스 | 쿼리 성능·인덱스 문제인지 AI가 제시한 원인이 맞는지 검증 |
| 자료구조/알고리즘 | AI가 생성한 코드의 시간·공간 복잡도가 적절한지 판단 |
.env + .gitignore 사용).생성형 AI 호출은 대부분 토큰(입력+출력 글자 단위) 수에 비례해 과금된다. 학생 프로젝트에서는 크게 체감하지 못하지만, 실제 서비스를 설계할 때는 이 감각이 직접적인 영향을 준다.
| 상황 | 고려할 것 |
|---|---|
| 실험 / 학습 단계 | 로컬 LLM(Ollama)으로 비용 0원으로 반복 테스트 |
| 프로토타입 배포 | 가벼운 모델로 먼저 검증하고, 필요할 때만 고성능 모델 사용 |
| 실서비스 운영 | 프롬프트 길이, 캐싱, 호출 빈도를 설계 단계에서부터 고려 |
| 응답 속도가 중요한 경우 | 모델 크기와 응답 품질 사이의 트레이드오프를 저울질 |
생성형 AI 도구는 매우 빠르게 바뀐다. 특정 도구 이름을 암기하는 것보다 문제를 보고 필요한 도구를 찾아가는 능력이 중요하다.
| 내가 하고 싶은 일 | 검색 방법 |
|---|---|
| AI로 코딩하고 싶다 | AI coding assistant |
| AI에게 프로젝트 작업을 맡기고 싶다 | agentic coding tools |
| 웹 서비스를 공개하고 싶다 | deploy FastAPI / deploy Streamlit |
| LLM을 프로그램에서 호출하고 싶다 | LLM API Python tutorial |
| 내 문서로 챗봇을 만들고 싶다 | RAG Python tutorial |
| 로컬 LLM을 사용하고 싶다 | Ollama local LLM |
| 서비스 로그를 보고 싶다 | application monitoring Python |
| 로그를 AI로 분석하고 싶다 | LLM log analysis |
이 네 가지 분류는 실제 채용 공고와 직무 구분에도 가깝게 연결된다.
| 카테고리 | 관련 직무 / 현업 키워드 |
|---|---|
| ① 런타임 / 제품 | AI/ML Engineer, Applied AI, Backend + LLM 통합 |
| ② 에이전틱 개발 | 아직 직무명이 고정되지 않았지만, 개발 생산성 도구로 전 직군에서 요구 증가 |
| ③ 개발자 보조 | 대부분의 SW 엔지니어 채용 공고에서 "AI 도구 활용 경험" 언급 증가 |
| ④ 운영 자동화 | SRE, DevOps, Platform Engineer |
면접에서 "AI를 어떻게 활용하는가"라는 질문을 받으면, 이 네 가지 구분을 설명하고 각 단계의 장단점을 예로 들 수 있으면 도움이 된다.
예전에는
의 각 단계를 사람이 직접 수행하는 비중이 컸다.
이제는
개발자의 핵심 능력은 코드를 직접 입력하는 속도만이 아니라, 문제를 정의하고, AI에게 적절한 일을 맡기고, 결과를 검증하고, 서비스 전체를 이해하는 능력으로 확장되고 있다.