/show-me: 코딩 에이전트를 위한 압축 시각 표현

/show-me: 코딩 에이전트를 위한 압축 시각 표현

dex @dexhorthy · 2026-08-13 · X 아티클

tl;dr 에이전트가 산문 벽(walls of prose) 대신 시각적으로 대화하게 만들어라.

npx skills add humanlayer/skills --skill show-me

HTML보다 가볍고 빠르며, 대부분의 개발 작업 형태 문제에는 충분히 좋다.

코딩 에이전트는 사실상 읽을 수가 없다

레딧 전 CEO:

Yishan @yishan · 2026-08-09

좋아, Claude의 거슬리게 끔찍한 말투(과장된 장황함 + 불필요한 축약이 뒤섞인 이상한 조합)를 계속 고쳐보려 하는데, 도저히 안 된다. 모델에 너무 깊이 박혀 있는 것 같다. 이 모델을 만드는 Anthropic 사람들은 하루 종일 이걸 대체 어떻게 쓰는 거지??

Okay, I keep trying to correct Claude's gratingly awful speaking style (a weird mix of over-dramatic wordiness + unnecessary terseness) and I can't. It seems to be too embedded in the model. How do all the people at Anthropic who work on this model use this thing all day??

pi를 만든 Mario Zechner:

Mario Zechner @badlogicgames · 2026-08-11

좋은 아침, 슬롭 갱(slop gang).

good morning, slop gang. https://t.co/9PD5qvuVBS

Replicas의 Connor:

Connor Loi @connortbot · 2026-07-27

Claude의 쓰레기 같은 글을 더는 못 읽겠는 게 나뿐인가? AI 특유의 말버릇 때문에 가장 기본적인 개념조차 알아들을 수 없게 된다

am I the only one who can’t read Claude’s garbage writing anymore? Like the most basic concepts become unintelligible because of its AI mannerisms

Dillon Mulroy는 모델에게 언어를 단순화해 달라고 요청하는 /bro라는 스킬까지 만들었다.

Dillon Mulroy @dillon_mulroy · 2026-07-20

/bro는 여전히 무패다

/bro remains undefeated https://t.co/T0dmAg1xRq

그 내용은 이렇다:

마지막 메시지를 다시 말하라. 전문용어(jargon) 사용을 멈추고 조리 있게 말하라.
사람이 사람에게 말하듯, 더 단순하고 간결하게 진술하라.

이제 정말 지긋지긋하다

에이전트는 서류상으로는 더 똑똑해졌지만, 이 측면에서의 사용 경험은 눈에 띄게 나빠졌다

사람들이 claude에서 사랑했던 것 — 그 목소리, 그 개성, 그 "영혼"은 RL 던전에서 씻겨 내려가 버렸다

sol은 그보다는 덜 오글거리지만, 여전히 눈이 게슴츠레해지는 전문용어 벽으로 우리를 정기적으로 때린다

최근에 받은 응답 하나를 보자. 이런 일이 하루에도 몇 번씩 일어난다

내 제안: show me

우리는 이 문제를 개선하기 위해 — 특히 코딩용으로 — 내부 도구들을 만지작거려 왔고, 그것들을 show-me라고 부르는 스킬로 공개하고 있다.

오늘부터 humanlayer에 탑재돼 있고, 다른 코딩 에이전트에서 쓰고 싶다면 여기서 받을 수 있다:

npx skills add humanlayer/skills --skill show-me

또는 인라인 HTML과 다이어그램을 일급(first-class)으로 지원하는 humanlayer 내장 버전을 받아라:

brew trust humanlayer/humanlayer
brew tap humanlayer/humanlayer
brew install humanlayer

인프라 시스템에서 직관(intuition) vs 주의(attention)를 다룬 coda hale의 강연을 본 적이 있다면, 여기서 어느 정도 영감을 받았다:

정보를 분석하는 일은 어렵고 지치는 일이다

너의 시각 피질은 수백만 년에 걸쳐 풍부한 시각 정보를 힘들이지 않고 처리하도록 훈련되었다

도구를 그에 맞게 최적화하라

도끼가 유용하려면 사람의 손에 맞아야 하듯, 소프트웨어가 유용하려면 사람의 마음에 맞아야 한다

/show-me는 에이전트에게 산문 벽 대신 간결한 시각 자료로 무슨 일이 일어나고 있는지 설명하도록 프롬프트한다.

이건 프로그램 설계(program design)에 정말 좋다 — 요즘 많은 사람이 건너뛰는 단계지만, 나는 필수라고 생각한다. 에이전트가 코드를 쓰는 작업에 들어가기 전에 코드의 형태(타입, 시그니처, 콜스택)를 논의해야 한다.

같은 기법은 대형 diff를 사후(post-hoc)에 탐색해서 리뷰 때 어디를 파고들지 파악하는 데도 쓸 수 있다.

안에 뭐가 들었나

컴포넌트 트리

프런트엔드에서도 같은 아이디어다 — 중요한 state hook과 모듈 경계는 남기고, 나머지는 전부 뺀다.

이건 2025년 12월에 트위터에 공유했던 것이다:

dex @dexhorthy · 2025-12-11

컴포넌트를 리팩토링하고 복잡한 state와 너무 많은 useEffect를 제거할 때, claude에게 이런 컴포넌트 트리를 그려 달라고 프롬프트해 왔다. 실제 계획을 쓰기 전에 에이전트와(그리고 팀과) 멘탈을 정렬하는 데 엄청나게 유용하다

have been prompting claude to make me component trees like this when refactoring components and eliminating complex state and too many useEffects. super helpful for mental alignment with the agent (and with the team) before writing the actual plan https://t.co/GzxQa1WfAd

콜스택

오케스트레이션이나 제어 흐름(control-flow) 작업, 혹은 그냥 백엔드 형태의 문제라면 — dillon이 우리에게 이 "콜스택(call stack)" 형태를 알려줬다.

Dillon Mulroy @dillon_mulroy · 2026-05-28

내 "계획서"는 대체로 타입/인터페이스, 그것들이 어떻게 조합되는지, 그리고 그 경계로 이루어진 의사코드(pseudo code)처럼 생겼다

최근에는 콜스택도 넣기 시작했다 — 구현할 때 나에게도 에이전트에게도 아주 유용했다

my "plans" largely look like pseudo code composed of mostly types/interfaces, how they compose, and their boundaries ive recently started including call stacks - been very helpful for both me and agents when implementing https://t.co/SLrYX3ywqc

Tanishq는 AST에서 곧바로 콜스택을 계산해 내는 도구까지 만들었다

Tanishq (tk) @tanishqk · 2026-08-07

콜스택 diff가 내가 마크다운 계획서를 읽는 방식을 완전히 바꿔놨다

고마워요 @dillon_mulroy

call stack diffs have completely changed how I read markdown plans thank u @dillon_mulroy https://t.co/kYFucQV4bM

다이어그램

클래식이다. 채팅 인터페이스가 인라인 mermaid를 지원한다면 큰 도움이 된다. (가끔은 여전히 슬롭이지만, 보통은 글을 읽는 것보단 낫다)

선택지는 많다. 우리는 상태 다이어그램(state diagram)과 시퀀스 다이어그램(sequence diagram)을 가장 좋아한다.

파일 레이아웃

얕은 파일 트리에, 항목당 책임 한 줄. "이건 어디에 사는가" 질문과 리팩터 범위 잡기(scoping)에 좋다.

의사코드 (pseudocode)

특히 알고리즘 관련 작업에서는 의사코드가 더 간결할 수 있다.

타입과 시그니처

코드가 하나도 존재하기 전의 코드의 형태 — 아키텍처 문서에 넣기엔 너무 내부적이지만, 에이전트가 여전히 틀릴 수 있는 것들이다.

interface Item {
  id: ItemId
  parentId: ItemId | null
  // ...
}

interface Cursor {
  position: ItemId
  direction: 'up' | 'down'
  // ...
}

resolveTarget(items: Item[], cursor: Cursor) -> ItemId | null

diff 문법

내용 대부분이 그대로라면, 여기에 diff 문법을 쓸 수도 있다:

컴포넌트 변경이라면:

콜 트리 변경이라면:

파일 레이아웃 변경이라면:

그리고 형태가 실제 코드가 아니라 의사코드인 상태·제어 흐름 변경이라면:

HTML 목업

우리 프로토타이핑 작업의 상당 부분에서 HTML이 figma를 대체했다. (솔직히 말하면 나는 애초에 figma를 그렇게 잘 다루지도 못했다)

HTML 다이어그램

때로는 다이어그램이나 설명 페이지(explainer)가 딱 필요한 것일 때가 있다.

humanlayer에서는 에이전트가 어시스턴트 응답 안에 HTML을 직접 포함할 수 있게 한다.

물론 그냥 브라우저에서 열어 볼 수도 있다.

다른 영감들

그의 /teach 스킬이 생성하는 HTML explainer에 대해 @mattpocockuk에게도 경의를 표하고(hat tip) 싶다 — 아주 훌륭하다.

가서 써봐라

npx skills add humanlayer/skills --skill show-me

스킬을 설치한 뒤 /show-me를 호출하거나 에이전트에게 show-me 스킬을 쓰라고 요청하라. 라우트, 서비스, 기능, 풀 리퀘스트, 지금 다루는 주제를 겨냥해도 되고, 그냥 모델에게 질문이나 진술을 다시 말해 달라고 하는 데 써도 된다.

this is too much content. show me. (내용이 너무 많아. 보여줘.)

또는

/show-me as an html explainer (HTML explainer로 보여줘)

어떻게 생각하는지 알려달라! 결과물이나 커스터마이즈/추가한 내용과 함께 @humanlayer_dev나 @dexhorthy를 태그해 달라 — 같이 리프(riff)해 보자!