에이전트 스택 논쟁, 병목은 파이썬이 아니라 설계층으로 옮겨갔다

오전 11시 45분, 한 참가자가 사내에서 챗 형태로 제공되는 에이전트 서비스를 맡고 있다며 기술스택 고민을 길게 털어놨다. 파이썬으로 서비스를 이미 올려두긴 했지만 본인은 자바 출신이라 이 언어로 계속 가는 것이 맞는지 확신이 서지 않는다는 이야기였다. 주변에서 a2a에도 부정적인 말을 듣는데 정작 물어볼 곳이 마땅치 않아 방에 적게 됐다는 말이 뒤따랐다.

저는 저희 회사에서 챗 형태로 제공되는 에이전트 서비스를 담당하고 있는 개발자 입니다. python기반으로 서비스는 올렸는데.. 태생이 자바 출신이라.. 정말 이 언어로 가야하는지도 계속 고민이 들고, 가끔 주변 이야기 들어보면 a2a도 부정적인터라.. 어떤 기술스택이 맞는지 고민이 많이 드는데 어디에 물어볼 곳이 없어서 주저리 적게 되었어요..

정오를 막 넘긴 12시 12분, 다른 참가자가 실무 경험을 근거로 짧게 답을 달았다. 언어가 병목이 된 적은 없었다는 것이다. 5분 뒤 같은 참가자는 이 자리에서 다툴 논제가 무엇인지를 한 문장으로 못박았다.

언어가 병목되진 않았었습니다

제가 얘기하는건 파이썬이라는 언어가 에이전트 오케스트레이션의 성능병목이냐는 논제고

논제가 언어에서 설계로 옮겨가자 대화는 곧 데이터 레이어로 번졌다. 한 참가자는 RAG(검색증강생성) 검색을 초 단위에서 밀리초 단위로 줄이려 애쓰는 대신 QC 레이어 하나를 걷어내는 편이 낫다는 실무 관점을 내놨다. 응답 지연의 원인을 언어 런타임이 아니라 파이프라인에 몇 겹을 쌓아뒀는지에서 찾는 시각으로 읽힌다.

RAG 검색 s에서 ms 초 단위로 만들 동안 처라리 QC 레이어 하나 쳐내는게 더 맞는 방식

온톨로지 이야기도 같은 맥락에서 나왔다. 한 참가자는 온톨로지 자체가 무겁다기보다 사람마다 조직마다 정의가 제각각인 것이 문제에 가깝다고 짚었다. 다른 참가자는 그래프 데이터베이스인 neo4j 역시 자바 기반이라는 점을 들었는데, 언어를 바꾼다고 스택 전체가 한 언어로 정리되지는 않는다는 뜻으로 보인다.

온톨로지도 이제 뭐 사람마다 조직마다 정의가 다 달라서 온톨로지자체가 헤비하다- 라기보다는

이 토론은 이날 방에서 가장 많은 말이 오간 자리였다. 전체 628건 가운데 180건이 이 주제에 몰렸고, 참여자는 4명이었다. 적은 인원이 긴 시간 주고받았다는 뜻인데, 스택 선택이 검색 한 번으로 답이 나오는 질문이 아니라 각자의 실무 맥락을 붙여야 겨우 답할 수 있는 질문이라는 점을 시사한다.

질문을 던진 쪽이 원한 것은 어느 언어가 빠른지에 대한 판정이었지만, 돌아온 답은 병목을 재는 자리를 옮기라는 쪽에 가까웠다. 언어와 프레임워크 선택보다 온톨로지 정의나 QC 레이어 같은 설계 결정이 실제 응답 시간을 좌우한다는 관점이 이 자리의 공통된 흐름으로 모인 것으로 보인다. 한 사람의 언어 선택 고민이 방 전체의 아키텍처 논의로 번진 것은, 에이전트 서비스에서 스택 질문이 사실은 설계 질문의 다른 이름이었다는 것을 보여준다.