2023년 이후, 개발자 커뮤니티에서 자주 듣는 말 중 하나는 "ChatGPT로 코드 짜면 되지 않나요?"입니다. 실제로 많은 개발자분들이 ChatGPT나 GitHub Copilot을 활용해 코드를 생성하고 있습니다.
그런데 문득 이런 생각이 듭니다. 우리가 AI를 충분히 활용하고 있는 걸까요?
ChatGPT에 "이 기능 만들어줘"라고 입력하고 나온 코드를 복사해서 붙여넣는 것도 물론 AI 활용입니다. 하지만 AI가 제공할 수 있는 가치의 일부만 사용하고 있는 것일 수도 있습니다. AI를 사용하는 것과 AI를 제대로 활용하는 것 사이에는 생각보다 넓은 스펙트럼이 존재합니다.
이 글에서는 개발자로서 AI를 더 효과적으로 활용하기 위해 알아두면 좋은 것들을 이야기하고, 실제 기업들이 AI를 비즈니스에 적용한 사례를 통해 더 넓은 시야를 함께 살펴보겠습니다.
LLM이 어떻게 작동하는지 이해하기
AI를 더 잘 활용하려면, 먼저 LLM(Large Language Model, 대규모 언어 모델)이 어떻게 작동하는지 이해하는 것이 도움이 됩니다. 도구의 특성을 알면 더 적절하게 사용할 수 있기 때문입니다.
LLM은 "확률적 생성기"입니다
ChatGPT나 Claude 같은 LLM은 입력된 문맥을 보고 "다음에 올 가장 자연스러운 단어"를 예측하는 방식으로 문장을 만들어냅니다. 원리만 놓고 보면 스마트폰 키보드의 자동완성과 비슷하지만, 수천억 개의 파라미터와 방대한 학습 데이터 덕분에 훨씬 복잡한 맥락을 이해합니다.
이런 방식으로 동작하기 때문에 LLM에는 몇 가지 특성이 있습니다.
지식의 최신성에 한계가 있습니다
학습 데이터 이후에 나온 정보는 알 수 없습니다. 최근에 출시된 라이브러리의 새 API를 물어보면 예전 버전 기준으로 답하거나, 존재하지 않는 메서드를 생성할 수 있습니다.
때로는 그럴듯하게 틀립니다
이를 업계에서는 '환각(Hallucination)'이라고 부릅니다. "이 라이브러리에 이런 기능이 있어요"라고 자신 있게 말하지만, 실제로는 없는 기능인 경우가 있습니다.
정밀한 계산에 약합니다
복잡한 수학 연산이나 정확한 카운팅은 LLM이 잘하는 영역이 아닙니다.
코드를 생성하지만 실행하지는 않습니다
코드를 작성해줄 수는 있지만, 직접 서버에 배포하거나 데이터베이스를 조작하는 것은 별도의 시스템이 필요합니다.
왜 이걸 알아야 하나요?
이 특성을 이해하면 AI 활용의 폭이 넓어집니다.
AI의 강점을 알면 적극적으로 활용할 수 있습니다. 아이디어 브레인스토밍, 보일러플레이트 코드 생성, 복잡한 개념 설명 요청 등에서 큰 도움을 받을 수 있습니다.
AI의 약점을 알면 적절히 검증할 수 있습니다. 최신 버전 관련 정보나 보안 관련 코드는 공식 문서로 확인하는 습관을 들이면 됩니다.
LLM의 강점과 약점을 파악해야만, 언제 AI를 쓰고 언제 다른 방법을 써야 하는지 판단할 수 있습니다.
AI에게 맥락을 제공하고 결과를 검증하기
AI를 활용할 때 어떤 맥락을 제공하느냐와 결과를 어떻게 검증하는 것이 꽤나 중요합니다. 같은 도구라도 어떻게 쓰느냐에 따라 결과가 완전히 달라집니다. 같은 질문이라도 맥락을 얼마나 잘 제공하느냐에 따라 답변 품질이 달라집니다.
맥락이 적은 질문:
"이 에러 어떻게 해결해?"
맥락이 풍부한 질문:
"Python 3.11 + FastAPI 환경에서 비동기 DB 조회 중 'connection pool exhausted' 에러가 발생합니다. 현재 connection pool size는 5이고, 동시 요청이 약 50개입니다. SQLAlchemy async를 사용 중입니다."
전자의 경우 AI는 일반적인 에러 해결 방법을 나열할 수밖에 없습니다. 후자의 경우 AI는 문제를 정확히 파악하고 "pool size를 늘리거나, connection 재사용 로직을 점검하거나, 요청 수를 제한하는 방법" 같은 구체적인 해결책을 제안할 수 있습니다.
좋은 질문에는 보통 이런 정보가 들어갑니다.
•
사용 중인 기술 스택과 버전
•
현재 상황과 기대하는 결과
•
이미 시도해본 방법과 그 결과
•
관련 코드나 에러 메시지
다만 AI의 답변을 그대로 복사-붙여넣기 하는 것은 위험합니다. AI는 자신 있는 말투로 틀릴 수 있기 때문입니다. 특히 다음과 같은 경우에 주의가 필요합니다.
최신 버전 관련 정보
학습 데이터 이후 변경되었을 수 있습니다. React 19의 새 기능을 물어봤는데 React 18 기준으로 답변하는 경우가 흔합니다.
보안 관련 코드
취약점이 있는 패턴을 제안할 수 있습니다. SQL 쿼리 작성이나 인증 로직에서 AI 코드를 그대로 쓰면 보안 사고로 이어질 수 있습니다.
성능 크리티컬한 로직
일반적으로는 맞지만 특정 상황에서 문제가 될 수 있습니다. 대용량 데이터를 다룬다면 알고리즘 복잡도를 한 번 더 생각해보시면 좋습니다.
AI의 답변을 출발점으로 삼고, 중요한 부분은 직접 검증하는 습관을 들이면 생산성과 안정성을 모두 챙길 수 있습니다.
실제 사례로 보는 문제에 따른 다양한 접근 방법
AI를 비즈니스에 적용한 기업들의 사례를 보면, 문제의 성격에 따라 다른 기술을 선택했다는 공통점이 있습니다. 지금 당장 직접 구현할 수 있어야 한다는 이야기가 아닙니다. 이런 선택지들이 있다는 것을 아는 것만으로도 문제를 바라보는 시야가 넓어집니다.
유형 1: RAG, 최신 정보 기반 답변이 필요할 때
RAG(Retrieval-Augmented Generation)는 번역하면 "검색 증강 생성"입니다. 쉽게 말해, LLM에게 질문하기 전에 먼저 관련 문서를 찾아서 함께 보여주는 방식입니다.
예를 들어 회사의 쿠버네티스 클러스터에서 발생한 오류를 ChatGPT에 물어본다고 가정해 보겠습니다. ChatGPT는 일반적인 쿠버네티스 지식은 알고 있지만, 여러분 회사의 내부 설정이나 최신 매뉴얼은 전혀 모릅니다.
RAG는 이 문제를 해결합니다. 질문이 들어오면 먼저 회사 내부 문서에서 관련 자료를 검색하고, 그 자료를 LLM에게 함께 전달합니다. 여기서 사용되는 것이 벡터 검색인데, 이는 텍스트를 숫자 배열(벡터)로 변환한 뒤 의미적으로 비슷한 문서를 찾는 방식입니다. 키워드가 정확히 일치하지 않아도 관련 문서를 찾을 수 있다는 장점이 있습니다.
사례: 삼성 SDS의 SKE-GPT
삼성 SDS는 자사 클라우드 플랫폼(SCP)의 쿠버네티스 서비스 문의를 처리하는 SKE-GPT를 개발했습니다.
전체 고객 문의의 약 68%가 이미 존재하는 가이드 문서만으로 해결 가능한 사례였는데요, 문서는 있는데 찾기가 어려웠던 문제를 해결하고자 개발했다고 합니다.
SKE-GPT는 클러스터 상태를 자동 진단하고, 관련 내부 문서를 벡터 검색으로 찾은 뒤, 그 정보를 바탕으로 해결책을 안내합니다. RAG 적용 전에는 "SCP를 알려줘"라는 질문에 엉뚱한 답변이 나왔지만, 적용 후에는 삼성 클라우드 플랫폼에 대한 정확한 정보를 제공할 수 있게 되었습니다.
사례: Uber의 Genie
Uber도 사내 온콜 엔지니어들을 위한 Q&A 코파일럿 Genie를 RAG 기반으로 구축했습니다. 매월 약 45,000건의 질문이 Slack 채널을 통해 들어오는데, 많은 질문이 이미 문서화되어 있지만 정보가 여러 곳에 흩어져 있어 찾기 어려웠습니다.
Genie는 사내 위키, Stack Overflow, 기술 문서 등을 벡터 DB에 인덱싱하고, 질문이 들어오면 관련 문서를 검색해 LLM에게 전달합니다. 출시 이후 70,000건 이상의 질문에 답변하며 13,000시간의 엔지니어링 시간을 절약했습니다.
초기에는 단순 RAG로 시작했지만, 정확도를 높이기 위해 문서 강화와 사후 검증 단계를 추가한 Agentic-RAG 구조로 발전시켰습니다. 이를 통해 허용 가능한 답변 비율을 27% 향상시키고, 잘못된 답변을 60% 감소시켰습니다.
유형 2: 에이전트, LLM이 스스로 작업을 해야할 때
고객이 "주문을 취소하고 환불받고 싶어요"라고 문의했다고 가정해 보겠습니다. 이 요청을 완전히 처리하려면 주문 정보 조회 → 환불 정책 확인 → 실제 환불 처리 → 결과 안내라는 여러 단계가 필요합니다. 단순한 챗봇으로는 실제로 시스템에 액션을 취하는 것이 어렵습니다.
에이전트는 LLM이 외부 도구를 호출하고, 여러 단계의 작업을 수행할 수 있게 해줍니다. 단순히 답변을 생성하는 것을 넘어서, 실제로 API를 호출하고 데이터를 변경할 수 있는 거죠.
사례: Minimal의 고객지원 자동화
네덜란드 이커머스 스타트업 Minimal은 LangGraph 프레임워크를 활용해 역할이 다른 여러 AI 에이전트가 협업하는 시스템을 구축했습니다.
플래너 에이전트가 문의를 분석해서 하위 작업으로 나눕니다. 예를 들어 "주문 취소하고 싶고, 웹사이트에 오류도 있어요"라는 문의가 오면, "환불 처리"와 "기술 문제 해결"이라는 두 개의 서브태스크로 분리합니다.
리서처 에이전트가 각 서브태스크에 필요한 정보를 찾습니다. 환불 처리에는 환불 정책 문서를, 기술 문제에는 오류 해결 매뉴얼을 검색합니다.
툴 실행 에이전트가 실제 조치를 수행합니다. Shopify API를 호출해서 주문을 취소하고, 환불을 처리하고, 그 결과를 기록합니다.
이 방식을 통해 80% 이상의 응대 효율 향상을 달성했으며, 고객 문의의 90% 이상을 AI가 자율 처리하는 것을 목표로 운영 중입니다. 하나의 거대한 LLM에게 모든 것을 맡기는 것보다, 전문화된 에이전트들이 분업하는 것이 더 안정적이었다고 합니다.
물론 안전장치도 두었다고 합니다. AI가 처리하기 어려운 케이스는 사람에게 에스컬레이션하는 구조를 만들었습니다. AI가 100% 완벽할 수 없다는 걸 인정하고, 한계 상황에 대비한 거죠.
이 기술들을 당장 구현할 줄 알 필요는 없습니다. "이런 문제에는 이런 접근법이 있구나"를 아는 것, 그래서 필요할 때 찾아보거나 전문가와 이야기할 수 있는 것만으로도 충분히 의미가 있습니다.
당신의 AI 러닝 갭은 어느 정도인가요?
이 글에서 다룬 내용을 다시 정리하면 다음과 같습니다.
•
LLM의 작동 원리와 한계 이해하기
•
맥락 제공과 결과 검증하기
•
문제 유형별 기술 선택지 알기
이 중에서 자신 있는 영역도 있고, 아직 낯선 영역도 있을 겁니다. AI 기술은 빠르게 발전하고 있고, 모든 개발자가 이 변화를 따라잡기는 쉽지 않으니까요.
혼자서 학습하기 막막하거나 실무에서 어떻게 적용해야 할지 구체적인 방향이 필요하다면, F-Lab에서 준비한 무료 웨비나를 통해 실전적인 인사이트를 얻어보세요.
참고 자료
무단 복제 및 배포 금지
이 자료의 모든 저작권은 F-Lab에게 있습니다. 저작권자의 허락 없이 본 자료의 전체 또는 일부를 복사하거나 배포하는 행위는 금지됩니다.