목차(클릭하세요)
바이브 코딩을 시작하고, 보안/품질의 관점에서 리뷰
1.바이브 코딩에서 AI모델이란?
1-1. 엔트로픽 모델
•
주종은 Sonet, Opus, Fables
◦
Sonet: 일을 잘함(빠르게, 싸게)
◦
Opus: 팀장 역할, 사용토큰이 비쌈
1-2.구글 gemini모델
•
구글의 LLM모델은 Flash와 pro모델로 나눌 수 있음
◦
flash: 일을 잘함(빠르게, 싸게)
◦
Pro: 팀장역할, 사용 토큰이 비쌈
◦
Low와 HIGH의 차이: High는 굉장히 고차원적인 추론이 필요할때
•
결과적으로 깊은 사고와 복잡한 추론이 필요한 작업에는 3.1 Pro를, 빠르고 즉각적인 반응이나 가성비가 중요한 작업에는 3.5 Flash를 선택하는 것이 가장 효율적이라는 의견
1-3.물리 선생님의 아이디어
•
교실컴퓨터 Tracking Idea
◦
교실 컴퓨터의 학생 무단사용을 기록, 추척하는 프로그램
•
학생들 Idea: 축구 감독AI, 4방향 테트리스
2. AI업계의 Trend와 Future
2-1. A라는 서비스를 만들때?
•
학교의 식단을 가져오는 서비스를 만든다고 가져올때
◦
API서버에서 json형태로 답변을 가져왔음
◦
지금은 MCP를 활용하는 경우가 더 많아짐
•
*API는 "전화번호부"
◦
급식실 서버에 전화(요청)를 걸면, 정해진 형식(JSON)으로 답변을 딱 던져줘.
◦
근데 그 답변을 어떻게 해석하고, 어떤 화면에 뿌릴지는 전부 개발자가 코드로 짜야 함.
•
MCP는 "비서를 고용하는 것"에 가까워.
◦
AI한테 "오늘 급식 뭐야?"라고 물으면, AI가 알아서 급식 서버라는 도구를 꺼내 쓰고, 결과를 이해해서 자연어로 정리해줌.
◦
개발자는 "이 도구를 쓸 수 있어"라고 등록만 해주면 됨.
2-2. API vs MCP
1) API 방식 — 지금까지의 표준
•
흐름: 클라이언트 → REST/GraphQL 요청 → 서버가 JSON 반환 → 개발자가 파싱해서 UI에 꽂음
•
급식 예시라면: GET /api/meal?date=2026-07-11 호출 → {"lunch": "제육볶음, 김치찌개..."} 받아서 프론트엔드 컴포넌트에 직접 매핑
장점 | 단점 |
성능 예측 가능, 캐싱 쉬움 | 서비스마다 스펙이 다 달라서 붙일 때마다 새로 학습·구현 |
명세(OpenAPI 등)가 명확 | AI가 이걸 "이해"하려면 별도로 함수 설명을 프롬프트에 다 적어줘야 함 |
이미 검증된 생태계, 툴 풍부 | N개 서비스 붙이면 N개의 커스텀 통합 코드가 생김 (확장성 낮음) |
2) MCP 방식 — AI 네이티브 통합
•
[흐름] AI 모델 MCP 서버(급식 도구 제공) — 표준 프로토콜로 "도구 목록 + 사용법"을 AI가 스스로 조회하고 호출
MCP 서버(급식 도구 제공) — 표준 프로토콜로 "도구 목록 + 사용법"을 AI가 스스로 조회하고 호출•
[급식 예시] 급식 MCP 서버를 하나 만들어두면, 이 AI든 저 AI든 "오늘 메뉴 뭐야?" 질문에 알아서 도구를 찾아 호출함
장점 | 단점 |
도구 재사용성 높음 (한 번 만들면 어떤 MCP 클라이언트든 붙일 수 있음) | 아직 생태계 초기 — 표준이 계속 진화 중 (버전 호환성 이슈 종종 발생) |
AI가 컨텍스트 안에서 "언제 이 도구를 쓸지" 스스로 판단 | 매 호출마다 도구 설명이 컨텍스트에 실려서 토큰 비용 증가 가능 |
여러 도구를 조합한 복잡한 워크플로우(체이닝)에 강함 | 실시간성·초저지연이 중요한 서비스엔 API 직결이 더 유리 |
인증·권한 관리가 프로토콜 레벨에서 어느 정도 표준화됨 | 디버깅 시 "AI가 왜 이 도구를 안 썼지"같은 블랙박스 이슈 존재 |
2-3. 개발자를 뽑을때
•
과거에는 프론트엔드 개발자/벡엔드 개발자 로 구분해서 뽑았음 AI개발자로 통합하여 선발함!
AI개발자로 통합하여 선발함!•
내가 어떤 프로젝트를 해봤다하는 ‘경험’이 중요해진 시대가 되었음