[태그:] AI서비스

비개발자를 위한 AI 개발 구조: IDE, MCP, Agent가 왜 중요한가

IDE, MCP, Agent를 어떻게 이해하고 설계할까

최근 AI 코딩 도구와 모델이 빠르게 좋아지면서 개발 방식도 크게 바뀌고 있습니다.
하지만 여기서 단순히 “모델이 얼마나 똑똑한가”만 보면 핵심을 놓치기 쉽습니다.

실제로 서비스를 만들 때 더 중요한 건, 이 강력한 AI를 어떤 구조로 연결하고 굴릴 것인가입니다.
즉, 이제 AI 개발은 점점 지능의 싸움이 아니라 구조의 싸움에 가까워지고 있습니다.

오늘은 AI 서비스를 이해할 때 꼭 알아두면 좋은 4가지 개념과, 어떤 구조로 시작하는 것이 현실적인지 간단히 정리해보겠습니다.

1. 헷갈리는 AI 용어, ‘주방’ 비유로 이해하기

AI 개발 환경은 하나의 주방으로 생각하면 이해가 쉽습니다.

  • IDE(통합개발환경): 요리가 이뤄지는 주방 그 자체입니다.
    칼, 도마, 가스레인지가 갖춰진 작업 공간이라고 보시면 됩니다.
    Cursor처럼 IDE 안에서 쓰는 방식도 있고, Claude Code나 Codex처럼 터미널(CLI) 기반으로 많이 활용되는 에이전트형 코딩 도구도 있습니다.
  • Agent(에이전트): 무엇을 만들지 판단하고 실제로 움직이는 셰프입니다.
    질문을 이해하고, 필요한 도구를 고르고, 결과를 정리하는 역할을 맡습니다.
  • MCP (Model Context Protocol): 주방 밖에서 재료를 가져오는 표준 연결 통로입니다.
    날씨, 항공권, DB, 파일 등 외부 데이터와 도구를 AI에 연결해주는 방식입니다.
  • Data / Tools(데이터 / 도구): 실제 요리에 쓰이는 식재료입니다.
    예를 들어 실시간 날씨 정보, 사용자 예약 기록, 사내 문서 등이 여기에 해당합니다.

이렇게 나눠보면 조금 명확해집니다.
IDE는 작업 공간, Agent는 실행 주체, MCP는 연결 방식, Data/Tools는 실제 재료입니다.

2. MCP가 중요한 이유: ‘매번 새로 붙이지 않기’ 위해서

예전에는 AI가 외부 정보를 쓰게 하려면, 서비스마다 연결 코드를 제각각 붙여야 하는 경우가 많았습니다.
처음에는 빨라 보여도, 도구가 늘어나면 관리가 금방 복잡해집니다.

MCP의 핵심은 이 지점을 정리해준다는 데 있습니다.
한마디로 말하면, AI와 외부 데이터/도구를 연결하는 방식을 표준화하는 것입니다.

쉽게 말해, 매번 전용 어댑터를 새로 만드는 대신 공용 규격을 만드는 느낌에 가깝습니다.
이렇게 해두면 프로젝트가 바뀌어도 연결 구조를 재사용하기 쉬워지고, Agent를 바꾸더라도 전체 구조가 덜 흔들립니다.

결국 MCP의 장점은 기술 이름 자체보다도 재사용성과 유지보수성에 있습니다.
한 번 잘 분리해두면, 다음 프로젝트에서 그대로 자산이 됩니다.

3. 한 명의 에이전트로 갈까, 여러 명의 에이전트로 갈까

AI 서비스를 설계할 때 자주 나오는 고민이 있습니다.

“에이전트를 한 명만 둘까, 여러 명으로 나눌까?”

예를 들어 여행 가이드 서비스를 만든다고 가정해보겠습니다.

A. Single Agent + 필요한 도구 연결

한 명의 유능한 에이전트가 항공권 조회, 맛집 검색, 날씨 확인 같은 도구를 필요할 때 직접 호출하는 방식입니다.

  • 특징: 한 에이전트가 전체 맥락을 쥐고 있어 답변이 일관적입니다.
  • 장점: 구조가 단순하고, 비용과 속도 면에서 유리합니다.
  • 추천 대상: 대부분의 MVP, 개인 프로젝트, 초기 서비스

B. Multi-Agent

항공 전문가, 호텔 전문가, 일정 조정 전문가처럼 여러 에이전트가 역할을 나눠 협업하는 방식입니다.

  • 특징: 역할 분리가 명확할수록 강력합니다.
  • 장점: 복잡한 다단계 업무나 검토/검증이 중요한 구조에 적합합니다.
  • 단점: 구조가 복잡해지고, 비용과 응답 시간이 늘어날 수 있습니다.

겉으로는 Multi-Agent가 더 고급스러워 보일 수 있습니다.
하지만 실제로는 작은 문제에 너무 큰 구조를 올리는 경우도 많습니다.
사람 조직도 회의 참석자가 많아질수록 느려지듯, 에이전트도 비슷합니다.

4. 그래서 어떤 구조로 시작하는 게 좋을까

제 기준에서는, 처음부터 복잡하게 가기보다 아래 순서가 가장 현실적입니다.

  1. 먼저 한 명의 에이전트로 시작합니다.
    전체 흐름이 실제로 어떻게 돌아가는지 먼저 보는 편이 빠릅니다.
  2. 재사용할 도구와 데이터는 분리합니다.
    날씨, DB, 문서 조회처럼 반복 활용할 요소는 처음부터 연결 구조를 나눠두는 게 좋습니다.
  3. 정말 필요할 때만 Multi-Agent로 확장합니다.
    검증 단계가 따로 필요하거나, 역할 분리가 분명할 때만 늘려도 늦지 않습니다.

즉, 처음부터 “멋진 구조”를 만드는 것보다
작게 시작해서, 필요한 만큼만 구조를 키우는 것이 더 실용적입니다.

마치며

AI 기술은 계속 바뀌겠지만, 그 안에서도 비교적 오래 남는 역량이 하나 있습니다.
바로 복잡한 문제를 단순한 구조로 바꾸는 능력입니다.

좋은 AI 서비스는 단순히 똑똑한 모델 하나로 완성되지 않습니다.
어떤 Agent가 어떤 Tools를 어떻게 쓰고, 그 연결을 얼마나 재사용 가능하게 설계했는지가 결과를 많이 좌우합니다.

결국 중요한 건 “최신 기술을 많이 붙이는 것”이 아니라,
내 문제에 맞는 구조를 설계하는 것입니다.

기술에 끌려가기보다, 기술을 구조적으로 다루는 쪽이 오래 갑니다.

Next…
다음 글에서는 이번 글과 이어서 “나에게 맞는 AI 바이브 코딩 하기”라는 주제로,
툴보다 더 중요한 것은 무엇인지 정리해보겠습니다.

 

AI 챗봇 기획, 처음이라면 꼭 알아야 할 개념 5가지

서문

LLM 기반 챗봇을 처음 기획하면서 가장 어려웠던 점은, 핵심 개념들이 전혀 익숙하지 않다는 점이었습니다. 예를 들어, 처음 들었던 ‘RAG’, ‘폴백 시나리오’, ‘쿠션멘트’ 같은 용어들은 그 의미조차 가늠이 되지 않아 막막했던 기억이 납니다. RAG, LLM, 프롬프트 등의 용어부터 구조, 그리고 대응 방식까지 모두 새로운 세계였습니다.

무엇보다도 제가 가장 먼저 가졌던 생각은…

“AI니까 방향만 입력해주면 알아서 다 하는 거 아니야? 내가 기획자로 꼭 필요할까?”

하지만 프로젝트를 진행할수록 명확해졌습니다.
AI가 더 똑똑해질 수 있도록, 그 방향과 기준을 제시하는 역할은 여전히 ‘기획자’에게 있다는 사실입니다.
AI는 방대한 정보를 학습했지만, 그 중 어떤 것을 언제 어떻게 보여줄 지를 스스로 정하지 못합니다. 예를 들어 어떤 발화가 ‘혐오인지 아닌지’, ‘차별인지 아닌지’를 아직은 완벽하게 판단하지는 못하죠.

즉, AI는 많은 걸 아는 존재지만, 정확히 어느 선에서 말해야 하는지를 모릅니다. 그 기준을 설정하는 사람이 필요합니다.
물론… 기획자가 아주 잘 설계해놓고 계속 피드백까지 제공한다면 언젠간 정말 기획자가 필요 없어질지도 모르겠습니다.

이 글은 저와 같은 입장에서 출발하는 모든 분들을 위해, LLM 챗봇을 기획하면서 반드시 마주치게 되는 기본 개념들을 정리한 글입니다.
가볍게 한 번 살펴봐 주시면 감사하겠습니다.

1. LLM + RAG

LLM (Large Language Model)은 대규모 텍스트 데이터를 학습해 문장을 생성하는 AI 모델입니다. 대표적인 예시로 GPT-4, Gemini, Claude 등이 있죠.

하지만 LLM은 모든 정보를 알고 있는 전지적 존재가 아닙니다. 일정 시점까지의 데이터로 학습되었고, 그 이후 정보나 기업 내부 정보는 모릅니다. 이를 보완하기 위해 도입된 개념이 RAG (Retrieval-Augmented Generation) 입니다.

  • RAG 1.0: 유저 질문을 벡터화 → 문서 검색 → 검색된 문서를 기반으로 LLM이 응답 생성
  • RAG 2.0: 유저 질문 + 문서 검색 결과를 통합 → 프롬프트에 구조화하여 응답 생성 (더 높은 정밀도와 출처 추적 가능)

RAG를 한 줄로 쉽게 설명한다면, 정보를 최신화하는 프레임워크라고 볼 수 있습니다. RAG 1.0이 ‘좋은 책 한 권’을 찾아 답변하는 것이라면, RAG 2.0은 ‘여러 권의 좋은 책’을 찾아 ‘정확하고 논리적인 비교 분석’까지 해주는 것이라고 생각하면 이해하기 쉽습니다. 다만 아직 2.0은 보편적으로 적용된 상태는 아닙니다.

기획자는 이 구조를 이해해야, 왜 ‘출처 표기’가 필요한지, 어떤 식으로 데이터를 전처리해야 하는지를 설계할 수 있습니다. 일반적으로 말하는 AI 모델은 이 두 가지를 함께 패키지로 언급하는 걸로 이해하시면 쉽습니다.

2. 메인 시나리오 / 폴백 시나리오

LLM 챗봇도 여전히 시나리오 설계가 핵심이고 기획자가 필요한 이유입니다. 사용자의 질문이 정해진 흐름대로 이어질 수 있는 경우에는 메인 시나리오, 그렇지 않거나 실패 상황에서는 폴백 시나리오로 구분됩니다.

  • 메인 시나리오: 유저가 의도한 목적(예: “배송 조회”)에 도달하기 위한 핵심 플로우. 대부분의 시나리오 설계의 기반.
  • 폴백 시나리오: ‘의도 불일치, 시스템 오류, 잡담 대응, 부적절 발화’ 등 예상 외 상황. (발화 예: “제가 잘 이해하지 못했어요. 다시 한 번 말씀해주시겠어요?”)

메인 시나리오 / 폴백 시나리오 구조는 챗봇에서 유래했지만, 챗봇에만 국한되지 않고 다양한 인터랙티브 시스템(서비스) 전반에 통용되는 개념입니다.

두 시나리오는 각각 다른 UX, 응답 톤, Safety 정책이 필요하며, 기획자가 이 경계를 명확히 잡아주는 것이 중요합니다.

3. 쿠션멘트

쿠션멘트란, 사용자의 감정선을 고려하여 직접적인 응답 이전에 제공하는 완충 문장을 의미합니다. 예를 들어, 사용자가 반복적으로 같은 질문을 하거나 챗봇이 명확히 답을 주지 못하는 상황에서, “죄송합니다. 다시 한번 확인해보겠습니다.”와 같은 문장이 쿠션멘트가 될 수 있습니다.

  • 예: “확인해볼게요! 잠시만 기다려주세요.”
  • 예: “질문 감사합니다. 안내드릴게요.”

단순히 친절해 보이기 위한 표현이 아니라, LLM이 제공하는 불안정하거나 모호한 응답을 감싸는 장치로써 매우 중요한 역할을 합니다. 특히 반복된 fallback 시나리오에서는 사용자 피로감을 줄여주거나, 부정적 사용 경험을 완화하는 효과도 있습니다.

실제 운영에서도 쿠션멘트가 포함된 응답은, 포함되지 않은 응답보다 사용자 만족도와 피드백 지표가 더 높게 나타났습니다. 정성 분석 결과, 사용자들은 쿠션멘트가 포함될 경우 “배려받는 느낌이다”, “AI가 나를 신경 쓰는 것 같다”는 반응을 보이기도 했습니다.

실험 설계나 AB 테스트를 통해 쿠션멘트의 효과를 직접 검증해보는 것도 기획자에게 매우 유의미한 경험이 될 수 있습니다.

4. 파지티브 규제 / 네거티브 규제

챗봇이 어떤 질문에 답을 해도 되는지, 어떤 질문은 막아야 하는지를 정하는 방식은 두 가지로 나뉩니다.

  • 파지티브 규제 (Positive Regulation): 정해진 질문과 응답만 허용 (화이트리스트 기반)
  • 네거티브 규제 (Negative Regulation): 금지된 항목만 차단, 그 외는 허용 (블랙리스트 기반)

용어 때문에 자칫 헷갈릴 수 있는데, 실제 자유도는 반대입니다. 파지티브 규제는 ‘되는 거만 빼고 다 안되기’에 자유도가 낮고, 오히려 ‘네거티브 규제’는 ‘안되는 거만 빼고 다되기 때문’에 자유도가 높습니다.

LLM 기반 챗봇은 자유도가 높기 때문에 네거티브 규제를 적용해야 하며, 민감 이슈나 출처 문제로 인해 일부 영역에서는 파지티브 규제를 혼합 적용하기도 합니다. 특히 금융, 의료, 공공 분야에서는 이 균형이 매우 중요합니다.

5. Safety 정책

AI 챗봇은 사용자와 직접적으로 상호작용하기 때문에, 적절한 안전 정책(Safety Policy) 설정이 필수입니다.

  • 예: 욕설, 차별, 혐오 발언 차단
  • 예: 개인정보 질문 차단 (예: 주민번호, 계좌번호 등)
  • 예: 자살/자해 등 심각한 이슈에 대한 대응 시나리오

이를 해결하는 장치로는 프롬프트 차단(input filtering)과 응답 차단(output filtering)이 있습니다. 리스크가 큰 경우에는 프롬프트 차단을 우선 적용하며, 기본적으로는 응답 차단을 적용합니다.

카테고리 중 리스크가 큰 ‘아동 성착취, 혐오 및 차별’ 관련해서는 면밀한 검토가 필요하며, 출시 전에 높은 수준의 내부 검수가 필요합니다.

✅ 함께 알아두면 좋은 개념들

▸ 프롬프트(Prompt) & 프롬프트 엔지니어링

프롬프트는 LLM에게 질문이나 지시를 내리는 문장입니다.
“AI에게 말을 거는 방식”이라 생각하면 이해가 쉽습니다.

예시:
→ “이 글을 두 문장으로 요약해줘.”
→ “너는 친절한 고객센터야. 질문에 간결하게 답변해줘.”

좋은 프롬프트를 설계하면 더 정확하고 명확한 응답을 받을 수 있습니다.
기획자는 단순히 질문을 적는 게 아니라, 어떤 맥락에서 어떤 톤으로 응답해야 할지를 고려해 프롬프트를 설계해야 합니다.

📃참고: 안트로픽(Claude) 프롬프트 엔지니어링 가이드

▸ 싱글턴 vs 멀티턴

구분설명예시
싱글턴(Single-turn)한 번의 질문과 응답으로 끝나는 단문 대화 구조대부분의 고객센터, 쇼핑몰, 은행, 공공기관 챗봇 등
멀티턴(Multi-turn)이전 대화 맥락을 기억하며 이어지는 연속 대화 구조ChatGPT, Claude, Copilot 등 생성형 AI 서비스

현재 대부분의 상용 챗봇은 싱글턴 구조를 기반으로 구현되며, 멀티턴은 고도화 단계에서 도입됩니다.
반면, 생성형 AI 서비스는 멀티턴을 기본 전제로 설계됩니다.

▸ UI 출력 방식

LLM 챗봇은 단순 텍스트 외에도 이미지, 동영상, 버튼, 문서 링크 등을 포함할 수 있습니다. 이는 사용자의 몰입도와 정보 이해도를 높이기 위한 중요합니다. 실제 챗봇 UI에서 다양한 출력 형태가 어떻게 표현될 지는 정리하는 것은 주요한 기획 포인트입니다.

예시:
– 대표 이미지 썸네일
– 관련 문서 링크 버튼
– 답변 내용 하이라이트
– 출처 명시 (문서명, 링크 등)

▸ LLM의 한계 및 환각(Hallucination)

LLM은 정답을 “검색”하는 게 아니라, 가장 그럴듯한 답을 생성합니다.
그래서 다음과 같은 특징이 존재합니다.

– 동일한 질문에도 응답이 달라질 수 있음 → 비결정성
– 실제 존재하지 않는 정보를 만들어낼 수 있음 → 환각(hallucination)

이런 이유로, 다음 상황에서는 Rule 기반 시나리오와 병행이 필요합니다.

– 정답이 반드시 고정되어야 하는 영역 (예: 약관, 정책, 법률 등)
– 민감한 주제 또는 정확성이 중요한 고객상담 영역
– 내부 기준이나 구조화된 출력이 필요한 응답

이 글이 AI 챗봇 기획의 첫걸음을 떼는 분들께 작게나마 도움이 되기를 바랍니다. 끝까지 읽어주셔서 고맙습니다 🙂