AI 트렌드를 따라가려면 무엇을 공부해야 할까?

About this offer

요즘 AI를 공부하면서 가장 어려운 것은 기술 자체보다도 무엇을 공부해야 하는지 결정하는 것 인 것 같다. 하루가 멀다 하고 새로운 모델이 나오고, Claude, GPT, Gemini, Qwen 같은 모델뿐만 아니라 Agent, MCP, RAG, Computer Use, Local LLM, Multimodal, Vibe Coding 같은 새로운 키워드가 계속 등장한다. 처음에는 새로운 모델이 나오면 설치해보고, 새로운 AI 서비스가 나오면 사용해보는 것이 AI 트렌드를 따라가는 것이라고 생각했다. 그런데 최근 직접 여러 가지를 만들어보면서 생각이 조금 달라졌다. 중요한 것은 새로운 AI를 얼마나 많이 알고 있느냐가 아니라, AI를 실제 시스템에 어떻게 연결할 수 있느냐는 것 아닐까? 그래서 앞으로 어떤 방향으로 AI를 공부할지 한번 정리해보려고 한다. 나는 지금 어느 정도일까? 나는 토목공학과 컴퓨터공학을 함께 공부했고 현재는 웹 개발을 하면서 스마트건설 관제 시스템을 개발하고 있다. AI와 관련해서도 조금씩 여러 가지를 시도해봤다. Claude API를 이용해 수학 문제를 분석하고 풀이와 채점을 생성하는 시스템을 만들어보기도 했고, Mathpix OCR과 LLM을 연결해서 이미지에서 수식을 추출하고 문제 데이터를 만드는 파이프라인도 구현해봤다. 최근에는 Ollama와 Qwen을 이용해서 Local LLM 환경을 구축하고, OpenClaw를 연결해 AI가 브라우저를 직접 조작하도록 테스트하고 있다. 실제로 사용자 명령 ↓ OpenClaw ↓ Local Qwen ↓ Browser ↓ Velog 게시글 작성 같은 자동화도 실험하고 있다. 여기까지 해보면서 느낀 것은 내가 아직 AI 모델 자체를 연구하는 사람은 아니지만, AI를 기존 서비스와 연결해서 실제 기능으로 만드는 쪽에 점점 가까워지고 있다는 것 이다. 그리고 앞으로도 이 방향으로 공부하는 것이 나에게 가장 잘 맞는다고 생각한다. AI 공부도 단계가 있다고 생각한다 개인적으로 AI 활용 수준을 대략 이렇게 나눠볼 수 있을 것 같다. 단계 AI 활용 방식 1. 소비자 ChatGPT, Claude 등을 사용한다 2. 활용자 코딩, 문서 작성, 분석 등 업무에 적극 사용한다 3. 적용자 API를 이용해 서비스에 AI 기능을 붙인다 4. 설계자 Agent와 Tool을 조합해 AI가 일을 수행하도록 만든다 5. 운영자 성능, 비용, 평가, 보안까지 관리한다 지금의 나는 개인적으로 3단계 후반에서 4단계로 넘어가는 과정 이라고 생각한다. 단순히 ChatGPT를 잘 사용하는 것을 넘어 API와 Local LLM을 사용해봤고, 이제는 Agent가 여러 도구를 사용해서 실제 작업을 수행하도록 만드는 것에 관심을 가지고 있기 때문이다. 그래서 지금부터의 공부 방향도 여기에 맞춰야 한다고 생각한다. 1. 가장 먼저 공부할 것: Agent 내가 가장 먼저 제대로 공부하려는 분야는 AI Agent 다. 기존 LLM 서비스는 기본적으로 이런 구조였다. 사용자 ↓ LLM ↓ 답변 하지만 최근 AI 시스템은 점점 이런 방향으로 발전하고 있다. 사용자 목표 ↓ Agent ↓ 상황 판단 ↓ 필요한 Tool 선택 ↓ Tool 실행 ↓ 결과 확인 ↓ 다음 행동 결정 ↓ 작업 완료 OpenAI 역시 2026년 9월 Agents API를 공개하면서 장시간 작업, Tool 사용, Context 관리, Subagent 협업 등을 Agent 시스템의 핵심 요소로 두고 있다. Agents SDK 역시 Agent loop, handoff, tool integration, state, observability 등을 애플리케이션에서 직접 제어하는 구조로 제공되고 있다. 즉 이제는 “좋은 답변을 생성하는 AI” 뿐만 아니라 “목표를 주면 필요한 작업을 수행하는 AI” 를 공부해야 한다. 내가 공부해야 할 핵심도 프레임워크 사용법보다 Agent의 기본 구조라고 생각한다. Prompt ↓ Reasoning ↓ Tool Selection ↓ Tool Calling ↓ Execution ↓ Observation ↓ Next Action 여기에 Context 관리, Memory, 승인 과정, 실패 처리, 재시도 같은 개념들이 붙는다. 2. Tool Calling을 제대로 이해하기 Agent를 공부하려면 결국 Tool Calling 을 이해해야 한다. 예를 들어 AI에게 현재 현장에서 위험한 구역을 찾아줘. 라고 요청했다고 생각해보자. AI가 직접 센서 데이터를 알고 있는 것은 아니다. 대신 이런 Tool을 사용할 수 있다. get_sensor_data() get_cctv_events() get_worker_location() get_weather() get_equipment_status() Agent는 질문을 분석하고 필요한 Tool을 결정한다. 현재 위험한 구역을 찾아줘 ↓ 센서 데이터 필요 ↓ get_sensor_data() ↓ CCTV 이벤트 필요 ↓ get_cctv_events() ↓ 작업자 위치 필요 ↓ get_worker_location() ↓ 결과 종합 이 구조를 제대로 이해하면 LangChain이나 CrewAI 같은 특정 프레임워크를 몰라도 Agent가 어떻게 동작하는지 이해할 수 있다. 그래서 앞으로는 라이브러리 사용법보다 먼저 Tool Schema, Structured Output, Agent Loop, Context 관리 부터 공부하려고 한다. 3. MCP 다음으로 공부하려는 것은 MCP(Model Context Protocol)다. MCP는 2024년 Anthropic이 공개한, AI 애플리케이션과 외부 데이터 및 도구를 연결하기 위한 오픈 프로토콜이다. 처음에는 Claude 중심의 기술처럼 보였지만 이후 생태계가 크게 확장되었고, 현재는 Agent가 외부 시스템과 연결되는 중요한 인터페이스 중 하나로 발전하고 있다. MCP를 이해하기 쉽게 표현하면 AI ↓ MCP ↓ 외부 시스템 이다. 예를 들어 스마트건설 관제 시스템용 MCP Server를 만든다고 생각해보자. construction-mcp getSensorData getCctvEvents getWorkerLocation getWeather getEquipmentStatus getAlarmHistory 이렇게 만들어두면 MCP를 지원하는 Agent가 이 기능들을 사용할 수 있다. 내 입장에서는 이것이 꽤 재미있는 주제다. 현재 개발하고 있는 스마트건설 관제 시스템 자체가 센서, CCTV, 작업자, 장비, 기상 데이터처럼 다양한 데이터를 가지고 있기 때문이다. 기존에는 사람이 대시보드를 열어 데이터를 하나씩 확인했다면, 앞으로는 Agent에게 지금 현장에서 확인해야 할 위험 요소 알려줘. 라고 요청하는 방식으로 바뀔 수도 있다. 그리고 MCP도 계속 발전하고 있다. 2026년 7월 공개된 MCP 규격에서는 stateless 구조, 장시간 작업을 위한 Tasks 확장, MCP Apps, 인증 구조 개선 등이 포함됐다. 단순히 로컬 Tool 몇 개를 연결하는 규격에서 실제 Agent 인프라에 가까운 방향으로 발전하고 있다는 점이 흥미롭다. 4. RAG는 여전히 중요하다 Agent가 행동을 담당한다면 RAG는 지식을 가져오는 역할 을 담당한다고 볼 수 있다. 단순하게 생각하면 질문 ↓ 관련 문서 검색 ↓ 필요한 내용 추출 ↓ LLM에게 전달 ↓ 답변 구조다. 하지만 실제로 사용하려면 단순히 PDF → Embedding → Vector DB → GPT 정도에서 끝나서는 안 된다고 생각한다. 앞으로 공부하면서 Document ↓ Chunking ↓ Embedding ↓ Vector Search ↓ Keyword Search ↓ Hybrid Search ↓ Reranking ↓ Context ↓ LLM 과정을 직접 만들어보고 싶다. 특히 스마트건설과 결합하면 활용할 데이터가 많다. 예를 들어 안전관리 매뉴얼, 시공 지침, 장비 매뉴얼, 센서 설명서, 현장 보고서 같은 문서를 검색하도록 만들 수 있다. 그러면 Agent에게 현재 CO 센서 농도가 평소보다 높아졌는데 어떤 조치를 해야 하지? 라고 질문했을 때 실시간 Sensor Data + 안전관리 문서 RAG ↓ Agent 구조로 답변을 만들 수 있다. 이때 답만 생성하는 것이 아니라 어떤 센서 데이터와 어떤 문서를 근거로 판단했는지 함께 보여주는 것 까지 구현해보고 싶다. 5. Eval을 공부해야 하는 이유 최근 AI 개발을 해보면서 가장 부족하다고 느끼는 부분이 이것이다. 보통 기능을 만들고 나면 몇 번 테스트해봤는데 잘 되네. 하고 끝내기 쉽다. 하지만 실제 서비스라면 그것으로 부족하다. 예를 들어 Agent에게 100개의 테스트 상황을 주고 올바른 Tool을 선택했는가? 필요한 Tool을 빠뜨리지 않았는가? 잘못된 정보를 만들지는 않았는가? RAG에서 올바른 문서를 검색했는가? 응답시간은 얼마나 걸렸는가? 비용은 얼마나 발생했는가? 를 측정해야 한다. OpenAI의 현재 Agent 개발 문서에서도 tracing과 observability, evaluation을 Agent workflow 개선 과정의 중요한 요소로 다루고 있다. 결국 AI 시스템을 만드는 것과 신뢰할 수 있는 AI 시스템을 만드는 것 은 다른 문제다. 앞으로는 AI 기능 하나를 만들더라도 테스트 Dataset을 같이 만들어보려고 한다. 6. Multimodal AI 내가 특히 관심을 가지는 부분이다. 스마트건설에서는 텍스트보다 이미지와 영상 데이터가 굉장히 많다. 현재도 CCTV 영상과 실시간 스트리밍 데이터를 다루고 있기 때문에 Vision AI와 연결하기 좋은 환경이다. 예를 들어 이런 구조를 만들 수 있다. CCTV ↓ Vision Model ↓ 작업자 / 장비 / 위험상황 분석 ↓ ┌─ Sensor Data │ ├─ Worker Data │ ├─ Weather Data │ ▼ Agent ↓ 위험 상황 판단 여기까지 가면 AI는 단순히 챗봇이 아니다. 실제 현장의 다양한 데이터를 종합하는 인터페이스 가 된다. 토목공학과 컴퓨터공학을 같이 공부한 내 배경도 이 부분에서 꽤 재미있게 활용할 수 있을 것 같다. 7. Local LLM도 계속 공부한다 최근 Ollama와 Qwen을 사용하면서 Local LLM도 계속 테스트하고 있다. 처음에는 단순히 ollama run qwen 정도로 모델을 실행하는 것이 신기했다. 하지만 앞으로는 실행 자체보다 어떻게 효율적으로 모델을 운영할 것인가 를 공부해야 한다고 생각한다. 특히 Model Size Quantization VRAM Context Length Tokens/sec Embedding GPU Inference vLLM GGUF 같은 개념을 더 공부하고 싶다. vLLM 같은 추론 서버는 현재 다양한 Quantization 방식과 OpenAI 호환 API 기반 서빙 등을 지원하기 때문에 Local AI를 서비스 관점에서 공부할 때 좋은 실습 대상이라고 생각한다. Quantization은 모델의 메모리 사용량을 줄여 더 다양한 하드웨어에서 모델을 실행할 수 있도록 하는 대표적인 최적화 방법이다. 특히 건설현장에서는 인터넷 연결이나 데이터 보안 문제도 발생할 수 있기 때문에 Local AI와 Cloud AI를 조합하는 구조도 생각해볼 수 있다. 일반적인 AI 작업 ↓ Cloud LLM 민감한 현장 데이터 ↓ Local LLM 복잡한 판단 ↓ Cloud / Local 선택 이런 Hybrid AI Architecture도 한번 직접 구현해보고 싶다. 그런데 모든 AI 프레임워크를 공부할 필요는 없다 AI를 공부하다 보면 끝이 없다. LangChain이 보이면 LangChain을 공부하고, LangGraph가 나오면 LangGraph를 공부하고, CrewAI가 나오면 CrewAI를 공부하고, n8n이 유행하면 n8n을 공부하고, OpenClaw가 나오면 OpenClaw를 공부하게 된다. 그런데 이렇게 공부하면 계속 새로운 도구만 따라가게 된다. 실제로 AI 개발 도구 자체의 변화 속도도 빠르다. 예를 들어 OpenAI는 2026년 Agent Builder와 기존 Evals 플랫폼의 종료 계획을 발표했고, Agent 개발은 Agents SDK 등의 코드 기반 도구로 이동시키고 있다. 그래서 특정 프레임워크를 외우기보다 Tool Calling Agent Loop Context MCP Retrieval Evaluation Observability Local Inference 같은 변하지 않는 구조를 먼저 이해하는 것이 더 중요하다 고 생각한다. 프레임워크는 그다음이다. 그래서 나는 무엇을 만들 것인가? 공부를 위해 새로운 토이 프로젝트를 계속 만드는 것보다 지금까지 해왔던 것들을 하나로 연결해보려고 한다. 가칭 Smart Construction AI Copilot 이다. 전체 구조는 대략 이렇게 생각하고 있다. User │ ▼ Next.js Dashboard │ ▼ AI Copilot │ ▼ Agent ┌─────────────┼─────────────┐ │ │ │ Sensor Tool CCTV Tool Weather Tool │ │ │ Worker Tool Equipment Tool Document RAG │ │ │ └─────────────┼─────────────┘ │ ▼ MCP Server │ ┌─────────┴─────────┐ │ │ PostgreSQL API 사용자는 단순하게 질문한다. 현재 현장에서 가장 위험한 구역을 알려줘. 그러면 Agent가 필요에 따라 센서 데이터 확인 ↓ CCTV 이벤트 확인 ↓ 작업자 위치 확인 ↓ 기상 데이터 확인 ↓ 안전관리 문서 검색 ↓ 위험 요소 분석 ↓ 근거와 함께 결과 제공 을 수행한다. 예를 들면 결과가 이렇게 나올 수도 있다. A터널 3구간 주의 - CO 농도 지속 상승 - 현재 작업자 4명 위치 - 최근 10분간 센서 값 증가 - CCTV에서 작업 진행 확인 권장 조치: 작업자에게 현장 상황 확인 요청 근거: Sensor #CO-03 CCTV #TUNNEL-02 안전관리 매뉴얼 3.2절 물론 실제 안전 판단을 AI에게 전적으로 맡길 수는 없다. 그래서 이런 시스템에서 더욱 중요한 것이 근거 데이터, 불확실성 표시, 사람의 최종 확인, Tool 권한 관리 라고 생각한다. 이 부분까지 포함해야 실제 사용 가능한 AI 시스템에 가까워진다. 앞으로의 공부 순서 현재 내 기준으로는 이렇게 공부하려고 한다. Tool Calling → Agent → MCP → RAG → Eval & Observability → Multimodal → Local AI → 실제 서비스 통합 그리고 각 개념을 따로 공부하는 것에서 끝내지 않고 Smart Construction AI Copilot이라는 하나의 프로젝트에 계속 붙여볼 생각이다. Agent를 공부하면 Sensor Tool을 만든다. MCP를 공부하면 Construction MCP Server를 만든다. RAG를 공부하면 안전관리 문서를 연결한다. Multimodal을 공부하면 CCTV를 연결한다. Local LLM을 공부하면 Qwen을 붙인다. Eval을 공부하면 위험 상황 테스트 Dataset을 만든다. 이런 방식이면 공부한 결과가 그대로 하나의 시스템에 쌓인다. 마무리 AI 트렌드를 따라간다는 것은 모든 신제품의 이름을 알고 있는 것이 아닐지도 모른다. GPT의 다음 버전이 무엇인지, Claude의 최신 모델이 무엇인지, 어떤 Agent 프레임워크가 GitHub Star를 가장 많이 받았는지를 빠르게 아는 것도 물론 재미있다. 하지만 개발자로서 더 중요한 것은 결국 AI가 어떤 방향으로 발전하고 있고, 그 기술을 내가 만드는 시스템에 어떻게 적용할 것인가 라고 생각한다. 지금까지는 AI에게 "이거 해줘" 라고 질문하는 방법을 배웠다면, 앞으로는 "이 목표를 달성해줘" 라고 요청했을 때 AI가 필요한 정보를 찾고, 도구를 선택하고, 실행하고, 결과를 검증하는 시스템을 공부해보고 싶다. 그래서 앞으로 당분간 나의 AI 공부 키워드는 Agent, Tool Calling, MCP, RAG, Eval, Multimodal, Local AI 가 될 것 같다. 그리고 최종 목표는 단순히 AI 기술을 많이 아는 개발자가 아니라, 토목 도메인과 웹 개발, 실시간 관제 데이터, AI를 하나의 시스템 안에서 연결할 수 있는 개발자 가 되는 것이다. 이 블로그에도 앞으로 하나씩 직접 구현하면서 그 과정을 기록해보려고 한다.