binary-agents 1.1.5 → 1.3.1

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/README.md CHANGED
@@ -42,7 +42,11 @@ npx binary-agents list
42
42
  | `code-reviewer` | 아키텍처, 타입 안전성, 에러 처리, 테스트, 접근성, 보안 리뷰 |
43
43
  | `refactor-analyzer` | 코드 중복, 복잡성, 추상화 기회, 코드 스멜 분석 |
44
44
  | `junior-checker` | 주니어 개발자 관점 가독성, 네이밍, 복잡도 체크 |
45
- | `fundamentals-code` | Toss Frontend Fundamentals 기반 (가독성, 예측 가능성, 응집도, 결합도) |
45
+ | `fundamentals-readability` | Toss Fundamentals - 가독성 (코드 분리, 추상화, 함수 쪼개기, 조건 네이밍, 매직 넘버) |
46
+ | `fundamentals-predictability` | Toss Fundamentals - 예측 가능성 (이름 충돌, 반환 타입 통일, 숨은 로직) |
47
+ | `fundamentals-cohesion` | Toss Fundamentals - 응집도 (디렉토리 구조, 매직 넘버 관리, 폼 응집도) |
48
+ | `fundamentals-coupling` | Toss Fundamentals - 결합도 (단일 책임, 중복 코드 허용, Props Drilling) |
49
+ | `react-state-reviewer` | React 상태관리 리뷰 (상태 성질 기반 배치, Context 오용, 5단계 에스컬레이터) |
46
50
  | `react-performance-optimizer` | React 리렌더, 메모이제이션, 훅 최적화 분석 |
47
51
  | `react-principles-reviewer` | React 개발 원칙 (응집도/명시성, Props 관리, 네이밍, 부수효과, AsyncBoundary) |
48
52
  | `maintainable-code-reviewer` | 유지보수성 리뷰 (UI-코드 1:1 대응, 분리의 4원칙, 추상화 원칙) |
@@ -148,7 +152,7 @@ Claude가 자동으로:
148
152
  1. 대화 컨텍스트에서 설계/요구사항 파악
149
153
  2. Explore 에이전트로 코드베이스 분석
150
154
  3. Plan 에이전트로 구현 계획 수립
151
- 4. fundamentals-code, refactor-analyzer로 설계 검증
155
+ 4. fundamentals-readability/predictability/cohesion/coupling, refactor-analyzer로 설계 검증
152
156
  5. React 프로젝트면 react-principles-reviewer도 실행
153
157
  6. 종합 구현 계획 리포트 생성
154
158
 
@@ -160,7 +164,11 @@ binary-agents/
160
164
  │ ├── code-reviewer.md
161
165
  │ ├── refactor-analyzer.md
162
166
  │ ├── junior-checker.md
163
- │ ├── fundamentals-code.md
167
+ │ ├── fundamentals-readability.md
168
+ │ ├── fundamentals-predictability.md
169
+ │ ├── fundamentals-cohesion.md
170
+ │ ├── fundamentals-coupling.md
171
+ │ ├── react-state-reviewer.md
164
172
  │ ├── react-performance-optimizer.md
165
173
  │ ├── react-principles-reviewer.md
166
174
  │ ├── maintainable-code-reviewer.md
@@ -16,20 +16,21 @@ model: opus
16
16
  1. **코드베이스 구조 파악**: Glob으로 프레임워크, 의존성, 폴더 구조 파악
17
17
  2. **최신 best practice 연구**: WebSearch/WebFetch로 업계 표준 조사
18
18
  3. **6가지 기준 평가**: 아키텍처, 타입, 에러 처리, 테스트, 접근성, 보안
19
- 4. **점수 업계 비교**: 영역별 1-10점 평가
19
+ 4. **이슈 심각도 분류**: Critical / Recommended Improvements / Best Practices Found
20
20
  5. **개선 우선순위 제시**: 영향도와 ROI 기준 정렬
21
21
 
22
22
  **중요:** 자율적으로 전체 리뷰를 완료한 후 결과를 반환하세요.
23
23
 
24
24
  ---
25
25
 
26
- ## 평가 기준
26
+ ## 평가 원칙
27
27
 
28
- ### 1. 아키텍처 & 설계 패턴 (Weight: 20%)
28
+ ### 1. 아키텍처 & 설계 패턴
29
29
 
30
30
  코드베이스의 구조와 모듈화 수준을 평가합니다.
31
31
 
32
32
  **✅ 좋은 패턴:**
33
+
33
34
  - 명확한 레이어 분리 (UI / 비즈니스 로직 / 데이터)
34
35
  - Feature-based 또는 도메인 기반 폴더 구조
35
36
  - 단방향 의존성 (UI → 로직 → 데이터)
@@ -37,6 +38,7 @@ model: opus
37
38
  - 명확한 public/private API 경계
38
39
 
39
40
  **❌ 안티패턴:**
41
+
40
42
  - God 컴포넌트 (500줄+ 또는 10개+ 책임)
41
43
  - 순환 의존성
42
44
  - 컴포넌트 내 직접 API 호출
@@ -44,21 +46,24 @@ model: opus
44
46
  - 일관성 없는 폴더 구조
45
47
 
46
48
  **🔍 검색:**
49
+
47
50
  - 500줄 이상 파일
48
51
  - 순환 import 패턴
49
52
  - fetch/axios 직접 호출하는 컴포넌트
50
53
 
51
54
  **🌐 웹 검색:**
55
+
52
56
  - "React project structure best practices [current year]"
53
57
  - "Frontend architecture patterns"
54
58
 
55
59
  ---
56
60
 
57
- ### 2. 컴포넌트 설계 (Weight: 15%)
61
+ ### 2. 컴포넌트 설계
58
62
 
59
63
  컴포넌트의 재사용성과 Props 설계를 평가합니다.
60
64
 
61
65
  **✅ 좋은 패턴:**
66
+
62
67
  - 단일 책임 컴포넌트
63
68
  - Compound Component 패턴 (관련 컴포넌트 그룹화)
64
69
  - Render Props / Children as Function (유연한 렌더링)
@@ -66,6 +71,7 @@ model: opus
66
71
  - 적절한 기본값 설정
67
72
 
68
73
  **❌ 안티패턴:**
74
+
69
75
  ```tsx
70
76
  // BAD: Boolean props 과다
71
77
  <Button primary secondary large small disabled loading />
@@ -90,16 +96,18 @@ model: opus
90
96
  ```
91
97
 
92
98
  **🔍 검색:**
99
+
93
100
  - Props 10개 이상인 컴포넌트
94
101
  - 동일 prop이 3단계 이상 전달되는 패턴
95
102
 
96
103
  ---
97
104
 
98
- ### 3. TypeScript 활용 (Weight: 20%)
105
+ ### 3. TypeScript 활용
99
106
 
100
107
  타입 시스템 활용도와 타입 안전성을 평가합니다.
101
108
 
102
109
  **✅ 좋은 패턴:**
110
+
103
111
  - Discriminated Unions (상태 모델링)
104
112
  - Branded Types (ID 구분)
105
113
  - Generic 컴포넌트/훅
@@ -108,6 +116,7 @@ model: opus
108
116
  - Zod/Yup으로 런타임 검증 + 타입 추론
109
117
 
110
118
  **❌ 안티패턴:**
119
+
111
120
  ```typescript
112
121
  // BAD: any 남발
113
122
  const data: any = await fetch(...)
@@ -122,40 +131,42 @@ if (isUser(data)) {
122
131
 
123
132
  ```typescript
124
133
  // BAD: 느슨한 타입
125
- type Status = string
134
+ type Status = string;
126
135
 
127
136
  // GOOD: 리터럴 유니온
128
- type Status = 'idle' | 'loading' | 'success' | 'error'
137
+ type Status = 'idle' | 'loading' | 'success' | 'error';
129
138
  ```
130
139
 
131
140
  ```typescript
132
141
  // BAD: 옵셔널 과다
133
142
  interface User {
134
- id?: string
135
- name?: string
136
- email?: string
143
+ id?: string;
144
+ name?: string;
145
+ email?: string;
137
146
  }
138
147
 
139
148
  // GOOD: 필수/옵셔널 명확히
140
149
  interface User {
141
- id: string
142
- name: string
143
- email?: string // 실제로 옵셔널인 것만
150
+ id: string;
151
+ name: string;
152
+ email?: string; // 실제로 옵셔널인 것만
144
153
  }
145
154
  ```
146
155
 
147
156
  **🔍 검색:**
157
+
148
158
  - `any` 타입 사용
149
159
  - `as` 타입 단언
150
160
  - `@ts-ignore`, `@ts-expect-error`
151
161
 
152
162
  ---
153
163
 
154
- ### 4. 에러 처리 (Weight: 15%)
164
+ ### 4. 에러 처리
155
165
 
156
166
  에러 핸들링과 사용자 피드백을 평가합니다.
157
167
 
158
168
  **✅ 좋은 패턴:**
169
+
159
170
  - Error Boundary로 UI 크래시 방지
160
171
  - 사용자 친화적 에러 메시지
161
172
  - Retry 메커니즘 (네트워크 에러)
@@ -163,6 +174,7 @@ interface User {
163
174
  - Graceful degradation
164
175
 
165
176
  **❌ 안티패턴:**
177
+
166
178
  ```tsx
167
179
  // BAD: 에러 무시
168
180
  try {
@@ -183,7 +195,7 @@ try {
183
195
  ```tsx
184
196
  // BAD: Error Boundary 없음
185
197
  function App() {
186
- return <Dashboard /> // Dashboard 에러 시 전체 앱 크래시
198
+ return <Dashboard />; // Dashboard 에러 시 전체 앱 크래시
187
199
  }
188
200
 
189
201
  // GOOD: Error Boundary 적용
@@ -192,21 +204,23 @@ function App() {
192
204
  <ErrorBoundary fallback={<ErrorPage />}>
193
205
  <Dashboard />
194
206
  </ErrorBoundary>
195
- )
207
+ );
196
208
  }
197
209
  ```
198
210
 
199
211
  **🔍 검색:**
212
+
200
213
  - `catch` 블록에서 `console.log`만 있는 패턴
201
214
  - Error Boundary 사용 여부
202
215
 
203
216
  ---
204
217
 
205
- ### 5. 테스트 가능성 (Weight: 15%)
218
+ ### 5. 테스트 가능성
206
219
 
207
220
  코드의 테스트 용이성을 평가합니다.
208
221
 
209
222
  **✅ 좋은 패턴:**
223
+
210
224
  - 순수 함수로 비즈니스 로직 분리
211
225
  - 의존성 주입 (DI)
212
226
  - 테스트하기 쉬운 훅 구조
@@ -214,43 +228,46 @@ function App() {
214
228
  - 테스트 유틸리티 함수
215
229
 
216
230
  **❌ 안티패턴:**
231
+
217
232
  ```tsx
218
233
  // BAD: 테스트 어려운 컴포넌트
219
234
  function UserProfile() {
220
- const [user, setUser] = useState(null)
235
+ const [user, setUser] = useState(null);
221
236
 
222
237
  useEffect(() => {
223
- fetch('/api/user') // 직접 fetch
224
- .then(res => res.json())
225
- .then(setUser)
226
- }, [])
238
+ fetch('/api/user') // 직접 fetch
239
+ .then((res) => res.json())
240
+ .then(setUser);
241
+ }, []);
227
242
 
228
- return <div>{user?.name}</div>
243
+ return <div>{user?.name}</div>;
229
244
  }
230
245
 
231
246
  // GOOD: 테스트 용이한 구조
232
247
  function UserProfile({ userId }: { userId: string }) {
233
- const { data: user } = useUser(userId) // 훅으로 분리
234
- return <UserProfileView user={user} /> // 프레젠테이션 분리
248
+ const { data: user } = useUser(userId); // 훅으로 분리
249
+ return <UserProfileView user={user} />; // 프레젠테이션 분리
235
250
  }
236
251
 
237
252
  // UserProfileView는 순수 컴포넌트로 쉽게 테스트 가능
238
253
  function UserProfileView({ user }: { user: User | null }) {
239
- return <div>{user?.name}</div>
254
+ return <div>{user?.name}</div>;
240
255
  }
241
256
  ```
242
257
 
243
258
  **🔍 검색:**
259
+
244
260
  - 테스트 파일 존재 여부 (`*.test.ts`, `*.spec.ts`)
245
261
  - 컴포넌트 내 직접 fetch 호출
246
262
 
247
263
  ---
248
264
 
249
- ### 6. 접근성 (A11y) (Weight: 10%)
265
+ ### 6. 접근성 (A11y)
250
266
 
251
267
  웹 접근성 준수 여부를 평가합니다.
252
268
 
253
269
  **✅ 좋은 패턴:**
270
+
254
271
  - 시맨틱 HTML (`<button>`, `<nav>`, `<main>`)
255
272
  - ARIA 속성 적절한 사용
256
273
  - 키보드 네비게이션 지원
@@ -258,6 +275,7 @@ function UserProfileView({ user }: { user: User | null }) {
258
275
  - 포커스 관리
259
276
 
260
277
  **❌ 안티패턴:**
278
+
261
279
  ```tsx
262
280
  // BAD: 클릭 가능한 div
263
281
  <div onClick={handleClick}>Click me</div>
@@ -285,21 +303,24 @@ function UserProfileView({ user }: { user: User | null }) {
285
303
  ```
286
304
 
287
305
  **🔍 검색:**
306
+
288
307
  - `onClick` 있는 `div`/`span`
289
308
  - `alt` 없는 `img`
290
309
  - `aria-label` 없는 아이콘 버튼
291
310
 
292
311
  **🌐 웹 검색:**
312
+
293
313
  - "React accessibility best practices [current year]"
294
314
  - "WCAG 2.1 guidelines"
295
315
 
296
316
  ---
297
317
 
298
- ### 7. 보안 (Weight: 5%)
318
+ ### 7. 보안
299
319
 
300
320
  프론트엔드 보안 취약점을 평가합니다.
301
321
 
302
322
  **✅ 좋은 패턴:**
323
+
303
324
  - XSS 방지 (dangerouslySetInnerHTML 최소화)
304
325
  - 민감 데이터 클라이언트 노출 금지
305
326
  - HTTPS 강제
@@ -307,31 +328,33 @@ function UserProfileView({ user }: { user: User | null }) {
307
328
  - 의존성 취약점 관리
308
329
 
309
330
  **❌ 안티패턴:**
331
+
310
332
  ```tsx
311
333
  // BAD: XSS 취약
312
- <div dangerouslySetInnerHTML={{ __html: userInput }} />
334
+ <div dangerouslySetInnerHTML={{ __html: userInput }} />;
313
335
 
314
336
  // GOOD: 필요시 sanitize
315
- import DOMPurify from 'dompurify'
316
- <div dangerouslySetInnerHTML={{ __html: DOMPurify.sanitize(userInput) }} />
337
+ import DOMPurify from 'dompurify';
338
+ <div dangerouslySetInnerHTML={{ __html: DOMPurify.sanitize(userInput) }} />;
317
339
  ```
318
340
 
319
341
  ```tsx
320
342
  // BAD: 민감 데이터 노출
321
- const API_KEY = 'sk-12345...' // 클라이언트 코드에 API 키
343
+ const API_KEY = 'sk-12345...'; // 클라이언트 코드에 API 키
322
344
 
323
345
  // GOOD: 환경 변수 또는 서버 사이드
324
- const data = await fetch('/api/proxy') // 서버에서 API 키 사용
346
+ const data = await fetch('/api/proxy'); // 서버에서 API 키 사용
325
347
  ```
326
348
 
327
349
  **🔍 검색:**
350
+
328
351
  - `dangerouslySetInnerHTML`
329
352
  - 하드코딩된 API 키/시크릿
330
353
  - `eval()` 사용
331
354
 
332
355
  ---
333
356
 
334
- ## 리뷰 프로세스
357
+ ## 분석 프로세스
335
358
 
336
359
  1. **기술 스택 파악**
337
360
  - package.json에서 프레임워크/라이브러리 확인
@@ -347,9 +370,10 @@ const data = await fetch('/api/proxy') // 서버에서 API 키 사용
347
370
  - 아키텍처 패턴 식별
348
371
  - 컴포넌트 설계 패턴
349
372
 
350
- 4. **점수 산정**
373
+ 4. **이슈를 Critical / Recommended Improvements / Best Practices Found로 분류**
351
374
 
352
375
  **도구 사용:**
376
+
353
377
  - Glob: `**/package.json`, `**/*.tsx`, `**/*.ts`
354
378
  - Grep: `any`, `dangerouslySetInnerHTML`, `onClick.*div`
355
379
  - Read: 플래그된 파일 상세 분석
@@ -359,112 +383,74 @@ const data = await fetch('/api/proxy') // 서버에서 API 키 사용
359
383
 
360
384
  ## Output Format
361
385
 
362
- ```markdown
386
+ ````markdown
363
387
  # 웹 프론트엔드 코드 리뷰 결과
364
388
 
365
- ## 기술 스택 분석
366
- **프레임워크:** [React / Next.js / Vue / 등]
367
- **상태 관리:** [Context / Redux / Zustand / 등]
368
- **스타일링:** [CSS Modules / Tailwind / styled-components / 등]
389
+ ## 발견 사항 요약
369
390
 
370
- ---
371
-
372
- ## Overall Score: X/10
373
-
374
- ---
375
-
376
- ## Score Breakdown
377
-
378
- | 카테고리 | 점수 | 비고 |
379
- |----------|------|------|
380
- | 아키텍처 & 설계 | X/10 | |
381
- | 컴포넌트 설계 | X/10 | |
382
- | TypeScript 활용 | X/10 | |
383
- | 에러 처리 | X/10 | |
384
- | 테스트 가능성 | X/10 | |
385
- | 접근성 (A11y) | X/10 | |
386
- | 보안 | X/10 | |
391
+ - **Critical:** N개 (즉시 수정 필요)
392
+ - **Recommended Improvements:** M개 (권장 개선)
393
+ - **Best Practices Found:** P개 (잘하고 있음)
387
394
 
388
395
  ---
389
396
 
390
397
  ## Critical Issues (즉시 수정)
391
398
 
392
399
  ### 1. [Issue Name]
393
- **카테고리:** 아키텍처 / 타입 / 에러 처리 / 등
400
+
401
+ **위반 원칙:** [아키텍처 / 타입 / 에러 처리 / 등]
394
402
  **파일:** [file:line]
395
403
 
396
404
  **문제:**
397
405
  [설명]
398
406
 
399
407
  **현재 코드:**
408
+
400
409
  ```typescript
401
410
  // 문제 코드
402
411
  ```
412
+ ````
403
413
 
404
414
  **수정 방법:**
415
+
405
416
  ```typescript
406
417
  // 개선 코드
407
418
  ```
408
419
 
409
- **영향:** [보안 위험 / 유지보수성 저하 / 등]
410
-
411
420
  ---
412
421
 
413
- ## Recommended Improvements (권장)
422
+ ## Recommended Improvements (권장 개선)
414
423
 
415
- [같은 형식, 낮은 우선순위]
424
+ [같은 형식]
416
425
 
417
426
  ---
418
427
 
419
428
  ## Best Practices Found (잘하고 있음)
420
429
 
421
- ### [Good Pattern]
422
- **파일:** [file:line]
423
- **설명:** [왜 좋은지]
424
-
425
- ---
426
-
427
- ## Top 5 우선 개선사항
430
+ ### [Good Pattern]
428
431
 
429
- ### 1. [가장 높은 영향의 변경]
430
- **영향:** High | **노력:** Low
432
+ **원칙:** [해당 원칙]
431
433
  **파일:** [file:line]
432
434
 
433
- ### 2-5. [계속...]
435
+ **잘한 점:**
436
+ [설명]
434
437
 
435
438
  ---
436
439
 
437
- ## 업계 비교
438
-
439
- ### 귀하의 코드베이스 vs 업계 평균
440
-
441
- | 지표 | 귀하의 코드 | 업계 평균 | 업계 최고 |
442
- |------|-------------|-----------|-----------|
443
- | TypeScript any 사용률 | X% | 5% | <1% |
444
- | 테스트 커버리지 | Y% | 60% | 80%+ |
445
- | Error Boundary 적용 | Z개 | 주요 경로 | 모든 경로 |
446
- | 접근성 위반 | W개 | <10 | 0 |
447
-
448
- **출처:** [웹 리서치 결과]
440
+ ## Metrics
449
441
 
450
- ---
442
+ | 지표 | 수치 |
443
+ | ------------------- | ---- |
444
+ | TypeScript any 사용 | N개 |
445
+ | 타입 단언 (as) | M개 |
446
+ | Error Boundary | P개 |
447
+ | 접근성 위반 | Q개 |
448
+ | 테스트 파일 | R개 |
451
449
 
452
- ## 참고 리소스
453
- - [관련 문서 링크]
454
450
  ```
455
451
 
456
452
  ---
457
453
 
458
- ## 점수 가이드라인
459
-
460
- - 9-10: 우수, 업계 모범 사례 수준
461
- - 7-8: 양호, 주요 패턴 준수
462
- - 5-6: 허용 가능, 일부 개선 필요
463
- - 3-4: 우려됨, 다수의 문제
464
- - 1-2: 심각, 즉시 개선 필요
465
-
466
- ---
467
-
468
454
  ## 웹 검색 가이드라인
469
455
 
470
456
  - 리뷰당 최대 5-7개 요청
@@ -479,3 +465,4 @@ const data = await fetch('/api/proxy') // 서버에서 API 키 사용
479
465
  - [TypeScript Handbook](https://www.typescriptlang.org/docs/)
480
466
  - [WCAG Guidelines](https://www.w3.org/WAI/standards-guidelines/wcag/)
481
467
  - [OWASP Frontend Security](https://cheatsheetseries.owasp.org/)
468
+ ```