메로그

AI 모델을 더 똑똑하게 만들기 위해선, 두 가지 방법이 자주 언급된다.바로 MCP (Model Context Protocol) 와 RAG (Retrieval-Augmented Generation) 이다.둘은 서로 다른 목적과 방식으로 AI의 한계를 극복하며, 실무에선 함께 사용되기도 한다.이 글에서는 MCP와 RAG가 무엇인지, 어떻게 다르고, 언제 어떤 방식을 써야 하는지 정리해본다.MCP (Model Context Protocol)개념MCP는 AI 모델이 실시간으로 외부 시스템과 상호작용할 수 있도록 설계된 프로토콜이다.모델이 스스로 필요하다고 판단하면 외부 API, 데이터베이스, 파일 시스템 등을 호출해 직접 작업을 수행한다.즉, "AI가 도구를 써서 일까지 하는 구조" 다.구조AI 모델 ↔ MC..

AI 기술이 급속도로 발전하면서 다양한 AI 모델들이 등장하고 있습니다. 각각의 모델은 고유한 특성과 강점을 가지고 있어, 사용 목적에 따라 최적의 선택이 달라집니다. 오늘은 현재 가장 주목받고 있는 AI 모델들의 특징을 자세히 살펴보고, 어떤 상황에서 어떤 모델을 선택해야 하는지 알아보겠습니다.ChatGPT (GPT-4/4o): 만능 AI의 대명사OpenAI의 ChatGPT는 현재 가장 널리 알려진 AI 모델 중 하나입니다. GPT-4와 최신 GPT-4o 모델의 가장 큰 장점은 멀티모달 지원입니다. 텍스트는 물론 이미지, 음성, 심지어 비디오까지 처리할 수 있어 다양한 형태의 입력을 통한 상호작용이 가능합니다.주요 강점자연스럽고 유창한 대화 능력창의적 글쓰기와 스토리텔링에 탁월광범위한 지식 베이스와 다..

클라이언트에서 엑셀 다운로드? 이 모듈 하나면 충분합니다 – client-excel-module 소개프론트엔드를 하다 보면 엑셀 다운로드 기능은 정말 자주 등장하는 요구사항 중 하나입니다.특히 관리자 페이지나 통계 페이지를 만들다 보면 엑셀로 내보내기는 거의 필수죠.보통은 Java + POI 조합?백엔드가 Java라면 대부분 Apache POI를 사용해서 엑셀을 생성합니다. 강력하긴 하지만…설정 복잡하고,러닝 커브도 제법 있고,결국 서버 API를 만들어야 하니 관리 포인트가 늘어나고…이런 경험, 다들 한 번쯤 해봤을 거예요. 특히 작은 기능을 위해 백엔드까지 건드리는 건 꽤 비효율적이죠.클라이언트에서 바로 엑셀을?그래서 프론트에서 직접 엑셀을 만들 수 있으면 좋겠다고 생각하게 됩니다.그때 보통 가장 먼저..

패키지를 관리하다 보면 package.json의 버전과 Git 태그가 서로 달라지는 경우가 자주 발생한다. 특히 Git 태그를 기준으로 배포하거나, npm publish 같은 작업을 자동화하려는 경우에는 버전 일치가 굉장히 중요하다. 필자의 경우 Git Flow 기반으로 개발하고 있으며, 릴리즈 시 Git 태그를 이용해 버전을 관리하고 있다. 이러한 구조에서는 Git 태그만 생성하면 자동으로 package.json의 버전까지 맞춰주는 방식이 매우 유용하다.이를 위해 간단한 스크립트를 작성해, Git 태그에서 버전을 추출하고 package.json의 버전을 자동으로 동기화하는 과정을 구현했다. 덕분에 GitHub Actions + npm 자동 배포 + 버전 자동 동기화까지 전부 매끄럽게 연결할 수 있었다...

왜 실과 팀, 각각의 그라운드룰이 필요했을까?실 차원에서 별도의 그라운드룰을 만들자는 논의가 나왔고, 우리 팀은 이미 팀 차원에서 자체적인 그라운드룰을 운영하고 있었기 때문에 실 그라운드룰 작성을 맡아서 진행하게 되었습니다. 그래서 이제 진행하면서 느낀 부분에 대해서 말씀드리겠습니다.먼저 실과 팀의 그라운드룰은 성격 자체가 다르다는 점에서 출발했고 그래서 각각의 기준을 명확히 잡는 것이 우선이라고 판단하였고 거기에 대한 분리부터 시작해야 한다고 생각이 들었습니다.실 그라운드룰의 성격‘실’ 단위는 단순히 한 팀 내부의 약속을 넘어서는, 조직 전체의 정합성과 방향성을 맞추는 상위 개념의 기준입니다!그래서 이 룰은 자주 변경되면 안 되고, 구성원 모두가 신뢰하고 따를 수 있는 기준이 되어야하고 너무 디테일하거..

프로젝트에 Git Flow를 도입해 브랜치 전략을 체계적으로 운영하고 있었지만, prod 배포 시마다 수동으로 태그를 만들고 릴리즈 노트를 작성하는 작업은 여전히 개발자의 몫이었음. 이런 반복적인 업무는 개발에만 집중할 수 없는 환경을 만들게 되었고, 이를 해결하기 위해 배포 시점에 자동으로 버전 태그를 생성하고, 커밋 로그 기반으로 릴리즈 노트를 자동 생성하는 GitHub Actions 워크플로우를 구축.시나리오우선 도입한 깃플로우 전략에 따라서 release/, feature/, hofix/ 이렇게 별도 브랜치를 구분해서 완료시켜 dev, prod 로 브랜치 병합 작업을 진행했음.예를 들어, release/v1.0.0 브랜치를 prod로 머지한다고 가정하면, 이 브랜치명에서 v1.0.0이라는 버전 정..