→ 옆으로 밀어 시간대별 흐름 보기
대규모 메모리를 DB와 계층형 색인으로 나누고, 단어·의미·맥락별 드릴다운 검색을 수행하는 에이전트 메모리 구조를 논의했다. 경량 모델을 스카우트처럼 앞단에 세워 층위별 탐색을 맡기면 빠를 수 있다는 아이디어가 제시됐다. 이미 구현을 시작한 뒤 유사 사례를 찾으며 agent memory, basic-memory, markdown-memory, claude-mem 등을 참고 후보로 모았다.
에이전트가 기능 개발을 맡는 환경에서도 개발자에게 코드 리딩 역량이 필요한지 논의했다. AI가 작성한 코드라도 기존 흐름을 이해하고 수정 결과·오류·사이드이펙트를 검토할 수 있어야 하며, 실무에는 기존 코드를 읽고 고치는 일이 많다는 의견이 중심이었다. 디버깅 시에는 로그를 전부 넘기기보다 문제 지점을 단계적으로 좁혀가는 능력이 필요하며, API 요청부터 컨트롤러·서비스·매퍼·SQL·DB까지 추적하는 예시가 제시됐다.
자료·로그·작업일지·회의록·사고 기록을 모아 AI가 조직의 방향성과 일관된 실행을 조언하게 하는 구조를 고민했다. 단순한 수치 분석이나 과거 학습 기반 제안을 넘어, 상황과 판단 이력이 가리키는 방향성을 설계하는 AX 방식을 찾고자 했다. 논의 중 정량적 개념과 정성적 개념이 혼재됐음을 인식하고 문제를 재정의했다.
메모리 병목은 해결했지만 8코어 PC에서 Codex 세션 두 개와 하위 서브에이전트 병렬 실행만으로 CPU 사용률이 88%까지 오른 상황을 공유했다. CPU 업그레이드 필요성, Windows PC와 Linux VPS의 메모리 관리·누수 차이, 전용 서버 전환 여부를 질문했다. VPS의 vCPU 성능과 공유 여부를 SSH로 점검하는 방법 및 확인용 프롬프트도 요청했다.
OMO를 사용한다는 언급을 계기로 여러 에이전트를 한 번에 돌리는 편의성과 통제 문제를 논의했다. 병렬 탐색이 필요한 큰 작업에는 유용하지만, 과정과 산출물이 과도하게 쏟아져 검수 비용과 통제감 저하가 생길 수 있다는 의견이 나왔다. 작은 작업보다 대규모 탐색·병렬 작업에 적합하다는 결론으로 정리됐다.
Speech-to-speech·realtime voice가 기존 STT→TTS 파이프라인과 어떻게 다른지, 성능과 가성비가 좋은 모델이 무엇인지 질문이 나왔다. 한국어 TTS가 자연스러운 업체를 찾는 대화로 이어졌고, ElevenLabs도 검토 대상에 올랐다. GPT TTS의 한국어 품질은 아쉽다는 체감 의견이 있었으며, 테스트가 필요하다는 반응도 나왔다.
GPT 음성라이브 기능이 외국인이 한국어를 조금 배운 듯한 말투를 재현해 모의 테스트에 활용하기 좋다는 경험이 공유됐다. 다른 참여자도 지연이 거의 없고 자연스럽다고 동의했다. 실시간 음성 기능의 자연스러움과 낮은 지연이 핵심 장점으로 언급됐다.
아르곤에 접근해 사용해 본 경험으로, 특정 모델과 비슷한 품질이면서 토큰 처리 속도가 약 2.4배 빠르다는 체감이 공유됐다. 이어 토큰 소모량이 빠른 것인지 출력 생성 속도가 빠른 것인지 확인 질문이 나왔다. 구체적 벤치마크나 후속 답변은 없었다.
한국어 음성 인식 또는 처리 품질의 아쉬움과 관련해 일본어로 말한다는 경험담이 나왔다. 다만 다른 참여자는 많은 사람이 일본어를 하지 못한다는 현실적 제약을 언급했다. 언어별 음성 품질 차이가 사용 방식에 영향을 준다는 가벼운 대화였다.
투잡 이야기에서 가재코드가 언급됐고, 가재·랍스터·크래미·도레미로 이어지는 짧은 말장난이 오갔다. 기술적 정보나 결론은 없는 가벼운 잡담이었다.