[AI] LLM : AI Literacy에 대한 고찰

Background

위키피디아에 AI Literacy (이하, 'AI 리터러시')를 찾아보았다. "개인이 AI 기술을 비판적으로 평가하고 AI와 효과적으로 커뮤니케이션 및 협업하며, 온라인, 가정 및 직장에서 AI를 도구로 사용할 수 있는 일련의 역량"이라고 정의한다. AI 리터러시는 2가지의 측면으로 구상이 가능할 것 같다. 첫째는 'AI의 작동 원리를 이해하고 본인이 원하는 답변을 이끌어 내도록 환경을 구축하고 활용할 수 있는가?'이고, 둘째는 'AI가 처리한 결과물에 대해서 무조건적인 믿음이 아닌 비판적 사고로 받아들이고, 이를 평가 및 판단할 수 있는가'이다. 우리는 이제는 더 이상 괄시할 수 없는 AI에 대해서 보다 활용을 잘하기 위해서, 'AI 리터러시'라는 과제에 대해서 좀 더 고민하고 공부를 해볼 필요가 있다고 생각한다.
 
2022년 말에 ChatGPT라는 친구가 등장했다. 이때만 해도 그냥 또 다른 AI 장난감이라고 생각했다. 2023년도에는 점차 검색 엔진의 대용으로 사람들이 사용하기 시작했다. 솔직히 ChatGPT는 너무 아는 척해서 탈이었다. 마치 내가 대학생 때에 번역기로 영어 과제를 했을 때처럼, 학생들이나 신입 친구들은 ChatGPT의 답변을 그대로 복사/붙여 넣기 했다. 심지어 아는 척하는 ChatGPT의 답변을 맞다고 생각하고, 이에 대해서 틀리다고 말하는 시니어의 의견에 반하여 ChatGPT를 두둔해 주었다. 2019년부터 AI/ML에 대해서 공부도 하고, 대학원 수업을 들으면서 논문도 읽어오던 나에게는 AI/ML은 향후 모바일 서비스를 개발하는 데 있어서, 필수불가결하게 응용해야 할 기술로 받아들였다. 하지만 AI에 의해서 개발자 간의 기술 지식의 시비 논쟁을 만드는, 또 모르는데 아는 척하는 AI가 싫었다. 그런데 2024년을 너머 2025년이 되면서 AI는 몰라보도록 발전을 거듭했다. 불과 2~3년의 시간이 지났지만, 아는 척하던 AI는 좀 더 정확한 답변을 내놓기 시작했다. 현재는 나도 이해가 어려운 부분은 AI에게 묻고는 한다. 하지만 AI는 정확한 답변을 항상 내놓기만 하는가...? 꼭 그렇지만은 않다. 하지만 보다 정확한 답변을 하게 만들기 위한 시도는 계속되고 있다.
 
LLM이라는 단어를 처음 접했던 것은 2021년도쯤인 것 같다. 자연어의 영역과 인류의 지식은 너무 거대하기 때문에 천문학적인 비용을 들여서 학습을 시켜야 한다고 했다. 그래서 흔히 우리가 말하는 AI 기업과 훌륭한 스펙을 지닌 사업가들이 자본을 투자받아서 거대한 모델을 학습하기 시작했다. 그리고 LLM이라는 물건을 내놓았다. 'Pre-training, Fine-tuning'이란다. 비용이 큰 general knowledge는 미리 학습을 시킨다. 그리고 우리가 질문하는 내용의 세부적인 부분을 prompt라는 것으로 보강해 준다.
 

AI Infrastructure

LLM (Large Language Model)

LLM은 이미 유수의 회사들이 제품을 서비스하고 있다. 자연어는 촘스키의 언어 위계 상으로 문맥 의존 언어에 해당한다.  프로그래밍 언어는 'if'라는 키워드가 어느 공간에 위치하든 똑같은 '조건/분기'의 의미로 존재한다. 하지만 자연어에서는 위치에 따라서 조건이 될 수도, '인지/ 아닌지'의 부사절이 될 수도, 벌어지지 않은 일에 대한 가정문 등으로 사용될 수 있다. 이러한 문맥 의존적 특성 때문에 자연어 처리는 기존 알고리즘만으로 해결하기 어려운 영역이었다. RNN, LSTM 등의 자연어, 솔직히 자연어보다는 선형 데이터 처리를 위한 모델들이 나왔다. 그러나 이를 획기적으로 해결한 것은 'Attention is all you need'라는 이름의 논문이었다. Transformer는 자연어의 문맥을 유지하면서 각 키워드의 실질적인 내용에 보다 정확하게 접근하도록 해주었다. 문제는 좀 더 다양한 대화가 가능하고 보다 많은 지식을 학습하기 위해서, 더욱 많은 가중치로 구성된 언어 모델이 필요하다는 것이다. 이 가중치, 즉 파라미터 수는 현존하는 LLM 기준으로 어느새 2조 8천억 개가 되었다고 한다. 참고로 인간의 뇌는 1,000억 개 정도의 뉴런과 160조 개 정도의 시냅스가 존재한다고 한다.
 

MCP (Model Context Protocol)

이렇게 LLM이 점점 자연어를 이해하고 지능적으로 발전하면서 활용도가 높아졌다. 일반적인 대화와 질의뿐만이 아니라, 질문과 문제를 이해하고 분석한 다음에 코드나 문서를 만드는 수준으로 올라선 것이다. 각 회사에서 만든 LLM들은 각 회사에서 학습한 방법과 방향성에 따라서 아래와 같은 서로 다른 특징들을 지닌다. 

	ChatGPT	Claude	Gemini	Copilot
주요 용도	범용 LLM (대화, 코딩, 문서, 이미지 등 멀티모달)	대화, 분석, 문서 이해 중심 (긴 컨텍스트 강점)	멀티모달 + 에이전트 기반 작업 자동화	코드 자동완성, 리팩토링, 개발 보조
모델 구조	Transformer 기반 (GPT-4 / 4-Turbo / 4o)	Constitutional AI 기반 Transformer	Gemini 1.x~2.x (Transformer + multimodal encoder)	GPT 계열 기반 모델(OpenAI 모델 활용)
멀티모달 지원	✅ 텍스트 + 이미지 입력 (GPT-4o는 음성도 지원)	⚪ 텍스트 중심 (이미지 실험적)	✅ 텍스트 / 이미지 / 오디오 / 비디오	⚪ 텍스트(코드) 중심
컨텍스트 윈도우	8K ~ 128K (GPT-4 Turbo 기준)	최대 200K (Claude 3 Opus 기준)	32K ~ 1M (Gemini 2.5 Flash/Pro)	IDE 내 코드 파일 단위로 자동 추론
강점	고품질 응답, 창의적 작업, 추론 능력 탁월	매우 긴 문서/분석, 안정적 톤, 윤리적 설계	구글 생태계 통합, 멀티모달 강점	개발 환경 통합, 생산성 향상
약점	긴 대화 시 컨텍스트 한계, 비용 높음	멀티모달 제한적, 창의성 다소 보수적	실사용 접근성 낮음(2025년 기준 일부 제한)	코드 외 대화/일반 문맥 약함
도구 연동 (Tool Use)	✅ Code Interpreter, Web browsing, API 호출	✅ Tool Use 강화 (API 실행 가능)	✅ Google Search, Docs, Sheets, Actions	⚪ IDE 한정 기능 (VS Code, JetBrains 등)
API 제공 여부	✅ (OpenAI API, Azure OpenAI Service)	✅ (Anthropic API, AWS Bedrock 등)	✅ (Vertex AI / Gemini API)	✅ (GitHub Copilot API 일부)
대표 사용처	ChatGPT, Copilot+, 기업용 챗봇, 데이터 분석	기업 문서 분석, 보고서 요약, 법률문서 검토	Google Workspace 통합, 에이전트형 서비스	GitHub, VSCode, JetBrains IDE
주요 인터페이스	ChatGPT / API / Playground	Claude.ai / API	Gemini App / Google Workspace	IDE Plugin (VSCode, JetBrains)
가격 정책	토큰 단위 과금 (모델별 차등)	토큰 단위 과금 (문서량 중심)	Google Cloud 과금 체계	월 구독 (개인 $10~, 기업 $19~)
특징 요약	가장 범용적이고 강력한 멀티모달 LLM	안정성 중심, 긴 문서처리 탁월	멀티모달·검색 통합형, 구글 서비스 연동	개발자 생산성 특화형 AI 도구

이렇게 다양한 LLM들이 제공되다 보니, 또 다른 이슈가 발생한다. 다양한 LLM을 기반으로 동질의 서비스를 제공하려는 문제이다. 우리는 LLM에게 보다 정확한 질문을 하고 이에 대한 답변을 받기 위해, LLM이 참고할만한 데이터를 준비하고 찾을 수 있는 인프라 구축이 필요하다. 하지만 각 LLM의 프로토콜이 다르다면 이에 대한 서비스 구축의 비용이 늘어날 것이다. 그래서 MCP라는 표준 프로토콜이 만들어졌다. 덕분에 이 표준 프로토콜을 사용한 MCP Server/Client를 통해 LLM 이용이 가능해졌다. 일반적으로 MCP Server는 로컬에 띄우거나 클라우드 상에 배포하여 이용 가능하다. MCP Server는 LLM에 질의하기 위해 사용할 데이터와 기능의 성격에 따라 선택해서 구축 가능하다. Client는 각 회사에서 제공해 주는 경우도 있고 직접 구현하기도 한다. 우리가 IDE 혹은 플러그인을 설치했다면, 그것이 MCP Client라고 보면 된다. MCP Client를 설치한 후에 어떤 MCP Server를 통해서 질의를 진행할지 설정이 가능하다. 의도하는 혹은 정확한 답변을 받고 싶다면, 본인이 참고하고 싶은 데이터의 성격이나 기능에 따라 설정된 MCP Server를 Client에 연동하도록 하자.
 

RAG (Retrieval-Augmented Generation)

RAG는 LLM에게 보다 적합한 질문을 통해서 정확한 답변을 얻기 위한 첫 과정이다. 각 LLM은 MCP 규격 하에 각 클라이언트에서 편리한 질의가 가능해졌다. 편리해졌다면 이제는 정확해져야 한다. RAG는 연결된 DB에서 관련된 정보를 가져온 (Retrieve) 뒤에 그 결과를 바탕으로 Context를 보강 (Augment) 한다. 그리고 이를 바탕으로 LLM에게 질의를 하고 답변의 생성 (Generation)을 돕는다. 이를 통해서 AI가 흔히 '아는 척'이라고 불리는 환각 (Hallucnation)을 감소시킨다. 우리는 RAG를 통해서 각 회사에서 필요한 도메인 지식을 활용하도록 구축할 수 있다. 소스코드, 위키 문서, 그 외 기타 업무 히스토리와 데이터들을 연결할 수 있다. 그리고 지라 이슈 및 트렌드 등의 최신 정보를 반영하여 워크플로우의 최적화 및 개선에도 기여할 수 있다.
 

 

Vector DB

위에 얘기한 RAG에서 원하는 정보를 쉽고 정확하게 찾기 위해서, 텍스트/이미지/코드 등의 데이터를 인덱싱해야 한다. 기존의 관계형 DB에서 지원하는 데이터 구조와 쿼리로는 수행하기 힘든 역할이다. 왜냐면 기존의 관계형 DB는 데이터 간의 관계를 스키마로 정의하고 이에 맞혀서 각 데이터를 저장했다. 데이터의 관계와 키워드를 이용하여 데이터를 검색했다. 하지만 RAG에서 필요로 하는 데이터는 정확하게 어떤 데이터를 필요로 하는 것이 아니다. 내가 질문하고자 하는데 있어서 필요로 해 보이는 것들을 찾아야 한다. '필요로 해보이는 것'을 찾기 위해서는 기존의 키워드 기반 데이터의 매칭이 아니라, 데이터의 의미와 유사도 분석을 통해서 비슷해보이는 혹은 필요해보이는 것들을 찾아야 한다. 이를 위해서는 새로운 저장 방식과 새로운 검색 방식이 적용한 DB가 필요하다. Vector DB는 모든 데이터들은 숫자 벡터로 변환하여 저장한다. 이 숫자들의 배열 간의 거리를 계산해서 유사도를 분석하여 거리가 최대한 짧은, 즉 제일 유사도가 높은 결과 N개를 반환하도록 한다. 
 

Chroma	로컬 / 오픈소스	설정 간단, LangChain 친화적	대규모 데이터엔 부적합
FAISS	Meta 오픈소스	빠른 검색, 로컬 실행 가능	관리 도구/메타데이터 기능 약함
Pinecone	클라우드	빠르고 안정적, 완전관리형	유료, 쿼터 제한
Milvus	클라우드 + 온프레미스	고성능 분산 검색, 대용량 대응	설치/운영 복잡
Weaviate	오픈소스 + SaaS	Graph + Vector 혼합 검색 가능	리소스 요구 큼
Qdrant	오픈소스	Rust 기반 빠른 성능, REST/gRPC 지원	커뮤니티 중심 운영

 

Conclusion

AI는 지식에 대한 질의뿐만 아니라, 코드 생산과 업무 효율성을 위한 도구로서의 가치가 높아지고 있다. 물리적인 시간을 측정하기 위해서는 2개의 시점 혹은 사건이 필요하다고 한다. 2023년과 2025년이라는 2가지의 시점으로만 비교해 봐도 발전 속도는 충분히 빠르다. 앞으로는 등속이 아닌 등가속으로 발전이 빨라질 것으로, 혹은 그보다도 빠를 것으로 예상한다. 이를 활용하기 위해서 Model의 직접적인 활용을 위해서는 ML의 학습과 사용 방법에 주의를 기울여야 하고, LLM을 사용한 업무 프로세스 개선을 위해서는 LLM infrastructure의 구축과 활용에 주목해야 할 것이다.

이미 Amazon Bedrock이라는 제품도 등장했다. 그리고 굵직한 IT 회사들은 채용을 줄이고, LLM infrastructure를 구축하여 얼마나 적은 인력으로 기존 서비스의 운용이 지속되는가를 실험하고 있다. 개발자로서 당연히 신기술을 배우고 보다 효율적인 업무를 처리해야 한다고 생각한다. AI도 이러한 관점에서 배워야 하는 필수불가결한 요소라고 생각한다. 단지...... 10년 뒤에 개발자들은 어떤 일을 하고 있을지가 미지수일 뿐이다.