Event Streams를 앞두고 잡담

 
Celery와 RabbitMQ를 중심으로 잡다한 테크닉들을 덧붙여 SSE 버전 Scan API 첫 구현 및 부하 테스트를 마쳤다.
누군가에겐 기술 부채로 느껴질 수 있지만.. 그렇게 소비되지 않기 위해 실시간 시계열 데이터와 테스트, Opus가 함께하는 중이다.
이번 작업은 큐잉 및 비동기를 활용해 에이전틱의 표준 UX인 SSE 방식을 이코에코에 부분 도입하는 과정이었다.
큐잉이 마련된 만큼 비즈니스 앱 레이어와 Persistence 레이어(주로 RDB, Postgre다.)의 분리도 함께 시도했다.
메트릭을 뽑아보며 든 생각이지만 LLM 파이프라인의 태스크를 큐잉 체인으로 관리하는 건 그다지 효율적이진 않다.
작업기에서도 밝혔지만 Redis Streams로 RabbitMQ 및 Scan API SSE 동시 접속 연결부하를 해결하면 LangChain/LangGraph로 전환할 생각도 가지고 있다. 그렇게 되면 Celery의 역할이 기존 태스크별 체인이 아닌, run_id 단위의 LLM 체인을 큐잉하는 역할로 변경될 수 있다. 파이프라인과 오케스트레이션의 분리, 현재는 파이프라인 단위가 아닌 태스크별로 큐잉 오케스트레이션 중인 상황이다.
 

고도화를 할 때마다 느끼는 건 결국 돌고 돌아 표준으로 향한다는 점이다. 초반부에 '우리의 수준에 맞지 않다.'라고 도입을 반려해도 결국 시스템을 디벨롭하다보면 기존 툴들만으로 생기는 불필요한 복잡성과 병목 지점이 데이터로 찍히니 종착지는 비슷해진다. 그 도메인에서 가장 가볍고 앞선 프레임워크로 향하게 되니 이런 중간 과정이 무슨 의미가 있나 싶다. 개인의 학습과 성장을 제외한다면 말이다.
테크 기업은 언제나 개인의 경험과 학습, 퍼포먼스를 우선시하는 점을 앞세우지만 마냥 그런 건 아니다. 한국에선 저 캐치 프라이즈가 조금 왜곡돼서 '저렴한 가격에 유사한 경력이 있는 분을 모시고 싶다.'로 변질된 면도 있다. 그덕에 ChatGPT 출시 3주년인 상황에도 5년차 에이전틱 앱 개발자 공고가 보이는 아이러니함도 함께 한다.
아무튼 디벨롭의 끝이 엇비슷해진다는 건 비단 에이전틱 웹앱 뿐만 아니라 프론티어 모델 개발사도 마찬가지이지 않을까.
Anthropic(다른 모델에 비해 Claude 계열 모델이 생산하는 코드의 품질이 도드라지는 건 놀랍다.), OpenAI, Google / 중국 오픈소스 모델의 출시 주기와 퍼포먼스가 엇비슷하게 나아가니 '트랜스포머 구조 뿐만 아니라, 레시피도 유사하다.'는 의견들이 나올 법도 하다.
물론 난 모델들에 대해선 잘 모른다. 흐릿하게 발전사와 흐름만 알 뿐이다. 모델 개발은 한국에서도 잘 없긴 하니.. 한국계는 보통 프롬프트와 에이전틱 쪽 개발이 많은 걸로 알고 있다.
심지어 현재의 이코에코는 에이전틱보다는 어시스턴스에 가깝다. Streams와 LangChain/LangGraph 계열 마이그레이션(이건 할지 안할지 모르겠다.)을 거쳐 SSE 시도가 안정화가 되면 Chat을 에이전틱하게 구성해도 좋겠다는 생각이 들었다. Scan은 이코에코의 얼굴이 되는 기능이기도 하고, 그만큼 디자인, UX, 로직이 결정론적으로 짜여진 상태라 건드리기가 쉽지 않다. 그에 비해 chat은 거의 간판만 달려있는 상황이라 딱 시도해보기 적합한 위치에 있다.
Chat API에 대해 짧게 설명하면, 일반 채팅이 들어오면 분리수거 관련 안내를, 이미지와 함께 들어오면 scan[vision]과 동일한 파이프라인인 [cdn->s3->cdn_url 발급, url->vision->rule-based-retrieval->answer]을 타는 구조다.

테스트를 하던 중 OpenAI API Tier1에서 Tier2로 승격됐다. 커서에 쏟아부은 돈이 얼만데.. 그게 모델사에 반영 안된 건 너무 아쉽긴 하다.

 
바이브코딩으로 클러스터, GitOps, API들을 쭉 개발하고, 익히는 걸 반복하는 입장에서도 '이게 맞나..?'싶은 경우가 가끔 있다.
비용의 한계를 풀어둔 채로 빠르게 구축하고 실제 데이터를 수집, 이걸 다시 모델에 먹여서 코드베이스로 디벨롭하는 방식인데 음..
그렇게 특출난 접근은 아니지만 이걸 실제로 회사나 팀 단위로 적용하는 곳은 많지 않은 걸로 안다. 그만큼 개인은 더 없을테니 낯설 수 있다. 그래서 항상 LLM 주도 개발에 따라오는 문제가 리뷰다. 원래는 사람이 한땀한땀 코드를 작성하던 시절에 고착된 문화라.. 현재처럼 코드가 공장처럼 쏟아져 나오면 일일 리뷰로 따라갈 방법이 없다. PR을 잘게 나눠 검증하거나, LLM에게 맡기거나(솔직히 믿음이 안간다.) 실험을 통해 실데이터를 뽑는 수 밖에 없다.
작은 단위의 실험, 빠른 적용 사이클은 어찌보면 사일로의 정신이기도 하지만 정작 난 사일로를 별로 안좋아한다. 6개월 쯤 겪었던 주니어 때 경험이 그닥.. 좋지는 않아서 말이다.
아무튼 올해 6월 쯤에 '코드 베이스 자체를 LLM이 잘 생성하게 만들어야 한다.'는 MS CEO의 말이 근거없는 얘기는 아니었다고 생각된다. 그 때는 내부적으로 앞선 모델을 사용하거나, 각종 워크플로우를 실험하고 있었을 테니 말이다.
 

공모전용 MVP 이상의 이코에코를 원함. 내 욕심이긴 하지만 디벨롭돼서 나쁠 건 없다.

요즘 이코에코를 만들면서 에이전틱 앱이랑 관련 스택들과 동작 방식을 살피다보니 EDA에 대한 열망이 조금 사그라든다.
현재 Cursor, Perplexity, ChatGPT, Claude Code 등 다수의 에이전트 앱은 로컬 캐시(컨택스트 윈도우)로 돌아가서 서버측의 엄격한 상태관리가 요구되지 않는다. 그럼에도 툴콜링이랑 라우팅으로 보여주는 퍼포먼스를 보면.. 서버측의 기술 부채가 증강이 아닌 제약이 될 수도 있겠다는 판단도 선다. Redis Streams 이후 상황을 봐야겠지만 포트폴리오가 아니라 이코에코 아버지의 관점으로 간다면 EDA가 아니라 Lang-계열을 적용하는 게 맞지 않나 싶다.

Cursor 없이 기준 퍼포먼스를 내고, 뒷단으로 에이전틱 코드를 쓰는 게 다수의 주니어들이 보낸 지난 2025년일 거라 생각한다.
모두가 다 에이전틱 코드에 위협을 느끼는 건 아니겠지만 말이다. 몇몇은 한철 지나갈 유행이라고 생각할 수도 있다. (그러기엔 너무 많이 오긴 했다.)
에이전틱의 임팩트가 코딩과 검색 도메인에서 유독 크다. 이게 다른 도메인으로 퍼질 수 있을지는 의문이다.
기업이 아닌 일반 유저까지 풀이 넓어지려면 토큰비가 저렴해져야 한다. 토큰비는 매 업데이트마다 싸지고 있긴 하지만 말이다. 모델 개발사도 이런저런 비용 빼면 남는 거 없이 퍼주는 건 알지만 그걸 감안해도 비싸게 느껴지는 건 어쩔 수 없다.
그런 면에서 보면 Gemini Flash가 딱 빅테크가 낼 수 있는 제품 포지션이라고 생각한다. 저렴한 가격에 체감 성능이 낫뱃한 제품군인데 이런 건 투자 비용 대비 남는 게 없는 걸 넘어 손해에 가까워서 수익 모델이 잡히지 않은 스타트업들은 시도하기 힘들다. 경쟁사에서 엔트리 고객층을 뺏거나 세미 치킨게임을 유발하는 용도의 제품이라고 생각한다. LLM 모델의 DRAM 같은 제품군이 아닐까.

이러니 저러니해도 AI로 인력을 줄이고 있다는 말은 반정도만 믿는다. 정말 LLM으로 인력 줄이기를 시도했고 관련 워크플로우가 나왔으면 바이브코딩이 낯선 사람 자체가 많이 없었을 거라고 생각한다.
라쿠텐도 OpenAI와 Claude랑 엔터프라이즈 계약은 돼있어도 LLM 워크플로우..?까지는 없었다. 관련 교육이랑 권장하는 리모트 세션이 많긴 했지만 말이다. 모두 답을 찾아가는 와중이라고 여긴다. 개인적으로는 수많은 LLM SaaS 워크 플로우의 끝이 Cursor나 Claude Code라고 여긴다.. 바이럴에 비해 실제로 노출된 개발자의 수가 적은 걸 보면 K8s와 겹치는 면이 있다.
각설하고 현재로선 SSE가 안정적으로 50VU+ 이상으로 마무리되면 다음을 생각해봐도 될 듯 싶다.