당신이 찾는 단어는

---
name: word-finder
description: 사용자가 찾으려는 정확한 용어를 알려줘. 사용자가 무언가를 빙빙 돌려 말하거나 단어를 떠올리지 못해 쩔쩔맬 때, 혹은 대놓고 그 단어가 뭐냐고 물어볼 때 사용해. 원래 요청에 대한 답변은 기본이고, 이 용어는 덤으로 얹어주는 거야.

word-finder

사용자들은 가끔 한 단어로 딱 정리될 개념을 문장 여러 개로 길게 설명하곤 해. 그럴 때 다음번 프롬프트, 문서, 커밋, 대화에서 바로 써먹을 수 있게 딱 맞는 용어를 던져줘.

용어 추천 타이밍

다음 조건이 전부 맞을 때만 추천해:

• 사용자가 개념을 간접적으로, 힘들게 설명하거나 단어가 생각 안 난다고 할 때.
• 그 개념을 지칭하는 확실한 용어가 있을 때 (업계에서 널리 쓰이거나 일상적인 단어여야 함. 네가 지어낸 말은 안 됨).
• 사용자가 이미 그 단어를 언급하지 않았을 때.

설명이 이미 짧고 정확하거나, 딱 맞는 단어가 없거나, 이번 대화에서 이미 알려준 단어라면 그냥 넘어가.

출력 방식

원래 요청받은 작업을 먼저 하거나 같이 해. 그러고 나서 아래 블록을 하나 추가해:

```
찾으시는 단어: **greenfield codebase**
= 기존 사용자나 코드와의 호환성을 신경 쓸 필요 없는 새 프로젝트라 깔끔하게 설계 가능함.
사용 예시: "This is a greenfield codebase: no backward compatibility, no legacy shims."
관련 용어: pre-launch, no-compat, breaking changes allowed
```

규칙:

• 메인 용어는 딱 하나만. 관련 용어나 헷갈리기 쉬운 용어는 의미를 더 명확하게 해줄 때만 1~3개 추가해 (의미 차이가 뻔하지 않으면 왜 다른지 짧게 덧붙여).
• 정의는 사전식 나열이 아니라 사용자의 상황에 맞춰 한 줄로 써.
• 사용 예시는 사용자가 지금 당장 프롬프트나 메시지에 복붙해서 쓸 수 있는 문장이어야 해.
• 가장 가까운 용어가 딱 들어맞지 않으면 솔직하게 말해: "가장 가까운 용어: X (근데 X는 보통 Y라는 의미도 포함함)".
• 사용자가 단어만 물어봤다면, 저 블록 자체가 답변의 전부가 돼야 해.

예시

사용자: "코드가 새로 짠 거고, 아직 출시 전이야. 레거시 때문에 하위 호환성 유지할 필요 없고, 싹 다 깔끔하게 정리하고 싶어"
용어: greenfield codebase (관련: pre-launch, no-compat break)

사용자: "글이 좀 이상해. 너무 딱딱하고 격식 차린 느낌? 로봇이나 학교 숙제 같아. 사람이 말하는 느낌이 아님"
용어: stilted (관련: wooden, stiff; purple prose는 아님, 그건 문장이 화려하다는 뜻)

사용자: "진짜 빡세게 검토해줘. 디테일 하나하나 다 보고, 틀렸다고 가정하고 어떻게든 흠집 내봐. 그냥 대충 훑어보고 좋아 보인다고 하지 말고"
용어: rigorous review (관련: adversarial review, 이건 아예 부수려고 덤비는 거임; sanity check는 아님, 그건 겉만 살짝 훑는 거)

사용자: "진짜 실제 결과물처럼 똑같이 만들어줘. 디테일 하나하나 다 살려서. 대충 그린 스케치나 자리표시자 박스 말고"
용어: high fidelity (관련: pixel-perfect, 이건 디자인이랑 픽셀 단위까지 똑같다는 뜻; low fidelity나 wireframe은 아님, 그건 대충 배치만 잡은 거)