“블로그 하나 만들어줘!”
AI로 무언가 만들 수 있다는 이야기를 듣고 처음 건넬 법한 부탁입니다. 그런데 내가 원한 것은 사진을 크게 올리는 여행 블로그인데, AI는 글이 빼곡한 독서 기록장을 제안합니다. 분명 블로그이기는 합니다. 다만 내가 생각한 모습은 아닙니다.
“게임 만들어줘!”도 비슷합니다. 머릿속에는 자동차 경주가 있었는데, AI는 같은 그림을 찾는 카드 게임을 내놓을 수 있습니다. 반대로 어떤 게임을 만들고 싶은지 아직 생각하지 못했을 수도 있습니다. 그저 내 손으로 게임 하나를 만들어 보고 싶은 것이지요.
이럴 때 필요한 것은 어려운 명령어를 외우는 일일까요? 먼저 AI가 받은 말에서 알 수 있는 것과, 아직 정해지지 않은 것을 나누어 보는 일이 도움이 됩니다. 이 차이를 이해하면 LLM이 무엇인지도 훨씬 쉽게 다가옵니다.
‘블로그’라는 말 안에 들어 있는 여러 갈래
블로그를 떠올려 보세요. 어떤 사람은 여행 사진과 짧은 설명이 있는 화면을 생각합니다. 어떤 사람은 재료와 조리 순서가 나오는 요리 블로그를, 또 다른 사람은 책을 읽고 긴 감상을 남기는 공간을 생각합니다.
셋 다 블로그입니다. 하지만 첫 화면에서 크게 보여야 할 것이 다릅니다. 여행 블로그는 사진, 요리 블로그는 음식과 만드는 순서, 독서 블로그는 글의 제목과 내용이 중요할 수 있습니다.
“블로그 만들어줘”라는 말에는 아직 빈칸이 많습니다. 무엇을 올릴지, 누가 읽을지, 사진과 글 중 무엇을 먼저 보여 줄지 정해지지 않았습니다. ‘기존 블로그 서비스에 내 공간을 열고 싶다’는 뜻인지, ‘새 웹사이트를 만들고 싶다’는 뜻인지도 다를 수 있습니다.
AI는 추가로 질문하거나, 몇 가지 선택지를 제안하거나, 나름의 가정을 두고 초안을 만들 수 있습니다. 앞선 대화에 여행 사진 이야기가 있었다면 그 내용이 방향을 잡는 단서가 될 수도 있습니다.
따라서 첫 결과가 내 취향과 다르다는 이유만으로 AI가 말을 전혀 이해하지 못했다고 판단할 필요는 없습니다. 내가 생각한 조건이 대화 안에 전달되었는지부터 살펴볼 수 있습니다.
그 말을 읽고 답을 만드는 LLM
많은 대화형 AI에서 요청을 읽고 답을 만드는 중심 역할을 하는 것이 LLM입니다. Large Language Model의 약자이며, 우리말로는 ‘대규모 언어 모델’이라고 합니다.
많은 언어 자료에서 표현과 지식 사이의 관계를 학습한 모델입니다. 그 바탕으로 질문에 답하고 글을 요약하거나 새로운 내용을 작성합니다. AWS의 LLM 설명
블로그 예시로 돌아가 보겠습니다. ‘여행’, ‘사진’, ‘날짜별 기록’이라는 말을 함께 주면 글 중심의 독서 기록장보다 여행 사진을 보여 주는 구성이 요청에 더 잘 맞습니다. 사용자가 보탠 내용이 답을 만드는 단서가 되는 것입니다.
그렇다고 LLM 안에 여행 블로그 완성품이 들어 있어 그것을 꺼내 주는 방식으로만 작동하는 것은 아닙니다. 대화형 생성 LLM은 입력과 앞서 생성한 내용을 참고해 다음에 이어질 작은 텍스트 조각을 생성하고, 이를 반복해 답을 만듭니다. 글뿐 아니라 프로그램을 만드는 코드도 생성할 수 있습니다.
이 작은 텍스트 조각을 토큰이라고 합니다. 단어 하나일 수도, 단어의 일부일 수도 있습니다. 지금은 용어를 외우기보다, 전달한 내용을 참고하면서 답을 차례로 구성한다는 정도로 이해해도 충분합니다. Microsoft의 LLM 설명
스마트폰에서 다음에 쓸 단어를 추천받는 장면을 떠올리면 출발점을 잡기 쉽습니다. 다만 LLM은 긴 설명이나 코드처럼 훨씬 복잡한 결과도 만들어 내므로 짧은 단어 추천만으로 모든 능력을 설명할 수는 없습니다.
또 LLM과 우리가 사용하는 AI 서비스는 같은 말이 아닙니다. LLM이 코드를 생성하더라도, 그 코드를 실행하거나 화면으로 보여 주거나 인터넷에 올리는 일에는 별도의 기능이 필요합니다. 그래서 ‘블로그 만들어줘’라는 같은 부탁도 사용하는 도구에 따라 설명이나 코드로 돌아올 수 있고, 미리보기 화면까지 이어질 수도 있습니다. 사용하는 AI가 어디까지 할 수 있는지 확인해야 합니다.
‘게임 만들어줘’에서 시작해도 괜찮습니다
이번에는 게임을 떠올려 보겠습니다. 미로에서 출구 찾기, 자동차 경주, 같은 과일 카드 맞추기는 모두 게임이지만 규칙과 조작 방법이 다릅니다.
처음부터 ‘장르’, ‘개발 환경’, ‘구현 방식’을 알아야 하는 것은 아닙니다. 원하는 게임이 떠오르지 않으면 무엇을 만들지 정하는 일부터 AI에게 부탁할 수 있습니다.
게임 하나를 만들어 보고 싶어요. 코딩은 전혀 모릅니다.
어떤 게임을 만들고 싶은지도 아직 정하지 못했어요.
휴대전화에서 짧게 즐길 수 있는 간단한 게임을 세 가지 제안해 주세요.
각 게임에서 내가 무엇을 누르고, 어떻게 이기는지 쉽게 설명해 주세요.
아직 만들기 시작하지 말고, 제가 하나를 고를 수 있게 도와주세요.
가령 ‘과일 카드 맞추기’를 골랐다고 해 보겠습니다. 아래는 실제 실행 결과가 아니라, 게임의 범위를 좁혀 가는 대화 예시입니다.
AI가 물어볼 수 있는 질문: 카드를 눌러 뒤집고, 같은 과일 두 장을 찾는 방식으로 할까요?
내 선택: 네. 처음에는 카드 여섯 장만 보여 주세요. 같은 과일 두 장은 열린 채로 남고, 다르면 다시 뒤집히면 좋겠어요.
더 정할 부분: 모든 짝을 찾으면 어떻게 될까요?
내 선택: ‘완성!’이라고 보여 주고, 다시 시작하는 버튼이 나오면 좋겠어요.
이제 ‘게임’이라는 말이 구체적인 행동으로 바뀌었습니다. 카드는 여섯 장, 한 번에 두 장을 뒤집고, 같은 그림이면 남기고, 세 쌍을 찾으면 끝납니다. 개발 용어를 몰라도 원하는 동작은 설명할 수 있습니다.
요청을 잘 쓰는 데 중요한 것은 어려운 표현보다 작업과 필요한 조건을 분명하게 전달하는 일입니다. Anthropic도 명확한 지시와 세부 정보, 원하는 결과의 예시를 제시하도록 안내합니다. Anthropic의 요청 작성 안내
물론 막연한 부탁으로 바로 나온 결과가 마음에 들 수도 있습니다. 무엇이 가능한지 구경하고 싶다면 그 방식도 괜찮습니다. 다만 원하는 모습이 따로 있거나 고쳐야 할 부분이 생겼을 때는, 그 차이를 말로 꺼내 주어야 합니다.
블로그도 ‘어떤 모습인지’부터 함께 정하기
앞서 생각한 여행 블로그도 같은 방식으로 시작할 수 있습니다. ‘예쁘게 만들어줘’에서 조금만 더 나아가, 내가 무엇을 올리고 방문자가 무엇을 보았으면 하는지 설명해 보세요.
여행 사진과 짧은 일기를 올리는 블로그를 만들고 싶어요.
코딩은 모르고, 웹사이트를 만드는 것도 처음입니다.
첫 화면에는 사진과 글 제목이 함께 보였으면 좋겠어요.
사진을 누르면 그 여행의 사진과 일기를 읽을 수 있으면 좋겠습니다.
휴대전화에서도 사진과 글이 잘 보여야 해요.
우선 예시 여행 글 세 개가 있는 미리보기를 만들고 싶어요.
예시 글은 실제 제 여행 기록과 구분되게 표시해 주세요.
인터넷 공개와 실제 글을 추가하는 방법은 다음 단계에서 정할게요.
바로 만들기 전에 꼭 정해야 할 것이 있으면
어려운 용어 없이 질문 세 개 이내로 물어봐 주세요.
이 요청에는 첫 화면의 모습, 눌렀을 때의 동작, 사용하는 기기, 이번에 만들 범위가 들어 있습니다. ‘블로그’라는 넓은 단어보다 결과를 판단하기 쉬워졌습니다.
AI가 “사진을 크게 한 장씩 보여 줄까요, 여러 장을 격자로 보여 줄까요?”라고 묻는다면 마음에 드는 쪽을 고르면 됩니다. 어느 쪽이 좋은지 모르겠다면 “두 방식의 차이를 간단한 그림이나 예시로 보여 주세요”라고 부탁할 수도 있습니다. 해당 도구가 그림을 만들 수 없다면 글로 차이를 설명받아도 됩니다.
같은 여행 소재를 서로 다르게 배치한 개념 예시입니다. 실제 서비스 화면이나 동일 사진의 배치 실험은 아닙니다.
처음부터 모든 조건을 생각해 낼 필요는 없습니다. 첫 화면을 보고 “사진은 마음에 드는데 글 제목이 너무 작아요. 사진 크기는 유지하고 제목만 더 잘 보이게 해 주세요”라고 좁혀 갈 수 있습니다.
요청을 한 번에 완성하기보다, 선택하고 확인하며 원하는 결과에 가까워집니다.
여기서 한 가지가 더 남습니다. 예시 글이 보이는 화면과, 내가 새 글을 계속 올릴 수 있는 블로그는 다릅니다. 글을 어디에서 작성하고 어떻게 저장할지, 다른 사람이 어떤 주소로 들어올지도 나중에는 정해야 합니다. 첫 화면을 만든 뒤에 해결할 일을 구분해 두면 지금 무엇까지 만든 것인지 알 수 있습니다.
그래서 저는 먼저 계획부터 세웁니다
저는 AI에게 바로 “개발해 주세요”, “수정해 주세요”라고 맡기기보다 무엇을 어떻게 만들지 계획부터 세웁니다. AI가 만든 계획에서 빠진 부분과 마음에 들지 않는 부분을 고치고, 개발을 시작해도 되겠다고 판단되면 그 계획대로 진행하는 방식입니다.
여기서 계획은 “블로그 만들기 → 디자인하기 → 배포하기”처럼 순서만 적은 목록이 아닙니다. 어떤 화면이 필요한지, 무엇으로 만들지, 글과 사진은 어디에 저장할지, 어디에 올려 다른 사람이 보게 할지까지 정하는 문서입니다. 모르는 선택은 AI에게 이유와 대안을 설명받고 결정합니다.
웹 개발 입문 자료인 MDN도 코드를 작성하기 전에 사이트의 내용과 디자인을 먼저 계획하도록 안내합니다. 다만 계획의 깊이는 만들려는 것의 크기에 맞추면 됩니다. 첫 카드 게임 하나를 위해 거대한 서비스 설계서를 만들 필요는 없습니다. MDN의 첫 웹사이트 만들기
블로그라면 화면·저장·공개 방법까지
“여행 블로그를 만든다”는 목표를 정했다면, 저는 계획에서 다음 세 부분을 구분합니다.
프론트엔드는 방문자가 보고 누르는 쪽입니다. 사진 목록, 글 상세 화면, 메뉴, 휴대전화에서의 배치가 여기에 해당합니다. 백엔드는 서버에서 요청을 처리하는 쪽으로, 글을 저장하거나 로그인한 작성자를 확인하는 기능 등이 들어갈 수 있습니다. 배포는 만든 결과를 다른 사람이 접속할 수 있는 곳에 올리는 일입니다. 파일을 내 컴퓨터에서 열어 보는 것과 인터넷 주소로 공개하는 것은 다른 단계입니다.
개발 도구 이름을 많이 적었다고 좋은 계획이 되는 것은 아닙니다. “이 블로그에 왜 그 도구가 필요한가?”가 설명되어야 합니다. 예시 여행 글 세 개를 보여 주는 첫 미리보기라면 다음처럼 작게 정할 수 있습니다.
| 구분 | 역할 | 설명 | 예시 |
|---|---|---|---|
| 화면 | 사진 목록과 글 상세 | 사진과 제목을 누르면 해당 여행 글을 읽습니다. 휴대전화에서도 가로로 잘리지 않게 만듭니다. | HTML로 내용을 구성하고, CSS로 배치하며, 필요한 동작은 JavaScript로 만듭니다. |
| 서버와 저장 | 첫 버전은 별도 백엔드 없이 | 예시 글과 사진은 프로젝트 파일로 관리합니다. 로그인, 댓글, 브라우저에서 글을 쓰는 관리 화면은 이번 범위에 넣지 않습니다. | 실제 새 글 작성 기능이 필요해지면 CMS 연결이나 서버·저장소 구성을 별도로 결정합니다. |
| 배포 | 정적 파일을 제공하는 곳에 공개 | 파일을 제공하는 호스팅을 정하고 공개 주소, 업로드 방법, 요금과 제한을 확인합니다. | 이 예시의 후보는 Cloudflare Pages입니다. 실제 공개는 화면과 링크를 확인한 뒤 진행합니다. |
HTML은 웹페이지의 내용과 구조, CSS는 모양과 배치, JavaScript는 버튼을 눌렀을 때의 동작 등을 맡습니다. 각각을 따로 외우기보다 이번 계획에서 어떤 역할인지 연결해 보면 됩니다. MDN의 웹 기초 설명
Cloudflare Pages는 정적 HTML 사이트를 배포하는 방법을 공식 문서로 안내합니다. 여기서는 공개할 위치의 예로 든 것이며, 모든 블로그에 같은 서비스를 골라야 한다는 뜻은 아닙니다. Cloudflare Pages의 정적 HTML 배포 안내
이 계획을 읽다가 “나는 파일을 수정하지 않고 화면에서 글을 쓰고 싶은데?”라는 생각이 들면 개발 전에 그 부분부터 계획을 고칩니다. 글 작성 화면이 있는 기존 블로그 서비스를 쓸지, 콘텐츠를 관리하는 CMS를 연결할지, 직접 관리 기능을 만들지 다시 비교해야 합니다. 어떤 기능을 선택하느냐에 따라 저장 방식과 배포 구성이 달라지기 때문입니다.
게임이라면 개발 도구와 규칙·조작까지
카드 맞추기 게임도 “재미있게 만들어 주세요”에서 멈추지 않습니다. 어떤 기기에서 할지, 무엇으로 만들지, 눌렀을 때 어떻게 바뀌는지, 언제 끝나는지까지 계획합니다.
이번 예시라면 브라우저에서 실행하는 HTML·CSS·JavaScript 게임으로 범위를 정할 수 있습니다. 카드 모양은 HTML과 CSS로 만들고, 카드를 뒤집고 짝을 비교하는 규칙은 JavaScript로 처리하는 방식입니다. 웹 기술로 게임을 개발할 수 있다는 점은 MDN의 웹 게임 개발 안내에서도 확인할 수 있습니다. MDN의 웹 게임 개발 입문
계획에는 “카드 여섯 장”뿐 아니라 세부 동작도 적습니다. 마우스 클릭과 휴대전화 터치로 조작하고, 두 장을 비교하는 동안에는 세 번째 카드를 누를 수 없게 합니다. 같은 그림이면 열린 채로 두고, 다른 그림이면 잠시 보여 준 뒤 닫습니다. 세 쌍을 찾으면 완료를 알리고, 다시 시작하면 카드를 섞어 새 게임을 시작합니다.
첫 버전에서는 계정, 온라인 순위, 여러 사람의 동시 접속을 제외할 수 있습니다. 그러면 별도의 서버에 점수를 저장하지 않고, 현재 게임의 상태만 브라우저에서 관리하는 계획이 됩니다. 새로고침하면 진행 상황을 초기화할지도 미리 정해 둡니다. 3D 캐릭터나 복잡한 물리 동작이 필요하다면 이런 단순한 카드 게임과는 요구가 다르므로, 게임 제작 전용 도구인 게임 엔진을 쓸지부터 다시 검토하면 됩니다.
계획을 먼저 부탁하는 문장
처음에는 다음처럼 요청할 수 있습니다. 블로그 대신 만들고 싶은 게임이나 도구를 넣어도 됩니다.
여행 블로그를 만들고 싶습니다. 아직 코드는 작성하지 말고 계획부터 세워 주세요.
저는 개발 지식이 없으니 어려운 용어는 역할과 쉬운 예를 함께 설명해 주세요.
계획에는 다음을 포함해 주세요.
1. 이번에 만들 기능과 나중으로 미룰 기능
2. 필요한 화면과 각 화면에서 누르면 일어나는 일
3. 프론트엔드는 무엇으로 만들지, 그 선택이 필요한 이유
4. 백엔드가 필요한지, 필요하다면 무엇을 사용하고 어떤 일을 맡길지
5. 글과 사진을 어디에 저장하고, 새 글을 어떻게 추가할지
6. 어디에 배포할지, 비용이나 사용 제한은 무엇을 확인해야 하는지
7. 개발 순서와 단계마다 제가 직접 확인할 항목
8. 아직 결정하지 못한 점과 개발 전에 답해야 할 질문
모르는 조건은 임의로 확정하지 말고 선택지와 추천 이유를 알려 주세요.
제가 계획을 검토하고 개발을 시작하자고 말하기 전에는 구현하지 마세요.
게임이라면 3~5번을 “브라우저 게임으로 만들지, 게임 엔진을 쓸지”, “카드와 점수는 어떻게 처리할지”, “서버나 저장 기능이 필요한지”로 바꾸어 부탁하면 됩니다. 중요한 것은 기술 이름을 정답처럼 받는 것이 아니라, 내가 원하는 기능과 선택 이유가 연결되는지 확인하는 것입니다.
고친 계획을 기준으로 개발하기
계획을 받은 뒤에는 내용을 읽고 빠진 조건을 추가합니다. “휴대전화에서도 써야 해요”, “로그인은 빼 주세요”, “글을 수정하는 방법이 빠졌어요”처럼 구체적으로 말하고, 그 변경이 다른 부분에도 영향을 주는지 확인해 달라고 요청합니다. 설명을 이해하지 못한 항목은 그대로 승인하지 말고 더 쉬운 예를 요청할 수 있습니다.
제가 개발을 시작할 만큼 계획이 정리되었다고 보는 기준은 만들 것과 만들지 않을 것, 사용할 기술의 이유, 저장·공개 방법, 완료를 확인할 방법이 분명해졌는지입니다. 이때도 실제로 만들어 보며 발견할 문제는 남을 수 있습니다. 계획은 한 번 정하면 못 바꾸는 약속이 아니라, 무엇이 달라졌는지 비교할 기준입니다.
방금 수정한 계획을 기준으로 개발을 진행해 주세요.
먼저 첫 단계까지만 만들고, 제가 무엇을 눌러 확인하면 되는지 알려 주세요.
계획에 없는 기능이나 새 유료 서비스가 필요해지면 진행 전에 설명해 주세요.
구현 중 계획을 바꿔야 한다면 이유와 영향을 정리하고 계획도 함께 수정해 주세요.
기존 프로그램을 고칠 때도 같습니다. “수정해 주세요”에 앞서 무엇이 문제인지, 어느 부분을 바꿀지, 기존에 되던 기능 중 무엇을 다시 확인할지를 먼저 정리합니다. 그 계획에서 보완할 부분을 고친 뒤 구현을 맡기면, 결과를 받았을 때 무엇을 확인해야 하는지도 분명해집니다.
마음에 안 드는 결과와 잘못 작동하는 결과
여행 블로그를 원했는데 독서 블로그가 나왔다면 먼저 요청에 여행이라는 조건이 있었는지 살펴볼 수 있습니다. 조건을 말하지 않았다면 방향을 추가하면 됩니다. 이미 말했는데 무시했다면 그 조건을 놓친 것입니다.
게임도 마찬가지입니다. ‘게임 만들어줘’에 레이싱 게임이 나오는 것과, ‘카드 여섯 장으로 만들어줘’라고 했는데 열두 장이 나오는 것은 다른 문제입니다. 전자는 아직 선택하지 않은 부분이고, 후자는 전달한 조건을 지키지 못한 것입니다.
겉모습이 맞아도 실제 동작은 다를 수 있습니다. 카드가 예쁘게 그려져 있어도 눌렀을 때 뒤집히지 않을 수 있고, 같은 과일을 찾았는데 다시 닫힐 수도 있습니다. 다음과 같이 직접 해 보아야 합니다.
- 카드 한 장을 눌렀을 때 그림이 나타나는지 봅니다.
- 같은 그림 두 장은 열린 채로 남는지 확인합니다.
- 서로 다른 그림은 잠시 보여 준 뒤 다시 닫히는지 확인합니다.
- 모든 짝을 찾으면 완료 표시가 나오는지 봅니다.
- 다시 시작하면 처음부터 정상적으로 진행할 수 있는지 확인합니다.
문제를 찾았다면 “게임이 안 돼요”보다 **“같은 딸기 카드 두 장을 눌렀는데 다시 닫혀요. 같은 그림이면 열린 채로 남아야 합니다”**라고 설명하는 편이 수정할 지점을 분명하게 전달합니다.
블로그에서는 사진을 눌렀을 때 맞는 글이 열리는지, 휴대전화에서 글이 잘리지 않는지 확인할 수 있습니다. 화면이 좁아졌을 때 사진이나 글이 옆으로 튀어나간다면 그 상황을 설명하면 됩니다.
사실과 다른 정보를 맞는 것처럼 설명하는 문제도 있습니다. 이런 오류를 ‘환각’ 또는 ‘할루시네이션’이라고 부릅니다. 원하는 디자인을 아직 정하지 않은 상황과는 구분해야 합니다. LLM의 답이 자연스럽다는 것만으로 설명이나 결과의 정확성이 보장되지는 않습니다. IBM의 AI 환각 설명
따라서 결과가 기대와 다를 때는 아직 말하지 않은 조건인지, 말한 조건을 놓쳤는지, 실제로 작동하지 않는지를 나누어 보면 다음 부탁이 쉬워집니다.
바이브코딩의 시작은 원하는 동작을 정하는 일
‘블로그 만들어줘’에서 사진을 누르면 여행 글이 열리는 화면으로, ‘게임 만들어줘’에서 같은 과일 두 장을 찾는 게임으로. 그 사이에 한 일은 어려운 개발 용어를 익히는 것이 아니라, 선택하고 설명하고, 계획을 고친 뒤 결과를 확인하는 것이었습니다.
AI에게 일상 언어로 원하는 동작을 설명하고 코드를 만들거나 고쳐 가는 접근을 넓게 ‘바이브코딩’이라고 부르곤 합니다. 이 연재에서는 작은 결과를 직접 확인하며 만들어 가는 방식으로 접근하겠습니다. 코드를 이해하지 않고 결과를 그대로 믿어도 된다는 의미로 사용하지는 않겠습니다.
LLM은 이 과정에서 요청과 대화 내용을 바탕으로 설명이나 코드를 생성합니다. 실행·미리보기 같은 기능은 사용하는 도구가 지원하는 범위에 달려 있습니다. 그리고 어떤 블로그인지, 어떤 게임인지에 대한 선택은 대화를 통해 함께 정할 수 있습니다.
AI의 도움으로 만든 카드 게임이 실행할 때마다 AI에게 물어봐야 하는 것도 아닙니다. 카드의 짝을 비교하는 정해진 규칙만으로 작동하게 만들 수도 있습니다. AI로 만든 프로그램과, 사용하는 동안 AI를 호출하는 프로그램은 구분할 수 있습니다.
처음부터 완벽한 설명을 준비할 필요는 없습니다. 이렇게 시작해 보세요.
만들고 싶은 것은 있는데 무엇부터 정해야 할지 모르겠어요. 선택할 수 있는 쉬운 예시를 보여 주고, 하나씩 물어봐 주세요.
‘만들어줘’는 충분히 좋은 출발점입니다. 그다음에 어떤 결과를 원하는지 함께 정하고, 실제로 그렇게 되는지 확인하는 과정이 이어지면 됩니다.
VIEW—
