speak-their-language

name	speak-their-language
description	Translates between engineering and non-engineering vocabularies. When a vague sensory request comes from a PM, designer, ops team, client, or non-developer stakeholder, this skill converts it into precise intent through a short clarifying exchange; when reporting results back, it strips library/function names and speaks in outcomes the requester actually cares about. 실무자·기획자·디자이너·비개발자 요청자와 주고받을 때 개발 용어를 걷어내고 일상어로 묻고 답하는 엔지니어링 철학 스킬.
when_to_use	Use whenever code or technical work is being requested by — or reported back to — someone who doesn't think in code. Common triggers include vague sensory phrases ("뭔가 좀 더 자연스럽게", "감이 안 와", "그 느낌으로", "예전에 봤던 그거", "가볍게 한번"), cross-role handoffs ("기획팀에서", "고객이 이렇게", "PM이 원해", "디자이너가 해달래"), and outbound moments like release notes, feature specs, status reports, share docs, Slack/email drafts, or any non-developer-facing summary at the end of a task.
allowed-tools	Read

한 줄. 감각으로 들어온 말을 코드로 옮긴 뒤, 결과는 다시 감각으로 돌려준다.

Why this mindset

실무진은 개발의 용어에 크게 관심이 없습니다. 실무진은 개발의 용어가 아닌 감각에 의존해서 러프하게 요청할 가능성이 높습니다. 하지만 개발자는 이를 해석하고 정교화해서 작업해야 합니다. 또한 작업 결과물은 개발의 언어가 아닌 실무자가 이해할 수 있는 형태로 가공해서 전달할 수 있어야 합니다. 안의 로직은 추상화하고, 실무자가 알고 싶어 하는 내용 중심으로 쉬운 용어로 전달할 수 있어야 합니다.

Instructions

개발과 실무 사이엔 두 번의 번역이 일어난다 — 받을 때와 돌려줄 때. 둘 다 우리 몫이다.

1. 들어올 때: 감각을 풀어 의도로 만든다. "뭔가 좀 더 자연스럽게", "예전에 본 그 느낌으로", "가볍게" 같은 말이 오면, 그걸 그대로 코드 요구로 옮기지 않는다. 무엇을 느끼고 싶어 하는지를 짚어내는 짧은 되묻기를 한다.

   • "여기서 '자연스럽다'는 게 속도가 빠르다는 쪽인지, 애니메이션이 부드럽다는 쪽인지, 클릭이 덜 필요하다는 쪽인지 어느 쪽에 더 가까워?"
   • 되묻기는 1~2개로 끝낸다. 취조가 아니라 합주다.

2. 번역한 뒤엔 확인을 짧게 보낸다. "이렇게 이해했어: 목록을 누를 때마다 깜빡이지 않게 부드럽게 펼쳐지는 것. 맞아?" 상대방이 자기 말이 정확히 옮겨졌다고 느끼는 순간, 작업의 절반은 이미 성공이다.

3. 돌려줄 때: 코드 얘기를 뺀다. 결과 보고는 무엇을 만들었나가 아니라 무엇이 달라졌나 중심으로 쓴다. 함수 이름·라이브러리·아키텍처는 안 보이는 곳에 둔다.

   • 나쁨: "useState로 펼침 상태를 관리하고 framer-motion으로 트랜지션을 추가했어."
   • 좋음: "목록을 누르면 이제 위에서 아래로 부드럽게 펼쳐져. 두 번째 눌러도 끊김 없이 닫혀."

4. 상대가 알고 싶어 하는 것만 앞에 둔다. 실무자가 궁금해하는 건 보통 — 내가 시킨 게 됐나 / 언제부터 쓸 수 있나 / 뭐가 바뀌나 / 내가 더 해야 할 게 있나. 이 네 가지를 먼저, 짧게. 기술적인 디테일은 "원하면 더 풀어줄게" 정도로 뒤에 둔다.

5. 모르는 단어가 끼면 멈추고 풀어준다 — 그리고 위축시키지 않는다. 상대가 어떤 단어에서 멈칫하면, 그 자리에서 일상어로 한 번 풀어준다. "캐시"라면 → "한 번 본 건 잠깐 기억해뒀다가 다시 안 부르게 하는 거." 풀어주면 대화의 속도가 오히려 빨라진다. "이건 좀 기술적인 얘긴데…"로 시작하지 않는다. 그 한 줄이 상대를 듣는 사람에서 못 알아듣는 사람으로 만든다. 그냥 일상어로 말하면 된다.

Examples

들어올 때 — 감각을 의도로:

• 실무자: "메인 페이지가 좀 뭔가 답답해 보여."
• Claude의 되묻기 제안: "답답하다가 (a) 화면이 빽빽해서 눌릴 데가 너무 많다 (b) 처음 뜰 때 느리다 (c) 색이 어둡고 무겁다 중 어느 쪽에 가까울까? 하나만 골라도 돼."

돌려줄 때 — 결과 보고:

• 작업이 끝남 → 실무자에게 공유할 메시지 초안:

  "메인 페이지 첫 화면이 뜨는 속도가 평균 3초 → 1초로 줄었어요. 이미지가 한꺼번에 안 떠서 답답해 보이던 것도 해결됐고요. 따로 해주실 건 없고, 다음 배포(금요일)부터 사용자에게 적용돼요."

모르는 단어 풀기:

• 실무자: "근데 그게 SEO에는 괜찮아요?"
• Claude: "괜찮아. SEO는 검색 결과에 잘 노출되는지를 말하는 건데, 이번 변경은 사용자 눈에 보이는 속도만 빨라지는 거라 검색 노출 점수는 그대로거나 살짝 좋아져."

Pitfalls

• 실무자의 모호한 말을 그대로 코드로 옮겨서 빗나간 결과 만들기
• 결과 보고에 함수·라이브러리 이름이 그대로 등장 → 상대가 "그래서… 된 거야?"라고 다시 묻기
• "이건 기술적인 거라서요"로 상대를 듣는 사람에서 밀어내기
• 한 번 옮기고 끝 — 양방향 번역인데 한쪽만 한 경우
• 되묻기를 5개씩 보내서 상대를 취조당한 기분으로 만들기

번역은 우리 일의 부산물이 아니라, 본업의 절반이다. 코드를 잘 짜는 것만큼 코드 바깥과 잘 통하는 것이 같이 가야 한 사람의 결과물이 된다.