빈이의 AI이야기

개발을 하다 보면 터미널 환경을 벗어나지 않고 AI의 도움을 받아 코드를 작성하고 수정하고 싶을 때가 많다. 특히 프로젝트 규모가 커질수록 단순한 코드 자동완성보다는 기존 소스코드를 분석하고, 여러 파일을 수정하고, 오류 원인을 찾아 해결하는 AI 코딩 에이전트의 필요성이 커진다. 최근에는 IDE에 내장된 AI 기능뿐 아니라 터미널에서 직접 실행하는 AI 코딩 도구도 주목받고 있다. 그중 하나가 바로 오픈소스 AI 코딩 에이전트인 **OpenCode**다. OpenCode는 터미널(TUI), 데스크톱 앱, 웹 인터페이스 등 다양한 환경을 지원하며, Claude, GPT, Gemini 등 여러 AI 모델을 연결해 사용할 수 있다.  이번 글에서는 OpenCode의 개념부터 npm을 이용한 설치, Google AI Studio에서 Gemini 무료 API 키를 발급받는 방법, 그리고 OpenAI API 키를 발급받아 연결하는 과정까지 단계별로 살펴보겠다. 특히 하나의 AI 모델에 종속되지 않고 Gemini와 OpenAI를 필요에 따라 바꿔 사용할 수 있다는 점에 주목해 보자. 1. OpenCode란 무엇인가? OpenCode는 개발자가 터미널에서 AI와 대화하며 실제 프로젝트 코드를 분석하고 수정할 수 있도록 지원하는 오픈소스 AI 코딩 에이전트다. 일반적인 AI 챗봇은 개발자가 코드를 복사해서 질문하고, 답변으로 받은 코드를 다시 편집기에 붙여 넣는 방식으로 사용한다. 반면 OpenCode는 프로젝트 디렉터리에서 실행하면 현재 작업 중인 소스코드와 파일 구조를 파악하고, 사용자의 요청에 따라 파일을 읽거나 수정하는 작업을 수행할 수 있다. 예를 들어 다음과 같은 작업을 요청할 수 있다. 현재 프로젝트의 전체 디렉터리 구조와 주요 모듈 분석 특정 함수의 실행 흐름과 코드 동작 설명 반복되는 코드를 공통 함수로 리팩토링 컴파일 오류나 런타임 오류의 원인 분석 기존 코드 스타일을 유지하면서 새로운 기능 추가 테스트 코드 작성 및 ...

  AI 에이전트가 발전하면서 웹 브라우저를 활용하는 자동화 작업도 빠르게 늘어나고 있다. 웹사이트에서 정보를 수집하고, 로그인한 계정으로 데이터를 확인하고, 반복적인 웹 작업을 대신 수행하는 방식이다. 하지만 실제로 AI 에이전트에게 브라우저 작업을 맡겨 보면 생각보다 불편한 부분이 많다. 자동화 도구가 마우스와 화면을 직접 제어해 사람이 하던 작업을 방해하기도 하고, 별도의 브라우저 환경에서 실행되기 때문에 이미 로그인해 둔 웹사이트에 다시 접속해야 하는 경우도 있다. 이런 문제를 해결하기 위한 접근 방식 중 하나가 **ego lite(에고 라이트)**다. 사람과 AI 에이전트가 브라우저를 함께 사용하면서도 서로의 작업을 방해하지 않도록 설계된 Chromium 기반 브라우저 앱이다. 이번 글에서는 ego lite의 개념과 주요 기능, 기존 브라우저 자동화 도구와의 차이점, 실제 활용 시 고려해야 할 사항을 살펴본다. 1. ego lite란 무엇인가? ego lite는 사람과 AI 에이전트가 하나의 브라우저 환경에서 각자의 작업을 수행할 수 있도록 설계된 브라우저 앱이다. 기존 웹 자동화는 일반적으로 Playwright 같은 자동화 라이브러리를 이용하거나, 별도의 브라우저 인스턴스를 실행하는 방식으로 구현한다. 이러한 방식은 테스트 환경을 독립적으로 구성하기 좋지만, 사용자가 평소에 이용하는 브라우저 환경과 분리되는 경우가 많다. 예를 들어 사람이 이미 로그인한 웹사이트에서 AI 에이전트가 정보를 수집하도록 만들고 싶다고 가정해 보자. 별도의 브라우저 환경에서는 로그인 절차를 다시 처리해야 할 수 있고, 인증 과정이나 세션 유지 문제 때문에 자동화가 중단될 수도 있다. ego lite는 이러한 불편을 줄이기 위해 사람과 AI가 브라우저를 사용하는 방식을 새롭게 구성한다. 핵심은 단순히 AI가 웹페이지를 열고 클릭하도록 만드는 것이 아니다. 사람이 브라우저를 사용하는 동안에도 AI 에이전트가 별도의 작업 공간에서 웹 작업을 수행할 수 있도록 하는 것이다...

 LLM을 공부하다 보면 토큰(Token), 컨텍스트(Context), 컨텍스트 윈도우(Context Window)라는 용어를 자주 만나게 된다. 특히 ChatGPT나 Gemini 같은 생성형 AI를 사용하거나 RAG, AI Agent를 개발하려면 이 세 가지 개념을 이해하는 것이 중요하다. AI에게 긴 문서를 입력했는데 일부 내용을 놓치거나, 대화가 길어지면서 앞에서 이야기한 조건을 제대로 반영하지 못하는 이유는 무엇일까? 이 문제를 이해하려면 LLM이 정보를 처리하는 단위인 토큰과 한 번에 참고할 수 있는 정보의 범위인 컨텍스트 윈도우부터 살펴봐야 한다. 1. LLM의 Context Window란? Context Window(컨텍스트 윈도우)는 LLM이 한 번의 처리 과정에서 참고할 수 있는 정보의 최대 범위 를 의미한다. 일반적으로 토큰 개수로 표현하며, 모델마다 지원하는 크기가 다르다. 사람의 기억에 비유하면 컨텍스트 윈도우는 지금 대화하면서 머릿속에 펼쳐 놓고 참고할 수 있는 작업 공간과 비슷하다. 예를 들어 10페이지 분량의 문서를 읽고 질문에 답하는 상황을 생각해 보자. 문서 전체를 참고할 수 있는 모델이라면 여러 부분을 비교하면서 답변을 만들 수 있다. 반면 입력 가능한 범위를 초과한다면 문서를 나누거나, 중요한 내용을 요약하거나, 필요한 부분만 검색해서 전달하는 방법을 고려해야 한다. 컨텍스트 윈도우가 크면 긴 문서, 대규모 코드, 여러 차례의 대화 기록을 한 번에 처리하는 데 유리하다. 다만 컨텍스트 윈도우가 크다고 해서 모든 내용을 항상 완벽하게 기억하거나 정확하게 이해한다는 뜻은 아니다. 입력 가능한 용량과 실제 정보 검색 및 추론 능력은 구분해야 한다. 2. Token이란 무엇인가? 토큰(Token)은 LLM이 텍스트를 처리할 때 사용하는 기본 단위다. 사람이 읽는 단어와 토큰은 반드시 일치하지 않는다. 예를 들어 영어의 짧은 단어 하나가 토큰 하나로 처리될 수 있지만, 긴 단어나 특정 문자열은 여러 토큰으로 나뉠 수 있다. 한국...

 최근 AI 개발 분야에서는 LLM의 성능뿐 아니라 AI가 외부 시스템과 어떻게 연결되고 실제 작업을 수행하는지가 중요한 주제로 떠오르고 있습니다. 대규모 언어 모델(LLM)이 질문에 답하는 수준을 넘어 데이터베이스를 조회하고, 파일을 읽고, 개발 도구를 사용하며, 여러 시스템을 연결해 작업을 수행하는 구조가 주목받고 있기 때문입니다. 이 과정에서 자주 등장하는 기술이 바로 MCP(Model Context Protocol) 입니다. MCP는 AI 모델 자체를 더 똑똑하게 만드는 기술이라기보다, AI 애플리케이션이 외부 도구와 데이터에 접근하는 방식을 표준화하는 프로토콜입니다. 그렇다면 MCP는 기존의 API나 Function Calling과 무엇이 다를까요? 그리고 AI Agent 개발에서 MCP가 중요한 이유는 무엇일까요? 이번 글에서는 MCP의 기본 개념부터 아키텍처, 실제 작동 방식, 개발 시 고려해야 할 부분까지 살펴보겠습니다. 1. MCP란 무엇인가? MCP(Model Context Protocol)는 AI 애플리케이션이 외부 데이터 소스와 도구에 연결할 수 있도록 통신 방식을 표준화한 프로토콜입니다. Anthropic이 2024년 11월 공개했으며, 이후 다양한 AI 개발 도구와 애플리케이션에서 활용되고 있습니다. 쉽게 설명하면 MCP는 AI와 외부 시스템 사이에서 공통으로 사용하는 연결 규격입니다. 예를 들어 AI Agent가 다음과 같은 작업을 수행한다고 가정해 보겠습니다. 프로젝트 폴더에 있는 파일을 읽습니다. 데이터베이스에서 특정 정보를 조회합니다. GitHub에서 이슈 목록을 가져옵니다. 개발 환경에서 테스트 결과를 확인합니다. 외부 서비스의 기능을 호출합니다. 이러한 기능을 AI에 연결하려면 기존에는 서비스마다 API를 분석하고, 인증 방식을 구현하고, 도구의 입력과 출력을 처리하는 코드를 작성해야 했습니다. MCP는 이러한 연결 과정을 공통된 프로토콜로 다룰 수 있도록 설계되었습니다. 비유하자면 MCP는 다양한 주변기기를 연결할...

  최근 AI 기술을 이야기할 때 AI Agent(에이전트)​ 라는 단어를 자주 접하게 됩니다. ChatGPT와 같은 생성형 AI가 질문에 답하는 것을 넘어, 사용자의 목표를 이해하고 필요한 도구를 선택한 뒤 실제 작업까지 수행하는 방향으로 발전하면서 AI Agent에 대한 관심도 커지고 있습니다. 그렇다면 AI Agent는 기존의 LLM이나 챗봇과 무엇이 다를까요? 단순히 더 똑똑한 챗봇을 AI Agent라고 부르는 것은 아닙니다. 핵심적인 차이는 AI가 주어진 질문에 답하는 것을 넘어 목표를 달성하기 위한 여러 행동을 스스로 결정하고 실행할 수 있다는 점 에 있습니다. LLM은 무엇을 하는 기술일까? AI Agent를 이해하려면 먼저 LLM(Large Language Model)의 역할부터 살펴볼 필요가 있습니다. LLM은 방대한 텍스트 데이터를 학습하고 사용자가 입력한 프롬프트를 바탕으로 다음에 올 내용을 예측하면서 자연어 형태의 답변을 생성합니다. 예를 들어 사용자가 다음과 같이 질문한다고 생각해 보겠습니다. "인공지능 에이전트가 무엇인지 설명해줘." LLM은 학습한 지식을 바탕으로 이에 적절한 설명을 생성합니다. 즉, 기본적인 LLM의 역할은 입력된 정보와 컨텍스트를 바탕으로 적절한 출력을 생성하는 것 이라고 볼 수 있습니다. 물론 최신 LLM은 단순한 텍스트 생성 이상의 기능을 제공합니다. 이미지 이해, 코드 작성, 구조화된 출력, Tool Calling 등 다양한 기능이 추가되면서 LLM의 활용 범위도 크게 확장되고 있습니다. 하지만 LLM 자체가 사용자의 컴퓨터에서 파일을 찾거나 외부 API를 호출하고, 그 결과를 다시 분석해 다음 행동을 결정하는 것은 별도의 시스템 설계가 필요한 영역입니다. 챗봇과 AI Agent의 차이 기존의 챗봇은 일반적으로 사용자와 질문과 답변을 주고받는 구조입니다. 예를 들어 고객이 "주문한 상품이 언제 도착하나요?" 라고 질문하면 챗봇이 주문 정보를 조회하고 배송 예정일을 알려주는 ...

 ChatGPT와 같은 생성형 AI를 공부하다 보면 Embedding(임베딩)​ 이라는 용어를 자주 만나게 됩니다. 특히 RAG(Retrieval-Augmented Generation), 벡터 데이터베이스, 의미 기반 검색, 추천 시스템 등을 이해하려면 Embedding의 개념을 알아두는 것이 중요합니다. 그런데 Embedding을 처음 접하면 한 가지 의문이 생깁니다. AI는 도대체 어떻게 텍스트의 '의미'를 숫자로 표현할 수 있을까요? 핵심은 텍스트를 고차원 벡터 공간의 좌표로 변환하는 것 입니다. 이번 글에서는 Embedding이 무엇인지, 문장이 어떻게 숫자 벡터로 변환되는지, 그리고 이 벡터가 RAG와 같은 AI 시스템에서 어떻게 활용되는지 살펴보겠습니다. 1. Embedding이란 무엇인가? Embedding은 텍스트, 이미지, 음성 등의 데이터를 고정된 길이의 숫자 벡터로 변환하는 기술 입니다. 예를 들어 다음과 같은 문장이 있다고 해보겠습니다. "오늘 날씨가 정말 좋습니다." "오늘은 햇빛이 따뜻하고 하늘이 맑습니다." "반도체 시장의 전망이 밝습니다." 사람이 보면 첫 번째와 두 번째 문장은 서로 비슷한 의미라는 것을 쉽게 알 수 있습니다. 하지만 컴퓨터에게 문자열은 기본적으로 문자들의 집합일 뿐입니다. Embedding 모델은 이런 텍스트를 입력받아 다음과 같이 숫자로 표현할 수 있습니다. "오늘 날씨가 정말 좋습니다." ↓ Embedding Model ↓ [0.021, -0.184, 0.731, 0.092, ...] 실제 벡터는 수백~수천 개의 숫자로 구성될 수 있습니다. 중요한 것은 단순히 문장을 숫자로 바꾸는 것이 아닙니다. 의미가 비슷한 텍스트가 벡터 공간에서도 가까운 위치에 있도록 만드는 것 이 Embedding의 핵심입니다. 2. 왜 굳이 텍스트를 벡터로 바꿀까요? 컴퓨터는 숫자를 이용하면 데이터를 비교하고 계산하기가 ...

  최근 생성형 AI 서비스를 개발하다 보면 LLM(Large Language Model)만으로는 해결하기 어려운 문제가 있다는 것을 쉽게 발견하게 됩니다. LLM은 방대한 데이터를 학습하고 자연스러운 문장을 생성할 수 있지만, 학습 이후 새롭게 생성된 정보나 특정 조직 내부의 데이터를 알지 못한다는 한계 가 있습니다. 또한 질문에 대한 답을 생성하는 과정에서 실제 근거가 없는 내용을 사실처럼 만들어내는 이른바 ‘환각(Hallucination)’ 문제도 발생할 수 있습니다. 이러한 LLM의 한계를 보완하기 위해 등장한 대표적인 기술이 바로 RAG(Retrieval-Augmented Generation) 입니다. RAG는 우리말로 검색 증강 생성 이라고 부릅니다. 말 그대로 사용자의 질문과 관련된 외부 정보를 먼저 검색하고, 검색된 정보를 LLM에게 제공한 뒤 답변을 생성하도록 만드는 구조입니다. 단순히 LLM에게 질문하는 것이 아니라, 질문 → 관련 정보 검색 → 검색 결과를 LLM에 전달 → 답변 생성 이라는 과정을 추가하는 것이 핵심입니다. LLM만으로는 왜 부족할까? LLM은 기본적으로 학습된 데이터를 기반으로 답변을 생성합니다. 예를 들어 2026년에 새롭게 공개된 특정 기업의 보고서나 사내 업무 문서가 LLM의 학습 데이터에 포함되어 있지 않다면, 해당 내용을 정확하게 알고 있다고 기대하기 어렵습니다. 또 다른 문제는 기업이나 조직에서 사용하는 비공개 데이터 입니다. 회사 내부의 기술 문서, 고객 데이터, 제품 매뉴얼, 업무 규정, 프로젝트 문서 등은 일반적인 LLM 학습 데이터에 포함되어 있지 않습니다. 그렇다면 LLM에 이 데이터를 모두 학습시키면 해결할 수 있을까요? 실제로는 그렇게 단순하지 않습니다. 새로운 데이터가 추가될 때마다 모델을 다시 학습시키는 것은 비용과 시간이 많이 필요하고, 데이터가 자주 변경되는 환경에서는 적합하지 않습니다. 여기서 RAG의 개념이 등장합니다. LLM 자체를 다시 학습시키는 대신 필요한 순간에 외부 데이터...