바이브 코딩에서는 언제 갈아엎고 언제 유지보수할까: 내가 정한 의사결정 기준
초기 스타트업 맥락에서 바이브 코딩 결과물을 리라이트할지 유지보수할지 결정하는 실전 기준과 체크리스트.
Blog
문제 정의와 해결 과정을 기록하는 블로그
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 중 무엇을 선택해야 하는지 요구사항과 운영 리스크 기준으로 정리한 글.
결제 성공보다 어려운 것: 쿠폰·웹훅·권한 동기화를 상태 머신으로 푼 방법
월 구독 결제를 운영 가능한 구조로 만들기 위해 결제 이벤트를 상태 머신으로 모델링하고 쿠폰/웹훅/권한 동기화를 설계한 기록.
OpenAI Realtime API 운영기: 세션 복구와 비동기 후처리를 먼저 설계한 이유
OpenAI Realtime API 기반 음성 Agent를 실제 서비스로 운영하기 위해 세션/상태/실패처리를 먼저 설계한 기록.
LangGraph로 운영 가능한 에이전트 만들기: 상태 전이·체크포인트·재시도 설계
툴 호출과 워크플로우 분기를 운영 가능한 구조로 만들기 위해 LangChain/LangGraph로 오케스트레이션을 설계한 기록.
모놀리식 관제를 분해한 이유: AWS IoT + Firehose + OpenSearch 파이프라인 설계
모놀리식 관제 서버의 병목을 해소하기 위해 AWS IoT Core, Data Firehose, Lambda, S3, Elasticsearch로 파이프라인을 분리한 설계/운영 기록.
JPEG-over-WebSocket에서 탈출: 로봇 영상을 WebRTC SFU로 1초 지연까지 줄인 설계
JPEG-over-WebSocket 구조의 지연 문제를 해결하기 위해 GStreamer, WebRTC SFU, Ant Media Server, AWS를 조합해 저지연 스트리밍 경로를 설계한 기록.
FluentBit를 로봇 쪽으로 당기다: ROS 통합으로 전처리 비용 줄인 운영 설계
수집 파이프라인 전처리를 로컬로 이동해 서버 부담과 비용을 줄이기 위해 FluentBit를 ROS 환경에 통합한 설계 기록.
이력서는 주장, 기술 블로그는 증거: 엔지니어 경력 문서화 전략
이력서와 포트폴리오가 전달하지 못한 핵심 문제를 정의하고, 문제 해결 경험과 가치관을 블로그로 증명하는 방식.
로봇 음성 스택을 플러그인으로 분리하기: STT/TTS 교체 비용 줄이는 아키텍처
현장 환경에서 음성 인터랙션을 안정적으로 운영하기 위해 STT/TTS/디바이스 제어를 플러그인 아키텍처로 분리한 기록.
GStreamer는 정상인데 왜 수신이 실패했나: 로봇 WebRTC 장애를 경계로 분해한 디버깅
GStreamer 송신은 정상인데 서버 수신에서 막히는 문제를 SRTP, Transport, 서버 정책 경계로 분해해 원인을 좁혀간 트러블슈팅 기록.
완전 TDD 대신 테스트 가능성: 로봇 Agent를 운영 가능한 코드로 만드는 원칙
완전한 TDD가 어려운 환경에서도, 테스트 가능한 구조와 배포 프로세스를 먼저 설계해 운영 리스크를 줄이는 방식.
Infra→Deploy→Run을 하나로: 복구 시간을 줄인 Observability-First 운영 설계
실시간/결제 서비스에서 장애를 줄이기 위해 배포 이전에 관측·실패처리 중심으로 운영 구조를 만든 기록.
EC2 단일 서버에서 ECS로: 로봇 관제 API를 안전하게 마이그레이션한 기준
운영 규모 확장에 맞춰 EC2 단일 서버 구조를 ECS 기반으로 전환하고, JS→TS 마이그레이션과 테스트 도입을 병행한 기록.
로봇 GPT 응답 지연 줄이기: 컨텍스트 계층화와 임베딩 캐시 운영 기준
로봇 상태 기반 대화에서 지연과 비용을 줄이기 위해 컨텍스트 계층과 임베딩 캐시를 결합한 아키텍처 기록.
ROS와 인증을 분리하다: 디바이스 등록 CLI로 복구 시간을 줄인 설계
인증서 등록 로직을 ROS 런타임에서 분리해 장애 복구와 배포 자동화를 가능하게 만든 구조 설계 기록.
가입 이벤트에서 디바이스 인증서까지: AWS IoT Core + Lambda 온보딩 파이프라인
수동 연결 중심 로봇 세팅을 이벤트 기반 자동화로 전환하기 위해 Webhook, Lambda, Fleet Provisioning을 연결한 설계 기록.
앱 서버 병목을 끊다: MQTT 브로커 분리와 선택 기준 재정의
실시간 로봇 메시징을 앱 서버에 집중시켰을 때 발생한 병목을 기준으로, MQTT 브로커 분리와 선택 기준을 다시 정의한 의사결정 기록.
기술 선택 전에 고정해야 할 것: 로봇 관제 실시간 메시징 요구사항
메시징 기술 선택 전에 반드시 고정해야 할 전달 보장, 지연 허용치, 재연결 정책을 요구사항 관점에서 정리한 기록.
수동 등록을 끝내다: AWS IoT Fleet Provisioning + X.509로 로봇 온보딩 자동화
수동 등록 중심의 로봇 온보딩을 AWS IoT Fleet Provisioning과 X.509 기반 자동화로 전환하기 위해 정의한 문제, 제약, 의사결정 기록.