1장. 왜 지금 개발자는 AI를 배워야 하는가

1. 개발 환경은 계속 바뀌어 왔다

개발자는 원래 변화에 적응하는 직업이다.

예전에는 서버 한 대에 웹 서버와 데이터베이스를 같이 올려서 서비스를 운영하는 경우가 많았다.
서버가 부족하면 장비를 새로 구매하고, IDC에 입고하고, 네트워크를 연결하고, 직접 운영해야 했다.

하지만 클라우드가 등장하면서 개발과 운영 방식이 크게 바뀌었다.

이제는 서버를 직접 구매하지 않아도 된다.
필요한 만큼 서버를 만들고, 트래픽이 줄면 다시 줄일 수 있다.

배포 방식도 바뀌었다.

과거에는 개발자가 서버에 직접 접속해서 소스를 올리고 배포하는 일이 흔했다.
지금은 GitHub Actions, Jenkins, GitLab CI 같은 도구를 사용해 테스트와 배포를 자동화하는 방식이 일반적이다.

AI도 이 흐름과 비슷하다.

처음에는 단순히 질문에 답해주는 챗봇처럼 보였지만, 지금은 개발 방식 자체를 바꾸는 도구가 되고 있다.

예전에는 개발자가 다음 과정을 대부분 직접 처리했다.

요구사항 확인
→ 설계 고민
→ 샘플 코드 검색
→ 코드 작성
→ 에러 해결
→ 테스트 코드 작성
→ 문서 작성
→ 리뷰 대응

하지만 AI를 잘 활용하면 일부 과정은 훨씬 빠르게 처리할 수 있다.

요구사항 정리 초안 생성
→ 설계 방향 비교
→ 코드 예시 생성
→ 에러 원인 분석
→ 테스트 케이스 추천
→ 문서 초안 작성
→ PR 리뷰 보조

중요한 점은 AI가 개발자를 완전히 대체한다는 뜻이 아니라는 것이다.

AI는 개발자가 해야 할 일 중에서 반복적이고 시간이 많이 걸리는 작업을 줄여주는 도구에 가깝다.

다만 이 도구를 잘 쓰는 개발자와 그렇지 않은 개발자 사이에는 생산성 차이가 점점 커질 수밖에 없다.

AI란?
Artificial Intelligence의 약자로, 사람이 하던 판단, 분류, 생성, 예측 같은 작업을 컴퓨터가 수행하도록 만드는 기술을 말한다.
이 책에서는 특히 텍스트, 코드, 이미지, 음성 등을 다루는 생성형 AI를 중심으로 설명한다.

2. AI는 단순한 검색 도구가 아니다

많은 개발자가 처음 AI를 접할 때 이렇게 생각한다.

“구글 검색 대신 ChatGPT에 물어보는 거 아닌가?”

물론 AI를 검색처럼 사용할 수도 있다.
하지만 AI는 단순 검색 도구와는 다르다.

검색 엔진은 기본적으로 관련 문서를 찾아준다.

예를 들어 검색창에 이렇게 입력한다고 해보자.

React useEffect 무한 호출 해결

검색 엔진은 관련 블로그, 공식 문서, Stack Overflow 글을 보여준다.

그다음은 개발자의 몫이다.
여러 글 중에서 현재 상황에 맞는 내용을 찾고, 자신의 코드에 적용해야 한다.

반면 AI에게는 이렇게 물어볼 수 있다.

아래 React 코드에서 useEffect가 계속 호출되는 이유를 설명해주고,
어떻게 수정하면 되는지 알려줘.

[코드 붙여넣기]

AI는 단순히 관련 문서를 찾아주는 것이 아니라, 입력한 코드를 기반으로 문제를 분석하고 수정 방향을 제안한다.

이 차이가 크다.

검색은 정보를 찾는 도구다.
AI는 정보를 바탕으로 정리, 변환, 생성, 추론을 도와주는 도구다.

예를 들어 검색은 다음 질문에 강하다.

PostgreSQL 인덱스 공식 문서

반면 AI는 이런 요청에 강하다.

아래 SQL이 느린 이유를 설명해주고,
인덱스를 어떻게 잡으면 좋을지 예시와 함께 알려줘.

[SQL 붙여넣기]

검색이 자료를 찾는 과정이라면, AI는 자료를 이해하고 활용하는 과정을 도와준다.

물론 AI가 항상 맞는 것은 아니다.
하지만 초안을 만들고, 비교하고, 방향을 잡는 데는 매우 강력하다.

3. 개발자의 역할은 어떻게 달라지는가

AI 시대에도 개발자가 해야 하는 핵심 역할은 여전히 남아 있다.

AI가 코드를 만들어줄 수는 있다.
하지만 그 코드가 실제 서비스에 적합한지는 개발자가 판단해야 한다.

AI가 설계를 제안할 수도 있다.
하지만 회사의 도메인, 운영 환경, 장애 이력, 비용 구조까지 완벽하게 알지는 못한다.

즉, 개발자의 역할은 다음과 같이 바뀐다.

직접 모든 것을 작성하는 사람
→ AI가 만든 결과를 판단하고 설계 방향을 결정하는 사람

예전에는 문법을 정확히 알고, 코드를 빠르게 작성하는 능력이 중요했다.

물론 지금도 그 능력은 필요하다.
하지만 앞으로는 다음 능력이 더 중요해진다.

예를 들어 AI에게 단순히 이렇게 말하면 좋은 결과를 얻기 어렵다.

로그인 API 만들어줘

이 요청은 너무 모호하다.

어떤 언어인지 알 수 없다.
어떤 인증 방식을 쓰는지도 알 수 없다.
DB 구조, 보안 요구사항, 응답 형식도 알 수 없다.

반면 이렇게 요청하면 결과가 훨씬 좋아진다.

Node.js Express 기준으로 로그인 API 예시를 만들어줘.

DB는 PostgreSQL을 사용하고,
비밀번호는 bcrypt로 검증해줘.

로그인 성공 시 JWT를 발급하고,
실패 시에는 계정 존재 여부가 노출되지 않도록 동일한 에러 메시지를 내려줘.

SQL Injection과 비밀번호 로그 노출에 주의해서 작성해줘.

AI를 잘 쓰는 개발자는 단순히 질문을 많이 하는 사람이 아니다.

AI가 제대로 일할 수 있도록 목적, 조건, 제약사항을 명확하게 전달하는 사람이다.

JWT란?
로그인 성공 후 사용자의 인증 상태를 표현하기 위해 사용하는 토큰 방식이다.
서버는 JWT를 통해 사용자가 누구인지 확인하고, API 접근 권한을 판단할 수 있다.

4. AI가 잘하는 일과 못하는 일

AI를 제대로 사용하려면 AI가 잘하는 일과 못하는 일을 구분해야 한다.

AI는 다음과 같은 일에 강하다.

반대로 AI가 약한 부분도 있다.

예를 들어 AI가 결제 API 코드를 만들어줄 수는 있다.

하지만 실제 PG사 연동에서는 다음과 같은 요소를 함께 고려해야 한다.

- 결제 요청 파라미터 검증
- 위변조 방지 서명
- 콜백 검증
- 중복 결제 방지
- 환불 처리
- 장애 시 재처리
- 로그 보관
- 개인정보 처리

AI가 만든 샘플 코드는 출발점으로는 좋다.
하지만 그대로 운영 환경에 넣으면 위험할 수 있다.

AI 시대의 개발자는 “AI가 답을 줬으니 끝”이라고 생각하면 안 된다.

AI의 답을 검토하고, 현재 서비스 구조에 맞게 고치고, 실제 운영 가능한 수준으로 다듬어야 한다.

PG사란?
Payment Gateway의 줄임말이다.
카드 결제, 계좌 이체, 간편 결제 같은 결제 처리를 중계해주는 업체를 말한다.

5. AI는 개발 생산성을 어떻게 높이는가

AI가 개발 생산성을 높이는 방식은 크게 세 가지로 볼 수 있다.

첫 번째는 속도 향상이다.

간단한 유틸 함수, 정규식, SQL 예시, 테스트 코드 같은 것은 AI가 빠르게 초안을 만들어줄 수 있다.

예를 들어 다음과 같이 요청할 수 있다.

이 이메일 검증 정규식의 문제점을 설명하고,
실무에서 사용할 수 있는 수준으로 개선해줘.

아래 SQL에서 성능 문제가 발생할 수 있는 부분을 찾아줘.

이 함수에 대한 Jest 테스트 코드를 만들어줘.

이런 작업은 개발자가 직접 해도 된다.
하지만 AI를 사용하면 초안을 빠르게 만들고, 개발자는 검토와 수정에 집중할 수 있다.

두 번째는 이해 속도 향상이다.

새로운 프로젝트에 투입되었을 때 가장 어려운 일 중 하나는 기존 코드를 이해하는 것이다.

AI는 복잡한 코드를 설명하거나, 함수 간 흐름을 요약하는 데 도움을 줄 수 있다.

예를 들어 다음과 같이 요청할 수 있다.

아래 PHP 코드를 처음 보는 개발자가 이해할 수 있게 설명해줘.

전체 흐름, 주요 조건문, DB 접근 부분을 나눠서 정리해줘.

또는 이렇게 요청할 수도 있다.

이 코드에서 방송 시작 처리와 관련된 부분만 찾아서 흐름을 정리해줘.

세 번째는 품질 보조다.

AI는 사람이 놓칠 수 있는 부분을 한 번 더 점검하는 용도로 사용할 수 있다.

이 API 코드에서 보안상 위험한 부분이 있는지 점검해줘.

입력값 검증, 인증, 권한, 로그 노출 관점에서 봐줘.

물론 AI의 점검 결과가 항상 맞는 것은 아니다.

하지만 개발자가 리뷰하기 전에 1차 체크리스트로 활용하면 실수를 줄이는 데 도움이 된다.

6. AI를 배울 때 조심해야 할 오해

AI를 처음 배울 때 자주 하는 오해가 있다.

6.1 AI가 모든 코드를 대신 짜줄 것이라는 오해

AI는 코드를 만들 수 있다.
하지만 좋은 서비스를 대신 설계해주지는 않는다.

실제 서비스에서는 코드 몇 줄보다 더 중요한 것이 많다.

- 장애가 났을 때 어떻게 복구할 것인가
- 트래픽이 늘면 어떻게 확장할 것인가
- 비용이 얼마나 나올 것인가
- 개인정보는 안전하게 처리되는가
- 운영자가 문제를 추적할 수 있는가
- 다른 팀과의 업무 흐름에 맞는가

이런 판단은 여전히 개발자의 몫이다.

AI는 빠르게 초안을 만들어줄 수 있다.
하지만 그 초안을 서비스 수준으로 끌어올리는 것은 개발자의 역할이다.

6.2 프롬프트만 잘 쓰면 된다는 오해

프롬프트를 잘 쓰는 것은 중요하다.

하지만 AI를 실무에 적용하려면 프롬프트만으로는 부족하다.

AI 기능을 서비스에 붙이려면 다음을 함께 알아야 한다.

- API 호출 구조
- 인증과 권한
- 로그 관리
- 비용 제한
- 장애 처리
- 응답 검증
- 데이터 보안
- 운영 모니터링

AI를 잘 쓰는 것과 AI 서비스를 잘 만드는 것은 다르다.

개인적으로 사용할 때는 질문만 잘해도 충분할 수 있다.
하지만 회사 서비스에 AI 기능을 붙일 때는 시스템 구조와 운영 방식까지 함께 봐야 한다.

프롬프트란?
AI에게 입력하는 요청문이다.
단순한 질문뿐 아니라 역할, 조건, 출력 형식, 예시까지 포함할 수 있다.

6.3 클라우드 AI만 알면 된다는 오해

OpenAI, Claude, Gemini 같은 클라우드 AI는 성능이 좋고 사용하기 쉽다.

하지만 모든 상황에 클라우드 AI가 정답은 아니다.

예를 들어 다음과 같은 경우에는 로컬 AI나 사내망 AI 구성이 필요할 수 있다.

- 개인정보가 포함된 데이터를 외부 API로 보내기 어려운 경우
- 사내 문서를 외부로 전송하면 안 되는 경우
- API 비용이 너무 많이 나오는 경우
- 인터넷 연결 없이 AI 기능이 필요한 경우
- 특정 업무에 맞게 모델을 내부에서 통제하고 싶은 경우

클라우드 AI는 빠르게 시작하기 좋다.
반면 로컬 AI는 보안과 비용 통제에 유리하다.

앞으로의 개발자는 둘 중 하나만 아는 것이 아니라, 상황에 따라 적절한 방식을 선택할 수 있어야 한다.

클라우드 AI와 로컬 AI
클라우드 AI는 외부 AI 서비스를 API로 호출하는 방식이다.
로컬 AI는 개발자 PC나 회사 내부 서버에서 직접 AI 모델을 실행하는 방식이다.

6.4 AI가 만든 답은 믿어도 된다는 오해

AI는 매우 그럴듯하게 틀릴 수 있다.

이 점이 가장 위험하다.

예를 들어 AI가 존재하지 않는 함수명을 만들어낼 수 있다.
오래된 라이브러리 사용법을 최신 방식처럼 설명할 수도 있다.
보안상 위험한 코드를 아무 문제 없는 코드처럼 제안할 수도 있다.

이런 현상을 보통 환각이라고 부른다.

AI 답변은 정답이 아니라 검토해야 할 초안으로 봐야 한다.

개발자는 AI 결과를 사용할 때 다음 질문을 해야 한다.

- 이 코드가 실제로 실행되는가?
- 공식 문서와 맞는가?
- 보안상 문제는 없는가?
- 우리 서비스 구조와 맞는가?
- 예외 상황을 처리하는가?
- 장애가 나면 추적 가능한가?

AI를 믿는 것이 아니라, AI를 활용하되 검증하는 습관이 중요하다.

환각이란?
AI가 사실이 아닌 내용을 그럴듯하게 만들어내는 현상이다.
개발에서는 존재하지 않는 함수, 잘못된 설정, 틀린 공식 문서 링크 등을 만들어내는 식으로 나타날 수 있다.

7. 개발자가 AI를 배워야 하는 현실적인 이유

개발자가 AI를 배워야 하는 이유는 단순히 유행 때문이 아니다.

가장 현실적인 이유는 업무 요구사항이 바뀌고 있기 때문이다.

앞으로 많은 회사에서 다음과 같은 요구가 늘어날 가능성이 높다.

- 관리자 페이지에 AI 요약 기능을 붙여주세요.
- 고객 문의를 자동 분류해주세요.
- 사내 문서를 검색하는 챗봇을 만들어주세요.
- 로그를 분석해서 장애 원인을 추정해주세요.
- PR 리뷰를 자동화해주세요.
- 회의록을 요약하고 액션 아이템을 뽑아주세요.
- 라이브 방송 자막을 자동 생성해주세요.
- 번역 품질을 AI로 보정해주세요.

이런 요구는 단순히 “AI를 써봤다” 수준으로는 해결하기 어렵다.

실제 서비스를 만들려면 AI 모델, API, 데이터, 보안, 비용, 운영까지 함께 이해해야 한다.

예를 들어 사내 문서 검색 챗봇을 만든다고 해보자.

겉으로 보기에는 단순한 챗봇이다.
하지만 내부에는 여러 단계가 필요하다.

문서 수집
→ 문서 분할
→ 임베딩 생성
→ 벡터DB 저장
→ 사용자 질문 분석
→ 관련 문서 검색
→ AI 답변 생성
→ 출처 표시
→ 권한 체크
→ 로그 저장

이 구조를 이해하지 못하면 단순히 AI API만 호출하는 수준에서 멈추게 된다.

하지만 이 구조를 이해하면 회사 내부 업무에 맞는 AI 기능을 직접 설계할 수 있다.

임베딩과 벡터DB
임베딩은 문장이나 문서를 숫자 형태로 바꾸는 방식이다.
벡터DB는 이렇게 바뀐 숫자 데이터를 저장하고, 서로 의미가 비슷한 문서를 빠르게 찾는 데 사용된다.
자세한 내용은 RAG 장에서 다시 다룬다.

8. AI 시대 개발자의 핵심 역량

AI 시대의 개발자는 다음 네 가지 역량을 갖추는 것이 좋다.

8.1 질문을 구조화하는 능력

AI에게 좋은 답을 받으려면 질문이 좋아야 한다.

나쁜 질문은 보통 짧고 모호하다.

이거 고쳐줘.

이런 질문만으로는 AI가 현재 상황을 정확히 알기 어렵다.

좋은 질문에는 목적, 상황, 조건, 원하는 결과가 들어 있다.

아래 코드는 Node.js Express에서 회원 로그인 처리하는 API야.

현재 로그인 실패 시 원인을 구분해서 내려주고 있는데,
보안상 계정 존재 여부가 노출될 수 있어.

실패 메시지를 동일하게 처리하면서도
로그에는 실패 원인을 남기는 방식으로 수정해줘.

질문을 잘 구조화하는 능력은 앞으로 더 중요해진다.

AI가 아무리 좋아져도, 개발자가 원하는 목표를 명확히 설명하지 못하면 좋은 결과를 얻기 어렵다.

8.2 AI 결과를 검증하는 능력

AI가 만든 결과를 그대로 믿으면 안 된다.

특히 개발자는 다음 관점에서 검증해야 한다.

- 코드가 실제로 동작하는가
- 보안 문제가 없는가
- 성능 문제가 없는가
- 예외 처리가 되어 있는가
- 유지보수하기 쉬운가
- 팀의 코드 스타일과 맞는가

AI가 만든 코드는 완성품이 아니라 초안이다.

개발자는 이 초안을 검토하고 실제 서비스 수준으로 다듬어야 한다.

8.3 AI를 시스템에 연결하는 능력

AI를 개인 도구로 쓰는 것과 서비스에 붙이는 것은 다르다.

개인 도구로 쓸 때는 ChatGPT 창에 질문하면 된다.
하지만 서비스에 붙일 때는 다음과 같은 흐름이 필요하다.

사용자 요청
→ 백엔드 API
→ AI 모델 호출
→ 응답 검증
→ 결과 저장
→ 사용자에게 응답
→ 로그와 비용 기록

또한 AI가 외부 도구를 사용해야 하는 경우도 많다.

예를 들어 AI가 Jira 이슈를 조회하거나, GitHub PR을 읽거나, DB에서 데이터를 가져와야 할 수 있다.

이때 필요한 개념이 나중에 배울 MCP와 Tool Calling이다.

MCP와 Tool Calling
Tool Calling은 AI가 필요한 도구나 함수를 호출해 작업을 수행하는 방식이다.
MCP는 AI가 파일, DB, API, 업무 도구 같은 외부 시스템과 연결될 수 있도록 돕는 표준 방식이다.
이 책의 후반부에서 자세히 다룬다.

8.4 비용과 보안을 고려하는 능력

AI는 공짜가 아니다.

특히 클라우드 AI는 대부분 사용량 기반으로 비용이 발생한다.

짧은 테스트에서는 문제가 없어 보일 수 있다.
하지만 실제 서비스에 붙이면 비용이 빠르게 늘어날 수 있다.

예를 들어 사용자가 하루 1만 명이고, 각 사용자가 AI 기능을 여러 번 사용한다면 토큰 사용량이 급격히 증가한다.

그래서 AI 기능을 만들 때는 처음부터 다음을 고민해야 한다.

- 어떤 모델을 사용할 것인가
- 비싼 모델과 저렴한 모델을 어떻게 나눌 것인가
- 같은 요청을 캐싱할 수 있는가
- 사용자별 사용량 제한이 필요한가
- 민감 정보가 AI API로 전송되는가
- 로그에 개인정보가 남지 않는가

AI 개발은 기능 구현만으로 끝나지 않는다.

비용과 보안을 함께 설계해야 실제 서비스에 적용할 수 있다.

토큰이란? AI가 문장을 처리하는 기본 단위다. 단어와 비슷하지만 완전히 같지는 않다. 클라우드 AI에서는 보통 입력 토큰과 출력 토큰 사용량에 따라 비용이 계산된다.

9. 이 책에서 배우게 될 것

이 책은 단순한 AI 개념서가 아니다.

개발자가 AI를 실제 업무와 서비스에 적용할 수 있도록 구성한다.

앞으로 다음 흐름으로 학습한다.

AI 기본 개념 이해
→ 프롬프트와 AI 활용법
→ AI API로 기능 만들기
→ RAG로 사내 데이터 연결하기
→ 클라우드 AI 운영하기
→ 로컬 AI 구성하기
→ AI 코딩 도구 활용하기
→ MCP로 외부 시스템 연결하기
→ AI 에이전트 만들기
→ 보안과 운영 설계하기

처음에는 AI가 무엇인지 쉽게 이해한다.
중간에는 직접 AI 기능을 만들어본다.
마지막에는 실제 업무 자동화와 서비스 운영까지 다룬다.

목표는 하나다.

AI를 단순히 사용하는 개발자가 아니라,
AI를 서비스와 업무 시스템에 연결할 수 있는 개발자가 되는 것

10. 정리

지금 개발자가 AI를 배워야 하는 이유는 명확하다.

AI는 더 이상 단순한 유행이 아니다.
개발 업무의 일부가 되고 있다.

코드 작성, 문서화, 테스트, 리뷰, 장애 분석, 업무 자동화까지 AI가 관여할 수 있는 영역은 점점 넓어지고 있다.

하지만 AI가 모든 것을 대신해주지는 않는다.

AI가 만든 결과를 검증하고, 서비스 구조에 맞게 연결하고, 보안과 비용을 고려해 운영하는 일은 여전히 개발자의 역할이다.

앞으로의 개발자는 AI에게 일을 맡길 줄 알아야 한다.
동시에 AI가 만든 결과를 의심하고 검증할 줄도 알아야 한다.

이 책은 그 균형을 배우기 위한 출발점이다.

1장 핵심 요약