웹사이트, 문의 챗봇, 사내 ERP, 견적서, 계약서, 블로그 자동화.

바이브 코딩 활용 사례를 찾다 보면 전혀 다른 결과물이 계속 나옵니다. 교육 후기를 모으는 페이지도 있고, 파워포인트 대신 브라우저에서 여는 HTML 발표 자료도 있습니다. 퇴근길에 작업을 맡겨 두고 나중에 결과를 확인하는 방식도 사례로 소개됩니다. 이쯤 되면 오히려 막막해집니다.

“그래서 내 일에는 무엇을 만들면 되지?”

사례를 더 모으면 답이 나올 것 같지만 목록만 길어질 때가 많습니다. 홈페이지를 만드는 사람과 강의를 운영하는 사람, 견적서를 작성하는 사람이 쓰는 결과물은 서로 다르기 때문입니다.

이럴 때 결과물의 이름을 잠시 지우고 그 안에서 사람이 하는 일을 보면 공통점이 나타납니다. 저는 『디지털 설계력』에서 일을 여섯 역할로 나눴습니다.

활용 사례가 여섯 개뿐이라는 뜻은 아닙니다. 모든 일이 반드시 이 순서로 움직인다는 뜻도 아닙니다. 하나의 홈페이지에도 여러 역할이 섞이고, 작은 문서 작업에서도 앞뒤 단계를 오갈 수 있습니다. 다만 이 여섯 칸을 놓고 보면 “무엇을 만들까?”보다 먼저 “내 일의 어느 구간을 바꿀까?”를 물을 수 있습니다.

홈페이지와 ERP는 달라도, 하는 일은 겹칩니다

홈페이지는 밖으로 정보를 보여줍니다. ERP는 안에서 업무 상태를 관리합니다. 챗봇은 질문을 받고 답하며, 견적서는 입력한 항목을 계산해 문서로 만듭니다.

겉모습만 보면 서로 다른 기술입니다. 업무 안에서 맡는 역할을 보면 겹치는 부분이 있습니다. 문의 챗봇은 고객의 질문을 받습니다. 필요한 내용을 찾아 답을 만들고, 사람이 읽기 쉬운 말로 전달합니다. ERP는 주문이나 재고 정보를 받고, 정한 규칙으로 상태를 바꾸며, 담당자가 확인할 화면을 보여줍니다. 견적서는 작업 항목과 금액을 받아 계산하고 문서로 전달합니다.

하나씩 뜯어보면 정보를 받고, 고르고, 방법을 정하고, 움직이고, 보여주고, 다시 고치는 일이 반복됩니다.

이 글에서는 이 움직임을 여섯 역할로 나눠봅니다. 보편적으로 증명된 유일한 업무 분류는 아닙니다.

제가 웹핏에서 홈페이지와 문서, 자동화 작업을 하며 복잡한 일을 살펴보기 위해 만든 지도에 가깝습니다.

지도는 목적지가 아닙니다. 내가 지금 어디에 서 있는지 찾는 데 씁니다.

1. 접수·수집: 다음 일에 필요한 정보를 받습니다

일은 무언가를 받으면서 시작합니다. 고객의 문의, 신청서, 설문 답변, 후기, 기존 문서, 판매 데이터가 들어옵니다. 홈페이지 제작에서는 고객의 사업 자료를 받고, 견적서에서는 작업 항목과 수량을 받습니다. 많이 받는다고 좋은 접수는 아닙니다.

홈페이지를 만들 고객에게 “원하는 느낌을 모두 적어주세요”라고만 물으면 긴 답변은 받을 수 있습니다. 그렇다고 누구에게 보여줄 홈페이지인지, 방문자가 무엇을 결정해야 하는지 빠져 있다면 다음 단계에서 다시 물어야 합니다. 수집 화면이나 신청 페이지를 만든다고 가정해 보겠습니다. 먼저 다음 일을 정해야 합니다.

• 다음 단계에서 반드시 필요한 정보는 무엇인가?
• 선택지로 받을 내용과 직접 적게 할 내용은 무엇인가?
• 받지 않아도 되는 개인정보는 무엇인가?
• 답변이 모호할 때 어떤 추가 질문을 할 것인가?

교육 후기를 모으는 페이지도 같은 원리로 볼 수 있습니다. 후기 칸 하나를 만드는 데서 끝나지 않습니다. 다음 강의의 설명을 고치려는지, 수강생이 막힌 부분을 찾으려는지에 따라 받아야 할 질문이 달라집니다. 바이브 코딩은 입력 화면을 빠르게 만들 수 있습니다. 어떤 정보를 왜 받을지는 사람이 먼저 정해야 합니다.

2. 분석·판단: 들어온 정보를 다음 선택에 씁니다

자료가 모였다고 일이 저절로 진행되지는 않습니다. 후기 스무 개가 들어왔다면 반복되는 불편을 찾아야 합니다. 여러 작업 항목이 있다면 견적에 포함할 것과 제외할 것을 나눠야 합니다. 클릭 기록을 봤다면 숫자를 보여주는 데서 멈추지 않고 어느 화면부터 살펴볼지 정해야 합니다. 이때 계산과 해석, 승인을 구분하면 일이 보입니다.

AI는 사람이 놓친 가능성을 펼쳐볼 수 있습니다. 판단의 책임까지 가져가지는 않습니다. 웹핏에서 비즈니스 프로필을 만들 때도 자료를 그대로 옮기지 않았습니다. 사업 소개, 핵심 고객, 고객의 문제, 작동 방식, 지향하는 변화처럼 읽는 데 필요한 내용을 골랐습니다.

실제 성과로 확인되지 않은 내용은 목표로 남기고, 현재 기능과 준비 중인 기능도 구분했습니다. 이 구분이 없으면 보기 좋은 문서 안에 서로 다른 상태의 정보가 섞입니다.

3. 기획·설계: 선택한 내용을 결과의 구조로 바꿉니다

판단한 내용을 어떤 순서와 형태로 보여줄지 정하는 단계입니다. 비즈니스 프로필 작업에서는 고객의 자료를 한 페이지에 모두 넣지 않았습니다. 처음에는 사업이 무엇인지 보여주고, 그다음 핵심 고객과 작동 방식, 고객이 기대할 변화, 사업 철학, 이용 방식으로 이어지게 했습니다.

기존에 쓰던 웹핏 견적서와 함께 전달할 문서였기 때문에 파일의 디자인도 신경 써야 했습니다. 상단선과 색상, 제목 배치, 요약표, 목차를 견적서 양식에 맞췄습니다. 여기서 AI와 코드는 여러 구조를 제안하고 빠르게 시안으로 만들 수 있습니다. 어떤 내용을 앞에 둘지, 무엇을 빼고 어디까지 약속할지는 사람이 정합니다.

기획·설계에서는 기능을 많이 넣는 것보다 사용 장면을 먼저 그려보는 편이 낫습니다.

• 누가 이 결과를 사용하는가?
• 처음에 무엇을 알아야 하는가?
• 그다음 어떤 행동을 해야 하는가?
• 무엇을 넣으면 오히려 헷갈리는가?
• 어디에서 사람이 다시 확인해야 하는가?

이 질문에 답하면 홈페이지인지, 문서인지, 작은 내부 도구인지도 자연스럽게 좁혀집니다.

4. 실행·운영: 정한 방법을 실제로 움직입니다

설계가 끝나면 결과물을 만듭니다. HTML을 작성하고, 데이터를 저장하고, 문서를 생성하고, 상태를 바꾸는 일이 실행에 해당합니다. 같은 작업을 반복해야 한다면 정해진 조건에서 다시 돌아가도록 만들 수도 있습니다.

비즈니스 프로필은 HTML로 제작했습니다. 실제 사업 자료를 넣고 화면의 구성과 문장을 고쳤습니다. 요청받은 내용이 바뀌면 작업 파일을 수정하고 전달용 파일도 최신 내용으로 갱신했습니다. 여기까지는 바이브 코딩으로 결과물을 만든 과정입니다. 장기간 운영되는 자동화 시스템을 구축했다는 뜻은 아닙니다.

이 구분이 필요합니다. 코드를 한 번 실행해 문서를 만드는 일과 새로운 자료가 들어올 때마다 자동으로 처리되는 운영 시스템은 다릅니다. 후자는 시작 조건과 저장 위치, 실패했을 때 멈출 지점, 재실행 방식까지 정해야 합니다.

작동하는 화면을 만들었다고 운영이 끝난 것도 아닙니다. 실제 업무에서 반복해 사용할 수 있는지, 정보가 바뀌면 누가 고치는지, 오류가 나면 어디부터 확인할지까지 정해야 운영이 됩니다.

5. 설명·전달: 사용할 사람에게 맞게 보여줍니다

결과를 만들었어도 상대가 이해하지 못하면 일이 끝나지 않습니다. 비즈니스 프로필을 HTML로 만든 이유도 전달 방식에 있었습니다. 고객이 브라우저에서 바로 열어볼 수 있고, 화면이 작아져도 읽을 수 있으며, 필요하면 인쇄하거나 PDF로 저장할 수 있게 하려 했습니다.

개발자에게는 기능 목록이 중요할 수 있습니다. 고객에게는 이 서비스가 누구에게 필요하고 어떤 순서로 작동하는지가 먼저입니다. 같은 내용도 사용하는 사람에 따라 앞에 놓을 정보가 달라집니다. 웹사이트, 챗봇, HTML 발표 자료가 모두 설명·전달에 쓰일 수 있습니다. 그렇다고 같은 도구는 아닙니다.

• 웹사이트는 방문자가 스스로 정보를 찾아 선택하게 합니다.
• 챗봇은 들어온 질문에 맞춰 필요한 답을 꺼냅니다.
• HTML 발표 자료는 발표자가 정한 흐름에 따라 내용을 보여줍니다.

도구보다 먼저 상대가 결과를 만나는 순간을 살펴야 합니다. 무엇을 알고 들어오는지, 어디에서 헷갈릴지, 다음에 무엇을 해야 하는지가 전달 방식을 정합니다.

6. 평가·개선: 확인한 결과를 다음 작업에 남깁니다

비즈니스 프로필을 만든 뒤에는 화면을 다시 확인했습니다. PC 너비와 모바일 너비에서 가로로 넘치는 부분이 없는지 살폈습니다. 목차 링크가 제대로 이동하는지, 인쇄 버튼이 작동하는지, 화면에서 오류가 발생하지 않는지도 확인했습니다. 수정된 작업본과 전달용 파일이 같은지 파일 해시도 비교했습니다.

이 검수는 결과를 좋다고 평가하는 말과 다릅니다. 무엇을 확인했는지 항목으로 남겼기 때문에 다음 수정에서도 같은 기준을 사용할 수 있습니다. 실제 작업을 여섯 역할에 놓으면 다음처럼 보입니다.

하나의 HTML 문서를 만드는 일에도 여섯 역할이 함께 들어 있었습니다. 매번 여섯 개의 도구를 따로 만들 필요는 없습니다. 어디가 가장 자주 막히는지 찾아 작은 구간 하나부터 바꾸면 됩니다.

오늘 반복한 업무 하나를 적어보세요. 무엇을 받았는지, 받은 것을 어떻게 골랐는지, 어떤 방법으로 처리했는지, 누구에게 어떻게 전달했는지, 마지막에 무엇을 확인했는지를 한 줄씩 적으면 됩니다. 빈칸이 생기거나 같은 행동을 계속 반복하는 곳이 보일 겁니다. 그곳이 바이브 코딩을 시작할 자리입니다.