내가 바이브 코딩을 하면서 느낀 docs의 필요성

 작업 실록을 바이브코딩으로 개발 하면서 중요하게 생각한 것은 기억이다. AI의 기억. 세션이 계속 끝나고, 다시 이어지고, 컨텍스트를 압축시키고 새로운 세션에서 다시 이어가면서, 다른 얘기를 중간에 섞는 순간이 온다면, 프로젝트에 대한 방향성이나 계획이 망가져서 길을 잃을 때가 있다. 

 

 작업을 할 때 방향이나 테스트, 그리고 아키텍쳐 구조나 하드코딩 방법, 전반적인 코드 스타일 같은 것들도 정리하고, 사용하는 스펙 같은것도 정리하고, 같이 결정했던 것들도 여기서 정리하고 그래야 작업 기간이 길어졌을 때, 규모가 커졌을때, 중요한 이슈가 터졌을때, 다음 작업으로 미뤘을때 이어서 하거나 할 수 있었다. 

 

 그러니까 음... 작업 기억이라고 하면 맞을 것이다. 나도 확인이 가능하게끔. 

 

 여기서 중요한 것은 뭐냐면 워크 가이드(작업 방식 및 참고 문서 안내, 문서 업데이트 타이밍과 방식 안내), 플랜, 디버그 로그(잘못했거나 발생한 문제와 원인, 그 해결방법), 업데이트 로그, CONTEXT_NOTE(맥락 노트), 아키텍쳐, Function(앱 내에서 사용하는 함수 설명), PROGRESS, EXPERIENCES(작업중 AI의 경험), 디자인 토큰 등등을 Docs에 작성하면서 작업하라고 하면 좋다. 

 

 보통 작업을 하다가 많은 변경사항과 보완할 사항, 그리고 새로운 결정을 하거나 그럴 때, 일관되게 방향을 잡고 할 수 있게 해준다.  

 

 

 디자인 패키지 쪽에서 보면 같이 정하고, 같이 결정한 사항에 대해서 이렇게 정리를 클로드코드가 한 것들이다. 

 

 나는 이 작업을 하면서 내가 썼던 방식은, 디자인 토큰을 따로 뺴서 디자인의 값을 수정해서 앱 전역으로 한 번에 고칠 수 있게 하려고 만든 거였다. 그리고 다른 디자이너의 디자인을 받았을 때 그 톤을 바로 앱에 적용할 수 있겠다 라는 판단에서 했었다. 글골과 글짜 크기, 곡률과 굵기, 패딩이나 마진 같은 값들도 빼서 작업해달라고 했었다. 하드코딩 하지 말라고 한거였다. 하드코딩.. 

 

 음... 이건 내가 개발을 부트캠프에서 배우고, 프로젝트를 하면서 느낀거였는데, 하드코딩을 하면 일이 너무 불어난다. 간단하게 하나 고치려고 할 때 건드려야 할 곳이 너무 많아지고, 색 하나 바꾸려고 해도 싹다 뒤져서 그 색을 찾아야 했고 글자 크기도 마찬가지였다. 사람이 해도 그런데, 바이브코딩을 했다고 하면, 모든 파일을 다 읽어대야 했을 거고, 그랬다면, 아마도..... 간단한 작업이라고 생각한 것이 토큰 폭탄으로 돌아왔을 것이다. 

 

 바이브코딩을 할 때 문제는 토큰량이다. 토큰 사용량, 그리고 작업의 순서가 되게 중요하다. 최대한 재작업의 여지를 줄이고, 확장 가능성을 열어두는 지시가 필요하다. 그러니까, 앱을 만드는 것은, 한 번 만들고 끝이 아니다. 기능을 확장할 수 있어야 하고, 새로운 모듈을 낄 수 있게 만들어야 한다. 그래야 새로운 기능을 만들고 넣을 때 앱이 망가지지 않는다. 그 부분만 고치도록 하면 된다. 

 

 일단 나는 클린아키텍쳐를 많이 사용하려고 한다. Core와 Features로 나누고, 각 Features에 Domain, Data, Presentation으로 레이어를 나눈다. 

 

 

 각 레이어별로 data는 datasources(로컬 DB나 파이어베이스, Supabase, API 통신 담당), mappers(datasource에서 받은 데이터를 파싱해서 화면에서 사용하는 entity로 전환하는 것), repositories(화면에서 버튼을 누르거나 이벤트가 발생했을 때 데이터를 가져오거나 전송하는데 어떤 데이터소스 어떤 DB와 작업할건지 분배해주는 중간업자 느낌, domain의 리포지토리 인터페이스를 채택해서 쓰는 IMPL이다)가 들어있다. 도메인은 entity(화면에서 쓰는 데이터 모델), usecase(어떤 이벤트가 발생 했을 때 상태값이나 데이터 종류 같은 것들로 분기를 하거나 복잡한 로직이 여기에 들어감, 내가 이해한 것이 맞는지 확인 필요), 그리고 리포지토리가 필요하다. 데이터 단의 리포지토리랑 같은 역할이다. presentation은 화면쪽을 관할하는데 화면을 그리는 것은 스크린, 화면의 상태나 이벤트 처리(CRUD 이벤트), 데이터를 fetch했을 때의 데이터 정리 같은 것들? 을 관할하고, 상태값이 바뀌면 화면을 다시 그리도록 만드는 역할을 한다. 

 

 그러러니까 스크린은 그냥 화면만 그리고, 버튼을 누른다는 그런 이벤트를 받는 정도로, 뷰모델이 자기 메모리에서 데이터를 관리하고, 상태를 관리해서 usecase를 호출하는 식으로 작동한다. 

 

 근데 이렇게 작업을 해야 나중에 어떤 문제가 생겼을 때 파일만 찾아들어가서 확인하고 수정을 해도 다른 기능에 영향을 덜주게 된다. 이런 규칙을 정해놨는데 한 번만 이걸 얘기하고 기억하고 이렇게 하겠지 하면 어떤 줄 아는가? 망각해버리고 자기맘데로 한다. 내가 몇 번 당했다. 그리고 클린아키텍쳐라고 했을때 AI가 생각하는 클린아키텍처가 있는것 같았는데 내가 생각한것과는 구조가 다르더라. 정확하게 작업을 시켜야 한다. 

 

 아, 그리고 이번에 느낀건데 설계를 진짜 꼼꼼하게 상세하게 고민하고 결정해서 작업을 시켜야 한다. 안그러면 전체적으로 리펙토링을 해야하는 경우가 생기고, 그럴 경우 Pro 기준으로 1주일치를 싹 갈아넣어야 하는 경우도 생기고, 테스트며 문제가 생겼는지 점검하는 것도 오래 걸리기에, 일정이 밀릴 가능성이 커진다. 그런 구조를 처음부터 정하고 계속 작업을 했다면? 토큰을 아낄 수 있게 될 것이다. 

 

  이런 구조나 그런 것들은 공부하고 익힐 필요가 있고, 왜 필요하고 왜 쓰는지 알 필요가 있다. 그래야 작업을 할때 좀 더 원활하게 할 수 있고, 앱을 완성시킨다기 보다 나중에 고칠 것을 기본으로 보고 작업을 해야한다. 진짜다 이건. 

 

 재작업 하는 경우도 많고, 개발 방향이 바뀌는 경우도 꽤 많고, 기능을 잠궈야 하는 경우도 생기는데, 그럴때마다 바뀌거나 그런다면 문제가 생긴다. 유지보수에 문제가 생기는데, 그것은 AI도 마찬가지일 것이다. 난 그렇게 생각한다. 그리고 바이브코딩을 하다가 직접 봐야하는 경우에도 작업할 수 있게끔은 해야한다가 내 기본 입장이다. 

 

 이런 것들을 하는 규칙을 정해서 못을 박아두면? 다시 같은 프롬프트를 보내지 않아도 된다. 솔직히 귀찮아서 이렇게 한거다. 귀찮아서. 매번 같은 지시를 계속 보내야한다는게 귀찮아서. 한거다. 개발 방향을 잡고 진행중인데 이런것까지 신경을 쓰기 싫었기 때문이다. 뭐까지 했지? 같은 생각을 하기 싫었고 알아서 하길 바랬다. 그것마저 맡기고 하고있고 시행착오를 겪으면서 진행중이긴 하지만 그래도 얼추 내 스스로 틀은 잡혀가는 것 같다. 지금 단계에서의 내 수준은 이정도라고 할 수 있다. 

 

 물론 더 잘하시는 분들이 많을거고, 컨텐츠로 하고계신 분들, 이미 수익화를 내신 분들도 많을텐데, 나는 음... 이제 시작하는 단계라서 좀 더 작업하면서 방법을 모색해봐야 할 것 같다. 

 

 바이브코딩을 할때, 바이브코딩으로 앱을 만들 생각이신 분들이 계시면 한 번 참고해서 하시는게 맞을 것 같다.