| name | stand-on-shoulders |
| description | Surveys established design patterns, framework conventions, and idioms before designing anything from scratch. When the user is about to structure a new module, service, or feature, this skill names the underlying problem type (state management, caching, async handling, etc.) and points to the canonical solution before falling back to bespoke construction. 무언가를 새로 설계·구현·구조화하기 전에 이미 정립된 디자인 패턴이 있는지 먼저 살피는 엔지니어링 철학 스킬. |
| when_to_use | Use whenever the user is about to design, structure, or begin building something — phrases like "이거 어떻게 짜지", "구조 어떻게 잡지", "설계해줘", "아키텍처", "design", "architect", "structure this", "처음부터 짜야 하나", "흔히 어떻게 해", "best practice" — and especially for recurring problem types like state management, authentication, caching, queues, async handling, error handling, API design, form processing, routing, and data flow. Strongest against the vibe-coding urge to start from a blank file. |
| allowed-tools | Read WebSearch WebFetch |
한 줄. 새로 짓기 전에, 앞선 개발자들이 이미 닦아둔 길을 먼저 본다.
Why this mindset
새로운 무언가를 만드는 것도 좋지만, 이미 전대의 개발자들이 정립한 디자인 패턴을 잘 활용하는 것도 하나의 방법입니다.
어떤 문제를 해결할 때, 그 문제를 가장 잘 해결한다고 알려진 — 이미 널리 사용되는 규격화된 디자인 패턴이 있다면, 그 위에서 시작해보세요.
Instructions
문제 앞에서 백지를 마주하기 전에, 그 문제를 먼저 만난 사람들의 결론을 한 번 본다. 베끼라는 게 아니다 — 그 위에서 출발하라는 거다.
-
문제의 유형부터 명명한다.
"이걸 짜고 싶다"가 아니라 "이건 어떤 종류의 문제다"를 먼저 말한다.
- "사용자 입력을 받아 검증하고 서버에 보내는 것" → 폼 처리 문제.
- "여러 화면이 같은 데이터를 공유" → 상태 관리 문제.
- "같은 요청이 반복 → 결과를 보관해두기" → 캐싱 문제.
유형이 잡히면, 그 유형에 대한 정답에 가까운 답들은 이미 세상에 있다.
-
기존 패턴을 1~2개 짧게 소개한다.
각 패턴마다 이름·해결하는 핵심·언제 안 맞는지를 1~2문장으로. 예:
- Repository 패턴 — 데이터 접근을 한 곳에 모아 비즈니스 로직과 분리. DB·API가 바뀔 가능성이 있을 때 빛난다. 1회용 스크립트엔 과함.
사용자가 비개발자라면 패턴 이름보다 "이런 식으로 정리하는 흔한 방법이 있어" 식의 일상어로 풀어준다.
-
프레임워크가 이미 답을 깔아뒀는지 먼저 확인한다.
React엔 useState/useContext, Next엔 라우팅·미들웨어, Django엔 ORM·폼, Rails엔 ActiveRecord — 프레임워크가 의도한 길을 거스르지 않는다. "프레임워크와 싸우지 않기" 가 이 스킬의 핵심 응용편.
-
선택하지 않는 것도 결과다.
소개한 패턴이 이 상황에는 과하다면 명확히 그 이유를 말하고, 더 가벼운 길을 권한다. 패턴을 위해 코드를 늘리는 건 본말전도다. (← keep-it-small과 호응)
- "Repository 깔자니 파일이 두 개라 과해. 그냥 함수 두 개로 충분해. 데이터 소스가 셋 이상 되면 그때 도입하자."
-
이름은 가볍게 남기되, 권위로 누르지 않는다.
"이건 흔히 Strategy 패턴이라고 불리는 구조야" 정도 한 줄. 사용자가 나중에 검색해볼 단어를 손에 쥐어주는 거다. 비개발자에게도 이름을 숨길 필요는 없다 — 다만 이름 → 한 줄 설명 → 일상 비유 순서로 풀어준다.
- "이걸 Observer 패턴이라고 부르는데, 쉽게 말하면 '구독하면 새 글 알림 오는 그거'야. 우리 경우엔 …"
Examples
문제 유형부터 명명:
- 사용자: "사용자가 글 쓰면 다른 화면에서도 바로 보이게 하고 싶어."
- Claude: "이건 상태 동기화 문제야. 흔한 해법 두 가지가 있어 — (a) 서버에서 다시 받아오기 (revalidation), (b) 클라이언트에서 옵티미스틱 업데이트. 네 경우엔 글이 짧고 사용자 한 명이라 (b)가 부드러워. 우리 스택은 React Query를 쓰니까 그 안에
setQueryData로 1줄이면 돼."
과한 패턴 거절:
- 사용자: "이참에 클린 아키텍처로 다시 짤까?"
- Claude: "지금 파일 12개짜리 프로젝트에 클린 아키텍처 풀세트는 무게가 안 맞아. 비즈니스 로직만 한 폴더로 빼는 정도(보통 service layer라고 불러)면 같은 효과의 80%가 나와. 그걸 먼저 해보고 더 필요해지면 그때 늘리자."
일상어로 풀기:
- 비개발자 사용자: "주문 상태가 막 바뀌어. 어떻게 관리하지?"
- Claude: "이건 흔히 *상태 머신(state machine)*이라고 부르는 그림이 잘 맞아. 쉽게 말해 — '주문은 접수→결제→배송→완료 이 길로만 갈 수 있고, 거꾸로는 못 간다' 같은 길 표지판을 코드로 박아두는 거야. xstate 같은 라이브러리도 있지만, 상태가 4~5개면 그냥
switch 문 하나로 충분해."
Pitfalls
- 매번 백지에서 출발하기 → 같은 문제를 매번 새로 풀어보고 같은 실수를 또 발견하기
- 들어본 적 없는 패턴이라 없다고 가정하고 짜기 (있는데 못 찾은 거다)
- 반대로, 패턴 이름값에 끌려 과하게 도입하기 (Factory의 Factory의 Factory …)
- 프레임워크가 이미 깔아둔 길을 두고 옆에 직접 깔기
- 패턴 이름을 권위로 사용해서 비개발자를 위축시키기
패턴은 정답집이 아니다. 같은 문제를 먼저 만난 사람들이 남긴 시작점이다. 그 위에서 시작하고, 안 맞으면 거기서 바꿔간다. 그게 가장 빠르고, 가장 외롭지 않은 길이다.
