메뉴
HN
Hacker News • 47일 전

LLM 출력물을 '사람답게' 수정하는 것은 옳지 않다

IMP
7/10
핵심 요약

최근 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)에서만 생성되어야 합니다. 그러니 이 유행하는 저장소들은 궁극적인 목표가 아니라 시스템의 개선점을 알려주는 버그 리포트로 보아야 합니다.

원문 보기
원문 보기 (영어)
The largest tell for me to tell where culture and sentiment is shifting for AI tools is usually X, viral GitHub repositories and Hacker News. One of these tells I’ve been seeing a lot lately is skills like I have ADHD and Agents.md instructions such as giving outputs in only ASD-STE100 Simplified Technical English . I understand the appeal, none of us really like the verboseness and specific quirks of LLM outputs, but I really think fixing that by humanising the model is the wrong abstraction. The problem is that these instructions are not applied after the model has finished doing the work, it becomes part of the same work - If you tell an agent to use short sentences, avoid jargon, never overwhelm you and only include the most important details, you are asking it to continuously compress its output into a lower-bandwidth format. That compression is lossy. You probably never notice what got dropped because the output still reads nicely. ASD-STE is a great example because it sounds so reasonable. It was designed to make documentation unambiguous for humans . But an agent isn’t a human technical writer, and the raw state is often the most information-dense representation available. Meanwhile the style rules sit on the same instruction list as: solve the task, use tools correctly, preserve abstractions, don’t break anything. This becomes even stranger once agents start talking to other agents. A subagent investigates a bug, turns its findings into a nice human-readable summary, the parent agent reads that summary, and then turns it into another nice human-readable summary for you. If a subagent ran six tests, I don’t want: Most tests passed, although there was one issue worth looking into. I want: More importantly, humanisation hides failure. Agents fail in useful, ugly ways: conflicting evidence, unresolved branches, stack traces, uncertain assumptions. Human prose is extremely good at smoothing these into sentences like: There are a few considerations here. That sounds nicer. But I’d rather find my agent is hallucinating or near its token window than be happy with that. Every other system we build works the opposite way - Databases don’t store data in the format a dashboard displays it, compilers don’t make their IR pleasant to read, APIs don’t exchange friendly summaries. We keep the highest-fidelity representation as long as possible and transform it at the boundary where a human consumes it, but LLM tooling is increasingly doing this backwards. To be clear, none of this is an argument against accessibility or personalisation. If you want three-line answers or Simplified Technical English, great! I just think it’s better to do it at the end. Let agents keep detailed state, let subagents exchange schemas, diffs, exact errors, confidence, provenance. Then compress it for me. I think the best part is that these viral skills might actually be pointing toward the right future. Users are patching this at the prompt layer, something that belongs further down the stack. “Talk to me like I have ADHD” makes perfect sense as a renderer, it makes much less sense as an operating instruction. The durable version is agents whose native language is precise, machine-facing state, with the warm, concise, human version generated only at the boundary. So the viral repos aren’t the end state, but a bug report.