Show GN: SongRyeon Core - LLM이 쓴 말과 코드가 검증한 정보를 분리하는 로컬 에이전트 런타임 실험

안녕하세요. 코딩을 배우면서 AI 에이전트 런타임을 직접 실험하고 있는 정후입니다.

SongRyeon Core는 “LLM이 말한 판단”과 “코드가 실제로 확인한 사실”을 분리해서 다루는 작은 로컬 우선(agent runtime) 실험입니다.

요즘 LLM 기반 에이전트를 만들다 보면 다음 문제가 자주 생긴다고 느꼈습니다.

• LLM이 추측한 내용을 시스템 사실처럼 보여줌
• 코드가 만든 fallback이나 휴리스틱이 LLM 판단처럼 섞임
• 문서를 몇 개 읽었는지, 어떤 실행이 실제로 일어났는지 화면마다 다르게 보임
• 최종 답변이 내부 런타임 상태와 어긋남

그래서 이 프로젝트에서는 정보를 크게 세 가지로 나눠 다룹니다.

• 절대정보: 코드/trace/schema/tool result로 확인 가능한 값
• 상대정보: 하나의 절대정보에 대응하는 LLM 판단
• 혼합정보: 여러 source bundle에 근거한 LLM 판단

현재는 아직 작은 연습판이지만, 다음 같은 구조를 실험하고 있습니다.

• node_0 memory supplier
• node_1 router
• L loop
• node_3 reporter
• node_4 verifier
• smoke-test 기반 회귀 검증
• runtime terminal/final renderer 정직성 검사

목표는 “멋진 데모”보다, AI 에이전트가 어떤 근거로 무엇을 말했는지 최대한 숨기지 않는 작은 런타임을 만들어보는 것입니다.

아직 제가 코딩을 배우는 중이라 거친 부분이 많습니다.
구조, README, 테스트, 용어 정의, agent runtime 설계에 대해 피드백 주시면 정말 감사하겠습니다.

GitHub:
https://github.com/Junghoo-developer/SongRyeon

[anima]

보충입니다.

현재 SongRyeon Core는 웹 서비스 형태보다는 로컬 CLI / smoke-test 중심의 런타임 실험입니다.

바로 확인해볼 수 있는 것은 README의 실행 방법과:

• python -m compileall songryeon_core main.py
• python main.py smoke-test

입니다.

특히 피드백 받고 싶은 부분은 다음입니다.

• 절대정보 / 상대정보 / 혼합정보 구분이 설계상 납득되는지
• LLM 판단과 code-verified fact를 나누는 방식이 실제 agent runtime에 유용해 보이는지
• README에서 처음 보는 사람이 이해하기 어려운 부분이 어디인지

아직 학습 중인 프로젝트라 거친 부분이 많습니다. 편하게 찔러주시면 감사하겠습니다.