AI란 무엇이고, 어떻게 써야 제대로 쓰는 걸까
AI, 머신러닝, 딥러닝, LLM이 어떤 관계인지 정리하고, 대화형 AI가 답을 만드는 방식과 그 때문에 생기는 한계(환각, 학습 시점), 그리고 결과를 좋게 만드는 다섯 가지 사용법과 개발할 때 쓰는 요령을 다룹니다.
"AI 써봤어?"라는 말이 가리키는 것
요즘 "AI를 쓴다"고 하면 대부분 ChatGPT, Claude, Gemini 같은 대화형 서비스에 질문을 던지는 걸 말합니다. 그런데 뉴스에서는 자율주행, 추천 알고리즘, 사진 보정까지 전부 AI라고 부릅니다. 같은 단어가 너무 넓게 쓰이다 보니 "AI가 뭘 할 수 있고 뭘 못 하는지"도 흐릿해집니다.
이 글은 두 가지를 정리합니다. AI라는 말이 실제로 무엇을 가리키는지, 그리고 지금 우리가 쓰는 대화형 AI를 어떻게 써야 결과가 좋아지는지입니다.
AI, 머신러닝, 딥러닝, LLM은 어떤 관계인가
네 단어는 서로 다른 것이 아니라 큰 범위 안에 작은 범위가 들어가는 관계입니다.
| 용어 | 뜻 | 예시 |
|---|---|---|
| 인공지능(AI) | 사람이 지능적이라고 여기는 일(인식, 판단, 언어 이해 등)을 컴퓨터가 하도록 만드는 기술 전체 | 체스 프로그램, 스팸 필터, 챗봇 |
| 머신러닝 | 규칙을 사람이 직접 짜는 대신, 데이터에서 패턴을 학습하게 하는 방법 | 메일 내용을 보고 스팸 여부 분류 |
| 딥러닝 | 여러 층으로 쌓은 인공신경망으로 학습하는 머신러닝 방법 | 이미지 인식, 음성 인식 |
| 대규모 언어 모델(LLM) | 방대한 텍스트로 학습한 딥러닝 모델. 문장을 이해하고 만들어 냄 | ChatGPT, Claude, Gemini의 바탕 모델 |
정리하면 AI ⊃ 머신러닝 ⊃ 딥러닝 ⊃ LLM 입니다. 지금 화제가 되는 "생성형 AI"는 이 중에서 글, 이미지, 코드처럼 새로운 결과물을 만들어 내는 모델을 묶어 부르는 말입니다.
LLM은 답을 어떻게 만드는가
LLM의 기본 동작은 생각보다 단순합니다. 지금까지의 문장 다음에 올 가능성이 높은 토큰(단어 조각)을 하나씩 이어 붙이는 것입니다. 엄청난 양의 텍스트를 학습했기 때문에 그 결과가 자연스럽고 논리적으로 보입니다.
이 구조를 알면 AI의 약점이 왜 생기는지도 이해됩니다.
- 그럴듯하지만 틀린 답(환각, hallucination): 모델은 "사실인지"가 아니라 "그럴듯한지"를 기준으로 문장을 만듭니다. 그래서 없는 논문, 없는 함수, 틀린 날짜를 자신 있게 말할 수 있습니다.
- 학습 시점 이후는 모름: 모델은 학습 데이터가 끝나는 시점(knowledge cutoff)까지의 정보만 압니다. 웹 검색 기능이 붙은 서비스가 아니라면 최신 소식이나 최신 라이브러리 버전은 틀릴 수 있습니다.
- 같은 질문, 다른 답: 생성 과정에 무작위성이 있어서 같은 질문에도 매번 표현이나 결론이 조금씩 달라질 수 있습니다.
즉, AI는 아는 것을 꺼내 주는 검색 엔진이 아니라, 문장을 생성하는 도구입니다. 이 차이를 기억하는 것만으로도 사용 방식이 달라집니다.
맡기기 좋은 일, 조심해야 할 일
| 맡기기 좋은 일 | 조심해야 할 일 |
|---|---|
| 초안 작성 (메일, 문서, 기획 메모) | 사실 확인 없이 그대로 쓰는 정보 |
| 긴 글 요약, 핵심 뽑기 | 정확한 수치·통계·날짜 |
| 어려운 개념을 쉬운 말로 풀어 설명 | 법률·의료·세무처럼 책임이 따르는 판단 |
| 아이디어 브레인스토밍 | 최신 뉴스, 최신 버전 정보 (검색 기능이 없을 때) |
| 코드 설명, 에러 메시지 해석 | 이해하지 못한 코드를 그대로 배포 |
공통점은 하나입니다. 결과를 내가 검토할 수 있는 일에 쓰면 강력하고, 검토할 수 없는 일에 쓰면 위험합니다.
잘 쓰는 다섯 가지 방법
1. 상황과 목적을 먼저 알려 준다
AI는 내가 누구이고 왜 묻는지 모릅니다. 질문이 짧을수록 가장 평범한 답이 나옵니다.
1나쁜 예: 2회의록 요약해줘. 3 4좋은 예: 5아래는 프론트엔드 팀 주간 회의록이야. 회의에 못 온 팀원이 읽을 거라서, 6결정된 사항과 각자 맡은 일만 bullet 5개 이내로 정리해줘. 7결정되지 않은 논의는 "보류"로 따로 표시해줘.
좋은 예에는 누가 읽는지, 무엇이 필요한지, 어떤 형태로 받고 싶은지가 들어 있습니다.
2. 결과 형식을 지정한다
표, 목록, 글자 수, 말투를 정해 주면 다시 고치는 일이 줄어듭니다. "3줄로", "표로 비교해서", "존댓말로" 같은 짧은 조건만으로도 결과가 꽤 달라집니다.
3. 한 번에 끝내려 하지 않는다
첫 답이 마음에 들지 않으면 처음부터 다시 묻기보다 대화를 이어 가는 편이 낫습니다. "두 번째 항목을 더 구체적으로", "더 짧게", "초보자 기준으로 다시" 처럼 고칠 부분을 짚어 주면 됩니다.
4. 검증은 사람이 한다
- 사실이나 수치는 원문 출처를 직접 확인합니다.
- 코드는 실행해 보고, 테스트를 돌려 봅니다.
- 계산은 다시 계산해 봅니다.
"출처를 같이 알려줘"라고 요청할 수도 있지만, AI가 제시한 출처 자체가 존재하지 않을 수도 있으니 링크를 직접 열어 보는 것까지가 확인입니다.
5. 민감한 정보는 넣지 않는다
비밀번호, API 키, 주민등록번호 같은 개인정보, 회사 내부 코드나 문서는 입력하지 않는 것이 기본입니다. 입력한 내용이 어떻게 저장되고 학습에 쓰이는지는 서비스와 요금제마다 다르므로, 업무에 쓴다면 해당 서비스의 데이터 정책과 회사 규정을 먼저 확인해야 합니다.
개발할 때는 이렇게 쓴다
프론트엔드 개발에서 AI가 특히 유용한 순간은 이런 때입니다.
- 처음 보는 코드나 라이브러리 동작을 설명받을 때
- 에러 메시지와 스택 트레이스를 해석할 때
- 테스트 케이스나 반복적인 보일러플레이트의 초안을 만들 때
- 리팩터링 방향을 여러 개 비교해 볼 때
질문할 때는 환경 정보와 실제 에러, 관련 코드를 같이 주는 것이 핵심입니다.
1Next.js 15(App Router) + TypeScript 프로젝트야. 2서버 컴포넌트에서 아래 코드를 실행하면 3"useState only works in Client Components" 에러가 나. 4원인을 설명하고, 컴포넌트를 어떻게 나누면 되는지 알려줘. 5 6(관련 코드 붙여넣기)
그리고 받은 답은 이렇게 다룹니다.
- 이해하지 못한 코드는 붙여 넣지 않습니다. 설명을 다시 요청해서 내가 설명할 수 있을 때까지 묻습니다.
- 없는 API를 만들어 낼 수 있습니다. 처음 보는 함수나 옵션이 나오면 공식 문서에서 실제로 있는지 확인합니다.
- 버전 차이를 의심합니다. 예전 버전 방식의 코드가 나오는 경우가 많으니, 질문할 때 버전을 적고 답도 그 버전 기준인지 확인합니다.
핵심 한 줄
AI는 그럴듯한 문장을 아주 빠르게 만드는 도구입니다. 맥락을 충분히 주고, 결과는 사람이 검증한다는 원칙만 지켜도 훨씬 믿을 만한 동료가 됩니다.