요약

저는 AI Agent, 실시간 시스템, 백엔드 운영이 만나는 문제를 주로 다룹니다.

빠르게 만드는 것보다 오래 운영되는 구조를 더 중요하게 보고, 기능 설명보다 문제 정의와 선택 근거를 남기려고 합니다.

이 블로그는 기술을 자랑하는 공간이라기보다, 실제로 겪은 문제와 선택을 증거와 함께 남기는 작업 노트에 가깝습니다.

기준이 바뀐 계기

개인 메모를 정리하다 보면, 한 문장이 자주 나옵니다.
“제품을 먼저 만들고 고객을 나중에 찾으면 늦다.”

실제로 저도 한동안 제품을 먼저 만들고 나중에 고객을 찾는 방식으로 일했다가, 아무도 원하지 않는 기능에 시간을 많이 쓴 경험이 있습니다. 그 뒤로는 고객이 겪는 문제를 먼저 확인하고, 문제를 작은 단위로 쪼개서 검증하는 방식으로 일하는 기준을 바꿨습니다.

이 변화는 아래 글들과 같은 방향으로 이어졌습니다.
바이브 코딩의 핵심은 감이 아니라 스펙이었다

지금 하는 일

최근에는 실시간 음성 Agent를 운영 환경에서 안정화하는 일에 가장 많은 시간을 쓰고 있습니다. 세션 상태 모델, 비동기 후처리, 장기 맥락 저장/검색 분리, 결제 웹훅 동기화 같은 주제를 반복해서 다듬고 있습니다.
OpenAI Realtime API 운영기 , 장기기억 설계 , 구독 결제 상태 머신 에서 실제 작업 내용을 확인하실 수 있습니다.

그리고 글을 쓸 때도 같은 기준을 씁니다. “무엇을 만들었는가"보다 “어떤 문제를 어떤 제약에서 풀었는가"를 먼저 남기고, 가능하면 운영 기준이나 상태 모델까지 함께 공개합니다.

커리어 여정

일할 때 중요하게 보는 기준

관련 글: Agent 코딩의 경계 · 바이브 코딩의 핵심은 스펙 · 개발은 빨라졌지만 엔지니어링은 여전히 시간의 문제 · Infra→Deploy→Run: 장애 포인트를 줄이는 운영 설계

지금 집중하는 주제 (2026)

대표 글

협업 / 연락