바이브 코딩에서는 언제 갈아엎고 언제 유지보수할까: 내가 정한 의사결정 기준
초기 스타트업 맥락에서 바이브 코딩 결과물을 리라이트할지 유지보수할지 결정하는 실전 기준과 체크리스트.
Engineer Journal
안녕하세요
AI Agent와 실시간 시스템, 운영 가능한 백엔드 구조를 설계하고 구현합니다.
최근 글
전체 글 보기AI에 과의존하면 설계 근육이 줄어든다: 내가 다시 되찾은 사고 루프
AI에게 프로세스 설계를 과도하게 맡겼을 때 생긴 사고력 저하를 인정하고, 설계 근육을 회복한 실전 루틴.
개발은 빨라졌지만 엔지니어링은 여전히 시간의 문제다
바이브 코딩으로 구현 속도는 빨라졌지만 운영 가능한 시스템은 다른 역량이 필요하다는 현장 경험 정리.
Agent 코딩은 왜 결제 시스템에서 자주 무너졌나: 내가 경계를 나눈 방법
코딩 에이전트로 결제/상태 동기화를 구현하며 겪은 기술 부채와, 이를 줄이기 위해 만든 경계 설계 기록.
바이브 코딩의 핵심은 감이 아니라 스펙이었다: 내가 요구사항 문서부터 다시 쓰게 된 이유
바이브 코딩에서 가장 중요한 것은 모델 성능이 아니라 요구사항 명세라는 결론에 도달한 실제 경험 정리.
Discord Interaction을 도메인 상태 머신에 붙이는 법: 중복·역순 이벤트 대응 설계
외부 플랫폼 이벤트(Discord Interaction)를 서비스 세션/상태 모델과 정합성 있게 연결하기 위한 설계 기록.
Discord UI 갱신이 왜 장애가 되었나: 응답 제약과 Rate Limit를 동시에 다루는 설계
빠른 결과 전달을 위해 UI 갱신을 반복하던 패턴이 왜 Rate Limit 리스크를 키웠는지, 운영 이슈 로그와 설계 메모를 바탕으로 정리한다.
장기기억은 저장보다 선택이다: 상태 저장·벡터 검색 분리 아키텍처
대화 누적형 캐릭터 서비스에서 일관성을 유지하기 위해 SQLite 상태 저장과 Vector 검색을 분리한 아키텍처 설계 기록.
캐릭터 일관성을 지키는 4+1 레이어: 프롬프트 초기화 아키텍처 실전
캐릭터 일관성을 유지하기 위해 프롬프트를 4+1 레이어로 분리하고, 사용자/상황 기반 초기화 절차를 어떻게 연결했는지 정리한다.
WebRTC vs RTP/SIP vs WebSocket: 실시간 음성 프로토콜을 운영 기준으로 고르는 법
실시간 음성 서비스를 운영할 때 WebRTC, RTP/SIP, WebSocket 중 무엇을 선택해야 하는지 요구사항과 운영 리스크 기준으로 정리한 글.