LLM 출력물을 '사람답게' 수정하는 것은 옳지 않다
최근 LLM 사용자들이 프롬프트를 통해 출력물을 사람이 읽기 편하고 친근하게 만들려는 시도가 유행하지만, 이는 정보 손실을 초래하는 잘못된 접근법입니다. 에이전트 간의 통신이나 작업 수행 과정에서는 기계가 처리하기 좋은 고밀도의 원시 상태를 유지하다가, 최종적으로 사용자에게 전달하는 마지막 단계에서만 요약하고 사람이 읽기 좋은 형태로 렌더링해야 합니다.
AI 도구에 대한 문화와 대중의 인식이 어떻게 변화하는지 파악하는 가장 좋은 지표는 보통 X(트위터), 인기 있는 GitHub 저장소, 그리고 해커 뉴스(Hacker News)입니다. 최근 제가 많이 목격하는 지표 중 하나는 '나는 ADHD가 있으니 짧게 대답해'와 같은 프롬프트 스킬이나, 오직 'ASD-STE100 Simplified Technical English(단순화된 기술 영어)'로만 출력하라는 에이전트 설정 파일(Agents.md)입니다. 이런 요구의 매력은 이해합니다. 우리 중 누구도 LLM 출력의 장황함과 독특한 특성을 진정으로 좋아하지 않으니까요. 하지만 모델을 '사람답게(humanising)' 만드는 방식으로 이 문제를 해결하는 것은 잘못된 추상화라고 생각합니다. 문제는 이런 지시사항들이 모델이 작업을 마친 후에 적용되는 것이 아니라, 작업 자체의 일부가 된다는 점입니다. 에이전트에게 짧은 문장을 쓰고, 전문 용어를 피하고, 너무 많은 정보를 주지 말며, 가장 중요한 세부 사항만 포함하라고 지시한다면, 끊임없이 출력을 저대역(low-bandwidth) 형식으로 압축하라고 요구하는 셈이 됩니다. 이러한 압축은 필연적으로 손실(lossy)을 발생시킵니다. 결과물이 여전히 읽기 좋기 때문에 무엇이 누락되었는지 아마 결코 알아채지 못할 것입니다. ASD-STE100은 매우 합리적인 규칙처럼 들리기 때문에 좋은 예시입니다. 애초에 인간을 위해 문서를 명확하게 만들도록 설계되었으니까요. 하지만 에이전트는 인간 기술 작성자가 아니며, 처리된 원시 상태(raw state)야말로 정보 밀도가 가장 높은 표현 방식입니다. 한편, 이런 글쓰기 스타일 규칙은 '작업을 해결하고, 도구를 올바르게 사용하고, 추상화를 유지하고, 아무것도 망가뜨리지 마라'와 같은 규칙과 동일한 지시어 목록에 포함됩니다. 에이전트들이 다른 에이전트와 소통하기 시작하면 상황은 훨씬 더 이상해집니다. 하위 에이전트가 버그를 조사하고, 그 결과를 읽기 좋은 사람의 언어로 요약합니다. 부모 에이전트는 그 요약본을 읽은 다음, 다시 당신을 위해 또 다른 읽기 좋은 사람의 언어로 요약합니다. 만약 하위 에이전트가 6개의 테스트를 실행했다면, 저는 이런 대답을 원하지 않습니다: '대부분의 테스트가 통과했지만, 살펴봐야 할 문제가 하나 있었습니다.' 저는 이렇게 구체적인 원시 데이터를 원합니다: [결과값: 통과 5, 실패 1. 오류 코드 XXX]. 더 중요하게도, 이러한 사람 중심의 변환은 실패를 숨깁니다. 에이전트는 유용하면서도 볼품없는 방식으로 실패합니다. 증거 충돌, 미해결 분기, 스택 트레이스, 불확실한 가정 등이 그 예입니다. 반면 인간의 산문은 이런 내용들을 매우 부드럽게 다듬어 버립니다. '여기에는 몇 가지 고려할 사항이 있습니다.'라고 말이죠. 물론 더 좋게 들립니다. 하지만 저는 이런 식으로 만족하기보다는, 제 에이전트가 환각 현상을 겪고 있거나 토큰 창(token window) 한계에 다다랐다는 사실을 직접 발견하는 것이 낫습니다. 우리가 만드는 다른 모든 시스템은 정반대로 작동합니다. 데이터베이스는 대시보드가 표시하는 형식으로 데이터를 저장하지 않고, 컴파일러는 과정(IR)을 읽기 좋게 만들지 않으며, API는 친근한 요약본을 교환하지 않습니다. 우리는 인간이 소비하는 최종 경계(boundary)에 다다르기 전까지는 항상 가장 높은 충실도(high-fidelity)의 데이터를 유지하고 변환합니다. 하지만 LLM 도구들은 점점 이를 거꾸로 하고 있습니다. 분명히 하자면, 이것이 접근성이나 개인화에 반대하는 주장은 아닙니다. 세 줄짜리 답변이나 단순화된 기술 영어를 원하신다면, 훌륭합니다! 다만 그 작업이 맨 마지막 단계에서 이루어지는 것이 더 낫다고 생각할 뿐입니다. 에이전트가 상세한 상태를 유지하고, 하위 에이전트가 구조화된 데이터(schemas), 코드 변경 사항(diff), 정확한 오류, 신뢰도, 출처 등을 서로 교환하게 두십시오. 그리고 나서 저를 위해 압축해 주세요. 가장 흥미로운 점은 이렇게 유행하는 프롬프트 스킬들이 실제로 올바른 미래를 가리키고 있을 수 있다는 것입니다. 사용자들은 스택의 더 아래쪽에 있어야 할 기능을 프롬프트 계층(layer)에서 패치하고 있습니다. 'ADHD가 있는 것처럼 나에게 말해줘'라는 지시는 화면 렌더러(renderer)로서는 완벽하게 의미가 있지만, 시스템의 핵심 작동 지침으로서는 전혀 의미가 없습니다. 진정으로 발전한 형태의 에이전트는 그들의 고유 언어가 정확하고 기계가 읽기 좋은 상태(state)여야 하며, 따뜻하고 간결한 인간의 언어는 최종적으로 사용자에게 보여주는 경계(boundary)에서만 생성되어야 합니다. 그러니 이 유행하는 저장소들은 궁극적인 목표가 아니라 시스템의 개선점을 알려주는 버그 리포트로 보아야 합니다.