매일매일 gemini cli와 language api 제한에 쫓기며 라노벨 번역과 개발을 지속하고 있다.

‎2025‎년 ‎9‎월 ‎12‎일 ‎금요일, ‏‎오후 7:34:15에 시작해서,
바이브코딩한지 거의 한달이 다되어가는데, 느끼는점이 여러가지 있다.

1. 바이브 코딩은 장점과 단점이 명확하다.

• 장점: 복잡한 코드 리뷰가 필요없는 즉각적인 수정, 코드 레퍼런스를 통해 검색할 시간을 아껴줌, 스니펫으로썬 최적, 모델이 똑똑할 수록 단점이 감소함

• 단점: 이전 맥락을 이해하지 못하고 현재 답변에만 집착해서 기존 기능을 자주 삭제함- 이래서 바이브코딩은 비개발자가 하면 안됨, gemini는 무한루프버그에 지침을 잘 안따라는 문제가 있음, api 일일 제한에 너무 엮임, 솔직히 대규모 프로젝트에서 바이브코딩 하려면 무조건 기업용 필요함, cli 자체의 구조적인문제-웹버전과 비교해서 사용성이 너무 떨어짐, 업뎃후 특정오류 계속됨-ai가 파일작업중 리밋걸려서 빈답변을 내놓은상태로 작업중이면 api오류 걸리며 자체 셧다운됨

그외 등등..

단점이 더 많지만 분명한건 시간을 확실히 아껴줌 내가 이걸 직접 개발하면서 검색하고 연구하고 수정하고 하면 이거의 20배에 해당하는 시간이 걸린다고 생각함

그래서.. 대안이 무엇이냐

2. 그래서 바이브코딩은 현재 구조설계용으로는 적합하며, 세밀한 디테일 수정엔 취약하다

내가 개발자라서 하는말은 아니지만 개발자가 대체되는것보다 고용이 감소하는 정도임 여전히 인간 개발자는 필요함

사실 이 라노벨 번역프로젝트가 끝난다면 살짝 접어뒀던 인공지능 프로젝트를 바이브코딩 "도움받으며"하려함 바이브코딩은 의존하기엔 리스크가 너무나도 크다...

지금 db화가 이루어져서 일본어->한국어 번역 데이터가 좀 쌓이는데 내생각엔 200만 300만건이 필요한데 이제야 2만건이다 하루에 대략 1500~1700건이 쌓이는데 (물론 1건마다 텍스트양은 상이함)
그런걸 고려해도 << 이걸 쓰자마자 오늘치 번역api 제한이 걸렸다 허겁지겁 api 요청 중지하고 다시왔다

암튼 다시 본론으로 돌아가서 그런걸 고려해도 대략 100만 후반대는 있어야 유의미한 일본어 번역에 쓸만한 학습데이터가 될거같다.

오늘같은경우는 1805건이 쌓였는데 전체는 21300건 언저리다 하루에 과대하게 쌓여 2000건 쌓인다고 보면, 만건엔 5일이 필요하고 백만건에는 100일이다 하지만 이미 2만건이 존재하니 대략 3달정도면 되겠지, 그럼 연말엔 이 데이터로 로컬에서 돌아가는 일본어 번역(특히 라노벨 분야에서)이 가능해진다.

암튼,, 이 다음은 ai 이용한 프로젝트가 될거같은데 뭘할지는 백만건에 도달하고 나서 로컬 번역 시도해보고 정해보려 한다

느낀점은 여기까지고, 프로젝트에 대해서 자세히 말해보려한다.

일단 원래는 크롬 로컬스토리지를 쓰는 방식이였다가 리소스 점유율땜에 버벅거려서 서버를 쓰게 되었다.

지금 장기 계획으로는

1. 라노벨 번역후 로컬에서 볼수있는 뷰어시스템 갖추기
2. ocr로 소설 부분만 인식해서 번역하는 시스템으로의 전환- 현재는 페이지소스에서 긁어옴, 다양한 소설 사이트에 대응하지 못하는 문제가 존재함
3. 시스템 상태 볼수있는 섹션 만들기
4. 다양한 세부통계(텍스트)제공
5. 현재 페이지에 조금 더 책같은 ui적용하기
6. more?

가 있는데 서버화를 시켜서 db체제로 가니 훨씬 개발 자체가 재밌고, 직관성도 생겼다.

원래는 그냥 뇌빼고 작업했는데 바이브 코딩을 진행할수록 오히려 공부 욕구를 늘게 한다.

개발 방법론이나 개발 요소들을 다양하게 적용해보고 싶은욕구또한있다.
42mb인 작업폴더인데, 이처럼 다양한걸 할수있다니 역시 개발은 재밌는거 같다.

그래서 api 초기화가 되는 오후 4시까지 다양한 공부를 해보는게 내일부터의 목적이다.