코딩 손 놓은지 2년된 사람의 바이브 코딩 모험기

서론

블로그 글이 대부분 프로그래밍인 것과는 대조적으로 나는 코딩을 한지 몇 년 되었다. 마지막으로 내 손으로 직접 코딩한 게 업비트 코인 자동 거래 프로그램을 다시 구현할 때니까... 24년 여름쯤에 짠 게 마지막이다.

 

이유는... 통신공-네트워크 엔지니어라는 42서울에서 열심히 배운 것과 전혀 다른 루트를 탔다거나... 등등 여럿 있지만, 이건 결과이고, 가장 큰 원인은 불면증이었다. 코딩을 하면 알 수 없는 불면증에 시달려서, 관련 직군에 오래 근무하면 정신병자처럼 살다가 못 견디고 퇴사하는 삶의 반복이었다. 

 

그래서 병원가서 불면증 약도 타먹어 보고, 힐락의원이라고 대체치료 전문 병원도 다녀봤지만(수액 라인 빼는지도 모를 만큼 깊게 잠잔적도 있음) 도저히 정확한 원인을 알 수 없었다.

코딩을 그만둔 뒤에 깨달은 놀라운 사실은... 불면증의 원인이 바로 코딩 그 자체였다는 사실이다. 

 

몰입하다 보면 가끔 잠이 오지 않는 경우가 있다. 대개는 많은 아이디어가 떠오를 때다. 늦은 시간에 아이디어가 떠오르면 뇌가 흥분되어서 잠이 안 온다. <몰입: 100쇄 기념 합본 에디션>, 황농문

 

이게 뭔 이상한 소리냐 싶겠지만, 나도 책만 읽으면서 자다 깨다를 반복하는 백수의 삶을 즐기다가 이 문구를 보고 소스라치게 놀랐다. 의자에서 50cm는 뛰어올랐던 것으로 기억난다.

 

나는 프로그래밍을 하면서 떠오르는 아이디어는 많은 주제에, 구현력은 한참 모자라서 늘 일정 이상의 태스크가 머릿속에 남아있고, 거기에 계속 아이디어가 추가만 되고 빠져나가질 않으니 밤에 누워서 구현 방향 생각 + 아이디어 생각만 하다가 잠에 못 자는 것이었다.

 

어쨌든 그래서 프로그래머의 꿈을 접고 이곳저곳을 돌다가, 코딩과 아무 상관없고 일의 종결이 확실한 네트워크 직군에서 일을 하게 된 것인데, 최근에 갑자기 회사에서 코딩 업무를 맡게 되었다.

 

 

갑자기 돌아온 코딩 업무

새로 맡은 업무는 사내에서 보유 중인 매뉴얼을 빠르게 검색할 수 있게 도와주는, 로컬 LLM을 이용한 작은 파이프라인이었다. 규모도 그리 크지 않다고 생각했고, 로컬 LLM에 대해서나 RAG에 대해서나 공부해 볼 수 있는 기회라고 생각해서 맡게 되었다. 

 

특히 AI 공부하려고 로컬 머신이 돌아갈만한 3090TI 박힌 PC를 김해까지 왕복 6시간 반을 운전해서 230만 원에 사 올 정도로 열의에 가득 차 있었기 때문에, 내가 원하는 프로젝트를 시작하기 전에 해볼 만한 프로젝트라고 생각했다.(항상 재밌어 보여서 나서서 시작하고, 후회하면서도 어떻게든 끝을 보는 삶의 반복입니다...)

 

정말 마음에 들어서 블로그에 두번째 쓰고 사내 교육 자료에도 넣은 그림

 

코딩을 안 하고 살았다고는 말했지만, 회사 생활에서 필요한 자료를 만들 때나 개인적으로 필요한 것들은 파이썬 프로그램으로 종종 작성을 했다. 당연히 내 손으로 짠 건 아니고, LLM에게 맡긴 다음 잘 나오나 확인하면 끝나는 정도로 살다가, 이번에는 그래도 파일 하나짜리 프로젝트는 아닐 것 같아서 바이브 코딩 툴을 사용해 보기 시작했다.

 

claude code를 처음 사용하자마자 와... 이래서 다들 이걸 쓰는구나 하고 놀랐다. 클로드의 코딩 속도가 내가 생각을 정리하고 말하는 시간보다 빨랐다. 설계를 완성하지도 않았는데 구현이 끝나있는 듯한 기분이었다. 목요일에 클로드 코드 한번 써보고, 금요일 오후에 시작해서 토요일 오전에 대충 완성했다. 구현 시간은 중간에 잠든 시간 빼면 한나절?

 

물론 어디다가 내놓을 수는 없는 PoC 혹은 MVP이었지만, 그래도 질의 튜닝도 해보고... 이런저런 학습의 계기가 됐다. 팀원들에게 써보라고 던져주고는 바로 다음 버전 제작에 착수했다. 

 

 

첫 바이브 코딩의 교훈과 버전 업 시도

가장 중요했던 건 설계의 필요성이었다. 이런 걸 만들고 싶어라고만 하고 바로 시작하니, 리모델링을 하고 싶다고만 말했는데, 갑자기 누가 달려들어서 벽지 붙이고 있는 걸 구경하는 기분이었다. 실제로 나의 의도가 반영되었는지도 알 수 없는 상태로 코딩이 진행됐다. 

 

그래서 다음에는 첫 대화를 plan mode로 시작해서 차분히 내가 원하는 것을 다 말한 뒤, 뭔가 생각났던 대로 기능을 덧붙여서 시작했다. phase와 task를 나눠서 콘텍스트를 관리하고, TDD를 이용해서 개발하고, codex cli를 켜서 리뷰를 진행하면서 blind spot을 없애고, merge 전에 나에게 반드시 구현내용을 설명하고 merge를 허락받게 하는 게이트를 만들면서 본격적으로 개발을 시작했다.

 

클로드 코드에서 코덱스를 직접 부를수있는 MCP가 있다는걸 모르던 시절엔 md 파일을 만들었습니다.

 

그렇게 두 개의 바이브 코딩 툴을 번갈아가면서 일을 시키다 보니 이걸 자동화할 수 있지 않나? 하는 욕심이 생겼다.

 

사실 남들은 다 아는 거라서 관련 도구가 있는지 조금 찾아봤으면 좋았을 텐데...

 

 

야크 털 깎기의 시작

출처는 https://brunch.co.kr/@lesstif/4

 

방금 내가 자연스럽게 생각해 낸(그리고 사실 다른 사람들은 다 좋다고 알고 있던) 이 규칙이 잘 동작한다는 걸 느낀 다음, 이걸 도구화하려는 시도를 했다. '지금 빠르게 도구화를 하면 원래 작업도 개발 시간에 쓴 만큼 빠르게 진행할 수 있고, 다음에 내 프로젝트를 할 때 가져다 쓰면 되니까 개이득이잖아?' 이러면서.

 

지금 작업을 마무리하고, 얻은 교훈을 정리하기 위해 시작했으면 더 좋았겠지만... 그땐 이게 더 좋은 선택처럼 느껴졌어요. 그래서 토요일 밤에 시작한 작업을 화요일 새벽까지 이어서 하고, 화요일에 일하러 가서도 클로드가 잘 구현하고 있는지 틈틈이 확인하다가 화요일 저녁에 머리를 식히려고 튼 유튜브 영상이 이 구조를 설명하고 있었습니다...

 

머리가 식는 건지 뜨끈해지는 건지 알 수 없는 감각 속에서 화요일 밤에 프로젝트를 폐기하고, 설계 의도 정도만 남겨서 claude.md 파일에 넣고, 적절한 플러그인과 MCP의 조합으로 의도한 규칙을 전부 완성한 다음, 원래 개발하던 걸로 돌아와서 다시 시작했다.

 

 

현재 워크플로우와 개발 상황

이러한 '바퀴의 재발명' 끝에 정립한 나의 워크 플로우는 다음과 같다.

 

claude code 실행 - codex MCP 확인 - 설계부터 시작 -  전체 작업을 phase / task 별로 분해 - 병목 지점 먼저 개발 -

 

각 phase 별로 워크트리를 분리하고 sonnet 서브 에이전트 실행 - task 별로 브랜치를 나누고 기획/테스트 제작 요청 - lead 인 opus 가 기획 의도를 나에게 물어봐서 구체화해서 문서로 남기고, 그걸 테스트로 남김 - 서브에이전트가 명세를 보고 테스트를 보강한 다음 개발 시작 - 개발 완료 후 새로운 codex 열어서 검사 - 문제 없을 시 lead 에게 완료 보고 - opus 가 개발 내용과 전체 코드를 검수한다음 문제가 없을시 merge 후 다음 작업 지시 -

 

전체 종료 시 opus와 codex 가 전체 코드를 free scan 하면서 버그 / 보안 이슈 확인 - 문제없으면 배포

 

 

이렇게 말을 하면 복잡하지만, 한 번만 제대로 굴러가는 걸 보면 그다음부터는 거의 보지 않아도 알아서 진행된다. 필요하면 telegram bot 하나 만들어서 한 시간에 한 번씩 보고하고, 유저 확인 사항 있을 때 부르라고 해도 되고요.

 

출처 : 구글 ai 개요

 

이런 식으로 만들고 나서 가장 큰 문제는, 첫 버전에 비해 기능이 지나치게 커진 것 같다는 점이다. 내가 구현을 할게 아니니까 필요한 기능을 막 던져놓고 정확히 어떻게 구현이 됐는지는 모르는 상태에서 완성이 된다는 아쉬움이 있다.

 

그리고 다음 문제는 리뷰 루프가 끝없이 길어진다는 점이다. PR 제목 하나는 planner round 4: artifact contract + Codex 18 rounds + Lead audit이다. Codex 리뷰만 18회. 이건 솔직히 좀 많이 이상한 숫자다.

물론 이건 내가 당시 구조가 지금처럼 정립되지 않았기 때문에 벌어진 일이지만, (소넷에게 개발을 시키고 codex의 지적사항을 같은 소넷이 처리하면 코드를 잘 아니까 금방 고칠 거라고 생각함. 그런데 그게 아니라 리뷰한 codex 가 직접 고치는 게 더 빨랐음) 내가 직접 코드를 안 읽으니까 리뷰어가 OK 할 때까지가 이 코드의 품질 기준이 되어버리기 때문에 이런 일이 벌어져도 막을 수가 없었다.

 

 

결론

처음으로 돌아와서, 왜 내가 예전에 코딩만 하면 불면증이었는지 다시 생각해 보면, 그때 내 머릿속엔 항상 '하다 만 무언가'가 있었다. 구현력이 모자라거나, 시간이 모자라거나, 다른 일에 밀려서 끝까지 못 간 아이디어들이 계속 쌓였다. 아이디어가 들어오는 속도는 빠른데 나가는 속도가 느리니까 누워서도 머릿속에서 계속 굴러다녔다.

그런데 지금은 일정 부분 수면 시간을 확보할 수 있다. 구현하는 속도가 압도적으로 빠르기도 하고, 모든 할 일이 명시적으로 기획으로 완성되어 있고,  자고 있는데도 구현/리뷰가 이루어지고 있단 생각에 마음 편히 잘 수 있었던 것 같다.

다만 그래도 수면 시간이 부족했던 부분은 있다.  내가 토큰 관리를 잘못해서 사용량이 떨어졌을 때 사용량이 돌아오는 시점에 알람을 맞추고 두 시간 자고 돌아오고... 하지만 순수하게 구현이 진행되는 게 재미있어서 구경한 적도 있다. 

몇 주동안 정말 많은 걸 배우고 체화했다고 생각하지만, 이걸 계속 지속할 수 있을지는 아직 잘 모르겠다. 사실 지금 완성한 프로젝트 혹은 워크플로우도 뭔가 맘에 안 들면 고치려 들지 않을까? 아직 배포 전인데 부디 잘 동작하길...