kwakseongjae 한 줄. 새로 짓기 전에, 앞선 개발자들이 이미 닦아둔 길을 먼저 본다.
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 …)
- 프레임워크가 이미 깔아둔 길을 두고 옆에 직접 깔기
- 패턴 이름을 권위로 사용해서 비개발자를 위축시키기
패턴은 정답집이 아니다. 같은 문제를 먼저 만난 사람들이 남긴 시작점이다. 그 위에서 시작하고, 안 맞으면 거기서 바꿔간다. 그게 가장 빠르고, 가장 외롭지 않은 길이다.