바이브 코딩 2
AI 관련해서는 지수함수적이라는 표현이 그저 비유가 아니라 있는 그대로의 현상을 설명하는 시대다. AI가 AI를 만든다는 충격적인 사실도 지금은 그냥 어, 그래, 그렇구나 하고 넘어가게 된다. AI를 활용한 코딩, 흔히 바이브 코딩이라고 불리는 개념도 불과 십수 개월 동안 그 양상이라고 해야 할지 동태, 흐름, 그리고 사람들의 반응 같은 것들이 그야말로 격변의 격변을 거치는 중이라 뭐라 딱 꼬집어 말하는 게 무슨 의미가 있나 싶다. 아니, 나까짓 게 바이브 코딩을 분석하고 정의하겠다는 의도는 결단코 없고 단지 습관적으로 글을 쓰는 입장에서 다루고자 하는 글감에 대해 짚고 넘어가 보려는 강박 같은 것에 지나지 않는달까.
그리고 어차피 중요한 건 바이브 코딩이 무엇인지는 아닌 것 같다. 그러니까 바이브 코딩이 아니라 빨간색 버튼이라고 불러도 상관없는 거 아닐까. 누르면 콜라가 대령되는 그런 버튼 말이다.
내가 AI에 본격적으로 관심을 가지게 되면서 그중에서도 특별히 주의한 분야는 프로그래밍이었다. 이유는 간단하다. 나에겐 해적왕이 될, 아니 나만의 프로그램을 만들고자 하는 오랜 꿈이 있었기 때문이다. 2025년 즈음까지만 해도 AI를 활용한 코딩, 일명 바이브 코딩(그리고 빨간색 버튼)은 일종의 두쫀쿠에 불과했다고 생각한다. 오픈AI나 그록AI처럼 신모델 출시에 애플식 집착을 하는 기업들은 꼭 원샷 프롬포트와 그 결과물을 자랑스럽게 내어놓는데 가령 이런 것이다.
“슈퍼 마리오 브라더스 게임을 웹 형식으로 만들어줘.”
그리고 실제로(?) AI가 그 요청을 받아서 출력한 수백 줄의 html 코드가 웹브라우저상에서 슈퍼 마리오 게임으로 나타난다. 우리가 평소 접속하는 웹페이지가 다 html 등의 코드로 되어 있고 그것을 사파리나 크롬 같은 웹브라우저가 보기 좋게 번역해 주는 것처럼 말이다. 출시 직후 사람들은 그 원샷 프롬포트를 복사해 가서 자신들의 앱이나 웹을 통해 그러한 신모델들에 집어넣어 본다. 그러면 그 즉시 화면에는 이상하리만큼 사람들이 좋아하는 해커에 대한 판타지가 펼쳐진다. 검은 화면에 형광색 글자들이 우르르 몰려 올라가는 그림을 떠올리자. 사실 그 이미지는 묘한 전율을 일으키기는 한다. 잠시 후 각자의 화면에는 자기만의 슈퍼 마리오 웹게임이 플레이된다. 거대 언어 모델의 특성이자 한계상 모든 슈퍼 마리오는 랜덤하게 다르다. 어느 것은 하늘이 까맣고 어느 것은 버섯 몬스터가 괴상하게 생겼다. 간혹 게임 자체가 버그 때문에 이상해 보이는 경우도 있는데 그게 다 SNS에서 소빗거리가 된다.
나는 사실 그러한 것에 관심이 없었고 그래서 채팅창에 대고 이런 얘기를 주로 했다.
“표정 인식해서 마우스 클릭하게 해줘.”
단순하다고 해야 할지, 아니면 집요하다고 해야 할지, 아무튼 내가 원하는 건 시종일관 같았다. 내가 거의 유일하게 다룰 수 있는 컴퓨터를 좀 더 쉽게 사용하는 것.
내 요청에 AI는 예의 해커 판타지를 실현하고는 그것을 터미널에 붙여넣으라고 알려준다. 나는 AI가 적어준 것을 받아들고 터미널 창으로 간다. 그리고 내심 기대되는 마음으로 그것을 집어넣는다. 또다시 내가 이해하지 못하는 판타지가 눈앞에 펼쳐지고 나면 그다음에는 아무것도 없다. 나는 뭔가를 기다려 보다가 다시 채팅창 쪽으로 가서 묻는다.
“아무것도 달라지는 게 없는데?”
그러면 AI는 핵심을 찔렀다면서 다시 이만큼의 코드 뭉치를 생성해 준다. 그리고 다시 한번 조용히 실패. 그것이 몇 차례 반복되면 나는 채팅창을 끄고 글이나 계속 쓴다. 두쫀쿠를 실제로 먹어보지는 않았지만 먹어본다면 필시 느꼈을 허망함을 느끼며 말이다.
다시 말하지만 이것은 2025년 초의 이야기다. 느낌상 한 십년은 더 된 것 같은데 아무튼 그렇다. 이로부터 몇 개월 뒤 또 다른 신모델과 원샷 프롬포트가 사람들을 유인하고, 나는 다시 또 요청한다.
“표정 인식해서 마우스 클릭하게 해줘.”
놀랍게도, 이번에는 내 컴퓨터에서 무언가가 실행된다. 아주 단순한 창 하나가 떴을 뿐이지만 그것은 꽤 경이로운 경험이다. 나는 놀라움을 안고 AI한테 보고한다.
“무슨 창이 떴어. 근데 표정 인식은 어떻게 해?”
AI는 말한다. 그것은 좋은 징조이니 이번에는 이것을 시도해 보라고 내게 쥐어준다. 근데 혹시나 해서 말하는 건데 내가 지금 무슨 삼류 포스트 아포칼립스 소설을 쓰고 있는 건 아니다. 그렇다고 있었던 사실 그대로 쓰고 있는 것도 아니지만 노파심에 하는 말이다. 다시 본론으로 돌아가면, 이 새로운 시도 또한 뒷맛이 느끼한 단맛을 남기면서 허무하게 끝나기는 마찬가지다. 나는 일기에 적는다. 바이브 코딩이란 다 사기라고. 그게 아니라면 내가 문제거나. 결론은 실패.
2025년(아직도) 하반기가 되면서는 상황이 사뭇 달라진다. 주로 기업을 대상으로 코딩용 AI 서비스를 제공하던 엔트로픽에서 일반 소비자한테도 동일한 서비스를 제공하기 시작한 것이다. 그렇게 쏘아올려진 신호탄이 만들어낸 급류는 이전과는 전혀 다른 방향으로 나아갔다. 오픈AI와 구글 등의 기업들도 앞다퉈 일반 소비자들을 대상으로 AI 프로그래밍 툴을 제공하기 시작했다. 채팅창에 지나지 않았던 앱은 프로그래밍 언어 편집기가 되었다. 접근법은 비슷했다. 원하는 것을 말하면 그에 대한 코드를 작성해준다. 단, 이제는 거기에서 끝나지 않고 AI가 그것을 직접 실행하고 오류가 발생하면 수정해서 다시 실행했다. 될 때까지. 마침내 뭔가가 실행되면 그것은 상반기의 결과물과는 완전히 다른 모습으로 날 반긴다.
나는 내 얼굴이 보이는 프로그램 앞에서 입술을 이렇게 내밀고 저렇게 내밀고 해본다. 투박하지만 내 표정에 따라 변화하는 그래프가 있고 거기에 연결할 액션 목록도 나름 세심하게 정리돼 있다. 나는 조심스럽게 표정 하나에 액션 하나를 연결해 본다. 그리고 표정을 지어본다. 음. 역시나 실패.
고백컨대, 이때쯤의 바이브 코딩은 사기라고 치부할 수 없는 수준이었다. 그저 내가 그것을 제대로 다룰 준비가 안 되어 있었을 뿐. 한창 AI 열풍이 불던 때, 사람들은 자신의 요청에 대한 AI의 답변을 가지고 고개를 갸우뚱했다. 기업들이 주장하는 소위 박사급의 답변이 왜 나오지 않는가? 사기라기엔 정말로 박사급 답변을 받았다는 사람들이 인터넷에 많았다. 결론은 간단했다. 박사급 답변을 받으려면 박사급 질문을 해야 했다. 그 또한 사기라면 사기라고 주장해볼 여지가 있는 거 아닌가 싶지만 아무튼 사람들은 박사급 질문을 하기 위해 공부를 하고 심지어는 돈까지 내고 박사급 질문을 사기도 했다. 나는 몰랐는데 인터넷 초창기에는 검색하는 기술이 너무나도 중요해서 검색만을 전문으로 하는 검색사라는 직업이 존재했다고 한다. 지금의 프롬포트 엔지니어는 말하자면 수십년 전의 검색사들의 후예인 셈이다.
바이브 코딩도 마찬가지다. 정말로 느낌적인 느낌대로 앱을 만들기 위해서는 기술이 필요했다. 하지만 검색 알고리즘이 개선되면서 검색 기술이 더는 중요하지 않게 되었듯이 이제는 박사급 답변을 받기가 초창기 때보다는 쉬워졌다. 그리고 코딩 또한 그 흐름을 이어가고 있다.
나도 점점 달라졌다. 사실 달라지는 게 당연한 게, 그렇게 맨땅에 헤딩하기를 반복하다보면 뭐라도 배우기 마련이다. 나는 실패를 거듭할수록 내가 원하는 것을 구현하기 위해서는 무엇을 어떻게 요청해야 하는지를 감으로 익혀갔다. 그리고 내가 정말로 원하는 것이 무엇인지에 대해서도 보다 명확한 그림을 그려볼 수 있게 됐다. 내가 당장 사용할 만한 기능 한두 개를 구현해내기 시작했고 이제는 ‘앱’이라고 할 만한 뭔가가 껍질을 깨고 정체를 드러냈다. 안드로이드 폰에서 표정 인식으로 액션을 수행하는 ‘미믹이지’, 맥을 쓰는 유저라면 모르는 사람이 없는 PopClip(텍스트를 선택하면 복사나 붙여넣기 등의 액션을 실행할 수 있는 팝업이 뜨는 앱으로 키보드 단축키 누르는 일을 대체한다)을 윈도우용으로 구현한 ‘오비탈’ 등 깃허브라는 코드 공유 플랫폼에 내가 만든, 엄밀하게 말하자면 내가 주문한 프로그램들이 업로드됐다.
그리고 알트키.
나는 이기적이고 개인주의적이라 내가 쓸 만한 앱이 아니면 머릿속으로 구상조차 할 수가 없다(자랑은 아니다). 알트키 또한, 내가 어렸을 때 쓰던 클리키라는 프로그램이 더는 개발되지 않는다는 사실과 그 프로그램에 의지할 수밖에 없는 사람들이 있다는 현실이 계기인 것만은 아니다. 우연히 다시 윈도우를 쓰게 됐고, 옛날부터 나만의 화상키보드를 만들어보고 싶어했고, 운이 좋게 소설가가 되긴 했지만 결국 그 운이 다했는지 일이 없고, 바이브 코딩이 게임만큼 재밌어서 알트키를 만들어보고 싶어졌던 것이다.
알트키의 목적은 명확했다. 한국어 자동 완성 기능이 있고, 복사 붙여넣기 등 단축키를 설정할 수 있고, 키보드 레이아웃도 커스터마이징 가능하고. 딱 애플의 손쉬운 사용 키보드다. 내가 AI한테 처음 요청한 사항도 그것이었다. 맥의 손쉬운 사용 키보드를 윈도우용으로 구현할 것.
사기를 치면 안 되는 시점이 왔다. 내가 알트키를 만들기 위해 AI한테 단순히 “손쉬운 사용 키보드 윈도우용 만들어줘.” 하고 요청한 건 아니다. 대강의 흐름을 나열해 보자면 다음과 같다.
손쉬운 사용 키보드를 벤치마크해서 윈도우용 화상키보드를 만들기 위한 사전 조사를 한다. AI의 딥 리서치 기능은 자료 조사에 있어 문자 그대로 타의 추종을 불허한다. 애플과 마이크로소프트의 개발자 전용 데이터베이스를 뒤져 화상키보드와 관련된 모든 정보를 가져오는데 단순히 복사를 해오는 게 아니라 그것을 실제로 어떻게 활용할지에 대한 구체적인 계획까지 제시해준다.
한국어 자동 완성을 위한 전용 계산기를 설계한다. 내가 어렸을 때 가장 장벽을 느낀 부분이 이거다. 한국어는 영어와 달리 자모를 순서대로 던져댄다고 저절로 단어가 만들어지지 않는다. 물론 한국에서 태어나 자라 한국어를 모국어로 사용하는 우리는 거의 그런 식으로 구사를 하지만 이제 막 한글을 뗀 아이들이 특히 받침을 표기하는 방식을 보면 알 수 있듯 자음의 두 가지 역할을 구분하는 게 꽤나 까다로운 일이다. ㄱ + ㅏ + ㄴ = 간. 이게 컴퓨터에게 그토록 어려울 줄은 정말이지 몰랐다. 하지만 결국은 산수의 문제라 수포자인 내가 아닌 컴퓨터한테는 구현 자체가 불가능하고 그렇지는 않은 듯했다.
이상의 두 가지를 토대로 아주 구체적인 작업 지시서를 만든다. 바로 구현을 할 수는 있지만 작업량이 적지 않아서 어차피 한번에 안 된다. 게다가 작업이 길어질수록 AI는 환각 증세를 겪을 확률이 높아져서 기껏 만든 구조를 한방에 작살낼 수가 있다. 작업은 단위별로 작게 쪼개서 문서화하고 이후에 하나씩 처리한다. 그리고 마지막으로 최종 검토를 시켜 작업 간의 간극을 바로잡으면 일단은 실행 가능하고 작동 가능한 화상키보드가 만들어지는 것이다. 진짜 딱 이대로 했다.
문제는 이후부터였다. 뭐, 레이아웃을 가다듬거나 기능을 추가하는 걸 말하는 게 아니다. 개인이 만든 프로그램의 한계가 알트키에도 여실히 적용됐다. 나만의 화상키보드를 시험해 보던 나는 처음 얼마간 흐뭇해하다가 이내 당황을 금치 못했다. 그동안 크게 신경은 못 썼는데 윈도우의 한/영 상태는 프로그램마다 별도로 작동했다(그러고 보면 맥에는 이것을 강제로 동기화시키는 옵션이 있었다). 예를 들어, 워드 프로세서에서 한글로 글을 치다가 갑자기 딴짓을 하고 싶어 인터넷 창을 열고 검색창에 글을 입력하는 경우다. 아마 영어가 입력돼서 지우고 다시 한글로 검색했던 경험이 있을 것이다. 영어가 입력되면 키보드의 한/영 키를 눌러 윈도우의 한/영 상태를 바꾸고 다시 타이핑한다. 이게 바로 문제의 시작이었다.
일단 현재 윈도우의 언어 상태를 화상키보드는 알지 못한다. 관련 기능이 없는 건 아닌데 화상키보드를 관리자 권한으로 실행한다거나 윈도우 디펜더가 화상키보드를 바이러스로 오인하게 해서 완전히 삭제시킬 수준으로 선 넘는 기능들을 추가해야 했다. 키보드가 한/영 상태를 알아서 뭐하느냐고? 그래야 사용자가 입력하는 문자를 언어에 맞게 조합해서 자동 완성을 할 수 있기 때문이다. 내가 ‘안녕’이라는 단어를 자동 완성시켰는데 실제로 입력되는 글이 ‘dkssud’이라면 그리 안녕하지 못한 기분일 테니 말이다. 그 역도 마찬가지로, 내가 ‘hello’라고 입력한 게 ‘ㅗ디ㅣㅐ’로 사용자 단어장에 저장된다면 참 헬로하지 않을까.
나는 이 문제로 고심했다. 원래는 각 문자 키에 한글과 영어만 깔끔하게 표시하고 한/영 키를 누르면 그 둘이 전환되게 해놨는데 포커스되는 프로그램이 바뀔 때마다 실제 언어 상태와 화상키보드 언어가 달라지는 현상이 발생했던 것이다. 키보드에 괜히 두 언어를 병기하는 게 아니구나 싶었다. 알트키도 한/영 문자를 병기하고 ‘dkssud’이나 ‘ㅗ디ㅣㅐ’ 같은 건 모른 척 넘어간다면 이쯤에서 편해질 수도 있었다. 하지만 윈도우 터치형 화상키보드를 쓰면 한/영 상태 신경 쓸 필요도 없고 한국어 자동 완성도 되는데 ‘dkssud’하지 못한 이 화상키보드를 굳이 써야 할 이유가 있을까? 단축키와 레이아웃 편집 때문에? 다시 말하지만 이 화상키보드는 나도 쓸 거라서 그런 옥의 티는 용납이 안 될 것 같았다. 그래서 나는 굳이 어려운 길을 가기로 했다.
그것이 최선인가 하는 생각은 들지만 그래도 나쁘지 않은 길이었다. 나한테는.