AI · 모델

요즘 개발 얘기에 ‘바이브코딩’이라는 말이 부쩍 늘었어요. 그런데 막상 “그게 정확히 뭐야?” 하면 설명이 애매해지죠. 느낌은 알겠는데 정의가 흐릿하거든요.

간단히 봐요. 바이브코딩은 코드를 손으로 짜는 대신, AI에게 ‘이런 걸 만들어줘’라고 말로 시켜서 만들어가는 방식이에요. 문법을 다 외우지 않아도, 의도를 잘 전하고 나온 결과를 확인·수정하면 앱이 굴러가요. 요리 레시피를 몰라도 “이런 맛으로” 주문하면 접시가 나오는 것과 비슷해요.

핵심은 타이핑이 아니라 ‘지시와 확인’으로 무게중심이 옮겨간 것이에요.

그래서 비전공자도 진입이 빨라졌어요. 다만 착각하면 안 되는 게, AI가 90%를 만들어줘도 뭘 시킬지 정하고, 이상한 10%를 걸러내는 건 사람 몫이에요. 바이브코딩을 잘한다는 건 코드를 안 본다는 뜻이 아니라, 의도를 정확히 전하고 결과를 판단하는 감각을 키운다는 뜻에 가까워요.

ChatGPT나 Claude를 쓰다 보면 ‘LLM’이라는 말을 만나요. Large Language Model, 우리말로 대규모 언어모델이에요. 이름은 거창한데 원리는 생각보다 단순해요.

LLM은 아주 많은 글을 학습해서 ‘다음에 올 말’을 잘 맞히는 예측기예요. “하늘이 맑고 날씨가 ___” 하면 ‘좋다’가 올 확률이 높다는 걸 아는 거죠. 이걸 문장, 문단, 코드 단위로 어마어마하게 잘하는 게 요즘 모델이에요. 인터넷의 글을 거의 다 읽은 사람이 다음 문장을 술술 이어주는 느낌이에요.

LLM은 ‘검색’이 아니라 ‘예측’이에요. 그래서 그럴듯하지만 틀린 말(할루시네이션)도 나와요.

이 원리를 알면 두 가지가 이해돼요. 하나는 왜 답이 매번 조금씩 달라지는지, 또 하나는 왜 최신 정보를 못 맞히는지(지식 컷오프)예요. 검색기가 아니라 학습된 예측기라서 그래요. 이 감각만 잡아도 AI를 훨씬 덜 헷갈리며 쓸 수 있어요.

바이브코딩에서 실력 차이가 가장 크게 나는 지점이에요. 같은 AI를 써도 누구는 원하는 걸 한 번에 받고, 누구는 열 번을 다시 시켜요. 그 차이가 대부분 프롬프트에서 갈려요.

핵심은 구체성이에요. “로그인 만들어줘”보다 “이메일·비밀번호로 로그인하고, 실패하면 빨간 메시지를 띄워줘”가 훨씬 정확한 결과를 불러와요. 맥락, 원하는 형식, 예시를 얹을수록 AI가 덜 헤매거든요.

프롬프트를 잘 쓰는 건 마법이 아니에요. 원하는 걸 스스로 명확히 아는 것에 가깝죠.

그래서 저는 결과가 어긋나면 코드부터 뜯어보지 않아요. 내 지시가 애매하진 않았는지를 먼저 봐요. 이 습관 하나만 들여도 재시도 횟수가 눈에 띄게 줄어요.

바이브코딩을 하다 보면 “토큰”이라는 말을 계속 만나요. 요금 얘기할 때도, 문서가 잘렸다는 얘기할 때도 나오죠. 그래서 처음엔 좀 헷갈려요.

간단하게 봐요. AI는 글을 글자나 단어가 아니라 ‘토큰’ 단위로 읽어요. 대략 한글은 한 글자가 한두 토큰, 영어는 한 단어가 한 토큰쯤이에요. 우리가 문장을 눈으로 읽듯, AI는 토큰을 하나씩 세면서 읽는 셈이에요.

대화가 길어질수록 토큰이 쌓이고, 토큰이 곧 요금이자 길이 한도예요.

그래서 긴 코드나 문서를 통째로 붙여넣으면 두 가지가 벌어져요. 하나는 비용이 올라가는 것, 또 하나는 모델이 한 번에 담을 수 있는 양(컨텍스트)을 넘겨서 뒷부분이 잘리는 거예요. 저는 처음에 이걸 몰라서, 긴 파일을 매번 다 붙여넣다가 “왜 답이 자꾸 앞부분만 보고 얘기하지?” 하고 한참 헤맸어요.

요령은 단순해요. 필요한 부분만 잘라서 주기. 파일 전체가 아니라 관련 함수만, 로그 전체가 아니라 에러난 줄 주변만. 토큰을 아낀다는 건 결국 AI에게 “핵심만 정확히” 주는 습관이에요.

AI와 길게 대화하다 보면 이런 순간이 와요. 분명 아까 말했는데, AI가 그걸 까먹고 엉뚱한 소리를 하는 거죠. 사람이면 서운할 일인데, 여기엔 이유가 있어요.

AI는 한 번의 대화에서 기억할 수 있는 양에 정해진 한계가 있어요. 그 한계가 컨텍스트 윈도우예요. AI의 책상 크기라고 보면 돼요. 책상이 넓으면 서류를 많이 펼쳐두고 참고하지만, 꽉 차면 오래된 서류부터 밀려 떨어져요. 그렇게 떨어진 내용은 AI가 더 이상 못 봐요.

대화가 길수록, 긴 파일을 붙일수록 책상이 빨리 차요. 그래서 앞부분이 잊혀요.

이걸 알면 대처가 쉬워요. 중요한 지시는 한 번에 몰아서, 앞이 아니라 가까이에 다시 주는 거예요. 파일도 통째로 말고 필요한 부분만. 이 습관 하나로 “왜 자꾸 딴소리하지?” 하는 순간이 확 줄어요. 참고로 이 책상에 올라가는 글자 수를 세는 단위가 토큰이에요.

바이브코딩에서 제일 조심해야 할 게 이거예요. AI는 모른다고 말하기보다, 그럴듯한 답을 자신있게 만들어내는 쪽으로 자주 기울어요.

예를 들어 “이 라이브러리에 이런 옵션 있어?” 하고 물으면, 실제로는 없는 옵션 이름을 진지하게 알려줄 때가 있어요. 코드도 마찬가지예요. 문법은 완벽한데 존재하지 않는 함수를 호출하는 코드를 척척 써주죠. 저도 처음엔 말투가 워낙 당당해서 그대로 믿고 돌렸다가 에러를 만난 적이 많아요.

AI의 확신은 정답의 근거가 아니에요. 말투가 당당한 것과 사실인 것은 별개예요.

해결책은 의심이 아니라 검증 습관이에요. 코드는 일단 돌려보고, 사실 주장은 공식 문서로 한 번 확인하는 거죠. 바이브코딩이 빨라질수록 이 “돌려보고 확인” 한 박자가 오히려 더 중요해져요. AI가 90%를 맞혀도, 나머지 10%를 걸러내는 건 결국 사람 몫이거든요.

AI에게 최신 라이브러리 사용법을 물었는데, 한물간 방식이나 옛날 버전을 알려줄 때가 있어요. 분명 요즘 건데 왜 모를까요. 여기서 알아야 할 개념이 지식 컷오프예요.

AI는 특정 시점까지의 데이터로 학습하고 멈춰요. 그 마감일이 지식 컷오프예요. 어떤 날짜까지의 신문만 읽은 사람과 같아요. 그날까지의 세상은 훤히 알지만, 그 뒤에 나온 새 버전·새 뉴스는 몰라요. 아는 척은 하지만 사실 학습이 안 된 거죠.

그래서 “최신”이 걸린 질문엔 AI 답을 그대로 믿지 말고 한 번 확인하는 게 안전해요.

요즘은 검색 도구를 붙여 이 한계를 메우기도 해요. 하지만 기본값은 여전히 ‘마감일까지의 지식’이라고 생각하는 게 맞아요. 특히 버전이 자주 바뀌는 도구는, AI 답 + 공식 문서 한 번 대조가 습관이 되면 헛발질이 줄어요. 이건 AI가 검색이 아니라 예측이라는 점과도 이어져요.

같은 AI인데 어떤 도구에선 딱딱하게, 어떤 도구에선 친근하게 답해요. 사용자가 매번 말투를 지정한 것도 아닌데 말이죠. 이 차이를 만드는 게 시스템 프롬프트예요.

시스템 프롬프트는 대화가 시작되기 전에 AI에게 미리 깔아두는 설정이에요. “너는 친절한 상담원이고, 존댓말을 쓰고, 코드엔 항상 주석을 달아” 같은 배경 지시죠. 매 질문에 따라붙는 게 아니라, 무대 뒤에서 계속 작동하는 배역 설명서예요. 배우가 그 설정 위에서 연기하듯, AI도 그 위에서 답해요.

우리가 보통 치는 질문(사용자 프롬프트)은 대사, 시스템 프롬프트는 그 대사가 놓이는 배경이에요.

바이브코딩 도구에서 이걸 자주 만나요. Cursor의 규칙 파일, 커스텀 인스트럭션, CLAUDE.md 같은 것들이 다 시스템 프롬프트 자리예요. 여기에 “이 프로젝트는 이런 규칙을 지켜” 하고 한 번 적어두면, 매번 반복해 말하지 않아도 AI가 그 톤을 유지해요. 잘 써두면 재지시가 확 줄어드는 지점이에요.

AI 도구를 켜면 모델을 고르라고 해요. Opus, Sonnet, Haiku 같은 이름이 뜨죠. 처음엔 “뭐가 다르지? 그냥 제일 좋은 거 쓰면 되나?” 싶어요. 여기서 알아둘 게 모델 티어예요.

모델 티어는 같은 계열 AI를 성능·속도·가격으로 나눈 등급이에요. 자동차 트림을 떠올리면 쉬워요. 깡통 모델, 중급, 풀옵션. 위로 갈수록 더 똑똑하지만 대신 느리고 비싸요. 반대로 아래 티어는 저렴하고 빠른데 복잡한 일엔 조금 아쉬워요.

핵심은 ‘제일 센 것’이 아니라 ‘이 일에 맞는 것’을 고르는 거예요.

그래서 저는 일에 따라 갈라 써요. 복잡한 설계·긴 추론은 상위 티어, 단순 반복이나 대량 작업은 하위 티어. 무조건 최상위만 켜두면 요금(토큰 비용)이 생각보다 빨리 쌓이거든요. 상황에 맞게 티어를 고르는 감각만 잡아도 비용과 속도를 둘 다 챙길 수 있어요.

챗봇은 물으면 답하고 끝이에요. 그런데 요즘 도구는 한 번 시키면 알아서 파일을 고치고, 명령을 돌리고, 결과를 보고 다음 걸 이어가요. 이런 걸 에이전트라고 불러요.

에이전트는 지시 하나로 스스로 여러 단계를 계획하고, 도구까지 써서 일을 끝내는 AI예요. 챗봇이 질문마다 답하는 알바라면, 에이전트는 심부름 리스트를 통째로 맡길 수 있는 인턴이에요. “이 기능 만들어줘” 하면 파일을 찾고, 코드를 고치고, 테스트를 돌리는 걸 알아서 이어가요.

편한 만큼 조심할 것도 있어요. 알아서 실행하니, 뭘 했는지 사람이 확인하는 습관이 중요해요.

바이브코딩 도구의 ‘에이전트 모드’가 바로 이거예요. 강력하지만 만능은 아니에요. 복잡하거나 애매한 판단이 필요한 일에선 여전히 엉뚱한 결과를 자신있게 내놓거든요. 그래서 저는 에이전트에게 크게 맡기되, 결과는 꼭 훑어보고 넘어가요. 맡기는 것과 방치는 다르니까요.

Claude Code 같은 도구를 쓰다 보면 ‘MCP 서버’라는 말이 튀어나와요. Model Context Protocol의 약자인데, 이름만 보면 뭔지 감이 안 오죠. 그런데 개념은 의외로 직관적이에요.

MCP는 AI에게 외부 도구나 데이터를 표준 방식으로 연결해주는 규격이에요. AI를 위한 USB 포트라고 보면 돼요. 예전엔 도구마다 연결 방식이 제각각이었는데, 포트 규격을 통일하니 어떤 기기든 꽂으면 되잖아요. MCP도 똑같아요. 규격만 맞으면 파일 시스템, 데이터베이스, 외부 API 같은 걸 AI에 꽂아서 쓰게 해줘요.

덕분에 에이전트가 쓸 수 있는 ‘도구’의 폭이 확 넓어져요.

비전공자라면 지금 당장 깊게 알 필요는 없어요. 다만 도구에서 “MCP 추가하면 이런 것도 돼요” 같은 안내를 만났을 때, ‘AI에 기능을 꽂는 표준 방식이구나’ 정도만 알아도 충분해요. 필요해지는 순간이 오면 그때 한 걸음 더 들어가면 돼요.

바이브코딩으로 외부 기능을 붙이다 보면 꼭 만나는 칸이 있어요. “여기에 API 키를 입력하세요.” 처음엔 여기서 다들 멈칫하죠. 키가 뭐고, 어디서 받아서, 어디에 넣으라는 건지 막막하거든요.

API 키는 외부 서비스를 쓸 때 ‘나 이거 쓸 자격 있어요’를 증명하는 비밀 문자열이에요. 회원 전용 라운지의 출입증 같은 거예요. 이게 있어야 API라는 창구가 문을 열어주고, 내가 쓴 만큼 내 계정으로 요금이 집계돼요. 보통 그 서비스에 가입하면 대시보드에서 발급받아요.

그래서 API 키는 남에게 보이면 안 돼요. 출입증을 잃어버리면 남이 내 이름으로 들어가 버리니까요.

가장 흔한 사고가 키를 코드에 그대로 적어 공개 저장소에 올리는 거예요. 그럼 남이 내 키로 요금을 태우는 일이 생겨요. 그래서 키는 코드에 직접 쓰지 말고 환경변수로 빼두는 게 기본이에요. “키는 환경변수로” 이 한 줄만 습관 들여도 사고의 절반은 막아요.

앱이 잘 돌아가다가 갑자기 “rate limit exceeded” 같은 에러가 뜰 때가 있어요. 코드를 바꾼 것도 아닌데 말이죠. 당황스럽지만, 이건 고장이 아니라 규칙이에요.

레이트 리밋은 정해진 시간 안에 보낼 수 있는 요청 횟수의 상한이에요. 인기 놀이기구의 시간당 탑승 인원 제한과 같아요. 한꺼번에 너무 몰리면 안전을 위해 “잠시 후 다시” 하고 줄을 세우잖아요. 서비스도 서버를 지키려고, 짧은 시간에 요청이 몰리면 잠깐 막아요.

에러라기보다 ‘지금은 좀 천천히’라는 신호예요. 대개 잠시 기다리면 풀려요.

대처는 두 가지예요. 하나는 요청을 몰아치지 말고 간격을 두는 것, 또 하나는 무료 등급이라면 한도가 낮으니 사용량을 확인하는 거예요. 참고로 이 한도는 API 키 단위로 걸리는 경우가 많아요. 그래서 갑자기 막히면 “내가 지금 너무 빨리 부르고 있나?”부터 의심하면 대개 맞아요.