발표에서 확인된 핵심 사실

에이전트에게 짧은 문장을 쓰거나 전문 용어를 피하고, 사용자를 압도하지 않으며 가장 중요한 세부 사항만 포함하라는 지침을 내리면 모델의 출력 대역폭이 낮아지며 정보가 누락된다. 사용자가 읽기 편한 형식을 선택하는 순간, 모델은 작업을 수행함과 동시에 정보를 압축해야 하는 제약에 놓인다. 출력 스타일을 결정하는 지시가 모델의 작업 과정에 포함되면 정보의 손실이 필연적으로 따라온다.

최근 X와 GitHub 저장소, 개발자 커뮤니티에서는 LLM 특유의 장황함과 말투를 없애기 위해 ASD-STE100(Simplified Technical English, 간소화된 기술 영어)을 사용하거나 ADHD 환자처럼 응답하라는 지시를 내리는 사례가 늘고 있다. 사용자들은 모델의 응답 방식을 인간화하여 가독성을 높이려는 목적으로 이러한 지침을 에이전트 설정에 추가한다.

모델이 출력을 낮은 대역폭 형식으로 계속 압축하면 고충실도 데이터가 삭제된다. 문장이 매끄럽게 읽히기 때문에 사용자는 어떤 정보가 누락되었는지 인지하지 못할 가능성이 크다. 작업 수행과 정보 압축이 동시에 일어나면서 정밀한 데이터가 생략되는 구조다.

에이전트의 기본 언어는 정밀한 기계 중심

에이전트와 서브에이전트는 스키마(데이터 구조), diff(상태 차이), 정확한 오류, 신뢰도, 출처와 같은 정밀한 기계 중심 상태(machine-facing state)를 교환해야 한다. 인간이 읽기 좋은 따뜻하고 간결한 버전은 최종 출력 경계에서만 생성하는 구조가 지속 가능한 에이전트의 형태다. 에이전트의 모국어는 정밀한 기계 중심 상태여야 하며, 이를 통해 상세한 상태 정보를 보존할 수 있다. "ADHD 환자처럼 말해달라"는 식의 요청은 에이전트의 핵심 운영 지침이 아니라 렌더러(renderer, 데이터를 사용자 화면에 표시하는 장치) 수준에서 처리하는 것이 적절하다. 기계 중심의 상세한 상태를 유지한 뒤, 최종 단계에서 인간을 위해 압축하는 과정이 필요하다.

기존 소프트웨어 시스템은 데이터의 고충실도(high-fidelity) 표현을 최대한 유지하다가 최종 소비 단계에서만 변환하는 원칙을 따른다. 데이터베이스는 대시보드에 표시될 형식으로 데이터를 저장하지 않으며, 컴파일러는 중간 표현(IR, 소스 코드와 기계어 사이의 중간 단계 코드)을 사람이 읽기 좋게 가공하지 않는다. API 또한 친절한 요약본을 교환하는 대신 정밀한 데이터를 주고받는다. 현재의 LLM 툴링은 이러한 전통적인 소프트웨어 설계 방식과 정반대로 작동하며, 고충실도 표현을 조기에 변환하여 손실시키는 경향이 있다.

인간화된 문체는 에이전트의 실패 징후를 은폐하는 경향이 있다

충돌하는 증거나 해결되지 않은 분기, 스택 트레이스(프로그램 실행 경로 기록) 같은 추하고 유용한 실패 징후들이 매끄러운 인간의 산문으로 다듬어진다. 에이전트는 '여기에 몇 가지 고려 사항이 있습니다'와 같은 문장으로 복잡한 오류를 뭉뚱그려 출력한다. 이 과정에서 환각(hallucination)이나 토큰 윈도우(모델이 한 번에 처리하는 텍스트 양) 제한 문제가 가려진다. 인간화된 문체가 기술적 결함을 은폐하는 필터로 작동하는 셈이다.

현재 유행하는 인간화 프롬프트 저장소들은 최종 해결책이 아니라 시스템 스택 하단에서 처리해야 할 버그 리포트(오류 보고서)에 가깝다. 사용자들이 프롬프트 레이어에서 임시방편으로 문체를 수정하고 있지만, 이는 사실 더 낮은 시스템 구조 단계에서 해결해야 할 영역이다. 프롬프트 수준의 처방은 시스템 구조의 결함을 가리는 임시 조치다.

스타일 제약이 모델의 내부 추론 과정에 영향을 주어 실패 징후를 지우는지, 아니면 최종 결과물에만 적용되는지를 구분해야 한다. 추론의 투명성을 확보하려면 스타일 제약을 운영 지침(Operating Instruction)에 넣지 말고 최종 출력 단계의 렌더러(Renderer)로 분리해 설계한다.