처음 만나는 AI 용어 12가지 정리

AI 이야기를 듣다 보면 익숙하지 않은 용어가 계속 나옵니다. LLM, RAG, MCP, 에이전트 같은 단어는 이제 기사나 서비스 소개에서도 자주 보이지만, 처음 접하면 서로 어떻게 다른지 헷갈리기 쉽습니다. 이 글에서는 AI를 이해할 때 자주 만나는 용어 12가지를 최대한 쉬운 말로 정리해보겠습니다. 깊은 기술 설명보다는, 각 용어가 어떤 역할을 하는지 큰 그림을 잡는 데 초점을 맞췄습니다. 1. LLM: AI의 기본 두뇌 LLM은 Large Language Model의 줄임말입니다. 한국어로는 거대 언어 모델이라고 부릅니다. 쉽게 말하면, 엄청난 양의 글을 학습해서 사람의 언어를 이해하고 이어서 답변할 수 있도록 만들어진 AI 모델입니다. 우리가 ChatGPT 같은 서비스에 질문했을 때 문장을 읽고 ..

Unity 7 발표를 보며 생각한 개발 환경의 변화

Unity 7 발표 내용을 보면서 가장 먼저 눈에 들어온 것은 화려한 그래픽 기능보다 개발 흐름의 변화였습니다. 물론 실시간 글로벌 일루미네이션이나 셰이더 빌드 속도 향상도 중요한 변화입니다. 하지만 개인적으로 더 오래 남을 것 같다고 느낀 부분은, 개발자가 에디터 안에서만 작업하는 시대가 조금씩 바뀌고 있다는 점이었습니다. Unity는 Unity 7을 소개하면서 CoreCLR 기반의 더 빠른 개발 사이클, 거의 즉각적인 플레이 모드 진입, 변경된 코드만 다시 읽어들이는 도메인 리로드, 최대 90% 빠른 셰이더 빌드, Surface Cache GI를 통한 실시간 글로벌 일루미네이션 등을 언급했습니다. 또한 무료로 사용할 수 있는 MCP를 통해 Claude나 Codex 같은 코딩 에이전트가 Unity와 직..

서비스를 만들다 보면 로그를 먼저 생각하게 됩니다. 문제가 생겼을 때 원인을 찾아야 하고, 어떤 요청에서 실패했는지 확인해야 하기 때문입니다. 저도 닷넷 프로젝트를 만들 때 Serilog 같은 구조화 로깅 도구를 자주 떠올립니다. 하지만 로그를 남기기 시작하면 곧 다른 질문이 생깁니다. 로그는 문제가 생긴 뒤에 뒤져보는 기록에 가깝습니다. 그렇다면 지금 서비스가 어떤 상태인지, 오늘 어떤 일이 있었는지, 사용자가 실제로 어떤 흐름을 지나고 있는지는 어디에서 봐야 할까요. 이 지점에서 작은 대시보드나 상태 확인 화면이 필요해집니다. 거창한 분석 시스템이 아니라, 운영자가 매일 한 번쯤 열어보고 서비스의 현재 상태를 감각할 수 있는 화면입니다. 혼자 운영하는 서비스일수록 이런 화면이 생각보다 중요합니다. 로..

프론트엔드를 리액트로 만들다 보면 어느 순간 인증 처리를 어디까지 맡겨야 하는지 고민하게 됩니다. 화면을 그리는 일은 리액트가 잘합니다. 상태를 다루고, 컴포넌트를 나누고, 사용자와 빠르게 상호작용하는 것도 리액트의 장점입니다. 하지만 인증은 조금 다릅니다. 토큰을 어디에 저장할지, 쿠키는 어떻게 다룰지, API 호출 권한은 어디서 확인할지, 새로고침 후 세션은 어떻게 유지할지 같은 문제들이 따라옵니다. 처음에는 단순해 보이지만, 실제 서비스를 운영하려고 하면 생각보다 신경 쓸 부분이 많아집니다. 그래서 요즘 다시 관심을 두고 있는 구조가 BFF입니다. Backend for Frontend의 줄임말인데, 이름 그대로 프론트엔드를 위한 백엔드 계층을 하나 두는 방식입니다. 저는 이 구조를 “서버사이드가 프..

이 글은 2026년 7월 7일 기준으로 정리한 기록입니다. .NET 11은 아직 프리뷰 단계에 있고, 현재 공개 자료 기준으로는 Preview 5까지 나와 있습니다. 정식 릴리스는 2026년 11월로 안내되어 있으니, 지금 보이는 기능들이 모두 그대로 고정된다고 보기는 어렵습니다. 그래도 프리뷰를 살펴보는 일은 의미가 있습니다. 당장 운영 중인 서비스를 옮기기 위해서라기보다, 앞으로 닷넷 생태계가 어떤 방향으로 움직이는지 미리 감을 잡을 수 있기 때문입니다. 저는 21년차 닷넷 개발자로 일하면서, 요즘은 웹소설 집필 보조 서비스 메리톡톡을 만들고 운영하는 흐름도 함께 고민하고 있습니다. 그래서 새 버전을 볼 때도 “멋진 기능이 나왔는가”보다 “혼자 오래 운영하는 서비스에 어떤 영향을 줄까”를 먼저 보게 ..

작은 서비스를 만들 때 처음부터 관리자 화면을 신경 쓰는 일은 조금 과해 보일 수 있습니다. 사용자에게 보이는 기능도 아직 충분하지 않은데, 운영자만 보는 화면을 먼저 만든다는 것이 뒤로 미뤄도 되는 일처럼 느껴지기 때문입니다.저도 예전에는 비슷하게 생각했습니다. 우선 사용자가 보는 화면을 만들고, 데이터가 쌓이면 그때 관리자 기능을 붙이면 된다고 봤습니다. 하지만 혼자 서비스를 만들고 운영하는 시간이 길어질수록, 관리자 화면은 나중에 붙이는 부가 기능이 아니라 서비스를 오래 붙잡기 위한 기본 도구에 가깝다는 생각을 하게 됩니다.특히 메리톡톡처럼 창작자의 흐름을 돕는 서비스를 만들 때는 더 그렇습니다. 사용자가 어떤 지점에서 막히는지, 어떤 데이터가 쌓이고 있는지, 문제가 생겼을 때 어디를 먼저 봐야 하..

닷넷 프로젝트에서 Serilog를 자주 쓰는 이유 닷넷 프로젝트를 만들다 보면 로깅 도구를 고르는 순간이 자주 옵니다. 작은 기능을 만들 때는 Console.WriteLine만으로도 충분해 보이지만, 서비스가 실제로 운영되기 시작하면 이야기가 달라집니다. 문제가 생겼을 때 “어디에서”, “어떤 값으로”, “누가”, “얼마나 자주” 발생했는지 확인할 수 있어야 하기 때문입니다. 저는 닷넷으로 서비스를 만들고 운영하면서 Serilog를 자주 사용합니다. 대단히 특별한 이유라기보다, 혼자서도 상황을 추적하고 정리하기에 현실적인 도구라고 느껴왔기 때문입니다. 로그는 개발 중 확인용 메시지가 아니라, 운영 중인 서비스를 이해하기 위한 기록에 가깝습니다. 그런 관점에서 Serilog는 꽤 오랫동안 손에 익은 선택지..

서비스를 만들다 보면 로그인보다 더 오래 고민하게 되는 부분이 있습니다. 바로 “이 사용자가 어디까지 할 수 있는가”를 판단하는 일입니다. 처음에는 닷넷 코드 안에 Admin, Manager, User 같은 역할을 기준으로 조건문을 넣으면 충분해 보입니다. 하지만 서비스가 조금씩 커지고, 조직이나 기능 단위의 규칙이 늘어나면 접근 제어는 금방 복잡해집니다. 저는 이 문제를 보면서 인증과 인가를 조금 더 분리해서 생각해보고 싶었습니다. 사용자가 누구인지 확인하는 일은 OIDC가 맡고, 그 사용자가 특정 자원에 접근할 수 있는지 판단하는 일은 OPA가 맡는 구조입니다. 닷넷 애플리케이션은 두 세계를 연결하는 얇은 통로가 됩니다. OIDC는 사용자가 누구인지 확인합니다 OIDC, 즉 OpenID Connect..

닷넷 어스파이어를 다시 살펴보게 된 이유 요즘 애플리케이션은 예전처럼 하나의 프로젝트만 실행해서 끝나는 경우가 점점 줄어들고 있습니다. API 서버가 있고, 프론트엔드가 있고, 데이터베이스와 Redis 같은 외부 서비스가 붙습니다. 여기에 로그, 설정, 배포 환경까지 생각하면 작은 서비스도 금방 여러 조각으로 나뉩니다. 닷넷 어스파이어는 이런 분산 애플리케이션을 개발할 때 필요한 실행, 연결, 관찰 흐름을 한곳에서 정리해주는 도구입니다. Microsoft 문서에서는 Aspire를 여러 언어를 지원하는 로컬 개발 시점의 오케스트레이션 도구 체인으로 설명하고 있습니다. 단순히 닷넷 프로젝트를 하나 더 만드는 도구라기보다, 여러 구성 요소를 함께 실행하고 살펴보기 위한 작업 환경에 가깝습니다. 혼자 만드는 서..

React로 화면을 만들다 보면 생각보다 많은 시간이 API 데이터를 다루는 데 쓰입니다. 데이터를 불러오고, 로딩 상태를 표시하고, 실패했을 때의 처리를 만들고, 다시 새로고침해야 하는 시점을 고민합니다. 처음에는 단순한 fetch 코드로 충분해 보이지만, 화면이 늘어나면 이 흐름이 금방 복잡해집니다. TanStack Query, 예전 이름으로 React Query는 이 문제를 꽤 잘 정리해주는 도구입니다. React 애플리케이션에서 비동기 데이터, 특히 서버에서 가져오는 데이터를 가져오고, 캐싱하고, 동기화하고, 업데이트하는 일을 도와줍니다. 클라이언트 상태와 서버 상태는 다릅니다 React에서 상태라고 하면 보통 useState나 Zustand 같은 상태 관리 도구를 떠올립니다. 하지만 서버에서 가..