바이브 코딩 3일간의 일지
2026.04.30
회사에서 망할놈에 바이브코딩을 이주동안 해서 결과물을 가져오라고 했다.
최초로 주어진 토큰은 2시간 만에 다 썼다. 다른 계정으로 코덱스를 썼는데 구조를 꽤 만들다가 공모전 마감이 끝나서 아주 초보적인 작업이 완료된 상태로 커밋되었다. 앱이 나왔는지는 잘 모르겠다.
덕분에 바이브코딩 환경 세팅이 다 완료되었다. 코덱스를 설치했고, 공모전을 대비해 찾아봤던 코딩 스킬도 코덱스와 클로드코드에 설치했다.
지금은 완전 바이브 코딩에 중독되었다. 트위터보다 더 재밌다. 레버를 당길 때마다 그림이 바뀌는 파찡코 같다.
원래는 상담사를 따라하는 작은 챗봇을 만들 계획이었다.
그러나 나는 일을 작게 끝내지 못하는 사람이다.
CBT이론을 찾고 몇 가지 시나리오를 정의하는 것 까지는 좋았다. 챗봇을 언어모델 없이 만들기는 쉽지 않다. 하지만 그랬어야 했다. 몇가지 키워드를 트리거로 하고 단순한 3단 시나리오(시작-진행-종료)를 했었야 했다.
시나리오가 5가지였는데, 시나리오 간의 전이의 가지수가 늘어났다. 11가지가 되었다.
시나리오에 대한 사용자 행동 유형을 정의해야했다. 정상부터 고위험까지 5가지가 되었다. 시나리오별로 분류 규칙이 달라질테니 최소 25가지의 사용자 행동 유형 라벨이 생긴다.
행동 유형에 대한 챗봇의 반응을 정의해야했다. 정상부터 고위험까지 N가지가 정의되었다. 행동유형별로 다르게 리액션을 해야하니 최소 25가지의 동작 유형이 생긴다. 여기에 전이 여부를 고려하는 로직이 필요하다.
여기까지 하다보니 서비스가 아니라 상담사처럼 행동하는 하나의 기계를 정의하고 있다는 것을 깨달았다. llm을 사용하지 않는게 문제가 아니라, 챗봇 데이터 관리 솔루션 없이 챗봇을 만들려고 한게 문제였던 것 같다.
CBT이론은 LM Notebook에 수집해 gemini-pro를 이용해 최초의 챗봇 시나리오를 잡았다.
최초의 코드는 openai codex gpt-5.4-mini(medium)을 이용해 작성했다. 여기까지가 현재 배포 버전. 앱 프로젝트에 페치는 했는데 UI가 만들어졌는지도 잘 모르겠다.
이후의 코드를 claude-code로 만들고 있다.
시나리오의 계획은 여전히 gemini-pro lm notebook 대화를 이용하고 있지만, 한국어를 잘 못하는 바람에 대화 템플릿이 엉망이었다.
결국 대화템플릿을 수정하려다가 시나리오 검토까지 chatgpt-pro d에게 맡기게 되었다.
시나리오 아래의 사용자 상태 유형과 동작, 전이 규칙을 하나의 문서로 만들어 코드에이전트에게 맡기기 위해 상태전이표를 claude opus-4.6에게 작성하도록 했고, 이 표를 claude-code에게 전달했다.
gemini에게 시스템 아키텍처와 데이터 구조를, claude-code (ecc skill)에게 실질적인 구현을 시키며 봇을 번갈아 쓰다보니 중독이 안될 수가 없다. 핸드폰에 claude 앱을 설치하고 원격 세션 설정을 켰을때 이미 망한 것이다.
여기에 gemini의 CBT 동작 설계를 chatgpt에게 검토시키기까지 하니 내가 에이전트 어드민이고 하위 에이전트들을 거느리고 있는 것 같다.
에이전트를 설계한다는건 내가 슈퍼 어드민이 된다는걸까? 결국 어드민에 내 사고방식을 주입함으로써 나의 일부분이 자동으로 돌아가게 만드는건가?
아무튼 지금도 집에서 서비스 세 개를 돌리다가 약간 현타가 와서 블로그를 쓴다.
perplexity를 200불 내고 클로드와 제미나이와 챗지피티에게 대화시키는게 시간적으로 더 싸게 먹힐까.
---
2026.05.01
GLiNER2 API를 붙여서 스프린트1을 마무리했다.
역시 사람이 중간중간에 필요한 개입을 해야한다. transfomer 버전이 안맞는지는 사람이 기억하고 있으니까. 그리고 어떤 api reference를 봐야하는지는 모델이 대화로만 기억하고 있기 어려운 것 같다.
---
2026.05.02
과제가 하나 늘었다.
뮤지컬 캐스팅 스케줄을 시각화 하는 것이다.
역할별로 배우가 3명, 2명인데 주요 배역이 4개이다. 총 3*3*2*2 = 36가지 조합이다.
배우마다 선호도가 다르고 꼭 보고싶은 조합이나 피하고 싶은 조합이 있다.
이걸 시각화해서 볼 수 있으면 굳이 스케줄표를 캡쳐 이미지나 표로 가지고 있지 않아도 되겠지.
라는 생각으로 시작했다.
pyplot은 쉬웠지만, 원하던 효과는 아니었다. 대충 다들 골고루 하시는데 차지님이 서편제때문에 후반부 스케줄이 많이 줄어드시는구나 정도 확인할 수 있다.
배역을 카테고리컬하게 표현하기로 했다. 더 알수 없게 됐다.
그러니까 데이터 시각화는 데이터의 문제지 시각화 도구의 문제는 아닌 것이다.
애초에 배우들이 번갈아 출연하는 것이니 어떤 경향성을 발견하기는 어렵고 그러니 패턴이 없어 어지러워보이는건 당연하다. 그러니 이 시각화 도구에는 필연적으로 사용자 요구사항에 따라 선택적으로 데이터를 확인할 수 있는 인터렉션이 필요하다.
또 일이 커지는 것이다.
---
그래서 추천 조합같은걸 만들어주는걸 깃에 올렸는데 배포에서 막혔다.
html 을 만들어서 뿌려야겠다.
---
2026.05.03
생각해보니 사람들은 폰으로 더 많이 볼텐데 그러면 반응형 웹을 만들어야하잖아....
쉽지않다.
---
완전 쉽다. 챗지피티와 모바일로 대화하니까 모바일 반응형으로 바꿔줬다.
근데 웹에서 보는것보다 훨씬 불편해졌다.
쉽지않다.
클로드와 챗지피티를 대화시켜 유아이개선책을 만들었다.
그럼 데스크탑 화면은 어떻게 바꿔야하지?
쉽지 않다.
---
뒤집어 엎었다. 그러나 감동적인 반응.
휴. 하나 끝냈다.
---
끝났다고 생각했는데 결국 방금 끝났다. (github)
사실 아직도 고치고 싶은 부분이 있다. 날짜 필터가 인터렉티브하지 않다.
특정 조합을 선택하면 그 조합의 날짜를 아래 날짜 조회 탭의 시작일이나 종료일로 만들어야되는데 이걸 고려하지 않아서 지금 날짜 없음.. 같은 화면이 나온다.
...버그 아닌가? 버그지. 역시 고쳐야겠다.
삼천포로 빠졌는데 CBT 챗봇은 pioneer API 이용한 분류 결과 테스트 중이다. 내가 API 테스트를 하고 확정한 스키마를 던저줘야할 것 같아서 뭔가 만드는건 멈췄다. 개발상황은 시나리오1개발과 엔드투엔드 테스트 환경을 설정하는 스프린트1까지 완료되었다. UI가 아직 없다. 추론 기록에는 만들었다고 했는데 회사 로컬 컴에 남아있고 하필 원격접속권한을 연정하는걸 잊어버리는 바람에 접속해서 열어볼 수 도 없다. 나름 회사에서 낸 과제인데. 깃에 그럴듯한 뭔가가 올라가있으니 제출됐다고 칠 수 겠지 뭐.
챗지피티로 html을 수정하는 작업은 괜찮긴하지만 compact같은 기능이 없어서 대화가 길어지면 대화 히스토리와 코드 위젯 때문에 세션이 무거워져서 창이 버벅거린다.
근데 이렇게, 프론트의 ㅍ도 모르는데 챗지피티에게 명령만 해서 뭔가 만드는게 의미가 있을까. 사실 내가 원하는 툴을 만든거지만, 내가 쓰면서 괜찮다고 느끼면 충분한걸까? 너무 편리하고 얻는 지식은 아무것도 없어서 바보가 된 기분이다.
---
바보가 된 기분이라면서 gemini에게 UI수정을 맡긴다. 기본 pro챗을 했더니 역시 믿을 수 없이 바보다. notebook LM을 켜서 정보디자인 기본 이론을 넣고 비판하게 한 다음, html을 수정하게 했다. 꽤 그럴듯하고 정확히 동작하는 결과가 나왔다. 디자인은 확실히 전에 만든 것보다 깔끔하고 요즘 것(?) 느낌이 난다.
gemini는 chatgpt에 비해 추론 종료 속도가 빠르다. 그러나 필요한 부분만 고치는 그런 쌈박함은 없다. 그리고 chatgpt와 마찬가지로 코드를 대화창에 늘어놓는다. chatgpt는 코드는 파일로 주고 프리뷰를 화면에 띄우는건데, gemini는 파일 생성 에러가 자주 발생해서 그런지 파일은 안주고 코드만 준다. 코드 안에 데이터와 css와 script를 다 박아놨는데... 코드를 반복 수정하는 시나리오를 전혀 고려하지 않고 창을 무겁게 만든다. 빨리 답변이 나온들 창이 버벅대면 무슨 소용인가.
그러나 빨리 대답하니까 빨리 결과물을 보고 빨리 수정을 요청하게 된다. 속도와 성능의 트레이드오프에서 항상 속도가 이기는 것 같다.
---
생각난 김에 블로그 템플릿 수정을 chatgpt에게 맡겨 본다(실수로 pro플랜을 구독하는 바람에 무제한으로 토큰을 낭비할 수 있다).
---
blogger 템플렛에 익숙한지 내가 원하는 것만 알아서 잘 수정해줬다.
원하는게 그렇게 복잡하지는 않았다. 그냥 행간 늘리고 인덴트 적용하고 포스트 리스트에서 텍스트 요소 변경하는거였다. 오류 없이 금방 됐다는게 만족스럽다.
---
2026.05.04 1:30
결국 버그를 고친다는게 UI도 뜯어고쳤다. 인터파크보단 낫다. 엑셀보다는 보기 편하다. 3일을 들인 것 치고는 소소한 얻음이지만 기획이 얼마나 어려운건지 또 깨달았다. 그리고 화면 기획보다 중요한건 올바른 문제 정의라는 것이다...
---
삼천포에서 헤어나오질 못하고 있는데, pioneer api를 코랩에서 테스트한 뒤 클로드코드에게 줬다. 뭔가 테스트 중이다. pioneer api의 gliner-multi-large-v1은 프리트레이닝 없이 쓰이게는 괜찮은 모델인 것 같다. 속도도 꽤 빠르다. 그런데 도큐먼트가 엉망이라 api reference에 기본적인 요청 스키마도 정의되어있지 않았다. GLiNER2 깃과 예시 API request문을 보고 적당히 때려맞춰서 스키마를 구성했더니 일단 정의된 태스크를 수행한 결과가 돌아왔다(이 요청 스키마도 chatgpt가 써줬다). API reference 찾는데 30분 이상 소요됐지만, 정작 스키마 테스트는 10분 정도 밖에 걸리지 않았다.
제발 아침에 출근해서 회사에 가면 뭔가 답변이 나오는 챗봇UI가 만들어져있기를....
이 프로젝트를 어떻게 마무리해야할지는 잘 모르겠다. GLiNER가 기대한 바를 수행해주지 못할 것 같고, 내가 너무 거대한 시나리오를 짜버려서 스프린트 1개를 마무리하는데도 3일이 걸렸는데 총 스프린트가 4개 정도 나왔다. 그래도 한 달 안에는 되겠는데?
---
댓글
댓글 쓰기