노가다 아재 바이브코딩 3개월, 코딩도 ’노가다'더라

intro

안녕하세요, 노가다 아재 입니다.

처음 올린 게시글 [Gemini와 19일, '터미널'도 모르던 노가다 아재의 Full-Stack AI앱 개발기] 이후

일요일에 올린 [노가다 아재 바이브 코딩체험(EGO 찾기 어플)]까지의 개발 과정을 좀 풀어보려 합니다.

일요일에 올린 게시글은 거의 결과물에 대한 소개와 설명 위주였고, 사실 대부분의 커뮤니티 특성상 사람들이 무슨 앱을 만들었는지는 딱히 궁금하진 않을 것 같아요. 비전공자가 3개월 동안 만든 앱 정도로 대단한 앱이 탄생하긴 힘들기도 하고, 저 또한 한계를 많이 느꼈죠.

그래서 오히려 그것을 만드는 ‘사람’이 노가다 하면서 어떻게 저걸 했는가, 하면서 어땠는가 하는 ‘과정’이 더 궁금해하실 것 같아서 키보드 앞에 앉았어요.

‘과정’을 보고 나면 또 ‘심리’가 궁금할 수도 있을 것 같아서 그건 이다음에 써보도록 할게요.

첫 19일 개발기 게시글 작성(첫 배포) 이전 까지의 이야기는 다음에 풀기로 하고, 그 이후 부터 두번째 버전까지를 위주로 풀어보겠습니다.

어찌 되었던 이 또한 소개글의 일부이니 결과물에 대한 링크를 시작으로 3개월 전의 일부터 시작해보려 합니다.

▶ 두번째 '자기 증명' 부산물 https://ego-coach-lite.vercel.app/

▶ 프로그램 소개 : 노가다 아재 바이브 코딩체험(EGO 찾기 어플)

코딩 비슷한 것의 시작

2025년 8월 31일에 처음 vscode를 깔면서 시작하였으니 불과 3개월 전까지 깃 허브가 뭔지, 터미널이 뭔지, cd는 뭔지 하나도 몰랐습니다. 그래도 스스로의 신념과 중요하게 생각하는 가치, 그리고 내면을 성장시키는 여러 가지 방법론 중에 제가 설계하고 강화해서 gemini와 했던 훈련들을 앱으로서 구현하고 싶다는 마음가짐으로 시작하게 되었습니다.

처음 만들 때는 답답했지만 너무 신기하기도 하고, 조금씩 살을 붙이니 구현되어가는 게 재미있어서 시간 가는 줄 모르고 만들었어요.

일단 저는 본업이 건설업이다 보니 거의 매일 새벽 6시에 숙소에서 나가서 저녁 6시 도착, 직원들과 저녁 먹고 들어가면 7~8시, 새벽 2~4시 취침을 반복하면서 작업하였고

출근해서는 하루에 반 정도는 사무실, 반 정도는 현장에 나가있습니다. 버그 픽스나 로그분석 정도는 모바일 깃허브와 모바일로 Gemini 대화창 켜서 가능하니, 코파일럿을 아직 써보진 않았고, 그냥 크롬 창들만 열어놓고 render, 깃허브(+깃허브 codespaces 기능), vercel, gemini 접속해서 하고, gemini code assist 기능을 사용하는 게 아니라, gemini 대화창에다가 말하고, 코드를 받아서 깃허브에 복붙하는 방식으로 하였어요.

현장에 나가서 담배 피거나, 누군가를 기다리거나, 어떤 작업이 끝날 때까지 애매하게 기다리거나 할 때 잠깐잠깐 빈 시간에 릴스나 쇼츠 대신 안전모 쓴 채로 버그 픽스를 하곤 했습니다.

저의 10년간 노가다 생활은 조만간 시간이 좀 있을 때 게시글로 적어보도록 하겠습니다.

바이브 코딩의 환각:오만

처음에는 19일 개발기 게시글 까지의 결과물이 나오고 나니 들떴습니다. 만들기는 했는데 마땅히 알릴 곳이 없어서 okky에 처음 게시글을 작성하였죠.

이후에는 다음은 뭘 해야 할지 고민하다가, 첫 standard 버전은 진입장벽이 너무 높았습니다. 어플이 사용자에게 어떤 리턴을 주는지도 모르는 상태에서 물어보는 게 너무 많았고, 막상 지나간다고 하더라도 반응도 느릴뿐더러 ux가 개판임을 느꼈습니다.

이후 막연하게 뭘 해야 할지 생각해보다가 약 20일 동안 잠을 거의 못자다 보니 몸 상태가 말이 아니어서 이틀정도 쉬고 9월 21에 lite버전 개발을 시작하였습니다.

시작은 원형만 비슷한 백엔드는 전혀 다른 앱이며, 완전히 다 갈아엎겠다는 마인드로 기존 작동 방식 정도만 남겨두고 완전 개편을 하였습니다.

19일 만에 뭐라도 만들었다는 기분에 들떠서 사실 내심 쉽게 봤나 봅니다. LITE버전으로 만들겠다 하였을 때 한달 정도면 충분할 줄 알았습니다.

물론 처음 개발 과정에서도 몇 차례 갈아엎은 적은 많았습니다. 그 과정 중에 충돌이나 버그가 나도 10~20번 정도 원인 파악하고, 구동해보고 하다 보면 어느샌가 고쳐져 있어서, 이번에도 그럴 줄 알았죠.

바이브 코딩의 환각:현실인지

막상 시작하고 보니 처음 19일 만에 엡을 만들 수 있었던 것은 그냥 기능이 적어서였던 것 같더라고요.

비교적 더 단순하였고, 유저 데이터나 프롬프트가 훨씬 단순해서였습니다.

거기서 문제가 생겼습니다. 전 아무것도 몰랐고, 더 큰 문제는 ‘내가 뭘 모르는지도 모르는 상태’ 였습니다. 메타인지가 좀 부족했나 봅니다.

제가 구현할 수 있을 거라 생각했던 기능은 사실상 LLM에다가 yes or no 조차 요청할 정도로 너무 의존하였고, 유저 데이터를 여러가지 종류를 넣으려다 보니 한 번의 유저 상호작용에 2~3번의 LLM API요청을 기다려야 하는 시간과, 각기 다른 기능들을 수행한 이후, 해당 유저 데이터를 수집하고 정리하는 로직도 복잡해졌으며, 복잡해진 상태로 또 다시 LLM에게 보내니 프롬프트가 너무 길어졌으며, 프롬프트가 늘어날수록 응답시간이 길어졌습니다.

3개 기기 정도로만 동시 작업을 하여도 먹통이 되어버리는 상황까지 발생하였습니다. 며칠간 원인도 모른 체 프롬프트를 최적화하여 줄일 생각만 하고 있었고, 무슨 짓을 해도 고쳐지지 않았습니다.

OKKY의 도움

그래서 okky 유저분들에게 도움을 요청하였고, 우여곡절 끝에 응답시간이 길어짐에 따라 싱글스레드인 node인 것+ api의 기다림이 길어지는 동안 서버가 한 사람에게 물려서 대기하고 있는 문제가 겹쳐, 두세 명만 겹쳐서 요청해도 처리를 못한 채로 응답 자체가 없고, 서버가 다운되어버리는 현상이라는 것을 알았고, 자바 베이스는 멀티 스레드 기능이 기본적으로 있다는 것과, node에서는 pm2기능으로 멀티스레드 환경을 만들어줘야 한다는 것을 배웠습니다.

그 과정에서 나는 아무것도 모르며, 어떤 것을 모르는지 자체를 모른다. 더 많은 기능을 구현하고 싶으면 고수를 고용하던가, 공부를 더 해야 한다. 라는 생각을 하게 되었어요.

원인 해결

그래도 많은 분들이 쉽게 설명해 주셔서 pm2 구현과, 백그라운드 워커로 무거운 작업을 분산하고, REDIS에 담아놓으면, 마냥 기다리지 않고 프론트엔드에서는 1초마다 폴링 로직을 도입해서 구현에 성공하였고, 막상 구현하고 나니 순환 참조, 충돌, 오류, 버그가 엄청나게 튀어나왔어요.

가장 열받았던 건 젬민이는 “자기는 잘못 없으니 render 환경이 문제이다. 재배포해라, console 스크린샷이랑 백엔드log 안 보여주면 못 믿겠다. 그거 안 보여주면 자기는 도와줄 수 있는 것이 없다.”할 때가 가장 화가 났죠.

극복:10년간의 관리 경험을 젬미니에게 적용

처음에는 해당 원인을 찾는 것부터가, 어디서 버그가 났는지를 찾지를 못해서 애먹었는데, 여기서 ‘AI는 신입 직원이다. 모르면 알려줘야지’ 하고 방식을 좀 바꿨어요.

이유는 나의 1회당 토큰 사용이 줄어들수록 오히려 양질의 결과가 나왔습니다. 물론 프롬프트 자체가 줄어든다고 양질의 결과가 나온다기보다는 체감상 대략 50번의 업데이트 약 2일 정도 한 대화창에서 사용하다 보면, ai가 아주 이전에 혹은 몇 시간 전에 말했던 답을 지금 한다거나, 오류가 생기더라고요. 그래서 내가 의도한 바를 정리하고 나면, 다른 대화창으로 새 대화를 만들고 있어요.

여기서 발전한 점이 시작할 때 이해를 먼저 시키고 나면 나의 의도대로 시행할 확률이 높더라고요.

지금까지의 관리 방법은 대화창마다 다른 신입사원이라 생각하며, 신입사원마다 회사(나)의 시스템을 이해를 시키는 것입니다. 저도 10년간 지시하는 직책을 맡고 있었어요. 언젠가부터는 한국말도 못 알아듣는 분들에게 바디랭기지를 포함하여 설명하는 일이 많았고, 역으로 신입사원들에게 나의 원하는 바를 전달하기 위해서는 다양한 스킬을 시도해 보고 그나마 나은 것들을 선택하고 있었죠.

그래서 LLM에게도 적용해 보았습니다. 무작정 ‘어떤 걸 해줘’ 하는 것이 아닌, 시작부터 이건 어떤 거고 저건 저거고, 나는 이렇게 대답하는 것을 좋아하고, 나의 의도를 추측해 보고, 틀린 건 틀렸다 정정해 주고, 최종적으로 어떤 것을 원하니 어떻게 해달라.

지금까지 조금씩 나아지는 방법은 한 번의 프롬프트에서 내가 직접 타이핑한 프롬프트가 줄어들수록 양질의 결과가 나왔습니다. 그리고 로그 분석, 질문, 정보탐색, 해결방법 탐색, 막상 코딩하는 대화창 모두를 각각의 전문가처럼 나누는 것이 더 도움 되더라고요. 쓸모없는 정보가 적을수록 더 나은 결과물이 나왔습니다.

물론 더 좋은 방법이 있을 수 있고, 저도 경험이 더 쌓이거나 다른 방법을 시도하다 보면 더 나은 방법이 있을 수 있습니다. 지금까지의 저의 방식을 설명해 보겠습니다.

일단 백엔드 파일을 모두 공유한 이후에 분석 먼저 시킵니다.

처음 온 신입사원에게 일을 시키지 않습니다. 처음에는 현장 분위기 구경만 하라고 한 이후, 할 일 없으면 도면과 현장 비교하면서 보고 다녀라. 라고 지시하듯 LLM에게도 똑같이 시킵니다.

전체적인 분석 이후, 디테일을 공부 시킵니다.

어느 정도 감 잡았다 싶으면 디테일 도면과 시방서 관련 법률, 지금 해당 공종은 어떤 부분에서 뭘 챙겨야 하는지 한번 봐라. 자료는 내가 보내줄테니 거기서 찾으면 된다. 라고 하듯이 LLM에게 시킵니다.

모든 전체 아키텍처 분석을 시킨 이후, 최종적으로 내가 원하는 것을 말합니다. 어디 어디에서 문제가 있다. 지금 나는 뭐로 추측하지만 너가 생각하는 원인을 5가지 이상 말해봐라. 거기서 가장 높은 확률의 원인을 찾아봐라. 해당 원인을 고칠 수 있는 방법을 알려줘라. 해당 원인을 해결하였을 때, 다른 함수에서 충돌이나 논리적 오류로 인한 api 충돌을 알려줘라. 등등

신입사원에게 일을 알려주듯이 차근차근 큰 아키텍처부터 하나의 함수 혹은 한 번의 상호작용에 의한 디테일 까지 공부시킨 이후에 문제해결을 찾습니다.

그러다 보니 양질의 결과를 뱉을 확률이 높아졌지만, 문제는 오히려 제가 더 알아야 더 일을 잘 시킬 수 있더라고요. 그만한 디테일 지식이 없기 때문에 확룰이 더 낮은 것 같기도 해요.

수용

여러 가지 하고 싶은 것은 더 많이 있었지만. _{최소한의 프롬프트로 최대의 효과를 낼 수 있는 명령어 같은 프롬프트, 고난이도 유저맞춤 기능, 하드 커리큘럼 선택 기능, 현재 Gemini api 답변을 토대로 자체 llm 제작, DB에서 적정 주제 검색 이후 없을 시 API요청 기능, 유저데이터 요약 및 DB 정리 로직, 프론트엔드 애니메이션, 디펜서 역할의 API없는 하드코딩들, 스키마를 따르지 않거나 할루시네이션을 줄일 방법들 등등}

공부하고 배워야 할 게 너무 많았고, 지금으로서 그 정도까지 하려면 올해가 다 가도록 배포 못 하겠다 싶어서 목표를 바꿨어요.

어찌 되었던 유저는 화면에 나온 걸 보니까, 백엔드에서 어떤 일이 일어나던 여러 가지의 필터로 걸러서 유저에게는 티가 안 나도록 하자. 정도로 완성하였습니다.

바이브코딩:코딩도 결국 노가다더라

결국 아직 제가 기능을 사용한 적이 없을 지도 모르지만, 테스트는 제가 직접 합니다. 그것 또한 자동으로 하고 저의 행동 의도와, 행동 그 자체를 자동화한다면 딸깍하면 해결이 가능할 것 같은데, 그것 까지는 아직 못하고 있습니다.

테스트는 제가 직접 하고, 프롬프트도 제가 고치고 그래도 안 고쳐지면 로그 복사해서 붙여놓고, 콘솔 캡처하고, 원인 파악 다시 시키고, 해결 방안 중에 이전에 했던거 제끼고, 등등 충분히 자동화가 가능할 것 같지만 아직 못하더라고요.

이후

그래도 제 마음속에는 미완성이어도 완성은 하였습니다. 업데이트를 하더라도 1.0V이 아닌 2.0V으로 가겠죠. 다른 어플과 마찬가지라 생각합니다.

프로토타입의 반응이 괜찮다면 추후 동숲 같은 느낌의 유저화면과, 여러 가지 기능들을 넣고 싶은 머릿속에 애니메이션처럼 구현되는 기능들은 있지만, 해당 기능을 구현할 때까지의 시간이 조금씩 더 예측되기 때문에 오히려 엄두가 안 나는 것 같습니다.

outro

이렇게 ego lite 소개를 마치며, 다음에는 3개월 간의 기술적이 아닌 내면의 성장, 깨달은 점, ‘심리’를 들고 와보도록 하겠습니다.

해당 결과물 자체가 궁금하신 분이 계시다면 게시글 혹은 어플링크를 찾아주세요.

▶ 프로그램 소개 : 노가다 아재 바이브 코딩체험(EGO 찾기 어플)

▶ 두번째 '자기 증명' 부산물 https://ego-coach-lite.vercel.app/

다른 분들은 몇일짜리 사이드프로젝트로도 만들만한 사실상 챗봇을 거창하게 소개한다는 것은 조금 부끄럽습니다. 있지도 않은 실력을 보여드리는 것은 아닐까? 잠깐 생각도 해봅니다. 하지만 지금 제가 할 수 있는 레버리지가 높은 일 중의 하나이고, 깨달은 점은 혼자서는 할 수 없습니다. 벗이 필요합니다.

지금 책을 하나 쓰고 있는 게 있는데 아마 어플과 같은 목적으로 만들고 있는 책이며, 전자책이 조만간 나올 것 같아요. 제 얘기를 쓰는 책은 아니고, 해당 어플이 책으로 만들어진 느낌 이에요. 1/3정도 썼는데, 그게 이다음 도전일 것 같습니다.

이후에는 revit에 적용하는 tool을 좀 뜯어보고 공부하고 싶은 계획입니다.

저의 행동이 한마리의 잠자리 정도의 날개짓 일지 몰라도,

제 인생에 스스로 부끄럽지 않고 변명하지 않도록, 오늘은 최고의 선택이라 믿고 달려가보겠습니다.

ps. 현업 개발자 선배님들은 이 머리만 좋고 말귀는 못 알아듣는 ‘신입사원(AI)' 다루는 저만의 노하우가 있으신가요? 혹은 지금 젬미니(Gemini)에 의존하고 있고 정이 들었지만, 다른 LLM을 주로 쓰나요? GPT?Claude? 혹은 copoilot기능 들을 추천해 주시면 좀 더 경험해 보고 싶습니다. (지금 젬미니는 고집도 너무 쎄고, 장비 탓이라도 해보려고요) 댓글로 조언 주시면 안전모 고쳐 쓰고 배우겠습니다.