라고 묻는다면, 네 그렇습니다.
“가장 핫한 새로운 프로그래밍 언어는 영어입니다.”
오픈 AI 공동 창업자이자 전 테슬라 AI 디렉터였던 안드레 카르파시의 말, 기억나시나요? 지금 보니, 단순한 유머가 아닙니다. 수십 년간 유지되어 온 소프트웨어 개발의 문법이 바뀌고 있다는 선언에 가깝다오 보입니다.
그동안 소프트웨어는 ‘코드를 아는 사람’의 영역이었습니다.
세미콜론 하나, 괄호 하나에 따라 실행 여부가 달라졌습니다. 인간은 기계의 문법을 배워야 했습니다.
하지만 이제는 반대 방향으로 흐릅니다.
기계(인공지능)가 알아서 문법을 처리합니다.
인간은 그저 이제 의도를 설명할 뿐이죠.
위 두 줄이 바로 그 유명한 ‘바이브 코딩(Vibe Coding)'의 핵심입니다. 바이브코딩은 지금 저희가 그냥 이렇게 쓰는 언어(자연어, 즉 프로그래밍 언어가 아닌 일반 언어)로 기능과 느낌을 설명하는 방식의 코딩입니다. GPT에 어떤 의도를 갖추고 입력하면 알아서 AI가 코드를 생성하며, 인간은 결과를 조율할 뿐이죠.
그렇다면 문득 궁금해집니다.
진짜 언어를 다루는 직업, 스토리텔링으로 고객(대중)과 기업 등을 소통하는 PR은 이 변화 앞에서 어떻게 해야 할까요? PR인도 바이브 코딩을 배워야 하나요?
네, 안타깝지만(?) 배우시는 게 좋습니다. 결국, PR팀/홍보팀도 최소화되면서 혼자 앞으로는 1~2인 홍보팀으로 언론홍보, 인플루언서마케팅, 소셜미디어를 모두 직접 진행해야 하는 상황이 올 수 있기 때문입니다.
그뿐인가요. 생성형 AI 덕분에(?) 마케팅팀이 하고 있던 부분도 PR팀이 할 수 있게 되었습니다. 개발팀, 마케팅팀, 디자인팀의 리소스를 사용하지 않고, 이제 스스로 마케팅, 디자인의 기초를 배워서 직접 랜딩페이지를 개발할 수 있습니다. 개발은 생성형 AI에게 바이브 코딩을 시키면 되거든요. 캠페인용 마이크로 사이트, 기자 전용 인터랙티브 리포트, B2B PR의 경우 기능 설명용 데모 페이지 모두 이제 자연어를 기반으로 프로토타입을 만들 수 있습니다.
그래서, 오늘은. 어쩔 수 없이(?) PR인도 배워야 하는 바이브코딩에 대해 알아보겠습니다. 오늘의 자료 역시 연세대학교 심리과학이노베이션대학원 겸임교수이신 박중희 교수님의 2025년 2학기 자료를 바탕으로 구성했음을 밝힙니다.
사실 도입부의 두 줄로 바이브코딩을 설명하긴 역부족이라, 한 번 더 짚고 넘어가고자 합니다. 바이브 코딩은 개발자가 코드의 세부 구현을 일일이 신경 쓰지 않고, 자연어로 기능이나 추상적인 '느낌(vibe)'을 지시하여 소프트웨어를 완성해 가는 방법입니다. 2025년 초 안드레 파파시에 의해 제안된 이 개념은, AI가 고도화됨에 따라 인간의 역할이 '코더(Coder)'에서 '오케스트레이터(Orchestrator)'로 이동했음을 의미합니다.
파파시는 바이브 코딩을 실천하는 두 가지 층위를 제시하는데요,
• Pure Vibe (아이디어 탐색): 코드 한 줄 보지 않고 오직 AI와의 대화만으로 프로토타입을 만드는 단계입니다. 아이디어의 실현 가능성을 빛의 속도로 검증할 때 유용합니다. 우리가 일상에서 GPT를 탐색하는 것을 생각하시면 됩니다.
• 생성형 AI가 보조하여 개발: AI가 생성한 코드를 인간이 엄격하게 검토하고, 테스트를 거치며 품질을 관리하는 실무적 접근입니다. '바이브'로 시작하되, 코드를 볼 줄 알면 더 좋겠죠. 물론, 몰라도 됩니다. 생성형 AI에게 에러를 고치라고 명령하면 되니까요.
결국 바이브 코딩은 앞으로도 소프트웨어 개발의 진입 장벽을 낮추는 동시에, 숙련된 개발자에게는 코드 로직의 노예가 아닌 창의적인 설계자로의 역할로 바꿀 것입니다.
사실 위 소제목에 대한 대답은 저도 알 수 없습니다.
다만, 단순 열풍으로 끝나기엔 이미 바이브코딩으로 만든 어설픈 서비스와 제품이 등장하는 것을 보면 단순 열풍으로만으로는 끝나지 않고 꽤 대중화될 것 같습니다. XR, VR과 다르게 생성형 AI가 점점 대중화된 것처럼 말이죠.
어쩌면 바이브 코딩은 개발 트렌드가 아니라 새롭게 등장한 설계 패러다임일지도 모릅니다. 즉, 단순히 코드를 빨리 짜는 기술이 아니라, 소프트웨어를 설계하는 방식 자체의 변화라고 할 수 있죠.
과거의 개발은 “어떻게 구현할 것인가”에 집중했다면, 2026년 지금의 개발은 코딩하는 언어 그 자체를 습득하기보다는 “무엇을 만들 것인가, 왜 만드는가” - 즉, 설계에 더 방점이 가해지고 있다고 볼 수 있습니다.
바이브 코딩의 기본 구조는 다음과 같은데요,
Describe → Generate → Run → Observe → Refine→...
쉽게 말해, 설명하고, 생성하고, 실행하고, 관찰하고, 개선의 반복 과정이라고 보시면 되는데요. 이 과정에서 가장 중요한 단계는 ‘관찰’입니다. 코드를 읽는 것이 아니라, 결과를 보고 조율하는 것인데요. 디자인이 어색하면 “버튼을 더 둥글게 만들어 달라”라고 요청하는 것, 그리고 생성형 AI가 짠 초안에서 사용자 흐름이 복잡하면 “단계를 줄여 달라”라고 지시하는 것 자체를 말합니다.
어디선가 많이 들어보지 않으셨나요? 이 구조는 PR의 업무 방식과 매우 유사합니다.
메시지 정의→초안 만들기→ 수정 후 콘텐츠 릴리스해서 반응 보기 → 효과 없을 경우 수정하기 → 다시 배포하기→그리고 반복..
어쩌면 PR은 원래부터 현재 생성형 AI를 이용한 업무방식, 즉 ‘바이브 방식’으로 일해 왔을지도 모르겠습니다. (다른 직무도 마찬가지죠. 초안을 만들고 수정하는 반복하는 작업 말이죠.) 다만 이제 그 대상이 보도자료와 콘텐츠를 넘어, 제품과 서비스 자체로 확장되고 있는 것입니다.
AI로부터 최상의 결과물을 얻어내기 위해서는 막연한 부탁이 아닌 전략적인 프롬프트 구성이 필요합니다. 이때 활용할 수 있는 것이 바로 VIBE 프레임워크입니다.
Vision (목표): 만들고자 하는 앱의 궁극적인 목적과 핵심 가치를 정의합니다.
Inputs (자료/제약): 활용할 데이터셋, 기술 스택, 혹은 반드시 포함되어야 할 라이브러리를 명시합니다.
Boundaries (금지/보안): 보안상 민감한 정보의 노출을 금지하고, 특정 코딩 스타일이나 라이선스 제약 사항을 엄격히 지정합니다. "이 API 키는 외부로 유출되어서는 안 돼"와 같은 보안 가이드가 여기에 해당합니다.
Examples (예시): 참고할 만한 디자인 톤, UI 레이아웃, 혹은 선호하는 코드 스타일 예시를 제공하여 결과물의 편차를 줄입니다.
또한, 생성형 AI에게 무작정 코드를 짜라고 시키기보다 스펙 우선의 접근법이 좋습니다. 요구사항과 수용 기준을 먼저 텍스트로 확립한 뒤 생성을 지시하면 훨씬 안정적인 결과를 얻을 수 있습니다. 결과의 일관성을 위해 "JSON 스키마로 출력해 줘" 혹은 "특정 디렉토리 구조를 유지해 줘"와 같이 출력 형식을 고정하는 것도 중요한 기술적 팁입니다.
(JSON이 모르시는 분은 GPT 이용해 주세요^_ㅠ)
앱을 만든다고 생각한다면, 앱을 한 번에 완성하려는 시도는 실패로 가는 지름길입니다.
자연어로 하는 '바이브 코딩'에서는 복잡한 문제를 잘게 쪼개는 능력이 탁월해야 합니다.
• 작은 단위 분할: 페이지, 컴포넌트, 혹은 개별 API 엔드포인트 단위로 독립적인 설계를 진행합니다. 각 부분을 하나씩 완성하고 결합하는 것이 관리 효율성이 높습니다.
• 변경점(diff) 요청: "전체 코드를 다시 짜줘"라고 말하는 대신, "이전 코드에서 로그인 기능만 diff 형태로 추가해 줘"라고 요청해 보세요. 이는 AI가 기존 맥락을 잃지 않게 하고, 불필요한 토큰 소비를 줄이는 가장 효율적인 방법입니다.
• 품질 자동화: AI에게 유닛 테스트나 Playwright를 이용한 E2E 테스트 생성을 지시해 보세요. 자동화된 검증 환경은 '바이브'로 만든 기능이 실제로 '작동'함을 보장해 주는 안전장치입니다.
• 단계적 요청 (Chain of Thought): 여기서도 CoT가 나오죠. 한 번에 열 가지 기능을 요구하는 대신, 논리적 흐름에 따라 하나씩 단계적으로 요청(CoT 적용)하여 AI의 추론 성능을 극대화해야 합니다.
아직까지는 바이브코딩으로 구현하는 것이 어쩌면 더 시간낭비일지도 모릅니다. 다만, 생성형 AI의 성능이 놀랍게 빠르고 또 발전하고 있어서, 바이브코딩을 처리하는 생성형 AI의 역량 역시 단시간 내에 30년 차 개발자가 할 수 있는 수준으로 발전할지도 모릅니다. 바이브코딩의 명암을 알려드리면서 오늘의 포스팅은 마무리하려고 합니다.
1. 보안과 라이선스: API 비밀키는 절대로 코드에 직접 박지 말고 .env 파일로 관리해야 합니다. 또한 AI가 제안한 외부 라이브러리의 의존성을 감사하고, 생성된 에셋의 저작권 문제는 늘 확인해야 합니다.
2. 성능과 비용 관리: 무분별한 프롬프트 반복은 토큰 낭비와 비용 상승을 초래합니다. 토큰 최적화와 효율적인 모델 선택(예: 가벼운 작업은 작은 모델로)이 필요합니다.
3. 유지보수의 흔적 남기기: 나중의 '나' 혹은 동료를 위해, AI에게 주석 작성과 아키텍처 다이어그램 문서화를 병행하는 것이 좋습니다. 코드는 AI가 짰어도, 구조는 인간의 머릿속에 있어야 합니다.
.
.
.
사실, 핵심 메시지는 명확합니다.
"빠르게 만들고, 작게 검증하고, 엄격히 리뷰하자."
(바이브코딩은 참 스타트업과 많은 결이 비슷하네요.)
비개발자도 코딩을 모르고 코딩을 할 줄 알게 되는 시대. 이런 시대일수록 의도를 명확하게 갖고 있어야 하고, 자신이 만든 시스템을 조율하고, 결과를 검증하는 역량이 있어야 합니다. 이 말은, 결국 어떤 영역이든 기초와 본질을 알아야 한다는 것과 일맥상통합니다. 본질과 통찰, 기초가 없으면 생성형 AI의 결과물을 검증할 수도 없고, 무엇이 잘못되었고 고쳐야 하는지도 모르기 때문이죠.
다음 시간에는 구글로 손쉽게 홈페이지를 무료로 만드는 법에 대해 가져오겠습니다.
바이브코딩으로 만드냐고요? ㅎㅎ 다음 주에 바로 보시죠.
글쓴이 카리나는..
글로벌 PR과 콘텐츠 마케팅 분야에서 활동해 온 12년 차 홍보/콘텐츠 마케터입니다. IT, 헬스케어, 유통 산업 전반에서 브랜드 론칭과 리드 전환에 전문성이 있습니다. 스타트업부터 글로벌 기업까지 다양한 조직의 성장을 함께 합니다.
현재 초기 스타트업들의 홍보를 맡은 PR 디렉터이자, 연세대학교 심리과학 이노베이션 대학원 사회혁신 심리트랙에서 심리학을 공부하며, “일하는 마음”의 구조와 번아웃, 회복에 대해 탐구하고 있습니다. PR 전문가로서의 경험과 심리학적 시각을 접목해, 직장인의 정신건강과 건강한 조직문화에 관한 이야기를 글과 영상으로 전하려 합니다.